code-reviewlisted

# Code Review · 버그 진단 + diff/브랜치 리뷰 방법론 > ★**왜 빌트인인가 — 파리티다** (2026-08-30 사용자 결정). 이 스킬엔 tiguclaw 고유 지식이 거의 > 없다(실측: 160줄 중 2건, 그마저 *"어댑터 무관"* 이라는 면책 문구다). 그래서 *"일반적인 > 방법론이니 빼도 되지 않나"* 로 읽히기 쉬운데 **반대다** — Claude Code 가 코드 리뷰를 > 빌트인으로 주므로, 없으면 **1번 원칙(슈퍼셋)의 누락 = 버그**다. > > 즉 빌트인 자격은 축이 **둘**이다: ①tiguclaw 고유 지식을 담거나 ②Claude Code 파리티. > 이건 ②다. 고유 밀도로만 재면 틀린 결론이 나온다 — 실제로 한 번 그랬다. 두 겹으로 동작한다. **아래 §A 방법론(발견의 *질*)은 항상 적용**되고, **§B 워크플로우(리뷰의 *범위·강도*)는 요청에 맞춰 선택**한다. 간결함을 유지하되 correctness 는 절대 놓치지 않는다. --- ## A. 발견 방법론 (모든 발견이 통과해야 하는 질 기준 — 절대 보존) 솔로든 팬아웃이든, 리뷰 차원 서브든, 각 발견은 아래를 만족해야 한다. ### A1. 근본 원인 진단 (증상 아닌 원인) - 증상("모드가 Normal 로 나감")이 아니라 **왜 그 값이 그렇게 되는지 메커니즘**을 짚는다. 생성·전달·소비 지점을 추적해 *실제 원인*을 특정한다. - "여기서 채워지고 → 저기서 재계산되어 → 값이 섞인다" 처럼 **경로**로 설명한다. 추측 금지 — 코드를 읽고 확정한다. ### A2. ★확장 점검 (correctness — 항상 한다) - **같은 근본 원인이 인접한 필드·경로·호출부에도 있는지 반드시 확인한다.** 하나만 고치고 형제 버그를 남기지 마라. - 예: `GameMode` 가 "종료 시점 재계산"이라 stale 이면 — **같은 방식으로 채워지는 `Round`·`Level` 도 stale 아닌가?** 를 반드시 본다. - 체크리스트: "이 값이 잘못됐다면, *같은 패턴으로 만들어지는 다른 값들*도 같은 함정에 빠지지 않나?" — 명시적으로 훑는다. 취향이 아니라 **정확성**이다. ★위가 *값*을 따라가는 축이라면, 아래는 *변경*을 따라가는 축이다. **2차 결함은 대부분 여기서 난다 — A를 바꾸고 A에 의존하던 B를 안 본 것.** 수정을 제안·검토할 때 「무엇을 바꿨나」에서 「무엇을 다시 봐야 하나」가 자동으로 따라 나와야 한다: | 바꾼 것 | **전수**로 다시 봐야 하는 것 | |---|---| | **계약** — 시그니처·반환값·throw 여부·에러 타입 | 그 함수의 **호출부 전부**. 특히 반환을 안 쓰던 곳, `try` 로 안 감싼 곳(안 던지던 게 던지기 시작하면 그 경로가 죽는다) | | **조건을 반전·확대**했다 | 그 조건에 **도달하는 입력 전부**. ★파급이 가장 크다 — 조건이 바뀌면 거기 들어오던 *모든 것의 의미*가 같이 바뀐다 | | **새 값**을 만들었다 —