Track

---
name: track
description: 다작 vs 깊게 하나 — 범위·규모와 수익 모델을 보고 트랙을 추천하고 불일치를 짚는다. 트리거 "트랙", "다작", "깊게", "규모 판정", "어디에 낼까", "플랫폼 선택".
---

# track

nereus:common 규칙을 따른다. 담당 에이전트: architect.
**엔진과 무관하다** — 트랙은 엔진이 아니라 플랫폼과 수익 모델이 정한다.

**언제 부르나**: spec 이 끝난 직후다. 그때 `tasks.md` 가 있고 규모가 실측값으로 존재한다.
intake 직후에는 규모를 모르므로 추측이 된다.

## 0. 이것만 게이트가 아니다

다른 검사기는 `violations` 를 내고 통과·차단을 판정한다.
여기는 `recommendation` · `reasons` · `mismatches` 를 낸다. **강제하지 않는다.**

트랙 선택은 **사업 판단**이지 기술 판정이 아니다.
"이 게임은 다작으로 가면 안 된다"를 하네스가 강제하면 하네스가 사업을 결정하게 된다.
근거를 주고 판단은 사람이 한다.

## 1. 두 트랙은 성격이 정반대다

| | 깊게 하나 | 다작 |
|---|---|---|
| KPI | 리텐션 · ARPU | **사이클 타임** |
| 게이트 | 두껍게 — liveops · compliance · telemetry 전부 | **얇게** |
| 출시 | **시작** | 끝 |
| 대표 플랫폼 | 로블록스 · 스위치 | 스팀 |

**트랙을 잘못 고르면 게이트가 일을 방해한다.** 다작에 두꺼운 게이트를 씌우면
게임 하나당 통과 비용이 커져 사이클이 안 돈다. 깊게에 얇은 게이트를 씌우면
라이브 운영에서 터진다.

## 2. 깊게를 강제하는 조건이 먼저다

"다작이 좋다/나쁘다"가 아니다. **구조적으로 다작이 불가능한 조건**이 있다.

| 조건 | 왜 |
|---|---|
| 플랫폼 = 로블록스 | 알고리즘이 체류·리텐션·라이브옵스를 보상한다. 얕은 여러 개는 전부 발견되지 않는다 |
| 플랫폼 = 스위치 | 승인·개발기·Lotcheck 으로 타이틀당 마찰이 가장 크다 |
| 수익 = IAP | 지속 경제는 운영이 필요하다. 내고 잊을 수 없다 |
| 라이브 이벤트 계획 | 시즌·이벤트는 정의상 지속 운영이다 |
| 상태 유지 멀티플레이어 | 서버 상태·진행도가 살아 있어야 한다 |

하나라도 걸리면 `deep` 이다. **아무것도 안 걸릴 때만** 규모를 본다.

## 3. 사용법

```bash
echo '{"tasksText":"'"$(cat openspec/changes/<변경>/tasks.md)"'","model":{"platform":"steam","revenue":"premium","liveEvents":false,"persistentMultiplayer":false}}' \
  | node "${CLAUDE_PLUGIN_ROOT}/lib/track-advisor.mjs"
```

규모는 **파일에서 읽는다.** 태스크 형식이 둘이라 둘 다 센다:

| `matched` | 형식 | 내는 도구 |
|---|---|---|
| `"nereus"` | `- [ ] T1. 설명` — 번호 뒤 마침표 | nereus:spec / OpenSpec |
| `"spec-kit"` | `- [x] T001 설명` — 번호 뒤 공백. 끼워 넣은 `T042a` 포함 | spec-kit (greenfield) |
| `null` | 어느 쪽도 아니다 | — |

Steps 안의 체크박스는 세지 않는다(세면 규모가 몇 배로 부풀어 판정이 틀린다).
수익 모델·플랫폼은 파일에서 알 수 없으므로 **선언받는다.** 추론하면 그럴듯하게 틀린다.

알 수 없는 플랫폼·수익 모델은 기본값으로 떨어지지 않고 **던진다.**

### `matched: null` — 태스크가 0개인 것과 다르다

둘 다 `tasks: 0` 으로 도착하면 호출자가 구분할 수 없다. 그래서 `matched` 를 같이 낸다.
`null` 이면 `recommendTrack` 은 **규모 임계 비교를 건너뛰고** `reasons` 에 `scope-unknown` 을 싣는다.
강제 조건 근거는 형식과 무관하게 그대로 나온다.

`checkboxes`(체크박스 총수)는 태스크 수의 **상한**이다 — Steps 항목이 섞인다.
형식 미상일 때 이걸로 대신 판정하지 않는다. 부푼 수로 게이트를 돌리는 것이 판정 없는 것보다 나쁘다.

> 실측(2026-09-13): ToonTone 의 spec-kit `tasks.md` 에 태스크 188개가 있었는데 0개로 셌다.
> 계수기가 nereus:spec 형식만 읽었기 때문이다. 에러가 아니라 **조용히** 근거 0건의 `many` 가 나왔다 —
> 임계 24개를 7.8배 넘는 프로젝트에서. 고친 뒤 188 · `spec-kit` · `deep` 이 나온다.

## 4. 불일치가 라벨보다 가치 있다

추천은 한 단어지만 불일치는 고칠 거리를 준다. **추천과 독립적으로** 계산한다 —
`deep` 추천이어도 모순은 모순이다.

| 코드 | 뜻 |
|---|---|
| `premium-with-live-events` | 유료 단품인데 라이브 이벤트를 계획했다. 판매는 한 번이고 운영은 계속이다 |
| `scope-over-budget` | 다작을 막는 구조적 조건은 없는데 규모만 크다. **범위를 줄이면 다작이 가능하다** |

## 5. 임계값은 추정이다

`tracks.json` 의 `manyTrack.maxTasks` 는 메챠 카멜레온의 2인·2개월을 기준점으로 삼은 **추정**이고,
`estimate: true` 와 근거가 붙어 있다. 우리 실측 이력이 없기 때문이다.
규모로 낸 근거에도 추정 표시가 따라 붙는다 — **조용한 추정은 틀린 확신을 만든다.**

게임을 실제로 한 번 끝내면 그 태스크 수로 이 값을 고친다. **코드가 아니라 `tracks.json` 만 고친다.**

## 하지 말 것

- 추천을 판정으로 쓰지 않는다. 근거를 읽고 사람이 정한다.
- intake 직후에 부르지 않는다. 규모를 모르는 상태의 추천은 추측이다.
- 임계값을 코드에 박지 않는다. 실측이 생기면 데이터만 고쳐야 한다.