이직에 바로 먹히는 프론트엔드 AI 실무: Playwright 기반 E2E Eval 운영 가이드
요즘 Velog 트렌드를 보면 AI 코딩 도구 후기, 바이브 코딩 경험, 자동화 워크플로우 글이 계속 상위에 올라옵니다. 흐름 자체는 좋지만, 면접에서 실제로 평가받는 지점은 생각보다 단순합니다.
“AI로 만든 기능이 실제 사용자 시나리오에서 안전하다는 걸 어떻게 증명했나요?”
즉, 생성 능력보다 검증 설계 능력이 이직 경쟁력을 만듭니다.
이번 글에서는 프론트엔드 관점에서 Playwright를 활용해 AI 생성 코드를 평가(Eval)하는 체계를 소개합니다. 핵심은 다음 3가지입니다.
- 기능 구현 속도보다 회귀 방지 속도를 높이기
- E2E 테스트를 단순 QA가 아니라 채용 포트폴리오 자산으로 전환하기
- “AI를 잘 쓴 개발자”가 아니라 AI 산출물 품질을 통제한 개발자로 보이기
왜 지금 프론트엔드에게 E2E Eval이 중요한가
AI 도구를 쓰면 UI 기능은 빠르게 나옵니다. 문제는 그 다음입니다.
- 기존 플로우가 깨졌는지
- 접근성이 후퇴했는지
- 예외 상황에서 앱이 버티는지
이런 질문은 코드만 읽어선 답하기 어렵습니다. 실제 사용자 플로우를 자동 실행해야 확인됩니다. 그래서 E2E Eval은 단순 테스트를 넘어, 운영 가능한 제품을 만들 줄 아는 사람이라는 증거가 됩니다.
관련 배경으로 이직에 강한 프론트엔드 포트폴리오: AI 코드리뷰 실무 적용 플레이북을 먼저 보면 전체 맥락을 더 빠르게 잡을 수 있습니다.
Eval 설계 원칙: “모든 화면”이 아니라 “돈 되는 흐름”부터
처음부터 전체 시나리오를 E2E로 덮으려 하면 실패할 확률이 높습니다. 대신 아래 순서가 실무적으로 안정적입니다.
1) 핵심 사용자 여정 3개만 고정
예시:
- 로그인 → 대시보드 진입
- 검색 → 상세 페이지 이동
- 결제/제출 → 완료 확인
이 3개만 안정화해도 릴리즈 리스크가 크게 줄어듭니다.
2) “정답 HTML” 대신 “관찰 가능한 상태”를 검증
취약한 셀렉터나 마크업 구조에 의존하면 테스트가 쉽게 깨집니다. 다음처럼 검증 대상을 사용자 관점으로 바꾸세요.
- 버튼 클릭 후 URL이 기대 경로로 바뀌는가
- 에러 토스트가 실제로 노출되는가
- 제출 후 서버 응답 상태에 맞는 UI가 보이는가
3) 실패 로그를 디버깅 가능한 형태로 남기기
실패했을 때 필요한 자료를 자동 저장하면 복구 속도가 빨라집니다.
- 스크린샷
- trace 파일
- 콘솔 에러 로그
에러 모니터링은 Sentry 에러 모니터링 가이드와 같이 연결하면 원인 파악이 더 쉬워집니다.
Playwright + AI 실무 패턴
아래 패턴은 “AI가 테스트 코드를 일부 생성하고, 사람이 품질 기준을 통제”하는 방식입니다.
패턴 A: 시나리오 스켈레톤은 AI로, 단언(assertion)은 사람이 직접
AI에게는 다음까지 맡깁니다.
- 테스트 파일 뼈대 생성
- 반복 입력/이동 시퀀스 생성
하지만 아래는 사람이 확정해야 합니다.
- 어떤 상태를 “성공”으로 볼지
- 어떤 실패가 배포 차단 사유인지
패턴 B: flaky 테스트는 “재시도”보다 “원인 분리”
간헐 실패를 retry로 덮으면 지표는 좋아 보여도 품질은 나빠집니다.
- 네트워크 지연 문제인지
- 애니메이션 타이밍 문제인지
- 비동기 상태 전이 문제인지
원인을 분리해 해결하고, 재시도는 마지막 수단으로만 두는 편이 장기적으로 유리합니다. 비동기 이해가 약하면 JavaScript 비동기 처리 완전 정복을 함께 보는 걸 권장합니다.
패턴 C: PR 품질 게이트로 고정
테스트가 “선택 실행”이면 결국 안 돌게 됩니다. PR에서 강제해야 효과가 납니다.
- lint
- build
- 핵심 E2E 스모크 테스트
브랜치와 리뷰 흐름은 GitHub Flow 또는 Trunk Based Development 중 팀 문화에 맞는 방식으로 고정하세요.
면접에서 통하는 설명 템플릿
아래 포맷으로 답하면 기술 깊이 + 실무 임팩트를 함께 보여줄 수 있습니다.
- 문제: AI 도입 후 기능 속도는 빨라졌지만 회귀 버그가 증가했다.
- 조치: Playwright 핵심 시나리오 3개를 PR 게이트로 도입했다.
- 결과: 릴리즈 직후 장애가 감소하고, 리뷰 시간이 예측 가능해졌다.
- 학습: flaky 원인을 분류해 비동기/상태 전이 설계를 개선했다.
숫자를 넣으면 더 좋습니다.
- 예: “배포 후 UI 회귀 이슈 월 5건 → 월 2건”
- 예: “핫픽스 리드타임 평균 1일 → 4시간”
2주 실행 플랜 (포트폴리오 전환용)
1주차: 최소 Eval 체계 구축
- 핵심 여정 3개 선정
- Playwright 스모크 테스트 작성
- CI에서 PR마다 자동 실행
2주차: 품질 데이터화
- 실패 로그(스크린샷/trace) 축적
- 회귀 이슈 전후 비교표 정리
- README에 운영 규칙 문서화
이 과정을 공개 저장소에 남기면 “AI로 빠르게 만들었다”를 넘어 제품 품질을 운영했다는 증거가 됩니다.
마무리
AI 시대 프론트엔드 이직에서 경쟁력은 결국 다음 문장으로 요약됩니다.
- 코드를 생성할 수 있는가? → 대부분 가능
- 생성된 코드를 운영 품질로 끌어올릴 수 있는가? → 여기서 격차 발생
Playwright E2E Eval은 그 격차를 가장 명확하게 보여주는 수단입니다. 오늘 한 기능만이라도 Eval 관점으로 다시 설계해 보세요.
면접에서 “무엇을 만들었는지”보다 “어떻게 안전하게 배포했는지”를 말할 수 있게 됩니다.