IT 프로젝트, 견적서 양식 그대로 쓰면 안되는 이유
7년차 PM이 알려주는 견적서 제대로 작성하는 법
안녕하세요~ 리뷰온리예요! :)
날씨가 참 선선해졌어요~ 이제 완전 가을이 됐네요!
PM으로 일하다 보면 견적서를 직접 작성해야 하는 순간이 꽤 자주 찾아와요.
처음에는 저도 검색해서 다운로드한 양식을 그대로 쓰곤 했는데요,
어느 순간부터는 직접 만들어 사용하고 있어요.
이유는 간단해요. 양식 그대로는 항상 부족했고,
현실적인 프로젝트 상황을 반영하기가 어렵더라구요...ㅠㅠ
오늘은 견적서 양식이 부족한 이유와,
제가 지금은 어떤 방식으로 견적서를 작성하는지 팁도 함께 나눠보려 해요!
출처: 서해환경신문양식만 쓰면 프로젝트 범위가 왜곡돼요
견적서 양식은 보통 '항목/단가/수량/합계' 정도만 들어있어요.
보기엔 깔끔하지만 실제 IT 프로젝트는 그렇게 단순하지 않아요.
로그인 기능 하나만 해도 자체 인증, 소셜 로그인, OTP 여부에 따라
난이도와 비용이 크게 달라지거든요.
관리자 화면도 마찬가지예요.
표 보기, 정렬, 검색, 필터, 엑셀 다운로드, 권한 분리 같은
"자잘해 보이는 옵션"이 실제로는 시간을 많이 잡아먹어요.
그런데 양식만 쓰면 이런 부가 요구사항이 한 줄에 섞여 버려서,
어디에 얼만큼의 공수가 들어가는지 보이지 않아요.
결국 프로젝트 시작 후 "이건 빠졌잖아요?"라는 말이 나오기 십상이에요 ㅠㅠ
맨아워 분해가 없으면 설득이 안 돼요
견적은 단순히 총액을 적는 문서가 아니에요.
"개발자 2명 × 8주"처럼 인력과 기간이 나뉘어 있어야
변경 요청이 생겨도 근거를 갖고 조정할 수 있어요.
화면 단위, 컴포넌트 단위, 연동 단위로 맨아워를 쪼개두면
"무엇을 줄이면 얼마가 줄어드는지"가 금방 드러나서 의사결정이 빨라져요.
반대로 양식에는 이런 세부 산출이 빠져 있어서,
이해관계자에게 왜 이 금액이 나왔는지 설명하기가 너무 어렵더라구요.
총액만 놓고 얘기하면 클라이언트가 "가격 흥정"으로만 이해하게돼요.
그래서 반드시 맨아워 근거를 함께 제시해야 해요!
버퍼 없는 견적은 현실과 어긋나요
실무에서는 요구사항이 바뀌고, 외부 API가 늦고, 데이터 품질 문제도 터져요.
디자인이 실제 단말에서 달라 보이는 일도 잦구요.
그래서 보통 10~20% 정도는 예비비를 잡아두는 게 안전해요.
버퍼는 여유가 아니라 리스크 흡수 장치예요.
그런데 다운로드한 양식은 이런 버퍼를 고려하지 않은 경우가 대부분이라,
일정이나 품질이 중간에 깨질 위험이 커져요.
"버퍼가 있으면 느슨해지지 않나?"라는 질문도 종종 받는데,
버퍼는 느슨함의 변명이 아니라 "변경을 수용하는 규칙"에 가까워요.
버퍼를 투명하게 공개하고, 어느 상황에서 쓰일지
기준을 합의해두면 오히려 프로젝트가 단단해져요 :)
QA와 운영 항목이 빠져 있어요
양식에는 QA나 운영 관련 부분이 거의 보이지 않아요.
하지만 실제 프로젝트에서는 테스트 케이스, 기기 대응, 배포 방식, 모니터링까지
다 비용에 포함돼야 하거든요.
예를 들어 "모바일 상위 단말만 본다"와
"안드로이드/아이폰 주요 해상도 + 태블릿까지 본다"는 QA 공수가 전혀 달라요.
성능 기준(P95 응답시간, 초기 페인트 시간)이나
보안 점검 포함 여부도 비용과 일정에 큰 영향을 줘요.
QA와 운영이 빠지면 "완성"의 기준이 서로 달라지고, 런칭 이후 분쟁이 커지기 쉬워요! ㅎㅎ
견적서 양식으로만 작성하면 안되는 이유
저도 예전에 쇼핑몰 리뉴얼 프로젝트를 맡아 견적서를 작성한 적이 있는데요!
그때 왜 단순한 양식만으로는 부족한지 확실히 알게 됐어요.
UI 자체는 단순해 보였지만, 데이터 처리 방식 때문에 견적 차이가 크게 났거든요.
기존 주문 데이터를 전부 이관하고 정합성 검증까지 포함한 경우와,
신규 DB로 전환하는 경우는 투입 공수가 완전히 달랐어요.
겉으로는 비슷해 보여도 실제 차이를 만드는 건 이런 보이지 않는 부분이에요.
그런데 클라이언트는 이런 배경을 알기 어렵기 때문에,
화면만 보고 판단하는 경우가 많아요.
그 간극을 메워주지 않으면 견적은 항상 "왜 이렇게 비싸요?"라는 질문으로 돌아오죠.
외주개발사 PM으로서 제가 느낀 건, 견적서는 일종의 프로젝트 설명서라는 거에요.
총액이 아니라 "어디까지가 포함이고, 어떤 위험 요소가 있고, 어떤 선택이 비용을 갈라놓는지" 를 적어야
비로소 제대로 된 견적이 돼요.
그 차이를 설득력 있게 보여주는 게 바로 PM의 역할이더라구요 :)
7년차 PM의 견적서 작성법
저는 지금 이렇게 작성하고 있어요.
사용자 흐름 정리 "장바구니 → 쿠폰 적용 → 가격 재계산 → 결제 성공/실패 → 주문 확정"처럼
실제 사용 시나리오를 적어둬요.
클라이언트가 견적을 보면서 바로 이해할 수 있도록 노력해요.
컴포넌트 기준 산출 화면이 아니라 버튼, 리스트, 모달 같은 컴포넌트 단위로 맨아워를 나눠요.
여기에 반응형 기준이나 접근성 기준을 붙여두면 QA에서 오해가 줄어들어요.
연동과 데이터 분리 로그인, 결제, 알림, 분석, 배송, CRM 같은 연동 항목은 따로 모아두고,
지연 시나리오까지 메모해둬요.
데이터 마이그레이션도 추출·정제·매핑·검증·롤백 단계를 분리해요.
운영·배포 계획 포함 DEV/QA/PROD 환경 구성, 배포 방식, 롤백 절차, 로그와 알림 체계까지 적어둬요.
이렇게 하면 견적은 단순한 가격표가 아니라 프로젝트 운영 계획서처럼 읽히죠.
견적서 작성에 관한 자주 묻는 질문
Q. 양식은 아예 쓰면 안 되나요?
→ 아니에요! 출발점으로는 좋아요.
다만 실제 프로젝트에서는 반드시 맨아워, 버퍼, QA, 운영 같은 현실적인 요소를 덧붙여야 해요.
Q. 버퍼는 꼭 넣어야 하나요?
→ 네. 요구사항 변경이나 외부 지연은 늘 생겨요!
평균적으로 10~20% 정도 버퍼가 필요했어요.
Q. 고정가 vs 맨아워 단가, 뭐가 나을까요?
→ 범위가 명확하다면 고정가,
불확실성이 많다면 맨아워 단가+상한선(cap)이 안전해요.
Q. 디자인 결과물은 얼마나 영향을 주나요?
→ 디자인 완성도가 높을수록 기능 모호성이 줄어들고 견적도 안정돼요.
컴포넌트 단위로 정리된 디자인이면 훨씬 정확해지죠.
견적서 양식은 정말 많이 나와있고, 쓰기도 간편한데요,
하지만 그대로 쓰면 실제 프로젝트의 현실을 담기엔 부족하죠.
견적서는 단순한 비용 산출이 아니라,
프로젝트의 방향과 위험 요소를 함께 기록하는 문서예요.
제대로 작성된 견적서는 이후 일정 조율이나 의사결정에서도 좋은 기준점이 되어 줄 수 있어요!
추가로 견적서 작성에 어려움을 겪으신다면,
클라이언트는 어떤 기준으로 비교하는지도 같이 확인해보세요!
좋은 글이 있어서 링크 공유드립니당~
오늘의 글도 도움이 되셨으면 좋겠네요~ㅎㅎ
읽어주셔서 감사합니다 :)
