홈페이지 개발 기획서 작성법: 견적이 정확해지는 항목 12개 [2026]
홈페이지 개발 기획서에 넣어야 할 사업 목표, 대상 고객, 사이트맵, 페이지별 콘텐츠, 기능, 관리자, 외부 연동, SEO, 검수와 운영 항목을 정리했습니다. 완성된 화면 설계 없이도 여러 업체가 같은 범위로 견적을 내고 일정과 책임을 합의하게 만드는 작성법을 안내합니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
홈페이지 개발 기획서는 완성 화면을 미리 그리는 문서가 아니라 사업 목표·사용자·핵심 과업·콘텐츠 원천·사이트 구조·기능·데이터·권한·외부 연동·품질·법적 제약·검색 이전·운영·검수와 미확정 가정을 후보 업체가 같은 범위로 해석하고 시험할 수 있게 만드는 요구사항 기준선입니다. 12개 항목을 채우는 것보다 요구의 이유·책임·완료 증거·변경 계보를 연결하는 일이 중요합니다.
기획서가 페이지 이름과 참고 사이트만 담으면 업체마다 콘텐츠 작성·관리자·회원·문의 전달·다국어·SEO·촬영·이관·운영을 다르게 가정합니다. 견적 차이는 개발사 실력보다 숨은 범위 차이에서 생길 수 있습니다. 현재 확정된 사실과 가설·선택지·제외를 구분해 동일한 질문에 답하도록 해야 합니다.
반대로 모든 화면과 정책을 발주 전에 고정하려 하면 검증되지 않은 해법을 계약으로 굳힐 수 있습니다. 목표와 필수 결과·제약은 기준선으로 정하되 정보구조·프로토타입·기술 설계에서 발견되는 내용을 변경 원장으로 반영합니다. 요구사항 ID를 설계·개발·검수·운영 문서와 연결하면 누락과 과잉 구현을 줄일 수 있습니다.
사업·사용자·콘텐츠·기능·데이터·품질·운영 정보를 한 기준선에 담는다#
화면 목록보다 왜 필요한지, 원천과 책임자, 실패 조건과 완료 증거를 함께 기록합니다.
| 영역 | 필수 질문 | 산출물 | 누락 위험 |
|---|---|---|---|
| 목표·사용자 | 누가 어떤 결정을·과업을 하나 | 성과 가설·여정·우선순위 | 페이지 수가 목표를 대체 |
| 콘텐츠·구조 | 원천·승인·언어·수명은 | 인벤토리·사이트맵·모델 | 오픈 직전 자료 지연 |
| 기능·데이터 | 상태·권한·연동·오류는 | 흐름·데이터·경계 계약 | 정상 화면만 견적 |
| 품질·운영 | 접근성·SEO·보안·성능·복구는 | 검수·이관·런북 기준 | 오픈 뒤 책임 공백 |
요구사항·가정·결정·변경·검수·운영 증거를 ID로 추적한다#
긴 문서의 문장을 구현 여부와 연결할 수 있도록 상태와 승인 사건을 관리합니다.
| 기록 | 필수 필드 | 연결 대상 | 종료 조건 |
|---|---|---|---|
| 요구 | ID·이유·우선순위·책임 | 사용자 과업·페이지·기능 | 승인 기준선 |
| 가정·질문 | 근거·확인자·기한·영향 | 견적·일정·위험 | 확정·제외·변경 |
| 결정·변경 | 선택지·이유·영향·승인 | 설계·계약·릴리스 | 새 기준선 반영 |
| 검수·운영 | 조건·데이터·기대·결과 | 결함·문서·지표 | 통과·예외·소유자 |
실무 시나리오: 견적 뒤 회원·승인·CRM 요구가 뒤늦게 발견됐다#
문의 폼으로 합의했지만 실제로는 거래처 로그인, 담당자 승인, 계약별 자료, CRM 양방향 상태가 필요해 범위와 보안이 크게 달라진 상황을 가정합니다.
| 단계 | 확인 질문 | 복구 | 종료 증거 |
|---|---|---|---|
| 정지 | 현재 기준선과 계약은 어디까지인가 | 미합의 구현 중단·요구 분리 | 영향 요구·산출물 목록 |
| 분해 | 사용자·상태·데이터·권한·연동은 | 여정·경계·대안·위험 분석 | 선택 가능한 범위안 |
| 재기준 | 일정·금액·품질 영향은 | 변경 승인·단계 릴리스·검수 | 계약·계획·요구 일치 |
| 재발 방지 | 초기 질문에서 왜 빠졌나 | 대표 과업 워크숍·가정 기한 | 견적 전 발견 게이트 |
요구공학·소프트웨어 인수·웹 접근성 공식 기준을 기획서의 구조 참고로 사용한다#
ISO/IEC/IEEE 29148:2018은 시스템·소프트웨어 생애주기의 요구공학 프로세스와 정보 항목을 정의하며 2024년에 현행판으로 확인됐지만 2026년 현재 개정 절차가 진행 중입니다. NIST 소프트웨어 인수 가이드는 검수 기준을 조기에 정하고 중간·최종 산출물의 인수를 계획하는 원칙을 제공합니다. WCAG 2.2는 웹 품질 요구 중 접근성을 시험 가능한 성공 기준으로 표현하는 자료입니다. 이 문서들은 프로젝트 맞춤 기획·국내 법률·계약 검토를 대신하지 않습니다.
- ISO/IEC/IEEE 29148:2018: 요구공학 프로세스·정보 항목의 국제 표준과 개정 상태
- NIST 소프트웨어 인수 가이드: 초기 검수 기준·중간 산출물·최종 인수 계획
- W3C WCAG 2.2: 웹 접근성을 시험 가능한 성공 기준으로 표현하는 공식 표준
초안·질문·발견·기준선·변경·검수·운영 인수를 하나의 요구 관리 흐름으로 만든다#
초안에는 배경·목표·비목표·사용자·대표 과업·콘텐츠 인벤토리·사이트맵·페이지 목적·기능 상태·권한·데이터·연동·알림·분석·SEO·접근성·보안·성능·법적 검토·이관·운영·예산·일정·제약을 둡니다. 확정·가설·미정·제외를 표시하고 항목마다 결정자와 기한, 견적에 적용할 기본 가정을 정합니다.
후보 업체와 발견 세션에서는 예쁜 참고 화면보다 실제 과업을 처음부터 끝까지 걷습니다. 문의 중복, 첨부 실패, 승인 거절, 외부 API 지연, 콘텐츠 미승인, 다국어 누락, 이전 URL, 관리자 실수와 장애 복구를 질문합니다. 답변은 요구 ID·선택지·영향·결정으로 남기고 범위·일정·견적 기준선을 갱신합니다.
개발 중 요구는 설계·작업·테스트와 연결하고 변경은 요청·이유·대안·일정·금액·보안·운영 영향·승인을 기록합니다. 검수 결과와 결함·예외를 같은 ID에 붙이고 오픈 뒤 콘텐츠 소유자·계정·지표·백업·장애 절차까지 인수합니다. 문서는 최신 링크와 버전·승인 상태가 보이는 단일 원천으로 운영합니다.
제안 요청 문서의 전체 구조는 개발 외주 RFP 템플릿에서 이어서 확인하세요. 요구와 의존성을 일정으로 바꾸는 법은 홈페이지 개발 기간 산정을 함께 보세요. 기준선을 계약·검수·인수에 연결하려면 홈페이지 계약·인수 체크리스트도 참고할 수 있습니다.
서로 다른 후보사가 같은 범위·가정·완료 조건으로 견적하고 대체 담당자가 추적할 수 있으면 승인한다#
대표 사용자와 과업, 콘텐츠 원천·작성·승인·이관, 페이지 목적, 기능 상태·오류, 권한, 데이터·개인정보, 외부 연동, 알림, 관리자, 검색 이전, 접근성·보안·성능, 분석, 운영·유지보수, 검수 조건과 제외·가정을 샘플링합니다. 요구마다 이유·우선순위·책임·증거가 있어야 합니다.
후보사 두 곳 이상이 같은 문서를 읽고 핵심 범위와 미정 항목을 유사하게 설명할 수 있고, 대체 담당자가 요구에서 결정·변경·설계·검수·운영 문서까지 역추적할 수 있어야 합니다. 뒤늦은 회원·CRM 요구를 변경 절차로 분해·승인·재검할 수 있을 때 기준선을 인수합니다.
핵심 요약
- ✓기획서를 화면 문서가 아니라 목표·과업·콘텐츠·데이터·품질·운영 요구 기준선으로 만든다
- ✓확정·가설·미정·제외와 견적 기본 가정·결정자·기한을 표시한다
- ✓요구 ID를 설계·변경·검수·운영 증거와 연결한다
- ✓정상 흐름뿐 아니라 오류·권한·외부 연동 지연·콘텐츠 미승인·복구를 질문한다
- ✓서로 다른 업체가 같은 범위와 완료 조건을 설명할 수 있는지로 기획서를 검증한다
자주 묻는 질문