AI가 코드를 공짜로 써주는 시대, '이제 미리 다 지어도 되지 않나?'라는 물음에 켄트 벡이 답했다 — YAGNI는 애초에 타이핑 절약이 아니었다. 그것은 옵셔널리티와 NPV, 두 장의 청구서였다. 1996년 크라이슬러 C3 프로젝트에서 태어난 슬로건이 왜 2026년 최대 화제가 되었는지, 금융의 실물옵션 이론부터 마틴 파울러의 비용 해부, 실전 사례까지 쉽고 깊게 풀었다.
1996년 미국 디트로이트. 크라이슬러 사옥 한켠에서 회사의 급여 시스템을 새로 만드는 프로젝트가 돌아가고 있었다. 이름은 C3(Chrysler Comprehensive Compensation). 훗날 소프트웨어 역사에 남을 이유는, 이 프로젝트가 익스트림 프로그래밍(XP) 이 태어난 산실이었기 때문이다. 켄트 벡(Kent Beck), 워드 커닝햄, 론 제프리스 — 이름만 들어도 아는 사람들이 여기 모여 있었다.
어느 날, 팀원 쳇 헨드릭슨(Chet Hendrickson)이 벡에게 이렇게 말한다.
"지금은 이 단순한 걸로 되겠지만, 3주 뒤엔 이걸론 부족할 거예요. 어차피 그 복잡한 게 필요할 테니, 지금 미리 만들어 두고 싶어요."
합리적으로 들린다. 미래를 내다보고 미리 준비하는 것 — 그게 좋은 엔지니어링 아닌가? 그런데 벡의 대답은 한 문장이었다.
"넌 그거 필요 없어(You aren't going to need it)."
헨드릭슨이 또 미래의 기능을 예로 들면, 벡은 또 같은 말을 반복했다. "넌 그거 필요 없어." 결국 헨드릭슨은 그 복잡한 구조를 만들지 않기로 했고 — 이 실랑이에서 YAGNI(You Aren't Gonna Need It) 라는 약어가 태어났다.
그로부터 30년이 흐른 2026년, 이 낡은 개발자 슬로건이 뜬금없이 개발자 커뮤니티 최대 화제로 다시 떠올랐다. 이유는 하나다. AI가 코드를 공짜로, 순식간에 써주는 시대가 왔기 때문이다. 사람들은 이렇게 말하기 시작했다. "코드 짜는 게 이제 공짜인데, YAGNI 같은 절약 원칙은 이제 필요 없는 거 아냐?"
여기에 켄트 벡 본인이 직접 답을 내놓았다. 뉴스레터 글의 제목은 이랬다 — 「YAGNI는 애초에 그 비용에 관한 게 아니었다(The Cost YAGNI Was Never About)」. 이 글이 이번 특집의 출발점이다. 결론부터 말하면, 벡의 주장은 이렇다:
YAGNI는 한 번도 '절약'이었던 적이 없다. 그것은 프로그래머의 슬로건을 뒤집어쓴 두 개의 가격 이론(price theory)이었다.
이게 무슨 말인지, 왜 이게 AI 시대에 더 중요해졌는지 — 지금부터 아주 천천히, 쉽게 풀어보자.
대부분의 개발자에게 YAGNI는 이런 뜻으로 통했다.
즉, 핵심은 '노동 절약' 이라는 것이다. 코드를 짜는 건 힘들고 시간이 드는 일이니까, 안 써도 될 코드는 안 쓰는 게 이득이라는 논리. 언뜻 맞는 말 같다.
그런데 벡은 이 통념을 정면으로 부순다.
"YAGNI는 코드를 생산하는 비용에 관한 게 아니다. 그 기능이 실제로 필요해지기 전에 미리 지어 두는 '투기적 구조(speculative structure)'의 비용에 관한 것이다."
이 구분이 왜 중요한가? AI 때문이다.
만약 YAGNI가 정말 "타이핑 아끼기"였다면, AI가 타이핑을 공짜로 만들어 버린 지금 YAGNI는 은퇴해야 맞다. 코드 생산 비용이 0에 수렴했으니까. 실제로 많은 사람이 그렇게 주장했다. "AI한테 시키면 5초면 프레임워크 하나 뚝딱인데, 미리 좀 지어두면 어때?"
벡의 반박은 서늘하다. YAGNI가 절약에 관한 것이었다면 값싼 코드 생성이 YAGNI를 은퇴시켰을 것이다. 그런데 YAGNI는 절약에 관한 게 아니었으므로, 은퇴하지 않는다. 오히려 AI 시대에 더 날카로워진다.
그 "그대로 남는 비용"이 정확히 무엇인지가 이 글의 핵심이다. 벡은 그것을 두 장의 청구서(two bills) 라고 불렀다. 하지만 그 청구서를 이해하려면, 먼저 YAGNI가 어디서 왔는지 계보를 한 바퀴 돌아야 한다.
YAGNI는 하늘에서 떨어진 게 아니다. 놀랍게도 그 뿌리는 1970년대 금융 이론까지 거슬러 올라간다. 아래 타임라인에서 각 마디를 눌러 펼쳐 보자. 금융의 옵션 이론이 어떻게 소프트웨어 설계 원칙으로 흘러들어왔는지 보인다.
핵심만 요약하면 이렇다. YAGNI는 1990년대 소프트웨어 업계를 지배하던 '거대한 사전 설계(Big Up-Front Design)' 문화에 대한 반작용이었다. 당시엔 코드를 짜기 전에 모든 요구사항을 분석하고, 미래에 필요할 법한 모든 확장 포인트를 설계도에 그려 넣는 게 프로페셔널의 미덕이었다. XP는 그 반대편에 섰다. 론 제프리스가 남긴 정식 정의는 지금도 표준으로 인용된다.
"실제로 필요할 때 구현하라. 필요할 것 같다는 이유만으로는 절대 만들지 마라." — Ron Jeffries, 『Extreme Programming Installed』(2001)
그런데 "필요할 것 같아서 미리 만들면" 정확히 무엇이 나빠지는가? 이 질문에 가장 체계적으로 답한 사람이 마틴 파울러다.
2015년, 마틴 파울러는 자신의 블로그에 YAGNI를 해부하는 글을 썼다. 그는 미래를 예상해 미리 만드는 기능 — 그가 '추정 기능(presumptive feature)' 이라 부른 것 — 이 어떻게 비용을 만드는지 네 가지로 쪼갰다.
파울러는 재밌는 비유를 든다. 곤도르의 항구도시 미나스 티리스에 있는 해상보험 스타트업을 상상해 보자(『반지의 제왕』 세계관이다). 이 회사의 가격 책정 팀은 지금 '폭풍 위험' 보험료 계산 기능을 만들고 있다. 그런데 누군가 말한다. "6개월 뒤엔 '해적 위험' 보험도 필요할 텐데, 지금 같이 만들어 둘까요?"
이때 미리 만들면 어떤 비용이 발생하나?
| 비용 종류 | 무엇인가 | 미나스 티리스 예시 |
|---|---|---|
| ① 짓는 비용 (Build) | 결국 안 쓸 기능을 분석·코딩·테스트하는 데 든 노동 | 해적 보험 로직을 만드는 데 든 시간 |
| ② 지연 비용 (Delay) | 그거 만드느라 지금 당장 돈이 되는 폭풍 보험 기능이 늦어짐 | 폭풍 보험 출시가 2개월 밀려 매출이 밀림 |
| ③ 보유 비용 (Carry) | 안 쓰는 기능이 코드베이스를 복잡하게 만들어 다른 모든 작업을 느리게 함 | 폭풍 보험 개발에 2주가 더 붙음 |
| ④ 수리 비용 (Repair) | 정보가 없을 때 만들었으니 '맞는 기능을 틀리게' 만들어 나중에 고쳐야 함 | 실제 요구사항이 오면 처음부터 뜯어고침 |
그리고 결정적인 반전. 6개월 뒤, 곤도르 해군이 해적을 소탕해 버린다. 해적 위험 보험은 영영 필요 없어졌다. 미리 만든 코드는 통째로 매몰비용이 됐다.
이게 극단적 우화 같은가? 파울러는 마이크로소프트의 실험 연구자 로니 코하비(Ronny Kohavi)의 데이터를 인용한다. 아무리 신중하게 분석해서 기능을 기획해도, 실제로 의도한 지표를 개선한 기능은 약 3분의 1에 불과했다. 나머지 3분의 2는 효과가 없거나 오히려 해로웠다. 우리는 미래를 생각보다 훨씬 못 맞힌다.
파울러는 추정 기능을 세 부류로 나눈다. 각각 다른 비용 조합을 문다.
여기서 파울러가 남긴 가장 중요한 단서 하나를 기억해두자. 이 글 후반에서 다시 만난다.
"YAGNI는 추정 기능을 지원하기 위해 넣은 기능에만 적용된다. 소프트웨어를 수정하기 쉽게 만드는 노력에는 적용되지 않는다."
즉, 리팩터링·자동화 테스트·깔끔한 구조를 만드는 건 YAGNI 위반이 아니다. 오히려 그게 있어야 "나중에 필요할 때 짓기"가 가능해진다. 이 얘긴 8장에서 이어가자.
자, 여기까지가 2015년까지의 이야기다. 파울러의 네 비용 중 ①번 '짓는 비용'이 바로 타이핑 비용이다. 그리고 2026년, AI가 이 ①번을 0으로 만들어 버렸다. 그렇다면 YAGNI는 이제 힘을 잃었을까? 켄트 벡은 "아니다"라고 답하며, 파울러의 네 비용 중 AI가 절대 건드리지 못하는 두 개를 꺼내 든다.
벡의 통찰은 이렇게 요약된다. 미리 구조를 지을 때 당신에게 날아오는 청구서는 두 장이다. 그리고 어느 청구서에도 '타이핑 비용'이라는 항목은 없다.
먼저 벡의 문장 그대로.
"구조를 기능보다 먼저 지을 때, 당신은 추측에 커밋(commit)하는 것이다. 당신이 대비한 그 기능은, 보통 실제로 나타나는 기능과 다르다."
핵심 단어는 커밋(commit) 이다. 미리 짓는다는 건, 아직 정보가 없는 상태에서 하나의 답에 손을 묶어버리는 행위다. 그런데 여기 반직관적인 통찰이 있다.
"정확히 맞혀도, 안 짓느니만 못하다. 가치는 애초에 그 구조에 있던 게 아니었다."
이게 무슨 소리인가? 미래를 완벽히 예측해서 딱 맞는 구조를 지었는데도 손해라고? 그렇다. 여기서 실물옵션(Real Options) 개념이 등장한다(자세한 건 5장에서). 핵심은 이 한 문장이다.
"기다림은 게으름이 아니다. 기다림은 자산을 쥐고 있는 것이다(Waiting is holding an asset)."
기다린다는 건, "지금 결정하지 않을 권리", 즉 옵션(option) 을 손에 쥐고 있는 상태다. 정보가 더 쌓인 뒤에 딱 맞는 걸 만들 수 있는 유연성 — 그 자체가 값어치를 지닌 자산이다. 미리 지어버리면 이 옵션을 행사해서 태워 없애는 것이다. 정보가 도착하기도 전에.
그래서 예측이 빗나가면(대부분 그렇다) 이미 지은 구조를 뜯어고치고, 안 맞는 부분을 철거하는 이중 비용이 든다. 설령 예측이 맞아도, 애초에 쥐고 있던 옵션의 가치를 날려버렸으니 여전히 손해다.
두 번째 청구서는 완전히 독립적인 논리다. 벡의 문장.
"3개월 뒤에 필요할 기능을 위해 지금 짓는 구조는, 비용은 앞으로 당겨지고 매출은 뒤로 밀리는 것이다."
돈에는 시간 가치(time value of money) 가 있다. 오늘의 100만 원은 1년 뒤의 100만 원보다 값지다. 은행에 넣어 이자를 벌 수도 있고, 물가는 오르니까. 기능에도 똑같은 시간 가치가 있다.
미리 짓는다는 건:
돈이 나가는 시점은 당기고, 들어오는 시점은 미룬다. 이 현금흐름의 시점 역전 자체가 손실이다. 그리고 결정적으로:
"이 청구서는 당신의 추측이 맞아도 날아온다(This bill comes due even when your guess is right)."
예측 정확도와 무관하다. 순수하게 '시점'의 문제이기 때문이다.
| 청구서 #1 · 옵셔널리티 | 청구서 #2 · NPV | |
|---|---|---|
| 정체 | 미리 커밋해 '기다릴 권리(옵션)'를 태운 값 | 비용은 당기고 매출은 미룬 시점 손실 |
| 뿌리 | 실물옵션 이론 (금융) | 화폐의 시간 가치 (재무) |
| 예측이 맞으면? | 그래도 손해 (옵션 가치 소멸) | 그래도 청구됨 (시점 문제) |
| AI가 타이핑을 공짜로 만들면? | 그대로 청구됨 | 그대로 청구됨 |
그리고 벡이 방점을 찍는 문장.
"어느 청구서에도 없는 항목을 보라 — 코드를 타이핑하는 비용이다."
바로 여기서 AI 시대의 반전이 완성된다. 옵셔널리티 청구서가 살아남는 이유는, 그것이 노동이 아니라 커밋(미래를 닫아버리는 결정) 에 관한 것이기 때문이다. NPV 청구서가 살아남는 이유는, 그것이 생산 가격이 아니라 현금흐름의 시점에 관한 것이기 때문이다. AI는 타이핑을 지워도 이 둘은 못 지운다.
말로만 하면 감이 안 온다. 직접 조작해 보자. 아래 시뮬레이터에서 슬라이더를 움직이고, 무엇보다 "AI 모드"를 켜서 타이핑을 공짜로 만들어 보라. 두 기둥은 낮아지지만, 둘 사이의 격차(=두 청구서의 합) 는 꿈쩍도 하지 않는다.
시뮬레이터에서 두 가지를 꼭 확인하자. ① 예측 정확도를 100%로 올려도 옵셔널리티 청구서는 0이 되지 않는다("정확히 맞혀도 손해"). ② "기능 도착까지"를 0개월로 놓으면 NPV 청구서가 0이 된다 — 지금 당장 필요한 기능이라면 지금 짓는 게 맞다. YAGNI는 '미래를 위한' 구조에만 칼을 겨눈다.
벡의 "기다림은 자산이다"라는 문장은 시적인 비유가 아니다. 그 뒤엔 반세기짜리 금융·재무 이론이 버티고 있다. 잠깐 곁길로 새서 이 뿌리를 보고 오면, 벡의 주장이 훨씬 단단하게 이해된다.
1973년, 피셔 블랙과 마이런 숄즈가 옵션(선택할 권리)에 값을 매기는 공식을 내놓는다(블랙–숄즈 모형). 여기서 나온 반직관적 통찰 하나: 불확실성이 클수록, 그리고 결정을 뒤로 미룰 수 있을수록 옵션의 가치는 커진다. 미래가 안개 속일 때, "아직 결정하지 않아도 되는 권리"는 그 자체로 비싸다.
1977년, MIT의 스튜어트 마이어스는 이 아이디어를 금융상품 밖으로 끌고 나온다. 그는 기업의 투자 결정도 사실은 옵션이라며 '실물옵션(Real Options)' 이라는 말을 만든다. 공장을 지금 다 짓지 않고, 시장을 보다가 확장하거나·중단하거나·전환할 수 있는 유연성 — 그 유연성 자체가 값어치라는 것이다. 그리고 그는 전통적 NPV 계산이 바로 이 '유연성의 가치'를 놓친다고 지적했다. (그렇다. 벡의 두 청구서는 마이어스의 두 관점을 그대로 물려받은 것이다.)
NPV(Net Present Value, 순현재가치)는 이름이 무섭지만 뜻은 단순하다. "미래에 들어올 돈을 오늘 가치로 환산하면 얼마냐" 를 계산하는 것이다. 1년 뒤의 100만 원은 오늘 기준으로 100만 원보다 적다(예: 할인율 5%면 약 95만 원). 그래서:
이게 벡의 청구서 #2다. 예측이 맞든 틀리든, 시간을 앞당겨 지불한다는 사실만으로 손해가 발생한다.
2000년대 후반, 금융 파생상품 전문가였던 크리스 매츠(Chris Matts) 와 올라프 마센(Olav Maassen)이 실물옵션을 소프트웨어 개발 의사결정에 본격 접목한다(나중에 『Commitment』라는 그래픽 노블로 정리된다). 그들은 복잡한 이론을 단 세 문장, 12개 단어로 압축했다.
매츠의 진단은 뼈아프다. "우리는 결정을 미루느니 차라리 틀리는 쪽을 택한다. 확실함을 원하는 욕구가, 꼭 그럴 필요가 없는데도 우리를 성급한 결정으로 몰아간다." 헨드릭슨이 "3주 뒤엔 필요할 거예요"라고 했던 그 마음이 바로 이것이다. 불확실한 채로 기다리는 게 불안하니까, 지금 뭐라도 지어서 확실함을 손에 쥐고 싶은 것. 벡의 "넌 그거 필요 없어"는, 그 옵션을 만료되기 전에 함부로 행사하지 말라는 말이었다.
이제 왜 이 30년 된 슬로건이 2026년에 다시 불붙었는지 정면으로 보자.
벡은 AI 코딩 도구를 램프의 요정(genie) 에 비유한다. 소원을 빌면 순식간에, 게다가 공짜로 이뤄준다. "미래에 쓸 법한 추상화 계층을 미리 다 만들어줘" 하면, 요정은 기꺼이 아름다운 투기적 프레임워크를 지어 바친다. 여기서 벡의 결정타.
"요정은 기꺼이 당신에게 아름다운 투기적 프레임워크를 지어줄 것이다. 그리고 당신은 그 위에 얹힌 두 장의 청구서를 똑같이 지불하게 된다 — 게다가 당신이 직접 짜지 않았으니, 그걸 더 이해하지 못한 채로."
AI 시대에 상황은 나아지기는커녕 더 나빠질 수 있다. 세 겹으로 그렇다.
여기서 요즘 유행하는 '바이브 코딩(vibe coding)' — AI에게 느낌만 던져주고 코드를 통째로 받아쓰는 방식 — 의 함정이 드러난다. AI는 "혹시 몰라서" 온갖 확장 포인트, 추상 인터페이스, 설정 옵션을 친절하게 얹어준다. 겉보기엔 견고하고 프로페셔널해 보인다. 하지만 그 대부분은 아무도 요청하지 않은 추정 기능이고, 당신은 그 위에 옵셔널리티와 NPV 청구서를 고스란히 떠안는다. 게다가 그 구조를 직접 설계하지 않았으니, 6개월 뒤 그걸 뜯어고쳐야 할 때 "이게 대체 왜 여기 있지?"부터 시작해야 한다.
바로 이 지점이 벡이 강조하는 "AI가 코드를 짜는 시대일수록 설계 판단(design judgment)은 더 중요해진다" 는 메시지의 핵심이다. 타이핑을 위임할 수 있게 될수록, 무엇을 짓지 않을지 결정하는 능력이 인간의 가장 값진 기여가 된다.
추상적인 이론이 실제로 얼마짜리 청구서인지, 현장 사례로 확인하자.
"우린 나중에 대규모로 확장할 테니, 처음부터 마이크로서비스로 쪼개자." 흔한 판단이다. 결과는?
미래의 '확장'이라는 추정 기능을 위해 미리 지은 구조가, 정작 필요하지도 않은 복잡성으로 현재를 짓눌렀다. 전형적인 보유 비용(Carry) 폭발이다.
한 개발자가 단순한 로그 출력이 필요했다. 그런데 "혹시 나중에 DB에도 로그를 쌓고, 이메일로도 보내야 할지 몰라"라며 인터페이스와 여러 구현체를 갖춘 정교한 로깅 시스템을 만들었다. DatabaseLogger, EmailLogger… 상상 속의 그 타입들은 끝내 단 한 번도 만들어지지 않았다. 필요했던 건 단순한 Logger 하나뿐이었다.
"한 번도 쓰이지 않는 확장 포인트는 낭비된 노력일 뿐 아니라, 십중팔구 당신의 앞길을 막는다." — Jeremy Miller (파울러가 인용)
가장 무서운 사례. 한 팀이 "장애에 강한(resilient)" 재시도 추상화 계층을 선제적으로 구축해뒀다. 그런데 그 안의 지수 백오프(exponential backoff) 로직이 데이터베이스의 트랜잭션 타임아웃과 미묘하게 충돌하며 레이스 컨디션을 일으켰다. 진단에 3개 팀, 27시간이 투입됐다.
미리 지은 추상화는 "혹시 몰라서" 만든 것이었지만, 그 복잡성이 실제 장애를 숨기는 벽이 되어버렸다. 이것이 벡이 말한 "직접 짜지 않아 이해하지 못하는" 구조가 부르는 수리 비용의 실체다.
세 사례 모두 공통점이 있다. 타이핑이 문제였던 적은 없다. 문제는 미리 커밋한 결정(옵셔널리티)과, 그 복잡성을 계속 이고 가는 시간(NPV·보유 비용)이었다.
여기까지 읽으면 위험한 오해가 생길 수 있다. "그럼 아무것도 미리 준비하지 말고 대충 짜라는 거야?" 절대 아니다. 이 경계선을 정확히 긋는 게 YAGNI를 제대로 쓰는 마지막 열쇠다.
3장에서 붙잡아 둔 파울러의 단서를 다시 꺼내자. YAGNI는 '추정 기능'에만 적용되고, '수정하기 쉽게 만드는 노력'에는 적용되지 않는다.
| YAGNI가 막는 것 ❌ | YAGNI가 막지 않는 것 ✅ | |
|---|---|---|
| 대상 | 아직 필요 없는 미래 기능을 위한 투기적 구조 | 코드를 수정하기 쉽게 만드는 노력 |
| 예시 | 상상 속 EmailLogger, 조기 마이크로서비스, 안 쓰는 설정 옵션 | 리팩터링, 자동화 테스트, 명확한 이름, 깔끔한 경계 |
| 판단 | 정보가 올 때까지 옵션으로 남겨둔다 | 지금 당장, 꾸준히 한다 |
론 제프리스가 못 박은 문장이 있다. "YAGNI, 맞다. 하지만 대충 짜기(skimping)는 아니다. 기술 부채? 그것도 아니다." 오히려 리팩터링과 테스트라는 '수정 가능성'이 받쳐주지 않으면, YAGNI는 축복에서 저주로 바뀐다. 나중에 필요할 때 빠르게 만들 수 있어야, 지금 안 만들고 기다리는 게 성립하기 때문이다.
그래서 실전 판단 규칙은 이렇게 단순해진다.
정리하자. 켄트 벡의 「YAGNI는 애초에 그 비용에 관한 게 아니었다」가 던지는 메시지는, 겉보기엔 오래된 슬로건의 재해석이지만 실은 AI 시대 소프트웨어 설계의 헌법에 가깝다.
코어닷투데이가 AI 제품과 자동화 시스템을 설계할 때 붙드는 원칙도 여기서 크게 다르지 않다. "AI가 5초 만에 지어줄 수 있다"는 사실은, "지금 지어야 한다"의 근거가 되지 못한다. 지금 필요한 것을 정확히 짓고, 미래의 것은 옵션으로 남겨두되, 그 옵션을 언제든 값싸게 행사할 수 있도록 코드를 깨끗하게 유지하는 것 — 30년 전 디트로이트에서 켄트 벡이 "넌 그거 필요 없어"라고 말했던 그 규율은, AI가 코드를 대신 써주는 2026년에 오히려 더 큰 값어치를 갖는다.
기다림은, 여전히 자산이다.
