DeepSeek V4: 저예산 AI 게임 생성 최적화 실험

저렴한 모델로도 사람들이 실제로 플레이하고 싶어 하는 브라우저 게임을 만들 수 있을까요? 지난 한 주 동안 OpenGame Studio에서 이 질문을 테스트했습니다. 가장 최근에 추가된 모델은 DeepSeek V4 제품군의 10월 17일 출시 버전인 DeepSeek-V4.1-Flash-1017입니다.

Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5도 테스트했습니다. 생성 비용, 대기 시간, 플레이 가능성, 시각적 품질의 균형을 개선하는 것이 목표였습니다. 게임이 정상적으로 열려도 플레이어가 왼쪽을 누를 때 오른쪽으로 움직이거나, 접촉하기 전에 코인을 지급하거나, 일시 정지 중에도 계속 떨어질 수 있습니다.

최신 DeepSeek 러너는 저희가 실행한 핵심 게임플레이 검사를 통과했습니다. 아트워크는 소박했습니다. 이전 실험에서는 저희 자체 전달 검증의 결함을 포함해 서로 다른 문제가 드러났습니다. 그 구체적인 내용은 설명 없이 모델 순위를 매기는 것보다 제작자에게 유용합니다.

원본 DeepSeek-V4.1-Flash-1017 러너입니다. 캐릭터와 차선, 코인은 구분되지만 배경은 기본적인 프로토타입 수준입니다.

저렴한 게임 생성 최적화하기

소규모 게임 제작에서는 반복 실험이 중요합니다. 첫 버전의 카메라, 조작, 충돌 규칙, 아트 방향을 다시 시도해야 할 수 있습니다. 실용적인 질문은 그 과정을 통해 얼마나 많은 유용하고 테스트 가능한 게임을 얻을 수 있는가입니다.

Claude Opus 5.5 같은 강력한 플래그십 모델은 까다로운 코딩 작업의 분명한 대안입니다. 공식 설명에는 서브에이전트 작업도 언급되어 있습니다. 더 큰 워크플로를 선택하기 전에 저렴한 후보군을 살펴보고자 했습니다. 모델 이름만으로 좋은 게임이 보장되지는 않으며 여러 에이전트를 사용하는 것도 작업량과 사용량을 늘릴 수 있는 워크플로 선택입니다.

후보 모델은 각각 다른 역할을 맡았습니다.

• Grok 4.6은 범용 기준 모델이었습니다. 저희에게는 예산을 우선한 선택지는 아니었지만 구독을 통한 접근이 장점이었습니다. 공식 출시 페이지에는 Grok Build와 다른 도구를 통한 코딩 접근이 설명되어 있습니다.
• Xiaomi MiMo V2.6 Flash와 Pro는 같은 제품군의 두 옵션을 비교하게 해줬습니다. Xiaomi는 Flash를 효율적인 빈번 사용에, Pro를 더 까다로운 추론 및 프로젝트 작업에 맞춘다고 소개합니다. Pro는 자체 제품군의 플래그십이지만 저희 예산 실험 후보에 포함했습니다.
• GLM 5.3 Flash는 효율성을 강조하는 또 다른 옵션이었습니다. 공식 소개에 해당 포지셔닝이 설명되어 있습니다. 전체 게임 요청을 어떻게 처리하는지 확인하고자 했습니다.
• Claude Haiku 5.5는 해외 비용 민감형 옵션으로 추가했습니다. Anthropic은 Haiku를 빠른 대량 작업용으로 소개합니다. 아래에 한계를 적은 제한적 검토와 함께 게임 제작 모델로 테스트했습니다.
• DeepSeek-V4.1-Flash-1017은 가장 최근 실험이었습니다. 출시 발표에는 프로젝트 시연이 포함됩니다. 저희의 러너 요청으로 무엇이 OpenGame Studio에 적용되는지 살펴봤습니다.

저렴한 옵션을 찾느라 중국 기반 모델 제품군이 후보에 더 많이 들어갔습니다. 이는 후보를 고른 과정의 특징이지, 국가별 모델 품질에 관한 결론은 아닙니다.

러너 하나로 진행한 6개 모델 실험

공통 게임은 오리지널 3인칭 3차선 무한 러너 Colossal Runner였습니다. 캐릭터는 자동으로 앞으로 달립니다. 플레이어는 차선을 바꾸고, 장벽을 뛰어넘고, 머리 위 장애물 아래로 미끄러져 통과하고, 코인을 모으고, 충돌 후 다시 시작합니다. 키보드와 터치 입력은 같은 결과를 보여야 합니다.

원래 요청에는 일시 정지, 획득한 코인으로 부활, 두 차선을 막고 한 개의 안전 경로만 남기는 거대 장애물도 포함했습니다. 서로 영향을 주는 규칙이 있어 점수판만 있는 움직이는 장면보다 요청을 더 잘 검증할 수 있습니다.

2026년 10월 11일부터 17일까지 다음 실험에 같은 오리지널 요청을 사용했습니다.

개발자가 직접 실행한 개별 실험입니다. 실용적인 비교 자료로 쓸 수 있지만 한계가 분명합니다. 각 모델은 시각적 선택이 서로 다른 자체 요약과 구현을 만들었습니다. 테스트 날짜가 달랐고 웹사이트 환경도 고정되어 있지 않았습니다. MiMo Flash는 빌드 전에 추가 대화가 필요했습니다. 시간에는 대화, 사양 작성, 플레이 테스트가 포함되지 않았으며 GLM 시간은 거부 시점에서 끝납니다.

DeepSeek 러너에는 기존 생성 제약과 MiMo 실험에 사용한 것과 동일한 3D 제작 지침을 적용했습니다. 승인 검사를 하기 전에 소스를 수동으로 수정하지 않았습니다. 이 실험은 통계적으로 신뢰할 수 있는 속도나 품질 순위를 입증하지 않습니다.

MiMo, GLM, Haiku가 비교에 더한 점

MiMo Flash는 검사할 수 있는 게임을 만들었고 유용한 조작 기능도 구현했습니다. 키보드, 터치, 일시 정지를 제한적으로 확인했습니다. 문제는 코인 규칙이었습니다. 러너가 코인에 닿기 전에 보상이 지급될 수 있었습니다. 수집 검사에서 소스가 잘못된 위치 필드를 읽고 있었습니다. 그럴듯한 장면과 올라가는 카운터가 고장 난 상호작용을 가리고 있었습니다.

이후 선별 수정을 하기 전 MiMo Flash의 원본 출력입니다. 수집 타이밍 결함은 게임플레이 및 소스 검사로 발견했습니다. 이 한 프레임만으로 결함을 입증할 수는 없습니다.

MiMo Pro도 플레이 가능한 프로토타입을 전달했고 방향과 코인 접촉 검사는 양호했습니다. 점프 중 일시 정지하면서 다른 결함이 드러났습니다. 거리와 코인은 멈췄지만 캐릭터는 계속 떨어졌습니다. 완전한 일시 정지는 수직 이동을 포함해 관련 시뮬레이션을 멈춰야 합니다.

MiMo Pro의 원본 도시 장면입니다. 보기 좋은 정지 이미지로는 드러나지 않는 일시 정지 결함을 찾으려면 점프 중 검사가 필요했습니다.

GLM에 대해서는 두 가지 결과를 구분해야 합니다. Studio 실행에서는 검증기가 인라인 게임 코드를 허용되지 않는 리소스 마크업으로 잘못 읽어 전달에 실패했습니다. 플랫폼 오류였습니다. 이를 GLM이 게임을 생성할 수 없다는 증거로 세면 오해를 부릅니다.

변경하지 않은 원본을 복구해 별도로 검사했습니다. 제한된 방향, 터치, 일시 정지 검사는 작동했지만 재시작 뒤 오래된 코인 표시가 남을 수 있었습니다. 별도 검사는 결과물의 동작에 대한 정보를 제공하지만, 실패한 Studio 흐름을 성공적인 전달로 바꾸지는 않습니다.

별도 검사 중 복구한 GLM 원본입니다. Studio에서 성공적으로 전달됐다는 증거는 아닙니다.

이번 표본에서 Haiku 5.5는 비교적 빠르게 미리보기를 전달했습니다. 시작 화면을 확인한 뒤 첫 시각적 검토만 마치고 테스트를 종료했습니다. 키보드, 터치, 충돌, 부활, 재시작 승인을 마치지 않았습니다. 첫인상은 MiMo 실험에 더 무게를 둔 저희 선호를 바꾸지 않았지만, Haiku의 품질에 확정적인 판단을 내릴 게임플레이 근거도 부족합니다.

테스트 기록에서는 전달 완료, 시각 검토, 동작 검증을 서로 다른 단계로 구분해야 합니다.

왼쪽 입력이 왜 오른쪽으로 움직이나요?

Grok 러너에서 가장 분명한 조작 실패가 발견됐습니다. 중앙 차선에서 ArrowLeft를 누르면 화면 오른쪽으로 이동했습니다. 왼쪽으로 쓸어도 같은 결과가 나왔습니다.

전: 러너가 중앙에 있습니다.

ArrowLeft 입력 후: 러너가 눈에 보이는 오른쪽에 있습니다. 두 캡처 모두 수정하지 않은 생성 빌드에서 가져왔습니다.

소스를 보면 이유가 드러났습니다. “왼쪽” 입력 처리기가 월드 좌표의 음의 X 방향으로 이동했지만, 카메라 방향 때문에 화면에서는 오른쪽으로 보였습니다. 키보드와 터치가 같은 차선 제어기를 사용해 두 입력 모두 같은 오류가 있었습니다.

플레이어의 기준은 화면에 보이는 트랙입니다. 좌표가 감소한다고 올바른 왼쪽 이동이 보장되지는 않습니다. 따라가는 카메라에서는 캐릭터가 화면 중앙에 머무르는 동안 트랙이 움직일 수 있으므로 차선 기준 캐릭터 위치도 확인해야 합니다.

별도 레이싱 실험에서는 저희 평가의 약점도 발견됐습니다. 자동 조작기가 반대 방향 조향을 보정해 랩을 완주할 수 있었습니다. 이제 매번 새로 시작해 각 방향을 따로 확인합니다. 코스를 완주한 것만으로 조작 표시가 정확하다고 검증된 것은 아니었습니다.

러너 테스트에서 DeepSeek V4는 어땠나요?

짧은 확인 후 최신 러너는 약 7분 만에 생성됐습니다. 웹사이트 미리보기에서 원본 결과를 시험했습니다.

• 방향: ArrowLeft, ArrowRight, A, D는 눈에 보이는 올바른 차선으로 이동했습니다. 반복 입력은 가장자리 차선에서 멈췄습니다.
• 터치: 세로 및 가로 모의 화면에서 좌우 스와이프가 작동했습니다. 위로 스와이프하면 점프했고 아래로 내리면 캐릭터가 내려와 슬라이딩했습니다.
• 장애물: 키보드 플레이로 지상 장벽을 뛰어넘고, 머리 위 막대 아래로 슬라이딩하고, 거대 장애물 옆의 안전 차선을 통과했습니다.
• 코인과 부활: 코인에 도달하면 수집이 시작됐습니다. 부활은 획득 코인을 사용해 안전하게 재개됐습니다. 비용을 감당할 수 없으면 코인도 횟수도 소비하지 않았습니다.
• 일시 정지와 재시작: 점프 중 일시 정지하면 높이와 거리가 멈추고 트랙 입력이 차단됐습니다. 재시작하면 중앙 차선, 거리, 화면의 코인 수가 초기화됐습니다.

한 장애물 주행은 216미터를 넘어 계속됐고 코인 51개를 모았습니다. 브라우저 자동화는 일반 플레이 입력을 보냈습니다. 결과를 얻기 위해 좌표, 점수, 충돌 상태를 변경하지 않았습니다.

세로 브라우저 모의 환경에서 왼쪽으로 스와이프하면 눈에 보이는 왼쪽 차선으로 이동합니다. 실제 휴대전화 호환성은 테스트하지 않았습니다.

모든 무작위 장애물 순서, 열차 지붕 경로, 부활 한도, 후반 게임 상태를 확인하지는 않았습니다. 테스트 범위 내에서 규칙 처리에 기대를 갖게 하는 작동 가능한 프로토타입이었습니다.

로직, 아트워크, 가독성은 따로 평가해야 합니다

DeepSeek 러너에서는 청록색 캐릭터, 밝은 차선 테두리, 금화, 대비되는 장애물처럼 중요한 오브젝트가 구분됐습니다. 어둡고 단순한 배경과 기본적인 건물은 시각적으로 개선할 여지가 많았습니다. 단일 결과만으로 DeepSeek이 일반적으로 아트보다 로직에 강하다고 결론 내릴 수는 없습니다.

별도의 Neon Harbor Sprint 실험은 네온 스타일이 돋보였지만 자동차의 실루엣과 도로는 알아보기 어려웠습니다. 성능 개선을 위해 렌더링 해상도를 낮추자 반응성은 좋아졌지만 선명함은 떨어졌습니다.

DeepSeek으로 만든 별도 레이싱 프로토타입입니다. 공통 러너 비교와는 다른 요청을 사용했습니다.

다른 게임은 비교를 흐릴 수 있어 러너로 돌아왔습니다. 레이서 실험에서도 유용한 교훈을 얻었습니다. 실제 플레이 크기에서 움직이는 게임을 보며 캐릭터, 장애물, 차선 경계를 평가하세요. 효과와 인터페이스 장식이 있어도 가독성이 떨어질 수 있습니다.

프롬프트와 스킬이 지나치게 제약적인가요?

재사용할 수 있도록 러너 요청을 의도적으로 상세하게 작성했습니다. 일반 제작자는 훨씬 짧은 아이디어로 시작할 수 있어야 합니다. 그 아이디어를 유용한 제작 요약으로 다듬는 것도 제품이 맡을 일입니다.

짧은 프롬프트와 상세 프롬프트를 통제된 방식으로 비교하지 않았습니다. 따라서 프롬프트 길이만으로 반대 방향 조작을 설명할 수 없습니다. 실패한 소스에서는 카메라와 입력 간의 직접적인 원인이 드러났고, 같은 요청을 받은 다른 결과물은 방향을 올바르게 처리했습니다.

일관된 조작, 코인 접촉, 완전한 일시 정지, 깔끔한 재시작 같은 제약은 경험을 보호합니다. 반면 테마, 색상, 카메라 표현, 모델의 장면 구성 방식은 자유롭게 선택할 수 있습니다. 경직된 제작 절차는 첫 구현을 살펴보고 개선할 여지를 너무 적게 남길 수도 있습니다. 더 많은 수정 기회를 시험할 가치가 있지만, 이 실험만으로 그 이점을 입증한 것은 아닙니다.

이전 시도는 워크플로를 살펴봐야 하는 이유를 보여줬습니다. 한 MiMo 시도는 게임 전달 전 응답 한도를 소진했습니다. 다른 시도는 코드를 작성했지만 공급자 스트림 오류로 최종 전달에 실패했습니다. 두 실패는 원인이 달랐으며 게임플레이 결함과 별도로 기록해야 합니다. 이런 사례 때문에 모든 과거 시도를 모델만 바꾼 A/B 테스트로 간주할 수 없습니다.

제작자는 다음처럼 시작할 수 있습니다.

3차선의 짧은 3D 러너를 만들어 주세요. 키보드나 터치로 좌우 이동하고 장벽을 뛰어넘고 들보 아래로 슬라이딩할 수 있게 해주세요. 알아보기 쉬운 캐릭터, 만족스러운 코인 수집, 충돌 후 빠른 재시작이 필요합니다. 배경과 시각 스타일은 자유롭게 정해주세요.

이것은 시작점으로 제안하는 문구이지 원래 비교용 프롬프트는 아닙니다. Studio는 빠진 규칙을 확인하고 요약을 확정하며 창의적인 선택을 위한 여지를 남길 수 있습니다. 그런 다음 짧게 플레이해 다음에 유용한 수정을 찾으세요.

이 테스트로 다음 실험에서 달라질 점

저희에게 최적화는 이제 전달 신뢰성, 검사 시간, 플레이 가능한 결과를 얻기 위해 필요한 수정량도 포함합니다. 저렴한 생성은 결과가 일반 입력에 견디고 관리 가능한 수정 과정으로 나아질 때 유용합니다.

원본 결과를 보관하고 각 시도의 단계와 도달 지점을 기록하고, 키보드와 터치를 화면에서 보이는 동작에 맞춰 시험하겠습니다. 향후 비교에서는 게임을 고정한 채 요약 길이나 수정 기회 등 워크플로 변수 하나를 바꿀 수 있습니다. 이번 관찰만으로는 다음 실험에서 어떤 모델이 앞설지 알 수 없습니다.

플레이 가능한 예시는 Colossal Runner에서 확인하세요. 공개된 선별 버전에는 이후 수정이 반영되어 있으며 여기서 보여준 원본 실험과는 별개입니다. 원하는 경험의 아이디어를 얻으려면 다른 브라우저 게임도 둘러보세요.

작은 게임 아이디어가 있나요? OpenGame Studio에서 요약을 시작하고 핵심 루프를 정한 뒤 실제 입력으로 첫 버전을 시험하세요.

출처 안내

공식 출처는 모델명, 출시 맥락, 공급자 소개를 확인하는 데 사용했습니다. DeepSeek 10월 17일 출시, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5, 테스트하지 않은 플래그십 배경 사례인 Claude Opus 5.5를 참고했습니다.

게임플레이 관찰과 빌드 시간은 OpenGame Studio 실험과 보관된 원본에서 나왔습니다. 이미지 8장은 검사 당시 변경하지 않고 캡처한 것으로, 절차적 원본 아트 또는 CC0-1.0 라이선스의 OpenGame M0 캐릭터 에셋을 사용했습니다. 공급자 시연 이미지나 보정해 재구성한 이미지가 아닙니다.