🧩 MSA 전환과 모놀리식 구조의 차이, 그리고 마이크로서비스 설계 시 고려할 점

최근 시스템 설계나 백엔드 아키텍처 이야기에서 빠지지 않고 등장하는 단어가 바로 "MSA (Microservice Architecture)"이다.
하지만 '좋다더라', '확장성 좋다더라'는 말만 듣고는 정확히 무엇이고, 어떤 장단점이 있는지 파악하기 어렵다.
이번 포스팅에서는 MSA의 개념부터, 모놀리식과의 비교, 그리고 실제로 MSA로 전환할 때 어떤 점을 고려해야 하는지까지 깊이 있게 정리해보려고 한다.

 

---

1️⃣ MSA란 무엇인가?

MSA(Microservice Architecture)는 하나의 시스템을 작고 독립적인 서비스들로 분리하여 운영하는 아키텍처 스타일이다.

각 서비스는 자기만의 도메인, 자기 데이터베이스, 자기 비즈니스 로직을 가지고 서로 API 혹은 메시지로 통신한다.

 

📌 MSA의 핵심 특징

• 작고 독립적인 서비스들로 구성
• 서비스 간 결합도 낮음
• 각 서비스는 독립적으로 배포/스케일링 가능
• 서비스마다 다른 기술 스택 사용 가능 (Polyglot)

📍예시 구조

[사용자 서비스] ─┐
[상품 서비스] ──┼─> [API Gateway] ──> 클라이언트
[주문 서비스] ─┘

 

---

2️⃣ 모놀리식 구조란?

Monolithic Architecture는 하나의 통합된 애플리케이션으로 모든 기능(회원가입, 결제, 상품 등)을 구현한 구조다.

 

📌 모놀리식의 특징

• 모든 기능이 하나의 코드베이스에 있음
• 단일 배포 단위 -> 하나 고치면 전체 빌드 & 배포
• 개발 초기에는 빠르지만, 점점 유지보수가 어려워 

---

3️⃣ MSA vs 모놀리식 구조 비교

항목	모놀리식	MSA
구조	모든 기능을 하나로 통합	기능별로 독립적인 서비스
배포	전체 앱을 함께 배포	서비스 단위로 개별 배포 가능
장애 전파	한 곳 문제 -> 전체 영향	서비스 단위로 격리 가능
확장성	전체 시스템 확장 필요	필요한 서비스만 확장 가능
유지보수	복잡해질수록 어려움	서비스별 책임 분리로 쉬움
학습/운영 난이도	상대적으로 쉬움	설계/운영 복잡도 증가

---

4️⃣ MSA로 전환하게 되는 이유

시스템이 커지고 사용자가 많아질수록 모놀리식은 속도, 유연성, 안정성 면에서 한계를 보이기 시작한다.

그래서 많은 기업이 MSA로의 전환을 선택한다.

 

🔥전환 배경 예시

• 빌드/배포 시간이 너무 오래 걸림
• 기능 하나 수정하려면 전체 시스템 영향 받음
• 특정 기능(예: 주문) 트래픽이 폭주함
• 개발 팀 규모가 커져서 코드 충돌 많아짐
• 서비스 별로 기술 스택을 다르게 가져가고 싶음 

---

5️⃣ MSA 설계 시 고려할 포인트

전환 자체보다 설계의 고민이 훨씬 더 중요하다.

다음 포인트들은 꼭 짚고 넘어가야 한다.

 

✅1. 서비스 분리 기준 (Bounded Context)

• DDD(도메인 주도 설계)를 참고하여 도메인 별로 잘게 쪼갬
• 사용자, 주문, 결제, 알림 등은 대표적인 분리 단위

✅2. 서비스 간 통신 방식

• 동기 HTTP (REST) vs 비동기 메시지 (Kafka 등)
• 동기는 빠르지만 장애 전파 위험 / 비동기는 복잡하지만 유연

✅3. 데이터 분리

• 서비스 간 DB 공유는 절대 금지
• 각 서비스는 자기 DB만 접근해야 함 -> 데이터 일관성 문제는 Eventual Consistency로 해결

✅4. API Gateway 설계

• 외부 요청을 받아 내부 서비스에 라우팅
• 인증, 로깅, 라우팅 처리 역할

✅5. 장애 감지 & 복구

• 서비스 별 모니터링 도입 필요 (Prometheus, Grafana 등)
• Circuit Breaker 패턴으로 장애 전파 방지

✅6. CI/CD 자동화

• 서비스가 많아지면 배포 자동화 없이는 감당 불가
• Jenkins, GitHub Actions, ArgoCD 등으로 배포 파이프라인 구성

---

6️⃣ MSA의 단점과 주의할 점

MSA가 만능은 아니다.

잘못 설계하면 모놀리식보다 더 망할 수도 있다.

 

🚫단점 정리

• 설계 난이도 증가 (서비스 쪼개는 기준이 불명확하면 오히려 혼란)
• 운영 부담 증가 (배포/모니터링 대상 서비스 수가 많음)
• 네트워크 호출 비용 증가 (Latency, 트래픽)
• 트랜잭션 관리 어려움 (분산 트랜잭션 문제)

---

7️⃣ MSA 환경에서 운영 시 대표적으로 발생하는 문제

MSA 환경에서 운영 시 대표적으로 다음과 같은 문제들이 발생할 수 있다.

 

1. 배포 복잡도 증가
   • 서비스가 수십 개 이상으로 늘어나면 수동 배포는 사실상 불가능
   • CI/CD 자동화 도입 (Jenkins, ArgoCD, GitOps) 필수
2. 모니터링/로깅의 단편화
   • 서비스별 로그와 메트릭이 분산되어 있어 장애 분석이 어려움
   • 통합 모니터링 도구 (ELK, Prometheus + Grafana, Zipkin 등) 도입 필요
3. 네트워크 장애 및 타임아웃 이슈
   • 서비스 간 호출이 많아지면 통신 실패나 지연이 발생하기 쉬움
   • Circuit Breaker / Retry / Timeout 정책을 통해 회복력 보완
4. API 버전 관리의 어려움
   • 다양한 클라이언트가 다양한 서비스에 의존할 경우 버전 충돌 가능
   • API Gateway 수준에서 버전 관리 및 호환성 유지 전략 필요
5. 트랜잭션 관리 어려움
   • DB가 분리되면서 분산 트랜잭션 관리가 어려워짐
   • Saga 패턴, Eventual Consistency, Outbox 패턴 등을 활용

---

✅ 마무리

MSA는 단순히 "서비스를 쪼개는 것"이 아니다.
어떻게 나눌 것인지, 통신을 어떻게 할 것인지, 장애에 어떻게 대응할 것인지 등 
전반적인 시스템 아키텍처를 다시 설계하는 수준의 변화다.
그러니까 도입 전에는 반드시 팀 규모, 트래픽 특성, 시스템 복잡도 등을 고려해서
"지금 이 시스템에서 정말 MSA가 필요한가?"를 먼저 점검하는게 필요하다.