테스트를 수정하는 대신 버려지는 자동화가 AI 시대에 적합한 이유

셀프-힐링(Self-healing) 테스트는 잘못된 문제를 해결하고 있습니다.

'힐러(healer)'가 깨진 로케이터(locator)를 '충분히 가까운' 요소로 대체할 때, 실행은 녹색 상태를 유지하지만, 테스트는 아무도 의도하지 않은 것을 단언할 수 있습니다. 당신은 테스트를 고친 것이 아닙니다. 시끄럽게 실패하는 오류를 조용한 거짓 양성(false positive)으로 바꾼 것입니다.

제가 계속 돌아가고 있는 대안이 여기 있습니다: 스크립트를 아예 유지하지 마세요. 만약 모델이 테스트 케이스를 읽고 스스로 브라우저에서 실행할 수 있다면, 스크립트는 더 이상 필요한 것이 아닙니다. 중요한 것은 그 테스트 케이스 자체입니다. 존재하지 않는 스크립트는 고장 날 수 없습니다.

셀프-힐링은 증상만 해결한다

셀프-힐링 로케이터는 '버튼이 움직였는데, 어떻게 클릭할 수 있을까?'에 답합니다. 그것은 결코 '이 스크립트가 여전히 존재해야 할까?'라고 묻지 않습니다.

더 나쁜 것은, 힐러가 깨진 셀렉터(selector)를 그럴듯해 보이는 근처 요소로 대체할 수 있다는 것입니다. 테스트는 통과하지만, 이제 작성자가 의도하지 않은 것을 확인하게 됩니다. 당신은 시끄럽게 실패하는 오류를 조용한 거짓 양성으로 바꾼 것이고, 이것들이 가장 비용이 많이 드는 종류의 테스트 부채(test debt)입니다. 계속 깨지는 로케이터 역시 무언가를 알려주고 있습니다 (불안정한 훅, 변동하는 화면 등). 그리고 자동 복구 기능은 그 메시지를 침묵시킵니다.

버려지는 루프: 테스트 케이스를 입력하고 실행을 출력한다

제가 계속 돌아가고 있는 대안이 여기 있습니다. 당신의 진실 공급원(source of truth)은 일반 언어로 작성된 테스트 케이스입니다. 수동 테스터에게 건네줄 것과 같은 것입니다. 이것을 누군가가 소유해야 하는 Playwright 스크립트로 변환하는 대신, AI 에이전트가 이를 읽고 실행하도록 합니다.

Playwright MCP 서버와 같은 브라우저 제어 도구를 사용하면, 에이전트는 헤드리스(headless) 브라우저를 열고, 단계를 따르고, 페이지를 살펴보고, 무슨 일이 일어났는지 보고할 수 있습니다. 이것이 현재의 페이지에서 작동하기 때문에, 고칠 것이 아무것도 없습니다. 만약 버튼이 움직였다면, 인간이 하는 방식대로 그 버튼을 찾습니다.

이 세계에서의 테스트 케이스는 단지 다음과 같습니다:

## TC-CART-014: Promo banner shows for a new promo SKU
Precondition: logged in as a standard test user, cart is empty
1. Add the item with SKU PROMO-001 to the cart
...

에이전트에게 전달되는 지침 역시 마찬가지로 짧습니다.

Run TC-CART-014 against the staging URL in a headless browser.
For each step, note what you did and what you saw.
Take a screenshot at the end. Report PASS/FAIL per expected result, with evidence.

결과는 스크린샷이 포함된 짧은 보고서입니다. 사용자가 시각적으로 검증합니다. 사람이 증거를 몇 초 만에 훑어보는 것이 때로는 빨간 CI(Continuous Integration) 작업 디버깅보다 빠릅니다. 스크립트가 존재하지 않기 때문에, 스크립트가 망가지지도 않습니다.

왜 이것이 긴 꼬리 부분(long tail)을 치유하는 것보다 나은가

대부분의 테스트 스위트는 특정 순간에 중요한 '긴 꼬리' 검사들을 가지고 있습니다. 예를 들어, 릴리스, 마이그레이션, 위험한 리팩토링, 재현하고 싶은 단일 버그 보고서 등이 그렇습니다. 이러한 것들에 대한 스크립트를 작성하고 유지하는 것은 좋지 않은 거래입니다.

• 유지보수 불필요. '자동화'는 실행할 때마다 테스트 케이스로부터 재생성됩니다. UI 재설계가 아무것도 망가뜨리지 않습니다.
• 백그라운드에서 실행 가능. 헤드리스 모드로 시작해 보고서로 돌아올 수 있습니다. 실행하는 동안 사용자의 주의를 필요로 하지 않습니다.
• 시각적 검증. 스크린샷은 코딩된 단언(scripted assertions)이 결코 묻지 않았던 것들, 즉 중첩되는 요소, 깨진 레이아웃, 잘못된 이미지를 포착합니다.
• 테스트 케이스가 지속 가능한 자산으로 남습니다. 제품 테스터와 수동 테스터를 포함하여 모두가 이를 읽고 검토할 수 있습니다.

가치가 있는 것만 승격시키기(Promote only what earns it)

제가 가장 좋아하는 부분은 여기에 있습니다. 이것은 일방통행 문이 아닙니다. 이러한 백그라운드 실행들은 유지보수되는 스위트의 발견 파이프라인 역할도 합니다.

어떤 시나리오가 계속 나타나거나, 실제 버그를 포착하거나, 중요한 것을 보호하는 경우, 그것은 제대로 된 결정론적(deterministic) 스크립트로 승격할 가치가 있다는 신호입니다. 그때 당신은 이를 승격시킵니다. 에이전트가 수행한 것(단계, 찾은 셀렉터, 필요했던 상태)을 가져와 실제 단언이 포함된 검토된 테스트로 변환하는 것입니다.

import { test, expect } from '@playwright/test';

test('promo banner shows for a new promo SKU', async ({ page, request }) => {
...

내 규칙은 이렇습니다: 스크립트가 고장 났을 때 당신이 긴급하게 수정하지 않을 것이라면, 그것을 홍보(promote)하지 마십시오. 그 외 모든 것은 에이전트가 필요할 때 실행하는 테스트 케이스로 남겨둡니다. 이렇게 하면 관리되는 스위트(suite)는 작고 신뢰할 수 있게 유지됩니다. 왜냐하면 이 안에 있는 모든 스크립트는 축적된 것이 아니라, 선택되었기 때문입니다.

여기서 잘못되는 부분들

제가 과장하고 싶지는 않습니다. 몇 가지 솔직한 한계점들이 있습니다:

• 이것들은 머지 게이트(merge gate)가 아닙니다. 에이전트 실행은 비결정적(non-deterministic)이며, 컴파일된 스크립트보다 느리고 토큰을 소모합니다. 두 번의 실행은 다른 경로를 따르거나 '보이는 것'을 다르게 판단할 수 있습니다. 탐색이나 릴리스 검사에는 괜찮지만, 수천 개의 테스트 회귀(regression) 실행용으로는 적합하지 않습니다.
• 에이전트가 너무 관대할 수 있습니다. 고장 난 흐름(flow)을 '우회하는' 에이전트는 실제 사용자가 막힐 곳에서 통과(pass)했다고 보고할 수 있습니다. 기대 결과는 엄격하게 작성하고, 증거를 읽어내야 합니다.
• 핵심 흐름은 코드가 필요합니다. 감사 및 규정 준수 추적(Audit and compliance trails)에는 결정론적이고 지속 가능한 스크립트가 필요합니다.
• 테스트 데이터와 환경 지식은 여전히 당신에게서 나옵니다. AI는 당신이 시딩한 계정이나 스테이징 환경의 특이점(quirks)을 알지 못합니다. 당신이 알려주지 않는 한 말입니다.
• 일부 실패는 실제 버그입니다. 녹색(green)으로 돌아갈 때까지 절대 재실행하지 마십시오.

핵심 요약 (The Bottom Line)

자가 치유(Self-healing) 방식은 모든 스크립트를 살아있게 유지하는 데 최적화되어 있습니다. 반면, 버려지는 접근법(throwaway approach)은 올바른 스크립트들만 살아있게 유지하는 데 최적화되어 있습니다. AI가 당신의 테스트 케이스를 읽고 헤드리스(headless)로 실행하게 하고, 증거를 시각적으로 검증하며, 가치가 입증되었을 때만 해당 시나리오를 관리되는 코드로 전환해야 합니다.

SDET로서 당신의 가치는 얼마나 많은 스크립트를 유지하느냐가 아닙니다. 어떤 점검이 아예 코드가 되어야 할 자격이 있는지를 판단하는 능력입니다.

그래서 제 질문은 이렇습니다: 현재 사용 중인 스위트(suite)의 어느 부분이 잘 작성된 테스트 케이스와 에이전트로 대체될 수 있을 것이며, 당신이 그것을 신뢰하기 전에 무엇을 봐야 할까요?

원래 luthfiferdian.com에 게시되었습니다.