Claude Code와 ComfyUI로 만든 비주얼노벨 버티컬 슬라이스 회고

들어가는 글

나는 예전에 함께 일했던 동료 한 분과 자주 연락하고 지낸다.

안타깝게도 최근 프로젝트가 접히면서 부득이하게 구직을 시작하셨다고 한다. 몇 달 동안 연락 오는 곳이 없어서, 이참에 1인 개발이나 해 볼까 싶으셨단다. 근황을 여쭤보니 그 1인 개발 게임을 포트폴리오에 넣고부터 면접 기회가 잘 잡혔다고 했다. 그 말이 필자에겐 꽤 인상적이었다.

내러티브 디자이너에게 포트폴리오란 무엇일까. 기존처럼 시나리오를 쓰고, 캐릭터를 설계하고, 게임 안에서 이야기가 어떻게 전달되어야 하는지 안다는 것을 어필하는 것으로 끝일까. 만약 내가 ‘작가’라는 포지셔닝을 유지한다면 이걸로 충분할지도 모른다. 그러나 ‘스토리 연출’이나 ‘서브컬처 감각’처럼 문서로 보여 주기 어려운 영역은 어쩔 수 없이 얕게 전달되곤 했다.

기획서로 어떤 경험을 의도했는지는 설명할 수 있다. 하지만 실제 게임 화면에서 대사가 어떻게 출력되고, 캐릭터가 어떤 표정을 짓고, 플레이어가 무엇을 선택하는지까지 보여 주기는 어렵다.

그래서 생각했다. 내가 직접 게임을 만들면 어떨까.

프로그래머나 아티스트의 도움 없이 내가 설계한 이야기를 플레이할 수 있는 형태로 보여 줄 수 있다면, 역량을 증명하는 데 도움이 될 것 같았다. 마침 Claude Code를 비롯한 AI 개발 도구가 빠르게 발전하고 있었다. 코드를 직접 짜지 않아도 기획과 요구사항만 명확하게 전달하면 게임을 구현할 수 있지 않을까 하는 기대가 생겼다. 그래서 일주일 동안 AI로 비주얼노벨의 버티컬 슬라이스를 만들어 보기로 했다.

중간 결과부터 말하자면, 시스템은 됐지만 게임은 잘 안 됐다.

AI는 생각보다 훨씬 많은 일을 해냈다. 비주얼노벨 시스템을 구현했고, 미니게임을 만들었고, 심지어 Unity를 직접 조작해 플레이테스트까지 했다. 그런데 정작 내러티브 디자이너인 나는 내러티브를 거의 만들지 못했다.

어쩌다 이렇게 됐을까.

최초 발상: 내 어린 시절의 시골 경험을 배경 비주얼노벨을 만들어보자

처음부터 돈을 벌 수 있는 게임을 만든다는 목표를 세운 건 아니었다.

내가 게임을 만들 수 있다는 걸 증명하고, 그걸 포트폴리오로 활용할 수 있다면 좋겠다는 생각에서 시작했다. 그렇게 첫 발을 떼야 비로소 그 이후에 상업화나 부수입 같은 다음 단계를 기대할 수 있다고 생각했다.

그래서 거창한 서브컬처 프로젝트나 명확한 타깃 고객을 노리기보다는 그저 인디 감성으로, ‘나만의 게임’ 같은 생각으로 프로젝트를 접근하고자 했다.

첫 발상은 내 어린 시절의 기억에서 시작됐다. 1990~2000년대의 한국. 오래된 골목과 건물, 지금과는 다른 풍경, 그 시절의 생활감이 남아 있는 장소들. 고작 십 수년의 세월만에 빠르게 변해가는 인물과 배경을 그려내고 싶었다.

개인적인 경험을 소재로 삼은 이유는 또 있다. ‘내 이야기’에서 출발하다보니 어디선가 막히는 일 없이 계속 아이디어를 발상하기 수월할 것 같았다. 그리고, 현대 일본풍이나 어떤 판타지 세계관을 배경으로 한 서브컬처 게임과는 조금 다른 감성을 만들 수 있을 것 같았다.

그렇게 구상한 게임의 첫 가제는 「폐광 마을의 일주일」이었다. 그래도 나름 미소녀가 등장하는 게임을 생각했는데 게임 이름이 ‘폐광’으로 시작하니 칙칙해서, 지금은 「그날, 우리가 기억하는 봄으로」로 이름을 바꿨다.

재수를 준비하던 스무 살 청년이 오랜만에 강원도 할머니 댁을 찾는다. 그곳에서 돌아가신 할아버지가 남긴 낡은 카메라를 발견하고, 마을의 풍경과 사람들을 사진으로 남기기 시작한다. 오래전 알고 지냈던 소꿉친구를 다시 만나고, 마을에서 일주일을 보내며 이야기가 펼쳐지는 연애 어드벤처다.

게임의 핵심 소재는 ‘사진’이다. 플레이어는 카메라로 마을을 바라보고, 히로인과 시간을 보내고, 평범하게 지나쳤을지도 모르는 순간들을 사진으로 남긴다.

비주얼노벨을 고른 데에도 현실적인 이유가 있었다. 우선 내 내러티브 역량을 가장 직접적으로 보여 줄 수 있는 장르였다. 복잡한 전투나 이동 시스템 없이도 스토리와 캐릭터, 연출만으로 플레이 경험을 만들 수 있다. 또 다른 장르보다 시스템 개발 부담이 적고, 필요한 리소스도 상대적으로 적을 거라고 생각했다.

그런데 이 판단은 나중에 예상보다 훨씬 크게 나를 괴롭혔다.

개발: 기획서를 Claude Code가 실행할 작업 단위로 쪼개다

1페이지 기획서부터 다이얼로그 기능구현서까지

개발 환경은 Unity로 정했다. 구현은 전적으로 Claude Code에 맡기고, 다이얼로그 시스템에는 무료 오픈소스인 Ink를 썼다.

현업에서 익숙하게 써 온 Naninovel을 그대로 쓰는 방법도 있었다. 다만 이번에는 유료 에셋을 사서 쓰는 대신, 필요한 기능을 직접 구현하고 넓혀 갈 수 있는 구조를 만들어 보고 싶었다. 대부분의 게임 회사는 다이얼로그 시스템을 자체 구현해서 쓰기 때문에, 나도 ‘구현’까지 보여 줄 수 있는 결과물을 만들고 싶었다. 그렇다고 바닥부터 시작하면 공수가 너무 크니, 무료로 쓸 수 있는 Ink를 기반으로 Naninovel에 준하는 비주얼노벨 경험을 구현하는 것을 첫 목표로 삼았다.

개발 방식은 평소 게임 기획 업무와 크게 다르지 않았다. 먼저 1페이지 기획서를 썼다. 게임 컨셉과 경험 목표를 정하고, 그걸 바탕으로 마일스톤을 잡았다. 빠르게 기획서를 10페이지 규모로 늘리면서 필요한 기능을 마일스톤 목표에 더했다. 구현 과정동안 목표치와 빗나간 결과가 나오면 마일스톤마다 기능구현서를 다시 갱신해서 Claude Code에 개발 변경사실을 공유했다.

AI와의 역할 분담은 MDA 프레임워크에 빗대어 나눴다. 나는 A, 즉 유저가 느낄 경험(Aesthetics)을 정한다. 사진을 찍는 경험, 데이트하는 것 같은 경험, 미연시를 플레이할 때 같은 UI/UX.

AI는 그걸 M, 즉 메커닉(Mechanics)으로 바꿔 알아듣는다. 촬영 시스템, 캐릭터 호출과 퇴장, 이동 같은 정의와 세이브·로드 처리 같은 기능이 그렇게 마일스톤에 더해졌다. 코딩이나 기술 명세를 잘 몰라도, 원하는 것을 분명하게 전달하면 AI는 생각보다 훨씬 잘 ‘구현’해 왔다.

생각보다 순조로웠던 시스템 구현

이 과정은 생각보다 순조로웠다. 대사창, 선택지, 백로그, 저장과 불러오기처럼 비주얼노벨에 필요한 기본 기능이 빠르게 붙었다.

구현 과정 자체도 꽤 단순했다. 내가 요구사항을 정리해 넘기면, Claude Code가 코드를 짜고 Unity 프로젝트에 반영했다. 수정과 확인은 물론 필요했다. 그래도 기본적인 비주얼노벨 시스템을 세우는 데 예상만큼 큰 어려움은 없었다. 예전이라면 프로그래머 없이는 엄두를 내기 어려웠을 작업이다.

가장 놀라웠던 건 촬영 시스템이었다. 사실 내가 정한 A는 꽤 허술했다. 1페이지 기획서에 적은 건 사진을 찍으며 히로인과 가까워진다는 방향, 그리고 “새로 만들 기술은 셔터 타이밍(손떨림 게이지)과 이미지 필터만으로 제한한다”는 구현 원칙 한 줄 정도였다. 그런데 Claude Code가 쓴 기능구현서는 이 한 줄을 실제로 만들 수 있는 M으로 바꿔 놓았다.

• 첫 마일스톤(M1)은 대사 → 구도 선택 → 셔터 → 현상 → 앨범 저장 → 세이브 → 재시작 → 로드까지 이어지는 3~5분짜리 검증 장면 하나로 잡는다.
• 완료 기준은 “로드 직후 앨범에 같은 사진(같은 구도·같은 품질 필터)이 보이고, Ink 변수도 복원된다”로 적는다.
• 손떨림 게이지의 속도나 선명 구간 같은 값은 [가정]으로 표시하고 나중에 바꾸기 쉽게 상수로 빼 둔다.

나는 ‘무엇을 만들지’를 대강 던졌을 뿐인데, 기능구현서에는 ‘어디서 멈추면 되는지’까지 정리돼 있었다. 정하지 못한 값에는 [가정]이나 [미정]이 붙었고, AI는 그 항목을 임의로 확정하지 않고 나에게 보고했다. 그렇게 하도록 규칙을 둔 건 나였지만, A의 빈칸을 이렇게 메커닉으로 채워 올 줄은 몰랐다.

적어도 시스템 구현만 놓고 보면, AI를 활용한 게임 개발은 충분히 실용적인 수준에 와 있다는 인상을 받았다.

그런데 시스템이 돌아가는 것과 재미있는 게임이 나오는 것은 전혀 다른 이야기였다. 허술하게 남겨 둔 A가 발목을 잡은 곳이 바로 이 촬영 미니게임이었다.

게임 디자인: 사진을 잘 찍는 남자친구가 되는 게임

의도한 경험과 구현된 규칙

이 게임에는 사진 촬영 미니게임이 들어간다. 그냥 카메라를 들고 셔터를 누르는 게 아니라, 게임을 반복하면서 사진 잘 찍는 법을 자연스럽게 익히는 경험을 만들고 싶었다.

사진에 익숙하지 않은 사람은 구도나 초점, 흔들림을 다루기 어려워한다. 그런데 게임 속에서 계속 찍다 보면 이런 요소를 조금씩 이해하게 되고, 나중에는 히로인이 원하는 사진을 능숙하게 찍어 줄 수 있게 된다. 쉽게 말해, 하면 할수록 여자친구가 원하는 사진을 잘 찍어 주는 남자친구가 되는 게임을 만들고 싶었다.

막힌 건 이 목표를 실제 게임 시스템으로 옮기는 단계였다. 내가 원하는 경험이 무엇인지는 설명할 수 있었다. 문제는 그것을 어떤 규칙과 조작, 피드백으로 구현해야 하는지였다.

처음에는 할아버지의 카메라를 필름 카메라로 설정했다. 그런데 필름 카메라라면 찍은 사진을 현상해야 결과를 볼 수 있다. 내가 처음 생각한 건 찍고 나서 바로 결과를 보고 다시 찍으며 감을 잡는 경험이었는데, 현상이라는 단계가 그 사이를 끊어 버린다. 그래서 카메라를 디지털카메라로 바꿨다.

결국 나온 미니게임은 「원신」의 요리 제작과 비슷한 타이밍 게임이었다. 뷰파인더 화면에서 구도 후보를 좌우로 넘겨 보다가, 손떨림 게이지가 가라앉는 순간에 셔터를 누른다. 타이밍을 맞추면 선명한 사진이, 놓치면 초점이 나가거나 흔들린 사진이 나온다.

기능은 정상적으로 작동했다. 하지만 직접 플레이해 보니 아쉬움이 컸다.

처음에는 타이밍을 맞추는 재미가 있다. 그런데 몇 번 반복하면 패턴이 몸에 익고, 그다음부터는 지나치게 쉬워져서 플레이가 단조로워진다. 무엇보다 사진을 잘 찍는 법을 배우고 있다는 느낌이 부족했다.

플레이어가 숙달한 것은 사진이 아니라 타이밍이었다

왜 그렇게 됐는지는 기획 문서를 다시 읽어 보니 보였다.

10페이지 기획서의 촬영 시스템 표에서 구도 선택은 “관계와 서사를 담당”하고 셔터 타이밍은 “짧은 촉각적 재미”를 담당한다. 정답이 없는 구도 선택은 히로인을 어떻게 바라보는지에 대한 선택이고 셔터는 손맛이다. 그런데 ‘사진을 잘 찍는 법’을 맡은 규칙은 이 표 어디에도 없었다. 초점과 호흡, 손떨림을 잡는 요령은 튜토리얼에서 히로인이 대사로 가르치는 내용이었다. 기술은 대사 속에 있고 손으로 하는 규칙에는 없었던 것이다.

규칙 쪽도 숙달할 거리를 일부러 비워 둔 상태였다. 뷰파인더에는 셔터 속도, 조리개, ISO 같은 촬영 정보가 뜨지만 기능구현서에는 “표시 수치 1/125 F5.6 ISO 200 고정, 노출 눈금 바늘은 가운데 고정(판정 요소로 보이지 않게)”이라고 적혀 있다. 카메라처럼 보이게 하는 장치였지 플레이어가 판단할 변수가 아니었다. 결국 플레이어가 결정할 수 있는 건 ‘어떤 구도로’와 ‘언제 누를지’ 두 가지였고 그중 실력이 늘 수 있는 쪽은 타이밍뿐이었다.

피드백 구조도 학습과는 반대 방향이었다. 10페이지 기획서에는 촬영 결과를 “그 자리에서는 자세히 보지 않고 밤에 함께 확인한다”고 적혀 있고 기능구현서도 찍은 자리에서는 판정을 보여 주지 않도록 만들었다. 밤에 둘이 작은 화면을 들여다보는 장면은 관계 연출로는 중요했다. 하지만 플레이어 입장에서는 무엇을 잘했고 무엇을 놓쳤는지를 찍은 순간에 알 수 없다. 즉각적인 피드백을 위해 필름 카메라를 디지털카메라로 바꿔 놓고, 관계 연출을 위해 판정은 다시 밤으로 미룬 셈이다.

이야기를 위한 설계와 숙달을 위한 설계가 한 미니게임 안에서 서로 다른 방향을 보고 있었다. 관계를 위해 판정을 늦췄고 첫 게임이라 규칙을 타이밍 하나로 묶었다. 각각은 이유 있는 결정이었지만 그 합이 “사진을 잘 찍는 남자친구가 되는 경험”은 아니었다. 내가 정한 A와 AI가 만든 M은 서로 맞았다. 하지만 그 사이에서 플레이어가 실제로 반복하는 D(Dynamics)는 ‘타이밍 맞추기’가 되어 버렸다. 허술하게 남겨 둔 A의 빈칸을 M이 채워 줄 수는 없었던 셈이다.

물론 이걸 전부 AI의 한계라고 말할 수는 없다. 이 범위를 정한 건 나였다. 촬영이라는 행위를 어떻게 재미있는 게임 규칙으로 만들지 충분히 정의하지 못했고 전문적으로 다뤄 본 적 없는 분야에서는 원하는 결과를 설명하는 것부터가 어려웠다. 이후 레퍼런스 게임을 참고하면서 구현 완성도를 일부 끌어올렸지만, 처음 의도한 플레이 경험까지는 가지 못했다. 결국 이 부분은 기초 기능만 만들어 두고 다른 일부터 처리한 뒤에 다시 보기로 했다.

AI 플레이테스트: Claude Code와 Unity MCP로 테스트를 맡기다

개발하면서 예상하지 못한 문제가 하나 더 있었다. 검증이다.

Claude Code가 기능을 빠르게 구현하는 건 좋았다. 그런데 기능이 하나 완성될 때마다 내가 Unity를 직접 실행해 플레이테스트를 해야 했다. 대화창이 제대로 출력되는지, 선택지가 작동하는지, 저장한 데이터를 제대로 불러오는지, 미니게임이 의도대로 진행되는지 확인해야 했다.

구현이 빨라질수록 검증해야 할 결과물도 쌓였다. AI가 개발을 대신해 주는데, 정작 나는 그 결과를 확인하느라 계속 시간을 써야만 했다. 어느 순간 문득 이런 생각이 들었다. ‘AI가 대신 테스트해줄 수는 없나?’.

예전에 게임 안에서 자동으로 시뮬레이션을 돌리다가 오류가 나면 로그에 찍어 주는 기능을 본 적이 있다. 하지만 나는 그런 기능을 따로 ‘구현’하기보다, 말 그대로 Claude Code가 마우스를 쥐든 뭘 하든 Unity를 알아서 돌려 봐 주기를 바랐다. 그렇게 시켜 봤더니 놀랍게도 정말 게임을 ‘플레이’하고 있었다. 마우스 포인터를 움직하며 플레이한 건 아니었다. Unity MCP로 에디터를 직접 움직이며 장면을 하나씩 진행시키는 방식이었다.

그 뒤로는 플레이테스트도 AI에게 맡겼다. 코드나 로그를 확인하라는 게 아니라, Claude Code가 구현한 마일스톤 목표가 기획 의도대로 반영됐는지 직접 플레이하면서 검증하라는 뜻이었다. 그리고 AI가 스스로 확인할 수 없는 부분이나 중요한 판단이 필요한 부분만 따로 보고하게 했다.

실제 보고는 이런 식이었다. 먼저 실행 직후 컴파일 오류가 없는지 확인했다. 그다음 “이번엔 건너뛰지 않고 처음부터 실제 순서대로 진행하면서 장면마다 찍을게요”라며 장면별 화면을 캡처해 가며 테스트를 진행했다. 끝나고 올라온 보고는 바꾼 연출과 파일, 규격 변경, 커밋 번호에 더해 두 가지 목록으로 나뉘어 있었다.

‘플레이에서 확인할 것’에는 줌 속도가 답답하지 않은지, 소라가 튀어 오르는 크기가 과하지 않은지, 화면 가장자리를 어둡게 한 정도가 적당한지가 적혀 있었다. 이유도 함께 적혀 있었다. 정지 화면으로만 봐서 움직임의 느낌은 판단하지 못했다는 것이다. ‘남은 문제’에는 진행을 스크립트로 시켰기 때문에 실제 클릭과 키 입력, 소리는 확인하지 못했다는 내용과, 대본에는 디지털카메라인데 다락 그림의 카메라는 필름 카메라처럼 생겼다는 지적이 들어 있었다. 시험하느라 장면을 건너뛰어 생긴 화면은 실제 흐름에는 없다고 스스로 정정했고, 테스트하며 바뀐 세이브와 읽음 기록은 테스트 전 상태로 되돌려 두었다.

내가 할 일은 직접 플레이해 보고 “버스정류장 줌이 느려”, “튀어 오르는 게 과해” 정도로 느낌을 전하는 것이었다. 값은 AI가 다시 조정했다.

이렇게 하니 내가 직접 확인해야 하는 작업이 상당히 줄었다. 개발을 요청하고, 결과물을 확인하고, 문제를 고치는 과정 일부를 AI가 알아서 처리하게 된 것이다.

그런데 여기서 새로운 고민이 생겼다. 도대체 어디까지 AI에게 맡겨야 할까?

처음에는 AI가 구현하고 내가 검증하는 게 당연하다고 생각했다. 그런데 AI가 테스트까지 할 수 있다는 걸 알고 나니, 다른 일도 더 맡길 수 있지 않을까 싶었다. 나는 창작에만 집중하고, 테스트하며 버그를 고치는 잡일은 Claude Code에 맡기고 싶었다. 나중에는 속으로 이런 생각까지 들었다.

‘나는 게으른 개발자다. 네가 다 해라.’

진심이라기보다는 ‘얘가 진짜 어디까지 혼자 할 수 있는 거지?’를 시험해 보던 중에 떠오른 생각이었다. 그 과정에서 내가 직접 해야 한다고 믿었던 일 상당수가 사실은 AI에게 넘길 수 있는 일이었다는 걸 깨달았다.

다만 AI가 정상 작동한다고 보고한 기능이 실제로 재미있는지는 여전히 별개였다. 첫 검증 장면(M1)을 마친 기록이 그 차이를 잘 보여 준다. 기획서의 검증 항목에는 두 가지가 나란히 적혀 있다. 세이브/로드 후 촬영 결과가 복원되는 것은 확인했고 ‘구도를 먼저 고르는 흐름이 헷갈린다’는 촬영 조작감 문제는 다음 마일스톤으로 넘겼다. 앞의 것은 기능이 맞게 도는지의 문제라 테스트로 판정할 수 있다. 뒤의 것은 손에 쥐었을 때 어떤 느낌인지의 문제라 사람이 해 봐야 나온다. 이후 구도를 먼저 고르던 방식은 뷰파인더 한 화면에서 구도를 넘겨 보다 셔터를 누르는 방식으로 바뀌었다.

촬영 미니게임 전체도 마찬가지였다. 기능은 제대로 돌아갔지만, 내가 의도한 재미와 깊이에는 닿지 못했다. 테스트는 “선명 판정이 나온다”까지는 확인해 주지만 “이 판정을 반복하면 사진이 늘었다고 느끼는가”는 확인해 주지 않는다.

결국 검증을 AI에게 맡기는 것만큼이나, 무엇을 AI가 검증하고 무엇을 사람이 판단할지 나누는 일이 중요했다. LLM 교차검증 워크플로우를 정리할 때도 결론은 비슷했다. 판단은 결국 사람의 몫이었다.

아트 제작: ComfyUI로 가장 많은 시간을 쓴 이미지

시스템 구현보다 훨씬 어려웠던 건 리소스 제작이었다.

비주얼노벨은 다른 장르보다 시스템이 단순한 편이다. 그래서 처음에는 제작 난이도도 상대적으로 낮을 거라고 생각했다. 하지만 막상 개발해 보니 사정이 달랐다. 비주얼노벨에서 플레이어가 보는 화면의 상당 부분은 캐릭터와 배경 이미지다. 시스템이 단순한 만큼, 화면에 걸리는 리소스의 완성도가 게임의 인상을 크게 좌우했다.

이미지 제작에는 ComfyUI를 썼고, 주로 Anima 체크포인트를 활용했다.

캐릭터: 매력적이지만 결이 다른 히로인

테스트 단계에서 생성한 캐릭터 이미지는 어느 정도 만족스러웠다. 생각보다 AI 티가 심하지 않았기 때문이다. 문제는 방향이었다. 내가 만들어야 하는 건 현실 배경에 서 있어도 어색하지 않은, 일상적인 여친룩의 히로인이었다. 의상을 조정한 결과물은 그 조건에는 맞았다. ‘현실적인가’라는 기준으로 보면 틀린 그림은 아니었다. 하지만 지나치게 현실 쪽으로 기운 나머지, 애니메이션풍의 밋밋한 소녀에 그쳤다. 서브컬처 히로인에게 기대하는 매력, 이른바 모에한 느낌이 없었다. (캐릭터 스탠딩을 만든 과정은 ComfyUI로 비주얼노벨 스탠딩 한 벌 만들기에서 따로 다뤘다.)

배경: 로드뷰와 img2img 사이에서

그보다 더 난감했던 건 배경 생성이었다.

나는 흔히 보는 일본풍 배경이 아니라, 어린 시절 기억 속에 남아 있는 한국의 풍경을 그리고 싶었다. 그래서 실제 장소의 로드뷰 이미지를 참고 자료로 썼다. 하지만 원하는 결과는 좀처럼 나오지 않았다. 돌아보면 실패의 원인은 한두 가지가 아니었다.

첫째는 img2img의 공간 재현 문제였다. 로드뷰 캡처를 넣고 원본을 얼마나 바꿀지(denoise)를 0.45, 0.60, 0.75로 바꿔 가며 시험했다. 어느 값에서도 로드뷰의 구도와 형태를 지나치게 그대로 따라갔고 0.45에서는 사진에 필터를 씌운 것에 가까웠다. 반대로 텍스트 프롬프트만으로 생성하면 실제 장소의 공간감이 사라졌다.

내가 원한 건 실제 장소를 그대로 베낀 이미지가 아니었다. 기억 속 한국의 거리가 서브컬처 게임의 배경으로 자연스럽게 재해석된 그림이었다. 그런데 현실적인 공간감과 원하는 그림체를 동시에 잡기가 어려웠다.

둘째는 모델의 출력 경향이었다. 내가 쓴 Anima Turbo 설정은 CFG 1이었는데 이 설정에서는 네거티브 프롬프트가 사실상 듣지 않는다. 그래서 ‘글자 없는 간판’을 요구하고 글자를 네거티브에 넣어도 한글을 흉내 낸 깨진 글자가 남았다. 배경 분석 문서에 정리해 둔 ‘뜬금없이 나오는 것’ 목록도 길었다. 일본식 기와와 목조 상가, 석유 시추탑 같은 철골 격자탑, 유럽풍 지붕창, 끝없이 뾰족한 침엽수. 모델이 기본으로 끌고 가는 방향을 막으려면, 빼라고 적는 대신 대신할 재질과 형태를 하나하나 적어야 했다.

셋째는 한국 배경의 디테일 문제였다. 폐광 마을다운 풍경은 시멘트 미장 벽, 알루미늄 새시, 실외기, 방범창, 원색 간판 같은 작은 요소가 모여서 만들어진다. 이런 요소는 프롬프트에 하나씩 적을 수 있었지만 화풍도 원하는 방향과 달랐고 사물의 형태나 배치에서는 특유의 AI 생성 이미지 같은 느낌이 강하게 묻어났다. 기획서에 적어 둔 ‘슬레이트 지붕’처럼 정작 참고 사진으로는 확인되지 않은 설정도 있었다.

그리고 내 쪽의 한계도 분명히 있었다. 미술 분야의 전문 지식이 부족하다 보니 결과물이 왜 어색한지, 무엇을 어떻게 고쳐야 하는지 구체적으로 피드백하기가 어려웠다. 내가 어떤 결과물을 원하는지 아는 것과, AI가 그 결과물에 닿도록 요구사항을 전달하는 것 사이에는 거리가 있었다. 미연시 비주얼노벨의 CG를 레퍼런스로 주고 화풍을 분석해 프롬프트에 반영하는 시도도 해 봤지만 결과는 크게 달라지지 않았다. 레퍼런스를 더 주고 프롬프트를 고치는 것만으로는 해결되지 않았다.

아예 모델을 Anima Turbo에서 Anima Aesthetic이나 Illustrious XL 계열로 바꿔 보기도 했다. 하지만 결과물은 여전히 쓸 수 없는 수준이었다. 결국 배경 작업은 여기서 보류하고 다른 작업으로 넘어가야 했다.

리소스 자동 생성의 로망과 좌절

리소스 생성 과정에서 가장 중요하게 생각한 건 ‘자동화’였다.

리소스 생성 과정에서 가장 중요하게 생각한 건 ‘자동화’였다. 어느 정도 퀄리티만 나온다면 수십에서 수백 장을 알아서 생성하게 두고, 나는 그동안 내러티브나 구현에 집중할 생각이었다.

하루는 배경 화풍 테스트와 생성 작업을 자동화해 밤에 걸어 두고 잤다. 장소 13곳에 화풍 4종(일상풍, 수채화, 선명한 색감, 필름풍)을 곱하고 조합마다 8장씩. 모두 416장을 생성했다. 파일 기록을 보면 생성은 11월 5일 0시 13분에 시작해 1시 29분에 끝났다. 한 시간 남짓이면 416장이 나오는 셈이다.

아침에 확인하니 이미지는 상당히 쌓여 있었다. 그런데 하나하나 보면 어색한 점이 한두 가지가 아니었다. 끝없이 이어지는 계단과 그 사이에 어색하게 놓인 건물. 현실에 없을 것 같은 지붕과 골목. 휘어진 손잡이와 엉뚱한 자리에 난 풀. 사람이 그렸다면 나올 수 없는 ‘불쾌한 그림’이었다. 결국 밤에 걸어 둔 자동 생성 결과물은 전량 폐기했다.

AI에게 시간을 더 준다고 결과가 좋아지지는 않았다. 같은 날 오후에 돌린 다른 배치 기록에는 작업마다 ‘success’가 찍혀 있고, 마지막 줄은 “bad= 0″이다. 스크립트가 아는 실패는 이미지가 아예 만들어지지 않는 경우뿐이었다. 게임에 쓸 수 있는지는 사람이 한 장씩 봐야 알 수 있었다.

어설픈 자동화로 늘어난 건 못 쓸 결과물의 개수와 내 고민뿐이었다. 오히려 고민은 여기서부터 시작됐다.

저런 결과물을 받았을 때, 어떻게 피드백해야 내가 원하는 결과물에 가까워질 수 있을까?

회고: 병행 개발과 개발 순서

세 가지 일을 동시에 하면 세 배 빨라질까?

Claude Code가 시스템을 구현하는 동안 나는 ComfyUI로 리소스를 만들고, 그 사이에 내러티브 기획을 진행한다. 나의 이런 계획을 바탕으로 작업을 동시에 돌리면 개발 기간을 크게 줄일 수 있을 것 같았다.

실제로 작업은 병행할 수 있었다. 각각의 활용을 데스크탑과 노트북 각각의 LLM에 과제를 할당했고, 어느 한쪽이 일하는 동안 다른쪽에 기획 명세를 전달하며 개발하는 건 가능했다. 문제는 각 작업의 결과를 판단하고 다음 방향을 정하는 사람이 나 하나였다는 점이다.

AI가 기능을 구현하면 확인해야 했고, 이미지가 나오면 품질을 평가해야 했다. 원하는 결과가 아니면 요구사항을 다시 고쳐야 했다. 앞에서 말한 배경 작업이 바로 그 반복이었고, 그러는 동안 내러티브 기획은 계속 뒤로 밀렸다.

일주일 동안 쓴 시간을 대략 돌아보면 이 정도다.

• 시스템 구현과 검증: 약 30%
• 이미지 등 리소스 제작: 약 60%
• 내러티브 기획: 약 10%

정확히 잰 수치는 아니고 체감상 비중이다. 내러티브 역량을 보여 주려고 시작한 프로젝트에서, 정작 내러티브에 쓴 시간은 전체의 10% 정도였던 셈이다. 결국 AI가 여러 작업을 동시에 수행할 수 있다는 것과, 사람이 그 결과를 동시에 판단할 수 있다는 것은 다른 문제였다.

AI가 일을 대신하면서 구현의 병목은 줄었다. 대신 결과물을 평가하고 다음 작업을 정하는 과정이 새로운 병목이 되었다.

다시 시작한다면 무엇부터 할까?

이번 프로젝트를 다시 시작한다면 가장 먼저 바꾸고 싶은 건 개발 순서다.

처음에는 기획서를 쓰고, 시스템을 구현하고, 리소스를 만드는 순서로 접근했다. 시스템 구현이 빠르게 진행되니 개발이 순조롭다고 생각했다. 하지만 가장 불확실했던 건 시스템이 아니라 리소스 제작이었다. 원하는 화풍의 캐릭터를 안정적으로 뽑을 수 있는지, 한국의 실제 풍경을 게임 배경으로 자연스럽게 표현할 수 있는지, 캐릭터와 배경이 한 화면에서 어울리는지. 이걸 제대로 확인하지 않은 채 개발을 시작했다.

다시 한다면 본격적인 개발에 앞서 리소스 제작 파이프라인부터 연구하고 검증할 것이다. 캐릭터 한 명과 배경 한 장을 원하는 품질로 만들 수 있는지, 같은 방식으로 다른 장면도 만들 수 있는지부터 확인하는 것이다.

그렇다고 모든 리소스를 완성한 다음에야 개발을 시작해야 한다는 의미는 아니다. 중요한 건 본격적인 제작에 들어가기 전에 가장 불확실한 부분부터 검증하는 것이다.

앞에서 던진 ‘어떻게 피드백해야 할까’라는 질문에도 아직 답을 찾지 못했다. 다만 그 질문은 개발 중간이 아니라 개발을 시작하기 전에 던졌어야 했다.

촬영 미니게임도 마찬가지다. 타이밍 게임을 구현하는 건 어렵지 않았다. 하지만 플레이어가 사진 잘 찍는 법을 배우는 경험을 어떻게 만들어야 하는지는 충분히 검증하지 못했다. 다음에는 기능구현서를 쓰기 전에, 핵심 플레이 경험부터 작은 프로토타입으로 확인해 보고 싶다. AI가 얼마나 빨리 구현하느냐보다, 무엇을 구현해야 하는지를 먼저 확인하는 것이다.

마치며: 방향을 규칙으로 옮기는 일

일주일이 기대대로 흘러가지는 않았지만, 아무것도 얻지 못한 건 아니다.

오히려 이번 경험이 앞으로 내가 어떤 다른 각도로 게임 개발에 접근해야 할지 좀 더 명확한 선택지를 남겨주었다. 비유하자면 ‘지뢰찾기에서 이미 지뢰 위치를 몇 개 알고 있어서 거기를 피해 어디부터 시작해야 할지 알 것 같다’고나 할까.

Claude Code로 비주얼노벨의 기본 시스템을 구현했고, AI가 Unity를 직접 조작하며 플레이테스트까지 하는 개발 방식도 겪어 봤다. 기획서를 체계적으로 쓰면 AI에게 상당한 수준의 개발 업무를 맡길 수 있다는 것도 확인했다.

반면 원하는 플레이 경험을 게임 규칙으로 구체화하는 일, 아트 리소스의 방향을 정하고 품질을 평가하는 일에서는 예상보다 많은 시행착오를 겪었다. AI는 코드를 짜 주었지만, 어떤 게임을 만들어야 하는지까지 대신 정해 주지는 않았다.

결과적으로 이번 프로젝트는 다른 포트폴리오 작업을 준비하다보니 잠시 보류하게 되었다. 아직 완성된 게임도 아니고, 처음 목표한 내러티브와 연출 역량을 충분히 보여 줄 결과물도 아니어서 아쉽게도 포트폴리오로 첨부하진 못했다. 이렇게 이 프로젝트가 끝날 수도 있다. 하지만 적어도 다음에 무엇부터 확인해야 하는지는 알게 됐다.

내가 원하는 캐릭터 한 명과 배경 한 장이 같은 화면에서 자연스럽게 어울리는가. 그리고 그 화면 안에서 플레이어가 내가 의도한 경험을 할 수 있는가.

돌이켜 보면, 만들고 싶은 게임과 목표 경험의 방향은 처음부터 비교적 분명했다. 기억 속 한국의 골목, 사진을 찍으며 가까워지는 두 사람, 하면 할수록 사진이 느는 손. 어려웠던 건 그 방향을 실제로 돌아가는 시스템과, 같은 품질로 다시 만들 수 있는 아트 제작 파이프라인으로 옮기는 일이었다. 시스템 쪽은 내가 허술하게 남긴 A를 AI가 M으로 빠르게 채워 줬지만, 플레이어가 겪는 D까지 의도대로 만들어 주지는 못했다. 아트 쪽은 옮길 방법부터 아직 찾지 못했다.

방향은 분명했다. 부족했던 건 그 방향을 규칙과 파이프라인으로 옮기는 방법이었다.