같은 버그를 두 번 통과시키는 AI 리뷰어
AI 코드 리뷰어를 도입하면 팀이 즉시 마주치는 불편한 진실이 있다. 도구가 똑똑해 보이는데, 지난달 포스트모템에서 정리한 바로 그 패턴을 또 'LGTM' 처리한다. dev.to에 공개된 Omni-SRE 구축 사례는 이 문제를 날카롭게 드러낸다. 소켓 누수를 유발하는 비동기 제너레이터 패턴이 AI 리뷰를 두 번 통과했고, 두 번째 사고는 첫 번째 포스트모템이 이미 존재했음에도 발생했다. 문제는 모델의 지능이 아니라 상태의 부재다. 제네릭 LLM은 팀의 역사를 모른다. 포스트모템을 읽은 적 없고, 컨벤션을 기억하지 못한다. 매 PR마다 기억을 잃는 도구를 코드 리뷰어라고 부를 수 있을까.
첫 번째 문제: 기억 설계
이 '망각 문제'를 해결하는 구조적 접근은 벡터 메모리를 에이전트의 영구 저장 레이어로 붙이는 것이다. Omni-SRE는 Vectorize의 Hindsight 메모리 시스템을 활용해 팀의 과거 인시던트와 컨벤션을 [pattern:async-generator-leak] 같은 시맨틱 태그와 함께 저장한다. PR이 들어오면 에이전트는 먼저 arecall()로 관련 히스토리를 쿼리하고, 그 컨텍스트를 주입한 뒤 코드를 분석한다. 결과는 극명하다. 메모리 없이는 같은 패턴을 그냥 통과시키지만, 메모리가 주입되면 이전 인시던트 ID를 명시적으로 인용하며 위험성을 설명한다.
여기서 핵심 설계 원칙이 나온다. 어떻게 벡터 메모리를 프루닝하고 주입하느냐가 에이전트의 실질적 지능을 결정한다. 팀의 모든 포스트모템과 컨벤션을 무작위로 쌓아두는 게 아니라, 리뷰 대상 diff와 의미적으로 매칭되는 컨텍스트만 선택적으로 불러오는 recall 전략이 필요하다. 메모리 설계는 기술 결정이 아니라 제품 결정이다.
두 번째 문제: 피드백 인프라
기억 문제를 해결했다고 에이전트가 유능해지는 건 아니다. Signadot의 분석이 지적하듯, 코딩 에이전트의 산출물 품질은 받는 피드백 신호의 품질에 정비례한다. 대부분의 팀은 에이전트에게 코드 에디터와 터미널 정도만 주고 기적을 기대한다. 이건 시니어 엔지니어를 채용해놓고 스테이징 환경, 모니터링 대시보드, 테스트 인프라 접근을 모두 차단하는 것과 같다.
OpenAI가 Codex로 내부 제품을 만들 때 엔지니어 3명이 수백만 줄의 코드를 생성할 수 있었던 건 모델이 뛰어나서가 아니었다. 하네스 엔지니어링—에이전트가 자신의 작업을 검증할 수 있는 환경을 구축하는 것—에 집중했기 때문이다. Stripe의 Minions 프레임워크도 동일한 패턴이다. 400개 이상의 도구를 에이전트에 노출하고, lint → 타입 체크 → 테스트 → 통합 검증으로 이어지는 결정론적 검증 루프를 에이전트의 실행 사이클 안에 내장했다. 주당 1000개 이상의 머지 PR이 이 구조에서 나온다.
피드백 신호에는 계층이 있다. 신택스 체크는 가장 얕은 수준이고, 유닛 테스트, 통합 테스트, 옵저버빌리티 데이터, 시각적 end-to-end 검증 순으로 에이전트의 자율성 천장이 높아진다. SQL 쿼리가 문법적으로 완벽하고 올바른 결과를 반환해도 풀 테이블 스캔이면 프로덕션을 죽인다. 에이전트가 explain plan에 접근할 수 없다면 이 실패는 조용히 배포된다.
세 번째 문제: 비용 가시성
기억과 피드백 인프라를 갖춘 에이전트는 강력하다. 그리고 비싸다. Claude Code 토큰 사용 추적 도구를 다룬 dev.to 아티클이 지적하듯, 소규모에서는 토큰 비용이 보이지 않는다. 문제는 에이전트가 내부적으로 얼마나 많이 반복 추론하는지, 어떤 모델을 어떤 태스크에 쓰는지, 팀 전체에서 병렬로 얼마나 소비되는지가 직관적으로 파악되지 않는다는 점이다.
도구 선택은 팀의 성숙도에 따라 달라진다. 초기에는 Anthropic Console 같은 네이티브 대시보드로 충분하다. 팀이 커지면 Bifrost 같은 게이트웨이 레이어가 필요해진다—모든 LLM 요청을 단일 진입점에서 포착하고, 사용자별·에이전트별 소비를 추적하고, 예산 한도를 설정한다. 프로덕션 규모에서는 Langfuse나 Datadog를 조합해 워크플로우 단위 추적과 인프라 메트릭 연계가 필요하다. 에이전트 기반 코드 리뷰를 도입했는데 토큰 비용이 어디서 나오는지 모른다면, 비용 폭등은 시간문제다.
실전 프레임: 세 축을 동시에 잡아야 한다
이 세 문제는 독립적이지 않다. 벡터 메모리로 기억 문제를 해결하면 arecall() 호출마다 토큰이 소비된다. 피드백 루프를 강화할수록 에이전트의 반복 횟수가 늘고 토큰 비용이 오른다. 비용을 줄이려고 컨텍스트를 줄이면 기억과 피드백 품질이 낮아진다. 세 축은 서로 트레이드오프 관계다.
내일 당장 팀에 적용 가능한 순서는 이렇다. 1단계: 토큰 가시성부터 확보한다. 현재 어디서 얼마를 쓰는지 모르면 나머지 설계를 할 수 없다. 2단계: 팀의 포스트모템과 컨벤션을 시맨틱 태그와 함께 벡터 메모리에 적재한다. 완벽하지 않아도 된다. 최근 6개월 인시던트 10개부터 시작하면 충분하다. 3단계: 에이전트가 접근 가능한 피드백 신호를 단계적으로 확장한다. lint → 타입 체크 → 유닛 테스트 순서로, 각 단계마다 토큰 소비 증가분을 측정하며 진행한다.
전망: 상태 없는 리뷰어의 시대는 끝난다
코드 리뷰 에이전트의 경쟁력은 모델의 파라미터 수가 아니라 운영 설계에서 갈린다. 팀 스코프의 메모리를 얼마나 잘 관리하느냐, 에이전트에게 얼마나 풍부한 피드백 신호를 주느냐, 그 과정의 비용을 얼마나 가시적으로 통제하느냐. 이 세 축이 에이전트 코드 리뷰의 실질적 품질 상한선을 결정한다. 제네릭 LLM을 CI/CD에 붙여두는 것과, 팀의 역사를 기억하고 자신의 작업을 스스로 검증하는 에이전트를 운영하는 것은 전혀 다른 엔지니어링 문제다. 그 간격을 좁히는 팀이 AI 코드 리뷰의 실제 ROI를 가져간다.