04. 팀 협업 룰 직접 만들기 — 대화형 AI로 여섯 단계 밟기

이 문서에서는 팀 프로젝트에 맞는 협업 룰을 AI 프롬프트로 직접 만들어 본다. Notion 팀 DB와 Figma 디자인시스템을 소스로 연동해 카테고리를 확정하고, 실제 사건에서 룰을 뽑아 매핑표까지 완성하는 과정이다. 다 따라 하면 환경 카드 1장, 카테고리 번호표 1장, 세부 룰 1개, 산출물-룰 매핑표 1장이 남는다.

1 – 팀 환경 카드 만들기

룰은 팀마다 다르다. 쓰는 도구, 만드는 산출물, 마감 주기가 다르기 때문이다. 먼저 팀 환경을 한 장에 정리해야 그에 맞는 룰이 나온다. 이 묶음에서는 메모장에 환경 카드를 작성하고, AI에게 룰 시스템의 세 원칙을 팀 예시로 설명받는다.

1.1 – 작업 환경 준비

환경 카드와 룰 작업 기록을 저장할 폴더와 파일을 먼저 만든다.

1. 바탕화면에 "팀협업룰" 폴더를 만든다.
2. Windows: 바탕화면 빈 곳에서 마우스 오른쪽 클릭 → [새로 만들기] → [폴더] → 이름을 팀협업룰로 입력한다.
3. macOS: Finder → 바탕화면 → 마우스 오른쪽 클릭 → [새로운 폴더] → 이름을 팀협업룰로 입력한다.
4. "팀협업룰" 폴더 안에 아래 두 파일을 빈 텍스트 파일로 만든다.
5. "환경카드.md" — 팀 정보를 정리하는 파일이다.
6. "룰_작업기록.md" — 룰 ID, 사건, 매핑표를 모아 두는 파일이다.
7. 브라우저에서 AI 대화창을 연다. ChatGPT, Claude, Gemini 중 하나를 쓴다.
8. ChatGPT: https://chat.openai.com 접속 → 로그인 → [New chat] 클릭
9. Claude: https://claude.ai 접속 → 로그인 → [New conversation] 클릭
10. Gemini: https://gemini.google.com 접속 → 로그인
11. 브라우저 탭을 하나 더 열고, 팀의 Notion 워크스페이스에 로그인한다.
12. 브라우저 탭을 하나 더 열고, Figma에 로그인한다.

작업에 쓸 화면이 모두 준비됐다. 텍스트 편집기, AI 대화창, Notion, Figma — 네 개 창을 오가며 작업한다.

1.2 – 환경 카드 작성

환경 카드(environment card)는 팀명, 도구, 산출물, 소스 주소를 한 곳에 정리한 문서다. 이 카드에 적은 정보가 뒤의 모든 단계에서 기준이 되므로, 빈칸 없이 채우는 것이 중요하다.

1. "환경카드.md" 파일을 텍스트 편집기로 연다.
2. 아래 템플릿을 복사해 붙여 넣는다.

# 환경 카드

- 프로젝트명:
- 팀명:
- 저장 플랫폼: (Notion / Google Drive / GitHub / 기타)
- 주요 산출물: (예: 벤치마킹, 와이어프레임, 시안, 코드)
- 마감 단위: (주차별 / 일자별 / 스프린트별)
- 연동할 소스 주소:
    · Notion 팀 DB URL:
    · Notion 할일 DB URL:
    · Figma 디자인시스템 URL:
    · Figma 시안 URL:

3. 각 항목을 팀 상황에 맞게 채운다.
4. 프로젝트명: 팀이 진행 중인 프로젝트 이름을 적는다. 예: 쇼핑몰 리디자인.
5. 팀명: 팀 이름을 적는다. 예: 디자인2팀.
6. 저장 플랫폼: 산출물을 모아 두는 곳을 적는다. 여러 곳이면 모두 적는다.
7. 주요 산출물: 팀이 만드는 결과물을 나열한다. 예: 벤치마킹, 와이어프레임, 시안, 프로토타입.
8. 마감 단위: 일을 끊는 주기를 적는다. 예: 주차별.
9. 소스 주소: Notion DB와 Figma 파일의 URL을 붙여 넣는다.
10. 파일을 저장한다(Ctrl+S / ⌘+S).

1.3 – 룰 시스템 세 원칙 이해하기

협업 룰은 한꺼번에 다 만들지 않는다. 세 가지 원칙에 따라 조금씩 쌓아 간다.

1. 계층화 — 공통 룰 위에 카테고리 룰, 그 위에 세부 룰을 쌓는 구조다. 아래 층의 룰이 위 층의 룰을 이어받고, 겹치면 아래 층이 우선한다. 회사 전체 코딩 규칙(공통)보다 프론트엔드팀 규칙(카테고리)이, 그보다 버튼 컴포넌트 규칙(세부)이 우선하는 식이다.
2. 모듈화 — 작업 단계별로 룰을 독립된 블록으로 나누는 방식이다. 벤치마킹 룰과 시안 룰을 섞어 두지 않고 블록별로 나누면, 한 블록을 고쳐도 다른 블록에 영향이 없다.
3. 애자일 — 룰을 미리 다 만들지 않고 문제가 반복될 때마다 하나씩 만드는 방식이다. “이번에 이런 일이 생겼으니 다음부터는 이렇게 하자”를 룰로 적는다.

이 세 원칙을 팀 상황에 맞는 예시로 바꿔 보면 더 잘 이해된다. AI에게 요청한다.

1. AI 대화창으로 전환한다.
2. 아래 프롬프트를 복사해 붙여 넣되, {중괄호} 안의 내용을 환경 카드에서 가져와 채운다.

아래 세 원칙을 우리 팀 상황에 맞는 예시로 다시 설명해줘.

1. 계층화 — 공통 룰 > 카테고리 룰 > 세부 룰, 하위가 상위를 상속·우선
2. 모듈화 — 작업 단계별로 룰을 독립 블록으로
3. 애자일 — 룰을 미리 다 만들지 않고, 반복될 문제만 사건 발생 시 룰화

우리 팀 산출물: {환경 카드의 주요 산출물}
우리 팀 도구: {환경 카드의 저장 플랫폼}

주의: 카테고리 이름은 지금 지어내지 마라. 카테고리는 뒤에서 팀 소스를 읽어 정한다.

3. Enter를 눌러 전송한다.

AI가 팀 산출물(예: 벤치마킹, 와이어프레임, 시안)을 예시로 들어 세 원칙을 설명한다. 이 응답에서 카테고리 이름이 나오더라도 지금은 참고만 하고 확정하지 않는다. 카테고리는 3번 묶음에서 Notion DB의 실제 분류값을 읽어 정한다.

4. AI 응답을 읽고, 세 원칙이 팀에 어떻게 적용되는지 이해한다.

실습 코칭 프롬프트

이 묶음에서 환경 카드 작성과 룰 시스템 세 원칙 이해를 마쳤다. 아래 프롬프트를 AI에 붙여 넣으면, 환경 카드가 제대로 채워졌는지와 세 원칙을 이해했는지 한 단계씩 점검받을 수 있다.

아래는 "팀 협업 룰 생성기" 실습의 첫 묶음(환경 카드 + 룰 시스템 세 원칙)을 점검받기 위한 요청이다.

점검 대상:
- 환경 카드(팀명·도구·산출물·소스 주소가 적힌 문서)
- 룰 시스템 세 원칙(계층화·모듈화·애자일) 이해

행동 규칙:
- 답을 통째로 주지 않는다.
- 내가 적은 환경 카드를 보고, 빠진 항목이나 모호한 부분을 하나씩 짚는다.
- 세 원칙 중 하나를 골라 "네 팀 산출물에 이 원칙을 적용하면 어떻게 되는지 설명해 봐"라고 물어, 내가 직접 답하게 한다.
- 내 답이 맞으면 다음 원칙으로 넘어가고, 틀리면 힌트를 하나 주고 다시 답하게 한다.
- 세 원칙을 모두 확인하면 "환경 카드와 원칙 이해가 끝났다. 다음은 룰 ID 형식을 정할 차례다"로 마무리한다.

내 환경 카드:
{여기에 환경카드.md 내용을 붙여 넣는다}

지금 막힌 부분:
{막힌 게 없으면 "없음"이라고 적는다. 막힌 게 있으면 구체적으로 적는다}

아래는 "팀 협업 룰 생성기" 실습의 첫 묶음(환경 카드 + 룰 시스템 세 원칙)을 점검받기 위한 요청이다.

점검 대상:
- 환경 카드(팀명·도구·산출물·소스 주소가 적힌 문서)
- 룰 시스템 세 원칙(계층화·모듈화·애자일) 이해

행동 규칙:
- 답을 통째로 주지 않는다.
- 내가 적은 환경 카드를 보고, 빠진 항목이나 모호한 부분을 하나씩 짚는다.
- 세 원칙 중 하나를 골라 "네 팀 산출물에 이 원칙을 적용하면 어떻게 되는지 설명해 봐"라고 물어, 내가 직접 답하게 한다.
- 내 답이 맞으면 다음 원칙으로 넘어가고, 틀리면 힌트를 하나 주고 다시 답하게 한다.
- 세 원칙을 모두 확인하면 "환경 카드와 원칙 이해가 끝났다. 다음은 룰 ID 형식을 정할 차례다"로 마무리한다.

내 환경 카드:
# 환경 카드
- 프로젝트명: 쇼핑몰 리디자인
- 팀명: 디자인2팀
- 저장 플랫폼: Notion, Figma
- 주요 산출물: 벤치마킹, 와이어프레임, 시안, 프로토타입
- 마감 단위: 주차별
- 연동할 소스 주소:
    · Notion 팀 DB URL: https://notion.so/team/design2-db
    · Notion 할일 DB URL: https://notion.so/team/design2-tasks
    · Figma 디자인시스템 URL: https://figma.com/file/abc123/design-system
    · Figma 시안 URL: https://figma.com/file/def456/shopping-mall-redesign

지금 막힌 부분:
없음

1. {여기에 환경카드.md 내용을 붙여 넣는다} — 앞에서 작성한 환경카드.md의 전체 내용을 복사해 넣는다.
2. {막힌 게 없으면 "없음"이라고 적는다...} — 작성 중 헷갈린 항목이 있으면 적는다. 예: 소스 주소를 어디서 찾는지 모르겠다.

2 – 룰 ID와 소스 연동

환경 카드가 준비됐으니 이제 두 가지를 정한다. 첫째, 룰을 식별하는 ID 형식을 못 박는다. 둘째, Notion DB와 Figma 디자인시스템을 열어 카테고리를 확정하고 불일치를 찾는다. 카테고리는 임의로 짓지 않고 팀이 이미 쓰고 있는 분류를 그대로 읽어 오는 것이 핵심이다.

2.1 – 룰 ID 형식 정하기

룰 ID(rule identifier)는 룰을 식별하는 고유 번호다. 형식이 일정해야 문서, 태그, 커밋 메시지 어디에서든 같은 룰을 가리킬 수 있다.

1. "룰_작업기록.md" 파일을 텍스트 편집기로 연다.
2. 파일 맨 위에 아래 내용을 붙여 넣는다.

# 룰 ID 규칙

- 형식: [카테고리번호]-[룰번호]
- 숫자와 하이픈만 쓴다 (점·한글·약어 금지)
- 한글 이름은 ID 옆에 병기한다 (사람이 읽는 자리에만)

## 경로별 표기
- 문서: [3-1]
- 태그: @r3-1
- CLI/터미널: @r3-1
- 커밋 메시지: [3-1]

## 카테고리 번호표
(3번 묶음에서 채운다)

3. 파일을 저장한다.

이 형식에서 앞의 숫자는 카테고리 번호, 뒤의 숫자는 그 카테고리 안에서의 룰 순서다. 예를 들어 [3-1]은 “3번 카테고리의 첫 번째 룰”이다. 카테고리 번호는 아직 비어 있다. 다음 단계에서 Notion DB를 읽어 채운다.

4. AI 대화창에 아래 프롬프트를 붙여 넣어 ID 형식의 호환성을 점검한다.

우리 팀 룰 ID 형식을 점검해줘.

- 형식: [카테고리번호]-[룰번호], 숫자와 하이픈만 (점·한글·약어 금지)
- 한글 이름은 ID 옆에 병기 (사람이 읽는 자리에만)
- 경로별 표기: 문서 [3-1] / 태그 @r3-1 / CLI @r3-1 / 커밋 [3-1]

우리 도구: {환경 카드의 저장 플랫폼}

이 형식이 위 도구에서 안 깨지는지 확인하고 형식 확정안을 줘.

5. AI 응답을 읽고, 호환성 문제가 있으면 형식을 수정한다. 문제가 없으면 그대로 확정한다.

2.2 – Notion DB에서 카테고리 읽기

카테고리(category)는 룰을 분류하는 작업 단계 이름이다. 카테고리를 임의로 짓지 않고 Notion DB에 이미 있는 분류값을 그대로 읽어 온다. 팀이 실제로 쓰는 분류를 기준으로 삼아야 룰이 현실과 맞기 때문이다.

1. 브라우저에서 Notion 탭으로 전환한다.
2. 환경 카드에 적은 Notion 팀 DB URL을 주소창에 붙여 넣고 Enter를 누른다.
3. DB가 열리면, 상단의 속성(property) 목록에서 유형 또는 타입 속성을 찾는다.
4. 테이블 뷰라면 칼럼 헤더에 속성 이름이 보인다.
5. 보드 뷰라면 그룹 기준이 유형 속성인 경우가 많다.
6. 그 속성의 선택 옵션(select options) 목록을 확인한다.
7. 속성 이름을 클릭한다.
8. [속성 편집] → 선택 옵션 목록이 나타난다.
9. 나열된 옵션을 메모장에 순서대로 적는다.

5. "룰_작업기록.md"의 “카테고리 번호표” 아래에 읽어 온 값을 적는다.

## 카테고리 번호표
1. 공통 (소스에 없어도 항상 1번)
2. 벤치마킹
3. 와이어프레임
4. 시안
5. 프로토타입

위 예시에서 2~5번은 Notion DB의 유형 속성에서 읽어 온 값이다. 1번 “공통”은 소스에 없어도 항상 넣는다. 여러 단계에 걸치거나 단계와 무관한 룰이 여기에 들어간다.

6. 파일을 저장한다.

2.3 – Figma 디자인시스템에서 토큰 확인하기

디자인시스템(design system)은 색상, 글꼴, 여백, 브레이크포인트 같은 디자인 규칙을 모아 둔 파일이다. 이 파일에 정해 둔 값(토큰)을 시안이 제대로 따르는지 비교하면, 3번 묶음에서 불일치를 찾을 재료가 된다.

1. 브라우저에서 Figma 탭으로 전환한다.
2. 환경 카드에 적은 Figma 디자인시스템 URL을 주소창에 붙여 넣고 Enter를 누른다.
3. 디자인시스템 파일이 열리면, 왼쪽 사이드바에서 아래 항목을 찾아 값을 확인한다.
4. 색상(Color): Primary, Secondary, Background 등의 헥스 코드.
5. 타이포그래피(Typography): 폰트 이름, 크기(px), 행간(line-height).
6. 브레이크포인트(Breakpoint): 반응형 기준 폭(예: 768px, 1024px).
7. 여백·컨테이너(Spacing/Container): 최대 폭, 기본 패딩.
8. 확인한 토큰을 "룰_작업기록.md" 파일 아래에 적는다.

## 디자인시스템 토큰 (Figma에서 읽음)
- Primary: #3B82F6
- Secondary: #10B981
- Font: Pretendard, 16px / 1.5
- Breakpoint: 768px, 1024px, 1280px
- Container max-width: 1200px, padding 24px

위 값은 예시다. 팀의 디자인시스템에서 실제 값을 읽어 적는다.

5. 파일을 저장한다.

2.4 – 불일치 찾기

디자인시스템 토큰(스펙)과 실제 시안(구현)을 비교해 어긋나는 지점을 찾는다. 이 불일치 목록이 4번 묶음에서 룰을 만드는 재료가 된다.

1. 브라우저에서 Figma 탭을 하나 더 열고, 환경 카드에 적은 Figma 시안 URL을 주소창에 붙여 넣고 Enter를 누른다.
2. 시안 파일이 열리면, 디자인시스템 탭과 시안 탭을 나란히 놓고 비교한다.
3. 아래 항목을 하나씩 대조한다.
4. 시안의 Primary 색상이 디자인시스템의 Primary 헥스 코드와 같은지.
5. 시안의 본문 폰트 크기가 디자인시스템의 Typography 값과 같은지.
6. 시안의 레이아웃이 디자인시스템의 브레이크포인트 기준 폭에서 잘 나뉘는지.
7. 시안의 컨테이너 최대 폭이 디자인시스템 값과 같은지.
8. AI 대화창에 아래 프롬프트를 붙여 넣어 체계적으로 점검받는다.

디자인시스템(스펙)과 시안(실제)의 불일치를 찾아줘.

디자인시스템 토큰:
{룰_작업기록.md에서 "디자인시스템 토큰" 부분을 복사해 넣는다}

시안에서 확인한 실제 값:
{시안을 보고 확인한 색상·폰트·여백 값을 적는다}

불일치 목록을 아래 형식으로 정리해줘:
- 항목 | 디자인시스템 값 | 시안 실제 값 | 차이

5. AI가 정리한 불일치 목록을 "룰_작업기록.md" 파일 아래에 붙여 넣는다.

## 불일치 목록 (사건 후보)
| 항목 | 디자인시스템 값 | 시안 실제 값 | 차이 |
|------|----------------|-------------|------|
| Primary 색상 | #3B82F6 | #2563EB | 헥스 코드 다름 |
| 본문 폰트 크기 | 16px | 14px | 2px 차이 |
| 컨테이너 max-width | 1200px | 1280px | 80px 차이 |

6. 파일을 저장한다.

이 불일치 목록에서 하나를 골라 4번 묶음에서 첫 룰을 만든다. 불일치가 없으면 Notion 할일 DB에서 상태·담당·마감 스키마를 확인하고, 카드 작성 규칙이 지켜지지 않는 사례를 사건 후보로 쓸 수 있다.

실습 코칭 프롬프트

이 묶음에서 룰 ID 형식 확정, Notion DB 카테고리 읽기, Figma 토큰 확인, 불일치 목록 작성을 마쳤다. 아래 프롬프트를 AI에 붙여 넣으면 작업 결과를 한 단계씩 점검받을 수 있다.

아래는 "팀 협업 룰 생성기" 실습의 두 번째 묶음(룰 ID 형식 + 소스 연동 + 불일치 찾기)을 점검받기 위한 요청이다.

점검 대상:
- 룰 ID 형식(숫자-하이픈, 경로별 표기)
- 카테고리 번호표(Notion DB에서 읽은 값)
- 디자인시스템 토큰(Figma에서 읽은 값)
- 불일치 목록(스펙과 시안의 차이)

행동 규칙:
- 답을 통째로 주지 않는다.
- 카테고리 번호표를 보고, 작업 단계가 아닌 값이 섞이지 않았는지 짚는다.
- ID 형식이 팀 도구에서 깨지지 않는지 확인한다.
- 불일치 목록이 비어 있으면, Notion 할일 DB 스키마에서 사건 후보를 찾는 방법을 한 단계씩 안내한다.
- 점검이 끝나면 "소스 연동이 끝났다. 다음은 불일치 하나를 골라 첫 룰을 만들 차례다"로 마무리한다.

내 작업 결과:
{여기에 룰_작업기록.md의 "룰 ID 규칙"부터 "불일치 목록"까지 전체 내용을 붙여 넣는다}

지금 막힌 부분:
{막힌 게 없으면 "없음". 있으면 구체적으로 적는다}

1. {여기에 룰_작업기록.md의...} — 룰_작업기록.md에서 “룰 ID 규칙”부터 “불일치 목록”까지를 복사해 넣는다.
2. {막힌 게 없으면...} — 예: Notion DB에 유형 속성이 없어서 카테고리를 못 읽었다.

3 – 첫 룰 만들기와 매핑

불일치 목록이 준비됐으니 그 가운데 하나를 골라 첫 룰을 만든다. 룰은 추상적인 원칙이 아니라 실제 사건에서 나온다. 사건 하나를 기록하고 룰로 바꾸는 과정을 한 번 해 보면, 이후에 새 사건이 생길 때마다 같은 방법으로 룰을 늘릴 수 있다. 룰을 만든 다음에는 산출물과 연결하는 매핑표까지 완성한다.

3.1 – 사건 기록하기

2번 묶음에서 만든 불일치 목록 중 하나를 골라 사건으로 기록한다.

1. "룰_작업기록.md" 파일을 연다.
2. 파일 아래에 다음 템플릿을 붙여 넣는다.

## 사건 기록

### 사건 1
- 무슨 일이 있었나 (사실만):
- 어떤 축의 문제인가: [ ] 지식(몰라서)  [ ] 검증(안 맞춰봐서)
- 근본 원인:

3. 불일치 목록에서 하나를 고른다. 예를 들어 “시안의 Primary 색상이 디자인시스템과 다르다”를 골랐다면 아래처럼 채운다.

### 사건 1
- 무슨 일이 있었나 (사실만): 시안의 Primary 색상이 #2563EB인데, 디자인시스템에는 #3B82F6으로 정해져 있다.
- 어떤 축의 문제인가: [x] 검증(안 맞춰봐서)
- 근본 원인: 시안 작업 시 디자인시스템 토큰을 확인하지 않고 색상을 직접 입력했다.

사건에는 두 가지 축이 있다. 지식 축은 “무엇이 맞는지 몰라서” 생긴 문제이고, 검증 축은 “맞는 값을 알지만 맞춰 보지 않아서” 생긴 문제다. 하나를 골라 표시한다. 위 예시는 디자인시스템에 값이 정해져 있었지만 시안 작업 시 확인하지 않은 경우라 검증 축이다.

4. 파일을 저장한다.

3.2 – 룰 도출하기

기록한 사건을 룰로 바꾼다. 룰에는 지식(무엇이 맞는가)과 검증(어떻게 확인하는가) 두 부분이 모두 들어간다.

1. 사건 기록 아래에 다음 템플릿을 붙여 넣는다.

## 룰 도출

### 룰 [ID] - [이름]
- 카테고리: (카테고리 번호표에서 고른다)
- 지식 (무엇이 맞는가, 처음 보는 사람도 알게):
- 검증:
    · 사람이 눈으로 볼 것:
    · AI 프롬프트에 넣을 것:
    · 테스트 태그:
- 적용 시점:

2. AI 대화창에 아래 프롬프트를 붙여 넣어 룰을 도출한다.

아래 사건을 룰로 바꿔줘.

사건:
{사건 기록에서 "무슨 일이 있었나", "축", "근본 원인"을 복사해 넣는다}

카테고리 번호표:
{카테고리 번호표를 복사해 넣는다}

아래 템플릿에 맞춰 작성해줘:
- 룰 ID / 이름: (카테고리 번호-룰번호, 한글 이름 병기)
- 카테고리: 번호표에서 고른다. 한 단계에만 걸리면 그 단계, 여러 단계면 1 공통.
- 지식 (무엇이 맞는가, 처음 보는 사람도 알게):
- 검증:
    · 사람이 눈으로 볼 것:
    · AI 프롬프트에 넣을 것:
    · 테스트 태그: @r[ID]
- 적용 시점:

3. AI 응답에서 나온 룰을 검토한다. 아래 세 가지를 확인한다.
4. 룰 ID가 카테고리 번호표의 번호를 쓰고 있는가.
5. 지식 부분이 처음 보는 사람도 이해할 수 있게 적혔는가.
6. 검증 부분에 구체적으로 어떻게 확인하는지가 적혔는가.
7. 검토한 룰을 "룰_작업기록.md"에 채워 넣는다. 예시:

### 룰 [4-1] - 시안 색상 토큰 준수
- 카테고리: 4. 시안
- 지식: 시안에 쓰는 모든 색상은 디자인시스템의 Color 토큰 헥스 코드를 그대로 쓴다. 직접 입력하지 않고 Figma 스타일 라이브러리에서 가져온다.
- 검증:
    · 사람이 눈으로 볼 것: 시안의 색상 값을 클릭해 헥스 코드가 디자인시스템과 같은지 대조한다.
    · AI 프롬프트에 넣을 것: "시안 파일의 모든 색상 값을 추출해서 디자인시스템 토큰과 대조해줘"
    · 테스트 태그: @r4-1
- 적용 시점: 시안을 디자인 리뷰에 올리기 전

5. 파일을 저장한다.

한 가지 사건에서 하나의 룰이 나왔다. 이후에 새 사건이 생기면 같은 과정(사건 기록 → 룰 도출)을 반복해 룰을 늘린다.

3.3 – 산출물-룰 매핑표 만들기

매핑표(mapping table)는 산출물마다 지켜야 할 룰과 검증 태그를 연결한 표다. 룰이 검증 기준이고, 산출물은 그 기준을 통과하는지 여부로 판정된다.

1. "룰_작업기록.md" 파일 아래에 다음 템플릿을 붙여 넣는다.

## 산출물-룰 매핑표

| 산출물 | 트랙 | 관련 파일명 | 지켜야 할 룰 | 검증 태그 |
|--------|------|------------|-------------|----------|
|        |      |            |             |          |

2. AI 대화창에 아래 프롬프트를 붙여 넣는다.

우리 산출물 목록과 만든 룰을 하나의 매핑표로 이어줘.

산출물 목록: {환경 카드의 주요 산출물}

만든 룰:
{룰_작업기록.md에서 룰 도출 부분을 복사해 넣는다}

표 열: 산출물 | 트랙 | 관련 파일명 | 지켜야 할 룰 | 검증 태그(@r)

원칙:
- 룰이 검증 기준이고, 산출물은 통과 여부로 판정된다
- 아직 룰 없는 칸은 [미정]으로 둔다
- 디자인시스템이 스펙의 원천이다

3. AI 응답에서 나온 매핑표를 "룰_작업기록.md"에 채워 넣는다. 예시:

## 산출물-룰 매핑표

| 산출물 | 트랙 | 관련 파일명 | 지켜야 할 룰 | 검증 태그 |
|--------|------|------------|-------------|----------|
| 벤치마킹 | 리서치 | benchmarking.md | [미정] | - |
| 와이어프레임 | 설계 | wireframe.fig | [미정] | - |
| 시안 | 디자인 | visual-design.fig | [4-1] 시안 색상 토큰 준수 | @r4-1 |
| 프로토타입 | 개발 | prototype.fig | [미정] | - |

4. 파일을 저장한다.

[미정]으로 남겨 둔 칸은 나중에 그 산출물에서 사건이 생길 때 채운다. 지금은 룰이 있는 산출물만 연결하면 된다.

1. 환경 카드의 주요 산출물이 매핑표에 빠짐없이 들어갔는가.
2. 만든 룰이 맞는 산출물에 연결됐는가.
3. 검증 태그(@r)가 룰 ID와 일치하는가.
4. 룰이 없는 칸에 [미정]이 적혀 있는가.
5. 산출물 이름이 팀에서 실제로 부르는 이름과 같은가.

3개 이상 맞으면 매핑표를 바로 쓸 수 있다.

실습 코칭 프롬프트

이 묶음에서 사건 기록, 룰 도출, 매핑표 작성을 마쳤다. 아래 프롬프트를 AI에 붙여 넣으면 첫 룰과 매핑표를 한 단계씩 점검받을 수 있다.

아래는 "팀 협업 룰 생성기" 실습의 세 번째 묶음(사건→룰 + 매핑표)을 점검받기 위한 요청이다.

점검 대상:
- 사건 기록(무슨 일, 축, 근본 원인)
- 룰 도출(ID, 지식, 검증, 적용 시점)
- 산출물-룰 매핑표

행동 규칙:
- 답을 통째로 주지 않는다.
- 사건 기록에서 사실과 의견이 섞이지 않았는지 짚는다.
- 룰의 지식 부분이 처음 보는 사람도 이해할 수 있는지 확인한다. 모호하면 "어떤 부분이 모호한지" 힌트를 주고 내가 고치게 한다.
- 검증 부분이 구체적인지 확인한다. "확인한다"만 적혀 있으면 "무엇을 어떻게 확인하는지"를 물어 내가 보완하게 한다.
- 매핑표에서 룰이 엉뚱한 산출물에 연결됐거나, 빠진 산출물이 있으면 짚는다.
- 점검이 끝나면 "첫 룰과 매핑표가 완성됐다. 앞으로 새 사건이 생기면 사건 기록→룰 도출→매핑표 갱신을 반복한다"로 마무리한다.
- 자주 놓치는 실수: 룰의 지식 부분에 "알아서 하면 된다" 같은 모호한 표현이 들어가는 것, 검증에 구체적인 방법 없이 "확인한다"만 적는 것을 발견하면 짚는다.

내 작업 결과:
{여기에 룰_작업기록.md의 "사건 기록"부터 "매핑표"까지 전체 내용을 붙여 넣는다}

지금 막힌 부분:
{막힌 게 없으면 "없음". 있으면 구체적으로 적는다}

1. {여기에 룰_작업기록.md의...} — 룰_작업기록.md에서 “사건 기록”부터 “매핑표”까지를 복사해 넣는다.
2. {막힌 게 없으면...} — 예: 사건을 지식 축과 검증 축 중 어디에 넣을지 모르겠다.

아래는 변수를 실제 값으로 채운 예시다.

아래는 "팀 협업 룰 생성기" 실습의 세 번째 묶음(사건→룰 + 매핑표)을 점검받기 위한 요청이다.

점검 대상:
- 사건 기록(무슨 일, 축, 근본 원인)
- 룰 도출(ID, 지식, 검증, 적용 시점)
- 산출물-룰 매핑표

행동 규칙:
- 답을 통째로 주지 않는다.
- 사건 기록에서 사실과 의견이 섞이지 않았는지 짚는다.
- 룰의 지식 부분이 처음 보는 사람도 이해할 수 있는지 확인한다. 모호하면 "어떤 부분이 모호한지" 힌트를 주고 내가 고치게 한다.
- 검증 부분이 구체적인지 확인한다. "확인한다"만 적혀 있으면 "무엇을 어떻게 확인하는지"를 물어 내가 보완하게 한다.
- 매핑표에서 룰이 엉뚱한 산출물에 연결됐거나, 빠진 산출물이 있으면 짚는다.
- 점검이 끝나면 "첫 룰과 매핑표가 완성됐다. 앞으로 새 사건이 생기면 사건 기록→룰 도출→매핑표 갱신을 반복한다"로 마무리한다.
- 자주 놓치는 실수: 룰의 지식 부분에 "알아서 하면 된다" 같은 모호한 표현이 들어가는 것, 검증에 구체적인 방법 없이 "확인한다"만 적는 것을 발견하면 짚는다.

내 작업 결과:
## 사건 기록
### 사건 1
- 무슨 일이 있었나: 시안의 Primary 색상이 #2563EB인데, 디자인시스템에는 #3B82F6으로 정해져 있다.
- 축: 검증(안 맞춰봐서)
- 근본 원인: 시안 작업 시 디자인시스템 토큰을 확인하지 않고 색상을 직접 입력했다.

## 룰 도출
### 룰 [4-1] - 시안 색상 토큰 준수
- 카테고리: 4. 시안
- 지식: 시안에 쓰는 모든 색상은 디자인시스템의 Color 토큰 헥스 코드를 그대로 쓴다.
- 검증:
    · 사람: 시안의 색상 값을 클릭해 헥스 코드가 디자인시스템과 같은지 대조한다.
    · AI: "시안 파일의 모든 색상 값을 추출해서 디자인시스템 토큰과 대조해줘"
    · 태그: @r4-1
- 적용 시점: 시안을 디자인 리뷰에 올리기 전

## 매핑표
| 산출물 | 트랙 | 파일명 | 룰 | 태그 |
| 벤치마킹 | 리서치 | benchmarking.md | [미정] | - |
| 시안 | 디자인 | visual-design.fig | [4-1] | @r4-1 |

지금 막힌 부분:
없음

여기까지 마치면 환경 카드 1장, 카테고리 번호표 1장, 세부 룰 1개, 매핑표 1장이 "룰_작업기록.md" 파일에 모두 들어 있다. 이후 프로젝트를 진행하며 새 문제가 생기면 사건 기록 → 룰 도출 → 매핑표 갱신을 반복한다. 한 바퀴를 돌 때마다 팀의 룰이 한 줄씩 늘어난다.