브라우저 자동화 (Browser automation)는 AI 기반 웹 애플리케이션에 여전히 필수적입니다.

사용자들은 여전히 버튼을 클릭하고, 양식을 제출하며, 대화 상자를 열고, 파일을 업로드하며, 인터페이스가 올바르게 작동하기를 기대합니다.

하지만 AI 제품은 일반적인 UI 어설션 (UI assertions)만으로는 완전히 설명할 수 없는 실패 사례들을 야기합니다.

모델이 잘못된 형식의 JSON을 반환하는 동안 페이지는 올바르게 렌더링될 수 있습니다. 지원 위젯 (support widget)이 정상적으로 답변하는 듯 보이지만 프롬프트 인젝션 (prompt injection) 이후 제한된 정보를 노출할 수도 있습니다. 브라우저 확장 프로그램 (browser extension)이 자체 패널 내에서는 작동하면서 호스트 애플리케이션을 조용히 망가뜨릴 수도 있습니다. 모니터링 시스템이 보고하는 회귀 (regression)가 실제로는 평가자 노이즈 (evaluator noise)일 수도 있습니다.

이러한 제품들을 테스트하려면 여러 계층이 함께 작동해야 합니다.

구조화된 출력 (Structured output)은 애플리케이션 계약입니다

많은 AI 기능은 모델이 구조화된 데이터를 반환하는 것에 의존합니다.

모델은 다음과 같은 것을 생성할 수 있습니다:

• JSON
• 액션 리스트 (A list of actions)
• 도구 인자 (Tool arguments)
• 분류 객체 (A classification object)
• 양식 필드 값 (Form-field values)
• 워크플로 계획 (A workflow plan)
• 인용 세트 (A set of citations)
• 스키마 제약 응답 (A schema-constrained response)

그러면 애플리케이션은 해당 응답을 파싱하여 사용할 수 있다고 가정합니다.

그 가정은 위험합니다.

모델은 실제 계약을 위반하면서도 유효해 보이는 출력을 반환할 수 있습니다:

• 필수 필드 누락
• 숫자가 문자열로 전달됨
• 열거형 (enum) 값이 변경됨
• JSON 앞에 산문 (Prose)이 나타남
• 객체가 구문론적으로는 유효하지만 의미론적으로 불가능함
• 중첩된 구조가 이전 스키마를 사용함
• 응답이 잘림 (truncated)

UI가 텍스트를 표시하는지만 확인하는 브라우저 테스트는 이러한 실패의 대부분을 놓치게 됩니다.

구조화된 출력 검증, JSON Schema 드리프트, 그리고 잘못된 페이로드 복구를 위한 AI 테스트 도구 평가에 관한 기사는 구조화된 출력을 여러 수준에서 테스트해야 하는 대상으로 규정합니다.

강력한 테스트는 다음을 검증해야 합니다:

1. 파싱 가능성 (Parseability)
2. 스키마 준수 (Schema compliance)
3. 필수 필드 (Required fields)
4. 허용된 값 (Allowed values)
5. 의미론적 일관성 (Semantic consistency)
6. 검증 실패 시 UI 동작 (UI behavior when validation fails)
7. 복구 및 재시도 동작 (Recovery and retry behavior)

또한 스키마 드리프트(schema drift) 및 깨진 JSON 응답에 대한 AI 테스트 도구 평가에 관한 집중 가이드가 있으며, 여기서는 중요한 실무적 요구 사항을 강조합니다: 테스트 시스템은 응답이 왜 실패했는지 설명하는 데 도움을 주어야 합니다.

"부적절한 출력(Invalid output)"이라는 말만으로는 충분하지 않습니다.

팀은 문제가 잘못된 형식의 JSON인지, 스키마 불일치인지, 누락된 필드인지, 아니면 제품 측의 파싱 버그인지 알아야 합니다.

모델이 자연스럽게 실패하기를 기다리지 마세요

비결정론적(Nondeterministic) 시스템에도 여전히 결정론적(Deterministic) 테스트가 필요합니다.

모델이 깨진 JSON을 반환할 때 UI가 복구되어야 한다면, 테스트가 모델을 반복적으로 호출하며 깨진 응답이 오기를 바라는 식이어선 안 됩니다.

가로채거나 시뮬레이션하십시오.

다음 항목들에 대한 피스처(Fixtures)를 생성하세요:

• 빈 응답 (Empty responses)
• 잘린 JSON (Truncated JSON)
• 잘못된 타입 (Invalid types)
• 알 수 없는 열거형 값 (Unknown enum values)
• 누락된 필수 속성 (Missing required properties)
• 예상치 못한 추가 필드 (Extra unexpected fields)
• 극도로 큰 출력 (Extremely large outputs)
• 거부 메시지 (Refusal messages)
• 제공자 타임아웃 (Provider timeouts)

그 다음 애플리케이션이 다음과 같은지 확인하십시오:

• 충돌(Crash)하지 않는지
• 가공되지 않은 파서 에러(Raw parser errors)를 노출하지 않는지
• 사용자에게 유용한 설명을 제공하는지
• 재시도 경로(Retry path)를 제공하는지
• 충분한 진단 정보를 기록하는지
• 안전하지 않은 동작을 반복하지 않는지

라이브 모델 테스트(Live-model tests)는 여전히 가치가 있지만, 이는 결정론적 계약 테스트(Deterministic contract tests)를 대체하기보다는 이를 보완하는 용도로 사용되어야 합니다.

프롬프트 인젝션은 제품 워크플로우의 문제입니다

프롬프트 인젝션(Prompt injection) 테스트는 종종 영리한 문구들의 집합처럼 취급되곤 합니다.

그것은 너무 좁은 시각입니다.

AI 지원 위젯은 계정 정보, 내부 도구, 고객 이력 또는 환불 및 구독 변경과 같은 작업에 접근할 수 있습니다. 진짜 보안 문제는 신뢰할 수 없는 콘텐츠가 시스템이 허용된 동작을 변경할 수 있는지 여부입니다.

유용한 테스트 전략은 다음 사항들을 포함해야 합니다:

• 직접적인 프롬프트 인젝션 (Direct prompt injection)
• 붙여넣은 콘텐츠에 숨겨진 지침 (Instructions hidden in pasted content)
• 외부 소스에서 가져온 악성 콘텐츠 (Malicious content retrieved from external sources)
• 시스템 규칙을 무시하려는 시도 (Attempts to override system rules)
• 내부 지침을 노출하라는 요청 (Requests to expose internal instructions)
• 권한 없이 도구를 호출하려는 시도 (Attempts to invoke tools without authorization)
• 사용자 간 데이터 접근 (Cross-user data access)
• 공격과 유사한 양성 메시지 (Benign messages that resemble attacks)

정상적인 사용자 흐름을 방해하지 않고 AI 지원 위젯의 프롬프트 인젝션 방어 체계를 테스트하는 방법에 관한 가이드는 마지막 항목이 특히 중요하다는 점을 시사합니다.

일반적인 고객의 질문을 차단하는 방어 체계는 좋은 방어 체계가 아닙니다.

보안 테스트는 다음 양면을 모두 검증해야 합니다:

• 악성 입력이 경계를 넘지 않는지
• 정당한 입력이 여전히 작동하는지

브라우저 확장 프로그램은 테스트해야 할 두 가지 제품을 생성합니다

AI 브라우저 확장 프로그램은 기존 애플리케이션을 변경할 필요 없이 보조 기능을 추가할 수 있기 때문에 점점 흔해지고 있습니다.

하지만 확장 프로그램은 타인의 페이지 내부에서 작동합니다.

이는 더 넓은 테스트 표면 (Test surface)을 생성합니다:

• 확장 프로그램 UI (Extension UI)
• 콘텐츠 스크립트 (Content scripts)
• 백그라운드 스크립트 (Background scripts)
• 브라우저 권한 (Browser permissions)
• 호스트 페이지 DOM (Host-page DOM)
• 호스트 페이지 스타일 (Host-page styles)
• 스토리지 (Storage)
• 싱글 페이지 네비게이션 (Single-page navigation)
• 확장 프로그램 업데이트 (Extension updates)
• 브라우저 업데이트 (Browser updates)

확장 프로그램이 자체 테스트를 통과하더라도 호스트 애플리케이션에 피해를 줄 수 있습니다.

다음과 같은 현상이 발생할 수 있습니다:

• 페이지를 위해 의도된 키보드 단축키를 캡처함
• 이벤트 전파 (Event propagation)를 변경함
• 전역 CSS를 주입함
• 중복된 ID를 추가함
• 드래그 앤 드롭 (Drag-and-drop) 동작을 망가뜨림
• 네비게이션 후 스스로를 재주입함
• Shadow DOM을 방해함
• 탭 간에 데이터를 노출함

기존 웹 페이지를 망가뜨리지 않고 기존 웹 앱에 AI를 주입하는 브라우저 확장 프로그램을 테스트하는 방법에 관한 기사는 왜 확장 프로그램 테스트가 주입된 기능(injected feature)과 그 아래에 있는 애플리케이션 모두에 대한 어설션 (assertion)을 필요로 하는지 보여줍니다.

유용한 호환성 스위트 (compatibility suite)는 다음과 같은 여러 호스트 페이지 패턴에 대해 확장 프로그램을 실행해야 합니다:

• 전통적인 멀티 페이지 애플리케이션 (multi-page applications)
• React 또는 Vue 싱글 페이지 애플리케이션 (single-page applications)
• Shadow DOM이 있는 페이지
• 리치 텍스트 에디터 (Rich-text editors)
• 엄격한 콘텐츠 보안 정책 (Content Security Policy)이 적용된 페이지
• 이미 글로벌 단축키를 사용하는 앱
• 가상화된 리스트 (virtualized lists)가 있는 페이지
• 빈번한 DOM 교체가 발생하는 사이트

확장 프로그램은 호스트 페이지 역시 성공적으로 유지될 때에만 성공적이라고 할 수 있습니다.

AI 품질에는 여러 계층의 증거가 필요합니다

브라우저 테스트는 다음과 같은 질문에 답할 수 있습니다:

• 사용자가 프롬프트 (prompt)를 제출했는가?
• 응답 (response)이 나타났는가?
• 재시도 (retry) 버튼이 작동했는가?
• 대화 내용이 유지되었는가?
• UI가 충돌했는가?

하지만 브라우저 테스트 자체만으로는 답변이 정확한지, 안전한지, 근거가 있는지 (grounded), 또는 정책을 준수하는지 판단할 수 없습니다.

이것이 바로 AI 품질 시스템에 종종 여러 계층이 포함되는 이유입니다:

• 브라우저 자동화 (Browser automation)
• 모델 평가 (Model evaluations)
• 실행 트레이스 (Execution traces)
• 구조화된 출력 검증 (Structured-output validation)
• 가드레일 (Guardrails)
• 정책 체크 (Policy checks)
• 인간 검토 (Human review)
• 프로덕션 모니터링 (Production monitoring)

에이전트형 애플리케이션을 위한 AI 테스트 마켓 맵 (AI testing market map for agentic applications)은 이러한 카테고리들이 어떻게 서로 맞물려 있는지 보여주는 유용한 개요입니다.

단일 계층만으로는 충분하지 않습니다.

모델 평가는 응답이 올바르다는 것을 확인할 수는 있지만, UI가 잘못된 고객 계정 아래에 응답을 표시했다는 점은 놓칠 수 있습니다.

브라우저 테스트는 응답이 나타났다는 것을 확인할 수는 있지만, 응답에 허구의 정보가 포함되었다는 점은 놓칠 수 있습니다.

트레이스 (trace)는 어떤 도구들이 호출되었는지는 보여줄 수 있지만, 최종 화면을 사용할 수 없는 상태로 만들었다는 점은 놓칠 수 있습니다.

각 레이어는 식별자(identifiers)와 증거(evidence)를 공유해야 하며, 이를 통해 하나의 실패가 스택 전체에 걸쳐 어떻게 이어지는지 추적할 수 있어야 합니다.

CI/CD 통합이 테스트의 가치를 결정합니다

한 달에 한 번 수동으로 실행되는 좋은 테스트는 가치가 제한적입니다.

테스트는 배포의 적절한 시점에 실행되고, 사람들이 조치를 취할 수 있는 신호(signals)를 생성할 때 비로소 운영 단계로 진입합니다.

CI/CD 파이프라인에 테스트 자동화를 통합하는 방법에 대한 가이드는 다음과 같은 일반적인 구성 요소들을 다룹니다:

• 풀 리퀘스트 (Pull-request) 체크
• 배포 검증 (Deployment verification)
• 예정된 회귀 테스트 실행 (Scheduled regression runs)
• 병렬 실행 (Parallel execution)
• 환경 설정 (Environment configuration)
• 결과 보고 (Result reporting)
• 릴리스 게이트 (Release gates)

AI 제품은 종종 하나의 거대한 스위트(suite)보다는 여러 개의 파이프라인을 필요로 합니다.

예를 들어:

풀 리퀘스트 (Pull request)

• 단위 테스트 (Unit tests)
• 스키마 검증 (Schema validation)
• 결정론적 모킹된 AI 케이스 (Deterministic mocked AI cases)
• 빠른 브라우저 스모크 테스트 (Fast browser smoke tests)

프리-릴리스 (Pre-release)

• 더 넓은 브라우저 커버리지 (Broader browser coverage)
• 라이브 모델 평가 (Live-model evaluations)
• 프롬프트 인젝션 (Prompt-injection) 시나리오
• 도구 호출 권한 테스트 (Tool-call authorization tests)
• 마이그레이션 및 하위 호환성 체크 (Migration and backward-compatibility checks)

프로덕션 모니터링 (Production monitoring)

• 합성 사용자 여정 (Synthetic user journeys)
• 지연 시간 (Latency) 체크
• 제공업체 가용성 (Provider availability)
• 출력 품질 샘플링 (Output-quality sampling)
• 가드레일 알림 (Guardrail alerts)
• 인간 에스컬레이션 (Human escalation)

이러한 방식은 모든 리스크를 모든 커밋마다 평가할 수 있는 것처럼 가장하지 않으면서도 피드백 속도를 빠르게 유지해 줍니다.

소규모 팀은 워크플로 비대화를 피해야 합니다

테스트가 확장됨에 따라, 팀들은 종종 더 많은 도구, 필드, 대시보드 및 승인 단계를 추가하는 방식으로 대응합니다.

이는 실제 테스트 속도를 늦추면서도 마치 성숙해진 것 같은 착각을 불러일으킬 수 있습니다.

소규모 QA 팀은 보통 다음과 같은 질문에 쉽게 답할 수 있게 해주는 테스트 관리 시스템 (test-management system)이 필요합니다:

• 무엇을 테스트하고 있는가?
• 무엇이 변경되었는가?
• 실패의 책임자는 누구인가?
• 어떤 릴리스가 영향을 받는가?
• 어떤 증거를 사용할 수 있는가?
• 무엇에 여전히 주의를 기울여야 하는가?

워크플로우의 비대화 없이 소규모 QA 팀을 위한 테스트 관리 도구를 선택하는 방법에 관한 가이드는 더 높은 설정 가능성(configurability)이 반드시 더 큰 가치를 의미하는 것은 아니라는 점을 유용한 시사점으로 상기시켜 줍니다.

가장 좋은 워크플로우는 종종 소유권과 릴리스 리스크(release risk)를 명확하게 유지하는 가장 단순한 워크플로우입니다.

아무도 업데이트하지 않는 40개의 커스텀 필드(custom fields)가 있는 시스템은 팀이 실제로 따르는 단순한 프로세스보다 유용성이 떨어집니다.

AI 제품에도 크로스 브라우저(Cross-browser) 커버리지는 여전히 중요합니다

AI 애플리케이션은 대부분 채팅 인터페이스를 갖춘 백엔드(backend) 시스템이라고 가정하기 쉽습니다.

하지만 실제로는 브라우저 레이어(browser layer)가 복잡할 수 있습니다:

• 스트리밍 응답 (Streaming responses)
• 리치 텍스트 렌더링 (Rich-text rendering)
• 클립보드 액세스 (Clipboard access)
• 파일 업로드 (File uploads)
• 마이크 권한 (Microphone permissions)
• 팝오버 (Popovers)
• 가상화된 대화 (Virtualized conversations)
• 브라우저 스토리지 (Browser storage)
• 확장 프로그램 API (Extension APIs)
• 인증 리다이렉트 (Authentication redirects)

이러한 기능들은 Chromium, Firefox, Safari에 따라 다르게 동작할 수 있습니다.

외부 QA 파트너를 평가할 때, “크로스 브라우저 테스트 (cross-browser testing)”라는 문구만으로는 충분하지 않습니다. 팀은 파트너가 브라우저별 조사(investigation), 버전 커버리지(version coverage), 환경 설정(environment setup), 그리고 증거(evidence)를 어떻게 처리하는지 물어야 합니다.

Chromium, Firefox, Safari에 대한 크로스 브라우저 커버리지를 위한 QA 파트너 평가 방법에 관한 기사는 실질적인 체크리스트를 제공합니다.

질문할 가치가 있는 사항들은 다음과 같습니다:

• 테스트가 실제로 세 가지 엔진 모두에서 실행되는가?
• 어떤 브라우저 버전들이 커버되는가?
• 모바일 브라우저가 포함되어 있는가?
• 브라우저별 버그를 어떻게 재현하는가?
• 실패 사례를 단순히 “Safari 문제”로 치부해 버리는가?
• 어떤 로그(logs)와 녹화본(recordings)이 제공되는가?
• 브라우저 업데이트 이후 얼마나 빠르게 커버리지를 확장할 수 있는가?

크로스 브라우저 커버리지는 그것이 진단(diagnosis)으로 이어질 때에만 가치가 있습니다.

도구 선택은 불확실성을 줄여야 합니다

AI 기반 웹 애플리케이션을 위한 테스트 스택은 빠르게 복잡해질 수 있습니다.

다음과 같은 요소들이 포함될 수 있습니다:

• 브라우저 자동화 프레임워크 (Browser automation framework)
• 모델 평가 플랫폼 (Model-evaluation platform)
• 트레이스 뷰어 (Trace viewer)
• 스키마 검증기 (Schema validator)
• 보안 테스트 레이어 (Security-testing layer)
• 테스트 관리 도구 (Test-management tool)
• CI 시스템 (CI system)
• 모니터링 서비스 (Monitoring service)
• 외부 QA 파트너 (External QA partner)

목표는 모든 카테고리를 수집하는 것이 되어서는 안 됩니다.

목표는 릴리스(release)에 대한 불확실성을 줄이는 것이어야 합니다.

도구는 다음과 같은 질문 중 하나에 더 쉽게 답할 수 있게 해줄 때 유용합니다:

• 제품이 올바르게 동작했는가?
• 모델 출력(model output)이 유효했는가?
• 시스템이 권한(permissions) 내에서 유지되었는가?
• 실패를 재현(reproduce)할 수 있는가?
• 어떤 레이어(layer)에서 문제가 발생했는가?
• 이 이슈가 릴리스를 차단하고 있는가?
• 누가 조치를 취해야 하는가?

만약 스택이 이해(understanding)보다 더 많은 알림(alerts)을 생성한다면, 그것은 품질을 개선하고 있는 것이 아닙니다.

마지막 생각

AI 기반 웹 애플리케이션을 테스트하는 것은 브라우저 자동화(browser automation)를 대체하는 것이 아닙니다.

그것은 브라우저 자동화의 확장입니다.