최근 공개 저장소 Agent Skill Garden에 브라우저 E2E 검증 스킬 두 개를 추가했다.

  • e2e-test-design: 코드 변경과 위험을 실행 가능한 브라우저 시나리오로 바꾼다.
  • browser-e2e-check: 시나리오 하나를 실제 환경에서 실행하고 근거와 함께 판정한다.

처음에는 하나의 스킬로도 충분해 보였다. 변경 파일을 읽고, 확인할 경로를 찾고, 브라우저를 열어 테스트한 뒤 결과를 남기면 된다. 하지만 이 흐름에는 서로 다른 판단이 섞여 있었다.

무엇을 검증할 것인가와 실제로 검증했는가는 다른 문제다.

설계와 실행을 분리했다

e2e-test-design은 코드를 수정하지도, 브라우저를 실행하지도 않는다. 변경된 코드와 소비 경로를 보고 다음을 정한다.

  • 어떤 사용자 흐름이 영향을 받는가
  • 실패 가능성이 큰 지점은 어디인가
  • 어떤 환경과 사전 조건이 필요한가
  • 무엇을 관찰해야 통과 또는 실패로 판단할 수 있는가

이 결과를 받은 browser-e2e-check는 한 번에 하나의 환경과 하나의 시나리오만 실행한다. 로컬, 배포 환경, 운영 환경을 한 결과 안에 섞지 않는다. 배포 환경에서는 확인하려던 리비전이 실제로 반영됐다는 근거도 필요하다.

이렇게 나누니 테스트 계획은 구현과 독립적으로 검토할 수 있고, 실행 결과는 처음 세운 기준과 대조할 수 있게 됐다.

성공을 추정하지 않는다

실행 결과는 세 가지뿐이다.

  • PASS: 필요한 단계와 관찰 결과가 모두 확인됐다.
  • FAIL: 기대 동작과 다른 결과를 재현했다.
  • BLOCKED: 인증, 브라우저 제어, 배포 확인 등 필요한 조건이 없어 판정할 수 없다.

중요한 것은 BLOCKED다. 브라우저를 제어할 수 없는데 HTTP 응답만 보고 화면이 정상이라고 말하거나, 로그인이 필요한 흐름을 추측으로 통과시키지 않는다. 실행 근거가 부족하면 실패가 아니라 판정 불가로 남긴다.

운영 환경은 기본적으로 관찰만 허용한다. 데이터를 바꾸는 행동과 외부 시스템에 증거를 게시하는 행동도 각각 별도의 승인이 필요하다. 테스트를 자동화하더라도 실행 권한까지 자동으로 넓어져서는 안 되기 때문이다.

공개 저장소에 넣었다

이번 작업은 PR #2로 병합했다. 저장소 검증에서는 14개 스킬, 16개 라우팅 사례, 6개 단위 테스트와 공개 안전성 검사를 통과했다. Claude Code와 Codex가 사용하는 스킬 경로에도 선택 설치와 재설치를 확인했다.

설치와 구조는 저장소 README에서 볼 수 있다. 특정 서비스의 경로나 계정, 테스트 데이터는 포함하지 않았다. 각자의 프로젝트에 맞는 경로와 시나리오만 설계 단계에서 채우면 된다.

마치며

E2E 자동화의 완성도는 브라우저를 얼마나 많이 움직이는지로만 결정되지 않는다. 무엇을 확인해야 하는지 먼저 정하고, 근거가 없을 때 성공이라고 말하지 않는 것이 더 중요하다.

이번에는 실행 기능을 늘리는 대신 판단의 경계를 먼저 적었다. 테스트를 설계하는 일과 실행하는 일을 분리하니, 자동화가 더 빨라졌다기보다 결과를 믿을 수 있는 조건이 분명해졌다.