pxd story

AI 크롤러 시대의 접근 제어, 그리고 에이전트가 방문하는 웹

bareum.park — Thu, 22 Oct 2026 17:10:34 +0900

들어가며

드디어 시리즈 마지막 편입니다.

2편에서 검색엔진 크롤러가 사이트를 발견하는 과정을 다루면서, AI 크롤러(GPTBot, OAI-SearchBot 등)의 존재와 robots.txt에서의 허용 여부를 잠깐 언급했었습니다. 그때는 "AI 검색에 노출되고 싶다면 열어두는 게 좋다" 정도로 정리했는데, 이번 편에서는 이 주제를 제대로 다뤄보려고 합니다.

2026년 현재, AI 크롤러 생태계는 꽤 복잡해졌습니다. OpenAI만 해도 봇이 3종류이고, Anthropic도 올해 검색 전용 크롤러를 새로 출시했습니다. 어떤 봇을 막으면 AI 인용이 사라지고, 어떤 봇을 막아도 인용에는 영향이 없습니다. 이 구분을 모르고 "AI 봇 전부 차단" 같은 설정을 하면, 의도치 않게 AI 검색 생태계에서 완전히 사라질 수 있어요.

그리고 이제는 크롤러만의 문제가 아닙니다. AI 에이전트가 사용자를 대신해서 사이트를 방문하고, 상품을 비교하고, 결제까지 하는 시대가 시작됐거든요. 이번 편에서 이 흐름까지 정리하고 시리즈를 마무리하겠습니다.

AI 크롤러의 세 가지 유형 — 이걸 구분해야 전략이 나온다

2026년 기준으로 AI 크롤러는 목적에 따라 세 가지 유형으로 나눌 수 있습니다. 이 구분이 접근 제어 전략의 출발점입니다.

① 학습용 크롤러 (Training Crawlers)

AI 모델의 학습 데이터를 수집하는 봇입니다. 주기적으로 대량 크롤링하고, 수집된 콘텐츠는 모델의 기반 지식이 됩니다.

GPTBot (OpenAI)
ClaudeBot (Anthropic)
Google-Extended (Google — 뒤에서 설명하겠지만 실제 크롤러가 아니라 robots.txt 토큰입니다)
CCBot (Common Crawl)
Meta-ExternalAgent (Meta)

② 검색 인덱싱 크롤러 (Search/Retrieval Crawlers)

AI 검색 서비스가 실시간 답변에 사용할 인덱스를 구축하는 봇입니다. 이 인덱스에 있어야 AI 답변에서 인용될 수 있습니다.

OAI-SearchBot (OpenAI — ChatGPT Search용)
Claude-SearchBot (Anthropic — 2026년 신규 출시)
PerplexityBot (Perplexity)

③ 사용자 요청 페처 (User-Triggered Fetchers)

사용자가 AI에게 질문했을 때, 실시간으로 특정 페이지를 가져오는 봇입니다.

ChatGPT-User (OpenAI)
Claude-User (Anthropic)
Perplexity-User (Perplexity)

왜 이 구분이 중요한가

핵심은 이겁니다. 학습용 크롤러를 차단해도 AI 인용에는 영향이 없습니다. 하지만 검색 인덱싱 크롤러나 사용자 요청 페처를 차단하면 인용이 사라집니다.

예를 들어 GPTBot(학습용)을 차단하면 우리 콘텐츠가 GPT 모델 학습에 사용되지 않지만, ChatGPT Search에서의 인용에는 영향이 없습니다. 반대로 OAI-SearchBot을 차단하면 — OpenAI가 문서에 명시한 대로 — ChatGPT 검색 답변에 우리 사이트가 나타나지 않습니다.

"학습 데이터로는 쓰이기 싫지만 AI 검색에는 노출되고 싶다"는 조합이 가능한 겁니다. 이 구분 없이 일괄 차단하면 원치 않는 결과를 얻게 됩니다.

주요 사업자별 봇 정리 (2026년 7월 기준)

OpenAI — 3종 체제

봇용도차단 시 영향

GPTBot	모델 학습	학습 데이터에서 제외. 인용에는 영향 없음
OAI-SearchBot	ChatGPT Search 인덱싱	ChatGPT 검색 답변에서 제외
ChatGPT-User	사용자 요청 실시간 페치	사용자가 링크를 요청해도 접근 불가

한 가지 주의할 점이 있습니다. OpenAI는 ChatGPT-User가 자동 크롤러와 같은 방식으로 robots.txt의 적용을 받지 않을 수 있다고 명시하고 있습니다. 사용자의 직접 요청에 의한 접근이라 성격이 다르다는 겁니다.

참고로 실제 트래픽 로그 분석들을 보면, 범용 검색 크롤러인 Googlebot을 빼고 나면 OpenAI·Anthropic 계열 봇이 AI 크롤러 트래픽의 상위를 차지합니다. 특히 OpenAI의 봇 3종은 그중에서도 비중이 큰데, 사용자 요청에 실시간으로 반응하는 ChatGPT-User의 활동량이 두드러집니다. ChatGPT 노출이 그만큼 큰 기회라는 의미입니다.

Anthropic — 2026년부터 3종 체제

봇용도차단 시 영향

ClaudeBot	모델 학습	학습 데이터에서 제외
Claude-SearchBot	검색 인덱싱 (2026년 신규)	Claude 검색 답변에서 제외
Claude-User	사용자 요청 실시간 페치	사용자 요청 시 접근 불가

Anthropic이 2026년에 Claude-SearchBot을 별도로 출시하면서, OpenAI와 같은 "학습/검색/사용자" 3종 분리 체제가 됐습니다. Anthropic의 봇들은 robots.txt를 엄격하게 준수하는 것으로 알려져 있습니다.

Perplexity

봇용도

PerplexityBot	검색 인덱싱
Perplexity-User	사용자 요청 페치

Perplexity는 인용 기반 AI 검색이 핵심 서비스라서, 이 봇들을 차단하면 Perplexity 인용에서 완전히 제외됩니다. 다만 Perplexity는 과거 robots.txt를 우회하는 스텔스 크롤링이 문서화된 적이 있어서, 업계에서 논란이 있었던 사업자이기도 합니다.

Google — 조금 특수한 구조

Googlebot — 검색과 AI 기능(AI Overviews, AI Mode)이 하나의 크롤러로 통합되어 있습니다. 즉, AI Overviews에서만 빠지고 일반 검색에는 남는 선택지가 없습니다. Googlebot을 차단하면 검색 자체에서 사라집니다.

Google-Extended — 실제 크롤러가 아니라 robots.txt 토큰입니다. 이걸 Disallow하면 Gemini 모델 학습에서 콘텐츠가 제외되는데, 일반 검색 순위에는 영향이 없습니다. "학습 거부 + 검색 유지"가 가능한 유일하게 깔끔한 레버입니다.

그 외 — Bytespider 문제

ByteDance의 Bytespider는 robots.txt를 제대로 지키지 않는 것으로 여러 차례 보고된 대표적인 봇입니다. 활동량은 시기에 따라 편차가 큰데, Cloudflare 데이터를 보면 2024년 한때 AI 크롤러 트래픽의 40%를 넘길 만큼 공격적으로 수집하다가 이후 급감하는 등 점유율이 크게 출렁였습니다. 문제는 규모가 아니라 태도입니다. Cloudflare도 명시하듯 robots.txt 준수는 어차피 자발적이라, 이렇게 선언을 무시하는 봇은 robots.txt로 막을 수 없고 서버나 WAF(방화벽) 레벨에서 차단해야 합니다.

실전 robots.txt 전략

세 가지 기본 자세

접근 제어 전략은 크게 세 가지로 나뉩니다.

전면 개방(Open by default) — 모든 주요 AI 봇을 허용합니다. AI 검색에서의 노출을 최대화하는 전략으로, 브랜드 노출이 중요한 B2B SaaS, 미디어, 콘텐츠 사이트에서 일반적입니다.

선택적 허용(Selective) — 검색·인용에 필요한 봇(OAI-SearchBot, Claude-SearchBot, PerplexityBot 등)은 허용하고, 학습 전용 크롤러(CCBot, 선택적으로 GPTBot)는 차단합니다. 노출은 유지하면서 학습 데이터 제공은 제한하는 절충안입니다.

전면 차단 — 모든 AI 봇을 차단합니다. 콘텐츠 유료화 모델이거나 저작권 보호가 최우선인 경우인데, AI 검색 생태계에서 완전히 사라진다는 걸 감수해야 합니다.

국내 서비스들은 어떻게 하고 있나 (2026년 7월 기준)

robots.txt는 누구나 확인할 수 있는 공개 파일입니다. 국내 주요 서비스들의 설정을 살펴보면, 전략적 분화가 뚜렷하게 보입니다.

네이버 — 명시적 전면 차단. 네이버는 메인 도메인(www.naver.com)부터 User-agent: * / Disallow: /로 사실상 모든 봇을 막고, 콘텐츠가 실제로 쌓이는 검색·블로그 도메인(search.naver.com, blog.naver.com)에서는 한발 더 나아갑니다. 이들 robots.txt에는 주석으로 "BOT ACCESS FOR THE PURPOSES OF AI TRAINING AND RETRIEVAL-AUGMENTED GENERATION (RAG) IS STRICTLY PROHIBITED"라고 명시하고, GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Claude-SearchBot, Google-Extended, CCBot 등 주요 AI 봇을 전부 개별 지정해서 차단합니다. 학습뿐 아니라 RAG(검색 인용) 목적의 접근까지 명시적으로 금지한다는 점이 특징입니다.

쿠팡 — 화이트리스트 방식 전면 차단. Googlebot, Yeti(네이버), Bingbot 같은 전통 검색 크롤러에게만 특정 경로를 허용하고, 마지막에 User-agent: * + Disallow: /로 나머지 모든 봇을 차단하는 구조입니다. AI 봇을 개별 지정하지 않고, 허용 목록에 없는 봇은 전부 막는 방식입니다.

무신사 — 화이트리스트형 개방. 무신사는 OAI-SearchBot, ChatGPT-User, Claude-User, Claude-SearchBot, Perplexity-User 같은 검색·사용자 요청 봇은 전면 허용하고, GPTBot·ClaudeBot·CCBot·Google-Extended 같은 학습용 봇까지 마이페이지·로그인 등 일부 사적 경로만 제외하고 허용합니다. 그리고 마지막에 User-agent: * / Disallow: /로 명단에 없는 봇을 전부 막습니다. 학습이냐 인용이냐로 가르기보다, 허용할 봇을 명시적으로 추린 화이트리스트에 가깝습니다.

탑텐 — 사실상 전면 개방. AI 학습·수집 크롤러(GPTBot, ClaudeBot, cohere-ai, Meta-ExternalAgent 등)까지 포함해서 대부분의 봇을 허용하고, 로그인·보안 경로만 차단하고 있습니다.

이 분화에는 패턴이 있습니다. 자체 콘텐츠 생태계와 트래픽 기반을 가진 플랫폼(네이버, 쿠팡)은 차단을 선택하고, AI 검색에서의 노출이 곧 유입 기회인 브랜드 커머스(무신사, 탑텐)는 개방을 선택하고 있습니다. 네이버 입장에서 AI 검색은 자사 검색 서비스의 경쟁자이고, 쿠팡 입장에서 콘텐츠는 앱 안에서 소비되는 자산이니까요. 반면 무신사나 탑텐 입장에서는 "10만 원 이하 러닝화 추천해줘"라는 질문에 자사 상품이 인용되는 게 이득입니다.

참고로 올해 초까지만 해도 네이버와 쿠팡이 AI 크롤러 접근을 일부 허용하고 있었는데, 이후 전면 차단으로 바뀌었습니다. 이 영역은 각 기업의 전략에 따라 계속 움직이고 있어서, 우리 서비스의 방향을 정할 때도 "지금 어떤 선택을 하는가"만큼 "언제든 다시 검토할 수 있는가"가 중요합니다.

한 가지 짚어둘 점은, 어느 쪽이 정답이라는 건 아니라는 겁니다. 비즈니스 모델에 따라 합리적인 선택이 달라지는 영역입니다. 다만 어느 쪽이든, 자기 사이트의 robots.txt가 실제로 어떤 상태인지 알고 내린 결정이어야 합니다. SEO 플러그인 기본값 때문에 의도치 않게 차단되어 있는 것과, 전략적으로 차단을 선택한 것은 완전히 다른 이야기니까요.

AI 노출을 원한다면 — 권장 설정 예시

# OpenAI
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

# Anthropic
User-agent: ClaudeBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

# Perplexity
User-agent: PerplexityBot
Allow: /

# 민감한 경로는 공통으로 차단
User-agent: *
Disallow: /admin/
Disallow: /checkout/
Disallow: /api/

"학습은 거부, 인용은 유지"를 원한다면

# 학습용 크롤러 차단
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# 검색·인용용 봇은 허용
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

주의할 점들

SEO 플러그인의 기본값을 확인하세요. WordPress나 Shopify의 일부 SEO 플러그인이 2024~2025년에 "AI 봇 차단" 토글을 추가하면서 기본값을 켜둔 경우가 있습니다. 의도치 않게 AI 검색에서 사라진 사이트들이 이 케이스인 경우가 많습니다. 우리 사이트의 robots.txt를 실제로 열어서 확인해보는 게 좋습니다.

robots.txt는 신사협정입니다. 강제력이 없습니다. Bytespider처럼 무시하는 봇에게는 서버 레벨 차단(WAF, CDN 봇 관리)이 필요합니다. 정말 보호해야 할 콘텐츠라면 robots.txt 선언만으로는 부족합니다.

봇 검증은 역방향 DNS로. User-Agent 문자열은 누구나 위조할 수 있습니다. 로그에서 특정 봇의 진위를 확인하려면 역방향 DNS 조회(reverse DNS lookup)로 실제 해당 사업자의 IP 대역인지 확인해야 합니다.

Agentic Experiences — 크롤러 다음에 오는 것

4편에서 다뤘던 Google의 AI 최적화 가이드에는 "Agentic Experiences"라는 섹션이 있습니다. AI 에이전트가 사용자를 대신해서 사이트를 방문하고 작업을 수행하는 시대에 대한 이야기입니다.

이게 먼 미래 이야기가 아닙니다. 이미 진행 중이거든요.

Universal Commerce Protocol (UCP)

2026년 1월, Google이 NRF(전미소매협회) 컨퍼런스에서 Universal Commerce Protocol(UCP)을 발표했습니다. AI 에이전트가 이커머스 사이트와 소통하고 사용자 대신 구매까지 완료할 수 있게 하는 오픈소스 표준입니다. Shopify, Etsy, Wayfair, Target, Walmart 같은 리테일 기업들과 공동 개발했고, Visa, Mastercard, Stripe, PayPal 같은 결제 사업자들이 참여하고 있습니다.

사용자가 Gemini에게 "10만 원 이하 러닝화 찾아줘"라고 하면, AI 에이전트가 여러 리테일러의 상품을 검색·비교해서 제시하고, 사용자가 승인하면 구매까지 완료하는 흐름입니다. 2026년 5월에는 Universal Cart(리테일러 간 장바구니 통합)가 발표됐고, 호텔 예약과 음식 배달 같은 새로운 버티컬로도 확장되고 있습니다.

프론트엔드 개발자에게 의미하는 것

이 흐름에서 흥미로운 지점이 있습니다. AI 에이전트는 사람보다 데이터 불일치에 민감합니다.

사람은 상품 페이지의 가격과 피드의 가격이 조금 달라도 눈치 못 챌 수 있지만, AI 에이전트는 바로 잡아냅니다. 반품 정책이 페이지마다 다르게 적혀 있으면, 에이전트는 그 사이트를 신뢰할 수 없는 소스로 판단할 수 있습니다.

그래서 에이전트 시대의 사이트 관리 포인트는 이렇게 정리됩니다.

상품 정보가 사이트, 피드(Merchant Center), 외부 채널에서 일관되는가
배송·반품·고객지원 정보가 모든 위치에서 일치하는가
구조화 데이터(4편)가 실제 페이지 내용과 정확히 일치하는가
결제·예약 흐름이 에이전트가 진입해도 무리 없는 구조인가

결국 이것도 새로운 기술이라기보다, 이 시리즈에서 계속 다뤄온 원칙의 연장입니다. 정확하고 일관된 정보를, 기계가 이해할 수 있는 구조로 제공하는 것. 크롤러에게든, AI에게든, 에이전트에게든 같은 원칙이 적용됩니다.

시리즈를 마치며 — SEO 없이 GEO는 없다

여섯 편에 걸쳐 다뤄온 내용을 한 줄로 정리하면 이렇습니다.

GEO는 SEO를 대체하는 게 아니라, SEO 위에 쌓이는 확장이다.

1편에서 SEO가 왜 여전히 중요한지, 그리고 AI 검색 시대에 GEO라는 관점이 왜 필요해졌는지를 다뤘습니다. 2편에서는 크롤러가 사이트를 발견하는 과정을, 3편에서는 AI가 인용하고 싶어하는 콘텐츠 구조를, 4편에서는 구조화 데이터를, 5편에서는 성능을, 그리고 이번 편에서는 AI 크롤러 접근 제어와 에이전트 시대를 다뤘습니다.

돌아보면 전부 연결되어 있습니다. robots.txt가 잘못되면 크롤링이 안 되고, 크롤링이 안 되면 인덱싱이 안 되고, 인덱싱이 안 되면 검색에도 AI 답변에도 나올 수 없습니다. Google이 공식 가이드에서 확인해준 것처럼, AI 검색은 기존 검색 인덱스를 기반으로 작동하니까요. 헤딩 구조가 엉망이면 검색엔진도 AI도 콘텐츠를 이해하기 어렵고, 성능이 나쁘면 사용자도 크롤러도 떠납니다.

SEO와 GEO를 별개로 보면 판단을 놓칩니다. FAQPage 스키마가 좋은 예였습니다 — SEO 관점만 보면 리치 결과가 종료됐으니 빼도 되지만, GEO 관점까지 보면 AI 인용 신호로 유지하는 게 맞습니다. 반대로 GEO만 좇으면 기반 없이 지붕을 올리는 셈이 됩니다. llms.txt 같은 비공식 트렌드에 시간을 쓰는 것보다, robots.txt와 sitemap을 정확히 설정하는 게 훨씬 실질적입니다.

두 가지를 함께, 하나의 흐름으로 보는 것. 그게 이 시리즈에서 전하고 싶었던 핵심입니다.

긴 시리즈 읽어주셔서 감사합니다. 이 글이 검색과 AI의 경계가 흐려지는 시대에, 우리가 만드는 웹페이지를 조금 더 잘 이해받게 만드는 데 도움이 됐으면 좋겠습니다.

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

참고 자료

VPC

crsmym — Mon, 12 Oct 2026 14:30:00 +0900

들어가며

최근 웹 서비스, 클라우드, 그리고 AI 애플리케이션 개발에서 인프라 구조를 이해하는 일은 점점 더 중요해지고 있습니다. 예전에는 서버 한 대에 웹 서버와 데이터베이스를 함께 올려 운영하는 경우도 많았지만, 요즘은 서비스 규모가 커지고 구조가 복잡해지면서 네트워크 설계 역시 중요한 요소가 되었습니다.

AWS를 사용하다 보면 EC2, RDS, Load Balancer, NAT Gateway 같은 여러 서비스를 만나게 됩니다. 그리고 이 서비스들을 구성할 때 거의 항상 함께 등장하는 개념이 있습니다. 바로 VPC입니다.

처음에는 VPC라는 용어가 낯설 수 있습니다. Virtual Private Cloud라는 이름도 어렵게 느껴지고, Subnet, CIDR, Route Table, Internet Gateway, Security Group 같은 용어들이 한꺼번에 나오기 때문에 더 헷갈릴 수 있습니다.

하지만 VPC는 어렵게만 볼 개념은 아닙니다.

조금 쉽게 말하면, VPC는 클라우드 안에 만드는 우리 서비스만의 네트워크 공간입니다.

이번 포스팅에서는 VPC를 이해하기 위해 필요한 기본 개념들을 일상의 예시와 함께 정리해보려 합니다.

VPC란?

VPC

정의: VPC는 Virtual Private Cloud의 약자로, 클라우드 안에 논리적으로 분리해서 만드는 나만의 가상 네트워크 공간입니다.

일상 비유: AWS라는 거대한 도시 안에 우리 회사만 사용할 수 있는 독립된 동네를 만드는 것

특징: 이 공간 안에 서버, 데이터베이스, 로드 밸런서 같은 리소스들을 배치하고, 외부 인터넷과 어떻게 연결할지, 내부 리소스끼리는 어떻게 통신할지 정할 수 있습니다.

AWS 전체를 하나의 거대한 도시라고 생각해보면, VPC는 그 도시 안에 있는 우리 회사의 독립된 구역이라고 볼 수 있습니다.

그 안에는 여러 건물이 있을 수 있습니다.

웹 서버 = 사용자가 방문하는 매장
API 서버 = 실제 업무를 처리하는 사무실
데이터베이스 = 중요한 정보를 보관하는 금고
로드 밸런서 = 방문객을 적절한 창구로 안내하는 안내 데스크

이 리소스들을 아무 곳에나 배치하는 것이 아니라, 어떤 리소스는 외부에서 접근 가능하게 하고, 어떤 리소스는 내부에서만 접근 가능하게 나누어야 합니다.

이런 구조를 만들기 위한 기본 공간이 바로 VPC입니다.

왜 VPC가 필요할까?

웹 서비스를 하나 만든다고 생각해보겠습니다.

사용자는 브라우저를 통해 서비스에 접속합니다.

서비스는 API 서버에 요청을 보내고, API 서버는 데이터베이스에서 데이터를 가져옵니다.

흐름만 보면 단순합니다.

사용자 → 웹 서버 → API 서버 → 데이터베이스

하지만 실제 운영 환경에서는 모든 서버가 외부 인터넷에 그대로 노출되면 안 됩니다.

웹 서버나 로드 밸런서는 외부 사용자의 요청을 받아야 합니다.

하지만 데이터베이스는 외부 사용자가 직접 접근하면 안 됩니다.

API 서버도 가능하다면 외부에 직접 노출하기보다는 로드 밸런서를 통해서만 접근하게 하는 것이 좋습니다.

즉 리소스마다 공개 범위가 달라야 합니다.

로드 밸런서: 외부 사용자 접근 가능
API 서버: 로드 밸런서를 통해서만 접근
데이터베이스: API 서버에서만 접근
내부 배치 서버: 외부 접근 불필요

일상적으로 비유하면 회사 건물과 비슷합니다.

회사 1층 로비는 외부 방문객이 들어올 수 있습니다.

하지만 사무실 내부, 서버실, 문서 보관실은 아무나 들어가면 안 됩니다.

클라우드에서도 마찬가지입니다.

외부에 열어야 하는 공간과 내부에 숨겨야 하는 공간을 구분해야 합니다.

VPC는 이 구분을 가능하게 해주는 기본 틀입니다.

CIDR

정의: VPC 안에서 사용할 IP 주소 범위를 정하는 방식입니다.

일상 비유: 우리 회사 동네에서 사용할 주소 체계를 정하는 것

특징: VPC를 만들 때 가장 먼저 정하는 값 중 하나이며, 이 범위 안에서 Subnet을 나누고 서버들의 내부 IP가 할당됩니다.

VPC를 만들 때 보통 이런 값을 보게 됩니다.

10.0.0.0/16

처음 보면 숫자와 슬래시 때문에 어렵게 느껴질 수 있습니다.

하지만 처음에는 이렇게 이해하면 충분합니다.

이 VPC 안에서는 10.0으로 시작하는 주소 범위를 사용하겠다.

예를 들어 VPC 주소 범위를 10.0.0.0/16으로 정했다면, 그 안에 있는 서버들은 이런 내부 주소를 가질 수 있습니다.

10.0.1.10 → 웹 서버
10.0.2.20 → API 서버
10.0.3.30 → 데이터베이스

CIDR은 결국 VPC 안에서 사용할 내부 주소 범위를 정하는 개념입니다.

Subnet

정의: VPC라는 큰 네트워크 공간을 더 작은 구역으로 나눈 것입니다.

일상 비유: 회사 부지를 사무동, 연구동, 창고, 보안 구역처럼 나누는 상황

특징: EC2, RDS 같은 리소스는 보통 특정 Subnet 안에 배치됩니다.

예를 들어 VPC 전체 주소 범위를 이렇게 잡았다고 해보겠습니다.

VPC: 10.0.0.0/16

이 VPC 안을 여러 Subnet으로 나눌 수 있습니다.

Public Subnet A:  10.0.1.0/24
Private Subnet A: 10.0.2.0/24
Public Subnet B:  10.0.3.0/24
Private Subnet B: 10.0.4.0/24

Subnet을 나누는 이유는 역할이 다른 리소스를 같은 공간에 섞어두지 않기 위해서입니다.

현실에서도 도시를 만들 때 상가 지역, 주거 지역, 공장 지역, 보안 구역을 나누듯이 클라우드에서도 역할에 따라 공간을 나눕니다.

외부 사용자가 접근해야 하는 로드 밸런서 → Public Subnet
외부에서 직접 접근하면 안 되는 API 서버 → Private Subnet
중요한 데이터를 저장하는 데이터베이스 → Private Subnet

즉 Subnet은 VPC 안에서 리소스의 위치와 역할을 나누기 위한 구역입니다.

Public Subnet과 Private Subnet

Public Subnet

정의: 인터넷과 직접 연결될 수 있는 Subnet입니다.

일상 비유: 외부 손님이 들어올 수 있는 회사 로비나 매장 입구

특징: 보통 Internet Gateway로 향하는 경로가 Route Table에 설정되어 있습니다.

Public Subnet에는 보통 외부 요청을 받아야 하는 리소스를 둡니다.

Load Balancer
Bastion Host
외부 공개용 웹 서버

다만 Public Subnet에 있다고 해서 모든 리소스가 자동으로 인터넷에 공개되는 것은 아닙니다.

외부에서 접근하려면 보통 다음 조건들이 함께 필요합니다.

VPC에 Internet Gateway가 연결되어 있어야 함
Subnet의 Route Table에 Internet Gateway 경로가 있어야 함
리소스에 Public IP가 있어야 함
Security Group에서 필요한 포트가 열려 있어야 함

즉 Public Subnet은 “외부와 연결될 수 있는 길이 있는 구역”이지, 무조건 모두에게 공개된 구역은 아닙니다.

Private Subnet

정의: 인터넷에서 직접 접근할 수 없도록 내부에 숨겨둔 Subnet입니다.

일상 비유: 회사 내부 사무실, 서버실, 금고방처럼 외부 손님이 직접 들어올 수 없는 공간

특징: 외부에서 직접 들어오는 길은 막고, 필요한 경우 NAT Gateway를 통해 내부에서 외부로 나가는 요청만 가능하게 구성합니다.

Private Subnet에는 보통 중요한 리소스를 둡니다.

Application Server
Database
Cache Server
Batch Server
Worker Server

데이터베이스를 예로 들어보겠습니다.

사용자가 웹사이트를 이용한다고 해서 데이터베이스에 직접 접속할 필요는 없습니다.

사용자는 웹 서버나 API 서버에 요청을 보내고, API 서버가 데이터베이스와 통신하면 됩니다.

사용자 → Load Balancer → API Server → Database

이 구조에서 사용자는 Load Balancer까지만 접근합니다.

API 서버와 데이터베이스는 내부에 숨겨둘 수 있습니다.

이렇게 구성하면 보안 측면에서 훨씬 안전합니다.

Route Table

정의: 네트워크 트래픽이 어디로 가야 하는지 알려주는 경로 규칙입니다.

일상 비유: 동네 안에 설치된 도로 표지판 또는 내비게이션

특징: Subnet과 연결되어 있으며, 어떤 목적지로 가는 트래픽을 어디로 보낼지 결정합니다.

VPC 안에 서버를 만들었다고 해서 트래픽이 자동으로 원하는 곳으로 이동하는 것은 아닙니다.

트래픽도 길을 알아야 합니다.

예를 들어 이런 Route Table이 있다고 해보겠습니다.

10.0.0.0/16 → local
0.0.0.0/0   → Internet Gateway

이걸 말로 풀면 이렇게 볼 수 있습니다.

10.0.0.0/16 범위의 주소는 VPC 내부에서 처리한다.
그 외 모든 목적지는 Internet Gateway로 보낸다.

여기서 0.0.0.0/0은 쉽게 말해 “나머지 모든 곳” 정도로 이해하면 됩니다.

Route Table이 중요한 이유는 길이 없으면 트래픽이 갈 수 없기 때문입니다.

서버가 켜져 있고 Security Group이 열려 있어도, Route Table에 경로가 없으면 통신이 되지 않을 수 있습니다.

현실에서도 건물이 아무리 잘 지어져 있어도, 그 건물로 가는 도로가 끊겨 있으면 갈 수 없습니다.

VPC에서도 마찬가지입니다.

Internet Gateway

정의: VPC가 외부 인터넷과 통신할 수 있게 해주는 출입구입니다.

일상 비유: 우리 회사 동네와 외부 도로를 연결하는 정문

특징: Public Subnet에서 인터넷으로 나가거나, 인터넷에서 Public Subnet의 리소스로 들어오기 위해 사용됩니다.

VPC는 기본적으로 독립된 네트워크 공간입니다.

그 공간이 외부 인터넷과 통신하려면 출입구가 필요합니다.

그 역할을 하는 것이 Internet Gateway입니다.

하지만 Internet Gateway를 VPC에 연결했다고 해서 모든 리소스가 바로 인터넷과 연결되는 것은 아닙니다.

Internet Gateway 연결
Route Table 경로 설정
Public IP 할당
Security Group 포트 허용

이 조건들이 함께 맞아야 외부에서 접근할 수 있습니다.

Internet Gateway는 정문입니다.

하지만 정문이 있다고 해서 모든 방의 문이 열려 있는 것은 아닙니다.

NAT Gateway

정의: Private Subnet 안에 있는 리소스가 외부 인터넷으로 요청을 보낼 수 있게 도와주는 서비스입니다.

일상 비유: 외부에 직접 나갈 수 없는 내부 직원 대신 심부름을 다녀오는 담당자

특징: Private Subnet의 리소스가 외부로 나갈 수는 있게 하지만, 외부에서 Private Subnet으로 직접 들어오게 하지는 않습니다.

Private Subnet의 서버도 가끔 외부 인터넷이 필요할 때가 있습니다.

OS 패키지 업데이트
Docker 이미지 다운로드
외부 API 호출
라이브러리 설치
보안 패치 다운로드

하지만 이런 이유로 Private Subnet의 서버를 인터넷에 직접 노출하는 것은 좋지 않습니다.

이때 사용하는 것이 NAT Gateway입니다.

흐름은 대략 이렇습니다.

Private Subnet의 서버
  ↓
NAT Gateway
  ↓
Internet

즉 서버가 직접 밖으로 나가는 것이 아니라, NAT Gateway가 외부 요청을 대신 처리해주는 방식입니다.

중요한 점은 NAT Gateway가 외부에서 Private Subnet으로 들어오기 위한 문은 아니라는 것입니다.

NAT Gateway는 내부 리소스가 외부로 나가기 위한 통로입니다.

Security Group

정의: EC2, RDS, Load Balancer 같은 리소스 단위에 적용하는 가상 방화벽입니다.

일상 비유: 각 건물 출입문 앞에 있는 보안 담당자

특징: 어떤 IP 또는 어떤 리소스가 어떤 포트로 들어올 수 있는지 제어합니다.

예를 들어 웹 서버의 Security Group은 이렇게 설정할 수 있습니다.

80번 포트  → 전체 허용
443번 포트 → 전체 허용
22번 포트  → 내 사무실 IP에서만 허용

데이터베이스의 Security Group은 더 엄격하게 설정할 수 있습니다.

3306번 포트 → API 서버에서만 허용
외부 인터넷 → 직접 접근 불가

이렇게 하면 사용자는 웹 서버에는 접근할 수 있지만, 데이터베이스에는 직접 접근할 수 없습니다.

Security Group의 중요한 특징은 stateful이라는 점입니다.

쉽게 말하면 요청과 응답의 관계를 기억한다는 뜻입니다.

서버가 외부 API에 요청을 보냈다면, 그 요청에 대한 응답은 자연스럽게 다시 서버로 돌아올 수 있습니다.

요청과 응답의 흐름을 기억하기 때문입니다.

Network ACL

정의: Subnet 단위로 적용하는 네트워크 접근 제어 규칙입니다.

일상 비유: 동네 입구에 있는 검문소

특징: Security Group보다 더 넓은 범위인 Subnet 단위에서 인바운드, 아웃바운드 트래픽을 허용하거나 차단합니다.

Security Group이 각 건물의 출입문 보안이라면, Network ACL은 동네 입구의 검문소에 가깝습니다.

Security Group = 건물 출입문 보안
Network ACL    = 동네 입구 검문소

Network ACL의 중요한 특징은 stateless라는 점입니다.

Security Group은 요청과 응답의 관계를 기억하지만, Network ACL은 기억하지 않습니다.

그래서 들어오는 규칙과 나가는 규칙을 각각 따로 봐야 합니다.

처음에는 이렇게 기억하면 좋습니다.

Security Group은 리소스 단위의 방화벽
Network ACL은 Subnet 단위의 방화벽
Security Group은 stateful
Network ACL은 stateless

Availability Zone

정의: 하나의 리전 안에 있는 물리적으로 분리된 데이터센터 구역입니다.

일상 비유: 같은 도시 안에 있지만 서로 떨어져 있는 여러 지점의 사무실 또는 창고

특징: 장애에 대비하기 위해 리소스를 여러 Availability Zone에 나눠 배치할 수 있습니다.

AWS에서 VPC는 특정 리전 안에 생성됩니다.

예를 들어 서울 리전을 사용한다면, VPC는 서울 리전 안에 만들어집니다.

그리고 그 리전 안에는 여러 Availability Zone이 있습니다.

운영 환경에서는 보통 Public Subnet과 Private Subnet을 여러 AZ에 나눠 구성합니다.

AZ A
- Public Subnet A
- Private Subnet A

AZ C
- Public Subnet C
- Private Subnet C

이렇게 구성하는 이유는 장애에 대비하기 위해서입니다.

모든 서버를 하나의 구역에만 배치했는데 그 구역에 문제가 생기면 서비스 전체가 영향을 받을 수 있습니다.

반대로 여러 AZ에 나눠두면 한쪽에 문제가 생겨도 다른 쪽에서 서비스를 계속할 가능성이 높아집니다.

전체 흐름 예시

간단한 웹 서비스를 하나 만든다고 가정해보겠습니다.

요구사항은 다음과 같습니다.

사용자는 웹사이트에 접속할 수 있어야 함
외부 요청은 Load Balancer가 받아야 함
Application Server는 외부에 직접 노출하지 않음
Database는 Application Server에서만 접근 가능해야 함
Application Server는 외부 API 호출이나 패키지 업데이트가 가능해야 함

이 구조를 VPC로 표현하면 대략 이렇게 볼 수 있습니다.

VPC: 10.0.0.0/16

Public Subnet
- Load Balancer
- NAT Gateway

Private Subnet
- Application Server
- Database

사용자의 요청 흐름은 이렇게 됩니다.

사용자
  ↓
Internet
  ↓
Internet Gateway
  ↓
Load Balancer
  ↓
Application Server
  ↓
Database

Private Subnet의 Application Server가 외부 인터넷으로 나가야 할 때는 이렇게 됩니다.

Application Server
  ↓
NAT Gateway
  ↓
Internet

보안 규칙은 대략 이런 식으로 잡을 수 있습니다.

Load Balancer
- 80, 443 포트: 전체 인터넷에서 허용

Application Server
- 애플리케이션 포트: Load Balancer에서만 허용

Database
- DB 포트: Application Server에서만 허용

이 구조의 핵심은 단순합니다.

외부 사용자는 Load Balancer까지만 접근합니다.

Application Server와 Database는 외부에 직접 노출하지 않습니다.

Private Subnet의 서버가 외부로 나갈 필요가 있을 때는 NAT Gateway를 사용합니다.

핵심 구분

VPC를 처음 공부할 때는 여러 용어가 한꺼번에 나오기 때문에 헷갈리기 쉽습니다.

그래서 각 개념을 역할 중심으로 구분해보면 이해가 조금 쉬워집니다.

VPC
→ 클라우드 안에 만드는 우리 서비스의 독립된 네트워크 공간

CIDR
→ VPC 안에서 사용할 주소 범위

Subnet
→ VPC 안을 역할별로 나눈 구역

Public Subnet
→ 인터넷과 직접 연결될 수 있는 구역

Private Subnet
→ 외부에서 직접 접근하지 못하게 숨겨둔 구역

Route Table
→ 트래픽이 어디로 가야 하는지 알려주는 경로 규칙

Internet Gateway
→ VPC와 인터넷을 연결하는 정문

NAT Gateway
→ Private Subnet의 리소스가 외부로 나가도록 도와주는 대리인

Security Group
→ 리소스 단위의 방화벽

Network ACL
→ Subnet 단위의 방화벽

Availability Zone
→ 장애에 대비하기 위해 나눠진 데이터센터 구역

실무에서의 고려사항

1) 데이터베이스는 가능하면 Private Subnet에 두기

데이터베이스는 외부 사용자에게 직접 노출될 이유가 거의 없습니다.

일반적으로는 Application Server만 데이터베이스에 접근하도록 구성하는 것이 좋습니다.

사용자 → Load Balancer → Application Server → Database

2) Public Subnet에는 꼭 필요한 리소스만 두기

Public Subnet은 인터넷과 직접 연결될 수 있는 구역입니다.

따라서 아무 리소스나 Public Subnet에 두는 것은 좋지 않습니다.

보통 외부 요청을 받아야 하는 Load Balancer나 Bastion Host 정도를 Public Subnet에 두고, 실제 Application Server는 Private Subnet에 두는 구성이 많이 사용됩니다.

3) Private Subnet의 외부 통신은 NAT Gateway로 처리하기

Private Subnet의 서버도 외부 API 호출이나 패키지 업데이트가 필요할 수 있습니다.

이때 서버를 Public Subnet으로 옮기기보다는 NAT Gateway를 통해 외부로 나가게 구성하는 것이 좋습니다.

4) Security Group은 최소한으로 열기

Security Group은 필요한 포트만 열어야 합니다.

나쁜 예시:
3306 포트를 전체 인터넷에 허용

좋은 예시:
3306 포트를 Application Server에서만 허용

특히 SSH, DB 포트처럼 민감한 포트는 전체 인터넷에 열어두지 않는 것이 좋습니다.

마치며

정리해보면, VPC는 클라우드 안에 만드는 우리 서비스만의 독립된 네트워크 공간이라고 볼 수 있습니다. 처음에는 CIDR, Subnet, Route Table, Internet Gateway, NAT Gateway, Security Group, Network ACL 같은 용어들이 한꺼번에 나와 어렵게 느껴질 수 있지만, 각각의 역할을 일상적인 비유로 이해하면 훨씬 덜 복잡하게 느껴집니다.

VPC는 회사의 사유지와 비슷합니다.

CIDR은 그 사유지 안에서 사용할 주소 체계이고, Subnet은 역할별로 나눈 구역입니다.

Route Table은 길 안내 표지판이고, Internet Gateway는 외부로 나가는 정문입니다.

NAT Gateway는 내부 리소스를 대신해 외부 요청을 처리하는 심부름 담당자이며, Security Group은 각 건물의 출입문 보안, Network ACL은 동네 입구의 검문소라고 볼 수 있습니다.

결국 VPC를 이해한다는 것은 단순히 서버를 어디에 둘지 정하는 문제가 아닙니다.

외부에 어떤 문을 열어둘지, 어떤 리소스는 내부에 숨길지, 어떤 길로 트래픽을 보내야 할지, 누가 어떤 포트로 접근할 수 있는지를 설계하는 일입니다.

처음부터 모든 네트워크 이론을 완벽하게 이해할 필요는 없다고 생각합니다.

다만 VPC를 볼 때마다 다음 질문을 던져보면 좋을 것 같습니다.

외부에서 직접 접근이 가능해야 할까?
내부에서만 접근하면 될까?
인터넷으로 나가는 길이 필요할까?
누가 어떤 포트로 접근할 수 있어야 할까?

이러한 질문들에 답하다 보면 VPC는 막연하게 어려운 네트워크 용어 묶음이 아니라, 서비스를 안전하고 안정적으로 운영하기 위한 기본 설계 도구로 보이기 시작할 것입니다.

읽어주셔서 감사합니다.

서비스 아이디어 발굴부터 프로토타입까지, AI와 함께 일해본 기록 - 2편

Haeun Choi — Thu, 1 Oct 2026 07:50:36 +0900

1편에서는 아이데이션 과정에서 AI Persona를 활용해 여러 사용자의 관점에서 아이디어를 바라보고, 고도화의 힌트를 얻었던 경험을 이야기했습니다.

이번 편에서는 아이디어가 어느 정도 구체화된 이후, UX 리서처로서 Figma Make를 활용해 직접 프로토타입까지 만들어본 경험을 이야기해보려고 합니다.

평소에는 서비스 아이디어와 UX 컨셉을 구체화하는 데 집중했다면, 이번에는 AI를 활용해 그 아이디어를 실제 화면으로 옮기는 과정까지 직접 경험해 봤습니다. 그 과정에서 컨셉 단계와는 또 다른 고민이 필요했고, 동시에 AI 프로토타이핑을 활용해 아이디어를 다시 바라보고 고도화하기도 했습니다.

이번 글에서는 UX 리서처의 관점에서 AI 프로토타이핑을 해보며 무엇을 새롭게 고민했고, 어떤 방식으로 활용할 수 있었는지를 정리해보려고 합니다.

Figma Make가 임의로 채우는 ‘빈칸’ 줄이기

처음에는 아이디어의 배경과 컨셉, 주요 사용 장면 정도만 전달하면 Figma Make가 어느 정도 알아서 화면으로 풀어줄 것이라고 생각했습니다.

하지만 실제 결과를 받아보니 정보 구성이 다소 엉성하거나, 팀이 중요하게 생각한 내용이 빠지기도 했고, 컨셉은 맞지만 우리가 의도했던 경험과는 다른 화면이 나오기도 했습니다.

돌이켜보면 아이디어나 UX 컨셉을 정의할 때와 실제 화면을 만들 때 필요한 구체성의 수준 자체가 달랐습니다.

컨셉 단계에서는 주요 기능을 중심으로 시스템이 어떤 정보를 바탕으로 무엇을 판단하며, 어떤 경험을 제공할 것인지 정도를 정의해도 충분했습니다. 하지만 실제 화면으로 구현하기 위해서는 그보다 훨씬 더 구체적인 정의가 필요했습니다.

1. 컨셉과 화면 사이의 빈칸 채우기

프로토타이핑 단계에서 가장 크게 느낀 차이는 아이디어나 UX 컨셉을 정의할 때와 실제 화면을 만들 때 필요한 구체성의 수준이 다르다는 것이었습니다.

아이디어를 발전시키는 단계에서는 주요 기능을 중심으로 시스템이 어떤 정보를 활용해 무엇을 판단하고, 어떤 경험을 제공할 것인지 정도를 정의해도 충분했습니다. 이 단계에서는 서비스 전체의 구조와 핵심 가치가 명확한지가 더 중요했기 때문입니다.

예를 들어 여러 조건과 데이터를 종합해 시스템이 사용자를 대신해 최적의 시점과 방법을 판단하고 조정해 주는 서비스라면, 컨셉 단계에서는 어떤 정보를 활용하고 무엇을 자동으로 판단·조정하는지 정도만 정의해도 아이디어를 설명할 수 있었죠.

하지만 이를 실제 화면으로 옮기려고 하니 훨씬 더 많은 것을 결정해야 했습니다.

사용자는 현재 어떤 상태를 확인해야 하는지
시스템이 무엇을 대신 판단했는지, 어디까지 보여줄지
왜 그런 판단을 했는지, 어떤 정보로 설명할지
어떤 메시지가 있어야 현재 상황을 이해할 수 있는지
사용자는 확인만 하면 되는지, 직접 수정하거나 개입할 수도 있어야 하는지
상세한 정보는 언제, 어느 수준까지 보여줄지

처럼 시스템이나 서비스 차원에서 정의했던 기능을 실제 사용자 경험으로 전달하기 위해 필요한 정보와 행동을 하나씩 다시 정의해야 했습니다.

Figma Make에 프롬프트를 작성할 때도 단순히 “이 화면에서는 ○○ 기능을 보여준다” 정도로는 부족했습니다. 각 씬을 다시 여러 화면으로 세분화하고, 화면마다 최상단에서 무엇을 보여줄지부터 각 섹션에 어떤 정보와 메시지가 들어가야 하는지까지 구체적으로 작성해야만 원하는 수준의 화면 결과를 받을 수 있었습니다.

결국 컨셉 단계에서는 “서비스가 무엇을 해줄 것인가”를 중심으로 생각했다면, 프로토타입 단계에서는 한 단계 더 나아가 “사용자는 그것을 화면에서 무엇을 통해 이해하고, 어떻게 확인하고, 필요할 때 개입할 것인가”까지 구체화해야 했습니다. 직접 프로토타입을 만들어보면서 컨셉을 실제 사용자 경험으로 연결하기 위해 생각보다 훨씬 많은 콘텐츠와 정보가 정의되어야 한다는 것을 체감했습니다.

2. 컨셉을 어떤 UI로 표현할지까지 고민하기

정보와 콘텐츠를 구체적으로 정의한 뒤에는 또 다른 고민이 생겼습니다. 그 정보를 실제 화면에서 어떤 UI로 표현할 것인가였습니다.

평소 UX 리서처로 리서치 프로젝트를 할 때는 사용자 문제를 정의하고 서비스 아이디어와 컨셉을 구체화하는 데 집중하기 때문에, 실제 화면의 표현 방식까지 깊게 고민할 일은 많지 않습니다. 하지만 직접 프로토타입을 만들다 보니, 컨셉 단계에서는 자유롭게 나열할 수 있었던 기능과 정보를 한정된 화면 안에서는 모두 같은 깊이로 보여줄 수 없다는 것부터 고민해야 했습니다.

어떤 정보를 가장 먼저 보여줄지, 무엇은 상세 영역으로 내려야 할지, 어떤 기능을 사용자가 바로 조작할 수 있게 할지 등 정보의 우선순위와 위계를 결정해야 했습니다.또 같은 정보라도 카드, 그래프, 진행 상태 등 어떤 UI 형태로 표현하느냐에 따라 화면의 인상과 강조되는 지점이 크게 달라졌습니다.

물론 정보 구성을 충분히 구체적으로 입력하면 Figma Make가 기본적인 UI는 알아서 만들어줬습니다. 다만 몇 번 사용해보니, 화면의 목적이나 정보가 달라도 결과물이 전반적으로 비슷한 UI 형태로 생성되는 경우가 대부분이었죠. 기능적으로는 문제가 없더라도 AI가 선택한 UI 패턴이 항상 저희가 생각한 최선의 표현 방식은 아니었습니다.

그래서 원하는 UI가 있을 때는 말로 하나씩 설명하기보다 다른 서비스의 레퍼런스 이미지를 직접 보여주는 방식을 활용했습니다. 예를 들어 움직이는 대상의 실시간 위치와 진행 현황을 표현하고 싶을 때는 배달 앱의 라이더 현황 화면을 캡처해 전달했습니다. 그러면 Figma Make가 레퍼런스를 참고해 의도한 형태에 훨씬 가깝게 구현해 줬습니다. “토글 UI를 활용해 줘”, “바 그래프를 도넛 그래프로 바꿔줘”처럼 세세하게 설명하는 것보다 “이 화면의 UI 구성을 참고해 줘”라고 이미지를 함께 전달하는 편이 훨씬 빠르고 정확했습니다.

이 과정을 통해 디자이너들이 다양한 서비스와 디자인 레퍼런스를 많이 참고하는 이유도 체감할 수 있었습니다. 말로 설명하기 어려운 표현 방식과 정보 구조를 레퍼런스 하나로 훨씬 명확하게 전달할 수 있었기 때문입니다.

AI 프로토타이핑을 컨셉 고도화에 활용하기

Figma Make를 활용하면서 유용했던 점은 아이디어를 빠르게 화면으로 만들어보고 다시 논의할 수 있었다는 것이었습니다. 직접 화면으로 옮기는 과정에서 컨셉 단계에서는 충분히 정의하지 않았던 부분까지 고민하게 됐고, 구현된 형태를 보며 아이디어를 다시 검토할 수도 있었습니다.

이 경험을 바탕으로 UX 리서처의 관점에서 AI 프로토타이핑을 활용하며 중요하다고 느낀 점을 세 가지로 정리해봤습니다.

Lessons Learned 1. 컨셉을 화면으로 옮기려면 한 번 더 ‘번역’이 필요하다.

아이디어 단계에서는 주요 기능과 제공 가치만으로도 컨셉을 설명할 수 있지만, 실제 화면으로 옮기려면 그 기능이 사용자에게 어떻게 전달될지까지 구체화해야 했습니다. 사용자가 어떤 정보를 봐야 하는지, 어떤 메시지를 통해 상황을 이해해야 하는지, 무엇을 확인하거나 직접 조정할 수 있어야 하는지까지 정의해야 비로소 화면으로 연결할 수 있었습니다.

AI가 UI를 만들어준다고 해도 컨셉과 화면 사이의 구체적인 UX 경험까지 자동으로 해결되는 것은 아니었습니다.

Lessons Learned 2. AI가 임의로 판단해야 하는 ‘빈칸’을 최대한 줄여야 한다.

컨셉만 설명하고 나머지를 알아서 만들어달라고 하면 빠르게 결과를 얻을 수는 있지만, 각 화면에 어떤 정보가 어떤 순서로 들어가야 하는지 구체적으로 정의하고, 원하는 표현 방식이 있다면 레퍼런스 이미지까지 함께 전달했을 때 훨씬 원하는 결과에 가까워졌습니다.

결국 무엇을 보여줄지는 텍스트로 구체적으로 정의하고, 어떻게 보여줄지는 레퍼런스를 활용해 AI가 임의로 채워야 할 영역을 줄이는 것이 중요했습니다. 결과를 반복해서 수정하기보다 처음부터 구체적인 인풋을 주는 편이 훨씬 효율적이었습니다.

Lessons Learned 3. 빠른 프로토타이핑을 아이디어 검토와 고도화의 반복에 활용할 수 있다.

화면으로 만들어보면 서비스의 핵심 가치가 충분히 드러나는지, 어떤 정보가 부족한지, 실제 서비스 경험으로 연결했을 때 어색한 부분은 없는지를 더 구체적으로 살펴볼 수 있었습니다. 특히 AI를 활용하면 화면을 처음부터 직접 구현하는 것보다 훨씬 빠르게 대략적인 형태를 만들어볼 수 있기 때문에, 컨셉 → 프로토타입 → 검토 → 컨셉 보완의 과정을 부담 없이 반복해볼 수 있었습니다.

그래서 UX 리서처가 미래 서비스 컨셉을 만들 때도 AI 프로토타이핑을 단순한 화면 제작 도구가 아니라, 아이디어를 빠르게 눈에 보이는 형태로 만들어보고 다시 고도화하는 방법으로 활용해볼 수 있겠다고 느꼈습니다.

마치며

돌이켜보면 1편에서 다룬 AI Persona도, 이번 Figma Make를 활용한 프로토타이핑도 결국 고민하고 판단하는 주체는 사람이라는 점에서는 같았습니다.

AI Persona는 새로운 관점과 질문을 만들어주는 데 도움을 줬고, Figma Make는 생각한 내용을 빠르게 형태로 만들어 다시 바라보는 데 도움을 줬습니다. 하지만 그 결과를 어떻게 해석하고 무엇을 선택할지는 여전히 사람의 몫이었습니다.

그래서 중요한 것은 AI를 많이 사용하는 것이 아니라, 프로젝트의 단계와 목적에 맞춰 적재적소에 활용하는 것이라고 생각합니다. 퍼소나든 프로토타이핑이든 사람의 고민을 대신하기보다, 고민의 폭과 깊이를 더하고 결과물의 완성도를 높이는 데 활용하는 것이 AI를 잘 사용하는 방법이라고 느꼈습니다.

SEO와 GEO 운영 루틴

doworld — Mon, 21 Sep 2026 07:50:41 +0900

SEO/GEO는 발행으로 끝나지 않는다. 글을 올리고 색인되고 몇 주가 지나면 그때부터 운영이 시작된다.

어떤 글은 검색 결과에 보이지만 클릭되지 않는다. 어떤 글은 클릭은 오지만 전환이 없다. 어떤 글은 10위 근처에서 오래 멈춘다. 어떤 글은 예전에는 잘 됐지만 지금은 정보가 낡았다. 그리고 이제는 하나가 더 붙는다. 검색 결과에는 보이는데 AI 답변에는 전혀 언급되지 않을 수 있다.

그래서 운영 루틴은 검색 성과와 AI 답변 노출을 함께 본다.

검색 성과: 노출, 클릭, CTR, 순위, 전환, 색인
AI 답변 노출: 브랜드 언급, 인용 URL, 설명 정확도, 경쟁 브랜드, 수정 필요 항목

SEO가 검색 결과에서 발견되는 상태를 관리한다면, GEO는 AI 답변 안에서 브랜드와 콘텐츠가 어떻게 쓰이는지 확인하는 작업까지 포함한다.

새 글보다 기존 글이 먼저일 때가 많다

SEO를 시작하면 대부분 새 글을 더 쓰려고 한다. 하지만 실무에서는 기존 글 리라이트가 더 빠르게 성과를 만들 때가 많다.

이유는 단순하다.

이미 인덱싱되어 있다
이미 노출 데이터가 있다
어떤 쿼리로 보이는지 확인할 수 있다
제목 문제인지 본문 문제인지 판단할 힌트가 있다
내부 링크와 구조를 조금만 보강해도 개선 여지가 있다
AI 답변에서 잘못 설명되는 지점을 원문 수정으로 바로잡을 수 있다

새 글은 가설에 가깝다. 기존 글은 데이터가 있는 자산이다.

예를 들어 어떤 글이 월 5,000회 노출되는데 CTR이 0.5%라면 제목과 메타를 먼저 의심할 수 있다. 평균 순위가 9~15위 사이에 오래 있다면 본문 깊이, FAQ, 비교표, 내부 링크가 부족할 수 있다. AI가 브랜드를 잘못 설명한다면 공식 설명, FAQ, 제품 페이지, 외부 프로필 수정까지 검토할 수 있다.

리라이트는 문장을 예쁘게 다듬는 일이 아니다. 병목을 찾고 고치는 운영 작업이다.

SEO에서 먼저 볼 데이터

검색 성과를 볼 때는 적어도 네 가지를 확인한다.

1. Search Console

Search Console은 검색 성과를 보는 기본 창구다.

문서 단위로 아래 항목을 본다.

노출수
클릭수
CTR
평균 순위
실제 노출 쿼리
페이지별 성과
색인 상태

여기서 봐야 할 질문은 이것이다.

이 문서는 어떤 검색어에서 보이고 있고, 사용자는 왜 클릭하거나 클릭하지 않는가?

의도한 키워드와 실제 노출 쿼리가 다를 수 있다. AI SEO 전략을 노리고 쓴 글이 실제로는 ChatGPT 블로그 노출로 보인다면 본문을 조정할지, 별도 글을 만들지 판단한다.

2. GA4 또는 전환 데이터

검색 유입이 있다고 끝은 아니다. 들어온 사용자가 무엇을 하는지도 본다.

확인할 항목은 아래와 같다.

SEO 유입 후 체류와 참여
다음 페이지 이동
가입, 문의, 구매, 다운로드 같은 전환
CTA 클릭
문서별 전환 기여
이탈 구간

트래픽은 많지만 전환이 약한 글은 제목보다 다음 행동 설계가 문제일 수 있다. 내부 링크, CTA, 관련 사례, 제품 연결부를 다시 본다.

3. 실제 검색 결과

리라이트 전에는 검색 결과를 다시 본다. 예전에는 통하던 형식이 지금도 통한다는 보장은 없다.

확인할 것은 아래와 같다.

상위 문서가 가이드인지, 리스트인지, 비교표인지
FAQ, 영상, 포럼, 지도, 쇼핑 결과가 강해졌는지
경쟁 문서의 제목이 어떻게 바뀌었는지
상위 문서가 더 깊어졌는지
사용자 의도가 정보형에서 비교형이나 거래형으로 이동했는지

검색 결과가 바뀌었는데 기존 문서 구조를 그대로 두면 밀릴 수 있다.

4. 사이트 구조와 기술 상태

문서 자체가 괜찮아도 사이트 구조 때문에 성과가 안 날 수 있다.

확인할 항목은 아래와 같다.

내부 링크가 충분한가
허브 문서에서 연결되는가
같은 키워드를 노리는 문서가 여러 개인가
canonical이 올바른가
중복 URL이 있는가
색인 제외나 noindex 문제가 있는가
페이지 속도와 모바일 표시가 괜찮은가

특히 캐니벌라이제이션은 제목 수정으로 해결되지 않는다. 문서 역할을 다시 나누거나 통합한다.

AI 답변 노출도 따로 기록한다

GEO 운영에는 AI 답변 테스트가 들어간다. 아직 Search Console처럼 표준화된 대시보드는 없다. 그래서 직접 질문을 정하고 반복 관찰한다.

테스트 질문은 세 종류로 나누면 좋다.

질문	유형예시
카테고리 추천	SEO/GEO 분석 도구 추천해줘
문제 해결	AI 답변에 브랜드가 나오게 하려면 무엇을 봐야 해?
브랜드 확인	GEONIQ은 어떤 서비스야?
비교 질문	GEONIQ과 일반 SEO 도구는 뭐가 달라?
출처 질문	SEO/GEO를 배울 만한 신뢰할 자료 알려줘

기록 양식은 단순하면 된다.

질문 / 플랫폼 / 날짜 / 브랜드 언급 여부 / 인용 URL / 설명 정확도 / 경쟁 브랜드 / 수정 필요 액션

확인할 항목은 아래와 같다.

우리 브랜드가 언급되는가
설명이 맞는가
출처로 어떤 URL이 쓰이는가
경쟁 브랜드는 누구인가
오래된 정보나 잘못된 설명이 있는가
답변에 필요한 원문이 우리 사이트에 있는가

AI 답변은 매번 달라질 수 있다. 한 번의 결과만 보고 결론을 내리면 안 된다. 같은 질문을 같은 조건으로 반복해서 보고, 변화 추세를 기록한다.

리라이트가 필요한 신호

모든 글을 계속 고칠 필요는 없다. 먼저 신호를 본다.

신호	의미	먼저 볼 것
노출은 높은데 CTR이 낮다	보이지만 클릭되지 않음	제목, 메타, 검색 의도
6~20위권에 오래 머문다	보강 여지가 있음	본문 깊이, 구조, 내부 링크
예전엔 좋았는데 하락한다	정보나 경쟁력이 낡음	최신성, 경쟁 문서, 검색 결과 변화
실제 노출 쿼리와 본문이 어긋난다	의도 불일치	제목, H2 구조, 문서 목적
비슷한 문서끼리 충돌한다	내부 경쟁 가능성	문서 통합, 역할 재분배
AI가 브랜드를 잘못 설명한다	공식 정보와 외부 설명이 부족함	제품 설명, FAQ, 외부 프로필
AI 답변에 경쟁사만 나온다	답변 후보 신호가 약함	비교 문서, 외부 신뢰, 인용 가능한 원문

리라이트가 답이 아닌 경우도 있다.

발행한 지 얼마 안 돼 데이터가 너무 적다
기술 문제가 커서 문서 수정만으로 해결되지 않는다
기존 글을 고치기보다 별도 검색 의도의 새 문서가 낫다
비즈니스 가치가 낮아 고쳐도 얻을 것이 작다

운영은 고칠 글과 놔둘 글을 구분하는 일에서 시작한다.

리라이트 판단 기준

문제를 여섯 가지 중 어디에 넣을지만 정해도 수정 방향이 빨라진다.

문제	증상	먼저 고칠 것
CTR 문제	노출은 많은데 클릭이 낮다	Title, Meta Description, 서론 첫 문장
순위 정체	6~20위권에 오래 머문다	아웃라인, 소주제, 비교표, 예시, FAQ, 내부 링크
의도 불일치	실제 노출 쿼리와 문서 내용이 어긋난다	문서 목적, 제목, 서론, H2 구조
최신성 문제	예전엔 좋았지만 최근 하락한다	최신 정보, 사례, 스크린샷, 수정일, 관련 FAQ
구조 문제	길지만 읽기 어렵고 답이 늦다	초반 답변, H2/H3 재배치, 중복 삭제
AI 답변 설명 문제	AI가 브랜드를 빼거나 틀리게 설명한다	공식 설명, 제품 페이지, FAQ, 비교 문서, 외부 프로필

운영 글에서 필요한 것은 긴 리라이트 매뉴얼이 아니라, 어떤 문제를 어떤 수정으로 연결할지 정하는 기준이다.

우선순위는 기회와 가치로 정한다

모든 글을 다 고칠 수는 없다. 우선순위를 정한다.

간단한 기준은 아래와 같다.

우선순위 = 기회 크기 × 비즈니스 가치 × 개선 가능성

각 항목은 이렇게 보면 된다.

항목	질문
기회 크기	노출, 순위, 검색량, AI 답변 질문 수요가 충분한가
비즈니스 가치	가입, 문의, 구매, 브랜드 신뢰에 도움이 되는가
개선 가능성	제목, 구조, 내부 링크, 최신화, 공식 설명 수정으로 바뀔 여지가 있는가

우선순위가 높은 문서는 아래와 같다.

노출이 높은데 CTR이 낮은 문서
전환 가능성이 높은데 성과가 약한 문서
허브 문서인데 품질이 약한 문서
6~20위권에서 정체된 문서
하락세가 뚜렷한 문서
AI가 자주 답하는 질문과 연결된 문서
브랜드 설명 오류를 바로잡을 공식 문서

가장 약한 글부터 고치는 것은 좋은 운영이 아니다. 성과를 만들 가능성이 큰 글부터 고쳐야 한다.

주간, 월간, 분기 루틴으로 나눈다

운영 루틴은 복잡하면 오래가지 못한다. 주간, 월간, 분기로 나눈다.

주간 체크

주간에는 큰 사고와 빠른 변화를 본다.

신규 발행 문서 색인 여부 확인
급격한 하락 문서 확인
CTR이 비정상적으로 낮은 문서 확인
404, noindex, canonical 같은 기술 이슈 확인
내부 링크 누락 확인
AI 답변 테스트 질문 3~5개 확인
브랜드 설명 오류 여부 기록

주간 체크는 깊은 분석이 아니라 조기 경보에 가깝다.

월간 리포트

월간에는 문서 단위로 판단한다.

좋은 월간 리포트는 숫자 나열이 아니라 다음 액션을 정하는 문서에 가깝다.

기본 구조는 아래와 같다.

이번 달 변화
성과 좋은 문서
성과 저조한 문서
새로 떠오르는 쿼리
CTR 낮은 문서
순위 정체 문서
AI 답변 언급 변화
브랜드 설명 오류
리라이트 후보
기술 이슈
다음 달 액션

리포트 마지막에는 반드시 “다음 달에 무엇을 고칠 것인가”가 있다.

분기 점검

분기에는 개별 글보다 구조를 본다.

토픽 클러스터별 성과 점검
중복 문서 통합 판단
허브 문서 업데이트
내부 링크 구조 점검
오래된 문서 정리
브랜드 엔티티 설명 일관성 점검
AI 답변 테스트 질문 세트 갱신
경쟁 브랜드 변화 확인

SEO/GEO는 글 단위로 시작하지만 시간이 지나면 구조 관리가 된다. 분기 점검에서는 문서군 전체를 본다.

운영 로그를 남긴다

리라이트와 AI 답변 테스트는 기록이 없으면 반복 학습이 안 된다.

간단한 로그만 있어도 충분하다.

날짜	문서/질문	문제	수정	확인 지표	다음 확인일
2026-04-29	GEO란 무엇인가	AI 답변에서 브랜드 설명 누락	FAQ와 서비스 설명 보강	AI 언급 여부, 인용 URL	2026-05-13
2026-04-29	Technical SEO/GEO	CTR 낮음	Title, Meta 수정	CTR, 평균 순위	2026-05-13

수정한 날짜, 수정 이유, 기대한 변화, 다음 확인일을 남겨야 한다. 그래야 나중에 어떤 수정이 효과가 있었는지 볼 수 있다.

SEO/GEO 운영 루틴 요약

이 글에서는 운영 루틴의 뼈대만 남긴다.

주기	목적	핵심 확인
주간	조기 경보	신규 문서 색인, 급락, 404/noindex/canonical, AI 답변 오류
월간	문서별 개선	노출·클릭·CTR·순위, 전환, 리라이트 후보, 다음 달 액션
분기	구조 관리	토픽 클러스터, 중복 문서, 허브/내부 링크, 브랜드 설명 일관성

이 정도만 고정해도 SEO/GEO 운영은 일회성 발행에서 반복 개선으로 넘어간다.

GEONIQ으로 확인하면

GEONIQ이 SEO/GEO 운영에서 보려는 것은 검색 성과와 AI 답변 노출을 같은 루틴 안에서 확인하는 것이다.

검색 결과에서는 어떤 쿼리로 보이는가?
클릭과 전환은 이어지는가?
AI 답변에서는 브랜드가 언급되는가?
언급된다면 설명은 정확한가?
어떤 문서를 고치면 검색과 AI 답변 모두에 도움이 되는가?

이 질문을 주기적으로 보면 SEO/GEO는 일회성 발행이 아니라 운영 루틴이 된다.

정리

SEO/GEO는 계속 쓰는 일이 아니라 계속 고치는 일에 가깝다. 새 글을 발행하는 것도 필요하지만, 이미 데이터가 쌓인 글을 보고 병목을 고치는 일이 더 빠른 성과를 만들 수 있다.

검색 성과는 Search Console, GA4, 검색 결과, 기술 상태로 본다. AI 답변 노출은 브랜드 언급, 인용 URL, 설명 정확도, 경쟁 브랜드, 수정 필요 항목으로 본다.

운영 루틴은 복잡하면 오래가지 못한다. 주간에는 사고를 잡고, 월간에는 문서별 액션을 정하고, 분기에는 구조를 정리한다.

검색과 AI 노출을 함께 점검하려면

GEONIQ은 사이트 URL을 기준으로 검색 성과와 생성형 AI 답변 언급을 함께 확인한다. 순위와 트래픽만 보는 대신, 어떤 질문에서 브랜드가 언급되고 어떤 설명으로 인용되는지 운영 루틴 안에서 점검하는 데 초점을 둔다.

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

서비스 아이디어 발굴부터 프로토타입까지, AI와 함께 일해본 기록 - 1편

Haeun Choi — Mon, 14 Sep 2026 16:05:39 +0900

최근 흥미로운 프로젝트를 진행했습니다. 바로 일본 시장을 대상으로 스마트홈과 모빌리티 영역의 새로운 서비스 아이디어를 발굴하고, 이를 프로토타입으로 구체화하는 프로젝트였습니다.

프로젝트를 진행하면서 아이디어를 더 다양한 관점에서 바라보고, 빠르게 구체화하기 위해 AI를 두 가지 방식으로 활용해 봤습니다.

1. 아이데이션 단계에서 AI Persona를 활용해 보기
2. AI 기반 프로토타이핑 툴을 활용해 아이디어를 빠르게 화면으로 구체화하기

이번 편에서는 그중 첫 번째인 AI Persona를 아이디어 발굴과 고도화 과정에서 어떻게 활용했는지를 이야기해보려고 합니다. Figma Make를 활용해 프로토타입을 제작했던 경험은 2편에서 이어서 다뤄보겠습니다.

사용자 조사 없이 아이디어를 만들다가 부딪힌 장벽

보통 신규 서비스 아이디어를 만드는 프로젝트에서는 사용자 조사를 통해 사용자의 삶의 방식과 페인포인트, 니즈를 파악하고 이를 기반으로 아이데이션을 진행합니다.

이번 프로젝트에서도 데스크 리서치를 통해 기존 서비스에 대한 사용자들의 불편한 점, 만족하는 점, 기대하는 점 등을 파악했습니다. 하지만 실제 사용자를 직접 만나 이야기를 들으며 다양한 삶의 맥락이나 감정, 행동의 동기까지 이해할 수는 없었기 때문에 아이디어를 깊게 발전시키는 데 한계가 있었습니다.

수십 개의 시드 아이디어를 만든 뒤 다시 살펴보니 표현과 기능은 달라도 비슷한 페인포인트를 해결하는 아이디어가 반복되기 시작했습니다. 그러면서 두 가지 의문이 생겼습니다. 실제 일본 사용자들도 이 아이디어를 보고 가치를 정말 느낄까? 그들에게는 무엇이 필요할까?

팀원들끼리 계속 비슷한 자료를 보면서 아이디어를 만들다 보니 생각도 점점 비슷한 방향으로 모였습니다. 그렇다고 중간에 일본 사용자 조사를 새로 진행할 수도 없는 상황이었죠. 그래서 사용자 조사를 대체하려는 목적이 아니라, 우리의 사고를 조금 더 확장하고 다른 관점에서 아이디어를 바라보기 위한 도구로 AI Persona를 활용해 보기로 했습니다.

다른 삶의 시선을 담은 AI 퍼소나 만들기

AI Persona를 활용함으로써 팀이 얻고 싶었던 것은 “일본 사용자는 이렇게 생각할 것이다.”라는 답이 아니라,“이런 삶을 사는 사람이라면 이런 생각을 할 수도 있겠구나.”라는 관점이었습니다.

그래서 Persona를 정의할 때도 단순히 나이, 성별, 직업 같은 인구통계 정보만 넣지 않았습니다.

예를 들어,

맞벌이를 하며 혼자 귀가하는 어린 자녀의 안전을 걱정하는 사람
혼자 거주하는 고령의 부모를 떨어진 곳에서 원격으로 돌보는 사람
공동주택에 거주하며 EV로 장거리 통근하고 충전 문제를 자주 경험하는 사람

서로 다른 삶의 조건을 가진 퍼소나를 설정했습니다.

또한 주변 사람들에게 실제로 겪은 불편이나 걱정을 물어보거나, 뉴스 기사와 기존 사례에서 접한 생활 장면을 참고해 스마트홈과 모빌리티 관점에서 그 사람의 판단에 영향을 줄 만한 하나의 구체적인 스토리를 각 Persona에 추가했습니다.

실제 스토리를 바탕으로 현재 어떤 서비스를 사용하고 있는지, 신규 구독료에 얼마나 민감한지, 집 안 센서나 카메라에 어떤 거부감이 있는지, 앱이 하나 더 생기는 것을 얼마나 귀찮아하는지, 평소 어떤 문제를 가장 큰 스트레스로 느끼는지 등 실제 의사결정에 영향을 줄 수 있는 조건들까지 구체적으로 정의했습니다.

답변 방식 역시 구체적으로 설계했습니다. 단순히 “이 기능은 좋습니다.” “프라이버시가 걱정됩니다.”라고 결론만 말하지 않도록 프롬프트를 작성했습니다. 대신 모든 판단에 구체적인 생활 장면이나 과거 경험을 근거로 포함하도록 프롬프트를 설계했습니다.

예를 들어 프라이버시가 걱정된다고 답한다면, 예전에 홈카메라 설치를 고민했다가 가족의 거부감 때문에 포기했던 경험처럼 왜 그런 판단을 하게 됐는지 그 사람의 생활 맥락까지 함께 설명하도록 했습니다.

즉, 팀이 퍼소나 의견을 읽으면서 “아, 이 사람은 이런 삶을 살아서 이렇게 생각하는구나.”라고 이해할 수 있도록 했습니다. 결국 Persona를 그럴듯하게 만드는 것보다, 그 사람이 어떤 삶을 살고 있고 왜 그런 판단을 하는지를 함께 볼 수 있는 툴을 만들고자 했습니다.

AI Persona의 시선을 빌려 아이디어 고도화의 힌트 찾기

이렇게 만든 Persona에게 실제 아이디어를 넣고 의견을 받아본 뒤, 결과를 아이디어 고도화를 위한 참고자료로 활용했습니다.

특히 도움이 됐던 부분은 크게 세 가지였습니다.

1. 실제 이용자 관점에서 서비스 수용성 점검

예를 들어 아이의 안전한 귀가를 지원하기 위해 학원 버스에서 내린 아이를 순찰 로봇이 집까지 에스코트하는 아이디어가 있었습니다.

처음 저희가 생각했던 핵심 가치는 명확했습니다. 아이 혼자 이동하는 구간에서 유괴나 납치 등의 위험을 줄이고, 보호자에게는 아이가 안전하게 귀가하고 있다는 안심을 주는 것이었습니다.

그런데 맞벌이 부모 Persona에게 이 아이디어를 보여주자 이런 반응이 나왔습니다.

“'학원 버스 하차장에서 세대 엘리베이터까지 순찰 로봇이 에스코트'라는 문구에서 바로 멈췄다. 딸이 로봇 옆에서 걷는 걸 부끄러워하거나 친구들이 놀리면 안 쓰려고 할 것 같다는 생각이 들었다. 초등 2학년은 부모가 좋다고 해도 본인이 싫으면 가방에 태그를 안 달고 나간다.”

팀에서는 당시 서비스의 가치를 아이의 안전을 높이는 것에 집중해서 보고 있었습니다. 로봇이 함께 걸어주면 부모는 안심할 수 있고, 위험 상황도 줄일 수 있으니 당연히 사용할 것이라는 다소 단순한 가정도 있었죠.

하지만 실제 서비스를 사용하는 사람은 부모가 아니라 아이였습니다. 부모에게는 안심되는 기능이어도, 아이가 친구들의 시선을 의식하거나 함께 걷는 경험 자체를 부담스럽게 느낀다면 서비스는 결국 사용되지 않을 수 있습니다. 즉, 보호자에게 전달되는 가치만 보고 실제 이용자의 수용성을 놓치고 있었다는 점을 다시 생각하게 됐습니다.

그래서 로봇이 항상 아이와 함께 이동하는 것을 기본 경험으로 두기보다, 평소에는 이동 상태를 확인하고 필요할 때만 로봇 에스코트를 요청할 수 있는 방향으로 아이디어를 조정했습니다.

2. 신규 기능이 유발할 수 있는 새로운 불안 요인 발견

또 같은 Persona는 과거 아이의 GPS 위치가 건물 안에서 튀면서 실제로는 학교에 있는데 학교 밖으로 이동한 것처럼 보여 괜히 담임에게 연락할 뻔했던 경험을 이야기했습니다.

여기서도 한 가지 힌트를 얻을 수 있었습니다. 안전 서비스라고 해서 정보를 많이 보여주고 알림을 많이 줄수록 과연 좋은 것일까? 란 질문을 던지게 됐죠.

위치나 경로 변화가 있을 때마다 알림을 보내면 오히려 부모가 하루 종일 아이의 위치를 확인하며 불안해질 수도 있었습니다. 안전을 위해 만든 서비스가 오히려 부모의 불안을 계속 자극하는 서비스가 될 수도 있다는 생각을 하게 되었습니다.

그래서 실시간 위치를 계속 보여주기보다 정상 이동, 지연, 경로 이탈, 도착 완료와 같이 상태 중심으로 정보를 제공하고, 평소와 다른 상황에서만 확인이 필요한 구조를 고민하게 됐습니다.

그렇다고 AI Persona의 말을 그대로 기능으로 반영한 것은 아니었습니다. 다만 이런 의견을 통해 “우리가 만든 방식이 오히려 새로운 불편을 만들고 있지는 않은가?” “이 기능이 실제 생활에서 사용되기 위해서는 어떤 조건이 필요한가?”를 다시 생각하며 아이디어의 방향이나 컨셉을 고도화하고 다듬어나갔습니다.

3. 지불 의사를 통해 적절한 ‘서비스의 형태’를 고민

Persona에게 지불 의사에 대해서도 물어봤습니다. “월 몇 엔까지 낼 수 있다”는 숫자 자체를 활용하려는 목적은 아니었고, 오히려 왜 별도 비용을 낼 수 있는지, 왜 별도 구독이라면 부담스럽다고 느끼는지를 참고했습니다.

예를 들어 어떤 Persona는 한 아이디어에 대해 별도 앱 기반의 구독 서비스라면 과하지만, 공동주택 전체에 제공되는 공용 인프라라면 수용할 수 있다고 판단했습니다.

이런 의견을 보면서 “애초에 이 아이디어를 사용자가 직접 가입하는 별도 서비스로 제공하는 것이 맞을까?”라는 질문을 하게 됐습니다.

사용자가 매달 직접 비용을 내고 이용하는 서비스가 적합한지, 아니면 공동주택의 안전이나 이동처럼 거주 환경에 기본적으로 포함되는 인프라 형태가 더 자연스러운지 다시 검토하게 됐습니다. 즉, Persona의 지불 의사는 가격을 정하기 위한 자료라기보다 서비스를 어떤 형태로 제공해야 하는지를 생각해 보기 위한 단서로 활용했습니다.

AI Persona를 ‘답’보다 ‘질문’에 활용하기

사실, AI Persona를 활용하면서 처음엔 “이게 사용자 조사를 대체할 수 있을까?” “과연 얼마나 도움이 될까?”하는 의문이 가득했습니다. Persona가 이야기한 생활 경험이나 과거 에피소드는 실제 누군가에게 일어난 일이 아니라, 우리가 설정한 조건을 바탕으로 AI가 만들어낸 가정인데 이걸 어떻게 믿고 활용할 수 있을까가 계속 걱정이었죠.

그런데 막상 활용해 보니, AI Persona의 가치는 ‘정답을 알려주는 것’보다 막혀 있던 사고를 다른 방향으로 돌리고, 새로운 관점과 질문을 만들어주는 데 있었습니다. 그래서 이번에는 AI Persona를 활용하면서 배우고 느낀 점을 세 가지로 정리해보려고 합니다.

Lessons Learned 1. 가정 기반 퍼소나는 시드 아이디어 단계에서 사고를 확장하는데 도움이 된다.

AI Persona에도 여러 유형과 활용 방식이 있지만, 이번처럼 가정을 기반으로 만든 Persona는 시드 아이디어를 발굴하고 고도화하는 초기 단계에서 관점과 사고를 넓히는 데 유용했습니다.

실제 사용자를 만나기 어려운 상황에서 “이런 삶을 사는 사람이라면 어떻게 생각할까?”를 빠르게 가정해 보며, 놓친 사용 장면이나 우려 요인을 발견하고 아이디어를 가볍게 점검할 수 있었습니다.

다만 이들은 실제 사용자가 아니기 때문에, Persona의 의견이나 지불 의사·선호도를 실제 사용자 데이터처럼 받아들이거나 이를 근거로 아이디어 방향을 결정하는 것은 위험하다고 생각됩니다.

결국 가정 기반 Persona는 답을 얻기보다, 우리가 미처 생각하지 못한 방향까지 사고의 범위를 넓히는 용도로 활용할 때 가장 효과적이지 않을까 싶습니다.

Lessons Learned 2. 아이디어에 대한 단순 ‘좋다/싫다’ 평가보다 왜 그렇게 생각하는지를 볼 수 있게 설계하는 것이 중요하다.

Persona에게 단순히 “이 아이디어에 점수 몇 점 주실래요?”, “얼마까지 지불할 수 있나요?”라고 물었다면 아이디어를 발전시키는 데 활용하기 어려운 답이 나왔을 것 같습니다.

오히려 유용했던 것은 왜 그렇게 판단했는지, 그 사람의 생활 맥락까지 함께 드러나도록 프롬프트를 설계한 것이었습니다. 판단의 배경을 알아야 그 안에서 어떤 기능을 바꿀지, 무엇을 줄일지, 어떤 방식으로 제공할지에 대한 힌트를 얻을 수 있었기 때문입니다.

결국 구체적인 답변을 얻기 위한 설계가 중요한 이유는 더 그럴듯한 가상 사용자를 만들기 위해서가 아니라, 그 판단이 나온 맥락을 이해하고 아이디어를 다시 바라보기 위한 재료를 얻기 위해서입니다.

Lessons Learned 3. 결국 고민하고 판단하는 것은 사람이 해야 한다.

AI Persona를 활용한다고 해서 아이디어 고도화까지 AI에게 맡길 수 있었던 것은 아닙니다. Persona가 새로운 우려를 이야기했다고 해서 기능을 바로 추가하지도, 어떤 기능을 싫어한다고 해서 곧바로 삭제하지도 않았습니다.

결과는 어디까지나 아이디어를 다시 바라보기 위한 하나의 참고자료로만 활용했습니다. 그 의견이 실제로 중요한 문제인지, 아이디어의 핵심 가치와 충돌하지는 않는지, 그렇다면 어떤 방식으로 풀어내는 것이 적절한지는 결국 팀이 다시 판단하고 고민해야 했습니다.

돌이켜보면 AI Persona가 가장 크게 도와준 부분은 “이 아이디어는 이렇게 고치세요”라고 답을 주는 것이 아니라, “이런 점은 생각해 봤나요?”라고 새로운 질문을 던져준 것이란 생각이 듭니다.

마치며

개인적으로는 이번 경험 전까지 AI Persona 활용에 꽤 회의적인 편이었습니다. 하지만 직접 활용해 보면서 생각이 많이 바뀌었습니다. AI Persona가 무엇을 대신 해주는 도구인지보다, 어떤 목적으로 써야 하고 어떤 상황에서 특히 효과적인지를 확실히 체감할 수 있었습니다.

앞으로 비슷한 프로젝트를 진행한다면, AI Persona를 활용해 아이디어 초기 단계에서 익숙한 관점에 갇히지 않았는지 점검하고, 놓친 질문을 찾아보는 데 다시 활용할 것 같습니다.

다음 편에서는 두 번째 제약이었던 ‘디자이너 없이 리서처들이 프로토타입까지 만들어야 했던 상황’에서 Figma Make를 어떻게 활용했는지, 그리고 실제로 사용해 보며 얻은 경험과 인사이트를 이어서 나눠보겠습니다.

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