몇 년 전만 해도 브라우저 테스트 프레임워크 (browser test framework)를 구축할 때 가장 어려운 부분은 시작하는 것이었습니다.

러너 (runner)를 선택하고, 브라우저를 설정하며, 페이지 오브젝트 (page objects)를 생성하고, 리포팅 (reporting)을 연결하고, 재시도 (retries) 기능을 추가하고, 비밀 정보 (secrets)를 관리하고, 이를 CI에 연결하고, 팀의 다른 누군가가 이 모든 것이 어떻게 작동하는지 배우도록 설득해야 했습니다.

오늘날에는 AI 어시스턴트 (AI assistant)를 열고 점심시간 전까지 그 중 대부분을 생성해 달라고 요청할 수 있습니다.

이것은 극적인 개선처럼 들립니다. 어떤 면에서는 그렇습니다.

하지만 이는 병목 현상 (bottleneck)의 위치를 옮길 뿐입니다.

질문은 더 이상 "우리가 프레임워크를 만들 수 있는가?"가 아닙니다.

질문은 "우리가 만들어진 것을 운영할 수 있는가?"입니다.

이 차이는 보이는 것보다 더 중요합니다.

생성 비용은 소유 비용이 아니다

생성된 프레임워크는 첫 번째 버전이 빠르게 도착하기 때문에 저렴하게 느껴집니다. 코드는 컴파일되고, 몇 개의 테스트가 통과하며, 풀 리퀘스트 (pull request)는 당신이 오후 내내 작성할 수 있었던 그 어떤 것보다 더 완성도 있어 보입니다.

그러다 현실이 압박을 가하기 시작합니다.

애플리케이션이 변경됩니다. 스테이징 (staging) 환경에서 인증 (Authentication) 동작이 달라집니다. 공유 헬퍼 (shared helper)가 실패를 숨기기 시작합니다. 병렬 워커 (Parallel workers)가 테스트 데이터 (test data)를 두고 충돌합니다. 누군가 의존성 (dependency)을 업그레이드하면 세 개의 리포터 (reporters)가 서로 일치하지 않게 됩니다.

초기 생성은 빨랐습니다. 소유 비용 (ownership cost)은 단지 미뤄졌을 뿐입니다.

이것은 Claude가 대규모 Playwright 프레임워크를 생성할 때 실제로 무엇이 망가지는가에서 설명된 핵심 문제입니다. 대규모로 생성된 시스템은 종종 이음새 부분에서 실패합니다: 픽스처 (fixtures), 추상화 (abstractions), 환경 가정 (environment assumptions), 테스트 데이터 (test data), 그리고 명시적으로 합의되지 않은 컨벤션 (conventions)들 말입니다.

코드는 한 줄씩 읽을 때는 가독성이 있을지 모르지만, 시스템 전체로 볼 때는 추론하기 어려운 상태로 남을 수 있습니다.

이는 생산적으로 보이기 때문에 위험한 형태의 복잡성 (complexity)입니다.

더 많은 코드는 더 적은 이해를 숨길 수 있다

팀들은 때때로 출력량을 세어봄으로써 AI가 생성한 자동화 (automation)를 평가하곤 합니다:

• 테스트 파일 수;
• 시나리오 수;
• 통과한 체크(checks) 수;
• 완료된 프롬프트(prompts) 수;
• 추가된 코드 라인 수.

그러한 숫자들은 산출하기 쉽고 보고하기도 쉽습니다.

하지만 그것들은 신뢰도(confidence)를 나타내는 취약한 대리 지표(proxies)이기도 합니다.

생성된 테스트가 500개인 스위트(suite)가 의도적으로 선택된 40개의 여정(journeys)으로 구성된 스위트보다 덜 유용할 수 있습니다. 규모가 더 큰 스위트는 수익, 고객 신뢰 또는 데이터 무결성(data integrity)을 실제로 위험에 빠뜨리는 소수의 전환(transitions)을 놓치는 동안, 피상적인 상태만을 반복적으로 검증할 수 있기 때문입니다.

이것이 바로 팀들이 사용자 여정의 위험(user journey risk) 대신 프롬프트 통과율(prompt pass rate)을 최적화할 때 AI 테스트 커버리지(AI test coverage)가 무너지는 이유입니다. 프롬프트는 성공할 수 있지만, 그 결과로 나타나는 테스트 전략은 여전히 형편없는 상태로 남을 수 있습니다.

목표는 AI가 지시사항을 따랐음을 증명하는 것이 아닙니다.

목표는 비용이 많이 드는 뜻밖의 상황(expensive surprise)이 발생할 확률을 줄이는 것입니다.

이 둘은 같은 것이 아닙니다.

스택은 조용히 계속 확장되고 있다

현재 흔히 볼 수 있는 설정은 다음과 같습니다:

1. Playwright가 브라우저를 실행합니다.
2. Claude가 테스트 코드를 생성하거나 수정합니다.
3. GitHub Actions가 스위트(suite)를 실행합니다.
4. 리포팅 서비스(reporting service)가 결과를 저장합니다.
5. 시각적 도구(visual tool)가 스크린샷을 비교합니다.
6. 테스트 데이터 서비스(test data service)가 계정을 생성합니다.
7. Slack이 알림을 받습니다.
8. 누군가가 프롬프트(prompts), 컨벤션(conventions), 그리고 가드레일(guardrails)을 유지 관리합니다.

각 구성 요소는 개별적으로는 합리적일 수 있습니다.

문제는 통합 표면(integration surface)입니다.

테스트가 실패했을 때, 팀은 해당 문제가 제품에서 발생했는지, 생성된 코드인지, 브라우저 타이밍인지, 픽스처 상태(fixture state)인지, 환경 설정(environment configuration)인지, 모델의 가정(model assumption)인지, 아니면 리포팅 계층(reporting layer)에서 발생했는지를 판단해야 합니다.

이 지점이 바로 Playwright와 Claude를 함께 사용하는 것이 너무 많은 가동 요소(moving parts)처럼 느껴지기 시작하는 지점입니다. 부담의 원인이 반드시 두 도구 중 어느 하나가 나쁘기 때문은 아닙니다. 진짜 부담은 여러분의 팀이 결합된 시스템을 조립하고, 문서화하며, 지원해야 하는 책임을 지는 사실상의 벤더(vendor)가 되어버렸다는 점에 있습니다.

이는 어떤 기업들에게는 좋은 거래일 수 있습니다.

하지만 귀사의 경우에는 자동으로 좋은 거래가 되는 것은 아닙니다.

생성된 프레임워크는 생성된 불일치성을 상속받는다

AI에게 몇 주에 걸쳐 10개의 테스트를 추가해 달라고 요청하면, 아키텍처(architecture)에 대해 서로 상충하는 여러 아이디어를 받게 될 수 있습니다.

어떤 테스트는 페이지 오브젝트(page objects)를 사용합니다. 다른 테스트는 피스처(fixtures)를 직접 사용합니다. 어떤 헬퍼(helper)는 네트워크 유휴 상태(network idle)를 기다립니다. 다른 것은 로케이터(locator)를 기다립니다. 어떤 파일은 API를 통해 데이터를 생성합니다. 다른 것은 UI를 통해 설정을 진행합니다. 명명 규칙(naming conventions)은 프롬프트(prompt)의 문구에 따라 변합니다.

각각의 개별적인 결정은 모두 타당해 보일 수 있습니다.

하지만 이들이 모이면 엔트로피(entropy)를 만들어냅니다.

출력물이 Playwright이든 Selenium이든 동일한 문제가 적용됩니다. Claude가 대규모 Playwright 또는 Selenium 프레임워크를 생성할 때 주의 깊게 살펴봐야 할 것은 단순히 구문(syntax)의 품질이 아닙니다. 생성된 시스템이 인간이 일관되게 확장할 수 있는 일관된 내부 모델을 구축하느냐의 문제입니다.

강력한 아키텍처 소유자(architecture owner)가 없다면, AI는 팀이 전역적 일관성(global consistency)을 확립하는 속도보다 로컬 결정(local decisions)을 더 빠르게 가속화하곤 합니다.

결과적으로 자동화는 늘어나지만, 동시에 표준화는 줄어들게 됩니다.

진짜 테스트는 2년 차에 시작된다

새로운 프레임워크의 첫 달은 유난히 찬란합니다.

원작자는 모든 것을 기억하고 있습니다. 애플리케이션은 크게 변하지 않았습니다. 의존성(dependencies)은 최신 상태입니다. 테스트 개수도 관리 가능한 수준입니다. 실패 사례들도 조사할 만큼 충분히 참신하게 느껴집니다.

경제성이 눈에 보이기 시작하는 시점은 바로 2년 차입니다.

새로운 엔지니어가 특정 헬퍼 (helper)가 왜 존재하는지 이해할 수 있는가?

QA가 TypeScript를 다시 작성하지 않고도 비즈니스 흐름 (business flow)을 수정할 수 있는가?

사용되지 않는 픽스처 (fixtures)를 식별할 수 있는가?

마이그레이션 프로젝트 없이 러너 (runner)를 업그레이드할 수 있는가?

10분 안에 제품 결함 (product defect)과 취약한 어설션 (brittle assertion)을 구분할 수 있는가?

유용한 평가는 이와 같은 운영 측면의 질문에 집중해야 합니다. 이것이 바로 빠르게 변화하는 프론트엔드에서 안정적인 실행을 위한 브라우저 테스트 도구 선택 가이드를 기능 체크리스트가 아닌 조직적 결정으로 읽어야 하는 이유이기도 합니다.

빠르게 변화하는 제품은 불분명한 소유권과 취약한 추상화 (abstractions)에 대가를 치르게 합니다.

반면, 변화 속에서도 가독성을 유지하는 시스템에는 보상을 제공합니다.

경량화 (Lightweight)는 검증이 필요한 약속이다

"경량화 (Lightweight)"라는 말은 매력적으로 들립니다. 아무도 또 다른 플랫폼 도입을 원하지 않기 때문입니다.

하지만 경량화는 여러 가지 서로 다른 의미를 가질 수 있습니다:

• 더 적은 기능;
• 더 적은 설정 (configuration);
• 더 작은 런타임 (runtime);
• 더 단순한 인터페이스;
• 더 적은 벤더 (vendor) 개입;
• 귀하의 팀에 더 많이 위임되는 작업.

마지막 의미는 종종 누락되곤 합니다.

작은 AI 러너를 도입하기 전에, 무엇이 포함되어 있는지와 무엇을 그 주변에 구축해야 하는지를 비교하십시오. 경량 AI 테스트 러너를 도입하기 전에 비교해야 할 사항은 단순한 원시 성능(raw capability)보다는 제품과 내부 엔지니어링 작업 사이의 경계에 관한 것입니다.

도구는 설치 규모 (installation footprint)는 매우 작을 수 있지만, 조직적 영향력 (organizational footprint)은 매우 클 수 있습니다.

그것이 반드시 틀린 것은 아닙니다. 단지 정직하게 가격이 책정되어야 할 뿐입니다.

구매(Buy) 대 구축(Build)은 이제 구축(Build) 대 지속적 재생성(Continuously Regenerate)이다

과거의 논쟁은 명확했습니다:

테스트 플랫폼을 구매할 것인가, 아니면 자체 프레임워크를 구축할 것인가?

AI는 느낌은 다르지만 종종 비슷하게 작동하는 세 번째 옵션을 도입했습니다:

AI를 사용하여 내부 프레임워크를 지속적으로 재생성하고 패치(patch)합니다.

이는 개별 변경 사항에 필요한 노동력을 줄여줄 수 있습니다. 하지만 아키텍처 (architecture), 리뷰 (review), 디버깅 (debugging), 보안 결정 (security decisions), 테스트 데이터 관리 (test data management), 릴리스 정책 (release policies), 그리고 유지보수 책임 (maintenance ownership)의 필요성을 제거하지는 않습니다.

AI는 구현의 속도를 변화시킵니다.

하지만 구현의 결과(consequences)를 없애지는 않습니다.

더 나은 질문은 "우리가 이것을 얼마나 빨리 생성할 수 있는가?"가 아닙니다.

다음과 같습니다:

우리가 팀에게 어떤 영구적인 책임을 부여하고 있는가?

그 질문은 지루하게 들릴 수 있지만, 이는 보통 그 질문이 유용하다는 신호입니다.

생성된 테스트 프레임워크는 분명히 올바른 선택이 될 수 있습니다. 하지만 프레임워크는 귀사의 회사가 판매하는 제품이 아닙니다. 그것은 제품을 지원하는 인프라 (infrastructure)입니다.

그에 따라 적절히 취급하십시오.

모델이 한 번에 4,000줄의 코드를 생성하는 것을 지켜보는 즐거움이 아니라, 신뢰성 (confidence), 이해 가능성 (comprehensibility), 그리고 유지보수 비용 (maintenance cost)을 최적화하십시오.