Cypress가 AI 기반 코딩 에이전트가 실행 중인 Cypress 테스트 세션에 연결하여 DOM 스냅샷과 명령 로그를 가져오고, 이러한 시각적 정보를 사용하여 실패 원인을 진단할 수 있게 해주는 tap이라는 베타 기능을 출시했습니다. 이 도구는 Cypress 15.21.0 이상, Chromium 기반 브라우저, 그리고 "cypress open" UI에서만 작동하며, headless 모드에서는 실행되지 않습니다.
AI 에이전트에게 종료 코드(exit code) 이상의 것이 필요한 이유
대부분의 AI 코딩 어시스턴트는 Cypress 실행을 일반적인 명령줄 도구처럼 취급합니다. 즉, npx cypress run을 실행하고, 프로세스의 종료 상태를 읽은 뒤, 테스트 통과 여부를 결정합니다. 종료 코드는 에이전트에게 무언가 잘못되었다는 사실은 알려주지만, 셀렉터(selector)가 잘못 입력되었는지, 페이지 로드에 실패했는지, 아니면 오버레이가 버튼을 가로막고 있는지에 대한 단서는 제공하지 않습니다. 반면, 사람은 Cypress UI를 열고 브라우저를 관찰하며, DOM 트리를 검사하고, 명령 로그를 읽은 후에야 가설을 세웁니다.
이러한 격차는 자동화된 디버깅을 불안정하게 만듭니다. "Element not found"는 수십 가지의 근본 원인에서 비롯될 수 있으며, 시각적 증거가 없다면 AI는 동일한 수정 사항을 계속 시도하며 끝없이 루프에 빠질 수 있습니다.
tap이 격차를 해소하는 방법
Tap은 실행 중인 Cypress 인스턴스에 대한 터미널 기반 인터페이스를 생성합니다. 개발자가 open 모드로 Cypress를 실행하면:
npx cypress open --e2e --browser=chrome
에이전트는 별도의 셸에서 일련의 JSON 출력 명령을 내릴 수 있습니다:
npx cypress tap specs --json– 사용 가능한 spec 파일 목록을 나열합니다.npx cypress tap run <spec> --json– 단일 spec 실행을 시작합니다.npx cypress tap status --json– 타임스탬프를 포함하여 현재 실행 상태를 반환합니다.
상태 페이로드에 startedAt 타임스탬프가 포함되어 있기 때문에, 에이전트는 자신이 보고 있는 결과가 이전에 종료된 오래된 결과가 아니라 최신 결과임을 확인할 수 있습니다. 단순히 원시 종료 코드에만 의존하는 것은 더 이상 충분하지 않습니다.
테스트가 실패하면 에이전트는 더 깊이 파고들 수 있습니다:
npx cypress tap reporter --json– 전체 테스트 보고서를 가져옵니다.npx cypress tap command --test-id <ID> --command-id <ID> --json– 오류가 발생한 정확한 명령과 함께, 그 시점의 앱 DOM, ARIA 트리 및 관련 요소 속성의 스냅샷을 가져옵니다.
해당 스냅샷을 통해 AI는 셀렉터가 왜 일치하지 않았는지, 페이지가 여전히 로딩 중이었는지, 아니면 모달이 대상을 가리고 있었는지 등을 추론할 수 있습니다. 그런 다음 코드 변경을 제안하고, 이를 적용한 뒤 동일한 spec을 다시 실행하여 수정 사항을 검증할 수 있습니다.
자율 에이전트를 위한 안전 정책
루프가 무한히 반복되는 것을 방지하기 위해 Cypress 팀은 절제된 워크플로우를 제안합니다:
- 단 하나의 특정 spec 파일만 실행합니다.
- 엄격한 마감 시간을 두고
tap status를 폴링하며,startedAt이 마지막 폴링보다 오래된 결과는 무시합니다. - 실패한 테스트와 문제가 된 명령만 검사합니다.
- 다음 실행 전에 단 한 번의 코드 수정을 허용합니다.
- spec을 다시 실행합니다.
- 결과가 바뀌면 중단하고 검토를 위해 사람에게 알립니다.
에이전트는 또한 자신이 관찰한 내용과 제안된 수정 사항이 왜 작동해야 하는지에 대해 자연어로 된 설명을 생성해야 합니다. 단순히 테스트를 통과하는 것만으로는 부족합니다. AI는 시각적 증거를 이해했음을 증명해야 합니다.
누가 이득을 보는가
이미 코드 생성을 위해 AI 어시스턴트에 의존하는 개발자들은 이제 해당 어시스턴트에게 더 풍부한 디버깅 환경을 제공할 수 있습니다. 기대되는 이점은 특히 실패를 수동으로 재현하는 데 몇 분이 걸릴 수 있는 대규모 엔드 투 엔드(end-to-end) 테스트 세트에서, 불안정한(flaky) 테스트를 추적하는 데 소비되는 시간을 줄이는 것입니다. tap을 도입하는 팀은 UI 컴포넌트를 수정하는 풀 리퀘스트(PR)의 처리 속도가 빨라지고, 디버깅을 위한 반복적인 소통이 줄어드는 것을 경험할 수 있습니다.
위험 및 한계
Tap은 아직 베타 단계이므로 버그가 있을 수 있고, 명령 구문이 변경되거나 특정 구성에 대한 지원이 예고 없이 중단될 수 있습니다. open UI에 의존하기 때문에 headless CI 파이프라인은 제외되며, 따라서 팀은 자동화된 빌드를 위한 별도의 전략이 필요합니다. 이 기능은 실시간 DOM 데이터를 스트리밍하므로, 대규모 spec의 경우 성능 오버헤드가 발생하여 속도가 느려질 수 있습니다. 마지막으로, 안전 정책은 AI가 마감 시간을 준수하고 단 한 번의 변경 후 중단할 수 있음을 가정합니다. 잘못 설계된 에이전트는 여전히 무한 루프에 빠지거나 잘못된 수정을 적용할 수 있습니다.
향후 주목할 점
- 베타 피드백 사이클 – Cypress는 초기 사용자의 피드백을 바탕으로 JSON 스키마를 개선하고 더 세분화된 명령어를 추가할 가능성이 높습니다.
- CI 통합 – 가상 디스플레이를 생성하는 등의 방식으로 tap의 open-mode 요구 사항과 headless runner를 연결하는 커뮤니티 스크립트가 등장할 것으로 예상됩니다.
- AI 에이전트 툴링 – 코딩 어시스턴트를 개발하는 벤더들이 tap 지원을 기본 디버깅 모듈로 포함하기 시작하면서, 주요 IDE 확장 프로그램에서 이 기능을 더 쉽게 접할 수 있게 될 것입니다.
AI 기반 테스트 유지보수를 실험 중이라면, 단일 flaky spec에 tap을 적용하여 시각적 컨텍스트가 디버깅 사이클을 단축하는지 확인해 보세요. 이 도구가 인간의 판단을 대체하지는 않겠지만, 코딩 에이전트에게 이전에는 없던 '눈'을 제공해 줄 것입니다.