LLM 위키

시스템 원 모델 (System One)

갱신 2026-09-22

한눈에 요약

왜 이런 모델이 필요한가

질문이 하나 있다. LLM이 아니라면 대체 어떤 모델이라는 건가?

출발점은 불일치다. LLM은 사람이 읽을 텍스트를 만들도록 설계된 물건이다. 그런데 코드가 써야 할 판단이 필요해지면, 텍스트 생성기를 억지로 구조화된 결정으로 밀어 넣고 그 결과를 다시 파싱해 코드가 의지할 수 있는 무언가로 되돌려야 한다 52.

쉽게 말하면 이렇다. 소프트웨어는 앞 단계의 결과를 뒷 단계가 이어받는 식으로 돌아가니, 주는 쪽과 받는 쪽이 결과물의 모양을 미리 약속해 둬야 한다. 자연어는 그 약속이 없는 형식이다 54.

시스템 원 모델은 그 약속을 모델 쪽에서 지키게 만든 설계다. 답의 후보 공간을 내가 정하고, 모델은 그 안에서만 답한다 52.

LLM과 무엇이 다른가

가장 큰 차이는 생성하지 않는다는 점이다. 시스템 원 모델은 답장을 쓰지도, 코드를 만들지도, 자기 추론 과정을 설명하지도 않는다 52.

축 LLM 시스템 원 모델
자연어 입력 이해 한다 한다
출력 생성된 텍스트(토큰을 차례로) 타입이 정해진 값 + 확률 분포
답의 범위 열려 있다 내가 준 선택지·레벨·참/거짓으로 닫혀 있다
코드가 받는 방식 파싱해서 복원 그대로 분기·정렬·라우팅
대표 용도 글·코드·설명 생성 분류·라우팅·점수 매기기·가드레일

자세한 비교와 "언제 무엇을 쓰나"는 Jev vs LLM vs 코드에서 따로 다뤘다. LLM 쪽 배경이 필요하면 LLM 기초를 먼저 보면 된다.

학습 경로 — RLHF·RLVR·RLCD

사전학습을 마친 언어모델은 사후학습(post-training)에서 갈래가 나뉜다. 사후학습이란 이미 다음 단어를 잘 맞히게 된 모델을 어떤 쓰임에 맞게 다시 다듬는 단계를 말한다.

문서는 세 갈래를 이렇게 정리한다 52.

경로 풀이 만들어 내는 것
RLHF 사람 피드백 기반 강화학습 사람이 선호하는 응답을 내놓는 챗봇
RLVR 검증 가능한 보상 기반 강화학습 수학 같은 과제에 강하지만 느리고 비싼 추론 모델
RLCD 보정된 결정을 위한 강화학습 텍스트 대신 결정과 보정된 확률을 돌려주는 모델

TypeSafe가 택한 경로가 RLCD다. RLCD가 최적화하는 출력 계약은 세 줄로 요약된다. 모델은 텍스트를 생성하지 않는다. 결정과 확률을 돌려준다. 확률이 높을수록 그 답이 맞을 가능성도 높아야 한다 52.

문서는 RLHF의 문제도 함께 적는다. 사람의 선호를 목표로 삼으면 아첨과 그럴듯한 환각에 보상이 갈 수 있고, 모델이 특정 스타일로 쏠리는 모드 드로핑이 생긴다. 사람이 보기 좋은 출력과 기계가 믿고 쓸 수 있는 출력은 서로 다른 최적화 목표라는 것이다 52.

보정(calibration)이 뜻하는 것

보정이란 모델이 붙인 확률이 실제 적중률과 맞아떨어지는 성질이다. 확률 0.2를 붙인 결과들은 약 20%, 0.8을 붙인 결과들은 약 80% 일어나야 한다 52.

여기서 헷갈리기 쉬운 대목이 있다. 이 비율은 예측 집단에 대한 성질이지 개별 답에 대한 보증이 아니다. 문서가 곧바로 이어 붙이는 문장이다 52.

한마디로, 0.92가 붙었다고 이 한 건이 맞는다는 뜻은 아니다. 비공식 매뉴얼의 표현을 빌리면 타입이 맞는 답도 틀린 답일 수 있다 (#53 Jev 매뉴얼(비공식)).

그래서 보정이 쓸모 있는 지점은 따로 있다. 불확실성을 소프트웨어가 다룰 수 있는 숫자로 만들어 준다는 것이다. 어디서 자동으로 실행하고 어디서 사람에게 넘길지를 코드가 정할 수 있게 된다 52.

Machine Native Intelligence 주장

TypeSafe는 자신들의 지향을 Machine Native Intelligence라고 부른다. 구조·신뢰성·관측 가능성·테스트 가능성·속도·일관성·낮은 비용처럼 소프트웨어가 갖는 성질을 지닌 AI라는 뜻이다 52.

근거로 드는 예상은 이렇다. 대규모 AI 자동화는 99%가 기계-기계 상호작용이고 1%만 사람과의 상호작용이 되리라는 것이다. 그러면 설계 목표가 "읽기 좋은 응답"에서 "소프트웨어 안에서 예측 가능하게 움직이는 출력"으로 옮겨 간다 52.

이건 회사의 주장이자 베팅이지 검증된 사실이 아니다. 문서 스스로 "다른 베팅에서 출발한다"고 쓴다.

한 요청이 처리되는 흐름

동작은 단순하다. 평가할 내용인 state와 타입이 정해진 질문들을 한 요청에 담아 보내면, 모든 질문이 같은 state에 대해 병렬·독립으로 평가되고, 타입이 정해진 답과 확률이 한 번에 돌아온다 52.

flowchart LR
  ST["state (평가할 내용)"]
  Q["타입이 정해진 질문들"]
  EV["같은 state에 대해<br/>병렬·독립 평가"]
  AN["타입이 정해진 답<br/>+ 확률 + 신뢰도"]
  CO["내 코드가 분기·정렬·라우팅"]
  ST -- "한 번의 요청" --> EV
  Q -- "한 번의 요청" --> EV
  EV -- "한 번의 응답" --> AN
  AN --> CO

그림 1. state와 질문들이 한 요청으로 들어가 타입이 정해진 답으로 돌아오는 흐름 52

질문 하나하나를 어떻게 쓰는지는 Jev 프리미티브에 따로 정리해 뒀다.

왜 빠르고 싼가 — 문서가 말하는 범위까지

문서가 근거로 드는 것은 세 가지뿐이다 52.

여기에 하나 더. state는 한 번만 실어 보내면 되므로, 독립적인 질문들을 한 요청에 묶으면 가장 큰 입력을 반복해 보내지 않아도 된다 (#53 Jev 매뉴얼(비공식)).

그 이상은 추정이다. 모델 크기나 아키텍처 때문에 빠르다는 식의 설명은 공개 문서에 근거가 없다. 실제로 몇 배 빠른지는 비교 대상과 과제에 따라 달라지며, 실측값은 Jev vs LLM vs 코드에 모아 뒀다.

어디까지가 공개된 사실인가

이 페이지에서 가장 중요한 경계선이다. 비공식 매뉴얼은 "System One"이 제품·인터페이스 용어이지 모델 내부 아키텍처의 공개 명세가 아니라고 못 박는다 (#53 Jev 매뉴얼(비공식)).

같은 문서는 한 걸음 더 나아간다. TypeSafe가 공개한 정보만으로는 내부 아키텍처를 독립적으로 재구성할 수 없다는 것이다. 그래서 자기들은 관측 가능한 API 동작만 설명하고 훈련 아키텍처는 추측하지 않는다고 선언한다 (#53 Jev 매뉴얼(비공식)).

그러니 이 위키도 같은 선을 지킨다. 여기 적힌 것은 모델이 무엇을 받고 무엇을 돌려주며 어떻게 훈련됐다고 회사가 말하는지까지다. 그 안쪽 구조는 적지 않는다. 모르기 때문이다.

함께 읽기

이 문서를 참조하는 문서 7개