김형 BLOG

토큰 생성 대신 확률적 결정을 내리는 AI: TypeSafe AI의 System One 모델과 Jev

16분 읽기 AILLMTypeSafeAIJevSystemOneRLCDStructuredOutputAutomation

토큰 생성 대신 확률적 결정을 내리는 AI: TypeSafe AI의 System One 모델과 Jev

지난 몇 년간 대규모 언어 모델(LLM)은 사람과의 채팅 영역에서 인간을 능가할 정도로 눈부신 발전을 이뤄냈습니다. 하지만 개발자가 소프트웨어 안에서 돌아가는 자동화 파이프라인—예를 들어 “이 거래를 자동 승인할 것인가?”, “이 보안 경보의 심각도는 몇 등급인가?”, “이 요청을 어느 백엔드 서비스로 라우팅할 것인가?”—을 구현하려 할 때, 여전히 사람은 불안해하며 모니터링 화면을 지켜보거나 복잡한 파싱 로직을 덧붙이곤 합니다.

그동안 우리는 이 문제를 해결하기 위해 함수 호출(Function Calling), JSON 모드, 구조화된 출력(Structured Outputs) 같은 기법을 동원해 텍스트 생성 모델에 스키마를 강제해 왔습니다.

하지만 OpenAI에서 ChatGPT의 기반이 된 인간 피드백 기반 강화학습(RLHF) 연구에 참여했던 Diogo Almeida가 설립한 TypeSafe AI는 전혀 다른 질문을 던집니다:

“소프트웨어 내부의 의사결정을 굳이 한 글자씩 텍스트를 생성하는 챗봇 모델로 처리해야 할까?”

2년간의 비공개 개발 끝에 공개된 첫 번째 System One 모델인 ‘Jev’는 텍스트 토큰을 생성하지 않고, 소프트웨어가 즉시 소비할 수 있는 타입이 정의된 확률적 결정(Calibrated Decisions)을 초저지연으로 출력합니다.

이 새로운 아키텍처가 왜 등장했는지, 기존 LLM과 무엇이 다른지, 그리고 개발자에게 어떤 의미가 있는지 깊이 있게 살펴보겠습니다.

1. 왜 새로운 모델 부류가 필요한가? (RLHF의 한계와 RLCD)

지금까지 사전 학습(Pre-trained)된 기본 언어 모델을 서비스에 맞게 정렬(Post-training)하는 방식은 크게 두 가지였습니다:

  1. RLHF (인간 피드백 기반 강화학습): 사람이 선호하는 대답을 하도록 보상 모델을 학습시켜 ChatGPT 같은 대화형 모델을 탄생시킴.
  2. RLVR (검증 가능한 보상 기반 강화학습): 수학 증명이나 프로그래밍 코드 채점처럼 명확한 정답이 있는 영역에서 모델의 다단계 추론(Reasoning) 역량을 극대화함 (예: OpenAI o1/o3 계열, DeepSeek-R1).
[언어 모델 사후 학습의 세 가지 경로]

1. 기본 언어 모델 ──(RLHF)──> 사람과 대화하는 챗봇 (ChatGPT, Claude)
2. 기본 언어 모델 ──(RLVR)──> 심사숙고 추론 모델 (System 2: o1, R1)
3. 기본 언어 모델 ──(RLCD)──> 빠르고 정확한 결정 모델 (System 1: Jev) ★

TypeSafe AI는 프로덕션 자동화 환경에서 RLHF의 구조적 취약점을 지적합니다.

모드 드로핑(Mode Dropping)과 불확실성 왜곡

RLHF는 인간 평가자가 선호하는 단 하나의 ‘무난하고 친절한’ 답변 패턴으로 확률 질량이 쏠리는 모드 드로핑(Mode Dropping) 현상을 유발합니다. GAN의 모드 붕괴(Mode Collapse)와 유사하게, 기본 모델이 가지고 있던 다양한 가능성과 미묘한 확률적 불확실성이 깎여 나가며 극단적인 과신(Overconfidence)이나 아첨(Sycophancy)이 발생합니다.

하지만 프로덕션 코드에서는 “이 판단이 80% 확률로 맞다”는 식의 정밀하게 보정된 확률(Calibrated Probability)이 필수적입니다. 확률 0.8로 예측된 사건이 실제로도 약 80% 빈도로 발생해야만, 개발자는 if confidence > 0.95:와 같은 임계값 기반의 안전한 자동 분기 로직을 작성할 수 있기 때문입니다.

이를 위해 TypeSafe AI가 제시한 제3의 사후 학습 방식이 바로 RLCD (Reinforcement Learning for Calibrated Decisions, 보정된 결정을 위한 강화학습)입니다. 텍스트 생성을 완전히 배제하고, 결정과 그에 수반되는 확률 분포 자체가 실제 정답률과 정확히 일치하도록 훈련하는 기법입니다.

2. 기존 LLM vs System One (Jev) 비교

System One 모델인 Jev를 가장 쉽게 설명하자면 “프런티어급 지능을 내장한 타입 안전한 함수 호출”입니다.

[기존 LLM의 구조화 출력]
비정형 입력 ──> [순차적 토큰 생성 (문자열)] ──> "{\"approved\": true, ...}" ──> JSON 파싱/검증 ──> 코드
                     (수 초~수십 초 소요 / 스키마 에러 & 환각 위험 상존)

[System One Jev의 구조화 결정]
비정형 입력 ──> [RLCD 기반 결정 엔진] ────> { approved: true, probability: 0.94 } ──> 코드 즉시 실행
                     (70ms~500ms 병렬 샘플링 / 태생적 환각 0%)

두 접근 방식의 기술적/비용적 차이는 다음과 같이 요약됩니다:

구분 기존 프런티어 LLM System One (Jev)
학습 방법 RLHF / RLVR RLCD (보정된 결정 학습)
최적화 목표 사람 선호 응답 / 검증 보상 정밀하게 보정된 확률적 결정
입력 형태 대화 메시지 중심 비정형 텍스트 프로그램 상태 중심 비정형 데이터
출력 형태 문자열 (파싱 및 스키마 검증 필수) 타입이 정의된 구조화된 값 + 확률 분포
샘플링 메커니즘 순차적 (토큰을 하나씩 자기회귀 생성) 병렬적 (단 1회 쿼리로 모든 질문 동시 평가)
지연 시간(Latency) 3초 ~ 수십 초 (토큰 수 비례 증가) 70ms ~ 500ms (초저지연 고정)
입력 토큰 비용 100만 토큰당 $0.20 ~ $10 100만 토큰당 $0.042 (수백 배 저렴)
출력 토큰 비용 입력 대비 약 3~5배 사실상 무료 (토큰 생성이 없음)
구조화 오류율 모델에 따라 최대 45.5% 오류 발생 0% (구조적으로 스키마 이탈 불가)

가장 주목할 점은 ‘병렬 샘플링’입니다. 기존 LLM은 이전 토큰에 의존해 다음 토큰을 생성하므로 질문이 많아지거나 응답이 길어질수록 대기 시간이 급증합니다. 반면 Jev는 여러 개의 독립적인 질문을 병렬 샘플러로 한 번에 처리하므로, 질문 개수를 늘려도 전체 응답 시간이 거의 늘어나지 않습니다.

3. Jev를 구성하는 3대 AI 기본 요소 (AI Primitives)

TypeSafe AI는 복잡한 프롬프트 엔지니어링 대신 소프트웨어의 원시 자료형(Primitive)에 대응하는 3가지 질문 타입을 제공합니다:

                  ┌── Choice: 목록 중 1개 선택 (값, 확률분포, 확신도)
Jev AI Primitives ├── Score : 기준에 따른 수치 채점 (점수, 확률분포, 확신도)
                  └── Noul  : 명제의 참/거짓 판정 (0 ~ 1 연속 확률값)
  1. Choice: 주어진 목록에서 가장 적절한 선택지를 고르고, 각 후보별 확률 분포와 확신도를 반환합니다. (예: 티켓 분류 [버그, 결제, 기능요청])
  2. Score: 정의된 기준에 따라 상태를 평가해 점수와 분포를 산출합니다. (예: 신용 위험도 평가 1~10)
  3. Noul: 특정 서술이 참인지 거짓인지 0과 1 사이의 보정된 확률값으로 판정합니다. (예: "이 영수증 이미지는 훼손 없이 식별 가능한가?")

설계 철학: “원자적(Atomic)으로 쪼개고 코드로 합성하라”

TypeSafe가 강조하는 핵심 아키텍처 규칙은 질문의 원자화입니다.

❌ 하나의 거대한 복합 프롬프트:
“이 스타트업의 IR 덱을 읽고 투자 타당성을 종합 평가해 점수를 매겨줘.”
➔ LLM이 각 요소를 어떻게 저울질했는지 블랙박스이며 가중치 수정도 어렵습니다.

⭕ 원자적 질문 분해 + 결정론적 코드 결합:

  1. Noul: 시장 규모가 1조 원 이상인가?
  2. Score: 창업팀의 기술적 실행 역량 점수 (1~5)
  3. Choice: 비즈니스 모델 유형 [SaaS, 커머스, 플랫폼]
  4. 코드(Python/TypeScript): final_score = 0.4 * q1 + 0.6 * q2
    ➔ 판단 기준이 바뀌면 프롬프트를 고칠 필요 없이 코드의 가중치 계수 하나만 변경하면 됩니다.

각 질문이 서로 독립적으로 병렬 평가되기 때문에, 질문을 여러 개 추가하더라도 앞선 질문이 뒤 질문을 오염시키는 컨텍스트 로트(Context Rot) 문제가 원천 차단됩니다.

4. 실전 아키텍처 패턴: 투기적 팬아웃(Speculative Fan-out)

TypeSafe의 초저지연·초저비용 특성은 기존 소프트웨어 설계 패턴을 완전히 바꿔 놓습니다. 대표적인 예가 ‘투기적 팬아웃(Speculative Fan-out)’입니다.

전통적인 조건부 프로그래밍이나 LLM 체이닝에서는 단계별로 분기를 확인한 뒤 다음 호출을 실행합니다:

[기존의 순차적 체이닝: 느림]
사용자 입력 ──> [1단계: 조명 관련인가?] ──(Yes)──> [2단계: 위치는 어디인가?] ──> [3단계: 켤까 끌까?]

하지만 Jev 환경에서는 모든 가능성 있는 질문을 처음부터 한 번의 API 호출에 모두 담아 병렬로 질의합니다:

[투기적 팬아웃 패턴: 100ms 컷]
                     ┌── Q1: 요청 카테고리가 무엇인가?
                     ├── Q2: 대상 공간은 어디인가?
사용자 입력 ─────────┼── Q3: 제어할 기기 종류는 무엇인가?
("거실 불 꺼줘")     └── Q4: 조명에 취할 동작은 무엇인가? (투기적 사전 실행)
                            │
                            ▼
               [코드 로직에서 Q1~Q3 조건 확인 후 Q4 값 즉시 채택]

요청이 조명에 관한 것인지 확정되기도 전에 조명 동작 질문(Q4)을 미리 던져두고, 조건이 맞지 않으면 코드에서 버리는 방식입니다. API 호출 비용이 사실상 무료에 가깝고 지연 시간이 병렬화되어 늘어나지 않기 때문에, 순차 호출보다 이 방식이 압도적으로 빠르고 단순합니다.

5. 생성형 LLM과의 이상적인 협업 구조

그렇다면 기존 LLM은 완전히 대체되는 것일까요? 아닙니다. TypeSafe는 Jev와 LLM이 상호보완적으로 작동하는 하이브리드 아키텍처를 제시합니다.

[하이브리드 지능 파이프라인]

              [ 사용자 입력 ]
                    │
                    ▼
          ┌───────────────────┐
          │  Jev (System 1)   │ ──(70ms 판별)
          │  빠른 분류 & 라우팅│
          └───────────────────┘
            │               │
  (정형화된 명령/판단)       (자유로운 대화/심층 추론)
            │               │
            ▼               ▼
   [ 즉시 내부 함수 실행 ]    [ LLM (System 2 / 챗봇) ]
   (결정론적 / 초저비용)       (자연어 생성 및 심층 추론)

스마트홈 데모나 고객 지원 파이프라인에서 대부분의 일상적인 요청은 Jev 단독으로 수십 밀리초 만에 처리하고, 복잡한 예외나 자유 대화가 필요한 소수의 케이스만 거대 LLM으로 넘김으로써 전체 시스템의 응답 속도와 서버 비용을 드라마틱하게 최적화할 수 있습니다.

6. 이름에 담긴 철학: 카너먼의 시스템 1과 제번스의 역설

TypeSafe AI의 작명에는 명확한 철학이 담겨 있습니다:

  1. System One:
    노벨경제학상 수상자 대니얼 카너먼의 저서 《생각에 관한 생각(Thinking, Fast and Slow)》에서 따왔습니다. 인간의 뇌에서 작동하는 빠르고 직관적인 ‘시스템 1(System 1)’과, 느리고 신중하게 계산하는 ‘시스템 2(System 2)’의 구분입니다. o1이나 R1 같은 모델이 시스템 2라면, Jev는 번개처럼 결정을 내리는 시스템 1을 지향합니다.

  2. Jev (제번스):
    19세기 경제학자 윌리엄 스탠리 제번스의 ‘제번스의 역설(Jevons Paradox)’에서 유래했습니다. 증기기관의 효율이 높아져 석탄 소비율이 떨어지자 오히려 산업 전반의 석탄 총소요량이 폭발적으로 늘어났던 것처럼, 지능(추론)의 단가가 극단적으로 낮아지면 소프트웨어 안에서 지능이 소비되는 총량은 수천 배로 폭증할 것이라는 믿음을 담고 있습니다.

7. 한계와 시사점: 개발자가 유의할 점

물론 스타트업이 자체적으로 설계한 벤치마크 결과를 해석할 때는 냉정한 시각도 필요합니다.

그럼에도 불구하고 Jev가 던지는 메시지는 매우 강력합니다:

“모든 AI 문제를 텍스트 생성 챗봇 프레임워크로 환원할 필요는 없다.”

수많은 엔지니어가 지금도 Pydantic 모델과 JSON 스키마, 수초의 지연 시간, 간헐적인 파싱 실패 에러와 싸우며 씨름하고 있습니다. 소프트웨어의 본질인 ‘타입 안전성’과 ‘확률적 판단’을 처음부터 모델의 훈련 목표(RLCD)로 삼은 Jev의 등장은, AI가 챗봇의 껍질을 벗고 소프트웨어 내부 엔진으로 완전히 녹아드는 중요한 변곡점이 될 것입니다.

🔗 관련 링크