포스트

구글 안티그래비티 테스트 시나리오 & 케이스 작성 가이드

게시
By BLUEBUG
40 분읽는 시간
구글 안티그래비티 테스트 시나리오 & 케이스 작성 가이드

AI 에이전트가 이해하고 실행할 수 있는 테스트 문서 작성법

핵심 질문: 에이전트가 문서를 읽고 테스트를 실행할 수 있는가?

답: 네, 가능합니다!

구글 안티그래비티의 AI 에이전트는 프로젝트 내의 문서(Markdown, YAML 등)를 읽고 이해할 수 있습니다. 하지만 몇 가지 중요한 원리를 이해해야 합니다:

안티그래비티의 문서 이해 메커니즘

1. 에이전트의 컨텍스트 인식 안티그래비티 에이전트는 프로젝트의 전체 파일 시스템에 접근할 수 있습니다. 특정 파일을 열어보거나, 프로젝트 구조를 분석하거나, 여러 문서를 참조하여 작업할 수 있습니다.

1
2
3
4
5
6
7
8
9
10

프로젝트 구조 예시:
my-project/
  ├── docs/
  │   ├── test-scenarios.md        ← 에이전트가 읽을 수 있음
  │   └── test-cases.md            ← 에이전트가 읽을 수 있음
  ├── .antigravity/
  │   └── workflows/
  │       └── run-tests.yaml       ← 에이전트가 실행할 수 있음
  └── src/
      └── components/

2. 자연어 이해 능력 Gemini 3 Pro, Claude Sonnet 4.5 같은 최신 LLM을 사용하므로, 잘 구조화된 자연어 문서를 정확히 이해할 수 있습니다. 하지만 구조화가 명확할수록 더 정확하게 이해합니다.

3. Artifacts 시스템 에이전트는 작업을 수행하면서 다음 Artifacts를 생성합니다:

  • Task List: 작업 계획
  • Implementation Plan: 구현 계획
  • Walkthrough: 실행 결과 요약
  • Screenshots: UI 상태 캡처
  • Browser Recordings: 테스트 실행 비디오

4. 실행 방법 문서가 있다고 자동으로 실행되지는 않습니다. 다음 중 하나의 방법으로 실행합니다:

1
2
3
4
5
6
7
8

방법 1: 직접 지시
"docs/test-scenarios.md 파일을 읽고 거기 있는 모든 테스트 시나리오를 실행해줘"

방법 2: Workflow 활용
"/run-all-tests" (미리 만들어둔 Workflow 실행)

방법 3: 자동 스케줄링
매일 자동으로 실행되도록 설정

테스트 시나리오 vs 테스트 케이스

정의와 차이점

테스트 시나리오(Test Scenario) 는 테스트할 기능이나 상황을 고수준에서 설명한 것입니다. “무엇을” 테스트할 것인가에 집중합니다.

예시:

1
2

시나리오: 사용자 로그인 기능
목적: 사용자가 유효한 자격 증명으로 시스템에 로그인할 수 있는지 확인

테스트 케이스(Test Case) 는 시나리오를 구체적인 단계와 예상 결과로 세분화한 것입니다. “어떻게” 테스트할 것인가에 집중합니다.

예시:

1
2
3
4
5
6
7
8

케이스 ID: TC-LOGIN-001
전제 조건: 사용자가 로그아웃 상태
단계:
  1. 로그인 페이지로 이동
  2. 이메일 필드에 "test@example.com" 입력
  3. 비밀번호 필드에 "TestPass123!" 입력
  4. "로그인" 버튼 클릭
예상 결과: 대시보드 페이지로 리다이렉트

안티그래비티 관점에서의 활용

테스트 시나리오는 에이전트에게 전체 그림을 제공합니다. 에이전트는 이를 읽고 세부 테스트 케이스를 스스로 생성할 수 있습니다.

테스트 케이스는 명확한 실행 지침을 제공합니다. 에이전트는 이를 정확히 따라 테스트를 수행합니다.

권장 접근법: 두 가지를 모두 작성하되, 시나리오는 사람이 읽기 쉽게, 케이스는 에이전트가 실행하기 쉽게 작성합니다.

에이전트 친화적 테스트 시나리오 작성법

기본 템플릿

에이전트가 쉽게 이해할 수 있는 테스트 시나리오 템플릿입니다:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

# 테스트 시나리오: [기능명]

## 개요
- **시나리오 ID**: TS-[카테고리]-[번호]
- **기능 영역**: [예: 인증, 결제, 검색]
- **우선순위**: [높음/중간/낮음]
- **작성일**: YYYY-MM-DD
- **작성자**: [이름]

## 목적
[이 시나리오로 무엇을 검증하려는가]

## 범위
### 포함사항
- [테스트할 기능 1]
- [테스트할 기능 2]

### 제외사항
- [이 시나리오에서 테스트하지 않을 것]

## 전제 조건
- [필요한 환경 설정]
- [필요한 테스트 데이터]
- [의존하는 서비스나 컴포넌트]

## 테스트 대상
- **환경**: [개발/스테이징/프로덕션]
- **URL**: https://...
- **브라우저**: [Chrome, Firefox, Safari]
- **화면 크기**: [Desktop 1920x1080, Mobile 375x667]

## 주요 테스트 포인트
1. [검증할 핵심 기능 1]
2. [검증할 핵심 기능 2]
3. [검증할 핵심 기능 3]

## 예상 결과
[이 시나리오가 통과했을 때의 상태]

## 위험 및 고려사항
- [알려진 이슈나 제약사항]
- [특별히 주의해야 할 점]

실전 예제: E-commerce 결제 시나리오

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

# 테스트 시나리오: E-commerce 결제 플로우

## 개요
- **시나리오 ID**: TS-PAYMENT-001
- **기능 영역**: 결제 (Payment)
- **우선순위**: 높음
- **작성일**: 2026-01-22
- **작성자**: QA Team

## 목적
사용자가 상품을 선택하고 결제를 완료하는 전체 플로우가 
모든 단계에서 올바르게 작동하는지 검증한다.

## 범위
### 포함사항
- 상품 선택 및 장바구니 추가
- 배송 정보 입력
- 결제 수단 선택
- 주문 확인 및 완료
- 주문 확인 이메일 전송

### 제외사항
- 배송 추적 기능
- 주문 취소 및 환불
- 구독 결제 (별도 시나리오)

## 전제 조건
- 스테이징 환경이 정상 작동 중
- 테스트 사용자 계정 존재: test-user-001@example.com
- 테스트 상품 재고 존재
- 테스트 결제 게이트웨이 설정 완료
- 테스트 결제 카드: 4242-4242-4242-4242

## 테스트 대상
- **환경**: 스테이징
- **URL**: https://staging.example-shop.com
- **브라우저**: Chrome 최신 버전
- **화면 크기**: Desktop 1920x1080

## 주요 테스트 포인트
1. 상품 페이지에서 "장바구니 추가" 기능이 작동하는가
2. 장바구니 페이지에서 수량 조절이 가능한가
3. 결제 페이지에서 배송 정보를 올바르게 입력할 수 있는가
4. 결제 카드 정보가 올바르게 검증되는가
5. 주문 완료 후 주문 번호가 생성되는가
6. 주문 완료 페이지에 올바른 정보가 표시되는가
7. 백엔드 API가 올바른 주문 데이터를 저장하는가

## 예상 결과
- 모든 단계가 에러 없이 완료됨
- 사용자가 주문 완료 페이지를 확인함
- 주문 번호가 생성되고 표시됨
- 백엔드 데이터베이스에 주문 정보가 정확히 저장됨
- (선택적) 주문 확인 이메일이 전송됨

## 위험 및 고려사항
- 결제 게이트웨이의 응답 시간이 느릴 수 있음 (최대 10초 대기)
- 재고 부족 시나리오는 별도 테스트 케이스에서 다룸
- 쿠폰 적용은 별도 시나리오 (TS-PAYMENT-002)

에이전트에게 실행 지시하기

이 문서를 작성한 후, 에이전트에게 다음과 같이 지시합니다:

1
2
3
4
5
6

docs/test-scenarios.md 파일을 읽고 
"TS-PAYMENT-001" 시나리오를 실행해줘.

각 테스트 포인트를 순서대로 검증하고,
각 단계마다 스크린샷을 찍어줘.
문제가 발견되면 즉시 중단하고 상세히 보고해줘.

에이전트는:

  1. 파일을 읽고 시나리오를 이해함
  2. 전제 조건 확인
  3. 각 테스트 포인트를 순차 실행
  4. Artifacts 생성 (스크린샷, 비디오, 리포트)
  5. 최종 결과 보고

에이전트 친화적 테스트 케이스 작성법

기본 템플릿

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# 테스트 케이스: [구체적 기능]

## 케이스 정보
- **케이스 ID**: TC-[카테고리]-[번호]
- **시나리오 ID**: TS-[카테고리]-[번호] (연결된 시나리오)
- **테스트 타입**: [UI/통합/E2E/API]
- **우선순위**: [P0-Critical/P1-High/P2-Medium/P3-Low]
- **자동화 여부**: [자동/수동/반자동]

## 테스트 목적
[이 케이스가 검증하는 구체적인 기능]

## 전제 조건
### 환경
- URL: [정확한 URL]
- 테스트 계정: [이메일/ID]
- 테스트 데이터: [필요한 데이터]

### 시스템 상태
- [필요한 초기 상태]

## 테스트 단계
### 단계 1: [액션]
- **수행**: [정확히 무엇을 할 것인가]
- **입력 데이터**: [사용할 데이터]
- **예상 결과**: [무엇이 나타나야 하는가]
- **검증 방법**: [어떻게 확인할 것인가]

### 단계 2: [액션]
...

## 최종 예상 결과
- [전체 테스트 통과 기준]

## 실패 시 조치
- [실패했을 때 취할 행동]

## 비고
- [추가 정보나 참고사항]

실전 예제: 로그인 성공 케이스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115

# 테스트 케이스: 유효한 계정으로 로그인 성공

## 케이스 정보
- **케이스 ID**: TC-AUTH-001
- **시나리오 ID**: TS-AUTH-001
- **테스트 타입**: UI + 통합
- **우선순위**: P0-Critical
- **자동화 여부**: 자동

## 테스트 목적
등록된 사용자가 올바른 이메일과 비밀번호를 입력했을 때
성공적으로 로그인하고 대시보드로 이동하는지 검증

## 전제 조건
### 환경
- URL: https://staging.example.com/login
- 테스트 계정: test-user-001@example.com
- 비밀번호: TestPass123!

### 시스템 상태
- 사용자가 로그아웃 상태
- 브라우저 쿠키 및 캐시 삭제됨
- 네트워크 연결 정상

## 테스트 단계

### 단계 1: 로그인 페이지 접속
- **수행**: 브라우저에서 로그인 페이지로 이동
- **입력 데이터**: https://staging.example.com/login
- **예상 결과**: 
  - 로그인 폼이 표시됨
  - 이메일 입력 필드 존재
  - 비밀번호 입력 필드 존재
  - "로그인" 버튼 존재
- **검증 방법**: 
  - URL이 /login인지 확인
  - 페이지 제목이 "로그인"인지 확인
  - 모든 폼 요소가 활성화 상태인지 확인

### 단계 2: 이메일 입력
- **수행**: 이메일 필드를 클릭하고 테스트 이메일 입력
- **입력 데이터**: test-user-001@example.com
- **예상 결과**: 
  - 입력한 이메일이 필드에 표시됨
  - 유효성 검증 에러가 없음
- **검증 방법**: 
  - 이메일 필드의 value 속성 확인
  - 에러 메시지가 표시되지 않는지 확인

### 단계 3: 비밀번호 입력
- **수행**: 비밀번호 필드를 클릭하고 비밀번호 입력
- **입력 데이터**: TestPass123!
- **예상 결과**: 
  - 입력한 비밀번호가 마스킹 처리됨 (*****)
  - 유효성 검증 에러가 없음
- **검증 방법**: 
  - 비밀번호 필드의 type이 "password"인지 확인
  - 실제 텍스트가 아닌 마스킹 문자가 표시되는지 확인

### 단계 4: 로그인 버튼 클릭
- **수행**: "로그인" 버튼 클릭
- **입력 데이터**: 없음
- **예상 결과**: 
  - 로딩 인디케이터가 잠깐 표시됨
  - 페이지가 대시보드로 전환됨
- **검증 방법**: 
  - HTTP POST 요청이 /api/auth/login으로 전송되는지 확인
  - 응답 상태 코드가 200인지 확인
  - JWT 토큰이 쿠키/로컬스토리지에 저장되는지 확인

### 단계 5: 대시보드 확인
- **수행**: 자동으로 리다이렉트된 페이지 확인
- **입력 데이터**: 없음
- **예상 결과**: 
  - URL이 /dashboard로 변경됨
  - 환영 메시지 표시: "안녕하세요, [사용자 이름]님"
  - 사용자 프로필 이미지 또는 아이콘 표시
  - 로그아웃 버튼 표시
- **검증 방법**: 
  - URL 경로 확인
  - 특정 텍스트가 DOM에 존재하는지 확인
  - 사용자 관련 UI 요소들이 렌더링되는지 확인

### 단계 6: API 통신 검증
- **수행**: 네트워크 로그 확인
- **입력 데이터**: 없음
- **예상 결과**: 
  - POST /api/auth/login 요청 성공
  - 요청 바디에 이메일과 비밀번호 포함
  - 응답 바디에 token과 user 정보 포함
  - 응답 시간 < 2초
- **검증 방법**: 
  - 브라우저 개발자 도구의 Network 탭 확인
  - 요청/응답 헤더 및 바디 검사

## 최종 예상 결과
- ✅ 모든 단계가 에러 없이 완료됨
- ✅ 사용자가 대시보드에 로그인된 상태
- ✅ 세션이 유지되어 페이지 새로고침 후에도 로그인 상태 유지
- ✅ 브라우저 콘솔에 에러 메시지 없음

## 실패 시 조치
1. 스크린샷과 비디오 녹화본 저장
2. 네트워크 로그 (.har 파일) 저장
3. 브라우저 콘솔 로그 저장
4. 정확히 어느 단계에서 실패했는지 기록
5. 예상 결과와 실제 결과 비교
6. Jira 티켓 생성 (자동)

## 비고
- 이 테스트는 Happy Path (정상 경로) 테스트임
- 실패 케이스는 별도 테스트 케이스에서 다룸:
  - TC-AUTH-002: 잘못된 비밀번호
  - TC-AUTH-003: 존재하지 않는 이메일
  - TC-AUTH-004: 빈 필드 제출

에이전트에게 실행 지시하기

1
2
3
4
5
6
7

docs/test-cases.md 파일에서 
"TC-AUTH-001" 케이스를 실행해줘.

각 단계를 정확히 따라하고,
모든 검증 방법을 적용해서 결과를 확인해줘.
실패하면 즉시 중단하고,
"실패 시 조치" 섹션에 명시된 대로 데이터를 수집해줘.

Workflow로 변환하기

테스트 케이스를 Workflow로 만들면 반복 실행이 쉬워집니다.

테스트 케이스 → Workflow 변환

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152

name: test-login-success
description: TC-AUTH-001 자동화 (유효한 계정으로 로그인 성공)

# 메타데이터
metadata:
  case_id: TC-AUTH-001
  scenario_id: TS-AUTH-001
  priority: P0
  test_type: UI + Integration

# 매개변수 (다른 환경이나 계정으로 테스트 가능)
parameters:
  environment:
    type: string
    default: "staging"
    description: "테스트 환경 (dev/staging/production)"
  
  test_email:
    type: string
    default: "test-user-001@example.com"
    description: "테스트 계정 이메일"
  
  test_password:
    type: string
    default: "TestPass123!"
    description: "테스트 계정 비밀번호"

# 환경별 URL 매핑
environment_urls:
  dev: "https://dev.example.com"
  staging: "https://staging.example.com"
  production: "https://www.example.com"

# 실행 단계
steps:
  # 준비
  - name: "환경 초기화"
    actions:
      - 브라우저 캐시 및 쿠키 삭제
      - 네트워크 모니터링 시작
      - 타임스탬프 기록 (테스트 시작 시간)

  # 단계 1
  - name: "로그인 페이지 접속"
    url: "${environment_urls[environment]}/login"
    validations:
      - URL 경로가 "/login"인지 확인
      - 페이지 제목에 "로그인" 포함 확인
      - 이메일 필드 존재 확인 (selector: 'input[type="email"]')
      - 비밀번호 필드 존재 확인 (selector: 'input[type="password"]')
      - 로그인 버튼 존재 확인 (selector: 'button[type="submit"]')
    capture:
      - 스크린샷: "01-login-page.png"

  # 단계 2
  - name: "이메일 입력"
    actions:
      - 이메일 필드 클릭
      - "${test_email}" 입력
      - 0.5초 대기 (입력 확인용)
    validations:
      - 이메일 필드의 value가 "${test_email}"인지 확인
      - 유효성 검증 에러 메시지가 없는지 확인
    capture:
      - 스크린샷: "02-email-entered.png"

  # 단계 3
  - name: "비밀번호 입력"
    actions:
      - 비밀번호 필드 클릭
      - "${test_password}" 입력
      - 0.5초 대기
    validations:
      - 비밀번호 필드의 type이 "password"인지 확인
      - 마스킹 문자(*****)가 표시되는지 확인
    capture:
      - 스크린샷: "03-password-entered.png"

  # 단계 4
  - name: "로그인 버튼 클릭"
    actions:
      - 로그인 버튼 클릭
      - 최대 10초 대기 (로딩 및 리다이렉트)
    validations:
      - HTTP POST 요청이 "/api/auth/login"으로 전송되는지 확인
      - 응답 상태 코드가 200인지 확인
      - 응답 시간이 2초 미만인지 확인
      - 응답 바디에 "token" 필드가 있는지 확인
    capture:
      - 네트워크 로그: "04-login-request.har"
      - 스크린샷: "04-logging-in.png"

  # 단계 5
  - name: "대시보드 확인"
    wait_for:
      - URL이 "/dashboard"로 변경될 때까지 대기
      - 환영 메시지가 표시될 때까지 대기
    validations:
      - URL 경로가 "/dashboard"인지 확인
      - 텍스트 "안녕하세요"가 페이지에 존재하는지 확인
      - 로그아웃 버튼이 존재하는지 확인
    capture:
      - 스크린샷: "05-dashboard.png"

  # 단계 6
  - name: "API 통신 검증"
    validations:
      - 네트워크 로그에서 /api/auth/login 요청 찾기
      - 요청 바디에 email과 password 포함 확인
      - 응답 바디 구조 검증:
        * token: string
        * user: object
        * user.id: string
        * user.email: string
      - 쿠키 또는 로컬스토리지에 토큰 저장 확인
    capture:
      - 네트워크 상세 로그

# 성공 기준
success_criteria:
  - 모든 단계의 모든 validations 통과
  - 브라우저 콘솔에 에러 없음
  - 최종 URL이 /dashboard
  - 사용자 세션이 활성 상태

# 실패 시 자동 조치
on_failure:
  - 현재 단계의 스크린샷 촬영
  - 전체 테스트 비디오 저장
  - 네트워크 로그 전체 저장
  - 브라우저 콘솔 로그 저장
  - Jira 티켓 자동 생성:
      project: "QA"
      issue_type: "Bug"
      summary: "[Automated] TC-AUTH-001 실패"
      priority: "Critical"
      labels: ["automated-test", "login", "regression"]
  - Slack 알림 전송:
      channel: "#qa-alerts"
      message: "🚨 로그인 테스트 실패: TC-AUTH-001"

# 성공 시 조치
on_success:
  - 테스트 결과를 데이터베이스에 기록
  - 통과율 메트릭 업데이트
  - (선택적) Slack 알림: "✅ TC-AUTH-001 통과"

# 정리
cleanup:
  - 브라우저 종료
  - 네트워크 모니터링 중지
  - 임시 파일 정리

Workflow 실행

1

/test-login-success

또는 다른 환경으로:

1

/test-login-success environment=production test_email=prod-user@example.com

복잡한 시나리오: 여러 테스트 케이스 묶기

테스트 스위트 Workflow

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

name: test-suite-authentication
description: 인증 관련 모든 테스트 케이스 실행

# 실행할 테스트 케이스 목록
test_cases:
  - id: TC-AUTH-001
    workflow: test-login-success
    priority: P0
  
  - id: TC-AUTH-002
    workflow: test-login-invalid-password
    priority: P0
  
  - id: TC-AUTH-003
    workflow: test-login-invalid-email
    priority: P1
  
  - id: TC-AUTH-004
    workflow: test-login-empty-fields
    priority: P1
  
  - id: TC-AUTH-005
    workflow: test-logout
    priority: P0

# 실행 전략
execution:
  mode: "sequential"  # 또는 "parallel" (독립적인 케이스의 경우)
  stop_on_failure: false  # 실패해도 계속 진행
  retry_on_failure: true
  max_retries: 1

# 실행 로직
steps:
  - name: "환경 준비"
    actions:
      - 테스트 데이터베이스 초기화
      - 테스트 계정 확인
      - 브라우저 환경 설정

  - name: "테스트 케이스 실행"
    for_each: "${test_cases}"
    actions:
      - 테스트 케이스 시작 로그
      - "${workflow}" Workflow 실행
      - 결과 수집 및 기록
      - (실패 시) 재시도 로직 적용

  - name: "결과 집계"
    actions:
      - 전체 통과율 계산
      - 실패한 케이스 목록 작성
      - 실행 시간 통계 생성

# 리포팅
report:
  format: "HTML"
  include:
    - 전체 요약 (통과/실패/건너뜀)
    - 각 케이스별 상세 결과
    - 스크린샷 갤러리
    - 네트워크 로그 요약
    - 실행 시간 차트
  output: "reports/auth-suite-${timestamp}.html"

# 알림
notifications:
  - condition: "any_failure"
    action:
      type: "slack"
      channel: "#qa-alerts"
      message: |
        🚨 인증 테스트 스위트 실패
        통과: ${passed_count}/${total_count}
        실패: ${failed_count}/${total_count}
        상세: ${report_url}
  
  - condition: "all_passed"
    action:
      type: "slack"
      channel: "#qa-results"
      message: "✅ 인증 테스트 스위트 전체 통과 (${total_count}개)"

실행

1

/test-suite-authentication

문서 기반 vs Workflow 기반: 언제 무엇을 사용할까

문서 기반 접근 (Markdown 테스트 케이스)

장점:

  • 사람이 읽고 이해하기 쉬움
  • 버전 관리가 간단 (Git)
  • 비개발자도 작성 가능
  • 유연한 설명 가능

단점:

  • 에이전트에게 매번 읽어달라고 요청해야 함
  • 구조가 덜 엄격하면 에이전트가 오해할 수 있음
  • 재사용이 덜 편리함

사용 시기:

  • 테스트 계획 수립 단계
  • 문서화가 주 목적일 때
  • 일회성 테스트
  • 탐색적 테스트 가이드

Workflow 기반 접근 (YAML Workflow)

장점:

  • 에이전트가 직접 실행 가능 (/workflow-name)
  • 구조화되고 반복 가능
  • 매개변수화로 재사용성 높음
  • 자동화 및 스케줄링 용이

단점:

  • YAML 문법 학습 필요
  • 초기 작성 시간이 더 걸림
  • 사람이 읽기에는 덜 직관적

사용 시기:

  • 회귀 테스트
  • CI/CD 통합
  • 반복 실행이 필요한 테스트
  • 자동화가 필수인 경우

권장 하이브리드 접근

  1. 처음에는 Markdown으로 작성
    • 테스트 시나리오와 케이스를 사람이 읽기 쉬운 Markdown으로 작성
    • 팀 리뷰 및 승인
  2. 검증 후 Workflow로 변환
    • 승인된 테스트 케이스를 Workflow로 변환
    • 에이전트에게 “이 테스트 케이스를 Workflow로 변환해줘”라고 요청 가능
  3. 두 가지를 함께 유지
    • Markdown: 문서화 및 사람 참조용
    • Workflow: 실제 실행용
    • 주기적으로 동기화

실전 사례: 전체 프로세스

1단계: 테스트 시나리오 작성 (Markdown)

파일: docs/scenarios/checkout-flow.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 테스트 시나리오: 체크아웃 플로우

## 개요
사용자가 상품을 선택하고 구매를 완료하는 전체 과정 검증

## 주요 테스트 포인트
1. 장바구니 추가
2. 수량 조절
3. 쿠폰 적용
4. 배송지 입력
5. 결제 수단 선택
6. 주문 확인

... (상세 내용)

2단계: 상세 테스트 케이스 작성 (Markdown)

파일: docs/test-cases/checkout/TC-CHECKOUT-001.md

1
2
3

# 테스트 케이스: 정상 결제 플로우

... (단계별 상세 내용)

3단계: Workflow 생성 요청

Chat Panel에서:

1
2
3
4
5

docs/test-cases/checkout/TC-CHECKOUT-001.md 파일을 읽고
이를 Workflow로 변환해줘.

파일명: .antigravity/workflows/test-checkout-success.yaml
매개변수로 환경, 테스트 계정, 상품 ID를 받을 수 있게 해줘.

에이전트가 자동으로 Workflow 파일을 생성합니다.

4단계: 수동 실행 및 검증

1

/test-checkout-success environment=staging

결과를 확인하고 문제가 있으면 Workflow를 수정합니다.

5단계: CI/CD에 통합

.github/workflows/regression-tests.yml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

name: Regression Tests

on:
  push:
    branches: [ main, develop ]
  schedule:
    - cron: '0 9 * * *'  # 매일 오전 9시

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Setup Antigravity
        run: |
          # Antigravity CLI 설치
          
      - name: Run Test Suite
        run: |
          antigravity run /test-suite-all
          
      - name: Upload Results
        uses: actions/upload-artifact@v2
        with:
          name: test-reports
          path: reports/

베스트 프랙티스

1. 명확한 셀렉터 사용

나쁜 예:

1

"버튼 클릭"

좋은 예:

1
2
3
4
5

"로그인" 텍스트를 가진 버튼 클릭
또는
data-testid="login-submit" 속성을 가진 버튼 클릭
또는
role="button"이고 name="로그인"인 요소 클릭

2. 명시적 대기 조건

나쁜 예:

1

버튼 클릭 후 3초 대기

좋은 예:

1
2
3
4

버튼 클릭 후:
- 로딩 스피너가 사라질 때까지 대기 (최대 10초)
- 그 다음 대시보드 페이지가 로드될 때까지 대기
- 특정 텍스트가 나타날 때까지 대기

3. 검증의 구체성

나쁜 예:

1

로그인 성공 확인

좋은 예:

1
2
3
4
5
6

다음을 모두 확인:
1. URL이 /dashboard로 변경됨
2. 사용자 이름이 헤더에 표시됨
3. 로그아웃 버튼이 활성화됨
4. JWT 토큰이 쿠키에 저장됨
5. 브라우저 콘솔에 에러 없음

4. 독립적인 테스트

각 테스트 케이스는 다른 케이스에 의존하지 않아야 합니다.

나쁜 예:

1

TC-001을 먼저 실행한 후 TC-002를 실행

좋은 예:

1
2
3
4

각 테스트 케이스는:
- 자체적으로 환경 준비
- 필요한 데이터 직접 생성
- 완료 후 정리

5. 테스트 데이터 분리

나쁜 예:

1

하드코딩된 이메일: "test@example.com"

좋은 예:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

test-fixtures.json:
{
  "users": {
    "valid": {
      "email": "test-user-001@example.com",
      "password": "TestPass123!"
    },
    "invalid": {
      "email": "invalid@example.com",
      "password": "wrong"
    }
  }
}

Workflow에서 참조:
email: "${fixtures.users.valid.email}"

결론

구글 안티그래비티의 AI 에이전트는 잘 구조화된 문서를 읽고 이해하여 테스트를 실행할 수 있습니다. 핵심은:

  1. 명확한 구조: 에이전트가 쉽게 파싱할 수 있는 형식
  2. 구체적인 지시: 모호하지 않은 단계별 설명
  3. 검증 기준: 성공/실패를 명확히 판단할 수 있는 조건
  4. Workflow 활용: 반복 실행을 위한 YAML 변환

Markdown 문서로 시작하여 사람이 읽고 승인한 후, Workflow로 변환하여 자동화하는 하이브리드 접근법이 가장 효과적입니다.

테스트 문서를 작성할 때는 항상 “이 문서를 AI 에이전트가 읽고 정확히 실행할 수 있을까?”를 자문하세요. 명확하고 구체적이고 검증 가능한 문서가 가장 좋은 문서입니다.

문서 작성 일자: 2026-01-22

추가 리소스

  • 안티그래비티 공식 문서: antigravity.google
  • Workflow 문법 가이드: docs/workflows
  • 테스트 자동화 베스트 프랙티스
  • CI/CD 통합 가이드

템플릿 다운로드

  • 테스트 시나리오 템플릿 (Markdown)
  • 테스트 케이스 템플릿 (Markdown)
  • Workflow 템플릿 (YAML)
  • 테스트 스위트 템플릿 (YAML)
AI, Antigravity
AI Antigravity test-case test-scenario unit-test integration-test Guide Claude.write
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.