code-reviewlisted

# 코드 리뷰 > 원칙: **지적은 재현 가능한 근거와 함께.** "별로예요"가 아니라 "이 입력이면 이렇게 깨진다". ## 절차 1. **전체 범위를 본다**: `git diff <base>...HEAD` — 최신 커밋만 보지 않는다. 2. 관점 순서��로 훑는다 (심각한 것부터): - **정확��**: 이 diff 로 깨지는 입력·상태가 있는가. 경계값·None·빈 목록. - **보안**: 입력이 셸/SQL/경로/역직렬화에 닿는가. 시크릿이 코드·로그에 박히는가. - **회귀**: 기존 호출자가 이 변경으로 달라지는가. 테스트가 그 경로를 덮는가. - **단순화**: 같은 일을 더 적은 코드로 할 수 있는가 (기존 유틸 재사용 포함). - **일관성**: 이 레포의 관례(네이밍·에러 처리·주석 밀도)와 어긋나는가. 3. 각 지적은 `파일:줄 — [심각도] 주장. 실패 시나리오.` 형식으로 쓴다. 심각도: **blocker**(사고·데이터 손실) / **should**(머지 전 수정) / **nit**(취향, 무시 가능). ## 규칙 - **직접 고치지 않는다** — 리뷰 요청은 수정 요청이 아니다. 수정까지 원하는지 확인 후 진행. - 지적이 없으면 없다고 말한다. 채우기용 nit 를 만들지 않는다. - 확신 없는 지적은 질문으로 바꾼다: "X 인 경우가 가능한가요?" - blocker/should 가 하나라도 있으면 결론을 "머지 보류"로 명시한다. ## 내 작업을 리뷰받을 때 - **신선한 컨텍스트로 시킨다.** 작업한 대화 히스토리를 준 리뷰어는 내 가정을 물려받는다 — diff(`BASE..HEAD`)와 요구사항만 주고 리뷰시킨다. 이 번들의 `reviewer` 서브에이전트가 정확히 이 용도다(Claude Code: `.claude/agents/reviewer`). - 받은 피드백은 심각도대로: blocker 는 즉시, should 는 다음 진행 전에 고치고, 리뷰어가 틀렸다고 판단되면 무시하지 말고 **근거와 함께 반박**한다. > 참고: [obra/superpowers](https://github.com/obra/superpowers) 의 requesting-code-review 에서 > "신선한 컨텍스트 리뷰" 원칙을 가져왔다.