Orc Hwang's Wiki

개발 학습 기록과 기술 지식을 체계적으로 관리하는 개인 위키입니다.

0.7초 만에 내 글 전부를 심사한 모델: TypeSafe Jev 미니 바이브 체크 (Mike Taylor)

articles ai llm agentic-engineering evaluation structured-output
판단의 컨베이어 — 문서 37편 × 판정 렌즈 21개, 777개 확률 도장이 0.7초에 찍힌다 판정 렌즈 ×21 · 동시 판정 0.92 0.13 0.88 0.95 0.21 0.90 0.84 문서 37편 · 컨베이어 0.7초 777개 판단 · 약 0.25¢
판단의 컨베이어 — 37편의 문서 위로 21개의 판정 렌즈가 동시에 초록(통과)·빨강(지적) 확률 도장을 찍는다. 모래시계의 모래가 다 떨어지기도 전에: 777개 판단, 0.7초, 약 0.25센트.

원문 정보

에이전트 시대의 최대 병목인 “검증”을 정면으로 겨냥한 새로운 모델 계층 — 판단 특화 모델 — 의 실사용 리뷰라서 Articles에 담는다.

한 줄 요약 (TL;DR)

TypeSafe의 Jev는 대화하는 LLM이 아니라 “주관적 질문 → 보정된(calibrated) 확률”만 돌려주는 판단 특화 모델이다. 저자가 자기 글 37편에 21개 질문(총 777개 판단)을 던지자 0.7초, 약 0.25센트에 결과가 나왔고 — 이 속도와 가격이라면 지식 노동에도 코드 린터 같은 실시간 품질 검사가 가능해진다는 것이 글의 결론이다.

글의 척추를 한 장으로 정리하면 이렇다 — 같은 주관적 질문이 기존 LLM 경로와 Jev 경로에서 어떻게 갈라지고, 확률이 어디로 흘러가는가.

flowchart LR
    Q["주관적 질문<br/>(평범한 영어)"]
    Q --> LLM["기존 LLM<br/>(대화·생성 모델)"]
    Q --> JEV["Jev<br/>(판단 특화 모델)"]
    LLM --> TXT["텍스트(산문) 출력"]
    TXT --> PAIN["파싱 취약 · 느림 · 비쌈"]
    JEV --> PROB["보정된 확률<br/>(calibrated)"]
    PROB --> CODE["코드에 바로 사용<br/>(확률 + 임계값 + if문)"]
    CODE --> U1["① 컨텍스트 찾기<br/>(파일·정책 검색)"]
    CODE --> U2["② 작업 검사<br/>(채점·플래깅·감사)"]
    CODE --> U3["③ 의사결정<br/>(우선순위·분류·예측)"]

왜 이 글을 골랐나

이 위키에서 반복해 온 주제가 하나 있다. 생성은 싸졌는데 검증은 싸지지 않았다는 비대칭이다. 확률적 엔지니어링과 24-7 직원에서 다뤘듯, 에이전트 함대가 밤새 코드를 쏟아내는 시대의 병목은 생성이 아니라 “이게 맞는지”를 판정하는 쪽이다. Jev는 바로 그 판정 단계를 밀리초·마이크로센트 단위로 끌어내리겠다는 시도다.

또 하나의 이유는 형태다. 이 글은 벤더 발표문이 아니라 저자가 자기 글 전체를 실험 대상으로 던져본 실사용기(“mini-vibe check”)라서, 스펙 나열이 아니라 “실제로 어디에 쓸 수 있고 어디서 틀리는가”를 보여준다. 새 도구 계층을 평가할 때 가장 유용한 형식이다.

핵심 내용

문제: “문제는 텍스트 그 자체다”

기존 LLM을 자동화 파이프라인에 끼워 넣으면 늘 같은 곳에서 부러진다. 프로그램은 숫자나 구조화된 값을 기대하는데 모델은 산문을 돌려준다. TypeSafe 공동창업자 Diogo Almeida(전 OpenAI, 2022년 InstructGPT 논문 공저자)는 이를 “The problem is the text itself”라고 요약한다. 프롬프트로 “JSON만 출력해”라고 구슬리는 건 근본 해법이 아니라는 것이다.

Jev: 판단을 위해 훈련된 모델

Jev는 애초에 대화가 아니라 의사결정을 위해 설계됐다.

  • 평범한 영어로 된 (주관적이어도 되는) 질문을 받아 yes/no 확률 또는 카테고리 분포를 반환한다
  • 토큰을 하나씩 생성하는 방식이 아닌 “System One 아키텍처”로 동작한다 (이 아키텍처와 레이턴시의 기술적 의미는 자매편 Jev와 구조화 출력의 재발견에서 깊게 다룬다)
  • RLCD(Reinforcement Learning for Calibrated Decisions)로 훈련되어, 모델이 말하는 확신도가 실제 정답률과 맞도록 보정(calibration) 되어 있다
  • 가격은 10억 토큰당 42달러 — 통상적인 “백만 토큰당” 단가와 자릿수가 다르다. Almeida는 출력 토큰을 “too cheap to meter”(계량할 필요도 없이 싸다)라고 표현한다

TypeSafe의 철학을 압축한 문장이 인상적이다: “We’re building prod, not God.” 범용 지능이 아니라 프로덕션에 꽂히는 부품을 만든다는 선언이다.

저자의 테스트: 777개 판단, 0.7초, 0.25센트

실험 요약 — 37 × 21 = 777개 판단 매트릭스와 속도·비용·정확도 계기판 판단 매트릭스 문서 37편 → 질문 21개 → = 777개 판단 (37 × 21) 0.7초 속도 · 약 25배 빠름 ~0.25¢ 비용 · 약 580배 저렴 6 / 7 정확도 · 결함 7개 중 6개 검출
실험 요약 — 문서 37편 × 질문 21개 = 777개 판단. 0.7초, 약 0.25센트, 일부러 심어 둔 결함 7개 중 6개 검출.

저자는 자신이 쓴 진짜 아티클 27편에 AI 스타일로 쓴 10편을 섞어 37개 문서를 만들고, 글쓰기 품질에 대한 21개 질문을 동시에 던졌다. 질문은 이런 식이다.

  • “같은 아이디어를 근거 추가 없이 반복하는가?”
  • “억지로 대칭적인 ‘양쪽 다 일리 있다’ 논증을 만드는가?”
  • “뻔한 포인트를 과잉 설명하는가?”

결과: 777개의 판단이 0.7초에, 약 0.25센트로 처리됐다. 원문은 프론티어 모델 대비 약 25배 빠르고 580배 싸다고 비교한다. 정확도 검증을 위해 일부러 심어 둔 결함 7개 중 6개를 잡아냈다 — 완벽하진 않지만, 이 가격과 속도에서 이 정도면 얘기가 달라진다.

세 가지 활용 영역

저자는 총 11개 시나리오(코드 파일·사내 정책 찾기, 고객지원 답변 채점, 스타트업 피치 분류, 도움이 급한 고객 우선순위 매기기, “이건 CEO가 결정할 사안인가” 판정 등)를 실험한 뒤 활용처를 세 갈래로 정리한다.

  1. 컨텍스트 찾기 (Finding context) — 코드베이스에서 관련 파일 찾기, 해당되는 정책 문서 검색
  2. 작업 검사 (Checking work) — 응답 채점, 위험한 액션 플래깅, 콘텐츠 감사
  3. 의사결정 (Making decisions) — 우선순위 부여, 요청 분류, 선택 예측

고객서비스 라우팅이 전형적인 예다. “이 고객이 화나 있는가?”에 확률을 돌려받아, 임계값을 넘으면 에스컬레이션하는 코드를 그대로 짤 수 있다.

“지식 노동의 린터”

글의 가장 좋은 프레임이다. 코드 린터가 저장할 때마다 즉시 지적해 주듯, Jev급 속도·가격이면 지식 노동에도 작업 도중의 실시간 품질 피드백이 가능해진다. 다 쓰고 나서 리뷰받는 게 아니라, 쓰는 동안 계속 검사받는 것이다.

누가 써봐야 하나

저자의 권고는 절제되어 있다. 반복적인 판단 작업이 있는데 지금까지 속도나 비용 때문에 자동화하지 못했다면 시도해 보라 — 단, ① 이미 존재하는 판단 수요를 찾고, ② 자기 유스케이스에서 정확도를 직접 검증하고, ③ 그 결과에 따라 행동하는 것이 실제로 결과물을 개선하는지 확인하라는 조건이 붙는다.

분석과 인사이트

여기서부터는 원문 요약이 아니라 내 해석이다.

검증 비대칭에 대한 첫 번째 “가격 파괴” 응답

에이전트 시스템의 신뢰성 논의 — PRINCE 사례의 하니스 엔지니어링이든, 하니스의 필요충분조건이든 — 는 결국 “모델 출력을 누가, 얼마나 자주, 얼마의 비용으로 검사하느냐”로 수렴한다. 지금까지 검사자는 사람이거나 또 다른 프론티어 LLM이었고, 둘 다 비싸고 느려서 검사는 드문드문 배치될 수밖에 없었다. Jev의 제안은 검사 단가를 사실상 0으로 만들어 검사를 루프의 모든 스텝에 상시 배치하자는 것이다. “확률적 엔지니어링” 시대에 필요한 건 더 똑똑한 생성기가 아니라 값싼 판정기라는 직관과 정확히 맞물린다.

진짜 열쇠는 속도·가격이 아니라 보정(calibration)

25배 빠르고 580배 싸다는 숫자보다 중요한 건 RLCD, 즉 확신도가 실제 정답률과 일치하도록 훈련됐다는 부분이다. 보정이 안 된 확률은 임계값 기반 자동화에 쓸 수 없다 — 0.9라고 말하는데 실제로는 60%만 맞는 모델로는 에스컬레이션 정책을 짤 수 없기 때문이다. 보정이 유지된다면 “확률을 코드의 if문에 그대로 꽂는다”는 이 글의 전제가 성립하고, 그 순간 LLM 판단은 소프트웨어 부품이 된다. 다만 이건 벤더 주장이므로, 저자의 권고대로 자기 도메인 데이터로 보정 곡선을 직접 확인하는 게 도입의 선결 조건이다.

6/7이라는 숫자를 읽는 법

결함 7개 중 6개 검출은 훌륭하지만, 이 도구의 올바른 자리를 알려주는 숫자이기도 하다. 린터가 코드 리뷰를 대체하지 않듯, Jev는 최종 판정자가 아니라 상시 작동하는 1차 필터다. 놓친 1개는 사람(또는 더 비싼 모델)의 몫으로 남는다. 값싼 판정기의 가치는 정확도 그 자체보다, 비싼 검토 자원을 어디에 쓸지 정해 주는 triage에 있다.

단일 벤더 실사용기라는 한계

이 글은 저자 한 명의 테스트이고, 대상도 자기 글이라는 좁은 도메인이다. 적대적 입력(프롬프트 인젝션에 가까운 문서), 도메인 이동 시 보정 붕괴, “주관적 질문”의 애매함이 확률의 의미 자체를 흔드는 경우 등은 다뤄지지 않았다. “판단 특화 모델”이라는 계층이 진짜 성립하는지는 경쟁 제품과 독립 벤치마크가 나와야 판가름 난다. 다만 방향 자체 — 생성과 판정의 분리, 판정의 상품화 — 는 하니스 설계자 입장에서 충분히 주목할 가치가 있다.

적용 포인트

  • 파이프라인에서 “판단 지점”부터 목록화하라. 라우팅, 에스컬레이션, 채점, 우선순위 부여 등 지금 사람이나 프론티어 LLM이 하는 반복 판단이 후보다.
  • 확률 + 임계값 구조로 설계하라. 판정 모델의 출력을 boolean이 아니라 확률로 받고, 임계값과 폴백(사람/상위 모델 에스컬레이션)을 코드로 명시하면 벤더를 갈아 끼울 수 있다.
  • 도입 전 자기 데이터로 보정을 검증하라. 정답을 아는 케이스 수백 건으로 “모델이 0.8이라 할 때 실제로 80% 맞는가”를 먼저 확인한다.
  • 값싼 판정기는 triage로 써라. 최종 게이트가 아니라 1차 필터로 배치하고, 걸러진 소수만 비싼 검토(사람·프론티어 모델)로 보낸다.
  • “지식 노동의 린터” 실험을 해보라. 자기 글·문서·PR 설명에 “근거 없는 반복이 있는가?” 같은 질문 세트를 만들어 저장 시점마다 돌리는 워크플로는 지금 도구로도 흉내낼 수 있다.

마무리

이 글의 본질은 Jev라는 제품 리뷰가 아니라, 판단이 토큰이 아니라 확률로 상품화될 때 무엇이 가능해지는가에 대한 초기 관찰이다. 생성 모델의 시대가 “무엇이든 만들어 주는” 시대였다면, 다음 병목은 만들어진 것을 판정하는 쪽이고, 그 판정이 0.7초·0.25센트로 내려오는 순간 검사는 이벤트가 아니라 배경 프로세스가 된다. 코드에 린터가 그랬듯 — 도입 초기엔 시끄럽고 불완전하겠지만, 한번 상시화되면 없던 시절로 돌아가기 어려운 종류의 변화다.

더 읽어보기