pxd story

AI 전사 도입 시대, 스마트워커 되기 - 강의 후기

강은영 — Thu, 10 Sep 2026 07:50:39 +0900

들어가며

얼마 전 "AI 전사 시대, 스마트워커로 살아남는 법"라는 강의를 듣고 왔습니다. 하루 만에 Claude Code의 핵심과 실무 활용법을 쭉 훑어보는 알찬 시간이었어요.

강의를 듣는 내내 머릿속에 계속 맴돌던 핵심 문장이 하나 있었습니다.

"이제는 내가 직접 일하기보다, AI 인부 5~10명을 관리하는 현장 감독이 되어야 한다."

코드를 직접 짜는 개발자뿐만 아니라, 저 같은 비개발자나 일반 실무자도 '관리자 마인드'로 AI를 대할 때 비로소 일의 생산성이 폭발한다는 이야기였죠. 오늘은 강의에서 인상 깊었던 핵심 인사이트와 실습에서 배운 유용한 실무 팁을 함께 정리해 보았습니다.

1. 시대의 변화: 프롬프트 입력에서 '현장 감독'으로

예전의 AI 활용이 "프롬프트 하나 잘 던지는 기술"이었다면, 이제는 여러 AI 에이전트에게 역할을 나누어 맡기고 결과를 검수하는 '관리자의 역량'이 중요해졌습니다.

일반 챗봇: '뇌'만 있어서 질문에 답을 알려주는 수준
Claude Code: '뇌 + 손'이 결합되어 실제 파일 실행 및 환경 제어까지 끝내는 AI Agent

[스마트워커의 새로운 태도]

실행 (Execution): 사람이 직접 하던 타이핑/작업을 AI에게 전권 위임
반복 (Routine): 매번 수동으로 하던 일을 스킬 및 템플릿으로 자동화
역할 (Role): 단순 실무 수행자에서 기획, 맥락 제공, 최종 판단자로 전환

2. 먼저 용어부터 깔끔하게 정리하기

헷갈리기 쉬운 AI 용어들은 '포함 관계'로 이해하면 한눈에 들어옵니다.

AI (인공지능): 가장 큰 범주
생성형 AI (Generative AI): 글·그림·영상을 만들어내는 기술 (예: ChatGPT)
LLM (대형 언어 모델): 생성형 AI의 언어 처리 엔진 (예: GPT-4, Claude, Gemini)
AI Agent: 스스로 목표를 세우고 외부 도구를 활용해 실행까지 완수하는 주체

Claude Code는? LLM을 강력한 엔진 삼아, 스스로 행동하는 'AI Agent'처럼 동작하는 도구입니다.

3. Claude Code의 핵심 강점 4가지

깊은 업무 맥락 이해 (@ 태그 & CLAUDE.md) 매번 같은 회사/업무 배경을 길게 설명할 필요 없이 @ 태그로 폴더나 파일을 지정하고, 프로젝트 가이드북 역할을 하는 CLAUDE.md를 통해 업무 맥락을 유지합니다.
자율적인 문제 해결 능력 탐색 ➔ 실행 ➔ 에러 감지 ➔ 코드/로직 수정 ➔ 재실행을 스스로 반복합니다.
외부 도구 생태계 연결 (MCP) MCP(Model Context Protocol)를 통해 Slack, Google Workspace, 캘린더 등 사내 툴과 직접 연동됩니다.
반복 업무의 명령어화 (스킬) 자주 하는 작업 흐름을 '스킬'로 저장해 두고 단 한마디로 자동 실행합니다.

4. 일을 잘 시키는 상사의 지혜: 플랜 모드와 모델 선택

AI에게 일을 잘 시키는 핵심은 "좋은 상사처럼 일하는 것"입니다.

실행 전 방향을 맞추는 Shift + Tab (플랜 모드) 무작정 실행부터 하게 두지 않고 Shift + Tab을 눌러 플랜 모드로 진입하세요. AI가 먼저 전체 실행 계획을 제시하고, 내가 검토/승인한 뒤에만 작업에 착수합니다.

진행 여부 확인(Prompt) 팁 작업 중 "Do you want to proceed?"라는 질문이 계속 나와 흐름이 깨진다면, "Yes, and don't ask again for..." 선택지를 이용해 승인 팝업 없이 더 빠르게 작업을 맡길 수 있습니다.

난이도별 Claude 모델 선택 가이드

Haiku: 가벼운 데이터 정리 및 단순 요약
Sonnet: 일상적인 대부분의 실무 및 코드/문서 작성
Opus: 복잡한 추론이나 아키텍처 설계
Fable: 가장 까다롭고 깊은 맥락 이해가 필요한 고난도 작업

5. 나만의 워크스페이스(CLAUDE.md) 세팅과 스킬 구축

실습을 진행하며 가장 유용했던 것은 나만의 폴더 구조와 프로필을 설정하는 것이었습니다.

CLAUDE.md 파일 활용하기 VS Code에서 /setup-workspace 명령어를 실행하고 이름, 직무, 관심사 등을 입력하면 나만의 사용자 프로필이 CLAUDE.md로 저장됩니다.

파일/폴더별로 CLAUDE.md 전용 가이드북을 만들 수 있습니다.
다만, 문서가 많아지면 읽을 때 토큰이 소모되므로 필요한 핵심 폴더 위주로 신중하게 생성하는 것이 좋습니다.

아이디어를 앱/서비스로 배포하는 5단계 프로세스 아이디어를 실제 가시적인 서비스로 만드는 과정은 다음과 같이 진행됩니다.

기획 (PRD 작성): AI가 AskUserQuestion으로 질문하며 상세 기획서(PRD)를 함께 완성
맥락 연결: 완성된 PRD 내용을 기반으로 CLAUDE.md 세팅 및 스킬 연동
화면/기능 구현: HTML/CSS 및 로직 구현 (미리보기 화면으로 확인)
검수 및 수정: 로컬 테스트 및 예외 사항 보완
배포: GitHub Push 및 Vercel 등을 통한 실제 자동 배포

6. 롱런을 위한 컨텍스트 관리 꿀팁

대화가 길어질 때 사용할 수 있는 유용한 명령어들입니다.

/compact : 길어진 대화의 핵심 맥락만 압축 정리
/clear : 이전 대화를 비우고 새로운 상태로 시작
/context : 현재 사용 중인 컨텍스트 용량 확인
/resume & /rename : 지난 대화 이어보기 및 대화방 이름 변경
ESC 키 : AI가 엉뚱한 방향으로 실행할 때 즉시 정지 및 방향 전환

마치며

하루라는 짧은 시간이었지만, 이번 강의와 실습을 통해 Claude Code의 기본 기능과 전체적인 동작 흐름을 확실하게 파악할 수 있었습니다. 막연하게 느껴졌던 AI 에이전트 개념이 손에 잡히기 시작했고, 실무에서 기본적으로 어떻게 다루고 활용해야 할지 감을 잡은 것이 가장 큰 성과였습니다.

강의 자료에 적혀 있던 이 문장처럼, 주저하지 말고 직접 실행해 보면서 익혀나가는 게 핵심인 것 같아요. "무엇을 마주쳐도, 일단 해보면 된다 (Action First -> Iterate -> Make It Yours)"

감사합니다.

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

합성 사용자(Synthetic User)를 보는 세 가지 기준 - Act

Seungyoon Lee — Mon, 7 Sep 2026 03:05:29 +0900

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview [바로가기]
2. Anchor [바로가기]
3. Align [바로가기]
4. Act

Act

합성 사용자는 대부분 질문에 잘 대답하는 사용자에서 출발했습니다. 그런데 합성 사용자에게 UX에 대한 의견을 구하게 되면서 의견을 생성하는 것을 넘어 실제 행동으로 경험을 할 수 있게 해야 합니다. 그래서 점점 궁금해지죠.

이 합성 사용자는 실제 사람의 경험 중에서 어디까지 행동할 수 있는가? (What can this synthetic user actually do?)

Act의 자율성

합성 사용자의 행동 수준은 어떤 스펙트럼을 구성할까요?

답변 Answer

합성 사용자는 백그라운드, 니즈, 목표, 속성, 페인포인트, 선호도 등의 정보를 바탕으로 ‘이 기능을 어떻게 생각하세요?’ ‘무엇이 가장 걱정되나요?’ ‘왜 이 브랜드를 선택하겠어요?’와 같은 질문에 대해서 대답합니다. 또는 인터뷰, 서베이와 같은 리서치에 참여하여 질문에 대답하고 의견을 내기도 합니다. 여러 리서치 회사에서 합성 사용자 패널을 만들어 서베이를 하거나 콘셉트 테스트를 하는 상황을 상상해 보면 됩니다.

사용 Interact

최근 합성 사용자는 실제 제품이나 프로토타입을 직접 조작하기 시작했습니다. 예를 들어 합성 사용자에게 프로토타입을 제공하고 직접 태스크를 수행하게 하는 것입니다. 그러면 합성 사용자가 남긴 세션 정보를 통해 어디를 클릭하는지, 어디에서 뒤로 돌아가는지, 어디에서 머뭇거리는지 클릭 패스, 히트맵과 같은 데이터를 얻을 수 있게 됩니다. 이후 왜 여기서 머뭇거렸는지, 왜 뒤로 돌아갔는지 후속 질문을 던질 수도 있겠지요.

Synthetic Users는 합성 사용자가 실제 화면을 조작하며 발생시킨 클릭, 호버 등의 행동 데이터와 개별 페르소나를 결합해, 화면의 어느 곳에 주의를 둘지 예측한 히트맵을 제공합니다.

합성 사용자의 탐색 흔적 (탐색했을 거라고 추정)

합성 사용자는 점점 ‘어떤 버튼을 누를 것 같다’고 대답하는 존재에서 실제 화면 안에서 버튼을 찾고 탐색하는, 행동하는 존재로 확장되고 있습니다.

자율 탐색 Explore

사용 (Interact)이 "주어진 화면 안에서" 사용하는 것이라면, 자율 탐색 (Explore)은 합성 사용자가 목표를 달성하기 위해 능동적으로 행동하는 것을 의미합니다. 합성 사용자에게 태스크가 아니라 목표를 제시하면 무엇을 할지 스스로 정하고, 필요한 곳을 찾아다녀서 목적을 달성하게 하는 것이지요.

쇼핑으로 비유하면, 사용 (Interact)은 "이 온라인몰에서 검정 백팩 하나 골라봐"에 가깝습니다. 해당 몰에서 최선의 검정 백팩을 고르기 위해 노력하죠. 반면 이 단계의 합성 사용자가 받는 미션은 "출근용 가방이 필요해”에 가깝습니다. 합성 사용자는 여러 사이트를 찾아다니고, 후기를 읽고, 가격을 비교하고, 어떤 건 담아뒀다 결국 사거나 포기합니다. 어디까지 갈지, 무엇을 볼지, 언제 그만둘지를 스스로 정합니다.

기억과 목표를 가진 25명의 AI 에이전트가 스스로 살아가는 마을(Smallville)을 만든 스탠퍼드의 생성 에이전트 연구가 있습니다. 이 연구의 흐름은 이후 Simile로 이어졌습니다. 생성 에이전트 연구와 Simile이 공통적으로 보여주는 문제의식은, AI를 단순히 더 똑똑한 비서로 만드는 것만으로는 인간을 충분히 재현할 수 없다는 점입니다. 중요한 것은 사용자의 가치, 취향, 경험, 행동 패턴을 모델링하고, 특정 상황에서 그 사람이 실제로 어떤 선택을 할지를 재현하는 것입니다.

Simile

Act 스펙트럼

지금까지 살펴본 세 유형은 아래와 같이 정리해 볼 수 있습니다.

응답하는 사용자에서 행동하는 사용자로

합성 사용자의 목표는 가장 똑똑하게 과업을 해결하는 에이전트를 만드는 것이 아니라 특정한 사람이 실제로 선택할 법한 행동을 재현하는 것입니다. 또, 합성 사용자의 다음 단계는 기억과 경험이 누적되면서 스스로 변화하는 모델이 될 가능성이 큽니다. 그래서 Anchor, Align, Act 세 축이 서로 맞물려 돌아가야 합니다.

사람에 근거하고 (Anchor)
실제와 맞춰가며 (Align)
자율적으로 행동하는 (Act)

우리가 만드는 합성 사용자는 어떤 단계에 있나요? AAA: Anchor, Align, Act 프레임으로 한번 평가해 보세요.

참고

Where do synthetic eyes look?, Synthetic Users, https://www.syntheticusers.com/science-posts/where-do-synthetic-eyes-look#gaze-screen-18

Computational Agents Exhibit Believable Humanlike Behavior, Stanford University Human-Centered Artificial Intelligence, https://hai.stanford.edu/news/computational-agents-exhibit-believable-humanlike-behavior

Simile, https://www.simile.com

합성 사용자(Synthetic User)를 보는 세 가지 기준 - Align

Seungyoon Lee — Mon, 7 Sep 2026 02:56:49 +0900

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview [바로가기]
2. Anchor [바로가기]
3. Align
4. Act [바로가기]

Align

합성 사용자가 실제 사용자 데이터에 잘 닿아 있다고 해서, 실제 사용자처럼 반응하는 것은 아닙니다. 실제 인터뷰, 설문, 고객 데이터, 행동 로그를 기반으로 만들어졌더라도 새로운 질문이나 새로운 제품 상황에서 전혀 다른 반응이 나오기 때문입니다. 그래서 두 번째로 이런 질문이 떠오릅니다.

이 합성 사용자는 얼마나 실제 사람같이 반응하는가?(How well does this synthetic user align with reality?)

예를 들어 여러 EV 배터리를 비교해 본 사용자는 "배터리에서 무엇이 가장 중요한가"에는 그 경험을 근거로 일관되게 답합니다. 하지만 "구독형 배터리 교체 서비스가 나오면 가입하겠는가"처럼 겪어보지 않은 새로운 상황에는, 그럴듯한 답을 자신 있게 내놓더라도 그것이 실제 사용자의 선택과 같으리란 보장이 없습니다.

그래서 그럴듯하게 응답하느냐(plausibility)를 넘어, 실제 사용자의 응답과 얼마나 일치하느냐(alignment)를 확인해야 합니다.

Align의 깊이

현실과 얼마나 일치하는지 확인하는 스펙트럼에 대해서 알아봅니다.

그럴듯함 (Plausible)

가장 기본적인 수준은 결과를 사람이 읽고 “그럴듯하다”라고 판단하는 것입니다. 아이데이션 단계에서는 그럴듯한 답변을 하는 것만으로도 어느 정도 유용한 결과를 얻을 수 있습니다. 하지만 아직은 실제 사람이 이렇게 이야기할지 아닌지는 모르는 상태입니다.

전문가 검토 (Expert-reviewed)

좀 더 나아가서는 합성 사용자의 응답을 UX 리서처나 도메인 전문가가 검토할 수 있습니다. 예를 들어, 기존 인터뷰에서 보던 패턴과 비슷한가? 지나치게 전형적인 답변은 아닌가? 너무 논리적인가? 기존 리서치 근거와 맞지 않는 점은 없는가? 등에 대한 검증을 할 수 있습니다. 한편, 전문가의 검토는 합성 사용자의 잘못된 답변을 가리는데 도움이 되지만 여전히 실제 사용자의 응답과 일치하고 있는지를 알기는 아직 어렵습니다.

응답 일치 (Human response-aligned)

합성 사용자와 실제 사람에게 동일한 질문을 하고 결과를 비교하는 방식입니다. 예를 들어 EV 브랜드 선호도를 묻는 질문을 합성 퍼소나와 동일한 특성을 가진 실 사용자에게 동시에 묻는 방식입니다. 두 결과가 얼마나 유사한지 비교하는 과정을 통해 합성 사용자 응답의 정합성을 맞춰 나가게 되고 이 단계부터 합성 사용자가 얼마나 현실을 반영하고 있는지 기준을 가지게 됩니다.

퀄트릭스는 자체 합성 패널과 실제 패널을 동일한 인구 통계 조건으로 매칭한 뒤 같은 질문에 대한 응답을 비교했습니다. 이렇게 합성 패널의 응답이 실제 패널과 얼마나 가까운지 측정함으로써 합성 응답의 정합성을 검증합니다.

행동 일치 (Behavior-aligned)

UX 리서치에서는 사용자의 행동이 중요합니다. 실제 사용자와 합성 사용자 모두 “이 기능은 쉽게 사용할 수 있을 것 같아요.”라고 말할 수 있지만, 이 기능을 실제로 사용해 보는 태스크를 수행할 때에는 다른 행동을 보여줄 수도 있기 때문입니다.

합성 사용자와 실제 사용자의 말은 일치할 수 있지만 행동은 일치하지 않을 수 있다는 말입니다. 그래서 합성 사용자를 평가하려면 태스크 성공 여부, 내비게이션 경로, 에러 여부, 백버튼(백트래킹), 포기, 소요 시간, 클릭/터치 횟수 등과 같은 항목을 비교 테스트 해야 합니다.

Userbrain은 합성 사용자와 실제 사용자에게 요금제 프로토타입에서 동일한 태스크를 수행하게 했습니다. ‘월 20명의 테스터를 이용할 때 가장 저렴한 옵션'을 찾으라는 태스크에서 실제 사용자는 5명 중 3명이 정답을 맞힌 반면, 합성 사용자는 모두 정답을 맞혔습니다. 실제 사용자가 겪은 실패를 재현하지 못하고 보다 이상적으로 성공한 것입니다.

User Brain의 테스트에 쓰인 화면 프로토타입

닐슨노만그룹(NN/g)은 실제 사용자와 진행했던 연구에 합성 사용자를 붙여, 합성 사용자가 생성한 응답을 실제 인터뷰 결과와 비교했습니다. 그 결과, ‘업무 방식’과 같은 일반적인 질문에 대해서는 실제 사용자와 유사한 답변을 했지만, 실제 경험을 묻는 대목에서 크게 차이가 있음을 발견했습니다. 예를 들어, 온라인 학습에서 실제 사용자들은 강의가 좋았지만 코스를 끝까지 마치지는 않았는데, 합성 사용자는 언급한 코스를 모두 완료했다고 응답했습니다.

닐슨노만그룹은 합성 사용자가 '의견'은 그럴듯하게 만들어내도 '실제로 무엇을 했는지'에 대한 행동 데이터는 만들어내지 못한다고 합니다. 말은 사람처럼 들려도 실제 행동과 경험은 검증 없이 어긋날 수 있다는 것, 이것이 행동 일치를 따로 확인해야 하는 이유입니다.

NN/g의 비교 연구를 설명한 유튜브 Synthetic Users: AI “Participants”

변화 일치 (Continuous alignment)

사용자의 생각과 행동은 고정되어 있지 않습니다. 새로운 기능에 익숙해지거나, 제품을 반복해서 사용하거나, 시장 환경이 변하면서 응답과 행동도 달라질 수 있습니다. 따라서 합성 사용자도 특정 시점의 사용자 데이터를 그대로 유지하는 것이 아니라, 새롭게 관찰된 현실을 다시 반영해야 합니다.

예를 들어 새 EV 충전 예약 기능이 출시되기 전과 후의 사용자의 의견에 대해서 변화가 있을 수 있습니다. 새 기능이 출시되기 전에는 합성 사용자와 실제 사용자가 서로 같은 의견으로 시작하지만, 실제 사용자가 제품을 사용해 본 후 기대와 다른 방향으로 사용하게 된다면, 이후 합성 사용자도 의견을 업데이트할 수 있도록 해야 할 것입니다.

변화 일치는 단순히 최신 데이터를 추가하는 것이 아니라, 실제 사용자의 생각과 행동이 어떻게 변했는지를 다시 관찰하고 그 변화를 합성 사용자에 반영하면서 지속적으로 정합성을 맞춰가는 과정이라고 할 수 있습니다.

Sentia Labs는 합성 사용자로 제품을 시뮬레이션한 뒤, 출시 후에는 실제 고객 데이터를 바탕으로 모델을 다시 수정하는 닫힌 루프(closed loop)를 사용합니다. 이렇게 되면 합성 사용자는 특정 시점에 만들어진 퍼소나가 아니라 실제 사용자와 시장 변화에 따라 계속 갱신되는 사용자 모델에 가까워집니다.

Sentia Labs에서 합성 사용자의 모델을 업데이트 하는 과정

Align 스펙트럼

지금까지 살펴본 다섯 가지 유형은 아래와 같이 정리해 볼 수 있습니다.

그런데, 어디까지 행동하는가?

Anchor는 합성 사용자가 어디에서 왔는가, Align은 합성 사용자의 응답과 행동이 실제로 현실과 맞는가에 대한 이야기였습니다.

이제 실제 사람과 같은 합성 사용자를 만들었다면, 그 합성 사용자는 어디까지 행동할 수 있을까요? 묻는 말에 잘 대답하면 그걸로 충분할까요? 합성 사용자가 어떤 역할까지 할 수 있는지 다음 글, Act에서 알아보겠습니다.

참고

Testing Synthetic Data Against Academic Benchmarks: A Replication Study, Greenbook, https://www.greenbook.org/insights/data-science/testing-synthetic-data-against-academic-benchmarks-a-replication-study

We Ran an Experiment with Synthetic Users: Here’s What We Found, User Brain, https://www.userbrain.com/blog/synthetic-users-experiment

Synthetic Users: If, When, and How to Use AI-Generated “Research”, NN/g, https://www.nngroup.com/articles/synthetic-users

Synthetic Users: AI “Participants,” NN/g, https://www.youtube.com/watch?v=q_fdcbwHJKQ&t=6s

Sentia Labs, https://www.sentialabs.ai/synthetic

합성 사용자(Synthetic User)를 보는 세 가지 기준 - Anchor

Seungyoon Lee — Mon, 7 Sep 2026 02:39:44 +0900

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview [바로가기]
2. Anchor
3. Align [바로가기]
4. Act [바로가기]

Anchor

AI가 생성한 사용자의 많은 특성은 실제 고객에게서 관찰된 것이 아니라 모델이 이미 학습한 사람에 대한 일반적인 패턴에서 채워집니다. ‘30대 직장 여성’이라는 조건만 있어도 AI는 수많은 다양한 합성 사용자를 생성할 수 있습니다. 우리가 입력하지 않은 정보가 자연스럽게 채워지면 어느 순간 이 모든 것들이 근거 있는 실제 데이터처럼 느껴집니다. 그래서 합성 사용자를 볼 때 다음 질문을 합니다.

이 사용자는 실제 무엇에 근거하고 있는가? (What is this synthetic user anchored in?)

사용자의 실제 데이터에 닻을 내린다는 의미로, Anchor라고 부르려고 합니다.

Anchor가 닿는 위치

모든 합성 사용자가 동일한 수준의 근거를 가지고 만들어지는 것은 아닙니다. 얼마나 현실의 데이터에 깊게 닿아 있는지에 대한 스펙트럼이 존재합니다.

가정 기반 (Assumption)

일단 프롬프트만으로 만들어진 합성 사용자가 있습니다. 우리가 성별, 나이, 목적 정도의 정보를 프롬프트로 입력하면 나머지는 AI가 채우는 방식입니다.

예를 들어, “40대 일본 남성, EV 구매를 고민 중, 새로운 충전 환경 구축 프로젝트에 필요”라고 정의하면 AI는 그에 맞는 관심사, 걱정, 구매 기준 등을 척척 생성해 냅니다. (아래 더보기에서는 ChatGPT가 바로 생성한 합성 사용자 프로필을 볼 수 있습니다.)

합성 사용자 타카시 사토

이름: Takashi Sato / 佐藤隆志
나이: 46세
거주지: 일본 요코하마시
직업: 중견 제조기업 영업기획 매니저
가족: 아내, 고등학생 자녀 1명
주거: 약 12년 된 분양 맨션, 지하 공용주차장 이용
차량: 7년 된 하이브리드 SUV 보유
연간 주행거리: 약 10,000–12,000km
평일 출퇴근은 전철 중심, 자동차는 주말·가족 이동·장보기·여행에 주로 사용

현재 상황
다음 차량으로 EV를 진지하게 검토하고 있다. 자동차 자체에 대해서는 긍정적이다. 정숙성, 유지비, 최신 기술, 집에서 충전할 수 있다는 점에 매력을 느낀다. 하지만 현재 거주하는 맨션에는 자신의 주차구역에 개인 충전기가 없으며, 향후 충전기가 설치되더라도 “실제로 내가 필요할 때 사용할 수 있을까?”에 대한 확신이 없다. 그에게 EV 구매의 가장 큰 문제는 차량 가격보다 오히려 충전 환경의 불확실성이다.

EV에 대한 태도
“EV 자체는 이제 충분히 괜찮다고 생각해요. 문제는 차가 아니라, 충전을 얼마나 신경 쓰면서 살아야 하느냐인 것 같아요.”
신기술을 좋아하지만 얼리어답터는 아니다. 기술적으로 새롭다는 이유만으로 구매하지 않고, 이미 충분히 안정적으로 작동한다는 확신이 생긴 뒤 구매하는 편이다.

충전과 관련한 핵심 니즈

충전을 별도의 일로 만들고 싶지 않다.
귀가해서 주차하면 자연스럽게 충전되고, 다음에 차를 사용할 때 필요한 만큼 충전되어 있기를 원한다.
충전 가능 여부를 미리 알고 싶다.
집에 도착한 뒤 “충전기가 다 사용 중”이라는 사실을 발견하는 상황을 싫어한다. 필요하다면 예약이나 자동 배정 기능을 선호한다.
매번 완충할 필요는 없다.
자신의 다음 이동 일정에 필요한 만큼만 충전되어 있으면 된다고 생각한다.
충전 비용을 통제하고 싶다.
심야 전력이나 저렴한 시간대를 자동으로 활용해 전기요금을 최소화해 주기를 기대한다.
문제가 생겼을 때 자신이 해결하고 싶지 않다.
충전기 고장, 결제 오류, 다른 차량의 장시간 점유 같은 문제를 관리사무소나 시스템이 알아서 처리해 주기를 원한다.

Typical Scenario
금요일 오후, 회사에서 집으로 돌아가는 전철 안에서 주말 가족 일정이 확정된다.
토요일 오전에는 자녀를 학원에 데려다주고, 오후에는 쇼핑몰, 일요일에는 가족과 약 150km 떨어진 곳으로 당일 여행을 갈 예정이다.
Takashi는 차량 앱을 확인한다.
현재 배터리는 38%.
시스템은 그의 캘린더와 평소 이동 패턴을 기반으로 다음 날 오전까지 약 80% 충전이 필요하다고 판단한다. 하지만 현재 맨션 충전기는 다른 차량들이 사용 중이다.

Takashi가 원하는 경험은:
“충전기를 찾아서 예약하고 충전 시간을 계산하는 것”이 아니라
“일요일 여행을 위해 필요한 충전이 준비되어 있습니다.”
라는 결과만 확인하는 것이다.
시스템이 알아서 충전 가능한 시간을 찾아 배정하고, 전력 사용량이 낮은 새벽 시간에 충전을 시작해 비용까지 최적화해 주기를 기대한다.

Pain Points
현재 내연기관 차량

주유소 방문은 귀찮지만 5분이면 끝난다는 확신이 있음
장거리 여행에서도 어디서 주유할지 크게 고민하지 않음

EV로 바꿀 경우 예상되는 불안

맨션 충전기를 다른 주민과 공유해야 하는 문제
충전기 설치 후 이용자가 늘어났을 때의 대기
다른 사람이 충전 후 차량을 이동하지 않는 상황
충전기 고장 여부를 출발 직전에 알게 되는 상황
급하게 차량을 사용해야 할 때 충전량 부족
여러 충전 사업자별 앱과 결제 방식
“오늘 밤 충전해야 하나?”를 계속 판단해야 하는 정신적 부담

그가 가장 피하고 싶은 것은 Range Anxiety보다 Charging Management Anxiety에 가깝다.

Decision Criteria for Buying an EV
Takashi가 EV 구매를 결정하려면 다음 질문에 모두 어느 정도 확신이 필요하다.
“집에 돌아오면 충전할 수 있는가?” → 충전기 숫자보다 충전 접근성의 예측 가능성
“내가 충전에 대해 계속 생각해야 하는가?” → 가능하면 자동화
“여러 사람이 사용해도 공정하게 운영되는가?” → 예약·우선순위·사용시간 관리
“전기요금이 예상 가능한가?” → 비용 가시성과 자동 최적화
“갑자기 차가 필요해도 괜찮은가?” → 최소 필요 배터리 확보 또는 긴급 충전

아이데이션 단계에서는 가정 기반 합성 사용자의 의견도 충분히 유용합니다. 새로운 관점이 필요하거나 아이디어를 생성하기 위한 목적이라면 반드시 실제 사람과 꼭 같은 합성 사용자의 의견까지는 필요 없을 것입니다. 저도 얼마 전 끝난 스마트홈 프로젝트에서 생성형 AI로 간단히 만든 합성 사용자를 생성하여 새로운 아이데이션을 평가하여 큰 도움을 받은 적이 있습니다.

스마트 홈 관련 아이데이션에서 퍼소나가 평가하고 의견을 제시하는 과정을 통해 프로젝트 팀의 아이디어를 확장하고 새로운 관점을 얻을 수 있었습니다.

인구 통계 기반 (Population-anchored)

다음 단계는 특정 인구집단의 구조와 분포를 반영하는 것입니다.

인구 센서스, 인구통계, 서베이, 시장 조사 데이터 등을 특정 인구 집단 안에 어떤 특성을 가진 사람들이 얼마나 존재하는지를 근거로 하여 사용자를 만들어 냅니다. 예를 들어 NVIDIA의 Nemotron-Personas-Korea처럼 한국의 인구, 지역, 사회적 분포를 반영해 대규모 합성 퍼소나를 생성한 사례가 있습니다.

NVIDIA Nemotron-Personas-Korea 일부

실제 인구 통계 정보를 기반하여 합성 사용자를 만들었지만, 고객/사용자의 세세한 취향, 태도, 지식을 반영하고 있지는 않습니다. 예를 들어 일본 EV 잠재 구매자를 실제 인구 통계에 맞춰 구성했다고 해도,’늘 붐비는 공용 충전기’에 대해 어떤 의견을 가지고 있는지에 대해서는 명확한 의견을 가지고 있다고 하기 어렵습니다. 물론 AI는 상당 부분 필요한 의견을 생성해 낼 수 있기는 합니다.

그래서 이 인구 분포에 있는 사용자들의 구체적인 특성을 드러내기 위해서 좀 더 사용자의 실제 정보를 바탕으로 합성 퍼소나를 생성해야 할 필요성을 느끼게 됩니다.

고객 데이터 기반 (Customer-anchored)

일반적인 인구집단의 특성만 반영하는 것이 아니라, 실제 사용자나 고객이 과거에 무엇을 말하고 어떻게 반응했는지, 직접 관찰된 사용자 데이터를 활용할 수도 있습니다.

예를 들면 다음과 같은 실제 고객의 데이터를 활용합니다. 인터뷰 스크립트, 서베이 응답, 고객의 소리, NPS 등의 코멘트, 기존에 만들었던 퍼소나 등 말입니다.

제품을 직접 운영하는 기업이라면 실제 고객의 인터뷰, CRM, 고객센터 기록, 제품 사용 데이터 등을 활용할 수 있고, 반대로 자체 제품을 보유하지 않은 리서치 회사라면, 실제 패널이 여러 조사에서 남긴 반복 응답과 행동 데이터를 축적하여 이를 근거로 합성 사용자를 만들 수도 있습니다.

예를 들어, 리서치 준비부터 AI 퍼소나로 UX 검증까지 리서치를 돕는 ReOpsAI는 pxd가 다년간 금융 프로젝트를 수행하며 만난 사용자의 생생한 목소리를 근거로 만든 퍼소나를 제공합니다.

ReOpsAI의 AI 퍼소나 소개

Synthetic Users는 고객사가 보유한 인터뷰, 고객 상담 기록 등의 고유 데이터를 합성 사용자가 참고하도록 연결합니다. 또한 센서스와 사회조사 등 인구집단 데이터도 합성 사용자의 근거로 활용한다고 설명합니다.

Synthetic Users 소개 화면

가령 자체 패널을 장기간 운영하는 회사의 5,000명의 패널에 대해 EV 구매 의향, 가격 민감도, 충전 불안, 주거 형태, 보유 차량, 브랜드 선호, 실제 구매 여부 등이 축적되어 있다면, 합성 사용자는 단순히 “40대 남성은 아마 이렇게 생각할 것이다”라고 가정하기보다 실제로 비슷한 특성을 가진 사람들이 과거에 어떻게 응답했는지를 바탕으로 새로운 응답을 생성하게 됩니다.

이렇게 만들어진 합성 사용자는 인터넷에 존재하는 평균적인 소비자를 흉내 내는 대신 우리 조직이 실제로 관찰해 온 사용자의 의견과 행동을 바탕으로 새로운 질문에 대답하게 됩니다.

합성 사용자는 이제 조직이 축적해 온 고객에 대한 지식을 미래 지향적인 모델로 바꿀 수 있다는 것입니다. 예를 들어 지난 수백 건의 인터뷰, 서베이, FGI, 사용성 평가의 결과가 축적되어 있다면 이제 아카이브에서 꺼내 살아 숨 쉬는 사람으로 만들어 낼 수 있습니다.

고객 행태 기반 (Behavior-anchored)

인터뷰와 서베이에는 사용자가 ‘말한’ 것이 들어 있습니다. 그런데 ‘말한 것’만으로 충분할까요?

UX 리서처가 사람을 직접 관찰하는 이유는 사람들이 자신이 하는 행동을 항상 정확하게 설명하지 못하기 때문입니다. 예를 들어, 사용자는 “저는 EV를 구매할 때 충전 가능 시간”이 제일 중요해요”라고 이야기할 수 있지만 실제로는 디자인을 보고 구매할 수도 있으니까요.

“서술”에서 “행동”으로 Anchor를 확장시키는 것이 필요합니다.

이 단계에서는 클릭 스트림, 내비게이션, 스크롤, 검색, 구매 이력, 태스크 실패로 백하기, 이탈, 에러 등 실제 사용자의 행동 데이터가 필요합니다.

이 데이터는 “사용자가 무엇을 중요하게 생각한다고 말하는가”보다 특정 상황에서 실제로 무엇을 했는가를 보여줍니다. 우리가 원하는 것은 인터뷰에 그럴듯하게 답하는 사용자가 아니라 이 화면에서 무엇을 먼저 보고, 어떤 옵션을 선택하고, 무엇을 놓치고, 어디에서 멈추고, 어떤 실수를 하고, 언제 포기하는지를 재현하는 사용자이기 때문입니다.

업데이트 기반 (Living Evidence)

사람은 변합니다. 시장도 변하고, 제품도 변하고, 기술도 변합니다. 2년 전 사용자가 AI 기능을 받아들이던 방식과 지금 사용자가 받아들이는 방식이 다를 수 있습니다.

실제 데이터를 바탕으로 합성 사용자를 만들었다고 해서 그 합성 사용자가 계속 현실을 반영한다고 볼 수는 없습니다. 그래서 Anchor의 가장 오른쪽에는 지속적인 업데이트로 근거를 생생하게 만드는 업데이트 기반의 합성 사용자가 있습니다. 실제 사용자 변화와 함께 변화하는 모델인 것입니다.

예를 들어 Cresta의 합성 사용자는 기업의 실제 고객 상담 데이터를 바탕으로 고객의 행동 패턴을 모델링하고, 이를 “진화하는 고객 퍼소나 (evolving customer personas)”로 설명합니다. 고객이 실제 상담에서 어떤 언어를 사용하고, 어떤 상황에서 불만을 제기하거나 재확인하고, 어떻게 반응하는지를 지속적으로 반영함으로써 고객 모델을 최신 상태로 유지하려는 접근입니다.

Cresta의 합성 고객 소개

Anchor 스펙트럼

지금까지 살펴본 다섯 가지 유형은 아래와 같이 정리해 볼 수 있습니다.

그런데, 실 사용자처럼 반응하는가?

실제 사용자 데이터를 다양하게 사용한다고 해서 좋은 합성 사용자가 자동으로 만들어지는 것은 아닙니다. 실제 데이터를 학습했더라도 모델이 새로운 상황에서 잘못된 행동을 예측할 수 있습니다. 그래서 다음 질문이 필요합니다.

실제 사용자에 기반해 만들었다면, 정말 실제 사용자처럼 반응하는가?

이 질문에 답하는 것이 Align입니다.

참고

When synthetic users fail: A cross-domain benchmark of llm-simulated human survey responses, https://arxiv.org/pdf/2607.26348

NVIDIA Nemotron-Personas-Korea, https://huggingface.co/datasets/nvidia/Nemotron-Personas-Korea

Generating, running and sharing synthetic research, Synthetic Users, https://www.syntheticusers.com/post/generating-running-and-sharing-synthetic-research-really

ReOpsAI, https://reopsai.com

Cresta, https://cresta.com/synthetic-customers

합성 사용자(Synthetic User)를 보는 세 가지 기준

Seungyoon Lee — Mon, 7 Sep 2026 01:47:42 +0900

지난해, 한 콘퍼런스에서 합성 퍼소나에 대한 발표를 듣고 적잖이 충격을 받았던 기억이 납니다. 바로 피엑스디 내부 팀에서는 ReOpsAI에서 금융 관련 AI 퍼소나를 만들었고 관련 프로젝트도 진행했으니 빠르게 이 새로운 변화를 경험하고 있는 것 같습니다.

ReOpsAI 의 AI 퍼소나

합성 사용자, 무엇이 다른가?

지난 몇 년 사이 AI 퍼소나, 합성 퍼소나, 합성 사용자, 합성 패널, 디지털 트윈 같은 말들이 빠르게 늘었습니다. 이름만 보면 다 비슷해 보입니다. 사용자의 특성을 AI에 부여하고, 질문을 던지고, 그 사람이 어떻게 생각하거나 행동할지를 알아보는 방식이니까요.

하지만 조금만 들여다보면 서로 다른 문제에 답하고 있다는 걸 알 수 있습니다. OpenAI의 리서처 Saeideh Bakhshi는 합성 사용자를 입력되는 데이터의 성격, 결과물이 제공하는 의미 등에 따라 6가지로 분류했습니다. 그런데 이 이름들의 경계는 생각보다 뚜렷하지 않고 빠르게 변화하고 있으므로 이 글에서는 ‘합성 사용자’는 넓은 개념의 용어로 접근하려고 합니다.

하지만 다양한 합성 사용자를 어떤 관점으로 봐야 하는가는 중요합니다. 여러 형태의 합성 사용자의 능력과 가치를 어떤 기준으로 봐야 할 것인지, 이번 글에서는 Anchor(근거), Align(정합), Act(행동)이라는 3가지 주제를 얘기해보려고 합니다.

합성 사용자를 보는 세 가지 기준

[Anchor] 합성 사용자는 무엇을 근거로 만들어졌는가?

합성 사용자를 볼 때 가장 먼저 물어야 할 것은 ‘이 사용자가 무엇에 근거하는가’입니다.

LLM에게 ‘EV를 구매하려고 하는 퍼소나를 만들어줘’라고 하면 구매 동기, 기대사항 등 그럴듯한 정보를 만들어냅니다. 그 과정에서 실제로 존재하지 않은 근거가 어느새 진짜처럼 보이기도 합니다.

합성 사용자를 만들어내기 위한 근거가 사용자에게 얼마나 깊이 있게 닿아있느냐, 즉 근거의 직접성에 따라 합성 사용자의 모습이 달라집니다. 이 글에서는 프롬프트에서 시작하는 가정 기반(Assumption), 인구 통계 기반(Population-anchored), 고객 정보 기반 (Customer-anchored), 고객 행태 기반(Behavior-anchored), 나아가 실제 데이터가 계속 갱신되는 업데이트 기반(Living Evidence)으로 구분했습니다. 후자로 갈수록 모델의 상상에서 실제 사용자를 관찰하게 됩니다.

[Align] 합성 사용자의 반응은 얼마나 실제 사용자와 일치하는가?

고객 정보에 잘 근거한 합성 사용자를 만들었습니다. 그런데 이 합성 사용자가 실제 사용자처럼 반응한다고 보장할 수 있을까요? 그럼 우리는 ‘이 사용자의 반응이 얼마나 실제와 일치하는가’를 확인해야 합니다.

합성 사용자의 반응이 ‘사람 같은가(plausible)’와 ‘실제 사용자와 일치하는(aligned)’는 전혀 다른 이야기입니다. 따라서 합성 사용자를 리서치나 의사결정에 쓰려면 현실과 맞는지 확인하는 과정이 필요합니다.

합성 사용자를 무엇과 대조해서 확인하는가에 따라 합성 사용자의 정합성을 판단할 수 있습니다. 이 글에서는 그럴듯함(Plausible), 전문가 검토(Expert-reviewed), 응답 일치(Human response-aligned), 행동 일치(Human behavior-aligned), 변화 일치(Continuous alignment)로 구분했고 후자로 갈수록 현실을 직접적이고 반복적으로 대조하게 됩니다.

[Act] 합성 사용자는 실제로 무엇을 할 수 있는가?

사람은 말과 행동이 다릅니다. 그래서 합성 사용자가 UX에서 더 의미 있는 도구가 되려면, 질문에 대답하는 것을 넘어 ‘제품과 서비스를 행동으로 경험할 수 있어야’ 합니다.

합성 사용자가 얼마나 자율성을 가지느냐에 따라 사용자에 대답(Response), 제품을 사용(Interact), 자율 탐색(Explore)으로 구분했습니다.

[AAA] Anchor, Align, Act

정리하면 합성 사용자는 이 세 가지 질문으로 볼 수 있습니다. 무엇에 근거하는가(Anchor), 현실과 얼마나 맞는가(Align), 실제로 어디까지 행동하는가(Act).

다만 이 스펙트럼을 단순한 성숙도 단계로 볼 필요는 없습니다. 모든 합성 사용자가 세 축의 가장 오른쪽까지 갈 필요도 없습니다. 아이데이션에 필요한 합성 사용자와 실제 제품 행동을 예측하기 위한 합성 사용자에게 요구되는 근거와 검증, 행동 능력은 다르기 때문입니다. 중요한 것은 합성 사용자를 어디에 사용할 것인지에 맞춰 필요한 수준의 Anchor, Align, Act를 갖추는 것입니다.

그렇다면 현재 합성 사용자 관련 서비스들은 AAA의 어느 위치에 있을까요?

합성 사용자 관련 서비스를 제공하는 LLM이 만드는 퍼소나, ReOpsAI, Synthetic Users, Simile는 대략 어떤 서비스를 제공하고 있을까를 매핑해 봤습니다.

● 해당함 ❘ △ 부분적으로 해당함 ❘ 빈칸 = 해당 없음

이 세 기준은 서로 독립적이면서 유기적입니다. 데이터가 풍부해도(Anchor), 실제로 행동하지는 못할 수 있고(Act), 능숙하게 행동해도 그것이 실제 사람과 비슷한지는 또 다른 문제(Align)입니다. 그래서 좋은 합성 사용자는 AAA가 모두 최대치인 사용자가 아니라, 하려는 의사결정에 필요한 만큼의 Anchor, Align, Act를 갖춘 사용자일 것입니다.

이어지는 세 편의 글에서 각 기준을 하나씩 들여다보겠습니다.

합성 사용자(Synthetic User)를 보는 세 가지 기준
1. Overview
2. Anchor [바로가기]
3. Align [바로가기]
4. Act [바로가기]

참고

Synthetic users are not one method, Saeideh Bakhshi, https://saeidehbakhshi.substack.com/p/synthetic-users-are-not-one-method

ReOpsAI, https://reopsai.com

Synthetic Users, https://www.syntheticusers.com

Simile, http://www.simile.com

화면 설계서의 디스크립션을 대신 써 주는 Figma 플러그인을 만들었습니다

문한별 — Thu, 27 Aug 2026 07:50:05 +0900

UX 디자이너로서 화면 설계서를 작업해 본 분이라면 아실 겁니다. 화면을 그리는 일은 그래도 할 만합니다. 손이 가긴 해도 눈에 보이는 결과가 쌓이니까요. 문제는 그 옆에 붙는 디스크립션입니다.

버튼 하나에 번호를 매기고, 번호마다 “이건 무슨 버튼이고, 누르면 어떻게 되고, 어떤 조건에서 비활성화되는가”를 한 줄씩 적어 내려갑니다. 화면 하나에 요소가 스무 개면 스무 번. 화면이 쉰 장이면… 세는 것도 일입니다. 게다가 초벌을 넘겼다고 끝이 아닙니다. 개발을 하면서, 정책과 화면이 바뀔 때마다 몇 주에서 몇 달을 고칩니다. 이 팔로업이 사실 규격서 작업에서 가장 오래 걸리는 일입니다.

그러다 문득 궁금해졌습니다. 이 반복 작업의 절반 이상을 AI가 대신해 줄 수 있지 않을까요?

그래서 만들기 시작했습니다. 이름은 SpecSaver입니다. 스펙 쓰는 시간을 세이브하겠다는 포부를 담았지요. Figma로 작업된 화면 설계서 내의 Key screen을 분석해, 각 화면의 디스크립션을 자동으로 생성해 주는 플러그인입니다. 실제로 써 보면 체감이 꽤 큽니다. 화면 한 장의 디스크립션 초안을 손으로 쓰면 보통 30분에서 1시간은 잡아야 하는데, SpecSaver로 초안을 뽑고 검토, 보완까지 마치면 10분 안팎으로 줄어듭니다. 물론 화면 복잡도와 검토 꼼꼼함에 따라 편차는 있습니다. 중요한 건 0에서 문장을 쥐어짜는 시간이, 이미 있는 초안을 다듬는 시간으로 바뀐다는 점입니다.

만들면서 기준으로 삼은 건 하나였습니다. 기획자가 실제로 일하는 방식에서 출발하자. 없던 일을 새로 시키는 도구가 아니라, 이미 하고 있는 일을 덜어주는 도구여야 한다고 봤습니다.

그려진 화면을 이미지로 봅니다

사실 SpecSaver의 첫 버전은 화면을 지금과 다른 방식으로 읽었습니다. 선택한 화면의 레이어 구조를 읽었습니다. Figma 파일 안에는 화면을 이루는 레이어들이 이름표를 달고 트리로 쌓여 있는데, 그 트리를 훑어 “여기는 버튼, 저기는 입력창”을 찾아내는 방식이었죠. 텍스트와 좌표를 정확히 가져올 수 있어서 나쁘지 않았습니다.

바쁜 기획자에게 레이어 정리까지 시키는건 쉽지 않다

문제는 이 방식이 디자이너 또는 기획자가 레이어를 얼마나 깔끔하게 정리했는지에 통째로 의존한다는 것이었습니다. 현실의 Figma 파일은 그렇게 단정하지 않습니다. 레이어 이름이 ‘Frame 42085672169’로 남아 있는 경우가 태반이고, 눈으로 보면 분명히 하나의 ‘검색 영역’인데 레이어 구조상으로는 뿔뿔이 흩어져 있기도 합니다. 그러면 도구는 “여기가 한 덩어리다”를 알아채지 못하고 엉뚱하게 쪼개거나 놓칩니다.

여기서 선택지가 갈렸습니다. 실무자에게 “도구가 잘 읽게 레이어를 깔끔하게 정리해 주세요”라고 요구할 것인가? 저는 그건 순서가 틀렸다고 봤습니다. 도구가 사람의 작업 방식에 맞춰야지, 사람이 도구에 맞춰 없던 일을 더 하게 만들면 안 되니까요.

그래서 SpecSaver 2는 읽는 방식을 바꿨습니다. 레이어 트리 대신, 다 그려진 화면을 이미지 자체로 인식할 수 있게 했습니다. 사람이 화면을 눈으로 훑으며, 이건 로그인 버튼, 저건 체크 박스… 이렇게 인식하듯이요. 이렇게 하니 레이어가 정리돼 있든 엉망이든 상관없이, 시각적으로 묶인 영역을 사람과 비슷하게 인식했습니다. 화면을 이미지로 이해하는 멀티모달(비전) 모델이 쓸 만해지면서 가능해진 전환입니다. 물론 더 비싸고 느리지만요.

AI가 펼쳐놓고, 사람이 완성합니다

아주 흔한 화면 하나를 예로 들어 보겠습니다. 아이디 입력창, 비밀번호 입력창, 자동 로그인 체크박스, 로그인 버튼, 비밀번호 찾기, 회원가입 링크가 있는 평범한 로그인 화면입니다. 이 화면을 넘겼을 때 SpecSaver가 하는 일을 네 단계로 나눠 보겠습니다.

1단계. SpecSaver가 화면을 통째로 봅니다

SpecSaver는 선택한 프레임 전체를 한 번에 보고 구조를 분석합니다. 그리고 화면 위의 요소들을 찾아 정해진 규칙대로 번호를 매기고, 유형을 판단합니다.

SpecSaver가 로그인 화면을 분석한 뒤 번호 배지를 생성한 모습

이렇게 정리된 번호는 버튼 한 번만 클릭하면 캔버스에 배지로 얹힙니다. 디스크립션을 쓰기 위해 손으로 하나하나 번호 배지를 찍어 본 분이라면, 이것만으로도 절반은 왔다는 느낌이 들 겁니다.

2단계. 사람이 한 번 봅니다

여기서 바로 디스크립션으로 넘어가지 않습니다. AI가 뽑은 구조를 사람이 먼저 검토합니다.

SpecSaver의 분석 항목 편집 모드

번호 순서가 마음에 안 들면 바꿉니다. 로그인 버튼을 자동 로그인 체크박스보다 먼저 설명하고 싶다면 리스트를 끌어 순서를 조정하면 됩니다. 이름을 바꾸거나 유형을 고칠 수 있습니다. 필요 없는 항목은 지웁니다.

AI가 한 번에 많이 뽑되, 최종 구조는 사람이 확정합니다.

3단계. 맥락을 넣고 초안을 생성합니다

구조가 확정되면 SpecSaver가 수초 내에 상세한 디스크립션을 생성해 냅니다. 생성 전에 미리 두 가지를 함께 넣어두면 디스크립션의 결과를 조절할 수 있습니다.

SpecSaver에서 화면 밖 맥락을 주입하는 두 가지 경로

하나는 배경 자료입니다. 프로젝트 전체의 골격이 되는 사업기획서, 기능정의서 같은 정책 문서를 첨부해 두면, “어떻게 동작하는가”의 근거로 삼습니다.

다른 하나는 해당 화면에 특정된 컨텍스트입니다. “로그인 실패 시 5회까지만 시도할 수 있다” 같은, 화면에는 안 보이지만 반드시 들어가야 할 정책을 미리 적어두면 초안이 그 내용을 반영합니다. 화면으로 “무엇이 어디 있는가”를 보고, 입력된 컨텍스트와 문서로는 “어떻게 동작하는가”를 읽는 셈입니다.

그렇게 나온 초안은 대략 이런 모습입니다.

SpecSaver에서 생성된 디스크립션

4단계. 사람이 또 한 번 봅니다

마지막은 다시 사람입니다. 디스크립션의 내용 편집 모드로 진입해서 [확인 필요]를 채우고, 어색하거나 보충이 필요한 문장을 다듬습니다. 편집 모드에서는 화면 설계할 때 자주 쓰는 ‘TBD, 참조 페이지’와 같은 입력을 도와주는 칩(Chip)이 제공되고, 가독성을 위한 문장 들여 쓰기 같은 디테일도 지원합니다.

정리하면 이렇습니다. AI가 화면을 보고 → 사람이 구조를 다듬고 → AI가 초안을 쓰고 → 사람이 내용을 완성합니다. AI 한 번, 사람 한 번. 이 리듬이 SpecSaver의 핵심입니다.

피그마 캔버스에 생성된 디스크립션 표 (화면 우측)

디스크립션은 표 형태와 리스트 형태 중에서 고를 수 있도록 했습니다. 팀이나 고객사가 쓰는 규격서 양식에 맞추기 위해서입니다.

조금 더 안을 들여다보면

이 네 단계는, 뜯어보면 두 번의 AI 호출로 이뤄집니다. 화면을 보고 구조를 뽑는 분석 호출, 그리고 확정된 구조에 맥락을 얹어 문장을 만드는 생성 호출입니다. 그 사이에 사람의 검토가 끼어 있는 구조죠.

두 호출은 모두 중간 서버를 한 번 거쳐 나갑니다. 이유는 둘입니다. 하나는 팀의 화면 설계서 작성 가이드와 프롬프트를 클라이언트에 노출하지 않고 서버 뒤에 숨기기 위해서고, 다른 하나는 모델 교체·재시도 같은 통제를 한곳에서 하기 위해서입니다. 작은 디테일 하나 더 붙이면, 작업마다 모델이 ‘생각하는 깊이’를 다르게 줬습니다. 구조를 빠르게 훑는 분석에는 얕게, 문장을 짓는 생성에는 조금 더 깊게. 필요 이상으로 뜸 들이지 않도록요.

실무자는 작업 도중에 멈추면 안 됩니다

여기엔 눈에 잘 안 띄는 고민이 하나 더 있습니다. AI를 부르는 도구는 AI 서버 사정에 휘둘립니다. 요즘처럼 다들 AI를 쓰는 시기엔 서버가 몰려서(과부하) 응답이 느려지거나 아예 실패하는 일이 생깁니다. 그런데 생성 버튼을 눌렀는데 그대로 멈춰버리는 경험은 실무자의 흐름을 가장 확실하게 끊는 일입니다.

그래서 안전장치를 겹겹이 넣었습니다. 요청이 실패하면 1초, 2초, 4초로 간격을 늘려가며 몇 번 다시 시도하고(지수 백오프), 그래도 안 되면 메인으로 쓰는 최신 모델 대신 더 가벼운 모델로 자동으로 갈아탑니다. 생성처럼 오래 걸리는 작업은 결과를 한꺼번에 기다리게 하지 않고 만들어지는 대로 흘려보내되(스트리밍), 첫 응답이 90초, 중간 응답이 20초를 넘게 끊기면 하염없이 매달려 있지 않도록 스스로 중단하며 상태를 안내합니다.

여기서도 한 가지를 지킵니다. 더 가벼운 모델로 자동 전환 됐을 때 대체 모델로 넘어갔다는 사실을 숨기지 않습니다. 품질이 평소와 다를 수 있으니 “지금은 대체 모델로 만든 결과”라고 배너로 알려줍니다. 뒤에서 설명할 [확인 필요]와 같은 태도입니다. 불확실한 것도, 평소와 다른 상태도 사람에게 숨기지 않고 드러내는 것입니다.

화면은 저장되지 않습니다

AI 도구를 쓸 때 가장 먼저 드는 걱정이 이겁니다. “내가 넘긴 화면과 정보가 어딘가에 저장되거나, 모델 학습에 쓰이는 건 아닐까?” 실무에서 다루는 화면은 대개 미공개 서비스이고 보안이라 민감한 부분이니까요.

먼저, SpecSaver는 화면 이미지를 서버에 저장하지 않습니다. 화면은 분석에 필요한 그 순간에만 중간 서버(프록시)를 거쳐 AI로 전달되고, 응답이 오면 그 자리에서 사라집니다. 실제로 서버에는 이미지를 담아둘 저장소 자체가 붙어 있지 않고, 이미지가 로그로 기록되는 경로도 없습니다. 화면이 향하는 곳은 오직 하나, Google의 Gemini 뿐입니다. 다른 어떤 제3의 서버로도 보내지 않습니다.

그다음이 중요한데, AI 호출은 사용자가 직접 넣은 API Key로 이뤄집니다. SpecSaver는 각 사용자가 자기 Google Gemini Key를 설정에 입력해 쓰는 구조입니다(BYOK, Bring Your Own Key). 즉 화면은 SpecSaver의 어떤 공용 계정이 아니라, 개인 소유의 Key를 통해 Google의 Gemini로 직접 갑니다.

그러면 “학습에 쓰이느냐”는 결국 사용자가 넣은 Key의 등급에 달립니다. Google의 유료 Gemini API는 프롬프트·응답을 제품 개선(모델 학습 포함)에 사용하지 않는다고 약관에 명시합니다. 반면 무료 등급은 제출한 내용이 제품·서비스 개선에 사용될 수 있고, 사람 검토자가 볼 수도 있습니다. (유럽경제지역·스위스·영국 사용자는 무료 등급에도 유료 약관이 적용됩니다.)

따라서 민감한 자료를 다룬다면, Gemini Key를 유료 등급으로 쓰길 권합니다. 학습 사용 여부의 최종 결정은 그 Key가 쥐고 있기 때문입니다. 정책은 바뀔 수 있으니, 민감한 작업 전에는 Google의 최신 Gemini API 약관을 한 번 확인하시는 편이 안전합니다.

100% 완성된 디스크립션을 제공하지 않는 이유

여기서 이상하게 느끼는 분이 계실 겁니다. 기왕 AI를 붙일 거면, 화면을 넣으면 완성된 설계서가 뚝 나오게 하면 안 되나요? 버튼 한 번에 규격서 완성. 데모로 보여주면 제일 그럴듯한 그림입니다.

만들면서 저도 그런 유혹을 받았습니다. 그런데 조금만 따져보니 그건 안 되는 방향이었습니다.

완성본을 받으면, 사람은 그냥 받아들입니다

연구자들이 반복해서 관찰한 현상이 있습니다. 사람과 AI가 함께 일하는 팀이 종종 AI 혼자 할 때보다 못한 결과를 낸다는 것입니다. 사람이 자기 판단을 AI 결과에 더하는 게 아니라, AI가 준 걸 그냥 받아들이기 때문입니다. 틀린 답까지 같이 통과시키는 것이죠.

그럼 차라리 사람을 빼고 AI가 완성본을 한 번에 뽑는 게 낫지 않냐고요? 그 결론이 성립하려면 전제가 하나 필요합니다. AI가 절대 안 틀려야 합니다. 그래야 사람이 안 봐도 되니까요. 그런데 디스크립션은 정확히 그 전제가 성립하지 않는 일입니다. 뒤에서 다시 이야기하겠지만, “이 버튼을 누르면 무슨 일이 벌어지는가”는 화면에 없는 정보라 AI가 구조적으로 틀릴 수밖에 없습니다. 틀릴 수밖에 없는 일에서 완성본을 한 번에 뱉으면, 그 틀린 부분을 사람이 그대로 받아들일 위험만 커집니다.

그러니 문제는 사람이 낀 것이 아니라 낀 사람이 판단을 안 한 것입니다. 하버드의 부친차(Buçinca) 연구진이 내놓은 처방도 사람을 빼라가 아니라 그 반대였습니다. 사람이 곧바로 수용하지 못하도록, 중간에 스스로 판단하게 만드는 장치. 이른바 인지적 강제 장치(cognitive forcing function) 를 끼워 넣으면, 틀린 AI 제안에 휩쓸리는 일이 줄어든다는 것입니다. 완성본을 툭 던지는 도구는 정확히 그 반대로 작동합니다. 받아들이기 가장 쉬운 형태로 결과를 내밀어, 사람이 판단을 건너뛰게 만들기 때문입니다.

SpecSaver’s human-in-the-loop workflow

SpecSaver가 ‘AI 한 번, 사람 한 번’의 리듬을 고집하고, 분석과 생성 사이에 사람의 검토 단계를 일부러 끼워 넣은 건 이 때문입니다. 검토를 권하는 게 아니라 구조적으로 거치게 만든 것입니다. 완성본을 받아 대충 넘기다 보면, 남는 건 빠르게 만들었지만 뭐가 맞고 뭐가 틀렸는지 모르는 설계서일 뿐이니까요.

화면은 무엇은 알아도 어떻게는 모릅니다

이유는 하나 더 있습니다. 화면 이미지가 알려주는 건 딱 하나입니다. 무엇이 어디에 있는가. 버튼이 여기 있고, 입력창이 저기 있다. 여기까지는 AI가 꽤 잘 봅니다.

하지만 디스크립션의 진짜 알맹이는 그게 아닙니다. 이걸 누르면 무슨 일이 벌어지는가, 어떤 조건에서 막히는가, 왜 이렇게 동작하는가. 이건 화면 어디에도 안 적혀 있습니다. 기획자의 머릿속과 기획서에 있습니다.

앞의 로그인 버튼을 다시 봅시다. “버튼을 누르면 로그인이 된다”까지는 화면만 봐도 짐작이 갑니다. 그런데 “실패하면 어떻게 되는가”는 화면에 없습니다. 5회 실패하면 잠기는지, 그냥 에러 메시지만 뜨는지는 정책의 영역입니다.

그럴듯한 거짓말이 제일 위험합니다

AI가 이 빈칸을 그럴듯하게 채우면 어떻게 될까요. 그럴듯한 거짓말이 됩니다. 화면만 보고 “이 버튼을 누르면 홈으로 이동합니다”라고 자신 있게 써놨는데, 실제로는 이전 화면으로 돌아가는 버튼일 수 있습니다. 검토하는 사람이 그 문장을 믿어버리면, 틀린 설계서가 그대로 나갑니다. 매끄럽게 쓰인 문장일수록 더 잘 통과되겠지요.

그런데 스탠퍼드 연구진(Vasconcelos 외, 2023)은 반대 방향의 실마리도 보여줍니다. AI가 무엇을 근거로 그렇게 판단했는지를 드러내면, 사람이 맹목적으로 따르는 정도가 줄어든다는 것입니다. 핵심은 판단의 근거와 불확실성을 감추지 않고 보여주는 데 있습니다.

그래서 SpecSaver는 화면만으로 단정할 수 없는 자리는 확신하는 척 채우지 않고, [확인 필요]로 남깁니다. 채워야 할 빈칸이 어디인지를 사람에게 짚어주는 것입니다. 비슷한 발상은 코드 자동완성 도구 연구에서도 나옵니다. 같은 스탠퍼드 그룹이 참여한 2024년 연구(ACM TOCHI)는, AI가 짜준 코드에서 확신이 낮은 부분을 골라 인라인으로 표시해 주는 방식을 실험했습니다. 개발자들은 이런 표시가 뭉뚱그리지 않고, 짚어주되, 과하지 않을 때 가장 쓸모 있다고 평가했습니다. [확인 필요]가 노리는 것도 똑같습니다. 문장을 매끄럽게 다 채워 넘기는 대신 여기가 불확실하다를 콕 집어 사람 앞에 놓아두는 것입니다.

금지해야 할 것은 추론 자체가 아니라 추론을 숨기는 것입니다. AI가 합리적으로 추측하는 건 괜찮습니다. 다만 다른 그럴듯한 답이 열려 있다면, 확신한 얼굴로 하나만 써 놓지 말고 “여기는 확인이 필요하다”라고 함께 적어두는 것입니다. 판단의 기준을 “내가 확신하는가”(주관)에서 “다른 그럴듯한 답이 존재하는가”(객관)로 바꾼 셈입니다.

결국 이 모든 결정은 한 가지 고민으로 이어집니다. 자동화를 너무 밀어붙이면 사람이 판단을 놓고, 반대로 사람이 다 붙들고 있으면 도구가 아무것도 덜어주지 못합니다. SpecSaver는 이 자동화와 통제감 사이의 균형을 맞추려고 했습니다. 지겨운 절반은 도구에 맡기되, 판단이 필요한 자리에서는 사람이 반드시 개입하게. 그 경계를 어디에 그을지가, 사실 이 도구를 만드는 내내 가장 오래 붙든 질문이었습니다.

진짜 오래 걸리는 일, 팔로업

앞에서 잠깐 말했지만, 규격서 작업에서 가장 시간을 잡아먹는 건 초벌이 아니라 이후의 팔로업 과정입니다. 한 번 쓰고 끝이 아니라, 몇 주에서 몇 달에 걸쳐 계속 고치고 고도화하는 일입니다.

이 팔로업에도 나름의 규칙이 있습니다. 수정한 부분은 빨간 글씨로 표시하고, 삭제한 부분은 취소선을 긋고, 수정한 페이지에는 변경 이력을 남깁니다. 손으로 하면 빠뜨리기 쉽고, 빠뜨리면 “이번에 뭐가 바뀐 거냐”는 질문이 돌아옵니다.

SpecSaver의 디스크립션 수정 검토 상세 화면

SpecSaver는 이 팔로업을 돕습니다. 업데이트해야 할 내용을 입력하면 선택한 기존 디스크립션 표 내에서 수정이 필요한 부분을 모두 찾아낸 뒤에 어떻게 수정이 되는지 미리 보여줍니다. 원본과 나란히 비교해서 보여주고, 확정하면 실제 디스크립션에 반영합니다. 기존 디스크립션에서 바뀐 부분을 빨간색으로 하이라이트하고, 삭제하는 정의에 취소선을 그어 기존 디스크립션 표에 반영합니다. 그리고 가장 중요한 것. 이전 버전에서 표시했던 바뀐 부분의 하이라이트는 보통 상태로 되돌려 놓습니다. 그래야만 이번에 고친 최신 내용만 하이라이트 할 수 있으니까요.

지금 그리고 앞으로의 계획

SpecSaver는 현재 사내에서 실무에 적용해 보는 단계입니다. 우리 팀의 실제 프로젝트에 매일 테스트하면서, 어떤 화면에서 잘 되고 어떤 상황에서 부족한지를 보고 있습니다. 도구를 팀 밖에 내놓기 전에, 먼저 충분히 써보려고 합니다.

앞으로 다듬어 갈 방향은 대략 이렇습니다. 지금 가장 공들이는 건 팔로업 고도화입니다. 버전 태그와 변경 이력을 캔버스에 남기고, 그 이력을 따로 뽑아낼 수 있게 만드는 일입니다. 그 밖에 규격서 표 양식을 더 갖추고, 여러 화면을 한 번에 처리하는 배치 작업, 도구 자체가 자기 초안의 누락·[확인 필요]를 점검하는 '자가 검증' 같은 것들을 로드맵에 두고 있습니다. 외국어 지원, Gemini 외 클로드, 챗GPT 같은 다양한 모델 선택도 고려 중이고요.

한 가지 방향은 특히 눈여겨보고 있습니다. SpecSaver는 표준화된 규칙에 맞춰 커스터마이즈 할 수 있습니다. 어떤 어체로 쓸지, 어떤 항목을 어떤 위계로 담을지, 무엇을 [확인 필요]로 남길지와 같은 규칙을 바꾸면 같은 화면에서도 전혀 다른 결의 디스크립션이 나옵니다. 여기에 플러그인 설정으로 조절할 수 있는 것들(표 양식, 번호 체계, 유형 분류 등)까지 더하면, 결국 각 기업마다 고유한 UX 규격서 표준에 맞춰 도구를 통째로 맞춤할 수 있다는 뜻이 됩니다.

화면설계서 양식은 회사마다, 심지어 프로젝트마다 다릅니다. 기존 규격서 스타일을 가이드로 녹이고 설정을 그 팀에 맞게 잡아주면, 범용 도구가 아니라 회사의 화면설계서를 쓰는 도구가 됩니다. 아직 구체적인 제공 형태를 정한 단계는 아니지만, SpecSaver가 팀 밖으로 나간다면 이런 커스터마이즈가 하나의 축이 될 수 있다고 보고 있습니다.

마치며

만들면서 계속 스스로에게 물었던 건 “이것이 기획자의 역할을 얼마나 대체하나?”였습니다. 답은 아니오입니다. 그리고 그래서는 안 된다고 생각합니다.

디스크립션 작성에는 두 종류의 일이 섞여 있습니다. 하나는 번호를 매기고 요소를 나열하는, 판단이 거의 없는 노동입니다. 다른 하나는 이 화면이 이렇게 동작해야 하는 이유를 정하고, 이 페이지에서 어디까지 설명하고 다음 페이지로 넘겨야 읽는 사람이 보기 더 좋을지에 대한 판단 그 자체인 일입니다. 전자는 AI가 덜어줄 수 있습니다. 후자는 여전히 사람 몫이고, 앞으로도 그럴 것입니다.

돌아보면 이 도구의 크고 작은 결정들은 대부분 한 방향을 봅니다. 레이어를 정리하라고 요구하는 대신 화면을 눈으로 읽고, 번호 배지를 대신 찍고, 서버가 몰려도 작업이 멈추지 않게 하고, 몇 달짜리 팔로업을 거들고, 확신할 수 없는 자리는 숨기지 않고 드러내는 것. 전부 기획자의 작업 흐름을 끊지 않으려는 선택이었습니다.

이건 저희 팀에서도 계속 나오는 이야기입니다. 같은 pxd의 동료가 쓴 글들도, 결국 ‘AI를 잘 부리는 기술’보다 ‘자기 일에 대한 사람의 판단력’이 진짜 변수라는 결론에 닿습니다. AI 앞에서 “이건 괜찮고 이건 아니다”를 가르는 기준은 프롬프트를 잘 쓰는 법이 아니라 사용자를 관찰하고 맥락을 이해해 온 경험에서 나옵니다.

SpecSaver가 하는 일도 딱 거기까지입니다. 그 판단력을 대신하려는 게 아니라, 판단력이 발휘될 자리를 비워두는 것. 지겨운 절반을 덜어주고, 아낀 시간을 단순 노동이 아닌 진짜 고민에 쓰게 하는 것.

그거면 충분하다고 생각합니다. 적어도 지금은요.

써보고 싶으시다면

앞서 말씀드린 대로 SpecSaver는 지금 사내에서 다듬는 중이라, 아직 외부에서 바로 쓰실 수는 없습니다. 그럼에도 “우리 팀 작업에도 이런 게 필요하다” 싶거나, 제품이 궁금하시다면 편하게 문의를 남겨 주세요.

프로덕트 문의: xdax@pxd.co.kr

참고 자료

연구

Buçinca, Z., Malaya, M. B., & Gajos, K. Z. (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1). Harvard University. https://doi.org/10.1145/3449287
Vasconcelos, H., Jörke, M., Grunde-McLaughlin, M., Gerstenberg, T., Bernstein, M. S., & Krishna, R. (2023). Explanations Can Reduce Overreliance on AI Systems During Decision-Making. Proceedings of the ACM on Human-Computer Interaction, 7(CSCW1). Stanford University. https://doi.org/10.1145/3579605
Vasconcelos, H., Bansal, G., Fourney, A., Liao, Q. V., & Vaughan, J. W. (2024). Generation Probabilities Are Not Enough: Uncertainty Highlighting in AI Code Completions. ACM Transactions on Computer-Human Interaction. https://doi.org/10.1145/3702320

함께 보면 좋은 pxd 글

이예진 (2026). 「AI와 협업하는 최선의 워크플로우 찾기」. pxd story. https://story.pxd.co.kr/1914

검색엔진과 AI가 우리 페이지를 더 정확히 이해하도록 돕는 방법

Seulbi Lee — Mon, 24 Aug 2026 07:50:47 +0900

프론트엔드 개발자가 알아야 할 SEO/GEO 네 번째 이야기, 구조화 데이터 실전 가이드: JSON-LD로 검색엔진과 AI에게 맥락 전달하기

들어가며

이번 편을 준비하면서 꽤 의미 있는 문서가 하나 나왔어요. 2026년 5월 15일, Google Search Central에서 "Optimizing your website for generative AI features on Google Search"라는 공식 가이드를 발행했어요.

이 문서에서 Google이 명확히 한 핵심 메시지가 있어요.

"AEO"나 "GEO"라는 용어가 온라인에서 사용되고 있지만, Google Search의 관점에서 AI 검색 최적화는 검색 경험 최적화이며, 따라서 여전히 SEO다.

이건 이 시리즈에서 계속 얘기해온 방향과 맞닿아 있어요. SEO가 죽고 GEO가 대체한다는 게 아니라, GEO는 SEO의 확장이라는 거예요. SEO 없이는 GEO도 없어요. Google의 AI 기능(AI Overviews, AI Mode)은 기존 검색 인덱스에서 페이지를 가져와서(RAG) 응답을 생성하거든요. 인덱싱되지 않으면 AI 노출도 없어요.

그래서 이번 편에서 다루는 구조화 데이터도 같은 맥락에서 봐야 해요. 구조화 데이터는 AI 검색에 필수가 아니에요 — Google도 이번 가이드에서 그렇게 말했어요. 하지만 SEO 전체 전략의 일부로서 리치 결과를 얻고, 검색엔진과 AI가 페이지를 더 정확히 이해하도록 돕는 데는 확실히 가치가 있어요.

JSON-LD란 무엇인가

구조화 데이터의 세 가지 형식

구조화 데이터를 마크업하는 형식은 세 가지가 있어요 — JSON-LD, Microdata, RDFa. 이 중에서 Google이 공식적으로 권장하는 형식은 JSON-LD예요.

JSON-LD가 권장되는 이유는 명확해요. HTML 구조와 완전히 분리된 <script> 태그 안에 넣기 때문에, 기존 HTML을 건드리지 않고도 구조화 데이터를 추가할 수 있어요. Microdata나 RDFa는 HTML 속성에 직접 마크업을 섞어야 해서 유지보수가 어렵고 오류가 생기기 쉽거든요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO 가이드",
  "author": { "@type": "Person", "name": "GEONIQ" }
}
</script>

구조화 데이터의 역할을 정확히 이해하기

구조화 데이터에 대해 먼저 정확히 짚고 갈 게 있어요.

검색 순위를 직접 올려주지 않아요. Google이 여러 차례 확인한 사실이에요. 구조화 데이터의 역할은 검색 결과에 리치 결과(별점, 가격, 이미지, 빵부스러기 등)를 표시할 수 있게 해주는 거예요. 리치 결과가 표시되면 클릭률(CTR)이 올라가고, 그게 간접적으로 SEO에 도움이 되는 구조예요. Nestlé의 사례에 따르면, 리치 결과로 표시된 페이지가 일반 결과 대비 82% 높은 클릭률을 기록했어요(Google Search Central 사례 연구).

AI 검색에 필수는 아니에요. Google의 최신 가이드에서 명시한 내용이에요 — "Structured data isn't required for generative AI search... However, it's a good idea to continue using it as part of your overall SEO strategy." 구조화 데이터를 넣었다고 AI Overviews에 더 잘 나오는 건 아니지만, SEO 전반의 퀄리티를 높이는 데 도움이 되고, 그게 결국 AI 노출의 기반이 되는 거예요.

그렇다고 안 해도 되는 건 아니에요. 구조화 데이터는 검색엔진에게 "이 페이지에 뭐가 있는지"를 가장 명확하게 전달하는 방법이에요. 리치 결과를 통한 CTR 향상은 여전히 강력한 SEO 수단이고, 잘 구조화된 데이터는 AI가 페이지의 사실 관계를 파악하는 데도 참고할 수 있어요.

정리하면: 구조화 데이터는 SEO의 도구이고, 좋은 SEO가 곧 AI 검색의 기반이에요. "AI를 위한 특별한 마크업"이 아니라, "검색 전체를 위한 기본기"로 접근하는 게 맞아요.

Article — 블로그와 뉴스 페이지의 기본

블로그 글이나 뉴스 기사를 작성한다면, Article 스키마가 가장 기본이에요. Google은 이 스키마를 통해 검색 결과에 큰 이미지, 헤드라인, 작성자 정보를 표시할 수 있어요.

필수 속성과 권장 속성

Google이 요구하는 필수 속성은 headline, datePublished, author예요. image는 필수는 아니지만, 리치 결과에 큰 이미지로 표시되려면 포함하는 게 좋아요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "프론트엔드 개발자를 위한 SEO 가이드",
  "image": "https://example.com/images/seo-guide.jpg",
  "datePublished": "2026-05-01",
  "dateModified": "2026-05-15",
  "author": {
    "@type": "Person",
    "name": "GEONIQ",
    "url": "https://geoniq.ai"
  },
  "publisher": {
    "@type": "Organization",
    "name": "pxd XE Group",
    "logo": {
      "@type": "ImageObject",
      "url": "https://tech.pxd.co.kr/_next/image?url=%2Fimages%2Fxegroup_tech_logo_light.png&w=1080&q=50"
    }
  },
  "description": "프론트엔드 개발자가 알아야 할 SEO와 GEO의 핵심 요소를 정리합니다."
}
</script>

실무 포인트

headline은 110자 이내 — Google 리치 결과 표시 제한 때문에 110자를 넘으면 잘릴 수 있어요.

dateModified는 반드시 넣기 — 3편에서 다뤘던 콘텐츠 최신성과 직접 연결되는 부분이에요.

author.url을 포함하기 — Google의 E-E-A-T(경험, 전문성, 권위성, 신뢰성) 관점에서, 저자가 누구인지 확인할 수 있는 URL을 포함하는 게 좋아요.

Next.js에서 구현하기

Next.js App Router 기반이라면 페이지 컴포넌트에서 JSON-LD를 직접 삽입할 수 있어요.

// app/posts/[slug]/page.tsx
export default function PostPage({ params }: { params: { slug: string } }) {
  const post = getPost(params.slug);
  
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: post.title,
    image: post.thumbnail,
    datePublished: post.createdAt,
    dateModified: post.updatedAt,
    author: {
      '@type': 'Person',
      name: post.author.name,
      url: post.author.url,
    },
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article>
        <h1>{post.title}</h1>
        {/* 본문 */}
      </article>
    </>
  );
}

구조화 데이터에 포함된 정보가 실제 페이지에 보이는 내용과 일치해야 해요. 페이지에 없는 정보를 JSON-LD에만 넣으면 Google 가이드라인 위반이에요.

Product — 이커머스와 상품 페이지

상품을 판매하는 페이지라면 Product 스키마가 핵심이에요. 가격, 재고 상태, 별점이 검색 결과에 직접 표시될 수 있어요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "무선 키보드 MK-200",
  "image": "https://example.com/images/mk200.jpg",
  "description": "블루투스 5.0 지원, 충전식 무선 키보드",
  "brand": { "@type": "Brand", "name": "TechBrand" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/mk200",
    "priceCurrency": "KRW",
    "price": "89000",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "127"
  }
}
</script>

offers는 필수 — 가격 정보가 없으면 Product 리치 결과가 표시되지 않아요.

aggregateRating — 별점이 검색 결과에 보이면 CTR이 크게 올라가요. 다만 실제 리뷰 데이터를 기반으로 해야 해요.

참고로 Google의 AI 가이드에서는 이커머스 사이트의 경우 구조화 데이터와 함께 Merchant Center 피드와 Google Business Profile도 정비하라고 권장하고 있어요. AI 응답에 상품 정보가 포함될 수 있는데, 이런 피드 데이터가 그 원천이 되거든요.

BreadcrumbList — 사이트 계층 구조 전달

BreadcrumbList는 페이지가 사이트 구조 안에서 어디에 위치하는지를 알려주는 스키마예요. 검색 결과에서 URL 대신 "홈 > 카테고리 > 하위 카테고리" 형태의 빵부스러기 경로가 표시돼요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "홈", "item": "https://example.com" },
    { "@type": "ListItem", "position": 2, "name": "블로그", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "SEO 가이드" }
  ]
}
</script>

구조가 명확한 사이트라는 신뢰감을 주고, 사용자가 검색 결과에서 페이지의 맥락을 바로 파악할 수 있어요.

HowTo — 단계별 가이드 페이지

단계별 절차를 설명하는 콘텐츠라면 HowTo 스키마를 고려할 수 있어요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Next.js 프로젝트에 JSON-LD 추가하는 방법",
  "step": [
    { "@type": "HowToStep", "name": "JSON-LD 객체 생성", "text": "페이지 컴포넌트에서 구조화 데이터 객체를 정의합니다." },
    { "@type": "HowToStep", "name": "script 태그에 삽입", "text": "type='application/ld+json'으로 script 태그를 추가합니다." },
    { "@type": "HowToStep", "name": "Rich Results Test로 검증", "text": "Google의 Rich Results Test에서 정상 인식 여부를 확인합니다." }
  ]
}
</script>

알아둬야 할 제한 사항 — 2023년 8월 Google이 HowTo 리치 결과를 모바일에서 제거했고, 이후 데스크톱에서도 제거되어 현재는 검색 결과에 표시되지 않아요. 다만 FAQPage와 마찬가지로, 스키마 자체는 검색엔진과 AI가 콘텐츠 구조를 이해하는 데 참고할 수 있어요.

Organization과 WebSite — 사이트 전체를 대표하는 스키마

페이지 단위가 아니라 사이트 전체에 대한 정보를 전달하는 스키마도 있어요. 홈페이지에 한 번만 넣으면 돼요.

<!-- Organization -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "pxd XE Group",
  "url": "https://tech.pxd.co.kr",
  "logo": "https://tech.pxd.co.kr/logo.png",
  "sameAs": ["https://github.com/pxd-xe-group"]
}
</script>

<!-- WebSite (사이트링크 검색창) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://example.com",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

FAQPage — 리치 결과는 끝났지만, AI 인용 신호로는 오히려 올라가는 중

3편에서 FAQPage 스키마를 다루면서 "리치 결과는 사실상 끝났다"고 했었는데, 2026년 5월 7일부로 공식 종료됐어요. 6월에는 Rich Results Test에서 FAQ 지원이 제거되고, 8월에는 Search Console API에서도 삭제될 예정이에요.

타임라인을 정리하면 이래요.

2019년: FAQ Schema 출시
2023년 8월: 정부·의료 등 고신뢰 사이트만 남기고 제거
2026년 5월 7일: SERP에서 리치 결과 완전 종료
2026년 6월: Rich Results Test 도구에서 FAQ 검증 제거 예정
2026년 8월: Search Console 리포트 + API 지원 종료 예정

그런데 중요한 건, Schema 자체는 죽지 않았다는 거예요.

FAQPage 스키마 마크업은 여전히 유효해요. 시각적 리치 결과는 사라졌지만, AI 검색 서비스들이 Q&A를 추출할 때 FAQPage 구조화 데이터를 파싱하고 있다는 분석이 나오고 있어요. ALM Corp의 분석에 따르면, FAQPage 스키마가 있는 페이지는 AI가 Q&A를 추출할 때 유리하다는 분석이 나오고 있어요.

이건 이번 시리즈의 메시지와도 정확히 맞닿아 있어요. SEO 관점에서만 보면 "리치 결과 없으니 빼도 된다"가 되지만, GEO 관점까지 함께 보면 "AI 인용 신호로서의 가치가 오히려 올라가고 있으니 유지하는 게 맞다"가 돼요. SEO와 GEO를 따로 보면 놓치고, 같이 봐야 판단이 정확해지는 대표적인 사례예요.

실무 권장: 기존에 FAQPage 스키마를 넣어둔 사이트는 그대로 유지하세요. 새로 구현할 때도 Q&A 구조의 콘텐츠가 있다면 FAQPage 스키마를 넣는 걸 권장해요. 리치 결과를 기대하고 넣는 게 아니라, 페이지 이해와 AI 인용을 돕는 신호로 활용하는 거예요.

검증 도구

구조화 데이터를 넣었으면 배포 전에 반드시 검증해야 해요.

Google Rich Results Test — 리치 결과 적격 여부를 확인하는 가장 기본적인 도구예요.

Schema.org Validator — JSON-LD 문법이 Schema.org 표준에 맞는지 확인할 수 있어요.

Google Search Console — 배포 후 실제 리치 결과 표시 여부와 오류를 모니터링할 수 있어요.

흔한 오류들

페이지에 없는 정보를 마크업한 경우 — JSON-LD에 가격이 89,000원이라고 했는데 페이지에 가격이 안 보이면 가이드라인 위반이에요.

필수 속성 누락 — Article에 author가 없거나, Product에 offers가 없으면 리치 결과가 표시되지 않아요. 부분 구현은 효과가 없어요.

JSON 문법 오류 — 쉼표 하나 빠지거나, 스마트 따옴표(" ")가 섞이는 것만으로도 전체 JSON-LD가 무시돼요.

정리 — 어떤 스키마를 어디에 넣을지

스키마 타입적용 페이지리치 결과비고

Article	블로그, 뉴스	큰 이미지, 헤드라인, 작성자	headline 110자, dateModified 필수
Product	상품 페이지	가격, 별점, 재고 상태	Merchant Center 피드 병행 권장
BreadcrumbList	전체 페이지	URL 대신 경로 표시	사이트 구조 전달
HowTo	가이드, 튜토리얼	리치 결과 종료	스키마 자체는 AI 이해에 참고 가능
Organization	홈페이지 (1회)	Knowledge Panel	sameAs로 소셜 연결
WebSite	홈페이지 (1회)	사이트링크 검색창	SearchAction 포함
FAQPage	Q&A 콘텐츠 페이지	리치 결과 종료 (2026.05)	AI 인용 신호로 가치 상승 — 마크업 유지 권장

Google이 확인해준 것, 그리고 우리가 챙겨야 할 것

이번 Google 가이드가 나오면서, 시리즈에서 다뤄온 내용들의 위치가 좀 더 명확해졌어요.

Google은 AI 검색 기능이 기존 검색 인덱스를 기반으로 작동한다(RAG)고 공식 확인했어요. 그러면서 "콘텐츠를 AI용으로 별도로 재작성할 필요 없다", "청크 분할이 필요하지 않다"고 못 박았어요.

이건 "GEO를 위해 뭔가 특별한 걸 해야 한다"는 접근이 아니라, "SEO의 기본기를 제대로 하면 AI 검색에서도 자연스럽게 노출된다"는 의미예요.

다만 그렇다고 AI 검색 환경의 변화를 무시해도 된다는 건 아니에요. 사용자가 정보를 찾는 방식이 달라지고 있고, AI가 콘텐츠를 요약하고 인용하는 환경에서 "어떤 구조가 더 잘 이해되는가"를 고민하는 건 여전히 의미 있어요. GEO는 SEO를 대체하는 게 아니라, SEO 위에 쌓이는 확장이에요. SEO가 탄탄하지 않으면 GEO도 작동하지 않아요.

이 시리즈에서 다뤄온 것들 — robots.txt와 sitemap 정비, 명확한 헤딩 구조, 핵심이 앞에 오는 문단, 구조화 데이터 — 은 전부 SEO의 기본기예요. 그리고 Google이 이번에 확인해준 것처럼, 그 기본기가 곧 AI 검색의 기반이에요.

마치며

구조화 데이터는 "AI를 위한 특별한 마크업"이 아니에요. SEO 전략의 일부로서 리치 결과를 얻고, 검색엔진이 페이지를 더 정확히 이해하도록 돕는 도구예요. 그리고 좋은 SEO가 곧 AI 검색의 기반이라는 게 Google의 공식 입장이에요.

프론트엔드 개발자라면, Article과 BreadcrumbList부터 시작하는 걸 추천해요. 블로그나 콘텐츠 사이트에서 가장 보편적으로 쓰이고, 구현 난이도도 낮은 편이에요. 배포 전에 Rich Results Test로 검증하는 습관을 들이면 대부분의 실수는 잡을 수 있어요.

다음 편에서는 프론트엔드 개발자가 가장 익숙한 영역인 웹 성능 이야기를 해볼게요. Core Web Vitals가 검색 노출에 실제로 어떤 영향을 미치는지, LCP·INP·CLS를 챙기는 게 SEO/GEO 양쪽 모두에서 왜 중요한지 정리할 예정이에요.

참고 자료

Google Search Central — Optimizing your website for generative AI features on Google Search (2026.05.15) (https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)
Google Search Central — 구조화 데이터 소개 (https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
Google Search Central — 구조화 데이터 일반 가이드라인 (https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
Google Search Central — Article (https://developers.google.com/search/docs/appearance/structured-data/article)
Google Search Central — Product (https://developers.google.com/search/docs/appearance/structured-data/product)
Google Search Central — BreadcrumbList (https://developers.google.com/search/docs/appearance/structured-data/breadcrumb)
Google Search Central — FAQPage deprecation (2026.05.07) (https://developers.google.com/search/docs/appearance/structured-data/faqpage)
Search Engine Land — Google to no longer support FAQ rich results (2026.05.09) (https://searchengineland.com/google-to-no-longer-support-faq-rich-results-476957)
Google Search Central — Changes to HowTo and FAQ rich results (2023.08) (https://developers.google.com/search/blog/2023/08/howto-faq-changes)
Google Rich Results Test (https://search.google.com/test/rich-results)
Schema.org Validator (https://validator.schema.org)

AI 에이전트 시대의 정성 데이터 분석 툴, 어피니티버블

yewon.jang — Thu, 20 Aug 2026 07:50:53 +0900

들어가며

어피니티버블은 정성 데이터를 에이전트 방식으로 분석하는 도구로 진화하고 있습니다. 이 글에서 그 변화가 실제로 어떤 모습인지 공유하고자 합니다.

지난 8월 5일, 어피니티버블 팀은 SMIT AI스타트업학과 유훈식 교수님이 매주 진행하시는 온라인 AX 디자인 세미나(71회)에 참여해 '어피니티버블을 활용한 UX 정성 리서치 데이터 분석하기'를 주제로 강연을 진행했는데요. 이 글은 그중에서도 최근 새롭게 업데이트된 부분, AI 에이전트 시대에 정성 데이터를 분석하는 방법을 정리해 보았습니다. (강연에서 함께 다룬 정성 데이터 시각화 방법은 이전 포스트에서 소개했으니, 궁금하시면 아래 링크를 참고해 주세요.)

이 글에서는 다음과 같은 순서로, AI 에이전트의 방식으로 어피니티버블을 활용하여 정성 데이터를 분석하는 법을 소개해 드리려고 합니다.

에이전트가 사용하는 도구로서의 어피니티버블
API로 에이전트와 더 세분화된 분석 하기
어피니티버블이 제공하는 서비스들

이 글을 읽고 나면, 어피니티버블이 왜 에이전트가 쓰는 도구로 방향을 틀었는지, 그리고 지금 에이전트를 이용해 정성 데이터를 얼마나 깊게 분석할 수 있는지 확인하실 수 있습니다.

1. 에이전트가 사용하는 도구로서의 어피니티버블

어피니티버블이 정식 서비스를 출시한 지 1년이 되어가고 있는데요. 그동안 사용자들의 피드백을 들어보니 공통적으로 나오는 이야기가 있었습니다.

"데이터가 어떤 모습인지 한눈에 파악하는 데는 유용한데, 실제 업무에 쓰려면 더 깊은 분석이 필요해요."

문제는 그 '더 깊은 분석'이 사람마다, 팀마다 다 다르다는 점입니다. 어떤 팀은 시계열로 리뷰 변화를 보고 싶어 했고, 어떤 팀은 메타데이터와 교차 분석을 하고 싶어 했고, 어떤 팀은 전처리부터 다시 하고 싶어 했습니다. 모든 유스케이스를 담은 UI를 만들기엔 많은 논의와 기획이 필요한 상황이었죠.

더불어 이미 많은 분들이 업무에 AI 에이전트를 사용하고 있었습니다. 저희는 이 맥락에서 앞선 상황의 의사 결정에 필요한 시간을 줄여줄 좋은 방법을 떠올릴 수 있었는데요. 새로운 UI를 발명하지 말고, 에이전트가 이미 쓰고 있는 도구를 잘 만들어서 건네주자.

실제로 UI의 흐름은 CLI → GUI → Agent UI로 넘어가는 중입니다. GUI는 사람의 인지 부담을 줄여주지만, 에이전트에게는 오히려 비용입니다. 에이전트에게는 텍스트가 훨씬 빠르고 저렴하기 때문입니다. 그래서 어피니티버블은 API + 시각화 라이브러리를 에이전트가 스킬로 사용할 수 있는 형태로 제공하는 방향으로 피봇을 시도했습니다.

어피니티버블 API

어피니티버블 API 문서 https://api.affinitybubble.com/docs

어피니티버블 API는 에이전트가 잘 읽고 스킬화할 수 있게 작성되어 있습니다. 해당 문서를 에이전트에게 전달한 뒤, 아래와 같은 흐름으로 사용해 볼 수 있습니다.

소스 수집

1. 소스 수집

SNS 게시글, 앱 리뷰, 유튜브 댓글 등을 크롤링 API를 사용하여 가져옵니다. (소스 수집 단계에서는 다른 유료 API를 사용합니다.) (예시에서는 테슬라 FSD 관련 169개의 트윗을 수집.)

분석 결과

2. 분석

어피니티버블 API가 위에서 모은 텍스트를 묶어 세그먼트로 정리합니다. (해당 사례에서는 158개 항목이 배포 일정 지연 61% / 소비자 권리 보호 26% / 제조사 소통 방식 13% 3개 세그먼로 정리되었고, 세그먼트별 긍부정 편향까지 함께 나왔습니다.)

3. 시각화

어피니티버블 API가 보로노이 버블로 결과를 그려줍니다.

추가 분석 및 최종 시각화 산출물

4. 에이전트 내 추가 분석

이후 사용자가 추가 피드백을 주면 에이전트가 그 자리에서 다시 분석하게 됩니다. (같은 사례에서 4개 세그먼트로 재구성 — 기약 없는 대기 36% / 배포 일정 불확실성 31% / 기업 소통 불신 17% / 소비자 권리 투쟁 17%) 나아가 "댓글에 언급된 차량 연식×모델을 막대 그래프로 보여줘" 같은, 어피니티버블이 제공하는 기능 외의 간단한 요청도 에이전트에서 처리할 수 있습니다.

이런 식으로, 서비스가 모든 기능을 제공하는 대신 분석 API + 시각화 라이브러리라는 재료를 제공하고, 에이전트와 사용자가 자유롭게 조합할 수 있는 방향으로 가고 있습니다. API와 시각화 라이브러리는 아래 링크에서 사용할 수 있습니다. (링크를 AI 에이전트에게 전달 후 적용해 달라고 해 보세요!)

API 문서 보기 (사용을 위해 링크 내에서 API 키 발급이 필요합니다.)
시각화 라이브러리 사용하기 (GitHub)

2. API로 에이전트와 더 세분화된 분석 하기

어피니티버블로 전체 지도를 본 다음에는, 더 세밀하게 분석하는 작업이 필요한데요. 이를 위해 저희는 퍼소나와 속성 기반 감성 분석(ABSA) 방법을 채택하고 있습니다.

퍼소나 API로 행동 변수 기반 군집화 하기

어피니티버블이 생성하는 퍼소나는 두 가지 특징이 있습니다.

1. 중간값 없는 4점 척도를 사용

어피니티버블은 행동 변수 채점을 LLM으로 자동화하면서, 중간값이 있는 5점 척도 대신 중간값을 없앤 4점 척도를 사용합니다. 사람이 직접 평가할 때는 애매한 경우 중간값을 주지만, 기계로 채점할 때는 그 중간값을 생략해야 애매한 응답까지 한쪽으로 정리되면서 사용자 유형이 더 뚜렷하고 정확하게 갈렸습니다.

2. 히트맵 테이블로 시각화

기존 퍼소나 도구에서 사용하던 행동 변수 도트 플롯은 사용자를 색으로, 변숫값을 x 위치로 설정합니다. 비슷한 사용자를 찾으려면 색과 위치 두 속성의 조합을 행마다 눈으로 훑어야 하는데, 이런 탐색은 인지 비용이 큽니다. 같은 정보를 변수×사용자 히트맵 테이블로 나타내면 사용자 위치를 열에 고정하고 변숫값만 컬러맵으로 표현하기 때문에, 같은 행에서 색이 비슷한지만 비교하면 됩니다. 색에 대한 판단은 전주의적으로(의식적으로 주의를 기울이지 않아도) 처리되어, 어떤 그룹이 어떤 변수에서 다른지가 한눈에 드러납니다.

퍼소나는 아래와 같은 프로세스로 생성하고 있습니다.

1. 행동 변수 추출
인터뷰 등 원문 데이터에서 후보 행동 변수를 뽑고, 각 변수를 이름 붙이고 척도별 기준을 정의합니다.

2. 행동 변수 맵핑
응답자마다 각 변수에 (4점 척도로) 점수를 매깁니다. 이후 개별 행동 변수를 묶어 더 큰 축으로 정리합니다.

3. 클러스터링
축을 기준으로 응답자를 묶고, 세그먼트별 특징과 니즈, 근거 인용문까지 담은 퍼소나 카드를 만들어줍니다.

퍼소나 카드 결과

이미 쌓여 있는 리뷰나 설문 텍스트만으로도 이 프로세스를 통해 사용자를 이해할 수 있습니다. 퍼소나 도구는 API 형태로 준비 중이니, 관심 있는 분은 biz@affinitybubble.com으로 문의해 주세요.

(*참고: 앱 리뷰, 댓글 등 이미 쌓인 텍스트로 사용자를 이해할 때는 한 가지 유의점이 있습니다. 댓글을 다는 행위 자체에 편향이 있어서, 그 결과가 전체 모집단을 대표한다고 해석하면 안 됩니다. 초기 이해와 가설 발견용으로 쓰는 게 적절해 보입니다.)

속성 기반 감성 분석(ABSA)으로 사용자의 속성과 스탠스 파악하기

행동 변수 기반 군집화가 "사용자를 어떻게 나눌까"에 대한 답이라면, 속성 기반 감성 분석(ABSA)는 "무엇에 대해 어떻게 느끼는가"를 보는 축입니다.

한 문장 안에서도 판단은 여러 개로 쪼개질 수 있습니다. "배송은 좋은데 포장은 나쁘다"라는 리뷰 한 줄에는 배송(속성)에 대한 긍정과, 포장(속성)에 대한 부정이 함께 들어 있습니다. 이렇게 속성, 즉 무엇에 대해 말하는지와, 스탠스, 즉 어떻게 판단하는지를 분리해서 보는 것이 ABSA의 핵심입니다. 속성 체계는 미리 정해둘 수도 있지만, 데이터에서 직접 추출할 수도 있습니다.

이 방법론이 아래 제공 서비스들 중 앱 리뷰 드릴다운 리포트, 상품 리뷰 API, 발화 유형 분석 API의 기반이 됩니다.

pxd 블로그로 자세한 내용 알아보기

앱 리뷰 드릴다운 리포트: 앱 리뷰를 쪼개 의사결정으로 연결하는 법
상품 리뷰 API: 상품 리뷰 AI 요약은 구매 결정을 어떻게 도울 수 있을까
발화 유형 분석 API: 부동산 정책 토론회 게시판의 10가지 유형 목소리

3. 어피니티버블이 제공하는 서비스들

위 세분화 기능을 적용하여, 어피니티버블은 현재 아래와 같은 서비스로 확장하고 있습니다.

앱 리뷰 드릴다운 리포트
경쟁 서비스들의 앱 리뷰를 속성별로 분석해, 사용성 주제별 긍/부정 인용문과 언급량을 비교합니다.
샘플 리포트 확인하기

상품 리뷰 API
상품 리뷰를 속성별(착용감·디자인·사이즈·소재·배송·가격 등)로 요약해, 구매 전 사용자에게 "실제로 어떤지"를 보여줍니다.

발화 유형 분석 API
같은 단어를 사용해도 화자가 어떤 입장에 서 있느냐에 따라 요구가 정반대일 수 있습니다. 글쓴이가 자신의 입장을 밝히지 않아도 글에는 그 위치가 드러납니다. 이 API는 질적 연구에서 하던 코딩 작업을 자동화해, 발화 위치와 요구를 기준으로 유형을 나눠줍니다.

어피니티버블 API 외에는 정식 오픈 전이지만, 문의해 주시면 우선적으로 답변드릴 예정입니다!

‍ 문의하기 (biz@affinitybubble.com)

이외에 제공하고 있는 기존 서비스는 아래 링크를 참고해 주세요.

어피니티버블 사이트 | 엔터프라이즈 분석 | API 문서

마치며

지금까지 AI 에이전트 시대에 어피니티버블을 활용하여 정성 데이터를 분석하는 법을 살펴봤습니다. 정리하면,

어피니티버블은 에이전트가 쓰는 도구로 발전하고 있고,
오버뷰 이후엔 퍼소나 API와 ABSA로 더 깊이 들어갈 수 있으며,
그 결과는 앱 리뷰 드릴다운, 상품 리뷰 API, 발화 유형 분석 API 같은 실제 서비스로 이어지고 있습니다.

새로운 서비스를 배우고 적응해야 하는 장벽을 낮추고, 이미 쓰고 있는 에이전트 워크플로우 안에서 자연스럽게 정성 데이터 분석까지 이어지도록 하는 것이 지금 어피니티버블이 지향하는 AX 전환의 방향입니다.

지금 쓰고 있는 에이전트에게 위 API 문서와 예제를 그대로 던져보세요. 여러분의 데이터가 어떤 모습으로 정리되는지, 직접 확인해 보시길 바랍니다.

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 요약, 키워드 방식으로는 내가 궁금해 하는 리뷰를 찾기 어렵습니다. 요약한 상품의 장점을 보여주는 것에서 내가 중요하게 생각하는 조건을 찾을 수 있는 구조로 리뷰를 제공해 보면 좋겠습니다.