pxd story

"AI에게 우리를 소개하고 싶었습니다", UX 전문 기업이 GEO 서비스를 만든 이유

GEONIQ — Tue, 7 Apr 2026 17:12:27 +0900

시작은 하나의 질문이었습니다

pxd는 대한민국에서 UX/UI 분야를 대표하는 사용자경험(UX) 디자인 전문 기업입니다. AI에게 "대한민국에서 UX/UI 컨설팅 잘하는 업체 추천해줘"라고 물으면, pxd는 빠지지 않고 언급됩니다.

그런데 한 가지 의문이 생겼습니다.

"화면 UI 개발을 잘하는 회사는?" — pxd, 언급 없음.

"프론트엔드 개발을 잘하는 회사는?" — pxd, 역시 언급 없음.

2002년에 설립된 pxd는 2019년부터 UX 컨설팅 및 리서치, 설계, 디자인 뿐만 아니라 UI개발 및 프론트엔드개발까지 수행하는 회사가 되었습니다. 그런데 AI는 그 사실을 모르고 있었습니다. 왜일까요?

이 질문을 파고들면서 저희는 GEO(Generative Engine Optimization)와 AIEO(AI Engine Optimization)라는 영역을 발견했습니다. AI에게 잘 인용되려면 단순히 좋은 콘텐츠를 만드는 것만으로는 부족하다는 것, AI가 이해하고 신뢰할 수 있는 구조로 콘텐츠를 제공해야 한다는 것을 알게 되었습니다.

그래서 생각했습니다.

"우리만 이 문제를 겪고 있는 건 아닐 거야. 좋은 서비스나 상품을 제공하고 있거나 만들고도 AI에게 제대로 소개되지 못하는 곳이 얼마나 많을까? 그렇다면, AI에게 잘 인용될 수 있는 방법을 알려주자."

이것이 GEONIQ(지오닉)의 시작이었습니다.

그리고 2025년 11월, 그 고민을 담아 "AI 검색 시대의 새로운 기준, GEONIQ(지오닉)을 소개합니다"라는 글과 함께 베타 서비스를 세상에 공개했습니다.

그로부터 약 4개월. 수많은 피드백과 개선을 거쳐, 오늘 GEONIQ이 정식 서비스로 오픈합니다.

베타 오픈 전 진행한 예비 사용자 조사에서 다음과 같은 피드백들을 받았습니다.

"국내에 GEO(AIEO)까지 포함한 통합 SEO 진단 도구가 없었는데, 한국어 환경에 맞게 최적화해 제공하는 점이 좋습니다." — 6년 경력 스타트업 퍼포먼스 마케터

"유사한 국내 서비스와 비교했을 때, UI·UX 완성도와 리포트 품질이 압도적으로 높습니다." — 10년 경력 대기업 퍼포먼스 마케터

이 목소리들이 정식 오픈을 준비하면서 저희가 가장 집중한 방향이기도 합니다.

베타에서 정식 오픈까지, 지오닉은 어떻게 달라졌을까?

스스로를 진단하며 성장했습니다

정식 오픈 전, 먼저 우리 자신부터 진단했습니다. geoniq.ai를 GEONIQ으로 지속적으로 분석하고, 개선 가이드를 따라 고치고, 다시 진단하는 과정을 반복했습니다. 그 결과를 숫자로 보여드립니다.

항목	베타 (2025.11)	현재 (2026.04)
종합 점수	60점	98점
기술 최적화	40점	100점
콘텐츠 품질	85점	100점
성능 및 사용자 경험	100점	100점
콘텐츠 신뢰성	26점	77점
보안 및 정책 준수	44점	95점
정상 항목	37개	62개
조치 필요 항목	24개	0개

진단하고, 가이드를 따라 고치고, 다시 진단하는 과정을 반복하며 조치가 필요한 항목을 모두 해결했습니다. 저희가 만든 도구로 저희 서비스를 직접 개선한 것, 이것이 실 검증된 GEONIQ의 가치입니다.

AI가 GEONIQ을 알아보기 시작했습니다

GEONIQ이 SEO/GEO 개선에 실제 효과가 있는지 확인하기 위해 "SEO, GEO(AIEO) 검증하는 국내 사이트 추천해줘"라는 질문을 다양한 AI에게 직접 던져봤습니다. 베타 초기에는 어떤 AI도 GEONIQ을 언급하지 않았습니다. 하지만 시간이 지나면서 변화가 시작됐습니다.

(아래 결과는 사용자 편향을 최소화하기 위해 각 플랫폼에서 신규 계정을 생성한 후, “SEO, GEO(AIEO) 검증이 가능한 국내 사이트를 추천해줘”라는 동일한 질문을 한 달 간격으로 반복하여 얻은 것입니다.)

ChatGPT의 답변 (2026년 1월)

gpt 답변 내용

ChatGPT는 GEONIQ을 국내 SEO+GEO 도구 추천 목록의 첫 번째로 소개했습니다.

Perplexity의 답변 (2026년 2월)

perplexity 답변 내용

Perplexity 역시 GEO 진단 도구를 추천하면서 GEONIQ을 가장 먼저 언급했습니다.

Gemini의 답변 (2026년 3월)

gemini 답변 내용

Gemini 또한 GEONIQ을 국내 GEO/AIEO 특화 진단 솔루션으로 첫 번째로 소개했습니다.

"AI에게 우리를 소개하고 싶다"는 바람에서 시작한 서비스가, 이제 AI로부터 직접 추천받고 있습니다. GEONIQ이 추구하는 가치가 실제로 작동하고 있음을 보여주는 결과입니다.

정식 오픈, 새로운 기능과 더 고도화된 분석

베타에서 정식 오픈까지, GEONIQ은 단순 수정이나 개선 가이드 제시를 넘어 서비스 전반을 한 단계 끌어올렸습니다.

1. 마이페이지: 내 사이트를 체계적으로 관리

베타에서는 분석 결과를 한 번 보고 끝이었습니다. 이제는 다릅니다.

대시보드: 주요 사이트를 고정하고 점수 변화를 한눈에 추적합니다. 이전 대비 몇 점이 올랐는지, 어떤 항목이 개선됐는지 시각적으로 확인할 수 있습니다.
점수 추이 차트: 시간에 따른 점수 변화를 라인 차트로 시각화합니다. 개선 작업의 효과를 데이터로 확인하세요.
사이트 비교: 경쟁 사이트와 나란히 비교합니다. 카테고리별 점수를 바 차트로 비교해 우리 사이트의 강점과 약점을 파악할 수 있습니다.
분석 이력 관리: 모든 분석 기록이 사이트별로 그룹핑되어 저장됩니다.

2. AI 개선 가이드 강화

베타에서도 제공하던 AI 기반 개선 제안이 더욱 정밀해졌습니다.

As-Is / To-Be 코드 비교: 현재 코드와 개선된 코드를 나란히 보여줍니다. 무엇을 어떻게 고쳐야 하는지 개발자가 아니어도 이해하고 수정할 수 있습니다.
연관 검사 안내: "이 항목을 개선하려면 먼저 이 항목을 확인하세요"와 같은 선행 개선 조건을 안내합니다.

3. PDF 리포트: 공유하고, 보고하고, 실행하는 보고서

진단 결과를 체계적인 PDF 보고서로 다운로드할 수 있습니다. 사내 보고나 고객 제안서에 바로 활용하세요.

즉시 프린트 가능한 보고서: 종합 점수, 카테고리별 분석, 개선 제안이 담긴 체계적인 PDF 보고서를 제공합니다.

4. 팀 협업: 같은 데이터를 함께 보며 함께 개선

혼자만 보는 리포트가 아니라, 팀과 함께 보는 리포트가 됩니다.

팀원을 이메일로 초대하여 분석 결과를 공유
마케터, 개발자, 기획자 등이 같은 데이터를 보며 개선 방향을 논의
외부 이해관계자에게도 URL로 간편하게 전달 공유 가능

5. 진단 정확도 & 성능 개선

GEONIQ만의 체크리스트 항목의 검증 로직을 지속적으로 고도화
분석 속도 최적화 (병렬 처리, 캐싱 전략 개선)
SPA/CSR 사이트 분석 정확도 향상
리포트 UI/UX 전면 개편으로 가독성 향상

플랜 안내

GEONIQ은 체험부터 기업 맞춤까지, 운영 규모에 맞는 4가지 플랜을 제공합니다.

Starter — GEONIQ을 처음 체험해보고 싶다면
Basic — 개인·실무 중심의 일반 운영
Pro — 전문가·팀 중심의 확장 운영
Enterprise — 기관·기업 전용 맞춤형 통합 플랜

무료 회원도 진단 기능을 이용할 수 있습니다. 단, 일부 제한이 있을 수 있으며, 유료 플랜 사용자에게 전체 개선 가이드, 대시보드, 사이트 비교, 팀 공유 기능 등이 제공됩니다.

각 플랜의 상세 내용은 geoniq.ai에서 확인하세요.

앞으로의 GEONIQ

정식 오픈은 끝이 아닌, 새로운 시작이라 생각합니다.

"AI에게 우리를 소개하고 싶다"는 하나의 질문에서 출발한 GEONIQ은, 이제 모든 서비스가 다양한 AI 엔진들에게 발견되고 신뢰받을 수 있도록 돕는 도구로 성장하려고 합니다. AI 검색 환경의 변화에 맞춰 분석 항목과 로직을 지속적으로 업데이트 하며 고도화해 나갈 예정입니다.

Google의 AI Overviews가 확대되고, ChatGPT와 Perplexity의 검색 기능이 고도화되면서, "AI에게 이해되고 인용되는 콘텐츠"의 중요성은 앞으로 더 커질 것입니다.

GEONIQ은 이 변화의 속도를 따라가며, 여러분의 사이트가 어디에서든 인용되고 신뢰받을 수 있도록 돕겠습니다.

지금 시작하세요

URL을 입력하는 것만으로 진단을 시작할 수 있습니다.

검색엔진과 생성형 AI가 이해하고 신뢰하는 콘텐츠 구조, 사람이 신뢰하는 경험, 그 연결의 기준을 GEONIQ이 제시합니다.

여러분의 사이트는 지금, AI에게 어떻게 보이고 있나요?

Next.js App Router에서 프록시 레이어를 둔 이유

seonju.lee — Mon, 6 Apr 2026 10:00:17 +0900

들어가며

GEONIQ(SEO/GEO(AI Engine Optimization)를 분석해주는 서비스) 개발에 저도 같이 참여하게 되었는데 프론트엔드는 Next.js의 App Router, 백엔드는 FastAPI로 구성되어 있어 프론트엔드에서 백엔드 API를 호출할 일이 많았습니다.

처음에는 프론트엔드에서 백엔드를 직접 호출하는 단순한 구조로 시작했지만, 개발을 진행하면서 CORS 문제라든지, 작업 환경에 따라 URL이 각각 바뀌는 것에 의해 필연적으로 ”중간에 서버인 Proxy 서버 ”가 필요해 졌습니다.

이 글은 Next.js API Routes를 활용해 API 프록시 레이어를 만들게 된 과정과, 만들고 나서 느낀 점을 이야기해 보려고 합니다

프론트엔드가 백엔드를 직접 호출하면 안 되나?

실제로 많은 프로젝트가 프론트엔드에서 백엔드 API를 직접 호출합니다. 하지만 직접 호출로는 해결하기 어려운 문제들이 하나둘 생기기 시작했습니다.

문제 1: CORS
프론트엔드(localhost:3000)에서 백엔드(localhost:8001)를 직접 호출하면 CORS 설정이 필요합니다. 백엔드에서 “Access-Control-Allow-Origin:*”와 같이 추가해서 관리하면 되지만, 환경이 늘어날 때마다 양쪽을 맞춰줘야 합니다. (별거 아닌 것 같지만, 개발 중에 CORS 오류로 시간을 쓰지 않아도 된다는 건 생각보다 편합니다 :-))

이런 필요들이 모여서 만들어진 API 라우트 구조는 이렇습니다.

app/api/
├─ [...path]/route.ts   ← catch-all 프록시
└─ auth/
├─ set-tokens/route.ts     ← 토큰 저장 (쿠키 관리)
├─ refresh/route.ts   ← 토큰 갱신
├─ me/route.ts     ← 사용자 정보 조회
└─ logout/route.ts     ← 로그아웃

async function proxyRequest(
  request: NextRequest,
  params: Promise<{ path: string[] }>,
  method: string,
) {
  const { path } = await params;
  const accessToken = request.cookies.get("access_token")?.value;
  if (!accessToken) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  // 경로 조합: /api/example/123 → 백엔드의 /test-api/example/123
  const { searchParams } = new URL(request.url);
  const queryString = searchParams.toString();
  const apiPath = path.join("/");
  const url = `${API_BASE}/admin/${apiPath}${queryString ? `?${queryString}` : ""}`;
  const body = method !== "GET" && method !== "DELETE" ? await request.text() : undefined;
  const response = await fetch(url, {
    method,
    headers: {
      Authorization: `Bearer ${accessToken}`,
      "Content-Type": "application/json",
    },
    body,
    signal: controller.signal,
  });

  const data = await response.json();
  return NextResponse.json(data, { status: response.status });
}
// 모든 HTTP 메서드를 동일한 함수로 처리
export async function GET(req, { params }) {
  return proxyRequest(req, params, "GET");
}

export async function POST(req, { params }) {
  return proxyRequest(req, params, "POST");
}

httpOnly 쿠키에서 access_token을 꺼낸다.
요청 경로 앞에 /test-api/을 붙여 백엔드 URL을 조합한다.
Authorization 헤더에 토큰을 실어 백엔드로 전달한다.

문제 2: 백엔드 URL이 환경마다 다르다

관리자 백엔드는 localhost:8001(개발)과 프로덕션 서버가 다릅니다. 클라이언트에서 직접 호출하면 이 URL이 브라우저에 그대로 노출되는데 관리자 API의 주소가 외부에 드러나는 건 보안상 좋지 않아 서버 사이드에서 URL을 결정하면, 보안상의 문제도 해결할 수 있습니다.

// 환경변수로 백엔드 URL 결정 (서버 사이드에서만 접근)

const API_BASE =
  process.env.API_BASE_URL ||
  process.env.NEXT_PUBLIC_API_BASE_URL ||
  "http://localhost:8001";

문제 3: 인증 토큰을 안전하게 관리해야 한다

관리자 사이트는 Google OAuth로 로그인합니다. 백엔드에서 받은 JWT 토큰을 어디에 저장할 것인가의 문제가 있었습니다. localStorage에 넣으면 XSS에 취약하고, 일반 쿠키는 JavaScript에서 접근 가능합니다.

결국 httpOnly 쿠키를 사용하게 되었는데 이 쿠키는 브라우저 JavaScript에서 읽을 수 없으므로, 서버에서 꺼내 백엔드로 전달하는 중간 레이어가 필요해졌습니다. 이것이 API 프록시 레이어가 필요한 가장 직접적인 이유였습니다.

프록시 서버를 이용한 장점 1 : 코드가 깔끔해진다.

클라이언트 코드의 단순함입니다. 백엔드 URL도 모르고, 토큰 관리도 신경 쓸 필요가 없습니다.토큰 전달도 없이 그냥 /api/로 호출하여 간단히 작성했습니다.

export const getTextAPI = async (params): Promise<TTextListResponse> => {
  const response = await fetch(`/test-api/test?${searchParams.toString()}`, {
    credentials: "include",  // 쿠키 자동 전송
  });
  return response.json();
};

export const patchTextAPI = async (id, data) => {
  const response = await fetch(`/test-api/test/${id}/`, {
    method: "PATCH",
    credentials: "include",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),

  });
  return response.json();
};

/api/test → catch-all이 /test-api/test로 변환 → 쿠키에서 토큰 꺼내서 Authorization 헤더에 주입 → 백엔드로 전달. 이 모든 과정이 프록시 레이어 안에서 자동으로 일어납니다. 새 기능이 추가될 때도 클라이언트에서 /api/test2를 호출하는 함수만 추가하면 되고 프록시 쪽은 건드릴 필요가 없어 좋습니다.

프록시 서버를 이용한 장점 2 : OAuth 콜백 흐름

인증 전체 흐름을 보면 프록시 레이어의 역할이 좀 더 명확졌던 것 같습니다.

사용자가 "Google 로그인" 클릭
백엔드(admin-api)의 OAuth URL로 이동
Google 인증 완료 → 백엔드가 콜백 처리
백엔드가 프론트엔드로 리다이렉트 (URL에 토큰 포함)
→ /auth/callback/google?access_token=xxx&refresh_token=yyy
콜백 페이지에서 /test-api/test-auth/tokens 호출 (BFF)
→ httpOnly 쿠키에 토큰 저장
/test-api/test-auth/is-admin 호출해서 관리자 권한 확인
대시보드로 이동

토큰이 URL 파라미터로 잠깐 노출되긴 하지만, 곧바로 httpOnly 쿠키에 저장되고 URL에서 사라집니다. 이후 모든 요청은 쿠키가 자동 전송되므로, 클라이언트 코드에서 토큰을 직접 다룰 일이 없습니다.

마치며

사실 이 API 프록시 레이어는 "좋은 아키텍처를 설계하겠다"는 의도보다, 보안이나 CORS 같은 실무적인 문제를 풀기 위해 자연스럽게 만들어진 결과물이었습니다.

Next.js App Router를 사용하고 계신다면, API Routes가 단순한 서버리스 함수가 아니라 프론트엔드와 백엔드 사이의 유용한 중간 레이어가 될 수 있다는 점을 한번 고려해 보시면 좋겠습니다. 특히 [...path] catch-all 라우트 하나로 일반 프록시를 처리하고, 보안이 필요한 라우트만 개별로 분리하는 패턴은 코드 양 대비 꽤 실용적이었다고 생각합니다.

읽어주셔서 감사합니다.

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

GEONIQ Integrated Insight Report — 여행·숙박 플랫폼 (Vol.3 선택이 이어지는 구조 조건 분석)

GEONIQ — Mon, 6 Apr 2026 07:50:27 +0900

리포트는 GEO(AIEO)와 SEO를 한 번에 통합 분석해주는 GEONIQ의 진단 기준에 따라 국내 주요 여행·숙박 플랫폼의 페이지 구조와 정보 구성 방식을 분석하고 AI·검색 환경에서 숙소 상품이 선택 단계로 이어지기 위해 필요한 구조적 조건을 관찰·정리한 분석 보고서이다.

좌측부터 우측 방향으로 네이버 여행, 야놀자, 여기어때 메인 페이지 이미지

1) 이번 분석의 관점과 범위

Vol.1에서는 숙소 정보가 AI검색(GEO) 환경에서 어떤 단위로 인식되는지를 살펴봤다.
Vol.2에서는 그 인식이 왜 선택으로 이어지지 않는지를 선택 시도–비교–검증 흐름을 기준으로 관찰했다.

이번 Vol.3에서는 앞선 두 편의 관찰을 전제로 선택이 실제로 이어지기 위해 필요한 구조적 조건을 정리한다.
이 조건은 특정 기능이나 UI의 문제가 아니라 여러 플랫폼에서 반복적으로 확인되는 구조적 패턴을 기준으로 도출된다.

2) AI검색(GEO) 관점에서의 선택

이 리포트에서 말하는 선택은 단순한 예약 행위를 의미하지 않는다.
AI검색(GEO) 관점에서의 선택은 여러 숙소가 동일한 기준 위에서 연결되고, 그 중 하나가 상대적 맥락 안에서 판단되는 상태를 의미한다.

GEO(AIEO) 환경에서는 숙소 간 관계가 구조적으로 드러날 때 선택이 형성된다.

3) 핵심 발견 (Key Findings)

Key Finding 1

선택은 ‘후보 집합’이 형성될 때 시작된다.

현재 구조에서는 숙소가 개별 정보 단위로 분리되어 인식된다.
그 결과 여러 숙소가 존재하더라도 하나의 선택 후보 집합으로 묶이지 않는다.
선택은 개별 정보가 아니라 서로 비교 가능한 후보 집합이 형성될 때 시작된다.

Key Finding 2

선택은 ‘비교 기준이 구조로 드러날 때’ 형성된다.

가격, 평점, 위치와 같은 정보는 대부분 존재하지만, 이 정보들이 동일 기준 위에서 정렬된 구조로 표현되지 않으면 비교는 형성되지 않는다.
선택은 정보의 양이 아니라 비교 기준이 구조로 표현될 때 발생한다.

Key Finding 3

선택은 ‘흐름이 유지되는 구조’에서 이어진다.

사용자는 여러 숙소를 탐색하고 비교한다.
그러나 상세 페이지 진입 이후 다른 후보와의 연결이 단절되면 선택 과정은 반복적으로 끊긴다.
선택은 단일 페이지에서 완결되지 않는다.
후보 간 이동과 비교가 유지되는 흐름 안에서 이어진다.

4) 구조적 조건으로 본 선택 가능 상태

GEONIQ 진단 결과를 기준으로 보면 AI검색(GEO) 환경에서 선택이 형성되기 위해서는 다음 조건이 함께 충족되어야 한다.

① 후보 집합 구조

여러 숙소가 단순 나열이 아니라 동일 조건 기반의 후보 집합으로 묶여 있어야 한다.

동일 지역
동일 일정
동일 인원 조건

이 조건이 구조적으로 유지될 때 숙소는 비교 가능한 단위로 인식된다.

② 비교 기준 구조

각 숙소의 정보는 개별적으로 존재하는 것이 아니라 동일 기준 위에서 정렬 가능한 형태로 표현되어야 한다.

가격
평점
위치
예약 가능 여부

이 기준이 구조로 드러날 때 비교는 자연스럽게 형성된다.

③ 흐름 유지 구조

하나의 숙소를 확인한 이후에도 다른 후보와의 관계가 유지되는 흐름이 필요하다.

유사 숙소 연결
동일 조건 기반 후보 이동
이전 후보 집합으로의 복귀 흐름

이 흐름이 유지될 때 선택은 단절되지 않고 이어진다.

5) 구조 관점에서의 정리

이번 분석을 통해 확인된 것은 여행·숙박 플랫폼의 기능 부족이 아니다.

다음 요소들은 이미 충분히 갖춰져 있다.

숙소 정보는 충분히 제공된다
사용자 탐색 흐름은 안정적으로 설계되어 있다
SEO 관점에서의 노출 구조도 확보되어 있다

그러나 동시에 다음 조건이 함께 나타난다.

숙소가 후보 집합으로 묶이지 않는다
비교 기준이 구조로 표현되지 않는다
탐색 이후 흐름이 유지되지 않는다

이 구조에서는 정보는 충분하지만 선택은 이어지지 않는다.

지오닉 검증 결과 바로가기
네이버 여행 메인	야놀자 메인	여기어때 메인이자 목록
네이버 여행 목록	야놀자 목록	-
네이버 여행 상세	야놀자 상세	여기어때 상세

pxdAX 관찰 노트 (종합)

이번 여행·숙박 플랫폼 연재에서 확인된 것은 정보의 부족이 아니다.

Vol.1에서는 숙소가 어떻게 인식되는지를 살펴봤다.
숙소는 분명히 보이고 있었다.

Vol.2에서는 그 다음 단계를 확인했다.
선택은 시작되지만 구조적으로 이어지지 않았다.

Vol.3에서는 그 이유를 구조의 관점에서 정리했다.
선택은 정보의 양이 아니라 구조적 조건이 형성될 때 비로소 발생한다.

숙소는 이미 충분히 설명되어 있다.
그러나 그 정보는 사람의 탐색을 기준으로 배열되어 있을 뿐, AI검색(GEO) 환경에서 선택으로 이어지는 구조로 정리되어 있지는 않다.
그 결과 보이는 것과 선택되는 것 사이에는 간극이 남는다.

그 간극은 기능으로 채워지지 않는다.
그 간극은 구조로만 연결된다.

정보는 이미 충분하다.
보이는 것과 선택되는 것의 차이는 정보의 양이 아니라 구조의 문제이다.
선택은 더 많은 정보를 통해 만들어지는 것이 아니라 비교와 흐름이 가능한 구조가 형성될 때 비로소 발생한다.

이제 필요한 것은 정보를 더하는 것이 아니라
선택이 이어지는 구조를 만드는 일이다.

GEONIQ 서비스 바로가기

GEONIQ Integrated Insight Report는 GEONIQ, pxd story, xe group tech blog 에서 동시 발행 됩니다.

GEONIQ Integrated Insight Report — 여행·숙박 플랫폼 (Vol.2 선택 구조와 비교 흐름 분석)

GEONIQ — Thu, 2 Apr 2026 07:50:54 +0900

본 리포트는 GEO(AIEO)와 SEO를 한 번에 통합 분석해주는 GEONIQ의 진단 기준에 따라 국내 주요 여행·숙박 플랫폼의 페이지 구조와 정보 구성 방식을 분석하고 AI·검색 환경에서 숙소 상품이 선택 단계로 어떻게 이어지거나 단절되는지를 관찰·정리한 분석 보고서이다.

좌측부터 우측 방향으로 네이버 여행, 야놀자, 여기어때 메인 페이지 이미지

1) 이번 분석의 관점과 범위

Vol.1에서는 SEO 이후 단계인 GEO(AIEO) 환경에서 숙소 정보가 어떤 단위로 인식되는지를 살펴봤다.
숙소 정보는 충분히 존재하지만, 상품 단위로 구조화되어 있지 않다는 점이 확인되었다.

이번 Vol.2에서는 그 다음 단계인 선택 구조를 다룬다.
즉, 인식 이후 사용자의 선택 시도가 어떤 흐름을 거쳐 이어지거나 끊기는지를 구조적으로 살펴본다.

분석은 다음 흐름을 기준으로 진행한다.

선택 시도
비교 형성
검증 및 확정

이 세 단계가 웹 구조 내에서 어떻게 연결되거나 단절되는지를 GEONIQ 진단 기준으로 관찰한다.

2) 선택 시도는 어떻게 시작되는가

사용자는 일정, 인원, 지역, 가격과 같은 조건을 기반으로 숙소 탐색을 시작한다.

이 조건들은 플랫폼 내에서 잘 반영되어 있으며, SEO 유입 이후에도 자연스럽게 탐색 흐름으로 이어진다.
검색 결과에서 특정 숙소나 지역 페이지로 유입된 이후에도 탐색은 중단되지 않는다.
즉, 선택 시도 자체는 구조적으로 문제없이 발생하나, 이 흐름은 다음 단계에서 구조적 제약을 받는다.

3) 비교는 어떻게 제한되는가

선택이 이어지기 위해서는 여러 후보를 동일 기준 위에 놓고 비교할 수 있어야 한다.
GEONIQ 진단 결과, 다음과 같은 구조가 반복적으로 관찰된다.

숙소 목록은 존재하지만 비교 기준이 명시적으로 정렬된 구조로 표현되지 않는다
가격, 평점, 위치 등의 정보는 존재하지만 동일 기준으로 배열된 비교 구조는 제한적이다
유사 숙소 또는 대체 선택지로 이어지는 관계 구조가 명확히 드러나지 않는다

그 결과 사용자는 여러 숙소를 확인할 수는 있지만 동일 기준 위에서 후보를 비교하는 구조는 형성되지 않는다.

SEO 관점에서는 다양한 숙소 페이지가 노출되지만,
GEO(AIEO) 환경에서는 이 숙소들이 비교 가능한 집합으로 묶이지 않는다.

4) 검증 단계에서 흐름이 끊기는 이유

비교 이후에는 선택을 확정하기 위한 검증 단계가 이어져야 한다.
이 단계에서 사용자는 다음과 같은 정보를 확인한다.

실제 예약 가능 여부
가격 및 조건
객실 유형
리뷰 및 평점

이 정보들은 각 숙소 상세 페이지에 충분히 제공된다.
그러나 구조적으로 다음과 같은 흐름이 나타난다.

특정 숙소 상세 페이지 진입 이후 다른 후보와의 연결이 약화된다
상세 페이지는 단일 숙소 중심의 정보 소비 구조로 완결된다
이전에 탐색하던 후보 집합으로 다시 연결되는 흐름이 제한된다

그 결과 하나의 숙소를 깊게 이해할 수는 있지만 여러 후보를 비교한 상태에서 선택을 확정하는 흐름은 유지되기 어렵다.

5) 선택은 어디에서 완결되는가

이러한 구조에서 선택은 플랫폼 내부에서 자연스럽게 이어지지 않는다.
사용자는 다음과 같은 방식으로 선택을 이어간다.

여러 숙소 페이지를 반복적으로 이동하며 비교한다
별도의 비교 환경(앱, 검색 결과, 개인 메모 등)을 활용한다
개인 기준으로 정보를 재정리한다

즉, 선택은 플랫폼 내부의 구조가 아니라 사용자의 외부 판단 과정에서 완결되는 흐름을 보인다.

6) 구조 점검 관점에서 본 Actionable Signals

GEONIQ 진단 결과를 종합하면 선택이 이어지지 않는 이유는 선택 기준의 부족이 아니라 선택 흐름이 구조적으로 연결되지 않은 상태로 관찰되기 때문이다.

아래 항목은 GEO(AIEO) 관점에서 구조가 어디에서 끊기는지를 점검하기 위한 포인트이다.

숙소가 선택 후보 집합으로 묶이지 않고 개별 정보 단위로 분리되어 있다
후보 간 비교 기준이 명시적으로 정렬된 구조로 표현되지 않는다
유사 숙소 또는 대체 선택지로 이어지는 관계 구조가 제한적이다
상세 페이지 진입 이후 다른 후보로 이어지는 흐름이 단절된다
SEO 유입 이후 정보 소비 단계에서 흐름이 종료된다

이러한 조건에서 선택은 플랫폼 내부가 아니라 사용자 판단 과정에서 완결되는 경향을 보인다.

지오닉 검증 결과 바로가기
네이버 여행 메인	야놀자 메인	여기어때 메인이자 목록
네이버 여행 목록	야놀자 목록	-
네이버 여행 상세	야놀자 상세	여기어때 상세

pxdAX 관찰 노트

Vol.1에서는 숙소가 어떻게 인식되는지를 살펴봤다.
정보는 충분하지만, 상품 단위로 구조화되어 있지는 않았다.

Vol.2에서는 그 다음 흐름을 확인했다.
선택은 시작되지만 구조적으로 이어지지 않는다.

문제는 사용자가 기준을 갖고 있지 않아서가 아니다.
문제는 그 기준을 적용할 수 있는 구조가 형성되어 있지 않다는 점이다.

숙소는 나열되어 있지만 비교는 구조로 정리되어 있지 않다.
정보는 충분하지만 선택은 이어지지 않는다.

이 지점에서 하나의 차이가 드러난다.
보이는 것과 선택되는 것은 동일한 문제가 아니다.

그리고 그 사이에는 비교를 가능하게 만드는 구조가 필요하다.
이 구조는 다음 단계에서 더 명확히 드러난다.

선택은 기준이 많아서 발생하는 것이 아니라 비교가 가능한 구조가 형성될 때 비로소 이어진다.
다음 Vol.3에서는 이 선택이 실제로 이어지기 위해 어떤 구조적 조건이 필요한지를 정리한다.

GEONIQ 서비스 바로가기

GEONIQ Integrated Insight Report는 GEONIQ, pxd story, xe group tech blog 에서 동시 발행 됩니다.

[pxd talks] 계산기 말고 엑셀처럼... AI와 함께 일하는 ‘언러닝’의 기술

seulgeekim — Mon, 30 Mar 2026 07:50:01 +0900

pxd talks는 여러 분야의 연사님을 초빙해 인사이트를 나누는 시간입니다. pxd 구성원들이 더 넓은 시야로 무언가를 새롭게 발견하거나 자신을 성장시킬 수 있는 기회를 얻을 수 있도록 말이죠. 그리고 그 경험은 [pxd talks] 아티클로 기록합니다. pxd 구성원들이 함께 보고 듣고 느끼고 배운 것들이 사라지지 않고 pxd story에 남아 더 넓은 세상으로 뻗어갈 수 있기를 바랍니다.

다들 일할 때 AI 많이 사용하시나요? 이제 AI 없는 일터는 상상하기 어려운데요. 새로운 아이디어를 얻고 싶거나 참고자료를 찾을 때, 중요하지 않지만 손이 많이 가는 작업이 필요할 때 AI를 찾곤 하죠. 단순히 ‘일할 때 AI를 쓴다’를 넘어, AI 중심으로 업무 방식을 재구성하고 조직 문화, 운용 구조에 반영하는 ‘AI 전환(AI Transformation. AX)’을 목표로 하는 기업도 늘어나고 있어요.

그중 삼양라운드스퀘어 DXT팀은 성공적인 AX 사례를 보여주는 조직이에요. 올해 성과를 내야 하는데 개발자는 없고, 채용도 외주도 어렵다면? 막막한 상황에 처한 DXT팀이 선택한 건 바로 'AI 주도 개발(AI-Driven Development)'이었어요. 기존의 성공 방정식을 과감히 버리고 AI와 함께 전 팀원이 바이브 코더(Vibe Coder)가 된 DXT팀의 실험과 도전, 그 생생한 이야기를 PM 최동운 님과 pxd talks로 만나볼게요.

용기로 뗀 첫걸음 “일단 해보자!”

‘불닭볶음면’으로 전 세계 입맛을 사로잡은 삼양스퀘어라운지의 다음 스텝은 IT 신사업이었어요. 하지만 추가 채용이나 적절한 외주 업체를 찾는 건 쉽지 않은 일이었죠. 소수의 팀원이 단기간에 성과를 보여야 하는 상황에서 DXT팀은 ‘바이브 코딩’이라는 돌파구를 발견했다고 해요.

“모두가 코딩을 해보자는 마음으로 시작했어요. 힘들겠지만, 어쩌면 기회일 수도 있다고 생각했죠.”

DXT팀은 ‘우리의 아이디어를 프로토타이핑해 보자’를 목표로 챗GPT와 레플릿(Replit)를 적극 활용했어요. 챗GPT로 요구사항을 정리하고 레플릿으로 배포하기까지, 단 4시간이면 충분했죠.

노션(Notion), PPT, 피그마(Figma)를 동원해 자료를 공유하고 관계자를 설득해야 했던 기존 방식과 비교하면 획기적인 효율이었어요. 최동운 님은 이 프로토타입 덕분에 경영진과 수월하게 소통할 수 있었고 빠르게 다음 단계로 진입할 수 있었다고 해요.

코딩을 AI가 하면, 사람은?

실제 제품 개발에 들어가면서 DXT팀의 개발 풍경은 완전히 달라졌어요. 실험적 성격의 프로토타입과 달리 높은 완성도를 확보해야 했거든요. 개발 초기에는 모든 팀원이 AI 에이전트 클로드 코드(Claude Code)와 커서(Cursor)를 활용해 코드를 썼죠.

이러한 환경에서 사람의 역할은 ‘실행’에서 ’결정’으로 옮겨갔어요. 최동운 님은 “마치 주니어와 일할 때처럼” AI가 만든 결과에 대해 취향과 판단력을 발휘해 좋고 싫음, 맞고 틀림을 정해야 한다고 강조했어요.

문제는 작업량이 늘어나서면서 발생했는데요. 팀원 각자가 AI와 쓴 코드들이 서로 충돌하고, 맥락을 놓친 AI가 “헛소리”를 늘어놓으면서 점점 결과의 품질이 하락하기 시작했다고 해요.

“AI 천국인 줄 알았는데 지옥이었어요. 다시 피그마, 지라(Jira)로 돌아가고 싶은 유혹에 시달렸습니다.”

‘바이브 코더’인 팀원들은 코드를 꼼꼼히 살펴보며 AI에 피드백을 줄 수 없었고, 방대한 코드를 매번 다른 동료나 제미나이, 챗GPT에 물어볼 수도 없는 노릇이었어요. 이때 최동운 님의 머릿속에 불현듯 한 단어가 떠올랐어요. 바로 ‘맥도날드’!

전 세계 어디서든 같은 맛을 내는 맥도날드처럼

맥도날드가 전 세계 매장에서 동일한 품질을 유지하듯, DXT팀에도 ‘일관성’과 ‘예측가능성’이 필요했다고, 최동운 님은 설명했어요. 그러기 위해서는 일의 기준을 명확히 정의하고 동일한 방식으로 실행하게 만드는 시스템과 규칙을 갖춰야 했죠. 최동운 님은 맥도날드의 본사, 지점장, 알바생의 역할을 아래와 같이 정의하고 DXT팀에 내재화했어요.

- 본사(테크 리드): 운영 매뉴얼과 레시피 (워크플로, 콘텍스트, 프롬프트)를 정의. 위생 관리처럼 반드시 지켜야할 항목은 프롬프트 대신 자동화된 스크립트로 관리.

- ‍ 지점장 (프로덕트 빌더): 본사 레시피와 규칙 안에서 각자 직원들에게 작업을 지시하고 관리. 메뉴 또는 레시피에 대한 피드백 본사에 제공.

- 직원 (코딩 에이전트): 표준화된 지시에 따라 성실하게 코드를 짜고 작업을 수행.

먼저, 모든 회의를 녹음하고 녹취록을 노트북LM(Notebook LM)에 저장했어요. 문서화 과정에서 왜곡 가능성을 줄이고 모두와 일관된 콘텍스트를 공유했죠. 가이드와 프롬프트 등은 깃허브(Github)에 업로드해 모두가 확인할 수 있도록 했고요.

콘텍스트를 바탕으로 요구사항을 정의할 때도 AI를 적극 활용했어요. 여러 AI에 사용자, 디자이너, 임원 등 다양한 관점에서 어떻게 생각할지를 질문해 토론 시뮬레이션을 돌려보고 논리적 허점을 발견해 보완하거나 인사이트를 도출했죠. 최종적으로는 사람이 직접 컨펌했고요.

템플릿을 만들어 디자인을 표준화할 때는 아스키 아트와 같은 로우파이 와이어프레임을 그려 AI 코딩 에이전트에 학습시켰어요. 커서, 클로드 코드 등 AI가 생성한 코드는 또 다른 AI인 코드 래빗(CodeRabbit)이 검토해 사람의 부담을 덜어줬고요.

이러한 방식 덕에 DXT팀은 불필요한 의사소통을 줄이고, 일관된 품질 기준을 유지하며 빠르게 합의하고 실행하는 AI 기반 업무 문화를 구축할 수 있었다고 해요.

새로움을 가능케 한 ‘언러닝’

최동운 님은 과거의 경험, 작업 방식을 잊는 ‘언러닝(Unlearning)’이 필요하다고 강조했어요. DXT팀이 시행착오를 감수하며 실험을 이어간 결과, 이전에는 상상할 수 없었던 변화와 성과를 얻을 수 있었던 것처럼요. 최동운 님은 ‘AI가 나보다 더 나을 수 있다’는 생각으로, 막히는 부분이 생긴다면 주저 말고 AI에 물어보는 태도가 중요하다고 전했어요.

”우리가 두려워해야 할 것은 실패가 아니라, 망설이다 기회를 놓치는 것입니다.”

제한적인 조건 안에서 다소 무모하게 보일 수 있었던 DXT 팀의 실험은, AI와 함께 일하는 새로운 업무 방식을 가능하게 만들었어요. DXT팀의 경험은 지금 많은 조직이 고민하고 있는 ‘미래의 일’에 대한 실마리를 보여준다고 볼 수 있어요. 기술 변화를 기민하게 받아들이고 AI를 적극 활용해 새로운 일 문화를 구축해 낸 DXT팀의 이야기가 pxd를 비롯한 여러 회사 또는 팀에 많은 영감을 줄 것이라고 확신해요.

글. 김슬기

편집. 임현경

GEONIQ Integrated Insight Report — 여행·숙박 플랫폼 (Vol.1 숙소 상품 인식 구조 분석)

GEONIQ — Mon, 23 Mar 2026 14:00:38 +0900

본 리포트는 GEO(AIEO)와 SEO를 한 번에 통합 분석해주는 GEONIQ의 진단 기준에 따라 국내 주요 여행·숙박 플랫폼의 페이지 구조와 정보 구성 방식을 분석하고 AI·검색 환경에서 숙소 상품이 어떤 단위로 인식되는지를 관찰·정리한 분석 보고서이다.

좌측부터 우측 방향으로 네이버 여행, 야놀자, 여기어때 메인 페이지 이미지

1) 이번 분석의 관점과 범위

본 분석은 네이버 여행, 야놀자, 여기어때 3개 플랫폼을 대상으로 진행하였다.
각 플랫폼은 다음 3개 유형의 페이지를 기준으로 GEONIQ 진단을 수행하였다.

메인 및 숙소 탐색 페이지
숙소 목록 페이지
숙소 상세 페이지

Vol.1에서는 이 구조를 기준으로 숙소가 AI검색(GEO) 환경에서 어떤 단위로 인식되는지를 중심으로 살펴본다.
선택과 비교, 판단 흐름은 Vol.2에서 다룬다.

2) 숙소 ‘상품’의 정의

여행·숙박 플랫폼에서 숙소는 단순한 장소 정보가 아니라 예약 가능한 단위로 구성된다.

실제 선택이 발생하는 기준은 객실 유형, 일정(체크인·체크아웃), 인원 수가 결합된 상태이다.
즉 하나의 숙소는 단일 상품이 아니라 조건에 따라 분기되는 다수의 상품 집합으로 구성된다.

본 리포트에서는 이 결합 단위를 기준으로 숙소를 ‘상품 단위’로 정의한다.

3) AI검색(GEO) 관점에서의 ‘인식’이란 무엇인가

이 리포트에서 말하는 인식은 사람이 정보를 읽고 이해하는 과정을 의미하지 않는다.

AI검색(GEO) 관점에서의 인식이란 특정 대상이 독립된 단위로 구분되고, 그 속성과 상태가 구조적으로 해석 가능한 상태를 의미한다.
SEO 관점에서는 개별 페이지 단위의 노출이 가능하나, GEO(AIEO) 환경에서는 다음 조건이 함께 충족되어야 한다.

대상이 명확한 단위로 정의되어야 한다
해당 단위의 속성이 구조화되어 있어야 한다
다른 대상과 구분 가능한 형태로 표현되어야 한다

이 조건이 충족되지 않으면 정보는 존재하더라도 인식 가능한 단위로 해석되기 어렵다.

4) 핵심 발견 (Key Findings)

Key Findings 1

숙소 정보는 존재하지만, AI검색(GEO)이 상품 단위로 인식할 수 있도록 구조화되어 있지는 않다.

Product schema가 존재하지 않거나 Hotel·장소 단위 중심으로만 구조화되어 있으며,
객실·일정·인원과 같은 실제 예약 단위가 독립된 상품으로 분리되어 표현되지 않는다.

그 결과 숙소는 개별 정보로는 인식되지만, 예약 가능한 상품 단위로 구분되는 구조는 형성되지 않는다.

Key Findings 2

숙소 간 관계를 통해 비교 대상으로 묶는 구조는 형성되지 않는다.

숙소 목록은 존재하지만 비교를 전제로 한 정렬 기준이나 리스트·표 형태의 구조는 제한적으로 나타나며,
유사 숙소 간 관계나 대체 선택지로 이어지는 연결 또한 구조적으로 명시되지 않는다.

그 결과 개별 숙소 정보는 인식되지만, 상품 간 상대적 위치를 판단하는 비교 맥락은 형성되지 않는다.

Key Findings 3

가격·재고·날짜와 같은 변동 정보의 기준 시점이 구조적으로 명시되지 않는다.

여행·숙박 상품은 시간에 따라 상태가 변화하는 특성을 가진다.
그러나 대부분의 페이지에서 정보의 기준 시점이나 업데이트 흐름이 구조적으로 드러나지 않는다.

그 결과 동일한 정보라도 어떤 시점을 기준으로 한 것인지 판단하기 어려우며,
AI검색(GEO) 환경에서 상태 정보를 안정적으로 해석하기 위한 조건은 형성되지 않는다.

5) 플랫폼별 구조 관찰 요약

네이버 여행

정보 탐색 중심 구조가 강하게 나타난다
콘텐츠 구성은 풍부하지만 상품 단위 구조화는 제한적이다
비교 관계를 드러내는 구조는 확인되지 않는다

야놀자

숙소 목록과 상세 정보는 명확하게 제공된다
개별 페이지 단위 완결성은 높다
그러나 상품 단위 구조화와 비교 구조는 형성되지 않는다

여기어때

성능 및 사용자 경험 측면에서는 안정적인 구조를 보인다
메인과 목록이 통합된 구조로 탐색 흐름은 단순하다
그러나 상품 단위 정의, 비교 구조, 상태 정보 표현은 제한적으로 나타난다

6) 구조 점검 관점에서 정리

이번 분석에서 확인된 것은 특정 플랫폼의 기능적 완성도 문제가 아니다.

여행·숙박 플랫폼 전반에서 공통적으로 나타나는 구조는 다음과 같다.

숙소 정보는 충분히 제공된다
개별 페이지 단위의 완결성은 높다
사용자 탐색 흐름은 잘 설계되어 있다

동시에 다음 조건이 함께 나타난다.

상품 단위 구조가 명확히 정의되지 않는다
숙소 간 관계를 통한 비교 구조가 형성되지 않는다
시간 기반 상태 정보가 구조적으로 드러나지 않는다

이 구조에서 숙소는 선택 가능한 상품이라기보다 정보 단위에 가까운 형태로 표현된다.

지오닉 검증 결과 바로가기
네이버 여행 메인	야놀자 메인	여기어때 메인이자 목록
네이버 여행 목록	야놀자 목록	-
네이버 여행 상세	야놀자 상세	여기어때 상세

pxdAX 관찰 노트

이번 분석에서 확인된 것은 정보의 부족이 아니다.

여행·숙박 플랫폼은 이미 충분한 정보를 제공하고 있으며 사용자는 필요한 내용을 대부분 확인할 수 있다.
그러나 그 정보는 사람의 탐색과 이해를 기준으로 배열되어 있을 뿐 AI검색(GEO) 환경에서 상품 단위로 인식될 수 있도록 구성되어 있지는 않다.
그 결과 숙소는 보이지만 하나의 선택 가능한 단위로 분리되거나 다른 상품과 비교 가능한 관계로 묶이지 않는다.

이 지점에서 하나의 질문이 남는다.

숙소를 ‘정보로 충분히 설명되는 대상’으로 유지할 것인가,
아니면 ‘선택 가능한 상품 단위’로 구조화할 것인가.

GEONIQ 서비스 바로가기

GEONIQ Integrated Insight Report는 GEONIQ, pxd story, xe group tech blog 에서 동시 발행 됩니다.

AI 에이전트의 시대, 우리는 어떤 개발자가 되어야 할까?

doworld — Mon, 16 Mar 2026 07:50:38 +0900

들어가며

개발 생태계의 변화가 무섭습니다.
이제는 단순한 '도구의 진화'를 넘어섰죠.
AI 에이전트가 코드를 짜는 수준을 넘어 직접 PR을 올리고 작업을 수행하는 모습을 보며, 바이브 코딩을 곁들인 대'딸깍'의 시대가 된 것 같아요.

이제 개발자가 고민해야 하는 것은 "어떻게 코드를 짤 것인가"가 아니라 "어떤 문제를 정의하고, AI가 내놓은 답을 어떻게 검증할 것인가"라는 본질적인 질문에 대한 답일거에요.

좁아진 취업문

요즘 시장은 기묘한 양극화를 보이고 있습니다. 하버드 연구에 따르면 AI 도입 이후 주니어 채용은 약 10% 감소한 반면, 시니어 수요는 여전하다고 해요. "가르쳐야 하는 신입보다 AI 에이전트가 가성비 좋다"는 냉혹한 논리가 현장을 지배하기 시작한 것 같아요.

이제는 문턱이 매우 높아졌어요.
이제는 '배우러 온 신입'이 아니라, AI를 동료 삼아 1인분 이상의 생산성을 즉각 증명하는 '실전형 엔지니어'만이 살아남는 시대가 되었습니다.

'코드 작성자'에서 '시스템 지휘자'로

과거에는 알고리즘을 얼마나 효율적으로 구현하느냐가 실력이었습니다.
하지만 개발자의 84%가 AI를 쓰는 지금, 단순 구현 능력은 더 이상 희소 가치가 없습니다.
생산성 또한 이젠 더이상 경쟁력이 아니에요. 더 좋은 품질을 만들어내야 합니다.

오히려 AI가 쏟아내는 수많은 코드 속에서 미묘한 보안 취약점을 찾아내고, 전체 아키텍처의 정합성을 맞추는 판단력이 핵심이 되었습니다.
이제 개발자는 벽돌을 쌓는 조적공보다, 여러 AI 워커들에게 업무를 배분하고 조율하는 '총괄 감독'이나 '오케스트라 지휘자'에 가까워지고 있습니다. 창작의 즐거움이 리스크 관리의 압박으로 바뀔 수도 있겠지만, 이는 우리 역할이 더 가치 있는 전략적 영역으로 이동하고 있다는 신호이기도 합니다.

T자형 인재와 학습의 재정의

이런 환경에서 가장 강력한 생존 모델은 'T자형 인재'입니다.
자신만의 깊은 전문성(Depth)을 하나 갖추되, AI를 활용해 인접 분야까지 유연하게 넘나드는 확장성을 가진 분들이죠.

백엔드 개발자가 AI 도움으로 UI를 뚝딱 만들고, 프론트엔드 개발자가 인프라를 직접 만지는 것이 일상이 되었습니다.
학벌이나 학위는 이제 크게 중요하지 않다고 생각해요. "어디서 배웠나"보다 "무엇을 해결해봤나"가 더 중요한 증명 수단입니다.

마치며

미래가 어떻게 변하든 변하지 않는 본질이 있습니다. 바로 비판적 사고와 도메인에 대한 깊은 이해입니다.
AI는 웹 앱을 눈 깜짝할 새 만들어낼 순 있지만, 그 서비스가 사용자에게 정말 필요한지, 윤리적으로 문제는 없는지 판단하지 못합니다.

실제 문제 해결에 기술을 적용하는 엔지니어에 대한 수요는 항상 존재해왔고 기술을 지속적으로 업데이트하고 역량을 확장하며, 창의성·비판적 사고·협업 같은 인간 고유의 강점에 집중할수록 흐름에서 이탈하지 않을 수 있을거에요.

감사합니다.

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

[HCI KOREA 2026] AI와 알고리즘을 이용한 정성 조사 스케일업과 시각화

yewon.jang — Thu, 12 Mar 2026 07:50:59 +0900

리서처라면 한 번쯤 해 봤을 작업이 있습니다. 인터뷰 내용을 포스트잇에 옮겨 적고, 비슷한 것끼리 모으고, 패턴을 찾는 일인데요. 손으로 하나하나 붙이다 보면 어느새 벽 한 면이 가득 차 있죠. 그런데 데이터가 200개, 2000개가 되면 어떨까요?

올해 HCI KOREA에서 pxd가 던진 질문이 바로 이것이었습니다. 학회 주제는 "AI, 일상(日常), 이상(理想), 상상(想像)"으로, AI가 우리의 일상과 경험을 어떻게 바꾸는지 탐구하는 자리였는데요. pxd는 그 답을 리서치 현장에서 찾았습니다. 오래된 방법론에 AI를 결합해, 정성 조사의 스케일을 완전히 바꿔보고자 하는 시도를 공유합니다.

AI와 알고리즘을 이용한 정성조사 스케일업과 시각화: 어피니티 다이어그램, 퍼소나 자동화 (pxd UX Tech Lab 한상택 소장)

AI와 알고리즘으로 대규모 정성 데이터에서 인사이트를 도출하고 시각화하는 방법을 소개한다.

기존 정성조사는 소수 사용자 대상의 수작업 분석에 의존해 왔다. 정성조사의 주요 분석 도구인 어피니티 다이어그램과 퍼소나 방법은 모두 '클러스터링 기반 세분화'라는 공통 구조를 가진다. 기존에는 직관과 경험 중심의 분석을 하였으나, 텍스트 임베딩, 클러스터링, LLM을 활용한 알고리즘을 통해 체계적이고 재현 가능한 방식으로 전환할 수 있다. 이는 단순한 시간 절약을 넘어 다양한 관점의 탐색과 더 깊은 인사이트 도출을 가능하게 한다. 이렇게 도출된 계층적 정보를 직관적으로 전달하는 시각화 방법도 함께 다룬다.

MBTI와 사용자 조사의 공통점?

MBTI와 사용자 조사의 작동 원리가 똑같다면, 믿어지시나요? MBTI에서 외향/내향, 감각/직관처럼 사람을 나누는 기준을 만들고, 그 기준에 따라 유형을 분류하는 작업은 사실 사용자 유형을 세분화하는 작업과 같은데요. 이 기준을 UX에서는 "행동 변수"라고 부릅니다.

사용자 조사의 핵심도 결국 이 행동 변수를 찾는 일입니다. 모든 사용자를 위한 디자인을 하려다 보면 아무도 만족시키지 못하는 디자인이 나오기 쉽거든요. 그래서 리서처는 사용자를 유형별로 나누고, 각 유형이 어떤 문제를 겪는지 파악합니다.

그런데 여기서 문제가 생깁니다. 행동 변수를 찾고, 사용자를 분류하는 작업을 사람이 직접 하려면 시간이 많이 걸립니다. 데이터가 많아질수록 더욱 그렇고요. 이때 등장하는 것이 바로 군집화입니다.

군집화는 미리 정해진 기준 없이, 데이터 스스로 패턴을 드러내게 하는 방법입니다. 기계는 데이터 간의 거리를 계산해서 가까운 것끼리 묶습니다. 텍스트 데이터라면, 텍스트 임베딩 기술로 의미를 숫자로 변환한 뒤, 비슷한 의미끼리 묶어내는 것입니다.

발표에서는 데이터 분석으로 숫자 속에 숨어 있던 사용자 패턴을 찾아낸 사례들을 소개했습니다. 사용자의 특성을 숫자 벡터로 표현하여, 비교적 단순한 계산만으로도 유사한 행동 패턴을 묶어낸 사례들입니다.

예를 들어, 미국인의 하루 24시간 활동 데이터를 분석한 결과, 은퇴자·직장인·학생 등 생활 유형이 뚜렷하게 구분되었습니다. 또한 GA와 트랜잭션 데이터를 군집화해 감에 의존하지 않는 Data-driven Personas를 도출한 사례도 있었습니다. 단순히 평균값이나 개별 지표만 보았을 때는 차이가 명확히 보이지 않았는데요. 사용자 행동을 벡터화한 뒤 군집화를 적용하면, 하나의 패턴으로 드러납니다.

출처: A Day in the Life of Americans, Nathan Yau

사용자 조사 실무, AI Multiplier로서의 어피니티버블

pxd는 이 군집화 기술을 리서치 업무에 직접 적용했습니다. 그렇게 만들어진 툴이 어피니티버블(affinitybubble.com)입니다.

어피니티버블의 베이스는 어피니티 다이어그램입니다. 사용자 발화를 계층적으로 묶어나가며 패턴을 찾는 방법론인데, 원래는 포스트잇으로 손수 작업합니다. 직관적이지만 느리고, 데이터가 많아지면 사람이 감당하기 어렵습니다. 어피니티버블은 이 과정을 텍스트 임베딩과 군집화로 자동화하고, 결과를 보로노이 트리맵으로 시각화합니다. 계층적 데이터의 구조와 크기를 한눈에 볼 수 있어서, 어떤 주제가 얼마나 많이 언급됐는지 바로 파악할 수 있습니다.

왼쪽: Nielsen Norman Group / 오른쪽: Affinity Bubble

발표에서 가장 인상적이었던 건 이 한마디였습니다.

"빨리 하는 게 중요한 게 아니라, 다양한 관점을 보고 인사이트의 질을 높이는 게 중요합니다."

10배 빠르게 작업할 수 있다면, 같은 시간 안에 10배 많은 관점으로 탐색할 수 있습니다. 어피니티버블이 AI Multiplier로 불리는 이유입니다. 앱 리뷰를 분석하더라도 사용자 행동 목표 기준으로 볼 수도 있고, 긍부정 기준으로 볼 수도 있고, 시간대별로 볼 수도 있습니다. 관점을 바꿀 때마다 새로운 인사이트가 나옵니다.

현재는 사용자 세분화에 집중한 퍼소나 도구도 개발 중인데요. 행동 변수를 자동으로 추출하고 맵핑해 주는 툴로, 리서처가 행동 변수를 "마음의 눈으로 보라"는 말에 의존하지 않아도 되는 날이 머지않은 것 같습니다.

마치며

발표가 끝난 후 수집한 청중 반응도 흥미로웠습니다. "질적 인터뷰에서 인사이트 뽑는 시간이 단축될 것 같다", "회사에서 아직 아날로그 방식을 쓰는데 새로운 방식이 필요했다"는 이야기가 나왔는데요. 기술 개념을 퍼소나 도출, 시각화라는 실무 맥락에 연결해서 와닿았다는 반응도 있었습니다.

사용자 조사의 핵심은 변하지 않습니다. 사용자 조사는 패턴을 찾고, 사용자를 이해하는 일입니다. AI를 적용해서 달라진 건 그 일을 할 수 있는 규모와 속도, 그리고 관점의 수입니다. 앞으로 어피니티버블과 함께 확장할 수 있는 정성 조사의 가능성, 기대해도 좋을 것 같습니다!

어피니티버블 사용해보기

GEONIQ Integrated Insight Report — 금융권 · 자산운용사 (Vol.3 비교 구조와 점검 관점)

GEONIQ — Thu, 5 Mar 2026 07:50:09 +0900

본 리포트는 GEO(AIEO)와 SEO를 한 번에 통합 분석해주는 GEONIQ의 진단 기준에 따라 국내 자산운용사 웹사이트의 페이지 구조와 정보 구성 방식을 분석하고 AI·검색 환경에서 자산운용사의 펀드·ETF 상품이 어떤 구조적 조건에서 선택 단계로 이어지지 않는지를 관찰·정리한 분석 보고서이다.

좌측부터 우측 방향으로 삼성자산운용, 미래에셋자산운용, 한국투자신탁운용, KB자산운용, 타임폴리오자산운용 메인 페이지 이미지

1) 이번 분석의 관점과 범위

Vol.1에서는 SEO 이후 단계인 GEO(AIEO) 환경에서 자산운용사의 펀드·ETF 상품이 어떤 단위로 인식되는지를 살펴봤다.
Vol.2에서는 그 인식이 왜 선택 단계로 이어지지 않는지를 선택 시도–비교–검증이라는 흐름을 기준으로 관찰했다.

이번 Vol.3에서는 앞선 두 편의 관찰을 전제로 사람의 선택 구조와 AI·검색(GEO(AIEO))의 선택 구조 사이에 존재하는 구조적 차이를 중심으로 정리한다.
그리고 이 차이 중 일부는 웹 구조와 정보 배열 방식에 따라 점검·조정이 가능한 영역임을 함께 짚는다.

2) AI·검색 관점에서의 ‘비교’란 무엇인가

이 리포트에서 말하는 비교는 사람이 정보를 읽고 해석해 판단하는 행위를 의미하지 않는다.
AI·검색(GEO(AIEO)) 관점에서의 비교란 서로 다른 펀드·ETF 상품이 동일한 기준과 맥락 안에서 연결되고, 상대적인 위치 관계가 구조적으로 드러나는 상태를 의미한다.
즉, 사람이 비교할 수 있는 정보가 충분히 제공되는 것과 AI·검색이 비교 관계를 인식할 수 있는 구조는 동일하지 않다.

SEO 관점에서는 개별 상품 페이지의 정보 노출이 가능하다.
그러나 GEO(AIEO) 환경에서는 상품 간 관계가 구조적으로 표현되지 않으면 비교와 선택으로 이어지기 어렵다.

3) 핵심 발견 (Key Findings)

Key Findings 1

자산운용사의 펀드·ETF 상품은 사람의 비교를 전제로 설계되어 있으나 AI·검색(GEO(AIEO))의 비교를 전제로 구조화되어 있지는 않다.

펀드·ETF 상품은 투자자 관점에서는 명확한 비교 대상이다.
그러나 AI·검색 환경에서는 이 상품들이 서로를 비교 대상으로 인식할 수 있는 관계 구조로 명시적으로 연결되어 있지 않은 경우가 많다.
그 결과 개별 상품 정보는 인식되지만 상품 간 상대적 위치를 판단하는 비교 맥락은 형성되기 어렵다.

Key Findings 2

자산운용사 웹의 펀드·ETF 상품 정보는 개별 상품 이해에는 충분하지만 상품 간 관계를 드러내는 구조는 제한적이다.

펀드·ETF 상품 상세 페이지에는 지표, 설명, 공시 정보가 충실히 제공된다.
그러나 이 정보는 대부분 단일 상품 단위로 완결되어 있으며 유사한 펀드·ETF 상품과의 관계가 웹 구조상 명확히 드러나지 않는다.
이로 인해 AI·검색 환경에서는 상품을 나란히 놓고 비교할 맥락이 자연스럽게 형성되기 어렵다.

Key Findings 3

이 과정에서 선택은 자산운용사 웹이 아니라, 투자자가 비교·판단을 수행하는 외부 정보 환경에서 완결되는 경향을 보인다.

실제 투자 판단에서의 비교와 선택은 증권사 HTS·MTS, 금융 포털의 ETF 비교 화면, 시장 데이터 기반 정보 서비스 등에서 이루어진다.
자산운용사 웹은 신뢰 가능한 상품 정보를 제공하지만 AI·검색 환경에서 선택을 완결시키는 구조로 작동하지는 않는다.

4) 반도체 · AI & Robot 테마 ETF 사례로 본 구조적 차이

예를 들어 반도체 또는 AI·Robot 테마의 펀드·ETF 상품은 자산운용사마다 유사한 상품이 다수 존재한다.
사람의 관점에서는 다음과 같은 지표 등을 기준으로 비교와 선택이 이루어진다.

총보수(TER), AUM(운용자산 규모), 거래량, 괴리율, 추적오차, 기간별 수익률 등

이 정보는 각 펀드·ETF 상품의 상세 페이지나 공시 자료에 존재하며, 투자자는 이를 종합해 선택 여부를 판단한다.
그러나 AI·검색(GEO(AIEO)) 환경에서는 이 상품들이 같은 테마 안에서 서로 어떤 위치에 있는지를 판단할 수 있는 관계 구조가 명시적으로 표현되지 않는 경우가 많다.
그 결과 개별 상품 정보는 인식되지만 상품 간 비교 판단은 구조적으로 형성되기 어렵다.

5) 구조 점검 관점에서 본 Actionable Signals

GEONIQ의 진단 결과를 종합하면 선택이 발생하지 않는 이유는 선택 기준의 부족이라기보다 선택 단계가 구조적으로 형성되지 않은 상태로 관찰되기 때문이다.

아래 항목은 개선 지시가 아니라, GEONIQ 진단 결과에서 반복적으로 확인된 구조적 단절 지점을 점검하기 위한 포인트이다.

펀드·ETF 상품이 개별 정보 단위로만 인식되고 선택 후보로 구분되지 않는다.
유사한 상품 간 관계가 웹 구조상 명확히 드러나지 않는다.
비교에 필요한 핵심 지표는 존재하지만 비교를 전제로 정렬된 구조는 제한적이다.
하나의 상품을 인식한 이후 다른 후보 상품으로 이어지는 흐름이 단절된다.
SEO 유입 이후 정보 소비 단계에서 흐름이 종료된다.

이러한 조건에서 선택은 자연스럽게 자산운용사 웹 외부에서 완결된다.

지오닉 검증 결과 바로가기
삼성자산운용 메인	미래에셋자산운용 메인	KB자산운용 메인	한국투자신탁운용 메인	타임폴리오자산운용 메인
삼성자산운용 펀드 목록	미래에셋자산운용 펀드 목록	KB자산운용 펀드 목록	한국투자신탁운용 펀드 목록	타임폴리오자산운용 ETF 목록
삼성자산운용 펀드 상세	미래에셋자산운용 펀드 상세	KB자산운용 펀드 상세	한국투자신탁운용 펀드 상세	타임폴리오자산운용 ETF 상세

pxdAX 관찰 노트 (종합)

이번 ‘금융권·자산운용사’ 연재에서 확인한 것은 자산운용사의 웹이 부족하다는 사실이 아니다.

Vol.1에서는 펀드·ETF 상품이 AI·검색 환경에서 어디까지 인식되는지를 살펴봤다.
정보는 존재했고 상품은 분명히 ‘보이고’ 있었다.

Vol.2에서는 그 인식이 왜 선택 단계로 이어지지 않는지를 관찰했다.
문제는 기준이 아니라 선택 단계 자체가 형성되지 않은 구조였다.

Vol.3에서는 이 현상이 개별 운용사나 특정 페이지의 문제가 아니라 사람의 선택 구조와 AI·검색(GEO(AIEO))의 선택 구조 사이의 차이에서 비롯된다는 점을 정리했다.

자산운용사의 웹은 사람의 판단을 돕는 정보에는 이미 충분히 충실하다.
그러나 그 정보들은 사람의 비교를 전제로 배열되어 있을 뿐 AI·검색 환경에서 비교 관계로 인식되도록 구조화되어 있지는 않다.
그 결과 상품은 보이지만 선택 후보로 묶이지 않고, 비교는 가능하지만 웹 내부에서 완결되지 않는다.

이 지점에서 자산운용사의 웹은 하나의 질문 앞에 서게 된다.
우리는 웹을 ‘충분한 정보를 제공하는 공간’으로만 유지할 것인가, 아니면 AI·검색 환경에서도 선택의 일부를 담당하는 구조로 확장할 것인가.

선택은 기준을 더한다고 만들어지지 않는다.
선택은 관계가 드러나고 흐름이 이어질 때 비로소 시작된다.

이미 잘 작동하는 구조 위에서 무엇을 더할 것인가가 아니라,
어디부터 다시 바라볼 것인가에 대한 질문이다.

GEONIQ 서비스 바로가기

GEONIQ Integrated Insight Report는 GEONIQ, pxd story, xe group tech blog 에서 동시 발행 됩니다.

GEONIQ Integrated Insight Report — 금융권 · 자산운용사 (Vol.2 선택 단계 구조 분석)

GEONIQ — Thu, 26 Feb 2026 14:30:45 +0900

본 리포트는 GEO(AIEO)와 SEO를 한 번에 통합 분석해주는 GEONIQ의 진단 기준에 따라 국내 자산운용사 웹사이트의 페이지 구조와 정보 구성 방식을 분석하고 AI·검색 환경에서 자산운용사의 상품(펀드·ETF 등)이 어떤 조건에서 선택 단계에 진입하며, 어디에서 선택이 중단되는지를 관찰·정리한 분석 보고서이다.

좌측부터 우측 방향으로 삼성자산운용, 미래에셋자산운용, 한국투자신탁운용, KB자산운용, 타임폴리오자산운용 메인 페이지 이미지

1) 이번 분석의 관점과 범위

Vol.1에서는 SEO 관점에서 노출되는 정보와는 별개로 GEO(AIEO) 환경에서 자산운용사의 상품이 어떤 단위로 인식되는지를 중심으로 살펴봤다.
그 결과 다수의 자산운용사 웹사이트에서 펀드·ETF는 콘텐츠로는 존재하지만 AI·검색 환경에서는 선택 이전 단계에 머무르는 패턴이 확인되었다.

이번 Vol.2는 이 관찰을 전제로 한다.
본 편에서는 SEO 노출이나 브랜드 인지의 문제가 아니라 GEO(AIEO) 환경에서 선택이 실제로 어디까지 작동하는지를 다룬다.

즉, ‘왜 선택되지 않는가’를 설명하지 않는다.
대신 선택이 어디까지 시도되고 어떤 단계에서 중단되는지를 관찰한다.

분석 대상은 Vol.1과 동일하게 국내 주요 자산운용사 웹사이트이며 메인 페이지, 펀드·ETF 목록 페이지, 펀드·ETF 상세 페이지를 ‘선택 시도 → 비교 → 검증’이라는 선택 단계 흐름으로 재구성해 분석했다.

2) AI·검색 환경에서 ‘선택’이 작동하는 방식

AI·검색 환경에서의 선택은 SEO 중심의 검색 노출과는 다른 방식으로 작동한다.
선택은 한 번에 발생하지 않는다. 다음과 같은 단계를 거쳐 형성된다.

상품이 선택 후보로 인식되는 단계
여러 후보를 나란히 놓고 비교하는 단계
특정 후보를 검증 대상으로 좁히는 단계

이 중 어느 한 단계라도 형성되지 않으면 다음 단계인 선택(인용)으로 이어지지 않는다.

SEO는 주로 첫 번째 단계에서의 노출과 수집을 담당한다.
그러나 GEO(AIEO) 환경에서는 비교와 검증 단계가 형성되지 않으면 선택(인용)은 발생하지 않는다.

Vol.2는 이 흐름을 기준으로 자산운용사의 상품이 AI·검색 환경에서 실제로 어느 단계까지 도달하는지를 살펴본다.

3) 핵심 발견 (Key Findings)

Key Findings 1

자산운용사의 펀드·ETF는 SEO 관점에서는 노출될 수 있으나 GEO(AIEO) 환경에서는 선택(인용) 과정이 시작되지 않는다.

AI·검색 환경에서 자산운용사의 펀드·ETF는 SEO 관점에서는 검색 결과에 노출될 수 있다.
그러나 GEO(AIEO) 환경에서는 비교나 검증의 대상으로 진입하기 이전 단계에 머무르며 선택 후보로 인식되지 않는다.
그 결과 선택 기준이 적용되기 전에 선택 과정 자체가 시작되지 않는다.

Key Findings 2

비교 단계에 도달하지 못한 상품은 GEO(AIEO) 환경에서 선택(인용) 후보로 유지되지 않는다.

펀드·ETF는 목록과 상세 페이지를 통해 제공된다.
그러나 AI·검색이 여러 상품을 나란히 놓고 비교를 시도하는 단계는 GEO(AIEO) 환경에서 제한적으로만 형성된다. 비교 단계에 도달하지 못한 경우 선택 시도는 유지되지 않고 중단된다.

Key Findings 3

브랜드 신뢰와 SEO 신호만으로는 GEO(AIEO) 선택(인용)을 만들지 않는다.

자산운용사의 브랜드 인지도와 SEO 기반 노출은 선택이 즉시 종료되는 시점을 늦출 수는 있으나 GEO(AIEO) 환경에서 선택을 발생시키는 조건으로 무조건 작동하지는 않는다.
선택은 비교나 검증 단계에 도달하지 못한 채 종료된다.

4) 자산운용사별 요약 인사이트

삼성자산운용

GEONIQ 진단 결과 삼성자산운용의 상품은 AI·검색 환경에서 선택 시도가 시작되는 단계까지는 도달한다.

브랜드 신호와 SEO 노출을 통해 선택 후보로 인식되는 흐름은 반복적으로 관찰된다.
그러나 선택은 펀드·ETF 간 비교 단계로 확장되지 않는다.
GEO(AIEO) 관점에서 비교 기준이 고정된 형태는 확인되지 않으며 선택은 비교 단계 초입에서 멈춘다.

미래에셋자산운용

미래에셋자산운용의 상품은 선택 시도가 비교적 길게 유지된다.

SEO 관점에서의 노출과 풍부한 상품 정보로 인해 선택 후보 상태가 일정 시간 지속된다.
그러나 GEO(AIEO) 환경에서는 비교 단계가 안정적으로 형성되지 않으며 선택 시도는 유지되지만 완결되지 않는다.

KB자산운용

KB자산운용의 경우 선택 시도는 메인–목록–상세 흐름을 따라 비교적 안정적으로 시작된다.

선택 후보로 인식되는 단계까지는 도달한다.
그러나 선택은 비교 이후 검증 단계로 확장되지 않는다.
AI·검색 환경에서 선택을 완결시키는 조건은 확인되지 않는다.

한국투자신탁운용

한국투자신탁운용의 상품은 선택이 시작되는 조건 자체가 제한적으로 형성된다.

SEO 기반 노출은 존재하지만 GEO(AIEO) 환경에서 선택 후보로 인식되는 단계에 도달하는 경우는 드물다.
선택은 시작 이전 단계에서 반복적으로 종료된다.

타임폴리오자산운용

타임폴리오자산운용은 ETF 중심의 비교적 단순한 구조를 갖고 있다.

그러나 AI·검색 환경에서 선택 시도는 제한적으로만 발생한다.
SEO 노출과 무관하게 선택은 비교 단계 이전에서 대부분 종료된다.

5) Actionable Signals — 선택 단계 구조 점검 가이드

이번 Actionable Signals은 자산운용사의 상품이 SEO 노출 이후 왜 GEO(AIEO) 환경에서 선택 단계로 이어지지 않는지를 점검하기 위한 기준이다.

이는 선택을 만드는 방법이 아니라 선택이 실제로 어디에서 멈추는지를 확인하기 위한 질문으로 구성된다.

선택 시도가 실제로 시작되는 지점이 존재하는가
선택이 비교 단계로 이어지는가
비교 이후, 선택이 검증 단계로 확장되는가
브랜드 또는 SEO 노출이 선택을 대신하고 있지는 않은가
선택 실패의 원인을 ‘기준’이 아니라 ‘단계’에서 점검하고 있는가

이 질문에 명확히 답하기 어렵다면 SEO 성과와 무관하게 GEO(AIEO) 환경에서 선택은 이미 멈춰 있을 가능성이 높다.

지오닉 검증 결과 바로가기
삼성자산운용 메인	미래에셋자산운용 메인	KB자산운용 메인	한국투자신탁운용 메인	타임폴리오자산운용 메인
삼성자산운용 펀드 목록	미래에셋자산운용 펀드 목록	KB자산운용 펀드 목록	한국투자신탁운용 펀드 목록	타임폴리오자산운용 ETF 목록
삼성자산운용 펀드 상세	미래에셋자산운용 펀드 상세	KB자산운용 펀드 상세	한국투자신탁운용 펀드 상세	타임폴리오자산운용 ETF 상세

pxdAX 관찰 노트

Vol.2의 관찰을 종합하면 자산운용사의 펀드·ETF는 SEO 노출의 문제가 아니라 GEO(AIEO) 선택(인용) 단계에 도달하지 못한 상태에 놓여 있다.
선택은 시작되지 않거나 시작되더라도 비교와 검증 단계로 이어지지 않는다.

이 흐름이 개별 운용사나 개별 페이지의 문제가 아니라면 왜 이 업종에서는 AI·검색 환경에서 선택 이전 단계에 머무를 수밖에 없는가?

다음 편에서는 이 질문을 중심으로 자산운용사 업종이 GEO(AIEO) 환경에서 구조적으로 가지는 조건을 살펴본다.

GEONIQ 서비스 바로가기

GEONIQ Integrated Insight Report는 GEONIQ, pxd story, xe group tech blog 에서 동시 발행 됩니다.