약 한 달 전에 제가 작업하던 프로젝트를 공유했었는데, 오늘 드디어 완성했습니다. 간단하게 알고 싶은 것이 하나 있습니다. Qwen 3.8FN이 게임 개발(gamedev)에 얼마나 좋을까요? 그리고 이 과정이 너무 재미있어서, 무료로 즐길 수 있는 완성된 제품을 출시하게 되었습니다. 요약 및 링크는 아래에 첨부합니다. 저의 Qwen 3.8FN 사용 경험은 다음과 같습니다.
사용 데이터 모델: Qwen 3.8 Flash Next - Unsloth Quant - UD_Q4_XL (업데이트 전)
머신: Strix Halo (Ryzen AI 395+, Bosgame M5) - Windows (Windows에 대해 뭐라고 말하든 상관없습니다. 저는 다른 용도로 필요하고 가상 머신(dualboot)을 사용하고 싶지 않기 때문입니다.)
추론 엔진: 제가 직접 만든 windows Gufo 포크 (솔직히 말씀드리자면, Gufo 개발자들의 작업이 없었다면 이 전체 프로젝트를 진행하지 못했을 것이라고 생각합니다. llama의 속도는 너무 느립니다.)
하네스(Harness): 제가 직접 만든 하네스입니다. 이건 정말 평범한 것인데, opencode나 pi가 아마 더 좋을지 모르겠지만 저는 제 것을 소유하고 싶고, 솔직히 이걸 출시할 계획도 없습니다. 하지만 사람들이 물어볼까 봐 말씀드립니다.
프로젝트 기술 스택: typescript + three.js (렌더러)
통계(Stats): 프롬프트(Prompts): 1,911 || 도구 호출(Tool calls): 31,883 || 출력 토큰(Tokens out): 20,370,450 || 입력 토큰(Tokens in): 3,069,385,337 (캐시된 값: 3,042,941,686)
3.8 Flash Next에 대한 생각
만약 이 모델을 구동해 볼 수 있다면, 오늘날 사용할 수 있는 최고의 모델인 것 같습니다. 저는 이전에 3.8 27b나 3.6 35B 등으로 작은 게임들을 만들어 본 적이 있습니다. 하지만 항상 '이것은 그냥 작동하는 완전한 제품'이라고 말할 지점까지는 도달하지 못한다고 느꼈습니다. Flash Next에서는 그런 느낌을 받지 못했습니다. 제가 던지는 대부분의 문제들을 해결해 줄 것이라고 느꼈습니다. 코딩과 관련된 일이라면요. 3D 작업에는 사용하지 마세요. 이 모델이 그 용도로 만들어진 것은 아닙니다. 비록 Opus 5.5로 디버깅 속도를 높이는 유혹을 느낄 때도 있었지만, 제가 원하는 방향과는 맞지 않았습니다. 그래서 계속 시도했고, 결국 제가 가지고 있던 모든 버그나 불일치는 모델 자체를 통해 해결되었습니다. 따라서 코드는 100% Qwen 3.8FN이 작성했다고 자신 있게 말할 수 있습니다. 프론티어(frontier)의 도움은 없었습니다. 디버깅 과정 자체는 때때로 고통스러웠습니다.
꽤 잘 작동했던 몇 가지 방법들(물론 이 내용은 대부분의 분들에게는 새로운 정보가 아닐 것이지만, 초보자가 읽을 경우를 대비하여 말씀드립니다): 제가 모델이 무언가를 파악하지 못할 때 짜증이 나서 그냥 코드를 붙여넣어 달라고 요청했습니다. 그러면 약 70%의 확률로 실제 버그까지 스스로 인지하는 경우가 있었습니다. 측정(measure), 검증(validate), 확인(verify), 헤드리스 실행(headless runs)을 하라고 지시해 보세요. 모델은 문제에 대해 생각하느라 엄청난 시간을 낭비할 것입니다. 만약 측정 가능한 결과물(예: 제 경우의 게임)로 구성된 프로젝트를 진행하고 있다면, 항상 '스크립트를 작성하라', '디버그 출력을 작성하라', '코드로 추론하려고 하지 말고 숫자를 보라'고 요청하세요. 사람이 사용할 수 있는 로깅 도구를 만드세요. 제 게임은 통제가 매우 어려워서 시각적 검증이 많이 필요했습니다. 그래서 키보드를 통해 토글할 수 있는 로깅 도구를 만들게 했습니다. 이렇게 하면 버그를 재현한 후, 순수한 숫자들만 모델에게 전달하여 문제를 해결하도록 할 수 있었습니다.
제가 반대하는 것은 AI에게 결정을 맡기는 것입니다. 그것은 저품질(slop)을 만들어내는 지름길입니다. 모델을 세상의 모든 교과서적 지식을 갖추었지만, 다른 사람들(이 경우, 주로 제 개인적인 재미를 위해 제작된 것)이 원하는 바에 대해서는 실제로는 능숙하지 않은 주니어 직원이라고 상상해 보세요. 그리고 그 주니어 직원은 지름길을 택할 것입니다. 지름길이야말로 AI와 작업할 때 가장 주의해야 할 첫 번째 문제입니다. 만약 너무 큰 조각(slice)을 요청하면, 그것을 달성하기 위해 어떤 식으로든 지름길을 택할 가능성이 매우 높습니다. 전체 물리 시뮬레이션 파이프라인을 구축하지 않거나 합의된 아키텍처를 따르지 않는 경우도 마찬가지입니다. 이 지점에서는 누구도 확신할 수 없습니다. 따라서 모델이 무엇을 하고 있는지 항상 주시해야 합니다. 이러한 이유로 저는 모델에게 자율적인 개발 작업을 맡긴 적이 거의 없습니다. 왜냐하면 언제든지 인간의 안내 없이 스스로 무언가를 하기만 해도 꽤 형편없었기 때문입니다.
범위(scope)를 명확히 하세요: 만약 원하는 코드 조각에 대해 모호하게 말한다면, 모델은 범위를 넘어서 더 많은 것을 시작할 것입니다. 무엇을 원하는지 그리고 '오직 그것만을' 원한다는 점을 항상 매우 구체적으로 지정해야 합니다. 그 이상은 안 됩니다.
만약 명시적으로 지시한다면 모델은 이를 존중합니다. 자율적인 실행이 가능한 영역에 대해 말씀드리자면: 저는 게임 플레이나 디자인 선택에 관한 것이 아니라, 완전히 측정 가능한 출력(fully measurable output)이라는 영역을 말하고 싶습니다.
예를 들어, 게임 내 AI는 10K 파라미터(params)를 가진 미니 신경망입니다. 이는 AI에게 넘기기 쉬운 요소였습니다. A) 벤치마크(benchmarks)를 통해 측정 가능하며, B) 학습이 완료되기를 기다리는 시간이 많아, AI가 잠들었다가 (만약 하네스(harness)가 잘 갖춰져 있다면) 다음 단계에 맞춰 깨어날 수 있기 때문입니다. 제가 기본적으로 한 것은 잦은 체크포인트(checkpoint)를 가진 30분간의 학습 세션을 진행하고, 모델이 새로운 게임 내 AI 체크포인트를 사전에 합의된 벤치마크로 테스트하게 한 뒤, 순수한 벤치마크 수치를 기반으로 배치에서 다음 30분 학습을 위한 체크포인트를 선택하는 것이었습니다. '음, 이게 좋을 것 같아'와 같은 추측이 아닙니다. 아니요, 오직 숫자에 기반한 결정입니다. 이를 위해 모델은 자율적으로 작동할 수 있습니다.
제 생각에 사고 과정 보존(Preserve thinking)은 필수적입니다. 저는 이 기능을 끄고 프로젝트를 시작했습니다 (물론 제 하네스는 아직 지원하지 않았습니다). 그 과정은 상당히 느렸습니다. '사고 과정 보존'을 켜자 작업 완료 속도가 급증했고, 컨텍스트(ctx) 문제에 직면하는 일이 거의 없었습니다.
문서 기반 지식: 많은 사람들이 압축(compaction)을 사용하는 것을 알고 있습니다. 저는 개인적으로 사용하지 않습니다. 제 하네스는 심지어 이를 지원하지도 않습니다. 모든 것은 .md 파일을 통해 전달됩니다. 완벽하게 작동했습니다. 제가 가진 파일 중 하나는 하네스가 매번 새로운 턴마다 미리 채워 넣는 파일인데, 끝날 무렵에도 초기 컨텍스트가 10k를 넘지 않았습니다. 따라서 저에게는 문제가 없었습니다.
빌드 도구: 이는 게임 개발(gamedev) 분야에서 일하는 사람이라면 누구나 명확하게 알겠지만, 새로 들어온 동료들에게는 스스로 빌드 도구를 만들어보라고 권합니다. 예를 들어, 이 게임의 다른 사람들처럼 저는 Qwen 3.8FN에게 간단한 모델 에디터를 만들게 했습니다. 이를 통해 레이스카프트(racecrafts)를 제작하고, 간단한 트랙 에디터와, 게임 내 레이싱 AI의 학습 진행 상황을 평가하는 대시보드를 만들었습니다.
Git: 그게 전부입니다. Git을 사용하세요. 로컬 Git을 사용하세요. 만약 Git을 사용하지 않는다면, 어떻게 변경 사항을 관리하는지 모르겠습니다. 이게 다인 것 같은데, 제가 빠뜨린 것이 있다면 댓글로 질문해 주세요.
그리고 짧은 요약(tl;dr)으로 말씀드리자면, Qwen 3.8 Flash Next는 훌륭한 로컬 모델입니다. 이 모델은 frontier의 도움 없이 게임 코드의 100%를 완성했습니다. 매우 유능하지만, 구축하려는 내용과 모든 것이 일치하는지 확인하려면 어느 정도 직접적인 접근(hands-on approach)이 필요합니다. 확인하고 싶다면 다음 링크를 참고하세요: https://mattte.itch.io/hyper-clashers (제출자: /u/hiImMate) [링크] [댓글]
