규칙에 없는데 33곳에서 복제된 부호

TL;DR

• 블로그 작성 규약에 낫표와 가운뎃점을 금지하는 항목이 없는데 초안마다 그 부호가 나왔다
• 규칙이 빠진 것이 아니라 규약 문서 본문이 그 부호를 33곳에서 쓰고 있었다. 같은 계열 문서는 0곳이다
• 규칙 한 절과 본문 33곳을 같이 고쳤다. 검사는 코드펜스를 건너뛰고 센다
• 그 문서는 자기가 정한 대시 금지 규칙도 한 곳에서 어기고 있었다

규칙에 없는 부호

이 블로그에는 글쓰기 규약을 적어 둔 문서가 있다. 대시 금지, 명사구 제목, 금지 표현 목록 같은 것이 들어 있다. 초안을 쓸 때 이 문서를 읽고 시작한다.

낫표 「」 와 가운뎃점 · 가 초안에 계속 나왔다. 규약에서 찾아보면 두 부호에 대한 항목이 없다. 금지 목록에도 없고 치환 표에도 없다. 규칙이 없으니 안 지켜지는 것이 당연해 보였다. 그래서 처음에는 금지 목록에 두 줄을 더하면 끝나는 일로 봤다.

문서가 시연하던 33곳

규칙을 적기 전에 그 문서 자체를 세어 봤다.

grep -o '「' SKILL.md | wc -l   # 18
grep -o '·' SKILL.md | wc -l    # 15

33곳이었다. 규칙이 없는 것이 아니라, 규칙을 적어 둔 문서가 그 부호를 33번 시연하고 있었다.

같은 계열의 다른 규약 문서와 비교하면 차이가 분명하다. 문체 일반론을 담당하는 문서는 같은 검사에서 0곳이 나온다. 두 부호를 쓰는 습관은 이 문서 하나의 것이었다.

사용자가 블로그 글을 써달라, 초안을 잡아달라 (...)
커밋 메시지·PR 본문·AGENTS.md·API 문서에는 쓰지 않는다.

위는 그 문서의 첫 부분이다. 규칙을 설명하는 문장 안에 가운뎃점이 들어 있다. 초안을 쓰는 쪽에서 보면 규칙 문장과 그 문장이 쓰인 방식이 같이 들어온다. 명시된 규칙은 한 줄이고 문체는 문서 전체에 깔려 있으니, 없는 규칙보다 있는 시연이 이긴다.

이 문서는 554줄이고 그중 33곳에 두 부호가 있었다. 열여섯 줄에 한 번꼴이다. 규칙 목록을 아무리 늘려도 본문을 그대로 두면 이 밀도가 계속 예시로 작동한다.

같은 검사를 대시로 돌리면 한 건이 더 나왔다.

TL;DR 은 본문 안에서 읽는 사람이 보는 것이다. 둘을 같은 문장으로 채우지 마라 —

대시는 그 문서의 첫 번째 하드 규칙이다. 규칙을 정한 문장에서 스무 줄 떨어진 곳에 그 규칙을 어긴 문장이 있었다.

규칙이 걸리는 문서와 안 걸리는 문서

같은 검사를 저장소의 AGENTS.md 에 돌리면 307줄에 가운뎃점 49개, 낫표 4개가 나온다. 그 문서는 사람과 도구가 저장소 규약을 확인하려고 읽는 것이지 블로그 글의 본보기가 아니다. 그래서 이 규칙의 대상이 아니다.

가르는 기준을 한 줄로 적으면 이렇다. 그 문서가 결과물의 본보기로 읽히는가. 글쓰기 규약은 결과물이 어떻게 생겨야 하는지를 말하는 문서라서 본문 자체가 본보기가 된다. 저장소 규약은 무엇을 지켜야 하는지를 말할 뿐 그 문장을 흉내 낼 일이 없다.

이 구분이 흔들리면 두 방향으로 잘못 간다. 전부 규칙 대상으로 잡으면 기술 문서에서 표를 정리하는 부호까지 걷어내게 되고, 반대로 전부 예외로 두면 정작 본보기가 되는 문서가 계속 반대로 시연한다. 판단은 문서 종류가 아니라 읽히는 방식으로 한다.

고친 범위

규칙 절을 하나 넣고 본문 33곳을 같이 바꿨다. 둘 중 하나만 하면 상태가 나빠진다. 규칙만 넣으면 문서가 자기 규칙을 어기는 상태가 되고 본문만 고치면 다음에 누가 다시 쓴다.

치환은 쓰임에 따라 갈린다.

증상·원인·결과 는 증상, 원인, 결과 가 되고 조사·어미 는 조사와 어미 가 된다. 가운뎃점을 전부 쉼표로 바꾸면 두 개짜리 열거가 어색해진다.

일괄 치환이 안 되는 자리

가운뎃점을 전부 쉼표로 바꾸는 명령 한 줄이면 끝날 것 같지만 결과가 어색해진다. A·B 는 A와 B 이고 A·B·C 는 A, B, C 다. 셋이 묶여 있어도 앞의 둘만 한 덩어리인 자리가 있어서 명령·경로·설정 은 명령이나 경로, 설정 이 된다. 이 문서에서는 일곱 자리를 하나씩 정했다.

낫표는 반대로 기계적이었다. 「A」 는 대부분 'A' 로 바꾸면 그대로 읽힌다. 인용문에 쓰인 것만 큰따옴표로 돌리면 된다. 열여덟 자리를 한 번에 처리했다.

검사가 자기 예시에 걸리는 문제

발행 전 기계 검사에 한 줄을 더했다. 처음에 쓴 것은 이렇다.

grep -nE '「|」|『|』|·' "$F"

이 검사는 규약 문서 자신에게 돌리면 걸린다. 금지 규칙을 설명하려면 예시로 그 부호를 써야 하기 때문이다. 코드블록 안의 예시까지 세면 규칙을 적을수록 검사가 더 시끄러워진다.

코드펜스를 건너뛰고 세면 갈린다.

awk '/^```/{f=!f;next} !f' "$F" | grep -nE '「|」|『|』|·'

지금 이 검사에 걸리는 것은 세 곳이고 전부 규칙을 정의하는 문장이다. 금지한다고 말하려면 그 부호를 한 번은 적어야 한다.

개선

• 규약 문서 본문에서 33곳이 3곳이 됐다. 남은 셋은 규칙 정의 문장이다
• 대시는 1곳에서 0곳이 됐다
• 검사는 코드펜스를 건너뛰므로 예시 블록이 늘어도 결과가 안 흔들린다

남은 것

• 이미 발행한 글 8편은 안 봤다. 새 규칙은 앞으로 쓰는 글에만 걸린다. 기존 글에 두 부호가 몇 개인지는 데이터베이스를 조회해야 알 수 있는데 아직 안 했다
• 저장소의 AGENTS.md 는 두 부호를 계속 쓴다. 그쪽은 사람이 읽는 규약 문서라 이 규칙의 대상이 아니다. 다만 초안을 쓰는 쪽이 두 문서를 같이 읽으므로 시연은 그대로 남아 있다. 이 경로로 다시 새어 나오는지는 다음 초안에서 확인해야 한다

다음부터

작성 규약에 금지 항목을 더할 때는 규약 문서 본문부터 같은 검사로 세고, 그 문서가 결과물의 본보기로 읽히면 규칙과 본문을 함께 고친다. 금지 부호를 세는 검사는 코드 블록을 건너뛰게 만들어 규칙을 설명하는 예시에 걸리지 않게 한다.