Jev와 OpenAI Decisions API 차이와 사용법

“카드로 두 번 결제됐어요”라는 문의가 들어왔다고 해볼게요. 답변 문장을 만들기 전에 어느 팀으로 보낼지부터 정해야 하죠. Jev는 이런 작은 판단을 코드가 바로 읽을 수 있는 값으로 돌려주는 TypeSafe AI의 모델이에요. 회사는 이 방식을 System One이라고 부르며, 2026년 9월 15일 Jev를 공개했어요.

판단할 자료는 state, 물어볼 내용은 questions에 넣어요. 질문은 세 가지로 나뉘어요.

Choice: 결제팀, 기술지원팀, 기타처럼 정해 둔 선택지 중 하나를 골라요.

Score: 낮음, 보통, 높음처럼 순서 있는 기준으로 평가해요. 결과는 각 등급의 확률을 반영한 값이라 중간 숫자도 나올 수 있어요.

Noul: “이 문의에 긴급한 상황이 나타나나요?”처럼 예, 아니오 질문에 0~1의 확률을 돌려줘요. 무조건 참, 거짓 하나만 받는 것은 아니에요.

Jev가 선택을 내놓으면 그다음 행동은 우리 코드가 정해요. billing을 받았다고 바로 환불할 필요는 없어요. 담당 대기열에 넣는 것부터 시작할 수 있어요. 자유로운 답장이나 긴 글을 쓰는 역할과도 구분하면 이해하기 쉬워요.

OpenAI Decisions API도 앱이 쓸 판단값을 받는 창구예요. 다만 Jev가 모델 이름이라면 Decisions API는 API 이름이고, 2026년 10월 8일 공식 문서에서 지원하는 모델은 gpt-6-luna예요. 현재 공개 베타로 안내하고 있어요.

질문 종류는 choice, score, predicate예요. 앞의 둘은 선택과 등급 평가이고, predicate는 조건이 참일 가능성을 probability로 받아요. Jev의 Noul과 용도가 비슷하지만 필드명이 달라요.

예를 들어 사진에 파손이 보이는지 판단하거나, 문의를 부서별로 나누거나, 처리 우선순위를 매길 수 있어요. OpenAI는 텍스트와 이미지 입력을 지원해요. 두 제품이 같은 기능 일부를 제공한다고 해서 내부 구조나 학습 방식까지 같다고 단정할 수는 없어요.

빠르게 이해하려면 아래의 같은 문의 분류 예제를 비교해 보세요. 공식 문서를 바탕으로 작성한 코드이며, 이 글에서는 유료 API를 직접 호출한 결과나 속도 실측을 제시하지 않아요.

먼저 TypeSafe 공식 사이트에서 API console로 들어가 접근 가능 여부와 API 키를 확인해요. 별도 연습 폴더에서 Python 3.10 이상을 사용하고, 아래 명령으로 공식 패키지를 설치해요. 키는 코드에 쓰지 말고 실행 환경의 TYPESAFE_API_KEY에 설정해 주세요.

python -m pip install typesafe-sdk

다음 코드를 jev_example.py로 저장해요. 고객 자료 대신 아래의 짧은 합성 문의를 그대로 쓰면 돼요. criteria는 각 선택지가 뜻하는 기준이에요. 분류가 애매할 때 보낼 other도 넣었어요.

from typesafe_sdk import Choice, TypeSafeClient

client = TypeSafeClient()
result = client.system_one(
    model="jev-1.13.0",
    state="카드로 두 번 결제됐어요. 중복 결제를 확인해 주세요.",
    questions={
        "department": Choice(
            instructions="이 문의를 어느 팀에 전달할까요?",
            criteria={
                "billing": "결제, 청구, 환불 문의",
                "technical": "오류, 장애, 제품 사용 문제",
                "other": "어느 분류에도 맞지 않거나 정보 부족",
            },
        )
    },
)
answer = result.answers["department"]
print(answer.choice)
print(answer.probabilities)
print(answer.confidence)

파일을 저장한 폴더에서 python jev_example.py를 실행하면 API 요청이 전송돼요. 이 단계부터 API 사용 요금이 발생할 수 있어요. SDK는 공식 POST /v1/systemone 엔드포인트를 호출해요.

답은 answers["department"]로 꺼내요. choice는 선택값, probabilities는 선택지별 확률, confidence는 확률 분포를 요약한 값이에요. 위 문의는 결제팀을 정답으로 정해 비교할 수 있지만, 실제 모델이 반드시 billing을 반환한다고 보장하지 않아요.

인증 오류가 나면 같은 실행 환경에 키가 설정됐는지와 계정 접근 권한부터 확인해요. 호출 제한 오류는 잠시 기다린 뒤 재시도하고, 실패한 요청을 결제팀으로 분류된 것으로 처리하지 마세요.

이번에는 OpenAI Platform에서 API 프로젝트와 키를 준비하고 실행 환경의 OPENAI_API_KEY에 설정해요. Python SDK는 공식 가이드가 요구하는 3.26.0 이상을 사용해요. 이 숫자는 Python 언어 버전이 아니라 openai 패키지 버전이에요.

python -m pip install "openai>=3.26.0"

아래를 openai_example.py로 저장해요. Jev의 state 대신 input, 이름이 붙은 질문 객체 대신 questions 배열을 써요. 선택지 설명도 criteria 대신 choices에 넣어요.

from openai import OpenAI

client = OpenAI()
result = client.decisions.create(
    model="gpt-6-luna",
    input="카드로 두 번 결제됐어요. 중복 결제를 확인해 주세요.",
    questions=[{
        "type": "choice",
        "name": "department",
        "instructions": "이 문의를 어느 팀에 전달할까요?",
        "choices": [
            {"value": "billing", "description": "결제, 청구, 환불 문의"},
            {"value": "technical", "description": "오류, 장애, 제품 사용 문제"},
            {"value": "other", "description": "어느 분류에도 맞지 않거나 정보 부족"},
        ],
    }],
)
answer = next(a for a in result.answers if a.name == "department")
if answer.type == "refusal":
    print("응답 거절: 사람 검토로 전달")
else:
    print(answer.choice)
    print(answer.probabilities)
    print(answer.confidence)

저장한 폴더에서 python openai_example.py를 실행하면 과금될 수 있는 API 요청이 전송돼요. 전용 주소는 POST /v1/decisions예요. 일반 Responses 호출에서 모델 이름만 바꾸는 방식과 달라요.

응답도 배열이라 질문에 붙인 name으로 찾았어요. 결과가 refusal이면 선택값을 사용하지 않고 검토로 넘겨요. decisions 속성이 없다는 오류가 나면 실제 실행 중인 환경에서 python -m pip show openai로 설치 버전을 확인해요. 인증, 호출 제한 오류도 분류 성공으로 취급하지 마세요.

입력: 현재 Jev 1.13은 텍스트 전용이에요. JSON 객체를 받아도 사진을 직접 이해하는 입력이 되는 것은 아니에요. OpenAI Decisions는 이미지도 받아요. 이미지를 보낼 때는 외부 이미지 주소나 파일 ID 대신 inline data URL 형식이 필요해요.

자료 구조: Jev는 질문 이름을 키로 한 객체와 criteria를 써요. OpenAI는 name이 있는 질문 배열, choices 또는 levels를 써요. 응답의 확률 목록도 Jev는 객체, OpenAI는 배열이므로 주소와 모델명만 바꿔서는 예제가 호환되지 않아요.

언어와 버전: TypeSafe는 영어를 주요 학습 언어로 설명하고 다른 언어의 성능은 같지 않다고 밝혀요. 위 한국어 문의 코드를 작성했다고 한국어 정확도가 검증된 것은 아니에요. jev-latest는 새 모델로 바뀔 수 있어 이번 예제는 jev-1.13.0으로 고정했어요. 모델을 바꾸면 분류 기준과 보류 기준도 다시 평가하세요.

긴 답변이 필요할 때: 문의 분류가 끝난 뒤 답장까지 써야 한다면 그 부분은 텍스트 생성 모델에 맡길 수 있어요. 임의의 필드를 추출해 JSON 객체를 만들려면 Structured Outputs가 더 맞는지 살펴보세요. 판단값을 받는 API와 자유로운 내용을 생성하는 API의 역할을 나누는 거예요.

2026년 10월 8일 공식 기본 단가로 Jev는 입력 100만 토큰당 0.042달러, OpenAI Decisions는 0.10달러예요. 토큰은 모델이 글을 처리하는 단위이고, 두 서비스 모두 출력 토큰 요금은 없다고 안내해요. OpenAI는 캐시 읽기, 쓰기 요금도 없으며 지역 처리와 긴 입력에 따른 요금 조건이 따로 있어요.

이 숫자만 보고 실제 서비스 총비용이 몇 배 차이라고 확정하면 안 돼요. 입력에는 질문과 선택 기준도 포함될 수 있고, 토큰 계산, 재시도, 보류 비율도 비용을 바꿔요. 같은 평가 자료로 실제 사용량을 비교하는 편이 좋아요.

OpenAI의 “약 10배 빠르다”는 안내는 Responses API와의 비교예요. Jev보다 10배 빠르다는 뜻이 아니에요. TypeSafe의 발표 속도 역시 공급사가 제시한 조건의 결과예요. 서로 다른 홍보 수치를 붙여 순위를 매기지 않았어요.

실무에서는 한국어 문의 묶음을 고정하고 정확도, 애매해서 보류한 비율, 늦은 응답까지 포함한 지연 시간, 실제 청구 입력량을 함께 비교해 보세요. 빨라도 잘못된 부서로 자주 보내면 전체 업무는 더 느려질 수 있어요.

confidence를 그 요청의 정답률로 읽으면 안 돼요. TypeSafe는 이를 반환된 확률 분포에서 계산하는 값으로 설명해요. 선택지가 세 개이고 확률이 0.6, 0.3, 0.1이라면 공식 Choice 공식의 confidence는 0.4예요. 60%와 40%는 서로 다른 수치예요.

형식이 정확해도 부서를 잘못 고를 수 있어요. “선택지 밖의 문장을 만들지 않는다”와 “항상 옳은 결정을 한다”는 다른 말이에요. 공급사가 바뀌어도 같은 confidence 숫자에 같은 의미나 성능을 기대하지 마세요.

처음에는 결과를 실제 담당자 분류와 나란히 기록해요. 애매한 문의, 분류에 없는 문의, 한국어 줄임말, 여러 요청이 섞인 문장도 평가에 넣어요. 어떤 오분류가 더 손해인지 보고 자동 전달 기준을 정하면 돼요. 임의로 0.8 같은 값을 골랐다고 안전성이 보장되지는 않아요.

other, 낮은 확신, 응답 거절, 통신 실패는 사람 검토로 보내는 출발점이 될 수 있어요. 같은 입력을 함께 보는 독립 질문은 한 요청에 넣고, 앞선 답에 따라 다음 질문이 달라지면 요청을 나눠요. 분류 결과가 환불 같은 실제 행동의 권한 확인을 대신하지 않도록 해 주세요.

이런 곳에 활용해 볼 수 있어요. 고객 문의를 결제, 기술지원, 기타로 나누어 담당자에게 전달하거나, 들어온 문서와 업무의 긴급도를 점수로 매겨 사람이 볼 순서를 정할 수 있어요. AI가 답변하기 전에 검색된 자료가 질문과 관련 있는지 판별하는 데도 쓸 수 있어요. 이때 RAG는 검색으로 찾은 자료를 AI 답변에 참고시키는 방식이에요.

텍스트 분류, 점수화는 두 제품의 비교 후보가 되고, 상품 사진의 파손 여부처럼 이미지 자체를 판단하려면 이미지 입력을 지원하는 OpenAI Decisions를 살펴볼 수 있어요. 이는 활용 아이디어이며 이 글에서 효과를 실측한 사례는 아니에요. 처음에는 자동 실행보다 사람이 확인할 후보를 정리하는 보조 역할부터 붙여 보세요.

텍스트 문의의 작은 판단을 실험한다면 Jev의 질문 분해 방식과 공개 단가를 살펴볼 수 있어요. 이미지 판단이나 기존 OpenAI API 연동이 중요하다면 Decisions API를 같은 평가 자료로 비교해 볼 만해요. 어느 쪽이 내 한국어 업무에 더 정확한지는 이름이나 출시 순서만으로 정할 수 없어요.

첫 프로젝트는 자동 환불보다 문의 분류 보조 도구가 좋아요. 합성 문의에 사람이 정답 부서를 붙이고, 두 API가 반환한 선택, 확률, 보류 여부를 비교해 보세요. 아직 API를 호출하지 않아도 질문과 선택 기준부터 설계할 수 있어요.

배울 핵심은 네 가지예요. 업무를 작은 판단으로 나누기, 정답이 있는 평가 자료 만들기, 오분류 비용에 맞춰 보류 기준 정하기, 모델, 질문 버전과 결과를 기록하기예요. 모델이 답을 주더라도 그 답을 언제 사용하고 언제 멈출지 설계하는 역량은 개발자에게 남아요.