MSA 도입했음에도 다시 모놀로틱으로 돌아간 이유

1. MSA의 부상과 현실적인 문제

마이크로서비스 아키텍처(MSA)는 IT 산업이 발전하면서 많은 직군이 기술 중심적으로 변화하고, 트래픽 증가에 따라 확장성 요구가 커지면서 주목받게 되었다. 초기에는 MSA가 서비스 확장성과 분산 환경에 적합한 솔루션으로 각광받았지만, 실제 운영에서 여러 문제점이 드러나면서 MSA를 도입할지 여부를 두고 논쟁이 벌어지는 상황이 되었다.

현재 IT 업계에서는 "MSA를 도입해야 하는가?" 또는 "MSA를 포기하고 다시 모놀로틱으로 돌아갈 것인가?" 하는 두 가지 입장이 대립하고 있다.

---

2. MSA 도입의 주요 문제점

 

(1) 기술적 부채 증가

MSA를 도입하면 서비스가 여러 개로 나뉘면서 개별적인 테스트가 어려워지고, 전체 시스템의 일관성을 유지하기 위한 테스트 코드와 통합 테스트 비용이 기하급수적으로 증가한다.

• 단위 테스트(Unit Test) 관리 어려움: 각 마이크로서비스별로 독립적인 테스트 코드 작성 필요
• 통합 테스트(Integration Test) 부담 증가: 여러 서비스가 동시에 동작해야 하므로 통합 테스트가 어렵고 불완전할 가능성이 높음
• QA 과정 복잡화: 모든 서비스가 올바르게 동작하는지 확인하기 위해 QA 단계가 많아짐

결과적으로, 테스트 비용 증가와 유지보수 부담으로 인해 기술적 부채가 누적되기 쉬운 구조가 된다.

 

 

(2) 운영 관리 및 인프라 비용 부담

MSA는 서비스가 분리됨에 따라 운영 및 인프라 관리의 복잡도가 증가하고, 이를 유지하기 위해서는 상당한 자본과 인력이 필요하다.

• 각 서비스의 배포 및 유지보수 관리 필요: 배포 자동화(CI/CD), 모니터링, 로깅, 보안 등을 위한 추가적인 인프라가 필요함
• 네트워크 비용 증가: 마이크로서비스 간 통신이 많아지면서 네트워크 트래픽이 증가하고, API Gateway, Service Mesh 같은 추가적인 계층이 필요해짐
• 데이터 일관성 유지 어려움: 각 서비스가 독립적인 데이터베이스를 가질 경우, 분산 트랜잭션 관리가 복잡해짐 (예: SAGA 패턴 적용 부담)
• 전문적인 운영 인력 필요: DevOps, SRE(Site Reliability Engineering) 등의 역할이 필수적으로 요구됨

대기업 수준의 자본력이 있는 기업이 아니라면, MSA를 완전히 운영하는 것이 현실적으로 어렵다.

 

 

(3) 개발 및 배포 속도 저하
MSA의 핵심 목표 중 하나는 빠른 배포와 지속적인 배포를 가능하게 하는 것이다. 하지만 실제 운영 환경에서는 다음과 같은 이유로 인해 배포 속도가 예상보다 느려질 수 있다.

1. 서비스 간 의존성 증가   

마이크로서비스가 서로 긴밀하게 연결되어 있을 경우, 특정 서비스의 변경이 다른 서비스에 영향을 미칠 가능성이 높아진다. 특히, 도메인 경계를 명확하게 나누지 못하면 여러 서비스 간 동시 배포가 필요해지고, 배포 전 조율이 복잡해졌다.

2. 데이터 마이그레이션 및 버전 관리의 어려움

개별 서비스의 데이터 스키마가 변경될 경우, 해당 데이터를 참조하는 모든 서비스에서 이를 반영해야 한다.

API 버전 관리 및 데이터 이중화(Migration + Shadow DB) 등의 기법을 적용하지 않으면, 배포 시 충돌이 발생할 가능성이 높았다.  

3. 장애 대응 복잡화
모놀리식 환경에서는 하나의 애플리케이션 내부에서 오류를 수정할 수 있지만, 제대로 MSA에서 고찰하지 않으면 오히려 특정 서비스 장애가 다른 서비스로 전파될 가능성이 크다. 서킷 브레이커(Circuit Breaker), 폴백(Fallback) 전략, 분산 트랜잭션 관리(Saga Pattern) 등이 적절히 적용되지 않으면 장애가 전체 시스템에 영향을 미칠 수 있다. 실제로 인지하지 못하고 있던 부분에서 문제가 발생하는 경우가 많았다. 이는 MSA 사용에 깊은 고민이 필요하다는 반증이었다.   

결론적으로, 이론적으로는 MSA가 빠른 배포를 가능하게 하지만, 실제로는 이러한 복잡성을 해결하지 않으면 오히려 배포 속도가 저하될 수 있었다.

---

3. 왜 MSA를 포기하는가?

MSA는 특정 조건에서는 효과적인 아키텍처지만, 모든 기업이나 모든 프로젝트에 적합한 것은 아니다. 특히, MSA를 유지하는 데 필요한 비용, 인력, 인프라 등의 현실적인 문제가 존재하며, 다음과 같은 이유로 MSA를 포기하는 기업도 늘어나고 있다. [ 우리의 이번 프로젝트도 같은 이유이다. ]

 

(1) 초기 개발 속도와 유지보수 비용의 불균형

• 스타트업이나 소규모 프로젝트에서는 MSA보다 모놀로틱 아키텍처가 개발 속도 면에서 유리
• 초기부터 MSA를 도입하면 개발 복잡도가 높아지고, 핵심 비즈니스 로직보다 아키텍처 관리에 더 많은 시간을 소비하게 됨
• 시간이 지날수록 MSA 유지보수 비용이 증가하여 개발 속도가 저하됨

(2) MSA가 필요한 수준의 트래픽이 아님

• MSA는 수백만 이상의 트랜잭션을 처리해야 하는 대규모 트래픽 환경에서 빛을 발함
• 하지만, 트래픽이 적은 경우에는 분리된 서비스 간 통신 비용이 오히려 증가하여 성능이 저하될 수 있음
• 즉, 트래픽 대비 과도한 아키텍처 분리가 오히려 시스템 성능을 떨어뜨릴 수 있다

(3) 대규모 시스템을 운영할 인프라와 인력이 부족

• MSA를 제대로 운영하려면 DevOps, SRE, CI/CD 엔지니어, 클라우드 아키텍트 등의 전문 인력이 필요
• 그러나, 소규모 조직이나 중견 기업에서는 이러한 인력을 충분히 확보하기 어렵고, 운영 비용도 감당하기 어려움

---

4. 결론: 언제 MSA를 도입해야 하는가?

⭕ MSA가 적합한 경우

1. 고트래픽, 글로벌 서비스 운영 → 수백만 트랜잭션을 처리해야 하는 서비스 (예: Netflix, Amazon)
2. 독립적으로 확장해야 하는 서비스 → 특정 기능(예: 결제, 추천 엔진 등)만 빠르게 확장해야 하는 경우
3. 다양한 기술 스택을 활용해야 하는 경우 → 각 서비스별로 최적의 기술을 적용해야 할 필요성이 있는 경우
4. 서비스 간 의존성을 최소화할 수 있는 경우 → 비즈니스 도메인이 명확히 구분되는 경우

❌ MSA를 피하는 것이 나은 경우

1. 소규모 프로젝트나 스타트업 → 초기 개발 속도가 중요한 경우
2. 서비스 간 결합도가 높은 경우 → 데이터 정합성을 유지해야 하고, 트랜잭션이 강하게 결합된 경우
3. 운영 비용을 감당하기 어려운 경우 → DevOps, SRE, CI/CD 엔지니어 등의 인력을 확보하기 어려운 경우
4. 개발 및 배포 속도가 중요한 경우 → 팀 규모가 작고 빠른 피드백 루프가 필요한 경우

---

결론적으로, MSA는 특정 규모 이상의 시스템에서는 효과적일 수 있지만, 기술적 부채, 운영 비용, 유지보수 복잡성 등의 현실적인 문제를 고려해야 한다. 모놀로틱 아키텍처를 적절히 활용하면서 필요할 때만 MSA로 전환하는 점진적인 접근이 가장 현실적인 선택지일 것이다.