"코드 리뷰해줘"라고 입력하면 AI는 뭐라고 답하나. 십중팔구 "이 코드는 전반적으로 좋습니다. 에러 핸들링을 추가하고 변수명을 개선해보세요" 같은 말이 돌아온다. 그 피드백이 틀린 건 아니지만, 루프 안의 off-by-one이나 14번째 줄의 null 미처리는 짚어주지 않는다. 문제는 모델이 아니다. 프롬프트가 문제다.
Dev.to에 공개된 실전 프롬프트 분석에 따르면, 좋은 리뷰 프롬프트는 네 요소로 구성된다. 역할+컨텍스트("당신은 결제 시스템을 다루는 시니어 백엔드 리뷰어입니다"), 우선순위가 매겨진 체크리스트(정확성→보안→신뢰성→가독성 순), 플러프 제거 제약("특정 라인을 지목할 수 없는 개선 제안은 하지 말 것"), 그리고 고정된 출력 포맷(BLOCKING / SHOULD-FIX / NITS 세 섹션)이다. 이 중 제약 조건이 결정적이다. "특정 라인을 가리킬 수 없으면 말하지 말라"는 한 줄만으로 AI가 뱉는 일반론적 노이즈의 절반이 사라진다.
리뷰 모드는 하나가 아니어야 한다. 기본 삼단 분류 리뷰 외에도, "적대적 QA 엔지니어" 모드로 전환해 코드를 실제로 깨뜨릴 입력과 조건을 찾게 하거나, 인증·결제·사용자 입력이 닿는 코드엔 보안 전용 패스를 별도로 돌리는 것이 효과적이다. 보안 리뷰를 일반 리뷰에 끼워 넣으면 모델이 네이밍·구조·보안 사이에서 주의를 분산시킨다. 전용 프롬프트로 단일 모드를 유지해야 발견율이 올라간다.
그런데 리뷰 결과를 받아도 실제로 수정하는 건 여전히 사람의 몫이다. PR 브랜치를 체크아웃하고, 5분짜리 수정을 하고, 린터를 돌리고, 커밋을 푸시한 뒤 CI가 통과하길 기다리는 루프는 개발자의 컨텍스트 스위칭 비용을 조용히 태운다. 같은 Dev.to 글에서 소개된 접근은 이 루프 자체를 에이전트에게 넘기는 것이다. PR 코멘트 끝에 @agent fix를 붙이면 GitHub Actions 위에서 Gemini 3.5 Flash 기반 에이전트가 깨어나 해당 파일을 수정하고 린터를 실행한 뒤 커밋까지 푸시한다.
여기서 설계에서 가장 중요한 부분이 드러난다. 에이전트가 "친절한 리팩토링"을 하도록 두면 안 된다. 버튼 색상 하나 바꾸라고 했더니 500줄짜리 파일을 재작성해 머지 컨플릭트를 터뜨리는 시나리오는 에이전트를 불신하게 만드는 가장 빠른 경로다. 이 에이전트가 채택한 봉쇄 설계는 세 가지다. 최소 변경 원칙(코멘트를 충족하는 가장 작은 수정만), 로컬리티 제약(페이로드에 명시된 파일만 건드림), 검증 후 실패 시 자동 중단(린트가 깨지면 revert하고 AUTOMATED_ABORT 메시지 출력). 이 세 가지가 없으면 자율 수정 에이전트는 생산성 도구가 아니라 리스크 공장이 된다. 이는 최근 이 지면에서 다룬 에이전트 경계 설계 논의와도 맞닿아 있다.
파이프라인의 세 번째 레이어는 클라우드 인프라와의 연동이다. AWS Agent Toolkit은 AI 코딩 에이전트가 AWS를 다룰 때 발생하는 고전적 문제를 해결한다. 모델의 학습 데이터가 오래됐기 때문에 에이전트는 존재하지 않는 API 파라미터를 만들어내거나, 보안 리뷰에서 즉시 반려될 S3 버킷 설정을 제안한다. AWS Agent Toolkit은 MCP(Model Context Protocol)를 통해 Kiro, Claude Code, Cursor, Codex 등 에이전트에 현재 AWS 문서와 검증된 스킬 패키지를 실시간으로 주입한다. 300개 이상의 AWS 서비스에 접근하는 MCP 서버, 64개의 큐레이션된 스킬(Lambda-DynamoDB 연결, 프로덕션 VPC 구성, IAM 최소 권한 설계 등), 그리고 모든 에이전트 호출에 aws:CalledViaAWSMCP 조건 키를 붙여 사람의 API 호출과 에이전트 호출을 정책 수준에서 분리하는 기능이 핵심이다. 에이전트 트래픽이 CloudTrail에 기록되고, 역할 범위를 read-only로 스코프할 수 있다는 점은 실제 운영 환경에서 에이전트를 허용하는 전제조건이기도 하다.
세 레이어를 정리하면 하나의 파이프라인이 보인다. 구조화된 프롬프트로 리뷰 품질을 올리고 → 자율 수정 에이전트가 반복적 패치 루프를 대체하며 → AWS 툴킷이 인프라 레벨의 에이전트 작업을 감사 가능한 범위 안에서 실행한다. 이 세 단계를 이어야 비로소 "AI가 코드 품질을 관리한다"는 말이 성립한다. 하나만 도입해선 파이프라인이 아니라 점으로 끝난다.
실행 순서의 관점에서 내가 팀에 권하는 진입 순서는 다음과 같다. 먼저 리뷰 프롬프트부터 구조화하라. 비용 0, 학습 곡선 낮음, 오늘 당장 효과 확인 가능이다. "review my code"와 구조화된 프롬프트를 같은 함수에 돌려보면 차이가 즉시 체감된다. 다음으로 자율 수정 에이전트는 도입 전 봉쇄 설계를 먼저 문서화하라. 에이전트가 무엇을 하면 안 되는지를 시스템 프롬프트에 명시하지 않으면 팀의 신뢰를 빠르게 소진한다. AWS 툴킷은 IAM 권한 스코핑과 CloudTrail 로깅 확인이 선행된 뒤에 연결하라. 에이전트에게 인프라 접근권을 주는 건 감사 가능한 경계가 확보된 다음 이야기다.
전망은 분명하다. AI 코드 리뷰는 이미 "쓸 수 있느냐 없느냐"의 문제가 아니라 "어떻게 설계하느냐"의 문제로 넘어왔다. 프롬프트 구조, 에이전트 봉쇄, 인프라 감사 경계—이 세 설계를 갖추지 않은 팀은 AI를 도입했지만 AI-First 워크플로우를 운영하는 게 아니다. 도구만 늘어난 채 책임 구조는 그대로인 팀이 맞닥뜨리는 결과는 이미 예측 가능하다.