사용 가이드

테스트 만들기

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

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

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

만들어지는 순서

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

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

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

왜 승인을 거치게 했나요

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

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

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

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

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

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

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

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

이미 만든 테스트 손보기

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

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

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

영역으로 묶어 정리하기

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

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

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

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

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

정리하면

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

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