애셋이 준비됐으니 이제 코딩입니다. 그런데 이번엔 제가 직접 짜지 않고 **클로드코드(Claude Code)**에 맡겼습니다. 여기서 제가 나름 정착시킨 워크플로우가 있는데, 꽤 잘 굴러가서 공유해봅니다.
프롬프트를 매번 쓰는 건 비효율적이다
AI 코딩 도구를 쓰다 보면 흔히 하는 실수가, 매번 "이거 해줘 저거 해줘"를 즉흥적으로 프롬프트로 던지는 겁니다. 이러면 몇 가지 문제가 생겨요.
- 이전에 뭘 요청했는지 기록이 안 남는다.
- AI가 맥락을 잃어버리면 다시 설명해야 한다.
- 프로젝트가 커질수록 "지금 이게 어떤 상태였지?"가 헷갈린다.
그래서 저는 SPEC.md라는 사양 문서 하나를 만들어서 그걸 단일 기준으로 삼았습니다. 게임의 모든 것 — 게임 루프, 상태 머신, 애셋 목록, 차트 로직, 색상 처리 방식, 심지어 화면에 쓸 한국어 문구까지 — 이 문서 하나에 다 담았어요.
그리고 클로드코드에는 이렇게만 말합니다.
"SPEC.md 읽고 이대로 만들어줘."
스코프 가드레일: AI가 오버하지 않게
SPEC을 짤 때 특히 신경 쓴 게 "하지 말 것" 목록입니다. AI 코딩 도구는 종종 시키지도 않은 걸 과하게 만듭니다. 프레임워크를 끌어오거나, 빌드 도구를 붙이거나, 파일을 잘게 쪼개거나요.
그래서 SPEC 상단에 못을 박아뒀습니다.
- 순수 HTML/CSS/JS만. React·Vue·번들러·npm 전부 금지.
- 차트 라이브러리 쓰지 말고 Canvas로 직접 그릴 것.
- 파일은 index.html / style.css / game.js + assets 로만. 과하게 쪼개지 말 것.
- 백엔드·DB·계정 전부 없음.
이렇게 경계를 명확히 그어두니, 클로드코드가 삽질 없이 딱 필요한 만큼만 만들어줬습니다.
변경은 CHANGELOG로 쌓는다
프로젝트가 진행되면서 수정할 게 계속 나옵니다. "부자 확률이 너무 높다", "색이 자꾸 겹친다", "말풍선이 정신없다" 같은 것들요. 이걸 매번 새 프롬프트로 던지는 대신, 저는 SPEC 문서 상단에 CHANGELOG 섹션을 만들어서 변경 사항을 위에 계속 쌓았습니다.
## 🔧 최근 변경 (CHANGELOG — CC는 여기부터 확인)
### v-latest
1. 가격/차트 로직을 "매수 전 / 매수 후"로 분리
2. 배경 "기본 장식 크아악 1마리" 사라지는 버그 수정
...
그러면 클로드코드에는 이 한 줄이면 끝입니다.
"SPEC 최신본으로 교체했어. 상단 CHANGELOG 보고 반영해줘."
이 방식의 장점은, 문서 하나만 넘기면 최근 변경분이 다 전달된다는 겁니다. 별도로 프롬프트를 길게 쓸 필요가 없고, 나중에 "내가 이걸 왜 이렇게 바꿨더라"를 돌아볼 기록도 남고요.
튜닝 값은 한곳에 모으게 했다
게임 밸런스는 결국 숫자 싸움입니다. 승률, 상승 강도, 말풍선 빈도, 원근 열 간격 같은 것들요. 이걸 코드 여기저기 흩어놓으면 나중에 조정할 때 지옥이 됩니다.
그래서 SPEC에 "튜닝 상수는 game.js 상단에 모아둘 것"이라고 명시했습니다. 덕분에 밸런스가 안 맞으면 그 값 몇 개만 만지면 됐어요. "승률이 너무 높네" 싶으면 DOWN_BIAS 하나 올리는 식으로요.
사람이 하는 일, AI가 하는 일
이 워크플로우를 굴리면서 느낀 건, 역할 분담이 명확해진다는 점입니다.
- 저는 "무엇을, 왜"를 정합니다. 게임이 어떤 감성이어야 하는지, 어떤 트레이드오프를 감수할지.
- 클로드코드는 "어떻게"를 처리합니다. 그 사양을 실제 코드로 옮기는 일.
- 화면을 보면서 하는 픽셀 단위 조정(말뚝 위치, 웅덩이 배치 같은)은 실시간으로 볼 수 있는 클로드코드 쪽에서 바로바로 잡았고요.
SPEC이라는 공유 문서가 그 사이의 계약서 역할을 한 셈입니다.
다음 편에서는
게임이 완성됐으니 이제 세상에 내놓을 차례입니다. 그런데 여기서 아주 현실적인 고민에 부딪혔어요. 도메인입니다. 단독 게임으로 배포하려니 도메인을 또 사야 하는데, 재미로 만든 게임에 그 비용을 쓰기가 부담스러웠거든요. 다음 편에서는 이 문제를 어떻게 풀었는지 — 기존에 운영하던 사이트에 하위 페이지로 붙인 이야기를 하겠습니다.
👉 플레이톡 에서 직접 써보실 수 있습니다.
