pxd story

검색에는 보이는데, 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으로 연락주시기 바랍니다.

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가 코드를 생산해 내는 지금 같은 시대에서는 거대한 생태계와 생태계가 어떤 흐름을 타고 있는지가 생각보다 중요하더라고요. 기회가 되면 다른 프레임워크의 생태계도 확인해 보면 재미있을 것 같습니다.

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/ 에서도 보실 수 있습니다.

AI 리서치 파트너, Affinity Bubble 서포터즈 1기를 모집합니다

yewon.jang — Tue, 19 May 2026 07:50:02 +0900

방대한 인터뷰와 설문 데이터 속에서 의미 있는 인사이트를 찾기 위해 고군분투해 오셨나요? pxd의 UX 노하우를 담아 정성 데이터 분석의 새 길을 열어가는 어피니티버블(Affinity Bubble)이 더 강력해진 v1.1 업데이트와 함께, 서비스의 완성도를 함께 높여갈 서포터즈 1기를 모집합니다.

어피니티버블은 인터뷰, 앱 리뷰, 설문 등 흩어진 정성 데이터를 AI로 분석해 어피니티 다이어그램 형태의 버블 시각화로 보여주는 도구입니다. 어피니티버블이 실무자분들에게 정말 유용한 도구로 진화할 수 있도록, 여러분의 현장감 넘치는 의견을 들려주세요.

1️⃣ 서포터즈는 어떤 활동을 하나요?

어피니티버블 서포터즈 1기의 자격 유지 및 활동 조건은 아래와 같습니다. 부담 갖기보다는 어피니티버블과 함께 즐겁게 연구하고 소통해 주시면 됩니다!

어피니티버블로 만든 분석 결과를 SNS에 공유하기 (월 2회)
- 어피니티버블을 쓰며 발견한 흥미로운 데이터 분석 결과를 개인 SNS 채널에 공유해 주세요.
- 활용 가능한 SNS: 링크드인, 브런치, 티스토리, 네이버 블로그, 인스타그램, X(트위터), 페이스북
- 필수 해시태그: #어피니티버블 #AffinityBubble #데이터분석
분석이 필요한 주변 동료들에게 즐겁게 추천하기
- 동료 리서처, 기획자, 마케터 분들에게 어피니티버블을 널리 알려주세요.
3개월 활동 종료 시점 피드백 설문 참여
- 활동이 마무리되는 시점에 어피니티버블의 발전을 위한 솔직한 피드백 설문에 참여해 주세요.

여러분이 SNS에 공유해 주신 소중한 포스트는 어피니티버블 공식 계정에서 적극적으로 공유하고, 월간 우수 사례는 공식 SNS에 소개됩니다.

2️⃣ 서포터즈 분들을 위해 준비한 혜택

서포터즈 분들이 데이터 분석과 연구에 몰입하실 수 있도록 다채로운 혜택을 지원합니다.

Business 플랜 지원
대량 데이터 분석이 가능한 최고 요금제(매월 59,800원 상당)를 서포터즈 자격 유지 동안 무상으로 제공합니다.
지인 추천 쿠폰 매월 3장 지급
주변 동료들에게 선물할 수 있는 'Standard 플랜 30일 무료 사용권' 쿠폰을 매달 3장씩 챙겨드립니다.
신기능 선사용 혜택
신기능 정식 출시 전, 유용한 기능들을 가장 먼저 테스트해 보고 피드백에 참여할 수 있습니다.
온오프라인 밋업 우선 초대
어피니티버블만의 인사이트 공유 밋업 및 네트워킹 행사를 최우선으로 안내해 드립니다.

3️⃣ 모집 일정 및 안내

신청 기간: 5월 19일(화) ~ 5월 31일(일)
선정 결과 발표: 6월 8일(월) (개별 안내)
신청 링크: (모집이 마감되었습니다. 감사합니다.)

정성 조사의 규모와 속도, 인사이트를 함께 키워갈 리서처, 기획자, 마케터 분들의 많은 관심과 참여를 기다립니다.

서비스 및 서포터즈 관련 문의는 support@affinitybubble.com 으로 주세요.

어피니티버블 서포터즈 1기 신청

어피니티버블 사용하러 가기

컬러 토큰 설계 3가지 방식 (스케일 / 시멘틱 / 하이브리드)

워킹맘 루나 — Mon, 18 May 2026 07:50:07 +0900

AI의 등장과 디자인 자동화가 본격화되면서, 이제는 작업 속도 자체보다 그 속도 안에서도 서비스의 일관성을 끝까지 유지할 수 있는지가 더 중요해졌습니다.

한 때는 정말 픽셀 하나, 간격 하나에 목숨 걸며 그 정교함이 디자인의 실력을 가늠하는 기준처럼 여겨지던 시절도 있었는데요.
이제는 손으로 어떻게 만들었는지보다, 어떤 기준을 세워 그 결과가 나오도록 만들었는지가 더 중요해졌다는 것이죠.

이러한 변화 속에서 디자인 시스템은 서비스를 안정적으로 운용하기 위한 핵심 인프라로 자리 잡았으며, 이를 전담 조직으로 운영하는 기업 역시 빠르게 늘어나고 있습니다.
그렇다면 디자인 시스템 중에서도 가장 기초이면서도, 동시에 가장 큰 영향을 미치는 컬러 토큰 설계는 어떤 관점에서 접근해야 할까요?

최근 진행했던 프로젝트에서 컬러 토큰 체계를 새롭게 구축하는 과정에서 얻은 경험과 인사이트를 바탕으로, 컬러 토큰 설계를 어떤 관점에서 선택하고 구조화할 수 있는지 공유해보려고 합니다.

컬러 토큰의 기본 개념은 아래 글을 참고하세요 :)
3. 유연함을 갖춘 시맨틱 컬러 시스템
4. 균일한 대비값을 가진 스케일 컬러 시스템

컬러 토큰 설계 방식 살펴보기

디자인 토큰은 '무엇(Scale)'인지와 '어디(Semantic)'에 쓰이는지에 따라 스케일 중심, 시멘틱 중심, 그리고 두 방식을 접목한 하이브리드 구조로 설계할 수 있어요.

1) 스케일 토큰 : 가장 직관적이고 빠른 시작

스케일 토큰의 가장 큰 장점은 '무엇(기초값)'인지를 바로 이야기 하기 때문에 별도의 해석이나 학습, 합의 같은 과정이 필요없다는 거예요. 이는 스케일 토큰이 디자인 과정에서 만들어지는 공통 컬러 팔레트를 구조화 하고, 이를 코드화해 관리하는 방식이기 때문이죠.

스케일 토큰

예를 들어 포인트 컬러로 #1244C5(Hex값)를 사용하는 Blue가 있다면, 이 값을 기준으로 밝기와 톤을 조정해 컬러 스케일을 정의하고 $blue-100, $blue-300, $blue-500처럼 단계별 값으로 관리하는거죠. 이렇게 정의된 스케일 토큰을 “주요 액션 버튼에는 $blue-500을 사용한다”와 같은 가이드를 통해 디자이너와 개발자 간에 바로 커뮤니케이션될 수 있어요.

하지만 서비스의 복잡도가 높아진다면 이야기는 달라지죠.

기초값으로만 정의되어 있기 때문에 그 색을 ‘왜' 여기에 썼는지 맥락이 남아있지 않은 상태로 존재하게 되는데요.
이로인해 서비스의 확장이 어려울 수 있어요. 의미와 목적이 명시되어 있지 않기 때문에 기존 화면을 다시 분석하거나, 히스토리 추적을 해야하는 불필요한 공수가 발생하게 되죠.

또한 공통 수정이 필요한 경우에도 해당 색이 사용된 화면을 직접 찾아 맥락을 파악하고, 코드까지 함께 수정해야 하는 상황이 반복되며 시간이 지날수록 누적되어 부채로 남게 되기도 합니다.

그래서 관리자는 서비스의 방향성과 디자인 맥락을 충분히 이해한 상태에서, 새로운 색이 언제, 어떤 기준으로 스케일에 편입되는지를 꾸준히 트래킹하고 관리해야 해요. 관리자의 판단이 서비스의 품질과 확장 비용에 직접적인 영향을 미치기 때문이죠.

이런 이유로 스케일 토큰 중심 설계는 설계에 투입할 수 있는 리소스가 제한된 초기 프로젝트나, 최소한의 브랜드 컬러를 중심으로 빠른 대응이 필요한 서비스, 혹은 브랜드 아이덴티티를 깊이 이해한 디자이너가 주도하는 소규모 팀에 적합한 구조라고 볼 수 있어요.

2) 시멘틱 토큰 : 다양한 환경에 유연한 대응

시멘틱 토큰 중심 설계는 색상 값 자체보다, 그 색이 어떤 역할과 상태를 가지는지를 먼저 정의하는 방식입니다.
UI 맥락에 맞는 토큰명을 먼저 정하고, 그 안에 실제 Hex 값을 연결해 사용하는 구조라고 볼 수 있어요. 이렇게 설계하면 디자인과 개발 모두가 색을 값이 아니라 역할과 맥락의 관점에서 다루게 돼요.

시멘틱 토큰

예를 들면 “블루를 사용한다”가 아니라 “이 블루는 버튼에 사용한다" 라고 말해주는 거라고 보면 쉬워요. 색 자체보다, 어디에 쓰이는지 목적을 명확히 해주는거죠. 이처럼 공통으로 합의된 의미로 소통하기 때문에 각자의 해석이 개입할 수 없다는 점이 가장 큰 장점이에요. 그 결과 시스템 전반의 일관성을 비교적 안정적으로 관리할 수 있어요.

그래서 시멘틱 토큰 중심 설계는 멀티 테마를 운영하거나, 접근성 기준을 체계적으로 반영해야하는 서비스에서 특히 효과적으로 활용할 수 있어요. 색에 대한 합의가 구조 안에 들어가면서 커뮤니케이션 비용일 확실히 줄어들어요.
이미 코드에는 '의미'로 부여되어 있기 때문에 "버튼의 배경색을 라이트 모드에서는 블루를 쓰고, 다크 모드에서는 화이트를 써." 처럼 의도만 전달해주면 구체적인 색상 값은 시스템이 알아서 처리하는거죠.

다만 시멘틱 토큰 중심 설계는 초기 설계와 합의 과정에 드는 비용이 비교적 큰 편이에요.
각 컬러가 어떤 역할을 하고, 어디까지 사용될 수 있는지를 미리 정의해야하고, 토큰 이름 하나하나에도 조직 차원의 합의가 필요하기 때문이죠. 이 과정이 충분하지 않으면 의미가 모호한 토큰만 늘어나게 되고, 결국 관리하기 어려운 구조로 이어지면서 코드 부채가 쌓이게 될 가능성도 커져요.

시멘틱 토큰은 "결정론적 디자인"이라고 볼 수 있어요.
어떠한 상황에서도 시스템이 예측 가능한 결과물을 내놓아야한다는게 기본 전제죠.
그렇다 보니 디자인은 제한적일 수 밖에 없고, 디자이너의 역할 역시 그 기준 안에서 판단하고 적용하는 오퍼레이터의 역할로 축소되죠.

그래서 시멘틱 토큰 중심 설계는 브랜딩이 강한 서비스보다 Hexagrid와 같이 다국어, 다중 테마 등과 같이 유연하게 대응해야 하는 서비스에서 활용도가 높아요. 일관된 기준을 유지한 채로 변화를 관리해야 하는 경우에 강점을 발휘하는 방식이라고 볼 수 있어요.

3) 스케일과 시멘틱의 하이브리드 : 변화에 강한 시스템 구조

스캐일과 시멘틱 토큰의 관계

하이브리드 구조는 스케일 토큰과 시멘틱 토큰의 강점을 접목해서 설계하는 방식이라고 볼 수 있어요.
디자인 컬러값은 스케일 토큰으로 설계해 디자인 유연성을 열어두고, 소통은 의미와 맥락을 담아 시멘틱 토큰으로 적용해 소통과 운영을 구조화하는 방식이에요.

예를 들어 $blue-100, $blue-300, $blue-500 등 과 같은 스케일 토큰을 정의한 뒤, 이를 $fill/brand/primary처럼 역할이 명확한 시멘틱 토큰에 연결해 사용하는 방식이에요. 화면과 디자인 커뮤니케이션에서는 의미를 담고 있는 시멘틱 토큰명으로 소통하고, 실제 색상 값의 변경이나 조정은 스케일 토큰 단계에서 관리를 하게 되는 구조죠.

이 구조의 가장 큰 장점은 유연성과 확장성을 동시에 가져갈 수 있다는 거에요.

리브랜딩처럼 컬러 조정이 필요할 경우, 스케일 토큰 값만 변경하면 이와 연결된 시멘틱 토큰도 자동으로 업데이트되면서 제품 전반에 한 번에 반영할 수 있죠.

컬러 테마를 추가할 경우도 마찬가지예요. 이미 시멘틱 토큰 기준으로 구조가 잡혀 있기 때문에, 테마별로 참조하는 컬러 스케일만 정의해주면 새로운 테마도 비교적 수월하게 확장할 수 있어요. 이 덕분에 컬러 변경이 화면 수정이 아니라, 구조를 조정하는 작업으로 바뀌게 되는거죠.

이런 이유로 서비스의 확장성과 유연성을 동시에 만족해야 하는 기업들에서는 하이브리드 구조를 많이 선택하고 있어요.
실제로 당근이나 토스처럼 서비스 규모가 크고, 다양한 환경과 사용 맥락을 함께 고려해야 하는 경우에 이 구조가 효과적으로 활용되고 있는 것으로 알려져 있어요. 특히 당근의 사례를 보면, 시멘틱 토큰 단계에서 가독성과 대비 기준을 함께 고려하는 접근을 취하고 있고, APCA 알고리즘* 과 같은 지각 대비 기준을 참고해 기기 모드나 환경에 따라 컬러 명도가 자연스럽게 조정될 수 있는 적응형 컬러 구조를 설계한 것으로 소개되고 있어요.

※ APCA 알고리즘 이란?
APCA는 단순한 명도 차이가 아니라, 사람이 실제로 인식하는 가독성을 기준으로 텍스트와 배경의 대비를 계산하는 알고리즘이에요.
기존의 WCAG 대비 비율이 숫자 중심의 기준이었다면, APCA는 글자의 크기, 두께, 화면 환경까지 고려해 “이 텍스트가 읽히는가”를 판단하는 데 초점을 둡니다. 그래서 다크 모드나 다양한 기기 환경에서도 보다 안정적인 가독성을 확보하는 데 활용되고 있어요.
또한 현재 개발 중인 WCAG 3.0에서 이 APCA를 새로운 색상 대비 표준으로 채택할 예정이라고 해요.

이런 구조에서는 스케일 토큰이 변경될 때, 대비 부족으로 인해 가독성이 떨어질 가능성을 화면 단위가 아니라 토큰 단계에서 미리 발견하고 조정할 수 있어요. 이게 가능한 이유는 스케일 토큰으로 컬러가 묶여져 있고, 이 값이 시멘틱 토큰을 통해 어디에, 어떤 목적으로 사용되는지 명확하게 정의되어 있기 때문이에요.

하지만 하이브리드 구조는 단일 구조로 설계할 때보다 초기 설계 비용이 더 많이 드는 방식이기도 합니다.
스케일 토큰과 시멘틱 토큰을 각각 설계해야 할 뿐만 아니라, 두 계층을 어떻게 연결할지에 대한 구조까지 함께 고민해야 하기 때문이에요.

초기 설계가 충분히 정리되지 않은 상태에서 하이브리드 구조를 도입하면, 값과 의미가 동시에 늘어나면서 토큰 수가 과도하게 증가하는 이른바 ‘토큰 스프롤(Token Sprawl)’ 상태로 이어질 수 있습니다.
이 경우 문제는 문서나 구조에만 머무르지 않고, 색의 일관성 저하나 가독성, 속도 문제처럼 서비스 품질로 바로 체감되기 시작하죠.

그래서 하이브리드 구조에서는 새로운 토큰을 추가할 때마다 “이건 새로운 값의 문제인가, 아니면 새로운 의미의 문제인가”를 먼저 판단하는 과정이 중요해요. 이 기준이 명확할수록 토큰 구조는 불필요하게 비대해지지 않고, 확장성과 안정성을 비교적 균형 있게 유지할 수 있습니다.

그래서, 어떤 선택이 우리에게 맞을까

컬러 토큰 체계를 도입할 때, 서비스가 지금 어떤 단계에 있는지, 무엇을 가장 우선해야 하는지를 분명히 짚고 넘어가야 합니다.
당연한 이야기처럼 들릴 수 있지만, 방향이 정리되지 않은 상태에서 특정 ‘방식’부터 선택해버리면 이후에 감당해야 할 리스크는 생각보다 훨씬 커져요.

이와 함께 조직의 구조와 성격도 아주 중요한 고려사항이에요.
디자인 중심의 의사결정이 중요한 조직인지, 개발 중심으로 빠른 구현이 우선되는 환경인지, 혹은 협업과 유연함을 얼마나 중시하는지에 따라 적합한 설계 방식을 채택해야하죠.

그리고 무엇보다 중요한 건, 그 선택을 팀 안에서 하나의 ‘약속’으로 명확히 공유하는 일이라고 생각해요.
컬러 토큰은 개인의 취향이나 노하우가 아니라, 함께 일하는 사람들이 같은 기준으로 판단하고 움직이기 위해 합의한 구조이기 때문입니다. 결국 컬러 토큰 설계의 완성도는 어떤 방식을 선택했느냐보다, 그 기준을 팀이 얼마나 일관되게 이해하고 지켜나가느냐에 달려 있습니다.

서울 시민의 목소리를 시각화하기

無異 — Thu, 14 May 2026 19:46:44 +0900

시민의 목소리를 데이터로

UI 디자인을 할 때 늘 부딪히는 문제가 있습니다. 다양한 의견을 가진 사용자의 목소리를 어떻게 정리하고 전달할까. 개개인의 목소리에 집중하면 맥락과 목표가 저마다 다른 모두를 만족시키기 어렵고, 그렇다고 평균을 내면 누구도 대표하지 못해 모두가 만족하지 못하는 디자인이 됩니다. 그래서 보통 퍼소나로 사용자를 몇 가지 유형으로 나눠 접근하게 됩니다.

정원오 서울시장 후보가 만든 '서울의 목소리'는 비슷한 문제를 도시 단위로 마주하고 있습니다. 서울 시민의 불편과 고충을 수집해 데이터 기반 해법을 찾고, 그 데이터를 공공데이터로 모두에게 공개하고 있습니다. 수천명의 시민 목소리를 어떻게 정리해 보여주고 있는지, 거기에서 어떤 정보를 얻어낼 수 있는지 시각화 측면에서 살펴보았습니다.

설문을 통해 시민의 의견을 수집하는데, 세개의 주관식 문항이 주된 질문입니다.

서울 생활에서의 고충
차기 서울시장에게 바라는 점
서울하면 떠오르는 키워드

정성 데이터를 보여주는 방식

서울의목소리 사이트는 데이터를 두 갈래로 보여줍니다. 개별 목소리를 그대로 보여주는 방식과 통계로 보여주는 방식입니다.

개별 목소리

지도 위 시각화: 응답한 위치마다 카테고리별 픽토그램과 색으로 구분된 마커를 띄우고, 클릭하면 한 명 한 명의 글을 읽을 수 있습니다.
카드 목록: 의견을 카드 형태로 나열해 훑어볼 수 있게 했습니다.

공간 맵핑

카드형 시각화

시민 개개인의 목소리가 단위입니다. 개개인의 목소리가 흐려지지 않고 그대로 전달된다는 장점이 있지만, 수천개나 되는 모든 의견을 모두 읽기는 어렵고 전체 그림이 전달되지는 않습니다.

통계

막대 그래프, 파이 차트 - 범주별 빈도 (전체와 세분화)
버블 차트 (키워드 빈도, 워드클라우드의 변형)

범주형 바 그래프

세그먼트별 범주 차트

카테고리, 성별, 세대, 지역구처럼 정해진 값을 가지는 범주형 변수는 비율을 계산할 수 있으니 막대 그래프나 파이 차트 같은 시각화 방법을 많이 사용합니다. 그리고 세대나 성별 같은 범주로 세분화하여 어떤 차이가 있는지 세그먼트 분석도 많이 합니다. 여기에서는 범주를 하나 하나를 바꿔가며 비교하는 (stacked in time) 방식을 사용하였는데, 공간에 펼쳐놓으면 (adjacent in space) 한눈에 비교할 수 있어 좋습니다.

아래는 고충 카테고리를 연령별로 순위 변화를 띠 형태로 쌓아놓은 충적도(Alluvial Diagram)로 그린 것입니다. 연령대라는 변수에 따라 어떤 고충이 있는지 교차분석할 수 있습니다. 순위가 바뀌면 단층처럼 끊어져 보여 변화가 강조됩니다. 남성은 거의 모든 연령대에서 집값에 대한 고민이 가장 많고. 40대까지는 출퇴근 교통에 대한 고충이 2위였지만 50대부터는 낮아지고 물가 생활비가 x자로 교차하며 더 높아지는 것이 보입니다. 은퇴 연령대를 생각하면 납득이 됩니다.

남성 연령대별 고충 충적도

하지만 20,30 대 여성에서는 전혀 다른 모습인데요. 남성 응답에서는 거의 보이지 않는 안전·치안에 대한 고충이 가장 높습니다. 특히 20대에서는 71%가 안전·치안을 서울의 가장 큰 고충으로 얘기하면서 여성을 대상으로 하는 범죄와 차별에 대해 큰 목소리를 내고 있습니다. 남성과 여성이 전혀 다른 서울에 살고 있는 셈입니다. 이 차이는 뒤에서 좀 더 자세히 살펴 보도록 하겠습니다.

여성 연령대별 고충 충적도

주관식 응답의 시각화

시각화는 보통 정량 데이터를 다룹니다. 빈도, 비율, 추세 처럼 수치화 할 수 있는 데이터는 막대·선·지도 같은 익숙한 형태로 옮길 수 있습니다. 반면 정성 데이터를 시각화하는 일은 훨씬 까다롭습니다. 가장 익숙한 방식이 워드클라우드인데, 단어를 세어 정성을 정량으로 환원하는 방식으로 기계적으로 쉽게 처리할 수 있기 때문입니다. 하지만 그 과정에서 위계도 맥락도 담기지 않는 문제가 있습니다. 주관식 설문 같은 자유 응답을 분석할 때는 응답에 레이블링을 하고 이를 토대로 귀납적으로 범주를 만드는 코딩 작업을 거칩니다. 빈도를 계산하면 위에서와 같은 범주형 데이터를 시각화하는 방식을 사용할 수 있습니다.

서울하면 떠오르는 키워드 같은 열려있는 질문에 대해서 버블 차트 형태로 Top 10 키워드를 보여주고 있습니다. 보통 워드클라우드를 많이 사용하는데 빈도에 따라 단순히 글자 크기를 다르게 하면 같은 빈도라도 긴 단어는 시각적으로 더 커보여서 왜곡할 수 있습니다. 이런 경우 버블의 크기로 나타내면 정량적인 정보를 더 잘 가늠할 수 있습니다. 이때 정량값이 시각적 면적에 비례하도록 그리는 게 중요합니다. 여론조사 꽃이 후보 적합도를 지름에 비례하게 그리는데요. 지름을 값에 맞추면 면적은 제곱에 비례해 커지기 때문에, 실제 차이보다 훨씬 크게 인식됩니다. 차이를 강조하려는 의도일 수도 있지만, 그 강조가 인지를 왜곡하기도 합니다.

키워드를 보여주는 방식은 최상위 빈도 일부를 보여주는데 그치는 경우가 많습니다. 표준분포에서는 주요 값이 과반을 차지하는 것과 다르게 이런 정성값은 긴 꼬리 분포가 되는 경우가 많아 상위 일부에 그칩니다. 이 데이터에서도 상위 10개가 전체의 약 30% 만을 설명합니다.

전체의 큰 모습을 보여주면서도 개별 목소리의 디테일을 잃지 않는 시각화는 가능할까요? 이 빈자리를 어떻게 메울 수 있을지 살펴보겠습니다.

서울 키워드 지도 - 워드클라우드의 대안

모든 키워드를 표시하면서도 복잡해 보이지 않으려면 시각적 위계를 갖추는 것이 핵심입니다. 정보량이 많더라도 위계가 있으면 인지 부담을 줄일 수 있습니다.

정보 위계를 만들기 위해 어피니티버블을 사용했습니다. 임베딩 클러스터링과 LLM을 이용해 사람이 하는 범주화 코딩 작업을 간소화한 도구입니다. 비슷한 키워드를 묶어 레이블을 붙이고, 한 번 더 큰 도메인으로 분류해 3단계의 계층을 만들었습니다. 그렇게 정리한 데이터를 가지고 개별 키워드 하나하나가 드러나도록 force 시뮬레이션으로 키워드가 겹치지 않게 배치했습니다. 워드클라우드는 단어를 무작위로 배치하는 반면에 의미가 가까운 키워드가 자연스럽게 모이도록 공간의 위치가 정보값을 가지도록 했습니다. 가장 큰 위계는 색상으로 구분되어 쉽게 인지할 수 있습니다. 비슷한 의미 덩어리를 묶고 요약 레이블을 붙여 주었습니다. 클러스터 안에는 개별 키워드가 모두 살아 있어 확대하면 확인할 수 있습니다. 어피니티버블이 보로노이트리맵으로 위계와 크기로 정량적 비율을 잘 나타내는데 초점을 맞추었다면 워드맵은 위계를 조금 흐리게 하는 대신 개별 텍스트와 공간적인 위치정보를 강조한 자매 시각화 방법입니다.

서울 키워드 지도

이렇게 보면 전체의 시각적 위계와 의미 유사도가 함께 드러나는 키워드 지도가 됩니다. 키워드에는 숨겨진 맥락이나 여러 의미가 있을 수 있어서 분류가 완벽하게 객관적이지는 않습니다. 다른 관점으로 해석할 여지도 있고 기계 분석의 한계도 있습니다. 하지만 빠르게 전체적인 지형도를 파악할 수 있다는 장점이 있습니다.

여기서 저는 한강을 남산, 경복궁, 광화문 등과 함께 서울의 랜드마크로 묶었습니다. 글로벌, 다양성, 인프라, 편리함 등은 역동적 정체성으로, 수도·중심 같은 단어는 수도 상징성으로 묶었습니다. 이 세 범주는 서울의 긍정적인 부분에 해당합니다.

나머지는 부정적인 이미지를 나타내고 있습니다. 각박하고 복잡한 대도시, 범죄의 위험, 차갑고 삭막하고 불평등한 도시, 인구 과밀로 인한 복잡함, 교통 혼잡, 비싼 집값 같은 키워드들이 서울의 이미지를 만들고 있었습니다. 상위 10개의 키워드로는 보이지 않던 서울의 양면성이 지도에 드러납니다. 긍부정 분석에 따라 컬러 맵핑을 해보아도 차이가 보입니다.

긍부정분석 컬러 맵핑

세대별로 갈리는 서울의 이미지

전체 오버뷰 말고 집단을 세분화해 보면 또 다른 발견이 보입니다. 세대별로 교차 분석을 하면 40대 이상은 서울을 눈에 보이는 랜드마크로 많이 인식하지만, 20대는 사회적 불평등과 과밀된 도시를 더 많이 떠올립니다. 같은 도시에서 세대에 따라 서울의 인상이 다릅니다.

세대별 서울 연상 키워드

데이터 분석의 한계 — 자발적 응답의 편향

여론조사처럼 무작위로 표집한 것이 아니라 응답자가 자발적으로 참여한 설문이라 선택편향(self-selection bias)이 있습니다. 자발적 참여의 편향은 보통 두 갈래로 나뉩니다.

동기 편향 — 불편을 크게 느끼는 사람일수록 응답 동기가 큽니다. 별로 불편한 게 없는 시민은 굳이 시간을 들여 길게 답을 쓰지 않습니다. 그래서 응답자 풀은 불만의 강도가 평균 이상인 시민 쪽으로 쏠립니다. 정책 입안 입장에서는 시급한 문제를 잘 잡아내는 장점이지만, 동시에 문제의 보편성을 과대평가할 위험이 있습니다.

도달 편향 — 사이트에 닿을 수 있는 경로 자체가 한정되어 있습니다. 어떤 채널로 홍보됐는지에 따라 응답자 풀의 인구 구성이 달라져 모집단을 충분히 대표하지 못하게 됩니다.

응답자 성별 연령별 분포를 보면 서울 시민 인구와는 구성이 많이 다릅니다. 20대에서 여성이 과표집되고 남성은 과소표집되었습니다. 온라인 설문 참여다 보니 60, 70대에서의 의견은 충분히 반영되지 않은 것 같습니다.

[응답자 vs 서울 인구 분포 비교 차트]

타임라인을 보면 이유를 알 수 있는데요. 4월 23일 정원오 후보가 트위터에 사이트를 알린 당일과 다음날 응답이 폭발적으로 증가했는데, 대부분이 20대 여성이었습니다. 특정 네트워크 안에서 리트윗과 노출이 일어나며 응답자 구성 자체가 한쪽으로 치우친 것으로 보입니다. 서울 시민에게 골고루 도달한 채널이 아니라 특정 커뮤니티에 집중된 채널이 되면, 그 채널의 인구 구성이 데이터의 인구 구성을 그대로 결정해 버립니다.

[타임라인 + 성-연령 히트맵]

일자별 응답자 수

여론조사에서는 이런 경우 응답자 분포를 인구 분포에 맞추는 셀 가중치를 적용해 보정합니다. 그런데 자발적 참여 데이터에 같은 방법을 적용하면 오히려 정밀도 과잉을 만들어 낼 수 있습니다. 가중치는 셀 안의 응답자가 비응답자를 대표한다고 가정하는데, 응답자 안에 이미 편향이 남아 있으면 가중치만으로는 그 집단을 대표하게 만들 수 없습니다. 아래 차이를 보면, 응답자 안에서도 응답이 폭증했던 이틀간의 20대 여성은 다른 날의 응답자와도 결이 다르다는 걸 알 수 있습니다. 하지만 앞에서 살펴본 20대 여성의 안전·치안에 대한 고충은 편향을 감안하더라도 보편적인 신호라는 것 역시 분명합니다.

응답이 많았던 이틀간 응답자의 편향

그래서 이 데이터는 서울 시민 전체의 목소리를 대표한다기보다 참여한 사람들의 목소리로 읽는 게 좋겠습니다. 비율과 순위 같은 정량 수치를 일반화하려 하기보다, 어떤 목소리가 어떤 결로 모이는지 정성적인 측면에 초점을 맞춰 보는 것입니다. 이어지는 범주별 분석도 그런 시선으로 보면 좋겠습니다.

주요 범주별 서울 시민 고충 어피니티버블

안전, 치안

안전·치안 카테고리에서는 여성 응답자가 압도적으로 많았습니다. 많은 여성이 여성 대상 범죄와 유해환경과 치안에 대해 불안해 하고 있습니다. 남성과 여성의 안전에 대한 체감이 확연히 다릅니다. 개별 시민의 목소리는 어피니티버블에서 확인할 수 있습니다.

물가,생활비

이 범주는 성별·세대 구분 없이 고르게 응답이 모였습니다. 임금 대비 물가와 생활비가 급격하게 오르는 데 대한 고충이 공통된 목소리입니다. 개별 시민의 목소리는 어피니티버블에서 확인할 수 있습니다.

출퇴근,교통

교통 범주는 다른 범주보다 구체적인 요구가 많이 보입니다. 지하철 혼잡, 도로 정체, 버스 배차, 철도 역 신설에 대한 요구가 큰 줄기를 이루고, 장애인 이동권 보장에 대한 목소리도 함께 들어볼 필요가 있습니다. 개별 시민의 목소리는 어피니티버블에서 확인할 수 있습니다.

정성 데이터에 어울리는 시각화를 향해

지금까지 정성 데이터의 시각화가 워드클라우드 같은 단순한 방식에 머물러 있었던 데는 이유가 있습니다. 응답 하나하나를 사람이 직접 읽고 범주를 만들고 코딩하는 일이 까다로웠기 때문입니다. 그래서 빈도라는 단일 축으로 환원하는 처리가 쉬운 방식을 택해, 맥락은 사라지고 위계와 의미의 인접성은 드러나지 않았습니다.

임베딩과 LLM은 그 코딩 작업을 상당 부분 자동화해 줍니다. 분석이 쉬워진 만큼 시각화도 한 걸음 더 나아갈 수 있습니다. 어피니티버블이나 워드맵처럼 정보를 위계화하고 위치에 의미를 담는 시각화는 그 빈자리를 채울 수 있습니다. 전체 지형도를 한눈에 보여주면서도 개별 목소리의 디테일을 잃지 않습니다. 시민의 의견을 데이터로 모으는 일도 중요하지만, 그 데이터를 다시 정리해 시민에게 잘 전달하는 일도 그만큼 중요합니다. 시민의 목소리든 사용자의 응답이든, 정성 데이터를 다루는 자리라면 이런 시각화를 한 번 시도해 볼 만합니다.

한강을 떠올린 사람은 한강 근처에 살까?

마지막으로 가볍게 정성과 공간을 엮어보는 관찰 하나로 마무리하겠습니다. 키워드 데이터를 보다 보니 가벼운 호기심이 생겼습니다. 한강을 키워드로 뽑은 사람들은 한강 가까이 살고 있을까?

한강 키워드 응답 구별 코로플레스맵

응답자 중 한강 인접 11개 구의 한강 키워드 응답 비율은 11.1%, 비인접 14개 구는 6.3%로 실제 응답에서도 약 1.8배 차이가 났습니다. 다만 동 단위까지 좁히면 경향이 약해집니다. 표본이 작아져 노이즈도 있겠고, 거주지와 상관없이 학교나 직장에 따라 매일 한강을 지나거나 주말에 한강을 자주 찾을 수도 있으니 강한 상관관계가 있지는 않을텐데요. 그래도 한강을 연상하는데 영향이 있긴 한 것 같습니다.

하네스 엔지니어링

doworld — Mon, 11 May 2026 07:50:18 +0900

들어가며

OpenAI의 엔지니어링 팀이 5개월 동안 약 100만 줄의 프로덕션 코드를 만들었다. 놀라운 건 규모가 아니다. 수동으로 작성한 소스코드가 단 한 줄도 없다는 점이다.

소수의 엔지니어가 Codex 에이전트에게 작업을 지시하고, PR을 검토하고, CI 파이프라인을 관리했을 뿐이다. 애플리케이션 로직, 문서, CI 설정, 모니터링 설정까지 전부 AI 에이전트가 만들었다.

이 실험에서 OpenAI가 얻은 가장 중요한 교훈은 이것이다:

"어려운 건 AI 에이전트가 아니다. 에이전트가 일할 환경(harness)이 어렵다."

이 환경을 설계하는 분야가 바로 하네스 엔지니어링(Harness Engineering)이다.

하네스 엔지니어링이란?

비유로 이해하기

"하네스(harness)"는 말에게 씌우는 마구(馬具)다. 말이 아무리 빠르고 강해도, 고삐 없이는 짐을 나를 수 없고 밭을 갈 수도 없다. 방향을 잡아주고, 힘을 전달하고, 안전하게 제어하는 것이 마구의 역할이다.

AI 에이전트도 마찬가지다.

- GPT-5든 Claude든, 에이전트 자체는 이미 충분히 강력하다

- 하지만 고삐 없이 풀어놓으면 엉뚱한 코드, 아키텍처 위반, 스타일 불일치가 쏟아진다

- 하네스 엔지니어링은 이 고삐를 설계하는 기술이다

정의

하네스 엔지니어링: AI 에이전트가 대규모로 안정적이고 일관된 결과물을 만들어내도록 환경, 제약, 피드백 루프를 설계하는 엔지니어링 분야

핵심은 에이전트를 바꾸는 것이 아니라 환경을 바꾸는 것이다.

왜 지금 필요한가?

2025년의 전형적인 실패 패턴

개발자: "결제 모듈 만들어줘"
에이전트: (코드 생성)


문제들:
- 프로젝트 코딩 컨벤션 무시
- 이미 있는 유틸 함수를 중복 생성
- 아키텍처 레이어 경계를 넘나듦
- 테스트는 통과하지만 기존 모듈과 스타일이 불일치
- 3일 후, 다른 에이전트가 같은 파일을 다른 방식으로 수정

에이전트 하나가 한 번 작업하는 건 어떻게든 된다. 문제는 규모가 커질 때다. 10개의 에이전트가 동시에 100개의 파일을 수정하면, 제약 없이는 카오스가 된다.

프롬프트 엔지니어링의 한계

"코딩 컨벤션을 지켜줘", "아키텍처 레이어를 위반하지 마" 같은 프롬프트를 아무리 정교하게 써도, 에이전트는 잊거나 무시한다. 프롬프트는 부탁이고, 하네스는 강제다.

프롬프트 엔지니어링: "이 규칙을 지켜주세요" (부탁)

하네스 엔지니어링: 규칙을 위반하면 CI가 실패한다 (강제)

LangChain 팀은 이를 정량적으로 증명했다. 에이전트 모델은 그대로 두고 하네스만 개선했더니, 벤치마크 성과가 52.8%에서 66.5%로 향상되었다. 순위로는 Top 30에서 Top 5로 뛰었다. 에이전트를 바꾸지 않고도, 환경을 바꾸는 것만으로 이 정도 차이가 난다.

하네스 엔지니어링의 3가지 핵심 기둥

1. 컨텍스트 엔지니어링 (Context Engineering)

"에이전트에게 추측시키지 말고, 읽게 하라"

AI 에이전트가 올바른 결과물을 만들려면, 프로젝트의 규칙과 상태를 알아야 한다. 컨텍스트 엔지니어링은 이 정보를 머신이 읽을 수 있는 형태로 구조화하는 것이다.

정적 컨텍스트: 규칙 파일

# AGENTS.md (또는 CLAUDE.md)

## 아키텍처 규칙
- 모든 API 엔드포인트는 /api/v1/ 하위에 위치
- 데이터베이스 접근은 반드시 Repository 레이어를 통해서만
- UI 컴포넌트에서 직접 API를 호출하지 않음

## 코딩 컨벤션
- 함수명: camelCase
- 파일명: kebab-case
- 테스트 파일: *.test.ts

## 금지 패턴
- console.log 사용 금지 (logger 사용)
- any 타입 사용 금지
- 인라인 스타일 금지

이 파일은 에이전트가 작업을 시작할 때 자동으로 로드된다. 사람에게 온보딩 문서를 주듯이, 에이전트에게도 "입사 첫날 읽어야 할 문서"를 주는 것이다.

동적 컨텍스트: 실시간 상태

CI/CD 파이프라인 상태
로그, 메트릭, 에러 추적
현재 진행 중인 PR과 이슈
최근 변경된 파일과 그 이유

핵심 원칙: 저장소가 단일 진실 소스(Single Source of Truth)

모든 정보는 코드 저장소 안에 있어야 한다. 위키, 노션, 슬랙 대화에 흩어진 정보는 에이전트가 읽을 수 없다. 저장소에 넣어야 에이전트의 컨텍스트가 된다.

2. 아키텍처 제약 (Architectural Constraints)

"자유롭게 코드를 쓰되, 정해진 경계 안에서만"

컨텍스트가 "무엇을 해야 하는가"라면, 아키텍처 제약은 "무엇을 해서는 안 되는가"다.

의존성 방향 강제

OpenAI는 코드베이스의 의존성 방향을 이렇게 정의했다:

Types → Config → Repository → Service → Runtime → UI

UI는 Service를 호출할 수 있지만, Service는 UI를 참조할 수 없다
Repository는 Config를 읽을 수 있지만, Config는 Repository를 모른다
이 규칙을 위반하는 import가 있으면 **빌드가 실패**한다

이것은 프롬프트로 "지켜줘"라고 부탁하는 것이 아니다. 린터와 구조 테스트가 자동으로 차단하는 것이다.

구현 예시

// architecture.test.ts — 아키텍처 제약 테스트

describe('Architecture constraints', () => {
  test('UI layer must not import from Repository', () => {
    const uiFiles = getFilesIn('src/ui/');

    for (const file of uiFiles) {
      const imports = getImports(file);
      expect(imports).not.toContainPath('src/repository/');
    }
  });

  test('Service layer must not import from UI', () => {
    const serviceFiles = getFilesIn('src/service/');

    for (const file of serviceFiles) {
      const imports = getImports(file);
      expect(imports).not.toContainPath('src/ui/');
    }
  });
});

에이전트가 아무리 "이렇게 하는 게 더 효율적인데"라고 생각해도, 이 테스트가 실패하면 코드는 머지되지 않는다.

Pre-commit 훅

# .husky/pre-commit
npx lint-staged          # 코드 스타일 강제
npm run test:architecture  # 아키텍처 규칙 검증
npm run test:types         # 타입 안전성 확인

커밋 자체가 되지 않으므로, 잘못된 코드가 저장소에 들어갈 수 없다.

3. 엔트로피 관리 (Entropy Management)

"AI가 만든 코드는 시간이 지나면 부패한다"

Martin Fowler는 이 현상을 "코드 부패(code rot)"에 비유하면서, 하네스 엔지니어링의 엔트로피 관리를 프로그래밍 언어의 가비지 컬렉션(GC)에 빗대었다.

가비지 컬렉션이 메모리 누수를 자동으로 정리하듯, 엔트로피 관리는 코드베이스의 일관성 붕괴를 자동으로 탐지하고 복구한다.

왜 엔트로피가 증가하는가?

에이전트 A가 유틸 함수를 만들고, 에이전트 B가 같은 기능의 함수를 또 만든다. 에이전트 C는 이전 버전의 패턴을 사용한다. 10개의 에이전트가 동시에 작업하면, 각각은 올바르더라도 전체적으로는 불일치가 쌓인다.

대응 방법

정리 에이전트(Cleanup Agent)를 주기적으로 실행:
  1. 문서와 코드의 불일치 탐지
  2. 중복 함수/모듈 발견
  3. 사용되지 않는 코드 식별
  4. 네이밍 패턴 위반 스캔
  5. 순환 의존성 감지

이것은 "한 번 설정하면 끝"이 아니다. 지속적이고 반복적인 프로세스다.

실제 사례로 보는 하네스 엔지니어링

OpenAI: 100만 줄의 무인 코드

구성:

소수의 엔지니어 + 다수의 Codex 에이전트
모든 아키텍처 규칙을 머신 가독형 문서로 명세
관찰성(observability) 데이터로 에이전트 성과 모니터링
구조화된 PR 리뷰 워크플로우

결과:

5개월, 약 100만 줄의 프로덕션 베타 제품
수동 작성 코드 0줄
애플리케이션 로직 + 문서 + CI + 모니터링 전부 포함

핵심 교훈:

에이전트에게 "좋은 코드를 써줘"라고 하지 않았다. 대신 좋은 코드만 통과할 수 있는 환경을 만들었다.

Stripe: 주당 1,000개 PR

Stripe의 "Minions" 에이전트 시스템:

Slack에서 작업 요청
  → 에이전트가 자동으로 코드 작성
  → CI 파이프라인 통과 확인
  → PR 자동 생성
  → 인간 엔지니어가 최종 리뷰
  → 머지

주당 1,000개 이상의 PR이 이 파이프라인을 통해 머지된다. 핵심은 에이전트가 만든 코드가 기존 코드와 동일한 품질 게이트를 통과해야 한다는 점이다.

LangChain: 하네스 변경만으로 벤치마크 점프

LangChain 팀은 에이전트 모델(Claude, GPT)은 전혀 바꾸지 않고, 미들웨어 구조만 개선했다:

LocalContextMiddleware: 코드베이스 매핑 자동 생성
LoopDetectionMiddleware: 에이전트 반복 루프 감지 및 중단
ReasoningSandwichMiddleware: 추론 단계 최적화
PreCompletionChecklistMiddleware: 완료 전 검증 강제

결과: 벤치마크 52.8% → 66.5%, 순위 Top 30 → Top 5

이 사례가 증명하는 것: "더 좋은 AI"보다 "더 좋은 환경"이 성과를 좌우한다.

도입 가이드: 3단계로 시작하기

Level 1: 개인 프로젝트

가장 가성비 좋은 시작점이다.

# 1. CLAUDE.md (또는 AGENTS.md) 작성
프로젝트 규칙, 컨벤션, 금지 패턴 정의

# 2. Pre-commit 훅 설정
코드 스타일과 기본 규칙 자동 검증

# 3. 테스트 작성
에이전트가 만든 코드가 기존 테스트를 깨뜨리지 않는지 확인

이것만으로도 에이전트의 결과물 품질이 체감될 정도로 달라진다.

Level 2: 소규모 팀

# 1. AGENTS.md 고도화
아키텍처 다이어그램, 모듈 경계, 의존성 규칙 포함

# 2. CI 파이프라인에 아키텍처 테스트 추가
레이어 위반, 순환 의존성 자동 탐지

# 3. PR 검토 체크리스트
에이전트 생성 코드에 대한 표준 리뷰 절차 수립

# 4. 린터 규칙 강화
프로젝트 전용 커스텀 린터 규칙 추가

Level 3: 조직 규모

# 1. 미들웨어 레이어 구축
에이전트 요청/응답 파이프라인에 검증 단계 삽입

# 2. 관찰성(Observability) 시스템
에이전트 성과 메트릭 수집 및 대시보드

# 3. 엔트로피 관리 자동화
정리 에이전트 주기적 실행, 코드 건강도 리포트

# 4. 버전 관리된 하네스 설정
하네스 자체를 코드로 관리, 변경 이력 추적

흔한 실수 5가지

1. 과도한 제어 흐름 설계

에이전트의 모든 행동을 미리 정의하려는 유혹이 있다. 하지만 LLM은 빠르게 진화한다. 너무 세밀한 제어 흐름은 모델이 업데이트될 때마다 깨진다. 큰 경계만 정하고, 경계 안에서는 자유를 주는 것이 더 견고하다.

2. 정적 하네스

한 번 만들어놓고 방치하는 하네스는 금방 쓸모없어진다. 모델이 진화하면 하네스도 함께 진화해야 한다. 하네스 자체를 코드로 관리하고 버전 관리해야 하는 이유다.

3. 문서화 경시

"AGENTS.md 대충 써도 되겠지"는 위험한 생각이다. 에이전트는 당신의 의도를 추론하지 않는다. 명확하지 않으면 추측하고, 추측은 틀린다. 규칙 파일의 품질이 곧 에이전트 결과물의 품질이다.

4. 피드백 루프 부재

에이전트가 성공했는지 실패했는지 모르면 개선할 수 없다. 어떤 에이전트가 어떤 작업에서 어떤 이유로 실패했는지를 추적하고 기록해야 한다. 이 데이터가 하네스를 개선하는 연료다.

5. 저장소 밖에 정보 저장

"이건 노션에 있어", "그건 슬랙에서 공유했어" — 에이전트는 이런 정보에 접근할 수 없다. 저장소 안에 없으면 존재하지 않는 것이다.

프롬프트 엔지니어링 → 하네스 엔지니어링으로의 전환

2023~2024년의 키워드가 "프롬프트 엔지니어링"이었다면, 2025~2026년의 키워드는 "하네스 엔지니어링"이다.

프롬프트 엔지니어링:

AI에게 무엇을 하라고 말하는 기술
한 번의 대화, 한 번의 결과물에 집중
개인 스킬에 의존

하네스 엔지니어링:

AI가 올바르게 작동하는 환경을 만드는 기술
수천 번의 반복 실행에서 일관된 품질을 보장
시스템적이고 팀 전체에 적용

프롬프트 엔지니어링이 "좋은 질문하는 법"이라면, 하네스 엔지니어링은 "좋은 답만 나올 수밖에 없는 구조를 만드는 법"이다.

마치며

하네스 엔지니어링은 결국 개발자의 역할에 대한 질문이다.

"당신은 코드를 쓰는 사람인가, 코드가 만들어지는 환경을 설계하는 사람인가?"

AI 에이전트가 코드를 작성하는 속도와 품질은 계속 좋아질 것이다. 하지만 아무리 좋은 에이전트도 잘못된 환경에서는 잘못된 결과를 낸다. 반대로, 적절한 하네스 안에서는 평범한 에이전트도 놀라운 결과를 만든다.

2026년의 시니어 엔지니어에게 기대되는 역량은 더 이상 "복잡한 알고리즘을 얼마나 잘 구현하느냐"가 아니다. "AI 에이전트가 복잡한 시스템을 안정적으로 구축할 수 있는 환경을 얼마나 잘 설계하느냐"로 무게중심이 옮겨가고 있다.

코드를 쓰는 시대가 끝나는 게 아니다. 코드를 쓰는 방식이 바뀌는 것이다. 그리고 그 변화의 중심에 하네스 엔지니어링이 있다.

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

참고 자료

- OpenAI — 하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기

- Martin Fowler — Harness Engineering

- NxCode — Harness Engineering: The Complete Guide