웹 개발을 하다 보면 항상 마주치는 딜레마가 있다. 새로운 기능을 추가하거나 기존 코드를 수정할 때마다 "혹시 다른 기능이 망가지지 않았을까?"하는 불안감 말이다. 특히 AI 코딩 시대에는 코드 변경이 더욱 빈번해지면서 이런 걱정이 더욱 커지고 있다.
End-to-End 테스트가 필요한 이유
전통적인 개발에서도 E2E 테스트는 중요했지만, AI 코딩 시대에는 더욱 필수적이 되었다. AI가 코드를 생성하거나 수정할 때, 우리가 예상하지 못한 부분에서 기존 기능이 영향을 받을 수 있기 때문이다.
예를 들어, 로그인 버튼이 항상 제대로 작동하는지, 결제 프로세스가 정상적으로 진행되는지, 모바일에서도 모든 기능이 잘 동작하는지 등을 일일이 수동으로 확인하는 것은 현실적으로 불가능하다. 이런 반복적인 검증 작업을 자동화하는 것이 바로 E2E 테스트의 핵심 가치다.
Playwright를 활용한 테스트 환경 구축
현재 웹 개발 생태계에서 E2E 테스트 도구로는 Playwright가 사실상 표준이 되었다. 과거에는 Puppeteer 같은 도구들도 많이 사용되었지만, 지금은 Playwright가 가장 널리 채택되고 있다.
Playwright의 장점은 다양한 브라우저(Chrome, Firefox, Safari)와 디바이스 환경을 동시에 테스트할 수 있다는 점이다. 실제로 테스트를 실행해보면 데스크톱 Chrome, 모바일 Chrome, Safari 등 여러 환경에서 동시에 테스트가 진행되는 것을 확인할 수 있다.
테스트가 실행되면 실제 브라우저가 자동으로 열리고, 우리가 설정한 시나리오대로 페이지를 탐색하며 각 요소들이 제대로 존재하고 작동하는지 확인한다. 테스트가 실패하면 스크린샷과 비디오까지 제공해서 정확히 어느 부분에서 문제가 발생했는지 쉽게 파악할 수 있다.
AI를 활용한 테스트 코드 자동 생성
하지만 여기서 중요한 것은 Playwright의 복잡한 API를 모두 외우고 있을 필요가 없다는 점이다. AI 코딩 시대에는 자연어로 원하는 테스트를 설명하면 AI가 알아서 적절한 테스트 코드를 생성해준다.
예를 들어 "홈페이지의 로그인 버튼이 존재하는지 확인해줘"라고 요청하면, AI가 Playwright MCP를 사용해서 실제 브라우저를 열고 해당 요소를 찾아 테스트 코드를 작성해준다. 더 나아가 테스트가 실패하면 그 이유를 분석하고 개선된 테스트 코드를 다시 작성해주기까지 한다.
특히 흥미로운 점은 모바일 환경에서의 테스트 처리 방식이다. 데스크톱에서는 로그인 버튼이 직접 보이지만, 모바일에서는 햄버거 메뉴 안에 숨어있을 수 있다. AI는 이런 차이점을 자동으로 인식하고, 모바일에서는 먼저 햄버거 메뉴를 클릭한 후 로그인 버튼을 찾도록 테스트를 수정해준다.
완전 자동화된 테스트 워크플로우
더 나아가서는 어떤 부분을 테스트해야 할지조차 AI가 찾아주도록 할 수 있다. 이를 위해 두 단계의 커스텀 명령어를 만들어 사용하는 방법이 효과적이다.
첫 번째 명령어는 "Find End-to-End Test"로, 특정 페이지를 분석해서 테스트해야 할 요소들을 찾아내는 역할을 한다. AI가 실제 브라우저로 페이지를 탐색하면서 로고, 네비게이션 메뉴, 버튼들, 링크들을 찾아내고 이들이 제대로 작동하는지 확인해야 할 항목들을 마크다운 형태로 정리해준다.
두 번째 명령어는 "Create End-to-End Test"로, 첫 번째 단계에서 찾아낸 테스트 항목들을 실제 Playwright 테스트 코드로 변환하는 역할을 한다. 여기서 핵심은 테스트가 실패할 경우 그 이유를 분석하고 성공할 때까지 반복적으로 개선하도록 설정하는 것이다.
실제 적용 사례와 결과
실제로 이 워크플로우를 적용해보면 놀라운 결과를 얻을 수 있다. 홈페이지 하나를 분석한 결과, AI가 자동으로 70개 이상의 테스트 케이스를 생성하고 이 중 대부분이 성공적으로 통과하는 것을 확인할 수 있었다.
테스트 항목들을 살펴보면 다음과 같은 것들이 포함된다:
- 네비게이션 바의 로고 클릭 시 홈페이지로 이동하는지 확인
- 각 메뉴 링크들이 올바른 페이지로 연결되는지 확인
- 로그인, 회원가입 버튼의 존재 여부 확인
- 반응형 디자인이 다양한 화면 크기에서 제대로 작동하는지 확인
각 테스트는 스크린샷과 함께 결과를 보여주기 때문에, 테스트가 실제로 어떤 부분을 확인했는지 시각적으로 검증할 수 있다.
AI 코딩 시대의 테스트 전략
유닛 테스트나 통합 테스트보다 E2E 테스트를 먼저 권하는 이유가 있다. AI 코딩을 하다 보면 유닛 테스트는 너무 많아져서 관리가 어려워지는 경우가 많다. 또한 개별 함수나 컴포넌트 단위의 테스트는 전체적인 사용자 경험을 보장해주지 못한다.
반면 E2E 테스트는 실제 사용자가 경험하는 전체 플로우를 검증하기 때문에, 시스템의 핵심 기능들이 제대로 작동하는지 한눈에 파악할 수 있다. 특히 AI가 코드를 수정했을 때 예상치 못한 부작용이 발생했는지 빠르게 감지할 수 있어서 매우 유용하다.
커스텀 명령어 설계의 핵심 포인트
효과적인 자동화를 위해서는 커스텀 명령어를 잘 설계하는 것이 중요하다. 다음과 같은 요소들을 포함해야 한다:
1.명확한 역할 정의: AI가 Playwright 전문가 또는 QA 전문가 역할을 하도록 페르소나를 설정
2.단계별 프로세스: 페이지 접속 → 요소 분석 → 테스트 코드 작성 → 실행 및 검증의 순서
3.반복 개선 로직: 테스트 실패 시 원인 분석 후 성공할 때까지 재시도
4.결과 포맷 지정: 마크다운 형태로 정리된 결과물 요청
이런 구조화된 접근 방식을 통해 AI가 일관성 있고 신뢰할 수 있는 테스트를 생성하도록 유도할 수 있다.
실무 적용 시 고려사항
물론 이 방법이 만능은 아니다. 복잡한 비즈니스 로직이나 결제 프로세스 같은 중요한 기능들은 여전히 수동으로 세밀하게 테스트 시나리오를 작성해야 한다. 하지만 기본적인 UI 요소들의 존재 여부나 간단한 네비게이션 같은 것들은 AI가 충분히 잘 처리할 수 있다.
또한 테스트 환경 설정도 중요하다. 로컬 개발 환경뿐만 아니라 CI/CD 파이프라인에서도 이런 테스트들이 자동으로 실행되도록 설정해두면, 코드 변경사항이 메인 브랜치에 병합되기 전에 문제를 미리 발견할 수 있다.
결론: 테스트 자동화의 새로운 패러다임
AI 코딩 시대에는 테스트 작성 방식도 완전히 바뀌고 있다. 복잡한 API를 외우고 수동으로 테스트 코드를 작성하는 대신, 자연어로 원하는 테스트를 설명하면 AI가 알아서 모든 것을 처리해준다.
이런 접근 방식의 가장 큰 장점은 개발자가 테스트 작성에 들이는 시간을 크게 줄이면서도, 더 포괄적이고 신뢰할 수 있는 테스트 커버리지를 확보할 수 있다는 점이다. 특히 빠르게 변화하는 AI 코딩 환경에서는 이런 자동화된 검증 시스템이 필수적이다.
결국 AI 코딩의 핵심은 단순히 코드를 빠르게 생성하는 것이 아니라, 생성된 코드의 품질과 안정성을 보장하는 시스템을 함께 구축하는 것이다. End-to-End 테스트 자동화는 이런 목표를 달성하기 위한 가장 실용적이고 효과적인 방법 중 하나라고 할 수 있다.