2026년 7월 25일에 확인된 증거입니다. 이 비교는 벤더의 주장, 일반적인 코딩 증거, 그리고 네이티브 Unreal Engine 구현 능력을 구분합니다. 이들은 서로 동일한 것이 아닙.

Kimi K3, Claude Opus 5, 그리고 Qwen3.8-Max-Preview는 모두 코딩, 시각적 반복 (visual iteration), 장기 실행 에이전트 (long-running agents), 또는 3D 생성과 관련하여 이례적으로 강력한 주장을 내세우며 등장했습니다. 이는 게임 개발자들에게 피할 수 없는 질문을 던지게 합니다:

Unreal Engine 5 게임을 제작하는 데 실제로 가장 좋은 AI 모델은 무엇인가?

짧은 답변은 다음과 같습니다: Claude Opus 5는 현재 신뢰할 수 있는 에이전트 기반 엔지니어링 (agentic engineering) 및 3D 재구성 (3D reconstruction)에 대해 가장 강력한 공개 증거를 보유하고 있습니다; Kimi K3는 플레이 가능한 3D 게임 및 비전 인 더 루프 (vision-in-the-loop) 반복에 대해 가장 명확한 자체 주장을 가지고 있습니다; Qwen3.8-Max-Preview는 대규모 멀티모달 (multimodal) 엔지니어링 작업에 유망하지만, 공식적인 Unreal 구현 증거가 없는 프리뷰 상태로 남아 있습니다.

더 중요한 답변은 이러한 모델들의 발표 자체만으로는 해당 모델이 유효한 네이티브 Unreal 프로젝트를 전달하고, Blueprint 또는 C++를 컴파일하며, 에셋을 쿠킹 (cook assets)하고, 빌드를 패키징하며, 그 결과를 재현할 수 있다는 것을 증명하지 못한다는 점입니다. Unreal 작업의 경우, 실행 환경 (execution environment)이 모델 지능의 미세한 차이보다 더 중요한 경우가 많습니다.

요약 (TL;DR): Unreal 특화 판결

따라서 저의 실질적인 순위는 작업에 따라 달라집니다:

1. 어려운 코드, 디버깅 및 자기 검증 (self-verification)을 위해: Claude Opus 5.
2. 시각적 반복 (visual iteration) 및 개방형 생태계 실험을 위해: Kimi K3.
3. 대규모 컨텍스트 (large-context), 멀티모달 (multimodal), 비용 민감도 평가를 위해: Qwen3.8-Max-Preview.
4. 실제로 플레이 가능한 네이티브 Unreal 결과를 위해: 실제로 Unreal을 열고, 스크린샷과 로그를 검사하며, 프로젝트를 수정하고, 빌드를 패키징 (package)할 수 있는 워크플로우를 선택하세요. 모델의 마케팅 정보만 보고 선택하지 마십시오.

첫째, “3D 게임 제작”의 의미를 정의해야 합니다

인상적인 많은 AI 게임 데모들은 Three.js, Babylon.js, WebGL 또는 커스텀 JavaScript 런타임을 사용하는 브라우저 프로젝트입니다. 그것들은 훌륭한 결과물일 수 있지만, Unreal Engine 프로젝트는 아닙니다.

신뢰할 수 있는 Unreal 평가를 위해서는 다음 사항이 모두 요구되어야 합니다:

• .uproject 파일이 포함된 유효한 네이티브 프로젝트.
• 선택한 범위에 맞는 올바른 Config, Content, Source 및 플러그인 구조.
• 누락된 종속성(dependencies) 없이 열리는 맵.
• 작동하는 입력(input), 카메라, 충돌(collision) 및 작은 게임플레이 루프.
• 해당 시스템이 사용되는 곳에서 컴파일되는 블루프린트 (Blueprint) 및 C++.
• 지정된 타겟 플랫폼에 대해 올바르게 쿡 (cook)되는 에셋 (Assets).
• 에디터 외부에서 실행되는 패키징된 빌드.
• 단발성 영상이 아닌 로그, 스크린샷 및 재현 가능한 핸드오프 (handoff).

Epic의 패키징 문서에서는 **빌드 (Build), 쿡 (Cook), 스테이지 (Stage), 패키지 (Package), 배포 (Deploy), 실행 (Run)**을 별개의 작업으로 설명합니다. 매력적인 스크린샷은 이 파이프라인의 아주 일부분만을 보여줄 뿐입니다.

이러한 구분은 비교에서 가장 중요한 부분입니다. 최첨단 모델 (frontier model)이 뛰어난 C++를 작성할 수 있더라도, Unreal 에디터를 볼 수 없거나, 에셋 참조를 해결하지 못하거나, 프로젝트 파일을 재생성하지 못하거나, 쿡 에러를 검사하지 못하거나, 패키징된 실행 파일을 다시 실행하지 못한다면 실패할 수 있습니다.

출시 상태: 실제로 무엇을 사용할 수 있는가?

Kimi K3

Moonshot AI는 2026년 7월 17일, 네이티브 비전 (native vision) 기능과 100만 토큰의 컨텍스트 윈도우 (context window)를 갖춘 2.8조 파라미터 모델인 Kimi K3를 선보였습니다. K3는 Kimi, Kimi Work, Kimi Code 및 Kimi API를 통해 사용할 수 있습니다. 기술 블로그에 따르면 전체 모델 가중치 (model weights)는 2026년 7월 27일까지 공개될 예정입니다.

이 날짜는 중요합니다. 7월 25일 기준으로 호스팅된 제품과 API는 사용 가능하지만, "오픈 모델 (open model)"을 "전체 가중치를 어디서나 즉시 다운로드할 수 있다"는 의미로 해석해서는 안 됩니다.

Kimi의 가장 핵심적인 주장은 이례적일 정도로 직접적입니다. K3는 3D 추론 (3D reasoning), 코딩 (coding), 그리고 비전 (vision)을 결합하여 플레이 가능한 인터랙티브 경험을 생성하며, 코드와 라이브 스크린샷을 교차하며 사용하는 비전 인 더 루프 (vision-in-the-loop) 워크플로우를 제공합니다. 홈페이지 또한 플레이 가능한 멀티플레이어 및 3D 게임 제작을 명시적으로 홍보하고 있습니다.

이는 게임 개발과 매우 밀접한 관련이 있습니다. 다만, 아직 Unreal 엔진에 특화된 증거는 아닙니다.

Claude Opus 5

Anthropic은 2026년 7월 24일 Claude Opus 5를 출시했습니다. 이는 Claude 제품군과 API를 통해 claude-opus-5로 사용할 수 있으며, Anthropic이 Opus 4.8에 책정했던 것과 동일한 기본 API 가격으로 제공됩니다.

이번 출시는 장기 실행 소프트웨어 에이전트 (software agents), 검증 (verification), 컴퓨터 사용 (computer use), 전문적인 작업, 그리고 개선된 시각적 출력 (visual output)을 강조합니다. 3D 작업과 특히 관련이 깊은 두 가지 증거는 다음과 같습니다:

• Anthropic의 평가에서, Opus 5는 원시 픽셀 (raw pixels)에서 기하학적 구조 (geometry)를 추출하기 위해 자체적인 컴퓨터 비전 파이프라인 (computer-vision pipeline)을 구축한 후, 기계 부품을 3D FreeCAD 모델로 재구성했습니다.
• 한 얼리 액세스 (early-access) 파트너는 Opus 모델로부터 본 적 없는 최고의 애니메이션, 게임 및 3D 작업물을 보고했다고 보고했습니다.

Opus 5는 또한 성공을 보고하기 전에 자신의 작업을 스스로 점검하는 것에 이례적일 정도로 중점을 둡니다. 이러한 동작은 모델이 "코드가 그럴듯해 보인다"와 "에디터가 컴파일했고 패키징된 빌드가 실행되었다"를 구분해야 하는 Unreal 환경에서 매우 가치 있습니다.

다시 한번 말씀드리지만, 두 사례 모두 공식적으로 발표된 네이티브 Unreal 패키징 벤치마크는 아닙니다.

Qwen3.8-Max-Preview

현재 접근 가능한 모델은 최종적인 오픈 웨이트 (open-weight) Qwen3.8 출시 버전이 아닌 Qwen3.8-Max-Preview입니다. Alibaba Cloud의 개발자 커뮤니티 개요에 따르면, 이는 엔지니어링, 장기 실행 에이전트 (long-running agents), 대규모 리포지토리 (large repositories), 그리고 이미지, 비디오, 문서 이해를 위한 2.4조 파라미터 규모의 멀티모달 (multimodal) 프리뷰 모델입니다. 최종 가중치 (weights) 공개는 향후 과제로 남아 있는 반면, 현재는 선정된 Alibaba/Qwen 코딩 및 API 인터페이스를 통해 사용할 수 있습니다.

Qwen의 현재 공개적인 포지셔닝은 일반적인 엔지니어링 및 웹 개발 (WebDev) 분야에서 가장 강력합니다. 이는 C++ 모듈 읽기, 서브시스템 아키텍처 제안, 빌드 스크립트 리팩토링 (refactoring), 또는 스크린샷 해석과 같은 Unreal 작업으로 전이될 수 있습니다. 하지만 Qwen3.8이 네이티브 .uproject 파일을 생성하거나, 블루프린트 (Blueprint) 그래프를 컴파일하거나, 에셋을 쿠킹 (cook) 하거나, 프로덕션 Unreal 빌드를 패키징 (package) 한다는 공식적인 주장은 찾을 수 없었습니다.

이를 검증된 Unreal 생성기가 아닌, 유망한 프리뷰 모델로 취급하십시오.

준비도 매트릭스: 주장 대 Unreal 실행 능력

아래의 라벨은 합성 벤치마크 점수가 아닌 증거 등급입니다:

• Strong (강함): 현재의 퍼스트 파티 (first-party) 릴리스 또는 구체적인 사례에 의해 직접적으로 지원됨.
• Moderate (보통): 인접한 기능에 의해 간접적으로 지원됨.
• Unproven (미검증): 해당 요구 사항에 특화된 현재의 공개적 증거가 없음.

이 표는 의도적으로 보수적으로 작성되었습니다. 일반적인 코딩 벤치마크는 성능을 예측하는 데 도움이 될 수 있지만, 바이너리 에셋 (binary assets), 에디터 전용 API (editor-only APIs), 플러그인 호환성 (plugin compatibility), 셰이더 컴파일 (shader compilation), 쿠킹 규칙 (cook rules), 타겟 SDK (target SDKs), 또는 패키징된 런타임 동작 (packaged runtime behavior)을 테스트하지는 않습니다.

Unreal 워크플로우에서 각 모델이 어떻게 동작할 것인가

Claude Opus 5: 가장 강력한 엔지니어링 리드 (engineering lead)

Opus 5는 단순한 생성량보다 판단력이 더 중요한 작업에 가장 적합해 보입니다:

• 멀티 모듈 Unreal C++ 버그 추적 (tracing);
• 편집 전 안전하지 않은 아키텍처에 대한 의문 제기;
• Gameplay Ability System (GAS) 구현 계획 수립;
• 빌드 (build), 쿡 (cook), 런타임 (runtime) 로그 해석;
• 수정 사항이 근본 원인 (root cause)을 해결하는지 확인;
• 스크린샷 및 도구 출력값을 활용한 반복 (iteration);
• 완료를 선언하기 전 인수인계 (handoff) 검토.

Opus 5의 가장 큰 장점은 가장 예쁜 3D 장면을 그려낼 수 있다는 점이 아닙니다. 그것은 코딩, 컴퓨터 사용 (computer use), 반복 (iteration), 그리고 검증 (verification)의 결합입니다.

위험 요소는 이것이 자동으로 Unreal 에셋에 대한 접근 권한을 부여한다고 가정하는 것입니다. 언어 모델은 엔진을 인식하는 도구 경로 (engine-aware tool path) 없이는 바이너리 .uasset 파일을 신뢰성 있게 생성하거나 수리할 수 없습니다. Unreal, 소스 제어 (source control), 로그, 스크린샷, 그리고 명시적인 통과/실패 (pass/fail) 체크를 제공하십시오.

Kimi K3: 가장 강력한 3D 네이티브 주장

K3는 플레이 가능한 3D 제작과 관련하여 가장 명확한 벤더 주장을 펼치고 있습니다. K3의 네이티브 비전 (native vision), 긴 컨텍스트 (long context), 터미널 오케스트레이션 (terminal orchestration), 그리고 스크린샷 루프는 다음과 같은 작업에 적합합니다:

• 긴 세션에 걸쳐 플레이 가능한 프로토타입 제작;
• 구도 (composition), 내비게이션 (navigation), 시각적 결함에 대한 반복 작업;
• 방대한 디자인 브리프 (design brief) 및 리포지토리 (repository) 컨텍스트 유지;
• 코드, 연구, 에셋 준비 및 테스트의 조정;
• 최소한의 감독으로 게임 개발 작업을 수행.

K3가 발표한 제한 사항 또한 유의해야 합니다. Moonshot은 하네스 (harness)가 예상되는 사고 이력 (thinking history)을 보존하지 않을 경우 품질이 불안정해질 수 있으며, 지침이 모호할 때 모델이 과도하게 주도적일 수 있다고 경고합니다. Unreal 워크스페이스에서는 권한, 파일 경계, 플러그인 정책, 허용된 명령, 그리고 패키징 타겟 (packaging targets)이 명시적이어야 함을 의미합니다.

K3는 게임 제작 에이전트 내부의 훌륭한 엔진이 될 수 있습니다. 현재의 증거만으로는 베이스 모델 단독으로 Unreal 파이프라인 (pipeline)이 될 수 있음을 보여주지는 않습니다.

Qwen3.8-Max-Preview: 유망하지만, 프리뷰로서 평가할 것

Qwen3.8-Max-Preview는 작업에 매우 큰 리포지토리 (repository), 혼합된 문서 및 시각 자료, 또는 반복적인 엔지니어링 작업이 포함될 때 매력적입니다. 가능한 Unreal에서의 활용 사례는 다음과 같습니다:

• 프로젝트 소스, 설정, 빌드 파일 및 기술 설계 문서를 함께 읽기;
• 리뷰 루프 (review loop) 하에서 C++ 또는 자동화 스크립트 생성;
• 스크린샷, 로그 및 사양 (specifications) 분석;
• 마이그레이션 (migrations) 또는 리포지토리 전반의 변경 사항 계획;
• 더 강력한 검증기 (verifier)가 결과를 검토하기 전에 더 저렴한 탐색적 패스 (exploratory passes) 실행.

문제는 증거의 성숙도입니다. 제가 찾은 공개 자료들은 프리뷰 액세스 (preview access), 일반적인 엔지니어링, 롱 에이전트 (long agents), 그리고 웹 개발 (WebDev)을 강조할 뿐, 재현 가능한 Unreal 결과에 대해서는 강조하지 않습니다. 최종 릴리스, 모델 카드 (model card), 그리고 네이티브 엔진 테스트가 제공될 때까지 Qwen3.8은 광범위한 주장보다는 더 엄격한 체크포인트 (checkpoints)를 통해 평가되어야 합니다.

실제로 의미 있는 재현 가능한 Unreal 벤치마크

모델을 공정하게 비교하고 싶다면, 각 모델에 동일한 환경, 프롬프트 (prompt), 시간 예산, 도구 권한, 그리고 깨끗한 Unreal 프로젝트를 제공하십시오.

다음은 컴팩트한 벤치마크입니다:

플레이어가 산과 물이 있는 환경을 탐험하고, 세 개의 체크포인트에 도달하며, 완료 화면을 보는 작은 3인칭 Unreal 5 게임을 제작하십시오. 재배포 가능한 자산 또는 생성된 자산만 사용하십시오. 재시작 액션을 추가하고, Windows용으로 패키징하며, 패키징된 빌드를 실행한 후 프로젝트, 빌드 로그, 런타임 로그, 그리고 5개의 스크린샷을 제공하십시오.

관찰 가능한 게이트 (gates)로 점수를 매기십시오:

인간의 개입 횟수, 도구 호출 (tool calls), 경과 시간, 재시도 횟수, 그리고 해결되지 않은 경고 (warnings)의 수를 기록하십시오. 그것이 모델의 일반적인 코딩 순위보다 더 많은 것을 알려줄 것입니다.

그렇다면 Unreal 개발자는 어떤 모델을 선택해야 할까요?

이미 역량 있는 도구 환경을 갖추고 있으며, 현재 가장 강력한 엔지니어링 판단력, 어려운 디버깅 (debugging), 또는 세심한 검증이 필요하다면 Claude Opus 5를 선택하십시오.

시각적 반복 (visual iteration), 긴 컨텍스트 (long context), 그리고 3D/게임 실험이 핵심이며, 여러분의 하네스 (harness)가 모델의 예상된 히스토리를 보존하고 자율성을 제어할 수 있다면 Kimi K3를 선택하십시오.

리포지토리 분석 (repository analysis), 자동화 (automation), 또는 비용 효율적인 탐색을 위해 대규모 멀티모달 모델 (large multimodal model)을 평가하고자 한다면 Qwen3.8-Max-Preview를 선택하십시오. 단, 프리뷰 (preview) 단계의 리스크와 Unreal에 대한 네이티브한 검증 부족은 감수해야 합니다.

본격적인 작업을 위해서는 멀티 모델 파이프라인 (multi-model pipeline)이 더 나을 수 있습니다. 하나의 모델이 초안을 작성하고 구현하면, 다른 모델이 변경 사항을 검토하고, Unreal 자체가 컴파일 (compile), 쿡 (cook), 패키징 (package), 그리고 런타임 테스트 (runtime tests)를 통해 신뢰할 수 있는 단일 진실 공급원 (source of truth) 역할을 수행하는 방식입니다.

더 깊은 결론: 헤드라인보다 중요한 것은 하네스 (harness)입니다

2026년의 모델 경쟁은 3D 데모를 더 빠르고 인상적으로 만들고 있습니다. 하지만 Unreal 게임 개발은 단 한 번의 세대적 도약으로 이루어지지 않습니다. 그것은 소스 코드 (source code), 블루프린트 (Blueprints), 에셋 (assets), 에디터 상태 (editor state), 로그 (logs), 렌더링 (rendering), 성능 (performance), 패키징 (packaging), 그리고 런타임 동작 (runtime behavior)에 걸친 피드백 루프 (feedback loop)입니다.

따라서 최고의 Unreal AI 시스템은 단순히 파라미터 수 (parameter count)가 가장 많거나 가장 매력적인 데모를 보여주는 모델이 아닙니다. 다음과 같은 능력을 갖춘 시스템이 최고의 시스템입니다:

1. 네이티브 프로젝트를 생성할 수 있는 능력
2. 실제 에디터와 런타임을 관찰할 수 있는 능력
3. 로그와 스크린샷을 사용하여 실패를 복구할 수 있는 능력
4. 결과물을 패키징하고 실행할 수 있는 능력
5. 정직한 한계점을 명시하며 편집 가능한 아티팩트 (artifacts)를 반환할 수 있는 능력