①편에서 pi를 Gemini 무료 모델에 붙여 스네이크를 한 방에 뽑고, ②편에서 버그를 잡고 다듬어 완성했습니다. 마지막은 솔직한 회고입니다. 비싼 모델 없이, 무료 gemini-3.1-flash-lite만으로 코딩 에이전트를 굴려본 경험이 어땠는지.
1. 숫자로 본 결과
- 총 빌드 3라운드: 생성 → 버그수정 → 폴리시
- 라운드당 약 8~10초, 체감 지연 거의 없음
- 모델 호출: 핑 1회 + 빌드 3라운드 = 손에 꼽을 정도. 무료 티어(분당 호출 제한)로도 전혀 빠듯하지 않았습니다.
- 결과물: 단일
index.html약 6.4KB, 하이스코어 저장까지 되는 플레이 가능한 게임 - 비용: 0원
가벼운 작업에 한해서는 “무료 모델 + 좋은 하네스”의 조합이 충분히 실용적이라는 걸 확인했습니다.
2. flash-lite가 잘한 것
- 한 파일 게임을 한 방에: 캔버스, 게임 루프, 키 입력, 충돌, 점수, 오버레이까지 빠짐없이 구성했습니다.
- 의외로 좋은 기본 UI 감각: 시키지도 않은 박스 섀도우, 라운드 테두리, 레이아웃 정렬을 알아서 했습니다.
- 수정 지시를 정확히 반영: “이 파일을 읽고 1~5번을 고쳐라” 같은 구조화된 지시를 잘 따라갔습니다.
- 빠르다: 라운드당 10초 안쪽이라 반복이 부담 없습니다.
3. flash-lite의 한계
- “당연한 예외”를 놓침: 정지 상태에서 자기 충돌로 즉시 게임오버 — 요구사항에 명시 안 한 디테일은 빈다.
- 요구가 많아지면 흘림: 한 프롬프트에 항목이 많으면 일부를 빠뜨리기 쉬워, 번호로 쪼개 주는 것이 거의 필수였습니다.
- 스스로 검증하지 않음: 만든 결과를 브라우저로 직접 확인하는 건 결국 사람 몫. “되는 것처럼 보이는 코드”와 “실제로 도는 코드”는 다릅니다.
요약하면, 방향을 잘 잡아주는 운전자가 있을 때 빛나는 모델입니다. 알아서 다 해주길 기대하면 실망하지만, 명확히 쪼개서 시키면 가성비가 훌륭합니다.
4. 그대로 따라 할 수 있는 팁
① print 모드로 자동화하라. 대화형으로 일일이 치지 말고, -p로 프롬프트를 던지면 셸 스크립트로 묶을 수 있습니다.
set -a; . ./.env; set +a
pi -p --provider google --model gemini-3.1-flash-lite \
--api-key "$GEMINI_API" --no-session "..."② 요구사항은 번호 리스트로. “이것도 하고 저것도 하고”보다 1. ... 2. ... 3. ...가 누락을 줄입니다.
③ “Read X and fix…” 패턴을 적극 활용하라. 새로 만들게 하지 말고, 있는 파일을 읽혀서 고치게 하면 맥락이 유지됩니다.
④ 결과는 직접 확인하라. 게임이면 브라우저로 열어보고, 스크립트면 실행해봅니다. 모델은 “될 것 같다”고 말할 뿐 보장하지 않습니다.
⑤ 무거운 판단은 사람이, 반복 노동은 모델이. 버그의 원인을 짚는 건 사람이 빠르고, 그 수정의 손놀림은 모델이 빠릅니다.
직접 해보기 — 이 글에서 만든 게임
말로만 하면 재미없으니, 위 3라운드로 실제로 만들어진 게임을 아래에 그대로 띄웠습니다. 보드를 한 번 클릭한 뒤 화살표(또는 WASD)로 움직여 보세요.
▶ 전체 화면으로 플레이 ⬇ 게임 파일 다운로드 (index.html)
단 하나의 index.html 파일입니다. 다운로드해서 더블클릭하면 서버도 빌드도 없이 어디서든 그대로 돌아갑니다. 무료 모델 + pi가 만든 결과물이 이 한 파일이라는 게, 이 시리즈가 하고 싶었던 이야기의 전부이기도 합니다.
마치며
“비싼 모델이 없으면 코딩 에이전트는 못 쓴다”는 편견이 있었다면, 이번 실험이 작게나마 반례가 됐으면 합니다. 무료 flash-lite + pi의 print 모드만으로도, 방향만 잘 잡아주면 빈 폴더에서 플레이 가능한 게임까지 갈 수 있었습니다.
핵심은 모델의 크기가 아니라 작업을 어떻게 쪼개서 맡기느냐였습니다. 그게 결국 하네스(harness)를 잘 쓴다는 말의 진짜 의미일지도 모르겠습니다.
PI 시리즈를 여기까지 읽어주셔서 감사합니다. 직접 만든 게임이나 워크플로우가 있다면 언제든 공유해 주세요!