Field Report · 2026
도구는 준비되었는데 성과가 나지 않는다. 많은 기업이 같은 자리에서 멈춘다. 원인은 모델의 성능이 아니라, 결과만 보고 '일하는 과정'을 설계하지 않은 데 있다.
지난 1~2년 사이 기업들은 앞다투어 AI 에이전트(AI agent, 사람의 지시를 받아 스스로 판단·실행하는 인공지능 소프트웨어)를 도입했다. 시연 화면에서는 막힘이 없다. 그런데 실제 업무에 붙여보면 기대만큼 굴러가지 않는다. 이 간극은 개별 기업의 운이 아니라 산업 전반에서 반복되는 패턴이다.
여러 조사 기관의 2025~2026년 집계는 이 현실을 숫자로 보여준다. 컨설팅 기업 딜로이트(Deloitte)의 2025년 조사에서는 에이전틱 AI(agentic AI)를 완전한 생산 환경까지 가져간 조직이 약 11%에 그쳤다. 가트너(Gartner)는 2027년까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 전망했다.
주목할 점은 실패 원인의 성격이다. 한 분석은 2024~2025년 에이전트 배포 사례에서 범위 확장(scope creep)과 데이터 품질 문제가 전체 실패의 61%를 차지한다고 정리했다. 둘 다 모델의 똑똑함과는 무관한, 설계와 조직 규율의 문제다. 기술이 부족해서가 아니라, 일을 어떻게 흘려보낼지 정하지 않아서 무너진다.
AI 에이전트의 실패는 대부분 모델 성능이 아니라 '워크플로우 설계 부재'에서 비롯된다.
현장에서 가장 흔히 마주치는 장면은 이렇다. 개발자에게 "이 에이전트의 워크플로우(workflow, 입력에서 최종 결과까지 일이 거쳐 가는 단계의 흐름)를 설명해 달라"고 물으면 답이 잘 나오지 않는다. 대신 "이런 기능, 저런 기능을 붙였습니다"라는 기능 목록이 돌아온다.
이것이 핵심 증상이다. 흐름에 대한 깊은 고민 없이 기능 단위로 부품을 따닥따닥 붙인 뒤, "이렇게 하면 동작하겠지, 결과가 나오겠지"라고 가정한다. 그리고 결과가 어긋날 때마다 그때그때 땜질로 보정한다. 판단 → 실행 → 검증 → 피드백으로 이어지는 일의 골격이 처음부터 그려져 있지 않으면, 겉만 그럴듯한 껍데기 에이전트가 된다.
레시피 없이 좋은 재료만 사 모은 주방. 칼도 좋고 팬도 좋고 식재료도 신선하다. 그런데 "무엇을 먼저 손질하고, 어느 단계에서 간을 보고, 어떻게 마무리할지"라는 조리 순서가 없다. 손님 앞에 음식이 나가긴 하지만 매번 맛이 다르다. 도구가 부족한 게 아니라 '순서'가 없는 것이다. AI 에이전트도 같다. 기능(재료)이 아니라 워크플로우(레시피)가 결과를 결정한다.
이유 중 하나는 익숙한 개발 방식의 관성이다. 애자일(Agile)·스크럼(Scrum) 방식에서는 전체 흐름의 설계를 보통 시니어 개발자나 PM(Project Manager)·PL(Project Leader)이 먼저 그려주고, 팀원들은 분담된 기능을 구현한다. 흐름 설계가 '내 일'이 아니었던 구조다.
그런데 에이전트는 다르다. 무엇이 하나의 에이전트인지, 그 경계를 정하는 일 자체가 설계의 출발점이다. 이 판단을 건너뛰고 기능부터 쌓으면, 흐름은 누구의 책임도 아닌 채 비어버린다.
"법률 상담 에이전트를 만들겠다"는 한 문장은 단순해 보이지만, 그 안에는 수많은 하위 기능이 들어 있다. 세무 상담, 형사 자문, 고소장·내용증명 같은 문서 작성……. 이 모두를 하나의 큰 에이전트로 묶을지, 아니면 여러 개의 전문 에이전트로 쪼갤지가 설계의 갈림길이다.
큰 덩어리로 한 통에 만들면 처음에는 빠르고 편하다. 일단 출시할 수 있고 손도 덜 간다. 하지만 덩치가 클수록 흐름을 신경 쓰지 않게 되고 결과에만 매달리게 된다. 무언가 어긋나도 "어느 부분 때문인지" 짚기가 어려워진다. 반대로 잘게 쪼개면 부품마다 품질을 끌어올리고 따로 테스트할 수 있지만, 관리해야 할 연결점과 파이프라인이 늘어난다.
마이크로소프트(Microsoft)의 아키텍처 지침도 비슷한 기준을 제시한다. 기능이 서너 개를 넘어 다섯 가지 이상으로 확장될 전망이라면 모듈형(여러 에이전트로 분리)이 유리하고, 단일 에이전트는 책임이 원래 범위를 넘어 커질수록 유지보수가 어려워진다는 것이다.
| 관점 | 단일(한 덩어리) 에이전트 | 분할(여러) 에이전트 |
|---|---|---|
| 초기 구축 | 빠르고 단순 | 설계·연결에 시간 필요 |
| 부품별 품질·테스트 | 고립해서 검증 어려움 | 각각 따로 검증 가능 |
| 장애 격리 | 한 곳 고장이 전체로 번짐 | 한 곳이 멈춰도 나머지 유지 |
| 고장 위치 추적 | 원인 지목 어려움 | 비교적 명확 |
| 관리 비용 | 낮음(연결점 적음) | 높음(파이프라인 증가) |
| 토큰 비용 | 긴 지시문으로 매 호출 비쌈 | 필요한 지시만 불러와 절약 |
분할이 항상 정답은 아니다. 한 분석은 단일 워크플로우·명확한 경계를 가진 좁은 범위의 프로젝트가 제때 완료될 확률이 65%인 반면, 여러 워크플로우와 통합 지점을 한꺼번에 끌어안은 넓은 범위는 16%에 그쳤다고 정리했다. 에이전트를 너무 많이, 너무 일찍 쪼개 동시에 띄우는 것도 또 다른 실패 경로다. 핵심은 분할 여부 자체가 아니라, 장단점을 끝까지 따져 의도적으로 선택했는가다.
실무 권고: "한 개로 시작해 필요할 때 늘린다"
여러 지침이 공통으로 권한다. 먼저 하나의 에이전트로 시작하고, 새 에이전트를 추가하기 전에 도구(tool, 에이전트가 외부 기능을 불러 쓰는 연결부)부터 붙여본다. 그리고 제약이 그것을 강제할 때 비로소 에이전트를 늘린다. 대부분의 팀은 에이전트를 너무 일찍 늘린다.
또 하나 자주 빠지는 함정은 데이터를 "옆 팀 일"로 미루는 태도다. 개발자는 데이터 웨어하우스(data warehouse, 정형 데이터를 모아둔 저장소)나 데이터 레이크(data lake, 가공 전 원천 데이터까지 폭넓게 담는 저장소)를 자기 영역이 아니라 여기고, "데이터만 주세요" 하고는 그 데이터를 어떻게 가져와 쓸지의 좁은 부분만 본다.
문제는 에이전트의 데이터 흐름이 단방향 조회로 끝나지 않는다는 점이다. 대화 기록 관리나 메모리 기능을 위해 양방향 입출력이 빈번하고, 그 데이터 영역은 특정 서비스 하나만 쓰는 것이 아니라 여기저기서 함께 건다. 기존 시스템(레거시, legacy)에 데이터가 한 덩어리로 묶여 있으면, 막상 에이전트를 쪼개려 할 때 오히려 병목 구간과 관리 포인트가 늘어난다. 데이터 구조를 함께 설계하지 않으면 흐름 설계는 절반만 한 셈이 된다.
주방과 창고가 따로 노는 식당. 요리사는 "재료만 갖다주면 된다"고 생각하지만, 실제로는 조리 중에도 창고를 수시로 들락거린다. 게다가 여러 요리사가 같은 창고를 동시에 쓴다. 창고 동선을 함께 설계하지 않으면 주방이 아무리 좋아도 병목이 생긴다. 데이터 인프라가 바로 이 '창고 동선'이다.
흐름 설계가 막히면 많은 조직이 곧장 외부 솔루션을 찾는다. "정답 같은 제품이 있겠지"라는 기대다. 그러나 솔루션 기반으로 출발하면 그 제품의 제약과 확장 한계가 그대로 내 시스템의 한계가 된다. 정작 무엇을 물어야 할지 모르니 공급업체에 제대로 된 질문도 못 하고, 내부 기술 방향도 보지 못한다.
그러면 다음 수순으로 "해봤다는" 대형 업체를 부른다. 그런데 그들은 성공률을 높이고 기간·공수를 줄이기 위해 자신들이 늘 하던 방식을 고수한다. 이 사이클이 돌수록 워크플로우는 더 방치되고 결과값에만 집착하게 된다. 에이전트 프로젝트인데 정작 에이전트의 단위 경계가 어설프게 잡히고, 그 어설픔이 나중에 고도화를 더 어렵게 만든다.
여기에 도구 자체의 흐름도 한몫한다. 최근 쏟아지는 AI 스튜디오나 에이전트 빌더(agent builder, 코드 없이 에이전트를 조립하는 도구)는 '에이전트 사이의 흐름'은 보여주지만, 그 안에서 일이 어떻게 처리되는지의 워크플로우는 다루지 않는 경우가 많다. 서브 에이전트(sub-agent, 큰 에이전트가 작은 에이전트에게 일을 위임하는 구조) 개념까지 더해지면 에이전트 간 연결은 늘지만, "어디서 무엇 때문에 어긋났는가"는 더 흐려진다.
전통적인 소프트웨어는 결정론적(deterministic)이다. 같은 입력에는 같은 결과가 나온다. 무언가 깨지면 오류 코드가 뜨고, 로그가 어느 지점에서 실패했는지 가리킨다. 데이터베이스 조회가 실패하면 에러 코드, 응용 프로그램 인터페이스(API)가 끊기면 500 응답이 돌아온다. 고장이 눈에 보이고, 기록되며, 대개 재현된다.
AI 에이전트는 그렇게 깔끔하게 실패하지 않는다. 비결정론적(non-deterministic)이어서 같은 입력에도 매번 다른 도구를 고르고, 다른 자료를 가져오고, 다른 답을 낸다. 더 까다로운 점은 자신만만하고 깔끔하게 정돈된 출력을 내놓으면서도 내용은 완전히 틀릴 수 있다는 것이다. 두 번째 단계에서 지시를 잘못 이해하고도, 그 오류를 이후 스무 단계에 조용히 퍼뜨린다. 화면에는 200(정상) 응답이 떠 있는데 답은 틀려 있는 식이다.
고장 신호 없이 멈추는 기계 vs. 조용히 빗나가는 통역사. 일반 기계는 멈추면 경고등이 켜진다. 어디가 문제인지 바로 보인다. 반면 AI 에이전트는 말을 멈추지 않는 통역사에 가깝다. 중간에 한 단어를 잘못 옮겨도 끊김 없이 유창하게 계속 말한다. 듣는 사람은 통역이 매끄러우니 믿어버린다. 정작 처음 빗나간 그 한 단어가 대화 전체를 다른 방향으로 끌고 갔다는 걸 한참 뒤에야 깨닫는다.
각 단계가 꽤 높은 성공률을 가져도, 단계를 곱하면 전체 성공률은 빠르게 무너진다. 한 단계의 성공률이 85%인 에이전트가 8단계를 거치면, 전 과정을 한 번에 옳게 끝낼 확률은 0.85의 8제곱, 약 27%에 불과하다. 네 번 중 세 번꼴로 어딘가에서 빗나간다는 뜻이다. 그것도 요란한 실패가 아니라, 알아채기 힘든 조용한 실패로.
그래서 일반 디버깅이 거의 통하지 않는다. 어느 부품 때문인지 좁혀 들어가려 해도, 단점이 여러 곳에 흩어져 있고 재현조차 어렵다. 반복(iteration)을 통한 개선 자체가 성립하지 않는 상황이 생긴다. 위험이 큰 에이전트라면 기업은 차라리 그 부분을 빼거나, 더 잘게 분해해 안전한 부분만 돌리는 선택을 하게 된다.
전통적 모니터링이 서버 가동률·응답 시간·오류율 같은 결정론적 지표를 본다면, 에이전트에는 추론의 맥락까지 따라가는 관측가능성(observability, 시스템 내부에서 무슨 일이 일어났는지 들여다보는 능력)이 필요하다. 어떤 도구를 호출했고, 무슨 자료를 가져왔으며, 어디서 추론이 본래 경로에서 갈라졌는지를 단계별로 드러내는 것이다.
핵심 개념은 추적(trace)이다. 입력에서 최종 행동까지 모든 단계를 한 줄기로 잇고, 문제가 생기면 그 추적을 재생(replay)해 '처음 빗나간 한 단계'를 찾는다. 근본 원인은 거의 항상 첫 번째 잘못된 판단이기 때문이다. 한 조사에서 생산 환경 팀의 62%가 향후 1년간 가장 시급한 투자 영역으로 관측가능성 개선을 꼽은 것은 이 때문이다. 코드가 아니라 추적이 진실의 원천이 되는, 사고방식의 전환이다.
정리: 에이전트 신뢰성의 세 기둥
① 추적(tracing) — 입력에서 결과까지 흐름을 한 줄기로 잇는다. ② 로깅(logging) — 각 단계의 판단·도구 호출·입출력을 기록한다. ③ 평가(evaluation) — 출력의 품질을 측정 가능한 점수로 바꾼다. 비결정론적 시스템의 디버깅은 이 세 가지가 함께 있어야 성립한다.
이 모든 진단이 추상적으로 느껴진다면, 확인하는 방법은 간단하다. 지금 시장에 나도는 제안요청서(RFP, Request For Proposal)를 펼쳐 보면 된다. 상당수가 "이런 에이전트를 만들어 주세요" 수준에서 멈춰 있고, 그 에이전트가 충족해야 할 조건 자체가 거칠게만 적혀 있다. 흐름·경계·데이터·검증에 대한 요구가 비어 있다. 발주하는 쪽도 무엇을 요구해야 할지 모르기 때문이다. 설계의 공백은 코드 이전에 문서에서 이미 시작된다.
AI 에이전트가 성과를 내지 못하는 이유는 대체로 모델이 부족해서가 아니다. 무엇이 하나의 에이전트인지 경계를 정하고, 판단·실행·검증·피드백이 어떻게 이어질지 흐름을 그리고, 데이터가 어떻게 오갈지 함께 설계하고, 어긋났을 때 어디서 빗나갔는지 추적할 수 있게 만드는 일 — 이 '과정의 설계'를 건너뛰었기 때문이다.
하나로 시작하되 의도적으로 경계를 긋고, 데이터를 남의 일로 미루지 말며, 처음부터 추적·평가를 심어라. 도구가 아니라 흐름이 성과를 만든다.
도구는 이미 충분히 좋다. 부족한 것은 일을 어떻게 흘려보낼지에 대한 깊은 고민이다. 결과에 매달릴수록 과정은 비고, 과정이 비면 결과는 끝내 손에 잡히지 않는다.
본 글은 기업 현장의 AI 에이전트 도입 실패에 관한 한 실무 논의를 출발점으로, 2025~2026년 공개된 산업 조사·아키텍처 지침·관측가능성 연구를 교차 확인해 재구성한 것이다. 주요 수치는 딜로이트·가트너의 2025년 조사 및 다수 배포 사례 분석에서 인용했으며, 단계별 누적 성공률은 단계 성공률 85%·8단계를 가정한 0.85⁸≈27%의 단순 모델에 근거한다. 구체 수치는 조사 표본과 정의에 따라 달라질 수 있다.