GEO/AEO

ChatGPT·Perplexity가 인용하는 법무법인 사이트 만들기

ChatGPT·Perplexity·Gemini·네이버 AI가 법무법인 사이트를 인용하게 만드는 GEO 실무 기준. llms.txt 카탈로그, LegalService 엔티티와 sameAs, 구성원 자격·학력·취급 업무를 인용 가능한 사실로 구조화하는 방법을 광고규정 안에서 정리했습니다.

2026-09-03·웨비스튜디오

#GEO#생성형 엔진 최적화#llms.txt#구조화 데이터#법무법인 홈페이지#AI 검색 인용#변협 광고규정

핵심 요약

생성형 엔진은 수식어가 아니라 검증 가능한 사실을 인용합니다. 법무법인 사이트에서 인용 확률을 높이는 순서는 (1) 기계 판독용 /llms.txt 카탈로그 구축, (2) 하나의 @id로 고정한 LegalService 엔티티와 sameAs로 동일성 확보, (3) 구성원의 성명·자격 취득 연도·학력·경력·주요 취급 업무를 텍스트와 구조화 데이터로 동시 제공입니다. 승소율·결과 보장·최상급·전관 강조·비교·수임료 유인은 광고규정상 사용하지 않으며, 인용 여부는 고정된 질의 세트로 주 1회 관측해 판단합니다.

핵심 판단

AI 답변에서 중요한 것은 검색 순위가 아니라 인용 여부이며, 인용되는 문장은 주어가 고유명사이고 술어가 검증 가능한 사실이다.
/llms.txt는 비용이 낮고 사실 목록을 강제로 정리하게 해주지만, 거기 적은 사실이 대응 페이지 본문 텍스트에 없으면 아무 역할도 하지 못한다.
조직 스키마의 @id를 URL 프래그먼트로 고정해 전 페이지가 같은 값을 참조하고, sameAs 대상 프로필과 상호·주소·전화 표기를 한 글자까지 통일해야 엔티티가 하나로 합쳐진다.
구성원 정보는 성명·자격 취득 연도·학력·경력·주요 취급 업무만 이미지가 아닌 텍스트로 제공하며, 승소율·보장·최상급·전관·비교·수임료 유인은 본문에도 스키마에도 올리지 않는다.
지역·분야 랜딩은 데이터 1개 + 공통 템플릿으로 자동 생성하되, 고유 canonical·고유 JSON-LD·고유 사실·고유 FAQ·내부 링크 중 셋 이상을 채우지 못하면 만들지 않는다.
인용 가시성은 고정 질의 세트를 주 1회 관측해 인용 점유, 인용 URL 정확도, 사실 오기 건수, AI 레퍼러 유입으로 판단하며 1회 관측을 결론으로 삼지 않는다.

상담 유입 경로가 조용히 바뀌고 있습니다. 의뢰인은 "○○구 상속 한정승인 절차"를 검색창이 아니라 ChatGPT나 Perplexity에 묻고, 답변 아래 각주로 달린 서너 개 링크 중에서 연락할 사무실을 고릅니다. 여기서 문제는 순위가 아니라 인용입니다. 검색 결과 10위 안에 있어도 그 대화에 인용되지 않으면, 그 의뢰인에게 우리 사이트는 존재하지 않는 것과 같습니다.

GEO(Generative Engine Optimization, 생성형 엔진 최적화)는 바로 이 인용 슬롯을 겨냥한 작업입니다. 기존 SEO가 "검색엔진이 이 페이지를 수집하고 색인할 수 있는가"를 다뤘다면, GEO는 "언어 모델이 답변에 그대로 옮겨 적을 만한 사실이 이 페이지에 있는가"를 다룹니다. 둘은 별개가 아닙니다. 색인되지 않는 페이지는 인용도 되지 않습니다. 다만 색인만으로는 부족합니다.

법무법인·법률사무소 사이트에는 제약이 하나 더 붙습니다. 변호사법 제23조와 대한변호사협회 광고규정 때문에 "눈에 띄는 자극적인 문장"을 쓸 수 없습니다. 승소율·성공률, 결과 보장, 최상급 표현, 전관 강조, 다른 변호사와의 비교, 수임료 할인·환불 약정은 애초에 선택지가 아닙니다. 그런데 이 제약은 GEO와 오히려 잘 맞습니다. 생성형 엔진이 실제로 옮겨 적는 것은 수사가 아니라 검증 가능한 사실이기 때문입니다. 아래 내용은 웨비스튜디오가 자사 사이트에서 실제로 운영 중인 구조 — /llms.txt 카탈로그, serializeJsonLd로 출력하는 JSON-LD, 검색의도 랜딩 팩토리 — 를 법무법인 사이트에 어떻게 옮기는지 정리한 것입니다.

AI는 왜 사실 밀도가 높은 사이트를 인용하나

생성형 엔진의 인용은 대체로 세 단계를 거칩니다. (1) 질의를 몇 개의 하위 질문으로 쪼개고, (2) 검색 인덱스에서 후보 문서를 가져오고, (3) 각 문서에서 그 하위 질문에 그대로 대응하는 문장을 뽑아 답변에 붙입니다. 3단계에서 살아남는 문장에는 공통점이 있습니다.

주어가 고유명사다. "저희 사무실"이 아니라 "법무법인 ○○".
술어가 검증 가능하다. "풍부한 경험"이 아니라 "2015년 변호사 자격 취득, 주요 취급 업무: 상속·유류분".
문장 하나가 독립적으로 성립한다. 앞 문단을 읽어야 이해되는 문장은 발췌되지 않습니다.
페이지 주제와 문장이 일치한다. 상속 페이지에 형사 사건 설명이 섞여 있으면 어느 쪽으로도 뽑히지 않습니다.

반대로 인용되지 않는 전형은 이미지 안에 텍스트를 넣은 대표 인사말, 슬라이드로만 존재하는 업무 분야, "믿을 수 있는 법률 파트너" 같은 주어 없는 형용사 나열입니다. 사람 눈에는 정돈돼 보여도 모델 입장에서는 추출할 명제가 없습니다.

판단 기준은 하나로 줄일 수 있습니다. 페이지에서 아무 문장이나 하나 잘라내 맥락 없이 읽었을 때, 그 문장만으로 "누가 / 무엇을 / 언제"가 성립하는가. 성립하지 않으면 인용 후보가 아닙니다.

(a) /llms.txt — 기계 판독 카탈로그부터 만든다

llms.txt는 사이트 지도를 사람이 아니라 모델에게 주는 문서입니다. 웨비스튜디오 사이트에서는 Next.js 15 App Router의 라우트 하나(app/llms.txt/route.ts)로 운영하며, 정적 생성 후 일정 주기로 재생성되도록 두었습니다. 구성은 사이트 한 줄 정의, Base URL·Sitemap·Robots·RSS·대표 상담 URL, 서비스 목록(이름 + 설명 + URL), 공개 페이지 목록, 그리고 각 글의 URL과 한 줄 요약입니다. 법무법인 버전으로 옮기면 이렇게 됩니다.

# 법무법인 ○○
> 서울 ○○구에 위치한 법무법인. 상속·가사·부동산 분쟁을 주로 다룸.

Base URL: https://example.com
Sitemap: https://example.com/sitemap.xml
RSS: https://example.com/rss.xml
상담 접수: https://example.com/contact

## 구성원
- 변호사 ○○○ — 2015년 변호사 자격 취득. ○○대학교 법학전문대학원 졸업.
  주요 취급 업무: 상속, 유류분, 상속재산분할. URL: /members/hong

## 취급 업무
- 상속 한정승인·상속포기 — 절차, 기간, 준비 서류 안내. URL: /practice/inheritance

## 자료
- /blog/limited-acceptance-deadline — 한정승인 기간 계산 기준. 요약: 상속 개시를 안 날부터의 기산점과 예외를 정리.

llms.txt는 아직 모든 엔진이 읽는다고 보장된 표준이 아닙니다. 그래도 만들 값어치가 있는 이유는 두 가지입니다. 첫째, 비용이 라우트 하나 수준으로 낮습니다. 둘째, 이 문서를 작성하는 과정에서 "우리 사이트가 주장하는 사실 목록"이 강제로 정리됩니다. 다만 원칙 하나는 반드시 지켜야 합니다. llms.txt에 적은 사실은 대응하는 페이지 본문에도 같은 문장으로 존재해야 합니다. 실제 인용은 본문 HTML에서 일어나므로, 카탈로그에만 있고 페이지엔 없는 사실은 아무 역할도 하지 못합니다.

(b) LegalService 엔티티와 sameAs — 하나의 법인으로 인식시키기

엔티티가 흐릿하면 인용이 흩어집니다. 같은 법인이 홈페이지, 네이버 플레이스, 블로그, 유튜브에서 조금씩 다른 이름과 주소로 존재하면 모델은 이를 하나로 묶지 못하고, 결국 정보가 한 곳에 모인 다른 사이트를 인용합니다. 최소 구성은 다음과 같습니다.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example.com/#organization",
  "name": "법무법인 ○○",
  "url": "https://example.com",
  "telephone": "+82-2-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○대로 00, 3층",
    "addressLocality": "서초구",
    "addressRegion": "서울특별시",
    "postalCode": "00000",
    "addressCountry": "KR"
  },
  "areaServed": ["서울특별시", "경기도"],
  "serviceType": ["상속", "유류분", "상속재산분할"],
  "sameAs": [
    "https://map.naver.com/…",
    "https://www.google.com/maps/…",
    "https://www.youtube.com/@…"
  ],
  "member": [
    {
      "@type": "Person",
      "@id": "https://example.com/members/hong#person",
      "name": "홍○○",
      "jobTitle": "변호사"
    }
  ]
}

여기서 실무적으로 중요한 판단은 네 가지입니다.

@id를 URL 프래그먼트로 고정하고 모든 페이지에서 같은 값을 참조합니다. 페이지마다 이름만 같고 식별자가 다른 조직 스키마를 뿌리면, 기계 입장에서는 비슷한 법인이 여러 개 있는 셈이 됩니다.
sameAs는 홍보 링크 모음이 아니라 동일성 증거입니다. 서로 다른 플랫폼의 프로필이 같은 상호·주소·전화를 가리킬 때 엔티티가 하나로 합쳐집니다. 표기가 한 글자만 달라도(예: "3층"과 "301호") 합쳐지지 않습니다. 스키마를 손대기 전에 NAP(상호·주소·전화) 표기부터 통일하는 편이 순서상 맞습니다.
지점이 여럿이면 각 지점을 별도 LegalService로 두고 parentOrganization으로 연결합니다. 한 페이지에 지점 정보를 몰아넣으면 지역 질의에서 어느 지점도 뚜렷하게 뽑히지 않습니다.
출력 단계에서 반드시 이스케이프합니다. 웨비스튜디오는 모든 JSON-LD를 serializeJsonLd로 감싸 <script type="application/ld+json"> 안에 넣습니다. 구현 자체는 JSON.stringify 결과에서 <를 \u003c로 치환하는 한 줄이지만, 법인 소개 문구에 부등호나 따옴표가 들어가는 순간 스크립트 태그가 조기 종료되어 스키마 전체가 무효가 되는 사고를 막습니다. 저장소에는 직렬화 누락을 잡는 검사 스크립트를 두고 빌드 전에 돌립니다.

(c) 구성원 정보를 '인용 가능한 사실'로 바꾸기

AI가 법률 질의에 답할 때 가장 자주 인용하는 대상은 서비스 소개 문구가 아니라 사람입니다. "누가 이 업무를 다루는가"가 질문의 실질이기 때문입니다. 그래서 구성원 페이지가 GEO의 핵심 자산이 됩니다.

표시 가능한 사실	스키마 속성	화면 표기 예
성명	`Person.name`	변호사 홍○○
자격 취득 연도	`Person.hasCredential`	2015년 변호사 자격 취득
학력	`Person.alumniOf`	○○대학교 법학전문대학원 졸업
경력	`Person.worksFor` / `description`	2016–2020 ○○법률사무소 근무
주요 취급 업무	`Person.knowsAbout`	상속, 유류분, 상속재산분할
소속 단체	`Person.memberOf`	대한변호사협회, 서울지방변호사회

반대로 어떤 형식으로도 올리지 않는 항목은 다음과 같습니다. 승소율·성공률 같은 성과 수치, 결과를 보장하거나 기대하게 하는 표현, 최상급 표현(최고·1위·유일 등), 전관 관계를 부각하는 표현, 다른 변호사·법인과의 비교, 수임료 할인·쿠폰·환불 약정 형태의 유인. 이는 광고규정상 금지되는 영역이며, 구조화 데이터라고 예외가 되지 않습니다. 오히려 스키마에 넣으면 기계가 그대로 퍼 나르기 때문에 위험이 커집니다.

한 가지 더. 협회의 '전문분야' 표시는 등록이 확인된 변호사에게만 사용합니다. 등록 없이 본문이나 knowsAbout 값에 "전문"을 붙이면 규정 위반 소지가 생기므로, 등록 전에는 '주요 취급 업무'로 적습니다. 스키마 속성 이름이 knowsAbout이더라도 화면 문구는 '주요 취급 업무'로 두는 편이 안전합니다.

작성 형식은 문장 하나로 끝내는 것이 좋습니다. "변호사 ○○○은 2015년 변호사 자격을 취득했고, ○○대학교 법학전문대학원을 졸업했으며, 상속·유류분 사건을 주로 다룹니다." 이 한 문장이 사람이 읽는 소개인 동시에 모델이 그대로 옮길 수 있는 명제입니다. 같은 내용이 프로필 이미지 안이나 첨부 PDF에만 있으면 인용되지 않습니다.

(d) 지역·분야 페이지를 doorway로 만들지 않는 조건

AI에 들어오는 법률 질의는 대부분 "지역 + 분야 + 상황" 형태입니다. 그래서 지역·분야별 랜딩 페이지가 유효한 전략인 것은 맞지만, 같은 문장에서 지역명만 바꾼 페이지를 수십 개 찍어내면 얇은 중복 페이지(doorway)가 되어 사이트 전체 평가를 끌어내립니다.

웨비스튜디오가 자사 사이트에서 쓰는 방식은 데이터 객체 1개 + 공통 React 템플릿 → 지역·분야별 페이지 N개 자동 생성입니다. 자동 생성 자체는 문제가 아닙니다. 문제는 각 페이지가 고유한 내용을 갖는지입니다. 아래 다섯 가지 중 세 개 이상을 채우지 못하면 그 페이지는 만들지 않습니다.

요소	페이지마다 고유해야 하는 이유
canonical	자기 자신을 가리켜야 색인 대상이 됩니다. 잘못 묶이면 페이지가 통째로 사라집니다
JSON-LD	해당 업무·지역에 맞는 `serviceType`, `areaServed`, FAQ가 들어가야 인용 대상이 됩니다
본문 사실	절차·기간·필요 서류·담당 구성원처럼 다른 페이지에는 없는 내용이 있어야 합니다
FAQ	그 주제로 실제 들어오는 질문 4~6개를 담습니다
내부 링크	관련 글과 관련 업무로 이어지는 경로가 있어야 합니다

판단 기준을 한 문장으로 줄이면 이렇습니다. 이 페이지를 그 지역 의뢰인에게 그대로 보여줬을 때, 다른 지역 페이지와 구별되는 정보가 있는가. 없다면 페이지 수를 늘리는 대신 하나를 제대로 쓰는 쪽이 낫습니다.

(e) FAQPage와 배포 경로 3중화

글과 업무 페이지마다 FAQPage 구조화 데이터를 답니다. 질문–답변 쌍은 생성형 엔진이 그대로 재사용하기 가장 쉬운 형태이기 때문입니다. 질문은 실제 상담 전화에서 들은 문장 그대로 쓰고, 답변은 2~4문장으로 결론부터 적습니다. 다만 "사안에 따라 다릅니다"만 쓰면 인용 가치가 없고, 반대로 단정하면 규정 문제가 생깁니다. 안전한 형태는 **"일반적인 절차와 기간은 A이며, B 요건에 따라 달라질 수 있습니다"**입니다.

배포 경로는 세 갈래로 둡니다. 런타임 sitemap.xml(새 글이 즉시 반영), rss.xml(수집기·피드 리더), /llms.txt(모델용 카탈로그). 그리고 마지막으로 robots.txt에서 AI 크롤러 UA(GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended 등)를 차단하고 있지 않은지 확인합니다. 차단 상태라면 위 작업은 전부 무의미해집니다. 과거 대행사가 넣어둔 규칙 때문에 막혀 있는 사이트가 실제로 있습니다.

검색 노출과 AI 인용은 클릭, 상담 예약, 사건 수임을 보장하지 않습니다. 여기 정리한 구조는 인용 후보에 들어갈 조건을 만드는 작업이며, 실제 결과는 지역, 분야 경쟁 상황, 문의 응대 속도에 따라 달라집니다.

인용 가시성을 어떻게 판단하나 — 측정 방법론

남의 사례에서 숫자를 빌려오면 판단이 틀어집니다. 우리가 한국 전문서비스 질의로 "AI가 실제로 누구를 인용하는가"를 확인할 때 쓰는 절차는 다음과 같고, 그대로 자기 도메인의 기준선을 만드는 데 쓸 수 있습니다.

질의 세트를 고정합니다. 지역 + 분야 + 상황 조합 20~30개. 마케팅 용어가 아니라 실제 상담 전화에서 들은 표현 그대로 씁니다.
엔진을 고정합니다. ChatGPT 검색, Perplexity, Gemini, 네이버 AI 검색. 개인화 영향을 줄이기 위해 비로그인·시크릿 세션을 기본으로 하고, 로그인 세션 결과는 따로 기록합니다.
기록 항목을 정합니다. 답변에 인용된 도메인 전체 목록, 우리 도메인 인용 여부, 인용된 URL 유형(홈 / 업무분야 / 구성원 / 블로그), 인용된 문장이 사실과 일치하는지.
주기를 고정합니다. 주 1회, 같은 요일·같은 시간대. 생성형 답변은 재실행마다 달라지므로 1회 관측을 결론으로 삼지 않습니다.
네 가지 지표로 판단합니다. ① 인용 점유(질의 중 우리 도메인이 한 번 이상 인용된 비율) ② 인용된 URL이 의도한 페이지인지 ③ 사실 오기 건수 ④ 서버 로그·분석 도구에서 확인되는 AI 레퍼러(chatgpt.com, perplexity.ai 등) 유입 추이.

세 번째 지표를 가볍게 보지 않는 편이 좋습니다. 사무실 위치나 자격 취득 연도가 틀린 채로 인용되는 상황은 인용이 없는 상태보다 손해가 큽니다. 원인은 대개 사이트 안에 같은 사실의 옛 버전이 남아 있는 것이고, 이는 엔티티 정리로 해결됩니다.

발행 전 체크리스트

정리

GEO는 새로운 기술이라기보다 정보 정리 작업에 가깝습니다. 법무법인 사이트에서는 규정상 쓸 수 있는 문장이 결국 검증된 사실뿐인데, 생성형 엔진이 인용하는 것도 사실입니다. 성과 수치 대신 자격 취득 연도, 수식어 대신 절차와 기간, 이미지 대신 텍스트 — 이 세 가지 교체만으로 인용 후보에 들어갈 조건의 상당 부분이 채워집니다. 남는 일은 엔티티를 하나로 고정하고, 기계가 읽을 수 있는 카탈로그를 유지하고, 고정된 질의 세트로 관측을 계속하는 것입니다.

자주 묻는 질문

그렇지 않습니다. llms.txt는 모든 엔진이 읽는다고 보장된 표준이 아니고, 실제 인용은 페이지 본문 HTML에서 일어납니다. 그럼에도 만들 값어치가 있는 이유는 라우트 하나 수준의 낮은 비용으로 사이트가 주장하는 사실 목록을 정리하게 되고, 카탈로그와 본문의 불일치를 발견하게 되기 때문입니다.

승소율·성공률, 결과 보장, 최상급 표현, 전관 강조, 다른 변호사와의 비교는 광고규정상 사용하지 않습니다. 대신 표시할 수 있는 사실은 학력, 경력, 자격 취득 연도, 주요 취급 업무이며, 여기에 절차·기간·준비 서류를 정확히 설명한 콘텐츠가 더해질 때 사람과 모델 양쪽이 참조할 근거가 생깁니다.

'전문' 표시는 등록이 확인된 변호사에게만 사용합니다. 등록 사실을 확인할 수 없다면 본문과 구조화 데이터 모두 '주요 취급 업무'로 표기하는 편이 안전합니다. 스키마 속성 이름이 knowsAbout이더라도 화면에 노출되는 문구는 취급 업무 표현으로 두는 것을 권합니다.

각 페이지가 고유한 canonical, 고유한 JSON-LD, 그 지역·분야에만 해당하는 사실, 실제 질문에서 뽑은 FAQ를 갖추면 유효합니다. 반대로 같은 문장에서 지역명만 바꾼 페이지는 얇은 중복 페이지로 취급되어 사이트 전체 평가에 불리하게 작용할 수 있습니다.

공통 부분은 같습니다. 수집 허용, 텍스트로 존재하는 사실, 구조화 데이터, 일관된 엔티티가 전제입니다. 다만 네이버는 서치어드바이저 등록과 수집 상태, 플레이스에 등록된 상호·주소·전화의 일관성이 추가로 영향을 주므로 sameAs에 네이버 플레이스를 포함하고 표기를 홈페이지와 일치시키는 작업이 필요합니다.

즉시 확인되지 않습니다. 재수집과 색인 갱신에 시간이 걸리고, 생성형 답변은 재실행마다 달라집니다. 고정된 질의 세트 20~30개를 주 1회 같은 조건으로 관측해 인용 점유와 인용된 URL 유형, 사실 오기 여부를 기록하고 추세로 판단합니다. 인용이 늘어도 상담이나 수임이 보장되지는 않습니다.