CIO를 위한「데이터웨어하우스 구축 프로젝트 7계명」

데이터웨어하우스(DW)는 전통적인 관계형 데이터베이스 관리 시스템(RDBMS)의 형제뻘이다. 그러나 둘 사이를 아무리 미화한다 해도 할 수 있는 말은 그저 약간 닮았다는 것 뿐이다. 만약 이전에 DW를 구축한 경험이 없다면 DW 구축 프로젝트를 진행하면서 매우 색다른 경험을 하게 될 것이다.목표 설정부터 설계완성까지, 데이터 구조 생성부터 최악의 사용자 인터뷰 분석문 작성까지 모든 부분이 이전과 전혀 다르다. 즉 RDBMS와 관련해 쌓아왔던 기존 방식을 고집한다면 예산 초과는 물론이며 프로젝트 실패가 불보듯 뻔하다는 말이다.DW 프로젝트를 진행할 때 금기시되는 목록은 분명 존재한다. 그러나 프로젝트를 매끄럽게 운영할 수 있는 바람직한 예비단계도 있기 마련이다. 새로운 아이디어에 개방적인 자세를 가져라. 그리고 새로운 사고방식에 적응하기 위해 기존의 안전 제일주의 관행을 뒤엎는다는 각오를 다져라.1. 전담 프로젝트 매니저(PM)를 둬라, 아니면 직접 전담 매니저로 나서라PM들이 동시에 여러 프로젝트를 관리하는 것은 흔히 볼 수 있으며 또한 피할 수 없는 일이기도 하다. 그러나 DW를 구축할 때는 이런 생각 자체를 하지 말아야 한다. 당신과 당신 휘하의 팀은 지금 전혀 경험해보지 못한 새로운 영역에 발을 들여놓고 있기 때문이다.분석, 설계, 프로그래밍, 테스트, 수정, 관리에 이르기까지 모든 작업이 새로울 것이다. PM은 ‘도전’ 의식에 고취되고 이 상태를 계속 유지할 때 프로젝트의 성공 확률이 높아질 것이다.2. 프로젝트 단계별로 담당 팀을 바꿔라각 DW 구축 단계는 너무나 다르기 때문에 한 단계를 완수한 다음에 다른 PM에게 인계해도 전혀 문제가 없다. 물론 1번 규칙을 따른다는 가정 하에서.왜 문제가 없는가? 먼저 DW 구축 프로젝트의 모든 단계별 작업은 PM 입장에서 볼 때 진이 빠지는 일이다. 게다가 물리적인 스토리지 시스템의 설치부터 시작해 ETL(Extract-Transform-Load)의 구현까지, 그리고 스키마의 설계와 개발부터 OLAP에 이르기까지 DW 구축의 각 단계는 서로 너무나도 다르다.관리적인 측면에서도 각 단계는 신규 인력으로도 충분히 수행될 수 있을 뿐 아니라 새롭게 창조적으로 접근하는 것도 가능하게 된다. 단계마다 각각 다른 팀을 배정하는 것은 반드시 나쁜게 아니라 오히려 도움이 될 수 있다.3. ‘사용자-마이닝’ 인터뷰를 제도화하라이 내용은 매우 중요하기 때문에 따로 설명해도 괜찮은 부분이다. DW 설계 단계로 진입할 때 DW를 사용할 사람들은 자신이 뭘 원하는지 명확하게 알지 못한다는 사실을 명시하라.사용자 인터뷰를 통해 탐색, 발견 단계를 거치는 것은 필수다. 이 글을 보는 당신의 개발팀도 예외일 수는 없다. 인터뷰를 솔직하고 개방적인 분위기로 만들고 필기를 많이 하며 인터뷰 담당자들이 절차 자체보다 그 결과에 집중하도록 해야 한다.인터뷰의 목적은 어떤 데이터가 저장되고 어떻게 효율적으로 저장할 건지 아이디어를 얻기 위한 것이다. 따라서 사용자와 협력해 데이터를 처리하는 것이 아니라 ‘보는’ 새 방식을 찾아내야 한다.또한 수집 가능한 잠재적인 정보를 찾으려 노력해야 한다. 이것은 트랜잭션 데이터로부터가 아니라 그 뒷단에 존재하는 정보나 숫자의 변화로부터 얻어진다. 인터뷰에서 답을 구하려 말고 답이 스스로 찾아오도록 하라.4. 기술·정보의 보고인 리더를 선정하라리더들은 DW 구축 프로젝트에 전담할 필요까지는 없다. 그러나 DW 구축의 각 단계가 매우 상이하다는 사실을 고려해볼 때 연속성을 담보해줄 사람이 있어야 한다는 점은 분명하다. 여기에는 아키텍처, 기술, 사업이라는 세가지 주요 영역이 존재한다.아키텍처 담당 리더는 물리적인 수준부터 시작해 프로젝트 일정이 종결될 때까지 다들 합의한 DW의 아키텍처가 계속 유지되도록 하는 역할을 수행한다. 기술 담당 리더는 DW 프로젝트를 진행하는 개발팀과 주요 사용자들이 지금까지 사용해보지 못한 툴을 다뤄야 하기 때문에 반드시 필요하다. 이 사람은 툴 개발과 사용의 일관성을 감시하는 역할을 담당한다.마지막으로 DW 구축으로 달성될 사업상의 요구는 신중하게 감시되고 문서화돼야 한다. 그래야만 개발의 연속성이 보장된다. 또한 분석, 측정치들이 각 과정에서 얻어졌다 해도 서로 의사소통이 잘 되지 않은 채 시간 간격을 두고 개발이 진행될 수 있다. 따라서 개발 과정을 감시하고 연속성을 보장하며 작업 달성 수준을 더 높여줄 사업 담당 리더를 확보해야 한다.5. 반복 작업에 익숙해져라DW는 처음부터 완벽한 상태로 만들어질 수는 없다. 직접 보기 이전에는 진정으로 뭘 원했는지 알 수 없기 때문이다. 더 정확히 표현하자면 사용자들이 DW를 일정정도 사용해야만 그들이 정말로 뭘 원했는지 알 수 있다는 말이다.시행 착오, 반복 작업은 아마 당신이 사회생활 내내 해왔던 맹세와 대치될 것이다. 그러나 가야하는 길이다. 비즈니스 인텔리전스(BI)는 아직 초기 수준에 있을뿐더러 각 기업들끼리도 제각기 다르기 때문이다.제대로 된 DW를 만들려면 올바른 데이터를, 올바른 형식으로 담기 위해 끊임없이 노력해야 한다. 게다가 변화도 자주 진행될 것이다. BI는 아주 ‘개인적’인 성격이 있기 때문에 사업 환경, 시장, 협력 관계에 따라 매우 상이한 모습을 갖는다.이 말은 데이터베이스 관리자를 방에 가둬놓고 DW의 데이터 구조가 계속 바뀌고 또 바뀌고, 다시 한번 바뀌고, 또 바뀌며 ETL 프로시저도 마찬가지라는 사실을 말해줘야 한다는 의미다.그렇다고 해서 다른 대안이 있느냐? 절대 없다. 마음의 안정을 유지하는데 신경을 쓰고 당신과 데이터베이스 관리자가 받을 스트레스를 다른 형태로 풀도록 하라.6. 데이터 소스 분석에 기획에 배정된 자원의 투입을 아끼지 마라당신은 분명 원격지에 위치한 데이터 저장소의 낡아빠진 자기 테이프의 낡아빠진 데이터베이스의 낡아빠진 데이터의 바다를 허우적거리며 건너고, 또 건너고 할 것이다. 게다가 이 데이터들은 대부분 매우 지저분한 형태일 것이 뻔하며 온전한 상태로 추출해내는 것조차도 힘들 것이다.그러나 데이터 추출은 매우 빈번히 수행될 작업 중 하나다. 따라서 이런 종류의 데이터를 검색하고 추출하는 ETL 프로시저를 계속 고안하게 될 것이다. 그렇기 때문에 처음에 이를 위한 방식을 확립해 놓는 것이 모두에게 이롭다.개발팀이 낡아빠진 데이터를 완전히 분석해내고 데이터의 오염도 문제를 현실적으로 해결할 수 있도록 해야 하며 강력한 추출, 변환 프로시저를 완벽한 수준으로 설계, 구현하라. DW의 ETL 부분은 프로젝트에 할당된 전체 자원의 80%를 차지할 수도 있다. 자원을 현명하게 사용하라.7. 대인 관계를 우선순위에 올려라DW 구축에 있어 가장 곤욕스런 부분은 기술이나 개발이 아니라 사람 문제가 될 것이다. 관리자들은 완료 기한과 불투명한 목표에 불만을 제기할 것이며 개발팀들은 프로젝트 완료까지 긴 시간이 걸리는데도 왜 옛날 방식대로 할 수 없냐고 불평할 것이다. 설상가상으로 마우스 클릭은 잘하지만 현명하게 투자를 진행할 능력도 없고 비현실적인 기대에 꽉 찬 사용자들을 만나야한다.모든 수준에서 욕구를 수요로 변환시켜나가면서 당신은 점점 녹초가 돼갈 것이다. 현실을 이야기하고 투자를 독려하고 당신의 팀과 사용자, 심지어 상관에게까지도 새로운 기술을 습득하도록 교육하는 과정을 꿋꿋하게 거쳐낼 수 있도록 각오를 단단히 다져놓는게 좋다.무엇보다도 계속 미소를 지어라. 모든 것이 종결되면 당신은 마법과도 같은 재원을 갖게 될 것이며 슬픔은 이미 지난 과거가 될 것이다. 결국 미소는 자연스레 나오게 될 것이다. @