IT는 유명하건 그렇지 않건 매우 복잡하다. 대규모 프로젝트의 성공과 실패에는 수많은 변수들이 있다. 시간과 예산이 충분하다고 해서 성공작이 되는 것은 아니며 시간과 예산이 적다고 해서 반드시 실패하는 것은 아니다. ERP의 경우 CFO의 눈치를 보는 경우도 생기며 여기 저기 단점이 노출되어 회사 내부에서 ‘경질’의 압박을 받는 경우가 허다하다.

여기에서는 8대 기술 실패 사례를 짚어보고 이를 타산지석으로 삼고자 한다. 실패 사례는 단순한 애플리케이션 업그레이드의 잘못에서부터 전사적인 전략 실패로 낙인 찍히는 사례까지 다양하다. ‘업계 최초’라는 말에 집착한 나머지 조급하게 서둘러 구축해 돌이킬 수 없는 결과를 초래하는 경우도 있으며 도입해놓고는 사용은 전혀 하지 않는 허울뿐인 구축 사례도 존재한다. 이러한 ‘생생한’ 실패 사례를 되짚어보고 원인을 진단해봄으로써 이미 값비싼 대가를 앞서 치러준 전철을 밟지 않도록 해야 할 것이다. <편집자>

Rule 1 - 과유불급
맥도날드 : 이노베이트(글로벌 ERP 애플리케이션) 프로젝트

맥도날드는 세계에서 유래가 없는 대규모 프로젝트를 진행했지만 완료하지 못하고 말았다. 패스트푸드 체인 회사인 맥도날드는 2001년 본사와 전세계 지점들을 인트라넷으로 연결해 운영 정보를 제공하는 야심찬 프로젝트를 구상했다.

이노베이트(Innovate)라 명명되었던 이 프로젝트는 본사 매니저가 특정 지역의 매출이 떨어질 경우 즉시 이를 파악할 수 있게 해주며 런던 지점의 그릴 온도가 조리하기에 충분할 정도인지 아닌지를 실시간으로 점검할 수도 있게 해줄 것이라는 기대를 받았다.

하지만 현재 맥도날드는 이노베이트에 대해 함구하고 있으며 기억에서 잊혀지기를 바라는 눈치이다. 확실한 것은 이노베이트 프로젝트가 성공하지 못했다는 것이다. 당시 맥도날드의 기획 및 기술 구매 업체로 선정되었던 컨설팅 업체인 Mpower의 화이트 페이퍼에 따르면, 이노베이트 프로젝트는 ‘맥도날드의 모든 매장을 연결하는 글로벌 ERP 애플리케이션’ 구축이었다. 다시 말해서, 120여 국가의 3만 여 매장을 연결하는 것이다. ‘누워서 맥도널드 떡먹기’. 말이야 쉽다.

맥도날드가 미국 증권거래위원회(SEC)에 제출한 문서에 따르면 이노베이트 프로젝트 컨설팅 및 기획, 구축 초기 비용으로 1억7,000만 달러가 책정되어 있는 것으로 나타났다. 2003년에 이르러서는 이노베이트 프로젝트에 대한 ‘소멸’을 알리고 장기적인 기술 프로젝트를 철회한다고 명시했다.

노련한 IT 프로젝트 매니저들이라면 맥도날드의 프로젝트가 시작부터 잘못되어 있다는 것을 말했어야 했다. 수만 개의 매장에, 그것도 일부 국가의 경우 IT 인프라도 제대로 갖춰지지 않았음에도 전세계적인 네트워크를 구축하겠다는 시도는 실패로 끝날 수밖에 없다는 사실을 몰랐던 것일까. 장기적인 관점에서 볼 때 많은 이점이 있다고 해도 시장 상황에 적합하지 않고 몸집이 거대한 ‘야심찬’ 프로젝트는 야심으로만 머물게 된다. 애꿎은 인력과 비용만 허공에 날린 셈이 된 것이다.

즉, 지나치면 부족한 것만 못하다는 진리를 간과한 대표적인 사례라 할 수 있다.

Rule 2 - 신중하게 문제를 해결하라
퍼스트 에너지 : 소프트웨어 버그에 의한 정전 사태

초기 대응이 미흡할 경우 엄청난 피해가 발생하게 된다. 450만 고객에게 전력을 공급하는 오하이오의 설비 회사인 퍼스트 에너지(First Energy)의 경우 3년 전에 소프트웨어 버그로 인해 미국 북동부와 캐나다 지역에 정전사태가 빚어졌다.

당시 정전은 오하이오 지역의 전선이 큰 나무에 걸리면서 전선의 전류 흐름에 이상이 생겨 전선이 과열, 이로 인해 다른 전선까지 과부하가 걸리게 되어 정전 사고가 일어나게 되었다. 하지만 그보다 더 큰 원인은 퍼스트 에너지의 컴퓨터 부서에 근무하는 담당자들이 기본적인 운영 원칙을 지키지 못했다는 데에 있다. 문제가 확대되는 것을 충분히 방지할 수 있었음에도 초기 대응에 실패하면서 정전 사태가 걷잡을 수 없이 커지게 된 것이다.

아무리 자동화되어 있다고 해도, 그리고 직원들이 아무리 경험이 많다고 해도 국제적인 IT 서비스 관리 최적 구현 사례인 ITIL(Information Technology Infrastructure Library)에서 규정한 것처럼 기본적인 IT 관리 프로토콜을 준수해야 한다.

당시 정전 사태에서 퍼스트 에너지의 소프트웨어 경보 시스템이 제대로 작동했더라면 일부 지역만 정전되는 것으로 끝날 수도 있었다. 바로 여기에 주목해야 한다. 무엇인가가 잘못되어있다고 깨달을 때에는 너무 늦은 것이다. 북미 전기신뢰성위원회(NERC)의 인프라 보안 매니저인 스탠 존슨은 “단전이 문제가 아니라 퍼스트 에너지의 대응이 신속치 못했다는 것이 가장 큰 문제였다”고 지적했다.

2003년 8월 13일 오후 2시경에 퍼스트 에너지의 IT 직원들은 제너럴 일렉트릭(GE) XA/21 에너지 관리 시스템의 경보 모듈이 고장난 것을 발견했다. 직원들은 문제 해결을 위해 해당 서버를 재부팅했지만 서버가 복구되었을 때 경보 시스템의 전원은 꺼져있었다. GE는 추후 공식 논평을 통해 소프트웨어 코드 에러로 인해 경보 애플리케이션을 복구하지 않고 무한 루프로 전환되었다고 밝혔다.

오하이오에 위치한 퍼스트 에너지의 통제실 근무자들은 이러한 방어 체제가 무력화되었다는 것을 인식하지 못했는데, IT 담당자들이 재부팅 뒤에 모든 시스템이 온라인으로 복구되었는지를 확인해주지 않았기 때문이다. 더욱이, 불안정한 전력 상태가 급속도로 퍼져나가게 되었다.

IT 관리의 최적 실행 방안을 무시한 직원들은 중요한 시스템이 완벽히 복구되었는지의 여부를 확인하지 않았다. ITIL은 IT 부서에게 관리자가 중요 시스템을 재부팅할 경우 연락해야 하는 통화 목록을 작성하도록 권고하고 있다. 정전 사태에 대한 최종 보고서에서 NERC는 퍼스트 에너지의 IT 부서에게 커뮤니케이션이 부족했다는 책임을 물었다.

퍼스트 에너지는 인터뷰 요청을 거절했지만 존슨은 현재 퍼스트 에너지가 위원회의 정전 최종 보고서에 제출한 권고 사항을 따르고 있다고 밝혔다. 위원회는 시스템 업그레이드 실행 방법을 비롯, 패치 관리와 유지 보수 등을 포함해 주요 하드웨어 및 소프트웨어 시스템의 테스트, 도입, 백업을 관리하는데 필요한 정확하고 문서로 기록한 프로토콜을 만들라고 퍼스트 에너지에 권고했다. 아울러 시스템 장애 발생 시 커뮤니케이션을 효과적으로 실행할 수 있도록 프로토콜을 구축할 것도 요구했다. 이러한 권고 사항은 모든 기업들에게 적용되는 것이다.

Rule 3 - 상세한 내용을 파악하라
어스케어 : WFS의 특정 사업부 인수 사건

회계 시스템이 없는 회사에서 회계 담당자로 근무한다고 생각해보라. 대일 신스키의 경우가 이에 해당되는데, 그는 폐유 재활용 업체인 어스케어(Earthcare)에 2000년에 합류하면서 그 같은 상황에 처했다. 이 회사는 그가 전까지 재직했던 WFS(World Fuel Services)의 인터내셔널 페트롤리움(International Petroleum) 사업부를 3,500만 달러에 인수했지만 상세한 내용에는 주의를 기울이지 않았다.

인수 당시, WFS는 그와 그의 동료들이 담당했던 오라클 회계 시스템을 관리하고 있었다. 하지만 문제는 어스케어가 시스템 유지에 필요한 대가를 치루지 않았으며 해당 시스템의 전환이 불가피했다. 그는 “3개월이 지난 뒤에는 아무 것도 남아 있지 않았다”고 말했다. 어스케어는 재무 실적을 추정해 대략적으로 수치화해야 했으며, 그러한 추정치는 객관성과 설득력을 가질 수 없었다.

이러한 주먹구구식 장부 계원은 어스케어에 더 큰 문제를 초래했다. 2001년에 인터내셔널 페트롤리움의 인수와 관련된 문제를 해결하기 위해 175만 달러를 WFS에 지불하게 되었으며, 2002년 4월에는 도산하게 되었다. 신스키는 어스케어가 인터내셔널 페트롤리움을 U.S. Filter Recovery Services에 매각한 그해 6월에 회사를 떠났다.

이것이 이야기의 끝이 아니다. U.S. Filter Recovery Services에 근무하면서 신스키와 그의 동료들은 사게 소프트웨어(Sage Software)의 MAS 200 애플리케이션을 업타임 소프트웨어(Uptime Software)로 전환시켰다. 신스키는 당시 작업이 최악이었다면서 당시 회사가 1980년대의 구식 소프트웨어 버전을 사용하고 있었으며 오라클 환경에 맞도록 통합하는데 있어 전혀 지원을 해주지 않았다고 밝혔다. 호환성은 전혀 없었으며 컴퓨터에는 사용할 수 없는 것들로 가득차 있었다는 것이다.

그와 그의 동료들은 어쩔 수 없이 회사를 떠나야만 했다. 현재 지멘스의 사업부가 된 U.S. Filter Recovery Services의 임원진들은 이에 대한 본지의 질문에 아무런 대답도 하지 않았다. 그는 사업부가 합병에 의해 통합될 경우 모든 운영에 관련된 세부 사항을 철저히 고려하고 지원해야 한다고 지적했다. 여기에는 기업 운영에 필요한 IT 툴의 지원도 포함된다.

Rule 4 - 돈에 집착하지 말라
콘세코 : 인도 아웃소싱 업체 ExlService.com 인수 실패 사례

일부에서는 아웃소싱 업체를 통해 IT의 실패를 막아보려는 시도를 하기도 한다. 미국의 한 대형 보험 및 금융 서비스 업체의 경우 자체 아웃소싱 업체를 보유해 이득을 얻을 수 있을 것이라는 매혹적인 생각을 갖게 되었다. 하지만 이러한 판단은 후회로 마무리되었다.

2001년과 2002년 사이에 장장 15개월에 걸쳐, 인디애나폴리스에 위치한 콘세코(Conseco)는 인도의 아웃소싱 업체인 ExlService.com을 인수했지만 최근 다시 매각했다. ExlService는 인도의 비용이 저렴한 센터에서 고객 서비스를 제공하는 ‘애송이’ 업체였다. 당시 콘세코의 CEO였던 게리 웬트는 제너럴 일렉트릭(GE)의 회장이었으며 콘세코에 스카우트된 상태였다. 웬트의 지휘아래 콘세코는 5,210만 달러에 ExlService를 인수했다.

웬트는 ExlService가 고객 서비스를 단번에 강화하고 비용을 절감시켜줄 수 있는 방법을 콘세코에 제공할 수 있을 것이라 생각했다. 그는 인디애나에서 이용할 수 있었던 아웃소싱 업체는 배제했다. 웬트는 콘세코의 고객 서비스 운영을 해외로 전환한 이유에 대한 인디애나폴리스 스타와의 인터뷰에서, “인도의 고객 서비스가 훨씬 좋을 것이라는 확신을 갖고 있다. 그러나 인디애나는 아니다”고 밝혔다.

그가 밝힌 것은 여러 이유 중의 하나에 불과하며, 웬트는 당시 ExlService와의 거래에 대해 더 큰 목적을 갖고 있었다. 그 자신이 ExlService의 공동 설립자였으며 거래 당시 20%의 주식을 갖고 있었다. 웬트와 그의 아내는 ExlService의 인수로 692,567주(당시 시가 970만 달러)의 콘세코 주식을 확보한 것으로 SEC 문서에 나타나있다. 이러한 주식은 콘세코가 당시 거래로부터 충분한 투자 대비 수익을 거둘 때까지 매도할 수 없었다. 콘세코는 이에 대한 확인 요청을 거부했다.

콘세코는 ExlService 인수 이후 ExlService로 2,000여 고객 서비스 업무를 이관했다. 콘세코는 2002년 11월에 ExlService를 매각해 2천만 달러의 손실을 기록했으며 웬트의 주식은 ‘휴지조각’이 되고 말았다. 일부 콘세코 경영진들은 인디애나폴리스 스타와의 인터뷰에서 나쁜 타이밍으로 인해 실패했다고 원인을 돌렸다. ExlService 콜 센터는 2001년 9월 10일에도 가동 중이었다. 하지만 바로 그 다음날 테러리스트의 공격이 일어났으며 그날 이후 콜 센터 상담원인 인도인의 액센트가 미국인들에게 거부감을 불러 일으키게 되었다.

교훈은 무엇일까? 아웃소싱의 단점을 인식해야 한다는 것? 파트너를 신중히 선택해야 한다는 것? 인디애나를 과소평가하지 말라는 것? 아마도 언급한 모든 것이 해당될 것이다.

Rule 5 - 사공이 많으면 배가 산으로 간다
영국 국가보건서비스(NHS) : IT 현대화 프로그램

영국의 국가보건서비스(NHS; National Health Service) IT 현대화 프로그램은 최악의 IT 재난으로 언급되고 있는 프로젝트 중의 하나이다. 스케줄보다 2년 이나 지체되었으며 100억 달러의 예산이 초과된 이 프로젝트의 주요 계약 업체 중의 하나인 헬스 케어 애플리케이션 제조 업체 iSoft는 네트워크에 대한 자사의 소프트웨어 구축 지연으로 인해 도산 일보 직전에 있다. 

이 회사는 애플리케이션이 실제로 도입될 때까지는 돈을 받을 수 없기 때문에 프로젝트의 지연은 회사의 운영에 엄청난 어려움을 안겨주고 있다. 이 프로젝트는 호환되지 않는 시스템을 결합시키려는 시도를 비롯해 프로그램 기능에 대한 충분한 컨설팅이 없었다는 의사들의 저항, 하청 업체들간의 권한 다툼 등의 여러 요인들로 인해 지연되어왔다.

이 프로그램을 담당했던 IT 경영진들과 정부 기관들은 프로젝트를 제자리로 돌리는데 수년의 세월을 보냈다. 하지만 심각한 문제점이 계속 노출되었다. 올해에는 대규모 컴퓨터 고장이 발생해 영국의 노스 웨스트와 노스 미들랜드 지역의 80여 의료 설비에서 4일 동안 운영이 중단되는 사고가 발생했다. 원인은 환자의 기록과 의료 데이터를 저장하는 서버에 있었다. 해당 지역에 있던 의사들은 며칠 동안 적절한 데이터에 접근할 수 없어 환자 진료에 어려움을 겪었다. NHS는 공식 논평에서 환자의 안전에는 아무런 영향이 없었다고 밝혔다.

NHS의 문제점을 분석했던 한 캠브리지 대학 컴퓨터 과학 교수는 “정부가 당시 프로젝트를 너무나 많은 벤더들에게 ‘분배’해줌으로써 서로 유기적으로 협력하는데 문제가 있다”고 지적했다. 현대화 계획의 ‘싱크 탱크’인 정보정책연구재단(FIPR)을 이끌고 있는 로스 앤더슨 교수는 “너무도 다양한 소프트웨어와 표준을 비롯해 그밖에 너무나 많은 것들로 구성되어 있다”고 말했다. NHS 당국자들은 이 프로그램이 문제점을 갖고 있었다는 데에는 동의했지만 환자 의료 체계의 개선이 지속적으로 이루어지고 있다는 것이 더 중요한 결과라고 언급했다.

앤더슨은 “많은 경우에 있어서 도입된 시스템들은 호환되지 않는 사례가 일반적이다. 이러한 호환성의 부족은 예산의 낭비에 머무는 것이 아니라 더 큰 희생을 치러야 하는 경우가 발생한다”고 경고했다. 시스템들은 기본적으로 호환이 보장되어야 한다. 이번 프로젝트에 참여했던 액센츄어의 경우 최근 다른 업체에게 계약을 이양했다. 액센츄어는 프로젝트의 손실 비용이 약 4억5,000만 달러에 달할 것으로 추산하고 있다.

대규모 아웃소싱 프로젝트의 경우 많은 벤더들이 개입하는 경향이 크다. 위험을 줄이고 하청 업체간 경쟁을 촉발하기 위해서이다. NHS 현대화 프로젝트의 경우 2차 하청업체까지 포함해 10여 벤더들이 참여하고 있다. ‘바벨탑’ 구축 기술이라는 말이 나올 정도이다. 여러 벤더들이 개입할 경우 위험 관리가 가능하다는 장점도 있지만 사공이 많으면 배가 산으로 올라갈 수도 있음을 간과해서는 안 된다.

Rule 6 - 머피의 법칙을 잊지 말라
미 국세청(IRS) : 사기방지 시스템 구축 프로젝트

IT의 실패 사례에 대해 모든 사람들이 안타까워하는 것은 아니다. 미 국세청(IRS; Internal Revenue Service)의 경우 IT의 실패에 오히려 ‘희열’을 느낀 사람들도 있을 것이다. 이는 올해 초에 IRS가 사기 탐지(fraud-detection) 소프트웨어의 업그레이드를 실패했을 때였다. 재무부의 감사원인 마가렛 베그는 “무슨 일이든 잘못될 가능성이 있고 그 일이 실제로 일어난다면 특히 이번 프로젝트의 경우가 그렇다”고 말했다.

IRS는 이 시스템을 1월에 2006 세금 시즌에 맞춰 출범할 계획이었는데, 원래의 구축 시기보다 1년이 뒤진 것이었다. 국세청은 예상대로 오래된 시스템의 플러그를 제거했다. CSC(Computer Sciences Corp.)가 개발 및 구축했으며 IRS의 마스터 데이터베이스를 제외한 모든 시스템의 데이터베이스를 보유한 새로운 버전은 작동되지 않았다. 소프트웨어가 좋지 못하다는 평가는 2001년 계획 당시부터 제기되어온 문제였다. 현재, 재무부의 감사원은 사기 방지 시스템이 제 기능을 발휘하지 못하면서 빚어진 손실에 대해 부정 환급금을 포함해 3억1,800만 달러에 달하는 것으로 추산하고 있다.

하원 세입위원회(House Ways and Means Committee)의 4개월에 걸친 조사 결과, 빌 토마스 위원장은 “모든 면에서 부적격하다”라고 재무부에 보고했다. IRS IT 리더들은 업그레이드가 아닌 유지 보수 프로젝트로 분류해서 실수를 저지른 것으로 조사되었다. 이로 인해 시스템의 중요성에도 불구하고 예산을 너무 낭비하게 되었다는 지적이다. 이 시스템은 테러리스트의 공격으로부터 보호되어야 하는 국가의 주요 인프라에 해당되는 연방 정부의 19개 IRS 자산 중의 하나임은 말할 나위가 없다.

지난 1월, 시스템이 가동되는 시기가 되었을 때 사용자들로부터 534개의 문제점이 지적되었다. 한 가지 문제점은 전자 사기 탐지 시스템 프로젝트 사무실과 이 시스템의 주요 사용자인 IRS의 범죄 조사부와의 커뮤니케이션이 이루어지지 않았다는 것이다. 실제로, 커뮤니케이션은 여러 곳에서 중단되었다. 한 개발 팀이 무언가를 바꾸었을 때 그 변경 사항의 영향을 받는 다른 개발 팀에게 제대로 통지되지 않았다. 그 결과, IRS의 시스템 심의 테스트 팀은 또 다른 곳에서 또 다른 문제에 직면하게 되었다.

이로 인해 SAT 팀은 또 다른 문제점을 지적할 수밖에 없게 되었고 이것이 하청 업체에게 돌아가 또 다른 소프트웨어를 교정하도록 했다는 것이 베그의 설명이다. 인터뷰에서, 베그는 IRS가 주요 애플리케이션과 같은 업그레이드를 성공시키는 프로젝트 관리가 부족했다고 전했다. 베그는 “테스트에 있어서의 엄격함도 없었고 계획 수립이라든가 실행 등 프로그램 관리 행동 강령이 전혀 없었다”고 밝혔다.

이것이 IRS의 대규모 IT 실패 사례의 첫 번째는 물론 아니다. IRS는 지난 8년 동안 80억 달러를 투자해 전체 컴퓨팅 인프라를 업그레이드해왔다. 미국회계감사원(Government Accountability Office)의 조사에 따르면 이 프로젝트가 대표적인 비용 낭비와 비효율적인 사례라고 지적되었다.

IRS IT 인력들의 경우 사임하는 사례가 많았고 대체 인력을 찾기가 어려웠다는 점도 문제점으로 지적된다. 베그는 “특정 프로그램을 구현하는데 있어 필요한 안정성과 일관성이 부족했다”면서 IT 관리자의 이직률이 특히 높았다고 전했다. IRS는 2007 세금 시즌을 목표로 구 시스템의 대체를 진행하고 있으며 웹 기반의 시스템 도입 역시 계획하고 있다. 성공 여부는 모르겠지만.

Rule 7 - 유통기한을 확인하라
미 연방수사국(FBI) : 가상사건 파일 프로젝트

2005년에 미 연방수사국(FBI)은 요원들이 다양한 범죄 데이터베이스를 검색할 수 있도록 해주는 맞춤형으로 개발된 소프트웨어 애플리케이션인 가상사건파일(VCF; Virtual Case File)을 폐기하기로 결정했다. 가상사건파일의 개념은 소프트웨어 업체인 Inslaw가 FBI가 사용할 목적으로 국무부가 Inslaw의 프로미스(promis) 사건 관리 소프트웨어를 훔쳤다고 주장했던 1980년대부터 FBI에게 ‘성배’와 같은 것이었다. 결국 Inslaw는 패소했다. 구식 시스템을 없애고 최첨단 시스템으로 전환하라는 목소리는 9.11 테러 공격 이후 긴급하게 진행해야 할 최우선 과제로 떠올랐었다.

FBI의 트릴로지(Trilogy) IT 근대화 프로그램의 하나인 가상사건파일의 실패는 1억7,000만 달러의 금전적인 손실을 입혔으며 이를 대체할 새로운 프로젝트의 도입과 함께 IT 기획에 대한 ‘금언’을 무시해서는 안 된다는 교훈을 주고 있다. 바로 프로젝트가 완수될 무렵에 낡은 것이 될 수도 있는 기술을 토대로 장기적인 프로젝트를 구상하지 말라는 것이다. 프로젝트 입안자들은 기술이 향후에 어떻게 변모할지 전체적인 기술 환경을 조망해야만 하며 어떤 기술이 폭 넓게 사용될지 심사숙고해야 한다.

2001년 VCF를 기획했던 당시, FBI는 훨씬 저렴하고 유연한 ‘기성품’ 형태의 애플리케이션이 대기업에서 호평을 받고 있었음에도 불구하고 맞춤형으로 개발된 소프트웨어를 선택했다. FBI측은 프로젝트의 폐기를 알린 지난해 보고서에서, “기술적인 혁신 추세가 FBI의 원래 VDF 비전을 앞서 나갔으며 트릴로지 프로젝트를 시작했을 당시에는 존재하지 않았던 제품들이 현재 많이 나와 있다”고 밝혔다. 또한 VCF 프로젝트는 말도 많고 탈도 많았던, 그 짧았던 4년 동안 아홉 명의 프로그램 매니저와 다섯 명의 CIO들을 보유하고 있었다.

FBI는 VCF 프로젝트의 실패로부터 충분한 교훈을 얻었다. VCF 프로그램을 폐기 처분하고 센티넬(Sentinel)이라 불리는 정보 관리 시스템을 도입하고 있다. 센티넬은 최첨단 기술을 토대로 하고 있으며 ‘유통 기한’도 길다. 웹을 토대로 서비스 지향적인 아키텍처를 도입해 외부 법 집행 데이터베이스와 정보 소스를 연결하게 된다.

센티넬의 첫번째 단계에서는 FBI 요원들과 분석가, 기타 인력들이 조만간 대체될 자동화된 사건 지원 시스템에 액세스할 수 있는 기능을 제공하며, 추후 새로운 사건 관리 시스템의 데이터에도 접근할 수 있도록 할 방침이다.

지난 3월, FBI는 센티넬의 구축에 대한 지원을 높이 평가해 록히드 마틴(Lockheed Martin)과 3억500만 달러의 계약을 체결했다. 하청 업체들로는 액센츄어와 CSC가 포함되어 있다. CSC의 Dyncorp 부서는 국무부의 프로미스 프로젝트 원 계약 업체 중 한 곳이기도 하다.

Rule 8 - 급할수록 돌아가라
닐슨 미디어 리서치 : 등급 시스템(rating system) 개발 프로젝트

1990년대 중반, TV 시청률 통계 제공 업체인 닐슨 미디어 리서치(Nielsen Media Research)의 기술 경영진들은 주요 프로젝트 진행에 어려움을 겪게 되었다. 이 회사는 핵심적인 등급 시스템(rating system)을 재개발하려 했다. 이 시스템을 재구축하는 데에는 단순히 백 오피스 부문의 주변 기기들을 바꾸는 것이 아니라 닐슨의 핵심 사업의 주요 엔진을 바꾸는 것이 필요했다.

불행히도, IT 경영진들은 이를 점진적인 방법이 아닌 급격한 속도로 전환시켰다. 그 결과, 코드에 문제가 생겼으며 수백만 달러가 낭비되었고 벤더들과의 법적인 소송 문제에 얽히게 되었으며 현재 10년이 지난 뒤에도 프로젝트를 완료하지 못하고 있다. 프로젝트의 한 관계자는 “경영진들은 서둘러 프로젝트가 완료되길 바랬는데 이제 그 대가를 치루고 있는 셈이다”라고 전했다.

이 프로젝트는 메인프레임용으로 개발된 어셈블러 코드 기반의 등급 시스템을 클라이언트 서버 구조로 변환해 사용자의 친밀도와 유연성을 강화해 방송국 고객들에게 보다 정확한 데이터를 제공하는 것을 목표로 했다. 프로젝트의 복잡성을 감안한 닐슨의 기술 담당자들은 데이터 변환 작업 완료 시한을 3년으로 잡았지만 경영진들은 1년 이내에 완료하기를 원했다. 이에 따라 급하게 처리되게 되었다.

닐슨의 IT 부서는 로봇이 아니기 때문에 불가능하다는 의사를 표명했다. 하지만 한 외부 벤더가 가능하다는 의견을 제시했다. 이에 따라 닐슨은 1년 이내에 끝낼 수 있다는 그 아웃소싱 업체를 고용했다. 1997년, 닐슨은 텐폴드(TenFold)와 소프트웨어 개발 계약을 체결했다. 소식통에 따르면, “닐슨과 텐폴드가 결정을 내렸고 모든 사람들이 따를 수밖에 없었다”는 것이다. 텐폴드와 닐슨은 이에 대한 언급을 회피했다.

닐슨의 기술 담당자들은 처음부터 회의적이었는데, 이들의 생각이 맞았다는 징후가 곧 이어 등장했다. 텐폴드 역시 마감 시한까지 끝낼 수 없다는 보고서가 잇달아 제출된 것이다. 또한 임의대로 코드나 개발 방법을 변경하는 일도 잦아졌다. 닐슨 내부에서는 되도록 텐폴드의 심기를 건드리지 않도록 내부 직원을 단속했지만 여기 저기에서 텐폴드의 ‘막무가내식’ 진행 방법에 대해 불만을 제기했다.

결국, 닐슨의 IT 의사 결정자들도 텐폴드의 그런 태도에 질리게 되었으며 2000년 6월에 프로젝트를 종료시킨 뒤 450만 달러의 손해 배상을 청구했다. 양측은 합의에 도달했지만 닐슨의 문제는 거기서 끝나지 않았다. 프로젝트가 시작된 지 거의 10년이나 되었지만 여전히 시스템 업그레이드를 진행 중이다.
Paul McDougall <paulmcd@cmp.com>