개원 초기 법률사무소 홈페이지에서 가장 아깝게 버려지는 자산은 상담 FAQ입니다. 대표 변호사는 이미 실제 상담에서 반복되는 질문 20~30개를 알고 있습니다. 그런데 그 질문들은 대부분 "자주 묻는 질문" 아코디언 안에 평범한 텍스트로만 들어가 있습니다. 사람이 읽기에는 충분하지만, 크롤러와 답변 엔진 입장에서는 이 페이지에 질문-답변 쌍이 존재한다는 사실을 확신할 근거가 없습니다.
AEO(Answer Engine Optimization)는 이 지점에서 갈립니다. 목표가 "우리 페이지로 클릭을 끌어오는 것"에서 "질문에 대한 답의 출처로 인용되는 것"으로 바뀌기 때문입니다. 구글 AI Overview, People Also Ask, 그리고 각종 LLM 챗봇은 페이지 전체를 읽고 순위를 매기는 대신 답이 될 만한 문단(패시지) 단위를 뽑아 씁니다. 뽑히기 쉬운 형태로 미리 잘라 두는 것이 FAQPage 구조화 데이터의 역할입니다.
이 글은 웨비스튜디오가 법무법인·법률사무소 홈페이지를 만들 때 실제로 적용하는 FAQ 스키마 설계 기준을 정리한 것입니다. 질문을 고르는 방법, JSON-LD 형태와 리치결과 자격의 현재 상태, answer-first 문장 설계, 그리고 변호사 광고 규제상 스키마에 절대 넣지 않는 문장까지 다룹니다.
1. 질문은 상상하지 말고 검색 수요에서 캐낸다
FAQ를 만들 때 가장 흔한 실패는 사무실 안에서 회의로 질문을 짜내는 것입니다. 그렇게 만든 질문은 "저희 사무소의 강점은 무엇인가요" 같은 자기소개형이 되기 쉽고, 실제 검색어와 표현이 어긋나 매칭되지 않습니다. 질문은 발명하는 것이 아니라 수집하는 것입니다.
| 수집 소스 | 얻는 것 | 판단 포인트 |
|---|---|---|
| Search Console 쿼리 보고서 | 이미 노출 중인 실제 질문형 쿼리 | 노출은 있는데 CTR이 낮은 질문 = 답이 페이지에 없다는 신호 |
| PAA(People Also Ask) 박스 | 구글이 인정한 연관 질문 집합 | 펼칠 때마다 확장되므로 2~3단계까지 기록 |
| 검색 자동완성 | 사용자가 실제로 타이핑하는 어순 | 문어체로 다듬지 말고 어순을 살릴 것 |
| 상담 전화·문의 폼 로그 | 검색 도구에 안 잡히는 실무 질문 | 개인정보 제거 후 질문 유형만 추출 |
| 지식iN·커뮤니티 질문글 | 비전문가의 어휘와 오해 지점 | 표현을 그대로 베끼지 말고 질문 의도만 채택 |
수집한 질문은 세 가지 기준으로 거릅니다.
- 질문형인가. "이혼 재산분할"은 키워드지 질문이 아닙니다. FAQ에는 "이혼할 때 재산분할 비율은 어떻게 정해지나요?"처럼 물음표로 끝나는 형태만 넣습니다.
- 답이 사실·절차·요건으로 끝나는가. 답변이 "사안에 따라 다르니 상담받으세요"로만 귀결되는 질문은 스키마에 넣어도 인용 가치가 없습니다. 기간, 요건, 절차 순서, 필요 서류처럼 확정 가능한 정보가 답의 중심에 있어야 합니다.
- 우리 취급 업무 범위인가. 취급하지 않는 분야의 질문으로 트래픽을 모으면 문의 품질이 떨어지고, 표시 가능한 사실(주요 취급 업무)과도 어긋납니다.
여기서 반드시 버려야 할 질문 유형이 있습니다. "어느 변호사가 잘하나요", "승소 가능성이 얼마나 되나요", "어디가 더 저렴한가요" 같은 질문입니다. 검색 수요는 분명히 존재하지만, 답변이 성립하려면 비교·결과 예측·수임 유인이 들어가야 하므로 변호사 광고 규제와 정면으로 충돌합니다. 수요가 있다는 이유만으로 스키마에 넣으면 안 됩니다.
2. FAQPage JSON-LD의 실제 형태와 리치결과 자격
schema.org의 FAQPage는 구조가 단순합니다. FAQPage 안에 mainEntity로 Question 배열이 들어가고, 각 Question은 정확히 하나의 acceptedAnswer를 가집니다.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "상속포기는 언제까지 신청해야 하나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "상속포기는 상속개시가 있음을 안 날부터 3개월 이내에 가정법원에 신고해야 합니다. 이 기간을 특별한 사유 없이 넘기면 단순승인한 것으로 보아 채무도 함께 승계됩니다. 상속재산 조회에 시간이 필요하면 같은 기간 안에 기간 연장을 청구할 수 있습니다."
}
}
]
}
여기서 리치결과 자격에 대해 현재 상태를 정확히 알고 시작해야 합니다. 구글은 2023년 8월 FAQ 리치결과 표시를 정부·보건 분야 등 일부 신뢰도 높은 사이트로 제한했습니다. 즉 일반 법률사무소 홈페이지가 FAQPage 마크업을 넣었다고 해서 검색결과에 접히는 FAQ 스니펫이 나오는 경우는 거의 없습니다. 이 사실을 모른 채 "리치결과가 안 나온다"며 마크업을 걷어내는 곳이 많은데, 그건 잘못된 판단입니다. 마크업을 유지하는 이유는 별표 스니펫이 아니라 다음 세 가지입니다.
- 기계 판독 가능한 Q&A 쌍 제공. AI Overview와 LLM 크롤러는 HTML 파싱보다 구조화 데이터에서 질문-답변 경계를 훨씬 확실하게 인식합니다.
- 답변 경계의 명시. 어디까지가 하나의 답인지 표시해 두면 문단이 잘못 잘려 인용되는 위험이 줄어듭니다.
- 정책 변화 대비. 자격 조건은 구글 정책에 따라 바뀝니다. 스키마가 없으면 정책이 바뀌어도 후보에 들어가지 못합니다.
FAQPage와 QAPage를 혼동하면 안 됩니다.
| 구분 | FAQPage | QAPage |
|---|---|---|
| 질문 작성자 | 사이트 운영자 | 사용자(방문자) |
| 답변 개수 | 질문당 1개(acceptedAnswer) | 여러 개 + 투표 |
| 법률사무소 홈페이지 | 여기에 해당 | 해당 없음 |
Q&A 게시판을 운영하더라도 방문자가 직접 질문을 올리는 구조가 아니라면 QAPage가 아닙니다. 잘못된 타입을 쓰면 유효성 검사에서 걸립니다.
3. AI Overview가 답을 가져가는 방식과 answer-first 문장 설계
AI Overview와 PAA는 페이지 전체를 요약하지 않습니다. 질의와 의미적으로 가장 가까운 짧은 단락을 골라 그대로 쓰거나 살짝 다듬어 씁니다. 그래서 답변의 첫 문장 한 줄이 전부입니다. 첫 문장이 결론이 아니면 그 답변은 후보에서 밀립니다.
웨비스튜디오가 쓰는 규칙은 네 가지입니다.
- 첫 문장에 결론을 넣는다. 40~70자 안에서 답이 끝나야 합니다. 배경 설명, 법 취지, "많은 분들이 궁금해하시는데" 같은 도입부는 첫 문장에 오면 안 됩니다.
- 숫자와 요건을 문장 안에 박는다. "3개월 이내", "가정법원", "필요 서류 3종"처럼 구체값이 문장 안에 있어야 인용 시 정보가 살아남습니다.
- 대명사를 쓰지 않는다. "이 경우", "그것은"으로 시작하면 문단이 분리 추출될 때 맥락이 사라집니다. 매번 주어를 다시 씁니다.
- 답변 하나가 독립적으로 성립하게 쓴다. 앞 질문을 읽어야 이해되는 답변은 쓰지 않습니다.
| 나쁜 예 | 좋은 예 |
|---|---|
| "이 부분은 사안마다 달라 일률적으로 말씀드리기 어렵습니다. 다만 실무상…" | "상속포기 신고 기한은 상속개시를 안 날부터 3개월입니다. 다만 상속재산 조사에 시간이 필요하면 같은 기간 안에 연장을 청구할 수 있습니다." |
| "그것은 법원의 판단 사항입니다." | "재산분할 비율은 혼인 기간, 재산 형성 기여도, 부양적 요소를 종합해 법원이 정합니다." |
분량은 답변당 24문장, 200400자 정도가 실무적으로 안정적입니다. 너무 짧으면 정보량이 부족해 인용 가치가 없고, 너무 길면 앞부분만 잘려 나가면서 조건절이 떨어집니다.
4. 화면 텍스트와 구조화 데이터는 어긋나면 안 된다
구조화 데이터의 제1원칙은 화면에 보이는 내용과 일치입니다. 화면에 없는 질문을 JSON-LD에만 넣거나, 화면에는 요약만 두고 스키마에는 다른 문장을 넣는 것은 스팸 정책 위반이며 수동 조치 대상이 될 수 있습니다.
이걸 사람의 주의력으로 막으려 하면 반드시 실패합니다. 내용을 고칠 때 화면과 스키마 두 군데를 동시에 고쳐야 하는 구조 자체가 문제이기 때문입니다. 웨비스튜디오는 데이터 객체 하나를 단일 출처로 두고 화면과 JSON-LD를 같은 배열에서 렌더링합니다.
const faq = [
{ q: "상속포기는 언제까지 신청해야 하나요?", a: "상속포기는 …" },
];
// 화면 렌더와 JSON-LD가 같은 배열을 소비한다
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: serializeJsonLd({
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faq.map((item) => ({
"@type": "Question",
name: item.q,
acceptedAnswer: { "@type": "Answer", text: item.a },
})),
}),
}}
/>
모든 JSON-LD는 serializeJsonLd를 거칩니다. 구현은 한 줄입니다. JSON.stringify(value).replace(/</g, '\\u003c') — 직렬화 결과에 들어간 < 문자를 유니코드 이스케이프로 바꿔 </script> 시퀀스가 스크립트 블록을 조기 종료시키는 문제를 막습니다. 법률 콘텐츠는 인용문이나 조문 표기에 꺾쇠가 들어가는 일이 잦아서, 이 한 줄이 없으면 특정 글에서만 스키마가 통째로 깨지는 사고가 납니다.
구조화 데이터는 검색엔진과 답변 엔진이 페이지 내용을 정확히 이해하도록 돕는 장치일 뿐입니다. 마크업을 추가한다고 해서 검색 노출, AI 답변 인용, 클릭, 상담 문의가 보장되지는 않습니다. 노출 순위와 인용 여부는 각 플랫폼의 알고리즘과 정책에 따라 달라지며, 이 글은 특정 결과를 약속하지 않습니다.
5. 랜딩 팩토리에 FAQ를 얹을 때의 doorway 함정
웨비스튜디오는 지역·분야별 검색의도 랜딩을 데이터 객체 1개 + 공통 React 템플릿으로 생성합니다. 템플릿 하나를 고치면 N개 페이지가 함께 개선되고, 페이지를 늘릴 때 코드가 아니라 데이터만 추가하면 됩니다.
이 구조에서 FAQ는 가장 위험한 부품입니다. 편의상 FAQ 배열을 공통 상수로 빼서 모든 지역 페이지에 같은 6개 질문을 뿌리면, 그 순간 페이지들은 본문만 조금 다른 얇은 중복 페이지가 됩니다. 구글이 doorway 페이지로 판단하는 전형적인 형태입니다. 그래서 규칙을 못박아 둡니다.
- 각 페이지는 고유 데이터를 가진다. FAQ 질문·답변은 그 지역/분야의 실제 검색 수요에서 뽑는다.
- 각 페이지는 고유 canonical을 가진다. 템플릿 공유가 canonical 공유를 의미하지 않는다.
- 각 페이지는 고유 JSON-LD를 가진다. 그 페이지 화면에 실제로 보이는 Q&A만 마크업한다.
- 지역명만 치환한 문장은 고유 데이터가 아니다. 관할 법원, 절차 소요 기간처럼 실제로 달라지는 정보가 없으면 그 페이지는 만들지 않는다.
공통 템플릿의 목적은 페이지 수를 늘리는 게 아니라 페이지마다 다른 내용을 일정한 품질로 담는 것입니다. 채울 고유 정보가 없으면 페이지를 만들지 않는 편이 낫습니다.
6. 기계 판독 경로를 열어 둔다
FAQ 스키마는 크롤러가 페이지에 도달해야 의미가 있습니다. 웨비스튜디오 사이트는 세 가지 경로를 함께 운영합니다.
/llms.txt— LLM과 AI 크롤러를 위한 기계 판독용 카탈로그. 사이트의 주요 페이지와 글 목록을 요약과 함께 평문으로 제공합니다./rss.xml— 새 글 발행을 구독 경로로 알립니다.- 런타임
/sitemap.xml— Next.js 15 App Router에서 빌드 산출물이 아니라 요청 시점에 생성합니다. 글이 추가되면 재빌드 없이 즉시 반영되고, standalone 빌드로 배포해도 목록이 어긋나지 않습니다.
7. 스키마에 절대 넣지 않는 문장
변호사법 제23조와 대한변호사협회 광고 관련 규정은 홈페이지 본문뿐 아니라 구조화 데이터에도 동일하게 적용됩니다. JSON-LD는 사람 눈에 잘 안 보인다는 이유로 규제를 느슨하게 적용해도 되는 영역이 아닙니다. 오히려 AI가 그대로 인용해 퍼뜨리기 때문에 위험이 더 큽니다.
| 넣지 않는 유형 | 예시 성격 | 대신 쓰는 서술 |
|---|---|---|
| 승소율·성공률·사건 결과 수치 | 결과 통계 제시 | 취급 업무 분야와 절차 설명 |
| 결과 보장·기대 표현 | "반드시", "무조건" 류 | 요건과 법원 판단 기준 설명 |
| 최상급 표현 | 최고·최상·1위·유일 | 학력·경력·자격 취득 연도 등 사실 |
| 전관 강조 | 특정 직역 경력의 영향력 시사 | 경력 사실만 연도와 함께 표기 |
| 다른 변호사와의 비교 | 우열 판단 문구 | 자기 사무소 취급 업무 서술로 한정 |
| 수임료 할인·쿠폰·환불 약정 | 금전적 유인 | 비용 구조에 대한 일반적 설명 |
FAQ 답변은 사실과 정보 전달에 그쳐야 합니다. "이혼 소송은 얼마나 걸리나요?"에 대한 답은 일반적인 절차 소요 기간과 변수를 설명하는 데서 끝나야 하고, "저희에게 맡기시면 더 빠릅니다" 같은 문장이 붙는 순간 정보 제공이 아니라 광고 유인이 됩니다. 상담 안내는 스키마 밖 CTA 영역에서 사무소 연락처와 상담 절차를 사실대로 안내하는 방식으로 처리합니다.
전문분야 표시도 주의가 필요합니다. 대한변호사협회 전문분야 등록이 확인된 변호사에 한해 해당 분야를 표시할 수 있으며, 등록 없이 "전문"을 쓰면 안 됩니다. 스키마의 about이나 knowsAbout 같은 속성에 등록되지 않은 분야를 "전문"으로 적는 것도 같은 문제를 일으킵니다.
8. 배포 전 체크리스트
- FAQ 질문이 실제 검색 수요(Search Console·PAA·자동완성·상담 로그)에서 나왔는가
- 모든 질문이 물음표로 끝나는 질문형인가
- 각 답변의 첫 문장이 결론이고 40~70자 안에서 끝나는가
- 답변에 대명사로 시작하는 문장이 없는가
- JSON-LD의 모든 Q&A가 화면에도 그대로 보이는가(문장 단위 일치)
- 질문마다
acceptedAnswer가 정확히 하나인가 - 페이지별 canonical과 JSON-LD가 고유한가(템플릿 공유와 무관하게)
- 승소율·결과 보장·최상급·전관·비교·할인 문구가 스키마와 화면 어디에도 없는가
- 전문분야 표시가 등록 확인된 범위 안에 있는가
-
serializeJsonLd를 거쳐<이스케이프가 적용되었는가 - Schema Markup Validator로 문법 오류가 0인가
-
/llms.txt,/rss.xml,/sitemap.xml에 해당 페이지가 포함되었는가
마무리
FAQ 스키마는 화려한 기법이 아닙니다. 이미 알고 있는 상담 질문을 기계가 오해 없이 읽을 수 있는 형태로 바꿔 두는 정리 작업에 가깝습니다. 그래서 성과는 마크업을 넣었느냐가 아니라 질문을 어디서 골랐는지, 첫 문장을 어떻게 썼는지, 화면과 스키마가 일치하는지에서 갈립니다.
법률 분야에서는 여기에 하나가 더 붙습니다. 답변은 끝까지 사실과 정보에 머물러야 한다는 것입니다. 규정을 지키는 문장은 규제 회피용 타협이 아니라, 답변 엔진이 선호하는 문장과 방향이 같습니다. 결과를 약속하는 문장보다 요건과 절차를 정확히 적은 문장이 더 자주 인용됩니다. 규제 준수와 AEO가 같은 곳을 가리키는 드문 영역입니다.