work-proposal — 과제 발굴 + 제안서 내용 작성

제안서에서 가장 중요한 칸은 “해결하고자 하는 문제”다. 대부분은 솔루션(“AI로 ~하는 시스템”)부터 쓰고 문제를 역으로 꾸민다 — 그 순서를 뒤집는 것이 이 스킬의 존재 이유다. 문제가 진짜여야 심사도, 실제 구현도 통과한다.

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

[HARD] 문제 컨펌 전에는 제안서의 어떤 항목도 작성하지 않는다. 관문2 게이트를 통과해야 관문3 진입. [HARD] 지어내지 않는다. 제안서의 사실·수치는 인터뷰에서 나온 것만 쓴다. 기대 효과의 추정치는 “(추정)” 표기 + 산출 근거(관문1의 정량값)를 함께 쓴다. 사용자가 모르는 수치는 비워 두고 확인 방법을 안내한다. [HARD] 솔루션 선행 입력의 역파기. 사용자가 솔루션부터 말하면(“~하는 시스템을 만들고 싶어요”) 그 아이디어를 버리지 말고, “그게 되면 어떤 불편이 사라지나요?”로 밑에 깔린 문제부터 역으로 파낸다. 질문은 한 번에 1~2개. 전문용어 없이, 비전공 실무자의 언어로.

관문0 — 입력·양식 확인#

• work-find 후보 메모가 있으면 그것을 관문1 의 출발점으로 삼는다 — 이미 파인 불편·정량값은 다시 묻지 않고 빈 값만 보충한다.
• 소속 조직의 제출 양식이 있으면 항목명을 받아 references/form-structure.md 의 기본 6항목에 매핑한다(항목이 다르면 매핑 표를 먼저 보여주고 확인). 양식이 없으면 기본 6항목으로 간다.

관문1 — 문제 발굴 인터뷰#

사용자가 준 한 줄(있다면)에서 출발해, 아래 순서로 파고든다. 답이 짧으면 예시를 들어 다시 묻는다.

1. 불편 후보 찾기 — “요즘 업무에서 시간을 가장 많이 잡아먹는 반복 작업이 뭔가요?”, “’이걸 왜 아직 사람이 하고 있지’ 싶은 순간이 있나요?”
2. 구체 사례 1건 깊이 파기 — 가장 최근에 그 일을 한 때를 붙잡고: 정확히 어떤 단계로 진행되나, 어느 단계가 제일 지겹거나 실수가 잦나, 무엇을 보고/열고/옮기나.
3. 정량화 (필수) — ① 1회 소요 시간 ② 주/월 빈도(복합 빈도는 연 N회로 환산해 함께 기록 — 예: “월 1회 + 분기 1회 = 연 16회”) ③ 하는 사람 수 ④ 실수 났을 때의 비용 (재작업 시간·클레임·금액). 모르면 대략 범위라도 받아 “(추정)”으로 기록한다.
4. 근본 원인 한 줄 — 왜 이 비효율이 생기는가: 정보가 흩어져 있어서 / 판단 기준이 문서화가 안 돼서 / 시스템 사이를 수작업으로 옮겨서 / 같은 질문에 매번 새로 답해서 …
5. AI 적합성 3문 — ① 입력이 문서·데이터·텍스트인가 ② 판단 기준을 말로 설명할 수 있는가 ③ 지금 사람이 반복적으로 하고 있는가. 셋 중 둘 이상 “아니오”면 솔직하게 말하고(물리 작업· 순수 대면 업무는 AI 과제로 부적합) 다른 불편 후보로 돌아간다 — 억지로 끼워 맞추지 않는다.

관문2 — 문제 컨펌 (게이트)#

인터뷰 결과를 pain 서술 1~3문장으로 정리해 제시한다 — 1인칭, 구체 상황, 정량 포함:

예) “나는 매주 고객 VOC 수십 건을 직접 읽고 유형을 분류해 담당 부서에 전달한다. 건당 10분, 주 5시간이 들고, 분류 기준이 사람마다 달라 같은 VOC가 다른 부서로 가는 일이 월 3~4건 생긴다.”

“이 문제로 제안서를 쓸까요?”를 명시적으로 묻는다. 수정 요청이 오면 관문1로 돌아가 보완한다. 컨펌을 받아야만 관문3으로 간다.

관문3 — 제안서 6항목 텍스트 작성#

references/form-structure.md의 항목별 가이드(질문·문체·분량)를 따라 작성한다. 핵심 원칙:

• §3 문제는 컨펌된 pain 서술을 양식 문체(“현재 ~하고 있습니다. ~로 인해 ~비효율이 발생하고 있습니다”)로 확장한 것이다 — 새 내용을 만들지 않는다.
• §4-2 프로세스는 5~6단계, 각 단계 = 이름(5자 내외) + 설명 1줄. “①접수 → ②분석 → …” 텍스트 체인이 기본 산출이고, 도식이 필요하면 같은 체인을 mermaid(flowchart LR)로도 함께 준다 — 슬라이드·문서에 붙여 그림으로 렌더링할 수 있다.
• §4-3 도구는 실사용 예정 도구만 쓴다(기본 “Claude 활용 예정”). 사내 전용 AI 도구·플랫폼이 있는지 1문으로 확인한 뒤 확정한다. 모르는 도구를 나열하지 않는다.
• §5 핵심 기능은 4~6개 불릿, 지금 가진 데이터·도구로 구현이 상상 가능한 것만.
• §6 기대 효과의 정량치는 관문1 수치에서 도출하고, 파생 계산은 산출식을 괄호 병기한다 — 예: “월 6시간 절감(추정: 2명 × 3시간)”. 측정 방법(무엇을 세서 성공을 판정할지) 1줄을 포함한다.

산출은 항목별 마크다운 블록으로 — 사용자가 제출 양식(PPT·문서·웹폼)에 항목 단위로 붙여넣는다. 공간이 부족한 양식이면 “양식을 확장해도 되는지”를 주최 안내문에서 확인하도록 알려 준다.

관문4 — 심사위원 셀프 리뷰#

초안을 심사위원의 눈으로 스스로 공격한다(공모전별 공식 루브릭이 있으면 그것을 우선, 없으면 일반 심사 5축):

각 축에서 약점을 최소 1개 찾아 보완한다(사용자 확인이 필요하면 질문 1~2개). 보완 후 최종본 전체를 다시 제시하고, 무엇을 고쳤는지 2~3줄로 요약한다.

완료 보고#

최종 텍스트(6항목) + 제출 양식에 항목별로 붙여넣으라는 안내 + 남은 빈칸(사용자 확인 필요 수치)이 있으면 목록으로 명시한다. 마지막에 다음 단계를 안내한다: 제안을 실제로 돌아가는 파일럿으로 만들려면 work-pilot 스킬(“이거 실제로 만들어보자”) — 실현 계획·모의 데이터·1회전 실측·팀 스킬화까지 이어진다.

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

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

원칙#

• 문제 먼저, 양식은 나중 — 컨펌 게이트가 이 스킬의 thesis.
• 정직 > 그럴듯함 — 모르는 수치는 “(추정)”·빈칸으로. 심사장에서 무너질 숫자를 만들지 않는다.
• 산출은 내용까지 — 도식·디자인 마감은 사용자 몫(mermaid 체인까지는 스킬이 제공).