이 영상은 단테가 Codex CLI와 VS Code만으로 브라우저용 3D 레이싱 게임을 처음부터 만드는 라이브 코딩 편집본입니다. 몇 번의 프롬프트로 게임을 완성해 가는 과정에서 요구사항을 어떤 순서로 주는지, 커밋을 왜 자주 남기는지, 사용량 한도와 컨텍스트가 실제로 얼마나 줄어드는지 보여 줍니다. Codex CLI로 작은 프로젝트를 처음 끝까지 만들어 보려는 분께 맞는 내용이며, 버전과 요금제 이야기는 영상 게시 시점(2025-10-05) 기준입니다.
완성된 게임의 모습
먼저 결과물입니다. 시작 화면에서 두 가지 맵 중 하나를 고르면 레이스가 시작되고, Sunset Canyon을 고르면 배경이 바뀝니다. 맵도 바이브 코딩으로 에이전트가 직접 만들었습니다.
- 체크포인트를 지날 때마다 점수가 쌓이고, 화면 왼쪽에 타이머와 16개 체크포인트 중 몇 개를 지났는지 표시됩니다.
- 길을 벗어나면 속도가 느려지고, AI 경쟁자와 부딪히면 밀려납니다.
- 오른쪽 아래 미니맵은 M 키로 켜고 끌 수 있습니다.
- 레이스가 끝나면 최고 기록이 표시되고, 다시 시작할 수 있습니다.
게임이 제대로 돌아가려면 30프레임 이상이 필요한데, 실제로는 60프레임 정도가 나왔습니다. 완성본은 GitHub에 올라가 있습니다.
프로젝트 시작과 환경 확인
단테는 codex를 실행해 사용 중인 버전이 0.42.0임을 보여 주고, 새 디렉터리를 만들어 3D 레이싱 게임 프로젝트를 설정해 달라고 요청했습니다. 진행 중에는 /status로 상태를 확인했습니다. 이 명령으로 현재 모델(GPT-5 Codex, 가장 높은 추론 수준), 남은 컨텍스트, 그리고 5시간 한도와 주간 한도의 사용량을 볼 수 있습니다. 단테는 ChatGPT Plus 계정을 썼고, 촬영 시작 시점에 주간 한도는 38%를 써서 62%가 남아 있었습니다.
Codex는 README, .gitignore, package.json을 만들고 Vite 기반 개발 환경을 구성했으며, 로드맵에 GitHub Actions를 이용한 CI 구성까지 넣었습니다. 단테는 index.html 하나와 웹 서버만으로도 만들 수 있는 게임인데 파일을 많이 만든다고 평가하면서도, 이번에는 개입하지 않고 그대로 진행했습니다. 참고로 /init을 쓰면 AGENTS.md를 만들어 Codex가 코드를 쓸 때 지침으로 삼게 할 수 있다고 소개했습니다.
설치는 npm 대신 pnpm으로 했고, 서버가 뜨지 않아 나온 에러 메시지를 그대로 Codex에 붙여 넣자 pnpm dev로 다시 실행하라는 안내를 받았습니다. 개발 지식이 없어도 에러를 그대로 전달하면 해결 방향을 얻을 수 있다는 예입니다.
첫 결과의 문제와 요구사항 우선순위
첫 실행 결과는 기대와 거리가 멀었습니다. 뒤 방향키를 누르면 앞으로 가고, D를 누르면 왼쪽으로, A를 누르면 오른쪽으로 빙빙 돌았습니다. 길을 벗어나도 아무 제약이 없었습니다.
여기서 단테가 강조한 교훈은 순서입니다. 처음 의도한 방향으로 만들어지지 않았을 때는 스타일을 예쁘게 하거나 차 모양을 바꾸는 요청보다, 가장 먼저 필요한 최소 요구사항부터 고치게 해야 합니다. 조작 방향과 도로 이탈 처리를 먼저 바로잡자 다음 결과에서는 차의 앞뒤가 분명해지고, 풀밭과 중앙선이 있는 도로가 생겼습니다. 기본 틀이 잡히자 이후 작업이 수월해졌습니다. Codex는 작업이 끝날 때마다 다음 단계로 할 일을 추천해 주므로 이를 참고해 다음 프롬프트를 이어 갈 수 있습니다.
커밋을 자주 남겨야 하는 이유
GitHub에 새 저장소를 만들 때는 README, .gitignore, 라이선스를 추가하지 않았습니다. Codex가 이미 기본 파일을 만들어 뒀기 때문에, GitHub가 안내하는 명령 중 원격 저장소를 추가하고 main 브랜치로 푸시하는 부분만 복사해 실행하면 됩니다.
단테는 작업 단위가 하나 끝날 때마다 커밋을 남기라고 권했습니다. 예를 들어 요청의 90%가 완성된 상태에서 나머지 10%를 위해 프롬프트를 다시 보냈는데, 오히려 완성도가 40% 수준으로 떨어질 수 있습니다. 이때 커밋 기록이 없으면 되돌리기 어렵습니다. Cursor처럼 IDE에 통합된 도구는 특정 대화 이전으로 되돌리는 기능이 있지만, 촬영 당시 Codex 확장에는 그런 기능이 없어 보였다고 설명했습니다. 커밋 상태 확인에는 VS Code의 Git Graph 확장을 사용했습니다.
또 Codex CLI가 처음 실행되는 디렉터리에서는 권한 요청이 다시 뜨는데, 이는 해당 폴더 안에서의 권한을 새로 묻는 것입니다. Codex는 실제 개발자가 터미널에 명령을 치듯 bash나 zsh 명령을 실행하고, git diff로 변경 사항을 확인하는 과정이 투명하게 드러난다는 점도 짚었습니다.
사용량과 컨텍스트, 그리고 병렬 작업
경쟁자 추가, 가로등과 나무 같은 배경 요소, 미니맵, AI 경쟁자가 중앙선만 따라가지 않고 실제 운전하듯 움직이게 하는 요청을 차례로 보냈습니다. Vite의 핫 리로드 덕분에 개발 서버를 껐다 켜지 않아도 변경이 바로 반영됐습니다. 진행 중 남은 컨텍스트는 95%에서 67%, 56%, 52%로 줄었습니다.
사용량은 더 빠르게 줄었습니다. 필수 기능을 다 만들기 전에 5시간 한도의 40%를 썼고, 요청한 기능까지 만들면 50%를 넘을 것으로 봤습니다. 단테는 이 정도 크기의 앱을 만들려면 Plus로는 부족하다고 느낄 수 있으며, 프롬프트를 더 잘 쓰거나, 만드는 범위나 빈도를 줄이거나, 더 높은 요금제를 쓰는 선택지가 있다고 정리했습니다.
이번에는 일부러 프롬프트를 순차적으로 보냈지만, 다음 요청을 큐에 넣어 두거나 메모 정리 같은 부차 작업을 병렬로 했다면 훨씬 일찍 끝났을 것이라고 덧붙였습니다. 라이브 코딩은 한 시간 정도 걸렸고, 최종 결과는 처음 세운 요구사항을 모두 충족했습니다.
정리
- 결과가 의도와 다를 때는 꾸미기보다 조작, 충돌 같은 최소 요구사항부터 고치게 해야 합니다.
- 작업 단위마다 커밋을 남겨야 프롬프트로 품질이 떨어졌을 때 되돌릴 수 있습니다.
/status로 모델, 남은 컨텍스트, 5시간·주간 사용량을 수시로 확인하는 것이 좋습니다.- 에러 메시지는 그대로 Codex에 붙여 넣으면 해결 방향을 얻을 수 있습니다.
- 순차 작업은 느리므로, 요청을 큐에 넣거나 병렬로 진행하면 시간을 줄일 수 있습니다.