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

> Clean Markdown view of GeekNews topic #24618. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24618](https://news.hada.io/topic?id=24618)
- GeekNews Markdown: [https://news.hada.io/topic/24618.md](https://news.hada.io/topic/24618.md)
- Type: news
- Author: [baeba](https://news.hada.io/@baeba)
- Published: 2025-11-26T09:56:15+09:00
- Updated: 2025-11-26T09:56:15+09:00
- Original source: [spectrum.ieee.org](https://spectrum.ieee.org/it-management-software-failures)
- Points: 3
- Comments: 1

## Topic Body

* **요약 개요:**  
    * **핵심 주제:** 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)'에서 벗어나는 유일한 길임.

## Comments



### Comment 46796

- Author: baeba
- Created: 2025-11-26T09:56:37+09:00
- Points: 1

##### **해커뉴스(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'식 개발 행태를 보임.