[우테코] 장바구니 협업 미션 회고: 협업을 잘 하기 위한 노력

💋 소통이 잘 되고, 문서화를 잘 하는 팀원

 

아직 내가 어떤 개발자가 되고 싶다는 뚜렷한 목표는 없다!

늘 팀에 기여하는 기분을 느끼면서 살고싶다.

 

나는 우테코에서 가장 개발 공부 기간이 짧다. 따라서 인프라에 익숙하지도 않고, 아직 특출나게 코드 작성이 뛰어나지도 않다. 따라서 이번에는 "팀원 전체가 공통된 설계를 동기화할 수 있도록, 원활한 협업을 위해 소통이 잘 되고, 문서화를 잘 하는 팀원" 포지션이 되기로 다짐했다. 

 

 

 

✔ 회의 전에 할 일을 정리한다.

 

 

첫 회의 때 다들 큰 준비를 하지 않은 것 같아서, 오늘 무엇을 해야 하는지 목표에 대해서 먼저 정리했다.

 

 

원래 내 목표는 함께 인수테스트를 작성하는 것이었지만 안드로이드가 인수테스트에 능숙한 것 같지는 않아서, 함께 API를 설계하는 것을 목표로 했다. 

 

 

 

✔ 어색한 원격 첫 회의에 했던 말을 놓치지 않기 위해 기록한다.

 

첫 회의를 원격으로 진행했는데, 역시나 굉장히 어색했다. 

 

화상으로 서로 5개의 화면으로 분할된 얼굴을 보고 있으면 집중도 분산되고, 어떤 한 가지 일에 집중한다는 생각이 잘 들지 않기 때문에 노션을 파서 화면공유를 하고, 자발적으로 기록이가 되었다. 

 

각자 팀원들이 자신의 주장을 해야 할 필요가 있을 때가 많은데, 누가 어떤 주장을 했는지 빠짐없이 기록하면 (잘못되었을 때 책임을 물으려는 용도는 아님! ><) 음성으로만 할 때와 달리 모든 팀원들이 차례를 가지고 자신의 생각을 말할 수 있어서 좋은 것 같다고 생각했다. 

 

미션에서 선택적으로 요구사항을 골라야 할 때도 있었고, API의 URI를 정하는 과정에서 특히나 의견이 많이 갈렸는데, 기록을 하면서 함께 보여주는 것만으로도 의견 정리가 잘 되는 것 같다. 

 

선택 요구사항 고르기!

 

또한 API에서 요청과 응답의 body에 관한 내용은 말로 하다보면, 각자 상상하는 모습이 다르게 될 수 있는데 글로 작성하면 더 빠르게 모두가 같은 생각을 할 수 있게 되어서 좋은 것 같다! 타자가 좀 빠른 편이라, 앞으로도 내가 기록이를 자처할 일이 많을 것 같다. (사실 기록벽 있어서 너무 행복함)

 

우리의 첫번째 API 설계

 

의견이 갈리는데, 애플리케이션 전체의 존망에 관련된 경우는 아닐 때는 다수결로 한다!

 

다수결로 결정! 유난히 많은 의견이 갈리던 URI

 

역시나 다수결이 최고죠! 의견에 대한 근거도 적어두면 좋음

각자 다른 정책

 

 

✔ API를 설계할 때, 클라이언트 측의 의견을 먼저 듣는다.

 

백엔드 크루 3명, 프론트엔드 크루 2명, 이렇게 총 5명이 한 팀인 상황에서 첫 원격 회의 때 있던 일이다. 

 

장바구니에 상품을 담아놓고, 그중 일부를 선택해서 주문하는 API를 만드는 상황이었다. 

여기서 중요한 '그중 일부를 선택'한다는 사실이 처음에 동기화되지 않은 상황에서 회의를 진행하고 있었다.

 

장바구니 자체의 id를 cart_id라고 하고, 장바구니에 들어있는 각 상품의 아이디를 cart_item_id라고 하겠다.

 

1. 백엔드의 한 크루: 주문하기 요청 body로 cart_id를 받자!

 

 

2. 백엔드 나머지 두 크루: 주문하기 요청 body로 cart_item_id를 List 형태로 받자! 

 

 

나는 나머지 두 크루에 속했기 때문에 1번 주장에 대해서 어떤 근거인지 완전히 이해하지는 못했지만, 그 크루는 해당 방법이 더 효율적이라고 생각해서 주장했던 것 같다. 하지만 2번 주장을 하는 두 크루를 제대로 설득하지 못해서 5~10분 가량 토론이 이어지는 상황이었다.

 

원격 회의 중간에 갑자기 이렇게 논의를 하게 되어서 안드로이드 크루들이 다소 당황스러울 것 같다는 생각이 굉장히 크게 들었다.

그래서 말을 끊고 먼저 안드로이드에게 물어봤다. 안드로이드 측에서는 cart_item_id를 가지고 있기 때문에 위의 형태와 같이 보내줄 수 있고, cart 자체의 id에 대해서는 잘 상상이 되지 않는다고 답했다. 따라서 곧바로 요청 body로 넘겨줄 수 있는 2번이 쉽게 채택되었다.

 

백엔드끼리 아무리 뭐가 더 좋다고 이야기해도 답이 나오지 않는 상황이었는데, 이와 비슷하게 클라이언트 측에서 가능하다고 하는 쪽으로 결정하면 쉬운 경우가 많았다. 

 

결과적으로 클라이언트에 물어보기 전의 백엔드끼리의 토론은 무의미해진 것이다. 

늘 통하는 규칙이지는 모르겠지만, 먼저 클라이언트에 어떤 경우가 가능한 것인지, 어떤 경우를 생각하고 있는지 물어보는 것이 회의를 쉽고 빠르게 이끈다는 것을 깨달았다!

 

 

✔ 용어를 분명하게 통일한다.

 

자신이 생각한 단어로부터 가장 쉽게 연상되는 영어 단어를 말하기 쉽다. 

그래서 각자 자신이 생각한 것과 다른 사람이 생각한 단어가 계속해서 다른 경우가 많았다.

 

우리 팀은 구매하기로 선택한 상품들의 판매가를 모두 더하고, 사용하겠다고 한 포인트만큼을 차감한 금액을 최종 주문금액으로 하기로 했다.

 

처음에는 아래와 같이 용어를 정했다. 

 

1. 구매하기로 한 상품 판매가의 총액 = total_price

2. 최종 주문금액 = order_price

 

그런데, 사람에 따라 total price는 머릿속에서 생각하기로는 1번, 2번 모두 가능하다...?!!

따라서 계속해서 크루들이 용어를 혼용해서 사용했고, 의사소통이 잘 되지 않았다.

무엇보다 json에서 요청과 응답의 파라미터 이름으로 사용해야 했기에, 헷갈리면 큰일나는 이름들이었다. 

 

total price라는 네이밍을 버리고, 

 

1. 구매하기로 한 상품 판매가의 총액 = original_price

2. 최종 주문금액 = order_price

 

위와 같이 하자고 팀에서 결정했고, 이후로 저 명확한 단어들을 사용하니 의사소통에 관련된 혼란은 더이상 없었던 것 같다. 

 

 

✔ API 설계에 대한 최종 API 명세서를 작성하고, 변경사항이 있을 경우 빠르게 동기화한다.

 

 

내 README에 들어가 보면, API 명세서를 작성하고, 꾸준히 수정한 기록이 있다.

팀원들 모두 그닥 하고싶어 하는 일은 아닌 것 같은데, 누군가 한 명은 꼭 해야 하는 일인 것 같다.

기왕이면 정리벽인 내가 하자!

 

 

 

위와 같이 작성했고, 변경사항이 있는 경우에 다시 링크를 보내면서 아래와 같이 공유했다.

 

동기화!

 

근데 하다보니 너무 귀찮고, 나도 사람이다보니 업데이트가 안되는 부분이 있었다. 

자동화를 하기 위한 툴을 방학동안 공부해보면 좋을듯

 

💋 피드백

 

친절하고, 정리를 잘 해줘서 고맙다는 피드백을 받았다. 오예 ><