시나리오 목록
42개 시나리오. 각각 전제 → 절차 → 기대 결과로 되어 있어 그대로 검증에 쓸 수 있다.
왜 시나리오인가
기능 설명만으로는 "정상"을 판단할 수 없다. 인스턴스를 중지했을 때 얼마가 빠져야 맞는지, 크레딧이 모자랄 때 무엇이 막혀야 맞는지는 관찰 가능한 결과로 적어야 한다.
여기 있는 시나리오는 세 가지 용도를 겸한다.
| 용도 | 어떻게 쓰나 |
|---|---|
| 학습 | 처음 쓰는 사람이 순서대로 따라 하며 익힌다 |
| 검수 | 배포 후 핵심 경로가 살아 있는지 확인한다 |
| E2E 명세 | 기대 결과를 단언으로 옮기면 자동화 테스트가 된다 |
읽는 법
각 시나리오는 이 형식을 따른다.
### S-xx 제목
역할 · 소요 · 선행
전제 시작 상태
절차 1. ... 2. ...
기대 ✅ 관찰 가능한 결과
관련 해당 가이드 페이지
기대 결과는 화면에서 눈으로 확인할 수 있는 것으로만 적었다. 내부 상태를 확인해야 하는 경우에는 어디를 봐야 하는지 함께 적었다(원장 기록·감사 로그).
전체 목록
A. 온보딩 — 빈 상태에서 팀이 GPU를 쓰기까지
| # | 시나리오 | 역할 |
|---|---|---|
| S-01 | 조직 생성과 초기 크레딧 | Super Admin |
| S-02 | 중복 어드민 이메일로 조직 생성 시도 | Super Admin |
| S-03 | 크레딧 추가 판매 | Super Admin |
| S-04 | 인스턴스 유형 등록 | Super Admin |
| S-05 | 노드 등록과 검증 실패 | Super Admin |
| S-06 | 팀 생성과 예산 할당 | Org Admin |
| S-07 | 미할당 풀을 넘는 예산 시도 | Org Admin |
| S-08 | 팀 코드로 가입 | 사용자 |
B. 즉시 실행 — 지금 바로 GPU 쓰기
| # | 시나리오 | 역할 |
|---|---|---|
| S-09 | 인스턴스 시작에서 중지까지 | 사용자 |
| S-10 | 자동 중지 타이머 조정 | 사용자 |
| S-11 | 보안 그룹 규칙 추가·삭제 | 사용자 |
| S-12 | SSH 키페어로 접속 | 사용자 |
| S-13 | 허용되지 않은 유형 시작 시도 | 사용자 |
| S-14 | 가용 노드 없이 시작 시도 | 사용자 |
C. 서버급 예약 — 승인제 자원
| # | 시나리오 | 역할 |
|---|---|---|
| S-15 | 예약 신청에서 승인까지 | 사용자 → Super Admin |
| S-16 | 동의 없이 신청 시도 | 사용자 |
| S-17 | 잘못된 기간으로 신청 시도 | 사용자 |
| S-18 | 조건 조정 후 수락 | Super Admin → 사용자 |
| S-19 | 조건 조정 후 거절 | Super Admin → 사용자 |
| S-20 | 예약 반려 | Super Admin |
| S-21 | 승인된 예약 취소 시도 | 사용자 |
| S-22 | 크레딧 부족 상태로 승인 시도 | Super Admin |
| S-23 | 노드 추가 요청과 처리 | 사용자 → Super Admin |
D. 서버리스 — GPU 없이 LLM 쓰기
| # | 시나리오 | 역할 |
|---|---|---|
| S-24 | 키 발급에서 첫 호출까지 | Org Admin → 사용자 |
| S-25 | 키 예산 증액·감액 | Org Admin |
| S-26 | 키 폐기와 환원 | Org Admin |
| S-27 | 팀 예산을 넘는 키 발급 시도 | Org Admin |
| S-28 | 예산 소진 후 호출 | 사용자 |
| S-29 | 폐기된 키로 호출 | 사용자 |
| S-30 | 접근 없는 모델 호출 | 사용자 |
E. 한도와 차단 — 막혀야 할 때 막히는가
| # | 시나리오 | 역할 |
|---|---|---|
| S-31 | 크레딧 소진과 팀 잠금 | 사용자 → Org Admin |
| S-32 | 잠긴 팀에서 시작 시도 | 사용자 |
| S-33 | 로그인 5회 실패 잠금 | 사용자 |
| S-34 | 멤버 비활성화 즉시 차단 | Org Admin |
F. 장애와 복구 — 무엇이 죽어도 자원은 새지 않는다
| # | 시나리오 | 역할 |
|---|---|---|
| S-35 | 기동 실패와 보상 | 사용자 |
| S-36 | 고아 자원 수렴 | 운영 |
G. 운영·정리 — 되돌리기와 흔적
| # | 시나리오 | 역할 |
|---|---|---|
| S-37 | 강제 중지 | Org Admin |
| S-38 | 팀 삭제와 예산 반환 | Org Admin |
| S-39 | 노드 등록 해제와 과금 이력 | Super Admin |
| S-40 | 사용량 CSV 내보내기 | 사용자 |
| S-41 | 진행 중 자원이 있는 조직 제거 시도 | Super Admin |
| S-42 | 감사 로그로 추적하기 | Super Admin |
자동화 현황
backend/src/voltra/scripts/smoke.py가 HTTP 레벨에서 아래를 이미 검증한다.
make smoke로 돌린다.
| 스모크 단계 | 커버하는 시나리오 |
|---|---|
| A. 로그인 · 전용 팀 생성 | S-06 · S-08 |
| B. 즉시 실행 → 과금 → 중지 | S-09 |
| C. 서버리스 게이트웨이 | S-24 · S-28 · S-29 · S-30 |
| D. 예약 → 승인(확정 차감) → 취소 불가 | S-15 · S-21 |
| E. 리포트 · 알림 · 감사 | S-40 · S-42 |
| F. 정리 | S-38 |
나머지는 아직 수동이다. 특히 조정안 왕복(S-18·S-19), 자동 반려(S-22), 팀 잠금(S-31~S-32), 장애 복구(S-35·S-36)는 자동화되어 있지 않다.
브라우저 E2E를 붙인다면 여기에 화면 상태를 더하는 층이 된다. 버튼 비활성화, 배지 문구, 경고 문구 노출 같은 것은 HTTP로는 검증되지 않는다.
실행 순서
시나리오 사이에 선행 관계가 있다. 처음부터 검증한다면 이 순서를 권한다.
A(S-01~08) ─┬─▶ B(S-09~14)
├─▶ C(S-15~23)
├─▶ D(S-24~30)
└─▶ E(S-31~34) ─▶ G(S-37~42)
F(S-35~36)는 독립
E를 먼저 돌리면 팀이 잠겨서 B·C·D가 막힌다. 잠금 시나리오는 마지막에 두는 편이 낫다.
값을 확인할 때
기대 결과에 나오는 코드나 숫자가 무엇인지 확인하려면 레퍼런스를 본다.
| 찾는 것 | 어디 |
|---|---|
| 차감액이 왜 그 값인가 | 크레딧 계산 모델 |
| 이 상태에서 뭘 할 수 있나 | 상태 전이 |
| 이 에러 코드가 무슨 뜻인가 | 에러 코드 |
| 이 알림이 왜 왔나 | 알림 종류 |
| 이 용어가 무슨 뜻인가 | 용어집 |