--- title: "work-proposal" description: "업무 개선·AI 과제 아이디어를 제안서 뼈대(프로젝트명·한 줄 소개·해결하려는 문제·AI 해결 방안(프로세스 포함)·핵심 기능·활용 계획 및 기대 효과)로 구조화하는 스킬입니다. 바로 양식을 채우지 않습니다 — 불편·비효율을 인터뷰로 정량화하고 문제를 컨펌한 뒤에야 항목별 초안을 쓰고, 심사위원 관점 셀프 리뷰까지 거칩니다. 사내 AI 과제 공모·AX 경진대회 신청서, 업무 개선 제안서에 씁니다. \"제안서 써줘\", \"AX 과제 신청서 도와줘\", \"이 아이디어 제안서로 정리해줘\", \"뭘 제출해야 할지 모르겠어\"처럼 말하면 됩니다. work-find 메모가 이상적 입력이지만 빈손도 됩니다." pack: itda-work slug: work-proposal status: stable tags: ["proposal", "problem-discovery", "interview", "quantify", "self-review", "ax-competition"] --- # 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축): | 축 | 자문 | |---|---| | 문제 구체성 | 누가·언제·무엇 때문에 불편한지 장면이 그려지는가? | | 정량 근거 | 시간·건수·금액 숫자가 하나 이상 있는가? | | AI 적합성 | "왜 AI여야 하는가"에 답이 되는가? | | 실현 가능성 | 지금 가진 데이터·도구로 첫 버전이 되는가? | | 효과 측정 | 성공을 무엇으로 잴지 적혀 있는가? | 각 축에서 약점을 최소 1개 찾아 보완한다(사용자 확인이 필요하면 질문 1~2개). 보완 후 **최종본 전체**를 다시 제시하고, 무엇을 고쳤는지 2~3줄로 요약한다. ### 완료 보고 최종 텍스트(6항목) + 제출 양식에 항목별로 붙여넣으라는 안내 + 남은 빈칸(사용자 확인 필요 수치)이 있으면 목록으로 명시한다. 마지막에 다음 단계를 안내한다: **제안을 실제로 돌아가는 파일럿으로 만들려면 `work-pilot` 스킬**("이거 실제로 만들어보자") — 실현 계획·모의 데이터·1회전 실측·팀 스킬화까지 이어진다. --- ## 파이프라인 (itda-work 업무 스킬 패밀리) `work-find`(무엇을 풀지 발굴) → **`work-proposal`(제안서로 구조화)** → `work-pilot`(파일럿 실증·스킬화). 계획·실행 관리로 가려면 `work-plan`(itda-work 팩). 앞 단계 산출 메모/텍스트를 첨부하면 이어서 진행한다. --- ## 원칙 - **문제 먼저, 양식은 나중** — 컨펌 게이트가 이 스킬의 thesis. - **정직 > 그럴듯함** — 모르는 수치는 "(추정)"·빈칸으로. 심사장에서 무너질 숫자를 만들지 않는다. - **산출은 내용까지** — 도식·디자인 마감은 사용자 몫(mermaid 체인까지는 스킬이 제공).