제안서를 나란히 펴 놓으면 금액이 몇 배씩 벌어져 있는데, 대개는 업체 욕심 때문이 아니라 범위와 방식이 서로 다르기 때문입니다. 다만 어디가 어떻게 다른지는 제안서만 봐서는 잘 드러나지 않습니다. 아래 질문을 받으신 제안서 전부에 빠짐없이 던져 보세요.
1. 진단 방식 — 도구인가 사람인가
비용 차이는 대부분 여기서 갈립니다. 스캐너가 내놓은 목록을 정리한 보고서와, 항목마다 사람이 손으로 재현해 오탐을 걷어낸 보고서는 들어가는 시간부터 다릅니다.
2. 인증 이후 영역을 보는가
로그인 화면 앞에서 멈추는 진단은 절반도 못 봅니다. 권한이 다른 계정을 여러 개 받아서 남의 데이터가 열리는지 직접 눌러 보는지가 관건입니다. 인가 우회와 권한 상승, 그리고 업무 논리 결함은 전부 로그인 뒤에 있습니다.
3. API와 모바일이 범위에 있는가
화면만 보고 API를 빼면 정보가 대량으로 빠져나가는 통로를 통째로 놓칩니다. 모바일 앱이 있다면 앱 자체를 뜯어보는 일과 앱이 부르는 API를 보는 일이 서로 다른 작업이라는 점도 짚어야 합니다.
4. 재점검이 포함되어 있는가
재점검이 빠지면 과업은 “고쳤다고 생각하는 상태”에서 끝납니다. 포함 여부와 함께 어디까지 다시 보는지도 확인하세요. 전체를 재수행하는지 조치한 항목만 보는지에 따라 성격이 달라집니다.
5. 산출물이 정의되어 있는가
제안서에 “보고서 1식”이라고만 적혀 있으면 산출물이 정의된 것으로 보기 어렵습니다. 무슨 문서를 몇 부 받고 그 안에 무엇이 들어가는지가 계약서에 적힐 수 있어야 합니다.
- 발견 사항별 재현 절차가 포함되는가 요청과 응답 없이 “취약함”이라고만 적힌 줄을 받으면 개발팀은 무엇부터 고쳐야 할지 알 수 없습니다.
- 위험도 산정 기준이 보고서에 명시되는가 정의가 빠지면 “이게 왜 High냐”를 두고 회의가 한 번 더 잡힙니다.
- 경영진 요약과 실무 조치 가이드가 분리되는가
- 조치 우선순위가 제시되는가 (위험도만이 아니라 조치 난이도까지)
- 보고 회의가 포함되는가, 몇 회인가
6. 수행 규칙이 문서로 있는가
운영 중인 시스템을 직접 건드리는 일이라, 아래가 서면으로 남지 않으면 무슨 일이 생겼을 때 원인보다 책임 소재부터 다투게 됩니다.
- 대상 범위가 IP·도메인·계정 단위로 특정되는가
- 수행 시간대와 가용성 영향 가능성에 대한 합의가 있는가
- 비상 정지 조건과 연락 체계가 정해져 있는가
- 실데이터 취급 원칙(열람 범위, 추출 금지)이 명시되는가
- Critical 발견 시 즉시 통보 조항이 있는가
7. 데이터 파기와 비밀유지
- NDA를 착수 전에 체결하는가
- 진단 데이터의 보관 기간과 파기 시점이 정해져 있는가
- 파기 확인서를 제공하는가
- 산출물을 어떤 경로로 넘길지 미리 합의되어 있는가
8. 누가 수행하는가
제안서를 쓴 회사와 현장에 오는 사람이 다를 수 있습니다. 담당자가 정말 궁금한 건 회사 규모가 아닙니다. 내 프로젝트에 누가 오느냐입니다.
- 참여 인력의 이력(경력 연차, 수행 분야)이 제시되는가
- 재하도급 여부와 범위가 명시되는가
- 과업 중 인력 교체 시 통보·승인 절차가 있는가
비교표로 쓰기
제안서가 여러 건이면 아래 칸에 옮겨 적어 보세요. 빈칸이 많이 남는 쪽이 곧 답입니다.
| 항목 | 업체 A | 업체 B | 업체 C |
|---|---|---|---|
| 수동 검증 비중 | |||
| 인증 이후 영역 | |||
| API 포함 / 산정 기준 | |||
| 재점검 횟수 · 범위 | |||
| 산출물 종수 | |||
| 수행 규칙 문서 | |||
| 파기 확인서 | |||
| 참여 인력 이력 | |||
| 금액 |