작은 팀 블로그의 SEO, GEO, AEO 개선 기록: JSON-LD 다음에 한 것들#

얼마 전 우리는 위글플러스 블로그와 Typefy에 JSON-LD 구조화 데이터를 넣고, 그것이 SEO, GEO, AEO에 어떤 의미가 있는지 정리했습니다.

그 글의 결론은 단순했습니다. JSON-LD는 검색 순위를 올리는 버튼이 아닙니다. 대신 검색엔진과 AI 검색 시스템이 페이지를 더 정확히 이해하도록 돕는 보조 신호입니다.

그 다음 질문은 자연스럽게 이어졌습니다.

JSON-LD를 넣은 뒤에는 무엇을 더 손봐야 할까?

이번 글은 그 후속 기록입니다. 위글플러스 팀 블로그에서 OG 이미지, RSS 피드, BreadcrumbList, 블로그 인덱스 JSON-LD, 동적 키워드, canonical URL을 어떻게 묶어서 봤는지 정리합니다.

관점은 세 가지입니다.

1. SEO: 검색 결과에 더 정확하고 클릭 가능한 형태로 노출되기
2. GEO: 생성형 검색이 출처로 이해하기 쉬운 구조 만들기
3. AEO: 질문에 답할 수 있는 단위로 콘텐츠 정리하기

먼저 문제를 숫자로 봤습니다#

작은 팀 블로그에서 SEO 개선을 할 때 가장 조심해야 할 점은 "멋있어 보이는 작업"에 시간을 쓰는 것입니다.

그래서 우리는 먼저 블로그의 현재 상태를 봤습니다.

최근 블로그 기획 문서 기준으로 /blog는 읽히고 있었습니다. 예를 들어 최근 30일 기준 /blog는 PV 477, activeUsers 106, bounceRate 22.1%, avgSessionDuration 199초 수준이었습니다. 다른 문서에서는 블로그 DAU가 15~25명/일, 평균 스크롤 깊이가 57~100%로 기록되어 있었습니다.

문제는 읽기 품질보다 유입면이었습니다.

같은 기간 검색 유입은 작았습니다. 블로그 주제별 모아보기 기획에서는 Direct 107 sessions 대비 Organic Search 11 sessions로 기록했습니다. OG 이미지 기획에서는 Organic Social이 34%, Organic Search가 4.3%로 정리되어 있었습니다.

이 숫자에서 우리가 내린 결론은 이렇습니다.

• 들어온 사람은 꽤 읽습니다.
• 그런데 검색과 공유에서 들어오는 입구가 좁습니다.
• 따라서 본문 품질만이 아니라 검색 결과, SNS 미리보기, 피드 배포, 페이지 구조를 함께 손봐야 합니다.

그래서 이번 개선은 "글을 더 쓰자"가 아니라 "이미 쓴 글이 더 잘 발견되고, 더 잘 이해되고, 더 잘 클릭되게 하자"에 가까웠습니다.

SEO 관점: 검색 결과에서 오해를 줄이고 클릭 이유를 늘립니다#

SEO에서 우리가 먼저 본 것은 검색엔진이 페이지를 어떻게 읽고, 검색 결과에 어떻게 보여주는가였습니다.

Google Search Central은 구조화 데이터가 페이지 의미에 대한 명시적인 단서를 제공한다고 설명합니다. 또한 Google은 구조화 데이터를 사용해 페이지를 이해하고, 경우에 따라 리치 결과를 만들 수 있다고 안내합니다. 다만 올바르게 마크업해도 검색 결과 노출이 보장되는 것은 아닙니다.

출처:

• Google 구조화 데이터 소개
• Google Search 구조화 데이터 갤러리
• Google 구조화 데이터와 리치 결과 안내

이 관점에서 블로그에 필요한 작업은 네 가지였습니다.

1. 블로그 인덱스 페이지를 Blog로 설명하기
2. 상세 글을 BlogPosting으로 설명하고 image를 포함하기
3. BreadcrumbList로 홈, 블로그, 글 상세 경로를 알려주기
4. 공유와 검색 미리보기에 쓸 1200x630 OG 이미지를 제공하기

여기서 중요한 점은 "검색엔진만 보는 데이터"를 따로 만드는 것이 아닙니다. 실제 페이지에 있는 제목, 요약, 작성자, 날짜, URL, 이미지 정보를 기계가 읽기 좋은 형식으로 다시 정리하는 것입니다.

예를 들어 블로그 상세 글의 BlogPosting은 이런 데이터를 갖습니다.

const postUrl = `https://weggle-plus.co.kr/blog/posts/${post.id}/${slug}`;

const blogPostingJsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  description: post.summary,
  image: `${postUrl}/opengraph-image`,
  author: {
    "@type": "Person",
    name: post.authorName,
  },
  datePublished: post.publishedAt ?? post.createdAt,
  dateModified: post.updatedAt,
  mainEntityOfPage: {
    "@type": "WebPage",
    "@id": postUrl,
  },
};

이 코드는 검색 순위를 직접 올리기 위한 코드가 아닙니다. 검색엔진이 "이 페이지는 누가 언제 쓴 어떤 글이고, 대표 이미지는 무엇이며, 원본 URL은 어디인가"를 추측하지 않게 만드는 코드입니다.

특히 image는 중요했습니다. 이미 opengraph-image.tsx로 글별 OG 이미지를 만들고 있었지만, JSON-LD의 BlogPosting에도 같은 이미지 URL을 넣어야 구조화 데이터 안에서도 대표 이미지가 명확해집니다.

OG 이미지는 공유용 장식이 아니라 클릭 전 정보입니다#

블로그의 Organic Social 비율이 34%로 기록되어 있었기 때문에, OG 이미지는 단순한 꾸미기 작업이 아니었습니다.

SNS, 카카오톡, Facebook, LinkedIn, Threads에서 링크가 공유될 때 사용자는 본문을 읽기 전에 제목과 이미지를 먼저 봅니다. 이때 이미지가 없거나 플랫폼이 임의로 뽑은 썸네일이 보이면 글의 신뢰도가 떨어집니다.

그래서 블로그 글마다 1200x630 이미지를 동적으로 만들기로 했습니다.

이미지에는 최소한 아래 정보가 들어갑니다.

• 글 제목
• 작성자명
• 발행일
• 위글플러스 블로그 브랜드

Next.js App Router에서는 opengraph-image.tsx 파일을 route segment에 두면 Open Graph와 Twitter 이미지 메타데이터를 자동으로 연결할 수 있습니다. 공식 문서도 opengraph-image와 twitter-image 파일 convention이 route segment의 Open Graph, Twitter 이미지를 설정하는 방법이라고 안내합니다.

출처:

• Next.js opengraph-image 파일 convention
• Next.js metadata files 문서

우리 입장에서는 이 방식이 좋았습니다.

첫째, 글마다 이미지를 수동으로 만들 필요가 없습니다.

둘째, 제목이 바뀌면 이미지도 같은 데이터에서 다시 생성됩니다.

셋째, generateMetadata와 별도 이미지 파일이 같은 route 안에서 관리되기 때문에 글 URL과 이미지 URL의 관계가 명확합니다.

검색 관점에서는 OG 이미지가 직접 랭킹을 올린다고 말할 수 없습니다. 하지만 공유 결과에서 클릭률을 높일 수 있는 표면은 분명히 만듭니다. 작은 블로그에서는 이 차이가 큽니다. 하루 15~25명이 들어오는 블로그라면, 공유 링크에서 몇 명이 더 들어오는 것만으로도 체감이 생깁니다.

GEO 관점: AI 검색이 출처를 고르기 쉽게 만듭니다#

GEO는 Generative Engine Optimization으로 자주 불립니다. Google AI Overviews, AI Mode, ChatGPT search, Perplexity 같은 생성형 검색 환경에서 콘텐츠가 답변의 근거 링크나 참고 출처로 선택되도록 만드는 관점입니다.

여기서 가장 피해야 할 말은 "이 태그를 넣으면 AI 답변에 나온다"입니다. 그런 보장은 없습니다.

우리가 할 수 있는 일은 더 현실적입니다.

• 크롤러가 접근할 수 있게 합니다.
• 본문을 명확한 문단과 제목으로 씁니다.
• 제목, 요약, 날짜, 작성자, URL, 이미지 정보를 구조화합니다.
• RSS와 sitemap처럼 최신 글을 발견할 수 있는 경로를 제공합니다.
• canonical URL을 명확히 둡니다.

GEO 관점에서 RSS 피드를 추가한 이유도 여기에 있습니다.

RSS는 오래된 기술처럼 보이지만, 작은 팀 블로그에는 여전히 실용적입니다. RSS 리더 사용자를 위한 구독 경로이면서, 외부 피드 수집기와 크롤러가 최신 글 목록을 안정적으로 찾을 수 있는 구조화된 입구이기 때문입니다.

우리 RSS 명세는 단순합니다.

<channel>
  <title>WegglePlus 블로그</title>
  <link>https://weggle-plus.co.kr/blog</link>
  <description>WegglePlus 팀 블로그 — AI, 스타트업, 제품 개발 이야기</description>
  <language>ko</language>
  <lastBuildDate>...</lastBuildDate>
  <atom:link href="https://weggle-plus.co.kr/rss.xml" rel="self" type="application/rss+xml" />
</channel>

각 글은 title, link, guid, description, pubDate, author를 포함합니다.

이 구조는 화려하지 않습니다. 하지만 GEO 관점에서는 꽤 중요합니다. 생성형 검색이 어떤 경로로 웹 콘텐츠를 발견하든, 우리는 최소한 최신 콘텐츠 목록과 원본 URL을 일관된 형식으로 제공해야 합니다.

RSS를 만들면서 robots.txt에도 https://weggle-plus.co.kr/rss.xml을 추가하는 쪽으로 설계했습니다. sitemap과 RSS는 역할이 다릅니다. sitemap은 검색엔진에게 색인 대상 URL을 알려주는 쪽에 가깝고, RSS는 독자와 수집기에게 최신 콘텐츠 흐름을 제공하는 쪽에 가깝습니다. 둘 다 작은 블로그의 발견 가능성을 넓히는 장치입니다.

AEO 관점: 질문에 바로 답할 수 있는 페이지 구조를 만듭니다#

AEO는 Answer Engine Optimization으로 불립니다. 사용자가 검색창이나 AI 도구에 질문했을 때, 우리 글이 답변의 근거가 되기 쉬운 구조를 만드는 일입니다.

여기서 핵심은 메타태그보다 본문 구조입니다.

예를 들어 이 글이 답해야 하는 질문은 명확합니다.

• JSON-LD 다음에 블로그 SEO에서 무엇을 해야 하나요?
• OG 이미지는 SEO에 어떤 의미가 있나요?
• RSS는 GEO 관점에서 왜 필요한가요?
• AEO를 위해 블로그 글 구조를 어떻게 잡아야 하나요?

그래서 글의 제목과 소제목도 질문에 답하는 방식으로 잡아야 합니다. SEO 관점, GEO 관점, AEO 관점처럼 독자가 찾는 개념을 직접 드러내면 사람도 읽기 쉽고, 답변 엔진도 문단의 역할을 파악하기 쉽습니다.

블로그 UI에서도 같은 고민이 이어졌습니다.

긴 글을 쓰면 사용자는 원하는 구간으로 바로 이동하고 싶어합니다. 그래서 자동 목차를 추가했습니다. 본문에서 h2, h3 heading을 수집하고, heading이 3개 이상이면 상단에 목차를 보여줍니다. 목차 클릭은 toc_click 이벤트로 기록합니다.

이 기능은 단순한 편의 기능이 아닙니다.

사용자가 "OG 이미지 부분만 보고 싶다", "RSS 구현 부분만 보고 싶다"처럼 명확한 의도를 갖고 들어왔을 때, 바로 해당 구간으로 이동할 수 있게 만듭니다. AEO는 검색 결과에만 있는 문제가 아니라, 페이지 안에서 답을 얼마나 빨리 찾게 하느냐의 문제이기도 합니다.

BreadcrumbList는 사람보다 기계에게 더 중요한 길 안내입니다#

블로그 상세 페이지는 사람이 보기에는 그냥 글입니다. 하지만 검색엔진 입장에서는 사이트 안에서 이 글이 어디에 있는지 알아야 합니다.

그래서 BreadcrumbList를 추가합니다.

const breadcrumbJsonLd = {
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  itemListElement: [
    {
      "@type": "ListItem",
      position: 1,
      name: "홈",
      item: "https://weggle-plus.co.kr",
    },
    {
      "@type": "ListItem",
      position: 2,
      name: "블로그",
      item: "https://weggle-plus.co.kr/blog",
    },
    {
      "@type": "ListItem",
      position: 3,
      name: post.title,
      item: postUrl,
    },
  ],
};

BreadcrumbList는 SEO 관점에서는 검색 결과의 경로 표현에 도움을 줄 수 있습니다. GEO와 AEO 관점에서는 페이지의 위치와 관계를 설명합니다.

작은 블로그일수록 이 관계가 중요합니다. 글 수가 20개 안팎인 블로그라도 글의 성격은 다릅니다. 어떤 글은 서비스 소개이고, 어떤 글은 구현기이며, 어떤 글은 운영 회고입니다. 검색 시스템이 이 글들을 모두 "그냥 블로그 글"로만 보면 맥락이 약해집니다.

그래서 다음 단계로 주제별 모아보기도 설계했습니다.

• ai-automation: AI 협업·자동화
• service-build: 서비스 설계·구현
• launch-retrospective: 서비스 소개·회고

대규모 태그 시스템을 바로 만들지는 않았습니다. 현재 공개 글 수가 많지 않기 때문입니다. 대신 운영자 큐레이션 기반으로 주제 페이지를 먼저 두는 방향을 택했습니다. 글이 10개 정도인 블로그에서 완전한 taxonomy를 만드는 것은 이른 최적화일 수 있습니다. 하지만 주제별 랜딩 페이지 2~3개는 검색 유입면을 넓히는 데 도움이 됩니다.

동적 키워드는 자동 태깅이 아니라 보조 신호로 봤습니다#

포스트별 키워드도 고민했습니다.

기존에는 블로그 layout에 공통 키워드만 있었습니다. 이 방식은 블로그 전체의 성격은 설명하지만, 개별 글의 차이를 잘 드러내지 못합니다.

그래서 제목과 요약에서 의미 있는 단어를 뽑아 포스트별 metadata keywords를 만드는 방식을 검토했습니다.

const generateKeywords = (title: string, summary: string): string[] => {
  const baseKeywords = ["위글플러스", "블로그"];
  const words = `${title} ${summary}`
    .replace(/[^\w\sㄱ-ㅎㅏ-ㅣ가-힣]/g, "")
    .split(/\s+/)
    .filter((word) => word.length >= 2);

  const uniqueWords = [...new Set(words)].slice(0, 8);
  return [...baseKeywords, ...uniqueWords];
};

이 방식은 완벽한 태그 시스템이 아닙니다. 형태소 분석도 아니고, 검색 의도 분석도 아닙니다.

하지만 작은 팀이 당장 운영할 수 있는 수준에서는 충분히 현실적입니다. 제목과 요약은 이미 사람이 검수한 텍스트입니다. 그 안에서 중복을 제거하고 적당한 개수만 metadata에 넣으면, 적어도 모든 글이 같은 키워드만 들고 있는 상태는 벗어날 수 있습니다.

다만 이 작업을 과신하면 안 됩니다. 검색 유입은 키워드 메타태그 하나로 만들어지지 않습니다. 실제로 더 중요한 것은 검색 의도에 맞는 제목, 충분한 본문, 내부 링크, 외부에서 참조될 만한 품질입니다.

그래서 우리는 동적 키워드를 "검색 노출을 만드는 핵심 장치"가 아니라 "페이지 차이를 설명하는 보조 신호"로 봤습니다.

canonical URL은 중복 해석을 막는 안전장치입니다#

블로그 글 URL에는 id와 slug가 함께 들어갑니다.

/blog/posts/{id}/{slug}

현재 slug는 제목에서 생성됩니다. 한국어 제목은 URL 인코딩으로 길어질 수 있습니다. 영문 slug를 따로 관리하면 더 깔끔하지만, DB 변경이 필요하기 때문에 별도 과제로 미뤘습니다.

대신 지금 중요한 것은 canonical URL입니다.

같은 글이 여러 경로로 접근될 가능성이 있더라도 검색엔진에게 "대표 URL은 이것"이라고 알려줘야 합니다. 특히 제목 기반 slug는 제목이 바뀌면 달라질 수 있습니다. 이런 구조에서는 canonical을 명확히 두는 편이 안전합니다.

SEO 관점에서는 중복 콘텐츠 해석을 줄입니다.

GEO 관점에서는 AI 검색이나 외부 수집기가 원본 링크를 잘못 잡을 가능성을 줄입니다.

AEO 관점에서는 답변 근거로 연결할 때 대표 URL이 안정적으로 유지됩니다.

화려한 기능은 아니지만, 작은 블로그의 검색 인프라에서는 이런 기본기가 더 오래 갑니다.

우리가 정리한 실행 순서#

이번 개선은 한 번에 모든 것을 바꾸는 작업이 아니었습니다. 우선순위를 낮은 비용과 높은 명확성 기준으로 잡았습니다.

첫 번째는 BlogPosting JSON-LD에 image를 추가하는 일이었습니다. 이미 동적 OG 이미지가 있으므로 같은 URL을 구조화 데이터에 연결하면 됩니다.

두 번째는 BreadcrumbList를 추가하는 일이었습니다. 블로그 인덱스와 상세 글 모두 홈, 블로그, 글의 관계를 명확히 설명할 수 있습니다.

세 번째는 블로그 인덱스 페이지에 Blog JSON-LD를 추가하는 일이었습니다. 상세 글만 신경 쓰면 /blog 목록 페이지는 그냥 일반 웹페이지로 남습니다. 블로그 홈 자체도 "위글플러스가 운영하는 한국어 팀 블로그"라는 신호를 가져야 합니다.

네 번째는 블로그 인덱스 OG 이미지와 Twitter Card를 보강하는 일이었습니다. 상세 글뿐 아니라 블로그 홈이 공유될 때도 대표 이미지가 필요합니다.

다섯 번째는 RSS 피드와 robots.txt 연결이었습니다. 최신 글이 생성될 때 외부 도구와 구독자가 안정적으로 발견할 수 있는 경로를 둡니다.

여섯 번째는 포스트별 동적 키워드였습니다. 이 작업은 효과를 과장하지 않고, 개별 글의 주제를 보조적으로 설명하는 수준으로 제한했습니다.

정리하면 아래와 같습니다.

메타데이터는 콘텐츠를 대신하지 못합니다#

이번 작업을 하면서 가장 많이 경계한 것은 메타데이터 만능론이었습니다.

JSON-LD, OG 이미지, RSS, BreadcrumbList, canonical은 모두 필요합니다. 하지만 이것들은 좋은 글을 대신하지 못합니다.

검색 유입을 늘리는 가장 중요한 재료는 여전히 콘텐츠입니다.

• 실제로 겪은 문제를 다루는가
• 숫자와 사례가 있는가
• 제목이 검색 의도와 맞는가
• 본문이 질문에 직접 답하는가
• 관련 글과 서비스로 이어지는 내부 링크가 있는가
• 외부에서 인용할 만한 구체성이 있는가

우리 블로그에서 잘 읽힌 글도 대부분 이 조건을 갖고 있었습니다. Typefy를 토스 앱 안으로 옮기며 배운 것들, Versus 토스 미니앱에서 만든 미투표 상태와 fetch·인증의 디테일, JSON-LD는 SEO, GEO, AEO에 얼마나 의미가 있을까 같은 글은 모두 실제 구현 경험과 구체적인 판단을 담고 있습니다.

그래서 이번 개선의 목적은 글을 포장하는 것이 아닙니다.

이미 쓴 글이 검색엔진, AI 검색, 독자에게 덜 오해되도록 만드는 것입니다.

작은 팀 블로그에서는 이 정도가 현실적인 출발점이라고 봅니다. 거대한 SEO 시스템을 만들기 전에, 글마다 제목, 요약, 작성자, 날짜, 이미지, URL, 경로, 피드가 일관되게 제공되는지부터 확인하는 것입니다.

다음에 볼 것은 성과 측정입니다#

이제 남은 일은 측정입니다.

우리는 아래 지표를 보고 있습니다.

• /blog와 /blog/posts/*의 Organic Search sessions
• Organic Social 유입과 공유 링크 클릭
• 검색 결과 CTR
• RSS 요청 수와 외부 피드 유입
• 글 상세의 스크롤 깊이
• 자동 목차 toc_click
• 관련 글과 서비스 전환 CTA 클릭

작은 블로그에서 절대 숫자는 작을 수 있습니다. 그래서 비율만 보면 흔들립니다. 한 명이 더 들어오면 전환율이 크게 튈 수 있습니다.

대신 방향을 봐야 합니다.

검색에서 들어온 사람이 글을 읽는지, 공유 링크의 미리보기가 정상적으로 뜨는지, RSS가 안정적으로 응답하는지, 글 상세에서 사용자가 원하는 섹션으로 이동하는지 같은 작은 신호를 계속 봐야 합니다.

SEO, GEO, AEO는 서로 완전히 다른 일이 아닙니다.

검색엔진이 읽기 쉬운 페이지는 AI 검색도 이해하기 쉽습니다. AI 검색이 인용하기 쉬운 페이지는 사람도 구조를 파악하기 쉽습니다. 사람이 답을 빨리 찾을 수 있는 글은 검색 결과에서도 좋은 클릭 이유를 갖습니다.

결국 작은 팀 블로그가 할 일은 단순합니다.

좋은 글을 쓰고, 그 글이 웹에서 잘 발견되도록 기본 구조를 정리하고, 실제 데이터로 다음 개선을 정하는 것입니다.

위글플러스 서비스#

Typefy - 나를 발견하다: MBTI·여행 DNA·직업 성향 등 다양한 무료 심리 테스트로 나 자신을 탐색해 보세요.

Versus - 오늘의 선택, 당신의 생각: 매일 새로운 A vs B 밸런스 게임에 참여하고, 다른 사람들의 선택과 비교해보세요.

Nomad's - 세상을 탐색하다: 전 세계 디지털 노마드들이 추천하는 지역 리뷰와 실제 체류 경험을 확인해 보세요.

Nomad'With - 일상을 나누다: 디지털 노마드들의 여행, 원격 근무, 한달살기 이야기를 피드에서 만나보세요.

JobSkill - 역량을 키우다: 현직자가 직접 진행하는 직무 스킬 세미나로 실전 커리어 경쟁력을 높여보세요.

ThingsInThing - 미디어 속 숨겨진 것들을 발견하세요: 책, TV 프로그램 속에 등장하는 숨겨진 것들을 발견하고 탐색하세요.

staglit - 무대 위의 모든 순간: 국내외 공연과 페스티벌 정보를 한 곳에서 확인하세요.

별짓 - 오늘의 운명을 읽다: 별자리 일간 운세로 매일의 흐름을 확인하세요.

셀링페이퍼 - 독후감으로 수익 만들기: 책을 읽고 독후감을 작성하세요. 다른 사람이 내 독후감을 통해 책을 구매하면 수수료를 받을 수 있습니다.

문장 만들기 - 단어를 문장으로 엮다: 랜덤 단어를 받아 한국어, 영어, 일본어 문장을 만들고 커뮤니티 반응으로 톤을 검증하세요.

롤모아 - 경기를 모아보다: 리그 오브 레전드 주요 대회 경기 일정과 결과를 확인하고 팀 평점과 의견을 남겨보세요.

puff - 가까운 흡연구역을 찾다: 최근 확인일, 제보 상태, OpenStreetMap 길찾기를 함께 보여주는 흡연구역 지도입니다.

비슷한 고민을 하고 계시거나 같이 실험해보고 싶은 분은 커피챗 하고 싶습니다 ☕️ 📩 ksy90101@gmail.com