홈페이지 첫 화면은 잘 나오는데, 블로그에서 ‘앱’을 누르면 아무 일도 일어나지 않았습니다. 원본 파일을 수정했는데 공개 사이트에는 이전 화면이 남아 있기도 했습니다.
나인투식스랩을 워드프레스로 구성하며 어려웠던 부분은 설치 버튼을 누르는 일보다 홈페이지와 블로그를 하나로 연결하고, 수정한 결과를 방문자 화면에서 확인하는 일이었습니다. 같은 문제를 겪는 분을 위해 실제 구성과 해결 순서를 정리합니다.
2026년 9월 13일 운영 구성 기준입니다. 설명 그림은 직접 만든 구성도이며, 관리자 화면 캡처가 아닙니다.
먼저 홈페이지와 블로그의 역할을 나눴습니다
이 사이트에는 앱 소개와 사용법 글이 함께 있습니다. 앱을 처음 보는 사람은 어떤 서비스인지 빠르게 알고 싶고, 검색으로 들어온 사람은 당장 궁금한 문제의 답을 찾고 싶습니다. 그래서 첫 화면에는 앱 소개를, 블로그에는 사용법과 제작 기록을 두었습니다.
- 홈페이지: 서비스 중인 앱, 개발 중인 게임, 만드는 방식을 안내합니다.
- 앱 상세: 실제 화면과 이용 방법, 알아둘 점을 보여줍니다.
- 블로그: 하나의 질문을 해결하는 사용법과 제작 경험을 쌓습니다.
- 소개·개인정보처리방침: 운영 주체와 서비스의 정보 처리 방식을 확인하는 곳입니다.
처음 만드는 분이라면 메뉴 이름보다 먼저 “이 페이지에 들어온 사람이 무엇을 하고 나가야 하는가”를 한 줄씩 적어 보세요. 역할이 겹치는 페이지를 줄이고, 내용이 없는 메뉴를 먼저 노출하는 일도 피하기 쉽습니다.
‘페이지’와 ‘글’을 구분해야 관리가 편합니다
워드프레스의 페이지는 소개처럼 시간순으로 쌓을 필요가 적은 내용을 담고, 글은 블로그에 계속 발행하는 내용을 담습니다. 나인투식스랩도 소개는 페이지로, 사용법과 개발 기록은 글로 관리합니다. 이 구분은 워드프레스 공식 페이지 안내에서도 확인할 수 있습니다.
일반적인 구성에서는 홈으로 쓸 페이지와 글 목록용 페이지를 각각 만든 뒤, 설정 → 읽기 → 홈페이지 표시에서 정적인 페이지를 선택하고 홈페이지와 글 페이지를 따로 지정합니다. 테마와 관리자 언어에 따라 표현은 달라질 수 있습니다. 세부 항목은 공식 읽기 설정 문서를 기준으로 확인하세요.
여기서 헷갈리기 쉬운 점이 있습니다. 글 목록으로 지정한 페이지가 편집기에서 비어 있다고 해서 공개 블로그도 빈 페이지인 것은 아닙니다. 글 목록은 발행한 글을 모아 보여주는 역할입니다. 편집기뿐 아니라 실제 블로그 주소를 열어 확인해야 합니다.
기존 홈페이지 디자인은 살리고, 글은 편집기에서 씁니다
나인투식스랩에는 이미 HTML·CSS·자바스크립트로 만든 홈페이지가 있었습니다. 이 화면을 유지하면서 블로그를 운영하기 위해, 카페24의 워드프레스에 자체 플러그인으로 기존 정적 화면을 제공하는 방식을 사용했습니다.
홈페이지와 앱 소개는 원본 파일을 수정하고 플러그인으로 배포합니다. 블로그와 소개 글은 워드프레스 편집기에서 고칩니다. 일반 콘텐츠 화면에는 GeneratePress 테마를 사용하고, 메뉴와 하단 안내를 홈페이지와 연결했습니다.
이 방식은 기존 디자인을 유지할 수 있다는 장점이 있습니다. 대신 고칠 곳이 두 군데라 배포 경로를 알아야 합니다. 처음 시작하는 모든 사이트에 자체 플러그인이 필요한 것은 아닙니다. 기존 HTML을 유지할 이유가 없다면 테마와 블록 편집기로 홈과 글을 함께 관리하는 구성이 더 단순할 수 있습니다.
수정했는데 그대로라면 ‘배포’와 ‘캐시’를 나눠 확인합니다
저희 구성에서는 깃 저장소에 원본을 올리는 것만으로 워드프레스 홈페이지가 바뀌지 않습니다. 사이트가 읽는 것은 플러그인 안에 들어 있는 사본이기 때문입니다. 원본을 고쳤어도 새 사본이 서버에 전달되지 않았다면 이전 화면이 나옵니다.
또 하나는 캐시입니다. 이전에 만들어 둔 화면을 빠르게 보여주기 위해 보관한 사본이라고 생각하면 됩니다. 이 사이트는 WP Super Cache를 사용하므로 플러그인을 교체한 뒤 캐시를 비우고 공개 주소에서 결과를 확인합니다.
- 고친 곳 확인: 블로그 글인지, 플러그인이 제공하는 홈페이지인지 구분합니다.
- 저장·배포 확인: 글은 업데이트됐는지, 홈페이지는 새 플러그인이 설치됐는지 봅니다.
- 캐시 확인: 사용 중인 캐시 도구에서 이전 사본을 비웁니다.
- 방문자 화면 확인: 로그인하지 않은 브라우저에서 최종 주소를 다시 엽니다.
캐시 삭제는 배포를 대신하지 않습니다. 새 파일이 서버에 없는데 캐시만 계속 지워도 새 디자인은 나타나지 않습니다. 반대로 일반 글 하나를 수정할 때마다 저희 홈페이지용 플러그인을 다시 만들 필요는 없습니다.
홈페이지에서 되던 메뉴가 블로그에서 끊긴 이유
이번에 실제로 발견한 오류는 페이지 안의 위치로 이동하는 링크였습니다. 홈페이지의 앱 영역에는 apps라는 이름을 붙여 두었고, 메뉴는 #apps로 연결돼 있었습니다. 홈페이지 안에서는 정상입니다.
그 메뉴를 블로그에도 그대로 넣자 문제가 생겼습니다. 글에서 #apps를 누르면 현재 글 안에서 apps라는 위치를 찾습니다. 하지만 글에는 그런 구역이 없습니다. 주소가 틀려 404가 뜨는 것도 아니라 눈으로 지나치기 쉬운 오류였습니다.
해결은 목적지를 분명하게 지정하는 것이었습니다.
- 앱 메뉴:
#apps대신https://ninetosixlab.com/#apps로 연결했습니다. - 만드는 방식: 홈페이지의 해당 구역으로 연결했습니다.
- 로고: 홈페이지 첫 주소로 돌아가게 했습니다.
- 맨 위로: 각 글에 실제로 존재하는 본문 시작점으로 연결했습니다.
메뉴를 검사할 때는 첫 화면에서만 누르지 마세요. 홈페이지 → 글 하나 → 카테고리 목록처럼 서로 다른 화면에서 같은 메뉴를 눌러 보면 공통 메뉴의 연결 실수를 찾기 쉽습니다.
글은 짧게 나누고, 그림에는 설명할 역할을 줬습니다
처음에는 설명이 길게 이어져 읽기 어렵다는 피드백을 받았습니다. 이후에는 한 문단에 하나의 이야기만 담고, 소제목으로 질문을 나눴습니다. 비용 계산에는 계산 그림을, 운영 과정에는 순서도를 넣었습니다.
이 글에서도 구성도는 “어디에서 고치는가”를, 배포 그림은 “어느 단계가 빠졌는가”를 설명합니다. 장식용 그림을 늘리기보다 독자가 멈출 만한 지점에 필요한 설명을 붙이는 방식입니다.
워드프레스에서는 문단·제목·이미지를 블록으로 나눠 편집합니다. 자세한 조작은 공식 블록 편집기 안내를 참고하세요. 저희는 게시 전에 대표 이미지가 본문에 중복되지 않는지, 모바일에서 글씨와 그림이 잘리는지, 이미지에 대체 텍스트가 있는지도 확인합니다.
카테고리는 ‘사용법’과 ‘만드는 이야기’처럼 큰 분류에, 태그는 워드프레스·캐시처럼 구체적인 주제에 사용합니다. 태그를 많이 붙이는 것 자체보다, 눌렀을 때 관련 글을 실제로 찾을 수 있는지가 중요합니다.
완성 여부는 관리자 화면 밖에서 확인합니다
최근 점검에서는 공개 글과 페이지에서 연결되는 주소 57개, 이미지·CSS·자바스크립트 주소 86개를 확인했습니다. 공통 메뉴를 수정한 뒤 점검 범위에서 내부 404와 잘못된 페이지 내 연결은 발견되지 않았습니다. 이 수치는 2026년 9월 13일 점검 결과이며, 이후 추가되는 글까지 자동으로 보증하지는 않습니다.
외부 문서 중에는 빈 응답을 보내 정상 여부를 확정하지 못한 링크도 있었습니다. 모든 외부 사이트를 저희가 고칠 수는 없으므로, 확인한 것과 확인하지 못한 것을 구분해 남겼습니다.
처음 사이트를 만든다면 다음 다섯 가지만 직접 눌러 확인해 보세요.
- 첫 화면에서 블로그로 들어갈 수 있는가?
- 글에서 로고를 누르면 홈페이지로 돌아오는가?
- 카테고리와 다음 페이지에 실제 글이 나오는가?
- 모바일에서 이미지와 본문이 화면 밖으로 밀려나지 않는가?
- 로그아웃한 상태에서도 최종 글 주소가 열리는가?
지금 다시 구성한다면 메뉴별 역할과 편집 위치를 먼저 한 장으로 적을 것 같습니다. 그다음 첫 글을 올려 홈페이지에서 글로, 글에서 홈페이지로 오가는 길을 확인하겠습니다. 설정 화면을 채운 순간보다, 방문자가 내용을 읽고 다음 화면으로 이동하는 순간이 실제 완성에 가까웠습니다.
실제 구성은 나인투식스랩 홈페이지와 블로그에서 살펴보실 수 있습니다. 운영 경험을 콘텐츠로 정리한 다른 사례로는 쓰레드 자동화의 게시·결과 확인 과정도 함께 읽어 보세요.