534. 하위 도메인에 따른 분해 (Decompose by Subdomain - DDD 기반)

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

1. 본질: 하위 도메인에 따른 분해는 에릭 에반스의 도메인 주도 설계(DDD, Domain-Driven Design) 철학을 차용하여, 마이크로서비스를 단순히 부서(팀) 단위로 쪼개는 한계를 넘어, "데이터의 의미(문맥)가 단절되는 경계선(Bounded Context)"을 엑스칼리버처럼 그어 데이터베이스(DB)까지 물리적으로 찢어발기는 극강의 디커플링(Decoupling) 외과 수술이다.
2. 가치: 똑같은 '상품(Product)' 데이터라도 결제팀이 쓸 때와 배송팀이 쓸 때의 의미(속성)가 180도 다르다는 사실(God Class의 모순)을 깨닫게 해준다. 억지로 하나의 공용 DB 테이블을 같이 쓰다 다른 팀 코드가 박살 나는 참사를 막고, 각 서비스가 자신만의 언어와 DB 스키마를 100% 독점 소유하게 만들어 완벽한 데이터 독립성과 릴리즈(배포) 자율성을 보장한다.
3. 융합: 앞 장(533번)의 **비즈니스 능력 분해(Decompose by Business Capability)**가 1단계 초벌구이라면, 하위 도메인 분해는 시스템이 거대해졌을 때 발동하는 2단계 정밀 타격이다. MSA의 궁극적 목표인 Database-per-Service(서비스당 1DB) 아키텍처 및 사가(Saga) 패턴과 융합되어 진정한 클라우드 네이티브 생태계를 완성한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 세상의 거대한 비즈니스(쇼핑몰)를 '도메인(Domain)'이라고 부른다. 이걸 쪼갠 조각을 '서브도메인(Subdomain)'이라 한다.

  • 핵심(Core) 서브도메인: 우리 회사가 돈을 버는 1등 공신 (예: 쿠팡의 '로켓배송 알고리즘'). 무조건 최고 에이스 개발자를 투입해 인하우스(자체 개발)로 짠다.
  • 지원(Supporting) 서브도메인: 보조 역할. '상품 카탈로그 전시'.
  • 일반(Generic) 서브도메인: 남들도 다 하는 거. '결제(PG)', '로그인'. 이건 짜지 않고 외부 솔루션(SaaS, Keycloak 등)을 사다 쓴다. 아키텍트는 이 3개의 조각(서브도메인) 모양대로 1:1 매칭하여 도커 컨테이너(마이크로서비스) 깡통을 찍어낸다.

• 필요성: 비즈니스 능력(부서)으로만 썰었더니, A부서와 B부서가 똑같은 User 테이블을 쳐다보며 피 터지게 싸웠다. A팀은 "유저 테이블에 '배송지' 컬럼 추가해!", B팀은 "유저 테이블에 '신용카드' 컬럼 추가해!" 테이블 하나에 컬럼이 500개가 달린 **갓 클래스(God Class / 뚱뚱한 괴물 테이블)**가 탄생했다. B팀이 '신용카드' 컬럼명을 살짝 바꿨더니 A팀 서버 전체가 500 에러를 토하며 기절했다(강한 결합). **"데이터를 공유하면 우린 다 죽는다! 차라리 데이터를 파편화(중복)시키더라도 서로의 문맥(Context)을 완벽히 찢어내자!"**는 피눈물 나는 반성에서 Bounded Context(제한된 문맥) 분해법이 강림했다.

• 💡 비유: 하위 도메인 분해는 **'병원 수술실의 다국어 통역기 분리'**와 같습니다. 하나의 환자(User 데이터)를 두고, 정형외과(결제팀) 의사는 "뼈"를 보고, 피부과(배송팀) 의사는 "피부"를 봅니다. 두 의사에게 환자의 모든 것이 적힌 1,000페이지짜리 공용 차트(통짜 DB) 하나만 주면 서로 자기 글씨를 적느라 싸우고 차트가 찢어집니다. DDD(도메인 주도 설계)는 두 의사에게 **'각자 전용 차트(독립 DB)'**를 따로 줍니다. 정형외과 차트에는 오직 '뼈' 이야기만, 피부과 차트에는 '피부' 이야기만 적습니다. 둘은 언어(문맥)가 다르므로 영원히 차트를 섞어 쓸 필요가 없고, 서로 방해받지 않고 광속으로 수술(개발)을 마칠 수 있습니다.

• 등장 배경 및 발전 과정:

  1. 데이터베이스 정규화(Normalization)의 시대: 2000년대 DBA들은 "데이터가 중복되는 건 죄악이다!"라며 무조건 1개의 완벽한 테이블(통짜 DB)로 모든 부서를 묶었다(결합 지옥).
  2. 에릭 에반스의 DDD 출간 (2003): "개발자들이 기획자랑 딴소리하니까 버그가 난다. 기획자가 쓰는 단어(Ubiquitous Language)를 그대로 클래스 이름으로 써라! 그리고 그 단어의 뜻이 통하는 공간(Bounded Context)에 펜스를 쳐라!"라는 철학이 나왔지만, 당시엔 서버를 찢을(MSA) 기술이 없어 책장에 박혀있었다.
  3. MSA와 도커의 등장 (2010s~): 도커(Docker)가 서버를 1초 만에 찢어주자, 아키텍트들이 10년 묵은 에릭 에반스의 책을 꺼내 들었다. "어떻게 찢지? 아하! 이 Bounded Context 펜스 1개당 서버 1개씩 띄우면 100% 완벽한 독립 마이크로서비스네!"라며 DDD가 MSA 분해의 글로벌 스탠다드로 화려하게 부활했다.

• 📢 섹션 요약 비유: 이 분해법은 **'사전(Dictionary) 찢기'**입니다. '배(Ship)'라는 단어를 두고 해군(항해팀)과 과일가게(상품팀)가 뜻을 두고 싸웁니다. 옛날엔 두 뜻을 하나의 사전에 욱여넣었습니다. DDD는 사전을 2권으로 찢어버립니다. 해군 전용 사전(항해 서브도메인)에는 배를 '탈 것'으로만, 과일 전용 사전(상품 서브도메인)에는 배를 '먹을 것'으로만 적어 각자 쥐여줍니다. 헷갈릴 일(버그)이 0%가 됩니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. Bounded Context (제한된 문맥)의 엑스칼리버 칼질

이 칼질을 이해하지 못하면 MSA를 찢을 자격이 없다. 면접/실무 절대 1순위.

[ 💥 1개의 뚱뚱한 God Class (모놀리식의 지옥) ]

• 테이블 이름: Product (상품)
• 컬럼: id, name, price(결제팀이 씀), weight, size(배송팀이 씀), review_score(CS팀이 씀), stock_count(재고팀이 씀).
• 이 뚱뚱한 테이블 하나를 4개 팀이 쳐다보며 서로 눈치를 보고 쿼리를 날린다(Deadlock 지옥).

[ 🛡️ Bounded Context로 4갈래 찢기 (DDD의 구원) ] 아키텍트는 Product라는 1개의 단어(개념)를 4개의 맥락(Context)으로 무자비하게 썰어 4개의 독립 DB에 흩뿌린다.

1. [주문/결제 Context]: Product 객체 ➡ (id, name, price) 만 존재! (배송 정보는 1도 관심 없음)
2. [배송/물류 Context]: Product 객체 ➡ (id, name, weight, size) 만 존재! (가격 따위 관심 없음)
3. [재고 Context]: Product 객체 ➡ (id, stock_count) 만 존재!
4. [리뷰 Context]: Product 객체 ➡ (id, review_score) 만 존재!

• 원리: 1개의 상품을 4개 팀이 볼 때 의미가 다르다. 4개의 마이크로서비스는 각자 자기 DB를 가지고, 각자의 DB 속에는 자기가 필요한 컬럼 딱 2개씩만 가진 얄팍한 Product 테이블이 따로 존재한다. 데이터 중복(Redundancy)이 발생하지만, 남의 컬럼이 수정되든 말든 내 코드는 절대 터지지 않는 **100% 완전한 물리적 격리(Isolation)**를 달성한다.

2. 안티 코럽션 레이어 (Anti-Corruption Layer, ACL)

새로운 집(MSA)을 지었다고 옛날 집(모놀리식 레거시)을 당장 버릴 순 없다. 둘이 대화해야 한다.

• 문제: 새 MSA 서버가 낡은 레거시 DB와 통신해야 한다. 레거시 DB의 데이터 구조는 개판 5분 전이다. 새 서버가 이 개판 구조를 그대로 가져다(Mapping) 쓰면, 새 서버의 깨끗한 도메인 코드도 똥물(레거시)에 오염(Corruption)된다.

• 방어 (ACL): 새 서버와 낡은 서버 사이에 **통역사(Anti-Corruption Layer)**를 세운다. 낡은 서버가 X, Y, Z 라는 더러운 데이터를 던지면, 통역사가 중간에서 깔끔하게 A, B 로 씻고 다듬어서 새 서버로 던져준다. 새 서버는 레거시의 더러움을 평생 모르고 깨끗한 아키텍처를 유지할 수 있다.

• 📢 섹션 요약 비유: Bounded Context 쪼개기는 **'종합병원 진료실 분리'**와 같습니다. 내과(주문팀)와 안과(배송팀)는 같은 '환자(데이터)'를 보지만 관심사가 다릅니다. 내과는 환자의 '위장'만, 안과는 '눈알'만 기록하는 전용 차트(DB)를 각자 방에 둡니다. 안과 의사는 위장 상태가 궁금하지도 않고 볼 필요도 없습니다. 데이터의 파편화가 곧 진료 속도(개발 속도)와 전문성(응집도)을 극대화하는 비결입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 비즈니스 능력 분해(533번) vs 하위 도메인 분해 (DDD)

둘의 차이를 모르면 결국 모놀리스의 늪으로 회귀한다.

과목 융합 관점

• 소프트웨어 공학 (유비쿼터스 언어, Ubiquitous Language): DDD의 핵심 철학. 기획자는 "고객", 개발자는 "User", DB 관리자는 "Member"라고 부르면 시스템이 망한다. 아키텍트는 3명을 한 방에 가두고 "지금부터 우리는 이 Bounded Context 안에서는 이 놈을 무조건 'Account'라고 부른다!"라고 법으로 못 박는다. 이 언어의 통일이 곧 클래스 이름, DB 컬럼 이름, API 파라미터 이름까지 수직 관통하며 코드 1만 줄을 하나의 거대한 시로 만들어버리는 위대한 소통 공학이다.

• 데이터베이스 (이벤트 스토밍, Event Storming): 도메인(DDD)을 어떻게 찢을지 회의실에 모였다. 말로 하면 안 된다. 다 같이 벽에 노란색, 주황색 포스트잇을 미친 듯이 붙인다(이벤트 스토밍).

  • 주황색(Event): 주문생성됨, 결제완료됨, 배송시작됨
  • 노란색(Command): 주문하다, 결제하다 시간순으로 포스트잇을 쫙 붙여놓고 보면, "아! [결제완료] ➡ [배송시작] 으로 넘어갈 때 포스트잇 성격이 확 바뀌네? 여기가 Bounded Context 찢는 경계선(API 통신 구간)이다!" 라며 아키텍처 구조를 눈으로 보면서 직관적으로 썰어버릴 수 있는 현대 MSA 설계의 마법의 도구(Workshop)다.

• 📢 섹션 요약 비유: 비즈니스 분해가 정육점 아저씨가 소 한 마리를 크게 '갈비, 등심, 안심'으로 도끼로 큼직하게 내리치는 것이라면, **하위 도메인 분해(DDD)**는 수술실 의사가 메스를 들고 신경(로직)과 핏줄(데이터)이 섞이지 않게 **현미경을 보며 소유권(Context)의 미세한 경계를 잘라내는 초정밀 마이크로 서저리(수술)**입니다. 대충 썰면 피(버그)가 섞이고 살(데이터)이 썩습니다.

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

실무 시나리오

1. 시나리오 — 공유 DB의 유혹에 빠진 엉터리 마이크로서비스 (분산 모놀리스의 재앙): 사장님이 MSA로 찢으라고 해서 코드는 5개로 찢었다. 그런데 백엔드 팀장이 "DB 서버 여러 대 띄우면 AWS 요금 폭발하니까, 그냥 오라클 DB 큰 거 1개에 5개 서버가 다 같이 붙어서 쓰자! JOIN 쿼리 치면 되니까 개꿀!" 이라며 타협했다. 다음 달, 배송팀이 테이블 구조를 addr1에서 address로 바꿨다. 그 테이블을 같이 눈팅하던 결제, 쿠폰 서버가 1초 만에 Column not found 에러를 토하며 회사 서버 5대가 100% 동시 셧다운(SPOF) 당했다.

   • 아키텍트의 해결책: Database-per-Service(서비스당 1 DB) 원칙의 파멸적 붕괴다. 532장에서도 강조했지만, DDD Bounded Context의 핵심은 "내 데이터는 나만 만진다"는 극단적 독재주의다. 아키텍트는 1) 물리적인 DB 서버를 5개로 찢거나, 최소한 논리적 Schema(계정)라도 5개로 완벽히 찢어 남의 DB를 SELECT조차 할 권한을 차단해야 한다. 2) 옆 팀 데이터가 궁금하면 절대 쿼리로 물어보지 말고, 무조건 **HTTP REST API나 Kafka Message 큐를 통해서 "JSON으로 포장해서 좀 줄래?"라고 예의 바르게 요청(Decoupling)**하게 아키텍처를 강제해야만 장애의 횡적 전파(Blast Radius)를 콘크리트 벽으로 막을 수 있다.

2. 시나리오 — CQRS (Command and Query Responsibility Segregation)의 등판, 분산 DB의 조회 지옥: DB를 서비스마다 다 찢어놨더니(천국 달성), 기획자가 미친 요구사항을 가져왔다. "사용자 '마이페이지' 화면 하나에 [내 주문 내역], [내 배송 상태], [내 쿠폰 개수]를 다 합쳐서 한 화면에 예쁘게 그려주세요!" 옛날 통짜 DB 시절엔 JOIN 1번 치면 0.1초 컷이었다. 지금은 API Gateway가 주문 서버 찌르고, 배송 서버 찌르고, 쿠폰 서버를 3번 찔러서 데이터를 합치느라 로딩이 3초가 걸린다.

   • 아키텍트의 해결책: **도메인 분리(DDD)의 치명적 반작용, 분산 조회 병목(Read Bottleneck)**이다. 이를 타파하는 궁극의 패턴이 CQRS다. 명령(쓰기/Command)과 조회(읽기/Query)의 책임을 완전히 찢어버린다!
     • 쓰기(Write): 주문, 배송은 각자의 전용 DB(RDBMS)에 쓴다. 쓰자마자 카프카(Kafka)에 "나 주문 들어옴!" 이벤트를 던진다.
     • 읽기(Read): '마이페이지 전용 서버'가 카프카의 이벤트를 다 주워 먹고, **Elasticsearch나 MongoDB 같은 초고속 NoSQL(조회 전용 DB)**에 [주문+배송+쿠폰] 덩어리 JSON을 통째로 뭉쳐서 한 번에 박아둔다.
     • 사용자가 마이페이지를 열면, 느린 3개 서버를 찌르지 않고, 저 '조회 전용 DB' 딱 1곳만 0.01초 만에 광속 조회(SELECT)하고 나간다. 궁극의 비동기 성능 최적화 융합이다.

도입 체크리스트

• 조직적: '도메인 전문가(Domain Expert)'가 화이트보드 회의에 참여하고 있는가? DDD는 코더(Coder)들의 놀이가 아니다. "이 할인 쿠폰은 주문 취소 시 다시 살려주나요?"라는 비즈니스 룰의 엣지 케이스는 백엔드 개발자 100명이 모여도 모른다. 무조건 현업 콜센터 직원이나 상품 기획자(Domain Expert)를 납치해서 회의실에 가두고 3일 내내 이벤트 스토밍(Event Storming)을 같이 뛰게 만들어, **"코드 로직 = 현실 세계 비즈니스 룰"**이 100% 거울처럼 복제되도록 조율(Facilitating)하는 것이 아키텍트의 1순위 잡무다.
• 기술적: 도메인 이벤트(Domain Events)를 카프카(Kafka) 같은 이벤트 버스로 던지는가? 내 도메인 안에서 벌어진 일(주문 완료)을 남의 도메인(배송팀)에 알릴 때, 직접 상대방 서버를 HTTP POST로 찌르면 동기식 강결합(Coupling)이 생겨 상대가 뻗었을 때 나도 뻗는다(Time-out 붕괴). 아키텍트는 100% **비동기 이벤트 주도(Event-Driven)**로 짜야 한다. 주문 서버는 "주문 1건 됨"이라는 전단지(Event)를 허공(Kafka)에 휙 뿌리고(Publish) 자기 할 일 하러 간다. 배송팀 서버는 알아서 그 전단지를 주워 먹고(Subscribe) 택배를 싼다. 둘은 서로의 IP나 얼굴조차 모르는 완벽한 타인이어야 시스템이 절대 죽지 않는다. (다음 장 536번 연계)

안티패턴

• "유틸리티(Utility) 서비스 몽땅 묶기 (Trash Can Anti-pattern)": 도메인을 쪼개다가 "어? 이메일 발송, SMS 발송, S3 이미지 업로드는 어느 도메인이지? 에라이, 그냥 Common-Service (공통 서버) 1개로 묶어버려!"라고 쓰레기통처럼 다 때려 박는 짓. 결국 세상 모든 50개 마이크로서비스가 그 쓰레기통 서버 1대(공통 서버)를 찌르느라 트래픽이 몰려, 이 서버 1대가 뻗으면 회사 전체 메일과 문자와 결제가 다 마비되는 최악의 단일 장애점(SPOF)으로 타락한다. 공통 기능조차 알림(Notification) 도메인, 미디어(Media) 도메인으로 철저하게 그 문맥(Context)에 맞게 찢어발겨야 한다.

• 📢 섹션 요약 비유: 공통 서버를 1개로 묶는 짓은, 아파트 50가구가 각자 화장실을 안 짓고 **'1층 공중화장실 1개를 다 같이 쓰는 것'**과 같습니다. 화장실 변기가 1번 막히면 50가구 주민 전원이 배를 부여잡고 바닥에 쓰러집니다. 진정한 DDD는 낭비(중복) 같아 보여도 무조건 50가구 각자 방 안에 개별 변기(독립 모듈)를 50개 달아주는, '비용을 지불하고 쟁취하는 완벽한 고립과 가용성의 사치'입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• Event Sourcing (이벤트 소싱)과 CQRS의 주류화: DDD의 극한의 종착역은 이벤트 소싱이다. 현재는 DB 테이블에 "현재 내 잔고 5만 원" 이라고 최종 결과값(State) 1줄만 업데이트(UPDATE)해서 덮어씌운다. 미래엔 데이터 덮어쓰기 자체를 미개한 짓으로 본다. "10만 원 입금 이벤트", "5만 원 출금 이벤트" 처럼 일어난 모든 사건(Event) 10,000줄을 블록체인 장부처럼 절대로 지우지 않고(Append-only) 주르륵 다 적어둔다. 필요할 때 이 10,000줄을 1초 만에 덧셈 뺄셈(Replay)해서 "아 현재 5만 원이네"를 실시간 계산해 내는 우주적 무결성 아키텍처(이벤트 소싱)가 금융권 코어 뱅킹(Core Banking)을 완전히 뒤엎어 삼키고 있다.
• AI 주도 도메인 설계 (LLM-Driven DDD): 가장 고통스러운 작업인 "이벤트 스토밍 회의 3박 4일"을 AI가 박살 낸다. 기획자가 워드 문서로 10페이지짜리 "쇼핑몰 요구사항"을 챗GPT에 던지고, "이거 Bounded Context 5개로 찢어주고, 각 도메인 간 카프카 이벤트(Event) 날리는 통신 다이어그램 그려와"라고 치면, AI가 단 10초 만에 완벽한 UML 도면과 DTO 클래스 자바 코드를 100% 토해내는 자동 아키텍처 스캐폴딩(Auto-Scaffolding) 시대가 도메인 주도 설계의 무거운 진입 장벽(러닝 커브)을 완전히 박살 내 줄 것이다.

참고 표준

• Domain-Driven Design (에릭 에반스, 2003): 소프트웨어 아키텍트들의 영원한 블루북(파란 책). 코드를 찢기 전에 도대체 비즈니스의 '말(Language)'과 '문맥(Context)'을 어떻게 찢어야 하는지 숟가락으로 떠먹여 준 21세기 아키텍처 십계명.
• Microservices Patterns (크리스 리처드슨): "MSA 어떻게 찢어? DB는 어떻게 관리해? 롤백은 어떻게 쳐?"라며 실무자들이 피눈물 흘릴 때, Decompose by Subdomain, Saga, CQRS 등 44가지 실전 엑스칼리버 패턴을 정리해 준 위대한 교과서.

하위 도메인에 따른 분해 (Decompose by Subdomain), 즉 DDD 기반의 아키텍처는 소프트웨어 공학이 "위대한 코드는 컴퓨터의 CPU 속도에서 나오는 것이 아니라, 그 시스템을 짓고 있는 인간들의 입에서 나오는 언어(Language)의 통일과 명확한 선 긋기(Boundary)에서 나온다"는 철학적 통찰을 이뤄낸 가장 찬란한 진화다. 우리는 과거 "데이터 중복은 죄악"이라는 정규화(Normalization)의 미신에 갇혀, 수천 명의 개발자가 하나의 거대한 DB 꿀단지에 머리를 처박고 서로의 코드를 짓밟으며 피 흘려 싸웠다. 기술사는 도끼를 들고 이 망상(모놀리식 DB)의 제단을 산산조각 내야 한다. 아무리 데이터가 낭비되고 메모리를 더 퍼먹더라도(Redundancy), 철저히 **"내가 다스리는 문맥(Context)의 영토 안에는 그 누구의 숟가락(남의 팀 DB 접근)도 허락하지 않겠다"**는 폐쇄적이고 잔혹한 고립(Isolation)의 벽을 세워야 한다. 이 완벽한 단절을 이룬 자만이 역설적으로, 옆 팀 서버가 폭발하고 인터넷망이 찢어지는 클라우드의 지옥 속에서도, 내 서버(마이크로서비스)만큼은 영원토록 0.1초 만에 춤추듯 혼자 살아남아 숨 쉬게 만드는 궁극의 회복 탄력성(Resilience)을 쟁취할 수 있다.

• 📢 섹션 요약 비유: Bounded Context로 분해한다는 것은, 대항해시대의 거대한 '범선(모놀리식)'을 50개의 작은 '구명정(MSA)'으로 찢어 바다에 띄우는 작전과 같습니다. 옛날 범선은 주방 하나, 돛 하나를 다 같이 썼기 때문에 대포 1방 맞고 구멍이 나면 전원 수장되었습니다(장애 전파). 구명정으로 찢어 타면 밥그릇(DB)도 50개, 노(서버)도 50개로 비효율적으로 돈(중복)이 듭니다. 하지만 상어가 나타나 3번 구명정을 물어 뜯어버려도, 나머지 49개의 구명정은 1도 쳐다보지 않고 살아남아 각자의 노를 저어 당당하게 목적지(비즈니스 가용성)에 도착하는 가장 압도적인 생존과 독립의 법칙입니다.

📌 관련 개념 맵 (Knowledge Graph)

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

1. 학교 도서관(모놀리식)에서 친구 10명이 '백과사전(통짜 DB)' 한 권을 같이 보며 숙제를 하려니까, 서로 자기가 먼저 보겠다고 싸우고 책이 북북 찢어졌어요 ㅠㅠ
2. 그래서 똑똑한 선생님(아키텍트)이 백엔드 사전을 '동물 사전', '우주 사전', '음식 사전'(서브도메인) 등 10권의 미니 책으로 쫙쫙 찢어서 친구들 각자 자기 책상(컨테이너)으로 가져가게 해 줬어요!
3. 이제 우주 사전 내용이 바뀌든 말든 동물 사전을 보는 친구는 자기 일만 빛처럼 빠르게 끝낼 수 있어요! 이렇게 하나의 뚱뚱한 데이터를 서로 신경 안 쓰고 혼자만 쓸 수 있게 완벽히 쪼개버리는 짱 똑똑한 마법을 **'하위 도메인 분해(DDD)'**라고 부른답니다!