발화 하나가 SP 호출이 되기까지

라우팅은 한 번의 판정이 아니라, 비용이 다른 여러 단계를 거치는 깔때기입니다. 대부분의 단계는 LLM 호출 없이(로컬 스코어링) 처리되고, 신호가 약할 때만 저지연 모델을 한 번 더 부릅니다. 최종 판정은 항상 AC(AI 비서)의 §CORE 로직이 맡습니다 — 사전 필터는 후보를 "좁혀줄" 뿐 대신 "결정"하지 않습니다.

사용자 발화 R0 · 생명·신체 위험 신호인가? Yes 즉시 kemergency 이하 전부 건너뜀 No 0단계 · 실행요청인가, 잡담·감정 표현인가? 잡담 AC가 그 자리에서 직접 응답 (새 탭 없음) 실행요청 라우팅 힌트 사전필터 (routing-hint.js) 0단계 · 로컬 문자열 매칭 candidate-prefilter.js · LLM 미호출 trigger 점수 ≥4면 그대로 확정 약함 1단계 · 도메인 분류(LLM 1회) domain-classifier.js · 상위 9개 도메인 실패 시 좁히지 않고 전체 통과 AC-PRO-CORE §CORE 2단계 판정 R1 · 공익(GWP) vs 사익 위임(EXPERT) R2 · GWP끼리 겹치면 코드가 사전 확정(R2확정) 힌트는 참고용 — §CATALOG 대조가 최종 판단 확신도 게이트 통과하는가? No · 되묻기 후 재평가 Yes §CATALOG·§CATALOG-EXPERT 표 안에 있는가? 표 밖 [CALL_KINTENT] 오케스트레이션 K-Intent → K-Compose → K-Execute → K-Deliver 표 안 · 단일 SP [GWP: id] 또는 [EXPERT: personaId] ktelecom·kestate만 예외 → [CALL_KTELECOM] / [CALL_KESTATE] (새 탭 없음) manifest-loader.js sp-catalog.json에서 id → 파일명 조회 후 fetch 시스템 프롬프트 조립 순서 UNIVERSAL-INTEGRITY → UNIVERSAL-common → (PROFESSIONAL-common | K-Public_common) → 개별 SP 새 탭에서 해당 SP가 대화 인계

※ 실선 화살표는 기본 진행, 붉은 점선 경로는 "확신 부족 → 되묻고 재평가" 루프입니다. 이 그림은 K-서비스/전문가 페르소나 트랙 기준이며, 정부기관 (Jejudo) 트랙의 별도 분기는 §4에서 다룹니다.

본 판정 전에 후보부터 좁혀두기

AC-PRO-CORE(§CATALOG)는 93개 이상의 GWP·EXPERT 행을 담고 있습니다. 매 발화마다 이 전체를 훑게 하는 대신, LLM 호출이 필요 없는 로컬 매칭으로 먼저 후보를 추리고, 신호가 약할 때만 저지연 모델을 한 번 더 부릅니다 — routing-hint.js가 이 두 단계를 오케스트레이션합니다.

  1. 0단계 — 로컬 문자열 매칭 (LLM 호출 없음)
    candidate-prefilter.js가 발화 텍스트와 각 GWP·EXPERT의 trigger·description을 부분일치로 대조해 점수를 매깁니다. 더 길고 구체적인 trigger일수록 높은 점수를 받습니다. 최상위 점수가 4 이상(WEAK_SIGNAL_THRESHOLD)이면 추가 호출 없이 상위 8개(MAX_HINT_CANDIDATES)를 그대로 힌트로 확정합니다. 순수 부분일치라 리터럴 trigger 단어가 없는 패러프레이즈 발화는 못 좁혀준다는 한계가 문서에 명시돼 있습니다.
  2. 1단계 — 도메인 분류 (신호가 약할 때만, LLM 1회)
    0단계 신호가 약하면 domain-classifier.jsdomain-taxonomy.js의 상위 도메인 9개(응급·온보딩 제외) 중 해당 발화가 속하는 도메인을 저지연 모델에 묻습니다. 실패하면 좁히지 않고 null을 반환해 전체 후보로 안전하게 되돌아갑니다 — 잘못 좁혀 정답을 배제하는 것이 안 좁히는 것보다 더 나쁘다는 원칙입니다. 이 폴백 경로는 후보 간 우열이 없어 상한을 25개(MAX_DOMAIN_HINT_CANDIDATES)로 넉넉히 둡니다 — 너무 세게 자르면 정답 후보를 무작위로 버릴 수 있기 때문입니다.
  3. 힌트 전달 — system이 아니라 user 메시지 앞 [ctx] 블록
    DeepSeek Auto Prompt Caching은 system 메시지가 세션 내내 고정될 때만 캐시 할인이 유지됩니다. 그래서 매 턴 달라지는 이 힌트는 system을 줄이는 대신, 매번 바뀌는 다른 데이터(GUID·위치·PDV 요약)와 같은 방식으로 사용자 메시지 앞 [ctx] 블록에 "라우팅후보:id1,id2,..." 형태로 얹습니다. AC-PRO-CORE §CORE 2단계는 이 힌트가 있으면 §CATALOG 전체를 훑기 전에 먼저 검토하되, 힌트가 없거나 명백히 안 맞으면 주저 없이 표 전체로 돌아갑니다 — 힌트는 표 자체를 대체하지 않습니다.
이 사전필터는 "누가 관련 있어 보이는가"만 판단합니다 — GWP인지 EXPERT인지, 혹은 그 후보가 실제로 맞는지는 여전히 다음 단계 (AC-PRO-CORE §CORE)의 몫입니다.

누구를 부를지 가르는 두 개의 축

후보가 좁혀진 뒤에도 실제 판정은 순서(ordinal)가 아니라 질문의 성격으로 갈립니다. ROUTER-PRIORITY_v1_0.md가 정한 원칙을 AC-PRO-CORE가 실사 사례로 구체화한 형태입니다.

기준예시
R1
GWP vs EXPERT
제도·제3자적 관점 질문 → GWP가 기본값.
개인 이익을 위한 위임 의도가 명시된 경우에만 → EXPERT로 우선권 이동.
"이혼 절차가 법적으로 어떻게 되나요" → klaw
"제 상황에서 유리하게 변호사님께 맡기고 싶어요" → SP_lawyer
R1 보강
trigger 아닌 "분야" 개념 매칭
GWP 기본값 판정은 trigger 단어가 우연히 겹치는지가 아니라, 그 GWP의 "분야" 칸에 개념적으로 속하는지로 판단. 단, 그 사무를 전담하는 전용 GWP가 따로 있으면 그쪽이 우선. klaw의 trigger엔 "특허"가 없어도, 전담 GWP가 없는 광의의 법률 사무이므로 위임의도 없는 절차 질문이면 klaw 기본값
R2
GWP vs GWP
두 GWP가 동시에 그럴듯하면, 더 길고 구체적인 trigger· "분야" 서술을 가진 쪽을 우선. 2026-08-31부터 코드가 선확정 — 한쪽 trigger가 다른 쪽을 문자열로 포함하면 candidate-prefilter.js가 승자를 확정해 [ctx]R2확정:id로 얹고, AC는 재판단 없이 그대로 채택합니다(라이브 재검증에서 프롬프트 지시만으로는 반복 재발함을 확인 후 전환). "부가세 신고"(구체, kbusiness) vs "부가세"(일반, ktax) → 코드가 kbusiness로 사전 확정
예외 처리 2건(설계상 의도됨)ktelecom· kestate[GWP: id] 문법을 쓰지 않고 [CALL_KTELECOM: query=...] / [CALL_KESTATE: query=...]로 시스템 내부 전환되는 게 정상 경로입니다(새 탭 없음). 다만 실사에서 이 두 서비스만 구식 [GWP: id]로 출력되는 사례가 2026-08-07·2026-08-31 두 차례 반복 재현됐습니다 — 그때마다 call-ai.js의 자동복구 안전망(switch-type 가드)이 100% 결정론적으로 감지해 올바른 SP로 우회 전환하는 것도 함께 확인됐습니다. 그래서 이건 "안 고쳐진 버그"가 아니라 코드 레벨 동등 처리를 정식 설계로 채택한 것입니다 — 라이브 테스트 채점 기준도 이에 맞춰 두 형태 모두 PASS로 인정하도록 갱신했습니다.

§CATALOG 밖 — Jejudo 자치사무 라우팅

위 흐름은 K-서비스(국가사무)·전문가 페르소나 트랙 기준입니다. "자치사무"(제주도·행정시·읍면동 소관)로 갈리면, 별도의 정부기관 트리(gov-tree)가 시군구·부서 단위까지 판별을 이어갑니다.

  1. 국가사무 vs 자치사무 (R2, ROUTER-PRIORITY)
    공익 대변으로 분류된 발화는 소관 기관 기준으로 다시 갈립니다 — 전국 단일 기관 소관(국세청·소방청 등)이면 K-서비스, 제주도·행정시·읍면동 소관이면 정부기관(Jejudo) 트랙입니다. 동일 생활영역(예: "세금")이라도 세목에 따라 국세(K-Tax)와 지방세 (Jejudo)로 갈립니다.
  2. 전국 행정구역 분기
    national-division-router.js가 시·도 단위로, gov-router.js가 시군구·부서 단위까지 세부 판별을 수행합니다. 15개 위성 도(province) 저장소로 분리 운영되며, SP-Tree 감사를 통해 고아 부서·라우팅 경로 누락을 주기적으로 점검합니다.
  3. SP 간 위임(relay) — 최대 1회
    두 관할이 동시에 필요한 질의(예: 국세+지방세 체납액 합산)를 위해 /gov/relay 전용 위임 메커니즘이 있습니다. 무한 위임을 막기 위해 MAX_SP_HOPS=2(위임은 최대 1회), MAX_LLM_CALLS_PER_TURN=3 두 겹의 방어선이 걸려 있습니다.

이 페이지가 취합한 문서·코드

이 페이지는 아래 문서·코드에 흩어져 있던 라우팅 판단을 하나의 그림으로 종합한 것입니다. 실제 동작의 정본(source of truth)은 항상 코드와 AC-PRO-CORE이며, 이 페이지와 ROUTING-BRANCH-REFERENCE는 그 스냅샷 요약입니다 — 원본이 바뀌면 함께 갱신이 필요합니다.