AI 에이전트 시대의 새로운 병목: 코드 리뷰
최근 Claude Code와 같은 에이전트 도구의 발전으로 엔지니어 한 명이 처리하는 PR(Pull Request)의 양이 주당 10개에서 50개로 급증함. 하지만 시스템이 자율화될수록 개발자는 자신이 읽지도 않은 코드가 머지되는 상황에 직면하며, 모든 코드를 직접 리뷰하는 것은 불가능해짐.
"자기 만족 기계"의 함정
AI가 작성한 코드를 동일한 AI에게 테스트하게 시키는 것은 위험함. 이는 AI가 자신의 이해도를 바탕으로 스스로를 검증하는 격이라, 근본적인 요구사항 오해를 잡아내지 못함. 결국 동일한 편향을 가진 두 AI가 서로를 칭찬하는 결과만 낳을 뿐임.
TDD의 귀환: 수락 기준 정의
이 문제를 해결하기 위해 테스트 주도 개발(TDD)의 핵심 가치를 도입해야 함. 코드를 짜기 전, 무엇이 '정상 작동'인지 평문으로 된 수락 기준(Acceptance Criteria, AC)을 먼저 작성함.
- 방식: 기능 구현 전 사용자 인증 성공, 에러 메시지 노출 등 구체적인 동작 조건을 명시
- 장점: 에이전트가 코드를 짜고 나면, 별도의 브라우저 에이전트가 이 기준에 맞춰 실제 동작을 검증함
자동 검증 워크플로우
작성된 수락 기준을 바탕으로 Playwright와 같은 도구를 사용해 실제 브라우저에서 동작을 확인하고 스크린샷과 리포트를 생성함. 개발자는 수만 줄의 코드 차이를 읽는 대신, 검증에 실패한 특정 기준만 확인하면 됨.
1
검열관 메모 (2)
코딩 에이전트를 써봤던 여러 개발자의 이 글에 대한 코멘트는 대체로 부정적이네요.
news.ycombinator.com/item?id=47327559
개별 의견 요약
종합
전반적으로 AI 코딩 에이전트의 실용성에 회의적인 시각이 우세했음. 밤새 무감독으로 에이전트를 돌리는 방식은 비용 대비 효용이 불분명하고, 코드 품질·보안 문제가 현실적으로 심각하다는 경험담이 많았음. 생산성 향상 자체는 인정하되, “스펙 작성 → 소수 에이전트 감독”이라는 절제된 접근이 더 효과적이라는 의견이 현실적인 대안으로 자주 등장했음. 멀티에이전트, TDD 자동화 등 고급 워크플로에 대해선 가능성을 인정하면서도 리워드 해킹·테스트 무력화 같은 한계도 명확히 지적됐음. 전체적으로 “AI는 생산성 도구이지 자율 개발자가 아니며, 사람의 판단과 감독이 여전히 핵심”이라는 공감대가 형성되어 있었음.