모놀리식 vs 마이크로서비스 선택은 기술이 아니라 팀 규모의 문제다. CNCF 2025 조사에서 마이크로서비스를 도입한 팀의 42%가 일부 서비스를 다시 통합 방향으로 돌렸다. 이유는 하나다. 팀이 감당할 수 있는 복잡도를 넘겼기 때문이다.
결론부터 말하면 코드 아키텍처보다 지금 팀이 몇 명인지가 더 정확한 판단 기준이다.
실무에서 면접 준비를 하거나 사이드 프로젝트를 막 시작하는 시점에 이 질문이 자주 나온다. “MSA 써야 하나요?” 그 대답을 팀 규모 기준으로 정리한다.
모놀리식 아키텍처: 코드베이스 하나에 다 넣는 방식
모놀리식 아키텍처는 애플리케이션의 모든 기능이 하나의 코드베이스 안에 들어있는 방식이다. 프론트엔드, 비즈니스 로직, 데이터 접근 계층이 단일 프로세스로 함께 실행된다.
배포는 간단하다. 코드를 빌드하고 서버에 올리면 끝이다. DB도 하나, 로그도 한 곳에서 본다. 로컬에서 실행하는 방식이 운영 환경과 거의 같다.
단점은 규모가 커질수록 두드러진다. 버튼 하나를 수정해도 전체를 다시 빌드하고 배포해야 한다. 하나의 서비스가 메모리를 과점하면 전체 애플리케이션이 영향을 받는다. 코드베이스가 30만 줄을 넘어가면 새 팀원이 온보딩하는 데 몇 주가 걸린다.
마이크로서비스: 기능별로 쪼개서 독립 운영
마이크로서비스 아키텍처(MSA)는 기능별로 작은 서비스를 분리해서 각자 독립적으로 배포하고 운영하는 방식이다. 결제 서비스, 알림 서비스, 사용자 서비스가 각각의 프로세스와 DB를 갖고, REST API나 메시지 큐로 통신한다.
장점은 명확하다. 트래픽이 몰리는 서비스만 스케일아웃할 수 있고, 특정 서비스에 장애가 나도 전체 시스템이 다운되지 않는다. 팀이 서비스 단위로 독립적인 배포 주기를 가져갈 수 있어서 대규모 조직에서 개발 속도가 빨라진다.
그런데 이 모든 장점은 전제 조건이 있다. DevOps 인프라가 갖춰져 있어야 하고, 분산 시스템을 운영할 수 있는 팀 역량이 있어야 한다. 서비스 간 통신 장애를 추적할 수 있는 분산 트레이싱 도구, 컨테이너 오케스트레이션 경험, 서비스 메시에 대한 이해가 필요하다.
모놀리식 vs 마이크로서비스: 핵심 차이 비교
| 구분 | 모놀리식 | 마이크로서비스 |
|---|---|---|
| 배포 | 전체 재배포 | 서비스별 독립 배포 |
| 확장 | 전체 확장 | 서비스별 개별 확장 |
| 장애 격리 | 전체 영향 | 해당 서비스만 격리 |
| 운영 복잡도 | 단순 | 높음 |
| 초기 개발 속도 | 빠름 | 느림 |
| 통신 방식 | 내부 함수 호출 | HTTP·gRPC·메시지 큐 |
| 적합한 팀 규모 | 10명 이하 | 50명 이상 |
판단 기준: 팀 규모와 비즈니스 단계가 전부다
판단 기준은 단순하다. 팀 규모로 결정하면 된다.
개발자 10명 이하: 모놀리식으로 시작한다. MSA의 운영 복잡도는 팀 리소스를 소모하고, 피처 개발 속도를 20~40% 떨어뜨린다. Shopify는 280만 줄짜리 Ruby 모놀리스로 블랙프라이데이에 분당 3,200만 요청을 처리한다. 팀이 작아도 모놀리식으로 충분히 대규모 트래픽을 감당할 수 있다.
개발자 10~50명: 모듈러 모놀리스(Modular Monolith)를 고려할 시점이다. 단일 배포를 유지하면서 내부 코드를 도메인별 모듈로 분리하는 방식이다. 마이크로서비스의 구조적 이점과 모놀리식의 운영 단순함을 동시에 가져갈 수 있다.
개발자 50명 이상 + DevOps 역량 갖춘 후: 그때 마이크로서비스를 검토한다. 쿠팡이 모놀리식에서 MSA로 전환에 성공한 건 충분한 팀 규모와 DevOps 인프라가 갖춰진 시점이었기 때문이다.
흔한 실수: MSA가 만능이라는 착각
Martin Fowler는 말했다. “모놀리식으로 관리하기에 너무 복잡한 시스템이 아니라면 마이크로서비스는 고려조차 하지 말라.”
MSA 도입 비용은 생각보다 크다. 동등한 기능 구현에 모놀리식 대비 3.75~6배의 인프라 비용이 드는 경우가 있다. 컨테이너 오케스트레이션, API 게이트웨이, 분산 트레이싱 도구, 서비스 디스커버리, 분산 DB 관리가 모두 추가된다.
MVP를 만드는 스타트업이나 사이드 프로젝트에 MSA를 적용하는 건 오버 엔지니어링이다. 아키텍처에 쓸 시간과 리소스로 실제 제품을 더 빠르게 만드는 게 맞다.
실제로 5명 팀이 MSA를 도입했다가 서비스 간 인증 토큰 전파 문제를 디버깅하는 데 2주를 날린 사례가 있다. 모놀리식이었다면 로컬에서 바로 재현하고 한 시간 안에 끝났을 문제였다. MSA의 장애 격리는 운영 중인 대규모 서비스에서 빛나는 것이지, 아직 사용자도 없는 MVP에서는 그냥 복잡도다.
자주 묻는 질문
Q. 사이드 프로젝트는 어떤 아키텍처를 써야 하나요?
모놀리식으로 시작한다. 혼자 또는 소수가 운영하는 프로젝트에서 MSA의 운영 복잡도는 득보다 실이 크다. 서비스가 성장해서 특정 기능에 병목이 생기면 그때 해당 부분만 분리하는 게 현실적이다.
Q. 모놀리식에서 MSA로 언제 전환해야 하나요?
세 가지 신호가 동시에 나타날 때다. 첫째, 팀이 50명 이상으로 성장했을 때. 둘째, 특정 기능의 배포 주기가 다른 기능에 발목을 잡기 시작할 때. 셋째, 특정 서비스만 집중 스케일아웃이 필요할 때. 이 중 하나만 해당된다면 아직 전환 시점이 아니다.
Q. 모듈러 모놀리스가 뭔가요?
단일 배포를 유지하면서 내부 코드를 도메인 기준으로 엄격하게 분리한 방식이다. 결제 모듈, 사용자 모듈, 알림 모듈이 각자 자기 영역 밖의 코드를 직접 호출하지 않는 규칙을 지킨다. MSA 전환의 중간 단계로 쓰거나, 그 자체로 최종 아키텍처로 유지하는 팀이 늘고 있다.
한줄 정리: 모놀리식으로 시작하고, 팀이 50명을 넘고 DevOps가 갖춰진 후에 마이크로서비스를 검토하라.