sd-estimate

sd-estimate

요구 범위로부터 신뢰도 높은 공수(M/D)·금액을 산정하고 견적서를 산출. 최우선 목적 = 근거 있는 산정 (뻥튀기·낙관 편향·임의값 차단). 고객이 "뻥튀기"라고 의심할 여지를 남기지 않는 것.

입출력

• Input (자유): 산정 대상 범위를 알 수 있는 자료라면 무엇이든. spec.md(요구 분석서)·회의록·메일·기능/화면 목록·PPT·구두 범위 설명 등. 정형/비정형 무관. 특정 형식을 강제하지 않음 — 입력에서 "산정 대상 작업 목록"을 도출하는 것이 1단계.
• Output: ① 고객용 견적서 (HTML 등) — 작업별 공수·금액 위주, 내부 산정 용어 비노출. ② (내부용) 공수 산정 내역서 (작업 분해 + 3점 추정 표) — 검토·근거 보관용, 고객에 미동봉.
• 사용자 입력 우선: 사내 표준 공수·단가·실적이 제공되면 그것이 최우선 근거 (아래 방법론보다 우선).

핵심 원칙 (편향 차단 — 위반 시 산정 무효)

1. 분해 강제 — 큰 덩어리("화면 하나에 N일") 단위 추정 금지. 작업을 잘게 쪼갠 뒤 합산(bottom-up). 덩어리가 클수록 낙관·패딩이 숨음.
2. 3점 추정 — 단일값 금지. 모든 작업을 낙관(O)/최빈(M)/비관(P) 3점으로 잡고 PERT 가중평균 (O+4M+P)/6 사용. 불확실성을 드러내 뻥튀기·낙관 둘 다 노출.
3. 유추 우선(reference class) — 가능하면 사내 유사 프로젝트 실적 분포에 근거. 과거 실적이 있으면 그것이 모든 추정의 1차 기준점.
4. 근거·가정 명시 — 모르는 값은 임의로 채우지 말고 [가정: …] 또는 [OPEN]. 산정 방식·단가 출처를 견적서에 명기.
5. 생산성 보정은 근거 있을 때만 — "프레임워크 쓰니 1/3" 같은 정량 배수는 근거가 약함(연구상 반박됨). 사내 실적으로 입증되지 않은 생산성 배수를 단정하지 않음.
6. 고객 산출물과 내부 산정 분리 — 고객에게 가는 견적서에는 내부 도구명(sd-* 등)·산정 과정 용어(PERT·(O+4M+P)/6·O/M/P·낙관/비관·델파이·reference class 등)·자신 없어 보이는 표현("가정 기반·실적 미대조" 등)·단가 산출 방법론명(KOSA·노임단가 등)을 노출하지 않음. 고객 견적서 = 작업별 공수·금액 + 합계 + 전제(일반어)만. 3점 추정 표·산정 근거·가정은 내부 산정 내역서로 분리(고객 비공개; 요청 시에도 신중).

절차

작성은 순차로 진행하되, 각 단계 산출물을 사용자가 검토·정정.

1. 작업 분해 (WBS)

입력 자료에서 산정 대상을 작업 단위로 분해. 입력이 무엇이든(spec·회의록·구두) 동일하게 "할 일 목록"으로 환원.

• 분해 입도: 1작업 ≈ 0.5~3 M/D 수준까지 쪼갬 (그보다 크면 더 쪼갬).
• 빠지기 쉬운 작업도 (누락 방지 위해) 식별: 설계, 연동 시험, 데이터 마이그레이션, 배포 셋업, 안정화. 단 PM/문서·리스크 예비는 고객 견적서에 별도 라인으로 두지 말고 각 작업 단가에 내재(§5 참조) — WBS·내부서에선 공수에 반영하되 고객 라인으로 분리 표기하지 않음.
• 입력에 없어 추정 불가한 범위는 [OPEN]으로 두고 견적 범위 외로 두되 전제 조건에 일반어로 명시.

2. 유형 분류 + 유형별 M/D 기준 확인

작업을 유형으로 묶어 산정 단위를 잡음. 유형 항목은 고정 목록이 아니라 견적 대상(무엇을 만드는지)에서 도출 — 대상에 맞는 유형들을 그때 구성. 흔한 분류 예(강제 아님, 대상에 맞게 가감):

유형	설명
마스터 CRUD	목록+등록/수정/삭제, 스캐폴딩 가능
단순 조회	필터+목록 표시
복합 화면	실시간·상태·다중 영역·인쇄 등
트랜잭션	입력·검증·상태 전이
외부 연동	프로토콜·파싱·재시도·멱등
배치/자동	스케줄·이벤트 처리
로직/계산	도메인 규칙·산식
비화면 작업	데이터 이관·통합 시험·설치·배포·안정화

유형별 M/D 기준은 사용자에게 물음 (필수 — 임의값·기본값으로 채우지 않음). M/D 단가를 사용자에게 확정받듯(§7-1), "이런 유형 작업은 대략 몇 M/D 걸리는지" 그 생산성 기준도 사용자 확정 사항. 사내 표준 공수·실적이 제공되면 그것이 최우선 근거.

• 견적 대상에서 구성한 유형 목록을 사용자에게 제시하고, 각 유형의 가늠 M/D(또는 O/M/P 범위)를 받음.
• 마이그레이션 vs 신규 구분해 묻기: 검증된 레거시·명세가 있어 로직·화면·산식이 확정된 이식·통합과, 요건·설계·UX 미확정 신규 개발은 같은 유형이라도 M/D 가 다름(신규가 설계·발굴·시행착오로 더 큼). 유형별 기준을 받을 때 이 구분을 함께 확인.
• 화면 1개 = vertical slice(모델+서버+화면+테스트). 동형(파생) 화면은 한 단계 낮은 유형으로. 횡단 인프라(인증·이력·재고/변동 엔진 등)는 화면과 별도 항목으로 분리(이중 계상 방지).
• 받은 유형별 기준을 각 작업에 적용해 1차 가늠치를 부여 → 3단계에서 3점 추정으로 보정.

3. 3점 추정 → PERT

각 작업에 O/M/P(M/D)를 매기고 PERT = (O+4M+P)/6 계산. 표로 작성:

작업	유형	O	M	P	PERT

• O/M/P는 §2 에서 사용자가 확정한 유형별 M/D 기준으로. 비관(P)에는 통합·디버깅·요건 변경 리스크 반영.
• 합계 PERT = 기본 공수. 합계 O~P = 변동 범위(내부 검토·리스크 판단용; 고객 견적서에는 노출하지 않음).

4. 유추 보정 (reference class)

사내 유사 프로젝트 실적과 대조해 합계를 보정. 실적이 없으면 그 사실을 명시([가정 기반 — 실적 미대조])하고 비관(P)에 가중.

5. 합계 + 리스크 버퍼

• 기본 공수 = ΣPERT.
• 리스크 예비·예비비: 별도 항목 금지 — 각 작업 단가에 합리적으로 반영. 단가를 변동·리스크를 감안한 보수적 값으로 책정해 녹임. 단 내부 산정 내역서에는 반영 사실·정도(기초 공수 vs 최종 M/D)를 반드시 명시(투명성 — 근거 없는 패딩과 구분).
• 사업관리·기술문서(PM·문서화)도 별도 항목 금지 — 당연 업무이므로 각 작업 단가에 내재(고객 견적서에 "PM/문서" 라인 미표기). WBS·내부서엔 누락 방지로 반영하되 고객 라인으로 분리하지 않음.
• 끝자리는 tfoot 절삭 행으로 맞춤.

6. 금액 산정

금액 = 공수(M/D) × 단가. 단가·방식은 아래 "금액 산정 방법론" 참조. 사용자 지정 단가가 있으면 우선.

• 직접인건비 = ΣM/D × 단가.
• (필요 시) 직접경비·기술료/이윤·VAT 별도 행.

(7-1) 필수 정보 확인 — 모르면 사용자에게 질문. 아래 값은 견적서에 그대로 인쇄되므로, 자료에 없으면 임의로 채우거나 [OPEN] 으로 두지 말고 사용자에게 물어서 확정한다 (확정 전 견적서 산출 보류):

• 수신처(고객사)명
• 제안사(발신) 주소 · 담당자명 · 연락처 — 견적서 발행처·"문의처" (고객사 담당자가 아니라 제안하는 쪽 정보). 사내 표준값이 있으면 그대로, 없으면 물어서 확정. (상호·워드마크는 템플릿 고정)
• 유형별 M/D 기준 — §2 에서 구성한 작업 유형별 생산성("이런 유형은 대략 몇 M/D"). 공수(M/D) 산정의 기준값. 사내 표준 공수·실적이 1순위. 자료·지정이 없으면 임의값·기본값으로 채우지 말고 물어서 확정. (단가와 별개 — 단가는 M/D당 금액, 기준은 작업당 M/D.)
• M/D 단가 — 금액 = 공수 × 단가 의 단가. 회사 표준 단가가 1순위(아래 "금액 산정 방법론" 참조). 자료·지정이 없으면 임의값·기본값으로 채우지 말고 물어서 확정.
• 결제조건 — 착수금 / 중도금 / 잔금 비율(%) (예: 착수 50 / 잔금 50)
• 납기 (예: 계약체결 후 N개월)
• VAT 별도 / 포함 여부
• 그 외 자료에서 확정되지 않는 헤더·조건 값

7. 견적서 생성

고객용 견적서를 references/estimate-template.html 을 복제해 산출(기본 HTML, 인쇄 A4 / PDF). 채울 내용:

• 공급(제안사)/수신(고객사·담당자) 정보, 발행일·유효기간.
• 항목별 표(작업·공수·단가·금액), 소계·VAT·합계 (VAT 별도/포함은 7-1 확인값을 따름).
• 결제조건·납기 등 비고.
• 전제 — 일반어로만 (예: "상세 요건 확정 후 조정됩니다").
• (큰 요구일 때 필수) 「[부록] 과업 세부 내역 — 항목별 산출물」 — 화면·항목이 수십~백 단위면 견적서 끝(전제 조건 다음·서명 앞)에 이 부록 섹션을 둔다(템플릿 [선택] 과업 세부 내역 부록 섹션, <table class="excl">). 견적 내역 각 항목에 포함된 산출물(화면·기능)을 전수 나열해 고객이 "이 항목에 뭐가 들어가나"를 보게 한다. 내부 용어(tier·복잡도·M/D 내재·기초 build 등) 금지 — 산출물 명칭만. 공수·금액은 「견적 내역」을 따르고 부록엔 중복 표기하지 않음(산출물 목록만). 작은 요구(항목 소수)면 섹션 삭제.

세부 작성 규칙은 아래 "출력 형식 (템플릿)" 을 따른다. 산정 과정(3점 추정 표·O/M/P·가정·방법론)은 견적서에 넣지 않고 별도 내부 산정 내역서로 둠 (위 "핵심 원칙" 6 참조).

8. 편향 방지 체크리스트 (산출 전 자가 점검)

• 작업을 충분히 잘게 분해했나? (덩어리 추정 없음)
• 모든 작업이 3점 추정인가? (단일값 없음)
• 사내 실적과 대조했나? 못 했으면 명시했나?
• 생산성 배수를 근거 없이 단정하지 않았나?
• 단가 출처·산정 방식·가정·OPEN을 견적서에 명기했나?
• 낙관·뻥튀기 점검: P(비관)가 비현실적으로 낮거나, M이 근거 없이 높지 않은가?

공수 산정 방법론 (지식 레퍼런스)

근거: deep-research 검증 결과 (소프트웨어 공수 추정 방법론).

• 규모 → 공수 변환: 공수 = 기능 규모 × 생산성 계수. 기능점수(FP)당 투입시간(ISBSG 평균 약 8시간/FP, 최대 65시간/FP), 유스케이스 포인트(UCP)당 약 20시간(Karner; 1530 범위, Ribu). 규모-공수는 비선형일 수 있음(규모의 경제/비경제).
• COCOMO II: PM_nominal = A × (Size)^B, B(0.91~1.26)가 규모 경제/비경제를, 노력승수(EM, 기준 1.0; Early Design 7개 / Post-Architecture 17개)가 보정을 표현. 공수(PM)와 일정(개월)은 별개.
• 추정 기법군: 전문가 판단 / 파라메트릭(COCOMO 등) / 유추(analogy) / ML. 단일 전문가의 주관성을 줄이려 와이드밴드 델파이·플래닝 포커(익명·동시 공개·재추정, 보통 3라운드 내 수렴) 같은 집단 합의 기법 사용.
• 3점 추정: PERT E = (O + 4M + P) / 6.
• Cohn 3대 기법: 전문가 의견 + 유추 + 분해(disaggregation) — 결합이 단독보다 우수.
• Reference class forecasting(바깥 시각): 과거 유사 프로젝트 실적 분포에 근거. 낙관 편향(무의식)과 전략적 허위표현(의도적 padding/lowballing)을 둘 다 우회 — 정확도 향상의 핵심.
• 생산성 보정 주의: 로우코드/노코드/프레임워크의 정량적 생산성 배수(3~10배 등)는 적대검증에서 반박됨 — 단순 업무앱 한정 사례일 뿐, 신뢰할 보정계수로 단정 불가.

금액 산정 방법론 (지식 레퍼런스)

근거: deep-research 검증 결과 (KOSA SW사업 대가산정). 단가는 사용자 지정 또는 협의가 우선이며, 아래는 기준점일 뿐 강제 아님.

• 단가 결정 원칙 (중요): 회사 표준 M/D 단가(사용자 지정)가 1순위.
  • 사용자가 회사 표준 M/D 단가를 지정하면 그 값을 사용하고, 공식(제경비·기술료·보정) 없이 단순 공수(M/D) × 단가 로 산정. 지정값이 없으면 7-1 에 따라 물어서 확정한다(임의값·기본값으로 산출하지 않음). (1 M/M = 20.8 M/D 환산 참고)
  • 노임단가를 청구 단가로 그대로 쓰지 말 것 — 노임단가는 ① 등급 평균이고 ② 직접인건비만(제경비·기술료/이윤 미포함)이라 원가 이하임.
  • 공공 입찰 등으로 공식 산정이 필요하면, 노임단가(직접인건비)에 제경비·기술료를 가산하거나 아래 KOSA 구조를 따른다 (그 결과는 내부 원가 검증용, 고객 견적서엔 미노출).
• 투입공수 방식: 직접인건비 = M/D × 등급별 노임단가. KOSA 'SW기술자 평균임금'의 일평균임금 = M/D당 직접인건비 기준점 (월평균 ÷ 월근무일수) — 청구 단가가 아니라 하한·참고.
  • 2026년 적용(2025 조사): 응용SW개발자 378,250원/일, 시스템SW개발자 284,888원/일. / 2025년 적용: 응용SW개발자 337,061원/일.
  • KOSA 대가산정 구조: 직접인건비 + 제경비(인건비의 약 110120%) + 기술료(직접인건비+제경비의 약 2040%). 노임단가만으로는 개발원가가 되지 않음.
  • 법정 최저가 아니라 공공사업 기준점 — 수·발주자 협의로 적용. 민간은 회사 단가로 협의.
• 기능점수(FP) 방식: 개발비 = 최종 FP × FP당 단가. KOSA 가이드 FP 단가 605,784원(2024 개정, +9.5%), 2025 개정판이 최신(2025-08-11 공표). FP 단가에는 제경비·기술료가 포함되어 공공 기준이라 오히려 높게 나올 수 있음 — "공식 = 무조건 저렴"이 아님에 유의.
• 합산: 개발비(FP 또는 투입공수) + 직접경비 + 기술료/이윤 + VAT(10%). 2025 개정 가이드는 DevOps에서 개발비=FP, 운영·유지관리비=투입공수로 산정 후 합산하는 기준 신설.
• 단가는 매년 변동 — 적용 연도를 명시하고, 최신 KOSA 공표값 확인 권장.

출력 형식 (템플릿)

고객용 견적서는 references/estimate-template.html = 디자인 토큰(:root) + A4 인쇄 CSS + 섹션 컴포넌트 + 「…」 플레이스홀더. 이를 복제해 채움.

• 디자인 토큰·컴포넌트 클래스는 그대로 재사용 — 새 컴포넌트·임의 인라인 스타일을 만들지 않음.
• @media print / @page 블록은 수정하지 않음 — @page{margin:0}(브라우저 기본 머리글·바닥글 제거; A4 여백은 .sheet 패딩이 담당)·print-color-adjust:exact(네이비 헤더·배너 음영 출력)·page-break 제어가 PDF 출력 품질을 좌우함. 본문이 길면 2페이지로 흘러도 표 행·섹션이 페이지 경계에서 잘리지 않음.
• 자기완결 1파일 — 외부 폰트·CDN·스크립트를 추가하지 않음(오프라인/PDF 인쇄 안정). 폰트는 템플릿의 시스템 스택 그대로.
• 액센트 1색(--accent)만 브랜드/도메인에 맞게 조정 가능. navy 베이스 팔레트는 고정.
• 공급자 고정값(상호·SIMPLYSM 워드마크·직인 블록)은 유지. 주소·담당자·연락처와 수신처·건명·금액·조건은 7-1 확인값으로 채움.
• 섹션 주석 [공통·필수] / [선택] 을 따름 — [선택] = ① 견적 전제 조건, ② 「[부록] 과업 세부 내역 — 항목별 산출물」(큰 요구일 때만 사용; 작으면 삭제). 해당 내용이 없으면 섹션을 통째로 삭제. tfoot 의 절삭 행도 끝자리를 맞출 때만 남기고 아니면 삭제.
• 플레이스홀더 「…」 는 전부 실제 값으로 채움. 미확정 헤더 값(고객사·담당자·결제조건·납기·VAT)은 7-1 에 따라 사용자에게 확정받은 뒤 채움(빈 채로 산출 금지).
• 금액 표기 일관성 — 금액은 천단위 콤마·우정렬, 공수는 PERT 반올림값을 중앙정렬. 공급가액=Σ금액, VAT·소계·합계가 산술적으로 맞아떨어지는지 산출 전 검산.
• 내부 산정 용어·도구명 비노출 — 핵심 원칙 6 을 따름(견적서에 과정 용어 미기재).

내부 산정 내역서(별도): 1~5단계 산출물(작업 분해 + 3점 추정 표 + 합계)을 보관 — 견적 검토·근거 추적용. 고객 견적서와 분리하며 기본 비동봉.

• 큰 요구(화면·항목 수십~백 단위)면 세부 항목별 부록을 별도로 둠(예: estimate-internal-appendix.md) — 각 항목(화면/모델/인프라/연동/단계)을 복잡도·tier·M/D 로 전수 나열해 모듈 합계를 역추적 가능하게. 모듈 합계만 있으면 "이 숫자가 어느 항목들로 구성됐나"가 안 보임. 부록 끝에 세부 항목 → 고객 라인 매핑 → 예비·문서 내재 → 최종까지 닫아 검산 일치 확인.