# S2 · 격리 게이트

> 전개하기 전에 "이 설계가 전개 가능한가"를 코드가 다시 봅니다. 그리고 추적의 앵커를 심습니다.

- 수치: 결정론
- 사람이 보는 화면: https://aitryed.com/ko/built/tc-team/s2/
- 반대 언어: https://aitryed.com/en/built/tc-team/s2/index.md
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

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

## 두 가지를 합니다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

그 결과 표의 데이터 줄 <strong>다섯 중 하나(20%)</strong>가 장부 밖에 있었습니다(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(남은 것은 변경 이력·빈 행·반복 헤더 등 의도된 제외). 세 단계 이상 들여쓴 목록과 목록 아닌 산문은 여전히 규칙으로 뽑지 않는다.

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

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