Imported from leh60245/task-sizing-kit (skills/task-sizing/SKILL.md). Install upstream with npx skills add leh60245/task-sizing-kit --skill task-sizing. Copyright stays with the author.

작업 사이징

답하는 것은 "몇 시간 걸리나"가 아니라 "오늘 안에 안 끝날 확률이 높은가"다. 시간 점추정은 이 데이터로 못 준다(전형 오차 2배 초반). 꼬리만 본다.

자료 위치

수치편이 없는 프로젝트면 일반편의 규칙만 쓰고 "이 프로젝트는 기준선이 없어 일반 규칙으로만 판정했다"를 출력에 명시한다. 없는 숫자를 다른 프로젝트에서 빌려오지 마라.

🔴 언제 스스로 발동하는가 — 말이 아니라 사건으로

2026-09-01 실측: 계측 착수 후 닷새 동안 PR 27건이 머지됐는데 원장 항목은 0건이었다. 「사이징해줘」를 기다리면 아무것도 안 쌓인다. 실제 작업은 그 말 없이 시작되기 때문이다. 그래서 말이 아니라 사건으로 발동한다.

보드가 계획의 유일한 자리다 (2026-09-04 부터). 리포 안에 「다음에 뭘 하나」 문서를 만들지 않는다 — 같은 날 만든 폴더를 같은 날 폐기했다(다른 채팅이 폴더만 보고 보드를 놓친다). Status 의 뜻은 Todo = 백로그(시작 없음) / In Progress = 진행 중 / Done = 끝. 계측 통계는 시작 이 있는 항목만 센다.

훅이 집행하는 사건 (my-career-ai, 2026-09-04 부터) — 문서만으로는 닷새에 27건, 다음 주에 28건이 샜기 때문이다. 워크트리 생성 → 초안을 만들라는 알림(H2) · PR 생성 → 제목에 (PR #N) 붙이라는 알림(H3) · PR 머지 → 원장에 #N 이 든 항목이 없으면 거부(H1). 그래서 PR 이 생기면 그 즉시 원장 항목 제목에 (PR #N) 을 붙인다 — 안 붙이면 머지가 막힌다. 다른 프로젝트에는 훅이 없으니 이 표만이 규칙이다.

⛔ 기록 없이 PR 이 머지되면 그 자체가 결함이다. 세션 끝에 「이번에 만든 PR 중 원장에 없는 것」이 있으면 그 자리에서 채운다.

⛔ 코드 변경 0줄이어도 조사는 기록한다. 조사 세션은 브랜치도 PR 도 남기지 않아서, 사건 표에 없으면 영영 안 쌓인다 — 수치편의 조사·R&D 칸이 표본 17건에 「기준선 없음」인 이유가 이것이다 (2026-09-01 확인: 그날의 49분짜리 조사도 사용자가 "마무리"라고 말해 준 덕에 겨우 기록됐다). 그 칸을 채우는 유일한 방법은 조사할 때마다 1건씩 남기는 것이다.

⚠️ 발동해도 30초를 넘기지 마라. 이 의식이 무거워 보이면 다음번에 또 건너뛴다. 판정이 애매하면 멈추지 말고 섞였다 로 적고 진행한다 — 빈 원장보다 거친 라벨이 낫다.

사후에 채운 값은 그렇게 표시한다. 「착수 시점의 추정」과 「끝나고 복원한 값」은 다른 데이터다. 복원한 것이면 추정(분) 을 비워 둔다 — 채우면 추정 정확도 통계가 오염된다.

다섯 가지 상황

① 작업 착수 — "사이징해줘"

판정은 「내가 어느 파일을 열 것인가」로만 한다. 제목·브랜치명 키워드로 판정하지 마라 — 실측 정확도가 기저율보다 9%p 높을 뿐이고 그 라벨로는 배수가 1.04로 붕괴한다. 어느 파일을 열지 모르겠으면 먼저 찾아보고 나서 판정한다.

수치편의 Q1-Q7 을 순서대로 적용한 뒤 아래 형식 그대로 출력한다.

📏 <작업 한 줄>

위험    외부·상태          ← Q2 (payments 를 연다)
규모    중 (100-500줄 예상)
추정    35분 · 1시간 초과 확률 12%
라운드  authoring

⚠️ 지금 17:40 — 「퇴근 90분 전엔 시작하지 마라」에 걸립니다.

→ Project #7 에 기록했습니다. 틀린 칸이 있으면 말씀해 주세요.

규칙:

• 경고 줄은 걸릴 때만 넣는다. 안 걸리면 통째로 뺀다
• 「우리 코드 안」이면 배수를 곱하지 않는다
• 배수를 두 번 곱하지 마라 — 규모를 모른 채 잡을 때만 2.1배, 규모를 이미 반영했으면 1.4배
• 규모가 크면(650줄 이상 예상) 2배가 아니라 2.6배
• 판정이 갈리면 높은 쪽. 그래도 못 고르겠으면 억지로 고르지 말고 섞였다로 기록한다

② 라운드 시작 — "라운드 시작", "이거 큰 작업이야"

🎯 라운드 「report-authoring」

비슷한 과거   관리자 콘솔 리포트 제작 = PR 24건 / 4일
거친 추정     조각 15-30개 · 3-5일
리스크        외부·상태 (조각 다수가 Q1 마이그레이션)  · Q6 외부대기: 예
집중도        라운드가 하루를 독차지하지 않습니다 (과거 4일간 절반이 다른 일)
단계          논의·정의 (항상) · 와이어프레임 (새 화면) · 부분 ERD (Q1)
PRD           켬 제안 (새 도메인 신설) — 확정해 주세요

명세화가 끝나면 다시 재겠습니다 — 그때 정확해집니다.
브랜치는 authoring/* 로 짓겠습니다.
라운드 폴더 docs/superpowers/rounds/authoring/ 을 만들었습니다 (ROUND.md · 01-discussion.md).

→ Project #7 에 기록했습니다 (층=라운드).

세 줄을 빠뜨리지 마라 — 실제로 빠졌던 곳들이다.

1. → Project #7 에 기록했습니다 (층=라운드) — 라운드도 원장에 남아야 한다. 안 남기면 "이 라운드 실제로 며칠 걸렸나"가 사라지고, 다음 라운드도 영영 "기준선 없음"이다.
2. 거친 추정 에 날짜를 넣어라. 기준선이 없어 못 내겠으면 조각 수만 적고 끝내지 말고 며칠인지는 모릅니다 — 이 라운드가 첫 표본이 됩니다 라고 명시한다.
3. 리스크 칸에 값을 두 개 넣지 마라. 원장 필드가 단일 선택이다. 위험은 우리코드안 / 외부상태 / 섞였다 중 하나, Q6 는 같은 줄 뒤에 · Q6 외부대기: 예/아니오 로 따로 적는다.

단계 줄과 라운드 폴더 — 이것도 빠뜨리지 마라.

• 트리거 단계는 자동으로 켜고 근거를 괄호에 병기한다 (와이어프레임·API·부분 ERD·상태 조합 표·시퀀스). 조건은 수치편 §7-1 이 소유한다 — 여기 적어 두지 않는다.
• PRD 만 사용자가 확정한다. 기본값(새 도메인 신설 / 크기 문턱 — 값은 수치편 §7-1)을 제안하고 "확정해 주세요"로 끝낸다.
• 한 방향 래칫: 논의·정의를 진행하다 트리거가 새로 보이면 그 자리에서 켠다고 말하고 ROUND.md 에 적는다. 내리지는 않는다.
• 라운드 폴더를 만든다 (경로는 수치편 §7-1). ROUND.md 는 아래 틀 그대로, 01-discussion.md 에는 논의 전문을 화자 표기로 이어 붙인다 — append-only, 구현 후 고치지 않는다.
• 결정 줄마다 누가 정했는지 표기한다 — 무표시는 위반이다 (2026-09-05 🧑 요청: "이해해서 더 말을 안 한 건지, 체크를 안 한 건지"를 나중에 구분하려면 Claude 가 정한 것도 명시해야 한다. 포트폴리오용 AI 협업 증거이기도 하다). 🧑 사람이 직접 정함 · 🧑! 사람이 정했고 Claude 추천과 달랐음 · 🧑✓ Claude 추천을 사람이 내용을 보고 채택(메시지가 선택지·이유·조건·질문을 짚음) · 🧑⏩ 사람이 읽지 않고 위임("권장대로"·"진행"·"알아서" — 내용을 짚지 않은 승인. 사용자가 "위임"이라 말하면 그대로) · 🤖 Claude 가 정했고 사람이 확인하지 않음(관례·기본값). 라운드를 닫을 때(③) 🧑⏩·🤖 줄을 사람에게 읽어 주고 확인되면 🧑✓ 로 바꾼다 — 「이해했는가」를 묻는 유일한 순간이다. my-career-ai 에서는 편집 훅이 경고하고 CI(round-caps.test.mjs)가 막는다.
• 원장에 층=작업 · 단계=명세 항목을 하나 만든다 (시작 시각 기입). 첫 구현 브랜치를 만들 때 그 항목을 닫는다(종료·실제분). 이 항목이 "게이트가 우리를 다시 느리게 만들었나"를 4주 뒤 판정하는 유일한 근거다.

ROUND.md 틀:

# 라운드 <슬러그>

**목표**: <한 줄>

## 게이트
- 논의·정의: 항상
- <단계>: 켬 (<근거>) / 안 켬
- PRD: 🧑 켬/안 켬 (<근거>)

## 결정
- 🧑 <결정> (<날짜>)

## 산출물
| 파일 | 상태 |
|---|---|
| 01-discussion.md | 진행 중 |

ROUND.md 상한 — 50줄 · 4,500자 · 백틱 0 (2026-09-05). 사람이 읽는 한 화면이다. PR 번호·함수 이름·마이그레이션 ID·긴 표는 같은 폴더의 ROUND-ref.md 로 내린다. my-career-ai 에서는 편집 훅이 경고하고 CI(round-caps.test.mjs)가 막는다 — quota-billing-clock 의 ROUND.md 가 100줄짜리 참조 문서로 자라 사람이 읽지 못했던 실측에서 나온 상한이다.

착수 시점에 못 맞히는 것은 정상이다. 명세화 산출물이 조각 개수를 확정해 준다. 이 2단 구조를 매번 말해 줘서 "왜 처음엔 못 맞혔지"를 자책하지 않게 한다.

기준선이 없을 때가 오히려 중요하다. 그 라운드가 그 종류의 첫 표본이므로 종료 시 실제 소요를 반드시 기록한다 — 그래야 다음번에 "기준선 없음"이 사라진다.

③ 작업 종료 — 머지했거나 "끝났어"

✅ 종료 — 실제 52분 (추정 35분, 1.5배)

추정을 넘겼습니다. 사유가 어느 쪽인가요?
외부대기 / 재작업 / 범위확장 / 병행전환

• 추정 안에 들었으면 사유를 묻지 않는다. 조용히 기록만 한다
• 시작·종료 시각을 원장에 기입한다

④ 우선순위 — "뭐부터 할까", "이거랑 저거 중에"

RICE = (R × I × C) ÷ E. E 는 사이징 결과가 그대로 들어가므로 자동이고, 사람은 R·I·C 세 개만 고른다. 척도는 수치편 §5-2.

🔢 우선순위 (라운드끼리)

    RICE   R          I     C     E
1.  4.8    회원전체   큼    보통  5조각   자소서 프롬프트 포팅
2.  2.4    유료회원   큼    확실  10조각  결제 재시도 UX
3.  0.6    운영자만   중간  추측  20조각  콘솔 지표 확장

⚠️ 1위가 감과 다르면 말씀해 주세요 — R·I·C 중 무엇을 잘못 골랐는지가 거기서 나옵니다.

⛔ 세 가지 오용을 반드시 지켜라

1. 층이 다르면 비교하지 마라. 라운드의 E 는 조각 수, 작업의 E 는 시간이라 단위가 다르다.
2. 점수를 명령으로 읽지 마라. E 가 분모라 작은 일을 체계적으로 위로 올린다. 그대로 따르면 큰 일이 영영 착수되지 않는다. 점수는 눈금이지 답이 아니다. 사용자의 감과 다르면 뒤집으라고 하지 말고 왜 다른지 물어라.
3. 마감이 있는 일은 RICE 밖이다. 날짜가 정한다. 점수로 뒤집지 마라.

⑤ 하루 용량 — "오늘 뭐 할까", "용량"

📊 오늘 08-28 (목)

용량      5.5h (마감 약속엔 4.5h)
기록됨    2.3h / 4건
남음      3.2h — 꼬리 1건 자리 1.5h 를 떼고 1.7h

RICE 상위    ① 자소서 프롬프트 포팅 (40분)  ② 결제 재시도 UX (1.2h)

순서를 지켜라 — 꼬리 자리를 먼저 떼고 남은 용량에 RICE 순으로 채운다. 반대로 하면 RICE 상위가 대개 작은 일이라 하루가 그것들로 차고 큰 일이 항상 밀린다. 하루 시간의 33.6%가 상위 5.8% 작업에 몰린다.

원장 기록

Project #7 필드 17종 (Status 는 GitHub 기본 필드):

Q6외부 를 빠뜨리지 마라. Q6 는 시간 예산을 안 올리지만, 4주 뒤 「경계통과」 티어를 되살릴지 판정하는 유일한 근거다. 안 세면 그 판정을 영영 못 한다.

착수 시 초안 항목(draft)을 만든다 — 레포 이슈를 만들지 않는다. PR 이 열리면 링크한다.

GH="/c/Program Files/GitHub CLI/gh.exe"
"$GH" project item-create 7 --owner leh60245 --title "<작업 한 줄>" --format json
"$GH" project item-edit --project-id <PVT_...> --id <item> --field-id <PVTF_...> --text "..."

필드 ID 는 "$GH" project field-list 7 --owner leh60245 로 그때 조회한다. 여기 적어 두지 않는다 — 적어 두면 필드를 다시 만들었을 때 조용히 틀린 칸에 쓴다.

라운드 경계

1. 라운드 시작 시 사용자가 한 번 선언한다
2. 이후 브랜치 이름에 라운드 슬러그를 넣는다 — 브랜치는 어차피 Claude 가 지으므로 사용자 손이 안 든다
3. 슬러그 없는 브랜치는 무소속으로 둔다
4. 주간 동기화가 "무소속 N건" 을 목록으로 띄운다 — ⛔ 조용히 통과시키지 마라

⛔ 하지 말 것

전부 PR 513건 실측으로 뒤집힌 것들이다. 근거는 docs/design/2026-08-27-findings.md.

• 유형 × 리스크 격자를 만들지 마라. 예측력 개선 0이고 고위험 칸이 반대 방향으로 안심시킨다
• 유형과 리스크를 곱하지 마라. 유형은 참고값, 리스크는 경고등이다
• P80 을 안전 버퍼로 쓰지 마라. 초과분 평균이 P80 의 2배가 넘는다
• 칸별 P50 을 합산해 하루 계획을 세우지 마라. 실측에서 중앙 2.15배 부족했고, 깊은 작업일에는 8-13배 틀렸다
• 변경 규모로 위험을 가늠하지 마라. 1파일 15줄이 청구 경로일 수 있다
• 없는 숫자를 만들지 마라. 표본 5건 미만이면 "기준선 없음"이라고 쓴다
• 사전 산출물(정의·와이어프레임·계약 표)을 구현 후 갱신하지 마라. 달라진 결정은 ROUND.md 에 한 줄로

출력 길이

위 형식보다 길게 쓰지 마라. 30초짜리 의식이 목적이다. 근거를 설명하고 싶으면 한 줄로 줄이거나, 사용자가 물을 때만 편다.