[블로그를 파이프라인으로 만들기] 1. 발행 경로에 게이트를 박다

기술 블로그를 만들면서 가장 먼저 해결한 문제는 디자인이나 배포가 아니라 내가 쓰고 싶은 이야기를 그대로 쓰면 안 된다는 것이었다.

글감은 전부 운영 중인 서비스에서 나왔다. 근본 원인, 실제 수치, 티켓 번호, 예약번호가 붙어 있다. 이걸 지우는 걸 매번 기억해야 한다면 언젠가 빠뜨린다.

기억에 의존하는 규칙은 반드시 빠진다

이 판단에는 근거가 있었다. 개인 리포에 회사 이메일로 커밋된 파일을 그날 발견했기 때문이다. "개인 프로젝트는 개인 이메일로" 라는 규칙을 스스로 정해두고도, 리포 하나에서 설정을 빼먹은 상태로 몇 달이 지나 있었다.

규칙을 지키려는 의지가 부족했던 게 아니다. 지켜야 할 시점에 알려주는 것이 없었을 뿐이다.

검사 스크립트를 만들고 CI에 넣었다. 사내 고유명사가 남아있으면 종료 코드 1로 끝난다. PR은 머지되지 않는다.

if (blockCount > 0) {
  console.error("사내 고유명사가 남아있어 발행할 수 없습니다.");
  process.exit(1);
}

두 단계로 나눴다.

차단 — 회사명, 서비스명, 리포명. 이건 판단의 여지가 없다.
확인 필요 — 티켓번호, 예약번호 형태의 코드, 이메일, 내부 URL, 전화번호, 인프라 식별자, 커밋 해시. 맥락에 따라 남겨도 되는 경우가 있어 사람이 본다.

처음 만든 정규식은 HTTP2, JWT, SHA256, ISO8601을 예약번호로 잡았다. 대문자와 숫자가 섞인 7~8자 코드라는 조건에 정확히 들어맞았기 때문이다.

경고가 매번 20건씩 뜨는 검사는 아무도 읽지 않는다. 오탐이 많은 게이트는 없는 게이트와 같다. 허용 목록을 만들어 흔한 기술 약어를 걸러냈다.

통과하는 걸 확인하는 것으로는 부족하다. 잡아야 할 것을 실제로 잡는지 봐야 한다. 회사명, 티켓번호, 예약번호, 이메일, 내부 URL, 전화번호, 인프라 ID, 커밋 해시를 심은 파일을 만들어 돌렸다. 12건 전부 검출되고 정상 용어는 통과했다.

이 순서가 중요하다. 게이트가 아무것도 못 잡는데 초록불만 뜨는 상태가 가장 위험하다.