NAVER D2의 **「AI 에이전트를 위한 Playwright E2E 테스트 하네스 구축하기」**는 AI 코딩 에이전트가 만든 코드를 사람이 매번 직접 검증하지 않고, **Playwright 기반 E2E 테스트를 이용해 에이전트가 스스로 검증·디버깅·수정하도록 만드는 하네스 엔지니어링** 사례를 다룹니다. ## 왜 E2E 테스트가 다시 중요해졌나 AI 에이전트 도입으로 코드 작성 속도는 빨라졌지만 검증이 병목이 되기 시작했습니다. 특히 단위 테스트만 통과해도 실제 브라우저에서는 Middleware, Server-side Logic, Component, API, Browser State 사이의 경계에서 오류가 생길 수 있습니다. ## Harness Engineering 관점 하네스는 모델 가중치 바깥에서 에이전트가 더 잘 일하도록 돕는 모든 환경입니다. - AGENTS.md 같은 지침 - Skill - MCP - LLM Wiki - Lint / Type Check - Automated Test 이번 발표에서 핵심 검증 Harness는 **Playwright E2E Test**입니다. ## 브라우저 조작만으로는 부족하다 Playwright MCP 같은 도구로 에이전트가 브라우저를 직접 조작할 수 있지만 매번 자연어로 시나리오를 해석하게 하면 느리고, Token을 많이 쓰고, 비결정적입니다. 그래서 반복 실행 가능한 **결정론적 테스트 코드**가 필요합니다. ## Playwright의 장점 Playwright는 실제 브라우저에서 실제 사용자 흐름을 검증합니다. 예: **페이지 이동 → 버튼 클릭 → 결과 표시 확인** 을 그대로 자동화합니다. 테스트 코드는: **읽으면 Specification** **실행하면 Verification** 역할을 동시에 합니다. ## Trace가 Agent에게 좋은 이유 Playwright Trace에는: - Screenshot - Video - DOM Snapshot - Console Log - Network Request/Response - Action History - Error Stack 같은 정보가 남습니다. 이 덕분에 Agent가 사람 개발자처럼 DevTools를 보듯 실패 원인을 추적할 수 있습니다. 즉: **Test Failure → Trace 분석 → 원인 추론 → 코드 수정** 루프가 가능해집니다. ## 무엇을 테스트할까 모든 기능을 E2E로 검증하기보다 **Critical User Flow**에 집중합니다. 예: - 약관 동의 - 본인 인증 - 결과 조회 - 상품 신청 처럼 깨졌을 때 서비스 핵심 가치가 무너지는 흐름입니다. ## Agent가 테스트를 잘 작성하게 만드는 네 가지 Harness ### 1. AGENTS.md 서비스 구조, 핵심 Flow, 인증 방식, 접근 제어 등 프로젝트 Context를 설명합니다. ### 2. E2E 전용 Single Source of Truth 테스트 작성 규칙, 실행 환경, 인증 방식, 테스트 범위와 제외 범위를 문서화합니다. ### 3. Helper / Utility 인증, 상태 초기화, 테스트 데이터 준비 같은 반복 작업을 재사용 가능하게 만듭니다. ### 4. MCP 기획서, 디자인, 이슈, PR 같은 사내 Context에 Agent가 접근하도록 합니다. ## Planner → Generator → Healer 발표에서는 테스트 자동화를 세 역할로 나눕니다. ### Planner 관련 코드와 이슈를 분석해 Test Plan 작성 ### Generator 승인된 Plan을 기반으로 Playwright Test 작성 ### Healer 실패한 Test와 Trace를 분석해 수정 전체 흐름은: **Requirement → Plan → Human Review → Test Generate → Run → Failure → Heal → Re-run** 입니다. ## 테스트 독립성 여러 시나리오가 공통된 앞단계를 반복하면 실행 시간이 길어지고 공통 부분이 깨질 때 테스트가 줄줄이 실패할 수 있습니다. 그래서 각 테스트가 검증하려는 갈래의 시작 상태를 API로 미리 세팅해 독립적으로 실행되도록 구성합니다. ## 외부 의존성은 통제한다 외부 인증, 전자문서, 앱 연동 같은 서비스까지 실제로 호출하면 느리고 불안정해집니다. Playwright의 route mocking이나 테스트 환경의 고정 응답을 사용해 **우리가 통제할 수 있는 영역만 검증**하는 전략을 사용합니다. ## Flaky Test 예방 Flaky Test는 테스트 신뢰도를 빠르게 무너뜨립니다. 발표에서는: - 하드코딩된 sleep/timeout 대신 조건 기반 대기 - CSS 구조보다 role/name 같은 Semantic Selector - 작성 직후 반복 실행으로 burn-in 을 사용합니다. ## CI까지 연결 PR이 올라오면 CI에서 E2E Test를 실행하고 실패하면 Merge를 차단합니다. 실패 시 Trace Artifact를 남기고, Agent가 이를 다운로드해 원인을 분석한 뒤 수정하도록 합니다. 즉 개발자와 동일하게: **PR → CI Failure → Trace 확인 → 수정 → 재실행** 을 Agent가 수행합니다. ## Self-Improvement Loop 이 구조가 만들어지면 Agent는: 1. 코드를 작성하고 2. 테스트하고 3. 실패를 관찰하고 4. 수정하고 5. 다시 테스트합니다. 이것이 발표에서 말하는 **자가 개선 루프**입니다. ## Guide와 Sensor 자가 개선 루프에는 두 가지가 필요합니다. ### Guide 행동 전에 방향을 잡아주는 것 - AGENTS.md - Skill - MCP - 문서 ### Sensor 행동 후 결과를 측정하는 것 - Test - Lint - Type Check - Playwright E2E 특히 Playwright Test는 독특하게도 **Guide와 Sensor 역할을 동시에** 합니다. 코드를 읽으면 사용자 명세이고, 실행하면 검증 도구이기 때문입니다. ## Evaluator-Optimizer와의 연결 LLM이 답을 만들고 다른 LLM이 평가하는 Evaluator-Optimizer 패턴도 있지만, 평가를 LLM에만 맡기면 비싸고 비결정적일 수 있습니다. Playwright는 이 평가 자리에 들어가는 **결정론적이고 빠른 검증기** 역할을 합니다. ## 사람은 무엇을 해야 하나 사람의 역할은 사라지지 않습니다. 오히려 더 상위 수준으로 이동합니다. - 어떤 User Flow가 중요한지 결정 - 어떤 Context를 Agent에게 제공할지 설계 - 어떤 테스트 전략을 쓸지 결정 - 어떤 외부 의존성을 Mock할지 결정 - Agent의 Plan을 검토 - Harness 자체를 계속 개선 하는 역할입니다. ## 핵심 정리 이번 발표의 핵심은: > **AI에게 더 좋은 Prompt를 주는 것보다, 스스로 검증하고 고칠 수 있는 환경을 만들어 주는 것이 더 중요해지고 있다.** 는 점입니다. 한 줄로 정리하면: **Agent + Guide + Playwright Sensor + CI + Repair Loop = Self-Improving Coding Workflow** 입니다.