코드 리뷰를 없앤 순간, AI는 속도가 아니라 부채를 만들기 시작했다

화자가 말하고자 하는 핵심

현재의 AI 코딩 에이전트는 ‘당장 작동하는 코드’는 잘 만들지만, ‘앞으로 계속 변경하기 좋은 코드베이스’를 스스로 유지하지는 못한다. 따라서 AI가 구현을 담당하더라도 제품 의도·아키텍처·프로그램 구조·코드 검증은 인간이 계속 통제해야 한다.

화자는 AI 코딩을 반대하지 않습니다. 오히려 AI를 적극적으로 사용하는 HumanLayer의 CEO Dex Horthy입니다.

그가 반대하는 것은 다음과 같은 극단적인 주장입니다.

인간이 개발 속도의 병목이다.
최신 모델은 이미 충분히 똑똑하다.
AI가 만드는 코드는 사실상 공짜다.
그러므로 코드 리뷰도 없애고 최대한 많이 배포하자.

화자의 결론은 그 반대입니다.

AI 시대의 진짜 병목은 코드 작성이 아니라, 무엇을 어떻게 만들 것인지 판단하고 장기적인 품질을 지키는 일이다.

영상은 이며, 발표를 확장한 화자의 원문 글도 공개되어 있습니다.

전체 내용 요약

1. AI가 개발을 빨라지게 하자 코드 리뷰가 병목이 됐다

기존 개발 과정은 다음과 같았습니다.

text

요구사항 → 설계 → 개발 → 테스트 → 코드 리뷰 → 배포

사람이 코드를 작성할 때는 개발에도 몇 시간이나 며칠이 걸렸으므로 코드 리뷰 시간이 크게 부담되지 않았습니다.

하지만 AI 에이전트는 몇 분 또는 몇 시간 만에 대량의 코드를 생성합니다. 그러자 사람이 코드를 읽고 검증하는 과정이 상대적으로 느려 보이기 시작했습니다.

여기서 일부 팀은 이렇게 생각합니다.

“AI가 코드도 만들고 테스트도 하고 리뷰도 한다면 사람이 코드를 읽을 필요가 있을까?”

그 결과 등장한 것이 Lights-off Software Factory, 즉 사람이 코드를 쓰지도 읽지도 않는 완전자동화 소프트웨어 공장입니다.

자동 테스트, AI 리뷰, 샌드박스, 모니터링, 자동 롤백만 충분히 갖추면 인간 코드 리뷰를 제거할 수 있다는 발상입니다.

2. 화자도 실제로 코드 리뷰를 없애봤다

HumanLayer 팀은 2025년 7월부터 약 3~4개월 동안 이 방식을 직접 실험했습니다.

작은 작업과 중간 규모 작업을 백그라운드 에이전트에 맡김
사람은 명세와 티켓만 작성
사람이 에이전트가 만든 코드를 거의 읽지 않음
테스트와 에이전트 검증을 통과하면 배포

초기에는 개발 속도가 크게 향상된 것처럼 보였습니다.

그러나 몇 달 뒤 에이전트가 해결하지 못하는 복잡한 장애가 발생했습니다. 결국 사람이 몇 달 동안 읽지 않았던 코드를 다시 파헤쳐야 했습니다.

그 사이에 발생한 문제는 다음과 같습니다.

사이트 장애
사용자의 불만
문제의 원인을 찾기 어려운 복잡한 코드
한 부분을 수정하면 다른 부분이 깨지는 강한 결합
에이전트가 반복적으로 붙여 놓은 임시방편
일부 영역을 새로 작성하는 것이 더 싼 상태

화자는 처음 발생한 복잡한 장애를 약 2주 동안 추적했다고 설명합니다. 비슷한 일이 세 번째 발생한 2025년 11월경에는 기존 코드를 고치는 대신 공동창업자가 핵심 구조를 직접 다시 작성했습니다. 이는 화자 자신의 사례이므로 강한 현장 증거이지만, 모든 조직에서 동일하게 발생한다고 입증하는 통계적 실험은 아닙니다. 화자의 실험 기록

왜 테스트를 통과했는데 코드베이스가 나빠지는가

이 부분이 발표에서 가장 중요한 논리입니다.

1. AI가 받는 보상은 대부분 단기적인 정답이다

코딩 모델을 강화학습시킬 때 대략 다음 과정을 반복합니다.

모델이 버그 수정 방법을 시도한다.
수정된 코드를 실행한다.
테스트 통과 여부를 확인한다.
성공한 행동은 강화하고 실패한 행동은 약화한다.

대표적인 SWE-bench 계열 평가에서는 모델에 실제 GitHub 이슈와 코드베이스를 주고 수정 패치를 생성하게 합니다. 이후 테스트를 통해 문제가 해결되었는지를 평가합니다. SWE-bench 공식 설명

평가의 핵심은 대체로 두 가지입니다.

FAIL_TO_PASS: 기존에 실패하던 테스트가 통과했는가
PASS_TO_PASS: 원래 통과하던 테스트가 계속 통과하는가

그러나 다음 질문은 쉽게 점수로 만들 수 없습니다.

책임이 적절한 클래스에 배치됐는가?
불필요한 결합이 생기지 않았는가?
같은 로직이 여러 파일에 중복되지 않았는가?
도메인 모델이 일관되는가?
6개월 후 새로운 기능을 쉽게 추가할 수 있는가?
임시방편이 시스템의 기본 규칙을 훼손하지 않았는가?

즉, 테스트는 **“지금 동작하는가”**를 확인하지만 **“앞으로 변경하기 좋은가”**까지 보장하지 않습니다.

2. AI는 테스트를 통과하는 가장 가까운 길을 선택할 수 있다

발표에서는 Fastlane의 Ruby 코드 사례를 보여줍니다.

선택적 파라미터가 nil인데 곧바로 .empty?를 호출해 오류가 발생하는 문제입니다. 자연스러운 수정은 입력 단계에서 기본값을 빈 배열로 만드는 것입니다.

ruby

@include = params[:include] || []
@exclude = params[:exclude] || []

하지만 테스트만 통과하면 된다는 기준에서는 다음과 같은 임시방편도 성공으로 처리될 가능성이 있습니다.

문제가 발생하는 부분에만 예외 처리 추가
의미 없는 타입 캐스팅
여기저기 nil 검사 중복
테스트가 기대하는 값만 반환하는 특수 조건
상위 계층의 잘못된 데이터 규칙을 하위 계층에서 보정

이런 코드는 오늘의 테스트를 통과할 수 있지만, 시스템 규칙을 더 불분명하게 만듭니다.

화자가 말하는 핵심은 “AI가 항상 나쁜 코드를 작성한다”가 아닙니다.

좋은 설계와 나쁜 설계가 똑같이 테스트를 통과한다면, 학습 과정에서 좋은 설계를 선택하도록 강제할 신호가 부족하다.

SWE-bench가 실제 저장소의 문제 해결 능력을 측정한다는 점은 분명하지만, 평가 결과를 장기적인 유지보수 능력과 동일시해서는 안 됩니다. SWE-bench 평가 방식

3. 테스트 결과는 몇 초 안에 나오지만 설계 비용은 몇 달 뒤에 나타난다

좋지 않은 설계는 작성 직후에는 잘 드러나지 않습니다.

text

오늘: 테스트 통과
다음 주: 정상 배포
두 달 후: 작은 변경을 위해 7개 파일 수정
석 달 후: 수정하지 않은 기능에서 장애 발생

AI 강화학습은 빠르게 반복 가능한 명확한 보상 신호가 필요합니다. 테스트 결과는 몇 초나 몇 분 안에 얻을 수 있지만, 유지보수성의 결과는 몇 달 또는 몇 년 후에 나타납니다.

따라서 현재의 학습 체계가 장기적인 설계 비용을 직접 보상에 반영하기 어렵다는 것이 화자의 주장입니다.

이는 매우 설득력 있는 논리지만, 약간의 주의도 필요합니다. 실제 코딩 모델은 테스트 기반 강화학습만으로 만들어지지 않습니다. 사전학습, 인간 피드백, 코드 리뷰 데이터, 별도의 품질 평가 등도 사용될 수 있습니다. 그러므로 “모델은 테스트만 배웠다”라고 단정하기보다는 다음과 같이 이해하는 편이 정확합니다.

기능적 정답은 자동 측정하기 쉽지만, 장기적인 설계 품질은 빠르고 객관적으로 측정하기 어렵기 때문에 학습 신호가 훨씬 약하다.

외부 통계는 화자의 경험을 얼마나 뒷받침하는가

화자는 Faros AI의 조사 결과도 인용합니다. 2026년 보고서는 약 2만2천 명의 개발자와 4천 개 팀의 데이터를 분석해 다음과 같은 상관관계를 보고했습니다.

개발자당 버그 증가
PR당 운영 장애 증가
코드 리뷰 시간 증가
리뷰 없이 병합되는 PR 증가
코드 변경량과 재작업 증가

Faros AI는 고도 AI 활용 집단에서 버그와 장애 지표가 크게 증가했다고 보고합니다. Faros AI 2026 보고서

주석: 이것은 인과관계가 아니다

이 통계만으로 다음을 확정할 수는 없습니다.

text

AI 사용 → 반드시 장애 증가

다른 해석도 가능합니다.

원래 복잡하고 빠르게 성장하는 팀이 AI를 더 많이 사용할 수 있음
AI 때문에 코드 생성량 자체가 늘어 장애 절대량도 증가했을 수 있음
AI 도입과 동시에 리뷰 정책이나 배포 빈도가 바뀌었을 수 있음
조직의 개발 규율 차이가 결과에 영향을 줬을 수 있음

화자도 자신의 원문에서 이 보고서를 “결정적인 증거가 아닌 상관관계 신호”라고 명시합니다. 따라서 이 자료는 화자의 경험과 방향이 일치하는 보조 증거이지, AI가 장애의 직접 원인임을 입증하는 실험 결과는 아닙니다.

“하네스 엔지니어링만으로는 부족하다”의 의미

하네스는 AI 모델을 둘러싼 실행 환경입니다.

파일 읽기·쓰기 도구
터미널 명령
테스트 실행
린터와 타입 검사
샌드박스
컨텍스트와 메모리
여러 에이전트의 작업 순서
완료 조건
자동 코드 리뷰
배포와 롤백 정책

좋은 하네스는 AI의 실수를 크게 줄일 수 있습니다. 화자도 그 효과를 부정하지 않습니다.

다만 하네스는 주로 다음과 같은 검증 가능한 실수를 잡습니다.

컴파일 실패
테스트 실패
스타일 위반
명백한 보안 문제
API 계약 위반
타입 오류

반면 다음 문제는 하네스만으로 판단하기 어렵습니다.

이 기능이 제품 방향에 맞는가?
이 책임이 어느 계층에 있어야 하는가?
지금의 추상화가 미래 변경에도 유효한가?
중복을 허용할 것인가, 공통화할 것인가?
이 설계가 팀의 암묵적 지식과 일치하는가?

따라서 발표 제목의 의미는 다음과 같습니다.

도구와 자동화 장치를 아무리 정교하게 만들어도, 잘못된 목표와 설계 판단까지 자동으로 올바르게 만들지는 못한다.

새로운 벤치마크가 이 문제를 해결하고 있지 않은가

발표자는 SWE-Marathon, DeepSWE, FrontierCode처럼 더 긴 작업과 코드 품질을 평가하려는 새로운 시도를 인정합니다.

특히 FrontierCode는 단순 테스트 통과를 넘어 여러 PR로 이어지는 작업과 프로덕션 코드 품질을 평가하려고 합니다. 별도의 모델이 변경 내용을 보고 품질 규칙을 채점하는 방식도 사용합니다. Cognition의 FrontierCode 설명

따라서 “유지보수성을 평가하는 벤치마크가 전혀 없다”는 표현은 2026년 7월 현재 다소 강한 표현입니다. 정확히는 다음에 가깝습니다.

장기간 진화하는 실제 코드베이스의 유지보수성을 충분히 검증했다고 널리 인정받는 벤치마크가 아직 부족하다.

평가 모델이 다른 모델의 코드를 검토하는 방식도 품질을 높일 수 있습니다. 다만 평가 모델 역시 동일한 설계적 맹점을 가질 수 있으므로 사람의 판단을 완전히 대체하는 최종 판정자로 보기에는 아직 이르다는 것이 화자의 입장입니다.

화자가 제안하는 현실적인 개발 방식

화자는 코드 리뷰를 과거 방식 그대로 느리게 유지하자고 말하는 것이 아닙니다.

코드를 작성한 후 처음 설계를 논의하지 말고, 코드를 작성하기 전에 중요한 결정을 합의하자.

그가 제안하는 순서는 다음과 같습니다.

1. Product Requirements — 무엇을 왜 만드는가

사용자가 겪는 문제
원하는 사용자 행동
성공을 판단할 수 있는 지표
화면이 중요하다면 긴 문서보다 간단한 HTML 목업

2. System Architecture — 시스템들이 어떻게 연결되는가

서비스와 컴포넌트의 경계
API 계약
데이터 모델과 스키마
큐, 저장소, 외부 시스템
오류와 재시도 정책

3. Program Design — 실제 코드는 어떤 모양이 되는가

발표자가 특히 강조하는 단계입니다.

변경될 파일 목록
새로 만들 타입과 인터페이스
메서드 시그니처
호출 순서와 call graph
어떤 계층이 어떤 책임을 가질 것인지
기존 로직 중 제거·재사용할 부분

아키텍처가 건물의 층과 방을 정하는 일이라면, 프로그램 설계는 실제 배관과 전선이 어디로 지나갈지를 결정하는 일입니다.

4. Vertical Slices — 작동하는 얇은 단위로 구현

AI는 다음과 같이 계층별로 한꺼번에 만드는 경향이 있습니다.

text

DB 전체 → 서비스 전체 → API 전체 → 화면 전체

화자는 다음처럼 실제로 실행 가능한 작은 흐름을 먼저 만들 것을 권합니다.

text

API 계약 + 목 데이터
→ 화면에서 호출해 확인
→ 서비스 연결
→ DB 연결
→ 비즈니스 규칙 추가
→ 오류 처리

각 단계에서 100~200줄 정도를 검토하고 방향을 다시 잡는 것이, 마지막에 2,000줄짜리 PR을 받는 것보다 훨씬 싸다는 설명입니다. 화자의 구체적인 4단계 워크플로

이 발표에서 가장 중요한 문장

제가 이 발표를 한 문장으로 다시 정리하면 다음과 같습니다.

AI가 코드를 빨리 작성하게 되었다고 해서 생각할 필요가 없어진 것이 아니라, 오히려 생각을 코드 작성 이전에 더 정확하게 해야 한다.

30분 동안 요구사항과 설계를 정리하면, 코드 리뷰에서 몇 시간을 절약할 수 있습니다. 그러면 최종 코드를 사람이 전부 읽는 것도 현실적으로 가능해집니다.

즉, 인간의 역할은 코드를 타이핑하는 사람에서 다음 역할로 이동합니다.

제품 의도를 결정하는 사람
시스템 경계를 정하는 사람
프로그램의 구조를 설계하는 사람
AI가 벗어나지 않도록 중간에 방향을 교정하는 사람
최종 결과에 책임지는 사람

발표의 한계와 이해관계에 관한 주석

이 발표는 매우 설득력 있지만 몇 가지 한계도 있습니다.

주장	근거의 성격	주의점
코드 리뷰를 없애자 장애가 발생했다	HumanLayer의 직접 경험	표본이 한 회사이므로 일반화에는 한계
AI 활용 증가와 버그·장애 증가	Faros AI의 대규모 관찰 데이터	상관관계이지 직접적인 인과관계는 아님
기존 벤치마크는 유지보수성을 측정하지 못한다	SWE-bench 평가 구조 분석	최근 FrontierCode 등 개선 시도가 등장함
모델은 장기적으로 코드베이스를 악화시킨다	경험적 관찰과 학습 구조에 대한 추론	장기간 통제 실험은 아직 부족함
사람이 설계와 리뷰에 남아야 한다	화자의 실무 경험과 공학적 판단	작업 위험도와 검증 가능성에 따라 자동화 범위를 달리해야 함

또한 HumanLayer는 인간과 AI의 협업 및 검토를 지원하는 제품을 만드는 회사입니다. 화자는 원문 첫머리에서 이 이해관계를 직접 공개합니다. 그렇다고 주장이 틀렸다는 뜻은 아니지만, 해결책이 자사 제품의 방향과 일치한다는 사실은 감안해서 읽어야 합니다.

개발 현장에 적용한다면

은행이나 장기 운영 시스템처럼 장애 비용이 큰 프로젝트라면 작업을 다음과 같이 분류하는 것이 현실적입니다.

작업 유형	AI 자율성	인간 개입
문구 수정, 명확한 단순 버그	높음	결과와 테스트 확인
DTO·매퍼·반복 코드	높음	계약과 예외조건 확인
일반 기능 추가	중간	API·데이터 모델 사전 합의, 코드 리뷰
대규모 리팩터링	낮음	프로그램 설계와 단계별 리뷰
인증·결제·원장·권한	매우 낮음	모든 설계 결정과 변경 코드 검토
장애 자동 수정	제한적	진단·수정안 생성까지만 자동화, 배포 승인 필요

가장 실용적인 원칙은 이것입니다.

자동으로 검증할 수 있는 범위만큼만 자동화하고, 검증하기 어려운 판단은 인간에게 남겨둔다.

결국 화자의 주장은 “AI를 적게 쓰자”가 아닙니다.

코드 리뷰를 없앤 순간, AI는 속도가 아니라 부채를 만들기 시작했다

중년개발자