calmglow (최진호)

오늘도 출근길에 스마트폰으로 서핑을 하다가 한번 이상 끊긴 인터넷때문에 눈을 감으며 지하철에 앉았었다. 3G는 어쩔 수 없으려나? LTE는 과연 지금보다 훨씬 나은 환경을 제공해줄까? 생각한다.

7년이라는 긴 시간동안 정들었던 IBM을 떠나게 되었다.
회사가 아니라 놀이터같았던 곳.
단 하루도 출근하기 싫었던 적이 없던 곳.
끊임없이 도전하게 하고 치열함을 맛보게 했던 곳.
돌이켜보면 얻은 게 너무나 많은 곳이다.

이곳을 나와서 미래에 나는 어떤 모습이 될까?
앞으로 내가 어디에서 어떤 일을 하건간에,
변하지 않을 것이라고 확신할 수 있는 것은
새로운 기술과 가치의 변화에 환장하고
그것을 직접 손으로 익혀보지 않고는 못배기며
사람들과 공유하기를 주저하지 않는,
나는 천상 엔지니어라는 것이다.

감사합니다 IBM

나는 작년에 noSQL기반의 이벤트처리에 특화된 룰엔진 솔루션을 이용하여 실시간 고객 마케팅 시스템을 구축하는 프로젝트에 6개월간 솔루션 아키텍트로 참여하였다.
때는 바야흐로 BigData의 시대, 고객의 정보는 넘쳐나고 그것들의 의미를 찬찬히 분석하고 의사결정을 하는 것도 중요하지만 고객이 정말 가려운 곳이 있을 때 재빨리 파악해서 대응을 하는 똘똘한 마케팅 시스템이 주목받고 있다. 즉, 대중 마케팅이나 타겟마케팅이 아니라 개인화 마케팅같은 눈치빠른 마케팅의 시대에 있다.

그런데 문제는 이러한 극단적인 실시간 개인화 마케팅에는 대량의 데이터에 대한 아주 아주 빠른 처리 능력이 요구된다는 점이다.

분당에 사는 30대 남자가 롯데마트에 와서 10만원 이상을 결제하고 분유와 맥주를 구매했을 때 그가 과거 해당 롯데마트에서 얼마나 실적이 있으며 신용도는 어떠한지, 구매한 시간대가 언제인지에 따라 그에게 롯데마트 포인트를 2배 올려주는 서비스를 제공할지 치킨을 할인된 가격으로 제공할지 술을 마실 수 없는 아내를 위해 콜라를 덤으로 제공할지 2초에서 3초 안에 결정해야하는 상황에서 기존의 RDB나 DW방식은 아주 많은 한계를 갖고 있다.

이처럼 고객 정보 자체보다 해당 정보와 관계맺고 있는 수없이 많은 열린 정보들과의 관계와 변화가 더 중요하고 그 관계와 변화를 빨리 파악해내는 데 있어 noSQL과 이벤트처리 솔루션은 큰 효율성을 제공한다.

아래는 해당 프로젝트에서 noSQL기반의 솔루션이 어떻게 대량의 이벤트 정보를 처리하는 지를 대략적으로 보여준다.


그림에서 보는 것같이 Grid기반의 memory cache스타일의 noSQL은 고객의 정보를 다양한 채널로부터 받아서 그것들간의 Context정보를 저장한다. 그리고 그 정보는 실시간으로 마케터에게 통계 및 분석 정보를 전달하기도 하고 실시간 룰엔진처리 엔진을 통해 즉각적인 마케팅 활동에 도움을 주기도 한다.

과거의 기술 방식이었다면 초당 몇만건의 SQL문을 처리해야 했고 그럼에도 불구하고 몇십초 몇분이 걸릴 수도 있었던 상황이었으나 noSQL과 이벤트 처리 솔루션을 통해 1-2초 내에 처리가 가능해졌다.

이 프로젝트에서 사용된 noSQL기술은 하둡(Hadoop)기반의 범용적인 noSQL이 아니라 그리드 기술이 적용된 memory cache방식인 IBM Extreme Scale(Oracle의 coherence와 유사함)이다. 5-6년 전에 이미 나온 기술이어서 기술적인 완성도도 높고 성능도 충분히 발휘할 수 있었다. 하지만 Row oriented sparse column store방식인 HBase나 Cassandra로도 구현이 당연히 가능하리라고 본다.

물론 실시간 마케팅을 처리하기 위해서는 noSQL기술만으로 되는 것은 아니다. 기획부터 테스트, 시뮬레이션, 실행, 분석에 이르는 모든 마케팅 프로세스를 지원해야하기 때문에 noSQL기술은 전체 중 아주 일부분이지만 실시간 마케팅 시스템에서 가장 큰 난제였던 성능 부분을 해결할 수 있는 핵심기술 중의 하나이기에 이렇게 소개하게 되었다.

작년에 noSQL기반 기술을 이용해서 성공적으로 프로젝트한 것을 블로그로 정리하려다가 먼저 첫번째로 noSQL의 기본 개념에 대해 먼저 정리하는 것이 좋겠다는 생각이 들어 Jimbojw.com의 2년전 포스트를 번역 및 정리할까 한다.

noSQL기술이 BigData처리와 함께 갑자기 화두가 되고 있다. 5년전 memory cache기반의 noSQL기술을 접했을 때에는 '이걸로 과연 어디에 적용할 수 있을까?' 하며 부정적이었는데, 어느새 이런 기술이 이전의 많은 기술을 뒤엎기라도 할 기세다. 아무튼 noSQL에 대한 나의 부정적인 감정(?)에 대한 토로는 나중으로 미루고 이번에는 noSQL의 기본 개념에 대해 정리해보자.

구글의 BigTable paper에 보면 구글의 BigTable이 대체 무엇인지에 대해 간단하고 명료하게 기술하고 있다.

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

이 간단한 문장에 noSQL기반 기술의 거의 모든 기본이 들어있다고 보면 된다. 자 이제 하나 하나 파들어가볼까?

Map이다
이게 정말 핵심중의 핵심이다. 이것만 이해해도 상당히 많은 기본개념을 이해한거라 나는 생각한다. 바쁘면 이제 이 글의 나머지를 안 읽어도 된다(^^). 거의 모든 noSQL은 Map이다. 즉, 유일한 키와 그것에 관련된 하나의 값을 가진 자료형이 noSQL이 데이타를 저장하는 기본적인 방식이다. JSON방식으로 예를 들면 다음과 같은 형태로 noSQL은 자료를 저장한다.

{
 "zzzzz" : "woot",
 "xyz" : "hello",
 "aaaab" : "world",
 "1" : "x",
 "aaaaa" : "y"
}

영구적이다 (Persistence)
noSQL은 기본적으로 데이타베이스의 역할을 수행한다. 당연히 데이타는 어느 정도 이상은 영구적이어야한다. 다만 메모리기반의 noSQL의 경우 이 영구적인 특성이 조금 떨어진다고 볼수도 있겠다.

분산기반이다 (Distribute)
noSQL이 나온 배경중의 하나는 기존의 RDB가 데이터 확장에 따른 확장성에 제약이 심했기 때문이다. 따라서 대부분의 noSQL은 데이터 저장 및 복제에 대해 설계 초기부터 분산시스템을 기반에 두게 되었다. 구글의 BigTable의 경우 Google File System(GFS)을 기반으로 하고, HBase를 비롯한 많은 noSQL은 하둡(Hadoop)의 분산 파일 시스템(HDFS)을 사용한다.
데이타 복제와 분산처리를 어떻게 하는지 자체에 대한 것은 사실 noSQL 기본 개념과는 큰 상관이 없는 주제이므로, 그리고 나도 사실 그쪽에는 내공이 딸리므로 넘어가자.

정렬기능이 있다 (Sorted)
모든 noSQL이 이 기능을 가지고 있다는 게 아니라 HBase, BigTable같은 일부가 가지고 있는 기능이다. 키와 값이 알파벳순으로 정렬이 되는 기능을 가진다. 실로 어마어마한 데이타를 처리하기 위한 용도로 만들어진게 noSQL이다보니 이런 정렬기능은, 혹은 이런 정렬기능의 성능은 너무나도 중요한 요소이다.

다차원적이다 (Multidimentional)
noSQL의 개념이 기존 데이타베이스에 익숙한 사람들에게 전달되기 위해 많은 noSQL기술들이 기존의 개념을 많이 차용한다. 테이블이나 칼럼 혹은 Row같은 RDB의 개념이 그대로 noSQL에서도 쓰이는 경우가 있고 이로 인해 noSQL의 이해를 어렵게 하는 경우가 있다. 새술은 새푸대에 담았으면 싶다. 그래서 다차원적인 Map을 지원하는게 noSQL의 특징이라고 강조하고 싶다. 다차원적이라는 말이 어렵다면 Map의 Map을 지원한다라고 할까? 즉,

{
 "1" : {
  "A" : "x",
  "B" : "z"  },
 "aaaaa" : {
   "A" : "y",
   "B" : "w"  
 },
 "aaaab" : {
   "A" : "world",
   "B" : "ocean"  
 },
 "xyz" : {
   "A" : "hello",
   "B" : "there"  
 },
 "zzzzz" : {
   "A" : "woot",
   "B" : "1337"  
 }
}

위의 코드와 같이 Map의 Map의 형태로 데이터를 저장하는 것이 가능하다. 이 특성을 이용해서 "1"이나 "aaaa"를 row에 대한 키로 정의하고 "A"나 "B"를 column의 키로 정의하는 것이 가능하고 전체를 하나의 테이블로 정의할수도 있겠다.

엉성하다 (Sparse)
noSQL의 데이타 모델의 특징은 엉성하다는데 있기도 하다. 기존 RDB가 명확한 데이타 스키마 기반으로 데이타를 처리하고 그 스키마를 변경하는데 많은 비용이 들었다면, noSQL의 경우는 그보다 훨씬 더 데이타 모델에 대해 유연성을 제공한다.

{  // ...
 "zzzzz" : 
  {    "A" : 
   {      
   "catch_phrase" : "woot",    
   }
  }
}

위의 예처럼, "zzzz" Row의 "A"칼럼은 이제까지 없었던 "catch_phrase"라는 키를 가지고 있다. 이처럼 noSQL은 데이타 모델에 대해 훨씬 더 유연한 특성을 가지고 있다.

그럼 어떤 종류의 noSQL이 있을까?
맵+엉성+다차원= memcache: 일단 가장 단순한 형태로 memcache를 들수 있다. 쉽게 말해 메모리상에 맵형태로 데이터를 처리하는 방식인데, 이 메모리가 해싱기법에 의해 다중 서버에 의해 관리되는 방식이다. 클라이언트는 자신만의 해싱키를 이용해서 자기가 원하는 서버에 데이터를 저장하고 처리할 수 있다. 하지만 Persistence를 지원하거나 확장성이 높은 형태를 지원하지는 않는다. 또한 메모리만을 사용하므로 가격이 저렴한 편도 아니다. 하지만 가장 단순하게 noSQL을 적용해서 처리할 수 있는 기술이고 특히 캐시용도로 많이 사용한다.

맵+엉성+다차원+분산= 오라클 coherence, IBM ObjectGrid: memcache에다가 그리드 기반의 기술을 접목한 것으로 메모리만 충분히 많다면 가장 빠른 처리시스템을 보유할 수 있고 데이타 복제나 분산기반 확장등에 아주 많은 잇점을 가져올 수 있다. 별도의 솔루션을 이용하면 일반 Disk기반의 영속성등을 처리할 수도 있다.

맵+엉성+다차원+분산+영속성+정렬=HBase, BigTable, Cassandra: 이것은 앞서 설명했던 기본적인 noSQL의 기능을 대부분 가지고 있는 기술들이다. 더 설명할 게 없다. MongoDB같은 문서기반의 noSQL도 설명할 수도 있겠는데, 일단 본 포스트는 기본 개념에 충실하자고 쓴 글이므로 여기서 마무리 한다.


이정도면 기본이겠지
noSQL기술이 얼마나 앞으로 사람들을 더 열광시킬지 잘 모르겠다. 분명 재미있는 기술이고 부분적으로나마 상당히 효과를 볼만한 곳이 많은 기술이다. 아무튼 기본적인 noSQL의 개념은 여기까지로 하고 그것에 얽힌 내 경험은 다음에 풀어보도록 하겠당.

나는 최근 몇년간 룰엔진의 기업 적용에 많은 노력을 기울여왔다. 엄밀하게 말하면 룰엔진을 기반으로한 CEP엔진이다. 그러다보니 룰엔진에 관심이 있거나 경험을 가진 고객을 만나왔고, 대부분 그 반응은 극과 극을 달린다. 즉,

룰엔진을 도입해서 우리 업무 시스템의 자동화를 극대화할 수 있었다.
룰엔진을 도입해서 쉽게 업무 변화에 대응할 수 있었다.
와 같이 지극히 만족하는 경우 아니면,

1년전에 룰엔진을 도입했지만 지금은 급격한 조직변경으로 인해 쓸 수가 없었다.
시스템의 변화에 룰엔진이 따라오지 못해 전혀 사용하지 못하고있다.
와 같이 구축해놓고 사용하지도 못하는 고객의 불만을 접할 수 있었다.

업무 자동화와 기민한 변화 대응능력을 높이기 위해 도입하는 룰엔진이 이처럼 그 반응이 극과극인 이유는 여러가지가 있다. 그중 룰엔진 도입이 실패하는 몇가지 경우를 나의 경험을 토대로 정리해보았다.
1. 업무 성격상 룰엔진이 어울리지 않는 경우.
2. 유연한 설계를 하지 않은 경우.
3. 시스템의 변화가 많은 경우.

1. 업무 성격상 룰엔진이 어울리지 않는 경우
룰엔진은 보통 업무 모델이 정해져있고 모델간의 상관관계나 규칙을 변화시켜 변화에 대응하게 된다. 그런데 업무 모델 자체의 변화가 매우 심하거나 다수의 업무 모델이 자주 변해야하고 연계가 되어야 하는 경우는 보통의 룰엔진으로 적응하기 어려운 부분이 있다. 인사나 상품 혹은 RiskManagement System과 같이 하나의 업무 내에서의 엔진 도입이 아니라 다양한 업무 시스템과의 연계가 필요하거나 모델자체가 자주 변해야만하는 경우 룰엔진의 도입은 보다 신중하게 고려되어야할 필요가 있다.

2. 유연한 설계를 하지 않은 경우.
이를테면 인사시스템의 임금지불규칙을 룰엔진으로 구축한 경우 설계를 어설프게 한다면 1년이나 2년 뒤 임금 지불 체계가 완전히 혹은 많은 부분이 바뀐 시점에서 더 이상 그 시스템은 사용이 불가능해질 수 있다. 즉, 급격한 변화를 고려하지 않은 룰엔진 기반의 시스템은 개발로만 이루어진 시스템과 다를바 없이 머지않은 시점에 재구축을 고려할 수 밖에 없을 것이다.

3. 시스템의 변화가 많은 경우
1번에서도 언급했지만 관련된 시스템의 향후 변화가 예측할 수 없을만큼 심한 경우 룰엔진 도입은 신중해져야한다. 룰엔진은 업무 내의 변화에는 유연하지만 시스템 자체의 변화와 연계의 유연성에는 취약하기 때문이다. 물론 이런 부분들은 여러 추가적인 솔루션으로 극복할 수 있다.

이러한 여러 극복해야할 것들이 있음에도 불구하고 룰엔진은 기업의 업무 유연성과 자동화에 막대한 장점을 안겨줄 수 있다. 때로는 조직의 반대로 인해 룰엔진 도입이 어려움에 처해질 수도 있다. 인간은 의외로 틀에 얽매이는 것을 싫어한다. 특히 한국인은 유도리(융통성)를 좋아한다. 룰엔진 도입시 룰에 규제를 받는 몇몇 사람의 인생은 다소 팍팍해질 수도 있다. 하지만 거의 대다수의 사람의 인생은 보다 자유로워질 것이다.

한편 가트너의 Managing Vice President인 David W. McCoy는 그의 최근 블로그에서 룰엔진 도입의 중요성을 강조하면서 룰엔진이 룰엔진 자체로 적용되기 보다는 여러 솔루션과 연계되어 시너지를 불러 일으키리라고 보았다.

1. Rules + events = real-time reaction
2. Rules + scenario analysis = policy-driven agility
3. Rules + process = mutable processes that stay within bounds
4. Rules + applications = rapid adaption to new opportunities

이 중에서 나는 주로 1번, 즉 룰엔진과 이벤트처리 엔진을 결합한 실시간 이벤트 처리 솔루션에 많은 경험을 갖고 있다.

사실 룰엔진은 도입을 고민할 필요도 없다. 이미 거의 모든 기업용 솔루션에 기본 엔진으로 포함되었고 모든 똑똑한 세상을 만드는 소프트웨어에 없어서는 안될 기능이 되었기 때문이다.
얼마나 더 똑똑하게 혹은 얼마나 더 빠르게가 더 중요한 핵심이 되었다고 본다.

마음은 언제나 무언가를 지향하는데 최적화되어있다. 마음이 존재한다면 그것은 지향성일 뿐이다. 나 아닌 세상에 이름을 붙이고 추억을 만들고 감정을 만든다. 이러한 세상에 대한 이름과 추억 그리고 감정이 한 묶음이 되어 그것이 정말로 객관적으로 존재한다고 믿고 그것에 집착한다. 그것이 마음이 세상과 어울리는 방식이다. 거기에 모든 희노애락이 존재한다. 하지만 그것은 마음이 세상과 어울리는 방식일뿐 그런 묶음이 나라는 존재 자체인 것은 아니다. 아니 나라는 존재는 그런 묶음으로 구성된 허구다. 사실은 정말로 존재하는 것은 이러한 세상에 대한 마음이 만들어낸 묶음을 엮어가는 마음의 지향성이다. 세상과 관계 맺어가는 마음의 지향성. 그것이 진짜 마음이다. 이런 마음의 지향성은 누구나 저마다의 스타일을 가지고 있다. 마음의 대상에 집착하지 않고 대상을 바라보는 마음의 지향성을 바라보는 것. 그것이 위빠싸나 혹은 부처의 자세다. 세상을 있는 그대로 바라본다는 말은 세상을 바라보는 나를 바라본다는 말과 다르지 않다. 그리고 그것이 나를 온전하게 바라보는 자세인 것이다.

너무 늦게 느끼고있는 것인지는 모르겠지만, 최근에 뭔가 거대한 흐름이 다가오고 있다는 생각을 하곤 한다. 단순히 스마트폰이나 Web 2.0정도의 국지적인 변화를 말하는게 아니다. 근본적인 변화의 흐름이 있는게 아닌가.. 해서 다음과 같이 술마시다 생각난 김에 써봤는데,.. 이것만이 내가 느낀 것은 아닌 것 같고... 나중에 잘 정리되면 또 한번 글을 써야겠다.

클라우드
일반 기업에게 IT기술은 아주 핵심적인 부분을 제외하고는 많은 부분 비용!으로 치부된다. 그 비용을 최소화하기 위해 CBD도 있었고 SOA도 있었다. 하지만 SOA 백날 해봤자 기업 IT환경을 아우르는 근본이 바뀌지 않는 이상 비용의 문제는 근본적으로 해결이 불가능했다. 그러나 클라우드 기술은 이러한 IT기술 투자에 따른 비용의 문제를 근본적으로 바꿀 수 있는 흐름이다. 비록 클라우드 기술이 기존의 관행을 뒤흔듦으로 인하여 일자리 구조의 변동은 있겠지만 이 흐름 자체는 거스를 수 없는 대세가 아닌가?

넘쳐나는 데이타와 지금 여기
데이타가 넘쳐나고 있다. 그냥 데이타만 넘쳐나는 게 아니라 데이타와 데이타간의 관계도 늘어나고 있다. 아니, 데이타 자체도 자체지만 데이타와 데이타간의 관계 정보가 더욱 더 넘쳐나고 있다. 아니, 더 정확히 말하면, 영구적인 관계 데이타가 아닌, 한시적이고 Context에 민감한 관계데이타가 늘어나고 있다. 지금 당장 감지하고 대응하지 않으면 아무 의미가 없는, 하지만 지금 바로 당장은 너무나 의미있는 그런 데이타가 넘쳐나고 있다.
1시간 뒤면 늦어버리는, 내가 지금 강남역에 있다는 위치 정보. 내가 지금 당장 스타벅스에서 커피를 마시면서 누군가를 기다리고 있는 그 순간의 정보. 내가 누군가와 대화하고 있는 그 정보. 이런 찰나와 같은 정보가 중요해지고 있다.
아니 지금 여기의 정보들간의 의미가 중요해지고 있다가 맞을 것이다.

물건이 숨을 쉰다
심지어는 마시는 물이나 건물도 살아나기 시작한다. 사람들은 슈퍼컴퓨터급의 스마트폰을 수고로이 들고다니며 열심히 과거에는 이름조차 불리지 않는 무생물에 사진이나 텍스트로 정보를 만들어 Crawling을 한다. 온 땅덩어리가 센서들로 뒤덮이고 끊임없이 정보를 주고받는다. 사람이 기기를 통해 진화하는 게 아니라 기계가 사람을 통해 진화하고 번식하고 있는 꼴이다. 지금의 정보의 유통과는 비교도 안될 정도의 물건과 물건, 사람과 물건사이의 소통과 네트워크에 따른 IT투자가 있을 것이 분명하다.