calmglow (최진호)

여기는 시카고.

글을 놓은지 꽤 되었더니 한줄 한줄이 고역이다.
시와 노래와 그림은 그렇다치더라도 어릴때부터 지속해온 글쓰기마저 고문이라면 나는 그동안 충분히 내 자신과 그리워하던 것들에 대하여 나태하였다.
많은 현자들은 자연 현상을 예로 들어 사람도 마찬가지로 새로 시작하려면 비워야 함을 강조하지만,
사람은 생명없는 그릇이 아닌
생명체, 중에서도 가장 촉망받는 생명체이기에
때로는 많이 채워야 더 새로움을 채울 그릇이 되기도 한다.

그동안 비우고 비워 새로 시작할 용기를 북돋지 못하였다면
어설픈 생각의 갈래라도 다시 채우고 채워 그릇의 크기를 채워 볼 참이다.
그대는 나에게 용기를 주기를 바란다.
때론 삐뚤어질지라도.

그리움 떠난 자리, 시와 노래와 그림도 떠나네.
큰 마음 떠난 자리, 치켜든 눈빛과 호탕한 기개도 떠나네.
언제쯤 그대가 찾아와 나의 뺨 후려갈기려나

그동안 글을 쓰지 않으면서
글을 쓰고자 하는 욕망이 스스로 생겨나 더 큰 에너지로 살아가지 않을까 했었는데,
나의 에너지는 글을 통해 되살아나고 세상과 호흡할 수 있다는 것을 알게되었다.
비록 어줍잖고 지난 10년간 아무것도 달라진 것이 없는 것만을 깨달은 6개월이었지만
그럼에도 글을 통해 더 나은 내가 될 수 있을 것이라는 희망으로
다시 블로그의 창을 활짝 열어본다.

calmglow, 적광(寂光)
1999년 여름, 수덕사, 지금은 입적하신 법장(法長) 스님에게 받은 그 법명으로 Calmglow는 태어났다. 그날 해지는 저녁에 바라본 노을빛은 유난히도 붉고 적적했었다.
적광, 적적한 빛, 극락정토의 빛이며 부처가 살고있는 곳의 빛을 의미하니 지금의 나와는 천양지차.
적광으로 지낸 10년은 비록 적광스럽지는 못하되 적광으로 가는 나침반 하나 정도는 얻은 듯하다.
마치 화엄경의 선재동자가 도를 구하려 53인의 스승을 세상속에서 만나 돌아다니듯 많은 스승이 적광을 깨우치게 도움을 주었고 그 적광은 오늘 새로운 눈으로 이 적광의 발자취가 새겨진 블로그를 살펴본다. 지금 이 블로그에는 그저 기술적인 내용만으로 채워져 지난날의 적광의 진짜 발자취는 사라져있지만 개인자료에 담겨진 지난 10년의 모든 글은 때로는 부끄러움과 때로는 놀라움으로 여전히 가슴을 두근거리게 한다.
몸과 마음과 영혼을 완전히 변화하게 해준 지난 10년의 스승들에게 진심으로, 진심으로 이렇게 말하고 싶다.
그대들 모두를 영원히 사랑할 것이고 원망하지 않을 것이며 언제나 빚진 마음으로 살아갈 것이라고.

왜냐하면 그는 그의 기나긴 진리의 여행을 통해서 배운 것들의 엄청난 양과는 달리 이제 그 양을 자꾸 줄여 가는 것을 원하고 있기 때문이다......
선재는 이 세계에 대해서 함부로 알아서는 안 될 것이 많다고 생각했다.... 이제까지 안 것이 이제 그에게는 새로운 미지 앞에서 아무것도 아닌 것을 깨달았다.
선재가 가야 할 길은 이제부터이다. 그가 보현 보살을 하직하고 나서 동쪽으로 향했던 것 그리고 강을 따라 바다에 들어와버린 것들은 그가 가야 할 세계에의 첫 전망에 틀림없다.
어린 나그네는 이제 그의 장엄하기까지 한 나그넷 길을 끝냈다.
-- 고은의 화엄경 중에서

이제 적광은 길을 끝냈다.

Web 2.0과 클라우드 컴퓨팅 환경 기반 웹 개발을 위해 태어난 새로운(?) 경량의 웹 프레임워크.
그루비와 PHP개발자를 위해 태어난 가벼운 웹 기반 프레임워크.
부하가 없을 땐 300K의 메모리밖에 점유하지 않는 엄청나게 가벼운 웹 프레임워크.
sMash 혹은 또 다른 이름인 Project Zero에 대한 소개 차트를 만들었다.
developerWorks에서 발표할 내용이다.
몰랐는데, 1시간이나 잡아주셨다. 그렇게 많이 이야기할 것도 없는데..
아무튼 처음으로 google docs의 프리젠테이션만을 이용해서 차트를 만들었는데,
고생해서 만들고난 소감은, 다시는 느려터지고 기능 그지같이 없는 구글Docs의 프리젠테이션을 쓰지 않겠다는 맘 뿐이다.

참고: 발표할 자료

약 1년 동안 IBM 소프트웨어그룹에서 기존과는 조금 다른 성격의 기술을 담당하고 있었습니다. 처음에는, 아니 어제까지도 전혀 다른 두 개의 기술이라고 여겼던 Situational Application과 Event Driven Architecture가 사실은 동일한 기업 문제를 해결하기 위한 것임을, 하나의 그래프로 엮어볼 수 있겠다는 아이디어가 떠올라서 다음과 같이 메모합니다.

---

기업 내에 존재하는 IT애플리케이션들의 기능들이 과연 그 기업의 어떤 프로세스와 상황을 대처하기 위해 만들어졌는지에 따른 기준으로 생각해보자.

IT 애플리케이션들아! 네 존재의 이유는 무엇이니?

그 기준은 오로지 하나이다. 기업의 목표가 수익 창출이라면,

기업 내에 존재하는 IT애플리케이션의 목적은 다음 3가지 중의 하나에 부합되어야만 한다.

A. 수익을 잃어버리거나 감소시키거나 손해를 크게 보지 않게 하기 위한 애플리케이션 혹은 기능.
C. 경쟁자에 비해 매우 높은 수익을 발생시키거나 기회를 잡을 수 있게 도와주는 애플리케이션 혹은 기능.
B. 그리고 기업 운영에 필요한, 적당한 ROI를 가능케 하는 애플리케이션 혹은 기능.

그렇다면 이 세가지 종류의 IT 애플리케이션들의 실제 비중은 어떨까? 이런 그래프가 아니겠는가?
비주얼에 약한 관계로 그래프가 조금 극단적으로 그려진 것을 양해해주시길...

B 구간, 즉 정상적인 기업 운영에 필요한 애플리케이션들이 정상적이게도 기업내에 가장 많은 비중을 차지하기 마련이다. 당연한 것이다. ERP나 홈페이지나 인사,회계 시스템들이 모두 B구간에 속하는 것들이다.
그러다가 기업이 IT자산 투자에 여유가 생기면 A와 C에 투자하기 시작한다.
해킹이나 서버다운과 같이 평소에는 발생하지 않지만 간헐적으로 발생하는 것만으로도 큰 영향을 미치는 A영역의 애플리케이션이나
잠재적인 고객 트렌드와 동향을 파악하고 고객의 숨은 니즈를 파악하는 덩치크고 비싸기 그지없는 BI툴이나 CRM애플리케이션들이 C영역에 속하는 애플리케이션들이다.

그런데 아주 아주 정상적인 프로세스와 흐름을 지닌 B영역의 애플리케이션에 비해서 A와 C영역의 것들은 사실 변수가 너무나 많이 존재한다.

먼저 A영역의 애플리케이션의 고충을 생각해보자.
A영역의 애플리케이션의 핵심은 바로 Risk 관리이다. 사기를 치거나 도덕적으로 옳지 못한 행동으로 이익을 챙기려는 고객의 행위는 항상 진화한다. 1년전에 구축한 모델과 룰은 메모리만 차지하는 쓰레기이다. 오늘은 오늘의 Risk 관리가 필요한게 A영역의 애플리케이션의 특징이다.

그럼 C영역의 애플리케이션은 다를까?
다를게 없다. 고객의 충성도를 높이고 더 나은 고객을 모으고 고객 니즈의 숨겨진 2%를 챙기려면 고객의 변화보다 한발짝 앞서가거나 적어도 보폭을 맞추어야만 한다. 눈치와 시간 그리고 센스의 싸움이다. 도저히 1년전에 만든 프로세스와 캠페인으로 경쟁자를 따돌릴 수 없다.

그래프상으로는 상극에 속하고 있는 A,C 두 종류의 애플리케이션은 사실 아래와 같은 동일한 특성을 가지고 있다.

* 변화가 빠르다.
* 통찰이 필요하다.
* 빠른 구현이 필요하다.
* 다양한 정보 원천으로부터의 용이한 매쉬업(연계)이 필요하다.
* 수명이 짧다.

다시 말해, 빠른 변화, 통찰, 빠른 구현, 매쉬업, 짧은 수명, 이 5가지가 바로 IT Agility를 고민하는 기업이 취해야할 핵심 키워드이다.
최근에 경량화된 웹 프레임워크인 Rails, Grails, sMash등의 출현은 보다 변화에 빠르게 대응하고 빠른 구현과 매쉬업을 제공함으로써 기업 생산성 증대 및 유연성을 기르는데 매우 중요한 기술로 발돋움하고 있으며 아울러 이벤트 기반의 솔루션들(CEP 엔진들) 역시 주목을 받고 있는 이유는 통찰과 빠른 변화 및 연계기술등을 통한 기업의 수익을 극대화하기 위한 흐름이라고 볼 수 있다. 굳이 가트너등의 리서치회사의 자료를 언급하지 않더라도 이미 IT 기술의 흐름은 이러한 5가지 키워드를 만족하는 것들에 관심을 가지고 있음을 알 수 있다.