# Git 커밋 없이 기술블로그를 발행하는 법: DB 직접 게시 파이프라인 실측기
## 요약
기술블로그(bungae-tech-blog)의 일일 아티클을 git 커밋·푸시·정적 재배포 없이 데이터베이스에 직접 게시하는 파이프라인을 실측했다. 핵심은 `blog_article_publish` 한 번 호출로 `tech_blog_articles` 테이블에 영속화하고, 블로그 API/동적 서빙 계층에서 실시간으로 노출하는 것이다. 발행 후에는 `blog_article_get`과 `blog_article_list`로 저장 여부를 직접 확인한다.
## 1. 배경: 왜 커밋 기반 발행을 피하는가
정적 마크다운 + git 커밋 방식은 단순하지만 일일 운영에는 세 가지 마찰이 있다.
1. **배포 대기**: 글 하나 올리려고 전체 사이트를 다시 빌드·배포해야 한다.
2. **충돌 위험**: 여러 필자가 같은 날 발행하면 브랜치·머지 관리가 늘어난다.
3. **검증 분리**: "DB에 저장됐는가"와 "배포됐는가"가 뒤섞여 원인 파악이 어렵다.
DB 직접 게시 방식은 이 셋을 분리한다. 글 저장은 DB 쓰기, 노출은 API 읽기, 사이트 껍데기 배포는 별개다.
## 2. 구조: 테이블 → API → 동적 서빙
파이프라인은 이렇게 단순하다.
```
아티클 작성 → blog_article_publish 호출 → tech_blog_articles 테이블 영속화 → 블로그 API/동적 서빙 계층에서 실시간 노출
```
조회 도구는 두 개다.
- `blog_article_list`: 목록 조회. 발행 후 전체 목록에 새 글이 보이는지 확인한다.
- `blog_article_get`: 슬러그별 상세·본문 조회. 저장된 본문이 깨지지 않았는지 확인한다.
git 커밋·푸시와 정적 배포 대기는 이 흐름에 없다. 대표 지침(2026-09-08 재강조)도 이 체계를 명시한다.
## 3. 인터페이스: 필수 필드 7개
`blog_article_publish`의 표준 필드는 다음과 같다.
- `title`: 글 제목
- `slug`: URL 식별자. 날짜 접미사 권장 (예: `...-2026-09-10`)
- `description`: 목록·SEO용 한 줄 요약
- `content`: 마크다운 본문
- `author`: 필자명
- `tags`: 검색·분류용 태그 배열
- `category`: `engineering` 등 대분류
호출 예시는 의사코드로 이렇다.
```ts
await blog_article_publish({
title: "Git 커밋 없이 기술블로그를 발행하는 법",
slug: "db-first-tech-blog-publishing-2026-09-10",
description: "DB 직접 게시 파이프라인의 구조·멱등성·검증 절차 실측기",
content: markdownBody,
author: "Evan",
tags: ["automation", "tech-blog", "database", "cms"],
category: "engineering",
});
```
## 4. 멱등성: 같은 slug를 다시 쓰면 어떻게 되는가
이 API의 중요한 동작은 슬러그 재사용 규칙이다.
- **같은 slug + 전체 아티클 동일 → 성공(멱등)**: 재시도·스케줄 중복 실행에 안전하다.
- **같은 slug + 내용 다름 → 실패 취급**: 덮어쓰기가 아니라 충돌로 본다. 제목을 고쳤다면 새 slug를 쓰거나 기존 글을 확인 후 조치한다.
그래서 일일 운영의 slug 규칙은 단순하다. `주제-YYYY-MM-DD` 형태로 날짜를 붙인다. 같은 날 재발행이 필요하면 본문이 바이트 단위로 같은지 먼저 확인한다. 이 규칙 하나로 "어제 글이 오늘 글에 덮어씌워졌다"는 사고를 원천 차단한다.
## 5. 검증: 발행했다고 말하기 전에 직접 읽는다
발행 후 검증은 두 단계다.
1. `blog_article_get(slug)`로 방금 쓴 slug를 다시 읽는다. 제목·본문·태그가 요청한 그대로인지 대조한다.
2. `blog_article_list`로 목록에 노출되는지 확인한다.
기대-실제(EXPECTED / ACTUAL) 비교 없이 "발행 완료"라고 말하지 않는다. 저장 확인이 실패하면 결과를 축소해 지어내지 않고 실패 사실을 밝힌다. 이것이 일일 운영의 최소 검증이다.
QA 판정 기준은 단순하다.
- 원본 수락 기준(스케줄 지시 실행: 1건 작성·업로드·배포 상태 검증)을 모두 충족하면 PASS.
- 저장·노출이 거부·미반영이면 FAIL.
- 외부 장애로 검증 자체가 불가하면 BLOCKED.
## 6. 운영 팁: 매일 1건을 깨지지 않게 돌리는 법
- **slug에 날짜를 붙인다**: 중복 충돌을 READ 단계에서 예방한다.
- **description을 먼저 쓴다**: 목록·검색 노출용 한 줄이 글의 방향을 잡아준다.
- **본문에 검증 섹션을 포함한다**: "어떻게 확인했는가"를 글 안에 남기면 다음날의 내가 고마워한다.
- **외부 수치는 출처와 함께만 쓴다**: 조회하지 않은 통계·트렌드는 쓰지 않는다. 확신 없는 숫자를 지어내느니 검증 가능한 내부 실측을 쓴다.
## 결론
기술블로그 일일 발행은 거창한 CMS가 없어도 된다. DB 쓰기 한 번과 읽기 두 번(단건+목록)으로 "썼다, 저장됐다, 보인다"를 닫을 수 있다. 내일도 같은 절차로 한 건을 쌓는다. 작은 파이프라인을 매일 검증 가능하게 돌리는 것이 자동화의 본질이다.