초록색 CI (Continuous Integration) 파이프라인은 안심을 줍니다.

빌드가 완료되었습니다. 유닛 테스트 (Unit Test)가 통과했습니다. 브라우저 스위트 (Browser Suite)는 100%를 보고했습니다. 풀 리퀘스트 (Pull Request)는 머지 (Merge)할 준비가 되었습니다.

하지만, 그럼에도 불구하고 배포는 여전히 망가질 수 있습니다.

이런 일은 항상 가능했지만, 프론트엔드 (Frontend) 시스템이 더욱 동적으로 변하고 팀들이 생성된 코드 (Generated Code), 피처 플래그 (Feature Flags), 제3자 서비스 (Third-party Services), 비동기 컴포넌트 (Asynchronous Components), 그리고 AI 보조 개발 (AI-assisted Development)에 더 많이 의존함에 따라 더욱 흔해지고 있습니다.

문제는 반드시 테스트가 나쁘다는 것이 아닙니다. 문제는 우리가 훨씬 더 큰 질문에 답하기 위해 이진법적인 테스트 결과 (Binary Test Result)에 계속해서 질문을 던지고 있다는 점입니다:

이 배포는 출시하기에 충분히 안전한가?

통과율 (Pass Rate)만으로는 그 질문에 답할 수 없습니다.

통과율은 너무 많은 맥락을 제거합니다

스위트에 500개의 브라우저 테스트가 있고 그중 495개가 통과한다고 가정해 봅시다.

99%의 통과율은 좋아 보이지만, 그 숫자는 배포 위험에 대해 거의 아무것도 알려주지 않습니다.

다섯 번의 실패는 다음과 같을 수 있습니다:

• 중요하지 않은 내부 설정 페이지에서의 알려진 플래키 테스트 (Flaky Test).
• 결제 (Checkout), 인증 (Authentication), 또는 계정 복구 (Account Recovery)에서의 새로운 실패.
• 중요한 테스트 실행을 방해한 인프라 (Infrastructure) 실패.
• 애플리케이션이 이미 손상된 상태에 진입한 후 실패한 어설션 (Assertions).
• 세 번의 재시도 후에야 통과한 테스트.

이러한 상황들은 동일한 배포 결정을 내려서는 안 됩니다.

이는 AI를 통합하는 시스템에서 특히 중요합니다. AI 기반 기능을 위한 유용한 CI 신호는 최종 화면이 나타났는지 여부 그 이상을 포착해야 합니다. 출력 가변성 (Output Variability), 폴백 동작 (Fallback Behavior), 응답 지연 시간 (Response Latency), 안전 제어 (Safety Controls), 그리고 기능이 유효하지 않거나 불완전한 응답으로부터 복구할 수 있는지 여부를 평가해야 할 수도 있습니다.

그렇기 때문에 팀들은 통과율을 신뢰하는 대신 AI 테스트 신뢰성을 위한 CI 신호를 구축하는 것에 대해 고민해야 합니다.

목표는 통과/실패 (Pass/Fail) 결과를 대체하는 것이 아닙니다. 그것들을 맥락 속에 두는 것입니다.

배포 신호는 여러 종류의 증거를 결합해야 합니다

더 나은 배포 결정을 내리기 위해서는 다음 사항들을 고려할 수 있습니다:

• 어떤 제품 영역이 변경되었는가.
• 어떤 테스트가 해당 영역을 커버했는가.
• 중요한 테스트가 누락되지는 않았는가.
• 통과된 테스트 중 재시도 (Retries)가 필요했던 것이 있는가.
• 실패 패턴이 새로운 것인가, 아니면 이미 파악된 것인가.
• 시각적 또는 동작적 변화가 예상된 것이었는가.
• 운영 환경 (Production)의 에러 신호가 개선되고 있는가, 아니면 악화되고 있는가.
• 테스트 환경이 운영 환경을 잘 나타내고 있는가.
• 실패를 조사하기에 충분할 만큼 증거가 완전한가.

이를 통해 CI (지속적 통합, Continuous Integration)는 단순한 체크박스 확인 절차에서 증거의 원천으로 변모합니다.

실질적인 시작점으로는 AI 지원 프론트엔드 변경을 위한 배포 리스크 체크리스트가 있습니다. 작은 체크리스트 하나만으로도 팀은 무엇이 변경되었는지, 어떻게 검증되었는지, 그리고 해피 패스 (Happy path) 이외에 무엇이 실패할 수 있는지를 반드시 고려하게 됩니다.

이 체크리스트가 거대한 승인 프로세스가 될 필요는 없습니다. 기존의 풀 리퀘스트 (Pull request) 워크플로우 위에 가벼운 계층으로 추가될 수 있습니다.

초록색 체크 표시가 불완전한 실행을 숨길 수 있습니다

가장 위험한 CI 결과 중 하나는 테스트 실패가 아닙니다. 바로 실행되지 않은 테스트입니다.

이는 다음과 같은 이유로 발생할 수 있습니다:

• 조건부 CI 규칙.
• 잘못된 테스트 필터.
• 사용 불가능한 테스트 환경.
• 경고 (Warning)로 분류된 설정 (Setup) 실패.
• 중요한 시나리오가 실행되기 전에 작업을 종료시키는 타임아웃 (Timeout).
• 특정 구성을 조용히 제외해 버리는 브라우저 매트릭스 (Browser matrix).
• 이름이 변경되어 더 이상 발견되지 않는 테스트 파일.

실행된 모든 테스트가 통과했다면, 파이프라인은 여전히 초록색으로 보일 수 있습니다.

이것이 바로 초록색 CI가 동적 애플리케이션에서 프론트엔드 회귀 (Regressions)를 숨길 수 있는 이유입니다. 배포 신호에는 단순히 우연히 실행된 테스트의 결과뿐만 아니라, 실행의 완전성 (Execution completeness)이 포함되어야 합니다.

최소한, 저는 다음 사항들을 알고 싶습니다:

1. 예상된 테스트는 몇 개인가?
2. 실제로 실행된 테스트는 몇 개인가?
3. 어떤 중요한 시나리오(Critical scenarios)가 건너뛰어졌는가?
4. 어떤 브라우저 및 환경 조합이 커버되었는가?
5. 재시도(Retry) 후에만 통과된 테스트가 있는가?

재시도는 인프라 불안정성(Infrastructure instability)을 진단하는 데 유용할 수 있지만, 재시도를 통해 통과된 결과가 처음부터 깨끗하게 통과된 결과와 동일하게 취급되어서는 안 됩니다.

AI 지원 풀 리퀘스트(Pull requests)에는 다른 리뷰 마인드셋이 필요합니다

AI는 그럴듯한 프론트엔드 코드를 매우 빠르게 대량으로 생성할 수 있습니다.

그 속도는 유용하지만, 리뷰의 경제성(Economics of review)을 변화시킵니다. 변경 사항을 생성하는 비용은 저렴해지는 반면, 전체적인 동작 영향(Behavioral impact)을 이해하는 비용은 더 비싸질 수 있습니다.

생성된 풀 리퀘스트(Pull request)는 다음과 같은 일을 할 수 있습니다:

• 로딩 동작(Loading behavior)을 수정함.
• 새로운 의존성(Dependency)을 도입함.
• 에러 핸들링(Error handling)을 변경함.
• 캐시 레이어(Cache layer)를 추가함.
• 상태가 유지(State is persisted)되는 방식을 변경함.
• 기존 테스트가 절대 도달하지 못하는 폴백 경로(Fallback path)를 추가함.
• 관련 없는 페이지에서 사용되는 공유 컴포넌트(Shared component)를 재작성함.

코드는 합리적으로 보일 수 있지만, 결과적인 동작은 미묘하게 틀릴 수 있습니다.

유용한 접근 방식은 초록색 체크 표시(Green checks)만 신뢰하지 않고 AI 지원 풀 리퀘스트를 위한 QA 신호를 구축하는 것입니다. 이 신호는 단순히 현재의 테스트 스위트가 에러를 발견했는지 여부가 아니라, 변경 사항의 범위와 리스크를 고려해야 합니다.

인증(Authentication), 결제(Billing), 스토리지(Storage), 권한(Permissions) 또는 공유 내비게이션(Shared navigation)을 건드리는 AI 생성 변경 사항은 사소하고 고립된 스타일 조정보다 더 많은 정밀 조사(Scrutiny)를 받아야 합니다.

프로덕션 에러 트래킹은 증거이지, 증명이 아닙니다

프론트엔드 에러 트래킹(Error tracking)은 팀들이 때때로 과도하게 신뢰하는 또 다른 신호입니다.

릴리스 후 JavaScript 에러의 뚜렷한 증가가 나타나지 않더라도 심각한 회귀(Regressions)가 발생할 수 있습니다. 아마도 사용자가 에러가 발생할 페이지에 도달하지 못하는 것일 수도 있습니다. 버튼이 더 이상 반응하지 않지만 예외(Exception)를 발생시키지 않을 수도 있습니다. 기술적인 에러를 생성하지 않으면서 잘못된 상태가 표시될 수도 있습니다.

에러 트래킹 (Error tracking)을 릴리스 게이트 (Release gate)로 사용하기 전에, 팀은 릴리스 결정을 위해 프론트엔드 에러 트래킹을 신뢰하기 전 무엇을 측정해야 하는지 결정해야 합니다.

유용한 질문들은 다음과 같습니다:

• 이벤트가 릴리스 버전과 연결되어 있는가?
• 에러를 영향을 받은 워크플로 (Workflow)별로 그룹화할 수 있는가?
• 소스 맵 (Source maps)을 사용할 수 있는가?
• 기존의 노이즈 (Noise)와 새로운 에러를 구분할 수 있는가?
• 발생한 예외 (Exceptions)뿐만 아니라 실패한 사용자 액션 (User actions)도 측정하는가?
• 에러가 브라우저, 디바이스, 지리적 위치, 그리고 피처 플래그 (Feature flags)와 상관관계가 있는가?

에러 트래킹은 가치가 있지만, 특정 릴리스 및 특정 사용자 여정 (User journey)과 연결될 수 있을 때 훨씬 더 유용해집니다.

테스트 증거는 조사를 뒷받침해야 합니다

맥락 (Context) 없는 실패 결과는 업무를 줄여주는 대신 오히려 업무를 생성합니다.

브라우저 테스트가 실패할 때, 팀에는 다음과 같은 것들이 필요할 수 있습니다:

• 스크린샷 (Screenshots).
• 비디오 (Video).
• 브라우저 콘솔 출력 (Browser console output).
• 네트워크 활동 (Network activity).
• 단계별 타이밍 (Step-level timing).
• 애플리케이션 로그 (Application logs).
• 테스트 데이터 식별자 (Test data identifiers).
• 브라우저 및 운영 체제 (Operating system) 정보.
• 정확한 애플리케이션 버전.
• 관련 피처 플래그 (Feature flags)의 상태.
• 재시도 (Retries) 및 이전 시도에 대한 기록.

이것이 바로 AI 테스트 시스템을 평가하는 팀이 실행 증거, 재생 가능성, 그리고 근본 원인 분류 (Root-cause triage)를 확인해야 하는 이유입니다.

실패를 보고하지만 이를 설명하는 데 도움을 주지 못하는 도구는 유지보수 부담을 가중시킬 수 있습니다. 중요한 지표는 시스템이 얼마나 많은 실패를 감지하느냐뿐만 아니라, 팀이 각 실패가 제품 결함 (Product defect), 테스트 결함 (Test defect), 또는 환경 문제 (Environmental problem)인지 얼마나 효율적으로 결정할 수 있느냐입니다.

더 많은 모킹 (Mocks)이 자동으로 더 나은 테스트 스위트를 만들지는 않습니다

모킹 (Mocks)은 유용합니다. 테스트를 더 빠르게 만들고, 드문 상황을 재현하는 데 도움을 주며, 불안정한 서비스에 대한 의존성을 줄여줍니다.

하지만 모킹 (Mocks)은 애플리케이션의 가상의 버전을 점진적으로 만들어낼 수도 있습니다.

팀이 더 많은 피스처 (Fixtures), 헬퍼 (Helpers), 인터셉터 (Interceptors), 그리고 공유 설정 코드 (Shared setup code)를 추가함에 따라, 테스트 스위트 (Test suite)는 더 느려지고 이해하기 어려워질 수 있습니다. 아이러니하게도 테스트를 단순화하기 위해 도입된 추상화 (Abstractions)가 결국 디버깅이 필요한 또 다른 내부 프레임워크가 되어버릴 수 있습니다.

팀이 더 많은 모킹, 피스처, 공유 헬퍼를 추가한 후 프론트엔드 테스트 스위트가 왜 느려지는지에 대한 유용한 조사가 있습니다.

문제는 모킹 그 자체가 아닙니다. 명확한 경계 없이 모킹을 사용하는 것이 문제입니다.

저는 보통 시나리오를 세 가지 그룹으로 나눕니다:

• 제어된 모킹 응답 (Controlled mock responses)을 사용해야 하는 테스트.
• 실제 서비스와의 통합 (Integration)을 검증해야 하는 테스트.
• 두 방식 모두로 실행해야 하는 테스트.

결정은 해당 시나리오가 무엇을 증명하려는가에 달려 있습니다. 엔드 투 엔드 (End-to-end) 테스트에서 언제 API를 모킹하고 언제 실제 서비스를 사용해야 하는지에 대한 분류는 그러한 선택을 내리는 데 유용한 프레임워크가 됩니다.

모킹된 결제 응답은 UI가 거절 메시지를 올바르게 처리하는지 확인할 수 있습니다. 하지만 프로덕션 결제 통합 (Production payment integration)이 올바르게 구성되었는지는 증명할 수 없습니다.

빌드 마이그레이션은 제품 요구사항을 변경하지 않고도 동작을 변경할 수 있습니다

하나의 프론트엔드 빌드 도구에서 다른 도구로의 마이그레이션 (Migration)은 인프라 프로젝트처럼 보일 수 있습니다.

제품은 변경되지 않은 것으로 간주되므로, 팀은 기존의 브라우저 테스트가 계속 통과할 것이라고 기대합니다.

실제로 빌드 마이그레이션은 다음과 같은 것들을 변경할 수 있습니다:

• 청크 로딩 순서 (Chunk loading order).
• 에셋 경로 (Asset paths).
• 모듈 초기화 (Module initialization).
• 환경 변수 (Environment variables).
• 개발 및 프로덕션 환경의 동일성 (Development and production parity).
• 캐시 동작 (Cache behavior).
• 소스 맵 (Source maps).
• 하이드레이션 (Hydration)과 상호작용 (Interaction) 사이의 타이밍.
• 동적 임포트 (Dynamic imports)가 실패하거나 복구되는 방식.

그렇기 때문에 프론트엔드 빌드 도구 마이그레이션 이후 E2E 테스트가 실패하기 시작할 수 있으며, 이는 아무도 의도적으로 사용자 워크플로 (User workflow)를 변경하지 않았을 때도 발생합니다.

이러한 실패는 종종 유용합니다. 이는 이전 빌드 설정 (Build configuration) 내부에 숨겨져 있던 가설들을 드러내 줍니다.

이를 "마이그레이션 노이즈 (Migration noise)"로 치부하여 억제하는 것은, 테스트가 제공하도록 설계된 바로 그 증거를 제거하는 결과가 될 수 있습니다.

브라우저 인프라 (Browser infrastructure)는 릴리스 계산에 포함되어야 합니다

테스트 프레임워크 (Test framework)는 브라우저 자동화 (Browser automation)의 일부분일 뿐입니다.

팀은 또한 다음과 같은 요소들을 운영하거나 구매해야 합니다:

• 브라우저 (Browsers) 및 운영 체제 (Operating systems).
• 병렬 실행 능력 (Parallel execution capacity).
• CI 워커 (CI workers).
• 테스트 환경 (Test environments).
• 비디오, 스크린샷 및 로그 (Videos, screenshots, and logs).
• 네트워크 격리 (Network isolation).
• 결과 저장소 (Result storage).
• 액세스 제어 (Access control).
• 재시도 및 스케줄링 시스템 (Retry and scheduling systems).
• 디버깅 워크플로 (Debugging workflows).

이는 초기 개념 증명 (Proof of concept) 단계에서 종종 간과되는 Selenium Grid 대 Playwright CI 예산의 중요한 부분입니다.

프레임워크 자체는 무료일 수 있지만, 전체 테스트 시스템을 구축하고 유지하는 데는 여전히 많은 비용이 들 수 있습니다.

올바른 질문은 단순히 "어떤 라이브러리가 라이선스 비용이 없는가?"가 아닙니다.

다음과 같아야 합니다:

어떤 접근 방식이 지속 가능한 총비용으로 팀에게 신뢰할 수 있는 릴리스 증거를 제공하는가?

테스트 데이터 품질은 신호의 신뢰성에 영향을 미칩니다

AI가 생성한 테스트 데이터는 더 다양한 시나리오를 만드는 데 도움이 될 수 있지만, 생성된 데이터가 자동으로 현실적이거나 안전한 것은 아닙니다.

데이터에 의존하기 전에 팀은 다음 사항을 평가해야 합니다:

• 민감한 운영 데이터 (Production information)가 프롬프트 (Prompts)에 유출될 수 있는지 여부.
• 생성된 레코드 (Records)가 비즈니스 제약 조건 (Business constraints)을 준수하는지 여부.
• 엣지 케이스 (Edge cases)가 진정으로 유용한지, 아니면 단순히 무작위인지 여부.
• 동일한 데이터셋 (Dataset)을 재현할 수 있는지 여부.
• 데이터가 실제 고객 행동을 나타내는지 여부.
• 실패 원인을 정확히 생성된 입력값 (Inputs)으로 추적할 수 있는지 여부.

개인정보 보호, 충실도 및 엣지 케이스(edge cases)를 위한 AI 테스트 데이터 생성 평가 방법에 대한 사려 깊은 가이드는 적절한 우려 사항들을 다룹니다.

더 많은 데이터가 반드시 더 나은 커버리지 (coverage)를 의미하지는 않습니다. 생성된 데이터는 의미 있는 리스크 (risks)를 타겟팅해야 합니다.

배포 준비 상태는 테스트 결과가 아니라 결정입니다

AI 코파일럿 (AI copilots)은 주변 워크플로 (workflow)를 변경하지 않고도 UI 텍스트, 제안, 자동 완성 동작을 변경할 수 있기 때문에 또 다른 층위의 불확실성을 도입합니다.