calmglow (최진호)

회사에서 갑자기 올해부터 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구축에 수많은 노가다를 감수해야 할 것이다.