1세대

서비스 정신에 입각한 아키텍처가 SOA라 불리며 대유행이 일었던 중홍기는 2005년경이었다 다른 애플리케이션이 편하게 의존해 편익을 취할 수 있는 애플리케이션을 만들기 위한 아키텍처 스타일이 제안된 것이다 이는 통합이란 사후가 아닌 사전에 염두에 두어야 한다는 것을 깨달았다는 신호였다언제든지 바뀔 수 있다는 비즈니스의 숙명을 염두에 두고 바뀌기 쉬운 방식으로 설계를 시도한 것이다 우리 사회가 그렇듯 IT의 시스템도 서로 서비스를 주고받는 서비스 주체들의 집합이라는 인식에서 시작됐다 물론 분산된 이정 시스템들 간 협업을 가능하게 한다는 방편이 제시된 것은 처음이 아니다 과거의 방법들과 크게 다른 점이 있다면 아주 구체적인 실천론을 기반으로 한 실현 가능한 대안이었다는 점일 것이다 서비스화란 사실 어떤 특징 기술이나 제품 프로토콜 표준이라기보다 오히려 정책 프레임워크 패턴과 같은 방향성에 가깝다 그런데 이와 같은 이상론은 누구나 펼 수 있다 그러나 이즈음부터 IT업계의 주도자들 간에 즉시 실현 가능한 실천 방안이 마련되기 시작한다 대표적 실천 방안으로 웹서비스라고 불리는 기술이 각광받기 시작한다 약 2004년 부터 2006년경이 피크였다 여기서 말하는 웹서비스란 웹사이트를 말하는 것이 아니라 웹기술을 가지고 서비스화의 서비스를 하자는 것이었다 웹서비스는 사실상 IBM,마이크로소프트,썬,오라클 등 당대 모든 IT기업들이 전폭적인 지지를 했던 표준안으로 부각된다 물론 과거에도 DOCM, IIOP, RMI 같은 연동 기술들이 매년 등장했었지만 모두 일부만의 약속이었을 뿐이다 마이크로소프트가 미는 기술은 썬이 싫어했고 IBM이 미는 기술은 오라클이 싫어했다 그러나 웹서비스는 이러한 한계를 넘어서는 것이었다 그동안 으르렁거리던 앙숙들이 하나의 테마에 동의를 했기 때문이다 그러나 이마저도 오래가는 못했다 웹 2.0 붐이 일어난 2006년 이후 구체적 연동 기술은 웹서비스 대신 아예 웹으로 대체된다 웹서비스만 해도 웹 기술이라 보기 어려울 정도의 변종이었다 아예 모든 브라우저에 기본 탑재된 보편적 기술을 이용해 소통하면서도 편의를 위해 극도로 단순화된 JSON/REST같은 새로운 기술로 사실상 대체된 것이다 작금의 오픈 API를 통한 연동은 대부분 이러한 단순화된 기술에 의존하게 되었지만 오히려 웹서비스 같은 나름 무거운 기술들이 지반을 다져주었기에 가능했던 일인지도 모른다 원래 모든 새로운 혁신은 곧 비교 대상이 되어 극복해야 할 숙제가 되니 말이다 웹서비스는 다음과 같은 점에서 두드러진 특성을 지녔다 그러나 이러한 대기업이 가진 습성까지 그대로 답습했다 안타깝게도 모든 위원회 기술이 그렇듯 충분히 가볍지 못했다 모두를 만족시키는 어중간한 사양이 나오기 십상이었다 지금까지의 통합 기술은 기업 내부에서 혹은 매우 폐쇄적인 관계의 파트너들끼리 독자적인 기술로 얽어놓기 위한 것들이었다 그러나 웹서비스는 마치 웹사이트가 전 세계 누구에게나 열려 있듯 자신의 시스템을 어떠한 상황과도 통합되게 하는 가능성을 제공했다는 점에서 칭찬할 만했다 그러나 웹서비스는 웹이 아니었다 그 근간이 된 XML과 일상적 웹과의 거리는 점점 멀어졌고 대신 웹은 자바스크립트의 데이터 소통 모델인 JSON을 쓰기 시작했다 웹서비스가 순식간에 구식이 되어버린 것이다 웹서비스는 SOA를 실현하기 위한 실직적 기술이라고 보아 무방했다 물론 웹서비스 없이도 SOA는 가능했고 거꾸로 SOA의 철학을 무시한 웹서비스도 구현 가능했을지 모른다 그러나 SOA라는 이상과 웹서비스의 실천은 의외의 방식으로 결합되었고 한쪽의 쇠퇴에 따라 그에 묶인 개념도 서서히 가라앉기 시작했다 결국 SOA는 한물간 개념이 되어버렸다 인류 사회으 역사가 서비스화로의 행진이었던 만큼 서비스는 기발한 발명이 아니다 IT의 역사에서도 예외가 아니어서 오브젝트와 컴포넌트라는 기술 개념도 인터페이스라는 단일 통로를 지니고 이를 활용해왔다는 점에서 볼 때 서비스는 수십 년째 시도되고 있는 개념일 뿐이다 오래되고 낡은 자바의 오브젝트나 심지어 엑티브X 컴포넌트도 모두 서비스업의 이상을 이해하고 있었던 것 그렇다면 서비스는 종래의 오브젝트 또는 컴포넌트와는 무엇이 다를까 눈에 띄는 차이는 그 크기다 오브젝트나 컴포넌트는 일단 그 알갱이가 작다 결국 이들은 프로그래머에 의해 완성되고 관리되는 프로그래밍 모듈이다 하나의 비즈니스 상황을 대변하려면 이들이 모이고 모여야 한다 업무 흐름을 만들기 위해서는 조금 더 비즈니스의 입장에서 정리된 무엇이 필요하다 그 입장차가 서비스를 특별하게 만든다 여기에 서비스의 가장 큰 차별점이 있다 서비스는 프로그래밍이나 시스템을 감싸서 비즈니스 프로세스 그러니까 업무의 실직적 흐름과 이어준다 업무는 늘 변화를 요구받는다 시장 상황의 변화에 따라 그리고 고객의 요구에 따라 업무의 흐름과 양태가 수시로 변하기 때문이다 결제가 앞에 올 수도 있고 사후에 이루어질 수도 있다 또는 중간 정산이 있을 수도 있다 꼭 이 모든 상황마다 프로그램을 다시 개발하거나 중복 개발하야만 할까 왜 결제나 정산이라는 서비스가 상황마다 등장해 처리해줄수는 없을까 지금까지의 IT는 변화에 힘겨워했다 변화란 곧 잔업이고 밤샘을 의미했기 때문이다 엄두가 나지 않아 비즈니스는 알아서 움츠리기까지 했다 서비스의 정신과 얼개는 이를 방지한다 비즈니스는 받고 싶은 서비스의 인터페이스에만 신경 쓰면 되고 이들은 충분히 자율적으로 동작하기에 흐름의 변화를 의뢰하기만 하면 된다 IT가 비즈니스에 해주는 일이 서비스로 정리되었다면 이제 남은 일은 이 서비스를 재배열하고 재구성하는 일뿐이다