에이전트 AI (Agentic AI)를 본 프로덕션(Production) 환경에서 운용하면, 파일럿 단계에서는 보이지 않았던 비용이 급증한다. 본 기사에서는 그 원인을 **6가지 비용 드라이버 (Cost Drivers)**로 분해하고, **품질을 떨어뜨리지 않으면서 비용을 제어하는 5가지 설계 레버 (Design Levers)**를 해설한다. 대상 독자는 시스템 설계, API 연동, 거버넌스, 운용 설계에 종사하는 엔지니어와 아키텍트이다.

어느 기업의 매입채무 (AP) 예외 처리 에이전트. 파일럿 단계에서는 1 트랜잭션당 비용이 충분히 낮게 보였다. 하지만 본 프로덕션 투입 6개월 후, 클라우드 비용은 8배로 뛰어올랐고, 사용자들로부터 응답 지연에 대한 불만이 쏟아졌다.

왜 일어난 일인가. 에이전트 워크플로우 (Agent Workflow)는 단일 모델 호출이 아니다. 다음과 같이 여러 단계가 연쇄된다.

• 케이스 접수
• ERP와 지식 베이스 (Knowledge Base)로부터의 컨텍스트 (Context) 취득 (검색 · 도구 호출)
• 모델에 의한 분류
• 송장과 입고 상태 확인 (도구 호출)
• 데이터 미비 시 재시도 (Retry)
• 권장 사항 또는 에스컬레이션 (Escalation) 생성

각 단계는 단독으로는 저렴하지만, 1건의 성공적인 결과물 (Success Outcome)당 누적 비용은 파일럿의 상상을 훨씬 초과한다. 파일럿은 저볼륨 · 클린 데이터 · 선별된 시나리오에서 동작하기 때문에 이러한 현실이 은폐된다.

중요한 것은 '1 프롬프트당 비용'이 아니라, '1 성공적인 결과물당 비용'이다.

많은 팀이 의도 분류나 필드 추출과 같은 경량 태스크에도 최고 성능 모델을 사용하고 있다. 조달 업무의 초기 카테고리 분류라면 소규모 모델로도 충분하며, 강력한 모델은 모호한 케이스나 고위험 판단에 한정해야 한다.

문서, 트랜잭션 이력, 메타데이터를 '만약을 위해' 모두 프롬프트에 포함하면 추론 비용과 레이턴시 (Latency)가 급증한다. **컨텍스트 길이 (Context Length)는 조용한 비용 킬러 (Cost Killer)**이며, 적절한 검색 설계 없이 에이전트를 운용하면 품질도 저하된다.

IT 인시던트의 기본적인 인리치먼트 (Enrichment)에 장대한 추론 체인은 불필요하다. 모든 태스크를 복잡한 문제로 간주하면 비용과 레이턴시가 불균형하게 증가한다.

벡터 스토어 (Vector Store)에 대한 쿼리, ERP/CRM/HRIS에 대한 API 호출은 AI 레이어의 비용뿐만 아니라 미들웨어 부하, 이벤트 처리, 라이선스 비용 등의 간접 비용을 수반한다. 엔터프라이즈 환경에서는 도구 호출 비용이 AI 추론 비용을 상회하는 경우도 드물지 않다.

로그 저장, 트레이스 (Trace) 처리, 대시보드 운용, 샘플링 리뷰, 회귀 테스트 —— 이것들은 모두 비용이다. 거버넌스를 강화할수록 제어 비용은 늘어난다. 가시성 (Observability)을 깎아내는 것이 아니라, 초기 비용 모델에 포함시키는 것이 올바른 설계 판단이다.

오케스트레이터 (Orchestrator) + 복수의 태스크 에이전트라는 구성은 1 요청당 비용을 승수로 늘린다. 모듈성이나 품질에 명확한 이점이 있는 경우에만 채택해야 하며, 단순한 유스케이스에서는 아키텍처상의 사치에 불과하다.

가장 강력한 레버. 경량 태스크에는 소규모 모델을, 복잡한 추론이나 고위험 판단에는 강력한 모델을 할당한다. 재무 마감(Financial Close) 시에는 구조화된 데이터로부터의 차이 추출에 경량 모델을, 정책과 비즈니스 내러티브를 통합한 코멘트 작성에 강력한 모델을 사용한다. 라우팅 (Routing)의 도입은 아키텍처와 평가의 복잡성을 증가시키지만, 비용 억제 효과는 크다.

다음 세 가지 수법이 실천적이다.

고정밀 검색: 불필요한 문서를 프롬프트에 포함하지 않는다 -
사전 요약: 메인 추론 전에 컨텍스트를 요약한다 -
캐싱 (Caching): 빈번한 컨텍스트를 캐싱한다

고객 운영 (Customer Operations)에서는 모든 이력을 매번 보내는 대신, 관련 요약 + 온디맨드 상세 취득만으로 충분한 경우가 많다. 다만, 요약에 의한 뉘앙스 손실이나 캐시의 노후화에는 주의가 필요하다.

'성공할 때까지 몇 번이고 시도하는' 에이전트는 비용 폭발의 원인이 된다. 모든 워크플로우에 다음을 설정한다.

• 명시적인 정지 조건
• 재시도 상한 (예: 최대 2회)
• 도구 호출 상한 (예: 최대 5회)
• 인간에게로의 에스컬레이션 조건

모든 유스케이스에 완전 자율 모드는 필요하지 않다. 다음 세 가지 모드를 상황에 따라 구분하여 사용한다.

드래프트 모드 (Draft Mode): 에이전트가 초안을 생성하고, 인간이 확인 · 수정 -
레코멘드 모드 (Recommend Mode): 에이전트가 권장 사항을 제시하고, 인간이 승인 -
실행 모드 (Execution Mode): 에이전트가 자율 실행 (리스크가 낮고 신뢰성이 확인된 경우에만)

모든 인터랙션에 풀 로그 (Full Log)를 남기면 비용이 많이 든다. 다음과 같은 계층화가 권장된다.

비용에만 집중하면, 너무 느려서 사용되지 않는 에이전트가 탄생한다. 레이턴시 (Latency)는 사용자 채택률, 프로세스 SLA, 팀 생산성, 그리고 에이전트에 대한 신뢰에 직접적인 영향을 미친다.

설계상의 가장 중요한 판단은 동기/비동기 (Synchronous/Asynchronous)의 구분이다.

동기 모드 (Synchronous Mode): 내부 Q&A, 초기 분류, 짧은 초안, 단순한 추천. 컨텍스트 (Context)를 제한하고 도구 호출 (Tool Call)을 최소화한다.

비동기 모드 (Asynchronous Mode): 복잡한 예외 분석, 보고서 생성, 인시던트 조사, 다중 소스 대조. 사용자는 화면에서 기다릴 필요가 없으며, 상태 알림과 검토 가능한 결과가 중요하다.

용량 계획 (Capacity Planning)은 모델 추론뿐만 아니라 검색, 통합 레이어, 워크플로 엔진, 인간의 승인 용량까지 포함해야 한다. 월말 재무 결산이나 고객 운영의 피크 시기에 사전에 용량을 확보하지 않으면, 레이턴시 악화 → 재시도 (Retry) 증가 → 비용 상승의 악순환에 빠지게 된다.

에이전트 AI의 FinOps를 기술 대시보드만으로 완결해서는 안 된다. 프로덕션 에이전트에는 다음이 필요하다.

비즈니스 오너 (Business Owner): 성과(Outcome)와 예산의 책임자 -
기술 오너 (Technical Owner): 아키텍처와 운영의 책임자 -
지출 한도 및 알림 (Spending Caps & Alerts): 예산 초과를 사전에 감지 -
이용 분석 및 성과 목표 (Usage Analysis & Outcome Goals): 비용 대비 효과를 지속적으로 측정

포트폴리오 리뷰에서는 이용 볼륨뿐만 아니라 총 비용, 성공 성과당 비용, 레이턴시, 수정률, 에스컬레이션 (Escalation) 비율, 비즈니스 가치를 비교한다. 인기 있는 에이전트가 반드시 경제적이라는 보장은 없다.

다음과 같은 징후가 나타난다면, 에이전트는 스케일 (Scale)을 견딜 수 없는 상태다.

• 성공 성과당 비용이 너무 높음
• 레이턴시로 인해 사용자가 수동 프로세스로 돌아감
• 재시도와 루프 (Loop)가 과도함
• 도구 호출 (Tool Call)이 비정상적으로 많음
• 승인 큐 (Approval Queue)가 병목 현상이 됨
• 운영·모니터링 비용을 정당화할 수 있는 비즈니스 가치가 증명되지 않음

이 경우 올바른 판단은 단순히 "모델을 최적화하는 것"만이 아니다. 워크플로 간소화, 자율성 저하, 비동기 UX로의 전환, 혹은 유스케이스 (Use Case) 자체의 중단도 선택지에 포함해야 한다.

에이전트 AI의 FinOps는 비용을 극한까지 낮추는 것이 아니다. 경제성, 사용자 경험, 운영 제어의 균형을 유지하며 스케일링하는 것이다. 파일럿 단계에서 인상적인 데모를 보여주는 것만으로는 불충분하며, 프로덕션 환경에서 지속 가능한 설계가 요구된다.