도메인(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가 필요하다. MSA에도 도움이된다"

  • DDD가 애자일또는 MSA를 위해 제공되는 기술자체가 아니며, 도메인을 중심에 놓고 설계하는 패러다임의 전환으로 모놀리식,SOA등에도 도움이 될수 있습니다. 

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

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

현재의 문제점

"작업 보드 셔플" 함정

할일 → 작업중 → 완료

포스트잇을 옮기기만하면  애자일인것처럼 보이던 초창기 애자일이 하던 실수, DDD를 도입하면서 지식획득과정을 포함시켜 성숙한 애자일이 되거나 여전히 포함하지 않고 작동하는 애자일이 존재할수있음

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

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

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

즉각적 방식의 함정

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시대, 어떤 미래가 기다릴까? (세 가지 시나리오)

LLM 발전에는 여러 미래가 예상되지만, 크게 세 가지 시나리오를 생각해 볼 수 있어요 .

• 첫 번째는 '종말 시나리오'예요 .

  • AI가 우리를 죽이거나 배터리로 사용하거나 , 토스터 생산량만 최적화하려다 세상을 토스터 공장으로 만들 수도 있죠 .

  • 이 시나리오에서는 우리가 LLM을 공부하든 안 하든 결과는 똑같을 거라고 해요 .

• 두 번째는 '정체 시나리오'입니다 .

  • LLM이 지금보다 크게 발전하지 않고 시들해지는 경우인데 , 저는 지금 도구로도 놀라운 일을 할 수 있다고 생각해요 .

  • 이 시나리오라면 지금 공부하지 않아도 괜찮고, 나중에 "내가 그럴 줄 알았지!"라고 말할 기회가 올 거예요 .

  • 그래도 저는 이 시나리오를 준비하고 있지는 않답니다 .

• 세 번째는 제가 가장 가능성 높다고 생각하는 '소프트웨어 혁명 시나리오'예요 .

  • 소프트웨어 개발이 완전히 바뀌지만, 인간 개발자는 여전히 필요하다는 거죠 .

  • 이 시나리오에서는 지금 LLM을 공부하는 것이 정말 중요해요 .

  • 미래에 더 쉽게 배울 수도 있겠지만 , 일찍 시작하는 것이 유리하답니다 .

LLM을 잘 쓰려면 '프롬프트 엔지니어링'이라는 것을 배워야 해요 . 이건 LLM에게 우리가 원하는 결과를 얻도록 명령을 잘 내리는 방법 같은 거죠 .

마치 요리사에게 재료와 레시피를 정확히 알려줘야 맛있는 음식이 나오는 것처럼요.

• 저는 게임 캐릭터 대화에 LLM을 써보는 실험을 했어요 .

• 단순히 "너는 해적이야"라고 시키는 건 잘 안 됐죠 .

  • 제가 해적에게 AI 스타트업 아이디어를 제안했더니, 해적은 돈이 될 것 같다며 관심을 보였지만 , 진짜 해적 같은 반응은 아니었어요 .

  • 시간 여행자가 보물을 훔치려 할 때 "요즘 세상에 그런 짓을 하다니!"라고 말하는 해적은 없겠죠 ?

• 그래서 명령을 여러 개로 나누어 쓰는 방법을 시도했어요 .

  • 하나는 '이 대화가 해적 시대 배경에 맞나?' 확인하고 .

  • 다른 하나는 '해적의 대사를 만들어줘'라고 시키는 거죠 .

  • 이렇게 하니 LLM이 제가 원하는 배경에 맞는지 더 잘 판단하더라고요 .

• 이것은 마치 오래된 디자인 원칙인 '관심사의 분리'와 같아요 .

• 하나의 복잡한 명령 대신, 명확한 여러 단계를 거치게 하는 것이 LLM을 더 신뢰성 있게 만드는 방법이 될 수 있답니다 .

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

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

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

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