AI 시대 QA의 무기는 자동화가 아니라 ‘판단’이다
AI가 테스트 케이스를 대신 써 주는 시대에 QA는 무엇을 하는가. Ministry of Testing이 정리한 ‘품질 엔지니어링에서 AI를 파트너로 쓰는 다섯 가지 실무법’은 이 질문에 명확히 답한다. 핵심은 AI를 자동화 지름길로 쓰는 게 아니라, 테스터의 일을 ‘산출물 찍어내기(artifact production)’에서 ‘문제 설계·오케스트레이션(problem orchestration)’으로 재정의하는 데 있다. AI 도입이 테스터의 판단력을 대체하는 게 아니라 오히려 날카롭게 만든다는 관점이다.
"AI won't replace Quality Assurance (QA), but a QA who learns to use AI effectively will replace those who don't."Ministry of Testing
무슨 일인가
제시된 다섯 가지는 모두 ‘사람이 문제를 정의하고 AI가 실행을 돕는’ 구조다. ① 역할·제약을 명시한 반복적 프롬프트로 테스트를 생성하고, ② 불안정한 플래키 테스트의 패턴을 AI로 분석·리팩터링하며, ③ 프롬프트 체이닝으로 회귀 스위트의 중복·공백을 찾아 최적화한다. ④ 배포 전 검증·코드 리뷰·버그 트리아지를 잇는 프로덕션 QA 워크플로에 AI를 끼워 넣고, ⑤ 표준화된 프롬프트를 팀 공용 자산으로 쌓는 QA 프롬프트 라이브러리를 만든다. 관통하는 전제는 하나 — 문제를 명확히 프레이밍하고, 제약을 정의하고, 결과를 해석하는 힘이 있어야 AI가 제값을 한다는 것이다.
여러 시각
같은 원리가 QA를 넘어 제품 기획에도 그대로 적용된다.
- Mind the Product — ‘하이프를 걷어낸 AI 제품 전략’ 관점. AI 기능은 직접 컴퓨트 비용의 최소 3배 가치를 증명해야 하고(안 그러면 잘 팔려도 마진을 갉아먹는다), 단일 프로바이더에 잠기지 말고 교체 가능한 아키텍처를 두며, ‘채택률’이 아니라 ‘실제로 줄인 업무량’을 성공 지표로 삼으라고 말한다. QA의 ‘문제 설계’와 기획의 ‘가치·비용 판단’은 결국 같은 근육이다.
왜 중요한가
AI가 실행 단가를 떨어뜨릴수록, 사람의 가치는 ‘무엇을·왜 검증하고 만드는가’라는 판단으로 이동한다. 테스트 케이스를 손으로 쓰고 실패를 수동 분류하던 일은 빠르게 기본값(table stakes)이 되고 있고, 그만큼 리스크 기반 전략·거버넌스·품질 판단의 몸값이 오른다. 기획도 똑같다 — 만들 수 있느냐가 아니라, 만들 가치가 있느냐를 숫자로 가르는 사람이 살아남는다. AI는 답을 주는 도구가 아니라, 좋은 질문을 던진 사람에게만 레버리지를 주는 도구다.
실무 적용
- AI에 테스트·요구사항을 맡길 때 역할·제약·수용 기준을 먼저 문장으로 못 박고, 산출물은 ‘초안’으로만 받아 사람이 리스크 관점에서 검수한다.
- 팀 공용 ‘프롬프트 라이브러리’를 리포에 두고, 잘 통한 프롬프트를 코드처럼 리뷰·버전관리해 품질을 재현 가능하게 만든다.
- 기획 단계에서 각 AI 기능에 ‘실패 조건’과 ‘가치 지표(줄인 업무량·전환)’를 컴퓨트 원가와 함께 명시해, 하이프가 아니라 단위 경제로 우선순위를 정한다.
Kenny의 관점
기획·QA·프런트엔드를 오가며 일하는 입장에서, 이 글의 ‘문제 오케스트레이션’이라는 표현이 가장 정확하다고 느낀다. 나는 AI에게 코드나 테스트를 시킬 때 결과물의 양보다 ‘내가 문제를 얼마나 좁게 정의했는가’로 품질이 갈린다는 걸 매번 확인한다. 그래서 AI를 쓸수록 요구사항을 더 명료하게 쪼개고, 실패 조건을 먼저 적는 습관이 늘었다. 자동화는 거들 뿐, 무엇을 검증하고 무엇을 포기할지 정하는 판단은 여전히 사람의 몫이다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Ministry of Testing ↗