Loading...
본문으로 건너뛰기
개발

Git 기반 CMS란? "DB 없이" 콘텐츠를 운영하는 가장 현실적인 방법

· siimplelab

Git 기반 CMS란? “DB 없이” 콘텐츠를 운영하는 가장 현실적인 방법

웹사이트를 만들다 보면 언젠가 이런 고민이 생깁니다.

  • “블로그/문서/랜딩 페이지를 자주 업데이트해야 하는데, DB까지 운영하긴 싫다.”
  • “콘텐츠가 바뀔 때마다 누가 무엇을 바꿨는지 추적하고 싶다.”
  • “검수(리뷰) 후 배포되는 워크플로우가 필요하다.”

이럴 때 가장 깔끔한 해답 중 하나가 Git 기반 CMS(Git-based CMS) 입니다. 한 줄로 요약하면:

콘텐츠를 데이터베이스 대신 ‘파일(마크다운/JSON/YAML)‘로 저장하고, 수정은 Git 커밋(또는 PR)으로 남기는 CMS 입니다.

Git 기반 CMS의 핵심 개념

1) 콘텐츠는 “파일”이다

전통적인 CMS(워드프레스 등)는 콘텐츠가 DB에 들어갑니다. 반면 Git 기반 CMS는 보통 이런 형태로 저장합니다.

  • content/posts/hello-world.md
  • content/docs/getting-started.md
  • data/products.json

즉, 저장소(repo)가 곧 CMS의 데이터 저장소 입니다.

2) 수정은 “커밋”으로 기록된다

콘텐츠를 수정하면 CMS가 Git에 커밋을 생성합니다. 그래서 자동으로 다음이 해결됩니다.

  • 누가 바꿨는지(작성자)
  • 언제 바꿨는지(시간)
  • 무엇을 바꿨는지(diff)
  • 되돌리기(revert)

“콘텐츠 변경 이력 관리”가 Git에 의해 거의 공짜로 따라옵니다.

3) 배포는 “빌드”로 이루어진다

대부분 Git 기반 CMS는 정적 사이트(SSG) 또는 하이브리드(Next.js/Astro 등) 와 잘 맞습니다.

흐름은 보통 이렇게 됩니다.

  1. CMS에서 글 수정 → Git 커밋/PR 생성
  2. CI/CD가 실행 → 사이트 빌드
  3. 정적 파일이 배포됨(Vercel/Netlify/Cloudflare Pages 등)

왜 Git 기반 CMS가 좋은가?

운영 비용이 낮다 (DB/서버 관리 부담 감소)

  • DB 백업/마이그레이션/보안 패치 같은 운영이 크게 줄어듭니다.
  • “데이터”가 결국 파일이므로, 최악의 경우에도 Git repo만 있으면 복구 가능합니다.

협업/검수 프로세스가 자연스럽다

PR 기반으로 운영하면 콘텐츠도 코드처럼 리뷰할 수 있습니다.

  • 초안 작성 → PR 생성
  • 리뷰(교정/팩트 체크) → 승인
  • 머지 후 자동 배포

콘텐츠 팀이 있는 조직일수록 이 구조가 강력합니다.

성능이 좋다

정적 사이트는 기본적으로 빠릅니다.

  • 캐시/ CDN 친화적
  • 서버 비용 절감

단점도 분명하다 (여기서 많이들 실패함)

1) “쓰기”가 많은 서비스엔 부적합

댓글, 좋아요, 주문, 장바구니처럼 사용자가 자주 데이터를 쓰는 서비스는 Git 기반 CMS로 버티기 어렵습니다.

  • 커밋이 폭증함
  • 동시 편집/경합으로 충돌 가능성 증가
  • 빌드가 자주 돌면 배포 비용/시간이 커짐

2) 복잡한 검색/필터/관계형 데이터가 어렵다

“태그별 글 목록”, “인기순 정렬”, “관계형 데이터 조인” 같은 건 DB가 잘합니다.

Git 기반 CMS에서도 가능은 하지만 보통 이렇게 우회합니다.

  • 빌드 단계에서 인덱스 JSON 생성
  • 태그별 리스트 파일 미리 생성
  • 검색 엔진(Algolia 등) 연동

즉, 성능은 좋아지는데 설계/구현 난이도는 올라갈 수 있습니다.

3) 콘텐츠 규모가 커지면 빌드 시간이 늘어남

글이 수천~수만 개가 되면 빌드/배포 시간이 무시 못 합니다. 이럴 땐 ISR(Incremental) 같은 하이브리드 전략이 필요합니다.

어떤 사이트에 가장 잘 맞을까?

Git 기반 CMS가 특히 잘 맞는 건 이런 유형입니다.

  • 회사 소개/랜딩 페이지(마케팅 사이트)
  • 블로그/뉴스룸
  • 제품/서비스 문서(Documentation)
  • 포트폴리오/사례(케이스 스터디)
  • 정적 카탈로그(가격표/메뉴/코스 안내)

반대로, 아래는 “CMS만 Git”으로 하고 나머지는 다른 저장소를 쓰는 하이브리드가 보통 더 낫습니다.

  • 회원/로그인/권한 관리
  • 댓글/리뷰/게시판
  • 결제/주문/재고

대표적인 Git 기반 CMS 선택지 (카테고리로 이해하기)

A) “사이트에 /admin 붙이는” 형태

  • 정적 사이트에 CMS 화면을 붙이고, 편집하면 repo로 커밋하는 방식
  • 장점: 구성 단순, SSG와 궁합 좋음
  • 단점: 편집 UX가 프로젝트마다 다르고, 설정에 따라 제한이 있을 수 있음

B) “프레임워크에 통합되는” 형태

  • Next.js/Astro 같은 앱에 CMS 기능을 통합
  • 장점: 개발자 경험 좋고, 커스터마이징 쉬움
  • 단점: 초기 세팅이 A보다 무거울 수 있음

C) “상용 서비스”

  • 비개발자 편집 경험이 더 매끄러운 경우가 많음
  • 협업 기능/권한/미리보기 등 제공
  • 단점: 비용 발생, 벤더 종속 가능성

실전 아키텍처 예시 (가장 추천하는 형태)

“콘텐츠는 Git, 동적 데이터는 따로”

가장 현실적인 운영 방식은 이 조합입니다.

  • 글/문서/페이지: Git 기반 CMS (파일 + 커밋)
  • 좋아요/조회수/간단한 설정: KV 같은 서버리스 스토리지
  • 회원/결제/트랜잭션: SQLite 또는 Postgres 같은 DB

즉, Git 기반 CMS를 “콘텐츠 영역”에만 쓰고, 서비스성 데이터는 목적에 맞게 분리합니다.

도입 체크리스트 (이거 안 보면 나중에 후회함)

  1. 누가 편집하는가?
    • 비개발자 편집자가 많으면 UI/권한/미리보기가 중요합니다.
  2. 리뷰가 필요한가?
    • PR 기반 검수 프로세스를 원하면 Git 기반 CMS의 강점이 극대화됩니다.
  3. 업데이트 빈도는 어느 정도인가?
    • 하루 수십 번 이상 수정한다면 빌드/배포 비용을 고려해야 합니다.
  4. 검색/필터/리스트가 핵심인가?
    • 빌드 인덱싱 또는 외부 검색 연동 계획이 필요합니다.
  5. 콘텐츠 규모가 커질 가능성이 있는가?
    • ISR, 캐싱 전략, 빌드 최적화를 미리 생각하세요.

마무리: “DB 없이 운영”의 정답은 보통 Git 기반 CMS다

Git 기반 CMS는 “DB 없이 콘텐츠를 운영하고 싶다”는 요구에 꽤 정확하게 들어맞습니다.

  • 변경 이력/협업/검수: Git이 해결
  • 배포/성능: 정적 빌드+CDN이 해결
  • 운영 비용: 낮음

단, 서비스성 데이터까지 억지로 Git에 넣으려 하면 망합니다. 콘텐츠에 집중해서 쓰고, 나머지는 KV/SQLite/DB로 분리하는 게 가장 안전합니다.