자동화 slecs

발행 전 드라이런으로 형식 오류 선제 차단

목차

포스트 발행 시스템에서 마크다운 스타일링과 메타데이터 처리를 자동화하는 작업이었다. 단순하지만 꽤 중요한 개선인데, 여러 개의 기능 개선을 한 커밋에 묶은 이유부터 풀어보자.

왜 형식 자동화가 필요했는가

컨텐츠 발행 시스템에서 가장 자주 마주치는 문제 중 하나가 휴먼 에러다. 포스트 작성자나 편집자가 일관된 형식을 유지해야 하는데, 특히 마크다운 헤더(H2, H3), 태그 정보, 메타데이터 같은 부분에서 스타일이 누락되거나 불규칙해진다. 예를 들어:

  • 어떤 포스트는 ## 헤더에 이모지가 있고, 다른 포스트는 없음
  • 태그를 수동으로 입력하다 보니 오타나 중복 발생
  • 포스트마다 헤더 형식이 조금씩 다르면 자동 생성되는 목차나 검색 인덱싱이 일관성 없이 동작

이런 문제들이 런타임에 드러나면 이미 발행이 된 후고, 사용자가 마주친다. 따라서 발행 전에 자동으로 보정하고, 검증하는 단계가 필수다.

한 커밋에 여러 기능을 포함시킨 의사결정

여기서 흥미로운 부분은 H2/H3 스타일, 캐릭터 헤더, 태그 자동, dryRun 이렇게 4가지를 한 커밋에 담았다는 것이다. 보통 각 기능을 분리된 커밋으로 작성하는 것이 관례인데, 이 경우는 다음 같은 이유로 묶기로 했다:

  1. 연관성: 모두 "포스트 발행 전 자동 검증/수정" 이라는 같은 목적의 기능들
  2. 테스트 일관성: dryRun 기능이 모든 변경을 검증하므로, 네 가지를 함께 테스트하는 게 더 안전
  3. 배포 원자성: 형식 규칙이 변경되면 검증 로직도 함께 업데이트되어야 하므로, 한 번에 배포되는 게 낫다

하지만 한 커밋에 너무 많은 변경을 담으면 리뷰 비용이 늘어난다. 팀원들이 각 변경의 의도를 파악하기 어렵고, 나중에 회귀(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

첫 댓글 달아줘.