Bounded Context — UL의 통치 범위 + AI session의 자연 경계

Eric Evans DDD의 또 하나 핵심 명제. Ubiquitous Language가 어디까지 통하는가의 답. 모델의 경계를 명시적으로 그어 vocabulary 충돌과 모델 일관성 붕괴를 차단. overview의 🌐 Domain 축 두 번째. AI 시대에는 context window 한계가 BC 경계를 강제해서, BC가 단순 design choice가 아니라 AI 시스템의 강제 조건.

한 줄

한 model·한 vocabulary가 일관되게 통하는 경계가 bounded context. 같은 단어("회원", "수업", "계좌")가 다른 context에서 다른 의미를 가질 수 있고, 그게 정상. 시스템 전체에 single universal model을 강요하려는 시도는 항상 실패한다. AI 시대에는 context window 자체가 BC를 강제하는 새 차원이 추가됨 — 한 AI session = 한 BC가 자연스러운 정합.

⚛️ 철학

원칙의 왜. 더 깊은 root와의 연결.

Evans DDD의 정의:

"A bounded context is a description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable."

— Eric Evans, Domain-Driven Design (2003)

ubiquitous-language|UL은 vocabulary가 통일된다고 약속하지만, 약속의 한계가 있음:

UL은 bounded context 안에서만 통일된다. 다른 BC에서는 같은 단어가 다른 의미를 가질 수 있고, 그게 정상이다.

학내 segment의 명료한 예시:

→ 단어가 다른 게 아니라 의미가 다름. 한 모델로 통합하려 하면:

• 모든 의미를 모두 표현하려는 bloated entity (회원 entity가 학사+학생회+도서관+동아리 속성 다 가짐)
• 어느 context에서도 완벽히 맞지 않는 모델
• 변경 시 다른 context까지 영향 (학생회 회원 정의 변경 → 도서관에 영향)

Single Universal Model 함정 (DDD anti-pattern)

DDD 진영이 가장 강하게 비판하는 모든 도메인을 한 모델로 표현하려는 시도. 결과:

→ 90년대 Enterprise Data Model 운동이 이 함정의 대표적 사례. 거의 모든 시도가 실패. 그래서 DDD가 bounded context로 해체를 답으로 제시.

다른 root와의 연결

• ubiquitous-language — UL의 통치 범위가 BC. UL과 BC는 짝
• information-hiding — BC 경계가 information hiding의 시스템 단위. 다른 BC에서 내부 모델을 볼 수 없음
• anti-corruption-layer — 두 BC 사이의 vocabulary 변환이 ACL의 직접 역할
• strategic-vs-tactical-programming — 어디서 BC를 끊을지가 가장 strategic한 결정 중 하나. 잘못 끊으면 시스템 전체 영향
• Conway's Law (Mel Conway, 1968) — 조직 구조가 시스템 구조에 박힘. BC가 조직 경계와 정렬되어야 자연스러움

🧱 추상적 작동 구조

두 BC의 vocabulary 분리:

핵심: 각 BC가 자기 model + 자기 UL. BC 사이는 명시적 변환 layer가 책임.

Context Map — BC 사이의 7가지 관계 패턴

Evans가 DDD에서 정의한 BC 사이의 관계 패턴 (Context Map):

→ BC 사이의 모든 관계는 명시적이어야. 이게 information-hiding|information hiding의 시스템 단위 표현.

⚠️ 약점/한계

원칙의 적용 한계. 잘못 적용 시 함정.

1. 경계 결정의 어려움

어디서 한 context를 끊고 다른 context를 시작할지 명확한 알고리즘이 없음. 도메인 expert와 깊은 대화로 발견. 시간·관계 비용 큼.

해결: Vocabulary 충돌 지점이 BC 경계 후보. 같은 단어가 의미가 다르기 시작하면 그 자리에 BC. 학습 도메인 + 운영 도메인이 같은 시스템에서 manage되면 BC 분리 신호.

2. 조직과 코드의 mismatch (Conway's Law 충돌)

"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." — Mel Conway

팀 경계와 BC 경계가 어긋나면 매 변경마다 팀 간 합의 비용. 팀 A가 자기 BC를 변경하려는데 팀 B의 BC도 영향이면 조정 비용 폭발.

해결: BC 경계를 조직 경계와 정렬. Inverse Conway Maneuver — 원하는 시스템 구조에 맞춰 조직을 재구성.

3. 너무 작은 BC → context 폭발

매 vocabulary 차이마다 BC 분리하면 수십 개 BC. 관리 비용 폭발. 통신 overhead 증가.

해결: BC는 cohesive한 모델 단위가 한 BC. 한 사람이 머릿속에 담을 수 있는 크기. 보통 1 BC ≈ 5-10 entities.

4. 너무 큰 BC → UL 의미 흐려짐

한 BC가 너무 크면 내부에서 vocabulary 충돌 시작. UL이 흔들림.

해결: BC 내부 충돌 발생 = 분리 신호. 변경에 따라 점진 분리.

5. 변화 시기 mismatch

BC 분리 시기를 잘못 판단:

• 너무 일찍 분리 → premature BC. 도메인 이해 부족 상태에서 분리. 잘못된 경계.
• 너무 늦게 분리 → big-ball-of-mud. 분리 비용 폭발.

해결: **모니카 가설 (Monica Heuristic)*: vocabulary 충돌이 3번 발생하면 그때 분리. Rule of three의 BC 단위 표현.

6. Cross-context 데이터 sync 비용

두 BC가 같은 entity를 다른 시각으로 보면 sync 비용:

• 학사 BC의 "학생" vs 도서관 BC의 "회원" — 둘 다 같은 사람
• 한쪽 변경 (졸업, 휴학) → 다른 쪽 sync 필요

해결: Event-driven sync + ACL. 두 BC가 직접 sync하지 않고 event를 발행. 다른 BC가 자기 모델로 reflect.

🔄 대안 흐름

이 원칙이 적용 안 되는 시나리오와 다른 답.

대안 1 — Monolithic single model

한 모델로 통합. 작은 시스템 / single team / 단순 도메인에 적합.

→ Single Universal Model 함정과 다름. 작은 시스템은 진짜로 한 BC. 비판받는 건 큰 시스템에서 한 모델 강요. 작은 시스템에는 BC 자체가 over-engineering.

대안 2 — Microservices = BC

서비스 경계가 BC 경계와 정렬. 가장 modern한 implementation.

→ 정렬되면 매우 강력. BC가 코드·배포·운영까지 분리됨. 단, microservices의 추가 비용 (네트워크, eventual consistency, 운영 복잡도) 발생.

대안 3 — Modular monolith

한 codebase 안에 BC만 분리. 코드 modularity는 BC, 배포는 monolith. microservices 비용 회피.

→ 학내 segment에 적합. 작은 팀 / 적은 사용자 / 운영 부담 회피. v1.0의 자연스러운 출발점.

대안 4 — Event-driven sync

두 BC 사이를 event로 통신. Direct call 대신 publish/subscribe. eventual consistency 허용.

→ BC 자율성 높임. 단, 학습 곡선 + 디버깅 어려움.

대안 5 — Shared database (anti-pattern이지만 실무 다수)

여러 BC가 같은 DB schema 공유. 빠른 sync, 그러나 BC 자율성 파괴. 변경 시 모든 BC 영향.

→ DDD 진영에서 강하게 비판. 그러나 실무 legacy 시스템 다수가 이 패턴. 현실적 절충 — 읽기 전용 view만 공유, 쓰기는 BC owner만.

💡 인사이트

AI 시대 왜 지금 부활하는가 + 학내 segment 의미.

1. Context window 한계가 BC 경계를 강제

AI agent의 context window는 제한 (Claude는 200K, GPT는 128K 등). 시스템 전체 vocabulary와 model을 한 session에 담을 수 없음. 이게 BC를 design choice가 아닌 강제 조건으로 만듦:

→ *AI 시대에 BC는 경제적 정합. 한 session = 한 BC = 한 UL = AI 정확도 최대.

2. AI session 자체가 자연스러운 BC

전통적으로 BC는 영구한 architectural 단위. AI 시대에 새 차원 추가:

1회성 AI session도 BC가 될 수 있음. 한 task에 필요한 vocabulary만 모아서 session.

sources/key-articles-summary#3. Anthropic — *Effective Harnesses for Long-Running Agents*|Anthropic harnesses 글의 feature list 한 번에 한 feature 패턴이 정확히 이 표현. 한 session = 한 작업 BC.

3. 학내 BC 분리 — 자연스러운 경계

학내 segment에서 명백한 BC 경계:

→ 각 BC가 자기 vocabulary skill + 자기 통합 모듈. v1.0이 학내 segment에 가져다 줄 분할 구조.

4. Conway's Law의 학내 segment 표현

Conway's law: 조직이 시스템 구조에 박힘. 학내에서는:

• 학사처 ↔ 학사 BC (자연스러움)
• 총학 ↔ 학생회 BC (자연스러움)
• 도서관 ↔ 도서관 BC (자연스러움)

→ 학내 조직 구조 자체가 BC를 자연스럽게 정의. 별 design 노력 없이 BC가 이미 존재. v1.0이 그 자연 구조에 정합.

5. v1.0 design 직접 적용

6. AI agent specialize — BC별 specialist

전통적으로 한 AI agent가 모든 도메인 처리. AI 시대 새 패턴:

BC별로 specialized AI agent. 학사 agent / 학생회 agent / 도서관 agent. 각자 자기 BC vocabulary와 model에만 집중.

장점:

• Context window 효율 (한 BC만)
• vocabulary 일관성 (UL 정착)
• specialization으로 정확도 ↑
• 학내 학생이 자기 BC agent만 쓰면 됨

→ 이게 v1.0 marketplace의 kernel value proposition. 학내 BC별 agent를 학내 사용자가 만들고 공유.

7. 조직 변화에 BC가 자연 적응

학내 조직은 학기마다 재선·개편 (총학생회 임기 1년). BC 단위로 분리되어 있으면:

• 새 총학 ↔ 학생회 BC만 영향. 학사 BC는 무관
• 학칙 개정 ↔ 학사 BC만 영향. 학생회 BC는 무관

→ 조직 변화 흡수 능력이 BC 분리에 직접 비례. 학내 segment의 높은 변화 빈도가 BC 분리의 가장 강한 정당화.

8. AI 시대 새 차원 — task-level BC

기존 BC: 영구 architectural 단위. AI 시대 추가: task-level transient BC.

예: 학생이 "이번 학기 시간표 짜기" task를 시작 → 임시 BC 생성:

• vocabulary: 시간표·과목·교수·강의실
• model: 시간 슬롯·충돌 검사·우선순위
• session 단위로 살아있다가 task 끝나면 사라짐

→ AI session = 1회용 BC가 새 design 단위. v1.0이 task-level BC를 도구화하면 학내 학생이 자기 일상의 작은 BC들을 만들고 활용.

다음에 가야 할 자리

이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:

• anti-corruption-layer — BC 사이의 vocabulary 변환. Domain 축 마무리. 가장 직접 후속
• orthogonality — BC 경계가 layer 독립성의 도메인 단위
• information-hiding — BC 경계가 시스템 단위 hiding

→ Domain 축 마무리에는 anti-corruption-layer가 가장 자연스러움.

관련

• overview
• ubiquitous-language — UL의 통치 범위가 BC. 짝
• information-hiding — BC 경계 = 시스템 단위 hiding
• anti-corruption-layer — BC 사이 변환 layer
• strategic-vs-tactical-programming — BC 경계 결정이 가장 strategic
• research/stateless-llm-sdk/design-principles|design-principles — 7 원칙의 segment fit과 직접 연결

Sources

직접 source

• Domain-Driven Design — Eric Evans (2003). Chapter 14 Maintaining Model Integrity (BC의 원전)
• Implementing Domain-Driven Design — Vaughn Vernon (2013). Chapter 2 Domains, Subdomains, and Bounded Contexts
• Learning Domain-Driven Design — Vlad Khononov (2021). 한국어판 《도메인 주도 설계 첫걸음》. BC 가장 접근 쉬운 설명

Context Map과 패턴

• Evans 책 Chapter 14 Context Maps — 7가지 관계 패턴 원전
• Khononov 책 — 더 modern한 표현

Conway's Law

• Conway, M. (1968). How Do Committees Invent?. Datamation. — 원전
• Inverse Conway Maneuver — Team Topologies (Skelton & Pais, 2019)

AI 시대 BC

• Anthropic — Effective Harnesses for Long-Running Agents — feature list / one-feature-at-a-time이 task-level BC

Microservices와 BC

• Building Microservices — Sam Newman (2nd ed). Microservices를 BC로 보는 시각
• Monolith to Microservices — Sam Newman. BC 분리 마이그레이션