아키텍쳐 /SOA

SOA에 대한 기술적 접근

Terry Cho 2007. 8. 20. 10:55

월간 마이크로소프트웨어 2007년 7월호 기고 내용

==
“ SOA는 무엇이고, SOA를 준비하기 위해서 무엇을 해야 할까? 그리고 SOA 시스템을 구축하기 위해서는 어떤 기술을 준비해야 할까 ? ”

수년간 많은 벤더와 매체를 통해서 SOA라는 단어를 들어보고, 웹서비스, ESB, BPM, Governance와 같이 SOA와 관련된 주요 키워드들에 대해서 접해왔을 것이다. 그러나 정작 시스템을 어떻게 SOA화 해야하는지 심한 경우에 SOA 자체가 무엇인지 조차 이해하지 못하는 경우도 많다.

 이 글에서는 SOA의 올바른 이해와 함께, SOA 시스템 구축에 용이한 기술에 대해서 알아보도록 하겠다. 

  1. SOA란 무엇인가?

 SOA란, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한 후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐이다. 

SOA의 단계적 발전 모델

필자가 SOA를 이야기 할 때 빼놓지 않고 이야기 하는 것 중의 하나가 SOA의 발전 모델이다.  
초기의 SOA는 시스템을 서비스화하여 이를 묶어서 하나의 통합 시스템으로 구축하는 통합 중심의 SOA모델이었다. 이 모델은 P2P형식으로 서비스를 묶는 것에 중점을 두었으며 특히 이 기종간의 통합이 주요 목적이었다. 이런 초기적인 SOA 모델을 Fundamental SOA라고 이야기 한다.

이런 SOA모델이 발전함에 따라서 P2P형식일 경우 서비스간의 연결이 거미줄처럼 연결되어 통제가 불가능하게 되고, 서비스의 변경에 따라 그 서비스를 사용하는 다른 시스템에 영향도가 증가해서 시스템의 유연성이 떨어지게 되었다. 이를 보완하기 위해서 서비스의 연계 구조를 중앙에 Hub를 넣어서 중앙 집중형 구조로 변경하고 업무의 변화에 따라서 변화 내용을 반영하는 서비스 (Intermediary service)를 추가한 모델을 Networked SOA라고 한다.

기업의 업무 환경이 급속하게 변화함에 따라 서비스를 묶어서 구현한 업무 프로세스의 변경이 잦아지게 되는데, 이 잦은 업무 변화를 빠르게 반영하고 또한 현업과 IT조직간의 업무 정의에 대한 커뮤니케이션을 쉽게 하기 위해서 도입되는 것이 BPM이다. 이러한 BPM도입을 통해서 SOA시스템에 민첩성을 추가한 SOA구조가 Process Oriented SOA이다. 

간략하게 SOA의 개념과 발전 모델에 대해서 설명을 하였는데 이는 SOA를 개발하는데 유용한 기술의 발명 단계와도 관련이 있기 때문이다.  

좀더 자세한 설명은 http://blog.javastudy.co.kr/bcho/entry/What-is-SOA-How-to-SOA 문서를 참고하기 바란다 

  1. SOA 관련 기술

 웹서비스를 사용하면 SOA라고 말할 수 있을까? ESB를 사용하고 있으면 SOA 시스템이라고 말할 수 있을까?

 대답은 NO! 이다. SOA는 앞에서도 설명했듯이 시스템을 개발하기 위한 하나의 아키텍쳐이며 개념이다. 웹서비스나 ESB는 SOA개념을 구체화 하기 위한 요소 기술이나 솔루션에 불과하다. 이러한 기술들은 SOA 아키텍쳐를 구현하고 고민하면서 필요에 의해서 선택되거나 개발된 솔루션이다. 그래서 기술을 선택할 때 원래 이러한 기술이 나오게 된 이유 즉, 필요성에 대한 인식을 하지 못하면, 잘못된 기술을 선택하는 결과를 낳을 수 있다. 

“SOA에 대한 이해를 통해서 기술과 솔루션의 필요성을 인식한다.”

SOA를 구축하기 위한 몇가지 유용한 기술에 대해서 소개한다. 

  1. 업무 도메인에 대한 이해

“조엘 온 소프트웨어”를 보면 소프트웨어를 크게 4가지 종류로 나눈다. 기업용 소프트웨어, 서비스 소프트웨어, 패키지, 엔터테인먼트 소프트웨어 종류로 나뉘어 진다.

패키지는 MS-Office처럼 패키징이 되서 판매되는 소프트웨어를 말하고 엔터테인먼트는 게임이나 MP3 등과 같은 성격의 소프트웨어를 말하며 서비스 소프트웨어는 블로그, 카페, 인터넷 포탈과 같은 B2C 형식의 소프트웨어를 말한다.

 이 4가지 분류에서 현재 SOA가 적용되기 적절한 것은 기업용 소프트웨어와 서비스 소프트웨어 이다. 물론 소프트웨어 인프라가 발전이 되면 MS-Office에서 맞춤법 검사나 폰트등이 서비스 형태로 인터넷에서 제공될 수 있지만, 현재로써는 SOA가 적용되기에는 다소 이르다고 볼 수 있다.특히 현재 주류를 이루는 SOA는 기업용 소프트웨어는 업무 복잡도가 높고 시스템간의 복잡한 연계가 많아 SOA 사용시에 여러 장점이 많으며, 비용에 민감한 구조가 SOA의 장점에 부합하기 때문이다. 상대적으로 서비스 소프트웨어의 경우 은행 계좌 이체와 같은 Critical한 업무가 적으며 복잡도나 변화도가 낮기 때문에, SOA의 개념을 변형하여 WEB 2.0에서 OPEN API의 개념으로 구현하고 있다.

SOA를 적용하기 위해서는 적용하고자 하는 업무가 이 4개의 소프트웨어 종류중에 어느것에 해당하는지를 인식할 필요가 있다. 

  1. XML

 XML은 SOA의 서비스의 메시지를 정의하는데 매우 유용한 기술이다. 유연성과 가독성이 높고 플랫폼에 종속적이 아니다. 이런 이유로 현재의 SOA의 대부분이 XML을 이용하여 서비스의 메서드를 정의하고 있다. XML 문서 정의 기술 자체와, XML의 항목을 쉽게 얻어올 수 있는 XPath, XML의 문서 형식을 정의하기 위한 XML Scheme, DTD, XML 문서를 변환하기 위한 XSLT, XML 문서의 내용을 마치 데이타베이스의 SQL처럼 쿼리하기 위한 XQuery등이 현재의 SOA에서 주로 사용되는 XML 관련 기술이다.

이를 프로그램에서 처리하기 위한 자바 관련 기술로는 XML 파싱 기술인 JAXP 등이 있으며 요즘에는 XML 문서와 JAVA 객체를 복잡한 Parsing API를 사용하지 않고 상호 변환해주는 XML to Java 기술이 있으며, J2EE에서는 JAXB가 표준에 포함이 되어 있고 그 외에도 Castor와 같은 비표준 기술이 있다.

  1. 웹서비스

 SOA의 서비스를 구현하기 위해서는 표준화된 인터페이스를 통해서 서비스를 제공해야 한다. 이를 위해 인터페이스 표준화 기술이 필요한데, 주로 언급되는 것이 웹서비스이다. CORBA, RMI 또는 XML/HTTP등과 같은 프로토콜을 사용해도 되지만 웹서비스가 SOA에 있어서 주목을 받는 이유는 XML 기반이기 때문이다. 웹서비스는 다른 프로토콜에 비해서 비교적 쉽고 .NET, JAVA 와 같은 개발 플랫폼에 상관없이 모든 솔루션에서 호환성이 뛰어나기 때문에, SOA의 표준 인터페이스로 많이 사용된다.

 웹서비스 표준은 WS-I을 기본으로 하고 있고, 트렌젝션이나 로깅 관리, 메세징 (Sync ,Async ,Reliable)등의 부가적인 기능을 제공하기 위해서 WS* (Webservice extension)이라는 확장 표준을 정의하고 있다.

웹서비스 적용에 있어서 주의 할 점은 표준을 지원하는 방법이 벤더나 솔루션 마다 다르다는 것이다. 예를 들어 Reliable Meassaging의 경우, Vendor에서 웹서비스를 이용한 Reliable 메세징을 지원한다고 해서, WS-Reliable Messaging의 표준을 따르지는 않는다. Reliable Messaging의 표준이 나온지 얼마 되지 않지만, 각 Vendor는 각자의 고유 방법으로 Reliable Messaging을 지원하다가 표준이 나온 후 표준 기반의 Reliable Messaging을 지원하기 때문에, 이러한 기능들을 어떤 표준이나 구현방법으로 웹서비스에서 지원하는지에 대한 확인이 필요하다. 

  1. CBD (Component Based Development)

 SOA에서 가장 중요한 것 중 하나는 서비스의 정의 방법이다.

SOA의 서비스 정의를 다시 살펴보면, “기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서..” 와 같이 기능을 비즈니스적인 의미를 갖는 컴포넌트로 묶는데 있다.

이 서비스 컴포넌트의 단위를 Fine-grained (작은 단위)로 묶을 것이냐? Coarse-grained(큰 단위)로 묶을 것이냐? 는 SOA에서 중요한 하나의 설계 포인트가 된다.

Fine grained로 서비스를 나눴을 경우에는 각각 서비스의 의미는 정확해지지만 많은 서비스들이 존재하기 때문에 관리가 어려워지는 결과를 낳게 되며, Coarse grained한 서비스는 각개의 서비스기능을 사용하기 위해서 큰 서비스 컴포넌트를 사용해야 하기 때문에, 효율성의 문제가 생긴다.

비즈니스 업무를 효과적으로 서비스 컴포넌트로 추출하기 위해서는 방법론이 필요한데, 현재에는 SOA를 위한 명확한 방법론이 많지 않다. 벤더나 컨설팅 업체마다 SOA 방법론이라는 것을 제공하고는 있지만, 필자의 개인적인 생각으로는 충분하지 않고 추상적이거나 학문적이라는 생각이 든다.

서비스 역시 소프트웨어 관점에서 보면 하나의 소프트웨어 컴포넌트이고, 컴포넌트에 대한 분석 설계를 하기 위한 방법론으로는 대표적으로 CBD (Component Based Development)가 있다. 비단 CBD가 아니더라도 비즈니스 업무를 적절하게 서비스로 맵핑 시키고 그 서비스의 크기(Granuality)를 결정하는 것은 SOA에 있어서 매우 중요한 기술 요소가 된다. 

  1. Integration

 SOA 시스템은 서비스를 조합하여 업무를 구현해야 한다. 이 과정에서 이기종이나 타시스템간의 트렌젝션을 보장해야 하는 경우가 있다. 이런 경우에는 서비스를 묶어서 하나의 트렌젝션으로 구현하거나 또는 시스템들을 묶어서 트렌젝션을 보장하는 하나의 서비스를 구현하는 두가지 방법이 있다.

 전자의 경우 서비스에 트렌젝션을 보장하기 위한 기술이 필요한데, WS*-Transaction과 같은 기술이 있지만, 아직 일부 벤더에서만 제공하고 있다. 웹서비스를 통해서 트렌젝션을 묶을 경우 XML과 HTTP 통신등의 부하로 인해서 트렌젝션 처리에 대한 속도문제가 대두될 수 있다.

후자의 경우에는 시스템간을 통합하는 방법으로 여러가지 방안이 있겠지만 현재 자주 사용되는 아키텍쳐로는 EAI (Enterprise Application Integration)을 통해서 시스템을 통합하는 방법이 있으며, 트렌젝션 관리를 위한 요소 기술로는 JTA,JTS와 같은 트렌젝션 관리와, 이 기종 시스템들을 표준화된 인터페이스로 연계 하기 위한 Connector 아키텍쳐인 J2CA등이 있다. 

  1. ESB

 SOA 시스템의 규모가 커져가고, 오가는 메시지의 포맷이 다양화 되면서, P2P형식의 단순 통합형태의 SOA에서 버스를 중앙에 둔 SOA 시스템이 고안되었고, 이를 구현한 구현체가 ESB(Enterprise Serbvice Bus)이다. ESB의 초기 디자인시의 기능은 들어오는 표준메세지에 대한 변환,라우팅,모니터링등의 기본적인 기능만을 가지고 있었으나, 근 1~2년간 Legacy 시스템을 연동할 수 있는 기능, 메시지 통신 방법을 Async나 Reliable 메세징을 지원하는 기능들이 추가되는등 매우 빠르게 발전하고 있으며, 요즘에서는 SOA 2.0이나 EDA (Event Driven Architecture)라는 개념을 부가하여, 새로운 형태의 ESB 제품을 계속해서 출시되고 있다..

ESB는 SOA 시스템에서 척추와 같이 중요한 기능을 하고 있으며, SOA의 솔루션 중 가장 중요한 솔루션으로 인식되므로 ESB의 발전되는 기능에 대해서 지속적으로 알아둘 필요가 있다. 

  1. BPM

서비스를 조합한 업무의 구현이 복잡해지고, 기업의 환경이 빠르게 변화함에 따라 그 속도에 따른 업무 변화를 요구하므로 신속하게 서비스를 조합하고 변경할 필요성이 생겼다.

이런 요구를 반영하기 위해서 BPM이 SOA에 사용되기 시작했다. SOA에서는 BPM 솔루션을 사용하는데, BPM을 이용해서 업무를 조합하는 것은 솔루션을 사용하면 되지만 좀더 중요한 것은 업무를 어떻게 BPM으로 구현하는 가이다. 

  1. Enterprise Portal

여러 시스템을 SOA로 통합함에 따라 사용자 인터페이스에 대한 통합 역시 필요하게 되는데, 사용자 인터페이스에 대한 통합이 Enterprise Portal이다. 업무 화면에 대한 통합, 권한 통제, Single Sign On등의 문제를 해결할 수 있다.

이미 많은 시스템에서 SOA를 이용 여부와 상관없이 Enterprise Portal을 통해서 업무를 하나의 UI로 통합하고 있다. Enterprise Portal은 비교적 간단하게 프로젝트를 진행할 수 있지만 특히 여러 시스템을 동시에 호출해서 하나의 UI에 보여주는 만큼 성능에 대한 깊은 고려가 필요하다. 

  1. RIA & AJAX

WEB 2.0이 나오면서 화두가 되고 있는것중에 하나는 RIA (Rich Internet Application)이다. 기존의 단순한 HTML 기반의 화면 UI에서 벗어나서 마치 GUI 애플리케이션과 인터페이스를 웹브라우져에서 제공할 수 있다.

현재 RIA 기술로 많이 사용되는 것은 AJAX,Adobe Flex이다. Applet이나 Active X를 이용해도 RIA 를 구현할 수 는 있지만, Applet이나 Active X는 다운로드에 소요되는 시간이 길고, Platform Dependency를 가지고 있기 때문에 AJAX나 Flex가 널리 사용된다.

특히 AJAX나 Flex는 XML 기반으로 메시지를 처리하고 HTTP 프로토콜을 사용하기 때문에 웹서비스를 사용하는 SOA에는 매우 쉽게 적용할 수 있기 때문에, SOA의 RIA 기술로써 유용하게 사용될 수 있다.

이미 국내의 통신사와 보험회사의 프로젝트에서 AJAX 기반의 RIA 클라이언트가 사용되었으며, 업무 시스템 역시 XML/HTTP 인터페이스 기반의 SOA 1단계 레벨로 구현되었다.

기업의 업무가 복잡해지고 빠른UI처리와 여러UI 기능이 필요함에 따라 RIA의 요구가 증가하게 되었고, 특히 XML,HTTP에 친밀한 AJAX나 Flex 기반의 RIA기술을 SOA에 유용하게 적용할 수 있다. 

  1. Governance

Governance는 소프트웨어 프로젝트의 기획에서부터 개발 운영까지의 모든 과정의 통제를 이야기 한다. Governance 역시 SOA 이전부터 등장한 개념이지만, SOA의 등장과 함께 중요시되는 이유는 SOA의 특징중의 하나는 전체 시스템을 하나의 SOA 거대 시스템으로 묶기 때문에 전체 프로젝트를 관리할 수 있는 방법이 필요하기 때문이다.

Governance는 작게는 형상관리, 배포 관리, 프로젝트 관리에서부터 기업의 장기적인 IT전략의 수립 기술의 전도에 까지 전반적인 IT환경에 대한 관리를 필요로 하기 때문에 프로젝트 관리와 전략 수립에 대한 준비가 필요하다. 

지금까지 간단하게나마 SOA 구축에 유용한 몇가지 기술에 대해서 살펴보았다. 필자가 “필요한”이 아니라 “유용한”이라는 단어를 선택한 이유는 SOA를 구축하는데 정해진 기술이나 방법론은 없다. SOA는 아키텍쳐이며 개념일 뿐이고, 이를 효과적으로 구축하는 것은 개발자의 몫이며, 적절하게 필요한 기술을 선택하여 SOA를 구축하는 것이 중요하기 때문이다. 

    SOA가 활성화되지 않는 이유. 

    비단 필자많이 아니라 많은 사람들이 “왜? SOA가 활성화 되지 못할까?”에 대한 많은 의문들을 가지고 있을것이라고 본다.

    SOA의 개념을 도입한 시스템은 1996년대부터 개발되어서 운영되고 있고 그 사례 또한 다양하다. 이런 사례들이 있다면 불가능한 프로젝트가 아닐텐데 왜 SOA가 활성화 되지 못할까? 

    * 경영자들의 인식 부족 

     필자는 가장 큰 원인을 “SOA에 대한 이해 부족”과 “Governance”조직의 부재라고 생각한다.

    국내의 SOA도입을 시도하는 기업의 담당자들과 이야기를 해보면 SOA의 개념이 무엇인지 ESB가 무엇인지를 제대로 이해하고 있는 사람이 드물다. 설사 SOA의 개념을 제대로 이해하고 있는 사람을 만나더라도 실무 개발자일 경우가 많다.

    SOA는 EJB등과 같은 구체성을 가지고 있는 기술이 아니라 개념이며 하나의 전사적인 IT경영전략이다. 그래서 실무진에서부터의 제안이 아니라 경영진의 장기적인 전략과 의지를 가지고 위에서부터 수행해야 하는 문제임에도 불구하고, 국내 경영진들은 SOA에 대한 개념과 의지가 약하다.

    국내의 IT 관련된 책임자들은 빨리 현업의 서비스를 개발해주고 안정적으로 운영할 수 있고 적은 비용을 초점으로 두며 특히나 단기적인 성과에 많이 집착을 하게 된다.

    국내에서 전사포탈(Enterprise Portal)이 기업에서 확산되는 이유는 통합에 대한 이슈를 수용하면서도 가장 짧은 시간내에 가시적인 성과를 보여주기 때문에 SOA에 비해서 높은 확산을 보이고 있는것이라고 생각한다.

    그러나 SOA로 시스템을 구축하면 단기적인 성과를 보기 어렵다. 초반에 SOA에 관련된 인프라를 구축하고, 기존 시스템을 서비스화하기 위해서는 많은 비용이 소요되지만 이러한 초기투자는 초기보다는 장기적인 관점에서 효과를 낼 수 있는것이기 때문에 선뜻 인프라에 대한 투자가 어렵다.

    또한 SOA는 하나의 업무가 아니라 궁극적으로는 전사적인 업무를 하나의 SOA시스템으로 묶는것이기 때문에, 기존의 부서나 프로젝트 단위의 통제 모델이 아니라 전체 시스템과 프로젝트에 대한 전사적인 통제조직이 필요하다.(Governance)

    그러나 국내에서는 부서간의 커뮤니케이션 문제와 부서간의 파워게임(?) 때문에 전사적인 통제 조직이 하부 조직을 관리하기가 어렵다.

    SOA Governance 조직이 있는 경우도 드물거니와, 있다하더라도 그에 충분한 통제 권한과 비용이 지원되는 경우가 드물다. 경영자가 SOA를 도입해서 그만한 효과를 보고자 한다면 그에 상응하는 의지를 가져야 하지 않을까? 

    이런상황에서 어떻게 해야 기업에서SOA를 도입할 수 있을것인가?

    SOA에 도입에 의한 가시적인 성과에 대한 공감을 이끌어 내야 한다.

    필자의 글중에 SOA 도입 방법론에서 설명한 내용중에, SOA의 첫 프로젝트에 대한 중요성을 언급한 내용이 있다. SOA의 첫 프로젝트는 가장 관심을 받는 프로젝트이며 SOA의 필요성과 장점을 필역할 수 있는 프로젝트이여야 한다. 그래서 SOA로 구현한 첫 프로젝트는 그에 대한 성과는 높이 평가되어야 하며 실패하지 말아야 한다.

    성공적인 SOA를 위해서는 첫 프로젝트를 선택하는 것이 매우 중요하며 “기업의 핵심 업무중 가시성이 높고 상대적으로 위험도가 낮은 업무를 선택”해야한다. 

    * 벤더의 SOA

    하나 또 집고 넘어가고 싶은 것이 벤더 들에서 이야기 하는 SOA이다.

    Messaging 시스템을 개발하던 벤더는 SOA 시스템중 메세징에 중점을 둔 ESB를 이야기 하면서 ESB가 SOA의 전부인 것 처럼 이야기하고, BPM이 강점인 벤더는 BPM이 SOA의 전부인 것 처럼 이야기 한다. SOA의 원래 개념보다는 벤더들의 제품과 자사의 장점에 맞춰서 SOA를 제각각 해석이 되고 그것이 전체 SOA인 것 처럼 이야기 한다.

    어떤 벤더들은 SOA를 할려고 하면 Governance도 해야하고 ESB도 있어야 하고 EAI,EP등등 모든 솔루션들을 다 이야기 한다. 틀린말이라고는 하지 않겠지만, 한꺼번에 그런 솔루션들을 도입한다고 해서 SOA화가 될까? 물론 가능은 하겠지만, SOA는 그런 솔루션을 당장에 도입하지 않더라도 단계적으로 차근차근 발전 시키면서 기업 업무에 필요한 솔루션을 선택해서 성숙 시켜나갈 수 있다.

    SOA를 도입하고자하는 기업이 SOA에 대한 이해를 하는데 어려운 점중에 하나가 이러한 벤더들의 SOA를 자체적으로 해석하고 포장한 것 때문이 아닐까?

    SOA를 제대로 수행하기 위해서는 벤더들에게 이끌려가지 말고, SOA를 적절히 이해해서 필요한 솔루션을 벤더들에게서부터 선택할 수 있는 수준의 SOA 자체에 대한 이해가 필요하다.

그리드형

'아키텍쳐 > SOA' 카테고리의 다른 글

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20