로그 제작기 8 — 한계와 과제, 그리고 3D라는 욕심

로그 제작기 시리즈

1. 게임은 어떻게 만들어지는가, 그 궁금증에서 시작했다
2. 세계관부터 세웠다 — 동양 신화와 현대의 결합
3. 연옥으로의 초대 — 세계관 일러스트로 먼저 보는 로그의 세계
4. 용도별 AI 협업과 프롬프트 — 그림을 만들어 게임에 넣기까지
5. PoC에서 열두 개의 문까지 — 제작 과정 전체
6. 게임 시스템 설계 — 넋칼, 요괴, 십이지신, 스테이지
7. 아키텍처와 흐름 — 한 파일짜리 PoC를 관리 가능한 프로젝트로
8. 한계와 과제, 그리고 3D라는 욕심 ← 지금 글

다시 한 번: 이건 프로토타입이다

로그는 처음부터 끝까지 한 바퀴를 돌 수 있지만, 완성작이 아니다. 세계관을 포함한 모든 것은 앞으로 바뀔 수 있고 더 다듬어질 수 있다. 이 편은 지금 기준으로 부족한 것을 솔직하게 적고, 다음에 할 일을 정리한다.

현재 한계

게임 디자인

• 여덟 보스의 난이도는 사람이 충분히 검증하지 않았다. 쉽다는 피드백을 받고 체력과 공격 빈도를 올렸지만, 그 뒤로는 자동 테스트로만 확인했다.
• 제2문부터의 맵은 생성기가 만든다. 동선 규칙으로 “막힌 곳”은 없앴지만, 레벨 디자이너가 손으로 다듬은 맵처럼 “여기서 이 요괴를 이렇게 만나게 하자” 같은 의도는 없다.
• 스테이지와 보스의 결합이 약한 곳이 있다. 제철소와 불가사리·소처럼 잘 맞물린 곳도 있지만, 몇몇 스테이지는 보스와 요괴 구성의 이야기적 연결이 약하다.
• 보스 보상이 단조롭다. 넋창과 넋활 외에는 보스마다 넋 6개로 같다.
• 설정이 드러나지 않는다. 기억의 조각을 모아도 아직 아무 일도 일어나지 않는다. 두 사람의 과거가 조각마다 드러나게 하려던 계획은 비어 있다.

그림

• 코드 그림과 AI 그림이 섞여 있다. 캐릭터·요괴·보스는 AI 스프라이트지만, 배경은 대부분 코드로 그렸다. 설정화의 밀도와 비교하면 차이가 크다. 그림 배경을 넣을 수 있는 구조와 도구는 준비해뒀다.
• 도깨비불과 그림자 잡귀는 아직 코드로 그린 임시 그림이다.
• AI 그림의 일관성 문제. 시트마다 캐릭터 크기가 달라 프레임별 배율 보정을 넣었고, 같은 캐릭터도 요청마다 조금씩 달라진다. 설정화에서는 깃털 수, 귀 색, 문 모양이 설정과 어긋났다.
• AI가 한국 문화를 일본 문화와 혼동하고, 한글을 자주 틀린다. 홍살문이 도리이로, “해시”가 “혜시”로 그려졌다. 지금은 구조를 설명하는 프롬프트, 그림 밖에서 글자를 얹는 방식, 핵심 요소는 코드로 직접 그리는 방식으로 막고 있다. 근본적으로는 실제 사진 레퍼런스 첨부, 한국 문화 요소 검수 체크리스트, 세계관 스타일 가이드 문서화가 필요하다(4편).
• AI 생성 이미지의 권리 문제. 개인 블로그의 비상업 프로토타입이라 문제 삼지 않았지만, 규모를 키운다면 각 도구의 이용 약관과 저작권 정책을 다시 확인해야 한다.

기술

• 옮겨온 모듈 대부분에 @ts-nocheck가 붙어 있다. 타입을 붙이는 작업이 남았다.
• 충돌 판정은 사각형이다. 휘어진 채찍이나 둥근 여의주도 사각형으로 판정한다.
• 설정 메뉴가 없다. 키 바꾸기, 음량 조절, 난이도 선택이 없다.
• 모바일은 에뮬레이션으로만 검증했다. 가로 화면에서는 버튼을 게임 위에 겹치고 세로 화면에서는 아래에 두는 터치 조작, 여러 손가락 동시 입력, 전체 화면을 넣었지만, 실제 폰에서 손의 크기와 화면 크기에 따라 버튼이 불편할 수 있다.
• 소리는 단순하다. 합성음만 쓰고, 장면별 음악이나 보스별 테마가 없다.

과제 목록

우선순위	과제	이유
높음	직접 플레이하며 보스·스테이지 난이도 조정	자동 테스트는 재미를 판단하지 못한다
높음	모바일 실기기 테스트	블로그 방문자 상당수가 모바일이다
중간	스테이지별 그림 배경 적용	세계관의 밀도를 화면에 올리는 가장 큰 한 걸음
중간	세계관 스타일 가이드와 한국 문화 검수 체크리스트	AI가 반복해서 틀리는 요소(홍살문, 복식, 한글)를 모델과 무관하게 같은 기준으로 걸러내기 위해
중간	기억의 조각 → 과거 회상 컷신	모으는 행동에 이야기적 보상을 준다
중간	보스별 고유 보상 확장	보스마다 새 능력이 생기면 다음 스테이지 공략이 달라진다
중간	설정 메뉴(음량, 키, 난이도)	기본적인 접근성
낮음	모듈 타입 정리	규모가 커질수록 필요하다. data/부터 시작한다
낮음	도깨비불·그림자 잡귀 스프라이트	마지막 남은 임시 그림

그리고, 3D라는 욕심

만들다 보니 욕심이 생겼다. 떠 있는 섬에서 떨어지는 폭포, 검은 해 아래 기와 도시, 금빛 궁궐로 이어지는 빛의 계단. 설정화를 볼 때마다 이 세계를 3D로 걸어 다니고 싶다는 생각이 들었다. 이미 블로그 게임 탭의 다른 두 게임(종이배, 도심 질주)은 3D였기도 하다.

무엇이 그대로 옮겨가는가

2D 프로토타입에서 만든 것 중 상당수는 3D로 가도 버리지 않아도 된다.

• 세계관과 이야기 — 연옥, 열두 시진의 문, 오류, 달토끼 서사는 차원과 무관하다.
• 설정이 규칙이 되는 설계 — 어둑시니는 3D에서도 쳐다볼수록 커지고, 장산범은 여전히 흉내를 낸다. 오히려 3D에서는 “쳐다본다”는 행동이 시선 방향으로 자연스러워진다.
• 데이터 기반 보스 패턴 — 예고·실행·회복, 거리, 쿨타임으로 정의한 구조는 3D 액션 게임의 보스 설계와 같은 뼈대다.
• 스테이지 테마 체계 — 테마마다 풍경, 지형 규칙, 대기 효과를 한 묶음으로 가진다는 구조.

무엇이 달라지는가

• 에셋 파이프라인 — 스프라이트 시트 대신 3D 모델, 텍스처, 뼈대(리깅), 애니메이션이 필요하다. 이미지 생성 AI로 끝나던 작업이 3D 모델 생성 도구와 수작업 보정으로 바뀐다. 지금의 스프라이트 파이프라인처럼, 이 과정도 도구로 재현 가능하게 만드는 게 먼저다.
• 카메라와 조작 — 횡스크롤의 “오른쪽으로 가면 된다”가 사라진다. 길을 잃지 않게 하는 레벨 디자인과 카메라 설계가 새 과제가 된다.
• 엔진 — 2D에서는 직접 만든 엔진으로 충분했지만, 3D에서는 조명, 물리, 애니메이션 블렌딩을 직접 만드는 건 비효율적이다. 브라우저를 유지한다면 Three.js나 Babylon.js, 규모를 더 키운다면 Godot 같은 엔진을 검토하게 될 것 같다.

단계적으로 간다면

1. 2.5D로 먼저 — 지금 게임을 유지하되, 배경만 3D로 만들어 카메라가 살짝 움직이며 깊이감을 주는 방식. 게임 규칙은 그대로 두고 3D 에셋 파이프라인을 먼저 익힐 수 있다.
2. 한 스테이지 3D 수직 슬라이스 — 제1문 하나를 3D로 끝까지 만들어 조작감, 카메라, 에셋 제작 비용을 측정한다.
3. 확장 여부 결정 — 측정한 비용을 보고 열두 문 전체로 갈지 판단한다.

2D 프로토타입이 그랬듯, 3D도 작게 시작해 돌아가는 걸 먼저 보는 방식으로 갈 생각이다.

회고

처음 질문은 “게임은 어떻게 만들어지는가”였다. 직접 겪어보니 게임 개발은 생각보다 평소 하는 일과 닮아 있었다.

• 작게 시작하는 PoC
• 피드백으로 고치는 반복
• 그림을 게임에 넣는 과정을 자동화한 에셋 파이프라인
• 숫자로 만든 규칙이 감으로 한 배치보다 오래 간다는 것
• 추측하지 않고 측정해서 찾은 성능 병목
• 일에 맞는 도구를 고르는 것처럼, 용도에 맞는 AI 모델을 고르는 것
• 타입 검사를 통과해야 배포되는 CI/CD

다른 점이 있다면, 이 모든 게 결국 “재밌는가” 라는, 자동화할 수 없는 질문 하나를 위해 존재한다는 것이다. 그리고 그 질문에 답하려면 결국 사람이 직접 해봐야 한다.

게임 탭에서 로그를 플레이해보고, 막히는 곳이나 답답한 곳이 있다면 알려주면 좋겠다. 그게 이 프로토타입이 다음 단계로 가는 가장 중요한 재료다.

🎮 바로 플레이: 게임 탭에서 로그 열기 · 소스: noah2byte/log-game