AI와 함께 개발하다 보면 이상한 비대칭이 하나 생깁니다. 결과물인 코드는 git에 차곡차곡 남는데, 그 코드를 만들게 한 내 말들은 어디에도 남지 않는다는 점입니다. 세션이 끝나면 대화는 사라지고, 며칠 뒤에 남는 건 커밋 메시지 한 줄뿐입니다.
그래서 저는 넉 달 전부터 제가 AI에게 입력하는 모든 프롬프트를 자동으로 기록하고 있습니다. 이번 글은 게임 제작기가 아니라, 이 기록이 실제 개발에서 어떤 도움을 줬는지에 대한 이야기입니다. 저도 이 방법을 어딘가에서 본 적은 없고, 어느 날 문득 '이런 걸 남겨두면 좋을 수 있지 않을까?' 하는 생각이 들어 남기기 시작했습니다. 그렇게 4개월 정도 쌓아보니 "이건 계속할 만하다"는 확신이 생겨서, 그 경험을 공유해 봅니다.
1. 셋팅: 훅 하나로, 손 대지 않고 쌓이게
방식은 단순합니다. Claude Code에는 훅(hook)이라는 기능이 있는데, 특정 이벤트가 일어날 때마다 지정한 스크립트를 실행해 주는 장치입니다. 그중 UserPromptSubmit 훅은 제가 프롬프트를 입력해서 전송하는 순간마다 실행됩니다. 여기에 짧은 셸 스크립트 하나를 걸어두었습니다.
# UserPromptSubmit 훅에 연결된 스크립트 (핵심만 발췌)
LOG_FILE="$HOME/.claude/prompt-logs/$(date +%Y-%m-%d).md"
PROMPT=$(echo "$INPUT" | jq -r '.prompt') # 방금 입력한 프롬프트
PROJECT=$(basename "$SESSION_CWD") # 어떤 프로젝트에서 입력했는지
echo "[$(date +%H:%M)] ($PROJECT) $PROMPT" >> "$LOG_FILE"날짜별 마크다운 파일에, 시각과 프로젝트 이름을 붙여 한 줄씩 덧붙이는 게 전부입니다. 이렇게 쌓인 로그는 이런 모습입니다.
[14:09] (lezhin-web-front) 상하 좌우 코너에 배치가 안되고 있어.
항상 다이아몬드 꼴이거나 삼각형 꼴이 되더라.
왜 2칸 이상 떨어진 시바는 배치가 안되는거야?지난달 팅글팡 제작기에서 "버그 하나에 회귀 테스트 하나는 사람이 시켜서는 안 지켜진다, 셋팅으로 강제해야 한다"고 썼는데, 기록도 똑같았습니다. 제가 뭔가를 따로 하는 순간 기록은 반드시 끊깁니다. 훅으로 걸어두면 제가 잊어도 쌓입니다. 그렇게 4개월간 일별 로그 파일 70개, 프롬프트 약 2,700개가 모였습니다. 텍스트뿐이라 전부 합쳐도 1.2MB밖에 안 됩니다.
한 가지 미리 말씀드리면, 이 로그는 git에 커밋하지 않고 제 개인 공간에만 둡니다. 프롬프트에는 정제되지 않은 온갖 것이 다 남기 때문입니다. 그래서 공개하기에는 쑥스러운 기록이라, 나만 보려고 나를 위해 저장해두는 것에 가깝습니다.
2. 커밋 메시지가 남기지 못하는 것
git은 훌륭한 기록 장치지만, 남기는 것은 기본적으로 결과입니다. 커밋 메시지는 "무엇이 바뀌었나"를 말해주지, "왜 그렇게 하기로 했나"와 "어떤 시행착오 끝에 거기 도달했나"까지 말해주지는 않습니다.
사람이 직접 코드를 짜던 시절에는 이 간극이 견딜 만했습니다. 내 손으로 짠 코드니까, 코드를 다시 읽으면 당시의 고민이 어느 정도 되살아나거든요. 그런데 AI 코딩에서는 사정이 다릅니다. 코드를 내가 짜지 않았기 때문에, 며칠만 지나면 커밋과 코드만 봐서는 그때의 판단 과정이 잘 재구성되지 않습니다.
반면 프롬프트에는 그 판단 과정이 날것 그대로 남습니다. 어떤 증상을 보고 문제라고 느꼈는지, 어떤 방향은 시도했다가 접었는지, 왜 이 방식을 골랐는지. 커밋이 결과의 기록이라면 프롬프트는 의도의 기록입니다.
3. 게임 하나의 탄생이 통째로 남는다
프롬프트를 공개하는 건 사실 조금 창피하기도 한 일입니다. 잘 정리된 문장이 아니라 구어체 반말로, 그날그날 생각나는 대로 적은 것들이라서요. 그래도 기록이 어떤 것인지 보여드리려면 실물이 필요하니, 몇 개의 예시만 올려보겠습니다.
지금 오락실 개발중 목록에 있는 타워디펜스 게임 길막TD의 가장 첫 프롬프트입니다. 이 게임의 기획서는 따로 없습니다. 이 프롬프트가 기획서였습니다.
[13:27:20] 모바일에서 플레이하기 좋은, 타워디펜스 게임을 만들어줘. 다른 오락실 게임들 처럼 회원랭킹이 있을거야. 50개의 waves로 만들어져서 점수경쟁하기 좋은 게임으로 만들어줘. 이 조건 하에서 가장 재미를 느낄 수 있을 게임을 만들어줘. 스테이지를 클리어하더라도 게임은 리셋되지 않고 계속 이어지는 구조야. 타워디펜스에서의 wave구조가 어떻게 되어있는지 리서치해보고, 타워디펜스의 난이도나 타워 능력 설계를 어떻게 디자인하는지 리서치해보고 시작해. 몬스터 다니는 길이 정해져있는 타워디펜스가 아닌 맵 전체에 타워를 지을 수 있고, 몬스터들은 맵에서 4개의 포인트를 찍고 나가는 워크래프트 유즈맵세팅식 타워디펜스가 되게 해줘. 몬스터가 타워를 지나갈 수 없으니 타워로 길을 만드는 셈인데, 모든 길을 막아서 몬스터가 다음 포인트로 지나갈 수 없게 되면 몬스터가 타워를 공격해서 부수게 해줘. 타워의 체력과 타워의 체력회복력 몬스터의 공격력이 적절히 셋팅되어서 너무 빨리 부서지거나, 너무 늦게 부서지지 않도록 해줘. 아주 급하면 길을 막을 수도 있지만, 길을 막으면 보통 3초정도면 몬스터에 의해 길이 부서지는 정도의 공격력 셋팅이면 좋겠어. 길이 막혀있지 않으면 몬스터들은 공격을 하지 않고 이동만 하는거야.
그리고 이 첫 프롬프트 뒤로, 한 시간이 채 안 되는 동안 수정 요청이 이렇게 이어졌습니다.
[13:44:46] 게임을 수정해줘. 맵이 4:3 비율로 보이는데, 3:5 정도의 비율로 바꾸면 좋겠어. 입구와 출구를 맵 안에 두지 말고, 맵 밖에 두어줘. 몬스터들이 맵 밖에서 안으로 들어와서 다시 밖으로 나가는 느낌이 되게. 캔버스의 max-width는 600px로 두어줘. 고밀도 디스플레이에서는 고해상도로 보이게 해줘. 지금은 몬스터들의 이동경로를 선으로 그려서 시각적으로 보이게 하고 있는데, 보이지 않게 바꿔줘. 몬스터가 향하는 각 포인트들은 인지할 수 있게 시각적 힌트를 남겨놓아야 하고, 출구와 입구도 텍스트가 아닌 다른 방식으로 시각적 힌트를 줘. 그래픽을 향상하는 방법을 고민해서 보기 좋게 꾸며줘. 테마가 있어도 좋겠어.
[13:52:47] 타워와 몬스터 간의 상성관계가 좀 더 뚜렷하게 해줘. 어떤 타워는 보스몹에게 강하고 일반몹에는 약하고, 어떤 타워는 공중몹에 강하고. 웨이포인트 설정시 타워에 영향을 받지 않고 포인트만 찍고 날아가는 공중 몬스터도 필요해. 그런 몬스터의 등장을 예상할 수 있게, 다음 웨이브에서는 어떤 타입이 나온다는 예고 창도 필요하고. 전반적으로 난이도가 너무 쉬워. 깨기 어려워서 매우 머리를 잘 써서 쥐어짜야 클리어할 수 있는 정도의 난이도로 설정을 해줘. 깨기 힘들지만 여러번 재시도하면서 방법을 찾아나가서 여러번의 재시도 끝에 겨우 클리어 할 수 있어야 재미있는 타워디펜스가 돼. 각 타워와 몬스터간의 상성같은것을 굳이 구체적인 텍스트로 설명하지 않으면서도 인지시키려면 대중적으로 알려진 테마들과 많은 게임들에서 사용하고 있는 상성을 조사해서 테마를 잘 입혀서 하면 될거 같아.
[13:59:18] 현재 그리드가 5:3의 비율인거 같아. 3:5의 portrait 비율로 바꿔줘. 그리고 여전히 입구와 출구가 맵 안에 있어. 맵 바깥에 있도록 바꿔주고, 입구와 출구에 대한 시각적 힌트를 남겨줘. 몬스터가 이동하는 루트를 시각적으로 그려놓은 선도 없애줘.
[14:04:01] 몬스터가 향해가는 각 포인트가 너무 크게 그려져있어. 작게 표시해줘. 순서를 예상할 수 있게 숫자 표시를 해줘. 그리고 각 웨이브는 해당 웨이브의 몬스터가 모두 죽으면 5초카운트후 자동으로 다음 카운트 시작이 되게 해줘. 수동으로 웨이브 시작 버튼을 눌러서 다음 웨이브를 빠르게 시작할 수 있고, 그렇게 하면 남은 시간에 비례해서 아주 작은 보너스 포인트를 줘.
[14:07:15] 포인트의 표시 크기는 적절한데 숫자가 너무 작아. 숫자를 지금보다 크게 보이게 해줘. 몬스터를 좀 더 캐릭터 답게 그려줘. 각 타입에 맞는 모양으로 그려줘. 상성이 테마적으로 느껴질 수 있게.
[14:10:32] 타워의 설명 텍스트가 공간을 먹는거 같으니 없애줘. 대공 텍스트도 빨간 점을 찍어서 힌트만 남겨줘. UI의 공간을 많이 차지 하지 않도록 해서 게임 맵이 사용하는 크기를 더 늘리고 싶은 취지야. 최대한 UI가 사용하는 공간을 줄여서 게임이 공간을 많이 사용하게 해줘.
[14:18:23] waves 는 정확히 텍스트로 표현을 해줘. 줄일 수 있는 게 있고, 줄여야하는게 있고 안줄여도 되는게 있잖아. 어떤 정보 텍스트는 게임위에 띄워도 되고, 다른 버튼과 같이 두지 않아도 되는게 있고 그럴거야. 레이어로 올려도 되는 정보는 올려서 UI가 먹는 공간을 줄여주고, 그러면서도 정보 표시는 충분히 되게 해줘.
다시 읽어보면 이 로그에는 커밋 히스토리가 담지 못하는 것들이 들어 있습니다. "길을 막으면 3초 정도면 부서지는 공격력"이라는 밸런스 수치의 근거, "여러 번 재시도 끝에 겨우 클리어해야 재미있다"는 난이도 철학, "UI 공간을 줄여 게임 맵을 키운다"는 레이아웃 판단의 취지 같은 것들요. 나중에 이 게임을 다듬을 때 "왜 이런 설정이지?"라는 질문이 생기면, 답은 코드가 아니라 이 기록에 있습니다. 즉흥적으로 시작한 게임이라도, 로그를 열면 처음의 기획 의도가 그대로 남아 있는 셈입니다.
4. 기록이 실제로 일한 장면들
쌓아두기만 한 건 아니고, 실제로 꺼내 쓴 장면들이 있습니다.
장면 1: 한동안 손 놓았던 코드로 돌아갈 때
오락실 게임 하나를 몇 주 만에 다시 정리하게 됐을 때, 에이전트에게 이렇게 시켰습니다.
"오락실 게임 블록트릭스의 내용을 살펴보고, 버그나 정리해야 할 내용을 확인해봐. 이전 커밋의 메시지나 프롬프트 로그 중에 참고할 것을 찾아봐도 좋겠어."
에이전트는 커밋 히스토리와 함께 당시 제 프롬프트들을 뒤져서, 그때 어떤 요청이 오갔고 어떤 문제가 미해결로 남았는지를 정리해 왔습니다. 흥미로운 건 이 검색을 제가 아니라 에이전트가 한다는 점입니다. 기록을 쌓는 것도 자동, 꺼내 읽는 것도 AI의 일이라, 저는 그냥 "로그도 참고해봐" 한마디만 얹으면 됩니다.
장면 2: 프롬프트 자체가 설계 메모가 될 때
시바런을 만들 때 이런 프롬프트를 쓴 적이 있습니다.
"아까는 시바가 바운스될 때 교착상태를 체크했는데 그건 오히려 나았어. 근데 지금은 시바가 화면 밖으로 빠져나갈 때만 체크하니까 실제 교착상태가 발생해도 failed 화면이 뜨지 않아. 왜냐면 교착된 시바는 애초에 화면 밖을 빠져나갈 수 없잖아."
이건 버그 신고이면서 동시에 "교착 판정을 언제 해야 하는가"에 대한 논리가 담긴 설계 메모입니다. 이런 판단의 근거는 보통 코드에도 커밋 메시지에도 남지 않고 휘발되는데, 로그에는 제 말투 그대로 남아 있습니다.
장면 3: 제작기와 회고의 사료가 될 때
사실 지난달 팅글팡 제작기에 인용했던 프롬프트들, 예를 들어 "16스테이지인데 얼음 깨기 목표가 9/10이야. 보드에는 남은 얼음이 없는데?" 같은 문장은 제 기억에서 나온 게 아니라 이 로그에서 나왔습니다. 글을 쓸 때 로그를 열어 그 무렵의 기록을 훑으면, 뭘 했는지가 아니라 뭘 하려다 뭘 겪었는지가 시간순으로 복원됩니다. 월간 업무 정리나 회고를 쓸 때도 마찬가지입니다. 기억이 아니라 기록에 기대어 쓰게 됩니다.
5. 한계와 주의할 점
물론 좋은 점만 있는 건 아닙니다. 4개월 해보면서 신경 쓰게 된 것들입니다.
로그는 아무거나 다 남깁니다. 훅은 판단하지 않고 전부 기록하기 때문에, 업무와 무관한 혼잣말이나 잠깐의 딴 궁리, 붙여넣은 자료까지 그대로 남습니다. 제가 이 로그를 git 밖 개인 공간에만 두는 이유이고, 이번 글처럼 어딘가에 인용하기 전에는 반드시 한 번 훑어봐야 하는 이유이기도 합니다.
대화의 반쪽만 남습니다. 이 로그에는 제 프롬프트만 있고 AI의 답변은 없습니다. 처음엔 반쪽짜리 기록인 가 싶었는데, 오히려 장점에 가까웠습니다. 답변까지 다 남기면 로그가 수십 배로 불어나 검색이 어려워지는데, AI의 답은 어차피 코드와 커밋으로 남아 있으니까요. 의도는 로그가, 결과는 git이 나눠 맡는 구조입니다.
꺼낼 수 없는 기록은 기록이 아닙니다. 날짜별 파일, 시각과 프로젝트 이름 태그라는 단순한 형식 덕분에 grep이든 에이전트든 쉽게 검색할 수 있습니다. 형식 없이 쌓기만 했다면 4개월치 로그는 그냥 큰 텍스트 덩어리였을 겁니다.
마무리
정리하면 세 가지입니다.
첫째, 커밋은 결과를 남기고 프롬프트는 의도를 남깁니다. 코드를 AI가 짜는 시대에는 의도의 기록이 점점 더 귀해집니다. 코드는 다시 만들 수 있지만, 그때 왜 그렇게 하기로 했는지는 다시 만들어지지 않으니까요.
둘째, 기록은 셋팅으로 강제해야 쌓입니다. 훅 하나 걸어두는 10분짜리 셋팅이면, 이후로는 아무 노력 없이 기록이 쌓입니다. 사람의 성실함에 기대는 기록은 반드시 끊깁니다.
셋째, 기록의 가치는 다시 꺼낼 때 생기는데, 꺼내는 일도 이제 AI가 해줍니다. 쌓는 것도 자동, 찾는 것도 자동이라면, 남는 질문은 하나뿐입니다. 기록해 둘 것인가, 흘려보낼 것인가.
