Strands Decider 핸즈온! 이벤트 메모

2026년 10월 8일의 'JAWS-UG Tokyo Strands Decider 핸즈온' 이벤트 메모입니다.

핸즈온 절차서가 공개되어 있어, 당일에 구두로 가이드나 보충된 내용이 있다면 앞으로 시도해 보고 싶은 사람(저 같은 사람… 에?)에게 좋을 것 같아 작성했습니다. 절차서에 쓰여 있는 내용(커맨드, 화면 조작, 결과 수치 등)은 생략했습니다.

미실시(시간을 맞추지 못했거나... 앞으로 할 예정) 상태에서 작성된 것이라 오류가 많을 수도 있습니다. 발견하시는 부분이 있다면 댓글 등으로 알려주시면 감사하겠습니다.

Strands Decider 소개와 AWS 계정 로그인, 리전(도쿄) 확인.

실행 포인트

• 리전은 '도쿄'로 설정해야 합니다. 처음 계정을 만든 사람은 초기 리전이 시드니인 경우가 있으므로 확인하세요 (절차서는 '도쿄에 설정'이라고만 쓰여 있습니다). - 절차서는 거의 완성되었으므로, 복습이나 심화는 절차서에서 다룬다는 위치입니다.

논의된 토픽

Strands Decider란 무엇인가: 공식 정보는 대부분 영어 블로그뿐입니다. 의사결정 모델로, 여러 선택지 중에서 최적의 것을 순식간에 골라주는 **'매우 유연한 if문'**이라고도 합니다. 9月中旬부터 화제가 된 Jev를 AWS에서도 호스팅할 수 있도록 한 것이라는 위치입니다.

로컬 PC가 아닌 EC2상의 VS Code에서 작업합니다 (Mac/Windows, 개인 PC/회사 PC 환경 차이를 없애기 위해). 공식 템플릿은 배포 시 오류가 발생하므로, 'うまくいかない場合は修正版のテンプレートで作成' 절차를 사용합니다.

실행 포인트

• 수정판 템플릿을 클릭하여 새 탭에서 열고 Ctrl+S로 저장합니다. 저장 이름이 기본값과 달라도 문제없습니다.
• 파라미터의 UserFullName(절차서에는 나오지 않는 항목)은 아무거나 괜찮습니다. - '스택 생성'에서 나오는 두 가지 선택지는 위에 있는 '新しいリソースを使用 (標準)'을 선택합니다.

논의된 토픽

Strands Decider의 원리(스택 생성 대기 시간에 설명) - 일반적인 LLM은 다음에 올 단어를 확률 순으로 하나씩 예측하며 문장을 만듭니다. Strands Decider는 그 '다음 단어를 예측하는 부분'을 제거하고, 대신 주어진 선택지를 채점하는 처리를 추가한 것입니다. - 기반은 Qwen3.5-2B로 작고 빠릅니다. '상황', '질문', '선택지'를 전달하면, 선택지별 점수를 반환합니다. '이것을 고른다'뿐만 아니라 7점, 2점, 1점과 같은 채점값이 함께 돌아옵니다. - 답변 방식은 세 가지입니다. Yes/No, 여러 선택지 중의 확률, 그리고 설명하기 어려운 score.

• 일반적인 LLM은 다음에 올 단어를 확률 순으로 하나씩 예측하며 문장을 만듭니다. Strands Decider는 그 '다음 단어를 예측하는 부분'을 제거하고, 대신-
• レオナさん(Fusic)의 Zenn 기사: 모델 구조나 학습 방법, 데이터까지 수식이 포함되어 자세히 쓰여 있습니다. 당일 설명은 표면적인 것이므로, 내부를 알고 싶은 사람은 이 글을 읽는 것이 좋습니다. - '이 모델의 장점은 속도인가?' - 문장을 생성하는 능력은 없습니다. 지금까지 나온 새로운 LLM 중 하나라는 인식은 수정해야 합니다.
• 활용처는 대량의 분기 처리(워크플로우) 대체나, 에이전트가 문의를 전달하기 전의 분류기(Strands Agents로 해결할 문제인지, 사람에게 에스컬레이션해야 할 어려운 내용인지를 미리 판정하는 것)입니다. - '선택지만 반환하는 것이 불편하지 않은가'라는 의문에는 기존 기술의 조합이긴 하지만, 빠르게 할 수 있게 된 것으로 인해 한 번에 화제가 되었다는 견해가 있습니다. - 참가자 의견:

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

• 로컬에서 구동하는 장점 (Jev와의 가장 큰 차이점은 로컬에서 사용 가능하다는 질문에 대한 답변) - 컴퓨터가 있다면, 자신의 환경에서 구동하는 것이 더 빠르다. 에이전트를 구동하는 환경에 함께 배치할 수도 있다.
• Jev는 미국 서버에 호스팅되어 있어, 일본에서는 거리 때문에 레이턴시(지연 시간)가 늘어난다. 하지만 체감할 정도의 차이는 불분명하다. 실시간성이 필요하다면 로컬이 낫다.
• 회사 근무 입장에서 정보가 외부로 나가지 않는다는 것이 큰 장점이다 (외부 서비스에 데이터를 전송하는 것만으로도 불안감을 느낀다). - Bedrock에 올라오면 선택지가 늘어날 것이라는 기대감도 있다.

스택을 완성한 후, VS Code에 로그인하여 터미널에서 Python 가상 환경을 만들고, strands-decider를 설치한다.

실행 시 주요 포인트

• 왼쪽 워크숍 아래에 HANDSON.md, README.md, 그리고 4개의 Python 파일이 나열되어 있어야 한다. 나열되어 있지 않다면, 스택 생성 시 RepoUrl 설정 오류일 가능성이 높다. 이 환경에서 git clone으로 보충할 수 있을지도 모르지만, 미검증이다. 처음부터 다시 만드는 것이 빠르다. - 터미널에서 클립보드 접근을 묻는 경우 '허용'을 선택하면, 명령어를 복사하여 붙여넣기 할 수 있다.

논의된 주제

특별한 내용은 없었다.

strands-decider ask를 사용하여, 같은 메시지에 대해 choice (담당 팀 선택), noul (긴급성 Yes/No), score (짜증 정도)를 테스트하거나 3가지를 한 번에 물어볼 수도 있다.

실행 시 주요 포인트

특별한 내용은 없다 (절차서에 따름).

논의된 주제

• 영어로 시도하면 결과가 달라진다: 참가자로부터 같은 질문을 영어로 시도했을 때 수치가 변했다는 보고가 있었다. 현재 Strands Decider는 영어가 더 적합할 수도 있지만, 외부에서 제공되는 Jev 역시 일본어 성능이 매우 좋다. 사용처에 따른 구분과 AWS 측의 향후 발전에 대한 기대라는 이야기가 오갔다.

serve를 사용하여 HTTP 서버로 구동하고, 모델 로드를 한 번으로 끝낸다. curl을 사용하여 요청을 보내고 JSON 응답을 확인한다.

실행 시 주요 포인트

특별한 내용은 없다 (절차서에 따름).

논의된 주제

• 출력 토큰이 1이 되는 것은, 문장을 만들지 않고 한 번의 계산으로 답을 내놓기 때문이다. Jev에서 출력 토큰 비용이 발생하지 않는 것도, 너무 작아서 일일이 관측할 필요가 없기 때문이라는 발표자의 추측이었다.

Strands Agents의 Intervention(도구를 호출하기 직전에 처리를 삽입하는 메커니즘)에 Strands Decider를 결합한다.

Intervention의 활용처: Claude Code의 훅(hook)처럼, 도구를 사용하기 전에 위험한 명령을 차단하는 용도입니다. 여기서는 그 전 단계에 Decider를 배치하여 에이전트에게 처리를 맡길지, 아니면 사람에게 에스컬레이션할지를 분배합니다. - 이 판별을 통해 AI 에이전트의 환각(hallucination)을 방지할 수 있었다는 것이 발표자의 정리입니다.

헬프데스크 AI 에이전트가 받은 문의를 LLM을 호출하기 전에 Decider가 AI로 답변할지 사람 담당자에게 넘길지를 판별합니다. 5건의 문의를 순차적으로 처리합니다.

실행 포인트

• 작업 디렉터리는 한 단계 전 디렉터리(workshop)로 돌아가서 실행합니다.

발표된 토픽

• 활용 이미지: LLM과 인간에게 태스크를 분배하는 메커니즘은 애플리케이션 제작 방식에 따라 폭이 넓어집니다. 정보 시스템(IT) 부서 같은 곳에서 직접 구현한 것을 준비하여 제공하는 형태가 좋을 것 같습니다. - 사람에게 넘기는 케이스는 LLM에 전혀 처리가 흐르지 않기 때문에(llm_input_tokens=0) LLM 비용도 들지 않습니다.

요청의 난이도에 따라 저렴한 모델(Claude Haiku 4.5)과 똑똑한 모델(Claude Sonnet 4.6)을 사용합니다. Strands Agents의 ModelRouter에서 모델을 결정하는 부분을 직접 만들어서 Decider가 판별하게 합니다.

실행 포인트

특별히 없습니다 (절차서에 따릅니다).

발표된 토픽

• 분배의 한계와 활용처: 이번 예시는 간단한 요청과 어려운 요청이 명확하게 구분되는 이해하기 쉬운 예입니다.
  코딩 태스크 분배로 가면 더 어려울 것 같습니다. - 헬프데스크처럼 '데이터 소스를 검색하여 찾은 것을 반환'하는 것만으로는 Haiku로 충분합니다.
  절차가 관련된 경우는 Sonnet 등 다른 모델을 끼우거나, 아니면 사람에게 그대로 넘긴다는 사용 구분도 가능합니다.

• 이번 예시는 간단한 요청과 어려운 요청이 명확하게 구분되는 이해하기 쉬운 예입니다.

Strands Agents의 그래프(여러 에이전트를 연결하는 메커니즘)에서, 에이전트들 사이를 잇는 선(엣지) 조건 판별에 Decider를 사용합니다. 접수 담당 에이전트가 티켓을 정리하고, Decider가 청구/기술/영업 담당자를 선택합니다.

실행 포인트

• 그래프 이해를 돕는 도해: 에이전트 A에게 사용자 요청이 도착하여, A가 B로 넘길지 C로 넘길지를 분기합니다. 그래프는 멀티에이전트 오케스트레이션(Multi-agent Orchestration) 기능으로, 기계적으로 결정하는 부분과 에이전트가 자율적으로 처리하는 부분을 나누어 설정할 수 있습니다. 이번의 'A→B/C' 분기 판단에 Decider를 사용합니다. - 코드로 볼 포인트: build_graph 안에서, add_node로 에이전트(접수, 청구, 기술, 영업)를 등록하고, add_edge로 접수부터 각 팀까지 선을 긋고, condition으로 분기시킵니다.

발표된 토픽

• 결과만 보면 Step.4 (LLM과 인간의 분배)와 다르지 않아 보이지만, 정해진 정형적인 복잡한 워크플로우나 멀티에이전트 워크플로우에도 적용할 수 있음을 보여주는 예시라는 위치입니다.

Strands Agents의 HumanInTheLoop로, 도구 실행 전에 인간의 승인이 필요한지 여부를 Decider의 noul로 판별합니다. 파일 목록이나 읽기는 자동이고, 이메일 전송이나 파일 삭제는 사람에게 확인을 받습니다.

실행 포인트

• 실행하면 로그 출력이 뒤섞여서 이해하기 어렵습니다. 마지막에 표시되는 최종 결과를 보면, 무엇이 실행되었고 무엇이 거부되었는지(이메일은 전송되고, tmp/old.log는 남음)가 명확합니다.

발표된 토픽

• 이 용도는 반드시 Decider를 사용할 필요는 없지만, HITL(Human Confirmation) 메커니즘에 포함될 수 있는 한 예시로 소개했다는 발표자의 위치입니다. - 인간의 승인이 필요한 도구는 사람에게 에스컬레이션되므로, 에이전트의 폭주를 막을 수 있습니다.

핸즈온 후 질의응답, 정리(스택 삭제) 안내, LT, 공지.

• 질의: 같은 질문에 대해 같은 수치가 반환되는 것은 샘플링 처리가 없기 때문인가? - 확률 분포는 구하지만, 일반적인 LLM과 달리 그 분포에서 랜덤하게 값을 선택하는 처리는 하지 않는다. 대신, 질문 유형에 따라 최대 확률의 선택지나, 확률 기반 기대값으로 결과를 반환한다. 같은 모델, 같은 입력, 같은 실행 조건이라면 기본적으로 같은 수치가 나온다. - 보충 (umitsu): Decider나 Jev 같은 판단 모델은 토큰을 골라 문장을 생성하는 샘플링 처리가 없고, 판단과 그 확률 자체를 반환하는 것이 특징이다. - 후쿠치의 정리: LLM은 확률 분포를 내고, 그중에서 랜덤하게 골라 문장(텍스트)을 생성한다. Decider는 그 직전의 확률을 반환하고 있을 뿐이므로, 확률 계산은 항상 같아진다.

• 확률 분포는 구하지만, 일반적인 LLM과 달리 그 분포에서

질의: Bedrock을 호출하는 부분에서 에러가 난다: 모델 ID를 jp로 설정하는 곳까지는 확인했었다. 원인은 Anthropic 모델 이용 신청(첫 번째 유스케이스 등록)이 완료되지 않은 것이었고, 나중에 실제로 모델 신청 문제였음을 알게 되었다. 흔히 막히기 쉬운 지점이다.

• LT (umitsu): Jev as a Judge를 Strands Decider로 시도해 봄 - Jev나 Decider의 유스케이스 중 하나는 Strands Agents 등 LLM의 출력을 Judge(평가)하는 방식이 있다. LLM 앱 트레이스에 강한 Langfuse에 'Jev as a Judge'라는 제안이 있었고, 공식적으로는 OpenAI와 Jev만 지원하지만, 같은 것을 Decider로도 할 수 있을 것 같아 시도해 보았다. - 소재는 단계 4~5 부근의 날씨 예시(도시를 언급하지 않으면 내부적으로 시애틀이 인수로 들어가 버리는 경우)였다. 최종 결과를 도구 결과에 기반한 답변을 하고 있는지 등의 관점에서 Decider에게 Judge를 맡기고, 그 점수(score)를 트레이스에 붙인다. - 임계값을 정해두고, 값이 낮으면 품질에 문제가 있을 것 같으니 수정한다는 방식으로 사용할 수 있다. LLM도 로컬에서 구동하여 gpt-oss 120b를 사용했다. 자세한 내용은 추후 기사로 만들 예정이다. - 후쿠치의 감상: 평가는 어려운 영역이므로, 새로운 방법이 나왔다는 것은 흥미롭다.

• Jev나 Decider의 유스케이스 중 하나는,

공지-
AI Builders Day 2026: 12월 19일, AWS 아사부대 오피스. Strands Agents 구축이나 프론티어 에이전트 활용 등을 배울 수 있는 스터디회/컨퍼런스. CFP(Call for Papers)를 모집 중이며, 마감일은 약 2주 후이다. - AWS 라이트닝 토크 나이트: 다음 주/다다음 주에 KDDI 다카나와 오피스에서 개최. 평소에는 JAWS-UG 도쿄에서 점심시간 LT 모임을 열고 있는데, 운영 측 멤버가 보기 드물게 발표하는 회차이다. 운영 6명과 참가자 LT 4명이 발표한다. 스트리밍 없는 완전 오프라인 방식이다. connpass를 통해 신청해야 한다.

작성에는 생성 AI를 사용했습니다. 작성에 있어서는 다음을 참조했습니다.