• 웹사이트를 만드는 재료(데이터, HTML, CSS, JS)를 누가, 언제, 어떻게 조립해서 사용자에게 보여줄 것 인가에 대한 전체 과정과 전략을 말함

렌더링 방식의 핵심 원리

• 웹 렌더링을 서버, 클라이언트, 빌드 도구 중 누가 주도권을 쥐느냐에 따라 나뉜다.

렌더링 방식이 중요한 이유?

• 조금 과장해서 렌더링 방식에 따라 웹사이트의 성패가 달라질 수 있기에, 웹페이지를 운영하는 목적에 따라 렌더링 방식을 전략적으로 고려하는 것도 좋은 방법일 것 같다.
  • 성능(Performance) : 첫 페이지가 얼마나 빨리 뜨는지
  • 사용자 경험(UX) : 페이지를 이동하거나 상호작용 할 때 얼마나 부드러운지
  • 검색엔진 최적화(SEO) : 검색엔진이 웹페이지의 내용을 얼마나 잘 읽어갈 수 있는지

웹 렌더링 방식

SSR (Server Side Rendering)

• SSR은 초기 웹 환경에서부터 사용된 고전적인 방식이었으나, 최근에는 사용자 경험과 SEO를 위해 현대적인 프레임워크(Next.js 등)에서 재도입되어 활용되고 있다.
• 웹 렌더링의 주도권을 Server 가 가지는 방식으로, 여기서 말하는 서버는 웹 호스팅 서버이다.
• 파일 서버이자 호스팅을 담당하면서 데이터 처리와 HTML조립을 모두 맡아 처리한다.

장점 1. SEO (검색 엔진 최적화)에 유리

• 위 시퀀스 다이어그램에서 보이듯, 요청 순간 데이터를 조회하고 HTML에 바인딩하여 완성된 HTML을 반환하기 때문에, 크롤러가 사이트 방문 시 페이지 결과를 바로 볼 수 있고, 좋은 컨텐츠로 인식하여 검색 결과에 노출하기가 수월한 편이다.

구글 공식 검색 프로세스(3단계)

• 발견하고 Crawling
• 이해하고 Indexing
• 순위를 매겨 보여주는 Serving

위 세 단계를 통해 검색 결과를 제공하는데, 세 단계가 동시에 진행되는 것이 아니라 며칠에 걸쳐 이뤄진다. 특히 구글은 크롤링(HTML 다운로드)과 인덱싱(콘텐츠 분석)을 한 번에 처리하지 않고, 효율성을 위해 두 단계(Two-Pass)로 나누어 처리한다.

1단계 : Crawling

CSR의 경우 구글은 이 단계에서 <title> 태그와 <meta> 태그 등 페이지의 기본 정보는 우선 파악하고 색인에 포함시키긴 하지만 실제 콘텐츠(본문)는 2단계 WRS를 거쳐야만 읽을 수 있다.

2단계 : Indexing

색인이 되기 위해 콘텐츠가 반드시 필요한 CSR 페이지들은 1단계에서 보류된 후, 구글의 웹 렌더링 서비스(WRS: Web Rendering Service) 라는 별도의 시스템으로 보내지는데, 이것이 시간 지연의 원인이 된다.

장점 2. 초기 로딩 속도가 빠름(FCP 한정)

• SSR이 초기 로딩 속도가 빠르다는 것은 FCP (First Contentful Paint)를 의미하는데, 이는 사용자가 화면에서 의미 있는 콘텐츠를 처음 볼 수 있을 때까지 걸리는 시간을 말한다.
• React.js(CSR) 와 Next.js(SSR) 로 간단히 비교하자면, CSR(React.js)은 빈 DOM 구조를 먼저 파싱한 후 JS 파일을 다운로드하고 실행하여 데이터를 가져와 최종 화면을 렌더링하는 반면, SSR(Next.js)은 응답 시점에 완성된 HTML을 전달하므로 FCP가 빠를 수밖에 없다.

‘초기 로딩 속도’에서 중요한 세 가지 지표

• TTFB (Time To First Byte) : 서버가 요청을 받고, 첫 번째 데이터를 브라우저에 보내는 데 걸리는 시간. (SSR 느림 < CSR 빠름)

• FCP (First Contentful Paint) : 사용자가 화면에서 의미 있는 콘텐츠(텍스트나 이미지)를 처음 볼 수 있을 때까지 걸리는 시간. (SSR 빠름 > CSR 느림)

• TTL (Time To Interactive) : 사용자가 페이지와 상호작용 할 수 있을 때까지 걸리는 시간 (SSR은 FCP와 TTL의 간격이 크고, CSR은 FCP와 TTL의 간격이 거의 차이가 없음)

SSR과 CSR의 FCP vs TTI 비교

장점 3. 낮은 초기 처리 부하 (저 사양 기기 유리)

• 앞서 보았듯 SSR은 페이지를 그리는 모든 무거운 작업 (데이터 바인딩, HTML 조립 등)들이 성능 좋은 서버에서 미리 처리되므로 상대적으로 브라우저 의 부하가 크게 줄어든다. 그래서 클라이언트(브라우저) 성능에 크게 좌우되지 않는 편이다. (하이드레이션으로 인한 부하는 제외 - 이미 화면에 그려진 DOM 구조를 다시 스캔하여 이벤트 리스너 등을 하나하나 연결하는 작업)

단점 1. 느린 서버 응답 시간 (TTFB 지연 가능성)

• 원인: SSR은 사용자의 요청이 있을 때마다 서버에서 데이터베이스(DB)에 접속하여 데이터를 조회하고, 템플릿에 렌더링하여 완성된 HTML을 즉시 생성해야 함. 이 일련의 서버 처리 과정 자체가 시간이 소요됨.

• 문제점: 동시에 많은 요청이 들어오거나(트래픽 급증), DB 조회 시간이 길어지면, 서버에 과부하가 걸려 응답 시간이 느려짐.

• 결과: 사용자가 첫 번째 데이터(첫 바이트)를 받을 때까지 걸리는 시간인 TTFB (Time To First Byte)가 CSR보다 길어질 수 있음. (CSR은 빈 HTML만 즉시 보내면 되므로 TTFB가 빠름.)

단점 2. TTL 지연 (느린 상호작용)

• 원인: SSR은 HTML을 빠르게 보내 FCP를 달성하지만, 이후 Hydration(하이드레이션)이라는 무거운 클라이언트 측 JS 실행 및 연결 작업이 필수적임.

• 문제점: Hydration 과정이 끝날 때까지 페이지는 사용자 입력에 반응할 수 없는 ‘먹통 구간’이 됨.

• 결과: 사용자 눈에는 페이지가 완성된 것처럼 보이지만, 클릭이 안 되는 답답한 경험을 주어 UX가 저하됨. (FCP와 TTI 간 간격이 큼.)

단점 3. 서버 리소스 및 운영 비용 증가

• 원인: SSR은 모든 요청을 서버가 직접 처리하고 HTML을 생성해야 함. (CSR은 대부분의 렌더링 작업을 사용자의 브라우저에 떠넘김.)

• 문제점: 서버는 DB 조회, 템플릿 엔진 실행, HTML 생성 등 복잡한 연산을 반복적으로 수행해야 하므로 CPU와 메모리 사용량이 매우 높음.

• 결과: 서버를 운영하기 위한 하드웨어 사양과 클라우드 비용이 CSR 대비 크게 증가함. 특히 트래픽이 폭증할 경우, 서버 증설 비용 부담이 커짐.

CSR (Client Side Rendering)

• CSR은 SSR과 정반대되는 철학을 가지는데, 서버의 부담을 최소화 하고, 모든 동적인 작업을 사용자의 브라우저에 맡기는 방식이다.
• 웹 렌더링 주도권을 Client(Browser)가 가지는 형태이다.
• 초기 로딩 시 기본 뼈대만 있는 HTML 파일과 JS 번들을 먼저 응답한 다음, JS 파싱 및 실행 후 데이터를 조회해 데이터 바인딩 및 완성된 HTML을 생성 한다.
• 여기서 웹 서버는 단순히 파일 호스팅만 담당하고, 실제 HTML 조립은 브라우저의 Javascript 가 처리한다.

장점 1. 빠른 페이지 전환 (부드러운 UX)

• CSR 앱은 초기 로딩 시 한 번만 전체 JS 코드를 다운로드 하고 나면, 이후 페이지 이동 시 HTML 전체를 다시 서버에서 받아올 필요가 없다.
• 필요한 데이터만 API를 통해 JSON 형태로 받아와 화면의 필요한 부분만 갱신함. 이는 페이지가 깜빡이거나 새로고침되는 현상 없이 매우 빠르고 부드러운 사용자 경험을 제공함.
• 여기서 SSR도 초기 로딩 시 전체 JS 코드를 다운받는데? 라는 의문이 들 수 있는데, 여기서 중요한 사용 방식의 차이는 CSR은 기본적으로 SPA(Single Page Application) 형태로 동작한다는 것이다.

SPA vs MPA 핵심 차이점 비교

my-react-app/
├── public/
│   └── index.html          # 빈 껍데기 (단 하나의 HTML)
│
└── src/
    ├── pages/              # Home.jsx, About.jsx, Product.jsx
    ├── components/         # Header.jsx, Footer.jsx
    ├── App.jsx             # 라우팅 설정
    └── index.js            # ReactDOM.render 진입점

<!-- public/index.html: 유일한 HTML -->
<!DOCTYPE html>
<html>
  <body>
    <div id="root"></div>  <!-- 비어있음 -->
    <script src="bundle.js"></script>
  </body>
</html>

장점 2. 웹 호스팅 서버 부하 감소 및 비용 절감

• 원인: 웹 호스팅 서버는 데이터 처리(DB 조회)와 HTML 템플릿 렌더링을 할 필요가 없음.

• 결과: 서버는 요청에 대해 빈 HTML 뼈대와 JS 파일, 그리고 이후 순수한 데이터(JSON)만 제공하면 됨. 서버의 CPU 부담이 대폭 줄어들어, 운영 비용이 낮고 대용량 트래픽에도 안정적으로 대응함.

장점 3. FCP와 TTI 간격 최소화

• 원인: JS가 실행되어야만 콘텐츠가 화면에 보이기 시작함 (FCP). 이벤트 리스너도 이 과정에서 동시에 붙음 (TTI).

• 결과: TTI 자체가 늦어지더라도, FCP와 TTI 사이의 ‘먹통 구간’이 거의 없어 사용자에게 “보이는데 클릭은 안 되는” 답답함을 주지 않음.

단점 1. 느린 초기 로딩 속도 (FCP 지연)

• 원인: 브라우저가 사용자에게 콘텐츠를 보여주기 위해 대용량의 JS 파일을 모두 다운로드하고 실행할 때까지 기다려야 함.

• 문제점: JS 파일이 클 경우, 사용자는 긴 시간 동안 하얀 화면(White Screen)만 보게 됨.

• 결과: 초기 로딩 속도 지표인 FCP가 SSR에 비해 현저히 느려지는 결정적인 단점이 있음.

단점 2. 검색 엔진 최적화 (SEO) 불리

• 원인: Googlebot이 1단계 크롤링 시점에 받아보는 HTML 파일이 <div id="root"></div>와 같은 빈 껍데기이기 때문임.

• 문제점: 실제 콘텐츠를 읽으려면 구글의 WRS(Web Rendering Service) 대기열을 거쳐 JS를 실행해야 함. 이 과정에서 색인에 시간이 더 오래 걸리는 지연(Delay) 이 발생할 수 있어 SSR보다 불리할 수 있음.

단점 3. 클라이언트 성능 의존성이 높음

• 원인: 페이지 렌더링 및 상호작용 관련 모든 복잡한 연산을 사용자 기기의 CPU가 처리해야 함.

• 결과: 사용자의 네트워크 환경이 불안정하거나 저사양 스마트폰을 사용할 경우, JS 다운로드 및 실행 시간이 오래 걸려 앱이 느리게 느껴지거나 버벅거림.

SSG (Static Site Generation)

• SSG는 웹사이트를 사용자가 요청하는 시점이 아니라, 배포 및 빌드하는 시점에 미리 완성된 HTML 파일을 생성해 놓는 전략이다. 따라서 SSG의 장단점은 매우 명확한데, 속도는 엄청 빠르지만 데이터 변경 시에는 재 배포가 필요하다는 점이다.

작동 원리 (빌드 시점의 SSR)

1. 빌드 시점: 개발자가 웹사이트를 서버에 올릴 때(빌드), SSG 도구(Next.js, Astro, Gatsby 등)가 데이터베이스에 접속하여 필요한 모든 데이터를 조회함.

2. HTML 생성: 조회된 데이터로 수천, 수만 개의 완성된 HTML 파일을 미리 만들어냄.

3. 배포: 이렇게 만들어진 정적인 HTML, CSS, JS 파일 묶음을 CDN(Content Delivery Network) 같은 분산된 파일 서버에 저장함.

4. 사용자 요청 (Runtime): 사용자가 페이지를 요청하면, 서버가 HTML을 만드는 것이 아니라, 가장 가까운 CDN 위치에서 이미 만들어진 HTML 파일을 즉시 가져와 보여줌.

장점 1. 압도적인 속도 (TTFB, FCP 최상)

• TTFB가 매우 빠르다. 서버에서 데이터를 조회하고 HTML을 만들 필요가 없기 때문에, 단순 파일을 전송하는 속도만 나오기 때문이며, 이에 따라 FCP 역시 매우 빠른 편이다.

장점 2. 최고의 SEO

• SSR처럼 이미 완성된 HTML이 크롤러에게 제공되므로, 구글의 WRS 대기열을 거칠 필요가 없다.

장점 3. 낮은 비용 및 높은 안정성

• 웹 호스팅 서버 대신 CDN에서 단순 파일을 제공하므로, 서버 운영 비용이 거의 들지 않는 편이다. 또한 트래픽이 아무리 폭증해도 CDN은 안정적으로 파일을 제공할 수 있다.

단점 1. 실시간 데이터 반영 어려움

• 데이터가 업데이트될 때마다 전체 웹사이트를 다시 빌드하고 배포해야 한다. (예: 블로그 포스팅 하나 수정 시 전체 사이트 재빌드)

• 뉴스 사이트처럼 실시간으로 데이터가 바뀌어야 하는 곳에는 부적합하다.

• SSG는 데이터 업데이트 시 재빌드가 필요하지만, 최근에는 ISR과 같은 기술을 통해 일정 주기를 설정하여 부분적으로만 재빌드하여 실시간성 문제를 완화하고 있다고 한다.

단점 2. 개인화 어려움

페이지가 미리 만들어져 있기 때문에, 로그인한 사용자별로 내용이 달라지는 개인화된 페이지(Personalized Content)를 만드는데 제약이 따른다. (이 경우 SSR이나 CSR 혼합 방식이 필요함)

웹 렌더링 방식 3가지 핵심 비교

참고자료

• Google 검색의 작동 방식
• Google 크롤링 및 색인 생성
• Google 검색 Essentials

구글 검색 노출을 위해 해야 할 주요 설정은 다음과 같다.

1. Google Search Console에 사이트 등록 및 소유권 확인
   • 내 GitHub Pages 주소를 Google Search Console에 등록하고, 제공하는 HTML 소유권 확인 파일을 다운로드 받아 GitHub 저장소 루트에 업로드해 소유권을 인증합니다.
2. sitemap.xml 파일 생성 및 업로드 및 Google Search Console에 sitemap 제출
   • 사이트의 각 페이지 위치를 알리는 sitemap.xml 파일을 만들어 GitHub 저장소 루트에 추가합니다. 이 파일은 Google이 사이트 구조를 쉽게 파악하도록 돕습니다.
   • Google Search Console에서 sitemap.xml 파일을 제출해 사이트 색인을 활성화합니다.
3. robots.txt 파일 생성 및 업로드
   • robots.txt 파일을 만들어 모든 검색 엔진에 사이트 접근을 허용하고 sitemap 위치를 명시합니다.
4. 사이트 메타태그 및 SEO 최적화
   • Jekyll을 사용하는 경우 jekyll-seo-tag 플러그인 설정 등으로 메타태그를 추가해 검색 노출을 개선합니다.

나의 경우 Jekyll을 사용하여 블로그를 생성했기 때문에, Jekyll의 플러그인을 사용하여 아래 항목들은 손쉽게 해결했다.

• sitemap
• SEO
• RSS feed

1. Google Search Console에 사이트 등록 및 소유권 확인

github.io 를 등록할 때는 URL 접두어 방식을 선택

• 왜? GitHub Pages는 GitHub가 소유한 도메인을 사용할 권한만 있고, 도메인 관리 권한은 없기 때문

• 도메인 속성은 DNS 레코드를 직접 수정해야 하는데, github.io는 GitHub 소유라서 DNS 설정을 할 수가 없음

파일 다운로드 후 GitHub Pages의 최상단 폴더에 업로드

• 이후 [완료] 버튼을 누르면 아래와 같이 소유권이 확인됨

2. sitemap.xml 파일 생성 및 업로드 및 Google Search Console에 sitemap 제출

• 앞서 말했다시피, Sitemap은 Jekyll을 사용하여 손쉽게 생성되었기에 사이트맵 주소만 Google Search Console에 추가하면 된다.

3. robots.txt 파일 생성 및 업로드

• robots.txt 파일 생성은 간단하다 아래와 같은 내용으로 파일을 만든 후 root(최상단)에 파일을 추가해주면 된다.

User-agent: *
Allow: /

Sitemap: https://yebinable.github.io/sitemap.xml

4. 사이트 메타태그 및 SEO 최적화

• Jekyll 플러그인을 이용해 손쉽게 적용할 수 있다.
• Jekyll-seo-tag 플러그인이 front matter와 config.yml의 정보를 기반으로 다음 메타태그들을 자동으로 생성한다.
  • 페이지 타이틀과 사이트 타이틀
  • 메타 description
  • Canonical URL (중복 콘텐츠 방지)
  • JSON-LD 구조화 데이터 (리치 스니펫용)
  • 이전/다음 페이지 URL (페이지네이션) …
• 이 방법을 사용하면 수동으로 메타태그를 작성할 필요 없이 Jekyll이 자동으로 SEO에 최적화된 메타태그를 생성하므로, front matter에 기본 정보만 잘 작성하면 된다.

레이아웃 파일에 태그 추가

• _layouts/default.html 의 <head> 섹션에 seo 태그를 삽입

_config.yml 에 사이트 전체 SEO 설정

title: "사이트 제목"
description: "사이트 설명"
author: "작성자 이름"
email: "your@email.com"
url: "https://yourusername.github.io"
locale: ko_KR

# 소셜 미디어 프로필
social:
  name: "작성자 이름"
  links:
    - https://github.com/yourusername
    - https://twitter.com/yourusername

각 포스트 별 개별 메타 데이터 설정 (front matter)

---
layout: post
title: "포스트 제목"
description: "포스트 설명 (메타 description으로 사용)"
date: 2025-11-19
author: "작성자 이름"
tags: [git, obsidian]
image: /assets/images/post-thumbnail.jpg
---

본문 입니다.

참고자료

구글-Search Console 시작하기

GitHub로 기술 블로그(Wiki)를 만들고 싶고, Obsidian으로 편하게 관리하고 싶었다. 하지만 다음과 같은 요구사항이 있었다:

• 비공개 노트: 업무 내용, 개인 메모, 작성 중인 초안은 Private으로 관리
• 공개 블로그: 완성된 기술 문서는 GitHub Pages(username.github.io)로 공개
• 단일 Vault: Obsidian에서 하나의 Vault로 모든 노트를 한 화면에서 관리
• 자동 Git 푸시: 파일 저장하면 자동으로 각 저장소에 커밋/푸시

시도한 방법들과 문제점

방법 1: 심볼릭 링크

• Public 저장소를 심볼릭 링크로 연결
• 문제: Public 폴더 수정 시 일일이 해당 폴더로 가서 수동으로 커밋/푸시해야 함
• 문제: Obsidian Git이 심볼릭 링크 내부를 자동으로 처리하지 못함

방법 2: Vault 2개 분리

• Private Vault와 Public Vault를 완전히 분리
• 문제: Vault를 전환해야 해서 불편함
• 문제: Private와 Public 노트를 동시에 볼 수 없음

방법 3: .gitignore로 제외

• 하나의 Public 저장소에서 특정 폴더만 .gitignore로 제외
• 문제: 실수로 비공개 내용이 Public에 올라갈 위험
• 문제: Private 내용이 Git 히스토리에 남을 수 있음

원인 분석

Obsidian은 파일 시스템 기반이고, Git은 저장소 단위로 동작한다.

필요한 조건

1. Private와 Public이 완전히 분리된 Git 저장소여야 함
2. Obsidian에서는 하나의 Vault로 보여야 함
3. Obsidian Git이 각 저장소를 독립적으로 자동 커밋/푸시해야 함

해결 방법

Git Submodule

Git Submodule은 하나의 Git 저장소 안에 다른 Git 저장소를 포함시키는 기능이다.

최종 구조

notes/ (Private Repository)
├── .git/                      ← Private 저장소
├── .gitmodules                ← Submodule 설정 파일
├── .obsidian/                 ← Obsidian 설정
├── private/                   ← 비공개 노트
│   ├── inbox/
│   ├── work/
│   └── life/
└── yebinable.github.io/       ← Public Repository (Submodule)
    ├── .git/                  ← Public 저장소 (독립적)
    ├── tech/
    └── README.md

설정 과정

1. GitHub 저장소 생성

**Private 저장소:**
- Repository name: `notes`
- Visibility: **Private**

**Public 저장소:**
- Repository name: `yebinable.github.io`
- Visibility: **Public**

2. Private 저장소 클론

git clone https://github.com/yebinable/notes.git
cd notes

3. Public 저장소를 Private 저장소의 Submodule로 추가

# Submodule 추가
git submodule add https://github.com/yebinable/yebinable.github.io.git yebinable.github.io

# 커밋
git add .gitmodules yebinable.github.io
git commit -m "Add public wiki as submodule"
git push

4. Obsidian 설정

1. Vault 열기: yebinable-private 폴더를 Vault로 열기
2. Obsidian Git 플러그인 설치
3. 중요 설정:

   Settings → Obsidian Git → Advanced
   → ✅ Update submodules (반드시 체크!)
      
   Vault backup interval: 1분
   Auto pull interval: 1분
   

작동 원리

Obsidian Git의 “Update submodules” 옵션이 이 두 단계를 자동으로 처리한다.

Private 노트 작성 시

private/work/보안-취약점.md 작성 및 저장
→ 10분 후 Obsidian Git 자동 실행
→ yebinable-private 저장소에 커밋 & 푸시 ✅

Public 노트 작성 시

yebinable.github.io/tech/Git-정리.md 작성 및 저장
→ 10분 후 Obsidian Git 자동 실행
→ 1단계: yebinable.github.io 내부 커밋 & 푸시 ✅
→ 2단계: yebinable-private에서 참조 업데이트 & 푸시 ✅

다른 환경에서 클론 시

# Submodule까지 함께 클론
git clone --recursive https://github.com/yebinable/yebinable-private.git

# 또는 이미 클론했다면
git submodule init
git submodule update