
MCP의 Progressive Discovery와 TOON으로 에이전트를 자기 진화시키기 【AI FinOps】
요약
AI 에이전트 운용 시 발생하는 토큰 비용 증가와 추론 정밀도 저하 문제를 해결하기 위한 AI FinOps 전략을 소개합니다. MCP의 Progressive Discovery와 TOON 형식을 도입하여 컨텍스트 고정비를 절감하고 에이전트의 자기 진화 파이프라인을 구축하는 방법을 다룹니다.
핵심 포인트
- TOON(Token-Optimized Object Notation)을 통한 구조화 데이터 메모리 압축
- Progressive Discovery 기법으로 MCP 도구의 동적 로드 및 토큰 절감
- 에이전트 스스로 시스템 규칙을 재작성하는 자기 진화 파이프라인 구축
- 컨텍스트 윈도우 최적화를 통한 추론 정밀도 향상
서론
2026년, AI 에이전트 운용에 있어 가장 큰 장벽은 **토큰 소비 비대화로 인한 비용 증가와 추론 정밀도 저하 (Lost-in-the-middle 문제)**입니다.
에이전트가 자율적으로 장시간 가동 (Long-Running Tasks)하게 되면, 매 턴 소비되는 "컨텍스트 고정비"가 무시할 수 없는 수준이 됩니다.
본 기사에서는 이 과제 (AI FinOps)에 대처하기 위해, MCP (Model Context Protocol) 도구의 고정비를 극적으로 절감하는 "Progressive Discovery"와 상태 관리를 경량화하는 "TOON (Token-Optimized Object Notation)"을 도입하고, 나아가 이를 에이전트의 **자기 진화 파이프라인 (Self-Evolution Pipeline)**에 통합한 사례를 소개합니다.
베이스가 되는 아키텍처: 3자 자기 진화 파이프라인
에이전트는 자신을 최적화하기 위해 다음과 같은 자기 진화 (Self-Evolution) 파이프라인을 정기적으로 실행합니다.
1. [정보 수집] 최신 트렌드 (Zenn/Qiita/X 등)를 Web 검색으로 수집
2. [분석 집적] NotebookLM의 API를 통해 소스를 투입하고, 개선안을 자동 추출
3. [구현] 에이전트 스스로 자신의 시스템 규칙 (AGENTS.md 등)을 재작성
...
개선 1: 구조화 데이터의 "TOON"화를 통한 메모리 압축
문제: JSON을 이용한 트래킹의 한계
지금까지 에이전트의 테스트 결과나 진행 상황 (태스크 상태)의 트래킹에는 JSON 형식을 사용해 왔습니다. 하지만 중첩(Nest)의 깊이나 키(Key) 이름의 반복으로 인해, 이력이 축적됨에 따라 토큰 수가 폭발적으로 증가하게 됩니다.
해결책: TOON 채택
冗長한 JSON을 폐지하고, 2026년의 최신 트렌드인 **TOON (Token-Optimized Object Notation)**을 채택했습니다.
상태 관리 프롬프트를 다음과 같이 개정했습니다.
- 구조화 데이터: 테스트 결과나 태스크 상태는 JSON 형식으로 추적
+ 구조화 데이터: 테스트 결과나 태스크 상태는, 冗長한 JSON 형식을 피하고 최신 트렌드인 TOON 등의 고압축 포맷을 활용하여 추적
개선 2: MCP 도구의 "Progressive Discovery (지연 로드)"
문제: 도구 정의의 고정비 압박
다기능 MCP 서버 (GitHub 조작, 로컬 파일 조작, 브라우저 자동화 등)를 연결하면, 초기화 시 수십 개의 도구 정의가 컨텍스트에 로드됩니다. 이는 한 번도 사용하지 않는 도구라 할지라도 매 턴 수십~수백 토큰의 고정비를 계속 지불해야 함을 의미합니다.
해결책: 태스크 진행에 따른 동적 로드
도구 노출의 최소 권한 원칙을 추진하여, 태스크의 진행에 따라 필요한 도구만을 동적으로 로드하는 "Progressive Discovery"를 규칙화했습니다.
settings.json의 mcpServers 설정에서 다음과 같이 규칙을 철저히 합니다.
처음부터 모든 기능을 포함하지 않고, 필요한 것만 includeTools로 좁히도록 설정합니다.
{
"github": {
"command": "npx",
...
에이전트의 시스템 규칙 (mcp-servers.md)에는 다음 조항을 추가했습니다.
불필요한 도구는 한꺼번에 모두 로드하지 말고, 태스크의 진행에 따라 includeTools를 동적으로 재작성하여 로드할 것.
이를 통해 LLM의 컨텍스트 윈도우 (Context Window) 소비를 억제하고, 정말 중요한 코드 분석이나 추론에 토큰을 할당하는 것이 가능해집니다.
향후 전망: Retrieval-Based Memory로의 진화
이번 파이프라인 실행 시, 추출·집적 대상인 NotebookLM으로부터 **"다음 자기 개선안"**으로서 다음과 같은 고도의 피드백이 반환되었습니다.
RAG적인 "Retrieval-Based Memory (검색 기반 메모리)"의 학습과 규칙화
모든 이력을 컨텍스트에 넣는 것이 아니라, 진행 중인 태스크와 관련된 과거의 기억이나 상태만을 동적으로 검색·추출하여 포함하도록 최적화할 것.
다음 자기 진화 파이프라인에서는, 이 NotebookLM의 제안을 바탕으로 에이전트가 자율적으로 RAG 기반의 메모리 관리 (Context Engineering)를 구현할 예정입니다.
요약
| 개선 항목 | 변경 규모 | 토큰 절약 효과 | 추론에 미치는 영향 |
|---|---|---|---|
| TOON 도입 | 소 | 대 (이력 축적 시 비용 감소) | 문맥 압박 방지 |
| Progressive Discovery | 중 | 대 (매 턴마다 발생하는 고정비 감소) | Lost-in-the-middle 회피 |
"에이전트 스스로 최신 트렌드를 학습하고, 자신의 규칙을 다시 쓰게 만드는" 접근 방식은 AI FinOps를 실천하는 데 있어 매우 강력합니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기