검색되는 FAQ는 세 가지가 한 섹션에 겹쳐 있습니다 — ① 즉시 검색(UX 필터)으로 사람이 답을 빨리 찾고, ② answer block(카피)으로 한두 문장 직답을 주고, ③ FAQPage 스키마(SEO/GEO)로 그 답을 검색·AI가 그대로 읽습니다. 화면의 답과 스키마의 답은 반드시 1:1로 같아야 합니다.
요약
- FAQ 섹션은 UX·카피·SEO·GEO가 동시에 일하는 보기 드문 합작 지점이다.
- 질문이 많으면 즉시 검색(필터)을 넣어 ‘환불’ 한 단어로 답을 좁힌다.
- answer block은 결론을 먼저, 한두 문장으로 — 사람도 AI도 인용하기 쉽게.
- FAQPage 스키마는 리치 결과를 보장하지 않지만 AI 인용 가능성을 크게 높인다. 화면=스키마 1:1 필수.
FAQ를 만들어 달라는 요청은 거의 항상 “질문이랑 답이랑 쭉 적어주세요”로 옵니다. 그런데 저희는 FAQ 섹션 하나를 만들 때 네 명이 모입니다. UX 담당은 “이 목록이 20개면 사람이 어떻게 자기 질문을 찾지?”를 걱정하고, 카피 담당은 “답을 몇 문장으로 끊어야 읽고 바로 행동할까”를 고민하고, SEO/GEO 담당은 “이 답을 구글과 ChatGPT가 그대로 가져가게 하려면 어떤 구조여야 하나”를 봅니다. 같은 섹션을 서로 다른 눈으로 보는 거죠. 그래서 FAQ는 저희에게 ‘조합 작품’입니다.
왜 FAQ가 네 사람의 합작 지점인가요?
대부분의 섹션은 한 직군이 주도합니다. 히어로는 카피와 디자인, 폼은 개발과 UX 식입니다. 그런데 FAQ는 다릅니다. 같은 질문·답 데이터가 사람이 읽는 화면, 검색엔진이 읽는 스키마, AI가 인용하는 답으로 동시에 쓰입니다. 한 군데를 잘못 짜면 나머지가 다 무너집니다. 그래서 처음부터 네 관점을 겹쳐 설계해야 합니다.
사람은 어떻게 답을 빨리 찾나요? (UX)
질문이 5개면 그냥 펼쳐두면 됩니다. 하지만 15개, 30개가 되면 사람은 자기 질문을 찾다가 지칩니다. 그래서 검색 입력을 답니다. ‘배송’만 쳐도 관련 질문만 남도록요. 아래에서 직접 해보세요.
검색되는 FAQ (필터+스키마)
'배송', '환불' 등을 입력해 즉시 걸러보세요.
{ "@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"배송은 얼마나 걸리나요?","acceptedAnswer":{"@type":"Answer","text":"평일 기준 2~3일."}}] }
위 위젯에는 두 가지가 같이 들어 있습니다. 사람이 쓰는 검색 필터, 그리고 검색·AI가 읽는 FAQPage 스키마. 화면에 보이는 질문과 스키마의 질문이 같은 데이터에서 나오는 게 핵심입니다.
답은 어떻게 써야 하나요? (카피 · answer block)
긴 답은 사람도 AI도 싫어합니다. 저희는 질문 바로 아래에 한두 문장짜리 직답(answer block)을 둡니다. 결론을 먼저 쓰고, 필요하면 부연을 그다음에. 이렇게 하면 사람은 스크롤 없이 답을 보고, AI 답변 엔진은 그 문장을 통째로 인용하기 좋습니다. “상황에 따라 다릅니다”로 시작하는 답은 사람도 AI도 가져갈 수 없습니다.
검색·AI는 답을 어떻게 가져가나요? (SEO/GEO · 스키마)
FAQPage 스키마는 “이건 질문이고, 이건 그 답이다”를 기계가 정확히 읽게 하는 표시입니다. 구글은 이를 읽어 검색 결과에 답을 직접 보여주기도 하고, AI 답변 엔진은 이 구조를 신뢰해 답을 인용합니다. 단, 스키마가 있다고 리치 결과가 보장되지는 않습니다. 노출 여부는 검색엔진 정책에 달렸습니다. 스키마는 ‘가능성’을 높이는 도구입니다.
화면의 답과 스키마의 답이 달라도 되나요?
절대 안 됩니다. 사용자가 보는 답과 스키마의 답은 1:1로 같아야 합니다. 검색엔진은 화면 콘텐츠와 구조화 데이터의 일치를 요구하고, 다르면 스팸으로 간주해 불이익을 줄 수 있습니다. 그래서 저희는 답을 한 곳(데이터)에서 만들어 화면과 스키마에 같이 흘려보냅니다. 사람을 위한 답과 기계를 위한 답을 따로 쓰지 않습니다.
이 합작이 실제로 무엇을 바꾸나요?
세 가지가 겹치면 결과가 달라집니다. 사람은 검색으로 답을 빨리 찾고(이탈 감소), AI 답변 엔진은 짧은 직답을 인용하고(노출 가능성 증가), 같은 질문으로 들어오던 전화·메일이 줄어듭니다(문의 감소). 한 섹션을 네 관점으로 설계했기 때문에 가능한 일입니다.
그래서 FAQ는 ‘목록’이 아니라 ‘인터페이스’입니다
FAQ를 단순한 텍스트 묶음으로 보면 셋 중 하나만 챙기게 됩니다. 사람만 챙기면 AI가 못 읽고, 스키마만 챙기면 사람이 답을 못 찾습니다. 네 관점을 처음부터 겹쳐 설계할 때, FAQ는 사람과 AI 모두에게 답을 주는 인터페이스가 됩니다.
이 작품에 들어간 기술
이 FAQ 섹션 하나에는 Findable이 따로 다루는 세 가지 기술이 겹쳐 있습니다. 각각을 더 깊이 보고 싶다면:
- 검색 UX(즉시 필터) — 입력 즉시 목록을 좁히는 인터페이스. 검색·필터 인터랙션 노트
- answer block(직답 카피) — 사람도 AI도 인용하는 한두 문장 직답. answer block 작성법
- FAQPage 스키마(SEO/GEO) — 질문·답을 기계가 읽게 하는 구조화 데이터. FAQ 스키마 설계
같은 FAQ 데이터를 네 담당이 각자 무엇으로 바꾸는지 이렇게 정리합니다.
| 담당 | 이 모듈에서 한 일 |
|---|---|
| 검색 UX | 입력창에 ‘배송·환불’을 치면 관련 질문만 즉시 남도록 목록을 실시간 필터링 |
| answer block 카피 | 결론을 먼저, 한두 문장으로 끊어 사람도 AI도 통째로 인용하게 작성 |
| FAQPage 스키마 | 화면의 질문·답을 1:1로 옮긴 구조화 데이터로 검색·AI가 답을 그대로 읽게 함 |
| 데이터 일치 기준 | 화면=스키마를 한 데이터에서 흘려보내 불일치 스팸 페널티를 차단 |
이 한 섹션에 실제로 겹쳐 들어간 기술은 다음과 같습니다.
| 항목 | 긴 FAQ 목록 | 검색+스키마 FAQ |
|---|---|---|
| 사람이 답 찾기 | 긴 목록을 위아래로 훑음 | 한 단어 입력 → 즉시 좁힘 |
| AI 인용 | 구조 없어 통째로 인용 어려움 | 스키마+직답으로 인용 쉬움 |
| 반복 문의 | 같은 질문 전화·메일 반복 | 검색 가능한 직답으로 감소 |
| 화면=데이터 | 스키마 따로면 불일치 위험 | 한 데이터에서 화면·스키마 동시 |
FAQ 섹션에 검색 기능을 꼭 넣어야 하나요?
FAQPage 스키마를 넣으면 검색 결과에 답이 바로 보이나요?
answer block은 무엇이고 왜 짧게 써야 하나요?
FAQ 화면에 보이는 답과 스키마의 답이 달라도 되나요?
FAQ 섹션이 고객 문의를 정말 줄여주나요?
FAQ 스키마 설계
FAQPage 구조화 데이터를 정확히.
검색·필터 인터랙션 노트
입력 즉시 좁히는 인터페이스.
answer block 작성법
사람도 AI도 인용하는 직답.
이 글의 검색 필터와 스키마 위젯은 이 페이지에서 실제로 동작하는 코드입니다(외부 라이브러리 0). FAQPage 스키마의 답은 화면 텍스트와 1:1로 같아야 하며, 스키마는 리치 결과·AI 인용을 보장하지 않고 가능성을 높이는 도구입니다. 날조된 사례·수치는 사용하지 않았습니다.