설계 검토 20건 전원 반대: 작업 흐름 엔진 폐기 결정

만들려던 게 있었다.

한국 웹소설 집필용 Claude Code 플러그인을 만들고 있다. 그 저장소에는 "개선 제안이 오면 이렇게 처리한다"는 절차가 문서로 있다. 여덟 단계다. 기각 이력 뒤지기 → 필요한지 판정 → 비판 검토 → 반영 → 검증 → 독립 검토 → 패치노트 → 블로그.

문제는 이게 산문이라는 것이었다. 읽고 따라 하는 것이다. 그러면 건너뛸 수 있다.

그래서 이걸 실행 가능한 그래프로 바꾸려 했다. 노드 11개, 되돌아가는 화살표 둘, 정지 조건 셋. 파이썬 러너가 지금 어느 단계인지 기억하고, 조건을 못 채우면 다음으로 안 넘겨준다.

논리는 우리 저장소 자신의 원칙 그대로였다.

같은 실패가 두 번 나오면 규칙이 아니라 검사로 고정한다. 규칙은 지키는 사람의 기억에 의존하고, 기억은 기본값으로 실패한다.

산문 단계는 건너뛸 수 있다. 스크립트가 막는 단계는 못 건너뛴다.

설계를 20명에게 던졌다. 각자 다른 각도로 보라고 했다. 이 대화를 전혀 모르는 상태에서.

짓자고 한 사람이 한 명도 없었다.

서로 모르는 사람들이 같은 곳을 짚었다

20명은 서로의 답을 못 본다. 그런데 겹쳤다.

일곱 명이 같은 걸 짚었다. 무진전 감지 — "같은 지적이 두 번 나오면 진전이 없는 것"을 판정하는 부분이다. 지적의 지문을 파일 + 줄번호 + 주장 으로 만들게 되어 있었다.

그런데 지적을 반영하면 파일이 바뀌고 줄번호가 밀린다. 같은 결함을 다시 지적해도 지문이 달라진다. 정지 조건 하나가 처음부터 죽은 코드였다.

다섯 명은 다른 걸 짚었다. 자기검증 단계 제목이 "반영 후 5회"인데 아래 항목이 여섯 개였다. 다섯만 채우고 넘어가면 빠지는 게 하필 "만든 기능에 도달 가능한지 실제로 확인했는가"였다. 그게 이전 릴리스의 실패를 잡은 항목이다.

그리고 격리가 설계를 무너뜨렸다

독립 검토를 제대로 하려면 검토자를 격리해야 한다. 우리는 git worktree 를 쓴다 — 같은 저장소의 별도 사본이다.

세 명이 각각 발견했다. worktree 는 커밋된 것만 가져온다.

반영은 커밋 전에 일어난다. 버전은 릴리스 단계에서 올라간다.

메인 작업 폴더:  반영된 코드   ← 방금 고친 것
검토자 폴더:     원본         ← 실제로 읽는 것

검토자는 고치기 전 코드를 검토한다. 그리고 "지금 보고 있는 게 맞는 판인가"를 확인하는 장치가 있었는데, 그게 버전 번호였다. 반영 시점과 검토 시점의 버전이 같으니 "판 맞다"고 도장까지 찍어 준다.

직접 돌려서 확인했다.

메인:     반영된 변경
worktree: 원본

검토가 아무 신호 없이 헛돈다. 그 상태의 worktree 에서 검증 스크립트를 돌리면 "통과 9 / 실패 0"이 나온다.

설계가 자기 논리에 자기가 걸렸다

정리하고 나서야 보였다.

세 줄 다 내가 쓴 기각 사유다.

실행체를 고르는 질문은 잘못 세운 질문이었다

두 번째로 물은 게 "이 검토를 무엇으로 돌릴까"였다. 후보 둘. 10명에게 물었다.

A 넷 / B 셋 / 제3안 셋으로 갈렸다.

갈렸다는 사실 자체가 답이었다. 그 축은 결과를 안 바꾼다.

한 명이 이유를 짚었다. 검토자를 어떤 도구로 띄우든, 저장소의 규범 문서가 자동으로 주입된다. "기본 동작을 덮어쓰는 지시"라는 딱지를 달고.

그러니까 규범 문서를 고치는 변경을 검토시키면, 검토자는 자기가 검토할 새 규범을 최우선 지시로 받고 시작한다. 도구를 바꿔서 넘을 수 있는 선이 아니다.

그리고 그 사람은 자기 프롬프트가 결론 방향을 유도했다고 스스로 신고했다. 내가 쓴 문장이었다.

안 지었더니 진짜 버그가 나왔다

20명이 설계를 부수는 동안, 부수는 근거로 저장소를 뒤졌다. 거기서 나온 게 더 값졌다.

배포된 문서에 거짓 문장이 있었다. "위 6개 중 하나로 좁혀라"인데 바로 위 표는 일곱 행. 최초 커밋부터 그랬고 여섯 번의 릴리스를 통과했다.

태그 두 개가 없었다. 패치노트에는 있는데 릴리스 절차 마지막 단계가 두 번 끊겼다.

검토자를 격리하는 순간 검증 스크립트가 가짜 실패를 냈다. 워크트리 안의 파일 사본이 "같은 파일이 두 곳에 있다"에 걸린다. 원인을 모르면 없는 문제를 고치러 간다.

릴리스 게이트 하나는 구조적으로 항상 건너뛰어졌다. 깨끗한 작업 트리를 요구하는데, 깨끗하면 비교 대상과 차이가 없어서 검사가 빈손으로 초록을 낸다. 침묵 실패를 잡으려고 만든 검사가 정작 릴리스 순간에 안 돌았다.

일곱 개를 찾았다. 러너는 그중 하나도 안 잡았을 것이다.

남은 것

설계는 이월했다. 조건을 적었다 — "제안 처리가 한 세션을 넘어간 사례가 한 건 나오면". 관측 가능해야 한다. "언젠가 필요해지면" 같은 조건은 영원히 안 온다.

절차를 기계로 고정하려는 설계는, 그 기계를 검사할 눈이 없으면 산문보다 나쁘다. 산문은 안 지키면 안 지킨 게 보인다. 초록 도장이 붙은 미검증은 안 보인다. 그리고 다음 릴리스가 그 초록을 근거로 쓴다.

---

webnovel-toolkit 의 제안 처리 자동화 설계 검토 기록. 이 툴킷이 무엇인지는 네 번의 릴리스에서 배운 것에 적어 뒀다.