본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
에이전틱 테스트 환경 엔지니어링

근본 원리

테스트 포트폴리오 운영 모델환경·상태 통제 전략실행 토폴로지와 러너 아키텍처테스트 하네스 엔지니어링

계약 & 구성

인터페이스 계약과 관측 포인트상태 구성과 시나리오 픽스처

실행 & 게이트

실행 패브릭과 오케스트레이션리스크 기반 릴리즈 게이트

신뢰도 & 운영

비결정성과 Flake 관리관측성·신뢰도 지표테스트 인시던트 대응거버넌스와 소유권

부록

런북 템플릿검증 리포트업데이트 내역
핸드북›에이전틱 테스트 환경 엔지니어링›거버넌스와 소유권

거버넌스와 소유권

DevEx, SRE, 제품팀, QA 플랫폼, AI 플랫폼 사이의 owner와 승인 경계를 정하는 기준

핵심 요약

  • 테스트 환경은 도구가 아니라 조직 시스템입니다. owner·승인·보안·분기 리뷰가 갖춰져야 신뢰도가 유지됩니다.
  • 플랫폼·환경·도메인 probe·릴리즈 게이트·agent repair loop별로 책임 팀을 명시합니다.
  • gate suite·공용 fixture·contract·retry·quarantine·classifier 변경은 최소 2개 시선의 리뷰를 거칩니다.
  • audit trail에는 release gate probe, 예외 승인자, quarantine 허용 기간, agent repair 범위를 남깁니다.
  • 거버넌스의 목표는 승인 단계를 늘리는 게 아니라 누가 무엇을 바꿀 수 있는지 분명히 하는 데 있습니다.

테스트 환경은 도구가 아니라 조직 시스템입니다. owner와 승인 기준, 보안 정책, 분기 리뷰가 없으면 probe 수는 늘어나도 신뢰도는 떨어집니다.

ownership 구조

영역책임 팀핵심 책임
플랫폼 계층QA Platform / DevExrunners, reporters, shared fixtures, evidence schema
환경 계층SRE / Platformseed, reset, queue, clock, sandbox, secrets
도메인 probe제품팀시나리오 정의, 기대 결과 유지
릴리즈 게이트Release Manager + QA Platformblocker 정의, 예외 승인
agent repair loopAI Platform / DevExsafe scope, audit trail, rerun policy

CODEOWNERS 권장 범위

/testops/runners/browser/             @qa-platform
/testops/fixtures/                    @qa-platform @platform-team
/testops/contracts/payments/          @team-payments @qa-platform
/testops/runbooks/                    @qa-platform @release-managers
/testops/evidence/classifier/         @qa-platform @ai-platform

변경 승인 규칙

다음 변경은 최소 2개의 시선에서 리뷰합니다.

  • gate suite 추가/삭제
  • 공용 fixture 또는 environment controller 변경
  • test id / schema / event contract 변경
  • retry 정책 변경
  • quarantine 승인/해제
  • classifier나 agent repair scope 변경

보안과 개인정보

  • 테스트 계정 자격증명은 secret manager로만 배포
  • artifact 링크는 사내 접근 제어 하에 보관
  • production PII가 trace에 남지 않도록 sandbox 또는 masking 정책 적용
  • agent가 접근 가능한 evidence 범위도 role별로 분리

audit trail에 남겨야 할 기록

  • 어떤 probe가 release gate였는지
  • 누가 예외를 승인했는지
  • known flaky 또는 quarantine를 누가 어떤 기간 허용했는지
  • 어떤 agent repair가 어떤 범위에서 실행되었는지
  • sandbox secret과 계정 owner가 누구인지

분기 리뷰 루틴

  1. gate probe 재선정
  2. nondeterminism top 10 재정렬
  3. suite duration과 비용 검토
  4. 더 이상 가치 없는 시나리오 정리
  5. 신규 서비스 onboarding 상태 점검

anti-pattern

  • owner 없는 공용 probe 증가
  • 제품팀이 테스트 환경을 QA 전담 문제로 보는 문화
  • known flaky가 승인 없이 계속 유지되는 상태
  • audit trail 없이 hotfix 예외가 반복되는 운영
  • agent repair가 사실상 무제한 self-approve 통로가 되는 구조

권장 문화

거버넌스의 목표는 승인 단계를 늘리는 게 아니라 누가 무엇을 바꿀 수 있고 어떤 evidence가 release 판단을 떠받치는지 분명히 하는 데 있습니다.

관련 문서

테스트 하네스 엔지니어링

테스트 코드를 넘어 환경 제어, 증거 수집, 재현성, agent repair boundary를 묶는 테스트 하네스 설계 원칙과 패키지 구조

테스트 포트폴리오 운영 모델

어떤 시나리오를 browser, API, workflow, canary probe로 나누고 어느 tier를 게이트에 올릴지 정하는 운영 표준

시나리오: 결제·정산 팀

하네스 엔지니어링 · 결제·정산 도메인에서 하네스가 승인, 정합성 검증, 감사 추적, rollback 시스템으로 작동하는 방식을 설명합니다.

승인형 백오피스 자동화

Vercel 엔터프라이즈 AI 플랫폼 · approval event, operator identity, side effect 통제를 포함한 백오피스 자동화 패턴을 정리합니다.

도메인별 적용 지도

하네스 엔지니어링 · 프론트엔드 팀, 플랫폼 팀, 결제·정산 팀, AI 제품 팀이 하네스를 어떻게 다르게 설계해야 하는지 안내합니다.

테스트 인시던트 대응

gate failure를 릴리즈 판단 시스템 인시던트로 다루고 triage, release hold, rollback을 연결하는 방법

런북 템플릿

incident, nondeterminism, release evidence, 신규 서비스 onboarding에 바로 쓸 수 있는 운영 템플릿

On this page

ownership 구조CODEOWNERS 권장 범위변경 승인 규칙보안과 개인정보audit trail에 남겨야 할 기록분기 리뷰 루틴anti-pattern