calmglow (최진호)

'불가사리와 거미(TheStarfish and The Spider):리더 없는 조직의 막강 파워'라는 책에서는 분산화된 의사결정 구조를 지닌 조직 구조를 '불가사리 조직'이라 부른다. 불가사리는 다리를 절단해도 새로운 다리가 생겨나 듯 권한이 하부 조직에 분산되어 있으며 엄격한 계급이나 틀에 박힌 비즈니스 권위를 찾아보기 힘들다. 구글, 애플 등 혁신적인 기업들로 평가받는 조직의 다수는 이와같은 조직구조를 보이고 있다. 도요타나 GE같은 중앙집중적인 관리가 체계화되어 있는 조직 구조와는 태생자체가 다른 구조이다.

SOA는 그 아키텍처 철학에서부터 중앙 집중적인 조직, 중앙 집중화된 서비스 통제를 강조하고있다. 이러한 기업 구조에서 CEO는 하부 조직에 명령을 전달하고 책임을 부여하고 그것의 수행결과를 감시하며 평가할 수있다. SOA는 철저하게 비즈니스적인 의사결정이 IT에 전달되고 그것을 비즈니스적으로 평가할 수 있는 잣대와 구조를 만들어가는구조인 것이다.

반면에 EDA는 탈 중앙 집중적이다. 즉 분산화된 의사 결정 구조를 가지고 있으며 앞에서 언급한 '불가사리'형 조직을 꿈꾸는 아키텍처라고 볼 수 있다. 이러한 분산화된 구조에서는 조직 내의 다양한 소규모 조직이 스스로 앞일을 예측하고 조직간에 어떻게 협업하여 진행할 지를 스스로 결정 하여야만 한다. 소규모 조직들 스스로가 판단한 여러 환경 조건과 기회요소들을 이용하여 외부로부터의 승인과정이나 검토과정없이 바로 action에 들어갈 수 있는 조직. 이것이 EDA가 구상하는 아키텍처이다. 따라서 EDA에서는 분산화되어 있는 이벤트들을 갖고 새로운 action을 취함에 있어 중앙 집중화된 거버넌스 조직이 거의 없으며 스스로에게 이러한 권리를 부여하도록 구성되어 있다.

물론 이러한 분산화된 의사 결정구조에는 장단점이 존재한다. 분명코 변화에 보다 능동적으로 대처할 수 있는 장점이 있는 반면에 비즈니스와 IT의 seamless한 연결부분에 대한 제약이 있을 수 있으며 통제가 어렵다는 단점이 있을 수 있다. 그래서 EDA와 SOA는 한쌍으로 구성되어야 한다.

얼마전 성능 및 아키텍처 분석 컨설팅을 하러 국내 모 회사를 방문하여 고객대상 웹사이트 시스템을 살펴보게 되었다. 해당 시스템은 과거 Tuxedo와 직접적으로 혹은 EAI를 통해 연결되어 돌아가는 WAS기반 웹사이트였는데 이게 작년에 했던 '차세대 프로젝트'로 인해 중간에 ESB가 생기면서 성능상으로 다양한 문제가 발생하게 되었다. 기존에 EAI에서 하듯이 ESB를 사용해버려서 겪게된 경우인데, 아키텍트가 SOA기반에서는 보다 Coarse-grained한 설계에 심혈을 기울이지 않으면 SOA 프로젝트가 오히려 기업 IT환경에 걸림목이 될 수 있음을 보여주는 좋은 사례로 보여진다.
아래 그림은 지하철에서 퇴근하면서 타블렛pc로 잠깐 그려본 해당 시스템의 차세대 이전과 이후의 모습을 간략하게 끄적여본 것이다.

흔들리는 지하철에서 그린 그림이라 완전 초딩의 그림일기 수준이지만 이해하기는 어렵지 않을 것이다(-_-;;;;). 보통 CBD나 OOP를 통해 솔루션이나 소프트웨어를 개발하다보면 최대한 기술적이고 구현적인 부분에서의 재사용성을 높이기 위해서 기능을 쪼개고 쪼개어 Fine-Grained한 컴포넌트의 묶음으로 만들게 된다. 물론 그렇게 만들어진 컴포넌트들을 다시 비즈니스 로직을 담기 위해 Facade등을 이용하여 어느 정도의 상대적으로 Coarse-grained한 컴포넌트가 만들어지게 되겠지만 그것은 어디까지나 컴포넌트가 담겨있는 컨테이너 안에서의 시도이기 때문에 성격상 Fine-Grained한 특성을 가질 수 밖에 없고 그것이 잘못된 것은 절대 아니다.

차세대 이전의 모습을 보자. 홈페이지 시스템은 내부적으로는 잘 설계된 Framework기반 위에 구현되어 있었으며 몇몇 필요에 의해 그때 그때마다 EAI통해서 혹은 개별적으로 Legacy영역인 Tuxedo를 호출하였다. 그러다보니 Tuxedo와의 interaction에 큰 제약이나 자원 부족을 느낄 수 없었다. Tuxedo와의 이러한 강결합(Tightly coupled)이 차세대 이전에는 큰 문제시되지 않았던 반면에 차세대 이후에는 이것이 약결합(Loosely coupling) 요건과 함께 분리가 되었다.

문제는 차세대 이후에도 여전히 홈페이지 시스템은 Tuxedo를 강결합되어있는 Fine-grained형태로 사용하고 있다는 점이다. 아마도 아키텍트는 이 차세대 시스템을 설계할 때 Tuxedo부분은 bottom-up방식으로 서비스화했을 것이고 대부분의 기존에 사용하던 function들을 그대로 ESB에 올려놨을 확률이 높다. 왜냐하면 무언가 변경을 해서 어떤 side-effect가 발생할 지 모르기 때문이다. 하지만 적어도 홈페이지 시스템이 ESB를 통해 Tuxedo서비스를 호출하는 방식은 충분히 Coarse-grained한 방식으로 호출할 수 있도록 서비스화했어야 했다. 결과적으로 단 한번의 사용자 요청을 홈페이지는 그 하나의 트랜잭션 안에 기본 4개 이상의 ESB호출을 하게 만들었다. 당연히 이 홈페이지 시스템은 차세대 이전보다 느려질 수밖에 없고 결합도는 여전히 차세대 이전과 마찬가지로 Tightly coupled하다.

고객은 이러한 문제를 사후에 인식하고 서버 증설과 함께 몇몇 튜닝작업을 벌여야 했고 그것은 결국 SOA에 대한 부정적인 기억만 갖게 했을 뿐이다.

ESB를 과거 EAI처럼 쓰거나 혹은 서비스의 결합도(Coupling)와 Granularity에 대한 제대로된, 확고한 인식이 없이 아키텍처가 설계되었기 때문에 발생한 사례이다. SOA 아키텍처는 기존의 CBD와 사뭇 다른 엔터프라이 아키텍처 관점에서의 사고가 필요하다. 그 중에 중요한 개념이 바로 Coarse grained한 서비스 설계 혹은 과연 서비스는 어느 정도의 Granularity를 가져야만 하는가하는 고민이다. 그냥 무턱대고 ESB나 서비스 저장소, 혹은 웹서비스로 개발한다고 하여 SOA가 구축되는 게 아니다.

다음에는 그렇다면 서비스 Granularity란 무엇인지 디벼보겠다.

SOA 정말 느슨한 연결(약결합: Loosely Coupled)인가?
SOA가 특별히 어떤 기술적인 표준과 강한 결합을 강요하지는 않더라도 어찌되었건간에 SOA는 웹서비스와 상당한 관련을 맺고 있는게 사실이다. 사람들이 그렇게 믿고 있고 웹서비스가 SOA를 실현시켜줄 견인차처럼 생각하고 있다면 그걸 틀리다고 말할 수는 없는 법. 웹서비스는 기본적으로 Request and Reply 방식을 선호한다. 부분적으로 비동기적인 메시징도 지원하거나 앞으로 지원하려고 하지만 SOA가 가장 자신있어 하는 기술적인 메시징 방식은 아직까지는 동기적인 처리 방식이며 상호운영성 부분에 있어서도 아직은 비동기적인 부분은 이뤄내야할 부분이 너무나 산적해있다.
그렇다, SOA의 기술적인 구현 부분은 결국 동기적인 방식이 주를 이룬다. 하지만 제 아무리 약결합을 극대화한다고 해도 Request and Reply 방식에서는 강결합이 해소되기 어려운 부분이 존재한다. Consumer는 물리적인 Provider의 위치와 그것을 호출하는 프로토콜을 몰라도 된다. 이것만으로는 완전한 약결합이라 할 수는 없다. Consumer는 어쨌든 어떤 Provider를 이미 예상하고 그 인터페이스도 알고 있어야하기에 Consumer의 메시지는 어느 정도 물리적인 Provider와 연결되어 있다고 볼 수있다.

반면에 EDA의 이벤트는 Provider와 Consumer가 완전히 분리되어 있다. Provider는 Provider가 전달하는 이벤트가 어떤 용도로 쓸일지 전혀 관심이 없고 Consumer역시 어떤 Provider에서 그 이벤트가 왔는지에 관심이 없다. 이벤트 자체에는 어떤 목적성이 있을 수가 없는 것이다.

그래서 사실 SOA가 목표로 하는 최상의 약결합은 오히려 EDA와의 동거를 통해 이루어질 가능성이 있다.

EDA와 SOA의 결합
물론 요새 오라클이 SOA세계에 새로운 강자로 떠오르기 위해 기존 SOA판에서 놀기보다 새판짜려는 마음으로 SOA 2.0이라고 하면서 SOA와 EDA의 결합 모델을 통해 SOA의 더더욱 진화된 유연성을 강조하고는 있지만, EDA는 SOA랑은 원래는 그다지 상관이 없는 독자적인 아키텍처라고 볼 수 있다. 어찌되었건 그 이름이 SOA 2.0이건, SOA와 EDA이건 EDA는 SOA의 탄탄한 기술구조와 거버넌스 및 방법론등을 필요로 하고 SOA는 EDA의 유연함을 필요로 한다. 둘은 서로가 원하고 있다. 아래 그림은 이러한 SOA와 EDA간의 결합 구조이다.
SOA는 프로세스 기반의 여러 비즈니스 인프라를 묶어내는 데에 사용되고 이러한 SOA기반의 비즈니스 서비스 덩어리들 간에 유연한 결합을 위해 EDA가 쓰일 수 있을 것이다.
만약 SOA 부분의 프로세스들을 감싸고 있는 덩어리를 ESB라고 가정한다면 ESB와 ESB들간의 직접적인 연결에 의한 상호 통신도 물론 존재할테지만 이 역시 강결합의 요소가 담겨있을 수 있다.
어찌되었건간에 EDA는 이 SOA로 이루어진 서비스 덩어리들의 이벤트 중계뿐만 아니라 기업내에 존재하는 다양한 Legacy와의 극대화된 약결합, 유연성을 제공할 것이 분명하다.

SOA가 잘할 수 있는 경우

• 비즈니스 트랜잭션 내에 여러 복잡하고 다양한 계층의 프로세스와 서비스와 컴포넌트의 조합이 필요한 경우
• Request and Reply 방식의 트랜잭션
• 무결성이나 트랜잭션등이 중요한 프로세스

EDA가 잘할 수 있는 경우

• 너무나 이질적이고 대량의 이벤트 소스로부터의 유연한 처리가 필요할 경우
• 전혀 다른 비즈니스 트랜잭션들간의 통신.
• 워크플로우 스타일의 프로세스

회사에서 갑자기 올해부터 CEP (Complex Event Processing) 분야를 맡게되었다. 요새 EDA(Event Driven Architecture)라는 용어가 스물스물 귓전을 때리더니 결국은 그 EDA에서의 핵심이라 할 수 있는 CEP분야의 나름대로 힘을 가지고 있던 AptSoft라는 회사를 회사가 인수를 하였고 그래서 어찌되었건간에 이 CEP를 맡게 되었다.

CEP, 이거 왠 '듣보잡'인가라고 하실 분이 계실지도 모르겠지만 나름대로 역사와 전통을 자랑하는 개념이어서 1990년대 중반부터 학계에서 떴다고 전해진다. SOA처럼 벤더사들이 처음 시작한거가 아니라서 좀 더 편안하고 순수한 마음으로 CEP를 바라보셔도 좋겠다. 일단 CEP의 개념은 상당히 간단하다. 기업 내부에 돌아다니는 이벤트를 filter같은 걸 이용해서 수집하고 이걸 실시간으로 분석하여 적절한 action을 취할 수 있게 하는 인프라다. 이런 수집과 이벤트에 따르는 행위를 자동으로 컴퓨터가 해주는 걸 의미한다.

사실 갑자기 나온 개념도 아닌 것 같고, 이미 왠만한 기업들도 비즈니스룰과 같은 개념으로 조금씩 국지적으로 사용하고 있을 것이다. 과거에 비해, 5년 전과 비교해보더라도 우리나라 은행등에서 외환관련 부서에서 처리하는 트레이딩의 량은 거의 열배는 늘었을 것이다. 그렇다면 열배 가까운 인력이 해당 부서에 더 보충이 되었을까? 오히려 줄었으면 줄었지 그다지 인력 보충은 있지 않았다. 그러면 어떻게 이것을 처리할 수있을까? 그것은 과거와 다르게 다양한 이벤트 처리 엔진등을 사용했기에 가능한 것이다. 그저 사람은 최종적으로 클릭질만 몇번 하면 되는 것이다. 이렇게 그전에는 의사결정을 내리기 위해 해야했던 많은 작업을 대신 처리하고 수많은 정보들을 걸러줘서 보다 많은 정보를 처리할 수 있게 하는 전사적인 이벤트 처리 시스템이 CEP의 개념이다.

CEP, 개념은 쉽지만 하지만 그게 쉽지가 않다. 이게 전사적인 관점으로 확장되면 이벤트를 받는 방법과 또 대량의 이벤트들을 받고 저장하고 걸러내는 작업, 그리고 최종적으로 다시 새로운 action으로 연결시키는 작업들이 상당히 많은 부분 표준적인 부분이나 성능적인 부분과 맞물려있게 된다. 그래서 이러한 표준과 성능관점에서 SOA와 그리드 기법들이 CEP에 도입되기 시작하고 그래서, CEP가 최근에 다시 각광을 받고있는 이유다. SOA가 뜨니까 드디어 조금씩 CEP가 제 물을 만난 것이라고 봐야한다.

ESB란 무엇인가? 쉽게 말하면 서비스의 중계자 혹은 허브라고 볼 수 있겠다. 기업 내의 모든 서비스를 원하는 요청자의 메시지는 이 ESB를 거쳐가게 하겠단 것이다. 그렇게 해서 보다 유연하게 서비스를 관리하겠다는 것이다. 이렇게 인터페이스만 있는 서비스가 ESB에서 한눈에 보이다보니 BPM도 이 ESB랑 연동하면 보다 쉽게 전사적인 BPM하겠다싶다. 그러니까 BPM도 SOA랑 엮이면 보다 유연하고 통합적인 관점에서 잘 할 수 있게 되고, 이렇게 BPM이랑 서비스랑 잘 엮이고 실시간으로 프로세스가 진행되니 메시지나 여러 자원들도 보다 통합적으로 볼 수 있을 것 같으니까 BAM도 스물스물 시장에서 언급이 되기 시작한다.
그런데 프로세스 관점에서만 봐서는 정말 유연한 IT환경을 가져가기가 어렵다는 게 문제다. 프로세스 모델링 아무리 잘해도 시시각각으로 변하는 비즈니스 상황을 제대로 반영하기란 그리 쉬운 노릇이 아니다. 실시간적으로 비즈니스 Insight를 요구하는 상황에서 '무슨무슨 프로세스를 이렇게 변경해서 이런 요구사항을 반영시켜주세여'라고 요청해도 그게 바꾸기가 어디 쉬운가? 핵심적인 비즈니스 프로세스는 그대로 유지하되 실시간적으로 요구되는 변화를 반영하기 위해서는 프로세스가 아니라 실시간이란 의미를 가장 잘 반영하고 있는 '이벤트'에 초점을 맞출 필요가 있으시다.

메시지라는 용어와 다르게 '이벤트'라는 용어에는 어떤 '목적성'이 없다. 메시지는 뭔가 대상이 있고 어떤 행위를 요구하는 의미가 이미 담겨있다. 그런데 이벤트는 그저 '상황 변화'만을 가지고 있는 것이지 이런 변화에 대해 어떻게 행동하란 내용은 전혀 없다. 경찰차의 사이렌이 울렸다. 죄없는 사람들은 그냥 평소 하던 일을 하면 될 것이고, 도둑님은 '짭새떴다'고 열심히 도망가시면 되는 것이다. 이벤트 자체에는 행위를 알려주지 않지만 그 이벤트를 원하는 사람의 입장에서 그 이벤트에 맞게 반응하면 되는 것. 그게 EDA다. EDA (Event Driven Architecture)는 기업 내의 IT환경의 최소 단위를 이 이벤트로 보는 아키텍처다.

생각해보면 정말 모든 건 이벤트였다. 그게 웹서비스였건 자바에서 돌아가는 프로그램이건 DB에 저장되는 SQL 쿼리이건, Telnet 접속이건간에 사실 모든건 프로토콜과 포맷만 다른거지 결국 이벤트다. 물론 이것들은 모두 그들 나름의 생겨먹은 이유가 있고 그들의 목적에 따라 원래의 목적지로 가서 일을 처리해야만 한다. 하지만 EDA에서는 이런 이벤트들을 따로 필터링해서 또 다른 비즈니스 의미를 가진 어떤 action을 처리할 수 있게 한다.

그래서 ESB는 서비스의 허브라고 한다면 CEP는 이벤트의 허브다. CEP에서는 기업내에 산재되어 있는 이벤트 덩어리들을 이벤트 구름(Event Cloud)이라고 부르는데, CEP가 하는 역할은 이 이벤트 구름에서 자신이 필요로 하는 의미있는 이벤트만을 걸러내어 예약된 이벤트를 처리하는 것 이다.



과연 이 CEP가 뜰것인가, 정말 필요한 물건이 될 것인가 하는 점은 확실치 않다. 하지만 분명 그 필요성은 항상 있어왔다. 보다 Real time이 강조되는 증권이나 금융 분야(알고리즘 트레이딩)가 그 예이다. 그 외에도 온라인 서비스를 하는 업체같은 즉각적인 고객대응이 매우 중요한 분야에서는 이 CEP가 귀중한 솔루션이 될 가능성이 높다.

CEP가 구축되면 필요한 비즈니스 룰이나 이벤트 처리 구축 요건을 개발하는데 2-3주면 된다. 상당히 개발 기간이 기존에 비해 단축되는 효과를 볼 수가 있다. 기존 시스템을 건드리는 게 아니라 그저 이벤트를 수집해서 원하는 행위를 수행하는 것이기 때문이다. 하지만 이러한 효과를 극대화하려면 결국 기존의 IT환경이 어느 정도 표준화되어 있거나 서비스화된 자원들이 많아야한다. 그렇지 않으면 CEP구축에 수많은 노가다를 감수해야 할 것이다.

20세기 최고 발명품 냉장고.
오래동안 보관할 수 있는, 한 때 리버풀을 사랑했던, 전생에 훌리건이었던, 열을 식히는 지혜를 배우기 위해 환생한, 세상 모든 것을 심지어 코끼리까지도 집어넣을 수 있는 냉장고라는 사내에 나는 박민규의 '카스테라'와 김언수의 '캐비닛'을 잠깐 보관해본다. 마르께스의 책이 있으면 딱이었을텐데 아쉽다.

당신은 ESB가 뭐라고 생각하시나요?
이름만 바꾼 EAI hub? 오옷. 딱이야. 이거 말고 ESB를 정의할 수 있는 것은 별로 없어 라고 생각하시는 분들이 대부분이 아닐까요?
근데 실제로도 ESB를 EAI hub처럼 쓰려는 분들이 많죠.
EAI 왜 쓰죠? 기존에 legacy들의 잡다한 프로토콜과 포맷과 산재되어 있는 자원 및 프로세스, 업무를 통합하기 위해 쓰잖습니까? 그런데 그렇게 구축한 EAI가 결국은 또 다른 legacy가 되어버리는 경험을 여러 갑 및 갑을 지원하는 을병정님들은 충분히 하셨을 거라 생각해욥. 뭐, 뭔가 어처구니없다고는 생각해도 어쨌든 이런것들을 현실적인 이유 때문이라도 통합은 해야겠고, 이를테면 3년이나 5년 주기로 이런 통합 이슈는 있다보니 주기적으로 EAI 비스무레한 것들을 진행하기도 합니다만, 이렇게 EAI가 자주 있는 것은 결국 EAI 프로젝트로 만들어진 게 또 다른 legacy가 되었다는 거죠. EAI의 진짜 목적은 이제는 제발 이런 통합 문제로 그만 골치썩고 그보다 높은 레벨의 것들을 걱정해보자인데, 여전히 현재 당면한 통합 문제 해결하기에 급급하죠. 이러니 IT가 아니라 DT(Data & Technology)다 라는 이야기가 나오는 겁니다.
그런데 ESB를 쓴다고 달라지나요? ESB를 EAI처럼 쓴다면 똑같죠. 제 아무리 대단한 ESB라도 기존의 EAI관점에서만 접근해버리면 이를테면,
'어~ 소켓기반으로 legacy가 되어있구만 ESB가 소켓 지원해야지'
'원래부터 hex binary 방식으로 되어있던건데 이거 포맷 그대로 유지해야 않겠어?'
아 예 여전히 데이타 중심적인 기업 데이터 통합 방식으로 문제 해결을 해버리고 있습니다. 좋습니다. 사실 속도 문제와 안정성 문제 이거 EAI에서 중요합니다. 증권쪽이나 은행의 일부 업무같은 경우야 뭐 어쩔 수 없다지만 이제는 표준기반으로 갑시다. 표준기반이란게 속도나 보안 문제에서 생각할 게 많다는 것은 알지만, 제 아무리 프로세스 통합이니, 비즈니스 프로세스 기반 기업 환경, RTE 외쳐보았자 IT가 여전히 데이타 통합만 신경쓰고 있다면 말짱 도루묵 아닐까요?
ESB가 그나마 기존의 EAI와 다를 수 있는 건 이러한 표준들을 제대로 지원할 수 있다는 데 있지 않을까 싶습니다. 아니 '그나마'라뇨, 사실 이 표준기반이라는 거 큰 차이죠. 표준기반이 구축되어야 비즈니스 프로세스 기반의 기업 IT환경, RTE 구축할 수 있습니다. 백날 RTE, EDA, SOA 떠들어 보았자 헛수고에요.
물론 성능이나 보안 문제 많습니다. 많고요, 성능이나 보안 문제 해결할 방법 제법 있습니다. 굳이 빵빵한 하드웨어 도입해야만 해결가능한 건 아니에요. 꼭 필요한 부분만 보안 해주고 정 안되는 거 legacy가 원하는 대로 해주고 그런 아키텍처 만들어주고 그래도 정 안되면 성능 가속기 얼마든지 있거든요.
2007년에 가트너라는 구라집단에선 2009년에는 대기업들의 대부분이 ESB를 도입할거라 합디다. 더구나 이렇게 구축한 ESB를 묶어가지고 federated ESB를 구축할 거라 예상하는군요. 가트너가 틀린 예측 어디 한 둘입니까? 하지만 이거는 어느 정도 믿어봅시다.
사실 제대로 된 비즈니스 프로세스라던가 EDA나 서비스 기반의 아키텍처라든가 어쨌든 간에 최소한의 비즈니스 의미를 지닌 서비스, 비즈니스 서비스가 존재할만한 공간은 ESB 밖에 없어요. 앗, 갑자기 어려운 용어들을 써버렸구만요. 하여튼간에 ESB가 비즈니스와 IT를 엮게 되는 시발점이 되리라는 것은 분명합니다.
집에서 만든 막걸리를 혼자 마시고 취해 끄적여 보았습니다.

전주를 가면 평소 맛보지 못한 진미를 값싸게 맛볼 수 있게 된다.

비빔밥만이 전주에 유명한 음식이 아니다. 그하고 많은 맛난 음식중에서도 평소에 맛보기 힘든 것 중에 애주가들의 눈길을 끄는 것이라면 단연 모주가 아닐까싶다. 모주는 술을만들고 남은 술찌깨미를 계피랑 대추등등을 넣고 팔팔 끓여 알콜은 날려보내고 술 냄새만 남겨 마시는 뜨뜻한 국물이다. 서울에서도한두군데는 이 모주를 맛볼 수 있다고 하는 그 귀한 것을 나는 오늘 처음 손수 해먹어본다.

계피와 대추, 물과 술찌깨미의 적절한 조합을 찾지 못해 조금 밍숭맹숭해지긴 했지만서도 그런대로 전주 콩나물국밥집에 온 듯한 느낌이 든다. 지화자.