IT 프로젝트 실패의 구조적 원인: 반복되는 관리적 무지와 그 비용

• 요약 개요:
  • 핵심 주제: IT 프로젝트 실패는 기술적 난제가 아닌, 경영진의 '의도적 무지'와 과거 실패 사례에서 배우기를 거부하는 오만함에서 비롯됨.
  • 주요 수치: 지난 20년간 글로벌 IT 지출은 3배(5.6조 달러) 증가했으나 성공률은 제자리이며, 레거시 시스템 유지보수에만 예산의 75%가 소모됨.
  • 핵심 사례: 캐나다 피닉스(Phoenix) 시스템의 총체적 관리 부실과 영국 호라이즌(Horizon) 사태의 비윤리적 은폐는 '실수(Blunder)'가 아닌 '행정적 악(Administrative Evil)'임.

---

1. 서론: 막대한 투자에도 개선되지 않는 실패율

• 투자 대비 효율성 정체:
  • 2005년 이후 전 세계 IT 지출은 1.7조 달러에서 2025년 기준 5.6조 달러로 3배 이상 급증했음.
  • 그러나 막대한 비용 투입에도 불구하고 소프트웨어 프로젝트의 성공률은 지난 20년간 뚜렷한 개선을 보이지 않음.
• AI에 대한 환상 경계:
  • 많은 경영진이 AI 도구나 코딩 보조 도구(Copilot)가 대규모 프로젝트를 성공시킬 것이라 기대하지만, 저자는 이에 대해 회의적임.
  • AI는 시스템 엔지니어링의 복잡성, 재무적 트레이드오프, 그리고 무엇보다 프로젝트 내의 '조직 정치(Organizational Politics)' 를 해결할 수 없음.
• 보편적 실패 현상:
  • 소프트웨어 실패는 국가, 기업 규모, 영리/비영리 여부를 가리지 않고 무차별적으로 발생하며, 이는 단순한 기술적 오류가 아닌 '인간의 상상력 부재'와 '비현실적 목표'에서 기인함.

2. 본론: 실패의 유형과 원인 심층 분석

2.1. 반복되는 '실수(Blunder)'와 학습 거부

• 실패와 실수의 구분:
  • 기술적 한계에 도전하다 겪는 '창조적 파괴(Creative Destruction)'로서의 실패는 환영받아야 함.
  • 그러나 대부분의 IT 실패는 이미 수십 년간 문서화된 원인(위험 관리 부재, 복잡성 과소평가 등)을 반복하는 '멍청한 실수(Blunder)' 에 불과함.
• 경영진의 오만함:
  • 프로젝트 관리자들은 자신의 프로젝트가 "특수하고 유일하다"고 주장하며, 과거의 실패 사례나 데이터를 무시하는 경향이 있음.
  • 이는 단순한 무지가 아닌, 위험 신호를 애써 외면하는 '의도적 무지(Willful Ignorance)' 임.
• 레거시 시스템의 덫:
  • 미국 내 조직들은 레거시 시스템 유지보수에만 연간 5,200억 달러 이상을 지출하며, 이는 전체 IT 예산의 70~75%에 달함.
  • 교체 실패에 대한 두려움으로 인해, 시스템이 물리적으로 붕괴되거나(예: 루이지애나 차량국 메인프레임) 비용 효율성이 완전히 사라질 때까지 현대화를 미룸.

2.2. 주요 실패 사례의 디테일과 파급 효과

• 캐나다 피닉스(Phoenix) 페이롤 시스템:
  • 초기 오판: 기성 솔루션(PeopleSoft)을 도입하면서 80,000개의 급여 규칙과 105개의 노사 단체 협약을 커스터마이징하려 했음.
  • 예산 삭감의 대가: 벤더 제안 예산의 60% 미만으로 프로젝트를 수행하기 위해 핵심 급여 기능 삭제, 테스트 축소, 필수 파일럿 테스트 생략을 강행함.
  • 결과: 2016년 가동 직후 붕괴. 직원 급여 오지급으로 인한 재정적 고통 야기(일부 직원의 자살 원인으로 지목).
  • 비용: 초기 예산 3.1억 캐나다 달러였으나, 복구 및 해결 비용은 현재 51억 캐나다 달러(약 36억 미화)를 초과함.
• 영국 우체국 호라이즌(Horizon) 스캔들:
  • 기술적 결함: 후지쯔(Fujitsu)가 제공한 시스템의 미들웨어 버그로 인해 금전 불일치 오류가 발생함.
  • 조직적 은폐: 경영진은 소프트웨어 결함을 알고도 이를 은폐하고, 오히려 3,500명의 우체국장을 횡령 및 절도 혐의로 고발함. 900명이 유죄 판결을 받고 투옥됨.
  • 사회적 비용: 피해자들의 파산, 이혼, 투옥, 자살 발생. 영국 역사상 최악의 IT 실패이자 사법 불상사로 기록됨.

2.3. 자동화된 의사결정과 '행정적 악'

• 알고리즘의 폭력성:
  • 미국 미시간주의 MiDAS(실업급여 부정수급 적발)와 호주의 Robodebt(복지 부정수급 적발) 시스템은 인간의 감독 없이 알고리즘에만 의존해 판정을 내림.
  • 수만 명의 무고한 시민을 범죄자로 몰았으나, 관료들은 시스템 오류가 입증된 후에도 보상을 거부하거나 책임을 회피함.
• AI 도입의 위험성:
  • 이러한 '행정적 악(Administrative Evil)'은 AI가 공공 인프라에 깊숙이 개입할수록 심화될 것임.
  • EU는 '설명 요구 권리'를 도입했으나, 전 세계적으로 투명성과 알고리즘에 대한 책임 소재 규명이 시급함.

3. 결론: 해결책과 IT 커뮤니티의 과제

• 방법론(Agile/DevOps)은 만능열쇠가 아님:
  • Agile 프로젝트의 실패율이 최대 65%에 달한다는 보고가 있듯, 방법론 자체가 성공을 보장하지 않음. 일관된 리더십과 조직적 규율 없이는 어떤 새로운 방법론도 실패함.
• 솔직한 위험 평가와 윤리적 책임:
  • 프로젝트 시작 전 "무엇을 알고, 무엇을 모르는가"에 대한 솔직한 격차 분석(Gap Analysis)이 선행되어야 함.
  • '인간 중심 AI(Human-centered AI)' 개념을 모든 IT 프로젝트로 확장하여, 시스템 실패가 최종 사용자에게 미칠 정서적·재정적 피해를 비용 편익 분석에 포함해야 함.
• 경영진의 태도 변화 촉구:
  • 소프트웨어는 본질적으로 취약(Fragile)하며 복잡함. 경영진은 예산을 쥔 권력자로서뿐만 아니라, 실패 시 책임을 지는 주체로서 소프트웨어 개발을 존중하고 지원해야 함.
  • 반복되는 오류를 멈추는 것만이 IT 산업이 '위기(Crisis)'에서 벗어나는 유일한 길임.

[baeba]

해커뉴스(Hacker News) 댓글 반응 요약

1. 점진적 배포와 스케일링 전략 부재 (Start Small)

• '빅뱅' 방식의 필연적 실패: 국가 단위 프로젝트를 한 번에 배포하는 것은 자살행위임. 작은 단위(마을→도시→국가)로 순차 검증하며 확장하는 전략 필수.
• 제품 vs 시스템의 차이: 왓츠앱 같은 단일 제품과 달리, 복잡한 엔터프라이즈 시스템은 초기부터 거대한 스케일을 감당해야 하므로 접근법이 달라야 함.
• 핵심 솔루션: "작게 만들고, 검증 후 기능을 추가하라"는 원칙이 무시되고 있음.

2. 경영진의 무능과 책임 회피 (Management Issues)

• 책임 없는 권력 구조: 프로젝트 실패 시 개발자는 야근으로 수습하지만, 결정권자인 경영진은 책임을 지지 않거나 오히려 보너스를 챙기는 모순적 구조 비판.
• 기술 이해도 결여: 기술적 난이도를 무시한 비현실적 일정 강요와 '나쁜 소식'을 듣기 거부하는 상명하복 문화가 문제 해결을 가로막음.
• 정치적 의사결정: 기술적 적합성보다 사내 정치나 외부 벤더와의 관계(리베이트 등)에 의해 솔루션이 결정되는 경향.

3. 통제 불가능한 요구사항과 복잡성 (Complexity & Scope Creep)

• 프로세스 단순화 선행 부재: 피닉스 프로젝트 사례처럼 8만 개의 급여 규칙을 정리하지 않고 그대로 전산화하려는 시도가 근본 원인. 엉망인 오프라인 프로세스는 엉망인 디지털 시스템을 낳을 뿐임.
• 잦은 요구사항 변경: 프로젝트 진행 중 경영진이나 고객의 변덕으로 인한 과업 범위 확장(Scope Creep)이 프로젝트를 늪으로 빠뜨림.

4. 개발자 문화와 잘못된 인센티브 (Developer Culture)

• 이력서 주도 개발 (RDD): 프로젝트 성공보다 본인의 이직에 유리한 최신 유행 기술(프레임워크)을 무리하게 도입하여 기술적 부채를 가중시킴.
• 학습의 단절: 2~3년 주기의 잦은 이직(Job Hopping) 문화로 인해, 개발자가 자신이 만든 코드의 장기적 실패를 목격하고 교훈을 얻을 기회가 차단됨.
• 재발명 집착: 검증된 기존 솔루션을 활용하기보다 자신의 자아 실현을 위해 처음부터 코드를 다시 짜는 비효율적 관행.

5. 소프트웨어 공학의 특수성 (Engineering Nature)

• 물리적 제약 부재: 건축/하드웨어와 달리 소프트웨어는 물리적 제약이 없어 무한한 복잡성을 허용하게 되며, 이것이 통제 불능 상태를 유발함.
• 과거 학습 부재: 타 공학 분야는 실패(예: 다리 붕괴)를 철저히 분석하고 교훈을 남기지만, 소프트웨어 업계는 "이번엔 다르다"며 과거의 실수를 반복하는 'YOLO'식 개발 행태를 보임.