code-review-feedback-handler

name	code-review-feedback-handler
description	코드 리뷰 코멘트/피드백을 받아 수용·부분 수용·거절로 분류하고, 최신 코드/호출 관계/사양/문서를 근거로 비판적으로 타당성을 검증한 뒤, 수용된 변경만 구현하고 최종 보고서를 작성한다. PR 리뷰 반영, 리뷰 코멘트 처리, 리팩토링 제안 검증/적용 요청에 사용한다.

코드 리뷰 피드백 처리(검토 + 적용)

목표

• 리뷰 코멘트를 “변경하지 않는 것이 기본”이라는 보수적 원칙으로 검토하고, 명백한 이득이 있는 변경만 반영한다.
• 단기 편의보다 장기적 유지보수성/확장성/안정성을 우선하고, 단순 취향 제안은 거절한다.

입력(권장)

• 리뷰 코멘트 목록(COMMENT): 각 항목에 원문, 파일/라인(또는 스니펫), 배경(왜 문제인지), 원하는 결과를 포함한다.
• 정보가 부족하면 구현/리팩토링부터 하지 말고, 먼저 필요한 질문을 한다.

워크플로(필수)

1. 코멘트 분석: 핵심 주장/제안/의도, 기대 효과, 전제(가정)를 분리해 요약한다.
2. 자율 코드 조사: 언급된 파일/라인을 기준으로 최신 코드를 직접 확인하고, 호출 관계/주변 맥락/테스트 영향 범위를 함께 조사한다.
3. 사양 및 문서 검토(필수): 변경 대상 기능과 관련된 문서를 우선 확인한다.
   • docs/specs/ 관련 사양서
   • docs/ 내 아키텍처/설계 문서
   • (존재 시) PROJECT.md, AGENTS.md
4. 비판적 타당성 검증: 아래 “판정 기준”으로 수용/부분 수용/거절을 결정한다.
5. 작업 진행(수용/부분 수용): 테스트 우선(가능한 범위)으로 최소 변경을 적용하고, SRP/Result/DRY/YAGNI를 준수한다. 사양에 영향이 있으면 사양을 먼저/함께 갱신한다.
6. 최종 보고 작성: references/final-report-template.md 형식으로 결과를 정리한다.

판정 기준

수용(Accept)

• 사양/아키텍처와 정합하며, 장기적 건강(Long-term Health) 또는 **실질적 가치(Practical Value)**가 명백하다.
• 리스크 대비 이득이 크고, 회귀 가능성을 테스트/근거로 통제할 수 있다.

부분 수용(Partial Accept)

• 문제 제기 자체는 타당하나, 제시된 해결책이 최선이 아니거나 범위/타이밍이 부적절하다.
• 핵심 의도는 반영하되, 더 안전/단순한 대안으로 조정하거나 단계적으로 적용한다.

거절(Reject)

• 사양 위반, 기술적 근거 부족, 비용 대비 이득 불분명, 단순 취향/스타일, 또는 현재 코드/사양에 대한 오해가 있다.

작업 원칙(요약)

• “리팩토링 자체”가 목표가 되지 않게 하고, 변경의 목표/효과/리스크를 문서화한다.
• 큰 변경은 작은 PR/단계로 쪼개고, 불확실하면 측정(벤치/프로파일/실험)으로 근거를 확보한다.
• 예외/실패는 가능하면 Result 패턴으로 제어하고, 숨은 사이드이펙트를 늘리는 분기/하드코딩/복붙은 피한다.

참고

• 최종 보고서 템플릿: references/final-report-template.md