개발 외주 전 기획서(RFP) 잘 쓰는 법 — 견적이 정확해지는 7가지 항목

개발 외주에서 견적이 업체마다 다르고, 중반에 "이건 견적에 없던 건데요"라는 말이 나오는 가장 큰 이유는 기획서가 모호하기 때문입니다. RFP(Request for Proposal, 제안요청서)는 거창한 문서가 아닙니다. "무엇을, 누구를 위해, 어디까지 만들고 싶은지"를 적은 한 장에서 시작해도 됩니다. 비개발자도 쓸 수 있는 7가지 항목과 순서를 정리합니다.

1. 목표 — 왜 만드는가

가장 먼저, 그리고 가장 중요한 항목입니다. 기능 목록보다 목표가 위에 와야 합니다.

• 이 서비스로 해결하려는 문제는 무엇인가
• 성공했다고 판단하는 기준은 무엇인가 (예: "현장 직원이 수기로 하던 일지를 모바일로 5분 안에 작성")
• 비즈니스 목표 (매출, 운영비 절감, 고객 응대 시간 단축 등)

목표가 명확하면 개발사가 "이 기능은 목표에 꼭 필요한가"를 함께 판단해 줄 수 있고, 불필요한 기능을 덜어내 비용을 줄일 수 있습니다.

2. 사용자 — 누가 쓰는가

같은 "관리 시스템"이라도 사용자가 누구냐에 따라 설계가 완전히 달라집니다.

• 주 사용자는 누구인가 (현장 작업자 / 사무직 / 외부 고객 / 관리자)
• 사용 환경은 어디인가 (PC 사무실 / 현장 스마트폰 / 키오스크)
• 사용자별 권한 구분이 필요한가 (일반 사용자 vs 관리자 vs 슈퍼관리자)

사용 환경은 특히 중요합니다. "현장에서 장갑 낀 손으로 쓴다"면 버튼이 커야 하고, "사무실 PC에서만 쓴다"면 정보 밀도를 높일 수 있습니다.

3. 기능 범위 — 무엇을 하는가

핵심입니다. 기능을 나열할 때 포함하는 것과 포함하지 않는 것을 함께 적는 것이 좋습니다.

• 꼭 있어야 하는 핵심 기능 (Must)
• 있으면 좋은 기능 (Want)
• 이번 범위에 넣지 않는 기능 (명시적으로 제외)

"넣지 않는 것"을 적어두면 나중에 "그건 당연히 포함인 줄 알았다"는 분쟁을 막을 수 있습니다. 1차 출시 범위를 좁히고 싶다면 Want 항목을 2차로 미루는 결정도 이 단계에서 합니다.

4. 화면 목록 — 어떻게 보이는가

기능을 화면 단위로 쪼개면 견적의 정확도가 크게 올라갑니다. 개발 비용은 결국 화면 수와 복잡도에 비례하기 때문입니다.

• 어떤 화면이 필요한가 (로그인, 목록, 상세, 등록/수정, 통계 등)
• 각 화면에서 사용자가 하는 일은 무엇인가
• 화면 간 이동 흐름 (A 화면 → B 화면)

완성된 디자인일 필요는 없습니다. 손그림 와이어프레임이나 "이 서비스의 이 화면처럼" 같은 참고 링크로 충분합니다.

5. 데이터 — 무엇을 저장하고 보여주는가

서비스의 뼈대입니다. 화면 뒤에서 어떤 정보가 오가는지 정리합니다.

• 어떤 정보를 입력·저장하는가 (회원 정보, 주문, 센서 측정값 등)
• 어떤 정보를 보여주고 검색·필터하는가
• 기존에 쓰던 데이터(엑셀 등)를 옮겨와야 하는가
• 데이터 양은 대략 어느 정도인가 (수백 건 / 수백만 건)

데이터 규모와 마이그레이션 여부는 서버 설계와 비용에 직접 영향을 줍니다.

6. 외부 연동·비기능 요구사항

겉으로 안 보이지만 비용과 일정을 크게 좌우하는 항목입니다.

• 외부 연동: 결제(PG), 본인인증, 카카오/네이버 로그인, 알림톡/SMS, 지도, IoT 기기/센서 등
• 성능: 동시 사용자 수, 응답 속도 기대치
• 보안·규제: 개인정보 처리 여부, 산업별 규제(의료·금융 등)
• 운영: 어디에 배포하는가(클라우드/자체 서버), 누가 운영하는가

IoT·하드웨어가 얽힌 프로젝트라면 "어떤 기기와 어떻게 통신하는지"를 이 단계에서 적어두면 견적 오차가 크게 줄어듭니다.

7. 일정·예산·산출물

마지막으로 제약 조건과 기대 결과물을 적습니다.

• 희망 출시 시점 (특정 행사·시즌이 있다면 명시)
• 예산 범위 (정확한 금액이 아니어도 "1천만 원대 / 수천만 원대" 수준은 도움이 됨)
• 받고 싶은 산출물 (소스코드, 운영 매뉴얼, 디자인 원본, 배포 문서)
• 유지보수 기대치 (출시 후 운영을 누가, 어떻게)

예산 범위를 공유하면 개발사가 그 안에서 우선순위를 조정한 현실적인 제안을 줄 수 있습니다. 예산을 숨기면 오히려 비교가 어려워집니다.

한 장으로 시작해도 됩니다

처음부터 완벽한 RFP를 쓸 필요는 없습니다. 위 7가지 항목에 각각 두세 줄씩만 적어도, 개발사가 같은 기준으로 견적을 내고 빠진 부분을 되물을 수 있는 출발점이 됩니다. 좋은 기획서는 의뢰자와 개발사가 같은 그림을 보게 만드는 문서입니다.

엠아이솔루션은 견적 단계에서 이 7가지 항목을 함께 인터뷰해 요구사항 초안을 작성해 드립니다. 개발 플로우에서 기획부터 검수까지 단계별 진행 방식을 확인하시거나, 무료 상담으로 아이디어 단계의 정리부터 시작해 보세요.