협업 방식에 대하여

Younngg·2023년 2월 18일

대학 때 연극을 전공했기 때문에 다인원 협업 경험이 많다. 학교에서만 한 학기 당 한 번의 공연, 그리고 동아리 공연까지 포함하면 총 7회 공연을 했고, 그렇게 함께 했던 인원을 모두 더하면... 150명 이상은 될 것 같다. 물론 디자이너를 맡았을 때 대화를 전혀 안 해본 사람들도 있다 ㅎㅎ

아무튼, 그래서 겪어볼 빌런은 다 겪어봤고 나름 사람들과 함께 일하는 걸 좋아하는 편인데도 여전히 팀플은 어렵다. 연극을 하면서도 좋은 협업 방식을 찾느라 열심히 이것저것 도전해봤지만, 역시 어디서나 최고는 없는 법이다. 개발 팀프로젝트도 마찬가지였다. 언제나 아쉬움이 남고, 더 효율적인 방법은 없을까, 좋은 방법을 발견하더라도 이걸 조금 더 일찍 했으면 어땠을까, 괜히 말했나, 요런 고민들을 하게 된다.
오늘은 문득 그런 생각이 들었다. 지금까지 해봤던 협업 방식을 모두 기록해보면 다음 팀프로젝트에서 알맞은 방식을 선택하는데 도움이 되지 않을까? 좋았든, 좋지 않았든 다음 프로젝트에는 그게 또 맞을 수도 있으니까!

대학 시절, 내가 시도해본 방식들

쓰다보니 서론이 길어졌다. 암튼 그래서 공연을 할 때 내가 겪었던 협업 방식은 이렇다.

1. 마스터 플랜

첫 모임에선 간단한 아이스브레이킹 시간을 가진 뒤 팀원들에게 대본과 컨셉을 공유한다.
연출이 어떤 방향성으로 작품을 만들고 싶어 하는지 이야기를 나누고, 연기, 디자인의 컨셉은 어떻게 잡을지, 머릿속에 그림을 그릴 수 있는 시간이다.

그림을 그린 것을 바탕으로 각자 계획을 세운다. 연출이 먼저 일주일에 장면을 얼마나 만들 것이고, 언제쯤 완성을 시킬 것인지 정하고 나면 각 팀들은 거기에 맞춰 계획을 짠다. 이것을 '마스터 플랜'이라고 부른다.

이렇게 주차마다 계획을 세운다. 팀 단위로 계획을 세워야 한다면 구글 시트 등을 이용해서 함께 편집해볼 수 있다.
나중에 개발 팀프로젝트에서 팀장을 맡게 된다면 이 마스터플랜을 도입해보고 싶다. 이전에 한 달 동안 진행한 팀프로젝트에서는 기획은 3일 정도, 그리고 그 다음엔.. 발표 3일 전에 배포하기. 이 정도로 계획을 세웠었다. 만약 마감 기한을 정할 수 있었더라도 계획을 저만큼 상세하게 세우진 않았을 것 같다.

상세한 계획을 세우면 좋은 이유는, 우선 작업의 속도를 조절할 수 있다. 세웠던 계획보다 딜레이 될 때는 문제점이 무엇인지 점검해볼 수 있고, 계획보다 빠르게 진행이 된다면 놓치고 가는 것은 무엇이 있는지, 미리 준비해야 할 것은 없는지 고민해볼 수 있다. 물론 계획을 적절하게 세웠을 때 말이다.

2. 회고와 합평회

하나의 공연을 마친 뒤엔 결과 보고서를 작성하고, 합평회를 한다. 결과보고서라 함은 우리가 블로그에 작성하는 회고글과 비슷하다. 이번 작품에서 좋았던 점, 아쉬웠던 점, 보완해야 할 점들을 기록한다.

이 결과보고서들은 하나로 취합되어 학교에서 따로 보관해두는 문서다. 이런 글은 내가 나중에 봤을 때에도 도움이 되지만, 작업 방식에 대해 고민하는 다른 사람들에게도 도움이 될 것이다. 우리가 쓰는 회고글도 이와 비슷하지 않을까?

합평회는 모두가 모여서 서로에 대한 피드백을 주고 받는 시간이다. 작품 결과에 대한 솔직한 피드백을 나눌 수도 있고, 작업 과정에 대한 피드백을 나눌 수도 있다. 다른 사람의 의견을 들을 수 있기 때문에 개인적인 회고와는 차이가 크다. 특히 작업 과정은 누군가에겐 좋았던 것이 또 다른 누군가에겐 불편했던 것일 수도 있기 때문이다.
농산물 쇼핑몰 프로젝트에서는 개인적인 회고글을 작성하는 것 뿐만 아니라, 다같이 모여 회고를 진행했었다. 만약 일회성이 아닌, 계속해서 프로젝트를 발전시키는 팀이라면 이러한 회고 방식은 큰 도움이 될 것 같다.

내가 시도해본 방식

팀프로젝트를 할 때마다 팀에 적합한 협업 방식은 무엇일까 고민을 하게 된다. 팀장을 맡은 적은 한 번도 없지만, 팀장도 우리와 같이 배우는 입장이기에 팀원들도 협업 방식에 대한 의견을 내면 큰 도움이 될 것이다.

페어 프로그래밍

나는 지금까지 페어 프로그래밍과 라이브 코딩을 경험해봤는데, 직접 '페어 프로그래밍을 하자!'라고 제안을 한 건 아니었다. 여행 동행 구인 커뮤니티 프로젝트에서는 refresh token 작동 방식에 대해 담당 팀원과 서로 이해한 바가 달랐다. 그래서 서로를 설득할 적당한 방법을 찾다가 페어 프로그래밍 중 내비게이터-드라이버 방식으로 함께 axios interceptor를 작성했다.
내비게이터-드라이버 방식은 컴퓨터 한 대에 키보드와 마우스를 연결하여 함께 코드를 작성하는 방법으로, 한 사람은 직접 작성하는 드라이버, 다른 사람은 조언을 하거나 방향을 지시해주는 내비게이터가 되어 진행한다.

출처 : 나의 페어 프로그래밍 탐험기

원래는 정해진 시간에 맞춰 역할을 바꿔가며 진행해야 하는데, 우리는 이 방식을 제대로 알고 한 것이 아니기에 처음부터 끝까지 내가 내비게이터, 다른 팀원이 드라이버를 맡아 진행했다.

함께 코드를 작성하다보니 서로의 사고의 방향을 알 수 있게 되었다. 자연스럽게 서로가 이해한 refresh token 작동 방식에 대해 알게 되었고, 코드가 의도대로 동작하지 않을 때, 제 3자의 눈으로 보고 있던 사람이 문제를 빠르게 캐치할 수 있었다. 혼자 코드를 작성할 땐 생각한 바를 그대로 옮기면 되는데, 상대에게 설명을 해줘야 하다 보니 생각한 것을 말로 옮기는 작업이 필요했다. 그 점이 힘들기도 했지만, 사고의 방향성과 이해 수준을 맞추는데 정말 좋은 시간이었다.

라이브 코딩

그리고 RTK query를 도입하자고 의견을 냈을 때, 팀원들은 사용 방식을 잘 모르거나 client 상태와 server 상태 분리 이유를 납득하지 못한 상황이었다. 나는 우선 방법을 알려주기 위해(생각보다 그리 어렵지 않다는 것을 알리기 위해...!) 화면 공유를 하고 slice 코드를 작성하는 것부터, 컴포넌트에서 전역 상태를 불러와 사용하는 것까지 라이브로 보여주었다. data fetching 로직을 client 상태(modal 등)를 분리한 것을 직접 보여주고 나니, 팀원들이 필요성에 어느정도 공감하게 되었다. 나 또한 남들에게 설명해줄 수 있을 만큼 사용 방법을 정리해볼 수 있었고, 사용 이유에 대해서도 다시금 생각해볼 수 있었다. 그리고 보다 정확한 용어를 사용하게 되고, 직관적인 코드를 작성하려고 노력하게 되었다.

사실 라이브 코딩은 이전에 했던 농산물 쇼핑몰 프로젝트에서 사용했던 방법으로, 그때 기억이 굉장히 좋았어서 그 다음 프로젝트에도 사용하게 된 것이었다.
그때는 백엔드 팀원이 에러를 해결할 때마다 화면 공유를 켜고 어떻게 해결했는지 처음부터 끝까지 재현해서 보여주었다. 백엔드 코드를 완벽히 이해하지는 못했지만, 프로젝트의 흐름을 더 자세히 알 수 있게 되고, 백엔드 팀원이 설명해준 것이 다른 장애 상황에 마주했을 때 길잡이가 되기도 했다. 아마 말, 또는 글로만 설명을 들었다면 기억하지 못했을 것이다.

페어 프로그래밍과 라이브 코딩 모두 시간이 많이 소요되는 방식으로, 프로젝트 막바지에는 실행에 옮기지 못할 것 같다. 그래도 프로젝트 초기에 처음 기술을 도입할 때, 또는 시간이 없더라도 중요한 이슈를 해결하고 이를 팀원들에게 자세히 공유해야 할 때, 공통 로직을 짤 때 이런 방식을 사용하면 좋을 것 같다.