pxd story

구글의 AI 검색 최적화 가이드, 실무자는 이렇게 읽었습니다.

Seulbi Lee — Sat, 18 Jul 2026 18:02:21 +0900

"GEO 방법론은 다 미신이다", "결국 SEO만 하면 된다" — 구글의 가이드 발표 이후 이런 해석들이 퍼지고 있는데요. SEO/GEO 분석 서비스를 만들면서 느낀 점들, 그리고 직접 측정해 본 데이터를 바탕으로 이 가이드를 어떻게 읽으면 좋을지 정리해 보았습니다.

들어가며

올해 구글이 「Optimizing your website for generative AI features on Google Search」라는 AI 검색 최적화 가이드를 발표했습니다. GEO(생성형 엔진 최적화) 분야에서 처음 나온 공식 지침이다 보니 반응이 뜨거웠는데요. 그런데 이 가이드가 여러 매체와 커뮤니티를 거치면서 "그동안의 GEO 방법론은 전부 미신이었다", "결국 SEO만 잘하면 된다더라" 같은 요약으로 퍼지는 걸 보게 되었습니다.

큰 틀에서는 맞는 말이지만, SEO/GEO 분석 서비스를 만들면서 매일 이 주제를 들여다보고 있는 입장에서는 이렇게 요약되면 곤란하지 않나 싶은 지점들이 있었습니다. 그래서 이번 글에서는 구글 가이드의 원문을 다시 짚어보고, 궁금했던 부분은 직접 측정해 보면서, 실무자 입장에서 어디까지 받아들이고 어디서부터는 조심해서 읽어야 하는지 생각을 정리해 보려고 합니다.

SEO가 기반이라는 건 맞습니다

먼저 가이드의 핵심 메시지부터 보겠습니다. 구글은 GEO를 잘하려면 결국 SEO부터 탄탄해야 한다고 말하는데, 여기에는 구조적인 이유가 있습니다. 구글의 AI 오버뷰와 AI 모드는 RAG(검색 증강 생성)와 쿼리 팬아웃이라는 방식으로 동작하는데, 둘 다 기존 검색 색인에서 콘텐츠를 가져와 답변을 만듭니다. 일반 검색에서 발견되지 못하는 페이지는 AI 답변의 재료조차 될 수 없다는 뜻이죠.

이건 지오닉(GEONIQ)을 만들면서 잡은 방향이기도 합니다. 여러 사이트를 분석하다 보면 크롤링이 막혀 있거나 렌더링이 깨져서 색인 자체가 제대로 안 되는 페이지를 생각보다 자주 만나는데, 이런 상태에서는 어떤 GEO 전략도 의미가 없습니다. "SEO가 잘되면 AI 인용도 따라온다"는 방향에는 저도 전적으로 동의합니다.

다만, 여기서부터가 이 가이드를 읽을 때 조심해야 하는 부분입니다.

'미신(꼼수)' 목록에는 결이 다른 것들이 섞여 있습니다

가이드에서 구글은 효과 없는 GEO 방법론들을 짚었습니다. llms.txt 파일, 콘텐츠 청킹, AI 전용 리라이팅, 진정성 없는 멘션 뿌리기, 그리고 스키마 마크업까지가 흔히 '미신 목록'으로 요약되어 돌아다니는데요. 이 목록, 자세히 보면 성격이 전혀 다른 것들이 한데 묶여 있습니다.

llms.txt

구글은 llms.txt를 "참조하지 않는다"고 명확히 선을 그었습니다. 다만 이것도 정확히는 '구글 기준'의 이야기입니다. 다른 주요 AI 플랫폼들은 구글처럼 공식적으로 부인한 적도 없지만, 반대로 답변을 만들 때 남의 사이트 llms.txt를 참조한다고 공식 확인한 적도 없습니다. Anthropic이나 Perplexity처럼 자사 문서 사이트에 llms.txt를 게시하는 곳이 있어서 이게 종종 "공식 지원"으로 와전되는데, 자기 문서를 그 형식으로 내놓는 것과 남의 사이트 파일을 읽어 답변에 반영하는 것은 다른 이야기입니다. 그러니 llms.txt의 정확한 현재 상태는 "구글에서는 무의미 확정, 그 외에서는 부인도 확인도 없는 효과 미검증"입니다.

스키마 마크업

반면 스키마 마크업(구조화된 데이터)은 또 이야기가 다릅니다. 구글이 원문에서 실제로 쓴 문장은 이렇습니다.

"Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add. However, it's a good idea to continue using it as part of your overall SEO strategy." (구조화된 데이터는 생성형 AI 검색에 필수는 아니며, 추가해야 할 특별한 schema.org 마크업도 없다. 다만 전체 SEO 전략의 일부로서 계속 사용하는 것이 좋다.)

"AI 인용을 위한 별도의 부스트 효과는 없다"와 "계속 쓰는 게 좋다"가 같은 문단에 있는 겁니다. 스키마 마크업은 schema.org 기반의 웹 표준이고, 구글이 지금도 공식 문서에서 권장하며 페이지의 저자, 조직, 제품 같은 엔티티를 이해하는 데 실제로 활용하는 정당한 기술입니다. 프론트엔드 작업을 하면서 마크업을 다뤄온 입장에서 보면, 스키마 마크업은 시멘틱 마크업의 연장선에 있는 '기계가 읽을 수 있는 문서 만들기'에 가깝습니다.

AI 전용 리라이팅

'AI 전용 리라이팅'에도 비슷한 결의 문제가 있습니다. 구글이 기각한 건 "생성형 AI 검색만을 위해 콘텐츠를 특별한 방식으로 다시 쓰는 것"입니다. 그런데 현장에서 'AI 리라이팅'이라는 이름으로 행해지는 작업을 뜯어보면 성격이 다른 두 가지가 섞여 있습니다. 하나는 사람은 안 읽는다는 전제로 AI 크롤러를 겨냥한 본문을 따로 만들어 붙이는 일이고, 다른 하나는 같은 내용을 사람도 AI도 파악하기 쉽도록 요약과 소제목, FAQ 구조로 다듬는 일입니다. 구글이 미신이라고 한 건 앞쪽입니다. 뒤쪽은 오히려 구글 가이드가 권장하는 "사람에게 유용한 콘텐츠"와 같은 방향이고, 저희가 사이트를 분석하며 개선을 제안할 때 하는 일도 대부분 뒤쪽에 속합니다. 그런데 "리라이팅은 미신"이라는 요약 한 줄에서는 이 두 작업이 함께 뭉개집니다.

"AI용으로 뭘 더 할 필요는 없다"와 "쓸모없는 편법이다"는 전혀 다른 말인데, 요약을 거치면서 이 둘의 경계가 사라지는 경우를 종종 봅니다. 이 구분이 왜 중요하냐면, 실무에서 벌어질 일이 그려지기 때문입니다. "구글이 스키마 마크업 필요 없다고 했다던데요?"라는 말과 함께, 멀쩡히 관리되고 있던 구조화 데이터가 정리 대상에 오르는 상황이요. SEO 관점에서 계속 유지해야 하는 자산이 요약 한 줄 때문에 걷어내지는 건 개발자 입장에서 꽤 안타까운 일입니다. 가이드를 읽을 때는 항목별로 구글이 실제로 어떤 표현을 썼는지, 원문의 뉘앙스를 확인해 볼 필요가 있습니다.

직접 확인해 본 결과, 구조가 좋다고 인용되는 건 아니었습니다

가이드 발표 이후 또 하나 자주 보게 된 것이 "이 사이트는 Q&A 구조도 잘 갖췄고 저자 정보도 명확하니 GEO가 잘 된 사이트다"라는 식의 평가입니다. 그런 구조적 요소들이 좋은 실천인 건 맞습니다. 그런데 구조가 좋다는 평가와 실제로 인용된다는 결과는 같은 말일까요? 마침 저희 팀은 올 하반기 출시를 목표로 지오닉에 "GEO 성과지표(KPI)" 기능(우리 서비스와 관련된 질문군을 정의해 두고 AI 답변에서의 인용 여부를 꾸준히 추적하는 기능)을 준비하고 있어서, 이 측정 파이프라인으로 직접 확인해 봤습니다.

최근 'GEO 잘 된 사례'로 소개된 국내 대기업 콘텐츠 플랫폼 5곳(금융 3, 유통·패션 1, 통신 1)을 골라, 각 사이트가 실제로 발행한 콘텐츠 주제에서 질문 30개를 뽑았습니다. "이 사이트가 직접 쓴 주제를 물으면 이 사이트가 인용되는가"를 측정하기 위해서입니다. 이 질문들을 웹검색을 켠 3개 AI(ChatGPT·Gemini·Perplexity)에 던지고, 답변의 인용 출처에 해당 플랫폼이 등장하는지 확인했습니다.

결과는 사이트마다 극단적으로 갈렸습니다. 같은 금융권 콘텐츠 플랫폼 두 곳이 좋은 대비인데요. 한 곳은 Gemini 기준 6개 질문 중 5개에서 인용된 반면, 다른 한 곳은 단 한 번도 인용되지 않았습니다. 둘 다 요약·소제목·Q&A 구조를 잘 갖춘, '잘 된 사례' 목록에 나란히 오른 곳들입니다. 인용되지 못한 자리는 네이버 블로그와 유튜브가 차지했습니다. 실제로 이번 측정 전체에서 가장 많이 인용된 출처는 특정 브랜드 사이트가 아니라 blog.naver.com과 youtube.com이었습니다.

왜 이런 차이가 생길까 생각해 보면, 인용이라는 게 '사이트 단위의 자격'이 아니라 '질문 단위의 경쟁'이기 때문입니다. AI는 사용자의 질문마다 관련 문서를 새로 검색하고, 그중 답변에 가장 잘 들어맞는 출처를 고릅니다. 아무리 콘텐츠 구조가 좋아도 그 주제에 더 직접적으로 답하는 경쟁 문서가 있다면 인용은 그쪽으로 갑니다. 체크리스트를 충족했다는 건 경쟁에 참가할 자격을 갖췄다는 것이지, 경쟁에서 이기고 있다는 뜻은 아닌 거죠.

한편으로는 "사람들이 AI에 던지는 질문이 매번 다른데 인용 측정이 의미가 있나?"라는 회의적인 시선도 있습니다. 실제로 질문은 점점 길고 다양해지고 있습니다. 구글이 I/O 2026에서 밝힌 바로는 AI 모드의 평균 쿼리 길이가 기존 검색의 3배 수준입니다. 키워드 몇 개가 아니라 맥락이 담긴 문장으로 묻는다는 뜻이죠. 그런데 저는 그래서 측정이 무의미해진다가 아니라, 오히려 반대라고 생각합니다. 질문이 매번 다르기 때문에, 관련 질문군을 정의해 두고 그 안에서 인용 여부를 꾸준히 추적하는 방식의 측정이 필요한 거고요. 측정을 포기하는 순간 남는 건 '좋아 보이는 구조'에 대한 인상 평가뿐인데, 위 결과처럼 인상 평가와 실측은 다를 수 있습니다.

구글의 방향이 곧 모든 AI의 방향은 아닙니다

마지막으로 짚고 싶은 건 이 가이드의 적용 범위입니다. 가이드 발표 이후 "결국 SEO만 하면 되는 거네, GEO는 허상이네"라는 반응도 보이는데, 구글의 문서는 어디까지나 구글 검색의 AI 기능에 대한 가이드입니다. 구글은 기존 검색 색인 위에서 AI가 동작하는 구조라 "SEO가 곧 GEO"라는 등식이 비교적 잘 성립하는 플랫폼이고, 구글 입장에서는 저렇게 쓰는 게 당연합니다.

문제는 이 등식이 다른 플랫폼으로 그대로 이식되지 않는다는 겁니다. 위에서 소개한 측정에서 플랫폼별 결과를 나눠 보면 격차가 선명합니다. 동일한 30개 질문에서 해당 플랫폼이 인용된 질문의 비율이 **Gemini 40%, Perplexity 30%, ChatGPT 10%**로 벌어졌습니다. 구글 검색 색인을 그대로 쓰는 Gemini가 SEO 잘된 사이트들을 가장 잘 인용하고 — 구글의 등식이 구글 생태계 안에서는 실제로 작동한다는 뜻입니다 — 검색 색인이 다른 ChatGPT에서는 같은 사이트들이 거의 인용되지 않았습니다.

측정하면서 알게 된 사실이 하나 더 있습니다. ChatGPT는 "인터넷이 느릴 때 어떻게 하나요" 같은 생활 밀착형 질문 6개에서 웹검색을 한 번도 수행하지 않았습니다. 검색 없이 자체 지식으로만 답했고, 당연히 인용도 0건이었습니다. AI가 검색 자체를 하지 않는 질문 유형에서는 어떤 콘텐츠도 인용될 기회가 없는 건데, 이런 플랫폼별 동작 차이는 구글 가이드 어디에도 나오지 않습니다. 나올 이유가 없죠. 구글의 가이드니까요.

그래서 저는 이렇게 정리하고 싶습니다. 구글이 "SEO에 충실하라"고 한 건 구글 생태계 안에서의 답이고, 그것이 GEO라는 개념 전체를 무효화하는 근거가 될 수는 없다. 오히려 플랫폼마다 인용 기준과 동작이 다르다는 사실이야말로, 플랫폼별로 관찰하고 대응하는 GEO라는 작업이 여전히 필요한 이유라고요.

마치며

정리하면 이렇습니다. 구글의 가이드는 검증되지 않은 방법론이 난무하던 시장에 기준을 제시했다는 점에서 반가운 문서이고, SEO가 기반이라는 핵심 메시지에도 동의합니다. 다만 '미신 목록'에는 결이 다른 항목들이 섞여 있으니 원문의 뉘앙스를 항목별로 확인해야 하고, 구조가 좋다는 것과 실제로 인용된다는 것은 별개이니 실측으로 검증해야 하며, 구글의 답이 AI 검색 환경 전체의 답은 아니라는 점을 함께 기억하면 좋겠습니다.

GEO는 아직 정보의 밀도보다 확산 속도가 빠른 분야입니다. 이런 시기일수록 누군가의 요약을 그대로 받아들이기보다 공식 문서를 직접 읽어보고, "잘 됐다더라"는 주장은 데이터로 확인해 보는 습관이 중요한 것 같습니다. 저도 인상이 아니라 실측으로 이야기하는 글을 계속 써보려고 합니다.

감사합니다.

측정 방법: 2026년 7월, 지오닉(GEONIQ)의 하반기 출시 예정 GEO 성과지표(KPI) 기능의 측정 파이프라인으로 수행. 'GEO 잘 된 사례'로 소개된 국내 콘텐츠 플랫폼 5곳을 대상으로 각 사이트가 실제 발행한 콘텐츠 주제에서 사이트당 6개(총 30개) 질문을 도출. ChatGPT(gpt-5.3, 웹검색 도구 ON)·Gemini(3.5 Flash, 검색 그라운딩 ON)·Perplexity(sonar)의 API를 질문당 1회 호출해 답변의 인용 출처 도메인을 판정. 단발 측정이므로 AI 응답의 비결정성에 따른 편차가 있을 수 있습니다.

참고 문헌

package.json 어디까지 알고 계신가요? (peerDependencies, files, engines, version)

seonju.lee — Thu, 9 Jul 2026 07:50:21 +0900

들어가며

프로젝트를 시작하면 공통 UI를 설계하더라도, 보통은 해당 프로젝트 내에서만 제한적으로 사용하는 경우가 많았습니다. 이번에는 저는 공통 컴포넌트를 별도 패키지로 만들어 배포하고, 다른 서비스에서 설치해 사용하는 구조로 진행하게 되었습니다.

그 과정에서 package.json을 단순히 “패키지 목록과 실행 스크립트를 관리하는 파일”로만 알고 있다가 실제로 어떤 역할을 하는지 살펴보게 되어 소개하고자 합니다.

1. PeerDependencies

dependencies와 devDependencies는 프로젝트 환경 세팅 시 설치해야 하는 항목들이라 익숙한 개념입니다. 하지만 peerDependencies는 npm init 시 기본적으로 생성되지 않기 때문에 상대적으로 생소할 수 있어, 함께 비교해 보았습니다.

dependencies
패키지가 실제 실행될 때 필요한 의존성으로 런타임에서 필요한 라이브러리는 dependencies에 포함해야 합니다.
(예: react, react-dom, styled-components, lucide-react)
devDependencies
개발, 빌드, 테스트 과정에서만 필요한 의존성입니다.
(예: TypeScript, ESLint, Sass, Storybook)
peerDependencies
peer는 ‘동료’, ‘동등한 위치’라는 의미가 있으며, 이 패키지를 사용하는 쪽에서 직접 설치해야 하는 의존성을 의미합니다. 공통 컴포넌트를 패키지로 배포할 경우 react, react-dom, styled-components와 같은 라이브러리는 peerDependencies로 정의합니다. 특히 React는 중복으로 설치될 경우 Hooks 오류나 Context 분리 문제가 발생할 수 있기 때문에 peerDependencies로 관리하는 것이 중요합니다.

1-1. 공통 컴포넌트 설계 시 의존성 구성 방법

공통 컴포넌트를 설계할 때는 devDependencies와 peerDependencies에 동시에 선언하는 방식을 추천합니다.
react를 dependencies에 넣었다가 배포 시 제외하는 방법도 있지만, 경험상 “나중에 제외하는 방식”은 실수할 가능성이 높아서 개발 단계에서는 필요한 의존성을 devDependencies에 포함하고 실제 사용 환경에서는 peerDependencies를 통해
버전 호환성을 사용자에게 위임하는 구조가 더 안정적이라고 합니다.

// common-components package.json
{
  "peerDependencies": {
    "react": "^18.0.0 || ^19.0.0",
    "react-dom": "^18.0.0 || ^19.0.0",
    "styled-components": "^6.0.0"
  },

  "devDependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "styled-components": "^6.1.0",
    "@types/react": "^18.2.0",
    "@types/react-dom": "^18.2.0",
    "typescript": "^5.0.0"
  }
}

또한 external 설정을 하지 않으면 peerDependencies로 선언했더라도 번들 결과물에 포함될 수 있기 때문에 반드시 설정해야 합니다.

export default defineConfig({
  build: {
    rollupOptions: {
      external: ['react', 'react-dom', 'styled-components']
    }
  }
});

2. Files

files 필드를 사용하면 배포에 포함될 파일을 명시적으로 제한하는 요소인데요,
불필요한 파일이 배포되는 것을 방지하기 위해 번들 결과물만 포함하는 것이 좋습니다.

"files": [
  "dist",
  "README.md"
]

3. Engines, packageManager

패키지를 사용할 수 있는 Node.js 버전과 패키지 매니저를 명시할 수 있습니다.
현재 프로젝트에서는 Node 버전이 12~20까지 다양하고, npm, yarn, pnpm 등 여러 패키지 매니저가 혼용되고 있었습니다.
이처럼 협업 환경에서 Node 버전 차이 때문에 빌드 오류가 발생하는 경우가 많아서, engines 필드를 통해 최소 버전을 강제하는 것이 안정성을 높이는 데 도움이 되었습니다.
(실제로 lockfile 충돌 문제로 pnpm으로 통일하는 작업을 진행하기도 했습니다.)

{
  "engines": {
    "node": ">=18"
  },
  "packageManager": "pnpm@9.0.0"
}

4. Version

단일 프로젝트에서는 package.json의 version을 크게 중요하게 생각하지 않았는데 공통 컴포넌트를 배포하는 구조에서는 version 관리가 매우 중요했습니다.
사용하는 프로젝트 환경에 따라 적절한 버전을 선택해 설치해야 하므로 배포 전 version 관리와 검증은 필수입니다. Semantic Versioning 규칙을 따르며, 협업과 배포 안정성을 위한 중요한 기준이 됩니다.

1.0.0
│ │ │
│ │ └─ patch: 버그 수정
│ └─── minor: 하위 호환 기능 추가
└───── major: 하위 호환이 깨지는 변경

마치며

package.json을 단순히 “패키지 목록을 관리하는 파일” 정도로만 생각했는데 이번 과정을 통해 역할을 다시 알게 되었습니다. 혹시 공통 컴포넌트나 디자인 시스템을 구축하고 있다면, package.json을 한 번쯤 들여다보는 것을 추천해 드립니다.

읽어주셔서 감사합니다 :)

이 글은 https://tech.pxd.co.kr/ 에서도 보실 수 있습니다.

검색에는 보이는데, AI 답변에는 없다면? (GEONIQ 온보딩 미션 이벤트)

GEONIQ — Wed, 1 Jul 2026 11:14:40 +0900

사용자는 이제 검색보다 AI에게 먼저 묻습니다.

“OO 추천해줘.”
“믿을 만한 곳 알려줘.”
“어떤 서비스를 고르면 좋을까?”

좋은 콘텐츠도 AI가 이해하기 어려운 구조라면 답변에 포함되기 어렵습니다.
GEONIQ에서 URL 하나로 내 콘텐츠의 SEO·GEO 상태를 진단해보세요.

두 가지 미션, 두 가지 혜택

참여 미션	대상	완료 조건	혜택
무료 진단 미션	신규 회원	회원가입 후 URL 진단 1회 완료	Starter 플랜 1개월 (16,800원 상당)
채널 공유 미션	신규 회원 · 기존 회원	공식 채널 팔로우 및 이벤트 게시물 좋아요, 리포스트 후 '공유 완료' 댓글 (댓글 계정으로 미션 완료 확인 되면 지오닉 계정을 받기 위해 DM 드립니다.)	Basic 플랜 1개월 (85,600원 상당)

신규 회원은 두 미션을 모두 완료하면 혜택을 함께 받을 수 있습니다.

보상 적용 기준

참여 유형	제공 혜택
신규 회원 · 무료 진단 미션 완료	Starter 플랜 1개월 (16,800원 상당)
신규 회원 · 두 미션 모두 완료	Basic 플랜 1개월 + Starter 플랜 1개월 상당의 진단 혜택 (85,600원 + 16,800원 상당)
기존 회원 · 채널 공유 미션 완료	Basic 플랜 1개월 (85,600원 상당)

※ 혜택은 참여 조건 확인 후 지급됩니다.
※ 두 미션을 모두 완료한 경우, Basic 플랜 1개월이 우선 적용되며 Starter 플랜 1개월 상당의 진단 혜택이 함께 제공됩니다.
※ 공유 미션은 지오닉 계정당 1회만 인정됩니다.

이벤트 기간

2026년 7월 1일 ~ 2026년 7월 31일

이벤트 진행 채널

Instagram · LinkedIn · Threads · X

앱 리뷰를 속성으로 쪼개 의사결정으로 연결하는 법

無異 — Tue, 30 Jun 2026 12:44:03 +0900

오버뷰 다음에 필요한 것

앱 리뷰를 볼 때 처음 필요한 것은 전체 지형입니다. 사람들이 어떤 이야기를 많이 하는지, 그 이야기가 긍정에 가까운지 부정에 가까운지를 먼저 알아야 하니까요. 어피니티버블은 이 첫 단계에 강합니다. 정성 텍스트를 한 장의 지도로 펼쳐서, 리뷰 더미 안의 큰 주제와 감정의 흐름을 빠르게 보여줍니다.

하지만 서비스 제공자 입장에서는 전체 지도를 보는 것만으로 다음 액션을 결정하기 어렵습니다. "이런 주제의 불만이 많구나", "이 영역은 만족도가 높구나"까지는 알 수 있지만, 무엇을 먼저 고쳐야 하는지, 어떤 기능을 더 밀어야 하는지, 경쟁사 대비 어디가 강점인지까지 바로 이어지지는 않습니다.

의사결정에는 한 단계가 더 필요합니다. 이번에서는 패션앱 3종(에이블리·무신사·지그재그) 리뷰를 샘플로, 오버뷰 이후의 분석을 어떻게 설계할 수 있는지 살펴봤습니다.

1. 도메인의 중요한 속성을 찾는다

의사결정을 하려면 먼저 이 도메인에서 사용자가 무엇을 기준으로 판단하는지 알아야 합니다. 패션앱 리뷰라면 가격, 혜택, 배송, 사용성, 고객지원, 상품 다양성 같은 속성이 나올 수 있습니다. 리뷰 문장 속에서 사용자가 반복해서 판단 기준으로 삼는 표현을 추출하고, 비슷한 기준을 묶어 도메인 코드북으로 만듭니다. 이제는 이런 작업을 LLM을 이용해 더 수월하게 할 수 있습니다.

도메인 속성 코드북은 완전히 MECE한 분류표라기보다, 의사결정을 돕기 위한 관점 체계에 가깝습니다. 리뷰 한 문장이 배송과 고객지원, 가격과 혜택처럼 여러 속성에 동시에 걸릴 수 있기 때문입니다. 대신 비슷한 속성은 병합하고, 너무 넓은 속성은 나누고, 각 속성의 정의를 고정해 이후 드릴다운과 교차분석에서 같은 기준으로 비교할 수 있게 만듭니다.

aspect-report는 이렇게 만든 속성 코드북을 기준으로, 각 속성이 얼마나 자주 언급되는지와 어떤 감정으로 말해지는지를 보여줍니다. 흔히 ABSA(Aspect-Based Sentiment Analysis), 즉 속성 기반 감성 분석이라고 부르는 방식입니다.

여기서 중요한 점은 많이 언급되는 속성과 불만이 큰 속성이 다를 수 있다는 점입니다. 많이 말하는 주제라고 꼭 문제인 것은 아니고, 적게 언급되더라도 강한 불만으로 나타나는 속성은 우선적으로 봐야 할 수 있습니다.

그림 1. 속성별 언급량과 스탠스

이 단계의 목적은 결론을 내리는 것이 아니라, 의사결정 후보군을 정리하는 것입니다. 어떤 속성을 더 들여다볼지 정하는 단계에 가깝습니다.

2. 속성 안을 다시 세분화한다

"혜택 불만이 많다"는 아직 추상적입니다. 쿠폰이 적다는 뜻인지, 조건이 복잡하다는 뜻인지, 적립이 안 됐다는 뜻인지, 이벤트가 미끼처럼 느껴졌다는 뜻인지에 따라 대응은 완전히 달라집니다.

기본 어피니티버블이 전체 리뷰를 의미 유사도 기준으로 묶어 큰 지형을 보여준다면, aspect-drilldown은 이미 찾은 특정 속성 안으로 들어갑니다. 그 속성과 관련된 문장 조각만 다시 묶기 때문에, 오버뷰에서는 "혜택 불만"으로 보이던 덩어리가 쿠폰 조건, 포인트 사용, 이벤트 불신처럼 실행 가능한 문제 단위로 나뉩니다.

그림 2. 측면 안의 하위 주제 분해. "사용성", "혜택", "배송"처럼 큰 측면을 다시 실행 가능한 문제 단위로 나눈다.

이렇게 쪼개야 비로소 선택이 가능해집니다. "혜택을 개선하자"는 말은 너무 넓지만, "쿠폰 적용 조건을 단순화하자"는 실행 항목이 됩니다. 측면 세분화의 목적은 리뷰를 선택 가능한 문제 단위로 바꾸어 줍니다.

3. 경쟁사별로 교차해 장단점을 본다

속성과 하위 주제를 찾았다면, 다음 질문은 비교입니다. 같은 배송 불만이라도 어느 앱에서 더 강한지, 같은 혜택 이야기라도 어느 앱에서는 장점이고 어느 앱에서는 불만인지 볼 수 있습니다.

aspect-cross는 공통 속성 코드북으로 리뷰를 분류한 뒤, 그 결과를 앱별로 교차 분석해 보여줍니다. 속성 × 앱 형태로 보면 각 앱의 장단점이 훨씬 선명해집니다.

그림 3. 속성 × 앱, 측면 × 별점 교차분석

이때 속성 단위 비교에서 한 번 더 들어가면, aspect-drilldown-cross처럼 볼 수 있습니다. 예를 들어 "혜택"이라는 속성을 프로모션 혜택체계와 쿠폰 이용 환경의 세부 하위 주제로 나누고, 각 하위 주제를 앱별로 나란히 비교합니다. 해결 가능한 실질적인 문제 단위로 나누고 각 앱의 장단점을 비교할 수 있습니다.

속성 드릴다운 x 앱 교차 분석 테이블

리뷰 분석이 우리 앱의 문제 목록에만 머물면 실행 우선순위를 잡기 어렵습니다. 경쟁사와 나란히 놓으면 문제가 전략적 의미를 갖습니다. 모두가 못하는 영역이면 차별화 기회가 되고, 특정 경쟁사가 잘하는 영역이면 따라잡아야 할 기준이 됩니다.

4. 오버뷰에서 선택까지

정리하면 흐름은 이렇습니다.

어피니티버블로 리뷰 전체의 오버뷰를 본다.
도메인에서 중요한 속성을 탐색한다.
각 속성 안의 하위 주제를 세분화한다.
경쟁사별로 교차해 장단점을 비교한다.

오버뷰는 출발점입니다. 전체 지형을 보지 못하면 어디를 파야 할지 알기 어렵습니다. 하지만 오버뷰에서 멈추면 "흥미로운 지도"에 머물 수 있습니다. 실제 의사결정에는 세분화와 비교가 필요합니다.

리뷰를 읽을 필요가 있는 위치를 좁히고, 손볼 수 있는 문제 단위로 바꾸고, 경쟁사 대비 어디에 집중할지 고르는 것입니다. 정성 분석의 가치는 요약이 아니라 선택을 돕는 데 있다고 생각합니다. 좋은 분석은 단순히 이해를 돕는 데서 멈추지 않고, 의사결정을 돕습니다.

위와 같은 분석은 어피니티버블의 프로 리포트의 형태로 제공될 예정입니다. 미리 경험하고 싶으신 분은 biz@affinitybubble.com으로 연락주시기 바랍니다.

그린그린 업무 대화

Seungyoon Lee — Fri, 26 Jun 2026 15:46:02 +0900

오래전에 함께 일을 했던 동료가 있어요. 그 동료의 업무 커뮤니케이션 방식에서 배울 점이 많았습니다. 제가 궁금해하기 전에 업무 상황이 공유되고, 제가 판단을 내려야 하는 부분이 콕 집어서 전달되어 저와 동료의 인지부하를 크게 줄여주었습니다. 아직도 가끔 ‘그 친구라면 어떻게 얘기했을까?’ 생각을 하곤 합니다.

조직이라는 곳은 참 다양한 사람들이 모이는 곳입니다. 듣기 좋은 얘기만 할 수 없고, 들을 수도 없습니다. 일정이 밀리기도 하고, 예상했던 만큼 결과가 나오지 않기도 하고, 클라이언트의 반응이 기대와 다를 때도 있는데, 이런 어려운 상황을 조직 안에서 잘 풀어내기가 어렵습니다.

어떤 대화는 문제를 더 크게 느끼게 만들고, 어떤 대화는 문제를 함께 다룰 수 있게 합니다. 전자를 레드레드, 후자를 그린그린이라고 불러보겠습니다.

PART 1. 팀원의 대화

이런 상황을 겪어 보신 적이 있으실 거예요.

사용자 인터뷰 대상자 20명을 모집하기로 했는데, 최종 모집 인원은 12명에 그쳤습니다. 목표를 달성하지 못한 것이죠. 이 상황을 어떻게 공유하면 좋을까요?

❌ 레드레드 ❌

아래 대화를 읽어 보세요.

그린그린

같은 상황을 다르게 공유해 볼 수도 있겠죠. 아래 대화처럼 말입니다.

이 두 대화는 어떻게 다르게 느껴지나요?

두 대화의 결과는 같습니다. 목표는 20명이었지만, 실제 모집 인원은 12명에 그쳤습니다.

레드레드 대화는 문제를 공유할 기회가 여러 번 있었는데도, 리더와 팀이 너무 늦게 알게 되었습니다. 왜 이런 일이 일어났는지 추측하며 급히 실패를 수습해야 하므로 인지부하가 생깁니다.

그린그린 대화는 문제 현황을 더 일찍 공유하는 동시에 문제의 원인도 함께 공유하고 있습니다. 리더는 상황을 추측할 필요가 없습니다. 추측할 시간에 문제를 해결하기 위해 일정 연장, 분석 범위 조정, 리포트의 한계 명시 등 가능한 선택지를 빠르게 검토할 수 있게 되는 것이죠. 이로써 리더가 결과를 상상하거나 여러 상황을 시뮬레이션해 보는 등 인지부하를 낮춰 빠르고 명료한 해결이 가능하게 됩니다.

그린그린 ≠ 성공 보고

좋은 커뮤니케이션은 리더를 안심시키거나 좋지 않은 결과를 예쁘게 말하는 것이 아닙니다. 실패와 위험을 더 빨리, 정확하게, 함께 다룰 수 있게 만드는 대화입니다. 그러기 위해서는 다음 정보를 함께 전달해야 합니다.

현재 상태는 어떠한가
목표와 얼마나 차이가 있는가
어떤 리스크가 예상되는가 (숫자와 영향도)
그 리스크를 줄일지, 해결할지, 감수할지
리더나 팀의 판단과 개입이 필요한 지점은 어디인가

PART 2. 리더의 대화

그린그린과 레드레드는 팀원의 공유 방식에만 있는 것이 아닙니다. 리더에게도 똑같이 적용됩니다.

똑같이 사용자 인터뷰 대상자 20명을 모집하기로 했는데, 최종 모집 인원은 12명에 그칠 것 같다는 예상을 리더에게 보고하는 상황입니다. 리더의 지적이 사람을 향하는지, 업무 해결을 향하는지, 문제의 원인을 파고드는지, 해결을 바라보는 데 있는지에 따라 팀의 효율이 크게 달라집니다.

❌ 레드레드 ❌

그린그린

같은 말을 들은 리더가 다르게 반응할 수도 있습니다.

두 대화 모두 리더는 발생한 문제를 해결하려고 합니다. 레드레드 대화에서는 대화가 진행될수록 초점이 점점 문제의 원인으로, 그 방향이 사람으로 옮겨지고 있습니다. 반면 그린그린 대화에서는 리더의 초점이 문제를 함께 해결하는 데 맞춰져 있습니다.

레드레드 대화는 듣는 사람의 입장에서 ‘문제를 함께 다루고 있다’기보다는 ‘내가 문제로 지목되고 있다’고 느낄 수 있고 이런 상황은 팀의 업무 효율을 크게 낮추는 부정적인 효과를 낳습니다.

그린그린한 리더는

고칠 점을 정확히 말하고,
기준을 분명히 세우고 있으며,
문제를 문제로 남겨 두고, 팀원이 다음 행동을 할 수 있게 돕습니다.

PART 3. AI 시대의 그린그린 업무 대화

AI와 함께 일하면서 업무 커뮤니케이션에도 새로운 애매함이 생겼습니다.

예전에는 초안이 거칠거나 표가 비어 있으면 “아직 판단 중이구나”를 알 수 있었습니다. 그런데 AI는 분류, 요약, 문장화를 빠르게 해내기 때문에 아직 검토가 필요한 판단도 완성된 결론처럼 보이게 만듭니다.

앞서 보았던 리크루팅 사례를 AI 시대의 업무로 다시 생각해 보겠습니다.

인터뷰 대상자 20명을 모집해야 하는 프로젝트에서 신청자 35명이 모였습니다. 팀원은 이 응답 데이터를 AI에 넣어 1차 스크리닝을 했고, AI는 14명을 우선 인터뷰 대상으로, 21명을 보류 대상으로 분류했습니다. 팀원은 우선 대상자 14명부터 컨택했고, 최종 12명을 확정했습니다.

❌ 레드레드 ❌

겉으로 보면 합리적인 과정처럼 보입니다. 신청자 데이터를 검토했고, AI가 적합도가 높은 사람을 골라 주었으며, 가능한 사람을 확정했기 때문입니다.

하지만 중요한 것은 판단의 주체가 어디에 있었는가 하는 것입니다. “AI가 우선순위로 뽑은 14명에게 연락했고, 최종 12명을 확정했습니다”라고 결과만 공유하면, 리더는 이미 끝난 판단을 뒤늦게 받게 됩니다. AI가 만든 기준이 팀과 논의되기 전에 이미 실행 기준이 되어 버렸다는 것이 업무 대화를 어렵게 만드는 이유가 됩니다.

그린그린

AI가 업무 프로세스에 중요한 역할을 할 때에는 AI가 어떤 기준으로 분류했는지, 그 기준이 프로젝트 목적과 맞는지, 보류되거나 제외된 대상 중 다시 봐야 할 사람이 있는지, 팀이 함께 판단해야 할 지점은 무엇인지 공유하는 것이 중요합니다.

AI는 업무를 빠르게 만들어 주지만, 그만큼 판단도 빨리 굳어질 수 있습니다. 그래서 결과를 빨리 공유하는 것을 넘어, AI가 만든 기준이 팀의 판단으로 굳기 전에 공유할 수 있도록 노력해야 합니다. AI가 어디까지 정리했고, 어디부터 사람이 다시 판단해야 하는지 드러내는 것입니다.

예를 들어, 아래와 같이 얘기할 수 있겠죠.

AI가 14명을 우선 인터뷰 대상으로 분류했습니다.
다만 분류 기준이 응답 충실도와 현재 사용 빈도에 가까운 것 같습니다.
이번 리서치 목적상 보류된 21명 중 이탈 가능성이 있는 사용자를 다시 봐야 할지 논의가 필요합니다.

즉, AI가 어디까지 정리했고, 어디부터 사람이 다시 판단해야 하는지 드러내는 것이 중요합니다.

리더가 개입해야 하는 시점과 개입 목적을 잘 파악하는 것이 중요

그린그린 업무 대화

지금까지 이야기한 내용을 요약해 보면 다음과 같습니다.

구분	기존 업무 대화	AI 시대 레드레드	AI 시대 그린그린
공유 시점	결과가 나오기 전	판단과 실행 완료 후	판단이 굳기 전
팀원은	진행 상황과 리스크 공유	AI가 정리한 결과를 실행 후 결과만 보고	AI가 제시한 기준·가설 및 리스크 공유
리더는	진행상황 확인 후 필요한 지원 제공	이미 끝난 판단을 검토 및 수습	판단이 필요한 지점을 함께 확인하고 방향 조정
핵심 내용	진행률·리스크	완료된 결과	확정/가설/재판단 지점

업무 대화의 핵심은 단순합니다.

팀원 입장에서는 리더와 팀이 적절히 개입할 수 있도록 상황을 공유하는 것이고, 리더 입장에서는 사람을 공격하지 않고 다음 판단을 함께 내리는 것입니다.

AI가 업무 과정에 도입되면서 이 기준은 조금 더 확장되었습니다. AI 이전에는 미완성인 상태를 공유할 용기가 필요했습니다. 하지만 AI 시대에는 완성된 것처럼 보이는 결과물을 미완성이라고 말할 책임이 필요합니다. AI 시대의 리더 역시 달라져야 합니다. 사람의 판단이 필요한 지점을 드러내고 함께 논의할 수 있게 해야 합니다.

결국 그린그린한 대화란, 사람이 함께 판단할 수 있는 시간을 확보해 효율과 질을 극대화하는 것 같습니다.

App Router 이후 React 생태계 동향

hongdoyoung — Mon, 22 Jun 2026 07:50:31 +0900

들어가며

React 공식 블로그나 Next.js App Router 중심의 흐름을 보면 최근 React 생태계는 서버 중심 렌더링 구조를 적극적으로 활용하는 방향으로 변화하고 있는 것 같습니다. Server Components, Streaming UI, Server Actions 같은 개념들의 등장 이후, 기존에 익숙했던 CSR(Client Side Rendering) 중심의 개발 방식이 Server Components 기반 구조와 공존하는 방향으로 흐르는 추세인 것 같습니다. 이런 흐름은 React 19 이후에 좀 더 명확해졌는데요, 근래의 React 동향에 대해서 정리해 보았습니다.

서버 중심 구조로 변화하는 React

Server Components 중심으로 변화해온 흐름

React 공식 블로그를 보면 몇 가지 공통적으로 등장하는 키워드들이 있습니다.

Server Components
Streaming UI
React Compiler
Server Actions

이 키워드들의 등장 의미는 React가 단순히 컴포넌트를 렌더링 하는 수준을 넘어, 서버와 클라이언트를 함께 고려하는 애플리케이션 구조로의 변화를 공식으로 삼고 있다는 점입니다. 특히 Next.js App Router 이후 이러한 흐름은 React 생태계 전반으로 빠르게 확산되고 안정화 및 정착되고 있습니다.

CSR 중심 구조의 한계

이러한 변화는 단순히 React 팀의 취향 변화라기보다는, 현대 웹 애플리케이션 규모가 커지면서 자연스럽게 등장한 흐름에 가까워 보입니다. CSR 방식에서는 프로젝트 규모가 커질수록 클라이언트가 처리해야 하는 JavaScript 양 역시 함께 증가하게 됩니다. 자연스럽게 번들 크기와 hydration 비용도 커지게 되고, 초기 렌더링 성능 문제로 이어지는 경우도 많았습니다. 특히 모바일 환경에서는 더욱 체감이 크기도 했고요.

전통적 React 프레임워크에서는 React Query나 SWR 같은 라이브러리를 활용해 클라이언트에 데이터를 가져오는 방식이 일반적이었습니다.

물론 이러한 방식은 캐싱이나 상태 관리 측면에서 많은 장점이 있었지만, 결국 브라우저에서 JavaScript가 실행된 이후 데이터를 요청하는 구조라는 점은 크게 달라지지 않았습니다.

const { data, isLoading } = useQuery({
  queryKey: ['posts'],
  queryFn: fetchPosts,
})

하지만 서버 컴포넌트 기반에서는 데이터를 가능한 서버에서 먼저 가져오고, 클라이언트에는 필요한 UI만 전달합니다. 클라이언트로 전달되는 JavaScript 양을 줄일 수 있다는 점은 초기 렌더링 성능 측면에서도 장점이 있습니다.

async function Page() {
  const data = await fetch(...)
  return <Component data={data} />
}

useEffect 기반 데이터 fetch 흐름은 결국 “렌더링 이후 데이터를 가져오는 구조”에 가까웠기 때문에 초기 사용자 경험 측면에서는 아쉬움이 존재하기도 했습니다. 되돌아보면 늘 사용자 경험을 고민해야 하는 XE 그룹 입장에서는 어떻게 해야 useEffect를 최소한으로 사용할 수 있을지도 고민 대상이었습니다.

React가 서버 중심 구조를 강화하는 이유도 결국 이런 문제들을 해결하기 위한 방향으로 볼 수 있을 것 같습니다. React 18 시기에 제시되었던 RSC 개념은 App Router를 거치며 React 19 이후 조금 더 안정화되었고, 최근에는 실제 생태계에서도 점진적으로 적용 범위가 넓어지고 있는 것 같습니다.

Streaming UI와 점진적인 렌더링 변화

Streaming UI 역시 현재 React 흐름에서 자주 등장하는 개념 중 하나입니다. 개념 자체는 등장한 지 꽤 되었지만 App Router 이후 적극적 사용 단계로 자리 잡았습니다.

기존 SSR(Server Side Rendering) 방식에서는 서버에서 페이지에 필요한 대부분의 HTML을 생성한 이후 브라우저로 전달합니다. 이 방식은 페이지 규모가 커질수록 페이지 렌더링 시간이 오래 걸렸고, hydration 과정 역시 부담이 될 수 있었습니다.

Streaming 기반 렌더링은 이러한 흐름을 조금 더 잘게 나누어 처리할 수 있도록 변경되었습니다.

준비된 UI부터 먼저 사용자에게 전달하고, 이후 필요한 부분들을 점진적으로 이어서 렌더링 하는 방식입니다. Suspense boundary를 기준으로 렌더링 흐름을 분리할 수 있게 되면서, 페이지 전체가 준비될 때까지 기다리지 않고도 먼저 준비된 영역부터 사용자에게 보여줄 수 있게 되었습니다. App Router 이후 이러한 Streaming 기반 렌더링 구조 역시 실무에서 점점 자연스럽게 사용되고 있는 것 같습니다.

React Compiler가 의미하는 것

React Compiler는 메모이제이션과 렌더링 최적화 일부를 컴파일 단계에서 자동으로 처리해, 개발자가 useMemo나 useCallback 같은 최적화 코드를 직접 관리해야 하는 부담을 줄여줍니다.

기존 React에서는 성능 최적화를 위해 개발자가 직접 useMemo, useCallback, memo 등을 관리해야 하는 경우가 많았습니다. 이러한 방식은 개발자에게 비교적 많은 제어권을 제공한다는 장점이 있었지만, 반대로 렌더링 최적화까지 직접 고민해야 한다는 부담도 함께 존재했습니다. 성능 최적화를 위해 코드가 점점 복잡해지거나, 불필요한 부분까지 최적화를 적용하면서 오히려 역효과가 발생하는 경우도 한 번쯤은 다들 있었을 겁니다.

또한, Vue나 Svelte처럼 경쟁 프레임워크들이 “React는 너무 복잡하고 어렵다”라는 점을 기반으로 성장한 부분도 어느 정도 있다는 점, 서비스 규모가 커지고 UX에 대한 기대 수준도 높아졌으며 모바일 환경에서의 성능 확보도 기본이 되고 있다는 점에서 React Compiler의 등장은 이러한 흐름의 자연스러운 결과로 보입니다.

*React Compiler는 2025년 10월에 1.0 stable 버전이 공식 릴리즈 되었으며 점진적 도입을 제안했습니다.

마치며

XE 그룹은 대체적으로 Next.js App Router 방식을 선호하지만 다른 프레임워크로도 개발하는데요, 이런 프레임워크 생태계 흐름에 대해서 살펴보니 흥미로웠습니다. AI가 코드를 생산해 내는 지금 같은 시대에서는 거대한 생태계와 생태계가 어떤 흐름을 타고 있는지가 생각보다 중요하더라고요. 기회가 되면 다른 프레임워크의 생태계도 확인해 보면 재미있을 것 같습니다.

AX, 차별화보다 해자

Seungyoon Lee — Fri, 19 Jun 2026 08:32:45 +0900

우리는 '차별화(Differentiation)'의 중요성을 너무나 잘 알고 있습니다. 그런데 a16z와 같은 실리콘밸리의 대표적인 벤처캐피탈은 최근 제품이나 서비스의 경쟁력에서 차별화보다 '해자(Moat)'의 중요성을 강조하고 있습니다.

차별화와 해자

본격적인 이야기에 앞서, 두 개념을 살펴보겠습니다.

차별화 (Differentiation, 差別化)

일반적인 언어로서의 차별화는 둘 이상의 사물 사이의 차이를 인식하거나 만들어내는 것을 의미합니다. 차별화란 기업이나 개인, 제품이 다른 대상과 구별되는 고유한 특성이나 가치를 창출해 소비자에게 인식시키는 행위나 전략을 뜻합니다.

AX 시대에는 새로운 AI 기능이나 에이전트 경험을 먼저 제공하는 것이 대표적인 차별화 전략이 됩니다. 다만 AI 기술의 확산 속도가 매우 빠르기 때문에 이러한 차별화는 과거보다 훨씬 짧은 시간 안에 경쟁사에 의해 모방될 수 있습니다.

해자 (Moat/Defensibility, 垓字)

비즈니스 관점에서의 해자, 즉 방어력은 경쟁 기업이 쉽게 모방하거나 빼앗을 수 없는 기업만의 고유한 강점을 뜻합니다. 회사가 시장 점유율을 유지하고 경쟁사들로부터 수익 마진을 보호할 수 있는 능력이라고 할 수 있습니다.

AX 관점에서의 해자는 단순히 AI 기술을 보유하는 것이 아니라, 조직 고유의 데이터와 업무 맥락, 그리고 AI가 축적한 경험이 경쟁사가 쉽게 복제할 수 없는 자산으로 작동하는 상태를 의미합니다.

수년 전 등장했던 서비스, 클럽하우스(Clubhouse)를 기억하시나요? 클럽하우스는 음성 기반 소셜 네트워크라는 강력한 차별화로 새로운 시장을 만들어냈지만, 해자를 충분히 구축하기 전에 경쟁사들이 동일한 기능을 빠르게 도입했습니다. 팬데믹 이후 오프라인 활동이 재개되고 핵심 크리에이터들이 이탈하면서 차별화 요소는 더욱 빠르게 희석되었습니다. 물론 실패의 원인은 복합적이지만, 이 사례가 보여주는 핵심 교훈은 분명합니다. 차별화만으로는 충분하지 않으며, 경쟁사가 따라오기 전에 사용자가 떠나기 어려운 구조, 즉 해자를 함께 설계해야 한다는 것입니다.

위 내용을 정리하면 아래와 같습니다.

구분	차별화 (Differentiation)	해자 (Moat)
개념	지금은 달라 보이는데, 남도 곧 할 수 있는 것	구조적으로 남이 못 따라오게 막는 것
특징	고객의 눈길을 끄는 '기능'	경쟁자가 공격하지 못하는 '성벽'
사례	최신 기술, 트렌디한 스타일 등	독보적인 커뮤니티, 독점 원료, 압도적 물류망

새로운 기술을 적용한 제품을 출시하는 것은 차별화의 요소 중 하나입니다. 하지만 AI는 이러한 차별화가 유효하게 유지되는 주기를 급격히 앞당기고 있습니다. 시장에 진입하자마자 곧바로 기술 평준화가 이루어지기 때문에, 이제는 초기부터 단단한 해자를 함께 설계하는 것이 생존의 필수 조건이 되었습니다. 그래서 이제 우리는 제품을 지속할 수 있는 단단한 해자가 있는지 깊이 있게 살펴봐야 합니다.

해자는 컨텍스트에서 나온다

예를 들어, AI 에이전트를 활용한 제품을 발 빠르게 출시하기만 하면 업무 효율이 극적으로 올라가고 독점적인 경쟁 우위가 생길 것이라 생각하지만, 현실적으로 요즘의 기술 평준화의 속도는 우리의 생각보다 훨씬 더 빨라졌습니다.

“AI 에이전트로 보고서를 딸깍!”이라고 하면 강력한 차별화 요소가 될 수 있습니다. 그런데 경쟁사 역시 곧 똑같은 오픈소스나 API를 구독하고, 유사한 프롬프트를 활용하면 우리의 기능을 즉시 따라잡을 수 있다는 것입니다.

이때 해자를 정교하게 설계하는 것이 필요하며, 사용자의 결과물(Output), 행동 방식(Behavior), 사고 방식(Thinking)에 해당합니다. 이 세 가지가 축적될 때 비로소 경쟁사가 복제하기 어려운 컨텍스트가 형성됩니다.

사용자의 데이터를 얼마나 축적하고 활용할 수 있는가?
사용자의 업무 방식이 얼마나 내재화되어 있는가?
사용자의 의사결정 기준을 얼마나 학습하고 있는가?

컨텍스트를 구성하는 요소들

사용자의 데이터를 얼마나 축적하고 활용할 수 있는가?

제품은 데이터 자산을 쌓고 사용자가 잘 활용할 수 있도록 해야 합니다. 레거시를 대체하는 제품이라면 지난 시간 동안 차곡차곡 쌓아온 데이터를 활용할 수 있게 해야 합니다. 만약 사용자의 의사결정 맥락을 AI 에이전트가 완벽하게 학습했다면 그것은 타사가 넘볼 수 없는 해자가 될 것입니다. 바꿔 말하면, 이 제품을 바꾸면 우리 회사의 뇌를 다시 키워야 하는 그런 한 방이 필요합니다.

사용자의 업무 방식이 얼마나 내재화되어 있는가?

제품이 사용자의 업무에 자연스럽게 녹아들 수 있다면 강력한 락인(Lock-in)효과가 생기게 됩니다. 업무 파이프라인 전체를 에이전트로 대체할 수도 있지만, 어느 한 부분을 AI 프로덕트로 대체하더라도 파이프라인의 각 업무 영역이 자연스럽게 연결되는 것이 중요합니다. 사용자가 업무의 영역과 결과를 명확하게 인지할 수 있는 경험을 설계하는 것이 중요합니다. 즉, "이 AI 프로덕트가 사라지면 우리의 업무가 무너지는가?", "다른 AI 솔루션으로 변경하려면 막대한 비용이 드는가?"를 자문해야 합니다.

차별화된 AI 프로덕트를 업무에 적용하더라도 같은 단계의 업무가 중복되거나 다음 단계로 자연스럽게 넘어가지 않으면 AI 프로덕트는 바로 대체되기 쉽습니다.

기존의 업무를 완벽하게 대체하고 전후 태스크와 자연스럽게 연결될 때 업무 맥락을 고려한 해자가 구축됩니다.

사용자의 의사결정 기준을 얼마나 학습하고 있는가?

AI는 단순히 데이터를 저장하는 것을 넘어 사용자가 어떤 기준으로 판단하는지 학습해야 합니다. 같은 데이터를 보더라도 어떤 사용자는 비용을 우선시하고, 어떤 사용자는 품질이나 리스크를 우선시합니다. AI가 이러한 의사결정 패턴을 이해하게 되면 단순한 자동화 도구를 넘어 사용자의 사고방식을 보조하는 파트너가 됩니다.

결국 "기술은 사 올 수 있지만, 사용자의 맥락(Context)은 사 올 수 없다"는 점이 핵심 해자가 될 것입니다. 이전 글, ‘AX, 사람과 일을 이해하는 여정’에서도 사람을 이해하는 UX가 여전히 중요하다고 하는 이유입니다.

마무리하며

아래 표는 위에서 설명한 차별화와 해자를 기준으로 AI 프로덕트의 위치를 이해하기 위해 구성한 간단한 프레임워크입니다. 지금 우리 제품이 어떤 상황인지 간단히 점검해 보세요.

	차별화 ↓	차별화 ↑
해자 ↑	Infrastructure 눈에 띄는 특별함은 없지만, 없으면 일이 안 돌아가서 어쩔 수 없이 사용하게 됨	Castle 사용자가 우리 제품을 특별하다고 느끼고, 다른 곳으로 옮기려 해도 비용이 너무 큼
해자 ↓	Danger Zone 별다른 차별점이 없어 사용자가 언제든 떠날 수 있는 상태	Fad 사용자가 지금 "신기하다/좋다"고 느끼는 점을 경쟁사가 곧 따라잡을 수 있음

UX 시대의 핵심 질문은 "사용자가 쉽게 사용할 수 있는가?"였습니다. 반면 AX 시대의 핵심 질문은 "AI가 사용자의 맥락을 충분히 이해하고 있는가?"에 가깝습니다.

즉, AI 시대의 해자는 기능이 아니라 축적된 컨텍스트에 있습니다. 주요 AI 기업에서 Context Engineering, Context Graph와 같은 개념을 강조하는 것과 맥락을 같이 합니다. 그래서 AX는 사용자의 맥락(Context)을 이해하고 설계하는 데 가깝습니다.

빠르게 발전하는 기술의 시대에 역설적으로 가장 중요한 것은 기술이 아니라 사람입니다. 결국 강력한 해자는 사용자를 얼마나 깊이 이해하고, 그 맥락을 얼마나 오랫동안 축적할 수 있는가에 의해 만들어집니다. AI 시대에 사람을 이해하는 일이 다시 중요해진 이유가 바로 여기에 있습니다. 해자를 구성하는 세 가지 요소, 즉 사용자의 데이터, 업무 방식, 의사결정 기준은 모두 사람을 깊이 관찰하고 이해해야만 설계할 수 있는 요소들입니다. AI가 아무리 발전해도, 사용자의 맥락을 먼저 발굴하고 정의하는 일은 결국 사람이 해야 합니다. 그래서 UX 리서처와 UX 디자이너가 여전히 바쁘고 할 일이 많은 것 같습니다.

AI가 인용하고 싶은 페이지는 어떻게 생겼을까

crsmym — Thu, 11 Jun 2026 10:08:15 +0900

들어가며

지난 편에서 검색엔진과 AI 크롤러가 우리 사이트를 어떻게 발견하는지를 다뤘어요. robots.txt, sitemap, canonical, 리다이렉트, AI 크롤러 허용까지 — 결국 "크롤러가 페이지에 안정적으로 닿을 수 있는가"가 핵심이었죠.

이번 편에서는 그 다음 단계 이야기예요. 크롤러가 페이지에 도착했어요. 그다음엔 뭘 볼까요?

검색엔진이든 AI든, 페이지에 도착한 이후에는 콘텐츠의 구조를 읽어요. 제목이 뭔지, 주제가 뭔지, 어떤 질문에 답하고 있는지, 정보가 어떤 단위로 나뉘어 있는지. 이 구조가 명확한 페이지는 검색 결과에서도, AI 답변에서도 선택받을 가능성이 높아요.

이번 편에서는 "AI가 인용하고 싶어지는 페이지"가 어떤 구조적 특성을 가지고 있는지, 프론트엔드 개발자가 실제로 챙길 수 있는 요소들을 중심으로 풀어볼게요.

검색엔진과 AI는 페이지를 어떻게 "읽는가"

검색엔진의 읽기 방식

Google 같은 검색엔진은 페이지를 크롤링한 후, HTML 구조를 파싱해서 콘텐츠를 이해해요. 이때 참고하는 주요 신호는 이런 것들이에요.

<title> 태그 — 이 페이지가 무엇에 관한 건지 가장 먼저 확인하는 요소예요. 검색 결과의 파란색 제목으로 직접 노출되기도 하고요.
<meta name="description"> — 검색 결과 스니펫의 설명 텍스트로 사용돼요. 직접 순위에 영향을 주진 않지만, 클릭률(CTR)에는 큰 영향을 미쳐요.
<h1>, <h2>, <h3> 같은 헤딩 태그 — 콘텐츠의 계층 구조를 파악하는 데 사용해요. 어떤 주제가 있고, 그 아래 어떤 하위 주제들이 있는지를 헤딩 계층으로 이해해요.
본문의 <p>, <ul>, <ol>, <table> — 실제 콘텐츠가 담긴 요소들이에요. 검색엔진은 이 안의 텍스트를 분석해서 페이지 주제와 키워드를 파악해요.

AI의 읽기 방식 — 여기서 차이가 생긴다

AI도 기본적으로 같은 HTML을 읽어요. 근데 목적이 달라요.

검색엔진은 "이 페이지가 어떤 검색어에 적합한가"를 판단하지만, AI는 "이 페이지에서 사용자의 질문에 대한 답을 추출할 수 있는가"를 봐요.

참고로 Google도 2021년부터 "Passage Ranking"이라는 기능을 통해 페이지 내 특정 구간의 관련성을 개별적으로 평가해서 랭킹에 반영하고 있어요. 전체 페이지의 주제와 다소 동떨어져 있더라도, 특정 문단이 검색어에 잘 맞으면 그 페이지를 상위에 올려주는 방식이에요. Google은 이게 "인덱싱 변경이 아니라 랭킹 변경"이라고 설명했고, 전체 쿼리의 약 7%에 영향을 준다고 밝힌 바 있어요.

AI 검색 서비스(ChatGPT, Perplexity 등)도 비슷한 방향이에요. 이런 서비스들은 RAG(Retrieval-Augmented Generation)라는 방식으로 작동하는데, 페이지 전체를 통째로 평가하기보다 페이지에서 질문과 관련 있는 구간을 찾아서 인용하는 방식에 가까워요. ChatGPT, Perplexity, Google AI Overviews, Claude 모두 이 RAG 구조를 기반으로 하고 있어요(참고). 그래서 긴 글이라도 AI가 실제로 인용하는 건 특정 문단 하나일 수 있어요.

예를 들어볼게요. 어떤 통신사 요금제 페이지가 있다고 해봐요. "이 요금제 월 요금이 얼마야?"라는 질문에 AI가 답하려면, 페이지에서 가격 정보를 정확히 추출할 수 있어야 해요. 근데 가격이 마케팅 배너 이미지 안에만 있거나, 긴 문단 중간에 "합리적인 가격으로 제공되는 이 요금제는 다양한 혜택과 함께..." 같은 식으로 묻혀 있으면, AI가 그 문단을 인용 대상으로 선택하기 어려워요.

반면 "월 55,000원"이라는 정보가 텍스트로 명시적으로 존재하고, 주변에 요금제 이름과 조건이 구조적으로 배치되어 있으면, AI가 그 문단을 인용하기 훨씬 쉬워지는 거예요.

Title과 Meta Description — 첫인상을 결정하는 메타데이터

Title 태그

<title> 태그는 검색엔진과 AI 모두에게 "이 페이지의 주제가 뭔지"를 알려주는 가장 강력한 신호예요.

길이는 픽셀 기준이다 — 많은 가이드에서 "60자 이내"라고 하지만, Google은 사실 글자 수가 아니라 픽셀 폭(데스크톱 기준 약 600px)으로 잘라요. 영문은 대략 50~60자가 이 안에 들어오지만, 한글은 글자당 픽셀 폭이 더 넓어서 같은 600px에 더 적은 글자가 들어가요. 한글 기준으로는 30~60자 정도가 실무적인 가이드라인이에요. SERP 미리보기 도구로 실제 표시 상태를 함께 확인하면 더 좋고요.
Google은 Title을 자주 재작성한다 — 이것도 알아둬야 할 현실적인 포인트예요. 2025년 Q1 기준 Google이 약 76%의 비율로 Title을 재작성한다는 분석 결과가 있어요. Title이 너무 길거나, 콘텐츠와 맞지 않거나, 키워드 스터핑이 심한 경우 Google이 자체적으로 더 적합하다고 판단한 제목으로 바꿔버려요. 그래서 Title 길이를 엄격하게 맞추는 것보다, 핵심 키워드와 명확한 주제를 Title 앞부분에 배치하는 게 더 실질적인 전략이에요.

<!-- 키워드가 뒤에 묻힌 경우 -->
<title>우리 회사 공식 홈페이지 - 클라우드 서버 호스팅 서비스</title>
<!-- 핵심 키워드가 앞에 온 경우 -->
<title>클라우드 서버 호스팅 — 안정적인 인프라 서비스 | 회사명</title>

GEO 관점에서의 Title — AI가 페이지 주제를 판단할 때도 Title을 가장 먼저 참고해요. "이 페이지가 어떤 질문에 답할 수 있는 페이지인지"를 Title에서 1차 판단하는 거예요. Title이 모호하면 AI가 인용 후보에서 제외할 가능성이 높아요.

Meta Description

길이 — 2026년 기준 데스크톱에서는 약 920px(평균 158자), 모바일에서는 약 680px(평균 120자)까지 표시돼요. 모바일 트래픽이 전체의 60% 이상을 차지하는 현실을 고려하면, 핵심 내용을 앞쪽 120자 안에 배치하는 게 중요해요. 전체적으로는 70~155자 사이가 적정 범위예요. 70자 미만이면 정보 전달이 부족하고, 155자를 넘으면 잘릴 수 있어요.
Google은 Description도 재작성한다 — Title과 마찬가지로 Google은 description을 자주 무시하고 페이지 본문에서 검색어에 더 적합한 텍스트를 뽑아서 스니펫으로 보여줘요. 그럼에도 명시적으로 작성해두는 게 좋은데, Google이 우리가 쓴 description을 그대로 사용하는 경우도 있고, AI가 페이지 주제를 빠르게 파악하는 데 참고할 수 있거든요.

헤딩 구조 — 콘텐츠의 뼈대를 만들기

H1은 페이지당 하나

H1 태그는 페이지의 대표 제목이에요. HTML5 스펙상 여러 개를 쓸 수 있고, Google의 John Mueller도 "여러 H1을 써도 순위에 직접적인 패널티는 없다"고 말한 바 있어요. 하지만 SEO와 GEO 모두에서 하나만 사용하는 게 권장돼요. 검색엔진과 AI가 "이 페이지의 핵심 주제가 뭐지?"를 판단할 때 H1을 가장 먼저 보는데, H1이 여러 개면 주제가 분산되어 보이거든요.

<!-- H1이 두 개인 경우 — 주제가 분산됨 -->
<h1>회사 소개</h1>
<!-- ... 중간 콘텐츠 ... -->
<h1>우리의 서비스</h1>

<!-- H1 하나 + H2로 구분한 경우 — 구조가 명확함 -->
<h1>회사 소개 및 서비스 안내</h1>
<h2>회사 소개</h2>
<!-- ... -->
<h2>우리의 서비스</h2>

헤딩 계층은 건너뛰지 않기

H1 → H2 → H3 순서로 사용해야 해요. H1 바로 아래에 H3이 오는 건 문서 구조상 논리적이지 않아요. 이건 검색엔진뿐 아니라 스크린 리더 같은 보조 기술에서도 중요한 부분이에요.

GEO 관점에서의 헤딩

AI가 페이지 콘텐츠를 파악할 때, 헤딩 구조를 목차처럼 활용해요. 특히 질문형 헤딩(<h2>배송 기간은 얼마나 걸리나요?</h2>)은 AI의 질의응답 매칭에 직접적으로 도움이 돼요. AI가 사용자의 질문과 유사한 헤딩을 발견하면, 그 바로 아래 문단을 답변으로 추출할 가능성이 높아지거든요.

문단 구조 — AI가 인용하기 좋은 글쓰기

왜 문단 구조가 중요하다는가

GEO에서 가장 실질적으로 영향이 큰 부분이 문단 구조예요.

앞서 말한 것처럼, AI 검색 서비스는 페이지 전체를 통째로 인용하는 게 아니라 특정 구간을 골라서 인용해요. 그래서 각 문단이 독립적으로 의미를 전달할 수 있는 정보 단위로 기능하는지가 중요해요.

최적의 문단 길이에 대해 공식적인 표준은 없지만, 여러 GEO 실무자들은 짧고 핵심이 명확한 문단을 권장하고 있어요. 문단이 너무 길면 핵심 정보가 다른 문장들 사이에 묻히고, 너무 짧으면 맥락이 부족해지거든요. 핵심은 "한 문단에 하나의 명확한 사실이나 주장이 담겨 있고, 그 문단만 떼어 읽어도 의미가 통하는가"예요.

첫 문장에 핵심 사실 배치

저널리즘의 "역피라미드 구조"와 비슷한 접근이에요. 각 문단의 첫 문장에 가장 중요한 정보를 넣는 거예요. AI가 문단의 관련성을 판단할 때 앞부분의 내용이 영향을 줄 수 있고, 여러 GEO 가이드에서도 "답을 먼저 쓰고, 그다음에 깊이를 더하라(Lead with the answer, then deepen it)"는 접근을 권장하고 있어요.

<!-- AI가 인용하기 어려운 구조 -->
<p>
  최근 클라우드 시장의 급격한 성장과 함께 다양한 서비스가 등장하고 있는 가운데,
  많은 기업들이 비용 절감과 확장성을 이유로 클라우드 마이그레이션을 고려하고
  있습니다. 이런 환경에서 우리 서비스의 월 이용 요금은 55,000원입니다.
</p>

<!-- AI가 인용하기 좋은 구조 -->
<p>
  클라우드 서버 호스팅 월 이용 요금은 55,000원입니다. 기본 제공 사양은 vCPU
  2코어, 메모리 4GB, SSD 100GB이며, 트래픽은 월 1TB까지 포함됩니다.
</p>

두 번째 예시에서는 첫 문장에 가격이라는 핵심 정보가 바로 나오고, 이어서 구체적인 사양이 나열되죠. AI가 "이 서비스 가격이 얼마야?"라는 질문에 이 문단을 바로 인용할 수 있어요.

리스트와 표 활용

비교, 나열, 단계별 설명 같은 정보는 <ul>, <ol>, <table> 같은 구조화된 요소로 표현하는 게 좋아요.

<!-- 문단으로 나열된 경우 — 정보 추출이 어려움 -->
<p>
  기본 요금제는 월 33,000원이고, 스탠다드 요금제는 월 55,000원이며, 프리미엄
  요금제는 월 99,000원입니다.
</p>

<!-- 표로 구조화된 경우 — 비교가 쉬움 -->
<table>
  <thead>
    <tr>
      <th>요금제</th>
      <th>월 요금</th>
      <th>용량</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>기본</td>
      <td>33,000원</td>
      <td>50GB</td>
    </tr>
    <tr>
      <td>스탠다드</td>
      <td>55,000원</td>
      <td>100GB</td>
    </tr>
    <tr>
      <td>프리미엄</td>
      <td>99,000원</td>
      <td>500GB</td>
    </tr>
  </tbody>
</table>

검색엔진은 <table> 안의 데이터를 구조적으로 해석할 수 있고, AI는 표 형태의 정보를 비교·요약하는 데 특히 강해요.

FAQ 구조 — AI 인용의 가장 직접적인 경로

왜 FAQ가 GEO에서 중요한가

AI가 사용자 질문에 답할 때 가장 쉽게 활용할 수 있는 구조가 FAQ예요. 질문과 답변이 1:1로 매칭되어 있으면, AI는 사용자의 질문과 유사한 질문을 찾아서 해당 답변을 바로 인용할 수 있거든요.

질문-답변 근접 배치

FAQ를 만들 때 중요한 건, 질문 바로 아래에 답변이 오는 구조예요. 질문 10개를 먼저 나열하고 답변을 한꺼번에 아래에 모아두는 구조는 AI가 매칭하기 어려워요.

<!-- 권장 — 질문 직후에 답변 배치 -->
<section>
  <h2>배송은 얼마나 걸리나요?</h2>
  <p>
    주문 후 보통 2~3 영업일 내에 배송됩니다. 제주 및 도서산간 지역은 1~2일
    추가될 수 있습니다.
  </p>
</section>
<section>
  <h2>반품은 어떻게 하나요?</h2>
  <p>
    마이페이지 > 주문내역에서 반품 신청이 가능합니다. 수령 후 7일 이내에
    신청해야 합니다.
  </p>
</section>

FAQPage Schema — 리치 결과는 끝났지만, 구조화 데이터의 가치는 남아 있다

이 부분에서 한 가지 짚어둘 게 있어요. 2023년 8월 Google이 FAQ 리치 결과를 정부·건강 관련 권위 사이트로 제한했고, 2024년 초부터는 사실상 대부분의 사이트에서 FAQ 리치 스니펫이 표시되지 않게 됐어요.

그래서 "FAQPage Schema를 넣으면 검색 결과에 FAQ 드롭다운이 뜬다"는 기대는 이제 현실적이지 않아요.

다만 FAQPage 구조화 데이터를 아예 빼야 하는 건 아니에요. Google도 "사용되지 않는 구조화 데이터가 있다고 해서 검색에 문제가 생기지는 않는다"고 밝혔고, 더 중요한 건 AI 크롤러가 Q&A 구조를 파악하는 데는 여전히 유용할 수 있다는 점이에요. 검색엔진의 리치 결과 표시 여부와, AI가 콘텐츠를 이해하고 인용하는 과정은 별개의 메커니즘이니까요.

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "배송은 얼마나 걸리나요?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "주문 후 보통 2~3 영업일 내에 배송됩니다."
        }
      }
    ]
  }
</script>

구조화 데이터 전반에 대해서는 다음 편에서 더 자세히 다룰 예정이에요.

GEO 연구가 말하는, 실제로 효과가 큰 전략들

GEO라는 개념을 처음 제안한 Princeton, Georgia Tech, IIT Delhi, Allen AI 공동 연구팀의 논문에서는 어떤 최적화 전략이 AI 인용률을 실제로 올리는지 정량적으로 측정했어요. 결과가 꽤 흥미로워요.

효과가 큰 전략 (인용률 30~40% 향상)

논문에 따르면, 아래 세 가지 전략이 가장 큰 효과를 보였어요. 이 전략들은 Position-Adjusted Word Count 기준으로 30~40%의 인용률 향상을 기록했어요.

구체적인 통계 추가(Statistics Addition) — "시장이 빠르게 성장하고 있습니다" 대신 "2025년 기준 국내 클라우드 시장 규모는 약 8조 원입니다"처럼 구체적인 수치를 넣는 방식이에요.
전문가 인용 추가(Quotation Addition) — 관련 분야 전문가의 발언이나 견해를 명시적으로 인용하는 거예요. AI 모델이 속성이 명확한 전문가 발언을 신뢰도 높은 콘텐츠로 판단하는 경향이 있어요.
출처 명시(Cite Sources) — 학술 논문, 산업 보고서, 정부 데이터 같은 신뢰할 수 있는 출처를 명시적으로 밝히는 거예요.

효과가 있는 전략 (인용률 15~30% 향상)

가독성 향상 — 문장의 유창성을 높이고, 복잡한 개념을 쉽게 풀어쓰는 것도 효과가 있었어요.

효과가 거의 없는 전략

키워드 스터핑 — 전통 SEO에서 쓰던 키워드 반복 삽입은 GEO에서 거의 효과가 없었어요. AI는 키워드 밀도보다 정보의 구체성과 신뢰성을 더 중요하게 봐요.

정리하면, GEO에서 가장 효과적인 건 "주관적 표현을 객관적 사실로 바꾸는 것"이에요. 수식어 대신 수치, 주장 대신 출처, 모호한 설명 대신 구체적인 데이터.

시맨틱 HTML — div 대신 의미 있는 태그 쓰기

2편에서 "표준 HTML 요소 사용"을 잠깐 언급했는데, 이게 콘텐츠 구조에서도 중요해요.

<div>와 <span>은 의미가 없는 범용 컨테이너예요. 크롤러 입장에서는 "이 안에 뭐가 있는지" 추가 분석 없이는 알 수 없어요. 반면 <article>, <section>, <nav>, <aside>, <main> 같은 시맨틱 태그를 쓰면, 크롤러가 페이지의 구조를 더 빠르고 정확하게 파악할 수 있어요.

<!-- 시맨틱 태그를 활용한 구조 -->
<main>
  <article>
    <h1>SEO 가이드</h1>
    <p>본문 내용...</p>
  </article>
  <aside>관련 링크...</aside>
</main>

AI 크롤러도 마찬가지예요. <article> 안에 있는 콘텐츠는 "이 페이지의 핵심 내용"으로 인식할 가능성이 높고, <aside> 안에 있는 콘텐츠는 부가 정보로 구분할 수 있어요.

콘텐츠 최신성 — 오래된 정보는 신뢰를 잃는다

AI는 최신 정보에 대한 편향(recency bias)이 강해요. 특히 가격, 정책, 기술 사양처럼 변동 가능성이 있는 정보를 다루는 페이지에서는 업데이트 일자가 없으면 AI가 "이 정보가 현재도 유효한지" 판단하기 어려워해요.

<article>
  <h1>2026년 클라우드 서비스 비교</h1>
  <time datetime="2026-04-10">마지막 업데이트: 2026년 4월 10일</time>
  <!-- 본문 -->
</article>

HTML에 날짜를 표시하는 것과 별개로, Article 구조화 데이터에 dateModified를 넣으면 검색엔진이 이 정보를 더 명확하게 인식해요. 변동 가능성이 있는 주제를 다루는 페이지라면 정기적으로 내용을 점검하고, 업데이트 일자를 함께 갱신해주는 게 좋아요.

정리 — AI가 인용하고 싶은 페이지의 조건

이번 편에서 다룬 내용을 정리하면 이래요.

메타데이터가 명확한 페이지 — Title에 핵심 키워드가 앞쪽에 배치되어 있고, Description이 120자 안에 핵심 내용을 담고 있어요. Google이 재작성하더라도 핵심 키워드와 명확한 주제를 담아두는 게 중요해요.
헤딩 구조가 논리적인 페이지 — H1이 하나이고, H2, H3으로 이어지는 계층이 콘텐츠의 목차 역할을 해요. 질문형 헤딩은 AI의 질의응답 매칭에 직접적으로 도움이 돼요.
각 문단이 독립적으로 인용 가능한 페이지 — AI는 긴 글에서도 특정 구간만 골라서 인용해요. 짧고 핵심이 명확한 문단에 사실이 첫 문장에 오는 구조가 유리해요.
객관적 사실이 풍부한 페이지 — GEO 연구에 따르면, 구체적인 통계, 전문가 인용, 출처 명시가 인용률을 가장 크게 올려요(30~40% 향상). 수식어보다 수치, 주장보다 출처.
정보가 구조화된 페이지 — 비교 정보는 표로, 나열 정보는 리스트로, Q&A는 질문 직후 답변 배치.
최신 정보를 제공하는 페이지 — 업데이트 일자가 표시되고, 정기적으로 갱신되는 페이지.

마치며

이번 편에서 다룬 내용들은 결국 하나의 원칙으로 수렴해요. 좋은 콘텐츠를 만드는 것만큼, 그 콘텐츠가 기계적으로 추출 가능한 구조로 전달되는 게 중요하다는 거예요.

Google의 Passage Ranking이든, AI 검색 서비스의 RAG든, 검색 기술은 점점 더 페이지 안의 특정 구간을 정밀하게 평가하는 방향으로 진화하고 있어요. 그래서 "글 전체가 좋으면 된다"보다는, "각 문단이 독립적으로 의미를 전달할 수 있는 정보 단위로 기능하는가"를 함께 고민하는 게 좋아요.

사실 여기서 다룬 요소들 — 명확한 Title, 논리적인 헤딩, 짧고 핵심이 앞에 오는 문단, 통계와 출처 — 은 사람이 읽기에도 좋은 글의 조건과 상당 부분 겹쳐요. 다만 프론트엔드 개발자가 추가로 신경 써야 할 부분은, 이런 콘텐츠 구조가 HTML 레벨에서 명확하게 표현되는지예요.

다음 편에서는 구조화 데이터(JSON-LD, Schema.org)를 본격적으로 풀어볼게요. Article, Product, HowTo 같은 주요 스키마 타입을 실제 코드 예시와 함께 정리할 예정이에요.

참고 자료

Aggarwal, P., et al. (2023). "GEO: Generative Engine Optimization" — Princeton, Georgia Tech, IIT Delhi (https://arxiv.org/abs/2311.09735)
Google Search Central — 검색결과에 표시되는 제목 링크 (https://developers.google.com/search/docs/appearance/title-link)
Google Search Central — 메타 설명 (https://developers.google.com/search/docs/appearance/snippet)
Google Search Central — Changes to HowTo and FAQ rich results (2023.08) (https://developers.google.com/search/blog/2023/08/howto-faq-changes)
Search Engine Land — How Google indexes passages of a page (https://searchengineland.com/how-google-indexes-passages-of-a-page-and-what-it-means-for-seos-342215)
Search Engine Journal — Google Passage Ranking: Martin Splitt 인터뷰 (https://www.searchenginejournal.com/google-passage-ranking-martin-splitt/388206/)
Search Engine Land — Google changed 76% of title tags in Q1 2025 (https://searchengineland.com/google-changed-76-of-title-tags-in-q1-2025-heres-what-that-means-454847)
MRS Digital — Meta Length Checker 2026 (https://mrs.digital/tools/meta-length-checker/)
web.dev — Headings and landmarks (https://web.dev/articles/headings-and-landmarks)
Schema.org — FAQPage (https://schema.org/FAQPage)

이 글은 https://tech.pxd.co.kr/ 에서도 보실 수 있습니다.

별점과 리뷰로 사용자 경험 이해하기

無異 — Tue, 9 Jun 2026 19:10:21 +0900

배달 음식점을 고를 때도, 상품을 살 때도 별점부터 봅니다. 소비자에게는 나쁜 걸 먼저 걸러내는 좋은 휴리스틱입니다. 그런데 서비스를 운영하는 쪽, 그러니까 마케터나 리서처는 같은 별점을 어떻게 읽어야 할까요? 별점은 결국 개개인이 누른 별의 평균이고, '평균적인 사용자'는 대체로 존재하지 않습니다. 퍼소나를 나눠 보듯, 별점도 사용자를 세분화해서 봐야 합니다.

리뷰 텍스트를 어피니티버블로 묶으면 "사용자가 무엇을 말하는지"는 꽤 잘 보입니다. 그런데 리뷰에는 별점, 작성 시점 같은 정보가 늘 함께 달려 있습니다. 텍스트 군집을 이 메타데이터와 함께 보면 어떻게 되는지, K뷰티 앱 top3 (올리브영·화해·글로우픽)의 앱 리뷰로 확인해봤습니다.

별점은 평균이 아닌 분포를 봐야 한다

별점 2.6점인 사용자는 없습니다. 시장 1위 올리브영의 iOS 리뷰 평균이 2.6점인데, 이 숫자는 누가 만들었을까요?

올리브영 iOS 앱스토어 리뷰 별점 분포

리뷰 499개를 별점별로 나눠보면 1점이 44%, 5점이 24%로 양쪽 끝에 몰려 있습니다. 보통 정규분포를 기대하고 평균 2.6점짜리 사용자가 많을 거라고 예상하지만, 완전히 다른 두 경험이 서로 상쇄된 결과입니다. 화해도 비슷해서, 평균 3.1점이지만 실제로는 5점(34.5%)과 1점(33.5%)이 거의 맞붙어 있습니다. 평균은 양극화를 숨깁니다. 자연스러운 일이기도 합니다. 리뷰를 남기는 건 대체로 정말 불만이거나 정말 만족한 사람들이라, 분포는 전체 만족도가 아니라 '리뷰를 남길 만큼 경험이 강했던 사람들'의 목소리로 읽어야 합니다.

올리브영 앱스토어 리뷰 어피니티버블

같은 리뷰를 어피니티버블로 군집화하면 두 무리의 정체가 보입니다. 가장 큰 군집은 앱 안정성·기술 오류(35%)인데, 1점 리뷰에는 앱 실행 오류, 무한 로딩, 결제 실패가 반복되고 5점 리뷰에는 쇼핑 편의와 빠른 배송이 나옵니다. 같은 앱 안에 "앱이 안 열려 답답한 사람"과 "잘 쓰고 있어 만족한 사람"이 함께 있습니다.

군집 지도의 색을 평균 별점으로 칠하면(빨강 1점, 초록 5점) 긍부정 지형이 한눈에 들어옵니다.

올리브영 리뷰 긍부정 버블맵 - 군집 색 = 평균 별점

화면 대부분이 살구빛으로 불만을 나타냅니다. "인증 확인이 안돼요"(평균 별점 1)로 가장 눈에 띕니다. 사용을 못하니 가장 심각한 문제겠죠. 텍스트만 묶으면 어느 군집이 큰지만 보이는데, 별점을 입히면 어느 군집에 불만이 많은지가 같이 보입니다. 배송 서비스같은 경우 빠른 배송에 만족하는 사용자와 늦은 배송에 불만이 사용자가 섞여있습니다.

많이 나온 문제가 가장 급한 문제는 아니다

많이 언급된 군집과 불만이 큰 군집이 다르다면, 우선순위도 달라져야 합니다. 이걸 매트릭스로 만들면 좋습니다.

대분류	비중	평균 별점
앱 안정성·기술 오류	34.7%	2.1
사용자 경험·개선사항	22.0%	3.2
배송 서비스·품질	7.2%	2.0

우선순위 매트릭스

평균 별점(가로축)과 빈도(세로축)로 놓으면, 많이 언급되면서 별점도 낮은 왼쪽 위 칸이 먼저 살펴볼 후보입니다. 앱 안정성·기술 오류는 빈도 1위(35%)에 별점 2.1점으로 명확한 최우선입니다. 배송 서비스·품질은 빈도 7%에 불과하지만 평균 2.0점으로, 자주 언급되진 않아도 놓치면 안 되는 숨은 불만입니다.

빈도만 보면 "많이 나온 것부터 고치자"가 되고, 별점을 함께 보면 "많이 나오면서 강하게 불만으로 표현된 것부터 보자"가 됩니다.

시계열 변화 보기

별점을 시계열에 늘어놓는 것만으로 많은 정보를 줍니다. 아래는 저 시기에 문제가 생겨서 불만 리뷰가 치솟았다가 해결 된 것을 보여줍니다.

이걸 다시 클러스터링하고 시계열에 펼쳐놓으면 주제별로 세분화해 확인 할 수 있습니다. 월단위나 분기 단위로 묶어서 볼 수 있습니다.

주제별 클러스터 시계열 변화

앱 안정성·기술 오류는 2024년부터 2026년까지 여러 분기에 걸친 반복 패턴입니다. 누구에게나 쉽게 재현되지 않는 예외적으로 케이스에서 간헐적으로 생기는 경우 쉽게 대처가 되지 않아 계속 남아있는 경우가 많습니다. 리뷰 정렬·옵션 필터는 반대로 2025년 4분기에 집중된 일시적 급증입니다(전체 15건 중 13건). 리뷰 UI를 개편하며 옵션별 필터링과 도움순 정렬을 없앤 데 대한 불만이 나오다가 업데이트로 해결 된 것 같습니다.

"상품별 리뷰 보기 왜 없어진거죠" · "리뷰 도움순 돌려내세요" · "누구를 위한 업데이트"

별점은 후한데 글은 부정적인 리뷰

리뷰에는 별점 말고 글 자체의 감정도 있습니다. 어피니티버블은 LLM으로 본문을 읽어 1점(부정)–5점(긍정) 감성 점수를 매기는데, 별점과 늘 일치하지는 않습니다. 군집 지도를 별점 대신 글의 감성으로 칠하면 화면이 한층 더 붉어집니다. 리뷰에서는 평상시 잘쓰고 있지만 사용 중 불만이나 개선 사항을 얘기하는 경우에 부정적인 얘기이니 긍부정 점수가 별점보다 낮은 경우가 많습니다.

별점, 긍부점 점수 차이

전체적으로 긍부정점수가 양극으로 더 치우친 경향이 있습니다. 그런데 방향이 반대인건 회원 가입 및 연령 제한 클러스터인데요.

"구매하고 싶은데 회원가입이 안 돼서ㅠㅠ 그거 빼면 너무 좋은 거 같아요" · "부모님 동의로 바꾸면 안 되나요, 하나하나 메모해서 사는 거 너무 번거로워요" · "지금은 아빠 아이디로 써요… 다른 건 다 좋습니다"

긍부정점수는 낮은데 왜 별점은 높을까요. 내용 자체는 불만을 얘기하지만 사용자는 애착이 있습니다. 별점에는 애착이 남아 있고, 글에는 막힘에 대한 불만이 드러납니다. 별점만 봤다면 "3점대면 괜찮네" 하고 지나쳤을 군집입니다. 그래서 별점과 감성이 벌어지는 군집은 따로 챙겨볼 만합니다. 애착이 남은 사람들이 모여 있으니까요.

별점 높은 앱에서는 '왜 좋은지'가 더 궁금하다

세분화가 필요한 건 불만만이 아닙니다. 글로우픽은 평균 4.6점에 5점이 82.6%입니다. "잘하고 있네"로 덮기 쉽지만, 별점이 높을수록 오히려 왜 좋은지가 궁금합니다.

글로우픽 iOS 앱스토어 리뷰 별점 분포

올리브영이 양 끝으로 갈라졌다면 글로우픽은 5점 하나로 쏠려, 평균 4.6점은 변별력이 없습니다. 남는 질문은 "왜 좋은가"입니다. 긍정 리뷰는 리뷰 신뢰(31.8%), 습관적 사용(23.4%), 체험단 당첨 경험(21.0%) 세 축으로 나뉘고, 그 안에 이런 말이 반복됩니다.

글로우픽 앱스토어 리뷰 어피니티버블

"화장품 살 때마다 꼭 켠다" · "없으면 큰일 난다" · "이벤트 당첨이 생각보다 잘 된다"

실제 사용자의 언어라서 광고 카피보다 강할 때가 있습니다.

다만 체험단 당첨 경험은 칭찬의 대상이 다릅니다. 처음엔 보상성 거품을 의심했는데요 :) 별점만 후하게 주는 패턴이라면 앞서 쓴 별점과 감성의 격차로 잡힐 테니까요. 결과는 별점 4.93에 감성 4.90로 격차가 거의 없습니다. "당첨되면 선물받는 느낌이라 너무 좋습니다" 같은 본문도 진심 어린 칭찬입니다. 대신 원문의 언어가 다릅니다. 이 군집에서는 '당첨'이 29%(전체 9%), '이벤트'가 66%(전체 18%) 등장합니다. 칭찬은 진짜인데 그 대상이 제품력이 아니라 당첨과 보상 경험인 거죠. 글로우픽 4.6점의 약 5분의 1은 보상 설계에 대한 평가입니다. 흥미로운 건 이게 별점과 감성의 격차로는 안 보인다는 점입니다. 보상에서 온 칭찬도 진심이라 둘 다 높으니까요. 원문의 보상 언어를 직접 봐야 드러납니다.

활용도 갈립니다. "제품 비교가 편하다"는 제품 메시지의 재료지만, "당첨이 잘 된다"는 체험단 운영의 성과 지표에 가깝습니다. 긍정도 무엇에 대한 긍정인지 나눠봐야 합니다.

정리하며

텍스트와 별점같은 메타데이터를 보면 사용자가 처해있는 상황을 좀 더 잘 상상해 볼 수 있습니다.

겹쳐 본 것	드러나는 것
텍스트 군집	사용자가 무엇을 말하는지
+ 별점 분포	평균 뒤에 숨은 양극화
+ 군집별 평균 별점	빈도와 다른 우선순위
+ 작성 시점	일시적 급증 vs 반복 패턴
+ 텍스트 감성	"쓰고 싶은데 막힌" 사용자
+ 원문의 언어	칭찬이 무엇을 향하는지

별점이나 날짜는 리뷰에 이미 달려 있는 정보입니다. 텍스트 군집과 함께 보기만 해도 같은 데이터가 훨씬 깊게 읽힙니다. 평균 별점에 가까운 사용자는 사실 거의 없었습니다. 사용자를 세분화해서 봐야 한다는 것은 별점에서도 똑같이 적용됩니다.

뷰티 앱 뿐 아니라 커머스, 금융, 교육, 헬스케어, SaaS처럼 리뷰와 VOC가 쌓이는 곳이라면 같은 방식으로 읽을 수 있습니다. 쌓인 리뷰를 평점표가 아니라 사용자 경험 지도로 바꿔보고 싶다면, 어피니티버블로 한 번 시도해보세요.

검색엔진은 우리 사이트를 어떻게 발견할까?

shushushu — Thu, 21 May 2026 07:50:10 +0900

들어가며

지난 편에서 프론트엔드 개발자가 왜 SEO를 챙겨야 하는지, 그리고 GEO라는 새로운 관점이 왜 필요해졌는지 이야기했어요. 이번 편에서는 좀 더 실전적인 이야기를 해볼게요.

검색엔진이 우리 사이트를 검색 결과에 보여주려면, 먼저 우리 사이트를 발견해야 하잖아요. 근데 이 "발견"이라는 과정이 생각보다 단순하지 않더라고요. SEO/GEO 분석 서비스를 만들면서 수많은 사이트를 들여다봤는데, 콘텐츠는 멀쩡한데 크롤러가 아예 접근을 못 하는 경우가 의외로 많았어요. 대기업 사이트에서도요.

이번 편에서는 검색엔진 크롤러가 우리 사이트를 발견하고 색인하는 과정을 프론트엔드 개발자 관점에서 풀어볼게요.

크롤링 → 인덱싱 → 랭킹, 이 흐름부터 잡자

검색엔진이 검색 결과를 보여주기까지는 크게 세 단계를 거쳐요.

크롤링(Crawling) — 크롤러가 웹을 돌아다니면서 페이지를 발견하고 수집하는 단계예요. 이때 크롤러는 링크를 따라가거나 sitemap을 참고해서 페이지를 찾아요.

인덱싱(Indexing) — 수집한 페이지의 내용을 분석해서 데이터베이스에 저장하는 단계예요. 페이지 제목이 뭔지, 어떤 주제인지, 어떤 키워드가 포함됐는지 등을 파악해서 정리해요.

랭킹(Ranking) — 사용자가 검색했을 때, 인덱스에 저장된 페이지들 중에서 가장 적합한 걸 골라서 순서대로 보여주는 단계예요.

여기서 핵심은, 크롤링이 안 되면 인덱싱도 안 되고, 인덱싱이 안 되면 랭킹에 아예 참여할 수 없다는 거예요. 아무리 좋은 콘텐츠를 만들어도 크롤러가 접근할 수 없으면 검색 결과에 나타나지 않아요. 그래서 기술적 SEO의 출발점은 항상 "크롤러가 우리 사이트에 제대로 접근할 수 있는가"예요.

robots.txt — 크롤러에게 보내는 첫 번째 신호

크롤러가 어떤 사이트를 방문하면 가장 먼저 확인하는 파일이 robots.txt예요. 사이트 루트에 위치하는 텍스트 파일인데, "이 사이트에서 어디를 탐색해도 되고, 어디는 안 되는지"를 크롤러에게 알려주는 역할이에요.

# 기본적인 robots.txt 예시


User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/
Sitemap: https://example.com/sitemap.xml

간단해 보이지만, 이 파일 하나가 SEO에 미치는 영향이 꽤 커요.

robots.txt가 없거나 잘못 설정된 경우

실제로 분석하다 보면 이런 케이스를 자주 만나요.

robots.txt 자체가 없는 경우 — 파일이 없더라도 크롤러는 일반적으로 모든 페이지에 접근 가능한 상태로 해석해요. 그래서 즉시 치명적인 문제가 생기지는 않을 수 있어요. 다만 robots.txt를 두면 sitemap 위치를 명시적으로 안내할 수 있고, 검색엔진 크롤러별 탐색 정책을 세밀하게 제어할 수 있어요. 특히 운영 환경에서는 관리 페이지나 불필요한 API 경로에 대한 크롤링을 제한하는 용도로 활용하는 경우가 많아요. 분석해본 사이트 중 꽤 많은 경우가 "파일 자체를 몰랐거나, 초기에 깜빡하고 그냥 운영 들어간" 경우였어요.

Disallow: /로 전체 차단한 경우 — 이건 진짜 치명적이에요. 모든 검색엔진 크롤러를 사이트 전체에서 차단하겠다는 의미예요. 실제로 이런 설정이 된 사이트가 있었는데, 검색 결과에서 완전히 사라져 있더라고요. 개발 환경에서 설정해둔 걸 운영에 그대로 올린 거였어요. 결과적으로 멀쩡한 사이트가 몇 달 동안 검색 노출이 0이었던 케이스예요.

핵심 디렉터리를 차단한 경우 — /product/나 /service/ 같은 중요한 경로를 Disallow에 넣어버리면, 정작 사용자에게 보여줘야 할 페이지가 검색 결과에서 빠져요. CMS 관련 경로를 막으려다가 실수로 전체 콘텐츠 경로를 막는 경우가 종종 있어요.

프론트엔드 개발자가 챙겨야 할 포인트

Next.js나 Nuxt 같은 프레임워크를 쓰고 있다면 robots.txt를 직접 관리해야 해요. Next.js의 경우 app/robots.ts에서 동적으로 생성할 수도 있고, public/robots.txt에 정적 파일로 놓을 수도 있어요.

// Next.js app/robots.ts 예시

import { MetadataRoute } from 'next'
export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: '*',
      allow: '/',
      disallow: ['/admin/', '/api/', '/private/'],
    },
    sitemap: 'https://example.com/sitemap.xml',
  }
}

중요한 건, 배포할 때 https://내도메인/robots.txt에 직접 접속해서 200 응답이 오는지, 내용이 의도한 대로 나오는지 눈으로 확인하는 거예요. 빌드 과정에서 빠지거나, 서버 설정에 따라 404가 뜨는 경우가 은근히 있거든요. 특히 배포 파이프라인 바꾼 직후에 한 번씩 꼭 확인하는 게 좋아요.

Sitemap — 사이트의 전체 지도를 건네주기

robots.txt가 "어디를 탐색해도 되는지"를 알려준다면, sitemap은 "우리 사이트에 어떤 페이지들이 있는지"를 목록으로 알려주는 역할이에요.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-03-15</lastmod>
  </url>
  <url>
    <loc>https://example.com/products</loc>
    <lastmod>2026-03-20</lastmod>
  </url>
</urlset>

크롤러는 링크를 따라가면서 페이지를 발견하기도 하지만, 사이트 규모가 커지면 링크만으로는 모든 페이지를 찾기 어려워요. sitemap이 있으면 크롤러가 사이트 전체 구조를 한눈에 파악할 수 있어서 크롤링 효율이 올라가요.

sitemap 관련 흔한 실수들

robots.txt에 sitemap 경로를 안 적은 경우 — sitemap 파일을 만들어놔도 robots.txt에서 경로를 알려주지 않으면 크롤러가 찾기 어려워요. Google Search Console에서 수동으로 제출할 수도 있지만, robots.txt에 한 줄 추가하는 게 가장 확실해요.

sitemap URL이 깨진 경우 — sitemap에 등록된 URL이 실제로 404나 500을 반환하면 크롤러 입장에서 사이트 품질이 낮아 보여요. 특히 콘텐츠를 삭제하거나 URL 구조를 바꿀 때 sitemap을 업데이트하는 걸 빠뜨리는 경우가 많아요. sitemap에 있는 URL은 200 응답이 오는 유효한 페이지여야 해요.

lastmod 날짜가 의미 없는 경우 — 모든 URL의 lastmod를 오늘 날짜로 일괄 설정해두는 사이트를 꽤 봤어요. 배포 스크립트에서 현재 날짜로 자동 채워지게 해둔 경우인데, 이러면 크롤러가 "어떤 페이지가 실제로 업데이트됐는지" 판단할 수 없어요. 실제 콘텐츠 수정 날짜를 넣는 게 중요해요.

대규모 사이트는 sitemap index를 쓰자

sitemap 하나에는 URL 50,000개까지만 넣을 수 있어요. 그 이상이면 sitemap을 여러 개로 나누고, sitemap index 파일로 묶어야 해요.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-posts.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>

Next.js에서는 app/sitemap.ts에서 동적으로 생성할 수 있어요. 페이지가 추가되거나 변경될 때 sitemap도 자동으로 갱신되게 만들면 관리 부담이 줄어요.

// Next.js app/sitemap.ts 예시

import { MetadataRoute } from 'next'
export default async function sitemap(): Promise {
  // DB나 CMS에서 동적 페이지 목록을 가져오는 경우
  const posts = await fetchPosts()
  const postEntries = posts.map((post) => ({
    url: `https://example.com/posts/${post.slug}`,
    lastModified: post.updatedAt,
  }))
  return [
    {
      url: 'https://example.com',
      lastModified: new Date('2026-01-15'), // 실제 최종 수정일을 넣어야 해요
    },
    {
      url: 'https://example.com/products',
      lastModified: new Date('2026-03-20'), // 실제 최종 수정일을 넣어야 해요
    },
    ...postEntries,
  ]
}

여기서 핵심은 lastModified에 실제 콘텐츠 수정 날짜를 넣는 거예요. 정적 페이지도 new Date()처럼 빌드 시점의 현재 날짜를 쓰면, 앞서 얘기한 "모든 URL을 오늘 날짜로 일괄 설정하는 실수"와 똑같은 문제가 생겨요. 동적 페이지처럼 실제 수정일을 명시하는 습관을 들이는 게 좋아요.

내부 링크 — 크롤러가 실제로 페이지를 탐색하는 경로

robots.txt와 sitemap 얘기를 했는데, 사실 크롤러가 새 페이지를 발견하는 가장 기본적인 방식은 링크를 타고 이동하는 것이에요. 이 부분을 빠뜨리면 크롤링 설명이 반쪽짜리가 돼요.

<a href> vs JavaScript 이벤트

검색 크롤러는 일반적으로 HTML의 <a href> 기반 링크를 가장 안정적으로 탐색해요. 반면 JavaScript 이벤트 기반 라우팅은 크롤러 종류와 렌더링 방식에 따라 링크로 인식되지 않거나 우선순위가 낮아질 수 있어요. 그래서 주요 탐색 경로는 가능하면 <a> 또는 프레임워크의 공식 Link 컴포넌트를 사용하는 것이 권장돼요.

SPA에서 라우팅을 처리할 때 이 부분을 놓치기 쉬워요. React Router나 Next.js의 <Link> 컴포넌트는 내부적으로 <a> 태그를 생성하기 때문에 괜찮지만, 커스텀 네비게이션을 만들 때는 확인이 필요해요.

// 크롤러가 안정적으로 따라갈 수 있는 링크
<a href="/products/123">상품 보기</a>
<Link href="/products/123">상품 보기</Link>

// 크롤러에 따라 인식되지 않거나 우선순위가 낮아질 수 있는 링크
<div onClick={() => router.push('/products/123')}>상품 보기</div>

네비게이션과 푸터는 크롤러 입장에서 사이트 전체 구조를 파악하는 중요한 단서이기도 해요. 주요 페이지들이 이 영역에서 링크로 연결돼 있다면 크롤러가 사이트 구조를 더 빠르게 이해할 수 있어요.

크롤 예산 — 크롤러에게도 한계가 있다

robots.txt와 sitemap, 내부 링크로 크롤러를 잘 불러들였다면, 이제는 크롤러가 사이트 안에서 헤매지 않도록 URL 구조를 정리할 차례예요.

"크롤 예산"이라는 말을 처음 들으면 다소 생소할 수 있어요. 간단히 말하면, Googlebot이 특정 사이트에 일정 기간 동안 할당하는 크롤링 자원의 한계예요. 사이트 규모, 서버 응답 속도, 링크 구조 등을 기반으로 결정돼요.

대부분의 소규모 사이트에서는 크롤 예산이 크게 문제가 안 돼요. 근데 페이지 수가 수만 개 이상이거나, URL 구조가 지저분한 경우엔 크롤 예산이 생각보다 빨리 소진돼요.

크롤 예산을 낭비하는 주요 원인들

무한한 URL 생성 — 필터링, 정렬, 검색 파라미터가 URL에 붙는 구조라면 조합이 기하급수적으로 늘어나요. ?sort=price&color=red&size=M 같은 조합이 무한히 생기면, 크롤러가 의미 없는 URL을 탐색하는 데 자원을 써버려요.

# 크롤 예산을 낭비하는 URL 패턴

/products?sort=price&page=1
/products?sort=price&page=2
/products?sort=name&page=1
/products?color=red&sort=price

이런 경우에는 우선 rel="canonical"로 원본 URL을 명확히 지정하고, 내부 링크와 sitemap도 표준 URL 기준으로 정리하는 것이 좋아요. 필요하다면 크롤링 부하를 줄이기 위해 일부 파라미터 URL에 대해 robots.txt로 접근을 제한할 수는 있지만, robots.txt는 canonical을 대신하는 수단은 아니에요. Google은 중복 URL 정리에는 canonical을, 크롤링 자체를 막을 때는 robots.txt를 구분해서 사용하도록 안내하고 있어요.

세션 ID가 URL에 포함된 경우 — ?sessionid=abc123 같은 값이 URL에 붙으면, 같은 페이지가 수백만 개의 URL로 인식돼요. 요즘은 세션을 쿠키로 관리하는 게 일반적이지만, 레거시 시스템에서 종종 보여요.

HTTPS와 리다이렉트 — 크롤러가 길을 잃지 않게

HTTP에서 HTTPS로의 리다이렉트

요즘 대부분의 사이트가 HTTPS를 쓰지만, HTTP로 접속했을 때 HTTPS로 제대로 리다이렉트되는지는 별도로 확인해야 해요. http://example.com으로 접속했을 때 https://example.com으로 301 리다이렉트가 돼야 해요.

이게 안 돼 있으면 검색엔진이 HTTP 버전과 HTTPS 버전을 별개의 페이지로 인식할 수 있어요. 같은 콘텐츠가 두 개의 URL에 존재하는 셈이 되니까 검색 노출이 분산돼요.

www vs non-www

비슷한 맥락에서, https://example.com과 https://www.example.com 중 하나로 통일해야 해요. 둘 다 접근 가능한 상태라면 크롤러는 두 개의 다른 사이트로 인식할 수 있거든요. 어느 쪽을 쓸지 결정하고, 나머지는 301로 리다이렉트해두세요.

리다이렉트 체인 문제

A → B → C → D 같은 식으로 리다이렉트가 여러 번 연쇄되는 경우가 있어요. Googlebot은 한 요청당 최대 10번의 리다이렉트 홉까지만 따라가고, 그걸 넘으면 Search Console의 페이지 색인 보고서에 리다이렉트 오류로 기록돼요. 한도 안이라도 홉이 늘어날수록 크롤링 효율이 떨어지고, 다른 크롤러는 더 일찍 포기할 수도 있어서 실무에서는 3~5회 이하로 유지하는 걸 목표로 잡는 게 안전해요. 리다이렉트는 가능하면 한 번에 최종 목적지로 보내는 게 좋아요.

리다이렉트 체인은 URL 구조를 바꿀 때 이전 리다이렉트를 그대로 두고 새 리다이렉트를 추가하는 과정이 반복되면서 생겨요. 주기적으로 점검하는 게 좋아요.

삭제된 페이지는 어떻게 처리할까

페이지를 삭제했을 때 그냥 404로 두는 경우가 많은데, 유사한 콘텐츠로 연결할 수 있다면 301 리다이렉트를 설정하는 게 좋아요. 대체 페이지가 아예 없다면 410(Gone)으로 응답하면 크롤러에게 "이 페이지는 의도적으로 삭제된 거야"라고 명확하게 알려줄 수 있어요. 404와 달리 410은 크롤러가 재방문을 빠르게 포기해서 크롤 예산 낭비를 줄여줘요.

Canonical 태그 — "이게 원본이야"라고 선언하기

프론트엔드 개발을 하다 보면 같은 콘텐츠가 여러 URL에서 접근 가능한 경우가 자주 생겨요.

이 세 URL이 사실상 같은 상품 목록을 보여주고 있다면, 검색엔진은 어떤 URL을 검색 결과에 보여줘야 할지 헷갈려해요. canonical 태그는 이 중 하나를 "원본"으로 지정하는 역할이에요.

<link rel="canonical" href="https://example.com/products" />

SPA에서 쿼리 파라미터를 많이 쓰거나, 필터링·정렬 기능이 URL에 반영되는 사이트라면 canonical 태그 관리가 특히 중요해요. 이걸 제대로 안 하면 검색엔진이 같은 페이지를 여러 개로 인식해서 크롤 예산을 낭비하게 돼요.

self-canonical의 중요성

페이지가 하나뿐이더라도 canonical 태그를 자기 자신을 가리키도록 설정하는 걸 권장해요. 이걸 "self-canonical"이라고 하는데, 검색엔진에게 "이 URL이 이 콘텐츠의 정식 주소야"라고 명확히 알려주는 거예요. 외부에서 쿼리 파라미터를 붙여서 링크할 때 생길 수 있는 중복 문제를 예방할 수 있어요.

CSR과 크롤링 — JavaScript 의존도를 점검하자

요즘 React, Vue, Angular 같은 프레임워크로 SPA를 많이 만드는데, CSR(Client-Side Rendering)로만 돌아가는 사이트는 크롤링에서 불리할 수 있어요.

Googlebot은 JavaScript 렌더링을 적극적으로 지원하는 대표적인 검색 크롤러예요. 다만 렌더링에 시간이 걸리고 크롤 예산을 더 많이 소모하기 때문에, CSR에만 의존하면 크롤링 효율이 떨어질 수 있어요. 반면 GPTBot, ClaudeBot, PerplexityBot 등 주요 AI 크롤러는 JavaScript 실행 범위가 제한적이거나 상세 동작이 공개되지 않았어요. Vercel과 MERJ가 한 달간 약 5억 7천만 건의 GPTBot 요청을 분석한 결과, JavaScript 실행 흔적이 전혀 발견되지 않았어요. 같은 분석에서 OAI-SearchBot, ChatGPT-User, ClaudeBot도 모두 JavaScript를 실행하지 않는 것으로 확인됐어요.

핵심 콘텐츠가 JavaScript 실행 없이는 HTML에 아예 존재하지 않는 구조라면, 크롤러가 그 콘텐츠를 인식하지 못할 수 있어요. Next.js의 SSR이나 SSG를 쓰는 이유가 여기에도 있는 거예요.

간단하게 확인하는 방법이 있어요. 브라우저에서 JavaScript를 끄고 우리 사이트에 접속해보는 거예요. 핵심 텍스트 콘텐츠가 보이는지, H1 태그가 있는지, 네비게이션 링크가 <a> 태그로 작동하는지 확인해보세요. 이걸로 크롤러가 보는 화면을 대략적으로 파악할 수 있어요.

설정 다 했으면, 실제로 잘 됐는지 확인하자

설정을 다 했다면, 실제로 크롤러가 우리 사이트를 어떻게 보고 있는지 확인하는 도구가 필요해요.

Google Search Console

Google Search Console(GSC)은 Google 크롤러 관점에서 사이트 상태를 확인할 수 있는 도구예요.

URL 검사 도구 — 특정 URL이 색인됐는지, 색인 안 됐다면 이유가 뭔지 확인할 수 있어요. "URL이 Google에 등록되어 있지 않음"이 뜨면서 "robots.txt에 의해 차단됨"이라고 나온다면, 앞서 말한 robots.txt 문제를 바로 잡아낼 수 있어요.

Sitemap 제출 및 상태 확인 — sitemap을 등록하고 나면 GSC에서 "읽힌 URL 수"가 나와요. 내가 등록한 URL 수와 크게 차이가 난다면 sitemap에 유효하지 않은 URL이 섞여 있거나, 크롤러가 접근 못 하는 페이지가 있다는 신호예요.

페이지 색인 보고서 — 색인된 페이지, 오류가 있는 페이지, 제외된 페이지를 한눈에 볼 수 있어요. (예전 명칭인 '커버리지 리포트'와 동일한 기능이에요.) "제외됨" 항목 중 "중복, Google이 표준 페이지를 선택함"이 많이 뜬다면 canonical 관리가 안 되고 있다는 신호예요.

Bing Webmaster Tools

Google이 GSC를 제공하듯, Bing에도 동일한 역할의 도구가 있어요. Bing Webmaster Tools(webmaster.bing.com)예요.

사이트를 등록하고 sitemap을 제출하면, Bing이 어떤 페이지를 색인했는지, 크롤링 오류는 없는지 확인할 수 있어요. 한국에서는 대부분 Bing은 아예 신경 안 쓰는 경우가 많은데, 뒤에서 다룰 ChatGPT 인용을 원한다면 여기도 한 번은 확인해두는 게 좋아요.

네이버 서치어드바이저

한국 서비스라면 네이버도 빠뜨릴 수 없어요. 네이버 서치어드바이저(searchadvisor.naver.com)는 네이버 검색 크롤러 관점에서 사이트 상태를 확인할 수 있는 도구예요.

GSC와 마찬가지로 sitemap을 등록하고, 크롤링 오류와 색인 상태를 확인할 수 있어요. 국내 B2C 서비스라면 특히 네이버 유입 비중이 높은 경우가 많아서, GSC만큼 주기적으로 들여다보는 게 좋아요.

네이버는 Googlebot과 별도로 Yeti라는 자체 크롤러를 운영해요. User-agent: *에 대해 이미 접근을 허용하고 있다면 별도 설정이 꼭 필요한 건 아니에요. 다만 검색엔진별로 robots.txt를 다르게 운영하고 있다면, Yeti가 의도치 않게 차단되고 있지는 않은지 함께 확인해보는 게 좋아요.

# 검색엔진별로 다르게 운영할 때 Yeti 명시적 허용 예시

User-agent: Yeti
Allow: /

새로운 서비스를 배포하거나 URL 구조를 바꾼 직후에는 GSC, Bing Webmaster Tools, 네이버 서치어드바이저를 한 번씩 열어보는 습관을 들이면 좋아요. 크롤러가 사이트를 어떻게 인식하고 있는지 검색엔진별로 직접 피드백을 받을 수 있거든요.

AI 검색 시대, 크롤러 전략도 달라졌다

1편에서 GEO 이야기를 했었는데, 크롤링 단계에서 바로 연결되는 부분이 있어요. 근데 여기서 한 가지 구분을 짚고 넘어가는 게 중요해요. AI와 크롤링의 관계는 사실 두 가지가 섞여 있거든요.

AI 봇은 이제 목적별로 분리되어 있다

최근 OpenAI와 Anthropic 모두 크롤러를 목적별로 분리해서 운영하기 시작했어요. 예전에는 "GPTBot 허용하면 AI에서 인용된다"는 식으로 단순하게 알려졌지만, 이제는 학습용과 검색 노출용이 완전히 다른 봇이에요.

OpenAI (ChatGPT)

GPTBot — AI 모델 학습 데이터 수집용
OAI-SearchBot — ChatGPT 검색 결과 노출용
ChatGPT-User — 사용자가 직접 요청했을 때 페이지 접근용

Anthropic (Claude)

ClaudeBot — AI 모델 학습 데이터 수집용
Claude-SearchBot — Claude 내 검색 결과 노출용
Claude-User — 사용자 질문에 답하기 위해 페이지 접근용

이 구분이 중요한 이유는, "학습에 쓰이는 건 싫지만, AI 검색에서 인용은 되고 싶다"는 선택이 이제 robots.txt로 분리 설정이 가능해졌기 때문이에요.

# 학습은 차단하고, 검색 노출은 허용하는 예시 (OpenAI)
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /

# Anthropic도 동일하게 분리 가능
User-agent: ClaudeBot
Disallow: /
User-agent: Claude-SearchBot
Allow: /

실시간 인용은 결국 어떤 검색엔진 기반이냐가 핵심

AI 서비스가 질문에 실시간으로 답할 때 인용하는 경로는 각 서비스마다 달라요.

ChatGPT — 웹 검색은 Bing 인덱스를 포함한 외부 검색 소스를 활용하는 것으로 알려져 있어요. 검색 노출 관점에서는 Bing 색인 상태를 함께 확인하는 게 유리해요.
Gemini — Google이 만든 서비스라 Google 검색 색인을 사용해요. 평소 Google SEO를 잘 하고 있다면 Gemini 인용에 유리해요.
Claude — Claude-SearchBot이 검색 노출을 담당해요. 어떤 검색 색인을 기반으로 하는지는 공개되지 않았어요.
Perplexity — 자체 크롤링과 여러 검색엔진을 혼합해서 사용해요.

정리하면 이래요.

AI 서비스 검색 노출용 봇 실시간 검색 기반 챙겨야 할 것

ChatGPT	OAI-SearchBot	Bing 포함 외부 소스	Bing SEO, Bing Webmaster Tools 확인
Gemini	별도 봇 없음 (Google 검색 직접 활용)	Google	Google SEO (기존 SEO와 동일)
Claude	Claude-SearchBot	미공개	검색엔진 SEO 전반
Perplexity	PerplexityBot	자체 + 복수 검색엔진	검색 노출 전반 + 콘텐츠 구조

한국 서비스들이 대부분 Google SEO만 신경 쓰는데, ChatGPT 인용까지 원한다면 Bing 색인 상태도 별도로 확인해볼 필요가 있어요. 위에서 소개한 Bing Webmaster Tools에서 바로 확인할 수 있어요.

"GPTBot 허용하면 AI가 우리 콘텐츠를 인용한다"는 단순화는 이제 맞지 않아요. 학습 데이터 수집과 실시간 검색 노출은 다른 봇이 담당하고, 실시간 인용은 결국 각 서비스가 기반으로 삼는 검색엔진 SEO가 핵심이에요.

마치며

이번 편에서 다룬 내용들은 하나하나는 어렵지 않아요. robots.txt 한 줄, sitemap 경로 한 줄, canonical 태그 한 줄. 근데 분석 서비스를 만들면서 수많은 사이트를 들여다봤을 때 공통적으로 느낀 게 있어요. 이 "한 줄"들이 빠져 있는 경우가 생각보다 훨씬 많다는 거예요. 콘텐츠는 정성껏 만들었는데, 크롤러는 그 페이지에 닿지도 못하는 상황이요.

결국 SEO와 GEO의 출발점은 크게 다르지 않아요. 검색엔진이든 AI 서비스든, 먼저 우리 사이트를 안정적으로 발견하고 이해할 수 있어야 다음 단계로 넘어갈 수 있어요. robots.txt, sitemap, 내부 링크, canonical 같은 기술적 기반은 지금도 가장 중요한 출발점이에요.

좋은 콘텐츠를 만드는 것만큼, 그 콘텐츠가 크롤러에게 제대로 전달되는 구조를 만드는 일 역시 프론트엔드 개발자의 중요한 역할이라고 생각해요.

다음 편에서는 페이지가 발견된 이후, 검색엔진과 AI가 콘텐츠를 어떻게 해석하고 인용하는지, 그리고 어떤 구조가 GEO 관점에서 더 유리한지 살펴보려고 해요.

참고 자료

Google Search Central — 크롤링 및 색인 생성

robots.txt 표준 — RFC 9309

Sitemaps.org — Sitemap 프로토콜

Next.js Docs — Metadata Files: robots.txt

OpenAI — Overview of OpenAI Crawlers (GPTBot, OAI-SearchBot, ChatGPT-User)

OpenAI Help Center — ChatGPT Search

Anthropic — Does Anthropic crawl data from the web? (ClaudeBot, Claude-SearchBot, Claude-User)

Google AI for Developers — Grounding with Google Search

Google Search Central Blog — Inside Googlebot: demystifying crawling, fetching, and the bytes we process

Vercel Blog — The rise of the AI crawler

Perplexity Help Center — How does Perplexity work?

네이버 서치어드바이저 — 웹마스터 도구

이 글은 https://tech.pxd.co.kr/ 에서도 보실 수 있습니다.