Jev의 빠른 판단을 어디까지 믿을까, 0.7초 글쓰기 점검의 조건

Jev의 777개 글쓰기 판단 실험과 별도 결함 탐지 비교를 통해 구조화 출력, 병렬 평가, 낮은 비용의 이점과 정확도·저자 판별의 한계를 살펴본다.

게시 2026/09/21

By 정섭

15 분읽는 시간

TL;DR

Jev는 문장을 생성하기보다 코드가 바로 사용할 선택·점수·확률을 반환한다. 작은 판단을 병렬로 실행해 업무 중간에 여러 번 확인하는 용도를 겨냥한다. 출력 형식이 맞는 것과 판단이 정확한 것은 별개의 검증 대상이다.
Mike Taylor의 실험은 공개 글 27편과 AI 문체 대조본 10편에 21개 질문을 적용했다. 37개 API 호출을 병렬 실행해 777개 판단을 약 612밀리초에 받았다. 이는 문체 신호 점검이며 AI가 쓴 글인지 확정하는 검사는 아니다.
별도 실험에서 Jev는 문단당 중앙값 0.35초로 Fable 5.1의 8.83초보다 빨랐다. 추정 비용도 낮았지만 의도적으로 넣은 결함 7개 중 1개를 놓쳤다. 빠른 점검은 후속 검토의 신호로 쓸 수 있어도 무오류 보장은 아니다.
유용한 적용은 반복되는 판단을 작은 질문으로 나누고 사람의 평가와 대조하는 데서 시작한다. 속도가 충분하면 완성 뒤뿐 아니라 작업 중간에도 점검할 수 있다. 최종 기준은 그 답에 따라 행동했을 때 업무 결과가 좋아지는지다.

글 37편을 점검한 0.7초의 구성

Every의 평가 책임자 Mike Taylor는 자신이 쓴 글 27편과 의도적으로 AI 문체를 입힌 대조본 10편을 Jev에 넣었다. 각 문서에 같은 질문 21개를 적용해 근거 없이 내용을 반복하는지, 억지로 양쪽 입장을 대칭시키는지, 단순한 내용을 과하게 설명하는지 등을 살폈다. 원문의 0.7초 미만이라는 결과는 이 37개 문서에 대한 777개 판단을 받는 데 걸린 시간이다. 글을 다시 쓰거나 평가 근거를 긴 문장으로 생성하는 시간은 아니다.

연결된 실험 데이터에는 문서마다 한 번씩 총 37개 API 호출을 실행했고 전체 경과 시간이 611.9밀리초였다고 기록돼 있다. 한 문서 안의 여러 질문을 병렬로 평가하는 기능과 여러 문서 요청을 동시에 보내는 구성이 함께 작용한 결과다. 추정 Jev 비용은 0.0026451달러였으며 기사에서는 약 4분의 1센트로 표현했다. 입력은 구독 없이 접근할 수 있던 공개 글 텍스트였으므로 제목의 모든 글을 전체 원고나 비공개 자료까지 읽었다는 뜻으로 넓혀서는 안 된다.

이 실험 묶음은 기사 발행일과도 구분해야 한다. 기사는 2026년 9월 15일 발행되고 9월 20일 수정됐지만 연결된 보고서의 저장된 측정 시각은 8월 28일이다. 웹 실험실의 재생 화면은 저장된 응답과 시간을 보여주며 방문할 때마다 새 API 시험을 하는 것은 아니다. 이 노트 역시 그 공개 결과를 대조한 것이며 Jev를 직접 다시 실행해 같은 시간을 재현한 기록은 아니다.

문장 대신 소프트웨어가 사용할 판단을 반환한다

Jev가 겨냥하는 업무는 고객 요청의 경로 지정, 청구서와 발주서의 일치 여부 확인, 거래의 위험 분류처럼 반복되는 결정이다. 자연어로 질문하되 결과는 코드에서 조건 분기나 정렬에 쓸 수 있는 값으로 받는다. 예를 들어 고객이 화가 났는지에 대한 확률을 반환하면 애플리케이션은 그 값과 자체 정책에 따라 우선순위를 정할 수 있다. 모델의 긴 답변에서 숫자를 다시 추출하는 단계를 줄이는 설계다.

TypeSafe 문서는 질문 형식을 Choice, Score, Noul로 나눈다. Choice는 정해진 선택지, Score는 평가 기준에 따른 점수, Noul은 예·아니요 명제에 대한 0부터 1 사이의 값을 반환한다. Choice와 Score에는 확률 분포와 confidence도 포함되며 서로 다른 질문 형식을 한 요청 안에 섞을 수 있다. 질문은 같은 상태를 대상으로 독립적으로 평가하므로 복합 문제를 작은 판단으로 나누고 결과를 코드에서 조합하는 방식이 권장된다.

범용 LLM도 구조화된 출력을 만들 수 있으며 Taylor 역시 이전에는 DSPy로 이를 다뤘다. Jev의 차별점은 그런 결정을 중심에 놓고 출력 형태와 실행 비용을 설계했다는 데 있다. TypeSafe는 RLCD라는 학습 방식으로 모델의 확신과 실제로 맞는 빈도를 일치시키려 한다. 다만 숫자로 확신을 반환한다고 그 확률이 해당 업무에서 잘 보정됐다는 사실까지 입증되는 것은 아니며 형식 준수와 의미적 정확성을 따로 확인해야 한다.

문체 점수는 저자를 판별하는 증거가 아니다

Taylor는 결과를 훑어보며 자신이 AI를 더 많이 활용한 글의 특징을 어느 정도 잡았다고 평가하지만 실제 운영 전에는 더 철저한 정확도 검사가 필요하다고 단서를 붙인다. 공개 실험의 대조본은 일부 원고를 의도적으로 AI 문체처럼 만든 자료다. 이런 자료에서 점수 차이가 나타나는 것과 다양한 실제 글의 작성자를 구분하는 것은 다른 문제다. 원래의 공개 글도 AI를 전혀 쓰지 않은 정답 집합으로 인증된 것은 아니다.

실험 보고서는 높은 점수가 AI 저작의 증거가 아니라 검토할 문체 신호라고 명시한다. 반복과 과잉 설명, 특정한 문장 구성은 사람이 쓴 글에도 나타날 수 있기 때문이다. 또한 21개 질문 중 종합 문체 지수는 19개 개별 패턴의 평균으로 구성하며 AI 생성 여부와 전체적 AI 느낌을 묻는 두 항목은 따로 표시한다. 서로 다른 점수의 의미를 섞지 않아야 결과를 저자 판정이나 글 전체의 품질 평가로 오해하지 않는다.

낮은 비용의 범위와 실험의 현실성

Taylor가 공개한 실험은 글쓰기 외에도 코드와 정책 검색, 고객지원 답변 평가, 에이전트의 위험 행동 점검, 투자 제안과 이메일의 우선순위 결정 등 11개다. 연결된 JSON의 호출·판단·추정 비용을 합산하면 299개 API 호출, 1,709개 판단, 0.0081492달러로 보고서의 합계와 일치한다. 판단 수는 문서 수나 API 호출 수와 같은 단위가 아니며 반복 평가가 포함된 실험도 있다. 이 비용은 해당 실행에서 추정한 TypeSafe 사용료다.

작은 비용만으로 실제 업무 효과까지 결론 낼 수는 없다. 고객지원과 이메일 자료는 합성 사례이며 코드 탐색 비교도 인공 저장소에서 조건별로 한 번 실행한 시험이다. 가상 인물 100명이 어느 광고를 클릭할지 묻는 실험 역시 실제 광고 클릭을 관찰한 결과가 아니다. 검색 준비와 다른 모델의 사용, 시스템 구현과 운영에 드는 비용을 Jev 호출 비용과 동일시하지 않는 것도 중요하다.

빠른 검사기가 놓친 결함 한 개

Every의 CEO Dan Shipper는 글쓰기 검사기로서의 성능을 별도로 비교했다. 직접 만든 문단 12개는 명확한 버전 6개와 의도적으로 문제가 들어간 버전 6개였으며 두 모델에 같은 검사 항목 4개를 적용했다. 설명되지 않은 행동, 빠진 추론 연결, 목적을 수단으로 바꾼 표현, 원문을 왜곡한 주장을 찾는 과제다. 문제가 있는 문단 수는 6개지만 심어 둔 결함 수는 7개이므로 두 수치를 같은 분모로 쓰면 안 된다.

Jev의 문단당 응답 시간 중앙값은 0.35초였고 high effort 설정의 Fable 5.1은 8.83초였다. 기사에서 약 25배 빠르고 추정 비용은 약 580배 낮다고 설명하지만 Jev는 7개 결함 중 6개를 찾았고 Fable은 모두 찾았다. 특히 부모와 직원이 공유 일정표를 함께 가르친다는 문장에서 무엇을 가르친다는 것인지 설명되지 않은 문제를 Jev는 세 번 모두 놓쳤다. 이 작은 합성 시험은 속도와 탐지 능력의 교환 관계를 보여주지만 일반적인 정확도나 거짓 경고의 비율을 확정하지는 않는다.

완성 뒤의 채점에서 작업 중간의 점검으로

Taylor는 Jev를 지식 노동의 코드 린터에 비유한다. 생성 모델이 문단 하나를 쓸 때마다 미리 정한 질문으로 점검하고 의심스러운 결과가 나오면 생성 모델이나 사람이 해당 구간을 다시 살펴보는 흐름이다. 낮은 지연과 비용이 의미 있는 이유는 한 번의 최종 평가를 작업 도중 여러 번의 피드백으로 바꿀 수 있기 때문이다. 다만 모든 검사를 통과했다는 사실은 검사 목록 밖의 오류까지 없다는 뜻은 아니다.

Every에서 만드는 개인별 벤치마크도 정기적으로 하는 업무 5~10개의 예시와 선호를 개별 통과·실패 기준으로 바꾸는 데서 시작한다. 브랜드에 맞는 발표 자료인지, 홍보 문구의 도입이 좋은지처럼 주관적인 기준도 사람의 판단과 비교하며 다듬는다. Jev를 도입할 때 역시 이미 반복해서 내려야 하는 판단 하나를 고르고 기존 LLM 및 사람의 평가와 대조하는 방식이 출발점이다. 빠르게 답을 얻는 것을 넘어 그 답에 따른 행동이 실제 업무를 개선하는지가 최종 수용 기준이다.