# 수조 달러를 쏟아붓고도 여전히 실패하는 대형 소프트웨어 프로젝트들 > Clean Markdown view of GeekNews topic #24624. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24624](https://news.hada.io/topic?id=24624) - GeekNews Markdown: [https://news.hada.io/topic/24624.md](https://news.hada.io/topic/24624.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-26T13:33:32+09:00 - Updated: 2025-11-26T13:33:32+09:00 - Original source: [spectrum.ieee.org](https://spectrum.ieee.org/it-management-software-failures) - Points: 7 - Comments: 5 ## Summary 전 세계 **IT 지출이 세 배 이상 늘었지만 대형 소프트웨어 프로젝트의 실패율은 여전**하다는 분석입니다. 캐나다의 **Phoenix 급여 시스템**부터 영국 **Horizon 사건**까지, 기술보다 **조직 문화·리더십·윤리 부재**가 근본 원인으로 지목되는데요. **AI나 Agile, DevOps**도 이런 구조적 문제를 대체하지 못하며, 여전히 **레거시 유지비와 관리 착오**가 혁신을 가로막고 있습니다. 결국 중요한 건 기술이 아니라 **투명성과 책임, 인간 중심의 설계 원칙을 지키는 일**인 것 같습니다. ## Topic Body - 전 세계 **IT 지출이 2005년 이후 세 배 이상 증가**했지만, 대규모 소프트웨어 프로젝트의 **성공률은 거의 개선되지 않음** - 캐나다의 **Phoenix 급여 시스템**, 영국 **Post Office Horizon**, 미국과 호주의 복지·행정 시스템 등에서 **관리·조직·윤리적 실패**가 반복 - **AI 도구나 코파일럿**이 이런 문제를 해결할 수 없으며, **인간의 상상력 부족·비현실적 목표·위험 관리 실패**가 여전히 주요 원인 - **레거시 시스템 유지비용**이 IT 예산의 70~75%를 차지하고, **Agile·DevOps 도입**도 조직적 리더십과 문화 변화 없이는 실패율이 높음 - 반복되는 **관리 착오와 책임 회피**가 사회적 비용을 키우며, **투명성과 윤리, 인간 중심의 시스템 설계**가 필수 과제로 제시됨 --- ### 소프트웨어 실패의 지속적 문제 - 지난 20년간 IT 지출은 1.7조 달러에서 5.6조 달러로 증가했으나 **소프트웨어 성공률은 정체 상태** - 실패는 국가, 산업, 조직 형태를 가리지 않고 발생 - 실패의 사회적·경제적 비용이 지속적으로 증가 - **AI가 관리 문제를 해결할 수 없다는 한계** 명시 - 대규모 프로젝트의 복잡한 이해관계와 정치적 요인을 AI가 통제하기 어려움 - IT 프로젝트는 이미 **비합리적 의사결정**이 많아 AI가 학습할 만한 사례가 부족함 - 실패 원인은 **인간의 상상력 부족, 불명확한 목표, 복잡성 관리 실패, 위험 통제 부재** 등 - 수십 년간 동일한 요인이 반복되어 “failure déjà vu” 현상 지속 ### 캐나다 Phoenix 급여 시스템 - 2016년 가동된 **CA$310백만 규모의 Phoenix 시스템**은 80,000개 급여 규칙과 105개 노조 협약을 통합하려다 실패 - 예산 절감을 위해 **테스트·파일럿 절차 축소**, 핵심 기능 제거 등 무리한 절차 진행 - 결과적으로 9년간 **직원 43만 명 중 70%가 급여 오류** 경험 - 2025년 3월 기준 **34만9천 건의 오류 미해결**, 절반 이상이 1년 이상 지연 - **직원 자살 사례**까지 보고됨 - 총비용은 **CA$51억 이상**, 감사원은 “프로젝트 관리와 감독의 불가해한 실패”로 평가 ### 영국 Post Office Horizon 시스템 - 1999년 도입된 **Fujitsu의 Horizon POS 시스템**은 내부 오류를 숨기며 3,500명 지점장을 **허위 회계·사기 혐의로 기소** - 900명 유죄, 236명 수감, 13명 이상 자살 - **기술·관리·법적·윤리적 실패**가 복합적으로 작용 - 버그 많은 미들웨어, 통제되지 않은 스코프 확장, 테스트 부족, 인력 미비 - 경영진은 문제 제기자에 적대적 태도, 증거 은폐, 조직적 은폐 시도 - 2016년과 2021년 교체 시도도 실패, 여전히 Horizon 사용 중 - 새 시스템 예산 £4.1억, 2026년 7월 결정 예정 ### 다른 주요 실패 사례 - **미네소타 MNLARS**: 2016년 착수, 2019년 취소, 비용 $1억 달러 - **호주 Modernising Business Registers**: AU$4.8억 예산이 AU$28억으로 증가, 2022년 취소 - **루이지애나 차량등록 시스템**: 50년 된 메인프레임 반복 장애로 2025년 비상사태 선포 - **Jaguar Land Rover**: 2025년 사이버공격으로 한 달 이상 전 세계 운영 중단, 손실 $12~19억 - **Lidl ERP**: SAP 기반 €5억 ERP 실패 후 자체 시스템으로 복귀(2017년) - **Boeing 737 Max**: MCAS 설계 결함으로 346명 사망, 총비용 $740억 추정 - **F-35 Block 4 업그레이드**: 일정 5년 지연, 비용 $105억→$165억 상승 ### 실패의 경제적 비용 - 미국 내 **2022년 소프트웨어 실패 비용 $1.81조**, 개발 실패 $2,600억 - 총액은 **국방예산($7,780억)** 보다 큼 - **레거시 시스템 유지비** 연간 $5,200억, IT 예산의 70~75% 차지 - 교체 비용이 높고 실패 위험이 커 교체 지연 - **NTT DATA 2024 보고서**: 80% 조직이 노후 기술이 혁신을 저해한다고 응답 - 경영진 대부분이 **레거시 인프라가 시장 대응을 방해**한다고 인식 ### Agile·DevOps의 한계 - 반복적·점진적 개발 방식 확산에도 **실패율 여전** - 일부 보고서: Agile 프로젝트 실패율 65%, DevOps 90%까지 언급 - 성공적 도입에는 **리더십, 조직 규율, 훈련, 문화 변화** 필요 - 그러나 대부분 조직이 이를 지속하지 못함 ### 반복되는 관리 착오와 학습 부재 - IT 프로젝트 관리자는 종종 “우리 프로젝트는 다르다”며 과거 실패 교훈을 무시 - 캐나다 정부는 1995년 첫 급여시스템 실패 교훈을 Phoenix에서 반복 - 대부분의 실패는 **혁신적 시도보다 평범한 관리 실수**에서 비롯 - “창조적 파괴”가 아닌 “재정적 파괴”에 가까움 - **AI 기반 행정 시스템 실패 사례** - 미국 **MiDAS 실업급여 시스템**, 호주 **Centrelink Robodebt**가 잘못된 알고리듬으로 수십만 명을 부당 기소 - 정부는 오류 인정과 보상에 소극적 태도 ### 책임, 윤리, 투명성의 필요성 - AI가 내재된 시스템의 **불투명한 의사결정**은 시민의 권리 침해 우려 - EU는 **‘알고리듬 결정에 대한 설명권’** 을 법적으로 보장 - 전 세계적으로 **자동화 시스템의 투명성과 책임성**을 인권으로 확립할 필요성 제기 - **소프트웨어 책임법·전문가 면허제** 논의 존재하지만 실현 가능성 낮음 - 현실적 대안은 **경영진의 정직·회의적 사고·윤리적 판단** 강화 - 위험을 명확히 인식하고, 공급업체의 과장된 약속에 경계 필요 - **AI 포함 모든 IT 시스템에 인간 중심 설계 원칙 적용** 강조 ### 결론: 반복된 실수를 멈출 때 - 소프트웨어 개발은 본질적으로 **복잡하고 취약**하며, 작은 오류가 큰 결과로 이어짐 - 성공적 프로젝트를 위해서는 **충분한 자원·리더십·책임성**이 필수 - 사용자에게 미치는 **정서적·경제적 피해**까지 고려한 비용 산정 필요 - 1968년 “[소프트웨어 위기](https://www.scrummanager.com/files/nato1968e.pdf)” 이후 50년 넘게 같은 실수를 반복하고 있음 - **“새로운 실수를 하세요”** > “누구나 실수를 할 수 있지만, 오직 바보만이 자신의 실수를 고집한다” - [로마의 웅변가 키케로](https://www.loebclassics.com/view/marcus_tullius_cicero-philippic_12/2010/pb_LCL507.191.xml) ## Comments ### Comment 46869 - Author: kgun9 - Created: 2025-11-27T14:27:59+09:00 - Points: 1 이정도 오랫동안 고쳐지지 않았다면 개발 기술이나 개발 원칙의 문제가 아니라 받아들이는 운영쪽의 문제 아닐까... ### Comment 46861 - Author: s0400615 - Created: 2025-11-27T11:17:11+09:00 - Points: 1 영국 우정국 스캔들은 드라마도 있습니다. 아직까지도 피해자에게 보상이 안되어서, 계속 진행중입니다. ### Comment 46857 - Author: t7vonn - Created: 2025-11-27T10:32:45+09:00 - Points: 1 최근 국내 사례로는 경기신보 차세대 전산 구축 실패 사례가 생각나네요 https://v.daum.net/v/20251111165048155 ### Comment 46856 - Author: pcj9024 - Created: 2025-11-27T10:14:15+09:00 - Points: 1 다른나라도 엄청나게 커다란 si프로젝트를 진행하는건가 ### Comment 46811 - Author: neo - Created: 2025-11-26T13:33:33+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46045085) - 글의 마지막 부분에서 제시된 해결책이 아쉽다고 느꼈음 내가 생각하는 진짜 해결책은 **작게 시작해서 실제 운영 환경에서 검증**하는 것임 예를 들어 전국 단위 급여 시스템을 만들려면, 먼저 50명 규모의 작은 마을에서 테스트하고, 버그를 잡은 뒤 점차 큰 도시로 확장해야 함 작은 규모에서 문제를 해결하지 않고 한 번에 전국 규모로 가는 **소프트웨어 개발 프로세스**는 존재하지 않음 - 대형 리테일 체인에서 POS 시스템 교체 프로젝트를 했을 때, 우리는 먼저 **사내 구내식당과 재고처리 매장** 두 곳에만 조기 배포했음 거래량이 적어 문제가 생겨도 수작업으로 조정할 수 있었고, PCI 규정을 피할 수 있었음 실제 매장 배포 전에 이런 식으로 테스트한 덕분에 큰 사고 없이 마감일을 맞출 수 있었음 만약 처음부터 고객 매장에 배포했다면, **세금 계산 오류나 성능 문제**로 큰 혼란이 생겼을 것임 - 이런 접근은 **제품(Product)** 에는 맞지만, **시스템(System)** 에는 한계가 있음 점진적 확장은 기술 부채를 쌓게 만들고, 결국 아무도 코드베이스의 핵심을 확신하지 못해 **리라이트 공포**에 빠짐 WhatsApp처럼 단순한 제품이지만 처음부터 **대규모 확장성**을 고려한 엔지니어링 설계가 필요함 - 핵심은 시스템 전체를 이해하는 **한 사람의 존재**임 작은 성공적인 시스템일수록 이런 사람이 생기기 쉽고, 사용자와 개발자 모두의 신뢰를 얻어 점진적으로 성장할 수 있음 대형 프로젝트는 실패 확률이 높으므로, **예방 원칙(Precautionary Principle)** 에 따라 작게 시작해야 함 - 결국 필요한 건 단순함임 — **Plan → Implement → Test → Repeat** 어떤 프로젝트든 이 반복 주기가 기본임 - [*How Big Things Get Done*](https://www.amazon.com/How-Big-Things-Get-Done/dp/0593239512)에서도 같은 원칙을 강조함 작게 시작하고, **모듈화 후 확장**하라는 것임. Tesla의 메가팩토리 사례가 인상적이었음 - 기술사를 연구하면서 느낀 건, 하드웨어 업계는 과거의 성공과 실패에서 배우지만 **소프트웨어 업계는 그렇지 않음** 대부분의 개발자는 과거 시스템을 분해해 배우지 않고, 매 세대가 같은 문제를 다시 겪음 - 대형 테크 기업에서 일하는데, 모든 대형 프로젝트가 끝날 때쯤 항상 **혼돈의 막판 러시**가 생김 회고에서는 늘 “개발자가 다음엔 뭘 다르게 해야 하나”만 묻고, **관리자는 아무 책임도 지지 않음** 결국 같은 문제가 반복되고, 그 부담은 개발자에게 전가됨 - 세대가 바뀔수록 개발자들은 이전 기술 스택 위에서만 일함 과거 세대는 문제를 **스택의 하단**에서 해결했지만, 지금은 상단에서만 해결하려 함 그 결과 **추상화의 탑**이 쌓이고, 자원은 더 들지만 기능은 비슷함 이제는 AI 모델 위에 또 하나의 소프트웨어 층을 쌓는 시대가 오고 있음 - ERP 같은 대형 시스템을 오래 다뤄본 입장에서, 문제는 도구가 아니라 **유능한 프로젝트 관리자 부족**임 경험과 성격이 모두 중요하며, **낮은 자아와 문제 해결 중심 사고**가 필수임 대부분은 프로젝트의 복잡성을 과소평가함 - 많은 개발자가 **코드 읽기 능력**을 배우지 못함 나는 대학원 시절 TinyOS 소스코드를 일주일간 읽으며 구조를 익혔고, 이 경험이 큰 도움이 되었음 낯선 코드베이스를 빠르게 이해하는 능력은 매우 유용함 - 기술의 빠른 교체는 **의도된 현상**일 수도 있음 새로운 언어나 프레임워크가 주기적으로 등장하면, 기업은 **저임금 신입**을 계속 채용할 수 있음 이런 구조가 소프트웨어가 다른 공학 분야처럼 다뤄지지 않는 이유 중 하나라고 생각함 - 근본적으로 이건 프로그래밍 문제가 아니라 **관리의 무능** 문제임 대부분의 프로젝트에서 비즈니스 요구사항이 명확히 정의되지 않고, 전부 **추측 기반**으로 진행됨 - 대형 공공 IT 프로젝트의 실패는 **계약 구조와 인센티브**를 보면 이해됨 실력보다 **시간 청구형 컨설팅**에 의존하는 구조가 문제임 성공적인 프로젝트는 기술보다 **조직 간 정렬(alignment)** 과 **역량(competence)** 이 핵심임 - 결국 문제는 **사람과 정치**의 문제임, 소프트웨어 자체가 아님 - 혹시 참고할 만한 **문헌이나 사례 연구**가 있다면 추천을 부탁함 - 실리콘밸리의 **연령차별**이 진짜 문제라고 생각함 경험이 무시되고, 과거의 교훈이 전혀 반영되지 않음 하드웨어 업계는 유산을 존중하면서도 혁신을 추구했음 - 하지만 어떤 이는 “경험을 버리는 건 진화의 일부”라고 주장함 과거의 실패를 배운 사람은 새로운 시도를 못 한다는 시각도 있음 - 소프트웨어 프로젝트는 결국 **인간의 실패** 때문임 완벽한 프로세스나 도구보다 중요한 건 **동기와 책임감 있는 사람**임 법적 **결과(Consequences)** 가 있어야 사람들이 제대로 일함 물리적 공사처럼, 각 단계마다 독립 검증과 책임을 부여해야 함 - 하지만 책임이 너무 크면 아무도 **리스크를 감수하지 않게 됨** 그래서 일정 수준의 위험을 감수하며 진행하는 게 현실적임 - 35년간의 경험상, 실패의 원인은 대부분 **사람과 문화**였음 성공한 프로젝트는 **감정지능과 리더십**이 있는 몇몇 인물 덕분이었음 결국 소프트웨어 엔지니어링은 **사람의 문제**임 - 진짜 엔지니어라면 **공학 실패 사례**를 배워야 함 하지만 업계는 여전히 **책임 회피와 유행 추종**에 빠져 있음 - 이런 문제는 소프트웨어만의 일이 아님 [Auburn Dam](https://en.wikipedia.org/wiki/Auburn_Dam), [Columbia River Crossing](https://en.wikipedia.org/wiki/Columbia_River_Crossing), [Big Dig](https://en.wikipedia.org/wiki/Big_Dig) 같은 대형 토목 프로젝트도 예산 초과로 악명 높음 - 하지만 “97% 예산 초과”가 꼭 실패는 아님 초기 예산이 **비현실적**이었다면 단순히 현실화된 비용일 뿐임 그래서 **작은 프로젝트에서 점진적으로 확장**하는 접근이 중요함 - 나는 개발자도 PM도 아니지만, 대규모 성공 사례가 궁금했음 병원에서 일하기 때문에 **헬스케어 관련 성공 사례**면 더 좋겠음 《The Phoenix Project》를 읽고 **Agile과 DevOps 사고방식**을 조금 이해했지만, 실무에 적용하기는 어려움 작은 프로젝트에서 성공의 씨앗을 심고 싶음 - 대표적인 성공 사례는 **Unix와 Linux**임 Multics의 복잡함을 반성하고, Ken Thompson이 **3주 만에 Unix를 직접 작성**한 것이 시작이었음 [관련 글](https://benoitessiambre.com/integration.html) 참고 - 성공을 정의하는 게 중요함 — 일정 준수보다 **운영 후의 지속적 가치**가 진짜 성공임 **Conway’s Law**, **핵심 인력 리스크**, **명확한 소유권**, **테스트 문화** 등도 필수임 무엇보다 “아니오”라고 말할 용기가 필요함 - Google Search나 Facebook도 성공이지만, **정부 프로젝트**처럼 처음부터 거대하게 시작한 건 아님 healthcare.gov처럼 실패 후 개선된 사례도 있음 - 인도의 [UPI](https://en.wikipedia.org/wiki/Unified_Payments_Interface)는 거의 완벽한 대규모 성공 사례임 - 미국의 **Direct File** 프로젝트도 94%가 긍정적으로 평가했음 - IT 커뮤니티를 탓하기 전에, **기업의 단기 이익 중심 문화**를 봐야 함 보안과 안정성은 항상 **예산 삭감 1순위**임 경영진은 실패해도 **황금 낙하산**으로 떠나고, 책임은 개발자에게 남음 정부도 기업의 **부실한 보안 사고**를 제대로 처벌하지 않음 결국 “AI, 컨설턴트, 외주”로 해결하자는 식의 **냉소적 현실**이 반복됨 - AI에 수조 원을 쏟아붓는다고 상황이 나아지지 않음, 오히려 **악화될 것**임 - AI 버블이 터지면 **경제 위기와 정치적 혼란**이 뒤따를 것임 이미 서구 사회는 불안정하고, 극우로 기울고 있음 다음 위기는 단순한 금융 붕괴가 아니라 **사회적 붕괴**로 이어질 수 있음 인류가 위기 대신 **이해를 통한 진보**로 나아가야 함 - 하지만 AI는 본질적으로 **증폭기**임 좋은 프로세스가 있으면 성과를, 나쁜 프로세스가 있으면 **문제를 가속화**함 결국 방향은 같고, 속도만 빨라질 뿐임