AI 코드 리뷰를 돌렸다. 12개 이슈가 나왔다. 고쳤다. 다시 돌렸다. 8개가 더 나왔다. 고쳤다. 또 돌렸다. 5개가 또 나왔다. dev.to의 한 테크 리드는 여섯 번째 실행 이후에야 뭔가 근본적으로 잘못됐다는 걸 깨달았다고 썼다. 익숙한 느낌이라면, 당신만의 문제가 아니다.
이게 프롬프트를 잘못 썼기 때문이라고 생각하면 오산이다. 이건 LLM이 작동하는 방식의 구조적 특성이다. 컴파일러나 린터처럼 모든 라인을 순서대로 결정론적으로 읽는 게 아니라, 각 토큰을 확률적으로 생성한다. temperature가 존재하는 한, 동일한 코드와 동일한 프롬프트를 줘도 결과는 매번 달라진다.
여기에 앵커링 효과(anchoring effect)가 겹친다. 모델이 첫 번째 패스에서 null-safety 이슈에 '꽂히면', 비슷한 패턴을 계속 추적하다가 race condition 같은 전혀 다른 범주의 버그는 통째로 놓친다. 다음 실행에서는 또 다른 테마에 앵커를 내린다. 같은 코드를 여섯 번 돌렸는데 여섯 개의 다른 리포트가 나오는 이유가 바로 이것이다.
이게 단순한 경험담이 아니라는 걸 2025년 연구들이 뒷받침한다. Semgrep의 실험에서는 동일한 보안 프롬프트를 같은 코드베이스에 세 번 실행했을 때 각각 3개, 6개, 11개의 서로 다른 취약점이 발견됐다. 원인으로 지목된 건 'context compaction'—모델이 대량의 코드를 처리하려다 손실 압축을 적용하면서 특정 세부사항을 잃어버리는 현상이다. SWR-Bench 연구는 더 직접적인 숫자를 제시했다. 리뷰를 10번 실행하고 결과를 병합하는 'Self-Aggregation' 전략을 썼더니 실제 버그 검출률(Recall)이 118% 증가했다. 단일 패스는 코드에 실제로 존재하는 버그의 절반도 못 잡는다는 의미다. Ericsson의 엔지니어들은 '거대한 프롬프트 하나'를 쓰는 naive한 접근이 실패한다는 걸 확인하고, Security·Logic·Design·I/O로 특화된 프롬프트를 분리하고 변경 사항의 '인클로징 메서드'로 모델의 집중 범위를 제한하자 할루시네이션이 크게 줄었다고 보고했다.
그렇다면 '그냥 더 많이 돌리면 되지 않나?'라는 생각이 든다. 직접 테스트한 결과는 부정적이다. 동일한 저장소에 전통적인 전체 프로젝트 리뷰를 여섯 번 실행하고 결과를 합산해도 두 개의 크리티컬 취약점이 끝까지 잡히지 않았다. 반면 모듈 기반의 구조화된 패스를 첫 번째 실행했을 때 두 버그가 모두 탐지됐다. 하나는 docker-compose 파일에서 환경변수 기본값으로 API 키가 조용히 주입되어 앱 레벨의 보안 체크를 무력화하는 케이스였고, 다른 하나는 Redis가 패스워드 없이 외부에 노출된 케이스였다. 토큰을 여섯 배 쓴 전통적 방식이 못 잡은 걸 구조화된 한 번의 패스가 잡아낸 것이다.
여기서 MCP 기반 코드베이스 컨텍스트 문제를 함께 봐야 한다. dev.to의 MCP 서버 비교 분석에 따르면, AI 에이전트가 코드베이스에 접근하는 방식은 단순 파일 검색부터 시맨틱 코드 검색, 그리고 구조화된 코드 인텔리전스까지 스펙트럼이 넓다. 핵심은 파일을 가져오는 것과 인텔리전스를 가져오는 것은 전혀 다르다는 점이다. 파일 검색 기반 MCP는 'auth'라는 단어가 들어간 파일을 돌려줄 뿐이다. 에이전트가 그 파일들에서 아키텍처를 스스로 구성해야 한다. 그 과정에서 앵커링과 context compaction이 개입한다.
인프라 영역에서도 같은 문제가 더 극단적인 형태로 나타난다. '더 많은 컨텍스트를 주면 된다'는 직관은 인프라 이해가 볼륨 문제라는 잘못된 가정에 기반한다. 어떤 서비스가 이 큐를 소비하는지, 어떤 Lambda가 이 테이블에 의존하는지, 어떤 스키마 버전이 실제로 배포됐는지—이것들은 텍스트 검색 문제가 아니라 그래프 문제다. RAG는 의미적 유사성을 기반으로 검색하지만 인프라는 정확한 상태와 정확한 관계를 요구한다. dev나 prod 간 리소스 불일치, 스키마는 바뀌었는데 코드는 그대로인 상황—AI는 이 비일관성 위에서도 마치 통합된 진실인 것처럼 추론한다. 코드 리뷰도 마찬가지다. 저장소 전체를 컨텍스트로 먹이는 건 코드가 프로덕션 시스템이라는 착각을 강화할 뿐이다.
결론은 명확하다. 덜 보는 것이 더 잘 보는 것이다. 실용적인 전략은 두 레이어로 구성된다.
Tier 1 — 병렬 모듈 리뷰: 파일 단위가 아니라 책임 영역(handlers, store, infra, WebSocket) 단위로 프로젝트를 나눈다. 각 모듈마다 새로운 세션에서 별도 에이전트를 실행한다. 새 세션은 앵커를 리셋한다. 이전 실행이 무엇을 찾았는지 모르기 때문에 신선한 시각으로 본다. 각 에이전트에는 Security → Performance → Logic → Code Quality 순서의 체크리스트를 주되, 마지막에 체크리스트 외 항목을 위한 추가 스윕을 요청한다.
Tier 2 — 통합 패스: 모듈 간 경계만을 전담하는 별도 에이전트를 돌린다. 인터페이스, 계약, 공유 가정들을 집중적으로 검토한다. 치명적인 버그들은 대부분 모듈 경계에 산다.
팀 현장에서 이 전략을 도입할 때 현실적인 마찰이 있다. 모듈 분리 기준을 처음부터 잡는 비용, 에이전트별 체크리스트 템플릿 설계, 각 패스 결과를 취합하는 프로세스—모두 초기 세팅이 필요하다. 하지만 이 비용은 일회성이다. 반면 단일 패스로 놓친 크리티컬 취약점이 프로덕션에서 터지는 비용은 반복적이고 비선형적으로 커진다.
AI 코드 리뷰 도구가 성숙해지는 방향도 이 구조적 이해 위에서 읽어야 한다. 단순히 더 큰 컨텍스트 윈도우를 제공하거나 더 빠른 추론 속도를 제공하는 방향으로는 이 문제가 해결되지 않는다. 코드베이스에 대한 결정론적 관계 그래프—어떤 컴포넌트가 어디에 의존하고, 비즈니스 규칙이 어떤 경로로 흐르는지—를 에이전트에게 사전 계산해서 전달하는 코드 인텔리전스 레이어가 다음 세대 AI 코드 리뷰의 핵심 인프라가 될 것이다. 지금 당장 팀에서 시작할 수 있는 건 거창한 도구 도입이 아니다. 리뷰 대상을 좁히고, 세션을 분리하고, 집중 범위를 설계하는 것—이 세 가지만으로도 내일 리뷰 품질이 달라진다.