블로그에 사이트 검색을 붙이기 전에 정해야 할 기준

블로그에 글이 10개 정도 있을 때는 검색 기능이 없어도 크게 불편하지 않습니다. 홈에서 최신 글을 보고, 블로그 목록에서 제목을 훑으면 됩니다. 그런데 글이 30개를 넘기고, 주제가 검색/신뢰, 기반 설계, 경험/운영, 도구 제작처럼 나뉘기 시작하면 이야기가 달라집니다. 운영자는 “예전에 쓴 그 글 어디 있었지?”를 찾게 되고, 독자는 특정 문제를 해결하려고 들어왔다가 비슷한 글을 더 읽고 싶어집니다.

이때 가장 쉬운 선택은 검색창을 하나 붙이는 것입니다. 하지만 검색 기능은 입력창이 아니라 약속입니다. 무엇을 찾아줄 것인지, 어떤 결과를 먼저 보여줄 것인지, 검색어가 없을 때와 결과가 없을 때 어떻게 반응할 것인지 정하지 않으면, 검색창은 오히려 사이트를 허술해 보이게 만들 수 있습니다. 특히 작은 블로그에서는 검색 품질이 조금만 어색해도 “이 사이트는 아직 덜 정리됐구나”라는 인상을 줄 수 있습니다.

이 글은 블로그에 사이트 검색을 붙이기 전에 정해야 할 기준을 정리한 메모입니다. 아직 거대한 검색 엔진을 만들 필요는 없습니다. 작은 블로그에 맞게 색인 범위, 결과 카드, 정렬 기준, 빈 결과 처리, 운영 비용을 먼저 정하면 됩니다.

도구 제작검색 도구 설계

블로그에 사이트 검색을 붙이기 전에 정해야 할 기준

블로그 검색은 입력창 하나를 붙이는 일보다 먼저 색인 범위, 결과 카드, 정렬 기준, 빈 결과 처리, 운영 비용을 정해야 오래 갑니다. 작은 블로그 기준의 검색 설계 기준을 정리했습니다.

핵심 1

검색창보다 먼저 정해야 할 것은 검색의 약속입니다

핵심 2

첫 버전은 제목, 요약, 카테고리, 날짜만으로도 충분할 수 있습니다

핵심 3

로컬 JSON 검색과 외부 검색 서비스를 구분합니다

검색 도구 설계도구 제작blog site search design

검색창보다 먼저 정해야 할 것은 검색의 약속입니다

검색 기능을 만들기 전에 가장 먼저 써봐야 할 문장은 이것입니다.

이 검색은 무엇을 찾아주는가?

답이 “사이트 전체”라면 너무 넓습니다. 작은 블로그에서는 보통 아래 중 하나로 좁히는 편이 좋습니다.

• 발행된 블로그 글만 검색한다
• 제목과 요약만 검색한다
• 제목, 요약, 본문 소제목까지 검색한다
• 전체 본문까지 검색한다
• 정책 페이지와 도구 페이지까지 포함한다

처음부터 전부 검색하려고 하면 구현은 복잡해지고 결과 품질은 낮아질 수 있습니다. 예를 들어 개인정보처리방침이나 이용약관까지 검색 결과에 나오면, 사용자는 글을 찾으려다 정책 페이지를 먼저 볼 수 있습니다. 도구 페이지까지 포함하면 도구와 글의 결과 형식이 달라져 카드 설계가 더 어려워집니다.

그래서 저는 작은 블로그의 첫 검색은 “발행된 글만 검색”으로 시작하는 편을 추천합니다. 검색창이 블로그 아카이브 안에 있다면 더더욱 그렇습니다. 글 검색을 안정적으로 만든 뒤, 나중에 도구 페이지나 정책 페이지까지 확장해도 늦지 않습니다.

첫 버전은 제목, 요약, 카테고리, 날짜만으로도 충분할 수 있습니다

검색이라고 하면 곧바로 본문 전체 검색을 떠올리기 쉽습니다. 하지만 글 수가 적은 블로그에서는 제목과 요약만으로도 꽤 쓸 만합니다. 오히려 첫 버전에서는 제목, 요약, 카테고리, 발행일을 명확히 다루는 쪽이 더 안정적입니다.

색인 필드를 나누면 이렇게 볼 수 있습니다.

이 블로그 구조에서는 이미 title, summary, category, focus, publishedAt이 정리되어 있습니다. 따라서 첫 검색 인덱스는 이 필드만으로도 시작할 수 있습니다. 본문 전체를 넣는 것은 나중에 “검색어를 넣었는데 분명히 있는 글이 안 나온다”는 상황이 반복될 때 확장해도 됩니다.

검색 기능은 처음부터 강할 필요보다 예측 가능해야 합니다. 사용자가 제목이나 요약에 나온 단어로 검색했을 때 결과가 나오고, 결과 카드가 왜 뜬 건지 이해되면 첫 버전으로 충분합니다.

로컬 JSON 검색과 외부 검색 서비스를 구분합니다

작은 블로그에서 중요한 선택 중 하나는 검색을 어디에서 처리할지입니다. 크게 보면 두 갈래입니다.

현재처럼 정적 블로그와 작은 도구를 함께 운영하는 구조라면, 첫 버전은 로컬 JSON 검색이 잘 맞습니다. 빌드 시점에 발행 글 목록을 JSON으로 만들고, 브라우저에서 검색어를 정규화해 필터링하면 됩니다. 글 수가 30개, 50개, 100개 수준이라면 이 방식이 충분히 가볍습니다.

외부 검색 서비스는 나쁜 선택이 아닙니다. 다만 “검색창을 붙이고 싶다”는 이유만으로 바로 도입하기에는 과할 수 있습니다. 외부 스크립트, 크롤링 설정, 색인 갱신 주기, 비용, 개인정보처리방침 문구, 장애 시 대체 흐름까지 같이 따라옵니다. 검색은 사용자 입력을 다루는 기능이므로, 사이트 정책과도 연결됩니다.

그래서 저는 이렇게 판단합니다.

• 글 수가 적고 검색 대상이 블로그 글뿐이면 로컬 JSON
• 오타 보정, 동의어, 다국어 검색이 중요해지면 외부 검색 검토
• 제품 문서처럼 검색이 핵심 기능이면 처음부터 검색 서비스 검토
• 단순 운영 블로그라면 먼저 로컬 검색으로 사용 패턴 확인

이 기준은 slug 변환기나 UTM 빌더 같은 작은 SEO 도구는 어떤 기준으로 고를까에서 말한 작은 도구 선택 기준과도 같습니다. 반복적으로 쓰이고, 입력과 출력이 분명하고, 유지보수 비용이 낮은 것부터 시작하는 편이 좋습니다.

검색 인덱스는 화면 데이터와 분리하는 편이 좋습니다

처음에는 블로그 목록 데이터를 그대로 검색에 써도 됩니다. 하지만 조금만 커지면 검색 인덱스를 별도 모델로 보는 편이 안정적입니다. 화면 카드에 필요한 데이터와 검색에 필요한 데이터가 완전히 같지는 않기 때문입니다.

예를 들어 검색 인덱스는 이런 식으로 시작할 수 있습니다.

type SearchIndexItem = {
  slug: string;
  title: string;
  summary: string;
  category: string;
  focus: string;
  publishedAt: string;
  updatedAt?: string;
  href: string;
  headings?: string[];
};

이 모델의 장점은 분명합니다.

• 검색 결과 카드에 필요한 필드가 고정됩니다.
• 나중에 headings나 keywords를 추가하기 쉽습니다.
• 본문 전체를 넣을지 말지 독립적으로 판단할 수 있습니다.
• 검색 UI가 원본 Markdown 구조에 직접 의존하지 않습니다.

검색 인덱스를 따로 둔다고 해서 과한 추상화는 아닙니다. 오히려 검색이 무엇을 약속하는지 코드로 드러내는 방식입니다. 글 데이터 전체를 브라우저로 넘기는 것보다 필요한 필드만 정리해 내보내면 성능과 개인정보, 유지보수 면에서도 깔끔합니다.

검색어 정규화 규칙을 먼저 정합니다

검색 품질은 랭킹 알고리즘보다 정규화에서 먼저 갈립니다. 작은 블로그에서는 복잡한 검색 엔진보다 기본 정규화가 훨씬 중요합니다.

최소한 아래는 정해두는 편이 좋습니다.

• 앞뒤 공백 제거
• 여러 공백을 하나로 합치기
• 영문 대소문자 구분하지 않기
• 하이픈과 공백을 어느 정도 비슷하게 다루기
• 너무 짧은 검색어는 바로 검색하지 않기
• 한글 조합 검색은 처음엔 무리하지 않기

예를 들어 open graph, Open Graph, open-graph가 완전히 다른 검색어처럼 동작하면 사용자는 검색 품질이 낮다고 느낍니다. 반대로 처음부터 형태소 분석이나 초성 검색까지 넣으려고 하면 구현 범위가 커집니다. 첫 버전에서는 “운영자가 실제 글 제목과 요약에 쓰는 표현”을 기준으로 안정적인 일치 검색을 만드는 편이 좋습니다.

간단한 정규화는 이런 느낌으로 시작할 수 있습니다.

function normalizeSearchText(value: string) {
  return value
    .trim()
    .toLowerCase()
    .replace(/[-_/]+/g, " ")
    .replace(/\s+/g, " ");
}

이 정도만 해도 영문 키워드, slug 조각, 기술 용어 검색의 체감 품질이 꽤 좋아집니다.

결과 정렬은 최신순만으로 부족할 수 있습니다

블로그 목록은 보통 최신순이 자연스럽습니다. 하지만 검색 결과는 최신순만으로는 부족할 수 있습니다. 검색어와 정확히 맞는 글이 오래됐다는 이유로 아래에 묻히면 사용자는 검색이 부정확하다고 느낍니다.

첫 버전의 정렬 기준은 너무 복잡하지 않아도 됩니다. 예를 들어 아래 정도면 충분합니다.

이 방식은 단순하지만 설명 가능합니다. “제목에 검색어가 있는 글이 먼저 나온다”는 것은 사용자가 이해하기 쉽습니다. 반대로 점수 계산이 지나치게 복잡하면 운영자도 왜 어떤 글이 위에 나오는지 설명하기 어려워집니다.

작은 블로그 검색에서 중요한 건 완벽한 랭킹이 아니라 납득 가능한 랭킹입니다. 사용자가 검색 결과를 보고 “아, 이래서 이 글이 먼저 나왔구나”라고 느끼면 충분합니다.

검색 결과 카드는 글 카드와 완전히 같을 필요가 없습니다

검색 결과는 일반 글 목록 카드와 목적이 다릅니다. 글 목록 카드는 훑어보는 용도이고, 검색 결과 카드는 “내가 찾는 답인가”를 빠르게 판단하는 용도입니다. 그래서 검색 결과 카드에는 아래 정보가 있으면 좋습니다.

• 제목
• 짧은 요약
• 카테고리
• focus
• 발행일 또는 수정일
• 검색어가 어디에 걸렸는지에 대한 힌트

처음부터 본문 하이라이트를 멋지게 구현할 필요는 없습니다. 하지만 제목에서 걸렸는지, 요약에서 걸렸는지 정도만 알려줘도 사용자는 결과를 더 잘 이해합니다.

예를 들어 이런 식입니다.

Open Graph와 Twitter Card가 깨질 때 확인할 체크리스트
검색/신뢰 · 공유 미리보기 · 2026-03-12
요약에서 "Open Graph"와 일치

이 정도 정보면 사용자는 바로 클릭할지 말지 판단할 수 있습니다. 검색 결과는 예쁜 카드보다 빠른 판단을 돕는 쪽이 더 중요합니다.

빈 결과 화면은 검색 기능의 신뢰를 좌우합니다

검색어를 넣었는데 결과가 없을 때가 가장 중요합니다. 좋은 검색은 결과가 없을 때도 사용자를 버리지 않습니다. 작은 블로그에서는 아래 정도의 처리가 좋습니다.

• 입력한 검색어를 다시 보여줍니다.
• 철자나 띄어쓰기 변경을 제안합니다.
• 카테고리 목록으로 돌아갈 수 있게 합니다.
• 최신 글이나 대표 글 몇 개를 보여줍니다.
• 너무 짧은 검색어에는 더 입력하라고 안내합니다.

빈 결과에서 피해야 할 것은 침묵입니다. 아무것도 안 보이면 사용자는 검색이 고장 났는지, 정말 결과가 없는지 알 수 없습니다. 특히 한글과 영문 기술 용어가 섞인 블로그에서는 표기 차이 때문에 결과가 없을 수 있으니, 빈 결과 화면은 넉넉하게 설계하는 편이 좋습니다.

이 부분은 404 페이지와 리다이렉트가 작은 블로그 신뢰도에 미치는 영향과도 닮아 있습니다. 404가 길을 잃은 사용자를 다시 아카이브로 보내야 하듯, 검색의 빈 결과도 다음 행동을 제안해야 합니다.

성능은 인덱스 크기보다 렌더링 방식을 먼저 봅니다

글 30개짜리 블로그에서 검색 인덱스 크기는 큰 문제가 아닙니다. 문제는 검색할 때마다 불필요하게 큰 렌더링이 일어나거나, 입력할 때 화면이 덜컥거리는 경우입니다. 특히 모바일에서 검색창과 결과 리스트가 흔들리면 검색 기능이 무겁게 느껴집니다.

첫 버전에서는 아래 정도만 챙겨도 충분합니다.

• 검색 인덱스에는 필요한 필드만 넣기
• 입력값이 비어 있으면 전체 필터링을 반복하지 않기
• 결과 수를 적당히 제한하기
• 검색어 입력과 결과 영역의 높이 변화가 너무 크지 않게 하기
• URL query parameter로 검색어를 남길지 여부를 정하기

검색어를 URL에 남기면 공유와 새로고침에는 좋습니다. 예를 들어 /blog?q=canonical 같은 형태입니다. 하지만 초반에는 UI 상태 관리가 조금 복잡해질 수 있습니다. 검색 페이지가 별도로 있다면 쿼리 파라미터가 좋고, 블로그 목록 안의 가벼운 필터라면 내부 상태로 시작해도 됩니다.

성능 최적화는 Next.js 이미지 최적화로 LCP를 줄이는 실제 방법처럼 큰 자산만의 문제가 아닙니다. 검색 입력처럼 작고 자주 만지는 UI도 체감 성능에 영향을 줍니다.

검색 로그를 남길지 여부는 신중하게 정합니다

사이트 검색을 만들면 “사람들이 무엇을 검색하는지 알고 싶다”는 생각이 자연스럽게 듭니다. 검색 로그는 콘텐츠 기획에 도움이 될 수 있습니다. 하지만 사용자 입력을 기록하는 순간 개인정보와 정책 문구를 같이 생각해야 합니다.

작은 블로그 첫 버전에서는 검색 로그를 남기지 않아도 됩니다. 로컬 JSON 검색은 브라우저 안에서만 동작하므로 서버에 검색어를 보내지 않을 수 있습니다. 이건 구현도 단순하고 정책 부담도 낮습니다.

나중에 검색어 통계를 수집하고 싶다면 최소한 아래를 정해야 합니다.

• 어떤 검색어를 저장하는가
• IP나 사용자 식별자와 연결하지 않는가
• 보관 기간은 얼마인가
• 개인정보처리방침에 설명되어 있는가
• 사용자가 민감한 내용을 입력할 가능성은 없는가

이 기준은 GA4를 붙였을 때 개인정보처리방침에 꼭 맞춰 써야 하는 문구와도 연결됩니다. 기능을 추가했다면 정책 문구도 실제 동작과 맞아야 합니다.

제가 추천하는 첫 검색 버전

이 블로그 같은 규모라면 첫 버전은 아래 정도가 좋습니다.

이 정도면 작은 블로그에서는 충분히 실제로 쓸 수 있습니다. 글 수가 더 늘고 검색어 패턴이 보이면 그때 본문 검색, 초성 검색, 동의어, 외부 검색 서비스를 검토하면 됩니다.

마무리

블로그 검색은 기능처럼 보이지만 사실은 정보 구조의 일부입니다. 검색창을 붙이기 전에 무엇을 찾게 할지, 어떤 필드를 색인할지, 결과를 어떻게 정렬할지, 빈 결과에서 어디로 안내할지 정해야 합니다. 이 기준이 없으면 검색 기능은 있어도 신뢰가 생기지 않습니다.

작은 블로그에서는 처음부터 거대한 검색 시스템을 만들 필요가 없습니다. 발행된 글을 대상으로 제목, 요약, 카테고리, focus를 검색하고, 결과 카드를 명확하게 보여주는 것만으로도 충분히 유용합니다. 중요한 건 검색 기능을 “있어 보이는 장식”이 아니라 운영자가 계속 관리할 수 있는 작은 도구로 만드는 것입니다. 그렇게 시작하면 나중에 글이 50개, 100개로 늘어도 검색의 기준이 흔들리지 않습니다.