개발자 채용 공고를 보면 우대사항에 빠지지 않고 등장하는 단어가 있습니다. 바로 MSA (Microservices Architecture)입니다. 넷플릭스, 아마존 같은 테크 자이언트들이 MSA를 통해 엄청난 트래픽을 감당한다는 성공 사례가 알려지면서, MSA로 구성된 서비스를 많이 접했습니다.
오늘은 제가 느낀 MSA의 핵심 개념과 치명적인 단점, 그리고 현실적인 대안인 Modular Monolith에 대해 알아보겠습니다.
(공부하며 느낀 개인적인 견해의 글입니다..)
1. MSA란 무엇인가?
기존의 전통적인 웹 개발 방식은 Monolithic Architecture(모놀리식 아키텍처)라고 부릅니다. 하나의 거대한 프로젝트 안에 사용자 관리, 주문, 결제, 배송 등 모든 기능이 다 들어있는 형태죠. 반면 MSA는 이 거대한 덩어리를 작고 독립적인 여러 개의 서비스로 쪼개는 것입니다.
- Monolith: 하나의 서버, 하나의 DB. 모든 코드가 얽혀 있음.
- MSA: 'User 서버', 'Order 서버', 'Payment 서버'가 물리적으로 분리됨. 각자 별도의 DB를 가질 수도 있으며, HTTP(REST API)나 gRPC 통신으로 대화함.
2. 왜 MSA를 할까?
MSA가 주는 이점은 명확합니다. "유연함"과 "확장성"입니다.
- 독립적인 배포: 결제 기능을 수정했는데, 전체 서버를 재시작할 필요 없이 '결제 서버'만 배포하면 됩니다.
- 부분 스케일 아웃(Scale-out): 주문은 없는데 조회 트래픽만 폭주한다면? 전체 서버를 늘릴 필요 없이 '조회 서버'만 10대로 늘리면 됩니다. 비용 효율적이죠.
- 장애 격리: 결제 서버가 터져도, 상품 목록 조회는 잘 됩니다. (모놀리스는 하나 터지면 다 죽습니다.)
- 기술 스택의 자유: 회원 서버는 안정적인 Java로, 실시간 알림 서버는 가벼운 Node.js로, 머신러닝 서버는 Python으로 만들 수 있습니다.
3. MSA의 단점 ?
① 복잡도의 폭발 (Complexity)
서버가 1대일 때는 로그 파일 하나만 보면 됐습니다. 서버가 50대가 되면요?
로그 수집(ELK), 모니터링(Prometheus/Grafana), 분산 추적(Zipkin/Jaeger) 등 DevOps 인프라 구축 난이도가 수십 배 올라갑니다.
② 데이터 정합성의 지옥 (No JOIN)
가장 큰 충격은 JOIN을 못 쓴다는 것입니다.
- Monolith:
SELECT * FROM orders JOIN users ON ...(한방 쿼리 끝) - MSA: 주문 서버에서 주문 정보 가져옴 → 유저 ID 확인 → 유저 서버에 API 요청해서 이름 가져옴 → 메모리에서 조합.
- 트랜잭션 관리: 주문은 성공했는데 포인트 차감이 실패하면? DB가 달라서
Rollback이 안 됩니다. Saga Pattern 같은 복잡한 보상 트랜잭션을 구현해야 합니다.
③ 네트워크 지연 (Latency)
함수 호출(메모리 참조)은 0.0001초면 되지만, HTTP 통신은 최소 10~50ms가 걸립니다. 서비스 간 통신이 많아질수록 응답 속도는 느려집니다.
4. Modular Monolith (멀티모듈)
제가 wecam 프로젝트에서 설계했던 domain-common, backend, adminbackend 구조가 바로 이것에 가깝습니다.
(해당 내용은 다른 장에 있습니다!)
https://ye-seul0-0.tistory.com/56
[Spring Boot] 사용자/관리자 API 분리를 위한 멀티모듈 설계 실전 가이드 (Common, User, Admin)
[Spring Boot] 사용자/관리자 API 분리를 위한 멀티모듈 설계 실전 가이드 (Common, User, Admin)백엔드 개발을 하다 보면, 일반 사용자용 API와 관리자용(Back-office) API를 분리해야 할 때가 옵니다. 트래픽 패
ye-seul0-0.tistory.com
| 구분 | Monolith (Spaghetti) | Modular Monolith (Good) | Microservices (MSA) |
|---|---|---|---|
| 코드 구조 | 코드가 뒤엉켜 있음 | 모듈별로 깔끔하게 분리됨 | 물리적으로 다른 서버 |
| 배포 단위 | 하나의 Jar 파일 | 하나의 Jar 파일 | 수십 개의 Jar 파일 |
| 데이터베이스 | 통합 DB | 통합 DB (스키마 분리 가능) | DB 분리 (Database per service) |
| 통신 비용 | 없음 (함수 호출) | 없음 (함수 호출) | 높음 (네트워크 통신) |
| 복잡도 | 낮음 | 중간 | 매우 높음 |
Modular Monolith의 장점
물리적으로는 한 덩어리라서 배포와 관리가 쉽지만, 논리적으로는 모듈이 나뉘어 있어 코드가 깔끔해지는 거 같습니당.
나중에 트래픽이 정말 많아져서 분리해야 할 때, 해당 모듈만 뚝 떼어내서 MSA로 전환하기 쉽습니다.
5. 언제 MSA를 해야 할까?
아래 조건에 해당하지 않는다면, 아직은 Monolith(혹은 멀티모듈)가 정답이라 생각해요
- 개발자가 50명 이상이라 코드 충돌이 너무 잦다.
- 특정 기능(예: 선착순 예매)에만 트래픽이 미친듯이 몰린다.
- 배포가 하루에 수십 번 일어나야 한다.
- 넷플릭스만큼 크다.
"Start with a Monolith, extraction to Microservices only when necessary."
(모놀리스로 시작해라, 정말 필요할 때만 마이크로서비스로 추출해라.)
- 마틴 파울러(Martin Fowler)
6. 느낀 점
- MSA는 서버를 기능별로 잘게 쪼개는 아키텍처다.
- 확장성과 배포 유연성이 좋지만, 복잡도와 데이터 관리 난이도가 극악이다.
- 초기 스타트업이나 중소 규모 프로젝트는 멀티모듈(Modular Monolith) 방식으로 코드의 구조만 잘 잡아도 충분하다.
- 유행을 좇지 말고, 우리 팀의 상황에 맞는 아키텍처를 선택하자!