[띵동] 딜리버리 서비스와 개발팀 이야기

띵동은 고객들이 원하는 것들을 모바일 앱으로 주문할 수 있는 온디맨드 딜리버리 서비스 입니다. 고객이 주문을 하면, 띵동의 메신저들은 음식/물건들을 픽업하고, 최종 목적지까지 배달을 완료합니다. 음식 영역 뿐만 아니라 생활에 필요한 다양한 생활편의 서비스들을 주문할 수 있습니다. 띵동 서비스를 제공하는 허니비즈라는 회사는 2012년에 창업을 하였고, 현재까지 꾸준히 서비스를 제공하고 있습니다. 많은 회사들이 그러하듯, 회사가 오랜기간 성장을 하며, 기술적인 부분에서의 발전이 좀 더 필요했고, 2018년 여름부터 띵동 서비스 미래를 위한 새로운 시스템, 더욱 탄탄한 개발 조직을 만들기 시작했습니다.

 

280개 이상의 테이블 중에, 30% 테이블은 legacy로 남아있었습니다.

지속적으로 발전하는 시스템을 만들기 위해서는 다음과 같은 과제들이 있었습니다.

1. 데이터베이스 성능 Bottleneck
   여러개의 서버가 1개의 데이터베이스를 바라보는 구조를 가지고 있어, 고객 사용량이 피크치는 시간대(점심, 저녁)에 모든 서버가 속도에 영향을 받고 있었습니다. 물론 이 데이터베이스의 성능을 최대치로 끌어올려 문제를 해결할 수도 있겠지만, 향후 지역 확장을 위한 방향에 있어서, 최고의 방법은 아니었습니다.
2. 고객의 요구에 맞춰 변화하는 비즈니스 로직
   처음 이 비즈니스가 시스템으로 구성될 때에는 출발지와 도착지가 있는 심플한 주문의 형태를 띠고 있었습니다. 그래서 퀵 배달 서비스들이 쓰던 솔루션으로 주문을 처리할 수 있는 상태였습니다. 하지만 시간이 지남에 따라서, 고객의 다양한 주문들 — 사다주기, 편의점 배달, 하우스 헬퍼, 가구 옮기기 등 — 이 새로 만들어지고 있었고, 이를 시스템에서 처리하기 위해, 기존의 주문 구조와 형태(음식점, 상품)를 조금씩 변형해서 일이 처리되고 있었습니다. 하지만 이런 주문 뿐만 아니라, 외부 O2O 주문, 지역 배달대행 주문등 더 다양한 형태들, 이러한 주문들에 대한 정산 처리등 확장 가능한 유연한 형태의 설계가 필요했습니다.
3. 레거시 코드, 조금은 오래된 프레임워크
   위에서 언급했듯이, 시스템은 1개의 데이터베이스에 여러개의 서버가 바라보고 있는 형태였습니다. 이러한 서버들은 각 클라이언트들(고객 앱, 라이더 앱, 음식점 앱등)을 대응하기 위해 만들어져 있었고, 각 서버에는 중복된 비즈니스 로직, 코드들이 존재하여 유지보수를 하려면 모든 서버를 동시에 수정해야되는 상태였습니다. 예를 들어, 라이더의 정산 수수료를 계산하는 로직을 바꾸려면, 개발자는 고객 앱, 라이더 앱등 여러곳의 서버를 찾아봤어야 했습니다. 또한 2009년쯤 만들어진 Spring 3로 서버들이 구성되어 있어, 이를 유지보수하기 위한 개발자들을 찾기도 어려웠고, 육성하기도 어려웠습니다.
4. 생각보다 많은 제품군, 하지만 적은 수의 개발자
   외부에서 보이는 것과 달리, 내부에는 10개 이상의 프로젝트들(고객 앱, 음식점 앱, POS, Web, 라이더 앱, TMS 어드민 등)이 있습니다. 각각의 프로젝트들은 서로 다른 프로그래밍 언어, 프레임워크들로 만들어져 있어(Spring3, Java, Objective-C, jQuery, Delphi, PHP, Mysql 등등) 각 언어 및 프레임워크를 다룰 수 있는 많은 수의 개발자들을 고용해야 했습니다.

많은 과제들을 한번에 풀 수는 없다고 판단했으며, 가장 첫번째는 팀과 아키텍처에 집중하였습니다.