프롬프트 한 번으로 만든 게임 TIDEWRIGHT, 재현 조건 분석

게임 TIDEWRIGHT는 Claude Opus 5가 한 세션에서 만든 GPU 기반 3D 모래성 시뮬레이터입니다. 산출물은 15개 파일 7,145줄입니다. 엔진과 라이브러리 없이 의존성 0개로 돌아가고, 세션은 벽시계로 7시간 47분이 걸렸습니다.

프롬프트 한 번이라는 말은 최초 요청이 하나였다는 뜻이고, 그 요청 뒤에는 같은 세션에서 어시스턴트 턴 2,596번과 도구 호출 1,680번이 붙었습니다. 이 표현이 실제로 가리키는 작업량은 이 두 수치에 담겨 있습니다.

한 세션 7시간 47분이 남긴 것 — 15개 파일 7,145줄, 의존성 0개

저장소에서 먼저 눈에 걸리는 것은 코드보다 없는 것의 목록입니다. 엔진, 라이브러리, 에셋, 빌드 단계가 전부 없습니다. index.html을 열면 file:// 경로에서도 바로 실행되고, 저장 기능을 쓸 때만 node server.js로 로컬 서버를 띄웁니다.

동작 조건이 없지는 않습니다. WebGL2에서 부동소수점 렌더 타깃 확장 2개를 지원해야 하고, Safari는 16 이상이어야 합니다. 성능은 RTX 4070 Laptop의 High 프리셋 기준으로 프레임당 5~6ms가 나옵니다.

코드가 한 덩어리인 것도 아닙니다. 시뮬레이션, 렌더러, 후처리, 사운드가 js 디렉터리 아래로 나뉘어 있고, 조정할 설계 값은 content.js 한 곳에 모여 있습니다. MIT 라이선스로 공개돼 있어 코드를 그대로 뜯어 봐도 됩니다.

브라우저에서 TIDEWRIGHT 실행해 보기

프롬프트 한 번의 실제 조건: 최초 요청 하나에 같은 세션 후속 작업이 붙는다

프롬프트 한 번은 응답 한 번이라는 뜻이 아닙니다. README에 인용된 최초 요청 하나가 세션의 출발점이고, 거기에 벽시계 7시간 47분, 실제 작업 6시간 45분의 후속 작업이 같은 세션 안에서 붙었습니다.

원문은 이렇습니다.

Create me a fully playable release-ready game. On GPU. Game about sandcastle simulator, where I can build things with sand and etc. I need it in 3D and not a voxel game.

GPU 위에서 도는 3D 모래성 시뮬레이터라는 목표와 복셀 게임 금지라는 제약만 정하고, 구현 방식은 전부 비워 둔 요청입니다.

세션 기록이 보여 주는 작업량은 어시스턴트 턴 2,596번, 도구 호출 1,680번입니다. 최초 요청이 정한 목표를 같은 세션이 계속 파고들어 7,145줄까지 끌고 간 결과입니다.

9억 4,320만 토큰 중 95%가 캐시 읽기, 생성 토큰은 261만이라는 뜻

총 토큰 9억 4,320만이라는 숫자에서 모델이 새로 써낸 몫은 얼마 안 됩니다. 이 가운데 9억 80만, 전체의 95%가 프롬프트 캐시 읽기입니다. 실제 생성 토큰은 261만으로, 총량과는 350배 넘게 벌어집니다.

저장소가 공개한 세션 수치입니다. 재현 비용을 가늠할 때 봐야 할 값이 생성 토큰이 아니라 캐시 읽기라는 점이 이 표에서 드러납니다.

항목	값
모델	Claude Opus 5
벽시계 시간	7시간 47분
실제 작업 시간	6시간 45분
어시스턴트 턴	2,596
도구 호출	1,680
생성 토큰	261만
프롬프트 캐시 읽기	9억 80만
총 토큰	9억 4,320만
코드	15개 파일 7,145줄

캐시 읽기가 이렇게 커진 이유는 세션을 유지하는 방식에 있습니다. 긴 단일 세션은 턴마다 코드베이스 전체를 다시 읽습니다. 코드가 자랄수록 턴 하나가 읽는 양도 같이 자라고, 그 턴이 2,596번 쌓이는 동안 같은 코드를 반복해서 읽은 비용이 총 토큰의 대부분을 차지합니다. 이런 긴 세션 중심의 작업 방식은 Claude Code 워크플로 문서에 정리돼 있습니다.

생성 토큰 261만이 전부 최종 코드로 남은 것도 아닙니다. 세션 동안 쓰고 고친 코드와 도구를 부르는 명령이 모두 이 안에 들어 있습니다. 결과물 7,145줄만 보면 생성이 일을 다 한 것처럼 보이지만, 세션이 소비한 토큰의 95%는 이미 쓴 코드를 다시 읽는 데 들어갔습니다.

신규·의존성 0개·단일 산출물이라는 유리한 조건을 걷어내면

TIDEWRIGHT의 세션에는 유리한 조건 세 개가 겹쳐 있습니다. 기존 코드가 없는 신규 프로젝트라는 점, 의존성 0개라 버전이 다른 라이브러리나 외부 API에 맞출 일이 없다는 점, 브라우저에서 바로 열리는 단일 산출물이라는 점입니다. 셋 다 모델이 세션 안에서 프로젝트의 전체 상태를 통제하게 해 주는 조건입니다.

실무의 작업은 대부분 반대편에 있습니다. EKS에서 Vault 파드와 PVC를 지운 뒤 Raft 클러스터를 복구하는 일은 이미 벌어진 장애 상태가 조건을 정하고, 만료된 쿠버네티스 인증서를 kubeadm으로 갱신하는 일은 기존 클러스터의 설정을 벗어날 수 없습니다. React Router의 중첩 라우팅처럼 라이브러리 위에서 짜는 코드는 그 API의 규칙이 형태를 정합니다. 이런 자리에서 모델의 첫 일은 이미 있는 상태를 읽고 거기에 맞추는 것입니다.

지금 판단은 이렇습니다. 이 기록은 모델이 조건까지 통제할 수 있는 자리에서 나오는 상한을 보여 준 사례이지, 보통 프로젝트의 기대치가 아닙니다. 프로토타입이나 데모처럼 신규로 시작해 의존성을 줄일 수 있는 작업이라면 같은 방식이 통할 여지가 크고, 기존 코드베이스 위의 작업이라면 이 수치를 그대로 가져올 근거가 아직 없습니다.

관전 포인트는 하나로 좁혀집니다. 기존 코드베이스와 외부 API 제약이 붙은 프로젝트에서도 한 세션에 7천 줄 규모가 재현되는지에 따라 이 사례를 일반화할 수 있는지가 정해집니다. 그런 사례가 나오면 결론은 상한에서 기대치로 바뀌고, 나오기 전까지 이 수치는 신규·의존성 0개·단일 산출물이라는 조건 안의 기록으로 남습니다.

출처: tidewright 저장소, 브라우저 데모, Claude Code 워크플로 문서