만약 오늘날 2D 플랫폼의 기본 문법이 여전히 「손맛은 파라미터 조정, 모멘텀은 Rigidbody2D, 충돌은 CharacterController에 맡기고, 글에는 소닉 같아질 때까지 오래 조율했다고 쓴다」라면, Trent Brew(u/trentbrew)가 2026년 9월 21일 Sonic Retro의 《Sonic Physics Guide》를 오프라인 Markdown 저장소로 묶어 r/gamedev에 던진 그 순간은, 그 대본을 공개적으로 뒤집는 행위에 가깝다. 고전 Mega Drive 《소닉》의 손맛은 아트 디렉션상의 「감각」이 아니었다. 프레임마다 대조할 수 있는 이산 시뮬레이션이었다.
그 문장은 향수 선언처럼 들릴 수 있다. 무게를 주는 것은 저장소에 못 박힌 사양표다——1픽셀=256서브픽셀, 각도는 0–255의 16진 링, 여섯 센서 발(A/B 지면, C/D 천장, E/F 벽)이 네 가지 충돌 모드로 루프에 맞춰 회전한다는 것, 지면 속도가 약 2.5픽셀/프레임 아래로 떨어지면 가파른 경사에서 미끄러진다는 것, 프레임 순서가 Player → Objects → Collision → Camera → V-INT로 적혀 있다는 것. 숫자가 수사를 눌러 고정한 뒤에야 「손맛」은 처음으로 감사 가능하고, 재현 가능하며, 인디 팀에 시스템으로 넘길 수 있는 것이 된다.
이 글을 관통하는 이미지는 루프 위의 그 여섯 발이다. 그것들은 캐릭터 그림의 장식이 아니다. 모멘텀 세계 전체의 계측기다. 어느 16×16 솔리드 블록을 발이 밟는지, 어떤 각도 바이트를 읽는지, Floor / Right Wall / Ceiling / Left Wall 중 어느 모드에서 프로브가 다시 배치되는지——그것이 그린힐 안쪽 곡선에 붙어 질주하는지, 「겉보기엔 비슷한데 계산은 표류하는」 방식으로 벽에서 떨어지는지를 결정한다.
1. 기본 논리: 손맛은 분위기, 모멘텀은 엔진 보간
업계 기본 논리는 깔끔하다. 그래서 게으르기도 하다.
2D 플랫폼을 만들 때 팀은 익숙한 메뉴를 연다. 강체에 중력과 마찰을 주고, 점프 충격을 「기분 좋을 때까지」 맞추고, 캡슐이나 상자로 땅을 치고, 연속 충돌 감지로 벽 뚫림을 막는다. Unity의 CharacterController / Rigidbody2D, Godot의 CharacterBody2D, 수많은 「플랫폼 컨트롤러」 에셋은 「설 수 있다·점프할 수 있다·틈에 안 낀다」 세 가지를 자동화한다. 플레이어도 같은 어휘로 모멘텀 플랫폼을 읽게 됐다——「손맛 좋다」「소닉 같다」「관성이 조금 부족하다」. 이 암묵적 합의가 「손맛」을 용서받을 수 있는 분위기 단어로 만든다. 전문적으로 들리지만 거의 재현할 수 없다.
고전 Genesis 《소닉》은 그 문법이 가장 삼키기 어려운 작품 중 하나다. 360° 루프, 경사 가속, 벽·천장 밀착, 고속에서도 벽돌 면에 붙으며 클리핑하지 않는 것. 그것은 범용 물리 엔진의 가변 타임스텝이 아니라, NTSC 60Hz에서 프레임마다 한 번 하는 고정소수점 가감을 겨냥했다. 그 체험을 「마찰을 며칠 만지작거리며 감각을 믿는다」 작업 흐름에 밀어 넣으면, 업계 직관은 거의 자동으로 「분위기 조율」로 향한다.
Trent의 공개 저장소는 그 지름길을 거부한다. README는 솔직하다. 이것은 Sonic Retro 커뮤니티가 유지하는 《Sonic Physics Guide》의 비공식 파생 재편——위키 마크업을 Markdown으로 바꾸고, 도식과 교차 링크를 로컬화해 오프라인 열람과 구현을 가능하게 한 것이다. 표현에 주의하라. 보호되는 것은 특정 팬게임의 브랜드 연상이 아니라, 「손맛이 여전히 정확히 기술될 수 있는가」다. 기술이 정확해지면 분위기 단어는 숨을 곳을 잃는다.
여기서 기본 논리와 제작 윤리가 갈라진다. 분위기로서의 손맛은 묻는다——마찰을 조금 더 틀면 가까워질까. 이산 시뮬레이션은 묻는다——가속·감속·마찰·최고속·점프 초속·중력·경사 계수는 각각 몇 서브픽셀인가, 충돌 프로브는 위치 갱신 전인가 후인가, 모드 전환 시 센서 좌표는 어떻게 회전하는가.
2. 대본을 부수다: 「조율」에서 여섯 센서 상태기계로
저장소와 원 가이드에서 가장 날카로운 장면은 향수 스크린샷이 아니라, 작업 일지 같은 센서 표다. 플레이어는 일반 오브젝트보다 더 많은 프로브 세트를 갖는다——A·B는 지면, C·D는 천장, E·F는 벽 밀기. 흰 점이 상대 앵커를 표시하고, 각 쌍의 첫 센서는 방향에 따라 X를 반전한다. 평지에서는 천장 프로브가 휴면하고, 지면 각이 루프에 들어가면 네 모드로 오프셋 전체가 다시 쓰인다. Floor(약 315°–45°), Right Wall(46°–134°), Ceiling(135°–225°), Left Wall(226°–314°). Floor 모드만 영원히 쓰면 게임이 평범한 플랫폼으로 퇴화한다고, 가이드 스스로 대조 GIF로 못을 박는다.
장면은 더 구체적으로 복원할 수 있다. 솔리드 블록은 높이 마스크와 각도 바이트를 갖고, 두 지면 발이 벽돌 면까지의 거리를 재며, 가까운 쪽이 이기고 동점이면 A 우선. 거리는 캐릭터를 땅에서 밀어 내고, 이긴 블록의 지면 각을 기록한다. 착지 중 벽 푸시는 위치 갱신 *전에* 일어난다——현재 X/Y 속도가 프로브 좌표에 더해지고, 맞으면 속도를 벽 밖으로 밀며 지면 속도를 0으로 만든다. 공중에서는 프로브가 지면 각에 맞춰 회전하지 않고, 공중 속도 사분면에 따라 네다섯 개가 활성화된다. 점프 전에는 천장을 먼저 묻는다. 최근 거리가 6픽셀 미만이면 기점프 자체를 포기한다.
여기서 핵심 메커니즘이 드러난다. 이것은 「충돌이 있다」는 모호함이 아니라, 여섯 프로브 레이캐스트 오토마톤이며, 모드 히스테리시스와 실행 순서의 비대칭을 동반한다. 구현 가이드는 치명적 함정을 한 페이지에 늘어놓는다——가변 deltaTime으로 속도를 곱하면 상수표가 깨지고, 고속에서 잘못된 프로브는 벽을 뚫고, 오목면 모드 전환에 지연이 없으면 커브에서 경련한다. 업계 기본은 「물리」를 범용 솔버에 외주한다. Genesis 《소닉》은 물리를 하나의 의사결정 사슬에 다시 용접한다——당신이 바꾸는 매 프레임 덧셈은, 같은 루프 질주에 여전히 봉사하는지 되돌아 대조되어야 한다.
3. 숫자가 수사를 누른다: 서브픽셀, 상수표, 그리고 「2.5 미만이면 미끄러진다」
사양표가 없으면 이산 시뮬레이션 서사는 공허로 미끄러진다. Sonic Retro 가이드와 Trent README의 빠른 참조표는 수사를 검증 가능한 바닥에 못 박는다.
원점은 왼쪽 위. 충돌 테스트는 서브픽셀을 버리고 정수 픽셀만 인정한다. 각도 0은 오른쪽, 64는 아래, 128은 왼쪽, 192는 위(Genesis 16진, 시계 방향). Sonic 1/2/3&K의 상용 상수는 부품 목록처럼 적힌다. `acc` 0x000C(12서브픽셀, 약 0.046875 px/frame), `dec` 0x0080(0.5 px/frame), `frc`는 관성 시 가속과 동일, `top` 0x0600(평지 6.0 px/frame), `jmp` 0x0680(6.5 px/frame; Knuckles는 0x0600), `grv` 0x0038(약 0.21875 px/frame), `slp` 0x0020(0.125 px/frame). 수중은 별표로 절반 또는 더 낮다.
더 날카로운 숫자는 경사 물리에서 온다. 지면 각이 미끄러짐 구간에 있고 지면 속도 절댓값이 2.5(2픽셀과 128서브픽셀) 미만이면 플레이어는 미끄러진다——착지 해제, 지면 속도 0(Sonic 3부터는 조건부 미끄러짐), 방향 입력을 약 30프레임 잠금. 이로써 천장을 천천히 걷거나 가파른 경사를 영원히 기어 오를 수 없다. 메인 루프 순서 또한 낭만적이지 않다. 플레이어 제어와 자신의 충돌이 엇갈리고, 오브젝트 루틴, 오브젝트–플레이어 충돌, 카메라, 그리고 V-INT. 고속 벽 클립이 막기 어려운 것은 종종 「상자가 작아서」가 아니라, 프로브가 프레임의 잘못된 반쪽에 놓였기 때문이다.
이 숫자들의 서사력은 레트로 취향이 아니라, 위장하기를 거부하는 데 있다. 「손맛이 맞을 때까지 조율하면 된다」는 재검증 불가능한 권위를 만들지 않고, 루프 장면을 약속 밖으로 빼지도 않는다. 루프야말로 모드 전환·경사 계수·센서 회전의 비용이 겹치는 장면이다. 그곳에 과녁을 못 박는 것은, 지켜야 할 체험이 가장 시끄럽고 가장 빠른 몇 초에 ���어난다고 공개적으로 인정하는 것과 같다.
4. 환류: 오프라인 문서가 강제하는 구현 가능성이 인디 파이프라인으로 돌아온다
이야기에서 가장 흥미로운 결말은 또 하나의 팬 위키가 아니라, 오늘날 도구 체인으로의 역류다.
Trent가 한 일은 우직해 보인다. 스크레이프, 재편, 이미지와 교차 링크 로컬화, 구현 장과 AI 에이전트 프롬프트 블루프린트 첨부, 그리고 텍스트가 Sonic Retro에서 왔으며 도식은 별도 조항을 가질 수 있고 스프라이트 저작권은 여전히 Sega에 있음을 GFDL에 맞춰 명시하는 것. 우직한 이유는 「튜토리얼 영상 두 편」으로 대체할 수 없기 때문이다. 비싼 이유는 엔진 기본 부품이 아니라 진짜 독서와 대조를 소비하기 때문이다. 저장소는 2026-09-21에 만들어졌고(r/gamedev 게시와 같은 날), 한때 info.sonicretro.org에 흩어져 있던 권위 페이지를 clone하고 오프라인으로 열고 파일 순으로 구현할 수 있는 문서 세트로 바꿨다. images/에는 백여 장의 기술 도식과 GIF——센서, 높이 마스크, 모드 전환, 미끄러짐 구간——이 통째로 착륙해, 「감각」이 처음으로 스크린샷으로 감사할 수 있는 자리에 선다.
이것은 인디 개발에서 「손맛 참고」의 위치를 거의 다시 쓴다. 모멘텀 플랫폼은 종종 미술과 조율의 하류였다——먼저 스테이지를 만들고, 마찰을 「조금 소닉」까지 튼다. Trent는 이야기를 비트다. 고전 손맛의 경계가 스트레스 벤치가 되어, 표현층 전에 결정론적 시스템을 쓰게 한다. 최적화는 한 방향 플러그인 추가가 아니라, 엔진을 가로지르는 공통 언어 학습이 된다——GameMaker도 Godot도 자체 C++도 같은 상수표를 읽는다.
인디와 소규모 팀에게 이 환류는 특히 아프다. 동시에 특히 유용하다. 합법적인 소닉 복제를 낼 필요는 없다. 그러나 누구나 「이미 충분하다」 목록을 갖고 있다——어떤 Rigidbody 마찰, 어떤 `* deltaTime`, 한 번도 적히지 않은 충돌 순서, 목표 손맛에서 먼 「느낌 좋다」 댓글. Steam의 모멘텀 작품과 게임잼의 루프 스테이지는 그 목록의 오만을 처음 보여주는 곳이 되기 쉽다. 공개 저장소는 인정한다. 현대 엔진 위의 「대충 비슷하다」는 고정소수점 서브픽셀과 여섯 프로브 앞에서는 종종 환상에 불과하다.
맺음: 독립과 제작은 「감사 가능한 손맛」 안에서 재정의된다
이 가이드를 2026년 제작 현장으로 되돌릴 때, 그것이 진짜로 치는 것은 「Unity로는 소닉을 못 한다」는 빈말이 아니라, 더 은밀한 제작의 게으름이다——플랫폼 차이는 범용 강체로 평탄해질 수 있다고 믿고, 손맛은 출시 두 주 전의 조율이라고 믿고, 플레이어가 「조금 비슷하다」로 「더 이상 같은 모멘텀 세계가 아님」을 용서할 것이라고 믿는 것.
Sonic Retro 기여자와 Trent의 오프라인 재편이 보여주는 반례는 우직하고 비싸다. 서브픽셀과 16진 각, 여섯 센서와 네 모드, 2.5 px/frame 미끄러짐 임계값, 명시된 프레임 순서, GFDL 귀속, 백여 장의 원도. 우직한 이유는 감각을 상태기계로 쓰라고 요구하기 때문이다. 비싼 이유는 플러그인 상점 별점 다섯이 아니라 진짜 구현 결정을 소비하기 때문이다.
이렇게 「독립」과 「제작」은 여기서 재정의될 수 있다. 독립은 고전 거부와 등호일 필요가 없고, 자원이 빠듯해도 「모멘텀의 최소 불가파괴 집합은 무엇인가」를 계속 묻는 것일 수 있다. 제작은 기능 쌓기와 등호일 필요가 없고, 그 최소 집합을 위해 충돌을 다시 쓰는 의지——설령 1991년 어셈블리와 대조하는 것처럼 보여도——일 수 있다.
실행 가능한 지침은 짧지만, 충분히 매섭고 정직하다.
- 먼저 「Sonic 감」 목록을 쓴다. 어떤 세 규칙이 변형되면 루프가 죽는가(예: 고정 60Hz 스텝, 착지 전후 프로브 순서, 경사 미끄러짐 임계값). 구현 시 그것들에 거부권을 준다.
- 목표 엔진에서 대조 실험을 한다——「범용 강체를 끄고, 운동학 바디+직접 쓴 프로브만 남긴다」. 물리 엔진을 영원히 버리기 위해서가 아니라, 보간이 어떤 프레임을 훔치는지 보기 위해서다.
- 이동 구현을 바꿀 때 센서 기하·모드 전환·메인 루프 순서를 함께 회귀한다. 속도 상수표와 충돌은 같은 커밋에서 합불을 낸다.
- 가이드가 강제하는 더 깨끗한 쓰기(고정소수점 서브픽셀, hex 각, 명시 프레임 순서)를 후보로 삼아, 주력 플랫폼 컨트롤러로 환류할 수 있는지 평가한다. 「레트로 전용 쓰레기 코드」로 두지 않는다.
저장소는 거기 있다. github.com/trentbrew/sonic-physics-guide. 권위 있는 원문은 여전히 info.sonicretro.org/Sonic_Physics_Guide. 다음에 마찰 슬라이더를 틀기 전에, 제작 현장은 감사 기준을 이미 말해 버렸다. 질문은 「닮았는가」가 아니다. 「프레임마다 재현할 수 있는, 그 모멘텀 그대로인가」다.
소광
출처와 더 읽기
GitHub: trentbrew/sonic-physics-guide (2026-09-21 생성)
Sonic Retro 원가이드: Sonic Physics Guide (GFDL)
- 저장소 내: `docs/06-slope-collision.md`, `docs/09-slope-physics.md`, `docs/12-main-game-loop.md`, `docs/23-implementation-guide.md`