2025년 12월 31일·5분
프롬프트로 수용 테스트 만들기: 기능을 시나리오로 바꾸기
각 기능 프롬프트를 5~10개의 명확한 시나리오(해피 패스와 엣지 케이스 포함)로 바꿔 테스트 과잉 없이 수용 테스트를 만드는 방법을 배워보세요.
각 기능 프롬프트를 5~10개의 명확한 시나리오(해피 패스와 엣지 케이스 포함)로 바꿔 테스트 과잉 없이 수용 테스트를 만드는 방법을 배워보세요.
채팅 스타일의 기능 프롬프트는 대화처럼 읽혀 명확해 보입니다. 하지만 몇 문장 안에 선택지, 규칙, 예외를 압축해 넣는 경우가 많습니다. 그 간극은 누군가 기능을 실제로 쓸 때까지 드러나지 않습니다.
대부분의 프롬프트는 조용히 가정에 의존합니다: 누가 이 동작을 할 수 있는가, 무엇이 "성공"으로 간주되는가(저장됨, 전송됨, 게시됨, 결제됨), 데이터가 누락되면 어떻게 되는가, 무언가 실패했을 때 사용자가 무엇을 봐야 하는가. 또한 “충분히 빠른” 또는 “충분히 안전한” 같은 모호한 기준을 숨기기도 합니다.
모호성은 보통 버그와 재작업으로 늦게 드러납니다. 개발자는 프롬프트가 의미한다고 생각한 대로 구현하고, 리뷰어는 겉보기엔 맞아 보인다고 승인하며, 그다음 사용자가 이상한 케이스—중복 제출, 시간대 문제, 부분 데이터, 권한 불일치—에 부딪힙니다. 나중에 고치는 비용이 더 드는 이유는 코드, UI 텍스트, 때로는 데이터 모델까지 건드려야 하기 때문입니다.
품질은 방대한 테스트 수트가 필요한 것이 아닙니다. 정상 사용과 예측 가능한 스트레스 하에서 기능을 신뢰할 수 있다는 뜻입니다. 잘 고른 소수의 시나리오로 수백 개의 테스트 없이도 그 신뢰를 얻을 수 있습니다.
프롬프트로 만든 기능에 대한 실용적 품질 정의:
이것이 프롬프트를 수용 시나리오로 바꾸는 목적입니다: 모호한 요청을 5~10개의 검사로 바꿔 숨겨진 규칙을 초기에 드러내는 것입니다. 모든 것을 테스트하려는 것이 아니라 실제로 일어나는 실패를 잡아내려는 것입니다.
빠른 프롬프트에서 Koder.ai 같은 분위기 기반 도구로 빌드하면 출력은 완전해 보이지만 여전히 엣지 규칙을 건너뛸 수 있습니다. 촘촘한 시나리오 세트는 변경이 아직 저렴할 때 그 규칙들을 명명하게 만듭니다.
수용 테스트 시나리오는 사용자 행동과 그 결과를 짧고 평이한 언어로 설명한 것입니다.
표면에 머무르세요: 사용자가 무엇을 할 수 있고, 제품이 무엇을 보여주거나 변경하는지. 데이터베이스 테이블, API 호출, 백그라운드 잡, 어떤 프레임워크를 쓰는지 같은 내부 세부사항은 피하세요. 그런 세부사항은 이후에 중요해질 수 있지만, 시나리오를 취약하게 만들고 합의하기 어렵게 합니다.
좋은 시나리오는 또한 독립적입니다. 깨끗한 환경에서 내일 쉽게 실행할 수 있어야 하며, 다른 시나리오가 먼저 실행되어야 한다는 것에 의존하면 안 됩니다. 만약 시나리오가 사전 상태에 의존한다면(setup), 예를 들어 “사용자가 이미 활성 구독을 가지고 있다”처럼 명확히 적으세요.
많은 팀이 Given-When-Then을 사용하는데, 이는 시나리오를 전체 사양으로 만들지 않으면서도 명확성을 강제합니다.
시나리오는 보통 하나의 목표, 분명한 시작 상태, 구체적 행동, 그리고 눈에 보이는 결과를 가질 때 “완료”로 간주됩니다. 이 결과는 이진적이어야 합니다: 팀의 누구든 실행 후 “통과” 또는 “실패”를 말할 수 있어야 합니다.
예: “Given(주어짐) 로그인한 사용자가 저장된 결제 수단이 없을 때, When 그들이 Pro를 선택하고 결제를 확인하면, Then 성공 메시지를 보고 계정에 Pro로 표시된다.”
채팅 우선 빌더인 Koder.ai에서 빌드하더라도 같은 규칙을 지키세요: 생성된 앱의 동작(사용자가 경험하는 것)을 테스트하세요, 플랫폼이 코드를 어떻게 생성했는지는 테스트 대상이 아닙니다.
최고의 형식은 사람들이 실제로 쓰고 읽을 형식입니다. 팀의 절반이 긴 서술을 쓰고 나머지가 간결한 불릿을 쓰면, 문구에 대한 논쟁 대신 품질에 관해 공백과 중복이 생깁니다.
기능이 상호작용적이고 상태를 가진다면 Given-When-Then이 잘 맞습니다. 입력-출력 규칙과 유사한 케이스가 많으면 간단한 표가 스캔하기에 더 쉬울 수 있습니다.
팀이 갈라져 있다면 30일 동안 하나의 형식을 선택하고 조정하세요. 리뷰어들이 계속 “성공은 무엇인가?”라고 묻는다면 Given-When-Then으로 가는 신호입니다. 시나리오가 길어지면 표로 바꾸는 편이 낫습니다.
어떤 형식을 택하든 표준화하세요. 같은 헤딩, 같은 시제, 같은 상세 수준을 유지하세요. 또한 포함하지 않을 것을 합의하세요: 픽셀 단위 UI 세부사항, 내부 구현, 데이터베이스 얘기. 시나리오는 사용자가 보는 것과 시스템이 보장하는 것을 설명해야 합니다.
시나리오를 이미 작업이 일어나는 곳에 두고 기능과 가깝게 유지하세요.
일반적인 옵션으로는 제품 코드 옆, 티켓의 "Acceptance scenarios" 섹션, 혹은 기능별 페이지를 둔 공유 문서 공간이 있습니다. Koder.ai를 사용한다면 Planning Mode에 시나리오를 두어 빌드 이력과 스냅샷, 롤백 포인트와 함께 보관할 수 있습니다.
핵심은 검색 가능하게 만들고, 단일 진실의 출처를 유지하며, 개발을 "시작"으로 간주하기 전에 시나리오를 요구하는 것입니다.
프롬프트를 사용자 목표와 명확한 종료선으로 다시 쓰는 것부터 시작하세요. 목표는 한 문장(누가 무엇을 원하는가), 그다음 검증 가능한 2–4개의 성공 기준을 적습니다. 눈에 보이는 결과를 가리킬 수 없다면 아직 테스트가 아닙니다.
다음으로 프롬프트를 입력, 출력, 규칙으로 분해하세요. 입력은 사용자가 제공하거나 선택하는 것들입니다. 출력은 시스템이 보여주거나 저장하거나 보내거나 차단하는 것들입니다. 규칙은 문장 사이에 숨겨진 “~일 때만”, “반드시” 같은 문구들입니다.
그다음 기능이 작동하기 전에 무엇에 의존하는지 확인하세요. 필수 데이터, 사용자 역할, 권한, 통합, 시스템 상태가 여기서 숨겨진 공백을 드러냅니다. 예를 들어 Koder.ai에서 앱을 빌드한다면, 사용자가 로그인되어 있어야 하는지, 프로젝트가 만들어져 있어야 하는지, 요금제나 접근 요건이 있는지 명시하세요.
이제 기능이 작동함을 증명하는 가장 작은 시나리오 집합을 작성하세요: 보통 1–2개의 해피 패스와 4–8개의 엣지 케이스. 각 시나리오는 실패할 수 있는 한 가지 이유에 집중하세요.
선택할 만한 좋은 엣지 케이스 예: 누락되거나 잘못된 입력, 권한 불일치, "이미 제출됨" 같은 상태 충돌, 타임아웃 같은 외부 종속성 문제, 복구 동작(명확한 오류, 안전한 재시도, 부분 저장 없음).
마지막으로 “무엇이 잘못될 수 있는가?”를 빠르게 검토하세요. 조용한 실패, 혼동스러운 메시지, 잘못된 데이터를 만들 수 있는 곳을 찾아보세요.
해피 패스 시나리오는 모든 것이 잘 풀릴 때의 가장 짧고 정상적인 경로입니다. 일부러 단조롭게 유지하면 엣지 케이스를 나중에 더 쉽게 찾아낼 수 있는 신뢰 기준이 됩니다.
기본 사용자와 기본 데이터를 명명하세요. “User” 대신 “이메일 인증한 로그인 사용자” 또는 “청구 편집 권한이 있는 관리자” 같은 실제 역할을 쓰세요. 그다음 한 개의 프로젝트, 리스트의 한 항목, 저장된 결제 수단 하나처럼 가장 작은 샘플 데이터를 정의하세요. 이렇게 하면 시나리오가 구체적이고 숨은 가정을 줄입니다.
성공까지의 가장 짧은 경로를 먼저 쓰세요. 선택적 단계와 대안 흐름을 제거하세요. 예를 들어 “작업 생성(Create a task)” 기능의 해피 패스는 생성 후 필터링, 정렬, 편집을 포함하면 안 됩니다.
간단한 체크 네 가지:
그다음 한 변수만 바꾼 변형을 하나 추가하세요. 나중에 깨지기 쉬운 변수를 선택하세요(예: 제목이 길 때, 사용자가 기존 항목이 없을 때).
예: 프롬프트에 “스냅샷 저장 후 ‘Snapshot created’ 토스트를 추가”라고 되어있다면 해피 패스는: 사용자가 Create Snapshot을 클릭하고 로딩 상태를 본 뒤 “Snapshot created”를 확인하고, 스냅샷이 올바른 타임스탬프와 함께 목록에 나타나는 것입니다. 한 변수 변형은 이름이 비어있을 때 기본 이름 규칙이 명확히 적용되는 경우일 수 있습니다.
엣지 케이스에서 대부분의 버그가 숨어 있고, 거대한 스위트를 만들 필요는 없습니다. 각 기능 프롬프트에서 실제 동작과 실패 모드를 반영하는 소수의 케이스를 선택하세요.
일반 분류:
모든 기능이 모든 분류를 필요로 하진 않습니다. 검색 박스는 입력에 더 신경을 써야 하고, 결제 흐름은 통합과 데이터에 더 신경을 써야 합니다.
위험에 따라 엣지 케이스를 선택하세요: 실패 비용이 큰 경우(금전, 보안, 프라이버시), 발생 빈도가 높은 경우, 깨지기 쉬운 흐름, 과거에 있었던 버그, 나중에 감지하기 어려운 문제 등이 해당합니다.
예: “사용자가 구독 플랜을 변경” 기능에서는 결제 시 세션 만료, Confirm을 더블클릭한 경우, 결제 제공자 타임아웃으로 플랜이 변경되지 않은 채 혼란스러운 메시지를 보는 경우 같은 시나리오가 자주 유용합니다.
예시 기능 프롬프트(평이한 언어):
"문제가 생기면 앱을 이전 스냅샷으로 롤백해서 마지막으로 동작하던 버전을 다시 라이브로 만들고 싶다."
아래는 간결한 시나리오 세트입니다. 각 시나리오는 짧지만 결과를 분명히 고정합니다.
S1 [필수] 가장 최근 스냅샷으로 롤백
Given 나는 로그인되어 있고 앱의 소유자이다
When "Rollback"을 선택하고 확인하면
Then 앱은 이전 스냅샷을 배포하고 앱 상태는 새로운 버전이 활성화된 것으로 표시된다
S2 [필수] 특정 스냅샷으로 롤백
Given 나는 내 앱의 스냅샷 목록을 보고 있다
When 스냅샷 "A"를 선택하고 롤백을 확인하면
Then 스냅샷 "A"가 활성 버전이 되고 언제 생성되었는지 볼 수 있다
S3 [필수] 허가 없음(인증)
Given 나는 로그인했지만 이 앱에 대한 접근 권한이 없다
When 롤백을 시도하면
Then 접근 오류를 보고 롤백이 시작되지 않는다
S4 [필수] 스냅샷을 찾을 수 없음(검증)
Given 스냅샷 ID가 존재하지 않거나(삭제됨)
When 해당 ID로 롤백을 시도하면
Then 명확한 "스냅샷을 찾을 수 없음" 메시지를 받는다
S5 [필수] 중복 제출(중복)
Given 내가 "Confirm rollback"을 빠르게 두 번 클릭하면
When 두 번째 요청이 전송되면
Then 오직 하나의 롤백만 실행되고 하나의 결과만 표시된다
S6 [필수] 배포 실패(실패)
Given 롤백이 시작되면
When 배포가 실패하면
Then 현재 활성 버전은 계속 라이브로 남아있고 오류가 표시된다
S7 [선호] 타임아웃 또는 연결 끊김
Given 롤백 중 내 연결이 끊기면
When 페이지를 새로고침하면
Then 롤백이 아직 실행 중인지 혹은 완료되었는지 확인할 수 있다
S8 [선호] 이미 해당 스냅샷이 활성화되어 있음
Given 스냅샷 "A"가 이미 활성 상태이면
When 스냅샷 "A"로 롤백을 시도하면
Then 변경된 것이 없고 새로운 배포가 시작되지 않았다는 안내를 받는다
각 시나리오는 세 가지 질문에 답합니다: 누가 하는가, 무엇을 하는가, 그리고 이후에 무엇이 참이어야 하는가.
목표는 "모든 것을 테스트"하는 것이 아니라 사용자에게 해가 되는 위험을 커버하면서 아무도 실행하지 않는 시나리오의 무더기를 만들지 않는 것입니다.
실용적인 기법 하나는 시나리오에 사용할 용도를 라벨링하는 것입니다:
각기 다른 위험마다 한 시나리오만 두세요. 두 시나리오가 같은 이유로 실패한다면 보통 하나면 충분합니다. “잘못된 이메일 형식”과 “이메일 누락”은 다른 위험입니다. 하지만 “1단계에서 이메일 누락”과 “2단계에서 이메일 누락”은 규칙이 동일하다면 같은 위험일 수 있습니다.
또한 여러 시나리오에서 UI 단계를 중복하는 것을 피하세요. 반복되는 부분은 짧게 유지하고 변경되는 것에만 집중하세요. 이는 Koder.ai 같은 채팅 기반 도구로 빌드할 때 더 중요합니다. UI는 바뀔 수 있지만 비즈니스 규칙은 동일할 수 있기 때문입니다.
마지막으로 지금 확인할 것과 나중에 확인할 것을 결정하세요. 일부 검사는 처음엔 수동으로 하고, 기능이 안정되면 자동화하세요:
시나리오는 놀라움을 막기 위한 것이지 팀이 기능을 구현하려는 방법을 설명하는 기술 체크리스트가 되어선 안 됩니다.
가장 흔한 실수는 사용자 목표를 기술적 체크리스트로 바꾸는 것입니다. 시나리오가 "API가 200을 반환한다"거나 "테이블 X에 컬럼 Y가 있다"면 설계를 한 가지로 고정시키는 동시에 사용자가 실제로 얻는 것을 증명하지 못합니다.
또 다른 문제는 여러 목표를 하나의 긴 시나리오에 합치는 것입니다. 실패했을 때 원인을 알기 어렵습니다. 하나의 시나리오는 하나의 질문에 답해야 합니다.
그리고 실제와 맞지 않는 영리한 엣지 케이스를 경계하세요. "사용자에게 1천만 개 프로젝트가 있다"거나 "네트워크가 2초마다 끊긴다" 같은 경우는 실제 환경과 맞지 않고 재현하기도 어렵습니다. 몇 분 안에 설정할 수 있는 엣지 케이스를 선택하세요.
모호한 결과("작동함", "오류 없음", "성공적으로 완료됨")는 피하세요. 그런 표현은 검증해야 할 정확한 결과를 숨깁니다.
Koder.ai의 "소스 코드 내보내기" 기능처럼 만든다면 약한 시나리오는: "유저가 내보내기를 클릭하면 시스템이 레포를 압축하고 200을 반환한다."입니다. 구현을 테스트할 뿐 약속한 결과를 증명하지 못합니다.
더 나은 시나리오는: "스냅샷 두 개가 있는 프로젝트에서 사용자가 내보내기를 하면, 다운로드에는 현재 스냅샷의 코드가 들어 있고 내보내기 로그에는 누가 언제 내보냈는지 기록된다."입니다.
"아니오" 경로도 잊지 마세요: "내보내기 권한이 없는 사용자가 내보내기를 시도하면 옵션이 숨겨지거나 차단되고 내보내기 기록이 생성되지 않아야 한다." 한 줄로 보안과 데이터 무결성을 모두 보호할 수 있습니다.
시나리오 세트를 "완료"로 간주하기 전에 까다로운 사용자와 데이터베이스 관점에서 읽어보세요. 테스트 시작 전에 무엇이 참이어야 하는지, "성공"이 무엇인지 알 수 없다면 준비가 된 것이 아닙니다.
좋은 세트는 작지만 구체적입니다. 작성자와 다른 사람에게 건네도 같은 결과가 나와야 합니다. 다음 항목으로 빠르게 검토하세요:
Koder.ai 같은 채팅 기반 빌더에서 시나리오를 생성할 때에도 같은 기준을 적용하세요: "작동하는 것"처럼 모호한 표현을 허용하지 마세요. 관찰 가능한 출력과 저장된 변경을 요구하고, 검증 가능한 것만 승인하세요.
시나리오 작성을 개발 끝의 정리 작업이 아니라 실제 단계로 만드세요.
구현 전에 시나리오를 작성하면 기능을 저렴하게 변경할 수 있을 때 어색한 질문들—성공의 정의, 잘못된 입력 시 동작, 아직 지원하지 않을 것들—에 답하게 강제합니다.
시나리오를 "완료 기준(definition of done)"으로 사용하세요. Product는 의도를 소유하고 QA는 위험 사고를, 엔지니어링은 실현 가능성을 소유합니다. 세 파트가 동일한 시나리오 세트를 읽고 동의할 수 있으면 ‘완료’라고 보기 어렵게 되는 것을 피할 수 있습니다.
대부분 팀에서 견디는 워크플로:
Koder.ai(koder.ai)에서 빌드하는 경우, 먼저 시나리오를 초안으로 작성하고 Planning Mode를 사용하면 각 시나리오를 화면, 데이터 규칙, 사용자에게 보이는 결과와 연결해 코드 생성이나 편집 전에 매핑하는 데 도움이 됩니다.
위험한 변경의 경우에는 반복하기 전에 스냅샷을 찍으세요. 새로운 엣지 케이스가 작동하던 흐름을 깨면 롤백으로 하루를 꼬이게 풀 필요가 없게 됩니다.
기능 요청 옆(또는 같은 티켓 안)에 시나리오를 두고 버전 관리되는 요구사항처럼 다루세요. 프롬프트가 진화하면 시나리오 세트도 함께 진화하지 않으면 "완료" 상태가 조용히 흐려집니다.
한 문장으로 사용자 목표와 완료 기준을 적는 것부터 시작하세요.
그다음 프롬프트를 다음으로 나누세요:
거기서 1–2개의 해피 패스와 4–8개의 엣지 케이스를 작성하세요. 권한 문제, 중복, 타임아웃, 누락된 데이터 같은 실제 위험과 일치하는 케이스를 선택합니다.
프롬프트가 가정들을 숨기기 때문입니다. 프롬프트는 “저장”이라고만 말할 수 있지만, 그것이 초안으로 저장된 것인지 vs 게시된 것인지, 실패 시 어떻게 되나요, 누가 이 작업을 할 수 있나요 같은 것을 정의하지 않을 수 있습니다.
시나리오는 배포 전에 규칙을 명확히 하도록 강제해서 중복 제출, 권한 불일치, 일관성 없는 결과 같은 버그를 방지합니다.
상태와 사용자 상호작용이 있는 기능에는 Given–When–Then을 사용하세요.
유사한 규칙 검사가 많은 경우에는 간단한 입력/출력 표가 더 편합니다.
한 달 동안 하나의 형식을 사용하고 표준화하세요(시제, 상세 수준을 통일). 팀이 실제로 계속 사용할 수 있는 형식이 최선입니다.
좋은 시나리오는:
누구든 실행해 동일한 결과를 판단할 수 있으면 “완료”입니다.
관찰 가능한 동작에 집중하세요:
구현 세부사항(데이터베이스 테이블, API 응답 코드, 백그라운드 잡, 프레임워크)은 피하세요. 그런 세부사항은 자주 바뀌고 사용자가 원하는 결과를 증명하지 못합니다.
모든 것이 잘 풀리는 가장 평범한 경로를 작성하세요:
그다음 네 가지를 확인하세요: 올바른 화면/상태, 성공 메시지, 데이터 저장 여부, 다음 합리적 행동 가능 여부.
위험과 빈도에 따라 엣지 케이스를 선택하세요:
서로 다른 위험마다 한 시나리오를 목표로 하세요. 모든 변형을 다루려 하지 마세요.
안전하고 명확하게 처리하세요:
실패 시나리오는 시스템이 데이터 손상이나 사용자 오도 없이 동작하지 않음을 증명해야 합니다.
Koder.ai 출력은 다른 앱과 동일하게 다루세요: 사용자가 경험하는 동작을 테스트해야지, 코드가 어떻게 생성되었는지는 테스트 대상이 아닙니다.
실용적인 절차:
작업이 이미 진행되는 곳에 보관하고 단일 진실의 출처(one source of truth) 를 유지하세요:
Koder.ai를 사용하면 Planning Mode에 시나리오를 두어 빌드 이력과 연결해 둘 수 있습니다. 가장 중요한 것은 개발 시작 전에 시나리오를 요구하는 것입니다.