모놀리스는 죄가 아니다. 이유 없는 분산이 죄다

 

1️⃣ 모놀리스가 “죄”로 오해받는 이유

대부분 이 상태를 모놀리스라고 부릅니다.

• 레이어 무너짐
• 도메인 경계 없음
• 공통 모듈 난사
• 변경 영향 범위 예측 불가
• 배포 공포증

👉 이건 모놀리스가 아니라 무질서입니다.

---

2️⃣ 잘 만든 모놀리스의 특징

제대로 된 모놀리스는 이렇습니다.

• 도메인 경계 명확 (패키지/모듈)
• 내부는 이미 분산을 가정한 구조
• DB 트랜잭션 일관성 확보
• 단일 배포, 단일 장애 지점
• 디버깅/롤백 빠름

👉 운영·개발·장애 대응 비용이 가장 낮은 형태입니다.

---

3️⃣ 이유 없는 분산이 시작되는 순간

다음 중 하나라도 나오면 경고입니다.

• “요즘은 다 MSA라서요”
• “확장성 대비죠” (트래픽 없음)
• “클라우드니까요”
• “나중에 클 줄 알아서요”

현실:

• 서비스 수만 늘어남
• 네트워크 실패 도입
• 트랜잭션 파괴
• 장애 전파
• 관측 비용 폭증

👉 문제 해결 없이 복잡도만 증가

---

4️⃣ 분산은 ‘문제 비용’이 ‘분산 비용’을 넘을 때만

분산의 정당한 이유는 매우 명확합니다.

조건설명

팀 분리 필요	배포/책임 독립
스케일 차이	특정 도메인만 트래픽 폭증
장애 격리	한 영역 죽어도 전체 생존
기술 이질성	언어/런타임 분리 필요

이 중 하나도 없으면 분산하면 안 됩니다.

---

5️⃣ 가장 위험한 패턴

“모놀리스 → MSA 전환 프로젝트”

이건 거의 항상:

• 일정 지연
• 기능 정체
• 품질 하락
• 인력 소모

정답은:

• 모듈형 모놀리스 → 필요 지점만 분리
• 추출 대상은 이미 내부적으로 느슨해야 함

---

6️⃣ 좋은 아키텍처 판단 문장

“이 분산이 사라지면, 우리가 잃는 건 무엇인가?”

• 아무것도 없음 → ❌ 분산 오버엔지니어링
• 팀 속도/안정성/독립성 → ⭕ 정당한 분산

---

한 줄 요약

모놀리스는 기본값이다.
분산은 ‘대가를 감당할 준비가 되었을 때만’ 쓰는 옵션이다.