# S1 · 설계

> 기획서에서 설계 골격을 뽑는 단계. 분류를 정하는 일이 곧 자동화 셋업을 정하는 일입니다.

- 수치: LLM
- 사람이 보는 화면: https://aitryed.com/ko/built/tc-team/s1/
- 반대 언어: https://aitryed.com/en/built/tc-team/s1/index.md
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

둘의 차이가 중요합니다.

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

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

지금 설계 검수는 모두 열여섯 가지 항목을 봅니다(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` 로 재개 지점을 준다. 해시가 실제로 일하는 곳은 반대 방향이다 — 설계가 바뀌었는데 옛 골격으로 진행하려 하면 골격 변환기가 막는다.

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