한 시니어 개발자가 downtime.partridge.works에서 약 48시간 만에 완성도 높고 플레이 가능한 웹 게임을 출시했습니다. 팀도 없었고, 기존에 사용하던 엔진도 없었습니다. 이 빌드는 "한 번에 모두 생성하기" 방식이 아니라, 개발자와 함께 긴밀한 프롬프트-검토-반복 (prompt-review-iterate) 루프를 수행하는 Claude Opus 4.7에 의해 주도되었습니다. 우리가 이 워크플로우를 깊이 파고든 이유는 속도 때문이 아니라, 그 협업 패턴이 흥미롭기 때문입니다.

어느 정도 괜찮은 기술 스택만 있다면 주말 동안 작은 웹 게임을 출시할 수 있습니다. 2026년 초에 변화된 점은 병목 현상이 "이 코드를 작성할 수 있는가"에서 "내가 원하는 것을 충분히 명확하게 설명할 수 있는가"로 옮겨갔다는 것입니다. Opus 4.7의 1M 토큰 컨텍스트 윈도우 (context window)는 모델이 며칠간의 세션 동안 전체 설계 문서, 현재 코드베이스, 그리고 결정 사항 목록을 작업 메모리에 유지할 수 있음을 의미합니다. 이것이 바로 대부분의 1인 개발자들이 여전히 제대로 활용하지 못하고 있는 핵심 열쇠입니다.

2일간의 타임라인

첫째 날은 거의 전적으로 계획 수립과 핵심 게임 루프 (core game loop)에 할애되었습니다. 개발자는 장르, 플레이어가 처음 10초 동안 하는 일, 다시 돌아오게 만드는 요소 등을 담은 한 페이지 분량의 디자인 브리프 (design brief)를 작성하여 씨앗 (seed)으로서 Claude에 붙여넣었습니다. 거기서부터 워크플로우는 다음과 같았습니다: Claude에게 구현 계획을 제안하도록 요청하고, 과하게 설계되었다고 느껴지는 부분은 거부하며, 더 단순한 버전을 요청한 다음, 승인하고 실행하는 방식이었습니다.

코드 생성은 한 번에 하나의 관심사 (concern) 단위로 덩어리째 이루어졌습니다: 입력 처리, 충돌 (collision), 기본적인 적 스포너 (enemy spawner), 그리고 점수 루프 (scoring loop) 순서였습니다. 각 덩어리는 다음 프롬프트를 실행하기 전에 브라우저에서 테스트되었습니다. 첫째 날이 끝날 무렵, 프로토타입은 플레이는 가능했지만 외관은 투박한 상태였습니다.

둘째 날은 폴리싱 (polish) 단계였습니다. 파티클 효과 (particle effects), 화면 흔들림 (screen shake), 사운드 디자인, 기본적인 타이틀 화면, 그리고 난이도 곡선 (difficulty curve) 작업이 진행되었습니다. 개발자는 둘째 날이 반복적인 워크플로우의 효과가 가장 크게 나타난 시점이라고 보고했습니다. "다른 주스 효과 (juice effect)를 시도해 보자"라는 결정에 따르는 비용이 프롬프트 왕복 시간 기준으로 약 2분 정도로 줄어들었기 때문에, 직접 코딩했다면 절대 시도하지 못했을 수십 가지의 변형을 시도할 수 있었습니다.

총 빌드 시간은 실제 시간(wall-clock hours) 기준으로 약 48시간이었지만, 실제 집중해서 작업한 시간은 12~14시간에 가까웠습니다. 나머지는 생각하고, 실제 브라우저에서 빌드를 테스트하고, 아이디어가 정리될 수 있도록 잠시 자리를 비우는 시간이었습니다. AI 지원 개발(AI-assisted development)이 한 걸음 물러나 생각할 필요성을 없애주는 것은 아닙니다.

실전에서의 반복적인 계획-피드백 프롬프팅 (Iterative plan-feedback prompting)

이 개발자가 사용한 방식 — 그리고 여러분이 그대로 따라 할 수 있는 방식 — 은 세 가지 단계로 이루어집니다.

1. 매번 코드를 짜기 전에 계획을 세우세요. "파워업 시스템이 있는 스네이크 게임을 만들어줘"라고 말하는 대신, Claude에게 먼저 계획을 작성하도록 요청하십시오. 어떤 파일들이 존재할 것인지, 각 파일에는 어떤 함수가 들어갈 것인지, 어떤 데이터 구조(data structures)가 상태(state)를 보유할 것인지, 그리고 실패 모드(failure modes)는 무엇인지 등을 정의합니다. 계획을 읽어보고, 어색한 부분이 있다면 수정을 요구하며, 계획이 완벽해진 후에야 코드를 요청하십시오. 느리게 들릴 수도 있습니다. 하지만 400줄짜리 원샷 생성(one-shot generation) 결과물의 버그를 잡는 것보다는 훨씬 더 극적으로 빠릅니다.

2. 차이점(diff)의 범위를 제한하세요. "플레이어가 코인을 얻을 때 파티클 효과를 추가해줘"는 나쁜 프롬프트입니다. Claude는 파티클 코드가 어디에 위치해야 하는지, 혹은 여러분이 이미 파티클 시스템을 가지고 있는지 알지 못하기 때문입니다. "플레이어가 코인을 얻을 때 파티클 효과를 추가해줘. src/effects/particles.ts와 src/entities/coin.ts에 있는 코인 획득 핸들러(coin pickup handler)만 수정해. 새로운 파일을 만들지 마. 기존의 이미터(emitter) 패턴을 따라줘"가 좋은 프롬프트입니다. _어떤 파일이 변경될 수 있는지_에 대한 구체성은 가장 높은 레버리지(leverage)를 제공하는 습관입니다.

3. 프롬프트 사이사이에 실제 브라우저에서 테스트하세요. 이것은 대부분의 1인 개발자들이 건너뛰는 부분입니다. 타입 체크(Type-checks)를 통과하고 코드가 잘 읽히면, 차이점(diff)을 수락하고 다음으로 넘어갑니다. 그러다 둘째 날이 되어서야 충돌 감지(collision detection)가 6시간 동안 조용히 잘못 작동하고 있었다는 사실을 깨닫게 됩니다. localhost를 여세요. 이곳저곳 클릭해 보세요. 여러분이 본 것과 요청한 것을 대조(diff)해 보세요. 모델은 빠른 협업자(collaborator)이지, 신중한 협업자가 아닙니다.

개발자는 또한 덜 명확한 습관을 언급했습니다. 바로 리포지토리(repo)에 DECISIONS.md 파일을 유지하고, 이 파일을 새로운 Claude 세션마다 붙여넣는 것입니다. 이 파일은 초기 선택의 배경(