3. SOA, 어떻게 시작하는가? (이번호)
1부에서 빠르게 변화하는 기업 환경에 유연하고 융통성 있게 대처하기 위해 제안된 SOA의 가치와 대략적인 구현단계를 알아봤다면 2부에서는 SOA의 라이프사이클에 대해 구체적으로 살펴봤다. 이번호에서는 SOA를 시작하는 로드맵에 대해 알아본다. <편집자>

최근 기업이 고민하고 있는 여러 가지 업무 추진과제들이 전략적으로 SOA를 시작하려는 요인으로 부각되고 있다. 여러 조직에서 동시 다발적으로 발생하고 있는 수많은 요인들이 SOA의 추진요인이 되고 있는 것이다.
인수합병, 매각, 다채널 영업전략 구현이나, 일부 국가에서는 경쟁사와의 큰 차별요인이 되는 적시 시장 진입과 적시 시장 출시 관련 문제, 그리고 고객, 비즈니스 파트너, 그 외 비즈니스 관련자들에게 정보와 서비스를 제공할 수 있는 기능을 확보하는 것 등이 SOA를 도입하도록 하는 업무 추진 과제들이다.
이와 같은 업무추진 과제는 결국 IT 시스템의 고도의 유연성에 대한 요구를 의미한다. 시스템의 규모가 커지고 복잡해지면서, 사용자가 늘어나고 사용자의 유형이 다양해지면서, 다양한 매커니즘이 구축되면서, 유연성의 문제는 해결이 더욱 힘들어지고 있다.
SOA는 점점 복잡해 지고 있는 시스템을 다시 유연하게 만들고, 비즈니스의 필요사항에 대응해 사업전략을 구현할 수 있는 방식이다. 또한 SOA는 애플리케이션 통합 문제에 대한 대응이기도 하다. 다양한 애플리케이션 포트폴리오를 보유한 기업들은 기존의 애플리케이션을 연계해 보다 통합된 업무 프로세스를 창출해야 하는 과제가 있기 때문에 통합에 대한 요구사항을 충족해야 한다.
뿐만 아니라 여러 가지 애플리케이션 개발 문제도 SOA를 도입하도록 하는데 하나의 요인이 되고 있다. 유연성을 달성하기 위해서는 기존에 개발된 것을 재사용하고, 간단하고 쓰기 쉬운 IT 시스템을 만들기 위한 변화 프로세스를 도입하며, IT 조직이 보유한 기술을 가장 효과적인 방법으로 활용할 수 있어야 하기 때문이다.

SOA 로드맵
SOA를 시작하는데 있어서 진입단계는 여러 가지가 있을 수 있다. 크게 4가지 단계로 나눌 수 있는데 초기도입 단계, 애플리케이션 통합 단계, 리엔지니어링 단계 및 성숙 단계로 나눌 수 있다. 물론 기업이 SOA를 적용하는데 있어서 반드시 초기 도입단계부터 거쳐야 하는 것은 아니다. 기업의 SOA 준비 상태, 기업의 목표 등을 고려해 애플리케이션 통합단계 또는 리엔지니어링 단계에서 시작할 수 있다. 각 단계를 살펴보면 다음과 같다.

● 초기도입 단계는 기존의 특정 애플리케이션이나 신규 애플리케이션을 SOAP, WSDL등의 웹 서비스 기술을 이용해 연결하는 단계다. 이 단계에서는 시스템간의 메시지 인터페이스를 표준화하고 향후 확장을 고려한 시스템 디자인이 필요하다. 이 기종 시스템 사이의 인터페이스를 확장하거나 외부기관 비즈니스 파트너와의 연결 등에서 SOA를 활용할 수 있다.
● 두 번째 단계인 애플리케이션 통합 단계는 복수의 애플리케이션을 서비스 기반으로 통합하는 단계로 초기 도입단계의 기술을 활용, ESB(Enterprise Service Bus)를 구현하는 단계다. 기존 시스템과의 연계, BPEL(Business Process Execution Language)을 사용한 비즈니스 프로세스 제어 등을 구현한다. ESB구축을 통한 EAI 실현이나 비즈니스 프로세스 관리 및 애플리케이션 통합 등을 위해 적용될 수 있는 단계로서 기존 시스템의 SOA/ESB 참여와 연결 계층(Connectivity Layer)에 집중을 통해 표준에 기반한 통합을 이룰 수 있다.
● SOA를 전사적으로 적용하는 리엔지니어링 단계에서는 시스템 간의 연계를 고려하는 것이 아니라 IT를 이용한 전사적 비즈니스 프로세스의 횡적인 연계를 검토하는 것으로부터 출발한다. 비즈니스 컴포넌트 모델링, 기업 내 데이터의 정규화, 일원화를 위한 분석, EA 접근방식에 의한 시스템 기본 계획의 책정, SOA 구현 방법론에 의한 비즈니스 프로세스에 대응한 서비스 컴포넌트의 도출과 컴포넌트 단위의 결정 등의 작업을 진행할 수 있다. 이 단계에서 SOA를 시작한다면, 업무개발부터 서비스 개념을 도입해 IT 인프라스트럭처에 연결함으로써 전사적인 SOA를 구현하게 된다.
● 마지막 단계인 온디맨드 비즈니스로의 전환 단계에서는 비즈니스 컨설팅을 통한 새로운 비즈니스 모델을 창출하고 EA 접근방식에 의한 시스템 기본계획 확정 등의 작업을 하게 된다. 예측 불가능한 급격한 변화에 대응하기 위해서는, 고객의 요구에 대해 기업 내부 자원뿐 아니라 외부에서 필요한 만큼의 자원을 조달하고, 최종적인 가치를 제공하는 비즈니스 모델을 실천할 필요가 있고, 이를 통해 기업은 대응 능력이 뛰어난 유연한 비즈니스를 전개할 수 있다.
어느 단계에서 SOA를 시작하든지 기업이 가장 먼저 수행해야 할 일은 자사의 SOA 수준을 확인하고 어느 단계부터 SOA를 시작해야 하는 지 결정하는 일이다. 물론 어느 단계부터 시작해야 한다는 것은 없다. 기업의 상황, 전략 등과 맞물려서 결정하게 된다. 이 과정에서 전문적인 컨설팅 전문가로부터 컨설팅을 받을 수 있다

SOA 구현
SOA는 컴포넌트 비즈니스 모델링 단계를 거쳐 나온 결과를 가지고 SOA를 구현하는 단계별 접근방식인 방법론을 통해 근간이 되는 서비스를 도출한 후 이를 SOA로 구현하게 된다. 보다 자세히 살펴보면 다음과 같은 과정을 거치게 된다.

● CBM(Component Business Modeling)을 통해 기업의 전체적인 컴포넌트를 도출하고 이들 컴포넌트 사이의 연계 관계를 파악한다.
● 기업 목표와 이의 달성 여부를 평가할 수 있는 KPI를 정의한다. 이 과정까지는 보통 전문적인 컨설팅을 통해서 이뤄진다.
● 도출된 컴포넌트를 사용해 서비스를 도출하고 이들 서비스 사이의 프로세스를 정의한다
● 도출된 서비스를 기업 목표와 일치시키는 작업을 한다. 이는 SOA를 구현이 기업의 목표 달성을 위한 보다 효율적인 방식을 찾는 행위이기 때문이다.
● 그리고 기업 목표를 달성하는데 실질적으로 도움이 되는 서비스를 추출한다.
● 추출된 서비스를 툴을 사용해 실제로 구현하고 구현된 서비스를 SOA 미들웨어 위에서 운영하고 이를 모니터링 하는 과정을 거치게 된다.

SOA 구현은 짧게 표현했지만 매우 방대한 내용이다. 이 과정에서 전문적인 컨설팅 작업이 포함돼야 할 필요도 있고 또한 SOA를 구현 하는 과정을 보다 안전하고 신속하게 진행할 수 있도록 하는 전문적인 SOA 방법론도 필요하다. 그리고 이러한 방법론을 통해 설계된 서비스를 실제로 구현하고 운영하고 관리하는 SOA 개발, 미들웨어 및 관리 솔루션도 필요하다. SOA 구현은 단순한 미들웨어 솔루션만을 가지고는 되지 않는다. 이를 실체화시키기 위한 많은 사전 작업과 사후 작업이 반드시 필요하다.

SOA 레퍼런스 아키텍처
SOA를 구현하게 되면 다음과 같은 모습을 가지게 된다.
● 인터랙션 서비스 - 실제로 사용자들이 화면을 통해 사용되는 서비스이다.
● 프로세스 서비스 - 기업 내부의 모든 비즈니스 프로세스를 관리하고 조정한다. 비즈니스 기능을 통해 각 부서에 걸쳐서 횡적으로 연결되는 비즈니스 프로세스를 관리하게 된다.
● 정보 서비스 - 내부의 서로 다른 데이터 소스에 대한 관리를 담당하는 서비스로서 데이터 베이스에 저장된 데이터뿐만 아니라 이메일, 텍스트 파일 등의 비정형 데이터에 대한 관리도 통합적으로 하게 된다.
● 파트너 서비스 - 온디맨드 기업은 모든 서비스를 내부 자원을 통해서 제공하지 않는다. 가장 잘하는 핵심 역량만을 보유하고 나머지는 비즈니스 파트너를 통해서 제공함으로써 가장 효율성 높게 비즈니스를 하게 된다. 따라서 SOA에서는 다양한 비즈니스 파트너에 대한 접속 서비스를 통해 연계될 수 있는 서비스를 제공한다.
● 비즈니스 애플리케이션 서비스 - 실제로 비즈니스 로직을 구현하는 애플리케이션으로서 데이터 처리나 트랜잭션 처리를 담당하는 서비스이다. 표준 기술을 통해 구현된다.
● 접속 서비스 - SOA를 구현하는 과정에서 반드시 필요한 것이 SOA가 구현이 안된 기존 시스템을 SOA체계에 포함시키는 것이다. 비 표준 기술을 사용한 경우가 많지만 접속 서비스를 통해서 SOA의 한 서비스로서 포함될 수 있다.
● 비즈니스 혁신 및 최적화 서비스 - 실시간 비즈니스 정보를 활용해 보다 정확하고 빠른 의사 결정을 하도록 함으로써 경쟁우위를 확보해 생존과 지속적인 성장이 가능하도록 한다.
● ESB(Enterprise Service Bus) - ESB는 SOA의 백본으로써 모든 서비스가 서로 연계되고 메시지의 전송 및 중재, 변환 등의 작업을 담당하는 중추가 된다. ESB를 통해서 각각의 서비스는 위치, 메시지의 성격에 구애받지 않고 작동하게 된다.
● 개발 서비스 - 어떤 서비스가 되든 표준화된 개발 서비스를 통해 구현이 된다. 모델링, 코드 생성, 테스팅 등의 서비스를 통해 SOA 애플리케이션이 만들어 진다.
● IT 서비스 관리 서비스로 구현된 모든 컴포넌트는 적절히 관리되고 개선돼야 한다. 개발된 복잡한 서비스들이 어떻게 어떤 순서로 연결돼 작동, 관리되고, 현재의 구성이 최적인지 모니터링해 더 좋은 시스템이 되도록 한다.
● 인프라스트럭쳐 서비스 - 모든 서비스들이 실제로 안정적이고 요구되는 서비스 수준에 맞게 서비스될 수 있도록 하는 기반 구조다.

이러한 SOA 레퍼런스 아키텍처는 단지 제시되는 사례다. 기업은 기업 상황에 맞춰 레퍼런스 아키텍처 중 일부를 구현할 수 있기도 하고, 전체를 모두 구현할 수도 있다. 그러나 SOA를 통해서 궁극적으로 기업이 유연한 비즈니스를 하도록 하기 위해서는 어떤 모습이든 SOA 레퍼런스 아키텍처에서 제시하는 서비스들이 구현돼야 한다

SOA를 통해 얻는 효과
SOA의 진정한 효과는 SOA에 내재된 세 가지 주요 효과에서 찾을 수 있다. 그 첫 번째는 아키텍처 분할이다. 아키텍처 분할은 복잡한 대형 시스템을 독립적인 기능을 가진 서비스로 분할해 전체 시스템을 보다 유연하게 만들 수 있는 요소로 다시 묶는 것인데 이렇게 하면 종속관계를 갖지 않고 서로 독립적으로 존재하게 돼 한 부분에서의 변화가 시스템 전체적으로 영향을 미치지 않게 된다.
두 번째 효과는 점진적 개발 및 적용이다. 한꺼번에 모든 시스템을 SOA로 구현할 수도 있지만 한 부분부터 점진적으로 SOA를 적용함으로써 내부적인 혼란을 최소화할 수 있다. SOA의 점진적 이행 능력은 SOA가 기존의 것을 뜯어내고 바꾸는 방식이 아니라 새로운 기술과 기존에 보유하고 있는 기술에 모두 적용할 수 있는 방식임을 의미하며, 여러 장소, 여러 시스템에 분산돼 있는 기능들을 통합, 가능한 한 일관되고 정확한 시스템으로 통합시킬 수 있는 기회를 가질 수 있다.
마지막으로, SOA의 세 번째 효과는 재사용에 있다. SOA 개념에서 재사용이 진정으로 의미하는 것은 공유다. 즉, 공유 정보 생성, 공유 프로세스 및 서브 프로세스 생성, 트랜잭션 공유, 데이터 공유 능력을 말한다. 이 모두가 SOA의 잠재적 효과의 매우 큰 부분을 차지하고 있다.
이와 같은 공유를 하게 되면 비용절감의 효과가 나타난다. 여러 번 개발하는 것이 아닌, 한 곳에서만 개발하고 이를 공통으로 사용하면 되기 때문이다. 그 한번을 정확하게 하는데 모든 역량을 집중할 수 있으면, 여러 번의 분산활동으로 추진할 때 보다 실제로 더 좋은 결과를 가져 올 수 있다.

IBM과 SOA
SOA는 단순히 이를 위한 미들웨어 솔루션만으로는 구현되기 어렵다. SOA는 비록 기업 시스템의 한 부분에서 시작할지라도 전사적인 관점에서 시스템 구축을 바라봐야 하기 때문이다. 따라서 SOA 구현에서는 솔루션뿐만 아니라 이를 실제로 구현할 수 있는 서비스 능력이 필수적으로 필요하다.
기업이 SOA를 구축하려 할 때 해당 기업의 상황에 맞게 적절한 안내를 할 수 있어야 하고 실질적인 구현 능력을 보유해야 한다. 새롭게 시작되는 여정을 보다 안전하고 손쉽게 갈 수 있도록 하는 SOA 방법론은 시행착오를 줄이고 진행하기 위해 반드시 필요한 중요 요소다.
IBM의 경우, 단순히 SOA 솔루션만을 제공하는 것이 아니라 전 세계에서 이미 SOA를 구축한 경험과 SOA를 구현하는 길잡이인 SOA 방법론인 SOMA(Service Oriented Modeling and Architecture)를 보유, 기업이 SOA를 구현하는데 있어서 실질적인 힘이 되도록 노력하고 있다.