개념
"알아서 해줘"로는 시작할 수 없다
레슨 5에서 배운 4단계 루프를 실제로 돌리려면, "그냥 우리 서비스를 테스트해줘"라는 지시로는 부족하다. 사람이 미리 몇 가지를 명확히 정의해줘야, AI 에이전트가 관찰-계획-실행-검증 루프를 의미 있게 돌 수 있다.
설계 요소 1 — 목표를 구체적으로 정의하기
레슨 1에서 배운 좋은 프롬프트 원칙이 여기서도 적용된다.
나쁜 목표: "쇼핑몰을 테스트해줘"
좋은 목표: "신규 사용자가 회원가입부터 첫 주문 완료까지 끊기지
않고 진행할 수 있는지 확인해줘. 결제는 테스트 카드
4111-1111-1111-1111을 사용해."목표가 모호하면 AI의 "계획" 단계가 방향을 잃는다 — 모듈 4(레슨 1)에서 배운 테스트 범위 정의와 같은 이유다.
설계 요소 2 — "성공"과 "실패"의 기준을 미리 정의하기
레슨 5에서 언급한 "검증 단계의 판단 기준"을 사람이 미리 정해둬야 한다.
성공 기준: "주문 완료 화면에 주문번호가 표시되고, URL이
/orders/confirmation을 포함한다"
실패 기준: "에러 메시지가 표시되거나, 3번 이상 같은 화면에서
진전이 없다"기준이 없으면 AI가 스스로 "이 정도면 성공이겠지"라고 느슨하게 판단할 위험이 있다 — 이건 모듈 3에서 배운 "명확한 기대 결과" 원칙이 Agentic Testing에도 그대로 적용되는 지점이다.
설계 요소 3 — 관찰 범위 정하기
AI가 매 단계 무엇을 "관찰"해야 하는지도 정의가 필요하다.
- 화면에 보이는 텍스트와 요소만 볼 것인가?
- 모듈 9(레슨 2)에서 배운 네트워크 요청·응답까지 함께 관찰할 것인가?
- 콘솔 에러(모듈 5 레슨 4)도 관찰 대상에 포함할 것인가?관찰 범위가 넓을수록 더 많은 문제를 잡아낼 가능성이 크지만, 그만큼 처리해야 할 정보도 많아진다 — 모듈 11(레슨 3)의 ROI 관점처럼 비용과 효과의 트레이드오프가 있다.
설계 요소 4 — 안전장치(Guardrails)
레슨 4에서 배운 신뢰 경계 원칙을 구체적인 규칙으로 만든다.
- 실행 환경: 반드시 테스트/스테이징 환경에서만 실행(모듈 7 레슨 3)
- 금지 동작: 실제 결제 승인, 데이터 영구 삭제 같은 동작은 절대
실행하지 않도록 제한
- 최대 시도 횟수: 같은 화면에서 5번 이상 반복 시도하면 멈추고
사람에게 보고(무한 루프 방지)설계 요소 5 — 결과를 사람이 검토할 수 있는 형태로 남기기
Agentic Testing이 끝나면, **"AI가 각 단계에서 무엇을 관찰하고, 어떻게 판단했는지"**를 사람이 나중에 확인할 수 있는 기록이 남아야 한다. 이건 모듈 13(레슨 2)에서 배운 트레이스·스크린샷 개념과 같은 역할이다 — AI의 판단 과정이 "블랙박스"로 남으면, 결과가 이상해도 원인을 추적할 방법이 없다.
하나로 엮어보기
목표 정의 → 성공/실패 기준 → 관찰 범위 → 안전장치 → 실행 기록이 다섯 가지를 미리 정의한 뒤에야, 레슨 5의 4단계 루프 (관찰-계획-실행-검증)를 안전하고 의미 있게 돌릴 수 있다. 이건 모듈 4(레슨 1)에서 배운 테스트 계획서 작성과 본질적으로 같은 작업이다 — 다만 그 계획이 사람이 아니라 AI 에이전트를 위한 것이라는 점이 다르다.
실무에서 왜 필요한가
"AI 에이전트로 우리 서비스 QA를 자동화하고 싶다"는 요청을 받았을 때, 이 다섯 가지 설계 요소 없이 바로 시작하면 통제 불가능한 결과가 나올 수 있다(무한 반복, 잘못된 성공 판정, 위험한 동작 실행). 이 설계 과정을 먼저 갖추는 QA는, Agentic Testing을 안전하고 신뢰할 수 있는 도구로 도입할 수 있다.