3줄 요약
- Sprite Fusion 블로그에 Hugo Duprez가 2026년 9월 18일 올린 실험 기록이다. TypeSafe가 사흘 전 공개한 구조화 출력 모델 Jev를 게임 런타임에 넣어, 네온 나이트풍 러너 게임의 다음 지형을 플레이 도중에 생성해 보았다.
- 절차는 간단하다. 플레이어의 좌표와 속도, 현재 지형, 대시 가능 여부를 한 번에 묶어 보내고, 앞으로 만들 네 표면의 폭, 간격, 높이, 종류를 선택지로 묻는다. 한 번의 API 호출로 답이 오고, 저자가 쓴 코드는 그 선택대로 블록을 배치한다.
- 데모 한 판에서 요청은 다섯 번 발생했다. Jev API의 지연은 319에서 375밀리초 사이, 요청당 평균 비용은 0.00057달러, 데모 전체 비용은 0.00286달러로 추정됐다. 저자는 100밀리초 미만도 아니고 무료도 아니지만 게임에서 주목할 만하다고 정리했다.
게임 런타임에서 AI 도입을 막아 온 두 가지
저자는 게임이 실행 중에 AI를 부르지 못하는 이유로 지연과 비용을 든다.
모델이 생각을 마칠 때까지 5분을 기다려 줄 여유는 대부분의 게임에 없다. 비용 쪽으로 가면 어조가 더 단호해진다. 저자는 지금의 LLM 가격 구조가 게임에서는 의미가 없다고 본다. 원문의 표현은 이렇다.
동의하지 않는 사람도 있겠지만, 나는 지금의 LLM 가격이 게임에서는 무의미하다고 생각한다. 선술집 주인과 대화를 더 많이 나눈다고 비싼 API 호출 비용을 지불하는 것은 내게는 말이 되지 않는다.
Jev가 내세우는 것이 정확히 그 두 항목이다. TypeSafe는 응답 시간이 1초 미만이고, 입력은 백만 토큰당 0.042달러이며, 출력 토큰에는 요금을 매기지 않는다고 제시한다.
Jev는 어떤 모델인가
TypeSafe는 Jev를 System One 모델이라고 부른다. 이 모델은 문자열을 생성하지 않는다. 미리 정의한 선택지 중에서 하나를 고르고, 그 선택에 확률을 함께 붙여 돌려준다. 회사는 스키마 일치가 보장되므로 타입 오류가 발생하지 않고 할루시네이션도 구조적으로 불가능하다고 설명한다. 발표문은 처음 요청부터 응답까지 70밀리초에서 500밀리초가 걸리고, 같은 유형의 과제에서는 기존 프런티어 모델보다 40배에서 200배까지 빠르다고 제시한다.1
원문 저자는 이 소개를 두고 나올 법한 반응을 먼저 적어 두었다. “그거 그냥 분류기 아니냐.” 그러고는 그렇다면 그 분류기로 플랫포머 레벨을 실시간으로 생성할 수 있는지 확인해 보자고 썼다.
이 블로그에는 Jev를 다룬 글이 이미 둘 있다. 모델 발표 자체를 정리한 Introducing System One Models & Jev, 그리고 도구 100개를 가진 비서 에이전트에서 다음 도구를 LLM이 직접 고를 때와 Jev가 대신 고를 때를 비교한 jev-eval-agent 저장소다. 앞의 둘이 모델 자체와 에이전트의 판단을 다뤘다면, 이번 실험은 게임이 돌아가는 동안의 쓰임을 본다.
테스트용 게임을 먼저 만들었다
저자는 네온 나이트풍 러너 게임 프로토타입을 준비했다. 픽셀 아트는 Sprite Fusion의 픽셀 아트 생성 API가 만들었고, 게임 엔진은 PhaserJS, 코드 작성은 Astra를 붙인 Codex가 맡았다. Sprite Fusion API로 네온 나이트 닌자의 스프라이트와 애니메이션을 만들어 달라는 요청에, Codex는 그것을 만들고 이동과 충돌 처리도 구현했다고 답했다.
![]()
Sprite Fusion API가 생성한 닌자 스프라이트. 위쪽은 대기와 달리기와 점프 자세, 아래쪽은 공격 애니메이션 여덟 프레임이다.
Jev에게 다음 지형을 물어보는 방법
게임 상태와 예시를 보낸다
먼저 게임의 현재 상태를 기록한다. 플레이어의 위치와 속도, 지형을 이루는 블록, 대시 상태가 여기에 들어간다. 저자는 이 스냅샷과 예시 지형 배치 몇 개를 Jev 요청에 함께 담았다.
{"x":158.86,"y":86.87,"vx":2.27,"vy":-2.34,"grounded":false,"dash_ready":true}
![]()
왼쪽은 이미 만들어진 지형, 320픽셀 지점부터 오른쪽은 Jev에게 채워 달라고 요청할 표면 네 개의 영역이다. 원문 도식을 그대로 옮겼다.
선택지 질문으로 물어본다
질문 자체는 어렵지 않다. 지금 이 상태에서 다음 지형 조각을 어떻게 채우겠는가. 저자는 폭, 간격, 높이, 표면 종류마다 선택지를 만들고 이를 한 번의 API 호출에 모두 담았다. 허용한 선택지는 다음과 같다.
| 질문 | 허용한 선택지 |
|---|---|
| 표면 종류 | 막힌 지붕 또는 한 방향 발판 |
| 폭 | 2, 3, 5블록 |
| 앞쪽 간격 | 0, 1, 2블록 |
| 높이 | 4행에서 9행 |
Jev가 돌려준 답은 이렇다.
| 표면 | 종류 | 폭 | 앞쪽 간격 | 높이 |
|---|---|---|---|---|
| 1 | 발판 | 2블록 | 없음 | 5행 |
| 2 | 발판 | 3블록 | 1블록 | 6행 |
| 3 | 발판 | 5블록 | 2블록 | 5행 |
| 4 | 막힌 지붕 | 2블록 | 없음 | 4행 |
![]()
위 표의 선택을 그대로 그린 지형. 발판 셋은 얇은 한 방향 발판이고, 네 번째만 막힌 지붕이라 두껍게 그려진다.
레벨을 실제로 만드는 일은 여전히 저자의 코드가 한다. Jev가 정하는 것은 그 코드에 넣을 매개변수뿐이다.
지연과 비용은 얼마나 나왔나
| 항목 | 값 |
|---|---|
| 데모 중 요청 수 | 5회 |
| Jev API 지연 | 319~375밀리초 |
| 요청당 평균 비용 추정 | 0.00057달러 |
| 데모 전체 비용 추정 | 0.00286달러 |
저자의 평가는 절제된 편이다. 게임이 끊기지 않을 만큼 지형이 빠르게 생성되고 비용도 매우 낮다. 그러면서도 100밀리초 미만은 아니고 무료도 아니라고 덧붙였다. 데모보다 오래 플레이해 보았을 때도 지연 시간은 안정적인 수준을 유지했고 레벨 생성도 계속 정상 작동했다고 한다.
![]()
Jev가 고른 폭과 간격대로 배치된 지형 위를 닌자가 달린다. 원문 데모 영상의 한 장면이다.
결론
저자는 결론에서 “유망하다"라고 말한 뒤 곧바로 단서를 붙였다. 손으로 쓴 규칙과 휴리스틱으로 레벨을 생성하는 방법은 수없이 많고, 저자도 이를 인정한다. 그럼에도 더 싸고 더 빠른 구조화 출력 모델은 게임 개발에서 시도해 볼 만한 아이디어와 실험을 늘려 준다고 보았다. 후속 실험을 곧 공유하겠다는 예고로 글을 맺는다.
읽고 나서 계속 생각한 두 가지
저자가 자기 실험의 한계를 어느 대목에 적어 두었는지가 먼저 눈에 들어왔다. 비교 도식의 대체 텍스트에는 애니메이션 타이밍이 예시일 뿐이고 속도 비교는 측정값이 아니라고 명시해 두었다. LLM 쪽을 설명한 문장에는 LLM도 구조화 출력을 낼 수 있다고 덧붙였다. 데모 영상 설명에는 Jev의 응답 지연을 그대로 녹화했고 지형 보정은 로컬에서 하지 않았다고 적었다. 자기에게 유리한 비교를 만들어 놓고 그 비교의 약점을 그림 설명에 먼저 적어 두는 실험 기록은 흔하지 않다.
비용을 두고 한 지적도 오래 남았다. 저자가 문제 삼은 것은 모델 성능과 별개다. 플레이어가 선술집 주인과 대화를 늘릴수록 개발사의 청구서가 함께 늘어나는 과금 구조를 두고 한 말이다. 이 구조에서 게임을 열심히 즐기는 플레이어는 개발사에게 손해다. 출력 토큰에 요금을 매기지 않고 입력만 백만 토큰당 0.042달러로 둔 가격표가 그 계산을 바꾼다. 이번 실험의 데모 한 판은 0.003달러에도 못 미쳤다.
출처
Hugo Duprez, “Generating levels in real time with the Jev model”, Sprite Fusion Blog, 2026년 9월 18일 원문: https://www.spritefusion.com/blog/generating-game-level-in-real-time-with-jev
Diogo Almeida, “Introducing System One Models & Jev”, TypeSafe AI Blog, 2026년 9월 15일. https://typesafe.ai/blog/introducing-system-one-models-and-jev TypeSafe는 이 모델의 학습 방법을 RLCD(Reinforcement Learning for Calibrated Decisions)라고 부르며, 토큰을 하나씩 순차 생성하는 대신 모든 출력을 한 번의 질의로 병렬 생성한다고 설명한다. ↩︎
