기획서 하나로 결함 등록까지, QA AI Hub를 만들며 배운 것

새 과제의 기획 리뷰가 잡혔습니다. 회의실에 개발자, 디자이너, QA가 모이고, 기획자가 화면을 넘기며 새 기능을 설명합니다. 1년 전이라면 QA는 리뷰가 끝난 뒤 며칠 동안 스프레드시트를 열어 TC를 한 줄씩 써 내려갔을 겁니다. 지금은 리뷰가 끝나면 기획서를 QA AI Hub에 넣고, AI가 정리해 둔 PM 문의표와 테스트 설계 초안을 검토하는 것으로 준비를 시작합니다.

안녕하세요, 컬리 프로덕트SQE 트라이브 리더 박상현입니다. 저희 트라이브는 커머스와 물류 두 도메인의 QA를 맡고 있습니다.

QA 일을 오래 해 오면서 늘 걸리던 것이 있었습니다. 테스트를 준비하는 데 테스트하는 만큼의 시간이 든다는 점이었죠. 올해 1월 이 시간을 AI로 줄여 보자는 프로젝트를 시작했고, 9개월 뒤 기획서 하나로 결함 등록까지 이어지는 사내 플랫폼 QA AI Hub가 나왔습니다. 커머스와 물류 QA 구성원 모두가 실제 과제에 적용하며 TC를 다듬고 실행 결과를 검증해 온 덕분입니다.

이 글에서는 무엇을 자동화했는지, AI가 만든 TC를 어떻게 믿을 수 있게 만들었는지, 그리고 그 과정에서 다섯 번 구조를 바꾸며 배운 것을 이야기하려 합니다.

반복 작업을 떼어내 준비 시간을 되찾는다

Before — 과제마다 TC를 새로 쓰던 시절

2025년 실측을 들여다보니 QA 총 투입 시간의 절반 이상이 테스트 설계와 TC 작성에 들어가 있었습니다. 준비 구간이 전체 일정에서 차지하는 비중은 커머스 50%, 물류 58%였습니다. 그렇게 쓴 TC의 재활용률은 5% 미만이었죠. 사실상 과제마다 TC를 처음부터 다시 쓰고 있었습니다.

테스트 자동화가 없었던 것은 아닙니다. 다만 스크립트 기반 자동화는 화면이 바뀔 때마다 스크립트를 고쳐야 해서, 회귀 테스트에는 맞아도 매번 새 화면이 나오는 신규 피처에는 쓰기 어려웠습니다. 가장 큰 공수가 드는 구간에는 정작 자동화가 닿지 않고 있었던 셈입니다.

팀원들에게 물어봐도 같은 답이 나왔습니다. QA 11명에게 TC 작성의 어려움을 물었더니 가장 많이 나온 답이 “시나리오를 중복·누락 없이 TC로 정리하기”(5명)였고, 사용자 흐름으로 재구성하기, 리스크 지점 떠올리기, 조건별 동작 차이 반영하기가 각각 4명으로 뒤를 이었습니다.

그래서 처음 세운 목표는 단순했습니다. AI가 80%를 쓰고 QA가 20%를 다듬어, TC 작성 공수를 절반으로 줄이는 것입니다.

After — 기획서 한 장에서 결함 등록까지

지금은 기획서를 넣으면 다섯 단계가 한 흐름으로 이어집니다. 앞 단계의 산출물이 다음 단계의 입력이 되고, 중간에 사람이 파일을 옮겨 붙이는 일은 없습니다.

요구사항 분석 시작 화면. 왼쪽 메뉴가 QA 다섯 단계와 테스트 자산·결과·시스템으로 나뉩니다.

항상 처음부터 밟을 필요는 없습니다. 쓰고 있던 TC가 있으면 바로 실행하고, 조건을 회귀 스위트로 저장해 두고 반복해 돌릴 수 있습니다. 빠르게 훑어보고 싶을 때는 TC 없이 기획서와 확인할 포인트만 주면, AI가 시나리오 5~15개를 스스로 도출해 탐색 테스트를 하고 리포트를 남깁니다. 주 사용자는 QA지만, 기획·PM·개발도 QA 과제로 올리지 않고 담당 기능을 직접 돌려 볼 수 있습니다.

반복 작성과 반복 수행은 시스템에, 판정과 리스크 결정은 사람에게.

BLOCKED 재분류와 FAIL 확인, 최종 판정은 여전히 QA의 몫입니다.

테스트 실행 결과. FAIL과 BLOCKED의 원인과 증적을 한 화면에서 검토하고, FAIL 건은 바로 Jira에 등록합니다.

서버는 관제탑, AI는 각자의 PC에서

구조는 관제탑 역할의 서버 한 대와, 실제로 AI를 돌리는 여러 대의 워커로 나뉩니다.

QA AI Hub 구성 · 서버 1대 + 분산 워커

• 서버는 Next.js 15 단일 앱입니다. 웹 UI와 API, 잡 상태를 담는 SQLite를 맡고, 잡을 만들 때 팀 정본에서 정책·스킬·정답 TC를 끌어와 작업 지시에 넣습니다. Confluence·Jira 자격증명은 서버에만 둡니다.
• 워커는 QA 각자의 PC에서 도는 Node.js 프로세스입니다. 잡을 받아 Claude Code를 헤드리스로 실행하고, 웹은 Playwright, 앱은 Mobile MCP로 실제 화면을 조작합니다.
• 연결은 항상 워커에서 서버로 걸립니다. 개인 PC의 방화벽을 열 필요가 없습니다.
• 병렬 실행은 에이전트 단위입니다. TC 39건을 13건씩 세 에이전트에 나눠 동시에 돌리고 결과를 하나로 합칩니다.

6월 첫 커밋 이후 넉 달 동안 커밋은 800건을 넘었고 테스트 파일도 400개가 넘습니다.

AI가 쓴 TC를 믿을 수 있게 만든다

기획서를 넣으면 TC는 나옵니다. 문제는 그 결과를 믿을 수 있느냐였습니다. 설계가 흐릿하면 AI는 그럴듯한 문장의 TC를 대량으로 만들어 내지만, 실제 검증력은 없습니다. 실험을 거치며 네 가지 장치를 파이프라인에 넣었습니다.

설계는 먼저, 작성은 그다음

초기 실험에서 기획서만 넣었더니 TC가 현저하게 적게 나왔습니다. 기획서는 기능을 만들기 위한 문서라, TC의 약 60%를 차지하는 UI 상태 조합 정보가 빠져 있었기 때문입니다. 그래서 “기획서 → TC”를 “기획서 → QA 설계 → TC”의 두 단계로 바꿨습니다.

요구사항 분석 결과. 주요 요구사항과 확인이 필요한 정책이 정리되고, PM 답변이 필요한 P0 문의가 맨 위에 표시됩니다.

설계 단계는 세 가지를 만듭니다.

• 요구사항 인벤토리: 기획서를 REQ-ID 단위로 쪼개고, 행마다 범위(진행·회귀·보류·제외), 조건, 기대결과, 리스크 등급(R1~R4)을 적음
• TC 설계 매트릭스: 각 REQ를 TC 축 × 대상 플랫폼으로 펼친 표. TC 한 건 한 건의 출처가 됨
• TC 수량 예산: 플랫폼별 예상 TC 수와 권장 상한, 산정 근거

이 산출물은 자동 검사를 통과해야 다음으로 넘어갑니다. 대상 REQ가 매트릭스에 100% 연결됐는지, 인벤토리와 매트릭스의 상태·리스크가 서로 맞는지를 봅니다. 설계가 고정되고 나면 TC 작성은 설계된 것을 옮기는 일이 됩니다.

모델보다 정답 TC

TC 품질을 가장 크게 가른 변수는 모델도 프롬프트도 아닌 참조할 정답 TC가 있느냐였습니다. 같은 채점 기준으로 비교했더니 정확한 정답 파일이 있을 때 95점, 비슷한 파일만 있을 때 26점, 아무것도 없을 때 15점이었습니다.

그래서 허브는 실행할 때마다 팀 정본 저장소(Git)에서 세 가지를 동기화해 함께 넣습니다.

• 도메인 마스터 정책: 도메인마다 “살아 있는 정책서 한 벌” (커머스 12개, 물류 18개 도메인)
• TC 작성 표준과 스킬: 컬럼 규칙, Depth·Pre-condition 규칙, 도메인 어휘
• 표준 TC 사전: 검수를 마친 정답 TC

정본이 바뀌면 다음 실행부터 곧바로 반영되니, 기준이 바뀔 때 고칠 곳은 한 곳뿐입니다. 사람이 검수한 TC는 다시 사전에 쌓여 다음 과제의 정답이 됩니다.

설계 → 기준 주입 → 생성 → 사람 검수 → 사전 적재. 쓸수록 참조할 기준이 두꺼워집니다.

게이트는 두 겹으로

TC 생성은 Claude Code 기반 멀티 에이전트 하네스가 맡습니다. 도메인별 오케스트레이터가 스킬 4개와 에이전트 11개를 묶어 다음 순서로 진행합니다.

1. 기획서 분석과 정답 TC 탐색
2. 정답 TC 파싱
3. 스켈레톤 사전 생성: 변수와 조합을 기계적으로 먼저 펼침 (정답 TC가 없는 과제의 품질 보완용. 한 과제에서 TC 118건 → 181건)
4. TC 생성
5. 스킬 준수 검증 (100점이어야 통과)
6. 품질 평가
7. 결과 보고

첫 번째 게이트는 스킬 안의 Python 체크포인트입니다. 그런데 LLM은 가끔 단계를 건너뜁니다. 그래서 두 번째로 Claude Code hook을 달아, 게이트를 통과하지 못한 산출물은 밖으로 나갈 수 없게 막았습니다.

TC 생성 설정. 대상 플랫폼과 실행 워커를 고르고, 생성 엔진으로 하네스를 선택합니다. 미해결 확인 이슈는 경고로 함께 넘어갑니다.

스크립트 대신 자연어 정의

TC는 자연어 정의로 남고, 실행할 때 AI가 그 정의를 읽어 브라우저를 조작합니다. 케이스마다 맞춘 자동화 스크립트는 없습니다. 화면이 바뀌면 고칠 대상은 TC 정의뿐이고, 그것은 바뀐 요구사항을 반영하는 평소의 QA 일입니다. 커버리지를 넓혀도 유지보수 부담이 같은 속도로 쌓이지 않는다는 점이 기존 자동화와 가장 크게 다릅니다.

숫자로 확인한 것

3월부터 9월까지 과제 137건을 측정했습니다. AI가 만든 TC는 과제 TC 작업의 약 70%를 그대로 덮었습니다. 다만 커머스와 물류의 차이가 컸고, 이 차이가 이번 프로젝트에서 가장 많이 배운 지점이기도 합니다.

커머스는 올랐고, 물류는 내려갔다

사내 AI TC 품질 평가 리포트 · 2026년 3~9월 과제 137건

물류의 하락은 품질이 나빠졌다기보다 측정 범위가 넓어진 결과입니다. 초기 2건뿐이던 표본에 고난도 레거시 과제가 본격적으로 더해졌고, 물류는 시스템 간 연동이 많고, 기획서에 없는 운영 규칙(코드 매핑, 센터별 정책 등)도 많습니다. 물류의 삭제율은 19.6%로 커머스(6.9%)의 두 배를 넘었고, 과제당 QA 정제 공수도 2.07일로 커머스(0.94일)의 두 배가 넘었습니다.

반대로 자산을 쌓으면 바로 반응했습니다. 정답 TC를 함께 준 커머스 과제는 수정률이 38.0%에서 19.8%로 절반이 됐고, 커머스 9월 한 달 활용률은 86.3%까지 올랐습니다. 물류도 회귀 성격 과제는 72.1%로, 일반 과제(45.3%)보다 26.8%p 높았습니다.

준비가 짧아지자 더 많은 과제를 맡게 됐다

2025년(AI 도입 전)과 2026년 3~9월을 비교했습니다.

물류 공수에는 9월 대형 과제의 영향이 섞여 있어, 전부를 AI 효과로 보지는 않습니다.

AI 실행은 아직 사람과 함께 돌린다

8~9월에는 E2E 기능 테스트 24건(커머스 13, 물류 11)을 AI와 사람이 동시에 수행해 신뢰도를 쟀습니다.

AI가 수행한 10,547건 중 판정이 틀린 거짓 PASS는 67건, 오류율 0.64%였습니다. 막힌 과제의 71%는 테스트 데이터 문제였습니다. 수행 담당자 7명은 모두 ‘화면 노출·문구’ 검증을 AI에 맡기기 좋은 유형으로 꼽았습니다.

다섯 번 구조를 바꾸며 배운 것

지금의 구조를 처음부터 그려 둔 것은 아닙니다. 프롬프트 한 장에서 시작해, 문제를 만날 때마다 한 칸씩 구조를 바꿔 왔습니다.

프롬프트에서 허브까지

허브의 출발점은 저희가 계획한 시스템이 아니었습니다. TC 품질을 어느 정도 끌어올린 뒤 다음 단계인 테스트 실행을 실험하던 중에, 트라이브의 안종관 님이 이미 워커 기반 실행 시스템을 개인적으로 만들어 쓰고 있었습니다. 새 시스템을 따로 만들기보다 이미 잘 짜여 있던 이 시스템을 확장하기로 함께 결정했고, 그 뒤로 트라이브 구성원 모두가 기능을 고도화하는 데 참여해 왔습니다.

TC 품질 개선은 장미가 님과 유현주 님이 실험을 설계·진행하고 구성원들이 따라올 수 있는 가이드를 만들며 이끌었습니다.

실수가 규칙이 되기까지

돌아보면 구조의 대부분은 실수에서 나왔습니다. 그리고 그 실수를 찾아낸 것은 실제 과제에 허브를 적용하며 TC를 고치고 실행 결과를 검증해 온 트라이브 구성원들이었습니다.

1. 도메인 지식이 모델보다 중요하다. 한 물류 과제에서 기획서만 넣으면 254건, 정책서를 함께 넣으면 963건이 나왔습니다. 레퍼런스를 참조하게 하자 종합 점수도 과제별로 59.5점에서 81.5점, 47.5점에서 87.7점으로 올랐습니다.
   • → 도메인 마스터 정책과 표준 TC 사전이 됐습니다.
2. AI는 해피패스를 좋아하고, 없는 것을 지어낸다. 커버리지 누락과 추상적인 기대결과가 반복됐고, 세 과제 중 하나는 기획서에 없는 항목 때문에 대량 보완이 필요했습니다.
   • → 평가 기준의 엣지 케이스 항목과 하네스의 스케일 규칙이 됐습니다.
3. 작은 오해석이 커버리지를 무너뜨린다. “페이지 미제공”을 “기능 미제공”으로 읽어 약 230건이 빠지고, 커버율이 10.8%까지 떨어진 과제가 있었습니다.
   • → 설계 단계의 범위 판정과 수량 예산이 됐습니다.
4. 반복 구조는 강하고 세부 분해는 약하다. 상태 전이·유효성·E2E 같은 기본 구조는 커버리지 100%였지만, 권한 세부 매트릭스는 37%, disabled 항목 상세화는 10%였습니다.
   • → 이런 영역은 QA가 직접 쓰는 것으로 역할을 나눴습니다.
5. 측정 기준부터 합의해야 한다. 담당자마다 측정 시점과 단위가 달랐고, 활용률 산식도 같은 TC를 분모에서 두 번 세고 있었습니다.
   • → AI 최종본과 QA 최종본을 diff해 판정 기준이 바뀐 변경만 수정으로 세는 측정 도구가 됐고, 산식은 10월에 개정했습니다.

어제의 실수가 오늘의 규칙이 됩니다. 규칙은 팀 정본에 쌓이고, 다음 실행부터 모두에게 적용됩니다.

다음 고민: 테스트 데이터와 지식 자산

가장 큰 병목은 이제 TC가 아니라 테스트 데이터입니다. AI 실행이 막힌 과제의 71%가 사전 데이터 문제였습니다. 허브에 상품·주문·쿠폰·멤버십 등을 만드는 테스트 데이터 기능을 넣었지만 아직 부족합니다. 물류 파트에서는 AI에게 테스트 계정만 주고 필요한 데이터와 참조 문서를 스스로 준비하게 하는 실험을 하고 있습니다.

두 번째는 개인의 노하우를 팀의 자산으로 옮기는 일입니다. 허브는 팀 정본에 등록된 문서만 참조합니다. 반면 각자의 PC에서 Claude를 직접 쓰는 QA는 개인 지식과 대화 기록까지 활용할 수 있어서, 같은 과제에서도 생성량에 차이가 납니다. 잘되는 방식을 발견하면 각자 복제해 쓰지 않고 정본으로 올리는 흐름을 만드는 것이 다음 과제입니다.

마지막은 AI 실행의 비중입니다. 지금은 신뢰도를 재기 위해 AI와 사람이 같은 TC를 이중 수행합니다. 데이터가 쌓이는 대로 사람 수행 비중을 줄여 나갈 계획입니다.

마치며

AI를 도입하며 얻은 것은 생산성 숫자 몇 개보다 QA의 일을 다시 나눌 수 있게 된 것입니다. 반복 작성과 반복 수행은 시스템이 맡고, 사람은 판정과 리스크 결정에 시간을 씁니다. 앞으로 QA의 역할도 이 방향으로 바뀌어야 한다고 생각합니다. TC를 많이 쓰는 사람이 아니라, 무엇을 확인해야 하는지 정하고 결과가 맞는지 판정하는 사람으로요. 요구사항 단계에서 정의 공백이 PM 문의표로 먼저 드러나니, 구현 뒤에야 발견되던 문제도 일부 앞으로 당겨졌습니다.

1년 전에는 과제마다 TC를 처음부터 썼고, 그 TC는 다음 과제에서 거의 쓰이지 않았습니다. 지금은 검수를 마친 TC가 다음 과제의 정답이 되고, 오늘의 실수는 내일의 규칙이 됩니다.

물론 모든 영역에서 잘되는 것은 아닙니다. 정책 문서와 정답 TC가 얇은 도메인은 여전히 사람 손이 많이 가고, 물류처럼 연동이 많은 영역은 QA 정제 시간이 커머스의 두 배를 넘습니다. 실행 단계는 아직 사람과 이중으로 돌리고 있어, 그쪽의 공수 절감은 이제부터 확인해야 합니다.

AI QA를 고민하는 팀이 있다면, 도구보다 자산부터 챙기시길 권합니다. 잘 쓴 TC 하나를 정답으로 정리해 두거나, 한 도메인의 정책을 문서 한 벌로 모아 두는 것부터요. 저희가 확인한 가장 큰 차이는 거기서 나왔습니다.

마지막으로, 이 글은 제 이름으로 나가지만 QA AI Hub는 프로덕트SQE 트라이브 구성원 모두가 함께 만든 결과입니다. 바쁜 과제 일정 속에서도 AI가 만든 TC를 검수해 정답 자산으로 쌓고, 실행 결과를 사람의 결과와 나란히 비교하며 신뢰도를 높여 준 동료들 덕분에 여기까지 올 수 있었습니다. 처음부터 끝까지 이 과제의 방향을 함께 고민하며 다양한 TC 품질 실험과 품질 측정 가이드, 지표 분석으로 개선을 이끈 장미가 님과 유현주 님, 워커 기반 테스트 실행 시스템의 출발점을 만든 안종관 님, 그리고 프로젝트 방향 설정과 기술 지원으로 하네스 엔지니어링을 적용해 준 민가혜 님께 특히 감사드립니다. 함께해 준 모든 구성원에게도 이 자리를 빌려 고마운 마음을 전합니다.