자신의 게임 제작에서 이미지 생성 AI에게 화면 안을 부탁하면, 얼핏 보기에는 상당히 괜찮은 결과물이 나오기 시작했습니다.

배경이 있고, 정보 패널이 나열되어 있으며, 버튼이나 아이콘도 배치되어 있다. 기획의 이미지를 공유하기 위한 한 장의 그림으로서는 매우 편리합니다.

하지만, 막상 게임에 구현하려고 하면 곤란해집니다.

원했던 것은 완성된 화면의 한 장의 그림이 아니라, 구현 시 재사용할 수 있는 배경, 패널, 버튼, 아이콘이었습니다.

이 문제를 어떻게든 하기 위해 만들고 있는 것이, OSS인 「Game Screen Foundry」입니다.

아름다운 한 장의 그림과, 구현 가능한 화면은 다르다

한 장의 이미지로 생성된 게임 화면에는 구현 시 필요한 경계가 없습니다.

• 버튼과 배경이 붙어 있다
• 패널 내부에 글자나 수치가 박혀(baked) 있다
• 같은 외형으로 통상·선택·무효 상태를 다시 만들 수 없다
• 잘라내면 투명도, 여백, 그림자, 윤곽이 무너진다
• 어느 좌표에, 어떤 겹침 순서(z-order)로 놓을지가 남아 있지 않다

이미지 편집 소프트웨어로 분리하면 해결될 것처럼 보이지만, 나중에 사이즈나 문구, 레이아웃이 바뀌면 결국 다시 한 장의 그림으로 돌아가 작업하게 됩니다.

필요했던 것은 「화면을 생성하는 도구」라기보다, **화면을 부품으로서 설계하고, 생성 결과를 조립하며, 문제가 있는 부품만 다시 만들 수 있는 제작 플로우(workflow)**였습니다.

생성하기 전에, 화면을 3개의 JSON으로 정의한다

Game Screen Foundry에서는 1개 화면의 정본을 주로 3개의 파일로 나누고 있습니다.

예를 들어, 소지 코인 수는 이미지에 박지 않고, 실행 시 게임 측이 그리는 runtime text로 둡니다. 반면, 패널의 장식 프레임은 PNG 측에 맡깁니다.

이 소유권을 먼저 결정함으로써, 「외형은 완성되어 있는데 숫자를 바꿀 수 없다」와 같은 사고를 줄일 수 있습니다. 자세한 파일 계약은 Data Schema에 두고 있습니다.

「생성하고 끝」이 아니라, 가조립과 재생성을 루프한다

제작 플로우는 다음과 같습니다.

screen KV + material spec
-> 구조를 와이어프레임(wireframe)으로 확인
-> 소재별 PNG를 생성
...

이미지를 만들기 전에는 각 소재를 색상이 있는 사각형으로 나열한 구조 프리뷰를 띄울 수 있습니다. 여기서 배치, 여백, 겹침, 텍스트 영역을 확인합니다.

생성 후에는 PNG를 원래의 좌표로 되돌려 화면 전체를 조립합니다. 단독으로는 아름다운 버튼이라도, 실제 화면에 배치하면 글자 영역을 압박하거나 옆의 아이콘과 맞지 않을 수 있습니다. 그래서 개별 소재와 완성 화면 양쪽을 모두 보도록 하고 있습니다.

수정할 때도 화면 전체를 다시 만드는 것이 아니라, 대상 소재를 재생성 큐(queue)에 넣습니다. 이미 채택한 소재나 고정한 소재는 유지하며, 「이 버튼의 여백만 늘린다」와 같은 변경 사항을 구조화하여 전달합니다.

이미지 생성 그 자체는 Foundry의 책무로 하지 않았다

Game Screen Foundry 자체는 이미지 생성 서비스가 아닙니다.

Foundry가 담당하는 것은 소재별 생성 조건, 유지할 요소, 투명도나 최종 사이즈, 채택 조건 등을 정리한 handoff입니다. 실제 래스터(raster) 생성은 ImageGen을 이용할 수 있는 Codex 등의 환경으로 넘깁니다.

출력된 PNG는 투명도나 최종 사이즈의 acceptance gate를 통과시킨 후 채택합니다. 나아가 여백, 늘어남, 레이아웃 적합성을 validator로 감사합니다.

생성 모델과 화면 사양을 분리해 둠으로써, 이미지 생성 측의 호출 방식이 바뀌더라도 게임 측의 화면 계약을 유지하기 쉬워집니다.

AI 에이전트에게도, 동일한 제작 규칙을 전달한다

이 제작 플로우는 앱 상에서 수작업할 뿐만 아니라, Codex나 Claude Code에서도 다룰 수 있도록 agent용 Skill을 동봉하고 있습니다.

작업 방법은 크게 3가지입니다.

• guided: 앱에서 위치나 사이즈를 세밀하게 조정한다
• autonomous: AI가 검증, 생성 handoff, 완성 화면 리뷰, 대상 한정 재생성을 진행한다
• hybrid: AI가 검증된 초안을 만들고, 인간이 앱에서 마무리한다

표준으로 생각하고 있는 것은 hybrid입니다.

입니다. 전부를 자동화하는 것이 아니라, AI가 구조화와 초안 작성을 진행하고, 인간이 완성된 화면을 보고 판단하는 방식입니다.

자율 모드(Autonomous mode)에도 반복 상한을 두고 있습니다. 화면이 좋아질 때까지 무제한으로 생성을 계속하는 것이 아니라, 각 반복의 완성 이미지와 리뷰를 남기고 완료·확인 필요·상한 도달 중 하나로 멈춥니다.

아직 public beta이며, 만능 디자인 도구는 아닙니다

현재의 Game Screen Foundry는 public beta입니다. 제작 루프의 검증에는 사용할 수 있지만, schema나 UI는 앞으로도 계속 변한다는 전제하에 운영됩니다.

또한, 다음과 같은 용도를 목표로 하는 것은 아닙니다.

• 범용적인 이미지 생성 UI
• 스토어용 스크린샷이나 광고 배너 제작
• 완성된 화면의 한 장의 그림을 자동으로 완전 분해하는 도구
• 디자이너의 판단을 불필요하게 만드는 완전 자동 시스템

처음부터 올바른 소재 경계(asset boundary)를 정의하고, 생성과 구현 사이에 있는 왕복 과정을 관리하기 위한 워크벤치(workbench)입니다.

시도해보기

Node.js 20 이상이 있다면, 로컬 브라우저 버전을 실행할 수 있습니다.

git clone https://github.com/surugawan-ebi/tool-game-screen-foundry.git
cd tool-game-screen-foundry
npm run dev

실행 후, http://127.0.0.1:4311을 열고, 데모를 불러오기를 누릅니다. 샘플 프로젝트의 JSON, 분리된 PNG 소재, 조립 프리뷰, 리뷰, 재생성 큐(queue)를 확인할 수 있습니다.

코드는 MIT License로 공개되어 있습니다.

한 장의 그림을 부정하고 싶은 것은 아닙니다

한 장의 그림으로 된 게임 화면은 기획이나 방향성을 공유하는 KV(Key Visual)로서 매우 유용합니다. 문제는 그것을 그대로 구현 자산으로 취급하려 할 때입니다.

KV는 완성 이미지로 사용하고, 구현에 필요한 요소는 별도의 소재와 runtime 정보로 나눕니다. 그 사이를 사양, 가조립, 검사, 재생성의 루프로 연결합니다.

Game Screen Foundry는 이 경계를 만들고자 합니다.

향후 과제도 보입니다. 현재 실제 이미지 작성은 Codex에서 ImageGen으로 전달하는 경로를 중심으로 정비하고 있지만, 화면 사양과 handoff(핸드오프) 계약을 특정 생성 환경에만 국한시키고 싶지는 않습니다. 다른 AI 에이전트나 이미지 생성 도구에서도 동일한 소재 사양을 받아들여, 생성 결과를 Foundry로 되돌릴 수 있도록 만들고 싶습니다.

또 하나는 생성된 이미지의 감사(audit)입니다. 현재도 투명도, 최종 사이즈, 늘어남(stretching), 레이아웃 적합성 등을 검사하고 있지만, 화면 전체로 보았을 때의 위화감, 의도한 질감과의 차이, 가독성 저하, 부자연스러운 묘사까지 충분히 판정할 수 있는 것은 아닙니다. 체크 메커니즘에는 아직 미흡한 점이 있다고 인식하고 있습니다.

기계적으로 판정할 수 있는 항목을 늘려가면서, 완성 화면의 육안 리뷰와 대상 한정 재생성을 조합합니다. 생성기를 가리지 않고, 나온 이미지를 제대로 감사할 수 있는 제작 기반으로 키워나가는 것이 앞으로의 목표입니다.

아직 beta 단계이므로, 실제 게임 화면에서 사용하면 "이 소재 경계로는 부족하다", "이 검사로는 놓치는 부분이 있다"와 같은 문제가 발생할 것입니다. 테스트 결과나 개선안을 Issue로 알려주시면 감사하겠습니다.

• GitHub: surugawan-ebi/tool-game-screen-foundry
• Schema: docs/schema.md
• Agent Skill: skills/game-screen-foundry

Discussion