AI 시대의 QA, 도구보다 먼저 바꿀 것은 사고방식
생성형 AI 덕분에 테스트 케이스와 자동화 스크립트는 몇 분 만에 쏟아져 나온다. 그런데 산출물이 늘어난다고 품질이 올라가지는 않는다. Ministry of Testing에 실린 두 편의 글은 같은 질문을 서로 다른 층위에서 다룬다. 하나는 '어떻게 생각할 것인가', 다른 하나는 '그 생각을 자동화에 어떻게 안전하게 심을 것인가'다.
"AI can accelerate output, but only humans can actually think. And thinking is where quality begins."Ministry of Testing
무슨 일인가
Ady Stokes는 품질 전문가가 상황에 맞춰 바꿔 쓸 수 있는 사고방식을 네 묶음으로 정리한다. 가능성을 그리는 '비저너리·개방형', 사실을 검증하는 '분석·현실 기반형', 영향과 윤리를 살피는 '철학·연결형', 파괴적 의도로 실패 경로를 탐색하는 '어두운·공격형'이다. 어느 하나가 우월하지 않고, 각각 잘 보는 것과 못 보는 것이 다르다는 점이 핵심이다. 글에는 '나중에 저장' 기능을 대상으로 네 라운드 동안 마인드셋을 강제로 바꿔 보는 훈련도 포함되어 있다. 자신의 기본 마인드셋을 먼저 파악하고 의식적으로 이탈해 보게 하는 구조다.
여러 시각
같은 주제를 자동화 쪽에서 보면 결론은 비슷하게 '판단은 사람이 설계한다'로 모인다.
- Ministry of Testing(Pranav Pandit) — AI는 결정론적 자동화를 대체하지 말고, 로케이터가 깨질 때만 작동하는 통제된 폴백이어야 한다고 본다. 모델 성능보다 맥락 신호가 더 중요하다는 것이 그의 결론이다.
- 실제 사고 사례 — 버튼 이름 하나가 바뀌어 테스트 40여 개가 한꺼번에 실패했고, 힐링이 대부분 복구했지만 맥락이 부족한 일부는 엉뚱한 요소를 골랐다. 자동 복구가 곧 정답은 아니라는 증거다.
- 단계적 도입 — 런타임 한정 힐링에서 시작해 사람이 검토하는 수정, 확신이 높을 때만 자동 병합으로 넓히는 순서를 제안한다.
왜 중요한가
AI가 테스트를 대신 써 주는 흐름에서 QA의 가치는 '많이 만드는 능력'에서 '무엇을 의심할지 아는 능력'으로 옮겨 간다. 마인드셋 모델은 그 능력을 훈련 가능한 항목으로 쪼갠 시도다. 반대로 셀프힐링 글은 AI가 만든 변경이 조용히 잘못된 요소를 통과시키는 위험을 보여 준다. 즉 사고의 폭이 좁으면 AI는 같은 맹점을 더 빠르게 복제한다. 기획 단계의 요구사항 검토에서도 같은 구조가 반복된다.
실무 적용
- 요구사항 리뷰 때 '이번에는 공격형 마인드셋으로만 읽는다' 같은 역할 라운드를 회의에 넣어 본다.
- 자동화에 AI를 붙일 때는 결정론적 경로를 먼저 두고, 복구 시도는 모두 로그로 남겨 사람이 검토한다.
- 자동 복구 결과를 바로 병합하지 말고 단일 매치·가시성·상호작용 가능 여부 같은 검증 규칙을 통과시킨다.
Kenny의 관점
프론트엔드를 만드는 입장에서 UI 변경은 늘 일어나고, 그때마다 테스트가 깨지는 비용을 체감한다. 그래서 셀프힐링이 반갑지만, 'data-testid' 같은 안정적인 계약을 코드에 먼저 심는 편이 가장 싼 해결책이라고 생각한다. AI는 그 계약이 없는 곳의 안전망일 뿐이다. 결국 AX 시대의 QA는 도구 선택보다 어떤 관점으로 의심할지를 팀이 공유하는 일이다. 기획 단계에서 마인드셋을 섞어 쓰는 습관이 나중의 자동화 비용을 줄인다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Ministry of Testing ↗