AI 지원 QA는 테스트 업무를 줄이는 것이 아니라, 업무가 발생하는 위치를 변화시킨다

AI 지원 개발 (AI-assisted development)은 종종 테스트 부담을 줄여주는 방법으로 홍보되곤 합니다. 하지만 그것은 잘못된 사고 모델 (mental model)입니다.

실질적인 효과는 보통 테스트의 양이 줄어드는 것이 아니라, 테스트의 성격이 변하는 것입니다. 어떤 업무는 더 앞 단계로 이동하고, 어떤 업무는 더 뒤 단계로 이동하며, 리뷰와 유지보수 방식을 바꾸지 않는다면 어떤 업무는 더 비용이 많이 들게 됩니다. AI 지원 QA (AI-assisted QA)로부터 가장 큰 이득을 얻는 팀은 보통 모든 것을 더 빠르게 자동화하려는 팀이 아닙니다. 그들은 다음과 같은, 다소 흥미롭지 않은 질문을 던질 용기가 있는 팀입니다: "우리는 실제로 어떤 종류의 테스트 업무를 인간이 계속 수행하기를 원하는가?"

일반적인 가정: AI는 더 적은 노력으로 더 높은 테스트 커버리지를 의미한다

AI가 테스트를 생성하고, 실패 원인을 요약하며, 어설션 (assertions)을 제안하고, 사람이 빈 파일에서 시작하는 것보다 더 빠르게 코드를 초안 작성할 수 있기 때문에 이러한 가정은 합리적으로 들립니다. 하지만 커버리지 (coverage)가 곧 가치 (value)와 동일한 것은 아닙니다. 테스트 스위트 (test suite)는 빠르게 성장할 수 있지만, 여전히 신뢰하기 어렵고, 디버깅하기 어려우며, 유지보수하기 어려워질 수 있습니다.

이 지점이 바로 AI 지원 개발이 테스트의 형태를 바꾸는 부분입니다. 이제 병목 현상 (bottleneck)은 단순히 테스트 코드를 작성하는 것에만 국한되지 않습니다. 병목 현상은 리뷰, 소유권, 그리고 해당 테스트가 스위트에 포함되어야 하는지 여부를 결정하는 것으로 옮겨갑니다.

만약 여러분이 대규모 자동화 스택을 물려받은 적이 있다면, 이미 그 패턴을 알고 있을 것입니다. 눈에 보이는 비용은 테스트 파일의 개수입니다. 숨겨진 비용은 중복된 커버리지, 불안정한 로케이터 (flaky locators), 디버깅 시간, CI 실행 시간, 그리고 어떤 프레임워크가 어떤 영역을 담당하는지 기억해야 하는 정신적 오버헤드 (mental overhead)입니다. 이것이 Playwright, Selenium, Cypress UI 테스트 스택이 혼합된 환경의 유지보수 실제 비용을 추정하는 방법에 관한 기사가 유용한 이유입니다. 단순히 하나의 스택 조합에 관한 것이 아니라, 테스트가 작성된 후 아주 오랜 시간이 지난 뒤에도 유지보수 비용이 어떻게 누적되는지를 보여주기 때문입니다.

AI는 그 문제를 제거하지 않습니다. 오히려 증폭시킬 수 있습니다.

절충안: 결정하기 위해서가 아니라, 초안을 작성하기 위해 AI를 사용하라

가장 실용적인 접근 방식은 AI가 생성한 테스트를 거부하거나 통째로 수용하는 것이 아닙니다. AI를 초안 작성 도구(drafting tool)로 취급하되, 다른 주니어 기여자에게 적용하는 것과 동일한, 어쩌면 그 이상의 규율을 적용하는 것입니다.

이는 로케이터(locator)의 품질을 검토하고, 어설션(assertion)이 의미를 갖도록 유지하며, 생성된 테스트가 실제로 중요하게 생각하는 사용자 행동을 반영하는지 확인하는 것을 의미합니다. 5개의 화면을 클릭하며 지나가지만 정작 검증하는 것은 거의 없는 생성된 테스트는 커버리지(coverage)가 아니라 장식에 불과합니다.

이것이 바로 리뷰 프레임워크(review framework)가 중요한 이유입니다. 유지보수 불가능한 테스트를 만들지 않고 AI 테스트 생성을 평가하는 방법에 관한 글에서 초점은 도구가 코드를 생성할 수 있는지 여부가 아닙니다. 유지보수성(maintainability), 디버깅 가능성(debuggability), 그리고 장기적인 소유 비용(ownership cost)에 초점을 맞춥니다. 그것이 올바른 관점입니다. 테스트를 생성하기는 쉽지만 수정하기가 고통스럽다면, 그 도구는 품질이 아닌 백로그(backlog)를 만드는 데 일조한 것입니다.

QA에서 AI가 실제로 잘하는 것

AI는 작업에 로컬 패턴 매칭(local pattern matching)이 많이 포함되어 있고 정책적 모호함(policy ambiguity)이 적을 때 가장 강력합니다. 예를 들어 다음과 같습니다:

• 수동 흐름(manual flow)을 테스트 단계의 초안으로 변환하기,
• 반복적인 설정 코드(setup code) 채우기,
• 어설션 패턴(assertion patterns) 제안하기,
• 놓쳤을 수도 있는 엣지 케이스(edge cases) 제안하기,
• 실패한 테스트 실행 결과를 리뷰어가 빠르게 훑어볼 수 있도록 요약하기.

이 중 그 어떤 것도 테스트 설계(test design)를 대체하지 않습니다. 단지 빈 페이지에서 시작할 때의 마찰(blank-page friction)을 줄여줄 뿐입니다.

위험은 팀이 생성 속도(generation speed)를 테스트 전략(test strategy)과 혼동할 때 발생합니다. AI가 더 많은 테스트를 저렴하게 만들 수 있다면, 잘못된 테스트를 더 빠르게 만드는 것도 더 쉽게 만듭니다.

작성자만이 코드를 이해하는 것이 아닐 때의 변경 사항 리뷰

AI 지원 개발 (AI-assisted development)에서 나타나는 한 가지 미묘한 변화는 코드 리뷰 (code review)가 덜 중요해지는 것이 아니라 오히려 더 중심적인 역할이 된다는 점입니다. 개발자가 모든 코드를 직접 손으로 작성할 때는 보통 의도를 충분히 이해하고 있으므로 나중에 이상한 점을 발견할 수 있습니다. 하지만 AI 지원 출력물 (AI-assisted output)을 사용할 때는 의도 (intent)와 구현 (implementation) 사이의 간극이 벌어질 수 있습니다.

이는 리뷰어가 더 정밀한 질문을 던져야 함을 의미합니다:

• 이 테스트가 실제 동작 (behavior)을 표현하고 있는가, 아니면 단순히 UI 액션의 연속일 뿐인가?
• 셀렉터 (selectors)가 일반적인 리디자인 (redesign) 상황에서도 견딜 수 있을 만큼 안정적인가?
• 만약 이 테스트가 실패한다면, 실패 지점이 우리에게 유용한 정보를 제공할 수 있는가?
• 이것은 제품을 테스트하는 것인가, 아니면 현재의 DOM 구조를 테스트하는 것인가?

이것들은 새로운 질문은 아니지만, AI는 이러한 질문들이 생략될 가능성을 높입니다. 생성된 테스트는 종종 그럴싸해 보이는데, 바로 그 점 때문에 더 신중한 리뷰가 필요합니다.

ChatGPT로 Playwright 테스트 생성하기에 관한 기사는 이러한 중간 경로에 대한 좋은 예시입니다. 이는 단순히 모델에 코드를 작성하도록 프롬프팅 (prompting)하는 것에 관한 것이 아니라, 결과를 리뷰하고 로우코드 (low-code) 플랫폼이 더 적합할 때가 언제인지 결정하는 것에 관한 것입니다. 이것이 중요한 지점입니다. 만약 귀하의 리뷰 프로세스가 취약한 생성 테스트를 안정적으로 잡아낼 수 없다면, 문제는 생성기가 아니라 표준 (standards)의 부재입니다.

커버리지 (Coverage)는 더 이상 양에 관한 것만이 아니다

AI는 특히 UI 경로 주변의 커버리지를 공격적으로 확장하고 싶은 유혹을 느끼게 할 수 있습니다. 하지만 테스트가 많아진다고 해서 자동으로 위험 감소가 더 잘 이루어지는 것은 아닙니다. 실제로 여러분은 다음 세 가지 계층에 걸쳐 균형 잡힌 커버리지를 원해야 합니다:

• 비즈니스 핵심 사용자 여정 (business-critical user journeys),
• 회귀 테스트 (regression)가 발생하기 쉬운 통합 지점 (integration points),
• 자동화 비용이 저렴하고 결정론적 (deterministic)인 저수준 엣지 케이스 (low-level edge cases).

AI는 각 계층에 대한 후보를 제안하는 데 도움을 줄 수 있지만, 최종적인 조합을 결정해서는 안 됩니다. 팀은 여전히 무엇을 자동화할지, 무엇을 수동으로 유지할지, 그리고 무엇을 완전히 제외할지에 대한 판단력이 필요합니다.

이 지점에서 아키텍처 (Architecture)의 중요성이 드러납니다. 만약 자동화가 정교한 프레임워크 글루 (Framework glue)에 의존하고 있다면, 새로운 테스트가 추가될 때마다 유지보수 비용(Maintenance tax)이 발생합니다. 이것이 일부 팀이 직접 구축한 프레임워크를 영원히 확장하는 대신, 편집 가능하거나 로우코드 (Low-code) 시스템을 검토하는 이유 중 하나입니다. Endtest vs Hand-Built Playwright Frameworks for Teams That Want Editable Tests에서의 비교는 특히 무거운 프레임워크 소유권 없이 협업이 필요한 팀들에게 이러한 트레이드오프 (Tradeoff)를 잘 보여줍니다.

로우코드는 차선책이 아니라, 하나의 결정입니다

로우코드 도구를 코딩 능력이 부족한 팀을 위한 타협안으로 취급하기 쉽지만, 이는 너무 단순한 생각입니다. 때로는 프레임워크 글루를 줄이고, 테스트 편집을 더 쉽게 만들며, 비전문가에게 워크플로우 (Workflow)를 더 많이 노출할 수 있는 것이 최선의 자동화 결정이 될 수 있습니다.

이러한 아이디어는 활발한 프론트엔드 환경에서의 편집 가능한 테스트 단계와 유지보수에 초점을 맞춘 Endtest for Fast-Moving Frontend Teams에서도 다시 나타납니다. 이 관점이 유용한 이유는 질문의 틀을 "이것을 자동화할 수 있는가?"에서 "UI가 세 번 변경된 후에도 이것을 이해 가능한 상태로 유지할 수 있는가?"로 재정의하기 때문입니다.

AI는 이러한 질문의 가치를 높이는 경향이 있습니다. 팀이 더 많은 자동화를 더 빠르게 생성할 수 있다면, 해당 자동화의 장기적인 편집 가능성 (Editability)은 훨씬 더 중요해집니다.

자동화 결정은 유행이 아니라 소유권을 따라야 합니다

제가 보는 가장 큰 실수는 단순히 새로움(Novelty)만으로 AI가 자동화 전략에 영향을 미치도록 방치하는 것입니다. 어떤 도구가 많은 Playwright 코드를 생성할 수 있다고 해서, 모든 테스트에 Playwright가 적합한 장소라는 뜻은 아닙니다. 마찬가지로, 로우코드 플랫폼이 편집을 더 쉽게 만들 수 있다고 해서 모든 시나리오가 그곳에 속해야 한다는 의미도 아닙니다.

더 나은 결정 규칙은 비록 화려하지는 않더라도 매우 단순합니다:

• 테스트에 깊은 제어(deep control), 사용자 정의 어설션(custom assertions), 또는 복잡한 설정(complex setup)이 필요하다면, 코드로 유지하십시오.
• 테스트가 자주 변경되고 비즈니스 측면에서 폭넓은 협업을 원한다면, 편집 가능한 단계(editable steps)나 로우코드(low-code)를 고려하십시오.
• 시나리오의 디버깅 비용이 높다면, 추상화(abstraction)가 그 자체로 비용을 상쇄할 만큼의 가치를 제공하지 않는 한, 추상화를 추가하여 상황을 더 어렵게 만들지 마십시오.

이는 특히 동적인 UI를 다루는 팀에게 매우 유의미한 Endtest Review for QA Teams Testing Dynamic Frontends Without Writing Framework Glue의 교훈이기도 합니다. 여기서 핵심 가치는 로우코드(low-code)가 엔지니어링적 판단을 제거하는 것이 아닙니다. 그 가치는 소유권 모델(ownership model)을 변화시켜, 더 많은 사람이 자동화 내용을 이해하고 유지 관리할 수 있게 한다는 점에 있습니다.

실질적인 시사점

AI 지원 QA는 테스트를 사라지게 만들지 않습니다. 대신 중심축을 생성(creation)에서 큐레이션(curation)으로 이동시킵니다.

즉, 최고의 팀들은 AI가 테스트를 작성할 수 있는지에 대해 논쟁하는 데 시간을 덜 쓰는 대신, 무엇이 테스트를 유지할 가치가 있게 만드는지를 정의하는 데 더 많은 시간을 보낼 것입니다. 그들은 생성된 코드를 더 주의 깊게 검토하고, 중요한 부분으로 테스트 커버리지(coverage)를 좁히며, 도구에 대한 흥분보다는 소유 비용(ownership cost)에 기반하여 자동화 스타일을 선택할 것입니다.

다시 말해, 테스트의 미래는 결정의 수가 줄어드는 것이 아닙니다. 더 많은 도움을 받아, 더 일찍, 그리고 단지 생산적으로 보이기만 하는 자동화에 대해서는 더 낮은 관용도를 가지고 더 나은 결정을 내리는 것입니다.