추출 가능한 구조: 답변 단위가 드러나는 본문 설계

추출 가능한 구조는 문서에서 질문에 필요한 부분만 골라 하나의 답변 단위로 읽을 수 있는가를 확인하는 카테고리입니다. 생성형 검색이나 답변 도구는 페이지 전체를 그대로 옮기기보다 질문과 가까운 구획, 정의 한 문장, 순서가 있는 절차, 비교 표의 한 행처럼 경계가 드러난 부분을 선택해 사용합니다. 이 카테고리는 그런 경계를 공개 HTML에서 관찰할 수 있는 형식 신호로 살펴봅니다.

8개 항목의 합계는 GEO 100점 중 15점입니다. 각 배점은 Google이나 특정 AI 검색 서비스가 발표한 규격이 아닙니다. 애드브랜치가 추출 실패 가능성과 판정 확실성을 고려해 정한 자체 우선순위입니다. 모든 항목을 통과해도 인용이나 노출을 보장하지 않으며, 점수가 낮다고 내용의 정확성이나 전문성이 낮다는 뜻도 아닙니다.

무엇보다 이 항목들은 내용의 품질이 아니라 형식 신호입니다. 목록과 표를 많이 넣는다고 설명이 더 정확해지지 않습니다. 질문형 제목 아래에 뻔한 답을 붙이고, 모든 문장을 억지로 정의문으로 바꾸고, 짧은 항목을 잘게 쪼개 점수만 맞춘 얇은 문서는 오히려 독자가 맥락을 이해하기 어렵게 만듭니다. 먼저 충분하고 정확한 내용을 쓰고, 실제로 구분되는 의미 단위에만 구조를 부여해야 합니다.

SEO 콘텐츠 구조와 무엇이 다른가

SEO의 콘텐츠 구조 카테고리는 H1에서 하위 제목으로 이어지는 개요, 본문의 존재, 이미지 설명, 링크 이름처럼 문서 전체를 순서대로 읽을 수 있는가에 관심을 둡니다. 반면 이 GEO 카테고리는 전체 문서가 이미 읽힌다는 전제에서 질문에 맞는 일부를 발췌 단위로 추출할 수 있는가를 봅니다.

두 카테고리에 제목 단계와 목록 같은 비슷한 신호가 있어도 목적과 무게가 다른 이유입니다. SEO 관점에서는 제목이 페이지 전체의 길잡이이고, GEO 관점에서는 제목 아래 구획을 독립적으로 선택하기 위한 경계입니다. SEO 문서의 개요를 그대로 반복하기보다, 여기서는 개별 구획의 경계가 어떻게 판정되고 어떤 오해가 생기는지에 집중합니다.

판정은 먼저 본문을 볼 수 있는지 확인합니다

8개 항목은 모두 초기 HTML의 본문을 바탕으로 판정합니다. 검사기는 텍스트와 HTML의 비율이 2% 미만이면서 스크립트가 3개 이상이면 JavaScript 렌더링 의존 가능성이 있다고 봅니다. 또는 본문 텍스트 길이가 0이면 구조를 분석할 재료가 없다고 봅니다. 이때 각 항목은 실패가 아니라 확인 불가로 남고 감점되지 않습니다.

초기 응답에 본문이 없는데 소제목이나 문단이 없다고 연달아 감점하면 하나의 렌더링 문제를 여덟 번 처벌하게 됩니다. 반대로 확인 불가는 통과도 아닙니다. 클라이언트에서 렌더링된 뒤에는 구조가 완전할 수 있지만, 검사기는 그 상태를 보지 않았다는 뜻입니다.

본문을 관찰할 수 있으면 먼저 구획의 뼈대인 소제목과 제목 순서를 보고, 다음으로 특정 답변 형태인 문답·정의·절차를 찾습니다. 이어서 항목형 정보의 그릇인 목록과 표를 살피고, 마지막으로 문단 길이 분포를 봅니다. 앞쪽 항목은 구획의 경계를, 가운데 항목은 구획 안의 의미 유형을, 뒤쪽 항목은 더 작은 발췌 단위를 다룹니다.

채점 규약도 결과를 읽을 때 알아둘 필요가 있습니다. 통과와 정보 판정은 해당 항목의 만점을 받고, 주의는 배점의 절반을 받습니다. 확인 불가와 해당 없음은 점수 계산 대상에서 제외됩니다. 따라서 모든 문서에 필요하지 않은 문답·정의·절차가 발견되지 않았다는 정보 판정은 감점이 아닙니다. 형식을 억지로 추가할 이유가 없는 설계입니다.

구획의 경계를 보는 두 항목

논리적 소제목 밀도 (2점)

검사기는 H2와 H3만 소제목으로 세고, 본문 단어 수와 함께 밀도를 계산합니다. 단어는 한국어 2음절 이상 연속 문자열 또는 라틴 문자·숫자 토큰을 기준으로 셉니다. 본문이 300단어 이상이면 H2/H3 개수 ÷ (단어 수 ÷ 300)으로 300단어당 소제목 수를 구합니다. 300단어 미만이면 H2/H3 개수 자체를 밀도로 사용합니다.

H2와 H3이 하나도 없으면 주의 판정입니다. 긴 본문에서 원하는 부분을 가리킬 구획 경계가 전혀 없기 때문입니다. 반대로 300단어 이상인 글에서 300단어당 소제목이 8개를 초과하면 실패가 아니라 정보 판정입니다. 소제목이 약 37.5단어마다 하나보다 더 자주 나타나는 셈이어서 각 구획이 내용 없이 잘게 쪼개졌을 가능성을 알려 주되, 용어집이나 짧은 문답 모음처럼 촘촘한 구조가 자연스러운 문서도 있으므로 감점하지 않습니다.

실무에서는 제목을 늘리는 방향으로만 대응하기 쉽습니다. 그러나 소제목 하나 아래에 한두 문장만 반복되면 경계는 많아져도 독립된 설명 단위는 생기지 않습니다. 반대로 짧은 공지, 연락처 안내, 단일 답변 페이지에 H2가 없다고 해서 실제 사용성이 나쁘다고 단정할 수 없습니다. 이 항목은 문서 장르를 판별하지 않으므로 결과에 표시된 단어 수와 소제목 수를 함께 읽어야 합니다.

H4 이하 제목은 밀도 계산에 포함되지 않으므로 H4를 많이 쓴 문서가 소제목 0개로 잡힐 수 있습니다.

제목 단계 순서 (2점)

제목이 2개 이상일 때 앞 제목과 다음 제목의 레벨 차이를 순서대로 비교합니다. H2 다음에 H4처럼 아래로 두 단계 이상 건너뛰면 주의 판정입니다. H4 다음에 H2로 올라가는 흐름은 새 상위 구획을 시작할 수 있으므로 문제 삼지 않습니다. 제목이 0개 또는 1개라면 비교할 쌍이 없어 해당 없음으로 제외됩니다.

이 항목은 제목 문구가 논리적인지 평가하지 않습니다. “설치 방법” 아래에 제품 역사만 적혀 있어도 단계만 연속이면 통과합니다. 반대로 시각 디자인 때문에 H2 다음에 H4를 쓴 문서는 내용 관계가 명확해도 경고를 받을 수 있습니다. 검사기가 보는 것은 제목 텍스트의 의미가 아니라 레벨 숫자의 연속성입니다.

소제목 밀도는 구획의 간격을, 단계 순서는 구획의 부모와 자식 관계를 보므로 한 항목을 통과해도 다른 항목이 자동으로 통과하지 않습니다.

답변 형태를 찾는 세 항목

Q&A 구조 (2점)

판정에는 두 경로가 있습니다. 첫 번째는 파싱에 성공한 JSON-LD에서 FAQPage 아래의 Question 노드를 순회하고, acceptedAnswer가 객체나 배열로 연결된 쌍을 하나 이상 찾는 것입니다. 정확히는 질문과 답변 쌍을 세며, JSON-LD 블록이 깨져 파싱에 실패하면 그 블록은 신호를 만들지 않습니다.

두 번째는 본문의 H2 또는 H3 중 질문형 패턴을 가진 제목을 찾는 것입니다. 물음표뿐 아니라 “무엇”, “어떻게”, “왜 ”, “언제”, “어디”, “누가”, “인가”, “는가”, “나요”, “까요”, “하는 법”과 영어 what, how, why가 대상입니다. 제목 문자열이 본문 텍스트 표본에서 나타나는 위치부터 다음 제목 전까지를 답변으로 근사하고, 80자 이상인 답변 쌍이 2개 이상이면 통과합니다.

JSON-LD 경로는 한 쌍이면 충분하지만 본문 경로는 두 쌍이 필요합니다. 구조화 데이터는 질문과 답의 관계가 명시돼 있고, 본문 경로는 텍스트 위치로 관계를 추정하기 때문입니다. 둘 다 없으면 정보 판정으로 만점을 유지합니다. 모든 문서가 질문에 답하는 형식일 필요는 없기 때문입니다.

오탐과 미탐은 제목 위치를 근사하는 방식에서 생깁니다. 같은 제목 문구가 앞 문단에 먼저 등장하면 엉뚱한 위치부터 길이를 셀 수 있고, 제목 텍스트가 본문 표본에서 잘렸으면 답변 길이는 계산되지 않습니다. 질문에 대한 짧고 정확한 답이 79자라면 신호로 인정되지 않는 반면, 80자가 넘는 장황한 답은 인정될 수 있습니다. 이 숫자는 답변 품질 기준이 아니라 너무 짧은 주변 문구를 답변으로 세지 않기 위한 애드브랜치 임계값입니다.

정의문 구조 (2점)

정의 목록인 <dl>이 하나 이상 있거나, 정규식에 맞는 정의문이 두 개 이상이면 통과합니다. 정의문은 줄 시작을 기준으로 앞부분 2자에서 40자 안에 “란”, “이란”, “은”, “는”이 있고, 이어지는 2자에서 100자 안에 “이다”, “입니다”, “뜻한다”, “의미한다”, “말한다” 중 하나가 나타나는 형태입니다.

이 규칙은 개념 설명 페이지에서 용어와 설명의 관계가 문장 자체에 드러나는지를 찾습니다. 하지만 한국어 정의는 훨씬 다양합니다. “GEO를 생성형 검색 최적화라고 부릅니다”처럼 목적격 조사와 다른 서술어를 쓰면 좋은 정의여도 잡히지 않습니다. 반대로 “이 기능은 설정을 의미합니다”처럼 모호한 문장이 패턴에 맞으면 정의로 셀 수 있습니다.

정의문은 우연한 일치를 줄이려고 두 개를 요구하지만, 의미 관계가 명시된 <dl>은 하나만 있어도 신호로 봅니다. 정의가 필요 없는 문서에서 정보 판정이 나오는 것은 정상이며 감점이 아닙니다.

단계별 설명 (2점)

검사기는 본문에서 1단계, 1 단계, step 1, 첫째, 둘째, 먼저, 다음으로 같은 단계 표현을 대소문자 구분 없이 셉니다. 단계 표현이 2개 이상이거나, 단계 표현이 1개 이상이면서 페이지 전체 목록 항목이 2개 이상이면 통과합니다. 그 밖에는 절차가 없는 문서일 수 있으므로 정보 판정으로 만점을 유지합니다.

이 조합은 스냅샷에 순서 목록과 비순서 목록을 구분하는 필드가 없어서 생겼습니다. 검사기는 목록 항목 수는 알지만 그것이 <ol>인지 <ul>인지 알지 못합니다. 따라서 단계 표현과 목록 수를 함께 봐서 절차일 가능성을 높입니다.

이 한계 때문에 “먼저 확인하세요”라는 문장과 관련 링크 목록만으로 통과하거나, 잘 만든 <ol>이 단계 표현을 남기지 않아 신호가 부족할 수 있습니다. 누락 단계, 잘못된 순서, 전제 조건은 사람이 따로 검토해야 합니다.

항목과 문단 단위를 보는 세 항목

목록 또는 표 (2점)

페이지 전체에서 목록 항목이 3개 이상이거나 표가 1개 이상이면 통과합니다. 둘 다 충족할 필요는 없습니다. 목록 항목이 2개뿐이고 표가 없으면 주의 판정이며, 2점 가운데 절반을 받습니다. 이 항목은 8개 규칙 중 선택 형식의 부재를 직접 경고로 다루는 몇 안 되는 항목입니다. 나열·비교 정보를 일반 문단에 묻어 두면 값이나 조건을 분리하기 어려운 경우가 흔하기 때문입니다.

다만 검사기는 그 목록과 표가 본문의 핵심 정보를 담는지 알지 못합니다. 머리글의 메뉴 항목, 푸터 링크, 관련 글 목록이 스냅샷 집계에 포함된다면 본문에 구조화된 정보가 없어도 통과할 수 있습니다. 표 한 개도 내용이 빈약하거나 레이아웃 용도여도 신호가 됩니다. 반대로 두 가지 선택지만 정확히 비교하는 짧은 글은 목록 항목이 2개라는 이유로 주의를 받을 수 있습니다.

점수를 높이려고 평범한 문장을 세 항목으로 쪼개거나 의미 없는 1행 표를 넣는 것은 잘못된 대응입니다. 목록은 서로 같은 수준의 항목이 실제로 셋 이상 있을 때, 표는 공통 축으로 비교할 값이 있을 때 쓰는 편이 낫습니다. 구조의 존재가 내용의 정확성보다 앞설 수는 없습니다.

표 헤더·캡션 (2점)

표가 0개이면 판정 대상이 없어 해당 없음으로 제외됩니다. 표가 하나 이상이면 이름과 달리 현재는 <th>와 <caption>의 존재를 실제로 판정하지 못합니다. 페이지 스냅샷에 표 개수는 있지만 헤더와 캡션 개수는 수집되지 않기 때문입니다. 검사 결과는 확인 불가로 남고 감점하지 않습니다.

따라서 이 항목에서 2점을 잃지 않았다는 사실은 표 구조가 올바르다는 증거가 아닙니다. 현재 구현은 “표가 있으니 사람이 헤더와 설명을 확인해야 한다”는 진단 지점을 만드는 역할만 합니다. 표 안의 첫 행이 시각적으로 굵게 보이더라도 <td>라면 열의 의미가 기계적으로 연결되지 않을 수 있고, 캡션이 화면 밖 텍스트로 제공돼도 스냅샷에서는 확인할 수 없습니다.

이 항목의 배점은 표의 행과 열을 해석할 때 머리글과 설명이 중요하다는 애드브랜치의 우선순위를 나타냅니다. 그러나 수집 정보가 없는 현재 상태에서는 그 중요도를 실제 감점으로 바꾸지 않습니다. 관찰할 수 없는 것을 실패로 단정하지 않는 원칙이 배점보다 앞섭니다.

짧은 문단 비율 (1점)

먼저 본문 텍스트 표본을 줄바꿈 기준으로 나누고, 앞뒤 공백을 제거한 뒤 빈 조각을 버립니다. 이 가운데 40자 이상인 문단만 표본으로 사용합니다. 대상 문단이 3개 미만이면 비율이 쉽게 흔들리므로 해당 없음으로 제외합니다.

표본이 3개 이상이면 길이가 40자에서 350자인 문단 수를 전체 40자 이상 문단 수로 나눕니다. 그 비율이 0.70 이상이면 통과하고, 미만이면 주의 판정입니다. 예를 들어 대상 문단이 10개라면 7개 이상이 350자 이하여야 합니다. 39자 이하 문단은 짧은 문단으로 가산되는 것이 아니라 계산에서 완전히 빠집니다.

배점이 1점인 이유는 문단 길이가 발췌 편의에 도움을 줄 수 있어도 좋은 글의 보편 기준은 아니기 때문입니다. 법률 조항, 연구 방법, 복잡한 예외 설명은 350자를 넘겨야 정확할 수 있습니다. 반대로 350자 이하 문단도 여러 논점을 뒤섞으면 추출 단위로 적합하지 않습니다. 글자 수는 의미 단위의 대리 신호일 뿐입니다.

줄바꿈 기반 분할에도 한계가 있습니다. 파서가 문단 사이에 줄바꿈을 남긴다는 전제이므로, 실제 DOM의 <p> 경계와 텍스트 표본의 줄바꿈이 어긋나면 문단 수가 달라질 수 있습니다. 결과가 예상과 다르면 화면의 문단 길이보다 초기 HTML에서 수집된 텍스트 경계를 먼저 확인해야 합니다.

결과를 실무에서 읽는 순서

첫째, 확인 불가가 여러 개라면 개별 형식을 고치기 전에 초기 HTML에 본문이 있는지 확인합니다. 같은 렌더링 원인이 여덟 항목을 동시에 막았을 수 있습니다.

둘째, 주의와 정보를 구분합니다. 소제목 없음, 제목 단계 건너뜀, 목록·표 부재, 긴 문단 비율은 주의가 될 수 있습니다. 반면 과도한 소제목, Q&A·정의·단계 구조 부재는 정보이며 만점을 유지합니다. 정보 판정을 실패처럼 보고 불필요한 형식을 추가하면 문서가 더 얇아질 수 있습니다.

셋째, 수치 바로 아래의 원문을 확인합니다. 300단어당 소제목 8개, 답변 80자, 정의문 2개, 목록 항목 3개, 문단 40자·350자·70% 같은 숫자는 문서 품질의 규격이 아닙니다. 자동 판정이 일관되게 경계를 긋기 위한 임계값입니다. 경계에서 한 글자나 한 항목 차이로 결과가 바뀌었다면 점수보다 실제 의미 구조를 우선해야 합니다.

넷째, 서로 다른 형식이 같은 내용을 중복하지 않는지 봅니다. 본문 Q&A와 FAQPage JSON-LD가 함께 있다면 화면에 보이는 답과 구조화 데이터가 어긋나지 않아야 합니다. 단계 설명을 목록으로 바꿨다면 앞뒤 문단에서 같은 절차를 다시 길게 반복할 필요가 없습니다. 추출 가능한 구조는 내용을 여러 형식으로 복제하는 일이 아니라, 한 번 쓴 내용의 경계를 분명히 하는 일입니다.

이 검사가 확인하지 못하는 것

• 내용의 사실성·깊이·독창성을 평가하지 않습니다. 틀린 정의, 빠진 단계, 왜곡된 비교도 형식 조건만 맞으면 통과할 수 있습니다.
• 형식이 문서 장르에 적합한지 판단하지 않습니다. 에세이, 공지, 짧은 답변처럼 목록이나 정의가 불필요한 문서에도 같은 임계값을 적용합니다.
• 초기 HTML만 봅니다. JavaScript 렌더링 의존이 의심되거나 본문이 없으면 모든 항목을 확인 불가로 두며, 렌더링 이후 DOM은 확인하지 않습니다.
• 텍스트 표본과 집계 필드에 의존합니다. 질문 제목의 위치, 답변 길이, 문단 경계는 실제 DOM 관계가 아니라 수집된 텍스트에서 근사합니다.
• 목록의 종류를 구분하지 못합니다. 순서 목록과 비순서 목록이 같은 항목 수로 집계되므로 단계별 설명에서 오탐과 미탐이 생길 수 있습니다.
• 목록과 표의 위치를 판단하지 못합니다. 내비게이션이나 푸터의 항목이 본문 구조 신호처럼 집계될 수 있습니다.
• 표의 헤더와 캡션을 실제로 수집하지 않습니다. 표 헤더·캡션 항목은 표가 있을 때 확인 불가로 남고 감점하지 않습니다.
• 문장과 제목의 의미를 이해하지 않습니다. 정규식과 글자 수가 맞는지만 보므로 자연스럽지만 다른 표현은 놓치고, 의미가 빈약한 문장은 잡을 수 있습니다.
• 인용 가능성이나 노출을 예측하지 않습니다. 배점과 임계값은 애드브랜치의 자체 휴리스틱이며 Google 또는 AI 검색 사업자의 공식 기준이 아닙니다.

형식 신호는 좋은 내용을 대신하지 못합니다. 목록과 표를 늘리거나 문단을 기계적으로 자르는 최적화는 점수 일부를 바꿀 수 있어도 독자에게 더 나은 답을 만들지는 않습니다. 형식만 맞춘 얇은 문서는 맥락, 근거, 예외를 잃어 오히려 사람과 답변 도구 모두에게 불리할 수 있습니다.

이어서 읽기

항목별 수정 방법과 코드 예시는 이 문서 아래의 자동 생성 표에서 확인할 수 있습니다. 제목 계층을 더 세밀하게 설계하려면 제목 구조 가이드, GEO 전체 점검 순서를 보려면 GEO 체크리스트, SEO와 GEO가 같은 본문을 서로 다른 관점에서 보는 이유를 이해하려면 SEO와 GEO의 차이를 함께 읽어 보세요.