AI가 '잘못된 코드'를 짜는 게 아니다
지난달 한 팀에서 실제로 벌어진 일이다. Claude Code가 3주 전에 팀이 폐기하기로 결정한 Redis 큐를 자신 있게 재구축했다. 레포에는 redis.go가 있었고, docker-compose.yml에 Redis 설정이 살아 있었으며, 곳곳에 TODO가 흩어져 있었다. 에이전트 입장에선 '반쯤 만들다 만 피처'처럼 보였고, 합리적인 판단으로 마무리에 착수했다.
문제는 Redis를 쓰지 않기로 이미 결정이 났다는 것이다. 복제 지연이 중복 결제 이벤트를 유발했고, 팀은 Redis를 걷어내기로 했다. 그 결정은 Slack 스레드 하나, PR 코멘트 몇 개, 그리고 엔지니어 세 명의 머릿속에만 존재했다. 코드 검색은 Redis 파일을 봤지만, 그 결정은 볼 수 없었다.
dev.to에 최근 올라온 「We Have Code Review. We Need Intent Review.」는 이 실패 모드를 정확하게 짚는다. AI 에이전트가 나쁜 코드를 짜는 게 아니라는 것이다. '잘못된 역사적 전제'를 기반으로 합리적인 코드를 짠다. 시니어 엔지니어라면 낯선 코드를 건드리기 전에 커밋 히스토리를 뒤지고, 관련 PR을 훑고, Slack에 "이거 왜 이렇게 짰어요?" 한 마디 던진다. 익숙하지 않은 패턴 앞에서 일단 멈춘다. 에이전트에겐 이 '겸손함'이 없다. 반쯤 완성된 것처럼 보이면 마저 완성하는 게 에이전트의 기본값이다.
기존 도구들이 이 문제를 해결하지 못하는 이유
AGENTS.md나 CLAUDE.md는 이미 알고 있는 결정만 담을 수 있다. "Redis 쓰지 말 것"은 Redis를 폐기한 다음에야 쓸 수 있다. 다음 주에 내려질 결정, 어제 동료가 내린 결정은 자동으로 파일에 들어가지 않는다. ADR이나 RFC는 관리 비용이 높아 대부분 첫 분기 이후엔 방치된다. Wiki나 Notion은 코드와 함께 이동하지 않는다. 에이전트는 PR 설명을 선제적으로 읽지 않는다.
결론은 하나다. 현재 존재하는 그 어떤 도구도, 에이전트가 낯선 코드를 건드리기 전에 팀의 역사적 결정에 구조화된 방식으로 접근하게 만들지 못한다. 코드 리뷰가 "이 변경이 잘 구현됐는가?"를 묻는다면, 의도 리뷰는 "이 변경이 팀이 이미 결정한 것과 충돌하지 않는가?"를 묻는다. 그리고 이 질문은 코드를 작성한 이후가 아니라, 이전에 던져져야 한다.
Anthropic이 직접 증명한 '회귀의 조건'
이 문제가 이론적 걱정이 아님을 보여주는 증거가 최근 공개됐다. Anthropic이 Claude Code의 품질 회귀 포스트모템을 발표했다. 3월 4일부터 4월 20일까지 세 건의 변경이 독립적으로 쌓이며 품질을 떨어뜨렸다. 추론 노력 기본값 변경, 캐싱 버그로 인한 매 턴 thinking 초기화, 시스템 프롬프트의 출력 길이 제한 추가. 각각은 작은 조정이었지만 합산 효과는 사용자가 체감할 만큼 컸다.
포스트모템이 공개적으로 인정한 핵심은 이것이다. "각 변경이 서로 다른 트래픽 세그먼트에 서로 다른 일정으로 영향을 미쳐, 초기 보고들이 정상 변동과 구별하기 어려웠다." 여러 단계의 인간 리뷰, 자동화 검증, 도그푸딩을 통과한 변경들이 사용자 피드백으로 뒤늦게 탐지됐다. dev.to의 분석(「Software Quality Has Never Been More Vulnerable」)이 지적하듯, 이 조건은 Anthropic만의 문제가 아니다. 프롬프트를 수정하고, 모델을 바꾸고, 에이전트 스캐폴드를 조정하는 모든 AI 네이티브 팀이 공유하는 운영 환경이다.
멀티 에이전트 시대, 의도 검증의 난도는 올라간다
5월 'Code with Claude 2026' 키노트에서 Anthropic이 공개한 멀티 에이전트 오케스트레이션, 아웃컴(Outcomes), 드리밍(Dreaming)은 에이전트 자율성의 상한선을 한 단계 끌어올렸다. 리드 에이전트가 복잡한 작업을 전문 에이전트들에게 분배하고, 채점 에이전트가 결과를 평가하고, 클로드가 이전 세션을 스스로 검토해 개선한다. 표준 프롬프트 루프 대비 작업 성공률 최대 10%포인트 향상, 파일 품질 최대 10.1% 개선이라는 수치도 나왔다.
좋은 뉴스다. 동시에 의도 리뷰의 필요성이 배가되는 신호다. 단일 에이전트가 팀의 결정을 모를 때 한 기능을 잘못 방향 잡는다면, 멀티 에이전트가 그 전제를 공유한 채 병렬로 달리면 오염 범위는 기하급수적으로 커진다. 드리밍이 '이전 세션에서 놓친 것'을 분석한다고 해도, 그 학습 데이터가 팀의 의도가 아닌 코드 상태만을 기반으로 한다면 같은 실수를 더 정교하게 반복할 뿐이다.
팀 리드가 지금 설계해야 할 것
의도 리뷰를 실제로 작동시키려면 세 가지 조건이 충족되어야 한다. 첫째, 결정은 구조화된 형식으로 기록돼야 한다. 자유형 산문은 에이전트가 매번 전체를 재파싱해야 하고, 쿼리할 수 없다. "무엇을 결정했는가, 무엇을 거부했는가, 왜, 어떤 파일에 영향을 미치는가"가 필드로 분리돼야 한다. 둘째, 결정은 코드 근처에 살아야 한다. Wiki 페이지는 드리프트하고, Notion 문서는 잊힌다. git에 붙어 있는 결정만이 클론, 포크, 브랜치, 시간을 살아남는다. 셋째, 조회는 자동으로, 변경 이전에 이뤄져야 한다. 에이전트에게 "먼저 위키를 확인해"라고 말하는 건 동작하지 않는다. grep이 심볼 정의를 자동으로 찾듯, 팀의 결정도 에이전트 워크플로우 안에서 자동으로 불러와져야 한다.
당장 실행 가능한 수준의 최솟값을 말한다면, AGENTS.md에 '지금 유효한 결정' 섹션을 만들고, 매 PR merge 후 팀이 30초짜리 업데이트 루틴을 갖는 것이다. 완벽한 시스템보다 일관된 습관이 먼저다.
코드 품질 게이트만으론 충분하지 않다
'에이전트가 쓴 코드가 린트를 통과하고 테스트를 통과하면 됐다'는 생각은 이제 절반짜리 기준이다. Claude Code 회귀 포스트모템이 보여줬듯, 각 변경이 개별적으로는 합리적이고 테스트를 통과해도, 누적 효과는 사용자가 체감하는 품질 저하로 나타난다. 코드 품질 게이트는 '잘 짜인 코드인가'를 검증하지만, '팀이 의도한 방향의 코드인가'는 검증하지 못한다.
AI-First 팀 리빌딩을 한다면, 코드 리뷰 자동화 다음 레이어에 의도 검증 레이어를 설계에 포함해야 한다. 에이전트의 자율성이 높아질수록, 그 자율성이 팀의 의도 안에서 작동하는지 확인하는 구조가 없으면 속도는 곧 기술부채가 된다. 멀티 에이전트 오케스트레이션이 팀 워크플로우 안으로 깊이 들어오기 전에, '무엇을 하지 않기로 했는가'를 에이전트가 알 수 있는 구조를 먼저 갖춰야 한다.