글자를 포기한 모델 — TypeSafe의 Jev와 '시스템 원' 완전 해부

"번개를 병에 담았는데, 쓸모가 없다"

크게 보기

TechCrunch의 기사는 이 한 줄로 시작한다.

ChatGPT는 디오고 알메이다의 마음을 아프게 했다.

알메이다는 OpenAI에서 ChatGPT를 만드는 데 참여했고 RLHF/InstructGPT 논문의 주 저자 중 한 명이다. 그런데 그는 만족하지 못했다.

"우리는 번개를 병에 담았습니다. 그런데 그게 쓸모가 없어요." 알메이다가 TechCrunch에 말했다. "그 뒤로 계속 그 문제와 싸웠습니다. 결론에 도달하는 데 한참 걸렸어요 — 문제는 우리가 사람의 언어를 최적화하고 있다는 겁니다. 우리는 4년째 사람 언어를 아주 잘하고 있지만, 그건 자동화에는 쓸모가 없어요. 컴퓨터는 다른 언어를 쓰니까요."

2년 전 그는 OpenAI를 떠나 TypeSafe AI를 세웠다. 그리고 2026년 9월 15일, 첫 모델 Jev를 공개했다. 해커뉴스에서 1,924점과 504개의 댓글을 받았고, TechCrunch에 따르면 수요가 몰려 회사가 잠시 API를 서빙하지 못하는 일까지 벌어졌다.

이 모델의 특이점은 한 문장으로 끝난다. 글을 쓰지 않는다.

이 특집은 그 모델을 처음부터 끝까지 해부한다. 앞서 다룬 두 편 — 「가장 쓴 교훈」과 「RLHF 다음은 무엇인가」 — 이 왜 이런 걸 만들었는가를 다뤘다면, 이 글은 실제로 무엇을 만들었고 얼마나 믿을 수 있는가를 다룬다. 회사가 공개한 평가 데이터를 전부 옮겨 왔고, 거기서 회사가 강조하지 않은 것도 함께 읽는다.

1부 — 한 문장 요약: 문자열을 포기했다

입력과 출력

발표문의 표현은 이렇다.

Jev를 프런티어 지능 함수 호출이라고 생각하면 된다. 비정형 상태가 들어가고, 타입이 붙은 확률적 결정이 나온다.

크게 보기

구체적으로는 두 가지를 보낸다.

• 상태(state) — 판단의 재료. 문자열, JSON 객체, 문자열 배열 중 하나. 상담 대화 전체, 주문 기록, 환불 규정을 한 덩어리로 묶어 보낸다.
• 질문(questions) — 그 재료에 대해 내리고 싶은 판단들. 각 질문에는 타입과 가능한 답이 미리 정해져 있다.

돌아오는 것은 텍스트가 아니라 타입이 정해진 값 + 확률 분포 + 확신도다. 파싱이 없고, 재시도가 없고, 형식이 깨질 일이 없다.

아래에서 같은 업무를 두 방식으로 처리하면 코드가 실제로 무엇을 받아 드는지 비교해 보자. 마지막 칸(‘못 하는 것’)이 제일 정직하다.

제원

2부 — 질문은 세 가지 모양뿐이다

크게 보기

이 모델의 설계는 놀랄 만큼 단순하다. 던질 수 있는 질문이 세 종류밖에 없다.

Score의 답이 1.4처럼 등급 사이의 소수로 나오는 것이 중요하다. 세 단계로 정의해 놓으면 그 사이 어디쯤인지를 알려 준다. Noul에는 confidence가 따로 없다 — 돌아오는 숫자 자체가 확률이기 때문이다.

어느 걸 써야 하나 — 문서가 직접 경고하는 함정 두 개

세 개 중에 고르는 일은 쉬워 보이지만, 문서는 두 가지 함정을 명시적으로 경고한다. 직접 풀어 보자.

특히 두 번째 함정 — "이 지원자가 파이썬을 잘하는가?"를 Noul로 물으면 안 된다 — 는 이 모델을 쓸 때 가장 흔히 저지르는 실수다. Noul이 0.5를 돌려주면 그건 "실력이 중간"이 아니라 "예와 아니오가 반반"이라는 뜻이다. 해석이 불가능해진다.

3부 — 상태 하나, 질문 여러 개

재료와 판단을 분리한다

크게 보기

상태에는 내용과 근거가 들어가고, 질문에는 그 내용에 대해 내릴 판단이 들어간다. 이 분리가 설계의 뼈대다.

{
  "ticket": {
    "subject": "중복 결제",
    "messages": [
      {"from": "customer", "text": "A-104 주문이 두 번 결제됐어요. 중복 건 환불해 주세요."},
      {"from": "support", "text": "결제 내역 확인 중입니다."}
    ]
  },
  "order": {
    "id": "A-104",
    "charges": [
      {"amount": 49000, "status": "captured"},
      {"amount": 49000, "status": "captured"}
    ]
  },
  "refund_policy": "중복 결제 건은 환불 대상입니다."
}

대화와 주문과 규정이 한 덩어리로 들어 있다. 판단하려면 이 셋을 비교해야 하기 때문이다. 그리고 질문은 경로로 상태의 특정 부분을 가리킨다.

questions = {
    "refund_requested": Noul(
        instructions="`ticket.messages[0].text`가 환불을 요청하고 있는가?",
    ),
    "policy_supports_refund": Noul(
        instructions=(
            "`order.charges`를 고려할 때 `refund_policy`가 "
            "`ticket.messages[0].text`의 환불 요청을 뒷받침하는가?"
        ),
    ),
}

질문을 아낄 이유가 사라진다

크게 보기

한 요청에 질문을 여러 개 담을 수 있고, 모든 질문이 같은 상태에 대해 병렬로, 서로 격리되어 평가된다. 결과적으로 두 가지가 따라온다.

1. 질문을 추가해도 응답 시간이 거의 안 늘어난다. 상태를 한 번만 읽기 때문이다.
2. 질문끼리 오염되지 않는다. 한 질문의 답이 다른 질문의 숨은 맥락이 되지 않으므로, 질문을 넣고 빼도 나머지 결과가 바뀌지 않는다. 문서는 이를 "컨텍스트 부패(context rot)가 생기지 않는다"고 표현한다.

숫자로 보면 설계가 확 달라지는 이유가 보인다.

그래서 문서의 권고는 대담하다. 투기적 팬아웃(speculative fan-out) — 코드가 나중에 쓸지도 모르는 질문을 지금 전부 넣고, 쓸지 말지는 답을 받은 뒤에 정하라. 문의가 버그 신고가 아니면 ‘버그 심각도’ 답은 그냥 버리면 된다.

문서에는 이런 팁도 있다 — "코딩 에이전트가 사람보다 ‘호출 하나에 질문 하나’ 습관에 더 잘 빠진다." LLM 시절의 본능이 그대로 남는다는 뜻이다.

4부 — 규정 문단을 워크플로로

여기까지가 부품이다. 그럼 실제 업무는 어떻게 옮길까. 회사의 평가 사이트에 실린 장난감 예제가 이 변환을 가장 잘 보여 준다 — 팀이 문서에 써 놓은 규정 네 문장을 한 줄씩 뜯어서, 각 문장이 모델의 질문이 되는지 코드의 규칙이 되는지 가리는 것이다.

이 작업에서 진짜 어려운 부분은 코딩이 아니다. ‘분명히 맞지 않으면’을 네 단계로 정의하는 일, 그리고 문턱을 어디에 둘지 정하는 일이다. 다만 한번 정하고 나면 코드에 남아서 고칠 수 있고, 테스트할 수 있고, 누가 왜 그렇게 정했는지 기록된다. 프롬프트 문단 하나에 묻혀 있을 때와의 차이가 거기에 있다.

확신도로 문을 연다

앞선 글에서 자세히 다뤘으므로 짧게만 짚는다. 문서의 권장 패턴은 3구간 — 높으면 자동 실행, 중간이면 확인 후 진행, 낮으면 사람에게. 그리고 결정적인 원칙은 이것이다.

확신 임계값은 숫자 하나가 아니다. 같은 시스템 안에서도 행동마다 다른 수준에서 문을 걸어야 한다 — 틀렸을 때의 결과에 따라서.

문서의 음성 뱅킹 예제를 보면 잔액 조회는 0.6이면 충분하고, 이체 승인은 0.85를 넘어야 하며, 그 아래면 사용자에게 한 번 더 확인한다. 같은 모델, 같은 호출, 다른 문턱. (자세한 계산은 앞 글의 게이트 계산기에서 직접 만져 볼 수 있다.)

5부 — 증거물: 회사가 공개한 워크플로 평가

이제 가장 중요한 부분이다. 회사는 evals.typesafe.ai에 평가 결과를 공개해 놓았다. 그 데이터를 전부 옮겨 왔다.

어떻게 쟀나

평가 설계 자체가 이 회사의 주장을 그대로 반영한다.

실제 데이터

여기서 읽어야 할 세 가지

① 가장 유용한 발견은 Jev와 무관하다.

크게 보기

네 과제를 평균하면 모든 모델이 워크플로에서 더 정확하고, 더 싸고, 더 빠르다. 모델을 하나도 바꾸지 않고 정책을 질문들로 쪼갠 것뿐인데 그렇다.

haiku 4.5는 18.1% → 53.6%, 35.5%포인트가 뛴다. 같은 모델이다. 게다가 비용은 절반, 시간도 절반으로 줄었다. 이 결과에는 Jev가 전혀 필요 없다. 오늘 쓰는 LLM에 그대로 적용할 수 있는 이야기다.

다만 정확히 말해야 한다. 이 개선은 네 과제를 평균했을 때 성립한다. 개별 과제로 내려가면 예외가 있다 — DeepSeek v4 flash는 보안 경보 과제에서 워크플로(37.9%)가 프롬프트(44.6%)보다 오히려 나빴다.

② Jev는 정확도 1등이 아니다.

크게 보기

네 과제 평균 정확도로 줄을 세우면 이렇게 된다.

9개 설정 중 공동 4위(sonnet 5 워크플로와 동점)다. 1위 sol보다 6.3%포인트 낮다. 과제별로 내려가면 편차가 더 크다 — 고객 응대에서는 76.0%로 상위권이지만, 송장 처리에서는 61.8%로 뒤에서 두 번째다. 금액·수량·날짜 대조가 핵심인 과제인데, 이건 회사 문서가 스스로 밝힌 약점과 정확히 겹친다.

③ 그런데 가로축이 두세 자릿수 다르다.

정확도가 정확히 같은 sonnet 5 워크플로와 나란히 놓으면 이렇게 된다.

FAQ의 한 줄이 이 그림을 정확히 요약한다.

"Jev는 작지도 않고 LLM도 아닙니다. 그래서 지능 파레토 곡선 바깥에 있는 겁니다."

더 똑똑한 것이 아니라, 같은 똑똑함을 전혀 다른 가격표로 파는 것이다.

6부 — 193.6배·444.6배는 어디서 나온 숫자인가

회사 홈페이지의 큰 글씨는 "193.6배 빠르고, 444.6배 저렴하다"이다. 별표가 붙어 있다 — System One 과제 워크플로 기준.

위 데이터로 모델별 배수를 직접 계산하면 이렇게 나온다.

배수는 8배에서 440배까지, 25배에서 216배까지 벌어진다. 어느 모델과 비교하느냐가 전부다. 홈페이지의 두 숫자는 이 범위의 위쪽 끝에 가깝고, 공교롭게도 비용 최댓값은 opus 5, 시간 최댓값은 sonnet 5 — 서로 다른 모델에서 나온다.

7부 — 커뮤니티의 반론

크게 보기

발표문은 이렇게 시작한다 — "비범한 주장에는 비범한 증거가 필요하니, 아래에 영수증을 첨부한다. 💅" 좋은 태도다. 해커뉴스의 504개 댓글은 그 영수증을 꽤 꼼꼼히 읽었다.

가장 많이 지적된 것: "환각할 수 없다"는 과장이다

Jev가 만들 수 있는 건 구조화된 출력뿐 아닌가요? 분류·라우팅·점수 매기기에는 엄청나게 유용하겠지만, 우리가 코드와 자동화에 쓰는 생성 모델과는 전혀 다른 물건입니다. 그리고 "환각할 수 없다"는 틀린 것 같은데요? 잘못된 타입을 못 낼 뿐, 형식은 맞는데 완전히 틀린 값은 얼마든지 낼 수 있습니다. 게다가 적절한 하니스를 쓰면 LLM에도 구조화 출력을 강제할 수 있고요.

— 해커뉴스 사용자 jacobgold

정확한 지적이다. 선택지를 신규 / 수정 / 근거 부족으로 제한하면 엉뚱한 형식은 원천 차단되지만, 실제로는 수정 공고인데 신규를 고르는 오류는 그대로 남는다. "타입 안전"과 "환각 불가"는 다른 말이다.

속도 비교가 사과와 오렌지다

"70~500ms 대 3~329초"는 LLM 쪽이 비교 가능한 일을 하고 있을 때만 유효한 비교입니다. Jev가 생성을 아예 건너뛰고 좁은 구조화 과제만 한다면, 당연히 빠르죠. (…) 그래도 저는 이게 사실이길 바랍니다.

— 해커뉴스 사용자 ramon156

결국 제로샷 분류기 아닌가

기술적 추정도 여럿 나왔다. "인코더 중심(-ish) 트랜스포머에 스칼라·순서형 출력 헤드를 붙인 것으로 보인다", "본질적으로 원문 텍스트를 받아 프런티어 LLM만큼 정확하게 분류하는 제로샷 분류기", "LLM(Large Language Model)이라기보다 대형 분류 모델(Large Classification Model)". 다만 같은 사람들이 "그래도 내 파이프라인에 당장 쓸 데가 있다"고 덧붙인 것도 사실이다.

가장 날카로운 한 줄

Pi 하니스를 만드는 Earendil의 CTO 아르민 로나허가 TechCrunch에 한 말이다.

"결국 환각 문제를 사용자에게 조금 떠넘긴 셈입니다." 사용자가 이렇게 말해야 하죠 — 좋아, 이게 50% 확률로만 돌아온다면 그건 동전 던지기니까 무시하자. 하지만 95%라면, 그래 뭔가 할 수 있겠군.

떠넘기기가 반드시 나쁜 건 아니다. 떠넘길 수 있는 형태로 만들었다는 것 자체가 설계의 핵심이기 때문이다. 다만 그 말은 판단의 책임이 모델에서 우리 코드로 옮겨 온다는 뜻이기도 하다.

반대편: 실사용 보고

같은 기사에 실린 초기 사용자들의 보고는 구체적이다.

• Vercel의 소프트웨어 엔지니어는 명령어 안전성 검토용 분류기를 OpenAI의 Luna 5.6에서 Jev로 바꾼 뒤 5~18배 빠른 결과를 더 높은 정확도로 얻었다고 밝혔다.
• Bryo AI의 CTO는 업무 이메일 분류에서 Jev와 Gemini를 비교했는데, Gemini가 근소하게 더 정확했지만 10~20배 비쌌다. 그가 더 인상 깊어한 것은 확신도였다 — "진짜 확률을 돌려주는 건 이것뿐이고, 그래서 워크플로 자동화에 딱 맞다!!"
• 로나허는 또 다른 용도로 모델 라우팅을 꼽았다. 어떤 요청에 어떤 모델이 필요한지 미리 판정하는 일은 유용하지만 LLM으로 하면 비싸다. Jev의 비용과 속도면 실시간으로 가능하다는 것.

이 주장들을 등급별로 정리하면 이렇게 된다.

8부 — RLCD는 무엇인가 (그리고 무엇을 모르는가)

회사가 밝힌 것은 이름과 목표뿐이다. RLCD — Reinforcement Learning for Calibrated Decisions(보정된 의사결정을 위한 강화학습).

문서의 설명은 이렇다.

여러 예측에 걸쳐, 확률 0.2가 붙은 결과는 약 20% 비율로 일어나야 하고, 0.8이 붙은 결과는 약 80% 비율로 일어나야 한다. 이 비율은 예측의 집단에 대한 서술이지, 개별 답이 맞다는 보장이 아니다.

해커뉴스의 한 사용자가 남긴 설명이 가장 알기 쉬웠다.

RLCD에서는 기본적으로, 정답이 ‘아니오’였는데 {예: 0.9, 아니오: 0.1} 분포를 낸 경우에 큰 벌점을 주고, {예: 0.6, 아니오: 0.4}를 낸 경우에는 덜 준다. 설계에 들어가는 세부 사항이 많지만 대략적인 아이디어는 그렇다. ‘보정된 RL’이라는 이름으로 이미 알려진 것이고, 이걸 LLM 위에서 작동시키는 게 어려웠는데 다양한 용도에서 통할 만큼 다듬어 낸 것으로 보인다.

같은 흐름에서 이런 대비도 나왔다 — RLVR는 정답을 맞힌 사고 흐름 전체의 토큰 확률을 올리는 방식이라, 모델이 ‘80% 가능성’을 내도록 훈련하지 않는다. 그냥 맞히도록 훈련한다. RLCD가 다른 지점이 여기라는 것이다.

모른다고 말해야 하는 것들

9부 — 못하는 것들 (그리고 한국어 이야기)

크게 보기

이 회사에서 가장 인상적인 문서는 마케팅 페이지가 아니라 「Model jaggedness」다. 현재 모델의 실패 모드 아홉 가지를 실명으로 나열하고, 각각 대신 무엇을 하라고 적어 놓았다.

이 표는 "쓰지 마라"는 목록이 아니라 역할 분담표다. 5부에서 Jev가 송장 처리 과제에 약했던 이유가 2·3·4번에 그대로 적혀 있다.

한국어 사용자에게: 이 문단이 가장 중요하다

크게 보기

문서의 「Models」 페이지에 이런 문단이 있다.

같은 경고가 「State」 페이지에도 반복된다. 한국어 문서를 다루는 팀에게 이것은 선택적 주의사항이 아니라 전제 조건이다. 최소한 이 세 가지는 하고 시작해야 한다.

10부 — "벤치마크 점수는 내지 않겠습니다"

이 회사의 선택 중 가장 논쟁적인 것은 성능 수치가 아니라 성능 수치를 내지 않겠다는 선언이다.

크게 보기

FAQ의 답은 이렇다.

공개 벤치마크에 대한 성능을 의도적으로 공개하지 않기로 했습니다. 사실 제품 업데이트를 할 때 일회성 평가만 낼 계획입니다. (…) 모델의 새 영역을 여는 입장이니, 더 유용한 관행을 밀어 보려 합니다 — ① 공개 벤치마크에 가중치를 두지 말 것. ② 사용자가 자기 용도에 맞는 자체 평가를 만들도록 권할 것(System One 과제는 평가하기가 훨씬 쉽다). ③ 자기 평가의 단서를 공개할 것. ④ 앞서 있을 때조차 벤치마크를 덜 강조할 것.

이 입장의 근거는 출시 나흘 전에 올린 「Lies, Damned Lies, and Benchmarks」에 정리돼 있다. 요지는 벤치마크가 아니라 벤치맥싱(benchmaxxing)에 반대한다는 것이다.

벤치마크는 모델을 만드는 사람이 공개 평가 점수를 최적화할 수 있게 되는 순간 필연적으로 벤치맥싱된다. 직접 벤치마크로 학습시킬 필요도 없다. 비슷한 데이터로 학습시키거나, 백 가지 실험 설정을 돌려 보고 비교하기만 하면 된다. 누구도 게임을 의도하지 않아도, 벤치마크가 모델을 선택한다.

글이 드는 사례들이 구체적이다 — Meta의 Llama 4가 LMArena 상위권에 올랐는데 알고 보니 공개 모델이 아니었고 27개의 비공개 변형을 시험한 뒤 가장 좋은 것을 골랐다는 것, 어느 지수 제공사의 순위가 사흘 사이 세 번 개정되며 "사람들의 직관이 평가의 타당성을 결정하는" 되먹임을 보여 준 것, 한 중국 오픈웨이트 모델의 승리가 체리피킹으로 퍼진 것, 그리고 원 논문에서 비전문가 사람의 MMLU 점수가 34.5%였다는 것.

가장 인상적인 진단은 가로등 비유다.

이 분야는 일반 지능을 재고 싶어 하지만, 볼 수 있는 것만 최적화할 수 있다. 공개 평가가 그 가로등이다. 그래서 후학습은 불 밝은 구역에서 능력을 가장 빨리 밀어 올리고, 그 바깥의 신뢰성은 제자리거나 오히려 나빠질 수 있다. ‘들쭉날쭉한 지능’의 뾰족한 봉우리 상당수가 사실은 벤치마크라는 것이 내 주장이다.

11부 — 매니페스토: 말 없는 마차, SQL 이전의 데이터베이스

크게 보기

회사의 매니페스토는 제품 문서보다 야심이 크고, 비유가 좋다.

비유 ① 말 없는 마차

초기 자동차는 말 없는 마차로 설계됐다. 운송을 처음부터 다시 상상하는 대신, 익숙한 마차를 가져와 말을 모터로 바꾸고, 높은 좌석과 마차용 스프링을, 심지어 어떤 모델은 채찍 꽂이까지 그대로 남겼다. 새 기술이 자기만의 고유한 형태를 찾기 전에 대체 대상의 모양과 가정에 억지로 끼워 맞춰지는 전형적인 예다.

지금의 AI는 도움이 되고, 조리 있고, 상냥한 비서가 되도록 학습된다. 모델 반대편에 사람이 있다고 가정하면 합리적인 목표다. 그런데 그 예측 가능한 결과가, 배경에서 돌아가는 대신 사람을 루프에 요구하는 AI다.

비유 ② SQL 이전의 데이터베이스

데이터베이스를 만든 사람들은 구글을 상상하지 않았다. 인터넷 프로토콜을 만든 사람들은 스트라이프를 그리지 않았다. 그들은 저수준 능력을 배경에서 돌아갈 만큼, 그리고 그 위에 쌓아 올릴 만큼 믿을 수 있게 만들었을 뿐이다.

오늘의 지능은 SQL 이전의 데이터베이스 같다. 강력하지만 쓸 때마다 맞춤 제작이다. 똑똑한 결정 하나가 데이터베이스 질의만큼 믿을 만하고 호출 가능해지는 순간, 만드는 사람들은 그것을 똑같이 쌓아 올릴 것이다.

그리고 이어지는 문장이 이 회사의 안전관이다.

쌓아 올리기 위한 전제 조건이 안전이다. 믿을 만해야 감시 없이 돌리고, 신뢰할 만해야 그 위에 짓는다. 의존성을 시스템 다섯 층 깊이에 묻으려면 신뢰가 필요하다.

정리하면 이들이 하려는 것은 신경기호주의(neuro-symbolic AI)의 오래된 꿈 — 인식은 신경망이, 논리는 기호가 — 이고, 매니페스토 각주가 이를 장난스럽게 줄여 놓았다. "똑똑한 if 문(smart if-statements)."

로드맵은 세 단계다. ① 기계 친화적인 조합 가능한 AI의 형태를 달러당 지능이 가장 높게 출시한다 → ② 진짜 자동화로 경제를 바꿀 만큼 신뢰성을 올린다 → ③ 세상이 그 위에 쌓아 올릴 수 있는 높은 층위의 추상을 제공한다. 그들이 정의한 "경제 혁명"은 구체적이다 — 전 세계 총요소생산성(TFP) 성장률이 5년 안에 3%에 도달해 10년간 유지되는 것. 경제사에 전례가 없는 수치라는 점을 스스로 적어 두었다.

그리고 모든 문서에 반복되는 슬로건. "Build Prod, Not God" — 신을 만들지 말고 프로덕션을 만들라.

12부 — 그래서 우리 팀은 무엇을 해야 하나

오늘 당장 할 수 있는 것 (이 모델 없이도)

5부에서 확인했듯 가장 확실한 이득은 모델 교체가 아니라 구조 변경에서 나온다. haiku 4.5가 18.1%에서 53.6%로 뛴 것은 모델을 바꿔서가 아니라 정책 문단을 질문들로 쪼개서다.

이 모델을 실제로 검토한다면

생태계는 이미 움직이고 있다

출시 일주일 만에 벌어진 일들을 보면 이 흐름이 한 회사의 제품 이야기로 끝나지 않을 가능성이 보인다. 해커뉴스에는 LLM 위에 같은 인터페이스를 얹은 재구현(mini-jev), 자기 GPU에서 돌리는 오픈 대안, 의미로 행을 거르는 MySQL 플러그인, Vercel 게이트웨이를 통한 접근, 그리고 다른 팀이 내놓은 System One 모델군까지 잇따라 올라왔다. 로나허의 관측이 담백하다.

지금은 Jev가 이런 종류의 모델로는 혼자지만, 쓸모가 분명해진 이상 경쟁자가 나올 겁니다. 여러모로 우리는 이걸 더 일찍 봤어야 했는데, 아마 LLM이 워낙 싸고 보조금이 붙어 있다 보니 아직 창의적일 필요가 없었던 거겠죠.

마치며 — 인터페이스가 바뀌면 생각이 바뀐다

이 모델이 성공할지는 아직 모른다. 정확도는 1등이 아니고, 아키텍처는 비공개고, 가장 중요한 보정 주장은 외부 검증을 기다리는 중이고, 한국어 사용자에게는 별도의 숙제가 붙는다.

그런데 이 발표가 남긴 것 중 검증이 필요 없는 부분이 하나 있다.

우리는 지난 4년 동안 AI에게 말을 걸어 왔다. 프롬프트를 쓰고, 답을 읽고, 마음에 안 들면 다시 물었다. 인터페이스가 대화였기 때문에 문제도 대화의 형태로 생각하게 됐다 — 프롬프트를 어떻게 쓸까, 어떻게 더 잘 설명할까, 어떻게 페르소나를 줄까.

이 회사가 제안하는 인터페이스는 다르다. 판단 하나를 정의하고, 답의 모양을 정하고, 확률을 받아, 코드에서 분기한다. 그 인터페이스를 쓰려고 하는 순간 질문이 통째로 바뀐다.

오른쪽 질문들에 답하는 데에는 Jev가 필요 없다. 지금 쓰는 LLM으로도 오늘 시작할 수 있고, 5부의 데이터가 말하듯 그것만으로도 대부분의 이득이 나온다. 새 모델이 한 일은 그 질문을 피할 수 없게 만든 것에 가깝다.

말 없는 마차에서 채찍 꽂이를 떼어내는 일은, 결국 모터를 바꾸는 일이 아니라 마차를 다시 그리는 일이었다.

참고 자료

• TypeSafe AI, Introducing System One Models & Jev (2026-09-15)
• TypeSafe AI, Workflow evals — 이 글의 5·6부 수치는 전부 이 사이트에서 가져왔다
• TypeSafe AI 문서 — Introduction · System One · State · Primitives · Confidence · AI primer · Models · Model jaggedness · Patterns
• TypeSafe AI, Manifesto · Lies, Damned Lies, and Benchmarks (2026-09-11)
• TechCrunch, A new kind of AI model from a ChatGPT inventor is thrilling developers (2026-09-18)
• Hacker News, Introducing System One Models and Jev — 1,924점 / 504댓글. 7·8부의 인용은 이 토론에서 가져왔다
• Diogo Almeida, The Bitterest Lesson (2026-09-10)
• 관련 특집 — 가장 쓴 교훈 — 계산량보다 데이터, 데이터보다 '올바른 과제' · AI는 왜 미해결 수학은 풀면서 환불 처리는 못 맡기나 · RLHF 특집