남윤서AX 사업개발 · 사업관리

A15

문서 지도 + 작성 순서 게이트

문서가 몇 개이고 무엇에 의존하며 어떤 순서로 써야 하는지의 단일 지도.

형식
템플릿
붙이는 곳
프로젝트 루트 DOCS-INDEX.md
분량
90줄
업무 단계
버전
v0.1 · 2026. 8. 10.

언제 쓰나

  • 기획 문서가 열 개를 넘어 신규 인원에게 열람 순서를 설명하기 어려울 때
  • 문서 A를 수정했을 때 B의 수정 필요 여부를 매번 판단해야 할 때
  • 규격 작성이 끝나기 전에 자동화 착수 요구가 생길 때 — 게이트로 차단이 필요한 시점

안 쓰는 경우

문서가 다섯 개 이하이면 지도가 영토보다 큽니다. 폴더를 직접 확인하는 편이 낫습니다. 문서 구조가 유동적인 초기에는 지도가 매일 어긋납니다. 구조를 두세 차례 재편한 뒤에 작성하십시오.

입력

현재 보유한 문서 목록. 최소 입력은 이 항목뿐이며, 계층·의존은 작성 과정에서 정하면 됩니다. 계층을 먼저 설계하고 문서를 배치하면 실제 구조와 어긋납니다.

사용법

  1. 프로젝트 루트에 DOCS-INDEX.md 로 저장합니다.
  2. §2 일람에 현재 문서를 모두 등재하고 상태를 표기합니다. 초안도 제외하지 않습니다.
  3. §4 작성 순서에 "← 현재" 를 표시합니다. 이후 진행 상태는 이 한 줄만 옮깁니다.

본문

90줄
<!-- 문서 지도 + 작성 순서 게이트 v0.1 · https://namtank96.github.io/assets/a15-docs-index -->

# 문서 목록 (Docs Index)

> 이 프로젝트의 문서가 몇 개이고, 무엇이 무엇에 의존하며, 어떤 순서로 써야 하는지의 단일 지도.
> 새 문서를 만들면 **같은 커밋에서** 이 표를 갱신한다.

## 0. 이 프로젝트가 만드는 것 (한 줄)

{한 문장. 이 줄이 안 써진다면 문서를 더 쓸 때가 아니다. 범위부터 정한다.}

## 1. 문서 계층

문서를 종류가 아니라 **바뀌는 속도**로 나눈다. 아래층이 바뀌면 위층은 대개 안 바뀐다.

| 층 | 무엇 | 바뀌는 빈도 |
|---|---|---|
| **L0 정체성** | 원칙. 규격들이 왜 그 모양인지의 근거 | 거의 안 바뀜 |
| **L1 규격 (SSOT)** | 입력·도출·출력의 형식. 기계 검증본과 항상 동기 | 결정이 갈릴 때 |
| **L2 운영** | 매 세션 지킬 규칙, 검증 방법, 배포 절차 | 자주 |
| **L3 실행** | 하네스, 스크립트, 축적 규칙 | 자주 |

**규칙이 규격과 어긋나면 규격이 이긴다. 규격이 원칙과 어긋나면 원칙이 이긴다.**

## 2. 문서 일람

층마다 표 하나. 각 행에 **상태**를 반드시 단다. 상태가 없으면 읽는 사람이 그 문서를 믿어도 되는지 판단할 수 없다.

| 문서 | 역할 | 상태 |
|---|---|---|
| `{경로}` | {한 줄} | 확정 v1.0 / 작성 중 / 초안 / **폐기** |

- **초안을 일람에서 빼지 않는다.** 빼면 같은 문서를 다시 만든다.
- **폐기 문서는 일람 맨 아래 별도 절에 사유와 함께 남긴다.**

## 3. 의존 관계

```
L0 원칙
  └─ L1 규격 A ──┬─ L1 규격 B (A의 출력을 입력으로 받음)
                 └─ L2 운영 규칙 (A·B를 요약해 매 세션 적용)
                        └─ L3 하네스 (B의 산출을 검증)
```

- **화살표를 거슬러 올라가는 참조를 만들지 않는다.**
  L1 규격이 L3 하네스를 참조하기 시작하면 순환이 생기고, 그때부터 어느 것이 먼저인지 아무도 모른다.
- 문서 A를 고칠 때 **아래로 흐르는 문서를 같은 커밋에서 확인한다.**

## 4. 작성 순서와 게이트

**이 절이 이 문서의 존재 이유다.** 진행이 어디까지 왔는지의 기준점이 여기 있다.

```
1. 원칙 (L0)              ← 여기서 갈릴 결정의 기준을 먼저 잡는다
2. 입력 규격 (L1)
3. 도출 규격 (L1)
4. 출력 규격 (L1)
5. ★ 첫 건을 손으로 완주   ← 게이트
6. 하네스 (L3)
7. 검증 (L3)
8. 축적 (L3)
```

**게이트 규칙**

- **5번을 손으로 완주하기 전에 6~8번에 착수하지 않는다.**
  손으로 한 번 끝까지 가보기 전에는 어디가 반복이고 어디가 판단인지 알 수 없다.
  그 상태에서 만든 자동화는 판단해야 할 곳을 자동화하고 반복을 남겨둔다.
- **규격 1개를 확정하면 즉시 1건에 적용해 교정한다.** 여러 개를 쌓아두고 한 번에 검증하지 않는다.
  결함이 한꺼번에 쏟아지면 어느 규격이 원인인지 분리되지 않는다.
- 순서를 앞당겨야 하면 **왜 앞당기는지 적고 확인을 받는다.** 조용히 건너뛰지 않는다.
- **현재 위치를 이 문서에 표시한다.** `← 현재` 한 줄이면 된다.
  여러 문서에 진행 상태를 흩어두면 어디가 진짜인지 모르게 된다.

## 5. 폐기 문서

| 문서 | 폐기일 | 사유 | 대체 |
|---|---|---|---|
| `{경로}` | YYMMDD | {왜 버렸는지} | `{경로}` 또는 없음 |

지운 이유가 다음 사람의 자산이다. 파일은 보관 폴더로 옮기고 표에 남긴다.

---

## 유지 규칙

- **새 문서 = 같은 커밋에서 이 표 갱신.** 별도 작업으로 미루면 반드시 어긋난다.
- 이 문서가 길어지면 문서가 너무 많은 것이다. 지도를 손보지 말고 문서 수를 줄인다.
- 문서 상태를 낙관적으로 적지 않는다. **"작성 중"을 "확정"으로 적는 순간 이 지도는 못 쓰게 된다.**

출력 예시

§4 게이트가 이 문서의 존재 이유입니다.

## 4. 작성 순서 — 게이트

1. 원칙 (L0)              ✅ 확정
2. 입력 규격 (L1)         ✅ 확정 v1.0
3. 도출 규격 (L1)         ✅ 확정 v1.0
4. 출력 규격 (L1)         🔨 작성 중        ← 현재
5. ★ 첫 건을 손으로 완주   ⛔ 게이트
6. 하네스 (L3)            ⏸ 5번 통과 전 착수 금지
7. 검증 (L3)              ⏸
8. 축적 (L3)              ⏸

6~8번에 “착수 금지”가 명시된 것이 핵심입니다. 자동화는 착수 요구가 상시 발생하고, 착수하면 진척이 체감됩니다. 다만 5번을 거치지 않으면 판단이 필요한 지점을 자동화하고 반복 작업은 남기게 됩니다.

일람에는 상태를 함께 표기합니다.

| 문서 | 역할 | 상태 |
|---|---|---|
| docs/PRINCIPLES.md | 규격이 왜 그 모양인지의 근거 | 확정 v1.0 |
| docs/INPUT-SPEC.md | 입력 형식. 스키마와 동기 | 확정 v1.0 |
| docs/OUTPUT-SPEC.md | 출력 형식 | 작성 중 |
| docs/HARNESS.md | 실행 하네스 | 초안 — 사용 금지 |

사용 금지 상태인 초안도 일람에서 제외하지 않습니다. 제외하면 동일한 문서가 다시 작성됩니다.

이 규칙의 근거

종류가 아니라 바뀌는 속도로 나누는 것. “기획/개발/운영”으로 나누면 한 폴더 안에 매일 바뀌는 문서와 반년에 한 번 바뀌는 문서가 혼재합니다. 변경 속도로 나누면 아래층이 바뀔 때 위층은 검토하지 않아도 된다는 판단이 가능해집니다.

위층이 아래층을 이기게 하는 것. 규칙과 규격이 어긋났을 때 어느 쪽이 기준인지 매번 논의하면 동일한 논쟁이 반복됩니다. 우선순위를 한 번 정해 두면 이 논쟁이 발생하지 않습니다.

화살표를 거스르는 참조 금지. 규격이 하네스를 참조하기 시작하면 순환이 생깁니다. 순환이 생기면 수정 순서를 결정할 수 없고, 이 시점부터 문서 세트 전체의 변경이 어려워집니다.

게이트를 두는 것. 순서를 정하지 않으면 선호하는 작업이 먼저 수행됩니다. 자동화가 선호되고 규격 작성은 후순위로 밀립니다. 규격 없이 만든 자동화는 규격이 정해지는 시점에 다시 만들어야 합니다. 게이트 한 줄이 이 재작업을 방지합니다.

현재 위치를 이 문서에만 표시하는 것. 진행 상태를 여러 문서에 분산하면 기준 문서를 특정할 수 없고, 문서 간 상태가 불일치합니다. ← 현재 한 줄을 한 곳에만 두면 이 문제가 발생하지 않습니다.

폐기 문서를 남기는 것. 폐기 사유는 후속 담당자에게 필요한 정보입니다. 기록이 없으면 반년 뒤에 동일한 문서가 다시 작성됩니다.

주의점·한계

  • 새 문서를 추가할 때 같은 커밋에서 갱신하지 않으면 하루 만에 실제 구조와 어긋납니다.
  • 문서 상태를 낙관적으로 기재하면("작성 중"을 "확정"으로) 지도 전체의 신뢰도가 저하됩니다.
  • 이 문서가 길어지면 문서 수가 과다한 상태입니다. 지도가 아니라 영토를 줄여야 합니다.

변경 이력

  • v0.1 · 2026. 8. 10. · 최초 공개