의사 결정 LLM: 모델이 결정해야 할 때와 결정하지 않아야 할 때

에이전트 시스템 실무자에게 무엇이 깨지는지 물으면, 답은 드물게도 능력(capability)이 아닙니다. 실패는 더 조용하게 찾아옵니다: 모델은 판단하지만, 아무도 올바른 판단과 유창한 답변을 구별할 수 없는 것입니다.

모델 출력은 하나의 샘플입니다. 판단에는 샘플이 가지 않는 속성이 있습니다 — 고정 입력에 대한 결정성, 만족해야 하는 불변 조건, 그리고 이것이 대안인 다른 선택지가 아닌 왜 이 것인지 설명하는 감사 추적입니다. 이러한 속성이 부재할 때, “판단"이라 불리는 것은 하나의 판단을 가장한 높은 확신의 추측에 불과합니다.

이 글은 그 간극에 기계적인 처리 방식을 제공합니다. 다섯 가지 판단 역할의 분류 체계, 각 판단을 그 판단을 수행하기에 가장 적임인 최소한의 모델로 라우팅하는 규칙, 그리고 “에이전트가 X를 판단했다"는 것을 나중에 옳았음을 입증할 수 있는 것으로 전환하는 검증 메커니즘입니다. 글은 독자 자신의 시스템에서 어떤 액션에든 적용할 수 있는 평가 기준(Rubric)으로 마무리됩니다.

“로컬 에이전트의 경우, 내가 계속 부딪히는 간극은 능력이 아니라 검증입니다. 에이전트가 파일을 읽었다고, 도구를 호출했다고, 또는 판단을 내렸다고 말하지만…” — r/LocalLLaMA, “최고의 로컬 에이전트 — 2026년 6월”

“LLM 에이전트가 실패할 때, 그것은 블랙박스가 되어 아무도 왜 그렇게 되었는지 모릅니다. 채택의 진정한 병목은 모델의 정확도를 92%에서 96%로 끌어올리는 것이 아니라 — [왜 X라고 판단했는지 아는 것입니다].” — r/AI_Agents, “판단과 실행 사이의 간극”

커뮤니티는 세 가지 본능으로 수렴했습니다: 모델에게 최종 결정권을 맡기지 말 것, 판단을 수행할 최소한의 적임 모델로 판단을 라우팅할 것, 그리고 판단을 설명 가능하게 만들 것. 그동안 빠졌던 것은 이 세 가지를 동시에 실행 가능하게 만드는 프레임워크였습니다.

왜 “답은 하지만, 판단은 하는가?”

모델 출력은 하나의 시퀀스로 수렴한 토큰 분포이며, 동일한 프롬프트를 두 번 실행하면 정확히 중요한 토큰에서 달라지는 두 개의 시퀀스가 생성될 수 있습니다. 반면, 판단은 고정 입력에 대해 결정적이며, 명시적인 불변 조건을 만족하고, 어떤 분기가 취해졌고 그 이유는 무엇인지 기록하는 감사 추적을 남깁니다.

모델이 주변 메커니즘 없이 “판단"할 때, 이러한 속성 중 어느 것도 존재하지 않습니다. 출력이 반드시 준수해야 할 불변 조건도, 취해진 분기의 로그도, 판단을 다시 실행하여 유지되었는지 확인할 방법도 없습니다. 그 간극은 지능이 아닙니다 — 확률적 출력이 결정적인 출력을 위해 설계된 슬롯에 배치되었기 때문입니다.

실무자의 본능은 모델의 판단 관여를 완전히 배제하는 것입니다:

“LLM은 시스템에서 최종 결정을 내리지 않습니다. 그 역할은 순수합니다: 논리 정교화, 스트레스 테스트, 시나리오 생성, 설명.” — r/AI_Agents, “‘가격 검증용 ‘추론 에이전트’로 LLM 사용하기…”

그것은 원칙으로 제시된 올바른 자세입니다. 이를 적용하려면, 주어진 액션에 대해 모델이 어떤 역할을 맡아야 하는지 분류할 방법이 필요합니다 — 아래에 제시된 분류 체계가 바로 그것을 제공합니다.

다섯 가지 판단 역할

시스템이 내리는 모든 판단은 다섯 가지 역할 중 하나에 할당될 수 있습니다. 역할은 모델 출력을 얼마나 신뢰할 수 있는지, 어떻게 감사되는지, 어떻게 실패하는지, 그리고 휴먼-인-더-루프(Human-in-the-loop)에 사람이 포함되어야 하는지를 결정합니다.

표를 메뉴가 아닌 제약 조건으로 읽어보세요. 대부분의 깨진 시스템은 하나의 결함을 공유합니다: 단일 모델이 다섯 가지 역할을 동시에 수행하므로, 결정성이 요구되는 역할(결정자)이 유창함 최적화 컴포넌트(생성자)에 의해 처리되는 것입니다. 모델이 생성자로서 작동하는 곳에서는 판단 메커니즘이 필요하지 않습니다 — 내용 검토가 필요합니다. 피해야 할 실패는 이것들을 혼동하는 것입니다: “에이전트가 환경을 삭제하기로 판단했다"는 것은 대부분 승인 게이트 누락이며, 판단 품질의 문제가 아닙니다.

판단을 수행할 최소한의 적임 모델로 라우팅

역할이 고정되면, 라우팅 문제는 어떤 모델 티어가 그것을 제공하는지가 됩니다. 실무자들이 직접 그 효과를 보고 있습니다:

“모델 라우팅: 분류/라우팅 판단에는 Haiku, 실행에는 Sonnet, 디자인/계획에만 Opus를 사용. 모든 것에 Opus를 사용하는 것을 멈추자 비용이 약 60% 감소했습니다.” — r/AI_Agents, “2026년 당신의 전체 AI 에이전트 스택은 무엇인가”

그 수치는 모델 선택을 시스템 단위가 아닌 역할 단위의 판단으로 처리한 데서 유래합니다. 라우팅 호출 — “이것은 이메일 분기인지 환불 승인인가?” — 는 분류이며, 분류에는 프론티어 모델이 필요하지 않습니다; 그것은 수천 번 실행되므로 작고, 빠르고, 낮은 온도(tempature)의 모델이 필요합니다. 티어 메커니즘 — 능력 기반, 비용 인식, 그리고 지연 시간 인식을 통한 선택, 더 나아가 폴백 체인(fallback chains) — 은 모델 라우팅: 모든 것에 하나의 모델을 쓰지 마세요에서 다뤄지며, 여러 모델 주변의 오케스트레이션 패턴은 멀티-모델 시스템 디자인에 있습니다.

판단 프레이밍이 제공하는 추가 요소는 **확신 기반 에스컬레이션(Confidence-based Escalation)**이며, 이는 “최소한의 적임자"가 가정되는 것이 아니라 측정되는 것이 되도록 합니다. 가장 작은 티어에서 시작합니다. 모델이 보정된 확신을 방출하거나 — 또는 구조화된 자기 평가를 내거나 — 임계값을 통과하면 멈춥니다. 그렇지 않으면 한 티어 상승하여 에스컬레이션을 기록합니다. 그렇게 되면 적임성은 모델별로 가정되는 속성이 아닌, 호출별로 검증되는 속성이 됩니다.

티어에 관계없이 절대적인 제약 하나 있습니다: 라우터 역할 자체가 무제한적인 언어 모델 호출이어서는 안 됩니다. 작업 유형, 페이로드 크기, 비용 예산에 대한 규칙이라는 결정적인 뼈대(Spine)가 분기를 선택하고, 모델은 그 안에 있는 리프(Leaf) 판단만 채웁니다. 뼈대는 감사 및 단위 테스트가 가능하며, 모델은 실제로 잘하는 것으로 제한됩니다.

판단을 검증 가능하게 만드는 것

이것이 바로 “에이전트가 X를 했다고 말했다"는 간극이 닫히는 지점입니다. 해결책은 판단을 채팅 턴의 부수적 효과(side effect)가 아닌, 일급 구조화된 산출물(First-class structured artifact)로 만드는 것입니다:

1. 구조화된 판단 저장소. 모델이 내릴 수 있다고 허용되는 모든 판단은 로그 라인이 아닌 테이블에 기록됩니다: 입력, 역할, 모델과 티어, 확신, 고려된 대안, 타임스탬프. 판단은 나중에 SELECT할 수 있는 것입니다. 대화 트랜스크립트에만 존재한다면, 그것은 추측입니다.
2. 실행 로그와 분리된 판단 로그. 실행 로그는 무슨 일이 있었는지를 말하고; 판단 로그는 무엇을 판단했는지, 그리고 그 근거가 무엇인지를 말합니다. 이 분리 사항은 중요합니다. 실패는 대개 실행이 아닌 판단에 있기 때문입니다 — 에이전트는 삭제를 완벽하게 실행했습니다; 버그는 삭제를 판단한 것이었습니다. 구조화되고 부속형(append-only) 로깅의 메커니즘은 실무에서 LLM 가드레일에서 준수 감사 추적을 위해 사용되는 것과 동일한 것입니다.
3. 불변 조건과 애플리케이션. 결정자와 평가자 역할을 위해, 판단은 모델이 그것을 방출한 후 결정적 코드로 확인되는 불변 조건을 만족해야 합니다. 가격 권고자는 아무것도 방출할 수 있습니다; “권고된 가격은 [최저한, 상한] 내에 있어야 한다"는 불변 조건은 코드로 강제됩니다. 모델은 제안하고, 불변 조건은 결정합니다.
4. 비가역성 경계에서의 휴먼 승인 게이트. 게이트는 모델의 확신이 아니라 액션의 폭발 반경(Blast radius)의 속성입니다. 임계값 이하의 환불은 자동 승인 가능합니다; 그 이상은 아닙니다. 99% 확신을 가진 모델조차 감사 기록이 없는 비가역적 액션을 승인할 수 없습니다.

핵심 통찰: 92%→96% 정확도 추진은 병목이 아닙니다 — 설명 가능성(Explainability)입니다. 모든 판단이 기록되고, 불변 조건으로 확인되며, 경계에서 게이트링된 92%의 시스템은 안전하게 출시됩니다. 왜냐하면 잘못된 판단의 8%가 피해를 입히기 전에 발견 가능하기 때문입니다. 블랙박스 판단 프로세스를 가진 99%의 시스템은 그렇지 않습니다. 왜냐하면 1%는 포렌식 기록 없는 진행 중인 사고이기 때문입니다. 게이트 자체가 어시스턴트에 있는 경우 — 승인 권한을 어떤 컴포넌트가 갖고 있고 요청은 어떻게 도달하는지 — 은 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 관찰 가능성에서 설명되어 있습니다.

실전 예시

세 개의 시스템, 각자 하나의 역할 할당.

가격 검증 — 모델은 권고자이며, 결코 결정자가 아님. 에이전트는 공급업체의 가격 변경을 검토하고 랭킹된 목록을 생성합니다: 수용, X에서 협상, 거절. 최종 호출은 결정적 규칙에 의해 채워지는 결정자 슬롯입니다: 원가 하한 이하, 자동 수용; 상한 이상, 사람에게 라우팅; 그 사이, “협상된 가격은 마지막으로 수용된 것보다 Y% 이상 이득이어야 한다"는 불변 조건을 적용. 모델은 자신의 권고를 승인하지 않으며, 권고는 잘못되면 그 평가 기준 추적을 포함하여 판단 저장소에 머뭅니다.

에이전트 작업 라우팅 — 뼈대는 결정자, 모델은 리프에서. 수신 요청(이메일, 티켓, 명령)은 페이로드 형태와 의도 카테고리에 의해 경로를 할당받습니다 — 결정적이고, 단위 테스트 가능. 작은 모델은 분기 안의 리프 판단만 채웁니다. 잘못된 라우팅은 폭발 반경 사건이며, 바로 이것이 분기 선택이 결정적이어야 하는 이유입니다.

LLM-as-judge — 모델은 평가자, 평가 기준은 제약. 하나의 모델이 버전 관리된 평가 기준으로 다른 모델의 출력을 점수화하고, 점수 및 평가 기준 추적은 단순히 숫자가 아닌 저장됩니다. 알려진 실패 모드는 자기 선호 편향 — 자신의 생성 스타일을 더 높게 점수화하는 모델 — 이며, 완화책은 구조적입니다: 평가 기준을 버전 관리하여 모델이 자신이 형성한 기준으로 은밀하게 점수화하는 일이 없도록 합니다.

정직한 경계

LLM이 내면 안 되는 종류의 판단이 있으며, 그것은 규모에 대한 문제가 아닙니다: 비가역적이고, 고위험하며, 폴백이 없는 액션 — 데이터 삭제, 자금 이동, 외부 약속. 롤백할 수 없는 액션에 대한 검증은 불가능하며, 이것이 모델 품질과 관계없이 “자율 에이전트"가 항상 같은 벽에 부딪히는 이유입니다.

허세(Therater)가 아닌 휴먼-인-더-루프는 정확히 그 경계에 위치하며, 다른 어디에도 없습니다. 모든 저위험 판단을 검토하는 사람은 마찰을 추가하고 안전은 제공하지 않습니다; 모든 고위험 판단에서 부재하는 사람은 그 사고입니다. 동일한 원리는 에이전트 메모리의 더 좁은 형태로 나타납니다: 자기 강화 메모리 루프는 영구 상태에 도달하기 전에 명시적인 휴먼 승인 뒤에 후보 메모리 기록을 게이트링합니다 — 기록이 깨질 수 있는 것에 맞게 게이트의 크기를 정한 것입니다. 멀티-에이전트 시스템의 경우, 이에 해당하는 질문은 누구의 대리로서 누구를 행동할 수 있는가이며, 그것에 대한 신원, 위임, 그리고 감사 추적 메커니즘은 A2A 및 MCP 에이전트 보안에 있습니다.

판단 평가 기준

이것을 시스템의 어떤 액션에도 적용해 보세요:

1. 역할을 분류하세요. 결정자, 권고자, 평가자, 생성자, 또는 라우터? 이름 없는 역할은 버그입니다 — 생성자의 확신을 쓴 결정자 슬롯에 있는 모델.
2. 그 역할에 맞는 티어를 선택하세요. 최소한의 적임, 호출별로 적임성이 측정되도록 확신 기반 에스컬레이션 포함.
3. 검증을 정의하세요. 어떤 불변 조건이 만족되어야 하나? 판단 저장소에 무엇이 들어가는가? 감사 추적은 무엇인가? 검증 경로가 없는 역할은 기본적으로 결정자입니다.
4. 확신이 아닌 폭발 반경에서 휴먼 게이트를 설정하세요. 비가역적이거나 고위험 → 게이트링. 그렇지 않으면 → 자동, 나중에 찾을 수 있도록 판단이 기록됨.

동일한 규율이 런타임 액션이 아닌 엔지니어링 선택에 적용되는 것이 판단 기록(Decision Records)이 하는 일입니다 — AI 주도 개발을 위한 판단 기록은 나중에 검토할 수 있도록 선택이 왜 만들어졌는지 포착하며; 위의 평가 기준은 실행 중인 시스템이 내리는 판단에 대해 같은 일을 합니다.

앞으로의 전망: 프로덕트로서의 결정자

이 프레임워크는 자체의 상품화(Commoditization)를 예측합니다: “판단을 수행할 최소한의 적임 모델로 라우팅"이 패턴이 된 후, 다음 단계는 판단만 하는 모델 클래스였습니다. 그 단계가 이제 도착했습니다.

2026년 10월까지, 여러 벤더가 공유된 레시피 — 동결된 Qwen 백본, 랭크-256 LoRA 어댑터, 그리고 결합 스키마 헤드 — 에 기반한 모델을 출시했습니다 — 단일 포워드 패스에서의 타입화된 판단을 방출합니다: 열거된 집합에서의 선택, 예/아니요, 또는 보정된 확률과 자유 형식 텍스트 없는 점수. 대기할 사고 사슬(Chain of thought)이 없습니다. 왜냐하면 생성이 없기 때문입니다. 벤더 보고 지연 시간은 이 클래스 전체에서 대략 8ms와 210ms 사이에 위치합니다 — 가장 작은 변형(d1-3B, 약 8ms)부터 가장 큰 것(d3, 약 209ms)까지 — 그리고 풋프린트는 소형 GPU 영역입니다: d1-3B는 약 1.67 GB, d3-flash는 Q4_K_M에서 약 6.6 GB. 지원도 빠르게 이동했습니다: llama.cpp는 출시 후 대략 두 주 안에 이 중 여러 모델에 대한 네이티브 아키텍처 지원을 병합했습니다.

위 프레임워크에 대한 두 가지 결과. 첫째, 라우팅 규칙에는 이전에 없던 하드웨어 표현을 얻습니다: 결정자 역할은 일반 모델의 프롬프트 모드 대신 전용 소형 모델로 처리될 수 있으며, 이는 최소한의 적임 티어 판단이 부분적으로 자동화됩니다 — 해당 판단 유형에 대한 티어가 존재하거나, 존재하지 않거나. 둘째, 검증에 관해 어떤 것도 변하지 않습니다. 8ms의 타입화된 판단은 여전히 판단 저장소, 불변 조건, 그리고 비가역성 경계의 게이트를 필요합니다; 모델 클래스가 제거하는 것은 생성 비용과 비결정성이며, 감사 부담이 아닙니다. 더 빠른 판단은 감사할 판단 기록의 수를 증폭시킵니다 — 병목은 모델의 속도가 아니었고, 모델의 지능도 아닙니다.

주시할 다른 방향은 더 조용합니다. 소형 모델의 도구 호출 신뢰성은 포화점에 근접하고 있으며 — 도구 사용에 대한 후학습(post-training)은 스택에서 가장 저렴한 고탄력 단계이며, 이는 주의를 위의 행들로 이동시킵니다. 신뢰할 수 있는 계획 지평(Horizons)은 계속 확장되고 있으며, 이는 결정자 역할을 더 긴 작업에서 도달 가능하게 만들고, 지평과 함께 검증 부담을 성장시킵니다. 둘 다 동일한 결론에馈(Feed)합니다: 에이전트 시스템의 희소 자원(Autonomous Agent Systems of the Scarce Resource)은 나중에 옳았음을 입증할 수 있는 판단이며, 나머지는 그것에 따라잡고 있습니다.