트럭 짐칸에 짐을 직접 쌓은 뒤 전진·후진·앞바퀴 조향으로 목적지까지 운전한다. 짐을 떨어뜨리지 않고 도달하면 승리하는 물리 기반 적재·주행 퍼즐이다.
두 시점을 오간다.
- 적재: 1인칭. 플레이어가 걸어다니며 짐을 하나씩 들어 짐칸에 쌓는다.
- 주행: 폴리브릿지 시뮬레이션 화면과 같은 자유 시점. 기본은 대각선 위에서 내려다보는 쿼터뷰이고, 마우스로 돌려 탑뷰나 사이드뷰에서 짐 상태를 확인하며 트럭을 직접 운전한다.
기획서: docs/game-design.md
- Unity
6000.5.4f1(Built-in 렌더 파이프라인, 레거시 Input) - 플랫폼: PC (itch.io / Steam)
- 팀: 3명, 전원 Unity 초급
Unity Hub에서 저장소 루트를 프로젝트로 추가하고 위 버전으로 연다. 다른 Editor 버전으로 업그레이드하지 않는다.
- Unity Hub에서 저장소 루트를 Unity
6000.5.4f1로 연다. Assets/Scenes/MainMenu.unity씬을 연다.- Play 버튼을 누른다.
Editor에서는 다른 씬을 열어 둔 상태에서도 Play하면 기본적으로 MainMenu부터 시작한다.
현재 씬을 바로 테스트하려면 CargoStack > Play Mode > 메인 메뉴부터 시작을 끈다.
적재 단계 (1인칭)
| 입력 | 동작 |
|---|---|
WASD |
이동 |
| 마우스 | 시점 |
Space |
점프 (짐칸에 올라갈 때) |
E (짧게) |
화물 집기 / 놓기, 조준한 짐칸 뒷문 열기 / 닫기 |
E (0.25초 이상 누른 뒤 놓기) |
화물을 카메라 정면으로 던지기 (1초에 최대 충전) |
Q (누름 유지) |
들고 있는 화물 미리보기를 초당 90도 반시계 회전 |
R |
로프 매듭 짓기 (첫 번째로 시작점, 두 번째로 끝점) |
X |
짓던 매듭 취소 / 조준한 로프 걷어 내기 |
Enter |
적재 완료, 출발 |
Tab |
커서 잠금 해제 |
Esc |
스테이지 선택으로 돌아가기 |
주행 단계 (자유 시점)
| 입력 | 동작 |
|---|---|
W / ↑ |
전진 (후진 중에는 먼저 제동) |
S / ↓ |
후진 (전진 중에는 먼저 제동) |
A, D / ←, → |
앞바퀴 좌우 조향 |
| 좌클릭 드래그 | 시점 회전 (쿼터뷰 ↔ 탑뷰 ↔ 사이드뷰) |
| 마우스 휠 | 확대 / 축소 |
Backspace |
재시작 |
Esc |
스테이지 선택으로 돌아가기 |
화물을 들면 조준한 수평면에 반투명 미리보기가 나타난다. 그 자리에 그대로 놓인다.
짐칸 뒷문은 빈손으로 조준하고 E를 누르면 열고 닫을 수 있으며, 출발할 때 자동으로 닫힌다.
R을 누르면 조준한 자리에 매듭이 하나 생기고, 걸어가서 다시 R을 누르면 그 두 점 사이에 로프가 걸린다.
두 점은 어디든 좋다. 짐 위든 짐칸 벽이든 차체든 지면이든, 조준해서 맞은 곳이면 매듭이 된다.
잘못 걸었으면 X로 걷어 내면 개수가 그대로 돌아온다. 짐을 든 손으로는 매듭을 짓지 못한다.
로프는 표시가 아니라 진짜 밧줄이다. 짧은 캡슐 강체를 조인트로 이은 사슬이 짐 위를 덮고, 그 사슬이 짐과 부딪히며 생기는 힘이 곧 고정력이다. 그래서 어디에 거느냐가 결과를 바꾼다.
거는 순간 팽팽하다. 늘어진 밧줄이 물리로 내려앉기를 기다리지 않고, 걸릴 자리를 미리 구해
그 선을 따라 사슬을 깐다. 팽팽한 로프가 지나는 자리는 두 매듭 사이에서 잰 장애물 윗면 높이의
위쪽 볼록 껍질이다. 오목하게 파인 자리는 로프가 닿지 않고 뜨는 자리이기 때문이다.
이 계산은 RopePathSolver에 물리와 분리해 두었다.
로프 개수는 스테이지마다 StageDefinition.ropeCount로 정한다(기본 2). 어디에 쓸지 고르는 것이
이 장비의 실력 요소이므로, 무제한으로 주면 "다 묶으면 그만"이 되어 배치의 고민이 사라진다.
로프 하나가 두 위협을 다 막지는 못한다. 실제 화물 고정과 같아서, 거는 방향에 따라 막는 것이 다르다.
| 거는 방향 | 막는 위협 | 실측 |
|---|---|---|
| 가로 (좌우 벽 사이) | 마루에서 짐이 뜨는 것 | 위로 튄 높이 0.425m → 0.04~0.14m |
| 세로 (뒷벽 → 앞 격벽) | 급제동에 짐이 앞으로 쏟아지는 것 | 앞으로 밀린 거리 0.60m → 0.02~0.10m |
원리가 다르기 때문이다. 가로 로프는 짐 윗면을 거의 수평으로 지나므로 장력의 수직 성분이 모서리에만 걸린다. 위로 뜨는 것은 잘 막지만 앞뒤로는 마찰만 조금 보탠다(실측 3% 감소). 반면 세로 로프는 짐이 앞으로 가려면 뒤쪽 구간이 늘어나야 하는데 양 끝이 차체에 묶여 늘어날 수 없다. 마찰이 아니라 기하학이 막으므로 훨씬 강하다.
현재 경로의 주 위협은 급제동이므로, 한 가닥만 쓴다면 세로가 낫다.
로프 규격을 튜닝하려면 RopeSettings와 Rope.cs를 보게 되는데, 두 설정은 정지 상태에서 좋아
보이지만 주행 중에 짐을 날려 버린다. 실제로 그렇게 한 번 터졌다.
| 설정 | 왜 건드리면 안 되나 |
|---|---|
조인트 projectionMode |
벌어진 조인트를 순간이동으로 되돌린다. 트럭은 한 스텝(0.02초)에 20cm를 가는데 사슬은 뒤처지므로 매 스텝 순간이동이 걸리고, 그 속도 불연속이 짐을 날린다. 실측 마디 속도가 트럭의 7배인 73.7m/s까지 올라갔다 |
maxDepenetrationVelocity |
얇은 마디가 짐과 벽 사이에 끼면 기본값 10m/s로 튕겨 나온다. 그 속도가 곧바로 짐에 실린다. 1.5m/s로 묶어 뒀다 |
| 조인트 앵커를 어긋나게 잡아 장력 주기 | 위치를 잠근 조인트에 만족할 수 없는 목표를 주는 셈이라, 솔버가 매 스텝 최대 힘을 내며 진동한다. 그 진동이 짐을 누르기는커녕 밀어낸다. 실측: 위로 튄 높이가 0.057m에서 0.329m로 나빠졌다 |
즉 로프를 늘어나지 않게 하려고 조이는 방향은 대부분 함정이다. 늘어남은 마디 개수를 줄여
(segmentLength를 키워) 줄이는 편이 안전하다.
짐을 누르는 힘은 조인트가 아니라 접촉으로 만든다. RopeSettings.gripDepth(기본 1.2cm)만큼
로프를 짐 표면에 파묻힌 상태로 생성하면, 물리가 그 파묻힘을 밀어내려는 힘이 곧 누르는 힘이 된다.
접촉 솔버는 침투를 부드럽게 처리하도록 설계돼 있어 조인트 방식보다 훨씬 안정적이다.
로프를 그릴 때는 transform.position을 읽어야 한다. Rigidbody.position은 마지막 물리 스텝의
위치라 50Hz로 계단처럼 튀고, 화면은 그보다 자주 그려지므로 물리가 안정해도 로프가 떨려 보인다.
마디에 켜 둔 보간의 결과는 transform에만 반영된다.
집는 거리는 3m, 놓을 면을 찾는 거리는 6m다. 조준은 화면 중앙 레이캐스트가 하므로
사거리를 늘려도 엉뚱한 상자가 집히지는 않는다. 값은 PrototypeSceneBuilder.CargoReach에 있다.
트럭 옆 바퀴 바깥에 선 자리를 기준으로 3m가 무엇을 덮는지는 이렇다.
| 목표 | 거리 | 3m로 닿는가 |
|---|---|---|
| 짐칸 한복판 | 2.6m | 닿는다 |
| 짐칸 건너편 구석 | 3.3m | 안 닿는다. 차체에 바짝 붙어야 겨우 닿는다 |
건너편 구석까지 서 있는 자리에서 닿게 하려면 3.4m 이상이 필요하다. 반대편에 놓을 때 트럭을 돌아가는 게 번거롭다고 느껴지면 그때 올리면 된다.
HUD 슬라이더로 짐칸/화물 마찰을 바꿀 수 있다. 적재 중에는 커서가 잠겨 있으니
Tab으로 커서를 푼 뒤 슬라이더를 만지고, 화면을 다시 클릭하면 시점 조작으로 돌아온다.
핵심 두 가지, 1인칭 짐 쌓기와 트럭 직접 주행이 재미있는지만 확인한다.
- 화물: 사용자 제공 Cardboard Box·Blue Barrel·Marble Bust·Floor Lamp FBX를 재사용한 6개 (보이는 모델과 물리 Box/Capsule 프록시를 분리해 짐칸에 3x2 한 층이 들어간다)
- 경로: 128m. 위에서 보면 일직선, 옆에서 보면 굽이치는 오르막과 내리막 (적재장 평지 → 첫 오르막 → 능선에서 급제동 1회 → 긴 내리막 → 골짜기 → 두 번째 마루 → 마무리 평지)
- 최고 속도 10m/s (약 36km/h)
- 고정 장비는 로프만 있다. 쐐기·고무 매트·그물 등 나머지와 유리 등 추가 짐 속성은 아직 없다
- 도착하면 별 셋짜리 결과 화면이 뜬다. 지킨 짐 수로 등급을 매기고(
CargoTracker.CalculateStars), 별이 하나씩 튀어나오며 나타난다(ResultScreen). 기획서 4.3 의 "유리 무파손" 조건은 유리가 아직 없어 빠져 있다
짐을 위협하는 것이 둘이다. 급제동은 짐을 앞으로 쏟고, 마루는 짐을 가볍게 만들어 마찰을 풀어 놓는다. 급제동은 능선의 평평한 곳에 따로 걸어 뒀다. 마루 위에 겹치면 "짐이 떠서" 미끄러진 건지 "너무 세게 밟아서" 미끄러진 건지 플레이어가 구분할 수 없다.
검증 질문 세 가지:
- 적재 단계에서 고민이 생기는가? (배치 정답이 하나뿐이면 실패)
- 주행 관전이 긴장되는가? (결과가 뻔하면 실패)
- 실패했을 때 다시 하고 싶은가?
PlayMode 테스트가 같은 짐 6개를 두 방식으로 싣고 완주시킨 결과다.
| 배치 | 생존 |
|---|---|
| 한 층으로 깔기 (무게중심 낮게) | 4 / 6 |
| 두 층으로 쌓기 (탑) | 5 / 6 |
경로 굴곡은 고저차 6.2m, 최대 오르막 25도, 최대 내리막 -22도다.
두 층 쪽 숫자는 실행마다 흔들린다. 쌓인 강체가 무너지는 과정은 접촉이 조금만 달라져도 결과가 갈리기 때문이다. 현재 계측에서는 두 층이 5/6으로 한 층의 4/6보다 오히려 많이 남았으므로, 반복 계측에서도 이 결과가 유지되면 배치 난이도를 다시 튜닝해야 한다.
배치가 결과를 바꾼다는 전제는 성립한다. 마찰·속도 프로필·경로 모양을 바꾸면 이 값이 움직이므로,
튜닝 후에는 테스트를 다시 돌려 [CargoStack] 로그로 확인한다.
직접 조향의 차체 롤은 서스펜션 접지를 유지하도록 최대 10도로 제한한다. 최대 롤에 도달한 평지 조향 테스트에서 네 바퀴의 지면 간격은 모두 0.000m였다.
Stage 05 설원 코스는 별도 기준을 쓴다. 경로 길이는 205.0m, 고저차는 5.53m,
최대 오르막은 13.4도, 최대 내리막은 -10.4도다. 고정된 좌우 이동 커브는 없으며,
트럭은 바퀴 아래 PhysicsMaterial의 동마찰을 읽어 조향에 필요한 횡가속도와 실제
접지 한계의 차이만큼 관성으로 밀린다. 현재 얼음 마찰은 약 0.01이며 최대 횡이탈은
좌우 6.50m/1.29m, 슬립 각은 약 49.8도, 롤은 약 5.9도였다. 같은 경로의 마찰을 1.0으로
올린 대조군은 횡이탈 0.05m로 미끄러짐이 사라졌다.
| Stage 05 배치 | 생존 |
|---|---|
| 좌우 균형 3층 적재 | 5 / 7 |
| 한쪽 고층 적재 | 3 / 7 |
같은 주행에서 두 배치의 생존 차이가 두 개 미만으로 줄면 빙판 드리프트나 적재 구성이 배치 판단을 충분히 평가하지 못하는 것으로 본다.
Stage 06은 Stage05를 덮어쓰지 않는 별도 설원 맵이다. 경로 길이 239.6m, 높이 -4.1~8.1m, 좌우 변화 28.2m이며 얼음 큐브 두 개를 포함한 화물 7개를 운송한다. 얼음 화물은 동마찰 0.015, 정지마찰 0.02이고 일반 화물은 동마찰 0.45, 정지마찰 0.55를 유지한다. 현재 자동 주행 기준으로 좌우 균형 3층 적재는 4/7이 생존한다.
Stage 07은 길이 170.4m의 별도 아스팔트 맵이며, 좁고 높은 대형 방지턱 다섯 개를 연속으로 넘는다. 최고 방지턱은 1.3m이고 더블턱 구간이 포함된다. 화물 8개를 두 층으로 싣고 로프 세 개를 모두 사용한 자동 주행에서 6/8이 생존하며, 화물의 최대 상승속도는 2.41m/s였다. 네 바퀴의 도로 간격은 전체 주행 동안 0.000m였고, 최대 서스펜션 이동은 0.258m였다. 로프 없이 무조건 전멸시키는 점프대가 되지 않도록 초기 2.8m 설계에서 낮췄다.
속도를 7m/s에서 10m/s로 올린 뒤에도 격차는 남았다. 다만 속도만 따로 올리면 안 된다. 같은 폭의 골짜기에서 최고 속도를 올리면 감속도가 함께 세져 급제동이 과격해진다. 그래서 급제동 구간을 진행도가 아니라 미터로 잡아 뒀다.
아직 남은 문제: 짐 6개가 한 층에 다 들어가서, 안전한 배치가 언제나 가능하다. 즉 "쌓을까 말까"라는 고민이 없다. 짐칸 용량보다 많은 짐을 주거나(실은 만큼 보수), 짐칸을 좁히면 그 딜레마가 생긴다. 1주차 플레이테스트에서 판단할 항목이다.
/Applications/Unity/Hub/Editor/6000.5.4f1/Unity.app/Contents/MacOS/Unity \
-batchmode -projectPath . -runTests -testPlatform PlayMode \
-testResults /tmp/cargo-stack-tests.xml -logFile /tmp/cargo-stack-tests.logCoreLoopTests가 게임이 성립하기 위한 전제들을 회귀 테스트로 고정한다.
- 마찰만으로 짐이 목적지까지 실려 간다 (이게 깨지면 게임 자체가 성립하지 않는다)
- 트럭 한쪽에 선 채로 짐칸 한복판까지 손이 닿는다 (더 줄이면 상자마다 트럭을 빙 돌아야 한다)
- 경로에 고저차 4m 이상, 오르막·내리막 8도 이상이 있다 (평지로 돌아가면 위협이 급제동 하나로 줄어든다)
- 몸통에 충격이 와도 1인칭 시점이 돌아가지 않는다
- 어떻게 쌓아도 트럭이 도착선까지 간다 (급제동 골짜기가 너무 깊으면 트럭이 멈춰 선다)
편집 전 원본은 SourceAssets/BlueTruck/BlueTruck.original.fbx, Blender 작업 파일은
SourceAssets/BlueTruck/BlueTruckTailgate.blend에 있다. 아래 명령은 원본을 다시 불러와
차체와 뒷문을 닫힌 입체로 Boolean 분리하고 Assets의 FBX와 Blender 작업 파일을 갱신한다.
/Applications/Blender.app/Contents/MacOS/Blender \
--background --factory-startup \
--python tools/edit_blue_truck_tailgate.py스크립트는 문과 차체 절단면의 열린 경계를 검사하며, 검증에 실패하면 FBX를 출력하지 않는다.
형태만 빠르게 확인하려면 tools/render_blue_truck_tailgate.py로 닫힘·열림 프리뷰를
/tmp/cargo-stack-blender-preview에 만들 수 있다. FBX를 갱신한 뒤에는 Unity 메뉴
CargoStack > 스테이지 > 모든 씬 다시 만들기로 파생 메시와 씬을 다시 생성한다.
RopeTests와 RopePathSolverTests가 로프가 표시가 아니라 실제 고정 장비인지 고정한다.
- 위로 튀어 오르려는 짐을 가로 로프가 절반 이하로 눌러 앉힌다 (이게 깨지면 로프는 화면에만 있는 것이다)
- 앞으로 쏟아지려는 짐을 진행 방향 로프가 막는다 (급제동이 주 위협이므로 이쪽이 더 중요하다)
- 주행 중에도 사슬이 튀지 않는다 (마디 속도가 트럭의 2.5배 미만)
- 로프를 건 짐이 주행 뒤에도 짐칸에 남는다 (고정 장비가 가해자가 되면 안 된다)
- 짐칸을 가로지르는 로프가 짐을 관통하지 않고 윗면 위로 지난다
- 팽팽한 선이 봉우리만 짚고 파인 자리는 건너뛴다 (물리 없이 검증한다)
로프 테스트를 처음에는 정지 상태에서만 걸었다가 실제 플레이에서 짐이 쏟아졌다. 고정 장비는 달리는 트럭 위에서 재야 한다. 정지 상태에서 안정을 돕던 설정이 주행 중에는 정반대로 작용하기 때문이다(아래 참고).
Assets/
Scripts/
Core/ GameFlow(상태 머신), GameState
Player/ PlayerController, FirstPersonCamera, PlayerCargoInteractor, PlayerRopeInteractor
Vehicle/ RoutePath(도로 중심선), TruckMover(앞바퀴 조향 직접 주행)
Cargo/ Cargo(짐), CargoTracker(낙하 판정)
Rope/ Rope(사슬 생성), RopePathSolver(팽팽한 선), RopeAttachment(매듭), RopeSettings
Stage/ StageDefinition(스테이지 데이터), StageContext(현재 스테이지), MainMenuController
View/ CameraDirector(시점 전환), DioramaCamera(자유 시점 관전)
Debug/ PrototypeHud(임시 HUD + 마찰 튜닝)
Editor/
PrototypeSceneBuilder.cs
PrototypePreview.cs
Stages/
Prototype/PrototypeStage.asset
Stage01/Stage01Tutorial.asset
Stage02/Stage02SpeedBumps.asset
Assets/Stages 아래의 StageDefinition 에셋에서 경로 제어점, 출발·도착 거리,
최고 속도, 속도 곡선, 화물 구성을 고친 뒤 해당 생성 메뉴를 실행한다.
제어점의 z를 바꾸면 위에서 본 좌우 굽이가 생긴다. RoutePath는 이 제어점을 부드럽게
이어 주며, 트럭의 노면 접지 계산도 만들어진 실제 코너 곡률을 그대로 사용한다.
보이는 도로와 부딪히는 도로가 같은 리본 메시를 공유해 이음매와 높이가 일치한다. 도로 메시는 씬 이름별 에셋으로 분리되어 여러 스테이지를 다시 만들어도 서로 덮어쓰지 않는다.
CargoStack > 프로토타입 씬 다시 만들기: 기존 물리 검증용Prototype- Project 창에서 정의 에셋을 선택한 뒤
CargoStack > 스테이지 > 선택한 정의로 씬 만들기 CargoStack > 스테이지 > 모든 씬 다시 만들기:Assets/Stages의 모든 정의를 경로순으로 생성CargoStack > 메인 메뉴 다시 만들기: 메뉴 노출이 켜진 스테이지만 선택 화면에 반영
새 스테이지는 기존 정의 에셋을 복제해 ID·씬 이름·경로·속도·화물만 바꾸면 된다. 빌더에 새 메뉴나 에셋 경로를 추가할 필요는 없다.
Stage06부터 계속 쓸 얼음 화물은 Assets/Art/Cargo/IceCube에 준비되어 있다.
기존 Stage05의 화물 구성은 유지하고, 새 설원 스테이지에서만 얼음 큐브를 사용한다.
Stage06_FrozenCargo는 별도 설원 경로와 얼음 큐브 두 개를 제공하며, 급경사와
연속 코너에서 일반 화물보다 쉽게 미끄러지는 짐을 함께 고정하는 단계다.
원본 IceCube.glb와 Unity 기본 임포터용 경량 IceCube.obj, 텍스처 4종을 함께 보관한다.
StageCargoDefinition에서 assetName을 IceCube, surfaceType을 Slippery로 지정하면
빌더가 동마찰 0.015, 정지마찰 0.02, Minimum 결합의 IceCargoSurface를 적용한다.
따라서 이동 경로를 인위적으로 밀지 않고 짐칸과의 접촉 마찰 때문에 화물이 미끄러진다.
원본 GLB를 다시 변환할 때는 아래 명령을 사용한다.
python3 tools/convert_glb_cargo.py \
'/Users/curve/Downloads/ice cube 3d model.glb' \
Assets/Art/Cargo/IceCube --name IceCube현재 Stage01_Tutorial은 원통 두 개, 상자 두 개, 조각상과 전등을 제공한다.
Stage02_SpeedBumps는 경로 높이에 방지턱 두 개를 만들고, 상자 네 개와
Capsule 충돌체를 사용하는 원통 화물 하나를 제공한다.
모든 씬 다시 만들기는 마지막에 메인 메뉴도 갱신한다. 메뉴 씬은 Build Settings의
첫 번째 씬이며, 각 스테이지 결과 화면에서 다시 돌아올 수 있다.
CargoStack > 시점 프리뷰 캡처 메뉴를 실행하면 /tmp/cargo-stack-preview에 그림이 떨어진다.
route-profile.png가 옆에서 본 굴곡이다. 경로를 고쳤으면 이걸 봐야 한다.
숫자만 봐서는 길이 굽이치는지 밋밋한지 알 수 없다.
GameFlow가 등뼈다. 적재 → 주행 → 결과 전환이 모두 여기를 거치고,
다른 시스템끼리는 서로를 직접 참조하지 않는다.
Assets/Scripts/Player/의 세 스크립트는 같은 작성자의 nan2026-cargo(NAN 2026 사전과제)
스파이크에서 가져왔다. 손맛이 이미 검증된 코드라 네임스페이스와 화물 타입만 바꿔 그대로 쓴다.
원본의 CargoCarrierProxy는 가져오지 않았다. 그쪽 트럭은 플레이어가 모는 동적 강체라
화물 반작용을 분리할 프록시가 필요했지만, 이 게임의 트럭은 키네마틱이라 화물이 트럭을 밀 수 없다.
씬 파일은 git 자동 병합이 되지 않아 두 사람이 같은 씬을 고치면 한쪽 작업이 통째로 날아간다. 그래서 프로토타입 씬은 코드로 생성한다.
- 차량·카메라처럼 모든 스테이지가 공유하는 생성 규칙은
PrototypeSceneBuilder.cs에서 바꾼다 - 경로·속도·화물처럼 스테이지마다 다른 값은
Assets/Stages의 정의 에셋에서 바꾼다 - Unity의 해당 생성 메뉴를 실행하면 정의마다 독립된 씬과 도로 메시가 만들어진다
- 씬마다 주인 한 명. 다른 사람은 씬을 직접 고치지 않고 프리팹으로 기여한다.
- 시스템 경계 지키기. 시스템끼리 직접 참조하는 대신
GameFlow를 거친다. - 주 2회 정기 통합. 마지막 주에 몰아서 합치지 않는다.
- 새 작업은 새 브랜치(
feat/*,fix/*)에서 시작한다. - 작업을 동시에 굴릴 때는 브랜치가 아니라 worktree로 가른다. 같은 작업 트리를
공유하면 미커밋 변경이 남의 브랜치로 딸려가고, 씬을 다시 만드는 순간 그것까지
씬에 함께 구워진다. 절차는
AGENTS.md에 있다.
AI 코딩 도구(Claude Code, Codex 등)로 작업할 때의 규칙은 AGENTS.md에 모아 두었다.
도구마다 지침을 복사해 두면 어긋나므로 한 파일로 관리한다.