# 테스트 만들기

> 테스트는 내가 승인한 개발 범위 안에서만 만들어져요. 말하기 → 검토안 → 내 승인 → 테스트 제출 → 첫 검증, 다섯 단계로 이어집니다. 만드는 일은 모두 내 AI를 통해 해요.

확인하고 싶은 흐름을 **테스트**(앱에서 일어나는 한 가지 흐름을 단계로 적어 둔 것 · 제품 안에서는 시나리오라고도 불러요)로 만드는 길은 하나예요. **내가 승인한 개발 범위 안에서만** 테스트가 만들어집니다.

한 가지 먼저 알아 두실 점이 있어요. **테스트 만들기는 모두 내 AI를 통해 합니다.** Cursor·Claude Code처럼 평소 쓰는 AI 코딩 도구에 Specnote를 연결해 두고(연결법은 [내 코드와 연결하기](/ko/docs/connect-your-code)) "이거 테스트 만들어 줘"라고 말하면 돼요. 예전에 웹 화면에 있던 "만들기" 버튼(입력 폼)은 없어졌습니다.

## 만들어지는 순서

AI가 혼자 테스트를 만들어 내지는 않아요. 가운데에 **내가 승인하는 자리**가 하나 있고, 그 승인을 거친 것만 테스트가 됩니다.

1. **내가 말해요.** 확인하고 싶은 일을 평소 말투로 AI에게 부탁합니다. "회원가입하면 환영 메일 오는지 확인하고 싶어" 하는 식이죠.
2. **AI가 검토안(PRD)을 정리해 올려요.** 이번에 무엇을 어떤 규칙으로 확인할지를 규칙 하나하나로 적어 Specnote에 제출합니다. 이때 AI는 실제 코드를 근거로 삼기 때문에, 코드에 없는 상상 속 기능이 섞이지 않아요.
3. **내가 화면에서 승인해요.** Specnote 화면에 올라온 검토안을 규칙별로 읽고 승인합니다. **이 승인은 사람만 할 수 있어요** — AI에게 "대신 승인해 줘"라고 시켜도 거부되고, 승인 화면 주소만 돌려줍니다. 일부러 그렇게 막아 두었어요.
4. **AI가 승인된 범위대로 테스트를 제출해요.** 3번에서 내가 승인한 규칙 안에서만 테스트가 만들어집니다. 승인 밖의 것은 만들어지지 않아요.
5. **첫 검증이 자동으로 돌기 시작해요.** 실제 브라우저가 열려 테스트대로 화면을 하나씩 눌러 봅니다.

한 가지 요령이 있어요. **한 번에 하나씩** 부탁하는 겁니다. "가입하고 결제하고 알림까지 다 확인해 줘"처럼 몰아서 말하기보다, 확인하고 싶은 일 하나를 또렷하게 말할수록 정확한 검토안이 나와요.

## 왜 승인을 거치게 했나요

승인 없이도 테스트를 만들 수 있던 길이 예전에는 여럿 있었어요. 코드만 보고 후보를 제안해 확정하는 길, 한 문장을 그대로 테스트로 바꾸는 길, 방금 바꾼 코드로 새 테스트를 만드는 길이 그랬습니다. 그 길들은 지금 전부 닫혔어요.

이유는 하나예요. **내가 확인하겠다고 정하지 않은 것이 검증 대상으로 늘어나면, 늘어난 만큼 크레딧이 나가고 실패도 늘어납니다.** 무엇을 확인할지 내가 먼저 정하고, 정한 만큼만 확인하는 편이 결과를 읽기도 쉬워요.

## 검토안을 더 정확하게 만드는 법

2번에서 AI가 만드는 검토안의 품질은 AI가 가진 근거에 달려 있어요. 근거를 늘리는 방법이 둘 있습니다.

- **코드를 연결해 두기.** 코드가 연결돼 있으면 AI가 실제 코드를 보고 검토안을 씁니다. 연결하는 법은 [내 코드와 연결하기](/ko/docs/connect-your-code)에 정리해 뒀어요.
- **기획 문서를 AI에게 함께 주기.** 이미 적어 둔 기획서나 PRD가 있다면, 검토안을 부탁할 때 그 문서도 같이 넘겨 주세요. AI가 그 내용을 근거로 규칙을 씁니다. 문서 자체가 Specnote에 저장되지는 않아요 — Specnote가 보관하는 것은 워크스페이스의 **한 줄 소개**뿐입니다. 그래서 자주 쓰는 문서라면 AI 도구 쪽에 두고 매번 함께 넘기는 편이 낫습니다.

## 만든 다음 — 통과 조건 승인하기

갓 만들어진 테스트는 아직 **초안**이에요. "무엇을 성공으로 볼지"(통과 조건)를 **사람이 한 번 승인**해야 정식으로 자리 잡습니다. AI는 초안까지 만들지만, 무엇을 합격으로 볼지 정하는 일은 사람 몫이에요.

승인해 둔 테스트는 이후 화면이 조금 바뀌어도 스스로 맞춰 따라가고, 기획과 어긋나면 "다시 승인해 주세요" 하고 알려 줍니다. 그리고 만들어진 테스트는 작업실 보드에서 이름을 바꾸거나 순서를 정리할 수 있어요.

## 이미 만든 테스트 손보기

새로 만드는 것과 달리, **이미 있는 테스트를 손보는 일은 승인을 다시 받지 않아도 돼요.** 확인하기로 이미 정해 둔 것을 다듬는 일이니까요.

- **단계 다시 만들기** — "이 테스트 단계 다시 만들어 줘"라고 하면 Specnote가 실제 화면을 사람처럼 둘러보며 단계를 **직접 측정해서** 채워 줍니다. 화면에 실제로 있는 버튼과 입력칸을 보고 잡기 때문에, 겉핥기가 아니라 실측 기반으로 정리돼요. 단계를 측정하려면 **테스트할 사이트 주소**(테스트 환경의 주소)가 먼저 등록돼 있어야 해요.
- **영향 확인하기** — "이번 변경이 어떤 테스트에 영향 주는지 분석해 줘"라고 하면, 방금 바꾼 파일과 맞닿은 테스트·단계를 짚어 줍니다. 어디를 다시 봐야 할지 알려 주는 것이지 새 테스트를 만들지는 않아요.
- **이름·순서 정리** — 테스트 이름을 바꾸거나 단계 순서를 조정할 수 있어요.

> 단계 다시 만들기처럼 AI가 앱을 직접 둘러보는 작업은 크레딧을 조금 써요. **실제로 둘러본 만큼만** 청구되고, 한 번 크게 훑는 작업이라 다른 작업보다는 조금 더 듭니다. 자세한 건 [크레딧과 요금제](/ko/docs/billing-and-credits)를 봐 주세요.

## 영역으로 묶어 정리하기

테스트가 늘어나면 한눈에 보기 어려워져요. 그래서 비슷한 테스트는 **영역**으로 묶어 정리해요. 예를 들어 "가입과 로그인", "결제", "프로필 수정" 같은 식으로요. 영역은 폴더처럼 생각하면 쉬워요.

영역에는 **관점**도 정할 수 있어요. 누구의 눈으로 보는 흐름인지 나누는 거예요.

| 관점   | 누구의 흐름인가요                |
| ------ | -------------------------------- |
| 전체   | 모든 사용자에게 공통인 흐름      |
| 방문자 | 아직 로그인하지 않은 사람의 흐름 |
| 회원   | 로그인한 사람만 볼 수 있는 흐름  |

관점을 나눠 두면 "로그인 안 한 사람도 결제 화면에 들어가지나 않는지" 같은 걸 또렷하게 검증할 수 있어요.

영역으로 묶어 둔 테스트는 작업실 보드의 **대시보드**에서 영역별로 가지런히 보여요. 영역 이름은 나중에 바꿀 수 있고, 순서도 자주 보는 것부터 위로 올려 정리할 수 있습니다. 테스트가 수십 개로 늘어나도, 영역과 관점만 잘 나눠 두면 "어디에 뭐가 있더라" 하고 헤매지 않아요.

## 정리하면

- 테스트는 **내가 승인한 범위 안에서만** 만들어져요. 승인은 사람만 합니다.
- 만드는 순서는 **말하기 → 검토안 → 내 승인 → 테스트 제출 → 첫 검증** 다섯 단계예요.
- 이미 만든 테스트를 손보는 일은 승인을 다시 받지 않아요.

처음이라면 코드를 연결한 뒤, 확인하고 싶은 일 하나를 한 문장으로 부탁해 보세요. 검토안이 어떻게 올라오는지 한 번 겪어 보면 나머지는 금방 익숙해집니다. 테스트를 다 만들었다면, 이제 실제로 한 번 돌려 보세요 — [검증 돌리고 결과 읽기](/ko/docs/running-and-results)에서 이어집니다.

---

Source: https://specnote.io/ko/docs/creating-scenarios