파트 1: AI를 활용해 30시간 안에 게임 만들기 — 실제 타임라인
Source: Dev.to
번역을 진행하려면 번역하고자 하는 본문 텍스트를 제공해 주세요. 현재는 링크만 포함되어 있어 번역할 내용이 없습니다. 텍스트를 알려주시면 그대로 마크다운 형식과 코드 블록, URL은 그대로 유지하면서 한국어로 번역해 드리겠습니다.
AI를 자동완성 도구가 아닌 개발 파트너로 대했을 때 어떤 일이 일어날까?
궁금해서 실험을 해봤습니다: 가능한 한 빨리 게임을 만들기, 속도와 반복을 중시하고 다듬기는 최소화. 별도의 기획 단계 없이. 상세 스펙도 없이. 빠른 프로토타이핑으로 실제로 무엇이 가능한지 확인해 보기 위해서였습니다.
그 결과물은 MagLava – 상승하는 용암을 피하기 위해 노드 사이를 휘두르는 마그네틱 플랫포머입니다. 6번의 개발 세션, 총 30 시간 정도 작업, 그리고 25개의 레벨, 7개 언어 번역, 데스크톱 앱까지 포함된 게임이 공개되었습니다.
Note: 이 접근 방식이 실험의 핵심이었습니다. 실제 제품 소프트웨어나 빠른 프로토타이핑을 넘어서는 작업에는 여전히 적절한 기획과 테스트가 필수입니다(추후 포스트에서 다룰 예정). 여기서는 반대 극단을 스트레스 테스트하고 있습니다.
커밋 로그
각 작업 후 AI 도구가 요약을 생성하도록 자주 커밋했기 때문에, 커밋 클러스터가 실제 작업 세션과 잘 맞아떨어집니다. Git 히스토리를 살펴보고 타임라인을 재구성했습니다:
| 날짜 | 커밋 수 | 예상 시간 | 무슨 일 있었나 |
|---|---|---|---|
| 12 월 18일 | 2 | ~1.5 시간 | 프로젝트 스캐폴드, Vue + Phaser 설정 |
| 12 월 19일 | 3 | ~2‑3 시간 | 핵심 마그네틱 극성 시스템 |
| 12 월 20일 | 27 | ~8‑12 시간 | 전체 움직임 재설계 + 15 레벨 |
| 12 월 21일 | 9 | ~4‑6 시간 | 모바일 컨트롤, 튜토리얼, PWA |
| 12 월 30일 | 13 | ~5‑7 시간 | 데스크톱 앱, 음악, 다듬기 |
| 1 월 15일 | 8 | ~3‑5 시간 | i18n (7개 언어), 25 레벨로 확장 |
| 총합 | — | ~25‑35 시간 (6세션에 걸쳐) | — |
간격을 보세요: 12 월 21일과 12 월 30일 사이에 9일, 마지막 세션 전에는 16일이 비었습니다. 캘린더상으로는 “한 달 동안 개발”이라고 보이지만 실제 작업 시간은 한 주 정도이며, 그 주가 한 달에 흩어져 있습니다.
“AI‑Assisted”가 실제 의미한 바
첫 날만 해도 6,555줄의 코드가 생성되었습니다 – 프로젝트 구조, 게임 설정, 메뉴 시스템, 라우팅, 스토리지 서비스, Vue와 Phaser 사이의 이벤트 브리지 등. 이 정도 스캐폴딩을 수작업으로 작성하려면 며칠이 걸렸을 것입니다.
놀라운 점은 코드 생성 자체가 아니라 그 외에 무엇이 나타났는가였습니다:
- 프로모션 웹사이트 (SEO, 사이트맵, 구조화된 데이터 포함) – AI가 구축.
- 전체 Electron 데스크톱 앱과 레벨 에디터 – 같은 이야기.
- 7개 언어를 지원하는 국제화 시스템 – 한 세션만에 구현.
AI가 이 모든 것을 처리하도록 목표를 잡은 건 아니었습니다. AI 파트너와 흐름 상태에 들어가면 “한 가지 더”라는 마찰이 급격히 줄어들기 때문에 이런 기능들이 자연스럽게 떠올랐습니다. 데스크톱 빌드를 추가하는 것이 “향후 로드맵 아이템”에서 “이번 세션에 바로 해보자”로 바뀐 것이죠.
숫자 뒤에 숨은 방법론
**“바이브 코딩(vibe coding)”**이라는 말을 들어보셨을 겁니다. 여기서는 플레이어 모드에 머물면서 문제를 기술적인 설명이 아니라 경험적으로 묘사하는 것이었습니다. 세션 중 실제로 사용한 프롬프트 예시입니다:
game just freezes! I can't actually SEE the LAVA LINE!!! I WANA SEE THE LAVA line.
And finally, we start way too close to the lava.오타, 대문자, 좌절감 – 모두 그대로였습니다. 픽셀 버퍼를 계산하지 않았고, 불공평함에 대한 느낌을 표현했습니다. AI는 “너무 가깝다”는 감정을 용암 라인 위에서 스폰 버퍼를 150 px에서 500 px로 늘리는 구체적인 수정으로 번역했습니다.
이 방법이 통하는 이유는 감정이 플레이어 경험을 목표로 할 때 유효한 기술 사양이 되기 때문입니다. “이게 불공평하게 느껴진다”는 “버퍼를 150 px에서 500 px로 늘려라”보다 더 많은 디자인 정보를 담고 있습니다.
st the Y‑offset parameter.”
Why the Timeline Matters
왜 이 타임라인이 중요한가
나는 30시간이 빠르다거나 느리다거나 주장하는 것이 아니다 – 게임 복잡도는 천차만별이다. 내가 주장하는 것은 이 타임라인이 내가 일한 방식 때문에 가능했다는 것이며, 단지 사용한 도구 때문만은 아니다.
전통적인 솔로 개발 파이프라인은 다음과 같다:
- 계획을 광범위하게 세운다.
- 아키텍처를 구축한다.
- 기능을 구현한다.
- 테스트한다.
정보가 부족한 상태에서 결정을 앞당겨 내린다.
내 파이프라인은 이를 뒤집었다:
- 무언가를 즉시 만든다.
- 그것을 플레이한다.
- 뭔가 잘못된 느낌을 설명한다.
- 반복한다.
AI가 “이건 별로다”를 “코드 변경은 여기다”로 번역해 주었다. 모든 시스템은 일시적인 것이었고, 모든 변경은 집중적이고 모듈식이었다. 무언가가 제대로 작동하지 않을 때, 나는 그것을 변호하지 않았다 – 다른 비전을 제시하고 다시 만들게 했다. 모든 라인을 직접 작성했을 때는 어려운 일이지만, 타이핑보다 지시하는 입장이면 쉬워진다.
What the Numbers Don’t Show
숫자가 보여주지 않는 것
돌이켜 보면 타임라인은 깔끔해 보이지만, 실제로는 그렇지 않았다.
Day 3 – 27개의 커밋이 한 번에 이루어진 대규모 세션 – 여기에는 Day 2에 만든 전체 움직임 시스템을 버리는 것도 포함되었다. 원래 개념은 극성 기반 등반이었다: 빨간 플랫폼은 끌어당기고, 파란 플랫폼은 밀어낸다. 나는 전체를 만들고 플레이했지만, 간접적이고 답답하며 내가 원했던 것과 동떨어진 느낌이었다.
그래서 나는 다른 것을 설명했다: “스윙을 원한다. 마치 스파이더맨처럼, 하지만 자석을 이용한다.” 몇 시간 안에 게임은 완전히 새로운 정체성을 갖게 되었다.
그 전환 – 그리고 나중에 일어난 또 다른 큰 전환 – 은 아마도 MagLava가 전혀 작동하게 된 이유일 것이다. 하지만 그 이야기는 더 길다.
다음 편: 프로젝트를 거의 죽음으로 몰아넣은 두 번의 전환과, 왜 감정적 프롬프트가 사양에서는 놓칠 수 있는 문제들을 포착했는지.
Tech stack for the curious: Vue 3 + Vite, Phaser 3, TypeScript, Electron (desktop), Firebase + itch.io (hosting), Claude (Opus via Claude Code CLI) for AI assistance.