Claude Code First PR Review Rubric: 스타일보다 실제 위험을 먼저 찾기

rubric 없이 Claude Code 에 PR 리뷰를 맡기면 운영 회귀와 이름 변경 제안이 같은 무게로 나올 수 있습니다. 결과는 많아 보이지만 무엇이 merge 를 막아야 하는지 흐려집니다.

이 글은 첫 PR 리뷰 rubric 을 만듭니다. diff 를 읽히기 전에 P0~P3, 증거, 댓글 형식, 재시도 규칙을 정합니다.

함께 읽기: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. 공식 문서 기준: Anthropic Claude Code docs.

첫 명령 전에 정해야 하는 이유

스타일 피드백보다 회귀, 권한 위험, 데이터 손실, 테스트 부족을 먼저 찾기

첫 요청을 너무 크게 만들지 않는 것이 핵심입니다. 읽을 범위, 보호할 영역, 첫 행동, 검증 명령을 먼저 적어 두면 Claude Code 가 불필요한 수정으로 번지기 어렵습니다.

Claude Code 로 review 를 시작했지만 더 날카로운 지적이 필요한 개발자

실무에서 쓰는 흐름

1. diff 전에 목표와 변경 파일을 붙입니다
2. 리뷰 시작 전에 P0~P3를 정의합니다
3. 증거 없는 추측 댓글을 금지합니다
4. 테스트, build, 재현 proof 를 요구합니다
5. P3 스타일 메모는 마지막에 모읍니다

상황	Claude Code 에 맡길 일	사람이 확인할 증거
인증 PR	token 저장과 권한 경계를 P0로 먼저 봅니다	build, diff, URL
UI 수정	클릭 불가와 모바일 깨짐을 P1로 확인합니다	build, diff, URL
리팩터링	동작 유지 증거와 테스트 부족을 P2로 나눕니다	build, diff, URL

이 증거가 있으면 Claude Code 의 결과를 자신감 있는 완료 문장이 아니라 실제 작업 결과로 판단할 수 있습니다.

복사해서 쓰는 프롬프트와 코드

이 PR diff 를 P0/P1/P2/P3 심각도로 리뷰하세요. P0는 보안, 데이터 손실, 결제, 인증, 운영 장애입니다. 각 지적에는 줄, 실패 시나리오, 필요한 증거, 수정안을 포함하세요. 스타일만의 피드백은 마지막에 모으세요.

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

실제 예와 실패 사례

상황	Claude Code 에 맡길 일	사람이 확인할 증거
인증 PR	token 저장과 권한 경계를 P0로 먼저 봅니다	build, diff, URL
UI 수정	클릭 불가와 모바일 깨짐을 P1로 확인합니다	build, diff, URL
리팩터링	동작 유지 증거와 테스트 부족을 P2로 나눕니다	build, diff, URL

• 이름과 포맷을 먼저 보면 Claude Code 는 낮은 위험 지적으로 review 를 채웁니다.
• 심각도가 없으면 결제 버그와 문장부호가 같은 목록에 섞입니다.
• proof 를 요구하지 않으면 그럴듯하지만 검증 안 된 댓글이 늘어납니다.

첫 요청을 너무 크게 만들지 않는 것이 핵심입니다. 읽을 범위, 보호할 영역, 첫 행동, 검증 명령을 먼저 적어 두면 Claude Code 가 불필요한 수정으로 번지기 어렵습니다.

Proof Pack 으로 남길 것

스타일 피드백보다 회귀, 권한 위험, 데이터 손실, 테스트 부족을 먼저 찾기 는 한 번의 채팅으로 끝내기보다 proof pack 으로 남길 때 가치가 커집니다. 원래 요청, Claude Code 가 읽은 파일, 건드리지 않은 영역, 실행한 명령, public URL 이나 screenshot, 아직 애매한 판단을 짧게 기록합니다. 다음 세션은 같은 판단을 다시 만들지 않고 이어서 쓸 수 있습니다.

Claude Code 로 review 를 시작했지만 더 날카로운 지적이 필요한 개발자 는 첫날부터 무거운 운영 문서를 만들 필요가 없습니다. PR 하나, note 하나, deploy 하나에서 먼저 시도하세요. 실패하면 그 이유를 checklist 에 되돌리고 더 작은 버전으로 다시 실행합니다. build proof, diff review, URL check, CTA check, rollback owner 가 보인 뒤에 Claude Code 접근 범위를 넓히면 충분합니다. proof 없이 permission 만 넓히면 빨라 보이지만 검증 비용은 다음 사람에게 넘어갑니다.

수익 경로도 같은 원칙입니다. 기본 명령에서 막힌 독자는 무료 PDF 가 맞습니다. 같은 prompt 형태를 반복하는 독자는 Gumroad 가 도움이 됩니다. 팀이나 운영 결정을 해야 하는 독자는 상담이 더 적절합니다. 이 글은 모두를 구매로 밀어 넣는 글이 아니라, PR 리뷰 프롬프트와 재사용 가능한 기준 가 필요한 독자만 paid guide 로 보내고 나머지는 무료 PDF 와 관련 글로 돌려보내는 글입니다.

무료 PDF, Gumroad, 상담으로 연결하기

기본 명령이 아직 흐릿하다면 무료 치트시트 로 매일 쓰는 틀을 잡으세요. PR 리뷰 프롬프트와 재사용 가능한 기준 를 더 깊게 다루려면 Gumroad 교재 가 다음 단계입니다. 팀 도입, 리뷰 규칙, 수익 경로 설계가 필요하면 상담 으로 이동하고, 제품 비교는 products 에서 확인하세요.

CTA 는 글 맨 아래에만 둘 필요가 없습니다. 도입부에서는 무료 PDF, 구현 예시 뒤에서는 Gumroad 교재, 팀 도입이나 운영 리스크가 나오면 상담이 자연스러운 다음 단계입니다.

게시 후 볼 숫자

게시 후 이 review 글에서 Prompt Templates, 미래 Code Review System, 상담으로 가는 클릭을 봅니다.

PV 만 보지 말고 본문 초반 읽기, 내부 링크, 무료 PDF 등록, Gumroad 클릭, 상담 페이지 이동을 나누어 봅니다. HTTP 200, h1, canonical, heroImage, CTA, 현지화 본문이 같은 slug 를 가리켜야 합니다.