# S5 · 적용

> 수정 계획을 적용하고 게이트 넷을 통과시킵니다. 거부가 정상 동작인 단계입니다.

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

---

**S5는 앞 단계(S4 리뷰)가 남긴 수정 계획을 테스트 케이스 표에 실제로 적용하고, 검문 넷을 통과시키는 단계입니다.**

테스트 케이스는 「이렇게 해 보고, 이게 되는지 확인」을 한 줄로 적은 점검 항목입니다. 수정 계획은 「몇 번 케이스의 이 칸을 이렇게 고쳐라」를 모은 목록이고, 검문은 표를 시트에 올리기 전에 코드가 기계적으로 걸러 보는 검사입니다.

걸리면 알아서 고쳐 넘어가지 않고, 대부분 **멈추고 사람을 부릅니다.** 그래서 «거부가 정상 동작»인 단계입니다.

## 「거부가 정상 동작」이 무슨 뜻인가

이 단계의 성격을 정하는 한 줄입니다.

수정 계획에는 <strong>「이 행이 지금 이렇게 되어 있다」</strong>는 현재 값이 같이 옵니다. 그리고 적용할 때 **그 값이 맞는지 먼저 확인**합니다.

**안 맞으면 적용하지 않고 거부합니다.**

| 상황 | 동작 |
|---|---|
| 현재 값이 계획과 같음 | 고침 |
| **현재 값이 다름** | **안 고치고 거부 → 런이 멈춤** |
| 고친 결과가 시트에 쓰기 직전 검사에서 막힐 문장이 됨 | 그 수정만 빼고 원래 문장을 둔 채 계속 |

왜 이게 중요하냐면 — **계획을 세운 시점과 적용하는 시점 사이에 내용이 바뀌었을 수** 있습니다. 그러면 **엉뚱한 것을 고칩니다.**

예를 들어 「7번 행의 「실패한다」를 「실패 메시지가 뜬다」로」라는 계획이 있는데, 그 사이에 행이 밀려서 **7번이 다른 케이스**가 됐다면 — 그대로 적용하면 **멀쩡한 케이스를 망칩니다.**

그래서 **거부는 고장이 아니라 안전장치**입니다. 엉뚱한 행을 덮어쓰느니 멈추는 쪽을 고른 것입니다.

사람 없이 혼자 도는 실행에서는 거부가 나오면 **런이 거기서 실패로 끝납니다.** 수정 계획을 알아서 다시 만들지는 않습니다 — 사람이 보고 계획부터 다시 세웁니다.

예외가 하나 있습니다(2026년 9월부터). 리뷰가 고친 문장이 오히려 **다음 단계의 쓰기 직전 검사에서 막힐 문장**이 되는 경우입니다. 이때는 그 수정 하나만 적용하지 않고 원래 문장을 남긴 채 계속 갑니다. 빠진 수정은 완료 보고에 목록으로 남습니다.

## 검문 넷 중 둘은 걸리면 곧장 멈춥니다

검문은 넷이고 각각 다른 것을 봅니다. 보통 떠올리는 「걸리면 고쳐서 다시 돌린다」가 아니라, 대부분 **멈추고 사람을 부릅니다.**

| 검문 | 보는 것 | 걸리면 |
|---|---|---|
| **표현** | 두루뭉술한 말, **근거 없이 남에게 미루는 표현** | **멈추고 사람을 부름** |
| **중복** | **케이스 한 줄이 글자까지 똑같은** 행 | **멈추고 사람을 부름** |
| **누락** | 장부에서 **안 챙겨진 규칙** | AI가 행을 보태 **딱 한 번** 메움 → 그래도 남으면 멈춤 |
| **분류** | 같은 분류가 **떨어져 앉음** | 코드가 자동으로 모음 |

여기서 «장부»는 기획서의 규칙마다 「이 규칙은 몇 번 케이스가 확인한다」를 적어 둔 표입니다.

넷 중 AI가 끼는 자리는 누락 메우기 하나뿐입니다. 보탤 행의 문장은 AI가 쓰고, 그 문장이 형식에 맞는지 확인해 표에 넣는 일은 코드가 합니다. 한 번 메웠는데도 빈 곳이 남으면 두 번째 기회는 없습니다.

## 중복 검문이 「완전 동일만」 막는 이유

이게 좋은 판단이었습니다.

중복 검문은 **완전히 똑같은 것만** 막고 **비슷한 것은 안 막습니다.** 견주는 것은 케이스 한 줄 전체 — 「무엇을 해 보고 무엇을 확인하는지」까지 적힌 문장입니다.

왜냐면 — **코드가 「비슷함」으로 자르기 시작하면 정당하게 비슷한 케이스까지 죽습니다.**

예를 들어 이 둘은 비슷합니다.

- 「재료가 **1개** 부족하면 실패한다」
- 「재료가 **전혀 없으면** 실패한다」

기계가 보면 거의 같은 문장입니다. 그런데 **둘 다 확인해야 하는 다른 경우**입니다. 경계값과 0은 다르게 깨질 수 있습니다.

그래서 **「비슷함」 판정은 앞 단계 AI가 맡고, 코드는 「완전히 같은 것」만** 봅니다.

> **기계가 판단할 수 있는 것과 판단하면 안 되는 것을 갈라야 합니다.**

## 중복이 나오면 지우기 전에 리뷰 전 문장부터 봅니다

똑같은 줄이 둘이면 하나를 지우면 될 것 같습니다. 그런데 먼저 **어떻게 똑같아졌는지**를 봐야 합니다.

리뷰(S4)는 두루뭉술한 말을 구체적으로 고칩니다. 그러다 문장 앞머리의 **전제 조건까지 같이 지우는** 일이 있습니다. 예를 들어 이 두 줄에서

- 「**재료를 넣은 직후** 연결이 끊기면 재료가 돌아오는지 확인」
- 「**결과가 뜨기 직전** 연결이 끊기면 재료가 돌아오는지 확인」

굵은 앞머리가 지워지면 두 줄은 글자까지 같아집니다. 원래는 **끊긴 순간이 다른 두 상황**이었는데요. 여기서 하나를 지우면 한 상황을 확인하던 케이스가 통째로 사라집니다.

2026년 9월 4일에 서로 다른 다섯 건이 이렇게 «중복» 두 쌍으로 뭉개진 일이 있었습니다. 그 뒤로 순서가 정해졌습니다.

| 리뷰 전 원래 문장이 | 할 일 |
|---|---|
| 서로 달랐다 | 지우지 않고 **지워진 앞머리를 되살림** |
| 원래도 같았다 | 진짜 중복 — 합치거나 차이를 적음 |

**아직 못 고친 것이 하나 있습니다.** 누락을 메우는 한 번의 라운드가 끝난 뒤에는 중복 검문을 **다시 돌리지 않습니다.** 그래서 AI가 보탠 행이 이미 있던 행과 글자까지 같은 채로, 그 한 쌍이 시트까지 올라간 적이 있습니다.

## 값을 치른 것 — 「번호는 변하고 내용은 안 변합니다」

안 챙겨진 규칙이 남으면 **행을 새로 만들어** 채웁니다.

그런데 **행을 끼워 넣는 순간 그 아래 번호가 전부 밀립니다.**

그러면 앞 단계에서 만든 장부의 번호가 **통째로 낡습니다.** 「3번 규칙은 7번 케이스가 담당」이라고 적어 뒀는데, **7번이 이제 8번**입니다.

처음엔 **계산해서 다시 매기려** 했습니다. **틀렸습니다.** 끼워 넣기가 여러 번 일어나고 순서도 섞이면 계산이 안 맞습니다.

지금은 **번호가 아니라 내용으로 잇습니다** — 큰 분류 + 작은 분류 + 확인 단계 + 케이스 한 줄 전체를 조합해서 찾습니다.

> **위치는 변하고 내용은 안 변합니다.**

## 다시 시작하면 리뷰가 고친 문장이 조용히 사라지던 구멍을 막았습니다

이 단계는 수정을 하나 적용할 때마다 <strong>「이건 적용했음」</strong>을 따로 적어 둡니다(적용 기록). 같은 수정을 두 번 하지 않으려는 장치입니다.

그리고 이 단계는 시작할 때마다 **리뷰 전 원본 표에서 처음부터** 최종본을 다시 만듭니다.

이 둘이 만나면 구멍이 생깁니다. 중간에 멈췄다 다시 시작할 때 **지난 시도의 적용 기록이 남아 있으면** —

1. 새로 만드는 표는 리뷰 전 원본인데
2. 기록에는 「이미 적용」이라고 적혀 있으니
3. 수정을 **건너뜁니다.**

결과는 리뷰가 고친 문장이 **리뷰 전 문장으로 조용히 되돌아간 표**입니다. 누락을 메운 행도 같이 빠집니다. 새 냄비에 처음부터 다시 끓이면서, 지난번에 체크해 둔 목록을 보고 「소금 넣음 ✓」이라며 소금을 건너뛰는 것과 같습니다.

**오류는 하나도 안 납니다.** 정상 종료이고 행 수도 맞습니다. 유일한 신호는 로그의 「건너뜀」 숫자 하나였습니다. 8월에는 리뷰가 고친 네 칸이 실제로 리뷰 전 문장인 채 시트에 올라갔고, 9월 초에는 **94칸이 전부 리뷰 전 문장인 채로 266행이 정상 완주할 뻔**했습니다.

2026년 9월 24~25일에 고쳤습니다. 지금은 이 단계가 시작할 때 **지난 적용 기록부터 비우고** 새로 적습니다. 장부도 리뷰 단계가 막 만든 상태로 되돌린 뒤 시작합니다.

제대로 됐는지는 이 식으로 봅니다.

> **적용 + 거부 = 계획에 든 수정 수 · 건너뜀 = 0**

건너뜀이 0이 아니면 성공이 아니라 기록이 오염된 것입니다. 다만 이 식은 아직 자동 검문이 아니라, **로그를 보고 사람이 맞춰 보는 식**입니다.

## 통과 표시는 남기지만, 아직 아무도 확인하지 않습니다

넷을 다 넘으면 **완료 표시 파일을 하나 떨어뜨립니다.**

원래 생각은 이랬습니다 — 중간에 멈췄다 다시 시작할 때 **파일이 있으면 이 단계는 끝난 것이고, 없으면 다시 돌린다.** 기억은 프로그램이 꺼지면 사라지지만 파일은 남으니까요.

그런데 2026년 9월 점검에서 **이 파일이 있는지 확인하는 코드가 한 곳도 없다**는 게 드러났습니다. 만들기만 하고 아무도 안 봅니다.

그래서 시트에 쓰는 단계(S6)나 마무리 단계(S7)부터 다시 시작하면, 이 단계의 검문을 통과했는지 **묻지 않고** 그대로 갑니다. 검문을 거치지 않은 표가 넘어갈 수 있는 길입니다. 아직 못 고쳤습니다.

> **표시를 남기는 것과 그 표시를 확인하는 것은 다른 일입니다.** 이 페이지도 한동안 「없으면 다시 돌린다」고 적고 있었습니다.

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

앞 단계가 낸 수정 계획을 적용하고, 그룹 경계를 봉합한 뒤, 게이트 넷을 통과해야 다음으로 간다. 적용과 검사는 전부 코드다 — 단, 미커버 봉합 행의 문장만은 AI(봉합 에이전트)가 쓰고 코드가 검증·적용한다(2026-09 기준).

## 거부가 정상 동작이다

수정 계획에는 "이 행이 지금 이렇게 되어 있다"는 before 값이 같이 온다. 적용기는 그게 안 맞으면 **적용하지 않고 거부한다.**

거부는 고장이 아니다. **그 사이 내용이 바뀌었다는 뜻**이고, 바뀐 자리에 낡은 수정을 얹는 것보다 계획을 다시 만드는 게 맞다. 앵커가 사라졌거나 다른 수정과 충돌해도 똑같이 거부한다.

무인 체인에서는 이 거부가 곧 런 실패다(2026-09 기준). 적용기가 exit 6 을 내면 체인이 거기서 실패로 끝나고, 계획을 자동으로 다시 만들지는 않는다. 예외는 2026-09-21 에 생긴 pre-write 회귀 거부 하나다 — S6 쓰기 전 검사의 차단 위반을 **새로** 만드는 edit 는 적용하지 않고 원문을 둔 채 런을 계속한다(종료 코드는 그대로, 거부 목록은 로그와 완주 보고에).

이걸 "성공률"로 보면 게이트를 느슨하게 만들고 싶어진다. 성공률이 아니라 **거부가 잡아낸 불일치 수**로 봐야 맞다.

적용 자체에는 판단이 없다. 앞 단계가 쓴 처방을 그대로 실행할 뿐이고, **처방대로 못 하겠으면 하지 않는다** — 알아서 비슷하게 고치는 경로는 아예 안 만들어 뒀다.

## 게이트 넷이 각각 다른 걸 본다

| 게이트 | 보는 것 | 걸리면 (2026-09 기준, 무인 실행) |
|---|---|---|
| 내용 | 추상 표현, 근거 없는 위임 | 런 정지 — 사람 확인(exit 14) |
| 중복 | F열(재현 스텝 한 문장 전체)이 완전히 같은 행 | 런 정지 — 사람 확인. 병합하거나 조건 차이를 명시 |
| 추적 | 커버리지 원장의 미커버 규칙 | AI 봉합 에이전트가 add_row 를 1라운드만 쓰고 코드가 검증·적용. 그래도 남으면 정지 |
| 그룹 | 같은 분류가 떨어져 앉음 | 자동 봉합 |

중복 게이트는 **F열 완전 동일만 차단**하고 유사는 안 막는다. 유사는 앞 단계 판정자가 볼 몫이라서다. 코드가 유사도로 자르기 시작하면 정당하게 비슷한 케이스까지 죽는다.

걸렸을 때는 지우기 전에 S4 이전 스냅샷의 F열부터 대조한다. 원본이 서로 달랐다면 S4가 추상 표현을 고치며 끊김 시점·사전 상태 접두부까지 지워 만든 중복이므로, 삭제하지 않고 접두부를 되살린다(2026-09-04 규칙). 한계 하나 — 봉합 라운드 뒤에는 중복 게이트를 다시 돌리지 않아, 봉합 행과 기존 행이 완전히 같은 한 쌍이 시트까지 간 적이 있다(미수리).

## 번호는 변하고 내용은 안 변한다

미커버 규칙이 남으면 행을 새로 만들어 봉합한다. 그런데 **행을 끼워 넣는 순간 그 아래 번호가 전부 밀린다.** 앞에서 만든 커버리지 원장의 번호가 그대로 낡는다.

여기서 번호를 산술로 밀어 맞추면 안 된다. 조인은 **내용으로** 한다 — 대분류·소분류·검증 단계·F열(재현 스텝 한 문장 전체)을 전부 쓴다.

소분류와 F열만으로는 부족하다. 같은 기획서 안에서 앞쪽 절이 뒤쪽 절의 문장을 다시 서술하는 일이 흔해서, 둘만 쓰면 엉뚱한 행에 붙는다. F열의 부분 일치로 찾는 것도 금지다 — 다른 행에 같은 표현이 있으면 그쪽을 잡는다.

확신이 안 서면 원장을 **확정본 기준으로 다시 만드는 편**이 안전하다. 낡은 원장을 억지로 맞추는 것보다 싸다.

## 통과했다는 표시를 파일로 남긴다

넷을 다 넘으면 완료 표시 파일을 하나 떨어뜨린다. 설계 의도는 **그 파일이 없으면 이 단계를 다시 돌린다**였다.

그런데 이 파일이 있는지 확인하는 코드는 0건이다(2026-09 기준) — 체인에서 이 파일이 나오는 곳은 만드는 한 줄뿐이다. 그래서 S6·S7 부터 재개하면 표시를 보지 않고 S5 게이트를 건너뛴다(2026-09-24 점검 지적, 미수리). 아래 문단은 의도로서는 유효하지만, 읽는 쪽이 생기기 전까지는 약속에 그친다.

이게 있어야 중간에서 재개할 수 있다. 종료 코드는 프로세스가 죽으면 같이 사라지는데, 파일은 남는다. 무인으로 도는 파이프라인에서 "여기까지는 됐다"를 아는 방법은 디스크에 적어 두는 것뿐이다.