발행 전 드라이런으로 형식 오류 선제 차단
목차
포스트 발행 시스템에서 마크다운 스타일링과 메타데이터 처리를 자동화하는 작업이었다. 단순하지만 꽤 중요한 개선인데, 여러 개의 기능 개선을 한 커밋에 묶은 이유부터 풀어보자.
왜 형식 자동화가 필요했는가
컨텐츠 발행 시스템에서 가장 자주 마주치는 문제 중 하나가 휴먼 에러다. 포스트 작성자나 편집자가 일관된 형식을 유지해야 하는데, 특히 마크다운 헤더(H2, H3), 태그 정보, 메타데이터 같은 부분에서 스타일이 누락되거나 불규칙해진다. 예를 들어:
- 어떤 포스트는
##헤더에 이모지가 있고, 다른 포스트는 없음 - 태그를 수동으로 입력하다 보니 오타나 중복 발생
- 포스트마다 헤더 형식이 조금씩 다르면 자동 생성되는 목차나 검색 인덱싱이 일관성 없이 동작
이런 문제들이 런타임에 드러나면 이미 발행이 된 후고, 사용자가 마주친다. 따라서 발행 전에 자동으로 보정하고, 검증하는 단계가 필수다.
한 커밋에 여러 기능을 포함시킨 의사결정
여기서 흥미로운 부분은 H2/H3 스타일, 캐릭터 헤더, 태그 자동, dryRun 이렇게 4가지를 한 커밋에 담았다는 것이다. 보통 각 기능을 분리된 커밋으로 작성하는 것이 관례인데, 이 경우는 다음 같은 이유로 묶기로 했다:
- 연관성: 모두 "포스트 발행 전 자동 검증/수정" 이라는 같은 목적의 기능들
- 테스트 일관성: dryRun 기능이 모든 변경을 검증하므로, 네 가지를 함께 테스트하는 게 더 안전
- 배포 원자성: 형식 규칙이 변경되면 검증 로직도 함께 업데이트되어야 하므로, 한 번에 배포되는 게 낫다
하지만 한 커밋에 너무 많은 변경을 담으면 리뷰 비용이 늘어난다. 팀원들이 각 변경의 의도를 파악하기 어렵고, 나중에 회귀(regression)가 발생했을 때 롤백 범위가 커진다. 이 부분에서는 명확한 커밋 메시지와 dryRun 같은 검증 장치가 얼마나 중요한지 배웠다.
드라이런 기능의 실제 가치
변경 파일 목록에서 test_dry.js 가 눈에 띈다. 이건 단순한 테스트 파일이 아니라, 실제 발행 로직을 실행하되 DB나 파일 시스템에 반영하지 않는 드라이런 모드다.
// 개념적 패턴 (실제 코드 아님)
async function publishPost(post, { dryRun = false } = {}) {
// 형식 자동화 + 검증
const validated = await validateAndFormat(post);
if (dryRun) {
console.log('(dry-run) Would publish:', validated);
return validated; // 실제 저장 안 함
}
// 실제 저장
return await savePost(validated);
}
이 접근은 다음 같은 이점이 있다:
- 팀원들의 신뢰도: "이 자동화가 정말 의도한 대로 동작하나?" 를 수동으로 검증할 수 있다
- 회귀 방지: 새 규칙을 추가할 때마다 dryRun으로 샘플 포스트 몇 개를 테스트하면 실수를 조기에 발견
- 온보딩 효율: 신입 팀원이 시스템을 이해할 때도 dryRun으로 "이렇게 변환된다" 를 눈으로 볼 수 있음
파일 변경의 의미
| 파일 | 역할 | 이번 변경의 영향 |
|---|---|---|
check_post.js |
포스트 유효성 검사 | H2/H3 스타일 규칙, 태그 형식 검증 추가 |
fmt_explore2.js |
포스트 탐색/파싱 | 캐릭터 헤더 추출 및 변환 로직 추가 |
lib_publish.js |
발행 라이브러리 | 자동 형식화 단계 통합, dryRun 파라미터 추가 |
server.js |
서버 엔드포인트 | dryRun 쿼리 파라미터 지원 |
test_dry.js |
드라이런 테스트 | 실제 발행 시나리오를 메모리상에서 시뮬레이션 |
작은 변경처럼 보이지만, 발행 파이프라인 전체에 터치하고 있다는 뜻이다.
회고
이 작업을 통해 느낀 점은, 자동화 기능을 추가할 때는 항상 "undo" 나 "verify" 메커니즘을 함께 고려해야 한다 는 것이다. 태그를 자동으로 생성하거나 헤더 스타일을 강제하는 건 좋지만, 팀원들이 "정말 이 형식이 맞나?" 를 검증할 수 있는 수단이 없으면 신뢰를 얻기 어렵다.
또 한 가지는, 여러 기능을 한 커밋에 담을 때 커밋 메시지의 정확성이 배로 중요하다 는 것. 메시지가 명확하지 않으면 리뷰 시간이 늘어나고, 나중에 코드 히스토리를 읽을 때도 혼란스럽다. "뭐가 바뀌었는가" 보다 "왜 이 네 가지를 함께 바꿨는가" 를 메시지와 코드에서 보여줘야 한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.