막연한 기대심리ㆍ요구사항이나 리스크 분석 무시ㆍ벤더에 올인 등
본지와 특약을 맺고 있는 <인포메이션위크>는 "확장성이 향후 데이터 웨어하우스 구축의 성패를 좌우한다"면서 "데이터의 다면적인 성장을 고려해 데이터 웨어하우스의 아키텍처와 투자규모를 결정해야 한다"고 강조했다. 그리고 데이터 웨어하우스의 확장성을 저해하는 요인으로 다음과 같은 7가지를 거론했다.
1. 확장성을 위한 테스트용 시스템이 완비될 때까지 기다리기
성능과 확장성 테스트를 실행하기까지 너무나 오래 기다려야 하기 때문에 겪는 '유혹'에 해당된다. 시스템이 생산 현장에 적용될 때까지 기다리는 데에 함정이 있다. 실제 데이터베이스와 애플리케이션을 구동할 수 있기 때문에 테스트를 건너뛸 수 있다고 생각하지만 무언가 잘못된 것이 발견될 경우 손쓰기에 너무 늦을 수가 있다. 실행하기 전에 충분한 확장성 테스트를 해봐야 한다.
2. 막연한 기대 심리
아무런 요구 사항이 없을 경우 실패를 입증할 수 있는 방법이 없다. 또한 모든 기대에 부합되지 못할 경우 시스템이 충분치 않은 것으로 판단해서도 안 된다. 기대치는 확실하게 정립해야 하며 현실적으로 수립해야 한다.
3. 요구 사항 건너뛰기
사용자들은 요구 사항이 무엇인지 모르는 경우가 많다. 새로운 비즈니스 프로세스와 이를 지원하는데 필요한 요구 사항에 대해 시각화해서 직원들에게 보여주어야 한다. 그런 다음에야 유효한 활용 시나리오와 엔지니어링 요구 사항을 만들 수 있다.
4. 리스크 분석 건너뛰기
요구 사항을 개발했다면 리스크를 규명하고 테스트하며 관리해야 한다.
5. 벤더에게 모든 것을 맡기기
벤더가 테스트에 대한 정의를 내리지 못하도록 해야 한다. 내부에 전문가가 없다면 복잡한 데이터 관리 시스템 테스트를 위한 벤치마크 스펙을 정의해본 경험이 있는 컨설턴트를 고용하라.
6. 성장률 과소평가하기
올해의 요구 사항만으로는 충분치 않다. 프로젝트 요구 사항은 2~3년 앞을 내다보고 결정되어야 하며 데이터와 워크로드의 성장률은 예상보다 훨씬 높다는 점을 간과해선 안 된다.
7. 확장성의 특정 부분 무시하기
데이터 크기는 측정하기에 가장 쉬운 부분에 해당되지만 워크로드나 데이터의 복잡성, 쿼리의 복잡성과 가용성, 데이터 지원 부분은 그 중요성만큼 측정하기가 불가능하다. 이런 부분을 감안해 적절한 플랫폼을 선택해야 한다.
InformationWeek USA
webmaster@itdaily.kr