토큰 가격이 낮아진다고 해서 AI 비용이 줄어드는 건 아닙니다. 기업이 AI 에이전트가 업무를 실행하는 방식을 다시 설계하지 않는다면, 전체 비용은 계속 늘어날 수 있습니다.
한 기업이 직원 라이선스에 사용 한도를 설정하지 않은 채로 클로드(Claude)에 단 한 달 만에 5억 달러(약 7,000억 원)를 지출했다는 보도가 있었습니다. 매우 이례적인 사례이지만, AI 사용량은 실제로 만들어내는 비즈니스 가치보다 훨씬 빠르게 늘어날 수 있다는 점을 잘 보여줍니다.
예산, 할당량, 모델 라우팅, 사용 정책은 비용을 일정 수준 안에서 관리하는 데 도움이 됩니다. 하지만 불필요한 모델 호출, 과도한 컨텍스트, 워크플로우 안에 이미 포함된 반복적인 추론까지 없애주지는 못합니다.
AI 에이전트 비용은 모델 가격의 문제가 아니라 아키텍처의 문제입니다.
에이전트가 파일럿을 넘어 실제 비즈니스 프로세스에 투입되기 시작하면, 작은 비효율도 수천 번의 실행 과정에서 빠르게 누적됩니다. 파일럿 단계에서는 감당할 수 있었던 비용이 엔터프라이즈 규모에서는 구조적으로 감당하기 어려운 수준이 될 수 있습니다.
더 저렴한 모델이 더 낮은 비용을 보장하지는 않습니다
고객 문의를 처리하는 AI 에이전트를 예로 들어보겠습니다. 이 에이전트는 ServiceNow에서 케이스를 조회하고, Salesforce에서 해당 계정을 매칭합니다. 이후 권한과 정책을 확인하고, 두 시스템을 업데이트한 뒤 Slack으로 지원팀에 알림을 보냅니다.
어떤 아키텍처에서는 이 모든 작업이 각각 별도의 툴로 노출됩니다. 이 경우 모델은 어떤 순서로 작업을 진행할지 직접 판단해야 합니다. 각 응답을 해석하고, 필요한 정보를 계속 기억하며, 문제가 발생했을 때 다음에 무엇을 해야 할지도 결정해야 합니다. 모델로 다시 돌아가는 과정이 반복될수록 유료 호출은 늘어나고, 더 많은 컨텍스트가 필요해지며, 지연 시간과 오류 가능성도 커집니다.
반면 다른 아키텍처에서는 resolve_customer_incident와 같이 거버넌스가 적용된 하나의 비즈니스 기능만 에이전트에 노출합니다. 에이전트는 목표와 필요한 입력값만 전달하고, 이후 정해진 프로세스는 사전에 설계된 워크플로우가 처리합니다. 에이전트는 최종적으로 구조화된 결과만 전달받습니다.
비즈니스 결과는 동일합니다. 하지만 어떤 아키텍처를 선택하느냐에 따라 필요한 모델 작업량, 토큰 비용, 운영 리스크는 크게 달라집니다.
가트너는 에이전틱 모델이 표준 GenAI 챗봇보다 작업당 5배에서 30배 더 많은 토큰을 필요로 할 수 있다고 추정합니다. 결국 토큰 단가가 낮아져도, 에이전트가 처리하는 업무가 늘어나면 전체 비용은 다시 커질 수 있습니다.
하지만 토큰 사용량만으로는 AI가 실제로 어떤 성과를 냈는지 알 수 없습니다. 업무가 끝까지 완료되었는지, 그 결과가 비즈니스 가치를 만들었는지, 그 성과를 내는 데 얼마의 비용이 들었는지가 더 중요합니다.
따라서 기업이 봐야 할 핵심 지표는 성공적인 비즈니스 결과 한 건당 비용입니다.
모델을 최적화하기 전에 실행 경로부터 최적화해야 합니다
대부분의 토큰 최적화는 모델 라우팅, 프롬프트 압축, 캐싱, 예산 설정, 모니터링에서 시작됩니다. 이런 방법들은 워크플로우가 이미 수행하고 있는 모델 호출을 더 효율적으로 만드는 데 도움이 됩니다. 하지만 핵심 질문은 모델 호출을 어떻게 줄일지가 아니라, 애초에 이 단계에서 모델 호출이 필요한지입니다.
GitHub는 반복적인 메타데이터 조회와 라벨 스캔 작업을 모델이 매번 판단하지 않아도 되도록 워크플로우로 분리했습니다. 그 결과 변경 이후 109번의 실행에서 비용을 반영한 Effective Tokens 지표가 62% 감소했습니다.
핵심은 모델의 추론을 줄이자는 것이 아니라, 모델이 꼭 필요한 곳에 쓰이도록 설계하는 것입니다. 모델은 실제 판단이 결과를 좌우하는 단계에서 사용해야 합니다.
반복 업무는 워크플로우에, 판단은 모델에 맡겨야 합니다
세분화된 툴은 탐색이나 단순 조회처럼 리스크가 낮은 업무, 또는 상황에 따라 처리 방식이 달라지는 업무에는 유용합니다. 하지만 이미 규칙과 예외 처리 방식이 정해져 있는 반복적인 업무에 그대로 적용하면 문제가 생깁니다. 모델이 매번 같은 프로세스를 다시 판단하고, 같은 순서를 다시 조율해야 하기 때문입니다.
비즈니스 결과를 기준으로 기능을 설계하면 역할을 더 명확하게 나눌 수 있습니다. 모델은 사용자의 의도를 이해하고, 모호한 부분을 해석하며, 실제 판단이 필요한 결정을 내립니다. 반면 사전에 설계된 워크플로우는 정해진 순서에 따라 업무를 처리하고, 비즈니스 규칙, 승인, 재시도, 오류 복구를 담당합니다.
즉, 에이전트는 “무엇을 해야 하는지”를 이해하는 데 집중하고, “어떤 순서로 어떻게 처리할지”는 사전에 설계된 실행 흐름이 담당하게 됩니다. 이렇게 하면 에이전트가 목표를 실행하기 위한 모든 단계를 매번 하나하나 추론할 필요가 없습니다.
이 원칙은 기업이 Model Context Protocol(MCP) 기능을 설계할 때도 중요합니다. MCP는 에이전트가 툴을 찾고 호출하는 방식을 표준화합니다. 하지만 MCP를 도입했다고 해서 그 툴이 자동으로 효율적이거나, 거버넌스가 적용되어 있거나, 운영 환경에 적합한 상태가 되는 것은 아닙니다.
MCP 서버는 여러 개의 세부 작업을 그대로 에이전트에 노출할 수도 있습니다. 이 경우 에이전트는 어떤 작업을 선택할지, 어떤 정보를 가져올지, 여러 단계를 어떤 순서로 처리할지 매번 판단해야 합니다.
반대로 MCP 서버가 하나의 완성된 비즈니스 기능을 제공할 수도 있습니다. 이 방식에서는 필요한 입력값, 업무에 필요한 컨텍스트, 적용해야 할 규칙, 반환해야 할 결과 형식이 미리 정의되어 있습니다. 에이전트는 복잡한 처리 과정을 직접 조율하지 않고, 정해진 방식으로 실행된 결과만 전달받습니다.
결국 중요한 것은 모델이 어디까지 판단하고, 어디서부터는 미리 설계된 업무 흐름이 처리할지 정하는 것입니다.
기업은 자사만의 비즈니스 지식을 담은 기능을 설계하되, 시스템 연결, ID, 거버넌스, 오류 복구, 유지보수를 위한 공통 기반은 재사용할 수 있어야 합니다. 이러한 기반이 없다면 MCP는 연결 방식을 표준화하더라도, 기존 포인트 투 포인트 연동에서 발생하던 복잡성을 다른 형태로 다시 만들게 될 수 있습니다.
통제와 실행은 함께 설계되어야 합니다
반복 업무를 모델이 매번 직접 판단하고 처리하게 만들 필요는 없습니다. 대신 해당 업무를 정해진 절차에 따라 정확하게 끝까지 처리할 수 있는 구조가 필요합니다. 이때 중요한 것은 단순한 자동 실행이 아닙니다. 누가 어떤 권한으로 실행하는지, 어떤 정책이 적용되는지까지 함께 관리되어야 합니다. 즉, 거버넌스는 실행과 분리될 수 없습니다.
운영 환경에서 AI 에이전트를 안정적으로 사용하려면 여러 시스템에 걸친 업무를 끝까지 처리할 수 있어야 합니다. 동시에 모든 작업이 올바른 사용자 ID, 권한, 승인 절차, 정책에 따라 실행되도록 보장해야 합니다.
요청을 승인하는 시스템만으로는 충분하지 않습니다. 요청이 허용되는지 판단할 수는 있어도, 여러 단계로 이루어진 프로세스를 끝까지 완료하거나 중간에 실패했을 때 복구까지 처리하기는 어렵습니다. 반대로 업무를 실행하는 시스템만 있고 ID, 권한, 감사 기록이 없다면 누가 어떤 권한으로 무엇을 실행했는지 추적하기 어렵습니다.
엔터프라이즈 규모에서 토큰 비용을 최적화하려면, 같은 비즈니스 프로세스 안에서 통제와 실행이 함께 작동하는 플랫폼이 필요합니다.
통제는 누가 어떤 작업을 수행할 수 있는지, 어떤 조건에서 허용되는지를 정의합니다. 실행은 실제 업무를 완료하고, 실패를 처리하며, 결과를 기록합니다.
한 번 구축하고, 모든 에이전트에서 재사용하세요
최적화된 워크플로우는 한 번 쓰고 끝나는 자동화가 아니라, 여러 에이전트가 반복해서 활용할 수 있는 비즈니스 기능이 되어야 합니다. 권한이 있는 에이전트와 모델, 업무 채널은 동일한 비즈니스 로직, 기업 내부 데이터와 업무 맥락, ID, 통제 기준을 바탕으로 이 기능을 호출할 수 있어야 합니다.
이런 공통 기반이 없다면 새로운 에이전트를 만들 때마다 비슷한 기능을 다시 개발해야 합니다. 거버넌스도 에이전트마다 달라져 일관성을 유지하기 어려워집니다. 결국 기업은 나중에 다시 정리하고 통합해야 할 자동화 자산을 계속 늘리게 됩니다.
모델, 에이전트 플랫폼, 사용자 인터페이스는 계속 바뀔 수 있습니다. 하지만 그 아래에서 실제 업무를 처리하는 엔터프라이즈 프로세스는 안정적이어야 합니다. 거버넌스가 적용되어 있어야 하고, 여러 에이전트에서 재사용할 수 있어야 합니다. 이를 가능하게 하는 기반이 바로 통제와 실행을 함께 제공하는 플랫폼입니다.
이러한 전략적 이점은 단순히 토큰 사용량을 한 번 줄이는 데 그치지 않습니다. 재사용 가능한 비즈니스 기능은 새로운 에이전트를 더 빠르게 운영 환경에 적용하고, 더 안전하게 실행하며, 더 낮은 추가 비용으로 측정 가능한 가치를 만들 수 있도록 돕습니다.
에이전트 확장 전에 CIO가 반드시 확인해야 할 다섯 가지 질문
1. 모델이 꼭 판단해야 하는 업무는 어디인가요?
모호한 요청을 해석하거나, 여러 조건을 비교해 결정을 내려야 하는 단계에는 모델이 필요합니다. 반대로 이미 규칙이 정해진 업무까지 모델에 맡기면 비용만 늘어날 수 있습니다.
2. 매번 모델이 다시 판단하지 않아도 되는 단계는 무엇인가요?
승인 절차, 정책 확인, 시스템 업데이트처럼 처리 방식이 정해진 업무는 사전에 설계된 워크플로우로 실행하는 편이 더 효율적입니다. 같은 프로세스를 실행할 때마다 모델이 다시 순서를 판단하게 만들 필요는 없습니다.
3. 한 번 검증한 업무 기능을 여러 에이전트가 함께 사용할 수 있나요?
고객 문의 처리, 직원 온보딩, 인보이스 승인처럼 반복적으로 쓰이는 업무는 특정 에이전트 전용으로 만들기보다 재사용 가능한 비즈니스 기능으로 설계해야 합니다. 그래야 새로운 에이전트를 만들 때마다 같은 기능을 다시 개발하지 않아도 됩니다.
4. 에이전트가 실행하는 업무를 제대로 통제하고 추적할 수 있나요?
누가 어떤 권한으로 무엇을 실행했는지 확인할 수 있어야 합니다. 실행은 되지만 권한, 승인, 감사 기록이 남지 않는다면 엔터프라이즈 환경에서는 안전하다고 보기 어렵습니다.
5. 토큰 사용량이 아니라 실제 성과 기준으로 비용을 보고 있나요?
토큰을 얼마나 썼는지만으로는 AI가 가치를 만들었는지 알 수 없습니다. 중요한 것은 업무가 성공적으로 완료되었는지, 그리고 그 결과 한 건을 만드는 데 얼마의 비용이 들었는지입니다.
결국 앞서가는 조직은 가장 저렴한 모델을 쓰거나 가장 많은 에이전트를 보유한 조직이 아닙니다. AI 도입이 확대되어도 비용, 복잡성, 리스크가 함께 늘어나지 않도록 설계한 조직입니다. 즉, AI 사용량 증가를 지속적인 비즈니스 가치로 전환할 수 있는 아키텍처를 갖춘 조직이 경쟁력을 갖게 됩니다.
AI 에이전트 비용을 줄이고, 더 안정적으로 확장하세요
통제와 실행이 함께 작동하는 플랫폼이 어떻게 불필요한 모델 호출을 줄이고, 에이전트의 업무 실행을 거버넌스 아래 관리하며, 검증된 비즈니스 기능을 기업 전반으로 확장하는지 확인해 보세요.
[1] Axios, “AI sticker shock hits corporate America,” 2026년 5월 28일
[2] Gartner, “Gartner Predicts That by 2030, Performing Inference on an LLM With 1 Trillion Parameters Will Cost GenAI Providers Over 90% Less Than in 2025,” 2026년 3월 25일
[3] GitHub, “Improving token efficiency in GitHub Agentic Workflows,” 2026년 5월 7일
🎬 YouTube채널 바로가기
Youtube 채널에서도 워카토 코리아 관련 다양한 콘텐츠를 만나보실 수 있습니다.