티스토리 뷰
서비스 구조를 고민할 때 가장 자주 나오는 질문 중 하나가 바로 모놀리식(Monolithic)과 MSA(Microservices Architecture) 중 무엇을 선택해야 하느냐는 점입니다.
처음에는 단순히 “옛날 방식 vs 최신 방식”처럼 보일 수 있지만, 실제로는 그렇게 단순하지 않습니다. 오히려 많은 팀이 서비스 규모, 팀 구조, 배포 방식, 장애 대응 능력을 충분히 고려하지 않은 채 구조를 선택해서 오히려 더 힘들어지는 경우도 많습니다.
이번 글에서는 모놀리식과 MSA가 각각 무엇인지, 어떤 차이가 있는지, 왜 많은 회사가 MSA를 말하는지, 그리고 실제로는 어떤 상황에서 어떤 구조를 선택하는 것이 더 현실적인지까지 흐름대로 정리해보겠습니다.
모놀리식 아키텍처는 말 그대로 하나의 큰 덩어리처럼 애플리케이션이 구성된 구조입니다.
예를 들어 쇼핑몰 서비스를 만든다고 해보겠습니다. 회원, 상품, 주문, 결제, 관리자 기능이 있다고 할 때, 모놀리식 구조에서는 이 기능들이 보통 하나의 프로젝트, 하나의 코드베이스, 하나의 배포 단위 안에 들어갑니다.
쉽게 말하면,
기능은 여러 개지만, 운영 관점에서는 하나의 애플리케이션처럼 움직이는 구조
라고 이해하면 됩니다.
간단한 Spring Boot 서비스 하나에 Controller, Service, Repository, DB 연동이 모두 들어있는 형태를 떠올리면 이해가 쉽습니다.
[하나의 애플리케이션]
├─ 회원 기능
├─ 상품 기능
├─ 주문 기능
├─ 결제 기능
└─ 관리자 기능
이 방식은 개발을 시작할 때 매우 자연스럽습니다. 구조가 단순하고, 로컬에서 띄우기도 쉽고, 기능 간 호출도 네트워크 통신이 아니라 내부 메서드 호출로 처리되는 경우가 많아 구현 속도도 빠릅니다.
MSA는 Microservices Architecture의 약자입니다. 하나의 큰 시스템을 여러 개의 작은 서비스로 나누고, 각각을 독립적으로 개발·배포·운영하는 구조를 뜻합니다.
예를 들어 같은 쇼핑몰 서비스라도 MSA에서는 다음처럼 나눌 수 있습니다.
[회원 서비스] [상품 서비스] [주문 서비스] [결제 서비스]
│ │ │ │
└──── API / 메시지 / 이벤트 기반으로 서로 통신 ────┘
즉, 기능이 하나의 프로젝트 안에 함께 있는 것이 아니라 서비스별로 분리되어 각자 실행될 수 있습니다.
이 구조의 핵심은 단순 분리가 아닙니다.
- 서비스별 독립 배포 가능
- 서비스별 기술 선택 가능
- 서비스별 장애 영향 분리 가능
- 서비스별 확장(스케일링) 가능
이처럼 독립성이 MSA의 가장 큰 특징입니다.
다만 여기서 중요한 점이 있습니다. 서비스만 쪼갠다고 자동으로 MSA가 잘 되는 것은 아닙니다. 오히려 서비스 사이의 통신, 데이터 일관성, 배포 자동화, 로그 추적, 장애 대응 같은 운영 난도가 크게 올라갑니다.
여기서 꼭 봐야 할 포인트는 MSA가 모놀리식보다 무조건 상위 구조가 아니라는 점입니다. MSA는 분명 강력한 장점이 있지만, 그 장점은 보통 운영 체계와 팀 역량이 함께 갖춰졌을 때 비로소 제대로 살아납니다.
MSA가 자주 언급되는 데에는 분명한 배경이 있습니다.
첫째, 서비스가 커지면 하나의 거대한 코드베이스를 유지하는 부담이 커집니다. 특정 기능을 수정했는데 전혀 다른 영역까지 함께 테스트하고 배포해야 한다면 속도가 떨어질 수밖에 없습니다.
둘째, 팀 규모가 커질수록 영역 분리가 중요해집니다. 주문 팀, 결제 팀, 회원 팀이 동시에 작업하는데 모두가 같은 애플리케이션 배포에 묶여 있으면 충돌이 잦아질 수 있습니다.
셋째, 특정 기능만 트래픽이 높아지는 경우가 생깁니다. 예를 들어 상품 조회는 매우 많지만 관리자 기능은 거의 사용되지 않을 수 있습니다. 이런 상황에서는 서비스별로 분리해 필요한 부분만 확장하는 것이 효율적일 수 있습니다.
정리하면 MSA는 다음 상황에서 매력이 커집니다.
- 서비스 기능이 많고 빠르게 커지는 경우
- 조직이 커져 팀 단위 분리가 필요한 경우
- 배포를 더 자주, 더 독립적으로 하고 싶은 경우
- 특정 도메인만 집중 확장해야 하는 경우
- 장애 영향 범위를 더 세밀하게 나누고 싶은 경우
모놀리식은 종종 구식처럼 오해받지만, 실제로는 매우 현실적이고 강력한 선택입니다. 특히 아래 상황에서는 모놀리식이 더 적합한 경우가 많습니다.
- 서비스 초기 단계라 빠른 출시가 중요한 경우
- 팀 규모가 작고, 한두 팀이 전체 기능을 함께 개발하는 경우
- 도메인이 아직 안정되지 않아 구조가 자주 바뀌는 경우
- CI/CD, 모니터링, 분산 추적 체계가 충분하지 않은 경우
- 서비스 간 경계를 명확히 나누기 어려운 경우
초기 스타트업이나 작은 팀에서는 속도가 중요합니다. 이때 지나치게 이른 MSA 전환은 오히려 개발 속도를 늦출 수 있습니다. 서비스 간 API 설계, 인증, 장애 처리, 통신 실패 대응, 데이터 분리까지 모두 고민해야 하기 때문입니다.
즉,
“작고 빠르게 검증해야 하는 단계”라면 모놀리식이 단순하고 효율적인 경우가 많습니다.
입니다.
MSA는 다음과 같은 상황에서 장점이 더 분명하게 드러납니다.
- 서비스가 이미 커져서 하나의 코드베이스 관리가 버거운 경우
- 팀이 여러 개로 나뉘어 독립 개발·독립 배포가 필요한 경우
- 특정 서비스만 빠르게 확장해야 하는 경우
- 장애 영향을 서비스 단위로 나누는 것이 중요한 경우
- 배포 주기가 매우 짧고 기능별 변경 속도가 다른 경우
예를 들어 결제 서비스는 안정성이 중요하고 변경 속도가 느리지만, 추천 서비스는 실험이 많아 배포가 잦을 수 있습니다. 이런 경우 모든 기능을 한 번에 묶어 배포하는 것보다 분리 운영이 더 유리할 수 있습니다.
다만 여기서도 전제 조건이 있습니다.
- 서비스 경계가 어느 정도 명확해야 하고
- 배포 자동화 체계가 어느 정도 있어야 하며
- 로그 수집, 모니터링, 장애 대응 체계가 뒷받침되어야 합니다.
즉 MSA는 구조만 바꾸는 일이 아니라 개발 문화와 운영 체계를 함께 바꾸는 일에 가깝습니다.
많은 분들이 MSA를 떠올릴 때 “서비스를 나누면 더 깔끔하겠지”라고 생각합니다. 그런데 실제 난관은 분리 이후에 시작됩니다.
대표적으로 아래 문제가 자주 나옵니다.
- 서비스 간 통신 실패
내부 메서드 호출이 아니라 네트워크 호출이 되므로 지연, 타임아웃, 재시도, 장애 전파를 고려해야 합니다. - 데이터 일관성 관리
하나의 트랜잭션으로 깔끔하게 처리하던 일이 서비스 분리 후에는 더 복잡해질 수 있습니다. - 운영 포인트 증가
애플리케이션 하나를 보던 것에서 여러 서비스의 로그, 메트릭, 배포 상태를 동시에 봐야 합니다. - 로컬 개발 환경 복잡화
회원 서비스, 주문 서비스, 결제 서비스, 메시지 브로커, API Gateway 등을 함께 띄워야 할 수 있습니다. - 조직 역량 부족
구조는 MSA인데 실제 운영 문화와 협업 체계가 모놀리식 시절 그대로라면 오히려 혼란이 커질 수 있습니다.
- 서비스를 나눌 만큼 도메인 경계가 명확한가?
- 배포 자동화와 모니터링 체계가 준비되어 있는가?
- 분산 환경 장애를 감당할 운영 여력이 있는가?
- 지금 문제의 본질이 정말 “구조” 문제인가?
이 질문에 명확히 답하기 어렵다면, 당장 MSA가 꼭 필요한 단계는 아닐 수도 있습니다.
구조 선택은 “어느 기술이 더 멋진가”의 문제가 아니라 “지금 우리에게 필요한가”의 문제입니다. 아래 항목으로 판단하면 조금 더 현실적으로 볼 수 있습니다.
이 표를 보면 알 수 있듯이, 구조 선택은 기술 용어 하나로 끝나는 문제가 아닙니다. 서비스 단계, 팀 규모, 운영 수준이 함께 맞물려야 더 적절한 선택이 나옵니다.
조금 더 깊게 보면, 모놀리식 vs MSA의 핵심은 단순히 애플리케이션 개수를 나누는 문제가 아닙니다. 더 중요한 것은 도메인 경계(boundary)를 어떻게 정의하느냐입니다.
예를 들어 주문과 결제를 나눈다고 했을 때,
- 어디까지가 주문 책임인지
- 결제 실패 시 주문 상태를 어떻게 처리할지
- 데이터 소유권은 어느 서비스가 가지는지
- 동기 호출과 비동기 이벤트 중 무엇을 쓸지
같은 질문에 답할 수 있어야 실제로 서비스 분리가 의미를 가집니다.
반대로 이런 경계가 불명확한 상태에서 무리하게 MSA를 도입하면, 내부 메서드 호출이 API 호출로 바뀌기만 하고 구조적 이점은 얻지 못할 수 있습니다.
이 관점에서 보면,
- 잘 설계된 모놀리식은 충분히 강력할 수 있고
- 경계가 불명확한 MSA는 생각보다 운영 비용만 높을 수 있습니다.
그래서 실제로는 처음부터 완전한 MSA로 가기보다, 모듈화가 잘된 모놀리식으로 시작한 뒤, 경계가 명확해지는 영역부터 점진적으로 분리하는 접근이 자주 추천됩니다.
실무 관점에서 아주 과하게 말하지 않고 정리하면, 보통은 아래처럼 접근하는 것이 무난합니다.
- 처음부터 거대한 MSA를 목표로 하기보다 모듈 구조가 명확한 모놀리식으로 시작한다.
- 기능이 커지면서 특정 도메인이 독립적으로 움직여야 할 필요가 생기면 그때 분리를 검토한다.
- 분리 전에는 반드시 배포 자동화, 로그 수집, 모니터링, 장애 대응 방식을 먼저 점검한다.
- 구조를 바꾸는 이유가 유행 때문인지, 실제 병목 때문인지 구분한다.
즉 지금의 선택이 “최종 구조”일 필요는 없습니다. 서비스는 성장하면서 구조도 바뀔 수 있습니다. 중요한 것은 현재 단계에 맞는 구조로 빠르게 움직이되, 나중에 분리할 수 있게 경계를 의식하며 설계하는 것입니다.
- 오해 1. MSA가 무조건 더 현대적이고 더 좋다.
- 오해 2. 서비스만 나누면 자동으로 확장성과 안정성이 높아진다.
- 오해 3. 모놀리식은 규모가 조금만 커져도 바로 한계에 부딪힌다.
모놀리식과 MSA 중 어느 것이 절대적으로 더 좋다고 말하기는 어렵습니다.
- 빠른 개발, 단순한 운영, 작은 팀이라면 모놀리식이 더 현실적일 수 있습니다.
- 복잡한 도메인, 여러 팀, 독립 배포와 선택적 확장이 중요하다면 MSA가 더 적합할 수 있습니다.
결국 중요한 것은 현재 우리 서비스가 어떤 문제를 겪고 있는지입니다. 구조는 그 문제를 풀기 위한 수단이어야 하지, 목표가 되어서는 안 됩니다.
마지막으로 한 줄로 정리하면 이렇습니다.
초기에는 잘 설계된 모놀리식이 좋은 선택일 수 있고, 성장 이후에는 필요한 영역부터 점진적으로 분리하는 전략이 가장 현실적인 경우가 많습니다.
- REST API란 무엇인가? RESTful 설계 핵심 정리
- 트랜잭션이란 무엇인가? ACID까지 쉽게 이해하기
- ORM이란 무엇인가? JPA 포함 개념 정리와 SQL과의 차이
- 인덱스는 왜 성능을 빠르게 만들까?