작업 병목 분석

왜 별도 스킬인가 — 시간 축이 다르다

비슷해 보이는 검토가 여럿 있으나 보는 시점이 다르다.

	시점	대상	묻는 것
실행 감시	실행 중	진행 상태	지금 방황하나
결과 검증	산출물 직후	개별 결과물	이게 진짜 됐나
병목 분석	여러 세션 누적 후	작업 흐름 전체	무엇이 우리를 느리게 했나

🔴 누적해야만 보이는 것이 있다. 실제 사례 — 어떤 프로젝트에서 최대 손실은
"에이전트 사용량 한도가 풀렸는데 아무도 재개시키지 않은 시간"(최대 14시간)이었다.
개별 작업을 아무리 들여다봐도 안 보이고, 여러 세션을 나란히 놓아야 드러난다.

발동 시점

• 사용자가 병목·회고·개선점을 요청할 때
• 큰 마일스톤이 끝났을 때 (요청이 없으면 제안만 한다)

⚠️ 대화 압축(compact) 예고 시에는 발동하지 않는다. 그 시점의 우선순위는 기록 보존이다.
압축 직전에는 병목 재료를 한 줄 남기는 것까지만 하고(→ 연계 절), 분석은 나중에 한다.

---

1. 재료를 모은다 — 기억이 아니라 기록에서

🔴 기억으로 쓰지 마라. 병목은 "답답했던 느낌"으로 남지만, 실제 손실은 기록에만 있다.

# 진행 문서·작업 로그에서 병목 신호어를 훑는다
grep -n "한도\|소진\|중단\|차단\|실패\|대기\|승인\|막힘\|blocked\|403\|401" <진행문서>

정량화할 수 있는 것을 우선 찾는다.

언제부터 언제까지 멈춰 있었나        ← 가장 값어치 있는 숫자
몇 번 반복됐나
산출물이 0인 채로 얼마나 돌았나

2. 네 갈래로 나눈다

갈래	무엇인가	전형적인 것
권한	규칙·승인·차단이 만든 정지	계정 금지 · 승인 대기 · 삭제 차단 · 샌드박스
사용자	사람만 할 수 있는 일의 대기	방향 결정 · 육안 확인 · 사용자만 아는 정보
에이전트	실행 주체의 한계	사용량 한도 · 루프 · 보고 유실 · 재검증 필요
외부	우리 밖의 사정	사이트 차단 · 자료 부재 · 환경 문제

한 병목이 두 갈래에 걸치면 둘 다 적고 주된 쪽을 고른다. 예를 들어 "한도 해제 후 방치"는
에이전트(한도)와 사용자(재개 지시)에 걸친다.

3. 🔴 없애면 안 되는 것을 먼저 가른다

이 단계가 이 스킬의 핵심이다. 병목을 전부 제거 대상으로 보면 품질 장치를 뜯게 된다.

필수 요소    없애면 결과물의 신뢰도가 떨어진다.  시간이 드는 것이 목적인 장치
개선 가능    품질과 무관하게 시간만 먹는다.      절차·도구로 줄일 수 있다
부분 개선    장치는 필요하나 운영 방식으로 비용을 줄일 수 있다

판별 질문: "이걸 없앴을 때 틀린 결과가 나갈 수 있는가?"

⚠️ 육안 확인·교차검증류는 거의 항상 필수다. 어떤 프로젝트에서 육안 확인 하나가
수치 검사를 전 항목 통과한 오류 4건을 잡았다. 느린 것이 아니라 그 느림이 일하는 것이다.

필수로 판정된 것은 줄이지 말고 앞으로 당길 궁리를 한다. 검증을 뒤에 두면 후보를 전부
만들고 나서 폐기하게 된다.

4. 우선순위는 효과 대비 비용으로

효과   회수되는 시간 (정량화한 숫자를 쓴다)
비용   그 조치를 도입하는 데 드는 것

대체로 상위는 "절차"이지 "도구"가 아니다. 새로 만들 것이 없고 지시서와 스킬에
한 줄씩 넣으면 되는 것들이 가장 크게 회수된다. 도구를 만들자는 결론이 상위에 몰리면
분석이 틀렸을 가능성을 의심한다.

5. 🔴 개선안을 이 스킬에 쌓지 마라

도출한 개선안은 그 일을 하는 업무 스킬·지시서에 반영한다. 병목 스킬에는
분석 절차만 남긴다.

✗ 병목 스킬에 "서브에이전트 병렬 금지" 를 적어 둔다   → 정작 일할 때 안 읽힌다
✅ 위임 지시서 템플릿과 위임 스킬에 넣는다             → 다음 위임에서 자동 적용된다

반영한 곳을 보고서에 적어 둔다. 다음 분석에서 "이건 이미 조치됐다"를 알 수 있어야 한다.

6. 보고 형식

0. 요약        — 순위표(병목 · 갈래 · 실측 손실 · 필수/개선)
1. 분류 기준   — 필수와 개선 가능을 무엇으로 갈랐는지
2~5. 갈래별    — 사례 · 실측 · 판정 · 개선안
6. 우선순위    — 효과 대비 비용
7. 이미 해결된 것  ← 재발 방지 확인용. 빠뜨리지 마라
8. 결론

§7이 중요하다. 같은 병목을 매번 새로 발견하는 것을 막는다.

---

하지 않는 것

• 개별 산출물의 옳고 그름을 판정하지 않는다 — 그건 결과 검증의 일이다
• 책임을 가리지 않는다. 누가 늦췄는지가 아니라 무엇이 늦췄는지를 본다
• 추정 손실을 숫자로 쓰지 않는다. 기록에 없으면 "미측정"이라고 적는다

연계

• 실행 중 방황 감지는 위임·감시 스킬 쪽 — 이 스킬은 사후 회고다
• 개별 산출물 검증은 결과 검증 스킬 쪽
• 압축 체크포인트 스킬과는 역할을 나눈다 — 압축 직전에는 *"막혔던 것·기다린 것"*을
  한 줄 남기는 것까지만 하고, 그 기록이 다음 병목 분석의 재료가 된다
• 도출된 개선안의 반영처는 그 일을 하는 업무 스킬 (§5)

이력 (필수 기록)

• 생성일: 2026-09-08
• 업데이트 횟수: 0
• 최근 업데이트: 2026-09-08 (신규 생성)
• 사용 이력:
  • 2026-09-08 — 신규 생성. 3주치 작업을 되짚어 병목을 4갈래로 나눈 것이 첫 적용이다.
    🔴 예상과 결과가 달랐다 — 권한 승인이나 외부 차단이 클 줄 알았는데,
    최대 손실은 "한도가 풀렸는데 재개시키지 않은 시간"(최대 14시간)이었다.
    승인 대기는 30분, 외부 차단은 우회법이 쌓여 있었다.
    → "대기"가 "작업"보다 비싸다는 것이 이 분석의 결론이었고, 상위 개선안 4건이
    전부 도구가 아니라 절차 한 줄이었다.
    같은 날 다음 위임 지시서에 개선안 4건을 바로 넣어 §5를 실천했고,
    첫 적용에서 승인 대기가 30분에서 0분이 됐다.