초반에 서비스를 빠르게 성장시켜 주었던 코드베이스는 어느 시점에 한계를 맞이한다. 성장과 함께 올라선 새로운 무대에서는 멋진 기능과 편의를 제공하는 수많은 경쟁자들이 기다리고 있다. 유저들의 기대는 서비스 초반과 같지 않다. 우리가 성장을 자랑하는 만큼 더 많은 기능을 더 빠르게 안정적으로 제공해야 한다. 그러나 새로운 기능을 도입할 때 기대와 설렘보다 걱정과 한숨이 앞선다면 한 번쯤 되돌아볼 타이밍이다. 미뤄둔 기술 부채가 점점 발목을 잡기 때문이다.
기술 부채는 네모난 바퀴처럼 앞으로 나아가는데 병목이 된다. 그러나 현실적으로 이것을 바꿀 마음을 잡기란 쉽지 않다. 열심히 힘을 쓰면 어쨌든 앞으로 나갈 수 있으니까.
V2의 시작
썸원 역시 이전 글에서 언급했던 이유로 기술 부채 청산을 위해 프로젝트 리뉴얼(이하 V2)을 결심했지만, 시작 당시에는 처음부터 완전히 다시 만들 생각을 하진 못했다. 서비스가 3년간 운영되면서 매일 100만 명 이상의 유저들이 이미 제각각의 방식으로 앱을 사용하고 있었기 때문에 각 유즈케이스를 전부 보장해 줄 엄두가 나지 않았기 때문이다(문서로 된 기능명세가 없기도 했다). 그래서 유저가 많이 사용하고, 버그를 많이 제보하는 부분부터 점진적으로 리팩토링을 진행하려 했다.
하지만 근본적인 구조를 바꾸지 못한 채 진행되는 부분 리팩토링은 효율이 매우 떨어졌다. 당시 클라이언트(이하 V1)의 구조는 꽤 복잡하게 얽혀있었다. 단일 코드베이스로 안드로이드 및 IOS 앱을 개발할 수 있도록 React Native를 사용하고 있었고, 한 사람이 서버와 클라이언트를 쉽고 빠르게 개발할 수 있도록 필요한 도구들을 제공해 주는 Parse Platform이라는 프레임워크를 채택하고 있었다. 거기에 상태관리를 위해 Redux가 있었고 그래프큐엘을 테스트해 보기 위해 적용했었던 apollo, relay 등의 라이브러리가 한데 섞여 있었다. 제각각의 라이프사이클을 가지고 동작하는 라이브러리들이 한데 모여있다보니 작은 변경에도 수많은 부수 효과가 만들어질 가능성이 있었다. 운영 환경에서 리팩토링을 진행하다보니 부수 효과를 최소화하기 위해서는 특정 기능부분의 코드를 통째로 복사해서 새로 만든 후에 조금씩 대체해 나갈 수밖에 없었다. 그러나 이마저도 코드들이 섞여 있다 보니 작업 단위를 깔끔하게 떼어내기 힘든 경우가 더 많았다.
이렇게 클라이언트 리팩토링이 지지부진해지고 있는 상황에서 새로이 백엔드 팀원들이 합류하게 되었다. 클라이언트와 마찬가지로 서버 역시 리뉴얼 대상이었다. 그런데 백엔드는 Parse 라는 플랫폼 기반 위에서 전체가 동작하고 있었기 때문에 부분 리팩토링보다는 근본이 되는 프레임워크 자체를 마이그레이션해야되는 상황이었다. 이때를 계기로 클라이언트 역시 새로운 프로젝트를 만들기로 결심하게 된다. 처음에 우려하고 있었던 기존 버전과의 연결성은 베타 테스트를 통해 해결하기로 했다. 부분 리팩토링을 시작한 지 1달 반이 된 시점이었다. 새롭게 처음부터 만드는 것에 대한 망설임에서 비롯된 결정으로 인해 한참 돌아서 다시 시작점으로 왔다. 똥인지 된장인지 찍어 먹어 봐야 아냐고들 하지만, 적어도 맛보고 나서 돌아오니 결정에 망설임은 없어졌다.
바보야, 문제는 사람이야
V2 프로젝트의 걸림돌이었던 운영환경과의 분리가 결정되자 개발에 속도가 붙을 것이라 생각했다. 그러나 하나의 문제가 해결되면 또 다른 문제가 오는 법. 그것은 개발은 사람이 하는 것이라는 점이다. V2 프로젝트에서 가장 중점으로 두었던 주요 기술은 그래프큐엘이었다. 그래프큐엘은 스키마라는 명세를 만들어서 서버와 클라이언트가 통신할 API를 구축할 수 있도록 한다. 따라서 스키마를 짜임새 있게 잘 만드는 게 중요한데, 이 과정에서 개발팀원들 간에 많은 논의가 필요했다. 새로 합류한 백엔드 팀원들은 물론 실력도 있고 경력도 있는 사람들이었지만, 문제는 입사한 지 얼마 안 된 시점이라 아직 개발 합을 맞춰보지 않았다는 점이었다. 또한 입사 전에 이미 그래프큐엘 도입이 결정되어 있었기 때문에 해당 결정에 완전히 공감하지 못한 상황이었다. 함께 이해도를 높이기 위해 외부 세미나에 참여해 보기도 하고 하루 시간 중 절반 이상을 논의하는 데 쓰기도 했다. 스키마의 변수명 하나 만드는 것에서도 생각이 다 달라서 컨벤션을 만드는 데 많은 시간이 들었다. 시간이 흐르는 만큼 기술의 숙련도가 올라가고 합이 맞춰져 갔지만, 그것을 프로젝트 기간동안 쌓다보니 나중에는 초반에 만들었던 부분이 기술 부채로 보이기도 했다. 돌이켜보면 핵심과 관계없는 문제들로 시간이 너무 지연된다고 생각했지만, 사실은 각각의 팀원들이 하나의 팀이 되어가는 과정이었던 것 같다. 개발 프로젝트를 진행하는 데 가장 중요한 것은 어떤 멋진 기술을 사용하느냐보다는 팀에서 의사결정을 하고 논의하는 과정 그 자체라고 느껴졌다.
백지장도 맞들면 낫다
V2 프로젝트는 그 필요성에 대해 전사적인 공감을 충분히 얻지 못한 상태에서 개발팀 내부 목표로 시작되었기 때문에 다른 팀원들은 무엇 때문에 프로젝트가 지연되는지 잘 이해하지 못했다. 그러나 개발팀 내부 상황 외에도 발목을 잡는 요인들이 있었다. 3년 간 성장해 온 서비스는 생각보다 더 거대했고 문서로 존재하지 않는 기획은 직접 당시 담당자를 찾아서 구두로 물어봐야 했다. 경우에 따라서 같은 기능에 대해 사람마다 기억하는 게 조금씩 달랐다. 복잡한 기능의 경우에는 V1에서 케이스 별로 일일이 재현해 보면서 정리해야 했다. 기술부채로 인해 비롯된 프로젝트 리뉴얼은 온전히 개발자의 몫이라는 생각이 오히려 덫이 되어 일을 점점 키워갔다.
개발팀에서 좌충우돌 프로젝트를 진행해 나가는 동안 시간은 계속 흘렀고 2024년이 되었다. 해가 넘어갔다는 상징적인 의미 때문이었을까. 어느 순간 타 부서 팀원들 사이에서 V2는 대체 언제 끝나냐는 말들이 나오기 시작했다. 개발팀의 가장 중요한 목표가 V2 프로젝트가 되면서 자연스럽게 V1은 간단한 기능 개선 및 유지보수 상태에 들어가게 되었다. 새롭게 기획된 기능들은 V2가 완성될 때까지 기다릴 수밖에 없었다. 자연스레 V2가 언제 끝나는지가 중요해졌고 마치 개발팀에 의해 전사적인 프로세스에 제동이 걸린 듯한 상황이 되었다.
클로즈베타 이후 정식 배포까지 좌절이 참 많았다.
그러나 사실 V2 프로젝트는 기술부채만 다룰 문제가 아니었다. 애플리케이션을 구성하는 코드를 직접 작성하는 게 개발자이다 보니 마치 개발자들만의 책임처럼 스스로 느꼈을 뿐이었다. 이론적으로 각 코드가 하는 기능을 새로운 코드베이스로 잘 옮기기만 하면 된다고 생각했던 것은 완전한 오산이었다. 더 이상 진행에 한계가 있다고 여겨질 무렵, 다른 팀원들에게 V2의 필요성을 설명하고 도움을 요청했다. 이 과정에서 프로젝트는 단순한 기술 부채를 해결하는 것이 아닌 서비스 자체에 대한 정비로 이어졌다. 프로젝트를 바라보는 시야를 달리하자 해야할 것들이 명확해졌다. UX 팀에서는 리뉴얼에 맞게 개선된 UX를 제안해 주었고, PM팀에서는 기능명세 정리하면서 서비스의 각 기능들을 문서화하기 시작했다. 유저 응대 및 서비스 운영을 담당해 주던 오퍼레이션 팀에서는 이제까지 쌓아온 유저 케이스들을 정리해서 QA 프로세스를 구축하기 시작했다. 개발 외적인 부분들에서 팀원들이 도움이 이어지자, 개발도 조금씩 자리를 찾아갔다. 끝나지 않을 것 같던 프로젝트는 여러 팀원의 도움으로 마침내 3월, 클로즈베타를 시작할 수 있었다.
V2를 처음 유저에게 선보이는 순간, 이상하게 CTO님은 신이 나신 듯하다
끝으로
프로젝트가 끝난 시점에서 되돌아보니 프로젝트 리뉴얼에서 오히려 기술 그 자체는 큰 문제가 아니었다. 개발자들은 문제를 기술적으로 해결해 보려는 경향이 있다. 그러나 생각보다 많은 문제들이 운영이나 정책적인 영역에서 쉽게 풀릴 수 있었다. 초반에는 운영환경에서 프로젝트 리뉴얼을 수행해야 한다는 문제에 집중하느라 부가적인 시간을 많이 사용했다. 그러나 새로운 프로젝트를 만들고 유저 사용성을 테스트하기 위해 베타 테스트를 진행한다는 정책이 결정되면서 쉽게 해결되었다. 개발자는 코드를 작성하는 사람이 아니라 문제를 해결하는 사람이라는 말을 다시 한번 생각해보는 계기가 되었다. 문제를 해결하기 위해서는 코드 외에도 다양한 수단을 동원해서 현재 상황에 맞는 해결책을 제시할 수 있어야 한다. 그외에도 프로젝트 기간동안 개발팀 내부에서 진행되었던 여러 논의들은 새로운 기술들을 어떻게 사용할지, 어떻게 협업을 할지 규칙을 만들어나가는 시기였고, 개발 외 부서 팀원들과는 어떻게 소통하고 협업을 해야할지 프로세스를 정비하는 시간이었다. 회사 차원에서는 파편화 되어있던 프로젝트가 문서화되고 전체적인 체계를 만들 수 있는 시간이었다. 이리저리 힘든 순간도 많았지만 개인적으로도 팀 차원에서도 한 단계 성숙해지는 계기가 되었다고 생각한다. 말 그대로 아프니까 V2다.