SOA와 MSA는 같은 아이디어인데, 왜 결과가 달랐을까?
May 12, 2026
요약
SOA(Service-Oriented Architecture)와 MSA(MicroService Architecture)는 시스템을 업무 기능별 서비스로 나눈다는 같은 생각에서 나왔고, 차이는 그 생각을 구현한 방식과 그 방식을 받쳐 준 인프라에 있었음
SOA는 ESB(서비스 사이의 통신을 중계하는 중앙 허브)라는 통신 경로에 업무 규칙까지 올렸고, MSA는 업무 판단은 서비스에 두고 통신 경로는 전달만 하게 했음(smart endpoints and dumb pipes)
서비스를 나눌 때는 통신 경로(브로커, 게이트웨이, 미들웨어)에 업무 규칙이 쌓이는지 봐야 하고, 쌓인다면 이름만 다른 ESB를 만들고 있는 것임
배경: 2000년대 초 SOA가 등장함
당시 기업들은 오라클, SAP 같은 거대한 소프트웨어를 운영했지만, 시스템끼리 연결이 안 되고 데이터가 따로 고립돼 있었음
SOA는 시스템을 업무 기능 단위의 서비스로 나누고, 서비스끼리는 공개한 약속(인터페이스)으로만 통신하게 하자는 서비스 지향 아이디어였음
실패: 분해했더니 ESB라는 새 덩어리가 생김
SOA를 구현하려면 모든 통신을 중계할 ESB(Enterprise Service Bus)가 필요했음
ESB는 메시지를 나르는 데서 그치지 않고, 어느 서비스로 보낼지 정하고 메시지 형식을 바꾸고 업무 규칙까지 처리했음
IBM, 오라클 같은 회사들이 비싼 ESB 제품을 팔았고, 기업들은 그 제품을 사는 것을 SOA 도입이라고 불렀음
하나로 묶여 있던 애플리케이션을 여러 서비스로 나눠도 서비스 사이의 규칙은 모두 ESB에 쌓였고, 이번에는 ESB가 새 덩어리가 됐음
그래서 서비스를 하나 추가할 때마다 ESB 설정을 고쳐야 했고, 그 변경이 다른 서비스에도 영향을 줘서 시스템은 분산됐지만 결합도는 그대로였음
SOA에서 서비스끼리는 XML로 메시지를 감싸 주고받는 SOAP이라는 통신 규약을 썼음
SOAP은 간단한 요청 하나를 보내는 데도 수십 줄짜리 XML을 써야 했고, 그래서 개발자들은 비즈니스 로직보다 XML 스키마와 씨름하는 데 시간을 더 썼음
급기야 2009년에는 한 업계 분석가가 “SOA는 죽었다”는 글까지 썼음
차이: 서비스는 똑똑하게, 통신 경로는 단순하게
2008년부터 넷플릭스는 시스템을 클라우드로 옮기면서 잘게 나눴고, 스스로 이 방식을 “잘게 나눈 SOA”라고 불렀음
이 방식은 2012년 무렵 마이크로서비스(microservices)라는 이름으로 자리 잡았고, 이 구조를 줄여서 MSA라고 부름
시스템을 작은 서비스로 나누고 각자 독립적으로 배포한다는 원칙은 SOA와 크게 다르지 않았지만, 통신 경로에 무엇을 맡기느냐가 달랐음
MSA는 통신의 양 끝에 있는 서비스가 업무를 판단하고 그 사이의 통신 경로는 메시지를 전달하기만 하게 했고, 이 원칙을 smart endpoints and dumb pipes라고 불렀음
예를 들어 “VIP 회원은 포인트 2배” 규칙이 ESB에 있으면, 정책을 바꿀 때 ESB 설정을 고쳐야 하고 그 설정에 얽힌 다른 서비스도 영향을 받음
반면 같은 규칙이 포인트 서비스 코드에 있으면, 포인트 서비스만 고쳐서 배포하면 됨
통신 경로로는 HTTP와 JSON, 또는 RabbitMQ 같은 가벼운 메시지 큐를 썼음
팀 하나가 서비스 하나를 끝까지 책임지고, 다른 팀과 상관없이 배포할 수 있었음
서비스마다 업무 판단을 맡기면 배포하고 운영할 서비스가 많아지는데, 마침 클라우드와 컨테이너 기술이 성숙해서 많은 서비스를 배포하고 운영하는 부담이 줄었음
다만, Fowler는 MSA를 정의한 글에서 ‘서비스가 깔끔하게 맞물리지 않으면 복잡성이 서비스 안에서 서비스 사이의 연결로 옮겨 갈 뿐’이라며, 그 연결은 더 잘 보이지 않고 다루기 어렵다고 경고했음
참고
