SOA(Service Oriented Architecture)
상태바
SOA(Service Oriented Architecture)
  • 데이터넷
  • 승인 2007.03.08 00:00
  • 댓글 0
이 기사를 공유합니다

개방형 표준 플랫폼· 표준 서비스 사용 … SOA만으로 완벽할 수 없어
박범순
SAP코리아 마케팅 팀장
adam.park@sap.com

‘SOA·BPM·EDA’ 삼각편대로 민첩성·유연성 실현

‘SOA(서비스 지향 아키텍처)’는 혼자서는 완벽할 수 없다. 서비스는 기존의 애플리케이션을 이리저리 조립하기 편하도록 잘게 쪼개놓은 것이다. 하지만 이렇게 쪼개는 목적은 다시 사용자의 용도에 맞게 조립하기 쉽도록 하는 데 있다. 결국 서비스를 조립해 업무 프로세스를 완성하는 것을 목표로 하기 때문이다. 그래서 SOA와 함께 비즈니스 프로세스 관리(BPM)가 논의되며 업무 프로세스에는 일정한 규칙을 정의하고 일 처리 시점을 지정해야 하기 때문에 이벤트주도형 아키텍처(EDA)도 한 축을 이룬다. 결국 SOA와 BPM, EDA가 삼발이를 이뤄 기업의 민첩성(agility)과 유연성(flexibility)을 실현하고 있다. <편집자>

몇 년 전 여러 민족이 살고 있는 미국 캘리포니아 주의 어느 대학 연구소에서는 취학 전 아동을 대상으로 흥미로운 실험을 한 바 있다. 레고 블록과 듀플로 블록(유아를 위한 큰 블록)을 섞어 동일한 크기의 집 모형 두 개를 만들어 놓고 각 블록마다 집이라는 단어를 적어 놓았다.
실험에 참여한 아동은 영어만 구사하는 아동과 2개 국어 이상을 구사하는 아동 등 두 그룹으로 구분한 후 각 그룹에 대해 집이라는 단어가 더 많이 들어 있는 쪽을 택하라는 동일한 과제를 제시했다. 놀랍게도 2개 국어 이상을 구사하는 그룹이 영어만 구사하는 그룹보다 먼저 문제를 해결했다.
이러한 결과를 어떻게 해석할 것인가? 기본적으로 2개 국어 이상을 구사할 경우 구체적인 표현보다는 의미에 집중하며 문제에 얽매이지 않고 한 걸음 물러나 해결책을 찾는 경향이 있다는 것이다. 다시 말해 영어만을 배운 아이는 문제에 주어진 대로 집이라는 단어가 적힌 블록의 수를 셈하느라 시간을 보낸 데 비해 여러 언어를 배운 아이는 문제에서 한 걸음 물러나 집이라는 단어의 수가 많은 쪽은 결국 크기가 작은 레고 블록의 수가 많은 경우라는 결론을 내리고 좀 더 간단하게 문제를 해결했다.

현업 부서와 IT 부서간 이해 필수
기업 내에서도 현업 부서와 정보기술(IT) 부서는 서로 다른 관점에서 세상을 바라본다. 그렇기 때문에 간혹 현업 부서의 요구사항을 IT 부서가 명확히 파악하지 못한 상태에서 개발에 나서는 경우가 있다. 이러한 문제를 해결하기 위해서는 서로 다른 두 세계를 연결해 줄 공통의 표현 방식이 필요하다. 세상을 현업과 IT 부서가 모두 이해하기 쉽게 표현하는 방식이 바로 서비스다. 서비스는 의미 있는 업무 단위를 표현하기 때문에 현업과 IT 부서 모두 레고 블록처럼 표준화된 서비스를 이용해 전체 업무를 표현하고 통합할 수 있다.
이러한 서비스지향 시대에는 현업 부서와 IT 부서의 언어를 모두 구사할 줄 알면서 두 세계를 연결해 줄 인력이 필요하다. 서두에 든 예에서처럼 두 언어를 구사하는 사람은 문제의 핵심을 보다 신속하게 간파하는 능력이 있기 때문에 기업의 경영 혁신을 가속화 할 수 있다. 현업의 업무 프로세스를 이해할 뿐 아니라 IT 부서의 입장에서 해결하는 역량을 갖추고 있다.

서비스는 프로세스의 기본 요소
전사적 자원관리(ERP)와 고객관계관리(CRM) 등 기업용 애플리케이션은 기업의 업무 프로세스를 표준화, 자동화, 효율화 한다. 하지만 이들 애플리케이션은 기본적으로 업계 선진사례(베스트 프랙티스)를 중심으로 구성돼 있다는 점에서는 강점이 있지만 사용자가 원하는 방식으로 변경이 용이하지 않다는 문제가 제기돼 왔다. 다시 말해 처음 프로젝트를 추진할 당시에는 기업의 요구사항을 수용하는 유연성이 있지만 일단 구축하고 나면 마치 욕실의 방수 처리에 사용하는 실리콘(실란트)처럼 금세 굳어 버린다.
기업은 이러한 유연성 문제를 해결하기 위해 다양한 방안을 모색해 왔다. 그 중에서 최근 가장 널리 각광 받는 개념이 서비스지향 아키텍처(SOA)다. 물론 SOA를 과거의 분산 컴포넌트 아키텍처의 한 흐름으로 치부하는 경향도 있지만 이는 핵심을 크게 벗어난 견해다. 분산 컴포넌트 아키텍처는 안정적으로 장기간 사용할 애플리케이션을 개발하는 데 초점을 맞추고 컴포넌트 간의 밀착 연동을 추구한다. 하지만 서비스지향 아키텍처는 궁극적으로 서비스의 조립을 통해 업무 프로세스를 완성하는 데 목적이 있으며 업무 환경이 바뀌면 그에 따라 업무 프로세스를 변경하기 쉽게 만드는 데 초점을 두고 있다.
한 마디로 서비스지향 아키텍처는 혼자서는 완벽할 수 없다. 서비스는 기존의 애플리케이션을 이리저리 조립하기 편하도록 잘게 쪼개놓은 것이다. 하지만 이렇게 쪼개는 목적은 다시 사용자의 용도에 맞게 조립하기 쉽도록 하는 데 있다. 결국 서비스를 조립해 업무 프로세스를 완성하는 것을 목표로 하기 때문이다.
따라서 SOA와 함께 비즈니스 프로세스 관리(BPM)가 논의되며 업무 프로세스에는 일정한 규칙을 정의하고 일 처리 시점을 지정해야 하기 때문에 이벤트주도형 아키텍처(EDA)도 한 축을 이룬다. 결국 SOA와 BPM, EDA가 삼발이를 이루어 기업의 민첩성(agility)과 유연성(flexibility)을 실현하는 것이다.

레고 디지털 디자이너와 개방형 혁신
레고 블록은 서비스지향 시대의 서비스와 닮은 구석이 많다. 무엇보다 주목할 만한 점은 바로 블록과 블록이 만나는 부분, 즉 인터페이스가 표준화 되어 있다는 사실이다. 표준화된 인터페이스 덕분에 무한한 조립 가능성을 제공한다.
시장조사 전문기업인 가트너(Gartner)가 서비스지향 아키텍처를 인터페이스지향 아키텍처로 부르는 편이 바람직하다고 했던 이유도 여기에 있다. 기존의 분산 컴포넌트 아키텍처와 SOA를 차별화하는 요인이 바로 무한한 조립 가능성이기 때문이다. 이러한 조립을 통해 완성한 애플리케이션을 IT 분야에서는 컴포지트 애플리케이션(composite application)이라 부른다.
레고는 사용자를 위해 레고 디지털 디자이너(LEGO Digital Designer)라는 소프트웨어를 무상으로 배포하고 이를 이용해 디자인한 자신만의 모델은 웹사이트 상에 있는 레고 팩토리(LEGO Factory)에 올릴 수 있게 한다. 사용자가 원할 경우 이 모델을 직접 조립할 수 있도록 필요한 모든 모양과 색상의 블록을 담은 상자에 완성된 모델의 이미지를 인쇄해 포장한 제품을 배송한다. 나아가 다른 사용자도 원하는 제품을 구입할 수 있다.
결국 레고는 사용자에게 모델링 할 수 있는 도구와 플랫폼을 제공함으로써 레고 디자이너의 수를 늘린 셈이다. 바로 이 점이 개방형 혁신(Open Innovation)의 핵심이다. 언제든지 다른 용도로 재사용할 수 있는 블록을 제공할 뿐 아니라 무한한 조립 가능성을 활용해 자신만의 창의력을 발휘한 레고 제품을 신속하게 만들 수 있는 것이다. 개방형 혁신의 키워드가 바로 기업의 울타리를 넘나드는 활용과 용도 변경, 협업이라는 점과 일맥상통한다.
SAP의 엔터프라이즈 SOA가 바로 이러한 레고의 노력과 유사하다고 하겠다. 다른 SOA 벤더와는 달리 SAP가 제공하는 비즈니스 프로세스 플랫폼(business process platform)인 SAP 넷위버(SAP NetWeaver)와 mySAP ERP 2005는 언제든지 바로 조립할 수 있는 프로세스 컴포넌트와 엔터프라이즈 서비스, 비즈니스 오브젝트 등을 담고 있다. 따라서 사용자는 다양한 색상의 레고 블록을 활용해 자신만의 모델을 완성하듯이 필요한 컴포넌트와 서비스, 오브젝트 등을 이용해 고유한 업무 프로세스를 완성할 수 있다.
개방형 혁신을 추진할 때 염두에 둬야 할 점은 바로 독불장군보다는 관계관리와 협업에 능한 기업이 성공한다는 사실이다. 레고는 자사의 디자이너가 사용하고 있었을 법한 디자인 소프트웨어를 공개 배포함으로써 사용자를 중심으로 디자이너 층을 다변화함으로써 신속한 혁신의 가능성을 높인 바 있다.

비즈니스 애플리케이션 분야의 롱테일
경제학의 기본 전제는 인간의 욕망은 무한한 데 비해 세상의 자원이 한정돼 있다는 데서 출발한다. 따라서 한 가지를 선택하면 다른 대안은 포기해야 하며 선택은 포기한 비용보다 큰 가치를 가져야 한다는 기회비용 같은 개념도 보편화 되어 있다.
한 마디로 경제학은 희소성이 만연한 환경에서 어떤 선택이 최선인지를 다루는 선택의 학문으로 자리 잡아 왔다. 만약 선택의 폭이 무한정 넓어진다면 어떤 일이 생길까? 그래서 누구나 자신이 원하는 것을 쉽게 얻을 수 있게 된다면 세상은 어떻게 변화할까?
이러한 질문에 대한 해답을 찾기 위해 와이어드(Wired) 매거진의 크리스 앤더슨(Chris Anderson) 편집장은 롱테일(The Long Tail)이라는 책을 집필했다. 롱테일 시장에서는 누구나 자신이 원하는 상품(서비스 포함)을 쉽게 빨리 찾을 수 있다. 이러한 롱테일 시장이 가능한 배경에는 생산수단(저작도구) 및 유통수단의 보편화와 함께 필터(사용자 추천, 랭킹, 자동 추천 등)가 필수적이다. 만일 원하는 상품을 쉽게 찾기 어렵다면 결국 무한대에 가까운 대안은 소음에 지나지 않기 때문이다.
롱테일 시장은 히트 상품 위주의 시장에 비해 보통은 몇 백배에서 몇 천 배에 이르는 상품을 갖추고 있다. 대형 서점보다 훨씬 많은 서적을 제공하는 아마존닷컴, 타워레코드보다 몇 백배 많은 음원을 제공하는 아이튠(iTunes)과 랩소디(Rhapsody), 대형 DVD 대여점보다 훨씬 많은 DVD를 제공하는 넷플릭스(NetFlix) 등이 대표적인 사례다. 이들 기업은 상품을 직접 생산하는 대신 수요와 공급을 한 곳에 모아 일치시켜 주는 역할을 하고 있다.
무엇보다 놀라운 사실은 일반 시중 서점에는 없고 아마존닷컴에만 있는 서적의 매출이 아마존 전체 매출의 57%를 상회한다는 사실이다. 또한 랩소디의 경우 히트곡과 틈새 노래 전체의 98%가 최소한 분기별로 한 번 이상씩 다운로드 된다. 이는 자신이 원하는 상품이나 서비스가 어딘가에 있고 이를 찾기 쉽게 해 주면 과거에 파레토 법칙(80/20 법칙)을 앞세워 히트 상품에 주력했던 시장이 점차 롱테일 시장으로 이동함을 의미한다.
그렇다면 비즈니스 애플리케이션의 롱테일 시장은 무엇일까? 그것은 바로 사용자제작 콘텐츠(UCC)와 같이 자신의 필요에 의해 직접 만들어 공유하는 애플리케이션일 것이다. 서비스지향 시대에는 이미 나와 있는 SAP의 다양한 엔터프라이즈 서비스(enterprise service)와 프로세스 컴포넌트(process component)를 조립해 완성하는 컴포지트 애플리케이션이 대표적이다. 이들 애플리케이션은 사용자의 입장에서 자신에게 꼭 맞는 맞춤 제품을 모델링하고 만들어 사용한다는 점에서 앞서 예로든 레고 팩토리의 사례와 유사하다.
SAP와 같은 소프트웨어 기업의 입장에서는 시장성이 높은 제품을 위주로 개발을 하기 마련이다. 하지만 이제 엔터프라이즈 SOA의 확산으로 누구나 자신의 업무에 필요한 애플리케이션을 손쉽게 조립해 구성한 후 제품화 할 수 있는 시대가 성큼 다가왔다. SAP의 개방형 표준 플랫폼과 이 플랫폼이 제공하는 다양한 표준 서비스와 컴포넌트를 재사용해 자신만의 애플리케이션을 완성해 상품화하는 세상. 바로 개방형 혁신에 바탕을 둔 비즈니스 애플리케이션 분야의 롱테일 시장을 여는 지름길이다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.