AI를 켰더니 19% 느려졌다 — 검증세라는 숨은 비용

AI(인공지능)를 개발 작업에 들이면 당연히 빨라질 줄 알았다. 그런데 정밀하게 측정한 한 실험은 정반대 결과를 내놨다.

METR(Model Evaluation and Threat Research, AI 능력을 측정하는 비영리 연구 조직)이 2025년 7월 발표한 무작위 대조 실험에서, 평균 5년 경력의 숙련 오픈소스 개발자 16명이 자기가 훤히 아는 성숙한 저장소에서 246개 작업을 수행했다. AI 도구를 쓰게 했더니 작업 시간이 오히려 19% 더 걸렸다. 더 흥미로운 건 인식과 현실의 어긋남이다. 시작 전 개발자들은 AI 덕에 24% 빨라질 거라 예측했고, 실험이 끝난 뒤에도 자신이 20% 빨라졌다고 믿었다. 실제로는 느려졌는데도 그랬다.

왜 이런 일이 벌어졌을까. 코드를 생성하는 시간은 분명히 줄었다. 하지만 줄지 않은 비용이 하나 있다. 바로 "그 코드가 진짜 맞는지 확인하고 확신하는 시간"이다.

도입 전의 기대와 도입 후의 현실

AI를 들이기 전에는 흔히 이렇게 상상한다. "버튼 한 번 딸깍이면 끝난다." 생성이 공짜에 가까워졌으니 일도 그만큼 빨라질 거라는 직관이다. 그런데 막상 도입하고 나면 엄청난 시간이 드는 일이 따로 있다. AI가 내놓은 결과가 의도대로인지, 빠뜨린 예외는 없는지, 정책이나 보안을 어기지 않는지를 사람이 읽고 검증하는 일이다.

이 숨은 비용을 영어권 개발자 커뮤니티는 여러 이름으로 부른다. 다만 이 이름들은 같은 말의 동의어가 아니라, "생성-검증 비대칭"이라는 한 뿌리에서 갈라져 나온 서로 다른 국면이다. "verification tax(검증세)"는 AI 결과물이 맞는지 사람이 직접 읽고 판단하는 데 드는 반복 노동을 가리킨다. CI나 정적분석 같은 도구를 돌리는 머신 비용이 아니라, 개발자의 주의력과 시간을 갉아먹는 인지 부담이다. 테스트·린트·정적분석은 오히려 이 세금을 자동으로 덜어주는 수단이지만, 그것들이 다 통과해도 "이게 정말 풀려던 문제를 푸는가"라는 마지막 판단만은 사람 손에 남는다 — 검증세는 바로 그 남는 몫이다. "verification debt(검증 부채)"는 그 판단을 건너뛰고 병합한 코드가 확인되지 않은 채 쌓이는 것이다. "comprehension debt(이해 부채)"는 결이 한 겹 더 깊다. 검증은 통과했어도 왜 그렇게 동작하는지는 아무도 모르는 코드가 누적되는 것, 즉 시스템에 쌓인 코드 중 사람이 실제로 이해하는 비율이 줄어드는 현상이다. 세 국면은 인과로 엮인다. 이해하지 못하면 제대로 판단할 수 없고, 미검증 병합은 다시 이해 부채를 키운다. 공통된 뿌리는 하나다. 생성은 싸졌는데, 사람이 읽고 이해하고 확신하는 일은 여전히 비싸다.

생성은 싸졌고 검증은 그대로다

OpenAI 연구자 Jason Wei는 이 비대칭을 "검증의 비대칭(asymmetry of verification)"이라 정리했다. 어떤 문제는 직접 푸는 것보다 정답이 맞는지 확인하는 게 훨씬 쉽다. 스도쿠가 대표적이다. 빈칸을 다 채우긴 어렵지만, 누군가 채워 온 답이 규칙에 맞는지는 금방 검사한다. 최근 AI가 빠르게 강해진 것도 이렇게 "확인이 값싼" 영역을 발판으로 삼았기 때문이다.

그런데 실무 코드에서는 이 비대칭이 거꾸로 작동할 때가 많다. AI는 그럴듯한 코드를 1초에 쏟아내지만, 그게 의도대로 동작하는지를 확인하는 일은 사람의 주의력에 묶여 있다. 코드가 컴파일되고 테스트를 통과하고 린트(코드 스타일·오류 자동 검사 도구)를 만족해도, "이게 정말 풀려던 문제를 푸는가"는 사람이 직접 읽어야 안다. 생성이 빨라진 만큼 검증할 양은 폭증하는데, 사람이 읽는 속도는 그대로다.

다이어그램 설명. 이 그림은 AI를 들인 작업이 어디서 막히는지 보여준다. "작업 요청"에서 출발해 "AI가 코드·문서 생성" 단계는 초 단위로 끝나지만, 이어지는 "사람이 맞는지 검증" 단계는 분 단위로 늘어진다. "믿을 수 있는가?" 판단에서 확신이 서면 "병합·사용"으로 빠지지만, 의심스러우면 "다시 읽고 재작업"을 거쳐 다시 검증 단계로 돌아온다. 핵심은 반복 고리가 만드는 단계가 아니라 검증 단계에 걸려 있다는 점이다. 생성이 아무리 빨라져도 이 고리가 길면 전체 시간은 줄지 않는다.

왜 검증은 사람에게 남는가

Andrej Karpathy는 이 현상을 한 문장으로 정리했다. "전통적 컴퓨터는 우리가 코드로 명세할 수 있는 것을 자동화하고, LLM(Large Language Model, 사람 언어를 생성하는 대규모 언어 모델)은 우리가 검증할 수 있는 것을 자동화한다." 뒤집어 말하면, 검증할 수 없는 일은 자동화의 사정권 밖에 그대로 남는다는 뜻이다.

그가 덧붙인 말이 검증세의 본질을 정확히 찌른다. "사고는 외주 줄 수 있어도 이해는 외주 줄 수 없다. 무엇을 만들 가치가 있는지, 어떤 결과가 의심스러운지, 어떤 절충이 받아들일 만한지는 여전히 사람이 알아야 한다." 만드는 일은 AI에 넘겨도, 그 결과를 이해하고 판단하는 일은 끝까지 사람 몫으로 남는다.

다이어그램 설명. 이 그림은 하나의 작업에서 무엇을 AI에 맡길 수 있고 무엇이 사람에게 남는지 가른다. "하나의 작업"은 "생성과 실행 — AI에 맡길 수 있다"와 "이해와 판단 — 사람에게 남는다"로 갈라진다. 맡길 수 있는 쪽은 "빠르게 쏟아지는 결과물"로 이어지고, 사람에게 남는 쪽은 "무엇이 의심스러운지 가려내는 일"로 이어진다. 두 갈래는 따로 노는 게 아니다. 결과물이 많이 쏟아질수록 가려낼 양도 같이 불어나기 때문에, 한쪽이 커지면 다른 쪽도 커지는 관계다. 그래서 사람에게 남는 몫을 줄이려면 애초에 검증하기 쉬운 형태로 일을 쪼개는 수밖에 없다.

개인 작업 흐름에 주는 함의

개인 AX(AI Transformation, 일하는 방식에 AI를 들이는 전환) 관점에서 검증세는 도입 계산을 통째로 바꾼다. 생성 속도만 보고 "이제 몇 배 빨라진다"고 기대하면, 검증이라는 고정비를 통째로 빠뜨린 셈이다. AI가 결과물을 많이 쏟아낼수록 사람이 읽고 판단할 양도 같이 늘어난다. 빨라지는 건 만드는 단계뿐이고, 병목은 조용히 검토 단계로 옮겨 간다. METR 실험의 숙련 개발자들이 빨라졌다고 느끼면서 실제로는 느려진 것도 이 옮겨 간 병목을 체감하지 못했기 때문이다.

그래서 작업 흐름을 짤 때 던질 질문이 바뀐다. "AI가 이걸 만들 수 있는가"가 아니라 "내가 이 결과를 빠르고 확실하게 검증할 수 있는가"다. 검증이 쉬운 일일수록 도입 이득이 크다. 테스트로 정답이 명확하게 갈리는 일, 작은 단위로 쪼개 한 조각씩 확인할 수 있는 일이 그렇다. 반대로 검증이 어려운 일은 생성을 아무리 빨리 해도 사람의 확인 비용이 그대로 남아 기대만큼 빨라지지 않는다. 미묘한 판단이 필요한 일, 큰 맥락을 통째로 이해해야 하는 일이 여기에 든다.

결국 AI 시대에 사람에게 남는 핵심 역량은 "빨리 만드는 힘"이 아니라 "쏟아지는 결과물 중 무엇이 틀렸는지 알아보는 힘"이다. 검증세는 없앨 수 없는 세금이다. 다만 검증이 쉬운 쪽으로 일을 설계하면 그 세금을 줄일 수는 있다. 생성이 공짜가 된 시대의 진짜 경쟁력은 거기서 갈린다.

---

참고한 공개 자료:

• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• arXiv 2507.09089 (위 METR 연구 논문) — https://arxiv.org/abs/2507.09089
• Andrej Karpathy, "2025 LLM Year in Review" — https://karpathy.bearblog.dev/year-in-review-2025/
• AI Builder Club, "Agentic Engineering: Karpathy's New Framework" — https://www.aibuilderclub.com/blog/karpathy-agentic-engineering
• Jason Wei, "Asymmetry of verification and verifier's law" — https://www.jasonwei.net/blog/asymmetry-of-verification-and-verifiers-law
• The New Stack, "There's a hidden tax on every AI-generated merge request" — https://thenewstack.io/hidden-tax-ai-code/
• Addy Osmani, "Comprehension Debt: the hidden cost of AI generated code" — https://addyosmani.com/blog/comprehension-debt/
• LeadDev, "Shipping faster, thinking less? The AI code verification trap" — https://leaddev.com/ai/shipping-faster-thinking-less-the-ai-code-verification-trap

---

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