“안녕하세요, 홈페이지 제작 견적 부탁드립니다.”
이메일 한 줄로 여러 제작 업체에 문의를 보낸다. 며칠 후 받은 제안서들을 펼쳐보면 당황스럽다. A업체는 3개월에 3000만원을 제안하고, B업체는 1개월에 800만원을 제안하고, C업체는 6개월에 5000만원을 제안한다. 같은 “홈페이지 제작”인데 왜 이렇게 다른가?
문제는 우리가 던진 질문이 너무 막연했다는 점이다. “홈페이지 만들어주세요”라는 한 문장 안에는 수많은 변수가 숨어 있다. 어떤 유형의 사이트인지, 몇 개 페이지인지, 어떤 기능이 필요한지, 콘텐츠는 누가 준비하는지, 디자인 방향은 무엇인지 — 이 모든 것이 정의되지 않았다.
업체는 각자의 기준으로 추측해서 제안한다. 어떤 업체는 “기본적인 회사 소개 사이트”를 가정하고, 어떤 업체는 “뉴스룸 포함 풀 패키지”를 가정하고, 어떤 업체는 “템플릿 커스터마이징”을 가정한다. 당연히 제안 내용도 비용도 천차만별이 된다.
“좋은 제안을 받으려면, 먼저 좋은 질문을 던져야 한다.”
제안요청서(RFP, Request for Proposal)는 단순히 견적을 받기 위한 문서가 아니다. 우리가 무엇을 원하는지 명확히 정의하고, 업체가 그에 맞는 솔루션을 제안할 수 있게 만드는 도구다. 지난 10년간 기업 웹사이트 제작 프로젝트를 관찰하며 발견한 것은, RFP가 체계적인 프로젝트는 제안 단계부터 방향이 명확했고, 결과물의 만족도도 높았다는 점이다.
제안요청서가 필요한 이유
많은 담당자가 “그냥 업체에 전화해서 물어보면 되지, 굳이 문서로 만들어야 하나”라고 생각한다. 하지만 체계적인 RFP 없이 진행하면 다음과 같은 문제가 생긴다.
문제 1: 비교 불가능한 제안서들
각 업체가 서로 다른 기준으로 제안하면, 비교 자체가 불가능하다. A업체 제안서에는 SEO 최적화가 포함되어 있는데 B업체 제안서에는 언급이 없다. 그게 빠진 건지, 기본 포함인데 안 쓴 건지 알 수 없다. C업체는 유지보수 1년을 포함했는데 D업체는 제작만 포함했다.
결국 “어느 업체가 더 나은가”를 판단할 수 없고, “어느 업체가 더 싼가”만 보게 된다. 가장 저렴한 업체를 선택했는데, 나중에 보니 필요한 기능이 다 빠져 있어서 추가 비용을 요구한다.
문제 2: 내부 합의 없는 프로젝트
RFP를 작성하는 과정은 사실 내부 합의를 만드는 과정이다. 우리가 정확히 무엇을 만들려는지, 누가 무엇을 원하는지, 우선순위는 무엇인지를 정리하게 된다.
이 과정 없이 업체부터 선정하면, 프로젝트 중간에 계속 내부 의견이 바뀐다. “IR팀에서 투자자 정보 페이지를 넣어달래요”, “사장님이 메인 비주얼을 이렇게 바꾸래요” — 요구사항이 중간에 계속 추가되고 변경되면, 일정도 예산도 통제할 수 없게 된다.
문제 3: 업체의 역량 파악 불가
막연한 문의에는 막연한 답이 온다. “경험 많은 전문 업체입니다”, “고퀄리티 디자인을 제공합니다” — 이런 추상적인 표현만 가득하다. 정작 우리가 알고 싶은 것은 “우리 산업에 대한 이해가 있는가”, “우리가 원하는 기능을 구현할 기술력이 있는가”인데, 그것을 판단할 근거가 없다.
구체적인 RFP를 보내면, 업체가 그에 맞춰 구체적으로 답한다. 어떤 방식으로 접근할 것인지, 유사 프로젝트 경험이 있는지, 우리 요구사항을 어떻게 해결할 것인지 — 실질적인 내용으로 역량을 판단할 수 있다.
제안요청서에 반드시 포함되어야 할 7가지
효과적인 RFP는 정보의 나열이 아니라, 업체가 우리를 이해하고 적절한 솔루션을 제안할 수 있게 만드는 구조를 갖춰야 한다.
1. 프로젝트 배경 및 목적
업체가 가장 먼저 이해해야 하는 것은 “왜 지금 이 프로젝트를 하는가”다. 단순히 “홈페이지가 오래되어서”가 아니라, 그 이면의 진짜 이유를 설명해야 한다.
포함할 내용:
- 현재 홈페이지 현황 (있다면 URL, 제작 시기, 주요 문제점)
- 리뉴얼 또는 신규 제작을 결정한 계기
- 해결하고 싶은 구체적 문제
- 새 홈페이지로 달성하려는 목표
좋은 예시:
현재 홈페이지는 2019년 제작되었으며, 모바일 최적화가 되어 있지 않아
모바일 방문자 이탈률이 70%에 달합니다. 또한 검색 엔진에서 회사명으로만
검색 가능하며, 산업 관련 키워드로는 노출되지 않습니다.
2025년 신사업 진출에 맞춰, B2C 고객도 타겟할 수 있는 홈페이지가 필요합니다.
기존 B2B 중심 메시지에서 벗어나, 일반 소비자도 이해할 수 있는
콘텐츠 중심 사이트로 전환하려 합니다.이렇게 쓰면 업체는 “모바일 우선 설계”, “SEO 최적화”, “B2C 메시징”, “콘텐츠 중심 구조”가 핵심임을 이해하고 제안할 수 있다.
2. 타겟 사용자 및 주요 이용 시나리오
홈페이지는 누가 보는가? 그들은 무엇을 찾으려 오는가? 방문 후 어떤 행동을 취하길 바라는가? 이것이 명확해야 정보 구조와 디자인 방향이 잡힌다.
포함할 내용:
- 주요 타겟 사용자 (1순위, 2순위 구분)
- 각 타겟의 방문 목적
- 사이트에서 찾으려는 정보
- 방문 후 기대하는 행동 (문의, 다운로드, 구매 등)
좋은 예시:
1순위 타겟: 잠재 B2B 고객 (구매 담당자)
- 방문 목적: 우리 제품의 기술 스펙 및 레퍼런스 확인
- 필요 정보: 제품 상세 정보, 기술 문서, 도입 사례, 견적 문의
- 기대 행동: 기술 자료 다운로드, 상담 신청
2순위 타겟: 구직자
- 방문 목적: 회사 문화 및 채용 정보 확인
- 필요 정보: 회사 비전, 복리후생, 채용 공고
- 기대 행동: 채용 공고 조회, 지원서 제출이 정보가 있으면 업체는 “제품 정보를 상세히, 기술 문서는 다운로드 가능하게, 채용 섹션은 별도 구성”하는 방향으로 제안할 수 있다.
3. 사이트 구조 및 필요 페이지
몇 개 페이지가 필요한지, 어떤 카테고리로 구성할 것인지를 대략적으로라도 정리해야 한다. 완벽한 사이트맵이 아니어도 괜찮다. 우리가 생각하는 대략적인 구조만 제시해도, 업체가 그것을 기반으로 제안할 수 있다.
포함할 내용:
- 주요 메뉴 구성 (1depth)
- 각 메뉴 아래 예상 페이지 목록
- 특별히 강조하고 싶은 섹션
- 참고할 만한 벤치마크 사이트 (구조 측면)
좋은 예시:
[메인 메뉴 구성]
1. 회사소개
- 대표 인사말
- 경영 철학
- 연혁
- 조직도
- 오시는 길
2. 사업 영역
- 사업 분야 A
- 사업 분야 B
- 사업 분야 C
3. 제품·서비스
- 제품 카테고리별 상세 페이지 (약 15개)
- 각 제품마다 스펙, 특징, 사례 포함
4. 뉴스룸
- 보도자료
- 공지사항
- 블로그 (산업 인사이트)
5. 채용
- 인재상
- 복리후생
- 채용 공고
[특이사항]
- 뉴스룸은 담당자가 직접 업데이트할 수 있어야 함
- 제품 페이지는 필터/검색 기능 필요4. 필요한 기능 및 기술 요구사항
단순 정보 제공 사이트인지, 특정 기능이 필요한 사이트인지에 따라 개발 범위가 완전히 달라진다. 필요한 기능을 구체적으로 나열해야 정확한 견적을 받을 수 있다.
포함할 내용:
- 필수 기능 (반드시 구현되어야 함)
- 선택 기능 (예산 범위 내에서 검토)
- 기술적 요구사항 (반응형, CMS, SEO 등)
- 외부 시스템 연동 필요 여부
좋은 예시:
[필수 기능]
- 반응형 웹 (모바일, 태블릿, PC 대응)
- 관리자 페이지 (담당자가 뉴스, 채용공고 직접 등록)
- 검색 기능 (전체 사이트 내 검색)
- 다국어 (한국어/영어, 향후 중국어 추가 가능성)
- SEO 최적화 (메타태그, 사이트맵, 스키마 마크업)
[선택 기능]
- 제품 비교 기능
- 다운로드 센터 (기술 문서, 카탈로그)
- 간단한 문의 폼
[기술 요구사항]
- CMS 필요 (워드프레스 선호하나, 다른 솔루션 제안 가능)
- 페이지 로딩 속도 3초 이내
- 웹 접근성 준수
- 크롬, 사파리, 엣지 최신 2개 버전 지원5. 디자인 방향 및 브랜드 가이드
“예쁘게 만들어주세요”는 방향이 아니다. 우리 브랜드가 어떤 느낌을 주길 원하는지, 어떤 톤을 추구하는지를 구체적으로 전달해야 업체가 그에 맞는 디자인을 제안할 수 있다.
포함할 내용:
- 브랜드 키워드 (예: 신뢰, 혁신, 전문성, 친근함)
- 선호하는 디자인 스타일
- 참고 사이트 (디자인 측면, 왜 좋은지 설명 포함)
- 기존 브랜드 가이드 (있다면)
- 피해야 할 스타일
좋은 예시:
[브랜드 키워드]
- 신뢰: 30년 업력의 안정적 파트너
- 전문성: B2B 산업재 분야 기술 리더
- 미래 지향: 지속가능성에 투자
[디자인 방향]
- 보수적이지만 답답하지 않은
- 깔끔하고 정돈된 느낌
- 과도한 장식 지양, 콘텐츠 가독성 우선
[참고 사이트]
- CJ 기업 홈페이지: 콘텐츠 중심 레이아웃, 읽기 편한 타이포그래피
- 삼성전자 제품 사이트: 제품 이미지 활용 방식
- (단, 우리는 B2B이므로 더 차분한 톤 필요)
[피해야 할 스타일]
- 지나치게 화려하거나 트렌디한 디자인
- 애니메이션 과다 사용
- 스타트업 느낌의 캐주얼한 톤6. 프로젝트 일정 및 예산 범위
언제까지 오픈해야 하는지, 예산은 어느 정도인지를 명시하면 업체가 현실적인 제안을 할 수 있다. 일정이 촉박하면 단계적 오픈을 제안할 수 있고, 예산이 제한적이면 우선순위를 조정한 제안을 할 수 있다.
포함할 내용:
- 희망 오픈 시기 (또는 마감 시한)
- 주요 마일스톤 (킥오프, 디자인 승인, 개발 완료 등)
- 예산 범위 (있다면)
- 예산에 포함되어야 할 항목 (제작비, 유지보수, 교육 등)
좋은 예시:
[희망 일정]
- 킥오프: 2025년 3월 15일
- 오픈 목표: 2025년 6월 1일
- (신사업 발표 시기에 맞춰 오픈 필요)
[주요 마일스톤]
- 디자인 시안 1차: 킥오프 후 3주
- 디자인 최종 승인: 킥오프 후 5주
- 개발 완료: 킥오프 후 10주
- 최종 검수 및 오픈: 킥오프 후 12주
[예산]
- 총 예산 범위: 2천만원대 중반 (내부 승인 기준)
- 포함 범위: 디자인, 개발, 초기 콘텐츠 입력 지원
- 별도 협의: 사진 촬영, 영상 제작, 장기 유지보수예산을 명시하지 않으면 업체마다 천차만별로 제안하지만, 범위를 제시하면 그 안에서 최적의 솔루션을 제안한다.
7. 제안서 제출 요구사항
업체가 제안서를 어떤 형식으로, 어떤 내용을 포함해서 제출해야 하는지 명시하면, 제안서들을 비교하기 쉬워진다.
포함할 내용:
- 제안서 제출 기한
- 제안서 형식 (페이지 제한, 파일 형식)
- 반드시 포함되어야 할 항목
- 평가 기준 (가능하면)
- 질의응답 방법
좋은 예시:
[제출 기한]
- 2025년 3월 10일 18시까지
[제안서 형식]
- PDF 파일
- 분량 제한 없음 (단, 핵심 내용 위주로 간결하게)
[필수 포함 항목]
1. 회사 소개 및 유사 프로젝트 실적
2. 프로젝트 이해도 및 접근 방법
3. 제안 사이트맵 및 주요 기능 설명
4. 디자인 방향 제안 (레퍼런스 또는 무드보드)
5. 개발 방법론 및 기술 스택
6. 프로젝트 일정 및 단계별 산출물
7. 투입 인력 및 역할
8. 상세 견적 (항목별 단가 포함)
9. 유지보수 및 사후 지원 계획
[평가 기준]
- 프로젝트 이해도: 30%
- 기술 역량 및 실적: 25%
- 제안 내용의 적합성: 25%
- 비용: 20%
[질의응답]
- 이메일: project@company.com
- 질문 마감: 3월 5일
- 답변은 전체 참여 업체에 공유자주 하는 실수들
RFP를 처음 작성하는 담당자들이 반복하는 실수가 있다. 이를 미리 알고 피하면 훨씬 효과적인 RFP를 만들 수 있다.
실수 1: 너무 짧거나 너무 길다
한 페이지짜리 간략한 요청서는 정보가 부족해서, 50페이지짜리 상세한 문서는 복잡해서 — 둘 다 문제다. 적정 분량은 5~10페이지 정도다. 핵심 정보는 명확하게, 세부 사항은 필요한 만큼만 담는다.
실수 2: 기술 용어 남발
비개발자 담당자가 인터넷에서 본 기술 용어를 무분별하게 나열하면, 오히려 혼란을 준다. “React 기반 SPA로 GraphQL API 연동하여 JAMstack 아키텍처로” — 이런 식으로 쓰면, 우리가 정확히 이해하지 못하는 기술을 요구하는 것처럼 보인다.
기술적 요구사항은 목적 중심으로 쓴다. “빠른 페이지 로딩”, “담당자가 직접 수정 가능한 구조”, “검색 엔진 최적화” — 이렇게 쓰면 업체가 적절한 기술을 제안한다.
실수 3: 경쟁사 벤치마크만 나열
“A사, B사, C사 홈페이지처럼 만들어주세요”라고만 쓰면, 업체는 그 사이트들을 복사한다. 중요한 것은 “왜 그 사이트가 좋은지”, “어떤 부분을 참고하고 싶은지”를 설명하는 것이다.
“A사 홈페이지의 제품 필터 기능이 사용하기 편해서”, “B사의 모바일 메뉴 구조가 직관적이어서” — 이렇게 구체적으로 쓴다.
실수 4: 예산 숨기기
예산을 말하면 업체가 그 금액에 맞춰 부풀릴 거라는 우려로 예산을 숨기는 경우가 많다. 하지만 예산 없이 제안 받으면, 우리 범위를 크게 벗어난 제안들이 와서 시간만 낭비한다.
예산 범위를 제시하면, 업체는 그 안에서 최적의 솔루션을 제안한다. “3천만원짜리 기능을 2천만원에”가 아니라, “2천만원으로 가장 효과적인 구성”을 제안하게 된다.
실수 5: 내부 미합의 상태로 발송
내부 이해관계자들과 합의 없이 담당자 혼자 작성한 RFP는, 나중에 “사실 우리 팀장님은 다른 생각이세요”로 뒤집힌다. RFP를 작성하면서 주요 의사결정권자들에게 검토받고, 핵심 요구사항에 대한 합의를 먼저 만들어야 한다.
업체 선정 후에도 RFP는 중요하다
RFP의 역할은 제안서를 받는 것으로 끝나지 않는다. 프로젝트 전체 기간 동안 기준점 역할을 한다.
계약서의 기초
RFP에 명시한 요구사항과 업체가 제안한 내용이 계약서의 기초가 된다. “○○ 기능은 포함입니다”라는 구두 약속이 아니라, RFP와 제안서에 명시된 내용이 계약 범위가 된다.
범위 관리 도구
프로젝트 중간에 “이것도 추가해주세요”라는 요구가 나올 때, RFP를 기준으로 판단한다. RFP에 명시되었으면 원래 범위 안이고, 명시되지 않았으면 추가 범위다. 이 기준이 명확해야 범위가 무한정 확장되는 것을 막을 수 있다.
검수 기준
완성된 사이트가 RFP의 요구사항을 충족하는지 검수할 때도 RFP가 기준이 된다. “반응형 웹”이 요구사항이었으면, 모바일에서 제대로 작동하는지 확인한다. “담당자가 직접 수정 가능”이 요구사항이었으면, 실제로 담당자가 관리자 페이지에서 수정할 수 있는지 테스트한다.
좋은 제안은 좋은 질문에서 나온다
홈페이지 제작 프로젝트의 성공은 업체 선정보다 훨씬 앞서, RFP를 작성하는 단계에서 결정된다. 우리가 무엇을 원하는지 명확하지 않으면, 업체가 아무리 좋아도 우리가 원하는 결과를 만들 수 없다.
“홈페이지 만들어주세요” 한 줄이 아니라, “우리는 이런 목적으로, 이런 타겟을 위해, 이런 기능을 가진 사이트가 필요합니다”라고 구체적으로 요청해야 한다. 그래야 업체는 우리 상황에 맞는, 비교 가능한, 실질적인 제안을 한다.
RFP 작성은 번거롭고 시간이 걸리는 작업이다. 하지만 이 시간이 나중에 프로젝트 지연, 범위 분쟁, 결과물 불만족으로 낭비될 수많은 시간을 아껴준다.
우리 회사 RFP, 어떻게 시작할까요?
만약 지금 홈페이지 제작을 준비 중이라면, 업체 검색보다 RFP 작성부터 시작하길 권한다. 7가지 필수 항목을 하나씩 채워가다 보면, 우리가 진짜 원하는 것이 무엇인지 명확해진다. 그 명확함이 좋은 제안을, 좋은 파트너를, 좋은 결과를 만든다.
스튜디오파티클 대표 박용덕은 기업 뉴스룸과 브랜드 웹사이트 구축에서 20년간 대기업 및 중견기업과 함께 일해왔다. 우리가 가장 좋은 결과를 낸 프로젝트는 모두 명확한 RFP에서 시작되었다. 고객이 무엇을 원하는지 정확히 알 때, 우리는 그 이상을 제안할 수 있기 때문이다.
효과적인 RFP 작성을 함께 준비하고 싶다면, 지금이 적기다.