[Brolog] AI Assistant 적용 과정 - Agent 구조와 API 사용량 관리 시 고려사항
🧩 AI Assistant 적용 이후 확인한 Agent 실행 구조와 API 사용량 문제
이전 글에서는 Brolog 프로젝트에 AI Assistant 기능을 적용하면서 발생했던 문제와 해결 과정을 정리했다.
Vercel AI Gateway 대신 Google AI Studio API를 사용하도록 변경했고, AI SDK Provider 버전 충돌 문제까지 해결하면서 기본적인 AI 요청 흐름을 구성할 수 있었다.
하지만 실제 테스트 과정에서 예상하지 못한 부분을 발견했다.
사용자는 질문 하나만 입력했지만, 내부적으로는 여러 번의 AI API 요청이 발생하고 있었다.
처음에는 API 호출 로직이나 설정 문제라고 생각했지만, 원인은 MCP와 Tool을 사용하는 Agent 구조 자체에 있었다.
이번 글에서는 MCP 기반 Agent 환경에서 하나의 질문이 어떻게 여러 LLM 호출로 처리되는지, 그리고 무료 API 환경에서 사용량을 어떻게 관리해야 하는지 정리한다.
🔍 실제 로그에서 확인한 AI Agent API 호출 구조
MCP 기반 AI Assistant를 적용한 이후 실제 동작을 확인하기 위해 Google AI Studio 사용량과 Vercel Function 로그를 함께 확인했다.
처음 예상했던 것은:
사용자 질문 1회
↓
AI API 요청 1회
와 비슷한 구조였다.
하지만 실제 로그를 확인해보니 하나의 질문에서도 여러 번의 모델 호출이 발생하고 있었다.
예를 들어:
사용자 질문
↓
LLM 판단
↓
MCP Tool 실행
↓
추가 LLM 호출
↓
최종 답변 생성
과 같은 과정이 진행되면서,
사용자가 입력한 질문 수보다 실제 API 요청 수와 Token 사용량이 더 크게 발생했다.
이 과정을 통해 AI Agent 환경에서는 단순히 "몇 번 질문했는가"가 아니라,
하나의 요청이 내부적으로 몇 단계의 모델 호출을 발생시키는지까지 고려해야 한다는 점을 확인했다.
🛠️ 일반적인 AI 호출 방식과 Agent 실행 구조의 차이
일반적인 AI API 호출 구조는 다음과 같다.
사용자 질문
↓
LLM 요청
↓
AI 답변 반환
사용자 입장에서는 질문 하나에 답변 하나가 반환되기 때문에 하나의 API 요청만 발생한다고 생각하기 쉽다.
하지만 MCP(Model Context Protocol)와 Tool을 사용하는 Agent 구조에서는 처리 과정이 달라진다.
Agent는 단순히 답변을 생성하는 것이 아니라,
사용자의 요청을 분석하고,
필요한 데이터를 검색하고,
검색 결과를 다시 판단한 뒤,
최종 답변을 생성한다.
즉 하나의 질문이 여러 단계의 LLM 호출 과정으로 처리될 수 있다.
🔄 MCP Tool 기반 문서 검색 Agent 실행 흐름
Brolog의 AI Assistant는 문서 기반 질문 답변을 위해 MCP Tool을 활용한다.
예를 들어 사용자가 다음과 같은 질문을 입력한다고 가정한다.
"Nuxt 설치 방법 알려줘"
내부적으로는 다음과 같은 과정이 진행될 수 있다.
1. LLM 호출
사용자 질문 분석
↓
문서 검색 필요 여부 판단
2. MCP Tool 호출
list-pages 실행
↓
관련 문서 목록 탐색
3. LLM 호출
Tool 결과 확인
↓
필요한 문서 판단
4. MCP Tool 호출
get-page 실행
↓
실제 문서 내용 조회
5. LLM 호출
검색 결과 기반 최종 답변 생성
사용자는 질문 한 번만 했지만 내부적으로는:
사용자 질문 1회
=
LLM 요청 여러 번
+
Tool 실행 여러 번
이 발생할 수 있다.
따라서 AI 서비스 사용량을 관리할 때는 단순히 사용자 질문 개수만 보는 것이 아니라 Agent 내부에서 발생하는 모델 호출 횟수까지 고려해야 한다.
⚙️ MCP Agent 실행 과정과 Step 제한의 필요성
AI SDK에서는 Agent 실행 단계를 제한할 수 있다.
예:
stopWhen: stepCountIs(5)
여기서 Step은 단순히 답변 횟수를 의미하지 않는다.
Agent 내부에서는 다음 과정들이 포함된다.
LLM 판단
↓
Tool 호출
↓
Tool 결과 확인
↓
추가 판단
Step 제한을 너무 높게 설정하면 다음 문제가 발생할 수 있다.
불필요한 LLM 호출 증가
↓
API 사용량 증가
↓
응답 시간 증가
↓
무료 Tier 한도 빠른 소모
문서 검색 기반 AI Assistant에서는 무한한 탐색보다 제한된 검색 과정이 더 적합하기 때문에 적절한 Step 제한이 필요하다.
Brolog에서는 다음과 같은 기준으로 관리하는 것이 적합하다고 판단했다.
const MAX_STEPS = 4 ~ 5
🎛️ Token과 Retry 설정을 통한 API 사용량 관리
Agent 실행 과정에서는 Step뿐 아니라 출력량과 재시도 횟수도 API 사용량에 영향을 준다.
maxOutputTokens
maxOutputTokens: 2048
AI 모델이 생성할 수 있는 최대 출력 Token 수를 의미한다.
높게 설정하면 긴 답변 생성이 가능하지만,
반대로:
더 많은 Token 사용
↓
비용 증가 가능
↓
응답 시간 증가
문제가 발생할 수 있다.
문서 기반 Q&A 서비스에서는 일반적으로 1024~2048 정도면 충분하다고 판단했다.
maxRetries
maxRetries: 1
API 요청 실패 시 재시도 횟수를 의미한다.
예:
첫 요청 실패
↓
재시도
↓
성공
형태로 동작한다.
하지만 무료 API 환경에서는 재시도 역시 추가 요청으로 계산된다.
Brolog 환경에서는 다음과 같은 기준으로 관리하는 것이 적합하다고 판단했다.
maxRetries: 1
📊 Google AI Studio API 제한과 사용량 관리 이해
Google AI Studio에서 제공하는 모델들은 무료 사용 범위가 존재하지만 API 호출 제한이 존재한다.
대표적인 제한 항목은 다음과 같다.
| 항목 | 의미 |
|---|---|
| RPM | Requests Per Minute |
| TPM | Tokens Per Minute |
| RPD | Requests Per Day |
RPM (Requests Per Minute)
분당 API 요청 수 제한이다.
예:
RPM 15
이라면 1분 동안 최대 15개의 API 요청이 가능하다.
중요한 점은:
사용자 질문 횟수 != API 요청 횟수
라는 것이다.
Agent 구조에서는:
질문 1회
↓
LLM 호출 4회
가 발생하면 RPM 기준으로 4개의 요청을 사용한다.
TPM (Tokens Per Minute)
분당 처리 가능한 Token 양이다.
입력 Token과 출력 Token을 모두 포함한다.
예:
사용자 질문
1000 Token
+
검색 문서
5000 Token
+
AI 답변
1000 Token
=
7000 Token
을 사용할 수 있다.
문서 검색 AI에서는 긴 문서를 Context로 전달하는 경우가 많기 때문에 RPM보다 TPM 제한이 먼저 문제가 될 수도 있다.
RPD (Requests Per Day)
하루 API 요청 제한이다.
예:
RPD 1500
이면 하루 동안 최대 1500번의 API 요청이 가능하다.
하지만 Agent 구조에서는:
사용자 질문 1회
↓
여러 API 요청 발생
하기 때문에 실제 사용자 질문 가능 수는 더 적다.
💰 무료 API 환경에서 고려해야 할 비용 관리 요소
웹 서비스에서 ChatGPT나 Gemini를 사용하는 것과 API를 사용하는 것은 다르다.
웹 서비스:
서비스 제공자가 비용 관리
↓
사용자는 서비스 이용
API:
개발자가 직접 모델 호출
↓
사용량 제한과 비용 관리 필요
구조다.
따라서 Google AI Studio, OpenAI API, Vercel AI Gateway 모두 API 사용량 관리 관점으로 접근해야 한다.
🚀 AI 기능 구현 과정에서 확인한 운영 고려사항
현재 Brolog에서는 다음 기준으로 AI 사용량을 관리할 예정이다.
Step 제한
+
maxOutputTokens 제한
+
Retry 제한
+
무료 Tier 모델 활용
+
환경 변수 기반 Model 관리
특히 MCP 기반 문서 챗봇은 일반적인 Chat API보다 내부 AI 호출 횟수가 증가할 수 있다.
따라서 비용 기준은:
사용자 질문 개수
×
Agent 내부 실행 Step
관점으로 접근해야 한다.
마무리
AI Assistant를 추가하면서 단순히 API Key를 연결하면 끝날 것이라고 생각했지만,
실제 Agent 구조에서는 하나의 질문도 여러 단계의 AI 판단 과정으로 처리된다는 것을 확인하며 고려해야 할 것이 많다는 것을 확인했다.
특히 MCP와 Tool을 사용하는 구조에서는:
사용자 질문
↓
LLM 판단
↓
Tool 실행
↓
추가 판단
↓
최종 답변
이라는 흐름이 발생한다.
따라서 AI 기능을 운영할 때는 단순히 "몇 명의 사용자가 몇 번 질문했는가"가 아니라,
내부적으로 몇 번의 모델 호출이 발생하는지를 기준으로 사용량과 비용을 관리해야 한다.
이번 과정을 통해 AI Assistant를 적용할 때는 단순히 모델을 연결하고 답변을 생성하는 것만 고려해서는 안 된다는 점을 확인했다.
Agent 구조에서는 Tool 호출과 추가 LLM 실행 과정으로 인해 예상보다 많은 API 요청이 발생할 수 있으며, 이러한 호출 구조와 사용량 제한까지 함께 고려해야 한다는 것을 알게 되었다.
이번 경험을 통해 AI 기능 구현은 단순히 API를 연결하는 것으로 끝나는 작업이 아니라,
Agent가 어떤 방식으로 동작하고, 내부적으로 얼마나 많은 모델 호출이 발생하며, 이를 어떻게 제어할 것인지까지 설계해야 하는 영역이라는 점을 알게 되었다.
앞으로 Brolog뿐만 아니라 다른 AI 기반 프로젝트를 구현할 때도 기능 구현 과정에서 이러한 운영 요소들을 함께 고려하며 설계해 나갈 예정이다.