블로그 메뉴와 카테고리를 다시 나눈 실제 과정

minml의 공개 글이 23편까지 늘었을 때도 상단 메뉴는 Home과 About뿐이었습니다. 홈페이지에는 모든 글이 최신순으로 길게 이어졌습니다. 제목을 알고 들어온 사람은 글을 읽을 수 있었지만, 처음 방문한 사람이 이 사이트에서 주로 다루는 내용과 다음에 읽을 글을 파악하기는 어려운 구조였습니다.

각 글의 앞부분에는 태그가 저장돼 있었습니다. 하지만 방문자가 태그를 선택할 수 있는 화면이나 주제별 목록은 없었습니다. 글 작성자에게만 보이는 분류 정보였고 실제 탐색에는 사용되지 않았습니다. 글이 몇 편 없을 때는 큰 문제가 아니었지만 제작 후기, Ghost 이전, Astro 배포와 AI 도구 사용기가 섞여 쌓이자 한 목록만으로는 글 사이의 관계를 설명하기 어려워졌습니다.

애드센스 승인 실패 후 콘텐츠를 정리했을 때도 글의 중복과 공개할 가치가 있는지를 먼저 검토했습니다. 이번에는 개별 글을 더 쓰기 전에 사이트 전체가 어떤 주제를 다루는지 보여주는 구조를 점검했습니다. 메뉴가 없었다는 사실이 승인 실패의 유일한 원인이라고 판단한 것은 아닙니다. 다만 방문자에게도 설명하기 어려운 사이트 구성을 그대로 두고 글 수만 늘리는 것은 순서가 아니라고 생각했습니다.

그래서 기존 글 주소와 디자인의 기본 분위기는 유지하면서 상단 메뉴, 주제별 목록, 처음 읽을 글과 관련 글을 추가했습니다. 이 글은 카테고리가 검색 순위나 승인을 보장한다는 이야기가 아니라, 한 줄 목록이었던 개인 블로그를 실제 콘텐츠 관계에 맞게 다시 정리한 과정입니다.

변경 전에는 글은 있었지만 시작점이 없었습니다

구조를 바꾸기 전 홈페이지가 제공하던 선택지는 단순했습니다.

위치	변경 전 표시
상단 메뉴	Home, About
홈페이지 본문	공개 글 23편 전체를 최신순으로 표시
글 상세	본문과 작성자, 모든 글 보기 링크
하단 메뉴	개인정보처리방침, 문의
주제별 페이지	없음

이 구조에서는 최신 글이 무엇인지는 알 수 있었습니다. 하지만 Ghost에서 Astro로 옮기는 과정을 처음부터 읽고 싶은 사람과 서버 운영 글만 찾는 사람이 같은 긴 목록을 훑어야 했습니다. 오래된 글일수록 아래로 밀렸고, 본문 안에 제가 직접 넣어둔 링크가 없다면 다음 글로 이어질 경로도 부족했습니다.

Google의 검색 개발자 안내서는 사이트의 모든 페이지가 다른 발견 가능한 페이지의 링크로 도달할 수 있어야 한다고 설명합니다. 링크 문구도 대상 내용을 이해할 수 있게 작성할 것을 권합니다. 검색 노출 이전에 방문자에게도 같은 문제가 있었습니다. 다음 글처럼 의미가 넓은 링크보다 운영·보안 전체 보기와 같이 목적지가 드러나는 문구가 선택하기 쉬웠습니다.

도구 이름보다 방문자가 하려는 일로 나눴습니다

처음에는 Ghost, Astro, Claude Code, Codex처럼 제품 이름으로 분류할 수도 있었습니다. 하지만 한 글에서 여러 도구를 함께 사용했고, 도구가 바뀌면 메뉴도 계속 늘어날 수 있었습니다. 방문자가 제품 이름을 이미 알아야만 글을 찾을 수 있다는 점도 맞지 않았습니다.

대신 글을 읽는 목적을 기준으로 세 가지 주제를 정했습니다.

주제	포함한 글	이 주제에서 답하려는 질문
제작·이전	8편	어떤 플랫폼과 구조로 사이트를 만들고 옮겼는가
운영·보안	9편	배포한 사이트를 어떻게 점검하고 오래 유지하는가
AI 활용	6편	AI 도구를 실제 작업에 어떻게 사용하고 검토했는가

이 숫자는 구조를 개편한 시점의 공개 글 23편을 기준으로 합니다. 이후 새 글이 추가되면서 글 수는 달라지지만 세 주제의 의미는 유지됩니다. 새 글이 어느 곳에도 포함되지 않거나 두 곳에 중복 배정되면 빌드 과정에서 알 수 있도록 검사도 추가했습니다.

제작·이전은 결과물을 만드는 흐름입니다

블로그 플랫폼 비교, AI로 사이트를 만든 후기, Ghost에서 Astro로 글과 이미지를 옮긴 과정, 대표 이미지 관리와 글 발행 과정이 여기에 들어갔습니다. 도구가 Ghost인지 Astro인지보다 사이트를 만들거나 이전하는 일이 글의 중심인지 확인했습니다.

예를 들어 AI로 사이트를 만든 후기에는 Claude Code와 Codex가 등장하지만 핵심 질문은 AI 제품의 기능 비교보다 웹개발 경험이 적은 사람이 사이트를 완성한 과정입니다. 그래서 AI 활용이 아니라 제작·이전에 넣었습니다.

운영·보안은 공개한 뒤의 흐름입니다

백업, 파일 권한, 유지보수, 발행 전 정보 검토, 릴리스 정리와 배포 검증 글을 모았습니다. AI가 SSH 작업을 돕는 글도 도구 사용기보다 안전한 서버 작업 절차가 중심이므로 이 주제로 분류했습니다.

글 제목에 AI가 있다고 무조건 AI 활용에 넣지 않은 이유입니다. 한 글이 어느 도구를 사용했는지보다 독자가 어떤 문제를 해결하려고 읽는지를 우선했습니다.

AI 활용은 도구의 사용 경험과 검토가 중심인 글입니다

Claude Code, Codex와 OpenCode 사용기, AI 글쓰기와 대표 이미지 스타일 관리처럼 AI를 선택하고 사용하는 판단 자체가 중심인 글을 모았습니다. 단순히 AI의 도움을 받아 작성했다는 이유만으로 다른 모든 글을 이곳에 넣지는 않았습니다.

겹치는 글은 대표 질문 하나만 선택했습니다

실제 글은 깔끔하게 한 주제만 다루지 않습니다. Ghost 이전에도 AI를 사용했고, AI 코딩 도구 후기에도 서버 배포가 등장합니다. 한 글을 여러 카테고리에 반복 노출하면 각 목록이 다시 비슷해질 수 있어 대표 주제 하나만 선택했습니다.

분류할 때는 다음 순서로 질문했습니다.

이 글을 읽은 사람이 최종적으로 만들거나 옮기려는 것은 무엇인가?
공개 후 유지·복구·보안 판단이 핵심인가?
특정 AI 도구의 선택과 사용 경험 자체가 핵심인가?
제목과 설명만 읽어도 선택한 주제가 자연스러운가?

두 주제에 모두 해당할 때는 본문의 분량보다 독자가 얻어갈 주된 결과를 기준으로 골랐습니다. 관련된 다른 주제는 본문 내부 링크로 연결하면 됐습니다. 카테고리는 글의 모든 속성을 표현하는 태그가 아니라 사이트에서 길을 찾기 위한 대표 입구로 사용했습니다.

상단 메뉴는 다섯 개 항목으로 정리했습니다

새 상단 메뉴는 다음과 같습니다.

제작·이전
운영·보안
AI 활용
전체 글
소개

주제 세 개만 두지 않고 전체 글도 남겼습니다. 최신순으로 사이트 전체를 훑고 싶은 사람에게는 기존 방식도 유용했기 때문입니다. 소개는 누가 어떤 경험을 기록하는 사이트인지 확인하는 독립 페이지로 유지했습니다.

영문이었던 메뉴 이름은 본문 언어와 맞게 한국어로 바꿨습니다. 메뉴가 가리키는 곳은 일반 링크로 만들었고, 현재 보고 있는 페이지에 해당하는 메뉴는 글자 굵기로 구분했습니다. 모바일에서는 다섯 항목을 여러 줄로 어색하게 접기보다 가로로 이동하며 볼 수 있게 했습니다.

하단에는 주제 안내, 전체 글, 작성자, 개인정보처리방침, 문의와 RSS를 배치했습니다. 상단은 글을 찾는 핵심 동선에 집중하고, 사이트 운영과 신뢰에 필요한 보조 페이지는 하단에서도 찾을 수 있게 나눴습니다.

홈페이지는 글 목록보다 사이트 설명을 먼저 보여줍니다

기존 홈은 사이트 이름과 짧은 설명 뒤에 곧바로 23편 전체 목록이 이어졌습니다. 개편 후에는 처음 방문한 사람이 위에서 아래로 네 가지 질문에 답을 얻도록 순서를 바꿨습니다.

홈의 순서	답하려는 질문
사이트 소개	이곳은 무엇을 직접 경험하고 기록하는가
세 가지 주제	어떤 범위의 글이 있는가
처음 읽을 글	어디에서 시작하면 되는가
최신 글 6편	최근에는 무엇을 확인했는가

처음 읽을 글에는 세 주제를 대표할 수 있는 안내 글을 배치했습니다. 가장 최근 글이나 조회수가 높은 글을 자동으로 고르지 않았습니다. 사이트의 제작 배경, 콘텐츠 이전 과정과 운영 점검 기준을 이해하는 데 도움이 되는 글을 직접 선택했습니다.

최신 글은 6편만 홈에 보여주고 나머지는 전체 글 페이지에서 볼 수 있게 했습니다. 홈의 역할을 모든 글을 담는 저장소보다 사이트의 방향과 입구를 설명하는 페이지로 바꾼 것입니다.

주제 페이지와 전체 글 페이지를 따로 만들었습니다

각 주제 페이지에는 제목, 한 문단 설명, 포함된 글 수와 최신순 목록이 있습니다. 운영·보안이라는 이름만 보여주는 대신 배포, 백업, 권한, 링크 검사와 보안 검토를 다룬다는 설명을 함께 적었습니다. 주제의 범위가 이름만으로 모호해지는 것을 줄이기 위해서입니다.

전체 글 페이지는 주제와 관계없이 공개 글을 최신순으로 보여줍니다. 기존 홈 목록의 장점을 별도 페이지로 옮긴 셈입니다. 글 카드 모양은 홈과 주제 페이지에서 서로 달라지지 않도록 하나의 공통 컴포넌트로 만들었습니다.

분류 정보는 별도 데이터베이스에 저장하지 않았습니다. 각 주제에 속한 글의 공개 슬러그를 사이트 설정에 두고 Astro가 빌드할 때 목록 페이지를 생성합니다. 글이 늘어날 때 새 슬러그를 주제에 추가하지 않으면 홈 빌드가 실패하므로, 공개했지만 어느 메뉴에서도 찾을 수 없는 상태를 놓치지 않게 했습니다.

글 하단에는 같은 주제의 글 세 편을 연결했습니다

메뉴만 추가하면 방문자는 현재 글을 읽은 뒤 다시 위로 올라가야 합니다. 그래서 각 글 하단에 같은 주제의 최근 글 세 편과 주제 전체 보기 링크를 추가했습니다.

예를 들어 배포 글 아래에는 릴리스 정리, 링크 검증과 발행 전 보안 검토처럼 운영·보안에 속한 글이 이어집니다. 제목뿐 아니라 한 문단 설명도 함께 표시해 단순한 링크 모음보다 다음 글의 내용을 판단할 수 있게 했습니다.

관련 글을 조회수나 자동 추천 모델로 고르지는 않습니다. 같은 주제라는 명확한 기준 안에서 현재 글을 제외하고 최근 글 세 편을 보여줍니다. 작은 개인 블로그에서는 복잡한 추천 기능보다 결과를 예상할 수 있고 관리하기 쉬운 방식이 적합했습니다.

기존 글 주소는 하나도 바꾸지 않았습니다

이번 작업의 목표는 탐색 구조를 추가하는 것이지 기존 콘텐츠를 다시 이전하는 것이 아니었습니다. 따라서 23편의 글 주소, Markdown 파일과 대표 이미지는 그대로 두었습니다. 새로 생긴 주소는 주제 안내, 세 개의 주제 목록과 전체 글 페이지뿐입니다.

유지한 것	새로 추가하거나 바꾼 것
기존 글 슬러그와 공개 URL	상단 주제 메뉴
본문 Markdown과 대표 이미지	주제 안내와 세 개의 목록 페이지
기존 리디렉션	전체 글 페이지
미니멀한 색상과 여백	홈의 소개·주제·입문 글·최신 글 순서
소개·문의·개인정보 페이지	글 하단의 같은 주제 글

주소를 카테고리 아래로 옮겨 /topics/operations/글주소/처럼 바꾸는 방법도 있지만 선택하지 않았습니다. 이미 공개된 주소와 내부 링크를 다시 수정해야 할 이유가 없었고, 주제는 나중에 조정될 수도 있기 때문입니다. 글 주소와 탐색 분류를 분리해두면 카테고리를 고쳐도 본문 URL은 유지할 수 있습니다.

빌드 성공 외에 분류와 링크를 따로 검사했습니다

구조 개편 당시 Astro 빌드는 34개 페이지를 생성했습니다. 별도 검증 결과는 다음과 같았습니다.

확인 항목	결과
공개 글	23편
공개에서 제외한 초안	10편
고정 페이지	3개
생성된 HTML 파일	40개
내부 경로 대상	38개
로컬 이미지 대상	24개
통합한 과거 주소	6개

여기에 모든 공개 글이 정확히 한 주제에 들어갔는지 확인했습니다. 주제 페이지, 전체 글과 홈의 새 링크가 실제 생성 파일로 이어지는지도 검사했습니다. 빌드가 성공했다는 사실만으로 본문의 깨진 링크까지 보장되지 않는다는 점은 내부 링크를 의도적으로 깨뜨린 검사에서 이미 확인했기 때문입니다.

운영 서버에 공개한 뒤에는 홈페이지와 사이트맵, 주제 안내, 세 개의 주제 페이지와 전체 글 페이지가 200인지 확인했습니다. 존재하지 않는 시험 주소는 404, 통합한 과거 글은 새 주소로 301 이동하는지도 함께 봤습니다. 같은 서버의 다른 사이트는 수정하지 않고 기존처럼 열리는지만 확인했습니다.

이 수치는 카테고리를 만들면 좋은 사이트가 된다는 증거가 아닙니다. 의도한 글이 빠지지 않았고 새 동선이 실제 파일로 존재한다는 것을 확인한 작업 기록입니다.

화면이 깔끔한 것과 구조가 명확한 것은 달랐습니다

기존 minml도 흰 배경과 큰 여백을 사용해 화면 자체는 단정했습니다. 하지만 디자인이 깔끔하다는 사실이 방문자가 사이트의 범위를 이해한다는 뜻은 아니었습니다. 글 목록이 한 줄로 정돈돼 있어도 무엇부터 읽어야 하는지 설명하지 못하면 구조는 평평한 상태였습니다.

이번에는 새로운 색상이나 화려한 효과를 추가하지 않았습니다. 기존 검정·흰색·분홍 포인트를 유지하고 정보의 순서와 링크를 바꿨습니다. 큰 디자인 개편보다 다음 세 가지가 더 중요했습니다.

상단에서 사이트의 세 주제를 바로 확인할 수 있는가
처음 방문한 사람이 대표 글을 선택할 수 있는가
한 글을 읽은 뒤 같은 흐름의 다음 글로 이동할 수 있는가

실제 브라우저에서는 홈과 주제 페이지, 글 상세를 각각 확인했습니다. 데스크톱에서는 긴 제목과 세 칸 카드가 깨지지 않는지 봤고, 모바일에서는 메뉴를 이동해 볼 수 있으며 카드가 한 열로 바뀌는지 확인했습니다.

아직 검색이나 승인 효과를 결과로 말할 단계는 아닙니다

이번 개편은 방문자와 검색 시스템이 글 사이의 연결을 발견할 수 있는 기본 구조를 만든 작업입니다. Google 공식 문서도 크롤링 가능한 일반 링크와 설명적인 링크 문구, 다른 페이지에서 도달 가능한 구조를 권장합니다. 하지만 메뉴와 카테고리를 추가했다고 검색 순위가 오르거나 애드센스 승인이 보장되는 것은 아닙니다.

글 내용이 얕거나 반복된다면 분류만 잘해도 해결되지 않습니다. 필수 페이지, 실제 경험, 출처, 모바일 사용성, 정상적인 오류 응답과 사이트맵도 별도의 문제입니다. 그래서 이번 작업과 함께 처음 읽을 핵심 글을 보강하고, 새 글도 기존 글을 바꿔 말하는 대신 실제 작업과 검증 결과를 중심으로 작성했습니다.

효과는 시간이 지난 뒤 방문자가 어떤 페이지를 읽는지와 검색 색인 상태를 확인해야 판단할 수 있습니다. 지금 확실히 말할 수 있는 변화는 처음 방문한 사람이 사이트의 주제와 대표 글을 이전보다 적은 선택으로 파악할 수 있고, 공개 글이 메뉴에서 누락되면 빌드 과정에서 알 수 있게 됐다는 점입니다.

다시 구조를 만든다면 이 순서로 진행할 것입니다

다른 개인 블로그에도 세 개의 카테고리가 정답이라는 뜻은 아닙니다. 글이 적거나 주제가 하나라면 전체 목록만으로 충분할 수 있습니다. 반대로 주제가 많더라도 각 목록에 글이 한두 편뿐이면 빈 메뉴만 늘어날 수 있습니다.

제가 다시 정리한다면 다음 순서를 사용합니다.

공개 글의 제목과 핵심 질문을 한곳에 모읍니다.
도구 이름보다 방문자가 해결하려는 일로 묶습니다.
겹치는 글에는 대표 주제 하나만 선택합니다.
각 주제를 한 문장으로 설명할 수 있는지 확인합니다.
전체 글을 볼 수 있는 경로도 남깁니다.
홈에서 사이트 소개, 주제와 시작할 글을 먼저 보여줍니다.
글 하단에 같은 주제의 다음 글을 연결합니다.
기존 글 주소는 필요한 이유가 없다면 유지합니다.
공개 글의 분류 누락과 내부 링크를 자동 검사합니다.
데스크톱과 모바일 화면을 직접 확인합니다.

minml에서는 글을 더 추가하기 전에 기존 23편의 관계부터 보여주는 편이 필요했습니다. 메뉴를 늘리는 작업처럼 보였지만 실제로는 이 사이트가 무엇을 기록하는지 다시 정의하는 과정이었습니다. 결과적으로 홈은 모든 글을 길게 늘어놓는 페이지에서 세 주제와 시작점을 안내하는 페이지로 바뀌었습니다.

앞으로 글 수가 늘어나도 주제를 계속 추가할 계획은 없습니다. 현재 세 묶음으로 설명하기 어려운 글이 생기면 먼저 사이트의 범위를 벗어난 글인지, 기존 주제 설명을 다듬으면 되는지 판단할 것입니다. 카테고리의 목적은 모든 차이를 이름표로 만드는 것이 아니라 방문자가 다음 글을 찾을 수 있는 적은 수의 명확한 길을 제공하는 것이라고 느꼈습니다.

글 23편이 한 목록에만 있었습니다, 블로그 메뉴와 카테고리를 다시 나눈 과정