에이전트한테 코드를 맡길 때 핵심은 생성이 아니라 검수 루프 (PR 자동리뷰 게이트 셋업기)

에이전트가 코드를 그럴듯하게 짜는 건 이제 신기하지 않습니다. 진짜 문제는 그 코드가 빌드 green이고 타입체크도 통과하는데 런타임에서 터진다는 겁니다. 정적 검사가 잡지 못하는 자리를 메우려고 팀에서 굳혀 쓰는 검수 루프를 공유합니다.

워크플로 (순서가 곧 게이트)

• 에이전트는 main 직접 push 금지. 무조건 브랜치를 따고 PR을 올립니다.
• PR이 올라오면 자동리뷰가 트리거됩니다. 참고로 직접 main에 푸시하면 리뷰가 안 돌기 때문에, 이 구조 자체가 브랜치 PR을 강제하는 효과가 있습니다.
• 리뷰 코멘트를 confirm한 뒤 사람이 머지 버튼을 누릅니다. 자동 머지는 안 합니다.
• 머지 = 자동배포이므로, migration SQL은 사람이 직접 RUN합니다. 이건 게이트 바깥에 따로 둡니다.

이 게이트가 실제로 잡은 것들

셋 다 CI는 green이었고, 실제 요청을 한 번 쏴야만 드러나는 부류입니다.

• NestJS 메서드레벨 @UsePipes(ZodPipe)가 body뿐 아니라 같은 핸들러의 @Param/@Query까지 같은 스키마로 파싱 → 정상 요청도 항상 400. 단위테스트는 green, supertest e2e로만 잡혔습니다.
• Next14 client 페이지에서 use(params) 사용 → 런타임 크래시. 빌드는 통과하고 상세 페이지 진입 순간 에러페이지로 떨어집니다. use(Promise)는 Next15 패턴인데 14에 섞여 들어온 케이스였습니다.
• 금액 정규화를 /\D/g로 처리해서 마이너스 부호를 같이 삼킴 → 음수가 양수로 둔갑. 환불 머니패스에 잠복해 있다가 리뷰에서 걸렸습니다.

// 잠복 버그: 마이너스가 \D에 먹혀 사라진다
const won = Number(raw.replace(/\D/g, ""));   // "-3000" → 3000

공통점은 빌드/타입/테스트가 전부 통과한다는 겁니다. 정적 검사가 닿지 못하는 자리를 사람 confirm 한 칸이 메우는 구조입니다.

마지막 한 칸은 비워둡니다

자동화 욕심으로는 confirm까지 봇에게 넘기고 싶지만 하지 않습니다. 에이전트가 짠 PR을 같은 에이전트가 승인하는 순간, 그건 검수가 아니라 도장 찍기가 됩니다. 같은 컨텍스트 안에서는 자기 합리화만 나오기 때문입니다. 머지 권한만큼은 사람이 들고 있는 게 맞다고 봅니다. 생성 속도가 빨라질수록 이 한 칸의 가치는 오히려 커집니다.