IT 프로젝트가 망하는 진짜 이유, AI로도 못 막는 소프트웨어 실패

소프트웨어가 세상을 움직이는 시대지만, 정작 소프트웨어 프로젝트는 여전히 자주 무너집니다. 돈은 20년 전보다 몇 배 더 쓰고 있는데, 성공률은 눈에 띄게 좋아지지 않았습니다.

많은 사람이 "이제 AI가 코딩도 해주고 설계도 도와주니, 대형 IT 프로젝트도 곧 잘 되겠지"라고 기대합니다. 하지만 현실은 정반대입니다. 실패의 핵심 원인은 기술이 아니라 사람, 특히 IT를 이끄는 경영과 관리에 있기 때문입니다.

이 글에서는 세계 곳곳의 초대형 IT 참사 사례를 통해 왜 IT 프로젝트가 반복해서 실패하는지, AI와 최신 방법론이 왜 만능 열쇠가 될 수 없는지, 그리고 우리가 지금 당장 무엇을 바꿔야 하는지 이야기해 보겠습니다.

IT 프로젝트 실패, 왜 20년이 지나도 안 줄어드나

지난 20년 동안 전 세계 IT 지출은 3배 이상 늘었습니다. 수천조 원 단위의 돈이 소프트웨어와 IT 시스템에 쏟아지는 시대지만, 프로젝트 성공률은 크게 나아지지 않았습니다.

소프트웨어 실패는 국가나 기업 규모를 가리지 않고 발생합니다. 선진국이든, 대기업이든, 정부기관이든, 비영리단체든 예외가 없습니다. 그리고 이런 실패는 단순한 "버그" 수준이 아니라, 사람의 삶과 생계를 뒤흔들고, 기업과 정부의 신뢰를 송두리째 무너뜨리는 수준으로 이어지곤 합니다.

문제는 대부분의 실패가 "완전히 새로운 유형의 사고"가 아니라는 점입니다. 이미 수십 년간 수많은 보고서, 논문, 책이 "이렇게 하면 망한다"는 경고를 반복해 왔고, 그 패턴도 상당 부분 정리되어 있습니다. 그럼에도 비슷한 이유로, 비슷한 방식으로, 비슷한 사람들이, 비슷한 말을 하며 같은 실수를 반복합니다.

결국 핵심 질문은 이것입니다. "이토록 많이 실패해서 배울 기회가 있었는데, 왜 여전히 똑같이 망할까?"

캐나다 '피닉스' 급여 시스템: 예고된 재앙의 모든 것

캐나다 정부의 피닉스(Phoenix) 급여 시스템은 대형 IT 프로젝트가 어떻게 완벽하게 망가지는지 보여주는 교과서 같은 사례입니다.

정부는 10만 명이 넘는 공무원들의 급여를 처리하기 위해 상용 패키지(피플소프트)를 강하게 커스터마이징해, 8만 개가 넘는 급여 규칙과 100개가 넘는 부처·기관의 인사 정보를 한 시스템에 엮으려 했습니다. 이 복잡한 요구사항을 두고도 "공급업체가 제안한 예산의 60% 이하로 끝낼 수 있다"고 자신했습니다.

그래서 한 일이 문제였습니다. 핵심 기능을 빼거나 뒤로 미루고, 통합·시스템 테스트를 줄이고, 인력을 줄이고, 시범 운영도 과감히 생략했습니다. 말 그대로 "이 정도면 되겠지"라는 낙관을 기반으로 프로젝트를 몰아붙였습니다.

결과는 참혹했습니다. 시스템 가동 이후, 현재와 과거를 합쳐 43만 명에 달하는 직원 중 약 70%가 급여 오류를 겪었습니다. 월급을 못 받거나, 덜 받거나, 너무 받았다가 나중에 토해내야 하는 상황이 반복되었습니다.

이 과정에서 수많은 공무원들이 모기지 상환, 생활비, 가족 부양 문제로 극심한 압박을 받았고, 한 사례에서는 급여 문제에서 비롯된 정신적·경제적 고통이 자살의 원인으로 공식적으로 지목되기도 했습니다.

캐나다 감사원은 이 프로젝트를 "이해할 수 없을 정도의 관리·감독 실패"라고 비판했지만, 사실 IT 업계의 시각에서는 그다지 "이해 불가능한" 일이 아닙니다. 오히려 너무나 자주 봐온 패턴이 반복되었을 뿐입니다.

영국 우체국 '호라이즌': 소프트웨어가 인생을 부숴버린 사건

피닉스가 재앙이었다면, 영국 우체국의 '호라이즌(Horizon)' 시스템은 "역대 최악의 IT 운영 실패"라 불릴 만한 사건입니다.

1999년 도입된 호라이즌은 전국 우체국 지점의 매출과 회계를 관리하는 시스템이었습니다. 문제는 이 시스템이 근본적으로 불안정하고, 내부 오류가 많았다는 것입니다. 그럼에도 우체국 경영진은 "소프트웨어는 완벽하다"고 반복해서 주장했습니다.

시스템 오류로 인해 장부상 돈이 맞지 않으면, 우체국 본사는 현장 점주들을 "횡령, 사기, 허위 회계" 혐의로 몰아갔습니다. 약 3,500명의 점주가 혐의를 받았고, 그 중 900명 가까이가 실제로 유죄 판결을 받았으며, 236명은 감옥에 갔습니다.

시간이 지나서야 드러난 사실은 충격적이었습니다. – 시스템은 근본적인 결함이 있었고 – 오류를 알 수 있는 정보는 내부에 있었지만 – 그 정보는 제대로 공유되지 않았고, 오히려 감춰졌으며 – 경영진은 시스템을 의심하는 사람들을 향해 법적 압박과 조직적인 은폐로 대응했다는 점입니다.

많은 이들이 사업, 건강, 평판, 가족 관계까지 잃었습니다. 상당수는 이미 세상을 떠난 뒤에야 억울함이 밝혀졌고, 일부는 스스로 생을 마감했습니다.

이 사건의 본질은 단순한 소프트웨어 버그가 아니었습니다. 기술적 결함, 프로젝트 관리 실패, 조직 문화의 독성, 윤리 부재, 그리고 책임 회피가 한데 엮인 총체적 붕괴였죠.

그리고 가장 씁쓸한 사실은, 이렇게까지 큰 참사를 겪고도, 이 시스템을 대체하는 프로젝트마저 또다시 실패하고 있다는 점입니다. "망한 시스템을 바꿀 새 시스템조차 제대로 못 만든다"는 것은 IT 거버넌스가 얼마나 취약한지 상징적으로 보여줍니다.

레거시 시스템, 바꾸자니 무섭고 안 바꾸자니 더 무서운 현실

많은 조직이 낡고 복잡한 레거시 시스템에 발이 묶여 있습니다. 미국 통계를 보면, IT 예산의 70~75%가 기존 시스템 유지·보수에 쓰이고, 레거시 지원 비용만 해마다 수백억 달러(수백조 원)에 이른다고 합니다.

C레벨 경영진 중 상당수는 "노후화된 IT 인프라가 혁신을 가로막는다"고 인정하면서도, 막상 교체에는 극도로 소극적입니다. 이유는 간단합니다. – 교체 비용이 천문학적이고 – 교체 프로젝트가 피닉스나 호라이즌처럼 망할까 두렵고 – 한 번 시작하면 되돌리기 어렵기 때문입니다.

그래서 어떻게든 "버틸 수 있을 때까지 버티자"는 선택을 하게 되고, 그 결과 50년 된 메인프레임이 여전히 국가 핵심 시스템을 떠받치고 있는 상황이 이어지곤 합니다.

문제는, 이렇게 "나중에"로 미뤄둔 기술 부채가 결국 어느 날 한꺼번에 폭발한다는 점입니다. 라이선스 종료, 장애, 보안 위협, 인력 이탈 등 언제 터질지 모르는 시한폭탄이 되는 셈입니다.

결국 레거시 교체는 "겁나서 미루다 더 크게 맞는" 전형적인 위험 관리 실패의 영역입니다. 그럼에도 많은 조직이 오늘의 비용 절감을 위해 내일의 대참사를 담보로 잡고 있습니다.

애자일·DevOps·AI… 방법론이 바뀌어도 실패가 반복되는 이유

지난 20년간 소프트웨어 개발 방식은 크게 변했습니다. 애자일, 스크럼, DevOps, CI/CD, 클라우드 네이티브, 그리고 이제는 AI 코드 도우미까지 등장했습니다.

이론상으로는 이런 접근들이 – 더 빠른 피드백 – 점진적 배포 – 자동화된 테스트와 배포 – 협업 강화 를 통해 실패를 줄여야 합니다. 실제로 많은 조직이 성과를 내고 있기도 합니다.

그런데도 "애자일 프로젝트의 상당수가 기대에 못 미친다", "DevOps 도입의 대부분이 목표를 달성하지 못했다"는 조사 결과가 계속 나옵니다. AI 도구도 마찬가지로, 잘못된 요구사항과 엉망인 프로젝트 관리 위에서 돌아가는 AI는 일을 더 빨리 망치게 만들 뿐입니다.

핵심 문제는 방법론이 아닙니다. – 리더십의 일관된 지원 – 조직 문화의 변화 – 충분한 교육과 훈련 – 현실적인 일정·예산·범위 설정 – 솔직한 위험 관리 이런 것들이 뒷받침되지 않으면, 어떤 최신 방법론도 이름만 멋진 슬로건에 그칠 뿐입니다.

"우리 프로젝트는 남들과 다르다"는 착각도 문제입니다. 다른 프로젝트의 실패 사례를 무시하고, 자기만의 성공 신화를 믿는 순간, 이미 실패의 길을 절반은 들어선 셈입니다.

AI 시대, 알고리즘에 '맡겨버린 책임'의 위험

이제 여러 나라 정부와 기업은 AI와 자동화된 의사결정 시스템을 복지, 세금, 심사, 채용 등 민감한 영역에 적용하고 있습니다. 여기서 벌어진 초기 사례들만 봐도 위험 신호는 충분합니다.

미국 미시간의 실업급여 시스템 'MiDAS'와 호주 복지청의 이른바 '로보덧(Robodebt)' 시스템은 사람 대신 알고리즘이 "사기" 여부를 판단하게 했습니다. 검증되지 않은 모델과 허술한 데이터로 의심 케이스를 쏟아냈고, 공무원들은 이를 거의 그대로 "사기 확정"처럼 다루었습니다.

수많은 시민이 잘못된 빚을 떠안았고, 일부는 극심한 정신적·경제적 압박을 받았습니다. 뒤늦게 정부가 잘못을 인정하기까지는 법적 공방과 언론 보도가 수년간 이어져야 했습니다.

이 사례들이 던지는 메시지는 분명합니다. – AI가 틀릴 수 있다는 상식을 무시하고 – "시스템이 그랬다"는 말로 책임을 회피하며 – 사람의 감시와 이의를 제기할 수 있는 절차를 무시하면 알고리즘은 사람을 돕는 도구가 아니라, 대량의 피해를 양산하는 무기가 됩니다.

그래서 요즘 많이 언급되는 개념이 "사람 중심의 AI"입니다. 인간의 가치, 권리, 안전을 최우선으로 두고 – 어디서 AI를 쓰면 안 되는지 – 언제 반드시 사람의 개입이 필요할지 – 오류가 날 경우 어떻게 완충 장치를 둘지 를 미리 설계하는 접근입니다.

이건 AI에만 필요한 원칙이 아닙니다. 이제 거의 모든 IT 시스템이 자동화, 추천, 규칙 기반 처리, 알고리즘 판단을 포함하고 있기 때문에, 사실상 모든 IT 프로젝트에 적용되어야 할 기본 철학에 가깝습니다.

IT 프로젝트를 덜 망치기 위해, 우리가 진짜 바꿔야 할 것들

IT와 소프트웨어 실패는 이제 한 기업이나 한 기관의 문제가 아닙니다. 전력망, 금융, 의료, 교통, 국방, 행정 등 거의 모든 사회 인프라가 소프트웨어에 의존하는 시대에는, 대형 IT 사고가 곧 사회 인프라 사고이자 생존 문제로 이어집니다.

그럼에도 업계에는 여전히 – "일단 시작하고 나중에 막자"는 무모한 추진 – 공급업체의 장밋빛 제안에 대한 비판 없는 수용 – 실패에 대한 책임 회피 – 사용자 피해에 대한 과소평가 가 만연해 있습니다.

법적 규제나 '소프트웨어 책임법', IT 전문가 면허제 같은 제도적 장치가 필요하다는 의견도 있지만, 당장 실현되기까지는 시간이 걸릴 가능성이 큽니다. 그래서 지금 당장 우리가 할 수 있는 최소한의 변화는 다음과 같습니다.

프로젝트를 시작하기 전에, 스스로에게 솔직하게 묻는 것입니다. – "이 규모와 예산과 일정으로, 비슷한 시스템을 실제로 성공시킨 사례가 있는가?" – "우리가 모르는 것이 무엇인지, 얼마나 많은지 알고 있는가?" – "위험과 부작용, 사용자 피해까지 포함해, 진짜 비용을 계산해 봤는가?"

그리고 경영진은 소프트웨어 개발과 운영을 "부차적인 기술 업무"가 아니라, 조직의 성패를 좌우하는 핵심 전략 활동으로 대우해야 합니다. 충분한 인력과 예산을 주는 것뿐 아니라, 정직함, 회의적인 시각, 윤리적 기준을 조직의 기본 문화로 요구해야 합니다.

작은 오류가 큰 참사로 이어지는 것이 소프트웨어의 특성입니다. 시스템이 복잡해지고 서로 얽힐수록, 그 위험은 기하급수적으로 커집니다. 이 현실을 직시하지 않는 한, 피닉스도, 호라이즌도, 그 다음 이름을 달고 또다시 돌아올 것입니다.

마무리하며: IT 실패, 제발 새로운 실수를 하자

소프트웨어 업계에는 오래된 농담이 하나 있습니다. "실패에서 배운다지만, 같은 실패를 반복하면 그건 학습이 아니라 고집이다."

지난 수십 년간 우리는 IT 프로젝트의 참담한 실패에서 배울 수 있는 기회를 수없이 받아 왔습니다. 그런데도 여전히 같은 이유로, 같은 방식으로 망가지는 사례가 줄어들지 않고 있습니다.

이제는 최소한 이런 정도는 말할 수 있어야 하지 않을까요? "기왕 실패할 거라면, 적어도 새로운 이유로 실패하자."

그 첫걸음은 기술이 아니라 태도의 변화에서 시작됩니다. – 우리는 무엇을 모르는지 인정하고 – 과거의 실패 사례를 진지하게 들여다보고 – 지나치게 낙관적인 계획을 경계하고 – 기술보다 사람과 조직, 윤리를 먼저 고민하는 것

AI가 코드를 대신 짜줄 수는 있어도, 이런 질문을 대신 던져주지는 못합니다. 결국 IT 프로젝트를 살리는 것도, 망하게 하는 것도, 언제나 사람입니다.

출처 및 참고 : Software Failures and IT Management's Repeated Mistakes - IEEE Spectrum