Tech Bridge 채널이 번역/자막 처리한 해외 컨퍼런스 강연(HumanLayer 소속 발표자로 추정). "AI 에이전트가 코드를 다 짜주니 이제 코드 리뷰는 필요 없다"는 업계 주류 담론을 정면으로 반박하며, 강화학습 기반 코딩 모델 훈련의 구조적 한계를 파고드는 발표.
- 채널: Tech Bridge
- 원본 발행일: 2026-07-25
- 영상: https://www.youtube.com/watch?v=-c43cv80FiA
- 재생시간: 18:20
1계층 — 핵심 주장
업계 일각에서는 StrongDM처럼 **"아무도 코드를 읽지 않는 무인 소프트웨어 공장"**을 만드는 것이 옳은 방향이라 주장하며, "모델은 이미 충분히 훌륭하고 코드는 사실상 공짜이니 토큰을 더 쓰고 더 많이 배포하라"는 것이 지배적인 의견이라고 발표자는 지적한다. 하지만 코딩 에이전트의 실수로 장애가 발생하는 사례, PR 리뷰 품질 저하, 개발자당 버그 발생 증가 등 균열이 이미 보이기 시작했다고 말한다.
발표자의 핵심 주장은 **"이것은 규모(scale)의 문제가 아니다"**라는 것이다. 하네스(harness) 엔지니어링을 아무리 정교하게 하고 에이전트 루프를 아무리 많이 돌려도, 코딩 모델이 강화학습으로 훈련되는 방식 자체의 근본적 한계는 해결되지 않는다고 주장한다.
2계층 — 근거와 논증
(1) 소프트웨어 공장의 역사와 에이전트화
- "소프트웨어 팩토리"라는 용어가 1968년 NATO 회의에서 정의된 오래된 개념임을 언급하며, 2022년(생성형 AI 코딩 대중화 직전)의 전형적인 개발 파이프라인을 설명한다: 사람이 만들고 → PR 생성 → 리뷰·테스트 → 배포 → 사용자 피드백/모니터링 → 다시 개발로 순환.
- 당시 병목은 "만드는 단계"와 "리뷰하는 단계" 모두 몇 시간~며칠씩 걸렸다는 점이었고, 이를 줄이기 위해 팀들은 사전 계획·아키텍처 제안·스프린트 계획 등을 도입했다고 설명한다.
- 에이전트 기반 공장에서는 "사람이 만드는 단계"를 에이전트로 대체하면서 빌드 시간이 분~시간 단위로 줄었지만, 리뷰·테스트는 여전히 병목이었고, 이를 해소하기 위해 에이전트 기반 코드 리뷰·회귀 테스트까지 도입한 뒤, 결국 "코드를 아예 읽지 않고" 테스트·모니터링·배포에만 투자하는 "무인 소프트웨어 공장"(용어 창안자로 Dentcho Vielarov를 언급)으로 진화했다고 짚는다.
- 발표자는 이 흐름이 실패할 수밖에 없다고 본다.
(2) "바이브 코딩"과는 다른 문제
- 소규모 사이드 프로젝트를 가볍게 만드는 개발자와, 10년 된 엔터프라이즈 시스템을 유지보수하는 팀은 거의 아무런 제약 조건도 공유하지 않는다는 한 블로그 글(Addy)의 문제의식을 인용하며, 이 발표는 후자 — 복잡한 "브라운필드" 코드베이스 — 를 다루는 문제라고 선을 긋는다.
(3) 에이전트는 3~6개월 뒤부터 무너지기 시작한다
- 코딩 에이전트에게 전권을 맡기는 실험을 2025년 7월에 직접 해봤다고 밝히며, 몇 달간 방치한 코드베이스에서 결국 사람이 직접 파고들어야만 풀리는 문제가 반드시 나타났다고 말한다 — 그 사이 사이트는 다운되고 사용자는 불만을 제기했다고 언급한다.
- 핵심 주장: 모델은 코드베이스의 유지보수성(maintainability)을 관리·개선하는 데는 한계가 있다는 것 — 한 부분을 고치면 다른 부분이 깨지는 문제(마틴 파울러의 "산탄총 수술" 코드 스멜)가 대표적 증상이라고 설명한다.
- 2024~2025년 사이 모델이 일회성 작업(새 마케팅 사이트 등)에서는 크게 좋아졌지만, 코드베이스 품질을 장기간 유지하는 능력은 별로 나아지지 않았다고 주장하며, 이를 제대로 측정하는 벤치마크가 아직 없다는 점을 스스로 한계로 인정한다.
(4) 왜 이런 일이 생기는가 — Claude Code 사례로 본 훈련 방식의 차이
- Claude Code가 1년도 안 되어 매출 40억 달러에서 90억 달러로 급증한 이유를 다른 CLI 코딩 에이전트(Aether, CodeBuff 등, 도구셋은 거의 동일: read/write/edit/grep/bash)와 비교해 설명한다 — 차이는 모델이 실제 배포되는 하네스(harness)에 맞춰 직접 강화학습된 최초의 사례였다는 점이라고 짚는다.
- OpenAI 팀이 발표에서 "하네스 개발자가 모델 가중치를 소유하지 못하고 그 하네스 안에서 강화학습을 할 수 없다면, 모델과 하네스를 모두 소유한 쪽에 비해 항상 불리하다"고 언급했다는 점을 인용한다.
- 강화학습 훈련 루프의 개략적 과정을 설명한다: 문제를 입력 → 여러 실행 결과(롤아웃) 생성 → 테스트 통과 여부 등으로 평가 → 정답 행동의 확률을 높이는 방향으로 가중치 업데이트.
(5) 벤치마크의 구조적 한계 — SWE-bench 사례 분석
- 대표 벤치마크인 SWE-bench Multilingual의 채점 구조를 Fastlane(Ruby 프로젝트)의 실제 이슈(nil 체크 누락으로 인한 null pointer 예외)를 예로 상세히 설명한다: 사람이 고치기 전 커밋으로 체크아웃 → 숨겨진 테스트 패치·골든 패치 적용 → 에이전트가 문제 해결 → 테스트 파일 변경분 되돌림 → 골든 테스트 패치 적용 후 기존 테스트 통과 + 새 테스트 통과 여부로 이진(1/0) 보상.
- 이 구조에서는 "테스트를 통과시키기만 하면" 보상받는 구조라서, 불필요한 try-catch 남발이나 테스트만 통과시키기 위한 억지 형변환처럼 유지보수성을 해치는 행동을 벌줄 방법이 시스템 안에 없다고 지적한다.
- 근본 원인: 나쁜 아키텍처의 대가는 몇 달~몇 년 뒤에야 드러나기 때문에, 그 지연된 비용을 강화학습의 즉각적 보상 신호로 연결하기가 매우 어렵다는 점을 강조한다.
(6) 개선되고 있는 차세대 벤치마크들
- Abundant AI의 "Sweep Marathon"(마이크로소프트 엑셀 기능 전체를 복제하는 400시간 규모 과제, 정교한 보상 체계), Data Curve의 "Deep Sweep"(실제 환경에서 한 번도 빌드된 적 없는 대규모 OSS 저장소 과제), Cognition의 "Frontier Code"(여러 PR을 묶어 평가하며 "패치 전 코드에서 실패하지 않는 테스트를 작성하면 페널티" 같은 장치와 코드 품질 판정 모델 포함) 등을 소개한다.
- 다만 코드 품질을 "판정하는" 모델 자체도 근본적 한계가 있다고 지적한다 — 좋은 코드가 무엇인지 아는 모델이라면 애초에 그렇게 작성했을 것이기 때문에, 리뷰 에이전트나 더 많은 토큰 투입은 최소 수준을 끌어올릴 뿐, 강화학습으로 가르칠 수 있는 것 자체에는 여전히 한계가 있다고 결론짓는다.
(7) 그래서 지금 무엇을 해야 하는가 — 다시 코드 리뷰로
- 모델의 근본적 한계가 곧 해결되길 기다리는 대신, 엔지니어링적으로 해결하는 접근을 제안한다: 코드 리뷰를 다시 도입하되, 사전 계획으로 리뷰 시간 자체를 줄이는 방식.
- 구체적 절차: (1) 제품 리뷰(원하는 동작·목업 확정) → (2) 시스템 아키텍처 설계(컴포넌트 계약·데이터 모델·제약조건) → (3) 프로그램 설계(타입, 메서드 시그니처, 프로그램 레이아웃, 호출 스택) — 에이전트 코딩 시대에 가장 과소평가되고 있는 단계라고 강조하며 Cloudflare의 딜런 멀로이가 활용하는 호출 그래프 사례를 언급한다 → (4) "수직 슬라이스"(구현 순서·멀티 레포 조정·단계별 검증).
- 핵심 메시지: 사전 계획·정렬에 30분을 투자하면 리뷰에 드는 몇 시간을 절약할 수 있다.
(8) "PR이 너무 많은 게 문제가 아니라, 나쁜 PR이 너무 많은 게 문제"
- 좋은 PR은 리뷰하는 재미가 있지만, AI 코드 특유의 허술함을 감안해도 관대하게 잡아 20% 정도의 재작업이 필요한 PR조차 리뷰어와 제출자 모두에게 상당한 정신적 부담을 준다고 지적한다.
- 모델 기반 사전 계획·정렬을 활용하면 (a) 정보 취합이 빨라 정렬 시간이 줄고, (b) 사전 정렬 덕분에 리뷰 속도가 빨라지며, (c) AI가 코딩을 대신해 속도가 빨라지는 세 가지 효과가 겹쳐, 속도는 빨라지되 모든 코드를 여전히 읽고 책임을 유지하는 방식이 가능하다고 결론짓는다.
3계층 — 실천적 시사점
- "코드를 아예 읽지 않는" 완전 자동화된 파이프라인을 지향하기보다, 사전 계획(제품 리뷰 → 아키텍처 → 프로그램 설계 → 수직 슬라이스)에 시간을 투자해 리뷰 부담 자체를 줄이는 전략이 현실적이라는 시사점을 준다.
- 특히 "프로그램 설계"(타입·메서드 시그니처·호출 스택 수준의 설계)를 아키텍처 설계와 별개의 과소평가된 단계로 재조명할 필요가 있다.
- AI 코딩 에이전트에게 장기간 방치된 브라운필드 코드베이스를 맡길 때는, 3~6개월 시점에 반드시 사람이 개입해야 하는 유지보수성 문제가 나타날 수 있음을 전제하고 계획을 세울 것.
- "PR 개수"가 아니라 "나쁜 PR의 비율"을 관리 지표로 삼아, 재작업률을 낮추는 사전 정렬 프로세스에 투자할 것.
4계층 — 개념 정리
| 개념 | 설명 |
|---|---|
| 무인 소프트웨어 공장 | 코드를 사람이 전혀 읽지 않고 테스트·모니터링·배포에만 투자하는 완전 자동화 개발 파이프라인 (Dentcho Vielarov 용어) |
| 브라운필드 코드베이스 | 오래되고 복잡한 기존 코드베이스. 스몰 사이드 프로젝트(그린필드/바이브 코딩)와 대비되는 개념 |
| 유지보수성(Maintainability) | 코드베이스의 한 부분을 바꿨을 때 다른 부분이 깨지지 않는 성질. 마틴 파울러의 "산탄총 수술" 코드 스멜과 연결 |
| 하네스(Harness) | 코딩 에이전트가 동작하는 실행 환경/툴링 레이어. 모델을 그 하네스에 맞춰 직접 강화학습했는지가 성능 차이의 핵심 요인으로 제시됨 |
| SWE-bench Multilingual | 오픈소스 저장소의 실제 이슈를 골든 패치·테스트 패치 기반 이진 보상으로 채점하는 대표적 코딩 에이전트 벤치마크 |
| 프로그램 설계 | 아키텍처보다 한 단계 더 구체적인, 타입·메서드 시그니처·호출 스택 수준의 설계 단계 |
| 수직 슬라이스 | 구현 순서·멀티 레포 조정·단계별 검증을 포함하는 실행 계획 단위 |
핵심 요약 (20줄)
- 업계 일각에서 "아무도 코드를 읽지 않는 무인 소프트웨어 공장"을 지향하는 흐름을 발표자가 정면으로 반박한다.
- StrongDM 사례를 들며 "모델은 충분히 훌륭하니 토큰을 더 쓰고 더 많이 배포하라"는 지배적 의견을 소개한다.
- 코딩 에이전트의 실수로 인한 장애, PR 리뷰 품질 저하, 개발자당 버그 증가 등 균열이 이미 나타나고 있다고 지적한다.
- 핵심 주장은 이것이 규모의 문제가 아니라, 코딩 모델이 강화학습으로 훈련되는 방식 자체의 근본적 한계라는 것이다.
- 2022년 전통적 개발 파이프라인에서 병목이던 "만들기"와 "리뷰하기" 단계가, 에이전트 도입 후 빌드는 빨라졌지만 리뷰는 여전히 병목이라고 설명한다.
- 이 병목을 없애려다 결국 코드를 아예 읽지 않는 "무인 소프트웨어 공장"으로 진화하는 흐름을 비판한다.
- 이는 소규모 사이드 프로젝트를 만드는 바이브 코딩과는 다른, 복잡한 브라운필드 코드베이스의 문제라고 선을 긋는다.
- 2025년 7월 직접 실험한 결과, 방치된 코드베이스는 3~6개월 뒤 사람이 반드시 개입해야 하는 문제가 나타났다고 밝힌다.
- 모델은 코드베이스의 유지보수성을 장기간 관리하는 데 근본적 한계가 있다고 주장한다.
- Claude Code가 급성장한 이유를, 모델이 실제 배포되는 하네스에 맞춰 직접 강화학습된 최초 사례였기 때문이라고 설명한다.
- 강화학습 훈련은 문제 입력 → 여러 실행 결과 생성 → 테스트 통과 평가 → 가중치 업데이트의 과정을 거친다고 설명한다.
- SWE-bench 같은 벤치마크는 테스트 통과 여부로만 이진 보상을 주기 때문에, 유지보수성을 해치는 행동을 벌줄 방법이 구조적으로 없다고 지적한다.
- 나쁜 아키텍처의 대가는 몇 달~몇 년 뒤에야 드러나 그 지연된 비용을 보상 신호로 연결하기 어렵다는 점을 근본 원인으로 짚는다.
- Sweep Marathon, Deep Sweep, Frontier Code 등 유지보수성을 반영하려는 차세대 벤치마크들을 소개한다.
- 다만 코드 품질을 판정하는 모델 자체도, 좋은 코드를 안다면 애초에 그렇게 썼을 것이라는 근본적 한계가 있다고 짚는다.
- 그래서 당분간은 사람이 직접 코드를 읽어야 하며, 대신 사전 계획으로 속도를 높이자고 제안한다.
- 제품 리뷰, 시스템 아키텍처, 프로그램 설계, 수직 슬라이스 순의 사전 계획 절차를 구체적으로 제시한다.
- 특히 프로그램 설계(타입·메서드 시그니처·호출 스택)가 에이전트 코딩 시대에 가장 과소평가된 단계라고 강조한다.
- 문제는 PR 개수가 아니라 나쁜 PR의 비율이며, 모델 기반 사전 정렬이 정렬·리뷰·코딩 속도를 모두 높여준다고 결론짓는다.
- 마지막으로 완전 자동화를 기대했던 사람들에겐 실망스러울 수 있지만, 엔지니어는 주어진 제약 안에서 문제를 풀어야 한다며 발표를 마무리하고 자신이 만드는 HumanLayer 플랫폼을 소개한다.