# tc-team

> 기획서를 넣으면 테스트케이스가 나온다. LLM은 문장만 쓰고, 구조와 게이트는 전부 결정론 코드가 소유한다. AI가 실행할 문서 묶음으로도 낸다.

- 수치: S0–S7
- 사람이 보는 화면: https://aitryed.com/ko/built/tc-team/
- 반대 언어: https://aitryed.com/en/built/tc-team/index.md
- 저장소: https://github.com/nobles92ts-ship-it/AI_GAME_QA_TestCase
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

**기획서를 넣으면 «테스트 케이스»가 표에 채워집니다. 핵심은 「AI가 써 준다」가 아닙니다 — 그건 아무나 엉망으로 할 수 있습니다. 진짜는 «AI에게 무엇을 안 맡겼는가»입니다.**

## 먼저 — 「테스트 케이스」가 뭔가요

게임이나 앱을 만들면 **제대로 되는지 확인**해야 합니다. 그런데 「잘 되나 봐 주세요」로는 확인이 안 됩니다. **뭘 눌러서 뭐가 나와야 하는지**를 미리 적어 둬야 합니다.

그 적어 둔 한 줄이 **테스트 케이스**입니다. 대략 이런 모양입니다.

| 항목 | 내용 |
|---|---|
| **무엇을** | 아이템 강화 |
| **어떻게** | 강화석 없이 강화 버튼을 누른다 |
| **그러면** | 「재료가 부족합니다」가 뜨고 강화가 안 된다 |

이런 걸 기능 하나에 수십 개씩 씁니다. **손으로 쓰면 오래 걸리고, 쓰다 보면 빠뜨립니다.**

이 도구는 **기획서를 넣으면 이 표를 채워 줍니다.**

2026년 10월부터는 같은 케이스를 **AI가 읽고 직접 확인할 문서 묶음**으로도 냅니다. 아래 「AI용 판」 절에 적었습니다.

## 핵심은 「AI가 쓴다」가 아닙니다

여기가 이 도구의 정체입니다.

**AI에게 「테스트 케이스 써 줘」 하면 씁니다.** 그건 누구나 할 수 있습니다. 문제는 **결과가 매번 다르다**는 것입니다.

- 오늘은 번호가 1부터고 내일은 0부터
- 어떤 날은 열이 여섯이고 어떤 날은 일곱
- 같은 기획서를 두 번 넣으면 **결과가 다름**

그래서 이 도구는 **역할을 갈랐습니다.**

| 누가 | 무엇을 소유하나 |
|---|---|
| **코드**(정해진 프로그램) | **순서 · 표의 뼈대 · 번호 · 서식 · 빠짐없이 챙겼는지 원장 · 표에 쓰기** |
| **AI** | **문장 · 설계 판단 · 지적 · 판정** |

즉 **AI는 「말」만 쓰고, 「모양」은 전부 코드가 잡습니다.**

왜 이렇게 했냐면 — **처음엔 AI가 전부 몰았는데, 하다 보면 자기가 정한 규칙에서 슬슬 벗어났습니다.** 30번째 줄쯤 가면 서식이 달라져 있습니다. 나쁜 뜻이 있어서가 아니라 **원래 그런 성질**입니다.

**모양을 코드가 쥐고 있으면 벗어날 수가 없습니다.**

## 여덟 단계로 돕니다

| 단계 | 하는 일 | 주인 |
|---|---|---|
| **0** | 원문 모으기, 다른 사람이 동시에 못 돌리게 잠그기, **입력이 멀쩡한지 자가 점검** | 코드 |
| **1** | 기획서 읽고 **설계 뼈대** 만들기 — 가장 센 AI가 맡는 자리 | AI |
| **2** | 설계가 쓸 만한지 **검문** | 코드 |
| **3** | 뼈대 만들고 → **문장 쓰기를 넷이 나눠서** → 합치기 | 코드 + AI |
| **4** | **적대적으로 검토** · 판정 · 빠짐없이 챙겼는지 기록 | AI |
| **5** | 수정 적용 + **검문 4종** — 빠진 규칙이 있으면 AI가 한 번 메워 봄 | 코드 + AI |
| **6** | **실제 표에 쓰기** | 코드 |
| **7** | 마무리 · 줄마다 **믿을 만한 정도 점수** · 대시보드 | 코드 |

0단계 준비만 따로 하고, **1~7단계는 명령 한 줄로 끝까지 혼자 돕니다.** 시작할 때 사내 채널에 「이거 만들기 시작합니다」 공지가 한 번 나갑니다.

## 성격을 정하는 것 — 「못 넘으면 섭니다」

이 도구는 **「최선을 다해 계속」하지 않습니다.**

중간중간 검문소가 있고, **못 넘으면 멈추고 사람을 부릅니다.** 멈추기 전에 스스로 고칠 수 있는 것은 먼저 몇 번 고쳐 봅니다.

| 검문소 | 걸리면 |
|---|---|
| 입력 점검 | 한 번 다시 모아 보고, 또 실패하면 **아예 시작 안 함** |
| 설계 검문 | **멈춤** — 사람이 설계를 고친 뒤 그 자리부터 이어서 |
| 합치기 대조 | **어긋난 조각만** 다시 |
| 표현 검문 | **두루뭉술한 말**을 스스로 최대 3번 고쳐 보고, 안 줄면 멈춤 |
| 수정 적용 | **「거부」가 정상 동작** — 고칠 대상이 예상과 다르면 안 고치고 멈춤 |
| 중복 검문 | 한 글자도 안 다른 케이스가 남아 있으면 멈춤 |
| 누락 검문 | **안 챙긴 규칙이 있으면** AI가 한 번 메워 보고, 그래도 남으면 멈춤 |

「수정 적용」 줄이 특히 중요합니다. **「고치려고 열었는데 내용이 예상과 다르면 안 고치고 멈춥니다.」** 사이에 누가 손댔을 수 있으니까요. **거부가 고장이 아니라 정상 동작**입니다.

이 성격에는 값이 붙습니다. 2026년 9월에 기록을 거슬러 세어 보니 **처음부터 끝까지 돌린 38번 가운데 13번(34%)이 한 번 이상 멈췄다가 사람 손으로 이어졌습니다.** 틀린 표를 조용히 내보내는 것보다는 낫지만, 「알아서 다 해 주는 도구」는 아직 아닙니다.

## 검토는 협력이 아니라 「적대」입니다

만들어진 케이스를 **여러 시선이 «동시에» 읽습니다** — 구조 보는 눈, 품질 보는 눈, 원문과 대조하는 눈.

그리고 **서로의 결과를 모릅니다.**

일부러 그렇게 했습니다. **서로 알면 의견이 수렴하고, 수렴하면 «같은 것»을 같이 놓칩니다.** 셋이 따로 봐야 셋이 다른 걸 잡습니다.

셋이 낸 지적은 **판정하는 AI 하나**가 모아서 따져 보고, 헛짚은 것을 걸러 냅니다. 남은 지적은 AI가 직접 고치지 않고, <strong>코드가 적용할 수 있는 «수정 계획»</strong>으로만 적습니다. 실제로 고치는 건 5단계의 코드입니다.

## 9월에 바뀐 다섯 가지 — 도구는 쓰면서 계속 고칩니다

2026년 9월 24일에 도구 전체를 한 번 점검했습니다. 결함 후보 50건을 찾았고, 각 후보마다 다른 AI가 반박을 시도하게 해서 걸러 냈습니다. 그 결과로 이런 것들이 바뀌었습니다.

| 무엇이 | 쉽게 말하면 |
|---|---|
| **설계는 가장 센 AI가** (9/24) | 한 번 돌 때 걸리는 시간의 64%가 1단계 설계라, 품질이 가장 크게 갈리는 자리입니다. 설계만 Claude Opus 5.5 에게 맡깁니다. 비교해 보니 세 기능 중 두 기능에서 결과가 더 좋았습니다 |
| **모르는 건 사내 위키부터** | 기획서에 답이 없어 「기획 확인 필요」로 남긴 것을, 회사 위키와 데이터 표에서 먼저 찾아봅니다. 답을 찾으면 담당자에게 물어볼 목록에서 뺍니다 |
| **표 안의 규칙도 한 줄씩** (9/25) | 기획서 안의 **표**는 규칙 장부에 다 들어가지 못하고 있었습니다. 표 속 줄의 20%가 장부 밖이었는데, 검사는 「빠진 것 0」이라며 통과시켰습니다. 장부에 없으면 빠졌는지도 모르니까요 |
| **이어 돌려도 고친 게 남게** (9/25) | 중간에 멈췄다가 이어서 돌리면, 4단계 검토가 고친 내용이 **조용히 버려지는** 결함이 있었습니다. 겉으로는 정상 완료였습니다 |
| **일하는 AI를 격리** (9/25) | 단계마다 불려 나오는 AI가 제 개인 설정·플러그인·기억까지 통째로 싣고 일하고 있었습니다. 그 틈으로 설계 AI가 제 드라이브에 직접 파일을 쓰고 지운 일도 있었습니다(자기가 만든 사본 110개, 원래 있던 파일 손실은 0). 지금은 **그 단계에 필요한 도구만** 들고 일합니다 |

마지막 줄은 돈이 꽤 줄 거라고 보고 시작했는데, 같은 기획서로 켜고 끄고 재 보니 **7% 남짓**(두 쌍만 비교해서 확정은 못 함)이었습니다. 진짜 이득은 다른 데 있었습니다. 단계마다 불려 나온 AI가 처음 받는 지시에 **이 일과 상관없는 내용**(다른 작업의 요약 같은 것)이 끼어든 횟수가 **격리를 켜면 23번 중 0번, 끄면 23번 중 23번**이었습니다.

## 값을 치르고 배운 것 — 「번호로 이으면 안 됩니다」

제일 아팠던 자리입니다.

빠짐없이 챙겼는지 기록하는 장부가 있는데, 처음엔 **케이스 번호로** 가리켰습니다 — 「3번 규칙은 7번 케이스가 담당」처럼요.

그런데 **중간에 행을 하나 끼워 넣으면 그 뒤 번호가 전부 밀립니다.** 7번이 8번이 됩니다. 장부는 여전히 7번을 가리키는데, **7번은 이제 다른 케이스**입니다.

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

지금은 **번호가 아니라 «내용»으로 잇습니다** — 분류 + 확인 단계 + 재현 방법을 조합해서요.

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

## AI용 판 — 같은 엔진에 출구만 하나 더 달았습니다

2026년 10월에 **tc-team-ai**를 더했습니다. 같은 엔진이 만든 테스트 케이스를 사람이 보는 시트 대신, **AI가 읽고 직접 게임을 확인할 수 있는 문서 묶음**으로 내는 판입니다. 기획서만 넣으면 됩니다.

| | 사람용 | AI용 |
|---|---|---|
| 넣는 것 | 기획서 + 구글 시트 | **기획서만** |
| 도는 단계 | 0~7단계 | 0~5단계 — 시트에 쓰는 6·7단계는 건너뜀 |
| 나오는 것 | 시트의 표 | 문서 묶음 — 실행 규칙, 케이스, 기획서 원문, 빈 결과표 |

따로 낸 이유는 하나입니다. **사람과 AI는 같은 한 줄을 다르게 읽습니다.** 사람은 「강화석 없이 강화 버튼을 누른다」만 봐도 강화석을 어떻게 비워 둘지, 화면 어디를 봐야 할지 압니다. AI는 그 빈칸을 짐작으로 메우다 헤맵니다.

그래서 한 줄을 네 칸으로 나눠 붙입니다.

| 칸 | 위 예시라면 |
|---|---|
| **전제** — 미리 갖춰 둘 것 | 강화석이 하나도 없는 캐릭터 |
| **조작** — 할 일 | 강화 버튼을 누른다 |
| **기대** — 나와야 하는 것 | 「재료가 부족합니다」가 뜨고 강화가 안 된다 |
| **관측** — 무엇을 보고 판단하나 | 안내 문구, 그리고 강화 단계 숫자가 그대로인지 |

나누는 일은 AI가 합니다. 그래서 제일 무서운 건 **나누다가 뜻이 바뀌는 것**입니다. 「0개」가 「1개」로 옮겨 적히거나 「열리지 않는지」가 「열리는지」로 뒤집히면, AI는 엉뚱한 것을 확인하고 PASS를 적습니다. 여기서도 코드가 지킵니다 — 원문의 숫자·영어 이름·따옴표 속 문구가 네 칸에 그대로 있는지, 부정이 뒤집히지 않았는지 검사하고, 두 번 걸린 케이스는 원문 한 줄만 냅니다.

**정본은 언제나 원문이고, 네 칸은 도움말입니다.** 묶음 맨 앞의 실행 규칙에도 그렇게 적혀 있습니다.

AI가 지킬 규칙도 그 자리에 같이 넣었습니다. 증거(스크린샷 경로·로그 한 줄·DB 값) 없이는 PASS도 FAIL도 적지 못합니다. 그리고 **기획서가 정하지 않은 동작을 「버그」라고 적으면 안 됩니다.** 그런 케이스는 처음부터 「판정 보류」 표시를 달고 나가고, AI는 FAIL 대신 BLOCKED(기획)로 적은 뒤 실제로 본 것을 메모합니다.

10월 8일에 사내 기획서 하나로 끝까지 돌려 봤습니다. 케이스 106개가 나왔고, 106개 모두 네 칸으로 나뉘어 검사를 통과했습니다. 15개는 판정 보류였습니다. 1시간 38분 걸렸는데 그중 81분이 설계였고, 네 칸 나누기는 6분 남짓이었습니다.

**여기서 「번호로 잇지 말 것」을 한 번 더 겪었습니다.** 묶음은 케이스마다 「이건 기획서의 어느 규칙에서 나왔나」를 붙여 줍니다. 그 정보는 4단계 장부에 있는데, 장부의 번호는 5단계가 번호를 다시 매기기 «전» 번호입니다. 그래서 번호 대신 문장으로 이었습니다.

그런데 **같은 문장이 두 군데** 있을 수 있었습니다. 맨 앞의 기본 점검 목록과 본문에 똑같은 문장이 들어가는 경우인데, 일부러 허용해 둔 겹침입니다. 지난 기록 65번 가운데 29번에 이런 쌍이 있었습니다. 지금은 장부가 가리킨 쪽(기본 점검인지 본문인지)을 먼저 고르고, 그래도 하나로 안 갈리면 **붙이지 않고 그 수를 셉니다.** 틀린 근거를 붙이느니 빈칸이 낫습니다.

**아직 못 한 것도 적어 둡니다.**

- **AI가 이 묶음을 들고 실제 게임을 확인해 본 적은 아직 없습니다.** 결과표는 빈칸입니다. 지금까지 검증한 것은 «만드는 쪽»뿐입니다.
- **상태를 만드는 법은 묶음에 없습니다.** 치트, 테스트 계정, 로그 보는 법은 게임마다 달라서 그 프로젝트가 따로 줘야 합니다. 안 주면 그 케이스는 BLOCKED(환경)로 남습니다.
- **검사가 못 잡는 바뀜이 있습니다.** 원문에 없던 부정이 새로 붙는 것, 숫자 없는 조건이 슬쩍 더해지는 것은 평범한 바꿔 말하기와 구분이 안 됩니다. 원문을 정본으로 둔 까닭이 이것입니다. 「안 된다」처럼 짧게 쓴 부정이 빠지는 것도 처음엔 통과했습니다 — 위 예시의 「강화가 안 된다」가 바로 그 꼴입니다. 이건 10월 12일에 고쳐서 이제는 걸립니다.

## 정직한 한계

**기획서가 부실하면 결과도 부실합니다.**

이 도구는 **없는 기획을 지어내지 않습니다.** 근거가 없으면 케이스를 만드는 대신 **「기획 확인 필요」로 표시하고 넘어갑니다.**

저는 그게 맞다고 봅니다 — **지어낸 케이스는 나중에 「이거 어디서 나온 거야」가 되고, 그때는 아무도 답을 모릅니다.**

다만 **기획이 얇은 조직에서는 산출량이 기대보다 적게 나옵니다.** 그건 도구 탓이 아니라 **재료 탓인데, 쓰는 사람에게는 똑같이 실망**입니다.

**느립니다.** 기능 하나를 처음부터 끝까지 돌리면 가운데값이 **1시간 36분**이고, 그중 64%가 설계입니다. 8월 27일을 기준으로 앞뒤를 나눠 보면 설계 한 번의 가운데값이 **41분에서 67분**으로 늘었습니다. 그날 설계를 더 센 AI로 올렸지만, 늘어난 게 그 때문인지는 따로 재 보지 않았습니다.

**아직 못 고친 것도 있습니다.** 9월 점검에서 찾았고 고칠 차례를 기다리는 것 둘을 적어 둡니다.

- **같은 폴더에서 다시 돌리면 지난번 탭을 «내 것»으로 보고 지운 뒤 새로 씁니다.** 그사이 사람이 그 탭에 테스트 결과를 적어 뒀다면 같이 사라질 수 있습니다. 「우리 탭인가」를 시트가 아니라 제 컴퓨터의 표시 파일로 판단해서 생기는 일입니다.
- **「검문을 다 통과했다」는 표시 파일을 남기지만, 그걸 확인하는 코드가 없습니다.** 그래서 중간 단계부터 이어서 돌리면 5단계 검문을 건너뛸 수 있습니다. 문서에는 「표시가 없으면 다시 돈다」고 적혀 있었는데, 코드가 그 약속을 지키고 있지 않았습니다.

## 기각한 것들

버전 기록은 대체로 **「진척처럼 보였는데 아니었던 것」의 목록**입니다. 만든 것보다 **뺀 것**이 더 많습니다.

> **[도판]** 검은 칸은 결정론 코드가, 주황 칸은 모델이 맡는다. S3만 두 레인을 오간다 — 코드가 골격을 만들고, 모델이 문장을 채우고, 코드가 다시 병합한다. 삼각형은 게이트고, 못 넘으면 그 자리에서 선다.
>
> S0부터 S7까지 여덟 단계를 코드 레인과 LLM 레인으로 나눈 흐름도. 코드가 S0·S2·S5·S6·S7을, LLM이 S1·S4를 맡고 S3은 두 레인을 오간다. 게이트는 S0·S2·S3·S5에 있다.

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

기획서 원문을 넣으면 라이브 스프레드시트 탭에 테스트케이스 세트가 채워진다. 원문을 받아 두는 준비(S0) 뒤로는 한 번의 호출로 끝까지 돈다.

핵심은 "LLM이 TC를 쓴다"가 아니다. 그건 아무나 엉망으로 할 수 있다. 진짜는 **역할을 가른 것**이다.

> **2레인 원칙 — LLM은 문장과 판단만, 결정론 코드가 구조와 사실을 가진다.**

## 왜 갈랐나

초기엔 모델이 파이프라인 전체를 몰았다. 드리프트했다.

단계마다 행 수가 달라지고, 커버리지가 조용히 떨어지고, **두 번 돌려서 같은 모양이 나온 적이 없었다.** 모델은 "대충 맞게" 하는 데는 훌륭한데, 같은 입력에 같은 출력을 내는 데는 쓸 수 없다.

해법은 설득이 아니라 **몰수**였다.

| 소유자 | 가진 것 |
|---|---|
| 결정론 코드 | 단계 순서, 행 골격, 번호, 서식, 병합, 커버리지 원장, 시트 기록 |
| LLM | 설계 판단, 문장, 리뷰 지적, 판정 |

## 여덟 단계

| 단계 | 하는 일 | 주인 |
|---|---|---|
| **S0** | 원문 수집, 실행락, 입력 자가검증 | 코드 |
| [**S1**](/ko/built/tc-team/s1/index.md) | 기획서 분석 → 설계 골격 | LLM |
| [**S2**](/ko/built/tc-team/s2/index.md) | 설계 격리 게이트 + 원문 슬라이스 | 코드 |
| [**S3**](/ko/built/tc-team/s3/index.md) | 골격 생성 → 문장화 팬아웃 → 병합 | 코드 + LLM |
| [**S4**](/ko/built/tc-team/s4/index.md) | 적대 리뷰 · 판정 · 커버리지 원장 | LLM |
| [**S5**](/ko/built/tc-team/s5/index.md) | 수정 적용 + 게이트 4종 | 코드 (미커버 봉합만 LLM) |
| [**S6**](/ko/built/tc-team/s6/index.md) | 라이브 시트 기록 | 코드 |
| [**S7**](/ko/built/tc-team/s7/index.md) | 완료 처리 · 확신도 · 대시보드 | 코드 |

(2026-09 기준) 착수 알림은 S7이 아니라 S1 시작 때 한 번 나간다. 실행락은 체인이 종료 시점에 스스로 푼다.

S1~S7은 각각 따로 적어 뒀다. 단계마다 값을 치르고 배운 게 하나씩 있어서, 표 한 줄로는 안 담긴다.

S3이 이 구조를 가장 잘 보여준다. **골격을 코드가 먼저 만들고**, 25행씩 잘라 모델에게 문장만 채우게 하고, 돌아온 것을 코드가 다시 병합한다. 병합할 때 인덱스·에코·해시·개수를 대조해서, 모델이 행을 밀거나 남의 행을 건드렸으면 **그 청크만 다시 돌린다.** 나머지 청크의 결과는 그대로 살린다.

## 게이트 — 못 넘으면 선다

이게 이 도구의 성격을 정한다. **"최선을 다해 계속"하지 않는다.**

| 게이트 | 단계 | 걸리면 |
|---|---|---|
| 입력 자가검증 | S0 | 재수집 1회 → 또 실패면 **시작 금지** |
| design_gate | S2 | 설계 결함 → **정지**, 사람이 설계를 고친 뒤 재개 |
| merge 대조 | S3 | 어긋난 청크만 재실행 |
| content_gate | S3 · S5 | 추상 표현·근거 없는 위임 — S3에서 최대 3라운드 자동 교정, 안 줄면 정지 · S5에서는 곧바로 정지 |
| apply before-불일치 | S5 | **거부가 정상 동작** — 적용 실패로 정지(계획을 자동으로 다시 만들지는 않는다) |
| dup_gate | S5 | 재현 스텝(F열) 완전 동일 케이스 잔존 시 정지 |
| traceability | S5 | 규칙 미커버 → LLM 봉합 1라운드 → 그래도 남으면 정지 |

(2026-09 기준, 무인 체인) 처음 쓸 때는 설계 결함이면 S1로 되돌리는 루프였지만, 그 왕복은 이제 사람이 단계를 손으로 모는 폴백 절차에만 남아 있다.

`apply before-불일치`가 특히 중요하다. 수정을 적용하기 전에 **"내가 고치려는 그 자리가 아직 내가 본 그 내용인가"** 를 확인하고, 다르면 거부한다. 사람이 중간에 시트를 만졌거나 앞 단계가 밀렸다는 뜻이라, 이때 밀어붙이면 엉뚱한 행을 덮어쓴다.

사람을 부르는 정지는 한 종류(무결성 위반, exit 14)로 모아뒀고, 그 앞에서 자동 재시도가 먼저 돈다. 그 밖의 종료는 인증 만료(10)·재시도 한도(13)·쿼터(15)·기타 오류(1)다. 그 외에는 무인으로 완주한다.

실제로 얼마나 서는지는 2026-09-24 감사에서 기록을 거슬러 쟀다 — **풀체인 38런 중 13런(34%)이 한 번 이상 멈췄다가 재개됐다.** 같은 감사의 벽시계는 풀런 중앙값 96분, 그중 S1이 64%였다.

## 리뷰는 협력이 아니라 적대다

생성된 케이스를 **렌즈 여럿이 병렬로** 읽는다 — 구조, 품질, 원문 대조. 서로의 결과를 모른다. 알면 수렴하고, 수렴하면 같은 걸 놓친다.

별도의 판정자가 이 지적들을 교차신문해 오탐을 떨어내고, **기계가 적용 가능한 형태의 수정 계획**을 만든다. 살아남은 지적은 코드가 적용한다. 모델에게 "고쳐주세요"라고 부탁하지 않는다.

같은 단계에서 커버리지 원장을 만든다. 기획서에서 뽑아낸 규칙 하나하나가 어느 케이스로 덮였는지를 기록하고, 안 덮인 규칙이 있으면 S5에서 행을 봉합한다.

## 시트는 한 번만 만진다

S6은 라이브 시트에 TC 본문을 **딱 한 번** 쓴다(그 뒤 S7이 같은 탭에 확신도 메모와 패널을 덧붙인다). 그리고 소유 마커로 판단한다.

- 우리가 만든 탭이면 → 통째로 지우고 다시 쓴다 (멱등)
- 남이 쓰던 탭이면 → 침범하지 않고 `_v2`~`_v9` 접미사로 새로 만든다
- 다른 탭은 무조건 불가침

여러 번 돌려도 결과가 같고, 남이 만든 탭은 덮지 않는다. 자동화가 사람 옆에서 돌려면 이 두 개가 먼저다.

⚠ (2026-09-24 감사, 미수리) 소유 마커가 시트가 아니라 **로컬 파일**에 있어서, 같은 폴더에서 다시 돌리면 늘 「우리 탭」으로 판정한다. 그사이 사람이 그 탭에 적어 둔 것이 있으면 같이 지워질 수 있다.

## AI용 판은 시트를 아예 안 만진다

2026-10-09 v4.3.6 에서 `tc-team-ai` 가 들어갔다([릴리스 노트](https://github.com/nobles92ts-ship-it/AI_GAME_QA_TestCase/releases/tag/v4.3.6)). 엔진은 여전히 하나다. 체인을 `run_pipeline_full.sh --no-sheet` 로 부르면 S5 확정본에서 끝나고 S6·S7 은 돌지 않는다. S1 은 `--local` 로 돌아 착수 알림을 건너뛴다. 옵션 없이 부르면 단계 순서가 전과 같다는 것은 `--sheet-id` 대조군을 둔 테스트로 묶어 뒀다. 설치할 때 `--mode human|ai|both` 로 고르고, 기본값 `human` 은 전과 똑같은 것을 깐다.

S5 뒤에 세 칸이 붙는다.

| 칸 | 주인 | 하는 일 |
|---|---|---|
| 다시 쓰기 | LLM | 25행 청크 · 동시 4개 · 청크당 2회. 재현 스텝 한 줄을 전제·조작·기대·관측으로 |
| 원문 보존 게이트 | 코드 | 숫자(빠짐·더함) · 영문 이름 · 따옴표·기호 문구 · 부정 극성 · 핵심 낱말 비율. 두 번 걸리면 원문대로 |
| 내보내기 | 코드 | 확신도를 시트 없이 같은 계산부로 다시 재고 묶음을 쓴다 |

네 칸은 «그때의 원문»과 함께 저장된다. 확정본을 다시 만들어 문장이 바뀌면 내보내기가 그 네 칸을 버린다. 낡은 도움말을 엉뚱한 케이스에 붙이느니 원문만 내는 쪽을 골랐다.

묶음은 네 파일이다. `INDEX.md`(실행 규칙 · 실행 순서 · 기획 확인 질문 · 제외 규칙), `cases/NN_<화면>.md`(케이스 블록 — 원문, 네 칸, 판정 표시, 근거 규칙 최대 3개, 확신도. 기본기능 스모크가 맨 앞), `spec.md`(기획서 원문, 절 단위), `results.md`(AI 가 채울 결과표 — 다시 내보내도 안 지운다).

판정 값은 PASS·FAIL·BLOCKED·N/A 넷이고, 증거 칸이 빈 PASS·FAIL 은 규칙 위반이다. 기획이 안 정한 동작은 `BLOCKED(기획)` 으로 적고 FAIL 은 금지다. 치트·계정·로그 같은 실행 환경은 묶음 밖에 둔다 — 프로젝트가 `QA_ENV.md` 같은 문서로 따로 주고, 없으면 그 케이스는 `BLOCKED(환경)` 이다. tc-team 이 아는 것은 «무엇을 확인하나»까지다. «그 상태를 어떻게 만드나»는 게임마다 다르다.

실런 1회(2026-10-08, 사내 기획서 1건) — TC 106 · 화면 그룹 15 · 판정 보류 15 · 네 칸 통과 106 · 원문대로 0. 벽시계 98분 가운데 S1 이 81분, 다시 쓰기가 386초였다. 첫 시도에서 튕긴 8건은 전부 `조작` 칸이 비어 있었고, 두 번째 시도에서 채워졌다.

**근거 규칙은 문장으로 잇는다. 그런데 같은 문장이 둘일 수 있다.** S4 커버리지 원장은 S5 가 행을 넣고 빼고 다시 매기기 «전» 번호로 적혀 있다. 그래서 원장 행의 문장(S4 가 고쳤으면 고친 문장, 아니면 원래 문장)으로 확정본 행을 찾는다. 문제는 dup 게이트가 QA 본문과 기본기능을 따로 본다는 것이다 — 같은 문장이 두 범위에 함께 남는 건 설계상 허용이다. 사내 런 65개 중 29개에 그런 쌍이 91개 있었다. 문장만으로는 이 연결이 하나로 갈리지 않는다.

지금은 원장 행이 속한 범위(기본기능 / QA)의 행을 먼저 고르고, 그래도 하나가 아니면 싣지 않고 `rule_links_unmapped` 로 센다. S4 원장이 남은 런 22개의 연결 5,568개에 대 보면 문장만으로는 5,511개, 범위를 먼저 보면 5,547개가 이어진다. 둘 다 이은 연결 가운데 서로 다른 행을 고른 것은 0개다. 남은 21개는 확정본에 그 문장이 아예 없는 연결이다.

**「하나도 못 읽음」과 「전부 걸러짐」은 산출물이 같다.** 실행기가 아예 안 돌면 모든 케이스가 원문대로 나가고, 묶음은 정상 완료처럼 보인다. 그래서 읽힌 결과가 0개면 종료코드 12 로 멈추고, 결과 파일이 없는지(실행기·모델 이름·네트워크) 있는데 JSON 이 아닌지(형식)를 갈라 적는다. 리뷰 때 JSON 을 코드펜스로 감싸 내는 가짜 실행기로 재현해 보니, 첫 메시지는 파일이 멀쩡히 있는데도 네트워크를 보라고 했다.

못 한 것.

- **AI 가 묶음으로 실제 QA 를 돌린 결과는 0건이다.** `results.md` 는 빈칸이다. 검증한 것은 만드는 쪽뿐이다.
- **게이트에 사각이 둘 남았다.** 긍정이 부정으로 뒤집히는 것과 숫자 없는 조건이 더해지는 것은 정상 바꿔 말하기와 구분이 안 된다(게이트 머리말에 적혀 있다). 기대 어디에든 부정어가 하나 있으면 부정을 지킨 것으로 보는 느슨함도 남았고, 붙여 쓴 「안되는지」는 부정으로 못 읽는다.
- **셋째 사각이던 짧은 부정은 v4.3.7(2026-10-12)에서 고쳤다.** 부정 극성을 문장 끝 「~않는지」「~없는지」로만 잡아서, 「안 되는지」가 빠져도 통과하던 것이다. 고치다가 같은 뿌리의 구멍이 하나 더 나왔다. 기대에 부정이 남았는지 볼 때 「안 」을 글자 조각으로 찾아서 「30일 동안 삭제된다」의 「동안 」까지 남은 부정으로 쳤다. 사내 확정본의 부정 문장 2,738줄 중 43줄이 이 꼴이라 같이 막았다. 앞서 이 자리에 적은 「33줄」은 틀린 수였다 — 그 정규식이 센 것은 「동안 재생되는지」 같은 긍정이었고, 짧은 부정 자체는 13,366줄에 0줄이다.
- **핵심 낱말 문턱 0.6 은 잰 값이 아니다.** 실런 1회에서 내용 사유로 걸린 케이스가 0건이라, 판단할 분포가 아직 없다.
- **드라이브 업로드는 코드가 아니라 지시로 막는다.** 설계 에이전트에게 건너뛰라고 말할 뿐이라, 완주 보고에서 링크 목록이 비었는지 따로 본다.

## 값을 치르고 배운 것 두 개

**행을 끼워 넣으면 번호가 밀린다.** 커버리지 원장은 케이스 번호로 규칙을 가리키는데, 봉합으로 행을 추가하면 그 번호가 통째로 낡는다. 처음엔 산술로 다시 매기려 했다 — 틀렸다. 지금은 **번호가 아니라 내용으로 잇는다**(분류 + 검증 단계 + 재현 스텝). 위치는 변하고 내용은 안 변한다.

**손으로 몰면 절반이 사람 대기 시간이다.** 한 번은 단계를 하나씩 손으로 돌렸는데, 벽시계로 2시간 23분 걸린 런에서 **기계가 실제로 일한 시간은 1시간 12분**이었다. 나머지는 전부 내가 다음 명령을 치는 걸 기다린 시간이다. 무인 완주를 만든 이유가 이 숫자다.

## 기각된 것들

버전 히스토리는 대체로 **"진척처럼 보였지만 아니었던 것"** 의 목록이다.

어휘 기반 진척도 감지 — 실측 2회로 기각. 임계값 통일 — 기각. 확신도 히트맵은 모델 채점판이 재현에 실패한 뒤, **모델 호출 0회의 순수 결정론 산출**로 끝났다.

기각할 때마다 재개 조건을 같이 적었다. 안 그러면 반년 뒤에 같은 아이디어를 다시 꺼내게 된다.

## 정직한 한계

기획서가 부실하면 결과도 부실하다. 이 도구는 **없는 기획을 지어내지 않는다** — 근거가 없으면 케이스를 만드는 대신 "기획 확인 필요"로 표시하고 넘어간다. 그게 맞다고 보지만, 기획이 얇은 조직에서는 산출량이 기대보다 적게 나온다.