컬리에서 선물하기를 개발하며 회고

주문서비스 개발팀이 선물하기 서비스를 오픈하기 까지 여정

정명성 게시 날짜: 2020.09.03.

들어가며

컬리에서 주문 서비스 개발팀이 신규 주문 서버를 개발하며, 첫 무대로 선물하기 서비스를 론칭하기까지 여정을 정리해보는 내용입니다. 레거시 시스템과 신규 시스템 호환을 맞추기 위해서 어떤 노력을 했는지, 커머스 주문부터 배송까지 어떤 고민을 하며 진행했는지를 담아보았습니다.

컬리와 비슷하게 레거시 시스템을 개선하기 위하여 노력하시는 개발자분들께도 이 글을 통해서 좋은 영향이 있었으면 합니다.

선물하기 서비스란?

컬리에서 선물하기 서비스란 컬리에서 판매되고 있는 상품을 구매하여, 선물을 주고 싶으신 분에게 카카오톡으로 선물 메시지를 보내주고, 배송지를 입력받아 선물 받은 상품을 배송을 받을 수 있는 서비스를 말합니다. 이때 선물 받으신 분은 선물 받으실 주소를 입력하시면 배송이 됩니다.

선물하기 입력 안내

여러 커머스에서 선물하기 서비스가 오픈되고 있는 상황이었고, 주문 서비스 개발팀에게도 선물하기 서비스를 이미 오래 전부터 오픈해야 하는 요구 사항이 들어온 상태였습니다. 하지만 컬리에는 레거시 시스템의 허들이 존재했는데요. 이 큰 허들을 넘기 위해서 어떤 노력을 했는지 같이 살펴보시죠.

선물하기 서비스를 개발하며 겪은 어려움들

고X몰 php로 이루어진 레거시 코드의 복잡함

레거시 시스템은 고도몰 솔루션(PHP)으로 만들어져 있습니다. 빠른 비즈니스 요건으로, 성장해 온 레거시 시스템에는 여러 기술 부채들이 많이 쌓여있는 상황이며, 컬리 비즈니스 성장을 위해서는 현재 이 허들을 넘어야 하는 상황입니다. 레거시 시스템은 하나의 큰 데이터베이스를 이용하여 모노리틱한 구조로 구성되어 있었고, 기존 데이터베이스를 넘어서 시스템을 구성해야 했기 때문에, API를 통해서 기존 데이터베이스에서 벗어나는 구조로 구성을 하지 못하면, 데이터베이스 장애가 단일 장애 유발점( Single Point Failure ) 이 되어 전면 장애를 유발할 수 있습니다.

부족한 개발팀의 리소스

주문 개발팀 8명 운영 및 신규 서비스도 개발해야 한다.

탈고도가 목표였던 시점에서부터 문제가 되었던 촉박한 일정

이미 운영 중인 서비스를 신규 서비스에 맞춰서 개발을 요청하거나, 기한에 맞춰서 요구 사항을 받기에는 현실적인 어려움이 있었습니다.

간략한 이미지

컬리몰을 운영하기 위해 위 이미지와 같은 여러 마이크로 서비스가 동작하고 있습니다. 선물하기 서비스를 하기 위해서는 여러 마이크로 서비스를 담당하고 있는 도메인 서비스 조직에 요청을 해야 합니다. 프로젝트 요구 사항을 정리하는 것부터 기존 시스템에 호환성도 유지하기 위해서 고민을 갖는 시간을 가졌습니다.

개발 과정

선물하기 서비스 아키텍처와 대략적인 데이터 스키마

신규 주문서버 아키텍처

신규 주문 서버는 기존 업무 툴, 고객 상담, 물류 전송, 적립금 지급, 배송 완료까지 기존 프로세스와 최대한 호환성을 맞추기 위하여, 데이터 동기화 (dual writing)를 하여, 신규 데이터베이스에 기록되는 정보를 기존 데이터베이스로 동기화하는 방향으로 구성을 하였습니다.

레거시 시스템과 기존 업무 프로세스를 한 번에 바꿔서 적용하는 것은 불가능하였으며, 누구도 장담할 수 없는 상황이었습니다. 그리고 자체 물류(생산/배송)를 담당하고 있는 컬리에서는 더욱 신중한 접근이 필요했습니다. 따라서, 기존 프로세스를 유지할 수 있도록 별도의 선물 주문 생태계를 구성하고 레거시 시스템에 호환하는 방식으로 접근을 하였습니다.

그리고, 데이터 동기화 (dual writing)은 장애 발생 시 회복하는 방법이 어려울 수 있지만, 데이터 정합성을 맞출 수 있는 장치를 마련하여 회복성 있는 구성을 할 수 있었습니다.

또한, 신규 주문 서버는 역할 별로 분산 서버 구조로 구성하였으며, 부하가 발생되었을 때 나누어진 서버 별로 스케일아웃 용이하도록 구성하였습니다.

더 나아가, 주문 요청을 더 이상 처리할 수 없는 상황이 된다면, 각 구간별 Message Queue를 Throttling를 적용해서 서버 구성을 변경하면 될 수 있다고 생각하였습니다. 하지만 현 컬리 주문량은 재고와도 연관되어 있어 폭발적으로 증가될 수 없기에 한걸음 더 나아간 구성은 남겨둔 채 API 통신으로만 처리할 수 있도록 구성하였습니다.

이후 신규 주문 시스템이 독립적인 생태계를 구축할 수 있는 순간이 온다면, 손쉽게 기존 데이터베이스에서 떨어져 나갈 수 있도록 구성하였습니다.

이런 방식으로 신규 아키텍처를 구성하였고, 선물하기 서비스를 오픈할 수 있었습니다.

기존의 운영 정책과도 잘 호환되는 시스템을 개발하자 (타협한 것들)

아키텍처 및 운영 서비스 고민

주문 서비스팀은 아래 요건 사항에 맞춰 고민하였습니다.

  • 주어진 기간 내에 어떻게 프로젝트를 성공적으로 수행할 방법은 무엇인가?
  • 도메인 전문가로부터 어느 영향 범위까지 고려해야 하는가?
  • 기존 시스템에 맞춰 어느 정도로 상품이 구성되어야 하는가?
  • 연관된 서비스를 담당하는 팀에 요청을 최소화하고, 선물하기 서비스를 만드는 방법은 무엇인가?

레거시 시스템을 극복하기 위해서 먼저 레거시 정책을 분석했던 문서들을 살펴보았고, 정리가 되지 않는 부분은 별도로 정리해 나아갔습니다. 그리고 고민했던 사항들을 적극적으로 반영하여 시스템 아키텍처를 설계하였습니다.

해결 방법을 고민

기존 시스템과 연동 문제

개발 진행 도중 일정과 관련된 변경과 그에 따른 고민들

성공적인 배포 후 운영 시작

8월 말부터 연관 도메인 서비스가 배포되었으며, 9월 2일 날 론칭 하였습니다. 신규로 나온 서버도 많았고, 신규로 주문 서버가 론칭 되었기 때문에 큰 어려움 없이 배포를 진행할 수 있었습니다. 짧은 일정에 맞춰 환경별 구성을 해주신 DOE 팀 에게 감사드립니다.

장애가 없다! QA 이슈가 1000개였기 때문

레거시 시스템에서 신규 주문 서비스를 론칭하기 까지는 많은 어려움이 있었습니다. QA를 진행하는 범위가 넓었고, 기간도 한 달로 잡고 진행하였습니다. 전체 프로젝트 일정이 넉넉지 않은 상황에서 한 달 정도 QA 일정을 넣어서 진행하기까지 선물하기 서비스를 론칭하기 위해 헌신하신 분들이 많이 있습니다. 고생 많으셨습니다.

QA_이슈

1000 여개의 이슈가 발생되었고, 론칭하기 전까지 최선을 다해 해결하였습니다.

선물하기 개발 회고

회고 1

아키텍처 및 운영 서비스 고민

컬리에서는 마이크로서비스 아키텍처 를 도입하면서 레거시 시스템을 개선해 나아가고 있습니다. 각 서비스는 도메인 단위로 독립적이며 변화에 빠르게 적응하도록 구성하고 있습니다.

하지만, 레거시 시스템이 존재하면서 신규 서비스를 론칭하기 위해서는 많은 고려사항들이 있었습니다.

마무리

커머스 시스템에서 신규로 선물 주문 서버를 개발하는 것은 정말 재밋는 여정이였습니다.더불어 물류까지 자체적으로 하고 있는 상황에서 서비스를 구축하다보니 많은 도메인 지식과 경험을 얻었습니다. 현재 컬리에서는 시스템을 개편하기 위해서 많은 개발자분들이 필요합니다.

이런 커머스 물류 도메인을 같이 경험 해보고 싶거나 레거시 시스템을 개선을 싶으신 분들의 많은 관심과 지원 부탁드립니다.