제5법칙: '문제 없어요' 뒤에 숨은 진짜 문제의 법칙
-주관적 바램과 객관적 사실이 같다면 그보다 만족스러운 일은 없을 것이다. 하지만 경영에서 그것은 오류일 가능성이 매우 높다. 현실은 나의 의지와 별개로 존재한다. 문제는 그것이 문제가 아니라고 생각할 때부터 문제일 가능성이 크다. 가능성은 어디든 있기 마련이다. '문제없어요(No Ploblem)'는 흔한 관용구이지만 경영에선 이런 경우란 좀처럼 없다. 문제를 인식하지 못해 문제를 키운 예를 한번 살펴보자.
사소한 일로 프로젝트가 결실을 맺지 못하고 엄청난 손실을 끼치는 경우가 왕왕 있다. 거대한 계획과 야심찬 목표를 가지고 시작한 덴버 국제공항 프로젝트는 그런 사례의 가장 적절한 예가 될 수 있을 것이다.
1988년 미국 콜로라도 주 덴버 시는 신공항 건설에 착수한다. 이는 제2차 세계대전 무렵부터 운영되던 기존의 스태플레턴(Stapleton) 공항을 대체 할 야심한 계획이었다. 구(舊)공항이 도심과 인접해 있어서 항공기 소음피해가 심각한데다 부지마저 비좁다는 불만이 대두되면서부터였다.
새로 건설되는 신공항은 기존 공항에 비해 비용절감 효과와 공해를 줄이는 것은 물론, 항공 교통의 체증도 일시에 해결할 수 있을 것으로 생각되었다. 나아가 덴버 시의 성장을 상징하는 공공시설로 부각되리라고 생각되었다. 신공항 건설을 위해 덴버시는 시민채권발행 등으로 42억 달러를 투입했다. 공항 면적은 우리나라 여의도의 46배, 뉴욕 맨하탄 섬의 2배나 되는 어마어마한 규모로 전체 4천2백만 평이나 되었다. 이는 미국이 자랑하는 덜레스, 케네디, 오하이오 등 3개의 공항을 합친 것과 비슷한 크기의 면적이었다.
공항의 위치도 사막 한가운데 위치해 사실상 공항부지의 경계선이 별도로 없는 사우디아라비아의 제다 공항을 제외하고는 세계 최대의 규모였다. 3천6백미터의 활주로는 동서와 남북으로 각각 2개, 3개씩 5개나 설치되어 풍향에 관계없이 항시 동시 이착륙이 가능했다. 게다가 3개의 콘코스(광장형 청사)가 마련돼 전용지하철을 타야만 여객 터미널로 이동할 수 있었다. 이 터미널은 4만2천여평에 달했다. 여기다가 1일 평균 수하물 취급량도 8만개에 달했고, 주차장 용량도 무려 1만3천대나 되었으며, 여객탑승구도 세계에서 제일 많은 94개나 되었다. 실로 어마어마한 인공조성물이었다.
덴버 국제공항(Denver International Airport, DIA)은 이처럼 웅장한 위용을 갖춘 세계 최대 규모의 공항으로 누가 봐도 전혀 손색이 없었다. 덴버 공항의 장점은 이뿐만이 아니었다. 공항은 해발 1천6백 미터에 위치해 있어 ‘1만 마일 도시’로 불렸다. 고지대의 장점은 항시 맑은 날씨를 유지하는 것이었다. 지리적으로도 록키산맥의 서쪽 주변에 위치해 있어 겨울철에는 스키를 타고 오는 관광객들이, 여름철에는 피서차 산을 찾는 사람들에게 인기 있는 휴양지였다.
이 같은 덴버공항이 자랑하는 것은 세계 최대의 공항답게 수많은 여객의 짐을 처리하는 완벽한 수하물 처리시스템이었다. 덴버공항은 DCV로 불리는 첨단설비와 재래식 설비 등 2가지 방식으로 수하물을 처리하도록 설계되어 있었다. DCV시스템은 광산의 궤도를 달리는 운반구 형태처럼 설치됐는데 궤도에 장착된 2천1백여개의 선형유도모터가 총연장 32킬로미터나 되는 궤도를 컴퓨터 제어에 의해 상하좌우로 이동하며 수하물을 나르도록 되어 있었다. 또 행선지에 대한 정보가 항공사의 예약 컴퓨터나 바코드 수하물표에서 레이저 스캐너로 자동 반복돼 수하물컴퓨터로 입력되며 이에 따라 수하물은 승객의 행선지로 자동 분류돼 이송되게 되어 있었다. 따라서 수하물이 잘못 옮겨지는 경우란 거의 없다는 게 공항당국자의 설명이었다. 이러한 덴버공항은 첨단 수하물 처리 시스템의 도움으로 아무리 늦어도 15분이면 자신의 짐을 찾아 공항을 나설 수 있었다. 그 당시에 우리나라 김포공항은 수화물을 처리하는데 통상 30여분 이상이나 소요되었다. 이와 비교해 보면 덴버 공항의 시설은 실로 대단한 것이었다.
그런데 덴버 국제공항은 완공을 앞두었을 무렵, 심각한 문제를 안고 있었다. 그것은 건물의 기초나 외관도 아닌, 앞서 덴버공항이 자랑하는 자동화물처리시스템과 관련된 소프트웨어 문제였다. 거대한 최첨단 시설은 완공되었는데, 눈에 보이지도 않는 소프트웨어가 전체 프로젝트의 발목을 잡은 것이다.
당초 계획대로라면 덴버 국제공항은 1993년 10월 31일에 개통되었어야 했다. 그러나 뜻밖의 문제가 불거졌다. 자동화물처리시스템(Automated Baggage Handling System) 개발을 맡은 소프트웨어 엔지니어들이 문제를 일으킨 것이다. 10월 31일이 되었을 때, 이 거대한 공항의 전 부분은 개항준비가 완료되어 있었으나, 마지막 점검에서 자동화물처리시스템의 미비점이 발견되었다. 소프트웨어 개발자들이 문제를 해결하기 위해 고심하는 동안, 공항에 투입된 모든 자본은 대책 없이 묶여 있을 수밖에 없었다. 개항이 지연될수록 공항은 점점 돈 먹는 하마가 되어 가고 있었다.
눈치 빠른 언론은 이 문제를 놓치지 않았다. 개항 지연의 징후가 보이자 언론은 1993년 초부터 대서특필해 댔다. 언론의 스폿 라이트는 부분적으로 개항된 1995년에까지 덴버 국제공항문제에 집중되었고, 개항 지연을 가져온 데에 대한 비난이 끊이지 않았다. 사이언티픽 아메리카지는 덴버공항 개항 실패 책임이 소프트웨어 업계의 엉성한 개발관리 문제점이라고 고발했다. 그러나 그 내막을 유심히 살펴보면, 그것은 소프트웨어 문제만은 아니었다. 소프트웨어 제작 프로세스가 중요한 요소의 하나이기는 했지만, 화물 처리 소프트웨어를 제외한 나머지 부분도 개항 당일 날 100 퍼센트 준비되어 있었다고 말할 수는 없었다.
이는 신공항 측이 언론의 비난에 대해 소프트웨어 때문에 개항이 불가능하다는 식으로 몰고 갔을 가능성이 높다. 그러면서 다른 프로젝트들은 이미 완수되었으나 화물 시스템 운영 소프트웨어가 미비되어 모든 것이 안되는 식으로 뒤집어 씌웠을 수가 있다. 문제가 먼저 터진 어느 한 곳에 주의가 집중될 때 겉으로는 눈살을 찌푸리는 척하면서도 내부에서 미친 듯이 각자의 일 마무리에 매진했을 것이라는 점이다. 화물 처리 소프트웨어가 전체 프로젝트의 핵심에 있었기 때문에 공항을 운영하는데 매우 중요한 것이긴 했지만, 그것 없이는 단 하루도 공항 내에서 승객들이 움직일 수 없었을까? 다시 말해 화물 처리 소프트웨어 없이는 개항할 수는 없었을까? 실제로 화물 처리 소프트웨어 없이는 텔레-카트(tele-cart), 바코드 판독기, 스캐닝 장치, 전철기(switch point), 카트 언로더(cart unloader) 등을 전혀 사용할 수 없기에 그런 주장은 설득력을 지니고 있다. 하지만 이는 책임을 면피하기 위한 하나의 이유에 불과했다.
예컨대 임시방편으로 건장한 짐꾼들이 짐을 나르도록 할 수도 있었다. 또 기존의 방법처럼 작은 트럭을 활용해 카트를 여러 개 연결해서 나를 수도 있었다. 그러나 이런 방법들은 화물 처리 소프트웨어 문제만 줄곧 얘기하며 시도되지 않았다. 뭔가 다른 문제를 숨기려는 의도가 교묘하게 개입됐던 게 아닌가 의구심이 이는 부분이다.
바로 여기에 개항을 준비하는 프로젝트 전반의 문제점이 드러난다. 즉, 어느 하나가 제대로 작동되지 않을 때의 대안은 전혀 고려되지 않았고, 무수히 숨은 사유들은 드러나지 않은 채 개항지연 원인으로 작용하고 있었다. 다시 말해, 개항 지연의 래드 플래그가 곳곳에서 눈에 띄지 않게 펄럭이고 있었던 것이다. 그 예로 자동 텔레-카트 시스템을 염두에 두고 설계된 터널들은 사람들이 다니기에 너무 낮았다. 당연히 트럭이 통과할 수도 없었다. 확장성이 전혀 고려 안된 터널설계가 다른 대안의 가능성마저 원천봉쇄한 것이다. 이것은 세계적인 공항답지 않는 졸속 시공이었다.
전체 개항을 준비하는 관리자들의 태도에도 문제가 있었다. 그들은 소프트웨어가 늦어질 거라는 사실을 알면서도 대안 마련에 소홀했다. 그들은 그저 추상적으로 터널을 개조하는데 걸리는 시간이면 소프트웨어를 완성할 수 있을 거라고 매우 작위적으로 판단했다. 터널을 좀 더 일찍 개조할 수 있었으나, 관계자들은 터널 개조에 들어갈 돈과 시간이 있으면 소프트웨어가 제때에 인도되도록 하는 데 투자하는 편이 낫다고 확신했을 것이다. 개발 상태와 무관하게 자신들의 주관적인 바람만이 반영되었던 것이다.
처음부터 개발 지연이 예상되었지만, 누구도 그것을 개항의 잠재적인 리스크로 보지 않았다. 심지어는 이 경우는 다를 거라고 라고 까지 생각했다. 신공항 관리자들은 개발자들과는 전혀 다른 동상이몽의 늪에 빠져있었던 셈이다. 그러한 사실을 짐작할 수 있는 대목으로 공항관계자들은 덴버공항과 동일한 설계에 따라 구축된 독일 뮌헨의 프란츠 조셉 스트라우스(Franz Josef Strauss) 국제공항을 방문한 적이 있다. 이때 뮌헨 소프트웨어 팀은 시스템 오픈 전에 도합 2년의 테스트와 6개월간의 24시간 운영을 통한 튜닝을 거치도록 권고했다. 하지만 덴버공항 관계자들은 이러한 충고를 받아들이지 않았다. 더군다나 그런 테스트와 튜닝을 할 시간이 없었으므로, 그렇게 하지 않기로 임의로 결정했던 것이다.
결과적으로 화물 처리 소프트웨어 개발 건은 처음부터 재앙을 자초한 것이었다. 예컨대, 공항 이사진들이 이 프로젝트를 입찰에 부쳤을 때, 계획된 납기 일자를 보고는 아무도 입찰에 응하지 않았다. 모든 입찰자들이 보기에도 그 같은 일정을 맞추는 것은 현실적으로 불가능했기 때문이다. 결국, 공항 측은 BAE 오토메이션 시스템과 최선의 노력을 전제로 계약을 체결했지만, 그것은 다분히 개발 로드맵에 대한 충분한 검토를 통해 리스크를 줄인 가운데 정한 일정이 아니었다. 그런 이유로 프로젝트 기간 중 계약자 측에서는 일찍부터, 그리고 자주 납기 일자를 맞추는 데 문제가 있다고 주장해 왔다. 더구나 매달 그리고 매번 새로운 스펙이 추가되고 변해서 그로 인해 프로젝트가 점점 더 지연되고 있었다. 모든 관계자들은 4년짜리 프로젝트를 2년 내에 끝내려고 하는 이런 시도가 제대로 끝날 수 없다는 점을 잘 알고 있었다. 하지만 이런 개발 실패의 징후들은 무시되었다. 개발지연으로 인한 개항지연이 불 보듯 뻔했지만, 이런 래드 플래그는 정책을 수정하기에 리스크가 너무 많다는 판단을 내린 공항관계자들로서는 받아들일 수 없었다.
문제가 터지기 전에는 언제나 크고 작은 징후가 여러 번에 걸쳐 나타난다. 그런 징후들을 포착해 내지 못한다면, 위험에 전면 노출되는 것과 다를 바 없다. 리스크 관리가 없으면 모두가 공격만 하고 수비는 하지 않는 축구를 하는 것과 같다. 이런 상황에서 승리의 전략은 오로지 상상할 수 있는 모든 행운이 내게 일어나도록 바라는 것뿐이다. 운이 전략의 일부가 되어 버릴 때, 모든 프로젝트는 수렁에 빠진다. 문제가 터진 다음에 아는 것은 바보나 하는 짓이다. 하지만 전 세계적으로 오늘날 경영 현장엔 이 같은 바보들이 넘쳐난다.
덴버 공항이 내부적으로 이런 문제에 골머리를 끓고 있을 때, 당시 한국정부는 연간 승객 수용 규모 3천5백만명 수준의 터미널과 4개의 활주로를 갖춘 서울 신국제공항(지금의 인천국제공항) 개발을 위해 현지답사를 했다. 그 무렵 정부는 인천국제공항 건설에 총공사비가 대략 8천7백억원이 소요될 것으로 내다봤다. 1990년 현지답사를 통해 한국관계자 일행은 덴버국제공항의 지상수송시스템과 새로운 CADD/FM(컴퓨터보조설계 및 개발/시설관리) 시스템에 많은 관심을 보였다. 덴버 신국제공항이 보유한 자동 트레인은 그 무렵 아틀란타 하스필드국제공항과 유사한 것으로서 메인터미널로부터 3개의 보조터미널 어느 곳으로도 승객 이동이 가능한 시스템이었다. 김포국제공항관리공단의 한국 대표단은 인천국제공항에도 지상수송 시스템이 설치될 예정이라고 말했다. CADD/FM 시스템을 새로 건설될 공항에 설치하는 것이 기존의 공항에 설치하는 것보다 훨씬 빠르기 때문이었다. 한국관계자들의 관심을 반영한 듯, 덴버공항의 캐롤 루더 여대변인은 “기존의 공항에 이런 시설을 설치하는 데는 2년 반 정도의 기간이 소요되지만 신공항에는 건설단계부터 정보가 입력되기 때문에 설치기간이 짧아진다.”며 브리핑을 했었다.
아무튼 우리의 견학활동과는 별개로 그 무렵 덴버 공항 관계자들의 속은 이만 저만 아니었을 것이다. 엄청난 돈을 허비하고 나서 결국 근 2년 정도 지연된 뒤 덴버 국제공항은 개항하기에 이른다. 그 무렵 상황으로, 개항은 했어도 프로젝트 전체에 대한 의문은 여전히 남는다. 지금까지 갖게 되는 의문은 그 당시 덴버공항 건설 관계자들이 소프트웨어가 개항 지연의 문제가 될 것이라는 점을 몰랐을까 하는 것이다. 그러면서도 한국관계자들에게는 그러한 개발 리스크에 대해 전혀 언급이 없었던 점은 자존심 때문이거나, 감추고 싶었기 때문일 것이다.
그 후 인천국제공항은 덴버 공항을 비롯해 여러 국제공항을 벤치마킹해 설계되었고 건설되었다. 덴버에서와 똑 같은 문제점이 생기지 않은 것은 그나마 극히 다행스러운 일이다. 그럼에도 불구하고 인천공항에서는 지금도 원인을 알 수 없는 이유로 외관을 이루는 대형 유리가 종종 금이 가는 일이 벌어지고 있다. 인천국제공항에는 총 2만9000여장의 유리가 촘촘히 짜여 있는데, 매년 외벽유리 60~80여장이 깨져 나가고 있다. 그런데도 정확한 원인조차 파악되고 있지 않다. 2001년에 72장, 2002년에 81장, 2003년에 64장 등 개항 후 3년간 200여장이 넘게 깨졌고, 2004년 상반기에 만에도 27장이 파손됐다. 2004년 상반기까지 유리 교체비로 쓴 돈만 4억원이 넘는다. 비록 강화유리로 시공되어 있어 아래로 추락하면서 이용객들을 덮친 사례는 아직 없지만, 2004년 5월 드골공항 붕괴와 같은 사고가 발생치 않도록 근본적인 대책마련이 필요하다는 지적이 있다.
출국자 수하물을 싣는 기기의 오작동 문제도 있었다. 2007년 5월 공항 컨베이어벨트 시스템이 승객들의 수하물에 표시된 바코드를 잘못 인식하면서 국제선 이용객 수하물을 싣지 않은 채 항공기가 출항하기도 했고, 운용시스템 문제로 항공기가 지연되거나 결항되는 일도 발생했다. 이에 대해 항공 전문가들은 “공항 운용시스템 등 ‘소프트 웨어’ 부문이 개선되지 않는다면 지연·결항을 근본적으로 줄이기는 어려울 것”이라고 지적한 바 있다. 개항 후 덴버공항과 같은 사태가 일어나지 않도록 주의를 기울이도록 만드는 사례이다.
어느 조직, 어느 시설이든 개발, 운용에는 리스크가 뒤따른다. 그러나 그러한 위험 요인들은 갑자기 나타난다기 보다는 시간을 두고 수차례에 걸쳐 래드 플래그를 펄럭인다. 요는 이 점을 알면서도 많은 조직이 대응책 마련에 소홀하다는 것이다. 덴버국제공항의 개항지연과 막대한 손실은 자동화물처리시스템 소프트웨어의 개발지연으로 인해 발생했지만, 그런 징후를 발견했으면서도 대안 마련에 소홀한데서 보다 근본적인 원인을 찾을 수 있다. 인천국제공항의 깨진 유리창이나 수하물 시스템은 작으나마 다른 어떤 기능들과 함께 결합될 때 더 큰 문제를 야기할 수 있다. 문제는 이에 대한 본질적 해결을 위한 접근법이다. 모든 문제가 그렇듯 진인(眞因)이 밝혀지고 해결되지 않는다면, 원인은 잠복상태를 지니고 있다. 뿌리부터 샅샅이 살펴보지 않으면 보일만한 것도 찾아지지 않는다.
<개발 관리 리스크의 교훈>
프로젝트를 수행하며 나타날 수 있는 개발 리스크는 어떻게 줄일 것인가? 원인 파악과 대안 마련은 어떻게 할 것인가? 이 점은 기업 경영에도 그대로 적용된다. 생산, 유통, 마케팅, 판매, 판매이후의 고객대응 등 기업 활동 전 과정에 걸쳐 리스크는 잠복해 있다. 그러다 어느 한 순간, 경미한 오류에 의해 크게 불거지기도 하고, 위기의 도미노 현상을 일으키기도 한다. 그리하여 마침내 전체를 통제불능의 상태로 끌고 가곤 한다. 덴버공항의 문제점으로부터 얻는 교훈은 다음과 같다.
-덴버공항 화물처리시스템 소프트웨어 개발 프로젝트의 가장 큰 문제점은 리스크 관리를 위한 노력이 전혀 없었다는 점이다. 최소한의 공식적인 리스크 관리노력만 있었더라도 소프트웨어 납기지연이 개항일정에 심각한 리스크로 부각됐을 것이다. 하지만 이 같은 징후들은 최종 단계에까지 계속 무시되어 왔다. 리스크 관리와 차단을 어느 단계에서 관여해 줄일 것인가 하는 점이 보다 중요하다.
-리스크에 대한 노출비용 분석을 했더라면, 화물 처리 소프트웨어가 핵심 경로상에 있었고, 그것의 지연이 개항을 연기시키고 따라서 매월 3천 3백만 달러의 경제적 손실을 초래할 수 있다는 사실을 사전에 알 수 있었을 것이다. 이런 유지 비용(carrying cost)은 처음부터 쉽게 계산될 수 있었지만, 공항 관계자들은 이를 무시해 엄청난 손실을 초래했다.
-리스크 관리는 감당할 만한 목표와 일정을 제시하여 프로젝트가 처음부터 끝까지 성공적으로 실행될 수 있도록 계획되어야 하지만, 이 점은 제대로 고려되지 않았다. 또한 초기에 수백만 달러만 투자해서 적절한 화물 처리 대안을 확보했더라면 소프트웨어 납기 지연으로 인한 5억 달러의 손실을 입지는 않았을 것이다. 덴버공항 관계자들은 어떤 대안이 될 수 있는 방법도 취하지 않았다.
-계약자들이 이미 화물 처리 소프트웨어가 납기 내에 인도되지 못할 것이라고 수없이 강조했음에도 불구하고, 이는 무시되었다. 5억 달러 초과 지출의 책임은 리스크를 무시한 대가였다. 그리고 이 책임은 책임을 치를 의무가 있는 모든 관련자들에게 있다.
-납기 일자에 대한 불확실성의 범위가 너무 컸다. 개발사 입장에서도 납기일을 지키기 어렵다면 계약을 포기하는 편이 차라리 나았을 것이다. 그들은 초기에 개발일정에 대한 소프트웨어 프로젝트 관리자들의 요구를 냉정하게 판단한 후 결정 내렸어야 했다. 하지만 그들은 공항 관계자의 요구를 수용함으로서 결국 책임이 자신에게 귀속되도록 한 결과를 가져왔다.
-소프트웨어 업계에는 ‘할 수 있다’는 식의 생각이 팽배해 있지만, 그것은 매우 추상적인 얘기이다. 누구도 수주를 할 때 ‘할 수 없다’라고 말하지는 않는다. 그들이 ‘할 수 있다’고 말하는 것 가운데 지켜질 수 있는 것과 그렇지 못한 것을 선별해 내는 것이 관리자의 능력이다.
-불확실성에 대해 상호 명쾌한 정의를 내리지 않았다. 기껏 낙관적으로 상상해서 도달할 수 있는 결과라고 해봐야 결국엔 실패다. 리스크 관리 없이 혁신적인 목표와 합당한 기대 수준을 구분할 방법이란 없어 보인다.
-공항 측은 리스크에 대비해 예비비를 마련하지 않을 까닭에 리스크가 현실화되었을 때 훨씬 많은 대가를 지불해야만 한다. 결국엔 분별없는 관리가 불러일으킨 엄청난 손실이었다.
래드 플래그 제5법칙: 징후 통찰의 법칙
-조직에서 발생하는 문제는 드러나는 문제 자체보다는 내재된 문제가 더 큰 위험을 자초한다. 문제 뒤에 숨어 있는 진짜 문제를 꿰뚫어 보지 못할 때 문제는 식인상어가 돼서 조직 전체를 삼켜 버린다. 이는 개인에게도 마찬가지이다. 자신에게 생길 수 있는 문제를 예측하거나, 어느 한 문제가 발생했을 때 그 문제의 이면에 있을 위험 요인을 파악하지 못한다면 나중에는 돌이킬 수 없는 상황이 되어 버린다. 이런 최악의 상황을 피할 수 있는 방법은 없는가?
<징후 예측과 위험 발생에 효과적으로 대처하는 방법들 >
-기업경영과 개인사에 있어 간과하지 말아야 할 것은 리스크를 평가해 보고, 이를 원천적으로 제거하는 것이다. 그러나 우리는 문제가 발생하면 그 문제가 단발적이고, 일회성이어서 곧 원상태로 돌아갈 것이라고 믿는 경향이 있다. 그러나 현실은 그렇지 못하다. 조직 내 어느 문제가 생기면 어느 조직이나 불끄기에 여념 없다. 이럴 땐 그 대신 문제가 어디서부터 생겨났는지 유심히 살펴보라. 미리 막을 수 있는 잠재적 문제 덩어리를 발견해 내는 쾌거를 올릴 수도 있지 않은가.
-전체를 망가뜨리는 것은 부분적 오류나 실책이다. 부분에 의해 전체가 작동하지 않을 때 에 문제는 더 이상 부분적인 게 아닌 게 되어 버린다. 조직의 위험을 감지하는 것은 부분을 보면서도 전체를 조망하는 것이다.
-자신의 의지치만 가지고 현실을 대하려 할 때에는 현실이 빗겨나가는 것을 알 수 있을 것이다. 개발 프로젝트, 납기일정 준수, 목표설정 등 모든 면에서 우리는 한 발이라도 객관적 시각에 설 수 있게 노력할 필요가 있다. 이 점이 무시되거나 간과되면, 징후를 보는 눈조차 흐려지게 될 것이다.
<참고자료>
톰 디마르코, 티모시 리스터, <소프트웨어 프로젝트에서의 리스크 관리>, 인사이트, 2004.
윤승용,「첨단기술과 디자인이 조화를 이룬 뉴덴버공항」, <<신공항>>, 1996.8. 통권 제5호.
짐 스트리트,「세계 최대의 덴버 국제공항」, <<항공>>, 1990. 통권 제14호.
「인천공항은 '깨진 유리의 城'?」, <<조선일보>>, 2004.07.29.
「인천공항 수하물 기기 오작동 여행객 짐 빼놓고 국제선 출발」, <<경향신문>>, 2007.5.29.
박병진, 「인천공항 지연·결항 88%가 항공사 잘못」, <<세계일보>>, 2007.5.28.
ⓒ전경일, <레드 플래그>
