AI 코딩 워크플로우를 위한 LiteLLM vs Lynkr: 토큰 절감이 실제로 발생하는 지점

대부분의 LLM 게이트웨이 (gateway)는 동일한 것을 약속합니다: 하나의 엔드포인트 (endpoint), 그리고 다양한 제공자 (providers). 그 부분은 유용하지만, AI 코딩 워크플로우에서 실제 절감이 발생하는 지점은 아닙니다.

비용이 많이 발생하는 부분은 반복되는 코딩 세션 내부에서 일어나는 일들입니다: 과도하게 큰 도구 스키마 (tool schemas), 거대한 JSON 도구 결과값, 반복되는 컨텍스트 (context), 그리고 필요하지 않은 턴 (turns)에 비싼 모델을 사용하는 것입니다.

저는 Lynkr를 만들었으므로, 이를 창업자로서의 비교로 받아들여 주시기 바랍니다. 솔직하게 말씀드리겠습니다: LiteLLM은 견고한 제공자 추상화 계층 (provider abstraction layer)입니다. 하지만 여러분의 목표가 구체적으로 Claude Code, Cursor, 또는 Codex 스타일의 워크플로우에서 지출을 줄이는 것이라면, 차이점은 "어떤 게이트웨이가 더 많은 제공자를 지원하는가"가 아닙니다. 차이점은 게이트웨이가 모델에 도달하기 전에 토큰을 절감하느냐 하는 것입니다.

대부분의 "게이트웨이 절감" 주장의 문제점

게이트웨이들이 비용을 절감한다고 주장하는 몇 가지 일반적인 방식이 있습니다:

• 더 저렴한 모델로 라우팅 (route)
• 폴백 (fallbacks) 추가
• 트래픽 중앙 집중화
• 예산 추적
• 정확히 반복되는 프롬프트 캐싱 (cache)

이 모든 것들은 도움이 됩니다.

하지만 코딩 워크플로우는 비용 구조가 다릅니다:

• 동일한 레포지토리 (repo) 컨텍스트가 계속해서 전송됨
• 도구 정의 (tool definitions)가 매 요청마다 부풀어 오름
• 도구 출력값이 매우 클 수 있음
• 모든 턴이 가장 강력한 모델을 필요로 하지는 않음
• 에이전트 루프 (agent loops)가 작은 비효율성을 거대한 청구서로 증폭시킴

이것이 바로 "멀티 제공자 지원 (multi-provider support)"만으로는 충분하지 않은 이유입니다. 게이트웨이 계층에서 토큰 감소가 필요합니다.

벤치마크 내용

최근 저는 **동일한 백엔드 제공자 (backend providers)**를 사용하여 Lynkr와 LiteLLM을 비교하는 벤치마크를 실행했습니다:

• Ollama 로컬
• Moonshot
• Azure OpenAI

벤치마크는 다음을 포함하여 4가지 기능 카테고리에 걸쳐 9가지 시나리오를 다루었습니다:

• 도구 중심 요청 (tool-heavy requests)
• 거대한 JSON 도구 출력값
• 의역된 캐시 히트 (paraphrased cache hits)
• 단순 vs 복잡한 라우팅 결정

전체 보고서:
https://github.com/Fast-Editor/Lynkr/blob/main/BENCHMARK_REPORT.md

1. 스마트한 도구 선택 (Smart tool selection): 토큰 53% 절감

토큰을 낭비하는 가장 쉬운 방법 중 하나는 모든 요청에 가능한 모든 도구 정의 (tool definition)를 전달하는 것입니다.

읽기 전용 질문에는 쓰기 (write), 편집 (edit), bash, 또는 git 도구가 필요하지 않습니다. 하지만 많은 설정에서 여전히 그런 일이 발생합니다.

Lynkr는 요청을 분류하고, 전달하기 전에 관련 없는 도구 스키마 (tool schemas)를 제거합니다.

벤치마크 결과 (Benchmark result)

프록시 (Proxy)	청구된 토큰 (Tokens billed)	비용 (Cost)
Lynkr	959	$0.0044
LiteLLM	2,085	$0.0091

결과: 동일한 모델과 프롬프트 기준, 토큰 53% 감소, 비용 52% 절감.

코딩 세션은 단발성 프롬프트 (one-shot prompts)가 아니기 때문에 이 차이는 매우 중요합니다. 매 턴마다 불필요한 도구 부하 (tool baggage)를 실어 나른다면, 비용은 조용히 두 배로 늘어납니다.

2. 대규모 JSON 도구 결과: 토큰 87.6% 절감

또 다른 숨겨진 비용은 도구 출력 (tool output)입니다.

bash 명령, grep, 파일 읽기, 또는 에이전트 단계 (agent step)가 대규모의 구조화된 JSON 페이로드 (JSON payload)를 반환하면, 해당 페이로드가 모델로 전달됩니다. 그리고 이는 빠르게 비용 상승을 초래합니다.

Lynkr는 대규모 JSON 도구 결과를 상위 시스템으로 보내기 전에 **TOON 압축 (TOON compression)**을 사용합니다.

벤치마크 결과 (Benchmark result)

프록시 (Proxy)	청구된 토큰 (Tokens billed)	비용 (Cost)	지연 시간 (Latency)
Lynkr	427	$0.009	12s
LiteLLM	3,458	$0.018	12s

결과: 이번 벤치마크에서 동일한 지연 시간(latency)을 유지하면서 87.6% 압축 및 50% 비용 절감.

이러한 최적화는 실제 에이전트 워크플로우 (agent workflows)에서 매우 중요합니다. 왜냐하면 그러한 시스템들은 종종 장황한 중간 출력 (intermediate outputs)을 생성하기 때문입니다.

3. 시맨틱 캐시 (Semantic cache): 캐시 히트 시 171ms 응답, 청구 토큰 0개

정확히 일치하는 방식의 캐싱 (Exact-match caching)도 유용하지만, 코딩 워크플로우는 바이트 단위로 완전히 일치하기보다는 거의 중복되는 프롬프트 (near-duplicate prompts)를 생성하는 경우가 많습니다.

예를 들어:

• “Explain TCP vs UDP”
• “What is the difference between TCP and UDP?”

Lynkr는 시맨틱 캐싱 (semantic caching)을 사용하므로, 말을 바꾼 프롬프트 (paraphrased prompts)도 캐시를 활용할 수 있습니다.

벤치마크 결과 (Benchmark result)

시나리오 (Scenario)	청구된 토큰 (Tokens billed)	응답 시간 (Response time)
첫 번째 호출 (cold)	2,857	1,891ms
두 번째 호출 (paraphrased cache hit)	0	171ms

결과: 캐시 히트 (cache hit) 시 응답 시간 171ms 및 청구 토큰 0개.

이것이야말로 팀 단위의 반복적인 사용에 따른 경제성을 변화시키는 승리입니다.

4. 계층 라우팅 (Tier routing): 모든 프롬프트가 동일한 모델을 사용할 필요는 없다

가장 저렴한 가용 모델로 라우팅하는 것이 곧 올바르게 라우팅하는 것과 같지는 않습니다.

만약 누군가 다음과 같이 질문한다면:

• “git stash는 무엇을 하나요?” → 로컬/무료 (local/free) 모델로 충분함
• “은행 인증을 위한 보안 JWT vs 쿠키 아키텍처를 설계해줘” → 이는 상위 모델로 에스컬레이션(escalate)되어야 함

Lynkr는 다음과 같은 **15가지 차원 (dimensions)**을 기준으로 요청을 점수화합니다:

• 토큰 수 (token count)
• 코드 복잡도 (code complexity)
• 추론 마커 (reasoning markers)
• 위험 패턴 (risk patterns)
• 에이전트 신호 (agentic signals)

그 후 자동으로 라우팅합니다.

벤치마크 결과

요청 (Request)	Lynkr	LiteLLM
“git stash는 무엇을 하나요?”	로컬/무료 계층 (local/free tier)	로컬/무료 계층 (local/free tier)
JWT vs 쿠키 보안 분석	클라우드 모델 (cloud model)	가장 저렴한 로컬 모델 (cheapest local model)

이 차이는 중요합니다. 저렴한 라우팅은 그것이 여전히 올바른 결정일 때만 유효합니다.

월간 비용 예측

벤치마크에는 도구 중심의 에이전트 워크로드 (tool-heavy agentic workload)를 사용하는 월간 100,000건의 요청에 대한 간단한 비용 예측이 포함되어 있습니다:

프록시 (Proxy)	월간 비용
LiteLLM	~$818
Lynkr	~$409

동일한 백엔드 사용 시 약 50% 더 저렴합니다.

이것이 핵심입니다. 게이트웨이를 동일한 조건에서 공정하게 비교한다면, 절감액은 마법에서 나오는 것이 아닙니다. 토큰이 제공업체(provider)에 도달하기 전에 낭비를 제거함으로써 발생하는 것입니다.

LiteLLM이 여전히 강력한 부분

만약 귀하의 주요 요구사항이 다음과 같다면 LiteLLM은 여전히 강력한 제품입니다:

• 제공업체 추상화 (provider abstraction)
• 예산 제어 (budget controls)
• 표준 프록시 동작 (standard proxy behavior)
• 기존의 Python 중심 인프라 (existing Python-heavy infra)

광범위한 프록시 계층을 원하며 코딩 워크플로우 특화된 토큰 최적화에 크게 신경 쓰지 않는다면, LiteLLM은 합리적인 선택입니다.

Lynkr가 차별화되는 부분

Lynkr는 특히 AI 코딩 및 에이전트 워크플로우를 중심으로 구축되었습니다.

즉, 다음과 같은 부분에 집중합니다:

• 스마트 도구 선택 (smart tool selection)
• 대규모 JSON 출력을 위한 TOON 압축 (TOON compression for large JSON outputs)
• 시맨틱 캐시 (semantic cache)
• 복잡도 기반 자동 티어 라우팅 (automatic complexity-based tier routing)
• MCP 통합 (MCP integration)
• 코드 모드 (Code Mode)
• 장기 기억 (long-term memory)
• Claude Code, Cursor, Codex를 위한 즉시 사용 가능한 호환성 (drop-in compatibility for Claude Code, Cursor, and Codex)

현재 README 내용:

• 13개 이상의 프로바이더 (providers) 지원
• 699개의 테스트 통과
• **코드 모드 (Code Mode)**는 MCP 도구 정의 오버헤드를 약 96% 감소시킵니다.
• 즉시 사용 가능한 통합을 위해 코드 변경이 전혀 필요하지 않습니다 (0 code changes required)

핵심 요약 (The real takeaway)

만약 여러분이 원하는 것이 단지 "하나의 API 뒤에 많은 프로바이더를 두는 것"뿐이라면, LiteLLM과 같은 게이트웨이가 그 역할을 수행합니다.

하지만 여러분의 실제 목표가 AI 코딩 인프라 비용을 실질적으로 낮추는 것이라면, 중요한 질문은 다음과 같습니다:

게이트웨이가 모델에 도달하기 전에 토큰을 줄여주는가?

가장 큰 비용 절감은 바로 그 지점에서 발생합니다.

AI 코딩 워크플로우에서 가장 큰 비용 결정 요인은 대개 다음과 같습니다:

• 관련 없는 도구 제거
• 도구 출력 압축
• 의미적으로 유사한 턴 (turns) 캐싱
• 단순한 요청은 저렴한 모델로 라우팅하고, 필요한 경우에만 상위 모델로 격상

이것이 바로 제가 Lynkr를 구축한 핵심 레이어입니다.

벤치마크를 확인하거나 직접 사용해보고 싶다면:

• GitHub: https://github.com/Fast-Editor/Lynkr
• 벤치마크 보고서: https://github.com/Fast-Editor/Lynkr/blob/main/BENCHMARK_REPORT.md

만약 여러분이 Claude Code, Cursor, Codex 또는 MCP 워크플로우를 기반으로 구축하고 있다면, 여러분의 가장 큰 토큰 낭비 원인이 무엇이었는지 궁금합니다.