요약 (TL;DR): 전통적인 코드 리뷰 체크리스트는 오타, 일관성 없는 명명 규칙, 누군가 서둘러 지나치며 놓친 잊혀진 엣지 케이스(edge cases)와 같은 인간의 실수 패턴을 포착하도록 조정되어 있습니다. AI 에이전트(AI-agent)가 작성한 코드는 다르게 실패합니다. 그 코드는 유창하고 일관적이며, 리뷰어의 일반적인 패턴 매칭(pattern-matching)을 트리거하지 않는 방식으로 자신 있게 틀립니다. 아래는 우리가 현재 실제로 사용 중인 체크리스트로, 유지된 항목, 추가된 항목, 그리고 더 이상 유용하지 않아 삭제된 항목으로 나뉩니다.

기존 체크리스트가 조용히 작동을 멈춘 이유

전통적인 리뷰 체크리스트는 코드를 작성한 사람이 서둘렀거나, 피곤했거나, 시스템의 일부에 익숙하지 않다고 가정합니다. 따라서 _일관성 없음(inconsistency)_을 포착하는 데 최적화되어 있습니다. AI 에이전트의 출력물은 일관성이 없습니다. 그것은 균일하게 유창하며, 이것이 바로 문제입니다. 균일한 유창함은 근본적인 로직에 실제 결함이 있더라도 리뷰어의 눈에는 역량(competence)으로 읽힙니다.

우리는 직감만으로 프로세스를 재설계한 것이 아닙니다. 기술적으로는 기존 체크리스트의 모든 항목을 통과했던 PR(Pull Request)들로부터 발생한 몇 가지 운영 환경(production) 버그들을 추적한 끝에 재설계했습니다.

변경 없이 유지한 것들

어떤 것들은 코드를 누가 — 혹은 무엇이 — 작성했는지에 상관없이 중요합니다:

• 이 코드가 인접한 해석이 아닌 실제 티켓(ticket)과 일치하는가
• 테스트가 단순히 구현을 재확인하는 것이 아니라 동작(behavior)을 테스트하고 있는가
• 변경 사항(diff)이 명시된 범위를 벗어난 부분을 건드리는가
• 운영 데이터(production data)를 건드리는 모든 사항에 대해 롤백(rollback) 계획이 있는가

에이전트 작성 PR을 위해 특별히 추가한 것들

1. 필수 PR 코멘트로 "무엇이 아닌, 왜를 설명하기"
우리는 사소하지 않은 변경 사항마다 이 접근 방식이 왜 선택되었는지를 설명하는 한 문장을 요구합니다. 이는 에이전트의 요약에서 복사하여 붙여넣는 것이 아니라, 리뷰하고 병합(merge)한 사람이 직접 작성해야 합니다. 만약 리뷰어가 왜 그런지를 명확히 설명할 수 없다면, 그것은 건너뛰어야 할 형식적인 절차가 아니라 속도를 늦춰야 한다는 신호입니다.

2. "그럴듯하지만 테스트되지 않은" 엣지 케이스 (edge cases)를 위한 전용 검토 단계.
에이전트 (Agents)는 당신이 명시적으로 설명한 엣지 케이스 (edge cases)는 잘 처리하지만, 당신이 언급할 생각을 하지 못한 부분에 대해서는 놀라울 정도로 일관성이 없습니다. 이제 우리는 리뷰어가 기존 테스트에 포함되지 않은 엣지 케이스를 두 가지 나열하고, 특히 에이전트가 작성한 로직에 대해 최소 하나 이상의 동작을 수동으로 검증하도록 요구합니다.

3. 인증 (auth), 결제 (payments), 외부 데이터 경계 (external data boundaries)에 대한 필수 두 번째 리뷰어 지정.
AI가 공동 작성한 풀 리퀘스트 (pull requests)를 독립적으로 분석한 결과, 인간만 참여한 PR에 비해 취약점 발생률이 유의미하게 높다는 것이 밝혀졌습니다. 우리는 이러한 카테고리에 속하며 에이전트가 손을 댄 모든 파일은 예외 없이 두 명의 승인을 받도록 처리합니다. "작은 변경 사항"이라는 이유로 예외를 두지 않습니다.

4. "재생성 (regenerate) vs 리팩터링 (refactor)" 체크포인트.
무언가를 수정해야 할 때, 기존 구조를 리팩터링 (refactor)하는 것보다 에이전트에게 작동하는 버전을 다시 생성하도록 요청하는 것이 더 빠릅니다. 이것이 바로 코드베이스 전체에 중복된 로직이 조용히 쌓이게 되는 방식입니다. 이제 우리는 에이전트가 이미 다른 곳에 존재하는 것과 병렬적인 구현을 만들어낸 모든 PR에 플래그를 표시하며, 머지 (merge)하기 전에 통합할 것인지 아니면 왜 통합하지 않는지에 대한 근거를 문서화할 것인지 결정하도록 요구합니다.

5. 모든 PR에 대한 출처 (Provenance) 라벨링.
모든 PR에는 디프 (diff)의 내용 중 에이전트가 생성한 부분과 인간이 작성한 부분의 비율이 대략적으로 태그됩니다. 이는 책임을 묻기 위함이 아니라, 얼마나 세밀하게 검토할지를 조정하기 위함입니다. 80%가 에이전트에 의해 생성된 PR은 인간이 작성한 두 줄짜리 수정 사항이 담긴 PR과는 다르게 읽혀야 합니다.

우리가 삭제한 것들

• 리뷰 카테고리로서의 스타일 지적 (Style nitpicking) 거의 전면 삭제. 에이전트는 대부분의 인간보다 포맷팅 (formatting)과 명명 규칙 (naming conventions)에 대해 더 일관적입니다. 따라서 이제는 린팅 (linting)이 이 작업을 처리하며, 리뷰어들은 이에 시간을 소비하지 않게 되었습니다.
• 체크리스트 항목으로서의 "테스트를 작성했는가" 삭제. 에이전트는 기본적으로 테스트를 작성하며, 종종 서두르는 인간보다 더 많은 테스트를 작성합니다. 관련 질문은 _테스트를 작성했는가_에서 _이 테스트가 실제로 올바른 것을 단언(assert)하고 있는가_로 옮겨갔으며, 이는 더 어렵고 유용한 질문입니다.

무엇을 먼저 변경할지 결정하는 빠른 비교

솔직한 트레이드오프

이것은 이전보다 PR당 검토 오버헤드가 더 크다는 의미이며, 이는 다른 곳에서 볼 수 있는 'AI가 모든 것을 더 빠르게 만든다'는 서사와 상충됩니다. 에이전트(agent)가 코드를 작성하는 것은 더 빠르다는 것이 사실입니다. 하지만 검토 과정 자체가 빨라진 것은 아닙니다. 대신 더 목표 지향적으로 바뀌었습니다. 순수 배포 속도는 여전히 증가했지만, 이는 검토 과정이 줄어들었기 때문이 아니라, 이전에 소요되던 보일러플레이트(boilerplate) 및 스캐폴딩(scaffolding) 시간이 사라졌고, 그 간극이 우리가 추가한 검토 오버헤드보다 컸기 때문입니다.

6senseHQ에서는 이 체크리스트가 더 이상 내부 실험이 아니라 고객 작업 전반에 걸친 기본 관행(baseline practice)이 되었습니다. 왜냐하면 '에이전트가 작성했고 괜찮아 보였다'는 답변은 프로덕션 환경에서 문제가 발생했을 때 우리가 고객에게 제공할 의사가 있는 대답이 아니기 때문입니다.

FAQ

모든 AI 에이전트 생성 PR에 추가적인 검토가 필요한가요, 아니면 일부만 필요한가요?
위험도(risk)를 기준으로 범위를 설정하세요. 위험도가 낮고, 충분히 테스트되었으며, 민감하지 않은 변경 사항에는 추가 프로세스가 필요하지 않습니다. 인증(auth), 결제(payments), 외부 데이터 또는 공유 핵심 로직에 영향을 주는 모든 것은 다릅니다. 아무리 작은 diff처럼 보여도 마찬가지입니다.

출처 표기(provenance labeling)가 팀의 속도를 늦추나요?
아주 약간 느려지지만, 그만한 가치가 있습니다. PR에 태그를 지정하는 데는 몇 초밖에 걸리지 않으며, 사전에 올바른 검토 수준을 설정함으로써 절약되는 검토자의 시간은 이 비용보다 훨씬 큽니다.

이 체크리스트가 특정 AI 코딩 도구에만 국한되나요?
아닙니다. 이는 단일 공급업체의(vendor's) 도구가 아닌, 에이전트 기반 코드 생성 전반에 걸쳐 공통적인 실패 패턴을 중심으로 구축되었습니다. 구체적인 도구보다 중요한 것은 여러분의 검토 프로세스가 그 도구가 어떻게 실패하는지를 고려하고 있는지 여부입니다.

온라인상의 대부분의 "AI 시대의 코드 리뷰 (code review in the AI era)"에 관한 조언은 "AI를 신뢰하라" 또는 "AI를 신뢰하지 마라" 중 하나입니다. 둘 다 프로세스는 아닙니다. 위에서 언급한 항목 중 여러분 팀의 실제 실패 패턴을 해결할 수 있는 두세 가지를 선택하여 거기서부터 시작하십시오. 전체 체크리스트는 단 한 번의 회의로 완성되는 것이 아니라, 한 번에 하나의 사고 (incident)를 거치며 점진적으로 재구축되었습니다.