AI 에이전트 시대, 테스트는 여정이 아니라 목표를 검증한다

웹앱을 테스트한다는 말은 오래도록 “버튼을 누르고, 폼을 채우고, 예상 문구를 확인한다”는 뜻에 가까웠다. 그런데 AI 에이전트가 브라우저를 직접 다루기 시작하면서 테스트의 중심이 바뀌고 있다. 이제 중요한 질문은 “정해진 클릭 경로를 그대로 탔는가?”가 아니라 “사용자의 목표가 실제로 달성됐는가?”다.

TL;DR

• Slack은 200건 이상의 agentic E2E 실험을 통해 에이전트 테스트가 기존 테스트를 대체하기보다 피라미드 최상단의 목표 검증 계층이 된다고 봤다.
• 에이전트 테스트는 클릭 여정이 아니라 goal → adapt → verify 구조다.
• 비용은 아직 비싸다. Slack 사례 기준 회당 $15–30, 5–11분 수준이다. 그래서 모든 CI에 넣기보다 복잡한 사용자 목표, 탐색, 디버깅, 릴리즈 전 confidence check에 맞다.
• Codex/Claude Code의 /goal 흐름, Woka의 제약·검증·교정·사람 원칙, Claude Code의 skills/hooks/subagents 구조는 모두 같은 운영 철학으로 수렴한다.
• Frandeer에는 Agentic Test Readiness Checklist, Goal Prompt Builder, AI Agent Cost vs Confidence Calculator 같은 유틸 기회가 있다.

1. 기존 E2E 테스트는 “여정”을 고정한다

전통적인 E2E 테스트는 보통 이런 모양이다.

로그인한다 → 버튼을 클릭한다 → 입력한다 → 제출한다 → 특정 문구가 보이는지 확인한다

이 방식은 강력하다. 빠르고, 결정론적이고, CI에 넣기 좋다. 같은 동작을 수천 번 반복할 수 있고, 실패하면 어느 단계에서 깨졌는지 비교적 명확하다.

하지만 한계도 있다.

• 사용자가 다른 경로로 같은 목표에 도달하면 실패로 볼 수 있다.
• UI가 조금만 바뀌어도 테스트가 깨질 수 있다.
• “실제로 사용자가 목표를 달성할 수 있는가?”보다 “내가 적어둔 경로가 아직 살아 있는가?”를 검증하기 쉽다.

테스트가 제품의 진짜 사용성을 보장하지 못하는 순간이 여기서 나온다.

2. Slack 실험의 핵심: 에이전트는 경로가 아니라 목표를 본다

Slack 엔지니어링팀은 에이전트 기반 E2E 테스트가 기존 결정론적 테스트를 대체할 수 있는지 확인하기 위해 200건 이상의 워크플로를 실행했다.

결론은 꽤 현실적이다.

에이전트는 기존 E2E 테스트를 대체하지 않는다. 대신 테스트 피라미드의 최상단에 탐색, 디버깅, 복잡 동작 검증 계층으로 추가된다.

전통 테스트가 “이 버튼을 누른다”를 강제한다면, 에이전트 테스트는 “스레드 메시지를 보낸다” 같은 목표를 준다. 그리고 에이전트가 화면을 보고, 가능한 경로를 선택하고, 결과가 맞는지 확인한다.

Slack 실험에서 흥미로운 점은, 최종 결과가 같아도 실행 경로는 자주 달랐다는 것이다. 검색 추천을 클릭하기도 하고, Enter를 누르기도 하고, 기존 상태를 재사용하기도 했다.

이건 테스트라기보다 작은 사용자 시뮬레이션에 가깝다.

3. 하지만 아직 비싸다: 회당 $15–30의 confidence check

여기서 흥분만 하면 안 된다. Slack의 숫자는 꽤 차갑다.

• Agent + Playwright MCP: 단순 플로 실패율 0%, 복잡 플로 약 12%, 평균 5–8분
• Agent + Playwright CLI: 실패율 약 12–20%, 평균 9–11분
• Generated Playwright Tests: 단순 플로는 빠르지만 복잡 플로에서 실패율 약 48%
• 에이전트 실행 비용: 보통 회당 $15–30

이 숫자는 “모든 테스트를 에이전트로 바꾸자”는 결론을 막는다.

대신 더 좋은 결론을 준다.

에이전트 테스트는 싼 반복 테스트가 아니라 비싼 confidence check다.

즉, 이런 곳에 먼저 맞다.

• 릴리즈 전 핵심 사용자 플로 점검
• 사람이 직접 QA하기 귀찮은 복잡한 경로 탐색
• 실패한 E2E 테스트의 원인 디버깅
• 여러 UI 경로가 가능한 제품의 목표 달성 확인
• 결제, 온보딩, 협업, 검색처럼 “사용자 목표”가 중요한 플로

4. 모델보다 하네스가 중요하다

Slack 실험에서 특히 중요한 포인트는 Playwright MCP 방식이 CLI 방식보다 안정적이었다는 점이다.

이유는 단순하다. 에이전트가 브라우저 상태를 얼마나 안정적으로 보고, 한 번의 왕복에서 얼마나 많은 상태 정보를 유지하느냐가 결과를 바꾼다.

CLI 방식은 매 단계마다 상태를 다시 읽고, 명령을 나누고, 스냅샷을 재구성한다. 반면 MCP 방식은 브라우저 상호작용과 상태 반환이 더 에이전트 네이티브에 가깝다.

여기서 교훈은 크다.

에이전트 품질은 모델 이름만으로 정해지지 않는다. 실행 하네스가 품질이다.

Claude냐 GPT냐도 중요하지만, 실제 운영에서는 이런 질문이 더 중요해진다.

• 에이전트가 현재 상태를 정확히 볼 수 있는가?
• 도구 호출이 너무 잘게 쪼개져 토큰과 시간이 낭비되지 않는가?
• 실패했을 때 로그와 증거가 남는가?
• 같은 세션에서 앞선 성공 경로를 재사용할 수 있는가?
• 검증 기준이 명확한가?

이 질문들은 Frandeer가 만들 수 있는 유틸과도 바로 연결된다.

5. /goal은 테스트의 언어가 된다

오늘 LinkedIn에서 들어온 /goal 흐름도 같은 이야기를 한다. Codex, Claude Code, LazyCodex, Gajae-Code가 모두 “프롬프트 한 번”에서 “목표를 걸고 증거가 나올 때까지 도는 루프”로 수렴한다는 신호다.

좋은 /goal은 이렇게 생겼다.

/goal <원하는 최종 상태>를 달성한다.
검증은 <구체적 evidence>로 한다.
<건드릴 수 있는 범위>를 지킨다.
반복 사이에는 <변경점, 결과, 다음 실험>을 기록한다.
막히면 <시도한 경로, blocker, 필요한 입력>을 남기고 멈춘다.

이건 코딩 에이전트만의 문법이 아니다. 테스트 문법이기도 하다.

예를 들어 Frandeer 블로그 게시 검증이라면 이렇게 쓸 수 있다.

/goal 새 블로그 글이 /ko/blog/<slug>/에서 실제 article HTML로 열리게 한다.
검증은 URL 200이 아니라 HTML에 예상 title 또는 slug가 포함되고,
/ko/blog/ 인덱스 카드가 보이며, cover image와 source label이 렌더되는 것으로 한다.
홈페이지 fallback이면 실패로 본다.
직접 main push는 하지 말고 branch + PR을 남긴다.
막히면 repo 상태, 빌드 결과, 배포 blocker, rollback path를 보고한다.

이건 단순 지시가 아니라 완료 계약이다.

6. 신뢰의 4원칙: 제약, 검증, 교정, 사람

Woka의 AI 운영 노트도 오늘 신호를 더 단단하게 만든다. “AI 자동화의 진짜 벽은 똑똑함이 아니라 신뢰”라는 말이 핵심이다.

정리하면 4가지다.

1. 제약 — 할 수 있는 일에 울타리를 친다.
2. 검증 — 한 일을 또 다른 AI나 테스트가 재검사한다.
3. 교정 — 같은 실수는 규칙과 문서로 승격한다.
4. 사람 — 되돌릴 수 없는 일만 사람이 승인한다.

이건 제품 운영에도, 코딩 에이전트에도, 블로그 게시 자동화에도 그대로 적용된다.

특히 “교정”이 중요하다. 에이전트가 한 번 실수하면 그냥 넘어가는 게 아니라, 다음 실행에서 같은 실수를 못 하게 skill, checklist, handoff template, test로 바꿔야 한다.

AI 팀의 성숙도는 모델 구독 수가 아니라 실패를 운영 자산으로 바꾸는 속도에서 드러난다.

7. Claude Code의 지시 방식은 운영 아키텍처다

Claude Code 글은 CLAUDE.md, rules, skills, subagents, hooks, output styles, system prompt append를 비교한다. 겉으로 보면 Claude Code 사용법이지만, 실제로는 에이전트 운영 아키텍처 이야기다.

모든 지시를 하나의 루트 문서에 넣으면 토큰 비용이 커지고, 관련 없는 지시까지 매번 따라다닌다. 대신 지시의 성격에 따라 위치를 나눠야 한다.

이걸 테스트에 적용하면 더 명확해진다.

• 반복되는 QA 절차는 skill로 만든다.
• 실행 후 lint/test는 hook이나 CI로 둔다.
• 복잡한 브라우저 탐색은 agentic test로 둔다.
• 외부 게시/배포는 handoff와 승인 게이트로 나눈다.

8. Frandeer가 바로 만들 수 있는 작은 유틸 3개

거창한 SaaS부터 만들 필요 없다. Frandeer는 작은 글로벌 유틸 사이트로 빠르게 실험하는 전략이 맞다. 오늘 주제에서 바로 뽑을 수 있는 유틸은 세 가지다.

1) Agentic Test Readiness Checklist

사용자가 자기 웹앱/서비스 정보를 입력하면 에이전트 테스트를 붙일 준비가 되었는지 점검한다.

체크 항목:

• 핵심 사용자 목표가 명확한가?
• 성공 evidence가 DOM/URL/API/DB 중 어디에 있는가?
• 테스트 데이터와 프로덕션 데이터가 분리되어 있는가?
• 실패해도 안전한 sandbox가 있는가?
• 로그인/권한/세션 처리가 자동화 가능한가?
• 비용상 매 PR마다 돌릴 것인가, 릴리즈 전만 돌릴 것인가?

2) Goal Prompt Builder

자연어 요청을 좋은 /goal 계약으로 바꿔준다.

입력:

내 체크아웃 플로우가 깨지지 않았는지 AI 에이전트로 확인하고 싶다.

출력:

/goal checkout flow에서 사용자가 상품을 담고 결제 직전 confirmation 화면까지 도달할 수 있음을 검증한다...

개발자뿐 아니라 일반인에게도 유용하다. “AI에게 일을 잘 시키는 문장”을 만들어주는 유틸이기 때문이다.

3) AI Agent Cost vs Confidence Calculator

작업 유형, 예상 턴 수, 모델, 검증 단계, 실행 빈도를 넣으면 비용과 confidence gain을 대략 보여준다.

핵심은 정확한 과금 계산보다 의사결정이다.

• 매 PR마다 돌릴 가치가 있는가?
• nightly로 충분한가?
• 릴리즈 전 수동 승인과 섞어야 하는가?
• 결정론적 Playwright 테스트로 내릴 수 있는 부분은 어디인가?

9. 반론: 에이전트 테스트는 너무 비싸고 느린 것 아닌가?

맞다. 지금 기준으로는 비싸고 느리다.

그래서 모든 것을 에이전트로 바꾸면 안 된다. 오히려 좋은 운영자는 테스트를 세 층으로 나눈다.

1. 결정론적 테스트 — 빠르고 싸게 매번 돈다.
2. 생성/보조 테스트 — 자연어에서 Playwright 테스트를 만들고 고친다.
3. Agentic confidence check — 복잡한 목표를 실제 사용자처럼 탐색한다.

에이전트 테스트는 1번을 대체하지 않는다. 1번이 놓치는 “목표 달성 가능성”을 최상단에서 본다.

이 차이를 이해하는 팀이 비용을 통제하면서도 더 좋은 QA를 만든다.

결론: 프롬프트보다 중요한 것은 완료 조건이다

AI 에이전트 시대의 테스트는 클릭 경로를 외우는 일이 아니다. 목표를 정의하고, 성공 증거를 정하고, 실행 범위를 제한하고, 실패하면 무엇을 남길지 설계하는 일이다.

이건 개발자만의 이야기가 아니다. AI로 블로그를 게시하든, 데이터를 수집하든, 고객 이메일을 분류하든 원리는 같다.

좋은 에이전트 운영은 “일을 시키는 문장”이 아니라 “완료와 실패를 판정하는 시스템”에서 시작한다.

Frandeer가 이 흐름을 잡는다면, 단순한 AI 뉴스 사이트가 아니라 사람들이 자기 작업에 에이전트를 안전하게 붙이도록 돕는 유틸리티 레이어가 될 수 있다.

그리고 그 출발점은 작다.

체크리스트 하나, goal builder 하나, 비용 계산기 하나.

2026년의 AI 유틸은 여기서부터 시작해도 충분하다.

Sources

• 에이전틱 테스팅 - E2E 테스트 스택에서 에이전트의 역할
• Coding agents usage pattern convergence: /goal, harness, loop engineering
• Woka AI 운영 노트
• Steering Claude Code: skills, hooks, subagents and more
• Image: <chatgpt image 2>