Hacker News 2026.04.25 31

60년째 반복되는 엔터프라이즈 시스템의 실패, 그 원인은 '익숙함'이었다

왜 또 엔터프라이즈 프로젝트 이야기냐면요

대기업이나 공공기관의 대규모 IT 시스템 프로젝트가 실패했다는 뉴스, 한 번쯤은 다들 들어보셨을 거예요. 수백억 원 들여서 만든 시스템이 결국 못 쓰게 되거나, 몇 년씩 지연되다가 조용히 묻히는 일들 말이에요. 이게 어제오늘 일이 아니라 무려 60년 동안 반복되고 있는 현상이라는 게 이번 글의 문제 제기입니다.

저자 펠릭스 바발렛(Felix Barbalet)은 단순히 '관리가 잘못됐다', '개발자가 부족했다' 같은 흔한 원인을 넘어서, 훨씬 더 근본적인 문제를 짚어요. 바로 '익숙함(Familiarity)이 진짜 적'이라는 겁니다. 우리가 당연하다고 생각하는 그 방식 자체가 문제라는 거죠.

익숙함이 왜 적이 되는지

엔터프라이즈 시스템을 구축할 때 조직들은 대부분 비슷한 패턴을 따라요. 컨설팅 회사를 부르고, 요구사항 명세서를 수백 페이지 쓰고, 대형 벤더의 솔루션을 도입하고, 폭포수식으로 단계를 밟아가죠. 이게 '익숙한 방식'이에요. 문제는 이 익숙한 방식이 한 번도 제대로 작동한 적이 없다는 점입니다.

1960년대 IBM 메인프레임 시대부터 2000년대 SAP 도입 붐, 최근의 디지털 트랜스포메이션 프로젝트까지, 이름과 기술만 바뀌었지 실패 패턴은 똑같아요. 예산 초과, 일정 지연, 사용자 외면, 결국 '레거시'라는 이름으로 또 다른 새 프로젝트를 부르는 악순환. 저자는 이걸 '익숙함 함정(Familiarity Trap)'이라고 부릅니다. 익숙하니까 의심하지 않고, 의심하지 않으니까 반복하고, 반복하니까 또 실패하는 거죠.

특히 요구사항을 문서로 확정하고 나서 개발을 시작하는 방식이 핵심 문제로 지목돼요. 실제 사용자는 자기가 뭘 원하는지 써보기 전까진 모르거든요. 그런데 수백 페이지 RFP(제안요청서)에 도장 찍고 시작하면, 중간에 '아 이거 아닌데' 싶어도 되돌릴 수 없어요. 이미 계약이고, 이미 예산이고, 이미 일정이니까요.

대안은 뭐냐면요

저자가 제시하는 방향은 사실 우리 개발자들에게 익숙한 것들이에요. 작게 만들어서 빨리 써보고, 사용자 피드백 받고, 고치고, 또 써보고. 이걸 이름 붙여서 부르자면 애자일이고 린 스타트업인데, 엔터프라이즈 세계에서는 여전히 '그건 작은 회사에서나 되는 거야'라는 반응이 많아요.

하지만 구글, 넷플릭스, 아마존 같은 초거대 기업들은 이미 이 방식으로 움직이고 있죠. 규모의 문제가 아니라 조직 문화의 문제라는 거예요. 기존 엔터프라이즈 조직은 실패를 용납하지 않고, 책임 소재를 명확히 하려고 하고, 그래서 더더욱 문서에 집착하게 됩니다. 결국 '실패하지 않는 것처럼 보이는 방식'으로 '확실하게 실패하는' 아이러니에 빠지는 거죠.

한국 개발자 입장에서 보면

이 이야기는 우리나라 SI 업계와 공공 프로젝트를 떠올리지 않을 수 없게 해요. '공공기관 차세대 시스템'이라는 키워드만 검색해도 매년 비슷한 실패 사례가 쏟아지잖아요. 수년간 개발하다 오픈 직후 장애로 멈추는 일도 흔하고요. 원인 분석 기사를 보면 '요구사항 변경이 너무 많았다', '벤더 책임 회피다' 같은 말이 나오는데, 저자의 관점으로 보면 이게 전부 익숙한 방식을 바꾸지 않아서 생긴 증상일 뿐입니다.

주니어 개발자 입장에선 이런 구조에 처음 들어갔을 때 '왜 이렇게 비효율적이지?'라는 의문이 들 거예요. 그 직관이 맞는 겁니다. 그걸 '원래 그런 거야'라고 받아들이는 순간이 바로 익숙함에 잡아먹히는 지점이에요. 반대로 프로덕트 조직이나 스타트업 환경에 있다면, 우리가 당연하게 쓰는 스프린트와 CI/CD가 얼마나 귀한 환경인지 다시 생각해볼 만해요.

실무에서 써먹을 수 있는 교훈은 명확해요. 큰 문서로 한 번에 확정하지 말고, 작게 쪼개서 빨리 검증할 것. 그리고 조직이 바뀌지 않는다면, 적어도 내가 맡은 작은 영역에서는 이걸 실천해볼 수 있다는 거죠. 프로토타입을 먼저 만들어 보여주고 피드백 받는 습관 하나만 들여도, 5년 뒤 커리어가 많이 달라질 겁니다.