20년전에 등장한 DDD, 도메인 지식 전문가라고 불리는 영역이 GPT와 같은 LLM이 흡수하고 있는것도 사실이며 "도메인 전문가"라는 의미를 다시 해석할 필요가 있는것 같습니다.
그렇다고 DDD의 철학/전략이 모두 쓸모없는것은 아닌것같고 도메인모델을 이해하고 해석하는 통찰력을 가지게 하는것은 사실이기때문입니다.
그러한 관점에서 DDD가 쓸모없다가 아니라, 20년전 등장한 방식이 오늘날도 유용한가? 의 관점에서 유용한 영상을 분석해보았습니다.
📌 도메인 주도 설계(DDD) 책의 1장과 2장을 읽고 저자가 느낀 현실과의 괴리감은 무엇인가?
저자는 비즈니스를 이해하는 것의 어려움, 핵심 하위 도메인과 일반 하위 도메인을 구분하는 것의 어려움, 핵심 하위 도메인을 내재화해야 한다는 주장에 대한 의문, 그리고 유비쿼터스 언어를 도메인 용어 기반으로 만드는 것의 불가능성 등 책의 내용이 현실과 동떨어진 부분이 많다고 느꼈습니다.
💡 저자가 생각하는 유비쿼터스 언어의 진정한 역할과 활용 장소는?
유비쿼터스 언어는 도메인 전문가와의 커뮤니케이션보다는 개발팀 내부에서 용어를 통일하기 위해 사용되며, 가장 효과적으로 활용되는 장소는 피그마와 같은 기획 문서입니다.
이 컨텐츠는 도메인 주도 설계(DDD) 책의 1, 2장을 읽고 현실적인 개발 환경과 애자일 방법론의 관점에서 비판적으로 분석한 내용을 다룹니다. 특히, 비즈니스 도메인이해의 어려움, 핵심 도메인내재화의 현실적인 제약, 그리고 유비쿼터스 언어의 실질적인 활용처에 대한 발표자의 경험과 생각을 공유하며, DDD 이론과 실제 적용 간의 괴리를 지적합니다.
1. 비즈니스 도메인 이해의 한계와 현실 [4]
비즈니스를 잘 이해한다는 증거는 실제로 돈을 벌고 있는지로 판단함 [4]
말만 번지르르하게 해도 돈을 못 벌면 비즈니스를 잘 아는 게 아님 [6]
대부분의 회사는 돈을 많이 벌지 못하거나 적자, 투자금으로 운영 중임 [9]
쿠팡도 흑자 전환이 늦었고, 많은 회사가 사후적으로 돈을 벌 거라 예상만 함 [13]
돈을 벌었어도 왜 벌었는지 모르는 경우가 많음 [16]
사업가, 경영인도 비즈니스로 돈을 버는 원리를 잘 모름 [20]
개발자가 비즈니스를 이해하는 것은 거의 불가능에 가까움 [24]
사업 당사자도 잘 모르는 비즈니스를 개발자가 이해하기 어렵다는 현실적 한계 [28]
실제 비즈니스 현장에서는 관찰 가능한 행동만 파악 가능함 [54]
예: 창고에서 출고 목록을 피킹, 패킹하는 과정 등 [56]
왜 그렇게 하는지, 효율적인지 이해는 어렵지만, 실제로 하고 있다는 사실만 알 수 있음 [66]
2. 도메인 전문가의 한계와 교차 검증의 필요성 [75]
도메인 전문가도 실제로는 전체 도메인을 잘 모를 수 있음 [75]
법령, 안전 기준 등도 현장에서는 잘 모르는 경우 많음 [74]
대기업 도메인 전문가는 좁은 범위만 알고 있을 가능성이 높음 [88]
업무가 세분화되어 있기 때문
중소기업 도메인 전문가는 시장 전체 흐름을 모를 수 있음 [90]
도메인 전문가의 지식은 반드시 교차 검증이 필요함 [98]
실제로 누가 이 검증을 할지 명확하지 않음 [99]
기획팀이 독박을 쓰는 경우가 많음 [108]
스크럼에서는 제품 책임자가 도메인 검증을 담당하지만, 실제로는 잘 운영되지 않음 [110]
3. 도메인 분류(핵심/일반/지원)와 그 현실적 어려움 [121]
책에서는 도메인을 핵심 하위 도메인, 일반 하위 도메인, 지원 하위 도메인으로 나눔 [122]
핵심: 경쟁력, 차별성, 돈이 많이 되는 부분 [126]
일반: 핵심은 아니지만 필요한 부분
지원: 돈을 벌기 위해 반드시 해야 하는 부수적 작업 [136]
핵심 도메인과 일반 도메인을 구분하는 것이 매우 어렵다 [138]
사장도, 도메인 전문가도 실제로 무엇이 핵심인지 모르는 경우가 많음 [138]
예시: 오리온 초코파이, 아마존(AWS vs 쇼핑몰), 세스코, SK의 이메일 CS 서비스 등 [128]
초코파이 광고로 인해 핵심 도메인이 바뀜 [129]
아마존은 AWS가 돈을 벌지만, 쇼핑몰은 적자 [162]
세스코의 하위 도메인이 돈을 벌기도 함 [167]
핵심/일반/지원 도메인 구분이 오히려 비즈니스 성장을 막을 수도 있음 [183]
실제로 돈이 되는 부분을 외주나 지원 도메인으로 분류해 놓고 기회를 놓칠 수 있음 [183]
예: 보도블록에 LED를 박아 신호등과 연동해 돈을 번 사례
4. 하위 도메인 개발과 자원 배분의 현실 [193]
회사는 개발을 위해 존재하는 게 아니라, 돈을 벌기 위해 개발함 [198]
비용과 자원을 최적화해야 함 [199]
개발팀 예산과 외주예산을 나누어 자원을 배분하는 방법 제시 [218]
개발팀 우선 배정: 개발팀이 소화 가능한 만큼 핵심/일반/지원 도메인에 자원 배정, 남은 것은 외주 [220]
외주우선 배정: 외주예산으로 지원/일반/핵심 순으로 배정, 남은 것은 개발팀이 담당 [227]
현실에서는 도메인 줄이기보다는 외주업체나 개발팀에 부담을 전가함 [231]
외주 업체의 품질이 낮은 이유는 예산이 적기 때문 [239]
책에서 제시하는 하위 도메인 개발 방법이 현실과 괴리가 있음 [241]
5. 핵심 도메인 내재화와 기술적 차별성의 현실 [244]
책에서는 핵심 도메인은 기술적 역량, 차별성, 비교 우위가 있어야 한다고 설명 [247]
하지만 실제로 돈을 버는 핵심 도메인은 기술적 차별성이 없는 경우가 많음 [249]
예: 삼성전자, 넷플릭스, 아마존 등은 기술이 아니라 외부 요인(협상력, 콘텐츠 등)으로 돈을 법 [254]
기술적 우위의 정의가 매우 다양하고, 실제로는 뻥이 많음 [264]
"나만 만들 수 있다"는 주장도 현실에서는 거의 없음 [270]
핵심 도메인 내재화(자체 개발)는 현실적으로 어렵고, 오히려 외주 비율이 높음 [295]
대기업, 은행, 국가기관 등도 핵심 도메인을 외주로 처리함 [298]
오프라인 예시: 건물 주차장, 자본잉여금 관리 등도 외부에 맡김 [305]
IT 기업도 외주인력, 오픈소스, 오픈 API 등 외부 솔루션을 적극 활용 [317]
핵심 도메인일수록 외주 비율이 높고, 빠른 대응이 중요함 [329]
5. 핵심 도메인 내재화와 기술적 차별성의 현실 [244]
책에서는 핵심 도메인은 기술적 역량, 차별성, 비교 우위가 있어야 한다고 설명 [247]
하지만 실제로 돈을 버는 핵심 도메인은 기술적 차별성이 없는 경우가 많음 [249]
예: 삼성전자, 넷플릭스, 아마존 등은 기술이 아니라 외부 요인(협상력, 콘텐츠 등)으로 돈을 법 [254]
기술적 우위의 정의가 매우 다양하고, 실제로는 뻥이 많음 [264]
"나만 만들 수 있다"는 주장도 현실에서는 거의 없음 [270]
핵심 도메인 내재화(자체 개발)는 현실적으로 어렵고, 오히려 외주 비율이 높음 [295]
대기업, 은행, 국가기관 등도 핵심 도메인을 외주로 처리함 [298]
오프라인 예시: 건물 주차장, 자본잉여금 관리 등도 외부에 맡김 [305]
IT 기업도 외주인력, 오픈소스, 오픈 API 등 외부 솔루션을 적극 활용 [317]
핵심 도메인일수록 외주 비율이 높고, 빠른 대응이 중요함 [329]
6. 유비쿼터스 언어(공통 언어)와 도메인 용어의 한계 [347]
도메인 용어를 유비쿼터스 언어로 만드는 데 한계가 많음 [361]
실제 도메인 용어가 부정확하거나, 스타트업처럼 새로운 비즈니스에는 기존 용어가 없음 [376]
예: 컬리의 새벽배송, 항공기 화물칸 경매 등 기존에 없는 개념 [378]
도메인 전문가와 IT팀 간의 언어적, 개념적 괴리 [411]
IT에 대한 이해가 없는 도메인 전문가와의 커뮤니케이션이 매우 어렵고, 실제로는 개발팀이 도메인 용어를 정의하는 경우가 많음 [414]
유비쿼터스 언어의 실질적 활용처는 기획서, 정책 문서, 피그마 등 [483]
코드에는 실제로 유비쿼터스 언어가 잘 반영되지 않음 [481]
피그마 등 실제로 많이 보는 화면에 용어가 일관되게 적용되는 것이 중요 [489]
예: '입항'이라는 용어가 피그마의 모든 화면에서 동일하게 사용되어야 함 [493]
영어 용어의 미묘한 차이(플랜, 스케줄, 오퍼레이션 등)도 한국어 사용자에게는 어렵다 [536]
7. 도메인 커뮤니케이션과 애자일의 현실적 결론 [547]
도메인 모델링의 핵심은 커뮤니케이션 [548]
하지만 실제로는 커뮤니케이션만으로 도메인 지식이 코드에 잘 전달되기 어렵고, 제품을 실제로 써봐야 알 수 있음 [557]
애자일 이론도 문서나 커뮤니케이션보다 제품 출시와 피드백을 중시함 [593]
도메인 전문가의 진짜 가치는 제품의 실제 사용자로서 피드백을 주는 것 [571]
도메인 모델링에 직접 참여하기보다는, 완성된 제품을 사용하고 피드백을 주는 역할이 더 중요함 [575]
스프린트 반복과 피봇(가치의 점프)이 중요 [663]
도메인 분석을 통한 솔루션이 아니라, 새로운 가치를 창출하는 것이 목표 [669]
DDD(도메인 주도 설계)와 애자일 방법론은 실제로는 상충하는 부분이 많음 [673]
DDD는 안정화된 도메인에 적합, 스타트업이나 변화가 많은 환경에는 애자일이 더 적합함 [675]
8. 결론 및 실무 적용의 어려움 [683]
책의 개념은 실무에 많은 도움을 주지만, 현실과의 괴리가 존재함 [345]
도메인 분류, 내재화, 유비쿼터스 언어등 이론과 실제의 간극이 큼 [346]
실제 현장에서는 유연하게 적용하고, 다양한 의견과 피드백을 통해 개선해 나가야 함 [290]
릴리 링크 : https://lilys.ai/digest/4959253/4281642?s=1¬eVersionId=559252
7년전이였나? DDD를 전혀 모를때 외국 글로벌 기업(VGW)에서 일을 하면서 DDD라는 컨셉을 처음듣고 해당 방법론대로 스프린트를 돌리는곳에
참여를해 고생한 경험이 있습니다. DDD는 그냥할수있는것이 아니라.. 그것을 하기위해 역량을 집중하고 설계를 고민하는 활동이
기본적으로 전제돠어 있습니다. 책한권 읽었다고 갑자기 할수 있는것은 아닌것같으며 개발팀은 이것을 도입하기위한 준비와
학습과정에 돈을 아끼지 않은듯...
국내 복귀후~ DDD가 우리(국내)에게는 안맞겠구나란 결정적으로 한 생각은 우리의 국내 문화가 해결책을 찾는 순서 자체가 완전히 다르다란 점이며
국내에서도 DDD를 일부 적용해 성공사례가 있을수 있겠지만 극히 소수인것같으며 , 보편적으로 문제를 찾고 인식하는 순서의 차이또는 문화적 습관으로 DDD도입이 어렵겠구나 라고생각하며
다음과 같은 이유들입니다.
| 구분 | 국내(한국 중심) | 해외(서구 중심: 미국, 유럽 등) |
|---|---|---|
| 출발점 | 해결책(솔루션)을 먼저 상상하고 시작 | 문제 정의부터 신중히 시작 |
| 사고방식 | "답을 빨리 내야 한다" → 속도 중심 | "문제가 맞는가?" → 정확성 중심 |
| 문제 정의 | 사후적으로 맞춰가는 경향 | 문제를 먼저 좁고 명확하게 정의 |
| 회의 패턴 | 결과지향적 브레인스토밍 (해결방안에 집중) | 원인 규명 중심 토론 (문제 원인과 가정 검증) |
| 보고 방식 | "어떻게 해결했는가"를 강조 | "무엇이 문제이고 왜 그것이 중요한가"를 강조 |
| 실패 인식 | 실패 = 책임 문제 → 회피 경향 | 실패 = 학습 기회 → 빠른 실험 장려 |
| 결정 방식 | 위에서 정한 방향에 맞는 문제를 나중에 맞춤 | 아래에서 문제 발견 후 위로 이슈 제기 |
| 대표적 표현 | “그거 해결됐어?” | “그게 진짜 문제야?” |
| 항목 | 국내식 접근의 장점 | 단점 | 해외식 접근의 장점 | 단점 |
|---|---|---|---|---|
| 속도 | 빠른 실행, 임시 해결 가능 | 근본 원인 방치, 반복 발생 | 문제 재발 방지 가능 | 초기 속도 느림 |
| 조직문화 | 상명하달, 위계질서 존중 | 비판·이견 표현 어려움 | 수평적 의견 수렴 가능 | 결론 도출 오래 걸림 |
| 창의성/혁신 | 정해진 틀 안에서 효율성 추구 | 창의적 시도 부족 | 다양한 관점의 문제 탐색 가능 | 통일된 방향성 부족 우려 |
| 학습/피드백 | 결과만 보는 평가 방식 | 실패 분석 부족 | 실패도 공유하며 성장 | 실험 과잉일 경우 리스크 존재 |
한국 조직은 “문제 해결”보다 “해결을 보이는 것”에 더 집중하는 경향이 있음. 이는 위기 대응 능력은 뛰어나지만 지속 가능한 개선에는 약점을 가질 수 있음.
해외에서는 “문제 정의 능력”이 곧 전문성으로 여겨짐. 문제를 잘 정의하면 절반은 푼 것이란 인식이 강함.
최근 한국 내에서도 “문제 정의의 중요성”, “가설 기반 접근”, “리트로스펙티브 문화” 등이 스타트업과 IT기업을 중심으로 점점 확산되고 있음.
| 구분 | 설명 |
|---|---|
| 1. 도메인 중심 사고 | DDD는 비즈니스 도메인의 문제와 복잡성 자체에 집중함. 기술은 그 문제를 해결하기 위한 도구일 뿐. |
| 2. 유비쿼터스 언어 (공통 언어) | 해결책을 먼저 정해놓고 진행하면 언어가 뒤따르기 쉽지만, DDD는 도메인 전문가와 개발자가 문제에 대한 공감대부터 만들어가는 것이 핵심. |
| 3. 지속적 탐색 (Exploration) | DDD는 끊임없이 문제를 탐색하고 모델을 수정해나가는 진화적 접근을 취함. 초기 해결책이 항상 옳지 않다는 전제를 깔고 있음. |
| 4. 복잡성 관리 | 표면적 문제가 아닌 **핵심 복잡성(Core Complexity)**을 파악하고 그것을 중심에 둔 구조 설계를 추구함. 이는 빠른 해결보단 올바른 문제 정의가 선행되어야 가능한 구조. |
| 한국식 (해결책 우선) | DDD 철학과 충돌하는 부분 |
|---|---|
| 빠르게 UI/기능 정의 → 개발 | 도메인 지식 없이 구조를 먼저 고정하면, 모델이 잘못되기 쉬움 |
| 개발 전에 해결책(PPT)부터 그리기 | 정작 중요한 문제는 해결되지 않고 겉모습만 구현될 가능성 |
| 도메인 전문가가 아니라 기획자가 요구사항을 주도 | 유비쿼터스 언어의 부재 → 커뮤니케이션 오류 발생 |
| 빠른 피처 구현과 릴리즈 우선 | 모델의 일관성과 의미 유지에 실패 |
DDD는 "문제를 먼저 정의하고, 도메인을 깊이 이해한 뒤 해결책을 도출하는 방식"에 최적화되어 있습니다.
따라서 해외(특히 유럽, 미국 등지)의 분석 중심, 가설 기반, 실험적 접근 방식과 가장 잘 어울립니다.
반면, 해결책을 먼저 상정하고 역으로 문제를 맞춰가는 조직 문화에서는 DDD가 형식적으로만 적용되고 실제 효과는 떨어질 수 있습니다.
나는 DDD신봉자도 반대자도 아니며 단지 뭔가 배울것이 어딘가에 있을것이다란 작은믿음이 있으며 , 프로젝트 초기팀을 셋업할때 이것을 꼭 적용하기 보다 "그냥 도움되는것있으면 배워~" 정도로 소개를 합니다.
적용하기 어려운 이유를 찾는것도 역시 뭔가를 배우고 있는것이고 통찰력을 기를수 있는 지점이라 생각되어 왜? 적용하기 어려운가를 조사하고 정리해보았습니다.
가령 MSA는 왜 적용하기 어려운가? 를 열심히 심층분석하다 보면~ 역설적으로 그것을 배워 나가지 않을까요? 안되서 포기해야할 이유를 찾는것이아니라 안되는 이유를 찾아 극복하다보면 우리만의 방식을 찾고 만들어내지 않을까?