223. 컨텍스트 매핑 (Context Mapping) - 도메인 주도 설계(DDD) 바운디드 컨텍스트 연동 관계 분산 시스템 파트너십 공유 커널 충돌 방지

핵심 인사이트: (221번 바운디드 컨텍스트 심화) 221번에서 쇼핑몰을 [주문 팀 방]과 [배송 팀 방]으로 철저하게 벽을 쳐서(바운디드 컨텍스트) 쪼개놨다. 벽을 치니 간섭이 없어서 속은 편한데, 문제는 방과 방 사이에 데이터를 주고받아야 할 일이 무조건 생긴다! 주문이 들어와야 배송을 할 거 아니냐! "야! 두 방 사이에 콘크리트 벽을 쳐놨으니, 이제 서로 소통할 '외교 관계(조약)'를 맺어야지!! 주문 팀이 갑을병정 중에 '갑'이 되어서 명령을 때릴 건지(Upstream), 배송 팀이 넙죽 엎드려서 주는 대로 받을 건지(Downstream), 아니면 서로 피 터지게 싸우다가 가운데 '통역사'를 세울 건지 도면에 명확하게 화살표를 그려라!!" 독립된 마이크로서비스(방)들 간의 우호/적대 외교 관계를 지도로 그리는 작업, 컨텍스트 매핑이다.

Ⅰ. 고립된 캡슐들의 소통 문제

• 221번에서 바운디드 컨텍스트(MSA 캡슐)로 시스템을 예쁘게 찢어놨습니다.
• 하지만 시스템은 혼자 돌아가지 않습니다. [주문 컨텍스트]의 데이터가 [결제 컨텍스트]로 흘러가야 합니다. 이 두 컨텍스트를 개발하는 2개의 개발팀은 서로 어떤 방식으로 협력(또는 대립)해야 할까요?

Ⅱ. 컨텍스트 매핑 (Context Mapping)의 개념 🌟

• 개념: 시스템 내에 존재하는 여러 바운디드 컨텍스트(구역)들 간의 물리적/논리적 연동 관계와, 각 컨텍스트를 담당하는 팀들 간의 조직적, 외교적 역학 관계(힘의 우위)를 한눈에 볼 수 있도록 도면(Context Map)으로 정의하는 작업입니다.

Ⅲ. 마이크로서비스 외교 관계 6대 패턴 🌟 핵심 🌟

컨텍스트 간의 힘의 균형(상류 Upstream vs 하류 Downstream)에 따라 패턴이 갈립니다.

1. 파트너십 (Partnership) - "피를 나눈 형제"

• 두 컨텍스트 팀이 100% 동등한 위치에서 서로 돕습니다.
• "야, 우리 엑셀 포맷 바꿀 건데 너희도 코드 같이 바꿔줄래?" 하면 "ㅇㅋ 같이 밤새자!" 하는 끈끈한 2인 3각 관계입니다. 실패하면 둘 다 같이 망합니다.

2. 공유 커널 (Shared Kernel) - "화장실 같이 쓰기"

• 벽으로 다 찢어놨지만, 도저히 포기 못 하는 '아주 작은 핵심 공통 코드(예: 인증 로직)' 하나만 교집합으로 떼어내서 양쪽 팀이 같이 공유해서 쓰는 방식입니다.
• 이 공통 코드를 고치려면 양쪽 팀의 완벽한 합의가 필요하므로 결합도가 치솟는 위험한 도박입니다. 가급적 안 쓰는 게 좋습니다.

3. 고객-공급자 (Customer-Supplier) - "갑질의 서막"

• **상류(Supplier 공급자)**와 **하류(Customer 고객)**의 수직 관계가 성립합니다.
• 하류 팀(배송)이 "대장님, 우리 배송 엑셀 폼 좀 이렇게 바꿔주시면 안 됩니까?" 라고 상류 팀(주문)에게 굽신거리며 요청(요구사항 제출)할 수 있는 관계입니다. 상류 팀은 하류 팀의 요청을 우선순위에 반영해 줍니다.

4. 준수주의자 (Conformist) - "완벽한 노예"

• 하류 팀(나)이 상류 팀(외부 권력)에게 절대 복종하는 구조입니다.
• 내가 아마존(AWS) 결제 API를 가져다 씁니다. 아마존이 내일 당장 "API 규격 이렇게 바꾼다!"라고 통보하면, 나는 찍소리 못하고 내 코드를 아마존이 시키는 대로 다 뜯어고쳐야(준수해야) 합니다.

5. 충돌 방지 계층 (ACL, Anti-Corruption Layer) 🌟 (가장 중요, 224번 독립 문서)

• 상류(무식한 레거시 똥통)에서 쓰레기 데이터가 흘러 내려옵니다.
• 하류 팀인 내가 "저 쓰레기 엑셀 포맷을 내 깨끗한 시스템에 그대로 넣을 순 없어!"라며, 두 장벽 사이에 '번역기(ACL 통역사)'를 떡하니 세워서 상류의 더러운 데이터를 내 입맛에 맞는 깨끗한 데이터로 싹 다 세탁(번역)해서 가져오는 궁극의 방어 패턴입니다.

6. 발행자-구독자 (Open Host Service & Published Language)

• 214번 이벤트 드리븐(EDA)의 핵심입니다. 상류 팀이 "난 표준 JSON(Published Language)으로 브로커 우체통에 이벤트 던질 테니까, 하류 니들은 알아서 복사해 가든가 말든가~" 하고 쿨하게 던지는 관계입니다. (극강의 느슨한 결합)

Ⅳ. 왜 이걸 도면으로 그려야 하나?

• 이 맵(Map)을 벽에 붙여놓으면, 개발자들은 "아! 우리가 [결제 팀] 코드 가져다 쓸 때는 쟤네가 '갑'이니까 우리 마음대로 쟤네 코드 수정해달라고 조르면 안 되는구나(Conformist)!"라는 걸 명확히 깨닫고 헛된 회의 시간을 수백 시간 아낄 수 있습니다.

📢 섹션 요약 비유: **컨텍스트 매핑(Context Mapping)**은 갈기갈기 찢어진 여러 부족(바운디드 컨텍스트)들 사이의 '살벌한 외교 관계와 국경선 조약 지도'를 그리는 작업입니다. 강을 따라 위에 사는 늑대 부족(상류 Upstream)과 아래에 사는 곰 부족(하류 Downstream)이 있습니다. 두 부족이 동맹을 맺고 같이 강을 청소하면 **'파트너십'**입니다. 하류에 사는 곰 부족이 윗마을 늑대 족장에게 "물 좀 깨끗이 흘려보내 주십쇼"라고 건의할 수 있으면 '고객-공급자' 관계입니다. 반대로 윗마을이 미친 제국(AWS)이라서 강물에 독약을 풀든 똥을 싸든 아랫마을이 닥치고 적응해서 마셔야만 하면 **'준수주의자(Conformist 노예)'**입니다. 만약 아랫마을 족장이 "저 윗마을 똥물을 그대로 마실 순 없어!"라며 국경선에 거대한 최첨단 정수기(ACL 번역기)를 설치해 깨끗한 물만 걸러 먹으면 '충돌 방지 계층' 방어술이 됩니다. 이 지도를 통해 개발팀들은 서로가 어떤 정치적 역학 관계에 있는지 완벽하게 파악하고 시스템 간 통신 인터페이스를 짜게 됩니다.