---
title: "work-pilot"
description: "작성된 제안서·과제 신청서(또는 아이디어)를 Claude Cowork 안에서 실제로 돌아가는 파일럿으로 만드는 스킬입니다. ① 각 단계를 \"Cowork 가능 / 수동 브릿지 / 시스템 연동(IT 과제)\"으로 정직하게 판별해 실현 계획을 세우고 ② 실데이터가 없으면 현실적인 모의 데이터를 만들어(실명 금지, 자체 점검) ③ 전 과정을 1회전 실행해 일치율을 실측한 뒤 ④ 검증된 절차를 팀 커스텀 스킬(SKILL.md)로 굳힙니다. \"신청서 다음 뭘 해야 해?\", \"이거 실제로 만들어보자\", \"파일럿 돌려보자\", \"이 업무 스킬로 만들어줘\"처럼 말하면 됩니다. work-proposal 산출물이 이상적 입력입니다."
pack: itda-work
slug: work-pilot
status: stable
tags: ["pilot", "feasibility", "mock-data", "proof-of-concept", "skill-authoring"]
---
# work-pilot — 제안을 "실제로 돌아가는 것"으로

제안서는 약속이고, 심사와 실무를 설득하는 건 **한 번이라도 실제로 돌아간 결과**다. 이 스킬은
Cowork 가 할 수 있는 것과 없는 것을 정직하게 가른 뒤, 없는 데이터는 모의로 만들어서라도
전 과정을 1회전시키고, 그 검증된 절차를 팀 스킬로 남긴다.

---

## Claude 오케스트레이션 지시서

> [HARD] **경계 정직성.** Cowork 가 할 수 없는 것(사내 시스템 자동 접속·정기 자동 실행·자동
> 발송 등)을 되는 것처럼 기획하지 않는다. 자동화 불가 단계는 반드시 "수동 브릿지" 또는
> "시스템 연동(IT 과제)"으로 명시한다. 경계 판별은 `references/cowork-boundary.md` 기준.
> [HARD] **모의 데이터에 실존 고객·실명·실연락처·실제 식별번호 금지.** 전부 가상으로 만든다.
> 실데이터를 쓸 때는 개인정보(이름·연락처·주소·식별번호) 마스킹을 먼저 안내하고 확인받는다.
> [HARD] **결과 과장 금지.** 파일럿 일치율·소요 시간은 실측값만 쓴다. 측정 전에 "성공"을
> 선언하지 않는다. **표본 10건 미만의 일치율은 "참고치(재측정 필요)"로만** 표기하고, 기준
> 보완 후의 재정렬은 "정답률 상승"이 아니라 **"판정 기준 합의"**로 서술한다.

### 관문1 — 실현 기획 (경계 판별)

1. 제안서(work-proposal 산출) 또는 아이디어를 받는다. 제안서가 없으면 핵심만 3문으로 수집:
   무엇을 자동화하나 / 입력 데이터는 무엇이고 어디에 있나 / 산출은 누구에게 어떤 형태로 가나.
2. 프로세스 각 단계를 **3분류 표**로 판별한다 (`references/cowork-boundary.md` 대조):

   | 단계 | 분류 | 파일럿에서의 처리 |
   |---|---|---|
   | 예: VOC 접수(웹 시스템) | 수동 브릿지 | 담당자가 엑셀 내보내기 → Cowork 업로드 |
   | 예: 분석·분류·근거 | Cowork 안 | AI 가 직접 수행 |
   | 예: 메일 발송 | 수동 브릿지 | AI 는 초안까지, 발송은 담당자 |
   | 예: 시스템 자동 수집 | 시스템 연동 | 파일럿 제외 — IT 과제로 §6 향후 계획에 기록 |

3. **파일럿 범위 확정** — "Cowork 안 + 수동 브릿지"만으로 시작→끝이 이어지는 최소 흐름을
   제시하고 사용자 컨펌을 받는다. 시스템 연동 항목은 버리지 말고 "확장 로드맵"으로 분리 기록.

### 관문2 — 데이터 준비

- **실데이터가 있으면**: 마스킹 안내([HARD]) 후 업로드 받는다. 10~50건이면 충분하다.
- **없으면 모의 데이터 생성**: 과제 도메인에 맞는 현실적 데이터셋을 만든다.
  - 규모 20~40건. **현실적 분포**(채널·유형·길이 편차) + **일부러 어려운 케이스 포함** —
    분류가 애매한 건 2~3건, 서로 유사한 중복 건 2~3건, 정보 부족 건 1~2건.
  - 부속 자료도 함께: 표준 기준 초안(예: VOC 분류 유형 5~8개 + 판단 기준 1줄씩),
    과거 이력 5~10건(유사 건 연결 시험용).
  - **생성 후 자체 점검 — 4항목 고정 체크리스트**(각 1줄 보고): ① 유형 분포 쏠림 없음(전
    유형 최소 2건) ② 기준으로 전건 분류 시도 가능(애매 건은 의도적임을 표시) ③ 실존
    고객·실명·실연락처 0 ④ 채널·길이 분포가 현실적.
  - 산출: CSV 또는 엑셀 파일(팀이 재사용할 수 있게).

### 관문3 — 파일럿 1회전 + 일치율 실측

1. 관문1 의 최소 흐름대로 **전건 처리**한다. 예(VOC): 건별 분류 + 판단 근거 1줄 + 유사 이력
   연결 + 부서 추천 → 결과표(표 형식) + 전달 메일 초안 2~3건 샘플. **애매하거나 정보가
   부족한 건은 임의 분류하지 않고 "판단보류(추가확인)" 큐로 분리**하고, 두 부서에 걸치는
   건은 **주관/협조 이원 표기**를 허용한다 — 애매 건 처리야말로 파일럿이 검증해야 할 핵심이다.
2. **일치율 실측** — 사용자에게 무작위 5~10건을 골라 "당신이라면 어떻게 분류했겠나"를 묻고,
   AI 판정과 대조해 일치율을 계산한다(제안서 §6 측정 지표의 리허설). 불일치 건은 **왜**
   갈렸는지 확인해 기준을 보완하고, 해당 건만 재분류해 개선을 보여준다(보완 루프 1회).
3. 산출 정리: 결과표 파일 + 일치율(실측) + 기준 보완 전/후 비교 + 남은 한계 목록.
   이것이 본선·실무 설득의 데모 자산이다.

### 관문4 — 스킬화 (팀 자산으로 굳히기)

파일럿으로 검증된 것만 스킬로 만든다 — 검증 안 된 기능을 스킬에 넣지 않는다.

1. **SKILL.md 초안 작성**: name(영문 kebab-case)·description(팀 동료가 쓸 한국어 트리거 포함)·
   지시서(파일럿에서 확정한 절차 그대로: 입력 계약 → 처리 규칙 → 출력 형식) + [HARD] 규칙
   (근거 없는 분류 금지 · 개인정보 마스킹 · 확신 없으면 "판단 보류"로 사람에게).
2. **기준은 참조 파일로**: 표준 분류 기준·템플릿은 `references/` 로 분리해 기준이 바뀌어도
   지시서를 안 고치게 한다.
3. **배포 안내**: ① 간단 공유 = 스킬 내용을 카드(프롬프트 문서)로 팀에 배포 ② 정식 =
   플러그인 zip 패키징 — **경로는 전부 ASCII**(한글 파일명 금지), **zip 루트에 플러그인
   폴더**(`zip -r x.zip <플러그인폴더>`) 구조로 만들어야 Cowork 설치가 된다.
4. **운영 루틴 제안**: 누가·언제(예: 매일 오전 접수분)·무엇을 올려 실행하고, 월 단위로
   §6 지표(처리 시간·일치율·오전달)를 집계하는 한 장 루틴을 함께 준다.

### 완료 보고

파일럿 범위 표(3분류) · 데이터셋 파일 · 결과표 + 일치율(실측) · 스킬 초안 · 운영 루틴 ·
확장 로드맵(시스템 연동 항목)을 정리해 제시한다.

---

## 파이프라인 (itda-work 업무 스킬 패밀리)

`work-find`(무엇을 풀지 발굴) → `work-proposal`(제안서로 구조화) → **`work-pilot`(파일럿 실증·스킬화)**.
계획·실행 관리로 가려면 `work-plan`(itda-work 팩). 앞 단계 산출 텍스트를 첨부하면 이어서 진행한다.

---

## 원칙

- **정직한 경계** — "Cowork 로 다 됩니다"가 아니라 "여기까지 되고, 여기는 사람, 여기는 IT 과제"
  가 신뢰를 만든다.
- **모의라도 끝까지** — 가상 데이터로라도 전 과정이 한 번 돌아야 진짜 문제(기준 모호·예외)가
  드러난다.
- **검증된 것만 스킬로** — 파일럿에서 확인 안 된 기능은 스킬에 넣지 않는다.