[SOA 특집 - BEA] BEA가 말하는 SOA

SOA의 도입은 그 자체가 목적이 아니라 기업의 비즈니스 목표를 달성하기 위한 수단이라는 점을 분명히 인지해야 한다. 기업은 무작정 SOA를 도입하기 보다 산업별 기업의 핵심 업무에 맞춘 도입 기대효과 예측 및 목적을 분명히 해야 한다.

예컨대, 금융계의 차세대 시스템의 핵심은 시스템 다운타임이 없이 물 흐르듯 이어지는 금융 서비스를 고객에게 제공하는 것이 가장 큰 목적이 될 것이며, 제조업의 경우 제품수명주기관리(PLM) 솔루션과의 연계를 통한 관리 업무 효율 극대화, 텔레커뮤니케이션 업계의 경우 경쟁사보다 신규 서비스를 신속하게 제공하여 매출을 극대화하는 것이 SOA도입의 가장 큰 효과이자 목적이다.

SOA는 CIO가 기존에 투자했던 애플리케이션들(ERP, CRM, SCM 등)을 한데 묶어 더욱 효과적으로 부가 서비스를 창출 할 수 있으며 어댑터와 연결 모듈 등의 추가적인 비용 지출없이 저렴하게 활용할 수 있게 해 준다.

CIO는 기존 시스템을 제거하고 새로운 시스템으로 대체할 필요가 없이 기존 시스템의 기능들을 파악한 후 그것들을 활용함으로서 위험을 최소화하면서 기존 IT 투자의 가치를 극대화할 수 있다.

SOA 도입을 비용 효과 측면에서 보면 유지보수 비용의 감소와 비즈니스 혁신을 들 수 있다.

"SOA가 제시하는 가장 큰 가치 가운데 하나는 이기종 환경의 통합"이라고 잽싱크의 선임 분석가 제이슨 브룸버그는 말한다. 웹서비스라는 표준 기술을 사용해 복잡한 코드없이 연동할 수 있기 때문에 통합에 대한 비용과 시간을 줄여 준다. 또한 이 코드들은 상당부분 재사용 가능하기 때문에 개발 비용과 시간은 점점 더 줄어든다.

SOA 구축 초기에는 SOA 관련된 기술에 대한 학습과 SOA 전용 소프트웨어 구매 따른 비용이 소요된다. 그러나 SOA 기반의 서비스가 확산됨에 따라 통합의 편이성, 서비스 형태 어플리케이션을 관리하게 됨으로써 개발 시간의 단축과 구축 비용의 절감 효과를 달성하게 된다.

<그림1>SOA 도입으로 인한 비용 효과

SOA 도입시 단기적인 효과를 기대하기 보다는 장기적인 시각으로 접근하는 것이 중요하다. 지금까지 대부분의 IT 인프라 프로젝트들은 내부의 유지비를 효과적으로 줄여서 TCO 감소를 통한 총생산성의 향상을 유도했다. 하지만 이는 장기적으로 볼 때 IT 자산의 재사용 및 서비스간 연결이 쉽지 않아 각 프로젝트마다 새로운 인프라 요소의 추가 및 통합을 필요로 해 시간이 지날수록 비즈니스 민첩성과 IT 자산의 유연성을 떨어뜨렸다.

이에 반해 SOA기반의 인프라는 내부의 비용을 줄여 단기간의 생산성을 높이기 보다, 장기적인 시각으로 기업이 새로운 비즈니스 기회를 포착하여 신규 서비스 프로젝트나 새로운 서비스의 창출 등의 새로운 비즈니스 요구가 있을 때 IT 자원의 재사용과 유연한 데이터 흐름을 보장하여 경쟁사보다 신속한 '타임투마켓(Time to Market)'을 가능하게 한다. 즉 내부보다는 외부에서 수익을 창출하는 형태이며, 시간이 지날수록 그 생산성은 향상된다.

마지막으로 통합이 쉬워지고 민첩성이 높아짐으로써 ROI가 높아진다는 부수적 이익도 맛볼 수 있다.

◆ SOA, 어떻게 구현할 것인가

SOA는 웹서비스 표준 지원, 이미 투자된 애플리케이션 인프라를 활용하기 위한 전사 애플리케이션 통합 하부 구조, 비즈니스 프로세스를 자동화하고 애플리케이션간 비즈니스 프로세스 상호 교환을 위한 서비스 조율, XML과 non-XML, 객체 등 다양한 유형별 데이터 통합 및 맵핑, 기존 콤포넌트 시스템 통합, 서비스 개발 환경을 위한 개발 도구 등을 SOA의 기술요건으로 하고 있다.

SOA는 단순히 웹서비스나 보안 등 IT 기술의 도입이나 웹 애플리케이션 서버(WAS)나 포털 등 특정 솔루션의 도입으로 완성될 수 있는 것이 아니다. SOA는 비즈니스 요구에 신속하게 대응하기 위한 IT 아키텍처 구현하는 방법으로서 전략적이고 장기적인 로드맵을 수립하여 도입해야 한다.

아래 그림에서 보는 바와 같이 전사적 SOA 도입 단계나 SOA 최적화 단계를 목표로 하여 전략적 계획을 수립하는 것이 필수적이다.

<그림2> SOA 도입 성숙도

위의 그림에서 SOA 도입의 성숙도는 6단계로 구분 될 수 있으며 SOA 도입전, 부분적인 SOA 도입, SOA의 반복적 구현, SOA 확립, 전사적 SOA 적용, 마지막으로 SOA의 최적화 단계로 나누어 진다.

이러한 SOA 성숙도를 다시 IT 프로젝트 입장에서 정리하면 SOA의 도입 계획이나 파일럿 단계, 프로젝트 수준에서의 서비스 구현, 부서 차원의 서비스 구현, 전체 부서에서 사용할 수 있는 공유 서비스 구현 마지막으로 전사적 SOA 구현으로 나누어 볼 수 있다.

전사적 SOA를 구현하기 위해서는 세 가지의 항목인 ▲ SOA 도입 전략 수립 ▲ SOA 구현 ▲ SOA 거버넌스 구성으로 정의할 수 있다.

◆ SOA 도입전략 수립

첫번째 SOA 도입 전략 부분에서 BEA는 SOA 구현을 위한 방법론으로 ‘SOA 도메인 모델’을 제공한다.

SOA 도메인 모델은 성공적인 SOA 구현을 위해 반드시 필요한 6개의 핵심 영역을 분석해 SOA에 접근하기 위한 기초를 제공한다. 이 모델은 기업의 비즈니스 전략 및 프로세스, 아키텍처, 구성 요소, 비용 및 이점, 프로젝트 및 애플리케이션, 조직 및 통제에 대해서 다루게 된다.

<그림3>BEA SOA 도메인 모델

BEA의 SOA 도메인 모델에서 다루는 여섯 개의 도메인의 내용은 다음과 같다.

1. 비즈니스 전략 및 프로세스 : 기업은 비즈니스 및 비즈니스의 변화하는 요구를 지원하는 IT 구현을 제공해야 한다. 이 도메인은 IT의 관리 및 평가에 대하여 비즈니스 전략과 연결하는 방안을 제공한다.

2. 아키텍처 : 거의 모든 기업은 비즈니스의 연장선상에서 프로젝트를 진행함으로써 IT 예산을 조달하고 IT를 구축하지만 전사적 프로세스 및 통합은 차후 문제로 미루고 향후 변화에 대해서도 대책을 마련하지 못하게 된다. 아키텍처 도메인은 표준, 분산, 유연한 결합 및 비즈니스 프로세스를 기반으로 IT 환경을 구축하는 가이드를 제공한다. 또한 변화에 대처하고 기업 수준에서 기능을 통합할 수 있도록 설계한다.

3. 빌딩 블록 : IT 구현시 일관성 및 재사용성이 결여되어 대부분의 기업은 IT 예산 및 민첩성과 관련된 목표를 달성하지 못한다. 빌딩 블록은 IT를 통한 업무 적용을 위한 공통된 표준 기반의 토대를 제공한다. 또한 구현 및 핵심 인프라스트럭처의 재사용을 통해 일관성을 얻고 성공을 반복하는 능력을 최대화할 수 있는 기초를 제공한다.

4. 프로젝트 및 애플리케이션 : 전통적으로 IT는 비즈니스 연장선상에서 프로젝트에 의해 개발됨으로써, 중복된 기능에 대한 과도한 자본 소모가 이루어지고 전사적 프로세스의 통합이 뒷전으로 밀리는 경우가 종종 있다. 이 도메인은 시스템 및 애플리케이션에서 제공되는 기능들을 목록화, 범주화 및 재분류하는 데 도움이 됩니다. 또한 중복을 줄이고 일관된 실행을 제공하는 한편 제공되는 기능들에 대해 표준화를 하게 된다.

5. 조직 및 통제 : 엔터프라이즈의 규모가 커지면 변경이 어렵고 변경에 따른 비용이 많이 드는 IT 인프라스트럭처가 생성된다. 이 도메인은 표준 방식으로 IT 프로젝트 구축을 통제하기 위한 조직적 구조 및 권한 생성에 집중한다. 또한 IT의 비즈니스 요구 충족 및 IT 활용의 최적화를 지원한다.

6. 비용 및 혜택 : IT 지원 비용과 IT를 통해 얻어지는 혜택의 비교는 기술 조직과 비즈니스 조직 사이의 지속적인 마찰의 원인이 된다. 이 도메인은 빠르고 지속적인 가치를 창출하기 위한 IT 구현의 계획 및 실천방안을 도출할 수 있도록 한다. 또한 비즈니스 변경과 성장을 수용함과 동시에 기존의 투자를 적극적으로 활용하게 된다.

SOA는 장기적 전략으로서 IT의 구축 방식을 변형하는 데 지속적인 초점을 맞춰야 하지만, 다른 한편으로는 당면한 비즈니스 의사 결정에 빠르게 대응해야 한다. 그 결과 SOA의 이점은 장기적인 목표와 단기적인 비즈니스 요구사항 사이의 균형을 유지할 때 실현할 수 있다.

SOA 추진 계획의 초기부터 조직, 재정, 운영, 설계 및 구축의 방식을 체계적으로 만들어감으로써 그러한 균형을 유지할 수 있다.

◆ SOA 구현 및 거버넌스

SOA 구현 및 거버넌스를 위해서는 SOA 관련 기술들, 빌딩 블록, 아키텍처 그리고 소프트웨어 인프라스트럭처가 필요하다.

서비스기반의 아키텍처 구성과 엔터프라이즈 기능 사용자 및 기능을 제공하는 시스템과 애플리케이션 사이의 서비스 도입을 위한 인프라스트럭처를 구성할 수 있는 수준 높은 '참조 아키텍처'가 필요하다.

참조 아키텍처는 SOA의 주요 콤포넌트 및 이들 상호간의 관계를 설명한다.

SOA는 고유한 속성 및 톱다운식 기능 제공 접근법을 사용하여 거의 모든 부문에 적용할 수 있는 수준 높은 엔터프라이즈 아키텍처를 정의할 수 있다. 이러한 수준 높은 아키텍처(또는 참조 아키텍처)가 SOA의 주요 컴포넌트 및 이들의 상호 관계를 설명한다.

이러한 아키텍처에서는 엔터프라이즈 기능의 사용자가 이를 제공하는 시스템 및 애플리케이션과 분리되며, 그 사이에는 서비스 및 서비스 전달를 위한 인프라스트럭처가 배치된다. 서비스 레이어 및 이를 지원하는 인프라스트럭처를 '서비스 인프라스트럭처 레이어'라고 한다.

기존의 애플리케이션, 데이터 및 미들웨어는 서비스가 공급되는 토대를 형성하게 되며 이러한 기반 인프라스트럭처를 ‘어플리케이션 인프라스트럭처’라고 한다.

기존의 기업 활동을 지원하고 여기에 형식을 부여하는 것이 서비스 지향 인프라스트럭처이다. 표준 기반의 인프라스트럭처 서비스는 모든 다른 유형의 서비스 운영을 위한 공통된 기초를 제공한다.

인프라스트럭처 서비스에는 서비스 관리가 포함되어 서비스제공자의 독립성, 장애 조치, 관리 및 기타 엔터프라이즈급 서비스 품질의 속성을 제공한다. 또한 서비스 버스는 일반 미들웨어 솔루션의 전통적인 메시지 브로커 또는 메시지 버스와 거의 동일한 방식으로 일반 라우팅 및 변환 기능을 제공한다.

<그림4> BEA 참조 아키텍처

위의 SOA 참조 아키텍처에서 언급하였 듯 SOA 구현을 위해서는 애플리케이션 인프라스트럭처와 서비스 인프라스트럭처가 필요하다.

애플리케이션 인프라스트럭처는 기존의 어플리케이션을 서비스하는 플랫폼으로서 WAS , TP-Monitor, EAI나 포털과 같은 미들웨어이다. SOA에서 이러한 애플리케이션 인프라스트럭처의 역할은 기존의 어플리케이션을 서비스로 변환시키고 변환된 서비스를 제공하는 서비스 제공자의 역할을 하게 된다.

서비스 인프라스트럭처는 SOA를 위해 새롭게 등장한 개념의 미들웨어로 ESB, 데이터 서비스 플랫폼 , 서비스 보안 제품 등이 포함된다. 서비스 인프라스트럭처의 역할은 애플리케이션으로부터 배포된 서비스에 대한 운영 관리, 상호운영성 보장, 서비스에 대한 검증, 배포 및 서비스 모니터링과 같은 주로 서비스 거버넌스 관련된 기능을 제공하게 된다.

<그림5> SOA에서 인프라스트럭처 요구

SOA 구현의 핵심이라 할 수 있는 '서비스 인프라스트럭처'는 이기종 플랫폼에 구축된 서비스를 별도 코딩없이 구성만으로 쉽게 서비스를 연결해주고, 표준 기반의 연결성을 제공할 수 있는 ESB(엔터프라이즈 서비스 버스)와 같은 '메시징 서비스 기능', 막힘없는 데이터 흐름을 위해 분산돼 있는 이기종 데이터 저장소간에 데이터를 액세스, 변형 및 업데이트할 수 있는 공용 프레임워크를 제공하는 '데이터 서비스', 인증 및 권한 부여와 자격 증명과 역할 매핑 및 감사에 대한 메커니즘 등을 제공하는 '보안 서비스', 서비스 구성을 변경하고 배치 및 취소 등의 관리를 가능하게 하는 '서비스 라이프 사이클 관리' 등의 기능을 포함하고 있어야 한다.

SOA의 본격적인 도입 움직임에 발맞추어 시장의 관심이 더욱 증가하고 있는 업무 프로세스 관리(BPM)와 생성된 서비스를 최종사용자가 직접 이용할 수 있는 포털의 도입도 SOA의 효과적인 구축을 위해 고려해야 할 사항이다.