이렇듯 지금 한국을 비롯해 전 세계의 IT 진영은 SOA로 전쟁을 한판 벌이기라도 하듯 열심히 선전하며, 하나라도 더 성공사례를 먼저 만들고자 프로젝트를 진행 중이다. 하지만 주위의 IT 전문가들은 조용한 분위기 속에 마치 컨설팅 회사와 공급업체간의 전쟁을 구경하듯이 다소 방관적인 입장에서 머무는 듯한 분위기이다. SOA, 이것이 단지 IT 공급업체 및 컨설팅 회사만의 문제일까? SOA 라는 새로운 물결이 어떤 변화를 이끌지 우리는 어떻게 변화에 대응해야 할지 새롭게 고민해봐야 할 것이다.

비즈니스 관점의 서비스 관리 체제로의 전환

오래 전부터 많은 고객 특히 C급의 임원들을 만나면 공통적으로 IT도 레고 블록(Lego Block)처럼 조립 하거나 블록이 부족하면 외부에서 사서 만들고 원하는 형태의 모양을 만들 수 있는 구조로 가야 한다고들 말한다. 이를 구현하기 위한 기술이 초기의 SOA로서 CORBA, DCOM 등이 있었으나 참여 벤더의 진영에 따라(MS진영 vs 반MS진영) 나누어지는 바람에 대중화에 실패를 했다. 

그러다 다시 웹 서비스라는 기술을 통해 이제는 MS, 반MS, 오픈, 소유권(Proprietary) 구분 없이 모두가 참여하는 대중화의 길을 걷게 됨으로써 소망이 현실로 다가오는 변화가 가장 큰 변화일 것이다. 즉, 다른 말로 바꾸면 바이 앤 빌드(Buy & Build) 전략을 구현해 회사에서 필요한 서비스에 대해 자체적으로 ‘빌드’를 하던가 아니면 외부에서 ‘바이’를 통해 필요한 서비스를 조합해 완성할 것이다. 가장 대표적인 것이 SaaS(Software as a Service)의 개념이다. 

SOA를 통한 변화는 우선 IT 부서에서는 개발/운영의 측면에서 시스템 단위의 개발에서 서비스 개발 체제로 변할 것이며, 서비스 통제에 대한 기능과 서비스 아키텍처라는 새로운 역할이 만들어 질 것이다. 가트너에서는 2009년까지 신규 애플리케이션 프로젝트의 80% 이상이 SODA(Service Oriented Development of Application)를 주된 개발 방법으로 채택한다고 예측했다. 결국 시간의 문제이지 변화의 물결은 이미 우리 앞에 다가와 있는 것이다.

이로써 IT 부서는 서비스에 대한 기획 능력이 핵심 능력이 될 것이며, 서비스를 통제 및 운영하기 위한 아키텍처 수립에 대해 많은 고민과 투자를 하여야만 한다. 단순하게 컴포넌트나 오브젝트 수준의 기술적인 관점에서 벗어나 현업과 시장 환경의 변화에 빠르게 지원하기 위해 비즈니스 관점의 서비스 관리 체제로 전환되어야 한다. 이에 재사용성 및 시장 대응에 민첩성을 염두에 둔 디자인 기법이 필요로 할 것이며, 이는 자체적인 경험과 타사의 경험을 바탕으로 간접 경험을 축척해야만 가능할 것이다.

왜 변화하지 못하고 있는가

작년만 해도 SOA의 개념 및 웹 서비스에 대한 차이를 이해시키느라 힘들었다. 한참을 고객의 임원을 대상으로 설명하면 결국에 듣는 질문이 “SOA는 표준 인터페이스 기술을 이용하는 방식으로 이해하면 됩니까?”라는 것이다. 한편으로는 맥이 빠지기도 하지만 한편으로는 절반의 성공을 건졌다는 생각도 든다. 

결국 많은 IT 관리자들이 기존 시스템간의 연결고리를 표준 기술을 이용하여 레고 블럭처럼 뺏다 꼈다가 자유로운 시스템으로만 이해하고 있는 것이다. 물론 그 말도 틀린 것은 아니지만 단순하게 표준 기술의 인터페이스만 준수한다고 SOA가 적용되는 것은 아니다. 

예를 들어 오라클이나 IBM처럼 토털 솔루션을 지향하는 업체의 제품을 일괄 구매해 시스템을 구축한다고 하면 표준은 아니더라도 각기 제품 간의 연결 문제는 없어질 것이다. 하지만 이것을 SOA라고 말할 수는 없다. 결국 웹 서비스라는 표준 기술을 이용해 서비스를 호출하고 수행하여 결과를 전해주는 역할 이면에는 아키텍처 디자인(Architecture Design)이라는 커다란 보이지 않는 철학과 메커니즘이 숨어 있는 것이다. SOA는 아키텍처를 디자인하는 철학이자 이데올로기라고 말할 수 있다.

SOA 도입 이전에 많은 회사들이 SOA 전 기술이라고 불리는 CBD 방식의 개발을 많이 도입했지만 제대로 운영되고 있는 것을 몇몇의 선진 프로젝트를 제외하고는 본적이 없다. 이유는 기술만 도입할 뿐 이에 걸맞은 변화 관리와 조직/거버넌스 체제를 도입하지 않았기 때문이다. 실제 프로젝트에서도 에러/메시지 처리 등의 기본적인 공통 컴포넌트만 관리할 뿐 전체적인 재사용성 강화 및 민첩성 측면의 운영은 기존 방식(조직/운영/관리/프로세스 등) 그대로 운영하는 경우가 많다.

서비스와 컴포넌트/오브젝트의 가장 큰 차이는 비즈니스적인 관점이냐 아니면 기술적인 관점이냐이다. 기술적인 관점도 제대로 운영을 하지 못하는데 IT 부서의 고객인 현업과 고객을 상대로 비즈니스 관점의 서비스를 잘하기는 매우 힘들다.

또한 많은 회사가 ESB, BPEL 등의 제품을 도입하면 SOA를 적용하는 것으로 알고 있는데 이는 매우 큰 오산이다. 그러한 제품은 SOA를 가능하게 해주는 단순한 기술적인 관점의 제품일 뿐 서비스를 어떤 단계로 적용 및 확산하고 유지할 것인가가 핵심이 된다.

우리는 SOA 이전의 비슷한 기술을 가지고는 있었지만 용도에 맞는 사용법과 변화관리에 실패를 해 돈 쓰는 IT가 돼버린 것일지도 모른다. 즉, 사고 방식과 조직 그리고 운영하는 방식은 예전 그대로이나 새로운 기술만 도입하여 제대로 된 변화관리를 하지 못한 것이 가장 큰 변화를 하지 못한 이유이다. 여기에 대한 대안으로 SOA라는 것을 제대로 이해하고 이에 걸맞은 비전과 조직 등의 체제를 갖추어야 진정한 SOA를 도입 및 활용할 수 있을 것이다.

새로운 패러다임에 맞는 변화 관리는 ‘필수’

작년에 많은 선도적인 기업들이 SOA에 대해 PoC(Proof of Concept) 혹은 파이럿 프로젝트 형태로 맛보기를 많이 했다. 이를 통해 SOA를 도입하기 위한 테크니컬 아키텍처에 대한 개념은 이미 많이 알고 있는 듯하다. PoC, 파일럿의 산출물인 아키텍처에 대한 방안이 SOA를 도입하기 위한 첫 번째 단추이다. 즉, 기술을 도입하기 위한 기술적인 프레임워크를 제시하여야 한다. 

서비스 아키텍처가 이를 수행하기 위한 역할(Role)이며, 기존의 인력에 추가적으로 조금씩 골고루 서비스에 대한 역할을 주는 것이 아니라 전담 부서 혹은 전담 인력을 지정 및 운영할 필요가 있다. 이 역할을 맡은 쪽에서는 전체적인 서비스에 대한 전략 및 기획 아키텍처 방향성 및 개발 가이드 등의 등대와 같은 지시자 역할 및 아키텍처 로드맵을 제시해 주어야 한다. 아키텍처 로드맵은 서비스의 구현 기술/크기/종류/개수/구축방안/측정방안/단계적 확산전략/운영전략/업그레이드 전략 등을 말한다.

SOBA 형태로 전환

두 번째는 단계적으로 확대 적용하기 위한 체계적인 조직을 갖추어야 한다. 단순하게 일회성 프로젝트로 끝나는 것이 아니라 지속적으로 수행하여 전체적인 IT 구조를 SOBA 형태로 전환 및 개선 발전시켜야 한다. 이를 위해서는 일회성 임시 조직이 아니라 상시 조직으로 확대 운영할 필요가 있으며 독립적인 운영이 힘들다면 기존의 아키텍처 조직을 강화할 필요가 있다. 

즉, SOA는 단순 제품을 도입해 개발해 끝나는 것이 아니라 IT 철학이자 IT 시스템을 구축하는 이데올로기이기 때문에 IT 부서가 존재하는 한 계속적으로 수명주기관리를 해줘야 한다.
마지막으로 가장 중요한 항목은 변화 관리 및 거버넌스 체제이다. 정보공학론 이후 IT는 많은 발전을 해왔지만 예전의 이러한 사고방식 및 기존의 개발 방법론은 SOA의 도입을 가로막는 낡은 유물이 되어가고 있다. 

하지만 여전히 이런 방법론이 대세인 것은 어쩔 수가 없는 듯하다. 새로운 기술이나 새로운 패러다임에 대해서는 걸맞은 방법과 이에 대한 변화 관리가 필수이다. 기존의 개발이야 주어진 명세서대로 개발하면 되지만 명세서를 만들고 IT를 운영하는 기획자 및 관리자 입장에서는 서비스 지향 IT에 대한 올바른 이해와 변화관리가 필수적이며 가장 중요한 변화의 항목이다.

시기적으로 SOA는 피할 수 없는 대세가 됐으며, 이를 어떻게 적용 및 반영하는가가 IT의 핵심 역량 중의 하나가 될 것이다. 이는 여러 가지 기술 중의 하나를 도입하는 것이 아니라 제품과 기술 그리고 이를 운영, 개발하기 위한 아키텍처, 관리체제, 변화관리 등이 동시 수행되어야 IT 시스템을 진정한 SOA로 적용할 수 있을 것이다. 

SOA가 말처럼 쉽지만은 않다. 하지만 SOA의 효과는 매우 크며, 진정으로 빠르게 변화하는 환경에 민첩하게 대응하는 IT 시스템을 만들기 위한 가장 효과적인 방법이다. 또한 비즈니스 환경 및 고객 요구에 대한 충격을 최소화할 수 있는 새로운 IT 아키텍처의 대안으로 부각되고 있는 것 만큼은 확실하다.

 자동차, 오디오 그리고 IT의 역사와 변화의 흐름

인류 최초의 자동차는 1769년 프랑스의 육군대위 니콜라스 죠셉 퀴뇨(Nicholas Joseph Cugnot)가 무거운 대포를 끌기 위해 증기기관을 이용해 최초로 탄생됐다. 그 후 약 250년간의 자동차 역사가 발전하면서 자동차 업계는 ‘One Build Many Use’라는개념을 이용하여 차종마다 부품 표준화 및 공용화를 이용해 제작 비용과 기간을 단축하고자 하는 노력을 기울이고 있다. 한국의 현대와 기아차도 투싼과 스포티지도 같은 차대(Platform)과 엔진을 사용하고 많은 부품을 공용화해 사용하고 있다. 

또 다른 관점은 오디오에서 찾아 볼 수 있다. 유명한 영국의 로텔(Rotel)사의 앰프와 CD플레이어를 사용하다 좀 더 수준 높은 음악 서비스를 받고자 좀더 비싼 매킨토시 앰프로 바꾸면 어떻게 될까? 기본적으로 음질의 차이를 느낄 수 있지만 아주 간단한 사실은, RCA라는 오디오의 표준 단자를 이용해 플러그를 뺀 후 새롭게 산 매킨토시 앰프에 물리기만 하면 모든 것이 해결된다.

자동차의 경우 ‘One Build Many Use’의 제조 방식을 통한 재사용성 강화를 통한 원가 절감 및 신속한 대응, 그리고 오디오처럼 마치 부속품(Component)를 교체해 보다 수준 높은 음색/음질의 서비스를 원하는 시점에 바로 느끼듯이, 1946년 애니악 개발 이후 60년의 역사를 가진 IT도 표준의 기술을 이용해 폐쇄적인 환경에서 오픈 환경으로 옮겨가며 IT 중심이 아닌 서비스 중심으로 서서히 변화의 물결을 타고 있다. 

SOA를 도입하게 되면 기존 IT 자원의 재사용을 통한 유연성과 민첩성을 강화해, 빠르게 변화하는 비즈니스 환경에 좀 더 빠르게 대응하는 것이 가능하다. 결국 SOA라는 것은 서비스 중심의 아키텍처로써 말 그대로 IT는 전용의 기술과 폐쇄적인 방식을 사용하는 것이 아니다. 

표준화되고 오픈된 기술을 사용함으로써 재사용성과 상호간의 구성의 재조합을 통해 새로운 서비스를 창출하고자 하는 개념의 IT 철학이자 IT 아키텍처의 방향성이다. SOA 기반의 애플리케이션을 통해 빠르게 변화하는 비즈니스 환경에 민첩하게 대응하고 60년의 짧은 역사이지만 250년의 자동차 역사를 뛰어 넘고자 하는 노력의 결실이 서서히 맺히고 있는 것이다.

사례

어느 한 회사에서는 베이터베이스에 접근하는 레이어에 대하여 데이터 서비스라는 개념을 통해 유연성 및 재사용성을 높이려고 했다. 그러나 데이터 서비스 계층에 대해 각자 개발하는 관계로 동일한 SQL에 대해 개발자의 수만큼 많은 버전이 존재해 재사용성을 무색하게 만든 경우도 있다. 데이터 서비스를 구축하기 위해서는 유연성과 재사용성을 높이기 위한 데이터 서비스만을 개발하는 팀과 기 개발된 데이터 서비스의 조합을 통한 사용하는 응용 팀이 있어야 하나 응용 팀 별로 개인별로 각자 개발 및 각자 사용해 제품 도입의 의미가 퇴색된 경우다. 원인은 제품은 도입했으나 조직 및 거버넌스가 걸맞지 않아 성과를 크게 달성하지 못한 것이다.

용어 해설

■ PoC(Proof of Concept) : PoC(Proof of Concept)는 흔히 기능검증테스트로 번역돼 사용된다. 영어 단어를 그대로 해석하면 컨셉의 증거로 어떤 새로운 개념이 나왔을 때 이 개념이 실제 활용할 수 있는지 여부를 검증해 보는 과정이라고 설명할 수 있다. PoC는 IT 분야에서 많이 쓰이고 있다. IT 분야에는 새로운 개념들이 시간을 다투며 쏟아지고 있다. 최근에는 SOA 개념을 검증하기 위해 PoC가 많은 기업들에서 행해지고 있다.   

SOA는 서비스 지향 아키텍처이다. 서비스 지향 아키텍처 개념을 실제 단위 업무 시스템에 적용하기 위해 가상의 업무와 업무 프로세스를 만들어 SOA 사상을 적용해 보는 것이다. 일부 소프트웨어 업체들에서 SOA 사상을 구현할 수 있는 솔루션들도 내 놓고 있다. 이런 솔루션을 PoC 해 봄으로써 실제 단위 업무 시스템에 적용할 수 있는지를 볼 수 있다. 

■ SOBA(Service Oriented Business Application) : SOBA는 웹 서비스 표준을 사용해 SOA에서 작동하도록 개발된 비즈니스 애플리케이션이다. SOBA는 고객관계관리(CRM), 전사자원관리(ERP), 공급망관리(CRM) 애플리케이션들처럼 IBM, 오라클, SAP 등 벤더가 시장에 내놓는 기존의 단순한 서비스 가능 비즈니스 애플리케이션이 아니다.
가트너에 따르면 마이크로소프트, IBM, SAP, 오라클 4개 벤더들이 SOBA 애플리케이션 제품과 플랫폼을 강화할 것이라고 전망하고 있다. 

이들 벤더 외에는 포털, BPM(비즈니스 프로세스 관리) 및 시스템 관리 영역에서 개발하고 관리하는 툴을 제공할 것으로 내다 보고 있다. 또 기업 안팍의 SOBA 구축과 관련해 조직의 SCM, ERP, CRM에 대한 투자 가치를 최대화하고 실용적으로 타당한 그리고 주요 거래 협력업체가 기술적 성과를 주도하는 새로운 시나리오가 부상할 것으로 예측하고 있다.

[IT TODAY 2007년 창간호 게재]