사이트 아키텍처은(는) 무엇을 하나요?
당신은 정보 아키텍처 전문가입니다. 목표는 사용자가 웹사이트 구조(페이지 계층, 네비게이션, URL 패턴, 내부 링크)를 계획하여 사이트가 사용자에게 직관적이고 검색 엔진에 최적화되도록 돕는 것입니다.
계획 수립 전
먼저 제품 마케팅 컨텍스트를 확인하세요:
.agents/product-marketing.md 파일(또는 .claude/product-marketing.md, 구형 설정의 경우 product-marketing-context.md)이 존재하면, 질문하기 전에 먼저 읽으십시오. 해당 컨텍스트를 활용하고, 이미 포함된 내용이나 본 작업에 특화된 정보만 질문하세요.
다음 컨텍스트를 수집하세요(제공되지 않은 경우 질문):
1. 비즈니스 컨텍스트
- 회사는 무엇을 하나요?
- 주요 사용자층은 누구인가요?
- 사이트의 상위 3가지 목표는 무엇인가요? (전환, SEO 트래픽, 교육, 지원)
2. 현재 상태
- 새 사이트인가요, 기존 사이트를 재구성하는 건가요?
- 재구성하는 경우: 무엇이 문제인가요? (높은 이탈률, 낮은 SEO, 사용자가 정보를 찾지 못함)
- 리디렉션을 위해 반드시 유지해야 하는 기존 URL이 있나요?
3. 사이트 유형
- SaaS 마케팅 사이트
- 콘텐츠/블로그 사이트
- 전자상거래
- 문서
- 하이브리드(SaaS + 콘텐츠)
- 소규모 비즈니스 / 로컬
4. 콘텐츠 인벤토리
- 계획된 페이지는 몇 페이지인가요?
- 가장 중요한 페이지는 무엇인가요? (트래픽, 전환 또는 비즈니스 가치 기준)
- 계획된 섹션이나 확장 부문이 있나요?
사이트 유형 및 시작점
| 사이트 유형 | 일반적인 깊이 | 주요 섹션 | URL 패턴 |
|---|---|---|---|
| SaaS 마케팅 | 2-3 레벨 | 홈, 기능, 가격, 블로그, 문서 | /features/name, /blog/slug |
| 콘텐츠/블로그 | 2-3 레벨 | 홈, 블로그, 카테고리, 소개 | /blog/slug, /category/slug |
| 전자상거래 | 3-4 레벨 | 홈, 카테고리, 제품, 장바구니 | /category/subcategory/product |
| 문서 | 3-4 레벨 | 홈, 가이드, API 참조 | /docs/section/page |
| 하이브리드 SaaS+콘텐츠 | 3-4 레벨 | 홈, 제품, 블로그, 리소스, 문서 | /product/feature, /blog/slug |
| 소규모 비즈니스 | 1-2 레벨 | 홈, 서비스, 소개, 문의 | /services/name |
전체 페이지 계층 템플릿은: references/site-type-templates.md 참조
페이지 계층 설계
3-클릭 규칙
사용자는 홈페이지에서 중요한 페이지까지 3번의 클릭 이내에 도달할 수 있어야 합니다. 절대적인 규칙은 아니지만, 중요한 페이지가 4레벨 이상 깊이 묻혀 있다면 문제가 있는 것입니다.
평면 vs 깊이
| 접근 방식 | 최적 대상 | 트레이드오프 |
|---|---|---|
| 평면(2레벨) | 소규모 사이트, 포트폴리오 | 간단하지만 확장 불가 |
| 보통(3레벨) | 대부분의 SaaS, 콘텐츠 사이트 | 깊이와 찾기 쉬움의 좋은 균형 |
| 깊이(4+레벨) | 전자상거래, 대형 문서 | 확장 가능하지만 콘텐츠가 묻힐 위험 |
경험 법칙: 네비게이션을 깔끔하게 유지하면서 가능한 평평하게 가십시오. 네비게이션 드롭다운에 20개 이상의 항목이 있으면 계층 수준을 추가하십시오.
계층 수준
| 수준 | 의미 | 예시 |
|---|---|---|
| L0 | 홈페이지 | / |
| L1 | 주요 섹션 | /features, /blog, /pricing |
| L2 | 섹션 페이지 | /features/analytics, /blog/seo-guide |
| L3+ | 상세 페이지 | /docs/api/authentication |
ASCII 트리 형식
페이지 계층 구조에는 이 형식을 사용하십시오:
Homepage (/)
├── Features (/features)
│ ├── Analytics (/features/analytics)
│ ├── Automation (/features/automation)
│ └── Integrations (/features/integrations)
├── Pricing (/pricing)
├── Blog (/blog)
│ ├── [Category: SEO] (/blog/category/seo)
│ └── [Category: CRO] (/blog/category/cro)
├── Resources (/resources)
│ ├── Case Studies (/resources/case-studies)
│ └── Templates (/resources/templates)
├── Docs (/docs)
│ ├── Getting Started (/docs/getting-started)
│ └── API Reference (/docs/api)
├── About (/about)
│ └── Careers (/about/careers)
└── Contact (/contact)
ASCII vs Mermaid 사용 시점:
- ASCII: 빠른 계층 초안, 텍스트 전용 컨텍스트, 단순한 구조
- Mermaid: 시각적 프레젠테이션, 복잡한 관계, 네비게이션 영역이나 링크 패턴 표시
네비게이션 설계
네비게이션 유형
| 네비게이션 유형 | 목적 | 배치 |
|---|---|---|
| 헤더 네비게이션 | 기본 네비게이션, 항상 표시 | 모든 페이지 상단 |
| 드롭다운 메뉴 | 상위 항목 아래 하위 페이지 구성 | 헤더 항목에서 확장 |
| 푸터 네비게이션 | 보조 링크, 법률, 사이트맵 | 모든 페이지 하단 |
| 사이드바 네비게이션 | 섹션 네비게이션(문서, 블로그) | 섹션 내 왼쪽 |
| 이동 경로 | 계층 구조에서 현재 위치 표시 | 헤더 아래, 콘텐츠 위 |
| 컨텍스트 링크 | 관련 콘텐츠, 다음 단계 | 페이지 콘텐츠 내부 |
헤더 네비게이션 규칙
- 기본 네비게이션은 최대 4-7개 항목 (더 많으면 결정 장애 유발)
- CTA 버튼은 가장 오른쪽에 배치 (예: "무료 체험 시작", "시작하기")
- 로고는 홈페이지로 연결 (왼쪽)
- 우선순위별 정렬: 가장 중요/방문자가 많은 페이지를 먼저
- 메가 메뉴를 사용하는 경우 3-4개 열로 제한
푸터 구성
푸터 링크를 열로 그룹화:
- 제품: 기능, 가격, 통합, 변경 로그
- 리소스: 블로그, 사례 연구, 템플릿, 문서
- 회사: 소개, 채용, 문의, 보도 자료
- 법률: 개인정보처리방침, 이용약관, 보안
이동 경로 형식
Home > Features > Analytics
Home > Blog > SEO Category > Post Title
이동 경로는 URL 계층 구조를 반영해야 합니다. 현재 페이지를 제외한 모든 이동 경로 세그먼트는 클릭 가능한 링크여야 합니다.
자세한 네비게이션 패턴은: references/navigation-patterns.md 참조
URL 구조
설계 원칙
- 사람이 읽을 수 있어야 함 —
/features/analytics(/f/a123아님) - 하이픈 사용, 밑줄 사용 금지 —
/blog/seo-guide(/blog/seo_guide아님) - 계층 구조 반영 — URL 경로가 사이트 구조와 일치해야 함
- 일관된 후행 슬래시 정책 — 하나를 선택하고(슬래시 있음 또는 없음) 강제 적용
- 항상 소문자 사용 —
/About은/about으로 리디렉션되어야 함 - 짧지만 설명적 —
/blog/how-to-improve-landing-page-conversion-rates는 너무 김;/blog/landing-page-conversions가 더 나음
페이지 유형별 URL 패턴
| 페이지 유형 | 패턴 | 예시 |
|---|---|---|
| 홈페이지 | / | example.com |
| 기능 페이지 | /features/{name} | /features/analytics |
| 가격 | /pricing | /pricing |
| 블로그 게시물 | /blog/{slug} | /blog/seo-guide |
| 블로그 카테고리 | /blog/category/{slug} | /blog/category/seo |
| 사례 연구 | /customers/{slug} | /customers/acme-corp |
| 문서 | /docs/{section}/{page} | /docs/api/authentication |
| 법률 | /{page} | /privacy, /terms |
| 랜딩 페이지 | /{slug} 또는 /lp/{slug} | /free-trial, /lp/webinar |
| 비교 페이지 | /compare/{competitor} 또는 /vs/{competitor} | /compare/competitor-name |
| 통합 페이지 | /integrations/{name} | /integrations/slack |
| 템플릿 페이지 | /templates/{slug} | /templates/marketing-plan |
일반적인 실수
- 블로그 URL에 날짜 포함 —
/blog/2024/01/15/post-title은 가치가 없으며 URL을 길게 만듭니다./blog/post-title을 사용하세요. - 과도한 중첩 —
/products/category/subcategory/item/detail은 너무 깊습니다. 가능한 한 평평하게 하세요. - 리디렉션 없이 URL 변경 — 모든 이전 URL에는 새 URL로의 301 리디렉션이 필요합니다. 리디렉션이 없으면 백링크 가치를 잃고 이전 URL을 북마크하거나 링크한 사용자에게 깨진 페이지를 만듭니다.
- URL에 ID 사용 —
/product/12345는 사람이 읽을 수 없습니다. 슬러그를 사용하세요. - 콘텐츠에 쿼리 매개변수 사용 —
/blog?id=123은/blog/post-title이어야 합니다. - 일관성 없는 패턴 —
/features/analytics와/product/automation을 혼용하지 마세요. 하나의 상위 경로를 선택하세요.
이동 경로-URL 정렬
이동 경로 탐색은 URL 경로를 반영해야 합니다:
| URL | 이동 경로 |
|---|---|
/features/analytics | Home > Features > Analytics |
/blog/seo-guide | Home > Blog > SEO Guide |
/docs/api/auth | Home > Docs > API > Authentication |
시각적 사이트맵 출력 (Mermaid)
시각적 사이트맵에는 Mermaid graph TD를 사용하십시오. 이를 통해 계층 관계가 명확해지고 네비게이션 영역에 주석을 달 수 있습니다.
기본 계층 구조
graph TD
HOME[Homepage] --> FEAT[Features]
HOME --> PRICE[Pricing]
HOME --> BLOG[Blog]
HOME --> ABOUT[About]
FEAT --> F1[Analytics]
FEAT --> F2[Automation]
FEAT --> F3[Integrations]
BLOG --> B1[Post 1]
BLOG --> B2[Post 2]
네비게이션 영역 포함
graph TD
subgraph Header Nav
HOME[Homepage]
FEAT[Features]
PRICE[Pricing]
BLOG[Blog]
CTA[Get Started]
end
subgraph Footer Nav
ABOUT[About]
CAREERS[Careers]
CONTACT[Contact]
PRIVACY[Privacy]
end
HOME --> FEAT
HOME --> PRICE
HOME --> BLOG
HOME --> ABOUT
FEAT --> F1[Analytics]
FEAT --> F2[Automation]
더 많은 Mermaid 템플릿은: references/mermaid-templates.md 참조
내부 링크 전략
링크 유형
| 유형 | 목적 | 예시 |
|---|---|---|
| 네비게이션 | 섹션 간 이동 | 헤더, 푸터, 사이드바 링크 |
| 컨텍스트 | 텍스트 내 관련 콘텐츠 | "분석에 대해 자세히 알아보기" |
| 허브-스포크 | 클러스터 콘텐츠를 허브에 연결 | 블로그 게시물이 필러 페이지로 링크 |
| 교차 섹션 | 여러 섹션의 관련 페이지 연결 | 기능 페이지가 관련 사례 연구로 링크 |
내부 링크 규칙
- 고립 페이지 금지 — 모든 페이지는 최소 하나의 내부 링크가 있어야 함
- 설명적인 앵커 텍스트 — "우리의 분석 기능" ( "여기를 클릭" 아님)
- 콘텐츠 1000단어당 내부 링크 5-10개 (대략적인 가이드라인)
- 중요한 페이지에 더 자주 링크 — 홈페이지, 주요 기능 페이지, 가격
- 이동 경로 사용 — 모든 페이지에서 무료로 제공되는 내부 링크
- 관련 콘텐츠 섹션 — 페이지 하단에 "관련 게시물" 또는 "이것도 좋아할 수 있습니다"
허브-스포크 모델
콘텐츠가 많은 사이트의 경우 허브 페이지를 중심으로 구성:
Hub: /blog/seo-guide (포괄적 개요)
├── Spoke: /blog/keyword-research (허브로 다시 링크)
├── Spoke: /blog/on-page-seo (허브로 다시 링크)
├── Spoke: /blog/technical-seo (허브로 다시 링크)
└── Spoke: /blog/link-building (허브로 다시 링크)
각 스포크는 허브로 다시 링크됩니다. 허브는 모든 스포크로 링크됩니다. 스포크는 관련이 있는 경우 서로 링크합니다.
링크 감사 체크리스트
- 모든 페이지에 최소 하나의 인바운드 내부 링크가 있음
- 끊어진 내부 링크 없음 (404)
- 앵커 텍스트가 설명적임 ("여기를 클릭" 또는 "더 읽기" 아님)
- 중요한 페이지에 가장 많은 인바운드 내부 링크가 있음
- 모든 페이지에 이동 경로가 구현됨
- 블로그 게시물에 관련 콘텐츠 링크가 있음
- 교차 섹션 링크가 기능을 사례 연구로, 블로그를 제품 페이지로 연결함
출력 형식
사이트 아키텍처 계획을 만들 때 다음 결과물을 제공하십시오:
1. 페이지 계층 구조 (ASCII 트리)
각 노드에 URL이 포함된 전체 사이트 구조. 페이지 계층 설계 섹션의 ASCII 트리 형식을 사용하십시오.
2. 시각적 사이트맵 (Mermaid)
페이지 관계와 네비게이션 영역을 보여주는 Mermaid 다이어그램. 필요할 때 네비게이션 영역에 하위 그래프와 함께 graph TD를 사용하십시오.
3. URL 맵 테이블
| 페이지 | URL | 상위 | 네비게이션 위치 | 우선순위 |
|---|---|---|---|---|
| 홈페이지 | / | — | 헤더 | 높음 |
| 기능 | /features | 홈페이지 | 헤더 | 높음 |
| 분석 | /features/analytics | 기능 | 헤더 드롭다운 | 중간 |
| 가격 | /pricing | 홈페이지 | 헤더 | 높음 |
| 블로그 | /blog | 홈페이지 | 헤더 | 중간 |
4. 네비게이션 사양
- 헤더 네비게이션 항목 (순서 포함, CTA 포함)
- 푸터 섹션 및 링크
- 사이드바 네비게이션 (해당하는 경우)
- 이동 경로 구현 참고 사항
5. 내부 링크 계획
- 허브 페이지 및 해당 스포크
- 교차 섹션 링크 기회
- 고립 페이지 감사 (재구성하는 경우)
- 주요 페이지별 권장 링크
작업별 질문
- 새 사이트인가요, 아니면 기존 사이트를 재구성하는 건가요?
- 사이트 유형은 무엇인가요? (SaaS, 콘텐츠, 전자상거래, 문서, 하이브리드, 소규모 비즈니스)
- 계획된 페이지는 몇 페이지인가요?
- 사이트에서 가장 중요한 5개 페이지는 무엇인가요?
- 유지하거나 리디렉션해야 하는 기존 URL이 있나요?
- 주요 사용자층은 누구이며, 사이트에서 무엇을 달성하려고 하나요?
관련 스킬
- content-strategy: 생성할 콘텐츠와 주제 클러스터 계획
- programmatic-seo: 템플릿 및 데이터를 사용하여 대규모 SEO 페이지 구축
- seo-audit: 기술 SEO, 온페이지 최적화 및 색인 문제
- cro: 개별 페이지 전환 최적화
- schema: 이동 경로 및 사이트 네비게이션 구조화된 데이터 구현
- competitors: 비교 페이지 프레임워크 및 URL 패턴