▲

수조 달러를 쏟아붓고도 여전히 실패하는 대형 소프트웨어 프로젝트들

 (spectrum.ieee.org)
5P by GN⁺ 1일전 | ★ favorite | 댓글 5개
  • 전 세계 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년 “소프트웨어 위기” 이후 50년 넘게 같은 실수를 반복하고 있음
    • “새로운 실수를 하세요”

    “누구나 실수를 할 수 있지만, 오직 바보만이 자신의 실수를 고집한다” - 로마의 웅변가 키케로

▲
kgun9 7시간전  [-]

이정도 오랫동안 고쳐지지 않았다면 개발 기술이나 개발 원칙의 문제가 아니라 받아들이는 운영쪽의 문제 아닐까...

답변달기
▲
s0400615 10시간전  [-]

영국 우정국 스캔들은 드라마도 있습니다.
아직까지도 피해자에게 보상이 안되어서, 계속 진행중입니다.

답변달기
▲
t7vonn 11시간전  [-]

최근 국내 사례로는 경기신보 차세대 전산 구축 실패 사례가 생각나네요

https://v.daum.net/v/20251111165048155

답변달기
▲
pcj9024 11시간전  [-]

다른나라도 엄청나게 커다란 si프로젝트를 진행하는건가

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 글의 마지막 부분에서 제시된 해결책이 아쉽다고 느꼈음
    내가 생각하는 진짜 해결책은 작게 시작해서 실제 운영 환경에서 검증하는 것임
    예를 들어 전국 단위 급여 시스템을 만들려면, 먼저 50명 규모의 작은 마을에서 테스트하고, 버그를 잡은 뒤 점차 큰 도시로 확장해야 함
    작은 규모에서 문제를 해결하지 않고 한 번에 전국 규모로 가는 소프트웨어 개발 프로세스는 존재하지 않음

    • 대형 리테일 체인에서 POS 시스템 교체 프로젝트를 했을 때, 우리는 먼저 사내 구내식당과 재고처리 매장 두 곳에만 조기 배포했음
      거래량이 적어 문제가 생겨도 수작업으로 조정할 수 있었고, PCI 규정을 피할 수 있었음
      실제 매장 배포 전에 이런 식으로 테스트한 덕분에 큰 사고 없이 마감일을 맞출 수 있었음
      만약 처음부터 고객 매장에 배포했다면, 세금 계산 오류나 성능 문제로 큰 혼란이 생겼을 것임
    • 이런 접근은 제품(Product) 에는 맞지만, 시스템(System) 에는 한계가 있음
      점진적 확장은 기술 부채를 쌓게 만들고, 결국 아무도 코드베이스의 핵심을 확신하지 못해 리라이트 공포에 빠짐
      WhatsApp처럼 단순한 제품이지만 처음부터 대규모 확장성을 고려한 엔지니어링 설계가 필요함
    • 핵심은 시스템 전체를 이해하는 한 사람의 존재임
      작은 성공적인 시스템일수록 이런 사람이 생기기 쉽고, 사용자와 개발자 모두의 신뢰를 얻어 점진적으로 성장할 수 있음
      대형 프로젝트는 실패 확률이 높으므로, 예방 원칙(Precautionary Principle) 에 따라 작게 시작해야 함
    • 결국 필요한 건 단순함임 — Plan → Implement → Test → Repeat
      어떤 프로젝트든 이 반복 주기가 기본임
    • How Big Things Get Done에서도 같은 원칙을 강조함
      작게 시작하고, 모듈화 후 확장하라는 것임. Tesla의 메가팩토리 사례가 인상적이었음

  • 기술사를 연구하면서 느낀 건, 하드웨어 업계는 과거의 성공과 실패에서 배우지만 소프트웨어 업계는 그렇지 않음
    대부분의 개발자는 과거 시스템을 분해해 배우지 않고, 매 세대가 같은 문제를 다시 겪음

    • 대형 테크 기업에서 일하는데, 모든 대형 프로젝트가 끝날 때쯤 항상 혼돈의 막판 러시가 생김
      회고에서는 늘 “개발자가 다음엔 뭘 다르게 해야 하나”만 묻고, 관리자는 아무 책임도 지지 않음
      결국 같은 문제가 반복되고, 그 부담은 개발자에게 전가됨
    • 세대가 바뀔수록 개발자들은 이전 기술 스택 위에서만 일함
      과거 세대는 문제를 스택의 하단에서 해결했지만, 지금은 상단에서만 해결하려 함
      그 결과 추상화의 탑이 쌓이고, 자원은 더 들지만 기능은 비슷함
      이제는 AI 모델 위에 또 하나의 소프트웨어 층을 쌓는 시대가 오고 있음
    • ERP 같은 대형 시스템을 오래 다뤄본 입장에서, 문제는 도구가 아니라 유능한 프로젝트 관리자 부족임
      경험과 성격이 모두 중요하며, 낮은 자아와 문제 해결 중심 사고가 필수임
      대부분은 프로젝트의 복잡성을 과소평가함
    • 많은 개발자가 코드 읽기 능력을 배우지 못함
      나는 대학원 시절 TinyOS 소스코드를 일주일간 읽으며 구조를 익혔고, 이 경험이 큰 도움이 되었음
      낯선 코드베이스를 빠르게 이해하는 능력은 매우 유용함
    • 기술의 빠른 교체는 의도된 현상일 수도 있음
      새로운 언어나 프레임워크가 주기적으로 등장하면, 기업은 저임금 신입을 계속 채용할 수 있음
      이런 구조가 소프트웨어가 다른 공학 분야처럼 다뤄지지 않는 이유 중 하나라고 생각함

  • 근본적으로 이건 프로그래밍 문제가 아니라 관리의 무능 문제임
    대부분의 프로젝트에서 비즈니스 요구사항이 명확히 정의되지 않고, 전부 추측 기반으로 진행됨

  • 대형 공공 IT 프로젝트의 실패는 계약 구조와 인센티브를 보면 이해됨
    실력보다 시간 청구형 컨설팅에 의존하는 구조가 문제임
    성공적인 프로젝트는 기술보다 조직 간 정렬(alignment) 과 역량(competence) 이 핵심임

    • 결국 문제는 사람과 정치의 문제임, 소프트웨어 자체가 아님
    • 혹시 참고할 만한 문헌이나 사례 연구가 있다면 추천을 부탁함

  • 실리콘밸리의 연령차별이 진짜 문제라고 생각함
    경험이 무시되고, 과거의 교훈이 전혀 반영되지 않음
    하드웨어 업계는 유산을 존중하면서도 혁신을 추구했음

    • 하지만 어떤 이는 “경험을 버리는 건 진화의 일부”라고 주장함
      과거의 실패를 배운 사람은 새로운 시도를 못 한다는 시각도 있음

  • 소프트웨어 프로젝트는 결국 인간의 실패 때문임
    완벽한 프로세스나 도구보다 중요한 건 동기와 책임감 있는 사람임
    법적 결과(Consequences) 가 있어야 사람들이 제대로 일함
    물리적 공사처럼, 각 단계마다 독립 검증과 책임을 부여해야 함

    • 하지만 책임이 너무 크면 아무도 리스크를 감수하지 않게 됨
      그래서 일정 수준의 위험을 감수하며 진행하는 게 현실적임
    • 35년간의 경험상, 실패의 원인은 대부분 사람과 문화였음
      성공한 프로젝트는 감정지능과 리더십이 있는 몇몇 인물 덕분이었음
      결국 소프트웨어 엔지니어링은 사람의 문제임
    • 진짜 엔지니어라면 공학 실패 사례를 배워야 함
      하지만 업계는 여전히 책임 회피와 유행 추종에 빠져 있음

  • 이런 문제는 소프트웨어만의 일이 아님
    Auburn Dam, Columbia River Crossing, Big Dig 같은 대형 토목 프로젝트도 예산 초과로 악명 높음

    • 하지만 “97% 예산 초과”가 꼭 실패는 아님
      초기 예산이 비현실적이었다면 단순히 현실화된 비용일 뿐임
      그래서 작은 프로젝트에서 점진적으로 확장하는 접근이 중요함

  • 나는 개발자도 PM도 아니지만, 대규모 성공 사례가 궁금했음
    병원에서 일하기 때문에 헬스케어 관련 성공 사례면 더 좋겠음
    《The Phoenix Project》를 읽고 Agile과 DevOps 사고방식을 조금 이해했지만, 실무에 적용하기는 어려움
    작은 프로젝트에서 성공의 씨앗을 심고 싶음

    • 대표적인 성공 사례는 Unix와 Linux임
      Multics의 복잡함을 반성하고, Ken Thompson이 3주 만에 Unix를 직접 작성한 것이 시작이었음
      관련 글 참고
    • 성공을 정의하는 게 중요함 — 일정 준수보다 운영 후의 지속적 가치가 진짜 성공임
      Conway’s Law, 핵심 인력 리스크, 명확한 소유권, 테스트 문화 등도 필수임
      무엇보다 “아니오”라고 말할 용기가 필요함
    • Google Search나 Facebook도 성공이지만, 정부 프로젝트처럼 처음부터 거대하게 시작한 건 아님
      healthcare.gov처럼 실패 후 개선된 사례도 있음
    • 인도의 UPI는 거의 완벽한 대규모 성공 사례임
    • 미국의 Direct File 프로젝트도 94%가 긍정적으로 평가했음

  • IT 커뮤니티를 탓하기 전에, 기업의 단기 이익 중심 문화를 봐야 함
    보안과 안정성은 항상 예산 삭감 1순위임
    경영진은 실패해도 황금 낙하산으로 떠나고, 책임은 개발자에게 남음
    정부도 기업의 부실한 보안 사고를 제대로 처벌하지 않음
    결국 “AI, 컨설턴트, 외주”로 해결하자는 식의 냉소적 현실이 반복됨

  • AI에 수조 원을 쏟아붓는다고 상황이 나아지지 않음, 오히려 악화될 것임

    • AI 버블이 터지면 경제 위기와 정치적 혼란이 뒤따를 것임
      이미 서구 사회는 불안정하고, 극우로 기울고 있음
      다음 위기는 단순한 금융 붕괴가 아니라 사회적 붕괴로 이어질 수 있음
      인류가 위기 대신 이해를 통한 진보로 나아가야 함
    • 하지만 AI는 본질적으로 증폭기임
      좋은 프로세스가 있으면 성과를, 나쁜 프로세스가 있으면 문제를 가속화함
      결국 방향은 같고, 속도만 빨라질 뿐임
답변달기