03. 산출물 저장 규칙 생성

아래 원칙에 따라 우리 팀 프로젝트에 맞는 산출물 저장 규칙 문서를 만든다.

# 입력

아래 빈칸을 채운다. 채우지 않은 항목은 기본값으로 처리한다.

- 프로젝트명:
- 팀명:
- 저장 플랫폼: (노션 / 구글드라이브 / GitHub / 기타)
- 주요 산출물 목록: (예: 벤치마킹 보고서, 와이어프레임, 시안)
- 마감 단위: (주차별 / 일자별 / 스프린트별)

# 네임스페이스 규칙 — Tailwind Primitive 패턴

네임스페이스(namespace)는 파일과 폴더를 겹치지 않게 구분하는 이름 체계다.
이 규칙은 Tailwind CSS의 프리미티브 토큰 방식을 빌려 쓴다.
Tailwind는 text-lg, bg-blue-500처럼 {카테고리}-{수식어} 형태의 짧은 토큰으로 스타일을 지정하는데, 이 패턴을 파일명과 폴더명에 그대로 적용한다.
한 번 정하면 팀원 누구나 파일 이름만 보고 그 파일이 어느 단계의 어떤 상태인지 바로 알 수 있다.

## 1. 카테고리 토큰 — 폴더가 곧 네임스페이스다

프로젝트 단계마다 폴더 하나를 만들고, 폴더 이름을 고정 토큰으로 쓴다.
Tailwind에서 bg-, text- 같은 접두사가 스타일 종류를 가르듯, 폴더 이름이 산출물 종류를 가른다.

| 토큰 | 뜻 | 예시 경로 |
|---|---|---|
| research | 조사·분석 | research/bench-v1.pptx |
| plan | 기획·설계 | plan/sitemap-v2.fig |
| design | 디자인 | design/main-v1.fig |
| dev | 구현·개발 | dev/proto-v1.html |
| qa | 테스트·검수 | qa/test-report-v1.xlsx |
| release | 배포·발표 | release/final-deck-v1.pptx |

우리 프로젝트에 없는 단계는 빼고, 필요한 단계가 있으면 같은 패턴으로 추가한다.

## 2. 수식어 토큰 — 파일 이름 짓는 법

파일 이름은 세 조각을 하이픈(-)으로 잇는다: {내용}-{상태}-{버전}.

| 조각 | 규칙 | 예시 |
|---|---|---|
| 내용 | 산출물 이름을 소문자 kebab-case로 쓴다 | bench, wireframe, user-flow |
| 상태 | draft(초안)·review(검토 중)·final(최종) 셋 중 하나를 쓴다 | draft |
| 버전 | v 뒤에 숫자를 붙인다. 1부터 시작한다 | v1, v2 |

세 조각을 이으면 이렇게 된다:

bench-draft-v1.pptx → bench-review-v1.pptx → bench-final-v1.pptx

이 이름만 보면 "벤치마킹 보고서, 초안, 첫 번째 판"이라는 것을 파일을 열지 않아도 알 수 있다.

상태가 바뀌면 파일을 새로 복사하지 않는다. 같은 파일의 이름(또는 태그)만 바꾼다.
내용이 크게 달라져서 이전 판을 남겨야 하면 버전 숫자를 올린다: bench-draft-v2.pptx.

## 3. 변형 토큰 — 같은 파일의 다른 용도가 필요할 때

Tailwind에서 sm:, md:, lg:를 붙여 화면 크기별 스타일을 나누듯, 산출물에도 용도별 변형이 필요할 때가 있다. 이때 파일 이름 끝에 변형 토큰을 하나 더 붙인다.

| 토큰 | 용도 | 예시 |
|---|---|---|
| -full | 전체 버전 | bench-final-v1-full.pptx |
| -lite | 요약본 | bench-final-v1-lite.pdf |
| -print | 인쇄용 | poster-final-v1-print.pdf |
| -presenter | 발표자 노트 포함 | deck-final-v1-presenter.pptx |

변형이 필요 없으면 이 토큰은 붙이지 않는다. 대부분의 파일은 세 조각(내용-상태-버전)만으로 충분하다.

## 4. 폴더 구조 — 전체 모습

위 규칙을 합치면 팀 폴더는 아래와 같은 모양이 된다.

{팀명}/
├── research/
│   ├── bench-draft-v1.pptx
│   ├── market-final-v1.pptx
│   └── schedule-final-v1.pptx
├── plan/
│   ├── sitemap-draft-v1.fig
│   └── user-flow-review-v1.fig
├── design/
│   ├── system-draft-v1.fig
│   └── wireframe-draft-v1.fig
├── dev/
├── qa/
└── release/
    └── final-deck-draft-v1.pptx

폴더 이름(카테고리 토큰)이 산출물의 단계를 알려 주고, 파일 이름(수식어 토큰)이 내용·상태·버전을 알려 준다.
새 팀원이 와도 폴더를 열면 "어느 단계에 어떤 산출물이 어떤 상태로 있는지" 바로 파악할 수 있다.

## 5. 제출 규칙

파일을 만들고 이름을 짓는 것만으로는 제출이 아니다.
아래 다섯 가지를 지켜야 제출로 인정된다.

1. 제출은 파일을 실제로 첨부하거나 접근 가능한 링크(Figma·Canva 등)를 남겨야 인정된다. 카드 상태만 "완료"로 바꾸는 것은 제출이 아니다. 파일이나 링크가 없으면 관리자가 확인할 방법이 없기 때문이다.
2. 위 토큰 규칙에 맞지 않는 이름의 파일은 제출 전에 이름을 맞춘다. 이름이 다르면 같은 산출물인데도 서로 다른 파일로 보인다.
3. 마감 시점에 제출하는 파일의 상태는 반드시 final로 바꾼다. 상태가 draft인 채로 마감을 넘기면 미제출로 간주할 수 있다.
4. 같은 이름으로 덮어쓰지 않는다. 수정한 내용이 있으면 버전 숫자를 올린다. 덮어쓰면 이전 판이 사라져 되돌릴 수 없다.
5. 링크로 제출할 때는 링크 앞에 도구 이름을 표기한다. 예: [Figma] https://..., [Canva] https://.... 링크만 있으면 열어 보기 전까지 무슨 도구인지 알 수 없다.

## 6. 출력 요청

위 원칙을 우리 팀의 입력값에 맞춘 저장 규칙 문서를 만든다.
아래 네 가지를 포함한다.

1. 우리 팀 전용 폴더 구조 — 트리 형태로 그린다
2. 산출물별 파일명 예시 표 — 산출물 이름, 폴더, 파일명 예시를 한 표에 담는다
3. 마감별 제출 체크리스트 — 마감 단위마다 제출해야 할 산출물과 상태를 정리한다
4. 팀원 공유용 한 장 요약 — A4 한 장에 이름 짓는 법, 폴더 구조, 제출 규칙을 넣는다