Source: Dev.to

---

코드 리뷰 코멘트를 무례하게 들리지 않게 쓰는 방법

코드 리뷰는 팀의 코드 품질을 높이고, 개발자들이 서로 배우는 중요한 과정입니다. 하지만 같은 내용이라도 표현 방식에 따라 협업 분위기를 해치거나 불필요한 갈등을 일으킬 수 있습니다. 아래에서는 친절하고 건설적인 리뷰 코멘트를 작성하기 위한 실전 팁을 정리했습니다.

---

1. 긍정적인 시작으로 분위기 잡기

예시
“좋은 시도네요! 특히 이 부분은 가독성이 뛰어나요.”

• 왜 중요한가?
  • 긍정적인 피드백은 방어적인 반응을 줄이고, 개선 제안을 더 수용하게 만듭니다.
• 팁
  • 코드의 특정 장점을 짚어 주세요. “전체적인 구조는 깔끔하지만…”처럼 구체적으로 말하면 더 효과적입니다.

---

2. “I” 혹은 “We” 문장으로 의견 제시

• 핵심: 비난이 아니라 관점 공유라는 느낌을 줍니다.

---

3. 질문 형태로 제안하기

예시
“이 로직을 이렇게 바꾸면 성능이 더 좋아질까요?”

• 왜 좋은가?
  • 질문은 상대에게 선택권을 주고, 토론을 촉진합니다.
• 사용법
  • “~하면 어떨까요?” 혹은 “~에 대해 생각해 보셨나요?” 같은 문구를 활용합니다.

---

4. 구체적이고 명확하게

• 좋은 예시

  - const x = a + b;
  + const total = a + b; // 변수명을 더 의미 있게 바꿨습니다.

• 나쁜 예시
  • “이 변수 이름이 별로예요.” → 왜 별로인지, 어떤 이름이 더 나을지 제시합니다.

---

5. 작은 개선점은 “Suggestion” 형태로

예시
“가능하면 eslint 규칙을 적용해 보세요. 이렇게 하면 자동 포맷팅이 쉬워집니다.”

• 핵심: “필수”가 아니라 “추천”이라는 뉘앙스를 줍니다.

---

6. 감정 표현은 피하고, 객관적인 근거 제시

• 피해야 할 표현
  • “이건 바보 같은 코드야.”
• 대신
  • “이 부분은 테스트 커버리지가 낮아 보입니다. 추가 테스트를 고려해 보세요.”

---

7. 이모지와 마크다운 활용 (적당히)

• ✅, ❓, 🚀 같은 이모지는 톤을 부드럽게 만들고, 포인트를 강조합니다.
• 하지만 과도하게 사용하면 전문성이 떨어질 수 있으니, 핵심 포인트에만 사용하세요.

---

8. 마무리는 긍정적인 요약

예시
“전체적으로 구조가 깔끔하고, 함수 이름도 직관적이에요. 위에서 언급한 몇 가지 작은 개선점만 적용하면 완벽합니다!”

• 효과: 리뷰를 받는 사람이 성취감을 느끼고, 다음 리뷰에도 적극적으로 참여하게 됩니다.

---

9. 팀 문화에 맞는 가이드라인 만들기

• 팀 내 공통된 리뷰 규칙을 문서화하면, 모두가 같은 기대치를 갖게 됩니다.
• 예시 항목:
  1. 톤 – 친절하고 건설적인 언어 사용
  2. 형식 – 마크다운, 이모지 사용 규칙
  3. 우선순위 – 버그, 보안, 성능 → 스타일, 리팩터링

---

10. 연습은 완벽을 만든다

• 처음엔 어색할 수 있지만, 피드백을 주고받으며 점점 자연스러워집니다.
• 서로의 리뷰를 리뷰해 보는 세션을 정기적으로 열어보세요.

---

요약

코드 리뷰는 협업의 핵심입니다. 위 원칙들을 적용하면, 팀원 간 신뢰를 쌓고, 코드 품질을 높이며, 동시에 건전한 커뮤니케이션을 유지할 수 있습니다. Happy reviewing!

한 단어가 만드는 차이

❌ “이것은 틀렸어요.”
✅ “제가 보기엔 이것이 문제를 일으킬 수 있을 것 같은데 …”

두 문장은 같은 메시지를 전달하지만, 두 번째는 판단적이라기보다 대화식으로 느껴집니다.

5가지 거친 표현 패턴 (그리고 대신 사용할 말)

1. “You should …”

명령처럼 들립니다.

• ❌ “You should use a constant here.”
• ✅ “What do you think about using a constant here?”
• ✅ “Have you considered using a constant here?”

왜 효과적인가: 질문은 토론을 유도하고, 명령은 대화를 차단합니다.

2. “Why did you …?”

심문처럼 들립니다.

• ❌ “Why did you use a for loop here?”
• ✅ “I’m curious about the for loop—was there a specific reason you chose it over map?”
• ✅ “Just wondering—is there an advantage to the for‑loop approach here?”

왜 효과적인가: “I’m curious”는 판단이 아닌 진정한 관심을 보여줍니다.

3. “This doesn’t make sense.”

작성자가 혼란스럽거나 어리석다고 암시합니다.

• ❌ “This logic doesn’t make sense.”
• ✅ “I’m having trouble following this logic—could you walk me through it?”
• ✅ “I might be missing something, but I’m not sure how this handles the edge case.”

왜 효과적인가: 이해하지 못한 책임을 자신에게 돌려 겸손함을 나타냅니다.

4. “Just do X.”

“Just”가 요청을 사소하거나 무시하는 듯하게 만들어요.

• ❌ “Just add error handling.”
• ✅ “It would be great to add some error handling here.”
• ✅ “Could we add error handling for the null case?”

왜 효과적인가: 무시하는 어조를 없애고 노력에 대한 인정을 보여줍니다.

5. “This is inefficient / bad / wrong.”

라벨은 개인에게 직접적인 비난처럼 느껴집니다(코드라도 마찬가지).

• ❌ “This approach is inefficient.”
• ✅ “I wonder if we could improve performance here by …”
• ✅ “This works, but I’m thinking we might hit performance issues at scale. What if we tried …?”

왜 효과적인가: 코드가 작동한다는 점을 인정한 뒤 개선을 제안합니다.

마법 문구

직접적인 표현이 필요할 때

모든 댓글이 부드럽게 할 필요는 없습니다. 다음과 같은 경우에 직접적으로 말하세요:

• 명확한 버그가 있을 때 – “This will throw a null‑pointer exception on line 42.”
• 보안 문제가 있을 때 – “This exposes the API key. Let’s move it to environment variables.”
• 단순한 사실일 때 – “This function is missing a return statement.”

사실은 완충이 필요 없고, 의견은 필요합니다.

문화적 메모

일부 문화에서는 직접적인 표현이 존경과 정직의 표시로 여겨집니다. 영어‑권 직업 환경에서는 간접적인 표현이 상대방의 판단을 존중한다는 의미로 더 존중받는 경우가 많습니다. 어느 접근법도 본질적으로 옳거나 그른 것은 아니지만, 국제 팀을 위해 영어로 글을 쓸 때는 약간의 부드러움이 큰 도움이 됩니다.

빠른 연습

다음 문장을 부드러운 어조(또는 댓글처럼)로 다시 작성하세요:

• “이 변수의 이름을 바꾸는 것이 좋겠어요.”
• “이 함수가 좀 길어요.”
• “콜백 대신 async/await을 사용하시는 이유가 궁금합니다?”

이 기사에서의 어휘

당신의 차례

지금까지 받은 최악의 코드‑리뷰 댓글은 무엇인가요?
또는 최고의 댓글—기분 나쁘게 만들지 않으면서도 뭔가를 가르쳐 준 댓글은?

댓글에 공유해 주세요. 서로에게 배울 수 있도록요.