※ 이 글에는 제휴 마케팅 링크가 포함될 수 있으며, 구매 시 수수료를 받을 수 있습니다.
파일럿은 화려했는데, 왜 아무것도 배포되지 않았을까
데모는 완벽했다. 회의실 스크린 위에서 AI 에이전트가 고객 문의를 읽고, CRM을 조회하고, 답변 초안을 뽑아냈다. 임원들은 고개를 끄덕였고 예산이 배정됐다. 그리고 6개월 뒤, 그 에이전트는 여전히 ‘파일럿’이라는 이름표를 단 채 개발 서버 어딘가에서 조용히 돌아가고 있다. 프로덕션으로 넘어가지 못한 것이다.
이건 특정 회사의 무능 때문이 아니다. Gartner는 2027년 말까지 에이전트형(agentic) AI 프로젝트의 40% 이상이 취소될 것으로 전망했다 — 비용, 보안, 조직 변화를 과소평가한 탓이다.(출처) 즉, 지금 이 순간 전 세계에서 진행 중인 에이전트 프로젝트 열 개 중 넷은 이미 사망 예약이 걸려 있다는 얘기다.
이 글의 관점은 하나다. 에이전트 구축의 승패는 모델 성능이 아니라 ‘어떤 하네스(harness) 위에 올리느냐’에서 갈린다. 도구를 고르는 문제가 아니라, 실패를 어디서 감지하고 어떻게 되돌릴지를 설계하는 문제라는 뜻이다. 국내 기업이 지금 놓치고 있는 지점도 정확히 여기다.
두 갈래 길: 로우코드냐, 코드냐
엔터프라이즈 에이전트를 짓는 방식은 크게 둘로 나뉜다. 이 선택이 이후 모든 것을 결정한다.
첫 번째 길은 로우코드다. 대표주자는 Microsoft의 Copilot Studio다. 드래그 앤 드롭에 가까운 화면에서, 1,400개가 넘는 프리빌트 커넥터로 SharePoint·Dynamics·ServiceNow 같은 사내 시스템을 물려 에이전트를 조립한다. 개발자가 아니어도 만들 수 있다는 게 핵심이다. Microsoft 365 Copilot 라이선스(사용자당 월 $30)에 Copilot Studio 기능이 포함돼 있어, 라이선스 보유자는 내부용 에이전트를 바로 만들 수 있다.(출처)
두 번째 길은 코드다. Anthropic의 Claude Agent SDK가 이쪽을 대표한다. Python·TypeScript로 자율 에이전트를 직접 짜는 라이브러리로, 2026년 초 ‘Claude Code SDK’에서 지금 이름으로 바뀌었다.(출처) Bash 실행, 파일 읽기·쓰기, MCP 통합에 hooks·subagents·sessions 같은 재사용 구조를 제공한다. 로우코드가 ‘조립’이라면, 이쪽은 ‘설계’다. 대신 개발 역량이 필요하다.
한 줄로 정리하면 이렇다. 로우코드는 빠르게 시작하고 통제권을 플랫폼에 넘긴다. 코드는 느리게 시작하고 통제권을 손에 쥔다. 어느 쪽이 옳으냐가 아니라, 당신 조직이 어느 통제권을 포기할 수 있느냐의 문제다.
진짜 청구서는 라이선스에 없다
여기서 대부분의 기업이 넘어진다. 라이선스 표를 보고 예산을 짠 뒤, 몇 달 후 전혀 다른 청구서를 받는다.
Copilot Studio의 과금 구조를 뜯어보자. 2025년 9월 1일부터 과금 단위가 ‘메시지’에서 ‘Copilot Credit’으로 바뀌었다. 선구매 크레딧 팩은 월 $200에 25,000 크레딧, 종량제(Pay-as-you-go)는 메시지당 $0.01로 Azure 청구에 얹혀 선결제가 없다.(출처)
숫자만 보면 저렴해 보인다. 함정은 여기 있다. 사용자당 월 $30이라는 라이선스 비용은 예측 가능한 고정비지만, 실제 비용은 라이선스가 아니라 대규모 사용 시의 소비량(크레딧)에서 폭발한다. 종량제는 확장할수록 예측과 통제가 어려워진다. 에이전트 하나가 복잡한 업무를 처리하며 툴을 여러 번 호출하면, 한 번의 ‘대화’가 수십 개의 과금 단위로 쪼개진다. 파일럿 단계에서 월 몇만 원이던 것이, 전사 배포 후 자릿수가 두 개 뛰는 시나리오는 드물지 않다.
Claude Agent SDK 쪽은 인프라와 모델 API 비용을 직접 관리하는 대신, 그 비용이 어디서 발생하는지 눈에 보인다. 통제권을 손에 쥔다는 말의 실질적 의미가 이것이다 — 청구서가 블랙박스가 아니다.
교훈은 단순하다. 에이전트 도입 비용을 계산할 때 라이선스 표는 시작점일 뿐, 종착점이 아니다. ‘사용자 수 × 라이선스’가 아니라 ‘에이전트 하나가 업무 한 건을 처리하며 몇 번 호출하는가’를 먼저 추정해야 한다.
통합과 신뢰성, 두 개의 벽
비용을 통과해도 두 개의 벽이 더 남아 있다. 조사 데이터가 이 벽의 높이를 정확히 알려준다.
첫 번째 벽은 통합이다. 엔터프라이즈 조사에서 응답자의 46%가 ‘기존 시스템과의 통합’을 에이전트 도입의 가장 큰 과제로 꼽았다.(출처) 국내 기업이라면 이 숫자가 더 아프게 다가올 것이다. 20년 된 그룹웨어, 커스텀 ERP, 엑셀로 굴러가는 결재 라인 — 프리빌트 커넥터 1,400개 목록에 당신 회사의 그 시스템은 없을 가능성이 높다. 결국 커스텀 API 커넥터를 짜야 하고, 그 순간 ‘로우코드’의 로우(low)는 사라진다.
두 번째 벽은 신뢰성이다. 그리고 이게 더 무섭다. 한 조사에서 55.4%가 ‘프로덕션에서의 에이전트 신뢰성·환각(hallucination) 관리’를 최우선 도입 장벽으로 꼽았다. LLM은 틀린 답에도 과신하며, 자신이 불확실하다는 신호를 잘 보내지 못하는 경향이 있다. 사람이라면 “이건 제가 잘 모르겠는데요"라고 말할 상황에서, 에이전트는 확신에 찬 오답을 내놓는다. 데모에서는 이게 안 보인다. 프로덕션의 롱테일에서만 터진다. 파일럿이 화려했는데 배포되지 못하는 진짜 이유가 바로 이 신뢰성·거버넌스 마찰이다.
그래서, 무엇을 설계해야 하는가
도구를 고르기 전에 이걸 먼저 설계해야 한다. 이게 이 글의 핵심 주장으로 돌아오는 지점이다 — 승부는 하네스에서 난다.
첫째, 관찰가능성(observability) 레이어를 먼저 깔아라. 모든 결정을 로깅하고, 가드레일을 강제하고, 감사(audit) 가능성을 확보하는 층이다. 에이전트가 무슨 판단을 왜 내렸는지 사후에 추적할 수 없다면, 그 에이전트는 프로덕션에 올릴 수 없다. 신뢰성 문제는 ‘더 좋은 모델’로 푸는 게 아니라 ‘감지와 되돌림 구조’로 푼다.
둘째, 장기 작업은 역할을 쪼개라. Planner–Generator–Evaluator처럼 계획하는 놈, 생성하는 놈, 평가하는 놈을 나누고 구조화된 산출물로 핸드오프하는 멀티에이전트 패턴이 검증되고 있다. 한 에이전트에게 전부 맡기면 환각이 누적된다. 생성한 놈과 검증하는 놈을 분리하면, 최소한 한 번의 자기 점검 관문이 생긴다.
셋째, 되돌릴 수 없는 행동에는 사람 승인 게이트를 박아라. 돈이 움직이거나, 외부로 나가거나, 지울 수 없는 작업 앞에는 반드시 사람의 확인을 세운다. 자율성과 안전의 경계선은 ‘이 행동이 되돌릴 수 있는가’다.
한계도 정직하게 말하자. 이 세 가지를 다 갖춰도 환각이 0이 되지는 않는다. 관찰가능성 레이어 자체가 상당한 엔지니어링 비용이고, 로우코드로 시작한 조직이 이걸 나중에 얹으려면 결국 코드로 내려가야 한다. 완벽한 에이전트는 없다 — 다만 ‘틀렸을 때 빨리 알아채고 되돌리는’ 에이전트와 ‘조용히 틀린 채 굴러가는’ 에이전트가 있을 뿐이다.
국내 기업이라면 어디서 시작할까
정리하면 이렇다. 사내 문서 검색이나 정형화된 문의 응대처럼 범위가 좁고 되돌리기 쉬운 업무라면, Copilot Studio 같은 로우코드로 빠르게 파일럿을 돌려 감을 잡는 게 맞다. 이미 Microsoft 365를 쓴다면 진입 마찰도 낮다.
반대로 여러 시스템을 넘나들며 판단하고 실행하는 자율성 높은 워크플로우, 그리고 청구서와 로직을 손안에 쥐어야 하는 경우라면 Claude Agent SDK처럼 코드 기반 하네스로 가는 편이 길게 봐서 유리하다.
무엇을 고르든, 잊지 말아야 할 한 문장. 에이전트 프로젝트의 40%가 취소된다는 통계에서 살아남는 쪽은, 가장 똑똑한 모델을 쓴 조직이 아니라 ‘틀렸을 때를 가장 잘 설계한’ 조직이다. 데모의 화려함이 아니라, 프로덕션의 지루한 방어선이 승부를 가른다.
당신 회사의 첫 에이전트는 완벽할 필요가 없다. 다만 틀렸을 때 그걸 당신이 가장 먼저 알아야 한다.