도메인 주도 설계(DDD) 입문 — 비개발자를 위한 3원칙과 AI 에이전트 시대에 다시 주목받는 이유
2003년, 소프트웨어 엔지니어 Eric Evans는 "Domain-Driven Design: Tackling Complexity in the Heart of Software"라는 책을 출간했습니다(Addison-Wesley, 2003). 업계에서 '블루북(Blue Book)'으로 불리는 이 책은 20년 넘게 소프트웨어 설계의 고전으로 자리잡았습니다. 그런데 2025년부터, 이 20년 된 설계 철학이 전혀 다른 맥락에서 다시 주목받고 있습니다 — 에이전틱 AI 시스템 설계입니다. AWS는 2025년 9월 공식 블로그에서 "항공 산업에서 DDD는 전문화된 에이전트를 위한 자연스러운 경계를 식별하는 데 도움을 준다"고 밝혔고(AWS Builder, 2025-09-04), James Croft는 "멀티 에이전트 AI 시스템을 구축하는 것은 현대 소프트웨어 플랫폼을 설계하는 것과 많은 유사점이 있다"고 분석합니다(James Croft, 2025-08-14).
이 글은 DDD의 핵심 3원칙을 비개발자도 이해할 수 있도록 일상적 비유와 실제 사례로 설명합니다. 코드는 한 줄도 등장하지 않습니다. 대신, 이 3원칙이 왜 AI 에이전트 시대에 다시 중요해졌는지를 함께 연결합니다.
DDD란 무엇인가 — 한 문장 정의
ByteByteGo 뉴스레터는 DDD를 이렇게 정의합니다. "DDD는 데이터베이스 스키마나 최신 프레임워크가 아니라, 비즈니스 도메인을 의사결정의 중심에 놓는 소프트웨어 설계 방식이다."(ByteByteGo, 2025-04-24) 한국어로 더 쉽게 풀면 이렇습니다: "기술이 아니라 비즈니스가 설계를 이끌게 하라."
카카오페이 기술 블로그도 비슷한 맥락에서 설명합니다. "DDD는 기존의 애플리케이션 설계가 비즈니스 도메인에 대한 이해가 부족한 상태에서 설계·개발되었다는 것에 대한 반성의 의미로 시작되었다." 카카오페이는 여신(대출) 코어 시스템을 DDD로 재설계하면서, 단순히 기능을 이전하는 것이 아니라 도메인 모델링을 통해 비즈니스 로직을 명확히 분리하는 접근을 선택했습니다(카카오페이 기술 블로그, 2025-05-23).
핵심은 이것입니다: 소프트웨어가 복잡해지는 이유는 기술이 부족해서가 아니라, 비즈니스 문제를 제대로 이해하지 못한 상태에서 코드를 작성하기 때문입니다. DDD는 이 순서를 뒤집습니다 — 먼저 비즈니스를 깊이 이해하고, 그 이해를 설계에 직접 반영합니다.
원칙 1 — 도메인 집중 (Domain Focus)
"도메인"이란 무엇인가? 소프트웨어가 해결하려는 현실 세계의 문제 영역입니다. 커머스라면 상품·주문·결제가 도메인이고, 병원이라면 진료·처방·수납이 도메인입니다. DDD의 첫 번째 원칙은 이 도메인을 모든 설계 판단의 출발점으로 삼으라는 것입니다.
비유하면 이렇습니다. 레스토랑을 설계한다고 가정해 봅시다. 기술 중심 접근은 "어떤 주방 장비를 쓸까?"부터 시작합니다. DDD 접근은 "우리 고객은 누구이고, 어떤 음식을 원하며, 주문에서 서빙까지 어떤 과정을 거치는가?"부터 시작합니다. 주방 장비(기술)는 그 답에 맞춰 선택합니다.
Spartner Software는 이를 명확하게 정리합니다. "DDD는 마인드셋이다. 프레임워크도, 라이브러리도 아니다. 도메인 — 당신이 해결하려는 비즈니스 문제 — 을 무대의 중앙에 놓는 원칙과 패턴의 집합이다."(Spartner Software) Architecti.blog도 DDD의 첫 번째 원칙으로 "핵심 도메인 집중(Core Domain Focus)"을 꼽으며, "조직이 가장 큰 경쟁 우위를 가진 비즈니스 영역에 설계 노력을 집중하라"고 설명합니다(Architecti.blog, 2025-08-17).
에이전틱 AI에서 이 원칙은 더 중요해집니다. James Croft는 "임의로 에이전트를 만들지 마라. 당신의 비즈니스나 문제 공간이 자연스럽게 분해되는 방식에 기반하여 에이전트를 설계하라"고 권고합니다(James Croft, 2025-08-14). 즉, "챗봇 에이전트", "분석 에이전트"처럼 기술 기능별로 에이전트를 나누는 것이 아니라, "재고 관리 에이전트", "규정 준수 에이전트"처럼 비즈니스 도메인별로 에이전트를 나누라는 것입니다.
잘못된 예 — 종합병원에서 "AI 챗봇 하나"가 접수, 진료 예약, 처방 확인, 보험 청구를 모두 처리합니다. 환자가 "내 약 바꿔줘"라고 하면, 이 챗봇은 처방 도메인, 보험 도메인, 약국 재고 도메인을 동시에 알아야 합니다. 결과는 혼란과 오류입니다.
DDD 적용 — 도메인별로 분리합니다. "진료 예약 에이전트"는 예약만, "처방 관리 에이전트"는 처방만, "보험 청구 에이전트"는 보험만 담당합니다. 각 에이전트는 자기 도메인의 전문가입니다.
원칙 2 — 유비쿼터스 언어 (Ubiquitous Language)
DDD에서 가장 과소평가되지만 가장 강력한 개념입니다. 유비쿼터스 언어란, 비즈니스 전문가와 기술팀이 동일하게 사용하는 공유 어휘입니다. Eric Evans는 원서에서 이를 "팀 내 모든 활동을 소프트웨어와 연결하기 위해 Bounded Context 안에서 모든 팀원이 사용하는, 도메인 모델을 중심으로 구조화된 언어"라고 정의합니다(Eric Evans, DDD Reference, 2015).
Medium의 DDD 입문 기사는 더 쉽게 설명합니다. "유비쿼터스 언어란 모든 사람 — 도메인 전문가와 개발자 — 이 동일하게 사용하는 공유 어휘다."(Medium, 2025-11-18) 목적은 단순합니다: 모든 사람이 같은 단어로 같은 의미를 말하게 하는 것입니다.
왜 이것이 중요할까요? 현실에서 같은 단어가 부서마다 다른 의미를 가지는 경우가 비일비재합니다. "고객"이라는 단어 하나만 해도, 영업팀은 "잠재 구매자"를, 지원팀은 "기존 사용자"를, 회계팀은 "청구 대상"을 의미합니다. 이 혼란이 코드에 그대로 들어가면, 시스템은 어느 순간 아무도 전체를 이해할 수 없는 상태가 됩니다. Eric Evans는 이 상태를 "Big Ball of Mud(거대한 진흙 덩어리)"라 부릅니다 — 모든 것이 뒤엉켜서 한 부분을 건드리면 예측할 수 없는 다른 부분이 깨지는 시스템입니다(Hackolade, DDD Data Modeling).
AI 에이전트 시스템에서 유비쿼터스 언어는 프롬프트와 코드의 일관성으로 나타납니다. James Croft는 "Bounded Context 내에서 인간 도메인 전문가가 이해할 수 있는 일관된 용어를 사용하라. 예를 들어, '규정 준수 에이전트'는 'policy check', 'regulation clause' 같은 용어를 일관되게 사용해야 한다. 이렇게 하면 에이전트의 프롬프트와 코드가 주제 전문가(SME)와 훨씬 가깝게 정렬된다"고 설명합니다(James Croft, 2025-08-14).
일상적 예시 — 어떤 가정에서 "저녁"이라는 단어가 가족마다 다른 의미라고 상상해 보세요. 엄마에게 "저녁"은 오후 6시 식사, 아빠에게는 퇴근 시간, 아이에게는 게임 시간입니다. "저녁 준비해"라는 말 한마디에 세 사람이 전혀 다른 행동을 합니다. 유비쿼터스 언어는 "우리 가족에서 '저녁'은 오후 6시 30분에 함께 먹는 식사를 의미한다"라고 명시적으로 합의하는 것입니다.
AI 에이전트 예시 — "주문"이라는 단어를 마케팅 에이전트는 "잠재 고객의 관심 표현"으로, 물류 에이전트는 "배송 대상 건"으로, 회계 에이전트는 "매출 인식 이벤트"로 해석할 수 있습니다. 유비쿼터스 언어가 없으면 에이전트 간 데이터 전달 시 의미가 왜곡되어 연쇄적 오류가 발생합니다.
원칙 3 — 바운디드 컨텍스트 (Bounded Context)
Martin Fowler는 바운디드 컨텍스트를 이렇게 정의합니다. "Bounded Context는 Domain-Driven Design의 핵심 패턴이다. DDD는 큰 모델을 서로 다른 Bounded Context로 나누고, 그들 간의 상호관계를 명시적으로 정의함으로써 대규모 모델을 다룬다."(Martin Fowler, 2014-01-15) Fowler는 또한 "DDD에서 특히 중요한 부분은 전략적 설계(Strategic Design) — 대규모 도메인을 Bounded Context의 네트워크로 조직하는 방법 — 이다"라고 강조합니다(Martin Fowler, 2020-04-22).
쉽게 말하면, 바운디드 컨텍스트란 "이 용어와 규칙이 적용되는 명확한 경계"입니다. 경계 안에서는 모든 용어가 하나의 의미만 가지며, 경계 밖과는 명시적인 번역(mapping) 규칙을 통해 소통합니다.
ByteByteGo는 이를 실무적으로 풀어줍니다. 이커머스 시스템에서 "Product"라는 개념은 카탈로그 컨텍스트에서는 이름·설명·이미지를 의미하지만, 주문 컨텍스트에서는 SKU·수량·가격을, 배송 컨텍스트에서는 무게·크기·창고위치를 의미합니다. 같은 단어지만 각 컨텍스트에서 다른 모델이 됩니다. DDD는 이 차이를 숨기는 대신 명시적으로 분리합니다(ByteByteGo, 2025-04-24).
국가와 국경 — 각 나라는 자체 법률, 화폐, 언어를 가집니다. 한국에서 "만 원"은 한국 원화 10,000원이고, 일본에서 "만 엔"은 일본 엔화 10,000엔입니다. 같은 숫자지만 경계(국경)에 따라 의미와 가치가 다릅니다. 국경을 넘을 때는 환전(번역)이라는 명시적 변환을 거칩니다.
바운디드 컨텍스트도 마찬가지입니다. "재고 관리" 컨텍스트의 규칙은 "마케팅" 컨텍스트에 직접 적용되지 않습니다. 경계를 넘어 데이터를 전달할 때는 명시적 변환(DDD에서는 이를 Context Mapping이라 부릅니다)을 거칩니다.
AI 에이전트 시스템에서 바운디드 컨텍스트는 에이전트의 자연스러운 경계가 됩니다. James Croft는 "하나 또는 그 이상의 에이전트가 하나의 바운디드 컨텍스트를 구성한다. 에이전트는 자신의 특정 도메인에 대한 지식과 규칙을 캡슐화한다"고 설명합니다(James Croft, 2025-08-14). AWS도 항공 산업 사례에서 "에이전트 책임을 바운디드 컨텍스트에 정렬함으로써, 항공사는 특정 작업에 탁월한 집중된 에이전트를 만들 수 있다"고 밝혔습니다(AWS Builder, 2025-09-04).
세 원칙이 만드는 구조 — 왜 AI 에이전트에 딱 맞는가
세 원칙을 합치면 하나의 명확한 설계 철학이 됩니다: 비즈니스 도메인(원칙 1)을 공유 언어(원칙 2)로 정의하고, 명확한 경계(원칙 3)로 분리하라. 이 구조가 AI 에이전트에 자연스럽게 매핑되는 이유를 표로 정리합니다.
| DDD 원칙 | 소프트웨어 설계에서의 의미 | AI 에이전트에서의 적용 |
|---|---|---|
| 도메인 집중 | 비즈니스 문제가 설계를 이끈다 | 에이전트를 기술 기능이 아닌 비즈니스 도메인별로 분리 |
| 유비쿼터스 언어 | 전문가와 개발자가 같은 용어 사용 | 에이전트 프롬프트와 출력이 도메인 전문가의 용어와 일치 |
| 바운디드 컨텍스트 | 경계 안에서 모델이 일관성을 유지 | 에이전트의 지식·권한·규칙 범위를 명시적으로 한정 |
Microsoft Azure Architecture Center가 2025년에 공개한 멀티 에이전트 AI 설계 패턴 레퍼런스 가이드는 DDD의 이 구조를 그대로 반영합니다. Sequential(파이프라인), Concurrent(병렬), Group Chat(협업), Manager/Planner(관리자) 등 네 가지 오케스트레이션 패턴 모두, 에이전트 간의 명확한 역할 분리와 정의된 인터페이스를 전제로 합니다(Azure Architecture Center, 2025).
원문 아티클의 저자 Sathiyan도 이를 명시적으로 연결합니다. "Bounded Context 대신 모놀리식 모델을 사용하면, DDD에서 Eric Evans가 경고한 'Big Ball of Mud' — 모든 것이 연결되어 아무것도 독립적으로 변경할 수 없는 시스템 — 가 AI 에이전트 영역에서 재현된다." 수십 개의 AI 에이전트가 경계 없이 서로의 데이터와 로직에 의존하면, 하나를 수정할 때 예측할 수 없는 연쇄 효과가 발생합니다(Sathiyan, Medium, 2025-07-27).
실제 적용 — DDD로 설계된 AI 에이전트 시스템
AWS Builder의 항공 산업 사례가 3원칙의 실전 적용을 가장 명확하게 보여줍니다. 항공사의 비즈니스를 DDD로 분석하면 자연스럽게 여러 바운디드 컨텍스트가 도출됩니다: 예약 관리, 항공편 운영, 고객 서비스, 수하물 처리, 규정 준수 등. 각 컨텍스트에는 고유한 용어(유비쿼터스 언어)가 있습니다 — "예약"은 예약 컨텍스트에서는 "좌석이 확보된 여정"이지만, 수익 관리 컨텍스트에서는 "가격이 책정된 수요 단위"입니다. AWS는 "에이전트 책임을 이 바운디드 컨텍스트에 정렬함으로써, 항공사는 특정 작업에 탁월한 집중된 에이전트를 만들 수 있다"고 결론짓습니다(AWS Builder, 2025-09-04).
한국에서는 카카오페이의 여신코어 DDD 적용 사례가 주목할 만합니다. 카카오페이는 여신(대출) 업무를 내재화하면서 DDD의 바운디드 컨텍스트로 도메인을 분리했고, 이를 통해 복잡한 대출 프로세스의 각 단계가 독립적으로 진화할 수 있는 구조를 만들었습니다(카카오페이 기술 블로그, 2025-05-23). 카카오 엔터테인먼트도 if(kakao)2022에서 레거시 서버를 DDD 기반 마이크로서비스로 전환한 사례를 공유했습니다(YouTube, if(kakao)dev2022). KB국민은행과 카카오페이증권도 AWS Summit 2025에서 DDD와 Hexagonal Architecture를 적용해 업무 도메인과 인프라를 분리한 사례를 발표했습니다(아잇팅, 2025-05-20).
LinkedIn에서 Tim Oleson은 DDD와 에이전틱 서비스의 연결을 더 확장합니다. "EventStorming 워크숍과 결합된 DDD 원칙이 MCP(Model Context Protocol)와 도구를 활용하는 에이전틱 서비스의 설계를 어떻게 안내할 수 있는지"를 탐구하며, 도메인 이벤트 기반으로 에이전트의 행동 범위를 정의하는 접근을 제안합니다(LinkedIn, Tim Oleson, 2025-07).
흔한 오해 — DDD가 "아닌" 것
"DDD는 코딩 기법이다" — 아닙니다. DDD의 핵심은 전략적 설계(Strategic Design)이며, 이는 코드 이전에 비즈니스 도메인을 이해하고 경계를 정의하는 사고방식입니다. ByteByteGo는 "DDD는 데이터베이스 스키마나 최신 프레임워크가 아니라, 비즈니스 도메인을 의사결정의 중심에 놓는 설계 방식"이라고 명확히 구분합니다(ByteByteGo).
"DDD는 마이크로서비스와 같은 것이다" — 아닙니다. Vladik Khononov는 "Bounded Context는 마이크로서비스의 정반대다. Bounded Context는 가능한 가장 큰 서비스의 경계를 정의한다"고 지적합니다(vladikk.com, 2018). 바운디드 컨텍스트는 분리의 기준이지, 특정 아키텍처 스타일이 아닙니다.
"DDD는 대기업만 쓰는 것이다" — 아닙니다. Reddit의 한 답변이 이를 잘 반박합니다. "DDD를 써야 하는지는 회사의 규모와 전혀 상관없다. 복잡한 도메인을 분해할 수 있게 해주는 전략적·전술적 도구 세트다."(Reddit, r/dotnet)
"DDD를 쓰면 모든 문제가 해결된다" — 아닙니다. ByteByteGo도 "DDD는 은탄환이 아니다. 코드를 생성하지도 않고, 레거시 모놀리스를 마법처럼 고치지도 않는다"고 분명히 말합니다. DDD가 제공하는 것은 "시스템이 무엇을 해야 하는지, 어디에서 변경이 허용되는지에 대한 명확성"입니다.
결론 — 20년 된 원칙이 AI 시대에 다시 빛나는 이유
정리하면, DDD의 3원칙은 놀랍도록 간결합니다. 비즈니스를 깊이 이해하라(도메인 집중). 모든 사람이 같은 단어로 말하게 하라(유비쿼터스 언어). 명확한 경계를 긋고, 경계 안의 일관성을 지켜라(바운디드 컨텍스트).
이 원칙이 2025~2026년의 에이전틱 AI에서 다시 주목받는 이유는, AI 에이전트가 직면하는 문제가 20년 전 소프트웨어가 직면했던 문제와 본질적으로 같기 때문입니다. 경계 없이 뒤엉킨 에이전트들은 Eric Evans가 경고한 "Big Ball of Mud"의 AI 버전이 되고, 이전 글에서 다룬 5가지 함정 — 비용 폭증, 파일럿 실패, 거버넌스 공백, 보안 위협, 에이전트 워싱 — 을 모두 촉발합니다.
다음 글에서는 이 3원칙을 기반으로, DDD가 AI 에이전트 시스템에 왜 특히 적합한지를 구체적인 매핑(Bounded Context = Agent Boundary)과 함께 더 깊이 탐구합니다.
- Eric Evans (2003): Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley)
- Eric Evans (2015): DDD Reference — 유비쿼터스 언어 공식 정의
- Martin Fowler (2014): Bounded Context — "DDD의 핵심 패턴"
- Martin Fowler (2020): Domain-Driven Design — 전략적 설계와 Bounded Context 네트워크
- ByteByteGo (2025.4.24): Domain-Driven Design (DDD) Demystified
- Architecti.blog (2025.8.17): The Fundamental Principles of DDD — 10가지 원칙 정리
- Spartner Software: DDD: Foundational Guide — "DDD는 마인드셋"
- Medium (Doğuhan Erbil) (2025.11.18): DDD: What It Is and Why It Matters
- Hackolade: Domain-Driven Data Modeling — Big Ball of Mud 정의
- James Croft (2025.8.14): Applying DDD Principles to Multi-Agent AI Systems
- AWS Builder (2025.9.4): How DDD Unlocks the Power of Agentic AI Systems — 항공 산업 사례
- Azure Architecture Center (2025): AI Agent Orchestration Patterns
- 원문 DDD 아티클 (Sathiyan) (2025.7.27): Revolutionizing Enterprise AI: Applying DDD for Agentic Applications
- 카카오페이 기술 블로그 (2025.5.23): 여신코어 DDD로 구축하기
- 카카오 엔터테인먼트 (2022): DDD와 적용 사례 공유 / if(kakao)dev2022
- 아잇팅 (2025.5.20): KB국민은행·카카오페이증권 DDD·Hexagonal Architecture 적용
- Tim Oleson, LinkedIn (2025.7): DDD's Role in Agentic Services
- Vladik Khononov (2018): Bounded Contexts are NOT Microservices
이 글은 2026년 2월 23일 기준으로 작성되었습니다. DDD는 Eric Evans가 2003년 제시한 설계 철학이며, 본문의 해석은 원서와 공개된 레퍼런스를 기반으로 합니다. AI 에이전트에 대한 DDD 적용은 2025년부터 활발히 논의되고 있는 신생 영역이므로, 산업 표준이 확립되기까지 시간이 필요합니다. 인용된 기업(카카오페이, AWS, Microsoft 등)의 발언은 각사 공식 블로그/발표에서 직접 발췌한 것이며, 해당 기업과의 이해관계는 없습니다.
댓글
댓글 쓰기