calmglow (최진호)

지금 막 따끈따끈하게 나온 IBM Redbooks, CaseStudy Web 2.0 SOA 시나리오는 가상의 여행사를 대상으로 Web 2.0기반의 보다 빠르고 유연한 웹 서비스 환경을 구축하는 방안을 설명하고 있다.
아래의 그림은 해당 여행사의 현재의 아키텍처를 보여준다.
신규 서비스 추가나 비즈니스 Policy변경 혹은 다양한 채널에대한 유연한 대응을 하는데 어려움이 있는 구조이며 덩치큰 애플리케이션 덩어리로 나누어져 있어서 빠른 대응이 힘든 구조라고 책에서는 이야기하고 있다. 사실 이대로만 사용한다면 IT운영 입장에서는 그 한계를 못느낄 수도 있을 것 같다. 현재의 대부분의 사이트의 모습도 이 아키텍처와 크게 다르지 않을 것이다.
책에서는 아래와 같은 아키텍처를 제안한다.
책에서는 비즈니스 로직과 Policy가 완벽히 분리되어 있어서 빠르고 간단하게 변화에 대응이 가능한 구조라고 이야기하고 있다. 더욱이 3rd 제품 추가가 용이하며 신규 서비스나 채널에 대응도 매우 유용하다 이야기하고 있다. 그림에서 언급된 sMash는 기존 WAS가 아닌 보다 빠르게 웹 2.0 자원들을 활용할 수 있는 경량화된 미들웨어이다. 또한 본 아키텍처에서는 ESB가 매우 강력하게 제안되어 있다. Service Integration Domain 영역이 그것인데, DataPower라는 ESB Appliance와 WPS라고 하는 BPM enabled한 ESB가 동시에 제안되어 있다. 실제로 사용자 혹은 채널과 연계를 담당하게 되는 인터넷 서비스 도메인(Internet Service Domain) 영역은 웹서버 혹은 다시 sMash와 같은 웹 2.0기반 미들웨어가 차지하고 있다.
비용적인 측면에서는 Service Integration Domain만 저렴한 ESB제품으로 교체하면 기존의 아키텍처에 비해 훨씬 더 저렴하게 시스템을 구축할 수 있을 뿐더러 DataCenter나 클라우드에 이전하여 운영하는 것도 그다지 어려운 일이 아니다.
다만 본 사례는 여행사라고 하는, 그다지 Legacy의 영역보다는 채널 연계가 핵심인 비즈니스에 어울릴 수 있는 사례라는 점이다. 궁금한 점은 과연 여행사 비즈니스가 내부망 연계에 sMash와 같은 경량화된 미들웨어를 써도 될만큼 복잡하지 않은 특성을 가지고 있는지 여부이다. 오늘 여행사 서비스를 계획하고 있는 업체를 방문하게 된다. 현실과 이상의 차이를 발견해보길 기대한다.

조영남이나 유승준 등등이 생각이 난다.
국가보안법이 엄연히 존재하는 직선의 대한민국에서
대체 뭘 기대한 거냐?

올 하반기는 나에게 있어서 CEP(Complex Event Processing), BEP (Business Event Processing) 솔루션이 업무 화두다. 이 따끈따끈한 주제로 많은 사람들과 이야기를 나누면서 자주 듣는 질문에 대해 다음과 같은 답변을 준비해보았다.

1. 우리 회사는 이미 BRMS를 일부 사용하고 있습니다. CEP(Complex Event Processing)나 BEP(Business Event Processing) 솔루션은 BRMS와 유사해보입니다. 그 둘의 차이는 무엇인가요? BRMS의 확장인가요?
룰에 의해서 특정 조건을 찾아내는 엔진의 차원에서는 BRMS나 BEP, CEP가 크게 다르지 않습니다. 하지만 대부분의 경우 BRMS가 BEP나 CEP보다는 다양한 룰을 작성하는 데 있어서 더 풍부한 옵션을 제공하고 있습니다. BEP, CEP는 대신에 보다 쉽게 룰을 정의할 수 있는 환경을 제공하고 BRMS가 동기적인 처리 방식인데 반하여 CEP, BEP는 비동기적인 특성을 갖고 있어 외부 시스템과 연계에 유연성을 발휘하고 연계가 쉽다는 장점이 있습니다. 또한 BRMS가 특정 시스템의 아키텍처등을 모델링하여 그것들을 이용하여 룰을 정의하는 반면, CEP, BEP는 복잡한 모델링보다는 보다 단순하게 이벤트기반으로 모델을 정의하여 시스템간 연계에 유연함을 강조하고 있습니다.
때문에 BRMS는 입출력이 비교적 확실하고 아키텍처가 명확한 솔루션 안에 포함되어 솔루션을 보다 유연하고 체계적으로 사용하는데 도움을 줄 수 있으며 CEP, BEP는 다양한 솔루션들간의 유연한 연계가 필요한 상황에서 강점이 있습니다. 즉 CRM시스템을 구축한다면 CRM 시스템 내에 필요한 룰엔진은 BRMS가 유리하겠으나 향후 이 CRM시스템과 콜센터나 영업망시스템, 홈페이지등이 지속적으로 연계되어 추가적인 이벤트 처리가 필요한 경우는 CEP나 BEP가 유리하다고 보겠습니다.

2. CEP나 BEP를 이용하여 고객 성향 분석이나 비즈니스 모니터링이 가능하다면 DW와 같은 BI솔루션과는 어떠한 차이가 있는 건가요?
CEP나 BEP는 분석 자체를 하지는 않습니다. BI솔루션들이 실시간보다는 정적이고 Histrorical 데이타 중심의 처리가 중심이라면 CEP, BEP는 실시간 빠른 응답이 필요한 상황에 유리합니다. BI솔루션을 통해 얻은 의미있는 Factor와 패턴 및 트렌드를 바탕으로 CEP, BEP에 적용시 비즈니스 응답 속도를 높일 수 있을 것입니다.

3. 이벤트를 받는 구조라고 한다면 결국 기존 시스템에 부하를 많이 줄 것 같습니다.
다양한 이벤트 수신,발신 기능을 제공합니다. DB polling, DB trigger, 웹서비스, 파일 시스템, FTP, SMTP, HTTP, JMS와 같은 다양한 프로토콜등을 제공하므로 기존 시스템에 영향을 최소한으로 미칠 수 있는 방식을 채택하는 것이 가능합니다. 또한 비동기 방식이므로 동기적인 방식에 비해 부하를 최소화할 수 있습니다.

4. CEP의 개념은 과거에 발생했던 이벤트들도 지금 판단의 근거로 삼을 수 있는 시스템을 필요로 합니다. 그렇다면 과거 이벤트 이력을 전부 보관하고 있다는 것인데 그 많은 이벤트들을 갖고있으려면 저장공간이나 성능이 뒷받침되어야할 것 같습니다만?
맞습니다. 이를테면 한달치 이벤트들을 모두 갖고있는다고 해도 그 크기는 무시할 수 없겠죠. 그것을 모두 DB나 물리적인 공간에 보관하기만 한다면 또 성능에 문제가 있을 수 있겠죠. 때문에 기존의 방법만으로는 힘이 듭니다. 그리드 기반의 기술이 적용되어 있다면 이러한 한계를 충분히 극복할 수 있습니다. 현재 그것을 제가 내부적으로 테스트해보고 있으며 적용 사례에 대해서도 추후 언급할 예정입니다.

요새 틈틈히 프로젝트 제로(Zero)로 간단한 코딩을 하고 있습니다. 제로 프로젝트는 경량의 미들웨어이자 웹기반 개발환경입니다. 개발 언어는 PHP, 그루비, Java를 지원하고 런타임이 약 40M밖에 되지 않는데다가 Request가 있을 경우에만 그 런타임이 동작하고 request가 없으면 런타임은 사라지고 약 100k 정도의 메모리를 차지하는 리스너만 동작하여 더이상 작아질래야 작아질 수 없을만큼 경량화되면서도 웹애플리케이션을 개발하기 위한 대부분의 것들을 모두 포함하는 미들웨어입니다.
게다가 가장 많이 쓰이는 PHP와 자바 그리고 그루비같은 스크립트 언어등을 지원하다보니 개발하는 것도 쉽고 재밌기까지 합니다.
이렇게 제로 프로젝트로 놀다보니 떠오르는 생각은,
어째서 미들웨어는 그토록 무거워지고 복잡해져버렸을까? 무슨 업보라도 지고 있듯 언젠가는 필요하리라 생각하는 그 모든 것들을 짊어지고 있는 근래의 자바 미들웨어들을 보고 있으면 곧 무너질 바벨탑처럼, 혹은 스타워즈의 제국군이나 데스스타처럼 위태위태해보입니다.
혹자는 말합니다. 우리가 비즈니스적으로 개발하려던 핵심 말고는 다른 모든 것을 알아서 해주기 위해 그런 라이브러리나 프레임워크가 필요하고 어차피 컨테이너가 알아서 해주니 개발과는 상관없지 않느냐고, 모든 것을 서비스로 만들어주면 어차피 밑의 부분은 신경 안쓰고 살 수 있다는 이상적인 이야기들.

수없이 많은 레이어들 그 위에 만들어진 애플리케이션, 과연 우리의 애플리케이션중 얼마나 많은 것들이 그 수많은 레이어에 부끄럽지 않을 정도의 고급 기능을 사용하고 있을까요?

프로젝트 제로를 접하면서, 기존의 미들웨어들의 큰 덩치에 의문을 품은 아침이었습니다.

당신은 엔지니어인가요 아니면 과학자인가요? 같은 기술이나 이론을 놓고 과학자와 공학자 혹은 엔지니어의 차이는 무엇일까요? 저는 그 개념의 끝을 파헤쳐서 그 차이를 분석하려고 이 글을 쓴 것은 아닙니다.
하지만 이 글을 읽고 있는 엔지니어인 당신 혹은 저는 가끔 엔지니어로서의 자세와 과학자로서의 자세를 혼동할 때가 있습니다. 저는 엔지니어를 시장에 내놓을 기술을 연마하고 익숙한 사람이라 생각합니다. 과학자는 어떤 이론이나 기술에 세상 사람들이 관심이 없다할지라도 그것의 근본을 파헤치는 데 열중한다면 엔지니어는 그 이론이나 기술을 응용하여 세상을 이롭게 하고 그것을 통해 적절한 보상을 받습니다.

전기라는 현상을 놓고 그것의 현상과 원인을 파헤친 페러데이와 그것의 원인은 모르지만 전기를 이용하여 전구나 전화기를 개발한 에디슨이 바로 과학자와 엔지니어의 차이를 극명하게 보여줍니다.

조금 의도적으로 정의하자면 엔지니어에게는 시장이 있고 과학자에게는 학교가 있다고할까요?
아무튼 엔지니어에게 있어서 시장은 없어서는 안될 중요한 동기부여의 장소라고 생각합니다.

그렇다면 엔지니어로서의 우리는 어떠한 발전 과정을 거치게 될까요?
저는 다음과 같은 과정이 엔지니어의 과정이 아닐까 생각합니다.

첫번째, 남이 주어진 요구사항을 구현하는 단계입니다. 이 단계에서는 그저 요구사항을 그대로 구현하기에도 벅찬 단계입니다. 기초 이론을 배우고 끊임없는 밤샘과 실수와 좌절을 거쳐 점점 숙련의 단계에 접어들게 되는 기간입니다. 좋은 사수를 만나면 좀 더 일찍 이 과정을 마스터할테지만 어찌되었건 몸이 고생하는 것을 피할 수는 없습니다.

두번째, 구현물을 개선하고 성능을 높이는 단계입니다. 이제는 남이 하라는 대로 따라하지 않고 보다 더 나은 자신만의 기술로 구현하기 위해 노력하는 단계입니다. 이를 위해 새로운 기술을 탐구하고 적용하며 손기술만이 아닌 뭔가 추상적이고 체계적인 시스템에 관심을 갖습니다. 조금씩 자신이 타인보다 우월하다고 생각하게 되는 단계입니다.

세번째, 시장에 없던 새로운 아이디어가 떠오르는 시기입니다. 이제는 기존의 것들에서 더이상 만족하지 못하고 타인이 만들어놓은 방향이 아닌 자신의 방향으로 시장을 생각할 수 있는 시기입니다. 자신의 생각으로는 대박일 것만 같은 시장에서 써먹힐만한 아이템과 아이디어가 자꾸 떠오르고 그것을 구현해보거나 설계를 해보는 시기입니다. 완전히 새로운 자신만의 방법론과 구현물에 대한 욕망이 최고조로 다다르는 시기입니다.

네번째, 돈을 버는 시기입니다. 이전 단계에서 쌓여진 경험과 시도한 아이디어등을 통해 돈을 적극적으로 버는 시기입니다. 꼭 사업을 한다는 의미는 아닙니다. 일개 엔지니어가 아닌 자신만의 브랜드가 회사이든 개인이든간에 생겨나고 그것을 통해 돈을 버는 시기라고 할 수 있습니다.

다섯번째, 즐기는 시기입니다. 엔지니어링 안에서 혹은 그 밖에서...:)

당신은 어느 단계에 있으신가요? 저는... 글쎄요 ... :)

4월부터 블로그가 휴업상태였습니다. 이미 이전 포스팅에서도 거듭되는 회사 업무로 블로깅을 잠시 쉰다고는 하였으나 이쯤되면 쉬는게 아니라 아예 문 닫은 것 아닌가 하는 의심이 들 것도 같습니다.

아무튼 그동안 좀 바빴습니다. 4월부터 WAS BMT에 EAI BMT에 ESB BMT에 EAI성 ESB BMT에 CEP BMT... 총 5건의 BMT 및 PoC를 했습니다.
BMT나 PoC를 모르는 IT 관계자분들도 많으실 것 같습니다. 대기업이나 관공서등은 IT프로젝트에 앞서 업체 및 솔루션과 장비 선정을 가격만 가지고 입찰하는 게 아니라 여러 제공 기능이나 유지보수 능력등을 비교평가해서 그 결과를 놓고 선정을 하게 되죠. 특히 하드웨어나 소프트웨어의 경우는 이러한 여러 업체를 놓고 그 기능을 평가하는 소위 작은 프로젝트를 1주일에서 한달가량 수행하게 되는데 그것을 BMT(BenchMark Test) 혹은 PoC(Proof of Concept)라고 부릅니다. 보통 성능을 평가하거나 경쟁인 경우 BMT라 부르고 기능만을 평가하는 경우를 PoC라고들 부르지요. (참고로 외국에서는 BMT라는 용어가 없으며 PoC 혹은 비용을 지불하고 수행하는 파일럿 프로젝트가 존재합니다.)

그런데 이 짧은 1주일에서 한달은 제품을 판매하려는 영업 입장에서는 상당히 중요한 기간입니다. 기술영업이나 기술자들은 최대한 자기들 제품이 타 제품보다 월등히 상대적으로 좋은 결과가 나오기 위해 노력하고 영업들도 어떻게든 고객을 자기네 편으로 끌어들이려 애를 씁니다. 고객은 고객 나름대로 이 기간동안 제품 가격을 어떻게든 더 낮추려고 업체들과 눈에 보이지 않는 줄다리기를 하며 고객의 IT운영팀이나 프로젝트팀은 프로젝트가 시작하기 전에 크리티컬한 경우의 것들을 이 기간에 모두 테스트해보려 시나리오를 최대한 현실에 맞게 구성합니다. 즉 이 BMT, PoC 기간은 모두에게 그야말로 크리티컬한 기간인 것이죠.

그 동안 제가 수행했던 4-50여 차례의 BMT, PoC 기간에 있었던 웃지못할 다양한 에피소드를 이 블로그에 이야기로 풀어내자면 한도 끝도 없을테지만 비밀을 지켜야만 하는 내용들이나 치부같은 것들이 적잖기 때문에 누군가의 피를 불러오는 경우가 많아 너무나 조심스럽죠.
역사로 따지자면 정사(正史)는 그저 BMT,PoC 에서 어느 업체가 어느 가격에 어떤 조건으로 선정되었다. 정도의 짧은 한줄이지만 야사(野史)는 책 한권이 나올만한 게 BMT, PoC라고 할까요?
돈벌어 먹기 참 쉽지 않구나라는 것을 여러 사람들의 이해관계에 의해 복잡하게 얽힌 BMT,PoC를 경험하면 느낄 수 있는 것 같습니다.

어쨌든 이러한 BMT나 PoC를 참여하는 기술자나 기술영업인의 관점에서 보자면 비록 몸과 마음은 고된 기간이지만 하나의 기나긴 프로젝트 기간에서 경험할 수 있는 기술적인 핵심 요소와 고객 인프라나 아키텍처를 짧은 기간에 압축시켜서 경험해볼 수 있다는 나름의 매력과 장점이 있기도 합니다.

아무튼 이러한 BMT와 PoC를 여러번 해내고 나니 몸과 마음이 지쳐서 그간 블로깅에 게을렀다고 한다면 이해가 되실 것도 같습니다. 뭐 사실 블로그라는 게 누가 숙제주거나 돈받고 하는 성질의 것이 아니니 몇년을 쉰다한들 무슨 문제이겠습니까. 이정도 쉼이었으면 얼마 있지도 않았겠지만 있던 구독자 분들도 다 떨어져 나가셨을 거고 새로 시작한다는 마음으로 블로그를 다시 활성화해봅니다.

하루 죙일 인터넷으로 온갖 업무와 여가를 즐기기 위해 여기 저기 돌아다니는 나에게 웹브라우저의 선택이란 자가용으로 아반떼를 살건지 그랜저를 살건지 선택하는 문제보다도 사실 비용만 들지 않는다 뿐이지 삶에 있어서 더 중요하고 실질적인 문제.
내가 모든 IT기기를 선택하는 데 있어 가장 중요하게 생각하는 선택 포인트는 뽀대도 아니요, 기능도 아니요, 성능도 아니다. 다름아닌 플랫폼의 공개여부와 확장성. 천생이 엔지니어인 나는 어쨌든간에 내 입맛대로 수정해서 최적화하지 않으면 모든 게 내 세상같지 않고 불편하다. 제 아무리 세상 모든 좋은 기능 죄다 박아넣었다 한들, 제 아무리 세상에서 가장 섹시한 디자인으로 떡칠을 한들, 나는 나만의 요구사항과 개성이 있다. 내가 원하는 대로 장식하고 기능을 추가하기 어렵다면 그것은 남의 떡일뿐.
그래서 나는 불여우, FireFox다. 회사 인사시스템 검색을 쉽게 해주는 확장기능을 만들어 넣고, 내 맘대로 자바스크립트 만들어서 자주 가는 사이트의 모양새도 적절히 바꾼다. 수많은 공개 확장기능은 너무 유명한 게 많아서 얘기하기도 입이 아프다.

그런데 이번에 3.5로 버전이 올라가면서 성능까지 너무나 좋아졌다(자바스크립트엔진 성능비교표). IE는 이미 아웃오브안중이고 구글 크롬처럼 메모리 잡아먹는 괴물만큼이나 성능이 좋아졌으니 불여우에 날개를 달게된 격.