'AI 에이전트 도입했더니 클라우드 비용이 구독료를 초과했다.' 해외 사례에서만 나오던 이야기가 국내 현장에서도 들리기 시작했다. 굿어스데이터 추창호 기술그룹장이 ZDNet 인터뷰에서 지적한 핵심이 바로 이것이다. 최신 AI 모델로 업그레이드한 뒤 토큰 사용량이 7배 이상 폭증해 서비스를 중단한 사례가 이미 있다. 에이전트는 잘 붙었는데, 청구서가 감당이 안 되는 상황. 이건 기술 실패가 아니라 설계 실패다.
문제의 구조는 단순하다. 과거 사용량 기반 비용 예측은 사람이 API를 직접 호출할 때를 기준으로 설계됐다. 하지만 AI 에이전트는 루프를 돈다. 하나의 사용자 요청이 내부에서 수십 번의 LLM 호출로 펼쳐질 수 있고, 멀티 에이전트 구조라면 에이전트끼리 서로를 재호출하면서 토큰이 기하급수적으로 쌓인다. 추 그룹장의 표현을 빌리면 '서로 자기 업무가 아니라고 책임을 전가하며 루프만 돌고 결과물이 안 나오는 현상'이다. 이 루프가 청구서를 만든다.
그렇다면 비용을 어떻게 잡을까. AWS 서버리스 AI 모델 평가 플랫폼 구축 사례(dev.to)는 여기서 참조할 만한 아키텍처 패턴을 제시한다. 핵심은 세 가지다. 첫째, 실행 전 검증을 분리하라. 이 플랫폼은 Step Functions 워크플로우의 Step 1에서 입력값 유효성 검사를 완전히 분리했다. 아티클이 비어있거나 모델 ID가 잘못됐으면 그 자리에서 종료다. Bedrock 호출이 한 번도 일어나지 않는다. 굿어스데이터가 고객사에 제공하는 '플레이그라운드' 환경의 설계 철학도 동일하다. 실제 프로덕션 투입 전에 모델별 토큰 소모량과 인프라 예산을 시뮬레이션으로 먼저 확인한다.
둘째, 토큰 사용량은 메타데이터로 전량 수집하라. AWS Bedrock의 Converse API는 모든 응답에 inputTokens와 outputTokens를 함께 반환한다. 이 수치를 버리지 않고 누적하면 비용 예측, 이상 감지, 고객사별 청구까지 가능해진다. 토큰 사용량 급증은 곧 에이전트 루프의 이상 신호다. 수집하지 않으면 청구서가 나올 때까지 모른다. 추 그룹장이 '비용 예측 자체가 어려워졌다'고 말한 이유가 바로 이 가시성 부재다.
셋째, API 보안은 Day 1에 잠가라. AWS 사례에서 가장 직접적인 경고가 나온다. '보호되지 않은 채로 파운데이션 모델을 호출하는 API는 공개된 신용카드나 다름없다.' API 키, 사용량 플랜(하루 500회, 월 5000회 쿼터), 요청당 속도 제한, 호출자 로깅을 첫날부터 걸어야 한다. AI 에이전트를 붙이기 전에 이 네 가지가 없다면 외부에 URL이 노출되는 순간 청구서가 폭발한다.
MCP(Model Context Protocol) 프로덕션 가이드(dev.to)는 여기에 거버넌스 레이어를 추가한다. MCP가 'AI를 위한 USB-C'로 불리는 이유는 도구·리소스·프롬프트를 표준화된 인터페이스로 연결하기 때문이다. 그런데 이 표준화가 비용 제어와도 직결된다. MCP 서버는 어떤 툴이 얼마나 호출됐는지 중앙에서 감사 로그를 남길 수 있다. 에이전트가 어떤 외부 API를 몇 번 호출했는지 추적되지 않으면, 비용 이상 탐지는 불가능하다. 툴 호출 승인 절차(MCP 스펙상 호스트가 사용자 확인을 요구할 수 있다)를 내부 고비용 작업에 적용하면 루프 폭주를 구조적으로 차단할 수 있다.
여기서 데이터 품질 문제를 빠뜨리면 설계가 반쪽이 된다. 추 그룹장의 벤치마킹 결과는 명확하다. 최신 AI 모델 알고리즘보다 데이터 품질과 전처리 기술이 성능에 더 큰 영향을 미쳤다. 이 말은 비용 구조와도 연결된다. 정제되지 않은 데이터를 넣으면 모델이 더 많은 토큰을 소모하며 재시도하거나, 엉뚱한 결과를 내서 후처리 에이전트 호출이 추가로 발생한다. 입력 품질을 높이는 것이 곧 토큰 비용을 낮추는 것이다. 금융권 불완전 판매 방지 시스템에서 야간 배치 스케줄링으로 토큰 리밋 안에서 처리량을 최적화한 사례가 이를 증명한다.
테크 리드로서 정리하면 이렇다. 에이전트를 빠르게 붙이는 것과 비용·품질·거버넌스를 동시에 잡는 것은 상충 관계가 아니다. 다만 순서가 있다. 모델을 고르기 전에 토큰 사용량 수집 구조를 잡아라. 에이전트를 배포하기 전에 API 보안과 쿼터 제한을 걸어라. MCP 툴을 연결하기 전에 감사 로그 레이어를 설계하라. 그리고 어떤 모델을 쓰든 입력 데이터 전처리 파이프라인을 먼저 검증하라. 이 네 가지가 없으면 에이전트는 빠르게 붙고, 청구서는 더 빠르게 날아온다.
향후 전망은 냉정하게 봐야 한다. 멀티 에이전트 구조는 아직 '루프만 돌고 결과가 안 나오는' 한계가 뚜렷하다. 추 그룹장이 지적했듯 중간에 사람이 맥락을 잡아줘야 한다. 이는 AI가 인간 개발자를 대체하는 시점이 아직 멀었다는 뜻이기도 하지만, 반대로 말하면 비용 구조를 설계하고 에이전트를 감독하는 역할이 테크 리드에게 새로 생겼다는 의미다. 빠른 도입보다 지속 가능한 운영 구조를 먼저 설계하는 팀이 AI-First 전환의 진짜 승자가 될 것이다.