230703 협업에 관하여 - 개발 편

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

+ 푸념과 하소연에 가깝기 때문에 내용이 엄청 깁니다

---

지난 번 작성한 글에 이어 프론트엔드 팀 내에서 어떤 경험을 했고 해프닝이 있었는지 작성해보려한다.
재밌는 내용!?이 궁금하시면 2번부터 읽어보시길 권해드린다.

아래 전체 팀협업 경험 글에 대해 첨부했으니 궁금하신 분들은 지난 글을 참고해 주시길 :)

230612 협업에 관하여 - 전체 편

---

Team SMASH 프로젝트가 절반정도 진행 될 때 팀원이 꾸려졌다. 두 프로젝트를 동시에 진행하는 상황이기도 하고 앞선 글에서 의도치 않게 팀장이 되어서 프론트엔드 안에서라도 평온하게 그리고 잘 리드하고 싶은 마음이 있었다. 

팀원분들에게 지난 프로젝트에서 코드 컨벤션과 작업 방법에 대해 팀원들과 회의해 친숙한 방식으로 진행하기로 결정했다. 그리고 가장 작업 속도가 빠른 팀원에게 초기 프로젝트 세팅을 맡기고, 팀장으로서는 다른 팀 리더들과의 조율한 내용정리 및 프론트엔드 개발문서 작성과 회의록을 작성했다.

거기에 지나왔던 프로젝트에서 했던 것 처럼 각자의 작업 상황을 확인하기 위해 깃허브 프로젝트 기능을 사용했다. 기존에 했던 프로젝트처럼 이번 프로젝트도 줌 소회의실을 사용하며 거의 상주 해 있는 상태로 있되,  호출 시 마이크 또는 화면 공유를 진행하자는 부분까지 프로젝트 컨벤션으로 정한 후 빠른 세팅을 마쳤다.

1 . 갈등

프로젝트를 빠르게 세팅하기 위해서 라이브러리 및 프레임 워크를 정하는 과정에서 1차 갈등이 있었다. 3D Asset을 판매하는 서비스니 SSR로 작업을 하는게 맞겠다는 판단 해 Next.js version 13을 사용하기로 결정 했었다. 하지만 각자 공식 문서와 기타 강의등을 공부하면서 알게 된 것이 있었다. Next.js 공식문서에서 스타일 적용을 위해 Tailwind를 사용을 권장 한다는 것.

아무래도 다들 찬성하지 않았던 이유는, 프로젝트 기간이 한 몫 했었기 때문에 Styled-components를 사용하면 좋겠다는 의견이 있었다. Tailwind보다 Styled-components를 사용하고 싶었던 구체적인 이유로는
첫째, 익숙한 도구기 때문에 UI 작업시간이 확 줄어 들 수 있다.
둘째, 구현하는 컴포넌트 당 디자인을 적용하는 방식이기 때문에 inline으로 적용하는 Tailwind보단 유지보수에 유리하다. 이 두가지 이유가 가장 큰 비중을 차지 했다.

때문에 이 부분을 멘토에게 질문하게 되었는데, 멘토의 피드백은 '회사마다 다르겠지만, 실무에 사용하는 기업이 꽤나 있다. 물론 프로젝트기간이 짧아 완성도가 낮아 질 순 있지만 그럼에도 Tailwind경험을 만드는 것을 추천드린다.'였다.
피드백도 받았고, tailwind.config.js에 서비스에 맞게 설정을 잘 하기만 해도 활용도가 정말 높은 프레임워크라는 생각도 들어 러닝커브와 초반 설정에 시간을 많이 잡아 먹을 까 두려웠지만 진행하기로 결정하였다.

1 - 1.팀원의 참여도

이번 프로젝트에선 나 포함 총 4명의 FE개발자가 구성이 되어있는데 함께 작업을 해본 적이 없는 팀원이 두 분이 계셨다. 하지만 그 두분의 성향을 익히 주변에서 듣고 어느정도 파악이 되어있었기 때문에 약간 힘들거라는 건 알고 있었지만 걱정은 되지 않았다(걱정했었어야 했어 과거의 나야....!!!). 

함께 작업한 경험이 없는 팀원 중 B라는 분이 계셨는데, 2월부터 해왔던 다양한 프로젝트에서 그 분과 작업을 했던 분들이 공통적으로 하시는 말은 '자리에만 계실 뿐 참여하지 않는다.' 였다. 하지만 마지막 협업 프로젝트니까 잘 참여하지 않을까? 라고 생각했던게 나의 팀장으로서의 패인이었던 것 같다.

역시나 그분들이 하신 말씀처럼 그 분의 평소 습관이 드러났고, 결국 나는 '자리에 안계셔서 협업에 어려움이 있다. 사정이 있으면 알려주시면 좋겠다. 오해하고 싶지 않다' 라는 내용으로 지적을 하게 됐다.
자리에 안 계시는 점이 가장 핵심적인 이유였던게, 자리에 없으면 소회의실에서 결정되는 것들,  진행되는 회의 등, 현 상황에 대한 흐름을 따라 잡기가 어렵고 모두의 의사결정에 따라 프로젝트 방향이 진행되고 있는데 소통이 안되는 것이 연쇄적으로 발생했다. 더군다나 회의록을 보지도 않고 매번 물어보는 것도 팀리드에 굉장한 피로감을 줬었다.

그래서 이러한 내용들을 최대한 감정을 빼고 전달드리려 노력했지만 그렇지 못했는지 B팀원은 '참여를 했는데 안한다고 하시면서 이렇게 지적하시는거면 마음의 결정을 내리신거 아니냐'라는 감정적인 답변을 주셨다. 사실 사람인지라 감정을 최대한 뺀다고 했을지라도 전달받은 사람입장에선 다를 수 있다. 하지만 그러한 답변은 원활한 소통을 하기 어렵게 만들었고, 결국 그 분은 자진 하차를 하셨다.

2. 새로운 팀원

남은 세명이 서비스를 다 진행하기엔 어렵다는 팀원의 의견에 동의해 새로운 팀원이 합류하게 되었다. 팀원C는 프로젝트 경험이 있는 분이셨지만 Next.js와 TypeScript에 경험이 없었고 이미 플젝이 1/3정도 진행되고 있는 상황이었기 때문에 빠른 온보딩과 적응을 도와줘야하는 상황이었다.
때문에 소통수단, 개발문서 그리고 가장 중요한 Github Organisation에 초대 후 기타 안내를 드렸다. 온보딩 당일이 목요일 저녁이었기에 금요일에 살펴보시고 월요일에 피드백 또는 질문을 주라고 한 후 온보딩을 간단히 마쳤다.

2 - 1. 소통의 방식

월요일에 연락을 취했지만 새 팀원C는 아팠다는 이유로 하루 종일 연락이 없었다. 아팠다니 어쩔 수 없고, 전 팀원이랑 비슷한 낌새가 느껴졌지만 기능구현이 더 중요하니 나는 계속해서 온보딩과 팀원방식에 적응하게 하기 위해 안내했고, 궁금한게 없는지 계속 물어봤다. 팀장이기도하고 이 사람이 어떤지 파악하기 위해 여러가지 것들을 물어 본 것도 있었다. 하지만 책임을 다하며 소통을 활발하게 하겠다는 초반 의지와는 달리 소통 방식에 오해를 불러오는 몇몇 행동들을 했다.

스크럼 시 부정확하게 본인 태스크 전달하기. 태스크 기한 내 미완료하기. 가장 중요한 기한 내 pr진행하지 않기 등 협업으로서 받아들이기 어려운 소통 방식으로 협업을 이어왔었다. 이런 반복된 상황들이 나 뿐만이 아닌 팀원분들을 불편하게 하는 상황이 생겨, '몇번 설명해줬으니 팀 컨벤션 대로 진행해주면 좋겠다'는 나의 완곡한 경고는 '무의미한 미팅하지 말자', '재촉하지 않았으면 좋겠다' 등의 답변으로 돌아왔다. 우선 100% 온라인 작업이기 때문에 소통방식은 줌 소회의실과 카톡 오픈채팅방이 주요 수단이었다. 소회의실에는 오지 않았기 때문에 텍스트라도 전달을 하고 소통하려했지만 아무래도 의견전달이 한계가 있었는지 소통의 간격을 줄이는게 정말 어려웠다. 

2 - 2. 일정 중 라이브러리 추가

내가 원하는 소통은 해주지 않았지만 팀원이 원하는 소통은 있었다.

팀원C는 지난 프로젝트에서 pre-commit 라이브러리인 husky를 활용해서 작업을 진행한 경험이 있어 도입을 하면 좋겠다는 의견을 냈었다. 하지만 당시 시점은 주말을 제외한 12일정도 남은 시점이었고, 이미 git remote branch에 protection을 적용해 놓은 상태에서 각자 맡은 파트를 진행 하고있는 상황이었다. 게다가 나를 포함한 나머지 팀원은 husky라는 라이브러리를 전혀 모르는 상태였고, Next.js와 Tailwind 그리고 TypeScript를 공부하고있어 러닝커브가 높은 상황이라 피로도가 높은 상황이었다.

하지만 무작정 반대를 할 수 없으니 husky를 본인 로컬에서 적용한 후 소회의실에서 에러가 나지 않은 상태에서 어떻게 pre-commit을 진행하면 되는지 보여주신 다음, pr해주시면 merge바로 하고 적용하면 좋을 것 같다. 라고 피드백을 드렸다. 하지만 그 분은 피드백 대신 별다른 말 없이 본인의 블로그 링크를 주며 각자 로컬에서 진행하자는 식으로 반응을 하셨다. 정확한 검증도 없고, 산출물이 나와야하는 시점에서 본인을 제외한 모두가 모르는 라이브러리에 대해 가르쳐 주지도 않고 어느 것 하나 제대로 보여주지 않는 부분 때문에 모두가 husky에 의문점을 갖게 되었고 결국엔 진행하지 않기로 했다.

2 - 3. pull request and merge with no approve to main branch... 

개발 브랜치인 develop브랜치는 본인 코드를 병합하지 못하며 병합을 진행하는 것은 한 사람으로 하는 브랜치 보호설정을 해뒀었다. 하지만 main branch엔 설정하지 않았었는데, 사유는 기존 팀원은 develop만 손대기로하고 main은 나만 손대는 것으로 컨벤션을 결정했었고 이슈가 지금 껏 없었기 때문에 간과했었다. 팀원C는 본인 진행하지 않기로한 husky가 없어서 그랬는지, 일주일 동안 부탁해서 겨우 받은 pr은 develop이 아닌 main 브랜치로 push가 되어있었고 내가 확인하기도 전에 팀원C는 pr한지 몇십초 만에 main로 merge를 하는 실수를 하고 만다.

합류 초반, 브랜치 전략에 대해 이야기 하기도 했고, 각 브랜치의 역할이, 코드 컨벤션이, 작업이, 어떻게 진행되는지 안내를 했음에도 불구하고 main에 병합을 진행한 것이다. 실수에 대한 사실을 이야기했고 잘못됐으며 본인의 실수이니 본인이 수습했으면 좋겠다고 말씀드렸다. 하지만 '아무버튼이나 누르다 보니 그렇게 됐다.', 해본 적이 없어서 수습 할 수 없다.','husky를 도입하지 않아서 이렇게 된 것이 아니냐' 등의 대답을 하셨다.

결국 나도 경험해 본적이 없던 remote reset작업을 주말동안 진행하게 되었다. commit 내역을 살리고 원하는 시점으로 돌리는 방법인 rebase를 진행하려했지만 commit내역 하나하나을 컴파일하는 과정, 그 과정에서 발생하는 충돌 내역이 너무 많아서 3시간 정도 작업하다가 포기하고 reset으로 원하는 시점으로 돌려 commit내역이 아쉽지만 삭제하는 방법을 선택해 5시간 만에 remote reset 작업을 마칠 수 있었다. 신중하게 접근하고 진행하다보니 시간이 오래걸렸다.

결론 및 반성

뭐 2번의 내용이 저것이 전부가 아니라 더더더 많이 있지만 그걸 나열하고 작성하다보면 스크롤이 끝없을 것 같아 여기서 마무리를 지어보려한다. 

마무리하는 소감을 말하자면 '사람과 함께 하는 일은 정말 쉽지않다'였다. 그리고 지난 글에서도 작성했지만 완장을 차는 일은 몇년동안 없을 것이다. 아무래도 숙련자도 쉽지않은 프로젝트를 안정적이며 아름답게 진행하는 것은 쉽지않다. 더군다나 숙련자도 아니고 학습하는 사람들이 그것도 FE단의 작업일이 20일도 안되는 상황에서 무사히 해내기는 더더욱 쉽지않다.

그런 사람이 팀장을 맡았으니 얼마나 정신없고 어떤 선택이 가장 최선의 선택일지 알길이 없다(사수님이 있었으면 좋겠다 라고 생각한 순간이 넘나리 많았따). 때문에 팀장으로서 타 부서 팀장과 회의 및 협업을 진행할 때 내가 만들었던 오해의 요소들을 살짝 나열해 보자면, 우선 서로를 배려하고 나의 감정을 공적인 일에 최대한 넣지 않기 위해 하는 화법이 의외로 소통에 오해를 불러일으키는 요소가 됐었다고 생각된다. 다음 협업에서는 좀 더 직설적이지만 젠틀하게 말하는 방법을 길러 의견을 전달해야겠다.

FE안에서 팀장으로서의 반성할 점은 좀 더 빠른 대처나 방향 전환이 가능할 수 있도록 프로젝트 초반에 느꼈던 전 팀원과의 비슷한 점을 무시하지 말고 지적이나 경고 등을 좀 더 정확히 그리고 빨리 이야기할 걸 그랬나 싶기도하다. 하지만 온보딩과 새 합류라는 점이 그 팀원을 무작정 끌지는 말아야겠다라는 생각을 심어줘서 결국 아름다운 방향으로 이어지진 못했다(참고로 새팀원C도 결국 하차를 했다).

프로젝트 기간동안 팀원 이슈 대해 팀원들에게 의견을 구하고, 수습하기 위해 선택을 해야하는게 쉽지 않았지만 그래도 이 선택이 프로젝트 마무리 하는데는 후회없는 선택이었다고 생각한다. 모든 부서의 팀원분들이 함께 으쌰으쌰 해주셨기 때문에 최우수 프로젝트라는 영광을 얻을 수 있었기 때문이다.

음... 내 소통방식과 방향선택 등이 옳지도 정답도 아니다.

하지만 타 부서와의 협업이고 일정을 조정 해서 최대한 빠르고 아름답게 기능 구현을 해야하는 상황에서 새로온 팀원이 지난 팀원과의 태도 등이 너무 비슷하며 기존 팀원들의 협업을 방해하는 것이 도저히 참아지지 않았다. 완장이 주는 책임감이 더해지기도 했고 이 불편한 작업 상황을 해소하고싶은 마음이 컸기 때문인지(나조차 평화로운 작업상황이 보장되지 않는게 말도 안된다구....!!) 감정이 한 스푼 섞인 결정을 하게 되었다. 언젠가 이 경험이 나중에 나에게 좀 더 나은 방법을 찾게 하고 결정을 할 수 있도록 도와주지 않을 까라는 기억 조작을 해보며 글을 마무리 하려한다.