블로그를 만들 때 가장 먼저 마주치는 갈림길이 있다. 글을 어디에 저장할 것인가. 관습적으로는 데이터베이스를 떠올린다. 글 테이블을 만들고, 관리자 화면에서 CRUD를 붙이고, 배포하면 그럴듯한 시스템이 된다. 하지만 개인 블로그라면 그 대신 마크다운 파일 + git이 훨씬 잘 맞는다. 이 글은 그 선택의 근거를 정리한다.
글은 애초에 문서다
데이터베이스는 자주 바뀌고, 동시에 여러 곳에서 읽고 쓰고, 관계로 얽힌 데이터를 다룰 때 빛난다. 쇼핑몰의 주문이나 SNS의 타임라인이 그렇다.
그런데 블로그 글은 성격이 다르다. 한 번 쓰면 거의 안 바뀌고, 쓰는 사람은 나 하나고, 글끼리 복잡한 관계도 없다. 이런 데이터를 굳이 테이블 행으로 쪼갤 이유가 없다. 글은 그냥 하나의 문서이고, 문서는 파일 하나로 두는 게 자연스럽다.
posts/
2026-07-15-what-is-mcp.md
2026-07-16-files-git-vs-db.md파일 하나가 글 하나. 파일명이 그대로 URL 슬러그가 되고, 프론트매터에 제목·날짜·태그를 적는다. 별도의 스키마도, 마이그레이션도 필요 없다.
git이 그냥 관리자 기능이 된다
파일로 두면 git이 따라온다. 그리고 git은 블로그 운영에 필요한 기능 대부분을 공짜로 준다.
- 버전 관리: 모든 수정 이력이 커밋으로 남는다. “3일 전 그 문단으로 되돌리기”가
git revert한 줄이다. - 백업: 원격 저장소에 push하면 그게 백업이다. DB 덤프를 따로 돌릴 필요가 없다.
- 발행 = 커밋: 글을 쓰는 행위와 배포하는 행위가 하나로 합쳐진다. push하면 CI가 사이트를 다시 빌드한다.
git add posts/2026-07-16-files-git-vs-db.md
git commit -m "새 글 발행"
git push관리자 로그인 화면도, 권한 관리도 필요 없다. 저장소에 push할 수 있는 사람이 곧 필자다.
정적 사이트 생성기와 궁합
이 구조는 Astro, Hugo 같은 정적 사이트 생성기(SSG)와 자연스럽게 맞물린다. SSG는 빌드 시점에 마크다운 파일들을 읽어 HTML로 굽는다. 결과물은 순수한 정적 파일이라 DB 서버도, 애플리케이션 서버도 없이 CDN에 얹기만 하면 된다. 요청마다 쿼리를 던지지 않으니 빠르고, 관리할 서버가 없으니 값도 싸다.
어디까지가 적정선인가
물론 만능은 아니다. 댓글처럼 방문자가 실시간으로 쓰는 데이터, 조회수 집계, 전문 검색이 핵심이라면 파일만으로는 버겁다. 글이 수만 편이 되면 빌드 시간도 부담이 된다.
핵심은 데이터의 성격에 저장소를 맞추는 것이다. 자주 안 바뀌고, 필자가 소수고, 문서 단위로 완결되는 데이터라면 파일 + git이 DB보다 단순하고 튼튼하다. 도구는 문제의 모양을 따라가야지, 관습을 따라갈 이유는 없다.
이 글에 대한 의견은 아래 댓글로 남겨주세요 (GitHub 계정 필요). 로그인 없이 남기고 싶다면