생성은 값싸졌지만 검증은 아니다 — AI 코딩의 새로운 병목

요즘 AI 코딩 워크플로우는 대개 이렇게 요약된다. "요구사항을 잘 기술(describe)하고, 모델이 생성한 결과를 다시 모델로 검증한다." 자연어로 스펙을 쓰면 코드가 나오고, 마음에 안 들면 다시 설명해서 고친다. 생성 비용이 거의 0에 수렴했으니 이 루프를 빠르게 돌리면 생산성이 폭발할 것 같다.

그런데 실제로 이 루프를 오래 돌려본 개발자들의 체감은 다르다. 코드를 쓰는 시간은 확실히 줄었는데, 그만큼 다른 데서 시간을 쓰고 있다. 그 "다른 데"가 바로 검증이다.

이 글의 주장은 하나다. "잘 describe하고 결과를 모델로 검증한다"는 워크플로우에서 가장 약한 고리는 생성이 아니라 검증이다. 생성은 값싸졌지만 검증은 값싸지지 않았다. 오히려 모델의 비결정성, 검증 비용의 재유입, spec drift(스펙과 산출물이 점점 어긋나는 현상)가 검증을 새로운 병목으로 밀어올린다. 그리고 이 병목을 다시 모델에게 맡기는 순간 — "생성한 모델이 스스로 검증하게 하자" — 우리는 순환 논증에 빠진다. 검증의 신뢰성을 검증할 독립적인 기준점이 사라지기 때문이다.

검증이 새로운 병목이 되는 과정

먼저 숫자로 확인해 보자. DORA(Google의 소프트웨어 딜리버리 연구 조직) 2025 보고서는 이것을 verification tax(검증세)라고 부른다. 개발자가 코드 작성 시간을 줄인 만큼, 그 시간을 AI 산출물을 검증하고 감독하는 데 재배분한다는 것이다. 즉 체감 속도 향상이 그대로 순이익이 되지 않는다 — 절약분의 상당 부분이 검증으로 다시 흘러 들어간다. Stack Overflow 2025 설문은 이 부담의 결을 보여준다. 개발자의 30%가 AI 코드를 거의 또는 전혀 신뢰하지 않고, 66%는 "거의 맞지만 완전히 틀린" 답을 최대 불만으로 꼽았으며, 45%는 AI 코드를 디버깅하는 데 오히려 시간이 더 걸린다고 답했다. "거의 맞지만 완전히 틀린" 출력이야말로 검증을 비싸게 만드는 핵심이다. 명백히 틀린 코드는 빨리 버리면 되지만, 그럴듯한 코드는 한 줄 한 줄 따져봐야 하기 때문이다.

여기에 모델의 비결정성이 겹친다. 같은 자연어 스펙을 여러 번 던지면 매번 조금씩 다른 코드가 나온다. 이 편차는 버그가 아니라 생성 모델의 본질적 성질이고, spec drift와 hallucination의 근원이다. 실제로 에이전트가 코드베이스에 이미 존재하는 클래스의 설명을 "새로 만들어야 할 스펙"으로 오인해, 재사용 대신 중복 코드를 생성하는 사례가 관측된다. 자연어는 이런 오인을 막을 만큼 정밀한 경계를 긋지 못한다.

다이어그램 설명. 루프의 무게중심이 어디에 실리는지를 보여준다. 요구사항 기술과 코드 생성 단계는 저렴해졌지만, 검증 단계에는 비결정성과 검증세가 동시에 유입되며 무게가 쏠린다. 그리고 이 병목을 해소하려고 검증마저 모델에게 넘기면, 점선 화살표처럼 다시 검증 단계로 되돌아오며 독립적 판단 기준이 사라진다. 검증하는 모델이 생성하는 모델과 같은 종류의 오류에 취약하다면, 우리는 틀린 답을 틀린 채점자에게 맡기는 셈이다.

스펙을 더 자세히 쓰면 되지 않느냐고 물을 수 있다. 그런데 그 방향에도 역설이 있다. Martin Fowler 사이트의 spec-driven development 도구 탐구에서, Kiro는 작은 버그 하나를 고치는 데 acceptance criteria(수용 기준)를 16개나 만들어 냈다. 검증해야 할 대상인 스펙 문서가 정작 원래 코드보다 리뷰하기 어려워진 것이다. 저자의 결론은 통렬하다 — 이럴 바엔 "마크다운 더미를 읽느니 코드를 직접 리뷰하는 게 낫다." 스펙을 부풀리는 것으로는 검증 비용을 줄일 수 없다. 검증 대상을 옮겼을 뿐이다.

완화책 — 검증 기준점을 자연어 밖으로

그렇다면 검증을 어떻게 다시 값싸게 만들까. 핵심은 검증의 기준점을 자연어와 모델 바깥, 즉 기계가 결정적으로 판정할 수 있는 곳으로 옮기는 것이다.

다이어그램 설명. 검증 기준이 사람의 눈에서 기계의 판정으로 단계적으로 옮겨가는 스택이다. "자연어 스펙"은 모호하고 비결정적이라 검증 기준점으로 삼기에 부적합하므로, 먼저 인간의 리뷰를 코드가 나온 뒤가 아니라 스펙을 쓰는 단계로 앞당긴다. 학술적 근거도 이 방향을 지지한다. SANER 2026에 실린 연구는, 인간이 정제한 스펙을 입력으로 주면 LLM이 생성한 코드의 오류가 최대 50%까지 줄어든다고 보고한다. 검증과 정제 단계에 사람이 여전히 필수라는 뜻이고, "모델이 스스로 검증한다"는 접근의 명백한 한계선이다. 그다음 "형식적 계약 / 타입 시그니처" 단계에서 검증 대상을 자연어에서 기계 판정 가능한 형태로 내린다 — 타입은 컴파일러가 결정적으로 판정하고, 계약(사전조건/사후조건)은 위반 시 즉시 드러난다. "자동화된 테스트" 단계는 실행 가능한 명세다 — 마크다운 수용 기준 16개보다, 통과/실패가 이진으로 갈리는 테스트 케이스 하나가 검증하기 쉽다. 마지막 두 단계는 검증량 자체를 줄인다 — 좁은 변경을 자주 검증하면 검증세의 단위가 작아지고, 결정성이 반드시 필요한 경계(API 계약, 데이터 스키마, 핵심 인터페이스)는 매번 재생성하지 말고 한 번 확정한 것을 고정해 비결정성 자체를 검증 대상에서 뺀다.

이 완화책들의 공통점은 하나다. 검증을 다시 모델에게 넘기지 않는다는 것이다. 대신 컴파일러, 테스트 러너, 인간 리뷰어처럼 생성 모델과 독립적인 판정자에게 기준점을 건넨다. 그래야 순환이 끊긴다.

정리 — 값싼 것은 생성이지 신뢰가 아니다

AI 코딩의 병목은 "얼마나 잘 describe하느냐"가 아니라 "어떻게 값싸게 검증하느냐"로 이동했다. 생성이 공짜에 가까워질수록 검증의 상대적 비중은 커진다. 그리고 검증을 다시 모델에게 위임하는 순간 우리는 스스로를 채점하는 학생을 만든다. 실질적인 지렛대는 검증 기준점을 자연어와 모델 바깥 — 타입, 계약, 테스트, 그리고 스펙 단계로 앞당긴 인간 리뷰 — 으로 옮기는 데 있다. 값싼 것은 생성이지 신뢰가 아니다.

---

참고한 공개 자료:

• Balancing AI tensions — verification tax, DORA (https://dora.dev/insights/balancing-ai-tensions/)
• Stack Overflow Developer Survey 2025: AI (https://survey.stackoverflow.co/2025/ai/)
• METR RCT — 검증·감독 부담과 기존 클래스 오인 사례, arXiv (https://arxiv.org/abs/2507.09089)
• Exploring spec-driven development tools — Martin Fowler 사이트 (https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html)
• 인간 정제 스펙이 LLM 코드 오류 최대 50% 감소 — SANER 2026, arXiv (https://arxiv.org/html/2601.03878v1)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.