시스템 원 모델(System One Model)과 Jev를 소개합니다 - TypeSafe AI 블로그

https://typesafe.ai/blog/introducing-system-one-models-and-jev

TypeSafe 창립자 Diogo Almeida

모델이 채팅 능력에서 인간을 뛰어넘은 지도 여러 해가 지났는데, 그 많은 자동화는 대체 어디에 있을까요?

지난 4년 동안 저는 줄곧 이 질문을 파고들었습니다. OpenAI에서는 언어 모델이 지시를 따르고 사람과 대화하는 데 유용하도록 만드는 기법을 개발하는 데 참여했습니다. 그 작업은 훗날 ChatGPT의 바탕이 된 연구로 이어졌습니다. 당시에는 채팅 모델이 AGI로 가는 길을 열지도 모른다고 생각했지만, 온갖 기대와 열광에도 불구하고 아주 중요한 무언가가 빠져 있다는 사실이 분명해졌습니다.

2년 동안 외부에 알리지 않고 개발하면서 수많은 기술적 난제를 해결하고 연구 성과를 거둔 끝에, 오늘 TypeSafe AI가 첫 번째 **시스템 원 모델(System One Model)**을 공개하게 되어 무척 기쁩니다. 시스템 원 모델은 소프트웨어가 곧바로 사용할 수 있는 빠르고 구조화된 의사결정을 내리도록 설계한 새로운 종류의 프런티어 모델입니다.

우리는 자동화에만 초점을 맞춰 완전히 새로운 스택을 구축했습니다. 새로운 모델 아키텍처, 효율을 극대화하는 병렬 샘플러, 그리고 우리가 보정된 의사결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions, RLCD)이라고 부르는 학습 기법으로 이루어진 스택입니다.

첫 공개 모델은 오늘부터 얼리 액세스로 이용할 수 있는 Jev입니다. Jev는 시스템 원 유형의 작업에서 기존 LLM과 비슷한 수준의 지능을 보이면서도 속도와 효율은 100배가량 높습니다. 문자열 생성 기능은 포기했지만 구조화된 출력에 최적화되어 있으며, 환각을 일으킬 수 없습니다.

Jev는 프런티어급 지능을 갖춘 함수 호출이라고 생각하면 됩니다. 구조화되지 않은 상태를 입력하면 타입이 지정된 확률적 의사결정을 출력합니다.

대담한 주장에는 그만큼 확실한 증거가 필요하니, 아래에서 근거를 확인해 보세요. 💅

기존 프런티어와 새로운 프런티어

증거 / 기술 결과

우리는 회의적인 사람들을 좋아하며, 우리 자신도 회의적인 태도를 유지합니다.

몇 가지 주장은 쉽게 검증할 수 있습니다.

• 호출당 속도: 실제로 이만큼 빠릅니다. 다만 우리가 공개한 평가는 대체로 미국 서부에 있는 노트북에서 실행했습니다. 현재 서비스가 그 지역을 기반으로 운영되고 있기 때문입니다.
• 호출당 비용: 가격을 투명하게 공개합니다. 다만 이 가격에 보조금이 반영되지 않았다는 사실까지 증명할 수는 없습니다. 가격을 지속 가능한 수준으로 유지할 수 있다는 점은 장기적으로 입증해야 합니다. 우리는 가격이 오르기보다 내려갈 것으로 예상합니다.
• 타입 오류 없음: 단 하나의 반례만 있어도 쉽게 반증할 수 있는 주장이지만, 타입 오류는 수학적으로 불가능합니다.

더 대담한 주장에는 가능한 한 세세한 맥락까지 함께 제시하려고 합니다.

나란히 비교한 데모

나란히 비교한 데모에서는 우리 모델과 LLM의 핵심 차이를 확인할 수 있습니다. Jev는 토큰을 자기회귀 방식으로 생성하는 대신 모든 확률을 병렬로 출력합니다. 문자열은 매우 강력하고 범용적이지만 비용이 많이 듭니다. 문자열을 "포기"하자 오히려 수많은 강력한 능력을 얻게 되었습니다!

세부 맥락

• TypeSafe 얼리 액세스 권한이 있다면 실제 쿼리를 확인할 수 있습니다.
  • 이 쿼리는 크게 단순화했으며, 화면에 표시된 출력을 쉽게 이해할 수 있도록 questions에는 설명적인 키, 즉 사람이 읽고 뜻을 알 수 있는 키를 사용했습니다.
    • 샘플링 방법론의 차이를 강조하기 위해 state도 짧지만 압축적이고 구체적인 문단으로 작성했습니다. 입력이 비교적 짧다는 점은 우리 모델에 유리하게 작용합니다.
• 영상을 자세히 보면, 녹화한 실행에서 GPT-5.6 Terra와 의견이 다른 항목은 "고객 이탈 가능성 수준(Churn likelihood level)"뿐입니다. 실제 답은 우리 눈에도 정말 모호해 보입니다.
• 이 예에서는 GPT-5.6 Terra를 기본 추론 설정으로 사용했습니다. 평균적으로 Jev와 지능 수준이 가장 비슷하다고 판단했기 때문입니다.
• 재미있는 사실이 하나 있습니다. 시스템 원 모델 개발에 전력을 다하기로 우리를 확신시킨 것도 이와 비슷한 데모였습니다!

워크플로 평가

우리는 AI가 코드 안에서 얼마나 잘 작동하는지를 측정하기 위해 새로운 유형의 평가를 만들었습니다. 정답으로 정해진 분류 결과에 맞춰 최적화하지 않으며, 평가 하네스와 모델을 바꾸도록 허용하지도 않습니다. 하네스 엔지니어링을 통해 과적합할 가능성을 막기 위해서입니다. 그 대신 올바른 계산 그래프, 즉 코드로 표현된 "워크플로"가 있다고 가정하고, 규모와 지능과 비용이 가장 높은 외부 모델들의 예측치를 기준 확률로 사용합니다.

다시 말하면 모든 모델에 같은 워크플로를 제공합니다. 그런 다음 각 모델의 결과를 가장 뛰어난 모델들, 이 경우에는 Astra와 Fable이 내놓은 결과의 평균과 비교합니다.

Jev의 결과는 그래프 범위를 벗어날 정도이며, 거의 100배에 이르는 구간에서 파레토 프런티어를 차지합니다. 모든 로직을 생각의 사슬에서 처리하도록 생성한 프롬프트를 사용하는 모델과도 비교하지만, 이 방식은 워크플로 자체를 사용할 때보다 대체로 결과가 현저히 나쁩니다.

여기서 사용한 호출은 위의 나란히 비교한 데모보다 훨씬 복잡합니다. 진정한 비즈니스 자동화에 필요한 실제 운영 환경의 작업 부하를 더 잘 반영하기 때문입니다. 공개하는 네 가지 워크플로 가운데 가장 단순한 것은 다음과 같습니다.

현실에서 가장 안정적으로 작동하는 워크플로에는 서로 독립적으로 분해된 질문이 많은 경우가 일반적이며, 세밀한 동작도 이산적인 결정이 아니라 확률에 따라 달라집니다. 최종 결과에서는 명확한 분기가 이루어지지만, 최종 답에 이르는 과정에는 도메인별로 상당한 엔지니어링이 필요하며 그 로직이 매우 일관되게 실행되어야 합니다.

예시, 모델 간 의견 차이, 전체 쿼리, 각 워크플로에 관한 자세한 내용은 워크플로 평가 사이트에서 확인할 수 있습니다.

세부 맥락

• 홈페이지에 제시한 193.6배 빠른 속도와 444.6배 낮은 비용이라는 수치는 여기서 나왔습니다. 실제 환경에서 얻을 수 있는 개선 폭 가운데서도 높은 편에 속할 것으로 예상합니다.
• 이 워크플로의 내용은 우리 모델이 유리해 보이도록 의도적으로 고르거나 구성한 것이 아니며, 학습 데이터 분포에도 포함되지 않습니다. 다만 우리 모델 역량 팀 구성원들이 만들었으므로 어느 정도 편향이 있을 수 있습니다.
• GPT-6 Astra와 Fable 5.1의 결과 평균을 기준 답으로 사용하므로, OpenAI와 Anthropic의 모델에 유리한 편향이 생깁니다. 우리 모델과 DeepSeek 모델의 상대적 성능은 실제보다 낮게 추정되었을 가능성이 큽니다.
• LLM에는 System One LLM 래퍼를 사용합니다. 이 래퍼는 LLM이 우리 API와 호환되는 구조화된 의사결정을 출력하도록 제한합니다. 우리가 시험한 방법 가운데 LLM에서 의사결정을 얻는 가장 정확한 방법이지만, 확률 없이 결정만 받는 방식보다 대체로 느리고 비용도 많이 듭니다.

환각과 타입 안전성

환각과 타입 안전성은 본질적으로 연결되어 있으며, 우리는 타입 안전성을 자동화를 위한 최소 요건으로 봅니다. 에이전트가 존재하지 않는 도구 호출을 만들어 내면 불편한 정도에 그칠 수 있습니다. 하지만 지연 시간 보장이 필요한 시스템의 일부이거나 의존성 사슬의 여러 계층 아래에 묻혀 있다면 절대로 용납할 수 없습니다. 기존 모델은 아무리 똑똑하더라도 여전히 환각과 타입 오류를 일으킵니다.

세부 맥락

• LLM 수치는 OpenRouter에서 가져왔습니다. 따라서 거의 확실하게 편향이 있습니다. 더 복잡한 쿼리가 더 뛰어난 모델로 전달될 수 있기 때문입니다.
• 우리 수치는 실험으로 측정한 값이 아닙니다. 스키마 일치를 보장하므로 그래프에 0%를 자신 있게 표시할 수 있습니다.

재미있는 데모

우리 작업에서 가장 흥미로운 부분은 아마 새로운 사용 사례를 가능하게 한다는 점일 것입니다. 보여 드릴 것이 훨씬 더 많지만, 우선 팀에서 특히 좋아하는 데모 두 가지를 소개합니다.

Doom

이 Doom 데모는 실시간 지능과 코드 + AI로 무엇을 할 수 있는지를 아주 멋지게 보여 줍니다. 이 데모를 만든 엔지니어는 초당 10번의 쿼리를 실행하면 비용이 시간당 약 7달러까지 들까 봐 걱정했지만, 나머지 팀원들은 예상보다 저렴하다는 데 의견을 모았습니다! 너무 재미있는 프로젝트여서 자세한 제작 과정을 공개할 뿐 아니라, 함께 개발해 보는 행사도 열 계획입니다.

세부 맥락

• 이 데모는 이미지가 아니라 텍스트를 담은 데이터 구조로 표현한 구조화된 상태를 사용합니다. 아직은 말이죠…
• AI를 사용하지 않는 Doom 봇이 게임을 더 잘할 수는 있습니다. 하지만 우리는 게임 상태를 서로 다른 방식으로 표현해도 그에 맞춰 반응하는 봇을 만들고 싶었습니다. 무엇보다도 지시를 따르는 모습이 정말 끝내줬습니다!

위키레이싱

이 게임의 목표는 한 위키백과 문서에서 출발해, 이동하는 동안 발견한 링크만 사용하여 지정된 다른 위키백과 문서에 도달하는 것입니다. 단계마다 수백 개에서 수천 개에 이르는 링크 가운데 하나를 골라야 할 수 있습니다! 초당 처리하는 지능뿐 아니라, 선택지가 아주 많을 때 환각이 없어서 얻는 이점이 얼마나 크게 누적되는지를 보여 주기에도 훌륭한 실험장입니다.

세부 맥락

• 우리가 아는 한, 두 번째와 세 번째 도전이 모두 "Rubber Duck"에서 시작한 것은 완전한 우연이었습니다. 작성자는 팀에서 알려 주고 나서야 이 사실을 알아차렸습니다.
• 여기서 얻는 속도 향상 폭은 앞선 데모보다 훨씬 작은 편입니다. 추론 기능을 사용하지 않는 모델 모드와 비교했기 때문입니다. 단, Astra만 가장 낮은 추론 설정을 사용했습니다. Jev가 대체로 더 적은 단계 만에 끝낸 것도 이 때문이며, 이는 더 높은 지능을 나타냅니다. 데모 영상을 좀 더 편하게 볼 수 있도록 이렇게 설정했습니다. 추론을 활성화했을 때와 비교하면 이 작업에서 LLM의 성능이 훨씬 나빠 보입니다.
• Jev는 최대 255개의 선택지를 지원합니다. 선택지가 많은 경우에는 먼저 각 항목의 점수를 독립적으로 계산하고, 그다음 하나를 명시적으로 선택하는 2단계 시스템을 사용합니다. 이 때문에 가끔 속도가 느려집니다.

다음 단계

Jev는 아직 초기 단계입니다. 준비하고 있는 것이 훨씬 더 많으며, 앞으로도 계속 새로운 결과물을 내놓을 생각에 무척 기대됩니다 🔥.

오늘부터 얼리 액세스를 시작하며, 대기 명단에 있는 개발자들에게 최대한 빨리 이용 권한을 제공하고 있습니다. 어떤 의사결정을 자동화해야 하는지, Jev가 어디에서 잘 작동하고 어디에서 부족한지 듣고 싶습니다. 어떤 공상과학적 상상을 현실로 만들고 싶은지 알려 주세요!!

우리가 TypeSafe를 시작한 이유는 소프트웨어가 믿고 의존할 수 있는 인터페이스를 AI에 제공해야 한다고 믿기 때문입니다. 새로운 사용 사례가 커뮤니티와 경제 전반에 끊임없이 퍼져 나가는 모습을 하루빨리 보고 싶습니다.

자주 묻는 질문에 답합니다

"시스템 원 모델"과 "Jev"라는 이름은 어디에서 왔나요?

Daniel Kahneman의 『생각에 관한 생각』(Thinking, Fast and Slow)에서 영감을 얻었습니다. 빠르고 직관적인 시스템 1 사고와 느리고 신중한 시스템 2 사고의 구분에서 이 모델 종류의 이름을 따왔습니다.

"시스템 1 사고"에는 오류가 발생하기 쉽다는 의미도 담겨 있습니다. 앞으로 자세히 설명할 여러 이유로, 우리는 시스템 원 모델을 다른 대안보다 더 안정적으로 만들 수 있다고 믿습니다.

Jev라는 이름은 William Stanley Jevons에서 따왔습니다. 증기기관의 효율 향상이 석탄 수요 증가로 이어졌듯이, 기계 지능도 비슷한 경로를 따를 것으로 예상합니다. 지능의 비용이 10분의 1로 낮아질 때마다 활용 사례는 수십 배, 수백 배로 늘어납니다.

새로운 학습 알고리즘이 필요했던 이유는 무엇인가요?

모든 연구소는 인간 피드백을 활용한 강화학습(RLHF) 과정에서 똑같은 과제를 최적화합니다. 바로 인간 평가자가 더 선호하는 텍스트를 생성하는 것입니다. 채팅 제품에는 적합한 과제였지만 자동화에는 적합하지 않습니다. 우리는 이를 가장 뼈아픈 교훈이라고 부릅니다. 올바른 과제를 최적화하는 일이 데이터나 컴퓨팅 자원, 알고리즘보다 더 중요하다는 뜻입니다.

RLVR은 프로그램으로 간단히 검증할 수 있는 작업에는 매우 적합하지만, 현실에서 판단이 필요한 작업은 대부분 그런 형태에 들어맞지 않습니다. 그 결과, 지능이 고르게 발휘되지 않고 견고하지 못한 경향이 생깁니다.

Jev는 어떤 사용 사례에 적합한가요?

여러 산업에서 Jev를 다양하게 활용할 수 있다는 사실을 확인했습니다. 몇 가지 사례는 문서에 정리해 두었으며, 개발자들이 또 어떤 것을 만들지 기대하고 있습니다.

Jev는 단지 더 작은 LLM인가요?

Jev는 작지도 않고 LLM도 아닙니다. 그래서 기존 지능 파레토 곡선에 들어맞지 않습니다.

공개 벤치마크에서 Jev의 성능은 어떤가요?

우리는 공개 벤치마크에서 측정한 성능을 의도적으로 공개하지 않기로 했습니다. 실제로 제품을 업데이트할 때만 일회성 평가를 진행할 계획입니다.

모델의 새로운 프런티어를 열고 있는 만큼, 더 유용한 모범 사례가 자리 잡도록 다음 원칙을 제안합니다.

• 공개 벤치마크에는 아무런 비중도 두지 않습니다.
• 사용자가 자신의 사용 사례에 맞는 평가를 직접 만들도록 권장합니다. 시스템 원 작업은 훨씬 쉽게 평가할 수 있습니다.
• 평가에 담긴 세부 맥락과 한계를 공개합니다.
• 앞서고 있을 때조차 벤치마크의 중요성을 낮춥니다.

벤치마크 최적화에 관한 우리의 철학은 이 블로그 글에서 확인할 수 있습니다.

학습 데이터는 어디에서 가져오나요?

TypeSafe는 기본적으로 데이터 연구소이며, AI 분야의 가장 큰 성과는 이런 방식으로 만들어집니다. 모든 데이터는 직접 만듭니다. 요청받더라도 사용자의 데이터로 학습하지 않을 것입니다. 물론 악의는 없습니다. 상당히 정교한 작업을 하고 있지만, 더 자세히 알고 싶다면 우리 팀에 입사하셔야 합니다.

결과가 상당히 놀라운데, 어떻게 가능한가요?

AI가 주는 가장 뼈아픈 교훈에 관한 블로그 글을 읽어 보세요. 짧게 답하면, 무엇을 최적화하느냐에 따라 결과가 달라집니다. LLM은 뛰어난 챗봇과 코파일럿이 되도록 최적화했고, 그 결과 사람이 개입하는 작업에서는 인간을 뛰어넘는 수준에 도달했습니다. 우리는 시스템 원 인터페이스를 최적화하고 있습니다.