149. 바운디드 컨텍스트 (Bounded Context)

핵심 인사이트 (3줄 요약)

본질: 바운디드 컨텍스트 (Bounded Context)란 DDD (Domain-Driven Design)에서 특정 도메인 모델이 유효한 논리적 경계로, 동일 단어도 경계 안에서 서로 다른 의미를 가질 수 있다.

가치: 각 바운디드 컨텍스트는 MSA (Microservices Architecture)에서 독립 배포 가능한 서비스 후보로 직결되어, 팀 경계·데이터 경계·코드 경계를 일치시킨다.

판단 포인트: 서비스 경계를 자를 때 비즈니스 언어(유비쿼터스 언어) 충돌 지점을 찾아 컨텍스트 맵을 그리면 과분리·과통합 없이 최적 경계를 도출할 수 있다.

Ⅰ. 개요 및 필요성

대규모 소프트웨어 시스템에서는 "고객(Customer)"이라는 단어 하나가 영업 팀에서는 잠재 리드를 뜻하고, 배송 팀에서는 수취인을, 청구 팀에서는 납부 주체를 의미한다. 이처럼 같은 용어가 맥락에 따라 다른 개념을 가리킬 때 하나의 통합 모델로 모든 의미를 담으려 하면 클래스는 비대해지고 결합도는 폭발적으로 늘어난다.

DDD (Domain-Driven Design)의 바운디드 컨텍스트 (Bounded Context)는 이 문제를 "모델이 유효한 경계를 명시적으로 선언"함으로써 해결한다. 경계 안에서는 유비쿼터스 언어 (Ubiquitous Language)가 일관되게 유지되며, 경계 바깥과는 컨텍스트 맵 (Context Map)으로 관계를 맺는다.

MSA (Microservices Architecture) 설계 시 바운디드 컨텍스트는 서비스 분리의 핵심 기준이 된다. 각 컨텍스트는 자체 데이터 스토어를 소유하고, 다른 컨텍스트와 API 또는 이벤트로만 통신한다. 이를 통해 팀 자율성(Conway's Law)과 기술 이종성(Polyglot)을 동시에 달성한다.

📢 섹션 요약 비유: 바운디드 컨텍스트는 외국어 사전과 같다 — "bank"가 영영 사전에서는 금융기관이지만, 지형 사전에서는 강둑이듯, 경계를 먼저 정해야 뜻이 명확해진다.

Ⅱ. 아키텍처 및 핵심 원리

항목	내용	특징
경계 정의	유비쿼터스 언어가 일관된 범위	도메인 전문가·개발자 공유 언어
데이터 소유권	컨텍스트별 독립 DB	데이터 결합 최소화
컨텍스트 맵	경계 간 관계 명시	ACL, Shared Kernel, Upstream/Downstream
서비스 후보	1 컨텍스트 ≈ 1 마이크로서비스	팀·배포·스케일 단위 일치
통신 방식	API(동기) 또는 이벤트(비동기)	느슨한 결합 유지

┌─────────────────────────────────────────────────────────────────┐
│                     전체 도메인 (E-Commerce)                    │
│                                                                 │
│  ┌──────────────────┐   ACL   ┌──────────────────────────┐     │
│  │  주문 컨텍스트    │◄──────►│    결제 컨텍스트          │     │
│  │  (Order BC)      │         │    (Payment BC)           │     │
│  │  ─ Order         │         │  ─ Invoice                │     │
│  │  ─ OrderItem     │         │  ─ PaymentMethod          │     │
│  │  [주문 DB]       │         │  [결제 DB]                │     │
│  └──────────────────┘         └──────────────────────────┘     │
│          │ Domain Event                    ▲                   │
│          │ (OrderPlaced)                   │ API               │
│          ▼                                 │                   │
│  ┌──────────────────┐         ┌──────────────────────────┐     │
│  │  재고 컨텍스트    │         │    배송 컨텍스트          │     │
│  │  (Inventory BC)  │         │    (Shipping BC)          │     │
│  │  ─ StockItem     │         │  ─ Shipment               │     │
│  │  ─ Warehouse     │         │  ─ Recipient              │     │
│  │  [재고 DB]       │         │  [배송 DB]                │     │
│  └──────────────────┘         └──────────────────────────┘     │
└─────────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 각 컨텍스트는 독립된 왕국 — 왕국마다 화폐 단위가 달라도 국경의 환전소(ACL, Anti-Corruption Layer)를 통해 교역이 가능하다.

Ⅲ. 비교 및 연결

구분	바운디드 컨텍스트 (Bounded Context)	하위 도메인 (Subdomain)
관점	솔루션 공간 (구현 경계)	문제 공간 (비즈니스 영역)
개수	설계 선택에 따라 변동	비즈니스 구조에 의해 결정
1:1 관계	권장하나 필수 아님	1개 하위 도메인 → 여러 BC 가능
핵심 도구	컨텍스트 맵, ACL	코어/서브/지원 도메인 분류

컨텍스트 맵 패턴 종류:

Shared Kernel: 두 컨텍스트가 작은 모델 일부를 공유, 변경 시 협의 필수.
Customer/Supplier: 업스트림이 다운스트림 요구를 충족해야 함.
ACL (Anti-Corruption Layer): 외부 모델을 내부 모델로 변환하는 번역 계층.
Open Host Service: 퍼블릭 API 형태로 서비스를 노출.

📢 섹션 요약 비유: 하위 도메인이 지도 위의 지형이라면, 바운디드 컨텍스트는 그 위에 그린 행정구역 선 — 지형은 고정이지만 경계선은 필요에 따라 조정된다.

Ⅳ. 실무 적용 및 기술사 판단

서비스 경계 도출 체크리스트

도메인 전문가와 이벤트 스토밍 (Event Storming) 세션을 통해 도메인 이벤트 목록 작성.
같은 명사가 다른 의미로 쓰이는 충돌 지점 → 컨텍스트 경계 후보.
각 컨텍스트의 변경 빈도·팀 소유권·독립 배포 요구 사항 검토.
컨텍스트 맵 작성 후 순환 의존 여부 점검 → 순환 발생 시 경계 재조정.
단일 DB 공유 여부 점검 → 공유 시 경계 실질적으로 무의미.

기술사 시험 포인트

바운디드 컨텍스트와 마이크로서비스 1:1 대응 원칙을 설명하고, 예외(대형 BC를 여러 서비스로 분리)도 언급할 것.
ACL 패턴을 레거시 시스템 연동 시나리오에서 적용하는 방법을 서술하면 가점.

📢 섹션 요약 비유: 경계 설계는 도시 계획 — 처음에 도로망(경계)을 잘 깔아야 나중에 건물(서비스)을 자유롭게 신축·재건축할 수 있다.

Ⅴ. 기대효과 및 결론

바운디드 컨텍스트를 기반으로 MSA를 설계하면 팀 자율성, 독립 배포, 데이터 소유권 명확화라는 세 가지 이점을 동시에 얻는다. 비즈니스 언어와 코드 구조가 일치하므로 신규 팀원의 온보딩 속도가 빨라지고, 도메인 변경이 특정 서비스에 국소화된다.

한계점으로는 초기 설계 비용이 크고, 잘못된 경계 설정 시 네트워크 홉 (hop) 증가·분산 트랜잭션 복잡도 상승 등의 역효과가 발생한다. 따라서 작은 모놀리스로 시작해 Strangler Fig 패턴으로 점진적으로 분리하는 것이 리스크를 줄이는 실용적 접근이다.

📢 섹션 요약 비유: 바운디드 컨텍스트는 집의 방 구조 — 방을 잘 나눠야 각자 편히 살 수 있지만, 벽을 너무 많이 세우면 이사하기도 불편하다.

📌 관련 개념 맵

개념	연결 포인트
유비쿼터스 언어 (Ubiquitous Language)	BC 내부에서 일관된 용어 사용
컨텍스트 맵 (Context Map)	BC 간 관계·통신 패턴 명시
이벤트 스토밍 (Event Storming)	BC 경계 발견 워크숍 기법
MSA (Microservices Architecture)	BC 1개 = 서비스 후보
ACL (Anti-Corruption Layer)	외부 BC 모델 오염 방지 번역 계층
Strangler Fig 패턴	모놀리스를 BC 단위로 점진적 분리

👶 어린이를 위한 3줄 비유 설명

학교에서 "선생님"은 담임 선생님이지만, 병원에서 "선생님"은 의사 선생님이에요 — 같은 말이라도 장소에 따라 뜻이 달라요.

📈 관련 키워드 및 발전 흐름도

모놀리식: 모든 도메인 용어 혼재
    │
    ▼
Bounded Context: 도메인별 독립 모델 경계
    ├─► Context Map: 관계 정의 (Upstream/Downstream)
    └─► Anti-Corruption Layer: 번역 계층
    │
    ▼
MSA 서비스 분할 기준 → API 계약

바운디드 컨텍스트는 그 '장소의 울타리'예요 — 울타리 안에서는 모두 같은 언어로 이야기해요.
울타리를 잘 치면, 학교와 병원이 서로 독립적으로 운영되면서도 필요할 때 연락해서 협력할 수 있어요.