S1 · 설계

기획서를 읽고 «설계 뼈대»를 뽑는 단계입니다. 설계 뼈대란 「무엇을 확인할지, 그걸 어떻게 묶을지」의 목록입니다. 여덟 단계 중 판단이 제일 많이 들어가고 시간도 제일 오래 걸려서 가장 센 AI를 여기서 씁니다 — 다만 이 단계 안에서도 «설계를 짜는 자리»에만 씁니다.

이 단계가 만드는 것 — 문서 두 장

기획서를 바로 표로 바꾸지 않습니다. 중간에 문서를 두 장 거칩니다.

문서	무엇
분석 문서	기획서를 정리하고, 확인해야 할 것 후보를 뽑음
설계 문서	그 후보를 분류와 케이스로 펼침

왜 한 번에 안 하냐면 — 「무엇을 확인해야 하나」와 「그걸 어떻게 나눌까」는 다른 일이기 때문입니다. 섞으면 나누기 좋은 것만 뽑게 됩니다.

제일 중요한 규칙 — 「분류는 정리가 아니라 준비물 계층입니다」

이 단계에서 제일 값나가는 한 줄입니다.

테스트 케이스를 묶을 때 보통 주제별로 묶습니다 — 「강화 관련」 「상점 관련」처럼요. 보기 좋습니다.

그런데 그렇게 묶으면 실제로 테스트할 때 고생합니다.

왜냐면 테스트는 준비물이 필요하기 때문입니다. 강화를 테스트하려면 강화할 아이템과 재료가 있어야 합니다. 그리고 준비물을 갖추는 게 제일 오래 걸립니다.

어떻게 묶나	테스트할 때
주제별	준비물이 뒤죽박죽 → 케이스마다 세팅을 다시
준비물별	한 번 세팅하고 여러 개를 연달아

그래서 이 도구는 분류를 「준비물이 같은 것끼리」로 잡습니다. 보기에는 덜 정돈돼 보이는데, 실제로 돌릴 때 훨씬 빠릅니다.

분류를 정하는 일이 곧 테스트 준비 방식을 정하는 일입니다.

없는 데이터로는 케이스를 안 만듭니다

케이스에 아이템 이름이 실제 이름으로 나와야 합니다. 「어떤 아이템」이 아니라 「강화석(중급)」처럼요.

그 이름은 기획서에 없고 게임 데이터 표에 있습니다.

그래서 설계 직전에 그 표를 훑어 실제 이름 사전을 만들어 AI에게 같이 줍니다.

안 주면 어떻게 되냐면 — AI가 그럴듯한 이름을 지어냅니다. 「강화의 돌」 같은 게 나오는데, 게임에 없는 아이템입니다. 그리고 그건 테스트할 때가 돼서야 드러납니다.

설계에 들어가기 전에 재료를 더 모아 둡니다

설계는 기획서 한 장만 보고 하지 않습니다. 바로 앞 준비 단계(0단계)가 재료를 몇 가지 더 모아 둡니다.

더 모으는 재료	왜
기획서가 링크로 가리키는 문서 — 한 번 건너간 곳까지, 최대 5건(2026년 8월부터)	링크만 따라가 읽으면 답이 나오는 것을 기획자에게 묻고 있었습니다
기획서를 여러 장 받으면 한 파일로 합친 본문(2026년 9월부터)	따로 두면 두 번째 문서가 통째로 빠지고 검문도 그걸 못 잡습니다. 합쳐 보니 두 번째 문서에서만 확인할 거리가 70건 나왔습니다
이 기능과 이어진 다른 시스템 후보(2026년 9월부터)	사내 위키의 «문서끼리 연결된 지도»에서 뽑습니다. 이 기능이 다른 기능과 만나는 자리를 놓치지 않으려고요

선이 하나 있습니다. 링크 문서는 빈칸을 메우는 참고일 뿐이고, 거기에만 나오는 기능을 이번 테스트 범위로 끌어오지 않습니다. 연결 지도가 주는 후보도 맞는 게 열에 일곱쯤이라(실측 약 71%) 자동으로 확정하지 않습니다. 설계가 기획서 본문에서 근거를 확인한 것만 씁니다.

검문소를 둘로 나눈 이유 — 「두 실패는 다릅니다」

설계가 끝나면 검문을 붙입니다. 처음엔 하나만 뒀다가 데었습니다.

빠지는 방식이 두 가지였습니다.

검문소	무엇과 무엇을 대조	잡는 실패
위쪽	기획서 ↔ 분석 후보	누락 — 애초에 후보로도 안 올라옴
아래쪽	분석 후보 ↔ 설계 케이스	압축 — 후보는 있는데 케이스로 안 펴짐

둘의 차이가 중요합니다.

누락은 기획서의 한 문단을 통째로 못 본 것입니다. 압축은 봤고 후보로도 적었는데, 케이스로 펼칠 때 한 줄로 뭉개 버린 것입니다.

아래쪽만 보면 누락이 안 걸리고, 위쪽만 보면 압축이 안 걸립니다. 그리고 겉으로는 둘 다 「케이스가 좀 적네」로만 보입니다.

지금 설계 검수는 모두 열여섯 가지 항목을 봅니다(2026년 9월 기준). 이 두 검문소는 그중 두 항목이고, 경계값(최솟값 바로 아래·최솟값·최댓값·최댓값 바로 위)은 하나라도 빠지면 그 자리에서 불합격입니다.

답이 이미 있는 질문은 기획자에게 보내지 않습니다

설계를 하다 보면 기획서만 봐서는 모르는 게 나옵니다. 「이 값의 최대치는 얼마인가」 같은 것입니다. 그런 건 지어내지 않고 「기획 확인 필요」 질문으로 남깁니다. 나중에 기획자에게 가는 질문 목록입니다.

그런데 그 답이 사내 위키의 다른 문서나 게임 데이터 표(엑셀)에 이미 적혀 있는 경우가 꽤 됩니다. 기획자 입장에서는 「그거 저기 있는데요」가 되는 질문입니다.

그래서 질문을 보내기 전에 한 번 찾아봅니다. 사내 위키를 찾기 쉽게 정리해 둔 색인을 안에서 «두 번째 뇌»라고 불러서, 이 일의 이름은 「뇌 대조」입니다. 찾아본 결과는 네 갈래 중 하나입니다.

결과	무슨 뜻	그 질문은
답 찾음	위키나 데이터 표에서 값까지 확인	케이스에 반영하고 질문에서 뺌
자리만 찾음	어디 있는지는 아는데 값을 못 읽음	「여기 보시면 됩니다」를 붙여 보냄
새로 발견	찾다가 기획서가 빠뜨린 규칙을 봄	케이스 후보로 넣고, 확인 질문도 보냄
그대로	못 찾았거나 확신이 없음	그대로 보냄

게임 데이터 표는 2026년 9월부터 봅니다. 기획서가 수치를 엑셀로 넘겨 두는 경우가 많아서, 위키만 봐서는 답이 엑셀에 있는 질문을 끝내 못 풀었기 때문입니다. 단 그 파일·시트·열이 목록에 올라 있고 실제 칸 값을 읽었을 때만 「답 찾음」으로 칩니다.

원칙은 하나입니다 — 의심스러우면 바꾸지 않습니다. 잘못된 「답 찾음」 한 건이 쓸데없는 질문 열 건보다 나쁩니다.

그래도 정직한 한계가 남습니다. 대조가 지나치게 자신만만하면 질문이 조용히 사라집니다. 틀린 답을 찾았다고 믿고 질문을 빼면, 기획자는 그 질문을 볼 일이 없습니다. 그래서 뺀 질문은 따로 기록해 두고, 한 건이라도 있으면 완료 보고에 「이런 질문을 뺐습니다, 한번 봐 주세요」를 붙입니다.

이 대조는 켜고 끄는 선택 기능입니다. 공개판은 기본이 «끔»입니다 — 받는 사람에게는 그런 색인이 없으니까요.

가장 센 AI는 «설계를 짜는 자리»에만 씁니다

AI 모델에도 등급이 있습니다. 센 모델일수록 깊이 생각하지만 더 느리고 더 비쌉니다.

이 단계 안에도 일이 여럿입니다 — 설계를 짜는 일, 그걸 검사하는 일, 위키와 대조하는 일, 지적받은 걸 고치는 일. 2026년 9월부터 가장 센 모델은 두 자리에만 둡니다.

자리	모델
설계를 짜는 자리	가장 센 모델 · 생각도 최대로
검수가 「분석이 기획서 내용을 빠뜨렸다」고 짚었을 때 고쳐 짜기	가장 센 모델
검수 · 위키 대조 · 보통 고치기	한 단계 아래 모델

바꾸기 전에 기능 세 건으로 옛 모델과 새 모델을 겨뤄 봤습니다. 누가 만든 설계인지 가린 채 채점자 둘(서로 다른 AI 모델)이 따로 매겼는데, 세 건 중 두 건에서 둘 다 새 모델을 골랐습니다. 나머지 한 건은 둘 다 옛 모델을 골랐습니다.

공짜는 아니었습니다. 설계에 드는 시간이 38% 늘고 써 내는 글의 양이 49% 늘었습니다. 한 번에 쓸 수 있는 길이 상한에 걸려 답이 중간에 잘린 적도 네 번 중 두 번 있었습니다 — 둘 다 다음 요청에서 스스로 이어 써 끝냈습니다. 문제가 생기면 설정 한 줄로 옛 모델로 돌아갈 수 있습니다.

이 단계가 전체 시간의 3분의 2를 씁니다

처음부터 끝까지 한 번 도는 데 드는 시간은 중간값(여러 번 잰 것을 줄 세웠을 때 한가운데 값)으로 96분입니다. 그중 64%가 이 단계입니다.

양으로 봐도 같습니다. AI를 불러 쓴 한 번 한 번 가운데 가장 비싼 것이 이 단계의 설계자입니다 — 한 번 도는 동안 AI가 써 낸 양의 40%가 설계자 한 명 몫입니다.

그리고 느려지고 있습니다. 2026년 8월 말(27일) 이후 이 단계의 중간값이 41분에서 67분으로 늘었습니다. 분석과 설계를 두 번으로 나눠 부르자는 안이 검토 목록에 올라 있을 뿐, 아직 못 고친 자리입니다.

「설계가 그대로면 건너뛴다」는 약속은 문서에만 있었습니다

뒤 단계에서 막혀 다시 돌려야 할 때가 있습니다. 그때 설계를 또 시키면 제일 비싼 한 시간이 다시 나갑니다.

그래서 계획은 이랬습니다 — 설계 내용을 지문처럼 찍어 두고, 지문이 같으면 이 단계를 통째로 건너뛴다. 운용 문서에도 그렇게 적혀 있습니다. 되돌아가는 게 싸야 막혔을 때 억지로 밀고 가는 대신 되돌아갈 수 있기 때문입니다.

그런데 점검에서 코드를 열어 보니 지문을 비교하는 곳이 없었습니다.

문서가 말한 것	코드가 하는 것
지문이 같으면 알아서 건너뜀	지문을 계산해 기록에 찍기만 함 · 건너뛰려면 사람이 「2단계부터」를 지정

문서만 믿고 다시 돌리면 설계를 한 번 더 합니다. 문서의 약속과 코드는 따로 갈 수 있고, 갈라져도 둘 다 조용합니다 — 이게 여기서 값을 치르고 배운 것입니다. 이 약속은 아직 코드로 옮기지 못했습니다.

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

기획서 원문을 읽어 분석 문서와 설계 문서 두 장을 만든다. 앞의 것은 원문을 정리하고 테스트 후보를 뽑는 문서고, 뒤의 것은 그 후보를 분류 트리와 케이스로 전개한 문서다.

이 파이프라인에서 판단이 가장 많이 들어가는 자리고, 그래서 상위 모델을 쓴다. 단 2026-09-24 부터는 이 단계 안에서도 설계자(STEP 1)와 분석 공백 때의 설계 수정(STEP 3)만 claude-opus-5-5·effort max 이고, 검수·대조·일반 설계 수정은 claude-sonnet-5 다(오너 결정). 되돌리기는 환경변수 한 줄(TCTEAM_OPUS_MODEL)이다.

분류는 정리가 아니라 셋업 계층이다

이게 이 단계에서 제일 중요한 규칙이다.

분류는 단순 기능 그룹핑이 아니라, 자동화 테스트의 사전조건 계층이다. 각 분류는 재현 스텝 실행 직전까지의 셋업 단계를 표현한다.

사람이 읽기 좋게 묶는 게 아니라, 자동화 코드가 그 계층에 그대로 매핑된다. 대분류는 어떤 화면·모드에 들어가 있어야 하는지, 중분류는 그 안에서 무엇이 준비돼 있어야 하는지를 뜻한다.

그래서 분류를 기능 이름으로 나누면 자동화가 매 케이스마다 처음부터 셋업한다. 같은 준비 상태를 공유하는 것들이 다른 분류에 흩어져 있으면, 묶어서 한 번만 만들 수가 없기 때문이다.

분류 이름에 동작·조건·결과를 쓰지 않는 것도 같은 이유다. 소분류 이름은 거기 도달한 상태를 가리켜야 하고, 무슨 동작을 하는지는 케이스가 말한다.

없는 데이터로는 케이스를 만들지 않는다

재현 스텝에 아이템이 실명으로 나와야 하는데, 그 이름은 게임 데이터 테이블에 있다. 그래서 설계 직전에 테이블을 훑어 실명 사전을 뽑아 설계기에 먹인다.

하필 여기인 이유는 문장이 여기서 태어나기 때문이다. 설계 문서에서 만들어진 표현이 문장화·리뷰·시트까지 그대로 흘러간다. 하류에서 고치면 이미 세 군데에 퍼진 뒤다.

규칙 세 개가 붙어 있다.

• 예시는 사전에서만 고른다. 기억이나 추측으로 아이템 이름을 쓰지 않는다. 그럴듯한 가짜 이름이 케이스에 박히면 실행하는 사람이 그걸 찾다가 시간을 버린다.
• 이름만으로 특정이 안 되면 식별자를 병기한다. 같은 이름이 여럿이면 이름은 정보가 아니다.
• 데이터에 없는 조합을 전제한 케이스는 지우지 않고 질의로 돌린다. 없는 게 기획 누락일 수도 있어서다. 지우면 그 질문이 사라진다.

값이 비어 있는 데이터의 동작도 후보에서 뺀다. 아직 안 채운 것과 비우기로 한 것은 다르고, 전자를 케이스로 만들면 데이터를 채우는 순간 그 케이스가 통째로 무의미해진다.

누락과 압축은 다른 실패다

설계가 끝나면 검수를 붙이는데, 게이트를 둘로 나눠 뒀다. 한동안 하나만 두다가 데었다. (2026-09 기준 검수 항목은 C-01~C-16 이고, 아래 상류가 C-13, 하류가 C-12 다.)

게이트	무엇을 대조하나	잡는 실패
상류	기획서 → 분석 후보	누락 — 애초에 후보로 안 잡힘
하류	분석 후보 → 설계 케이스	압축 — 후보는 있는데 케이스로 안 펴짐

하나만 두면 어떻게 되냐면, 하류만 보면 상류 누락이 통과한다. 분석이 놓친 항목은 설계에도 없으니 “설계가 분석을 잘 전개했다”로 PASS가 나온다. 100% 전개율이 100% 커버리지가 아닌 것이다.

그리고 하류 게이트는 비율만 적고 끝내면 안 된다. 후보 하나하나에 대해 어디로 갔는지 표로 적는다 — 전개됨 / 침묵 누락 / 정당한 제외. 제외는 사유를 안 쓰면 누락으로 친다.

경계값은 예외 없이 100%다. 최소-1, 최소, 최대, 최대+1 중 하나라도 개별 케이스로 안 갈라져 있으면 그 자리에서 실패다. N 이하 / N 초과 같은 통합 표기를 발견하면 즉시 되돌린다.

되돌아오는 비용이 0이어야 한다

설계 해시가 같으면 이 단계를 통째로 건너뛴다 — 가 설계 의도였고, 운용 문서에도 그렇게 적혀 있다. 뒤에서 막혀 되돌아왔을 때 설계를 다시 시키지 않기 위해서다. 그런데 체인 코드에는 그 비교가 없다(2026-09 기준). 해시는 설계 게이트(lib/design_gate.js)가 계산해 로그에 찍기만 하고, 건너뛰려면 사람이 --start-from s2 로 재개 지점을 준다. 해시가 실제로 일하는 곳은 반대 방향이다 — 설계가 바뀌었는데 옛 골격으로 진행하려 하면 골격 변환기가 막는다.

이게 없으면 다음 게이트에 한 번 걸릴 때마다 제일 비싼 단계를 다시 돌게 된다. 되돌아오는 걸 전제로 만든 파이프라인이면 되돌아오는 값이 싸야 한다.