Claude 3.5 Sonnet으로 만든 웹 기반 뉘르부르크링 레이싱 게임 — 커스텀 물리 엔진 + 합성 엔진 사운드
I made a web-based Nürburgring driving game with Fable 5 — custom physics + synthesized engine sound
핵심 요약
Claude 3.5 Sonnet을 활용해 물리 엔진과 사운드까지 구현한 웹 기반 뉘르부르크링 레이싱 게임 제작기.
- 개발 방식 — 단순 프롬프트가 아닌 단계별 계획과 검증 루프 활용
- 물리 엔진 — 실제 차량 데이터와 수식을 기반으로 한 정밀 튜닝
- 사운드 합성 — 실제 녹음 데이터와 스펙트로그램 비교를 통한 엔진음 구현
- 오픈 소스 — 깃허브 레포지토리를 통해 로직과 개발 로그 공개
뉘르부르크링에서 즐기는 브라우저 레이싱 게임
만든 이유: slowroads.io 같은 느낌이면서도 실제 서킷과 실제 차량을 기반으로 한, 레이싱 DNA가 살아있는 게임을 가볍게 즐기고 싶었음. 아케이드보다는 시뮬레이션 쪽에 가까워서 생각보다 좀 어려울 수 있는데, 키보드로 레이싱 게임 좀 해봤으면 무난할 거임.
코드 대부분은 Claude Fable 5가 짰고, 나는 튜닝이랑 조작감 잡는 데 집중했음. 시작할 때 첫 프롬프트로 스펙을 던진 게 아니라, 비전이랑 몇 가지 확실한 제약 사항을 먼저 줬음. 대충 "뉘르부르크링 레이싱 게임, 1인칭 시점, 물리 엔진 제대로 구현, 키보드 조작감 좋게. 일단 계획부터 제대로 짜고 깊게 생각해서 시작해"라고 했지. 먼저 전체 계획(트랙 데이터, 물리, 렌더링, 콕핏, 조작, HUD)을 짜게 시키고, 코드를 한 줄도 쓰기 전에 그 계획부터 검토했음. 그 뒤로는 "계속해"라거나 "조향이 반대인 것 같아", "시점 높이가 너무 낮아" 같은 식으로 짧게 피드백을 줬고, 그럼 얘가 알아서 고치고 헤드리스 테스트로 다시 확인하는 식으로 진행했음. 솔직히 말해서, 코딩보다 계획부터 세우는 단계가 훨씬 중요했음.
근데 이 게임이 그냥 프롬프트 한 번 던지고 끝나는 장난감 수준을 넘어서게 만든 건, Fable한테 측정 가능한 목표를 주고 스스로 검증하게 만든 거임. 효과 좋았던 패턴 몇 개 공유함:
- 물리 엔진: "현실적으로 만들어줘" 대신, 차마다 실제 0-100km/h 가속이랑 최고 속도를 주고 실제 물리 방정식을 역산해서 구현하게 시켰음(최고 속도는 종단 속도, 0-100은 트랙션 제한 vs 출력 제한 구간으로 계산). 그러고 나서 Playwright 헤드리스 테스트로 차를 직접 몰아보면서 측정하게 했지. 수치가 맞을 때까지 계속 반복함. "0-100 3.2초, 최고 속도 296km/h 맞춰. 방정식으로 유도하고 테스트 하네스로 측정해. 반복해"라고 하는 게 "GT3 RS 느낌 나게 해줘"라고 하는 것보다 훨씬 잘 먹힘.
- 사운드: 실제 온보드 녹음 파일을 가져와서 스펙트로그램을 뽑았음. 그리고 AI가 오프라인에서 합성한 소리랑 스펙트로그램을 비교하게 해서, 실제 엔진 곡선에 맞춰 파라미터를 튜닝하게 시켰음. 그냥 '느낌'이 아니라 측정값을 기반으로 A/B 테스트를 돌린 거지. 그러니까 엔진 소리가 양산형 머슬카 소리처럼 들리는 걸 막을 수 있었음.
- 큰 변경 사항 안전하게 관리하기: 차마다 튜닝 값을 따로 분리해서, 값을 설정 안 하면 아무것도 안 바뀌게 만들었음. 덕분에 차 한 대 튜닝한다고 다른 차들이 갑자기 고장 나는 일을 방지했지. 모델한테 코드 리팩토링 시킬 때 처음부터 이렇게 하라고 시키는 게 좋음.
결론: 요즘 다들 Fable로 프롬프트 한 번 던져서 게임 뚝딱 만들어내는데, 그것도 재밌긴 함. 근데 확실한 목표를 주고 검증할 방법까지 쥐여주면, 물리나 오디오 같은 지루하고 어려운 작업도 AI가 알아서 끈질기게 파고듦. 프롬프트 한 번으로 끝내는 거랑은 차원이 다름.



