모듈러 모놀리스 (Modular Monolith)

한 줄 정의

물리적인 네트워크 경계 없이, 단일 배포 단위 내에서 언어/프레임워크 수준 및 정적 도구를 통해 도메인 간 결합도를 차단하고 의존성 경계를 강제하는 소프트웨어 아키텍처 패턴이다.

핵심 요지

에이전트 컨텍스트 경제학 (Context Economics): AI 에이전트가 코드를 한 줄 수정하기 위해 소모하는 입력 토큰 대비 출력 토큰의 비율은 약 166:1(arXiv 2604.22750)에 달한다. 파편화된 분산 아키텍처(마이크로서비스)는 에이전트가 읽어야 할 메타데이터와 API 결합 정보를 폭증시켜 정보의 신호 대 잡음비(SNR)를 떨어뜨리고 API 환각을 초래한다.
의미적 지도(Semantic Map) 제공: 모듈러 모놀리스는 단일 리포지토리 안에서 컴파일러와 툴킷에 의해 검증된 의존성 그래프를 에이전트에게 제공한다. 이를 통해 에이전트는 환각 없이 이웃 도메인의 결합 관계를 인지할 수.
빌드 시점 강제(Build-time Enforcement): 기존 스파게티 모놀리스의 위험은 개발자 간의 구두 약속이 아니라 정적 린팅 및 컴파일러 도구를 사용하여 도메인 경계를 빌드 파이프라인에서 기계적으로 차단함으로써 예방한다.

상세

1. 마이크로서비스의 인간 인지 한계 극복과 에이전트 시대의 병목 변화

마이크로서비스의 본질: 마이크로서비스는 기술적 필요가 아닌 콘웨이의 법칙(Conway’s Law)과 인간 개발자들의 인지 부하(Two-Pizza Team 규모)를 쪼개기 위한 조직론적 해결책이었다.
에이전트 시대의 새로운 병목: 2026년 에이전틱 엔지니어링 시대에는 5초 안에 100개 파일을 읽는 에이전트가 협업하지만, 에이전트에게는 **컨텍스트 윈도우(Context Window)**라는 새로운 인지 한계가 존재한다. 아키텍처가 지나치게 파편화되면 에이전트가 다중 리포지토리를 참조하며 환각을 겪는 에이전트를 동반한 분산 모놀리스(Distributed Monolith with Agents) 현상이 발생한다.

2. 에이전트를 위협하는 3대 인지 병목

컨텍스트 부패 (Context Rot): 무분별하게 넓은 컨텍스트를 제공하면 중독(환각 누적), 주의 산만, 혼란, 충돌 등의 인지 왜곡이 누적되어 결과물의 품질이 저하된다.
중간 유실 (Lost in the Middle): 컨텍스트 범위가 길어질수록 모델은 중간에 위치한 클래스/함수의 흐름을 정확히 읽지 못하는 U자형 성능 하락 곡선을 나타낸다 (TACL 2024).
내비게이션 역설 (Navigation Paradox): 복잡한 코드 의존성 속에서 명확한 전체 의미 지도를 확보하지 못한 에이전트는 컨텍스트 윈도우가 크더라도 약 23.2%포인트 가량 낮은 정답률을 보였다 (2026년 2월 측정 결과).

3. 언어 생태계별 빌드 강제 도구

모듈러 모놀리스의 핵심은 패키지 경계를 넘나드는 무분별한 참조를 정적으로 차단하는 강제 도구를 적용하는 것이다.

Java (Spring Modulith): 모듈 간의 외부 API 호출을 제외한 내부 패키지 무단 접근을 런타임/테스트 시점에 기계적으로 차단한다.
Ruby (Packwerk): Shopify에서 공개한 정적 분석 도구로, 노후화된 코드베이스에서 모듈 경계 선언을 검증한다.
Python (import-linter / Tach): 소스코드 내 Import 구문의 방향을 정적으로 파싱해 아키텍처 독립 규칙을 지키게 한다.
Go (Go internal/): go 컴파일러 자체의 internal/ 디렉터리 규칙을 사용해 컴파일 단계에서 경계를 보장한다.

4. 마이크로서비스 도입을 위한 4대 전제조건

SAM NEWMAN 등 마이크로서비스 권위자들은 이를 최후의 보루로 간주해야 한다고 제언한다. 다음 4대 조건이 모두 충족되지 않으면 마이크로서비스 대신 모듈러 모놀리스를 기본값으로 삼아야 한다.

내부 개발자 플랫폼(IDP, Internal Developer Platform) 및 MCP: 통합 배포, 로깅, API 레지스트리 표준이 자동화되어 에이전트에게 일관된 호출 정보를 줄 수 있는가.
독립된 도메인 경계: 새로운 기능 구현 시 60% 이상의 결합이 단일 도메인 내에서 처리되며 3개 이상의 서비스를 넘나들지 않는가.
비대칭적 물리 스케일링: 특정 모듈(예: GPU 추론, 대규모 배치 연산)의 하드웨어 스케일 격리가 비즈니스상 필수적인가.
전담 플랫폼 엔지니어링 조직: 배포 오버헤드를 흡수할 수 있는 2~4명 수준의 전업 인프라 전문가 팀이 존재하는가.

예시

모듈러 모놀리스 구조 예시:

my-app/
├── internal/
│   ├── billing/          # 결제 도메인 (internal 구조로 외부 노출 최소화)
│   │   ├── api/          # 외부 모듈에서 호출 가능한 공식 API
│   │   └── db/           # billing의 스키마 격리
│   ├── order/            # 주문 도메인
│   └── shipping/         # 배송 도메인
├── go.mod
└── main.go

Shopify의 모노리포 전환: 280만 줄의 Ruby 코드로 구성된 단일 모듈러 모놀리스 아키텍처를 유지하며, Packwerk을 통해 도메인 경계를 유지하고 블랙 프라이데이 등의 분당 30테라바이트 트래픽 부하를 성공적으로 소화했다.

충돌

전통적 마이크로서비스 맹신 vs 컨텍스트 경제학:
- 기존 주장: 넷플릭스, 아마존 등의 성공 사례에 따라 빠른 기동 및 수평 확장을 위해 처음부터 서비스를 작게 쪼개야 한다.
- 반박 (2026년 기준): 인적 자원의 결합 오버헤드와 AI 에이전트의 컨텍스트 비용 낭비(166:1 비율)로 인해, IDP 플랫폼이 성숙하지 않은 상태에서의 서비스 분할은 인프라 오버헤드를 3.75배~6배 증가시키는 ‘분산 모놀리스’로의 퇴보를 야기한다.
- 확인 날짜: 2026-06-12 확인 (출처: raw/마이크로서비스 대신 모듈러 모놀리스 — AI 에이전트가 코드를 읽기 시작했을 때 바뀐 것들.md)

LLM Wiki

탐색기

모듈러 모놀리스