AI 에이전트의 95%가 망한다는데, 살아남은 5%는 뭐가 달랐을까
최근 AI 관련한 여러 소식 중에 동안 가장 많이 언급된 문장을 하나만 꼽으라면 저는 망설이지 않고 "엔터프라이즈 AI 파일럿의 95%가 실패한다"는걸 꼽을 것 같습니다. 링크드인 피드를 내리다가도, 누군가의 임원 보고 슬라이드에서도, 컨퍼런스 키노트의 두 번째 장표쯤에서도 이 숫자는 잊을만 하면 올라왔으니까요. 처음 봤을 때는 그저 자극적인 헤드라인 하나가 잘 팔리는 모양이라고 생각했고, 여전히 의심이지만 일명 ‘어그로’성 통계이지 않을까 생각했었습니다.
그런데 같은 통계를 인용하는 글을 열 개, 스무 개 읽다 보니 이상하게도 매번 똑같은 자리가 비어 있었습니다. 자연스럽게 "그래서 살아남은 5%는 도대체 뭘 다르게 했는가"라는, 가장 궁금한 부분이 늘 생략되어 있어 갈증이 있었습니다. 실패율을 나열하며 겁을 주는 글은 차고 넘쳤지만, 정작 그 지옥 같은 확률을 뚫고 실제로 돌아가는 에이전트를 만들어 본 사람의 기록은 의외로 찾기가 어려웠습니다. 이 글에 바로 그 빈자리를, 제가 현장에서 지켜본 것들을 근거로 알아보기 위한 내용을 적어봤습니다.
그 무서운 숫자, 출처부터 -
막연한 공포만큼 의사결정에 해로운 것도 없으니, 자주 인용되는 통계들이 정확히 어디서 나왔는지부터 짚고 넘어가는 게 순서일 것 같습니다.
"95%"는 MIT의 NANDA 보고서에서 나왔는데, 정식 제목은 'The GenAI Divide: State of AI in Business 2025'입니다. 52개 조직을 인터뷰하고 153명의 리더를 설문하고 300건이 넘는 공개 배포 사례를 뜯어본 결과, 측정 가능한 손익(P&L) 효과를 실제로 만들어낸 파일럿이 고작 5%에 불과했고 나머지 95%는 그저 파일럿 단계에서 멈춰 있더라는 이야기죠. 여기에 카네기멜런 대학이 힘을 얹었는데, TheAgentCompany라는 벤치마크 입니다. 가상의 소프트웨어 회사를 통째로 만들어 놓고 175개의 실무 과제를 에이전트에게 던졌더니, 가장 성능이 좋았던 Gemini 2.5 Pro조차 30.3%밖에 끝내지 못했고 Claude 3.7 Sonnet은 26.3%, GPT-4o는 8.6%에 그쳤습니다.
다만 저를 더 오래 붙잡은 건 이 점수 자체보다는 에이전트들이 실패하는 방식이었는데, 일부 모델은 과제를 완수한 것처럼 보이게 하려고 사용자 이름을 임의로 바꿔치기하는, 일종의 분식회계에 가까운 행동까지 했다고 합니다. 거기에 가트너가 2027년까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 거라고 못을 박으면서, 적어도 숫자만 늘어놓고 보면 그림은 꽤나 절망적으로 보입니다. 하지만 이 쯤에서 저는 한 가지를 더 묻고 싶었습니다. 이 벤치마크들이 측정한 게 정확히 무엇이었느냐는 질문입니다.
알고 보니 "모델이 멍청해서"가 아니었습니다
TheAgentCompany 논문을 조금만 자세히 들여다보면 꽤 결정적인 단서가 하나 보이는데, 이 실험이 모든 모델을 동일한 에이전트 골격(OpenHands harness) 위에 올려놓고 그 안에 들어가는 LLM만 갈아 끼우는 방식으로 설계됐다는 사실입니다. 말하자면 일하는 환경은 고정해둔 채 두뇌만 교체해본 셈인데, 그렇게 통제된 조건에서도 실패가 유독 한쪽으로 쏠렸습니다. 데이터 사이언스, 재무, 행정처럼 여러 단계를 거쳐야 끝나는 긴 호흡의 과제(long-horizon task)에서 모델들이 무너졌고, 반대로 한 번에 처리되는 단순한 작업은 제법 그럴듯하게 해냈죠. 단계가 길어질수록 성능이 가파르게 떨어졌다는 이 패턴은, 문제의 본질이 모델의 지능이 아니라 다른 데 있을지도 모른다는 의심을 키웁니다.
실제로 2026년에 접어들면서 업계의 진단도 슬슬 한쪽으로 모이기 시작했는데, VentureBeat가 'Spine vs. Brain' 논쟁이라고 이름 붙인 흐름이 대표적입니다. 질문 자체는 단순합니다. 에이전트가 실패하는 이유가 모델의 지능(Brain)이 안좋아서인지, 아니면 상태를 기억하고 장애를 견디고 여러 실행을 조율해야 하는 런타임 인프라(Spine)가 부실해서인지를 가르자는 거죠. 그리고 현장에서 올라온 대답은 시간이 갈수록 후자 쪽으로 기울었습니다. 상태를 제대로 기억하지 못하는 인프라 위에 급조한 파이썬 스크립트와 느슨하게 엮은 체인, 임시방편으로 짜맞춘 오케스트레이션을 올려둔 에이전트는 프로덕션의 현실을 거의 버티지 못하는데, 컨테이너가 한 번 재시작되는 순간 그동안 쌓아온 맥락이 통째로 증발하고 누적된 토큰 비용은 어느 순간 사업성 자체를 갉아먹기 때문입니다.
러프하게 정리하자면, 우리가 지난 2년 내내 "이 AI가 충분히 똑똑한가"를 물어왔는데 정작 진지하게 물었어야 할 질문은 "이 AI가 제대로 일할 수 있는 환경을 우리가 깔아주기는 했는가"였던 셈입니다. 물론 이건 어디까지나 현장에서 관찰된 데이터에 기댄 해석이고, 모델 자체의 추론 한계가 사라졌다는 식의 낙관으로 읽히는 건 결코 제 의도가 아닙니다. 다만 적어도 지금 시점에서 실패의 무게중심이 어느 쪽에 쏠려 있는지는, 여러 자료를 겹쳐 보면 생각보다 분명하게 드러납니다.
그래서 살아남은 5%는, 대체로 이 셋을 갖고 있었습니다
여기서부터는 통계라기보다는 관찰에 가깝습니다. 외부 API를 단 한 줄도 호출할 수 없는 폐쇄망 금융 환경이나 방산 고객사처럼, 조건이 까다롭기로 유명한 곳에서 에이전트를 끝내 프로덕션까지 끌고 간 사례들을 옆에서 지켜보며 추려낸 패턴이라고 보시면 됩니다. 지루하다 싶을 만큼 인프라와 데이터에 관한 이야기뿐인데, 신기하게도 실제로 작동하는 쪽은 거의 예외 없이 다음 세 가지를 공통적으로 갖추고 있었습니다.
1. 프롬프트가 아니라 컨텍스트를 엔지니어링했다는 것
한 2026년 조사에서 데이터·IT 리더의 82%가 이미 "프롬프트 엔지니어링만으로는 프로덕션 AI에 더 이상 충분하지 않다"고 답했고 데이터 팀의 95%가 컨텍스트 엔지니어링 역량에 투자하겠다고 했는데, 말장난처럼 들려도 둘의 차이는 꽤 본질적입니다. 프롬프트 엔지니어링이 던지는 질문을 잘 다듬는 일이라면 컨텍스트 엔지니어링은 그 질문에 답하기 위한 조건 전체를 설계하는 일에 가깝고, 실제로 에이전트는 한 단계 안에서 죽는 게 아니라 단계와 단계 사이에서, 그러니까 첫 번째 에이전트가 내린 결정을 두 번째가 모르고 세 번째가 있지도 않은 맥락을 지어내는 그 틈에서 무너지기 때문입니다.
특히 심각한건 이미 낡아버린 맥락인데, 어제 가져온 문서가 오늘 갱신됐다는 사실을 모른 채 뻔뻔(?)하게 행동하는 에이전트는 겉으로는 멀쩡한 추론처럼 보이는 오류를 태연하게 뱉어냅니다. 자연어를 SQL로 바꾸는 파이프라인을 한동안 돌려보면 스키마가 슬금슬금 바뀌는 이른바 '스키마 드리프트'가 가장 끈질긴 범인으로 남는데, 살아남은 팀들은 하나같이 RAG를 단순한 문서 검색쯤으로 취급하지 않고 메타데이터 품질과 청크 설계, 재랭킹, 갱신 주기까지를 하나의 살아 있는 파이프라인으로 묶어서 관리했습니다.
2. 인프라를 '실험'이 아니라 '운영'의 문제로 다뤘다는 것
실패하는 조직의 상당수는 AI를 여전히 혁신 예산 어딘가에 끼워둔 실험 항목으로 취급하는 반면, 끝까지 살아남은 쪽은 처음부터 운영(Ops)의 관점으로 접근했는데 이 차이는 폐쇄망 환경에서 특히 극명하게 드러납니다. 인터넷에 연결된 데모야 사실 누구나 만들 수 있지만, 외부 API를 쓸 수 없는 금융·공공·방산 환경에서 모델을 직접 서빙하고 쿠버네티스 위에서 장애를 견디고 토큰 비용을 통제해가며 안정적으로 돌리는 일은 그것과는 완전히 다른 종목의 게임이기 때문입니다. 내가 손쓸 수 없는 모델 가중치에 매달리는 대신 내가 통제할 수 있는 컨텍스트 파이프라인과 런타임을 단단히 붙드는 태도, 바로 그게 운영의 핵심이었고, 흥미롭게도 이 방향은 모델을 무작정 키워가는 흐름과는 정반대로 움직입니다. 거대한 범용 모델 하나에 모든 걸 거는 대신 도메인에 특화된 작은 모델을 폐쇄망 안에서 안정적으로 서빙하는 구성이, 적어도 실전에서는 더 자주 정답에 가까웠으니까요.
이런 "흩어진 것을 한곳에 묶는다"는 발상이 최근 도구 생태계에서 어떻게 구현되는지 잠깐 짚어두면, 모델 추론과 RAG 파이프라인, 에이전트 로직, 워크플로, 관측(observability)을 제각각 라이브러리로 꿰매는 대신 하나의 스택 안에서 다루려는 흐름이 뚜렷합니다. 대표적인 사례가 LangGenius가 만든 오픈소스 플랫폼 Dify인데, 비주얼 워크플로 빌더와 RAG 엔진, 에이전트 프레임워크, 100곳이 넘는 모델 제공자 연동, 그리고 노드별 토큰 사용량과 비용까지 들여다보는 관측 기능을 한 화면에 묶어둔 것이 특징입니다. 2026년 4월 기준 GitHub 스타 13만 8천 개를 넘기며 Flowise나 n8n 같은 대안들 사이에서 빠르게 자리를 잡았는데, 특히 클라우드에 의존하지 않고 자체 인프라에 통째로 올릴 수 있다는 점 때문에 데이터 주권과 컴플라이언스가 중요한 금융·공공·의료 쪽에서 자주 거론됩니다. 물론 Dify가 유일한 답은 아니고 자체 구축을 택하는 팀도 많지만, "파편화된 툴체인과 싸우는 대신 통제 가능한 한 겹의 계층 위에서 에이전트를 운영한다"는 방향 자체는 살아남은 쪽이 공유하던 그 원칙과 정확히 포개집니다.
2. 사람이 언제 어떻게 개입할지를 미리 설계해두었다는 점
과거 WRITER의 2026 설문에서 임원의 35%가 폭주하는 에이전트를 즉시 멈출 방법이 없다고 인정했고 36%는 에이전트를 감독할 공식적인 계획조차 없다고 답했으며 67%는 승인받지 않은 AI 도구 탓에 이미 데이터가 새어나갔다고 믿고 있었는데, 이런 환경에서 작동하는 시스템은 거버넌스를 일이 다 끝난 뒤에 덧붙이는 장식이 아니라 본격적으로 확장하기 전에 먼저 깔아두는 토대로 다뤘습니다.
규제 산업일수록 이 경향은 더 짙어지는데, 에이전트가 확신하지 못하는 케이스에서는 답을 지어내는 대신 담당자에게 넘기도록 만들고 모든 응대를 빠짐없이 로그로 남기며 되돌릴 수 없는 고위험 행동에는 반드시 사람의 승인을 끼워 넣는 식으로, "틀린 답을 내놓느니 차라리 담당자에게 연결하겠다고 말하는 편이 백 번 낫다"는 원칙이 시스템 곳곳에 배어 있었습니다.
그래서 우리는, 무엇부터 들여다봐야 할까요
만약 지금 AI 에이전트 도입을 진지하게 고민하고 있다면, 도구를 고르기 전에 스스로에게 던져봐야 할 질문이 몇 개 있다고 생각합니다. 우리 데이터가 에이전트가 신뢰하고 가져다 쓸 만큼 정리되고 또 꾸준히 갱신되고 있는지, 컨테이너가 재시작되거나 과제의 단계가 길어져도 끝내 살아남는 런타임 위에 우리 시스템이 올라가 있는지, 그리고 에이전트가 틀린 판단을 내렸을 때 우리가 그걸 언제 어떤 방식으로 알아채고 멈춰 세울 수 있는지 같은 질문들 말입니다. 흥미로운 건 이 세 질문이 하나같이 모델의 성능과는 거의 무관하다는 점이고, 제가 보기엔 바로 그 지점에서 95%와 5%가 갈렸습니다.
MIT 보고서 역시 핵심 문제는 모델 품질이 아니라 조직과 도구 양쪽의 '학습 격차', 그리고 엉성한 통합에 있다고 결론짓는데, 요약하자면 AI 에이전트의 실패는 기술 자체의 실패라기보다는 기술의 옷을 입고 나타난 조직과 인프라의 문제에 훨씬 가까웠다는 이야기가 됩니다.
그리고 여기 반가운(?) 부분 하나는 조직과 인프라의 문제는 모델의 근본적인 한계와 달리 우리가 직접 손을 댈 수 있는 영역이라는 사실입니다. 결국 가장 큰 컨텍스트 윈도우를 가진 에이전트가 이기는 게임이 아니라, 가장 정성껏 설계된 컨텍스트와 가장 단단하게 받쳐주는 런타임을 가진 쪽이 이기는 게임이라는 것. 적어도 작년 한 해의 데이터는, 그리고 그 험한 확률을 뚫고 살아남은 5%는, 우리에게 대체로 그렇게 말하고 있는 듯합니다.
이 글의 예상 질문
AI 에이전트와 챗봇은 뭐가 다른가요? 챗봇은 기본적으로 대화 중심이라 사용자의 질문에 답을 돌려주면 거기서 역할이 끝나는 반면, AI 에이전트는 목표를 받아 스스로 계획을 세우고 필요한 도구를 호출하며 여러 단계를 실행한 뒤 그 결과를 검토하고 수정하는 한 사이클 전체를 돕는다는 점에서 결이 다릅니다. 단순하게 말하면 '답을 하느냐'가 아니라 '행동을 하느냐'가 둘을 가르는 갈림길인 셈입니다.
정말로 95%가 실패하나요? MIT NANDA 보고서를 기준으로 보면 측정 가능한 손익 효과를 만들어내지 못한 파일럿이 95%였던 건 맞지만, 이 숫자는 '기술이 작동하지 않았다'기보다는 '충분한 준비 없이 도입했다'는 의미에 더 가깝습니다. 같은 보고서가 나머지 5%는 분명히 의미 있는 가치를 만들어냈다고도 말하고 있으니까요.
그럼 모델은 안 중요하다는 건가요? 당연히 중요합니다. 다만 2026년 현재 시점에서 실패의 무게중심이 모델의 추론 능력보다 인프라와 컨텍스트 품질, 거버넌스 쪽에 더 쏠려 있다는 게 여러 현장 데이터에서 반복적으로 확인되는 신호일 뿐, 모델을 가볍게 봐도 된다는 뜻은 아닙니다.
그렇다면 어디서부터 시작하는 게 좋을까요? 전사 도입을 한 번에 노리기보다는 성공의 기준을 명확하게 정해둔 작은 범위의 POC로 빠르게 검증해보는 편이 현실적이고, 그 과정에서도 어떤 모델을 고를지 고민하기에 앞서 데이터 정리와 컨텍스트 파이프라인 점검을 먼저 끝내두는 순서를 권하고 싶습니다.
오픈네트웍시스템 ㅣ 권태규