AI 시대에 MVP를 먼저 만들어야 할까? 2억 1100만 줄의 코드가 보여준 재작업률 3.3% → 7.1%
아이디어를 AI에 던지면 열 번에 여덟 번은, 돌아오는 첫마디가 「우선 최소 기능 버전을 만들죠」다.
판단처럼 들리지만 이것은 기억이다. Agile Manifesto는 2001년, 『The Lean Startup』은 2011년의 것이고, 이 둘과 거기서 파생된 수십만 편의 블로그 글, 강의, 사후 회고가 전부 AI의 학습 데이터 안에 있다. AI가 반복을 권하는 것은 자기 장부를 계산해봤기 때문이 아니다.
계산한 것은 사람의 장부다. 그리고 이 두 장의 청구서는 구조가 정확히 반대를 향한다.
MVP가 성립하는 네 가지 전제, 오늘 남은 것은 셋
반복은 자연법칙이 아니다. 구체적인 제약 아래에서의 최적해다. 그 제약은 이렇게 생겼다.
- 코드를 쓰는 일은 느리고 비싸다. 기능 하나가 이해된 상태에서 도는 상태까지 인일 단위로 걸린다.
- 고치는 것이 쓰는 것보다 비싸다. 고치려면 먼저 읽어야 하고, 읽으려면 남의(혹은 석 달 전 자신의) 머릿속으로 다시 들어가야 한다.
- 요구사항은 진행하면서 정확해진다. 사용자는 실물을 봐야 자기가 뭘 원하는지 안다. 그래서 일찍 보여주는 데 이득이 있다.
- 결정적인 하나: 조악한 구현과 완전한 구현 사이에 큰 비용 차이가 있다.
마지막 항목이 MVP의 경제적 지반이다. 일단 localStorage에 넣어두고, 일단 권한은 안 만들고, 일단 설정 몇 개는 하드코딩하고 — 그렇게 아낀 몇 주는 진짜였고, 그걸 가설 검증에 쓰는 것도 진짜로 남는 장사였다.
넷 중 셋은 오늘도 성립한다. 네 번째가 사라졌다.
localStorage와 PostgreSQL, AI의 손에서는 몇 분 차이
V2EX에 이 사실을 가장 깔끔하게 짚은 글이 있다(t/1216691, 제목이 「AI 코딩 시대에 MVP 사고는 이미 무효가 되었나?」다). 글쓴이의 원문은 이렇다. Cursor에게 「localStorage로 데이터를 저장」이라고 설명하는 것과 「PostgreSQL에 커넥션 풀을 붙여서」라고 설명하는 것의 생성 시간 차이는 몇 분에 불과하다.
비용이 같은데 왜 간이 버전을 만드나?
이 한 문장이 지반의 절반을 뽑아버린다. 아끼는 것은 더 이상 몇 주가 아니라 몇 분이고, 그 대가로 짊어지는 것들 — 교체될 운명의 저장 계층, 그것을 전제로 쓰인 호출들, 다시 해야 할 마이그레이션 — 은 하나도 줄지 않았다.
조악함은 더 이상 싸지 않다. 그냥 불완전할 뿐이다.
AI의 청구서: 주체는 작업이 아니라 맥락
지반의 나머지 절반은 비용 구조에서 무너진다. 이 층이 더 잘 안 보인다.
agentic 작업을 한 번 돌릴 때, 입력 토큰의 대부분은 결코 당신의 작업 설명이 아니다. 시스템 프롬프트이고, 저장소 지도이고, 대화 기록이고, AI가 읽은 파일들이다. 작업 설명이 차지하는 비율은 무시해도 될 만큼 작다.
여기서 따라 나오는 것들은 모두 실측되어 있다.
- 재시도할 때마다 맥락 전체를 다시 보낸다. 두 번의 재시도로 한 세션 비용이 세 배가 될 수 있다.
- 맥락 오버헤드를 감안하면 실제 비용은 단순 추정의 3~5배다. PR 하나당 0.27~3.25달러, 복잡한 저장소에서는 단일 작업이 20달러를 넘는 것도 드물지 않다.
- arXiv 논문 『Cheap Code, Costly Judgment』(2607.01087)의 실측에 따르면 agentic 작업이 소비하는 토큰은 일반 코드 대화의 1000배이고, 같은 작업을 반복 실행했을 때 토큰 소비의 편차는 최대 30배에 달한다.
이제 사람의 반복과 AI의 반복을 나란히 놓고 계산해보자.
사람이 한 가지 일을 3기로 나누면 각 기의 비용은 비슷하다. 사람은 지난 기에 뭘 했는지 기억하기 때문이다. 맥락이 머릿속에 있고, 그걸 불러오는 데는 돈이 안 든다.
AI는 기억하지 못한다. 매 기마다 맥락을 다시 산다.
| 똑같이 3기로 나눠도 | 사람 | AI |
|---|---|---|
| 각 기의 주요 비용 | 작업 그 자체 | 맥락 재구축 |
| 지난 기의 기억 | 머릿속에, 호출 무료 | 존재하지 않음, 다시 적재해야 함 |
| 3기 총비용 | ≈ 세 몫의 품삯 | ≈ 세 몫의 품삯 + 두 번의 재구축비 |
| 한 번 더 쪼갤 때의 한계비용 | 한 번의 소통 | 맥락 한 벌의 완전한 재구매 |
| 반복으로 사는 것 | 길을 잘못 들지 않을 기회 | 같은 기회, 다만 마찰비 별도 |
반복은 사람에게는 보험이고, AI에게는 마찰비다.
GitClear가 재작업을 실측했다: 3.3% → 7.1%
여기까지는 추론이다. 아래부터는 실측이다.
GitClear는 2억 1100만 줄의 변경 코드를 분석해 churn이라는 지표를 추적했다. 병합된 뒤 며칠 안에 크게 다시 쓰이거나 삭제되는 코드의 비율이다. 이것이 재는 것은 정확히 「한 번에 제대로 하지 못했다」는 사실이다.
| 연도 | churn |
|---|---|
| 2023년 이전(기준) | 3.3% |
| 2024년 | 5.7% |
| 2025년 | 7.1% |
2년 만에 두 배 이상. 같은 연구의 다른 지표들도 같은 방향을 가리킨다.
- 커밋 내 복사·붙여넣기 +41%
- 코드 블록 중복 +81%
- 오류를 가리는 작성 방식 +47%
- 파일 간 함수 호출(재사용의 대리 지표) −35%
- 리팩터링에 의한 줄 이동 −70%
GitClear는 AI가 증폭시킨 재작업을 세 종류로 나눈다. 어느 것이나 「일단 반제품을 내놓는」 행위의 직접적 결과다.
- 위치가 틀렸다 — 논리도 문법도 맞지만 잘못된 아키텍처 위치에 놓여, 나중에 사람이 옮긴다
- 두 번 만들었다 — 이미 있는 기능을 재사용하지 않고 다시 구현했다
- 며칠 뒤 다시 씀 — 병합한 뒤 엣지 케이스나 규약 충돌 때문에 크게 고쳐진다
같은 연구에서 AI가 작성한 PR의 평균 문제 수는 10.83건, 사람이 쓴 것은 6.45건. 1.7배다.
개발자 본인들의 체감도 이 숫자와 맞는다. Stack Overflow 2026 개발자 조사에서:
- 84% 가 AI 도구를 쓰고 있다
- 45% 가 AI 생성 코드를 디버깅하는 게 직접 쓰는 것보다 시간이 더 걸린다고 답했다
- 66% 가 가장 큰 불만이 「거의 맞지만 완전히 맞지는 않은」 결과물이라고 답했다
- 그리고 AI 출력에 대한 신뢰도는 3%
다른 조사에서는 AI 생성 코드 변경의 43% 가 운영 환경에서의 디버깅을 필요로 한다고 나왔다.
「거의 맞다」가 핵심이다. 문제가 당신이 검수하는 그 순간에 드러나지 않고 병합된 뒤에 드러난다는 뜻이다. 즉 다음 기의 머리 위로 떨어진다. 아꼈다고 생각한 그 한 바퀴는 뒤에서 청구된다.
「한 번에 제대로」는 「한 번에 전부」가 아니다: 납품 단위와 실행 단위
여기서 구호로 미끄러지기 가장 쉽다. 반복하지 말고 한 번에 다 하라고. 그건 틀렸고, 게다가 위험하게 틀렸다.
나눠야 할 단위가 둘이다.
- 실행 단위: 한 번에 한 곳만 고치고, 고쳤으면 검증한다. 이 조항은 오늘도 성립하며 오히려 더 중요해졌다 — AI가 한 번에 열 개 파일을 건드리면 사람의 리뷰가 따라가지 못한다.
- 납품 단위: 이번 바퀴에 넘기는 것이 완성품인가.
「한 번에 제대로」가 말하는 것은 후자다. 제약하는 것은 완성도이지 기능의 개수가 아니다.
범위는 좁아도 된다. 페이지 하나, 엔드포인트 하나까지 좁아도 된다. 하지만 이번 바퀴에 하기로 정한 부분은 완전해야 한다. 진짜 데이터 구조여야 하고 자리표시자가 아니어야 한다. 로딩·빈 상태·오류·성공 네 가지 상태가 다 있어야 하고 이상 경로만 있으면 안 된다. 실제로 돌아가서 사람이 쓸 수 있어야 하고 스크린샷이 아니어야 한다.
MVP라는 단어의 가장 큰 문제는 「범위가 좁다」와 「조악하게 만든다」를 묶어서 팔았다는 점이다. 예전엔 정말로 묶여 있었다 — 돈을 아끼려면 둘 다 아낄 수밖에 없었다. 지금은 분리된다. 범위는 여전히 좁아야 하지만, 조악함은 더 이상 절약이 아니다.
「MVP는 가설 검증이고 AI와 무관하다」 — 네 가지 반박 중 둘은 선다
그 V2EX 글 아래 달린 반대 의견이 본문보다 값지다. 하나씩 보자.
1. 「MVP의 핵심은 가설 검증이다. 코드와 무관하고, AI든 아니든과도 무관하다.」
선다. 그리고 이것이 문제의 소재를 그대로 가리킨다. MVP라는 단어는 줄곧 두 가지를 함께 실어 왔다 — 가설을 검증하는 것과, 불완전한 구현을 내놓는 것. 예전엔 분리할 수 없었다. 가설을 검증하는 유일하게 싼 방법이 조악한 걸 만드는 것뿐이었으니까. 지금은 분리됐다. 가설은 물론 검증하면 된다. 다만 완전한 것으로 검증할 수 있다.
2. 「잠재 사용자의 모든 요구를 한 번에 파악하는 건 영영 불가능하다.」
선다. 그리고 「한 번에 제대로」와 충돌하지 않는다. 모든 기능을 한 번에 만들라고 한 사람은 없다. 이번에 만들기로 한 그 부분을 반쯤 남기지 말라는 것이다.
3. 「논리가 복잡한 프로젝트, 특히 복잡한 업무 루프와 상태 기계를 가진 시스템은 한 방에 하면 결과가 엉망이다.」
진짜 문제지만 실행 단위의 문제다. 복잡한 상태 기계는 당연히 한 걸음씩, 매 걸음 검증하며 만든다. 그것이 「다시 쓸 걸 알면서 일단 한 버전을 내놓는」 근거가 되지는 않는다.
4. 「AI가 있으면 반복이 엄청 빠르고 비용도 극히 낮다.」
이건 서지 않는다. 위의 두 절이 그 반례다. 빨라진 것은 생성이지 수렴이 아니다. churn이 3.3%에서 7.1%로 오른 것이 재고 있는 게 정확히 그 차이다.
「반복 개발 금지」를 전역 규칙에 써 넣은 뒤
내 전역 규칙에는 한 줄이 박혀 있다. 반복 개발 금지, 납품은 곧 완성품, MVP와 단계적 납품 불허.
구체적인 동작으로 내려오면 이렇다.
- 첫 바퀴부터 진짜 데이터 구조와 진짜 내용을 요구한다. Lorem ipsum 금지, 가짜 데이터 금지
- 네 가지 상태를 한 번에 갖춘다. 로딩·빈 상태·오류·성공
- 납품 전에 반드시 직접 돌려본다. 브라우저에서 열고, 명령줄에서 실행하고, 엔드포인트를 curl로 때려본다
대가는 실재한다. 첫 설명이 훨씬 길어진다. 착수 전에 경계·상태·데이터 구조를 다 생각해둬야 한다. 이 작업은 AI가 가져가지 않았고, 다만 「세 번째 바퀴 재작업에서 어쩔 수 없이 생각하게 되는」 자리에서 「첫 바퀴 시작 전에 스스로 생각해두는」 자리로 옮겨갔을 뿐이다.
수익도 직접적이다. 같은 일을 두 번, 세 번 다시 설명하지 않아도 된다. 그리고 다시 설명하는 것이야말로 앞의 청구서에서 가장 비싼 항목이다.
범위를 얼마나 좁게 자를지, AI는 도와주지 못한다
이 질문에는 아직 답이 없다.
「한 번에 제대로」의 전제는 범위를 제대로 잘랐다는 것이다. 너무 넓게 자르면 「한 번」이 「아주 긴 한 번」이 되고, 너무 좁게 자르면 만든 걸로 아무 가설도 검증할 수 없다. 이 선을 어디에 그을지는 사용자와 상황에 대한 판단에 달렸다 — 그 논문의 제목이 이미 할 말을 다 했다. 코드는 싸졌고, 판단은 싸지지 않았다.
토론