OMS의 최적화된 마이크로서비스 아키텍처 디자인

컬리 OMS(주문 관리 시스템) 팀이 조직적으로 진화시킨 마이크로서비스 아키텍처를 다룬다. OMS 는 여러 판매 채널의 결제 완료 주문을 물류센터가 처리할 정보로 변환하는 "주문 통역기" 역할이다. 특정 채널에 강결합하지 않도록 설계하고, 공유 캐시 계층으로 피크 트래픽을 흡수하며, 연속 배포 문화를 정착시켰다.

핵심 포인트

역할: 판매 채널에 물류 실행 정보를 제공하고 판매 채널의 주문을 물류로 라우팅하는 두 축을 맡는다.
결합 회피: 컬리몰도 B2B 고객처럼 다뤄 특정 채널 오염을 막고, 물류 계획에서 벗어난 주문은 내부로 전파되지 않게 한다.
데이터 전략: 전량 복제 대신 필요한 정보만 동기화하고 재가공으로 보강해 응답 속도와 효율을 균형 맞춘다.
공유 캐시: 소유 MSA 가 쓰고 타 도메인은 읽기 전용으로 접근하며, 미스나 타임아웃 시 직접 MSA 호출로 폴백한다.
캐시 장애 리스크: MSA 가 캐시를 전제로 최소 용량 운영이라 캐시 장애가 곧 대형 장애이며, 보수적 오토스케일과 이중 캐시 클러스터로 방어한다.
배포 문화: 정기 배포에서 연속 배포로 전환해 작은 티켓 단위로 하루 최소 1~2회에서 10회 이상 배포한다.

상세 정리

정체성: OMS 는 다양한 판매 채널의 결제 완료 건을 물류센터가 이해하는 정보로 바꾸는 통역기이며, 모든 채널에 일관된 용어로 물류 정보를 제공한다.
결합 회피 설계: 판매 채널에서 물류에 필요한 필수 데이터만 요구하고, 물류 계획을 벗어난 주문이 내부로 퍼지지 않게 차단해 시스템 오염을 방지한다.
최소 동기화: 종합 데이터 복제 대신 필요한 정보만 동기화하고 재가공으로 보강하며, 특히 안정적 응답 속도가 필요한 구간에서 유효하다.
서비스 분리 기준: 기능·책임·관리 비용으로 나누되, 상품 정보처럼 분리 이득이 관리 비용을 못 넘으면 주문 도메인에 남겨 두고 향후 필요 시 분리 여지를 둔다.
공유 캐시 원리: 직접 묻지 말고 공용 게시판에 물어라 방식으로, 소유 MSA 가 캐시에 쓰고 다른 도메인은 읽기 전용으로 접근한다.
폴백: 캐시 미스나 타임아웃이면 해당 MSA 를 직접 호출한다.
피크 흡수: 고트래픽 운영 API 를 거의 캐시로만 응답해 내부 MSA 네트워크 호출을 제거하며, 23시 주문 피크에 운영 API 는 부하가 큰데 하위 MSA 지표는 잔잔하다.
캐시 취약점: MSA 들이 캐시가 트래픽을 흡수한다고 가정해 최소 용량으로 돌기 때문에 캐시 장애가 곧 대형 장애가 된다.
완화책: AS-IS 지표 기반의 보수적 오토스케일, hitrate·TTL 점검으로 메모리 최적화, 핵심 API 는 캐시 클러스터 2벌 운영으로 내결함성을 확보한다.
채널별 MSA: KLS(3PL)는 직접 계약으로 인터페이스 표준을 강제하고, 외부 마켓플레이스 브리지는 플랫폼 제공 연동 규격에 맞춰 다중 셀러를 지원하며, 둘 다 OMS MSA 그룹 밖에 둬 이관 가능하게 설계했다.
동시 개발: 반품/회수 기능 때 회수 주문 접수(operation)·기사 회수 접수(order)·회수 상태와 검수(tracking) 세 티켓이 서로 다른 저장소라 여러 엔지니어가 소스 충돌 없이 병렬 개발했다.
배포 전략: 준비용 MSA 선배포, 조립 전 검증, 호출 MSA 에서 카나리, 전체 배포 순으로 작은 단위 연속 배포를 한다.
라이브러리/스택: 영향이 적은 서비스부터 버전을 올리고, 처리량과 데이터 특성에 따라 Spring MVC 와 WebFlux 를 대략 반반 혼용한다.
팀 원칙: 모든 엔지니어가 모든 MSA 를 따라가야 컨텍스트가 균일해지며, 개인별 MSA 소유는 비효율과 불필요 데이터 중복 위험이라 티켓을 더 잘게 쪼개고 팀 규모는 최대 6명을 적정으로 본다.