IT 프로젝트가 실패하는 10가지 이유 (그리고 실패하지 않는 방법)

저자: Dale Defilippi

함정 1: 헌신의 결여
스스로 자신의 프로젝트에 열정이 없다면 다른 사람들이 이 프로젝트에 열정을 가질 수 있을까요? IGT의 고위 경영진은 대규모 프로젝트에 자금을 투자하기 전에 개개인의 보증을 요구했습니다. 저는 이 프로젝트의 성공에 내 명성과 내 직업까지 걸었습니다.

함정 2: 타협하지 않음
타협해야 할 문제, 특히 예산에 관련된 문제에 부딪혔을 때는 타협점을 찾으십시오. 예를 들어, 우리는 원격 DR 사이트에서 값비싼 고급 파이버 채널 어레이로 복제하는 대신 보다 저렴한 아키텍처를 추천했습니다. 속도는 다소 느리지만 주요 사이트에서 운용 서버로 사용했던 서버들을 재사용하기로 결정하고 파이버 채널 대신 SATA 디스크를 사용했습니다. DR을 구현하는 데 주요 데이터 센터에서 지출한 비용의 1/3 밖에 안들었다는 사실이 경영진에게 알려지자 일은 훨씬 쉬워졌습니다.

함정 3: 능력 과대 평가
비전은 크게 갖되 비전 수행을 도와줄 수 있는 전문가를 초청하는 것을 두려워하지 마십시오. 우리는 우리 IT 팀만으로는 이러한 대규모의 프로젝트를 완수하기가 불가능하다는 것을 깨닫고 전문 서비스 조직에 도움을 요청할 계획을 미리 세워 두었습니다. 그래서 SAN 관리에서부터 VERITAS 제품으로 백업하는 것까지 광범위한 지식을 갖춘 매우 숙련된 그룹을 구성할 수 있었고, 프로젝트 계획, 준비 그리고 실제 구현까지 도움을 받았습니다.

함정 4: 공급업체 신뢰
공급업체를 항상 100% 신뢰할 수 있는 것은 아니라는 현실을 직시하십시오. 공급업체가 약속한 사항을 실제로 지킬 수 있는지 항상 입증해 보이도록 해야 합니다. 먼저 우리는 처음에 선정한 18개의 업체를 세 개 회사로 줄인 다음, 업체에 철저한 개념 증명 방식(proof of concept)을 수행하도록 3주를 주었습니다.
저는 개인적으로 각 업체를 방문하여 우리가 있는 자리에서 우리 회사 데이터의 서브셋을 가동하고 모든 데이터베이스에서 실행하여 파일을 공유하는 것을 보여줄 것과 그 데이터를 복제하고 실패할 경우 Failover하는 것까지 입증하도록 요청했습니다. 이 과정에서 한 제공업체는 포기했고, 또 다른 제공업체는 요구 사항의 2/3 정도를 완수했으나 DR 사이트에서 SAN을 부팅하지 못하고 Oracle�� 데이터베이스를 완벽하게 복구해내지 못했습니다. NetApp은 영업팀에서 기한 내에 완수할 수 있다고 약속한 대로 모든 작업을 해낸 유일한 업체였습니다.

함정 5: 비현실적인 일정과 기대
종료일이 촉박할 경우 처음부터 일정에 여분의 시간을 넣거나 첫 구축 단계에서 보다 복잡한 요구 사항을 빼도록 해보십시오. 저는 마감 시한을 30% 연장하거나 적어도 PO를 더 일찍 마감할 수 있기를 바랬습니다. 사실, 프로젝트를 수행하는 동안 몇몇 분들이 무척 고생했고 우리가 원하는 방식대로 SAN에서 부팅하려는 과정에서도 어려움을 겪었습니다. 2003년도에 우리는 거의 최초로 NetApp 스토리지를 사용하여 SAN을 부팅하는 작업을 해냈습니다. 그 과정이 얼마나 복잡한 것인지 일찍이 알았더라면 아마 그 끔찍한 신기술 구현을 끝까지 미뤘을 것입니다.
“비전은 크게 갖되 비전 수행을 도와줄 수 있는 전문가를 초청하는 것을 두려워하지 마십시오.”

함정 6: 로드맵 없는 항해
이 같은 프로젝트를 시작하기 전에 안팎으로 얼마나 인프라가 복잡한지 알고 있어야 합니다. 각 어플리케이션이 운영 체제 및 디스크 스토리지 하위 시스템과 어떻게 상호 작용하는지와 네트워크 I/O를 어떻게 처리하는지 확실히 파악해야 합니다. DR 구현을 시작하기 전에 그 두 측면에 대해 발생할 수 있는 잠재적인 문제에 대해 알아보십시오. 드라이브와 데이터를 한 지점에서 다른 지점으로 옮기는 작업을 시작할 때 고객은, OS와 어플리케이션에 대해 직접 연결된 스토리지에서 새로운 SAN으로 이동하는 과정이 잘 진행되고 있는지 확인할 수 있기를 원합니다. 우리에게도 5~6개월 동안 내부에 있던 모르는 시스템이 있었고 복제 방법을 이해하는 데 시간이 너무 오래 걸려서 프로젝트 마지막 주까지도 그 시스템을 파악하지 못했습니다.

함정 7: 예기치 않은 상황이 발생할 수 있음을 예측하지 못함
프로젝트가 전개되는 동안에는 변함없이 창조적인 자세와 임기응변이 필요합니다. 즉, 예기치 않은 상황이 발생할 수 있음을 예측해야 합니다. 마지막 주에 우리는 대기 시간에 문제가 있고 패킷 전송이 너무 느려서 두 사이트 간에 미러링을 효과적으로 완료할 수 없다는 사실을 알게 되었습니다. 대역폭은 충분했으나 서비스 제공자의 WAN 라우팅의 물리적인 케이블에 한계가 있어 리노에서 라스베가스까지의 거리가 샌프란시스코에서 뉴욕까지의 거리보다 사실상 더 먼 거리로 인식되었습니다. 대기 시간이 평균 28밀리초여서 미러링 프로세스가 세 시간 이상 걸렸고 대역폭이 절반 이상의 사용되었습니다.
NetApp은 최소의 단서만 가지고 그 문제를 떠맡았습니다. 24시간 내에 우리는 타사 제공업체인 Peribit Networks에서 제공한 평가 장비를 테스트했고 NetApp의 도움으로 WAN을 경유하는 대기 시간을 줄일 수 있었습니다. 이렇게 하여 미러링 문제는 바로 해결되었습니다. 이러한 경험을 통해 제공업체가 자력으로 모든 일을 하려는 것보다는 다른 동종 업계 최고의 회사들과 협력할 때 이익을 얻을 수 있다는 사실을 다시 한 번 깨닫게 되었습니다.

함정 8: 현실 적응 실패
프로세스 작동 방식을 이론화하는 것과 실제 운용 환경에서 그 프로세스가 작동하는 것을 지켜보는 것은 서로 다릅니다. 새로운 사실이 밝혀졌을 때 초기 운영 절차를 변경하는 것을 두려워하지 마십시오. 처음에 두 사이트 간에 미러링을 설정할 때 우리는 90분에서 120분 간격으로 미러링을 수행할 계획이었습니다. 그러나 미러링은 Snapshot™ 복사본 간에 변경된 데이터 양으로 인해 예상했던 것보다 느렸습니다. 약 10% ~ 15%의 델타가 나타날 것이라고 예상했지만 실제로는 변경된 바이트에서 30% ~ 40%의 더 많은 델타가 나타났습니다.
성능을 개선할 수 있는지 확인하기 위해 미러링 간에 간격을 두고 실험하기로 결정했습니다. 먼저 미러링 간격을 한 시간까지 줄이자 거의 같은 대역폭을 사용할 때 성능이 나아지는 것을 확인할 수 있었고 15분마다 시도하자 성능은 더 나아졌습니다. 어느 주말에는 간격을 줄여 매 분 미러링해 보기도 했습니다. 이렇게 하자 대역폭 증가 없이 약 7분 내에 데이터가 전송되었습니다. 지금은 약 7TB의 데이터를 단 7분 간격으로 활성 사이트와 복제되는 사이트 간에 계속 동기화하고 있습니다.

함정 9: 테스트 실패, 테스트 그리고 또 테스트
계속적인 테스팅, 특히 DR 구현의 경우 테스팅의 중요성을 과소 평가하지 마십시오. 데이터가 필요할 때 액세스할 수 있는지 파악해야 합니다. 첫 미러링을 실행한 후 시스템 전원을 켜고 DR 사이트에서 시스템을 작동할 수 있는지와 복제중인 데이터가 도중에 손상되지 않았는지 확인하고 싶어할 수 있습니다. 우리는 분기마다 Failover 테스트를 실행하며, 감사관들이 솔루션을 살펴보고 이 솔루션이 계속 제대로 작동하는지 확인할 수 있도록 추가로 일년에 한 번씩 감사관들의 참석하에 테스팅을 진행합니다.

함정 10: 솔루션을 대신할 임시 방편 찾기
스팟 솔루션의 문제는 몇 달 내에 또 다른 임시 방편을 찾아야 한다는 것입니다. 대부분의 기술은 구현하고 2년이 지나면 교체해야 하는 경우가 잦지만, 우리가 구현한 유연성 있는 아키텍처는 앞으로 한 동안 우리 기술을 지원해줄 것이라고 확신합니다. 이제부터 이 아키텍처를 어디에 사용할 것인지에 대해서도 많은 아이디어를 가지고 있습니다. 우리는 초기 구현 후 스토리지 용량을 거의 세 배로 늘렸습니다. 또한 최근에는 개발을 위해 운용 환경을 즉시 복제할 수 있도록 Data onTAP™ 7G로 업그레이드했습니다. 매우 가치있는 일이었습니다. 이전에는 데이터베이스를 복제하는 데 몇 시간이 걸렸지만 이 업그레이드를 통해 시간을 많이 절약할 수 있게 되었습니다. 전체적으로 살펴볼 때, NetApp은 매우 인상적인 기술을 보유하고 있으며 이 기술을 적용할 수 있는 분야는 무궁무진합니다.