끝까지 걸은 순서표에서 드러난 숨은 전제 2건

TL;DR

• 다음 할 일을 하나만 내던 상태 안내를, 첫 회 발행 전에만 전부 내도록 바꿨다
• 끝까지 걸자 앞 항목이 대신 지켜 주던 전제 2건이 드러났다. 없는 표에 칸을 열라고 했다
• 같은 표에서 색인 22화 중 0화를 채운 상태가 '됨'으로 나왔다. 지금은 결과 파일마다 따로 본다
• 멈추던 목록을 끝까지 걷게 바꿀 때는 앞 항목이 지켜 주던 전제를 뒤 항목의 조건에 직접 적는다

증상

웹소설 작업 도구에 상태를 보는 명령이 있다. 원고와 설정 파일을 훑고 다음에 할 일을 하나만 알려 준다. 전부 늘어놓으면 쓰는 사람이 압도되어 아무것도 시작하지 않기 때문이다.

이 방식이 한 지점에서 틀렸다. 첫 회를 플랫폼에 올리면 회차를 합치거나 지우거나 순서를 바꿀 수 없다. 그 지점도 같은 한 걸음으로 지나갔다. 빠진 준비가 셋이어도 첫 하나만 보였다. 실제로 한 프로젝트가 발행 제목 없이 원고 18화와 다음 묶음 24화 설계까지 갔다.

그래서 첫 회를 올리기 전에만 한 걸음 규칙을 풀기로 했다. 목록을 새로 만들지는 않았다. 두 목록이 있으면 평소 안내와 점검이 언젠가 다른 말을 한다. 기존 순서표를 첫 항목에서 멈추지 않고 끝까지 걷게만 바꿨다.

def steps(st):          # 미충족을 순서대로 전부 낸다
    ...
def next_step(st):      # 평소 안내는 그 첫 항목
    return next(steps(st), None) or 종결_문구

평소 안내가 그대로인지는 옛 함수와 새 함수에 같은 무작위 상태 2만 개를 넣어 비교했다. 문구를 일부러 바꾼 자리를 맞춰 놓고 다시 재면 차이는 0건이었다.

반전

첫 항목에서 멈추는 목록에서는 순서가 뒤 항목의 전제를 대신 지킨다. 그래서 끝까지 걷게 바꿀 때는 그 전제를 뒤 항목의 조건으로 옮겨 적어야 한다.

평소 안내는 다르지 않은데 점검 표에서 틀린 문장이 나왔다. 두 자리였다.

표기 통일표는 같은 인물을 여러 이름으로 적은 것을 묶는 표다. 문체 기준은 원고에서 문장 습관을 통계로 뽑은 결과 파일이다.

둘 다 코드만 읽으면 맞았다. 칸 열기 바로 앞에 '표 만들기'가 있었고 그 항목이 걸리면 함수가 돌아갔으니 칸 열기는 표가 있을 때만 닿았다. 문체 기준은 앞의 후킹 진단(초반 회차에서 독자가 빠져나갈 지점을 보는 일)이 5편 미만을 막고 있었다. 조건에는 아무것도 안 적혀 있었다. 순서가 조건 노릇을 하고 있었다.

flowchart TD
  A[표가 없나] -->|예| B[표 만들기]
  B -->|평소: 여기서 멈춤| X[끝]
  B -->|끝까지 걷기: 계속| C[칸 열기]
  A -->|아니오| C
  C --> D["'묶는 쪽만 적혀 있다'"]

평소에는 '여기서 멈춤' 갈래로 끝나니 칸 열기에 닿을 때 표가 반드시 있다. 끝까지 걸으면 표가 없는 채로 칸 열기에 닿는다.

처리

전제를 조건에 직접 적었다. 칸 열기에는 '표가 있다', 문체 기준에는 '원고 5편 이상'을 붙였다.

반대 방향의 실수도 하나 했다. 점검 함수를 새로 쓰면서 "원고가 5편 미만이면 후킹 진단은 순서표가 이미 냈다"고 편수로 추정했다. 그런데 설정 파일이 없으면 순서표는 첫 항목에서 바로 멈춘다. 그 경우 후킹 진단이 표에서 아예 사라졌다. 순서가 지켜 준다고 믿은 것이 이번에는 거꾸로 틀렸다. 편수로 추정하지 않고 순서표가 그 항목을 실제로 냈는지를 보게 바꿨다. 목록이 일찍 끊기는 자리에서는 멈춘 이유를 함께 내서 "나머지는 판정하지 않았다" 줄을 표에 넣는다. 끊긴 목록이 전부처럼 읽히지 않게 하려는 것이다.

'됨'을 묶어서 판단할 때 생긴 거짓 2건

'됐다'는 표시는 결과 파일 하나마다 따로 판단한다. 같은 담당 스킬에 할 일이 남았다고 묶어 지우면 맞는 '됐다'도 같이 지워진다.

점검 표는 할 일만이 아니라 갖춘 것도 보여 준다. 처음에는 결과 파일이 원고와 맞으면 '됨'으로 냈다. 독립 검토가 실험 프로젝트를 만들어 돌려 보고 두 가지를 짚어 왔다.

• 회차 색인 골격(원고를 읽기 전에 기계로 셀 수 있는 값만 채운 색인)만 만든 상태에서 '색인 안 된 22화 채우기'와 '회차 색인 됨'이 한 표에 같이 나왔다. 골격은 원고 내용으로 만든 지문이 맞아서 최신으로 보인다. 최신이라는 것과 다 채웠다는 것은 다른 말이다
• 색인 도구가 만든 별칭 파일 하나 때문에, 작가가 쓴 적 없는 설정 바이블이 '됨'으로 나왔다

같은 담당 스킬에 할 일이 남아 있으면 '됨'을 안 내도록 묶었다. 다음 검토에서 작가가 직접 쓴 바이블이 표에서 사라졌다. 같은 스킬의 다른 할 일(칸 열기) 때문이었다. 묶음 단위를 버리고 결과 파일마다 따로 봤다. 색인은 다 채웠을 때만, 바이블은 작가가 쓴 파일이 있을 때만 '됨'이다.

부르는 시점이 섞인 질문

되돌릴 수 없는 일을 기록하는 명령에 점검을 붙일 때는, 그 명령을 일의 앞에서 부르는지 뒤에서 부르는지부터 정한다. 안 정하면 질문 하나가 이미 끝난 일과 이제 할 일을 섞어 받는다.

발행 표시 명령의 문서는 "플랫폼에 실제로 올린 회차를 git 태그로 표시한다"였다. 점검과 발행 안전성 검사(평문 입력창에서 마크다운 기호가 그대로 보이는지 보는 검사)는 올리기 전에만 뜻이 있다. 두 시점이 한 명령에 섞이자, 두 번째 발행에서 "3화까지 올렸다"고 답한 작가는 이번에 올릴 4화와 5화를 검사받지 못했다. 안전성 검사는 "검사할 회차가 없다"를 냈고 표시 명령은 이미 있는 3화 표시를 다시 만들려다 종료 코드 1로 끝났다.

명령을 올리기 직전에 부르는 것으로 정했다. 질문은 "이번 발행이 끝나면 몇 화까지 올라가 있게 되나요?" 하나다.

검증

회귀 검사 14개를 넣었다. 각 검사가 지키는 코드를 한 줄씩 부숴 16번 돌렸다. 처음 하나는 부숴도 통과했다. 같은 표시를 두 번 남기면 거부하는지 보는 검사였는데, 우리 거부 문구를 지워도 git 이 같은 이름의 태그를 거부해서 종료 코드가 같았다. 거부 문구까지 보게 고쳤고 나머지 15번은 전부 실패로 떨어졌다.

개선

직전 판과 비교한 것이다.

아래는 이번 판을 만드는 도중 검토가 잡아 발행 전에 고친 것이다.

남은 것

• "연재 준비 다 됐는지 봐줘" 같은 말은 정적 점검 도구에서 원고 검토 스킬 점수가 더 높게 나온다. 직전 판에서도 그랬다. 실제 대화에서는 시험하지 않았다. 명령으로는 닿는다
• 한 줄짜리 바이블 파일도 '됨'이 된다. 내용의 양을 보는 기준을 아직 못 정했다
• 프로젝트 폴더가 더 큰 저장소 안에 있으면 발행 표시를 저장소 전체가 같이 쓸 것으로 본다. 코드를 읽어 추정했고 실험하지 않았다

다음부터

첫 항목에서 멈추던 목록을 끝까지 걷게 바꿀 때는, 각 항목 앞에 무엇이 있어서 그 항목이 말이 됐는지를 세어 보고 그 전제를 조건에 직접 적는다. 그리고 앞 항목이 걸리는 상태를 일부러 만들어 뒤 항목의 문장을 읽어 본다.