로컬 SLM 신뢰 여부는 검증 가능성으로 그은 네트워크 자동화 경계로 정해진다.

무엇인가

네트워크 운영 데이터는 그 자체로 민감하다. 운영 중인 설정, 토폴로지, 로그를 매번 서드파티 프런티어 LLM에 보내는 것은 데이터 유출이면서 동시에 상당한 비용이다. 그렇다고 온프레미스에서 프런티어급 모델을 돌리려면 GPU 인프라와 운영 전문성이 필요하다. 8B 이하 소형 언어모델(SLM)을 사내에서 돌리면 이 문제는 사라지지만, SLM은 추론 능력이 약하고 환각이 잦으며 컨텍스트 창도 좁다. 이 논문의 문제의식은 여기서 출발한다. SLM을 "작은 프런티어 모델"로 취급하는 것이 잘못된 추상화이며, 로컬 출력을 받아들일지 프런티어로 넘길지 결정하는 원칙이 필요하다는 것이다.

어떻게 동작하나

저자들이 제시하는 기준은 검증 가능성(checkability)이다. 핵심 개념은 내재적 검사(intrinsic check)로, 입력 x, 후보 출력 y, 선택적 네트워크 상태 s에 대한 결정론적 술어 Q(x, y, s)다. 정답성 P(x, y)가 성립하면 반드시 Q도 성립한다는 함의 관계, 즉 Q는 정답의 필요조건이지 충분조건이 아니다. 그래서 검사는 단방향이다. 검사에 실패하면 후보는 확실히 틀렸다고 반박할 수 있지만, 통과했다는 것은 반박을 면했다는 뜻일 뿐이다. 통과한 후보 중 실제로 틀린 비율, 즉 오수용률(false-accept rate)을 따로 측정해야 신뢰도를 알 수 있다. 검사는 정답지도, 검증 모델도, LLM도, 원격 API도 쓰지 않는다. 논문은 작업별로 이런 검사를 하나씩 정의한다. 의도 번역에는 요청에 없는 위치·프리픽스를 만들어내지 않는 접지(grounding) 검사와 요구사항 절 수와 규칙 원자 수를 맞추는 커버리지 검사를 쓰고, 충돌 탐지에는 요구사항 문장을 위치-프리픽스 쌍으로 파싱해 같은 쌍이 도달 가능과 불가능으로 동시에 주장되는지 보는 일관성 검사를 쓴다. 로그 파싱에는 생성된 템플릿이 원본 로그 라인을 다시 만들어낼 수 있는지 보는 가역성 검사를, 라우팅 코드 생성에는 생성된 함수를 테스트 케이스에 실제로 실행하는 실행 검사를 쓴다. 검사는 질의마다가 아니라 작업마다 시스템 설계자가 한 번 작성하며, 분량은 각각 49줄, 43줄, 28줄 수준으로 작다.

무엇과 다른가

이 아이디어를 구현한 것이 Touchstone이다. Llama-1B, Qwen-1.5B, SmolLM-1.7B, Qwen-3B, Llama-3B, Qwen-7B, Llama-8B 등 7개의 기성 SLM을 세 단계로 돌린다. 첫째는 오프라인 프로파일링으로, 전체 데이터의 23.1~25.0%(작업당 100~150개)를 개발 셋으로 써서 모델별 정확도를 재고 투표 가중치 w_m = max(0.02, acc_m − chance)^1.5 를 계산한다. chance를 빼서 우연 수준의 모델이 집계를 지배하지 못하게 하고, 1.5제곱으로 우연보다 확실히 나은 모델에 힘을 실어준다. 둘째는 로컬 생성·집계다. 충돌 탐지와 로그 파싱은 단일 답을 내므로 가중 투표를 쓰되, 충돌 탐지에서는 일관성 검사가 모순을 입증하면 투표를 덮어쓰고, 로그 파싱에서는 가역성 검사를 통과하지 못한 템플릿을 배제한다. 라우팅 코드는 여러 구현이 정답일 수 있으므로 투표 없이 실행 검사를 통과한 후보를 모두 남긴다. 의도 번역은 규칙 단위 원자로 분해해 7개 모델의 원자를 합치고, 동일 원자를 병합한 뒤 그 원자를 생성한 모델들의 가중치 합이 전체의 절반 이상이면 채택한다. 이렇게 조립한 명세와 내재적 검사 점수가 가장 높았던 개별 명세를 비교해 더 나은 쪽을 남긴다.

어떻게 쓰나

셋째는 신뢰도 기반 에스컬레이션이다. 집계된 후보에 0~1 사이 신뢰도 conf(x)를 매기고, 임계값 τ = 0.6 미만이면 프런티어 LLM으로 넘긴다. 기본 신뢰도는 선택된 후보를 지지하는 가중치 비율인 패밀리 합의도다. 여기에 작업별 검사가 개입한다. 충돌 탐지에서 모순이 입증되면 conf를 1로 고정하고, 라우팅 코드는 테스트를 통과한 함수가 하나라도 있으면 1, 없으면 0으로 둔다. 의도 번역에서는 접지·커버리지 검사가 찾아낸 결함이 합의 점수를 깎아 임계값 아래로 밀어낼 수 있다. 에스컬레이션할 때는 재현되지 않은 토큰, 접지되지 않은 엔티티, 실패한 실행 테스트 같은 진단 증거를 프런티어 프롬프트에 수리 힌트로 함께 넣는다.

전제와 한계

실험은 충돌 탐지, 의도 번역, 로그 파싱, 라우팅 코드 생성의 네 가지 구조화된 네트워킹 작업과 지식 전용 대조군인 TeleQnA에서 이뤄졌고, 베이스라인은 모든 입력을 프런티어 모델(GPT-5.5)로 보내는 방식이다. 충돌 탐지는 98.6% 정확도에 에스컬레이션 16%, 오수용 0건이었다(프런티어 100%). 의도 번역은 93.8% 정확도, 에스컬레이션 17%, 오수용률 5.6%로 프런티어 99.2%에 못 미쳤다. 로그 파싱은 검사의 한계가 드러난 지점이다. 가역성은 필요조건이지만 선택력이 약해서 지나치게 일반화된 템플릿도 통과한다. OpenSSH 오수용률 27.7%, Proxifier 30.0%로 통과한 템플릿의 거의 3분의 1이 틀렸고, Touchstone은 각각 37%, 42%를 에스컬레이션해 정확도를 메웠다. HDFS는 에스컬레이션이 7%로 가장 낮았지만 정확도 91.7%(프런티어 98.7%)에 그쳤고, 오수용률 14.4%가 그 격차를 설명한다. 라우팅 코드는 검사가 가장 강력한 대신 SLM이 통과하는 함수를 거의 만들지 못해(최고 단일 모델 8개 중 1개, 전체 모델 합쳐 8개 중 2개) 75%를 에스컬레이션했고 정확도는 프런티어와 같은 50%였다. TeleQnA는 내재적 검사가 없어 78.2%에 머물렀다(프런티어 84.2%). 최고 단일 SLM 대비 개선폭은 충돌 탐지 84.0%→98.6%, 의도 번역 74.0%→93.8%, OpenSSH 74.3%→99.7%, HDFS 86.3%→91.7%, Proxifier 65.0%→87.7%였고, 검사가 없는 TeleQnA는 78.0%→78.2%로 사실상 변화가 없었다.

개발자에게 이 논문이 주는 실무 규칙은 단순하다. 작업 의미론이 정확하고 값싼 검사를 지원하면 추론을 로컬에 두고, 나머지는 프런티어로 올려라. 모델 선택보다 작업의 검증 가능성을 먼저 따지라는 것이다. 도입 전에 확인할 것은 두 가지다. 하나는 내재적 검사의 오수용률로, 통과한 로컬 답이 실제로 얼마나 틀리는지를 개발 셋에서 측정해야 한다. 다른 하나는 불필요한 에스컬레이션 비율, 즉 맞는 답을 검사가 잘못 거부하는 비율이다. 이 두 수치가 배포 전에 잔여 위험과 로컬 커버리지 손실을 명시적으로 보여준다. 에스컬레이션률이 낮다는 사실 자체는 성과가 아니다. HDFS처럼 잘못된 답을 로컬에 붙잡아 두면 프런티어 사용을 줄였어도 성공이 아니다.

저자들이 밝힌 한계는 분명하다. 내재적 검사는 필요조건일 뿐 충분조건이 아니므로, 오류가 탐지 가능한 흔적을 남기지 않으면 틀린 후보가 통과한다. 검사 강도는 스펙트럼을 이룬다. 명시적 논리 모순을 잡는 충돌 탐지가 강한 쪽 끝, 접지·커버리지로 흔한 실패만 거르는 의도 번역이 중간, 가역성처럼 관대한 로그 파싱이 약한 쪽 끝이고, 지식 전용 작업은 경계 바깥이다. 또한 강한 검사도 로컬 모델이 유효한 후보를 생성하지 못하면 무용하다. 라우팅 코드가 그 예로, 실행 검사는 신뢰할 만하지만 SLM이 통과하는 프로그램을 거의 만들지 못해 결국 대부분을 프런티어로 넘겼다. 검사는 작업마다 설계자가 직접 작성해야 하며, 모델 다양성과 선택적 에스컬레이션만으로는 내재적 검사가 없는 작업에서 전 프런티어 성능을 따라잡을 수 없다는 것이 TeleQnA의 부정적 결과다.