calmglow (최진호)

아침 출근 길, 지하철에 타자마자 손에 든 꾸러미들을 선반 위에 쓰러지지 않게 올려놓습니다. 오늘의 출근 길에는 손에 든 것이 많습니다. 일단 간만에 딱 들어맞은 일기예보의 빗소식 덕에 챙겨든 우산이 있고 언제나 함께하는 너덜너덜해진, 5년째 쓰고 있는 노트북 가방이 있습니다. 그 옆에는 바로 바로 점심에 챙겨먹을 도시락입니다.
오랜만에 아침 일찍 일어나는 부지런함 덕에 오늘은 특별히 마음먹고 점심에 먹으려고 도시락을 싸봤습니다. 반찬이라고 해봐야 김치와 김에 특별 반찬으로 북어찜(어머님이 특별히 마련해주신)이 전부이지만 좀 더 여유있게 아침에 일어나 도시락을 준비하는 과정에는 꽤 놀라운 즐거움이 있음을 알게 되었습니다.
또 어제는 잠자리에 들기 전에 다리미질을 해봅니다. 늘상 하는 다리미질이건만 이번에는 무릎을 꿇고 다리미질에 도전해봅니다. 뭔가 경건해지기도 하고 자세 교정에도 좋고 그리고 왠지 모르게 잡생각이 줄어드는 것 같아 조금 쥐가 날 것 같음에도 불구하고 참았습니다. 다리미질 그것에 집중하다보니 요새처럼 생각이 많고 많은 때에는 그러한 작은 일상의 일들에 집중하는 것이 의외로 효과적이라는 것을 배우게 되네요.

소니의 컴퓨터 사이언스 연구소에 근무하는 모기 겐이치로가 쓴 '뇌와 창조성' 중에서 다음과 같은 글귀가 있다고 합니다.(읽어보지는 못했어요)

살아가는 데는 중요한 것과 그렇지 않은 것이 있다. 그 가운데 중요한 것만 잡고 넘어가면 된다고 생각하는 것은 스스로의 사고를 인공 유리병 안에 가두는 것이다. 실제로 인간의 뇌는 일상에서 일어나는 자질구레한 사건의 영향을 받으면서 조금씩 계속 변화한다. 중요한 일회성의 사건은 일상으로부터 단절되어 연락도 없이 드러나는 것처럼 보이지만 실제로는 배후에 일상의 연속적인 역할이 숨어있다.

굳이 창조성을 위한 일상이 아니더라도 일상은 삶의 흐름을 유지시켜준다는 측면에서도 역시나 지나쳐서는 안되는 중요한 사건들입니다. 예전에는 일기와 블로그에 일상이 들어갈 틈이 별로 없었던 것 같습니다. 젊었을 때에는 그저 제가 나아가야 할 방향과 그 길에서 중요한 사건들만이 의미가 있었습니다. 하지만 조금씩 나이가 들어가고 조금씩 소소한 일상에 감사하는, 머리가 아니라 몸으로 감사하고 관심갖고 즐거워할 수 있는 자세에 마음이 동합니다.

아이고, 이게 누구 아이냐?
엄마 나 애낳았어.

내가 처음 태어났을 때 어머니는 외할머니에게는 알리지도 않으시고 홀로 병원에 가서 떡하니 애하나 낳고선 이렇게 외할머니한테 직접 찾아가 나를 보여드렸다. 자신은 어찌 애낳는 고통 속에 어머님 생각이 나지 않았겠는가?
어떻게든 남에게는 피해를 주고 싶지 않고 손벌리지 않고 싶고 그저 주는 것에만 익숙한 나의 어머니는 외할머니가 남이 아님에도 그렇게 홀로 아픔을 견뎌 나를 낳았더랬다.
그랬던 나의 어머니는 무슨 운명의 장난인지 나의 여동생 첫출산에 그토록 곁에 있고 싶었음에도 불구하고 곁에서 손잡아주지 못하셨더랬다. 여동생이 출산예정일을 며칠 지나 진통이 시작되던 바로 그 때 어머니는 교통사고를 당하셨다.

난생 처음 당하신 교통사고에 거리에 쓰러져 아파하시면서도 계속 읊조렸던 한마디는 오직 '오늘 내 딸이 애 낳는데, 거기 가봐야 하는데, 어쩌나, 어쩌나...'였다.

그렇게 어머니는 조카가 태어나서도 한참을 병원에 계셔야만 했다. 언제나 우리 곁에 계실 것만 같고 건강하실 것만 같은 든든한 그 분이 병원에 계실 때 나는 일도, 생활도 말이 아니었다. 마치 당연하게만 여겼던 평소의 맑은 공기 중에 산소 2-30%는 빠져나간 듯하고 다른 누구의 건강보다 그 분의 건강함이 가정에 더 큰 기둥이었음을 느끼고 있다.

며칠 전에는 아직 두툼한 깁스를 하신 채로 어떻게든 외손자를 보시겠다며 나를 대동하고 딸네 집엘 부득불 가신 후 그제서야 환한 미소로 외손자를 안으시었더랬다. 아직 산후 후유증으로 힘들어하는 조카의 어머니와 또 그 어머니의 어머니를 바라보며 세상의 모든 어머니의 건강이 세상의 건강이 아닐까 생각해본다.
'아이가 건강하게 잘 태어났구나.' 하시던 어머니는 내가 병원에 다시 모시고 하직인사 드릴 때 조차 불편한 거동 억지로 이끌며 '밥 잘먹고 건강하라'고 당부 말씀 잊지 않으신다.
당신의 건강이 모두의 건강이고 당신이 건강해야 모두에게 행복이 깃듦을 어머님은 아실까?
'어머니 건강하세요. 그리고 오래 오래 사세요'

모 사이트 이벤트에 calmglow가 응모한 글. 당첨되어 공연티켓 한장 받으면 좋겠다.ㅡ,.ㅡ

ALSB의 설계 철학은 서비스 구현으로부터 관리 기능을 분리하자라는 것. 그래서 서비스 제공자와 사용자간의 Req-Resp 메시지 흐름을 관리자적인 측면에서 중재할 수 있다. 이는 ALSB의 관리자가 서비스 사용자와 제공자간의 흐름을 제어하고 모니터링할 수 있으며 서비스 공개에 대한 Lifecycle을 관리할 수 있음을 의미한다. 또한 이 서비스 흐름에는 단지 서비스 제공자와 사용자간의 연계만 포함되는 것이 아니라 서비스에 대한 등록과 삭제, 동적인 Routing, 변환, 보안적인 이슈, 비즈니스 프로세스등이 포함된다. 즉, ALSB는 보다 지능화된 서비스에 대한 메타 프록시서비스이고 ALSB에서 강조되거나 독특한 점은 이러한 것을 관리자 수준에서 제어하도록 유도한다는 점일 것이며 따라서 이것은 개발이나 구현등의 이슈가 아닌 정책(Policy)이라는 이슈로 끌어올렸다는 점에서 다른 ESB와의 차별성이 있다고 할 수 있다.


그 외 기능 부분에서 다른 ESB와 차별화될만한 요소들은 다음과 같다.

XQuery 사용: XQuery를 관리자 수준에서 사용함으로써 보다 복잡한 XML 제어가 가능해졌다. 이는 어쨌든간에 장점으로 볼 수 있겠는데, 아무래도 XPath보다는 Xquery를 사용했을 때 보다 복잡하고도 세밀한 XML 제어가 가능해지며 관리자나 개발자의 역량에 따라 다양한 기법을 적용해볼 수 있다는 측면에서 적절한 선택이 아닌가 생각한다. 그 반면에 XQuery 역시 과도한 XML 처리를 불러오므로 속도의 저하는 피할 수 없는 게 아닌가 한다. XSLT보다는 처리 속도에 있어서 나은 성능을 보여줄 지는 모르겠으나 XQuery 역시 성능을 크게 낮출 요인이 될 것이다.


로깅 및 모니터링의 강화: SLA를 만족시키기 위해 할 수 있는 최대한의 것을 제공하겠다는 의도로 다양한 인프라스트럭쳐가 제공된다. 일단 기본적인 수준의 대쉬보드는 관리자 콘솔에서 확인할 수 있고 그 외 세밀한 것들에 대해서는 여러 API등을 통해서도 확인이 가능하다. 게다가 뭔가 문제가 생기거나 자신이 원하는 SLA를 만족시키지 못하였을 경우에는 Altert 기능도 사용할 수 있다. 또한 이러한 SLA에 따라 서비스를 종료하거나 실행하는 것이 가능하다. 일단 이 부분에 대한 보다 자세한 검증은 필요하겠으나 기본적으로 이 정도면 ESB에서 필요한 관리 요건을 어느 정도 충족했다고 보여진다.
(to be continue...)

어제 국내 모 SI회사의 SOA관련 세미나를 듣게 되었다.
외국계 벤더의 SOA만을 접하다가 국내의 SI회사의 SOA에 대한 접근과 모색을 엿볼 수 있는 좋은 기회였기에 의미깊은 행사여서 휴가임에도 불구하고 잠깐 참석하는 열의를 보였다.

무엇보다 놀라웠던 것은 그 분들이 개발하고 있는 SOA의 아키텍처나 방법론이 기존의 CBD와 크게 다르지 않았다라는 점이었다. View point역시 개별 프로젝트에 대한 SOA적 접근 방법으로서의 모습이었고 어떻게든 CBD와 SOA를 엮기 위해 노력하고 있다라는 점이었다.
내 생각으로는 이를테면 콜센터를 구축하건 CRM을 구축하건 MCA를 구축하건간에 이러한 개별 프로젝트는 기존대로 CBD가지고도 유연성과 재사용성을 발휘할 수 있다. 하지만 이러한 개별 프로젝트의 IT자산들이 다시 묶이고 묶여서 업무 부서들간의 자유로운 협업을 꾀한다면 그때 SOA를 위한 여러 장치나 비즈니스 가치에 따른 설계를 할 수도 있다. 왜 CRM시스템이나 콜센터 프로젝트 안에 ESB가 Presentation layer와 Biz Logic사이에 들어가야 하는 것일까?
SOA의 장점이 비즈니스의 유연성 가시성이라 할 때 이러한 장점들은 global한 IT 인프라에서야만 발휘될 수 있는 것이고, 단지 어느 IT 프로젝트에서라면 CBD관점만으로도 IT자산의 유연성과 가시성은 충분히 발휘될 수 있다고 본다.

자 보십시오. 국회의 주인은 한나라당이요, 이 나라의 주인은 한나라당입니다.
한나라당에서 굳이 대통령까지 나올 필요 있나요?

마케팅에 대해 잘 아는 사람은 아니지만 적어도 마케팅 관점에서 성공했던 유수한 사례에 비추어 보았을 때
과연 SOA는 성공한 상품(?)일까?
과연 어떻게든 CEO와 CIO등을 설득하기 위하여 진행하는 그들 대상의 며칠 짜리 골프를 겸한 워크샵이나
일반 IT 생산자들을 위한 SOA에 대한 대중 세미나에서 소비자들의 뇌리에 파박~ 하고 꽂히는 SOA에 대한 이미지는 무엇일까?

아 어렵다.
SOA는 Service Oriented Architecture래
서비스가 대체 뭐지?
벤더가 살아남기 위한 마케팅인가보다.

아마 위의 것이 대부분일 터. 그렇다면 제 아무리 SOA가 훌륭한 가치를 지닌 개념이라고 해도 마케팅관점에서는 이미 사람들에게 외면당하기 쉬운 상품일 수 밖에 없다.
만약 SOA로 떼돈을 벌고 싶다면 SOA... 다시 시작하는 게 나을지도 모른다.

ESB가 제대로 현업에서 기존의 EAI라든지 BPM등에서 적용되어 사용되기 위해서
기술적으로 선결되어야 하는 것에는

SOA에 대한 IT전반적인 인식이나 뭐 그런 인프라 수준의 문제 뿐만 아니라
XML처리에 대한 보다 획기적인 빠른 처리 성능을 제공할 수 있어야 하는 점이라고 생각한다.
특히 메시지 변환 시 XSLT등을 사용한다면 그 성능을 어느 수준 이상 기대하기는 어렵다.
정확한 비교 수치를 이 블로그에 기재하기에는 여러가지 여건이 되지 않아 아쉽지만
우리가 쉽게 자바만으로 테스트를 해보아도 메시지 변환에 대해
자바 클래스 매핑을 통한 변환과 XSLT를 이용한 변환의 성능 비교는
메시지 크기가 늘어나면 늘어날 수록 현격하게 차이나서
과연 아무리 메시지의 표준화라는 측면에서 XML을 사용해야만 하는 100가지 이유가 있다고 하더라도
이러한 성능상의 약점을 안고 가야만 하는 것인지 조금 스스로 확신하기 어려울 때가 종종있다.
그래서 DataPower같은 하드웨어에서의 XML변환 관련 프로세서가 탄생한 것인지도 모르겠다.