Tech Blog

웹페이지별 썸네일을 다르게 적용하고 싶어요! : 페이지별 메타태그 설정 전략

Loreen Kim

2026-03-10·조회수 0

카카오톡이나 트위터에 공들여 쓴 아티클 링크를 올렸는데, 원하는 썸네일이 아니라 플랫폼의 썸네일이 덩그러니 나온 적이 있나요?

셀렉트웨이의 홈페이지는 최초에는 Bolt.new 바이브코딩으로 구축되었지만, 점차 기능이 커지면서 구글 안티그래비티 환경으로 이전했습니다.

그 중에 자사만의 전문성과 브랜드의 가치를 높이기 위해 '아티클' 메뉴를 신설했고, 사용자가 보는 화면부터 어드민(Admin) 기능까지 개발되었습니다.

그런데, 여기서 한계에 부딪혔습니다. 작성한 아티클을 카카오톡 오픈 채팅방부터 외부 SNS 채널에 기사를 공유하려고 했더니, 한 가지 문제가 발생했습니다. 어떤 기사를 공유하든 아티클 고유의 제목과 썸네일 대신, 회사 홈페이지의 메인 제목과 로고만 덩그러니 뜨는 문제였습니다.

즉, 기업의 브랜딩과 마케팅을 위해서는 기사라는 메뉴에는 각 기사별 썸네일과 제목이 뜨는 것이 필요했습니다.

찾아보니 웹사이트가 화면을 그리는 방식에는 크게 두 가지가 있었습니다. SSR(Server-Side Rendering, 서버 사이드 렌더링)은 서버가 완성된 페이지를 내려주고, CSR(Client-Side Rendering, 클라이언트 사이드 렌더링)은 브라우저가 JS를 실행해서 화면을 그립니다.

그리고 Bolt.new, 안티그래비티 등 AI 도구로 만들어진 셀렉트웨이의 구조는 CSR(클라이언트 사이드 렌더링) 방식을 사용하고 있었습니다. 바로 이 CSR(클라이언트 사이드 렌더링) 방식이 페이지별 썸네일 문제의 원인이었습니다.

아래부터 AI를 활용해 개발하는 기획자와 초보 개발자가 꼭 알아야 할, CSR(클라이언트 사이드 렌더링) 방식의 한계를 극복하고 SNS 공유 규격에 맞게 페이지별 메타태그를 설정하는 전략을 정리해 드립니다.

1. 문제의 핵심: "SNS 로봇은 웹페이지의 정보를 다르게 읽는다"

앞서 설명한 것처럼, Bolt.new, 피그마의 Make, 그리고 Google 안티그래비티 등 AI 도구로 만들어진 웹사이트는 리액트(React)로 구현될 확률이 높고, CSR(클라이언트 사이드 렌더링) 방식을 사용합니다. 이 방식에서 '일반 사용자'와 'SNS 크롤러'는 페이지를 받아들이는 방법이 완전히 다릅니다.

🏃 사용자의 브라우저 기본 동작

사용자가 링크를 클릭하면 브라우저는 먼저 빈 HTML을 받습니다. 그 후 "자바스크립트를 실행해!"라는 명령에 따라 데이터를 불러오고 화면을 그립니다. 비록 1~2초의 로딩 시간이 걸리지만, 결국 사용자는 데이터베이스에서 갓 불러온 따끈따끈한 기사 제목과 섬네일을 보게 됩니다.

🤖 SNS 크롤러 (로봇)은 더 빠르게 승부한다

카카오톡이나 트위터의 로봇은 더 빠르게 승부합니다. 링크를 타고 들어오자마자 HTML 파일 상단의 영역에 적힌 정보(메타태그)만 번개처럼 훑고 바로 나갑니다. 로봇은 자바스크립트를 실행해 데이터를 채워주기 전인 '빈 껍데기 상태의 기본 메타태그'만 수집하는 차이가 발생합니다.

🔍 로봇 vs 브라우저: 어디서 페이지의 정보를 찾아오는가?

구분	SNS 크롤러 (로봇)	일반 사용자 (브라우저)
인식 방식	서버에서 받은 첫 HTML만 읽음	HTML을 받고 자바스크립트 실행 후 완성
대기 시간	0초 (기다리지 않음)	1~2초 (데이터 로딩 대기)
노출 결과	index.html에 고정된 기본 정보	데이터베이스에서 불러온 실제 기사 정보

💻 코드 예시: 크롤러가 수집해가는 '빈 껍데기' HTML

크롤러는 자바스크립트를 실행하지 못하므로, 모든 웹 사이트에서 공통적으로 들어가 있는 초기 상태의 HTML을 갖고 옵니다.
아래 코드에서 title부분과 description 부분이 어떤 페이지에서도 동일하게 나오는 것이 해결하고 싶은 문제라는 점입니다.

결과적으로 브라우저에서는 멋진 아티클이 보이지만, 카톡 공유창에는 index.html에 기본으로 적힌 정보(회사 홈페이지 제목 & 기본 로고)만 노출되는 현상이 발생합니다.

<html lang="ko">
<head>
  <meta charset="utf-8" />
  <title>셀렉트웨이 | 성장 중심 기획/DX/AX 에이전시</title>
  <meta property="og:title" content="셀렉트웨이 | 성장 중심 기획/DX/AX 에이전시" />
  <meta property="og:image" content="https://www.swy.kr/og-image.png" />
  <meta name="description" content="성장 중심의 기획, DX, AX 솔루션을 제공하는 전문 에이전시 셀렉트웨이입니다." />
  <meta property="og:type" content="website" />
</head>
<body>
  <div id="root"></div>
</body>
</html>

2. 해결책: 페이지별 메타태그 설정 전략

앞서 살펴본 문제를 해결하려면 페이지마다 다른 메타태그를 설정하는 전략을 적용해야 했습니다.

🎨 기획자를 위한 메타태그 설정 전략

페이지별 메타태그 설정의 도입 전과 도입 후를 비교해 보겠습니다.

구분	도입 전 (고정 메타태그)	도입 후 (동적 메타태그)
SNS 공유 화면	어떤 기사를 공유해도 회사 로고 & 회사 이름만 반복됨	기사마다 고유의 매력적인 썸네일 & 핵심 제목 노출
사용자 기대감	"그냥 회사 홈페이지네?" (클릭 유인 부족)	"내가 궁금했던 이 주제를 확인해볼까?" (관심 유발)
브랜드 전문성	콘텐츠 관리가 안 되는 미완성 서비스 느낌	세련되고 신뢰감 있는 전문 미디어 채널 느낌
유입률 (CTR)	낮음 (기대감이 낮아 클릭 없이 지나침)	높음 (콘텐츠 내용을 미리 보고 유입됨)

배달 전 포장 서비스: 사용자가 기사를 클릭하기 전, SNS 로봇이 먼저 도착합니다. 이때 서버(Firebase Functions)가 '포장 직원' 역할을 하여 기사 내용에 맞는 포장지를 입혀줍니다.

일관된 UX 제공: 사용자는 카톡 미리보기에서 본 제목과 그림을 브라우저 진입 후에도 똑같이 보게 됩니다. 이 '일관성'은 서비스에 대한 신뢰로 이어집니다.

🛠 메타태그 설정 전략을 기술적으로 이해하기

입구 및 안내 (Firebase Hosting): 사용자가 /contents/슬러그 주소로 접속하는 순간을 가장 먼저 맞이합니다. 평소처럼 화면을 바로 띄우지 않고, "이 주소는 제목을 갈아 끼워야 하니 서버(Functions)로 가라"고 요청을 토스합니다.
수행 및 가공 (Cloud Functions): Hosting이 넘겨준 주소에서 슬러그(slug)를 추출해 어떤 기사인지 파악합니다. 그 후, 원본 HTML 파일의 빈 제목칸과 섬네일칸에 Firestore에서 가져온 실제 데이터를 채워 넣는 '수술'을 진행합니다.
데이터 창고 (Firestore): 우리가 어드민에서 작성한 기사의 진짜 제목, 썸네일 주소가 저장되어 있는 '창고(DB)'입니다. 백엔드가 여기서 재료를 꺼내와야만 비로소 기사마다 각기 다른 메타태그 설정이 완성됩니다.

/**
 * 셀렉트웨이 아티클 동적 메타데이터 주입 로직 (Firebase Cloud Functions v2)
 */
const { onRequest } = require("firebase-functions/v2/https");
const admin = require("firebase-admin");
const fs = require("fs");
const path = require("path");

admin.initializeApp();

exports.shareMetadata = onRequest(async (req, res) => {
  // 1. [Hosting이 넘겨준 정보] URL에서 기사 식별자(slug) 추출
  const pathParts = req.path.split('/');
  const slug = pathParts[pathParts.length - 1];
  
  // 2. [Functions의 작업 준비] 서버에 보관된 원본 index.html 로드
  let html = fs.readFileSync(path.join(__dirname, 'index.html'), 'utf-8');

  try {
    // 3. [DB 창고 검색] Firestore에서 해당 슬러그의 게시물 검색
    const snapshot = await admin.firestore()
        .collection("contents")
        .where("slug", "==", slug)
        .limit(1)
        .get();

    if (!snapshot.empty) {
      const data = snapshot.docs[0].data();
      const title = `${data.title} | 셀렉트웨이`;
      const desc = data.description || "비즈니스 기획 인사이트";
      const image = data.thumbnail || "https://www.swy.kr/favicon.png";
      const url = `https://www.swy.kr/contents/${slug}`;
      
      // 4. [Functions의 수술] 메타태그를 기사 전용 데이터로 실시간 치환
      html = html.replace(/<title>[\s\S]*?<\/title>/, `<title>${title}</title>`);
      html = html.replace(/<meta name="description" content=".*?"\s*\/?>/, `<meta name="description" content="${desc}"/>`);

      // Open Graph (카카오톡, 페이스북 등)
      html = html.replace(/property="og:title" content=".*?"/, `property="og:title" content="${title}"`);
      html = html.replace(/property="og:image" content=".*?"/, `property="og:image" content="${image}"`);
      html = html.replace(/property="og:url" content=".*?"/, `property="og:url" content="${url}"`);
      
      // Twitter Card (트위터/X 전용)
      html = html.replace(/name="twitter:title" content=".*?"/, `name="twitter:title" content="${title}"`);
      html = html.replace(/name="twitter:image" content=".*?"/, `name="twitter:image" content="${image}"`);
    }
  } catch (error) {
    console.error("데이터 조회 실패:", error);
  }

  // 5. 최종 결과물(수정된 HTML)을 브라우저/로봇에게 응답
  res.status(200).set('Content-Type', 'text/html').send(html);
});

3. 외부 채널에서 정상 동작을 확인 (디버깅 도구)

코드를 반영한 후에는 플랫폼별 공식 검사기를 통해 캐시를 삭제하고 실제 노출되는 모습을 미리 확인해야 합니다. 플랫폼마다 메타데이터를 수집하고 보여주는 방식이 조금씩 다르기 때문입니다.

카카오톡 (공유 디버거): 카카오 개발자 도구에서 '캐시 초기화'를 진행하세요.
페이스북/인스타그램: Meta 공유 디버거를 활용하세요.
링크드인: Post Inspector를 통해 비즈니스 아티클 노출 상태를 점검합니다.
트위터/X: Twitter Card Validator를 통해 전용 태그 반영 여부를 확인합니다.

4. 결론: 우리 서비스에 맞는 최적의 선택은?

소규모 비즈니스나 중소기업에서 운영하는 기업용 홈페이지라면 현재 셀렉트웨이처럼 CSR(클라이언트 사이드 렌더링) 방식 + Firebase Functions(메타태그 설정 전략) 조합 대안으로도 충분히 전문적인 운영이 가능합니다.

상황별 기술 제안 (Case Study)

Case 1. 브랜드 홍보 및 기사 위주의 기업 사이트 (현재 상태)

제안: CSR(클라이언트 사이드 렌더링) 방식 유지 + 메타태그 설정 최적화
이유: 페이지 수가 수십 개 이내이며, 검색 엔진 전체 노출보다는 SNS 공유 시의 시각적 완성도가 더 중요하기 때문입니다.

Case 2. 콘텐츠 기반 성장이 중요한 미디어/커뮤니티 (벤치마킹: 토스, 요즘IT, 워싱턴포스트)

제안: Next.js(SSR, 서버 사이드 렌더링)로의 전환 권장
이유: 수천 개 이상의 문서를 관리하고 SEO 상단 노출이 필수적이라면 SSR이 생명줄입니다.

Case 3. 폐쇄형 B2B 툴 또는 관리 시스템

제안: 순수 CSR(클라이언트 사이드 렌더링) 유지
이유: 외부 공유가 필요 없는 보안 시스템이라면 추가 리소스를 투입할 필요가 없습니다.

📊 벤치마킹 분석 및 인사이트

앞서 살펴본 주요 서비스들을 기준으로 대기업과 스타트업 모델은 어떻게 적용하고 있을까요?

[Large Enterprise: 대규모 트래픽과 안정성]

워싱턴 포스트 (Washington Post): Next.js(SSR) 기반. 수만 개의 기사가 즉시 검색되고 공유될 수 있도록 무장되어 있습니다.
삼성전자 (Samsung): 전통적인 SSR 방식. 견고한 메타데이터 관리가 특징입니다.
네이버 웹툰 (Naver Webtoon): React(CSR) 방식 기반이지만 검색 로봇 전용 스냅샷을 별도로 제공하는 기술적 보완을 병행합니다.

[Startup & Media: 빠른 성장과 콘텐츠 확산]

토스페이 (Toss Pay): Next.js(SSR). 검색 엔진 최적화(SEO)와 부드러운 앱 경험을 모두 잡은 사례입니다.
요즘IT (Yozm IT): Next.js(SSR). 콘텐츠 확산을 위해 SNS 공유 품질에 극도로 집중되어 있습니다.
리캐치 (Recatch): Framer(SSG). 로우코드 툴을 사용하면서도 정적 생성을 통해 완벽한 공유 품질을 확보했습니다.

썸네일 문제는 해결 되었다!

셀렉트웨이의 아티클들을 공유해 보세요. 카카오톡이나 SNS에서도 페이지에 맞는 적절한 썸네일과 제목이 즉시 표시됩니다.

비즈니스 관점에서 초기 기업용 홈페이지는 CSR + Firebase Functions 대안으로도 충분합니다. 셀렉트웨이에서는 GA4 데이터 측정을 위해 가상 페이지뷰(Virtual Page View) 트래킹까지 구현하여 이탈 지점 등을 정교하게 파악하고 있습니다.

기업 브랜딩과 마케팅을 위한 페이지별 메타태그 설정 전략, 여러분들도 비즈니스 상황에 맞춰 적용해 보시길 바랍니다.

🧑‍💻

이 글을 쓴 에디터AUTHOR

셀렉트웨이 대표 / 기획자, 컴공 학사를 졸업하고 스타트업에서 커리어를 시작해서 지금 8년차 기획자이자 강사로 활동하고 있습니다. 10년 후의 같이 일할 기획자를 키운다는 마음으로 새로운 기술을 공부하고 나누고, 기록하고 있습니다.