Modular Monolith vs Microservice — 왜 나는 먼저 모놀리스를 고른다

한 줄 결론

나는 기본적으로 먼저 Modular Monolith를 고른다. 마이크로서비스는 확장 전략이지, 시작 전략이 아니다.

마이크로서비스는 듣기 좋다.

하지만 현실의 초기 제품에서 중요한 문제는 보통 이것이 아니다.

이런 상황에서 마이크로서비스는 해결책이 아니라, 복잡도 선반입이 되기 쉽다.

마이크로서비스는 코드만 나누는 것이 아니다.

다 같이 생긴다.

즉 “서비스를 나눴다”는 말은 사실상 운영 문제를 여러 개로 늘렸다는 뜻이다.

Modular Monolith는 하나의 배포 단위를 유지한다. 대신 내부 구조를 모듈 경계로 강하게 나눈다.

즉,

이게 좋은 이유는, 서비스 경계 실험을 코드 구조 안에서 먼저 해볼 수 있기 때문이다.

초기 제품의 제일 큰 병목은 보통 인프라가 아니라 기능 완성과 반복 속도다.

배포가 하나면:

초기에 마이크로서비스로 나누면, 나중에 잘못 자른 경계를 다시 합치기 어렵다.

반면 모놀리스 안에서 모듈 경계를 먼저 잡으면, 실제 사용 패턴을 보면서 “정말 분리할 가치가 있는가”를 판단할 수 있다.

작은 팀이 마이크로서비스를 운영하면 서비스 개수보다 운영 부담이 먼저 터진다.

2~5명 팀에 여러 서비스는 멋져 보일 수는 있어도, 유지 비용이 크다.

나는 마이크로서비스를 반대하지 않는다. 다만 조건이 있다고 본다.

이 조건이 모이지 않았는데 먼저 나누면, 대부분은 오버엔지니어링이다.

내가 DAEMON 구조에서 강조하는 것은 “지금 필요한 복잡도만 가져온다”는 태도다.

그래서 기본은 이렇다.

즉 내부는 모듈화하되, 운영은 단순하게 유지한다.

이게 내가 생각하는 현실적인 출발점이다.

마이크로서비스는 목적이 아니라 수단이다.

대부분의 경우 좋은 시작은 이렇게 정리된다.

내 기준에서 좋은 아키텍처는 화려한 아키텍처가 아니라, 지금 필요한 문제를 가장 적은 복잡도로 푸는 아키텍처다.