🌱 2년 전, 왕초보 개발자가 서비스를 출시하기까지의 기록 (#1)
운영 도중 인력 부족으로 아쉽게 동결 됐던 프로젝트가 다시 부활했다. 애정만으로 참여했던 프로젝트였고 그렇게 끝났던 게 아까워서 PM에게 당장 참여 의사를 밝혔다.
프로젝트 리부트 계획을 말하던 중 자연스레 프로젝트를 처음 시작했을 때의 이야기가 나왔다. 개발의 🐶 도 잘 몰랐던 내가 이제는 '그때 만든 프로젝트 지금 보면 개선할 점이 한두가지가 아니다' 고 말할 수 있을 정도로 꽤나 성장했다는 느낌이 들었다.
집에 돌아와서 대화를 곱씹다보니 문득 얼마나 성장했는지 지표가 없어서 단순히 느낌만으로 끝난 것이 아쉬워졌다. 그때의 경험을 기록으로 남겨놨다면 읽으면서 회고해볼 수 있었을텐데… 꽤 많이 늦었지만, 리부트에 참여하는 새로운 팀원들에게 내 이전 경험을 공유할 겸 지금이라도 이 글을 작성해본다.
💬 2년 전, 2021년
2년 전, 지인이 프로젝트를 권유했을 당시 나는 알고리즘 문제를 풀 수는 있지만 애플리케이션을 만들라고 하면 localhost 까지만 띄울 수 있는 정도의 실력을 가진 학부생이었다. 그러나 권유받은 프로젝트의 주제가 마음에 들었고 어쩐지 근거 없는 자신감이 솟아서 '어떻게든 하면 되겠지' 라는 마음으로 무턱대고 수락했다.
지금에서야 고백하지만 수락하고 나서는 조금 후회했다.🤣 나 할 수 있을까? 하는 생각이 뒤늦게 든 것이다. 그런 내가 프로젝트를 어떻게 실 사용자들에게 서비스할 수 있었는지… 지금 보면 답답한, 어찌 보면 그때로써는 최선이었던 어마어마한 삽질이 시작된다.
👩🏻💻 나 홀로 개발자
프로젝트는 PM이자 기획자가 1명, 데이터를 수집하는 분들이 4명, 디자이너 2명, 그리고 개발자인 나 1명이 함께 진행했다. 개발자가 나 혼자다보니 자연스레 개발팀의 팀원이자 팀장이 되었다. 조장 같은 것만 맡아봤지, 이런 본격적인 프로젝트에서는 한번도 팀장 롤을 맡아본 적이 없었어서 부족한 모습을 많이 보였다...ㅎㅎ
가장 어려웠던 지점은 다른 팀과의 의사소통이었다. 기획팀과 데이터팀, 디자인팀과의 소통을 내가 스스로 이끌어나가야 했는데, 개발적인 이슈나 맥락을 어떻게 개발자가 아닌 사람들이 이해할 수 있도록 신경 쓰며 말해야 했다. 한번도 개발자가 아닌 사람들과 협업을 해본 적이 없었으니 계속 개발 용어가 튀어나오고, 상대 쪽에서는 '그게 뭐예요?' 라는 질문을 들었다...
초반에는 주로 PM이 중간에서 이해를 위한 부차적인 질문을 더 던져주는 식으로 소통을 정리해주었다. 덕분에 어떤 식으로 소통해야하는 지 감을 잡을 수 있었다. 무엇보다 PM의 어깨너머로 정말 많이 배웠다. 그분의 깔끔한 의사소통 방식을 보며 (그분께 낯간지러워서 말은 못 했지만...) 항상 감탄했는데,나도 저렇게 소통할 수 있었으면 해서 본받으려고 노력했다 ㅎㅎ 그렇게 나름대로 얻은 답은 이렇다.
개발 용어 금지
내가 다른 팀에서 쓰는 용어 들어도 이해 못하듯, 개발자만 쓰는 개발 용어는 설명해봤자 아무도 이해하지 못했다. 차라리 개발 용어를 싹 빼고 화면을 보며 설명하는 게 나았다. '어떤어떤 기능에 이런 에러 말인데요...' 가 아니라, '이 버튼 누르면 이렇게 뜨는 거요' 처럼 말하니 소통이 전보다 매끄럽게 흘러갔다.
결론만 말하기
PM이 궁금해하는 건 결론이었다. 요청한 게 '되는지', 된다면 '언제' 되는지, 만약 안된다면 '왜' 안되고 '대안' 이 뭔지를 깔끔하게 정리해서 말해야 했다. 그래서 무언가 요청을 받았을 때는 이 항목들에 대답할 수 있을 정도로 알아본 후 대답을 했다. 이런 과정에서 내 전공지식도 공부가 참 많이 됐던 것 같다. 가끔 구태여 설명을 덧붙이고 싶어져서 타이핑을 하다가도 의식적으로 멈추고 '그러니까 제가 드리고 싶은 말씀은~' 이런 식으로 말을 정리했다.
빠른 피드백
무엇보다 중요한 건 빠른 피드백같다. 질문이 오면 바로 대답하고, 바로 대답할 수 없다면 언제까지 답을 드리겠다고 해야 상대방이 기다리지 않을 수 있다. 내가 답이 늦어지면 그만큼 그 팀의 작업 또한 늦어지니... 역지사지로 내가 다른 팀에 질문을 했는데 늦게 답장을 받으면 기다리는 시간 동안 답답할 것이다.
아직도 대화할 때 개발 용어가 튀어나온다거나, 복잡하게 설명을 할 때가 많다. 그렇지만 의식적으로 위처럼 하려고 노력하다보면 자연스러워지는 날이 오지 않을까... 한다. (제발!)
📅 개발 기간 정하기
이 프로젝트는 모두가 애정으로 하는 프로젝트라서 각자의 현생을 더 우선시하다보니 오픈일자를 개발이 언제 끝나냐에 따라 정해야 했다. 나는 팀장, 화면개발, 호스팅, 테스트... 모든 게 처음이어서 얼마나 걸릴지 가늠이 되지 않았다. 무턱대고 '다 만드는 날 오픈합시다!' 라고 할 수 없었으므로 대략적으로라도 기간을 전달드려야 했다.
먼저 예상되는 작업 목록을 전부 투두리스트로 만들었다. 그리고 평소 내가 개발하는 속도를 고려해 하나하나 기간을 매겼다. 구현을 어떻게 할지 바로 떠올릴 수 있는 건 1주일, 전혀 감이 안오면 3주로 잡았다. 그리고 그걸 다 합산한 기간을 개발 완료 기간으로 정해 전달드렸다.
하지만 내가 고려하지 못한 게 있었다. 계획은 늘 그렇듯 계획한대로 되지 않는 다는 것이다... 개발 도중에 예상치못한 이슈들이 매번 터졌는데, 이걸 해결하다보니 투두리스트는 기존보다 늘어나고 일정은 그만큼 추가되었다. 결국 오픈 일자가 1달 정도 지연되는 대참사가 벌어졌다...
그때는 '내가 다 처음이라 가늠을 못했다' 가 원인이라고 생각했는데, 지금 와서 보면 처음부터 기획에서 나온 모든 기능을 구현하겠다고 빼곡하게 투두리스트를 적은 게 원인이다. 오픈하기 위한 최소한의 기능만 뽑아서 mvp를 정의한 다음 우선순위를 매기고 그것대로 차근차근 처리를 했어야 했다... (그놈의 분할정복...!!)
그래도 어찌저찌 미룬 오픈일자 내에 개발을 마칠 수 있었다. 모든 게 처음인 왕초보 개발자가 어떻게 개발했는지, 테스트는 어떻게 했는지, 그리고 운영 도중 발생한 이슈는 어떻게 처리했는지 더 많은 이야기가 남아 있지만... 글이 너무 길어져서 다음 포스팅에 작성하기로 한다. 😀