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