토큰은 싸다: AI 시대 엔지니어링 비용의 재계산

URL: https://www.youtube.com/watch?v=U7ZYBCcdJPg 날짜: 2026-10-14 채널: aiDotEngineer (AI Engineer)

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 사용료가 급증해도 엔지니어링 결과물 1건의 총비용은 낮아질 수 있는가?== 핵심 답은 모델 호출료만 따로 떼어 보지 말고, 개발자 급여와 AI 비용을 합친 총 엔지니어링 비용을 결과물과 함께 계산해야 한다는 데 있다.

• Jellyfish의 엔지니어링 데이터에서 AI 지출은 관찰 기간 동안 60배 증가했다.
• 엔지니어 1인당 merge된 pull request 수는 43% 늘었다.
• 개발자 급여와 AI 비용을 함께 배분한 merge PR당 비용은 26% 감소했다.
• 가장 큰 비용 항목은 여전히 token bill이 아니라 개발자 급여다.
• 이 비교는 관찰 연구이므로 token 지출이 처리량 증가를 일으켰다는 인과관계나 기업의 현금 절감을 증명하지 않는다.

토큰 가격 상한만 정해 사용량을 억제하면 급여라는 큰 비용과 그 급여가 만들어 내는 처리량을 함께 놓칠 수 있다. 반대로 PR 개수나 lines of code만 생산성으로 간주해 AI 사용을 무제한 장려해도 고객 가치, 품질, 유지보수 부담을 놓친다. 비용·산출량·품질을 같은 시간 창과 같은 기준으로 측정한 뒤, 추가 token cost가 더 많은 유효한 결과물을 통해 상쇄되는지를 판단해야 한다.

1. AI 지출과 처리량이 동시에 움직이는 이유

AI 사용량만 보면 비용 폭증처럼 보이지만, 전체 경제성은 인건비와 결과물의 분모를 넣었을 때 달라진다.

1.1. 첫 관찰: AI 지출 60배, merge PR 43% 증가

1. 두 지표의 동시 변화

   1. AI 투자 확대: 비교 기간 동안 조직의 AI 관련 지출이 60배 커졌다.
   2. 엔지니어당 처리량 증가: 엔지니어 1명에게 귀속되는 merged pull request 수가 43% 늘었다.
   3. 표면적 긴장: AI 비용만 보면 생산성 개선보다 비용 증가가 먼저 보이지만, PR당 비용은 결과물의 분모가 커질 때 다른 방향으로 움직일 수 있다.

2. 단순한 상관관계가 주는 신호

   1. 경제적 질문의 전환: “AI 청구서가 올랐는가?”보다 “추가 지출이 유효한 엔지니어링 결과를 얼마나 더 만들었는가?”가 경영 판단에 적합하다.
   2. 측정 단위의 중요성: 총액, 엔지니어 수, merged PR 수를 같은 기간에 맞추지 않으면 AI 도입 효과와 조직 규모 변화를 혼동하게 된다.

1.2. 인과관계와 현금 절감의 한계

1. 관찰 데이터의 의미

   1. 원인 입증의 부재: AI 지출 증가와 처리량 증가가 함께 나타났다는 사실만으로 AI가 증가분을 만들었다고 말할 수 없다.
   2. 동시 변화 가능성: 팀 구성, 프로젝트 종류, 프로세스 개선, 채용 수준, 시장 상황이 두 지표를 함께 움직였을 수 있다.

2. 생산성 상승과 비용 절감의 구분

   1. 배분 비용의 감소: 한 PR에 배분되는 총비용이 낮아지는 것은 더 많은 산출물이 같은 급여 비용을 나눠 부담한다는 뜻이다.
   2. 현금흐름의 불변 가능성: 조직이 개발자를 해고하거나 예산을 줄이지 않았다면 PR당 비용 하락이 곧바로 현금 지출 감소를 뜻하지는 않는다.

2. PR당 비용을 계산하는 방식

엔지니어링 생산성은 모델 사용료가 아니라 사람과 도구를 합친 비용을 결과물에 배분할 때 더 현실적으로 측정된다.

2.1. 급여를 모델 비용과 함께 넣기

1. 비용 분자와 분모의 재구성

   1. 주요 비용: 개발자 급여가 총비용의 가장 큰 부분을 차지하므로 token cost만 관리하면 경제성의 핵심을 빠뜨린다.
   2. 추가 비용: 모델 호출료와 agent 사용료는 급여에 비해 작을 수 있지만, 사용량이 급증하면 별도 항목으로 추적해야 한다.
   3. 배분 방식: 일정 기간의 급여와 AI 관련 비용을 합산하고 같은 기간에 merge된 PR 수로 나누면 merged PR당 배분 비용을 얻는다.

2. 26% 하락의 해석

   1. 총비용 기준: 급여와 AI 비용을 합친 비용을 merged PR 수에 배분했을 때 PR당 비용이 26% 낮아졌다.
   2. 토큰의 상대적 위치: AI 비용이 60배 증가해도 급여가 압도적인 비용으로 남아 있으면, 처리량 증가가 추가 token bill보다 크게 나타날 수 있다.
   3. 조건부 결론: 더 많은 PR이 실제로 유효하고 품질이 유지될 때에만 PR당 비용 하락이 의미 있는 개선이 된다.

2.2. 비용 모델이 답하지 못하는 것

1. 배분의 가정

   1. 결과물 동일성 가정: PR 수는 모든 PR의 사업적 가치와 난이도가 같다고 보장하지 않는다.
   2. 시간 창의 영향: 짧은 관찰 기간은 아직 리뷰되지 않은 변경이나 나중에 되돌릴 변경을 개선으로 집계할 수 있다.

2. 현금비용과 기회비용

   1. 급여의 고정성: 인력이 그대로라면 생산성 증가는 더 많은 기능을 만들 여지를 주지만, 당장 급여 지출을 줄이지는 않는다.
   2. 기회비용: 같은 팀이 더 많은 PR을 만들면서 중요한 문제에 집중했는지, 아니면 작은 변경을 많이 쪼개 처리했는지는 별도로 확인해야 한다.

3. 지출 수준별 조직 비교

AI 비용이 더 큰 조직과 작은 조직을 비교하면 도입 강도와 결과물의 관계를 볼 수 있지만, 그룹 비교만으로 우열을 확정할 수는 없다.

3.1. 가벼운 사용 그룹과 무거운 사용 그룹

1. 그룹을 나누는 목적

   1. 사용 강도 관찰: 조직별 AI 지출 수준을 기준으로 더 가볍게 쓰는 그룹과 더 무겁게 쓰는 그룹을 나눈다.
   2. 결과 비교: 각 그룹의 엔지니어당 merged PR과 비용 지표를 비교해 추가 사용료가 추가 산출량과 함께 나타나는지 본다.

2. 그룹 비교의 주의점

   1. 선택 편향: AI를 많이 쓰는 조직은 원래 자동화 역량, 개발 문화, 리더십, 프로젝트 구조가 다를 수 있다.
   2. 인력 구성 효과: 같은 PR 수라도 시니어 비중, 제품 영역, 레거시 비율, 팀 규모가 다르면 급여와 처리량이 달라진다.
   3. 비용 상쇄 조건: 고사용 그룹의 비용이 정당화되려면 단순한 활동량이 아니라 더 많은 유효 산출과 허용 가능한 품질이 확인되어야 한다.

3.2. 조직 간 비교를 운영 지표로 바꾸기

1. 비교 단위 통일

   1. 엔지니어당 정규화: 팀 크기가 다른 조직을 비교할 때 총 PR이 아니라 엔지니어 1인당 결과를 사용한다.
   2. 같은 회계 범위: 급여, 모델 비용, 관련 플랫폼 비용을 같은 기간과 동일한 조직 범위로 집계한다.

2. 결과 해석

   1. 효율 신호: 더 높은 AI 사용이 더 낮은 총비용/PR과 함께 나타나면 투자 효율을 조사할 근거가 된다.
   2. 결정 근거의 한계: 그룹 평균은 개별 팀의 최적 사용량이나 모든 업무에 적용할 예산 상한을 알려주지 않는다.

4. 한 개발자의 주차별 비교

조직 간 차이를 줄이기 위해 같은 개발자의 agent 활용 주간과 비활용 주간을 비교하면 개인별 업무 패턴을 통제하는 데 도움이 된다.

4.1. 자기 자신의 이전 주와 비교

1. 비교 설계

   1. 개인 기준선: 개발자마다 과거 주간 성과를 기준선으로 삼아 사람마다 다른 능력과 역할의 영향을 줄인다.
   2. 사용 강도 구분: agent skill을 더 적극적으로 사용한 주와 그렇지 않은 주를 나누어 merged PR과 비용 변화를 본다.
   3. 변동성 확인: 한 주의 특수한 프로젝트나 휴일 효과가 평균을 왜곡하지 않도록 여러 기간을 관찰해야 한다.

2. 이 방식의 장점

   1. 개인 차이 완화: 서로 다른 조직을 비교하는 것보다 동일인의 능력과 역할이 일정하다는 가정에 가까워진다.
   2. 업무 맥락 보존: 개발자가 실제로 어떤 업무와 도구 조합으로 일하는지에 기반해 AI 사용의 운영 효과를 볼 수 있다.

4.2. 자기 비교의 함정

1. 시간에 따른 변화

   1. 학습 효과: 개발자가 시간이 지나며 숙련되면 AI 사용과 무관하게 처리량이 좋아질 수 있다.
   2. 업무 난이도 변화: agent를 쓰는 주에 더 작고 반복적인 일을 배정받았을 가능성도 있다.

2. 해석 규칙

   1. 상관관계 유지: 사용 주간에 PR이 늘어났더라도 agent가 유일한 원인이라고 단정하지 않는다.
   2. 추가 검증: 품질, 리뷰 시간, 재작업, 사용자 영향까지 붙여야 주간 처리량이 실질 생산성인지 판단할 수 있다.

5. 품질과 작업 크기를 함께 측정하기

PR 수가 늘어나는 것만으로는 가치가 보장되지 않으므로 되돌림, 변경 크기, 리뷰 부담을 함께 봐야 한다.

5.1. revert를 제한적인 품질 신호로 사용하기

1. revert의 의미

   1. 빠른 사후 신호: merge된 변경이 되돌려졌는지는 명백한 실패의 한 가지 신호가 될 수 있다.
   2. 측정의 용이성: 제품 가치나 설계 품질보다 자동 집계하기 쉽기 때문에 초기 품질 분석에 사용할 수 있다.

2. revert만으로 부족한 이유

   1. 부분 관측: 모든 결함이 revert로 이어지는 것은 아니며, 되돌림 없이 남은 버그도 많다.
   2. 시간 지연: 문제는 merge 직후가 아니라 사용자가 기능을 쓴 뒤나 운영 환경에서 발견될 수 있다.
   3. 정상적 revert: 실험, 롤백, 배포 전략 때문에 되돌린 변경은 AI가 만든 결함과 다를 수 있다.

5.2. lines of code와 PR 개수의 한계

1. 활동량과 가치의 차이

   1. LOC의 함정: 코드가 많아졌다는 사실은 복잡성이나 낭비가 늘었다는 뜻일 수도 있다.
   2. PR 개수의 함정: 하나의 큰 기능을 여러 작은 PR로 쪼개면 숫자가 늘지만 고객에게 전달된 가치가 늘었다고 할 수 없다.

2. 작업 크기까지 보기

   1. 변경 규모: PR 수와 함께 추가·삭제 라인, 파일 수, 리뷰 시간, 변경의 성격을 확인해야 한다.
   2. 유지보수 부담: 더 많은 코드가 장기적인 테스트, 운영, 문서화 비용을 늘릴 수 있으므로 단기 처리량과 장기 비용을 연결해야 한다.
   3. 문제 적합성: 큰 변경이나 많은 변경이 올바른 고객 문제를 해결했는지 별도 평가가 필요하다.

6. 토큰 지출 상한을 정하기 전의 경영 질문

예산 통제는 필요하지만 token bill 하나를 근거로 상한을 정하면 인건비와 결과물의 관계를 잘못 최적화할 수 있다.

6.1. 비용·산출량·품질의 균형

1. 먼저 확인할 지표

   1. 총 엔지니어링 비용: 개발자 급여, 모델 호출료, agent 플랫폼 비용을 같은 기간에 합산한다.
   2. 정규화된 산출량: 엔지니어당 merged PR을 기본 지표로 두되, 작업 크기와 제품 영역을 함께 기록한다.
   3. 품질 신호: revert, 결함, incident, 리뷰 재작업, 고객 영향 같은 후행 지표를 처리량과 나란히 둔다.

2. 상한의 판단 조건

   1. 추가 비용의 한계효용: token 사용량이 늘 때 추가 결과물과 품질 개선이 계속되는지 본다.
   2. 팀별 차이: 업무 유형과 모델 활용도가 다른 팀에 동일한 상한을 일괄 적용하지 않는다.
   3. 낭비 차단: 품질과 가치가 개선되지 않는 반복 호출은 제한하되, 유효한 작업을 단순 비용 때문에 막지 않는다.

6.2. 리더가 피해야 할 두 극단

1. 모델 비용만 줄이는 극단

   1. 잘못된 최적화: 작은 token bill을 만들기 위해 개발자 시간을 더 쓰게 하면 전체 비용은 오히려 커질 수 있다.
   2. 기회 손실: agent가 처리할 수 있는 반복 작업을 수동으로 남겨 핵심 문제에 쓸 시간을 줄일 수 있다.

2. 결과물 숫자만 늘리는 극단

   1. 가짜 처리량: 의미가 작은 PR이나 과도하게 쪼갠 변경은 지표를 개선해도 제품 가치를 높이지 않는다.
   2. 품질 부채: 리뷰와 유지보수 능력을 초과한 산출량은 뒤늦은 결함과 운영 비용으로 돌아온다.

주요 발언 모음

“Tokens are the cheap part.”

제목의 문장은 모델 호출료를 무시하자는 뜻이 아니라, 엔지니어링 비용 구조에서 가장 큰 항목이 사람의 시간일 수 있다는 문제 제기다. 따라서 비용 판단은 token bill과 급여를 함께 놓고 결과물과 품질에 배분해야 한다.

핵심 데이터 & 수치

• AI 지출: 관찰 기간 동안 60배 증가했다.
• 엔지니어당 merged PR: 43% 증가했다.
• 급여와 AI 비용을 합친 merged PR당 비용: 26% 감소했다.
• 영상 길이: 약 17분 31초(1,051초)다.
• 핵심 비교 구간: AI 지출과 PR 처리량(00:00), 급여를 비용 모델에 추가(02:48), PR당 배분 비용(04:15), 지출 수준별 그룹 비교(05:00), 개인의 이전 주 비교(08:55), revert 신호(10:12), 작업 크기와 LOC(11:02), token 상한 전 질문(15:02) 순서로 전개된다.
• 데이터 성격: 관찰 비교이며, AI 지출이 처리량 증가의 원인이라는 인과관계나 동일한 규모의 현금 절감을 입증하지 않는다.

결론 및 시사점

1. 토큰 가격을 단독 KPI로 삼지 않는다: 급여가 가장 큰 비용이라면 모델 비용 절감만으로 전체 효율을 판단할 수 없다.
2. PR당 총비용을 계산한다: 급여와 AI 비용을 합쳐 결과물에 배분하고, 엔지니어 수와 업무 기간을 정규화한다.
3. 처리량과 품질을 묶는다: merged PR, 작업 크기, 리뷰 부담, revert, 결함과 고객 영향을 함께 추적한다.
4. 상관관계와 인과관계를 분리한다: AI를 많이 쓴 조직이나 주간에 결과가 좋았더라도 업무·인력·프로세스 차이를 점검한다.
5. 팀별 한계효용을 찾는다: 추가 token 지출이 유효한 결과와 품질을 늘리는 구간까지 허용하고, 효과가 끊기는 사용 패턴을 제한한다.
6. 궁극적인 분모는 고객 가치다: 많은 코드와 PR보다 올바른 문제를 해결하고 운영 가능한 제품을 내놓는지가 최종 판단 기준이다.

핵심 요약 20줄

AI 지출이 60배 늘어도 결과물과 급여를 함께 계산하면 엔지니어링 효율은 개선될 수 있다. 엔지니어당 merged pull request 수는 관찰 기간 동안 43% 증가했다. 개발자 급여와 AI 비용을 합친 merged PR당 배분 비용은 26% 감소했다. 전체 비용에서 가장 큰 항목은 모델 호출료보다 개발자 급여로 남았다. 토큰 비용만 줄이는 정책은 더 큰 인건비와 기회비용을 보지 못할 수 있다. PR당 비용은 일정 기간의 급여와 AI 비용을 merged PR 수에 배분해 계산한다. 추가 token bill은 결과물 증가가 충분하면 전체 비용 하락과 공존할 수 있다. 관찰된 동시 변화만으로 AI 지출이 처리량 증가를 일으켰다고 말할 수 없다. 조직 규모와 업무 차이는 AI 사용량과 생산성 지표를 동시에 바꿀 수 있다. AI 지출 수준이 다른 조직을 비교하면 도입 강도를 평가할 단서를 얻는다. 동일 개발자의 agent 사용 주간과 이전 주를 비교하면 개인차를 일부 줄일 수 있다. 주간 비교도 업무 난이도와 시간에 따른 숙련도 변화를 완전히 제거하지 못한다. Revert는 품질을 보여 주는 빠른 신호지만 모든 결함을 포착하지는 못한다. Lines of code와 PR 개수는 활동량을 보여 줄 뿐 고객 가치를 보장하지 않는다. 작업 크기와 리뷰 부담을 함께 측정해야 처리량 증가의 의미를 해석할 수 있다. 더 많은 변경은 테스트와 유지보수 비용을 늘려 장기 비용을 키울 수 있다. 토큰 사용 상한은 비용·산출량·품질의 한계효용을 확인한 뒤 정해야 한다. 팀마다 업무 유형과 agent 활용 방식이 달라 일괄적인 상한은 위험하다. 관리자는 작은 모델 청구서와 큰 결과물 숫자 중 하나만 최적화해서는 안 된다. 최종 판단 기준은 token bill이 아니라 품질을 갖춘 고객 가치당 총 엔지니어링 비용이다.