게이트웨이 레이어를 통해 Microsoft Agent Framework 비용을 절감하는 방법

Microsoft Agent Framework는 프로덕션 환경의 멀티 에이전트 시스템 (multi-agent systems)을 위해 구축되었으며, 바로 이 점 때문에 LLM 비용이 예상보다 빠르게 증가할 수 있습니다. 재시도 (retries), 핸드오프 (handoffs), 도구 (tools), 체크포인트 (checkpoints)가 포함된 워크플로우를 실행 중이라면, 가장 쉬운 비용 절감 방법은 프롬프팅 (prompting)을 더 잘하는 것이 아니라 프레임워크 하단에 게이트웨이 레이어 (gateway layer)를 추가하는 것입니다.

저는 Lynkr를 만들었으므로, 창업자로서 당연히 밝힙니다: 이 기사는 Lynkr를 게이트웨이 예시로 사용합니다. 저는 실용적인 관점을 유지하며 Microsoft Agent Framework 워크로드에서 비용이 실제로 발생하는 지점에 집중하겠습니다.

이것이 왜 실제 Microsoft Agent Framework의 문제인가

현재 Microsoft Agent Framework의 README는 이를 다음과 같은 기능을 갖춘 Python 및 .NET용 프로덕션 등급 프레임워크로 정의합니다:

멀티 에이전트 워크플로우 (multi-agent workflows)
순차적, 동시적, 핸드오프 및 그룹 협업 패턴 (sequential, concurrent, handoff, and group collaboration patterns)
미들웨어 (middleware)
관측성 (observability)
제공자 유연성 (provider flexibility)
체크포인팅 (checkpointing) 및 인간 참여형 (human-in-the-loop) 흐름

이것은 바로 토큰 사용량이 조용히 증가하는 바로 그 종류의 스택입니다.

단일 프롬프트-응답 앱은 추론하기 쉽습니다. 하지만 프로덕션 워크플로우는 그렇지 않습니다. 라우팅 (routing), 재시도 (retries), 다중 에이전트, MCP 도구, 그리고 장기 실행 상태 (long-lived execution state)를 추가하면 동일한 컨텍스트 (context)가 계속해서 반복적으로 전송되기 시작합니다.

이는 네 가지 예측 가능한 비용 누출을 발생시킵니다.

Microsoft Agent Framework 워크로드에서 지출이 발생하는 지점

1. 에이전트 간 반복되는 공유 컨텍스트

멀티 에이전트 시스템은 동일한 컨텍스트의 많은 부분을 재사용합니다:

작업 지침 (task instructions)
도구 정의 (tool definitions)
이전 메시지 (previous messages)
워크플로우 상태 (workflow state)
그라운딩 컨텍스트 (grounding context)

프레임워크가 깔끔하게 오케스트레이션 (orchestration)을 수행하더라도, 모델 제공자는 여전히 반복되는 입력 토큰 (input tokens)을 보게 됩니다.

2. 도구 중심의 단계로 인한 프롬프트 크기 폭증

에이전트가 도구를 사용하기 시작하면, 응답은 단순한 채팅처럼 보이지 않게 됩니다. 다음과 같은 것들이 발생합니다:

검색 결과 (search results)
파일 읽기 (file reads)
JSON 블롭 (JSON blobs)
브라우저 출력 (browser outputs)
실행 추적 (execution traces)

이러한 페이로드 (payloads)는 종종 사용자의 실제 요청보다 훨씬 더 큽니다.

3. 모든 작업에 동일한 모델이 필요하지는 않음

“이것을 분류해줘”, “이 로그들을 요약해줘”, 또는 “다음 작업을 추출해줘”라고 말하는 워크플로 단계 (workflow step)에는 “네 개의 파일에 걸친 어려운 버그를 해결해줘”와 동일한 모델이 필요하지 않습니다.

라우팅 레이어 (routing layer)가 없다면, 팀들은 너무 많은 쉬운 작업들을 프리미엄 모델로 보내면서 과도한 비용을 지불하게 됩니다.

4. 재시도 (Retries)와 루프 (loops)는 낭비를 배가시킵니다

프로덕션 에이전트 시스템은 재시도 (retries), 폴백 (fallbacks), 승인 (approvals), 그리고 재실행 (re-runs)을 수행합니다. 이는 훌륭한 엔지니어링입니다. 하지만 동시에 월말에 토큰 비용이 이상하게 불어나는 원인이 되기도 합니다.

Microsoft Agent Framework에 적합한 게이트웨이 패턴

가장 깔끔한 설정은 다음과 같습니다:

Microsoft Agent Framework 앱
        ↓
     Lynkr 게이트웨이
...

프레임워크는 오케스트레이션 (orchestration) 역할을 계속 수행합니다. 게이트웨이는 그 하단에서 비용 제어를 처리합니다.

이러한 분리가 중요한 이유는, 모든 에이전트, 모든 워크플로 노드 (workflow node), 그리고 모든 환경에 비용 로직을 중복해서 구현하고 싶지 않기 때문입니다.

Lynkr가 프레임워크 하단에서 변화시키는 것

Lynkr는 Claude Code, Cursor, Codex, 그리고 일반적인 OpenAI 호환 워크로드 (workloads)를 위한 셀프 호스팅 LLM 게이트웨이 (self-hosted LLM gateway)입니다. 현재 README 및 벤치마크 보고서에 근거하여, 여기서 안전하게 사용할 수 있는 입증된 사실들은 다음과 같습니다:

버전 9.5.0
13개 이상의 프로바이더 (providers)
베이스 URL (base URL)이 게이트웨이를 가리키도록 설정하면 앱 레이어 (app layer)에서의 코드 변경이 전혀 없음
스마트한 도구 선택 (tool selection) 및 JSON 압축을 통한 벤치마크 기반 토큰 절감 확인
공개된 벤치마크 보고서 기준 약 171ms의 시맨틱 캐시 히트 (semantic cache hits)

Lynkr가 Microsoft Agent Framework에 유용하게 쓰이는 이유는 단순히 “추상화 레이어 (abstraction layer)가 하나 더 추가되는 것”이 아닙니다. 프레임워크는 오케스트레이션 역할을 유지하면서, 게이트웨이가 가장 중요한 세 가지 비용 레버 (cost levers)를 중앙 집중화한다는 점에 있습니다.

1. 프롬프트 및 시맨틱 캐싱 (Prompt and semantic caching)

에이전트 워크플로는 대부분의 팀이 인지하는 것보다 더 자주 반복됩니다.

분류 단계는 동일한 형태의 결과를 반환합니다.
재시도 (retry)는 거의 동일한 것을 다시 요청합니다.
두 번째 에이전트는 거의 동일한 업스트림 컨텍스트 (upstream context)를 받습니다.
인간 참여형 (human-in-the-loop) 재개는 종종 동일한 상태에 하나의 결정이 더해진 것을 다시 재생합니다.

캐싱 (Caching)은 거의 중복되는 작업에 대해 전체 비용을 지불하는 것을 막는 방법입니다.

Lynkr의 공개된 벤치마크 보고서에 따르면, 시맨틱 캐시 히트 (semantic cache hits)는 171ms 만에 반환되었습니다. 이러한 속도는 프로덕션 워크플로 (production workflows)에서 매우 중요한데, 낮은 지연 시간 (latency)이 비용 절감과 결합되어 시너지 효과를 내기 때문입니다.

2. 도구 페이로드 압축 (Tool payload compression)

이는 가장 적게 언급되지만, 가장 유용한 비용 절감 레버 (savings lever) 중 하나입니다.

Microsoft Agent Framework는 도구를 사용하는 워크플로 (workflows)를 구축하기 쉽게 만들어 줍니다. 하지만 도구가 구조화된 출력 (structured output)을 반환하기 시작하면, 병목 현상 (bottleneck)은 단순히 모델의 선택 문제가 아니라 페이로드 (payload) 크기가 됩니다.

Lynkr의 벤치마크 보고서는 다음과 같은 결과를 보여줍니다:

스마트한 도구 선택을 통해 도구 집약적인 요청에서 토큰 (tokens) 53% 감소
벤치마크 시나리오에서 대규모 JSON 도구 결과에 대해 87.6% 압축

이는 로그 (logs), 트레이스 (traces), 추출된 문서 (extracted documents) 또는 구조화된 도구 응답 (structured tool responses)을 주고받는 프레임워크 워크로드 (framework workloads)에 매우 잘 부합합니다.

3. 티어 라우팅 (Tier routing)

모든 오케스트레이션 (orchestration) 단계가 동일한 모델을 호출할 필요는 없습니다.

실용적인 티어링 (tiering) 설정은 다음과 같습니다:

단순 추출 또는 분류 (classification) → 저렴하고 빠른 모델
일반적인 에이전트 작업 → 균형 잡힌 모델
심층 추론 (deep reasoning) 또는 어려운 리팩토링 (hard refactors) → 프리미엄 모델

이것이 "우리는 여러 제공업체를 지원합니다"와 "우리는 능동적으로 비용을 적게 씁니다"의 차이입니다.

Microsoft Agent Framework는 이미 오케스트레이션 표면 (orchestration surface)을 제공합니다. 게이트웨이 (gateway)는 그 아래에 정책 레이어 (policy layer)를 추가합니다.

구체적인 사용 사례: 고객 지원 분류 에이전트 (customer support triage agents)

이것은 제가 충분히 다뤄지지 않았다고 생각하며, Lynkr에 매우 적합한 사용 사례입니다.

Microsoft Agent Framework로 구축된 고객 지원 워크플로 (support workflow)를 상상해 보십시오:

새로운 티켓 (ticket) 수집
제품 영역 및 긴급도 분류 (classify)
문제 요약 (summarize)
내부 문서 검색 또는 검색 (retrieval) 실행
응답 초안 작성 (draft)
모호하거나 위험한 케이스만 더 강력한 모델이나 사람에게 에스컬레이션 (escalate)

이 단계들 중 대부분은 난이도가 동일하지 않습니다.

만약 이 모든 단계에서 동일한 프리미엄 모델을 사용한다면, 다음과 같은 작업에 프리미엄 가격을 지불하게 됩니다:

분류 (classification)
중복 제거 (deduplication)
템플릿 기반 요약 (templated summaries)
기지 답변 조회 (known-answer lookups)
저위험 초안 작성 (low-risk drafts)

바로 이 지점이 게이트웨이 (gateway)가 도움을 주는 부분입니다.

이것이 특히 효과적인 이유

지원 분류 (support triage) 작업에는 게이트웨이 (gateway)가 최적화할 수 있는 세 가지 패턴이 모두 포함되어 있습니다:

반복되는 티켓 형태 (repeated ticket shapes) → 캐싱 가능 (cacheable)
검색/조회로부터 얻은 구조화된 도구 결과 (structured tool results from retrieval/search) → 압축 가능 (compressible)
워크플로 단계 전반에 걸친 혼합된 난이도 (mixed difficulty across workflow steps) → 라우팅 가능 (routable)

따라서 각 에이전트 (agent)에 비용 로직을 직접 심는 대신, 프레임워크 (framework)가 오케스트레이션 (orchestration)을 수행하게 하고 게이트웨이가 각 턴 (turn)의 비용을 결정하도록 하는 것입니다.

예시 아키텍처 (Example architecture)

from openai import OpenAI

client = OpenAI(
...

핵심은 이 정확한 코드 스니펫이 아닙니다. 핵심은 경계 (boundary)입니다:

에이전트 (agents)는 워크플로 로직을 유지합니다.
프레임워크 (framework)는 오케스트레이션 (orchestration)을 유지합니다.
게이트웨이 (gateway)는 제공자 선택 (provider choice), 캐싱 (caching), 토큰 감소 (token reduction)를 처리합니다.

이 워크로드에서 제가 다르게 라우팅했을 방식

만약 제가 지원 분류 (support triage)를 위해 Microsoft Agent Framework를 구성한다면, 보통 다음과 같이 할 것입니다:

티켓 분류 (ticket classification) → 저렴하고 빠른 모델 (cheap fast model)
FAQ / 알려진 이슈 매칭 (FAQ / known-issue matching) → 저렴하고 빠른 모델 + 캐시 (cache)
검색 기반 답변 초안 작성 (retrieval-grounded answer draft) → 중간 단계 모델 (mid-tier model)
모호하거나 법적 이슈가 있거나 고위험인 사례의 에스컬레이션 (escalation) → 가장 강력한 모델 (strongest model)
동일한 이슈에 대한 반복적인 후속 질문 (repeat follow-up questions) → 가능한 경우 캐시 (cache)가 처리하도록 함

이는 "모든 것을 기본적으로 최상위 모델로 설정하고 나중에 프롬프트 엔지니어링 (prompt engineering)이 해결해주길 바라는" 방식보다 훨씬 강력한 운영 모델입니다.

경쟁사들이 여전히 우위를 점할 수 있는 부분

공정성을 위한 참고 사항: 만약 귀하의 최우선 순위가 엔터프라이즈 대시보드 (enterprise dashboards), 중앙 집중식 거버넌스 (centralized governance), 또는 더 깊은 기본 제공 관측성 (out-of-the-box observability)이라면, 다른 게이트웨이 제품들이 이러한 축에서 더 강력할 수 있습니다.

하지만 애플리케이션을 다시 작성하지 않고 에이전트 워크로드 (agentic workloads)의 비용을 줄이려는 Microsoft Agent Framework 팀에게 제가 주목하는 조합은 더 단순합니다:

오케스트레이션 (orchestration)을 위해 프레임워크 (framework)를 유지합니다.
게이트웨이 (gateway)를 한 번 삽입합니다.
캐싱 (caching), 압축 (compression), 계층 라우팅 (tier routing)이 전역적으로 비용 작업을 수행하게 합니다.

실질적인 시사점

Microsoft Agent Framework는 본격적인 에이전트 시스템을 구축하는 것을 더 쉽게 만들어 줍니다. 이는 또한 실수로 비용을 과다하게 지불하게 만드는 것도 더 쉽게 만든다는 의미입니다.

과소평가된 패턴은 "더 저렴한 모델을 선택하는 것"이 아닙니다. 프레임워크 하단에 게이트웨이 레이어 (gateway layer)를 배치하여, 반복되는 컨텍스트 (context), 과도하게 큰 도구 페이로드 (tool payloads), 그리고 단순한 워크플로 (workflow) 단계들이 고도의 추론 (hard reasoning)과 동일하게 비용이 청구되는 것을 방지하는 것입니다.

이것이 바로 여기서 Lynkr의 진정한 유스케이스 (use case)입니다: 단순한 모델 가격이 아니라, 오케스트레이션 오버헤드 (orchestration overhead)에서 발생하는 낭비가 존재하는 프로덕션 멀티 에이전트 워크플로 (production multi-agent workflows).

원하신다면, 지원 분류 (support triage) 워크플로와 구체적인 Lynkr 라우팅 (routing) 설정을 사용한 Microsoft Agent Framework의 전체 예시를 담은 후속 글을 작성할 수 있습니다.

GitHub: https://github.com/Fast-Editor/Lynkr