데이터웨어하우스를 도입하는 것은 만만하게 볼 수 있는 작업이 아니다. 기존까지의 경험 대부분이 데이터웨어하우스 고유의 요구사항과 문제점을 해결하기에 적합치 않기 때문이다. 평소에 흔히 해오던 일이지만 데이터웨어하우스를 기반으로 작업할 때 주의해야 할 몇 가지 사항들에 대해 살펴 본다.

다음 일곱가지 항목들을 보면 일부는 꼭 필요한 것일까 의아해 할 수도 있다. 그러나 데이터웨어하우스는 특정 기준에 부합하거나 특정한 애플리케이션을 실행하기 위한 트랜잭션 시스템이 아니라, 본질적으로 매우 유기적인 시스템이다.

특히 데이터웨어하우스를 구축하는 기업마다 사례가 각기 다르고, 실제 작업 과정에서 각 기업에 알맞는 새로운 방법론을 찾을 수도 있다. 이때 가장 효과적인 방법은 비효과적인 방법을 제외하는 것이다. 다음은 이처럼 최선의 방법을 찾을 때 진지하게 고려해야 사항들이다.

1. 쉽게 수정할 수 없는 코드는 사용하지 말라
기업들이 애플리케이션을 도입할 때 중요한 것은 트랜잭션에 관한 것이 아니라 분석학(analytics)적인 것이다. 일반적으로 데이터웨어하우스 프로젝트는 애플리케이션을 사용할 당사자 조차 자신이 무엇을 원하는 지 정확히 알지 못한다. 따라서 전체 프로젝트를 진행하면서 몇 가지 작업을 반복해서 다시 처리해야 하는 경우도 발생할 수 있다. 이 때 만약 잘 구성된 유연한 코드를 이용했다면 코드를 수정해야 할 상황에서도 무리없이 일을 처리할 수 있다. 전자식(fly-by-wire) 코드를 이용하면, 반드시 후회하게 될 것이다.

2. 수정이 불가능한 데이터베이스 액세스 API는 이용하지 말라
과거의 데이터베이스 작업은 잠재적인 다수의 사용자들이 적절한 양의 데이터에 접속할수 있는 애플리케이션들을 모으는 것이어다. 그러나 현재에 이르러서는 방대한 데이터를 수집하는 애플리케이션을 관리하는 것으로 바뀌었다. 이런 환경에서는 각 읽기 작업마다 최대의 데이터 양을 얻을 수 있는 코드를 작성해야 하며 이는 한번에 수행하기에는 힘들다. 따라서 기업들은 재빠르고 신속한 수정이 가능한 툴을 선택할 필요가 있다.

3. 확장할 수 없는 것은 설계하지 말라
분석학은 온라인트랜잭션프로세싱(OLTP) 애플리케이션과 본질적으로 다르다. 분석학적 방법의 핵심은 오랫동안 축적한 방대한 데이터 내부의 패턴을 발견하고 이로부터 새로운 정보를 도출해 내는 것이다. 이 때 기본 정보에 접근하는 코드는 부가 정보를 포함하는 확장형이 될 가능성이 있다. 그러나 이는 별도의 '연결 작업'이 필요하므로, 추가 작업의 가능성이 있는 반(反)분석학적 코드는 사용하지 않는 것이 바람직하다.

4. 데이터와 사용자 사이에 불필요한 것은 끼워넣지 말라
데이터웨어하우스는 고객이 원하는 정보를 정확하게 산출하는 것이다. 사용자는 웨어하우스에 접속해 정보를 추출할 수 있어야 하며, 이러한 비즈니스인텔리전스(BI), 분석학 그리고 매트릭스의 특성상 처리 성능을 측정할 수 있는 평가 기준을 필요로 한다. 또한 사용자들은 그 데이터가 무엇이든지, 분석하고자 하는 데이터를 선별해 선택할 수 있는 작업 환경을 요구한다. 따라서 개발자는 이런 요구를 모두 만족시킬 순 없지만 최선을 다해야 한다. 사용자의 분석 애플리케이션이 웨어하우스 데이터에 엑세스하는데 방해가 되는 것이라면 그 무엇이든 끼워넣지 마라.

5. 데이터 정리와 소스 분석에 지름길은 없다
프로젝트를 진행하며 당신이 마주치게 될 가장 큰 문제는 아마도 추출-전환-호출 매커니즘 과정 동안 데이터 소스를 분석하는 것과 호출을 위해 데이터를 정리하는 것이 될 것이다. 현명한 프로젝트 매니저라면 여기에 전체 프로젝트 리소스의 절반 이상을 투입하는 것이 안전하다. 어리석게도 지름길을 택하고자 한다면, 훗날 십중팔구 이 때문에 난관에 봉착할 것이다. 번거로운 작업처럼 보이지만 지저분한 데이터를 정리하는데 드는 수고를 아끼지 말라.

6. 입자성과 파티션 관련 문제를 피하지 말라
데이터웨어하우스 설계와 관련해서 가장 화제가 되는 데이터 스토리지 이슈는 변환된 데이터를 적절한 입자성(granularity) 수준에 위치시키는 것과 카테고리 면에서 데이터 파티션을 어떻게 할당할 것인가 등이다. 이것이 중요한 이유는 전체 웨어하우스 크기가 입자성에 대응해 기하학적으로 변동하고, 데이터 액세스 효율성이 파티션 작업의 효율성에 비례하기 때문이다. 이것은 어렵고 또 불평이 나올만한 작업이지만 동시에 필수불가결한 것이기도 하다. 이 작업을 회피하려고 하지 말라.

7. 비즈니스 문제를 고려하지 않은 채 OLAP 작업을 시도하지 말라
고객들은 실제 결과물을 볼 때까지 어떤 애플리케이션을 원하는지 정확히 알지 못한다. 그들의 부서 또는 기업이 비즈니스 방식에 변화를 줄 만한 중요한 실행 매트릭스나 전망을 담은 분석학적 결과치를 산출하고자 할 때는 수많은 오류가 발생할 수 있다. 따라서 프로젝트 담당자가 사용자들의 부서는 물론 기업이 전반적으로 어떻게 움직이는지 가능한 한 많은 것을 파악해 놓지 않는다면, 프로세스 개선에 기여하거나 사용자의 실수를 방지할 수 있는 기회를 놓치게 된다.

전통적인 OLTP 개발에서는 비즈니스의 밑그림을 작성하는데 당신 주변의 것들에 이용할 수 있었다. 그러나 온라인 분석학적 프로세싱(OLAP)에서는 모든 것에 차이가 있으며, 주변의 사람들이 담당자의 오해에서 비롯되는 잘못을 반드시 지적할 의무는 없다. 따라서 당신이 할 수 있는 것 이상을 알고 있다고 섣부르게 단정하지 말라. 오히려 사람들에게 당신이 비즈니스 인텔리전스에 있어서 비즈니스를 어떻게 다뤄야 하는지를 명확히 알고 있음을 보여줄 수 있는 추가 보충 질문을 던져라. @