S2 · 격리 게이트

펼치기 전에 「이 설계로 펼쳐도 되나」를 코드가 다시 봅니다. 그리고 나중에 «빠짐없이 챙겼는지» 확인할 기준점을 여기서 심습니다.

두 가지를 합니다

무엇	왜
설계가 펼칠 만한지 판정	못 펼칠 설계로 시작하면 뒤가 전부 헛일
기획서를 규칙 단위로 쪼갬	나중에 「이 규칙 챙겼나」를 셀 기준점

그리고 앞 단계와 달리 둘 다 코드가 합니다. AI가 아닙니다.

설계가 틀리면 멈추고 사람을 부릅니다

검문 결과는 세 가지 중 하나뿐입니다 — 펼쳐도 됨 / 설계 결함 / 오류.

결함이면 그 자리에서 멈춥니다. 사람 없이 혼자 도는 실행은 스스로 앞 단계로 돌아가 고치지 않고, 「설계 수정 필요」라는 표시를 남긴 채 사람을 기다립니다. 사람이 설계를 고치면 이 단계부터 이어서 다시 돌립니다.

이 페이지도 처음에는 「앞 단계로 되돌려 고치고, 왕복 횟수를 센다」고 적었습니다. 코드를 열어 보니 그건 예비 절차 이야기였습니다.

누가 모나	설계 결함이 나오면
혼자 도는 실행(보통)	멈추고 사람을 기다림
사람이 단계를 한 칸씩 손으로 몰 때(예비 절차)	앞 단계로 되돌려 고치고, 왕복 횟수를 셈

「애매하니까 일단 진행」이 없습니다. 이게 이 도구의 성격입니다 — 뒤에서 고치는 것보다 앞에서 세우는 게 싸기 때문입니다.

「앞에서 봤는데 왜 또 보나」

앞 단계에서 이미 설계 검수를 한 번 했습니다. 여기서 또 봅니다. 중복 같은데 아닙니다.

	앞 단계 검수	여기 검문
누가	AI	코드
묻는 것	설계가 좋은가	펼칠 수 있는 형태인가
답의 성격	판단	기계적 판정

성격이 다릅니다. AI는 「이 설계 괜찮나」를 보고, 코드는 「필요한 칸이 다 채워져 있나」를 봅니다.

그리고 AI가 좋다고 한 설계도 칸이 비어 있을 수 있습니다. 내용은 훌륭한데 형식이 안 맞는 경우입니다. 그건 사람이 읽으면 안 보이고 기계가 봐야 보입니다.

그리고 기준점을 여기서 심습니다

두 번째 일입니다. 기획서 원문을 절과 규칙 단위로 쪼갭니다. 표는 2026년 9월 말부터 한 줄(행)이 통째로 규칙 하나가 되기도 합니다 — 왜 그렇게 바꿨는지는 바로 아래 절에 있습니다.

이 규칙 목록이 나중에 장부의 왼쪽 열이 됩니다.

기획서 규칙	어느 케이스가 확인하나
「재료가 부족하면 강화 불가」	7번, 12번
「10강 이상은 실패 시 하락」	23번
「강화권은 실패해도 소모」	(비어 있음) ← 이게 걸립니다

비어 있는 줄이 나오면 뒤 단계에서 걸립니다. 그러면 케이스를 보태서 채웁니다.

이게 왜 여기서 심어야 하냐면 — 기준점을 나중에 만들면 「만들어진 케이스 기준」으로 만들게 됩니다. 그러면 빠진 것을 빠졌다고 못 셉니다. 케이스가 없으면 규칙도 없는 것으로 세니까요.

기준은 결과보다 «먼저» 만들어야 합니다. 결과를 보고 기준을 만들면 항상 100% 통과합니다.

분모가 틀리면 100%도 거짓입니다

「몇 개 중 몇 개를 챙겼나」에서 「몇 개 중」이 분모입니다. 이 단계가 만드는 규칙 목록이 바로 그 분모입니다. 그 분모에 구멍이 있었습니다.

예전에는 기획서의 표를 칸 하나하나로 잘라 규칙을 만들고, 짧은 칸은 버렸습니다 — 숫자 하나, 「O」나 「X」 하나 같은 칸입니다. 한 줄의 칸이 전부 그런 칸이면 그 줄은 장부에 아예 안 올라갑니다.

그 결과 표의 데이터 줄 다섯 중 하나(20%)가 장부 밖에 있었습니다(39번 실행을 거슬러 센 것, 1,473줄 중 295줄). 그런데 42번의 실행이 전부 「빠진 규칙 0」으로 통과했습니다. 장부에 없는 규칙은 빠졌다고 셀 수도 없으니까요. 한 기획서에서는 표에 적힌 항목 53개 중 장부에 이름이 있던 게 25개뿐이었습니다.

	예전	2026-09-25부터
칸이 전부 짧은 표 줄	규칙 0개 → 장부에 없음	줄 전체가 규칙 1개(「머리글: 값」을 묶어서)
같은 42번 실행의 원문을 다시 자르면	규칙 5,868개	규칙 6,090개
규칙이 하나도 없는 표 줄	604줄	355줄

앞의 그 기획서는 53개 전부가 장부에 올라왔습니다. 남은 355줄은 변경 이력·빈 줄·되풀이되는 머리글처럼 일부러 빼는 줄로 분류됐습니다. (다시 자른 쪽은 42번 실행의 표 줄 1,919줄 전체를 센 것이라, 앞의 「1,473줄 중 295줄」과 셈법이 다릅니다.)

값을 치르고 배운 것은 이것입니다 — 「100% 챙겼다」는 분모만큼만 믿을 수 있습니다. 검문은 「세어 둔 것 중 빠진 게 있나」만 보고, 「애초에 세지 못한 것」은 못 봅니다. 그래서 초록불이 42번 연달아 켜져 있어도 아무도 몰랐습니다.

아직 못 고친 것도 있습니다. 세 단계 이상 깊이 들여쓴 목록과 목록이 아닌 줄글은 여전히 규칙으로 잘리지 않습니다.

여기부터는 자세한 기록입니다

두 가지를 한다. 설계가 전개 가능한지 판정하고, 기획서 원문을 규칙 단위로 쪼갠다. 앞 단계와 달리 둘 다 코드다.

만들기 전에 세운다

설계 게이트는 세 가지로만 답한다 — 전개 가능, 설계 결함, 오류. 결함이면 무인 체인은 exit 14 로 멈추고 사람을 기다린다(2026-09 기준 — 로그에 「세션에서 설계 수정 필요」). 앞 단계로 되돌려 수정 루프를 돌고 시도 횟수를 세서 무한 왕복을 막는 것은 사람이 단계를 손으로 모는 수동 폴백 절차의 규정이고, 체인 코드에는 그 카운터가 없다.

이 게이트가 없으면 결함 있는 설계로 수백 행을 만들고 나서 리뷰 단계가 그걸 발견한다. 틀린 설계로 만든 행은 고치는 것보다 버리는 게 싸다. 그래서 만들기 전에 세운다.

같은 문서를 두 번 보는 게 아니다

앞 단계에서 이미 설계 검수를 한 번 했다. 그런데 여기서 또 본다. 중복처럼 보이지만 아니다.

앞의 검수는 LLM이 읽었고, 여기는 코드가 읽는다.

둘은 못 보는 게 서로 다르다. LLM은 의미를 보는 대신 형식 위반을 자주 흘리고, 코드는 형식을 정확히 잡는 대신 “이 케이스가 말이 되는가”를 아예 못 본다. 그래서 같은 문서에 다른 종류의 눈을 두 번 대는 것이지, 같은 검사를 반복하는 게 아니다.

기계 게이트를 뒤에 둔 이유도 있다. 앞에 두면 LLM이 게이트를 통과하는 형태로만 쓰게 되고, 그러면 형식은 맞는데 내용이 빈 문서가 나온다.

원장의 앵커를 여기서 심는다

슬라이서가 원문을 절과 규칙으로 쪼갠다. 이 규칙 목록이 나중에 커버리지 원장의 왼쪽 열이 된다 — “기획서의 이 규칙이 어느 케이스로 검증되는가”.

2026-09-25 부터는 표 행에서 셀 규칙이 하나도 안 나오면 그 행을 행 단위 규칙 하나(from:"table-row", 머리글:값 묶음)로 만들고, 셀 규칙에는 그 행 문맥(row)을 붙인다. 그전에는 표를 칸 단위로 잘라 짧은 칸·한글 없는 칸을 버렸고, 2026-09-24 감사에서 현행 39런의 표 데이터 행 20.0%(295/1,473)가 원장 밖인데 42런이 전부 「미커버 0」으로 통과한 것이 드러났다. 수리 뒤 42런 원문을 다시 잘라 보니 규칙 5,868 → 6,090, 규칙 0개 행 604 → 355(남은 것은 변경 이력·빈 행·반복 헤더 등 의도된 제외). 세 단계 이상 들여쓴 목록과 목록 아닌 산문은 여전히 규칙으로 뽑지 않는다.

추적 가능성은 마지막에 붙이는 게 아니라 여기서 미리 심어야 한다. 나중에 붙이려 하면 “기획서에 규칙이 몇 개였나”를 다시 세야 하고, 그 숫자는 세는 사람마다 달라진다. 원문을 처음 읽을 때 한 번만 세는 게 유일하게 재현되는 방법이다.

그리고 분모를 먼저 고정해야 나중에 “다 덮었다”는 말에 의미가 생긴다. 분모를 나중에 세면 덮은 것만 세게 된다.