[yoo/개발] 개발하다가 평생 새우(🦐) 못먹게 된 이야기 - 사이드 프로젝트 절대 이렇게 하지마세요

스스로를 포함해서 친구들이 하나 둘 직장인이 되어가고, 서로 회식과 출장의 이유로 회의 불참을 이해하기 시작할때쯤. 아니면 더 이상 새로운 기능 개발에 속도가 붙지 않을때였을까? 언젠가는 트리브에도 끝이 올거라는걸 직감하고 있었습니다. 너무나 사랑했던 트리브를 이제는 마무리 하며 앞의 글 사이드 프로젝트 5년째, 우리 앱 정상 영업합니다에서는 트리브 전체에 대한 이야기를 했다면, 이번에는 사이드 프로젝트를 이끌며 겪었던 리더로서의 고충, 그리고 개발자로서의 개인적인 회고를 적어보려 합니다. 

 

시작은 이랬습니다

트리브를 시작하게 된 계기는 도키의 글 나는 어떻게 여행하고 싶을까?에서 언급된 바와 같이 일상적인 카톡 대화에서부터였습니다. 여행 중 비롯되는 트러블은 서로의 여행 성향에 대해 너무 모르기 때문이라는 생각을 하게 되었고, 간단한 질문지를 앱으로 만들면 어떨까라는 아이디어가 떠올랐습니다. 그 후 전공 수업의 팀 프로젝트 주제로 이를 선택했고, 팀원을 모아 학기 말에는 간단한 성향 검사와 여행 생성 기능이 있는 수준까지 개발을 완료했습니다.

 

종강 후, 플레이스토어에 런칭할 정도의 수준으로 앱을 완성하기 위해 트렌디한 디자이너가 필요하다는 생각에 가르디를 꼬셔왔고, 6개월 후 안드로이드 앱을 출시했습니다. 이제 iOS 앱도 있으면 좋겠다고 생각하던 참에 마침 같은 학번 동기인 희희와 밍글이 iOS 개발을 한다는 소식을 듣고 밥을 사주며 접근했습니다. '너 취업해야하지? 나랑 포폴만들자! 기획/디자인/서버 다 줄게 개발만 하면돼'와 같은 사탕발림으로 팀에 합류시켰습니다.

 

그때부터 iOS 앱을 개발하며 안드로이드 앱의 UI도 새롭게 변경했습니다. 기능 개발에만 집중했던 이전과 달리, 유지보수를 하며 아키텍처에 대한 고민을 시작했습니다. 반복되는 코드를 공통화하고, 스파게티 코드를 걷어내며 중구난방이던 코드를 정리했습니다. 1년 후 어느정도 개발적으로 안정화가 되고 나니 ‘우리 앱 진짜좋은데 왜 안쓰지? 마케팅이 필요하다’는 생각에 마케팅 직무로 진로를 생각하고 있는 바바를 데리고 왔습니다. 그 다음부터는

‘언니, 1n학번에 누가 뭘 잘한대’ → 꼬셔와

 

흡사 다단계처럼 능력있는 친구들을 모아 팀을 확장해 나갔습니다. 그 결과 16학번인 저부터 매번 언제 졸업하냐고 물어봐야 하는 21학번 막내까지 각자의 관심사를 가진 10명의 친구들이 한 팀에 모이게 됐습니다.

 

 

처음부터 PM을 할 생각은 아니었는데요

이렇게 친구들을 모으고 보니 막중한 책임감이 생겼습니다. 사이드 프로젝트가 순탄하게 이어지기 위한 필수 요건으로는 여러가지가 있을 수 있지만, 중간에 엎어지게 되는 가장 큰 이유는 의지라고 생각합니다. 따라서 자연스럽게 팀 분위기와 회의 방식에 대한 고민을 많이 하게 됐습니다. 

 

1️⃣ 우리 팀에 맞는 작업 방식 찾기

먼저, 팀의 특성을 파악하는것이 중요했습니다. 저희는 인원이 많고 모두가 멀리 살기 때문에 오프라인에서 모이기 힘들다는 문제가 있었습니다. 따라서 회의는 줌으로 진행해서 이동시간을 줄이고, 주 1회 고정된 회의시간을 정해두어 최대한 일정을 확보할 수 있도록 했습니다. 그 외의 시간에는 슬랙을 통해 작업 상황을 공유하도록 했는데 자세한 사항은 슬랙으로 사이드 프로젝트 관리하기 - 공지, 이슈 트래킹, 스크럼, 출석 관리까지 한 번에에 작성해 두었습니다.

 

또한, 팀원들이 회의 중에 의견을 내고 싶어도 회의가 길어질까 봐 선뜻 의견을 내지 못하거나, 자기 분야가 아니라 괜히 선을 넘는 것 같아 조심하는 경우도 있었습니다. 이 문제를 해결하기 위해 모두의 의견을 절충하는 방법도 시도해 보고, 돌아가면서 모두가 말하게도 해봤습니다. 하지만 나중에는 ‘도키는 어떻게 생각해?’와 같이 특정 사람을 지목하는 방법을 선택했습니다. 이렇게 몇 명의 의견을 들은 후 ‘혹시 더 의견 있는 사람 있어?’라고 물어보니 더 적극적으로 대답이 나왔습니다.

 

2️⃣ 효율적인 회의시간 만들기

회의를 주 1회만 진행했기 때문에 다음 논의를 하려면 일주일을 기다려야 했습니다. 또한, 공식적인 활동은 주간 회의가 전부였기 때문에 그 시간을 효율적으로 사용하지 않으면 사이드 프로젝트 자체의 의미가 퇴색된다고 생각했습니다. 따라서 팀원의 수가 적을 때는 회의 전에 각 팀원에게 개인적으로 연락하여 이번 주 회의에 가져오기로 한 작업을 다 했는지, 막힌 부분은 없는지 체크했습니다. 이를 통해 회의가 잘 이루어지도록 준비했습니다. 팀이 커지자 디자인, 개발, 기획, 마케팅 등 각 직군별로 따로 회의를 진행하고, 주간 회의에서는 각 팀의 진행 상황만 공유하는 방식으로 변경했습니다.

 

3️⃣ 방해물 제거하기

팀원들이 프로덕트 개발에만 집중할 수 있도록, 외부 방해를 최소화하는 환경을 조성하는 데 신경 썼습니다. 자잘하고 눈에 보이지 않는 작업들인데요, 예를 들면 '추천여행지' 콘텐츠 입력을 쉽게 하기 위해 내부 인원만 사용할 수 있는 백오피스를 개발하는일이 있습니다. 데이터를 수집하던 시절에는 기획자가 더 효율적으로 정제할 수 있도록 주소변환 프로그램을 작성했고, 마케팅 팀에서 더 빠르게 대응할 수 있도록 앱에서 CS문의가 오면 웹서버의 DB를 거쳐 팀 이메일로 자동 발송되는 시스템을 만들었습니다.

 

또한, 매년 마지막 회의는 회고 시간으로 진행하여, 올해 잘한 것, 아쉬운 것, 내년에 하고 싶은 것을 모아보았습니다. 이 과정에서 가로막고 있는 방해 요소는 무엇인지, 우리가 그리는 방향이 같은지를 함께 확인했습니다.

 

4️⃣ 편안한 팀 분위기 만들기

처음에는 팀원들이 학교에서 선후배 사이거나 친구의 소개로 모인 인원이라 어색함이 있을까봐 걱정을 했습니다. 그래서 수직적이지 않은 팀을 만들려고 했는데, 동생들이 대체로 깍듯하지 않아서인지 큰 어려움 없이 달성할 수 있었습니다. 나이 차이가 나는 팀원들끼리 섞여 있어도 모두가 편하게 의견을 낼 수 있는 분위기가 만들어졌습니다. 또, 작업을 하면서 친구들 사이의 의사소통에 오해가 없도록 하고 어떤 상황에서든 서로에게 날카롭지 않게 하기 위해 노력했습니다. 

 

하지만 너는 개발자잖아.. 

PM으로서 팀을 이끌어 가는 것도 즐겁고 보람있는 일이었지만, 아쉬운 점도 많습니다.

 

먼저, 많은 역할을 하느라 본업인 안드로이드 개발자로서 도전을 많이 해볼 시간을 확보하지 못했던것이 아쉽습니다. CI/CD 환경 구성이나 코드 구조화에 대한 욕심도 있었는데 끝내 하지 못했습니다. PM이나 개발자 둘 중 하나의 역할을 선택하고 집중해서 파고드는 경험을 해봤으면 더 좋았을텐데 늘 시간에 허덕여서 스프린트 마감을 맞추는데 급급했습니다.

 

그 와중에 익숙하지 않은 서버 개발까지 같이 해야하니 시간이 절대적으로 부족했습니다. 안드로이드 개발에 집중하기 위해 늘 서버개발자를 구해야겠다 생각은 했지만 이미 만들어진 레거시 코드들이 너무 많았고 이걸 다 설명하기도, 이어받겠다는 사람을 구하기도 어려웠기 때문에 결국 진행하지 못했습니다. 이런 상황에서 계속 서버 개발은 임시로 하는 것이라고 생각을 하며 작업했기 때문에 현재의 코드에 자신이 없다는 점이 트리브를 마무리 하며 가장 마음에 걸리는 부분이기도 합니다.

 

그러던중 나만 그만두면 아무것도 이어지지 않겠다는 생각이 들었을때 가장 힘들었습니다. 함께하는 팀원들의 문제라기보단 많은 역할을 혼자 하고 있었던 문제였다고 생각합니다. 아주 개인적인 얘기지만, 6년의 연애를 마무리하고 번아웃이 왔던 시기가 있었습니다. 디자인이 끝나서 개발을 시작해야 할 기능들이 쌓여있는데 컴퓨터를 켜는것 조차 힘들었고, 서버는 기다리는 사람이 있기 때문에 여기서 막히면 뒤가 계속 밀리게 된다는 것을 알면서도 도저히 작업을 할 수 없었습니다.

 

기존의 일하던 방식은 아래와 같았습니다. 

초기 디자인이 나오면 서버 개발 시작 → 안드로이드 개발 (여기서 api 문제 없는지 확인) → api 문서 작성 → iOS 개발자한테 넘겨줌

 

개발팀은 저만 기획회의에 참여하기 때문에 이런 순서로 작업을 해야 빼먹은게 없는지, 플로우는 논리적으로 문제가 없는지 확인이 가능합니다. 서버 개발을 먼저 진행하고, 그 후 안드로이드 개발이 끝나면 실제 리스폰스를 기반으로 api 문서를 작성합니다. 이러면 iOS 개발자가 api를 사용하는데에 문제가 거의 없습니다. 하지만 심리적으로 힘든 상황속에 안드로이드 개발을 생략하고 서버만 겨우겨우 작업해서 넘겨주게 되니 문제가 많이 생겨났습니다. 지금까지 계속 사용했던 프로세스가 저 한 명이 멈추니까 무너지는 것을 보고 그때 처음으로 문제가 있다는 것을 느꼈습니다. 나 혼자 너무 많은 일을 하고있었구나!

 

 

그래서 왜 새우를 못먹게 됐나면요,

여기까지 읽으셨다면 눈치 채셨을수도 있지만 알러지가 생겼습니다. 항상 즐거워서 하는 일이니까 괜찮다고 생각했는데 수면 부족과 스트레스로 인한 면역력 저하로 건강에 문제가 생겼습니다. 제가 일하는 시간대를 둘러싸고 ‘24시간중 20시간은 깨어있다’, ‘알고보면 두 명이 돌아가면서 일하는거 아니냐 - 쌍둥이설’ 등 여러 루머가 있었지만 ‘원래 히어로들이 파워가 하나씩 있잖아. 밤 새는게 내 수퍼파워야’라고 자신있게 말하던 저는 사실 저도 모르게 체력을(젊음을..) 갉아먹고 있던 것이었습니다.

 

체력관리 말고도 사이드 프로젝트로서는 작지 않은 팀을 이끌어가는 리더로서 미리 알았다면 더 좋았을 것들을 생각해봤습니다.

✂️ 적당한 선에서 끊을 줄 알아야한다! 

욕심 많고 잘하는 것도 많은 친구들이 모이면 하고 싶은 일이 많아집니다. 아이디어 회의를 하고나면 디벨롭 하고싶은 기능은 늘 산더미였는데 조금만 무리하면 한 스프린트 안에 모두 넣을 수 있을 것 같다는 기분이 들지만 그때가 끊어줄 타이밍입니다.

 

또, 기능 개발을 하며 조금씩 아쉬운 점이 보일때 ‘이것도 붙일까? 저것도 붙일까?’ 하는것도 과감하게 끊어줘야합니다. 완벽을 바라다가 길을 잃어서 점점 속도도 느려지고 눈에 보이는 결과물이 나오는 시기가 늦어지니 사기가 꺾이게 됩니다. 그렇기 때문에 이런 ‘보태보태’가 시작될 때 적절히 중심을 잡고 중재할 사람이 필요합니다. 그게 리더의 역할이었는데 오히려 제가 제일 욕심이 많았던것 같습니다.

 

🥳 매일 신나기만 할 수는 없다

우리 팀의 강점은 모두가 친구이기 때문에 무엇이든 재미있게 할 수 있다는 점이라고 생각해서 언제나 즐거운 분위기를 만들려고 노력했습니다. 하지만 이런 노력이 오히려 친구들에게 부담이 되었을 수도 있습니다. 결과를 내는 데는 성공했어도, '즐겁게 하자'는 강박이 있었던 것은 아닌지, 저의 기준을 친구들에게도 적용하려 했던 것은 아닌지 돌아보게 됩니다.

 

또, 불만이 있다면 문제 제기를 하고 해결 방법을 찾아야 하는데, ‘좋게 좋게 하자’는 분위기 속에서는 이야기를 꺼내기가 어렵습니다. 문제가 생기면 언제나 중심을 잡고 잘 끌고 가면 될 것이라고 생각했는데, 친구들의 고충을 듣고 현실적인 대안을 찾는 게 더 나은 접근이었을 것 같다는 생각을 (이제서야) 하고 있습니다.

 

👥 혼자서 모든걸 하려고 하면 안된다

저는 할 일이 많으면 조금 무리해서 혼자 해버리는 편이었는데, 이건 사실 다른 친구들을 배려하는 것이라기보단 성격이 급한 저의 욕심이었습니다. 1시간 동안 이 일에 대해 설명해 주고 함께 3시간 만에 해결하느니, 그냥 혼자 5시간 걸려서 작업하자는 마인드가 있었기 때문입니다. 하지만 이런 작업 방식은 서로에게 도움이 되지 않았습니다. 작업 상황이 공유되지 않으니 팀원들은 답답하고, 혼자 일하는 저는 힘들기 때문입니다. 또, 처음부터 설명을 안 하고 혼자 했기 때문에 점점 그 부분은 나 혼자만 알게 되고, 나중에는 나눠서 하고 싶어도 설명하는 데에 시간이 더 오래 걸리게 되어 어려워졌습니다.

 

이제는 제법 직장인이 되어 이 정도 규모의 서비스를 운영하려면 이 정도 인원으로는 안 된다는 것도 알게 되었지만, 부족한 리소스로 어떻게든 이끌어가려고 혼자 해결해 보려고 했던 것이 문제였다고 생각합니다. 어려움이 있다면 다 같이 이야기를 나누고, 친구들과 함께 부담을 나눴어야 합니다. 그리고 우리가 감당할 수 없는 그 이상의 욕심은 적당히 포기할 줄도 알아야 또 다른 좋은 선택을 할 수 있었을 것이라고 생각합니다.

 

그래도 결론은!

갑자기 글의 방향이 너무 자기반성문 같아졌지만 아쉬운 점은 아쉬운 거고, 그래도 결론은 ‘트리브 하길 잘했다!’입니다. 돌이켜보면 미숙하고 열정이 넘쳤기 때문에 잃은 것(🦐)도 있지만, 또 이런 무모함이 있었기 때문에 이룰 수 있었던 것도 많다고 생각되기 때문입니다.

 

따로 홍보나 유지보수를 하지 않는 지금도 꾸준히 매일 다운로드하고 접속하는 유저가 있다는 사실은 늘 가슴 뛰고 감사한 일입니다. 우리가 고민하고 개발해서 내놓은 결과물을 사용하는 사람이 있다는 것, 만족하는 후기를 남겨주고 의견 메일을 보내주는 인터랙션이 있다는 것 또한 큰 기쁨입니다. 따라서 서비스를 시작할 때 세웠던 목표인 ‘길가다가 우연히 트리브를 사용하는 사람을 마주하는 것’은 아직 이루지는 못했지만, 얼굴도 모르는 8,000명의 휴대폰에 트리브가 깔려 있다는 것, 그리고 멋진 친구들과 즐거운 프로덕트를 만들었음에 만족합니다!

 

다음에 읽으면 좋은 글로 저와 비슷한 고민을 한 기획자 몬몬의 [Regret편] 이렇게 하면 알.잘.딱.깔.센 기획자 된다-현업 병행러들을 위한 지침서를 소개하며 글을 마칩니다.