프로그래매틱 SEO 얇은 콘텐츠 367페이지 보강기: 338자에서 1,429자로

프로그래매틱 SEO 페이지 367개는 왜 문제였나?

프로그래매틱 SEO로 자동 생성한 페이지 367개가 전부 얇은 콘텐츠라는 사실을 2026년 6월 11일에야 데이터로 확인했습니다. 프로그래매틱 SEO는 데이터베이스의 행을 조건별로 묶고, 묶음 하나마다 같은 틀의 페이지를 하나씩 찍어 내는 방식입니다. 사람이 글을 한 편씩 쓰지 않아도 페이지 수백 개를 한 번에 만들 수 있어서, 데이터를 가진 작은 팀이 검색 노출 면적을 넓힐 때 자주 씁니다.

저희 페이지는 국내 기업 데이터를 조건별로 묶은 인사이트 페이지였습니다. 각 페이지에는 그 묶음에 속한 기업 몇 곳을 미리 보여 주는 표가 있었고, 나머지는 모든 페이지가 함께 쓰는 틀 문구였습니다. 이 페이지는 검색 유입용이면서 동시에 영업 메일의 링크가 가리키는 도착 페이지였습니다. 메일을 받은 사람이 링크를 눌렀을 때 처음 보는 화면이 이 페이지라는 뜻입니다.

문제는 대표의 질문 한 줄에서 시작했습니다. "기반이 돼야 메일 효과도 있는 것 아니냐." 메일 문구를 다듬기 전에, 메일이 데려가는 페이지가 믿을 만한지부터 봐야 한다는 지적이었습니다. 저희는 이 질문을 의견으로 다루지 않고 데이터로 확인하기로 했습니다.

왜 얇은 페이지가 위험한지는 외부 자료를 근거로 판단했습니다. 저희가 참고한 자료는 데이터 제품의 프로그래매틱 SEO 페이지 가운데 1/3이 18개월 안에 유입이 절벽처럼 떨어진다고 적고 있었고, 그 경계선으로 영어 기준 500단어 이상의 고유 콘텐츠를 들었습니다. 저희는 이 기준을 한국어 1,000자 이상으로 옮겨 잡았습니다. 이 환산은 저희가 정한 근사치이고, 검색 엔진이 한국어 페이지를 같은 선으로 자른다는 확인은 없습니다.

같은 자료에서 한 가지를 더 봤습니다. B2B 구매자의 40~51%가 ChatGPT나 Perplexity 같은 AI 답변 서비스에서 업체 조사를 시작한다는 내용입니다. 검색 엔진 최적화와 별개로, AI 답변에 인용되기 좋은 형태를 갖추는 작업을 GEO(생성형 엔진 최적화) 또는 AEO(답변 엔진 최적화)라고 부릅니다. 얇은 페이지를 두껍게 만드는 일과 AI 답변에 인용될 형태를 갖추는 일을 한 번의 빌드로 같이 처리할 수 있겠다고 판단했습니다.

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

측정 대상은 페이지마다 다른 고유 텍스트의 글자 수였습니다. 모든 페이지에 똑같이 들어가는 틀 문구는 검색 엔진이 보기에 중복이므로 빼고, 그 페이지에만 있는 텍스트만 셌습니다. 367페이지 전부를 같은 방식으로 셌고, 평균 대신 중앙값을 봤습니다. 몇몇 큰 묶음이 평균을 끌어올리면 대부분의 페이지가 얇다는 사실이 가려지기 때문입니다.

결과는 예상보다 나빴습니다. 고유 텍스트 중앙값은 338자였고, 500자를 넘는 페이지는 0개였습니다. 300자에도 못 미치는 페이지가 59개였습니다. 앞에서 잡은 1,000자 기준으로 보면 367페이지 중 기준을 넘는 페이지는 하나도 없었습니다.

측정을 이렇게 잡은 데에도 이유가 있습니다. 페이지 전체 글자 수를 세면 머리말, 메뉴, 바닥글, 공통 안내문이 다 들어가서 모든 페이지가 넉넉해 보입니다. 저희가 처음에 페이지가 괜찮다고 느낀 것도 이런 착시 탓이 컸습니다. 검색 엔진이 페이지의 가치를 볼 때 의미가 있는 부분은 다른 페이지와 겹치지 않는 텍스트이므로, 그 부분만 떼어 세는 것이 맞다고 판단했습니다.

숫자를 보고 나서야 이 페이지들이 왜 그렇게 생겼는지 이해했습니다. 페이지를 만들 때 저희 눈에는 기업 표가 꽉 차 있었기 때문에 내용이 있다고 느꼈습니다. 하지만 표 안의 기업 이름과 수치는 짧은 단어의 나열이고, 그 묶음이 무엇을 뜻하는지 설명하는 문장은 한 줄도 없었습니다.

세운 가설: 데이터에서 문장을 만들면 된다

가설은 단순했습니다. 페이지마다 이미 들고 있는 데이터, 즉 기업 수·채용·부도 위험·매출·규모·벤처 인증 여부 같은 값을 문장으로 풀어 쓰면 고유 텍스트가 1,000자를 넘는다는 가설입니다. 값이 페이지마다 다르니 문장도 페이지마다 달라지고, 그러면 중복 문제도 같이 풀린다고 봤습니다.

1,000자라는 목표도 그대로 두지 않고 조금 높게 잡아 보기로 했습니다. 근사치로 옮긴 기준선에 딱 맞추면, 환산이 조금만 어긋나도 다시 얇은 쪽으로 넘어갈 수 있기 때문입니다. 그래서 재측정 때는 1,000자를 넘었는지와 함께 1,200자를 넘었는지도 같이 보기로 했습니다.

판정 기준도 미리 정했습니다. 첫째, 367페이지 전부가 고유 텍스트 1,000자를 넘어야 합니다. 일부만 넘으면 얇은 페이지가 그대로 남습니다. 둘째, 새로 만든 문장이 서버가 내려주는 HTML에 실제로 들어 있어야 합니다. 빌드 산출물에는 있는데 화면에 안 보이면 검색 엔진도 못 봅니다. 셋째, 타입 검사와 전체 빌드가 깨지지 않아야 합니다.

가설에는 전제가 하나 숨어 있었습니다. 페이지마다 값이 다르면 문장도 충분히 달라진다는 전제입니다. 그런데 같은 틀에 값만 바꿔 끼우면, 숫자 몇 개만 다른 비슷한 문장이 367번 반복될 수 있습니다. 그래서 값만 바꾸는 것이 아니라 묶음의 규모에 따라 문장의 갈래 자체를 나누기로 했습니다. 기업이 많은 묶음과 적은 묶음은 같은 숫자라도 해석이 달라지기 때문입니다.

이 가설을 세우면서 함께 따져 본 다른 길이 셋 있었습니다. 다음 절에서 그 셋이 왜 맞지 않았는지 적습니다.

가설이 틀린 지점은 어디였나?

가장 먼저 틀린 것은 저희가 가설 이전에 깔고 있던 믿음입니다. 페이지 367개를 만들어 두었으니 영업 메일의 기반은 이미 있다고 여겼습니다. 측정해 보니 500자를 넘는 페이지가 0개였고, 이 믿음은 그대로 무너졌습니다. 메일이 데려가는 곳이 얇은 페이지라면 메일 문구를 아무리 고쳐도 도착한 사람이 신뢰할 근거가 없습니다.

두 번째로 버린 생각은 'LLM에게 페이지마다 자연스러운 글을 쓰게 하면 된다'였습니다. 문장 품질만 보면 가장 그럴듯한 길이었습니다. 하지만 367페이지마다 Claude를 따로 호출하면 비용과 시간이 들고, 더 큰 문제는 환각이었습니다. 기업 데이터 페이지에 모델이 지어낸 수치가 한 줄이라도 섞이면 신뢰를 쌓으려던 페이지가 반대로 신뢰를 깎습니다. 그래서 이 길은 보류했습니다. 데이터 템플릿은 수치가 원본에 묶여 있고, 같은 입력이면 같은 결과가 나오며, 추가 비용이 $0입니다.

세 번째는 '얇은 페이지는 색인에서 빼서 수를 줄이자'였습니다. 얇은 페이지 때문에 사이트 전체 평가가 떨어질까 걱정될 때 흔히 고르는 길입니다. 저희는 이 길을 기각했습니다. 페이지 수 자체가 시간이 지나며 유입이 불어나는 자산이라고 판단했고, 줄이기보다 두껍게 만드는 쪽을 골랐습니다. 이 판단은 이후 다른 이유로 다시 뒤집혔는데, 마지막 절에 적었습니다.

AI 답변 서비스용으로 llms.txt 파일을 추가하는 안도 있었습니다. 이건 보류했습니다. 그때 저희는 페이지 안에 넣는 FAQPage 구조화 데이터가 더 표준적인 방법이라고 봤고, 신호가 보이면 다시 검토하기로 했습니다.

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

원인을 다시 정리하면, 페이지가 얇았던 이유는 데이터가 부족해서가 아니었습니다. 각 페이지는 이미 기업 수, 채용, 부도 위험, 매출, 규모, 벤처 인증 같은 값을 들고 있었습니다. 페이지 틀이 그 값을 표로만 보여 주고 문장으로 해석하지 않았을 뿐입니다.

미리보기 표도 같은 문제를 안고 있었습니다. 묶음마다 기업 8곳을 보여 줬는데, 그 8곳의 이름과 숫자는 페이지마다 다르긴 해도 짧은 단어였습니다. 검색 엔진이 보기에도, 메일 링크를 누른 사람이 보기에도 '이 묶음은 이런 특징이 있다'는 설명이 없었습니다. 지역과 업종이 어떻게 퍼져 있는지 같은 분포 정보도 데이터에는 있었지만 화면에는 없었습니다.

영업 메일 쪽에서 보면 문제가 더 분명했습니다. 메일 링크를 눌러 들어온 사람은 이 페이지를 보고 '이 회사가 이 데이터를 제대로 다루는가'를 판단합니다. 기업 이름 8곳이 나열된 표만 있으면, 받는 사람은 그 데이터가 어디서 왔고 무엇을 뜻하는지 알 수 없습니다. 같은 표 위에 '이 묶음은 이런 특징이 있고, 그래서 이런 회사에 의미가 있다'는 문장이 한 단락만 있어도 페이지의 인상은 크게 달라집니다.

그러니 고칠 곳은 데이터 수집이 아니라 페이지를 만드는 빌드 스크립트였습니다. 이미 계산해 둔 값을 문장과 질문·답변으로 바꿔 내보내기만 하면 됐습니다.

조치: 빌드 스크립트에 고유 콘텐츠 블록 다섯 개

페이지 데이터를 만드는 build_seo_insights.py에 페이지별 고유 콘텐츠를 만드는 단계를 추가하고, 화면 템플릿이 그 결과를 그리도록 바꿨습니다. 추가한 블록은 다섯 가지입니다.

• 서술문: 기업 수·채용·부도 위험·매출·규모 해석·벤처 인증·이상적 고객군 해당 여부를 문장으로 풀었습니다. 묶음의 규모에 따라 문장 갈래를 나눠 페이지마다 다른 글이 나오게 했습니다
• 신호 해설: 이 묶음이 어떤 신호를 보이는지 실제 수치를 넣어 설명하는 짧은 단락입니다
• 자주 묻는 질문 3~4개: 데이터에서 바로 답할 수 있는 질문과 답입니다. 화면에는 펼쳐 보는 <details> 요소로 보여 주고, 같은 내용을 FAQPage 구조화 데이터(JSON-LD)로도 넣었습니다
• 분포 섹션: 묶음 안 기업이 어느 지역(top_regions)과 어느 업종(top_industries)에 몰려 있는지 보여 줍니다
• 미리보기 확장: 보여 주는 기업 수를 8곳에서 12곳으로 늘렸습니다

자주 묻는 질문은 데이터로 답할 수 있는 것만 골랐습니다. 이 묶음에 기업이 몇 곳인지, 어느 지역에 많은지, 채용이나 부도 위험 신호가 어떤지처럼 페이지가 이미 들고 있는 값으로 답이 끝나는 질문입니다. 데이터 밖의 판단이나 추천이 필요한 질문은 넣지 않았습니다. 답을 원본 값에서만 만들면, 데이터가 바뀌어도 질문과 답이 함께 맞게 바뀝니다.

FAQPage 구조화 데이터를 넣은 이유는 AI 답변 서비스가 질문과 답이 한 쌍으로 묶인 형태를 인용하기 좋기 때문입니다. 화면에 보이는 질문·답과 구조화 데이터의 내용은 같게 맞췄습니다. 화면에 없는 내용을 구조화 데이터에만 넣으면 검색 엔진이 숨긴 콘텐츠로 볼 수 있어서입니다.

문장은 틀에 값을 끼우는 방식이라 100% 자연스러운 글은 아닙니다. 대신 수치를 원본에서만 가져오고 규모별로 문장 갈래를 나눠, 페이지끼리 같은 문장이 반복되는 일은 피했습니다. 데이터를 매달 새로 받으면 이 문장들도 자동으로 다시 만들어집니다.

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

같은 방식으로 다시 쟀습니다. 고유 텍스트 중앙값은 338자에서 1,429자로 올랐고, 367페이지 중 367페이지가 1,200자를 넘었습니다. 처음 잡은 1,000자 기준을 넘지 못한 페이지는 남지 않았습니다. 300자 미만이던 59개 페이지도 전부 이 선 위로 올라왔습니다.

글자 수만으로는 실제 화면에 문장이 나오는지 알 수 없어서 렌더 결과도 따로 확인했습니다. 개발 서버에서 페이지 하나를 열어 HTTP 200 응답을 받았고, 서버가 내려준 HTML 안에 서술문, 자주 묻는 질문, FAQPage 구조화 데이터, 분포 섹션이 모두 들어 있는 것을 확인했습니다. 화면에 실제로 보이는 한글은 약 1,491자였습니다.

코드 쪽 검증도 같이 했습니다. TypeScript 타입 검사(tsc)가 exit 0으로 끝났고, 전체 빌드도 392페이지를 만들고 exit 0으로 끝났습니다. 392페이지는 인사이트 페이지 367개에 사이트의 다른 페이지를 더한 수입니다.

측정을 한 번만 하고 끝내지 않으려고, 보강 전과 같은 스크립트로 같은 367페이지를 다시 셌습니다. 측정 방법을 바꾸면 숫자가 올라도 개선인지 셈법의 차이인지 가릴 수 없기 때문입니다. 렌더 확인은 HTML 안에 블록이 실제로 들어 있는지를 보는 두 번째 측정이었습니다. 글자 수가 1,429자여도 화면에 안 나오면 의미가 없으니, 두 측정이 모두 통과해야 끝난 것으로 봤습니다.

숫자는 깨끗하게 올랐지만, 이 재측정은 글자 수와 렌더 결과를 다시 잰 것입니다. 검색 순위나 유입, 영업 메일 클릭 뒤의 문의 같은 결과 지표는 이 측정에 들어 있지 않습니다. 이 점은 다음 절에 그대로 남깁니다.

남는 한계는 무엇인가?

첫째, 이 작업을 끝낸 2026년 6월 11일 당시 운영 사이트에는 아직 반영되지 않았습니다. 바뀐 빌드는 개발 서버에서만 확인했고, 실제로 방문자가 보는 페이지는 여전히 얇은 상태였습니다. 운영 배포가 다음 순서로 올라갔습니다. 이후 사이트는 저장소에 반영되면 빌드할 때 페이지 데이터를 다시 만드는 방식으로 바뀌었습니다.

이 배포 지연은 작은 일이 아니었습니다. 대표의 질문은 영업 메일의 도착 페이지가 믿을 만한가였는데, 보강을 마친 날에도 메일 링크를 누른 사람은 여전히 얇은 페이지를 봤습니다. 개발 서버에서 통과한 것과 방문자가 보는 것은 다른 측정이라는 점을 이때 분명히 적어 두었습니다.

둘째, 문장이 틀에서 나온다는 한계는 그대로입니다. 수치와 규모별 갈래 덕분에 페이지끼리 같은 문장은 피했지만, 사람이 읽기에 기계적인 문장은 남아 있습니다. LLM으로 자연스럽게 다듬는 안은 환각 위험 때문에 보류한 상태입니다.

규모별 갈래가 몇 개면 충분한지도 아직 답을 못 냈습니다. 같은 갈래에 들어간 페이지끼리는 문장 뼈대가 같고 숫자만 다릅니다. 검색 엔진이 이 정도 차이를 고유한 콘텐츠로 볼지는 저희가 측정한 글자 수로는 알 수 없습니다.

셋째, 효과를 아직 재지 않았습니다. 외부 자료가 말한 18개월 유입 절벽을 피했는지는 18개월이 지나야 알 수 있고, FAQPage 구조화 데이터가 AI 답변 인용으로 이어졌는지도 이 작업 범위 밖이었습니다. 글자 수 1,429자는 '얇지 않다'는 필요조건일 뿐 '유입이 는다'는 증거가 아닙니다.

넷째, 페이지 수를 지키자는 판단이 오래가지 않았습니다. 저희는 이후 고유성을 더 다듬어 455페이지로 늘렸고, 신호 차원을 넓혀 770페이지까지 키웠습니다. 그런데 나중에 이 770페이지를 통째로 색인에서 뺐습니다. 이유는 얇은 콘텐츠가 아니라, 사이트 전체의 주제를 저희가 실제로 파는 서비스 쪽으로 맞추기 위해서였습니다. 처음에 기각한 '색인 제외'가 다른 이유로 결국 선택된 셈입니다.

돌아보면 이 작업에서 남는 교훈은 글자 수 기준 자체보다 순서입니다. 페이지를 몇 개 만들지 정하기 전에, 그 페이지가 사이트 전체에서 무슨 역할을 맡는지부터 정했어야 했습니다. 비슷한 고민은 프로그래매틱 SEO 키워드 페이지의 한계에 따로 적었습니다.

비슷한 페이지를 운영한다면 무엇부터 재야 하나?

데이터로 페이지를 대량 생성해 두었다면, 먼저 페이지마다 다른 텍스트만 따로 세어 보시길 권합니다. 평균이 아니라 중앙값으로 보고, 일정 기준 아래인 페이지가 몇 개인지까지 함께 세면 문제의 크기가 바로 보입니다. 저희는 이 측정 하나로 '페이지가 있으니 괜찮다'는 믿음을 버렸습니다.

기준선은 외부 자료를 그대로 믿기보다 출발점으로만 쓰시길 권합니다. 저희가 쓴 1,000자는 영어 500단어를 옮긴 근사치였고, 그 선을 넘었다고 검색 성과가 보장되지는 않았습니다. 기준선은 얇은 페이지를 골라내는 거름망으로 쓰고, 성과는 유입과 문의로 따로 재야 합니다.

그다음은 데이터에 이미 있는 값을 문장으로 바꾸는 일입니다. 수치는 원본에서만 가져오고, 규모나 범주에 따라 문장 갈래를 나누면 LLM 없이도 페이지마다 다른 글을 만들 수 있습니다. 화면의 질문·답과 FAQPage 구조화 데이터를 같은 내용으로 맞추는 것도 잊지 마세요.

자동 생성 페이지를 영업 도착 페이지로 쓰고 있는데 어디서부터 손댈지 모르겠다면 상담으로 상황을 알려 주세요. 저희가 겪은 측정 순서를 기준으로 같이 보겠습니다.