지난 해 9월부터 시작한 프로젝트 훕치치가 지난 3월, 3번째 릴리즈를 맞이했습니다.
프로젝트를 진행하며 마주친 문제를 기술적으로 해결하기 위해 다방면으로 고민했고, 이것을 실제 코드로 작성하는 과정에서 겪은 시행착오를 통해 많은 성장을 이룰 수 있었습니다.
가볍게 언급하자면, 현재 큰 문제 없이 서비스 단계를 진행 중이고, 단순히 개발하는 행위를 넘어 사용자를 고려한 다양한 노력을 하기도 했습니다. 다양한 애니메이션 기능으로 부드러운 유저 인터랙션을 구현했고, 성능 최적화를 위해서도 많은 고민을 했습니다.
이런 노력 덕분인지 감사하게도 실시간 접속자 수 160명을 달성할 수 있었고, 일일 접속 유저(DAU) 500명, 총 접속자 수 2000명을 확보하기도 했습니다. 지난 2차 서비스 기간 동안 900명의 사용자를 유치한 것과 비교하면 엄청난 성장이라고 할 수 있겠네요.
하지만 하지만 오늘은 자랑하고 싶은 욕심을 잠시 내려두고, 프로젝트를 진행하며 시간 관리에 실패한 경험과 그것으로부터 느낀 점에 대해 이야기해보려 합니다. 지극히 개인적인 생각이므로 가볍게 읽어주시면 감사하겠습니다.
문제의 인식
빠르게 문제 상황을 한 번 이야기해보자면, 이번 프로젝트 기간은 12월 말부터 3월 초까지로, 약 3달 가량 진행되었습니다. 그런데 아래 그래프를 확인해보면, 대부분의 작업이 2월 말부터 시작하여 근 한달간 폭발적으로 진행된 것을 볼 수 있습니다.
(우리 팀은 스쿼시 머지 전략을 이용하고 있기 때문에 하나의 커밋이 곧 하나의 PR이라고 생각할 수 있습니다.)
단순히 작업이 프로젝트 말미에 몰렸다는 것은 경우에 따라 문제가 아닐 수도 있습니다. 하지만 우리 프로젝트 내에서의 이 상황이 문제라고 인식한 이유는 다음과 같습니다.
- 후반으로 갈수록 점점 시간이 촉박해졌고, 코드 리뷰 퀄리티가 저하되었습니다. 이는 곧 코드의 안정성과 신뢰도와도 직결된다고 생각합니다.
- 깊이 고민하고 코드를 작성할 시간이 부족해졌습니다. 때문에 일단 동작하는 코드를 작성하는 데에 급급했던 것 같습니다.
- 수면 시간이 줄어들고, 점점 컨디션 관리에 실패하게 됩니다. 이것 자체로는 큰 문제가 아닐 수 있지만, 번아웃이라는 심각한 문제를 불러올 수 있다는 점에서 가장 경계해야 하는 지점이라 생각합니다.
원인 1. 동기적인 작업 방식
이 문제는 왜 발생했을까요? 1차적으로는 프로젝트 디자인의 대대적인 수정으로 인해 초반부에 작업을 많이 하지 못했다는 점이 원인이 될 수 있습니다. 그도 그럴 것이, 프론트엔드 개발자들은 서버에서 넘겨 받은 데이터로 UI를 그려 사용자에게 제공하는 사람들이기 때문에, 디자인과 API가 늦게 완성될수록 프론트엔드의 작업 역시 그만큼 늦어질 수밖에 없기 때문이죠.
또, 화면에 따라 API가 재구성되어야 했기 때문에 결국 프론트엔드 팀원은 디자인이 완성되기 전까지 새로운 환경으로의 마이그레이션이나, 기존 기능의 개선 등에 초점을 두고 작업을 진행했습니다.
최선이었나요?
개발을 공부하는 사람들이라면, 동기와 비동기의 개념에 대해 익숙할 것입니다. 간단히 설명하자면 동기는 모든 작업을 직렬적으로 수행하는 것이고, 반대로 비동기는 병렬적으로 수행하는 것을 의미합니다. 훕치치에서 비동기적인 작업 방식을 채택했다면 프론트엔드 작업을 다른 작업에 크게 영향 받지 않고 빠른 시간 내에 끝마칠 수 있었을 것 같습니다.
하지만 그럴 수 없었던 것은 초반 설계가 부족했기 때문이라고 생각합니다. 무슨 말이냐면, 백엔드 팀원들은 디자인이 완성되는 것을 보고 API를 개발하려 했고, 프론트엔드 팀원들은 디자인과 백엔드 팀원이 넘겨준 API 명세를 보고 페이지를 개발하려 했습니다. 모든 작업이 선행 작업에 굉장히 의존하고 있었고, 그 누구도 이에 대한 문제를 제기하지 않았습니다. 사전에 각 페이지에 포함되어야 할 기능과 데이터에 대해 논의했다면 이를 바탕으로 빠르게 작업할 수 있었을텐데 말이죠. 결국 집단의 구성원이라는 인식보다는 각자의 직무에 조금 더 집중한 것이 가장 근본적인 원인인 것 같습니다.
탄탄한 설계
근본적인 문제를 해결해야겠죠. 기획자를 주축으로 페이지 별 필요한 기능과 데이터를 사전에 논의하는 과정이 필요할 것 같습니다. 이를 바탕으로 디자인과 백엔드 API 명세 작성이 병렬적으로 진행될 수 있습니다. 프론트엔드에서는 msw와 같은 API Mocking 라이브러리를 이용하면 백엔드 개발이 완료되지 않은 시점에 데이터 전달을 흉내낼 수 있으니 이런 기술을 적극적으로 이용해볼 수도 있습니다.
디자인과 관련해서는 조금 복잡할 수 있는데, 디자이너와 충분히 소통하며 훕치치만의 디자인 시스템을 구축해두는 방법이 있습니다. 그렇게 되면 예상 가능한 틀 안에서 디자인 작업이 이루어지기 때문에 새로운 디자인 추가 및 변경에 대응하기 쉬워지겠죠. 하지만 디자인 시스템을 구축하는 것은 간단한 일이 아닙니다. 따라서 이 부분에 대해서는 충분한 논의가 필요할 것 같습니다.
원인 2. 작업 방식에 대한 문제 제기
훌륭한 팀원들과 즐겁게 작업을 하다 보니 좋은 코드를 작성하고 싶다는 욕심이 점점 커졌습니다. 그래서 코드 리뷰를 더욱 꼼꼼하게 하려다 보니 리뷰가 점점 늘어났고, PR을 머지하기까지 걸리는 시간이 조금씩 늘어났던 것 같습니다.
스프린트 회고를 하면서 이와 관련한 팀원의 피드백이 있었습니다.
- 과정을 챙기는건 항상 좋은 일이지만 그것보다 더 중요한 목표를 달성하려면 중간 과정에 힘을 빼는게 맞지 않았을까?
- MVP부터 제작한 뒤 고도화(polishing)를 했다면 오히려 더 여유롭고 많은 것을 시도할 수 있지 않았을까 싶음
제가 생각한 것이랑은 조금 달랐어요. 왜냐하면 훕치치는 현재 3차 릴리즈를 준비하고 있었고, 디자인의 대규모 수정을 제외하면 기능적인 부분은 기존의 것들을 그대로 사용하고 있었기 때문입니다.
기준의 차이
생각해보면, 저는 각 릴리즈 버전 업그레이드 과정 전체를 하나의 스프린트로 인식하고 있었던 것 같습니다. 1차 릴리즈의 결과물을 하나의 MVP라고 생각을 했고, 이후 2차, 3차 릴리즈 기간 동안 기능을 추가하거나 개선하는 작업을 고도화라고 생각했습니다. 이와 반대로 팀원은 각 릴리즈는 이전 단계와는 크게 관련이 없고, 릴리즈 단계마다 MVP를 제작해야 한다고 생각하는 듯 했습니다.
제 방식이 틀렸다고 생각하지는 않지만, 팀원의 생각 역시 충분히 좋은 방법이라는 생각이 들었습니다. 일단 완성된 모습을 두 눈으로 빠르게 확인하는 것은 그만큼 성취감을 줄 수 있기 때문에 프로젝트에 대한 열정을 키우는 데에도 도움이 될 것이라 판단했습니다.
의사전달이 아닌, 의사소통
가장 중요한 것은 의사소통인 것 같습니다. 사전에 충분한 의사소통을 통해 현재 프로젝트의 상황과 앞으로의 방향성을 결정할 필요가 있습니다. 훕치치 프론트엔드 팀에서는 회고를 통해 각자의 생각을 많이 표현하긴 했지만, 단순히 전달하는 데에 그쳤던 것 같습니다. 그러다 보니 팀원의 생각을 이해하는 것이 아니라 단순히 인지하고 있을 뿐이었고, 각자의 방향성에 차이가 발생하며 업무 효율에 악영향을 미쳤습니다. 이는 결국 시간 관리 실패라는 2차 문제로 이어지고 말았죠.
이런 이유로 앞으로는 회고를 피드백 하는 시간을 제안해볼까 합니다. 프로젝트를 진행하며 모든 사람이 같은 생각을 할 수 없기 때문에 이에 대해 깊이 이야기를 나누면 서로를 더 깊이 이해할 수 있습니다. 동시에 프로젝트의 방향성에 대해 이야기할 수도 있기 때문에 결국 팀 전체 업무 효율성을 향상시키는 결과와도 연결될 것이라 생각합니다.
맺음
결과론적으로 우리는 주어진 시간 내에 프로젝트를 마무리 했고, 사용자에게 큰 문제 없는 서비스를 제공할 수 있었습니다. 하지만 이와 같이 프로젝트 말미에 시간 부족으로 인해 밤샘 작업을 하는 상황이 반복된다면, 결국 구성원들은 지칠 수밖에 없습니다. 또 프로젝트를 기한 내에 마무리할 수 있을 것이란 보장도 없고 코드 퀄리티 역시 떨어질 수밖에 없겠죠. 모두 경험을 통해 직접 느낀 문제점이라는 것이 가슴을 찌르네요.
최근에는 개발을 더 잘하려면 어떻게 해야 하는지 보다 의사소통을 잘 하려면 어떻게 해야 하는지 더 많은 고민을 했던 것 같습니다. 그리고 돌고 돌아 마주한 해결책이 모두 활발한 의사소통과 관련 있다는 점에 느끼는 바가 많네요. 개발자는 사람들이 더 행복한 세상을 살아갈 수 있도록 돕는다는 점에서, 의사소통이 중요한 것은 어찌 보면 당연한 것이구나 하는 생각이 듭니다. 작은 조직에서조차 의사소통이 제대로 되지 않는데 어떻게 전세계를 행복하게 만들겠어요. 오늘의 깨달음이 저의 가치 실현을 하는 데에 좋은 양분이 될 것이라 기대하며, 앞으로도 꾸준히 고민하는 개발자가 되고자 합니다.
긴 글 읽어주셔서 감사합니다. 🙇♂️