S3 · 문장화

표의 «뼈대»는 코드가 만들고, 각 칸의 «문장»만 AI가 씁니다. 그리고 그 문장에는 금지 규칙이 여럿 붙어 있습니다.

다 쓴 문장은 코드가 한 번 더 검문하고, 걸린 줄만 AI에게 다시 쓰게 합니다.

일하는 순서

1. 코드가 행 뼈대를 만듦 — 몇 행, 번호, 어느 열에 뭐가 들어갈지
2. 25행씩 잘라서 AI 네 명에게 동시에 나눠 줌 — 문장만 채우게
3. 코드가 다시 합침
4. 코드가 문장을 검문함 — 걸린 줄만 AI가 고쳐 씀

왜 갈랐나

앞에서 말한 것과 같은 이유입니다. 행 개수·번호·열 배치·분류 경계는 전부 코드가 정합니다.

AI는 각 행의 문장만 씁니다.

이렇게 하면 AI가 몇 명이 나눠 써도 결과가 한 벌처럼 나옵니다. 뼈대가 이미 정해져 있으니까요.

25행씩 잘라 네 명이 동시에 씁니다

한 번에 다 시키면 뒤로 갈수록 품질이 떨어집니다. 앞에서 쓴 규칙을 잊어버립니다.

잘라서 주면 각자 25행만 보니까 끝까지 같은 품질이 나옵니다. 그리고 묶음끼리는 서로를 몰라도 되니까 동시에 쓸 수 있습니다. 2026년 8월부터는 네 명이 한 번에 씁니다. 넷이 다 끝나면 다음 넷이 들어갑니다.

	한 명씩 차례로	네 명이 동시에
묶음 하나 쓰는 데	평균 135.5초	평균 131.3초
케이스 300개 전체	약 41분 (추정)	약 13분 (추정)

넷이 한꺼번에 써도 묶음 하나가 느려지지 않았습니다. 유난히 튀던 묶음 하나는 빼고 잰 값입니다. 300개 줄은 잰 시간을 300개 기준으로 환산한 추정치입니다.

다섯 명 이상은 아직 재 본 적이 없습니다. 그래서 넷에 멈춰 있습니다. AI를 한꺼번에 너무 많이 부르면 서비스 쪽 호출 한도에 한꺼번에 걸릴 수 있어서, 재 보기 전에는 올리지 않습니다.

금지 규칙 하나 — 「또는」이 들어가면 케이스가 하나가 아닙니다

제일 자주 걸리는 규칙입니다.

나쁜 예: 「재료가 부족하거나 레벨이 모자라면 강화가 실패한다」

이게 왜 나쁘냐면 — 확인할 것이 둘인데 한 줄에 들어 있습니다.

실제로 테스트하면 이런 일이 생깁니다.

상황	이 케이스는
재료 부족으로 실패 확인	통과로 표시
레벨 미달은 안 해 봄	그런데 통과로 남아 있음

절반만 확인하고 전부 확인한 것처럼 기록됩니다. 그리고 나중에 레벨 미달 쪽이 깨져도 이 케이스는 통과라고 말합니다.

그래서 「또는」이 나오면 케이스를 쪼갭니다.

금지 규칙 둘 — 「사람이 읽는 문장이어야 합니다」

데이터 표 이름·내부 변수 이름·개발용 코드를 문장의 주어나 서술어로 쓰지 못합니다.

나쁜 예: 「ITEM_ENHANCE_FAIL_TYPE_2가 반환된다」

왜 나쁘냐면 — 이 케이스를 실행하는 사람이 그게 뭔지 모릅니다. 개발자에게 물어봐야 합니다. 그러면 테스트가 안 돌아갑니다.

좋은 예: 「강화에 실패하고 아이템이 그대로 남는다」

확인은 화면에서 하는 것이고, 화면에는 내부 이름이 안 나옵니다.

금지 규칙 셋 — 「비고 칸은 메모장이 아닙니다」

비고 칸에 쓸 수 있는 값이 다섯 개로 정해져 있습니다.

쓸 수 있는 값
(빈 값)
추후 구현
구현 우선순위 낮음
기획 확인 필요
확인된 기획서 오류 메모

자유롭게 쓰게 두면 어떻게 되냐면 — 사람마다 다르게 적고, 나중에 «세어 볼 수가 없습니다».

「기획 확인 필요가 몇 건이지?」에 답하려면 값이 정해져 있어야 합니다. 「확인 필요」 「기획 문의」 「PM 확인」이 섞여 있으면 셀 수가 없습니다.

나중에 세어 볼 것은 처음부터 골라 쓰게 만들어야 합니다.

값 두 개가 다 맞아 보일 때의 순서도 정해져 있습니다. 아직 만들지 않은 기능이면, 결과가 어떻게 나와야 하는지 기획서에 없어도 「기획 확인 필요」가 아니라 「추후 구현」을 씁니다.

만들기 전에는 물어봐도 답이 「만들면 정해진다」뿐이고, 테스트하는 사람에게는 확인할 화면조차 없기 때문입니다. 2026년 8월 한 작업에서는 「기획 확인 필요」 104건 중 74건이 이렇게 아직 안 만든 기능이었습니다. 질문만 쌓이고 답은 올 수 없는 줄이었습니다.

다 쓴 문장은 검문을 받고, 걸린 줄만 다시 씁니다

위의 금지 규칙은 말로만 적어 둔 게 아닙니다. 문장을 다 합치면 코드가 검문합니다. 표현 검문이라고 부르는데, 이런 것을 찾습니다.

• 「제대로」 「문제없이」처럼 사람마다 판정이 갈릴 수 있는 말
• 비고 칸에 들어간 정해진 다섯 값이 아닌 말
• 만드는 도중에 붙인 내부 표시가 문장에 새어 나온 것
• 시트가 수식으로 잘못 읽을 기호(= + @ 등)로 시작하는 칸

걸리면 AI에게 「이 줄이 이 규칙에 걸렸다」는 목록을 주고 그 줄만 고쳐 쓰게 합니다. 그리고 다시 검문합니다. 이걸 최대 세 번까지 합니다. 합치는 순간에도 문장 칸을 먼저 한 번 보고, 거기서 걸린 것은 두 번까지 고칩니다.

그런데 고쳐 썼는데도 걸린 줄 수가 안 줄면, 세 번을 채우지 않고 바로 멈추고 사람을 부릅니다. 안 줄어든다는 건 AI가 서툴러서라기보다 규칙 두 개가 서로 부딪히고 있다는 신호로 봅니다. 그건 몇 번을 더 돌려도 안 풀립니다.

고칠 목록을 절반만 주면, 나머지는 영원히 안 고쳐집니다

이 검문이 처음부터 세 번이었던 건 아닙니다. 2026년 8월 25일 전에는 고쳐 쓰기가 딱 한 번이었고, 한 번 고친 뒤에도 하나라도 남으면 바로 멈췄습니다.

게다가 AI에게 넘기는 위반 목록이 앞의 30건에서 잘려 있었습니다. 그날 이런 일이 났습니다.

무엇	몇 줄
검문에 걸린 줄	49
AI에게 실제로 전달된 줄	30
고칠 기회조차 없던 줄	19 — 그래서 작업이 멈춤

그러니까 위반이 30건을 넘는 작업은 처음부터 무조건 멈추게 되어 있었습니다. AI가 못 고친 게 아니라 고칠 줄을 받지 못한 것입니다.

그래서 두 가지를 바꿨습니다. 목록을 자르지 않고 전부 넘기고, 고쳐 쓰기를 여러 번으로 늘렸습니다. 대신 위의 「안 줄면 멈추는 장치」를 같이 달았습니다. 횟수만 늘리면 안 풀리는 문제에 시간만 씁니다.

고치라고 시킬 때는, 무엇을 고칠지 전부 줘야 합니다.

특정 도구가 없어도 이제는 돕니다

이 페이지는 원래 이렇게 적고 있었습니다 — 「이 단계는 여럿을 동시에 부리는 특정 도구가 있어야만 돈다. 대체 경로가 없다. 그래서 도구가 없으면 그냥 멈춘다.」

지금은 틀린 말입니다. 표준 경로는 그 도구를 쓰지 않습니다. 대신 명령줄에서 AI를 짧게 한 번씩 부르는 방법(claude -p)으로 묶음마다 AI를 따로 부르고, 돌아온 결과는 코드가 검사합니다. 위의 「네 명이 동시에」도 이 방법입니다.

그 도구는 지금 사람이 한 단계씩 손으로 몰 때만 씁니다. 도구가 없으면 그 손 경로만 막히고, 그때는 손으로 몰지 말고 표준 경로로 돌리면 됩니다. 도구의 설명서도 2026년 9월에 옛 문장을 지웠습니다. AI가 받는 규칙은 그 도구용 파일에서 그대로 뽑아 쓰기 때문에, 어느 길로 돌아도 AI는 같은 규칙을 받습니다.

값을 치른 것도 있습니다. 비슷한 옛 문장 하나(「사람 없이 끝까지 도는 건 아직 계획 단계」) 때문에, 2026년 7월에는 혼자 돌 수 있던 작업 하나를 사람이 처음부터 끝까지 손으로 몰았습니다. 2시간 23분이 걸렸습니다. 이 페이지도 옛 문장을 그대로 옮겨 적고 있었습니다.

「안 된다」고 적은 문장은, 사실이 바뀌어도 저절로 지워지지 않습니다.

그래도 원래 원칙 하나는 그대로입니다 — 다르게 해 놓고 같다고 말하지 않는다. 위의 검문에서 줄 수가 안 줄면 멈추는 것도 같은 원칙입니다.

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

설계 문서에서 행 골격을 결정론으로 만들고, 25행씩 잘라 병렬로 문장을 채운 뒤, 다시 결정론으로 병합한다.

구조와 문장을 갈라 놓은 이유

행 개수, 번호, 열 배치, 그룹 경계는 전부 코드가 정한다. LLM은 각 행의 문장만 쓴다.

이렇게 나누면 LLM이 행을 하나 잃거나 순서를 밀어도 병합에서 잡힌다. 병합기가 인덱스·원문 에코·해시·개수를 전부 대조하기 때문이다. 문장을 검사하는 게 아니라 문장이 제자리에 있는지를 검사한다.

청크는 서로를 모른다. 그래서 한 청크가 어긋나면 그 청크만 다시 돌린다. 나머지 결과는 그대로 유효하다. 무인 완주를 가능하게 한 게 이 성질이다 — 200행짜리 런에서 한 청크가 흔들렸다고 전체를 다시 돌려야 한다면, 사람이 안 보는 실행은 성립하지 않는다.

청크가 서로를 모른다는 성질은 속도에도 쓰인다. 2026-08-19 부터 풀체인은 청크를 동시 4개 웨이브로 띄운다 — 넷을 띄우고 넷이 다 끝나야 다음 넷이 뜬다. 무제한으로 띄우지 않는 이유는 순간 호출 한도 폭주다. 실측 표본은 동시 1~4 뿐이다. 측정 문서는 처음에 3을 권했는데, 그 근거였던 「동시 4에서 지연 +13.2%」는 13행짜리 이상치 청크 하나(213초) 탓이었다. 그 하나를 빼면 동시 4의 청크 평균은 131.3초로 순차 기준선 135.5초보다 짧다. 300TC 환산으로 순차 40분 46초가 동시 4에서 13분 08초가 된다 [estimated]. 설정 상한은 8인데 권장치가 아니라 「재 보려면 여기까지」의 경계이고, 5 이상은 재기 전에는 올리지 않는다.

“또는”이 들어가면 케이스가 하나가 아니다

기대 결과에 붙은 금지 규칙 중 제일 자주 걸리는 것이다.

한 케이스 = 사전조건 하나 + 과정 하나 + 기대 결과 하나. “또는”이 들어가는 순간 그건 케이스 하나가 아니다.

• 결과 분기 — “로딩 화면 또는 오류 안내가 표시”
• 사전조건 분기 — “미획득 또는 1개 보유 상태에서”
• 과정 분기 — “탭을 고르거나 재료를 등록했을 때”

처리는 둘 중 하나다. 기획서로 어느 쪽인지 정할 수 있으면 두 케이스로 쪼갠다. 못 정하면 쪼개지 말고 “기획 확인 필요”로 남긴다 — 임의로 하나를 고르면 그 판단이 어디에도 안 남는다.

예외는 하나뿐이다. 결과는 하나인데 허용 상태를 나열하는 경우 — “확정 완료와 확정 대기 중 하나로만 존재한다” 같은 것. 이건 결과가 “정합성 유지” 하나고 상태 나열은 그 조건이다. 단, 그 나열이 기획서에 확정돼 있을 때만.

사람이 읽는 문장이어야 한다

두 번째 금지 규칙. 데이터 테이블명·Enum 타입명·내부 판정 변수를 문장의 주어나 술어로 쓰지 않는다.

기능 QA는 테이블 구조를 뜯지 않는다. 식별자가 주어로 나오면 읽는 사람이 무슨 동작인지를 못 알아본다.

값 나열도 한 케이스에 뭉치지 않는다. 0~6 각각은 케이스 하나가 아니라 일곱이거나, 대표값 몇 개다.

그리고 추상 표현을 금지어로 잡아 둔다 — 정상 동작 올바르게 자연스럽게 문제 없이 적절히. 이런 말이 들어간 기대 결과는 누가 실행해도 판정이 안 갈린다는 보장이 없다. 화면 변화·수치 변화·상태 변화 중 하나로 써야 한다.

비고는 메모장이 아니다

세 번째. 비고 열에 쓸 수 있는 값이 다섯 개로 정해져 있다. 빈 값, 추후 구현, 구현 우선순위 낮음, 기획 확인 필요, 그리고 확인된 기획서 버그 노트.

이걸 안 잠가 두면 설계 단계의 태그가 그대로 흘러들어온다 — 경계값 표기, 동시성, 세션 같은 것들. 그건 만든 사람에게만 의미가 있고, 시트를 보는 사람에게는 잡음이다.

그리고 값마다 결과 열이 자동으로 정해진다. 추후 구현이면 결과가 N/A고, 구현 우선순위 낮음이면 미진행이다. 이 둘을 섞으면 통계가 틀어진다 — 빌드에 없는 것과 나중에 할 것은 다르다.

값끼리의 우선순위도 있다(2026-08-07 규칙). 대상이 구현 예정이면 기대값이 기획서에 없어도 기획 확인 필요가 아니라 추후 구현이다. 구현 예정 항목은 보일 수도 안 보일 수도 있는 상태가 정상이라 물어도 답이 없고, 테스터는 검증할 빌드가 없다. 이 규칙이 생긴 런에서는 기획 확인 필요 104건 중 74건이 구현 예정 항목이었다. 단 「사용하지 않기로 해 삭제」 계열은 구현 예정이 아니라 노출되면 안 되는 것이라 지금 검증할 수 있다 — 여기엔 해당하지 않는다.

병합 뒤 검사는 한 번이 아니라 라운드다

병합기는 먼저 재현 스탭 열의 내용 위반을 본다. 걸리면 위반 목록을 교정 에이전트(claude -p 짧은 호출)에 넘겨 그 행의 문장만 다시 쓰게 하고 병합을 다시 돌린다. 최대 2라운드이고, 그래도 남으면 무결성 정지다.

그다음이 표현 검문(content_gate)이다. 추상 표현(올바르게 제대로 문제없이 류), 비고 화이트리스트, 플랫폼 값, 근거 없는 위임 표현(「정책대로」 류 — 비고에 기획 확인 필요가 없으면 차단), 내부 마킹(⚠) 유출, 셀 첫 글자 특수문자(= + @ ' — 시트가 수식이나 리터럴 지시자로 먹어 저장값이 원본과 달라진다)를 본다. 걸리면 같은 교정 에이전트로 라운드를 돈다. 기본 3라운드, 설정으로 5까지 올릴 수 있다.

정체 감지가 붙어 있다. 직전 라운드보다 위반 수가 줄지 않으면 상한을 채우지 않고 즉시 멈춘다 — 규칙끼리 충돌한다는 뜻으로 보고 사람에게 넘긴다. 위반 수를 파싱하지 못하면 정체 감지를 조용히 끄지 않고 경고를 남긴 채 라운드 상한만으로 간다.

2026-08-25 전에는 단발이었다. 교정 1회 뒤 위반이 하나라도 남으면 곧바로 정지했고, 표현 검문은 상세 목록을 30건에서 잘라 넘겼다. 둘이 겹쳐 위반 30건을 넘는 런은 구조적으로 100% 정지했다. 실사고에서 위반 49건 중 30건만 교정기에 전달됐고, 나머지 19건은 교정 기회 없이 남아 런이 죽었다. 절단을 걷어내고 라운드를 넣었다. 교정 힌트에는 따로 바이트 상한(기본 20만 바이트)이 있는데, 넘으면 조용히 자르지 않고 경고를 찍는다 — 잘린 위반은 교정되지 않으니까.

도구가 없으면 진행하는 척하지 않는다

(2026-09 기준 정정) 이 절은 원래 「이 단계와 다음 단계는 멀티에이전트 오케스트레이션 도구가 있어야 돈다. 대체 경로는 없다.」로 시작했다. 대체 경로는 있고, 그쪽이 표준이다. 무인 풀체인은 그 도구를 한 번도 부르지 않는다. 문장화 규칙을 그 도구용 워크플로우 파일에서 런타임에 뽑아(사본 0) run-agent.sh(claude -p) 짧은 호출로 청크를 돌리고, 결과는 결정론 검증이 받는다. 그 도구가 필요한 것은 사람이 단계를 손으로 모는 수동 폴백뿐이다. 설명서의 「Workflow 전용, 동봉 대체 경로 없음」은 2026-09-04 에 낡은 단정으로 폐기됐고, 이 페이지는 그 문장을 옮겨 적고 있었다.

그래서 도구가 없으면 수동 폴백만 막힌다. 그때는 손으로 몰지 말고 표준 경로 한 줄로 간다 — 앞 단계 산출물은 남아 있으니 여기서 다시 들어가면 된다. 같은 부류의 낡은 문장(「완전 무인 드라이버는 로드맵」, 2026-07-31 폐기) 때문에 한 런을 통째로 손으로 몬 적이 있다(벽시계 2시간 23분). 없는 기능을 흉내 내며 계속 가는 것이 제일 나쁘다는 원칙은 그대로다 — 표현 검문이 정체되면 라운드를 남긴 채 멈추는 것이 같은 원칙이다.