에이전트를 보면 글을 쓰는 순간보다 고르는 순간이 더 많습니다. 다음 도구를 뭘 쓸지, 결과가 됐는지, 다시 할지, 사람에게 넘길지. 이런 작은 판단이 수십 번 이어지면 속도와 비용이 거기서 갈립니다.

이 글은 그 판단을 떼어내는 가장 실용적인 자리 세 곳과, 장애 대응을 예제로 한 분기 설계를 정리합니다. 개요 글에서 본 구조를 실전에 붙이는 순서입니다.

장애 보고서를 ACCEPT, RETRY, HUMAN_REVIEW로 나누는 분기 개념도

왜 떼어내나: 작은 판단마다 큰 LLM을 부르면 쌓인다

주문 오류 접수를 예로 들어봅니다. 결제 오류인지 계정 문제인지 가르는 단계에 긴 추론과 문장 생성이 꼭 필요할까요. 꼭 필요하지 않은데도 거대한 생성 모델을 매번 부르면 처리량이 늘수록 지연과 비용이 함께 쌓입니다.

전: 매 판단마다 대형 LLM 호출 (느림 + 비쌈)
후: 생성(Generator) + 판단(Decider) + 검증(Verifier) 역할 분담

라우팅 글의 분류 단계가 바로 Decider 자리입니다. Strands Decider 글에서도 본 것처럼, 선택은 빠르고 싸고 확신도를 주는 모델에게 맡기는 게 자연스럽습니다.

그렇다고 LLM을 없애는 건 아닙니다. 복잡한 문장과 추론은 LLM이 맡고, 반복되는 구조화 판단은 Decision AI가 맡는 겁니다. 나누는 게 핵심입니다.

실용적인 자리 3가지

Microsoft 발표와 현장 쓰임을 겹치면 세 자리가 남습니다.

1) 라우팅: 요청을 보고 모델과 팀을 고른다

질문 종류에 따라 저렴한 모델과 강한 모델을 고릅니다. 고객 문의를 billing, technical, account 중 하나로 보내는 것도 라우팅입니다.

입력: "결제 재시도 3회 실패, 로그 ID …"
판단: 어느 팀· 어느 모델· 어느 워크플로로?
출력: technical 0.78 + confidence
→ 확신 높으면 자동 라우팅, 낮으면 강한 모델에 재확인

Sonnet high 글의 승격 패턴과 똑같습니다. 작은 모델이 1차, 큰 모델이 2차. 확신도가 낮을 때만 비싼 모델에 묻는 구조입니다.

2) 품질 게이트: LLM 답변을 기준에 비춰 합격· 반려한다

LLM이 만든 답을 정의된 기준으로 검사합니다. Copilot 팀이 답장 품질을 재는 데 Decision-1을 쓴 사례가 여기입니다.

LLM 초안 → Decision AI가 루브릭으로 채점
  → ACCEPT (그대로 전달)
  → REVISE (다시 쓰기)
  → HUMAN_REVIEW (사람 확인)

글을 쓰는 모델에게 검사까지 맡기면 느리고 비쌉니다. 쓰는 일과 고르는 일을 나누면 게이트를 매 요청에 둘 수 있습니다.

3) 분류: 반복 문의를 일정한 기준으로 정리한다

고객 문의와 장애 티켓을 일정한 기준으로 나눕니다. Xbox가 1만 건 넘는 피드백을 정해진 주제에 묶은 사례가 대표적입니다.

매일 쌓이는 티켓:
  - 결제· 기술· 계정 중 하나로
  - 긴급도 low· medium· high로
  - 자동 처리 가능 여부 yes/no로
→ 한 요청에 세 질문을 묶어 병렬 평가

네 작업 다 텍스트 생성이 필수가 아닙니다. 선택과 점수, 예· 아니오면 충분합니다.

실전 예제: 장애 대응을 ACCEPT· RETRY· HUMAN_REVIEW로 나누기

이제 장애 보고서를 예제로 분기를 만들어봅니다. 결과는 세 가지입니다.

ACCEPT: 다음 단계로 (확신 높고 위험 없음)
RETRY: 정보 보강· 재시도 (일시 오류· 부족)
HUMAN_REVIEW: 사람 검토 (낮은 확신· 고위험은 무조건)

아래 코드는 외부 호출 없는 로컬 시뮬레이션입니다. 확률 숫자는 설명용 예시이며 실제 모델 응답이 아닙니다. 보여주고 싶은 건 모델이 아니라 게이트입니다. 확률이 높아도 위험 조건은 코드가 막는다는 것.

OPTIONS = ("ACCEPT", "RETRY", "HUMAN_REVIEW")

def select_action(probabilities, risk_flags, threshold=0.85):
    if set(probabilities) != set(OPTIONS):
        raise ValueError("option schema mismatch")
    # 위험 조건은 점수와 무관하게 사람에게
    if risk_flags & {"payment", "delete", "permission_change", "personal_data_export"}:
        return "HUMAN_REVIEW"
    selected = max(probabilities, key=probabilities.get)
    if probabilities[selected] < threshold:
        return "HUMAN_REVIEW"
    return selected

# 설명용 예시 (실제 모델 출력 아님)
print(select_action({"ACCEPT": 0.94, "RETRY": 0.03, "HUMAN_REVIEW": 0.03}, set()))  # ACCEPT
print(select_action({"ACCEPT": 0.52, "RETRY": 0.31, "HUMAN_REVIEW": 0.17}, set()))  # HUMAN_REVIEW
print(select_action({"ACCEPT": 0.99, "RETRY": 0.005, "HUMAN_REVIEW": 0.005}, {"payment"}))  # HUMAN_REVIEW

마지막 줄이 핵심입니다. 99%여도 결제가 걸리면 사람에게 갑니다. 모델의 확신과 실행 허가는 다른 층입니다. 이 원칙은 체크리스트 글에서 다시 다룹니다.

진짜 모델을 붙일 땐 세 가지를 확인

시뮬레이션 다음이 진짜 호출입니다. Microsoft Foundry 기준으로 세 가지를 확인하세요.

① 배포: Foundry 구독에 Decision-1 배포, 모델· 배포 식별자 확인
② 인증· 경로: providers/microsoft/v1/systemone 경로와 Entra 인증 헤더 확인
③ 검증: 돌아온 answers의 타입· 선택지 포함 여부 검사 (파싱 실패 처리 포함)

공식 TechCommunity 글의 Python 예제는 이 흐름 그대로입니다. state와 questions를 보내고 answers에서 choice를 읽어 정확도와 지연을 잽니다. 자격 증명은 코드 밖에 두고, 지역과 계정에 따라 값을 확인해야 합니다. 실습 코드에는 로컬 시뮬레이션과 실제 API 예제를 구분해 담아두는 게 좋습니다. 시뮬레이션 결과를 실제 호출 결과처럼 소개하면 안 됩니다.

측정할 때는 3개 예제가 아니라 여러분의 라벨 데이터로 돌리세요. 100개쯤이면 시작됩니다. 같은 입력으로 기존 방법과 Decision AI를 돌리고, 선택 일치율과 지연, 비용을 함께 봅니다. 확신도가 낮은 구간의 처리(임계값 아래면 상위로 올리기)까지 정해야 분기가 완성됩니다.

CodeBridge Mini Lab: 이번 주에 끝내는 분기 하나

① 고르기 1개 정하기: 라우팅· 게이트· 분류 중 가장 자주 불리는 것
② 2주간 로그: 호출 수· 토큰· 지연· 비용 (기존 LLM 기준)
③ Decision AI로 같은 일 돌리기:
   [ ] 선택 일치율 (95% 이상 목표)
   [ ] 지연· 비용 차이
   [ ] 확신도 낮은 경우의 상위 확인 경로
④ 판정: 일치하면 분리, 위험 조건은 코드로 강제
   (결제· 삭제· 권한· 개인정보는 무조건 HUMAN_REVIEW)

로컬 decisions 글의 Mini Lab과 같은 틀입니다. 모델만 바뀌고 호출처가 /v1/systemone 계열이 됩니다.

결론: 묻는 법을 나누세요

한 줄로 정리합니다.

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

에이전트의 선택 지점 하나를 찾아 로그를 켜는 것. 그 숫자가 다음 아키텍처를 정해줍니다. 답을 더 잘 쓰는 게 아니라, 고르는 일을 어디에 둘지가 먼저입니다.

안전하게 나누는 기준과 도입 전 측정은 체크리스트 글에서 이어집니다.

함께 읽으면 좋은 글

참고 자료

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

분기 설계까지 알았으면 다음은 내 업무에 붙이는 일만 남습니다. 어디까지를 코드 규칙으로 두고, 어디를 모델 판단에 맡기고, 어디서 사람 검토를 넣을지 정하는 부분이 실무에서 가장 막막합니다.

실무 Decision AI 과정에서는 Laya를 직접 실행하면서 상태와 질문을 만들고, 확신도를 정책과 Human Review로 연결하는 법과 내 업무에 적용하기 전 검증 틀을 함께 잡습니다. 반복되는 판단 하나를 자동화하고 싶은 분이라면, 이 글의 Mini Lab 다음 순서로 이어서 보셔도 좋습니다.