한국HP 컨설팅 사업본부 수석 컨설턴트
@hp.com
최근 많은 미디어들과 세미나들에서 SOA가 이야기되고 있고, 이를 통하여 SOA에 대한 개념 즉, SOA가 무엇인지에 대해서는 많은 이해를 갖게 되었다고 생각한다. 따라서 본 기고에서는 SOA가 무엇인지에 대한 논의는 이야기를 풀어나가기 위해 필요한 정도로만 핵심을 요약하는 수준에서 언급하고, 어떻게 SOA를 구현할 지에 중점을 두고 논의해 보고자 한다.
SOA란 무엇인가?
개요
현대의 치열한 경쟁에서 개인들의 성공은 한정된 시간을 어떻게 효율적으로 관리하느냐에 달렸다는 주장이 많은 공감을 얻고, 이를 도와주는 많은 도구들이 상품화되어있다. 기업이 처한 비즈니스 환경 또한 개인의 이러한 상황과 크게 다르지 않다.
선진 기업들은 경쟁 우위의 원천으로 시간을 중시하고, 비즈니스 수행을 위한 제품 기획과 개발, 생산, 재고 관리 등의 프로세스를 IT를 활용하여 자동화하고 최적화하여 빠르게 변화하는 시장 요구에 즉각적인 비즈니스 의사 결정으로 대응하는 시간 경쟁 우위 실시간 기업(RTE: Real-Time Enterprise) 구현에 심혈을 기울이고 있다.
그렇다면, RTE로 진화하기 위해 반드시 수행하여야 하는 핵심 단계는 무엇일까? 그것은 바로 기업의 IT 아키텍처와 프로세스의 현대화이다.
왜냐하면, RTE를 이룩한 기업의 IT는 어플리케이션 시스템을 통하여 관련 정보를 당사자들에게 지체 없이 제공하여야 할 것인데, 이는 모든 송수신 주체들이 연결되어 있다는 가정에 바탕을 두고 있고, 여기서 이야기하는 송신의 주체는 다수의 기업에 속해 있을 것이므로, 기업간 애플리케이션의 실시간 비즈니스 정보 교환을 지원하는 네트웍을 필요로 하게 된다.
여기서의 네트웍간 연결이란 네트웍의 단순한 물리적 연결이 아니라 비즈니스 프로세스를 수행하는 애플리케이션의 연결을 의미한다. 이를 위해서는 IT 아키텍처와 프로세스의 현대화가 필수적이고, 이를 지원할 수 있는 여러 아키텍처들 중 최적의 아키텍처가 서비스 지향 아키텍처(SOA: Service-oriented architecture)라는 것이다.
SOA라는 단어는 1996년 가트너에 의해 처음으로 사용되기 시작한 후, 최근 웹 서비스의 강력한 부상으로 다시 주목 받고 있다. 웹 서비스는 기술의 발전으로 이전의 다른 어떤 기술들보다 더 훌륭하게 SOA 소프트웨어 설계 원칙들을 지원할 수 있게 되었고, 이는 많은 주류 사용자들의 SOA에 대한 관심을 불러 일으켰으며, 이에 따른 SOA 선진 성공 사례는 또다시 웹 서비스의 성공을 도와주는 상생 관계를 형성하고 있다.
정의
SOA는 "서비스 제공자와 사용자가 합의된 계약(또는 인터페이스)을 통하여 느슨하게 연계(Loosely coupled)된 소통을 지원하는 아키텍처를 만들기 위해 필요한 원칙들의 모음"으로 정의된다.
여기서 말하는 느슨한 연계는 서비스 사용자는 자신이 필요로 하는 서비스의 가치(What)에만 집중하고, 서비스 제공자는 사용자가 필요로 하는 서비스를 어떻게(How) 구현할 것인가에만 집중할 수 있는 관계를 의미한다. 그리고, 서비스 사용자와 제공자는 그들 간의 소통을 정의하는 계약(또는 인터페이스)의 합의를 통해 연계되어진다.
즉, SOA는 애플리케이션에서 비즈니스 로직을 분리하여 하나 또는 여러 개의 소프트웨어 모듈에 포함시킨 후 잘 정의된 공개 인터페이스를 통하여 프로그램적으로 접근할 수 있게 노출시키는 방식의 애플리케이션 소프트웨어 토폴로지(Topology)이다. SOA는 기본적으로 소프트웨어 서비스와 이를 사용하는 소프트웨어 서비스 소비자로 구성되는 클라이언트/서버 소프트웨어 디자인 접근 방식을 취하고 있다.
그러나, SOA가 클라이언트/서버 모델과 다른점은 SOA에서는 소프트웨어 컴포넌트들 사이의 느슨한 연계를 지원하고, 각기 분리 독립된 인터페이스를 사용한다는 점이다. SOA의 핵심 속성들은 '<표 1> 핵심 SOA 속성'과 같이 정리될 수 있다.
비즈니스와 IT, IT 기술 발전의 역사 속에서 SOA의 위치는 어디인가?
지금까지 SOA의 태동 배경과 정의, 속성에 대해 간략히 알아보았지만, 비즈니스 배경에서 SOA 정의로 진행된 논의 전개가 갖는 많은 간극이 이해를 어렵게 했을 것으로 생각된다.
여기서는 비즈니스 요구와 IT 기술간의 정렬(Alignment)이라는 관점에서 SOA가 갖는 위치와 클라이언트/서버, 객체(Object), 컴포넌트 등과 같은 이전 기술 요소들과의 차이점들을 살펴봄으로써 SOA에 대한 이해의 폭을 넓혀보도록 한다.
비즈니스와 IT 기술
앞에서 선진 기업들이 경쟁 우위의 원천으로 시간으로 중시하고, 이를 구현하기 위하여 시간 경쟁 우위 실시간 기업(RTE)의 구현에 심혈을 기울이게 되었으며, 구체적인 실현 방안인 IT 아키텍처와 프로세스의 현대화에 SOA가 최적임을 언급하였다. 여기서는 IT 아키텍처와 프로세스의 현대화 부분에 대해 좀더 상세히 살펴봄으로써 비즈니스와 SOA 사이의 간극을 메워보도록 한다.
IT 아키텍처는 IT가 비즈니스 전략 수행을 지원하는 전략적 도구로 자리매김하면서 조직의 전략적 비즈니스 목표와 정보 자원의 효율적 관리, 비즈니스 민첩성 목표를 달성하기 위해 필요한 새로운 정보 기술의 획득과 기존 정보 기술의 유지 및 진화 발전을 위한 통합 프레임웍으로 등장하였다.
이 IT 아키텍처는 EA(Enterprise Architecture:전사 아키텍처)와 기술 참조 모델(Technical Reference Model), 표준 프로파일(Standards Profiles)로 구성되고, 대표적인 EA 프레임웍으로는 TOGAF(The Open Group Architecture Framework)와 Zachman Framework, Index Framework, FEAF(Federal Enterprise Architecture Framework), TEAF(Treasury Enterprise Architecture Framework), C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) Architecture Framework 등이 유명하다.
이들 EA 프레임웍들은 표현 방식의 차이는 있으나, 내용적으로는 모두 비즈니스, 애플리케이션, 데이터, 기술 아키텍처들을 내포하고 있다. 이들 아키텍처 중에서 애플리케이션 아키텍처 부분을 SOA가 담당하여 EA 프레임웍이 목적으로 하는 조직의 전략적 비즈니스 목표와 자원의 효율적 관리, 비즈니스 민첩성 목표 달성에 일조하고 있는 것이다.
이와 궤를 같이하여, HP는 현대의 빠른 비즈니스 환경 변화에 민첩하게 대응하는 기업을 어댑티브 엔터프라이즈(Adaptive Enterprise)로 정의하였다.
그리고, 비즈니스와 IT를 새로운 차원에서 통합하여 어댑티브 엔터프라이즈 구현을 지원할 수 있는 프레임웍을 만들어 다윈 아키텍처(Darwin Architecture)로 명명하고 있다.
어댑티브 엔터프라이즈를 위한 다윈 아키텍처는 기업의 비즈니스 목표와 전략, 비즈니스 및 애플리케이션, 인프라스트럭처 서비스로 구분되는 계층을 씨줄로 하고, 이들 계층이 어우러져 이루어지는 서비스의 제공과 그 서비스 제공의 관리, IT 비즈니스 관리를 날줄로 엮어 비즈니스와 IT간의 한 방향 정렬과 IT 자원의 효율적 관리, 민첩한 비즈니스 변화에의 대응을 지원하는 체계로 이루어져 있다.
이 HP의 다윈 아키텍처에서 애플리케이션 서비스 계층을 지원하는 하위 아키텍처는 SOA를 기반으로 하게 된다.
분산 소프트웨어 기술 진화의 역사
SOA는 새로이 창조된 것이 아니라 기존의 여러 분산 기술들의 발전을 바탕으로 진화되었다. 여기서는 기존의 분산 기술들의 발전과 각 기술들간의 특징 및 차이점을 살펴보고자 한다.
소프트웨어 기술은 70년대의 서브루틴(Subroutine)을 이용한 재활용성 향상 노력을 시발점으로 80년대의 분산 객체(Distributed objects), 90년대의 컴포넌트(Components), 그리고, 최근의 웹 서비스 기술로 발전하여, 분산된 전사 자원의 효율적인 이용과 분산 모듈의 추상화 수준 고도화를 통하여 하드웨어 플랫폼에의 의존성 탈피에서 소프트웨어 플랫폼 수준에서의 의존성 탈피를 가능하게 하여 변화 요구에 대한 민첩한 적응을 가능하게 하고 비즈니스와 IT가 같은 방향으로 움직일 수 있도록 지원하고 있다.
최근에 이루어진 분산 소프트웨어 기술의 진화인 분산 객체 컴포넌트와 웹 서비스에 대해 좀더 상세히 살펴보면, 우선 90년대 태동한 컴포넌트 기술은 적절한 인터페이스의 사용과 처리 기능의 내포(Encapsulate)를 통하여 재사용성을 향상시킴으로써 장기적인 개발 속도 증진과 적응성을 높일 수 있었지만, 비즈니스가 요구하는 수준의 민첩성을 제공하기에는 아직 부족한 면이 있다.
그리고, COM은 단지 COM과 커뮤니케이션이 가능하고 CORBA는 CORBA와만 커뮤니케이션할 수 있는 기술적인 제약성을 갖고 있다. 그러나, 분산 소프트웨어 기술이 웹 서비스로 진화하면서, 서비스 사용자와 제공자 사이의 플랫폼 의존적인 기술 제약성이 제거되고, 서비스 기술(Service Description)의 발전으로 서비스가 어떻게 구현 되었는지에 대한 지식 유무에 관계없이 사용할 수 있도록 함으로써 재사용성 향상을 실현하고 있다.
SOA를 보다 더 현실적으로 만든 웹 서비스에서 이야기하는 서비스는 미들웨어나 프로그램 언어 독립적이며, 느슨하게 연계되고, 컴포넌트 보다 한 차원 높은 전사 관점에서의 추상화를 지원한다는 점에서 컴포넌트 기술요소와 주요하게 차이를 나타내고 있다. 좀 더 상세한 내역을 '<표 2> 컴포넌트와 서비스의 특징과 차이점'에 정리하였다.
여기서 유의하여 살펴볼 점은 서비스가 컴포넌트를 활용하여 구현된다는 것이다. 즉, 소프트웨어 모듈 구분의 정도와 추상화 수준에 있어서, 제일 낮은(즉 제일 작은) 구분이 객체(Object)이고, 이들 객체들의 묶음으로 컴포넌트가 구성되고, 컴포넌트의 묶음으로 서비스가 구현됨으로써 이전의 기술 발전 성과를 계승하고 있다는 것이다.
SOA 구현을 통하여 어떤 효과를 기대할 수 있나?
정보 교환 포맷의 표준성과 인터페이스를 이용한 서비스 통합의 수월성, 느슨한 연계를 가능하게 하는 SOA 도구들의 낮은 비용은 SOA 구현을 통한 기대 효과의 핵심이라 할 수 있다.
기업들이 SOA 구현을 통하여 얻을 수 있는 주요 효과들은 다음과 같다.
▶협업의 민첩성 향상 : 성긴 비즈니스 서비스(Coarse Grained Service)를 비즈니스 파트너들이 표준적인 방식으로 이용할 수 있도록 함으로써 파트너와 관계자들과의 안전하고 쉬운 정보 공유를 가능하게 한다.
▶변화 적응의 민첩성 향상 : 비즈니스 파트너나 관계자로부터의 비즈니스 변경 요구 사항들은 가용 서비스 집합에서 서비스를 선택하여 비즈니스 프로세스를 변경하게 된다. 이는 곧 비즈니스 요구에 대한 빠른 대응으로 나타난다.
▶비용 절감 : SOA는 근본적으로 WSDL이나 SAML, SOAP, UDDI와 같은 표준에 기반을 둔 모듈로 구성된 아키텍처의 구현을 의미하는 것으로 궁극적으로 서비스의 재사용과 공유를 가능하게 함으로써 비용 절감 효과를 얻게 한다.
▶효율성 향상 : SOA는 기업 시스템의 모듈화를 촉진시켜서 전체적인 일관성은 유지하면서도 비즈니스 서비스의 재사용성을 향상시킨다.
▶비즈니스 운영성 향상 : SOA 기반 서비스는 이기종 레거시 시스템을 운영하는 기업에게 공통의 아키텍처와 일관된 접근을 가능하게 하여 비즈니스 운영성을 향상시킨다.
▶신기 적용의 수월성 : SOA의 성긴 모듈화는 서비스 인터페이스 변경 없이 보다 효율적인 신기술의 적용을 가능하게 한다.
SOA 구현의 장애 요소는 어떤 것들인가?
기업들이 단순한 웹 서비스 구현에서 전사 SOA와 비즈니스 서비스 구현으로 이행하는데 있어 당면하는 주요 장애들은 다음과 같이 정리될 수 있다.
▶서비스 개발 지원 체계 : 비즈니스 서비스는 비즈니스 차원에서의 기능 수행과 조직 경계를 넘어서는 재사용성을 확보하도록 설계되어야 한다. 이는 호환성을 담보하기 위해 준수하여야 할 기본적인 기술 기준과 불필요한 서비스의 중복 개발을 예방하기 위한 서비스 중복 인지와 회피를 지원하는 체계 구축을 필요로 한다.
▶서비스 검색 체계 : 서비스 재사용과 중복 제거는 SOA의 주요한 비즈니스 효과이다. 실제로, SOA 구현 선진 사례는 서비스 재사용이 재사용되는 개별 서비스 당 3만달러의 비용 절감 효과가 있음을 보여주고 있다. 비즈니스 분석가나 아키텍트, 개발자가 새로운 애플리케이션을 개발하거나 새로운 비즈니스 프로세스를 구현하고자 할 때 그들은 재사용 가능한 비즈니스 서비스 검색을 지원하는 잘 알려지고 체계화된 방법을 필요로 하게 된다.
▶서비스 배포 관리 : 서비스를 배포한다는 것은 곧 서비스 사용자에 의한 주요 비즈니스 프로세스의 수행을 의미하므로 배포되는 서비스의 품질은 경우에 따라서는 치명적인 비즈니스 결과를 초래할 수 있다. 그러므로, 최종 서비스 사용자를 위해 배포되는 서비스의 IT 및 비즈니스 정책 준수 여부, 서비스 품질 보증을 위한 점검 및 배포 승인 절차 수립은 매우 중요하게 된다.
▶서비스 연관 관계 관리 : 비즈니스 서비스는 다수의 비즈니스 서비스와 IT 서비스들로 구성될 수 있다. 서비스 모델에서의 IT 서비스는 애플리케이션 서버나 브로커, 데이터베이스와 같은 물리적인 서비스의 가상화를 의미하고, 이들 서비스와 상위 수준의 비즈니스 서비스 사이의 상호 연관 관계의 기록 관리가 중요하다.
▶비즈니스 서비스 보안 : 다양한 주체들에 의해 공개되는 보다 많은 웹 서비스들은 웹 서비스 보안을 점점 더 중요하게 만든다. 불명확한 인증 및 서비스 사용 권한은 전사적인 SOA에 있어서는 치명적일 수 있다.
▶비즈니스 서비스 통제 및 감사 : 비즈니스 서비스들은 웹 서비스로 구성될 수 있고 이들 웹 서비스는 또다시 다른 웹 서비스에 의존적일 수 있다. 이러한 환경에서는 이들 복잡성과 동적 관계를 통제할 정책과 감사가 매우 어려운 도전이 될 수 있다.
▶서비스 수준 준수 : 다양한 종류의 웹 서비스들로 구성되는 비즈니스 서비스는 개별 웹 서비스가 가지는 저마다의 서비스 수준 목표와 비즈니스 서비스의 서비스 목표 수준이 일치하지 않는 경우가 발생할 수 있다. 이는 비즈니스 서비스 수준 달성을 위한 성능과 가용성, 리포트, 장애 조치 등에 대한 새로운 요구를 발생시킨다.
▶비즈니스 서비스 수명 주기 관리 : 비즈니스 서비스는 SOA가 제공하는 유연성과 민첩성을 최적화하기 위하여 서비스 제공 체인상의 모든 구성 요소들에 대한 수명 주기 관리를 요구한다.
어떻게 SOA로 전환할 것인가?
SOA는 기본적으로 EA중에서 애플리케이션 아키텍처에 관한 것이라고 앞에서 언급했다. 이 절에서는 애플리케이션 아키텍처 구성 요소를 살펴보는 것으로 어떤 SOA 전환 방안이 가능한지 살펴보겠다. 애플리케이션 아키텍처는 '어떤 애플리케이션을 제공할까?'와 '제공할 애플리케이션은 어떻게 설계하고 구현하고 통합할까?', '어떤 기술을 바탕으로 애플리케이션을 제공할까?'에 대한 물음에 답하는 애플리케이션 전략과 설계 전략, 기술 전략으로 구성된다.
SOA로의 전환에 있어 애플리케이션 전략이란 SOA 전환을 위한 접근 방식은 어떠하여야 하는가와 SOA 적용 영역을 어떻게 가져가야 하는가에 대한 답을 모색하는 것이 될 것이며, 설계 전략은 서비스를 어떻게 설계할 것인가, 기술 전략은 어떤 기술 기반에서 애플리케이션을 구동하고 관리할 것인가로 귀결된다. 이들 전략들을 연이어서 상세하게 살펴보도록 한다.
접근 방식
SOA 구현을 위한 접근 상식은 크게 하향식(Top-down Appro-ach)과 상향식(Bottom-up Approach), 하향식과 상향식을 조합한 방식(Meet in middle Approach)으로 구분 가능하다. 개별 기업이 당면한 상황과 환경에 따라, 선택되는 접근 방식이 달라지겠지만, 결론부터 말하자면 일반적으로 상향식과 하향식을 조합한 방식이 목표하는 최종 SOA 상태를 훼손하지 않으면서, 빠르고 보다 많은 투자 효과를 획득할 수 있게 하는 현실적인 접근 방식이 된다.
각 접근 방식의 특징과 장단점을 정리하면 다음과 같다.
▶하향식 접근 : 이 접근은 SOA 적용을 전사적 범위로 추진하는 것으로 전사 비즈니스 프로세스 정의와 이를 비즈니스 서비스로 투영하는 많은 사전 작업이 필요하지만, 비즈니스와 애플리케이션 간의 보다 나은 방향성 일치를 확보할 수 있고, 비즈니스 운영에 필요한 변화 요구의 반영을 단순화시킬 수 있다. 즉, 비즈니스 서비스를 비즈니스 프로세스로부터 분리하고, 변화 요구를 비즈니스 규칙과 서비스 호출의 순서로 표현되는 비즈니스 프로세스를 통하여 지원한다. 이는 서비스를 비즈니스 모델에 대한 애플리케이션 포트폴리오의 추상화 계층으로 활용하여 기업의 민첩성을 향상시키는 결과를 낳는다. 그러나, 이 하향식 접근 방식은 비즈니스 모델 정의와 이를 비즈니스 서비스로 투영하기 위한 초기 투자를 상당히 요구한다.
▶상향식 접근 : 통합의 호환성에 중점을 두는 접근으로 전사 차원에서 기능들을 통합하는 것이 아니라, 기존 애플리케이션들의 효과적인 점대점(Point-to-Point) 통합을 통하여 상위 개념의 서비스를 만드는 방식이다. 즉, 부서나 팀 수준에서 기존 애플리케이션들을 서비스로 전환시키고, 이들 서비스를 기반으로 또 다른 서비스를 만들어 게시하는 것으로 시작한다. 이때 EAI 도구나 통합 서비스(Integration Services)들을 이용하게 되며, SOA 설계 원칙이 적용되지 않은 SOA 기술들이 활용되게 된다. 이때 주안점은 통합의 단순화에 두어지게 되고, 표면적으로는 SOA 구현으로 보이지만 비표준적인 데이터 모델에 기반을 둔 통합 서비스들의 공개와 기존 애플리케이션 포트폴리오에 대한 지식을 상위 수준의 프로세스에 투영시킴에 따라 많은 제약들을 갖게 된다. 요약하면, 구현이 쉽고, 빠른 효과를 얻을 수 있으나, 얻을 수 있는 이득에 제약이 있고, 전체적으로는 보다 많은 비용이 소요될 수 있는 방식이다.
▶하향식과 상향식을 조합한 접근 : 전사 애플리케이션 통합 부분을 우선적으로 설계하고 구현하는 것으로, SOA 기술 요소 뿐만 아니라 SOA 원칙을 모두 적용하여 통합 서비스를 개발하는 것이다. 한편으로는 전사 비즈니스 모델과 비즈니스 서비스를 정의하고 설계, 구현하여 잘 정의된 프로세스 부분에 이들 통합 서비스를 우선적으로 적용하여 상위 수준의 비즈니스 서비스를 지원하도록 한다. 이때 비즈니스 서비스는 통합 서비스를 호출하여 조립(Service Composition)하는 방식을 만들어 지며, 비즈니스 서비스 설계가 성숙됨에 따라 요구되는 변화 지원에의 유연성을 제공하게 된다. 이 하향식과 상향식을 조합한 접근 방식은 하향식 접근법 보다 빠른 효과를 기대할 수 있고, 장기적인 목표와 보다 더 잘 부합하며, 상향식 설계보다 더 많은 효과를 제공하게 된다.
SOA 적용 영역
SOA 구현에 있어서는 앞의 접근 방식 검토와 더불어 개별 기업 또는 한 기업 내의 개개 부서들이 갖는 SOA 구현 동인과 처한 환경을 근간으로 SOA 적용 영역별 비용 효과성과 우선 순위 도출을 위한 SOA 적용 영역 검토가 필요하다. 여기서는 SOA 적용 영역을 어떻게 구분할 수 있는지를 SOA가 갖게 될 일반적인 To-Be 계층 구조(<그림 5> 가시화된 HP 다윈 아키텍처)를 살펴봄으로써 논의를 진전시키고자 한다.
기업이 갖게 되는 To-Be SOA는 인프라스트럭처 서비스 계층 데이터 및 정보 자원들을 통합의 호환성을 보장하는 애플리케이션 서비스 계층의 기존 컴포넌트들 또는 웹 서비스, 통합 서비스들이 처리하게 된다. 이들 컴포넌트와 통합 서비스들은 비즈니스 서비스 계층에서 비즈니스 중심의 인터페이스를 제공하는 공유 가능한 비즈니스 서비스로 조합되어 규칙과 프로세싱을 통한 비즈니스 프로세스의 자동화와 관리를 지원함으로써 비즈니스 프로세스 변화에 따른 민첩하고 유연한 대응을 가능하게 한다.
이들 To-Be SOA 계층을 바탕으로 SOA 적용 영역을 구분하면 크게 컴포넌트 및 통합 서비스 영역과 공유 가능한 비즈니스 서비스 영역으로 구분 가능하며, 그 내역은 다음과 같이 정리할 수 있다.
▶컴포넌트 및 통합 서비스 영역 : 재사용성 향상과 처리 속도 증대, 데이터 중복 감소를 위하여 기업 내 다수의 시스템에서 공통적으로 사용되는 인증 및 권한 관리, 데이터 접근, 애플리케이션 통합(Application Integration)과 웹 및 이동 전화, PDA, 콜 센터와 같은 다수의 채널 지원에 사용되는 공통 모듈의 SOA 전환 그리고, SOA의 미들웨어 및 프로그램 언어 독립성, 느슨한 연계성을 살린 파트너 통합 영역의 SOA 전환으로 다시 세분화 할 수 있다.
▶공유 가능한 비즈니스 서비스 영역 : 보다 장기적인 효과를 위해서는 비즈니스 변화를 느리게 만드는 비즈니스 서비스 영역의 프로세스와 메시지 흐름, 데이터 구조, 애플리케이션 통합 구조 전체를 SOA 기반으로 전환하여 애플리케이션 변경을 보다 빠르게 만드는 것이다.
SOA 적용 영역은 각 기업의 SOA 동인과 처한 환경을 바탕으로 한 SOA 적용 영역 검토 결과로 확정되던 회사 전체적인 관점에서 출발한 접근 방식의 선택에 따른 적용 영역의 한정이던 서로 유기적으로 통합되어 고려되게 된다.
서비스 생성(Creation)과 통합(Integration)은 어떻게 가능한가?
이전의 애플리케이션 아키텍처 기술들과 SOA가 주요하게 다른 점은 서비스 개념의 도입이라고 할 수 있다. 이는 곧 어떻게 서비스를 만들어 낼 것인가와 어떻게 서비스들을 통합(Integra-tion)할 것인가라는 근본적인 질문을 유발하게 된다.
서비스 생성
서비스 생성과 관련해서는 어떻게 서비스 수준(Granularity)을 적절히 구분하여 정의하고 설계할 것이냐가 주요 이슈로 대두된다. 이를 위한 고려 사항과 점검 항목들을 살펴보면 다음과 같이 정리할 수 있다.
▶비즈니스 프로세스 지원 : 서비스 정의와 서비스 실행 조율, 요구되는 적절한 서비스의 호출은 비즈니스 프로세스에 바탕을 두고 이루어져야 한다. 비즈니스 민첩성은 비즈니스 프로세스를 실현하는 서비스의 기능과 인터페이스를 통하여 이루어지는 것이다. 비즈니스 프로세스의 성공적인 반영은 다음과 같은 질문들을 통하여 검증해 볼 수 있다.
쪾서비스가 지원하는 비즈니스 주체와 프로세스, 이벤트는 어떤 것들인가?
쪾고객 지원을 위하여 어떤 기능들이 공개되어야 하는가?
쪾고객 지원 프로세스를 위하여 어떻게 서비스들을 조합하여야 하나?
쪾비즈니스 프로세스가 다단계로 구분되어야 하는가?
▶서비스의 조합(Composition) 지원 : 서비스는 조합을 통하여 비즈니스 프로세스를 지원할 수 있는 모듈화 된 기능들로써 독립적이어야 하고 HTML 메시징과 같은 느슨한 연계를 통하여 접근이 가능하여야 한다. 정의 및 설계된 서비스의 조합 가능 여부는 다음과 같은 질문들을 통하여 검증해 볼 수 있다.
쪾어떤 기능을 모듈에 담는 것이 서비스 활용성을 높일 수 있는가?
쪾어떤 기능들이 서비스 통합에 도움이 되는가?
쪾의미 있고 유용한 최소한의 기능 단위는 무엇인가?
쪾너무 기능을 세분화해서 의미 있는 서비스를 만들기 위해서 서비스들을 다시 조합하여야 하지는 않는가?
▶최소 단위의 애플리케이션 : 하나의 서비스는 단일 목적을 지닌 더 이상 분리될 수 없는 기능 집합이다. 보다 다양한 기능을 제공할 필요가 있다면 그러한 기능을 제공하는 다른 서비스를 조합하여 새로운 서비스를 만들어서 제공하면 된다. 이러한 최소 단위 애플리케이션 속성은 다음의 질문에 답해봄으로써 유지할 수 있을 것이다.
쪾지원하고자 하는 비즈니스 요구 사항은 무엇인가?
쪾같은 요구 사항을 지원하는 다른 서비스가 존재하지는 않는가?
쪾애플리케이션 요구 사항을 충족시키는가?
쪾다른 서비스나 애플리케이션에 의해 같은 애플리케이션 요구 사항이 충족되고 있지는 않은가?
쪾요구 사항 해결을 위하여 다른 기능에 의존해야 하지는 않는가?
쪾데이터 요구 사항이 다른 데이터를 함께 이용해야 해결되는 것은 아닌가?
▶서비스의 재사용 : 서비스는 정의에서부터 재상용성을 목적으로 하고 있으며, UDDI를 통하여 검색되도록 구성할 수 있다. 이는 비즈니스 영역 내의 재사용 요소에 대한 비즈니스 모델과 시나리오 지도, 메타데이터 저장소, 데이터 사전에 대한 검토를 통하여 확보될 수 있다.
쪾적정한 재사용과 공유 비즈니스 컴포넌트란 무엇인가?
쪾복제된 데이터가 다른 곳에 존재하지는 않는가?
쪾복제된 기능이 다른 곳에 또 존재하지는 않는가?
쪾다른 서비스에서 이 데이터와 기능을 사용할 수 있겠는가?
이러한 고려를 통하여 만들어지는 서비스 체계는 여러 유형으로 나타난다. 가능한 경우를 예로 소개해 본다. 우선 다른 어떤 서비스도 사용하지 않고 전체를 코딩하여 만든 '기본 서비스'와 다른 기본 서비스를 하나 이상 사용하여 조합한 '복합 서비스(Composite Service)'로 구분할 수 있다. 또 다른 관점에서의 분류로는 비즈니스 모델의 행위자나 역할, 비즈니스 프로세스, 비즈니스 이벤트를 지원하는 '비즈니스 서비스'와 다수의 비즈니스 영역에서 활용할 수 있는 공통 서비스인 '애플리케이션 서비스', IT 인프라스트럭처에 국한된 단일 인증(SSO)이나 인쇄 지원과 같은 '인프라스트럭처 서비스'로 구분하는 것이다.
이들 두 구분 축을 교차하여 생기는 6가지의 세부 서비스 수준(Granularity)을 계층화하여 서비스 체계를 수립하는 방법이 하나의 예가 될 수 있다.
서비스 통합
서비스 통합에는 기존 EAI를 통한 애플리케이션 통합에 비하여 서비스 지향 아키텍처가 그 태생적 특성으로 인하여 보다 저렴하고 유연하게 대응할 수 있는 기반을 갖고 있다. 이러한 기반을 바탕으로 서비스 지향 아키텍처의 서비스 통합에 대한 이점을 현실화하는 몇 가지 방안들이 시도되고 있다. 이들 몇 가지 방안들에 대해 살펴보도록 한다.
▶비즈니스 통합 허브(BIH: Business Integration Hub) : 비즈니스 수준에서 제공 서비스(What)와 서비스 제공 방법(How)을 분리하여 광범위한 기업 비즈니스 프로세스를 지원하는 방법이다. 이 통합 방식에서는 백엔드 ERP 시스템과 기업 미들웨어 서비스 및 플랫폼간의 기능적인 간극을 해결하는 것에 주안점을 두어, 특정 비즈니스 문제와 관련된 프로세스들과 데이터, 메시징 사이의 긴밀한 연계를 제공한다.
▶서비스 지향 통합(SOI: Service Oriented Integration) : 패키지 애플리케이션과 써드 파티 벤더들이 서비스 지향 통합(SOI: Service Oriented Integration)을 제공하기 시작하였다. 이 방식은 벤더들이 자신들의 제품에 서비스 지향적 특성들을 부가함으로써 가능해진 것으로 상위의 비즈니스 서비스들을 정의하고 외부에서 제공하는 서비스 인터페이스를 탑재할 수 있도록 지원한다. 그러나, 아직 그 수준이 성숙한 된 것은 아니며, 긴밀한 연계(Tight coupled) 방식으로 애플리케이션에서 서비스를 추출하여 특정 비즈니스에 특화 된 통합 서비스를 제공하고 있다.
▶기업 서비스 버스(ESB: Enterprise Service Bus) : ESB가 SOA의 주요 구성요소로 부상하고 있다. ESB는 미들웨어 기술이 제공하는 다음과 같은 인프라스트럭처 기능들의 집합이라 할 수 있다.
쪾멀티트랜스포트 및 표준 기반 서비스, 메시지 기반 연동, 이벤트 기반 연동 지원
쪾컨텐츠 및 규칙(Rule) 기반의 라우팅, 중계(Mediation), 변환(Transformation) 수행
쪾보안과 모니터링 기능 제공
쪾분산 엔진과 중앙 집중 관리 및 제어 지원
SOA관리는 어떻게 하여야 하는가?
느슨한 연계와 인터넷을 포함하는 분산 네트웍 환경을 전제로 하는 SOA가 비즈니스 애플리케이션을 설계하고 생성, 관리하기 위한 새로운 패러다임으로 부상함에 따라, SOA 관리체계(Governance)와 서비스 품질(Quality of Service), IT 운영 효율과 같은 비즈니스 및 IT 측면에서의 관리 이슈들이 제기되고 있다.
구체적으로는 가용 자원으로서의 서비스 숫자가 수백에서 수천 가지에 이르는 환경을 어떻게 관리할 것인가와 기본 서비스들을 조합한 복합 서비스 체계를 지원하는 비즈니스 서비스 모델에서의 개별 구성 요소들의 성능과 모니터링을 어떻게 효과적으로 수행할 것인가의 문제가 주요하게 대두된다. 이러한 이슈들은 현대의 중단 없는 비즈니스 환경에서는 그 중요함이 더해지고 있다.
SOA를 통하여 서비스를 제공한다는 것은 사람과 프로세스, IT 기술의 통합을 통하여 이루어지며, 이 서비스 제공 조직 체계를 개념적으로 도식화하면 '<그림 9> 서비스 제공 조직 상세 개념도'와 같이 나타낼 수 있다. 즉, 각각의 서비스 제공 시스템(SDS: Services Delivery Systems)들을 제어하는 다수의 서비스 제동 제어기(SDC: Services Delivery Controllers)가 존재하여 다음과 같은 핵심적인 제어 기능들을 제공하게 된다.
▶모델 기반 자동화 : SDC 기능 구성 변경을 지원하고 SDS 운영과 SDC 제어를 연계한다.
▶서비스 할당 : 비즈니스 서비스가 요구하는 필요 자원과 우선 순위를 제어한다.
▶업무 자동화 : 서비스 검색과 인스턴스 생성, 중지, 제거, 서비스 이전, 확장과 같은 SDS와 연관된 수명주기 관리 업무를 지원한다.
▶자원 모니터링과 분석 : 모니터링 구성 변경과 서비스 수준 목표(SLO: Service Level Objective)를 정의한다.
▶이벤트 응답 정책 : 모니터링과 분석 촉발 이벤트를 적절한 업무 자동화 작업과 연계 시킨다.
HP SOA 오퍼링
HP는 고객의 비즈니스 성과 개선과 유연성 향상, 민첩성 증대를 목적으로 한 SOA 전환 및 설계, 구현, 통합, 관리를 지원하는 서비스 포트폴리오를 HP의 일관된 방법론을 기반으로 아래와 같이 제공한다. 이들 서비스들은 SOA 프로젝트의 전체 생명주기에 걸친 엔드투엔드서비스들로서 구체적인 내역은 다음과 같다.
▶SOA Envisioning : 대규모 기업들을 대상으로 SOA 개념 정립과 SOA 구현에 따른 기회 및 위험 요소 파악을 지원한다.
쪾비즈니스 부서의 주요 임직원 및 CIO와 CTO와의 인터뷰, 설문 대상자 파악 등과 같은 워크숍준비
쪾SOA 개념 및 비즈니스 이슈 도출 워크숍
쪾장애 및 기회 요소 도출 워크숍
쪾SOA 제약 및 준비 정도 파악, 변화 프로그램 도출 워크숍
쪾SOA로 전환 시작
▶SOA Assessment : HP의 SOA Agility Assessment 방법론을 활용하여 전사 SOA 적용 로드맵과 가이드라인을 개발한다.
쪾Learning session: SOA 개념 및 원칙 검토, SOA 성숙도 모델과 민첩도 검증 질의서 소개
쪾SOA 성숙도 및 준비 정도, 민첩도 검증을 위한 인터뷰 및 설문
쪾갭 분석을 통한 실행 과제 도출 및 우선 순위 선정, 타당성 도출
쪾분석 내역 검토 및 로드맵 준비를 위한 플래닝 워크숍
쪾종합 검토 및 보고
▶SOA Governance and Architecture : SOA로의 전환을 위한 전사 아키텍처 및 SOA 거버넌스 모델을 관장할 SOA 아키텍처 프로그램 오피스(Architecture Program Office) 구성을 지원한다.
쪾거버넌스 선진 사례 워크숍
쪾SOA 거버넌스 모델을 위한 상세 설계 및 구현 계획
쪾글로벌 프로그램 오피스 구축
쪾엔터프라이즈 아키텍처 프로그램 구축
쪾초기 SOA 엔터프라이즈 아키텍처 개발
▶SOA Enablement : 거버넌스 및 아키텍처 서비스의 산출물을 바탕으로 SOA 구현을 위한 인프라스트럭처 마련을 지원한다.
쪾As-Is 인프라스트럭처 검토
쪾SOA 인프라스트럭처를 위한 청사진 정의
쪾구현 계획 수립
쪾인프라스트럭처 구현
쪾인프라스트럭처 테스트
쪾Proof of Concept 실행
▶SOA Service Development : 전사 및 부문, 부서, 프로젝트 단위의 SOA 비즈니스 및 IT 서비스에 대한 정의 및 개발, 전개를 지원한다.
쪾적절한 구조와 세분화 정도를 갖는 서비스 모델을 구성하는 서비스들을 도출
쪾도출된 서비스 아키텍처를 관리와 보안, 비기능적 서비스 요구 사항에 맞도록 조정
쪾전사적 관점의 비즈니스 이점 극대화를 위한 서비스 아키텍처 검토
▶SOA Software Development : HP의 글로벌 소프트웨어 개발 능력을 활용하여 고객의 비즈니스 및 IT 서비스를 개발한다.
쪾EAI와 B2Bi 통합
쪾웹 서비스 및 애플리케이션 개발
쪾포탈과 협업, 리치미디어, 컨텐츠 관리를 위한 J2EE/.NET 솔루션 개발
쪾통합 지원 센터 지원
쪾비즈니스 프로세스 통합
▶SOA Management : 생명주기 관리와 서비스 관리, 모니터링, 감사, 분석, 서비스 수준 협약, 정책을 포함하는 관리 지원을 통하여 SOA 적용에 대한 제어권을 제공한다.
쪾모니터링과 제어 요구 사항, 대상 관리자, 서비스 수준 협약, 플랫폼 및 프락시 또는 에이전트 설치를 웹 컨테이너 파악을 위한 디스커버리 워크숍
쪾관리 솔루션 디자인
쪾HP OpenView SOA Manager 설치 및 구성 적용
쪾솔루션 테스트 및 검증
개별 기업이 처한 각기 다른 상황은 모든 기업에 적합한 하나의 SOA 구현 목표란 있을 수 없음을 의미한다. 즉, 개별 기업 마다 각기 다른 SOA 구현 목표는 SOA 정의에 있어서 약간의 변화를 가져오게 되고 SOA 구현 목표 달성을 접근 방법 또한 다르게 만든다.
이에 따라, HP는 SOA로의 전환 여행을 준비하는 기업들을 위하여, HP의 SOA Agility Assessment 서비스를 그 시발점으로 삼을 것을 추천한다. SOA Agility Assessment 서비스는 다음과 같은 4가지 영역에서 고객 및 고객이 비즈니스를 수행하는 산업에 대한 정보를 수집한다.
▶HP의 민첩성 측도인 시간과 변화 범위, 변화의 수월성에 바탕을 둔 비즈니스 민첩성과 산업별 민첩성 수준 분석
▶SOA 성숙 모델을 이용한 SOA 성숙도와 SOA 구현과 관련된 조직의 성숙도 평가
▶HP ROI 도구를 이용한 고객 기업이 속한 산업군과 IT 투자비용에 근거한 ROI(Return On IT) 계산
▶인터뷰와 현장 검증을 통한 아키텍처 평가
이상의 4가지 영역에서 수집된 고객 및 산업 관련 정보를 바탕으로 고객 기업의 아키텍처상의 개선 영역을 식별하고, 보다 많은 개선 효과를 가져올 수 있는 SOA 작업들을 고객과 함께 도출하여, 우선 순위를 매기고, 로드맵을 작성하게 된다. 이 평가 작업의 결과에 따른 고객 기업의 다음 추진 SOA 작업은 개별 기업에 따라 차이를 보이게 될 것이고, HP는 고객 기업들이 필요로 하게 될 SOA 지원 서비스들을 SOA 수명 주기 전체를 아우르는 엔드투엔드 솔루션으로 지원하고 있다.