AI 코딩 도구들은 매우 뛰어나졌습니다.

하지만 그 뒤에 있는 인프라는 여전히 이상할 정도로 비효율적입니다.

대부분의 도구는 하나의 제공업체, 하나의 경로, 하나의 결제 경로를 가정합니다.

이는 동일한 값비싼 모델이나 구독이 다음과 같은 모든 작업을 처리하게 된다는 것을 의미합니다:

• 파일 읽기
• 로그 요약
• 빠른 리포지토리(repo) 질문
• 다중 파일 리팩토링 (multi-file refactors)
• 아키텍처 설계
• 긴 디버깅 세션

이것은 잘못된 추상화입니다.

코딩 워크플로우는 한 가지 유형의 문제가 아닙니다. 따라서 한 가지 유형의 모델 경로를 통해서만 강제되어서는 안 됩니다.

이러한 아이디어가 저를 Lynkr를 만들게 했습니다.

Lynkr는 AI 코딩 도구를 위한 오픈 소스 LLM 게이트웨이로, 다음과 같은 것들을 하나의 라우팅 레이어(routing layer) 뒤에서 결합할 수 있게 해줍니다:

• Claude Pro/Max 구독 액세스
• Azure AI Foundry에서 호스팅되는 모델
• Amazon Bedrock에서 호스팅되는 모델
• 그리고 Ollama와 같은 로컬/무료 모델

단일 경로 AI 코딩의 문제점

만약 당신이 매일 프리미엄 코딩 어시스턴트를 사용한다면, 아마 이미 이 현상을 보았을 것입니다.

업무량의 상당 부분은 실제로 프리미엄 추론(reasoning) 작업이 아닙니다.

예를 들어:

• "이 파일 열어줘"
• "auth 미들웨어 찾아줘"
• "이 모듈 요약해줘"
• "이 클래스가 어디서 사용되는지 보여줘"
• "이 테스트 실패 내역 읽어줘"

이것들은 유용한 요청이지만, 다음과 같은 작업과는 다릅니다:

• "이 서브시스템을 리팩토링해줘"
• "더 안전한 auth 흐름을 설계해줘"
• "이 다단계 실패를 디버깅해줘"
• "이 에이전트 루프 버그를 추적해줘"
• "다섯 개의 파일에 걸쳐 이 구현을 다시 작성해줘"

하지만 대부분의 도구는 이 두 종류의 작업을 모두 동일한 값비싼 경로로 보냅니다.

이는 세 가지 문제를 야기합니다:

1) 프리미엄 용량을 낭비하게 됩니다

구독 기반 또는 프리미엄 모델이 모든 사소한 프롬프트를 처리하게 되면, 가치가 낮은 작업에 좋은 용량을 소모하게 됩니다.

2) 하나의 제공업체에 종속됩니다

이미 Azure, AWS 또는 로컬 모델에 대한 액세스 권한이 있더라도, 당신의 코딩 워크플로우는 종종 하나의 벤더 경로에 묶여 있게 됩니다.

3) 회복 탄력성(resilience)을 잃게 됩니다

한 제공업체에 속도 제한(rate-limited)이 걸리거나, 성능이 저하되거나, 혹은 단순히 특정 작업에 가장 적합하지 않은 경우에도, 이를 조정할 라우팅 계층(routing layer)이 없게 됩니다.

Lynkr의 핵심 아이디어

Lynkr는 AI 코딩 도구와 모델 제공업체(model providers) 사이에 위치합니다.

이는 **LLM 게이트웨이 (LLM gateway)**로 작동함을 의미하며, 즉 코딩 도구가 Lynkr와 통신하면 Lynkr가 다음 동작을 결정합니다.

이를 통해 게이트웨이는 다음과 같은 역할을 수행할 수 있습니다:

• 복잡도에 따른 라우팅 (route by complexity)
• 방대한 도구 출력값 압축 (compress bulky tool outputs)
• 반복되는 요청 캐싱 (cache repeated requests)
• 클라이언트 워크플로우를 변경하지 않고 제공업체 전환 (switch providers without changing the client workflow)
• 작업 유형별로 서로 다른 백엔드 사용 (use different backends for different classes of tasks)

제가 가장 기대하는 부분은 다음과 같은 서비스들을 가로지르는 하이브리드 라우팅(hybrid routing)입니다:

• Claude Pro/Max
• Azure AI Foundry
• Amazon Bedrock

"Claude Pro/Max 확장"의 의미

가장 단순한 버전은 다음과 같습니다:

• 단순한 작업 (simple tasks) → 로컬/무료 모델 (local/free model)
• 어려운 코딩 작업 (hard coding tasks) → Claude Pro/Max 구독
• 엔터프라이즈 워크로드 (enterprise workloads) → Azure AI Foundry
• 폴백 또는 대체 라우팅 (fallback or alternate routing) → Amazon Bedrock

따라서 게이트웨이는 Claude, Azure, 또는 Bedrock을 대체하는 대신, 이들을 결합합니다.

이것이 핵심 아이디어입니다: 모든 작업에 Claude Pro/Max를 소진하는 대신, 사용 범위를 확장(extend)하십시오.

예시 워크플로우

다음과 같은 코딩 세션을 상상해 보세요:

1. "인증 미들웨어(auth middleware)를 읽고 요약해줘."

   저렴한 로컬 모델로 라우팅합니다.

2. "이 헬퍼(helper)를 호출하는 모든 경로를 검색해줘."

   여전히 저렴한/로컬 모델을 사용합니다.

3. "테넌트 격리(tenant isolation)를 지원하도록 이 인증 흐름을 리팩터링(refactor)해줘."

   Claude Pro/Max로 라우팅합니다.

4. "우리 내부 스택에 맞는 엔터프라이즈급 안전 변형을 생성해줘."

   Azure AI Foundry로 라우팅합니다.

5. "Azure를 사용할 수 없거나 속도 제한이 걸렸어."

   Bedrock으로 폴백(fallback)합니다.

이는 모든 프롬프트가 동일한 모델 경로를 거쳐야 하는 것처럼 취급하는 것보다 코딩 에이전트(coding agents)를 실행하는 훨씬 더 자연스러운 방식입니다.

Claude Pro/Max + Azure + Bedrock 조합이 흥미로운 이유

이 조합이 중요한 이유는 각 경로가 서로 다른 문제를 해결하기 때문입니다.

Claude Pro/Max

이미 구독 가치를 보유하고 있는 고품질 코딩 및 추론 (reasoning) 작업에 매우 적합합니다.

Azure AI Foundry

팀이 엔터프라이즈급 호스팅 모델 (enterprise-hosted models), 내부 승인 절차, 또는 Azure 기반 인프라를 원하는 경우 유용합니다.

Amazon Bedrock

AWS 네이티브 조직, 대체 모델 접근성, 또는 다른 엔터프라이즈 제공업체 경로를 원하는 폴백 (fallback) 용도로 유용합니다.

로컬 모델 (Local models)

프리미엄 용량을 전혀 소모해서는 안 되는 저렴하고 빈번하며 중요도가 낮은 작업에 유용합니다.

이들을 하나의 게이트웨이 (gateway)로 통합하면, 개별적으로 사용할 때보다 더 나은 운영 모델을 가질 수 있습니다.

이것이 코딩 에이전트 (coding agents)에게 특히 중요한 이유

코딩 워크플로 (workflows)는 다음과 같은 특성을 갖기 때문에, 코딩이 LLM 게이트웨이의 가장 좋은 유스케이스 (use cases) 중 하나라고 생각합니다.

• 도구 의존도가 높음 (tool-heavy)
• 반복적임
• 다단계 (multi-step) 프로세스
• 구조화된 출력 (structured outputs)이 많음
• 토큰 낭비에 민감함
• 종종 많은 턴 (turns)에 걸쳐 분산됨

이는 게이트웨이가 여러 방식으로 가치를 더할 수 있음을 의미합니다.

1) 복잡도 기반 라우팅 (Complexity-based routing)

모든 프롬프트 (prompt)가 동일한 모델을 사용할 필요는 없습니다.

2) 비용 제어 (Cost control)

저렴한 요청은 저렴하게 유지됩니다.

3) 구독의 더 나은 활용

프리미엄 용량은 실제로 그것이 필요한 작업들을 위해 예약됩니다.

4) 엔터프라이즈 호환성 (Enterprise compatibility)

팀은 정책이나 조달 (procurement)이 중요한 경우 Azure AI Foundry 또는 Bedrock을 사용할 수 있습니다.

5) 회복 탄력성 (Resilience)

하나의 제공업체 경로가 실패하더라도 워크플로를 계속 진행할 수 있습니다.

MCP와 에이전트 워크플로가 위치하는 지점

이것이 중요한 또 다른 이유는 MCP와 에이전트 도구 (agentic tooling) 때문입니다.

코딩 도구들이 점점 더 에이전트화 (agentic)됨에 따라, 다음과 같은 것들을 더 많이 사용하게 됩니다.

• 도구 스키마 (tool schemas)
• 파일 읽기 (file reads)
• 명령 출력 (command outputs)
• 구조화된 결과 (structured results)
• 긴 멀티 턴 세션 (long multi-turn sessions)

이는 많은 오버헤드 (overhead)와 많은 반복적 컨텍스트 (context)를 생성합니다.

게이트웨이는 이를 최적화하기에 적합한 장소입니다.

그것이 바로 미래가 단순히 더 나은 모델에만 있지 않다고 생각하는 이유이기도 합니다.

미래는 이러한 모델들을 중심으로 더 나은 **라우팅 (routing), 캐싱 (caching), 도구 처리 (tool handling), 그리고 워크로드 분리 (workload separation)**에 있습니다.

내가 Lynkr에게 원했던 것

나는 단순히 또 다른 OpenAI 호환 엔드포인트 (endpoint)를 원했던 것이 아닙니다.

실질적인 코딩 경제성 (coding economics)과 워크플로우 설계 (workflow design)에 실제로 도움이 될 수 있는 게이트웨이를 원했습니다.

저에게 그것은 다음을 의미합니다:

• 코딩 도구의 워크플로우를 동일하게 유지
• 구독 가치 보존
• 구독 + 클라우드 + 로컬 경로 (lanes)의 결합
• 엔터프라이즈 백엔드 (enterprise backends) 지원
• 쉬운 작업에서의 낭비 감소

대상 사용자

이것은 특히 다음과 같은 분들에게 유용할 것이라고 생각합니다:

• Pro/Max 모델을 더 효율적으로 활용하고 싶은 Claude Code 사용자
• 승인된 엔터프라이즈 모델 액세스를 위해 Azure AI Foundry를 사용하는 팀
• 이미 Bedrock으로 표준화하고 있는 AWS 팀
• 로컬 모델과 프리미엄 코딩 어시스턴트를 혼합하여 사용하는 개발자
• LLM 게이트웨이가 필요한 MCP 및 에이전트 워크플로우 빌더

마치며

AI 코딩의 다음 큰 발전이 오직 더 강력한 베이스 모델 (base models)에서만 온다고 생각하지 않습니다.

많은 가치는 모델 주변의 더 나은 인프라에서 나올 것입니다:

• 더 나은 라우팅 (routing)
• 더 나은 캐싱 (caching)
• 더 나은 비용 제어 (cost control)
• 더 나은 도구 처리 (tool handling)
• 하나의 워크플로우 내에서 여러 모델 경로 (model lanes)를 더 잘 활용하는 것

그것이 바로 제가 Lynkr를 통해 구축해 나가고 있는 방향입니다.

GitHub: https://github.com/Fast-Editor/Lynkr
추신: Lynkr는 기존의 Claude Code를 래핑 (wrap)하는 방식이므로 Anthropic의 서비스 약관 (TOS)을 완전히 준수합니다.