AI

AI 코딩 에이전트에게 브라우저 게임 5개를 맡겨봤다 — 전체 파이프라인 공개

2026년 7월 한 주 동안, 나는 브라우저 게임 5개를 내 사이트에 배포했다. 마인크래프트류 복셀 서바이벌 게임, 마리오카트류 3D 레이싱 게임, 캔디크러시류 매치3 퍼즐, 실제 세계지도 위에서 1,200개가 넘는 프로빈스를 절차적으로 생성해 플레이하는 대전략 게임, 그리고 한국 요괴를 소재로 한 슈퍼마리오류 플랫포머. 다섯 개 모두 브라우저에서만 동작하고, 백엔드도 빌드 과정도 없으며, 도메인 비용 말고는 예산이 전혀 들지 않았다. 그리고 다섯 개 모두 AI 코딩 에이전트와 짝을 이뤄 만들었다 — 나는 기획자이자 테스터, 그리고 화면을 실제로 들여다보는 유일한 사람 역할을 맡았다.

나는 이 사이트를 AI·테크 주제로 운영하지만, 이번엔 평소 다루던 CRUD 앱이나 콘텐츠 파이프라인과는 완전히 다른 종류의 소프트웨어에서 AI 에이전트가 얼마나 갈 수 있는지 보고 싶었다. 물리·절차적 생성·적 AI가 들어가는 실시간 게임은 “컴파일이 된다”와 “재미있다” 사이의 거리가 전혀 다르다. 다섯 개를 실제로 배포하면서 배운 것은, 진짜 파이프라인이 어떻게 생겼는지 — 그리고 이 전체를 가능하게 만든 결정 하나였다.

게임 5개, 폴더 구조는 하나

각 게임은 사이트의 public/games/<슬러그>/ 아래 정적 파일 몇 개로 존재한다 — index.html.js 파일 한두 개, 3D 게임의 경우 Three.js 같은 작은 벤더 라이브러리가 하나 더 있는 정도다. 번들러도, 빌드 단계도, 패치를 신경 써야 할 npm 의존성 트리도 없다. 게임 슬러그·제목·설명을 5개 언어로 담은 등록 파일이 하나 있고, 게임 목록 페이지·각 게임의 상세 페이지·사이트맵은 전부 그 목록 하나에서 자동 생성된다. 여섯 번째 게임을 추가한다는 건 배열에 항목 하나를 추가하는 일이다.

다섯 게임을 짧게 소개하면:

  • 복셀 서바이벌 게임 — 낮밤 주기, 서로 다른 행동 패턴을 가진 몬스터 7종, 사흘째 밤마다 등장하는 보스전, 도전과제 시스템, 무기를 휘두르는 1인칭 전투 시점까지 갖췄다.
  • 3D 카트 레이싱 — 언덕·뱅킹·S커브가 있는 서킷, 서로 다른 스탯을 가진 플레이어블 캐릭터 11종, 드리프트로 충전하는 터보, 그리고 경기가 각본처럼 느껴지지 않으면서도 접전을 유지하게 해주는 러버밴딩 CPU.
  • 매치3 퍼즐 — 8x8 보드, 스페셜 타일 4종(한 가지 색을 통째로 지우는 레인보우 타일 포함), 파티클 효과, 그리고 오디오 파일 하나 없이 Web Audio API만으로 합성한 132bpm 배경음악.
  • 대전략 게임 — 실제 국경선을 시드로 삼아 보로노이 테셀레이션으로 약 1,200개 프로빈스를 생성한 실제 세계지도, 인구·식량생산 시뮬레이션, 각자의 외교·전쟁 로직을 가진 AI 국가 230개.
  • 플랫포머 — 굼바·쿠파 자리를 처녀귀신·도깨비·저승사자 같은 한국 요괴가 대신하는 런앤점프 게임, 손수 설계한 5개 스테이지, 요시 역할을 하는 탑승 가능한 유니콘까지.

이 중 어느 것도 서버가 필요하지 않았다. 진행 상황과 로컬 랭킹은 localStorage에 저장되고, 내보내기/불러오기 버튼 덕분에 세이브 파일은 그냥 JSON 다운로드 하나다 — 백엔드가 없다는 것에 대한 사실상 유일한 우회책이고, 여기에 나중에 실제 기기 간 랭킹을 연결하고 싶어질 경우를 대비한 훅(사용하지 않는 REMOTE_API 상수)까지 남겨뒀다.

배포 루프

사이트 자체는 정적 Astro 빌드이고, 새로 빌드한 dist/ 폴더를 gh-pages 브랜치로 강제 푸시하는 두 줄짜리 스크립트로 GitHub Pages에 올라간다 — 새로 발행할 게 생길 때마다 그냥 실행한다. 게임(그리고 사이트 나머지 전체)의 언어 전환은 별도의 지역화된 라우트 대신 평범한 ?lang= 쿼리 파라미터로 처리하는데, 덕분에 i18n 프레임워크 없이도 게임 빌드 하나로 5개 언어를 서빙할 수 있다. 모바일 지원은 나중에 다시 쓰는 대신 위에 얹는 레이어로 추가했다: 터치 기기는 자동으로 감지되고(pointer: coarse, 데스크톱에서 테스트할 땐 ?touch=1로 강제), 가상 방향키와 버튼은 기존 키보드 컨트롤이 쓰던 것과 완전히 똑같은 키 상태 객체에 값을 채워 넣는다 — 그래서 게임 로직 자체는 입력이 엄지손가락에서 온 건지 키보드에서 온 건지 전혀 알 필요가 없다.

가장 중요했던 결정: 사람 없이 테스트하기

이 프로젝트가 그 속도로 실제 배포까지 이어질 수 있었던 진짜 이유는 여기에 있다. 게임은 태생적으로 인터랙티브하고 시각적이라서, AI 에이전트가 스스로 검증하기 유독 어려운 소프트웨어다 — 텍스트 diff만 보고 “물리감이 괜찮다”를 단언할 수는 없으니까. 처음엔 헤드리스 브라우저로 사람처럼 게임을 조작해보려 했다. 그런데 이건 막상 부딪혀보기 전엔 잘 드러나지 않는 이유로 작동하지 않는다: 헤드리스 크롬의 가상 시간(virtual-time budget)은 requestAnimationFrame을 제대로 돌려주지 않는다. rAF 기반 게임 루프는 헤드리스 자동화 아래에서 가상 시간을 아무리 늘려도 쓸 만한 속도로 돌아가지 않는다. “페이지를 열고, 기다리고, 스크린샷을 찍는” 식으로 짠 테스트는 사실상 아무것도 검증하지 못한다.

이 다섯 게임 전부를 사람이 마우스 한 번 건드리지 않고도 검증 가능하게 만든 해법은 이거였다: 모든 게임에 ?test=sim 모드를 넣어서, requestAnimationFrame과 실제 시계에서 완전히 분리된 고정 타임스텝으로 게임 물리를 동기적으로 진행시키고, 판정 결과는 console.log가 아니라 console.warn으로 남긴다 — 헤드리스 크롬의 stderr 캡처는 warn은 확실히 잡아내지만 일반 log는 흘려버린다. 결정적이고 동기적인 스텝 진행 + warn 레벨 로깅, 이 하나의 패턴 덕분에 AI 에이전트는 플랫포머의 5개 스테이지가 전부 클리어 가능한지, 매치3 보드가 절대 데드락에 빠지지 않는지, 전략 게임에서 AI가 수십 턴을 진행한 뒤에도 프로빈스 인접 관계가 대칭을 유지하는지, 모든 세이브 파일이 정확히 왕복 저장·복원되는지를 — 실제 브라우저 탭에서 게임을 열어본 사람 하나 없이 — 확인할 수 있었다. 여기에 더해 ?shot=1이라는 가벼운 보조 모드는 프레임 시계를 한 순간 멈춰서 특정 극적인 장면(폭발 중인 순간, 보스와 마주치는 순간)을 타이밍 운에 기대지 않고 스크린샷으로 포착해 게임 커버 이미지로 쓸 수 있게 해준다.

가장 많이 배운 버그

대전략 게임은 약 1,200개의 프로빈스를 그릴 때, 각 프로빈스의 숫자 ID를 색상으로 인코딩해 숨겨진 캔버스에 래스터로 그린 뒤, 그 픽셀 색을 다시 읽어서 “이 좌표는 어느 프로빈스인가”, “어느 프로빈스끼리 인접해 있는가” 같은 질문에 답하는 방식을 쓴다. 캔버스를 그림이 아니라 조회 테이블로 쓰는 꽤 영리한 트릭인데 — 캔버스가 도형 경계에서 안티앨리어싱을 적용한다는 사실을 잊기 전까지는 그렇다. 그 블렌딩이 모든 프로빈스 경계마다 실제로는 존재하지 않는 ID를 조용히 만들어냈고, 그 결과 중심좌표 계산과 인접 데이터가 개별적으로는 미세하지만 합쳐지면 기괴한 방식으로 오염됐다 — 계산된 독일의 중심점이 대서양 한복판에 찍혀 있었다. 해법은 디코딩된 모든 픽셀을 해당 프로빈스의 실제 벡터 바운딩 박스와 대조해 검증하고, 그 검증에 실패한 픽셀은 주변 픽셀들의 다수결로 대체하는 것이었다. 이 교훈은 다른 게임에도 그대로 적용됐다: 렌더링 표면을 그림이 아니라 데이터 구조로 재사용할 때마다, 안티앨리어싱·블렌딩·밉매핑처럼 렌더링 파이프라인이 베푸는 편의 기능들이 그대로 정확성 버그가 될 수 있다.

이 작업에서 AI 에이전트가 진짜 잘하는 것

다섯 개를 만들고 나서 솔직한 결론은, AI 코딩 에이전트는 1인 게임 개발을 정확히 느리게 만드는 바로 그 부분들에서 진짜로 강하다는 것이다: 세이브 시스템을 연결하는 일, 스프라이트 소스를 구하는 대신 캔버스 위에서 절차적으로 벡터 아트를 생성하는 일, 측정만 가능하면 난이도 곡선을 튜닝하는 일(예를 들어 매치3 밸런스 조정은 그냥 수천 판을 시뮬레이션 플레이해서 이동당 평균 점수를 목표치와 비교하는 작업일 뿐이다), 그리고 한 게임에서 검증된 패턴을 다음 게임으로 옮기는 일. 하지만 결과물을 직접 플레이해보는 것을 대신할 수는 없다 — 몇몇 버그는 합성 테스트의 단언문은 기술적으로 통과했는데 실제 동작은 틀린 경우에만 드러났고, 그걸 잡아내는 진짜 방어선은 컨택트시트 스크린샷을 눈으로 보거나 완성 전에 직접 플레이해보는 것뿐이었다. 이 프로젝트 전체에서 가장 레버리지가 컸던 작업은 어떤 게임 하나가 아니라, ?test=sim 패턴을 처음 한 번 제대로 만들어 둔 것이었다 — 그 덕분에 두 번째 게임부터는 아무도 눈으로 보지 않고도 검증할 방법을 그냥 물려받았다.

다섯 게임 전부 menewsoft.com/games에서 무료로 플레이할 수 있다.

이 글에는 제휴 링크가 포함될 수 있습니다. 본문의 어떤 내용도 금융·투자 조언이 아닙니다.