개발자로 살아남기 Chapter 1.8. 코드리뷰, 협업, 커뮤니케이션의 기술

📘 Chapter 1.8: 코드리뷰, 협업, 커뮤니케이션의 기술

---

🧠 Intro – 코드만 잘 짜면 끝일까?

아니다. 절대 아니다.

실력 좋은데도 팀에서 인정 못 받고 도태되는 사람들 특징이 뭔 줄 아나?

• 말 한마디로 팀 분위기 박살 내고
• 코드리뷰에서 꼰대처럼 굴고
• 본인만 이해하는 방식으로 일하고

"내가 코드는 잘 짜는데 왜 이렇게 일이 힘들지?"
→ 그건 실력이 아니라 커뮤니케이션이 부족해서다.

---

📌 코드리뷰 – 기술보다 사람이 중요하다

✅ 코드리뷰, 그거 "틀린 걸 찾기" 아니고 "같이 맞추기"다

후배가 올린 PR을 봤다고 치자:

if(user.Type == "Admin") {
    DoSomething();
}

이걸 보고 바로 이렇게 쓰면?

❌ "이런 식으로 하시면 곤란합니다. 상수도 안 빼고, 이거 뭐하는 코드죠?"

➡ 이건 비판이지 리뷰가 아니다.

👍 이렇게 쓰자:

✅ "user.Type 값은 enum이나 상수로 분리하면 유지보수가 편할 것 같아요. 어떻게 생각하세요?"

📢 리뷰는 상대를 이기려고 하는 자리가 아니라, 같이 성장하는 시간이다.

✅ 리뷰할 때는 질문형이 기본

• ❌ "이 코드 왜 이렇게 짰어요?"
• ✅ "이 부분에서 enum 고려는 안 해보셨나요?"
• ❌ "이렇게 하면 안 되죠"
• ✅ "혹시 이런 방향도 생각해보셨나요?"

💬 말투 하나로 상대가 수용적으로도, 방어적으로도 변한다.

---

🤝 협업 – 좋은 팀은 절대 혼자 만든 게 아니다

✅ "니 혼자 잘하면 뭐하노?"

협업은 속도가 아니라 방향 맞추기다.

아무리 코드 잘 짜도:

• 회의 안 따라오고
• 공유도 안 하고
• 문서도 안 남기면

그건 팀플에서 혼자 조별과제 하는 놈이다.

🛠 실전 예시 – 요구사항 공유 빠뜨렸을 때

• 회의 때 정해진 조건: "로그인 실패 시 3회 이상이면 락 걸기"
• 니 혼자만 알고 개발하고, 릴리즈 때 팀장이 이렇게 묻는다:

🧓 "어? 이거 원래 기획에 없었는데?"

👉 팀 전체가 난감해진다.

📌 공유는 "나만 알고 있으면 위험한 지점"을 줄이는 일이다.

---

💬 커뮤니케이션 – 팀에 안전한 분위기 만드는 기술

✅ 갈등 피하지 말고, 피드백 기술을 키워라

개발 중에 이런 상황 많지?

• 누가 무리한 일정을 잡음
• 코드 스타일이 달라 충돌
• 테스트 누락돼서 QA 팀에서 빡침

이럴 때 "에이 그냥 넘어가자" 이러면 안 된다.

갈등은 피하는 게 아니라 건설적으로 해결하는 기술이 필요하다.

✅ 심리적 안전감 = 팀 생산성

• 실수해도 탓하지 않고
• 질문해도 무시 안 하고
• "몰라요"라고 말할 수 있는 분위기

이게 되어야:

• 문제를 빨리 찾고
• 개선 아이디어가 생기고
• 서로가 서로를 보완하게 된다

---

💡 실전 팁 모음

상황	피드백 예시
리뷰할 때	"이 부분은 유지보수를 생각하면 이런 방식도 괜찮을 것 같아요!"
일정 산정 시	"이 부분은 좀 더 여유 있게 잡아야 테스트 시간 확보돼요."
갈등 상황	"지금 이건 좀 감정 섞인 것 같은데, 우리 해결책 위주로 얘기해볼까요?"
질문 받았을 때	"좋은 질문이에요. 이건 문서화해두면 다른 사람도 도움될 것 같네요."

---

✅ 마무리

팀은 결국 사람과 사람이 함께 일하는 공간이다.

코드보다 중요한 건 말 한마디, 피드백 하나, 협업 태도다.

잘 소통하는 개발자는 기술보다 더 강력한 무기를 갖고 있다.

---

📢 다음 챕터 예고

Chapter 1.9 – 개발자로 10년, 20년 일하려면?