저는 Claude Code의 로컬 녹색 실행(green run)을 초기 신호로 활용하기 시작했습니다. 다음으로 제가 하는 것은 병합(merging) 전에 미리 배포된 환경에 대한 별도의 검사를 추가하는 것입니다. UI가 많은 변경 사항에 대한 현재 흐름은 다음과 같습니다: Claude Code가 변경 사항을 만들고, 미리보기 URL이 배포되며, testsprite CLI가 라이브 URL을 대상으로 실행됩니다. Claude는 실패 번들(failure bundle)과 패치(patches)를 받습니다. 이것은 할당 요청 흐름(assignup flows), 설정 페이지, CRUD 화면, 역할 기반 리디렉션 등 지루한 부분에서 가장 유용했습니다. 구현이 diff 상으로는 괜찮아 보이고, 단위 테스트(unit tests)도 통과했지만, 배포된 앱에 깨진 라우트, 누락된 환경 변수(env var), 잘못된 셀렉터(selector), 또는 프론트엔드/백엔드 불일치 문제가 있는 경우입니다. 설정을 위해 CLI는 Apache 2.0 라이선스를 따르며, 여기에서 확인할 수 있습니다: github.com/TestSprite/testsprite-cli. Node 20 이상이 필요합니다. testsprite 설정은 일회성 설정을 처리하고, API 키를 요청하며, Claude Code가 호출할 수 있도록 에이전트 스킬 파일(agent skill file)을 설치합니다. 계획해 둘 만한 한 가지 세부 사항이 있습니다: 브라우저/API 실행은 그들의 호스팅 서비스에서 이루어집니다. 무료 계정과 API 키가 필요합니다. 이 측면은 자체 호스팅(self-hostable)할 수 없으므로, 엄격한 미리보기 환경 정책을 가진 팀은 이를 일찍 확인해야 합니다. 출력 형식은 제가 이것을 계속 루프에 유지하는 주요 이유입니다. 실패할 경우, 실패한 단계, 스크린샷, DOM, 근본 원인 추측(root-cause guess), 그리고 권장 수정 사항을 하나의 번들로 반환합니다. Claude는 보통 이 정보만으로도 무작정 추측하기보다는 더 작은 패치를 만들 충분한 컨텍스트를 갖게 됩니다. 저는 여전히 일반 단위 테스트와 검토 과정을 유지하고 있습니다. 이것은 AI가 작성한 UI 변경 사항을 병합하기 전의 최종 '배포된 것을 클릭해 보는' 계층입니다.
/u/rHrCypher 제출 [link] [comments]