AI 코딩 에이전트는 더 많은 코드를 만들지만, 더 많은 소프트웨어를 만들지는 못함

2026년 3월 자료지만 실무에서 겪은 상황과 일치함. 코드 리뷰는 원래 큰 병목이었고 에이전트 코딩으로 더 심해짐. 자동 리뷰에 더 의존하자는 논의도 했지만 아직 실질적인 개선으로 이어지지 않았음. 에이전트가 아무리 좋아져도 시니어 엔지니어는 한 줄씩 검토하는 방식을 포기하기 어려워하는 듯함.
리뷰 문화의 큰 변화는 기존 개발팀보다 처음부터 사람의 리뷰 없이 운영하는 스타트업에서 시작될 것으로 봄. 그런 기업이 성장하면서도 방식을 유지하고 훨씬 빠르게 제품을 출시한다면 업계도 따라갈 수밖에 없음. 이미 그런 곳이 있겠지만 현재 연구나 설문에는 잘 잡히지 않을 가능성이 큼.

이를 품질은 원래 큰 병목이었고 에이전트 코딩으로 더 심해졌다고 바꿔 표현하고 싶음. 코드 리뷰는 설계와 코드 품질의 여러 결함이 발견되고 드러나는 지점임.

최신 모델은 요구사항만 명확하면 검증을 상당히 잘함. 최근 방대한 테스트가 있는데도 LLM의 변경으로 기존 테스트가 거의 깨지지 않고, PR에서 테스트를 추가하기만 할 뿐 수정하지 않는 게 수상해서 전체 감사를 시켰음.
테스트 약 10만 줄 중 6만 줄이 거의 쓸모없다고 판단함. 모의 객체를 과도하게 사용해 사실상 아무것도 검증하지 않는 테스트도 있었음. 이를 지우고 더 폭넓은 시나리오 테스트로 대체하면서 여러 버그까지 찾아 수정하는 데 약 2시간이 걸림.
사람은 요구사항, 명세, 테스트 시나리오를 검토해야 함. 업종과 용도에 따라 모든 세부 사항을 검토해야 할 수도 있지만, 일반적인 CRUD 앱이라면 더 빠르게 개발하면서도 절차와 품질 기준을 이전보다 높일 수 있는 단계라고 봄.

개인적으로 전통적인 코드 리뷰를 좋아하지 않음. 특히 GitHub와 GitLab 웹 인터페이스처럼 도구가 번거롭고, 사람도 정확성과 보안 검토를 아주 잘하지는 못함. 복잡한 변경은 작성자의 머릿속 모델을 재구성해야 프로그램 논리를 제대로 이해할 수 있음.
반면 에이전트만으로 하는 리뷰에는 다른 종류의 한계가 있음. 아키텍처와 설계 판단은 대체로 사람보다 부족하고, 오탐과 미탐도 여전히 우려됨.
지금까지는 제대로 된 IDE에서 에이전트의 도움을 받아 리뷰할 때 결과가 가장 좋았음. 에이전트가 먼저 정확성을 점검하게 하고, 코드의 구조와 논리를 빠르게 이해하는 데 활용함.

중요한 애플리케이션이라면 한 줄씩 검토하는 방식을 포기하면 안 됨. 우리 회사 경영진은 몇 주마다 AI 목표를 바꾸는데, 최근에는 AI 활용이 능숙해지면 향후 2~3년간 개발 속도가 약 두 배가 될 것으로 기대한다고 함.
하지만 우리 팀은 시간의 10%를 코드 작성, 90%를 설계와 분석에 사용함. 코드 작성 속도가 두 배가 되어도 전체 속도 개선은 약 5%에 불과하므로 앞뒤가 맞지 않음.

사람이 더 능숙해졌다고 한 줄씩 하는 리뷰를 생략하지는 않음. 시니어 엔지니어도 자신의 코드를 다른 사람이 그렇게 검토해주길 원함. 코드 작성 주체의 실력만으로 결정할 일이 아님.

경주차 엔진이 충분히 강해지면 타이어의 접지력 같은 다른 부품이 성능을 제한함. 이때 강력한 연료가 나와도 엔진 출력만 높아지므로 차는 조금 빨라지는 데 그침.
소프트웨어도 마찬가지임. 코딩은 전체 업무의 일부라서 완전히 자동화해도 생산성이 열 배로 늘지는 않음. 직업의 일부는 바뀌지만, 코딩이 사라져도 상위 수준의 공학적 모범 관행은 여전히 유효하며 공짜로 얻어지는 것은 없음.

하지만 엔진 설계자는 구동축이나 변속기 기어를 강화하거나 브레이크를 설계하는 일로 전환하고 싶지 않을 수 있음. 그 사람은 엔진을 만드는 사람임.
나도 20년 전 문제 해결과 코드 작성에 대한 열정으로 개발을 시작했는데, 이제는 이름만 그럴듯한 업무 분석가나 제품 관리자로 전환하도록 강요받고 있어 괴로움.

가장 어려운 일은 예나 지금이나 앞으로나 단순하고 명확한 비전과 전략을 세우는 것임. 나머지는 프로젝트 분해, 계획, 규모 확장의 영역이고, 이때 코드를 더 빨리 작성할 수 있으면 유용함. 지난 10년간 실리콘밸리가 추구한 실험, A/B 테스트, 데이터 과학 중심 접근에도 한계가 있음.

암달의 법칙 그대로임. 시스템 일부를 최적화해서 얻는 전체 성능 향상은 그 부분이 실제로 사용되는 시간의 비율에 의해 제한됨.

그냥 LLM이 설계가 엉망이고 버그투성이인 코드를 쏟아낸다는 사실을 인정하면 됨. 밋밋하고 황당한 글을 생성하는 것과 다를 바 없고, 그 뒤에 논리적으로 사고하는 주체조차 없다는 점에서는 더 나쁨. 사람이 쓴 나쁜 코드에는 적어도 그것을 생각해본 사람이 한 명은 있었음.

학술 논문은 연구 당시의 상황을 기술하지만, 집필과 출판에 시간이 걸리고 언론은 이를 현재 상황처럼 보도함.
이번 자료는 2025년의 상황에 가까움. 주요 에이전트 결과에 사용된 모델은 주로 Claude 3.5Sonnet 4.5, GPT-4.1GPT-5, Gemini 2.5임. 연구 설계상 기업들이 좋은 리뷰 절차를 마련하기 전인 도입 극초기의 효과를 주로 보게 됨.

이 연구는 두 차례 갱신됐고, 마지막 갱신은 2026년 8월임.

에이전트 코딩 시대에 맞춰 갱신했는데도 결과는 대체로 같았음. 코드 생성은 빨라졌지만 병목이 리뷰로 이동함.

지금의 모델이 1년 전보다 유의미하게 낫지는 않으므로, 어떤 모델을 썼는지는 여기서 별로 중요하지 않음.

내 경험과는 다름. 우리는 더 많은 소프트웨어를 만들고 더 야심 찬 개발을 하고 있음. 좋은 지침을 마련하면 제품 자체를 반복해서 개선하는 데 훨씬 많은 시간을 쓸 수 있음. 나도 이제 제품을 직접 써보고 여러 방식을 시도하며 다듬는 데 더 많은 시간을 사용함.
다만 그 전에 명세, 설계와 아키텍처, 코딩, 성능, 테스트, 품질 보증 등 방대한 기술 지침을 만드는 작업이 선행됨. 이런 지침·도구·절차의 기반을 갖추는 것이 핵심이라고 봄.

어느 분야인지에 크게 좌우됨. 일상에 유용한 개인 프로젝트는 엄청나게 만들어내고 있지만, 기업용 소프트웨어에서는 생산성이 사실상 멈출 정도로 떨어짐. 도구 사용법을 모르는 것도 원인이고, 경영진의 집단적인 AI 망상도 원인임. Fortune 500에 속한 소프트웨어 회사에서 일하고 있음.

내 경험 부족이 드러나는 질문일 수도 있지만, 정말 한 줄씩 하는 코드 리뷰로 버그를 잡고 예방할 수 있다고 기대했는지 궁금함.
나는 리뷰를 기본적인 타당성 확인, 모범 관행 적용, 주니어 교육의 기회로 활용해왔음. 무언가 깨질까 걱정되면 테스트 커버리지를 논의했음. 지금까지 내가 잘못하고 있었던 건가?

코드를 한 줄씩 읽으며 소프트웨어의 머릿속 모델을 구성하고, 그 과정에서 중요한 버그를 많이 찾음. PR은 작성자와 검토자 모두 배우고 소통하며 팀이 내보내는 코드의 품질을 높일 기회임. 안타깝게도 단기적인 속도를 위해 이를 포기하는 경우가 많음.

리뷰에서 버그를 잡은 적은 있지만 그것이 가장 중요한 목적은 아니라는 데 동의함. 대신 이상한 코드 패턴, 중복, 잘못된 추상화 수준처럼 버그가 숨어들고 자라나는 지점을 찾아 버그 유입을 예방하는 데 큰 역할을 해왔음.
이런 검토는 여전히 가치가 있고 모델이 잘하지 못하는 영역임. 프로젝트와 해결하려는 과제에 대한 폭넓은 맥락이 필요하므로, 자동화가 가능하더라도 특히 큰 프로젝트에서는 비용이 상당할 수 있음.

내가 해본 최고의 코드 리뷰는 구술시험에 가까웠음. 작성자가 변경 사항을 차례로 설명하고 나머지는 듣는 방식임. 특히 위험한 사고 과정의 오류를 잡아내기에 좋음.

한 줄씩 검토하는 방식은 거대한 C나 Fortran 코드베이스에서 더 중요했음. 포인터와 메모리 관리 오류를 실제로 잡아낼 수 있었음. Sun이 Java를 내놓은 뒤로 리뷰가 훑어보는 방식으로 바뀌는 것을 체감함.
이제는 컴파일러나 정적 애플리케이션 보안 분석(SAST)이 많은 결함을 잡으므로, 개발자가 코드의 나쁜 징후를 찾는 데 시간을 쓰는 것은 대체로 낭비임. 예전 방식도 모든 것을 잡지는 못했음. 지금은 컴파일러나 SonarQube가 당연히 잡아주는 결함이 당시에는 운영 환경까지 들어가 비정상 종료와 새벽 3시 장애 대응을 유발했음.

코드 리뷰는 거대한 물을 막아내는 댐과 같음. 완벽하게 하는 사람은 없고, 거의 모든 소프트웨어는 시간이 충분히 흐르면 엉망이 됨.

개인용으로 직접 만드는 소프트웨어가 급증했다는 점에서는 강하게 반박하고 싶음. 예전에는 시간을 낼 엄두도 못 냈던 프로젝트가 이제 가능해짐.

예전 같으면 만들지 못했을 멋진 도구를 너무 많이 만들어 감당하기 어려울 정도임. 지금도 샌프란시스코의 카페에서 Claude 원격 제어로 집에 있는 노트북에 접속해, 좋아하던 옛 MMO의 블랙박스 클라이언트와 서버 에뮬레이터를 만들고 있음. 정말 놀라움.

표본이 한 명인 건가, 아니면 더 있는 건가?

내 나름의 가설이 있음. LLM은 성공한 오픈 소스 프로젝트를 많이 학습하는데, 이런 프로젝트는 널리 쓰이면서 여러 해 동안 극단적인 예외 상황을 처리하는 코드가 쌓임. 일반적인 소프트웨어 대부분에는 그런 처리가 필요하지 않음.
그런데 LLM이 학습한 코드를 모방하면서 작성하는 코드 조각마다 예외 처리를 끼워 넣는 듯함. 그 결과 코드가 늘어나고 읽고 이해하기도 어려워짐.

AI가 이전에는 놓쳤던 버그를 많이 찾아내고 있음. 중요한 버그를 일찍 잡는 것은 좋은 일임.
다만 12개 중 나머지 11개는 실제로는 발생하지 않을 가능성이 큼. 그래도 일단 알게 되면 문서화하거나 이슈로 등록하거나 무시하더라도 각 항목을 이해하고 처리 방향을 결정하는 비용이 발생함.

모델이 혼자 코딩하기 전부터 새 프로젝트의 버그를 찾아달라고 요청했음. 몇 년에 한 번 건드리는 생소한 초기 설정을 떠올리느라 새 웹 프로젝트마다 낭비하던 15분을 1분도 안 돼 해결해줌.
사소한 문제 하나 때문에 구현이 완전히 막혀 낭비하는 시간을 상당히 줄여줄 것 같음. 절약되는 시간이 워낙 다양한 곳에서 생기므로 LLM이 줄여준 개발 시간을 측정하기 어려움.

코드는 늘지만 그 대가는 무엇인가? 실제로 코드 안에 무엇이 있는지 이해하는 팀원은 줄고, 버그는 계속 늘어남. 에이전트는 버그 하나를 기꺼이 고치면서 다른 세 곳을 망가뜨림. 아무도 기존 코드가 왜 그렇게 작성됐는지 멈춰서 묻지 않았기 때문임. 기록적인 속도로 레거시 코드를 만드는 기분임.

며칠 전 상사가 공유해서 논문을 읽었는데 몇 가지가 눈에 띔. 데이터는 대부분 2025년 이전이며, 기준 월평균 코드량은 5,017줄이고 추정 증가량은 인당 월 1,494줄임. 월 PR은 5.34건에서 1.22건 늘었고, 평균 코드 리뷰 기간은 7.03일임.
코드량과 PR 증가 수치는 오래된 데이터임을 뒷받침함. 2026년 말에는 코드가 고작 30% 더 나오는 수준이 아님. 그 정도 증가라면 여전히 모든 줄을 읽고 있을 것임. 코드가 많을수록 좋다는 뜻이 아니라, 아무도 읽지 않는 코드가 지나치게 늘어나는 것이 걱정됨.
리뷰 기간은 평균보다 중앙값이 더 유용했을 텐데 아쉬움. 그래도 기존 개발 문화가 이미 상당히 나빴다고는 볼 수 있음. 평균 PR이 7일씩 방치된다면 출시를 신경 쓰지 않는 셈이고, 에이전트가 그것까지 바꿔주지는 못함.

논문에 자료 수집 기간이 2021년 1월부터 2026년 3월이라고 명시된 것을 읽고도, 저자들이 거짓말하고 있다는 건가?