tc-team

기획서를 넣으면 «테스트 케이스»가 표에 채워집니다. 핵심은 「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가 직접 고치지 않고, 코드가 적용할 수 있는 «수정 계획»으로만 적습니다. 실제로 고치는 건 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단계 검문을 건너뛸 수 있습니다. 문서에는 「표시가 없으면 다시 돈다」고 적혀 있었는데, 코드가 그 약속을 지키고 있지 않았습니다.

기각한 것들

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

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

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

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

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

왜 갈랐나

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

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

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

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

여덟 단계

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

(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 가 들어갔다(릴리스 노트). 엔진은 여전히 하나다. 체인을 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회의 순수 결정론 산출로 끝났다.

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

정직한 한계

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