효율적이면서도 위험할 수 있는, 프로그래매틱 SEO·GEO 마케팅

프로그래매틱 SEO란 무엇인가요?

프로그래매틱 SEO는 글을 한 편씩 기획해서 쓰는 대신, 보유한 데이터베이스와 페이지 템플릿, 그리고 둘을 결합하는 조합 규칙으로 페이지를 대량 생성하는 방식입니다. 사람이 쓰는 것은 페이지 하나가 아니라 ‘페이지를 만드는 규칙’이고, 실제 페이지 수는 데이터 행의 개수만큼 늘어납니다. 데이터가 1만 행이면 페이지도 1만 개가 됩니다.

이 방식이 겨냥하는 것은 검색량이 큰 대표 키워드가 아니라, 검색량은 작지만 종류가 많은 긴 꼬리(롱테일) 검색입니다. 한 페이지가 월 수십 회 노출되더라도 그런 페이지가 수천 개 쌓이면 합계가 대표 키워드 하나에 맞먹거나 넘어설 수 있습니다. 개별 페이지의 경쟁 강도가 낮다는 점도 장점입니다.

조합 규칙의 일반적인 패턴

업종을 가리지 않고 반복해서 쓰이는 패턴은 대략 다음과 같습니다. 어떤 패턴을 고르느냐보다, 그 자리에 채울 고유한 데이터가 있느냐가 더 중요합니다.

• [지역] × [서비스] — 지역 단위로 공급·가격·업체 정보가 다를 때
• [A] vs [B] 비교 — 두 대상의 사양·요금·조건을 구조적으로 대조할 수 있을 때
• [상품·노선] 가격·시세 추이 — 시간에 따라 값이 변하고 그 기록이 남을 때
• [도구] 연동·설정 방법 — 대상마다 절차와 제약이 실제로 다를 때
• [직무] × [조건] 통계 — 분포·중앙값처럼 집계해야 의미가 생기는 데이터일 때

전통적인 콘텐츠 제작과 무엇이 다른가요?

흔한 오해 — 페이지 수가 성과의 단위라는 생각

프로그래매틱 프로젝트가 잘못되는 가장 흔한 출발점은 목표를 페이지 수로 잡는 것입니다. “1만 페이지 생성”은 측정하기 쉬워서 목표처럼 보이지만, 그 자체로는 아무 결과도 아닙니다. 실제로 확인해야 하는 값은 색인된 페이지 수, 노출이 발생한 페이지 비율, 그리고 클릭이 한 번이라도 발생한 페이지 비율입니다. 이 세 값은 생성 수와 전혀 다르게 움직입니다.

기획 단계에서 이 구분을 해 두지 않으면, 출시 후 “페이지는 다 올라갔는데 유입이 없다”는 보고가 나오고 원인 분석이 불가능해집니다. 생성은 됐지만 색인이 안 된 것인지, 색인은 됐지만 노출이 없는 것인지, 노출은 되는데 클릭이 없는 것인지에 따라 손을 대야 할 곳이 완전히 다르기 때문입니다.

프로그래매틱 GEO는 무엇이 다른가요?

프로그래매틱 GEO는 같은 방식을 AI 답변에 인용되기 위한 목적으로 쓰는 것입니다. 구글은 AI 개요와 AI 모드가 하나의 질문을 하위 주제와 여러 데이터 소스에 걸쳐 나누어 관련 검색을 여러 번 실행하는 방식, 이른바 쿼리 팬아웃(query fan-out)을 사용할 수 있다고 설명합니다. 사용자가 던진 질문 하나가 내부에서는 여러 개의 세부 질의로 쪼개진다는 뜻입니다.

여기서 프로그래매틱 방식의 논리가 나옵니다. 쪼개진 세부 질의 하나하나에 정확한 답과 수치를 담은 페이지가 존재한다면, 그 페이지는 인용 후보가 될 수 있습니다. 반대로 대표 키워드 페이지 한 장만 가지고 있으면 팬아웃된 세부 질의와는 잘 맞지 않을 수 있습니다. 커버리지를 넓히면 인용될 수 있는 자리도 함께 늘어난다는 것이 이 방식의 기대입니다.

다만 이것은 가능성이지 보장이 아닙니다. 구글은 AI 개요·AI 모드에 나오기 위해 따로 갖춰야 할 요건은 없으며, 색인되어 스니펫과 함께 표시될 수 있는 페이지가 대상이라고 안내합니다. 구글 기준으로 보면 프로그래매틱 GEO 역시 프로그래매틱 SEO로 만든 페이지가 먼저 색인되고 품질 기준을 통과해야 시작되는 셈입니다. AI 답변이 글을 어떤 단위로 읽고 인용하는지는 GEO 마케팅 방법론에서 따로 다뤘습니다.

왜 데이터가 쌓인 플랫폼에 특히 효과적인가요?

템플릿이 ‘빈 틀’이 되지 않으려면 페이지마다 그 페이지에만 있는 데이터가 들어가야 하기 때문입니다. 거래·가격·리뷰·재고·이용 기록처럼 서비스를 운영하는 동안 자동으로 쌓이는 데이터를 가진 플랫폼은, 조합을 만들 때마다 다른 곳에 없는 내용이 자연스럽게 채워집니다. 데이터가 갱신되면 페이지의 최신성도 함께 유지됩니다.

경쟁 관점에서도 차이가 큽니다. 템플릿 구조와 URL 설계는 하루면 베낄 수 있지만, 수년간 쌓인 거래 기록과 사용자 후기는 복제할 수 없습니다. 자사만 보유한 데이터가 경쟁사가 따라 하기 어려운 구조적 우위가 되는 이유가 여기에 있습니다.

어떤 데이터가 페이지가 되나요

아래 표는 실제 고객 사례가 아니라 이해를 돕기 위한 가정 예시입니다. 자사 데이터를 이 틀에 대입해 보면 만들 수 있는 페이지 단위가 대략 잡힙니다.

반대로 말하면, 이 표의 왼쪽 칸이 비어 있는 조직에서는 프로그래매틱 방식이 위험한 선택이 됩니다. 채울 데이터가 없는데 페이지 수만 늘리면 남는 것은 문구만 바뀐 껍데기이기 때문입니다.

데이터가 있어도 공개하지 못하는 경우

보유량과 공개 가능성은 다른 문제입니다. 개인을 식별할 수 있는 정보, 계약상 외부 공개가 제한된 거래 조건, 제휴사 요청으로 노출 범위가 정해진 가격 정보는 데이터베이스에 있어도 페이지에 쓸 수 없습니다. 기획 초기에 법무·제휴 담당과 공개 범위를 확정하지 않으면, 템플릿을 다 만든 뒤에 핵심 필드를 빼야 하는 상황이 생깁니다. 그렇게 빠진 자리를 일반 설명으로 메우면 그 순간 페이지가 얇아집니다.

집계 단위를 조정해 해결되는 경우도 있습니다. 개별 거래는 공개하기 어려워도 월 단위 중앙값이나 구간별 분포는 가능할 수 있습니다. 이때는 집계 기준을 페이지에 명시하는 것이 중요합니다. 같은 숫자라도 기준이 적혀 있지 않으면 인용하기 어려운 값이 되고, 사용자도 다른 출처와 비교할 수 없습니다.

가장 큰 위험인 얇은 콘텐츠는 어떻게 생기나요?

얇은 콘텐츠(thin content)는 대개 세 가지 형태로 생깁니다. 지역명이나 키워드만 바꿔 끼운 페이지, 해당 조합의 데이터가 사실상 비어 있는 페이지, 다른 곳의 정보를 가져와 이어 붙인 페이지입니다. 셋 다 페이지 수는 늘지만 검색한 사람이 새로 얻는 것은 없습니다.

구글 스팸 정책은 이를 대규모 콘텐츠 남용(scaled content abuse)으로 규정합니다. 정의는 “사용자를 돕기보다 검색 순위를 조작할 목적으로 많은 페이지를 생성하는 것”이고, 정책 문서가 드는 예시에는 생성형 AI 등 도구로 가치를 더하지 않고 페이지를 많이 만드는 경우, 피드나 검색결과를 스크래핑해 동의어 치환·번역 같은 자동 변환만 거친 페이지를 대량 생성하는 경우, 여러 웹페이지의 내용을 가치 추가 없이 이어 붙이는 경우, 독자에게는 의미가 거의 없지만 검색 키워드를 담은 페이지를 대량 생성하는 경우가 포함됩니다.

이미 정리가 진행된 영역입니다

구글은 2024년 3월 업데이트를 알리며 저품질·비독창적 콘텐츠를 40% 줄일 것으로 예상한다고 했고, 이후 검색 결과에서 그런 콘텐츠가 45% 줄었다고 밝혔습니다. 프로그래매틱 방식으로 찍어낸 얇은 페이지는 정확히 이 조정의 대상이 되는 유형입니다. 또한 구글은 생성형 AI 도구로 사용자에게 가치를 더하지 않고 많은 페이지를 만드는 것이 대규모 콘텐츠 남용 정책 위반이 될 수 있다고 별도 문서로 안내하고 있습니다.

판단이 갈리는 경계 사례

실무에서 자주 애매해지는 유형이 몇 가지 있습니다. 첫째는 공공 데이터를 그대로 페이지화한 경우입니다. 출처가 공개 데이터라는 사실 자체는 문제가 아니지만, 원본을 재배열만 한 페이지는 ‘가치 추가 없이 이어 붙임’에 가까워집니다. 같은 데이터라도 다른 데이터와 결합하거나, 해석·비교·주의점을 더했다면 판단이 달라집니다.

둘째는 데이터는 고유한데 분량이 짧은 경우입니다. 분량이 짧다는 것만으로 얇은 콘텐츠가 되지는 않습니다. 검색한 사람의 질문이 짧게 끝나는 종류라면 짧은 페이지가 오히려 맞습니다. 문제는 분량이 아니라 대체 가능성입니다. 다른 페이지로 대체해도 똑같으면 얇고, 여기서만 확인할 수 있으면 짧아도 얇지 않습니다.

셋째는 필터 조합 URL입니다. 커머스나 중개 서비스에서 정렬·필터 조합마다 색인 가능한 URL이 생기면, 의도치 않게 프로그래매틱 페이지를 대량 생성한 것과 같은 상태가 됩니다. 이 경우는 콘텐츠 기획 문제가 아니라 색인 관리 문제로 접근해야 하며, 검색 수요가 있는 조합만 색인을 허용하고 나머지는 정규 URL로 정리하는 편이 안전합니다.

GEO 관점에서는 더 불리합니다

AI 답변은 여러 출처를 비교해 하나의 서술을 만듭니다. 이때 인용할 이유가 생기는 페이지는 다른 출처에 없는 값이나 관점을 가진 페이지입니다. 같은 문장 구조에 지역명만 바뀐 페이지가 수천 개 있으면, 모델 입장에서는 그중 하나를 고를 근거도 없고 고를 필요도 없습니다. 검색 순위에서는 운 좋게 몇 개가 노출될 수 있어도, 인용 경쟁에서는 처음부터 후보가 되지 못합니다.

대량으로 색인시킨 뒤에는 왜 되돌리기 어렵나요?

색인을 취소하는 신호가 반영되려면 구글이 그 페이지를 다시 크롤링해야 하기 때문입니다. 구글은 noindex 태그가 크롤링 이후에 처리되며, 페이지의 중요도에 따라 Googlebot이 다시 방문하기까지 수개월이 걸릴 수 있다고 안내합니다. 프로그래매틱으로 만든 페이지는 대부분 중요도가 낮은 쪽에 속합니다. 올리는 데 하루가 걸렸어도 내리는 데는 그만큼 걸리지 않습니다.

두 번째 함정은 robots.txt입니다. 급한 마음에 해당 경로를 robots.txt로 차단하면 크롤러가 페이지를 읽지 못하므로 noindex 지시를 확인할 수 없고, 결과적으로 정리가 더 늦어집니다. 구글은 noindex가 작동하려면 해당 페이지가 robots.txt로 차단되어 있지 않아야 한다고 명시합니다. 또한 차단된 URL은 크롤링 대기열에 훨씬 오래 남는 반면, 404 상태 코드는 해당 URL을 다시 크롤링하지 말라는 강한 신호가 된다고 설명합니다.

크롤링 시간과 사이트 전체 신호

세 번째는 크롤링 효율입니다. 구글은 중복이거나 크롤링을 원하지 않는 URL이 많으면 구글의 크롤링 시간이 낭비된다고 설명합니다. 크롤링 예산을 실제로 신경 써야 하는 규모로는 고유 페이지 100만 개 이상이면서 주 1회 정도 바뀌는 대형 사이트, 또는 1만 개 이상이면서 매일 빠르게 바뀌는 사이트를 예로 듭니다. 프로그래매틱 프로젝트는 이 규모에 쉽게 도달합니다.

네 번째는 범위의 문제입니다. 구글의 순위 시스템은 기본적으로 페이지 단위로 작동하지만, 사이트 전체 신호와 분류기도 함께 사용되어 페이지 이해에 기여한다고 안내합니다. 동시에 구글은 좋은 사이트 신호가 모든 페이지의 높은 순위를 보장하지 않고 나쁜 신호가 모든 페이지를 낮추는 것도 아니라고 덧붙입니다. 따라서 “얇은 페이지를 만들면 사이트 전체가 벌점을 받는다”고 단정할 수는 없지만, 잘 만든 페이지까지 영향을 받을 가능성은 남는다고 보는 편이 안전합니다.

되돌리기 비용을 미리 계산해 두기

기획 단계에서 한 번은 계산해 볼 값이 있습니다. “이 프로젝트가 실패했다고 판단했을 때, 원상 복구에 얼마나 걸리는가”입니다. 생성 수가 많을수록, 그리고 개별 페이지의 중요도가 낮을수록 이 값은 커집니다. 재크롤링 속도를 직접 통제할 수 없기 때문에, 복구 기간은 대체로 출시 속도보다 훨씬 길다고 가정하는 편이 현실적입니다.

이 계산이 의미 있는 이유는 출시 규모를 정하는 근거가 되기 때문입니다. 감당할 수 있는 복구 기간을 먼저 정하고 거기에 맞춰 첫 묶음 크기를 잡으면, 최악의 경우에도 사업 일정이 흔들리지 않습니다. 반대로 규모를 먼저 정하고 나중에 복구 계획을 세우면 선택지가 거의 남지 않습니다.

그래도 쓰려면 어떤 원칙으로 운영해야 하나요?

위험의 대부분은 ‘전부 한꺼번에’에서 옵니다. 만들 수 있는 조합을 모두 만들고, 만든 것을 모두 색인시키고, 그다음에 결과를 보는 순서가 문제입니다. 순서를 뒤집으면 같은 방법이 꽤 안전해집니다.

수요와 데이터 임계값으로 조합을 거른다

첫째, 실제 검색 수요가 확인되는 조합만 만듭니다. 데이터베이스가 허용한다고 해서 모든 교차 조합을 생성할 이유는 없습니다. 둘째, 데이터 임계값을 정합니다. 리뷰·거래·가격 데이터가 일정 기준 이상 쌓인 조합만 색인을 허용하고, 기준에 미달하는 페이지는 noindex 상태로 두었다가 데이터가 차면 공개합니다. 임계값 설계는 이 프로젝트에서 가장 중요한 의사결정입니다. 비어 있는 페이지가 색인되지 않게 하는 유일한 구조적 장치이기 때문입니다.

임계값은 한 번 정하고 끝나는 값이 아닙니다. 처음에는 다소 보수적으로 잡아 색인 페이지 수를 줄이고, 노출·클릭 지표가 안정적으로 나오면 조금씩 낮춰 커버리지를 넓히는 방식이 안전합니다. 반대 방향, 즉 넓게 열어 두었다가 나중에 조이는 방식은 앞에서 본 것처럼 회수 비용이 큽니다.

작은 묶음으로 나눠 출시한다

BPXG가 권장하는 방식은 한 번에 전량을 공개하지 않고 수십~수백 개 단위 묶음으로 올리는 것입니다. 묶음별로 사이트맵을 분리해 두면 서치 콘솔에서 묶음 단위의 색인률·노출·클릭을 구분해 확인할 수 있고, 지표가 받쳐 줄 때만 다음 묶음으로 확장하면 됩니다. 이것은 구글의 규정이 아니라 회수 가능성을 확보하기 위한 운영 방침입니다.

묶음을 나누는 기준은 데이터 성격에 따라 다릅니다. 지역형이면 권역별로, 카테고리형이면 상위 카테고리별로 나누는 것이 해석하기 쉽습니다. 무작위로 나누면 지표 차이가 묶음 특성 때문인지 품질 때문인지 구분되지 않습니다. 확장 여부를 판단할 수 있는 단위로 쪼개는 것이 핵심입니다.

해석을 넣고 사람이 표본을 읽는다

템플릿 문장과 숫자만 나열된 페이지는 데이터가 있어도 얇게 읽힙니다. 추이 요약, 비교 시 유의점, 값이 튀는 구간에 대한 설명처럼 데이터를 해석한 문장이 들어가야 합니다. 그리고 출시 전마다 무작위 표본을 뽑아 사람이 직접 읽습니다. 자동 검사로는 ‘문법은 맞지만 읽을 이유가 없는 페이지’를 걸러내지 못합니다.

표본 검수에서 실제로 보는 것은 세 가지입니다. 데이터가 상식적인 범위 안에 있는지(이상값·단위 오류), 해석 문장이 그 데이터와 맞는지(값은 하락인데 문장은 상승이라고 쓰는 오류), 그리고 조합 자체가 말이 되는지입니다. 세 번째가 가장 자주 걸립니다. 규칙상 생성은 되지만 현실에서는 존재하지 않는 조합이 섞여 들어오는 일이 흔하기 때문입니다.

기준일·구조·고지를 갖춘다

갱신 주기를 정하고 페이지에 기준일과 집계 기준을 표시합니다. 상위 목록(허브)과 개별 페이지를 내부 링크로 연결해 크롤러와 사용자가 모두 구조를 파악할 수 있게 합니다. 페이지 성격에 맞는 구조화 데이터를 붙이면 내용이 기계적으로 해석되기 쉬워집니다. 문장 생성에 AI를 사용했다면, 구글이 제시한 자가진단 항목 중 “AI 생성을 포함한 자동화 사용이 고지 등을 통해 방문자에게 명확히 드러나는가”를 함께 점검하는 것이 좋습니다.

갱신을 멈추는 순간 프로그래매틱 페이지는 가장 빠르게 낡습니다. 기준일이 1년 전으로 남아 있는 가격 추이 페이지는 데이터가 있어도 신뢰를 잃습니다. 파이프라인을 만들 때 생성보다 갱신 자동화를 먼저 설계해 두면, 운영 인력이 바뀌어도 페이지가 방치되지 않습니다.

출시 전에 던져야 할 질문은 무엇인가요?

하나뿐입니다. “이 페이지가 검색한 사람에게 실제로 효익을 주는가?” 나머지 기술적 점검은 모두 이 질문을 확인하는 보조 수단입니다. 페이지 수 목표, 예상 유입량, 경쟁사 페이지 수는 이 질문을 대체하지 못합니다.

구글도 ‘검색엔진 우선 콘텐츠’를 가려내기 위한 자가진단 질문을 공개하고 있습니다. “일부라도 검색 결과에서 성과가 나기를 바라며 여러 주제에 걸쳐 많은 콘텐츠를 만들고 있는가”, “여러 주제의 콘텐츠를 만들기 위해 광범위한 자동화를 사용하고 있는가”, “다른 사람들의 말을 가치 추가 없이 요약하는 데 그치고 있는가”가 그것입니다. 프로그래매틱 프로젝트 기획서를 이 세 질문에 대입해 보면, 대체로 방향이 바로 드러납니다.

체크리스트 중 가장 강력한 항목은 세 번째입니다. 템플릿 문장을 전부 지워도 의미가 남는가. 남는다면 그 페이지의 본체는 데이터이고, 문장은 데이터를 읽기 쉽게 도와주는 역할을 하고 있다는 뜻입니다. 남지 않는다면 반대입니다. 데이터는 장식이고 문장이 본체인데, 그 문장은 모든 페이지에서 동일합니다.

같은 주제, 두 가지 결과

규제 업종이나 신뢰가 중요한 분야에서도 쓸 수 있나요?

조건이 더 까다로워집니다. 의료·금융·법률처럼 잘못된 정보가 실제 피해로 이어질 수 있는 분야에서는, 자동 생성된 문장이 사실과 어긋났을 때의 비용이 검색 성과보다 훨씬 큽니다. 이런 분야에서 프로그래매틱 방식을 쓴다면 범위를 사실관계가 기계적으로 확정되는 데이터로 좁히는 편이 안전합니다. 해석이나 권고가 들어가는 영역은 사람이 쓰는 쪽이 맞습니다.

또 하나는 책임 주체 표시입니다. 자동 생성된 페이지라도 그 내용을 누가 책임지는지, 데이터 출처가 무엇인지, 어느 시점 기준인지가 드러나야 합니다. 작성자와 조직의 신뢰 신호를 정리하는 작업은 E-E-A-T 관점에서 별도로 다뤄야 하는 주제이고, 대량 생성 페이지에서는 특히 소홀해지기 쉽습니다.

생성형 AI를 문장 작성에 쓸 때의 경계

AI로 템플릿 문장을 만드는 것 자체는 금지 사항이 아닙니다. 구글도 생성 방식이 아니라 결과의 가치를 기준으로 본다고 밝히고 있습니다. 문제가 되는 것은 가치를 더하지 않으면서 페이지 수만 늘리는 용도로 쓰는 경우입니다. 데이터에서 계산된 값을 사람이 읽기 좋은 문장으로 바꾸는 작업과, 데이터 없이 그럴듯한 설명을 채워 넣는 작업은 겉보기에 비슷해도 성격이 완전히 다릅니다.

실무에서 이 둘을 가르는 간단한 기준이 있습니다. 생성된 문장이 데이터와 모순될 수 있는가입니다. 모순 검사가 가능하다면 그 문장은 데이터에 종속된 서술이고, 검사할 대상 자체가 없다면 데이터와 무관하게 생성된 문장입니다. 후자가 많을수록 얇은 콘텐츠에 가까워집니다.

BPXG는 프로그래매틱 SEO·GEO를 제안할 때 무엇을 먼저 보나요?

보유 데이터부터 봅니다. 어떤 데이터가 얼마나 쌓여 있고, 갱신되는지, 공개해도 되는지를 확인하는 것이 첫 단계입니다. 이 단계에서 채울 데이터가 충분하지 않다고 판단되면 프로그래매틱 방식을 권하지 않습니다. 페이지 수를 늘리는 일 자체가 목적이 되는 순간, 앞에서 정리한 위험이 그대로 현실이 되기 때문입니다.

데이터가 확인되면 수요가 있는 조합 선별 → 효익 기준을 통과하는 템플릿 설계 → 작은 묶음 출시 → 측정 후 확장 순서로 진행합니다. 측정은 구글·네이버 검색 순위와 ChatGPT·Gemini·Perplexity 답변 속 노출을 함께 추적하는 AZEO로 합니다. 검색 순위와 AI 인용은 움직이는 방향이 다를 수 있어 따로 보는 편이 판단에 유리합니다. 참고로 네이버는 자체 품질 기준으로 노출을 정하므로, 구글 기준만으로 결과를 예상하기는 어렵습니다.

확장 여부는 숫자 하나로 정하지 않습니다. 색인률이 낮으면 품질이나 내부 링크 구조를, 색인은 되는데 노출이 없으면 수요 선별을, 노출은 있는데 클릭이 없으면 제목과 요약 서술을 봅니다. 같은 ‘성과 부진’이라도 원인에 따라 다음 조치가 다르기 때문에, 묶음 단위로 지표를 분리해 둔 것이 여기서 값을 합니다.

어떤 방식으로 진행하든 성과를 보장할 수는 없습니다. 다만 회수 가능한 크기로 시작하고 기준을 문서로 남겨 두면, 실패하더라도 정리 비용이 감당할 수준에 머무릅니다. 자사 데이터로 프로그래매틱 SEO·GEO가 가능한지 판단이 서지 않는다면 보유 데이터 목록만 정리해 문의해 주셔도 검토가 가능합니다.

자주 묻는 질문

참고 자료

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

• Google Search Central — 스팸 정책 — Google 검색 필수 요건
• Google 공식 블로그 — New ways we’re tackling spammy, low-quality content on Search
• Google Search Central — 웹사이트에서 생성형 AI 콘텐츠를 사용하는 방법에 관한 Google 검색 안내
• Google Search Central — noindex로 검색 색인 생성 차단
• Google Search Central — 대규모 사이트 소유자를 위한 크롤링 예산 관리 가이드
• Google Search Central — AI 기능과 웹사이트
• Google Search Central — Google 검색 순위 시스템 가이드
• Google Search Central — 유용하고 신뢰할 수 있는 사용자 중심 콘텐츠 만들기