FAQPage 구조화 데이터 전에 본문부터: 얇은 페이지 367개 보강기

FAQPage 구조화 데이터보다 먼저, 무엇이 문제였나?

문제는 AI 검색에 인용될 장치가 없다는 점이 아니라, 인용할 만한 본문 자체가 없다는 점이었습니다. 저희 사이트에는 국내 기업 데이터를 조건별로 묶어 자동으로 만든 페이지가 367개 있었고, 영업 메일의 링크도 이 페이지들로 이어져 있었습니다. 겉으로는 페이지 수가 넉넉해 보였기 때문에, 검색엔진 쪽 기반은 이미 깔려 있다고 여기고 있었습니다.

계기는 대표가 던진 질문 하나였습니다. 영업 메일을 더 보내는 방법을 이야기하던 자리에서 나온 말입니다.

기반이 돼야 콜드메일 효과 있는 거 아니야?

이 질문은 메일 문구가 아니라 메일을 누른 뒤 도착하는 곳을 겨냥합니다. 메일을 아무리 잘 써도, 링크를 누른 사람이 본 페이지가 숫자 몇 줄과 기업 이름 몇 개뿐이라면 신뢰는 거기서 끊깁니다. 그래서 감으로 답하지 않고 데이터로 확인하기로 했습니다. 확인 대상은 페이지마다 실제로 다른 글이 얼마나 있느냐였습니다.

이 상태가 왜 비싼지는 세 갈래로 나눠 볼 수 있습니다. 아래 두 수치는 저희가 직접 잰 값이 아니라, 작업 전에 정리해 둔 유통 채널 리서치 노트의 결론을 옮긴 것입니다. 저희 사이트에서 관측한 수치와 섞이지 않도록 구분해 둡니다.

• 검색엔진 쪽 위험: 리서치 노트는 데이터 제품형 프로그래매틱 SEO 페이지의 1/3이 18개월 안에 유입이 급락하는 “traffic cliff”를 겪는다고 정리했습니다. 저희는 얇은 페이지일수록 그 1/3에 들어갈 가능성이 높다고 봤습니다.
• 영업 메일 쪽 손실: 메일 링크를 누른 사람이 처음 보는 화면이 얇으면, 메일이 만든 관심이 페이지에서 사라집니다.
• AI 검색 쪽 공백: 리서치 노트는 2026년 B2B 구매자의 40~51%가 ChatGPT·Perplexity에서 공급업체 조사를 시작한다고 정리했습니다. 이 사람들에게 닿으려면 AI가 인용할 수 있는 문장 단위가 페이지 안에 있어야 합니다.

세 갈래는 따로 고치면 세 번 일해야 하는 문제처럼 보였습니다. 그러나 셋 다 “페이지마다 읽을 만한 고유한 글이 있는가”라는 한 지점으로 모였습니다. 그래서 이 글의 순서도 FAQPage 구조화 데이터 이야기보다 본문 두께 이야기가 먼저 나옵니다.

처음 잰 숫자: 고유 텍스트 중앙값 338자

측정 단위는 “고유 텍스트”입니다. 페이지마다 공통으로 붙는 머리글·바닥글·안내 문구가 아니라, 그 페이지에만 있는 글자를 셉니다. 자동 생성 페이지는 틀이 같기 때문에, 화면 전체 글자 수를 세면 실제보다 훨씬 두꺼워 보입니다. 검색엔진과 AI가 페이지를 서로 구별하는 근거도 결국 이 고유한 부분입니다.

367개 페이지 각각의 고유 텍스트 길이를 재고, 대표값으로는 평균이 아니라 중앙값을 썼습니다. 일부 페이지만 길고 대부분이 짧으면 평균은 실제 체감보다 높게 나오기 때문입니다. 함께 본 숫자는 두 개입니다. 500자를 넘는 페이지가 몇 개인지, 그리고 300자도 안 되는 페이지가 몇 개인지입니다.

결과는 예상보다 나빴습니다. 고유 텍스트 중앙값은 338자였습니다. 500자를 넘는 페이지는 367개 중 0개였고, 300자 미만인 페이지가 59개였습니다. 한두 페이지가 얇은 게 아니라 367개 전부가 얇은 콘텐츠였습니다.

판단 기준선도 리서치 노트에서 가져왔습니다. 노트는 영어 기준 500단어 이상의 고유 콘텐츠를 임계선으로 보았고, 저희는 이를 한국어로 대략 1,000자 이상에 해당한다고 환산해 두었습니다. 이 환산은 단어와 글자의 비율을 어림한 값이라 정밀한 기준은 아닙니다. 다만 중앙값 338자는 어림을 어느 쪽으로 잡아도 그 선에 한참 못 미쳤습니다.

이 숫자가 의미하는 바는 단순합니다. 페이지 수 367은 자산처럼 보였지만, 페이지 하나하나는 검색엔진 입장에서 서로 거의 구별되지 않는 껍데기에 가까웠습니다. FAQPage 구조화 데이터를 먼저 붙였다면, 껍데기 위에 표시만 하나 더 얹는 셈이었을 겁니다.

세운 가설: 페이지 수가 곧 검색 기반이다

측정 전에 저희가 실제로 품고 있던 가설은 이것이었습니다. “자동 생성 페이지가 367개 있으니 검색 기반은 이미 있다. 남은 일은 영업 메일을 더 많이, 더 잘 보내는 것이다.” 대표의 질문은 바로 이 가설을 겨냥하고 있었습니다.

측정 결과를 보고 나서는 두 번째 가설을 세웠습니다. “페이지마다 이미 데이터가 있으니, 그 데이터에서 페이지마다 다른 해석 문장을 만들어 내면 고유 텍스트를 1,000자 임계선 위로 올릴 수 있다. 그 문장 중 일부를 질문·답변 형태로 만들고 FAQPage 구조화 데이터로 표시하면, AI 검색이 인용할 단위도 같이 생긴다.”

두 번째 가설과 경쟁한 방향도 셋 있었습니다. 얇은 페이지를 검색 색인에서 빼서 페이지 수를 줄이는 방향, LLM으로 페이지마다 자연스러운 글을 써 넣는 방향, 그리고 AI용 안내 파일인 llms.txt를 사이트에 추가하는 방향입니다. 어느 쪽을 고르느냐에 따라 작업량과 위험이 크게 달랐기 때문에, 각 방향을 버리거나 미룬 이유를 따로 남겼습니다.

가설은 어디서 틀렸나?

첫 번째 가설은 측정 한 번으로 무너졌습니다. 페이지 수가 기반이라면 적어도 일부 페이지는 임계선을 넘었어야 합니다. 그런데 367개 중 500자를 넘은 페이지가 0개였습니다. 저희가 “기반”이라고 부르던 것은 페이지의 개수였지 페이지의 내용이 아니었습니다.

이 가설이 오래 살아남은 이유도 적어 둡니다. 페이지는 빌드에 성공했고, 주소로 들어가면 정상적으로 열렸고, 숫자와 기업 목록도 제대로 나왔습니다. 오류가 하나도 없었기 때문에 아무도 글의 양을 세어 볼 이유를 느끼지 못했습니다. 얇은 콘텐츠는 에러 메시지를 내지 않습니다.

돌아보면 이 가설을 깬 것은 새로운 기술이 아니라 측정 한 번이었습니다. 페이지별 고유 텍스트 길이를 세는 일은 어렵지 않았지만, 문제가 보이지 않는 동안에는 아무도 그 일을 하지 않았습니다. 그래서 이후로는 페이지를 찍어 내는 단계와 그 두께를 재는 단계를 한 묶음으로 보기로 했습니다.

색인 제외로 줄이는 방향은 기각했습니다. 자동 생성 페이지는 수가 늘수록 검색 노출 면적이 커지는 구조이고, 저희는 페이지 수 자체를 앞으로 불어날 자산으로 보았습니다. 그래서 줄이는 대신 두껍게 만드는 쪽을 택했습니다. 이 판단이 옳았는지는 뒤의 한계 절에서 다시 다룹니다.

LLM 자연문 생성은 보류했습니다. 367페이지마다 LLM을 호출하면 비용과 시간이 들고, 더 큰 문제는 환각입니다. 기업 데이터 페이지에 실제와 다른 숫자나 사실이 섞이면, 신뢰를 쌓으려던 작업이 신뢰를 깎는 작업으로 바뀝니다. 데이터 템플릿은 숫자가 원천에서 그대로 오고, 다시 돌려도 같은 결과가 나오며, 추가 비용이 0원이었습니다.

llms.txt도 보류했습니다. 당시 판단으로는 FAQPage JSON-LD가 AI 답변 엔진 대응에서 더 표준적인 방법이었고, llms.txt는 효과 신호를 본 뒤 다시 검토하기로 했습니다. 이 판단은 작업 시점의 판단일 뿐이며, 이 기록 안에서 검증한 사실은 아닙니다.

진짜 원인: 데이터는 있는데 해석 문장이 없었다

페이지가 얇았던 원인은 데이터 부족이 아니었습니다. 각 페이지에는 그 묶음에 속한 기업 수, 채용 동향, 부도 위험, 매출, 규모, 벤처 인증 여부 같은 데이터가 이미 연결돼 있었습니다. 없던 것은 그 숫자가 무슨 뜻인지 풀어 주는 문장이었습니다. 표와 숫자는 사람에게는 정보지만, 검색엔진이 페이지를 구별하는 고유한 글로는 거의 잡히지 않습니다.

두 번째 원인은 템플릿의 구조였습니다. 자동 생성 페이지는 하나의 틀을 367번 찍어 내기 때문에, 문장을 넣더라도 모든 페이지에 같은 문장이 들어가면 고유 텍스트는 늘지 않습니다. 예를 들어 “이 업종은 성장 중입니다” 같은 문장을 모든 페이지에 똑같이 넣으면 367페이지가 같은 말을 반복할 뿐입니다. 해석 문장은 페이지의 숫자에 따라, 그리고 기업 규모에 따라 갈라져야 했습니다.

정리하면, 문제의 뿌리는 “데이터를 문장으로 바꾸는 단계”가 빌드 과정에 아예 없었다는 점입니다. 그래서 조치도 페이지를 손으로 고치는 방식이 아니라, 페이지를 찍어 내는 빌드 스크립트에 그 단계를 끼워 넣는 방식으로 정했습니다.

조치: 빌드 스크립트에 고유 문장 생성과 FAQPage JSON-LD 추가

페이지를 만드는 파이썬 빌드 스크립트 build_seo_insights.py에 페이지별 고유 콘텐츠를 생성하는 단계를 추가하고, Next.js 템플릿이 그 결과를 화면에 그리도록 바꿨습니다. 추가한 블록은 다섯 종류입니다.

• 서술문(narrative): 기업 수·채용·부도 위험·매출·규모 해석·벤처 인증·이상적 고객 조건(ICP) 해당 여부를 문장으로 풀어 씁니다. 규모별로 문장이 갈라지기 때문에 페이지마다 내용이 다릅니다.
• 신호 해설(signal_note): 이 묶음에서 눈여겨볼 신호를 해당 페이지의 수치를 넣어 설명합니다.
• FAQ 3~4개: 데이터에서 만든 질문과 답변입니다. FAQPage JSON-LD로 마크업하고, 같은 내용을 화면에서 펼쳐 볼 수 있는 <details> 블록으로도 보여 줍니다.
• 분포 섹션: 이 묶음의 기업이 많이 모인 지역(top_regions)과 업종(top_industries)을 보여 줍니다.
• 기업 미리보기: 페이지에 보여 주는 기업 수를 8곳에서 12곳으로 늘렸습니다.

FAQ를 구조화 데이터에만 넣지 않고 화면에도 띄운 이유는 단순합니다. 마크업에는 있는데 사람 눈에는 안 보이는 문장을 만들고 싶지 않았습니다. 같은 질문과 답변을 JSON-LD와 화면 양쪽에 두면, 검색엔진·AI·사람이 모두 같은 내용을 봅니다. 구조화 데이터가 본문을 대신하는 장치가 아니라 본문을 가리키는 표시로 남습니다.

FAQ를 질문 단위로 만든 데에도 이유가 있습니다. 저희는 AI 답변 엔진이 페이지 전체보다 질문 하나에 붙은 짧은 답을 인용하기 쉽다고 보고 이 형태를 골랐습니다. 질문은 데이터로 답할 수 있는 것만 골랐고, 답에는 그 페이지의 실제 수치를 넣었습니다. 데이터로 답할 수 없는 질문을 지어내면 다시 환각 문제로 돌아가기 때문입니다.

중복을 피하는 장치는 두 가지입니다. 하나는 문장에 들어가는 수치가 페이지마다 다르다는 점이고, 다른 하나는 기업 규모에 따라 문장 자체가 갈라진다는 점입니다. 같은 틀에서 나온 문장이라도, 숫자와 분기가 다르면 페이지마다 다른 글이 나옵니다. 이 작업 전체에 든 추가 비용은 0원이었습니다.

재측정 결과: 367페이지 전부 1,200자 이상

보강 후 같은 방법으로 다시 쟀습니다. 고유 텍스트 중앙값은 338자에서 1,429자로 올라갔고, 367개 중 367개가 1,200자를 넘었습니다. 처음 측정에서 500자를 넘는 페이지가 0개였으니, 가장 짧은 페이지도 예전 어떤 페이지보다 두 배 이상 길어진 셈입니다. 300자 미만이던 59개도 전부 이 선 위로 올라왔습니다.

숫자를 한 가지 방법으로만 재면 그 방법의 맹점까지 같이 믿게 됩니다. 그래서 빌드 스크립트가 만든 글의 길이와 별도로, 개발 서버에서 실제 페이지를 열어 화면에 보이는 한글 글자 수도 셌습니다. 그 값은 약 1,491자였습니다. 생성 단계의 중앙값 1,429자와 비슷한 크기라, 만든 글이 화면에서 잘려 나가거나 숨지 않았다는 쪽으로 읽었습니다.

기능 쪽 확인도 함께 했습니다. 타입 검사(tsc)는 종료 코드 0, 사이트 전체 빌드는 392페이지로 종료 코드 0이었습니다. 392는 이 367개를 포함한 사이트 전체 페이지 수입니다. 개발 서버에서 페이지 주소를 열어 HTTP 200 응답을 받았고, 서버가 내려 준 HTML 안에 서술문·FAQ·FAQPage JSON-LD·분포 섹션이 모두 들어 있는지 확인했습니다.

눈여겨볼 숫자는 중앙값보다 최솟값 쪽입니다. 중앙값 1,429자는 페이지 절반이 그보다 길다는 뜻일 뿐이고, 가장 짧은 페이지가 어디에 서 있는지는 알려 주지 않습니다. 367개 전부가 1,200자를 넘었다는 사실은, 규모별 분기 중 가장 짧은 갈래조차 어림 환산한 임계선 1,000자보다 위에 있다는 뜻입니다. 환산이 다소 빗나가더라도 버틸 여유를 바닥 쪽에 남겨 둔 셈입니다.

이 재측정이 말해 주는 것과 말해 주지 않는 것을 나눠 둡니다. 말해 주는 것은 “페이지마다 고유한 글의 양이 임계선 위로 올라갔고, 화면과 HTML에 실제로 나간다”는 사실입니다. 말해 주지 않는 것은 검색 유입이나 AI 인용이 늘었다는 사실입니다. 이 기록에는 그 숫자가 없습니다.

남는 한계는 무엇인가?

가장 큰 한계는 측정 당일 이 변경이 운영 사이트에 나가지 않았다는 점입니다. 재측정은 개발 서버와 빌드 결과에서 한 것이고, 그날 실제 사이트는 여전히 얇은 페이지를 보여 주고 있었습니다. 배포 전까지 이 작업의 효과는 0이었고, 그래서 운영 배포의 우선순위를 올렸습니다.

두 번째 한계는 문장의 질입니다. 데이터 템플릿으로 만든 글이라 사람이 쓴 자연스러운 글과 같지는 않습니다. 수치와 규모별 분기로 페이지 간 중복은 피했지만, 같은 틀의 말투는 남습니다. 글자 수는 올라갔어도, 읽는 사람이 그 글을 유용하다고 느끼는지는 별개의 질문입니다.

세 번째 한계는 효과 측정이 없다는 점입니다. traffic cliff 1/3이나 AI 리서치 구매자 40~51%는 외부 리서치에서 가져온 숫자이고, 저희 사이트에서 관측한 결과가 아닙니다. 고유 텍스트를 1,429자로 올린 뒤 검색 노출·유입·AI 인용이 실제로 바뀌었는지는 따로 재야 하며, 이 기록은 거기까지 가지 않았습니다.

네 번째는 유지 비용입니다. 기업 데이터는 매달 바뀌고, 페이지는 데이터가 갱신될 때마다 자동으로 다시 만들어집니다. 자동 재생성은 편하지만, 그만큼 갱신 때마다 같은 측정을 다시 돌려 고유 텍스트 중앙값과 1,200자 하한이 유지되는지 확인해야 합니다. 한 번 재고 끝내면 다음 갱신에서 조용히 다시 얇아질 수 있습니다.

마지막으로, 페이지 수를 줄이지 않고 두껍게 만든 판단 자체도 아직 검증 전입니다. 이 판단은 “페이지 수가 앞으로 불어날 자산”이라는 전제 위에 있고, 그 전제는 유입 숫자로 확인해야 합니다. 같은 작업을 프로그래매틱 SEO 관점에서 정리하고 이후 이야기까지 이어 쓴 글은 프로그래매틱 SEO 얇은 콘텐츠 367페이지 보강기입니다.

FAQPage 구조화 데이터를 붙이려면 무엇부터 재야 하나?

자동 생성 페이지에 FAQPage 구조화 데이터를 붙이려 한다면, 마크업보다 먼저 본문 두께를 재 보기를 권합니다. 저희가 실제로 본 숫자는 세 개였습니다.

• 고유 텍스트 중앙값: 페이지 공통 부분을 뺀, 그 페이지에만 있는 글자 수의 중앙값. 저희는 338자에서 출발했습니다.
• 임계선을 넘는 페이지 수: 저희는 500자 초과를 셌고, 처음에는 0개였습니다.
• 바닥 페이지 수: 300자 미만 페이지. 저희는 59개였습니다.

이 세 숫자가 나쁘면 FAQPage JSON-LD를 붙여도 표시할 본문이 빈약합니다. 반대로 데이터가 이미 페이지에 연결돼 있다면, LLM 없이도 데이터를 문장으로 바꾸는 단계를 빌드에 넣는 것만으로 두께를 크게 바꿀 수 있습니다. 질문과 답변은 데이터로 답할 수 있는 것만 만들고, 구조화 데이터와 화면에 같은 내용을 두는 편이 안전합니다.

보강 후에는 두 가지 방법으로 다시 재기를 권합니다. 생성 단계의 글자 수와 렌더된 화면의 글자 수를 따로 재서 비교하면, 만든 글이 실제로 화면에 나가는지까지 확인할 수 있습니다. 저희 경우 1,429자와 약 1,491자로 크게 어긋나지 않았습니다.

자동 생성 페이지나 데이터 기반 홈페이지를 직접 운영하면서 비슷한 문제를 겪고 있다면, 현재 페이지 상태를 함께 재 보는 것부터 시작할 수 있습니다. 필요하면 상담으로 문의해 주세요.