CSP 차단까지 스스로 짚어낸 AI QA 에이전트: Antigravity 실무 후기
QA는 늘 필요하지만, 늘 손이 많이 갑니다.
새 기능을 배포하기 전에는 기획 의도대로 화면이 구현되었는지, 문구가 맞는지, 예외 케이스가 빠지지 않았는지 확인해야 합니다. 관리자 설정까지 포함되면 확인 범위는 더 넓어집니다.
이번에는 이 과정을 조금 다르게 해봤습니다.
기획서를 기반으로 Gemini에게 먼저 QA 프롬프트 작성을 요청하고, 몇 차례 기준을 다듬은 뒤, 그 프롬프트를 Antigravity에 그대로 입력해 실제 브라우저 기반 QA를 진행했습니다.
결론부터 말하면, 기대 이상이었습니다.
좋은 기획서와 명확한 프롬프트만 있다면, Antigravity는 QA 리포트 초안까지 꽤 손쉽게 뽑아낼 수 있었습니다. 그리고 그 과정에서 단순 자동화 도구와는 결이 다른 장면들을 몇 번 목격했습니다.
기획서와 프롬프트만으로 시작했습니다
이번 QA 흐름은 생각보다 단순했습니다.
먼저 Gemini에게 이렇게 요청했습니다.
“이 기획서를 기준으로 Antigravity에서 QA를 진행할 수 있게 도와줘.”
그다음 기획서를 함께 전달하고, 어떤 화면을 확인해야 하는지, 어떤 기준으로 PASS/FAIL/BLOCK을 나눌지, 결과 리포트는 어떤 형식이면 좋을지 몇 차례 조정했습니다.
이후 정리된 프롬프트를 Antigravity에 그대로 입력했습니다.
흐름을 단순화하면 이렇습니다.
기획서 전달 → Gemini로 QA 프롬프트 정리 → Antigravity에 프롬프트 입력 → 실제 브라우저 기반 QA 실행 → Markdown QA 리포트 생성
이번 기능은 화면과 예외 케이스가 꽤 복잡한 편이었지만, 전체 흐름 자체는 생각보다 간단했습니다. 이전에 다른 QA 건에서도 비슷한 방식으로 좋은 결과를 얻은 적이 있어서, 이번 경험이 단순한 우연만은 아니라고 느꼈습니다.
인상적이었던 순간 ①: “안 된다”가 아니라 “왜 안 되는지”를 말해줬습니다
보통의 자동화 도구는 스크립트가 막히면 “Element Not Found” 같은 에러를 뱉고 멈춥니다. 그런데 이번 QA에서는 다른 장면을 봤습니다.
테스트 중 특정 플레이어 영역이 렌더링되지 않는 현상이 발생했는데, Antigravity는 단순히 FAIL로 기록하고 넘어가지 않았습니다. 브라우저 콘솔 로그와 네트워크 요청을 스스로 확인한 뒤, CSP(Content Security Policy) 제약으로 외부 iframe 도메인이 차단되어 발생한 문제라고 원인을 짚고, 도메인 예외 처리라는 해결 방향까지 리포트에 함께 적어냈습니다.
화면 비교 수준을 넘어, URL에서 특정 ID를 추출하는 정규식 파싱 누락 같은 로직 단위의 오류까지 잡아내는 걸 보면서, 결함을 “발견”하는 도구가 아니라 “분석”까지 하는 도구라는 인상을 받았습니다. 개발팀에 전달할 때 재현 조건과 원인 가설이 함께 정리되어 있으니, 커뮤니케이션 비용이 눈에 띄게 줄었습니다.
인상적이었던 순간 ②: 막힌 곳은 사람이 뚫고, 검수는 AI가 이어갑니다
물론 모든 과정이 완전 자동으로 매끄럽게 흘러가지는 않았습니다.
React 기반 SPA 특성상 렌더링될 때마다 DOM 엘리먼트 식별자가 동적으로 바뀌어서, 에이전트가 클릭할 버튼을 찾지 못하고 헤매는 구간이 있었습니다.
이때 자동화 스크립트를 고치는 대신, 제가 직접 해당 화면까지 진입해 ‘길’을 열어준 뒤 이렇게 지시했습니다.
“앞 단계는 건너뛰고, 지금 띄워진 화면부터 이어서 검수해 줘.”
에이전트는 즉시 상황을 인지하고 다음 스텝부터 QA를 재개했습니다. 사람이 병목을 해소하고 AI가 반복 검수를 이어가는, 실무에서 통하는 Human-in-the-Loop의 형태였습니다. “전부 자동이냐”보다 “막혔을 때 얼마나 유연하게 협업이 되느냐”가 실무 도입의 관건이라는 걸 이 구간에서 배웠습니다.
결과물: 공유 가능한 수준의 리포트
테스트가 끝난 후 산출된 Markdown 리포트는 별도 가공이 거의 필요 없는 수준이었습니다.
- 전체 항목에 대한 명확한 판정 (PASS/FAIL/BLOCK)
- 실패 사유를 기획서 기준으로 정리 (문구 불일치, 툴팁 미노출, URL 입력 오류 등)
- 개발팀이 참고할 수 있는 개선 방향 제안
- 에러 화면 스크린샷 및 검수 과정 기록
수십 페이지짜리 엑셀 시트에 스크린샷을 일일이 캡처해 붙여 넣던 기존 방식과 비교하면, 리포트 작성 리소스 자체가 크게 달라졌습니다.
QA도 이제 프롬프트로 쉽게 시작할 수 있습니다
이번 경험을 통해 확실히 느꼈습니다.
QA는 더 이상 사람이 처음부터 끝까지 모든 화면을 클릭하며 정리해야만 하는 작업은 아닙니다. 좋은 기획서가 있고, 검수 기준을 프롬프트로 잘 정리할 수 있다면, Antigravity는 꽤 강력한 QA 파트너가 될 수 있습니다.
물론 최종 판단은 사람이 해야 합니다. AI가 만든 리포트는 그대로 믿기보다, 기획 의도와 실제 구현 맥락에 맞게 다시 확인해야 합니다. 하지만 반복적인 1차 검수, 문구 확인, 화면별 체크, 실패 사유 정리, 개발팀 전달용 리포트 초안 작성까지는 충분히 맡겨볼 만합니다.
요약하면 이렇습니다.
기획서가 있습니다.
프롬프트를 정리합니다.
Antigravity에 실행시킵니다.
QA 리포트가 나옵니다.
복잡한 자동화 테스트 코드를 작성하지 않아도, 누구나 기획서와 Antigravity로 QA 리포트 초안까지 뽑아볼 수 있습니다.
Next Step: 다른 에이전트와의 비교 실험
사실 브라우저 기반 QA는 다른 AI 도구들로도 몇 차례 시도해 봤습니다. 다만 제가 기존에 시도했던 방식에서는, 같은 프롬프트만으로 실제 브라우저 QA와 공유 가능한 리포트 생성까지 매끄럽게 이어지지는 않았습니다. 반면 Antigravity는 이번 케이스에서 잘 정리된 프롬프트만으로 팀에 바로 공유할 수 있는 리포트 초안까지 도달했습니다. 다만 아직 동일한 조건에서 정량적으로 비교한 것은 아니라서, 이 부분은 후속 실험으로 좀 더 확인해 보려고 합니다.
그래서 지금 동일한 기획서를 두고 Claude Code와 Antigravity에 각각 QA를 맡겨 결과물 퀄리티를 비교하는 실험을 실무에서 진행 중입니다. 두 에이전트로 돌릴 TC(Test Case)는 이미 뽑아둔 상태이고, 이제 한쪽은 Claude Code로, 다른 한쪽은 Antigravity 에이전트로 실제 E2E 실행만 하면 결과가 나옵니다. 같은 입력에서 어떤 도구가 어떤 유형의 QA에 강한지, 특히 ‘추가 가공 없이 바로 공유 가능한가’를 기준으로 비교한 데이터를 후속 포스팅에서 공유하겠습니다.
