소프트웨어 설계에서 가장 어려운 일 중 하나는 문제 공간을 효과적으로 나누는 것이다.
하나의 문제에도 다양한 관점이 존재하며, 이 관점의 차이가 바로 컨텍스트의 경계를 만든다.

이 포스트에서는 DDD 관점에서 전문 지식의 경계를 어떻게 설정할 것인지, 그리고 핵심과 지원, 일반 컨텍스트를 어떻게 구분해야 할지에 대해 알아본다.

컨텍스트는 특정한 의미 체계와 비즈니스 규칙이 일관되게 적용되는 지식의 영역이다.
이 영역은 보통 하나의 팀이 책임지고 있으며, 내부적으로 통일된 언어와 규칙을 유지한다.

• 관점의 차이가 곧 경계의 신호다
  • 하나의 문제 공간에 여러 관점이 존재하는 이유는, 그 안에 다양한 비즈니스 목표, 역할, 용어 사용 방식이 혼재하기 때문이다.
  • 이 관점 간의 충돌이 발생하는 지점을 경계삼아 바운디드 컨텍스트를 정의할 수 있다.
  • 예) ‘고객’ 이라는 단어가 영업팀에서는 ‘잠재 구매자’를 의미하지만, 회계팀에서는 ‘거래 완료자’를 의미한다면 이 둘은 서로 다른 컨텍스트를 가짐
• 컨텍스트는 팀과 프로젝트의 경계를 따라 형성된다
  • 전문 지식의 컨텍스트 분할은 보통 아래와 같이 결정된다.
    • 담당 팀의 역할과 책임
    • 프로젝트의 범위
    • 업무의 목적과 비즈니스 규칙
  • 이 때 외부의 의미나 규칙이 침투하여 경계를 흐리지 않도록 하는 것이 중요한데, 이를 부패 방지 계층(Anti-Corruption Layer) 라고 한다.
• 경계 안에서의 언어는 팀의 언어, 곧 유비쿼터스 언어다
  • 컨텍스트는 그 영역에서 작업하는 단일 책임 팀의 언어로 규정된다.
    • 도메인 모델과 코드, 설계 문서, 회의 모두 이 언어에 기반한다.
    • 이 언어는 단순한 언어의 정리가 아니라 비즈니스 의미와 규칙이 반영된 언어이다.
    • 이렇게 일관된 언어 사용을 통해 모델-코드-커뮤니케이션 간 불일치를 줄인다.
• 컨텍스트의 전략적 분할: 핵심 vs 지원 vs 일반
  • 모든 컨텍스트가 동등하게 중요한 것은 아니므로 전략적으로 투자해야 할 컨텍스트와 최소한의 관리만 필요한 컨텍스트를 구분해야 한다.
  • 핵심 하위 도메인
    • 비즈니스 경쟁력이 핵심, 가장 많은 투자 필요
    • 내부 개발, 최고 인재 투입
  • 지원 하위 도메인
    • 핵심을 돕는 기능, 내부 개발 혹은 외부
    • 적절한 수준의 개발 및 유지보수
  • 일반 하위 도메인
    • 차별성이 없음, 외부 솔루션 가능
    • SaaS 사용, 오픈소스 활용
• 컨텍스트 경계를 설정할 때 참고할 요소: 비즈니스 역량
  • 비즈니스 역량은 컨텍스트 경계를 정의할 때 좋은 기준이 된다.
    • 처음엔 기능 단위로 나누되,
    • 세분화된 전문 영역이 발견되면 점진적으로 새로운 컨텍스트를 추출한다.
    • 이 과정은 조직의 핵심 경쟁력을 구조적으로 파악하게 해준다.

---

목차

• 1. 바운디드 컨텍스트와 유비쿼터스 언어: 혼란을 줄이고 생산성을 높이는 DDD 핵심 개념
• 2. 핵심 도메인
• 3. 지원 도메인, 일반 도메인, 기술 메커니즘
• 4. 바운디드 컨텍스트의 크기
• 정리하며..
• 참고 사이트 & 함께 보면 좋은 사이트

---

1. 바운디드 컨텍스트와 유비쿼터스 언어: 혼란을 줄이고 생산성을 높이는 DDD 핵심 개념

<유비쿼터스 언어와 바운디드 컨텍스트의 관계>

• 유비쿼터스 언어
  • 특정 컨텍스트 내에서 일관되고 명확하게 사용되는 공통 언어
• 바운디드 컨텍스트
  • 그 유비쿼터스 언어가 적용되는 명사적 경계
  • 하나의 소프트웨어에서 여러 개 존재 가능
• 유비쿼터스 언어는 바운디드 컨텍스트 내부에서만 유효하다.
• 다른 팀이나 도메인에서는 같은 단어라도 다른 의미를 가질 수 있다.

<컨텍스트 경계의 중요성>
문제 해결에는 각기 다른 전문성과 언어가 필요하다. 서로 다른 배경을 가진 전문가들 간에 효과적으로 협업하려면, 컨텍스트를 나누고 언어를 일치시켜야 한다.
예를 들어 한 회사에서 계약(contract) 라는 용어는 아래와 같이 다르게 사용될 수 있다.

• 법무팀: 법적 계약 문서
• 서비스팀: 유저 이용 약관
• 개발팀: API 인터페이스 정의

바운디드 컨텍스트를 나누면 각 팀에서 이 용어를 정확히 정의하고 사용할 수 있게 된다.

---

2. 핵심 도메인

2. 하위 도메인(subdomain) 을 참고하세요.

OKR (Objective and Key Results)

조직이나 개인이 목표(Objective) 를 설정하고, 그 목표를 달성했는지 측정하기 위한 핵심 결과(Key Results) 를 함께 정의하는 성과 관리 프레임워크

• 목표
  • 달성하고자 하는 방향성
  • 영감을 주고, 명확하며, 측정 가능한 상태여야 함. 보통 정성적임
• 핵심 결과
  • 목표가 달성되었는지를 평가할 수 있는 정량적인 지표
  • 측정 가능하고 구체적이어야 함

OKR 예시

• KR1: 3개월 내 기술 포스트 6개 작성

OKR 특징

• 도전적 목표 지향
  • 100% 달성이 아니라 70~80% 달성을 권장함
• 정기적 검토 및 갱신
  • 보통 분기 단위로 설정하고, 리뷰함
• 투명성 강조
  • 조직 내 OKR 은 모두가 볼 수 있도록 공유
• 정량/정성 균형
  • 목표는 동기 부여, 결과는 객관적 평가

<OKR 과 KPI 비교>

항목	OKR	KPI
목적	방향성 설정과 도전	성과 지표 관리
측정 방식	정성 + 정량	정량 중심
목표 수준	도전적 (높은 목표)	실현 가능한 목표
사용 시점	변화와 혁신 중심	일상적인 성과 추적
공유 방식	조직 전체 공개	일부 비공개 간ㅇ

---

3. 지원 도메인, 일반 도메인, 기술 메커니즘

2. 하위 도메인(subdomain) 을 참고하세요.

---

4. 바운디드 컨텍스트의 크기

DDD 에서 바운디드 컨텍스트는 단순한 기술적 경계가 아니다.
비즈니스 역량과 유비쿼터스 언어를 온전히 담을 수 있어야 하며, 그 크기와 범위는 사전에 정해놓기보다 변화 가능성과 경험적 근거를 기반으로 결정해야 한다.

바운디드 컨텍스트는 비즈니스 역량 단위로 설계한다.
하나의 바운디드 컨텍스트는 하나의 비즈니스 역량을 포함한다. 해당 컨텍스트 내부에서 해당 역량은 완전히 구현될 수 있어야 한다.
핵심은 컨텍스트가 유비쿼터스 언어와 도메인 규칙을 온전히 담고 있는가이지, 마이크로서비스의 크기나 수가 아니다.
즉, 크기가 아니라 적절한 의미와 책임이 중요하다.

초기 설계 시에는 바운디드 컨텍스트 하나 당 마이크로서비스 하나로 일대일 대응하는 방식이 안정적이다.
이후 아래와 같은 상황이 발생할 때만 나누는 것을 고려한다.

• 도메인 안에서 비즈니스 역량이 더 작게 나뉘는 것이 명확해졌을 때
• 운영상의 이유(성능, 독립 배포 등)로 분할이 필요한 경우

즉, 변화는 언제나 증거 기반으로 이루어져야 한다.

바운디드 컨텍스트를 성급하게 나누는 것은 위험하다.
충분한 경험과 데이터가 없는 상태에서 구조를 바꾸면 설계의 일관성이 무너지고, 팀 간 커뮤니테이션 비용이 증가하며, 서비스 간 통신인 복잡도가 불필요하게 증가할 수 있다.

애자일(민첩함)의 진짜 의미는 “신중한 타이밍”이다.
“애자일하다”는 것은 빠르게 움직인다는 의미가 아니라, 필요한 변화에 적시에 대응한다는 뜻이다.
즉, 변화는 마지막까지 유보했다가 변화가 필요하다는 명확한 증거가 생긴 순간에 실행해야 한다.
그 전까지는 시스템을 잘 관찰하고, 팀이 그 구조에 익숙해지고, 피드백을 쌓은 시간이 필요하다.

---

정리하며..

• 유비쿼터스 언어는 바운디드 컨텍스트로 경계가 설정된 좁은 범위 내에서 일어나는 대화를 표현한다.
  • 유비쿼터스 언어로 표현된 각각의 비즈니스 개념, 다양한 용어의 정의, 비즈니스 규칙들에는 어떠한 모호함도 없어야 한다.
• 바운디드 컨텍스트는 유비쿼터스 언어가 통용되는 경계를 정해준다.
• 각 바운디드 컨텍스트별로 팀이 배정되는 것이 바람직하다. 다만, 하나의 팀이 여러 바운디드 컨텍스트를 가져갈 수는 있다.
• 바운디드 컨텍스트의 크기는 비즈니스 역량과 유비쿼터스 언어의 범위에 의해 결정되어야 한다.

---

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 반 버논, 토마스 야스쿨라 저자의 전략적 모놀리스와 마이크로서비스를 기반으로 스터디하며 정리한 내용들입니다.

• 전략적 모놀리스와 마이크로서비스