에이전트의 다음 경쟁력은 성능이 아니라 라우팅과 스펙이다

나는 요즘 에이전트 제품을 볼 때 모델 이름보다 먼저 라우팅 규칙을 본다. 어떤 요청이 로컬로 가고, 어떤 요청이 호스티드 모델로 넘어가고, 어떤 요청이 사람 승인을 기다려야 하는지 정해져 있지 않으면, 아무리 모델이 좋아도 제품은 금방 불안해진다. 오늘의 신호는 그 점을 아주 선명하게 보여준다. Wayfinder Router는 라우팅을 숨은 구현이 아니라 명시적인 제어면으로 끌어올리고, DESIGN.md는 스펙을 사람과 기계가 함께 읽는 지속 문서로 만들며, agentgateway는 identity·tracing·replay를 포함한 연결 계층을 전면에 둔다.

내가 보기엔 이건 단순한 도구 유행이 아니다. 에이전트 제품의 경쟁축이 바뀌고 있다는 신호다. 예전에는 “어떤 모델을 붙였나”가 중요했다. 지금은 “어떤 정책으로 보내고, 어떻게 실패를 기록하고, 나중에 같은 결정을 재현할 수 있나”가 더 중요하다. 제품이 커질수록 이 차이는 더 커진다.

이미 라우팅 일반론은 여러 글에서 다뤘다. 그래서 이 글은 주장을 다시 반복하기보다, Wayfinder Router·DESIGN.md·agentgateway라는 세 신호를 하나의 운영 체크리스트로 묶어 읽는 데 초점을 둔다.

라우팅은 백엔드 디테일이 아니라 제품 기능이다

Wayfinder Router의 핵심 메시지는 단순하다. 요청을 로컬 모델과 호스티드 모델 사이에서 deterministic하게 라우팅할 수 있어야 한다는 것. 중요한 건 ‘라우팅을 한다’가 아니라 ‘운영자가 읽을 수 있는 규칙으로 라우팅한다’는 점이다. Wayfinder Router GitHub는 이걸 아주 노골적으로 보여준다.

이 관점이 왜 중요할까. 에이전트 사용자 입장에서는 모델이 몇 개 붙어 있든 별로 중요하지 않다. 사용자가 체감하는 건 다음이다.

• 이 요청이 왜 이 경로로 갔는가
• 실패하면 다음 후보는 무엇인가
• 비용을 아끼기 위해 어떤 요청은 작은 모델로 먼저 흘렸는가
• 위험한 작업은 왜 자동 실행이 아니라 승인 대기 상태로 갔는가

이 질문에 답하지 못하면 라우팅은 최적화가 아니라 도박이 된다.

실무에서는 이런 질문이 더 날카롭다.

• 민감한 문서는 로컬에서만 처리해야 하는가
• 짧고 반복적인 작업은 저비용 경로로 보낼 수 있는가
• 긴 추론이 필요한 요청만 상위 모델로 승격하는가
• 실패 시 같은 모델을 다시 두드릴지, 다른 정책으로 바꿀지 정해져 있는가

정리하면 라우팅은 내부 구조가 아니라 신뢰의 얼굴이다. 사용자는 모델 이름이 아니라, 시스템이 어떻게 판단하는지에서 안심한다.

스펙이 없으면 라우팅은 금방 누수된다

라우팅 정책은 프롬프트 안에 흩뿌려두면 오래 못 간다. 그래서 DESIGN.md 같은 spec-first 흐름이 흥미롭다. DESIGN.md GitHub는 디자인 시스템을 위한 지속 문서 포맷을 제안하는데, 핵심은 머신이 읽을 수 있는 토큰과 사람이 읽을 수 있는 설명을 같이 둔다는 점이다. 에이전트 운영도 똑같다. 정책이 코드 주석처럼 흩어져 있으면 다음 주부터 이미 잊힌다.

스펙은 적어도 아래를 포함해야 한다.

routing_policy:
  classify:
    - sensitivity
    - cost
    - latency
    - accuracy
  lanes:
    local:
      use_for: ["private", "cheap", "repeatable"]
    hosted:
      use_for: ["complex", "high_accuracy", "long_reasoning"]
    human:
      use_for: ["destructive", "ambiguous", "policy_sensitive"]
  fallback_order:
    - local
    - hosted
    - human
  retry_cap: 2
  evidence_log: true
  approval_required_for:
    - writes_to_prod
    - billing_change
    - external_side_effect

이런 문서가 있으면 좋은 점은 단순하다. 운영자가 바꿀 수 있다는 것이다. 모델이 바뀌어도, 팀원이 바뀌어도, 같은 규칙을 다시 실행할 수 있다. 에이전트가 조직 안에서 살아남으려면, 명시된 정책이 있어야 한다.

나는 여기서 design.md의 메시지가 꽤 중요하다고 본다. 스펙은 보기 좋은 문서가 아니라, 다음 사람에게 같은 결정을 반복시키는 장치다. 에이전트 제품에서 이 기능이 없으면 policy drift가 금방 생긴다. 오늘은 비용 때문에 로컬로 보내던 요청이, 내일은 누군가의 임시 패치 때문에 항상 hosted로 흘러간다. 그 순간부터 예측 가능성이 무너진다.

local-first와 hosted inference는 대립이 아니다

가장 자주 생기는 오해는 local-first와 hosted inference를 둘 중 하나의 선택지로 보는 것이다. 실제 운영에서는 둘을 함께 써야 한다. 문제는 “어느 쪽이 더 좋냐”가 아니라 “언제 무엇을 쓰느냐”다.

agentgateway 쪽 흐름도 같은 방향을 가리킨다. agentgateway.dev는 Agent-to-Agent 프로토콜을 네이티브로 다루며, identity, tracing, replay를 가진 연결 계층을 강조한다. 이건 단순한 배선이 아니다. 연결이 곧 정책이고, 정책이 곧 감사 가능성이기 때문이다.

실제로는 이런 식의 분리가 더 낫다.

1. 요청을 민감도와 비용으로 먼저 분류한다.
2. 짧고 반복적인 작업은 로컬 경로로 먼저 흘린다.
3. 긴 추론, 복잡한 추론, 높은 정확도가 필요한 요청만 상위 경로로 승격한다.
4. 실패하면 같은 경로를 무한 반복하지 말고 fallback으로 이동한다.
5. 모든 결정을 tracing과 replay 가능한 로그로 남긴다.

이 구조가 있으면 인프라 선택이 철학 싸움이 아니라 운영 문제로 바뀐다. local-first는 개인정보와 비용을 지키는 기본값이 되고, hosted inference는 정확도와 처리량이 필요할 때만 쓰는 상위 경로가 된다.

이건 결국 신뢰의 구조다. 사용자는 “좋아 보이는 데모”보다 “나중에 되짚을 수 있는 시스템”을 더 오래 쓴다. agentgateway 같은 방향이 의미 있는 이유도 여기에 있다. 연결을 단순 통로로 두지 않고, 증거가 남는 경로로 바꾸기 때문이다.

한국 개발자에게 중요한 실질적 의미

이 흐름은 한국 개발자에게 특히 실용적이다. 왜냐하면 우리 환경에서는 비용 압박, 개인정보 민감도, 작은 팀 규모, 빠른 출시 요구가 동시에 온다. 이런 조건에서는 무조건 가장 큰 모델을 쓰는 전략이 오래 못 간다. 대신 작고 명시적인 정책이 오래 간다.

바로 점검할 수 있는 질문은 이렇다.

• 요청 분류 규칙이 문서로 남아 있는가
• 로컬과 호스티드 경로를 나누는 기준이 있는가
• 실패 시 fallback 순서가 고정되어 있는가
• 승인이 필요한 side effect가 명시되어 있는가
• replay 가능한 로그가 있는가
• 다음 운영자가 같은 결정을 재현할 수 있는가

이 질문에 답할 수 있으면, 에이전트는 실험에서 실무로 넘어간다. 답이 없으면 모델이 아무리 좋아도 데모에 머문다.

내가 보는 결론

나는 이제 에이전트 제품을 모델 경쟁으로 보지 않는다. 라우팅, 스펙, fallback, replay가 제품의 실제 경계다. 이 네 가지가 정리되어야 모델은 도구가 되고, 도구는 운영 가능한 시스템이 된다.

Wayfinder Router가 보여준 건 결정 규칙의 전면화이고, DESIGN.md가 보여준 건 스펙의 지속성이다. agentgateway가 보여준 건 연결 계층도 결국 신뢰 장치라는 사실이다. 셋을 같이 보면 메시지는 단순하다. 앞으로 좋은 에이전트 제품은 더 큰 모델보다 더 읽히는 정책을 갖게 될 가능성이 높다.

참고 자료

• Wayfinder Router GitHub
• DESIGN.md GitHub
• agentgateway.dev