10월 1일에 AWS Strands Labs가 작은 모델 하나를 오픈소스로 풀었습니다. Strands Decider 2B. 이름 그대로 "결정하는" 모델입니다.

특이한 점이 있습니다. 글을 쓰지 않습니다. 주어진 선택지 중 하나를 고르고, 각각의 확률과 확신도를 내놓는 게 전부입니다. 왜 이런 모델이 필요할까요? 에이전트가 매번 "다음에 뭘 할까"를 긴 추론으로 풀고 있기 때문입니다.

Decision model이 뭔가: System One이라는 별명

TypeSafe가 9월 15일에 Jev를 내면서 붙인 이름이 "System One" 모델입니다. Jev 글에서 다룬 것처럼, 문장을 쓰지 않고 결정을 내리는 AI입니다. 상태를 넣으면 선택·점수·예/아니오 확률이 나옵니다.

일반 LLM:       상태 → 긴 글 (토큰 많이, 느림)
Decision model: 상태 + 선택지 → 선택 + 확률 (한 번의 통과, 빠름)

Strands Decider 2B는 이 흐름의 오픈소스 버전입니다. Qwen3.5-2B를 베이스로, 다음 단어를 맞히는 부품을 떼고 선택지를 점수 매기는 "pointer" 부품(약 100만 파라미터)으로 바꿨습니다. rank-16 LoRA로 학습했고, 아키텍처 이름은 Hobson입니다. Apache 2.0이라 내려받아 뜯어보고 재학습할 수 있습니다.

Jev와의 차이는 접근 방식입니다. Jev는 API 전용(입력 100만 토큰당 $0.042, 출력 요금 없음)이고 가중치가 안 열려 있습니다. Decider는 가중치·학습 레시피까지 공개라 로컬에서 돌리고 고칠 수 있습니다. 같은 주에 OpenAI도 비슷한 offerings를 냈다는 보도가 있을 정도로, 이 자리는 지금 여러 회사가 동시에 파고 있습니다.

왜 중요? 에이전트의 선택이 비싸기 때문이다

에이전트 루프를 뜯어보면 의외로 많은 단계가 "선택"입니다.

- 다음에 어느 도구를 쓸까 (tool selection)
- 이 작업을 어느 모델에 넘길까 (routing)
- 실행해도 되는가 (approval)
- 다시 시도할까, 사람에게 넘길까 (retry)

지금은 이걸 전부 frontier LLM의 긴 reasoning으로 풉니다. 비싸고 느립니다. AWS 발표에 따르면 Decider는 짧은 작업에서 수십 밀리초대, 일반적인 하드웨어·입력에서도 100밀리초 안에서 결정을 냅니다. 크기는 약 1.9B급이라 노트북·로컬 서버에서 돕니다.

바뀌는 구조:
전:  매 선택마다 frontier 호출 (느림 + 비쌈)
후:  Generator(생성) + Decider(선택) + Verifier(검증) 역할 분담

라우팅 구현 글의 분류 단계가 바로 Decider 자리입니다. 분류는 단순해도 된다고 했는데, 이제 그 "단순한 분류"를 전담하는 오픈 모델이 생긴 것입니다.

CLI 예시: 이렇게 생겼다

공식 저장소의 예시를 가져오면 감이 옵니다.

$ strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \
  --state "Help! My payouts have been failing for 3 days!" \
  --choice "Which team should handle this?=billing,sales,retail"

choice_0 -> billing (confidence 0.768)
billing 0.845  retail 0.091  sales 0.064

예/아니오 질문도 됩니다. --noul "Does this convey urgency?" 같은 식으로 물으면 0~1 사이 값으로 답합니다. 1에 가까울수록 Yes 쪽입니다. 저장소에는 Strands 에이전트 안에서 Decider를 쓰는 예제(examples/strands/)도 들어 있습니다. 에이전트 본체는 로컬에서 돌고, 결정도 로컬 Decider에 묻고, 생성만 기본 LLM에 맡기는 구조입니다.

CodeBridge Mini Lab: 선택 1개를 떼어내기

① 우리 에이전트의 선택 지점 1개를 고른다:
   후보: tool selection / routing / approval / retry 여부

② 2주간 로그를 쌓는다 (frontier 호출 기준):
   - 선택 호출 횟수, 평균 토큰, 평균 지연, 비용

③ Decider류로 교체해 비교한다:
   [ ] 같은 선택을 하는가 (일치율)
   [ ] 얼마나 빨라졌는가 (지연 차이)
   [ ] 얼마나 쌌는가 (선택 1건당 비용)
   [ ] 확신도가 낮은 경우의 처리 (임계값 아래면 frontier에 재확인)

④ 판정:
   일치율 95% 이상 + 지연 10배 개선이면 분리 확정
   확신도 분포를 보고 임계값을 정한다 (낮으면 위로 올린다)

핵심은 확신도입니다. Decider는 답과 함께 "얼마나 확신하는지"를 줍니다. 확신이 낮을 때만 비싼 모델에 묻는 구조가 되면, Sonnet high 글의 승격 패턴과 똑같이 동작합니다. 작은 모델이 1차, 큰 모델이 2차. 자리가 정해지는 것입니다.

결론: 묻는 법을 나누세요

한 줄로 정리합니다.

"뭘 할까"와 "어떻게 할까"는 다른 모델의 일이다.

글을 쓰는 모델에게 선택까지 맡기던 시대가 끝나가고 있습니다. 선택은 빠르고 싸고 확신도를 주는 모델에게, 생성과 검증은 각자의 자리에게. 오늘 할 일은 하나입니다. 우리 에이전트에서 가장 자주 호출되는 선택 1개를 찾아 로그를 켜는 것. 그 숫자가 다음 아키텍처를 정해줍니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

선택·위임·검증을 구조로 설계하는 연습이 필요하다면, 하네스·루프·그래프를 순서대로 쌓는 과정이 이 글의 역할 분담과 바로 이어집니다.