CloudPlare
운영

우리 체크리스트로 우리 사이트를 다시 점검한 기록

쓴 사람 김영주 · 최초 작성 2026-07-14 · 최종 검토 2026-07-14 · 3분 읽기

체크리스트를 글로만 정리해두고 정작 자기 사이트에는 적용해보지 않으면, 그 체크리스트는 아직 검증된 것이 아닙니다. /checklist에 적어둔 항목을 cloudplare.com 자신에게 그대로 돌려본 기록입니다.

한눈에 보는 흐름

체크리스트를 자기 사이트에 적용광고 스크립트 노출 범위 재검토sitemap·메타데이터 재계산남은 항목은 미해결로 표시

왜 다른 사이트가 아니라 우리 사이트부터 봤나

CloudPlare의 /checklist에는 "기준 주소, canonical, sitemap이 같은 주소를 가리키는지 확인한다", "콘텐츠가 실제로 있는 페이지에서만 광고가 보이는지 확인한다" 같은 항목이 있습니다. 이 문서를 새로 쓰는 대신, 이미 적어둔 항목을 우리 사이트에 그대로 적용해 무엇이 실제로 걸리는지 확인했습니다.

결과적으로 세 가지 문제를 찾았고, 모두 코드에 남아 있던 것이었습니다. 아래는 발견한 순서 그대로의 기록입니다.

문제 1 — 콘텐츠가 거의 없는 화면에도 광고 스크립트가 실렸다

광고 스크립트(adsbygoogle.js)가 루트 레이아웃의 head에서 전역으로 로드되고 있었습니다. 즉 문의 폼 하나뿐인 /contact, 약관 텍스트만 있는 /privacy·/terms, 그리고 커스텀 404 페이지가 아예 없어 Next.js 기본 404 화면이 뜨던 경로에도 예외 없이 같은 스크립트가 실렸습니다.

조치는 방문 경로에 따라 스크립트 로드 여부를 판단하는 클라이언트 컴포넌트를 만들고, 콘텐츠가 실질적으로 있는 경로만 화이트리스트로 명시하는 것이었습니다.

src/components/AdsenseLoader.tsx (핵심 판정 로직)

const AD_ELIGIBLE_EXACT = ['/', '/checklist', '/glossary', '/about', '/editorial-policy'];
const AD_ELIGIBLE_PREFIXES = ['/notes'];

function isAdEligible(pathname: string): boolean {
  if (AD_ELIGIBLE_EXACT.includes(pathname)) return true;
  return AD_ELIGIBLE_PREFIXES.some(
    (prefix) => pathname === prefix || pathname.startsWith(`${prefix}/`)
  );
}

이 방식의 장점은 블랙리스트가 아니라 화이트리스트라는 점입니다. 새 유틸리티 페이지를 추가했을 때 실수로 목록에 안 넣으면 "광고가 안 뜨는" 쪽으로 실패하지, "콘텐츠 없는 화면에 광고가 뜨는" 쪽으로 실패하지 않습니다.

문제 2 — sitemap이 실제 수정일과 다른 날짜를 보고했다

sitemap.ts의 모든 항목이 lastModified를 new Date()로 채우고 있었습니다. 빌드되거나 요청될 때마다 "지금"이 찍히는 구조라, 6월 초에 쓰고 검토가 끝난 글도 sitemap에서는 항상 "방금 수정됨"으로 보였습니다. 개별 글의 JSON-LD에는 실제 검토일(reviewedAt)이 정확히 들어가는데, sitemap과 그 값이 서로 어긋나는 상태였습니다.

수정 전/후 요약

// 수정 전
lastModified: new Date()               // 매 빌드마다 "지금"

// 수정 후
lastModified: new Date(note.reviewedAt) // 실제 검토일 그대로

고치고 나니 sitemap의 lastmod 값이 노트별로 2026-06-08부터 2026-06-12까지 실제 검토일 그대로 흩어져 나왔습니다. 크롤러 입장에서는 "이 사이트는 실제로 각 글을 다른 시점에 손봤다"는, 이전보다 훨씬 정직한 신호입니다.

문제 3 — 읽기 시간이 실제 글자 수와 무관했다

각 노트의 readingMinutes 값을 실제 본문 글자 수로 나눠보니 분당 118자에서 351자까지 거의 3배 차이가 났습니다. 가장 긴 글이 오히려 가장 짧은 읽기 시간으로 표시된 경우도 있었습니다. 실제로 계산해서 넣은 값이 아니라 6~9분 사이에서 임의로 채운 값이었다는 뜻입니다.

분당 400자를 기준으로 요약과 본문 글자 수를 다시 계산해 전체 글의 readingMinutes를 2~4분 범위로 다시 채웠습니다. 숫자가 작아 보일 수 있지만, 실제 분량과 맞는 숫자가 부풀려진 숫자보다 낫다고 판단했습니다.

이번 점검에서 남은 것과 남기지 않은 것

이번에 고친 세 가지는 코드만으로 끝나는 문제였습니다. 반면 실기기에서 320~375px 폭을 직접 확인하는 것, EEA 방문자를 위한 동의관리플랫폼(CMP) 연동, 실제 스크린샷과 명령어 실행 결과를 글에 넣는 것은 코드 수정만으로 끝나지 않아 이번 점검에서는 항목만 확인하고 미해결로 남겨뒀습니다.

체크리스트를 스스로에게 적용해서 나온 결과를 숨기지 않고 그대로 남기는 것도 이 글의 목적 중 하나입니다. 다음 점검에서 이 글의 "수정 이력"에 추가로 남길 예정입니다.

운영 체크리스트

  • 광고 스크립트가 콘텐츠 없는 화면(문의, 정책, 404)에도 실리고 있지 않은지 확인했다.
  • sitemap의 lastModified가 실제 콘텐츠 수정일과 일치하는지 확인했다.
  • 읽기 시간 같은 메타데이터가 실제 콘텐츠 분량과 비례하는지 확인했다.
  • 전 페이지의 canonical과 OG URL이 자기 자신의 주소를 가리키는지 확인했다.
  • 고치지 못한 항목은 숨기지 않고 미해결로 기록해뒀다.

관련 노트

운영

접속 로그에서 이상 징후를 먼저 알아채는 법

운영

소규모 사이트 장애 기록은 어떻게 남기면 좋을까

DNS

메일 인증 레코드(SPF, DKIM, DMARC)를 정리하는 순서

확인한 공식 자료

아래 자료를 바탕으로 운영 관점의 설명을 덧붙였습니다. 세부 동작은 서비스와 배포 환경에 따라 달라질 수 있습니다.

이 글의 수정 이력

  • 2026-07-14최초 게시 — 광고 스크립트 노출 범위, sitemap lastModified, readingMinutes 계산 방식 점검 결과 반영