생성형 AI는 게임이 아닌 형태를 만든다: 제약 조건의 격차와 이를 해결하는 아키텍처

나는 한 도구를 벤치마킹하기 위해 자리에 앉았으나, 결국 벽의 지도 하나를 얻게 되었다.

Higgsfield는 Minecraft "프롬프트 투 빌드 (prompt-to-build)" 기능을 출시했다. 프롬프트를 입력하면 약 1분 후에 게임 월드 내에 구조물이 생성되는 기능이다. 나는 8개의 건축 프롬프트를 실행하여 각각의 점수를 매기고 결과를 살펴보았다. 이 작업의 시작점은 "이 도구가 얼마나 훌륭한가"였으나, 결과적으로는 더 유용한 결론에 도달했다. 왜냐하면 실패의 형태 (shape) 자체가 생성형 AI가 게임 콘텐츠에서 왜 벽에 부딪히는지, 그리고 이를 극복하기 위한 아키텍처는 어떤 모습이어야 하는지에 대한 명확한 통찰을 보여주었기 때문이다.

한 문장으로 요약하자면: 생성 모델은 **그럴듯함 엔진 (plausibility engines)**이며, 게임은 **정확성 엔진 (correctness engines)**을 필요로 한다. 이 둘은 동일한 기계가 아니며, 한 쪽을 확장(scaling)한다고 해서 다른 쪽을 얻을 수 있는 것도 아니다.

요약 (tl;dr) — AI Minecraft 빌더는 약 1분 만에 인식 가능한 단일 형태(구체, 탑, 실제로 걸어 들어갈 수 있는 문이 있는 성문)를 생성했지만, 정확한 크기, 지정된 재질, 문의 위치를 놓쳤다. 또한 내가 제시한 세 가지 다중 객체 장면(multi-object scenes)을 구성하는 데 실패했으며, "용암 없음" 규칙을 공허하게만 만족했다(액체 자체를 전혀 배치하지 않음). 그리고 출력물이 프롬프트를 충족했는지에 대한 어떠한 신호도 나타내지 않았다. 이러한 패턴은 생성 모델의 특징을 보여준다: 즉, 형태 (forms) 의 분포에 대한 샘플러(samplers)라는 점이다. 게임 콘텐츠는 형태 샘플러가 구조적으로 결여하고 있는 세 가지를 요구한다: 이산적 제약 조건 충족 (discrete constraint satisfaction), 구성적 구조 (compositional structure), 그리고 검증을 동반한 기능적 정확성 (functional correctness with verification)이다. 규모를 확장(Scaling)하는 것은 그럴듯한 형태를 추가할 뿐, 이 세 가지 역량을 추가하지는 않는다. 이 격차를 메우는 아키텍처는 연속적인 것(continuous)과 이산적인 것(discrete)을 분리한다: 심볼릭 플래너 (symbolic planner)가 씬 그래프 (scene graph)와 명시적 제약 조건을 방출하면, 생성 모델이 객체별 형태를 채우고, 솔버 (solver)가 제약 조건을 충족하도록 객체를 배치하며, 검증기 (verifier)가 결과를 확인하고 실패를 수정한다. 생성기(generator)로부터는 그럴듯함을, 구조와 검증으로부터는 정확성을 얻는 것이다.

증거, 짧게 요약하자면

전체 실습 벤치마크(benchmark), 프롬프트별 점수 및 도표는 companion findings post에서 확인할 수 있습니다. 압축된 버전만으로도 논거를 뒷받침하기에는 충분합니다.

성공한 사례. 강력한 시각적 사전 지식 (visual prior)을 가진 단일하고 응집력 있는 형태는 빠르고 인식 가능한 형태로 나타났습니다. "거대한 구체 (A giant sphere)"는 깔끔한 복셀 (voxel) 구체를 생성했습니다. 망루 (watchtower)는 탑으로 해석되었습니다. "두 개의 탑과 플레이어가 걸어갈 수 있는 중앙 게이트가 있는 성문 (A gatehouse with "two towers and a central gate players can walk through")"은 약 1분 만에 정확히 그 모습으로 생성되었으며, 실제로 걸어 들어갔을 때 게이트는 진정으로 통과 가능한 상태였습니다.

가장 강력한 결과물. 성문 (castle gatehouse)은 명명된 하위 부분들을 가진 하나의 응집력 있고 전형적인 (canonical) 형태이며, 빠르고 훌륭하게 생성되었습니다.

실패한 사례. 프롬프트가 이산적이고(discrete) 확인 가능한 요구 사항에 의존하는 순간, 그 요구 사항들은 무너졌습니다. "주로 나무와 돌을 사용하고, 남쪽에 입구가 있으며, 내부를 걸어 다닐 수 있는 15x15 블록 크기의 오두막 (A 15 by 15 block cottage using mostly wood and stone, entrance on the south side, inside walkable)"은 문이 없는 울퉁불퉁한 회색 벽으로 돌아왔으며, 15x15보다 훨씬 넓고, 나무도 없었으며, 들어갈 방법도 없었습니다.

가장 제약이 많았던 프롬프트가 최악의 결과를 낳았습니다. 크기, 재료, 문, 폐쇄 구조 등 모든 이산적인 요구 사항이 실패했습니다.

다중 객체 장면(Multi-object scenes)은 세 가지 프롬프트에 걸쳐 세 가지 방식으로 실패했습니다. 하나는 출력 없이 멈췄고, 하나는 극도로 일관성 없는 크기로 흩어졌으며, 하나는 두 개의 텐트와 캠프파이어를 하나의 청록색 더미로 붕괴시켰습니다. 그리고 부정적 제약 조건("유리, 용암, 물 또는 레드스톤을 사용하지 마세요")은 빌더가 액체를 전혀 배치하지 않았기 때문에 결과적으로만 "준수"되었습니다. 용암 색상의 띠는 게임 내에서 액체 없이 고체 orange_concrete로 읽혔습니다. 그 규칙은 규칙을 따름으로써가 아니라, 팔레트의 제한으로 인해 공허하게(vacuously) 충족되었습니다.

부정적 제약 조건이 공허하게 충족됨: 해석되어 준수된 "사용하지 마세요"가 아니라, 색상이 일치하는 고체 블록임.

이 모든 것의 밑바탕에는 두 가지 구조적 사실이 자리 잡고 있습니다. 이 동작은 **메시 생성 및 복셀화 파이프라인 (mesh-generation plus voxelization pipeline)**과 일치합니다: 하나의 3D 메시를 생성하고, 이를 복셀화(voxelize)한 뒤, 블록 팔레트에 색상을 매핑하여 배치하는 방식입니다. (제가 역컴파일하거나 추적한 것은 아니므로, 이는 확인된 사실이 아닌 가장 가능성 높은 설명으로 간주하십시오.) 그리고 워크플로우 어디에도 **검증 신호 (validation signal)**가 없었습니다. 출력물이 크기, 재료, 문 또는 기능을 충족하는지 나타내는 요소가 워크플로우 내에 전혀 없었습니다.

이 두 가지 사실을 기억하십시오. 이것이 축소된 형태의 핵심 논거입니다: 하나의 형태, 구조 없음, 확인 없음.

왜 이런 일이 발생하는가: 그럴듯함(plausibility)은 정확함(correctness)이 아니다

이 오두막을 버그, 즉 더 많은 학습이 필요한 모델로 해석하고 싶은 유혹이 생길 수 있습니다. 하지만 그것은 모델이 무엇인지 잘못 읽는 것입니다.

A 생성형 3D 모델은 **학습된 형태의 분포에 대한 샘플러 (sampler over a learned distribution of forms)**입니다. 학습은 텍스트 조건에 따른 그럴듯한 모양들의 매니폴드(manifold)를 모델에게 가르치며, 추론(inference)은 그로부터 한 점을 추출합니다. 이것은 "X의 그럴듯한 사례를 하나 보여줘"라는 하나의 작업에 적합한 기계이며, 실제로 그 일을 매우 잘 수행합니다. 구(sphere)와 성문(gatehouse)이 바로 그 작업을 잘 수행한 사례입니다.

게임 콘텐츠는 다른 종류의 작업을 요구합니다. 즉, "그럴듯한 인스턴스 (plausible instance)"가 아니라 "이러한 요구 사항을 충족하는 (satisfies these requirements) 인스턴스"를 요구합니다. 그리고 게임이 부과하는 요구 사항은 형태 샘플러 (form-sampler)가 처리할 수 있는 메커니즘이 없는 세 가지 유형으로 나뉩니다.

1. 이산적 제약 조건 (Discrete constraints)

"15×15". "남향 문". "용암 없음". 이것들은 이산적이고 상징적인 술어 (symbolic predicates)입니다. 이것들은 충족되거나 되지 않으며, 어떤 상태인지 확인할 수 있습니다.

연속적 샘플러 (continuous sampler)는 이산적 술어를 "넣을" 곳이 없습니다. 이 샘플러는 "15 곱하기 15"라는 단어와 분포적으로 "일치하는 (consistent with the words)" 출력물, 즉 작고 정사각형에 가까운 형태를 만들어낼 수는 있지만, "점유 면적이 15×15이다"라는 술어를 "충족 (satisfy)"할 수는 없습니다. 왜냐하면 아키텍처 내의 그 어떤 것도 해당 술어를 충족하고 확인해야 할 하나의 대상으로 표현하지 않기 때문입니다. 이는 이미지 모델이 정확한 손가락 개수나 읽을 수 있는 텍스트를 구현하지 못하는 것과 동일한 근본 원인입니다. 개수와 글자는 이산적이며, 그럴듯함 샘플러 (plausibility sampler)는 이를 충족하는 대신 근사 (approximate)할 뿐입니다. 오두막에 문이 없는 것은 학습의 공백이 아닙니다. 형태 샘플러가 위치 술어 (positional predicate)를 준수하기를 기대하는 것은 범주 오류 (category error)입니다.

2. 구성적 구조 (Compositional structure)

단일 객체는 하나의 형태입니다. 하지만 "장면 (scene)"은 그래프 (graph)입니다. 객체는 노드 (nodes)가 되고, 공간적 관계는 에지 (edges)가 됩니다. "나무가 각각의 사이에 놓인 길을 따라 늘어선 세 채의 집"은 구조화된 배열이지, 하나의 모양이 아닙니다.

단일 구조의 메쉬 생성기 (monolithic mesh generator)는 해당 그래프를 구축할 노드 및 에지 표현 방식이 없습니다. 장면을 요청받았을 때, 이 생성기가 사용할 수 있는 방법은 단 하나뿐입니다. 전체 배열을 하나의 형태로서 환각 (hallucinate)하고 이를 복셀화 (voxelize)하는 것입니다. 세 가지 장면 실패 사례는 그 방식이 저하되거나, 멈추거나, 흩어지거나, 붕괴되는 세 가지 양상이지만, 하나의 원인을 공유합니다. 즉, 장면 그래프 (scene graph)가 없기 때문에 구성 (composition)이 존재하지 않으며, 오직 요소들을 암시하는 덩어리 (blob)만 존재할 뿐이라는 점입니다. "장면을 만들 수 없다"는 표현은 너무 강합니다. "장면이 구성될 수 있는 구조화된 표현 방식 (structured representation)이 없다"가 정확한 표현입니다.

3. 기능적 정확성, 그리고 누락된 검증기 (Functional correctness, and the missing verifier)

"플레이어가 게이트를 통과할 수 있다"는 것은 기능적 (functional) 속성입니다. 이를 기하학적 형상만 보고 눈으로 확신을 가지고 읽어낼 수는 없습니다. 테스트를 하거나, 그 경로를 직접 걸어봄으로써 확인해야 합니다. 성문(gatehouse gate)이 통과 가능한 것으로 판명되었을 때, 그것은 형상(shape)이 결과로 나타난 것이지, 시스템이 해당 기능이 유지되고 있음을 알고 있거나 확인한 것이 아닙니다. 형상 샘플러(form-sampler)에는 기능(function)이라는 개념이 없으며, 더 결정적으로, 생성 후에 "출력이 요청을 충족했는가?"라고 묻는 루프(loop)가 없습니다.

그 누락된 루프가 가장 핵심적인 부분입니다. 운 좋게 제약 조건을 자주 맞추는 모델이라 할지라도 검증기(verifier) 없이는 신뢰할 수 없습니다. 왜냐하면 운 좋게 나온 결과물과 실패한 결과물을 구분할 수 있는 것이 아무것도 없기 때문입니다. 워크플로우에는 점수도, 자기 점검(self-check)도, "이 빌드는 15×15가 아니라 14×16이다"라는 식의 확인도 없었습니다. 검증 없는 생성은 성공했는지 여부를 알려줄 수 없으며, 이는 결과가 성공적이었을 때조차 신뢰할 수 없음을 의미합니다.

통합적 진단 (The unifying diagnosis)

이 세 가지를 종합하면 진단은 한 문장으로 요약됩니다: 생성 모델은 그럴듯함 (plausibility)을 최적화하지만, 게임 콘텐츠는 정확성 (correctness)을 요구하며, 정확성은 이산적(discrete)이고, 구성적(compositional)이며, 기능적(functional)입니다. 그럴듯함은 연속적인 매니폴드 (continuous manifold) 상에 존재합니다. 반면 정확성은 상징적(symbolic)이고, 구조화되어 있으며, 확인 가능합니다. 이들은 서로 다른 수학적 대상이며, 현재의 아키텍처는 전자를 위해 구축되었습니다.

스케일링(Scaling)만으로는 이 격차를 메울 수 없는 이유

2026년의 반사적인 반응은 "다음 모델이 이를 해결할 것이다"입니다. 하지만 이 격차에 있어서는, 동일한 아키텍처를 스케일링하는 것이 격차를 줄일 이유는 거의 없으며, 오히려 줄이지 못할 이유가 있습니다. 다른 아키텍처라면 가능할지 모르나, 더 큰 형상 샘플러(form-sampler)는 해결하지 못할 것입니다.

더 많은 파라미터(parameters)와 더 많은 데이터는 샘플러(sampler)가 형태 분포(form distribution)로부터 더 그럴듯한 형상을, 더 충실하게 그려내도록 만듭니다. 이는 아키텍처가 이미 최적화하고 있는 축(axis)에서의 실질적인 진보입니다. 하지만 이것이 이산적인 제약 조건 표현(discrete constraint representation)을 추가하는 것은 아닙니다. 왜냐하면 훈련 목적 함수(training objective)가 모델에게 술어(predicate)를 만족하고 확인하도록 요구하지 않기 때문입니다. 또한 이것이 씬 그래프(scene graph)를 추가하는 것도 아닙니다. 출력값은 여전히 하나의 메쉬(mesh)이기 때문입니다. 검증기(verifier)를 추가하는 것도 아닙니다. 검증은 생성기(generator)가 수행하도록 설계되지 않은 별개의 연산이기 때문입니다.

형태 사전 지식(form prior) 덕분에 개선된 벤치마크 부분과 그렇지 않은 부분을 비교해 보면 이 형상을 확인할 수 있습니다. 더 전형적인(canonical) 형태인 성문(gatehouse)은 망루(watchtower)보다 더 잘 만들어졌습니다. 스케일링(Scaling)은 그 축을 따라 모든 것을 밀어붙입니다. 즉, 더 낫고 더 전형적인 형태를 만드는 것입니다. 오두막(cottage)의 문은 그 축에 전혀 속해 있지 않습니다. 아무리

이 모든 것들은 동일한 분리(split)를 보여줍니다: 즉, 그럴듯함(plausible) (연속적(continuous), 분포적(distributional), 생성기(generator)가 제공하는 것) 대 정확함(correct) (이산적(discrete), 구조적(structured), 기능적(functional), 도메인(domain)이 요구하는 것)의 대립입니다. 게임 제작은 차원적(dimensional), 구성적(compositional), 기능적(functional)이라는 세 가지 정확함의 속성을 단 1분 내외의 검사 가능한 생성물 안에 모두 묶어 놓았기 때문에 매우 생생한 사례가 됩니다. 이 교훈은 모든 프로덕션급(production-grade) 생성 콘텐츠에 일반화될 수 있습니다.

격차를 해소하는 아키텍처

만약 하나의 모델이 그럴듯함 엔진(plausibility engine)과 정확함 엔진(correctness engine)의 역할을 동시에 수행할 수 없다면, 모델에게 그것을 요구하는 것을 멈추십시오. 연속적인 데이터와 이산적인 데이터가 각각 그에 최적화된 머신(machine)으로 향하도록 파이프라인(pipeline)을 분리하십시오.