에이전틱 테스트 환경 엔지니어링

에이전틱 시대의 테스트 환경은 더 이상 "테스트 러너 하나"로 설명되지 않습니다. 브라우저 자동화, API probe, workflow check, synthetic data, sandbox, observability, release gate가 하나의 판단 시스템으로 묶여야 합니다.

이 핸드북은 그 시스템을 Playwright 같은 브라우저 러너를 포함하되 거기에 한정하지 않고, 환경 설계, 상태 통제, 계약, 게이트, 관측성, 인시던트 대응 관점에서 다시 정리합니다.

왜 에이전틱 시대에 테스트 환경이 달라지는가

에이전트가 코드를 만들고 수정하는 속도가 빨라질수록, 테스트 환경은 단순 실행기가 아니라 변경 위험을 빠르게 분류하고 신뢰 가능한 반증을 제공하는 시스템이 됩니다.

이 책이 다루는 핵심 구성요소

• 포트폴리오: 어떤 시나리오를 browser/API/workflow/canary probe로 나눌지
• 환경과 상태: preview, shared integration, prod-like, sandbox, clock, queue, seed
• 테스트 하네스: probe가 같은 entry contract, evidence schema, repair boundary를 따르게 할지
• 계약: locator, API schema, domain event, log/tracing field 같은 안정적 관측 포인트
• 실행 패브릭: PR/main/nightly/release/canary/agent-repair 루프
• 판정: blocker 정의, evidence bundle, retry budget, quarantine, human gate
• 관측성: failure classification, environment fingerprint, MTTR, evidence completeness
• 운영: ownership, audit trail, postmortem, quarterly review

운영 원칙 6개

1. 게이트를 막을 probe만 높은 tier에 올립니다.
2. 환경과 상태의 비결정성을 제품 회귀와 분리해 추적합니다.
3. 테스트 코드는 증거 수집기의 일부일 뿐, 판정 시스템 전체가 아닙니다.
4. locator, schema, event, log field는 모두 테스트 계약입니다.
5. retry는 통과를 만드는 장치가 아니라 분류를 돕는 장치여야 합니다.
6. owner 없는 suite 확장과 런북 없는 자동화는 금지합니다.

성숙도 모델

에이전틱 테스트 환경의 기준 질문

• 지금 gate를 막을 가치가 있는 시나리오는 정확히 몇 개인가?
• 어떤 probe는 browser가, 어떤 probe는 API나 workflow runner가 더 적합한가?
• 실패 시 product vs data vs infra vs external이 10분 안에 분류되는가?
• 환경 fingerprint 없이도 "어제는 되고 오늘은 왜 안 되지?"를 설명할 수 있는가?
• agent가 재실행할 수 있는 범위와 사람이 반드시 승인해야 하는 범위가 분리되어 있는가?

추천 읽기 경로

테스트 환경 라이프사이클

목차

연관 핸드북

• 상위 테스트 피라미드와 모노레포 기본 전략은 엔터프라이즈 프로젝트 설계 - 테스트 전략을 참고하세요.
• 브라우저 액추에이터와 하네스 관점은 하네스 엔지니어링과 함께 보면 더 잘 연결됩니다.
• 접근성 자동화와 visual/a11y gate 확장은 Design Systems + AI를 같이 보면 좋습니다.