---
title: arawn/building-modular-monoliths-using-spring (박용권, 우아한형제들 발표 동반 코드)
source_type: company-tech-blog
url: https://github.com/arawn/building-modular-monoliths-using-spring
archive_url:
status: raw
confidence: medium
tags: [ca-architecture-layout, modulith, modular-monolith, arawn, woowahan, ddd]
related_branches: [feature-architecture-enforcement-rules, feature-skeleton-package-blueprint-contract, feature-domain-feature-onboarding-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# arawn/building-modular-monoliths-using-spring

> Layer: `raw/company-tech-blogs/` — 박용권 (당시 우아한형제들) GitHub repository 의 README 와 동반 코드. 2020 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다" 발표의 reference 구현체 — Spring Modulith 등장 이전 한국 커뮤니티의 모듈형 모노리스 사실상 표준 사례.
> 검증된 요약은 `/ingest` 후 `wiki/concepts/`에 별도 작성. 원본은 raw에 영구 보관.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-architecture-enforcement-rules]] | 응집/결합을 아키텍처 스타일보다 우선시한다는 원칙 — ca-tmpl 의 enforcement rule 우선순위 근거 |
| [[raw/branch-notes/feature-skeleton-package-blueprint-contract]] | 도메인 중심 패키지 구조 (catalogs/orders/shipments) 사례 — ca-tmpl 의 `features/{name}` 구조 reference |
| [[raw/branch-notes/feature-domain-feature-onboarding-contract]] | 모듈을 도메인 단위로 추출하는 onboarding 패턴의 reference 사례 |
| [[raw/project-notes/ca-skeleton-operational-contract]] | §20. Skeleton Blueprint Contract + §19. Domain Application Readiness Contract — feature-first 결정의 한국 커뮤니티 reference |

## 컨텍스트 / 왜 저장했는지

ca-tmpl 의 feature-first 결정에 대한 대안 4: Spring Modulith 등장 이전 한국 커뮤니티에서 가장 많이 인용된 modular monolith reference. Spring 공식 도구 없이 "어떻게 경계를 만들 것인가" 를 단계별로 보여주는 자료로, ca-tmpl 의 feature-first 가 다음 단계로 가려면 무엇이 필요한지 보여줌.

## 출처 / Source

- 원본 URL: https://github.com/arawn/building-modular-monoliths-using-spring
- 아카이브: (미확보)
- 저자 / 조직: arawn (박용권, 당시 우아한형제들)
- 동반 발표: 2020 "잘 키운 모노리스 하나 열 마이크로서비스 안 부럽다" (SlideShare)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§README — 목적] "스프링을 기반으로 모듈형 모노리스를 만들기 위한 방안을 공유합니다."

> [§README — 원칙] "나는 응집과 결합을 다스리는 것이 아키텍처 스타일보다 먼저라고 말하고 싶다."

> [§README — 설계 원칙] "높은 응집도(Cohesion)와 느슨한 결합도(Coupling)라 생각한다."

> [§README — 진행 단계] "step_1: modularization - 도메인 중심 모듈화와 모듈간 의존성 관리"

> [§README — 진행 단계] "step_2: encapsulation and separately - 모듈을 보호하고, 모듈간 의존성 분리"

> [§README — 진행 단계] "step_3: context boundaries - 모듈 자율성을 지키는 컨텍스트 경계"

> [§README — 도메인 구조] "핵심 도메인으로 상품(catalogs), 주문(orders), 배송(shipments)을 추출"

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| ARAWN-MOD-C1 | repository 의 목적은 **Spring 기반 모듈형 모노리스 구성 방안 공유** | [§README — 목적] "스프링을 기반으로 모듈형 모노리스를 만들기 위한 방안을 공유합니다." | `engineering-blog` | Spring + 모듈형 모노리스 학습/설계 사례 | "방안" 이 prod 환경에서 검증된 표준이라는 뜻은 아님 — 학습/발표용 reference |
| ARAWN-MOD-C2 | 저자의 핵심 주장: **응집과 결합을 다스리는 것이 아키텍처 스타일보다 먼저** | [§README — 원칙] "나는 응집과 결합을 다스리는 것이 아키텍처 스타일보다 먼저라고 말하고 싶다." + [§README — 설계 원칙] "높은 응집도(Cohesion)와 느슨한 결합도(Coupling)라 생각한다." | `engineering-blog` | 모듈 분할 원칙 우선순위 결정 | "아키텍처 스타일이 무의미하다" 는 뜻은 아님 — 우선순위만 명시 |
| ARAWN-MOD-C3 | 모듈화 진행은 **3단계: (1) 도메인 중심 모듈화 + 의존성 관리, (2) 캡슐화 + 모듈간 의존성 분리, (3) context boundaries 로 모듈 자율성 확보** | [§README — 진행 단계] "step_1: modularization - 도메인 중심 모듈화와 모듈간 의존성 관리" + "step_2: encapsulation and separately - 모듈을 보호하고, 모듈간 의존성 분리" + "step_3: context boundaries - 모듈 자율성을 지키는 컨텍스트 경계" | `engineering-blog` | 모듈형 모노리스 점진적 채택 로드맵 | 각 step 의 구체적 도구 (package-private / ApplicationEvent / DDD bounded context 등) 의 선택은 본 인용 범위 밖 |
| ARAWN-MOD-C4 | 패키지 구조는 **도메인 중심** (catalogs, orders, shipments) — 기술 layer 분할이 아닌 도메인 분할 | [§README — 도메인 구조] "핵심 도메인으로 상품(catalogs), 주문(orders), 배송(shipments)을 추출" | `engineering-blog` | 도메인 단위 최상위 패키지 결정 | feature 안의 내부 구조 (4-layer 등) 는 본 인용 범위 밖 — ca-tmpl 의 `features/{name}` 내부 layer 결정은 별도 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `ARAWN-MOD-C1`: repository 의 목적 (Spring 모듈형 모노리스 방안 공유)
  - `ARAWN-MOD-C2`: 응집/결합 우선 원칙 (저자 주장)
  - `ARAWN-MOD-C3`: 3단계 점진적 모듈화 로드맵
  - `ARAWN-MOD-C4`: 도메인 중심 패키지 구조 사례
- **이 자료가 증명하지 않는 것**:
  - 이 패턴이 한국 백엔드의 "공식 best practice" — `engineering-blog` 수준 (개인 GitHub repo + 발표). 우아한형제들 사내 표준이라는 보장 없음
  - Spring Modulith 도입 후에도 이 패턴이 권장된다는 주장 (Spring Modulith 와의 비교는 본 자료에 없음)
  - 경계 위반의 컴파일/테스트 단계 검출 메커니즘의 충분성 (저자가 "팀 컨벤션 유지" 강조)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 의 `features/{name}` 안 4-layer 구조와 arawn 의 도메인 단위 모듈의 분할 차이 (layer 강제 vs 자유)
  - Spring Modulith 도입 시 본 패턴이 어떻게 마이그레이션되는지

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- 적용 시나리오: Spring Modulith 도입 전 (또는 Boot 2.x 환경) 에서 모듈 경계를 만들고 싶은 팀.
- 장점: 도구가 아니라 "원칙" 중심. package-private 가시성, ApplicationEvent 기반 통신 등을 손으로 구현하며 모듈 분리 원리 학습.
- 단점: Spring 공식 도구 부재 → 경계 위반 시 컴파일/테스트 차원 검증 약함. 팀 컨벤션 유지가 핵심.
- ca-tmpl(feature-first) 와의 차이: arawn 자료는 **도메인 = 모듈 = 최상위 패키지** 라는 점에서 ca-tmpl 과 정확히 같은 발상. ca-tmpl 의 `features/{name}` 은 arawn 의 `catalogs/`, `orders/` 와 1:1 매핑. 차이는 ca-tmpl 이 feature 안에 4-layer 를 두는 반면 arawn 자료는 layer 분할은 케이스마다 다름.
- 신뢰도: `engineering-blog` (저자가 우아한형제들 시기, 개인 GitHub repo + 발표). 사례/관점으로 사용.

## Related / 관련

- 같은 주제 다른 raw:
  - [[raw/company-tech-blogs/woowahan-hexagonal-multimodule]] (우아한형제들 multi-module 헥사고날)
- 인용하는 branch:
  - [[raw/branch-notes/feature-architecture-enforcement-rules]]
  - [[raw/branch-notes/feature-skeleton-package-blueprint-contract]]
  - [[raw/branch-notes/feature-domain-feature-onboarding-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]] (§20, §19)
- 인용한 wiki 요약: (미작성)
- 대안 그룹: **Topic 1 — Architecture Layout** (대안 5종: feature-first / layer-first / hexagonal / modulith / onion)
- 본 source 의 위치: 대안 3: modulith (Spring Modulith 이전 reference)