반응형
<출처 :zdnetKorea>

소프트웨어의 이상적인 모습은 장난감 블럭에 비유되곤 한다. 여러 가지 모양의 블럭들을 이리저리 짜맞추면 차도 만들고, 집도 만들 수 있듯 말이다. 이런 꿈을 실현하기 위한 시도는 시대에 따라 이름을 달리하며 계속되어 왔다.

C언어에서는 DLL라고 불리는 기능(Function)들의 묶음을 여럿 만들어 놓고 필요한 기능들을 불러 쓰는 방식이었다. 자바 언어로 오면서 객체들을 대표하는 클래스를 정의하고 재활용하자는 객체지향 개발방법이 부상했다. 그 후 컴포넌트 기반 개발방법(CBD), 그리고 최근 서비스 지향 아키텍처(SOA)까지 궁극적인 목표는 늘 같았다. 어느 정도 독립적으로 동작할 수 있는 모듈을 만들고, 이 모듈들을 조립하여 쉽고 빠르게 원하는 시스템을 만들자는 것이다.

SOA의 한계
하지만 시행착오를 반복하고 있는 소프트웨어 역사가 말해주듯 이게 그리 쉽지만은 않은 모양이다. SOA를 구현하는 기술로 가장 많이 언급되는 웹서비스조차도 방대한 표준과 쉽지 않은 구현방법으로 인해 대중화되는 데는 한계를 보여주고 있다. 장난감 블럭보다는 퀼트(조각헝겁들을 꿰매 이어붙인 수공품) 정도 된다고 해야 할까.

최근엔 엔터프라이즈 서비스 버스(ESB)라는 개념이 구현되어, 서비스들을 쉽게 연결할 수 있게 한다곤 하지만 아직은 손바느질이 재봉틀로 진화한 정도라 할 수 있다.

ESB 기술도 날로 발전하고 있어서 강력한 워크플로우 기능을 접목하는 등 편의를 개선하려는 시도가 있지만, 이런 시도가 성공한다 하더라도 궁극적으로 SOA가 그리는 이상 실현에는 큰 장애가 남아있다. 공을 들여 만든 서비스들을 막상 재활용할 기회가 없는 것이다. 이런 기회 상실의 가장 큰 원인은 서비스의 재활용 범위가 조직 내부로 한정되기 때문이다.

큰 덩치의 서비스는 현실적으로 한 조직 내에서 재활용될 기회가 거의 없다. 급여를 산정하는 서비스는 하나의 기업에 하나면 족하다. 반대로, 조직 내에서의 서비스 재활용성을 높이려면 서비스가 가능한 작게 정의되어야 하는데 이렇게 되면 서비스로서 기능성과 완전성을 상실하게 된다. 기술적으로는 가능하더라도 숫자의 세 자리마다 콤마를 붙이는 기능만 제공하는 서비스도 서비스라 부를 수 있을까?

실질적으로 소프트웨어 개발의 생산성을 높이려면 자신이 조합할 수 있는 서비스들이 가능한 많이 널려 있어야 한다. 예를 들어 기업의 구매를 처리할 수 있는 다양한 유형의 서비스들을 활용할 수 있어서 기성복처럼 완성된 형태로 가져오거나, 맞춤복처럼 원하는 서비스들을 조합해 새로운 구매 시스템을 구축할 수 있어야 한다. 이렇게 되어야 기존에 개발자들이 몇 달씩 밤 새고 휴일 없이 만들 수 있었던 기능이 단 몇 일, 몇 시간만에 완성될 수 있는 것이다. 이것이야 말로 SOA가 궁극적으로 지향하는 소프트웨어 개발에 있어서의 혁신인 것이다.

웹서비스의 표준 요건 중에는 서비스의 고유한 주소를 정해진 저장장소(UDDI)에 반드시 등록하게 하는 것이 있는데, 이 저장장소는 전화번호부와 같은 역할을 한다. 원하는 서비스의 주소를 이 저장장소에서 찾아 해당 주소로 서비스를 요청하는 식이다. 이 같은 표준은 외부의 수많은 서비스들을 쉽게 활용할 수 있도록 만들어진 것이었으나, 지금과 같이 서비스가 내부용으로만 제한된다면 이런 주소 저장방식은 되려 속도를 저해하는 천덕꾸러기일 뿐이다. 조직 내의 한정된 서비스만으로는 개발 생산성면에서는 득보다 실이 많다.

공유와 개방의 웹2.0
이렇게 SOA가 제 위치를 찾지 못하고 있는 가운데, SOA 유토피아의 모습을 간접적으로나마 경험해 볼 수 있는 곳이 있다. 바로 인터넷이다. 구글, 야후, 아마존, 이베이, 네이버, 다음 등 국내외 유수 인터넷 기업들은 자신의 정보를 API 형태로 일반에 공개하기 시작했다. 이를 오픈API라고 한다.

인터넷 기업들은 검색, 쇼핑 아이템, 지도, 카페글 등 자신들의 정보 자산에 접속할 수 있는 오픈API를 무상으로 제공하고 있다. 원하는 개발자는 공개된 API들을 조합해 새로운 인터넷 서비스를 개발할 수 있는데, 이런 조합 작업을 매쉬업(mashup)이라 한다.

매쉬업은 웹2.0의 중요한 현상 중의 하나이다. 웹2.0은 새로운 기술과 네티즌의 획기적인 태도 변화가 만들어 낸 메가트렌드다. 2.0을 단순히 기술의 변화 정도로 이해하고 아무데나 2.0을 붙여대는 것은 2.0에 대한 모독이다. 웹2.0의 태동에는 인터넷 기업을 포함해 인터넷 참여 주체들의 중요한 태도 변화가 있었는데, 이것은 공유와 개방이라는 키워드로 요약될 수 있다.

1.0적인 사고는 폐쇄와 단속이었다. 내가 가진 지식과 노하우는 나만이 알고 있어야 득이 된다고 생각했다. 내가 힘들여 모은 정보와 자료는 절대 노출하면 안 되었다. 하지만 일부 네티즌들이 다른 생각을 하기 시작했다. 공유하고 개방하는 것이 자신에게 더 득이 된다는 사실을 깨닫게 된 것이다. 그것이 물질적인 보상이건 정신적인 보상이건 말이다. 이렇게 2.0을 맞이한 인터넷 경제는 전보다 몇 배, 몇 십배 성장할 수 있었다.

매쉬업은 새로운 경제를 만들어 내고 있다. MS의 팝플라이(www.popfly.com)나 야후의 파이프(pipes.yahoo.com)를 사용해 본다면 매쉬업의 매력을 쉽게 느껴볼 수 있다. 플리커의 사진에 접근하는 API와 앨범처럼 넘기는 UI를 연결하면 금방 새로운 서비스가 탄생한다.(그림 참고)

구글 맵과 부동산 정보를 연결하면 부동산 맵 서비스가 가능하다. 인터넷 쇼핑몰의 쇼핑 아이템 정보와 자신이 가진 전문지식을 결합하면 금새 전문 분야 쇼핑몰이 새로 탄생한다. 심지어 미국 정부는 개인 정보를 침해하지 않는 범위 내에서 공공 정보에 접근할 수 있는 API을 공개했다. 공유와 개방의 정신이 또 하나의 생태계를 인터넷에 만들고 있다.


마이크로소프트 팝플라이에서 간단한 매쉬업 수행 모습과 결과


웹서비스가 복잡한 표준화에 힘쓰는 동안 역동적인 인터넷은 신속하게 오픈API라는 실질적인 대안을 내놓은 것이다. 좋은 오픈API들이 늘면서 이것들을 쉽게 조합할 수 있는 플랫폼(매쉬업툴)이 탄생한 것은 정해진 수순으로 보인다. 법보다 주먹이 먼저라고 했던가.

SOA + 웹2.0 = 소프트웨어2.0
이제 다시 SOA로 돌아와 보자. 내부 서비스만으로 무언가를 만들어 보겠다는 것은 투자 대비 효과면에서도 바람직하지 못하고, SOA의 궁극적인 탄생 목적에도 위배되는 것이다. 결국 조직 내에 구축되는 수많은 서비스들은 외부로 공개되어야 한다.

기업의 핵심 서비스를 제외한 나머지는 공개돼도 크게 문제될 것이 없다. 데이터는 제외하고 비즈니스 로직 서비스만을 공개해도 좋다. 무료 공개가 아닌 상업적으로 판매하는 것도 나쁘지 않다.

시장이 형성되면 개인 개발자들도 자신들의 비즈니스 지식을 서비스로 개발해 수익을 올리려 할 것이다. 비즈니스 지식들이 무궁무진하게 쌓여있는 전 세계의 IT서비스 업체들과 비즈니스 컨설팅사들, 기업용 프로그램 업체들은 자신들의 지식을 상업화할 수 있는 새로운 유통망을 얻게 된다.

이런 서비스들을 등록, 검색, 판매해 주는 서비스 포털이 새로운 스타 사이트로 떠오르게 될 것이다. UCC와 함께 ECS(Enterprise Created Service)가 각광을 받게 되는 것이다. 오픈소스 대신 오픈서비스가 더 주목을 받는 것이다.

이렇게 시장에 가용한 서비스 재료들이 넘쳐나면 조직과 개인들은 플랫폼(ESB) 위에 서비스들을 조합해 원하는 기능을 쉽게 구성할 수 있게 된다. HR 컨설팅사는 자신의 독특한 인사평가제도를 서비스로 개발해 판매한다. 디자인 회사는 멋있는 차트 서비스를 판매한다. 한 IT서비스 기업은 커뮤니케이션 툴 서비스를 제공한다. 독특한 인사평가제도를 시스템으로 구축하고자 하는 기업은 이런 서비스들을 조합하고, 여기에 자신의 인사 데이터를 실어 자신에게 꼭 맞는 인사평가 시스템을 굉장히 빠른 시간 안에 구축할 수 있다. 또 차트가 맘에 안 든다면 다른 차트 서비스로 쉽게 대체할 수도 있을 것이다.

SOA가 웹2.0의 사상을 만난 이 새로운 환경을 '소프트웨어2.0'이라 한다면, 소프트웨어2.0은 웹2.0보다 훨씬 큰 경제를 새로 창출해 낼 수 있다. 비즈니스를 혁신할 아이디어만 있다면 1인 개발자도, 1인 컨설턴트도 부을 얻을 수 있는 기회의 장이 마련된다. 전 세계 소프트웨어인들에게 창의성을 발휘하고 부를 창출할 수 있는 동등한 기회가 제공된다. 아프리카이건, 동남아시아이건 지역이 문제되지 않는다. 자신의 아이디어가 세계 시장에 팔리는 것이다. 이것은 미국의 대형 소프트웨어 기업들이 형성해 가는 IT제국주의에서 벗어나 지구촌이 함께 인류를 발전시킬 수 있는 길이 될 것이다.

소프트웨어2.0의 선구자는 누가..?
문제는 누가 이런 비전과 이니셔티브를 쥐고 신 생태계를 만들 수 있을 것인가 하는 점이다.

이 선도자나 선도 그룹은 다음과 같은 요건이 필요할지 모르겠다. 우선 세목의 관심을 끌 수 있는 꽤 괜찮은 비즈니스 서비스와 이런 서비스를 유통하기 위한 포탈 사이트, 그리고 서비스들을 쉽게 조합할 수 있는 표준 방식의 서비스 버스 프로그램. 그리고 여기에 개발자 커뮤니티와 서비스 제작을 위한 간편한 도구와 교육 프로그램이 추가된다면 금상첨화일 것이다. 전 세계 지원군을 얻어가는 사업 초기에는 이 모든 것을 무료로 제공해야 할지도 모른다.

하지만 MS나 구글이 그랬듯 새 세상을 연 자에게는 엄청난 보답이 돌아온다. 소프트웨어2.0 시대의 선구자가 한국에서 탄생할 순 없을까?
반응형
반응형

웹기반 표준기술인 웹서비스 기술을 활용하여 새로운 비즈니스를 창출한다는 측면에서 SOA는 최근 화두가 되고 있는 웹 2.0과 매우 유사한 특징을 지니고 있다.


마이크로소프트 아키텍쳐 전략 담당관인 John de Vados는 웹 2.0과 SOA의 개념과 주요 특성을 비교하면서 현재 웹 2.0은 소비자 중심 비즈니스 모델을 지원하고, SOA는 기업 중심 모델을 지원하고 있다고 보고 있다. 그리고 미래 비즈니스 세계는 이 둘간의 구분이 모호해지고 연계가 활발해짐에 따라, 궁극적으로 웹 2.0이 글로벌 차원의 SOA를 실현할 수 있을 것으로 전망하고 있다.


* 웹 2.0과 SOA간 개념비교 (출처 : SOA Web Service Journal, 2006)

웹 2.0

SOA

서비스 모델

- 웹 서비스

- 웹 서비스

선호하는 서비스 표준

- HTTP, XML, RSS, REST

- WSDL, UDDI, SOAP, BPEL

재사용성

- 매우 높음

- 약간 높음

유연성 및 순응성

- 매우 높음

- 단순한 데이터 포맷

- 가벼운 프로그래밍 모델

- 높음(보다 더 공식적)

- 조합과 통합

 (Composition and Orchestration)

비즈니스 모델

- 롱테일(Long Tail) 효과

- 네트워크 효과

- 집단지능 활용

- 고객 셀프 서비스

- BPM

- 자산통합(Asset Integration)

- 데이터 퓨전(Data Fusion)

- 래거시 자산의 생명주기 연장

- 비즈니스 활동 모니터링

- 비즈니스 지능 활용

설계 플랫폼

- AJAX

- 신디케이션(syndication)

- 멀티 디바이스 소프트웨어

- Service layer

- Service Bus

- Unit of Work

핵심역량

- 서비스로서의 SW(Saas)

- 데이터 소스에 대한 통제

- 공동개발자로서 사용자 신뢰

- 집단지능 이용

- 롱테일 효과

- 단일 디바이스(PC플랫폼)을
  넘어선 소프트웨어

- 가벼운(lightweight) UI,
  개발모델, 비즈니스모델 채용

- 기능의 재정비

- 자산(Asset)으로서 데이터

- 접근가능성

- 시스템/데이터 통합

- 비용절감

- 비즈니스 기민성(Agility)

- B2B 셀프서비스

- 오픈스텐다드

- 온톨로지(ontologies)

- 오퍼레이션투명성

- 소비자 중심의 비즈니스 프로세스

내용출처 :
반응형

+ Recent posts