🎓 대학원김선배 프로젝트 회고

💡 지난 5월, 작년 10월부터 개발 작업에 들어갔던 "대학원김선배" 서비스가 런칭되었다. 지금까지 약 한 달 간의 서비스 운영이 진행되었고, 그 기간동안 팀과 서비스의 크고 작은 부분들이 바뀌었다. 오늘은 그 과정에서 내가 겪었던 일들과 그에 대한 생각들을 정리해 보는 시간을 가지려고 한다.

📌 프로젝트 소개

대학원 김선배는 예비 대학원생(후배 회원)과 실제 해당 랩실에서 공부하고 있는 대학원생(선배 회원)을 매칭해주는 멘토링 매칭 플랫폼입니다.

❤️‍🔥 서비스 둘러보기

📌 프로젝트 여정

2023.09

같이 프로젝트를 진행해 나갈 팀을 꾸렸다. 개발팀 4명은 모두 한 동아리에서 출발했고, 기획자와 디자이너 분들은 새로 구인했다. 빠르게 아이디어 회의를 진행하고, 기획자들이 몇 가지 아이디어를 선정해 검증을 진행하기 시작했다. 나는 프론트엔드 개발과 개발팀 리드를 맡게 되었다.

2023.10

검증한 내용을 토대로 아이디어를 확정시켰고, 본격적인 서비스 개발 프로세스에 돌입했다. 팀 전체의 OKR과 개발팀 내부의 OKR을 설정했고, 기술 스택을 정하는 시간을 가졌다. 협업 툴로는 JIRA를 세팅했는데, 팀원 모두가 JIRA를 처음 사용해 보는 거라 다같이 공부하면서 적응하는 시간을 가졌다.

팀 전체의 WBS를 제작해서, 모두가 각 파트의 진행 상황을 예측할 수 있도록 했다. 그 외에는 팀 그라운드 룰 등을 정하며 팀 문화를 만들어가는 시간을 가졌다.

브랜딩 스프린트를 통해 우리가 고객에게 어떤 목소리를 가지고 다가갈 것인지, 어떤 인상을 주어야 하는지 등을 정의하는 시간을 가졌다. (개인적으로 팀 활동 중에 가장 재밌었던 활동 중 하나이다.)

2023.11

본격적인 개발은 11월부터 이루어졌다. 와이어프레임과 기능명세서를 보면서 천천히 개발을 진행했고, 디자인이 한 화면씩 입혀짐에 따라 UI 개발도 진행했다.
개발팀 자체 회고를 시작했다. 매주 5F 회고를 진행하고, 월말에는 KPT 회고를 진행했다.

2023.12

12월에는 소통의 문제를 해소하기 위해 문화 세팅을 하는 날을 가졌다. 모두가 그동안 서로의 파트에서 알지 못하거나 얻지 못해 힘들었던 문제들을 언급하며 대화를 통해 해결책을 도출했다.

2024.01

기획자, 디자이너 분들과 합의를 맞춰가며 계속해서 개발을 진행해나갔다. 서비ㅡ가 거의 완성되어갈 즈음이라서 QA 테스트 케이스가 작성되기 시작했다. 그리고 기획자분들이 베타 런칭도 진행해 주셨다. 데이터 분석을 위한 GA도 세팅에 들어갔다. 런칭이 점점 다가온다는 생각이 들어서 들떠 있었다. 결과적으로는 3달이나 후에 런칭할 수 있었지만...

2024.02

먼저 개발팀 자체 QA가 진행되었다. TC 기반으로 제대로 하기보다는 치명적이거나 화면만으로 발견하기 힘든 기술적인 문제들을 사전에 제거하고자 했다. 통신판매업 신고 등등이 이루어져야 제대로 개발할 수 있는 부분들도 개발하기 시작했다.

2024.03

3월부터는 팀원 전체가 QA에 나섰다. 프론트 쪽 배포가 최종적으로 마무리되어서 이제 사용자에게 공개될 사이트가 제대로 만들어졌다. 팀원 전체가 TC를 보면서 버그를 보고하기 시작했고, 그래서 발견된 버그량이 급증했다. 모두가 QA에 참여했기 때문에 중복으로 보고된 버그가 많아서 여러 가지로 힘들었던 기억이 있다. 아무튼 3월에는 나를 포함한 프론트엔드 개발자 2명이 주에 20개씩 버그를 해결하면서 런칭 준비에 매달렸다. 힘들면서도 뿌듯한 작업이었다.

2024.04

4월에는 버그 픽스가 마무리되었다. 한 달 내내 QA만 해서 심적으로 매우 피로했었다. 그래도 해냈다는 사실에 큰 보람을 느꼈다. QA가 마무리 되어가며 각 파트 모두가 런칭 준비에 몰두했다. VWO를 이용한 Split test를 진행해 보려고 가설을 세웠고, 테스트 세팅을 시작했다. 데이터 분석을 위해 GA4도 심었다.
하지만 결과적으로 Split test는 도메인도 2개 이상을 구매해야 하고 생각보다 세팅이 번거로워서 시간 관계상 시도하지 못 했다. 대신 우리가 유리하다고 생각하는 가설을 바탕으로 마지막으로 사이트를 수정하고 배포를 시작했다. 서치 콘솔에 우리 사이트를 등록해서 구글과 네이버에 노출되는 것을 확인했을 때 큰 뿌듯함을 느꼈다.

2024.05

기존에 PM을 맡아주셨던 분이 더 이상 PM을 맡기 어려울 것 같다는 의사를 전해 왔다. 본격적인 배포 직전에 청천벽력 같은 소식이었지만... 아끼는 프로젝트였기 때문에 내가 PM을 이어서 하기로 했다. 그래서 인수인계와 배포 준비를 함께 진행했다.
대학생과 대학원생을 타겟으로 마케팅을 진행해야 했기 때문에 에브리타임에 배포를 시작했다. 본격적으로 사용자가 들어오기 시작했고 실제로 결제도 발생했다. 학부 프로젝트에서 리드를 맡아본 적은 종종 있었지만, PM을 제대로 맡아본 건 처음이라서 많이 헤맸고 정말 힘들었다. PM 일이 힘들면서도 프로젝트가 앞으로 나아가는 모습을 보면 뿌듯하기도 했던 것 같다.

2024.06

...ing.
지금부터는 내가 프로젝트를 하면서 느낀 점들, 좋았던 점과 나빴던 점, 다시 하고 싶은 것과 다시는 하고 싶지 않은 것들에 대해 이야기해 보려고 한다.

📌 프로젝트 회고

기술 관련 회고

✅ 코드리뷰 귀찮아서 대충 하면 나중에 더 귀찮아진다...

이번 프로젝트는 코드 리뷰를 처음으로 제대로 진행해 본 프로젝트였다. 그럼에도 불구하고 아쉬운 점이 많았다. 시간이 여유로울 때는 이 파일 저 파일 옮겨가며 코드 구조를 파악하고, 구조를 개편하거나 쓸모없는 코드를 제거하면 좋겠다는 식으로 상세한 리뷰를 해줬다. 하지만 시간에 쫓길 때는 대충 보고 Approve를 하거나, 배포에 실패하지만 않으면 일단 merge 하고 나중에 보겠다고 한 적도 많았다. 그리고 이게 결과적으로 나쁜 결과를 낳았다.
나중에 QA를 진행할 때 변수명이 정말 직관적이지 않은 코드를 발견했다. 눈치채지 못한 게 이상할 정도였다. "이걸 왜 코드리뷰에서 걸러내지 못 했지?" 라고 생각하면서도 어렴풋이 그때 이정도는 괜찮겠지~ 하며 넘겼던 게 기억이 났다.

또한 서로의 코드를 이해하지 못 해서 협업이 아닌 분업을 하게 되어버린 적도 있었다. 예를 들어, 나 말고 다른 개발자가 A 파트를 개발했는데 이 친구가 바쁠 때 A 파트에서 오류가 발생한 적이 있었다. 내가 A 파트에 대한 코드리뷰를 꼼꼼히 했으면 이 부분에 대한 이해가 잘 되어 있고, 그렇기 때문에 내가 대신 버그 픽스를 해줄 수 있었겠지만, 이 부분의 코드를 이해하지 못해서 오류를 대신 고쳐주지 못한 적이 있었다. 이때 이 부분에 대해 코드 리뷰를 제대로 했으면 서로가 납득할 수 있는 방향으로 코드를 수정했을 거고, 그럼 둘 다 이 코드에 대한 이해도가 높아졌을 텐데 그러지 못한 게 후회가 되었다.

코드리뷰 물론 귀찮고 하기 싫은 일이다. 하지만 미루고 대충 하면 나중에 더 귀찮아진다... 코드가 쌓이고 쌓일수록 이전에 코드리뷰를 제대로 하지 않은 것에 대한 후폭풍이 찾아올 가능성이 높아진다. 앞단에서 최대한 서로의 코드에 대한 합의와 이해를 만들어놓자.

✅ 새로운 스택을 도입할 때는 충분한 조사와 공부를 하자.

이번 프로젝트에서 꼭 제대로 활용해 보고 싶었던 기술 스택이 react-query와 jest였다. 하지만 결과적으로는 둘 다 사용해 보지도 못 했다. 나는 그 원인을 "해당 기술 스택에 대한 사전 공부를 하지 않았기 때문에"라고 생각한다.

프로젝트 개발에 들어가면 정말 바빠지고 시간에 쫓긴다. 여유롭게 기술 스택을 공부하면서 적용할 시간이 없다. 라이브러리를 직접 사용하면서 이해도를 높여갈 수 있는 사람이면 상관없겠지만, 공교롭게도 나는 그 정도 레벨도 못 되고, 그런 스타일도 아니었다. 나는 먼저 공식 문서를 보면서 테스트 코드도 따라해 보고, 여러 레퍼런스도 찾아보면서 라이브러리에 익숙해지는 스타일이다. 하지만 프로젝트 개발을 하다 보면 그렇게 여유롭게 공부하고 적용해 볼 시간이 생각보다 없다. 없어도 개발을 진행할 수 있는 라이브러리면 더더욱 그렇다.

결국 제대로 사용해 본 라이브러리는 프로젝트를 시작하기 전에 공식 문서를 둘러보면서 공부해 본 Jotai가 유일했다. 미리 공부해 봤기 때문에 프로젝트를 진행하면서도 자연스럽게 적용할 수 있었고, 사전 지식이 있으니까 사용하면서 적응해 갈 수도 있었다.

그래서 지금 공모전을 준비하면서는 jest를 미리 공부하고 있다. 시간이 조금 들어가도 아예 사용하지 못 하게 되는 것보다는 낫다고 생각한다.

✅ "모든 것은 바뀔 수 있다"

이번 프로젝트를 진행하면서 정말 뼈저리게 느낀 게 "확장 가능성이 얼마나 중요한지"다. 기획자와 함께 프로젝트를 진행하면 개발적인 변경 사항이 많을 수밖에 없다. 기획자들은 개발이 진행되는 중에도 끊임없이 서비스를 검증해 나가고, 그 과정에서 그들이 미리 설정했던 가설이 틀렸다는 결론이 나오면 그에 맞춰 기능과 화면을 변경해야 한다. 이게 나쁘다는 게 아니라 당연한 것이기 때문에 개발자가 그에 적응해야 한다는 말을 하고 싶다.

기획자, 디자이너, 개발자들이 모두 공감할 수 있는 문장이 "더 나은 서비스를 위하여 노력한다"라고 생각한다. 기능과 화면의 변경으로 서비스가 더 나아질 수 있다면 응당 그렇게 해야 한다. 그렇기 때문에 개발에서 가장 중요한 건 확장 가능성이 높은 코드를 설계하는 일이다. 기획자들이 기획 단계에서 "이 부분은 바뀔 수도 있을 것 같다", "저 부분은 바뀌지 않을 것 같다", 확실하게 말해줄 수 없다. 기획자는 미래를 예측하는 마법사가 아니라 서비스의 가능성을 끊임없이 실험하고 검증하는 사람이다. "이 부분은 안 바뀔 것 같아"라고 안일하게 확신해서 대충 짜지 말고, 모든 부분은 추후 수정될 가능성을 염두해 두고 확장 가능성 높게 설계하자.

✅ 자잘한 문제들 나중으로 미루지 말자. 최대한 앞단에서 해결하자.

QA에서 지옥을 맛봤다... 처음 서비스를 개발하면서 "이 부분은 기획과는 조금 다르지만 중요한 부분은 아니니까 나중에 처리해야겠다"라고 미루고 처리하지 않는 경우가 종종 있었다. 한두 번은 괜찮을 수 있지만, 보통 한두 번만 이러지 않는다...(ㅋㅋㅋㅋ) 이것들은 결국 QA에서 아주 세세하게 걸러진다. 또한 앞단에서 개발할 때는 별 거 아닐 수 있지만, 코드가 쌓이고 쌓여서 완성품에 가까워진 지금은 그때보다 유지보수가 훨씬 어려울 수 있다. 그렇기 때문에 귀찮아도, 별 거 아니어도 앞단에서 처리하는 게 좋다! 정말 당연한 말이지만 막상 개발을 할 때에는 자꾸만 바보같이 미루고 싶어지는 것 같다...

커뮤니케이션 관련 회고

✅ 슬랙으로 논의할 수 있는 사항과 회의에서 논의해야 하는 사항을 구분해야 한다.

슬랙에서 논의할 수 있는 내용을 붙들고 회의 날까지 기다리는 건 어리석은 일일 수 있다. 의사소통의 효율을 위해 슬랙으로 논의할 수 있는 사항과 회의에서 논의해야 하는 사항을 구분하는 건 필수적이다. 슬랙에서는 주로 질문과 그에 대한 답, 팀원 전체의 의견을 들어볼 필요까진 없고 특정 파트와의 짧은 논의를 통해 해결할 수 있는 사항을 논의하면 좋을 것 같고, 회의에서는 팀원 전체에게 알리거나 함께 이야기할 필요가 있는 사항, 팀원 전체의 의견을 들어보고 싶은 사항 등을 논의하면 좋을 것 같다.

개인적으로 우리 팀은 이것 때문에 많은 비효율을 겪었다고 생각한다. 회의 중에 "근데 이건 회의에서 이렇게 이야기할 건 아닌 것 같고 슬랙으로 전달해주시면 좋을 것 같아요" 이런 적이 정말 많았다. 슬랙에서의 논의 사항과 회의에서의 논의 사항을 엄격하게 분리할 수는 없겠지만, 스스로 생각했을 때 이건 슬랙에서 해결할 수 있다거나 회의에서 이야기해야만 하는 내용이라는 걸 기본적으로 분리할 수는 있어야 한다고 생각한다.

✅ 모든 것을 물어보고 조율하면서 할 수 없다. 시간이 부족할수록 더 그렇다.

스토리보드를 보고 작업했을 때의 일이다. 우리 개발자들은 Description이 없거나 모호한 부분에 대해서 기획자와 디자이너 분들에게 끊임없이 질문을 하고 답변을 들은 다음 개발을 진행했었고, 그래야만 한다고 생각했다. 그런데 지금 생각해 보면 꼭 그렇지만도 않은 것 같다.
우리는 시간이 정말 중요한 상황이었다. 하지만 위에서 설명한 과정을 거치려면

① 작업하려고 피그마에 접속한다
② 잘 모르겠는 Description이 있으면 슬랙으로 기획자에게 질문한다
③ 답변을 기다린다. 기다리는 동안 보통 다른 일을 하고 있지만, 이 부분이 개발되어야 넘어갈 수 있는 부분이면 그냥 하염없이 기다린다...
④ 기획자가 답변을 달아준다.
⑤ 납득했으면 바로 다시 개발 작업에 들어가면 되지만, 여전히 이해할 수 없으면 추가적으로 계속 질문을 하고 답변을 받는 과정을 거쳐야 한다.

이 과정에서 정말... 많은 시간이 들어갔다고 생각한다. 물론 이 과정이 불필요하다고 생각하지는 않는다. 모호한 부분을 개발자 임의로 개발했다가는 기획 의도에서 벗어날 수도 있고, UI/UX에 개발자보다 전문화 되어 있는 기획자나 디자이너들보다 정확한 의사결정을 내릴 수 있다는 보장도 없다. 하지만 시간과 효율을 생각했을 때 타협해야만 하는 부분도 분명히 있다는 이야기가 하고 싶다. 마음대로 개발하라는 말이 아니라 스스로 판단할 수 있는 부분은 일단 개발을 진행하고 추후에 기획자와 디자이너에게 컨펌을 받는 방식이 훨씬 효율적일 수도 있다는 말을 하고 싶다.

실제로 런칭이 코앞으로 다가왔을 때 회원가입 flow가 한 번 크게 바뀐 적이 있었다. 시간에 많이 쫓기는 상황이었기 때문에, 기획자들이 화면과 flow만 그려주고 잘 모르겠는 부분은 질문을 통해 해결하면 좋겠다고 말해주셨다. 그렇게 개발을 진행하다 보니 질문하고 싶은 부분들이 너무 많았다. Description이 없었으니까 이 부분이 이렇게 수정되는 게 맞나 싶은 부분들이 계속 보였다. 하지만 그 순간 "일일이 질문하는 건 너무 비효율적인 것 같고, 나도 UI/UX에 대해 아주 문외한인 건 아니니까 일단 개발을 해 보고 컨펌을 받는 게 나을 것 같은데?" 라는 생각이 들어서 그렇게 해 본 적이 있었다. 그랬더니 기획자분이 아주 좋은 작업 방식이었던 것 같다고 칭찬을 해 주셨다(‼️) 그래서 진작에 이렇게 할걸...이라는 생각도 들었다...

물론 이 방법은 많은 주의가 필요하다. 임의로 작업해도 될 것 같은 부분과 꼭 물어보고 진행해야 하는 부분을 잘 생각해서 행동해야 한다. 그리고 임의로 진행하고 나중에 컨펌을 받는 방식으로 진행해도 될지 기획자와 디자이너분들께 사전에 양해를 구하는 게 중요할 것 같다. 그렇지 않으면 그분들이 무시받는다는 느낌을 받을 수도 있을 것 같다.

✅ 기획자, 디자이너들이 현 개발 상황을 알 수 있는 방법이 필요하다.

단순히 "회원가입 개발 완료", "로그인 개발 완료"로는 서비스 개발이 정확히 어떻게 진행되고 있는지 알 수 없다. 기획자와 디자이너들이 궁금해하는 건 정확한 화면과 상호작용이다. 이번 프로젝트는 서비스 개발에 빨리 돌입해야 한다는 부담이 있어서 CI/CD를 제대로 구축하지 않고 화면 개발부터 들어갔었다. 그래서 기획자와 디자이너들이 우리 사이트에 직접 접속해서 개발이 잘 진행되고 있는지 알 수 있는 방법이 없었고, 나는 지금 생각해 보면 이게 정말 안 좋은 협업 방식이었다고 생각한다.

사전에 화면을 공유했더라면 기획자들이 아쉬운 점이나 부족한 점, 막상 화면을 보니 바뀌어야 할 것 같은 점들을 미리 알고 고쳐나갈 수 있었을지도 모른다. 그럼 QA 단에서도 훨씬 덜 힘들었을 거고, 기획자들이 방향성을 잡아가는 데도 많은 도움을 줄 수 있었을 것 같다. 물론 개발 과정에서는 힘들었을 수도 있다. 다음 개발을 진행하지 못 하고 앞의 오류를 잡고 넘어가야 했을 테니까. 장단점이 있을 테지만 앞서 회고했듯이, 앞단에서 해결할 수 있는 문제는 최대한 앞단에서 해결하는 게 좋다. 이 사실은 불변한다...

✅ 대면 회의와 비대면 회의의 장단점

대면 회의와 비대면 회의는 장단점이 명확하기 때문에 상황에 따라 잘 활용하는 게 중요하다. 처음에 나는 비대면 회의가 무조건 효율적일 거라고 생각했다. 왜냐면 대면으로 회의하는 장소가 모든 팀원들의 중간지였기 때문에 나는 왕복으로 2시간 반 정도가 걸리는 거리였고, 이동 시간에 대한 비효율이 너무 크다고 생각했다.

하지만 지금은 생각이 바뀌었다. 대면 회의는 비대면 회의에 비해 큰 장점이 있기 때문이다. 바로 소통이 효율적이라는 거다. 이게 무슨 말이냐면... 내가 비대면 회의를 진행해 보면서 느낀 점인데 전체 회의에서는 비대면으로 진행하면 회의에 집중하지 않는 사람이 분명히 생긴다. 각 팀원들이 내 화면을 보고 있는지 다른 일을 하고 있는지, 내 말을 듣고 있는지 안 듣고 있는지, 이런 것들을 제대로 파악할 수가 없다. 실제로 회의 내내 한 마디도 안 하거나 말을 걸었을 때 곧바로 대답하지 않는 팀원도 있었다. 분명 회의때 나누었던 이야기인데 나중에 보면 그 이야기를 모르거나 틀리게 알고 있는 팀원들도 있었고, 명백한 문제 상황이라고 생각했다. 대면 회의는 적어도 얼굴을 보고 진행하니까 누가 내 이야기에 집중하고 있는지, 또는 집중하고 있지 않는지를 바로 알 수 있다.

결국 소통의 효율이냐, 시간의 효율이냐, 양자택일의 문제다. 참여자의 입장에서는 시간의 효율이 중요했는데, 진행자의 입장이 되어 보니 소통의 효율이 정말 중요하다. 사실 팀원들이 모두 회의에 제대로 집중해주면 해결될 문제이지만, 그렇게 만들기 어렵다면 진행자가 적절한 회의 방식을 선택해야 한다.

직무 관련 회고

참고로 나는 그냥 프론트엔드 개발자였다가, 개발팀 리드가 되었다가, 지금은 PM으로 참여하고 있다. (아마 곧 인수인계를 할 것 같지만...)

✅ 사이드 프로젝트의 근태 관리는 회사에서의 근태 관리와 다르다.

대학생들끼리 하는 사프는 회사처럼 돈을 받고 하는 활동이 아니고 대부분 직무 경험을 쌓기 위해, 본인의 성장을 위해 하는 것이다. 그렇기 때문에 열심히 하지 않는 팀원이 있어도 열심히 해야 한다고 말할 명분이 별로 없다. 개인 공부보다 조금 더 책임감을 가지는 정도로 생각하는 팀원도 있을 것이다. 다른 팀원보다 열심히 해서 성과를 낸다고 성과급을 주는 것도 아니다. 그래서 동기부여가 굉장히 중요하다. 팀원들이 어떤 상황에서 동기가 부여되고, 어떤 것을 위해 열심히 하는 사람인지 파악하는 게 중요하다.

우리 팀도 동기부여 문제로 정말 우여곡절이 많았다. 의욕이 떨어지는 원인을 찾기 어렵기도 했고, 개개인이 동기부여되는 상황이 모두 달라서 얼라인 시키기도 힘들었다. 사실 이 문제는 지금도 현재진행형이다. 해결된 팀원도 있고 여전히 동기부여가 되지 않는 팀원도 있는 것 같다. 나 같은 경우에는 해결된 팀원에 속하는데, 내가 어떤 상황에서 동기부여가 되는지 파악한 게 핵심이었던 것 같다.

나는 나 스스로 성장했다고 느끼거나 새로운 지식이 쌓일 때, 또는 쌓여 있는 태스크들을 하나씩 처리해나갈 때 동기부여가 잘 되는 타입이다. 그래서 의외로 QA를 할 때 가장 의욕이 불타올랐다. 쌓여 있는 버그들을 내 손으로 하나씩 지우는 작업에서 큰 보람을 느꼈고, 버그의 원인을 파악하면서 배운점이 많다고 생각했다. 물론 항상 QA 같은 작업들이 주어지는 건 아니다. 내게 주어진 태스크들을 가지고 내가 동기부여를 잘 받을 수 있는 환경을 만드는 게 중요한 것 같다. 최근에는 프로젝트 외적인 공부도 하고, 기술 세미나 등을 계획하면서 번아웃에 빠지지 않도록 노력하고 있는 것 같다.

✅ 사이드 프로젝트에 참여하는 팀원들의 책임감은 모두 다를 수 있다.

앞서 말했듯이, 사이드 프로젝트는 회사에서 하는 일처럼 돈을 받고 하는 것이 아니기 때문에 프로젝트에 참여하는 목적이나 이루고 싶은 목표가 모두 조금씩 다를 수밖에 없다. 그렇기 때문에 사람마다 이 프로젝트를 얼마나 중요하게 생각하는지, 이 프로젝트에 쏟을 수 있는 시간이 얼마인지 역시 모두 다를 수 있다. 처음 PM이 되었을 때, 이 당연한 사실을 받아들이지 못 해서 많이 힘들어했다. '나만 이 서비스를 진지하게 생각하는 것 같아' 라는 삐딱한 생각을 많이 했다. 나는 이 프로젝트에 시간을 쏟느라 다른 많은 기회들을 포기했는데, 다른 팀원이 우리 팀 태스크는 해 오지 않고 다른 일을 하고 있으면 속상하고 기분이 좋지 않았다.

하지만 내가 열심히 해서 잃은 건 없다. 내가 남들보다 열심히 하면 손해본다는 마인드를 바꿔야 한다. 심지어는 '실패'에서도 배울점이 있는 게 인생이다. 다른 팀원들이 나보다 열심히 안 한다고 나 혼자 고생한다고, 나 혼자 손해 보고 있다고 땅굴 파면 결과적으로 나만 힘들다. 팀원들이 바뀌기 어렵다면 내 마인드를 바꾸는 수밖에 없다. 내가 이걸 열심히 해서 잃는 것보다 이걸 열심히 했기 때문에 얻을 수 있는 것들에 집중해야 한다.

나는 PM 일을 하면서 기획, UX, 리드 관련 책을 5권? 정도 읽었는데 내가 평소에 얻고 싶었던 지식들을 많이 얻을 수 있는 시간이었다. 리딩 능력도 많이 늘었고, 서비스와 프로젝트에 대한 이해도도 높아졌다. 기획자들만 만져보던 각종 툴들도 따라 만져봤고, 전체적으로 시야가 넓어졌다는 생각이 많이 들었다. 팀 프로젝트를 하다 보면 손해 보지 않으면 이득 볼 수도 없는 상황이 있다. 항상 잃는 것 말고 얻는 것에 집중하자!!

✅ PM은 귀찮은 일, 힘든 일, 어려운 일을 해 주는 사람이 아니다.

PM 일을 하면서 했던 가장 큰 실수가 귀찮은 일, 힘든 일, 어려운 일을 내가 다 도맡으려 했다는 것이다. 사프 특성상 모두 기획, 디자인, 개발에만 몰두할 수 없다. 사용자들에게서 오는 문의에도 답장해줘야 하고, 지원 사업 관련해서 서류 준비도 해야 하고, 여러 가지 계약도 신경써야 하고 그렇다. 나는 각 파트 팀원들이 해당 파트에서 원래 해야 하는 일 이외의 다른 자잘한 일들을 하게 되면 동기부여가 떨어질 것이라고 생각해서 CS 담당이나 지원 사업 관련해서 서류 준비 하는 일 등을 거의 내가 도맡아 했다. 결과적으로는 그것 때문에 나 한 사람의 피로도가 정말 높았다.

이런 귀찮은 일들은 분배해야 한다. 한 사람이 맡다 보면 아무리 열정적인 사람이라도 금방 지쳐버리고 결과적으로는 의욕이 떨어질 수밖에 없다. 그리고 분산 투자의 원리와도 같이, 그 모든 일을 감당하던 사람이 팀을 나가거나 일을 할 수 없는 상황이 되면 팀은 큰 패닉에 빠진다. 귀찮은 일을 분배하는 건 PM 한 사람만 좋은 일이 아니다. 팀 전체를 생각했을 때도 분배는 꼭 필요하다. 한 사람이 100을 짊어지는 건 힘들지만, 여러 사람이 10씩 짊어지는 건 모두 동기부여를 잃지 않고 앞으로 나아갈 수 있는 가장 좋은 방법이다.

기타 회고

✅ 시간과 돈이 생명이다!...

새 서비스를 준비하는 일은 시간이 정말 중요하고, 대학생들끼리 하는 프로젝트는 돈이 중요하다는 것을 느꼈다.

사용자의 액션이나 피드백은 서비스를 운영하는 사람들에게 큰 동기부여가 되어준다. 사람들이 괜히 애자일을 강조하는 게 아니다. 워터폴 방식으로 진행하다 보면 서비스 개발 기간이 길어지고, 사용자 피드백을 받아볼 수 있는 기회는 자연히 미뤄질 수밖에 없다. 그 과정에서 여러 팀원들의 사기가 저하되었고, 그 시기동안 다른 일이 생겨서 하차하는 팀원들도 있었다. 철저한 검증 과정을 거치는 것도 좋지만, 우리의 서비스를 빠르게 시장에 내놓고 사용자의 피드백을 받아보는 게 중요하다.

돈은 사이드 프로젝트에서 중요한 것 같다. 대학생들끼리 하는 프로젝트는 여기저기 창업 지원 프로그램을 알아보면서 지원금을 타내야 한다. 우리도 그런 식으로 타 온 지원금이 있긴 하지만, 결코 여유롭다고 말할 수준은 아니다. 정말 본격적인 마케팅에 들어가면 돈이 더 많이 들어갈 테고, 지속적으로 나가는 금액(서버비 등)도 항상 생각해야 한다. 당연히 써야 할 때는 강단 있게 써야겠지만, 아낄 수 있을 때는 아껴야 하는 것도 맞다. 그리고 피치못할 상황을 생각하면 여윳돈은 꼭 있어야 한다...

✅ 분업이 아닌 협업을 하자.

우리 팀은 오랫동안 협업이 아닌 분업을 해 왔다. 회의에서 서로의 진행 상황을 공유하기는 했지만, 서로가 모두 다른 문제에 집중하고 있다는 인상이 강했다. 그래서 각자의 파트에 몰두하느라 소통도 부족했고 서로에 대한 이해도 부족했다고 생각한다. 예전에 분명 기획이 이런 일을 하고 있다고 공유해줬는데, 이런 일을 진행한지도 몰랐던 개발팀원도 있었다. 팀원 전체, 특히 기획자의 동기부여가 떨어진 건 이 원인이 가장 크다고 생각했다.

그래서 런칭 직전에는 린 프로세스를 도입하여 팀원 전체가 스프린트 기간동안 하나의 문제에 집중하도록 하려고 했다. 지금은 서비스 운영이 너무 바빠서 잠시 미뤄두고 있지만... 서비스 초기 단계가 지나면 아마 다시 이 방식으로 운영하지 않을까 싶다. 이 프로세스를 진행하면서 다른 기획자들처럼 우리 서비스의 문제점도 파악해 보고 가설도 세워 보았다. 그 과정에서 기획자분들이 인사이트가 좋다고 칭찬해주시기도 했고, 나 스스로도 이런 문제 찾기 과정에 큰 재미를 느꼈던 것 같다. 나는 이 방식이 우리 팀에 다시 활기를 불어넣어 줄 거라고 믿고 있다. 원팀처럼 움직이는 팀이 되고 싶다.

✅ 팀 관리도 컴포넌트 관리와 유사하다.

리액트에서 컴포넌트를 구축하는 이유는 무엇인가? 바로 "재사용성" 때문이다. 나는 기획 쪽 지식이 부족하기 때문에 서비스를 이끌기보다는 팀을 이끄는 PM에 좀 더 집중하려고 했다.(둘 다 잘해야겠지만...) 그래서 팀 내에서 놓치고 있는 부분이나 반복되는 부분 등을 찾아서 프로세스를 정립하려고 노력했던 것 같다.

예를 들어 설명해 보면 우리는 매주 에브리타임 배포를 진행하고 있다. 이 배포 과정은 매주 조금씩 달라지고, 그래서 회의 때마다 회의 안건지에서 금주의 배포 방법을 공유받는 식으로 진행되었다. 하지만 이런 방법으로 진행하면 항상 배포를 할 때 회의 안건지를 뒤져서 배포 방식을 찾아야 했고, 배포 일정이 매주 달라지니까 시간이 헷갈려서 배포를 진행하지 않는 팀원들도 많았다. 그래서 재사용되는 부분들을 형식화 해서 팀원들이 쉽게 접근할 수 있게끔 문서를 만들었다.

배포 텍스트와 배포 계획은 그때마다 달라질 수 있기 때문에 문서 상단에 배치했다. 배포 관리자는 앞으로 회의 안건지에 금주의 계획을 일일이 작성하지 않고, 이 문서의 배포 계획만 수정해주도록 했다.

각 대학 담당자는 변하지 않을 것이기 때문에 DB로 만들어서 한군데에서 관리하도록 했고, 팀원들의 배포 시행 여부를 알 수 있는 컬럼도 추가했다. 이처럼 프로젝트에서 반복되고 있는 부분을 재사용 가능한 단위로 묶어서 제작하는 게 리액트 컴포넌트의 모습과도 같아서 하면서 재밌다는 생각이 들었다.

✅ 마감 기한은 현실적으로 가능한 기간으로 설정하자.

마감 기한은 정해놓고 지키지 않는 기한이 아니라, 정했으면 지켜야 하는 기한이다. 혼자서 하는 개인 프로젝트가 아니기 때문에, 각 파트는 다른 파트의 진행 상황을 보면서 플래닝을 할 수밖에 없다. 즉, 개발팀의 마감 기한이 지켜지지 않으면 기획, 디자인이 피해를 볼 수 있고, 반대의 경우도 가능하다. 그래서 마감 기한은 가볍게 생각하지 말고, 팀 프로젝트에서는 정말 잘 생각하고 고민해서 정해야 한다는 것을 깨달았다.

물론 마감기한을 지켜야 한다는 강박 때문에 너무 여유롭게 설정해도 문제가 있다. 사람이 쉽게 루즈해지고 일을 미루게 된다. 더 빨리 처리할 수 있는 일이어도 처리하지 않는 경우도 있다. 그래서 "내가 실제로 처리할 수 있을 것 같은 기한"과 "아무리 늦어도 이때까지는 처리해야 한다는 기한", 이 사이에서 유동적으로 정하는 게 가장 좋은 것 같다. 부가적으로 중요한 것은 마감 기한에 딱 맞춰서 태스크를 완료하겠다는 생각보다는, 할 수 있으면 최대한 빨리 처리해야겠다는 마인드다. 늦으면 계획에 차질이 생기지만, 빠른 건 보통 문제가 없다. 물론 마감기한조차 지키지 않을 거라는 마인드보다는 마감기한에 맞춰서 완료하겠다는 생각이 훨씬 낫긴 하다...

📌 맺음말

회고글이 이렇게까지 길어질지는 몰랐는데... 쓰다 보니 정말 길어져버렸다. 심지어는 지금 당장 생각나지 않아서 못 쓴 것들도 많은 것 같다. 그만큼 배운 점도 많고, 힘들었던 점도 많고, 좋았던 점도 많고... 김선배는 나한테 정말 아픈 손가락 같은 프로젝트다. 떠올리면 힘든 일들이 정말 많이 생각나지만 마지막에는 항상 그래도 좋았다는 결론을 내리게 된다.

아직 어떻게 될지 모르는 일이긴 하지만 다음달부터는 아마 다른 분이 PM을 이어나갈 것 같다. 나는 다른 곳에서도 PM을 맡고 있기도 하고, PM에 더 어울린다고 생각되는 분이 계셔서 그분이 프로젝트를 리딩해주실 것 같다. 오랜 기간 개발팀 리드로, 짧은 기간동안 PM으로 활동해 보았다. 내가 팀원들에게 어떤 개발자로, 어떤 리드로, 어떤 PM으로 기억될지는 모르겠다. 적어도 최악은 아니었다고 믿고 싶다(ㅠㅠㅋㅋㅋㅋ) 못 해도 항상 응원해주는 팀원들이라 고마움 반, 걱정 반인 것 같다. 그래도 나는 이 프로젝트가 어떤 사람이 이끌어도, 어떤 팀원들이 활동을 해도, 어떤 끝맺음을 하게 되더라도 훌륭한 경험으로 남을 거라고 생각한다.