📌 서론
MSA(Microservices Architecture)는
많은 SI 프로젝트에서 “정답”처럼 취급됩니다.
하지만 현실은 다릅니다.
- 어떤 팀은 MSA로 속도와 안정성을 얻고
- 어떤 팀은 장애와 복잡성만 얻습니다
같은 기술인데 결과가 다른 이유는 하나입니다.
“도입 방식이 다르기 때문”
📌 1. 실패한 MSA vs 성공한 MSA — 한눈에 비교
항목 실패한 MSA 성공한 MSA
| 출발점 | 기술 | 문제 |
| 서비스 분리 기준 | 임의 | 도메인 |
| 데이터 | 공유 DB | 서비스별 DB |
| 통신 | 복잡 (Kafka 남용) | 단순 → 점진적 |
| 배포 | 불안정 | 자동화 |
| 운영 | 고려 없음 | 모니터링/로그 필수 |
| 팀 구조 | 단일 팀 | 서비스별 책임 |
📌 2. 실패 사례: “일단 쪼개고 보자”
상황
“모놀리식은 구식입니다”
“MSA로 가야 합니다”
“MSA로 가야 합니다”
👉 바로 서비스 분리
- user-service
- order-service
- payment-service
- notification-service
결과
- 서비스 간 호출 지옥 (N+1 호출)
- 트랜잭션 깨짐
- 장애 전파
- 디버깅 불가
핵심 문제
❌ 도메인 설계 없이 분리
한 줄 요약
쪼갠다고 MSA가 아니다
📌 3. 실패 사례: “Kafka부터 도입”
상황
- 이벤트 기반 해야 한다고 해서 Kafka 도입
결과
- 메시지 흐름 이해 불가
- 장애 발생 시 추적 불가
- 중복 처리 / 멱등성 문제
핵심 문제
❌ 동기 설계도 안 된 상태에서 비동기 도입
한 줄
비동기는 난이도를 올리는 기술이다
📌 4. 성공 사례: “모놀리식에서 점진적 분리”
상황
- 기존 Spring Boot 모놀리식
접근
- 도메인 분리 (패키지 레벨)
- 경계 식별 (Bounded Context)
- 트래픽 높은 영역만 분리
결과
- user / payment / search 분리
- 나머지는 그대로 유지
핵심
✔ 필요할 때만 분리
📌 5. 성공 사례: “운영부터 설계”
접근
MSA 도입 전에 먼저 준비
- 로그 (ELK / OpenSearch)
- 모니터링 (Prometheus / Grafana)
- tracing (Zipkin)
결과
- 장애 위치 즉시 파악
- 서비스 간 흐름 추적 가능
핵심
✔ MSA는 개발이 아니라 운영 아키텍처
📌 6. 성공 사례: “데이터 분리 원칙 준수”
실패 구조
모든 서비스 → 하나의 DB
👉 사실상 모놀리식
성공 구조
user DB
order DB
payment DB
order DB
payment DB
👉 서비스 독립성 확보
핵심
✔ DB가 분리되어야 진짜 MSA
📌 7. 실무 기준: MSA 도입 체크리스트
✔ 도입하면 안 되는 경우
- 트래픽 낮음
- 팀 규모 작음
- 운영 경험 없음
- 단순 CRUD 시스템
✔ 도입해도 되는 경우
- 트래픽 증가
- 서비스별 확장 필요
- 장애 격리 필요
- 팀 분리 가능
📌 8. 가장 중요한 차이
실패 vs 성공의 차이는 하나입니다.
실패
기술 → 구조 → 문제
성공
문제 → 구조 → 기술
📌 결론
MSA는 좋은 기술이 아닙니다.
조건이 맞을 때만 좋은 기술입니다
📌 마무리 한 줄
MSA는 성능을 위한 기술이 아니라
복잡성을 감당할 수 있을 때만 쓰는 기술이다
LIST
'Software > Maker(Spring & Python & node)' 카테고리의 다른 글
| SI 산출물은 왜 따로 노는가 — 요구사항부터 테스트까지 ‘연결’로 설계하는 방법 (0) | 2026.03.23 |
|---|---|
| SI 프로젝트 산출물의 본질 — 요구사항부터 테스트까지, 제대로 만드는 기준 (0) | 2026.03.23 |
| SI 프로젝트에서 기술 선택이 실패하는 이유 — 현장에서 반복되는 5가지 패턴 (0) | 2026.03.23 |
| “기술을 선택하기 전에 반드시 던져야 할 3가지 질문 — 생존하는 아키텍처의 기준” (0) | 2026.03.23 |
| 테스트 격리란 무엇인가요? (0) | 2026.03.23 |