[데이터 아키텍처 활용] ⑤ 전사적 데이터웨어하우스 구축

요즈음 어디를 가보더라도 웬만한 기업이라면 자신들은 데이터웨어하우스를 구축하여 적용하고 있노라고 큰 소리를 치고 있다. 하지만 다량의 데이터를 액세스해야 생성할 수 있는 분석자료를 OLTP에서 처리하기에 부담이 되기 때문에 ‘다른 서버로 데이터를 옮겨 둔’ 정도에 지나지 않는 경우가 다반사다. 데이터웨어하우스라면 최소한 지켜야 하는 원칙을 한 번 생각해 보기로 하자. 우리가 어떤 경우에도 반드시 준수해야 할 기본 원칙은 바로 ‘통합, 단순, 장기(long term)’의 3가지다. OLTP는 사실 다른 목적들까지도 모두 감안해 줄 여력이 없는 형편이다. 결국 ‘목마른 사람이 샘을 판다’는 속담처럼 정보의 분석이 목적인 쪽에서는 자신의 입맛에 맡도록 남(트랜젝션 처리 시스템)이 변해 주기를 기다렸다가는 그야말로 아무 것도 할 수 없으므로 스스로 자신이 원하는 것을 찾아내어야만 한다. 즉, 정보의 분석을 위해 필요한 원료(소스, 데이터)를 얼마나 체계적이고 효율적으로 관리할 수 있느냐에 대한 문제는 전적으로 데이터웨어하우스가 아쉬워할 부분이다. 그러나 다량의 정보 소스는 OLTP에 너무나 넓게 흩어져 있고, 그들간의 오묘한 관계는 깊이 숨어 잘 드러나지 않기 때문에 이를 명확하게 재조명한다는 것은 그리 쉬운 일이 아니다. 그럼에도 불구하고 대용량의 데이터를 처리해야만 한다는 점과 툴이나 DBMS에게 많은 것을 맡겨야 하는 데이터웨어하우스의 메커니즘적인 특수성 때문에 최대한 단순명료해야 한다는 것이 쉽지 않은 해결 과제일 것이다. 사실 실전에서는 전사적인 OLTP를 모두 분석해야 하며, 미래를 감안한 종합적인 데이터 인프라가 되도록 해야 한다는 것이 너무 어려운 과제다. 그렇다 보니 대부분의 업체에서는 위의 3가지 원칙이 잘 지켜지지 않고 있다. 종합적인 분석을 해서 미래를 내다보는 전략적인 결정을 할 자신이 없다 보니 일단 OLTP의 모든 트랜젝션을 자신의 스테이징(Staging) 영역에 임시로 보관해 둔다. 여기서 현재 사용자가 보고자 하는 일부의 정보들만으로 목적DB를 만들어 일단 급한 불(사용자들의 기본적인 욕구)부터 꺼보자는 정도로 데이터웨어하우스를 구현한다. 물론 기존에 감안되지 않았던 새로운 요구사항이 들어오면, 덮어놨던 스테이징 영역에서 데이터를 꺼내 가공해 오는 일을 추가한다. 스테이징 영역에는 모든 데이터가 어딘가에는 흩어져 있으니 별로 문제가 되지 않는 것처럼 보일 수도 있다. 그러나 이러한 방식으로 구현한 것은 엄격하게 말한다면 전사적 데이터웨어하우스(EDW)가 아니라 데이터 마트에 불과하다. 잠시 머물렀다가 사라져 버리는 저 스테이징 영역이 우리의 데이터 인프라인 것은 더욱 아니다. 이러한 접근 방법은 필요한 것만 선별하여 만들었기 때문에 첫 번째 원칙인 전체적인 ‘통합’의 원칙을 무시했고, 날이 갈수록 새로운 요구를 반영하느라 자꾸만 중복된 집합이 생성되기 때문에 ‘단순’의 원칙을 지키지 못했으며, 장기간 숙성시켜야 할 데이터들이 증발되어 버리고 있기 때문에 ‘장기’의 원칙도 무시하고 있다. 물론 당장에야 사용자들이 원하는 것들을 보다 어렵지 않게 제공할 수가 있으니 걱정할 것이 없는 것처럼 보이지만, 나중에 가서는 반드시 몇 배로 그 대가를 지불해야 한다. 데이터는 물이 강을 흘러 바다로 들어가는 것처럼 한 번 흘러가면 다시 주워 담기가 어렵다. 오랜 기간 숙성이 되어야 값비싼 양주가 될 수 있듯이 진정한 고급 정보는 장기간의 데이터를 활용해야만 얻을 수 있다. 지금까지 우리가 보았던 분석정보는 앞으로 나타날, 논리적으로 존재할 수 있는 모든 의미있는 정보에 비한다면 극히 일부분에 지나지 않는다. 이 말은 곧 사용자들의 견물생심은 날이 갈수록 증가하게 될 것임을 의미한다. 산업이 발전하여 생활에 여유가 늘어날수록 더욱 고상한 문화를 찾게 되는 것처럼 앞으로는 더욱 종합적이고, 고난이도의 분석정보를 원하게 될 것이다. 그때 가서야 이를 위한 소스정보가 제대로 유지되지 않고 있었다는 것을 알게 된다면 너무 늦다. 사과가 먹고 싶다고 이제 와서 사과나무를 심으려 한다면 앞으로 몇 년을 기다려야 하는 것과 같은 이치다. 이렇게 하고서도 경쟁에서 승리할 수 있다고 생각한다면 그것은 너무나 안이한 생각일 것이다.데이터웨어하우스는 데이터가 생명이다. 그 데이터는 하늘에서 떨어지는 것이 아니라 OLTP를 젖줄로 해서 태어난다. 그렇다면 원천이 되는 OLTP를 완벽하게 알지 못하고 만들어진 데이터웨어하우스가 정상적인 모습이 될 수 없다는 것은 당연하다.조금 엉뚱한 예를 든 것 같기는 하지만, 산과 들에 자라고 있는 산나물을 OLTP의 데이터라고 생각하고, 본격적인 재배에 들어간 비닐 하우스를 데이터웨어하우스로 생각해 본다면 명심해야 할 것들을 분명히 알 수 있다. 자급자족을 하는 정도에 만족하려는 입장이라면 비닐 하우스에 재배를 하는 것은 시간과 비용이 많이 든다. 그저 현재 필요한 정도를 얻는 것에 문제만 없다면 만족할 것이다. 미래에 욕심이 없는 사람이라면 지천에 산나물이 어떻게 자라고 있는지 소상하게 파악할 필요도 없고, 지금까지 먹어보지 못했던 나물에 대해서는 더욱 고민할 필요가 없다. 이처럼 현재의 사용자 요구를 수용할 정도만 OLTP나 혹은 스테이징 영역에 가서 데이터를 수집해 온다면, 당장의 요구는 해소할 수 있으므로 별반 문제가 없는 것처럼 보일 수 있다, 물론 마치 이렇게 살아도 만족한 인생을 살 수 있는 사람들처럼 더 이상의 발전에 대한 욕심이 없다면 이것을 나쁘다고 할 수는 없을 것이다. 그러나 우리가 수행하는 프로젝트는 어디까지나 영리를 목적으로 하는 사업체이므로 결코 그렇게 할 수는 없는 노릇이다. 비닐 하우스라는 개념이 없었던 시절에는 비록 채취를 해서 먹었지만 이제는 전략적으로 잘 구성된 비닐 하우스에서 차원이 다른 접근을 해야 할 시점이 온 것이다. 우리가 직접 재배를 해야 한다면 과거에 비해 훨씬 구체적이고 체계적인 전략을 가지고 접근해야만 한다. 지금 당장 먹을 것이 아니더라도 미리 재배해 두어야 한다. 작물을 잘 선택해야 하고 파종할 시기와 재배할 양과 판로에도 신경을 써야 한다. 다시 말해서 관련된 많은 사항에 대해서 구체적인 파악을 하고 있어야 한다는 것이다. 비닐 하우스에서 조차 이러할 진대, 최첨단의 컴퓨터를 기반으로 한 정보시스템이 주먹구구식일 수는 없다. 데이터웨어하우스는 자신의 형태를 결정하기 전에 무엇보다도 먼저 자신의 기반이 되는 OLTP의 데이터부터 정확히 파악하는 것이 순서이다. 데이터 소스의 중요성에 대해 너무 강조한다고 해서 데이터웨어하우스를 활용하는 사용자의 요건정의를 무시해도 좋다는 것은 결코 아니다. 다만 여기서 강조하자는 것은 현재의 요건정의만 가지고, 마치 들에 가서 필요한 만큼만 산나물을 캐어 오는 것처럼 데이터웨어하우스를 만들어서는 안 된다는 것이다. 사용자 요건은 반드시 필요하다. 마치 비닐 하우스를 짓는 사람들처럼 자신이 재배한 작물이 누가, 얼마만큼, 언제 필요한 지를 조사하고 여기에 따른 전략적인 고민을 해야 하는 것과 같다. 사용자 층이나 그들의 요건은 시간이 지남에 따라 변하기 때문에 우리가 여기에 일희일비를 하지 않으려면 보다 근본적인 대책을 강구해 둬야 한다. 그 대책은 다름아닌 정보의 재료가 되는 데이터를 전략적으로 보존해 두는 것이다. 물론 이를 위해 해야 할 가장 중요한 일은 데이터의 근본이 되는 OLTP를 정확히 파악하는 것이다. 이런 의미에서 제대로 된 데이터웨어하우스를 구축하기 위해서는 OLTP의 데이터를 반드시 정확하고 구체적으로 아키텍팅할 필요가 있다. 앞서 만약 여러분이 OLTP의 데이터 아키텍처를 정확히 수립하였고, 그것이 논리화를 거친 논리적 모델이라면 이미 70% 가량 우리의 EDW 모델에 근접해 있다고 하겠다. 이 논리적 모델을 바탕으로 데이터웨어하우스의 원칙인 ‘통합, 단순, 장기’의 개념을 최대로 승화시킨 모델을 구현해 가는 것이 가장 이상적인 방법이다. 만약 여러분들이 EDW 데이터 모델을 확정해 가는 단계에서 참고를 해도 좋을 만큼 수준 높은 참조 데이터 모델을 확보했다면 이를 활용하는 것도 바람직한 방법이 될 수 있을 것이다. EDW가 크게 확산되면서 최근에는 업종별로 이러한 참조모델을 전문적인 제품으로 제공하는 업체가 늘어나고 있다. 다만 한 가지 걱정되는 것은 이들의 참조모델을 확신한 나머지 여기에 단지 곁가지 정도만 보완한다면 완전한 우리의 EDW 데이터 모델이 될 수 있다고 믿을 수 있다는 점이다. ‘템플릿 이용한 EDW 구축’이라고 하는 이런 형식으로 접근하는 경우가 종종 있는데, 필자는 그다지 권고하지 않는 편이다.이 세상의 어떤 기업도 유사업체와 완전히 동일할 수는 없다. 사업의 본질은 거의 유사할 수도 있겠지만 결코 그 기업의 환경, 문화, 비전까지도 모두 동일할 수는 없다. 물론 아무 것도 없는 상태에서 완벽한 것을 고안해 낸다는 것은 어렵기 때문에 유사한 어떤 것을 참조하면서 자신의 것을 결정해 가는 방법은 충분히 고려해 볼 수 있는 좋은 접근 방법임에는 틀림없다. 그렇지만 자신의 것을 찾기 위해 필요한 만큼만 참조를 하는 것과, 이미 만들어진 것을 몇 군데 손질하여 만들자는 것은 다르다. 만약 데이터웨어하우스의 기반이 되는 OLTP의 모든 데이터에 대해 매우 상세한 아키텍처를 수립하였고, 이를 바탕으로 모델링한 EDW 데이터 아키텍처 또한 상세하게 수립되어 있다면 이들 간에는 ‘집합 대 집합’ 간의 매핑룰이 존재하게 된다. 이 매핑룰이 바로 ETL(Extraction, Transformation and Loading; 추출, 변환, 탑재)의 알고리듬이 된다. OLTP도 데이터의 집합이고, EDW 또한 데이터의 집합이므로 이들간의 전환은 결국 ‘집합 간의 매핑’으로 볼 수 있다. 이것을 지금까지 DB 마이그레이션을 할 때 적용해 왔던 방식처럼 일일이 사례별로 다루어 알고리듬을 생성한다면 엄청난 경우의 수가 발생함은 물론, 오류나 누락이 증가할 뿐만 아니라, OLTP의 설계에 변화가 발생했을 때 유지보수를 하는 일도 매우 어려워질 것이다. 데이터웨어하우스에서 가장 우리를 괴롭히는 것 중의 하나는 상상을 초월하게 발생되어 있는 소스 데이터의 오류를 어떻게 말끔하게 정제할 수 있는가에 대한 문제이다. OLTP시스템의 잘못으로 인해 앞으로도 계속 생길 수 있는 문제를 미리 찾아내 원인을 봉쇄하는 것도 커다란 걱정거리라 하겠지만 과거에 무원칙하게 발생되었던 – 특히 개발자가 특정 목적을 위해 함부로 데이터를 훼손시켰던 – 것들까지도 제대로 복원하려는 것은 상당히 어려운 일이다.오류 데이터를 어떤 기준으로 보정할 것인지를 결정하는 것도 어려운 일이겠지만 도대체 어떤 유형의 오류 데이터가 존재하고 있는지를 찾는 것은 더욱 어렵다. 더구나 집합에 대한 명확한 정의, 즉 데이터 모델의 상세한 정의가 되어 있지 않다면 무엇이 오류인지 조차 판단할 수 없다. 여기서 말하는 오류 데이터란 단지 어떤 속성에 들어 있는 값이 규칙을 지키지 않았다는 정도만을 의미하는 것이 아니다. 자기 엔터티 내의 각종 업무규칙을 준수하는 것은 물론이고, 연결된 상하의 다른 엔터티와의 상호 간에 준수되어야 할 복합적인 업무규칙을 모두 의미한다. 실전 프로젝트에서 개발자들이 오류 데이터 유형을 충분히 도출했고, 이것을 거의 정제했다고 자신하고 있는 것을 다시 복합적으로 분석했을때 많은 오류들이 드러나는 경우가 많다. 그들이 이러한 오류를 미처 발견할 수 없었던 이유는 단지 속성 값을 체크하는 정도에만 그쳤고, 무엇을 체크해봐야 하는지 정확히 알지 못했기 때문이다. 이런 이유로 인해 수 많은 데이터웨어하우스가 구축되어 있기는 하지만 진정 장기간의 데이터를 제대로 깨끗이 정제하여 탑재해 둔 곳을 찾기가 매우 어려운 것이다. 그저 몇 개월, 길어야 1~2년 정도의 데이터를 탑재했을 뿐이다. 이제 많은 노력을 기울여 체계적인 모습으로 잘 정비된 데이터웨어하우스는 이 데이터를 소스로 헤 생성하는 다양한 목적 시스템(데이터 마트, 각종 전문가 시스템 등)으로 데이터를 공급한다. 일반적으로 이런 유형의 시스템은 매우 다양하게 존재하고, 계속적으로 증가하는 특성을 가지고 있다. 물론 이러한 시스템을 통해 많은 활용을 하도록 하는 것이 바로 데이터웨어하우스가 존재해야 하는 본래의 목적인 만큼, 날이 갈수록 확대되어야 하는 것은 지극히 당연하다. 이렇게 확장되는 목적 시스템은 그 데이터 기반이 데이터웨어하우스이므로 이들 간에도 결국 ‘집합 대 집합’ 간의 매핑으로 연결할 수 있다. 만약 목적 시스템의 데이터 아키텍처까지도 제대로 수립하고 있었다면, 이들 간의 데이터 인터페이스 또한 매우 명확하고 쉽게 정의할 수 있었을 것이며, 단순한 유지보수가 가능했을 것이다. 이처럼 데이터웨어하우스 뿐만 아니라 그 뒷단의 목적 시스템에 대해서도 데이터 아키텍처를 정확하게 수립한다면 이것이 바로 가장 높은 품질의 시스템을 가장 단순명확하게 관리할 수 있는 유일한 방법이라 할 수 있다. 거듭 강조하거니와 데이터웨어하우스는 결국 데이터를 다루고자 하는 시스템이므로 OLTP와는 달리 소수의 유능한 데이터 전문인력 위주로 구축하고 관리하는 것이 바람직하다. 대용량의 데이터를 다양하고 복잡한 가공을 통해 높은 가치의 정보를 생성해야 하기 때문에 데이터와 데이터베이스에 일가견이 있는 전문인력을 육성하거나 확보하는 것을 가장 우선적인 과제로 삼는 것이 필요하다. @