회원 탈퇴 기능의 테스트 42개가 모두 통과했습니다. 그런데 변경 차이를 열어 보니 탈퇴 API 수정 외에 공용 권한 검사 완화와 로그 원문 추가가 섞여 있습니다. 아래 사례의 숫자와 코드는 검토 순서를 설명하기 위한 예시입니다. 테스트 결과만 보면 초록색이지만 그대로 병합하면 다른 관리 기능의 권한과 개인정보 로그까지 바뀝니다.

핵심 AI가 만든 코드도 리뷰 기준은 같습니다. 다만 변경 속도가 빠르고 그럴듯한 설명이 붙기 때문에 검토자는 요약보다 실제 변경 차이를 먼저 읽고, 요구사항에서 운영까지 열 가지 질문을 일정한 순서로 확인해야 합니다.

리뷰 입력부터 고정합니다

연결된 이슈, 승인된 요구사항, 기준 커밋과 전체 변경 차이를 확보합니다. 에이전트가 남긴 요약은 탐색용일 뿐 변경의 목록으로 간주하지 않습니다. 생성 파일과 잠금 파일, CI 설정도 변경 차이에 포함합니다.

리뷰 전에 무엇이 바뀌어야 하고 무엇은 그대로여야 하는지 두 줄로 적습니다. 예시에서는 본인 탈퇴 요청의 재인증 검사가 바뀌어야 하지만 관리자 권한 정책과 로그 형식은 유지돼야 합니다.

1부터 3까지는 의도와 범위를 봅니다

1. 요구사항: 변경이 사용자의 문제를 해결하는지, 숨은 가정을 새로 만들지 않았는지 봅니다. 2. 변경 범위: 합의하지 않은 리팩터링, 포맷 변경과 생성물이 섞이지 않았는지 확인합니다. 3. 기존 계약: API 상태 코드, 공개 함수, 데이터 형식과 하위 호환성이 유지되는지 비교합니다.

코드가 더 깔끔해졌다는 이유는 범위 확대의 근거가 아닙니다. 공용 권한 검사를 단순화한 줄이 이번 기능에 필요하지 않다면 되돌리거나 별도 PR로 분리합니다.

4부터 6까지는 실패했을 때의 피해를 봅니다

4. 권한과 비밀: 호출자가 해서는 안 되는 행동이 새로 열리지 않았는지, 토큰과 개인정보가 코드나 로그에 들어가지 않았는지 봅니다. 5. 데이터: 중복, 트랜잭션 중단, 마이그레이션과 롤백 때 기존 행이 어떻게 되는지 확인합니다. 6. 외부 부작용: 메일, 결제, 배포와 메시지 발송이 재시도되어도 안전한지 살핍니다.

정상 요청 하나만 통과하는 테스트는 이 질문에 답하지 못합니다. 다른 사용자, 두 번의 같은 요청, 중간 실패와 오래된 클라이언트를 넣어 계약이 유지되는지 확인합니다.

7부터 10까지는 운영과 유지보수를 봅니다

7. 오류 처리: 실패를 숨기거나 무조건 성공으로 바꾸지 않았는지 봅니다. 8. 동시성·성능: 요청 수에 따라 반복 쿼리나 잠금 경합이 늘지 않는지 확인합니다. 9. 관찰 가능성: 장애 원인을 찾을 식별자는 남되 민감한 원문은 기록하지 않는지 봅니다. 10. 검증·복구: 관련 테스트와 프로젝트에서 정한 전체 검사, 배포 확인과 되돌릴 방법이 있는지 확인합니다.

모든 변경에서 열 항목의 무게가 같지는 않습니다. 문구 수정은 데이터 마이그레이션보다 가볍습니다. 그래도 해당 없음이라고 판단한 이유를 말할 수 있어야 빠뜨린 것과 구분됩니다.

리뷰 에이전트에게 정답을 암시하지 않습니다

작성 세션을 그대로 이어서 “잘했는지 봐줘”라고 하면 기존 가정을 반복할 수 있습니다. 새 세션에서 요구사항과 변경 차이를 주고 발견 사항을 심각도와 증거로 반환하게 합니다.

독립 리뷰를 요청하는 예시
이 변경을 수정하지 말고 리뷰하세요.
입력: 연결 이슈, 기준 브랜치와의 전체 diff, 테스트 결과
확인: 요구사항·범위·계약·권한·데이터·부작용·오류·동시성·로그·복구
발견마다 파일과 줄, 재현 조건, 사용자 영향, 수정 방향을 적으세요.
근거 없는 스타일 선호는 제외하세요.
발견이 없으면 확인하지 못한 영역과 추가로 필요한 테스트를 반환하세요.

발견 사항은 재현 가능한 문장으로 씁니다

“보안이 약해 보입니다”는 수정할 수 있는 리뷰가 아닙니다. “본인이 아닌 계정 ID로 DELETE 요청을 보내면 공용 검사 변경 때문에 204가 반환되고, 기존 권한 테스트에는 이 호출자가 없다”처럼 입력, 관찰과 영향을 적습니다.

심각도는 코드 모양이 아니라 피해와 발생 가능성으로 정합니다. 병합을 막는 발견, 후속 수정이 가능한 발견과 단순 제안을 구분하면 에이전트가 모든 코멘트를 기계적으로 적용하는 일을 줄일 수 있습니다.

예시 diff에서 두 가지 차단 사항을 찾습니다

회원 탈퇴 변경에서 공용 `canManageUser()`가 본인 확인을 건너뛰도록 바뀌었다면 권한 회귀입니다. 탈퇴 요청 본문 전체를 오류 로그에 남겼다면 이메일과 재인증 정보가 수집될 수 있습니다. 기능 테스트 42개의 통과는 두 문제를 반박하지 않습니다.

공용 권한 변경을 되돌리고 탈퇴 전용 검사로 범위를 좁힙니다. 로그에는 요청 ID와 결과 코드만 남깁니다. 다른 사용자 요청이 거부되고 민감 필드가 로그에 없다는 테스트를 추가한 뒤 기존 관리자 회귀도 실행합니다.

승인은 최신 diff를 다시 본 뒤에만 합니다

리뷰 코멘트를 고친 새 커밋이 올라오면 이전 승인을 그대로 쓰지 않습니다. 바뀐 변경 차이와 해결된 코멘트를 다시 보고, 추가 수정이 새 범위를 만들지 않았는지 확인합니다. 작은 PR과 파일별 검토 표시가 이 과정을 돕습니다.

최종 결과에는 차단 발견의 해결 근거, 통과한 명령, 확인한 파일과 남은 미검증 영역을 남깁니다. 에이전트 리뷰는 사람의 승인을 대신하지 않으며 특히 인증, 결제, 배포와 데이터 삭제는 소유자의 판단을 유지합니다.

읽고 나서 확인하기

답을 떠올린 뒤 본문의 판단 기준과 비교해 보세요.

  • 테스트 통과와 요구사항·권한·데이터 계약의 유지를 별도로 확인할 수 있습니다.
  • 리뷰 발견을 파일 위치, 재현 조건과 사용자 영향이 있는 문장으로 작성할 수 있습니다.
  • 작성 대화와 분리된 리뷰에서 최신 전체 변경 차이를 기준으로 승인합니다.

공식 출처