우리 게임 프로젝트 — 엔진 계층은 Rust + Bevy, 게임플레이는 Lua, 개발은 AI 에이전트, 아트는 Floniks가 생성 — 를 사람들에게 보여줄 때마다 첫 질문은 거의 항상 같습니다.
"흥미롭네요. 그런데… 에디터는 어디 있죠?"
솔직히 말하면, 우리도 흔들렸습니다. 지난 20년간 "게임 엔진"은 하나의 고정된 그림을 의미해 왔습니다. 왼쪽에 씬 트리, 가운데에 뷰포트, 오른쪽에 인스펙터, 아래에 애셋 브라우저. Unity가 그렇고, Godot이 그렇고, Unreal과 Cocos도 그렇습니다. 그 그림 없이 엔진이라고 부를 수 있을까요?
에이전트와 함께 미니게임 8개를 실제로 완성하고 — AI가 생성한 스프라이트, 배경, UI 아트가 Floniks의 MCP 서버를 통해 흘러들어오는 것을 보고 — 나서야 답이 분명해졌습니다. 우리의 개발 방식에서 에디터는 아직 짓지 못한 인프라가 아니라 부채입니다. "에디터 없음"은 빚이 아니라 우리의 토대입니다.
이 글은 그 이유에 대한 성찰이며, 더 중요하게는 에디터 대신 아트와 비주얼에 무엇을 장착했는지에 대한 목록입니다. 아래의 모든 주장은 로드맵 슬라이드가 아니라 오픈소스 저장소의 실제 파일로 뒷받침됩니다.
에디터란 결국 무엇인가
향수를 걷어내면, 게임 에디터의 본질은 I/O 어댑터 — 인간의 손(마우스, 드래그, 슬라이더)을 씬 데이터에 연결하는 장치입니다.
에디터가 최적화하는 것은 인간의 입력 대역폭입니다. 사람은 position: (312.5, -87.0)을 머릿속에 그릴 수 없으니 드래그해서 눈으로 확인해야 합니다. 4천 개의 API를 외울 수 없으니 모든 속성을 패널에 펼쳐주는 인스펙터가 필요합니다. 감으로는 색을 맞출 수 없으니 컬러 피커가 필요합니다. 에디터의 모든 위젯은 인간의 감각과 근육에 대한 양보입니다. 50년 동안 그 양보는 완전히 옳았습니다 — 조작자가 언제나 인간이었기 때문입니다.
하지만 비용도 줄곧 장부에 적혀 있었습니다. 우리가 보지 않게 되었을 뿐입니다.
- 씬 파일은 기계를 위한 것이지 사람을 위한 것이 아닙니다. 바이너리이거나 반쯤만 읽히는
.unity/.prefab/.tscn파일은 읽을 수 없는 diff, 기도에 의존하는 머지, "에디터 열어서 직접 봐 주세요"라는 코드 리뷰를 낳습니다. - 뷰포트는 거짓말을 합니다. 에디터의 라이팅, 임포트 설정, 스케일링은 출시 빌드와 결코 정확히 일치하지 않습니다. "내 에디터에서는 멀쩡했는데"는 업계 전체의 오래된 농담입니다.
- 일관성은 구조가 아니라 규율에 의존합니다. 스타일 가이드는 위키에 잠들어 있고, 세 명의 아티스트는 세 가지 외곽선 두께를 그립니다. 에디터는 좌표를 제약할 수 있지만 미감은 제약할 수 없습니다.
조작자가 사람에서 에이전트로 바뀌면 이 장부는 뒤집힙니다. 에이전트에게는 배려해야 할 눈도 손도 없습니다 — 에이전트의 네이티브 I/O는 텍스트입니다. 에이전트에게 GUI를 주는 것은 물고기에게 자전거를 주는 것과 같고, 위의 세 가지 숨은 비용은 에이전트 워크플로의 급소에 정확히 명중합니다.
그래서 우리의 선택은 단순했습니다. 에이전트가 쓸 수 없는 인터페이스를 만들지 않는다. 에디터의 각 직무를 에이전트 네이티브한 형태로 대체한다.
에디터 대신 무엇을 장착했는가
에디터에는 다섯 가지 핵심 직무가 있습니다: 스타일 정의, 애셋 관리, 콘텐츠 배치, 파라미터 조정, 결과 미리보기. 각각이 무엇으로 대체되었는지 살펴봅니다.
1. 스타일 정의: 실행 가능한 스타일 바이블
전통적인 파이프라인에서 아트 디렉터의 스타일 가이드는 PDF입니다. 2주 뒤 누군가 외주 이메일에서 그것을 바꿔 말하면 팔레트가 표류하기 시작합니다. 우리는 스타일 바이블을 코드로 작성했습니다(tools/style_bible.py). 파일 머리말에 철학이 적혀 있습니다.
"스타일 바이블의 유일한 임무는 미래의 모든 애셋이 같은 손에서 나온 것처럼 보이게 하는 것이다. 그 실패 모드는 드리프트다… 잠긴 토큰을 데이터 + 작은 조립기로 인코딩하면 드리프트는 구조적으로 소멸한다 — 공유 DNA는 매번 문자 그대로 같은 문자열이고, 바뀌는 것은 애셋별 주제 슬롯뿐이다."
팔레트, 외곽선 규칙, 카메라 앵글, 구도 — 전부 잠긴 상수입니다. 각 애셋이 채우는 것은 단 하나의 슬롯, 그 주제뿐입니다("a cute shiny red apple with a small glossy green leaf"). 게임 전체의 테마를 바꾸고 싶다면? 팔레트 스위치 하나를 돌리고 전부 다시 생성하면 됩니다. 스타일 일관성은 아티스트의 규율이기를 멈추고 프로그램의 보증이 됩니다 — 어떤 에디터도 줄 수 없는 것입니다. 에디터가 제약하는 것은 좌표이지 미감이 아니기 때문입니다.
2. 애셋 관리: 선언적 매니페스트
여기서는 아트에 소스 코드가 있습니다. tools/floniks_manifest.json의 한 줄이 애셋 하나의 전부입니다.
{"name": "gem", "w": 16, "h": 16, "bg": "alpha",
"subject": "a cute glowing teal diamond gem, faceted, glossy"}
이름, 정확한 픽셀 크기, 배경 키잉 모드(투명 컷아웃 / 파란 단색 키잉 / 발광을 보존하는 검정 / 전체 프레임 텍스처), 주제 설명. 애셋은 "어느 생성 실행의 산출물"이 아니라 "언제든 매니페스트에서 재생할 수 있는 결과"입니다. 파일을 잃어버렸다면? 다시 실행. 전체 세트를 2배 해상도로 올리고 싶다면? w/h를 바꾸고 다시 실행. 이것이 게임 아트의 Infrastructure-as-Code입니다.
3. 애셋 생산: Floniks 파이프라인
매니페스트의 실행자는 MCP를 통해 Floniks 위에서 달리는 자동화 파이프라인입니다.
스타일 바이블이 프롬프트를 조립 → Floniks 텍스트-이미지 생성
→ 다운로드 → 배경 키잉 제거(모드별로 보정된 허용치)
→ 목표 픽셀로 정확히 리사이즈 → assets/textures/에 배치
→ 사람의 표본 검사를 위한 8배 니어리스트 확대 프리뷰도 출력
시퀀스 프레임은 시트 슬라이서를 거칩니다. 스프라이트 시트를 생성해 walk_0.png … walk_7.png로 자르면, Lua의 열 줄짜리 프레임 타이머가 애니메이션 시스템이 됩니다. 파이프라인에서 얻은 교훈은 코드 주석에 침전됩니다 — 어떤 모델이 실제로 어떤 배경 지시를 존중하는지, 어떤 API가 어떤 파라미터 형태를 원하는지. 흉터는 누군가의 기억이 아니라 파이프라인의 일부가 되었습니다.
그 아래에는 안전망이 있습니다. 표준 라이브러리만 쓰는 절차적 생성기가 의존성 없이 플레이스홀더 전체 세트를 만들어냅니다. 게임은 어느 순간에도 실행 가능합니다. AI 아트는 업그레이드일 뿐, 결코 의존성이 아닙니다.
4. 콘텐츠 배치와 파라미터 조정: 계약과 핫 리로드
씬 트리와 인스펙터는 두 가지로 대체되었습니다.
- 계약. 한 페이지(
ART_REQUESTS.md)가 선언합니다: 같은 파일명과 같은 픽셀 크기로 놓인 애셋은 코드 변경 없이 즉시 반영된다. 다른 한 페이지(PACK_SPEC.md)는 완전한 게임 팩을 정의합니다: 팩토리 함수, 자기 등록 테이블, 사용 가능한 텍스처 목록, 그리고 헤드리스 테스트가 구동할 수 있도록DEBUG테이블을 노출할 의무. 메뉴는 등록 테이블에서 자동 생성됩니다. 그 어디에도 GUI에서 클릭해야 하는 단계는 없습니다. - 핫 리로드. 모든 배치와 튜닝은 Lua 소스 안의 숫자일 뿐입니다 — 그리고 Lua, 텍스처, 심지어 WGSL 셰이더까지 엔진의 애셋 파이프라인을 통해 로드되므로 데스크톱에서는 저장 즉시 반영됩니다. 사과를 더 빨리 떨어뜨리고 싶다면? 숫자를 바꾸고, 저장하고, 지켜보세요. 인스펙터의 슬라이더는 "텍스트 + 초 단위 피드백"이 되었습니다 — 사람에게도 나쁘지 않고, 에이전트에게는 유일하게 쓸 수 있는 형태입니다.
5. 미리보기: 실행 중인 게임이 곧 뷰포트
우리에게 에디터 뷰포트는 없습니다. 미리보기 창이 실행 중인 게임 프로세스 그 자체이기 때문입니다 — WYSIWYG의 최종 형태. 임포트 설정 불일치도, 에디터와 빌드의 라이팅 차이도 없이, 당신이 보는 모든 프레임이 플레이어가 보게 될 프레임입니다. 런타임 비주얼 API가 표현력을 지탱합니다: 틴트 가능한 그레이스케일 스프라이트(텍스처 한 장으로 색상 패밀리 전체), 회전, 리사이즈, 프레임 교체, 그리고 게임플레이에 실제로 반응하는 풀스크린 WGSL 오로라 셰이더 — 각 게임의 화면 흔들림 피드백이 배경의 에너지까지 구동합니다 — 여기에 트라우마 감쇠 카메라 셰이크, 4단계 햅틱, 합성 사운드까지.
검수도 눈에 의존하지 않습니다. 677줄의 헤드리스 불변식 스위트가 모든 게임을 수만 프레임 구동하며 "게임 필 계약"을 검증합니다 — 뚫고 지나가지 않기, 순간이동 없기, 속도 상한, 히트 시 필수 피드백. 에디터는 인간에게 보여줍니다. 테스트는 에이전트에게 보여줍니다.
왜 이것이 에디터를 능가하는가
다섯 조각을 합치면 에디터가 원리적으로 제공할 수 없는 능력이 나옵니다.
- 아트를 통째로 재생성할 수 있습니다. 스타일 토큰 하나 변경 → 매니페스트 재생 → 한 시간 안에 완전히 일관된 새 아트 세트. 에디터 파이프라인에서는 이것을 "3주짜리 재작업"이라고 부릅니다.
- 아트를 코드 리뷰할 수 있습니다. 아트 변경 PR은 매니페스트 diff와 프리뷰 이미지입니다 — 롤백할 수 있고, blame할 수 있고, 외곽선이 너무 두꺼운지 댓글로 논쟁할 수 있습니다. 바이너리 씬 파일은 결코 줄 수 없는 것입니다.
- 일관성은 요구되는 것이 아니라 구축됩니다. 같은 프롬프트 DNA, 같은 허용치 테이블, 같은 픽셀화 공정. "신입 아티스트가 규칙을 몰랐다"는 존재하지 않습니다.
- 게임플레이와 아트가 하나의 루프를 공유합니다. 하나의 에이전트, 하나의 세션: Lua를 손보고, 새 애셋이 필요함을 깨닫고, Floniks를 호출하고, 계약에 따라 배치하고, 핫 리로드하고, 테스트를 돌리고, 커밋. 전통적인 파이프라인이라면 두 부서와 임포트 절차와 회의 하나가 필요합니다.
- 대화가 곧 에디터입니다. "사과를 더 빨갛게, 하이라이트를 더 반짝이게" — 이 문장이 완전한 편집 작업입니다. 에이전트가 매니페스트의 주제를 고치고, 파이프라인을 재생하고, 핫 리로드가 결과를 보여줍니다. 에디터는 의도를 마우스 궤적에 사상하고, 우리는 의도를 자연어에 사상합니다. 후자의 상한이 더 높은 것은 분명합니다.
그리고 정직한 비용도 적어둡니다. 이 플로는 조작자가 "한 사람 + 에이전트 하나"임을 전제합니다. 에이전트를 통해 일하지 않는 전통적인 아티스트나 레벨 디자이너에게는 오늘 여기 설 자리가 마땅치 않고, 수백 개의 오브젝트를 손으로 정밀 배치해야 하는 레벨 유형에도 아직 편한 도구가 없습니다(유력한 답 — 데이터로서의 레벨, 에이전트 생성, 불변식 테스트 — 은 로드맵에 있지, 저장소에는 아직 없습니다). 50년의 에디터 인체공학은 진짜입니다. 에디터가 틀렸다는 것이 아니라, 에디터가 최적화하는 대상 — 인간의 손 — 이 더 이상 우리 루프의 병목이 아니라는 것입니다.
오늘 출력할 수 있는 것
| 형식 | 파이프라인 | 상태 |
|---|---|---|
| 투명 배경 스프라이트 | Floniks 생성 → 키잉 → 정확한 픽셀로 리사이즈 | ✅ 프로덕션(저장소에 약 60장) |
| 틴트 가능 그레이스케일 텍스처 | 동일 + 런타임 틴팅 | ✅ 프로덕션 |
| 시퀀스 프레임 애니메이션 | 스프라이트 시트 → 슬라이서 → 프레임 교체 | ✅ 파이프라인 가동 |
| 풀스크린 배경 / 아레나 | 세로형 생성, 전체 프레임 모드 | ✅ 프로덕션 |
| UI 아트(버튼, 장식) | 같은 스프라이트 파이프라인 | ✅ 프로덕션 |
| 절차적 다이내믹 배경 | 손으로 쓴 WGSL, 게임플레이 반응형 | ✅ 프로덕션, 핫 리로드 |
| 효과음 / 루프 음악 | 오늘은 합성 WAV, 다음은 Floniks 텍스트-음악 | ✅ / 🔶 |
| 폰트 | TTF 그대로 번들에 | ✅ |
| 마케팅 애셋 | 스크린샷 수록됨, 이미지-비디오 트레일러 | 🔶 |
아직 미지원: 스켈레탈(Spine형) 애니메이션, 파티클, 타일맵. 각각 구체적인 계획이 있으며, 그 "에디터" 역시 데이터 + AIGC입니다 — 리그는 에이전트가 쓸 수 있는 JSON 파일이고 Floniks가 레이어별 파츠를 생성하며, 타일셋은 스타일 바이블에서 나옵니다. 주류 엔진과의 전체 비교표와 4단계 로드맵은 저장소 docs에 있습니다.
크로스플랫폼인가?
세 개의 층으로, 얼버무리지 않고 답합니다.
애셋 층: 100% 이식 가능, 락인 제로. 모든 것이 PNG, WAV, TTF, WGSL, Lua, JSON입니다 — 독점 씬 포맷도, 에디터 프로젝트 파일도, 임포트 데이터베이스도 없습니다. WGSL은 Metal / Vulkan / DX12 / WebGPU로 컴파일됩니다. 내일 이 스택을 버리기로 해도 모든 애셋은 그대로 들고 나갈 수 있습니다. 그 자유는 에디터가 없다는 것의 부산물입니다.
엔진 층(Bevy): 3대 데스크톱 OS, Android, iOS, Web(WASM/WebGPU) 모두 업스트림에서 지원됩니다. Lua와 엔진 사이의 커맨드 큐 브리지는 플랫폼 중립입니다.
이 프로젝트가 오늘 연결해 둔 것: 개발용 macOS(핫 리로드 포함)와 시뮬레이터 및 실기기의 iOS — Metal, 120 Hz ProMotion, 자동 서명, TestFlight 파이프라인. 하나의 Rust 크레이트가 양쪽을 빌드합니다. Android와 Web은 로드맵상의 패키징 작업이지 아키텍처 리스크가 아닙니다.
궁금할 만한 질문들
내 게임이 이 스택이 아니어도 이 애셋 파이프라인을 쓸 수 있나요?
네. 이 패턴 — 프롬프트 토큰을 잠그는 스타일 바이블, 각 애셋의 이름·크기·키잉 모드를 선언하는 매니페스트, Floniks로 생성해 정확한 픽셀로 후처리하는 스크립트 — 은 폴더에서 PNG를 읽는 어떤 엔진에서도 동작합니다. 저장소의 도구는 작은 Python 파일들이라 한나절이면 자신에게 맞게 고칠 수 있습니다.
애셋 생성에 크레딧이 드나요?
네. Floniks를 통한 생성 호출은 사용 모델에 따라 크레딧을 소모하며, 실패한 작업은 자동으로 환불됩니다. 에이전트는 배치 실행 전에 get_credit_balance를 호출해 예산이 충분한지 확인할 수 있습니다.
생성된 애셋이 스타일과 맞지 않으면 어떻게 하나요?
저렴하게 다시 뽑으면 됩니다. 모든 애셋이 매니페스트에 선언되어 있으므로, 한 장 — 혹은 전체 세트 — 의 재생성은 레시피의 재생이지 작업의 반복이 아닙니다. 스타일 바이블이 모든 시도를 같은 잠긴 팔레트와 구도 규칙 안에 붙들어 두므로, 재시도를 거듭해도 드리프트가 쌓이지 않습니다.
프롬프트를 직접 써야 하나요?
아니요. 스타일 바이블이 공유 스타일 DNA를 자동으로 조립하고, 각 애셋은 주제만 선언합니다. 에이전트 워크플로에서는 그 주제 한 줄조차 대개 당신의 한 문장 요청으로부터 에이전트가 작성합니다.
에디터는 죽지 않았다. 형태를 바꿨을 뿐이다.
| 에디터의 직무 | 우리의 형태 |
|---|---|
| 스타일 가이드 PDF | 실행 가능한 스타일 바이블(잠긴 프롬프트 DNA) |
| 애셋 브라우저 / 임포트 설정 | 선언적 매니페스트 + 재생 가능한 파이프라인 |
| 씬 트리 / 드래그 앤 드롭 | 계약 + 자기 등록 |
| 인스펙터 슬라이더 | 핫 리로드되는 Lua 소스 |
| 에디터 뷰포트 | 실행 중인 게임 + 헤드리스 테스트 |
| 마우스 조작 | 자연어 대화 |
50년 동안 게임 도구의 모든 진보는 같은 질문에 답해 왔습니다: 창작자의 의도는 어떻게 하면 더 빨리 픽셀이 되는가? 창작자 곁에 에이전트가 있는 지금, 최단 경로는 더 이상 GUI를 지나지 않습니다. 우리는 에디터를 미처 못 만든 것이 아니라, 그 노력을 "한 문장으로 말하기"가 최단 경로가 되도록 하는 데 쓴 것입니다.
이 베팅이 옳은지는 저장소의 게임 8개, 트리 안의 AI 생성 애셋 60장, 그리고 그 모두를 120 Hz로 돌리는 아이폰 한 대가 계속해서 대신 답해 줄 것입니다.
여기서 언급한 모든 것은 오픈소스 저장소에서 검증할 수 있습니다: maweis1981/rust_bevy_lua_game — tools/style_bible.py, tools/floniks_manifest.json, tools/floniks_build.py, tools/PACK_SPEC.md, 전체 에세이 시리즈는 docs/ 참고. Floniks를 당신의 에이전트에 연결하려면 MCP 개발자 가이드에서 시작하세요.

