에이전트 diff를 사람처럼 리뷰하려면

에이전트가 PR·패치를 빠르게 쌓아도, 머지 결정은 사람이 합니다. 에이전트 diff는 사람이 쓴 것과 같은 도구(git diff, PR Files)로 보이지만, 범위 밖 친절한 리팩터·테스트 스킵·시크릿 근접·“통과했다고만” 적힌 본문이 섞이기 쉽습니다. 그래서 사람 리뷰 체크리스트로 읽는 습관이 필요합니다.

이 글은 뭘 먼저 보나 · 테스트 없이 머지해도 되나 · 롤백 기준은 뭔가만 다룹니다. 브랜치 이름·CODEOWNERS·경로 allowlist·에이전트별 PR 쪼개기는 multi-agent-pr-workflow 축입니다. 여기서는 이미 열린 하나의 diff를 사람이 어떻게 훑는지에 초점을 둡니다. 요금·플랜·토큰 숫자는 없습니다.

뭘 먼저 보나?

한 줄 답: 파일 목록·통계부터 보고, 의도(티켓·PR 본문)와 실제 경로가 맞는지를 확인한 뒤, 위험 표면(인증·데이터·배포·시크릿·스키마) 과 테스트/문서 짝을 봅니다. 줄 단위 미학은 그 다음입니다.

에이전트 diff를 사람 PR처럼 열었을 때 권장 순서:

순서먼저 볼 것질문
1Files changed / git diff --stat파일 수·추가·삭제가 티켓 범위와 맞는가? 잠금파일·생성물·i18n 전체가 갑자기 들어왔는가?
2PR 본문 vs diff“한 줄 요약·비범위·재현/테스트 방법”이 실제 변경과 일치하는가? 에이전트 주장만 있고 증거 경로가 없는가?
3위험 경로auth, 결제, 권한, 마이그레이션, CI/배포, .env* / 키 파일, 공개 API 시그니처가 바뀌었는가?
4삭제·이동큰 삭제·파일 rename이 “정리”인지 회귀인지. 호출부가 같이 갱신됐는지.
5테스트·픽스처동작 변경에 대응 테스트가 있는가? skip/xit/assertion 완화로 통과를 만들지 않았는가?
6스타일·네이밍위가 통과한 뒤에만. 순수 포맷-only는 별 PR이 낫습니다.

체크리스트(복붙용):

[ ] stat: 예상 경로만? 잠금파일·생성물 폭주 없음?
[ ] 의도: PR 본문 Done/Out-of-scope와 diff 일치?
[ ] 위험: 시크릿·권한·스키마·배포 스크립트 변경 명시 검토?
[ ] 삭제/rename: 참조·import·설정 동시 갱신?
[ ] 테스트: 새/변경 동작에 짝이 있거나, 왜 없는지 한 줄 사유?
[ ] 에이전트 “셀프 리뷰” 문구만 믿고 Approve하지 않음

에이전트-특유 함정 (사람 작성 diff보다 자주 보임):

  1. 범위 밖 “같이 고침” — 인접 파일 리네이밍, 무관한 lint 일괄 수정, 사용하지 않는 import 정리로 diff가 커짐.
  2. 설명과 코드 불일치 — 본문은 “버그 수정만”, 실제는 API 시그니처·기본값 변경.
  3. 테스트 모양만 — 존재하지만 실패 경로를 덮지 않거나, 플래키 타임아웃만 늘림.
  4. 도구 산출물 혼입 — 포맷터·codegen·스냅샷이 의도 없이 대량 갱신.

multi-agent-pr-workflow와의 한 줄 경계: 그 글은 누가 어느 브랜치에서 어떤 게이트로 머지할지이고, 이 절은 그 게이트 앞에서 사람이 diff를 어떤 순서로 읽는지입니다.

테스트 없이 머지?

한 줄 답: 기본은 아니오. 로컬·CI에서 합의된 최소 검증이 없거나 실패하면 머지하지 않습니다. 예외는 문서·주석·순수 설정 오타처럼 런타임 영향이 명백히 없고, 팀이 예외 라벨·사유를 PR에 남기는 경우뿐입니다. “에이전트가 돌렸다고 함”은 증거가 아닙니다.

결정표:

변경 유형최소 검증테스트 없이 머지?
동작·API·스키마·권한관련 단위/통합 또는 문서화된 수동 시나리오 + CI green아니오
버그픽스재현 실패 → 패치 후 같은 명령 통과(가능하면 회귀 테스트 추가)아니오 (재현 증거 필요)
리팩터(동작 동일 주장)기존 스위트 유지 + 핵심 경로 스모크아니오 (스위트 없이 “동일” 주장 금지)
문서·README·주석만링크·오타 확인, 빌드/사이트 프리뷰(해당 시)조건부 예 (런타임 코드 미포함일 때)
CI·배포 스크립트dry-run·파이프라인 검증 잡아니오
의존성 잠금만설치·빌드·핵심 테스트아니오 (공급망·브레이킹 가능)

실무 규칙:

  1. 증거 경로를 PR에 고정 — 실행한 명령, CI 체크 이름, 수동 시나리오 체크리스트. 에이전트 채팅 로그 전문 복붙은 필요 없습니다.
  2. 빨강 CI를 초록으로 속이지 않기 — skip, 타임아웃만 상향, flaky를 @retry로만 감추기, assertion 삭제. 보이면 머지 보류 + 되돌리기 요청.
  3. “테스트 추가가 어렵다”면 — 왜 어려운지, 대신 어떤 수동 검증을 했는지, 후속 티켓 ID를 적습니다. 빈칸이면 머지하지 않습니다.
  4. 에이전트 TDD 루프 글과의 경계 — 그 글은 작성 중 red→green 순서이고, 여기는 머지 직전 사람 게이트입니다. green을 에이전트가 주장해도 사람이 명령·CI를 한 번 더 확인합니다.

예외를 열어 둘 때도 라벨(예: risk:docs-only)과 롤백 한 줄(아래 절)을 같이 요구하면, “일단 머지”가 습관이 되지 않습니다.

롤백 기준은?

한 줄 답: 머지 전에 되돌릴 단위(revert 커밋 / PR revert / feature flag) 를 정해 두고, 증상·범위·시간 중 하나라도 임계를 넘으면 수정 패치보다 롤백을 먼저 합니다. 에이전트에게 “핫픽스로 더 고치라”만 반복하면 사고가 커집니다.

머지 전 롤백 설계:

항목정해 둘 것
되돌림 단위단일 PR revert가 안전한가? 여러 PR이 겹치면 통합 revert 담당은 누구인가?
플래그위험한 경로에 feature flag / config switch가 있는가?
관측어떤 메트릭·로그·알람이면 “실패”인가? (에러율, 5xx, 큐 적체, 데이터 불일치)
소통롤백 결정 채널·OWNER

머지 후 즉시 롤백을 고르는 기준 예:

  1. 사용자·데이터 손상 — 잘못된 쓰기, 권한 확대, 결제·삭제 경로 이상.
  2. 서비스 수준 — 합의된 에러율·지연·실패 예산 초과가 이 배포와 시간적으로 맞음.
  3. 되돌리기보다 전방 수정이 불명 — 원인 후보가 3개 이상이거나, 에이전트 후속 패치가 diff를 더 키우기만 함.
  4. 마이그레이션 실패 — expand/contract 없이 깨진 스키마. (데이터 마이그레이션은 revert만으로 부족할 수 있어 백업·forward-fix 런북을 별도 확인.)
  5. 시크릿·자격 증명 유출 의심 — 롤백과 동시에 키 회전·로그 점검. 코드 revert만으로 끝나지 않습니다.

롤백 실행 체크:

[ ] revert/flag로 증상이 줄었는가?
[ ] main/배포 브랜치에 재발 방지 라벨·이슈가 열렸는가?
[ ] 에이전트에게 “같은 브랜치에 이어서 큰 패치”를 시키지 않았는가? (새 브랜치·최소 repro)
[ ] 사람 포스트모템 한 줄: 무엇이 리뷰에서 빠졌는가? (통계? 테스트? 위험 경로?)

전방 수정(forward fix)을 택할 때: 원인이 한 줄로 좁고, 테스트가 이미 빨강을 재현하며, 변경 면적이 원래 PR보다 작을 때입니다. 그렇지 않으면 롤백이 기본값입니다.

FAQ

multi-agent-pr-workflow 글과 무엇이 다른가요?

그 글은 에이전트별 브랜치·사람 Approve 게이트·경로 충돌 예방입니다. 이 글은 게이트에 올라온 diff를 사람이 어떤 순서로·어떤 기준으로 읽을지의 체크리스트입니다.

에이전트 셀프 리뷰·리뷰 봇 Approve만으로 충분한가요?

충분하지 않습니다. 요약·누락 지적은 도움이 되지만, 의도·비밀·데이터·롤백은 사람(또는 CODEOWNERS) 책임으로 두는 편이 안전합니다.

로컬만 초록이고 CI가 없으면?

머지 전에 팀이 동의한 최소 명령을 PR에 적고 결과(통과/실패)를 남깁니다. CI가 없다면 그 공백 자체가 위험 신호이므로, 동작 변경 PR은 더 보수적으로 봅니다.

큰 포맷터 diff와 논리 변경이 섞이면?

리뷰 비용이 급증합니다. 포맷/생성물과 논리 변경을 PR에서 분리하라고 되돌리거나, 논리 파일만 먼저 리뷰하고 포맷은 후속 PR로 미룹니다.

출처 (Sources)

  • 팀 관행: PR Files / git diff --stat 우선, 위험 경로·테스트 증거·revert 가능성 — 본문 체크리스트
  • 인접 글 축: multi-agent-pr-workflow(브랜치·게이트), agent-tdd-loop(작성 중 red→green), git-worktree-agent(워킹트리 격리)