코드 리뷰는 원래 사람이 천천히 쓰고, 사람이 천천히 읽는 구조를 전제로 만들어진 관행이다. 작성자와 검토자가 비슷한 속도로 움직였기 때문에 균형이 유지됐다. 에이전트가 그 균형을 깼다. 이제 작성 속도는 검토 속도를 압도한다. dev.to에 게재된 "Code Review When Half the Diffs Are From Agents"는 이 불균형이 만들어내는 현실을 냉정하게 짚는다. 검토자가 기존 방식을 고수하면 두 가지 결과 중 하나가 나온다. 검토자가 병목이 되거나, 아니면 아무 생각 없이 승인 도장을 찍거나. 대부분의 팀이 조용히 후자를 선택하면서 전자를 선택했다고 믿는다.
문제는 리뷰 관행을 바꾸지 않았다는 것이 아니다. 무엇을 바꿔야 하는지 제대로 정의하지 않았다는 것이다. 줄 단위로 읽는 리뷰는 인간이 코드를 쓸 때 유효했다. 한 줄 한 줄에 의도가 담겨 있었기 때문이다. 에이전트가 만든 코드는 다르다. 그럴듯하게 생긴 보일러플레이트가 빠르게 쌓이고, 실제 의사결정이 담긴 지점은 드물다. 줄을 전부 읽는다고 의도를 전부 읽는 게 아니다. 리뷰 방식이 저작 방식의 변화를 따라가야 한다.
그렇다면 에이전트가 만든 PR에서 진짜로 물어야 할 질문은 무엇인가. "47번 줄이 맞게 동작하나?"가 아니다. "변경이 건드려야 할 파일만 건드렸나?", "테스트가 코드가 틀렸을 때 실패하게 설계됐나?", "기존 코드베이스 패턴을 따랐나, 아니면 새 패턴을 슬쩍 끼워 넣었나?", "PR 설명이 실제 diff와 일치하나?" 이 질문들은 줄을 전부 읽지 않아도 된다. 대신 변경의 형태를 이해해야 한다. 리뷰의 무게중심이 줄 단위에서 구조 단위로 이동하는 것이다.
물론 여전히 줄 단위 리뷰가 필요한 영역이 있다. 보안 민감 코드, 팀이 오래 손대지 않은 모듈, CI 센서가 경고를 올린 변경, 그리고 한 줄짜리 diff가 복잡한 문제를 마법처럼 해결한 것처럼 보이는 경우가 그렇다. 마지막 케이스가 특히 위험하다. 문제가 사라진 게 아니라 리포팅이 멈춘 것일 가능성이 높다. 이 카테고리들을 제외한 나머지는 구조 우선 리뷰가 합리적 선택이다.
한 가지 함정을 명시적으로 짚어야 한다. 에이전트가 만든 PR을 에이전트에게 리뷰 맡기는 것이다. 처리량 문제가 깔끔하게 풀리는 것처럼 보인다. 하지만 검토 에이전트는 작성 에이전트와 동일한 편향, 동일한 사각지대를 가진다. 오탈자는 잡고 아키텍처 실수는 놓친다. 테스트 커버리지는 칭찬하고 그 테스트가 실제로 무언가를 검증하는지는 모른다. 에이전트 보조 리뷰는 유효하다. diff 요약, 의심 패턴 플래그, 초안 코멘트 작성까지는 맡길 수 있다. 하지만 변경의 형태를 읽고 구조적 질문을 던지는 마지막 단계는 사람이 해야 한다. 그게 리뷰에서 유일하게 실질적인 하중을 지탱하는 스텝이다.
리뷰 관행 변경보다 더 앞선 문제도 있다. 에이전트와의 작업 방식 자체가 한계 구간을 넘어서는 시점이다. dev.to의 "When Vibe Coding Stops Working"은 이 구간을 명확하게 그린다. 바이브 코딩—채팅 열고, 원하는 것 설명하고, 결과 보고, 반복하는 방식—은 버릴 기술이 아니다. 단지 작동하는 범위가 있다. 일회성 스크립트, 새 도메인 탐색, 패턴이 이미 확립된 코드베이스의 소규모 추가 작업. 이 범위 안에서 바이브 코딩은 합리적 선택이다. 범위 밖에서는 예측 가능한 실패 모드로 이어진다.
실패는 갑작스럽지 않다. 기능을 추가할수록 속도가 느려지고, 두 파일의 패턴이 충돌하기 시작하고, 회귀 버그가 어느 세션에서 들어왔는지 추적이 안 되고, 새 팀원이 "컨벤션이 어디 있냐"고 물으면 대답이 "에이전트한테 물어봐"가 된다. 코드베이스가 일관된 스타일이 아니라 패턴의 짜깁기가 되면, 에이전트 자체도 더 나쁜 출력을 내기 시작한다. 패턴 매칭할 일관된 패턴이 없어서다. 이건 바이브 코딩이 나쁜 기술이라서가 아니다. 적합한 범위를 넘어서도 계속 썼기 때문이다.
임계값은 네 가지다. 코드베이스가 팀 전체 머릿속에 안 들어오는 규모, 두 명 이상이 기여하는 팀 규모, 내년에도 프로덕션에서 돌아갈 코드의 시간 지평, 버그가 실제 사용자나 시스템에 영향을 주는 순간. 하나라도 넘으면 모드를 전환해야 한다. 전환이란 에이전트를 버리는 게 아니다. 대화 속에 암묵적으로 있던 컨벤션을 파일로 옮기고, 수동 확인으로 때웠던 부분에 테스트를 추가하고, PR 프로세스를 도입해 게이트를 만드는 것이다.
그런데 컨벤션을 파일로 옮기는 것만으로는 충분하지 않다는 게 세 번째 문제다. dev.to에 게재된 Mneme 팀의 "Executable Architectural Intent"는 이 지점을 정확히 찌른다. 팀이 AI 에이전트와 일하면서 쌓는 지식은 ADR, PRD, AGENTS.md, Cursor rules 등 여러 곳에 흩어진다. 대부분은 참고 자료다. 에이전트가 읽을 수는 있지만, 지킬지 말지는 에이전트 재량이다. 그런데 일부 결정은 재량의 영역이 아니다. 에이전트가 이걸 무시하면, 코드가 실행되고 테스트가 통과하더라도 결과는 틀린 것이다.
이 구분이 핵심이다. 참고 지식과 구속력 있는 제약은 다른 레이어에 있어야 한다. 구속력 있는 제약—Mneme이 "실행 가능한 아키텍처 인텐트"라고 부르는 것—은 다섯 가지 기준을 충족해야 한다. 검증 가능한 규칙으로 명시돼 있고, 해당 시스템의 범위에 묶여 있고, 에이전트가 변경을 커밋하기 전에 컨텍스트로 올라오고, 훅이나 CI 게이트에서 결정론적 판정을 내릴 수 있고, 판정 결과가 원본 결정(ADR, PRD)으로 추적 가능해야 한다. 이 중 하나라도 빠지면 그 규칙은 여전히 문서다. 시행은 안 된다.
이 세 가지 문제는 하나의 구조로 연결된다. 에이전트가 코드를 빠르게 쌓으면, 리뷰 방식을 줄 단위에서 구조 단위로 바꿔야 한다. 에이전트와의 협업 범위가 일정 임계값을 넘으면, 암묵적 컨벤션을 명시적으로 뽑아내야 한다. 그리고 그 컨벤션 중 에이전트가 반드시 지켜야 할 것은 문서가 아니라 시행 레이어로 올려야 한다. 리뷰어의 코멘트 수가 아니라 머지 전에 잡은 문제 수로 팀의 리뷰 효과를 측정해야 한다는 말이 이 맥락에서 나온다.
팀 리드 입장에서 내일 당장 할 수 있는 것부터 짚자면 이렇다. PR 리뷰 체크리스트를 다시 쓴다. "변경 범위가 의도와 일치하는가", "테스트가 실패 조건을 검증하는가", "새 패턴 도입이 있다면 논의됐는가"를 맨 위에 올린다. 에이전트에게 자주 수정을 요구한 항목 세 가지를 rules 파일 첫 세 줄에 박는다. 그리고 아키텍처 결정 중 에이전트가 자의적으로 바꾸면 안 되는 것을 리스트업해서, 그것이 단순히 문서에 적혀 있는지 아니면 CI에서 검증되는지를 확인한다. 그 간극이 지금 팀의 에이전트 거버넌스 수준이다.