2nd/10_Wiki/Topics_Dev/Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션).md

# [[Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션)|Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션]]

## 📌 Brief Summary
코드 리뷰 에티켓 및 커뮤니케이션은 리뷰어와 작성자 간의 상호 존중과 협력을 바탕으로 건설적인 피드백을 주고받기 위한 행동 규범입니다 [1]. 이는 단순한 결함 발견을 넘어 팀 내 심리적 안전감을 형성하고 지식 공유를 촉진하며, 시스템의 장기적인 건전성을 유지하는 데 기여합니다 [4]. 명확한 의도 전달, 객관적인 언어 사용, 긍정적인 피드백의 균형을 통해 불필요한 감정 소모 없이 효율적으로 코드 품질을 높이는 것을 핵심 목표로 합니다.

## 📖 Core Content
*   **사람이 아닌 코드에 집중 (Egoless Programming):** 피드백은 작성자의 능력이 아닌 '코드(사물)' 자체에 집중해야 합니다 [1, 5]. "당신이 실수했다"는 공격적 표현 대신 "이 코드는 ~한 잠재적 위험이 있다"는 객관적 사실이나, "제 관점에서는 ~로 이해됩니다"와 같은 **'I-메시지(나 전달법)'**를 사용하여 방어적 태도를 방지합니다 [5, 8]. 개발자 스스로도 "나는 내 코드와 동일시되지 않는다(You are not your code)"는 겸손한 마음가짐이 필요합니다 [10].
*   **지시 대신 질문과 제안 활용:** 명령조보다는 "~하는 것이 어떨까요?" 또는 "이 로직의 의도가 무엇인가요?"와 같은 질문 형태로 피드백을 전달하여 작성자의 자율성을 존중합니다 [5, 12]. 지적 시에는 반드시 명확한 이유(Why)와 함께 구체적인 대안을 제시해야 합니다 [4, 16].
*   **컨벤셔널 코멘트(Conventional Comments) 적용:** 피드백의 의도와 심각성을 접두사로 명시하여 소통의 모호성을 제거합니다 [18, 21].
    *   `praise:` 잘 작성된 코드에 대한 칭찬 (긍정적 문화 조성) [30].
    *   `nit:` 사소한 스타일 수정 제안 (비차단적, Non-blocking) [21, 37].
    *   `suggestion:` 코드 개선 제안.
    *   `issue:` 반드시 수정이 필요한 결함 (차단적, Blocking).
    *   `question:` 의도 파악을 위한 질문.
*   **OIR 규칙 기반 피드백:** **관찰(Observation)**된 현상, 그로 인한 **영향(Impact)**, 그리고 개선 **요청(Request)**의 구조를 따라 논리적이고 비감정적인 피드백을 구성합니다 [38].
*   **텍스트 소통의 한계 극복:** 코멘트 핑퐁이 3~4회 이상 지속되어 교착 상태에 빠진다면 즉시 화상 회의나 대면 대화로 전환하여 오해를 풀고, 합의된 내용을 다시 문서화합니다 [32, 35].

## ⚖️ Trade-offs & Caveats
*   **완곡어법 vs 명확성:** 심리적 안전감을 위해 너무 우회적으로 표현하는 '피드백 샌드위치'는 자칫 중요한 수정 요구 사항을 흐릴 수 있습니다 [44]. 친절함을 유지하되 필수적인 보안/기능 결함은 단호하고 투명하게 전달해야 합니다 [47].
*   **니트피킹(Nitpicking)의 부작용:** 사소한 컨벤션 지적에 집착하면 리뷰 속도가 저하되고 팀원이 지칠 수 있습니다 [29, 50]. 스타일 검증은 Linter 등 자동화 도구에 전적으로 위임하고 사람은 중요한 로직에 집중해야 합니다 [55].
*   **주관적 취향 강요 경계:** 설계에는 여러 정답이 있을 수 있습니다. 자신의 선호를 '표준'으로 강요하기보다, 작성자의 방식이 시스템 건강을 해치지 않는다면 그 선택을 존중해야 합니다 [58, 61].

## 🔗 Knowledge Connections

### Related Concepts
*   **[[심리적 안전감 (Psychological Safety)|심리적 안전감(Psychological Safety]]**: 비판이 아닌 개선을 위한 협업임을 신뢰하는 효과적인 리뷰의 심리적 토대입니다.
*   **IKEA 효과(IKEA Effect**: 작성자가 자신의 코드에 과도한 가치를 부여하여 피드백을 방어적으로 받아들이게 되는 인지 편향입니다.
*   **Conventional Comments**: 피드백 라벨링을 통해 소통 마찰을 줄이는 구체적인 시스템 프레임워크입니다.
*   **Egoless Programming**: 개인의 자존심보다 팀의 코드 품질을 최우선으로 생각하는 개발 철학입니다.

### Deeper Research Questions
*   비동기 텍스트 리뷰에서 발생할 수 있는 '톤(Tone)의 오해'를 AI가 감지하여 더 부드러운 표현으로 수정을 제안해주는 도구의 효용성은 어느 정도인가?
*   문화적/언어적 배경이 다양한 글로벌 팀에서 'I-메시지'와 'Conventional Comments'가 실제 협업 효율에 미치는 영향은 어떻게 다른가?
*   주니어 개발자가 시니어의 'Nitpick' 피드백을 단순 지적이 아닌 학습 기회로 인지하게 만드는 가장 효과적인 멘토링 기법은 무엇인가?
*   '주관적 취향'과 '아키텍처적 일관성' 사이의 경계가 모호할 때, 소모적 논쟁 없이 빠르게 합의를 도출하는 의사결정 프로세스는 어떻게 설계하는가?
*   AI 생성 코드에 대해 인간이 피드백을 남길 때도 동일한 커뮤니케이션 에티켓을 적용하는 것이 팀의 코드 소유권 의식 유지에 도움이 되는가?

### Practical Application Contexts
*   **Implementation:** PR 코멘트 작성 시 반드시 접두사(`nit:`, `issue:`, `praise:`)를 사용하도록 가이드라인을 설정합니다.
*   **System Design:** PR 템플릿에 '자동화 테스트 통과' 항목을 필수화하여, 스타일 논쟁을 차단하고 비즈니스 로직 중심의 리뷰 환경을 설계합니다.
*   **Operation / Maintenance:** 스프린트 회고 시 리뷰 중 발생한 소통 마찰 사례를 분석하여 팀의 '리뷰 그라운드 룰(Ground Rules)'을 지속적으로 보강합니다.
*   **Learning Path:** 온보딩 시 "당신은 당신의 코드와 동일시되지 않는다"는 원칙을 교육하여 피드백 수용도를 높입니다.
*   **My Project Relevance:** 댓글 스레드가 길어지면 "10분만 대화하시죠"라고 제안하여 감정적 핑퐁을 끊고 문제를 신속히 해결합니다.

### Adjacent Topics
*   **Automated Static Analysis & Linters**: 인간 간의 스타일 논쟁을 근본적으로 제거하기 위한 자동화 도구 체계입니다.
*   **Pair Programming**: 소통 지연과 오해를 실시간 대화로 즉시 해소하는 동기식 협업 방식입니다.

---
*Last updated: 2026-05-02*