Project Discovery

홈페이지 제작 기획 단계 | 목표·범위·구조를 정리하는 출발점

좋은 홈페이지는 디자인부터 시작되지 않습니다.
무엇을 왜 만들고, 누구에게 보여주며, 어떤 결과를 기대하는지 먼저 정리해야 이후 구조 설계와 구현도 흔들리지 않습니다.

DISCOVERY ANSWER

홈페이지 프로젝트 기획은 무엇을 확정하는 단계인가요?

디자인을 시작하기 전, 목표·핵심 사용자·Desired Identity·범위·자료 책임·승인자·일정·리스크를 하나의 Project Brief로 정리하고 다음 정보 구조·UX 설계에 들어갈 조건을 확정하는 단계입니다.

좋은 Discovery는 아이디어를 많이 만드는 회의가 아닙니다. 무엇을 이번 런칭에 포함하고, 무엇을 제외하거나 이후로 미루며, 누가 사실을 검수하고 최종 승인하는지를 문서화해 이후 디자인과 WordPress 구축이 같은 기준으로 움직이게 합니다.

핵심 결과물: 승인 가능한 Project Brief · 미확정 항목 목록 · 다음 단계 진입 조건

01GOAL
02SCOPE
03RESPONSIBILITY
04APPROVAL

ROLE SEPARATION

체크리스트·RFP·Discovery는 서로 다른 단계입니다.

비슷해 보이지만 각 문서와 페이지가 해결하는 질문은 다릅니다. 역할을 분리해야 검색의도와 고객 여정이 겹치지 않습니다.

BEFORE CONTACT

기업 홈페이지 체크리스트

고객사가 목표·자료·기능·운영 준비도를 스스로 점검하는 사전 진단입니다.

준비도 확인

VENDOR REQUEST

홈페이지 RFP

여러 제작사에 동일한 조건으로 제안과 견적을 요청하기 위한 발주 문서입니다.

RFP 가이드

NEXT GATE

정보 구조·UX 설계

승인된 Brief를 메뉴·URL·페이지 역할·메시지·CTA와 대표 화면 구조로 구체화합니다.

다음 단계 보기

EIGHT DECISIONS

Discovery에서 8개의 결정을 순서대로 내립니다.

각 결정은 다음 단계의 입력값이 됩니다. 미확정 항목은 숨기지 않고 책임자·검수일·영향 범위와 함께 별도로 관리합니다.

01

목표·성공지표

질문왜 만드는가?
결정사업 목적·구축 성공·이해·전환 기준
산출물Goal Statement

02

핵심 사용자·구매상황

질문누구의 어떤 상황인가?
결정핵심 고객·검색·비교·문의 맥락
산출물Audience Brief

03

Desired Identity

질문어떤 회사로 보여야 하는가?
결정현재 인상·원하는 인상·차별화 방향
산출물Identity Direction

04

서비스·메시지 우선순위

질문무엇을 먼저 말할 것인가?
결정핵심 서비스·대표 문장·증거 순서
산출물Message Hierarchy

05

범위·제외·확장

질문이번 런칭에 어디까지 담는가?
결정포함·제외·선택·향후 확장
산출물Scope Map

06

콘텐츠·근거·사실검수

질문누가 무엇을 준비하고 확인하는가?
결정원고·이미지·사례·법무·기술 검수
산출물Content Responsibility

07

승인·일정·리스크

질문누가 언제 결정하는가?
결정최종 승인자·마일스톤·위험 대응
산출물Risk & Approval

08

Project Brief·착수 승인

질문언제 다음 단계로 넘어가는가?
결정미확정 목록·착수 조건·UX 인계
산출물Approved Project Brief

DISCOVERY MAP

질문·결정·산출물을 한 화면에서 연결합니다.

‘무엇을 논의했는가’보다 ‘무엇이 확정됐고 다음 단계에 무엇을 넘기는가’를 기준으로 Discovery를 운영합니다.

홈페이지 Discovery 8개 결정 지도
홈페이지 Discovery 8개 결정 지도 모바일
IDENTITY BEFORE DECORATION

디자인 취향보다 Desired Identity를 먼저 정의합니다.

참고 사이트의 색과 효과를 고르는 것만으로는 기업의 인상을 설계하기 어렵습니다. 현재 인식과 원하는 인식의 차이를 먼저 정의한 뒤 화면 언어로 번역합니다.

CURRENT IDENTITY

현재 어떤 회사로 보이는가

기존 사이트·소개자료·영업자료에서 전달되는 인상, 강점과 혼선을 확인합니다.

DIGITAL EXPRESSION

화면에서는 어떻게 구현할 것인가

타이포그래피·여백·색·이미지·레이아웃·반응형 원칙으로 기업 인상을 일관되게 구현합니다.

프리미엄 디자인은 장식의 양이 아니라, 원하는 기업 인상을 모든 화면에서 흔들림 없이 구현하는 체계입니다.
PROJECT BRIEF

Discovery의 결과물은 ‘Project Brief’입니다.

회의록이 아니라 디자인·콘텐츠·WordPress 구축·QA가 같은 기준으로 움직이도록 만드는 승인 문서입니다.

목표·성공지표

왜 만드는지, 무엇이 정상 구축인지, 고객이 무엇을 이해하고 어떤 행동을 해야 하는지 정리합니다.

사용자·구매상황

핵심 고객이 검색·비교·검토·문의하는 상황과 가장 먼저 확인해야 할 정보를 정리합니다.

메시지·증거 우선순위

대표 문장, 핵심 서비스, 사례·인증·실적·기술자료 등 신뢰 증거의 순서를 정합니다.

사이트맵·범위·제외

페이지 역할, 포함·선택·별도견적·향후 확장을 구분해 이번 런칭의 경계를 정합니다.

콘텐츠·사실검수 책임

Working Draft와 고객 제공 원본, 최종 사실검수 책임자, 미확정 항목의 기한을 정합니다.

RESPONSIBILITY & APPROVAL

웹버스·고객사·공동승인 책임을 분리합니다.

웹버스는 질문과 구조를 제안하고, 고객사는 기업 사실과 우선순위를 검수하며, 중요한 범위·메시지·일정은 공동으로 승인합니다.

Discovery 책임 승인 매트릭스
Discovery 책임 승인 매트릭스 모바일
SCOPE & CHANGE CONTROL

포함 범위뿐 아니라 변경 기준까지 먼저 정합니다.

프로젝트가 흔들리는 가장 큰 원인은 처음의 아이디어가 부족해서가 아니라, 승인 이후 페이지·기능·자료·언어·연동 요구가 계속 바뀌기 때문입니다.

INCLUDED

이번 런칭 포함

승인된 페이지·기능·언어·콘텐츠·QA 범위

CLIENT PROVIDED

고객 제공·검수

원고·이미지·사례·법무·기술 사실과 내부 승인

OPTION / QUOTE

선택·별도견적

번역·촬영·카피·고급 연동·대규모 데이터 이전

LATER PHASE

향후 확장

이번 런칭 이후 추가할 서비스·콘텐츠·언어·운영 기능

자료 지연원고·이미지·사례·번역의 책임자와 기한
승인자 변경실무 의견과 최종 결정권자의 구분
범위 확대페이지·기능·언어가 늘어날 때 영향 확인
연동 미확정API·결제·ERP·회원·외부 시스템 사양
사실검수 지연법률·의료·기술·재무 정보의 공개 승인
검색자산 손실기존 URL·GSC·canonical·301 관계

변경 원칙: 승인 이후 요청은 단순 보완인지 범위 변경인지 구분하고, 다음 단계·일정·비용·QA에 미치는 영향을 먼저 확인합니다.
DISCOVERY DEPTH

프로젝트 유형에 따라 Discovery의 깊이가 달라집니다.

같은 페이지 수라도 웹버스가 책임지는 사이트맵·콘텐츠·검색자산·다국어·이전·연동·승인 체계의 깊이가 다릅니다.

01 제작형

준비된 자료를 프리미엄 사이트로 구축

고객 제공 사이트맵·원고·이미지를 기준으로 브랜드 방향·디자인·WordPress 구축 범위를 확정합니다.

01 제작형 보기

검색자산 리뉴얼

기존 URL과 검색신호부터 보호

GSC·URL 인벤토리·canonical·301·콘텐츠·내부링크를 진단해 유지·보강·통합·이전 기준을 확정합니다.

리뉴얼 기준 보기

Enterprise·글로벌

다국어·데이터·연동·다수 승인자 통합

언어·시장·조직 책임·데이터 이전·외부 시스템·보안·접근성·PM·운영체계를 별도 구조로 정의합니다.

범위 상담

HANDOFF TO UX

Project Brief가 승인되면 정보 구조·UX 설계로 넘어갑니다.

Discovery가 ‘무엇을 왜 만들 것인가’를 정한다면, 다음 단계는 그 결정을 메뉴·URL·페이지 역할·메시지·CTA와 대표 화면 구조로 구체화합니다.

GoalAudienceDesired IdentityScopeContentResponsibilityRiskProject BriefUX

‘프리미엄 홈페이지 제작’은 한 번 만들고 끝나는 작업이 아니라, 영업과 신뢰를 쌓는 기반입니다. 상담에서 지금 단계에 필요한 것만 추려서 로드맵 형태로 정리해드립니다.

F.A.Q
프로젝트 기획

QUESTIONS

홈페이지 프로젝트 기획 단계에서는 무엇을 확정하나요?

제작 목적, 핵심 사용자, Desired Identity, 서비스와 메시지 우선순위, 사이트맵과 기능 범위, 콘텐츠 준비와 사실검수 책임, 최종 승인자, 일정과 주요 위험을 정리합니다. 이 결과를 Project Brief로 승인한 뒤 정보 구조·UX 설계로 넘어갑니다.

완벽한 자료가 없어도 Discovery를 시작할 수 있나요?

가능합니다. 다만 준비된 자료와 미확정 항목을 구분해야 합니다. 웹버스는 회사소개, 서비스 자료, 기존 사이트, 참고 사례, 필수 기능, 일정과 담당자를 확인하고 부족한 항목은 자료 목록과 책임자, 검수 기한으로 정리합니다.

기업 홈페이지 체크리스트와 Discovery는 어떻게 다른가요?

체크리스트는 고객사가 현재 준비 수준과 빠진 항목을 스스로 확인하는 사전 진단입니다. Discovery는 실제 프로젝트 착수 후 그 자료를 바탕으로 목표, 우선순위, 범위, 책임, 승인 기준과 다음 단계 진입 조건을 함께 확정하는 과정입니다.

RFP 작성과 Discovery는 어떻게 다른가요?

RFP는 여러 제작사에 동일한 조건으로 제안과 견적을 요청하기 위한 발주 문서입니다. Discovery는 선정된 프로젝트의 실제 조건을 더 구체화해 Project Brief, 범위, 역할, 승인자, 위험과 다음 작업 기준을 확정하는 단계입니다.

Project Brief에는 어떤 내용이 들어가나요?

프로젝트 목표와 성공기준, 핵심 사용자와 구매상황, Desired Identity, 핵심 서비스와 메시지, 사이트맵과 포함·제외 범위, 콘텐츠와 근거 자료, 고객사와 웹버스의 책임, 일정·승인·리스크, 미확정 항목과 다음 단계 조건이 포함됩니다.

페이지 수와 기능 범위는 언제 확정하나요?

Discovery에서 핵심 페이지 역할과 필수 기능을 먼저 정리하고, 이번 런칭에 포함할 범위와 선택 항목, 이후 확장 항목을 구분합니다. 세부 구현 방식은 정보 구조·UX 설계와 기술 검토를 거쳐 최종 명세로 이어질 수 있습니다.

디자인 취향은 Discovery에서 어떻게 다루나요?

참고 사이트의 색이나 효과만 고르는 방식보다 기업이 현재 어떤 인상으로 보이는지, 앞으로 어떤 회사로 인식되어야 하는지, 무엇을 피해야 하는지를 먼저 정리합니다. 이후 타이포그래피, 색, 이미지와 레이아웃은 Desired Identity를 구현하는 방향으로 설계합니다.

고객사와 웹버스의 책임은 어떻게 나누나요?

웹버스는 질문 구조, 페이지 역할, 우선순위, Working Draft와 승인 게이트를 제안합니다. 고객사는 회사·서비스·사례·기술·법률 정보를 사실 기준으로 검수하고 내부 승인자를 지정합니다. 중요한 범위와 메시지, 일정은 공동 승인합니다.

승인자가 여러 명이면 어떻게 진행하나요?

실무 담당자, 콘텐츠 책임자, 기술 또는 법무 검수자, 최종 승인자를 구분하고 의견 취합 창구를 정합니다. 단계별 승인 기한과 최종 결정권자를 먼저 정하면 후반부에 상충하는 의견이 추가되어 범위와 일정이 흔들리는 위험을 줄일 수 있습니다.

리뉴얼 프로젝트는 무엇을 추가로 확인하나요?

기존 URL, GSC 클릭과 노출, canonical, 301 리디렉션, 내부링크, 다국어 관계, 다운로드 자료, 문의와 전환 페이지를 함께 확인합니다. 유지·보강·통합·이전·삭제 후보를 구분한 뒤 검색자산을 보호하는 범위를 Project Brief에 반영합니다.

Discovery 이후 범위가 바뀌면 어떻게 되나요?

승인 이후 페이지, 기능, 언어, 콘텐츠 책임이나 외부 연동이 바뀌면 다음 단계와 일정, 비용, QA 범위에 미치는 영향을 먼저 확인합니다. 단순 보완인지 별도 범위 변경인지 구분한 뒤 필요한 경우 일정과 견적을 다시 협의합니다.

Discovery 다음 단계는 무엇인가요?

승인된 Project Brief를 기준으로 정보 구조·UX 설계에 들어갑니다. 이 단계에서는 페이지 역할, 메뉴와 URL 계층, 핵심 메시지 배치, 사용자 흐름, CTA와 대표 화면 구조를 구체화하고 이후 디자인과 WordPress 구축의 기준을 만듭니다.