의사결정 계층(Decision Layer): 타입 안정적 확률 모델이 밸리데이션된 쓰기 경로 외부에 위치해야 하는 이유

2026년 9월 15일, TypeSafe AI는 DCVC로부터 4,000만 달러 투자를 유치하며 스텔스 단계를 벗어나 Jev라는 모델을 공개했습니다. 2026년의 AI 출시치고는 매우 이례적일 정도로 명확한 콘셉트였습니다. Jev는 텍스트를 생성하지 않습니다. 프로그램 상태(state) 블록과 타입이 지정된 일련의 질문을 입력받아 확률 분포와 함께 타입이 지정된 값을 반환합니다. 문자열도 없고, 파싱도 없으며, 생성기 위에 억지로 얹은 JSON 스키마도 없습니다. TypeSafe가 내세운 주장들은 밸리데이션 책임자의 시선을 단번에 사로잡을 만한 내용이었습니다:

• 구조화된 출력 오류율 0% (0% structured output error rate). 스키마를 위반하는 것이 수학적으로 불가능합니다.
• 프론티어 모델의 문서화된 3329초 대비 엔드투엔드 **70500ms**의 처리 속도.
• 입력 토큰 100만 개당 $0.042, 출력은 무료 — “측정조차 불필요할 정도로 저렴함(too cheap to meter).”
• 캘리브레이션된 신뢰도(Calibrated confidence), 즉 0.95는 모델이 약 95%의 확률로 정답임을 의미.
• “환각(Hallucination) 없음.”

이 다섯 가지 주장 중 네 가지는 공식 문서를 통해 실제로 입증됩니다. 하지만 그중 하나는 모델이 감당할 수 있는 것보다 훨씬 과장되어 있으며, 규제 대상 환경의 배포에서 가장 중요한 숫자는 마케팅 페이지 어디에도 적혀 있지 않습니다.

이 글은 단순한 제품 리뷰가 아닙니다. 아키텍처에 관한 논증입니다: 의사결정 계층(Decision Layer)은 실재하며, 여러분의 참조 설계에 반드시 포함되어야 하지만, 밸리데이션된 쓰기 경로(write path)와의 경계는 실사(inspection) 도중 뒤늦게 발견되는 것이 아니라 사전에 신중히 설계되어야 합니다.

진정한 아키텍처적 전환

차이점은 “JSON이냐 아니냐”가 아닙니다. 두 접근 방식 모두 타입이 지정된 값을 반환합니다. 핵심적인 차이는 모델의 존재 목적에 있습니다.

구조화된 출력을 생성하는 기존 LLM은 여전히 어휘 사전에 마스크를 씌운 자기회귀(autoregressive) 생성기입니다. 모델은 {, ", d, e, p, a, r, t, m, e, n, t, "를 한 글자씩 써 내려가며, 스키마 제약 디코더가 이를 레일 위에서 이탈하지 않도록 붙잡아 줍니다. 스키마가 생성기 위에 사후 적용되는 구조입니다. 이는 제약과 검증을 제공할 뿐, 생성이라는 목적 자체를 바꾸지는 못합니다.

Jev는 이를 완전히 뒤집습니다. 호출 전에 답변 공간(answer space)이 미리 선언됩니다. 모델은 단 한 번의 순전파(forward pass)로 공유된 상태에 대해 선언된 모든 질문을 점수화하고 그 분포를 반환합니다. 문자열이 애초에 생성된 적이 없기 때문에 파싱할 문자열조차 존재하지 않습니다.

여기서 세 가지 결과가 직결되며, 이것이 바로 이 기술을 진지하게 검토해야 하는 이유입니다.

타입 안정성(Type safety)이 프롬프트에 기대는 희망 사항이 아닌 아키텍처적 보증입니다. TypeSafe는 이 점을 놀라울 정도로 솔직하게 밝힙니다. 0%라는 수치는 경험적 측정치가 아닙니다. 이들의 출시 자료에는 스키마 일치가 설계상 보장되므로 측정한 것이 아니라 그래프에 0%로 플롯했다고 명시되어 있습니다. 이는 반증 가능한 보증(단 하나의 반례만으로도 깨지는)이지만, 동작의 관측치가 아니라 형식에 대한 보증입니다. 이 차이는 밸리데이션 요약서(Validation Summary)를 작성할 때 매우 중요한 법적/기술적 의미를 갖습니다.

병렬 팬아웃(Parallel fan-out). 동일한 상태에 대한 모든 질문이 독립적이고 동시에 평가됩니다. 질문을 추가해도 지연 시간은 거의 늘어나지 않으며, 토큰 비용만 증가합니다. 반면 스무 개의 질문을 처리하는 기존 LLM 하네스는 20번의 순차적 생성을 대기해야 합니다. 공개된 데이터에서도 이러한 누적 차이가 확연히 드러납니다: 동일한 하네스에서 기존 LLM 기반 워크플로우가 케이스당 평균 78.1초가 걸린 반면, Jev는 0.4초에 불과했습니다.

신뢰도가 제어 신호(Control signal)가 됩니다. RLHF는 인간 평가자가 선호하는 응답을 최적화합니다. TypeSafe의 RLCD(Reinforcement Learning for Calibrated Decisions)는 결과에 대한 확률을 최적화합니다. 이것이 상업적 핵심 논거이자, 실제 아키텍처에서 가장 강력한 힘을 발휘하는 부분입니다.

마케팅이 객관적 증거를 앞서간 지점들

이것이 부정한 기만이라는 뜻은 아닙니다. TypeSafe는 대다수 벤더보다 훨씬 투명하게 주의사항을 공개하며, 출시 게시물의 모든 단일 주장 아래에 “뉘앙스(Nuance)” 콜아웃을 달아두었습니다. 그러나 차트 밑에 묻힌 벤더의 면책 문구는 조달 및 감사 과정에서 살아남지 못합니다. 여러분의 밸리데이션 문서에는 정직한 버전이 들어가야 합니다.

평가 데이터의 올바른 해석

Astra/Fable 합의점을 기준으로 채점된 4개 워크플로우 (모든 모델은 제공업체 기본 추론 설정 적용):

Jev는 Terra와 대등한 정확도를 유지하면서도 비용은 약 1/76 수준, 속도는 25배 빠릅니다. 지능 측면에서는 중간 수준이지만, 경제성 측면에서는 압도적입니다. 이것이 정확한 해석이며 매우 실질적인 결과입니다. 즉, 샘플링에 의존하던 판단 작업을 모든 단일 항목에 대해 실행하는 것이 경제적으로 가능해졌음을 의미합니다.

그러나 전체 평균값은 이 시스템을 실제 워크플로우에 배포할 수 있는지를 결정하는 핵심 요소를 가리고 있습니다:

정확도 페널티는 해당 작업이 얼마나 많은 다단계 추론(multi-hop reasoning)을 요구하는가에 직결됩니다. 청구서를 구매 주문서(PO) 및 입고 기록과 대조해야 하는 송장 처리 작업에서 성능은 급격히 무너집니다. 반면 단일 스레드를 좁은 범위에서 읽고 판단하는 대화형 라우팅에서는 강력한 경쟁력을 보이며 Opus 5를 넘어서기도 합니다.

이는 공식 문서에 명시된 한계와 정확히 일치합니다. Jev는 산술 연산, 카운팅, 날짜 계산을 수행할 수 없습니다. 날짜 추출 쿡북에는 모델이 텍스트가 명시한 부분만 읽고 “달력 계산은 절대 하지 않으며” 이를 코드에 위임한다고 명시되어 있습니다. 또한 범위와 부정어에 대해 지나치게 문자 그대로(literal-minded) 해석하며, 개방형 문자열을 추출하지 못합니다.

실무적 원칙: 벤더 기준이 아닌 워크플로우 단위로 평가하십시오. 고객 지원 대기열에서 2점 차이의 경미한 손실이었던 기능이, 매입채무 정산 작업에서는 17점의 심각한 퇴보로 이어질 수 있습니다.

모델 자체보다 더 중요한 발견

벤더 비교표 아래에는 Jev와 아무런 관련이 없는 놀라운 결과가 숨겨져 있습니다.

TypeSafe는 동일한 규정에 대해 모든 모델을 두 번씩 실행했습니다: 한 번은 단일 프롬프트 형태(“여기 규정이 있으니 케이스를 해결하라”), 다른 한 번은 워크플로우로 분해된 형태(분기 및 산술 연산은 코드에 남겨두고 원자적 타입 질문으로 쪼갠 형태)였습니다. 모델도, 작업도, 참조 라벨도 동일했습니다.

모든 단일 모델에서 성능이 대폭 향상되었습니다. 가장 저렴하고 약한 모델의 경우 35점이나 상승했습니다. 이는 작은 모델에서 실행되는 분해된 워크플로우가 모놀리식 프롬프트에 답변하는 프론티어 플래그십 모델보다 뛰어난 성능을 낼 수 있음을 증명합니다.

이러한 리팩토링은 비용이 들지 않고, 지금 즉시 적용 가능하며, TypeSafe의 제품을 구매할 필요도 없습니다. 이는 본 블로그의 게이트키퍼 패턴(Gatekeeper Pattern)이 반대 방향에서 도달했던 결론과 일치합니다: 확률론적 구성 요소에서 신뢰성을 확보하는 유일한 방법은 모델에 요구하는 의사결정 범위를 축소하고 밸리데이션 가능한 결정론적 코드로 로직을 옮기는 것입니다.

Jev 출시에서 얻어야 할 단 하나의 교훈이 있다면, 그것은 “Jev를 도입하라”가 아닙니다. 판단 작업을 결정론적 결합 구조를 가진 타입 기반 원자적 질문으로 분해하는 것이 프롬프트 기반 오케스트레이션보다 측정 가능할 정도로 우월하다는 사실이며, 한 벤더가 이 패턴을 전담하기 위해 모델 클래스 전체를 새로 구축했다는 점입니다.

GxP 스택에서 의사결정 계층이 위치해야 할 곳

다음은 권장 아키텍처입니다. 이 다이어그램의 핵심은 구성 요소가 아니라 **경계(boundary)**입니다.

   입력: 티켓 / 알람 / 일탈(Deviation) / 송장 / 문서 세트
                            │                                           
                            ▼                                           
                    ┌────────────────┐                                  
                    │  STATE BUILDER │  필터링, 정규화, 규정 첨부
                    │   (코드 구현)   │  불필요한 노이즈는 정확도를 떨어뜨림
                    └───────┬────────┘                                  
                            │                                           
                            ▼                                           
                    ┌────────────────┐                                  
                    │ DECISION LAYER │  Choice / Score / Noul 질문들
                    │  Jev 또는 SLM   │  병렬 점수화, 타입 출력 반환
                    └───────┬────────┘                                  
                            │  타입 응답 + 확률 분포 + 신뢰도
                            ▼                                           
                ┌───────────────────────────┐                           
                │  CONFIDENCE GATE (코드)   │  리스크 등급별 임계값 적용
                └────┬─────────────────┬────┘                           
                     │                 │                                
          높은 신뢰도 │                 │  낮은 신뢰도
                     ▼                 ▼                                
        ┌────────────────────┐   ┌──────────────────────────┐           
        │ DETERMINISTIC PATH │   │  ESCALATION PATH         │           
        │ 규칙 + 라우팅      │   │  인간 검토자, 및/또는     │           
        │ 밸리데이션된 쓰기   │   │  기록에 사유(rationale)를 │           
        │ 경로에 모델 배제   │   │  작성하는 추론 모델       │           
        └─────────┬──────────┘   └────────────┬─────────────┘           
                  │                           │                         
                  └─────────────┬─────────────┘                         
                                ▼                                       
                    ┌───────────────────────┐                           
                    │ POLICY ENGINE         │  결정론적 규칙
                    │ + 인간 승인(Human)     │  책임 권한을 가진 담당자
                    └───────────┬───────────┘                           
                                ▼                                       
                    ┌───────────────────────┐                           
                    │  GxP RECORD           │  ALCOA+ / 21 CFR Part 11  
                    │  + 전자서명(e-sign)    │  코드로 생성, 자격을 갖춘  
                    └───────────────────────┘  인간 담당자가 승인 서명

의사결정 계층은 밸리데이션된 쓰기 경로 외부에 위치합니다. 이 계층은 무엇이 주의를 기울일 가치가 있는지만 결정합니다. 배치 출하(batch disposition)와 같이 최종 기록되는 내용을 결정하지 않으며, 밸리데이션된 데이터 상태를 직접 수정하지 않습니다.

이러한 배치는 시스템의 본질적인 긴장을 명쾌하게 해결합니다. 기록은 결정론적 코드에 의해 생성되고 책임 있는 담당자에 의해 승인되며, 모델은 오직 라우팅 신호만 제공합니다. 결과적으로 밸리데이션 대상 표면적이 늘어나는 것이 아니라 축소됩니다: 재시도 루프를 가진 통제 불가능한 생성기 대신, 밸리데이션된 임계값, 밸리데이션된 질문 세트, 밸리데이션된 상태 빌더만 검증하면 됩니다.

게이트(Gate) 설정하기

TypeSafe의 공식 가이드는 훌륭한 출발점입니다. 신뢰도는 분포 형태에서 도출된 편의상 통계치이며, 사용자는 자체 측정 지표를 자유롭게 대체할 수 있습니다. 실제로 적절한 통계치는 워크플로우에 따라 달라지므로 직접 설정하는 것이 권장됩니다.

견고하게 작동하는 패턴은 편의가 아닌 결과의 중대성에 따라 조정되는 3단계 임계값 범위입니다:

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient()
response = client.system_one(
    model="jev-1.13.0",              # 별칭이 아닌 고정 버전을 지정할 것
    state=build_state(deviation),      # 필터링 적용: 무관한 내용은 정확도를 저해함
    questions={
        "category": Choice(
            instructions="이 일탈의 유형은 무엇인가?",
            criteria={
                "equipment": "장비 또는 기기 고장",
                "process": "공정 파라미터 이탈",
                "documentation": "기록 또는 문서 오류",
                "none_of_the_above": "위 카테고리 어디에도 해당하지 않음",
            },
        ),
        "data_integrity_impact": Noul(
            instructions="해당 일탈이 GxP 기록의 정확성 또는 완전성에 영향을 미칠 수 있는가."
        ),
    },
)

cat = response.answers["category"]
di = response.answers["data_integrity_impact"]

# 실제로 응답한 모델 버전을 기록 (별칭은 변경될 수 있음)
audit({"model": response.model, "category": cat.choice,
       "distribution": cat.probabilities, "confidence": cat.confidence})

# Noul 기본형에는 신뢰도 필드가 없음. 확률 값 자체를 게이트로 사용.
if di.noul > 0.5:
    escalate_to_qa()                      # 데이터 무결성 신호는 예외 없이 인간에게 전달

elif cat.confidence >= 0.90:
    route_automatically(cat.choice)        # 위험도가 낮은 트리아지 작업에만 자동 라우팅 허용

elif cat.confidence >= 0.50:
    queue_for_review(cat.choice)           # 권고안만 제시하고 직접 조치하지 않음

else:
    route_to_human()                        # 모델 스스로 판단할 수 없음을 선언한 상태

위 코드 스니펫에서 규제 환경상 타협할 수 없는 4가지 원칙이 있습니다:

1. 모든 Choice에 none_of_the_above 탈출구 마련. 확률 질량은 어디론가 분배되어야 합니다. 정답이 목록에 없는데 강제로 선택하게 만들면 조용한 오류(silent error)가 발생합니다.
2. 버전을 고정(Pinning)하고 버전을 기록(Log)할 것. 현재 jev-latest는 jev-1.13.0을 가리키지만 새로운 릴리스가 배포되면 자동으로 변경되며, 이는 튜닝해 둔 임계값 아래에서 답변을 바꿔놓을 수 있습니다. 모델 ID를 고정하고 반환된 model 필드를 감사 추적(Audit Trail)에 기록하십시오.
3. 작업별로 상이한 임계값 적용. 계좌 잔액을 조회하는 것과 결제를 승인하는 것은 전혀 다른 수준의 리스크입니다. 게이트는 조직의 리스크 허용도를 코딩한 것이므로, 밸리데이션의 핵심 대상은 바로 이 게이트입니다.
4. Noul에는 신뢰도 필드가 없음. 확률 자체를 기준으로 게이팅해야 하며, 해당 임계값은 신중하게 설정해야 합니다. 데이터 무결성(Data Integrity) 질문의 경우 극히 미미한 수준을 넘어서는 모든 신호는 인간 검토자에게 에스컬레이션되어야 합니다.

의사결정 계층이 수행할 수 없는 것들

• 사유(Rationale)를 입증하거나 설명하는 일. 근거 설명은 절대 제공되지 않습니다. 신뢰도 숫자는 사유가 아닙니다. SOP상 조치 사유를 설명해야 한다면 그 설명은 다른 컴포넌트에서 나와야 합니다. 아키텍처 다이어그램에 에스컬레이션 경로가 존재하는 이유가 바로 이것입니다.
• 산술 연산이나 카운팅. 총계, 날짜 차이, 수량 계산은 코드 내부에서 처리되어야 합니다. TypeSafe의 공식 날짜 쿡북조차 모델이 달력 계산을 수행하지 못하도록 엄격히 제한합니다.
• 무제한 값 추출. 사전에 열거할 수 없는 항목은 Choice의 선택지가 될 수 없습니다.
• 다단계(Multi-hop) 질문 처리. 암시적이거나 중첩되어 있거나 부정어가 많이 포함된 프롬프트는 정확도를 떨어뜨립니다. 질문을 쪼개거나 다른 계층으로 옮겨야 합니다.
• 노이즈가 심한 상태 블록에서의 생존. 무관한 내용이 쌓일수록 정확도는 저하됩니다. 상태 필터링은 모델이 아닌 코드의 책임입니다.
• 프롬프트 주입(Prompt Injection) 방어. 상태 내부의 텍스트가 답변을 유도할 수 있습니다. TypeSafe는 적대적 콘텐츠에 대응하기 위해 개선 중이지만 현재로서는 열려 있는 리스크입니다. 신뢰할 수 없는 데이터가 의사결정 계층에 도달하기 전에 반드시 적대적 입력 테스트를 거쳐야 합니다.
• 보유 데이터에 대한 캘리브레이션 입증. TypeSafe는 신뢰도 다이어그램이나 브리어 점수(Brier score)를 공개하지 않았습니다. 캘리브레이션은 벤더의 평가 분포에 대한 종합적 특성일 뿐, 여러분의 실제 워크로드에 대한 속성이 아닙니다.

도입 전 평가 프로토콜

Jev이든 다른 솔루션이든, 의사결정 계층을 규제 워크플로우에 적용하기 전에 다음 6단계를 수행해야 합니다:

1. 섀도 모드(Shadow mode), 라벨링된 실제 데이터 20~50건. 기존 프로세스와 의사결정 계층을 병행 실행합니다. 정확도, 비용, 지연 시간, 그리고 고정된 신뢰도 임계값에서의 정확도를 비교합니다. 이 마지막 수치가 자율 실행의 타당성을 입증하는 기준이며, 벤더 차트에서 빌려올 수 없습니다.
2. 워크플로우 단위 측정. 송장 작업에서의 17점 격차와 고객 지원 작업에서의 −2.3점 격차는 완전히 동일한 모델에서 발생했습니다. 평가의 최소 단위는 항상 워크플로우여야 합니다.
3. 적대적 입력(Adversarial input) 테스트. 상태 내부에 명령어를 주입해 봅니다. 이 계층이 공급업체 문서, 고객 메시지, 감사 지적사항 등에 노출된다면 이는 선택이 아닌 필수 절차입니다.
4. 버전 안정성 검증. 설정한 임계값에 의존하기 전에, jev-1.13.0과 다음 릴리스 사이에서 답변이 얼마나 변동하는지 사전 확인하십시오.
5. 데이터 처리 및 보관 규정 확인. 도입 요금제에 적용되는 데이터 보존 약관을 확인하십시오. 고객 요청 데이터로 학습하지 않으며 엔터프라이즈 고객 대상 데이터 무보존(Zero Data Retention)이 안내되고 있으나, 전송하려는 콘텐츠에 대한 계약서 조항을 반드시 직접 검토해야 합니다.
6. 모델뿐만 아니라 임계값 자체를 밸리데이션할 것. 통제 수단은 임계값입니다. 설정 근거와 함께 밸리데이션 문서에 명시되어야 하며, 임계값이 변경될 때 변경 제어(Change Control) 절차를 거쳐야 합니다.

요약

이 시스템의 명쾌한 프레임워크는 관심사의 4계층 분리에 있습니다:

LLM    = 추론 및 생성 기본 요소
         (작성, 설명, 초안 작성, 사유 생성)

Scorer = 확률론적 의사결정 기본 요소
         (분류, 라우팅, 점수화, 게이팅 — 모든 곳에 상시 적용 가능할 만큼 경제적)

Code   = 결정론적 통제 기본 요소
         (산술 계산, 임계값 판정, 조건 분기, 감사 추적 기록)

Human  = 권한과 책임
         (승인, 최종 처분 결정, 전자서명)

Jev는 두 번째 계층을 본격적으로 구현한 결과물이며, 타입 안정성 보증은 프롬프트 엔지니어링으로는 결코 재현할 수 없는 진정한 아키텍처적 강점입니다. 그러나 중요한 본질은 그 아키텍처적 통찰 자체이며, 이는 오늘날 당장 적용 가능합니다: 판단을 타입 기반의 원자적 질문으로 분해하고, 로직은 코드에 유지하며, 신뢰도에 따라 게이트를 걸고, 시스템이 확신할 수 없는 모든 사안을 인간에게 에스컬레이션하십시오.

이 결정을 내릴 때 두 가지 숫자를 기억하십시오. 첫 번째는 +8.3%p입니다. 모델을 변경하기 전, 동일한 정책 문서를 워크플로우로 분해하는 것만으로 Claude Opus 5가 얻어낸 순수 성능 향상분입니다. 두 번째는 $0.0004입니다. 표본 조사가 아닌 모든 개별 기록에 대해 의사결정 판단을 상시 수행할 수 있게 해주는 케이스당 실행 비용입니다.

첫 번째는 비용이 들지 않으며 현재 프로덕션에서 실행 중인 모델에 즉시 적용 가능합니다. 두 번째는 의사결정 계층을 애초에 구축할 가치가 있게 만들어주는 결정적 이유입니다.

연구 노트: [[TypeSafe-Jev-System-One-Models-vs-LLM-Structured-Output-2026]]

참고 자료: TypeSafe AI 출시 블로그 · TypeSafe 워크플로우 평가 데이터 · TypeSafe 개발자 문서 (Models, Confidence, Date extraction) · RuntimeWire 출시 기사 · DCVC 발표