첫 게임을 만들 때는 모든 것이 처음이었습니다. 캐릭터를 어떻게 걷게 하는지, 효과음은 어디서 구하는지, 화면이 끊기면 무엇부터 의심해야 하는지 하나도 몰랐습니다. 매번 처음부터 찾고, 처음부터 만들고, 처음부터 틀렸습니다.

지금은 이 사이트에 올린 게임과 앱이 마흔 개를 넘었습니다. 돌아보면 게임 수보다 더 크게 바뀐 것이 있습니다. 새 게임을 시작하는 출발선이 매번 조금씩 앞으로 당겨졌다는 점입니다. 게임 하나를 끝낼 때마다 손에 남는 것이 생기고, 그게 다음 게임의 바닥이 됐습니다. 이 글은 그 쌓이는 과정과, 쌓인 것을 클로드 코드의 스킬로 묶어 두는 방법에 대한 이야기입니다.

쌓이는 것은 두 가지였습니다

하나, 백 데이터 — 누구나 쓸 수 있게 풀린 에셋

게임을 만들다 보면 소리, 3D 모델, 텍스처가 계속 필요합니다. 처음에는 필요할 때마다 검색했는데, 어느 순간부터는 받아 둔 것을 먼저 뒤지게 됐습니다.

  • 효과음: 저작권을 포기한(CC0) 게임 효과음을 291개 모아 둔 폴더가 있습니다. 발소리, 타격음, 물소리 같은 것은 이제 새로 찾지 않습니다
  • 캐릭터와 짐승: Quaternius, KayKit처럼 무료로 공개된 3D 캐릭터·동물 묶음을 받아 두고, 뼈대 방향이 제각각인 것을 바로잡는 요령까지 같이 적어 두었습니다
  • 건물과 지형: 내려받아 둔 GLB 모델 묶음이 있습니다. 다만 이건 출처 표기가 의무이고 AI 학습에 쓰지 말라는 조건이 붙어 있어서, 쓸 때마다 조건을 다시 확인합니다

"무료"라고 다 같은 무료가 아니었습니다. CC0처럼 아무 조건이 없는 것도 있고, 출처를 밝혀야 하는 것도 있습니다. 받을 때 조건을 같이 적어 두지 않으면 나중에 쓸 수 있는지 판단하느라 다시 시간을 씁니다. 그래서 에셋 폴더에는 파일과 함께 어디서 왔고 무슨 조건인지를 꼭 남깁니다.

둘, 게임마다 만든 특화 기능

더 값진 쪽은 이쪽이었습니다. 게임 하나를 위해 만든 기능이 다른 게임에서 다시 쓰이는 일이 생각보다 자주 일어났습니다. 대표적인 두 가지를 적어 보겠습니다.

여우 한 마리가 사람을 걷게 했습니다

영상 속 여우의 걸음을 3D 여우에게 옮기는 작업을 한 적이 있습니다. 여우 사진 한 장으로 내 컴퓨터에서 돌아가는 Hunyuan3D 2.1로 3D 모델을 만들고, 뼈를 35개 심었습니다. 그다음이 핵심이었습니다. 영상의 한 장면마다 자세를 잡고, 그려 보고, 영상과 비교하고, 고치는 일을 반복해서 뼈의 각도를 맞췄습니다. 그렇게 만든 걸음은 무인도 전초기지의 여우가 됐고, 영상에 없던 질주는 걷기 동작의 다리 순서를 다시 배치해서 빚어냈습니다.

여기까지는 여우 하나를 위한 작업이었습니다. 그런데 사람의 움직임을 만들 차례가 왔을 때, 이 방식이 거의 손대지 않고 그대로 쓰였습니다. 다리가 넷에서 둘로 줄었을 뿐, 영상을 보고 뼈를 맞추고 그려서 비교하는 순서는 똑같았습니다. 여우를 할 때 이미 겪은 함정들, 예를 들어 옆모습만 보고 맞추면 좌우가 몰래 틀어진다는 것 같은 문제도 처음부터 피해 갈 수 있었습니다.

처음에 여우를 만들 때 "여우 걷게 하기"로 생각했다면 이렇게 되지 않았을 겁니다. 돌이켜 보면 제가 만든 것은 여우가 아니라 "영상 속 동작을 뼈대로 옮기는 방법"이었습니다. 대상이 바뀌어도 방법은 남습니다.

자동차는 게임을 옮겨 다녔습니다

자동차도 비슷했습니다. 아직 공개하지 않은 탐험용 4x4를 만들면서 차체를 코드로 설계하고, 문이 열리고 닫히게 하고, 실내와 엔진룸을 만들고, 엔진 소리를 합성했습니다.

이 차량 코드는 무인도 전초기지로 옮겨 가서 섬을 달리는 지프가 됐습니다. 원본 폴더를 불러다 쓰지 않고 사본을 통째로 가져왔는데, 이게 작은 교훈이었습니다. 원본을 계속 참조하면 4x4 쪽을 고칠 때마다 무인도 게임이 같이 흔들립니다. 게임 사이에서 옮길 때는 복사해서 독립시키는 편이 안전했습니다.

NT DRIVE에서는 한 발 더 나아갔습니다. 차를 여러 대 고를 수 있게 만들면서 차 한 대 = 설정 한 항목 + 차체를 만드는 함수 하나라는 구조를 잡았습니다. 물리, 엔진 성격, 소리, 카메라 위치를 전부 그 설정에서 읽으니 차를 하나 더하는 일이 작아졌습니다. 자동 변속을 만들며 겪은 함정도 남았습니다. 브레이크를 밟는 중에 단을 올리면 변속기가 위아래로 오락가락하는데, 이걸 한 번 겪고 나니 다음 차에서는 처음부터 막고 시작합니다.

쌓인 것을 스킬로 묶는 방법

문제는 이렇게 쌓인 것들이 폴더와 제 기억 속에만 있으면 다음 게임에서 다시 찾아야 한다는 점입니다. 어느 폴더에 있었는지, 그때 어떤 함정이 있었는지를 매번 되짚게 됩니다. 그래서 반복해서 쓰이는 것은 클로드 코드의 스킬로 등록해 두기 시작했습니다.

스킬은 생각보다 단순합니다. 폴더 하나에 SKILL.md 파일 하나를 넣으면 됩니다. 여우 사례를 스킬로 묶는다면 대략 이런 모양입니다(설명을 위해 줄인 예시입니다).

~/.claude/skills/motion-transfer/
  SKILL.md        ← 무엇을, 언제, 어떤 순서로
  scripts/        ← 같이 쓰는 도구 (선택)
---
name: motion-transfer
description: 영상 속 동물이나 사람의 동작을 3D 뼈대 애니메이션으로 옮긴다.
  "이 영상처럼 걷게 해줘", "동작을 뼈대에 입혀줘" 같은 요청에 쓴다.
---

# 동작 옮기기

## Steps
1. 사진으로 모델을 만들고 뼈를 심는다
2. 영상 장면마다 자세 → 그려 보기 → 비교 → 고치기를 반복한다
3. 좌우 틀어짐을 따로 잰다 (옆모습만 맞추면 몰래 틀어진다)

## 끝났다는 증거
- 겹침 비율과 관절 오차를 숫자로 남긴다

모든 프로젝트에서 쓸 스킬은 사용자 폴더(~/.claude/skills/)에, 한 게임에서만 쓸 스킬은 그 저장소의 .claude/skills/ 안에 둡니다. 실제로 저는 스프라이트를 만드는 스킬과, 다른 AI에게 제 결과물을 일부러 깐깐하게 검토시키는 스킬을 등록해 두고 씁니다.

스킬을 써 보며 알게 된 요령이 몇 가지 있습니다.

  • 설명(description)이 제일 중요합니다. 클로드는 이 한 줄을 보고 스킬을 꺼낼지 정합니다. 무엇을 하는지보다 언제 써야 하는지를 적어야 하고, 제가 실제로 하는 말투(한국어 요청 예시)를 넣어 두면 훨씬 잘 불립니다
  • 겪은 함정을 넣습니다. 순서만 적은 스킬은 인터넷의 일반 설명과 다를 게 없습니다. 제 게임에서 실제로 틀렸던 지점이 들어가야 다음에 같은 실수를 안 합니다
  • 끝났다는 증거를 정합니다. "잘 됐다"가 아니라 어떤 검사를 돌려서 어떤 숫자가 나오면 끝인지를 적어 둡니다
  • 두 번째로 쓰일 때 스킬로 만듭니다. 한 번 쓰고 끝날 코드까지 스킬로 만들면 오히려 찾기 어려워집니다. 여우의 방식이 사람에게 쓰였을 때처럼, 두 번째 쓰임이 보이는 순간이 묶을 때입니다

스킬로 묶기에는 작은 것들, 예를 들어 three.js에서 화면이 끊길 때 의심할 목록 같은 것은 따로 메모로 남겨 두고 새 작업을 시작할 때 먼저 읽게 합니다. 무인도 전초기지에서는 첫 화면이 끊기는 원인이 셰이더를 처음 그리는 순간에 엮는 데 있다는 것을 찾아 정리했고, 사이렌 러시의 끊김도 셰이더를 미리 엮어 두는 방식으로 줄였습니다. 한 게임에서 찾은 원인이 다음 게임에서는 처음부터 의심할 목록에 올라 있는 것입니다.

그래서 게임이 더 부드럽고 풍성해졌습니다

스킬과 메모가 쌓이면서 달라진 점은 속도만이 아닙니다. 예전에는 기본기를 맞추는 데 시간이 다 들어갔다면, 지금은 그 시간을 게임만의 재미에 씁니다. 짐승이 걷는 방식, 차가 달리는 느낌, 끊김 없는 첫 화면 같은 바닥은 이미 깔려 있으니, 그 위에 무엇을 더 얹을지를 고민하게 됩니다. 게임 하나하나의 완성도가 올라가는 이유가 결국 이것이었습니다. 앞선 게임들이 다음 게임의 어깨가 되어 주는 셈입니다.

공개된 프롬프트를 계속 읽고 배우시길 권합니다

마지막으로 꼭 권하고 싶은 것이 있습니다. 다른 사람이 공개한 프롬프트를 꾸준히 읽고 공부하는 것입니다.

스킬도 결국 잘 쓴 프롬프트입니다. 무엇을, 언제, 어떤 순서로 시키고, 끝났는지를 어떻게 확인할지 적어 둔 글이니까요. 그래서 남들이 공개한 프롬프트를 볼 때마다 배울 점이 있습니다. 칸을 어떻게 나눴는지, 같은 요구를 몇 번 반복하는지, 검사를 어디에 붙였는지를 보면 제 스킬을 어떻게 고칠지가 보입니다. 저는 그렇게 읽은 것을 프롬프트 해부 같은 글로 정리하고 있습니다.

다만 읽을 때 두 가지는 지키는 편입니다. 문장을 그대로 베끼기보다 구조를 봅니다. 그리고 좋아 보이는 방법이라도 제 게임에서 한 번 검증된 것만 스킬에 넣습니다. 남의 프롬프트에서 배운 구조에 제가 직접 겪은 함정을 더하면, 그게 가장 쓸모 있는 스킬이 됩니다.

아직 모르는 것

  • 스킬이 언제나 불리지는 않습니다. 설명이 애매하면 클로드가 스킬을 꺼내지 않고 처음부터 다시 하려 듭니다. 설명을 고쳐 가며 맞추는 중입니다
  • 사람 움직임이 여우만큼 정밀한지는 아직 숫자로 견주지 못했습니다. 같은 방식이 쓰였다는 것까지가 확인한 내용입니다
  • 무료 에셋의 조건은 바뀔 수 있습니다. 받아 둔 당시의 조건을 적어 두지만, 공개하는 게임에 넣을 때는 출처 페이지를 다시 확인합니다

게임이 하나 더 늘 때마다 스킬도 하나씩 늘고 있습니다. 쌓인 것이 어떤 게임으로 이어졌는지는 다음 개발 노트에서 또 적어 보겠습니다.