9월 27일 일요일
오늘의 공통 설계 질문은 거대한 생성 모델을 어디에 둘지가 아니라, 느리고 비싼 추론을 어떤 경계에서 타입·라우팅·공유 표현으로 바꾸고 그 결과를 어떻게 검증할지다.
에이전트의 병목은 모델 밖 판단 경로에서 생긴다
생성은 LLM에 남기되 반복 판단은 타입이 있는 저지연 계층으로 빼고, 여러 모델을 오가는 제어면에는 유통·정책·보안 책임까지 함께 설계해야 한다.
생성 모델의 능력을 유지하면서 에이전트 루프의 지연·비용·위험을 줄이려면 판단 책임을 어떻게 분리해야 하는가?
에이전트 하네스는 LLM이 요청을 해석하고 도구를 선택한 뒤 결과를 다시 읽는 반복 루프다. 도구 호출과 구조화된 출력은 이 루프를 코드와 연결하지만, 담당 팀 선택·긴급도 점수·위험 호출 판정처럼 답 공간이 좁은 판단까지 매번 생성 모델에 맡기면 지연과 비용이 누적된다. Jev가 제시하는 System 1 계층은 상태와 질문을 받아 타입이 있는 답과 확률을 반환한다. 원문은 분류 작업에서 LLM 대비 20~200배 빠르고 40~400배 저렴할 수 있다고 소개하고, PII 데모에서는 약 5초 걸린 LLM 대신 거의 즉시 98% 확률을 반환했다고 보고한다. 이 수치는 범용 우월성의 증거가 아니라 정형 판단을 분리할 때 기대할 수 있는 사례별 근거다. 반면 OpenRouter의 사례는 판단 분리가 한 프로세스 안에서 끝나지 않음을 보여준다. 모델마다 가격·속도·능력·거절 정책이 다르면 어떤 모델과 공급자를 쓸지 정하는 라우팅, 키와 엔드포인트, 버전, 장애, 권한, 사용량을 다루는 제어면이 별도 시스템이 된다. 따라서 설계의 단위는 ‘더 좋은 모델 하나’가 아니라 생성, 정형 판단, 공급자 선택, 실행 차단을 잇는 정책 경로다.
- 01
핫패스에서 분리할 판단
먼저 각 결정을 개방형 생성과 정형 판정으로 나눈다. 복잡한 계획과 답변 합성은 LLM에 남기고, choice·score·dual처럼 출력 타입과 정책 연결이 분명한 질문은 빠른 판단 계층으로 이동한다. 같은 상태에 담당 팀, 감정, 긴급성을 병렬로 묻는 예시는 직렬 LLM 호출을 줄이는 방식도 보여준다. 다만 발표의 속도·비용 배수는 분류형 작업 범위의 주장이다. 실제 하네스에서는 업무별 정확도, 확률 보정, 오탐 비용을 따로 측정해야 한다.
- 02
라우팅은 모델 선택 이상의 제어면
Jev 사례의 모델 라우팅은 요청 복잡도에 따라 빠른 모델과 강한 모델을 고르는 로컬 정책이다. OpenRouter가 설명하는 라우팅은 여기에 공급자 다양성, 가격과 속도, 거절 양상, 키·버전·장애 처리를 더한다. Mixtral 사례에서는 사용자가 빠른 모델을 먼저 쓰고 부족하면 비싼 모델로 올리는 수동 행동이 자동 라우터의 선행 패턴이 됐다. 즉 라우터 평가는 단일 품질 점수가 아니라 비용, 지연, 실패와 정책 적합성을 포함해야 한다.
- 03
안전성은 실행 전 게이트여야 한다
Auto Mode 사례는 데이터베이스나 중요 파일 삭제 같은 도구 호출을 실행 전에 분류해 차단한다. 보호 단계가 느리면 기능 자체를 끄게 되므로 안전 정확도와 판단 지연을 동시에 운영 지표로 삼아야 한다. 범위가 인터넷의 모델 공급망으로 넓어지면 도난 카드, 계정 침해, 추론 재판매, 통제되지 않은 에이전트의 비용 폭주가 추가된다. 로컬 게이트와 플랫폼 신뢰·안전 계층은 서로 다른 공격 표면을 담당하지만, 둘 다 가치가 이동하기 전에 판정해야 한다는 원칙을 공유한다.
- 04
검증 경계와 실패 처리
온라인 평가는 정확성·참조 일치·근거성·인용 같은 루브릭을 저비용 판정기로 계속 측정하고, 낮은 신뢰도나 높은 위험 사례를 사람에게 올리는 구조를 제안한다. 그러나 제어면이 프롬프트와 완성 결과를 기본적으로 보지 않는다면 플랫폼 전체 품질을 동일한 방식으로 평가할 수 없다. 애플리케이션 내부 trace 평가, 실행 게이트 로그, 공급자 장애와 비용, 계정 남용 신호를 분리해 관측하고 서로 다른 보존·접근 정책을 둬야 한다.
실행 순서는 단순하다. 먼저 반복 판단의 입력·출력 타입과 오탐 비용을 명시하고, 저지연 판정기를 그림자 모드에서 기존 LLM 경로와 비교한다. 그다음 모델 라우팅과 위험 도구 게이트를 분리 배치하고, 각 결정에 선택 이유·확률·지연·비용·후속 결과를 남긴다. 마지막으로 사람이 개입할 임계값과 공급자 장애 시 대체 경로를 정한다. 좁은 판정의 빠른 수치나 거대한 라우팅 플랫폼의 성장 지표만으로 안전한 하네스가 증명되지는 않는다. 핵심 증거는 실제 트래픽에서 정책 위반을 막으면서 품질 저하와 추가 지연을 허용 범위 안에 유지했는지다.
비싼 추론을 매 요청이 아니라 공유 자산으로 바꾸는 법
DoorDash는 LLM 판단을 라벨·시맨틱 ID·메모리로 증류하고, Spotify는 카탈로그 토큰을 언어 모델에 결합한다. 구현은 다르지만 둘 다 온라인 경로와 검증 경계를 먼저 설계한다.
대규모 검색·추천에서 LLM의 의미 추론을 프로덕션 지연과 비용 안에 넣는 두 경로는 어떻게 연결되는가?
- 1
1. 의미 감독 만들기
DoorDash는 사람의 정답, 편향될 수 있는 행동 신호, taxonomy 모델과 LLM 재평가를 합쳐 0·1·2 관련성 골든 데이터를 만든다. 경량 라벨러가 이를 전체 카탈로그로 확장하며, 비싼 추론은 온라인 응답이 아니라 검색과 순위가 공유할 감독 신호가 된다.
- 2
2. 카탈로그를 공통 언어로 바꾸기
DoorDash의 계층형 시맨틱 ID는 상품의 넓은 이웃과 세부 특성을 짧은 코드로 표현해 검색·순위·추천이 재사용하게 한다. Spotify는 콘텐츠 임베딩을 양자화한 Semantic ID를 오픈 LLM 어휘에 넣어 자연어, 청취 이력, 카탈로그 객체를 같은 생성 시퀀스에서 다룬다. 같은 이름의 표현이라도 전자는 운영 모델의 공유 특징, 후자는 생성 모델의 토큰이라는 구현 차이를 유지해야 한다.
- 3
3. 추론 위치를 선택하기
DoorDash는 LLM으로 관련성 라벨과 개인화 컬렉션 구조를 오프라인에서 만들고, 온라인에서는 기존 retrieval·ranking 스택이 재고를 채우고 순위를 정한다. Spotify의 NEO는 Semantic Foundation, Domain Binding, Capability Induction, 선택적 Post-Training을 거쳐 검색·추천·설명을 한 모델 계층에 결합한다. 하나는 추론을 적극적으로 증류하고 다른 하나는 도메인 토큰을 모델 안에 통합하므로 트래픽 지연, 갱신 주기, 제어 요구에 따라 선택해야 한다.
- 4
4. 보존과 제어를 검증하기
Spotify의 절제 연구에서 백본을 고정한 Domain Binding은 새 Semantic ID 임베딩을 배우면서 기존 언어 능력 손실을 줄였다. Grounding 단계를 제거하거나 다른 단계와 합치면 성능이 떨어졌고, 연속 사전학습은 기존 능력을 크게 훼손했다. 디코딩은 제약 없이도 Semantic ID의 98%가 유효했지만 특정 유형 강제가 필요할 때는 추가 지연을 감수하고 제약 디코딩을 사용한다.
- 5
5. 온라인 결과로 닫힌 고리 만들기
DoorDash는 2단계 관련성 학습에서 NDCG 2.3%, 시맨틱 ID를 적용한 ranker에서 MRR 4~5% 개선을 보고했지만, 화면별 value function으로 의미 적합성과 참여 목표를 계속 조정한다. Spotify는 사용자 프로필로 보강한 LLM Judge가 사람 선호와 75% 일치했고, 보강된 순위 평가의 일치 계수는 0.87이었다. 수치는 서로 다른 과업의 결과이므로 우열 비교가 아니라 각 파이프라인의 검증 경계로 읽어야 한다.
공통 원칙은 모델을 도입하는 데서 멈추지 않고, 의미 판단을 재사용 가능한 표현으로 만들고 온라인 시스템의 책임을 분명히 하는 것이다. 구축 전에는 표현의 갱신 주기와 원본 신호, 오프라인·온라인 경계, 재고나 카탈로그 변화의 반영 지점, 사람 기준과 행동 기준의 충돌 처리부터 고정해야 한다. 구축 후에는 모델 자체 점수뿐 아니라 검색·순위 지표, 제약 위반, 언어 능력 보존, 디코딩 유효성, 사람 평가와의 일치를 함께 읽어야 한다.
아직 못 읽은 북마크
북마크를 고르는 중…