domain-driven-design

현지인처럼 결 (새 탭에서 열림)

Airbnb는 전 세계 220개 이상의 국가에서 결제 편의성을 높이고 전환율을 개선하기 위해 14개월 만에 20개 이상의 지역 결제 수단(LPM)을 성공적으로 도입했습니다. 이를 위해 기존의 모놀리식 시스템을 도메인 주도 서비스 체계로 현대화하고, 다양한 결제 방식을 표준화된 인터페이스로 처리할 수 있는 기술적 기반을 마련했습니다. 결과적으로 복잡한 지역별 결제 환경을 추상화함으로써 확장성 있는 글로벌 결제 플랫폼을 구축하고 비즈니스 성장을 가속화했습니다. **현지 결제 수단(LPM) 도입의 전략적 가치** * **다양한 결제 수단 수용:** 신용카드 외에도 국가별 디지털 지갑(M-Pesa), 실시간 계좌 이체(Pix, UPI), 지역 결제망(Cartes Bancaires) 등 사용자에게 익숙한 수단을 제공합니다. * **접근성 및 전환율 증대:** 신용카드 보급률이 낮은 시장의 잠재 고객을 확보하고, 결제 단계에서의 이탈(friction)을 줄여 예약 전환율을 높입니다. * **체계적인 선정 프레임워크:** 전 세계 300개 이상의 결제 옵션 중 상위 75개 시장을 분석하고, 여행 서비스 적합도와 시장 점유율을 고려해 우선순위가 높은 20여 개를 선정했습니다. **결제 플랫폼 현대화 및 MST 프레임워크** * **서비스 지향 아키텍처(LTA):** 모놀리식 구조를 도메인 주도 아키텍처로 전환하여 결제 처리, 정산, 장부 관리 등 기능을 독립적인 서비스로 분리했습니다. * **커넥터 및 플러그인 구조:** 새로운 결제 서비스 제공업체(PSP)를 연동할 때 코드 재사용성을 높이고 시장 진입 시간을 단축하기 위해 플러그인 방식의 아키텍처를 채택했습니다. * **멀티스텝 트랜잭션(MST):** 업체마다 제각각인 결제 단계를 표준화하기 위해 MST 프레임워크를 도입했습니다. 리다이렉션이나 추가 인증이 필요한 경우 이를 'ActionPayload'로 규격화하여 처리합니다. **세 가지 표준화된 결제 흐름 모델** * **리다이렉트(Redirect) 흐름:** 네이버페이나 GoPay처럼 사용자를 외부 앱이나 웹사이트로 이동시켜 결제를 완료한 후, 다시 에어비앤비로 돌아와 토큰 기반으로 최종 확정하는 방식입니다. * **비동기(Async) 흐름:** Pix나 Blik과 같이 사용자가 QR 코드를 스캔하거나 푸시 알림을 통해 외부에서 결제하면, PSP가 에어비앤비에 웹훅(Webhook) 통보를 보내 상태를 업데이트하는 방식입니다. * **직접(Direct) 흐름:** 애플페이나 특정 로컬 카드처럼 에어비앤비 인터페이스 내에서 직접 결제 정보를 입력하고 실시간으로 처리하는 표준적인 방식입니다. **결제 오케스트레이션 및 데이터 무결성** * **외부 세션 제어:** 타사 앱 전환 시 발생하는 세션 핸드오프와 동기화 문제를 해결하기 위해 견고한 결제 오케스트레이션 로직을 설계했습니다. * **웹훅 기반 상태 관리:** 비동기 결제의 경우, 사용자 화면의 상태와 실제 결제 완료 상태를 일치시키기 위해 안정적인 웹훅 수신 체계를 구축했습니다. * **시장별 최적화:** 한국의 네이버페이처럼 높은 점유율을 가진 수단을 우선 도입하여 현지 사용자의 결제 경험을 네이티브 수준으로 개선했습니다. 글로벌 확장을 준비하는 엔지니어링 팀은 결제 시스템 설계 시 처음부터 '추상화'와 '표준화'에 집중해야 합니다. 지역별 결제 수단은 기술적 구현 방식이 모두 다르지만, 이를 리다이렉트, 비동기, 직접 흐름으로 범주화하여 공통 프레임워크(MST) 내에 수용함으로써 신규 결제 수단 추가에 드는 비용을 획기적으로 낮출 수 있습니다.

DDD를 Merchant 시스템 구축에 활용한 사례를 소개합니다 (새 탭에서 열림)

기존의 음식 배달 중심 시스템에서 벗어나 소매 상품 판매에 최적화된 새로운 Merchant 시스템을 구축하기 위해 도메인 주도 설계(DDD)를 도입했습니다. 이번 프로젝트는 DDD가 단순히 코드 구현 기술이 아니라, 도메인의 역할과 책임을 명확히 정의하고 이를 바탕으로 조직 구조와 협업 방식을 설계하는 방법론임을 보여줍니다. 클린 아키텍처와 비동기 이벤트 기반의 모듈 구성을 통해 시스템의 확장성을 확보하고, 글로벌 팀 간의 원활한 협업 체계를 마련하며 성공적으로 시스템을 론칭했습니다. **소매 플랫폼으로의 전환과 도메인 정의** * 기존 시스템의 '음식점 기반 소매 판매' 한계를 극복하기 위해 독립적인 Merchant 시스템을 설계했습니다. * Merchant 시스템은 점포, 상품, 재고 등의 정보를 제공하고, 실제 판매는 '소비자 플랫폼'에서 담당하는 구조로 역할을 분리했습니다. * 핵심 도메인을 점포(shop), 상품(item), 카테고리(category), 재고(inventory), 주문(order)의 다섯 가지로 정의하여 복잡도를 낮추었습니다. **클린 아키텍처를 활용한 시스템 설계** * 도메인 엔티티가 외부 환경의 변화에 영향을 받지 않도록 클린 아키텍처를 채택했습니다. * 모든 팀원이 쉽게 이해하고 따를 수 있는 명확한 계층 구조를 통해 유지보수 편의성을 높였습니다. * 의존성 방향을 내부(도메인)로만 허용하여 비즈니스 로직의 순수성을 유지했습니다. **비동기 기반의 모듈 및 통신 구조** * 시스템을 외부 요청을 받는 'API' 모듈과 비즈니스 로직을 처리하는 '엔진' 모듈로 분리하여 가용성을 높였습니다. * gRPC를 통한 API 제공과 Apache Kafka 기반의 내부 통신을 결합했으며, Decaton 라이브러리를 사용해 파티션 대비 높은 처리량을 확보했습니다. * 플랫폼 특성을 고려하여 즉각적인 응답보다는 최종 일관성(Eventual Consistency)과 빠른 API 응답 능력에 초점을 맞춘 비동기 구조를 설계했습니다. **글로벌 협업과 조직의 일치(Conway's Law)** * 한국 팀은 핵심 도메인(Core)을, 일본 팀은 현지 시스템 연계(Link, BFF)를 담당하도록 조직을 구성해 콘웨이의 법칙을 실천했습니다. * 의사결정 과정과 논의 배경을 기록하는 ADR(Architectural Decision Record)을 활용해 조직 간의 공감대를 형성하고 불필요한 재논의를 방지했습니다. * 추상화된 연계 계층을 통해 새로운 소비자 플랫폼이 추가되더라도 핵심 도메인의 변화는 최소화되는 유연한 구조를 만들었습니다. 성공적인 DDD 적용을 위해서는 헥사고날 아키텍처와 같은 기술적인 구현에만 매몰되지 않는 것이 중요합니다. 도메인의 역할과 책임을 먼저 명확히 정의하고, 그 경계에 맞춰 팀 조직과 소통 구조를 설계할 때 진정한 설계의 이점을 얻을 수 있습니다. 시스템의 아키텍처가 조직의 소통 구조를 반영한다는 점을 인지하고, 기술과 조직 관리의 균형을 맞추는 접근이 권장됩니다.