협업 잘하는 개발자로 거듭나기 위한 발자취

들어가며

사실 소프트 스킬에 강점을 가지고 있다는 생각을 했기 때문에 '협업? 별로 어렵지 않지'라고 생각했고, 협업에 대한 거부감은 없었던 것 같다. 학교생활 중 과 학생회의 홍보부원으로 시작하여 홍보부장을 거쳐 부회장, 회장을 경험했기에 여러사람들과 일하는 것에 대해 문제는 없을 것이라는 막연한 생각....하지만 오산이었다. 생각보다 어렵고 생각보다 막히는 부분들이 많았다. 이 글에서 모든 걸 담을 순 없겠지만, 협업을 위해 고민했던 내용 시도들을 정리하며, 이후 프로젝트나 회사에서 같이 일하고 싶은 개발자가 되기 위해 돌아보려한다.

 

---

학교생활

 학교생활에서도 개발프로젝트는 아니지만, 회장을 맡게되면서 3개월정도의 학술제라는 프로젝트를 주도했던 경험이 있다. 

 

- 주단위 스프린트

 

 학술제를 위한 주차별 테스크를 정하고, 홍보부 · 재무부 · 기획부 별로 해결해야할 문제들과 목표들을 분배했다. 2주에 한번씩 전체 회의를 통해 20명 정도의 인원의 의견을 듣기 위해 노력했고, 매주 부장 + 주요학생회 인원들과 회의를 통해 목표를 구체화했다. 

 

- 문서화

 

 회의 하루 전, 회의주제를 부장들과 함께 소통하여 정리하고 문서화를 통해 공유하여 충분한 생각을 한 후 회의를 참여할 수 있게 했다. 서기부를 따로 배치해 회의내용들을 기록하고, 회의 간 충분히 진행되지 못한 부분들을 추가 코멘트로 정리해서 부원들에게 문서를 제공했다.

 

 이외에도 지금 하고 있는 페어프로그래밍처럼 선후배가 함께 일을 해나갈수 있는 환경을 구성하고, 이전 학술제를 분석해서 교환학생 발표와 같은 새로운 컨텐츠를 도입해서 (현재까지 매년 학술제마다 진행하고 있다.) 학술제 재학생 참여율을 매우 높여 성공적으로 마무리한 경험이 있다.

 

이렇게 될줄 알았다고 한다...그치만 될 거라고 한다...

---

부트캠프 기간

 개인 토이 프로젝트 기간을 거쳐 팀프로젝트를 하면서 협업에 대한 고민들과 시도들을 해보게 된 것 같다. 두번의 부트캠프 기간동안 했던 협업의 방식 중 기억나는 것들을 3가지 정도 뽑으라고 하면, 페어프로그래밍 · 문서화 · 코드리뷰를 뽑을 것 같다.

 

- 페어프로그래밍

 

 부트캠프 동안 두가지 정도의 페어프로그래밍을 했었다. 하나는 VSC의 라이브쉐어를 이용한 라이브페어코딩과 세부 도메인의 페어프로그래밍(마땅한 단어가 생각나지 않는다..) 이였다.

 

 우선 세부도메인의 페어프로그래밍은 다음과 같이 진행했다. (이전 프로젝트에서 기능별로 프로젝트를 분배해서 진행했을때, 결국 전체 흐름과 코드는 이해하지 못한 채 자신의 파트에만 그쳤던 경험을 개선하고자) 기능별로 세부 도메인을 나누고, 도메인에서 세부적인 부분들을 분배해서 구현하는 방식으로 진행했다. 예시를 들면, Auth 관련 로직들을 회원가입과 로그인 기능으로 또 다시 분리해서 이걸 하나씩 나눠서 맡고 유기적으로 코드들을 공유하면서 기능을 하나 완성하면 다음 기능으로 넘어가는 방식으로 진행했다. 프로젝트 기능 전체에 대한 이해를 증대시키는 장점이 있었고 이슈 등이 실시간으로 공유된다는 장점이 있었고, 대신 시간소모가 심하거나 병목이 느껴졌다는 단점이 명확했다.

 

 VSC의 라이브쉐어는 이러한 페어프로그래밍을 좀 더 보완해 줄 수 있었다. 혼자서는 해결할 수 없는 문제들을 화면만 보고 해결방법을 제시하는게 아닌, 상황 자체를 공유할 수 있어 의미 있었던 것 같다. '아나바다'와 이후 원티드 코스에서도 라이브쉐어를 자주 애용했는데, 한 부분에서 막히는 시간이 길거나, 여러 산발된 문제들을 해결해야 할 때 유용했던 경험이 있다. 물론 하나의 문제에 대해 해결을 하려고 하다보면 한명이 주도해서 해야하거나 두명 이상이 다른 곳에서 작업할 시 오류로 인해 화면 단을 확인 못한다는 단점이 뚜렷하게 나타나기도 했다. 그렇지만 괜찮은 협업 방식이라고 생각된다.

---

이후 팀 프로젝트

커뮤니케이션 측면에서의 마음가짐은 항상 "항상 나의 상황을 공유하자." 였다. 그래서 스프린트 카드를 이용해서 작업예정/ 작업중/ 작업완성을 나눠서 프로젝트 내에서 현재 내 진행상황을 공유했다. 구체적인 마감 기한과 체크박스를 활용한 세분화된 진행상황을 공유하는 방식으로 업무상황을 공유할 수 있도록 했다.

또한 슬랙 메세지를 통해 삽질을 하고 있는 상황을 공유한다거나, 공통으로 겪을 수 있는 오류들을 해결한 부분들을 설명하고, 공유하는 노력들도 자주 했다. 아래는 공통로직으로 사용된 axios interceptior 와 관련된 설정에서 오류를 해결해서 공유한 부분인데, 이렇게 설정해둔 것들을 공유해서 작업시간을 많이 단축했던 기억이 있다.

 

- 코드리뷰

아직까지 능숙하진 않지만 코드 리뷰를 잘하기 위한 노력들도 하고 있다. 작은 커밋단위가 아닌 전체적인 부분에서 코드를 유지하고, 근거가 있는 코드리뷰를 하기 위해 점점 노력해야겠다는 생각을 하고 있다. 

개인적으로 좋은 코드리뷰 문화란,

•  코드는 개인의 소유가 아니라 팀의 소유다. 코드 품질은 팀의 책임이다. 코드 완벽주의나 개인주의를 지양하자.(https://jong6598.tistory.com/18) 
• 하나의 프로젝트는 일관성이 있어야 한다. 그래야 코드를 읽는데 들이는 시간을 낭비하지 않는다. 사람마다 다르게 코딩해놓으면 읽다가 흐름이 뚝뚝 끊기고 실수하기도 쉬워진다. (이래서 팀내 코드 컨벤션 설정이 매우 중요하다!)
• 커밋과 풀 리퀘스크는 30분 이내에 리뷰가 가능한 크기로 잘라서 할 것. (이부분은 기능개발을 하다보면 지키기 어려운 부분이지만 노력해보고 있다.)
• 최대한 많은 사람이 리뷰할수록 놓치는 부분이 적어진다. 
• 지적을 위한 코드리뷰보다는 더 나은 프로덕트를 위한 코드리뷰를 하자.

=> 무엇보다 구성원들이 더 나은 코드, 더 나은 프로덕트를 만드려는 생각들을 가지고 있다.

라고 생각한다.

---

마치며

'협업을 잘하는~' 이라는 수식어를 붙이기 위해 해나가야할 것들이 많다는 것을 느낀다. 아직은 매우 부족한 코드리뷰부터, 내 상황을 어느정도까지 공유하고 어느정도는 공유하지 않아도 될지와 같은 강약조절의 문제들이 협업과 관련해서 요즘 많이 고민을 하고 있는 부분이다. 되도록이면 많은 개발자와 동료들을 만나서 소통을 많이 해보고 싶다. 협업을 하면서 가장 크게 느낀 것은, 누구에게나 어떤 협업적인 장점이 최소 하나씩은 있다는 것이었다. 조금은 소통이 힘들었던 프로젝트를 조기에 마감하면서 협업에 대한 생각이 많이 드는 요즘이다. 나는 '누구에게는 같이 일하고 싶지 않은 사람이었을 수도 있다.' 는 생각이 들기도 한다.