AI 에이전트는 처음에는 단순해 보입니다.

모델을 가져와 프롬프트 (Prompt)를 추가하고, 아마도 도구 (Tool)를 연결하면 작동합니다. 마치 단 한 번의 API 호출만으로 답변을 얻는 것처럼 느껴집니다.

하지만 에이전트가 실제 작업을 시작하는 순간 그 환상은 사라집니다.

프로덕션 (Production) 환경에서 에이전트는 단 한 번의 호출이 아닙니다. 그것은 루프 (Loop)입니다. 모델을 여러 번 호출하고, 메모리 (Memory)를 검색하며, 도구를 실행하고, 실패 시 재시도 (Retry)하며, 자신의 출력을 스스로 개선할 수도 있습니다.

바로 이 지점에서 비용이 발생합니다.

단순히 토큰 (Tokens)뿐만 아니라 지연 시간 (Latency), 복잡성 (Complexity), 그리고 시스템 부하 (System load) 측면에서도 마찬가지입니다.

대부분의 사람들이 놓치는 멘탈 모델 (Mental model)

대부분의 튜토리얼은 에이전트를 다음과 같이 제시합니다:

사용자 (User) → 모델 (Model) → 응답 (Response)

실제 시스템은 다음과 더 유사합니다:

사용자 (User) → 런타임 (Runtime) → 모델 (Model) → 도구 (Tools) → 메모리 (Memory) → 검증 (Validation) → 모델 (Model) → 응답 (Response)

그리고 이 흐름은 여러 번 반복될 수 있습니다.

각 단계는 비용을 추가합니다.

단순히 돈뿐만이 아닙니다. 시간, 복잡성, 그리고 실패 위험이 추가됩니다.

1. 토큰 비용은 단 한 번의 요청이 아니다

첫 번째 숨겨진 비용은 토큰입니다.

개발자들은 종종 고정된 프롬프트와 함께 단일 요청이 이루어진다고 가정합니다. 하지만 실제로 에이전트는 한 번의 실행 과정 내에서 모델을 여러 번 호출할 수 있습니다.

예를 들어:

• 무엇을 할지 결정하기 위한 한 번의 호출
• 메모리 검색 후 한 번의 호출
• 도구 실행 후 한 번의 호출
• 최종 응답을 생성하기 위한 한 번의 호출

각 호출에는 입력 토큰 (Input tokens)과 출력 토큰 (Output tokens)이 포함됩니다.

만약 메모리 검색까지 포함한다면, 시간이 지남에 따라 프롬프트가 점점 더 커집니다. 이는 토큰 사용량을 더욱 증가시킵니다.

이를 생각하는 간단한 방법은 다음과 같습니다:

const totalTokenCost =
  (numberOfCalls) *
  (inputTokens + outputTokens);
...

문제는 numberOfCalls (호출 횟수)가 항상 예측 가능한 것은 아니라는 점입니다. 이는 에이전트가 어떻게 행동하느냐에 달려 있습니다.
이것이 바로 비용이 예상보다 빠르게 증가할 수 있는 이유입니다.

2. 도구 호출은 무료가 아니다

도구 사용은 종종 모델의 무료 확장 기능처럼 취급됩니다. 그렇지 않습니다.
각 도구 호출은 다음을 추가합니다:
네트워크 지연 시간 (Network latency)
외부 API 비용 (External API cost)
실패 시나리오 (Failure scenarios)
실행 후 추가적인 모델 호출
예를 들어, 간단한 흐름은 다음과 같을 수 있습니다:

모델 결정 → 도구 호출 → 도구 응답 → 모델 해석 → 계속

도구 자체가 저렴하더라도, 이를 둘러싼 오케스트레이션 (Orchestration)은 그렇지 않습니다.
많은 경우, 도구 사용 비용은 도구 그 자체의 비용이 아니라, 도구가 유발하는 추가적인 모델 호출과 지연 시간 (Latency)입니다.

3. 재시도 (Retries)는 모든 것을 배가시킨다

재시도는 비용이 복리로 쌓이기 시작하는 지점입니다.
도구가 실패하면 에이전트가 재시도할 수 있습니다. 모델이 유효하지 않은 출력을 반환하면 시스템이 재시도할 수 있습니다. 검증 (Validation)에 실패하면 시스템이 다시 재시도할 수 있습니다.
각 재시도는 단순히 한 번의 추가 호출로 끝나지 않습니다. 전체 단계를 반복합니다.
간단한 재시도 루프는 다음과 같을 수 있습니다:

for (let i = 0; i < 3; i++) {
  try {
    return await callTool(input);
...

이제 이것이 에이전트 루프 (Agent loop) 내부에서 발생하는 상황을 상상해 보세요.
한 번의 실패는 다음과 같은 결과를 초래할 수 있습니다:

• 다수의 도구 호출 (Tool calls)
• 다수의 모델 호출 (Model calls)
• 더 길어진 실행 시간
  재시도는 필요하지만, 제한이 없다면 비용이 빠르게 증가하게 됩니다.

4. 단계가 거듭될수록 지연 시간 (Latency)이 증가한다

지연 시간은 종종 과소평가됩니다.
각 모델 호출에는 시간이 소요됩니다. 각 도구 호출은 네트워크 지연 (Network delay)을 추가합니다. 각 재시도는 전체 실행 시간을 증가시킵니다.
각 단계가 빠르더라도, 결합된 지연 시간은 눈에 띌 정도로 커질 수 있습니다.
간단한 분석은 다음과 같습니다:

• 모델 호출: 500ms ~ 2s
• 도구 호출: 200ms ~ 1s
• 메모리 검색 (Memory retrieval): 100ms ~ 300ms
  이제 이를 여러 단계에 걸쳐 결합해 보십시오.
  데모에서는 "즉각적인" 것처럼 느껴지는 에이전트가 실제 운영 환경 (Production)에서는 몇 초가 쉽게 걸릴 수 있습니다.
  이것이 항상 문제는 아니지만, 사용자 경험 (User experience) 측면에서는 매우 중요해집니다.

5. 메모리 (Memory)는 가치와 비용을 동시에 더한다

메모리는 강력하지만, 공짜가 아닙니다.
메모리를 검색할 때마다 다음 항목들이 추가됩니다:

• 쿼리 비용 (Query cost) (벡터 검색 (Vector search) 또는 데이터베이스 조회 (Database lookup))
• 추가 토큰 (Additional tokens) (모델에 더 많은 컨텍스트 (Context) 전송)
• 프롬프트 구성 (Prompt construction)의 복잡성
  메모리가 신중하게 필터링되지 않으면 다음과 같은 문제가 발생할 수 있습니다:
• 토큰 사용량의 대폭 증가
• 무관한 컨텍스트 추가
• 모델 정확도 저하
  핵심은 더 많은 메모리가 아니라, 더 나은 메모리입니다.
  현재의 목표와 관련된 내용만 검색하십시오.

6. Reflection(성찰) 및 "thinking(사고)" 단계로 인한 사용량 증가

많은 현대적인 에이전트 패턴에는 Reflection(성찰)이 포함됩니다.
에이전트는 다음과 같은 작업을 수행할 수 있습니다:

• 자신의 출력물 평가
• 다음 단계에 대한 재계획 (Re-plan)
• 중간 결과 요약
  이러한 패턴은 품질을 향상시키지만, 모델 호출(Model calls)을 더 많이 추가합니다.
  예를 들어:

Model → 초안 응답 (Draft response)
Model → 응답 비판 (Critique response)
Model → 응답 개선 (Refine response)
...

이는 토큰(Token) 사용량을 두 배 또는 세 배로 늘릴 수 있습니다.
Reflection(성찰)은 유용하지만, 의도적으로 사용해야 합니다.

7. 비용은 단지 돈만이 아닙니다

사람들이 비용(Cost)을 말할 때, 보통 API 가격을 의미합니다.
실제로 비용에는 다음 사항들도 포함됩니다:

• 지연 시간 (Latency). 느린 에이전트는 사용자 경험을 저하시킵니다.
• 시스템 부하 (System load). 호출이 많아질수록 인프라 사용량이 늘어납니다.
• 실패 표면 (Failure surface). 단계가 많아질수록 무언가 잘못될 확률이 높아집니다.
• 디버깅 복잡성 (Debugging complexity). 움직이는 부품(Moving parts)이 많아질수록 문제를 추적하기 어려워집니다.
  이것이 바로 비용을 단순한 결제 문제가 아닌, 아키텍처적 관심사 (Architectural concern)로 다루어야 하는 이유입니다.

이를 생각하는 간단한 방법

모든 것을 하나의 아이디어로 단순화해야 한다면, 이것입니다:
새로운 기능이 추가될 때마다 비용은 곱절로 늘어납니다.

• 더 많은 도구 (Tools) → 더 많은 호출
• 더 많은 메모리 (Memory) → 더 많은 토큰
• 더 많은 재시도 (Retries) → 더 많은 루프
• 더 많은 추론 (Reasoning) → 더 많은 모델 사용
  에이전트는 선형적으로(Linearly) 확장되지 않습니다. 곱셈적으로(Multiplicatively) 확장됩니다.

실제 현업에서 작동하는 방식

실제 TypeScript 시스템에서 저는 상황을 통제된 상태로 유지하려고 노력합니다.

• 단계(Steps)의 수를 제한하십시오. 에이전트가 무한히 실행되도록 두지 마십시오.
• 프롬프트(Prompts)를 작게 유지하십시오. 관련 있는 컨텍스트(Context)만 포함하십시오.
• 도구(Tools)를 의도적으로 사용하십시오. 모든 것을 노출하지 마십시오.
• 재시도 제한(Retry limits)을 설정하십시오. 무한 루프를 방지하십시오.
• 사용량을 추적(Track usage)하십시오. 토큰, 지연 시간, 실패를 측정하십시오.
  이것들은 최적화(Optimizations)가 아닙니다. 가드레일(Guardrails)입니다.

진짜 핵심 요약 (The real takeaway)

AI 에이전트 (AI agents)는 강력하지만, 공짜로 얻을 수 있는 추상화 (abstractions)가 아닙니다.

시스템에 추가하는 모든 결정에는 비용이 따릅니다. 모든 레이어 (layer)는 복잡성을 더합니다. 모든 재시도 (retry)는 사용량을 배가시킵니다.

목표는 이러한 기능들을 제거하는 것이 아닙니다. 목표는 그것들을 의도적으로 사용하는 것입니다.

특정 문제를 해결하는 단순하고 통제된 에이전트가 모든 것을 하려고 시도하는 복잡한 에이전트보다 종종 더 가치 있습니다.

왜냐하면 프로덕션 시스템 (production systems)에서는 유연성 (flexibility)보다 효율성 (efficiency)과 신뢰성 (reliability)이 더 중요하기 때문입니다.

그리고 숨겨진 비용을 이해하는 것이 실제로 확장 가능한 (scales) 무언가를 구축하기 위한 첫 번째 단계입니다.