Page History
...
| Widget Connector | ||
|---|---|---|
|
영상 분석내용
📌 도메인 주도 설계(DDD) 책의 1장과 2장을 읽고 저자가 느낀 현실과의 괴리감은 무엇인가?
...
릴리 링크 : https://lilys.ai/digest/4959253/4281642?s=1¬eVersionId=559252
호주 퍼스에서의 경험
7년전이였나? DDD를 전혀 모를때 외국 글로벌 기업(VGW)에서 일을 하면서 DDD라는 컨셉을 처음듣고 해당 방법론대로 스프린트를 돌리는곳에
참여를해 고생한 경험이 있습니다. DDD는 그냥할수있는것이 아니라.. 그것을 하기위해 역량을 집중하고 설계를 고민하는 활동이
기본적으로 전제돠어 있습니다. 책한권 읽었다고 갑자기 할수 있는것은 아닌것같으며 개발팀은 이것을 도입하기위한 준비와
학습과정에 돈을 아끼지 않은듯...
- ex> 도메인 전문가가 세계의 어딘가에 있다고하면 , 그 전문가의 이야기를 듣기위해 개발팀을 해외로 보내기도하고, 스프린트 활동도 글로벌하게 이동하면서 수행
국내 복귀후~ DDD가 우리(국내)에게는 안맞겠구나란 결정적으로 한 생각은 우리의 국내 문화가 해결책을 찾는 순서 자체가 완전히 다르다란 점이며
국내에서도 DDD를 일부 적용해 성공사례가 있을수 있겠지만 극히 소수인것같으며 , 보편적으로 문제를 찾고 인식하는 순서의 차이또는 문화적 습관으로 DDD도입이 어렵겠구나 라고생각하며
다음과 같은 이유들입니다.
국내에서 DDD가 도입하기 어려운 이유
✅ 문제 해결 접근 방식의 차이: 한국 vs 해외
| 구분 | 국내(한국 중심) | 해외(서구 중심: 미국, 유럽 등) |
|---|---|---|
| 출발점 | 해결책(솔루션)을 먼저 상상하고 시작 | 문제 정의부터 신중히 시작 |
| 사고방식 | "답을 빨리 내야 한다" → 속도 중심 | "문제가 맞는가?" → 정확성 중심 |
| 문제 정의 | 사후적으로 맞춰가는 경향 | 문제를 먼저 좁고 명확하게 정의 |
| 회의 패턴 | 결과지향적 브레인스토밍 (해결방안에 집중) | 원인 규명 중심 토론 (문제 원인과 가정 검증) |
| 보고 방식 | "어떻게 해결했는가"를 강조 | "무엇이 문제이고 왜 그것이 중요한가"를 강조 |
| 실패 인식 | 실패 = 책임 문제 → 회피 경향 | 실패 = 학습 기회 → 빠른 실험 장려 |
| 결정 방식 | 위에서 정한 방향에 맞는 문제를 나중에 맞춤 | 아래에서 문제 발견 후 위로 이슈 제기 |
| 대표적 표현 | “그거 해결됐어?” | “그게 진짜 문제야?” |
- 국내 기획전문가라고 불리는 영역이 대부분 목업이란것을 먼저 그리고 , 비즈니스 문제를 찾기 시작합니다.
- 외국에서 우리나라의 기획자란 영어명칭의 단어는 존재하지 않으며~ BA라는 단어를 사용하며 기획자와 가깝습니다. 참고로 해외 애자일/DDD문화에서 BA가 목업부터 그리기 시작하면 프로덕트 메니저에게 혼나는 상황이 연출됩니다.
- 국내에서는 목업을 기가 막히게 그려 제출하면~ 사장님또는 사업가로부터 칭찬받습니다. - 이 결정적 차이는 해외에 나가서 기획업무를 해보지 않으면 알기 힘든지점입니다.
...
🔍 이 차이가 조직/프로젝트에 미치는 영향
| 항목 | 국내식 접근의 장점 | 단점 | 해외식 접근의 장점 | 단점 |
|---|---|---|---|---|
| 속도 | 빠른 실행, 임시 해결 가능 | 근본 원인 방치, 반복 발생 | 문제 재발 방지 가능 | 초기 속도 느림 |
| 조직문화 | 상명하달, 위계질서 존중 | 비판·이견 표현 어려움 | 수평적 의견 수렴 가능 | 결론 도출 오래 걸림 |
| 창의성/혁신 | 정해진 틀 안에서 효율성 추구 | 창의적 시도 부족 | 다양한 관점의 문제 탐색 가능 | 통일된 방향성 부족 우려 |
| 학습/피드백 | 결과만 보는 평가 방식 | 실패 분석 부족 | 실패도 공유하며 성장 | 실험 과잉일 경우 리스크 존재 |
...
💡 정리된 인식과 시사점
한국 조직은 “문제 해결”보다 “해결을 보이는 것”에 더 집중하는 경향이 있음. 이는 위기 대응 능력은 뛰어나지만 지속 가능한 개선에는 약점을 가질 수 있음.
해외에서는 “문제 정의 능력”이 곧 전문성으로 여겨짐. 문제를 잘 정의하면 절반은 푼 것이란 인식이 강함.
최근 한국 내에서도 “문제 정의의 중요성”, “가설 기반 접근”, “리트로스펙티브 문화” 등이 스타트업과 IT기업을 중심으로 점점 확산되고 있음.
✅ 왜 DDD는 "문제 정의 우선" 방식과 잘 맞는가?
| 구분 | 설명 |
|---|---|
| 1. 도메인 중심 사고 | DDD는 비즈니스 도메인의 문제와 복잡성 자체에 집중함. 기술은 그 문제를 해결하기 위한 도구일 뿐. |
| 2. 유비쿼터스 언어 (공통 언어) | 해결책을 먼저 정해놓고 진행하면 언어가 뒤따르기 쉽지만, DDD는 도메인 전문가와 개발자가 문제에 대한 공감대부터 만들어가는 것이 핵심. |
| 3. 지속적 탐색 (Exploration) | DDD는 끊임없이 문제를 탐색하고 모델을 수정해나가는 진화적 접근을 취함. 초기 해결책이 항상 옳지 않다는 전제를 깔고 있음. |
| 4. 복잡성 관리 | 표면적 문제가 아닌 **핵심 복잡성(Core Complexity)**을 파악하고 그것을 중심에 둔 구조 설계를 추구함. 이는 빠른 해결보단 올바른 문제 정의가 선행되어야 가능한 구조. |
...
✅ DDD와 한국식 접근의 충돌 지점
| 한국식 (해결책 우선) | DDD 철학과 충돌하는 부분 |
|---|---|
| 빠르게 UI/기능 정의 → 개발 | 도메인 지식 없이 구조를 먼저 고정하면, 모델이 잘못되기 쉬움 |
| 개발 전에 해결책(PPT)부터 그리기 | 정작 중요한 문제는 해결되지 않고 겉모습만 구현될 가능성 |
| 도메인 전문가가 아니라 기획자가 요구사항을 주도 | 유비쿼터스 언어의 부재 → 커뮤니케이션 오류 발생 |
| 빠른 피처 구현과 릴리즈 우선 | 모델의 일관성과 의미 유지에 실패 |
...
✅ 결론
DDD는 "문제를 먼저 정의하고, 도메인을 깊이 이해한 뒤 해결책을 도출하는 방식"에 최적화되어 있습니다.
따라서 해외(특히 유럽, 미국 등지)의 분석 중심, 가설 기반, 실험적 접근 방식과 가장 잘 어울립니다.
반면, 해결책을 먼저 상정하고 역으로 문제를 맞춰가는 조직 문화에서는 DDD가 형식적으로만 적용되고 실제 효과는 떨어질 수 있습니다.
...