만약 제가 본격적인 일상적 사용을 위해 T3 Code를 설정한다면, 제가 원하는 스택은 다음과 같습니다:

T3 Code
   ↓
Claude Code
...

이 흐름은 각 계층이 서로 다른 역할을 수행하기 때문에 흥미롭습니다:

• T3 Code는 워크플로(Workflow) 및 인터페이스 계층입니다.
• Claude Code는 코딩 에이전트(Coding agent)입니다.
• Lynkr는 에이전트 하단의 게이트웨이(Gateway) 계층입니다.
• **모델 제공업체(Model providers)**는 해당 게이트웨이 뒤에 위치합니다.

이러한 분리가 핵심입니다.

T3 Code는 제가 원하는 UX(사용자 경험)를 제공합니다.
Claude Code는 제가 원하는 코딩 동작을 제공합니다.
Lynkr는 모델 트래픽이 실제로 처리되는 방식에 대한 제어권을 제공합니다.

이는 모델 계층을 사후 고려 사항으로 취급하는 것보다 훨씬 더 나은 스택입니다.

빠른 데모

또한 이 설정이 실제로 작동하는 짧은 워크스루(Walkthrough) 영상을 녹화했습니다:

• YouTube:

나머지를 읽기 전에 더 빠른 시각적 버전을 원하신다면 거기서부터 시작하세요. 아키텍처는 동일합니다:

T3 Code
   ↓
Claude Code
...

T3 Code가 유용한 인터페이스인 이유

T3 Code가 흥미로운 이유는 새로운 모델이나 특정 연구소 전용 하네스(Harness)가 되려고 하지 않기 때문입니다.

이것은 사람들이 이미 사용하고 있는 코딩 에이전트와 함께 작업하는 더 나은 방법을 구축하고 있습니다.

이는 모든 것을 한꺼번에 교체하려는 시도보다 더 스마트한 제품 결정입니다.

현재 지원 범위에는 다음이 포함됩니다:

• Codex
• Claude
• Cursor
• OpenCode

즉, T3 Code의 가치는 "하나 더 추가된 코딩 어시스턴트"가 아닙니다.

그보다는 다음과 같습니다:

• 코딩 세션을 관리하는 하나의 장소
• 프로젝트와 스레드(Threads)를 관리하는 하나의 장소
• 여러 에이전트 백엔드(Backends)에 걸친 하나의 더 깔끔한 인터페이스
• 별개의 도구 간의 컨텍스트 스위칭(Context-switching) 감소

이는 매우 타당한 접근입니다.

하지만 해당 스택 내에서 코딩 에이전트로 Claude Code를 선택하고 나면, 다음 문제는 명확해집니다:

Claude Code 하단의 모델 계층은 최상위 UX만큼이나 중요합니다.

에이전트가 실제 작업을 수행하기 시작하면, 비용과 신뢰성은 더 이상 보이지 않는 배관(Plumbing) 문제가 아니기 때문입니다.

그것들은 제품 경험(Product experience)의 일부가 됩니다.

Claude Code가 적절한 예시인 이유

Claude Code는 문제를 매우 명확하게 드러내기 때문에 좋은 예시입니다.

실제 Claude Code 세션은 단 한 번의 "코드 생성 (generate code)" 호출처럼 보이지 않습니다.

그보다는 다음과 같은 모습에 가깝습니다:

1. 저장소(Repo) 조사
2. 몇 개의 파일 읽기
3. 수정 계획 수립
4. 도구 (Tools) 호출
5. 코드 생성 또는 편집
6. 문제 발생
7. 더 많은 컨텍스트 (Context)와 함께 재시도
8. 다른 파일 조사
9. 결과 요약
10. 추가 작업 수행

이는 일반적인 채팅과는 매우 다른 트래픽 패턴을 생성합니다:

• 반복되는 시스템 지침 (System instructions)
• 반복되는 저장소 컨텍스트 (Repo context)
• 반복되는 도구 스키마 (Tool schemas)
• 반복되는 상태 (State)
• 대규모 도구 출력 (Tool outputs)
• 토큰을 조용히 증폭시키는 재시도 (Retries)
• 쉬운 턴 (Easy turns)과 어려운 추론 턴 (Hard reasoning turns)의 혼합

이것이 바로 코딩 에이전트 워크플로우가 "단순히 하나의 제공업체(Provider)에 직접 연결하는 것"보다 더 강력한 모델 계층을 필요로 하는 정확한 이유입니다.

Claude Code가 실제 코딩 에이전트로 사용되기 시작하면, 그 아래의 모델 경로는 인프라 (Infrastructure)가 됩니다.

그리고 인프라 결정은 복리로 작용합니다.

Claude Code를 영구적으로 직접 연결할 때의 문제점

직접적인 설정은 테스트용으로는 괜찮습니다.

하지만 워크플로우가 더 진지해질수록 상황은 악화됩니다.

만약 Claude Code가 항상 하나의 제공업체 경로에 직접 연결되어 있다면, 몇 가지 문제에 직면하게 됩니다:

1. 모든 턴이 동일한 모델이 필요하다고 처리됨

이는 대개 사실이 아닙니다.

어떤 단계들은 가볍습니다:

• 파일 요약
• 오류의 예상 원인 추출
• 다음 행동 선택
• 로그 해석
• 답변 형식 재구성
• 짧은 구조화된 응답 생성

어떤 단계들은 진정으로 비용이 많이 듭니다:

• 여러 파일에 걸친 통합 오류 디버깅
• 대규모 코드베이스 전반에 걸친 추론
• 여러 번의 도구 루프 실패 후 복구
• 동작을 깨뜨리지 않고 깊은 부분 리팩토링 (Refactor)

이 모든 단계가 동일한 고비용 경로를 통하게 되면, 과다한 비용을 지불하게 됩니다.

2. 재시도가 비용 승수(Cost multiplier)가 됨

코딩 에이전트는 항상 재시도를 합니다.

그것은 버그가 아닙니다. 그것이 그들이 작동하는 방식입니다.

하지만 재시도(retries)는 동일하거나 거의 동일한 컨텍스트 (context)가 계속해서 반복적으로 전송됨을 의미합니다.

캐싱 레이어 (caching layer)나 라우팅 제어 (routing control)가 없다면, 반복되는 작업에 대해 계속해서 전체 비용을 지불하게 됩니다.

3. 도구 중심의 트래픽은 조용한 토큰 킬러가 됩니다

비싼 부분은 종종 사용자의 프롬프트 (prompt)가 아닙니다.

그 주변의 모든 것들이 문제입니다:

• 도구 정의 (tool definitions)
• 파일 읽기 (file reads)
• 로그 (logs)
• 스택 트레이스 (stack traces)
• JSON 블롭 (JSON blobs)
• 반복되는 상태 (repeated state)
• 구조화된 출력 (structured outputs)

그곳에 많은 토큰 낭비가 숨어 있습니다.

4. 제공자 변경이 번거로워집니다

어쩌면 오늘은 모든 것에 Claude를 사용하고 싶을 수도 있습니다.

나중에는 다음과 같은 조합을 원할 수도 있습니다:

• 저렴한 탐색적 패스 (exploratory passes)를 위한 로컬 Ollama
• 어려운 추론 (hard reasoning)을 위한 Anthropic
• 오버플로 (overflow)를 위한 OpenRouter
• 엔터프라이즈 제약 사항을 위한 Bedrock 또는 Azure
• 팀마다 다른 조합

만약 설정이 너무 긴밀하게 연결되어 있다면, 이러한 변경 사항들은 마땅히 겪어야 할 수준보다 더 고통스럽게 다가올 것입니다.

5. 신뢰성 문제가 워크플로 (workflow)로 유출됩니다

지연 시간 급증 (latency spikes), 속도 제한 (rate limits), 인증 이상 (auth weirdness), 제공자 중단 (provider outages), 저하된 출력 (degraded outputs) — 결국 이 모든 것을 겪게 됩니다.

게이트웨이 레이어 (gateway layer)가 없다면, 이러한 문제 하나하나가 클라이언트 측 문제 (client-side problem)가 됩니다.

그것이 바로 제가 모델 레이어 (model layer)에서 한 번에 해결하고 싶은 바로 그 종류의 문제입니다.

내가 원하는 분리

이것은 저에게 합리적으로 다가오는 멘탈 모델 (mental model)입니다.

T3 Code가 처리하는 것

• 스레드 (threads)
• 프로젝트 (projects)
• 최상위 UX (top-level UX)
• 세션 관리 (session management)
• 코딩 워크플로 인터페이스 (coding workflow surface)

Claude Code가 처리하는 것

• 코드 추론 (code reasoning)
• 편집 (edits)
• 도구 사용 (tool usage)
• 코딩 루프 (coding loop) 자체

Lynkr가 처리하는 것

• 라우팅 (routing)
• 캐싱 (caching)
• 폴백 (fallback)
• 토큰 최적화 (token optimization)
• 로컬/클라우드 백엔드 혼합 (local/cloud backend mix)
• 제공자 전환 (provider switching)
• 하나의 안정적인 엔드포인트 (endpoint) 아래에서의 비용 제어 (cost control)

이것이 깔끔한 스택 (stack)입니다.

인터페이스는 에이전트 (agent)와 분리되어 유지됩니다.
에이전트는 게이트웨이 (gateway)와 분리되어 유지됩니다.
게이트웨이는 제공자 (providers)와 분리되어 유지됩니다.

이러한 분리는 각 레이어가 독립적으로 진화할 수 있게 해주기 때문에 가치가 있습니다.

왜 Lynkr가 Claude Code 아래에 적합한가

Lynkr는 코딩 어시스턴트(coding assistants), MCP 중심의 워크플로우(MCP-heavy workflows), 그리고 도구 중심의 트래픽(tool-heavy traffic)을 위해 구축된 오픈 소스 **LLM 게이트웨이 (LLM gateway)**입니다.

마지막 부분이 중요합니다.

많은 모델 라우팅 (model-routing) 제품들이 범용적인 요청에 대해 이야기합니다. 하지만 코딩 트래픽은 다릅니다. 코딩 트래픽은 더 노이즈가 많고, 더 반복적이며, 대규모 도구 페이로드 (tool payloads)를 포함할 가능성이 훨씬 높습니다.

이것이 바로 여기서 Lynkr가 적합한 진짜 이유입니다.

이 스택에서 Lynkr의 역할은 Claude Code를 대체하는 것이 아닙니다.

Lynkr는 Claude Code 아래에 위치하여 모델 트래픽이 실제로 어떻게 처리되어야 하는지를 결정하는 역할을 합니다.

이를 통해 코딩 워크플로우에서 매우 중요한 몇 가지 레버 (levers)를 확보할 수 있습니다.

1. 티어 라우팅 (Tier routing)은 경제성을 변화시킵니다

사람들이 코딩 에이전트 (coding agents)를 사용할 때 저지르는 가장 큰 실수는 잘못된 질문을 던지는 것입니다.

그들은 이렇게 묻습니다:

“어떤 코딩 모델이 가장 좋은가?”

더 유용한 질문은 다음과 같습니다:

“내 코딩 워크플로우의 어떤 부분들이 실제로 비싼 모델을 사용할 가치가 있는가?”

이것이 바로 게이트웨이가 여러분이 답할 수 있게 해주는 부분입니다.

예를 들어:

• 저위험 요약 (low-risk summarization) 작업은 더 저렴하고 빠른 모델로 보낼 수 있습니다.
• 반복적인 검사 단계는 로컬 (local)에서 유지할 수 있습니다.
• 단순한 분류 (classification) 또는 추출 (extraction) 단계는 최첨단 (frontier) 모델의 가격을 지불할 필요가 없습니다.
• 어려운 디버깅 (debugging)이나 리팩터링 (refactors)은 더 강력한 경로로 에스컬레이션 (escalate)할 수 있습니다.

이는 모든 Claude Code 턴 (turn)을 최대 비용을 들여야 하는 것처럼 취급하는 것보다 훨씬 더 나은 경제적 모델입니다.

그리고 일단 그 로직이 게이트웨이에 자리 잡으면, 애플리케이션 레이어 (app layer)에서 이를 계속 다시 구축할 필요가 없습니다.

2. 캐싱 (Caching)은 사람들이 생각하는 것보다 코딩에서 더 중요합니다

코딩 에이전트들은 끊임없이 반복합니다.

동일한 지침, 동일한 리포지토리 (repo) 배경 지식, 유사한 프롬프트 (prompts), 유사한 복구 단계, 유사한 도구 출력값 — 이들은 계속해서 다시 나타납니다.

즉, 캐싱 레이어 (caching layer)는 단순히 "하면 좋은 최적화"가 아닙니다.

이는 스택 내에서 가장 명백하고 큰 이득 중 하나입니다.

Lynkr의 현재 벤치마크 (benchmark) 주장 중 눈에 띄는 부분은 다음과 같습니다:

• 도구 중심 요청에서 토큰 53% 감소
• 대규모 JSON 도구 결과에 대해 87.6% 압축
• 171ms 시맨틱 캐시 히트 (semantic cache hits)

그것이 바로 Claude Code가 실제 다단계 작업(multi-step work)을 수행하는 동안 생성하는 트래픽의 정확한 형태입니다.

핵심은 단순히 비용이 낮아지는 것만이 아닙니다.

핵심은 반복되는 작업에서 비용이 낮아지면서 동시에 지연 시간(latency)도 낮아진다는 점입니다.

이것은 매우 빠르게 복리 효과를 일으킵니다.

3. 도구 페이로드 최적화(Tool payload optimization)는 실질적인 레버입니다

이것은 코딩 에이전트 경제학(coding-agent economics)에서 가장 논의가 부족한 부분 중 하나입니다.

사람들은 모델 가격을 비교하는 데 많은 시간을 소비하지만, 엄청난 양의 낭비는 페이로드(payload) 형태 자체에서 발생합니다.

코딩 워크플로(workflows)에서 모델은 종종 다음과 같은 것들을 보게 됩니다:

• 대규모 도구 스키마 (large tool schemas)
• 장황한 JSON 결과 (verbose JSON results)
• 긴 명령 출력 (long command outputs)
• 반복되는 파일 발췌본 (repeated file excerpts)
• 반복되는 구조화된 상태 (repeated structured state)

즉, 페이로드 크기를 줄이는 것은 적절한 제공업체(provider)를 선택하는 것만큼이나 중요한 경우가 많습니다.

이것이 게이트웨이 수준의 최적화가 타당한 이유입니다.

이는 단순히 제공업체를 이리저리 바꾸는 것이 아니라, 실제 트래픽 패턴에서 발생하는 실질적인 문제를 해결하는 것입니다.

4. 모델 계층이 진화하는 동안 T3 Code는 안정적으로 유지됩니다

이것이 아마도 제가 이 스택을 좋아하는 가장 큰 아키텍처적 이유일 것입니다.

만약 T3 Code가 Claude Code를 가리키고, Claude Code가 Lynkr를 가리킨다면, 하단의 백엔드 정책이 변경되는 동안에도 최상위 워크플로는 안정적으로 유지될 수 있습니다.

즉, 매번 인터페이스와 워크플로를 다시 생각할 필요 없이 다음과 같은 것들을 변경할 수 있음을 의미합니다:

• 기본 제공업체 (default providers)
• 로컬/클라우드 혼합 (local/cloud mix)
• 폴백 정책 (fallback policy)
• 캐시 동작 (cache behavior)
• 비용 정책 (cost policy)
• 모델 티어 (model tiers)

…이것이 더 나은 장기적 설계입니다.

UI 계층은 모델 정책이 머무는 곳이 되어서는 안 됩니다.

5. 로컬 우선(Local-first) 및 폴백(fallback)이 훨씬 쉬워집니다

코딩 워크플로에는 로컬에서 처리하거나 더 저렴한 모델 경로로 처리할 수 있는 단계가 매우 많습니다.

또한 더 강력한 클라우드 모델을 원하는 단계도 매우 많습니다.

게이트웨이는 이러한 하이브리드 모델을 훨씬 더 쉽게 만들어 줍니다.

예를 들어:

• 가벼운 리포지토리 검사(repo inspection)를 위한 로컬 모델
• 어려운 디버깅(debugging)을 위한 더 강력한 제공업체
• 로컬 출력이 충분하지 않을 때의 클라우드 폴백(cloud fallback)
• 메인 경로가 느리거나 사용할 수 없을 때의 대체 제공업체

모든 클라이언트가 직접 연결되어 있다면, 그러한 설정을 깔끔하게 유지하기가 훨씬 더 어렵습니다.

실제 아키텍처 적용 사례

핵심은 T3 Code 자체가 게이트웨이(gateway)가 되는 것이 아닙니다.

핵심은 스택(stack)이 계층화된 상태를 유지한다는 것입니다:

T3 Code
   ↓
Claude Code
...

이를 통해 다음과 같은 이점을 얻을 수 있습니다:

• 상단의 깔끔한 인터페이스
• 중간의 강력한 코딩 에이전트 (coding agent)
• 하단의 안정적인 하나의 게이트웨이 계층
• 그 뒤에 교체 가능한 제공업체들 (swappable providers)

이것이 시간이 흐를수록 제가 더 신뢰할 수 있는 구조입니다.

T3 Code를 진지하게 사용하는 사람들에게 이것이 중요한 이유

T3 Code를 가볍게 사용해 보는 단계라면, 이 모든 것이 그리 중요하지 않을 수 있습니다.

하지만 실제로 반복적인 코딩 워크플로 (coding workflows)에 사용하고 있다면, 상황은 빠르게 달라집니다.

매일 코딩 에이전트를 사용한다는 것은 다음과 같은 의미이기 때문입니다:

• 수많은 반복 호출
• 도구 중심의 많은 턴 (tool-heavy turns)
• 예상보다 많은 재시도 (retries)
• 예상보다 많은 컨텍스트 반복 (context repetition)
• 예상보다 더 높은 백엔드 유연성 (backend flexibility)의 필요성

이 시점이 되면 게이트웨이는 선택적인 아키텍처 이론이 아니라, 비용과 신뢰성을 제어하는 실질적인 계층이 됩니다.

최종 결론

만약 제가 Claude Code와 함께 T3 Code를 사용한다면, Claude Code가 영원히 하나의 백엔드에만 직접 연결되어 있는 것을 원하지 않을 것입니다.

저는 다음과 같은 구성을 원할 것입니다:

• 워크플로 (workflow)를 위한 T3 Code
• 코딩 동작 (coding behavior)을 위한 Claude Code
• 라우팅 (routing), 캐싱 (caching), 폴백 (fallback), 그리고 비용 제어를 위한 Lynkr
• 해당 게이트웨이 뒤에 있는 다수의 제공업체 (multiple providers)

이것이 코딩 도구가 나아가고 있는 방향에 적합한 스택이라고 느껴집니다.

상단에는 더 나은 UX.

중간에는 더 나은 에이전트 동작.

하단에는 더 나은 경제성과 제어력.

프로젝트를 확인하고 싶다면:

• T3 Code: https://github.com/pingdotgg/t3code
• Lynkr: https://github.com/Fast-Editor/Lynkr