클로드 코드와 Playwright로 E2E 테스트를 정리하며 적어둔 메모
E2E 테스트는 중요하지만 늘 뒤로 밀리기 쉬운 작업입니다. 범위가 넓고, 깨지는 이유도 다양해서 꾸준히 관리하기가 쉽지 않기 때문입니다. 이번 글은 클로드 코드의 서브 에이전트 구조를 Playwright 테스트에 적용해 보며, 어떤 방식이 실제로 편했는지 메모처럼 정리한 내용입니다.
1. E2E 테스트가 늘 버거운 이유
E2E 테스트는 로그인부터 저장, 이동, 렌더링까지 실제 사용자 흐름을 따라가야 해서 관리 비용이 큽니다. 작은 화면 변경이나 비동기 타이밍만 흔들려도 금방 실패하고, 실패 원인을 좁히는 데도 시간이 꽤 듭니다. 그래서 많은 팀에서 필요성은 알지만 계속 뒤로 미루게 됩니다.
Playwright는 Chromium, Firefox, WebKit 세 엔진을 하나의 API로 다룰 수 있고, auto-wait 기능이 기본 내장되어 있어 Selenium이나 Cypress보다 비동기 타이밍 문제에 덜 시달립니다. 특히 page.waitForLoadState('networkidle') 같은 옵션으로 네트워크 안정 시점을 직접 기다릴 수 있어, SPA 환경에서 화면 전환 후 데이터 로딩이 끝났는지 확인하는 과정이 한결 단순해집니다. Cypress가 브라우저 내부에서 실행되는 구조인 반면, Playwright는 브라우저 외부에서 CDP(Chrome DevTools Protocol)로 제어하기 때문에 멀티탭이나 팝업 처리도 자연스럽습니다.
문제는 실제 장애가 이런 구간에서 자주 나온다는 점입니다. 단위 테스트만으로는 잡기 어려운 화면 간 연결 문제를 보려면, 결국 끝에서 끝까지 검증하는 흐름이 필요합니다.
2. 서브 에이전트 구조가 편했던 지점
서브 에이전트 구조를 써보며 느낀 장점은 한 세션에 모든 문맥을 몰아넣지 않아도 된다는 점이었습니다. 메인 에이전트가 전체 흐름을 보고, 세부 작업은 각 에이전트가 맡는 식으로 나누면 역할이 더 선명해집니다.
특히 테스트처럼 설계, 구현, 실패 복구가 섞인 작업에서는 이 분리가 꽤 유용했습니다. 누가 어떤 책임을 맡는지 분명해지면, 실패를 다시 검토하기도 편해집니다.
3. Plan, Gen, Heal로 나눠본 흐름
이번에는 플래너가 시나리오를 먼저 정리하고, 제너레이터가 테스트 코드를 만들고, 힐러가 실패 케이스를 다시 보는 흐름으로 나눠봤습니다. 이렇게 하니 "무엇을 테스트해야 하는지"와 "어떻게 고칠지"가 섞이지 않아 더 편했습니다.
병렬 실행도 유용했지만, 핵심은 동시에 많이 돌리는 것보다 서로 의존성이 적은 작업을 잘 나누는 일이었습니다. 인증 상태나 데이터 생성이 얽힌 테스트는 무작정 같이 돌리면 오히려 더 불안정해질 수 있어서, 순서를 나누는 판단이 중요했습니다.
실무에서 느낀 Plan-Gen-Heal 분리의 효과
가장 체감이 컸던 장면은 테스트가 실패했을 때였습니다. 이전에는 "왜 실패했는지 분석 → 코드 수정 → 재실행"을 한 흐름에서 처리하다 보니, 수정한 코드가 다른 테스트를 깨뜨리는 일이 잦았습니다. Heal 단계를 분리하고 나서는, 실패 원인만 먼저 좁히고 수정은 별도 사이클로 넘기는 식이 되어 되돌림이 훨씬 줄었습니다. 결국 속도보다 "되돌리지 않는 흐름"이 전체 시간을 더 줄여줬습니다.
4. 원스의 메모
이 기능을 보며 가장 크게 느낀 점은, 앞으로 개발자는 직접 타이핑하는 사람보다 작업을 설계하고 조율하는 사람 쪽에 더 가까워질 수 있다는 점이었습니다. 테스트 자동화에서도 무엇을 핵심 시나리오로 볼지, 어떤 실패는 바로 고치고 어떤 실패는 보류할지 정하는 판단이 계속 중요합니다.
그래서 이 글도 "혁명"을 말하는 글보다는, 실제로 어떤 식으로 역할을 나누니 관리가 편했는지 남겨두는 메모에 가깝습니다. 도구는 바뀌어도 구조를 잘 쪼개고 검토 기준을 세우는 감각은 계속 중요할 것 같습니다.
정리하면, 클로드 코드와 Playwright 조합에서 가장 인상 깊었던 지점은 속도 자체보다 역할 분리와 문맥 정리였습니다. 작업을 잘 나눌수록 테스트를 다시 보고 고치는 일도 덜 복잡해졌습니다.
댓글
댓글 쓰기