S3 · 문장화

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

비고는 메모장이 아니다

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

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

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

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

이 단계와 다음 단계는 멀티에이전트 오케스트레이션 도구가 있어야 돈다. 대체 경로는 없다.

그래서 도구가 없으면 즉시 멈추고 그 사실을 보고한다. 앞 단계 산출물은 남아 있으니 도구를 갖춘 뒤 여기서 재개하면 된다. 없는 기능을 흉내 내며 계속 가는 것이 제일 나쁘다.