제브 입출력 구조 — Choice·Score·Noul 세 유형을 코드에 연결하는 법

TL;DR — 제브 입출력 구조는 상태 하나와 이름 붙은 질문 여러 개를 넣으면 질문마다 형식이 정해진 값과 확률이 돌아오는 방식이고, 질문 유형은 Choice·Score·Noul 세 가지입니다. 확신도와 확률을 코드의 분기에 직접 연결하면 사람이 모든 건을 보던 루프가 예외 건만 보는 루프로 줄어듭니다.

판단 전용 모델을 프로덕션 운영 환경에 도입하려는 담당자는 입력을 어떻게 넣고 출력을 어떤 방식으로 코드에 연결하는지가 가장 먼저 궁금합니다. 이 글은 클라우드네이티브TV가 공개한 영상 ‘판단형 AI 제브, 입출력부터 Choice·Score·Noul까지'(약 20분)를 장면별로 풀어, 영상을 보지 않은 독자도 제브 입출력 구조와 세 질문 유형을 왜 그렇게 설계했는지, 값을 어떻게 읽어야 하는지 알 수 있도록 정리했습니다. 영상은 제브 입출력 구조를 중심으로, 생성이 아니라 판단에 특화된 System One 계열 모델이 확률을 돌려주는 방식을 코드와 일대일로 맞춰 보여 줍니다.

아래 영상은 제브 입출력 구조, 곧 제브가 상태와 질문을 받아 확률을 돌려주는 과정, 세 질문 유형이 코드의 분기와 맞물리는 방식, 숫자를 읽을 때 조심할 점을 20분 동안 차례로 보여 줍니다.

영상에서 다루는 순서는 다음과 같습니다.

• 확률이 붙은 응답이 자동 처리와 사람 검토를 가르는 방식
• 상태와 질문을 넣고 형식 있는 값을 받는 입출력
• Choice·Score·Noul 세 질문 유형과 확신도
• 유형별 코드 흐름과 실제 응답 예
• 모델 고르기, 변경 범위 채점, 인용 검증 사례
• 같은 0.5라도 유형에 따라 뜻이 달라지는 점
• 한 번의 호출로 여러 질문에 답하는 구조와 설계 원칙, 속도와 비용

1. 제브 입출력 구조에서 응답에 확률이 붙으면 운영 방식이 어떻게 바뀌는가?
2. 제브 입출력 구조의 입력과 출력은 무엇인가?
3. 세 질문 유형은 왜 돌려주는 값의 모양이 다른가?
4. 세 유형은 코드의 분기와 어떻게 대응하는가?
5. Choice는 모델 고르기에 어떻게 쓰이는가?
6. Score는 변경 범위를 어떻게 채점하는가?
7. Noul은 RAG 답변의 인용을 어떻게 검증하는가?
8. 같은 0.5를 왜 유형별로 다르게 읽어야 하는가?
9. 여러 질문이 어떻게 한 번의 호출로 끝나는가?
10. 질문 설계 원칙과 속도·비용은 어떤 기준으로 보는가?

영상은 같은 고객 문의를 두고 두 가지 응답을 견줍니다. LLM에게 물으면 사정을 설명하는 긴 글이 돌아오고, 그 글만 봐서는 모델이 얼마나 확신하는지 알 수 없습니다. 제브에게 같은 문의를 물었을 때는 결제팀 100%라는 한 줄이 돌아왔습니다. 정답 후보와 그 확률이 함께 오기 때문에 코드가 숫자를 읽고 다음 단계를 정할 수 있습니다.

▲ 확신도에 따라 자동 처리와 사람 검토로 갈린다 (영상 1:55)

분기 방식은 단순합니다. 신뢰도가 높으면 바로 처리하고, 낮으면 사람에게 넘기거나 더 큰 LLM에 다시 묻습니다. 영상은 병원 접수 창구에 빗댑니다. 가벼운 증상은 바로 진료실로 보내고 애매한 환자만 의사가 다시 봅니다. 어디까지를 가볍다고 볼지, 곧 기준선은 업무 위험도에 맞춰 우리가 정합니다.

제브 입출력 구조가 운영에서 주는 이득은 사람의 역할이 바뀐다는 점입니다. 모든 문의를 사람이 읽고 배정하던 루프가 예외 건만 보는 루프로 줄어듭니다. 다만 영상이 뒤에서 덧붙이는 조심할 점이 있습니다. 확신도가 낮은 고객 문의를 더 큰 모델로 넘겨 본 실험에서는 정확도가 오히려 0.7퍼센트포인트 떨어졌습니다. 그래서 확신도는 더 큰 모델에 다시 묻는 신호보다 사람에게 넘길 시점을 정하는 신호로 쓰는 편이 근거가 있다고 영상은 말합니다.

제브 입출력 구조를 이해하려면 먼저 모델의 위치부터 봐야 합니다. 제브는 TypeSafe AI가 9월 15일 얼리 액세스로 공개한 모델이고, 모델 계열의 이름은 System One입니다. 카너먼의 『생각에 관한 생각』에서 말하는 빠른 사고에서 이름을 가져왔고, 제브라는 이름은 경제학자 제번스에서 따왔다고 영상은 소개합니다. 입력은 글로 받으며 요청 한 번에 최대 6만 4천 토큰까지 가능합니다. 한국어도 되지만 공식 문서상 영어보다 정확도가 낮다는 단서가 붙습니다.

▲ 상태와 질문이 들어가고 형식 있는 값이 나온다 (영상 2:47)

제브 입출력 구조에서 입력은 두 가지입니다. 지금 상황을 담은 상태(state), 그리고 그 상태를 두고 던지는 여러 개의 질문입니다. 출력은 질문마다 형식이 정해진 결과와 확률입니다. 영상은 신호등에 빗댑니다. 긴 안내문을 읽지 않아도 색 하나만 보면 바로 움직일 수 있다는 뜻입니다. 그래서 출력을 따로 해석하지 않고 코드의 조건문에 곧바로 씁니다.

대신 치러야 할 조건이 하나 있습니다. 선택지는 사람이 미리 정해 두어야 합니다. 화면의 예시처럼 선택지 세 개의 확률을 모두 더하면 1이 됩니다. 후보 밖의 답은 나오지 않으므로, 이 제브 입출력 구조에서는 후보를 어떻게 적느냐가 곧 설계의 품질입니다.

질문 유형은 세 가지이고 유형마다 돌려주는 값의 모양이 다릅니다. Choice는 정해 둔 선택지 전체의 확률 분포를 돌려줍니다. 담당자나 모델을 고르는 데 씁니다. Score는 말로 적어 둔 채점 기준 위의 점수를 줍니다. 긴급도나 위험도를 잴 때 씁니다. Noul은 어떤 명제가 참일 확률 하나만 돌려주며, 실행을 허가할지 정하는 관문에 씁니다.

▲ 질문 유형마다 돌아오는 값의 모양이 다르다 (영상 4:21)

제브 입출력 구조 안에서 영상의 비유로 정리하면 Choice는 객관식, Score는 별점, Noul은 OX 퀴즈입니다. 값의 모양이 다른 이유는 묻는 내용이 다르기 때문입니다. 어느 것이냐를 묻는 질문에는 후보별 분포가, 어느 단계냐를 묻는 질문에는 순서 있는 단계 위의 점수가, 그렇다고 말할 수 있느냐를 묻는 질문에는 확률 하나가 맞습니다.

여기서 눈여겨볼 차이가 확신도입니다. 확신도는 분포가 답 하나에 몰리면 높고 퍼지면 낮아지는 값입니다. 영상은 선거에 빗댑니다. 같은 1등이라도 압승과 박빙은 다릅니다. 이 값은 Choice와 Score에만 붙고 Noul에는 없습니다. 응답 예의 긴급 여부 답에만 확신도 칸이 없는 것이 그 때문입니다. 성적표로 치면 국어와 수학에는 의견란이 있고 체육에는 점수만 있는 셈이라, 질문 유형마다 기준을 따로 정해야 한다는 결론으로 이어집니다.

영상은 제브 입출력 구조의 세 유형을 코드의 눈으로 다시 봅니다. Choice는 어느 것이냐를 묻고, 코드에서는 후보마다 다른 길로 갈라지는 switch 분기에 해당합니다. 요청에 맞는 AI 모델을 고르는 일이 대표 예입니다. Score는 어느 단계냐를 묻고, 받은 점수를 기준값과 비교해 길을 나누는 임계값 비교가 됩니다. 풀 리퀘스트에 리뷰가 얼마나 필요한지 채점할 때 씁니다. Noul은 그렇다고 말할 수 있느냐를 묻고, 예 확률 하나가 문턱을 넘으면 조건문이 참이 되는 if 문에 대응합니다. 사내 RAG 답변에 인용 근거가 있는지 확인할 때 씁니다.

▲ 세 유형은 코드의 분기 구조와 1:1로 대응한다 (영상 5:32)

영상의 고속도로 비유가 이 대응을 잘 보여 줍니다. Choice는 갈림길의 분기점, Score는 과속 단속 기준, Noul은 차단기입니다. 모델의 출력이 곧 코드 구조의 입력이 되므로, 별도의 파싱 층이나 해석 규칙 없이도 제브 입출력 구조를 기존 분기 코드에 바로 꽂을 수 있습니다.

주의할 점도 같은 장면에서 나옵니다. Noul의 0.5는 중간 정도라는 뜻이 아니라 예와 아니오가 반반이라는 뜻입니다. 공식 지침도 질문 하나에는 한 가지 판단만 담으라고 권합니다. 응답 예를 놓고 세 유형을 비교하면, Choice에는 고른 선택지 하나와 선택지별 확률과 확신도가, Score에는 소수점 점수와 단계별 확률과 확신도가, Noul에는 참일 확률 하나만 옵니다.

첫 번째 사례는 Choice를 모델 고르기에 쓰는 장면입니다. 오타를 고쳐 달라는 요청이 들어왔다고 합시다. 가벼운 모델과 고성능 모델 가운데 어느 쪽이 맞는지 Choice로 묻습니다. 돌아온 값은 가벼운 모델, 확률 0.95입니다. 영상은 이 수치가 설명용으로 만든 값이고 실제로 잰 값은 아니라고 분명히 밝힙니다.

▲ Choice로 요청에 맞는 모델을 고른다 (영상 8:22)

택배 분류와 같습니다. 작은 상자는 오토바이로, 큰 짐은 화물차로 보냅니다. 고른 값은 미리 적어 둔 후보 안에서만 나오므로 길을 나누는 코드에 예외 처리가 필요 없습니다. 후보가 모든 입력을 덮지 못하면 기타 후보를 따로 마련합니다. 그래야 맞지 않는 후보에 억지로 분류하는 일을 막을 수 있습니다.

제브 입출력 구조에서 Choice 사례가 주는 실무 지침은 두 가지입니다. 첫째, 선택지 설명은 구체적으로 써야 확률이 의미를 갖습니다. 둘째, 라우팅 결과를 확신도와 함께 읽되, 확신도가 낮을 때의 대응을 더 큰 모델이 아니라 사람 검토로 설계하는 편이 안전합니다. 앞서 본 실험에서 낮은 확신도 건을 큰 모델로 넘기자 정확도가 떨어졌다는 사실이 근거입니다.

두 번째 사례는 풀 리퀘스트의 영향 범위를 Score로 채점하는 장면입니다. 영향 범위를 세 단계로 정해 둡니다. 문구만 바꾼 경우, 기능 하나를 바꾼 경우, 여러 기능을 바꾼 경우입니다. 이렇게 물으면 단계별 확률과 점수가 돌아옵니다. 화면의 점수 1.6은 단계 번호에 확률을 곱해 더한 가중 평균입니다. 0×0.1, 1×0.2, 2×0.7을 더한 값이고, 공식 문서도 같은 계산을 밝히고 있습니다. 이 예시 수치 역시 실제로 잰 값은 아닙니다.

▲ Score로 변경 범위의 위험도를 채점한다 (영상 9:19)

제브 입출력 구조에서 Score를 쓸 때 함정이 있습니다. 서로 다른 분포가 같은 점수를 만들 수 있습니다. 평균이 똑같이 70점인 학급 두 곳을 떠올려 보십시오. 모두 70점인 반과 100점과 40점으로 갈린 반은 전혀 다릅니다. 두 단계 사이에서 확률이 갈린 건을 놓치면 안 되기 때문에, 영상은 점수와 확신도를 함께 보고 리뷰어를 배정하라고 권합니다.

세 번째 사례는 사내 RAG 답변을 Noul로 검증하는 장면입니다. 사내 절차서에는 운영 환경 배포는 운용 담당자만 할 수 있다고 적혀 있습니다. 그런데 RAG 답변은 전원이 배포할 수 있다고 말하면서 그 절차서를 인용합니다. 인용이 붙어 있어도 내용은 틀린 경우입니다. 답변과 인용 원문을 함께 넘기고 주장이 원문으로 뒷받침되는지 Noul로 물으면, 돌아온 값은 0.08, 강한 아니오입니다. 이 값도 설명용입니다.

▲ Noul로 인용과 주장의 일치를 검증한다 (영상 11:16)

제브 입출력 구조에서 Noul의 역할은 신문사의 교열 기자와 같습니다. 기사가 나가기 전에 인용이 원문과 맞는지 한 번 대조하는 사람입니다. 화면에 보여 주기 직전에 이 확인을 한 번 거치면 틀린 절차가 사용자에게 보이기 전에 답변을 다시 만들게 할 수 있습니다.

Noul 질문은 의문문보다 평서문으로 쓰는 편이 좋다는 조언도 이어집니다. 우려가 있느냐고 묻기보다 우려가 분명히 적혀 있다고 쓰는 식입니다. 참과 거짓을 가릴 수 있어야 해석이 분명해지고, 확률 하나에 직접 조건을 걸 때 기준값의 뜻이 흔들리지 않습니다. Noul에는 확신도가 없으므로 길을 나눌 때는 확률값에 직접 조건을 겁니다.

같은 0.5라는 숫자도 유형에 따라 뜻이 다릅니다. Score의 0.5는 보통과 이르게 사이, 곧 정도의 크기입니다. 시연에 나온 1.66은 이르게와 최우선 사이입니다. 반면 Noul의 0.5는 참인지 거짓인지 반반이라는 뜻이고, 판단이 서지 않았다는 말입니다.

▲ 같은 0.5도 유형에 따라 뜻이 다르다 (영상 12:07)

제브 입출력 구조의 숫자를 읽는 법을 영상은 온도계와 동전 던지기로 설명합니다. 온도계의 중간 눈금은 미지근하다는 뜻이지만, 동전의 반반은 모른다는 뜻입니다. 이 값을 등급처럼 읽으면 기준값 설계가 통째로 어긋납니다. 그래서 임계값을 정할 때는 유형별로 따로 정해야 하고, Noul의 0.5 근처는 자동 처리가 아니라 사람 검토로 보내는 구간으로 잡는 편이 자연스럽습니다.

이 대목은 제브 입출력 구조를 코드에 연결할 때 가장 흔한 실수를 짚습니다. 모든 유형의 숫자를 0에서 1 사이 확률로 보고 하나의 기준값을 공용으로 쓰면, 어떤 유형에서는 보류 구간을 자동 통과시키고 다른 유형에서는 정상 응답을 걸러 냅니다. 영상이 이 장면을 따로 떼어 설명하는 까닭입니다.

이제 제브 입출력 구조가 질문 여러 개에 어떻게 한 번에 답하는지 보겠습니다. LLM은 토큰을 하나 낼 때마다 모델 전체를 다시 돌립니다. 그래서 답이 길수록 지연이 쌓입니다. 제브는 상태와 여러 질문에 이름을 붙여 요청 하나에 담고, 한 번에 모든 답을 받습니다. 영상은 LLM이 손으로 한 글자씩 쓰는 답안이라면 제브는 한 번에 찍는 도장이라고 비유합니다.

▲ 한 번의 호출로 여러 질문에 동시에 답한다 (영상 13:34)

실제 호출 예에서는 문의 본문을 그대로 넣고 질문 세 개를 한꺼번에 붙입니다. 담당은 어디인지, 화가 났는지, 긴급한지입니다. 제브는 한 번 읽고 답 세 개를 동시에 돌려줍니다. 글은 만들지 않습니다. 화면의 숫자는 원 발표자가 도쿄에서 일본어 문의로 잰 예시로, 담당은 기술 쪽 0.93, 분노 정도는 0.98, 긴급은 0.88이었습니다. 건강검진에서 피를 한 번 뽑아 여러 항목을 함께 검사하는 것과 같습니다. 질문을 늘려도 호출은 한 번이라, 지연도 비용도 함께 줄어듭니다.

학습 방식에도 이름이 있습니다. RLCD입니다. 사람의 선호에 맞추는 방식이 아니라 예측한 확률이 실제로 맞는 빈도와 같아지도록 보정하는 것이 목표입니다. 다만 논문과 보상 함수는 공개되지 않았기 때문에, 이 보정이 우리 데이터에서도 맞는지는 직접 재 봐야 합니다.

영상의 마지막 3분의 1은 제브 입출력 구조를 실제 시스템에 넣을 때의 설계 원칙을 모읍니다. 먼저 비슷해 보이는 방법과의 비교입니다. 구조화 출력은 JSON 스키마에 맞춰 답을 생성하지만 여전히 글을 생성하는 방식이라 속도가 거의 같습니다. 전용 분류 모델은 빠르지만 학습 데이터와 재학습 운영이 따라옵니다. 제브는 학습 없이 말로 묻고 확률로 받으므로, 분류기를 만들기 전의 검증을 당일에 시작할 수 있다는 점이 가장 큰 차이입니다. 입력이 Slack 메시지든 영수증이든 코드 변경이든 제브 입출력 구조의 돌아오는 형식은 같고, 바뀌는 것은 상태와 질문뿐입니다.

질문 설계 원칙은 세 가지입니다. 하나, 질문 하나에는 판단 하나만 담습니다. 둘, 같은 입력에 대한 질문은 요청 하나로 묶어 보내고 코드로 합칩니다. 셋, 선택지 설명은 구체적으로 씁니다. 중요성과 긴급성과 기술성을 점수 하나에 섞은 나쁜 예는 결과를 설명하기 어렵습니다. 헷갈리는 경계를 설명에 직접 적는 것이 좋은 예입니다. 제브는 쓴 그대로 답하고 의도를 추론하지 않으며, 날짜 계산이나 건수 세기처럼 코드가 더 정확한 일은 코드에 맡겨야 합니다.

에이전트 안에서는 판정이 실행 직전의 가드 단계에 끼어듭니다. 운영 루프가 요청마다 프로젝트 결정, 노트 선택, 안전 판정, 실행, 완료 확인의 다섯 단계를 돈다면, 안전 판정은 공항의 보안 검색대와 같은 자리입니다. Claude Code에는 도구 실행 전에 스크립트가 허용과 거부를 정하는 지점이 있어, 가드를 붙일 자리가 이미 마련돼 있습니다. 행동마다 판정을 끼우려면 빠르고 싸야 하는데, 영상이 인용한 TypeSafe AI의 공개 수치는 다음과 같습니다.

독립 평가는 엇갈립니다. 고객 문의 200건 분류에서는 GPT-4.1 mini보다 정확도가 약간 높았고 비용과 지연은 크게 낮았지만, 의료 진단 추론 벤치마크에서는 크게 뒤졌습니다. 영상은 단거리 선수에 빗댑니다. 100미터에서는 빠르지만 마라톤을 맡기면 안 됩니다. 판정 한 번으로 끝나는 좁은 분류에만 쓸 때 비용 이점이 유지됩니다. 출력이 무료이므로 비용은 입력 길이에만 비례하고, 상태로 넘기는 글을 짧게 유지하는 것이 비용 관리의 전부입니다.

제브 입출력 구조는 상태 하나와 이름 붙은 질문 여러 개를 한 번에 넣고, 질문 유형별 형식의 값과 확률을 받아 코드의 분기에 직접 연결하는 방식입니다. 담당자는 질문 유형마다 기준값을 따로 정해야 한다.

제브의 입력과 출력은 무엇인가요?

입력은 상태 하나와 여러 질문이고, 출력은 질문마다 형식이 정해진 결과와 확률입니다. 영상은 상황을 담은 상태와 이름 붙은 질문을 한 번에 넣으면 코드의 조건문에 바로 쓸 수 있는 값이 돌아온다고 설명합니다. 선택지는 사람이 미리 정해 두어야 하며 요청 한 번에 최대 6만 4천 토큰까지 글로 입력할 수 있습니다.

Choice, Score, Noul은 무엇이 다른가요?

Choice는 선택지별 확률 분포, Score는 단계 위의 점수, Noul은 참일 확률 하나를 돌려줍니다. 영상은 객관식, 별점, OX 퀴즈에 빗대고 코드에서는 각각 switch 분기, 임계값 비교, if 문에 대응한다고 설명합니다. 확신도는 Choice와 Score에만 붙고 Noul에는 없습니다.

확신도는 무엇이고 어떻게 쓰나요?

분포가 답 하나에 몰리면 높고 퍼지면 낮아지는 값이며, 사람에게 넘길 시점을 정하는 신호로 씁니다. 영상은 확신도가 낮은 고객 문의를 더 큰 모델로 넘겼더니 정확도가 오히려 0.7퍼센트포인트 떨어졌다는 실험을 소개하며, 큰 모델 재질의보다 사람 검토로 넘기는 설계가 근거가 있다고 말합니다.

같은 0.5라도 왜 다르게 읽어야 하나요?

Score의 0.5는 단계 사이의 정도이고 Noul의 0.5는 참과 거짓이 반반이라 판단이 서지 않았다는 뜻입니다. 영상은 온도계의 중간 눈금과 동전 던지기의 반반에 빗대며, 이 값을 등급처럼 읽으면 기준값 설계가 통째로 어긋난다고 경고합니다.

제브는 질문이 여러 개여도 왜 한 번에 답하나요?

LLM과 달리 토큰을 하나씩 생성하지 않고 상태와 이름 붙은 질문을 요청 하나에 담아 한 번에 답을 받기 때문입니다. LLM은 토큰을 낼 때마다 모델 전체를 다시 돌려 답이 길수록 지연이 쌓입니다. 영상의 호출 예에서는 담당, 분노, 긴급 세 질문에 대한 답이 한 번의 읽기로 동시에 돌아옵니다.

제브는 어떤 일에 쓰면 비용 이점이 유지되나요?

판정 한 번으로 끝나는 좁은 분류에 쓸 때 비용 이점이 유지됩니다. 영상이 인용한 공개 가격은 입력 100만 토큰당 0.042달러이고 출력은 무료입니다. 반면 의료 진단 추론 벤치마크에서는 크게 뒤졌다는 독립 평가도 함께 소개하며, 단거리 선수에게 마라톤을 맡기면 안 된다고 비유합니다.

제브 입출력 구조를 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 개념 문서를 모았습니다.

• 판단 전용 모델 제브 발표 자료 — 영상의 전체 발표 자료
• 에이전틱 AI 거버넌스 가이드 — 승인과 감사 절차 설계
• AI 에이전트란 무엇인가 — 에이전트 구조의 기본 개념
• 에이전틱 AI란 무엇인가 — 판단과 실행을 이어 가는 방식
• LLM이란 무엇인가 — 생성형 모델의 기본 원리
• 판단형 AI 제브, 입출력부터 Choice·Score·Noul까지 — 클라우드네이티브TV, 이 글이 정리한 원 영상
• MSAP.ai 솔루션 문의 — 도입 검토 상담
• MSAP.ai 홈페이지 — 제품과 자료 모음
• Daniel Kahneman — 빠른 사고와 느린 사고의 제안자
• Thinking, Fast and Slow — System One 이름의 출처
• Retrieval-augmented generation — RAG의 일반 개념
• Statistical classification — 분류 문제의 일반 설명