Markdown 기반 블로그를 선택한 이유와 운영 기준

Markdown 블로그를 고르면 관리 화면의 편안함을 일부 포기해야 합니다. 글 하나를 고치려면 파일을 열고, Git으로 남기고, 빌드까지 확인해야 합니다.

그런데 Daejin Lab에는 이 방식이 꽤 잘 맞았습니다. 글이 파일로 남고, 수정 이력이 보이고, 나중에 다른 블로그로 옮기기도 쉬웠습니다. 불편함이 있지만 그 불편함이 운영 기록이 되기도 했습니다.

왜 Markdown으로 시작했나

블로그 운영에서 Markdown을 쓴다고 미리 정한 건 아닙니다. 처음에는 WordPress처럼 눌러서 쓰는 편한 도구를 써볼 수도 있었다고 생각합니다. 그런데 이전에 간단한 블로그를 운영해보니, 글이 플랫폼 안에 갇히는 게 불안했습니다. 그래서 이번에는 파일 기반으로 시작했습니다.

Daejin Lab의 글은 아래 폴더에 들어갑니다.

src/content/blog/

파일 하나를 열면 title, description, pubDate, tags, category가 같이 들어있습니다. 예를 들어 지금 이 글의 파일을 열면 아래처럼 보입니다.

title: "Markdown 기반 블로그를 선택한 이유와 운영 기준"
description: "Astro 정적 블로그에서 Markdown으로 글을 관리하며 확인한 파일 관리, 빌드 검증, 다중 블로그 확장 기준을 기록했습니다."
pubDate: 2026-05-07
updatedDate: 2026-05-31
category: "블로그 운영"
tags: [Markdown, 정적 블로그, Astro, 블로그 운영]

이 구조는 원시적인 만큼, 어디서든 열립니다. 배포 전에 파일을 열어봤는데 frontmatter에 따옴표가 빠져 있어 빌드가 깨졌던 적도 있습니다. 그때는 이식성보다 검증이 우선이라는 생각이 들었습니다.

운영하면서 편했던 점

Markdown 방식에서 가장 편했던 부분은 글과 코드가 같은 검증 흐름 안에 있다는 점이었습니다.

글 수정
frontmatter 확인
npm run build
sitemap URL 수 확인
Git commit으로 변경 이력 저장

관리자 화면에서 글을 바로 발행하는 방식보다 한 단계 느립니다. 하지만 AdSense 준비나 Search Console 대응처럼 “무엇을 언제 바꿨는지”가 중요한 상황에서는 이 느림이 오히려 안전장치가 됩니다.

특히 Daejin Lab에서는 커스텀 도메인 전환 뒤 https://daejinlab.com/sitemap.xml이 같은 도메인 기준으로 생성되는지 확인했습니다. Markdown 글이 늘어나거나 보류 글이 생겨도 빌드와 sitemap 검증을 같이 묶을 수 있다는 점이 좋았습니다.

운영하면서 부딪힌 점

Markdown 방식이 항상 편한 것은 아닙니다. 이번 작업에서도 몇 가지는 계속 신경을 써야 했습니다.

frontmatter 형식이 틀리면 빌드가 깨질 수 있다.
글 파일 이름은 영어 slug로 관리해야 한다.
이미지 경로가 틀리면 대표 이미지가 빠질 수 있다.
휴대폰에서 바로 수정하기는 어렵다.
배포 전 빌드를 통과해야 실제 공개를 판단할 수 있다.

이미지가 늘어나면 별도 규칙도 필요합니다. 지금은 기존 OG 이미지를 재사용해 글마다 최소한의 대표 이미지를 붙이고 있습니다. 완벽한 썸네일보다, 먼저 “어떤 글이 기본 이미지 없이 보이는가”를 줄이는 것이 우선이었습니다.

Obsidian과 같이 쓰는 이유

Markdown 블로그는 Obsidian 메모와도 잘 맞습니다. 글감은 Obsidian에 빠르게 적고, 발행할 때는 src/content/blog/의 글 파일로 옮기는 방식이 자연스럽습니다.

관련 흐름은 Obsidian에서 블로그 글감을 관리하는 방법에 따로 정리했습니다. 핵심은 예쁜 지식관리 시스템을 만드는 것이 아니라, 글감이 실제 발행 글로 이어지게 하는 것입니다.

Daejin Lab에서는 글감 메모를 바로 공개하지 않습니다. 먼저 파일로 옮기고, 문장과 링크를 확인한 뒤, 발행 버튼을 자동화하지 않기로 한 이유에서 정한 것처럼 사람이 마지막 판단을 합니다.

다중 블로그로 확장할 때 보는 기준

나중에 전기차 블로그, 맛집 블로그, 제품 리뷰 블로그를 만든다고 해도 기본 구조는 비슷하게 가져갈 수 있습니다.

Astro 프로젝트
src/content/blog
카테고리 메타데이터
소개/문의/개인정보/광고고지
Cloudflare Pages 배포
Search Console 등록

달라지는 것은 주제, 카테고리, 사진·자료 수집 방식입니다. 그래서 Daejin Lab에서 먼저 글 작성 → 빌드 → 배포 → 공개 확인 흐름을 안정화하는 것이 중요했습니다.

지금 남긴 Markdown 운영 기준

Markdown 기반 블로그는 처음에는 조금 개발자스럽고 불편합니다. 하지만 장기 운영, 백업, 자동화, 다중 블로그 확장에는 잘 맞았습니다.

Daejin Lab에서는 이 구조를 1호 블로그의 기본 템플릿으로 보고 있습니다. 다음 블로그로 넘어가기 전에는 Cloudflare Pages 배포 후 꼭 확인하는 체크리스트처럼 반복 검증 흐름까지 같이 복제할 수 있어야 합니다.

장기 운영 관점에서 더 중요해진 점

Markdown 기반 블로그의 장점은 글을 파일로 관리한다는 데서 끝나지 않았습니다. 이번 보강처럼 여러 글의 updatedDate, 내부 링크, 본문 길이, 대표 이미지 상태를 한 번에 점검할 수 있다는 점이 더 컸습니다. GUI 편집기에서는 감으로 볼 일을, 파일 기반 구조에서는 스크립트와 Git diff로 확인할 수 있습니다.

장기 운영에서 특히 유용했던 점은 아래입니다.

변경한 글 목록이 git diff에 그대로 남는다.
보강 전/후 지표를 audit JSON으로 비교할 수 있다.
같은 구조를 다음 블로그에 복제하기 쉽다.
문제가 생기면 특정 커밋으로 되돌릴 수 있다.
Obsidian 메모와 발행 글을 분리해서 관리할 수 있다.

물론 Markdown은 처음에 불편합니다. 그래도 Daejin Lab처럼 수익화 준비, Search Console, 내부 링크, 여러 블로그 확장을 같이 고려한다면 이 불편함은 관리 가능한 비용이었습니다. 다음 단계는 GitHub Actions로 블로그 배포 자동화를 볼 때의 기준처럼 반복 검증을 조금씩 자동화하는 것입니다.

그래도 Markdown을 쓰는 이유

Markdown 블로그는 빠른 발행 도구라기보다 오래 남길 기록 도구에 가까웠습니다. 글을 쓰는 즉시 버튼을 누르는 편함은 줄지만, 파일과 커밋으로 관리할 수 있습니다.

Daejin Lab처럼 실험 과정을 남기는 블로그라면 이 방식이 나쁘지 않았습니다. 다만 글을 자주 고치고 배포까지 해야 하니, 빌드 검증 루틴은 꼭 같이 가져가야 합니다.

불편함이 기록을 남겼다

Markdown 블로그는 편집 화면이 친절하지 않습니다. 대신 파일로 남고, 변경 이력이 남고, 빌드가 통과했는지도 확인할 수 있습니다. 오래 운영할 블로그를 실험하는 입장에서는 이 불편함이 오히려 운영 기록을 만드는 데 도움이 됐습니다.

2026-05-31에 다시 본 Markdown 블로그의 장단점

Markdown 블로그는 가볍게 시작하기 좋습니다. 하지만 공개 사이트로 운영하면 단순한 파일 묶음이 아닙니다. frontmatter, 이미지 경로, sitemap, RSS, draft 상태가 모두 공개 품질과 연결됩니다. 이 글은 Markdown의 편리함뿐 아니라 검증 책임까지 같이 설명해야 했습니다.

작성, frontmatter 구조, build 검증, 공개 책임으로 이어지는 Markdown 블로그 장단점 지도

이 카드는 Markdown 블로그가 가볍지만, 공개 단계에서는 구조와 검증이 필요하다는 점을 보여줍니다.

참고한 공식 문서

확인하지 않은 것

이 글은 WordPress, Notion, Ghost 같은 다른 CMS와의 정량 비교가 아닙니다. Daejin Lab에서 Markdown 기반 정적 블로그를 쓰며 느낀 장단점을 정리한 글입니다.

FAQ

Markdown 블로그의 가장 큰 장점은 무엇인가요?

파일 기반이라 구조가 단순하고 git으로 변경 이력을 남기기 쉽습니다.

가장 큰 단점은 무엇인가요?

자동으로 품질을 보장해주지 않는다는 점입니다. 메타데이터, 이미지, 링크, build를 직접 챙겨야 합니다.

얇은 파일 목록처럼 보이지 않도록 실제 경험, 출처, 이미지, FAQ, 내부 링크를 함께 갖춰야 합니다.