AI 에이전트, '탑재'와 '프로덕션' 사이의 거리
2026년 기업 앱의 80%가 AI 에이전트를 탑재했지만, 실제 프로덕션까지 간 곳은 31%에 그칩니다. 그리고 에이전트 프로젝트의 40%가 취소될 거라는 전망도 있습니다. 데모와 실전 사이의 거리를, 직접 에이전트를 만들어 본 입장에서 정리했습니다.
'AI 에이전트'는 올해 가장 뜨거운 단어입니다. 그런데 숫자를 들여다보면, 뜨거운 만큼 냉정한 간극도 보입니다. 만드는 것과 실제로 돌리는 것은 다른 일이라는 걸, 데이터가 그대로 보여줍니다.
숫자로 보는 간극
2026년 1분기에 출시·업데이트된 기업 애플리케이션의 **80%**가 AI 에이전트를 하나 이상 탑재했다고 합니다(2024년 33%에서 급증). 그런데 실제로 에이전트를 프로덕션에서 운영 중인 기업은 **31%**에 그칩니다. 은행·보험이 47%로 앞서지만, 전체로 보면 격차가 큽니다.
더 뼈아픈 전망도 있습니다. 여러 분석기관은 에이전트 프로젝트의 40% 이상이 2027년까지 취소될 것으로 봅니다. 이유는 비용 급증, 불분명한 사업 가치, 부실한 위험 통제입니다. 반면 이미 성과를 내는 곳도 있어서, 도입까지 걸린 기간(time-to-value)의 중앙값은 약 5개월로 보고됩니다. 즉 잘되는 곳과 엎어지는 곳이 뚜렷이 갈립니다.
데모는 쉽고, 프로덕션은 어렵다
왜 이런 간극이 생길까요. 에이전트 데모는 정말 쉽습니다. 몇 줄로 "스스로 판단해 일하는 봇"을 만들어 보이는 건 하루면 됩니다. 그런데 그걸 매일, 실제 데이터로, 안정적으로 돌리는 순간 전혀 다른 문제들이 쏟아집니다.
- 오래 걸리는 작업이 겹치면 어떻게 되나
- 같은 일을 중복 처리하거나 놓치면 어떻게 막나
- 뭔가 잘못됐을 때 어디서 틀어졌는지 보이나
- 비용이 조용히 새고 있지는 않나
화려한 데모에는 이런 게 없습니다. 하지만 프로덕션은 바로 이 지루한 것들의 합입니다.
직접 만들어 보니
지난 시리즈에서 저도 사내용 에이전트 파이프라인을 만들었습니다. 돌이켜 보면, 정작 시간을 많이 쓴 건 "똑똑한 에이전트"가 아니라 그 지루한 것들이었습니다.
- 작업이 겹치지 않게 하는 소비 루프(cron 대신 fixedDelay)
- 쓰는 파일과 읽는 파일이 부딪치지 않게 하는 봉인
- 오래 걸려도 진행이 보이게 하는 단계별 로그
- 출력이 제멋대로 나오지 않게 하는 스키마 주입
에이전트를 "붙이는" 데는 하루가 걸렸지만, 이걸 믿고 돌릴 수 있게 만드는 데는 며칠이 걸렸습니다. 그리고 그 며칠이 데모와 프로덕션을 가르는 거리였습니다.
왜 어떤 곳은 되고 어떤 곳은 안 되나
성과를 내는 곳들에는 공통점이 있습니다. '가장 똑똑한 에이전트'가 아니라 **'가장 좁고 명확한 과제'**를 골랐다는 점입니다. 이를테면 영업 초기 응대나 정형화된 문서 처리처럼, 성과가 숫자로 바로 보이는 일부터 붙인 곳들이 회수 기간이 짧았습니다. 반대로 "알아서 다 해 주는 만능 비서"를 노린 프로젝트일수록, 비용만 쓰고 접히는 경우가 많았습니다.
이 목록이 추상적으로 들릴 수 있지만, 하나하나가 실제로 서비스를 멈춰 세우는 것들입니다. 겹쳐 실행돼 같은 작업을 두 번 하거나, 조용히 실패했는데 아무도 몰라 며칠 뒤에야 발견하거나, 잘 돌던 게 어느 날 비용 폭탄으로 돌아오거나. 데모에서는 "한 번 잘 도는 걸" 보여주면 끝이지만, 프로덕션은 천 번째, 만 번째에도 같아야 합니다. 바로 이 '항상 같음'을 만드는 게 어렵고, 그래서 대부분이 파일럿에서 멈춥니다.
그래서 어떻게 접근할까
취소되는 40%에 들지 않으려면, 저는 순서를 뒤집는 게 낫다고 봅니다. "일단 똑똑한 에이전트부터"가 아니라, "작게, 검증 가능하게, 관측 가능하게" 먼저 세우는 것입니다.
- 범위를 좁게 잡아 명확히 성과가 보이는 작업부터.
- 잘못됐을 때 바로 드러나는 로그·검증 장치를 처음부터.
- 비용을 설계 단계에서 관리(호출 수·토큰).
덧붙이면, 저는 에이전트를 '똑똑함'으로 자랑하려 하지 않습니다. 자랑거리는 데모에서나 통하고, 현장에서 칭찬받는 건 "한 번도 안 멈췄다"는 쪽입니다. 그래서 새 에이전트를 붙일 때 스스로에게 던지는 질문은 "이게 얼마나 대단한가"가 아니라 **"이게 새벽 세 시에 조용히 실패하면 내가 알 수 있나"**입니다. 이 질문에 '그렇다'고 답할 수 있을 때만 프로덕션에 올립니다.
이렇게 하면 화려하진 않아도, 적어도 엎어지지 않는 에이전트가 됩니다. 그리고 현장에서는 화려함보다 "엎어지지 않음"이 훨씬 귀합니다. 결국 에이전트의 성패는 모델의 지능이 아니라, 그 지능을 믿고 맡길 수 있게 감싼 구조에서 갈립니다. 그 구조를 먼저 세운 팀이 파일럿을 넘어 프로덕션까지 갑니다.
정리
- 기업 앱의 80%가 에이전트 탑재, 그러나 프로덕션은 31% — 간극이 크다.
- 에이전트 프로젝트 40%+ 취소 전망(비용·모호한 가치·부실한 통제).
- 데모는 쉽고 프로덕션은 지루한 것들의 합(겹침 방지·검증·관측·비용).
- 취소되지 않으려면 작게·검증 가능하게·관측 가능하게 먼저.
참고 자료