화면 없이 게임이 도는 걸 증명하기 — 숫자가 대신 눈이 된 밤

GUI도 없고, 마우스로 클릭할 창도 없는 환경에서 게임을 만들었다. 게임이 제대로 돌아간다는 걸 어떻게 증명할까. 눈으로 못 본다면 — 숫자로 세면 된다. 이 글은 그 단순한 발견의 하룻밤 기록이다.

게임 하나를 새로 시작했다. 이모지로 만든 군중이 레인을 달리고, 게이트를 통과하면 숫자가 곱해지거나 더해지는 종류다. 모바일에서 흔히 보는 크라우드 러너 장르. 엔진은 Godot 4를 골랐다. 한 번도 써본 적 없는 엔진이었다.

동기는 수익보다 실험이었다. “AI와 함께 게임을 만든다”는 걸 실제로 해 보고 싶었다. 강대종이 디렉터이자 플레이테스터 역할을 맡고, 에이전트가 코드를 짜는 구조다. 지시하고, 결과를 받아 플레이해 보고, 다음 단계를 결정한다.

문제는 개발 환경에 있었다.

화면이 없는 곳에서 게임을 만들면

이번 작업은 노트북 노드에 위임했다. 리눅스 위의 WSL 환경이다. 그래픽 창을 열 수가 없다. Godot를 실행해도 화면이 뜨지 않는다. 마우스로 캐릭터가 움직이는 걸 눈으로 확인할 방법이 처음부터 없었다.

게임 개발을 보통 어떻게 검증하는지 생각해 보면, 거의 전부 “눈으로 본다”에 의존한다. 레벨을 만들고 실행해서 캐릭터가 움직이면 된다, 아니면 이상하다. 그런데 화면이 없으면 그 확인 방법 자체가 사라진다.

첫 단계에서 Godot를 설치하고 프로젝트 골격을 만들었다. 이건 비교적 쉬웠다. 에러 없이 통과됐고, 설치 자체는 화면이 없어도 검증할 수 있다. 하지만 두 번째 단계가 관건이었다. 군중이 실제로 움직이는지, 게이트를 통과할 때 숫자가 제대로 바뀌는지 — 이걸 화면 없이 어떻게 알 수 있을까.

숫자가 대신 눈이 된다

해법은 의외로 단순했다. 게임 로직이 실제로 작동하는지를 “화면에 보여주는 것”이 아니라 “숫자를 로그로 찍는 것” 으로 대체한 것이다.

군중이 10명으로 시작한다. 첫 번째 게이트는 ×2다. 통과하면 20명이 돼야 한다. 두 번째 게이트는 +5다. 20명이 통과하면 25명이 돼야 한다. 이 예상 값과 실제 계산 결과가 일치하는지를, 게임 엔진 안에 자체 검증 루틴으로 심어 뒀다. 헤드리스 모드로 실행하면 — 화면은 열리지 않지만 — 이 루틴이 돌면서 로그를 뱉는다.

[selftest] start crowd=10
[gate] 10 x2 -> 20
[gate] 20 +5 -> 25
[selftest] end crowd=25 (expect 25)

네 줄이다. 이 네 줄이 “게임 핵심 로직이 작동한다”는 증명이다. 화면을 보지 않아도, 군중이 ×2 게이트를 통과할 때 실제로 두 배가 되고 +5 게이트를 통과할 때 실제로 다섯이 더해진다는 것을, 숫자가 증명한다.

”보인다”와 “작동한다”는 다른 문제다

이 장면을 보면서 생각이 하나 이어졌다. 게임을 직접 실행해서 눈으로 캐릭터가 움직이는 걸 보는 것과, 게임 로직이 실제로 기댓값대로 연산하는 것은 사실 다른 문제라는 것.

화면에 뭔가 움직이는 게 보인다고 해서 로직이 맞는 건 아니다. 군중이 게이트를 통과하는 애니메이션이 그럴듯해 보여도, 숫자 계산 자체가 틀렸다면 그건 작동하는 게 아니다. 반대로 화면이 없어도 로직이 기댓값대로 움직인다면, 그건 충분히 작동하는 것이다.

UI는 나중에 붙이면 된다. 로직이 먼저 맞아야 한다. 그 순서를 뒤집으면, 눈에 보기 좋은 것을 완성했다는 착각 속에 로직이 어긋난 채로 앞으로 가게 된다. 화면이 없다는 제약이 오히려 이 순서를 강제해 줬다.

검증을 코드 안에 심어 두는 것

재밌는 건, 이 검증 루틴이 별도의 테스트 파일이 아니라 게임 코드 안에 함께 들어갔다는 점이다. 게임을 헤드리스로 실행하면 자동으로 자기 자신을 검증하고 결과를 로그로 남긴다. 배포 전에 누군가가 “테스트를 돌려야 한다”고 기억할 필요가 없다. 코드가 그 자체로 자기 동작을 증명하는 구조를 가지고 있다.

소프트웨어 개발에서는 이런 방식을 “테스트 코드”라고 부른다. 새로운 개념은 아니다. 그런데 게임 분야에서는 이 습관이 상대적으로 드문 편이다. 눈으로 확인하는 것에 익숙해져 있기 때문이다. 이번에는 화면이 없다는 조건이 이 오래된 습관을 처음부터 못 쓰게 만들었고, 덕분에 더 단단한 검증 구조를 처음부터 심게 됐다.

다음 단계가 남아 있는 것

로직이 증명됐다고 다 끝난 건 아니다. 이건 첫 번째 증명이다. 군중이 화면에 실제로 그려지고, 손가락으로 레인을 바꾸고, 실기기에서 플레이해 볼 수 있으려면 GUI 빌드 경로를 뚫어야 한다. 그건 다음 단계의 일이다.

지금까지 나온 건 이 단계의 것만 증명했다. 이것만으로는 게임이라 할 수 없다. 그런데 이것을 건너뛰고 화면을 만들면, 화면은 그럴듯하되 로직이 엉킨 게임이 된다. 순서를 지키는 게 결국 더 빠르다.

강대종이 직접 플레이테스트를 해볼 수 있게 되는 건 P3 이후다. 지금은 숫자로 읽는 중이다.

눈으로 못 봐도 작동을 입증하는 법

정리하면 이렇다. 화면을 볼 수 없을 때, 작동을 입증하는 방법은 두 가지다. 포기하거나, 숫자로 증명하거나.

이건 게임 개발에만 해당하는 이야기가 아니다. 배포된 서버가 제대로 동작하는지, 자동화 스크립트가 의도대로 흘러가는지, 야간에 돌아간 일괄 처리가 실제로 처리됐는지 — 전부 같은 문제다. 눈으로 직접 확인할 수 없는 상황에서, 믿을 수 있는 숫자를 남기는 것. 그 숫자가 곧 눈이 된다.

군중 10이 게이트를 통과해 25가 됐다는 로그 네 줄이, 그날 밤 가장 작은 완성이었다.

이 글은 Godot 4 기반 이모지 군중 러너 게임을 헤드리스 환경에서 착수한 하룻밤의 기록입니다. GUI가 없는 환경에서 로직을 먼저 검증하는 방식이 갖는 의미를 일반 독자용으로 풀어썼습니다.

— 강대종