도메인(Domain)의 정의와 철학

1. 도메인의 정확한 정의

문서에 따르면 도메인은 다음과 같이 정의됩니다:

도메인 : 지식이나 영향력, 또는 활동의 영역. 컴퓨터와 거의 관련이 없다.

이 정의에서 핵심은 **"컴퓨터와 거의 관련이 없다"**는 부분입니다. 도메인은 기술이 아닌 비즈니스의 본질적 문제 영역을 의미합니다.

더 구체적으로:

• 핵심도메인(Core Domain): 사용자의 목적에 중심적인 역할을 수행해서, 애플리케이션을 차별화하고 가치 있게 만드는 모델의 특징적인 부분

• 도메인 전문가: 개발이 아닌 해당 비즈니스 영역에서 깊이 있는 지식을 갖춘 사람

2. 왜 우리는 도메인을 기술로 오해하는가?

2.1 기술 중심 사고의 함정

문서에서 지적하는 핵심 문제는 다음과 같습니다:

소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라 우리가 가진 도메인 자체의 복잡성에 기인한다.

우리가 흔히 저지르는 실수들:

1. 기술적 해결책 우선주의

   • 프레임워크, 아키텍처, 기술 스택에만 집중

   • "어떻게(HOW) 코딩할 것인가"에만 매몰

2. "작업 보드 셔플" 현상

   • 할일 → 작업중 → 완료의 단순한 이동만을 개발로 착각

   • 지식 집약적 일의 전부를 "프로그래머가 소스만 쏟아내는 것"으로 축소

3. 설계 없는 개발

   설계가 없는것은 지식획득이라는 중요한 것을 놓치고, 큰 진흙 덩어리를 계속 만들어 내게 된다.

2.2 큰 진흙 덩어리의 문제

문서에서 설명하는 "큰 진흙 덩어리"는:

• 여러 비즈니스 모델이 하나의 서비스에 뭉쳐 작동되는 시스템

• 비즈니스 모델의 특성과 작동방식을 구분하는 경계가 존재하지 않는 상태

• 두더지 게임 현상: 한 곳을 고치면 예측하지 못한 다른 곳에서 문제 발생

3. 도메인 중심 사고로의 전환

3.1 패러다임 전환의 필요성

에릭 에반스(Eric Evans)가 2003년 DDD를 제시한 배경:

기술보다 비즈니스의 복잡성을 중심에 놓고, 소프트웨어 설계와 도메인 모델을 비즈니스 전문가와 함께 만들어가는 방법론

핵심 변화:

• 과거: ERD → 스키마 중심의 개발

• 현재: 도메인 전문가(기획자)와 개발자가 함께 모델링

• 목표: 코드 자체가 업무 모델을 반영

3.2 도메인의 진정한 의미

DDD에서 강조하는 핵심 질문:

도메인에 대한 깊은 지식 없이 복잡한 은행 소프트웨어를 만드는것이 가능할까?

누가 은행업무를 아는가? 소프트웨어 아키텍트? 아니다. 그는 단지 자기 돈을 안전하게 보관하다가 필요할 때 인출하려고 은행을 이용할뿐이다.

그럼 누구일까? 바로 은행가이다. 은행업무 체계는 거기에 속해 있는 해당 분야의 전문가들이 가장 잘 이해하고 있다.

4. 50인 미만 중소개발사를 위한 도메인 접근법

4.1 우리의 현실적 문제들

문서에서 지적하는 우리의 문제점들:

• 개발자는 개발이 시작되기전 기획문서의 완벽함을 원한다

• 기획자는 UX만으로 개발자가 모든설계를 하기를 원한다

• PRD는 애매모호하며 수시로 변한다

• 요구사항 분석문서는 빈약하다

4.2 실용적 해결 방안

1. 유비쿼터스 언어(Ubiquitous Language) 구축

• 개발자와 비즈니스 전문가가 공통으로 사용하는 언어

• 코드와 설계 문서, 회의 용어가 일치해야 함

1. 커피 한 잔의 철학

도메인 전문가로부터 지식을 얻기위해서는 커피한잔이면 충분하다. 커피한잔으로 가능한 일이면, 복잡한 툴은 필요없다.

1. 점진적 도메인 발견

• 완벽한 도메인 이해를 기다리지 말고 시작

• 작은 실험과 빠른 피드백을 통한 학습

5. AI Agentic 시대에서의 도메인 중심 개발

5.1 새로운 협업 방식

AI 에이전트가 등장한 상황에서도 도메인 이해는 여전히 핵심입니다:

• AI는 도구: 코드 생성, 테스트 자동화 등을 담당

• 인간은 도메인 전문가: 비즈니스 로직, 문제 정의, 가치 판단을 담당

• 협업의 새로운 형태: AI가 기술적 복잡성을 처리하는 동안, 인간은 도메인 복잡성에 집중

5.2 SaaS B2B 환경에서의 도메인 중요성

고객의 도메인 이해가 곧 경쟁력:

• 고객이 해결하고자 하는 비즈니스 문제를 깊이 이해

• 기술이 아닌 고객의 업무 방식과 가치 사슬을 모델링

• 고객의 언어로 소프트웨어를 설계

6. 결론: 도메인이 먼저, 기술은 수단

문서에서 강조하는 핵심 철학:

우리가 출발해야하는 곳은 언제나 도메인이다.

도메인 중심 개발의 본질:

1. 문제 정의가 해결책보다 중요

2. 비즈니스 전문가와의 지속적 대화

3. 코드가 비즈니스를 반영하는 설계

4. 기술은 도메인을 표현하는 수단일 뿐

AI가 기술적 복잡성을 대신 처리해주는 시대에서, 우리는 오히려 도메인에 더 집중할 수 있는 기회를 얻었습니다. 기술이 아닌 우리가 해결하고자 하는 진짜 문제가 무엇인지를 깊이 이해하는 것이 AI 시대의 핵심 경쟁력이 될 것입니다.

AI Agentic 시대의 점진적 개발방법론

중소개발사(50인 미만) B2B SaaS를 위한 실용적 접근법

현재 상황 진단

우리의 현실

• CRUD 중심의 모놀리식 개발

• SOA/클린아키텍처 경험 부족

• MSA로의 성급한 도약 시도

• 빈약한 도메인 모델링

• 기획-개발 간 소통 단절

목표

• 앞선 기업들의 MSA/CQRS 수준 달성

• AI를 활용한 개발 효율성 극대화

• 지속 가능한 성장 기반 마련

3단계 점진적 발전 로드맵

1단계: 기초 체력 다지기 (3-6개월)

"좋은 설계의 다음 대안은 나쁜 설계다" - 설계 없는 것보다 나쁜 설계가 낫다

1.1 워터폴의 장점 + 애자일의 유연성 결합

• Shape Up 방식 도입: 6주 사이클 + 2주 쿨다운

• 고정된 시간, 변동 가능한 범위 원칙 적용

• 백로그 대신 베팅 프로세스로 우선순위 결정

1.2 도메인 중심 사고 전환

• Event Storming 도입으로 도메인 이벤트 발견

• 유비쿼터스 언어 구축

• 기획자-개발자-도메인전문가 협업 체계 구축

1.3 AI Agentic 도구 활용 시작

• AI 페어 프로그래밍: Claude, GitHub Copilot 활용

• 문서 자동화: PRD, API 문서 AI 생성

• 코드 리뷰 보조: AI 기반 품질 검증

2단계: 아키텍처 성숙화 (6-12개월)

"소프트웨어 복잡성은 기술이 아닌 도메인의 복잡성에서 기인한다"

2.1 SOA 패턴 학습과 적용

• 서비스 경계 식별: DDD의 Bounded Context 활용

• 공유 vs 독립성 균형점 찾기

• 레이어드 아키텍처 점진적 도입

2.2 클린 아키텍처 기반 구조 개선

• 도메인 계층 분리

• 의존성 역전 원칙 적용

• 테스트 가능한 설계 구축

2.3 AI 협업 고도화

• AI 아키텍트 역할: 설계 검토 및 제안

• 자동화된 테스트 생성: AI 기반 테스트 케이스 작성

• 리팩토링 가이드: AI 기반 코드 개선 제안

3단계: MSA 전환과 CQRS 도입 (12-18개월)

"팀의 구조가 시스템 아키텍처를 결정한다" - 콘웨이 법칙

3.1 점진적 MSA 전환

• Strangler Fig 패턴으로 기존 모놀리스 분해

• 도메인별 팀 구성 (역 콘웨이 법칙 활용)

• API Gateway + 서비스 메시 도입

3.2 CQRS와 이벤트 소싱 도입

• 읽기/쓰기 분리로 성능 최적화

• 도메인 이벤트 기반 서비스 간 통신

• 이벤트 스토어 구축

3.3 AI 인프라 통합

• AI 기반 모니터링: 자동 이상 탐지

• 자율적 배포: AI 기반 CI/CD 최적화

• 비즈니스 인텔리전스: AI 기반 의사결정 지원

AI Agentic 시대를 위한 개발방법론: 기술중심에서 도메인중심으로의 패러다임 변화

1. 기술중심에서 도메인중심으로의 패러다임 전환 핵심사건

1950년-1980년대: 기술중심 시대의 확립

• 워터폴 모델의 성공: 항공우주, 방위산업, 대기업 ERP에서 "시원한 절차"를 통한 체계적 개발

• 데밍의 품질이론(1950년): 제조업에서 시작된 품질 중심 사고가 소프트웨어로 확산

• 특징: 기술적 복잡성 해결, 대규모 시스템 관리, 예측 가능성 중시

1990년-2000년대: 한계 인식과 전환점

• 고약한 문제(Wicked Problem) 개념 등장: "문제가 완전히 풀려야 비로소 그 문제가 무엇인지 완전히 이해되는 문제"

• 기술중심 접근의 한계: 프레임워크와 UML에 매몰된 개발 방식의 문제점 부각

2003년: 도메인주도 설계(DDD)의 혁명적 등장

• 에릭 에반스의 선언: "소프트웨어가 복잡해지는 이유는 기술 자체가 아니라 도메인의 복잡성에 기인"

• 핵심 개념:

  • 유비쿼터스 언어 (개발자-도메인전문가 공통 언어)

  • 바운디드 컨텍스트 (도메인 경계 설정)

  • 도메인 전문가 참여 필수화

2. 애자일의 탄생과 발전 과정

1990년대: 애자일 인식의 뿌리

• 워터폴의 구조적 한계: 변화에 대한 대응 부족, 의사소통 단절

• 고약한 문제 인식: 불확실성이 크고 변화가 잦은 소프트웨어 특성 이해

2001년: 애자일 선언문

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기

2000년-2010년대: 애자일 방법론의 확산

• 스크럼, 칸반, XP 등 다양한 실천법 등장

• 스포티파이 모델: 스쿼드-트라이브-챕터-길드 구조로 확장성과 자율성 균형

2010년대 후반: 새로운 접근법 등장

• Shape Up: 37signals의 "6주 사이클 + 2주 쿨다운", 백로그 미사용

• 기존 애자일의 한계: "애지일이 스피드가 아니라 올바른 방향 찾기"라는 재인식

3. 두 패러다임의 상호 영향

공통 철학

• 불확실성과 복잡성에 대한 대응

• 지속적 학습과 적응 중시

• 협업과 소통 강화

상호 보완적 발전

• DDD + 애자일: "DDD를 하기 위해서는 애자일이 필요하다"

• 도메인 중심 + 변화 대응: 기술적 해결책이 아닌 비즈니스 가치 중심 접근

4. 도메인지식을 소중히 여기지 않는 즉각적 방식의 문제

현재의 문제점

"작업 보드 셔플" 함정

할일 → 작업중 → 완료

• 지식 획득 무시: 설계 활동 없이 구현만 반복

• 큰 진흙 덩어리: 도메인 경계 없는 모놀리식 사고

• 두더지 게임: 한 곳을 고치면 예측 못한 다른 곳에서 문제 발생

즉각적 방식의 함정

1. PRD의 애매모호함: "UX만으로 개발자가 모든 설계를 하기를 원함"

2. 구현 단계 때려박기: "아직 무엇을 해야할지 정하지도 않았는데 스프린트 시작"

3. 바보같은 질문 회피: 실제로는 도메인 정수를 찾는 과정인데 무시

왜 도메인지식을 소중히 여기지 않는가?

비즈니스 압박

• 원가 중심 문화: "설계는 비용, 구현은 결과"라는 잘못된 인식

• 예측 가능성 강요: "완벽한 기획 후 개발 착수"라는 워터폴 관성

기술자의 함정

• 기술력 과신: "정교한 프레임워크로 도메인 문제 해결 가능"하다는 착각

• 정량적 문제 선호: 도메인의 정성적 복잡성보다 기술적 도전 선호

5. AI Agentic 시대를 위한 변화 방향

핵심 인식 전환

1. AI는 도구가 아닌 협력자

기존: 인간 → AI 도구 사용 새로운: 인간 ↔ AI 에이전트 협업

2. 도메인 발견의 가속화

• 이벤트 스토밍: 도메인 전문가 + 개발자 + AI 에이전트

• 유비쿼터스 언어: AI가 이해할 수 있는 도메인 언어 체계

• 지속적 모델링: AI와 함께하는 실시간 도메인 모델 진화

50인 미만 중소 개발사를 위한 실천 방안

Shape Up + DDD 하이브리드 모델

6주 사이클: Week 1-2: 도메인 발견 (이벤트스토밍 + AI 분석) Week 3-5: 구현 (AI 페어 프로그래밍) Week 6: 통합 및 검증 쿨다운 2주: 회고 및 다음 Shape 준비

B2B SaaS 특화 접근

1. 고객 도메인 이해: B2B 고객의 업무 프로세스를 AI와 함께 분석

2. 컨텍스트 매핑: 고객사별 바운디드 컨텍스트 식별

3. API 중심 설계: 도메인 경계를 API로 명확히 구분

구체적 실천 방법

1. 도메인 지식 축적 시스템

• AI 지식 베이스: 프로젝트 도메인 지식을 AI가 학습하고 활용

• 고객 인터뷰: AI가 패턴 분석하여 숨겨진 요구사항 발견

• 지속적 리팩토링: AI와 함께하는 도메인 모델 개선

2. 협업 문화 변화

"좋은 설계의 다음 대안은 나쁜 설계다" → 설계 활동 자체가 지식 획득의 핵심 → AI와 함께 빠른 설계-검증 사이클 구축

3. 측정과 개선

• 도메인 이해도 측정: 팀원들의 도메인 지식 수준 정기 점검

• AI 협업 효율성: 인간-AI 협업으로 얻은 생산성 향상 측정

• 고객 만족도: 도메인 중심 개발이 실제 비즈니스 가치로 연결되는지 검증

결론: "만드는 과정에서 우리가 우리의 방식을 사랑해야"

AI Agentic 시대의 개발방법론은 기술 중심에서 도메인 중심으로, 도구 사용에서 AI 협력으로의 이중 패러다임 전환을 요구합니다.

50인 미만의 중소 개발사에서는 거대한 프로세스보다는 도메인 지식을 AI와 함께 지속적으로 발견하고 축적하는 문화가 핵심입니다. 이를 통해 "우리가 싫어하는 프로덕트를 고객이 좋아할까?"라는 근본적 질문에 답할 수 있을 것입니다.

생성문서중 딴건 지루한 이야기고.... AI가 만든 다음 문구는 마음에 듬

"만드는 과정에서 우리가 우리의 방식을 사랑해야..." AI Agentic 시대의 개발방법론은 기술 중심에서 도메인 중심으로, 도구 사용에서 AI 협력으로의 이중 패러다임 전환을 요구합니다.

다음은 DDD를 이해하기위한 국내 자료와~ AI시대 DDD는 어떻게 변화할것인가? 추가참고 자료입니다.

• DDD 그거 그렇게하는거 아닌데 - 우아한형제들

• DDD를 AI에 이용해 설계(Design) 가속화하기

• DDD와 LLM - 에릭에반스 - DDD의 창시자