「Claude Code 사용하시나요?」— 텍스트 파일로 AI를 관리하던 내가 결국 시스템을 만들기까지

운명의 2026년 2월, 직장 동료의 한마디로 3년 동안 잠들어 있던 개발 인생이 다시 눈을 떴다.

커뮤니티에 어두웠던 나에게 동료가 문득 던진 한마디.

「Claude Code 사용하시나요?」

어쩐지 Web에서만 사용해 왔던 AI가, 내 PC 안으로 들어온다는 이야기. 반신반의하며 사용해 본 결과는 충격적이었다. 3년 동안 방치했던 개발 인생이 다시 돌아가기 시작했기 때문이다. 그 연대기를 지금부터 시작해 보려 한다.

약 3년 전, 나는 아이디어만 품고 있던 포커 게임을 ChatGPT와 만들고 있었다. 당시 버전은 3.5 Prometheus였다고 기억한다. 재미는 있었지만 개발 속도는 느렸고, 「개발에 있어서는 누구에게도 뒤지지 않는다」라고 불리던 Claude로 갈아타서 계속해 보았지만 — Web에서는 다 전달할 수 없는 한계의 벽에 부딪혀 결국 프로젝트를 묵혀두고 말았다.

그러던 중 동료로부터 「Claude Code」 이야기를 들었다. AI가 내 안으로 들어오면서 개발 속도가 눈에 띄게 변했다.

그리고 초기, 나는 모든 것을 텍스트로 관리하고 있었다.

마지막 Axxx 추가 번호
마지막 B001 버그 번호
c 클라이언트 상정
...

초라해 보일지도 모르지만, 이것도 나름의 관리법이었다.

Claude의 사용량 상한은 금방 찾아왔다. 대체 환경을 찾던 중에 GitHub Copilot을 알게 되었다. 흥미롭게도 *프리미엄 요청 (Premium Request)*으로 각종 모델을 호출하는 방식이었다. Pro 플랜으로 300회를 확보했다.

Claude Pro $20 + Copilot Pro $10

300회도 금방 바닥났다. 무료 모델(당시 GPT-4.1, 5-mini)로 버티는 방법을 고민하던 중, 이전에 무심코 보았던 광경이 떠올랐다. AI가 md 파일을 만들고 있던 모습. 사소한 것이라고 생각했던 그것이 답이 되었다.

「아, 설계로서 남겨두면 되는 거구나.」

Claude와 Copilot이 살아있는 동안, 무료 모델로도 양산할 수 있는 설계서 공장을 만들기 시작했다.

# Control.gd 함수 맵 (지시서 작성자 참조용)
**목적**: 「어떤 함수가 있고, 무엇을 하며, 어디서 호출되는지」를 빠르게 확인
**대상 파일**: client/.../Control/Control.gd
...

당연하게도 무료 모델이 내뱉는 설계서에는 한계가 있었고, 결국 Copilot의 **Pro+**로 갈아탔다.

Claude Pro $20 + Copilot Pro+ $40

아... 쾌적하다. Pro+는 1500회. 설계는 Claude에게 맡기고, 작업은 Copilot으로. 효율이 단번에 올라갔다.

워커(Worker)가 늘어나자 텍스트 관리는 감당할 수 없게 되었다. 그래서 도입한 것이 「인덱스 (Index)」. 그리고 직접 관리하는 대신 워커에게 이렇게 지시했다.

「기표(記票)해라.」

## 현재 기표 항목
| ID | 항목 | 상태 | 메모 |
|----|------|------|------|

나는 지시만 하면 되게 되었다. 더 이상 직접 관리하지 않고, 워커들이 스스로 관리하도록. 매우 편해졌다.

「Claude Code」를 알고 나서, 불과 1~2개월 만에 텍스트 관리 → 인덱스 위임까지 도달했다. 그렇게 게임을 완성시키고, AI 팀과 홈페이지까지 만들어 5월에 론칭했다. (👉 horriblegames.net — 결코 수상한 사이트가 아니라, 포커 게임 데모입니다.)

여기서 깨달았다. 인덱스 파일이 여기저기 산재해 있다는 것, 그리고 더 큰 문제 — AI는 일관되지 않다는 것. 매번 규칙을 전달해도, 전달해도, 제멋대로 작성한다.

그래서 만든 것이 [인덱스 채번기]. 명령어를 등록하면 자동으로 인덱스를 채워주는 프로그램. FlowGate가 태어나기 전까지는 이것을 사용했다.

하지만 채번기도 매번 프리셋을 관리해야 했고, 제대로 등록하지 않으면 에러가 나거나 AI가 제대로 사용하지 못하는 일이 다발했다. 그래서 — 차라리 시스템화하기로 했다.

그렇게 FlowGate가 탄생했다.

FlowGate를 사용한다고 해서 AI가 거짓말을 하지 않게 되는 것은 아니다. 다만 — 몇 번 거짓말을 했는지 증거로 남는다.

포커 게임을 만들면서 깨달은 점. 백엔드 (Backend)는 데이터의 흐름만 파악하면 어느 정도 해낼 수 있는데, 프론트엔드(Front-end)와 화면의 버그는 정말 고칠 수가 없다.

"이게 아니라고, 아 진짜 짜증 나네."

이 말을 몇 번이나 했는지 기억도 나지 않는다. 왜일까? 증거가 없기 때문이다. 말했다는 기억만 남을 뿐, AI가 무엇을 어떻게 고치는 바람에 진행이 안 되었는지는 사라진다. "잘 안되니까 우회해서 이렇게 해"라고 지시했던 기억만 남는다.

FlowGate가 완성되었다고 해서 고치지 못했던 버그가 저절로 고쳐지는 것은 아니다. 다만 흥미로운 두 가지가 생겨났다.

첫째, 증거가 남는다.

대화로 매번 확인할 수도 있지만, 어제 했던 일을 오늘 잊어버리는 것처럼 무언가 남겨두지 않으면 어제의 일을 알 수 없다. 하지만 FlowGate로 남긴 증거는 그대로 유지된다. 그래서 차이가 생겼다.

• 이전: "이건 해결하고 나서 진행해야 해."
• 현재: "오늘 해결하지 못해도, 내일 해결하면 돼."

FlowGate의 액션 바 (Action Bar) SSE 버그를 잡는 데 3일이 걸렸다. 이전 같았으면 어딘가 파일로 남겨두지 않으면 작업을 이어갈 수 없었겠지만, 지금은 그저 **"여기서 끊을까"**를 결정할 수 있게 되었다.

둘째, 몇 번 리젝트 (Reject) 했는지 보인다.

그 SSE 버그는 — 조사 11회, 작업 13회의 리젝트. 이전에는 채팅창에서 화만 냈지만, 지금은 내가 몇 번 화를 냈는지 셀 수 있다...는 건 농담이고 😅, 언제 같은 방법을 그만두고 다른 방법으로 전환할지를 명시적으로 판단할 수 있게 되었다는 의미다.

대개 같은 방법으로 23번 안 되면 다른 방법으로, 46번 더 안 되면 또 다른 방법으로... SSE 버그도 그 횟수 중에 우연히 걸려들었지만, 조건 분기 (Conditional Branching) 버그 + 배포 (Deploy)의 합작이었다고 기억한다. 어쨌든, 이 작업을 몇 번 시도했는지를 직접 셀 수 있게 되었다는 것이다.

FlowGate는 AI의 거짓말을 막아주지는 않는다. 대신:

• 증거가 남는다 → 작업을 미루더라도 이어서 할 수 있다.
• 리젝트 횟수가 카운트된다 → 언제 방법을 바꿀지 판단할 수 있다.
• 그리고... 내가 몇 번 짜증을 냈는지도 셀 수 있게 되었다.

텍스트 파일 한 장에서 시작해 인덱스 (Index)로, 번호 매기는 기계로, 마침내 시스템까지. *"AI가 다 했다"*와 "실제로 구현되었다" 사이의 간극을 메우려 했던 4개월간의 기록이다.

👉 FlowGate: github.com/horrible-gh/FlowGate