AI 게임 공장: Godot에서 웹으로 옮겨도 남았던 문제
표시 날짜는 이 글이 다루는 작업의 대표 기록일이며, 당시 발행된 글을 뜻하지 않습니다. 이후 회고와 적용 방법은 2026년 9월에 정리했습니다.
이미지 생성 도구를 바꾸면 화면도 좋아질 거라 기대하는 사람에게, 생성과 실제 적용이 왜 별개의 확인 단계인지 렌더 실측 사례로 보여준다.
PixelLab으로 그림 생성 방식을 바꿔도 8월 16일 렌더 실측 검사를 넣기 전까지는 그 그림이 실제 화면에 그려지는지 알 수 없었다 — 파일이 있다는 것과 소스가 참조한다는 것, 화면에 그려진다는 것은 서로 다른 확인이었다.
이미지 생성 도구를 바꾸기 전에, 대표 자산 한 개가 목표 화면에 실제 표시되는 경로부터 먼저 연결하고 그다음 늘린다.
연재 목차
- AI 게임 공장: 게임 하나가 아니라 만드는 과정을 만들고 싶었다
- AI 게임 공장: 많이 만들기에서 네 작품에 집중하기로
- AI 게임 공장: 완료 보고 옆에 실제 확인한 것을 적기 시작했다
- AI 게임 공장: Godot에서 웹으로 옮겨도 남았던 문제
- AI 게임 공장: 화면을 다듬고도 게임을 멈춘 이유
- AI 게임 공장: 완성 대신 부분완성이라고 적고 닫았다
- AI 게임 공장: 방치형으로 장르를 좁혀봤다
- AI 게임 공장: Swift로 옮기며 이전 공장에서 남길 것을 골랐다
- AI 게임 공장: 게임을 고치다가 검사기도 다시 고쳤다
- AI 게임 공장: 심사 제출까지 온 뒤 돌아본 AI 게임 공장
먼저 답하면
이 글에 실은 FOUR SIGHT 캡처는 파일명에 촬영 시각이 남아있지 않다. 정확한 시점보다 8월 11일 제작·QA 기록과 이어진다는 사실만 확인했다.
8월 10일 문서에는 Godot 중심 제작을 정리하고 웹 스택으로 옮기는 결정이 남아 있다. 전환 커밋은 다음 날이었다. 당시 Kein-games 작업에서 도구를 바꾼 것이지 따로 보존한 실험까지 전부 없앤 것은 아니다.
로비와 팝업은 React·CSS로 만들고 실시간 전투는 Phaser로 다루는 방향이었다. 작은 게임을 반복해서 만들면서 자주 손보는 화면을 익숙한 방식으로 다뤄보려 했다. 어느 엔진이 무조건 낫다는 결론은 아니었다.

8월 11일 제작·QA 기록에 연결되는 보존 화면. 정확한 촬영 시각은 확인하지 못했다.
그림을 받아도 화면은 그대로일 수 있었다
초기 웹 작업에는 숫자 그리드로 픽셀 그림을 만드는 방식이 있었다. 이후에는 마스코트 표현을 개선하려고 PixelLab 생성으로 방향을 바꿨다.
문제는 생성한 그림이 플레이 화면에 실제로 들어갔느냐였다. 더 나은 파일을 받아도 렌더러가 예전 것을 쓰면 게임은 달라지지 않는다. 8월 16일에는 에셋 미적용 문제와 실제 렌더링 확인을 보강한 변경이 남았다.
파일이 있는지 확인하는 것과 소스에서 그 이름을 찾는 것, 화면에 그려졌는지를 보는 것이 따로 필요했다. 엔진과 이미지 도구를 바꾸는 일 사이에 이 연결 작업이 남아 있었다.
다음에는 그림을 한 묶음 다 만든 뒤 넣기보다 대표 자산 하나부터 화면에 연결하려 한다. 실제 크기와 방향, 배치가 맞는지 먼저 본 뒤 늘리는 편이 낫겠다. 생성 품질을 올리는 것만으로 해결되지 않았던 구간이다.
기술 전환은 대표 장면 하나로 검증하기
엔진을 바꿀 때는 전체 게임을 옮기기 전에 상태가 바뀌는 대표 장면 하나를 연결한다. 메뉴에서 선택한 값이 전투에 들어가고 결과가 다시 메뉴에 반영되는 경로면 화면과 게임 로직 사이의 경계를 확인할 수 있다.
이미지도 대표 자산 하나를 새 경로에서 읽게 한 뒤 실제 표시 크기로 확인한다. 원본 파일, 코드 참조, 렌더링 결과를 함께 두면 미적용을 찾기 쉽다. 앱이 캐시된 구버전 자산을 읽는지까지 확인해야 새 파일을 받았다는 사실과 사용했다는 사실을 구분할 수 있다.
이 방식은 기술 전환 비용을 초기에 드러내는 데 도움이 된다. 렌더러를 바꾸었다고 규칙의 재미가 바뀌지는 않으므로 플레이 평가는 별도로 남긴다. 도구 비교 결론은 확인한 플랫폼과 장면 범위 안에서만 적는다.
← 이전 글: 완료 보고 옆에 실제 확인한 것을 적기 시작했다 · 전체 목차 · 다음 글: 화면을 다듬고도 게임을 멈춘 이유 →