Qwen3.6 27B 로컬 vs Opus 4.8, 프레임워크 없는 순수 C 언어 기반 복셀 엔진 구현 비교

일요일 실험. 두 모델에 동일한 프롬프트를 입력했습니다. 프레임워크 없이 순수 C 언어로 복셀(voxel) 월드를 구축하는 작업입니다. 엔진도, 게임 라이브러리도, 프레임워크도 없이 오직 컴파일러만 사용합니다. 모델이 직접 청크 메시(chunk meshing), 렌더 루프(render loop), 메모리 관리(memory management)를 수동으로 수행합니다.

왼쪽은 Opus 4.8 기반의 Claude Code입니다. 오른쪽은 vLLM에서 구동되는 Qwen3.6 27B 로컬 모델로, 새로운 NVFP4 양자화(quant) 및 256k 컨텍스트(context)를 적용했습니다. 제가 만든 코딩 에이전트를 통해 RTX 6000 Blackwell 96GB에서 약 130 TPS로 동작합니다.

Opus는 복셀 물리(voxel physics)를 명확히 이해하고 있습니다. 지형이 유지되고, 청크가 정렬되며, 충돌(collision)이 작동합니다. 27B 모델은 컴파일과 렌더링에는 성공하지만, 화면상에서 스스로를 파괴해 버립니다.

예상했던 품질 격차입니다. 하지만 제가 예상하지 못했던 점은 로컬 27B 모델이 C 언어를 아예 다룰 수 있다는 사실이었습니다. 거의 모든 로컬 데모는 프레임워크가 작업을 대신해 주는 Python이나 TypeScript 기반입니다. 그런 것들을 모두 제거하면 로컬 포인터(raw pointers)와 수동 할당(manual allocation)만 남게 되는데, 저는 양자화된 모델이 이 지점에서 무너질 것이라고 가정했습니다. 하지만 그렇지 않았습니다. 거칠긴 해도, 빌드되고 실행됩니다.

모두가 최첨단(frontier)의 경주를 지켜봅니다. 하지만 밑바닥이 따라잡고 있다는 사실은 아무도 말하지 않습니다. 2년 전 이 프롬프트를 로컬 모델에 넣었다면 세그폴트(segfault)가 발생했을 것입니다. 이제는 책상 아래 그래픽 카드에서 여전히 실행되는, 비록 망가졌을지언정 작동하는 세계를 보여줍니다. 천장은 거의 움직이지 않았지만, 바닥은 전력 질주했습니다.