2023년 11월 23일 첫 커밋으로 시작된 V2 프로젝트가 2024년 5월 10일 스토어에 전체 배포되면서 마무리가 됐다. 클라이언트부터 서버까지 제품과 관련된 모든 코드베이스를 처음부터 다시 만드는 대규모 작업이었다.
서비스 개선을 위한 리팩토링은 10월부터 진행되고 있었기 때문에 전체 기간은 대략 7개월이 걸렸다. 그 동안 기존 앱은 간단한 A/B 테스트나 기능개선 외에는 유지보수 상태에 들어가게 되었고 주요 리소스는 V2에 투입되었다.
이 글에서는 매일 100만 유저가 3년 동안 잘 사용하고 있었던 앱을 왜 바닥부터 다시 만들게 되었는지 그 이유를 돌아보고자 한다.
V2임에도 첫 배포 버전이 2.0.19인 이유는.. 나중에 다뤄질 것 같다.. 아마도..
초기 서비스의 성장과 한계
이전 글에서 시사하듯, 초기 스타트업에서는 적은 인원으로 큰 임팩트를 내기 위한 프로젝트 구조가 필요하다. 큰 임팩트는 빠르게 배포하고, 유저 피드백을 받아 다시 수정하는 사이클에서 나온다. 그리고 빠른 사이클을 가져가기 위해서는 제품이 최대한 단순한 구조를 띄는 게 중요하다. 단순할수록 고민할 것이 적다.규칙을 일일이 문서화 할 시간에 커밋 하나 더 추가하는 게 효과적일 수 있다. 잘못된 코드는 유저에게 버그 제보가 들어올 때 고치면 된다. 다양한 케이스를 세심하게 고려하며 견고하게 코드를 쌓아나가는 것보다 중요한 것은 임팩트가 나는 방향으로 빠르게 나아가야 한다는 점이다.
그러나 서비스가 점점 성장하게 되면 평소와는 다른 신호들이 여기저기서 나타난다. 초기부터 서비스에 애착을 가지고 사용했던 유저와 이미 성장한 서비스에 새롭게 들어온 유저들은 서비스를 바라보는 관점이나 원하는 것이 다르다. 기존 방식처럼 피드백을 통해 개선을 진행하기에는 유저들이 원하는 방향성이 제각각이다. 유저들은 생각하지 못한 본인만의 방식으로 서비스를 사용하는 습관이나 루틴을 형성한다.
따라서 서비스가 본인의 기존 사용 패턴에 맞지 않게 변하면 버그라고 생각하고 부정적 반응을 보이는 경우도 있다. 이 상황에서 여전히 기존 사이클을 유지한다면 서비스는 부정적 피드백이 점점 쌓일 가능성이 높아지고 최악의 상황에는 유저 이탈이 일어날 수도 있다. 유저 피드백을 직접 체감할 수 있는 FE 개발자로서는 이런 신호들이 더욱 선명하게 느껴졌다. 앞에서 크게 고려하지 못했던 견고한 원칙과 규칙이 필요한 시점이 온 것이다.
유저로부터의 신호와 더불어 제품 내부 이곳저곳에서도 삐걱거리는 소리를 내기 시작한다. 빠르게 성장한 서비스에는 당시 개발자들의 애환이 깃든 일종의 문법 같은 것들이 만들어진다. 유저 수를 폭발적으로 늘려주었던 치열한 흔적들이 있다. 하지만 당시엔 유용했던 구두로 합의된 규칙들은 시간과 상황에 따라 제각각의 형태로 자리하고 있고, 유저 피드백을 반영하기 위해 추가된 조건문들은 겹겹이 중첩되어 개발의 걸림돌이 되고 있다. 서비스를 성장시켜 주었던 코드들은 이제는 부메랑처럼 버그로 돌아온다. 나이테처럼 켜켜이 쌓인 코드들은 이미 서비스 그 자체가 되어있기 때문에 따로 분리하기가 힘들다.
프로젝트 리뉴얼의 필요성
나는 프로젝트가 조금씩 삐걱거리기 시작할 무렵 프론트 개발자로 입사했다. 온보딩을 진행하면서 프로젝트를 살펴보니 앞에서 언급한 문제들을 어렴풋이 인지할 수 있었다. 하지만 당연하게도 곧바로 프로젝트 리뉴얼을 진행할 수는 없었다. 아직 서비스에 대한 이해도도 부족했을뿐더러 이렇든 저렇든 겉보기에 잘 돌아가고 있었기 때문이다.
개발자들 사이에서 유명한 짤이지만, 남 일인줄만 알았다.
그렇게 나는 다소 불안감을 안고 펫스킨이라는 새로운 기능 개발에 투입되었다. 막상 기능 개발을 시작해보니 프로젝트 리뉴얼의 필요성을 뼈저리게 느낄 수 있었다. A 기능을 추가하거나 수정하면 C, D에서 문제가 발생했다. 그리고 이를 커버하기 위해서는 정말 수많은 테스트가 필요했다. 하지만 그렇게 공을 들여 테스트하고 배포해도 예상치 못한 부분에서 치명적인 버그들이 발생하는 경우가 있었다.
나의 마음은 타들어갔지만 그래도 무사히 출시된 반려몽 옷입히기 기능
펫스킨 기능을 개발하면서 나는 아래와 같은 문제점과 개선점을 생각했다.
•
중첩된 조건문과 이곳저곳에서 중복으로 사용되고 있는 로직들을 개선해서 개발 관리 포인트를 줄인다.
•
썸원 앱은 특유의 손그림 느낌을 살리기 위해 많은 이미지를 사용하고 있다. 그런데 그 이미지들은 모두 클라이언트에 담긴 채 배포되고 있었다. 이미지들이 쌓이면서 클라이언트 빌드 사이즈는 점점 늘어만 갔다. 앱 사이즈를 줄이기 위해 이미지를 다른 곳으로 옮길 필요가 있었다.
•
썸원 특유의 느낌을 살리기 위해 직접 그림을 그리는 것은 시간의 한계가 있었고, 열혈 유저가 많아질수록 콘텐츠 소비 속도는 점점 빨라졌다. 콘텐츠 제공 속도를 늘리기 위해 확장 가능한 디자인툴과 이에 맞는 렌더링 엔진이 필요해졌다.
•
서비스의 성장과 함께 인력이 늘어났기 때문에 병렬적으로 기능 개발이 이루어져야 되고 독립적으로 배포할 수 있어야 된다. 이때 각 기능간의 충돌을 최소화해야 한다.
•
에러 전파 범위를 최소화해야 되고 문제가 되는 기능은 빠르게 롤백할 수 있어야 된다.
•
프로덕션에서 난 에러를 빠르게 파악하기 위한 모니터링 도구들이 필요하다.
서비스가 더 성장하기 위해서는 새로운 기반이 필요하다는 점은 분명해졌다. 그리고 마침 작업을 함께할 새로운 동료들도 속속히 합류하고 있었다. 바야흐로 큰 결심이 필요한 시점이 왔다. V1과 헤어질 결심.
