변호사 홈페이지 구조화 데이터 — Attorney·LegalService 스키마 작성법

검색엔진은 페이지 HTML만 보고는 "이 사이트가 변호사다"라는 사실을 명확히 알 수 없습니다. 구조화 데이터(Structured Data) 는 페이지에 "이 엔티티는 변호사·법무법인이다"라고 기계적으로 선언하는 표준 언어입니다. 2024년 이후 Google AI Overview와 Bing Chat이 구조화된 데이터가 있는 페이지를 우선 인용하기 시작하면서, 변호사 사이트에도 선택이 아닌 필수가 되었습니다.

이 가이드는 schema.org JSON-LD 형식만 다룹니다. Microdata·RDFa는 구글이 사실상 JSON-LD를 권장하므로 생략합니다.

1. 어떤 타입을 써야 하나? — 3가지 케이스

변호사 사이트는 규모와 형태에 따라 스키마 타입이 달라집니다.

Case A. 법무법인·법률사무소 전체

LegalService 타입을 사용합니다. LocalBusiness의 하위 타입으로, 변호사 업무를 명시적으로 표현합니다.

Case B. 개별 변호사 프로필 페이지

Attorney 또는 Person 타입을 사용합니다. Attorney는 Person의 하위 타입이지만 검색엔진 지원이 더 넓습니다.

Case C. 여러 지점을 운영하는 중·대형 로펌

Organization + 복수 LocalBusiness 조합. 각 지점을 별도 LocalBusiness 노드로 선언하고 branchOf로 본사와 연결합니다.

2. LegalService 스키마 — 법무법인 필수 템플릿

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example-law.com/#organization",
  "name": "OO 법무법인",
  "url": "https://example-law.com/",
  "logo": "https://example-law.com/logo.png",
  "image": "https://example-law.com/og.jpg",
  "description": "서울 서초구에 위치한 이혼·상속·형사 전문 법무법인.",
  "telephone": "+82-2-0000-0000",
  "email": "contact@example-law.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "서초대로 OOO 5층",
    "addressLocality": "서초구",
    "addressRegion": "서울특별시",
    "postalCode": "06000",
    "addressCountry": "KR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.4923,
    "longitude": 127.0292
  },
  "areaServed": [
    { "@type": "City", "name": "서울특별시" },
    { "@type": "City", "name": "수원시" }
  ],
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }],
  "priceRange": "₩₩",
  "sameAs": [
    "https://www.facebook.com/example-law",
    "https://blog.naver.com/example-law"
  ]
}

필수 필드 체크리스트

✅ @type: LegalService (또는 LawFirm — 동일 시맨틱)
✅ name: 정식 법인명
✅ url: 홈페이지 루트 URL
✅ telephone: E.164 국제 표기(+82-2-...)
✅ address.streetAddress + addressLocality + addressRegion + addressCountry: KR

놓치기 쉬운 필드

areaServed: 지역 키워드 SEO의 핵심. 서비스 제공 지역을 City 배열로.
priceRange: ₩·₩₩·₩₩₩ 중 택1. 빠지면 Google Business Profile 연동이 약해집니다.
geo: 위도·경도. 네이버 플레이스·카카오맵 연동 시그널.

3. Attorney 스키마 — 개별 변호사 프로필

변호사 소개 페이지마다 Attorney 스키마를 넣습니다.

{
  "@context": "https://schema.org",
  "@type": "Attorney",
  "@id": "https://example-law.com/attorneys/kim-oo#person",
  "name": "김 OO",
  "jobTitle": "대표변호사",
  "image": "https://example-law.com/attorneys/kim-oo.jpg",
  "worksFor": { "@id": "https://example-law.com/#organization" },
  "knowsAbout": ["이혼·가사", "상속", "형사"],
  "alumniOf": [
    { "@type": "CollegeOrUniversity", "name": "OO대학교 법학과" }
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "license",
      "name": "대한변호사협회 등록 제OOOO호"
    }
  ],
  "memberOf": { "@type": "Organization", "name": "대한변호사협회" }
}

변협 규정과의 접점

hasCredential에는 변협 등록번호를 명시하는 것이 권장됩니다. 이는 변협 광고규정 준수의 사실 기반 표현이며 Google에게는 신뢰도 신호가 됩니다.
knowsAbout에 "전문"이라는 단어를 넣지 마세요. 변협 광고규정상 "전문"은 변협 전문분야 등록 변호사에게만 허용됩니다. 일반 변호사는 "주요 업무", "취급 분야"로 표기합니다.

4. 지점이 여러 개인 경우 — Organization + LocalBusiness

서초 본사 + 부산 지점을 운영하는 로펌이라면:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example-law.com/#organization",
      "name": "OO 법무법인",
      "url": "https://example-law.com/"
    },
    {
      "@type": "LegalService",
      "@id": "https://example-law.com/seocho#branch",
      "name": "OO 법무법인 서초 본사",
      "branchOf": { "@id": "https://example-law.com/#organization" },
      "address": { "@type": "PostalAddress", "addressLocality": "서초구", "addressRegion": "서울특별시", "addressCountry": "KR" }
    },
    {
      "@type": "LegalService",
      "@id": "https://example-law.com/busan#branch",
      "name": "OO 법무법인 부산 지점",
      "branchOf": { "@id": "https://example-law.com/#organization" },
      "address": { "@type": "PostalAddress", "addressLocality": "연제구", "addressRegion": "부산광역시", "addressCountry": "KR" }
    }
  ]
}

@graph로 묶으면 하나의 JSON-LD 블록에 여러 엔티티를 함께 선언할 수 있어 head 내 script 태그가 여러 개로 늘어나지 않습니다.

5. 자주 묻는 질문 — FAQPage 스키마

블로그 포스팅·업무분야 페이지 하단에 FAQ 섹션이 있다면 반드시 FAQPage 스키마를 추가하세요. Google SERP의 확장 스니펫(expandable answer) 후보가 됩니다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "이혼 소송은 얼마나 걸리나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "협의이혼은 3주 내외, 재판상 이혼은 평균 6~12개월 소요됩니다. 쟁점(재산분할·양육권)이 복잡할수록 기간이 늘어납니다."
      }
    }
  ]
}

주의: Answer.text에 "승소 보장" 같은 변협 규정 위반 표현을 쓰면 스키마가 위반의 증거로 박제됩니다. FAQ 답변은 더욱 엄격하게 검토해야 합니다.

6. 검증 도구 — 배포 전 필수

Schema Markup Validator — schema.org 공식. 구조 오류 체크.
Rich Results Test — Google 공식. 실제 리치 스니펫 후보 여부.
LawSERP 진단 — 변호사 사이트에 특화된 필수 필드·변협 규정 교차 검증.

7. 흔한 실수 5가지

@type을 LocalBusiness로만 남김 → LegalService로 더 구체화해야 변호사임이 명시됨.
address.addressCountry 누락 → 국제 SEO에서 한국 비즈니스로 인식 못 함.
전화번호를 +82 없이 02-0000-0000로만 기입 → 국제 검색 결과에서 탈락.
Attorney에 worksFor 미연결 → 변호사와 로펌 엔티티가 분리돼 권위 신호가 분산됨.
FAQ 답변에 규정 위반 표현 포함 → 변협 심의 리스크 증가.

구조화 데이터는 한 번 제대로 작성하면 이후 운영 비용이 거의 없습니다. 반대로 빠져 있으면 AI 검색 시대에 가장 큰 기회 손실입니다. LawSERP 무료 진단에서 내 사이트의 구조화 데이터가 어떤 상태인지 30초 안에 확인할 수 있습니다.