AI QA Workflow 설계: 기획서에서 리포트까지

Claude Code와 Antigravity를 같은 기준으로 적용하며 확인한 설계 기준과 한계

지난 글에서는 기획서와 프롬프트를 기반으로 Antigravity에 브라우저 QA를 위임하는 구조를 시험했습니다. 당시 Antigravity는 화면 검수에 그치지 않고 CSP 차단이나 정규식 파싱 누락 같은 실패 원인까지 분석해 리포트로 정리했고, 글 말미에 같은 서비스를 Claude Code로도 검증해 보겠다고 적었습니다.

이번 글은 그 후속입니다. 다만 진행해 보니 도구 비교보다 중요한 결과가 남았습니다.

기획서에서 TC(Test Case)를 도출하고, 사람이 검수한 뒤, AI가 실제 브라우저에서 실행하고, 결과 리포트까지 산출하는 하나의 QA Workflow를 상시 운영 가능한 형태로 만들 수 있는지 검증한 것이 실제 과제였습니다.

결론부터 정리하면 다음과 같습니다.

• 판정 기준을 사람이 문서로 고정하지 않으면, 어떤 도구를 쓰든 결과를 신뢰할 수 없었습니다.
• 화면 계층 검증에서는 결함이 드러나지 않았지만, 검증 범위를 네트워크와 파라미터까지 넓히자 고유 결함 5건이 나왔습니다.
• 결과적으로 남은 자산은 리포트가 아니라 재사용 가능한 TC 문서와 실행 규칙이었습니다.

1. 도구를 고르기 전에 Workflow를 먼저 설계했습니다

대상은 신규 KPI BI 서비스의 Front와 Admin 전체였습니다. 변경분 검수가 아니라 신규 구축 전체 범위가 대상이었고, Front는 필터·차트·피벗·다운로드·URL 파라미터가 얽혀 있었으며 Admin은 관리자 권한에 따라 노출 화면과 실행 가능한 기능이 달랐습니다.

전체 흐름은 다섯 단계로 구성했습니다.

기획서·데이터 명세 입력 → AI로 TC 도출 → 담당자가 TC와 실행 범위 검수 → AI 에이전트가 브라우저에서 QA 실행 → 결과 리포트 생성 및 최종 판정

이 중 실제로 품질을 좌우한 것은 3단계(검수)였습니다. AI가 만든 TC를 그대로 실행하지 않고, 아래 세 가지를 사람이 먼저 확정했습니다.

① 판정 가능 영역과 불가 영역을 분리했습니다. 모든 TC에 검증 방식(화면 / 수동 확인 / BE 확인)을 명시했습니다. 집계 로직 정합성, 부가세 적용, 이메일 발송처럼 화면만으로 단정할 수 없는 항목을 처음부터 자동 QA 범위 밖으로 뺐습니다. 이 구분이 없으면 AI는 판정 불가 항목을 임의로 통과 처리하거나, 반대로 정상 동작을 실패로 기록합니다.

② 권한 분기를 실행 회차로 바꿨습니다. Admin은 통합 관리자와 IP 관리자에 따라 화면 자체가 달라, 한 세션에서 섞으면 판정 기준이 무너집니다. 모든 TC에 대상 권한 컬럼을 붙이고 계정을 바꿔 2회차로 나눠 실행하도록 설계했습니다. 회차별 대상 TC 수와 기대 결과를 문서에 미리 박아두니, 실행 단계에서 AI가 로그인한 계정의 권한을 화면 근거로 스스로 판별하고 해당 회차 TC만 수행했습니다.

③ 데이터 변경 지점에 사전 승인 규칙을 넣었습니다. 저장·등록·수정·삭제·권한 부여는 실행 전 반드시 멈추고 확인받도록 명시했습니다. 조회·렌더링·필터·유효성 문구 확인 같은 비파괴 동작만 무확인 실행 대상으로 뒀습니다.

세 가지의 공통점은 “AI가 알아서 잘하기를 기대하는 대신, 사람이 실행 가드레일을 문서로 만들어 넘겼다”는 것입니다. 자동화 품질과 안전성에 가장 크게 기여한 부분이 여기였습니다.

2. 같은 서비스, 다른 깊이

Front QA에서 두 도구의 차이는 숫자로 드러났습니다.

먼저 짚어야 할 것은, 이 표가 정량 벤치마크가 아니라는 점입니다. 같은 기획서를 줬는데도 두 도구가 뽑은 TC 개수와 세분화 수준이 31건과 97건으로 3배 이상 벌어졌습니다. 통과율끼리 직접 비교하는 것은 의미가 없고, 이 차이 자체가 첫 번째 관찰 대상입니다.

Antigravity — 전체 상태를 빠르게 확인했습니다

30분 안에 Front 전 범위를 훑었습니다. 스크립트가 DOM Selector로 차트를 찾지 못해 WARN을 무더기로 뱉었을 때, 스크린샷 30여 장을 AI Vision으로 다시 판독해 실제 렌더링이 정상임을 확인하고 PASS로 뒤집었습니다. 주요 화면이 열리는지, 큰 흐름이 막히지 않는지를 판단하는 데는 충분했습니다.

다만 화면이 정상으로 보인다고 기능까지 정상은 아니었습니다. FAIL 0건이라는 결과는 “결함이 없다”가 아니라 “화면 계층에서는 결함이 보이지 않는다”로 읽어야 했습니다.

Claude Code — 화면 밖의 실패를 찾았습니다

2시간이 걸렸지만 네트워크 요청과 API 응답 바디, URL 파라미터, 예외 처리까지 확인했습니다. 발견한 5건 가운데 일부는 화면만으로는 성공 여부나 원인을 판단하기 어려운 유형이었습니다.

• 다운로드가 실패해도 화면에는 표시되지 않음: 버튼은 동작하고 서버도 HTTP 200으로 응답했지만, 응답 바디에는 필수 파라미터 누락 오류가 담겨 있었고 파일은 생성되지 않았습니다. 화면에는 아무 안내도 뜨지 않았습니다. 특정 컴포넌트를 제외하면 정상 파일이 반환되는 것까지 비교 확인해 원인을 격리했습니다.
• URL 파라미터 sanitize 미동작: 잘못된 날짜 값을 URL에 직접 주입하자 기본값 보정 없이 오버플로우 값으로 파싱됐습니다. 사람이 수동 QA에서 잘 시도하지 않는 케이스입니다.
• 화면 결함의 원인 범위 좁히기: 상품명이 [NAME] 리터럴로 노출되는 문제는 화면만 봐도 보이는 결함이지만, 두 개 화면에서 같은 패턴으로 재현되는 것을 확인해 개별 화면이 아닌 공통 로직 문제일 가능성까지 좁혔습니다.

세 사례의 성격은 서로 달랐지만, 화면 확인에 요청·응답 추적을 더하면서 재현 조건과 원인 범위를 좁힐 수 있었다는 점은 같았습니다.

같은 화면을 두고 판정이 엇갈린 사례도 있었습니다

Admin QA에서 한 도구는 통합 관리자 계정의 특정 메뉴가 노출되지 않는다며 이를 최상위 등급 결함으로 기록했습니다. 다른 도구는 같은 항목을 정상으로 판정했습니다. 사람이 직접 확인한 결과 정상이 맞았고, 결함 보고 쪽이 오탐이었습니다.

자동 QA 결과에 오탐이 섞인다는 사실 자체보다, 그것이 “Blocker”라는 최고 심각도로 리포트에 올라왔다는 점이 중요합니다. 그대로 개발팀에 전달됐다면 존재하지 않는 버그를 쫓는 데 시간을 썼을 것입니다. AI 리포트를 그대로 전달하지 않고 사람이 최종 판정하는 단계가 왜 워크플로우에 반드시 남아야 하는지를 보여준 사례였습니다.

정리하면 우열이 아니라 역할 차이였습니다. Antigravity는 빠른 전체 점검(Smoke Test), Claude Code는 느리지만 깊은 검증(Deep QA)에 적합했습니다. 이번 조건에서는 Claude Code를 정식 QA의 중심에 두고, 시간이 제한된 사전 점검에 Antigravity를 병행하는 구성이 가장 현실적이었습니다.

3. 운영하며 부딪힌 마찰과 대응

테스트 조건을 실행 전에 확정해야 합니다

QA 당일 공유받은 테스트 데이터 범위를 최초 프롬프트에 반영하지 못해, 실행 중간에 전달하며 일부 항목을 다시 검증했습니다. 토큰과 시간이 그대로 낭비됐습니다.

다음 실행부터는 아래를 사전 확정 항목으로 고정했습니다.

• 테스트 계정과 권한
• 검증 가능한 서비스·기간·데이터 범위
• 데이터가 없는 것이 정상인 케이스
• 화면 / 수동 / BE 확인 영역 구분
• 등록·수정·삭제 허용 범위
• 이번 QA 제외 항목

이 조건이 불분명하면 AI도 헤매고, 시간과 토큰도 함께 산책을 나갑니다.

승인 요청과 안전장치는 둘 다 조정 대상이었습니다

두 도구 모두 실행 중 사람에게 확인을 요구하는 빈도가 높아 흐름이 자주 끊겼습니다. Claude Code는 승인 모드를 자동 모드로 올려, Antigravity는 /goal 명령으로 목표를 고정해 해소했습니다. 다만 이건 편의성과 통제력의 교환이라, 데이터 변경 방지 규칙이 문서로 확보된 뒤에 승인 단계를 낮추는 순서를 지켜야 합니다.

반대 방향의 마찰도 있었습니다. 중복 코드를 일부러 입력해 예외 처리를 검증하려는 시도처럼, 정상적인 QA 입력이 데이터 변경이나 민감정보 입력으로 오인돼 차단되는 경우가 있었습니다. 대체 테스트 값으로 재검증하거나 해당 항목을 수동 검증으로 전환해 처리했습니다.

가드레일은 과탐과 항상 트레이드오프입니다. 자동화로 무리하게 뚫기보다 막힌 항목만 수동으로 넘기는 편이 결과적으로 빨랐습니다.

설계와 실행에 적합한 모델이 달랐습니다

요구사항 해석과 엣지 케이스 발굴이 핵심인 TC 설계 단계에서는 추론 성능이 높은 모델(Opus, Gemini High)이 유리했습니다. 반면 확정된 TC를 순서대로 밟는 실행 단계에서는 Sonnet이 더 안정적이었습니다.

상위 모델은 실행 중에도 TC를 지시가 아니라 검토 대상으로 취급합니다. “이 TC가 맞나, 더 나은 경로가 있지 않나”를 재평가하면서 절차를 이탈하고, 시간과 토큰을 더 씁니다. 능력 부족이 아니라 자율성 과잉입니다. 실행은 판단을 덜 할수록 잘 되는 작업이라 이 맥락에서는 강점이 단점이 됩니다.

프롬프트로 “TC를 재평가하지 말고, 판정 근거가 부족하면 BLOCK 또는 확인 불가로 기록한 뒤 진행”을 강하게 걸면 완화되긴 합니다. 다만 그렇게까지 눌러 쓸 거면 처음부터 Sonnet이 비용·속도 면에서 낫습니다. 참고로 Antigravity도 낮은 추론 수준에서는 작업이 제대로 진행되지 않아 High로 올린 뒤에야 안정적으로 실행됐습니다.

본 실행 전에 대표 TC 몇 개로 모델과 추론 수준을 먼저 확인하는 절차를 넣는 것이 좋습니다.

AI가 TC를 임의로 요약하지 않게 해야 합니다

AI는 비슷한 항목을 묶어 효율적으로 처리하려는 경향이 있습니다. 일반 업무에서는 영리한 최적화지만 QA에서는 TC와 결과의 1:1 대응이 깨집니다. 실제로 초기 실행에서 28개 TC가 10여 개 로그로 뭉쳐 나와 문서와 대조가 불가능했습니다.

프롬프트에 다음을 명시했습니다.

• 모든 TC를 생략 없이, TC별 개별 로그로 실행할 것
• TC별 PASS/FAIL/BLOCK을 기록할 것
• 실행하지 못한 항목을 임의로 PASS 처리하지 말 것
• 데이터 변경 전에는 멈추거나 Safe Mode를 적용할 것

QA에서는 빠르게 끝내는 것보다 무엇을 검증했고 무엇을 검증하지 못했는지 추적 가능한 것이 더 중요합니다.

4. 남은 자산은 리포트가 아니라 TC였습니다

이번 작업에서 가장 오래 남을 산출물은 결과 리포트가 아닙니다.

• 판정 기준(화면/수동/BE)이 구분된 TC 문서
• 권한별 실행 회차 규칙
• 데이터 변경 방지 조항이 포함된 실행 프롬프트

리포트는 이번 릴리즈에서 소비되고 끝나지만, 위 세 가지는 다음 릴리즈에 그대로 재투입되는 회귀 테스트 자산입니다. 기능이 추가되면 해당 영역 TC만 증분 수정하면 됩니다. 실제로 이번에도 필터 유효성 검증 시점이 바뀌는 기획 변경이 있었을 때, 전체를 재생성하지 않고 영향받는 TC만 수정·신설하고 변경 리포트를 붙이는 방식으로 처리했습니다.

AI QA를 1회성 실험이 아니라 상시 운영으로 만드는 조건이 이것이라고 봅니다. 실행을 자동화하는 것이 아니라, 판정 기준을 자산으로 축적하는 것.

5. AI QA는 수동 QA를 어디까지 대체할 수 있을까

완전 대체는 아직 어렵습니다. 원천 데이터와 화면 수치의 정합성, 권한별 예외, 실제 등록·수정·삭제, 이메일 발송, 서버 집계 로직은 사람이나 BE 확인 영역으로 남았습니다. 이번에도 97개 TC 중 28개는 데이터·계정 제약이나 BE 스코프로 화면 QA에서 판정할 수 없었습니다. 여기에 앞서 본 오탐 사례까지 더하면, 최종 판정은 담당자 몫이라는 결론은 당분간 바뀌지 않을 것 같습니다.

그럼에도 AI가 맡을 수 있는 범위는 생각보다 넓었습니다.

• 기획서 기반 TC 초안 작성
• 반복적인 화면·권한별 검증
• 전체 기능의 빠른 사전 점검
• 네트워크·로그 기반 실패 원인 추적
• 재현 절차와 리포트 초안 작성

사람은 기준과 범위를 정하고 애매한 결과를 판단하는 데 집중하고, AI는 반복 실행과 기록을 담당하는 구조가 현실적이었습니다.

앞으로는 다음을 기본 흐름으로 운영할 계획입니다.

상위 추론 모델로 TC 설계 → 담당자 검수와 테스트 데이터 확정 → Claude Code 중심 심층 QA → 필요시 Antigravity로 빠른 사전 점검 → 사람이 데이터 정합성·권한·BE 영역 보완 → 확정 TC를 회귀 테스트에 재사용

이번 작업 전까지 AI QA는 필요한 기능에 한 번씩 적용해 보는 도구에 가까웠습니다. Front와 Admin 전체에 적용한 뒤 판단이 바뀌었습니다. 아주 단순한 수정 건을 제외하면, 앞으로 대부분의 기능 개발·개선 업무에 이 Workflow를 상시 적용할 계획입니다.

AI QA의 가치는 사람을 빼는 데 있지 않았습니다. 반복 검증과 기록을 넘기고, 사람이 판단해야 할 것에 집중하게 만드는 데 있었습니다.

도구는 계속 바뀌겠지만, 기획서 → TC → 사람 검수 → AI 실행 → 결과 리포트라는 흐름과 그 과정에서 쌓이는 TC 자산은 꽤 오래 쓸 수 있을 것 같습니다.