sd-proposal

sd-proposal

요구 범위로부터 고객을 설득하는 제안서를 산출. 최우선 목적 = 근거 있는 설득 (근거 없는 우월 주장·정량효과 과장·현행 왜곡 차단). 고객이 "부풀렸다" 고 의심할 여지를 남기지 않는 것.

sd-estimate(공수·금액 산정)와 대칭되는 고객 대면 산출물이며, 견적이 함께 필요하면 sd-estimate 를 연계 안내.

입출력

• Input (자유): 제안 대상 범위를 알 수 있는 자료라면 무엇이든. spec.md(요구 분석서)·레거시 코드베이스·회의록·기능/화면 목록·구두 범위 설명 등. 정형/비정형 무관. 입력에서 "As-Is(현행)·To-Be(제안) 재료" 를 도출하는 것이 1단계.
• Output: 제안서 — PPT식 16:9 슬라이드 deck (HTML), 단일 자기완결 파일(외부 폰트·CDN 의존 없음). HTML 이 전달 산출물. 스킬은 PDF 를 추출하지 않음 — 고객 전달용 PDF 가 필요하면 사용자가 브라우저(Chrome/Edge)에서 HTML 을 열어 인쇄 → PDF 로 저장함(템플릿 @page 덕에 1 슬라이드 = 1 페이지).
• 저장 위치: 입력 자료(spec 등) 옆 또는 사용자 지정 경로(제안서.html).

핵심 원칙 (편향 차단 — 위반 시 제안서 무효)

1. 근거 있는 주장만 — As-Is 통증·To-Be 장점·도입 효과는 모두 입력 근거(코드·spec·제공 자료)에 연결. 근거가 없으면 그 항목을 빼거나 [OPEN] 으로 표시. 보기 좋으라고 효과를 지어내지 않음.
2. 정량효과 단정 금지 — "3배 빨라짐"·"비용 50% 절감" 같은 수치 효과는 사용자 실측·제공 근거가 있을 때만 기재. 없으면 정성(定性)으로 서술. 근거 없는 배수·퍼센트 단정 금지.
3. As-Is 는 사실로, 장점은 비교에서 도출 — 현행을 비하·왜곡하지 않고 사실대로 기술. 장점은 As-Is↔To-Be 대비에서 자연히 드러나게 함. 현황 서술(As-Is)을 그 자체로 우월성 근거로 쓰지 않음 — 통증의 근거는 코드·사실에서 가져옴.
4. 미확정은 협의 항목으로 — 정해지지 않은 범위·연동·규격은 확정인 척 단정하지 말고 §협의 사항(OPEN)·OPEN 뱃지로 분리. 일정은 추정이며 가변임을 명시.

절차

각 단계 산출물을 사용자가 검토·정정. 특히 3단계(스토리라인)는 생성 전 합의.

1. As-Is / To-Be 재료 도출

입력 자료를 도구로 직접 읽어 두 묶음을 도출.

• As-Is: 현행 시스템·프로세스의 구성, 한계·통증(코드·사실 근거와 함께).
• To-Be: 제안하는 모습 — 업무 흐름(사이클), 아키텍처, 기능 범위(모듈), 외부 연동.
• As-Is 가 없는 신규 구축 제안이면 As-Is 대신 "도전 과제(왜 필요한가)" 로 도출.

2. 변화 축 / 핵심 로직 정리

• 전환·통합·마이그레이션: As-Is → To-Be 변화 축을 비교 매트릭스로 정리(시스템 구조·데이터·연동·권한·추적성 등).
• 계산·판정이 핵심인 시스템: 그 핵심 메커니즘(역산·검증·경고 로직)을 정리.

3. 스토리라인(슬라이드 구성) 합의 (생성 전)

입력 자료에서 가장 설득력 있는 슬라이드 구성(장수·순서·각 장의 메시지)을 내용 우선으로 설계해 사용자와 합의. 1 슬라이드 = 1 메시지. 템플릿의 슬라이드 목록은 권장 예시일 뿐 고정 양식이 아니다 — 필요한 슬라이드는 새로 만들고, 의미 없는 슬라이드는 빼고, 쪼개거나 합치고 순서도 바꿈.

• 자주 유용한 골격(강제 아님): 표지 → (현황 진단 ↔ 도전 과제) → To-Be 비전 → (핵심 메커니즘) → 기능 범위 → (변화 비교표 · 연동 명세표) → 도입 효과 → 추진 일정 → (협의 사항) → 클로징.
• 위 골격에 없어도 그 제안에 필요한 내용(예: 보안·운영·데이터 이행·레퍼런스·비용 개요·팀 구성 등)이 있으면 슬라이드를 추가함. 반대로 설득에 기여하지 않는 장은 넣지 않음(공통 골격도 의미 없으면 뺌).
• 디자인은 템플릿 고정 — 컴포넌트는 카탈로그를 우선 재사용하되, 마땅치 않으면 같은 디자인 언어 안에서 새로 구성. 슬라이드 프레임·print/page·스크립트는 손대지 않음.
• 한 슬라이드에 내용이 많으면 둘로 쪼갬 — 720px 안에 들어가야 함(넘치면 잘림). 폰트·패딩은 템플릿 값을 유지하고 항목 수로 조절.

4. 슬라이드 deck 생성

references/proposal-template.html 의 디자인 시스템·컴포넌트를 참고해, 3단계에서 합의한 구성으로 산출. 템플릿을 그대로 채우는 게 아니라 내용에 가장 적합한 deck 을 구성함 — 슬라이드를 자유롭게 추가·삭제·분할·병합·재배치하고, 안 쓰는 .frame 은 통째 삭제. 규칙은 아래 "출력 형식" 을 따름.

5. 슬라이드 잘림 자가 점검

각 슬라이드 콘텐츠가 720px 안에 잘리지 않고 들어갔는지 점검(.slide 은 overflow:hidden — 넘치면 잘림). 넘치면 슬라이드를 쪼개거나 항목을 줄여 다시 맞춤. PDF 는 추출하지 않음.

• 점검 방법: 헤드리스 브라우저로 슬라이드별 1280×720 스크린샷을 떠 잘림 여부를 확인하거나, 콘텐츠 양 기준으로 자가 점검. (스크린샷이 필요하면 워크스페이스의 playwright 로 page.screenshot — npx playwright install chromium 으로 브라우저 설치.)
• 고객 전달용 PDF 는 사용자 몫: 필요하면 사용자가 브라우저(Chrome/Edge)에서 HTML 을 열어 인쇄 → PDF 로 저장함. 템플릿의 @page(1280×720) 덕에 1 슬라이드 = 1 페이지로 떨어짐.

6. 근거·과장 점검 게이트 (출력 전 자가 점검)

• 모든 통증·장점·효과가 입력 근거에 연결되나? 근거 없는 우월·정량 주장이 없나?
• As-Is 를 사실로 기술했나(비하·왜곡 없이)?
• 정량효과를 근거 없이 단정하지 않았나? (수치는 제공 근거 있을 때만)
• 미확정을 [OPEN]·협의 사항으로 분리했나? 일정의 가변성을 명시했나?
• 클로징 슬라이드에 근거 출처·작성일·공급자를 명기했나?
• 각 슬라이드가 720px 안에 잘림 없이 들어갔나? (스크린샷/브라우저로 확인)

출력 형식

references/proposal-template.html = 디자인 토큰(:root) + 슬라이드 프레임 + 컴포넌트 카탈로그 + 슬라이드 예시 메뉴 + fit·페이지번호 스크립트. 그대로 채우는 게 아니라 참고해, 내용에 가장 적합한 deck 을 구성함(복제 후 슬라이드 자유 가감).

• 1 슬라이드 = 1280×720px 고정 (= 96dpi 기준 13.333"×7.5" = PPT 와이드 16:9). 슬라이드 단위는 .frame > .slide. 콘텐츠는 720px 안에 들어가야 함(overflow:hidden — 넘치면 잘림).
• 컴포넌트는 카탈로그 우선 재사용 — 디자인 토큰·컴포넌트 클래스·슬라이드 프레임은 그대로 씀. 카탈로그로 표현이 마땅치 않으면 같은 디자인 언어(토큰·카드/그림자·여백 리듬) 안에서 새 레이아웃을 구성해도 됨.
• @media print / @page / fit·페이지번호 스크립트는 수정하지 않는다 — 사용자가 브라우저에서 인쇄(→PDF)할 때 1슬라이드=1페이지·배경 출력·자동 페이지번호 품질을 좌우. 페이지 번호(.pg)는 스크립트가 자동으로 채우므로 비워 둠.
• 구성·내용은 자유 — 슬라이드 추가·삭제·분할·병합·재배치를 내용 우선으로 자유롭게 함(필요하면 예시에 없는 주제도 새 슬라이드로, 의미 없으면 공통 골격도 뺌). 템플릿의 슬라이드 목록과 [공통·필수]/[선택] 라벨은 강제가 아닌 권장 예시 — template 대로 가 아니라 참고해 가장 적합하게. 안 쓰는 .frame 은 통째 삭제.
• 액센트 1색만 도메인/브랜드에 맞게 조정 가능(예: --cyan 강조 ↔ --rose 강조). navy+blue 베이스 팔레트는 고정.
• 플레이스홀더 「…」 는 전부 실제 내용으로 채우고, 채울 근거가 없으면 그 항목을 빼거나 OPEN 처리.
• 자기완결 1파일 — 외부 폰트·CDN·스크립트 의존 없음(오프라인/인쇄 안정). 폰트는 템플릿의 시스템 스택 그대로.