ESB-지향 아키텍처: SOA 채택에 있어서 잘못된 접근 방식 (한글)

엔터프라이즈 서비스 버스(ESB) 구현 프로젝트의 문제점을 짚어봅니다. 서비스 지향 아키텍처(SOA)라는 목표가 빠진 프로젝트가 왜 잘못된 생각인지를 설명하고, SOA를 올바르게 채택하는데 있어 무엇이 필요한지를 생각해 봅니다.

저자 : Bobby Woolf, WebSphere SOA and J2EE Consultant, IBM

머리말

전체적으로 SOA를 사용하지 않고, 엔터프라이즈 서비스 버스(ESB) 아키텍처만 구현하는 프로젝트를 수행해줄 것을 클라이언트들이 가끔 요청하곤 한다. 이와 같은 ESB 지향 아키텍처는 구상하기는 쉽지만 성공은 가늠하기 어렵다. 이와 같은 프로젝트를 요청하는 클라이언트는 ESB 지향 아키텍처는 비즈니스 가치를 이끌어 내지 못한다는 것을 이해하지 못한다. ESB 아키텍처에 기반한 프로젝트가 비즈니스 가치를 성공적으로 전달하기 위해서는 SOA 기반으로 전향해야 한다.

ESB 아키텍처만 사용하기

SOA는 비즈니스 요구 사항에 기반하고 있다. IT와 비즈니스를 제휴시켜 IT 시스템이 비즈니스가 수행되는 방식으로 실행되도록 하면서, IT가 비즈니스 가치를 만들어 내도록 하고 있다. IBM 백서, "IBM SOA Foundation: 아키텍처 소개와 개요"(참고자료)를 참조하라.

이 글에서, Bobby Woolf는 SOA의 핵심인 서비스를 규명 및 구현하려는 계획 없이 ESB를 채택하는 것이 왜 잘못된 생각인지를 밝히고 있다. 이것은 여러 번 언급되었던 일반적인 ESB 관련 문제들이기도 하다. 어떤 기술이 이끌어 낼 가치를 고려하지 않은 채 어떤 기술도 채택해서는 안된다. 이 글에서는 ESB라는 단어를 가상의 소프트웨어 제품 또는 용어로 대체했지만, 의미는 같다. 안타깝게도, 이 글은 일부 독자들에게 IBM은 더 이상 ESB에 가치를 두지 않는다는 인상을 주었다. 이 글은 (IBM의 입장은) ESB가 유용하고 필수적인 기술적 인프라스트럭처지만, SOA를 채택하는 것의 일환으로 채택되어야 한다는 것을 말하고 싶은 것이다. 이 문제에 대한 보다 자세한 내용은 "엔터프라이즈 서비스 버스 연구, Part 2: ESB가 SOA의 기본 요소인 이유" (developerWorks, 2007년 9월)를 참조하라.

SOA의 기본적인 목적은 비즈니스를 IT를 효과적인 방식으로 제휴시키는 것이다.

IBM 제품과 서비스를 사용하여 IT 시스템을 구현하는 IT 부서들은 비즈니스 요구 사항을 완벽히 이해하고 있지 않다. 시스템이 작동하는 방법을 정교하게 계획하는데 익숙한 엔지니어의 경우, 비즈니스가 수행되는 방식이 계획성 없고 마구잡이 식이라고 생각할 수 있다. 설명은 일관성이 없고 불가능하며, 비즈니스 사용자의 필요는 비현실적이고 늘 변한다. 비즈니스 요구 사항들은 신화와 속설처럼 조직 내에 존재하지만, 점차 그늘에 가려지고 만다.

이러한 관점에서 볼 때, IT와 비즈니스를 제휴시킨다는 것은 비현실적으로 보인다. IT는 비즈니스가 무엇을 원하는지를 모르고 있는 것 같다. 프로세스는 자동화를 거부하는 것 같다. 프로세스를 자동화 하려는 노력은 좌절되고 초점을 잃게 된다.

엔지니어가 이해하는 것은 기술이다. 기술은 비현실적인 위시 리스트를 필요로 하지 않는다. 다만, 코드가 필요할 뿐이다. 코드는 사용하기 어렵다는 점에 대해 불평하지 않고, 컴파일러는 원하는 바를 매일 바꾸지도 않는다. 코드는 작동할 수도 있고, 작동하지 않을 수도 있다. 코드가 오늘 실행되었다면, 내일도 실행될 것이다.

기술은 엔지니어가 더욱 이해하기 쉽고, 더 만족스럽다. 또한, 이것은 대부분의 엔터프라이즈 소프트웨어 기업들이 팔고 있는 주력 상품이기도 하다. ESB는 일종의 기술이고, 다른 기술들을 연결한다.

반대로, ESB는 이해하기 쉽지만 SOA는 복잡하다. ESB는 까다로운 비즈니스 요구 사항들을 필요로 하지 않고, 오직 기술적 요구 사항만 필요로 한다. ESB는 정확하다. 표준에 기반하고 있다. 데이터 포맷, 와이어 프로토콜, XML, IP, HTTP, SOAP, JMS, JAX-RPC, JAX-WS 등의 표준에 기반하고 있다. SOA는 분석에 의존하고 있지만, 실제로 무엇을 작동하게 하는 것은 ESB이다.

이것은 종종 "connect everything to everything" 프로젝트로서 언급된다. 클라이언트는 많은 파트들-애플리케이션, 컴퓨터 시스템, 데이터 센터, 부서, 자회사, 아웃포스트(outpost), 파트너 고객-을 갖고 있고, 이 파트들은 서로 소통하지 않는다. 왼쪽 파트들은 오른쪽 파트들이 무엇을 하고 있는지 모른다. 한 파트가 다른 파트가 필요로 하는 데이터를 갖고 있다면, 이러한 두 파트들은 서로 협력해야 한다. 모든 파트들이 서로 연결되어 있다면, 함께 작동할 수 있을 것이다. 비즈니스의 요구 사항이 무엇인지 이해하려고 하는 헛된 노력과는 달리, 모든 것이 서로 연결되어 있다면(connecting everything to everything) 문제는 해결될 수 있다. 기술로 문제가 해결될 수 있기 때문이다. IT 부서가 해머(hammer)라면, ESB는 SOA의 못(nail)이다.

"우리가 무엇을 필요로 하는지 몰라. 그래서 그저 ESB만 구현할 거야."라는 결심을 한다. 그렇다면 이것은 "코딩부터 시작하면, 그들이 무엇을 원하는지 알게 될 것이다."라는 접근 방식과 무엇이 다르단 말인가

꿈의 ESB

독자들은 종종 모든 것을 서로 연결하려는 욕구를 하나의 문장, 즉 엔터프라이즈 서비스 버스(enterprise service bus)로 요약하곤 한다. 그렇다면, ESB를 필요로 한다고 말할 때 이것은 무엇을 의미하는가 ESB로 무엇을 하려고 하는가 반드시 이것을 ESB로 칭해야 하는가

클라이언트들은 ESB라는 단어를 바꾸고 싶어한다. 엔터프라이즈(enterprise)대신, 회사(corporate), 부서(department), 정부(government) 같은 다른 조직 단위로 표현하고 싶어한다. 가끔, 사용처(procurement 또는 payroll)를 가리키기도 한다. 또는 제품 또는 주문 같이 이것이 전달하는 것을 기술하기도 한다. 클라이언트가 원하는 것이 "corporate product procurement service bus"라 할지라도, 서비스 버스(service bus)라는 단어에 속지 말라. 그러한 클라이언트는 ESB를 원한다. 이들은 가끔 "ESB이긴 하지만…"으로 설명될 수 있다.

클라이언트의 초점은 마지막 단어인 버스(bus)에 있다. 버스를 포함하고 있는 기술 토폴로지에서, 모든 것은 버스와, 그 버스를 사용하는 모든 것으로 연결된다. 버스는 파트들 간 통신의 주요 수단이다. 애플리케이션간 통신, 심지어 네트워크 상의 컴퓨터들 간 통신도 메시징연속적인 정보 패킷-을 사용하여 수행된다. 이것을 잘 설명하는 책, Enterprise Integration Patterns (참고자료)에서는 이와 같은 연결을 메시지 버스(message bus)라고 칭하고 있다.

클라이언트는 ESB의 서비스 파트에 대해서는 너무 많이 생각하지 않는다. xSB(엔터프라이즈 또는 기타)는 서비스를 호출한다. 또는, 단순히 메시지 버스이다. 서비스 호출이 의미하는 것은 다른 애플리케이션이 무엇을 수행하는지 말해주는 하나의 애플리케이션과, 이를 수행하고 응답을 보내서 결과를 보고하는 다른 애플리케이션을 의미한다.

따라서, 클라이언트가 구현하고자 하는 것이 xSB라면, 서비스는 무엇인가 "서비스는 모든 것이 다 될 수 있다"라고 IT 담당자는 말한다. 이것은 가장 명확한 대답이지만, 프로젝트는 순전히 기술적인 요소이다. 서비스가 관련이 없다는 것이 의미하는 것은 버스를 사용하는 애플리케이션이 관련성이 없다는 의미이고, 애플리케이션이 버스를 사용하는 방식이 관련이 없다는 것이고, 애플리케이션 통합 요구 사항들(비즈니스 요구 사항들)이 관련이 없다는 것이다. xSB는 모든 것에 적용된다. SOA를 위해 구축된 ESB는 처음에는 이러한 서비스 요구 사항들을 무시했다. SOA가 성장해 가면서 이것이 명확해 졌기 때문이다. 하지만, SOA 없는 ESB는 어떤 서비스도 없기 때문에, 이것은 단순한 버스에 불과하다.

단순한 버스만을 구현하는 프로젝트는 꿈의 IT 땅(IT field of dreams) 프로젝트로 간주될 수 있다. 야구 영화 속에 나오는 Kevin Costner의 역할처럼, IT 부서는 "구현하기만 하면 다 된다."라는 입장을 취할 것이다. 버스를 구현하면, 사람들은 버스와 관련한 SOA 애플리케이션을 구현할 것이다. 이러한 꿈의 땅(field-of-dreams) 방식의 문제점은 헐리우드와는 달리, 비즈니스 세계에서는 이들이 실현될 보장을 할 수 없다는 것이다. 사람들이 SOA 애플리케이션을 구현하면, 구현한 것이 맘에 들지 않으면, 사용하기 전에 많은 부분을 재구현 해야 한다. 결국 사용하게 되고 좋아하더라도, 만족도가 늦어지게 되고, 결국 IT 부서는 "영화"의 결말을 기다리기 힘들 것이다.

ESB- 지향 아키텍처의 한계 이해하기

ESB가 꿈의 땅이라는데 무슨 문제가 있는가 애니가 레이와 이혼하고 싶어했던 영화 중반이 기억나는가 (이 부분에서 사람들은 레이가 바보라고 생각했다.) 여러분의 프로젝트 역시 이와 같은 기간을 겪게 될 것이고, 프로젝트 스폰서는 자신의 고용주와 이혼하기를 원하지 않을 것이다.

문제는 이것이다. ESB 자체는 어떤 비즈니스 가치도 만들어 내지 않는다. ESB는 목표를 향해 가는 수단이지 목표는 아니다. ESB는 SOA의 전기 와이어 또는 배관과도 같다. 배관은 가치를 만들어 내지 않는다. 싱크대에 달린 수도 꼭지와 같은 역할이다. 전선은 가치를 만들어 내지 않는다. 빛, 특히 스위치와 연결된 빛이 가치가 있는 것이다. 한 지점에서 다른 지점으로 이끌 수 없다면 길은 쓸모가 없다. SOA가 없는 ESB는 어떤 누구도 가고 싶어하지 않은 길로 이어지는 길과도 같다. 사람들은 이런 길로 가고 싶어하지만, 중간에 모든 돈을 탕진하고 어떤 이득도 볼 수 없다.

ESB-지향 아키텍처는 어떤 누구도 사용하고 싶어하지 않는 연결을 구현한다는 점에서 태생적 한계를 지녔다. 비즈니스는 시스템이 다른 것과 연결되고 함께 작동하지 않는 한 추가 가치를 만들어 내지 않는다. 결국 ESB는 아무런 효과도 없이 비용만 들이게 된 것이다. 무엇인가를 구현했다는 이유로 IT 부서는 만족할 수도 있겠지만, 비즈니스는 어떤 것도 달성할 수 없었기 때문에 나아질 것이 없다. ESB는 IT 부서의 부속물처럼 되어가고 있다.

"구현만 하면 다 이루어진다."라는 꿈의 슬로건 대신, Extreme Programming (XP)의 슬로건이 더욱 알맞다: "결국 쓸모 없어 질 것이다." 이러한 슬로건은 다음과 같은 매우 실용적인 원리를 줄인 말이다.

필요할 것이라고 예상할 때가 아닌, 실제로 필요할 때 구현하라.

필요하기 전까지는 구현하지 말라고 하는 이 원리는 꿈의 IT 땅(IT field of dream) 원리와는 반대된다. 누군가가 필요로 할 것이라는 희망으로 구현하는 대신, 누군가가 실제로 필요로 한다는 것을 알기 전까지는 구현하지 말라. 이렇게 하면, 누군가가 결국 필요로 할 것이라고 예상하는 것이 아닌, 실제로 필요로 하는 것을 구현할 수 있다. 구현을 통해 이득을 보기 전까지 구현 비용을 물지 않게 된다. 이러한 원리는 훌륭한 비즈니스 철학이며, 비즈니스의 다른 부분들은 물론 IT 부서에도 적용된다.

SOA 사용하기

지금까지 소프트웨어 개발의 원리에 대해 몇 가지를 배웠다:

필요하기 전까지는 구현하지 말라.
비즈니스 가치를 만드는 것을 구현하라.
IT와 비즈니스를 제휴시켜라.

ESB-지향 아키텍처를 따르는 대신, SOA를 따르고, SOA의 일부로서 ESB를 구현하라. 다시 말해서, IBM SOA Foundation: 아키텍처 소개와 개요 ( 참고자료)에서 설명한 것처럼, SOA 토대 아키텍처를 구성하고 있는 애플리케이션을 구현 및 통합하는데 SOA를 사용하라.

이러한 접근 방식을 사용하여, SOA를 개발하는 것의 일환으로 ESB를 개발하라. 비즈니스 필요에 기반한 서비스를 발견한다. 각 서비스는 공급자와 소비자뿐만 아니라, 이 둘을 연결할 ESB의 채널을 필요로 한다. 이 채널은 서비스의 원격 호출(인터프로세스 통신)을 실행하는 서비스 요청과 응답을 위한 메시지 포맷을 포함하여, 공급자(프록시로서도 사용됨) 같은 서비스 인터페이스를 구현한다. 소비자와 공급자의 서비스 인터페이스, 메시지 포맷, 범위, 서비스 품질에서의 차이점은 보완될 수 있고, 중재될 수 있다. 이 모든 것은 ESB 디자인의 핵심이며, 이중 어떤 것도 ESB가 호출하는 서비스를 알지 못한 채 수행될 수 없다. 이러한 서비스를 이해하려면 ESB를 사용할 SOA에서의 서비스를 알아야 한다.

이러한 관점에서, 애플리케이션들을 연결하는 것은 쉬운 일이다. 비즈니스 기능을 연결하는 것은 큰 도전이다. 이는 ESB만을 구현해서는 이루어질 수 없다.

결론

클라이언트는 종종 ESB만을 구현하기 원한다. 혼잡한 비즈니스 요구 사항 없이도 기술적 문제를 개입시키기 때문이다. ESB만을 구현하는 것은 꿈의 IT 땅이 되겠지만, IT는 ESB를 구현하고, SOA가 구현되어 이를 사용하기를 바랄 것이다. 이 같은 ESB 지향 아키텍처는 SOA의 혜택을 잃는다. 비즈니스 가치를 만들어 내지 않는다. 사실, 즉각적인 혜택도 얻지 못하고 비용만 발생시킨다. 그리고 IT와 비즈니스도 제휴시키지 못한다. ESB 지향 아키텍처에 대한 올바른 대안은 SOA이다. ESB 자체만 구현하지 말라. SOA의 일부로서 이를 구현하라. IBM이 권장하는 SOA Foundation 아키텍처에 맞는 것으로 구현하라.

참고자료

교육

"엔터프라이즈 서비스 버스 연구, Part 2: ESB가 SOA의 기본 요소인 이유" (developerWorks, 2007년 9월). & Part 1

"IBM SOA Foundation: 아키텍처 소개와 개요" (developerWorks, 2005년 12월).

"A quick intro to WebSphere？？ Business Process Management" (developerWorks, 2006년 2월)

"Kevin Costner가 야구장을 건설하는 것과 같은 방식으로 IT 부서가 시스템을 구현해야 할까" IT field-of-dreams 컨셉에 대한 추가 정보

ESB.

"엔터프라이즈 서비스 버스로 아키텍처 통합을 단순화 하기" (developerWorks, 2005년 8월)와 "<a href="http://www.ibm.com/developerworks/webservices/library/ws-whyesb/S_TACT=105AGX55&amp;S_CMP=EDU" ,terget="_blank">개발자에게 엔터프라이즈 서비스 버스가 필요한 이유" (developerWorks, 2005년 8월)

Enterprise Integration Patterns

"You Aren't Gonna Need It" : Extreme Programming Roadmap wiki.

SOA와 웹서비스 존 : IBM developerWorks

<a href="http://www-306.ibm.com/software/solutions/soa/S_TACT=105AGX55&amp;S_CMP=EDU" ,terget="_blank">IBM SOA 웹사이트

<a href="http://www-128.ibm.com/developerworks/offers/techbriefings/S_TACT=105AGX55&amp;S_CMP=EDU" ,terget="_blank">developerWorks 기술이벤트와 웹캐스트

° 유연하고 확실한 WebSphere로 SOA 시작하기
° SOA 솔루션 구축과 서비스 라이프 사이클 관리
° SCA/SDO: 차세대 SOA
° SOA 재사용과 연결

Safari bookstore.

제품 및 기술 얻기

IBM 시험판 소프트웨어를 차기 개발 프로젝트에 활용해보라.(다운로드 또는 DVD 제공)

토론

developerWorks 블로그 참여하기.