코드 리뷰 피드백 처리(검토 + 적용)
목표
- •리뷰 코멘트를 “변경하지 않는 것이 기본”이라는 보수적 원칙으로 검토하고, 명백한 이득이 있는 변경만 반영한다.
- •단기 편의보다 장기적 유지보수성/확장성/안정성을 우선하고, 단순 취향 제안은 거절한다.
입력(권장)
- •리뷰 코멘트 목록(COMMENT): 각 항목에 원문, 파일/라인(또는 스니펫), 배경(왜 문제인지), 원하는 결과를 포함한다.
- •정보가 부족하면 구현/리팩토링부터 하지 말고, 먼저 필요한 질문을 한다.
워크플로(필수)
- •코멘트 분석: 핵심 주장/제안/의도, 기대 효과, 전제(가정)를 분리해 요약한다.
- •자율 코드 조사: 언급된 파일/라인을 기준으로 최신 코드를 직접 확인하고, 호출 관계/주변 맥락/테스트 영향 범위를 함께 조사한다.
- •사양 및 문서 검토(필수): 변경 대상 기능과 관련된 문서를 우선 확인한다.
- •
docs/specs/관련 사양서 - •
docs/내 아키텍처/설계 문서 - •(존재 시)
PROJECT.md,AGENTS.md
- •
- •비판적 타당성 검증: 아래 “판정 기준”으로 수용/부분 수용/거절을 결정한다.
- •작업 진행(수용/부분 수용): 테스트 우선(가능한 범위)으로 최소 변경을 적용하고, SRP/Result/DRY/YAGNI를 준수한다. 사양에 영향이 있으면 사양을 먼저/함께 갱신한다.
- •최종 보고 작성:
references/final-report-template.md형식으로 결과를 정리한다.
판정 기준
수용(Accept)
- •사양/아키텍처와 정합하며, 장기적 건강(Long-term Health) 또는 **실질적 가치(Practical Value)**가 명백하다.
- •리스크 대비 이득이 크고, 회귀 가능성을 테스트/근거로 통제할 수 있다.
부분 수용(Partial Accept)
- •문제 제기 자체는 타당하나, 제시된 해결책이 최선이 아니거나 범위/타이밍이 부적절하다.
- •핵심 의도는 반영하되, 더 안전/단순한 대안으로 조정하거나 단계적으로 적용한다.
거절(Reject)
- •사양 위반, 기술적 근거 부족, 비용 대비 이득 불분명, 단순 취향/스타일, 또는 현재 코드/사양에 대한 오해가 있다.
작업 원칙(요약)
- •“리팩토링 자체”가 목표가 되지 않게 하고, 변경의 목표/효과/리스크를 문서화한다.
- •큰 변경은 작은 PR/단계로 쪼개고, 불확실하면 측정(벤치/프로파일/실험)으로 근거를 확보한다.
- •예외/실패는 가능하면 Result 패턴으로 제어하고, 숨은 사이드이펙트를 늘리는 분기/하드코딩/복붙은 피한다.
참고
- •최종 보고서 템플릿:
references/final-report-template.md