Field Constraint
아트 후보와 런타임 자산 사이의 간극
raw 이미지는 예뻐도 엔진 입장에서는 불명확하다. 어디가 투명인지, 몇 프레임인지, 어느 좌표를 샘플해야 하는지 모른다.
01 · Problem Framing
AI가 이미지를 만들었다고 게임 자산이 된 것은 아니다
게임 개발에서 진짜 병목은 "그림 한 장"이 아니었다. 같은 스타일로 반복 생성해야 하고, 배경을 지워야 하고, 프레임을 잘라야 하고, 엔진이 읽을 좌표와 충돌 정보를 남겨야 했다. 더 중요한 것은 실제 화면에 그려졌다는 증거였다.
Automation Target
사람이 반복하던 후처리를 계약으로 전환
magenta key, grid slice, atlas JSON, collision metadata를 명시해 재현 가능한 작업 단위로 만들었다.
FDE Lens
도메인 병목을 제품화 가능한 시스템으로 번역
게임 에셋 문제를 단순 디자인 요청이 아니라 자동화 파이프라인과 검증 게이트로 재정의했다.
02 · Pipeline
raw image에서 runtime proof까지 이어지는 단일 흐름
핵심은 생성 모델을 믿는 것이 아니라, 생성 뒤의 모든 단계를 측정 가능하게 만드는 것이다. 그래서 이 파이프라인은 "그럴듯한 이미지"보다 "검증 가능한 자산 계약"을 먼저 본다.
Pipeline draft. Public page에서는 이 다이어그램을 더 압축하고 실제 atlas 이미지와 나란히 배치하면 좋다.
03 · Evidence
이미지는 장식이 아니라 증거로 배치한다
이 페이지의 시각자료는 모두 "무엇을 증명하는가"가 있어야 한다. AgentForge는 pipeline output, ClaudeCraft는 runtime reachability, libGDX는 review gate와 source governance를 보여준다.
tileset
player
enemy
props
| Case | Proof | Status |
|---|---|---|
| AgentForge | 5 atlases, 27 frames, QC JSON, loader seed | BUILD PASS |
| ClaudeCraft | 11 visible tile/item sprites rendered | PLAYWRIGHT PASS |
| Bone Trail | review-only asset gates and voxel prepass | NOT ACCEPTED |
| OSS package | repo, tests, license, sample scope pending | DRAFT |
04 · FDE Capability
FDE 역량은 "코드를 잘 짰다"보다 "현장 문제를 시스템으로 바꿨다"에서 나온다
이 케이스는 게임 아트 자동화처럼 보이지만, 실제로는 고객/현장형 문제 해결에 가깝다. 불명확한 요구를 운영 가능한 계약으로 바꾸고, 이해관계자가 볼 수 있는 증거물을 남겼다.
01
Discovery: 병목을 다시 정의
"에셋이 없다"를 "raw 생성, 후처리, manifest, runtime reachability가 연결되지 않았다"로 쪼갰다.
02
Solution Design: 생성 모델을 프로덕션 계약 뒤에 둠
image_gen은 raw 초안 담당. 품질과 반복성은 chroma-key, slicing, manifest, QC, proof가 담당하게 했다.
03
Delivery: 기존 렌더러와 하네스에 끼워 넣음
ClaudeCraft에서는 새 감사 시스템을 만들지 않고 기존 sprite loader와 proof convention을 따라 glyph path를 대체했다.
04
Enablement: 다음 사람이 재사용할 수 있게 문서화
OSS repo 구조, sample scope, claim guard, skill 후보까지 정리해 개인 작업을 재사용 가능한 자산으로 바꿨다.
포트폴리오 핵심 문장
저는 AI가 산출물을 "만들게" 하는 데서 멈추지 않고, 그 산출물이 실제 제품 경로에 들어가기 위한 계약과 검증을 설계합니다. 이 프로젝트에서는 게임 에셋 병목을 Codex 기반 자동화 파이프라인으로 바꾸고, runtime proof까지 남겼습니다.
05 · Technical Contract
핵심 구현은 manifest와 gate다
공개용 기술 블로그에서는 이 부분을 깊게 풀면 좋다. 포인트는 "프롬프트 잘 쓰기"가 아니라 모델이 흔들려도 파이프라인이 흔들리지 않게 만드는 계약이다.
asset-contract.json
draft
{
"id": "tile/crypt_floor",
"source": {
"rawOrigin": "built-in image_gen",
"background": "#FF00FF"
},
"frame": { "x": 0, "y": 0, "w": 128, "h": 128 },
"layer": "base",
"collision": { "solid": false },
"proof": {
"loaded": true,
"spriteRendered": true,
"fallbackReason": null
}
}
Why this matters
엔진은 이미지를 추측하지 않는다
manifest가 frame rectangle, anchor, layer, collision, proof state를 들고 있어야 한다. 그래야 renderer는 같은 규칙으로 샘플링하고, QA는 같은 규칙으로 실패를 잡는다.
이 구조는 게임 밖에서도 쓸 수 있다. 광고 소재, 아이콘 세트, UI variant처럼 "AI가 많이 만들고 사람이 승인해야 하는" 작업에 그대로 전이된다.
06 · Blog Draft Structure
기술 블로그로 풀 때는 감정 질문에서 시작한다
글은 처음부터 JSON 스키마로 들어가지 않는다. "왜 AI가 만든 이미지는 게임에 바로 못 들어갈까?"라는 익숙한 질문에서 시작하고, 그다음 기전과 자동화 설계로 들어간다.
초안 제목 후보
AI는 그림을 만들고, 파이프라인은 게임 자산을 만든다
- 도입: 생성 이미지를 받았는데 바로 못 쓰는 순간. 투명 배경, 프레임, 충돌, 검증이 없다.
- 문제 정의: 게임 에셋은 PNG가 아니라 엔진 계약이다. 좌표와 상태와 proof가 필요하다.
- 파이프라인: image_gen raw -> magenta key -> grid slice -> atlas -> manifest -> runtime proof.
- FDE 관점: 현장 요구를 자동화 단위로 쪼개고, 팀이 반복 사용할 수 있는 도구 계약으로 바꾼다.
- 결론: AI 자동화의 실력은 생성 품질보다 실패를 통제하는 구조에서 드러난다.
07 · Boundaries
좋은 포폴일수록 아직 아닌 것을 정확히 말한다
이 케이스는 과장하면 오히려 약해진다. 기술 게이트 PASS와 시각/재미 acceptance는 다르다. 공개 페이지에는 이 경계를 계속 보이게 둬야 한다.
- ClaimCodex 기반 raw-to-atlas 자동화 파이프라인을 구축했다.
- ClaimClaudeCraft에서는 visible map에서 11개 tile/item sprite draw path를 증명했다.
- Careful"game-ready"는 runtime proof가 있는 asset에만 쓴다.
- Do not claim최종 아트 품질, 사용자 수용, 완전 자동화, 상용 출시, 재미 검증.