230612 협업에 관하여 - 전체 편

✍️✍️✍️ 위 글은 작성자의 개인적인 경험이니 가볍게 읽어주시길 바랍니다.

---

모든 포지션이 하나의 서비스를 만들어 한 사이클을 돌려보는 30일짜리 프로젝트를 진행하게 되었다.
UX/UI를 제외한 포지션당 4명의 인원이 참여해 총 15명의 인원이 참여하는 나의 경험 중 대규모 프로젝트인 만큼,
포지션마다 리더가 있었으면 좋겠다는 PL님의 말씀에 따라 싱크업 미팅 때 나는 프론트엔드 리더(이하 FE리더)가 되었다.

---

1. 타 포지션과 미팅

TeamSMASH 개발이 한창이던 5월 중순, 모든 파트팀원들이 처음 만나는 싱크업 미팅이 진행 됐었다. 당시 첫 백엔드(이하 BE)와의 협업이었기 때문에 소통하는 부분에 있어 정신이 없는 상황이었다. 그래서그런지 첫 미팅이 스트레스로 다가왔었다(한꺼번에 여러정보를 정리해야하는 탓인 듯 했다). 하지만 다행히도 PM분들이 개발팀들은 미니프로젝트 진행 중에 현 프로젝트에 투입된 걸 아셨기 때문에 매주 목요일 Weekly meeting을 진행한다는 핵심만 전달을 받고 각 포지션 리더장을 뽑고 회의를 빠르게 마치게 되어 편했다.

우당탕탕 미니프로젝트를 마치자마자 바로 마지막 프로젝트가 시작되었다. 프로젝트의 첫 일정은, 포지션 별로 일정 조율해보기. 프로젝트의 Due Date는 6월 29일까지 였기 때문에 와이어프레임부터 UI/UX조율, API회의 및 조율 등이 빠르게 마쳐져야 프론트엔드가 개발에 착수 할 수 있기 때문에 빠른 호흡과 일정을 가져가는 것이 중요했다.

2. 내 생각을 제대로 전달하는 방법

빠른 개발 착수를 위해 스케줄 조율을 했던 5월 18일. 당시 PM 분들에게 러프한 서비스 정보구조도를 전달 받았었다. 러프라는 말 그대로 구조도가 픽스된건 아니지만 이것을 바탕으로 명일까지 가벼운 서비스 파악을 어느정도하고 차주 월요일 리더장 오프라인 미팅에서 기능 조율을 하면 좋겠다는 피드백이 있었다.

때문에 개발팀(FE, BE)은 19일에 따로 모여 서비스 정보구조도에 대해 회의를 진행하게 됬었는데, 당시 서비스에 필요한 전체 파트간의 회의시간이 짧기도 했고 서로 일하는 방식을 모르는 상태에서 전달받았었기 때문에 애석하게도 전달 받았던 구조도는 서비스를 파악하기에 굉장히 포괄적이고 혼선을 가질 수 있는 요소들이 적잖이 있었다. 때문에 개발팀 회의에서 PM 분들에게 물어보고 싶은 요소 및 질문들을 정리했다.

질문 리스트가 굉장히 길어짐에 따라 당시에 개발팀이 느꼈던 공통적인 생각이 점점 커져갔었는데, 그것은 "왜 이렇게 정보구조도가 진행히 되는거지?" 였다. 개발적인 시선에선 받아들이기가 애매한 UX와 페이지 구조라고 생각했기 때문이다. 하지만 이런 오해는 차주 월요일 오프라인 회의에서 1차적으로 해소가 될 수 있었는데, 원인은 같은 내용을 가리키고 있지만 사용하는 단어는 다른 경우가 있어 소통에 오해가 되거나 결론을 서로 달리 이해하는 경우가 종종있었던 것이 원인이었다.

오프라인 회의에 겪었던 소통의 방식에 문제가 있다고 인지를 한 후 이를 개선하는 의견을 서둘러 전달해야겠다는 생각을 했다. 왜냐면 팀장으로서 회의에 자주 참여를 해야하다보니 최대한 다른 포지션 분들에게 개발팀의 의견을 잘 전달하고 이를 통한 스케줄 및 기능 구현 조율을 오해없이 최선의 선택을 하며 협의가 마무리 됐으면 했기 때문이다.
때문에 회의 진행 시, 서비스 관련 용어 통일하자는 의견을 시작으로 개인적인 소통 노력으로는 개발 관련 의견 전달 시 이해하기 쉽도록 단어 및 적당한 비유를 선택해 의견 피력하기, 말씀드리고 이해가 됐는지 물어보기 등으로 소통에 대한 결함을 해소하려 노력했다.

3. 뜻대로 되지않는 스케줄

뜻대로 된다면 얼마나 아름다운 프로젝트 일까. 당연히 그런일은 없었다. 하지만 이대로 멸망할 순 없기 때문에 팀장으로서 할 수 있는 최대한의 소통과 협의를 하려 노력했다. 아무래도 PM입장에선 산출물이 눈에 보이는게 없으니 기업에게 전달드릴 내용이 없을 까 불안하고 답답할 것이고, UI/UX도 디자인 해 놓은 방향으로 UI/UX가 진행이 되는지 궁금할 것이고, BE도 구현이 된 API들이 에러는 없는지, 구현한대로 화면에 잘 출력 되는지가 궁금할 것이다.

프로젝트의 마무리를 맡고있고 모든 파트에게 상황을 전달해야하는 FE의 포지션에 있다보니 굉장히 부담감과 피로감이 몰려왔다. 팀장을 맡으면서 느낀건, "앞으로 근 5년간은 팀장을 맡지 않으리"이다. 책임을 지고 팀원의 일정을 짜고 전체 스케줄을 조율하는 것은 굉장히 정신적으로 많은 압박감을 느끼게 만들었다.

성격상 많은 정보가 한꺼번에 들어오는 것보단 우선순위로 차근차근들어오는 것을 선호하는데 팀장자리에 있는 이상 차근차근 들어오는건 바랄 수도 없고 더 나아가 병렬적으로 이것저것을 신경써야하는 점이 가장 힘들었던 것 같다. 팀원으로서 있었다면 팀장에게 내 상황, 할일 등만을 전달하고 작업을 진행하면 됐겠지만, 그게 아닌점이 프로젝트에서 가장 날 힘들게 하는 요소가 됐었다. 

하지만 뭐 어떻게하나 그냥 해야지 뭐.

압박감은 압박감이고 우선 얼레벌레라도 좋으니 마무리를 해보자 라는 생각으로 스트레스를 받더라도 진행하려 노력하고, 특히 FE팀원에게 많이 의지했다. 모르는 것도 물어보고, 일정조율은 어떻게 하면 편할지 내가 얼마나 불편한 소리를 들으면 되는지 등등을 팀원분들과 소통하며 최대한 작업하는데 편할 수 있도록, 다른 파트와의 회의에선 기한 내 진행할 수 있을 것 같은 기능, 기한 내 어려울 것 같은 기능을 쳐내는 역할을 열심히 수행 했다(오늘도 개발자는 안된다고 했다...).

4. 느낀점 및 반성

팀원과 프로젝트를 위해 노력했던 것들을 어떻게든 알아봐주는 사람이 있는 반면, 이 노력이 나를 잘 모르는 사람에겐 노력으로 느껴지지 않겠구나 하는 일화도 있었다. 자세한 내용은 다음 편에 더 자세히 개발적인 요소들과 함께 다뤄보려한다.

어쨌든 상황을 간략히 적어보자면 마감 기한이 보름정도 남은 시점에 FE팀원 관련 이슈가 있었다. 사유는 의논을 나눠야하는 사안을 반대했다와 기타 등등의 이유인데, 무조건 반대했던건 물론 아니었고, 오해가 쌓인 상황을 풀려는 의지가 대화에서 느껴지지 않아 하차를 요구한 상황이었다. 사람인지라 하차를 요구한 부분에 감정이 섞이지 않았다면 거짓말이겠지만 하여튼간 나의 발언 때문에 모두가 보는 슬랙채널에 팀장인 나에 대한 저격글이 올라오는 해프닝이 발생하고야 말았다.

예상했던 건 아니었지만 당시 모든 파트 팀원분들이 그 스레드에 의외로 아무런 반응을 하지 않으셨었다. 당시 시점의 나는 내 파트 관련 기능 구현, 팀장으로서 다른 팀원과의 소통 및 전달에 정신 없었기에 하차하는 팀원의 글의 내용을 정확히 모르기도 했고 특별히 신경쓰지 않았었지만, 프로젝트를 마친 후 개인적으로 팀원들의 생각이 궁금해(필요하다면 해명을 할 생각도 있었기에) 회식자리에서 몇몇분께 여쭤보니 '프로젝트를 진행하면서 내가 저격글 속의 사람과 같은 사람이라고 느껴지지 않았기 때문에 반응하지 않았다.'라는 반응이셨다.

일적인 소통을 위해 했던 노력이 빛을 발하는 순간이라고 해야 할까. 그 팀원 덕분에 책임을 지는 위치에 있을 때 일의 방향과 상황개선을 위해 책임지는 선택을 해야한다면 어떻게 최선을 선택하고 행동해야할지가 더더욱 확신에 찬 순간이었다. 하지만 나의 하차 통보 발언은 프로젝트의 선후 관계 및 체계 등등을 고려하지 않은 선택이었고 감정이 섞인 행동이었던건 확실하다. 때문에 온전히 내가 책임을 지고 감당 해야하며 다른 파트 팀원 분들과 프로젝트에 피해를 주지 않기 위해 그만큼 최선의 퍼포먼스를 내려 노력해야 한다는 점을 깨달았고, 그 점은 밤샘작업으로 돌아왔다. 하지만 코드에 고통받는게 났지 사람에게 고통받는건 정말이지 힘든일이다. 이제 남은 개발 협업 관련 글과 잔업을 하러 가야지.