SOA가 우리에게 제시하는 많은 기대 효과가 현실화되지 못하는 원인이 무엇이며, 이를 개선할 수 있는 방안은 무엇일까. 더불어 기업에 도입 운영되는 SOA 구현과 운영의 수명주기(Life cycle), 각 단계별 고려사항을 알아야할 필요가 있다.

우리는 그동안 주어진 시간 내에 최소한의 비용으로 프로그램을 개발하기 위한 방안으로 전사 차원의 표준화나 타 프로젝트에서 만들어진 모듈의 재사용을 검토할 여유 없이 그 때마다 사용자가 요구하는 비즈니스 단위 기능들을 구현해 왔다. 이렇게 만들어진 시스템들로 인해 동일하거나 거의 유사한 비즈니스 기능들이 무수히 많은 단위 애플리케이션에 중복 개발 운영되고 있으며, 또 단위 시스템간의 중복된 정보의 정합성을 유지하기 위하여 무수히 많은 인터페이스를 개발 관리하고 있다.  

SOA란 신규 애플리케이션의 개발 요구에 대해 전면 재구축 보다는 기존에 보유한 IT 자산을 서비스화하여 이를 연계 구현함으로써 재사용성을 극대화하고자 하는 사상이며, 이를 전보다 훨씬 더 구체적으로 지원하는 방법론과 개발 프레임워크, 개발 및 운영 툴을 통칭한다.

SOA 성공의 첫걸음, ‘명확한 목표’

무슨 일을 추진할 때 조직 구성원들이 목표를 명확히 인식하고 하나가 되어 이를 이루고자 집중하는 경우와 목적성 없이 남들이 모두 하니 뒤지지 않기 위해 시작하여 주어진 결과물을 만들어 내는 데에만 몰두하는 경우 그 결과는 엄청나게 다를 것이다. SOA를 이용해서 시스템 개발 시에 중복적인 컴포넌트의 양산을 막고 전사적인 관점에서 재사용 가능한 서비스를 만들어 이를 재사용함으로써 단위 기능의 중복을 배제한다. 이를 통해 불필요하게 늘어나는 인터페이스를 없앰으로써 장기적인 관점의 IT 비용 절감을 가져 올 수 있다.  

서비스의 품질과 경쟁력이 평가되는 것을 기본적인 특성으로 하는 서비스 개념을 기업 내 프로세스와 IT 인프라에 접목함으로써 단순한 업무 흐름의 자동화 관점이 아닌 보다 분석적이고 생산성있는 업무 서비스를 만들어 가도록 기업 문화의 변화를 추구할 수 있다. 표준 기술과 사전에 보안이나 필요한 타 서비스와의 연동을 고려하여 설계 개발된 인프라를 갖춤으로써 언제든지 국내외를 막론한 협력업체 소싱이나 활발한 인수 합병을 보다 빠르고 효율적으로 지원할 수 있는 비즈니스 역량을 갖게 될 것이다. 

목적없는 모방 지양

SOA가 제시하는 모든 기대효과를 바라보면서 모호한 목표를 세우고 정작 최소화된 사업 투자로 전혀 기대효과와는 거리가 먼 접근법을 구사하는 프로젝트를 우리는 주위에서 어렵지 않게 접할 수 있다. 신기술 경향에 대한 목적 없는 모방보다는 정확히 우리는 어떤 기대효과를 내고자 하며, 어떤 목표에 집중할 것인가를 명확히 해야한다. 프로젝트를 추진하는 모든 조직원이 이 목표에 집중하게 하는 것이 SOA의 성공을 가져올 수 있는 첫걸음이자 이를 통해 SOA가 제시하는 많은 실익을 차지할 수 있는 유일한 길일 것이다.

SOA 구현의 라이프사이클

·모델(Model)
비즈니스의 새로운 서비스 구현 요구나 기존 서비스에 대한 변경 요구를 구현하기 위해서 가장 먼저 필요한 일은 비즈니스 프로세스를 설계 정의하는 것이다. 과거에는 컨설턴트나 기업 내의 해당 비즈니스 전문가가 선진사례를 참조하여 최적의 프로세스 모델을 일반 문서 파일로 작성 정의하여 이를 자동화하는 형태로 이뤄진 것이 일반적인 경우이다. 

또한 이렇게 만들어진 산출물은 해당 프로젝트가 끝나고 난 후에 기업 내에서 재사용되거나 이를 유지보수하며 계속 사용하는 경우도 드물었다. 그런데 고객의 다양한 요구와 극심한 시장 경쟁은 물론이고 인터넷의 이용으로 고객의 제품/서비스에 대한 반응이 신속하고 대규모로 이뤄지는 상황에서 일회성 프로젝트에 의해 프로세스를 설계하고 이를 자동화하는 형태로는 경쟁력을 유지할 수 없게 됐다.  

또한 애즈-이즈(As-Is) 프로세스의 이슈를 전면적으로 개선하고자 전혀 다른 투-비(To-Be)를 설계하고 이를 통해 비즈니스 환경을 개선하기 보다는 운영되고 있는 프로세스를 있는 그대로 인정하고 객관적이고 데이터로 증명되는 개선의 기회를 찾아 지속적으로 프로세스를 개선해 내고자 하는 고객들이 늘어나고 있다.

최신 표준기술 지원

설계된 프로세스 모델을 전면 재설계하지 않아도 언제든지 변경 유지 보수할 수 있도록 최신 표준 기술을 지원하고, 서비스 구현까지 연속성을 제공하는 비즈니스 프로세스 설계 툴을 이용하여 프로세스 설계를 수행한다. 또한 시뮬레이션 기능을 제공하는 최신 비즈니스 모델링 툴을 이용함으로써 설계하고 있는 프로세스를 실제로 현장에 적용하기에 앞서 설계 단계에서 프로세스를 선 최적화하게 된다. 이를 통해 더 이상 프로세스 모델링은 컨설턴트들에 의한 프로젝트성 업무가 아닌 기업 내의 프로세스 관리 팀에 의해 상시화된 업무가 될 것이다.  

최근에는 단위 업무 프로세스 설계에 국한하는 것이 아니라 전사 차원의 프로세스 분류체계를 수립하고 전사의 모든 프로세스와 해당 성과 지표 등을 자동화된 시스템에 보관하여 이를 참조한다. 이로써 직원 개개인의 업무 역량과 무관하게 좀 더 표준화되고 균일한 품질의 프로세스가 수행될 수 있도록 지원하는 노력이 늘어나고 있다.

·조합(Assemble)
설계된 프로세스 모델을 업무에 그대로 적용하기 위하여 기존에 운영되고 있는 애플리케이션 내의 서비스를 서로 연계하거나 신규 서비스를 개발하여 설계된 프로세스를 그대로 지원하는 프로세스 자동화 인프라를 구현한다. 

변경 요구에 따른 대응 필요

과거와 다른 점은 설계된 프로세스 워크플로우를 애플리케이션 내에 하드 코딩 하거나 각 단위 프로세스 액티비티(activity) 지원 모듈들이 서로 긴밀한 연결 형태로 종속적인 관계를 형성하게 하는 데서 벗어나, 단위 액티비티를 지원하는 컴포넌트나 서비스를 서비스 통합을 지원하는 미들웨어 등을 이용해 느슨한 연결 형태로 연동 운영하도록 함으로써 새로운 요구사항 출현이나 변경 요구에 보다 빠르게 대응할 수 있도록 하는 것이다. 

기존에 투자된 IT 자산에서 재사용할 부분을 최대한 찾아 활용함으로써 기업의 IT 인프라에 중복성을 배제하도록 하는 것과 애플리케이션에 다양한 비즈니스 룰과 컴포넌트간의 연계로직을 배제한다는 점이 SOA 구현의 가장 큰 특징이라 할 수 있다. 

이를 위해서는 기업 내 모든 설계자와 SI 사업자들의 기존 서비스 활용에 대한 노력은 물론, 기업 내에서 전사 차원의 서비스를 관리 운영하며 프로젝트에서 이를 사용하도록 가이드하는 전담 조직이 형성되어야 한다. 서비스 연계나 신규 서비스 개발에 표준 기술인 웹서비스를 도입 적용함으로써 언제든지 기업 내의 인터페이스가 기업 외의 협력업체나 인수합병 파트너와의 인터페이스가 되거나 해도 보다 유연하게 연계 통합될 수 있도록 하는 것도 중요한 SOA의 구현 요소라 하겠다.  

그런데 현재 운영되는 애플리케이션의 모든 단위 기능 모듈을 서비스화하고 이 서비스는 모두 웹 서비스로 정의 운영되어야 하는 것이라고 이해하고 있다. 하지만 서비스 대상을 설계하는 것은 애플리케이션으로부터 모든 단위 로직을 분리해 서비스라 부르는 것이 아니라 비즈니스 관점에서 exposure가 필요하고 서비스로 운영되어질 만한 가치가 있는 대상을 추출하여 설계하는 것이 중요하다. 

설계된 서비스를 웹 서비스로 구현할 때는 현재 기술의 발전 상황이나 현재의 트랜잭션 미들웨어에 비해 상대적으로 응답 시간(response time)이 많이 소요되는 SOAP XML parsing이나 인코딩(encoding)과 암호화(encryption) 등 웹서비스 보안을 통해 구현하는 것이 효율적인지를 고려하여 이에 적절한 아키텍처적 의사결정을 내리는 것도 중요하다.

·배포(Deploy)
구현 조립된 서비스나 신규로 개발된 서비스를 포털 솔루션을 이용해 인프라 접점을 통합하거나, 프로세스 통합 관리 솔루션을 이용해 프로세스를 통합하거나, 정보 통합 솔루션을 이용해 다양한 플랫폼에 분산된 정보를 통합하는 등 다양한 기술 요소를 이용해 프로세스를 실제 업무에 적용 운영한다. 

통합 솔루션은 업계 표준 기술을 수용하고 이를 적극 지원하는 것을 선정해야 향후 이기종 플랫폼에서 운영되는 서비스를 통합하고 자유로운 기업의 통합을 효과적으로 지원할 수 있을 것이다. 이 때 중요한 점은 복합 애플리케이션 환경에서 SOA 타깃 아키텍처 참조 모델이나 SOA 구현 정책 및 기술 지침에 따라 각 서비스 계층 구조를 분명히 한다. 

더불어 인프라의 무분별하고 계층의 성격이 모호한 복잡한 애플리케이션 패키징을 막고 서비스의 배포시 이에 대한 영향도에 대한 분석을 통해 기존에 운영되고 있는 타 서비스에 영향을 최소화하도록 추진할 수 있어야 한다. 서비스의 배포 과정도 전사 차원의 SOA 전담팀과 서비스 라이프사이클을 관장하는 표준 프로세스에 의해 체계적으로 이루어져서 에러를 최소화해야 한다. ESB란 SOA를 지원하기 위한 벤더와 무관한 메시지 연동 기반을 의미하며, 이는 웹 서비스 기술에 기반해 실현될 것이다. 

과거의 EAI에서는 각 단위 애플리케이션이나 컴포넌트들을 어댑터를 통해 연동하는 방식이었다. 각기 다른 벤더의 EAI가 서로 호환 운용되지 못하는 한계를 가지고 있었던데 반해, SOA에 기반한 서비스 통합은 단위 애플리케이션이나 시스템이 모두 웹 서비스를 이해하고 웹 서비스로 연동 가능한 스마트 클라이언트(smart client)가 되어 더 이상 어댑터가 필요없고, 어느 벤더의 솔루션이건 서로 호환 운용성을 제공하게 된다. 오늘 현재 ESB가 과거 EAI 미들웨어가 지원하던 모든 기능을 전적으로 대체하지 못함으로 인해 당분간은 EAI 메시지 브로커와 ESB 솔루션의 양립이 불가피한 상태에서 공존하고 있다.

·운영(Manage)  
실제 업무에 적용되어 운영되고 있는 애플리케이션과 서비스를 관리하고 서비스 접근 권한 및 사용자의 인증관리 등 서비스 운영의 품질을 유지하기 위한 제반 관리 활동을 수행한다.  또한 설계된 비즈니스 프로세스 서비스의 운영 현황과 비즈니스 성과 지표를 중심으로 한 비즈니스 운영 환경을 모니터링한다. 

비즈니스 서비스의 IT 인프라 모듈 운영환경까지 연계해 모니터링하여 기업 내에서 발생한 문제점을 실시간으로 알려줌으로써 즉시 해결 가능하도록 한다. 또한 트렌드 분석과 미리 정의한 비즈니스 룰을 통해 발생 가능하다고 판단되는 위험요소를 사전에 인지하고 이를 해소하도록 함으로써 서비스의 보다 안정적인 운영 환경은 물론이고 지속적이고 점차적인 프로세스 개선의 상시화를 실현할 수 있다.

SOA, 비즈니스 요구를 기반으로 단계적으로 실현하라

과거의 애플리케이션 라이프사이클은 운영 관리 단계에서 애플리케이션 선셋으로 운영 주기를 마치는데 반해, SOA의 라이프사이클은 closed loop로 다시 모델로 이어지게 되는 점이 차이점이라 할 수 있다. OO나 CBD가 특정 업무에 적합한 방법론이 아닌 것처럼 SOA란 적용 대상 업무가 따로 있는 것이 아니라 우리가 IT 인프라 자원을 설계하고 이를 구현 운영해 나가는데 있어 과거부터 추구해 오던 바를 최신 기술을 도입한 상용화 툴의 발전으로 한층 더 구체적으로 현실화 할 수 있도록 된 것이다.  

모든 기업은 오늘도 인터페이스 표준화나 기존 애플리케이션의 업그레이드, 또는 신규 애플리케이션 개발 등 다양한 IT 인프라 변화 니즈를 접하고 있으며, SOA란 지금부터 시작할 것인가만 고민하고 결정하면 되는 것이다.
또한, SOA란 내가 가진 역량과 내가 갖지 못한 역량을 구해서 손쉽게 새로운 비즈니스 혁신을 추구할 수 있도록 지원하는 기업 혁신의 ‘이네이블러(enabler)’인 것이다.

그러나 이런 모든 것은 기업들이 자신의 비즈니스 서비스를 이네이블하는 첫 단계를 건너뛰고 곧바로 실현될 수는 없다. 가능성을 인식하고 먼저 시도하는 기업은 그로 인해 더욱 많은 기회를 볼 수 있고 누리게 될 것이다. 하지만 변화를 거부하고 의심을 품으며 이미 검증된 성공의 모델만 모방하려 드는 기업은 그로 인해 기회 손실을 감수하게 될 것이다.

SOA란 하지 않아도 될 일을 하는 불필요한 투자로 시작되는 것이 아니라 필요한 인프라의 구조화와 최적화의 노력을 서비스 지향적으로 시작하는 노력이다. 일거에 전사 아키텍처를 통째로 변화하는 빅뱅 방식의 위험을 감수하기 보다는 목표와 전략의 수립 하에 단계적으로 비즈니스 니즈를 기반으로 실현해 나가는 것이 맹목적인 SOA 추구에의 비난과 혼란을 피할 수 있으며, 단계적인 접근 전 기간에 걸쳐 연속적인 SOA 거버넌스가 반드시 함께 이뤄져야 한다.

[IT TODAY 2007년 창간호 게재]