Blog
컨텍스트 매핑(Context Mapping): 서비스 간의 관계를 조율하는 기술
이 글에서는 컨텍스트 매핑의 개념과 서비스 간 관계를 정의하고 조율하는 다양한 패턴을 설명합니다.
2025년 02월 24일
컨텍스트 매핑(Context Mapping): 서비스 간의 관계를 조율하는 기술
컨텍스트 매핑은 독립적으로 개발되고 배포되는 Bounded Context 간의 관계를 정의하고 관리하는 프로세스입니다. 마치 도시의 도로망처럼, 컨텍스트 매핑은 서비스 간의 상호작용 방식을 결정하고, 시스템 전체의 일관성과 유연성을 유지하는 데 중요한 역할을 합니다.
컨텍스트 매핑(Context Mapping)은 무엇인가?
컨텍스트 매핑은 여러 개의 바운디드 컨텍스트(Bounded Context) 간의 상호작용과 관계를 명확히 정의하는 과정입니다. 각 Bounded Context는 고유한 비즈니스 로직과 데이터 모델을 가지지만, MSA 환경에서는 서로 협력하여 복잡한 기능을 제공해야 합니다. 이때, 컨텍스트 매핑은 각 Bounded Context가 서로 어떻게 상호작용할지 정의하고, 그 관계를 명확히 함으로써 시스템의 복잡성을 줄이고 유지보수성을 높입니다.
이는 각 컨텍스트가 서로 다른 도메인 모델과 유비쿼터스 언어(Ubiquitous Language)를 사용할 때, 그 경계를 명확히 하고 통합 방식을 결정하는 데 필수적입니다. 여기서 언급된 세 가지 대표적인 관계 유형 파트너십, 공유 커널, 반부패 계층에 대해 좀 더 자세히 설명하겠습니다.
주요 컨텍스트 매핑 패턴
컨텍스트 매핑에는 다양한 패턴이 존재하지만, 여기서는 가장 대표적이고 실무에서 자주 사용되는 세 가지 패턴에 대해 자세히 설명하겠습니다.
1. Partnership (파트너십): 상호 협력적인 관계
두 개의 Bounded Context가 긴밀하게 협력하며, 상호 의존적인 관계를 가지고 있을 때 사용하는 패턴입니다. 마치 사업 파트너처럼, 두 컨텍스트는 공동의 목표를 달성하기 위해 서로 협력하고, 변경 사항을 공유하며, 공동의 책임을 집니다.
- 특징
- 양측 팀이 지속적인 커뮤니케이션과 협업을 통해 통합된 의사결정을 내립니다.
- 한 컨텍스트의 변화가 다른 컨텍스트에 직접적인 영향을 미치기 때문에, 일정이나 릴리즈 등 모든 계획이 함께 조율됩니다.
- 공동의 성공이나 실패를 공유한다는 점에서 매우 높은 상호 의존성을 보입니다.
- 적용 예시: 예를 들어, ‘주문 관리’ 컨텍스트와 ‘결제 관리’ 컨텍스트가 파트너십 관계를 맺고, 주문 생성 시 결제 정보를 생성하고, 결제 완료 시 주문 상태를 업데이트하는 방식으로 협력할 수 있습니다.
- 주의 사항: 파트너십은 높은 수준의 협업과 조정을 요구하므로, 컨텍스트 간의 책임과 의존성을 명확히 정의하고, 커뮤니케이션 채널을 효과적으로 관리해야 합니다.
2. Shared Kernel (공유 커널): 핵심 모델 공유
두 개 이상의 Bounded Context가 특정한 핵심 모델(데이터 구조, 비즈니스 로직 등)을 공유하지만, 그 외의 부분은 독립적으로 운영되는 패턴입니다. 마치 공유된 핵심 기술을 기반으로 여러 개의 제품을 만드는 것과 유사합니다.
- 특징
- 공유되는 모델은 양쪽 팀이 모두 동의한 공통의 핵심 개념과 용어를 포함합니다.
- 이 부분은 두 컨텍스트 간에 중복 개발을 피하고, 일관성을 유지하기 위해 협업하여 관리됩니다.
- 그러나 공유하는 영역 외의 다른 부분은 각 컨텍스트가 독자적으로 발전시킬 수 있으므로, 변경 사항이 공유 커널에 미치는 영향은 신중하게 조율되어야 합니다.
- 적용 예시: 예를 들어, ‘고객 관리’ 컨텍스트와 ‘상품 관리’ 컨텍스트가 고객 정보와 상품 정보에 대한 기본적인 데이터 모델을 공유하고, 각 컨텍스트에서 해당 모델을 확장하여 사용할 수 있습니다.
- 주의 사항: Shared Kernel 패턴은 코드 재사용 측면에서 효율적이지만, 공유 모델의 변경이 다른 컨텍스트에 미치는 영향을 최소화하기 위해 신중하게 관리해야 합니다.
3. Anti-Corruption Layer (부패 방지 계층): 의존성 격리
하나의 Bounded Context가 다른 Bounded Context의 모델을 직접 사용하는 대신, 중간에 변환 계층을 두어 사용하는 패턴입니다. 마치 통역가가 다른 언어를 사용하는 사람들과 대화할 때, 서로의 언어를 번역하여 소통하는 것과 유사합니다.
- 특징
- 모델 변환: 외부 시스템의 데이터나 명령어를 내부 모델에 맞게 변환하는 어댑터, 트랜스레이터, 또는 파사드와 같은 컴포넌트를 두어 통신합니다.
- 종속성 최소화: 이를 통해 외부 시스템의 변경이나 불일치가 내부 도메인 모델에 직접 영향을 주지 않도록 보호합니다.
- 보호막 역할: 외부의 이질적인 개념이나 복잡한 비즈니스 규칙이 내부로 전파되지 않도록 ‘보호막’ 역할을 수행합니다.
- 적용 예시: 예를 들어, 레거시 시스템의 데이터를 사용하는 Bounded Context에서 Anti-Corruption Layer를 사용하여 레거시 데이터 모델을 새로운 데이터 모델로 변환하고, 필요한 데이터만 추출하여 사용할 수 있습니다.
- 주의 사항: Anti-Corruption Layer는 추가적인 계층을 도입하므로 개발 복잡성을 증가시킬 수 있습니다. 하지만, 외부 시스템에 대한 의존성을 줄이고 시스템의 안정성을 높이는 데 매우 효과적입니다.
추가적인 컨텍스트 매핑 패턴 상세 설명
앞서 설명된 세 가지 컨텍스트 매핑 패턴(공유 커널, 부패 방지 계층, 공개된 호스트 서비스) 외에도, 실제 마이크로서비스나 모놀리식 시스템을 개발하고 운영하는 과정에서 다양한 상황에 맞춰 적용할 수 있는 유용한 컨텍스트 매핑 패턴들이 존재합니다. 여기서는 Customer-Supplier (고객-공급자), Conformist (순응자), Separate Ways (분리) 패턴에 대해 자세히 설명하겠습니다.
1. Customer-Supplier (고객-공급자) 패턴
Customer-Supplier 패턴은 두 개의 컨텍스트 간의 명확한 역할 분담을 정의하는 패턴입니다. 한 컨텍스트는 고객(Consumer) 역할을 하여 다른 컨텍스트가 제공하는 서비스를 소비(Consume)하고, 다른 컨텍스트는 공급자(Supplier) 역할을 하여 서비스를 제공합니다. 이 패턴은 서비스 지향 아키텍처(SOA)나 마이크로서비스 아키텍처에서 흔히 볼 수 있으며, 시스템 간의 의존성을 명확히 하고 재사용성을 높이는 데 효과적입니다.
예제
- 결제 시스템과 주문 시스템: 전자상거래 플랫폼에서 주문 서비스(Order Service)는 결제 서비스(Payment Service)의 고객 역할을 한다. 주문이 생성되면, 결제 서비스를 호출하여 결제를 수행한다.
- 인증 서비스와 사용자 서비스: 사용자 관리(User Management) 서비스가 인증(Authentication) 서비스를 활용하여 사용자 로그인 기능을 제공하는 경우, 인증 서비스가 공급자이고 사용자 서비스가 고객이 된다.
2. Conformist (순응자) 패턴
Conformist 패턴은 한 컨텍스트가 다른 컨텍스트의 우세한 모델에 맞춰 자신의 모델을 변경하는 패턴입니다. 이 패턴은 주로 두 컨텍스트 간의 상호운용성을 확보하거나, 개발 및 유지보수 비용을 줄이기 위해 사용됩니다. 한 컨텍스트가 다른 컨텍스트에 비해 기술적 성숙도가 높거나, 조직적인 영향력이 큰 경우 이 패턴이 적합할 수 있습니다.
예제
- 서드파티 API 연동: 기업이 외부 서비스(예: 결제 게이트웨이, 소셜 로그인 API)를 사용할 때, 해당 API에서 제공하는 데이터 모델을 그대로 따르는 경우.
- 레거시 시스템과 신규 시스템: 신규 서비스가 기존의 레거시 시스템과 통합되어야 하는 경우, 레거시 시스템의 모델을 그대로 따를 수밖에 없는 경우가 많다.
3. Separate Ways (분리) 패턴
Separate Ways 패턴은 두 컨텍스트가 서로 독립적으로 개발 및 운영되는 패턴입니다. 이 패턴은 두 컨텍스트 간의 의존성을 최소화하고, 각 컨텍스트의 고유한 요구사항과 개발 속도를 유지하는 데 중점을 둡니다. 컨텍스트 간의 상호작용이 거의 없거나, 특정 조건 하에서만 발생하는 경우 이 패턴이 적합합니다.
예제
- B2B와 B2C 시스템의 분리: 동일한 기업이 B2B(Business-to-Business)와 B2C(Business-to-Consumer) 고객을 대상으로 하는 서비스를 운영하지만, 두 시장의 요구 사항이 다르므로 완전히 분리된 시스템으로 운영하는 경우.
- 온프레미스 시스템과 클라우드 시스템의 분리: 기존의 온프레미스(내부 데이터센터)에서 운영되는 시스템과 새로운 클라우드 네이티브 시스템이 서로 독립적으로 운영되는 경우.
이 세 가지 패턴은 도메인 주도 설계에서 각 컨텍스트 간의 관계와 통합 방식을 명확하게 정의하기 위한 도구입니다.
| 관계 방향성 | 통합 수준 | 주요 사용 사례 | |
|---|---|---|---|
| Customer-Supplier | 단방향 | 높음 (협력적) | 공급자-소비자 관계가 명확한 시스템 |
| Conformist | 단방향 | 중간 (순응적) | 강제된 표준 준수 |
| Separate Ways | 독립 | 없음 | 연관성 없는 도메인 |
이러한 패턴을 상황에 맞게 조합하거나 전환하는 것도 가능합니다. 예를 들어, 초기에는 Separate Ways로 시작하다가 비즈니스 요구가 변화하면 Customer-Supplier로 전환할 수 있습니다. 컨텍스트 매핑은 정적이지 않으며, 도메인과 조직의 성장에 따라 유연하게 재설계되어야 합니다.
컨텍스트 매핑 시 고려 사항
컨텍스트 매핑을 수행할 때 고려해야 할 사항에 대해 자세하게 설명드리겠습니다.
1. 의존성 방향
각 컨텍스트 간의 의존성이 어느 방향으로 흐르는지 명확하게 정의하는 것이 중요합니다.
- 예를 들어, 한 컨텍스트가 다른 컨텍스트의 서비스를 소비하는 경우, 어느 쪽이 공급자이고 어느 쪽이 소비자인지를 분명하게 구분해야 합니다.
- 의존성 방향이 모호하면 시스템 전체의 복잡성이 증가하며, 나중에 유지보수나 확장 시에 예기치 않은 문제가 발생할 수 있으므로 신중하게 설계해야 합니다.
2. 상호작용 방삭
서로 다른 컨텍스트가 정보를 주고받는 방법을 결정하는 것도 필수적입니다.
- REST API, 메시지 큐, gRPC 등 다양한 통신 방식 중에서 시스템의 요구사항, 성능, 확장성 등을 고려하여 적합한 방식을 선택해야 합니다.
- 선택한 상호작용 방식에 따라 데이터 전송 방식, 오류 처리, 보안 정책 등이 달라질 수 있으므로, 각 방식의 장단점을 충분히 검토한 후 결정하는 것이 좋습니다.
3. 데이터 공유 방식
컨텍스트 간에 데이터를 공유할 때에는 데이터 동기화와 일관성 유지 전략을 반드시 고려해야 합니다
- 데이터를 실시간으로 동기화할지, 비동기 방식으로 처리할지, 또는 캐시와 같은 중간 매개체를 활용할지 등 여러 옵션 중에서 최적의 방법을 선택해야 합니다.
- 잘못된 데이터 공유 방식은 데이터 불일치, 중복 또는 성능 저하와 같은 문제로 이어질 수 있으므로, 신중한 검토와 테스트가 필요합니다.
4. 변화 관리
한 컨텍스트에서 발생하는 변경 사항이 다른 컨텍스트에 어떤 영향을 미치는지 고려하고, 이에 따른 변화 관리 전략을 수립해야 합니다.
- 예를 들어, API 변경 시 버전 관리 체계를 마련하거나, 이벤트 기반 통신을 도입하여 변경 사항이 각 컨텍스트에 원활하게 전파되도록 할 수 있습니다.
- 계약 기반 테스트나 자동화된 CI/CD 파이프라인을 활용하면, 변경에 따른 리스크를 최소화하고 시스템 전반의 안정성을 유지할 수 있습니다.
이와 같이, 컨텍스트 매핑 시에는 의존성의 방향, 상호작용 방식, 데이터 공유 방식, 그리고 변화 관리 등 여러 요소를 종합적으로 고려하여 설계하는 것이 매우 중요합니다. 이를 통해 시스템의 복잡성을 줄이고, 유지보수성과 확장성을 높이며, 안정적인 운영을 도모할 수 있습니다.
마무리
컨텍스트 매핑은 MSA 환경에서 서비스 간의 관계를 정의하고 관리하는 데 필수적인 기술입니다. 파트너십, 공유 커널, 부패 방지 계층 등 다양한 컨텍스트 매핑 패턴을 이해하고, 각 컨텍스트의 특성과 요구사항에 맞는 패턴을 적용해야 합니다. 컨텍스트 매핑을 통해 서비스 간의 의존성을 최소화하고, 시스템의 유연성과 유지보수성을 높일 수 있습니다.
