핵심 요약
AI 요약
기사 목차 펼치기 / 접기
두 판단 모델에 동일한 공개 데이터 400건을 1200번 똑같이 밀어 넣었다. 타입세이프AI(TypeSafe AI)의 Jev와 오픈AI(OpenAI) 디시전스 API가 내놓은 정답률 격차는 불과 1%p에 불과했지만, 보기 순서에 흔들리는 편향성과 오답에 부여한 확신도, 요청 구조별 계산서는 완전히 다른 궤적을 그렸다.
1부에서는 타입세이프AI(TypeSafe AI)의 Jev를 설치하고 문턱까지 정했다. 2부에서는 오픈AI(OpenAI) 디시전스 API(Decisions API)로 같은 과정을 밟았다. 3부는 둘을 같은 자리에 세운다. 사양과 값은 앞선 3종 비교 분석에서 정리했으니, 이번에는 같은 공개 데이터에 같은 질문을 넣어 직접 잰 결과만 다룬다. 정답률, 보기 순서에 흔들리는 정도, 틀릴 때의 확신도, 요청 모양에 따른 계산서를 차례로 보고 마지막에 상황별로 고르는 기준을 정리했다.
어떻게 쟀나
데이터는 두 가지를 썼다. 하나는 은행 고객 문의를 77개 의도로 나눈 Banking77 테스트셋에서 무작위로 뽑은 200건이다. 다른 하나는 SMS 스팸 데이터셋(SMS Spam Collection)에서 스팸 100건과 정상 문자 100건을 뽑은 200건이다. 앞의 것은 보기 77개 후보 중 하나를 고르는 다중 선택지(Choice) 질문으로, 수많은 갈래 중 정답 라벨을 골라내는 객관식 자동 분류기 역할을 맡겼다. 뒤의 것은 스팸 여부를 가려내는 예·아니오 단답형 질문으로 구성했다.
두 모델에는 질문 문장과 보기를 똑같이 넣었고, Banking77은 보기 77개를 알파벳 순서와 그 반대 순서로 한 번씩 모두 두 번 물었다. 10월 13일 jev-1.13.0과 gpt-6-luna에 1200번을 호출했고 오류는 없었다. 든 돈은 Jev 0.031달러, 디시전스 API 0.044달러로 합쳐서 약 100원이다.
두 가지는 미리 밝혀 둔다. Banking77은 2020년에 공개된 데이터라 두 모델이 학습 중에 봤을 가능성을 배제할 수 없다. 그리고 200건에서 정답률 76% 안팎이면 95% 신뢰구간이 위아래로 약 6%p다. 1~2%p 차이는 우열로 읽으면 안 된다.
정답률은 어디서 갈리나
Banking77에서 원래 순서로 물었을 때 Jev는 76.5%, 디시전스 API는 75.5%를 맞혔다. SMS 스팸에서는 Jev가 96%, 디시전스 API가 95%였다. 두 데이터 모두 차이가 1%p로, 신뢰구간 안에 든다.
아라이즈AI(Arize AI) 벤치마크는 상위 판단 모델들이 정확도에서 이미 범용재가 됐다고 결론 냈다. 이번 실측도 같은 쪽을 가리킨다.
“Jev 출시 3주 만에 상위 판단 모델은 정확도에서 범용재가 됐다.”
틀린 곳도 겹쳤다. Banking77에서 두 모델이 함께 틀린 문의가 41건으로, 각 모델 오답의 대부분이다. 뜻이 가까운 의도끼리 헷갈린 경우가 많았다. 추가로 붙는 요금이 뭐냐는 짧은 문의는 정답이 ‘이체 수수료 부과’인데, 두 모델 모두 ‘명세서의 추가 요금’으로 보냈다. 문장만 봐서는 사람도 헷갈릴 만한 문의다. 이 오답에 Jev는 0.96, 디시전스 API는 0.97을 붙여, 둘 다 같은 함정에 같은 자신감으로 빠졌다.
두 모델의 답이 같았던 179건 중 정답은 145건(81%)이었다. 두 판단 AI가 같은 답을 냈다고 그 답을 정답으로 받으면 다섯 건에 한 건은 틀린다. 모델끼리의 일치는 정답의 대용이 아니다.
보기 순서에 얼마나 흔들리나
두 모델이 가장 크게 갈린 곳은 정답률이 아니라 보기 순서였다. 보기 77개를 거꾸로 놓고 다시 묻자 Jev는 200건 중 8건(4%)의 답이 바뀌었고, 디시전스 API는 30건(15%)이 바뀌었다. 거꾸로 물었을 때의 정답률은 Jev 79%, 디시전스 API 72.5%로 벌어졌다.
1부와 2부의 작은 실험에서도 같은 방향이었다. 보기 둘짜리 결제 오류 문의에서 순서를 뒤집자 Jev는 13%p, 디시전스 API는 20%p 움직였다. 보기가 많은 분류에서 디시전스 API를 쓴다면 순서를 바꿔 두 번 묻는 것을 기본으로 삼는 편이 낫다.
두 번 묻는 일은 오답을 찾는 장치로도 쓸 수 있다. 디시전스 API에서 순서에 따라 답이 바뀐 30건 가운데 원래 순서의 답이 맞은 것은 15건뿐이었다. 답이 흔들린 건만 사람에게 보내면 검토 물량 30건으로 오답 15건을 잡는다. 비용은 요청이 두 배가 되는 것이다.
확신도를 믿어도 되나
두 모델 모두 확신도가 높을수록 더 자주 맞혔다. 가장 높은 보기 확률이 0.95 이상인 구간의 정답률은 Jev 92%, 디시전스 API 90%였다. 확률을 문턱으로 쓰는 일 자체는 둘 다 성립한다.
하지만 둘 다 실제보다 자신 있게 답했다. Banking77에서 가장 높은 보기 확률의 평균은 Jev 0.89, 디시전스 API 0.84였는데, 실제 정답률은 76.5%와 75.5%였다. 확률과 실제 정답률의 평균 차이를 재는 기대 보정 오차(ECE)는 Jev 0.125, 디시전스 API 0.101로 디시전스 API가 조금 나았다. 0.95 이상을 붙이고도 틀린 건은 양쪽 모두 10건이다.
문턱을 걸었을 때 남는 양은 이렇다.
| 문턱(가장 높은 보기 확률) | Jev 자동 처리 | Jev 정답률 | 디시전스 API 자동 처리 | 디시전스 API 정답률 |
|---|---|---|---|---|
| 0.5 | 192 | 79.2% | 181 | 79% |
| 0.7 | 168 | 85.7% | 156 | 85.3% |
| 0.8 | 156 | 87.2% | 137 | 88.3% |
| 0.9 | 138 | 89.9% | 120 | 89.2% |
| 0.95 | 121 | 91.7% | 98 | 89.8% |
같은 문턱에서 Jev가 자동으로 처리하는 양이 더 많고 정답률은 비슷했다. 디시전스 API는 맞힌 답에 낮은 확률을 붙이는 일이 잦았다. 맞혔는데 확률이 0.7 미만인 건이 Jev는 9건, 디시전스 API는 18건이었다. 문턱을 올리면 디시전스 API 쪽에서 맞힌 답이 먼저 검토로 빠진다.
순서를 바꿔 두 번 물으면 얼마나 남나
앞에서 본 두 번 묻기를 자동 처리 정책으로 바꿔 봤다. 순서를 바꿔 두 번 물어 답이 같고, 두 번 모두 가장 높은 보기 확률이 문턱을 넘을 때만 자동으로 처리하는 방식이다.
| 정책(Banking77 200건) | Jev 자동 처리 | Jev 그중 오답 | 디시전스 API 자동 처리 | 디시전스 API 그중 오답 |
|---|---|---|---|---|
| 한 번 묻고 문턱 0.8 | 156 | 20 | 137 | 16 |
| 두 번 묻고 문턱 0.8 | 145 | 15 | 93 | 8 |
| 한 번 묻고 문턱 0.9 | 138 | 14 | 120 | 13 |
| 두 번 묻고 문턱 0.9 | 130 | 11 | 72 | 6 |
디시전스 API는 두 번 묻자 오답이 절반으로 줄었지만 자동 처리량도 137건에서 93건으로 크게 줄었다. Jev는 순서에 덜 흔들리는 만큼 두 번 물어도 처리량이 156건에서 145건으로 조금 줄고 오답도 20건에서 15건으로 조금 줄었다. 두 번 묻기는 디시전스 API에서 효과가 크고 값도 크다. 요청이 두 배가 되고, 사람에게 가는 물량이 늘어난다.
틀릴 때 망설이나
SMS 스팸에서 두 모델이 놓친 스팸은 Jev 8건, 디시전스 API 9건으로 비슷했다. 갈린 것은 놓칠 때 붙인 확률이다.
Jev가 놓친 8건 가운데 5건은 스팸 확률 0.43~0.5로, 거의 반반이었다. 디시전스 API가 놓친 9건은 7건이 0.1 이하였다. 한쪽은 망설이다 놓쳤고, 다른 쪽은 확신하며 놓쳤다. 정상 문자를 스팸으로 잘못 잡은 건은 Jev 0건, 디시전스 API 1건이었다.
이 차이는 문턱을 만질 때 드러난다. 스팸 판정 문턱을 0.5에서 0.3으로 내리자 Jev는 스팸 100건 중 97건을 잡았고 정상 문자를 하나도 잘못 잡지 않았다. 디시전스 API는 같은 조정에도 91건에 머물렀다. 놓친 스팸에 0에 가까운 확률을 붙였으니 문턱을 내려도 걸리지 않는다.
2부의 고객 문의 실습에서도 디시전스 API는 유일한 오답에 0.98을 붙였고, Jev는 같은 건을 0.75로 망설였다. Banking77의 0.95 이상 오답은 양쪽 모두 10건으로 차이가 없었지만, 예·아니오 판정과 문의 실습에서는 방향이 두 번 같았다. 탐지 업무처럼 놓치는 것이 비싼 일이라면 문턱으로 재현율을 끌어올릴 여지가 어느 쪽에 남는지를 직접 재봐야 한다.
계산서는 요청 모양이 정한다
100만토큰 단가만 보면 Jev 0.042달러, 디시전스 API 0.1달러로 2.4배 차이다. 실제 요청의 입력 토큰을 곱해 보면 배수가 요청 모양에 따라 달라졌다.
예·아니오 질문 하나짜리 SMS 판정은 1000건에 Jev 0.014달러, 디시전스 API 0.02달러로 1.4배였다. 보기 77개짜리 Banking77도 0.071달러 대 0.099달러로 1.4배에 그쳤다. Jev가 보기 77개짜리 요청에 평균 1696토큰을 세는 동안 디시전스 API는 989토큰을 셌기 때문이다. 반대로 문의 하나에 예·아니오 질문 10개를 묶은 요청은 Jev 448토큰, 디시전스 API 1561토큰으로 8.3배 벌어졌다.
보기가 많을수록 Jev 쪽 토큰이 늘고, 질문을 많이 묶을수록 디시전스 API 쪽 토큰이 는다. 단가표로 견적을 내지 말고, 내 요청을 두 서비스에 한 번씩 보내 usage에 찍힌 입력 토큰으로 계산해야 한다.
응답 속도는 비슷했다. 우리 환경에서 잰 중앙값은 Jev 0.58~0.67초, 디시전스 API 0.58~0.60초였다. 느린 쪽 5%를 보는 95번째 백분위수는 SMS에서 Jev 1.38초, 디시전스 API 0.93초로 Jev가 더 길었다.
다른 측정과 맞춰 보면
아라이즈AI의 8종 모델 실측에서 Jev와 디시전스 API는 이렇게 나왔다.
| 항목(아라이즈AI 측정) | Jev | 디시전스 API |
|---|---|---|
| 환각 탐지 정확도(RAGTruth) | 85.5% | 81.5% |
| 피닉스(Phoenix) 평가 묶음 | 91.1% | 90% |
| 에이전트 라우팅 | 52건 중 49건 | 52건 중 48건 |
| 보정 오차(낮을수록 좋음) | 0.023 | 0.042 |
| 응답 시간 중앙값 | 0.08초 | 0.16초 |
| 1000건 비용(RAGTruth) | 0.045달러 | 0.09달러 |
정확도가 엇비슷하다는 결론은 이번 실측과 같다. 보정은 달랐다. 아라이즈에서는 Jev의 보정 오차가 절반 수준이었지만, 이번 Banking77에서는 디시전스 API 쪽이 조금 낮았고 SMS에서는 0.052달러 대 0.044달러로 비슷했다. 애브노멀(Abnormal)의 40개 모델 실측에서는 Jev가 가장 잘 보정됐고, 디시전스 API는 정밀도 99%를 맞춘 탐지에서 가장 돋보인다는 평가를 받았다.
“판단 API들은 가장 잘 보정된 축에 들었고, 그중 Jev가 우리가 시험한 어떤 모델보다 잘 보정됐다.”
보정은 모델에 고정된 성질이 아니고 과제마다 달라진다. 응답 시간도 아라이즈 측정에서는 Jev가 두 배 빨랐지만 이번 실측에서는 비슷했다. 서버와의 거리와 네트워크까지 포함한 시간은 측정 환경을 따라간다. 아라이즈도 고르는 기준으로 정확도표 대신 두 가지를 들었다.
“API로 부를지 가중치를 직접 올릴지, 어디서 돌릴지를 보고 골라라. 모델을 시험하는 만큼 질문도 시험하라.”
기능은 어디서 갈리나
| 항목 | Jev | 디시전스 API |
|---|---|---|
| 입력 | 텍스트 | 텍스트·이미지(base64) |
| 거부 응답 | 없음 | 있음. 지원자 탈락 여부 같은 질문을 거부 |
| 재료 속 주입 문장(1·2부 실험) | 결제팀 확률 1.0에서 0.64로 하락. 방어 문구로 복구 | 1.0에서 0.99로 하락 |
| 버전 고정 | jev-1.13.0으로 고정 | gpt-6-luna 하나, 고정 버전 없음 |
| 처리 한도 공개 | 초당 10만토큰·80요청 | 디시전스 전용 수치 미공개 |
| 요청 형식 | 마이크로소프트(Microsoft)·오픈라우터(OpenRouter)·공개 모델이 같은 형식 사용 | 자체 형식. 옮기려면 변환 필요 |
| 데이터 조건 | 고객 데이터 학습 없음, ZDR은 기업 고객 | ZDR·HIPAA(자격 고객), 미국·유럽 처리 지정 |
| 자체 설치 대안 | 같은 형식의 공개 모델(Kev·클레프 등) | 없음 |
| 출시 단계 | 정식 | 공개 베타 |
| 막힌 건 넘기기 | 다른 회사 LLM을 따로 호출 | 같은 키로 오픈AI 추론 모델 호출 |
어느 쪽을 고르나
실측과 기능을 합치면 고르는 기준은 이렇게 정리된다.
| 상황 | 먼저 볼 쪽 | 근거 |
|---|---|---|
| 한 입력에 질문을 여러 개 묶는 텍스트 판단 | Jev | 질문 10개 묶음에서 비용 8.3배 차이 |
| 보기가 많은 분류 | Jev, 또는 디시전스 API로 순서 바꿔 두 번 | 순서 뒤집기에서 답이 바뀐 비율 4% 대 15% |
| 놓치면 비싼 탐지(스팸·위험 신호) | 직접 재보되 Jev 쪽이 문턱 조정 여지가 컸다 | 문턱 0.3에서 재현율 97% 대 91% |
| 이미지 판단 | 디시전스 API | Jev는 텍스트 전용 |
| 오픈AI 계정의 데이터 조건, 같은 키로 상위 모델 연결 | 디시전스 API | ZDR·HIPAA·지역 처리, Responses API와 같은 키 |
| 데이터를 밖으로 못 보냄 | Jev 형식의 공개 모델 | 디시전스 API는 자체 설치 대안이 없다 |
| 사람에 대한 최종 결정 | 둘 다 맡기지 않는다 | 디시전스 API는 거부, 마이크로소프트도 단독 근거로 쓰지 말라고 권고 |
어느 쪽을 고르든 1부와 2부의 문턱 실습은 내 데이터로 다시 해야 한다. 두 모델의 확률은 같은 자로 잰 값이 아니어서, 한쪽에서 정한 문턱을 다른 쪽에 그대로 옮기면 처리량과 오답률이 함께 달라진다.
정답률은 같고 틀리는 방식이 다르다
같은 입력 400건에서 두 모델의 정답률 차이는 1%p였다. 차이는 다른 데서 났다. 보기 순서를 뒤집었을 때 답이 바뀐 비율이 4배 가까이 달랐고, 놓친 스팸에 붙인 확률이 반반과 0으로 갈렸다. 계산서는 요청 모양에 따라 1.4배에서 8.3배까지 벌어졌다.
판단 AI를 고르는 일은 단순한 정답률표 대조가 아니다. 보기 순서를 뒤집어 편향을 확인하고, 틀린 답에 찍힌 확신도와 usage에 찍힌 실제 토큰 영수증을 직접 들여다봐야 한다.
결국 모델의 우열이 아니라, 내 비즈니스 실패 비용의 성격이 선택을 가른다.
