pxd story

Core Web Vitals: 성능이 검색 노출에 미치는 실제 영향

shushushu — Mon, 10 Aug 2026 07:50:42 +0900

들어가며

이 시리즈를 쓰면서 "프론트엔드 개발자가 SEO를 왜 챙겨야 하는가"를 다양한 각도에서 다뤄왔어요. robots.txt 설정부터 헤딩 구조, 구조화 데이터까지. 근데 솔직히 말하면, 이번 편이 프론트엔드 개발자에게는 가장 자연스러운 주제일 거예요.

웹 성능 최적화.

이미지 최적화하고, 번들 사이즈 줄이고, 레이아웃 시프트 잡고 — 이미 하고 있는 일이잖아요. 근데 이 작업이 Lighthouse 점수를 올리는 것 이상으로, 검색 노출과 사용자 경험에 실질적인 영향을 미치고 있다는 걸 아는 것과 모르는 것은 다르거든요.

이번 편에서는 Core Web Vitals가 검색 노출에 실제로 어떤 영향을 미치는지, 그리고 4편에서 다뤘던 Google의 AI 가이드와 어떻게 연결되는지를 정리해볼게요.

Core Web Vitals — 세 가지 지표

Core Web Vitals는 Google이 사용자 경험을 측정하기 위해 정의한 세 가지 핵심 지표예요. 2024년 3월에 FID(First Input Delay)가 INP(Interaction to Next Paint)로 교체되면서 현재 구성은 이래요.

LCP (Largest Contentful Paint) — 로딩 속도

페이지에서 가장 큰 콘텐츠 요소(주로 히어로 이미지, 비디오, 큰 텍스트 블록)가 화면에 렌더링되기까지 걸리는 시간이에요.

Good: 2.5초 이하
Needs Improvement: 2.5초 ~ 4초
Poor: 4초 초과

2025 Web Almanac 기준으로 모바일 페이지의 62%만 Good 등급을 달성하고 있어서, 세 지표 중 가장 통과하기 어려운 항목이에요.

INP (Interaction to Next Paint) — 응답성

사용자의 인터랙션(클릭, 탭, 키보드 입력)에 페이지가 시각적으로 반응하기까지 걸리는 시간이에요. 이전의 FID가 첫 번째 인터랙션만 측정했다면, INP는 페이지 전체 라이프사이클 동안의 모든 인터랙션을 측정하고 그중 가장 느린 것을 보고해요.

Good: 200ms 이하
Needs Improvement: 200ms ~ 500ms
Poor: 500ms 초과

2025 Web Almanac 기준 모바일 페이지의 약 77%가 Good 등급을 달성하고 있어요. FID 시절에 문제없던 사이트가 INP에서는 실패하는 경우가 꽤 있어요. 첫 클릭은 빠른데 필터 패널이나 폼 제출이 800ms씩 걸리는 사이트가 전형적인 사례예요.

CLS (Cumulative Layout Shift) — 시각적 안정성

페이지 로딩 중에 콘텐츠가 예상치 못하게 밀려나는 정도를 수치화한 거예요.

Good: 0.1 이하
Needs Improvement: 0.1 ~ 0.25
Poor: 0.25 초과

세 지표 중 통과율이 가장 높아요 (모바일 페이지의 81%). 하지만 광고, 쿠키 배너, 웹폰트 로딩 같은 요소 때문에 의외의 곳에서 문제가 생기기도 해요.

CWV는 검색 순위에 얼마나 영향을 미치는가

보조 평가 신호로서의 CWV

이 부분을 정확히 이해하는 게 중요해요. Core Web Vitals는 Google의 랭킹 요소 중 하나이지만, 콘텐츠 관련성이나 백링크 같은 핵심 요소를 대체하지는 않아요. Google도 페이지 경험 신호가 콘텐츠 관련성을 대체하지 않는다고 설명하면서, 경쟁력이 비슷한 페이지 사이에서 추가적인 평가 요소로 작동할 수 있다고 말해요.

업계에서도 CWV를 순위를 결정하는 핵심 요소라기보다는, 비슷한 품질의 페이지 사이에서 우열을 가르는 보조 신호로 보는 견해가 많아요. 흔히 쓰는 "타이브레이커(tiebreaker)" 비유가 이 역할을 잘 보여줘요 — 비슷한 품질의 콘텐츠가 경쟁할 때, 성능이 좋은 페이지가 우위를 가져가는 거예요. (단, "타이브레이커"는 Google 공식 용어가 아니라 SEO 업계에서 흔히 쓰는 비유라는 점은 알아두세요.)

콘텐츠 관련성 + 권위성 (1순위)
    └── 비슷한 품질의 페이지들이 경쟁
        └── CWV가 타이브레이커로 작동
            └── 성능이 좋은 페이지가 우위

하지만 무시할 수 있는 수준은 아니에요

"보조 신호면 대수롭지 않은 거 아니야?"라고 생각할 수 있는데, 실제 비즈니스 임팩트를 보면 이야기가 달라요.

Vodafone은 LCP를 31% 개선한 뒤 판매가 8% 증가했다고 보고했어요(web.dev 케이스 스터디). Pinterest도 성능 개선 이후 검색 트래픽 증가를 보고한 바 있고요. 좀 더 일반적인 수치로는, 페이지 로드 시간이 1초에서 3초로 늘어나면 이탈 확률이 약 32% 증가한다는 Google의 분석이 잘 알려져 있어요.

특히 경쟁이 치열한 키워드에서는 CWV가 실질적인 차이를 만들어요. 같은 주제로 비슷한 품질의 콘텐츠를 가진 10개 사이트가 경쟁한다면, CWV를 통과한 사이트가 유리한 위치를 가져가거든요.

프론트엔드 개발자를 위한 CWV 최적화 포인트

이미 알고 있는 내용이 많겠지만, SEO 맥락에서 우선순위를 다시 정리해볼게요.

LCP 개선 — 가장 임팩트가 큰 항목

LCP는 SEO와 비즈니스 매트릭 모두에서 가장 직접적인 영향을 미치는 지표예요.

최적화에 들어가기 전에, LCP가 어디서 시간을 잡아먹는지부터 분해해보면 진단이 쉬워져요. LCP는 크게 네 구간으로 나뉘어요.

TTFB — 서버가 첫 바이트를 응답하기까지의 시간
리소스 로드 지연(Resource Load Delay) — LCP 리소스를 발견해서 요청을 시작하기까지 걸린 시간
리소스 로드 시간(Resource Load Time) — LCP 리소스를 실제로 내려받는 데 걸린 시간
요소 렌더 지연(Element Render Delay) — 다 받아놓고도 화면에 그려지기까지 걸린 시간

내 LCP의 병목이 이 중 어디인지 알면(Chrome DevTools Performance 패널에서 구간별로 확인 가능), 아래 조치 중 무엇을 우선할지 정할 수 있어요. 예를 들어 로드 지연이 크면 프리로드·fetchpriority가, TTFB가 크면 서버·CDN 쪽이 답이에요.

LCP 이미지에는 lazy loading을 걸지 마세요. 히어로 이미지처럼 뷰포트에 바로 보이는 요소에 loading="lazy"를 걸면 오히려 LCP가 느려져요. LCP 요소는 fetchpriority="high"로 우선 로딩해야 해요.

<!-- LCP 이미지 — lazy loading 사용 금지 -->
<img
  src="/hero.webp"
  alt="히어로 이미지"
  fetchpriority="high"
  width="1200"
  height="600"
/>

<!-- 스크롤 아래 이미지 — lazy loading 적용 -->
<img
  src="/below-fold.webp"
  alt="하단 이미지"
  loading="lazy"
  width="800"
  height="400"
/>

이미지 포맷은 WebP 또는 AVIF로. 같은 품질에서 JPEG 대비 25~50% 용량을 줄일 수 있어요. Next.js를 쓰고 있다면 next/image 컴포넌트가 자동으로 WebP 변환을 해주고요.

크리티컬 리소스를 프리로드하세요. LCP 이미지, 중요한 폰트, 크리티컬 CSS는 <link rel="preload">로 브라우저에게 우선순위를 알려줘야 해요.

TTFB(서버 응답 시간)를 800ms 이내로. 서버가 느리면 아무리 프론트를 최적화해도 LCP가 안 나와요. CDN 활용, 서버 사이드 캐싱, Brotli 압축이 기본이에요.

INP 개선 — 가장 잡기 어려운 항목

INP는 FID보다 훨씬 엄격해서, 이전에 문제없던 사이트도 실패할 수 있어요.

긴 JavaScript 태스크를 분할하세요. 50ms 이상의 Long Task는 메인 스레드를 차단해서 INP를 악화시켜요. setTimeout, requestIdleCallback, 또는 scheduler.postTask API로 태스크를 분할할 수 있어요.

서드파티 스크립트를 점검하세요. 채팅 위젯, 개인화 엔진, 태그 매니저 같은 서드파티 스크립트가 INP의 주범인 경우가 많아요. 페이지 초기 로드 이후에 로딩하도록 지연시키는 것만으로도 크게 개선되는 경우가 있어요.

DOM 크기를 줄이세요. 과도하게 큰 DOM은 렌더링과 인터랙션 성능 모두에 영향을 줄 수 있어요. Lighthouse도 DOM 크기를 점검 대상으로 보고, 총 노드 약 1,500개·최대 깊이 32레벨·부모 노드당 자식 60개를 경고 기준으로 삼아요. (Google의 공식 랭킹 권장사항이 아니라 Lighthouse 감사 기준이라는 점은 참고하세요.)

bfcache(뒤로/앞으로 가기 캐시)를 깨뜨리지 마세요. 사용자가 뒤로/앞으로 가기를 누를 때 페이지를 통째로 메모리에서 복원해주는 캐시예요. 이게 작동하면 재방문 내비게이션이 사실상 즉시 이뤄져 사용자 체감 성능이 크게 향상돼요. 그런데 unload 이벤트 핸들러나 Cache-Control: no-store 같은 설정이 있으면 bfcache가 비활성화돼요. unload 대신 pagehide/pageshow를 쓰고, DevTools의 Application 패널에서 bfcache 적격 여부를 점검하세요.

CLS 개선 — 가장 기본적이지만 놓치기 쉬운 항목

이미지와 비디오에 width/height를 명시하세요. 이게 CLS 개선의 가장 임팩트 있는 단일 조치예요. 크기가 지정되지 않은 이미지가 로딩되면서 아래 콘텐츠를 밀어내는 게 CLS의 가장 흔한 원인이에요.

<!-- CLS 유발 — 크기 미지정 -->
<img src="/product.webp" alt="상품 이미지" />

<!-- CLS 방지 — 크기 명시 -->
<img src="/product.webp" alt="상품 이미지" width="400" height="300" />

웹폰트 로딩 전략을 세우세요. 폰트가 교체되면서 텍스트가 리플로우되는 것도 CLS의 원인이에요. font-display: swap 또는 font-display: optional을 설정하고, 가능하면 폰트를 셀프 호스팅해서 로딩 시간을 줄이세요.

동적으로 삽입되는 요소에 공간을 예약하세요. 광고 슬롯, 쿠키 배너, 알림 바 같은 요소가 로딩 후 삽입되면 레이아웃이 밀려요. CSS로 미리 공간을 잡아두면 예방할 수 있어요.

측정은 필드 데이터로

CWV 최적화에서 자주 놓치는 포인트가 하나 있어요. Google은 Lighthouse 같은 lab 데이터가 아니라, 실제 사용자의 필드 데이터(CrUX)로 CWV를 평가해요.

개발 환경의 고성능 맥북에서 Lighthouse 점수가 100점이어도, 실제 사용자들의 3G 네트워크 + 저가 안드로이드 폰에서 측정된 필드 데이터가 나쁘면 Google은 그걸 기준으로 봐요. 75번째 백분위수(p75)가 기준이라서, 전체 방문의 75%가 Good 기준을 충족해야 해요.

측정 도구

Google Search Console — "환경" > "Core Web Vitals" 탭에서 필드 데이터 기반 상태를 확인할 수 있어요. Google이 실제로 사용하는 데이터예요.
PageSpeed Insights — 필드 데이터(CrUX)와 lab 데이터를 모두 보여줘요. 개선 포인트 진단에 유용해요.
Chrome DevTools — Performance 패널 — 페이지를 사용하면서 LCP·INP·CLS를 실시간으로 보고, LCP 구간 분해와 INP를 유발한 인터랙션까지 추적할 수 있어요. (기존 Web Vitals 확장 프로그램은 2025년 1월 지원이 종료되고 기능이 DevTools로 통합됐어요.)

SEO 관점에서의 판단은 항상 Search Console의 필드 데이터를 기준으로 하세요.

CWV와 AI 검색의 관계

4편에서 다뤘던 Google의 AI 가이드에서도 이 부분을 짚고 있어요.

> "사이트에 방문한 사용자에게 좋은 페이지 경험(good page experience)을 제공하세요. 여기에는 모든 디바이스에서 사이트가 잘 표시되고, 지연 시간이 적으며, 메인 콘텐츠를 다른 요소들과 쉽게 구분할 수 있는 것이 포함됩니다."

Google의 AI 기능(AI Overviews, AI Mode)은 기존 검색 인덱스를 기반으로 작동해요. 즉, 검색 인덱스에서 높은 평가를 받는 페이지가 AI 응답에서도 인용될 가능성이 높아요. CWV가 직접적으로 AI 인용을 결정하지는 않지만, SEO 품질의 일부로서 간접적으로 영향을 미치는 구조예요.

이건 이 시리즈의 핵심 메시지와 같아요 — GEO는 SEO의 확장이에요. SEO의 기본기(CWV 포함)가 탄탄해야 AI 검색에서도 가능성이 생겨요.

실제로 GEONIQ 리포트에서 다양한 업종의 사이트를 분석할 때도, 성능 지표가 좋지 않은 페이지는 콘텐츠 품질과 무관하게 전반적인 평가가 낮아지는 경향이 관찰되기도 했어요. 성능은 단순한 속도 이슈가 아니라, 페이지의 전반적인 관리 품질을 나타내는 간접 신호로 작동하는 거예요.

정리 — CWV 최적화 우선순위

지표 기준통과율 (모바일)최우선 조치

LCP	≤ 2.5초	62%	LCP 이미지 fetchpriority="high", WebP/AVIF, 프리로드, TTFB 800ms 이내
INP	≤ 200ms	77%	Long Task 분할, 서드파티 스크립트 지연 로딩, DOM 크기 축소
CLS	≤ 0.1	81%	이미지/비디오 width·height 명시, font-display 설정, 동적 요소 공간 예약

마치며

CWV 최적화는 프론트엔드 개발자가 가장 잘 할 수 있는 SEO 작업이에요. 이미 하고 있는 성능 최적화가 곧 검색 노출의 기반이 되고, 그 기반이 AI 검색에서의 가능성으로 이어져요.

다만 한 가지 명심할 건, CWV만으로 검색 순위가 크게 오르지는 않는다는 거예요. SEO 업계에서는 흔히 "타이브레이커"에 비유하기도 해요 — 콘텐츠 품질과 기술적 SEO가 갖춰진 상태에서 CWV가 경쟁에서의 우위를 만들어주는 거예요. 순서가 중요해요.

다음 편에서는 이 시리즈의 마지막 주제를 다뤄볼 예정이에요. AI 크롤러 시대의 접근 제어 — GPTBot, ClaudeBot, PerplexityBot을 어떻게 다룰 것인가, 그리고 Google이 말하는 "Agentic Experiences"까지 포함해서 시리즈를 마무리할게요.

참고 자료

상품 리뷰 AI 요약은 구매 결정을 어떻게 도울 수 있을까

無異 — Thu, 6 Aug 2026 19:17:04 +0900

온라인에서 상품을 고를 때는 직접 만져 볼 수 없으니, 결정하기 어려운 점이 많습니다. 신발의 발볼이나 화장품의 사용감, 향처럼 상품 설명만으로는 가늠하기 어려운 것들요. 그래서 먼저 써본 사람이 남긴 리뷰가 중요한 정보가 됩니다.

리뷰에서 필요한 것은 판매자가 말하는 장점의 반복만은 아닙니다. 내가 미처 생각하지 못한 조건과 경험을 먼저 아는 일도 구매 판단에 도움이 됩니다. 어떤 문제는 나에게도 치명적이라 구매를 멈추게 하고, 어떤 문제는 내 조건과 무관하거나 감수할 만해서 오히려 선택을 확신하게 합니다. 판매자에게도 같은 정보가 유용합니다. 누구에게나 맞는다고 말하는 대신, 어떤 사람에게 특히 잘 맞는지를 보여줄 수 있으니까요.

예전의 리뷰 화면은 평균 별점이나 별점 분포처럼, 리뷰를 정량적인 지표로 보여주는 데 주로 머물렀습니다. 이 지표는 만족도의 크기를 빠르게 알려주지만, 왜 만족했는지와 어떤 조건에서 의견이 갈리는지까지 담기는 어렵습니다. 리뷰가 구매 판단에서 차지하는 비중이 커지면서, 이제는 AI로 정성적인 내용까지 정리해 보여주기 시작했습니다. 수천 건의 리뷰를 한 문장과 태그로 정리하거나, 자주 언급된 특징을 칩으로 보여주는 방식을 주로 사용합니다

네이버 스토어 AI리뷰요약

홈페이지 AI리뷰요약

이런 AI 요약은 상품이 대체로 어떤 평가를 받는지 빠르게 파악하게 해줍니다. 리뷰를 처음부터 읽기 전에 살펴볼 첫 화면으로 충분히 유용합니다. 키워드를 누르면 관련 리뷰만 골라 읽을 수도 있습니다. 다만 그 목록을 읽으며 서로 다른 조건에서 나온 의견이 어떻게 갈리는지까지 파악하려면, 다시 여러 리뷰를 넘나들어야 합니다.

그래서 필요한 것은 요약을 한 문장 더 정교하게 만드는 일보다, 리뷰 전체를 한눈에 조망할 수 있는 목차이지 않을까 생각합니다. 해당 상품에 중요한 속성이 무엇인지를 보여주고 그 안의 서로 다른 의견이 어떻게 나뉘는지 보고, 필요할 때만 원문까지 펼쳐 보는 계층 말입니다.

뉴발란스 운동화 AI 리뷰 요약에는 "가볍고 편안한 여름 운동화, 디자인도 예뻐요!"라고 적혀 있고 태그도 모두 긍정적이었습니다. 요약이 틀린 건 아닙니다. 그런데 같은 페이지의 상품문의 탭에는 사이즈에 대한 문의가 반복되고 있었습니다. 답변도 인상적입니다. "발 모양과 너비, 발등 높이가 모두 달라 추천이 어렵습니다. 리뷰를 참고해 주세요."

리뷰를 참고하라는 말이 무성의해 보이진 않습니다. 실제로 답은 리뷰 안에 있으니까요. 다만 그 많은 리뷰 중 어디에 있는지를 알려줄 방법이 없었던 것 같습니다.

만족도와 구매 판단은 다른 층이다

이 장면이 흥미로웠던 건, 별점과 요약이 제품이 좋은지를 말해주는 데 반해 사람들이 알고 싶어 한 건 나에게 맞는지였기 때문입니다. 둘은 같은 리뷰에서 나오지만 서로 다른 질문입니다. 높은 별점은 "이 신발은 좋다"는 뜻이지 "당신 발에 맞는다"는 뜻은 아닙니다. 요약이 긍정 위주인 것도 자연스러운 반영입니다. 다만 그 요약을 읽고도 사람들은 여전히 질문을 남깁니다.

어피니티버블처럼 모든 리뷰를 한번에 펼쳐 보면 리뷰를 찾는 데 도움이 될지 궁금해서 최근 리뷰를 속성별로 묶어봤습니다. 그냥 주제별로 묶는 대신 ABSA(속성별 감성분석) API를 이용해 분석한 후 속성별로 드릴다운하여 세부 내용을 표시했습니다.

리뷰 속성별 상세 리뷰 목차

착화감과 디자인은 거의 전량 긍정이었습니다. 의견이 갈린 곳은 사이즈 하나였는데요. 새 요약은 "사이즈가 생각보다 크게 나왔다"는 의견을 자동으로 포함해, 구매 전에 살펴볼 조건이 무엇인지 알려줍니다. 그리고 아래 리뷰 목차에서는 정사이즈·반 사이즈 작게 구매·발볼처럼 의견이 나뉜 맥락과 건수를 한눈에 확인할 수 있습니다.

“나는 ○○인데” - 구매자의 조건까지 담은 리뷰

사이즈를 열어보면 정사이즈가 편했다는 의견과 반 사이즈 작게 사야 맞았다는 의견이 함께 나옵니다. 크게 나왔다는 사람도 있고, 발볼이 넓어도 편했다는 사람도, 다른 모델보다 좁게 느꼈다는 사람도 있습니다. 그래서 이 상품을 두고 "반 사이즈 작게 사세요"라고 한 줄로 안내하기는 어렵습니다. 의견이 엇갈리는 이유는 사이즈 자체보다 발 모양과 평소 신는 기준에 있을 수 있기 때문입니다. 그 기준을 직접 밝힌 리뷰는 특히 유용합니다.

"늘 반 업해서 신는 편인데, 이건 원래 사이즈로 했는데도 반 업한 느낌이에요"

"반 업해서 신는 편"이라는 전제가 있어야 "이 모델은 크게 나왔다"는 결론을 내 상황으로 번역할 수 있습니다. 앞서 인용한 문의도 같은 구조였습니다. 다른 모델에서 맞았던 사이즈를 자기 기준점으로 먼저 말했고, 리뷰에서 본 정보를 자기 케이스로 번역하기 어려워 다시 물은 셈입니다.

다른 카테고리에서도 비슷할지 궁금해서 다른 화장품 상품 리뷰도 확인해 봤습니다. 한 클렌저의 성분 항목에서 "민감한 피부인데 트러블 없이 잘 맞아요"를 열어봤는데요.

칩을 펼친 리뷰

펼쳐진 리뷰 여섯 건이 모두 자기 피부 조건을 먼저 밝히고 있었습니다.

"민감성이라 잘 맞는 화장품이 잘 없었는데 순하게 잘 맞아요"
"지복합성이라 오일 제품은 선호하지 않는데, 이 제품은 순해서 트러블도 없고"
"아이가 여드름 때문에 매일 관리하느라… 아무래도 민감한 피부라서 신경 쓰네요"

신발은 발 모양, 클렌징은 피부 타입이었습니다. 카테고리마다 이름은 다르지만, 리뷰어가 "나는 ○○인데"라고 밝히며 판단하는 축이 어디에나 있었습니다.

리뷰 전체를 한 번에 보는 버블

리뷰 목차가 꼭 목록 모양일 필요는 없습니다. 속성과 그 안의 세부 의견을 버블로 묶으면, 어떤 주제가 큰 비중을 차지하는지와 그 안에서 어떤 의견이 나뉘는지를 한 화면에서 볼 수 있습니다.

리뷰 버블

예를 들어 이 제품에서는 향기 버블이 가장 크게 보이지만, 그 안에는 "달콤한 향이 마음에 들어요"와 "향이 너무 강해서 머리가 아파요"가 함께 있습니다. 요약 한 줄이나 필터 결과 목록만으로는 지나치기 쉽습니다. 버블을 먼저 보면 전체 지형을 훑고, 궁금한 의견만 골라 원문을 확인할 수 있습니다.

요약은 입구, 리뷰 목차는 전체

요약은 많은 리뷰를 처음 만나는 좋은 입구입니다. 하지만 한 문장은 결국 대표 의견 하나를 고를 수밖에 없습니다. 이 화면의 장점은 그다음에 있습니다. AI가 추린 속성을 계층적으로 펼쳐 보여주기 때문에, 구매자는 한 화면에서 리뷰 전체의 지형을 보고 자신에게 중요한 갈래만 열어볼 수 있습니다. 모든 리뷰를 요약문 하나에 담으려 하지 않고, 전체를 훑은 뒤 필요한 정보로 내려가는 경로를 만드는 것입니다.

그래서 어떤 화면이면 좋을까

여기까지 보고 정리한 건 이런 구조였습니다.

리뷰 전체를 속성 → 갈라지는 의견 → 원문 순으로 계층화해 펼쳐 볼 수 있게 했습니다. 먼저 전체에서 어떤 조건들이 언급됐는지 한눈에 보고, "사이즈"를 누르면 정사이즈·반업·발볼처럼 의견이 갈리는 지점을 확인합니다.

별점 순이나 최신순이 아니라 조건 축으로 정렬했습니다. "도움이 돼요" 순으로 정렬하면 많은 사람에게 유용한 리뷰가 위로 오지만, 내 조건과 맞는 리뷰가 위로 오지는 않거든요.

긍정과 부정을 같은 자리에 뒀습니다. 향 관련 버블에서 봤듯, 같은 속성 안에서도 취향에 따라 평가가 갈릴 수 있기 때문입니다.

요약을 대체하지 않고, 그 아래에 리뷰 목차를 뒀습니다. 요약은 "이 제품이 대체로 어떤가"를 빠르게 알려주는 좋은 장치입니다. 그다음에는 전체 리뷰의 지형을 한눈에 보고, "나에게 맞는가"에 필요한 항목만 펼쳐 볼 수 있어야 한다고 봤습니다.

리뷰는 이미 답을 갖고 있다

구매자는 상품이 좋은지 몰라서만 구매를 미루는 것이 아닙니다. 나의 조건에 맞는지 판단할 정보를 충분히 찾지 못할 때 망설입니다. 그런데 그런 유용한 사용 경험 정보가 리뷰에 생각보다 많이 남아 있습니다. 다만 현재의 리뷰 구조나 AI 요약, 키워드 방식으로는 내가 궁금해 하는 리뷰를 찾기 어렵습니다. 요약한 상품의 장점을 보여주는 것에서 내가 중요하게 생각하는 조건을 찾을 수 있는 구조로 리뷰를 제공해 보면 좋겠습니다.

AI와 협업하는 최선의 워크플로우 찾기

Yejin.lee — Thu, 6 Aug 2026 07:50:31 +0900

들어가며

AI에게 바이브 코딩으로 AI툴 개발을 시킵니다. 또 하나의 창에서는 사용자 리서치 정리도 시켰습니다. 또 다른 에이전트에게는 경쟁사 분석도 시킵니다. 작업물 3개를 세 개를 동시에 돌렸으니 생산성은 마땅히 3배가 되어야 합니다. 하지만, 막상 결과물을 받으면 어디부터 봐야 할지 멍하니 고민이 됩니다. 결과물을 훑으며 "괜찮은데?" 했지만, 곧 불안해졌습니다. 이게 진짜 괜찮은 건지, 그냥 그럴듯해 보여서 괜찮다고 느끼는 건지, 구분이 안되기 시작했습니다.

왜 AI에게 일을 시키면 오히려 더 피곤하게 느껴질까요? AI와 함께 일하는 상황이 늘어나는 지금,
AI와 협업하면서 발생하는 어려움을 해결해 나가는 최선의 워크플로우는 무엇일지 고민해 보았습니다.

왜 우리는 AI 결과물 앞에서 판단이 흐려지는가?

우리가 경험적으로 걱정하는 문제들에 대한 기존 연구들을 하나씩 살펴보겠습니다.
Microsoft Research와 CMU 연구진들이 진행한 연구에서, 우리는 왜 AI 결과물을 받아보면서 발생하는 현상들을 확인할 수 있었습니다.

Microsoft Research와 CMU 연구진은 319명의 지식노동자로부터 생성형 AI를 사용한 실제 업무 사례 936개를 수집했습니다. 연구 결과, AI에 대한 신뢰가 높을수록 비판적 사고를 덜 했다고 보고한 반면, 해당 과업을 스스로 수행할 수 있다는 자신감이 높을수록 더 많은 비판적 사고를 했다고 보고했습니다.

자신이 작업에 관한 자신감을 가지고 과업에 참여할수록 AI 결과를 더 적극적으로 검토할 가능성이 있다는 것입니다. 실무에 대입해서 생각해 봅니다. “AI가 대충 잘 뽑아주겠지”라고 생각하며 화면 설계를 시키면 결과물을 검토하기보다 수락하는 태도에 가까워지는 반면. 내가 작업에서 “이 플로우에서는 사용자가 이탈하는 지점이 있을 수 있다”는 가설을 가지고 요청했다면 똑같이 AI가 만들어준 결과물을 보더라도 더 깊게 비판적으로 들여다보게 된다는 것입니다.

우리의 문제는, 위험이 낮은 일상적 작업에서 점점 전자 쪽으로 기울게 된다는 것입니다. 매일 반복되는 작은 판단들에서 AI를 믿고 활용하다 보면, 검증을 건너뛰는 습관이 자연스럽게 쌓이게 되고, 정작 중요한 결정 앞에서 "이 결과물이 정말 맞나?"를 묻는 습관이 점점 사라지게 되겠죠. 그 점을 경계해야 합니다.

AI는 생성 부담을 줄이지만 평가 부담을 남긴다

우리는 직접 와이어프레임을 그리면 왜 이 요소를 여기에 놓았는지 알고 있습니다. 정보 구조를 생각하고, 시선 흐름을 고려하고, 우선순위를 정하는 과정이 내 안에서 일어났기 때문입니다. 반대로 AI가 완성된 레이아웃을 주면 나는 결과에서 출발해 그 의도를 역으로 추론해야 합니다. “왜 이 버튼이 여기 있지?”, “이 정보가 먼저 나와야 하는 이유는 뭐지?”를 처음부터 복원해야 합니다. 같은 결과물이어도 내가 가지고 있는 맥락의 양은 다를 수밖에 없습니다. 따라서, 우리가 작업물을 직접 만들면 맥락을 이해하기가 쉬운데, 완성된 걸 받으면 유독 더 검수하기가 힘이 듭니다.

Microsoft Research는 "생성형 AI가 사람의 역할을 직접 만드는 사람에서 결과를 평가하는 사람으로 이동시킨다" 라고 설명합니다.
이를 production-to-evaluation shift, 즉 생성에서 평가로의 이동이라고 부릅니다. AI를 활용한 작업이 늘어날 수록 기존 맥락에 맞는지, 빠진 조건은 없는지를 판단하는 일이 중요해진다는 것입니다.

문제는 직접 만드는 역할에서 평가하는 역할로 바뀌면서, 역설적으로 평가에 드는 인지 부하 또한 함께 늘어난다는 것입니다. AI의 생성 속도만큼 사람의 이해와 판단 속도가 빨라질 수는 없기 때문입니다. 또한, 비슷한 이유를 이미 1978년 Slamecka와 Graf가 발표한 연구에서 발견된 Generation effect에서도 찾을 수 있습니다. "~"라는 의미로, 이 연구에서는 참가자가 직접 생성한 단어는 같은 단어를 읽기만 했을 때보다 이후 기억 검사에서 더 잘 회상된다고 합니다. 나중에 떠올리기 쉬워서가 아니라, 만드는 순간 자체가 더 깊은 인지 처리를 일으키기 때문입니다.

결국, 우리가 직접 만들지 않는 AI의 결과물을 이해하고 판단하는 일에는 더 많은 인지적 부담이 늘어나게 되고, 이는 AI와 협업하는 지금의 시대에 맞이할 우리의 새로운 어려움으로 나타날 수 있습니다.

판단력을 유지하려면 생성 과정에 관여해야 한다

사람의 관여도에 따른 작업 리뷰 및 이해도 테스트 결과

더 깊게 들어가보면, 작업에 얼마나 관여했는지에 따라 사람의 인지 결과도 달라집니다. 개발 분야에서 이루어진 선행 연구에서 52명의 소프트웨어 개발자가 새로운 라이브러리를 학습하는 무작위 실험을 진행했습니다. 그 결과, AI 사용 집단과 비사용 집단의 과제 완료 시간은 비슷했습니다. 그러나, 후속으로 진행된 작업 이해도 평가에서 AI를 사용한 집단의 후속 이해도 점수는 평균 50%로, 직접 코딩한 집단의 67%보다 낮았습니다.

흥미로운 점은, AI 사용 집단 안에서도 결과는 사용 방식에 따라 크게 달랐다는 것입니다. AI에게 코드 생성을 전적으로 맡기거나 오류 해결을 반복적으로 위임한 참가자 유형은 이해도 평가에서 24~39%를 기록했습니다. 반면 코드를 생성한 뒤 작동 원리를 질문하거나, 코드와 함께 설명을 요청하거나, 개념만 AI에게 묻고 직접 구현한 참가자 유형은 65~86%를 기록했습니다.

따라서, 우리에게 중요한 것은 AI를 좋은 프롬프트로 얼마나 잘 사용했느냐보다, AI의 작업 과정에 내가 어떤 방식으로 관여했느냐? 가 될 수 있습니다. 결과만 받는 것과, 중간에 “왜 이렇게 했어?”, “다른 선택지와의 트레이드오프는 뭐야?”라고 묻는 것은 전혀 다른 방식으로 AI를 활용하는 방식이며, 작업의 이해도 또한 달라질 수 있다는 것입니다.

먼저 생각을 표현하면 AI는 답변자가 아니라 피드백 도구가 된다

그렇다면 실제로, AI에게 시키기 전에 내 생각을 먼저 꺼내놓으면 결과가 달라질까요? CHI 2025에서 발표된 실험이 이 질문을 직접 검증했습니다. 참가자 21명에게 투자 포트폴리오를 짜는 과제를 주고, 두 종류의 AI 보조 도구를 비교 사용하게 했습니다.

각각 다른 방식의 작업 방식을 가진 AI를 비교

1. RecommendAI : 버튼을 누르면 AI가 바로 추천 안을 제시한다.
2. ExtendAI : 사용자가 먼저 자기 논리를 글로 쓰면, AI가 그 위에 피드백을 얹어준다.

예를 들면, RecommendAI는 "AI야 이 화면 디자인해줘"이고, ExtendAI는 "나는 이 화면에서 이런 걸 중요하게 생각하는데, 이 방향으로 만들어주고 빠진 거 알려줘"라고 하는 식입니다.

결과에서 가장 눈에 띈 건 자신감과 만족도의 관계입니다. RecommendAI를 쓴 그룹은 결정 직후 자신감이 86%로 높았는데, 실제 결과를 본 뒤 만족도는 43%로 급락했습니다. AI가 해준 추천을 믿고 따라갔는데, 막상 결과를 보니 내 판단이 맞지 않았던 것입니다. ExtendAI 그룹은 자신감 67%, 만족도 67%로 거의 일치했습니다. 내 논리를 먼저 세운 쪽은 결과가 어떻든 자기 판단 수준을 정확히 인지하기 때문입니다. 또한, ExtendAI를 사용한 참가자들은 특히 지역적 포트폴리오 다각화 측면에서 더 나은 결과를 보였습니다. 연구진은 사용자가 자신의 계획을 먼저 세운 뒤 피드백을 받는 방식이 포트폴리오 전체의 약점을 더 잘 이해하는 데 도움이 된 것으로 해석했습니다.

실무에서 이 차이가 드러나는 순간이 있습니다. 디자인 리뷰에서 팀원이 "왜 이 레이아웃이에요?"라고 물었을 때, AI 추천을 그대로 쓴 사람은 "AI가 이렇게 뽑아줬는데 괜찮아 보여서요"밖에 할 말이 없습니다. 먼저 자기 논리를 세운 사람은 "첫 진입 시 핵심 가치를 3초 안에 전달하려면 이 구조가 맞다고 생각했고, AI 피드백에서 CTA 위치만 조정했어요"라고 말할 수 있습니다. 이 차이는 결과물의 퀄리티뿐 아니라 협업에서의 신뢰에도 직결됩니다.

그래서 어떻게 일해야 할까? : 생성-지연-재현 워크플로우

그래서, 우리는 AI와 어떻게 일하면 좋을까요? 제 생각에는, AI와 작업을 하는 과정에서 단순히 속도에 집중하기보다는 나의 작업 속도에 맞게, 작업은 AI가 하되 나의 판단 능력을 최적화하는데 집중해야 한다고 생각했습니다. 그래서 AI 활용 워크플로우를 아래와 같이 고민해 보았습니다.

판단 능력을 잃지 않는 AI와의 협업 워크플로우

Step 1. AI에게 일을 맡기기 전, 나의 의도를 먼저 적습니다.

AI에게 "OO 해줘"를 보내기 전에, 내가 기대하는 결과를 2~3줄로 적습니다. 완벽하지 않아도 됩니다. 핵심은 시간이 아니라 내 머릿속에 의도의 흔적을 남기는 것입니다. 이 과정을 통해 나중에 AI에게 결과물을 받았을 때 "뭘 기준으로 볼 것인가"를 만듭니다.

'온보딩' 화면을 설계해 달라고 요청하기 전
→ 이 온보딩 플로우에서 가장 중요한 건 사용자가 '이 앱이 나한테 왜 필요한지'를 두 번째 화면에서 파악하는 것. 기능을 소개하기보다, 가치 제안을 먼저 진행해야 한다.

기능을 구상하고 설계해달라고 요청하기 전
→ 기능의 핵심 지표는 전환율이 아니라 재방문율이다. 한 번 쓰고 마는 기능은 의미가 없다. 사용자가 다시 찾아올 이유가 생기는 기능을 설계해야 한다.

Step 2. 기다리는 시간에 합격 기준을 씁니다.

AI가 도는 동안 다른 프로젝트로 넘어가지 않습니다. 대신, 지금 돌아가고 있는 작업의 합격/불합격 기준을 적아봅니다. EvalGen 연구에서 실제로, "기다려야 하는 시간에 채점 기준을 세우게 하자"는 작업 설계가 효과가 있었다고 합니다.

화면 설계를 시키는 동안 판단해보는 합격 기준
→ 합격 : 핵심 CTA가 스크롤 없이 보이고, 사용자가 다음 행동을 고민하지 않아도 된다.
→ 불합격 : 요소 간 위계가 불분명, 빈 공간이 의도 없이 존재, "다양한", "편리한" 같은 모호한 카피.

기능을 기획하는 동안 판단해보는 합격 기준
→ 합격 : 유저 시나리오 3개 이상을 충분히 커버하고 예외 상황(결제 실패, 재진입 등)이 플로우에 반영되어있어야 한다.
→ 불합격 : 해피 패스만 기술해 놓는다.

물론 기준은 나중에 바뀌어도 괜찮습니다. 기준은 작업 전에 한 번에 완성되기 어렵기 때문입니다. UC Berkeley 연구진이 UIST 2024에서 발표한 EvalGen 연구에서는 criteria drift라는 현상으로 설명합니다. 결과물을 채점하려면 기준이 필요하지만, 실제 결과물을 채점하다 보면 기준 자체가 수정된다는 것입니다.

실제로 이런 경험이 있을 것입니다. "카드 UI는 모서리 라운딩 8px로 통일한다"는 기준을 세우고 작업합니다. 그리고 실제로 다양한 화면을 만들다 보니, "콘텐츠 밀도가 높은 카드는 4px가 맞다"로 기준을 바꾸기도 합니다. 또는 "온보딩은 3단계 이내"라고 정했다가, 실제 사용자 플로우를 그려보니 "단계 수보다 각 단계의 인지 부하가 더 중요하다"로 생각이 바뀌기도 합니다.

결국 내가 기준을 세워 AI에게 전달하더라도, 어차피 그 기준을 한 번에 완벽하게 세울 수는 없습니다. 대신, 기준이 바뀔 때마다 왜 바뀌었는지를 기록해 볼 수는 있겠죠. 경험치가 쌓일수록 그 일이 익숙해지듯, 그 기록이 쌓인다면 다음 판단이 더 빨라질 수도 있을 것 같습니다.

Step 3. 결과물의 핵심적인 부분은 직접 재현해 봅니다.

전체를 다시 작업할 필요는 없습니다. 작업에서 판단이 가장 중요한 부분 하나만 골라서, 나의 버전을 짧게라도 만들어봅니다.
예를 들면, 아래와 같이 해보는 것입니다.

AI가 정리해 준 온보딩 플로우 전체 화면 구성 중, 사용자가 가장 먼저 이탈할 것 같은 구간을 골라
핵심 시나리오를 나의 생각으로 다시 써본다.

"이 화면에서 사용자가 뭘 보고, 어떤 판단을 내려야 하는지"를 직접 문장으로 옮겨봅니다. 내 머릿속에 "이 부분이 왜 이래야 하는지"의 맥락을 심어 보는 것입니다. 중요한 것은, 적어도 작업의 핵심 과정에 관여하여 나의 작업에 대한 소화를 제대로 시켜보아야 한다는 것입니다.

Step 4. 기준의 변화를 로그로 쌓는다

작업 중에 기준이 바뀔 때마다 AI에게 추가로 요청하게 됩니다. 최종적으로 원하는 결과물을 얻기 위해 기준을 수정하며 추가적인 요청을 합니다. 이 대화는 프로젝트가 끝나고 정리하는 게 아니라, 대화를 종료한 시점에 대화의 내용을 요약하여 정리해 봅니다.

v1: 온보딩은 3단계 이내로 끝낸다.
v2: 단계 수보다 각 단계에서 느끼는 인지 부하가 더 중요하다. (사용자 테스트에서 3단계인데도 이탈이 나오면서 수정)
v3: "가치 제안이 두 번째 화면까지 전달되는지가 기준. 단계가 몇 개든 상관없다. (Step 1에서 세운 의도로 다시 연결)

이 부분은 AI가 정리해 주고 읽어볼 수도 있습니다. 이 대화 로그의 목적은 두 가지입니다. 하나는 다음에 비슷한 작업을 시킬 때 프롬프트에 넣어서 시행착오를 줄이는 것, 다른 하나는 내 판단이 어떻게 진화하는지 나 스스로 추적할 수 있게 되는 것. AI와 함께 한 작업이 오롯이 내 역량이 됩니다.

Step 5. 병렬은 "일" 단위가 아니라 "콘텍스트" 단위로 제한한다

같은 프로젝트 안에서 서로 이어지는 작업들(e.g. 온보딩 플로우를 설계하고 생길 수 있는 예외 상황(결제 실패, 재진입 등)을 정리하고, 사용자가 이탈하는 지점을 리서치해서 다시 플로우에 반영하는 일 등)은 동시에 진행해도 전환 비용이 적습니다. 어차피 같은 사용자, 같은 맥락을 계속 들여다보고 있기 때문입니다.

그러나 이번 주 온보딩 기획을 하면서 동시에 전혀 다른 프로젝트의 유저 시나리오까지 검토한다면, 두 개만으로도 판단력이 무너질 수 있다는 점을 기억해야 합니다. 이 상태에서 다른 맥락으로 넘어가면, 나중에 결과가 돌아왔을 때 "내가 뭘 기대했더라"를 머릿속에 다시 떠올려야 하죠. 바로 이 복귀 비용이 생각보다 큽니다.

Sophie Leroy의 연구가 밝힌 attention residue의 개념이 그러한 현상을 증명합니다∙ 이전 작업이 끝나지 않은 채 다른 작업으로 넘어가면, 주의력의 일부가 이전 작업에 남아서 오히려 다음 작업 성과가 떨어진다고 합니다. 주의를 복귀하는 데 드는 비용은 탭을 전환하는 물리적 행위가 아니라, "내가 이 작업에서 뭘 기대했는지"를 재구성하는 데서 발생하는 것입니다.

따라서, 여러 작업 각각에 내가 어떤 의도를 가졌는지를 전부 다시 떠올리는 비용만으로도 판단의 질이 떨어질 수도 있습니다. 그래서 Step 1에서 나의 의도와 기대하는 결과를 메모해 두는 건 바로 복귀 비용을 줄이는 장치가 되기도 합니다.

마치며

“작업을 판단하고 기준을 만드는 건 AI의 능력이 아니라 나의 전문성이다”

지금까지 인용한 연구들을 다시 보면, 하나의 패턴이 있습니다. AI 활용에서 중요한 것은 기술적 능력이 아닌 본업에 대한 사람의 판단력과 역량이 변수라는 것입니다. MS/CMU 연구에서 비판적 사고를 더 많이 한 사람은 AI를 잘 다루는 사람이 아니라, “자기 분야에 대한 자신감이 높은 사람”이었습니다. ExtendAI 실험에서 더 나은 결과를 낸 사람도 AI 피드백이 좋아서가 아니라, “먼저 자기 논리를 세운 사람”이었습니다. 이해도가 상대적으로 높았던 개발자도 프롬프트를 잘 짜서가 아니라, AI의 작업물에 "왜?"를 물을 줄 아는 사람”이었습니다.

이 역량은 프롬프트 잘 쓰는 법을 공부해서 생기는 게 아니라, UX 업무를 해오던 경험에서 나오는 것입니다. 사용자가 어디서 막히는지를 관찰한 경험, 정보 구조를 잡을 때 무엇을 먼저 보여줘야 하는지에 대한 감각, "이 플로우는 왜 이래야 하는가"를 설명할 수 있는 논리, 이런 것들이 AI 결과물 앞에서 "이건 괜찮고 이건 아니다"를 가르는 기준을 만듭니다. 기준을 만들고, 바꾸고, 왜 바꿨는지를 판단하는 건 AI가 할 수 없습니다. 그건 사용자를 관찰하고, 맥락을 이해하고, "이건 아닌데"라고 느낄 수 있는 사람의 일입니다.

앞선 연구가 보여줬듯, 물론 판단 기준이 순수하게 내 머릿속에서만 나오지는 않습니다. AI 출력물을 보고 나서야 "아, 이건 안 되는구나"를 깨닫고 기준이 생기기도 합니다. 이렇듯, 판단 능력은 단순히 빈 종이에서 완성되는 게 아니라 AI와 부딪히면서 다듬어지기도 합니다.

이 워크플로우는 느릴 수 있습니다. 대신 결과물에 대한 확신과, 다음 판단의 출발점이 되는 노하우를 남깁니다. 화면 세 개를 동시에 뽑아내기보다, 그중 하나를 붙잡고 "왜"에 끝까지 답할 수 있는 능력. 이게 쌓이면 리뷰에서 막히는 시간과 재작업이 줄고, 비슷한 판단은 다음 프로젝트에서 더 빨라집니다. 빠르게 많이 만들었지만 뭐가 좋고 뭐가 나쁜지 모르는 상태는 진정한 의미의 생산성이 아니라고 생각합니다.
AI를 쓰더라도 "왜 이렇게 만들었는지"를 설명할 수 있는 능력이 복리로 쌓이는 것이 AI 시대의 진정한 의미의 생산성이라고 생각합니다.

참고 자료

1. Lee et al. (2025). "The Impact of Generative AI on Critical Thinking." Microsoft Research & CMU. CHI 2025.
2. Reicherts, Zhang et al. (2025). "AI, Help Me Think—but for Myself." Microsoft Research & UCL. CHI 2025.
3. Shankar et al. (2024). "Who Validates the Validators?" UC Berkeley. UIST 2024.*
4. Slamecka & Graf (1978). "The Generation Effect: Delineation of a Phenomenon." Journal of Experimental Psychology.
5. Simkute et al. (2024). "Ironies of Generative AI." Microsoft Research.
6. Leroy (2009). "Why Is It So Hard To Do My Work?" Organizational Behavior and Human Decision Processes.
7. O'Reilly (2026). "Comprehension Debt: The Hidden Cost of AI-Generated Code.

GEONIQ Integrated Insight Report — GEO 최적화 잘 되어있는 사이트 BEST 5 (Vol.2 진단 점수가 높으면 AI도 더 많이 인용할까?)

GEONIQ — Thu, 30 Jul 2026 13:07:25 +0900

GEO 우수 사례로 소개된 5개 사이트를 대상으로 90회 AI 인용을 실측했습니다.

페이지 진단/분석으로 '인용될 준비' 상태를 살펴봤습니다.
그렇다면 실제 AI 답변에서는 이들 사이트가 얼마나 출처로 선택됐을까요?

들어가며

1편에서는 GEO 우수 사례로 소개된 5개 사이트에서 총 30페이지를 선정해 진단했습니다.
사이트마다 강점이 나타나는 영역은 달랐습니다.
KB Think와 카카오뱅크는 기술적 준비 상태가 상대적으로 안정적이었고, SK브로드밴드와 이랜드는 콘텐츠 품질에서 높은 점수를 보였습니다.

그런데 GEO를 이야기할 때 페이지 진단만큼 중요한 질문이 하나 더 있습니다.
실제로 AI가 답변을 만들 때 이 사이트를 출처로 선택했는가입니다.

이번에는 각 사이트가 실제로 다루는 콘텐츠 주제를 바탕으로 질문을 구성했습니다.
ChatGPT, Gemini, Perplexity의 답변에서 대상 사이트가 출처로 등장하는지 확인했습니다.

인용 실측은 이렇게 진행했습니다

사이트별로 콘텐츠 주제 질문 6개를 구성하고, 3개 AI 플랫폼에 각각 한 차례씩 질의했습니다.

대상 사이트 : 5개
사이트별 질문 : 6개
AI 플랫폼 : 3개
전체 질문 : 30개
전체 답변 : 90개

대상 사이트가 답변 출처에 한 번 이상 포함되면 ‘인용 응답’으로 계산했습니다.
동일 답변에서 같은 도메인의 서로 다른 URL이 3개 인용됐다면 인용 응답은 1개, 누적 인용은 3건입니다.
www 유무와 http·https 차이는 제거해 동일 사이트로 판정했으며, 대상 콘텐츠 사이트가 아닌 동일 브랜드의 다른 도메인은 별도로 집계했습니다.
페이지 진단에 사용한 URL과 질문은 일대일로 대응하지 않습니다. 따라서 특정 페이지의 점수가 특정 질문의 인용을 만들었다고 해석하지 않고, 사이트 단위 결과를 병렬로 비교했습니다.

이번 측정의 범위와 한계

이번 실측은 사이트별 질문 6개를 3개 AI 플랫폼에 각각 한 차례씩 질의한 탐색적 측정입니다.

총 90개 답변을 확인했지만 사이트별 결과는 18개 답변을 기준으로 합니다. 질문을 무작위로 추출하거나 동일 질문을 반복 측정한 통계조사는 아닙니다.
AI 답변은 측정 시점과 모델, 플랫폼의 검색·출처 제공 방식에 따라 달라질 수 있습니다. 따라서 본문에 제시된 비율은 이번 질문군과 측정 조건에서 관찰된 결과로 해석해야 합니다.

전체 90개 답변 중 24개에서 대상 사이트가 인용됐습니다

사이트	인용된 답변	이번 인용 응답률	누적 인용 URL
KB Think	8/18	44%	12건
신한금융 인사이트	5/18	28%	6건
SK브로드밴드 블로그	5/18	28%	7건
카카오뱅크 블로그	3/18	17%	3건
이랜드 E:KI HOW	3/18	17%	4건
전체	24/90	27%	32건

* 인용 응답률은 소수점 첫째 자리에서 반올림했습니다. 누적 인용은 서로 다른 URL을 기준으로 집계했습니다.

<사이트별 AI 인용 응답률>

이번 표본에서 KB Think는 18개 답변 중 8개에 인용됐습니다. 진단 결과와 인용 응답률이 모두 상대적으로 높게 관찰된 사례입니다.

카카오뱅크는 상세 통합점수 평균이 82.8점이었지만 이번 측정에서는 18개 답변 중 3개에 인용됐습니다.

이랜드도 콘텐츠 품질 평균은 85.4점이었지만 인용된 답변은 18개 중 3개였습니다.

반대로 신한금융은 상세 통합점수 평균이 71.0점이었지만 인용된 답변은 18개 중 5개였습니다.

이번 다섯 사이트에서는 진단점수의 순서와 인용 응답률의 순서가 일치하지 않았습니다.
다만 사이트가 5개이고 질문당 한 차례 측정한 결과이므로, 이를 통계적인 상관관계나 인과관계로 해석해서는 안 됩니다.

진단 결과와 인용 응답률 비교

<상세 페이지 통합점수 평균과 AI 인용 응답률 비교>

* 서로 다른 두 지표를 동일한 0~100 범위에서 병렬 비교한 것으로, 두 지표 사이의 상관관계나 인과관계를 의미하지 않습니다.

플랫폼에 따라서도 결과가 달랐습니다

플랫폼	대상 사이트가 인용된 답변	이번 인용률	전체 출처 URL 수
Gemini	12/30	40%	360건
Perplexity	9/30	30%	421건
ChatGPT	3/30	10%	70건

플랫폼마다 답변 생성 방식과 출처 제공 방식이 다릅니다.
전체 출처 URL 수도 ChatGPT 70건, Gemini 360건, Perplexity 421건으로 차이가 컸습니다. 따라서 이 결과를 AI 플랫폼의 우열로 해석해서는 안 됩니다.
동일한 질문과 사이트라도 플랫폼의 출처 제공 방식에 따라 관찰되는 인용 결과가 달라질 수 있다는 의미로 보는 것이 적절합니다.

대상 사이트 외에 어떤 출처가 함께 인용됐을까?

대상 사이트	대상 사이트 누적 인용	함께 많이 집계된 도메인
신한금융 인사이트	6건	YouTube 20, Investing.com 10, 다음 7
KB Think	12건	네이버 블로그 19, YouTube 18
카카오뱅크 블로그	3건	네이버 블로그 28, YouTube 9, KB Think 8, 토스뱅크 8
이랜드 E:KI HOW	4건	네이버 블로그 16, YouTube 12, 다음 11, 패션비즈 11
SK브로드밴드 블로그	7건	YouTube 33, 아정당 13, 네이버 블로그 12

누적 인용은 서로 다른 URL을 기준으로 계산했기 때문에 답변 수보다 클 수 있습니다.
이 표는 어떤 출처가 더 정확하거나 우수하다는 평가가 아닙니다. 이번 90개 답변에서 실제로 집계된 출처 URL을 도메인별로 합산한 결과입니다.

공식 기업 콘텐츠라고 해서 AI가 항상 해당 기업의 페이지를 우선적으로 선택하지는 않았습니다.
YouTube와 네이버 블로그가 여러 질문군에서 반복적으로 등장했고, 금융·통신·패션과 같은 분야별 전문 매체와 비교 서비스도 함께 인용됐습니다.
다만 이번 결과만으로 AI가 특정 출처를 선택한 내부 원인을 확정할 수는 없습니다.

콘텐츠 구조와 별개로 정확성·최신성 관리가 필요했습니다

진단과 인용 실측을 함께 살펴보면서 다시 확인하게 된 것은 정확성과 최신성의 중요성이었습니다.

SK브로드밴드의 B 다이렉트샵 관련 페이지는 1G 상품 기준 월 36,300원을 3년 약정 월 39,600원보다 ’약 43% 절감’된다고 설명합니다.
두 금액의 차이를 기준으로 계산하면 감소율은 약 8.3%입니다. 같은 표에는 무약정과 기존 1년 약정 금액도 함께 제시돼 있지만, 해당 문장만으로는 43%의 구체적인 산출 기준을 확인하기 어려웠습니다. SK브로드밴드 공식 페이지

또 다른 셋톱박스 콘텐츠에는 ’2026년 4월 30일까지’라는 프로모션 안내가 2026년 7월 19일 확인 시점에도 표시돼 있었습니다.
이 사실만으로 해당 혜택의 실제 운영 여부를 판단할 수는 없습니다. 다만 공개된 페이지에서는 프로모션의 현재 적용 상태나 최근 검토 여부를 확인하기 어려웠습니다. SK브로드밴드 공식 페이지

이 사례를 특정 사이트 전체의 품질 문제로 확대해석할 필요는 없습니다.
가격·혜택·정책처럼 자주 바뀌는 콘텐츠라면 어느 사이트든 적용 기간과 최종 검토일을 함께 관리해야 한다는 운영상의 시사점에 가깝습니다.

GEO에서 확인해야 할 것은 다섯 가지였습니다

1. 발견할 수 있는가

검색엔진과 AI가 주요 콘텐츠를 안정적으로 찾을 수 있도록 사이트 구조와 내부 연결이 관리되어야 합니다.

2. 이해할 수 있는가

질문에 대한 결론과 근거가 분명하고, 소제목·표·목록을 통해 내용이 구조화돼야 합니다.

3. 확인할 수 있는가

작성 주체, 기준일, 원문 출처와 근거 정보를 독자와 AI가 확인할 수 있어야 합니다.

4. 최신 상태인가

변경 가능성이 높은 가격·정책·혜택은 적용 기간과 최종 검토일을 함께 관리해야 합니다.

5. 실제로 선택되는가

페이지 진단만으로 끝내지 않고 AI 답변에서 자사 브랜드와 콘텐츠가 얼마나 언급·인용되는지 지속적으로 확인해야 합니다.

llms.txt가 없거나 특정 스키마가 적용되지 않았다는 사실만으로 GEO 성과를 단정할 수는 없습니다.
구조화 데이터는 페이지 유형에 적합할 때 검색엔진과 시스템의 이해를 돕는 보조 수단이지, AI 인용을 보장하는 조건은 아닙니다.

한 번의 측정에서 지속적인 GEO 성과관리로

앞서 본 것처럼 AI 답변은 측정 시점과 플랫폼, 모델에 따라 달라질 수 있습니다.
따라서 한 번의 인용률을 성과로 확정하기보다 동일한 질문군을 반복 측정하고, 개선 전후의 변화를 함께 확인해야 합니다.

GEONIQ(지오닉)은 현재 Enterprise 및 별도 진단을 요청한 고객사를 대상으로 GEO 성과지표(KPI) 분석 기능을 우선 제공하고 있습니다. 일반 사용자 대상 기능은 올해 9~10월 공개를 목표로 개발 중입니다.

AI 검색 가시성 분석

AI 답변 내 브랜드 언급 및 출처 인용 현황
경쟁 브랜드 대비 노출·추천 결과
주요 질문별 AI 플랫폼 답변 비교
자사 인용률과 도메인 점유율 변화 추적

AI 인식 및 우호도 분석

AI 답변에서 반복적으로 나타나는 브랜드별 강점·약점 키워드
경쟁 브랜드 대비 포지셔닝
질문 유형별 추천·강점 중심 응답 분석
브랜드와 관련된 부정확한 인식 및 리스크 요소 점검

GEONIQ에서 말하는 우호도는 단순한 긍정·부정 감성 분석이 아닙니다.
AI가 특정 질문에서 해당 브랜드를 얼마나 추천하는지, 어떤 강점을 중심으로 설명하는지, 경쟁 브랜드와 비교해 어떤 위치에 두는지를 종합적으로 살펴보는 분석입니다.

GEO 개선 방향

경쟁 브랜드나 외부 출처가 더 자주 선택된 질문 확인
답변과 인용 출처에서 반복적으로 관찰되는 차이 분석
AI가 이해하기 쉬운 콘텐츠 구조 개선 방향
검색엔진과 생성형 AI 대응을 위한 실행 가이드
개선 이후 KPI 변화 추적

AI가 특정 출처를 선택한 내부 판단 과정을 직접 확인할 수는 없습니다.
따라서 GEONIQ은 하나의 원인을 단정하지 않습니다. 답변과 출처에서 반복적으로 관찰된 차이를 기반으로 개선 가설과 우선순위를 도출합니다.
기업의 목적과 운영 방향에 따라 분석 대상과 질문군, 비교 브랜드, 평가 기준, 대시보드와 결과물의 형태도 조정할 수 있습니다.

"GEONIQ의 차별점은 페이지를 한 번 진단하는 데서 끝나지 않고, AI 검색 가시성과 브랜드 인식·인용 변화를 지속적으로 측정합니다. 이를 통해 진단·실측·개선·성과 추적을 하나의 흐름으로 연결합니다. "

마치며

기존 소개 글이 주목한 질문형 제목, 핵심 요약, 명확한 소제목과 실생활 콘텐츠는 모두 GEO 관점에서 참고할 만한 요소였습니다. 하지만 이번 진단과 인용 실측에서는 사이트마다 강점이 나타나는 지점이 달랐습니다.

콘텐츠 점수가 높다고 이번 인용 응답률도 함께 높아지는 단순한 관계는 관찰되지 않았습니다. 같은 사이트도 AI 플랫폼에 따라 결과가 달랐습니다.

GEO는 정답 목록을 맞추는 작업이라기보다 콘텐츠가 발견되고, 이해되고, 확인된 뒤 실제 답변에 활용되는 과정을 지속적으로 점검하는 일에 가깝습니다. 한 번의 결과보다 더 중요한 것은 같은 질문을 계속 관찰하면서, 개선 이후 실제 변화가 나타나는지 확인하는 것입니다.

2편 측정 기준

AI 인용 실측일 : 2026년 7월 18일

대상 사이트 : 5개

질문 : 사이트별 6개, 총 30개

플랫폼 : ChatGPT, Gemini, Perplexity

전체 답변 : 90개

측정 횟수 : 질문당 플랫폼별 1회

집계 기준 : 대상 사이트가 출처에 한 번 이상 포함되면 인용 응답으로 판정

유의사항 : 무작위 표본조사나 반복 측정이 아닌 한 시점의 탐색적 실측

본문은 공개 페이지와 측정 시점의 GEONIQ 분석 결과를 기준으로 작성했습니다. 사실관계에 관한 정정이나 추가 근거는 geoniq@pxd.co.kr로 보내주시면 확인 후 반영하겠습니다.

GEONIQ 서비스 바로가기

AI 라이팅 어시스턴트, Writone 개선기

Yejin.lee — Thu, 30 Jul 2026 07:50:58 +0900

들어가며

2024년 9월, pxd story를 통해 UX Writing을 돕는 AI 툴에 대한 실험기를 공유한 적이 있습니다. 당시 우리는 'AI가 우리 회사만의 가이드라인을 학습해 글쓰기를 도와줄 수 있을까?'라는 질문에서 출발한 프로덕트였습니다. 그로부터 약 7개월, 우리가 발견한 건 단순히 기술적인 답이 아니었습니다.

"AI Writing 어시스턴트가 실제로 쓰이려면, 사용자의 경험 중 어디에 있어야 하는가?"

그 답을 Uxer로서 찾아가는 과정, UX의 필터를 통해 AX 서비스의 마켓핏을 찾아갔던 경험을 공유합니다.

1. 수천 페이지의 가이드라인은 어디로 가는가?

많은 기업이 막대한 비용을 들여 브랜드만의 UX Writing 가이드라인을 만듭니다. pxd도 여러 UX Writing 프로젝트를 거치며 기업의 가이드라인 제작을 함께해 왔습니다. 그런데 그 과정에서 반복적으로 마주하는 장면이 있었습니다. 공들여 만든 UX 라이팅 가이드라인이 사내 클라우드 깊숙한 곳의 PDF 파일로 잠들어 있는 것입니다. 디자이너와 기획자는 바쁜 마감 일정 속에서 수백 페이지의 문서를 뒤져 "우리 브랜드가 '경우' 대신 '하면'을 쓰기로 했었나?"를 확인할 여유가 없기 때문입니다. pxd는 이 문제를 해결해 주는 Writone 프로젝트를 시작하게 되었습니다.

2. 마켓핏을 찾는 열쇠: 실무자의 하루를 들여다보기

pxd가 가장 먼저 한 것은 실무자의 하루를 들여다보는 것이었습니다. UXer의 방식으로, 제품을 사용하는 사람을 먼저 이해하려 했습니다. UX 디자이너의 하루는 단순하지 않습니다. 기획 문서를 열고, Figma에서 화면을 그리고, 텍스트를 넣고, 동료에게 리뷰를 받고, 다시 수정하는 과정이 반복됩니다. 그 흐름 속에서 UX Writing 검토가 필요한 순간은 언제일까요? 생각보다 훨씬 자주, 그리고 항상 Figma 안에서 일어나고 있었습니다. 버튼 라벨을 적다가 "이게 맞는 표현이었나?" 하는 순간, 에러 메시지를 쓰다가 "우리 브랜드 톤이 이랬나?" 하는 순간. 이 모든 의문은 작업 과정에서, 작업 공간 안에서 발생했습니다.

그런데 UX 라이팅 가이드라인을 확인하려고 하면 우리의 작업 흐름은 완전히 끊깁니다. Figma에서 나와 PDF 파일을 열고, 적합한 규칙을 찾고, 규칙을 반영하기 위해 Figma로 가져와야 합니다. 이 작은 마찰이 반복될수록 실무자는 문구 검토 작업에서 점점 멀어지게 됩니다. 결국 가이드라인 확인을 포기하고 자신의 감각에 의존하게 됩니다.

"UX Writing 검토의 필요성은 인지하지만, 그것을 위해 흐름을 끊는 전환 비용이 너무 크다."

저니를 따라가며 우리가 발견한 핵심 인사이트는 이것이었습니다. 이 인사이트는 Writone의 방향을 결정했습니다. 실무자에게 좋은 AI 엔진을 제공하는 것보다, 그들의 흐름 안에 자연스럽게 존재하는 것이 먼저였습니다. 기술이 아닌 사람의 흐름에서 출발했기 때문에, 제품이 있어야 할 자리가 자연스럽게 결정되었습니다.

3. 해답은 Figma 플러그인이었다

실험기에서는 범용성을 위해 웹 버전을 시도하기도 했지만, 정식 출시를 준비하면서부터는 Figma로 완전히 돌아왔습니다. 실무자의 작업 흐름을 끊지 않는 것, 그것이 가장 중요한 제품 가치라고 판단했기 때문입니다. 그래서 "피그마 플러그인"을 선택했습니다. 실무 프로세스를 깊게 이해한 결과, 제품이 있어야 할 자리가 자연스럽게 결정된 것입니다.

피그마에에서 바로 문구 검토를 시작

작업 환경의 일치
Figma 안에서 텍스트 박스를 클릭하고 '검토하기' 버튼만 누르면 수정된 문구가 디자인 시안에 즉시 반영됩니다.
다른 탭으로의 이탈, 복사와 붙여넣기의 반복은 사라집니다.

컴포넌트의 노드 정보와 맥락을 읽어 규칙을 찾아 교정

맥락을 아는 AI
피그마에서의 글쓰기를 고민하는 상황이라면, 디자이너가 작업 중인 맥락을 AI가 이미 알 수 있을까?라는 부분이 중요해집니다. 바로 이 부분이 Figma 플러그인이기에 가능해졌습니다. AI가 레이어 이름(Node 정보)을 인식해 이 문구가 '버튼'인지 '토스트 메시지'인지 스스로 판단합니다. "버튼이니까 명사형으로 종결하자" 같은 구체적인 교정이 가능해집니다.

4. Writone의 AI Writing 성능을 UX로 고도화하기

곧바로 다음 질문에 직면하게 됩니다.

"어떻게 해야 실무자가 실제로 신뢰하고 사용할 수 있는 성능을 구현할 수 있을까?"

아무리 좋은 기능이라도, 사용자가 납득하지 못하거나 그 결과에 의존할 수 없다면 좋은 사용자 경험(UX)이라고 할 수 없기 때문입니다. 경험을 가장 먼저 생각하는 관점은 Writone의 AI 엔진 설계에도 그대로 적용되었습니다. 즉, 사용자 경험의 문제를 해결하기 위해 AI의 기술적 고도화 또한 필수적이었습니다.

4-1. AI의 사고방식 체계화: 인지 모델을 빌려온 구조 설계

방대한 규칙을 한꺼번에 제공하면 AI에게 혼란을 주어 성능이 저해될 뿐 아니라, 실무자가 받는 결과물도 일관성을 잃게 되고, 실무자 입장에서는 무엇을 기준으로 규칙의 옳고 그름을 판단할지 알기 어렵습니다. 즉, AI가 제공하는 결과에 사용자 신뢰도가 떨어지게 되는 것입니다.

이 문제를 해결하기 위해 우리는 UX 분야의 인지 모델을 빌려왔습니다. Aarron Walter의 사용자 요구 계층 모델입니다. 사용자의 경험에도 위계가 있듯, 사용자의 글쓰기 규칙에도 위계가 있다는 관점에서 출발했습니다. 이 프레임을 통해 UX Writing 규칙을 4가지 층위로 구조화했습니다. AI가 규칙을 평면적인 리스트가 아닌, 의미 있는 계층 구조로 인식하도록 했습니다. 이로써 AI는 규칙 간의 이슈를 유형화하고 위계와 연관성을 파악하여 필요한 규칙을 찾을 수 있게 되고, 더욱 정교한 교정을 할 수 있게 되었습니다. 또한, 실무자는 이 규칙이 어떠한 계층의 위계에 따라 적용되었는지를 자연스럽게 이해할 수 있습니다.

Level 1 : 용어(Terminology) - 서비스의 '신뢰성'
가장 기초가 되는 단계입니다. 금칙어와 권장어를 기반으로 용어를 통일하는 일관성(Consistency)은 사용자에게 주는 가장 기본적인 약속이자 신뢰의 뼈대입니다. 예) 익월'-> '다음 달', '당사'-> 'OO증권'

Level 2 : UI 규칙(UI Rules) - 환경에 따른 '사용성'
글은 놓이는 공간에 따라 기능이 달라집니다. 버튼(Button) 라벨은 간결해야 하고, 툴팁(Tooltip)은 친절해야 하죠. 컴포넌트별 글쓰기 규칙을 이해하고, 검토 시 피그마의 노드 정보를 통해 교정할 문구의 위치를 파악하고, 그에 맞는 규칙을 매칭시킵니다. 오류 메시지, 도움말, 버튼 라벨 등 특정 UI 컴포넌트나 상황에 따라 규칙이 유연하게 적용되어야 하는 부분을 다룹니다.

Level 3 : 문법(Grammar) - 소통의 '가독성'
오탈자나 비문은 서비스의 성의를 의심하게 만들고, 가독성을 크게 떨어뜨립니다. 문장 구조, 서식, 톤 앤 매너 등 규칙을 적용하는 구체적인 틀과 방식을 정교하게 이해하고 교정할 문구를 검증하여 정보 전달의 노이즈를 제거합니다.

Level 4 : 라이팅 원칙(Principles/Tone) - 브랜드의 '인격'
모든 UX 글쓰기의 근간이 되는 가장 기본적인 철학과 불변의 원칙을 담고 있습니다. (예: 명확성, 간결성, 사용자 중심적 언어 사용). 브랜드가 추구하는 페르소나와 톤앤매너를 입히는 과정은 모든 글쓰기의 근본에 필요한 과정입니다.

4-2. AI 검색 엔진의 고도화: 사용자가 납득할 수 있는 교정을 위해

UX Writing 가이드라인은 단순한 '좋은 예/나쁜 예'의 사례 모음이 아닙니다. "\~경우는 \~하면으로 쓴다"와 같은 추상적인 규칙의 집합입니다. 하지만 '유사도' 기반의 단순 검색 엔진은 규칙을 단순히 '비슷한 텍스트'로 검색하기 때문에, 결과를 받아도 "왜 이렇게 고쳐야 하는지"를 납득하기 어려웠습니다. 이를 해결하고자, AI가 '규칙(Rule)'을 우리가 앞서 구분한 글쓰기 구조에 따라서 이해하는 Rule-based RAG 아키텍처를 활용하여 AI 검색 엔진을 고도화했습니다.

Rule-based RAG 아키텍처

Rule-based RAG 아키텍처
PDF 가이드라인에서 "경로 표기는 '→'로 통일한다"와 같은 추상적 규칙을 AI가 스스로 추출하여 목록화합니다.

문맥 맞춤형 교정
사용자가 문구를 입력해서 검토를 요청하면 AI가 이슈를 식별하고, 가장 적합한 가이드라인 규칙을 매칭해 수정안을 제안합니다.

5. 결과만 뱉는 도구가 아닌, 신뢰할 수 있는 '협업자'로

AI 엔진을 고도화했다면, 다음은 사용 경험의 고도화를 고민할 차례였습니다. 여기서 우리는 한 가지 근본적인 질문에 직면했습니다

"아무리 AI가 좋은 결과를 주더라도, 실무자가 이를 이해하고 신뢰하지 않는다면 의미가 있는가?"

이 질문은 AI 기술 전반에서 가장 핵심적인 과제이기도 합니다. McKinsey의 2024년 AI 현황 조사에 따르면, 생성형 AI 도입에서 기업들이 꼽은 가장 큰 리스크 중 하나가 바로 '설명 가능성(Explainability)'이었습니다. AI가 아무리 정확한 결과를 내놓더라도, 사용자가 그 결과를 이해하지 못하면 신뢰하지 않고, 신뢰하지 않으면 쓰지 않습니다. UX 관점에서 이 문제는 더 구체적으로 보입니다. AI 시스템이 결과만 제시하고 이유를 보여주지 않을 때, 사용자는 그것을 '블랙박스(Black box)'처럼 느낍니다. 블랙박스는 사용자에게 불안을 낳고, 불안은 불신으로 이어집니다. 따라서, AI가 어떻게 결론에 도달했는지를 보여주어야 사용자는 AI의 결과를 이해하고, 믿고 협업하는 파트너로 인식할 것이라고 생각했습니다.

여기에 더해, 실무 현장에서 AI를 쓸 때 발생하는 또 다른 위험이 있습니다. 바로 자동화 편향(Automation Bias)입니다. AI의 제안을 비판적으로 검토하지 않고 그대로 수용하는 경향입니다. 이러한 경향은 실무자의 전문적 판단력을 오히려 약화시킬 수 있습니다. 따라서, 특히 UX 라이팅처럼 사람의 맥락적 판단과 인지가 중요한 영역에서는, AI가 '대체자'가 아닌 '조력자'로 설계되어야 한다고 생각했습니다.
따라서, 이 두 가지의 문제를 해결하기 위해, Writone의 UX는 세 가지 원칙을 중심으로 설계했습니다.

교정 결과와 함께 매칭된 교정 유형과 규칙을 제공하는 UI

투명성(Transparency): 근거를 함께 보여준다
Writone은 문구를 교정할 때 반드시 가이드라인의 어느 페이지, 어떤 원칙에 근거했는지를 함께 노출합니다. 사용자는 "AI가 마음대로 고쳤다"가 아니라 "가이드라인에 따라 제안받았다"는 느낌을 받게 됩니다. AI의 판단 근거가 보일 때, 비로소 사용자는 그 결과를 검토하고 수용할 수 있습니다.

설명 가능성(Explainability): 이유를 이해할 수 있게 한다
근거를 단순히 노출하는 것을 넘어, Writone은 '왜 이렇게 고쳐야 하는지'를 실무자가 납득할 수 있는 언어로 설명합니다. 복잡한 알고리즘을 보여주는 것이 아니라, 해당 교정이 어떤 라이팅 원칙에서 비롯된 것인지를 명확히 전달합니다. 이해할 수 있어야 신뢰할 수 있고, 신뢰할 수 있어야 실제로 쓰입니다.

교정 적용 결과를 선택적으로 적용할 수 있는 UI

사용자 주도권(Human Control): 최종 판단은 사람이 한다
자동화 편향을 막는 가장 효과적인 UX 설계는, AI가 '결정'하는 것이 아니라 '제안'하도록 만드는 것입니다. Writone은 실무자가 AI의 제안을 맹목적으로 따르는 것이 아니라, 브랜드의 원칙을 다시 한번 상기하며 스스로 최종 문구를 결정하도록 설계했습니다. AI는 선택지를 제시하고, 판단은 사람이 합니다.

마치며

많은 AI 기반 도구들이 쏟아지는 시대입니다. pxd는 이러한 흐름에서도 UXer로서의 사용자 경험을 중심으로 접근합니다.
Writone은 완벽한 정답을 내놓는 기계가 아닌, 실무자가 더 가치 있는 일에 집중할 수 있도록 곁에서 돕는 가장 똑똑한 조력자입니다. 잠들어 있던 가이드라인이, 이제 모든 실무자의 손끝에서 살아 움직이는 경험을 직접 만나보세요.

더 알아보기: http://www.pxdax.co.kr/
프로덕트 문의: info@pxd.co.kr

부동산 정책 토론회 게시판의 10가지 유형 목소리

無異 — Tue, 28 Jul 2026 12:48:03 +0900

지난 7월 23일, 대통령이 참여한 국민 부동산 정책 제안 토론회가 열렸습니다. 그에 앞서 온라인 의견수렴 게시판도 함께 열렸는데요. 7월 14일부터 토론회 당일까지 열흘 남짓한 기간에 6,680건이 올라왔습니다. 어떤 목소리가 담겨 있는지 AI 도구를 활용해 확인해 보았습니다.

우선은 어피니티버블을 이용해 주제별로 지형도를 확인했습니다. 대량의 정성 데이터를 바텀업으로 묶어 성격을 빠르게 확인해 볼 수 있습니다. 그런데 무엇을 말하는지는 보여도, 왜 그런 얘기를 하는지 맥락은 잘 드러나지 않았습니다. 큰 지형을 이제 다른 관점에서 세분화해 볼 필요가 있습니다.

부동산 토론회 게시판 지형도

누가 왜 어떤 주장을 하는가

그래서 맥락이 드러나도록, 누가 무슨 얘기를 하는지 유형을 나눠 보기로 했습니다. 비공개 본문과 블라인드, 동일 내용 복붙을 제외하면 4,959건이 남습니다. 여기에 공통 기준을 적용해 글별 변수를 코딩하고, LLM으로 분류한 뒤 그 변수 조합을 바탕으로 유형을 나눴습니다. 결과의 일부 표본은 사람이 검수했습니다. 분류가 틀린 경우도 있었지만, 정확한 판정이나 수치 산출보다 대화의 큰 흐름을 읽는 것이 목적이었기에 충분히 납득할 만한 수준이었습니다.

모든 글에 세 가지를 물었습니다

변수	질문	선택지
요구 방향	무엇을 해 달라는가	부담 완화·예외 / 지원·공급 확대 / 약속·원안 이행 / 구조개편 / 부담 강화 / 혼합
적용 태도	규제를 어떻게 보는가	범위 조정 / 이행 요구 / 경과조치 / 원칙 반대 / 판단 보류
발화 위치	어느 자리에서 말하는가	자기·가족·소속집단 근거 여부 / 원문에 밝힌 주택 상태

"완화해 달라"는 말은 셋으로 갈린다

무엇을 요구하는지를 나눠보면, 부담을 덜어 달라는 글이 2,635건으로 절반을 차지합니다. 이 글들을 다시 규제에 따른 태도로 나눠볼 수 있습니다. 정책 자체가 잘못됐다기보다 이번에 내가 정책 변화로 피해를 입게 되었으니 구제하기 위해 범위 조정이나 경과조치를 해달라는 이야기가 많습니다.

갈래	실제로 하는 말	비중%
범위 조정	규제는 필요하지만 적용 대상을 좁혀 달라	60%
원칙 반대	규제 자체가 잘못됐다	21%
경과조치	이미 계약한 사람은 예전 기준으로	15%

정책수단으로 보면 셋 다 "완화"입니다. 하지만 태도는 각각 다릅니다. 첫 번째는 기준을 조정하라는 요구, 두 번째는 제도를 철회해달라는 요구, 세 번째는 시행 시점을 조정하라는 요구입니다.

누구인가 — 발화 위치에 따른 구분

주택 상태에 따른 구분

세 번째 변수를 코딩할 때는 맥락으로 위치를 판단하지 않도록 했습니다. 대출 규제를 풀어 달라고 썼다는 이유로 무주택자로 간주하지 않는 것입니다. 글쓴이가 자기 상태를 직접 밝힌 경우에만 기록하고, 근거가 없으면 확인 불가로 남겼습니다. 요구를 보고 신분을 추정한 뒤 다시 "신분에 따라 요구가 달랐다"고 결론 내면, 자기가 넣은 답을 자기가 꺼내 보는 셈이 되니까요.

진입 단계에서 대출 관련된 문제로 글을 쓴 사람이 1주택,다주택, 임대인의 부동산 세금에 대해 글을 쓴 사람보다 훨씬 많습니다. 당장 처한 문제이니까요.

발화 위치에 따른 구분

이 기준으로 보니 개인 당사자, 집단 당사자, 관찰자, 제3자 지목의 네 갈래가 나타났습니다. 자신의 입장을 직접 드러내는 개인 당사자와 집단 당사자는 모두 자기가 정책 변경으로 피해를 입고 있다고 호소합니다. 관찰자와 제3자 지목 글은 요구 방향을 썼습니다.

부동산정책 게시판의 10가지 목소리

이 변수들을 이용해 10가지 유형을 나눴습니다. 전체의 79%가 아래 10개 유형에 들어갔습니다. 어느 유형에도 충분히 들어맞지 않은 1,064건은 억지로 배정하지 않았습니다.

원문에 드러난 발화 근거와 주택 상태를 바탕으로 나눈 10가지 유형과 주장

집단의 이름으로 말한 당사자는 네 유형이었습니다. 뉴홈 사전청약 등을 둘러싼 청약 당첨 집단(417건), 잔금일을 앞두고 대출 여건 악화를 호소한 입주 앞둔 집단(148건), 정비사업 조합(119건), 임차인 집단(105건)입니다. 이들은 단순히 부담을 줄여 달라고 하기보다 이미 제시된 조건과 계획을 이행하라는 말을 자주 썼는데요. 집단 당사자 글의 39%가 약속·원안 이행 요구였고, 다른 발화 유형에서는 이 비율이 4%를 넘지 않았습니다.

개인의 경험을 중심으로 쓴 당사자도 네 유형으로 나뉘었습니다. 실거주 1주택자(415건)는 보유 단계의 세 부담을, 계약·입주 진행자(249건)는 계약 이후 바뀐 대출 조건과 잔금 문제를 주로 말했습니다. 무주택 실수요자(201건)는 대출 문턱과 주거 기회를, 다주택자·임대인(230건)은 중과와 임대 제도를 이야기했고요. 이들 개인 당사자 글의 74%는 부담 완화나 예외를 요구했습니다.

나머지 두 유형은 발화 위치를 밝히지 않았습니다. 훈수형 제안자(1,724건)는 공급 확대, 세제 개편, 대출 기준 등 여러 정책 제안을 내놓은 가장 큰 유형입니다. 하나의 이해당사자 집단이라기보다, 부동산 정책에 대한 다양한 의견을 낸 집단입니다. 규제 강화 요구자(287건)는 자신의 피해보다 투기 수요나 다주택자처럼 규제해야 할 대상을 지목했습니다.

10가지 유형은 사람을 고정된 신분으로 분류한 결과가 아닙니다. 이 게시판에서 글쓴이가 자신을 어디에 놓고 말했는지를 구분한 것에 가깝습니다. 같은 사람도 다른 상황에서는 다른 유형의 목소리를 낼 수 있으니까요.

세금은 원칙을, 대출은 시점을, 공급은 약속에 대해 얘기한다

게시판의 큰 정책 영역은 공식 카테고리인 부동산세제, 주택금융, 주택공급(규제)이었습니다. 글 속에서는 각각 세금, 대출, 공급·정비의 문제로 나타났는데요. 영역마다 두드러진 태도가 달랐습니다.

영역	두드러진 태도	실제로 다투는 것
세금	원칙 반대 34%	보유세·양도세를 누구에게 어떤 기준으로 부과할 것인가
대출	경과조치 20%	새 기준을 이미 진행한 거래에 언제부터 적용할 것인가
공급·정비	이행 요구 25%	재개발 계획, 뉴스테이 분양전환, 용산국제업무지구 원안을 지킬 것인가

세제에서는 부담의 정당성을, 대출에서는 전환 시점을, 공급에서는 계획의 신뢰성을 묻습니다. 같은 규제를 놓고도 다투는 지점이 다릅니다. 정책별로 같은 해법을 적용하기 어려운 이유가 여기 있는 것 같습니다.

함께하는 목소리

텍스트를 분석할 때 유니크 갯수를 따로 보는데요. 본문 내용이 동일한 복붙 글이 꽤 있었습니다. 모아보면 특정 집단에서 오고 있었는데요.

집단 당사자 (25%)
규제 강화 요구자 (1.5%)
개인 당사자 (0.5%)

집단 당사자의 글 넷 중 하나는 본문이 완전 동일했습니다. 조합이나 입주예정자 모임처럼 이미 사람이 모여 있는 곳에서 나온 글이라 그런 것 같습니다. 커뮤니티를 통해서 대표 문안 하나를 만들어 구성원이 나눠 올린 것 같습니다. 실제로 가장 많이 반복된 문안은 제목만 44가지로 바꿔 71번 올라왔습니다. 단순 일치만 셋으니 실제로는 더 많을 수 있습니다. 그렇다고 복붙을 여론 조작의 흔적으로만 읽을 일은 아닌 것 같습니다. 문안을 만들어 나눠 올릴 만큼 절박했다는 뜻이고, 같은 문제를 겪는 사람들이 이미 서로를 찾아 집단을 이뤘다는 신호 이기도 하니까요.

읽고 나서 남은 생각

이 게시판을 국민 전체의 정책 선호로 읽을 수는 없습니다. 자발적으로 참여한 사람들, 그중에서도 더 간절한 쪽이 주도적으로 글을 남기는 공간이니까요. 게시량은 여론의 비율이 아니라 이 공간에서 표현된 요구의 규모 정도로 보는 게 맞을 것 같습니다.

그래도 모든 글에 같은 질문을 던져 보니, 찬성과 반대 사이에 가려져 있던 차이가 조금 드러났습니다. 어떤 사람은 규제의 원칙을 문제 삼고, 어떤 사람은 적용 범위를 조정해 달라고 합니다. 이미 청약하거나 계약한 사람은 정책의 옳고 그름보다, 자신이 선택할 때 제시됐던 조건이 유지되는지를 묻습니다.

같은 규칙도 계약 전에는 하나의 정책 제안이지만, 입주 직전에는 당장 감당해야 할 위험이 됩니다. 10가지 목소리는 서로 다른 진영이라기보다, 같은 정책이 서로 다른 삶의 단계와 만난 결과에 가까워 보입니다. 정부에서는 정책 변화로 실질적 위험에 처한 시민의 목소리를 들을 수 있는 창구 역할이 될 수 있을 것 같습니다.

데이터 분석 방법과 한계

부동산정책 국민 대토론회 의견수렴 게시판 2026년 7월 14–23일 게시글 6,680건. 비공개 1,273건·블라인드 27건·복붙 421건을 제외한 중복제거 고유 공개 의견 4,959건을 분석했습니다. 발화 위치는 원문에 자기·가족·소속집단 근거가 드러난 경우에만 코딩했고, 요구 내용으로 신분을 추정하지 않았습니다. 10개 발화 유형에는 3,895건이 포함됐습니다. 부담 강화 자동 후보 331건은 별도 전수 재판독을 거쳐 291건을 실제 강화 요구로 판정했습니다. 변수 코딩과 유형 분류는 LLM으로 수행하고 일부 표본을 사람이 검수했으며, 개별 판정에는 오류가 있을 수 있습니다. 그 밖의 자동 코딩 수치와 의미 지형도의 군집명은 후속 검증이 필요한 분석 결과입니다.

GEONIQ Integrated Insight Report — GEO 최적화 잘 되어있는 사이트 BEST 5 (Vol.1 실제 진단/분석 결과는?)

GEONIQ — Fri, 24 Jul 2026 17:43:09 +0900

신한금융, KB Think, 카카오뱅크, 이랜드, SK브로드밴드의 대표 콘텐츠 30페이지를 직접 진단했습니다

질문형 제목과 핵심 요약이 있으면 GEO가 잘된 사이트일까?
온라인에서 우수 사례로 소개된 5개 사이트를 GEONIQ으로 진단해, 콘텐츠의 인상과 실제 페이지 상태가 얼마나 일치하는지 확인해봤습니다.

들어가며

구글의 AI 검색 최적화 가이드 발표 이후 SEO/GEO에 대한 다양한 의견과 해석들이 많았습니다. 관련해 GEO 최적화가 잘된 국내 사이트 5곳을 소개한 글에서 언급된 사이트들을 GEONIQ으로 살펴보려 합니다.

신한금융 인사이트는 데이터와 시각 자료를 활용한 콘텐츠, KB Think는 금융 전문 콘텐츠, 카카오뱅크 블로그와 이랜드 E:KI HOW는 실제 검색 질문을 반영한 주제, SK브로드밴드 블로그는 질문형 소제목과 이용자 댓글이 강점으로 소개됐습니다.

이런 특징은 충분히 참고할 만합니다.
질문에 가까운 제목, 핵심 요약, 명확한 소제목, 표와 목록은 사람이 읽기에도 편하고 AI가 내용을 나눠 이해하는 데에도 도움이 됩니다.

그런데 여기서 한 가지 질문이 생겼습니다.
좋은 요소가 몇 가지 보인다는 이유만으로 사이트 전체를 GEO 우수 사례라고 부를 수 있을까요?

저희는 이 질문을 기존 글에 대한 반박이 아니라 검증 과제로 봤습니다.
소개 글이 짚은 콘텐츠의 특징이 실제 페이지 진단에서도 확인되는지 살펴봤습니다. 그리고 사이트마다 어떤 강점과 차이가 나타나는지 직접 확인했습니다.

이렇게 진단했습니다

사이트별로 허브 페이지 1개와 상세 콘텐츠 5개를 선정해 총 30페이지를 분석했습니다.
진단 영역은 다음과 같습니다.

기술 최적화
콘텐츠 품질
성능 및 사용자 경험
콘텐츠 신뢰성
보안 및 정책 준수

종합점수는 GEONIQ의 SEO·GEO 통합 점수를 사용했으며, 선정한 6개 페이지의 측정값입니다. 해당 기업의 모든 페이지나 브랜드 전체의 품질을 평가하는 절대적인 점수가 아니며, 자동진단만으로 판단하기 어려운 저자 전문성, 일시적인 서버 상태, 보안 정책 등은 공개 비교의 핵심 근거에서 제외했습니다.

먼저 숫자부터 보겠습니다

사이트	허브페이지 통합점수	상세 5페이지 통합점수 평균	기술 최적화 평균	콘텐츠 품질 평균	성능·사용자 경험 평균
KB Think	85	81.6	93.6	78.0	100
카카오뱅크 블로그	79	82.8	94.0	83.2	100
SK브로드밴드 블로그	77	79.6	79.6	84.6	100
신한금융 인사이트	69	71.0	74.0	72.4	87
이랜드 E:KI HOW	57	67.0	60.0	85.4	77

* 상세 관련 점수는 선정한 상세 5페이지의 평균이며, 모든 점수는 100점 만점입니다.

<5개 사이트의 상세 페이지 통합점수 평균>

가장 먼저 눈에 들어오는 곳은 KB Think입니다.
허브와 상세 콘텐츠 점수가 모두 80점대를 유지했고, 기술 최적화는 93.6점이었습니다.

카카오뱅크 블로그도 상세 평균 82.8점, 기술 최적화 94점, 사용자 경험 100점으로 안정적인 결과를 보였습니다.

SK브로드밴드와 이랜드 E:KI HOW는 상세 콘텐츠 품질이 각각 84.6점, 85.4점으로 높은 편이었습니다.
하지만 종합점수와 기술·사용자 경험에서는 차이가 나타났습니다.

이번 표본만 놓고 보면 ‘콘텐츠 품질이 높다’와 ‘사이트 전반의 준비 상태가 높다’는 같은 의미가 아니었습니다.

신한금융 인사이트

전문 주제의 강점과 70점대의 페이지 기반

신한금융 인사이트에서 선정한 상세 5페이지의 SEO·GEO 통합점수 평균은 71.0점이었습니다.
성능·사용자 경험 평균은 87점으로 양호했지만 기술 최적화 평균은 74점, 콘텐츠 품질 평균은 72.4점이었습니다.

기존 소개 글이 주목한 것은 금융 데이터와 전문적인 주제를 다루는 콘텐츠의 방향이었습니다.
투자·산업·시장 전망처럼 분석적 가치가 필요한 주제를 다룬다는 점은 분명 참고할 만합니다.

다만 이번 진단에서는 콘텐츠의 주제적 전문성과 페이지 전체의 최적화 상태 사이에 차이가 관찰됐습니다.
전문적인 주제를 다룬다는 사실만으로 기술적 전달과 콘텐츠 구조까지 자동으로 완성되는 것은 아니었습니다.

신한금융 인사이트의 경우 콘텐츠가 가진 전문성을 검색엔진과 AI가 더 쉽게 이해할 수 있도록 결론, 데이터 기준일, 근거 자료를 일관된 구조로 제공하는 방향을 검토할 수 있습니다.

지오닉 검증 결과 바로가기

신한 인사이트 – 불리기

중국의 AI Capex 상황, 과잉일까 아니면 이제 시작일까?

보험금 지급 거절, 왜 생길까? 가장 흔한 3가지 이유

2026년 브라질 국채 투자전략: 금리 인하 ‘골든타임’과 물가

섬유·의복 산업 전망: 브랜드사에서 찾는 밸류에이션 매력과 투자 기회

6월 8일 코스피 역대급 급락, 향후 증시 대응 전략은?

KB Think

이번 표본에서 가장 안정적인 진단 결과

KB Think는 허브 페이지 통합점수 85점, 상세 5페이지의 통합점수 평균 81.6점을 기록했습니다.
상세 페이지의 기술 최적화 평균 93.6점과 성능·사용자 경험 평균 100점도 이번 5개 사이트 가운데 상위 결과였습니다.

청년 금융, 대출, 보험, 연금처럼 사용자가 실제 질문으로 입력할 가능성이 높은 주제를 지속적으로 다루고 있다는 점도 특징적입니다.

이번 30페이지 진단만 놓고 보면, 기존 글에서 소개한 5개 사이트 중 허브와 상세 통합점수가 모두 80점대로 가장 고르게 확인된 곳은 KB Think였습니다.
다만 높은 진단점수가 모든 콘텐츠의 전문성이나 정확성을 보증하는 것은 아닙니다.

특히 금융 콘텐츠는 최초 발행일뿐 아니라 정보의 기준일, 공식 원문 출처, 변경 가능성까지 함께 관리해야 합니다.

지오닉 검증 결과 바로가기

KB Think 메인

2026 청년미래적금 조건, 신청 기간｜청년도약계좌 갈아타기 가능할까?

생애최초, 서민 실수요자 주택담보대출 조건｜LTV·DTI 완화 혜택은?

3대 메가프로젝트｜반도체와 AI에 집중 투자해요

KB 화상상담 서비스｜예금 만기 관리부터 비밀번호 변경까지

고객의 신뢰를 얻는 KB고객언어 가이드

카카오뱅크 블로그

읽고 답하기 좋은 콘텐츠 구조

카카오뱅크 블로그에서 선정한 상세 5페이지의 통합점수 평균은 82.8점이었습니다.
기술 최적화 평균은 94.0점, 콘텐츠 품질 평균은 83.2점, 성능·사용자 경험 평균은 100점이었습니다.

확인한 콘텐츠에는 핵심 요약, 질문형 소제목, 체크리스트가 비교적 명확하게 구성돼 있었습니다.
필진과 관련 콘텐츠를 확인할 수 있는 영역도 제공합니다.카카오뱅크 공식 콘텐츠 예시
기존 소개 글이 주목한 ‘실제 질문에 가까운 주제’와 ‘요약·소제목 구조’는 이번 확인에서도 유효했습니다.

이제 남는 질문은 이런 페이지 구조가 실제 AI 답변의 출처 인용으로도 이어졌는가입니다.
이 부분은 2편의 AI 인용 실측 결과에서 살펴보겠습니다.

지오닉 검증 결과 바로가기

카카오뱅크 answer 홈

대출 있는 집에 전세로 들어가도 될까요?

내 신용점수, NICE와 KCB 왜 다르게 나올까?

카카오뱅크에서 거래내역서는 어떻게 발급받나요?

MMF, CMA, 파킹통장은 무엇이 다를까?

카카오뱅크 고객센터 찾기 전, 궁금증 해결하고 싶다면?

이랜드 E:KI HOW

콘텐츠 점수와 기술 점수의 간격

이랜드 E:KI HOW의 상세 콘텐츠 품질 평균은 85.4점이었습니다.
반면 상세 통합점수 평균은 67.0점, 기술 최적화 평균은 60점, 성능·사용자 경험 평균은 77점이었습니다.

생활 속 질문을 다루고 바로 활용할 수 있는 정보를 제공한다는 콘텐츠 방향은 분명한 특징입니다.
그러나 이번 표본에서는 콘텐츠 품질과 기술·사용자 경험 사이의 점수 차이가 가장 크게 나타났습니다.

이 결과는 좋은 콘텐츠 소재만으로 사이트 전체의 GEO 준비 상태를 설명하기는 어렵다는 점을 보여줍니다.
콘텐츠의 실용성을 유지하면서 기술적 접근성과 사용자 경험을 함께 개선하는 것이 다음 단계가 될 수 있습니다.

지오닉 검증 결과 바로가기

E:KI HOW 목록

반찬 없을 때 무조건 ‘이것’ 드세요—가지 레시피

다진 마늘은 ‘이렇게’ 보관하세요

찌든 얼룩엔 ‘이것’을 문지르세요

다이어트할 때 우유는 안 좋고, 치즈는 좋은 이유

2026년 유행하는 가방에는 모두 ‘이 디테일’이 숨어 있을 거예요

SK브로드밴드 블로그

질문형 콘텐츠와 유지관리의 중요성

SK브로드밴드 블로그는 상세 콘텐츠 품질 평균 84.6점, 성능·사용자 경험 평균 100점을 기록했습니다.
인터넷 설치, 장애 조치, 셋톱박스와 리모컨처럼 사용자가 실제로 궁금해할 만한 문제를 제목과 소제목으로 구성하고 있었습니다.
목차와 FAQ를 적극적으로 사용한다는 점도 확인할 수 있었습니다.

기존 소개 글이 주목한 질문형 콘텐츠 구조는 실제 페이지에서도 비교적 뚜렷하게 나타났습니다.
다만 요금제·프로모션처럼 변경 가능성이 높은 콘텐츠는 구조만큼 유지관리가 중요합니다. 이 부분은 2편에서 실제 페이지 사례와 함께 살펴보겠습니다.

지오닉 검증 결과 바로가기

SK브로드밴드 공식 블로그

SK브로드밴드 인터넷 접속이 안 될 때 셀프 조치 방법

새 집 인터넷 설치할 때 알아두면 편리한 3가지 체크사항

셋톱박스 하나로 TV 두 대 볼 수 있어요?

B tv 리모컨 작동하지 않을 때 셀프 조치 방법

인터넷 가입, B 다이렉트샵에서 해야 하는 이유

이번 진단에서 확인한 것

이번 진단의 목적은 어느 사이트가 더 좋다고 절대적인 순위를 정하는 것이 아닙니다.
같은 GEO 우수 사례로 소개된 사이트라도 강점이 나타나는 영역이 서로 달랐다는 점을 확인하는 것이었습니다.

KB Think는 기술과 통합점수가 함께 안정적이었습니다.
카카오뱅크는 기술과 콘텐츠 구조가 모두 양호했습니다.
SK브로드밴드는 질문형 콘텐츠와 성능·사용자 경험이 강했습니다.
신한금융은 전문 주제를 다뤘으며, 선정한 상세 페이지의 통합점수 평균은 71.0점이었습니다.
이랜드는 콘텐츠 품질 점수보다 기술 최적화와 성능·사용자 점수가 상대적으로 낮게 나타났습니다.

페이지 구조가 좋다는 것과 실제 AI가 해당 콘텐츠를 출처로 선택한다는 것은 또 다른 문제입니다.

다음 편에서는 5개 사이트의 콘텐츠 주제로 질문 30개를 만들고, ChatGPT, Gemini, Perplexity에 총 90회 질의한 결과를 살펴보겠습니다.

1편 측정 기준

페이지 진단일 : 2026년 7월 24일

대상 사이트 : 5개

대상 페이지 : 사이트별 허브 1개, 상세 5개 (총 30페이지)

종합점수 : GEONIQ (SEO·GEO) 통합 점수

유의사항 : 선정 페이지의 측정 결과이며 사이트 전체에 대한 절대 평가가 아님

GEONIQ 서비스 바로가기

구글의 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