SOA와 MSA 그리고 AWS

SOA는 1990년대 후반 IT 시스템 통합을 위해 등장한 아키텍처 철학으로 비즈니스와 IT를 연결하는 근본적인 질문에서 출발했습니다. 최근 IT 분야에서 가장 스포트라이트를 받고 있는 MSA는 클라우드 환경에서 SOA를 실행하기 위한 최신 기술 방법론입니다.

*본 아티클은 하이드라프트®가 고객 컨설팅 과정에서 실제 활용하는 에셋의 일부를 발췌하여 구성하였습니다.

[1. SOA의 시작]
SOA(Service-Oriented Architecture)의 개념은 1990년대 후반 등장했으며, 2000년대 초반부터 XML Web Services와 같은 표준 기술의 발전에 힘입어 본격적으로 주목받기 시작했습니다. 이러한 기술 발전 덕분에 SOA의 구현이 현실화되었고 많은 기업들이 IT 시스템을 보다 유연하고 민첩하게 만들기 위한 전략으로 SOA를 도입하기 시작했습니다. 30년이 지난 현 시점에도 SOA는 복잡한 기업 IT 환경에서 다양한 시스템과 어플리케이션을 효율적으로 통합하고 관리하는 가장 강력한 개념입니다. SOA는 특정 개인이나 조직이 주도한 개념이라기보다는 IT 산업 전반에서 자연스럽게 발전한 결과물입니다. 그리고 최근 각광받고 있는 MSA(Microservices Architecture)는 ‘SOA의 철학을 클라우드 환경에서 구현한 최신 기술 방법론’ 으로 볼 수 있습니다.

· AWS는 SOA에서 탄생했고 그 철학을 계승했다.
· MSA는 SOA에서 파생했고 그 철학을 계승했다.
· CSP는 SOA, MSA 전략을 추진하기 위한 필수 도구이다.

[2. SOA의 등장 배경]
1990년대 대표적 개발 방식은 CBD(Component-Based Development, 컴포넌트 기반 개발)방식이었습니다. 이 방식은 독립적으로 개발된 여러 컴포넌트들을 조합하여 하나의 시스템을 구축하는 접근법이었지만 컴포넌트 간 의존성 관리, 통합 시 발생하는 복잡성, 그리고 무엇보다 개발 단계의 <추상화 레벨>과 <현실의 비즈니스 레벨> 간의 괴리가 크다는 한계가 있었습니다. 이러한 문제를 해결하기 위해 1990년대 후반부터 2000년대 초반에 걸쳐 SOA 개념이 등장했습니다. SOA는 분산 컴퓨팅 환경에서 보다 유연하고, 재사용 가능하며, 비즈니스 프로세스 중심의 IT 시스템을 구축하는 방법론으로 주목받았습니다. 특히 개발 단계에서 정의한 유스케이스(Use Case)나 시맨틱 모델(Semantic Model)을 실제 아키텍처 설계 및 비즈니스 정의와 유기적으로 연결함으로써 현실의 비즈니스 흐름을 반영한 직관적인 시스템 설계가 가능해졌다는 점에서 큰 의미를 가집니다.

'잘 정의된 인터페이스를 가진 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술 구조 방식을 SOA(Service Oriented Architecture)라 한다.' — Gartner, 1996

[3. W3C의 Web Services Architecture 등장]
2004년 2월, W3C(World Wide Web Consortium)는 SOA의 철학에 기반한 웹 서비스 아키텍처(Web Services Architecture)를 발표했습니다. 이를 통해 WSDL(Web Services Description Language)과 SOAP(Simple Object Access Protocol)을 사용하는 XML(eXtensible Markup Language) 기반의 표준이 공식화되었습니다. 이 표준은 XML을 기반으로 한 API(Application Programming Interface)를 통해 서로 다른 개발 언어나 시스템 간에도 원활한 상호작용과 통신이 가능하다는 것을 의미했습니다.

‍
[4. REST API 등장]
하지만 W3C의 Web Services Architecture는 SOAP과 WSDL을 기반으로 한 엄격하고 무거운 표준 체계였기 때문에 보다 단순하고 가벼운 방식의 API에 대한 수요가 점점 커졌습니다. 이러한 배경 속에서 등장한 것이 바로 그 유명한 REST(Representational State Transfer) API이며 주로 JSON(JavaScript Object Notation) 포맷을 통해 데이터를 주고받는 방식으로 널리 알려져 있습니다. REST API는 현재까지도 대부분의 웹 서비스에서 가장 보편적으로 사용되는 통신 방식입니다. 다만, 최근 고성능 실시간 통신이 요구되는 환경(예: 마이크로서비스 간 통신, 스트리밍, 모바일 네트워크 등)에서는 구글의 gRPC와 같은 바이너리 기반의 고성능 프로토콜에 비해 상대적으로 성능 및 효율 면에서 한계를 보이고 있으며 이로 인해 일부 특수한 요구사항에서는 REST API보다 다른 방식이 채택되는 사례가 증가하고 있는 추세입니다.

‍

[5. AWS의 탄생]
아마존의 CEO ‘제프 베조스’는 SOA 개념이 등장했을 때 그 가능성을 누구보다 빠르게 인식하고, 2000년대 초반부터 아마존의 모든 내부 시스템을 SOA 기반으로 재구축하기 시작했습니다. 이후 2006년, 아마존은 자체적으로 구축한 웹 서비스 환경과 API 인프라를 기반으로 축적된 경험과 기술 노하우를 바탕으로, 기존 시장 파괴적인 비즈니스 모델을 공개하게 됩니다. 이것이 바로 AWS(Amazon Web Services)이며, 인류 최초의 IaaS(Infrastructure as a Service)로 평가받습니다. AWS 가 ‘Amazon Web Services’의 약자인 것도 바로 SOA와 W3C의 Web Services Architecture의 철학을 계승했기 때문입니다. 이렇게 탄생한 AWS는 웹 생태계의 구조 자체를 근본적으로 변화시켰고, 이후 이러한 비즈니스 모델은 CSP(Cloud Service Provider) 혹은 클라우드 플랫폼이라는 형태로 자리 잡게 되었습니다. 현재는 AWS를 비롯해 Microsoft Azure, Google Cloud 등이 대표적인 CSP로 활발히 운영되고 있습니다.

"이 글을 쓰는 지금, 과거 직장 시절 ‘롱테일 법칙’을 통해 처음 알게 된 제프 베조스가 얼마나 대단한 통찰력을 지닌 인물이었는지 새삼 다시 느끼게 됩니다."

[6. MSA의 등장과 확산]
SOA의 철학과 개념을 추종하던 단체, 기업, 그리고 개발자들을 중심으로 클라우드 생태계는 무서운 속도로 발전했습니다. 이후 아마존, 페이스북, 넷플릭스 등의 미국의 IT 선도 기업들이 클라우드 환경에서 보여준 시스템 구축 방식의 특이점과 양상을 ‘제임스 루이스’라는 컨설턴트가 정리하여 공표하게 됩니다. 이것이 바로 SOA 개념을 클라우드 환경에 최적화한 형태인 MSA(Microservice Architecture)이며, 오늘날에는 업계의 표준 아키텍처 용어로 자리 잡게 되었습니다.

MSA의 가장 큰 장점은 ‘서비스 단위의 재사용성과 확장성’에 있습니다. 예를 들어, ‘A 호텔’ 프로젝트에서 구축한 ‘상품 구매~결제 과정’에 해당하는 마이크로서비스를 ‘B 종합 쇼핑몰 웹사이트’, ‘C 패션 모바일 앱’, ‘서드파티 셀러들의 웹 채널링 플랫폼’ 등 다양한 프로젝트에도 곧바로 적용할 수 있습니다. 이는 단순한 컴포넌트 재사용이나 코드 모듈화와는 구분되는 개념입니다. MSA에서는 기능을 제공하는 서비스 단위 자체를 하나의 독립 실행체로써 재사용이 가능하며 이러한 작고 독립적인 서비스들이 모여 하나의 시스템을 구성하게 됩니다.

이러한 구조 덕분에 개발 시간은 획기적으로 단축되며 버그 수정도 전체 시스템이 아닌 문제가 발생한 해당 마이크로 서비스만 수정하면 되기 때문에 유지보수의 효율이 높아 집니다. 또 서로 다른 플랫폼에서 동일한 UI/GUI를 경험할 수 있어 일관된 사용자 경험(UX)을 제공할 수 있다는 것도 큰 장점입니다. 최근에는 SI(System Integration) 비즈니스에서도 이러한 장점을 고려하여 클라우드 상에서 인스턴스를 분리하거나 멀티 테넌시와 DB 분리 전략 등을 적용하여 부분적으로 MSA를 병행하는 사례가 증가하고 있습니다.

‍

[7. 마무리]
SOA에서 MSA로 이어지는 흐름은 단순한 기술 진화가 아니라 우리가 디지털 전환 시대에 어떻게 대응하고 준비해야 하는지를 알려주는 핵심 개념입니다. 앞으로의 비즈니스 전략 수립에 이 정리가 작게나마 도움이 되길 바랍니다.

‍

Article Overview