커뮤니케이션 잘 하기

1. Why?

Pennyway팀은 팀원들의 상황이 학생 / 취준생 / 인턴 등으로 다양했기에 팀 프로젝트 중 처음으로 비대면으로 진행한 프로젝트다. 물론 스프린트 계획 / 리뷰를 위해 각각 2시간씩 주 2회 만나긴 했지만, 이를 제외한 대부분의 시간을 각자 진행했다. 

 

그러다보니 다양한 시간대와 일정으로 인해 실시간으로 소통하기 어려운 경우가 많았고, 또 비대면으로 대부분의 소통을 진행하다 보니 서로의 의도를 오해하는 등 협업 과정에서 문제도 많이 발생했다. 이번 글에서는 정확히 어떤 문제들이 있었고, 이를 해결하기 위해 어떤 문화를 도입했는지 작성해보고자 한다.

---

2. 문제 & 해결

1. 코드 리뷰 관련

문제

• 우선 프로젝트가 시작되는 시점에서 함께 하는 팀원을 파악하지 못한 상태였기에, 큰 문제점이나 의문이 아니라면 코드 리뷰 작성을 망설이고 있었다. 반대로, 같이 하는 팀원은 비교적 단순한 부분(ReactNode와 JSX.Element의 차이와 같은)에도 적극적으로 질문을 작성하고 있었고, 나는 모든 리뷰에 답변하는 것에 압박감을 느끼고 있었다.
• 즉, 나는 모든 리뷰에 공들여서 답변하는 것에 지쳤고, 반대로 팀원은 내가 리뷰를 소극적으로 한다고 생각해 실망감을 느끼고 있는 상황이였다.

해결

이를 해결하고자 단계적 코드 리뷰 방식을 도입했다. 리뷰어는 P1부터 P5까지의 단계로 리뷰를 작성하고, 작성자는 각 단계에 알맞게 대응하는 방식이다. 각 단계는 다음과 같다.

• P1: 꼭 반영해주세요 (Request changes)
  • 리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 경우, P1 태그를 통해 반드시 수정해야 한다고 요청합니다.
  • 작성자는 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 이유를 제시하여 설득해야 합니다.
• P2: 적극적으로 고려해주세요 (Request changes) 
  • 작성자는 수정 요청에 대해서 적극적으로 고려하며, 수용하거나 적합한 의견을 통해 토론하여 리뷰어를 설득해야 합니다.
• P3: 웬만하면 반영해 주세요 (Comment)
  • 작성자는 P3에 대해 수용하거나, 수용할 수 없는 상황이라면 그 이유를 설명하거나, Issues 등록 혹은 Jira 티켓으로 반영할 계획을 명시적으로 표현해야 합니다.
• P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
  • 작성자는 반영하는 것을 고민해 보되, 무시해도 괜찮습니다.
• P5: 그냥 사소한 의견입니다 (Approve)
  • 무시해도 되는 간단한 의견입니다. 간단한 질문이나 칭찬의 경우 이 단계로 작성합니다.

그 결과 다음과 같은 긍정적인 효과를 얻을 수 있었다.

• 작성자
  • 정말로 논의가 필요한 문제라면 적극적으로 리소스를 투입할 수 있다
  • 반대로 프로덕트에 큰 영향이 가지 않는 단순한 질문의 경우에는 리소스 소모를 줄일 수 있다
• 리뷰어
  • 작성자에게 리뷰를 어떤 의도로 작성했는지 명확하게 전달할 수 있다.
  • 작성자가 리뷰를 오독할 확률이 낮아지기에, 적극적으로 리뷰를 작성할 수 있다.

2. 소통 방식 개선하기

문제

비대면으로 프로젝트를 진행하다보니, 동기적 소통으로 인한 문제가 발생했다. 동기적 소통의 예시를 들자면 이렇다. 

🙋‍♂️ 팀원 : 의찬님 질문이 있는데용

😳 나 : ( 뭐지... 무슨 일일까... 어느 정도 사이즈의 이슈일까... )
🤨 나 : 무슨 일이신가요...? (두려움)

🙋‍♂️ 팀원 : (작성 중...)

• 어떤 질문인지, 어느 정도의 리소스가 투입 될 일인지, 급한 일인지 전혀 알 수 없기에 스트레스를 받는다.
• 또한 질문의 의도를 파악하기 위해서는 팀원의 답변이 오기까지 기다려야 하기에 자신의 작업에 집중할 수 없고, 자연스럽게 생산성의 하락으로 이어지게 된다.

해결

이를 해결하고자 아래와 같이 비동기적 소통 방식을 적극적으로 권장했다. 비동기적 소통 방식은 아래와 같이 상대의 승낙을 받은 후 작성하는 것이 아니라 본론을 모두 전달한 후, 자신의 작업에 집중하는 방식이다.

• 물론 동기적 소통이 늘 나쁜 것만은 아니다. 즉각적으로 의견을 주고받으며 소통해야만 하는 핵심적인 부분이라면 동기적 소통이 더 나을 수 있다.

+ α. 오렌지 주스 테스트

추가적인 소통 방식 개선을 위해 오렌지 주스 테스트를 팀에 공유했다. 오렌지 주스 테스트는 어떤 질문/요청이 들어왔을 때, Yes 혹은 No로 답변하는 대신, `어떤 선택지가 있고, 각 선택지의 장단점은 이렇습니다.` 라는 방식으로 답변하는 것이다. 이를 통해서 

• 질문/요청이 들어왔을 때, 여러 옵션을 생각하고, Trade-off를 고려하며 답변하는 것을 권장하고자 했다. 
• 반대로 자신이 질문/요청을 할 때도 단순하게 `이런 부분이 안된다` 혹은 `이런 부분이 필요하다`라고 하기보다는 어떤 부분에서 문제가 발생했고, 문제 해결을 위해 어떤 시도를 해봤는지, 또는 왜 해당 부분이 필요한지 전달하는 것을 권장하기 위해서 공유했다.

3. 문서를 통해 소통하기

문제

프로덕트를 만들어나가는 과정에서 다른 개발팀과 지속적으로 소통을 해야 했다. 상세한 사항은 다음과 같다.

• Backend팀 - API 설계 관련 논의
• iOS팀의 - WebView 로직과 관련된 논의

이 과정에서 상대적으로 본인 팀의 개발보다 상대방 팀에 대한 이해도가 떨어질 수 밖에 없다. 이로 인해 지속적으로 리소스가 소모되어 이를 해결하고자 했다.

해결

Github Wiki를 통해 상세하게 문서화를 하고, 이를 참조해서 소통하여 문제를 해결했다.

• API 설계의 경우 우리 Web Frontend 팀에서 주도적으로 API를 설계
  • 이후 이를 Github Wiki에 정리해 이를 기반으로 Backend팀과 소통하며 API 설계를 구체화
• WebView 관련 로직(WebView 시나리오, Token 시나리오 등)을 작성

이 외에도 Github Wiki에 Code Convention과 Commit Convention, Branch 전략 등을 추가로 작성해서 팀 내 개발 컨벤션도 착실하게 정리했다.

---

3. 래퍼런스

• 코드 리뷰 in 뱅크샐러드 개발 문화
• How GitHub Engineering communicates
• Github 엔지니어처럼 커뮤니케이션하는법
• 오렌지 주스 테스트 - 항상 대안을 제시하라