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