에이전트가 매번 큰 모델에게 물어보지 않아도 되는 순간: decision model 도입 기준

결론부터: decision model은 “답변 작성자”가 아니라 “다음 행동 라우터”다

2026년 10월 2일 기준으로 Cloudflare는 Clef와 Clef-flash라는 오픈소스 decision model을 공개했고, Strands Agents 팀도 Strands Decider 2B를 작은 오픈소스 decision model로 공개했다.Cloudflare 공식 Strands 공식

이 글의 답은 단순하다. 에이전트가 매번 큰 언어 모델에게 “무엇을 해야 하지?”를 긴 문장으로 묻고 있다면, decision model은 그 앞단의 라우터 후보가 된다. 다만 고객 환불 승인, 의료·법률 판단, 결제 실행처럼 실패 비용이 큰 결정은 작은 모델에게 바로 위임할 일이 아니다. 적용 조건은 선택지가 닫혀 있고, 평가셋을 만들 수 있고, 낮은 신뢰도에서 사람 또는 큰 모델로 빠지는 경로가 있을 때다.

출처 확인일은 2026년 10월 2일이다. 최근 seonoh.dev 글들은 브라우저 에이전트의 세션 권한, 프롬프트 캐싱, 에이전트 구조를 다뤘다. 오늘의 새 기여는 모델 이름 소개가 아니라 작은 decision layer를 어디에 끼워 넣고, 어디서는 막아야 하는지를 실무 체크리스트로 정리하는 것이다.

decision model이 뭔가: 문장을 쓰지 않고 선택지를 고르는 모델

일반 LLM은 답을 만들 때 토큰을 하나씩 생성한다. “이 티켓을 어떤 팀에 보낼까?” 같은 질문에도 이유와 설명을 문장으로 만들 수 있다. 반면 decision model은 애초에 출력 공간을 좁힌다. 질문, 상태, 후보 선택지를 넣으면 모델은 정해진 값과 확률을 돌려준다.

Cloudflare도 Clef를 “에이전트가 어떻게 행동할지 결정하도록 분류를 수행하는 decision model”로 설명한다. 예시는 고객지원 메시지가 긴급한지, 어느 팀이 처리해야 하는지, 사람에게 넘길지 같은 typed answer와 probability다.Cloudflare 공식

Strands Agents 글도 decision model을 “선택지 집합 사이에서 고르고 단순한 숫자 점수를 부여하는 모델”로 설명한다. 대신 복잡한 문제 해결, 코딩, 챗봇, 문서 요약 같은 일반 LLM 업무에는 맞지 않는다고 선을 긋는다.Strands 공식

관측은 이렇다. 업계가 갑자기 “작은 모델”을 사랑하게 된 것이 아니라, 에이전트 운영에서 매우 자주 반복되는 선택 문제가 드러났다. 도구를 고를지, 큰 모델을 부를지, 사람에게 넘길지, 중단할지, 더 물어볼지. 이 다섯 가지를 위해 매번 긴 자연어 추론을 생성하는 것은 느리고 비싸고 감사하기도 어렵다.

왜 지금인가: 에이전트 비용은 답변 길이보다 “결정 횟수”에서 샌다

채팅 제품에서는 사용자가 한 번 묻고 답을 읽는다. 에이전트 제품에서는 한 작업 안에 작은 결정이 수십 번 들어간다. 검색할까, 파일을 열까, 브라우저를 쓸까, 결제 화면에서 멈출까, 실패를 재시도할까, 사람에게 물을까. 각각이 큰 모델 호출이면 지연시간과 비용이 누적된다.

Cloudflare는 Clef 예시에서 Threat Intelligence 팀이 도메인 분류에 모델을 쓰고 있으며, Clef가 Browser Run과 함께 웹사이트를 가져와 렌더링하고 분류하는 데 2.2초가 걸렸고, 같은 워크플로에서 일반 LLM인 gpt-oss-120b는 4.7초가 걸리며 두 개 분류만 반환했다고 적었다.Cloudflare 공식 이 수치를 모든 업무에 일반화할 수는 없지만, “문장 생성이 아닌 분류·라우팅 업무는 다른 계산 형태가 유리할 수 있다”는 신호로는 충분하다.

Strands Decider 2B도 같은 지점을 말한다. Strands Agents 글은 이 모델이 2B 파라미터 규모이고 로컬 CPU나 GPU에서 실행 가능하며, 의미 있는 질문에 수십 밀리초 단위로 답하도록 설계됐다고 설명한다. 또 GitHub, Hugging Face, 학습 데이터와 스크립트를 함께 공개했다고 적었다.Strands 공식

여기서 중요한 한계도 있다. 작은 decision model은 “왜 그렇게 판단했는지”를 긴 글로 설명하는 데 강한 도구가 아니다. 확률과 선택지를 주기 때문에 코드에는 좋지만, 설명 책임이 필요한 결정에서는 별도 로그·근거·사람 검토가 필요하다. 속도가 빠르다는 이유로 책임까지 자동화되지는 않는다.

세 가지 도입 경로: Hosted API, open-weight, 기존 LLM prompt

Decision layer를 붙이는 방법은 크게 세 가지다.

경로	장점	한계	맞는 상황
Hosted decision API	도입이 빠르고 인프라 부담이 낮다	벤더 가격·가용성·데이터 경계에 묶인다	초기 실험, 빠른 라우팅, 이미지+텍스트 컨텍스트가 필요한 분류
Open-weight local model	지연시간·비용·데이터 통제를 직접 잡기 쉽다	배포·모니터링·튜닝 책임이 생긴다	반복량이 많고 선택지가 안정적인 내부 라우팅
기존 LLM prompt	별도 모델 없이 시작 가능하고 설명을 함께 받을 수 있다	느리고 비싸며 출력 형식이 흔들릴 수 있다	케이스가 적거나 선택지가 아직 정리되지 않은 초기 단계

Cloudflare는 Clef와 Clef-flash를 Workers AI에서 호스팅하면서도 Hugging Face에 Apache 2.0 라이선스로 오픈소스 공개한다고 밝혔다.Cloudflare 공식 Strands Decider 2B도 GitHub와 Hugging Face, 학습 데이터와 스크립트를 공개했다고 설명한다.Strands 공식 이 조합은 흥미롭다. 같은 카테고리 안에서도 “API로 빠르게 써보기”와 “가중치를 내려 받아 직접 통제하기”가 동시에 열리고 있다.

즉 오늘 제품에 붙일 때는 가용성, 계정 접근, 데이터 정책을 먼저 확인해야 한다. “모델이 나왔다”와 “우리 운영 환경에서 안전하게 쓸 수 있다”는 다른 말이다.

어디에 붙이면 좋은가: 다섯 가지 반복 결정

작은 팀이 바로 검토할 만한 적용처는 다음 다섯 가지다.

1. Tool routing: 검색, 파일 읽기, 브라우저, DB 조회 중 무엇을 먼저 쓸지 고른다.
2. Model routing: 작은 모델, 큰 모델, 이미지 모델, 코드 모델 중 어디로 보낼지 고른다.
3. Risk gating: 읽기 작업인지, 쓰기 작업인지, 사람 승인이 필요한지 분류한다.
4. Ticket triage: 고객지원·장애·영업 문의를 팀과 우선순위로 나눈다.
5. Retry decision: 같은 행동을 재시도할지, 다른 경로를 쓸지, 중단할지 고른다.

예를 들어 브라우저 에이전트라면 decision model은 “현재 화면에서 다음 행동은 click, type, wait, ask, stop 중 무엇인가”를 고를 수 있다. 코드리뷰 에이전트라면 “이 diff는 security, performance, style, docs, ignore 중 어디에 가까운가”를 고를 수 있다. 블로그 자동화라면 “이 후보는 today publish, save for later, reject, needs primary source 중 무엇인가”를 고를 수 있다.

핵심은 선택지를 작게 만드는 것이다. “좋은 글을 써줘”는 decision model의 일이 아니다. “이 후보를 오늘 쓸지 말지, 보류라면 이유 카테고리는 무엇인지”는 decision model에 맞다.

붙이면 안 되는 곳: 열린 판단, 고위험 실행, 설명 책임이 큰 결정

Decision model이 유행한다고 모든 판단을 맡기면 안 된다. 특히 다음 경우는 조심해야 한다.

• 선택지가 자주 바뀌고 정답 라벨을 만들기 어렵다.
• 한 번의 오분류가 결제, 삭제, 권한 변경, 고객 피해로 이어진다.
• 규정상 판단 근거를 사람이 이해할 수 있게 남겨야 한다.
• 낮은 신뢰도에서 멈추는 경로가 없다.
• 평가셋 없이 벤더 벤치마크만 믿고 운영에 넣으려 한다.

Cloudflare 글은 decision model이 typed answer와 probability를 돌려준다고 설명하지만, probability는 면책이 아니다.Cloudflare 공식 0.92라는 숫자가 있어도 평가셋이 잘못됐거나 실제 분포가 바뀌면 틀릴 수 있다. 그래서 decision model의 좋은 사용법은 “자동 승인”보다 “자동 라우팅 + 낮은 신뢰도 보류 + 사람이 볼 로그”에 가깝다.

작은 팀의 10단계 도입 체크리스트

1. 먼저 “결정 하나”만 고른다. 예: 티켓 우선순위, 도구 선택, 사람 승인 필요 여부.
2. 출력 선택지를 3~7개로 제한한다.
3. 각 선택지의 정의와 반례를 문서화한다.
4. 최근 실제 사례 100~300개를 라벨링한다. 적으면 30개라도 시작하되 운영 자동화는 미룬다.
5. 현재 LLM prompt baseline을 만든다.
6. hosted API 또는 open-weight model을 같은 평가셋에서 비교한다.
7. 정확도만 보지 말고 false positive, false negative, latency, cost, low-confidence 비율을 같이 본다.
8. 낮은 신뢰도는 큰 모델 또는 사람에게 넘긴다.
9. 운영 로그에는 입력 요약, 선택지, 확률, 임계값, 최종 실행 결과를 남긴다.
10. 모델 교체와 임계값 변경은 feature flag로 되돌릴 수 있게 둔다.

이 순서를 지키면 decision model은 “또 하나의 유행 모델”이 아니라 에이전트 운영의 작은 스위치가 된다. 반대로 이 단계를 건너뛰면 빠른 모델이 빠르게 틀리는 시스템이 된다.

seonoh.dev 자동화에 적용한다면

이 블로그 파이프라인에도 적용할 수 있는 지점이 있다. 주제 후보를 고를 때 “오늘 발행”, “출처 부족”, “최근 글과 중복”, “이미지 대기”, “사람 판단 필요”처럼 닫힌 선택지를 만들 수 있다. Slack 검토에서도 “pass/fail/blocked” 자체는 이미 닫힌 decision 구조다.

다만 최종 발행 여부는 작은 모델에게 맡기면 안 된다. 발행은 원고 해시, 이미지 해시, 실제 역할 검토, 빌드, 배포 read-back이 모두 묶이는 외부 상태 변경이다. Decision model은 그 앞단에서 후보를 줄이고 라우팅을 빠르게 할 수 있지만, 검증 증거를 대체하지 않는다.

이 구분이 오늘의 실무 결론이다. 작은 모델은 결정을 빠르게 만들 수 있다. 하지만 어떤 결정이 자동화 가능한지 정하는 일은 여전히 시스템 설계 문제다.

FAQ

Decision model은 작은 LLM과 같은 말인가?

겹치지만 같지는 않다. 작은 LLM은 여전히 문장을 생성할 수 있다. Decision model은 출력이 정해진 값과 확률로 제한되는 쪽에 초점이 있다. 구현은 LLM 기반일 수 있지만, 제품 관점에서는 “텍스트 생성기”보다 “선택 함수”에 가깝다.

기존 LLM에 JSON으로 답하라고 하면 충분하지 않나?

초기 실험에는 충분할 수 있다. 다만 요청량이 많고 선택지가 안정적이면 지연시간, 비용, 출력 형식 안정성 때문에 decision model을 검토할 만하다. 반대로 선택지가 자주 바뀌고 설명이 중요하면 기존 LLM prompt가 더 안전할 수 있다.

확률이 높으면 자동 실행해도 되나?

아니다. 확률은 운영 정책의 입력일 뿐이다. 결제, 삭제, 권한 변경, 고객 통지처럼 실패 비용이 큰 행동은 높은 확률이어도 사람 승인이나 별도 검증 게이트를 둬야 한다.

오픈 가중치 decision model이 hosted API보다 항상 낫나?

아니다. 오픈 가중치는 데이터 통제와 비용 예측에 유리할 수 있지만, 배포·모니터링·보안 패치·성능 튜닝 책임이 생긴다. 작은 팀은 hosted API로 평가셋을 먼저 만들고, 반복량과 데이터 정책이 명확해졌을 때 local path를 검토하는 편이 현실적이다.

가장 먼저 붙여볼 만한 업무는 무엇인가?

“정답 후보가 이미 있는 라우팅”이 좋다. 예를 들어 고객 문의 팀 배정, 도구 선택, 모델 선택, 사람 승인 필요 여부, 재시도/중단 판단이다. 자유로운 기획, 장문의 근거 작성, 법적 판단처럼 열린 문제는 맞지 않는다.

출처

• Cloudflare — Introducing Clef: open-source decision models
• Strands Agents — Introducing Strands Decider 2B

타깃 유입 키워드

AI decision model, Cloudflare Clef, Strands Decider 2B, AI agent routing, 에이전트 라우팅, small decision models