96 lines
8.7 KiB
Markdown
96 lines
8.7 KiB
Markdown
---
|
|
title: MSA로의 여정에서 만난 Spring Modulith 체리픽 해본 후기 (카카오뱅크)
|
|
source_type: company-tech-blog
|
|
url: https://tech.kakaobank.com/posts/2507-legacy-to-modular-monolith-with-spring-modulith/
|
|
archive_url:
|
|
status: raw
|
|
confidence: medium
|
|
tags: [ca-architecture-layout, modulith, kakaobank, modular-monolith, hexagonal]
|
|
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
|
|
---
|
|
|
|
# MSA로의 여정에서 만난 Spring Modulith 체리픽 해본 후기
|
|
|
|
> Layer: `raw/company-tech-blogs/` — 카카오뱅크의 모듈러 모놀리스 + Spring Modulith 체리픽 사례.
|
|
> 공식 best practice 가 아닌 **회사 사례**. ca-tmpl 의 architecture-layout 대안 5종 중 "modulith" 대안의 reference.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-architecture-enforcement-rules]] | Spring Modulith / ArchUnit 기반 모듈 경계 자동 검증 대안 비교 근거 |
|
|
| [[raw/branch-notes/feature-skeleton-package-blueprint-contract]] | 패키지 blueprint 결정 시 modulith 캡슐화 + Public API 패턴의 한국 금융권 사례 |
|
|
| [[raw/branch-notes/feature-domain-feature-onboarding-contract]] | 신규 도메인 추가 시 모듈 분리 비용 비교 근거 |
|
|
| [[raw/project-notes/ca-skeleton-operational-contract]] | §19 Domain Application Readiness, §20 Skeleton Blueprint 의 modulith 대안 reference |
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://tech.kakaobank.com/posts/2507-legacy-to-modular-monolith-with-spring-modulith/
|
|
- 아카이브 URL: (미수집)
|
|
- 저자: Kaya (강희서)
|
|
- 조직: 카카오뱅크 (KakaoBank)
|
|
- 발행일: 2025-07-04
|
|
- 마지막 확인일: 2026-05-27
|
|
|
|
## 왜 저장했는지 / Why archived
|
|
|
|
ca-tmpl 의 feature-first 결정에 대한 **대안 4: Spring Modulith** 의 한국 금융권 실 적용 사례. Kotlin + Spring Boot + Gradle 멀티모듈 + Hexagonal 위에 Spring Modulith 를 "체리픽" 한 케이스 — ca-tmpl 이 추후 진화할 수 있는 경로의 1차 증거.
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§모듈러 모놀리스 정의] "하나의 애플리케이션으로 배포되는 **모놀리스 형태**를 유지하면서 내부적으로는 **독립적인 모듈 단위로 도메인을 분리**하여 모듈 간에 명시적인 의존성을 기반으로 느슨하게 결합된 구조를 가집니다."
|
|
|
|
> [§캡슐화와 Public API] "각 모듈은 내부 구현 클래스를 감추고, 패키지 최상단에 위치한 일부 클래스만 public으로 외부에 공개합니다. 이 클래스들이 Public API로, 모듈 간 통신은 반드시 이 API를 통해서만 가능합니다."
|
|
|
|
> [§Spring Modulith 선택 이유] "Spring Modulith는 저희 팀의 요구에 맞춰 유연하게 모듈을 관리하고 경계를 설정할 수 있는 강력한 도구로, 사용해볼 만한 가치가 충분히 있다고 판단했습니다."
|
|
|
|
> [§헥사고날 통합] "Gradle 멀티모듈을 이용한 헥사고날 아키텍처를 적용하여 애플리케이션 계층과 어댑터 계층을 물리적으로 분리하고, Port 인터페이스로만 통신하여 외부 의존성으로부터 도메인을 보호하는 구조입니다."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| KAKAOBANK-MOD-C1 | 모듈러 모놀리스 = 단일 배포 유지하면서 내부적으로 도메인을 독립 모듈로 분리, 모듈 간 명시적 의존성 기반 느슨한 결합 | [§모듈러 모놀리스 정의] "하나의 애플리케이션으로 배포되는 모놀리스 형태를 유지하면서 내부적으로는 독립적인 모듈 단위로 도메인을 분리하여 모듈 간에 명시적인 의존성을 기반으로 느슨하게 결합된 구조" | `company-case-study` | 단일 배포 단위 + 도메인 다수 분리 필요 시나리오 | 이 구조가 모든 도메인에 적합하다는 뜻 아님. 도메인 경계가 모호한 초기 프로젝트에는 부담일 수 있음 |
|
|
| KAKAOBANK-MOD-C2 | 모듈 경계는 캡슐화 + Public API 패턴으로 강제 — 내부 구현은 숨기고 패키지 최상단 일부 클래스만 public 공개, 모듈 간 통신은 Public API 만 허용 | [§캡슐화와 Public API] "각 모듈은 내부 구현 클래스를 감추고, 패키지 최상단에 위치한 일부 클래스만 public으로 외부에 공개합니다. 이 클래스들이 Public API로, 모듈 간 통신은 반드시 이 API를 통해서만 가능합니다" | `company-case-study` | Spring Modulith 채택 모듈 경계 설계 | Spring Modulith 없이도 동일 패턴 강제 가능 (ArchUnit + package-private). Modulith 가 유일 방법이라는 뜻 아님 |
|
|
| KAKAOBANK-MOD-C3 | 카카오뱅크 팀은 Spring Modulith 를 "체리픽" 하여 도입함 — 전면 채택이 아닌 선택적 사용 | [§Spring Modulith 선택 이유] "Spring Modulith는 저희 팀의 요구에 맞춰 유연하게 모듈을 관리하고 경계를 설정할 수 있는 강력한 도구로, 사용해볼 만한 가치가 충분히 있다고 판단했습니다" | `company-case-study` | Spring Boot 3.x 환경 + 점진 도입 의사가 있는 팀 | Spring 공식 라이브러리이지만 "공식 best practice" 가 아님 — 사례임을 본문에 명시. 모든 금융권 팀에 적용 가능하다는 일반화 금지 |
|
|
| KAKAOBANK-MOD-C4 | 카카오뱅크는 Gradle 멀티모듈 + 헥사고날 아키텍처 위에 Modulith 를 추가 — 어플리케이션 / 어댑터 물리 분리 + Port 인터페이스 통신 | [§헥사고날 통합] "Gradle 멀티모듈을 이용한 헥사고날 아키텍처를 적용하여 애플리케이션 계층과 어댑터 계층을 물리적으로 분리하고, Port 인터페이스로만 통신하여 외부 의존성으로부터 도메인을 보호하는 구조" | `company-case-study` | 멀티모듈 + 헥사고날 기반 프로젝트 | Modulith 단독으로 헥사고날을 강제하지 않음 — 이 사례에서는 기존 헥사고날 위에 modulith 를 얹은 것 |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `KAKAOBANK-MOD-C1` ~ `C4`: 카카오뱅크 팀의 modulith 도입 동기와 구조 패턴 (캡슐화 + Public API, Gradle 멀티모듈 + 헥사고날 + Modulith 3중 스택)
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- 모듈러 모놀리스가 MSA 대비 운영 성능이 우월하다는 일반화
|
|
- "금융권 표준" 또는 "Spring 공식 best practice" — 카카오뱅크 single team 사례에 불과
|
|
- prod 트래픽 / 인시던트 / 측정값 — 본문에 numeric metrics 없음
|
|
- 이 구조가 ca-tmpl 의 single-module feature-first 보다 운영 성능에서 우월하다는 비교 데이터
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 single-module feature-first 에서 Spring Modulith 로 전환 시의 마이그레이션 비용
|
|
- ArchUnit 기반 경계 검증 vs Spring Modulith verifier 의 기능 비교
|
|
- Spring Boot 3.x 호환성 (ca-tmpl 의 현재 Spring 버전 확인 필요)
|
|
|
|
## 메모 / Notes
|
|
|
|
- 적용 시나리오: 수신상품처럼 도메인 경계가 명확하지만 별도 service 분리는 시기상조인 금융 도메인.
|
|
- 장점: Spring 공식 라이브러리라는 신뢰. ArchUnit 기반 경계 검증을 무료로 얻음. 추후 MSA 분리 비용 ↓.
|
|
- 단점: Spring Boot 3.x 필요. 도메인 모델링이 미흡하면 모듈 분리가 오히려 부담.
|
|
- ca-tmpl(feature-first)와의 차이: 카카오뱅크는 **Gradle 멀티모듈 + Hexagonal + Spring Modulith** 3중 스택. ca-tmpl 은 단일 모듈 + feature 패키지 + (Modulith 미적용). 경계 강제 강도: 카카오뱅크 > ca-tmpl. ca-tmpl 의 자연스러운 진화 방향이 이 사례.
|
|
- 신뢰도: `company-tech-blog` / `company-case-study` — 사례로 사용. **"금융권 표준" 으로 격상 금지**.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 raw:
|
|
- [[raw/company-tech-blogs/onion-allegro-tech-blog-2023]]
|
|
- [[raw/company-tech-blogs/domain-woowahan-ddd-aggregate-techblog]]
|
|
- 인용하는 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]] (§19, §20)
|
|
- 대안 그룹: **Topic 1 — Architecture Layout** (대안 5종: feature-first / layer-first / hexagonal / modulith / onion) — 본 자료는 대안 3 (modulith)
|
|
- 인용한 wiki 요약: (미작성)
|