2008년 SOA 전망

경영과 컴퓨터 1월호에 기고했던글..

==

2008년 SOA 기술 전망

 

저자  BEA 조병욱 과장 (Sr. consultant of BEA Systems Korea consulting dept.)

블로그 : http://bcho.tistory.com

온라인상의 필명으로 “조대협” 이라는 이름을 사용하고 있으며,온라인 자바사이트 www.javastudy.co.kr의 초대 운영과, 한국 자바 개발자 협의회 jco의 부회장을 맏았으며, SOA 관련 다수의 강의 경력과 컨설팅 경험을 가지고 있다.

 현재는 BEA Systems Korea에서 엔터프라이즈 시스템 관련 컨설턴트로 재직중이다.

 

1. 개요

 본 기고는 2007년의 SOA관련 기술의 흐름을 되 짚어보고, 2008년의 SOA의 기술의 변화 방향에 대해서 전망하여, SOA 를 적용할 기업들의 방향성에 대한 도움을 주고자 하는 기고이다.

 

2. SOA의 기술 계층

먼저 SOA가 어떤 기술 계층으로 이루어져 있는지를 이해하면, 각 계층들의 변화 방향을 통해서 전체 기술 방향의 변화를 인식할 수 있다.

 

(1) SOA의 3단계 기술 계층

SOA는 크게 다음과 같이 3단계 기술 계층을 가지게 되어 있다.

 

1) 서비스 가능화 계층 (Service Enablement Layer)

서비스 가능화 계층의 기존의 레거시 시스템 (기존에 운영되고 있는 시스템)들을 비즈니스의미를 갖는 단위의 컴포넌트로 묶고 표준화된 인터페이스로 시스템 외부로 서비스를 제공할 수 있도록 해주는 계층이다.

현재에 유행하고 있는 웹서비스 중심의 SOA에서는 레거시 시스템들의 기능들을 웹서비스로 노출 시키고, 노출되는 컴포넌트 단위를 비즈니스 업무 단위로 크게 묶는 계층을 정의한다.

 

각각의 시스템들이 표준화된 인터페이스를 통해서 기능을 제공하기 때문에, 이 계층에서는 타 시스템간의 통합(Integration)이 용이하게 된다.

* 키워드 : 비즈니스 업무 단위, 표준화 인터페이스, 서비스화, 시스템 통합

 

2) 서비스 허브 계층 (Service Hub Layer)

서비스화된 각각의 업무 컴포넌트간의 통합과 호출은 각 시스템 대 시스템으로 이루어지기 때문에, P2P 구조를 가지게 되고 결국 이는 시스템간의 복잡도를 증가 시켜서, 시스템간 연계 Topology가 마치 거미줄 처럼 복잡화된 구조를 가지게 된다.

이런 복잡한 Topology를 중앙에 공용 Bus를 넣어서 Hub & Spoke 방식으로 중앙 집중형 통제 구조를 가지게 하여 복잡성을 제거하고, 관리의 용이성을 증가 시키며, 이 Bus 안에 유연성을 가미할 수 있는 서비스 - Intermediary 서비스를 추가하여 시스템의 업무에 대한 유연성을 높인다.

 

 Intermediary 서비스란, 예를 들어 백화점의 구매 프로세스가 있었다고 가정하자 그런데 이 백화점에서 VIP 고객을 위한 특별한 포인트라는 신규 업무를 만들었을 경우에, 백화점 구매 프로세스에 변경을 가해서 포인트 적립하는 비즈니스 로직을 추가하거나 또는 백화점 구매 프로세스를 호출하는 쪽에서 포인트 적립을 하는 서비스를 호출해야 하는 것과 같이 ‘서비스 제공자’나 ‘서비스 사용자’ 에 대한 로직 변화가 필수적 이었다.

 이 문제를 해결하기 위해 ‘서비스 제공자’와 ‘서비스 사용자’ 사이에 중간자 적인 역할을 하는 Intermediary 서비스를 넣어서, ‘서비스 사용자’는 예전과 똑같은 방법으로 서비스 제공자를 호출하지만 이 Intermediary 서비스에서 고객의 정보에 따라서 VIP 고객일 경우, VIP 고객용 서비스로 라우팅(경로변환)을 함으로써 ‘서비스 사용자’와 ‘제공자’의 로직 변환 없이 그대로 변경된 업무를 유연하게 반영할 수 있도록 할 수 있다.

* 키워드 : 버스, 유연성의 추가

 

3) 서비스 조합 계층 (Service Orchestration Layer)

서비스 가능화 계층과, 서비스 허브 계층을 거치면 시스템의 업무들은 모두 비즈니스적인 의미를 가지고 표준화된 인터페이스를 통해서 서비스 허브에 집중화된 형태로 존재하게 된다.

이 서비스 업무하나하나를 조합하여, 현업에서 필요한 ‘비즈니스 업무 흐름’으로 구현해야 하는데, 이 계층이 서비스 조합 계층이다.

 이 계층에서는 비즈니스 업무 흐름을 조합하고, 이 조합된 업무 흐름을 사용자 인터페이스 (UI)로 보여주는 역할을 수행한다.

 

* 키워드 : 서비스 조합,업무 구현, 통합 사용자 인터페이스

 

(2) SOA 기술 계층별 사용 기술과 발전

지금까지 전통적인 SOA의 각 기술 계층이 어떤 역할을 수행하는지를 살펴보았다. 그렇다면 각각의 기술 계층들은 어떤 구체화된 기술을 이용하여 구현이 되어왔을까?

 

1) 서비스 가능화 계층 기술

서비스 가능화 계층에서 사용된 서비스 가능화 기술은, 기존 레거시 시스템의 기능을 서비스화 해주기 위한 “아답터”와, 여러 형태로 저장된 데이터들을 서비스 기능 형태로 변환해주는 “데이터 서비스” 기술이 그 주류를 이루어 왔다.

 또한 각각의 분리된 시스템 업무를 묶어서 하나의 서비스 업무로 변환하기 위해서 시스템간의 통합이 필요하게 되었는데, 이를 위해서는 EAI (Enterprise Application Integration)기술이 사용되었다.

 

 2008년의 서비스 가능화 계층 기술에서 눈 여겨 볼만한 기술적인 이슈는 SCA (Service Component Architecture)이다. SCA는 소프트웨어를 개발함에 있어서 각각의 Service Component로 다루어 이러한 서비스들을 조합하여 플랫폼에 중립적인 서비스로 재조합 한다는데 의미를 두는데, 특히 이 기술의 경우에는 기존의 SOA와는 다르게 명시적으로 WEB 2.0에 대한 프로토콜 (RSS,ATOM,JSON,Hessian etc)등을 폭 넓게 지원하여 좀더 개방적인 서비스 가능화 기능을 제공한다는 것이다.

 SCA를 통해서 서비스 자체에 대한 생성에 필요한 통합 기능이 증대될것이며, 서비스 가능화 계층에 필요한 “아답터”,”데이터 서비스”,”EAI” 솔루션들은 아직까지 몇몇 선두 SOA업체만이 보유하고 있기 때문에, SOA를 지향하는 솔루션 업체라면 이 기술 계층을 마련하기 위한 노력들이 뒷 따를 것이며, 이미 이러한 솔루션을 가지고 있는 기업들의 경우에는 이 기술들의 성숙도를 높이는데, 포커싱이 될것이다.

 

2) 서비스 허브 계층 기술

다음으로 서비스 허브 계층은 SOA에서 흔히 이야기 하는 ESB(Enterprise Service Bus)으로 대변되었던 한해였다. 이 서비스 허브 계층을 통해서 각각 다른 형태로 존재하는 시스템들이 통일화된 인터페이스를 가지고, 각각의 분리된 시스템들이 비즈니스 업무 단위로 통합 되면서 하나의 서비스로 형태가 변화게 된다.

 즉 서비스 허브 계층에 대한 요구 사항이 기존의 유연성의 증대와 중앙 집중화된 버스 방식에 더해서, 분리된 시스템 업무간의 통합 기능이 추가 되었다.

 

 기존의 EAI 솔루션을 통해서 수행되던 시스템 통합 기능이 서비스 허브 계층으로 올라오면서 SOA에 적절한 형태 (웹서비스의 지원, ESB와의 통합성)로 변화되면서 서비스허브에 통합되도록 진행되고 있다. EAI 솔루션과 ESB 솔루션간의 통합성 문제와, ESB 솔루션을 사용할 때, 시스템 통합에 대한 요건이 필수 불가결하게 발생하기 때문에, 이에 대한 기능이 흡수 통합되는 모델이다.

 

 특히 SOA 모델에서 자주 언급되는 , Process에 대한 이야기에서 “Process의 주체와 목적이 누구인가?”이다. EAI와 BPM에 각각의 Process가 있었고 두개의 Process의 존재로 인해서 많은 혼동을 초래하였다. 이러한 Process들은 크게 비즈니스 사용자위주의 사용자 프로세스(Human centric process)와, 시스템 통합에 필요한 시스템 프로세스(System integration process)로 나뉘어 지고, 이를 각각 ‘BPM과’ ‘EAI의 Process’로 분리되었고, 이 시스템 프로세스가 서비스 허브 계층에 통폐합 되는 형태로 변화 될것이다..

 

3) 서비스 조합 계층 기술

서비스 허브 계층의해서 제공되는 서비스는 전통적인 SOA에서는 사용자 애플리케이션에서 직접적으로 조합하여 사용하거나 프로세스가 있는 업무의 경우에는 BPM을 사용하는 절차로 가이드되어 왔었다. 여기에 BPA,BAM을 통한 비즈니스 프로세스의 설계와 모니터링을 통한 프로세스 개선에 목적이 맞춰져 왔으나,  실제 업무에서 BPM이 필요한 경우는 복잡한 업무 프로세스가 존재하는 경우이고, BPM을 사용할 수 있는 수준의 SOA 성숙 수준까지 시스템이 발전하기 전까지는 각각의 서비스들을 애플리케이션에서 조합해서 사용하는 수준인데, 이 역시 별다른 기술적인 대안이 존재하지 않았다.

 이에 대한 대안으로 제시될 수 있는 것이 SCA이다. 앞에서도 설명했듯이 SCA는 컴포넌트에 대한 조합 기능을 제공하기 때문에, 상태나 장기적인 프로세스를 갖는 업무가 아닌 일반적인 업무 조합에서는 SCA를 통해서 충분하게 조합이 가능하게 된다.

 

 이렇게 조합된 업무들은 사용자 인터페이스 (UI)를 통해서 사용자들에게 제공이 될것인데, 업무별 또는 조직이나 사용자별의 업무 제공 UI를 Enterprise Portal (EP)로 제공되어 왔던것에 더해서 WEB 2.0의 개념을 도입한 POA의 개념으로 업무에 대한 서비스가 사용자에게 제공될것이다.

 

 POA란 (Participant Oriented Architecture)의 약자로, 사용자 참여 중심의 아키텍쳐를 이야기 한다. 요즘 “공유하지 않으면 망한다..” 라는 말이 있듯이 현재 e-비즈니스 환경은 위키나 블로그등으로 대변되는 참여 중심의 WEB 2.0 환경으로 변화하고 있다.

마찬가지로 기업의 비즈니스 환경 역시 공유와 참여가 필요로 하게 되는데, 서비스화된 업무들을 OPEN API 형태로 외부에 제공하거나 또는 부서별이나 개인별로 각각의 업무에 맞춰서 워크플레이스를 Mash-up (매쉬업)을 통해서 조합하여 기업의 다양한 업무 요건에 대한 대응을 더 이상 IT 부서에만 일임하는 것이 아니라, IT 부서는 업무를 위한 컴포넌트를 제공하고, 실제 현업에서 구성할 수 있는 형태의 개방성을 부여하는 기능이 제공될것이다.

 또한 태그 방식의 검색등을 통해서 기업내에 흩어져 있는 자산과 서비스들에 대한 사용성이 높아지게 될것이고, 이는 기업내의 지식과 자산의 공유를 가속화 시킬것이다.

 

 

3. SOA 2008

이렇게 변화된 각 계층간의 모델을 정리해보면 다음과 같다.

2007년까지는 SOA 의 개념이 도입되고 정리되는 기간이었고, 기업에서는 이런 개념들을 관측하고 평가해왔으며, 발빠른 업체는 SOA의 도입을 시작하였다.

2008년에는 SOA의 관련 기술이 성숙단계에 들어서고 기업들 역시 적극적으로 SOA의 도입을 준비할것이다.  2007년에 진행되었던 SOA의 경험들을 바탕삼아 벤더에서 제공하는 SOA기술들은 개념으로만 떠드는 SOA가 아니라 고객의 요구사항을 충분히 반영한 실용주의성의 사상과 솔루션으로 발전되어서 부족한 기술이나 쓸모없는 기술은 도태되고 필요한 사상이나 기술들은 점점 더 진화되는 한해가 될것이다.

 또한 오픈소스 진영을 중심으로 발전한 WEB 2.0 관련 기술과 참여 공유의 사상은 기업의 SOA 시스템의 사상에 급속하게 녹아들면서 POA라는 이름으로 영향을 줄것이다.

 

 특히 현대의 기업의 IT 부서는 예전과는 달리 ROI가 적거나 RISK 가 높은 기술에 대해서는 점점 도입을 꺼리고 적극적인 검증을 통한 실용적이고 합리적인 경향이 높아졌기 때문에, 아직 SOA 기술에 진입하지 않은 기업은 SOA를 적극적으로 검토하는 한해가 될것이고, 이미 SOA 기술에 진입한 발빠른 업체들은 다른 기업보다 앞서서 자사의 SOA 모델을 성숙시켜가고, 비즈니스 모델에 적용해 나가면서 빠르게 변하는 업무 환경에 빠르고 유연하게 대응할 수 있는 IT 시스템들을 갖추게 될것이다.

“제이슨 블룸버그”의 말처럼, “SOA를 하지 않는 기업은 망한다.”