대형언어모델(LLM)을 실제 서비스에 붙여본 팀이라면 한 번쯤 마주치는 고민이 있다. 프런티어 모델은 품질이 좋지만 호출 단가가 비싸고, 값싼 모델로 내리면 특정 작업에서 품질이 무너진다. 요청마다 어떤 모델을 쓸지 사람이 일일이 판단하기도 어렵다. Y Combinator S26 배치에 선발된 스타트업 토큰리스(Tokenless)는 이 지점을 정면으로 겨냥한다. 회사는 자사 제품을 'OpenAI·Anthropic API의 드롭인 대체제이자 모델 라우터'로 소개하며, 같은 품질을 절반 이하의 비용으로 제공한다고 주장한다.
요청을 흘려보내지 않고 '지켜본 뒤' 고른다
일반적인 모델 라우터는 요청이 들어오면 난이도나 유형을 사전에 분류해 적절한 모델로 보낸다. 토큰리스가 설명하는 방식은 조금 다르다. 하나의 요청을 여러 모델에 동시에 흘려보낸(fan out) 뒤 각 모델이 '생각하는 과정'을 지켜보고, 한 모델이 확실히 정답 경로에 올라섰다고 판단되는 순간 그 모델을 채택하고 나머지 모델의 실행을 취소한다는 것이다. 사용자는 최종적으로 필요한 만큼만 비용을 낸다는 설명이다. 사전 분류의 오판 위험을 줄이는 대신, 초반 일부 구간에서는 여러 모델을 병렬로 돌려 실제 응답의 방향성을 근거로 선택한다는 점이 핵심 아이디어다.
회사의 전제는 '대부분의 호출은 프런티어 모델을 필요로 하지 않는다'는 것이다. 실무 트래픽을 들여다보면 이 진단 자체는 낯설지 않다. 요약, 분류, 형식 변환, 단순 질의응답 같은 작업은 중급 모델로도 충분한 경우가 많고, 정작 최고가 모델이 필요한 복잡한 추론·에이전트 작업은 전체의 일부에 그친다. 그럼에도 많은 팀이 품질 하락을 우려해 모든 호출을 최상위 모델로 처리하며 비용을 과다 지출한다.
도입 장벽은 낮게, 성능은 벤치마크로 제시
토큰리스는 OpenAI·Anthropic 호환 엔드포인트를 제공한다. 기존 코드에서 API 주소만 자사 쪽으로 돌리면 바로 쓸 수 있고, '두 줄만 바꾸면 된다'고 강조한다. 이미 두 회사의 SDK로 구축된 코드베이스가 산업 표준처럼 자리 잡은 상황에서, 호환 계층을 그대로 흉내 내 전환 비용을 최소화하는 것은 이런 중간 계층 제품의 정석적인 전략이다. 도입을 저울질하는 팀에게는 실제 트래픽으로 수치를 뽑아주는 데모도 제안한다.
성능 근거로는 공개된 에이전트 벤치마크에서의 과제 해결률(solve rate)과 과제당 비용을, 각 프런티어 모델의 가장 우수한 공개 실행 결과와 비교해 제시한다고 밝혔다. 다만 원문에서 확인되는 것은 '비교를 제시한다'는 사실까지이며, 구체적인 수치나 대상 벤치마크의 세부 조건은 드러나 있지 않다. 창업진은 구글 딥마인드, 프린스턴대, UC 버클리 출신 AI 연구자들로 구성됐다고 소개된다.
실무자가 따져봐야 할 지점
아이디어는 매력적이지만 실무 도입 전에 검증할 대목이 분명히 있다. 첫째는 지연 시간이다. 여러 모델을 병렬 실행하며 방향성을 관찰한 뒤 선택하는 구조는 초기 구간에서 추가 연산과 대기를 유발할 수 있어, 응답 속도에 민감한 서비스에서는 비용 절감과 지연의 균형을 실측해봐야 한다. 둘째는 '같은 품질'이라는 주장의 검증이다. 벤치마크 평균과 개별 서비스의 실제 트래픽 분포는 다르므로, 자사 데이터로 직접 A/B를 돌려 품질 저하 구간이 없는지 확인하는 편이 안전하다.
셋째는 의존성 문제다. API 호출 경로에 외부 라우팅 계층을 하나 더 끼우는 것은 그만큼 장애 지점과 데이터 흐름의 통제권을 위탁한다는 뜻이다. 민감 데이터를 다루는 조직이라면 요청이 어떤 모델들로 분산되는지, 로깅과 처리 정책이 어떻게 되는지를 계약 단계에서 명확히 할 필요가 있다. 결국 토큰리스가 겨냥한 '과다 지출' 문제는 실재하지만, 그 해법이 자기 워크로드에서도 성립하는지는 마케팅 문구가 아니라 직접 뽑은 숫자로 판단할 사안이다.