요약
AI 코딩 에이전트로 코드는 빨리 나오지만, 사람의 코드 리뷰가 병목이 되어 그 이득이 사라진다는 연구입니다.
아스테크니카가 소개한 연구입니다. 제목과 요약에 따르면 AI 코딩 에이전트로 얻은 효율이 사람이 하는 코드 리뷰라는 병목에 "흡수"되어, 늘어난 코드만큼 완성된 소프트웨어가 늘지는 않았습니다. HN 이용자에 따르면 이 연구는 2026년 3월에 나왔습니다. 사이트가 접속을 막아 원문을 읽지 못했습니다.
HN 반응
- 리뷰는 원래 병목이었고 에이전트 도입 뒤 더 심해졌다는 경험담이 많았고, 진짜 병목은 리뷰가 아니라 품질이라는 반론도 나왔습니다.
- AI가 만든 테스트가 기존 버그를 정답처럼 굳힌다는 지적과, AI로 쓸모없는 테스트를 정리했다는 사례가 맞섰습니다.
2026년 3월 글이긴 하지만, 제가 현업에서 겪은 것과 잘 맞아떨어집니다. 코드 리뷰는 예전부터 상당한 병목이었고, 에이전트 코딩에서는 그 정도가 더 심해졌습니다. 자동 리뷰에 더 의존하자는 논의도 해 봤지만, 지금까지는 실질적인 개선으로 이어지지 못했습니다. 시니어 엔지니어들은 에이전트가 아무리 좋아졌어도 한 줄 한 줄 읽는 리뷰를 포기하기가 매우 어려운 것 같습니다.
코드 리뷰 문화에 큰 변화가 온다면, 그건 기존 엔지니어링 팀에서 먼저 일어나지는 않을 것 같습니다. 처음부터 사람이 리뷰하지 않는 정책으로 시작해서 회사가 성숙한 뒤에도 그 정책을 유지하는 스타트업에서 먼저 일어날 겁니다. 이미 그런 곳이 있을 텐데, 지금은 대부분의 연구나 설문에 잡히지 않을 가능성이 큽니다. 이런 회사들이 성공을 거두고 눈에 띄게 더 빨리 출시하기 시작하면, 나머지 업계도 어쩔 수 없이 따라가게 될 겁니다.
저라면 이렇게 바꿔 말하겠습니다. 품질은 예전부터 상당한 병목이었고, 에이전트 코딩에서는 그 정도가 더 심해졌다고요.
설계와 코드 품질의 문제 상당수는 코드 리뷰에서 눈에 띄거나 드러나는 것일 뿐입니다.
테스트를 만들고 유지하는 일도 마찬가지입니다. AI가 만든 테스트는 기존 버그를 테스트 가능한 패턴인 양 그대로 박아 넣어서, 버그를 고치면 오히려 테스트가 깨지게 만들거나, 커버리지를 올리려고 내용 없는 assert에 기대는 경우가 많습니다. 사람이 쓰면 대체로 그런 걸 더 잘 압니다. 커버리지는 갈수록 보여주기용 쇼가 되어 가고, 변이 테스트(mutation test)도 거치지 않고 사람이 비즈니스 로직이 제대로 반영됐는지 살펴보지도 않은, 부풀려지고 불필요하고 겨냥도 없는 테스트 쓰레기가 CI 자원과 시간을 잡아먹고 있습니다.
결국 이 판에서 장기적으로 이기는 쪽은 빠르게 적응하는 법을 익힐 수 있는 작은 회사들입니다. 관료제가 굳어진 레거시 기업들은 경쟁사를 집어삼키고 수직 독점을 만드는 데 의존하면서 최악의 쓰레기를 계속 내보내고 있습니다. GH가 자꾸 먹통이 되고, Meta 제품들이 요즘 끔찍하게 버그투성이이고, 다들 다듬지 않은 MVP 같은 느낌인 이유가 그겁니다.
올해 제가 다룬 것 중에서 정식 RCA 절차를 밟을 만큼 심각했던 결함은 전부, “AI가 만든 테스트가 결함 있는 동작을 정상이라고 단언했다”는 것이 원인 중 하나였습니다. 예외 없이 하나도 빠짐없이요.
저는 아직 그런 일을 겪지 않았지만, 어젯밤에 바로 이 생각을 하고 있었습니다. TDD가 실제로 하기에 아무리 어려운 방식이라 해도, TDD를 하면 이 현상이 눈에 띄게 개선될지 정말 궁금합니다. 보통 에이전트는 대다수 사람이 하는 걸 그대로 따라 합니다. 방금 짠 코드가 짠 대로 동작한다고 단언하려고, 통과하도록 테스트를 쓰는 거죠.
저는 테스트 이름과 “given … when … then” 주석까지만 직접 뼈대로 써 두면 꽤 잘 되더라고요.
그렇지 않으면 AI는 최악의 TDD 안티패턴인 마이크로 테스트를 쓰는 경향이 있는 것 같습니다. 리팩터링은 불가능하게 만들면서, 정작 가장 중요한 기능 요구사항은 문서화하지도 확인하지도 못하는 테스트 말입니다.
그 뼈대만 있으면 제가 빠뜨린 동작이나 다른 개선점을 제안하는 건 꽤 잘합니다. 테스트 픽스처를 맨바닥부터 “설계”하라고 하면 그때부터 “그럴듯해 보이는 쓰레기를 만들어 내는” 모드로 들어가는 것 같습니다.
맞습니다. 바이브 코딩으로 만든 PR을 머지해도 괜찮은지 아는 능력은, 밑바탕이 되는 아키텍처가 얼마나 사려 깊고 단순한지, 그리고 기여자들이 해당 제품에 얼마나 주인 의식을 갖고 있는지에 달려 있습니다. 둘 다 더 기민한 팀에 유리합니다.
에이전트로 코드 리뷰를 할 수도 있습니다. 다만 짚어 둘 점이 있습니다. 이른바 “비트코인 레드팀”(7월 30일 Coldcard 공격 이후 비트코인 관련 소프트웨어를 전부 테스트해 온 팀)이 발견한 아주 유용한 사실인데, 미국 모델들은 “안전장치” 때문에 보안 관점에서 코드를 리뷰하는 데는 완전히 쓰레기라는 겁니다. 취약점을 찾으려는 코드를 같은 에이전트가 방금 작성한 경우에도 마찬가지입니다.
거기서는 Kimi K3가 인기가 높은 것 같고, 다른 오픈 웨이트/오픈 소스 모델도 일부 쓰이는 것으로 알고 있습니다.
그렇습니다, 그 경우에도 사람의 감독은 필요합니다. 하지만 사소한 것들로 시간을 낭비하지 않도록 대충 먼저 걸러 주기 때문에, 눈에 띄는 큰 구멍을 찾는 데 더 집중할 수 있습니다.
동의합니다. 요구사항만 분명하게 알려 주면 최신 모델들은 검증을 꽤 잘합니다. 얼마 전에 답답한 일이 있었어요. 테스트 스위트가 엄청나게 큰데도 LLM이 변경하면서 테스트를 깨뜨리는 경우가 거의 없다는 걸 알게 됐습니다. PR이 테스트를 추가하기만 하고 기존 테스트는 한 번도 바꾸지 않았는데, 수상쩍더군요.
그래서 전체 감사를 시켰습니다. 테스트가 약 10만 줄이었는데, 그중 6만 줄 정도는 거의 쓸모없다고 판단했습니다. 지나치게 목(mock)으로 채워진 것이 많았고, 일부는 사실상 아무것도 테스트하지 않는 수준으로 목을 썼더군요. 그걸 지우고 더 폭넓은 시나리오 테스트로 대체했고, 그 과정에서 버그를 많이 잡아 그것도 고쳤습니다. 걸린 시간은 총 2시간쯤입니다.
사람은 요구사항, 명세, 테스트 시나리오를 검토해야 한다고 생각합니다. 어떤 업계나 용도에서는 여전히 모든 세부 사항을 검토해야 하겠지요. 하지만 일반적인 CRUD 앱이라면, 이미 더 빠르게 움직이면서 프로세스와 품질 기준도 그 어느 때보다 높게 잡을 수 있는 단계에 와 있다고 생각합니다.
명세 이야기를 들으면 살짝 웃음이 납니다. 우리도 예전에는 그렇게 했어요. 명세서를 바인더 여러 권 분량으로 쓰고, 그다음에 구현에 들어갔죠. 그러다 그만뒀습니다. 잘 안 됐으니까요. 만드는 과정에서 배우는 것들이 있어서, 공들여 쓴 거대한 명세의 가치가 없어져 버렸습니다. 그래서 그만둔 겁니다. 지속적 개선, CI/CD, 더 짧은 릴리스 주기 같은 것들이 다 거기서 태어났고요.
하지만 왜 그랬을까요? 이유 하나는 구현이 병목이었다는 겁니다. 그래서 시스템을 전부 구현한 뒤에는 바꾸는 데 큰 비용이 들었어요. 엉뚱한 걸 구현하느라 시간을 낭비하지 않으려면 피드백을 일찍 받는 편이 나았죠.
이런 옛 격언들의 셈법이 많이 바뀌고 있습니다.
저는 구현이 병목이라서 그랬던 것만은 아니라고 봅니다. 구현을 하면 만들고 있는 것을 아주 세밀한 수준까지 생각하게 되고, 그러다 보면 상위 수준에서는 눈에 띄지 않던 결함이나 기회를 발견하게 되기 때문이기도 했습니다.
그런데 AI는 추론하다가 그런 걸 마주쳐도 사용자에게 묻지 않고 그냥 가정해 버리는 경우가 많더군요.
제 경험으로는 프롬프트에 따라 이 부분을 꽤 크게 바꿀 수 있었어요.
제 목소리를 따라오세요. 빛이 있는 쪽으로 돌아오세요.
프레드 브룩스는 “하나는 버릴 계획을 하라”고 조언한 것으로 유명합니다. 폭포수 방식 엔지니어링 시절 이야기입니다.
그렇게 말한 이유는 복잡한 시스템을 제대로 만드는 법을 배우는 가장 좋은 방법이 실제로 만들어 보는 과정을 거치는 것이기 때문입니다. 구현이 병목인 건 맞지만, 진짜 문제는 개발 경험이 최고의 스승이라는 점입니다.
저는 개인적으로 이 교훈을 에이전트 코딩에 적용하려고, 먼저 스파이크와 시험 구현을 합니다. AI가 정말 가치를 발휘하는 지점이 여기입니다. 아키텍처의 많은 부분을 건드리는 것을 빠르게 만들어 주기 때문에, AI와 저 모두 전체 윤곽을 제대로 잡을 수 있습니다. 그런 뒤에야 거기서 배운 것으로 제약을 걸어 놓고 본격적으로 풀어 줍니다.
“폭포수”라는 용어를 만들고 그 방법을 설명한 로이스의 논문에도, 첫 번째 구현을 버리는 내용이 들어 있었습니다.
피드백은 여전히 일찍 받는 편이 낫습니다. 거창한 명세를 쓰고, 토큰을 잔뜩 써서 구현하고, 명세에 맞춘 거대한 PR을 올렸는데 뒤늦게 틀렸다는 걸 알게 되면 시간 낭비가 막심합니다. 모르는 것을 모른다는 상황에서 거창한 계획을 세운다는 점은 달라진 게 하나도 없습니다.
세상이 바뀌어도 본질은 그대로입니다.
그 방식의 문제는 명세가 있었다는 게 아니라 반복이 없었다는 점입니다.
웃기죠. 어느 시점이 되면 코드가 곧 명세가 됩니다.
비즈니스 분석가가 UML 다이어그램만 그리면 되니 엔지니어를 다 해고할 때가 됐다던 시절, 기억나세요?
코드가 곧 명세라면, 시스템이 해야 하는 일에 대해 말할 수 있는 것은 그 시스템이 실제로 하는 일뿐입니다.
실제 동작이 뜻밖일 때는 작성자에게 무슨 생각이었는지 물어보면 어쩌면 이해할 수 있을지도 모릅니다. 하지만 그건 작성자가 생각할 수 있고, 자신이 무슨 생각을 했는지 기억할 수도 있는 존재일 때만 통하는 얘기입니다.
다른 분도 이걸 알아채셨다니 반갑습니다. 저는 AI가 쓴 단위 테스트를 보거나 다루는 게 두렵습니다. 화이트박싱이 엄청나게 많이 들어가거든요. 다만 이유는 반대입니다. AI 테스트는 거의 전부 화이트박스 테스트라서 내부 구현이 조금만 바뀌어도 깨집니다.
재미있게도 저는 LLM이 블랙박스 테스트의 단점 상당수를 효과적으로 완화해 준다는 걸 알게 됐고, 지난 1년간 블랙박스 테스트 활용을 크게 늘렸어요.
맞아요, 안타깝게도 요구사항과 명세 상당수가 이제 AI 쓰레기라서, 개발자들이 그걸 읽지 않게 되고, 에이전트는 쓰레기를 더 많이 만들어 냅니다.
요구사항과 명세 작성을 다시 사람에게 되돌려야 합니다.
사람이 쓴 유저 스토리를 상위 수준의 BDD 스타일 테스트(cucumber)로 도입하는 것도 아마 좋은 방법일 겁니다.
그냥 AI 하나가 요구사항을 쓰고, 다른 AI가 그 요구사항으로 명세를 쓰고, 또 다른 AI가 명세로 테스트를 쓰고, 또 다른 AI가 테스트로 구현을 쓰고, 또 다른 AI가 구현으로 PR을 쓰고, 또 다른 AI가 PR을 승인하고, 또 다른 AI가 승인된 PR을 프로덕션에 배포하게 하면 되겠네요!
빼먹지 마세요. 사용자의 AI가 제품을 써 보고 결함을 찾아서 AI가 쓴 버그 리포트를 제출하고, 그게 AI가 쓴 티켓으로 바뀌고, 그다음에 또 이어지고요.
그러는 동안 이 과정이 쓸모 있다고 느낀 사람이 있을까요? 아니, 전혀 없죠...
게다가 이 모든 게 AI 토큰으로 전액 충당되는데, 그 토큰은 AI 회사들에 투자된 돈으로 사고, 그 돈은 AI 연기금으로 마련한 거죠.
아, 아니다, 진짜 사람들의 연금이네요. AI 회사 중 상당수가 아직 “투자 적격”이니까요.
https://www.forbes.com/sites/brandonkochkodin/2026/10/12/ai-powered-bond-rating-startup-says-open-ai-debt-is-junk-anthropic-is-barely-investment-grade/
“끔찍한 자손들(Vile Offspring)”이 태어나려면 어떻게든 거쳐야 하는 과정이죠.
제 경험으로는, 코드 리뷰 단계(혹은 그 이후)에 발생하는 재작업 비용의 가장 큰 원인은 코드가 옳게든 그르게든 엉뚱한 것을 구현하고 있다는 걸 누군가 알아차릴 때입니다. 예를 들어 구현된 기능이 원래의 비즈니스 문제를 충분히 풀지 못하는 경우입니다. 아니면 과잉 설계나 불필요한 기술 부채를 떠안은 탓에 나쁜 방식으로 푸는 경우도 있고요. AI 코드 리뷰가 이 두 가지 문제를 잡아냈다는 증거는 지금까지 제대로 본 적이 없습니다.
사람이 하는 코드 리뷰도 이런 문제를 안정적으로 잡아내지 못한다고 불평하는 사람들이 있다고 들었습니다. 저도 직접 그런 걸 봤습니다. 다만 모든 팀이 그런 건 아닙니다. 공동 소유 의식이 강하고 설계를 함께 고민하는 문화가 있는 팀은 이런 문제를 코드 리뷰에서 꾸준히 잡아냅니다. 정말 잘하는 팀은 그보다 더 일찍 잡아내죠. 예컨대 플래닝 포커는 이제 유행이 지났다는 건 알지만, 제가 그걸 진지하게 하는 팀에 있었을 때는 비용이 가장 적게 드는 올바른 설계를 꽤 이른 단계에서 찾아내는 편이었습니다. 설계가 단순하면 관리하기도 쉬우니 코딩도 코드 리뷰도 빨라집니다. 그리고 코드 리뷰까지 넘어온 설계 결함도 대체로 작고 고치는 비용이 적게 듭니다. 그런 팀은 애초에 코드 리뷰에서 병목이 생기는 일이 거의 없었습니다.
DORA 같은 곳에서 AI 코딩은 좋은 소프트웨어 개발 관행의 효과도 나쁜 관행의 효과도 모두 증폭시키는 승수 같은 것이라고 관찰한 것도 이런 이유에서라고 생각합니다. 카우보이 코딩 문화를 가진 팀에 AI를 던져 넣으면 아마 에이전트 카우보이 코딩이 될 뿐일 겁니다.