개념
프롬프트 기법을 어디에 붙일 것인가
앞 레슨에서 6요소 구조와 세 가지 기법을 익혔다. 이제 그것을 테스트 프로세스의 어느 단계에 붙일지 를 본다.
모듈 8에서 배운 테스트 프로세스를 떠올려보자 — 계획, 분석, 설계, 구현, 실행, 완료. 생성형 AI가 실제로 값을 하는 지점은 이 중 일부에 몰려 있다.
| 단계 | AI의 기여 | 사람이 반드시 하는 것 |
|---|---|---|
| 테스트 분석 | 매우 큼 — 조건 도출, 모호성 탐지 | 도메인 판단, 우선순위 확정 |
| 테스트 설계 | 큼 — 케이스 생성, 기법 적용 | 커버리지 판정, 누락 확인 |
| 테스트 구현 | 큼 — 스크립트 초안, 데이터 생성 | 검증 로직의 타당성 |
| 테스트 실행 | 중간 — 에이전트 기반 실행 | 실패 원인 판단 |
| 모니터링·통제 | 중간 — 요약, 리포트 초안 | 의사결정 |
가장 값이 큰 곳이 테스트 분석 이라는 점이 의외일 수 있다. 대부분의 사람이 "테스트 케이스 생성"부터 떠올리지만, 그 앞 단계에서 얻는 이득이 더 크다. 이유는 단순하다 — 분석 단계의 누락은 뒤의 모든 단계로 전파되기 때문이다. 모듈 1에서 배운 결함 전파 그대로다.
테스트 분석 — 다섯 가지 작업
테스트 분석에서 AI가 도울 수 있는 일은 대략 다섯 갈래다.
1) 테스트 베이시스의 결함 찾기
요구사항 자체의 모호함·모순·누락을 찾는 일이다. 모듈 2(레슨 6)에서 배운 요구사항 리뷰를 AI가 1차로 훑는 셈이다.
역할: 요구사항 리뷰 경험이 많은 QA 엔지니어
지시: 아래 유저 스토리에서 테스트 관점의 문제를 찾아라
제약: 각 지적마다 (a) 어떤 유형인지(모호/모순/누락/검증불가),
(b) 왜 문제인지, (c) 어떻게 물어야 하는지를 함께 적어라
출력: 표. 열은 문장 인용 / 유형 / 이유 / 확인 질문(c)를 요구하는 것이 요령이다. "모호하다"까지만 나오면 회의에서 쓸 수 없지만, "이 문장은 '빠르게'가 몇 초인지 정의하지 않았습니다 — p95 기준 몇 초를 목표로 하십니까?"는 그대로 질문이 된다.
2) 테스트 조건 도출
요구사항을 검증 가능한 진술 로 쪼개는 일이다. 모듈 2에서 배운 "요구사항을 테스트로 옮기기"가 이것이다.
3) 리스크 기반 우선순위
발생 가능성과 영향도 정보를 주면 우선순위 초안을 제안하게 할 수 있다. 모듈 4(레슨 2)의 리스크 매트릭스를 프롬프트의 제약에 넣는다.
단, 우선순위 확정은 사람이 한다. AI는 규제 준수·매출 영향·과거 결함 이력 같은 조직 맥락을 모른다. 그 정보를 맥락에 넣어주면 초안의 질이 올라가지만, 그래도 초안이다.
4) 커버리지 분석
요구사항과 테스트 조건을 대응시켜 빠진 곳 을 찾는다. 모듈 18c (레슨 4)에서 다룬 커버리지 갭 찾기와 같은 작업이고, 여기서는 그것을 분석 단계에서 미리 하는 셈이다.
5) 적용할 기법 제안
"이 요구사항에는 경계값 분석과 상태전이가 적합하다" 같은 제안이다. 모듈 3(레슨 2)의 기법 지도가 있으면 이 제안을 판정할 수 있다. 없으면 제안을 그대로 받아들이게 되는데, 그게 위험하다.
인수기준 생성 — 멀티모달이 값을 하는 지점
특히 실무에서 자주 쓰게 되는 작업이 유저 스토리에서 인수기준 도출 이다. 여기서 앞 레슨의 멀티모달 모델이 힘을 발휘한다.
입력 데이터:
· 유저 스토리 원문
· 화면 설계서 이미지(와이어프레임)
· 입력 필드 제약(자릿수·형식)
· 적용할 비즈니스 규칙
지시: 이 화면과 스토리에 대한 인수기준을 Given-When-Then으로 작성하라
제약: 화면에 보이는 요소만 대상. 추측으로 기능을 추가하지 말 것
출력: 각 인수기준에 번호를 붙이고, 근거가 된 화면 요소를 함께 표기"추측으로 기능을 추가하지 말 것" 이라는 제약이 중요하다. 이게 없으면 모델은 일반적인 화면에 있을 법한 기능(비밀번호 찾기, 자동 로그인 등)을 만들어 넣는다. 모듈 18b(레슨 2)의 환각이 인수기준 형태로 나타나는 것이다.
그리고 여기에 체이닝 을 얹으면 품질이 한 단계 올라간다.
① 모호성 검사 "이 인수기준에서 해석이 갈릴 수 있는 표현을 찾아라"
→ 사람이 확인·보정
② 테스트 가능성 "각 인수기준이 관찰 가능하고 판정 가능한지 평가하라"
→ 사람이 확인·보정
③ 완전성 검사 "이 스토리에서 빠진 인수기준이 있는지 평가하라"
→ 사람이 확인·보정각 단계마다 사람이 확인하고 넘어간다는 것 이 핵심이다. 확인 없이 체인만 돌리면 1단계의 오류가 3단계까지 증폭된다.
테스트 설계·구현
분석 결과가 확정되면 케이스 생성으로 넘어간다. 레슨 1에서 다룬 내용이고, 여기서는 앞 레슨의 기법을 얹는 방법만 짚는다.
| 얹을 기법 | 효과 |
|---|---|
| 퓨샷 — 팀의 우수 케이스 3개 | 형식과 상세도가 팀 기준에 맞는다 |
| 제약 — 적용할 기법 지정 | "경계값 분석만" 같은 지시로 누락 축소 |
| 출력 형식 — 관리 도구 열 구조 | 모듈 22의 도구에 그대로 붙여 넣기 |
| 체이닝 — 생성 후 자기 검토 | "방금 만든 케이스에서 중복과 누락을 찾아라" |
마지막 줄이 값싸고 효과가 좋다. 생성 직후에 같은 모델에게 검토를 시키면 중복 케이스나 명백한 누락이 꽤 걸러진다. 물론 이것만으로 충분하지 않다 — 모듈 18c의 교차검증이 여전히 필요하다.
자동화 회귀 테스트에서
회귀 자동화에서 AI가 기여하는 지점은 셋이다.
- 스크립트 초안 생성 — 케이스를 코드로 옮기는 1차 작업
- 깨진 테스트 복구 제안 — 모듈 18a(레슨 3)의 셀프힐링
- 회귀 범위 제안 — 변경된 코드·요구사항을 근거로 "이번에 돌려야 할 케이스"를 추리는 작업
3번이 특히 실무적이다. 모듈 4(레슨 3)에서 배운 변경 규모별 커버리지 계획을 AI가 초안으로 잡아주는 셈이다. 다만 AI는 우리 시스템의 숨은 결합을 모른다. 코드상 무관해 보이는 모듈이 실제로는 같은 캐시를 공유하는 상황 같은 것. 그래서 초안이고, 확정은 사람이 한다.
테스트 모니터링·통제
차수 진행 중에 AI가 도울 수 있는 일이다.
- 실행 결과를 요약 해 진척 리포트 초안 만들기
- 실패 로그 묶음에서 패턴 찾기(같은 원인으로 보이는 실패 군집화)
- 결함 목록에서 리스크 신호 뽑기(특정 영역 집중, 재오픈 반복)
- 이해관계자용 보고 문구 초안
모듈 22(레슨 8)에서 만든 대시보드가 숫자를 보여준다면, AI는 그 숫자에 서술을 붙이는 역할을 한다. 단, 마지막 선은 분명하다 — 의사결정은 사람이 한다. 릴리즈 Go/No-Go(모듈 4 레슨 5)를 AI 요약에 근거해 내리는 것과, AI 요약을 참고 자료로 쓰는 것은 다르다.
결과를 어떻게 평가할 것인가
여기가 이 레슨에서 가장 중요한 부분이다. AI 결과가 좋아졌는지를 어떻게 아는가? 느낌으로 판단하면 프롬프트 개선도 느낌으로 하게 된다.
테스트 산출물에 대해 쓸 만한 평가 축은 다섯 가지다.
| 평가 축 | 무엇을 보나 | 재는 법 |
|---|---|---|
| 정확성 | 사실과 맞는가, 환각은 없는가 | 잘못된 항목 수 / 전체 |
| 완전성 | 빠진 것이 없는가 | 골든셋 대비 누락 수 |
| 관련성 | 우리 범위에 맞는가 | 범위 밖 항목 수 / 전체 |
| 일관성 | 형식과 상세도가 고른가 | 형식 위반 수 |
| 실행 가능성 | 그대로 쓸 수 있는가 | 손대야 하는 항목 비율 |
마지막 축이 실무에서 가장 정직한 지표다. "생성된 20개 중 손대지 않고 쓴 것이 몇 개인가." 이 숫자 하나가 프롬프트 품질을 잘 요약한다.
그리고 이 평가를 제대로 하려면 골든셋 이 필요하다. 사람이 잘 만든 정답 세트를 준비해두고, 프롬프트를 바꿀 때마다 같은 입력에 돌려 비교하는 방식이다. 모듈 18c(레슨 6)에서 하네스를 검증할 때 쓴 것과 같은 도구다.
프롬프트 v1 → 골든셋 입력 → 정확성 0.72 / 완전성 0.65 / 실행가능성 0.40
프롬프트 v2 → 같은 입력 → 정확성 0.85 / 완전성 0.80 / 실행가능성 0.65
↑ 개선이 숫자로 보인다여기서 앞 레슨의 온도 이야기가 이어진다. 같은 프롬프트도 실행마다 결과가 다르므로, 한 번 돌려보고 판단하면 안 된다. 모듈 18b(레슨 5) 에서 배운 대로 여러 번 돌려 통과율로 본다.
프롬프트 개선의 순환
평가가 되면 개선이 절차가 된다.
① 골든셋 준비 사람이 만든 정답 세트
↓
② 현재 프롬프트로 실행 (여러 번)
↓
③ 다섯 축으로 채점
↓
④ 가장 낮은 축을 겨냥해 프롬프트 수정
↓
⑤ 같은 골든셋에 재실행 → ③으로④에서 한 번에 하나씩 바꾸는 것 이 요령이다. 여러 곳을 동시에 고치면 무엇이 효과를 냈는지 알 수 없다. 모듈 10에서 배운 단위 테스트의 원칙과 같다 — 변수를 하나만 바꾼다.
축별로 대응이 다르다는 것도 알아두면 좋다.
| 낮은 축 | 손볼 곳 |
|---|---|
| 정확성 | 입력 데이터 보강, 추측 금지 제약 추가 |
| 완전성 | 체이닝으로 단계 분리, 기법 지정 제약 |
| 관련성 | 맥락과 범위 제외 제약 강화 |
| 일관성 | 퓨샷 예시 추가, 출력 형식 명시 |
| 실행 가능성 | 출력 형식을 실제 도구 구조에 맞춤 |
실무에서 왜 필요한가
AI로 테스트 케이스를 만들어봤다는 사람은 많지만, 그 결과가 나아지고 있는지를 숫자로 말할 수 있는 사람 은 드물다. 이 차이가 팀에서 AI 활용이 정착하느냐 흐지부지되느냐를 가른다. 숫자가 없으면 "AI 써봤는데 별로던데요"라는 인상 평가에서 논의가 끝난다.
분석 단계에 AI를 붙이는 것도 실질적인 이득이 크다. 요구사항 리뷰 회의 전에 AI로 1차 훑고 들어가면, 회의에서 "애매합니다"가 아니라 구체적 질문 목록 을 꺼낼 수 있다. 모듈 2 레슨 6에서 배운 리뷰의 질이 올라간다.
그리고 이 레슨의 내용은 그대로 자격증 준비와 겹친다. ISTQB CT-GenAI의 2장(프롬프트 엔지니어링)이 전체 학습시간의 절반 가까이를 차지하고, 그 안에서 테스트 분석·설계·회귀·모니터링 적용과 결과 평가가 핵심 학습 목표다.