저렴한 AI 코드 생성(Code Generation)이 반드시 비용 절감을 의미하지 않는 이유

많은 AI 지원 워크플로우(workflows)에서 코드 생성(code generation)은 더 이상 유일한 병목 현상(bottleneck)이 아닙니다. 어시스턴트(Assistants)는 저장소(repositories)를 읽고, 파일을 편집하며, 명령어를 실행하고, 테스트를 작성합니다. 에이전트 시스템(Agentic systems)은 계획을 세우고, 도구(tools)를 호출하며, 더 많은 컨텍스트(context)를 검색하고, 여러 단계 또는 여러 모델에 걸쳐 답변을 조립합니다.

하지만 매 실행이 끝난 후, 엔지니어에게는 동일한 질문이 남습니다:

실제로 무엇이 확인되었는가, 모델이 단순히 가정(assume)한 것은 무엇인가, 그리고 머지(merge)하기 전에 이 결과의 어느 정도를 신뢰할 수 있는가?

그럴듯한 코드를 생성하는 것은 더 저렴해졌습니다. 하지만 그 기초를 검증하는 것은 반드시 그에 따라 저렴해지지 않았습니다. 따라서 토큰 가격, 생성 속도, 또는 에이전트 수(agent count)만으로 AI 도구를 비교하는 것은 중요한 엔지니어링 결정, 즉 요청에서 정당화된 머지(merge) 결정에 이르는 경로를 놓치는 것입니다.

이 글은 세 가지 질문을 던집니다:

모델 호출, 리뷰(review), 재작업(rework), 그리고 탈출된 오류(escaped-error) 위험을 모두 고려했을 때, AI가 의사결정의 총비용을 줄여주는가?
라우팅(routing), 검색(retrieval), 다중 모델 숙의(multi-model deliberation), 그리고 자동화된 체크(automated checks)는 그 비용의 어느 부분을 겨냥하고 있는가?
별도의 검증 레이어(verification layer)는 무엇을 생성해야 하며, 그 가치는 단순히 주장되는 것이 아니라 어떻게 허위임이 증명(falsified)될 수 있는가?

1. 검증 세금 (The verification tax)

생산성에 대한 증거는 엇갈립니다. METR는 2025년 초의 도구들을 사용하여, 숙련된 16명의 오픈 소스(open-source) 개발자가 자신들이 잘 아는 성숙한 저장소에서 246개의 실제 작업을 수행하는 무작위 대조 시험(randomized controlled trial)을 실시했습니다. AI를 사용했을 때, 작업 시간은 평균적으로 19% 더 오래 걸렸습니다 [1].

2026년 2월, METR는 최신 데이터가 아마도 더 큰 향상(uplift)을 보여줄 것이라고 보고했으나, 해당 신호가 신뢰할 수 없다고 명시적으로 언급했습니다. 숙련된 개발자의 경우 완료 시간 변화에 대한 원시 추정치는 -18% (신뢰 구간 [-38%, +9%])였으며, 신입 개발자의 경우 -4% (신뢰 구간 [-15%, +9%])였습니다. 여기서 음수는 속도 향상을 의미합니다. 두 구간 모두 효과가 0인 경우를 포함하고 있습니다 [2].

솔직한 결론은 "AI가 항상 개발자의 속도를 높인다"도, "AI가 항상 개발자의 속도를 늦춘다"도 아닙니다. 생산성은 도구의 성숙도(maturity), 저장소(repository) 숙련도, 작업의 형태, 컨텍스트(context) 습득, 그리고 결과물을 검증하는 비용에 따라 달라집니다.

2025년 DORA 보고서는 약 5,000명의 기술 전문가를 대상으로 한 또 다른 관찰적 관점을 제공합니다: 90%가 업무에 AI를 사용하고 있으며, 80% 이상이 생산성 향상을 체감하고 있지만, 30%는 AI가 생성한 코드에 대해 신뢰도가 거의 없거나 전혀 없습니다. AI 도입은 전달 처리량(delivery throughput) 및 제품 성능과는 양(+)의 상관관계가 있지만, 전달 안정성(delivery stability)과는 음(-)의 상관관계가 있습니다 [9]. 이는 인과적 추정치는 아닙니다. 이는 시스템 가설(systems hypothesis)과 일치합니다: 테스트 및 전달 제어(delivery controls)가 변경량에 맞춰 확장되지 않는다면, 더 빠른 로컬 생성(local generation)이 다운스트림 부하(downstream load)를 증가시킬 수 있습니다.

7개의 Google 연구를 별도로 종합한 결과, 외부 개발자의 39%가 생성형 AI(GenAI) 출력 품질을 아주 조금만 신뢰하거나 전혀 신뢰하지 않는 것으로 나타났습니다. 리뷰 및 테스트의 엄격함에 대한 인식, 그리고 AI가 사용되는 위치에 대한 개발자의 통제권은 신뢰도와 양(+)의 상관관계가 있었습니다 [7].

리뷰 자체는 단순히 결함을 찾는 작업만이 아닙니다. Bacchelli와 Bird가 200개의 Microsoft 리뷰 스레드와 570개의 댓글을 대상으로 수행한 연구에 따르면, 코드 개선이 댓글의 29%를 차지했고 결함은 14%를 차지했습니다. 저자들은 컨텍스트와 변경 사항을 이해하는 것이 리뷰의 핵심이며, 지식 전수(knowledge transfer)를 그 자체로 하나의 결과물로 기록한다고 명시했습니다 [3].

따라서 자동화는 단순히 발견된 버그뿐만 아니라, 변경 사항에 대한 올바른 멘탈 모델(mental model)을 구축하는 비용을 얼마나 줄여주는가로 판단해야 합니다.

예시적인 리뷰 부하 모델 (review-load model)

한 팀이 주당 20개의 PR을 처리하고 평균 리뷰 시간이 30분이라고 가정해 보겠습니다:

20 PR × 0.5 h = 주당 10 리뷰어 시간(reviewer-hours)

만약 AI가 처리량을 두 배로 늘리는 동안 PR당 리뷰 비용이 고정된다면:

40 PR × 0.5 h = 주당 20 리뷰어 시간(reviewer-hours)

만약 AI의 도움을 받은 PR의 범위가 넓어지고 리뷰 시간이 25% 증가한다면:

40 PR × 0.625 h = 주당 25 리뷰어 시간(reviewer-hours)

시나리오 (Scenario)	주당 PR (PR/wk)	PR당 리뷰 시간 (Review/PR)	리뷰 부하 (Review load)
AI 도입 전 (Pre-AI)	20	30분	10시간
...

이것은 시장 통계가 아니라 민감도 모델 (sensitivity model)입니다. 이는 작업이 제거되는 것이 아니라, 더 빠른 생성(generation)이 업무의 성격을 작성(writing)에서 검토(checking)로 이동시킬 수 있다는 메커니즘을 보여줍니다.

2. 엔지니어링 결정의 총 비용 (The total cost of an engineering decision)

토큰 비용이 총 비용은 아닙니다. 하나의 결정에 대한 예상 비용을 다음과 같이 정의합니다:

C_total = C_model + C_tools + R_hour × (T_review + T_rework) + P_escape × L_escape

C_model: 모델 호출 (model calls) 비용;
C_tools: CI, 샌드박스 (sandbox), 검색 (retrieval) 및 기타 컴퓨팅 (compute) 비용;
R_hour: 엔지니어링 1시간당 내부 비용;
T_review: 적용/리뷰/거절 결정까지 걸리는 시간;
T_rework: 머지(merge) 전 발견된 문제를 수정하는 데 걸리는 예상 시간;
P_escape: 중대한 오류가 리뷰를 통과할 확률;
L_escape: 그러한 오류 유출로 인한 예상 손실.

예시적인 기준선을 잡아보겠습니다: C_model = $5, 리뷰에 60분이 소요되며, R_hour = $80이라고 가정합니다. 도구, 재작업(rework) 및 리스크는 잠시 제외하겠습니다:

C_total = $5 + $80 = $85

순수 모델 비용 최적화의 한계 (The ceiling on pure model-bill optimization)

만약 모델 호출 비용이 다음과 같은 비율을 차지한다면:

f = C_model / C_total

업무량, 품질, 리뷰, 재작업 및 리스크를 고정한 상태에서 모델 비용만을 최적화한다면 — 모델 비용을 0으로 줄이더라도 — C_total은 최대 f만큼만 감소합니다.

참조 수치를 적용하면:

f = 5 / 85 = 5.9%

이것이 라우팅 (routing)의 전체 효과에 대한 한계치는 아닙니다. 성능이 낮은 저렴한 모델은 재시도(retries), T_rework, P_escape를 높일 수 있고, 좋은 라우터는 지연 시간 (latency)과 호출 실패를 줄일 수 있습니다. 이것은 회계적인 관찰입니다: 모델 비용이 총 비용에서 차지하는 비중이 작을 때, 그 항목만을 최적화하는 것으로는 리뷰에 묶인 병목 현상 (bottleneck)을 해결할 수 없습니다.

리뷰 시간을 60분에서 40분으로 줄이는 것은 다른 규모의 변화를 만들어냅니다:

C_total = $5 + $80 × (40/60) = $58.33
절감액 (Saving) = ($85 - $58.33) / $85 = 31.4%

변경 사항	모델 (Model)	검토 (Review)	`C_total`	절감액 (Saving)
기준점 (Baseline)	$5.00	$80.00	$85.00	—
...

인간의 감독이 거의 없는 자율적인 에이전트 루프 (autonomous agentic loops)에서는 f 값이 커질 수 있으며, 라우팅 (routing)이 주요한 경제적 레버 (economic lever)가 될 수 있습니다. 비용이 많이 드는 인간의 검토 (human review)로 제한되는 워크플로우에서는 f 값이 더 낮습니다. 핵심적인 질문은 어떤 항이 실제로 총 비용을 지배하느냐 하는 것입니다.

3. 서로 다른 시스템은 비용의 서로 다른 부분을 제어합니다

현대적인 AI 시스템은 종종 유사해 보입니다: 에이전트 (agents), 오케스트레이션 (orchestration), 검색 (retrieval), 판사 (judge), 그리고 합성 (synthesis) 등이 그것입니다. 형태가 비슷하다고 해서 동일한 역할을 수행한다는 의미는 아닙니다.

라우팅 (Routing): Kilo Gateway 및 RouteLLM

Kilo는 OpenAI 호환 엔드포인트, 다양한 모델에 대한 액세스, BYOK (Bring Your Own Key), 사용량 추적, 지출 제한 및 조직 제어 기능을 제공합니다 [11]. ByteByteGo는 계획 (planning), 코딩 (coding), 디버깅 (debugging)과 같이 알려진 모드에 따라 사용자가 선택한 티어 (tier)와 서버에서 업데이트되는 모델 맵 (model map)을 사용하여 라우팅을 설명합니다. 보고된 Kilo의 수치 — 평균 요청 비용이 약 1/3 낮고, 요청의 80~90%가 프런티어 모델 (frontier models)을 필요로 하지 않으며, 티어 간 격차가 10배 이상이고, 일상적인 트래픽의 잘못된 라우팅으로 인해 분기당 약 $87K의 초과 지출이 발생했다는 내용 — 는 벤더(vendor)가 보고한 것이며 독립적으로 검증되지 않았습니다 [8].

이상적인 모델은 잠재적인 규모를 보여줍니다. 만약 단계의 15%에 최상위 티어 (top-tier)가 필요하고 나머지 요청 비용이 최상위 티어의 10%라면:

relative_cost = 0.15 × 1 + 0.85 × 0.10 = 0.235
relative reduction = 1 - 0.235 = 76.5%

RouteLLM은 이러한 트레이드오프 (trade-off)에 대한 주요 연구 증거를 제공합니다: GPT-4/Mixtral-8×7B 쌍의 경우, GPT-4의 MT-Bench 점수의 95%를 유지하면서 3.66배의 비용 절감 비율을 보여주며, 이는 72.7%의 상대적 비용 절감 (1 - 1/3.66)과 동일합니다 [12]. 이 비용 모델은 짧은 단일 턴 프롬프트 (single-turn prompts)를 사용하며 벤치마크 점수를 품질로 사용합니다. 이는 코딩 에이전트 루프 (coding-agent loop)가 아니며, 리포지토리 변경 (repository change)이 안전하다는 증거도 아닙니다.

라우팅은 어떤 모델이 단계를 실행해야 하는지와 그 호출 비용이 얼마인지를 결정합니다. 라우팅 그 자체만으로는 엔지니어링 주장 뒤에 있는 증거가 충분하다는 것을 입증하지 못합니다.

에이전틱 RAG (Agentic RAG): 충분한 컨텍스트 (context)

Google은 전용 충분한 컨텍스트 에이전트 (Sufficient Context Agent)를 포함한 멀티 에이전트 RAG (multi-agent RAG)를 설명합니다. 이 에이전트는 쿼리 (query), 검색된 스니펫 (retrieved snippets), 그리고 초안 (draft)을 비교하여 누락된 정보를 명시하며, 추가적인 검색 단계 (retrieval pass)를 트리거할 수 있습니다. Google은 사실 관계 데이터셋 (factuality datasets)에서 표준 RAG보다 정확도가 최대 34% 더 높다고 보고했습니다 [4].

충분한 컨텍스트 (Sufficient Context) 연구는 더 광범위한 실패 모드 (failure mode)를 드러냅니다. 즉, 컨텍스트가 불충분할 때 모델은 답변을 거부하기보다 종종 잘못된 답변을 내놓는다는 것입니다. 가이드된 거부 (Guided abstention)는 Gemini, GPT, Gemma에서 답변된 사례들의 정확도를 2~10% 향상시켰습니다 [5].

이는 충분한 컨텍스트 루프 (sufficient-context loop)를 뒷받침하지만, 이것이 소프트웨어 개발에서의 T_rework (재작업 시간) 또는 P_escape (결함 유출 확률)의 측정된 감소를 의미하지는 않습니다. 코드베이스 (codebase)는 단순한 문서 코퍼스 (document corpus)가 아닙니다. 여기에는 런타임 동작 (runtime behavior), 호출자 (callers), 불변량 (invariants), 그리고 마이그레이션 (migrations)이 포함되어 있습니다.

멀티 모델 숙의 (Multi-model deliberation): 합의가 곧 증거는 아니다

OpenRouter Fusion은 1~8개의 모델로 구성된 병렬 패널을 실행합니다. 심판 (judge) 모델은 합의 (consensus), 모순 (contradictions), 부분적 커버리지 (partial coverage), 고유한 통찰 (unique insights), 그리고 사각지대 (blind spots)에 대한 구조화된 비교를 반환하며, 최종 모델이 답변을 작성합니다. 해당 문서는 파이프라인을 설명하지만, 독립적인 효과성 벤치마크 (effectiveness benchmark)를 제공하지는 않습니다 [10].

Google Research는 180개의 에이전트 구성 (agent configurations)을 비교하였으며, "에이전트가 많을수록 더 신뢰할 수 있다"는 주장에 대한 유용한 반례를 제시했습니다. 독립적인 토폴로지 (topology)는 오류를 최대 17.2배까지 증폭시킨 반면, 중앙 집중식 조정 (centralized coordination)은 증폭을 4.4배로 억제했습니다. 멀티 에이전트는 병렬화 가능한 Finance-Agent의 결과를 80.9% 개선했지만, 모든 멀티 에이전트 변형 모델은 순차적인 PlanCraft의 결과를 39~70% 저하시켰습니다.
저자들의 예측 모델 (predictive model)은 보지 못한 구성 (unseen configurations)의 87%에 대해 최적의 아키텍처를 선택했습니다 [6].

이 평가는 리포지토리 코드 리뷰 (repository code review)를 포함하지 않았으므로, 이 수치들을 특정 제품에 할당할 수는 없습니다. 엔지니어링 가설은 더 좁습니다. 즉, 가치는 에이전트의 수뿐만 아니라 토폴로지 (topology), 작업 분해 가능성 (task decomposability), 중앙 집중식 게이트 (centralized gate), 그리고 증거 전달 (evidence handoffs)의 품질에 달려 있다는 것입니다.

테스트 및 정적 분석 (Tests and static analysis)

SAST, DAST, CodeQL, Semgrep, 단위 테스트 (unit tests), 그리고 변이 테스트 (mutation tests)는 제어된 입력, 설정 및 환경 하에서 명시적으로 인코딩된 속성들에 대해 반복 가능한 검사를 제공합니다. 이들의 품질은 커버리지 (coverage), 오탐 (false positives), 미탐 (false negatives), 그리고 플래키니스 (flakiness, 테스트 불안정성)에 의해 제한됩니다.

이러한 도구들은 필수적이지만, 모델이 관련 파일을 전혀 열지 않았거나, 잘못된 가정 위에 결론을 내렸거나, 시스템 불변량 (system invariant) 대신 구현 세부 사항을 테스트했는지 여부를 항상 밝혀내지는 못합니다. 초록색 체크 표시(Green checks)가 의도의 완전한 증명은 아닙니다.

4. 비교 (Side by side)

접근 방식 (Approach)	주요 문제 (Primary problem)	결정 단위 (Unit of decision)	주요 출력 (Main output)	자체적으로 해결하지 못하는 것 (Does not solve by itself)
Kilo / 모델 라우팅 (model routing)	모델 접근, 비용, 정책	모델 요청 (Model request)	완성본 + 비용 데이터	엔지니어링 변경 사항에 대한 신뢰
...

이러한 시스템들은 반드시 직접적인 경쟁 관계는 아닙니다. 라우팅 (Routing)은 모델 호출 비용을 관리합니다. 에이전틱 RAG (Agentic RAG)는 컨텍스트 충분성을 테스트합니다. 멀티 모델 숙의 (Multi-model deliberation)는 불일치를 드러냅니다. 테스트는 공식화된 속성들을 검사합니다. 검증 아티팩트 (verification artifact)는 이러한 신호들을 연결하여 후보가 얼마나 뒷받침되는지에 대한 결정으로 이어져야 합니다.

5. 신뢰 부채와 숨겨진 검증 작업 (Trust debt and hidden checking work)

엔지니어링 답변이 일련의 실질적인 주장 (material claims)을 포함하고 있다고 가정해 봅시다:

C = {c1, c2, ..., cn}

각 주장에 대해, 검토자는 해당 주장이 증거에 의해 뒷받침되는지, 모순되는지, 아니면 여전히 가정인지 알아야 합니다. 대략적인 진단 지표는 다음과 같습니다:

evidence_coverage = supported_claims / total_material_claims

만약 답변에 20개의 실질적인 주장이 있고 12개에 대해 충분한 증거가 존재한다면:

evidence_coverage = 12 / 20 = 60%

남은 40%가 반드시 틀렸다는 의미는 아닙니다. 그 부분은 검토자가 여전히 조사해야 할 영역입니다. 만약 도구가 해당 영역을 노출하지 않는다면, 엔지니어는 먼저 그 영역을 발견해야 하고 그 후에야 검증할 수 있습니다. 이것이 바로 숨겨진 검증 작업 (hidden verification work)입니다.

검증 레이어 (verification layer)의 목표는 답변이 절대적으로 옳다고 선언하는 것이 아닙니다. 그것은 다음과 같습니다:

재료적 주장(material claims)을 검증 가능한 증거와 연결합니다.
검사되었거나 검사되지 않은 관련 대상(targets)을 드러냅니다.
가정(assumptions)과 근거가 뒷받침된 결론(supported conclusions)을 분리합니다.
비판(critique)과 기각된 가설(rejected hypotheses)을 보존합니다.
공개된 프로덕션(production) 및 PR 리스크를 표면화합니다.
불확실성을 숨기지 않으면서 수동 검색 영역을 좁힙니다.

검토(Review)는 여전히 남습니다. 다만 검색 영역이 더 작아져야 합니다.

6. 추가 검증이 스스로의 비용을 충당하는 경우

잠시 리스크를 배제하고 생각해보면, ΔC만큼의 비용이 드는 추가 점검은 최소한 다음과 같은 비용을 절감할 때 그 가치를 스스로 증명합니다:

T_break_even = ΔC / R_hour

R_hour = $80일 때:

실행당 추가 비용	필요한 검토 절감 시간
$2	1.5분
...

이제 예상 손실(expected loss)을 다시 적용해 보겠습니다. 예를 들어 L_escape = $10,000인 상황에서 P_escape를 0.1 퍼센트 포인트(예: 1.0%에서 0.9%로) 줄이면 다음과 같은 결과가 나옵니다:

(0.010 - 0.009) × $10,000 = 실행당 예상 절감액 $10