site-architecture

site-architecture 스킬 개요

site-architecture 스킬이 하는 일

site-architecture 스킬은 웹사이트의 페이지 계층, 내비게이션, URL 구조, 내부 링크 체계를 계획하거나 재정비할 때 유용합니다. 이 스킬은 기술적인 XML sitemap 생성이 아니라 정보구조(IA) 설계를 위한 도구입니다. 핵심 질문이 “이 사이트에는 어떤 페이지가 있어야 하고, 서로 어떻게 연결되어야 하며, 사용자는 어떤 흐름으로 이동해야 하는가?”라면, 이 스킬이 잘 맞습니다.

site-architecture 스킬이 잘 맞는 사용자

이 site-architecture 스킬은 특히 다음과 같은 사용자에게 적합합니다:

• 새 사이트를 기획하거나 대규모 리뉴얼을 준비하는 마케터
• SaaS 마케팅 사이트 구조를 정의하려는 창업자
• 내비게이션과 IA를 다루는 UI/UX 팀
• 허브, 섹션, 페이지 관계를 설계해야 하는 SEO 관점의 콘텐츠 팀
• 빠르게 1차 sitemap, URL 맵, nav spec이 필요한 에이전시

특히 사이트가 오랜 기간 자연스럽게 커지면서 탐색이 어렵고, 구조가 들쭉날쭉하며, 깊이가 과도해진 경우에 효과적입니다.

site-architecture 스킬의 대표 활용 작업

다음이 필요할 때 site-architecture를 사용하세요:

• 대략적인 페이지 목록을 논리적인 사이트 맵으로 정리할 때
• 얕은 구조와 깊은 구조 중 어느 쪽이 적합한지 판단할 때
• header, footer, 섹션별 내비게이션을 정의할 때
• /features, /compare, /integrations 같은 섹션의 URL 패턴을 설계할 때
• 허브 페이지와 상세 페이지 간 내부 링크를 개선할 때
• 검토용 시각적 sitemap을 ASCII 또는 Mermaid로 만들 때

일반 프롬프트와 다른 점

일반 프롬프트도 페이지 목록은 뽑아줄 수 있습니다. 하지만 site-architecture 스킬은 결과물이 더 완성도 있게 나오도록 설계되어 있다는 점이 다릅니다:

• 먼저 비즈니스와 오디언스 맥락을 파악
• 명시적인 계층 구조 설계
• 내비게이션 권장안 제시
• URL 구조 패턴 정리
• 내부 링크 가이드 포함
• 시각적 sitemap 출력 지원
• 자주 쓰이는 사이트 유형용 재사용 템플릿 제공

저장소에는 Mermaid 다이어그램, 내비게이션 패턴, 사이트 유형 템플릿에 대한 실무형 참고 자료도 포함되어 있어, 처음부터 빈 화면에서 시작할 때보다 결과가 훨씬 일관되게 나옵니다.

중요한 범위 한계

이 스킬이 주력으로 다루지 않는 것은 다음과 같습니다:

• XML sitemap 파일
• 전체 SEO 감사
• schema markup
• 최종 wireframe 또는 완성형 UI 목업

site-architecture for UI/UX Design 관점에서는 특히 구조 설계 단계에서 가장 유용합니다. 즉, 상세 인터페이스 디자인 이전에 페이지 묶음, wayfinding, nav 영역, 콘텐츠 발견 가능성을 정리하는 데 강합니다.

site-architecture 스킬 사용 방법

설치 방식과 호출 패턴

다음 명령으로 저장소에서 스킬을 설치할 수 있습니다:

npx skills add https://github.com/coreyhaines31/marketingskills --skill site-architecture

실제 사용에서는 사이트 맵, 내비게이션, 페이지 계층, URL 설계에 대한 도움을 요청할 때 site-architecture가 트리거됩니다. 이 스킬은 모델이 스킬 파일을 읽고 해당 워크플로를 따를 수 있는 Skills 호환 에이전트 환경에서 가장 잘 작동합니다.

site-architecture 사용 전 먼저 읽을 파일

스킬을 빠르게 판단하고 싶다면 다음 순서로 보세요:

1. skills/site-architecture/SKILL.md
2. skills/site-architecture/references/site-type-templates.md
3. skills/site-architecture/references/navigation-patterns.md
4. skills/site-architecture/references/mermaid-templates.md
5. skills/site-architecture/evals/evals.json

이 순서로 읽으면 워크플로, 자주 나오는 결과물, 실제 내비게이션 선택지, 다이어그램 형식, 그리고 평가 기준상 “좋은 결과”가 무엇인지까지 한 번에 파악할 수 있습니다.

site-architecture 스킬이 가장 필요로 하는 입력값

다음 정보를 주면 site-architecture 스킬의 결과 품질이 크게 좋아집니다:

• 회사가 하는 일
• 주요 대상 오디언스
• 사이트의 핵심 목표(보통 2~3개 이내)
• 신규 사이트인지, 리뉴얼/재구성인지
• 기존 페이지 인벤토리 유무
• 중복, 과도한 하위 단계, 낮은 발견성 같은 문제 지점
• SaaS, ecommerce, services, marketplace, content-heavy site 같은 사이트 유형

이 정보가 없어도 구조 초안은 만들 수 있지만, 결과가 지나치게 일반적이거나 잘못된 내비게이션 패턴을 선택할 가능성이 높습니다.

먼저 product-marketing context를 확인하세요

이 저장소에서 특히 유용한 동작 하나가 있습니다. 스킬이 질문을 시작하기 전에 .agents/product-marketing-context.md 또는 예전 경로인 .claude/product-marketing-context.md를 먼저 확인하라고 명시하고 있다는 점입니다. 많은 구조 설계 결정은 포지셔닝, 오디언스, 오퍼 구조에 좌우되기 때문에 이 부분이 중요합니다.

이미 product marketing context를 문서화해두었다면, 모델이 그 파일을 보도록 안내하세요. 그러면 같은 질문을 반복하는 왕복이 줄고, 페이지 그룹핑 결정도 더 정확해집니다.

막연한 목표를 강한 site-architecture 프롬프트로 바꾸는 법

약한 프롬프트:

Help me make a sitemap.

더 강한 프롬프트:

Use the site-architecture skill to plan a SaaS marketing site for an analytics product aimed at ecommerce teams. Our goals are demo requests, SEO traffic, and partner integrations. We need a homepage, pricing, feature pages, docs, blog, integrations, and competitor comparison pages. Keep top nav to 5-6 primary items. Propose page hierarchy, URL structure, header/footer nav, and internal linking model.

이 프롬프트가 잘 작동하는 이유:

• 오디언스와 비즈니스 유형이 명확함
• 전환 목표와 콘텐츠 목표를 함께 제시함
• 필요한 콘텐츠 유형이 구체적임
• 내비게이션 제약이 포함됨
• 이 스킬이 잘 만드는 산출물을 정확히 요청함

좋은 site-architecture 사용 방식

다음 순서로 결과물을 요청하는 것이 좋습니다:

1. 가정과 누락된 입력값
2. 제안하는 계층 구조
3. URL 맵
4. 내비게이션 spec
5. 내부 링크 권장안
6. ASCII 트리 또는 Mermaid 다이어그램
7. 트레이드오프 또는 남은 쟁점

이 순서는 이 스킬의 실무적 강점을 그대로 활용하는 방식입니다. 라벨이나 디자인 디테일을 논의하기 전에 먼저 구조 자체를 검토할 수 있게 해줍니다.

빈 화면에서 시작하지 말고 reference 템플릿을 활용하세요

도입 장벽을 가장 크게 낮춰주는 부분은 reference 세트입니다:

• site-type-templates.md는 바로 가져다 쓸 수 있는 계층 패턴을 제공합니다
• navigation-patterns.md는 단순 header, mega menu, 기타 nav 모델 중 선택을 도와줍니다
• mermaid-templates.md는 시각적 sitemap 제작 속도를 높여줍니다

많은 팀에게 가장 효율적인 흐름은 이렇습니다: 가장 가까운 사이트 템플릿을 고르고, 섹션을 조정한 뒤, nav와 URL을 다듬습니다. 자유형 프롬프트로 처음부터 만드는 것보다 더 빠르고, 대체로 결과도 좋습니다.

신규 사이트를 위한 권장 workflow

새로 구축하는 경우에는 다음 순서가 좋습니다:

1. 비즈니스 목표와 오디언스를 정의
2. 가장 가까운 사이트 유형 템플릿 선택
3. 주요 섹션 조정
4. URL 규칙 설정
5. header 내비게이션은 우선순위 높은 항목만 남기기
6. 보조 페이지는 footer 또는 섹션 내 nav로 배치
7. 필요한 곳에 hub-and-spoke 내부 링크 구조 추가
8. 이해관계자 검토용 ASCII 트리 또는 Mermaid 다이어그램 출력

이 방식은 특히 SaaS에서 잘 맞습니다. /features, /customers, /resources, /integrations, /compare 같은 섹션은 분리가 명확해야 하는 경우가 많기 때문입니다.

리뉴얼/재구성을 위한 권장 workflow

이미 복잡해진 사이트라면 모델에 다음 정보를 주세요:

• 현재 nav
• 페이지 수 또는 페이지 인벤토리
• 중복된 섹션
• 트래픽이 낮거나 소유 주체가 불분명한 페이지
• “docs를 찾기 어렵다”, “드롭다운이 너무 많다” 같은 사용자 불만

그다음 다음 작업을 요청하세요:

• 섹션 통합
• 중복 진입점 제거
• 불필요한 깊이 축소
• 핵심 nav와 utility/footer 항목 분리
• 가능하면 가치 높은 기존 URL 유지

이 지점이 바로 site-architecture 스킬이 일반 브레인스토밍 프롬프트보다 유리한 이유입니다. 단순한 페이지 나열이 아니라, 재구성 작업으로 프레이밍해주기 때문입니다.

UI/UX Design 팀을 위한 site-architecture 활용

UI/UX Design 팀이라면 다음을 명확히 해야 할 때 wireframe 전에 이 스킬을 쓰는 것이 좋습니다:

• 무엇을 global nav에 넣어야 하는지
• 어디에 section landing page가 필요한지
• breadcrumbs가 계층 구조를 어떻게 반영해야 하는지
• 어떤 페이지는 직접 접근이 필요하고 어떤 페이지는 간접 접근이면 되는지
• mega menu가 정당화되는 시점이 언제인지

이 스킬이 interaction design을 대신하진 않지만, 컴포넌트 설계에 들어가기 전에 더 설득력 있는 IA 기준선을 만들어줍니다.

요청하기 좋은 실무형 출력 포맷

이 스킬은 다음 형식 중 하나 이상을 요청할 때 가장 강합니다:

• 빠른 검토용 ASCII 트리
• 문서화용 Mermaid sitemap
• 우선순위가 포함된 URL 맵 테이블
• header/footer nav spec
• 섹션별 내부 링크 모델

이 형식들은 모두 저장소 근거로 지원되는 결과물이므로, 이미 스킬이 잘 처리하는 방식에 맞춰 요청하는 셈입니다.

site-architecture 스킬 FAQ

초보자에게도 site-architecture가 괜찮을까요?

네. 사이트의 목표와 주요 콘텐츠 유형만 어느 정도 알고 있다면 괜찮습니다. IA를 완전히 처음부터 만드는 것보다 더 빠르게 구조를 잡아줍니다. 초보자가 막히는 이유는 대체로 스킬이 어려워서가 아니라, 맥락 정보를 너무 적게 주기 때문입니다.

일반 프롬프트 대신 언제 site-architecture를 써야 하나요?

결과물이 실제 작업에 바로 연결되어야 할 때 site-architecture 스킬을 쓰는 것이 좋습니다. 예를 들면 계층 구조, 내비게이션, URL 규칙, 링크 전략이 필요한 경우입니다. 일반 프롬프트는 페이지 아이디어를 브레인스토밍하는 데는 충분할 수 있지만, 검토 가능한 아키텍처 산출물이 필요하다면 이 스킬이 더 적합합니다.

site-architecture가 XML sitemaps도 만들어주나요?

아니요. 이 스킬은 정보구조와 내비게이션 기획을 위한 것입니다. XML sitemap 생성이나 기술적인 크롤링 진단용 도구는 아닙니다.

신규 사이트가 아니라 기존 사이트에도 site-architecture가 유용한가요?

네. 특히 페이지 수가 너무 많고, 그룹핑이 일관되지 않으며, 내비게이션이 혼란스러운 기존 사이트의 재구성에 잘 맞습니다. 원하는 미래 상태만 주지 말고, 현재 상태와 실제 불편 지점도 함께 제공해야 합니다.

수작업으로 IA를 하는 것과 비교하면 어떤가요?

수작업 IA는 여전히 중요합니다. 다만 이 스킬은 1차 구조 설계를 빠르게 해주고, 재사용 가능한 템플릿도 제공합니다. 초안 옵션을 만들고, 트레이드오프를 드러내고, 팀 검토용 산출물을 만드는 데 특히 유용합니다. 정치적 이슈, 소유권, 구현 제약 같은 부분은 여전히 사람의 판단이 필요합니다.

site-architecture for UI/UX Design 용도로도 잘 맞나요?

네. 상위 단계의 기획 도구로는 잘 맞습니다. UI/UX Design 팀이 상세 레이아웃에 들어가기 전에 페이지 간 관계, 내비게이션 깊이, wayfinding 논리를 정의하는 데 도움을 줍니다. 반면 컴포넌트 단위의 디자인 의사결정에는 적합하지 않습니다.

언제 site-architecture가 맞지 않는 스킬인가요?

실제 필요가 다음과 같다면 다른 도구를 쓰는 편이 낫습니다:

• technical SEO auditing
• schema planning
• content writing
• 고해상도 페이지 레이아웃 wireframing
• 마케팅 사이트 패턴을 훨씬 벗어나는 앱 정보구조 설계

기본적인 비즈니스 맥락조차 제공할 수 없는 경우에도 잘 맞지 않습니다.

site-architecture 스킬 개선 방법

비즈니스 제약을 더 날카롭게 주기

site-architecture 결과를 가장 빠르게 개선하는 방법은 제약 조건을 명확히 적는 것입니다:

• 주요 전환 액션
• 핵심 오디언스 세그먼트
• header nav 최대 개수
• 반드시 포함해야 할 섹션
• 메인 nav에서 제외해야 할 섹션
• SEO 랜딩 페이지 우선 여부

제약이 없으면 모델은 페이지를 과하게 포함하고, 내비게이션 우선순위는 약하게 잡는 경향이 있습니다.

리뉴얼에서는 페이지 인벤토리를 제공하기

기존 사이트라면 대략적인 페이지 인벤토리나 현재 nav를 붙여 넣으세요. 다소 지저분한 목록이어도 충분합니다. 그래야 site-architecture 스킬이 통합 가능한 부분, 중복 구조, 고립된 섹션을 더 잘 찾아낼 수 있습니다.

답 하나만 받지 말고 트레이드오프를 요구하기

효과적인 개선 패턴은 다음과 같습니다:

Give me a recommended architecture plus one simpler option and one SEO-expansion option.

이렇게 하면 다음과 같은 실제 선택지가 드러납니다:

• 단순한 nav vs 확장 가능한 nav
• 상위 섹션 수를 줄이는 방식 vs 전용 랜딩 페이지 허브를 두는 방식
• 더 평평한 계층 vs 더 명확한 분류

이런 비교가 있어야 이해관계자 정렬에도 훨씬 유용해집니다.

구체적인 산출물로 output을 더 명확하게 만들기

첫 번째 결과가 모호하게 느껴진다면 다음을 요청하세요:

• 전체 ASCII 트리
• 정확한 URL 패턴
• 항목 수가 포함된 nav 라벨
• breadcrumbs 예시
• 섹션 단위 내부 링크

출력 형식을 구체화하면 두루뭉술한 조언이 줄고, site-architecture 가이드가 실제 구현에 더 가까워집니다.

자주 발생하는 실패 패턴 주의하기

첫 초안에서 다음 문제를 확인하세요:

• 상위 nav 항목이 너무 많음
• 카테고리 이름이 서로 겹침
• 콘텐츠 허브와 전환 페이지가 우선순위 없이 섞여 있음
• 사용자 이점이 적은데도 깊게 중첩됨
• blog/resources/docs가 일관성 없이 묶임
• 링크 계획 없이 SEO 랜딩 페이지가 추가됨

이런 문제는 프롬프트가 너무 넓거나 모호할 때 site-architecture 스킬이 흔히 만들어내는 IA 오류입니다.

내부 링크 권장안을 더 실무적으로 개선하기

“내부 링크를 추가하라” 정도로는 충분하지 않습니다. 모델에게 다음을 구체적으로 지정하게 하세요:

• 어떤 허브 페이지가 어떤 상세 페이지로 링크해야 하는지
• 어떤 상세 페이지가 허브로 다시 링크해야 하는지
• features에서 integrations로, comparisons에서 pricing으로처럼 어떤 교차 링크가 적절한지
• 어떤 페이지는 과도한 교차 링크에서 제외해야 하는지

그래야 site-architecture 활용이 개념 수준에 머무르지 않고 실제 실행안으로 바뀝니다.

repo reference를 활용해 약한 초안을 보강하기

출력이 지나치게 일반적이라면 모델에게 다음 reference를 적용하라고 지시하세요:

• 내비게이션 결정에는 references/navigation-patterns.md
• 섹션 커버리지 점검에는 references/site-type-templates.md
• 더 명확한 다이어그램에는 references/mermaid-templates.md

이건 스킬 자체를 수정하지 않고도 site-architecture 결과를 개선할 수 있는 가장 쉬운 방법 중 하나입니다.

첫 번째 architecture 초안 이후 반드시 한 번 더 다듬기

권장되는 2차 프롬프트 예시는 다음과 같습니다:

Revise this site architecture to reduce header nav to 5 items, move low-priority pages to footer, preserve our existing /blog structure, and create a clearer hub model for integrations and comparison pages.

이처럼 수정 방향이 명확한 후속 프롬프트를 줘야, 비로소 실무에 쓸 만한 수준으로 올라가는 경우가 많습니다.

실제 사용자 여정으로 구조 검증하기

결과를 채택하기 전에 핵심 여정이 쉬운지 꼭 확인하세요:

• 첫 방문자가 제품을 이해하는 흐름
• 비교 검토 중인 사용자가 의사결정 페이지로 가는 흐름
• SEO 유입 방문자가 아티클에서 제품 의도로 넘어가는 흐름
• 기존 고객이 docs나 support로 가는 흐름
• 파트너 후보가 integrations 세부 정보에 도달하는 흐름

sitemap이 깔끔해 보여도 이런 여정이 어색하다면, site-architecture는 한 번 더 다듬어야 합니다.

오디언스를 좁히면 site-architecture 품질이 좋아집니다

오디언스 범위가 너무 넓으면 구조도 흐려집니다. 첫 결과가 모두를 만족시키려 한다면 우선순위를 나누세요:

• buyer vs user
• SMB vs enterprise
• prospect vs customer
• educational content vs conversion content

오디언스 우선순위가 명확해지면 내비게이션과 페이지 그룹핑을 훨씬 더 설득력 있게 설계할 수 있기 때문에, site-architecture 스킬의 품질도 눈에 띄게 좋아집니다.