TypeSafe Jev는 에이전트 파이프라인 어디에 넣어야 할까 2026 – 스크립트·System 1·LLM 분기점 지도

Posted on by

TypeSafe AI가 2026년 9월 15일 발표한 Jev 소식을 보고 제일 먼저 든 질문은 “이게 빠르고 싸다는 건 알겠는데, 내 파이프라인에서는 어느 칸에 들어가야 하지?”였습니다. 저는 옵시디언 볼트 안에서 블로그 글감 선정부터 검수, 발행까지 도는 에이전트 파이프라인을 운영하고 있고, 그 안에는 매일 수십 번씩 “다음에 뭘 할지”를 정하는 분기가 있습니다. 그래서 Jev 스펙을 공식 문서로 확인한 다음, 제 파이프라인의 실제 분기점에 하나씩 대입해 봤습니다.

미리 경계부터 밝혀 두면, Jev는 아직 얼리 액세스 대기열 단계라 이 글을 쓰는 시점에 직접 API를 호출해 보지는 못했습니다. 이 글은 사용 후기가 아니라 공식 스펙과 제 운영 기록을 나란히 놓고 “붙일 자리를 어떻게 고르는가”를 정리한 학습 노트입니다. 결론이 바뀔 수 있는 지점은 마지막에 따로 적었습니다.

Jev가 공식적으로 무엇인지부터

Jev는 텍스트를 생성하지 않는 모델입니다. TypeSafe AI 공식 블로그 설명에 따르면 비정형 입력과 프로그램 상태, 그리고 타입이 정해진 질문을 받아서 선택지(choices), 점수(scores), 예/아니오 판정을 반환하고, 모든 출력에 보정된(calibrated) 확률이나 신뢰도를 함께 붙입니다. 토큰을 하나씩 이어 쓰는 자기회귀 방식이 아니라 한 번에 결정을 내놓는 구조라서, 대형 LLM이 “다음 행동”을 문장으로 설명하게 한 뒤 그 문장을 다시 파싱하는 과정이 통째로 사라집니다.

가격은 입력 100만 토큰당 0.042달러이고 출력은 무료입니다. 속도는 공식적으로 비교 가능한 System One 작업에서 40배에서 200배 빠르다고 적혀 있고, 응답 시간은 70~500밀리초 수준으로 제시돼 있습니다. 흔히 돌아다니는 “200배 빠르고 400배 싸다”는 표현은 특정 워크플로 평가에서 나온 193.6배, 444.6배라는 상단 사례를 반올림한 것이라, 일반적인 기대치로 쓰면 과장입니다.

제 판단에 가장 큰 영향을 준 건 속도가 아니라 제한 사항이었습니다. 공식 모델 문서에는 요청당 64k 토큰 한도, 텍스트 전용 입력, 그리고 영어가 가장 잘 지원되고 다른 언어는 처리하되 정확도가 낮다는 설명이 붙어 있습니다. 제 파이프라인의 입력은 거의 다 한국어라서, 이 한 줄이 도입 판단의 첫 번째 필터가 됐습니다.

내 파이프라인의 분기는 이미 대부분 스크립트가 한다

대입해 보기 전에 현재 상태를 셌습니다. 볼트의 .claude/scripts 폴더에는 파이썬 스크립트가 232개 있고, 그중 이름에 gate, guard, router가 들어간 판정용 스크립트가 26개입니다. 발행 가능 여부, 채널 비중, 초안 해시 일치, 필수 메타데이터 유무 같은 판단은 LLM이 아니라 이 스크립트들이 숫자와 필드로 결정합니다.

오늘 실제로 이게 어떻게 작동했는지 보면 감이 옵니다. 블로그 후보 12개를 파이프라인에 넣었더니, 아이디어 게이트와 채널 슬롯 게이트가 LLM을 한 번도 부르지 않은 상태에서 12개를 전부 막았습니다. 필수 증거 필드가 비었거나 직전 7일 채널 비중이 상한을 넘었다는 이유였고, 둘 다 규칙이 명확해서 모델에게 물어볼 필요가 없는 판단이었습니다.

반대 방향의 실패 기록도 있습니다. 아침 브리핑 계약서에는 2026년 9월 15일과 16일 이틀 연속으로 LLM 워커가 채널 비중을 재고 구성비로 잘못 판정해서, 그 워커 자체를 폐지하고 스크립트 출력으로 대체했다는 기록이 남아 있습니다. 숫자로 계산할 수 있는 판단을 모델에게 맡기면 빠르고 싼 모델이든 비싼 모델이든 틀릴 여지를 만든다는 게 그때 얻은 교훈이었습니다.

그래서 Jev를 대입할 때 제 첫 번째 규칙은 “규칙으로 쓸 수 있는 분기에는 Jev도 넣지 않는다”가 됐습니다. 초당 수백 건을 싸게 판정해 준다고 해도, 스크립트는 공짜이고 항상 같은 답을 내고 틀리면 코드에서 원인을 찾을 수 있습니다. 보정된 확률은 좋은 기능이지만, 확률이 필요 없는 판단에 확률을 붙이는 건 복잡도만 늘립니다.

분기점 지도: 세 칸으로 나눠 보니

제 파이프라인의 실제 분기를 입력 형태와 선택지 형태로 나눠 보면 세 칸이 나옵니다. 입력이 숫자나 필드이고 규칙이 명확하면 스크립트, 선택지는 닫혀 있는데 입력이 자유 텍스트면 System 1 후보, 답 자체를 만들어야 하면 LLM입니다.

분기 입력 선택지 지금 처리 맞는 칸
채널 슬롯 게이트 직전 7일 발행 비중 GO / HOLD 스크립트 스크립트 유지
아이디어 게이트 원장 필드 유무 통과 / 보류 스크립트 스크립트 유지
발행 직전 해시 확인 초안 SHA-256 ship / 되감기 스크립트 스크립트 유지
미리알림 캡처 라우팅 한 줄 메모 텍스트 일정 / 할일 / 로그 / 위시 / URL 요약 / 잔류 sonnet 에이전트 System 1 후보
인박스 트리아지 노트 본문 AUTO / DECIDE / DEFER sonnet 에이전트 System 1 후보
리서치·팩트체크 웹 문서 없음(서술) sonnet 서브에이전트 LLM 유지
초안 작성·의미 검수 초안 전체 없음(판단 근거 서술) LLM LLM 유지

표로 그려 놓고 보니 Jev가 들어갈 자리는 생각보다 좁았습니다. 26개 게이트 스크립트는 전부 첫 번째 칸이고, 리서치와 작성과 검수는 세 번째 칸입니다. 가운데 칸에 남는 건 미리알림 캡처 라우팅과 인박스 트리아지처럼 “선택지는 여섯 개 이하로 정해져 있는데, 판단 재료가 사람이 대충 적은 한 줄 메모”인 구간입니다.

이 가운데 칸이 바로 지금 sonnet 에이전트가 규칙 문서를 읽어 가며 판정하는 곳입니다. 규칙 문서에는 “날짜·시간·고유명사가 모호하면 추측하지 않는다”, “애매하면 잔류한다” 같은 조건이 적혀 있는데, 이건 결국 신뢰도가 낮으면 사람에게 넘기라는 뜻입니다. Jev가 확률을 붙여 주는 구조와 개념적으로 잘 맞는 이유가 여기 있습니다.

가운데 칸에 대입해 본 설계안

직접 호출은 못 했으니, 공식 문서에 나온 필드 이름(state, questions, choices)만 빌려서 미리알림 라우팅을 어떻게 한 번의 결정으로 표현할지 설계해 봤습니다. 아래는 실제 API 스키마를 그대로 옮긴 게 아니라 문서의 개념을 제 파이프라인에 맞춰 적은 설계 메모입니다.

{
  "state": {
    "memo": "금요일 7시 아이 수영 픽업",
    "today": "2026-09-19",
    "has_explicit_date": true
  },
  "questions": [
    {
      "id": "route",
      "type": "choice",
      "choices": ["calendar", "task", "daily_log", "wish", "url_summary", "keep_in_inbox"]
    }
  ]
}

이렇게 두면 호스트 프로그램 쪽 규칙은 단순해집니다. 최상위 선택지의 신뢰도가 기준값 이상이면 그 목적지로 보내고, 기준값 미만이면 지금 규칙 문서처럼 “잔류”로 남겨 사람이 봅니다. 날짜 파싱이나 캘린더 중복 확인처럼 규칙으로 되는 일은 여전히 스크립트가 맡고, Jev는 “이 한 줄이 일정인가 할일인가”라는 좁은 판단만 합니다.

비용도 가정을 명시하고 계산해 봤습니다. 판정 한 번에 메모와 요약 규칙, 질문을 합쳐 입력 3,000토큰이 든다고 가정하면, 0.042달러 × 3,000 ÷ 1,000,000 = 약 0.000126달러입니다. 하루 30건씩 한 달 900건을 판정해도 약 0.11달러라서, 이 구간에서는 비용이 도입 판단의 변수가 아니게 됩니다. 남는 변수는 정확도와 한국어 처리 품질뿐입니다.

그래서 지금 붙일까: 내 판단과 남은 질문

지금 당장은 붙이지 않고 검증 계획만 세워 두기로 했습니다. 이유는 세 가지입니다. 얼리 액세스라 바로 쓸 수 없고, 공식 문서가 영어 외 언어의 정확도가 낮다고 밝히고 있으며, 가운데 칸의 판정 건수가 하루 수십 건 수준이라 지연 시간이 병목이었던 적이 없습니다. Jev의 200배 속도는 초당 수백 건을 판정하는 서비스에서 크게 체감될 이점이고, 개인 볼트 자동화에서는 한국어 정확도가 더 중요합니다.

대신 접근권이 생기면 바로 돌릴 실험은 정해 뒀습니다. 지난 미리알림 캡처 기록 중 사람이 최종 목적지를 확정한 항목을 모아 정답셋을 만들고, 같은 입력을 Jev에 넣어 선택지 일치율과 신뢰도 구간별 정확도를 봅니다. 신뢰도가 높을수록 실제로 더 잘 맞는지, 즉 공식 문서가 말하는 보정이 한국어 메모에서도 유지되는지가 핵심 확인 항목입니다.

이번에 정리하면서 바뀐 생각은 하나입니다. 처음에는 “비싼 LLM이 하던 라우팅을 싼 모델로 바꾸면 이득”이라고 단순하게 봤는데, 실제 분기를 세어 보니 라우팅의 대부분은 이미 LLM이 아니라 스크립트가 하고 있었습니다. Jev 같은 System 1 모델의 자리는 LLM과 스크립트 사이의 좁은 틈, 즉 선택지는 닫혀 있지만 입력이 규칙으로 안 잡히는 구간입니다. 그 틈이 얼마나 넓은지는 파이프라인마다 다르니, 도입 전에 자기 분기점부터 세어 보는 게 순서라고 생각합니다.

FAQ

Q1. Jev는 LLM을 대체하나요?

A: 아닙니다. 공식 설명상 Jev는 선택지·점수·예/아니오 같은 타입이 정해진 결정만 반환하고 자유 텍스트를 생성하지 않습니다. 코드 작성이나 문서 생성, 열린 계획 수립은 여전히 LLM 영역입니다.

Q2. 가격은 얼마인가요?

A: TypeSafe AI 공식 발표 기준 입력 100만 토큰당 0.042달러이고 출력은 무료입니다.

Q3. 200배 빠르다는 말은 사실인가요?

A: 공식 수치는 비교 가능한 System One 작업에서 40배에서 200배 빠르다는 범위입니다. 193.6배, 444.6배는 특정 워크플로 평가의 상단 사례입니다.

Q4. 한국어 입력도 되나요?

A: 공식 모델 문서는 영어가 가장 잘 지원되고 다른 언어는 처리하되 정확도가 낮다고 설명합니다. 한국어 파이프라인이라면 정답셋으로 먼저 검증하는 것이 안전합니다.

Q5. 지금 바로 쓸 수 있나요?

A: 발표 시점 기준 얼리 액세스 대기열로 개발자를 받는 단계입니다.

관련 글

참고 자료