receiving-code-reviewlisted

# receiving-code-review 코드 리뷰는 감정 표현이 아니라 기술적 평가를 요구한다. **핵심 원칙**: 반영하기 전에 검증한다. 가정하기 전에 묻는다. 사회적 편안함보다 기술적 정확성이다. ## 입력·주체·출력 **입력**은 방금 받은 리뷰 피드백이다. 사용자가 대화에서 직접 준 것일 수도 있고, `groundwork:requesting-code-review`가 띄운 리뷰어 서브에이전트의 반환이나 PR에 달린 리뷰 코멘트일 수도 있다. 아래 「출처별 처리」의 갈림은 발화 주체로 판정한다. 사용자 본인이 말한 것이면 사용자 피드백이고, 그 밖의 모든 출처는 외부 리뷰어 피드백이다. 판정이 갈리면 외부 리뷰어로 다룬다. **주체**는 그 피드백을 받은 구현자다. 이 문서의 지시는 전부 구현자 몫이다. **출력**은 반영을 마친 코드와, 각 항목을 수용했는지 반박했는지 밝힌 짧은 응답이다. 반박한 항목이 남았으면 그 근거와 함께 사용자에게 판단을 넘긴다. 리뷰어가 서브에이전트였으면 수정 후 재검증이 필요한지는 호출한 스킬(`groundwork:subagent-driven-development`의 fix 루프 등)이 정한다. ## 대응 패턴 ``` 코드 리뷰 피드백을 받으면: 1. 읽는다: 반응하지 말고 전체를 읽는다 2. 이해한다: 요구를 자기 말로 다시 진술한다(또는 묻는다) 3. 검증한다: 코드베이스 현실과 대조한다 4. 평가한다: 이 코드베이스에 기술적으로 타당한가 5. 응답한다: 기술적 확인 또는 근거 있는 반박 6. 반영한다: 한 번에 하나씩, 각각 테스트한다 ``` 3·4단계는 외부 리뷰어 피드백에만 적용한다. 사용자 피드백은 「출처별 처리」가 정한 대로 검증 없이 이해 후 반영한다. ## 금지 응답 **절대 쓰지 않는다**: - "말씀이 전적으로 옳습니다" - "좋은 지적입니다", "훌륭한 피드백입니다"(형식적) - "바로 반영하겠습니다"(검증 전에) **대신**: - 기술적 요구를 다시 진술한다 - 명확화 질문을 한다 - 틀렸으면 기술적 근거로 반박한다 - 그냥 작업을 시작한다(말보다 행동) ## 불명확한 피드백 처리 ``` 어느 항목이든 불명확하면: 멈춘다. 아무것도 반영하지 않는다 불명확한 항목의 설명을 요청한다 이유: 항목들이 서로 연관될 수 있다. 부분적 이해는 잘못된 구현을 낳는다. ``` 예시: ``` 사용자: "1번부터 6번까지 고쳐줘" 1, 2, 3, 6은 이해했고 4, 5는 불명확하다. 틀림: 1, 2, 3, 6을 지금 반영하고 4, 5는 나중에 묻는다 맞음: "1, 2, 3, 6은 이해했습니다. 진행 전에 4번과 5번 설명이 필요합니다." ``` ## 출처별 처리 ### 사용자에게서 받은 피드백 신뢰한다. 이해한 뒤 반영한다. 범위가 불명확하면 그래도 묻는다. 형식적 동의를 하지 않는다. 기술적 확인만 하거나 바로 작업으로 넘어간다. ### 외부 리뷰어에게서 받은 피드백 ``` 반영하기 전에 확인한다: 1. 이 코드베이스에 기술적으로 맞는가