데이터 중심에서 도메인 중심 아키텍처로의 전환: 충돌과 전략적 해법

클라우드 네이티브 시대의 도메인 중심 아키텍처 필요성과 충돌 배경

오늘날 금융 및 공공 기관을 포함한 많은 전통 기업들은 클라우드 네이티브 환경에 발맞춰 도메인 중심 아키텍처로의 전환을 모색하고 있습니다. 모놀리식을 모듈화한 모듈러 모노리스나 마이크로서비스 아키텍처(MSA), 서비스 기반 아키텍처(SBA) 등은 비즈니스 기능별로 시스템을 분리하여 민첩성과 확장성을 높이는 접근입니다. 이러한 도메인 중심 설계 철학은 각 도메인(업무 영역)이 자체 데이터와 서비스를 책임지는 자율성을 강조하며, DDD(Domain-Driven Design)의 바운디드 컨텍스트 개념에 뿌리를 두고 있습니다. 그러나 오랫동안 데이터 중심 조직 문화에 익숙한 기업에서는 이러한 전환 과정에서 기존 데이터 설계 및 거버넌스 원칙과 충돌이 발생하곤 합니다.

전통적인 데이터 중심 조직에서는 일반적으로 통합 데이터 모델과 강력한 중앙 통제를 기반으로 시스템이 운영되었습니다. 모든 비즈니스 영역의 데이터를 아우르는 엔터프라이즈 통합 데이터 모델을 정립하고, 데이터 사일로를 없애 단일 진실의 원천(Single Source of Truth)을 만들고자 했습니다. 데이터 용어와 스키마는 기업 전반에 일관되게 적용되었고, 중앙 데이터 아키텍트나 DBA 조직이 이러한 모델과 규칙을 엄격히 관리했습니다. 강한 정합성(일관성)과 ACID 트랜잭션이 미덕으로 여겨졌고, 데이터 중복이나 불일치는 가능한 한 배제하는 것이 원칙이었습니다.

하지만 클라우드 네이티브 시대에는 변화의 속도와 시스템 복잡도가 증가하면서, 하나의 통합 모델로 모든 것을 커버하기 어려워졌습니다. 각 비즈니스 도메인은 저마다 빠르게 진화하고, 서로 다른 요구사항을 가지게 되었습니다. 이에 따라 하나의 거대한 모델보다는 도메인 별로 최적화된 모델과 서비스를 갖추고, 느슨하게 통합하는 아키텍처가 부상했습니다. 마이크로서비스와 도메인 중심 설계는 이러한 요구에 부응하지만, 기존 데이터 거버넌스 구조와 필연적으로 마찰을 빚습니다. 이 글에서는 이러한 충돌이 구체적으로 무엇인지 살펴보고, 어떻게 전략적으로 극복할 수 있는지 실질적 해법을 제시합니다.

주요 충돌 지점: 전통 데이터 설계 vs 도메인 모델링

도메인 중심 아키텍처로 전환할 때 나타나는 주요 충돌 지점은 크게 세 가지 정도로 정리할 수 있습니다. 첫째는 통합 데이터 모델 vs 바운디드 컨텍스트의 충돌이고, 둘째는 용어 및 약어 규칙의 충돌, 셋째는 데이터 정합성 및 트랜잭션 관리에 대한 인식 차이입니다. 각각의 충돌을 구체적인 사례를 들어 설명해보겠습니다.

1. 통합 데이터 모델 vs 바운디드 컨텍스트

전통적인 데이터 중심 조직에서는 모든 데이터를 아우르는 통합 엔터프라이즈 데이터 모델을 선호합니다. 예를 들어, 고객, 상품, 주문 등 여러 도메인의 엔티티를 하나의ERD(Entity-Relationship Diagram)나 공통 스키마로 통합하여 관리하려 합니다. 표준화된 용어와 스키마로 모든 부서가 하나의 언어로 데이터 소통을 하도록 강제하고, 중복을 최소화하여 단일 데이터 출처를 만들고자 하죠. 이 접근은 데이터 웨어하우스나 마스터 데이터 관리(MDM) 등의 개념과 맞닿아 있으며, 중앙 조직이 데이터 스키마 변경이나 새로운 엔티티 추가를 엄격히 검토합니다.

반면 도메인 중심 아키텍처에서는 각 서비스나 모듈이 자신만의 도메인 모델을 가집니다. DDD의 바운디드 컨텍스트(Bounded Context) 개념에 따라, 하나의 도메인 내에서만 통하는 모델과 용어가 존재할 수 있습니다. 즉, 기업 전체에 단일한 모델을 강요하기보다는 도메인별로 별도의 데이터 스키마와 모델을 만들어야 한다는 철학입니다. 예를 들어 같은 "상품(Product)"이라 하더라도 영업 부서의 상품과 주문/배송 부서의 상품은 관점과 속성이 다를 수 있습니다. 영업에서는 상품에 대한 마케팅 정보와 카탈로그 중심의 속성을 중요시할 수 있지만, 주문 도메인에서는 재고나 배송 관련 속성을 더 중시할 것입니다. 하나의 통합 상품 모델로 이 모든 정보를 관리하려 하면, 필연적으로 여러 도메인의 모든 속성을 한 객체에 우겨넣게 되어 불필요한 필드와 도메인간 결합이 생깁니다. 더욱이 한 도메인의 요구로 모델을 변경하면 다른 도메인에 영향이 파급되는 문제가 발생합니다. 이런 이유로 DDD에서는 “모든 도메인에서 통용되는 하나의 모델은 존재하지 않는다”고 보며, 각 하위 도메인마다 모델을 분리해야 한다고 강조합니다.

현실 사례를 들어보겠습니다. 한 금융 기관에서 “고객(Customer)”이라는 개념을 생각해봅시다. 전사 통합 데이터 모델에서는 고객 정보를 담은 CUSTOMER 테이블 하나에 개인 고객, 법인 고객, 예비 고객 등의 모든 정보가 들어있고, 영업, 심사, 사후관리 부서 모두 이 테이블을 참조한다고 가정합니다. 그런데 도메인 별로 보면, 영업 부서는 고객의 마케팅 동의 여부나 선호 상품 같은 정보에 집중하고, 리스크 관리 부서는 고객의 신용 등급이나 연체 이력에 관심이 있습니다. 전통적 접근에서는 CUSTOMER라는 단일 테이블에 이 모든 필드를 넣고 부서별로 필요 없는 필드도 함께 공유하게 될 겁니다. 반면 도메인 중심 접근에서는 영업 도메인과 리스크 도메인이 각자 별도의 고객 모델과 DB 테이블을 가질 수 있습니다. 영업 도메인의 Customer는 마케팅 정보에 특화되고, 리스크 도메인의 Customer는 신용 데이터에 집중하도록 모델이 분화됩니다. 표면적으로 보면 데이터가 중복된 것처럼 보이지만, 실은 맥락이 다르기에 중복이라고 보기 어렵습니다. 각 서비스의 고객 데이터는 해당 맥락에서만 완전한 의미를 가지며, 다른 서비스의 고객 데이터와 일대일로 완벽히 대응하지 않을 수도 있습니다. 오히려 이렇게 분리함으로써 각 도메인은 자신의 변화에 민첩하게 대응하고, 다른 도메인의 변경에 영향받지 않는 유연성을 얻습니다.

이 지점에서 데이터 거버넌스 팀과 도메인 아키텍트 간에 충돌이 발생합니다. 중앙 데이터 조직 입장에선 “왜 고객 데이터가 둘로 분리되고 중복 저장되느냐, 한 곳에 모아서 관리해야 데이터 정합성이 유지된다”고 우려합니다. 또한 통합 모델 관점에서는 데이터 통합(integration)을 사후 처리(예: 데이터 레이크나 DW에서 통합)하는 것이 아니라 애초에 애플리케이션 설계 시에 통합해야 한다고 믿습니다. 그러나 도메인 아키텍처 관점에서는 서비스 간 데이터 복제와 중복을 허용하고, 서비스 경계를 넘어선 강한 결합을 피하는 것이 더 중요합니다. 이 충돌은 궁극적으로 “데이터 중복을 죄악시하는 문화”와 “필요한 한도 내 중복을 수용하는 문화”의 충돌이라고도 볼 수 있습니다.

2. 용어 및 약어 규칙 충돌

데이터 중심 조직에서는 기업 데이터 사전(Data Dictionary)이나 표준 용어집을 운용하여, 엔터티 이름부터 컬럼 약어까지 표준을 정하는 경우가 많습니다. 예를 들어 고객을 의미하는 필드는 전사적으로 CUST_NO와 같은 식별자 형식을 쓰도록 강제하거나, 모든 테이블 명을 4글자 약어로 짓는 등의 규칙이 있습니다. 이러한 약어 및 명명 규칙은 기업 전체에서 데이터 용어를 일관성 있게 유지하려는 취지이지만, 도메인 관점에서 볼 때는 개별 서비스의 언어 표현력을 제한하고 도메인 고유의 의미를 드러내지 못하게 할 수 있습니다.

DDD에서는 각 바운디드 컨텍스트 내에서 유비쿼터스 언어(Ubiquitous Language)를 사용하라고 합니다. 즉, 해당 도메인의 전문가와 개발자가 공유하는 용어를 코드와 스키마에 그대로 사용하여 의미가 통하는 모델을 만들라는 것입니다. 그런데 중앙 데이터 표준 용어가 이를 방해하는 사례가 발생합니다. 예를 들어 보험 도메인에서 "피보험자"라는 개념을 다루는 경우, 이를 전사 데이터 사전에는 그냥 CUSTOMER로 정의해 두었을 수 있습니다. 중앙 규칙에 따라 DB 필드도 CUST_ID로 쓰라고 강제하면 정작 해당 컨텍스트에선 '고객'과 '피보험자'의 차이를 표현하지 못하게 됩니다. 개발자는 업무적으로는 분명히 다른 개념인 두 객체를 데이터 모델상 같은 것으로 취급하거나, 억지로 구분하려고 CUSTOMER_TYPE 같은 플래그를 두는 식으로 우회해야 합니다. 이로 인해 의미상의 혼동이 발생하고, 도메인 지식이 제대로 모델에 녹아들지 못하게 됩니다.

또 다른 흔한 예로, 현장의 개발자들은 도메인 모델링을 할 때 Order, OrderItem 등 알기 쉬운 이름을 쓰고 싶어하지만, 중앙 데이터 팀은 약어 규칙에 따라 ODR_ITM 같은 이름을 요구하는 식입니다. 결과적으로 코드나 스키마만 봐서는 해당 객체의 의도를 쉽게 파악하기 어려워지고, 팀 내 소통도 불편해집니다. 이렇게 표준화 vs 표현력의 충돌이 발생하면, 개발팀은 표준을 따르느라 생산성이 떨어지고 잘못된 해석 위험이 높아지거나, 반대로 표준을 무시하고 자체 용어를 쓰다가 나중에 통합 단계에서 제재를 받기도 합니다.

이 문제는 단순히 이름짓기의 문제가 아니라, 도메인 지식의 컨텍스트화에 대한 이해 부족에서 비롯됩니다. 앞서 언급했듯, 같은 용어라도 맥락에 따라 의미가 달라질 수 있고, 서로 다른 용어라도 같은 대상일 수 있습니다. 도메인 중심 아키텍처에서는 이를 자연스러운 현상으로 보고 각 맥락에 맞는 언어를 존중합니다. 반면 기존 데이터 거버넌스는 용어의 통일을 중시하죠. 이 간극을 해소하려면 조직 전체에 “컨텍스트에 따른 용어 분리” 개념을 교육하고, 중앙 표준도 유연하게 운영할 필요가 있습니다. 뒤에서 자세히 다루겠지만, 조직적 차원에서 도메인 용어사전이나 컨텍스트 매핑(Context Map)을 도입하여 서로 다른 용어 간 관계를 관리하는 접근도 고려할 수 있습니다.

3. 정합성과 트랜잭션 관리에 대한 인식 차이

데이터 중심 시스템에서는 정합성(Consistence)을 유지하는 최우선 수단으로 강력한 트랜잭션(ACID)을 사용해왔습니다. 한 비즈니스 기능이 여러 테이블을 갱신해야 하면, 범위(tran) 트랜잭션으로 모두 한꺼번에 수행하거나, 데이터베이스 레벨에서 2단계 커밋(2PC)을 사용해 분산 트랜잭션도 불사합니다. 이렇게 하면 시스템 어디에서든 즉시 일관된 데이터를 볼 수 있고, 부분 실패 시 전체가 롤백되므로 정합성 오류가 발생하지 않는다는 안도감이 있습니다. 특히 금융권처럼 데이터 오류가 치명적일 수 있는 도메인에서는 이러한 강한 정합성 요구사항이 문화적으로 깊이 뿌리박혀 있습니다.

하지만 도메인 기반 분산 아키텍처에서는 모든 것을 하나의 트랜잭션으로 처리할 수 없습니다. Microservice 환경에서는 서비스마다 독립된 DB를 가지므로, 한 요청에 여러 서비스의 DB가 관여할 경우 전통적인 DB 트랜잭션 경계를 넘어섭니다. 이때 분산 트랜잭션을 사용할 수도 있지만, 이는 시스템 복잡도를 크게 높이고 성능을 떨어뜨릴 수 있어 권장되지 않습니다. 대신 Saga 패턴과 같은 기법을 활용하여 분산 트랜잭션을 대체하는 것이 일반적입니다. Saga 패턴은 여러 서비스에 걸친 작업들을 로컬 트랜잭션들의 연쇄로 구현하고, 중간에 실패가 발생하면 보상 작업을 수행하여 전체 비즈니스 일관성을 맞추는 방식입니다. Saga를 도입하면 개별 서비스들은 여전히 자신의 DB 안에서 ACID를 유지하지만, 전체 프로세스 차원에서는 Eventually Consistent(최종적 일관성)한 상태를 달성하게 됩니다. 이것은 중앙 DB 한 곳에 즉시 반영되던 강한 일관성과는 개념적으로 다르기에, 처음 접하는 조직은 불안감을 느낄 수밖에 없습니다.

예시 시나리오: 전통 방식에서는 "주문 생성 -> 결제 -> 배송지시" 과정을 하나의 거대한 트랜잭션으로 처리하여, 중간에 하나라도 실패하면 아예 주문 자체를 취소하고 모든 DB 변경을 롤백했습니다. 따라서 주문 테이블, 결제 내역 테이블이 항상 완벽히 일치했고, 실패 시 시스템에는 아무 영향이 남지 않았죠. 반면 MSA 환경에서는 주문 서비스, 결제 서비스, 물류 서비스가 분리되어 있고, 각자 자기 DB를 갱신합니다. 이때 Saga 패턴을 적용하면, 주문 생성 후 결제 단계에서 실패할 경우 주문 취소 이벤트를 통해 앞서 만든 주문을 취소하는 보상 트랜잭션을 실행합니다. 중요한 점은, 이 기간 동안 잠시 주문 DB에는 결제 안 된 주문이 남아있는 불일치 상태가 노출될 수 있다는 것입니다. 결국 나중에 취소되겠지만, 중앙 DB를 쓰던 시절에는 결코 보지 못했던 일시적 불일치상황이 발생합니다. 데이터 관리 조직이나 QA 입장에서는 이러한 현상이 버그로 보일 수 있습니다. “주문이 생성됐는데 결제가 실패하면 왜 바로 주문이 없어지지 않고 남아있나? 데이터 정합성이 깨진 것 아니냐”와 같은 반응이 나옵니다. 이는 최종적 정합성(Eventual Consistency) 개념에 대한 이해 부족에서 오는 혼란입니다. 분산 시스템에서는 일정 시간 동안 데이터가 불일치해도 결국 동기화됨을 허용해야 하는데, 기존 문화에서는 이를 용납하기 어렵다고 느끼는 것이죠.

또 다른 예로 메시지 지연에 대한 우려를 들 수 있습니다. 도메인 중심 아키텍처에서는 서비스 간 통신에 이벤트 드리븐 아키텍처(EDA)나 메시지 브로커(예: Kafka, RabbitMQ)를 자주 사용합니다. 이벤트 기반으로 동작하면, 한 서비스가 이벤트를 발행하고 다른 서비스가 이를 비동기로 처리하게 되는데, 네트워크나 처리 상황에 따라 지연이 발생할 수 있습니다. 예를 들어 회원 가입 이벤트를 발행하면 다른 여러 서비스가 이를 받아 각자 필요한 데이터를 세팅하거나 외부 시스템 호출을 할 수 있는데, 때로는 몇 초 늦게 처리될 수도 있습니다. 그러면 A서비스에서는 이미 가입이 완료되었다고 표시되지만, B서비스에서 관련 처리가 몇 초 뒤에 완료되어 그 사이에는 B서비스 상의 데이터가 준비되지 않은 일시적 갭이 생길 수 있습니다. 전통적 동기 통합 방식에 익숙한 실무자라면 “왜 시스템마다 완료 시점이 다르고 지연이 생기는가, 실시간으로 맞춰야 하지 않나?”라며 불안감을 표합니다. 여기에는 “실시간=정합”이라는 고정관념이 있습니다. 그러나 현대 아키텍처에서는 사용자 경험을 해치지 않는 범위에서 수 초 내지 수 분의 지연은 허용하면서, 전체 시스템의 탄력성과 비동시성을 확보하는 편이 더 중요하다는 철학 전환이 필요합니다.

정리를 하면, 기술적 정합성vs 비즈니스적 최종정합성 간의 인식 차이가 충돌의 핵심입니다. 전자는 “지금 이 순간 모든 데이터가 완벽히 일치해야 한다”는 관점이고, 후자는 “일정 시간 내 결국 일치하면 된다. 그 대신 시스템은 더 유연하고 견고해진다”는 관점입니다. 이 간극을 메우려면 새로운 트랜잭션 관리 기법(Saga 등)에 대한 교육과 신뢰 구축이 필수적입니다. 다음 장에서는 이러한 기술적 혼란 사례들을 좀 더 짚어보고, 해법을 모색해 보겠습니다.

실무에서 빈번히 발생하는 기술적 혼란 사례

도메인 기반으로 전환한 초기 단계에서는 개발팀과 운영팀이 여러 기술적 혼란을 겪게 됩니다. 앞서 언급한 정합성 이슈 외에도 패턴과 개념의 이해 부족으로 인한 어려움들이 자주 나타납니다. 여기에서는 현장에서 흔히 보고되는 혼란 사례들과 그 배경을 알아봅니다.

• Saga 패턴에 대한 이해 부족: 분산 트랜잭션의 대안으로 Saga를 도입했지만, 팀원들이 Saga의 보상 트랜잭션 개념이나 설계 방법을 완전히 소화하지 못한 경우가 많습니다. 그 결과, 보상 로직이 누락되거나 잘못 구현되어 데이터 불일치가 영구히 남는 버그가 생기기도 합니다. 또는 Saga의 오케스트레이션 vs 코레오그래피 방식 선택에서 혼동을 겪어, 언제 중앙 조정자를 둘지(Orchestrator), 언제 분산 이벤트로 처리할지 결정하지 못해 우왕좌왕하기도 합니다. 간혹 어떤 개발자는 Saga를 마치 실시간 트랜잭션처럼 오해해서, 각 단계가 끝날 때까지 다음 단계를 지연시키는 동기식 Saga를 구현하려 들기도 합니다. 이는 Saga의 의도와 다르며 결국 시스템 병목을 가져오게 됩니다. 이러한 오해는 분산 시스템 경험 부족과 교육 부족에서 기인합니다.
• Eventual Consistency(최종적 일관성)에 대한 불안: 최종적 일관성을 이론적으로는 이해해도, 막상 프로덕션에서 데이터 일시 불일치를 마주하면 불안해집니다. 예를 들어 주문이 완료되었는데 재고 차감이 몇 초 늦게 이루어지거나, 서로 다른 서비스에서 동일 고객의 정보가 잠시 불일치하는 상황에서, 이를 심각한 결함으로 간주하고 모든 서비스를 동기 호출로 바꿔야 하나 고민하기도 합니다. 특히 QA나 운영 부서에서 이러한 현상을 발견하면 큰 이슈로 보고하거나, 사용자가 혼란스러워할 것이라 우려하는데, 사용자 경험 측면의 모니터링과 정책 부족도 한 몫 합니다. 결국 어디까지가 허용 가능한 불일치인지 기준이 없고, 이를 사용자에게 어떻게 노출할지에 대한 합의도 부족한 상태에서 도메인 아키텍처를 적용하면, 팀 내 논쟁이 생기곤 합니다.
• 메시지 지연 및 중복 처리: 이벤트 기반 메시징을 채택하면 피할 수 없는 문제가 메시지 지연, 중복, 순서 뒤바꿈입니다. 처음 이벤트 드리븐 시스템을 접한 팀은  “메시지가 언제든 지연될 수 있다”는 것을 간과하고 시스템을 설계하다가, 특정 시나리오에서 이벤트 처리 순서가 뒤집혀 데이터 모순이 생기거나(예: 이전 상태 이벤트가 나중에 도착하는 경우), 중복 소비로 인해 동일 이벤트가 두 번 처리되는 상황을 만납니다. 이러한 문제를 겪으면 일부 개발자는 “차라리 기존처럼 동기 호출하고 말지”라고 회의적으로 생각하게 됩니다. 그러나 이는 메시지 처리의 기본 원칙(idempotency, 멱등성)과 재시도 설계 등에 대한 훈련이 부족한 탓입니다. 멱등성 설계를 통해 같은 이벤트가 여러 번 오더라도 한 번만 효과를 주도록 하거나, 메시지에 일련번호나 타임스탬프를 부여해 순서를 식별하는 등의 대응이 필요합니다. 초기에는 이런 부분까지 미처 설계하지 못해 혼란을 겪지만, 차츰 성숙한 이벤트 설계로 극복할 수 있습니다.
• 분산 모니터링의 미비: 모놀리식 시절에는 한두 개 서버의 로그와 모니터링 도구만 보면 트랜잭션 흐름을 파악할 수 있었습니다. 그러나 도메인 별로 서비스가 분리되면, 하나의 비즈니스 프로세스가 여러 시스템을 거치면서 진행됩니다. 이때 각 시스템에서 나눠진 로그와 지표를 통합적으로 추적할 수 있는 환경이 없으면, 문제 발생 시 어디서 잘못됐는지 찾기가 매우 어렵습니다. 분산된 서비스에서 트랜잭션 ID를 이어서 추적하거나, 각 이벤트의 상관관계 키(Correlation ID)를 심어두지 않았다면, 운영팀은 그야말로 미로 찾기를 하게 됩니다. 이러한 모니터링 부족은 곧바로 도메인 아키텍처에 대한 신뢰 저하로 이어집니다. “예전엔 에러나면 DB 트랜잭션 로그 보고 바로 알았는데, 이젠 뭔가 사라져버렸다”는 불만이 생길 수 있습니다.
• 기존 거버넌스와의 마찰: 기술적인 것 외에도, 중앙 데이터 관리팀과 개발팀 사이의 문화적 충돌이 현장에서 혼란을 가중시킵니다. 예를 들어 개발팀이 빠르게 스키마를 변경하여 배포하려는데, 중앙 아키텍처 위원회에서 승인을 내주지 않아 일정이 지연되는 경우가 있습니다. 도메인 팀은 “우리 서비스 DB인데 왜 중앙 승인이 필요하지?”라고 불만을 품고, 거버넌스 팀은 “전사 표준과 호환되지 않는 스키마 변경은 허용할 수 없다”며 맞섭니다. 이러한 충돌이 누적되면 프로젝트 지연, 팀 사이 긴장으로 이어지고, 최악의 경우 도메인 중심 전환 자체가 조직 내 정치 싸움으로 번질 수도 있습니다.

이상과 같은 혼란들은 새로운 아키텍처로 전환 시 거쳐야 할 산이라고 볼 수도 있습니다. 중요한 것은 이를 방치하지 않고 적극적으로 대응하여 학습 기회로 삼는 것입니다. 다음 장에서는 이러한 문제들을 극복하기 위해 사용 가능한 기술적/도구적 대안들과 모범 사례를 살펴보겠습니다.

실질적 대안: 기술 패턴, 오픈소스 프레임워크와 모니터링 도구

도메인 중심 아키텍처 전환에서 발생하는 충돌과 혼란을 해결하기 위해, 기술적인 대안과 도구를 전략적으로 활용할 수 있습니다. 여기서는 분산 환경에서 데이터 일관성과 통합을 유지하는 패턴, 이를 지원하는 오픈소스 프레임워크, 그리고 운영상의 가시성을 높여줄 모니터링 도구들을 소개합니다. 이러한 모범 사례를 활용하면 앞서 언급한 문제들을 완화하고 성공적인 전환을 뒷받침할 수 있습니다.

• Saga 패턴 구현을 위한 프레임워크: Saga 패턴의 수작업 구현에 익숙하지 않은 팀이라면, 검증된 오픈소스 프레임워크를 도입하여 시행착오를 줄일 수 있습니다. 예를 들어 Axon Framework는 DDD, CQRS, 이벤트 소싱 기반으로 Saga를 손쉽게 구현할 수 있게 도와주는 자바 기반 프레임워크입니다. Axon은 내부에 Saga 관리 컴포넌트를 갖추고 있어, 복잡한 보상 로직 흐름을 정의하고 상태를 추적하기 수월합니다. 또 다른 예로 Temporal.io(구 Uber Cadence) 같은 오케스트레이션 엔진을 사용하면, Saga를 일련의 워크플로우로 코드화하고 내장된 재시도 및 상태 관리 기능을 활용할 수 있습니다. .NET 환경이라면 NServiceBus (상용/오픈소스 혼합)나 MassTransit 등의 프레임워크가 Saga 패턴 지원을 내장하고 있습니다. 이러한 툴을 사용하면 개발자들이 개념에 익숙해질 때까지 안전장치를 얻을 수 있고, 패턴 구현에 소모되는 시간을 줄여 비즈니스 로직에 집중할 수 있습니다.
• 이벤트 일관성 확보를 위한 아웃박스 패턴 및 CDC: 이벤트 기반 아키텍처에서 데이터 일관성과 정확도를 높이기 위해 널리 쓰이는 기법이 트랜잭셔널 아웃박스(Transactional Outbox) 패턴입니다. 이 패턴은 애플리케이션의 데이터베이스에 Outbox 테이블을 하나 추가하고, 서비스가 이벤트를 발행할 때 실제로는 이 Outbox 테이블에 이벤트 내용을 기록한 뒤, 별도의 이벤트 발행 프로세스가 해당 레코드를 읽어 메시지 브로커(Kafka 등)에 전달하는 방식입니다. 이렇게 하면 서비스의 비즈니스 데이터 업데이트와 이벤트 기록이 동일한 DB 트랜잭션으로 처리되어 원자성이 확보되고, 커밋이 성공한 경우에만 이벤트가 브로커로 전달되므로 이중 쓰기 문제나 미발행 위험을 막을 수 있습니다. 오픈소스로 Debezium과 같은 CDC(Change Data Capture) 도구를 활용하면 Outbox 테이블에 삽입된 이벤트를 자동으로 캐치하여 브로커로 흘려보내는 구성을 구축할 수 있습니다. 이를 통해 개발팀은 비즈니스 로직에 집중하고, 이벤트 발행의 신뢰성은 기반 시설이 책임지게 할 수 있습니다. 요약하면, Outbox + CDC 조합은 데이터 일관성과 이벤트 전달 보장을 모두 충족시키는 강력한 수단이며, 많은 기업들이 이 패턴을 표준화하고 있습니다.
• 데이터 중복과 통합을 위한 데이터 레이크/메시/패브릭 활용: 도메인별로 데이터베이스를 분리하면, 전사 차원의 통합 조회나 분석은 별도 과제가 됩니다. 이 부분을 보완하기 위해 데이터 레이크나 데이터 메시 접근을 고려할 수 있습니다. 각 도메인 서비스는 운영에 필요한 데이터는 자체적으로 갖고 있지만, 분석이나 거버넌스 목적으로는 정기적으로 데이터 레이크/웨어하우스로 데이터를 유도하여 통합 뷰를 생성하는 것입니다. 최신 트렌드인 데이터 메시(Data Mesh)는 도메인별 데이터 제품을 만들어, 중앙 집중형 데이터팀이 아니라 각 도메인 팀이 자신의 데이터를 소비하기 좋게 제공하고, 이를 느슨하게 연합(federation)하는 방식을 취합니다. 이를 뒷받침하는 기술로는 데이터 카탈로그, 메타데이터 관리 도구, 분산 SQL 엔진(예: Presto/Trino) 등이 있습니다. 또한 데이터 패브릭 개념을 도입하면, 물리적으로 분산된 데이터 소스를 가상 통합하여 마치 하나의 데이터베이스처럼 질의할 수 있는 추상 레이어를 제공합니다. 이러한 기술 전략을 활용하면, 운영 서비스는 분산돼 있어도 필요 시 엔터프라이즈 차원의 데이터 분석과 거버넌스를 수행할 수 있어 중앙 데이터 조직의 요구와 서비스 팀의 자율성을 절충할 수 있습니다.
• 분산 모니터링 및 관측성(Observability) 도구: 앞서 지적한 모니터링 문제를 해결하려면 분산 추적(distributed tracing)과 로그/메트릭 통합을 위한 오픈소스 도구들을 적극 도입해야 합니다. 오픈 텔레메트리(OpenTelemetry) 표준을 채택하여 각 마이크로서비스에서 오는 트랜잭션 정보를 수집하고, 제거(Jaeger)나 집킨(Zipkin)과 같은 분산 추적 시스템으로 분석하면, 하나의 사용자의 요청이 거치는 서비스들의 호출 흐름과 시간 분포를 한눈에 볼 수 있습니다. 예를 들어 주문 ID나 트레이스 ID를 통해 해당 주문 요청이 거친 서비스와 각 단계 소요시간을 추적함으로써, 지연이나 오류 지점을 신속히 파악할 수 있습니다. 로그 관리를 위해서는 ELK 스택(Elasticsearch + Logstash + Kibana)이나 EFK(Fluentd를 대신적용)를 구축하여 모든 서비스 로그를 중앙에서 검색/시각화하도록 하고, Prometheus + Grafana 조합으로 각 서비스의 메트릭(cpu, 메모리, 요청 속도, 에러율 등)을 모니터링할 수 있습니다. 네이버에서 개발하여 공개한 Pinpoint와 같은 APM 도구도 분산 환경 모니터링에 유용한 오픈소스입니다. 핵심은, 이러한 Observability(관측 가능성) 체계를 사전에 잘 갖추어놓아야 개발팀과 운영팀의 불안감을 줄이고 신속한 문제 해결이 가능하다는 점입니다. 모놀리식에서 MSA로 전환했던 넷플릭스 사례를 보면, 모니터링 강화를 위해 오픈소스 Hystrix로 회로 차단기 패턴을 적용하고, 슬루스(Sleuth)와 Zipkin으로 분산 추적을 도입하는 등 운영단의 탄탄한 기초를 마련한 바 있습니다. 이러한 투자가 선행되어야만 분산 시스템의 비 가시성 문제를 해결하고 신뢰를 얻을 수 있습니다.
• 레퍼런스 아키텍처와 가이드라인 활용: 기술 스택과 아키텍처 패턴을 선정할 때 완전히 백지에서 시작하기보다, 검증된 레퍼런스 아키텍처를 참고하면 충돌을 줄일 수 있습니다. 예를 들어 금융권에 특화된 MSA 레퍼런스로 IFRS9 등의 프로젝트 경험이나, 공공기관에서 모듈러 모노리스로 성공한 사례들을 공부해보는 것입니다. 이러한 사례들은 어떤 부분에서 중앙 통제와 현업 요구의 타협점을 찾았는지 보여주며, 우리 조직에 맞게 변형할 아이디어를 줍니다. 또한 많은 오픈소스 커뮤니티(스프링 클라우드, CNCF 등)에서 Best Practice 문서와 가이드를 제공하므로, 이를 내부 지침에 반영하는 것이 좋습니다. 가령 “서비스 간 데이터 공유가 필요한 경우 이벤트와 백업 API 중 어느 것을 언제 사용할지”에 대한 가이드, “정합성 수준에 따른 패턴 선택(Saga vs 2PC vs 단순 통합)” 지침 등을 미리 정해두면 팀의 혼란을 예방할 수 있습니다.

이상의 기술적 대안들을 종합해보면, 도메인 중심 아키텍처는 단순히 서비스를 나누는 것이상으로, 분산 환경의 복잡성을 관리하기 위한 많은 기법들의 활용을 요구합니다. 새로운 기법을 도입할 때는 해당 분야의 오픈소스 도구와 커뮤니티의 지혜를 빌리는 것이 현명하며, 이를 통해 시행착오 비용을 낮출 수 있습니다.

조직적 대응 방안: 거버넌스 재편과 문화 변화

기술적인 대비책과 함께, 조직 구조와 문화 측면의 대응도 전환 성공을 위해 필수적입니다. 사실 도메인 중심으로의 전환은 단순히 아키텍처만 바꾸는 것이 아니라 일하는 방식과 책임의 범위를 바꾸는 일입니다. 따라서 조직적 지원 없이는 기술적 노력도 성과를 내기 어렵습니다. 여기에서는 거버넌스 조직 개편, 도메인 용어 관리, 교육과 지침 수립 등 주요 조직적 대응 전략을 제시합니다.

• 데이터 거버넌스 조직의 역할 재정의: 중앙 데이터 아키텍처팀이나 데이터 거버넌스 조직은 그동안 표준 수립과 통제에 주력해왔다면, 도메인 전환 후에는 조율자와 지원자의 역할을 맡도록 변화해야 합니다. 각 도메인 팀이 데이터 모델을 자율적으로 설계하더라도, 완전히 방임하는 것은 아니므로 중앙 거버넌스 팀은 가이드라인 제시와 조정 역할을 수행합니다. 예를 들어, 중복된 데이터의 출처(Source of Truth)에 대해 분쟁이 있을 때 중재하고, 각 도메인 모델 간 충돌을 식별해주는 역할을 합니다. 이를 위해 중앙 팀 내에 도메인 아키텍처 협의체를 만들어, 각 도메인의 리드 아키텍트들과 정기적으로 소통하며 표준과 구현 간 갭을 줄여나갈 수 있습니다. 조직 구조 측면에서는, 기존에 데이터 모델러/DBA들이 모여있던 부서를 해체하고 도메인 팀에 분산배치하는 것도 고려할 수 있습니다. 즉, 각 도메인팀에 데이터 전문가를 임베디드하여 그 도메인의 데이터 품질을 책임지게 하고, 중앙 조직은 이러한 분산된 데이터 책임자들의 커뮤니티를 운영하며 전사 이슈를 다룹니다. 이렇게 하면 중앙 통제가 완화되는 대신 현장 밀착형 거버넌스가 구현됩니다.
• 컨텍스트 기반 용어 사전과 컨텍스트 맵: 앞서 지적한 용어 충돌 문제를 해결하기 위해, 도메인 용어사전을 구축하는 것이 도움이 됩니다. 이는 각 도메인별 유비쿼터스 언어를 정리한 사전으로, 동일한 대상에 대한 도메인별 명칭과 정의를 나열하고 관계를 기술합니다. 예컨대 “고객 = {영업: 잠재고객(Lead), 심사: 신청인(Applicant), 상담: 민원인(Client)}”과 같이 서로 다른 용어들이 어떤 개념적으로 연관되어 있는지 표시합니다. 이렇게 하면 전사적인 데이터 카탈로그에서 한 용어를 검색했을 때 해당 도메인별 용어들을 함께 참조할 수 있어, 용어 불일치로 인한 소통 장애를 줄일 수 있습니다. 또한     DDD에서 말하는 컨텍스트 맵(Context Map)을 문서화하여, 어느 바운디드 컨텍스트들이 서로 어떤 데이터를 주고받는지, 통합 방식은 무엇인지(공유 커널, 도메인 이벤트, Anti-Corruption Layer 등) 명시해두는 것도 조직적 학습에 도움이 됩니다. 이러한 문서는 단순 기술 문서가 아니라 조직간 계약의 역할도 합니다. “우리 회계 도메인은 고객 정보를 참조하지만 원본은 영업 도메인에 있으므로, 월말에 영업 도메인으로부터 정산용 고객 스냅샷을 제공받는다”와 같은 합의를 문서화해두면, 나중에 사람이 바뀌어도 분쟁이 적습니다.
• 아키텍처 원칙과 설계 지침의 수립 및 교육: 조직 차원에서 전사 아키텍처 원칙을 재정립하고 이를 교육하는 작업이 필요합니다. 예를 들어, “하나의 서비스는 하나의 마이크로DB를 가진다”라든가 “교차 서비스 간 데이터 동기화는 이벤트를 원칙으로 한다”와 같은 원칙(Principles)을 선언적으로 정해놓습니다. 또한 앞서 기술 대안 부분에서 논의한 여러 패턴(Saga, Outbox, CQRS 등)에 대해 사내 표준 또는 권장 가이드를 문서화합니다. 이 가이드에는 언제 어떤 패턴을 쓰고, 트레이드오프는 무엇이며, 우리 회사 기술스택에서는 어떤 라이브러리나 방식을 사용할지를 담습니다. 중요한 것은 이러한 지침을 지속적으로 교육하는 것입니다. CIO나 IT 전략 부서는 정기적으로 아키텍처 워크숍이나 기술 세미나를 열어, 신규 프로젝트 팀과 기존 직원 모두가 최신 아키텍처 원칙을 숙지하게 해야 합니다. 교육 내용에는 단순 기술 사용법 뿐만 아니라, 왜 그런 원칙이 필요한지에 대한 비즈니스 맥락도 포함되어야 합니다. 예컨대 “왜 결국적 일관성을 우리가 수용해야 하는가?”에 대해, 실제 사례와 수치를 들어 설명하고 토론하게 하면, 이해와 수용이 높아집니다. 교육을 통해 공감대 형성이 이루어지면, 이후 현장에서 표준을 적용할 때 저항이 줄어듭니다.
• 파일럿 프로젝트와 성공 경험 전파: 조직 변화는 결국 사람을 통한 변화이므로, 초기에 작은 성공 사례를 만드는 것이 유효합니다. 하나의 도메인(예: 상대적으로 경미한 업무 영역)을 골라 도메인 중심 아키텍처 파일럿으로 전환해보고, 여기서 겪은 문제와 해결책을 전사에 공유합니다. 파일럿 팀에는 중앙 아키텍트도 참여시켜 협업하게 하고, 결과를 경영진 앞에서 발표하는 기회를 주어 인정받게 합니다. 이를 통해 “우리도 해보니 되더라”는 신뢰가 쌓이면, 나머지 도메인들도 따라오기 쉽습니다. 또한 전문가 영입 또는 자문도 고려해야 합니다. DDD나 MSA 전환에 경험이 많은 외부 전문가를 단기 자문으로 두어, 초기 설계와 리뷰를 함께 하도록 하면 시행착오를 줄일 수 있습니다. 이는 기술적 조언뿐만 아니라 조직 설득 측면에서도 도움이 됩니다. 외부 성공 사례를 직접 경험한 전문가의 이야기는 현업 리더들에게 큰 설득력이 있기 때문입니다.
• 비즈니스 부서와의 협력 강화: 도메인 중심 접근은 IT만의 이슈가 아니라 업무 부서와의 협업을 전제로 합니다. 각 도메인 팀에는 해당 도메인의 업무 담당자(PO, SME)가 깊이 관여하여, 도메인 모델링과 용어 정의에 함께 참여해야 합니다. CIO는 각 부서장들과 협력하여 이런 협업 구조를 설계하고 지원해야 합니다. 예를 들어 도메인 모델 설계 워크숍을 IT와 비즈니스가 함께 진행하고, 이벤트 스토밍 같은 기법을 활용해 모두가 같은 그림을 그리도록 합니다. 이렇게 업무와 IT의 벽을 허물면, 데이터 중심 vs 도메인 중심의 관점 차이도 자연스럽게 좁혀집니다. 왜냐하면 중앙 데이터 팀도 결국 비즈니스 요구에 부응하기 위해 존재하는 것이므로, 실무 부서와 새로운 아키텍처 논의를 함께 하다 보면 서로의 관점을 이해하게 되기 때문입니다. 요약하면, 조직의 칸막이를 허물고, 도메인을 단위로 크로스기능팀을 구성하는 방향으로 나아가야 합니다 (이것은 Conway의 법칙 관점에서도 바람직한 변화입니다).

이와 같은 조직적 대응 노력을 통해, 기술적 전환을 뒷받침할 제도와 문화의 기반을 갖추게 됩니다. 특히 금융/공공 분야는 규제와 감사에도 대비해야 하므로, 새로운 아키텍처 하에서 컴플라이언스와 보안을 어떻게 유지할지에 대한 가이드도 포함하여 거버넌스 체계를 보완해야 합니다. 중요한 것은 유연성 확보와 통제 간의 균형입니다. 완전 중앙통제에서 완전 자율로 한 번에 가기는 어렵기에, 단계적으로 Federated Governance 모델을 구현해 나가면서 경험을 축적하는 접근이 현실적입니다.

결론: 기술 이상의 변화, 업무 분해와 데이터 책임 재정의로의 여정

전통적인 데이터 중심 조직이 도메인 기반 아키텍처로 전환하는 과정은 단순히 새로운 기술 스택을 도입하는 프로젝트가 아닙니다. 이것은 조직의 사고방식과 업무 처리 방식 전반을 바꾸는 변혁입니다. CIO를 비롯한 정책결정자들은 이 변화를 기술적 혁신임과 동시에 비즈니스 운영모델의 재구성으로 이해해야 합니다. 다시 말해, 도메인 중심 아키텍처란 업무 분해(Business decomposition)를 기술적으로 뒷받침하는 것이고, 동시에 데이터 구조의 책임 범위를 재정의하는 작업입니다. 각 도메인 팀이 자신의 데이터와 기능에 끝까지 책임을 지게 되는 구조로 가는 것이며, 이는 조직 문화상 권한 이양(empowerment)과 책임소재의 명확화를 수반합니다.

물론 이러한 전환이 단기적으로는 혼란과 충돌을 유발하지만, 그 본질적인 목적은 민첩하고 유연한 조직으로 거듭나기 위함입니다. 클라우드 네이티브 시대에 비즈니스 변화 속도를 따라잡으려면, 더 이상 모든 것을 중앙에서 완벽히 조율하려는 느린 움직임으로는 불가능합니다. 도메인 중심 접근은 일정 부분 혼돈을 받아들이는 대신, 속도와 적응력을 얻는 선택입니다. 이것을 전략적으로 성공시키려면, 전사적 관점에서의 뒷받침이 필수적입니다. 최고 경영진은 명확한 비전과 의지를 가지고 조직 개편과 자원 투입을 주도해야 합니다. 예산 배분에서도 단순 시스템 개발 비용 외에 교육훈련, 문화 정착 비용을 반영하고, 전환 과정에서 일시적으로 효율이 떨어지더라도 장기적 안목으로 인내하며 지원해야 합니다.

마지막으로, “사람”의 중요성을 다시 한 번 강조하고 싶습니다. 새로운 아키텍처를 이해하고 활용하는 것도 사람이고, 협업하고 갈등을 해소하는 것도 사람입니다. CIO와 정책 결정자들은 기술적 투자를 넘어, 인재 육성과 조직 학습에 투자해야 합니다. 도메인 중심 아키텍처로의 전환 여정에서 나타나는 숱한 충돌들은 사실 조직이 성장통을 겪는 과정이라 볼 수 있습니다. 이 과정을 통해 조직은 자신만의 모델과 언어를 재발견하고, 더 탄탄한 디지털 근육을 갖추게 될 것입니다. 궁극적으로 이러한 노력이 금융 및 공공기관의 디지털 전환을 가속화하고, 빠르게 변화하는 환경에서도 민첩하게 대응하는 유연한 조직으로 거듭나게 할 것입니다. 기술 이상의 변화를 수용하겠다는 자세로 접근할 때, 도메인 중심 아키텍처 전환은 비로소 기대한 성과를 실현하게 될 것입니다.

글: 투이컨설팅 NIB 신창섭