웹사이트 구축 전 기획: 목표·콘텐츠·정보 구조를 정리하는 방법

좋은 웹사이트 기획은 화면을 많이 그리는 일이 아니라, 방문자가 해야 할 일을 콘텐츠와 구조로 명확하게 만드는 일이다. 이 글에서는 첫 코드를 작성하기 전에 목표, 사용자, 콘텐츠, 페이지 구조, URL, 접근성 기준을 하나의 실행 가능한 문서로 정리하는 방법을 다룬다.

웹사이트 구축 시리즈 1/3
이 글은 기획 단계에 집중한다. 레이아웃 원리가 먼저 필요하다면 웹 디자인 레이아웃의 기본을 함께 읽어보자.

1. 시작점은 페이지 목록이 아니라 목표다

“회사 소개, 서비스, 문의 페이지를 만든다”는 산출물 목록이지 목표가 아니다. 목표는 사이트가 만들어진 뒤 어떤 변화가 일어나야 하는지를 설명해야 한다.

좋은 목표 문장은 다음 세 가지를 포함한다.

• 누가: 가장 중요한 방문자는 누구인가
• 무엇을: 방문자가 어떤 행동을 완료해야 하는가
• 왜: 그 행동이 사용자와 운영자에게 어떤 가치를 주는가

예를 들어 “중소기업 담당자가 서비스의 적용 범위를 이해하고 상담에 필요한 정보를 남길 수 있게 한다”는 목표는 페이지 구성과 측정 방법을 함께 결정할 수 있다. 반면 “세련된 홈페이지를 만든다”는 문장은 판단 기준이 없어 프로젝트 중간에 취향 논쟁으로 흐르기 쉽다.

목표를 다음처럼 한 장에 고정해 두면 좋다.

항목	예시
핵심 사용자	처음 서비스를 검토하는 실무 담당자
해결할 질문	우리 상황에 적용 가능한가? 비용과 절차는 무엇인가?
핵심 행동	사례 확인 후 상담 요청
성공 신호	적합한 상담 요청 증가, 반복 문의 감소
제외 범위	회원 기능, 결제, 다국어는 이번 버전에서 제외

특히 제외 범위가 중요하다. 첫 버전에 모든 기능을 담으려 하면 핵심 경로가 늦게 완성된다. 지금 하지 않을 일을 명시하면 일정과 품질을 동시에 지킬 수 있다.

2. 사용자를 인구통계가 아니라 ‘상황과 질문’으로 정의한다

사용자 정의는 “30대 직장인”처럼 넓은 속성보다 방문 순간의 맥락을 적는 편이 실용적이다.

상황: 외부 제작사를 처음 비교하고 있다.
질문: 어떤 범위까지 맡길 수 있으며 결과물은 무엇인가?
불안: 기술 설명을 이해하기 어렵고 예상 비용이 불명확하다.
행동: 사례를 본 뒤 내부 공유용 정보를 저장하거나 상담을 신청한다.

이렇게 쓰면 콘텐츠 우선순위가 자연스럽게 보인다. 첫 화면에는 추상적인 슬로건보다 제공 범위와 신뢰 근거가 필요하고, 상세 페이지에는 과정·기간·준비물이 필요하다. 문의 폼에는 운영자가 실제로 답변하는 데 필요한 최소 필드만 남겨야 한다.

사용자 여정은 복잡한 다이어그램이 아니어도 된다. 아래 네 질문이면 충분하다.

1. 사용자는 어떤 경로로 들어오는가?
2. 첫 10초 안에 무엇을 이해해야 하는가?
3. 결정을 위해 어떤 근거가 필요한가?
4. 다음 행동을 완료한 뒤 무엇을 보게 되는가?

3. 콘텐츠 인벤토리부터 만든다

웹사이트가 늦어지는 흔한 이유는 코드가 아니라 콘텐츠다. 시안은 완성됐는데 실제 문구, 사례 이미지, 담당자 정보가 준비되지 않아 임시 문장으로 배포되는 경우가 많다.

현재 보유한 자료와 새로 만들 자료를 표로 정리하자.

콘텐츠	목적	소유자	상태	검토일	사용 페이지
서비스 소개	제공 범위 설명	사업 담당	초안	7/25	홈, 서비스
고객 사례	신뢰 근거	마케팅	승인 대기	7/27	홈, 사례
연락처	문의 연결	운영	완료	7/23	푸터, 문의
개인정보 안내	수집 근거 안내	운영/법무	미작성	7/28	문의

각 콘텐츠에는 반드시 소유자가 있어야 한다. “팀에서 확인”은 사실상 담당자가 없는 상태다. 이미지에는 사용 권한과 대체 텍스트 작성 여부도 함께 기록하면 공개 직전의 혼란이 줄어든다.

콘텐츠 초안을 작성할 때는 한 페이지가 하나의 핵심 질문에 답하게 한다. 첫 문단에서 결론을 보여주고, 제목만 훑어도 흐름이 이해되도록 소제목을 잡는다. Google의 SEO 시작 가이드는 사용자와 검색엔진 모두가 페이지 관계를 이해하도록 사이트를 논리적으로 구성하고 설명적인 URL을 사용하라고 안내한다. 이는 검색 기술 이전에 좋은 정보 설계의 원칙이다.

4. 정보 구조는 ‘메뉴’가 아니라 관계를 설계하는 일이다

정보 구조는 콘텐츠를 어떤 기준으로 묶고, 방문자가 현재 위치와 다음 경로를 어떻게 이해할지 정하는 작업이다. 먼저 모든 콘텐츠를 카드처럼 나열한 뒤 사용자의 언어로 그룹을 만든다.

예를 들어 제작사 사이트라면 다음처럼 시작할 수 있다.

홈
├─ 서비스
│  ├─ 웹사이트 구축
│  ├─ 운영·개선
│  └─ 디자인 시스템
├─ 작업 사례
│  └─ 사례 상세
├─ 인사이트
│  └─ 글 상세
└─ 문의

구조를 검토할 때는 다음을 확인한다.

• 같은 수준의 메뉴가 같은 분류 원칙을 따르는가
• 내부 용어보다 사용자가 검색하고 이해하는 말을 쓰는가
• 중요한 페이지가 홈에서 과도하게 멀지 않은가
• 상세 페이지에서 상위 범주와 관련 콘텐츠로 돌아갈 수 있는가
• 모바일에서도 메뉴 이름이 짧고 구별되는가

상위 메뉴를 너무 많이 만들지 말고, 방문자가 자주 선택하는 경로를 먼저 노출한다. 모든 페이지를 전역 메뉴에 넣는 대신 본문 링크, 관련 콘텐츠, 푸터를 역할에 맞게 나누는 것이 낫다.

5. 페이지 명세는 ‘섹션 목록 + 필요한 근거’로 쓴다

정보 구조가 정해지면 각 페이지를 구현 가능한 수준으로 명세한다. 화려한 와이어프레임보다 먼저 아래 항목을 작성한다.

페이지: 웹사이트 구축 서비스
목적: 제공 범위와 진행 방식을 이해시키고 상담으로 연결한다.
핵심 사용자 질문: 무엇을 어디까지 맡길 수 있는가?
필수 섹션:
  1. 한 문장 가치 제안
  2. 해결하는 문제
  3. 제공 범위
  4. 진행 과정
  5. 관련 사례
  6. 상담 안내
필요 근거: 실제 화면, 산출물 예시, 일정 범위, 담당 방식
주요 행동: 상담 요청
보조 행동: 사례 보기

이 명세가 있으면 섹션이 단지 예뻐 보여서 추가되는 일을 막을 수 있다. 각 블록은 사용자 질문에 답하거나 다음 행동을 돕는 역할을 가져야 한다.

와이어프레임은 그 다음이다. 작은 화면 폭부터 시작해 콘텐츠 순서, 제목 길이, 이미지 비율, 행동 버튼의 우선순위를 확인한다. 실제 문장 길이에 가까운 텍스트를 사용해야 레이아웃이 현실적인 제약을 드러낸다.

6. URL과 콘텐츠 모델을 미리 정한다

페이지가 몇 개 없을 때도 URL 규칙을 정해 두면 확장과 이전이 쉬워진다.

/services/website
/services/operation
/work/project-name
/insights/article-title

좋은 URL은 짧고 설명적이며, 같은 유형의 페이지는 같은 패턴을 따른다. 공개 후 URL을 바꾸면 기존 링크와 검색 색인에 영향을 주므로 초기에 합의하는 편이 비용이 적다.

반복되는 콘텐츠는 화면이 아니라 데이터 구조로 정의한다. 사례라면 제목, 요약, 문제, 해결, 결과, 이미지, 공개일, 관련 서비스 같은 필드가 필요하다. 블로그라면 작성자, 발행일, 수정일, 태그, 대표 이미지, 본문, 공개 상태를 정의할 수 있다. 이 모델은 CMS 선택과 컴포넌트 설계의 입력이 된다.

7. 접근성은 검수 항목이 아니라 기획 조건이다

접근성은 공개 직전에 도구 점수를 확인하는 것으로 끝나지 않는다. W3C WAI의 접근성 계획 가이드도 목표, 책임, 예산, 도구, 지속적인 점검을 계획 단계에서 정하도록 안내한다.

기획 문서에 최소한 다음 조건을 포함하자.

• 페이지마다 목적을 설명하는 고유한 제목이 있다.
• 제목 단계만 읽어도 문서 구조가 이해된다.
• 색상만으로 상태나 의미를 전달하지 않는다.
• 이미지·도표의 대체 설명 책임자를 정한다.
• 키보드만으로 주요 경로를 완료할 수 있어야 한다.
• 동영상에는 자막이나 동등한 텍스트 정보가 필요하다.
• 오류 메시지는 문제와 해결 방법을 함께 말한다.
• 확대, 긴 문장, 번역으로 콘텐츠가 늘어날 상황을 고려한다.

W3C의 페이지 구조 튜토리얼처럼 영역, 제목, 콘텐츠 순서를 명확히 설계하면 스크린 리더 사용자뿐 아니라 검색과 유지보수에도 도움이 된다.

8. 구현에 넘길 산출물은 작고 구체적으로 만든다

기획 완료의 기준은 문서 분량이 아니라 개발자가 모호한 결정을 다시 추측하지 않아도 되는 상태다. 다음 묶음이면 대부분의 소규모 사이트를 시작할 수 있다.

1. 목표·핵심 사용자·성공 신호 한 장
2. 사이트맵과 주요 사용자 경로
3. 페이지별 목적·섹션·주요 행동 명세
4. 콘텐츠 인벤토리와 담당자·마감일
5. URL 및 반복 콘텐츠 모델
6. 접근성·반응형·브라우저 지원 기준
7. 이번 버전의 제외 범위

결정이 바뀔 때는 문서를 조용히 덮어쓰지 말고, 무엇이 왜 바뀌었는지 짧은 변경 기록을 남긴다. 그래야 디자인과 개발이 오래된 가정을 따라가는 일을 막을 수 있다.

기획 단계 최종 체크리스트

• 사이트 목표를 사용자 행동으로 한 문장에 썼다.
• 핵심 사용자 질문과 불안을 정리했다.
• 콘텐츠마다 소유자와 준비 상태가 있다.
• 메뉴와 페이지 그룹이 사용자의 언어로 구성됐다.
• 각 페이지의 목적, 필수 섹션, 주요 행동이 정해졌다.
• URL 규칙과 반복 콘텐츠 필드를 정의했다.
• 모바일과 접근성 조건을 기획 문서에 포함했다.
• 성공을 판단할 지표와 제외 범위를 합의했다.

기획의 목적은 미래를 완벽하게 예측하는 것이 아니다. 팀이 같은 문제를 보고, 작게 만들고, 실제 사용 결과를 통해 다음 결정을 내릴 수 있게 만드는 것이다.

구축 시리즈 이어 읽기

1. 현재 글: 웹사이트 구축 전 기획
2. 디자인 시안을 웹으로 옮기는 순서: 시맨틱 HTML·토큰·컴포넌트
3. 웹사이트 구축 후 운영 설계: 측정·콘텐츠·보안·백업

참고 자료

• W3C WAI — Planning and Managing Web Accessibility
• W3C WAI — Plan
• W3C WAI — Page Structure Tutorials
• Google Search Central — SEO Starter Guide
• MDN — HTML elements reference
• Duolabs — 웹 디자인 레이아웃의 기본