스타트업을 위한 Bounded Context 나누기

도입

스타트업 단계에서 Bounded Context를 나누는 일은 과한 설계처럼 보일 수 있다. 하지만 초기 도메인 경계를 명확히 하지 않으면 팀이 늘어날수록 용어 충돌과 책임 혼선이 반복된다. 이 글은 작은 조직에서도 적용 가능한 DDD 경계 설정 방법을 소개한다.

스타트업을 위한 Bounded Context 나누기 커버 — Wikimedia Commons 기반 무료 이미지

문제 정의

컨텍스트가 없는 상태에서 기능만 빠르게 추가하면 다음 문제가 반복된다.

동일한 단어가 팀마다 다른 의미로 쓰여 커뮤니케이션 비용이 증가한다.
데이터 모델이 범용 테이블로 확장되어 변경 시 파급 범위가 커진다.
권한, 결제, 콘텐츠 정책이 한 서비스에 뒤섞여 배포 리스크가 높아진다.

초기에는 완벽한 분리보다 언어와 책임 분리부터 시작하면 된다. 컨텍스트 맵을 먼저 만들고 코드 경계를 점진적으로 맞춰간다.

핵심 개념

관점	설계 기준	검증 포인트
언어	팀별 유비쿼터스 언어 정의	용어 충돌 빈도
모델	컨텍스트별 엔티티 분리	모델 변경 파급 범위
통합	ACL(anti-corruption layer)	경계 침범 PR 비율
조직	팀 책임과 코드 경계 정렬	의사결정 속도

스타트업에서는 경계를 너무 세분화하기보다 핵심 도메인과 지원 도메인을 구분하는 수준이 현실적이다. 중요한 것은 명명 규칙과 인터페이스 계약이다.

코드 예시 1: Bounded Context 계약

// Billing Context
export type BillingInvoice = {
  invoiceId: string;
  accountId: string;
  totalAmount: number;
  status: "issued" | "paid" | "void";
};

// Content Context
export type ContentPost = {
  postId: string;
  authorId: string;
  title: string;
  visibility: "public" | "private";
};

코드 예시 2: ACL 어댑터

export class BillingAcl {
  constructor(private readonly billingClient: BillingApiClient) {}

  async getActivePlan(accountId: string) {
    const invoice = await this.billingClient.fetchLatestInvoice(accountId);
    return {
      accountId,
      isPaid: invoice.status === "paid",
      plan: invoice.totalAmount > 0 ? "pro" : "free",
    };
  }
}

아키텍처 흐름

Mermaid diagram rendering...

Clean Architecture 레이어 구조

DDD 경계도 Clean Architecture 관점으로 보면 애플리케이션 계층에서 컨텍스트 간 통합 정책을 관리하고, 인프라는 어댑터로 격리하는 구조가 안정적이다.

Layer	책임	적용 방식
Entities	컨텍스트 내부 모델	BillingInvoice, ContentPost
Use Cases	컨텍스트 간 정책	PublishIfPlanAllows
Interface Adapters	ACL, Event Translator	BillingAcl
Frameworks	DB, 메시지 브로커	Postgres, Kafka

인프라 구성도