Jev AI 워크플로 설계: Noul·Choice·Score 실전

Jev AI 워크플로는 모델에게 최종 행동을 통째로 맡기기보다, 작은 구조화 질문의 확률을 코드 규칙으로 조합할 때 가장 이해하고 검증하기 쉽습니다.

검증일: 2026년 9월 21일. TypeSafe AI가 공개한 고객 지원·청구서 처리·에이전트 관찰 워크플로를 비교하고, 배송 분실 문의를 처리하는 독립 로컬 harness에서 질문·임계값·코드 분기 흐름을 실행했습니다. 실제 고객 정보와 Jev API 키는 사용하지 않았습니다.

Table of Contents

Jev 워크플로의 기본 구조: 질문과 규칙을 나눈다

TypeSafe Workflow Evals가 보여 주는 공통점은 정책 문장을 두 종류로 나눈다는 것입니다. 의미 판단이 필요한 문장은 Noul·Choice·Score 질문이 되고, 합계·날짜·상태 비교·행동 순서는 일반 코드 규칙이 됩니다. 모델은 모호한 부분을 읽고, 코드는 확정 가능한 부분과 허용된 행동을 통제합니다.

예를 들어 “영수증을 읽을 수 없으면 새 영수증을 요청한다”는 정책에서 영수증 가독성은 Noul 질문이 될 수 있습니다. 반면 식비가 75달러를 넘는지는 산술 비교이므로 코드가 처리해야 합니다. 모델이 금액을 다시 읽고 계산하게 만들면 같은 값을 여러 번 해석하고 오류 가능성도 늘어납니다.

이 구분은 비용 절감만을 위한 것이 아닙니다. 정책이 바뀌었을 때 수정 지점을 명확하게 만들고, 실패한 결정을 질문 단위로 추적할 수 있게 합니다. “환불 여부가 잘못됐다”는 한 줄보다 의도 분류가 틀렸는지, 사기 위험 질문이 틀렸는지, 코드 우선순위가 잘못됐는지를 따로 확인하는 편이 운영에 유리합니다.

1단계: 입력 상태를 필요한 질문별로 최소화한다

공개 고객 지원 워크플로는 대화 기록, 고객 계정, 최근 결제와 환불, 카드 상태, 마지막 제안처럼 여러 상태를 입력으로 사용합니다. 그러나 모든 질문에 전체 상태를 반복해서 보여 주지는 않습니다. 의도와 감정은 대화를 중심으로 읽고, 환불 가능성은 결제 기록을 추가하며, 카드 동작은 카드 상태와 동의 여부를 함께 확인하는 식으로 범위를 나눕니다.

입력 최소화는 개인정보와 비용 모두에 중요합니다. 배송 의도를 분류하는 데 결제 카드 전체 기록이 필요하지 않다면 보내지 않는 편이 낫습니다. 질문별로 필요한 필드를 목록화하고, 누락됐을 때 임의 추정하지 않도록 “정보 부족” 선택지나 사람 검토 경로를 둡니다.

상태를 만들 때는 원본과 계산값도 구분합니다. 주문 금액, 날짜 차이, 이미 지급한 환불처럼 코드로 계산할 수 있는 값은 먼저 계산해 명시적인 필드로 전달합니다. 자유 형식 대화와 확정된 데이터가 충돌하면 어느 쪽을 우선할지 정책에 기록해야 합니다.

2단계: Noul·Choice·Score를 서로 독립적으로 설계한다

Noul은 “그런가, 아닌가”를 확률로 묻습니다. 사람이 요청됐는지, 문서가 읽을 수 있는지, 보안 위험이 있는지처럼 두 상태로 나눌 수 있을 때 적합합니다. 질문 문장에는 판단 기준을 넣되 최종 행동을 암시하지 않는 편이 좋습니다. “환불해야 하는가”보다 “고객이 중복 결제를 주장하는가”, “원장에 중복 승인 기록이 있는가”로 분해하면 정책과 관찰을 섞지 않을 수 있습니다.

Choice는 의도, 담당 팀, 문서 종류처럼 유한한 범주를 고릅니다. 실제 운영에서는 “기타”와 “판단 불가”를 넣을지 결정해야 합니다. 모든 입력을 억지로 기존 범주에 넣으면 새로운 유형이 나타났을 때 고신뢰 오분류가 생길 수 있습니다. 범주 이름은 서로 겹치지 않게 정의하고, 클래스별 예시와 반례를 정답 세트에 포함합니다.

Score는 긴급도, 위험도, 만족도처럼 연속적인 판단에 맞습니다. 점수 수준별 설명이 모호하면 팀마다 3과 4의 의미를 다르게 이해할 수 있습니다. 각 수준에 관찰 가능한 기준을 붙이고, 점수 자체보다 어느 구간에서 어떤 검토를 시작할지 코드로 정합니다.

3단계: 행동 우선순위를 코드로 고정한다

여러 질문이 동시에 참이면 행동 충돌이 생깁니다. 환불 의도가 높아도 사기 위험이 높으면 자동 환불을 중단해야 하고, 고객이 사람을 명시적으로 요청했다면 일반 안내보다 인계가 먼저일 수 있습니다. 이 우선순위는 모델이 매번 문맥으로 정하게 하기보다 코드의 순서로 고정해야 합니다.

TypeSafe의 고객 지원 예시는 안전, 이전 답변의 사실성, 대기 중 제안, 사람 인계, 종료, 개별 문제 순서로 규칙을 적용합니다. 각 구간에서 조건이 맞으면 허용된 행동을 내고 다음 구간으로 넘어갑니다. 이 구조는 “무엇을 판단했는가”와 “그 판단으로 무엇을 할 수 있는가”를 분리합니다.

공개 청구서 처리 워크플로도 비슷합니다. 합계, 날짜, 계정 번호와 상태는 코드가 계산하고, 사기 패턴·문서 종류·계약과의 의미 일치 여부는 질문으로 읽습니다. 사기, 이미 지급됨, 잘못된 업체, 청구서 아님과 같은 중단 조건을 먼저 검사한 뒤 보류·분쟁·수정·지급 규칙을 적용합니다.

직접 실행 결과: 배송 문의 라우팅

테스트 날짜: 2026년 9월 21일. 환경: Windows 로컬 Chromium, 1200×675 정적 페이지. 입력: 배송 완료로 표시됐지만 상품을 받지 못했고 조사 번호가 없는 가상 문의. 조건: 종료 여부, 다음 담당, 사람 검토 우선순위의 세 타입 질문. 기대 결과: 종료하지 않고 배송 조사를 만들며, 확률 0.90 미만에서는 확정 보상 문구를 쓰지 않는 것입니다.

배송 완료지만 미수령인 가상 지원 티켓과 세 개의 구조화 질문이 대기로 표시된 Jev 워크플로 로컬 화면 — 실행 전 화면에는 고객 상태와 세 질문만 있으며 담당 팀과 최종 안내는 아직 선택되지 않았습니다.

버튼을 누른 뒤 Noul은 즉시 종료에 “아니요 0.96”, Choice는 다음 담당에 “배송 조사 0.89”, Score는 사람 검토 우선순위에 “중상 0.74”를 표시했습니다. 마지막 코드 규칙은 종료 조건을 거짓으로 처리하고 배송 조사 티켓을 먼저 만들도록 했습니다. 담당 확률이 0.90보다 낮기 때문에 고객에게 보상을 확정하지 않고 조사 예정만 안내하도록 제한했습니다.

종료하지 않음 배송 조사 담당 0.89 사람 검토 중상 0.74와 최종 코드 규칙이 표시된 로컬 워크플로 완료 화면 — 완료 화면은 모델형 판단 세 개와 그 결과를 사용하는 코드 우선순위를 한 화면에서 분리해 보여 줍니다.

실행 대기부터 세 질문 완료와 배송 조사 규칙 적용까지 기록한 3초대 실제 Chromium 영상입니다.

이 로컬 결과는 Jev API의 실제 분류값이 아니라 워크플로 설계를 검토하기 위한 고정 예시입니다. 확인한 것은 입력 최소화, 타입별 질문, 확률 임계값과 코드 우선순위가 화면에서 분리돼 동작하는지 여부입니다. 실제 모델을 연결할 때는 동일한 입출력 계약을 유지한 채 응답 어댑터와 관찰 로그를 추가할 수 있습니다.

평가 세트와 임계값을 만드는 방법

첫 평가 세트는 정상 사례만 모으면 안 됩니다. 서로 모순되는 대화와 계정 기록, 정보가 부족한 문의, 새 범주, 한국어 표현 변형, 오타, 강한 불만, 사람 요청, 금전 피해가 큰 사례를 포함해야 합니다. 각 사례에는 최종 행동뿐 아니라 질문별 기대 분포 또는 최소한 허용되는 선택을 기록합니다.

임계값은 전체 정확도가 아니라 행동 비용으로 정합니다. 잘못 종료하는 비용이 잘못 인계하는 비용보다 크다면 종료 질문의 자동 처리 기준을 더 높여야 합니다. 0.90 이상 자동 처리, 0.60~0.90 사람 검토, 0.60 미만 정보 추가 요청처럼 구간을 나눌 수 있지만 숫자는 예시일 뿐입니다. 실제 분포와 검토 인력에 맞춰 조정해야 합니다.

모델이나 질문 문장을 바꿀 때는 같은 평가 세트를 다시 실행합니다. 평균 정확도만 비교하지 말고 범주별 재현율, 사람 검토율, 고신뢰 오답, 처리 시간과 비용을 함께 기록합니다. 프롬프트 회귀 테스트 글의 수정 전후 비교 원칙을 구조화 질문에도 적용할 수 있습니다.

운영 로그와 실패 복구

각 실행에는 입력 버전, 질문 스키마 버전, 모델 버전, 결과 분포, 임계값, 최종 코드 분기와 사람 수정 여부를 남깁니다. 개인정보 원문을 무기한 저장하지 말고 감사에 필요한 필드와 보존 기간을 정합니다. 확률만 저장하면 나중에 어떤 상태를 보고 판단했는지 알 수 없고, 원문만 저장하면 정책 버전 차이를 재현하기 어렵습니다.

일시적 네트워크 오류와 인증 오류도 구분합니다. 시간 초과와 5xx는 제한적으로 재시도할 수 있지만 잘못된 스키마, 권한 부족, 존재하지 않는 모델은 같은 요청을 반복해도 해결되지 않습니다. 재시도 뒤에도 결과가 없으면 기본 행동을 안전한 쪽으로 정합니다. 결제와 삭제는 중단하고 사람에게 보내며, 단순 분류는 일반 대기열로 보내는 식입니다.

워크플로 전체 성공도 마지막 외부 상태로 확인해야 합니다. “배송 조사 생성” 행동을 선택했어도 실제 티켓 API가 실패하면 고객에게 생성 완료라고 말하면 안 됩니다. 실행 결과를 다시 읽고 성공했을 때만 다음 안내를 만들도록 합니다. RSS 큐레이션 자동화의 사람 검토 원칙처럼 수집·판단·실행·확인을 분리하면 복구가 쉬워집니다.

한계와 위험한 설계 패턴

가장 위험한 패턴은 한 질문에 정책 전체를 넣고 바로 외부 행동을 실행하는 것입니다. 질문이 복잡해질수록 오류 원인을 나누기 어렵고, 정책 한 줄을 바꿨는데 다른 판단까지 흔들릴 수 있습니다. 두 번째는 낮은 확률을 무시하고 항상 최대 확률 선택을 실행하는 것입니다. 후보 중 0.36이 가장 높아도 충분히 확실한 결정은 아닐 수 있습니다.

세 번째는 모델에게 확정 계산을 맡기는 것입니다. 금액 합계, 날짜 범위, 재고 수, 권한 표처럼 코드와 데이터베이스가 정확히 처리할 수 있는 값을 다시 추정하게 할 이유가 없습니다. 네 번째는 자체 평가 없이 제품사의 예제 워크플로만 신뢰하는 것입니다. 공개 예제는 구조를 배우는 자료이지 우리 데이터의 성능 보장이 아닙니다.

다섯 번째는 사람 검토를 실패 경로로만 취급하는 것입니다. 초기에는 사람 판단이 정답 세트와 새 범주를 만드는 학습 자료가 됩니다. 어떤 확률 구간과 입력 유형에서 수정이 많이 발생했는지 기록하면 질문을 합치거나 나누고 임계값을 바꿀 근거가 생깁니다. 사람 검토량이 예상보다 많으면 자동화 성공으로 포장하지 말고 운영 비용에 포함해야 합니다.

실무 적용 체크리스트

정책 문장을 의미 판단과 확정 계산으로 나눴는가?
질문마다 필요한 상태 필드만 전달하는가?
Noul·Choice·Score의 선택지와 수준 설명이 겹치지 않는가?
정보 부족·새 범주·모순 입력의 안전한 경로가 있는가?
안전·권한·금전·종료의 우선순위를 코드로 고정했는가?
확률 구간별 자동 처리와 사람 검토 기준이 있는가?
외부 행동 뒤 실제 성공 상태를 다시 확인하는가?
모델·스키마·임계값 버전과 사람 수정 결과를 기록하는가?

Jev를 도입한다면 첫 목표는 “에이전트가 모든 정책을 알아서 처리하게 만들기”가 아니라, 한 가지 반복 판단을 질문 세 개 안팎으로 분해하고 코드 우선순위와 함께 재현 가능하게 만드는 것입니다. 구조가 안정된 뒤에만 더 많은 질문과 행동을 추가해야 실패 위치와 사람 검토 비용을 통제할 수 있습니다.

공식 출처

dea:no의 직접 검증과 콘텐츠 운영 범위는 사이트 소개 페이지에 정리돼 있습니다.