8.7 KiB
8.7 KiB
title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_branches | related_projects | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MSA로의 여정에서 만난 Spring Modulith 체리픽 해본 후기 (카카오뱅크) | company-tech-blog | https://tech.kakaobank.com/posts/2507-legacy-to-modular-monolith-with-spring-modulith/ | raw | medium |
|
|
|
2026-05-22 | 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:
- 인용하는 branch:
- 인용하는 project:
- 대안 그룹: Topic 1 — Architecture Layout (대안 5종: feature-first / layer-first / hexagonal / modulith / onion) — 본 자료는 대안 3 (modulith)
- 인용한 wiki 요약: (미작성)