🚨 소프트웨어 프로젝트가 실패하는 진짜 이유: 전략의 부재

 

 

좋은 코드가 아니라, 좋은 전략이 성공을 만든다

여러분, 혹시 이런 경험 있으신가요? 개발팀은 밤낮없이 코딩하는데, 프로젝트는 결국 실패로 끝나는 상황 말이에요. 보통은 "개발자들이 실력이 부족해서"라고 생각하기 쉬운데요, 놀랍게도 대부분의 소프트웨어 프로젝트 실패는 코드 품질 문제가 아니라 전략적 판단 실패 때문이래요.

실제로 스탠디시 그룹의 카오스 리포트에 따르면, IT 프로젝트의 약 19%만이 성공적으로 완료되고, 52%는 예산 초과나 일정 지연을 겪으며, 29%는 완전히 실패한다고 해요. 그런데 이 실패의 원인을 파헤쳐보면 기술적 역량보다는 불명확한 목표, 잘못된 요구사항 분석, 리소스 부족 같은 전략적 문제가 압도적으로 많았어요.

오늘은 한 개발자의 생생한 경험담을 바탕으로, 왜 소프트웨어 프로젝트가 실패하는지, 그리고 어떻게 하면 실패를 피할 수 있는지 알아볼게요.

형편없는 코드로 만든 세계적인 성공작

뉴질랜드의 한 음향 회사 이야기부터 시작해볼게요. 이 회사는 인턴 개발자에게 음향 전파 모델을 구현하는 작업을 맡겼는데요, 솔직히 그 소프트웨어의 코드는... 정말 엉망이었대요.

일단 사용한 언어부터가 Embarcadero Delphi라는, 10년 전에도 구식이었던 객체지향 파스칼이었어요. 버전 관리도 안 되고, 단위 테스트도 없고, 코드는 몇 개의 거대한 파일에 함수들이 마구 섞여 있는 구조였죠. 현대적인 소프트웨어 개발 기준으로 보면 최악의 사례라고 할 수 있어요.

그런데 놀라운 건, 이 소프트웨어가 전 세계에서 가장 인기 있는 음향 모델링 툴 중 하나가 됐다는 거예요. 수많은 고층 빌딩, 사무실, 아파트를 설계하는 데 사용되면서 엄청난 수익을 올렸대요. 왜냐고요? 음향 전문가들이 쉽게 사용할 수 있었고, 정확한 결과를 제공했거든요.

1,300억 원을 날린 호주 기상청의 실수

반대 사례도 있어요. 호주 기상청은 웹사이트 재구축에 9,600만 달러, 우리 돈으로 약 1,300억 원을 투자했는데요, 결과는 참담한 실패였어요.

이 프로젝트도 구식 기술인 Drupal을 사용했고, 개발 실력도 그리 좋지 않았대요. 그럼 왜 음향 소프트웨어는 성공하고 기상청 웹사이트는 실패했을까요?

차이는 명확해요. 음향 회사는 정확히 무엇을 원하는지 알았고, 그 분야 최고의 전문가들이 프로젝트를 관리했어요. 반면 기상청은 명확한 전략 목표도 없이, 막연히 "현대화"를 외치면서 엑센츄어 같은 컨설팅 회사에 모든 걸 맡겨버렸죠.

가장 웃긴 건, 보안 강화가 목표였는데 정작 가장 기본적인 TLS 암호화도 제대로 적용하지 않았다는 거예요. 2025년에 새로 만든 사이트가 여전히 일부 페이지를 HTTP로 제공하고 있다니, 믿어지시나요?

실패의 진짜 원인: 전략의 부재

소프트웨어 업계에서는 프로젝트가 실패하면 습관적으로 개발자 탓을 하는 경향이 있어요. "코드를 못 짜서", "실력이 부족해서", "버전 관리를 안 해서"... 뭐 이런 식이죠.

하지만 현실은 달라요. 대부분의 프로젝트 실패 원인을 들여다보면 이런 것들이에요. 프로젝트가 실제로 무엇을 달성해야 하는지 명확하지 않았어요. 요구사항을 제대로 파악하지 못했거나, 리소스가 턱없이 부족했거나, 관리와 조직이 엉망이었거나, 상황이 바뀌었는데도 전략을 업데이트하지 않았죠.

맥킨지의 2020년 보고서에 따르면, 대규모 IT 프로젝트는 평균적으로 예산을 45% 초과하고, 일정은 7% 지연되며, 약속한 가치의 56%만 제공한다고 해요. 이게 다 기술적 실력 부족 때문일까요? 아니에요. 대부분 전략적 계획과 실행의 문제예요.

좋은 전략이 나쁜 실행도 커버한다

다시 음향 소프트웨어 이야기로 돌아가볼게요. 그 회사는 왜 형편없는 코드로도 성공할 수 있었을까요?

첫째, 명확한 전략적 필요가 있었어요. 대형 건물을 설계할 때 음향 전파를 이해하는 건 필수거든요. 수작업으로 계산하면 오류도 많고 시간도 오래 걸리니, 소프트웨어가 절실했죠.

둘째, 회사에는 세계 최고 수준의 음향 전문가들이 있었어요. 그들은 소프트웨어가 정확한 결과를 내는지 판단할 수 있었고, 프로젝트를 효과적으로 관리하고, 합리적인 일정을 세우고, 필요한 물류 작업을 수행할 수 있었어요.

이런 전략적 기반이 갖춰지니까, 개발 실력이 평범해도 성공적인 결과를 낼 수 있었던 거죠. 마치 훌륭한 장군이 전략과 작전을 잘 짜면 평범한 병사들로도 승리할 수 있는 것처럼요.

전략 없는 프로젝트의 전형: 호주 기상청 사례

기상청 웹사이트는 거의 모든 면에서 전략적 기반이 없었어요.

먼저 프로젝트의 출발점부터 문제였어요. 2015년 데이터 유출 사고 때문에 IT 시스템 검토가 시작됐는데, 웹사이트 개편으로 이어진 거예요. 근데 생각해보세요. 데이터 유출이 웹사이트 문제였을까요? 아마도 피싱이나 다른 보안 문제였을 가능성이 높은데, 왜 웹사이트 개편에 집중했는지 이해가 안 가죠.

설령 웹사이트 개편이 필요했다 해도, 가장 큰 보안 구멍이었던 TLS 미적용부터 해결했어야 했어요. 요즘은 Caddy나 Let's Encrypt로 몇 분이면 설정할 수 있는데 말이죠. 근데 이걸 안 했어요.

그리고 백엔드를 현대화한답시고 Drupal을 선택했는데요, 2025년에 새 프로젝트에 Drupal을 쓴다는 건 정말... 이해가 안 돼요. Drupal은 보안 취약점으로 악명 높고, 유지보수할 개발자 찾기도 어렵고, 콘텐츠와 프레젠테이션 결합 문제를 오히려 악화시키는 선택이거든요.

결정적으로, 기상청에는 자신들이 뭘 하고 있는지 판단할 수 있는 내부 전문성이 없었어요. UX 역량도, 보안 전문성도, 소프트웨어 아키텍처 지식도 부족했죠. 그래서 엑센츄어 같은 곳에 모든 걸 맡겼고, 엑센츄어가 무능하거나 바가지를 씌우는지조차 파악하지 못했어요.

전략적 실패가 전술적 실패를 낳는다

"그래도 개발자들이 정말 못하면 프로젝트가 망하는 거 아니야?"라고 생각하실 수도 있어요. 맞는 말이긴 한데요, 재미있는 건 제대로 된 전략이 있으면 이런 상황 자체가 잘 안 생긴다는 거예요.

음향 회사를 다시 볼게요. 그들은 원하는 게 뭔지 명확히 알았고, 좋은 결과가 어떤 건지도 알았어요. 그래서 프로젝트를 관리하면서 진행이 제대로 되는지 명확히 파악할 수 있었죠. 만약 돈과 노력이 낭비되고 있다는 게 보이면, 프로젝트를 중단하거나 더 잘 이해하는 기술로 방향을 바꿨을 거예요. 엑셀 VBA 모듈로 구현하거나, 다른 로우코드 솔루션을 썼을 수도 있고요. 아니면 실력 좋은 개발자를 고용했겠죠.

반면 기상청처럼 내부 역량이 없으면 엑센츄어가 뭘 하든 감독할 수 없어요. 이런 환경에서는 형편없는 프로그래머들이 번성하죠. 코드 라인 수로 생산성을 측정하는 곳이 바로 이런 데거든요.

또 원하는 소프트웨어가 뭔지, 어떻게 생겨야 하는지 명확하지 않으면, 개발자 시간과 돈을 쏟아부어도 나쁜 코드만 잔뜩 쌓이게 돼요. 겉으로 보면 "개발자들이 못해서 실패했네"처럼 보이지만, 실제로는 전략적 실패예요.

실패하지 않는 프로젝트를 만드는 법

그럼 어떻게 해야 전략적 실패를 피할 수 있을까요?

19세기 군사 이론가 카를 폰 클라우제비츠의 프레임워크를 빌려올게요. 복잡해 보이지만, 연습하면 굉장히 직관적이에요.

첫 단계는 정책 수준에서 시작해요. 기본 목표가 뭔지, 환경에서 우리 위치는 어떤지, 강점과 약점은 뭔지 파악하는 거죠. 기업이라면 생존과 수익성이 1차 목표겠죠.

다음으로, 이 목표를 달성하기 위해 할 수 있는 구체적인 것들을 생각해요. 신제품 개발, 새로운 마케팅 전략, 중요 프로세스 효율화 등등이요. 기상청 예시로 보면, 추가 데이터 유출 방지가 생존에 필수적이니까, TLS 적용 같은 구체적 조치를 생각할 수 있겠죠.

그 다음엔 이 옵션들을 영향력 순으로 순위를 매기고, 가용 리소스로 최대 임팩트를 낼 수 있는 목표들을 선택해요. 가장 영향력 큰 한 가지가 모든 리소스를 먹는다면, 차선책 네 개를 하는 게 나을 수도 있어요.

이제 선택한 각 작업을 세 가지로 설명해요. 현재 상태, 원하는 최종 상태, 둘 사이의 장벽이요. 클라우제비츠는 이 장벽을 "중심"이라고 불렀어요. 군사적으로는 적이 저항을 계속할 수 있게 하는 것을 의미하지만, 비즈니스에서는 프로젝트가 아직 실현되지 못한 이유를 뜻해요.

목표는 이 장벽을 제거하는 거예요. 교육이 필요한가? 직원을 더 고용해야 하나? 다른 조직과 파트너십을 맺어야 하나? 기성 제품을 사야 하나? 아니면 맞춤형 코드를 짜야 하나?

코드 짜기 전에 생각할 게 많죠? 근데 이게 익숙해지면 꽤 직관적인 과정이 돼요.

이 방법의 강력한 효과

이렇게 전략적으로 접근하면 거의 확실하게 프로젝트 실패를 피할 수 있어요.

이유가 뭘까요? 현재 상태와 원하는 최종 상태를 알고 있으니까, 프로젝트가 실제로 그쪽으로 가고 있는지 아닌지 볼 수 있어요. 가장 큰 효과는, 실패할 확률이 높은 프로젝트는 아예 시작하지 않게 된다는 거예요. 시간과 돈과 리소스를 절약해서 성공 가능성 높은 일에 쓸 수 있죠.

실제로 프로젝트를 시작하면, 그게 의미 있는 영향을 줄 거라고 확신할 수 있어요. 제대로 가고 있는지 파악하기도 훨씬 쉽고요. 어려움에 부딪히더라도 방향을 바꾸거나, 대응 전략을 만들거나, 노력한 것에서 뭔가를 건지기가 쉬워져요.

가트너의 2023년 연구에 따르면, 명확한 비즈니스 목표와 전략을 가진 프로젝트는 그렇지 않은 프로젝트보다 성공률이 3배 높다고 해요. 또한 PMI(프로젝트 관리 연구소)의 보고서는 고성과 조직의 89%가 프로젝트 관리 사무소를 운영하며 전략적 계획을 강조한다고 밝혔어요.

비교적 적은 양의 계획과 전략적 사고가 일관되게 더 나은 결과로 이어져요. 항상 정확히 원하는 걸 얻는다고 보장할 순 없지만, 적어도 1,300억 원을 날려서 쓸모없는 웹사이트를 만드는 일은 절대 없을 거예요. 최고로는 모든 걸 정복할 수 있고, 최악으로는 잃을 수 없는 걸 걸지 않아서 훨씬 적은 피해만 입게 되죠.

결국 성공의 열쇠는 전략이다

오늘 이야기를 정리해볼게요.

소프트웨어 프로젝트가 실패하는 건 대부분 코드가 형편없어서가 아니에요. 전략이 없어서, 목표가 불명확해서, 필요한 역량이 부족해서, 상황을 제대로 파악하지 못해서 실패하는 거예요.

형편없는 코드로도 세계적인 성공을 거둘 수 있고, 최고의 기술로도 참담하게 실패할 수 있어요. 차이를 만드는 건 전략적 사고예요.

명확한 목표를 세우고, 현재 상태와 원하는 상태를 정의하고, 그 사이의 장벽을 파악하고, 그걸 제거할 방법을 찾으세요. 그러면 프로젝트 성공률이 극적으로 높아질 거예요.

다음번에 프로젝트를 시작하기 전에, 잠시 멈춰서 물어보세요. "우리는 정확히 무엇을 달성하려는 거지? 왜 아직 달성되지 않았지? 우리가 그 장벽을 제거할 수 있는 최선의 방법은 뭐지?" 이 질문들에 답할 수 있다면, 여러분은 이미 성공으로 가는 길 위에 있는 거예요.