|

[심재석의 입장] SOA 실패의 교훈을 잊지 말자

 

10여년 전 기업용 IT업계에서 가장 많이 들리던 용어는 ‘서비스 지향 아키텍처(SOA)’였다. 기업이 사용하는 애플리케이션을 ‘서비스’라는 업무단위로 쪼개고, ESB(Enterprise Service Bus)라는 미들웨어에서 연결하는 하자는 접근이었다.

이렇게 하면 애플리케이션의 유연성, 서비스의 재활용성 등이 높아진다는 것이 SOA가 추구하는 이상향이었다. 애플리케이션을 통으로 개발하지 않고 레고처럼 서비스를 ‘조립’해서 새로운 애플리케이션을 만든다는 것은, 비즈니스의 유연성과 민첩성이 월등히 높아진다는 것을 의미했다.

gs_soa_019_0SOA는 한동안 IT업계의 신앙이었다.

그러나  모든 IT 버즈워드가 그렇듯, SOA 역시 시간이 지나면서 시들해졌다. 소프트웨어 벤더들은 SOA라는 거대한 이상에 편승해 ‘ESB’ 제품 팔기에 급급했고, 이들의 고객인 기업들은 유행이라니 관심을 보였을 뿐 ‘서비스 지향’이라는 아키텍처의 변경에 대한 깊은 고민을 하지 않았다.

결국 2009년 한 컨설팅그룹에서 “SOA는 죽었다”라는 도발적인 칼럼이 나오기도 했다. 2016년 현재, SOA는 정말 죽은 단어가 됐다.

하지만 SOA는 죽었다고 하더라도 ‘서비스 지향’이라는 사상은 죽지 않았다. 애플리케이션 하나를 통으로 개발하는 것이 아니라 ‘서비스’라는 단위로 쪼개 개발해 이를 연결하자는 방법론은 여전히 가치를 가지고 있기 때문이다.

최근에는 SOA라는 단어의 후속으로 ‘마이크로서비스아키텍처(MSA)’가 인기를 끌고 있다. MSA와 SOA는 사상적 측면에서는 비슷하다. MSA 역시 ‘서비스’와 ‘연결’에 근간을 둔 접근이다. 그 사상을 실현하기 위한 기술적 방법론이 좀 다를 뿐이다

SOA가 엔터프라이즈 IT 업계에서 시작된 것이라면, MSA는 인터넷 업계에서 먼저 나왔다. 클라우드, 빅데이터 등 현재 IT업계의 핫이슈는 인터넷 업계에서 등장해 엔터프라이즈 IT로 확산되고 있다.

대형 인터넷 서비스 업체들은 방대한 시스템을 통으로 개발할 경우 지속적인 업그레이드가 어렵기 때문에 각 기능별로 쪼개서 이를 API(Application Programing Interface)로 연결했다. 이렇게 해야 지속적인 개발, 배포가 가능하기 때문이다. 이것이 MSA로 정립됐다.

microservicesMSA에서 핵심은 서비스와 API다. 서비스를 잘 모델링 해서 API로 매시업(mash-up)하는 것이 MSA의 본질이기 때문이다.

이는 디지털 트렌스포메이션이나 4차 산업혁명과도 맞물린다. 개발된 서비스와 API는 내부에서만 사용하는 것이 아니다. API를 오픈해서 외부와 연결하거나, 나아가 판매할 수도 있다.

예를 들어 은행들이 자체적으로 사용하고 있던 송금과 같은 내부 서비스를 외부에서 이용할 수 있도록 API를 제공하는 것이 대표적인 사례다. 이 경우 은행은 금융업을 넘어 IT서비스 업체로 디지털 트렌스포메이션하게 된다.

한가지 우려되는 것은 기업들이 또다시 벤더에 의존해 MSA에 접근하는 것이다. 벤더들이 강조하던 ESB에만 너무 매달려 SOA가 죽었던 것을 잊지 말아야 한다.

최근 CA테크놀로지스, IBM 등 소프트웨어 벤더들은 API 게이트웨이 등 API관리 솔루션의 필요성을 역설한다. 쏟아지는 API의 통합관리, 보안통제, 관리의 편리성을 위해서 꼭 필요하다는 것이다.

물론 API관리 솔루션의 역할은 필요하고 중요하다. 그러나 SOA의 본질이 ESB가 아니었듯, MSA의 본질도 API게이트웨이가 아니다.

ESB나 API게이트웨이는 SOA와 MSA라는 이상을 실현시키기 위해 사용하면 유용한 도구 중 하나일 뿐이다. 주목해야 할 것은 도구가 아니라, 서비스와 아키텍처다.

민첩하고 유연한 비즈니스, 서비스의 재사용성이라는 SOA가 추구했던 가치를 넘어 디지털 트렌스포메이션까지 나아가야 할 MSA이기 때문이다.

글.바이라인네트워크
<심재석 기자>shimsky@byline.network

관련 글

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다