법무법인 GEO 마케팅, 홈페이지에 넣어야 할 JSON-LD 스키마 7가지 — 변호사 광고 규정 안에서

3줄 요약

• 법무법인 본체는 LegalService로 적습니다. schema.org는 Attorney 타입을 지원 중단(deprecated)했고, 그 이유를 “LegalService가 더 포괄적이고 덜 모호하다”고 밝히고 있습니다.
• 스키마는 순위를 올리는 장치가 아니라 기계가 우리 법인을 다른 법인과 혼동하지 않게 하는 장치입니다. 구글은 구조화 데이터를 넣었다고 해서 그 기능이 검색 결과에 나타난다고 보장하지 않습니다.
• 화면에 쓸 수 없는 말은 스키마 안에서도 쓸 수 없습니다. 구글은 “구조화 데이터는 페이지 콘텐츠를 참되게 표현한 것이어야 한다”고 정하고 있고, 변호사법 제23조 제2항은 매체를 가리지 않고 광고의 ‘내용’을 규율합니다.

이 글은 다섯 가지 질문에 답합니다. ① 법무법인은 어떤 스키마 타입을 써야 하는가 ② 변호사 개인과 법인은 어떻게 나눠 적는가 ③ 업무 분야 페이지는 무엇으로 표시하는가 ④ 후기·승소율·전관 같은 항목은 왜 넣으면 안 되는가 ⑤ 붙인 뒤에 무엇으로 검증하는가. 코드는 전부 가상의 “법무법인 예시”로 썼고, 값만 바꾸면 그대로 쓸 수 있게 해 두었습니다.

다루는 항목은 일곱 가지입니다. ① 법인 본체 LegalService ② 지점(분사무소)별 LegalService ③ 변호사 Person ④ 업무 분야 Service ⑤ 칼럼·판례 해설 Article/BlogPosting ⑥ 조건부로 쓰는 FAQPage ⑦ 앞의 여섯을 하나로 잇는 @graph·@id 구조입니다.

구조화 데이터, schema.org, JSON-LD는 각각 무엇인가요?

세 단어는 자주 섞여 쓰이지만 층위가 다릅니다. 구조화 데이터는 페이지에 적힌 내용을 기계가 읽을 수 있는 형식으로 한 번 더 적어 둔 것입니다. 사람은 홈페이지 푸터의 “법무법인 예시 | 서울 서초구 ○○로 12 | 02-000-0000″을 보고 상호·주소·전화번호를 바로 구분하지만, 프로그램에게 그것은 문자열 한 줄입니다. 구조화 데이터는 그 한 줄에 “이것은 조직의 이름, 이것은 주소, 이것은 전화번호”라는 꼬리표를 달아 줍니다.

schema.org는 그 꼬리표의 공통 어휘집입니다. 2011년 구글·마이크로소프트·야후가 함께 만들었고, LegalService·Person·Service 같은 ‘타입’과 name·address·worksFor 같은 ‘속성’을 정의해 공개합니다. 검색 엔진과 답변 엔진이 같은 어휘를 읽기로 약속해 두었기 때문에 사이트마다 이름을 새로 지어 쓸 필요가 없습니다. JSON-LD는 그 어휘를 페이지에 싣는 형식 중 하나입니다. HTML 태그 사이에 끼워 넣는 Microdata·RDFa 방식도 있지만, JSON-LD는 본문과 분리된 스크립트 블록 하나에 JSON 형태로 적기 때문에 워드프레스 같은 CMS에서 관리하기 쉽고 구글도 이 형식을 권장합니다. 이 글의 코드가 전부 JSON-LD인 이유입니다.

정리하면, 무엇을 적을지는 schema.org가 정하고 어떻게 적을지는 JSON-LD가 정하며, 그 둘을 합쳐 페이지에 넣은 결과물이 구조화 데이터입니다. 법무법인에서 달라지는 것은 이 문법이 아니라 어떤 타입을 고르고 어떤 값을 넣으면 안 되는가이고, 이 글은 그 부분을 다룹니다.

법무법인 GEO 마케팅에서 왜 구조화 데이터가 먼저인가요?

생성형 답변 엔진이든 검색 엔진이든, 먼저 풀어야 할 문제는 ‘이 페이지가 누구에 관한 것인가’이기 때문입니다. 구글은 Organization 구조화 데이터 문서에서 이 마크업이 “조직의 행정적 세부 정보를 더 잘 이해하고, 검색 결과에서 내 조직을 다른 조직과 구별(disambiguate)하는 데 도움이 된다”고 설명합니다. 비슷한 이름의 법무법인이 여럿이고, 대표변호사 이름이 흔하고, 분사무소가 여러 곳인 업종에서 이 ‘구별’은 사소한 문제가 아닙니다.

콘텐츠를 아무리 많이 써도 기계가 법인·변호사·업무 분야를 한 덩어리로 읽으면, 그 콘텐츠가 어느 주체의 것인지 확정되지 않습니다. JSON-LD는 이 관계를 문장이 아니라 식별자로 적어 두는 방법입니다. 구조화 데이터를 JSON-LD 형식으로 작성하고 검증하는 기본 문법은 업종을 가리지 않고 같고, 법무법인에서 달라지는 것은 타입 선택과 ‘쓸 수 없는 값’의 범위입니다.

스키마는 순위를 올리는 장치가 아닙니다

구글 문서가 말하는 효과는 이해도 향상과 표시(appearance) 개선까지입니다. ProfilePage 문서를 비롯한 구조화 데이터 문서에는 “구글은 구조화 데이터를 사용하는 기능이 검색 결과에 나타날 것이라고 보장하지 않는다”는 고지가 붙어 있습니다. 대행사 제안서에 ‘스키마를 넣으면 순위가 오른다’, ‘AI 답변에 인용된다’는 문장이 있으면 근거 문서를 요구하십시오. 이 글도 그런 인과를 주장하지 않습니다.

하나 더 있습니다. 구글은 구조화 데이터 소개 문서에서 “구글 검색 동작에 대해서는 schema.org 문서가 아니라 Google Search Central 문서를 확정적(definitive) 근거로 삼아야 한다”고 적습니다. schema.org에 있는 속성이라고 해서 구글이 그것을 리치 결과에 쓰는 것은 아닙니다. 다만 같은 문서에서 “여기 문서화된 속성과 객체 외에도 sameAs 속성과 그 밖의 schema.org 구조화 데이터를 일반적으로 활용할 수 있다”고도 밝힙니다. 구글이 기능으로 쓰는 속성은 Search Central 문서로 확인하고, 그 밖의 속성은 schema.org 정의에 맞게 사실만 적는다고 정리하면 됩니다.

변호사 개인과 법무법인은 서로 다른 엔티티입니다

schema.org는 LocalBusiness를 “특정한 물리적 사업장, 또는 조직의 한 지점(branch)”으로 정의합니다. 사무소는 장소이자 조직이고, 변호사는 사람입니다. 이 둘을 한 객체에 섞어 적으면 기계에는 ‘주소를 가진 사람’이나 ‘학력을 가진 사무소’ 같은 객체가 생깁니다. 그래서 법인은 LegalService, 변호사는 Person으로 나누고, @id로 서로를 참조시키는 것이 기본 설계입니다.

광고 규정은 스키마 안쪽까지 따라옵니다

변호사법 제23조 제2항은 거짓된 내용의 광고(제1호), 소비자를 오도하거나 오해를 불러일으킬 우려가 있는 내용의 광고(제3호), 업무수행결과에 대하여 부당한 기대를 가지도록 하는 내용의 광고(제4호)를 금지합니다. 조문은 매체를 한정하지 않습니다. 홈페이지 본문이든, 화면에 보이지 않는 JSON-LD의 description 값이든 광고의 ‘내용’이라는 점은 같습니다. 구조화 데이터를 직접 언급한 조항은 확인되지 않지만, 내용 규제가 형식에 따라 면제된다고 볼 근거도 없습니다.

법무법인은 어떤 스키마 타입을 써야 하나요?

LegalService입니다. schema.org는 LegalService를 “법률 지향적 서비스·자문·대리를 제공하는 사업체다. 예컨대 로펌이 그렇다”고 정의하고, “LocalBusiness로서 하나 이상의 Service의 제공자로 기술될 수 있다”고 덧붙입니다. 반면 Attorney 타입 페이지에는 “이 타입은 지원 중단(deprecated)되었다. LegalService가 더 포괄적이고 덜 모호하다”는 문장이 실려 있고, ProfessionalService 페이지에도 “LegalService는 Attorney의 더 포괄적인 상위 타입으로 도입되었다”고 나옵니다.

그런데도 Attorney 타입은 schema.org 집계 기준 1만~10만 도메인에서 여전히 쓰이고 있습니다(2026년 8월 표기). 국내외 법률 마케팅 업체 가이드 상당수가 아직 Attorney를 권장 항목으로 다루기 때문입니다. 업계 관행과 표준 문서가 어긋나 있는 구간이고, 유지보수를 생각하면 표준 문서 쪽을 따르는 것이 맞습니다.

LocalBusiness를 따로 하나 더 넣어야 하나요?

아닙니다. schema.org의 타입 계층은 Thing > Organization > LocalBusiness > LegalService 순서입니다(Notary 페이지의 계층 표기로 확인됩니다). LegalService를 쓰면 이미 LocalBusiness이자 Organization입니다. 같은 사무소를 LegalService와 LocalBusiness로 두 번 정의하면 엔티티가 둘로 갈라져 오히려 혼선이 생깁니다. 다만 구글은 “LocalBusiness는 Organization의 하위 타입이므로 Organization 문서의 필드도 함께 따를 것을 권장한다”고 적고 있으므로, 로고·sameAs 같은 Organization 계열 속성은 같은 객체 안에 함께 넣습니다.

법인 본체 JSON-LD는 어떻게 쓰나요?

아래 코드를 홈(또는 법인 소개 페이지)에 한 번만 넣고 값을 바꾸면 됩니다. type이 application/ld+json인 스크립트 태그 안에 이 JSON 객체를 그대로 넣는 방식이고, 구글은 세 가지 형식 중 대부분의 경우 JSON-LD를 권장합니다.

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "@id": "https://example-law.co.kr/#office",
  "name": "법무법인 예시",
  "url": "https://example-law.co.kr/",
  "telephone": "+82-2-1234-5678",
  "email": "contact@example-law.co.kr",
  "image": "https://example-law.co.kr/img/office.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "서초대로 123, 8층",
    "addressLocality": "서초구",
    "addressRegion": "서울특별시",
    "postalCode": "06611",
    "addressCountry": "KR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 37.4900,
    "longitude": 127.0100
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "18:00"
  }],
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "서울특별시" },
    { "@type": "AdministrativeArea", "name": "경기도" }
  ],
  "sameAs": [
    "https://blog.naver.com/example-law",
    "https://www.youtube.com/@example-law"
  ]
}

값을 채울 때의 세 가지 원칙

첫째, 화면에 보이는 값만 넣습니다. 구글 일반 가이드라인은 “구조화 데이터는 페이지 콘텐츠를 참되게 표현한 것이어야 한다”고 정합니다. 푸터에 없는 전화번호, 운영하지 않는 시간대, 실제로 수임하지 않는 지역을 areaServed에 넣지 마십시오.

둘째, 많이 채우는 것보다 정확하게 채웁니다. 구글 문서의 표현을 그대로 옮기면 “가능한 모든 권장 속성을 불완전하거나 부정확하게 채우는 것보다, 적더라도 완전하고 정확한 권장 속성을 제공하는 편이 더 중요하다”입니다. 속성별 필수·권장 구분은 구글 Local Business 문서 원문에서 확인하시고, 이 글의 예시는 뼈대로만 쓰십시오.

셋째, priceRange나 수임료 관련 값은 신중하게 다룹니다. 「변호사 광고에 관한 규정」 제4조 제12호는 ‘공정한 수임질서를 저해할 우려가 있는 무료 또는 부당한 염가를 표방하는 광고’를 금지합니다. 화면에 표기하지 않은 가격대를 스키마에만 적어 두면 첫째 원칙과 이 조문에 동시에 걸립니다.

변호사 개인 페이지에는 무엇을 넣나요?

Person을 쓰고, worksFor로 법인 노드에 연결합니다. 구글은 ProfilePage 문서에서 “프로필 페이지 구조화 데이터를 사용해 내 웹사이트에 있는 사람과 조직에 관한 정보를 제공할 수 있다”고 설명하고, Person과 Organization이 공통 속성을 공유한다고 적습니다. 같은 문서에 표시 무보장 고지가 함께 붙어 있으므로, 변호사 프로필을 마크업하면 리치 결과가 뜬다고 기대할 일은 아닙니다.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example-law.co.kr/lawyers/hong/#person",
  "name": "홍길동",
  "jobTitle": "대표변호사",
  "url": "https://example-law.co.kr/lawyers/hong/",
  "image": "https://example-law.co.kr/img/hong.jpg",
  "worksFor": { "@id": "https://example-law.co.kr/#office" },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "○○대학교 법학전문대학원"
  },
  "memberOf": {
    "@type": "Organization",
    "name": "대한변호사협회",
    "url": "https://www.koreanbar.or.kr/"
  },
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "name": "변호사",
    "credentialCategory": {
      "@type": "DefinedTerm",
      "name": "Certification"
    }
  },
  "knowsAbout": ["이혼·가사", "상속", "형사변호"],
  "sameAs": [
    "https://blog.naver.com/example-law-hong"
  ]
}

hasCredential은 ‘검증 배지’가 아닙니다

schema.org는 hasCredential을 “Person 또는 Organization에 수여된 credential”로 정의합니다. 2026년 1월 GitHub에서 이 속성을 교육 자격에 국한하지 말자는 제안(이슈 #4685)이 나왔고, 2026년 9월 16일 공개된 schema.org 30.1에서 일반 Credential 타입이 검토 중(pending) 단계로 추가되면서 hasCredential의 기대 타입도 Credential로 바뀌었습니다. 기존 EducationalOccupationalCredential은 그 하위 타입으로 남아 있으므로 변호사 자격은 후자로 적으면 되고, 위 예시 코드도 그대로 유효합니다. 어느 쪽이든 이 속성은 자격을 사실대로 기술하는 칸이지, 구글이 그 자격을 확인해 주는 기능이 아닙니다.

이름을 밝히라는 규정과 맞물리는 지점

「변호사 광고에 관한 규정」은 2021년 전부개정에서 광고의 주체를 정하는 제3조를 앞세워 “변호사는 자신의 이름으로 업무광고를 하여야 한다”, “법무법인등이 광고를 하는 경우에는 광고책임변호사를 표시하여야 한다”고 정리했습니다(대한변협 전부개정 조문대비표). 구 규정 제10조의 “광고 속에 자신의 성명 또는 명칭을 표시”하라는 의무가 이 조항으로 옮겨 온 것입니다. 이 의무는 담당자 한 사람에게서 끝나지 않습니다. 서울행정법원은 2025년 11월 27일, ‘전관 출신’·무료 상담·형량 예측을 내세운 광고로 징계를 받은 법무법인 대표변호사들의 취소 청구를 기각하면서 “광고책임변호사를 지정하였다는 사정만으로 법무법인의 광고에 대한 다른 대표변호사들의 법령상 책임이 면제된다고 볼 수는 없다”고 판단했습니다(2025구합54763 등, 리걸타임즈 2025-12-05). 홈페이지의 스키마도 광고의 일부입니다. 무엇을 적을지는 광고책임변호사만이 아니라 대표변호사가 함께 볼 사안입니다.

Person 마크업 자체는 이 요구와 충돌하지 않습니다. 성명·직위·소속 법인을 화면과 스키마에 동일하게 적는 일이기 때문입니다. 위험해지는 것은 화면에 없는 이력을 스키마에만 얹을 때이고, 그 순간 구글 가이드라인과 규정 양쪽에 걸립니다.

‘전문’이라는 단어는 자유롭게 쓸 수 없습니다

규정은 “최고”, “유일” 기타 이와 유사한 용어의 사용을 금지하고, ‘전문’ 표시는 협회 「변호사 전문분야 등록에 관한 규정」에 따라 전문분야 등록을 마친 변호사만 쓸 수 있게 했습니다. 두 조항 모두 2021년 전부개정에서 그대로 유지됐습니다(대한변협 전부개정 조문대비표). 등록 가능 분야 수와 개인별 등록 한도는 개정 이력이 있으니 현행 「변호사 전문분야 등록에 관한 규정」으로 확인하십시오. knowsAbout에는 ‘○○ 전문’이 아니라 실제로 다루는 분야명만 적습니다.

업무 분야 페이지는 어떻게 마크업하나요?

페이지마다 Service를 하나씩 두고, provider로 법인 노드를 가리킵니다. schema.org의 Service 공식 예제가 바로 이 구조입니다. serviceType(서비스 종류) + provider(LocalBusiness) + areaServed(제공 지역) + hasOfferCatalog(서비스 목록) 조합이고, 법무법인에 대입하면 provider가 우리 LegalService 노드, serviceType이 ‘이혼·가사 사건 대리’가 됩니다. 표준 예제를 그대로 치환한 설계라 근거가 분명합니다.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example-law.co.kr/practice/divorce/#service",
  "name": "이혼·가사 사건 대리",
  "serviceType": "이혼소송 및 재산분할 사건 대리",
  "url": "https://example-law.co.kr/practice/divorce/",
  "provider": { "@id": "https://example-law.co.kr/#office" },
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "서울특별시" },
    { "@type": "AdministrativeArea", "name": "경기도" }
  ],
  "description": "협의이혼·재판상 이혼, 재산분할, 양육권 사건의 상담과 소송 대리를 수행합니다.",
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "가사 분야 업무",
    "itemListElement": [
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "재산분할 청구 사건"
        }
      },
      {
        "@type": "Offer",
        "itemOffered": {
          "@type": "Service",
          "name": "양육권·양육비 사건"
        }
      }
    ]
  }
}

한 페이지에 한 분야 원칙

이혼·형사·기업자문을 한 페이지에 몰아 두면 Service 노드를 어떻게 쪼개도 페이지의 주제가 하나로 확정되지 않습니다. 답변 엔진이 특정 질의에 맞춰 인용하는 단위는 결국 문서이므로, 분야마다 URL을 나누고 그 URL에 Service 하나를 대응시키는 쪽이 단순합니다. 목록 페이지에는 hasOfferCatalog로 분야를 묶고, 개별 페이지에서 상세를 적는 구성이 자연스럽습니다.

description에 결과를 예측하지 마십시오

「변호사 광고에 관한 규정」 제4조 제13호는 ‘수사기관과 행정기관의 처분·법원 판결 등의 결과 예측을 표방하는 광고’를 금지합니다. ‘불기소 이끌어내는’, ‘집행유예 가능’ 같은 문구는 화면에서도, Service의 description에서도 쓸 수 없습니다. 대신 절차·쟁점·준비 서류처럼 사실로 적을 수 있는 정보를 넣으면, 규정과 충돌하지 않으면서 답변 엔진이 인용하기 좋은 서술이 됩니다.

칼럼과 FAQ는 어떻게 처리하나요?

칼럼·판례 해설에는 Article 또는 BlogPosting을 쓰고, author를 변호사 Person 노드에 @id로 잇습니다. 구글 Article 문서는 “필수 속성은 없다. 대신 내 콘텐츠에 해당하는 속성들을 추가하라”고 적고, Article 객체가 Article·NewsArticle·BlogPosting 중 하나에 기반해야 한다고 명시합니다. 기대 효과도 분명히 적혀 있습니다. 페이지 이해도 향상과 제목·이미지·날짜 정보 표시 개선입니다. 같은 문서는 “Top stories 같은 구글 뉴스 기능에 노출되기 위한 마크업 요건은 없다”고도 밝힙니다.

핵심은 author를 문자열(“홍길동”)이 아니라 Person 노드 참조로 적는 것입니다. 그래야 칼럼, 저자, 소속 법인이 하나의 그래프로 이어집니다. 법률 콘텐츠에서 ‘누가 썼는가’는 내용 못지않게 중요한 정보이고, 이 연결은 문장이 아니라 식별자로만 기계에 전달됩니다.

FAQPage는 지금 어떤 상태인가요?

구글의 FAQ 리치 결과는 종료됐습니다. 구글은 2026년 5월 8일 문서 변경 로그에 “이 기능은 2026년 5월 7일부터 구글 검색에 더 이상 나타나지 않는다”는 지원 중단 공지를 올렸고, 6월 15일에는 FAQ 리치 결과 문서 자체를 삭제했습니다. 예전 문서 주소는 지금 변경 로그로 넘어갑니다. 공지에 적힌 후속 일정은 아래와 같습니다.

그렇다고 당장 지울 필요는 없습니다. FAQPage는 여전히 유효한 schema.org 타입이고, 쓰이지 않는 구조화 데이터가 검색에 문제를 일으키지 않는다는 것이 그동안의 정리입니다. 다만 “FAQ 스키마가 AI 검색 인용에 유리하다”는 주장을 구글 근거로 제시하지는 마십시오. 구글은 이번 지원 중단의 이유를 설명하지 않았고, AI 검색과 연결 지어 언급한 바도 없습니다. FAQPage는 리치 결과 목적이 아니라 문서 구조화 목적으로만 유지 여부를 판단하면 됩니다.

법률 FAQ 답변에 결과를 적지 마십시오. ‘보통 이 정도면 감형됩니다’, ‘대부분 승소합니다’ 같은 문장은 변호사법 제23조 제2항 제4호(업무수행결과에 대한 부당한 기대)와 「변호사 광고에 관한 규정」 제4조 제13호(결과 예측 표방)에 저촉될 소지가 있습니다. FAQ는 절차·기간 산정 방식·필요 서류·상담 시 확인 사항처럼 사실 정보로 채웁니다.

절대 넣으면 안 되는 마크업은 무엇인가요?

첫 번째는 자사 홈페이지의 후기 마크업입니다. 구글은 2019년 9월 발표에서 “주체 A에 대한 리뷰가 주체 A의 웹사이트에 놓인 것”을 self-serving 리뷰로 정의하고, LocalBusiness와 Organization 및 그 하위 타입에 대해서는 리뷰 리치 결과를 표시하지 않는다고 밝혔습니다. LegalService는 그 하위 타입이므로 그대로 해당됩니다. 리뷰 스니펫 문서에도 Local business는 “다른 지역 비즈니스에 대한 리뷰를 수집하는 사이트에 한함”이라는 단서가 붙어 있습니다.

구조화 데이터에 직접 넣든 구글·페이스북 리뷰 위젯을 삽입하든 같은 취급입니다. 구글 일반 가이드라인은 여기에 더해 “실제 사용자가 작성하지 않은 리뷰나 평점은 수동 조치(manual action)로 이어질 수 있다”고 경고합니다. 국내에서는 후기·평가 표시에 변호사법과 변협 규정상의 제약까지 겹치므로, aggregateRating은 법무법인 홈페이지에서 얻을 것이 없는 마크업입니다.

승소율·전관·최고

이 세 가지는 화면에서도 스키마에서도 쓸 수 없습니다. 「변호사 광고에 관한 규정」 제4조 제3호는 ‘승소율, 석방률 기타 고객으로 하여금 업무수행결과에 대하여 부당한 기대를 가지도록 하는 내용의 광고’를 금지합니다. 헌법재판소는 그 이유를 이렇게 설명했습니다.

“승소율이나 석방률이 통계수치로만 의미를 가질 뿐 특정한 의뢰인이나 사건과 관련하여 그 사건의 결과가 어떠하리라는 점을 보증해 줄 수 있는 자료가 아니므로, 그 자체로 고객을 오도하거나 업무수행결과에 대하여 부당한 기대를 가지도록 할 가능성이 있기 때문이다.” — 헌재 2022. 5. 26. 선고 2021헌마619

‘전관’ 표현은 2025년 개정으로 명문 금지가 됐습니다. 대한변협은 2025년 2월 10일 개정 규정을 공포·시행하면서 제7조를 신설해 법원·검찰·경찰·공정거래위원회·금융감독원 등 공직 재직 사실을 강조해 수임을 유도하는 행위, 공직에 영향력을 행사할 수 있다는 취지의 문구, ‘전관’·’전관 변호사’·’전관예우’라는 문구, 공직 제복 또는 유사 복식을 입는 방법의 표시를 금지했습니다(리걸타임즈 2025-02-24 보도의 조문 인용 기준). ‘최고’·’유일’은 구 규정에서부터 금지 용어였습니다.

이 표현들은 JSON-LD의 name, description, award, slogan 같은 값에 들어가기 쉽습니다. 스키마는 숨겨진 곳이 아닙니다. 화면에 못 쓰는 말은 코드에도 쓰지 않는다는 원칙 하나로 대부분의 위험이 정리됩니다.

화면에 없는 정보, 그리고 지점 처리

구글 가이드라인의 문장은 단순합니다. “구조화 데이터는 페이지 콘텐츠를 참되게 표현한 것이어야 한다.” 수상 이력, 언론 보도, 처리 건수처럼 본문에 근거가 없는 값을 스키마에만 적어 두는 방식은 정책 위반 소지가 있습니다. 구조화 데이터에 지정한 이미지 URL도 크롤링·색인이 가능해야 합니다.

지점 처리도 자주 틀립니다. 본점과 분사무소를 하나의 Organization으로 뭉쳐 놓거나, 반대로 페이지마다 조금씩 다른 이름·주소의 법인 객체를 새로 만들어 두는 경우가 많습니다. 구글 문서는 “각 지점을 각각 하나의 LocalBusiness 타입으로 정의하라”고 명시합니다. 타입을 여러 개 주고 싶다면 배열로 적습니다. additionalType은 지원되지 않습니다.

어떻게 붙이고 어떻게 검증하나요?

흩어진 노드를 @graph 하나로 묶고, 리치 결과 테스트와 Schema Markup Validator로 확인하는 순서입니다. 아래는 법인·변호사·업무 분야·칼럼을 한 문서 안에서 잇는 형태입니다. @id만 정확히 맞추면 페이지마다 나눠 넣어도 같은 그래프로 연결됩니다.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "LegalService",
      "@id": "https://example-law.co.kr/#office",
      "name": "법무법인 예시",
      "url": "https://example-law.co.kr/",
      "telephone": "+82-2-1234-5678"
    },
    {
      "@type": "Person",
      "@id": "https://example-law.co.kr/lawyers/hong/#person",
      "name": "홍길동",
      "jobTitle": "대표변호사",
      "worksFor": { "@id": "https://example-law.co.kr/#office" }
    },
    {
      "@type": "Service",
      "@id": "https://example-law.co.kr/practice/divorce/#service",
      "name": "이혼·가사 사건 대리",
      "serviceType": "이혼소송 및 재산분할 사건 대리",
      "provider": { "@id": "https://example-law.co.kr/#office" }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example-law.co.kr/column/2026-divorce-note/#article",
      "headline": "재산분할 기여도 판단에서 자주 다투는 쟁점",
      "datePublished": "2026-03-11",
      "dateModified": "2026-03-11",
      "author": { "@id": "https://example-law.co.kr/lawyers/hong/#person" },
      "publisher": { "@id": "https://example-law.co.kr/#office" },
      "about": { "@id": "https://example-law.co.kr/practice/divorce/#service" }
    }
  ]
}

워드프레스에서 붙이는 두 가지 방법

Yoast나 Rank Math를 쓰고 있다면 이미 사이트 전역에 @graph가 출력되고 있을 가능성이 높습니다. 여기에 위 코드를 통째로 또 넣으면 같은 법인이 두 번 정의됩니다. 선택지는 둘입니다. ① 플러그인의 조직 설정에서 타입·이름·주소·sameAs를 채워 기존 그래프를 쓰고, 부족한 Service·Person만 페이지 단위로 추가한다. ② 플러그인의 스키마 출력을 끄고 직접 삽입한다. 어느 쪽이든 법인 노드는 사이트 전체에 하나여야 합니다.

검증은 세 단계로

첫째, 구글 리치 결과 테스트로 치명적 오류(critical error)를 잡습니다. 구글은 critical error를 고치는 것이 우선이고, 비치명적 이슈 수정은 자격 요건은 아니지만 품질에 도움이 된다고 안내합니다. 둘째, schema.org의 Schema Markup Validator로 문법과 타입 오타를 확인합니다. 리치 결과 테스트는 구글이 쓰는 기능 위주로 보므로 두 도구의 역할이 다릅니다. 셋째, 배포 후 Search Console의 URL 검사와 개선사항 보고서로 유효·무효 항목 추이를 봅니다.

검증에서 자주 나오는 실수는 세 가지입니다. @id에 실제로 존재하지 않는 URL을 쓴 경우, 주소·전화번호가 화면 표기와 한 글자씩 다른 경우, 이미지 URL이 robots.txt로 막혀 있는 경우입니다. 마지막 항목은 구글 가이드라인이 명시적으로 지적하는 사항입니다.

네이버에서는 어떻게 되나요?

네이버는 구글과 다른 두 가지 조건에서 움직입니다. 첫째, 네이버 검색과 AI 브리핑은 홈페이지보다 네이버 안의 콘텐츠를 훨씬 자주 출처로 씁니다. 네이버 콘텐츠서비스 부문장은 2026년 6월 미디어 라운드테이블에서 AI 브리핑과 AI 검색 결과에 쓰인 콘텐츠 중 블로그·카페·지식iN 같은 자사 UGC 비중이 70%에 이른다고 밝혔습니다(비즈워치, 2026-06-01). 외부 홈페이지가 인용되지 않는다는 뜻은 아니지만, 자리 경쟁이 그만큼 좁다는 뜻입니다. 둘째, 네이버는 구조화 데이터를 읽습니다. 서치어드바이저 웹마스터 가이드는 어떤 타입의 구조화 데이터를 검색 결과에 반영하는지 안내하고 있고, JSON-LD는 네이버와 구글이 함께 권장하는 형식입니다(뱅크샐러드 기술 블로그의 가이드 정리). 이 글에서 만든 JSON-LD는 네이버용을 따로 만들 필요 없이 그대로 씁니다.

법무법인이 네이버에서 실제로 해야 할 일은 다섯 가지입니다.

1. 서치어드바이저에 홈페이지를 등록하고 사이트맵과 RSS를 제출합니다. 등록만 해도 검색로봇(Yeti)이 방문하고, 소유 확인 뒤 사이트맵·RSS를 내면 수집이 빨라집니다. JSON-LD·title·description·Open Graph가 제대로 읽히는지는 ‘웹 페이지 최적화’ 진단으로 확인합니다.
2. 네이버 플레이스에 법무법인을 등록하고, 상호·주소·전화를 홈페이지의 LegalService 값과 글자 단위로 맞춥니다. 지도·플레이스·홈페이지의 NAP가 어긋나면 같은 법인으로 묶이지 않습니다. 분사무소는 지점마다 따로 등록합니다.
3. 블로그는 법인 공식 블로그 하나로 운영하고, 글마다 담당 변호사 성명과 소속을 밝힙니다. 규정은 변호사가 자신의 이름으로 광고하고 법무법인은 광고책임변호사를 표시하도록 하므로 블로그 글도 예외가 아니고, AI 브리핑이 인용할 때도 ‘누가 쓴 글인지’가 드러나는 글이 유리합니다. 홈페이지 칼럼을 그대로 복사하지 말고, 질문 하나에 답하는 짧은 글로 다시 써서 원문 링크를 답니다.
4. 지식iN은 변호사 명의로 답합니다. 네이버 AI 브리핑이 출처로 쓰는 UGC에 지식iN이 포함되고, 법률 질문은 지식iN에서 가장 많이 오갑니다. 사건 결과를 예측하거나 상담을 유도하는 답이 아니라 일반적인 절차·기준을 설명하는 답이어야 규정과 신뢰 양쪽에서 안전합니다.
5. 카페·체험단 형식의 바이럴은 하지 않습니다. 규정은 광고이면서 광고가 아닌 것처럼 가장하는 방법의 광고를 금지해 왔고, 의뢰인 후기 형식의 글은 그 조항에 정면으로 걸립니다.

AI 브리핑이 어떤 질의에서 뜨고 무엇을 출처로 고르는지에 관한 네이버의 공식 기준 문서는 이 글을 쓰는 시점에 공개돼 있지 않습니다. 시중의 ‘노출 조건 N가지’는 업체 관찰이라 표본과 방법이 없습니다. 위 다섯 가지는 추정이 아니라 네이버가 공개한 사실(UGC 70%, 구조화 데이터 반영, 서치어드바이저 수집 방식)과 변호사 광고 규정에서 곧바로 따라 나오는 것만 골랐습니다. 홈페이지 JSON-LD가 구글·AI 답변 엔진·네이버 공통의 기반이고, 네이버에서 실제 노출을 만드는 것은 그 위의 채널 운영입니다. 어느 쪽이든 쓸 수 있는 표현의 한계는 변호사 광고 규정이 정합니다.

무엇부터 점검하면 되나요?

아래 표 순서대로 보시면 됩니다. 한 번에 다 하지 않아도 되고, 1~3번만 정확해도 기계가 우리 법인을 오해할 여지는 크게 줄어듭니다.

마지막으로 하나만 덧붙입니다. 구조화 데이터는 콘텐츠를 대신하지 않습니다. 페이지에 사실 정보가 없으면 스키마가 옮길 내용도 없습니다. 인용되는 문서를 만드는 일은 질문에 답하는 구조로 문서를 다시 쓰는 작업에서 시작하고, JSON-LD는 그 결과를 기계가 오해하지 않게 붙들어 두는 역할을 합니다. BPXG는 병원·금융·법률처럼 규제가 있는 업종의 SEO·AEO·GEO를 규정 검토와 함께 운영합니다.

자주 묻는 질문

참고 자료

아래는 본문 서술의 바탕이 된 공개 자료입니다.

• schema.org — LegalService — 법률 서비스 타입 정의
• schema.org — Attorney — 지원 중단(deprecated) 안내
• schema.org — ProfessionalService — LegalService 도입 경위
• schema.org — LocalBusiness — 정의 및 타입 계층
• schema.org — Notary — 타입 계층 표기
• schema.org — Service — 공식 예제(serviceType·provider·areaServed·hasOfferCatalog)
• schema.org — hasCredential — 속성 정의
• schema.org — EducationalOccupationalCredential — 타입 정의
• Google Search Central — Local Business (LocalBusiness) Structured Data
• Google Search Central — Organization Schema Markup
• Google Search Central — General Structured Data Guidelines
• Google Search Central — Intro to How Structured Data Markup Works
• Google Search Central — Review Snippet (Review, AggregateRating) Structured Data
• Google Search Central Blog — Making Review Rich Results more helpful (2019-09)
• Google Search Central — Search Central 변경 로그 — FAQ 리치 결과 지원 중단(2026-05-08)·문서 삭제(2026-06-15)
• Google Search Central — Article Structured Data
• Google Search Central — Profile Page (ProfilePage) Schema Markup
• 대한변호사협회 법규집 — 변호사 광고에 관한 규정 (2025. 2. 6. 개정 · 2. 10. 시행)
• 대한변호사협회 법규집 — 변호사 광고에 관한 규칙 (2025. 6. 30. 개정)
• 위키문헌 — 변호사업무광고규정 (구 규정 원문)
• 국가법령정보센터 헌재결정례 — 변호사 광고에 관한 규정 제3조 제2항 등 위헌확인 (2021헌마619)
• 리걸타임즈 — 변호사 광고에 ‘전관’ 문구 못 쓴다 (2025-02-24)
• AI타임스 — 네이버, ‘AI 브리핑’ 도입…검색창으로 누구나 이용 가능 (2025-03-24)
• Search Engine Journal — Google Drops FAQ Rich Results From Search (2026-05-10)
• 비즈워치 (2026-06-01) — [챗ICT] 네이버가 블로그·카페에 1조 베팅한 이유 — AI 브리핑 인용 콘텐츠 중 네이버 UGC 70%
• 뱅크샐러드 기술 블로그 — “검색엔진 가이드”를 금융쇼핑 서비스에 SEO로 활용하기 — 네이버·구글의 JSON-LD 권장 정리
• 대한변호사협회 — 변호사업무광고규정 전부개정규정 조문대비표(2021) — 제3조 광고의 주체·제7조 전문 표시·’최고’·’유일’ 금지
• 리걸타임즈 (2025-12-05) — [행정] 광고에 ‘전관 출신’ 용어 사용한 법무법인 로엘 대표변호사 징계 적법 — 서울행정법원 2025. 11. 27. 선고 2025구합54763 등
• schema.org GitHub (2026-01-13) — Expansion of hasCredential to generic Credential (#4685)
• schema.org — Credential — schema.org 30.1 (2026-09-16) 신설 타입