공식 문서만 보다 팀 전체 멘붕 왔던 경험: DDD 도메인 주도 설계 실전 적용기 2026

by

2년 전쯤, 팀 리드한테 이런 말을 들었다. “이번 프로젝트, DDD로 갑시다.” 그 순간 팀원 전원이 고개를 끄덕였지만, 눈빛만큼은 하나같이 ‘나는 모른다’였다. Eric Evans의 블루북 PDF를 Slack에 공유하고, 모두가 각자 읽고 왔는데, 막상 설계 회의에 들어가니 개발자는 개발자대로, 기획자는 기획자대로 다른 언어를 쓰고 있었다. 공식 문서와 책만 믿었다가 현장에서 산산조각 난 설계를 보며 깨달았다. DDD는 책으로 배우는 게 아니라, 삽질로 배우는 거구나.

이 글은 그 삽질의 결과물이다. 2026년 현재, 국내외 기업들이 실제로 어떻게 DDD를 쓰고 있는지, 어디서 막히는지, 절대 하면 안 되는 실수가 뭔지 전부 털어놓는다.

🔥 DDD가 뭔데? 5분 안에 때려잡기

도메인 주도 설계(DDD, Domain-Driven Design)는 복잡한 비즈니스 로직과 변화하는 요구사항을 효과적으로 관리하기 위해, 소프트웨어 설계의 중심을 “도메인”에 두는 접근 방식이다. 쉽게 말하면, DB 테이블 먼저 설계하는 거 그만하고, 비즈니스 언어로 먼저 생각하자는 얘기다.

일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말한다. 그리고 DDD의 핵심 무기는 유비쿼터스 언어(Ubiquitous Language)다. 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고, 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말한다.

분석 모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라, 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심원리이다.

domain driven design architecture diagram, DDD bounded context map

📊 전략적 설계 vs 전술적 설계: 숫자로 보는 차이

DDD는 크게 두 레이어로 나뉜다. 큰 그림을 그리는 전략적 설계, 그 그림 안에 살을 붙이는 전술적 설계다.

DDD에서 말하는 전략적 설계는 도메인 전반의 구조를 정의하고, 팀과 조직 차원에서 모델링을 관리하는 방법론이다. 거대한 도메인을 하위 도메인(Subdomain)으로 나누고, 각 하위 도메인에 대해 Bounded Context를 정의한다. 컨텍스트 매핑(Context Map)을 통해 여러 Bounded Context 간의 관계를 시각화하고, 협력 모델을 명시한다.

전술적 설계는 모델링 관점에서 구체적인 구현 기법을 다룬다. 엔티티, 값 객체, 애그리게이트, 리포지터리, 도메인 이벤트 같은 빌딩 블록이 여기에 속한다.

실무에서 팀 규모별로 DDD 도입 난이도와 ROI를 정리해보면 이렇다:

팀 규모 DDD 도입 난이도 초기 설계 비용 6개월 후 생산성 변화 추천 여부
2~5명 (스타트업 초기) ★★★★☆ (높음) +30~50% 오버헤드 큰 개선 없음 ❌ 비추
6~15명 (성장기) ★★★☆☆ (중간) +20~35% 오버헤드 +15~25% 향상 ✅ 조건부 추천
16~50명 (스케일업) ★★☆☆☆ (낮음) +15~20% 오버헤드 +40~60% 향상 ✅✅ 강력 추천
50명 이상 (대기업) ★☆☆☆☆ (매우 낮음) +10~15% 오버헤드 +60% 이상 향상 ✅✅✅ 필수

* 위 수치는 국내외 기술 블로그 및 실무 사례를 종합한 참고 추정치입니다.

초기 학습과 설계가 다소 부담될 수 있으나, 장기적으로 유지보수성과 확장성에서 이점을 얻는다. 단기 스프린트에 쫓기는 팀이라면 솔직히 DDD 도입하지 마라. 나중에 더 고생한다.

🏢 카카오페이·타다 실전 사례: 저 회사들은 어떻게 했나

카카오페이 여신코어 사례

카카오페이 후불결제(BNPL)의 여신코어시스템을 DDD로 구축한 경험이 공유되었다. 여신비즈니스가 시스템으로 구현되는 과정에서 DDD를 프로젝트 팀에서 어떻게 활용하였는지, 코드레벨에서는 어떤 구조로 설계하고 구현하였는지에 대한 내용이다.

특히, DDD의 핵심 가치인 ‘공통 언어(Ubiquitous Language)’의 정립은 프로젝트 성공의 중요한 키가 되었다. 개발자와 기획자, 여신 전문가 모두가 기술 용어가 아닌, 모두가 이해하는 도메인 중심의 언어로 소통하면서 요구사항의 모호함이 줄어들고, 핵심 비즈니스 로직에 대한 깊이 있는 논의가 가능해졌다.

카카오페이는 여러 도메인 모듈에 걸치는 복잡한 기능을 처리하기 위해 “Biz-component”라는 package를 만들어 공통으로 사용해야 하는 주요 기능들에 대해서는 이를 활용하는 것을 규칙으로 하여, 주요 기능의 중복 구현을 방어하고 집중할 수 있었다.

타다(TADA) 정산 도메인 사례

도메인 지식과 코드의 복잡성이 매우 높아 기능을 추가하는 데에 큰 어려움이 있었고, 도메인 전문가가 명확하지만 사용하는 언어의 의미가 달라 커뮤니케이션에 어려움을 느끼고 있었다. 이게 DDD를 도입한 핵심 이유였다.

결과는 놀라웠다. 현재까지 정합성 오류 0건일 정도로 성공적으로 프로젝트를 진행하고 있다. 특히 가독성과 확장성의 큰 개선은 앞으로 정산 도메인의 유지보수에, 공통 모델 정의는 도메인 전문가와의 긴밀한 의사소통에 매우 도움이 될 것으로 기대하고 있다.

마이크로소프트 Azure의 DDD+MSA 전략

글로벌 빅테크도 같은 접근이다. 마이크로서비스 설계의 일반 원칙으로, 하나의 마이크로서비스는 애그리게이트보다 작아서는 안 되고, Bounded Context보다 커서는 안 된다. 이게 2026년 MSA 설계의 정석이다.

microservices bounded context diagram, DDD aggregate Spring Boot

🗺️ Bounded Context, Aggregate, Ubiquitous Language 완전 정복

Bounded Context (바운디드 컨텍스트)

같은 상품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 바운디드 컨텍스트(Bounded Context)라고 부른다. 바운디드 컨텍스트는 모델의 경계를 결정하며, 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.

Aggregate (애그리게이트)

JPA가 entity 단위였다면, DDD의 repository는 Aggregate 단위로 repository를 만든다. Aggregate 단위의 repository가 aggregate의 원자성을 보장하게 된다. 이 차이를 모르고 JPA 쓰듯이 DDD 짜다가 팀 전체 야근 코스 탔다는 후배도 있다.

애그리게이트 간에는 결과적 일관성(eventual consistency)을 사용하라. 비즈니스 프로세스가 여러 애그리게이트에 걸쳐있을 때는 단일 트랜잭션이 아닌 도메인 이벤트를 사용하라. 예를 들어 배달이 완료되면 Delivery 애그리게이트가 DeliveryCompleted 이벤트를 발행하고, 다른 서비스들이 비동기적으로 반응한다.

Domain Service (도메인 서비스)

도메인 서비스는 하나의 aggregate만으로 처리가 힘든 경우의 ‘도메인 로직’을 처리해주는 ‘행위’만 가진 서비스다. 즉, 여러 aggregate 간의 협력이 필요한 도메인 로직을 수행해주며 이로써 도메인 로직이 어플리케이션 로직으로 침범하는 것을 막아주는 일종의 방파제 역할을 한다.

⚠️ 비교표: DDD vs 전통적 데이터 중심 설계

항목 데이터 중심 설계 (전통 방식) DDD (도메인 주도 설계)
설계 시작점 DB 테이블, ERD 비즈니스 도메인, 유비쿼터스 언어
캡슐화 낮음 (Getter/Setter 남발) 높음 (도메인 로직 내부화)
팀 커뮤니케이션 기획↔개발 언어 불일치 빈번 공통 언어로 오해 감소
확장성 결합도 높아 변경 시 리스크 큼 Bounded Context로 독립 확장 가능
초기 비용 낮음 높음 (설계·학습 비용)
장기 유지보수 복잡도 기하급수적 증가 도메인별 독립 관리 가능
테스트 용이성 낮음 (의존성 얽힘) 높음 (독립 단위 테스트)
MSA와의 궁합 나쁨 매우 좋음 (BC = 서비스 경계)

높은 응집력과 낮은 결합도로 각각의 도메인을 서로 철저히 분리하고, 변경과 확장에 용이한 설계를 얻게 된다. 데이터 중심 설계의 가장 큰 함정은 설계 시 협력에 고민을 하지 않았기 때문에 과도한 접근자와 수정자가 탄생하고, 결과적으로 대부분의 구현이 외부에 노출되기 때문에 캡슐화의 원칙을 위반하게 된다.

🚫 절대 하면 안 되는 실수 7가지

책에서 안 알려주는, 현장에서 피로 쓴 가이드다.

  • ❌ 실수 1: Aggregate를 너무 크게 설계하기
    “작은 Aggregate을 설계하라. 단일 트랜잭션 내에서 일관성을 유지해야 하는 데이터만 포함하라.” Order에 User 정보까지 다 때려박지 마라.
  • ❌ 실수 2: Bounded Context 간 직접 객체 참조
    다른 애그리게이트는 ID로만 참조하라. Delivery 애그리게이트는 DroneId와 PackageId만 저장하고, 그 객체에 직접 참조하지 않는다. 이 디커플링이 마이크로서비스 경계와 직접 연결된다.
  • ❌ 실수 3: Ubiquitous Language 없이 코드부터 짜기
    도메인에서 사용하는 용어를 코드에 반영하지 않으면, 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다. 용어 사전 없이 개발 들어가면 3개월 후 코드베이스가 고대 유물이 된다.
  • ❌ 실수 4: 비즈니스 로직을 Application Service에 넣기
    Application Service는 유스케이스를 조율하고 도메인 서비스와 리포지터리 호출을 조율하며 트랜잭션을 관리한다. Application Service 자체에는 비즈니스 로직이 없어야 한다.
  • ❌ 실수 5: 단순 CRUD 시스템에 DDD 억지로 끼워맞추기
    DDD 개념을 무리하게 적용하면 오히려 복잡도가 높아질 수 있으므로, 비즈니스 복잡도가 낮은 시스템에는 가벼운 접근을 고려한다. 게시판에 DDD 붙이면 욕먹는다.
  • ❌ 실수 6: 도메인 이벤트와 일반 DB 이벤트 혼동하기
    도메인 이벤트는 도메인 관점에서 의미있는 변화다. 예를 들어 “레코드가 테이블에 삽입되었다”는 도메인 이벤트가 아니지만, “배달이 취소되었다

    📚 관련된 다른 글도 읽어 보세요

    태그: []

Leave a Comment