글은 있는데 독자가 찾을 수 없다면: 블로그 추천 목록 점검하기

글 주소는 정상인데 추천 목록에서는 빠진 사례다. 사이트를 운영하는 사람이 직접 주소를 여는 검사와 메뉴에서 글을 찾는 검사를 구분하고, 이름이나 주소를 바꾼 뒤 누락을 점검하는 방법을 정리했다.

글을 발행했고 주소도 정상적으로 열리는데, 추천 목록에는 그 글이 없었다. 주소를 아는 사람은 읽을 수 있지만 메뉴나 추천 글을 따라오는 독자는 그곳에서 발견할 수 없는 상태였다.

이 블로그에서는 추천 목록이 옛 글 이름을 참조하면서 이런 누락이 생겼다. 이전 주소를 새 글로 연결해 둔 덕분에 링크는 열렸지만, 추천 목록을 만드는 조회에서는 글을 찾지 못했다. ‘주소가 열린다’와 ‘독자가 사이트 안에서 찾아갈 수 있다’는 다른 확인이었다.

글 이름이나 주소를 바꿨다면 목록에서도 찾아보기

바꾼 글의 주소를 직접 여는 데서 끝내지 말고, 홈·카테고리·관련 글처럼 독자가 들어오는 목록에서 그 글을 찾아본다. 표시할 항목과 실제 항목의 이름을 대조하고, 중복이나 의도적으로 제외한 글도 구분한다. 개수만 같아도 다른 글이 대신 들어가 있을 수 있다.

아래는 9월 25일에 고친 추천 설정을 9월 28일에 다시 대조한 기록이다. 수정 전 설정에서는 4건이 조회되지 않았고, 수정 후에는 설정한 항목이 모두 조회됐다. 독자 유입이나 검색 순위의 변화는 측정하지 않았다. 이 글은 그 작은 사례를 이용해 사이트의 ‘찾아가는 경로’를 점검하는 방법을 설명한다.

설명용 개념 일러스트이며 실제 측정 개수의 재현이 아니다.

목록은 세 단계를 거친다

화면에 보이는 추천 목록은 보통 다음 세 단계로 만들어진다.

1. 설정 항목: 표시하려고 지정한 글의 목록(이름·식별자 형태).
2. 조회: 각 식별자를 실제 글 데이터와 대조해 본문을 찾는 단계.
3. 표시: 조회에 성공한 항목만 카드로 렌더링하는 단계.

문제는 2단계에서 생긴다. 이번 사례의 원인도 여기에 있었다. 데이터 조회가 정식 규격에 맞는 글 파일만 대상으로 삼고, 조건에 맞는 항목을 찾지 못하면 빈 배열을 반환하는 구조였다. 빈 배열은 오류가 아니다. 예외도, 경고 로그도 없이 “결과 없음”으로 처리되고, 3단계는 결과 없는 항목을 그냥 건너뛴다. 목록은 조용히 짧아진다.

조회 단계에서 흔히 쓰는 코드는 이렇게 생겼다.

const matches = posts.filter((p) => p.id === id);
// 조건에 맞는 글이 없으면 빈 배열 — 오류도 경고도 발생하지 않는다

JavaScript의 filter나 find는 일치 항목이 없을 때 각각 빈 배열과 undefined를 반환할 뿐 실패를 알리지 않는다(MDN — Array.prototype.find()). 그래서 조회 실패를 일부러 세지 않는 한, 누락은 스스로 드러나지 않는다.

어떤 글이 조회에 실패하는가

정식 규격 대조 방식으로 조회하면, 글 자체는 멀쩡해도 다음 경우에 조회만 실패한다.

• 이름 변경: 파일이나 식별자를 나중에 바꾸면서 목록 설정의 옛 이름이 남아 있는 경우.
• 주소 이동·통합: 오래된 글을 새 통합 글로 옮긴 경우. 옛 주소로는 이동 안내 페이지가 제공된다.
• 형식 불일치: 글은 존재하지만 조회가 요구하는 형식(예: 정식 문서 규격)과 달라 대조에서 제외되는 경우.

가상 예시: 상품 데이터 목록의 코드 변경

참고: 다음은 구조 이해를 돕기 위한 가상 설명 예시다. 측정 성과는 제시하지 않는다.

쇼핑몰이 메뉴에 “인기 상품 10개”를 표시한다고 가정하자. 상품 개편으로 내부 코드가 바뀌었는데 메뉴 설정에는 옛 코드가 남아 있으면, 조회 단계에서 해당 상품 데이터를 찾지 못해 빈 결과를 반환한다. 상품 상세 페이지는 정상적으로 열리므로 링크 검사는 통과한다. 메뉴에서만 한 칸이 조용히 사라진다. 이번 글의 목록 누락도 같은 구조가 글 식별자에 적용된 사례다.

여기서 중요한 구분이 있다. 주소 이동은 링크 깨짐이 아니다. 오래된 글을 통합 글로 옮긴 경우 옛 주소로 접속하면 새 글로 보내는 페이지가 작동하므로, 링크 검사는 통과한다. Google의 검색 문서도 페이지를 옮기거나 사이트를 합칠 때 리다이렉트를 두면 기존 URL로 오는 사용자와 크롤러가 새 위치를 따라갈 수 있다고 설명한다(Google Search Central — Redirects and Google Search). 즉 사용자 입장에서는 링크가 살고 있는데, 목록을 만드는 내부 조회는 옛 식별자를 정식 글로 찾지 못해 실패할 수 있다. 링크 검사와 목록 완전성 검사가 서로 다른 이유다.

실제로 확인한 누락: 주제별 대조

이번 사례에서 수정 전 추천 설정과 현재 정식 글 데이터를 주제별로 대조하면 이렇다. 수정은 2026년 9월 25일에 했고, 아래 수치는 9월 28일에 수정 전후 구성을 정식 글 데이터와 재대조해 조회한 결과다. 당시 화면에서 실측한 카드 수도, 트래픽 실험 결과도 아니다.

누락은 총 4건이었다. 모두 글 자체가 사라진 것이 아니라, 목록 조회가 실패해 카드만 표시되지 않은 경우였다.

수정은 조회 대상을 넓힌 것이 아니었다. 추천 설정의 옛 식별자를 현재 정식 글 식별자로 바꾸고, 항목이 조회되지 않거나 주제가 일치하지 않으면 빌드를 실패시키는 검증을 추가했다. 수정 후 구성을 다시 대조했을 때 네 주제 모두 조회된 수가 설정 수와 같았다(9월 28일 재확인).

한 가지는 조심해서 읽어야 한다. 수정 후에는 추천 설정 자체도 늘렸다(업무 자동화 주제는 1개에서 3개로). 그래서 전체 카드 수가 늘어난 것을 버그 수정의 효과로 해석하면 안 된다. 수정의 검증 기준은 “카드 총수 증가”가 아니라 “설정 수 대비 누락 0건”이다.

독자를 위한 확인표

자기 사이트나 어떤 데이터 목록이든 같은 방법으로 점검할 수 있다.

2번과 3번은 반드시 분리해서 적용한다. 3번만 통과했다고 목록이 완전한 것이 아니고, 2번에서 빠진 항목이 있어도 3번은 전부 통과할 수 있다. 이번 사례가 정확히 그 조합이었다.

설명용 개념 일러스트이며 실제 측정 수의 재현이 아니다.

이 점검은 다음 세 시점에 하면 효과적이다. 항목의 이름이나 위치를 바꾼 직후, 메뉴·추천 같은 목록 설정을 변경한 직후, 그리고 정기적으로(예: 월 1회) 목록 전체를 점검할 때. 앞의 두 시점을 지킬수록 변경 때 생긴 누락을 바로 잡기 쉽다.

수정 후 확인 기준

수정 후에는 다음을 기준으로 삼는 것을 권한다.

• 누락 0건: 모든 기대 항목이 표시되는가. 이것이 1차 기준이다.
• 구성 변화 분리: 수정과 함께 설정 수를 바꾸었다면, 전후 총수 비교가 아니라 주제별 “설정 수 = 표시 수”로 검증한다.
• 재현 대조: 수정 내용을 다시 적용해 대조했을 때 같은 결과가 나오는가. 이번 사례에서는 9월 28일에 수정 전후 구성을 정식 글 데이터와 재대조해 같은 결론을 확인했다.

한계

이 글의 수치는 공개된 글 데이터와의 대조(조회) 결과이지, 검색 유입·색인 상태·광고 승인이나 방문자 행동의 개선 측정값이 아니다. 리다이렉트가 검색 결과에 반영되는 방식은 Google 문서에 설명된 일반 원칙이며, 이번 사례에서 별도로 측정하지 않았다. 본문 이미지는 개념 전달용 삽화로 실제 측정 값의 재현이 아니다.

확인한 출처 / 근거

• Google Search Central — Redirects and Google Search: 페이지 이동·통합 시 리다이렉트의 역할과 영구/임시 리다이렉트 구분. “주소 이동은 링크 깨짐과 다르다”는 논의의 근거. (2026-09-28 직접 열어 확인)
• MDN — Array.prototype.find(): 일치 항목이 없을 때 undefined 반환 — 조회 실패가 조용히 일어난다는 설명의 근거. (2026-09-28 직접 열어 확인)
• MDN — Array.prototype.flatMap(): 배열 변환·펼침 동작 — 목록 생성 코드 이해를 위한 참고. (2026-09-28 직접 열어 확인)
• 참고: 주제별 설정/조회/누락 수치는 2026-09-25 수정본과 수정 전 구성을 2026-09-28에 공개 글 데이터와 재대조한 내부 검증 기록이며, 트래픽·사용자 실험이 아니다.