feature-tracker-mcp

프로젝트에 구애받지 않는 기능 및 결정 추적기로, 한 사람이 여러 AI 코딩 세션을 동시에 지휘하면서 병목 지점이 된 경우를 위해 만들어졌습니다.

이 도구가 해결하는 문제는 "기능 추적"이 아닙니다. 해결하는 문제는 이렇습니다: 여러 트랙이 동시에 진행 중이고, 각 세션은 서로를 알지 못하며, 결정이 끊임없이 표면화되고, 모든 것을 읽는 것이 당신의 몫이라는 것입니다. 그 결정들 대부분은 평범하고 위임할 수 있는 것들입니다. 진짜로 당신의 몫인 것은 소수입니다. 오늘날에는 이 둘을 분리하는 메커니즘이 없어서, 당신은 전부를 읽어야 합니다.

이것이 바로 그 메커니즘입니다.

목차

• 역할

• 현재 존재하는 것

• 구조

• 동사

• 모드

• 중추: 프로젝트당 하나의 데이터베이스

• 카테고리

• 게이트: 승인 대기열

• 개수와 수렴

• 중단 조건

• 체크포인트, 일시정지, 요약

• 왜 git에 넣지 않는가

• 무엇이 이것을 망가뜨릴 것인가

• 구축 순서

역할

이 분리의 핵심은 두 번째 행이 현재 인간의 몫인데, 그중 거의 대부분이 인간의 몫일 필요가 없다는 점입니다.

구조

flowchart TD
    Ideate["/ideate — dialog"] -->|features as they are invented| DB[("project database")]
    Session["coding session (Claude)"] -->|every substantive turn| Capture{"implies a feature,<br/>guardrail, schema change<br/>or risk?"}
    Capture -->|yes, and not a duplicate| DB
    Capture -->|no| Session
    DB --> PM["ChatGPT as manager"]
    PM -->|next task, in priority order| Session
    PM -->|mundane decisions| PM
    PM -->|architectural · install · spend| Gate[["gate queue"]]
    Gate -->|approve / alter / reject| You([You])
    You -->|proceed| Session
    DB --> Table["/tracker-table · /standup"]
    Table --> You

두 가지 속성이 핵심 역할을 합니다: 데이터베이스가 상태이므로, 어떤 것도 모델의 기억에 의존하지 않습니다. 그리고 게이트가 차단하므로, "그래, 진행해"는 당신이 그 자리에서 받아야 했던 메시지가 아니라 메커니즘이 됩니다.

현재 존재하는 것

솔직한 구분입니다. 이 문서의 나머지 부분은 부분적으로만 구축된 시스템을 명세하기 때문입니다.

현재 작동 중 — 8개의 MCP 도구, 실제 데이터베이스에 대해 종단 간 검증 완료:

명세만 있고 구축되지 않음: 다음 섹션의 모든 슬래시 명령, 지속적 캡처, 실행 루프, 데이터베이스에서 마크다운 추적기를 다시 렌더링하는 생성기.

실제 프로젝트로 검증됨. 기존 387줄 마크다운 추적기에서 75개의 기능을 가져왔고 모든 id가 보존되었습니다 — DIP-16, GLG-1, UA-11 등이 여전히 해석됩니다. 이들은 커밋 메시지와 워크트리 이름에 인용되어 있고, 재할당하면 그 히스토리가 고아가 되기 때문입니다. 카테고리 카운터는 가져온 최고 id를 넘어서까지 전진되었으므로, 이미 사용 중인 것은 다시 발급될 수 없습니다.

동사

각각은 스킬이므로, 각각 슬래시 명령이기도 합니다. 이 중 어느 것도 아직 구축되지 않았습니다 — 이는 위 도구들 위에 놓일 의도된 표면입니다.

/standup, /tracker-table, /gates는 읽기 전용이며 작업 턴을 소모하지 않습니다.

모드

아이디에이션. 부산물로 채워진 백로그가 나오는 대화입니다. 기능이 발명되는 대로 즉시 데이터베이스에 제안되고, 각각은 동의하거나 수정하도록 당신에게 제시됩니다 — 어떤 것도 조용히 기록되지 않습니다. 이것이 대기열이 채워지는 방식입니다.

실행. 카테고리의 기능들이 우선순위 순서대로 하나씩 완료까지 진행됩니다. ChatGPT가 다음 항목을 선택하고, 코딩 세션에 브리핑하고, 돌아온 결과를 검토하여 수락하거나 다시 보냅니다.

지속적 캡처. 평범한 부분이자, 목록이 진실을 유지하는 이유입니다. 어떤 세션에서든 모든 실질적인 턴이 무엇을 암시했는지 검토됩니다: 새 테이블, 가드레일, CHECK 제약 조건, 완화가 필요한 위험, 아무도 이름을 붙이지 않은 하위 기능. 각각은 제안된 행이 됩니다. 대안은 오늘날 일어나는 일입니다: 한 번 언급되고, 스크롤되어 사라지고, 나중에 비싸게 재발견됩니다.

캡처는 파일을 변경했거나 결론에 도달한 턴에 실행됩니다. 대부분의 턴은 아무것도 암시하지 않으며, 모든 턴에 실행하는 것이 아무도 읽지 않는 백로그를 만드는 방법입니다.

중추: 프로젝트당 하나의 데이터베이스

각 프로젝트는 자체 Postgres 데이터베이스를 가지며, 첫 사용 시 생성되고 프로젝트의 git 원격 저장소 이름에서 이름을 따옵니다 (따라서 같은 프로젝트의 모든 워크트리와 모든 클론이 같은 추적기에 동의합니다).

kind는 feature, guardrail, schema, risk, mitigation 중 하나입니다. status는 proposed → agreed → in_progress → done 또는 dropped로 진행됩니다.

Id는 데이터베이스에 의해 원자적으로 할당됩니다. 이것은 세부 사항이 아닙니다 — 실제로 반복되는 버그 종류에 대한 수정입니다. 두 세션이 독립적으로 파일을 읽고, 다음 빈 번호를 보고, 둘 다 가져가면 중복 마이그레이션 016과 충돌하는 이슈 번호가 발생합니다. 트랜잭션 내부에서 증가하는 카운터는 이를 구조적으로 불가능하게 만듭니다.

모든 이벤트는 git 커밋, 브랜치, 트리를 기록합니다. 이후에 다시 작성된 커밋에 대해 제안된 기능은 HEAD에 대해 제안된 것과 다른 주장이며, 스탬프가 없으면 나중에 아무도 그 차이를 알 수 없습니다.

카테고리

카테고리는 "트랙"이라는 비공식적 개념을 대체하며, 사전에 구성되는 것이 아니라 기능이 기록될 때 생성됩니다. 새 카테고리 아래에 기능을 제안하면 해당 카테고리가 생성되고, 자체 id 접두사와 카운터를 갖습니다 — 따라서 DIP-17과 GLG-1은 충돌하거나 중앙에서 관리되지 않으면서 공존합니다.

게이트: 승인 대기열

게이트는 작업 세션이 단독으로 내려서는 안 되는 결정입니다.

게이트를 올리면 해당 게이트를 올린 세션이 차단됩니다. 게이트는 한 곳에 대기하고, 당신이 승인·수정·거부하면 세션이 재개됩니다. 이것이 *"이건 $40가 들 텐데, 괜찮아?"*를 당신이 지켜봐야 했던 메시지에서 기다리는 대기열 항목으로 바꾸는 방식입니다.

개수와 수렴

진행 상황은 비율이 아닌 두 개의 움직임으로 보고됩니다:

3/14  ->  5/16     +2 agreed, +2 surfaced

분자는 합의를 나타내며 수렴을 측정합니다. 분모가 커지는 것은 건강합니다 — 새 항목은 그동안 진술되지 않은 채 존재했던 실제 불일치가 발견되었음을 의미합니다.

백분율은 이를 뒤집습니다. 12/16 -> 12/20은 75% -> 60%로 읽히며, 아무것도 퇴보하지 않고 두 개의 진짜 이슈가 이름 붙여졌을 때 하락으로 보입니다. 단일 비율은 시스템이 존재하는 바로 그 행동을 처벌하므로, 결코 표시되지 않습니다.

중단 조건

정체는 분자만으로 판단합니다. 아무것도 합의되지 않은 채 항목이 표면화되는 것은 빙빙 도는 것이며, 그것을 진행으로 보고하는 것은 오후를 잃는 가장 쉬운 방법입니다.

체크포인트, 일시정지, 요약

두 턴마다 루프가 멈추고 보고합니다:

NEEDS YOU (1)
  · Is the target "one dollar per Track" or "one opportunity live"?
    Not a fact — it is what you are optimising.

HANDLED (6 of 7 tracks)      +2 agreed, +2 surfaced
  filter-decide   uncommitted migration 020 — no collision with other tracks
  layer-lift      6 behind main, clean rebase available
  ...

언제든지 pause라고 말하면 체크포인트를 기다리지 않고 즉시 요약을 받을 수 있습니다. 당신이 허용한 시간보다 더 오래 무인 실행되는 것은 없습니다 — 자율성은 두 턴에서 시작하며, 신뢰를 얻은 후에만 길어집니다.

왜 git에 넣지 않는가

추적기는 이전에 마크다운 파일이었습니다. 최근 한 주 동안 동시 워크트리에서 115개의 커밋이 발생했고, 히스토리에는 수동으로 해결된 번호 충돌이 포함되어 있습니다. 버전 관리 아래의 단일 파일은 인간의 쓰기 속도에서도 이미 경합 지점입니다. 여러 세션의 자동화된 턴별 쓰기가 추가되면 사용할 수 없게 됩니다.

따라서 데이터베이스가 정본이고 마크다운은 생성된 출력물이 되어, 요청 시 재생성되고 버전 관리에서 제외됩니다.

의도적으로 받아들여야 할 결과: git 히스토리가 곧 감사 추적(audit trail)이었다. feature_event가 이를 대체한다 — 추가 전용(append-only)이며, 행위자와 커밋이 찍혀 있다 — 그리고 이 대체는 선택이 아니라 필수다. 그렇지 않으면 병합 충돌을 기억 상실로 맞바꾸는 셈이다.

마크다운 파일을 표준(canonical)으로 지칭하는 프로젝트 수준의 지침은 같은 변경에서 다시 작성되어야 한다. 세션은 그 지침을 따르며, 하나가 이전 파일을 가리키도록 남겨두면 세션은 아무도 읽지 않는 곳에 계속 쓰게 된다.

무엇이 그것을 깨뜨릴 것인가

제안 스팸(Proposal spam). 여러 트랙에 걸친 턴별 캡처는 수백 개의 저가치 행을 생성할 수 있으며, 그러면 당신은 대화 기록 대신 백로그를 읽게 된다 — 같은 문제가 다른 옷을 입은 것이다. 기준은 명확하다: 오직 그렇지 않으면 유실되고, 실행 가능하며, 이미 다루어지지 않은 것만 기록하라. 중복 제거는 필수다. 두 세션이 독립적으로 동일한 누락 제약을 발견하는 것은 예외가 아니라 정상적인 경우이기 때문이다.

잘못된 트리를 읽기. 워크트리(worktree)는 별도의 체크아웃이다. 세션을 잘못된 트리에 지정하면 파일이 없다고 보고하고 변경 사항이 만들어지지 않았다고 보고할 것이다 — 확신을 가지고, 그리고 코드에 대한 발견처럼 읽히는 방식으로, 잘못된 구성처럼 읽히지 않게. 모든 작업은 읽은 트리를 기록하므로, 불일치는 누군가가 그것에 대해 행동하기 전에 보인다.

계산 대신 서술하는 매니저. 개수는 데이터베이스에서 계산되며, 사실이 아닌 것에 대해 유창할 수 없다. 모델이 쓴 요약은 그럴 수 있다. 둘이 불일치하는 곳에서는, 테이블이 이긴다.

자율성이 주의를 앞지르기. 복리 오류는 아무도 읽지 않을 때 가장 빠르게 비싸진다. 게이트와 체크포인트가 이를 위해 존재하며, 기본 간격은 의도적으로 짧다.

구축 순서

1. category, feature, feature_event, gate; 프로젝트별 데이터베이스 생성; 원자적 ID 할당

2. MCP 도구: propose, list, update, table, history, gate raise/list/decide

3. 지속적 캡처, 기준과 중복 제거, 그리고 동의-또는-변경 검토 큐와 함께

4. 트랙 전반의 /standup, 커밋되지 않은 작업 포함 — 커밋만으로는 작업이 실제로 어디에 있는지 놓친다

5. 세션을 차단하는 게이트

6. /ideate

7. 우선순위 순서로 카테고리를 완료로 이끄는 실행 루프