問라인 · 프론트엔드 · 직무 역량 · 2026년

E2E 테스트 도구인 Playwright나 Cypress를 사용한 경험이 있다면, 어떻게 테스트를 설계하고 실행했는지 구체적으로 이야기해 주세요.

Q: E2E 테스트 도구인 Playwright나 Cypress를 사용한 경험이 있다면, 어떻게 테스트를 설계하고 실행했는지 구체적으로 이야기해 주세요.

팀 프로젝트에서 Playwright를 처음 도입하면서 E2E 테스트 설계를 배웠습니다. 테스트 범위 설정에서 가장 먼저 고민한 건 어떤 사용자 흐름을 E2E로 남길지 결정하는 것이었습니다. 로그인·장바구니·결제 같은 핵심 경로만 E2E로 커버하고, 세부 컴포넌트는 단위 테스트에 맡기는 방식으로 분리했습니다. 시나리오를 작성할 때는 성공 경로뿐 아니라 잘못된 입력이나 빈 상태도 함께 다뤘습니다. 가장 어려웠던 건 테스트 실행마다 결과가 달라지는 플래키 테스트 문제였는데, 타이밍 의존성을 줄이는 방향으로 대기 조건을 정리했습니다. Page Object 패턴으로 UI 요소 선택자를 한 곳에 모으니 리팩토링 시 수정 범위가 줄어드는 효과가 있었습니다. E2E 테스트는 많이 만들기보다 핵심 경로를 믿을 수 있게 유지하는 것이 중요하다는 걸 배웠습니다.

E2E 테스트를 실제로 설계하고 운영한 경험이 있는지, 그리고 품질과 속도 사이에서 어떤 기준으로 판단했는지를 확인합니다.

예상 답변

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

이 질문으로 모의면접 한 번 해보기

INTENT

면접관이 진짜로 보는 건 답이 아닙니다.

이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.

테스트 범위 설정

어떤 사용자 흐름을 E2E로 남기고 어떤 부분은 다른 테스트로 분리했는지 봅니다. 핵심 경로를 고르는 기준의 흔적을 확인합니다.

시나리오 설계

성공 경로와 실패 경로를 어떻게 나눴는지, 데이터 준비와 상태 전이를 어떻게 다뤘는지 살핍니다. 테스트 의도의 구체성을 봅니다.

안정성 관리

비동기 처리, 대기 전략, 셀렉터 선택 등으로 테스트의 불안정성을 얼마나 줄였는지 확인합니다. 재현성과 유지보수 감각을 봅니다.

실행과 운영

로컬과 CI에서 어떻게 실행했는지, 실패 시 원인 파악과 수정 과정을 어떻게 운영했는지 봅니다. 실제 도입과 지속 운영 경험을 살핍니다.

읽기만 해도 충분하지만, 한 번 말로 해보면 다릅니다.

이 질문 그대로 음성 면접으로 받아볼 수 있어요. 첫 면접은 무료입니다.

이 질문으로 면접 시작

핵심 경로 선정 + 시나리오 설계 + 플래키 테스트 제거 + Page Object 패턴 적용약 65초 CI 통합 후 스크린샷/트레이스 자동 수집으로 실패 원인 원격 확인, 헤드리스 환경 뷰포트 맞춤, 실패율 측정해 플래키 테스트 우선 안정화 — E2E는 작성보다 CI에서 지속 통과시키는 것이 중요약 67초 data-testid + aria-label 셀렉터로 UI 리팩토링 내성, waitForResponse로 sleep 제거해 타이밍 의존 해소, 네트워크 모킹으로 외부 서비스 고정 — 안정성은 셀렉터+대기 방식에서 결정약 67초

Playwright E2E 테스트 경험

약 65초

핵심 경로 선정 + 시나리오 설계 + 플래키 테스트 제거 + Page Object 패턴 적용

팀 프로젝트에서 Playwright를 처음 도입하면서 E2E 테스트 설계를 배웠습니다. 테스트 범위 설정에서 가장 먼저 고민한 건 어떤 사용자 흐름을 E2E로 남길지 결정하는 것이었습니다. 로그인·장바구니·결제 같은 핵심 경로만 E2E로 커버하고, 세부 컴포넌트는 단위 테스트에 맡기는 방식으로 분리했습니다. 시나리오를 작성할 때는 성공 경로뿐 아니라 잘못된 입력이나 빈 상태도 함께 다뤘습니다. 가장 어려웠던 건 테스트 실행마다 결과가 달라지는 플래키 테스트 문제였는데, 타이밍 의존성을 줄이는 방향으로 대기 조건을 정리했습니다. Page Object 패턴으로 UI 요소 선택자를 한 곳에 모으니 리팩토링 시 수정 범위가 줄어드는 효과가 있었습니다.

E2E 테스트는 많이 만들기보다 핵심 경로를 믿을 수 있게 유지하는 것이 중요하다는 걸 배웠습니다.

예시 답변 2

약 67초

CI 통합 후 스크린샷/트레이스 자동 수집으로 실패 원인 원격 확인, 헤드리스 환경 뷰포트 맞춤, 실패율 측정해 플래키 테스트 우선 안정화 — E2E는 작성보다 CI에서 지속 통과시키는 것이 중요

Playwright 테스트를 CI에 통합하면서 로컬에서 잘 돌던 테스트가 CI에서 실패하는 경우를 처음 겪었습니다. 타이밍 차이와 환경 차이가 원인이었는데, CI에서 실패하면 스크린샷과 트레이스 파일이 자동으로 저장되도록 설정하니 어느 단계에서 실패했는지 로컬에서 재현하지 않고도 확인할 수 있었습니다. Playwright의 트레이스 뷰어로 테스트 실행 전체를 타임라인으로 보면서 어느 액션에서 타임아웃이 났는지 정확히 찾을 수 있었습니다. 헤드리스 모드에서 동작이 다른 경우도 있었는데, CI 환경의 해상도와 뷰포트를 로컬과 맞추니 이 문제가 줄었습니다. 테스트 실패율을 측정해두니 어떤 테스트가 플래키한지 패턴이 보였고, 반복 실패하는 테스트를 우선 안정화하는 방식으로 개선했습니다.

E2E 테스트는 작성보다 CI에서 지속적으로 통과시키는 것이 더 어렵고 중요하다는 것을 이 경험에서 배웠습니다.

예시 답변 3

약 67초

data-testid + aria-label 셀렉터로 UI 리팩토링 내성, waitForResponse로 sleep 제거해 타이밍 의존 해소, 네트워크 모킹으로 외부 서비스 고정 — 안정성은 셀렉터+대기 방식에서 결정

E2E 테스트를 작성하면서 셀렉터 선택이 테스트 유지보수 비용을 결정한다는 것을 경험했습니다. CSS 클래스나 XPath로 요소를 찾으면 UI를 리팩토링할 때마다 테스트가 깨졌습니다. `data-testid` 속성을 UI 컴포넌트에 추가하고 셀렉터로 사용하니 디자인이 바뀌어도 테스트 코드가 깨지지 않았습니다.

aria-label을 셀렉터로 쓰면 접근성 속성을 지키는 동시에 테스트 안정성도 얻을 수 있었습니다. 비동기 처리에서는 sleep을 쓰면 환경마다 결과가 달라지는 플래키 테스트가 됐는데, `waitForResponse`로 API 응답을 기다린 후 다음 단계로 넘어가는 방식으로 바꾸니 타이밍 의존성이 사라졌습니다. 네트워크 모킹도 써봤는데, 외부 API 응답을 고정값으로 설정하니 테스트 환경에 따라 외부 서비스가 달라도 동일한 결과를 얻을 수 있었습니다.

E2E 테스트 안정성은 어떤 셀렉터를 쓰고 어떻게 대기하는지에서 결정된다는 것을 이 경험에서 배웠습니다.

위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.

WHAT OFTEN MISSES

이 질문에서 자주 빠지는 자리.

답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.

도구를 썼다는 사실만 말하고 어떤 흐름을 검증했는지까지는 짚지 않습니다

셀렉터 작성이나 대기 방식만 설명하고 실패 지점과 안정화 전략은 빠뜨립니다

로컬에서 잘 돌았다는 수준에 머물고 실행 환경과 유지보수 관점을 함께 말하지 않습니다

FOLLOW-UPS

진짜 면접은 두 번째 질문부터입니다.

이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.

壹

예상 꼬리질문 1

가장 먼저 어떤 사용자 흐름부터 E2E로 묶었는지 설명해 주시겠어요?

대응 포인트핵심 전환 경로를 먼저 잡는 기준과 비즈니스 영향도를 함께 풀어주는 결이 통합니다

貳

예상 꼬리질문 2

테스트가 자주 깨질 때는 어떤 방식으로 안정화했나요?

대응 포인트대기, 네트워크, 데이터 준비, 셀렉터 선택 등 불안정 요인을 어떻게 줄였는지 짚어두면 좋습니다

參

예상 꼬리질문 3

CI에서 돌릴 때 로컬 실행과 달라진 점은 무엇이었나요?

대응 포인트실행 시간, 병렬화, 테스트 데이터, 리포트 확인 방식 차이를 함께 설명하면 좋습니다

읽으셨다면, 한 번 말로 해보세요.

같은 질문으로 음성 면접을 받아보면 어디서 막히는지 바로 보입니다. 첫 면접은 무료입니다.

이 질문으로 면접 시작

3 크레딧 차감 · 첫 회 무료 · 음성 데이터는 종료 즉시 폐기됩니다

DISCLAIMER

이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.

상호 우문현답대표 이성인사업자등록번호 330-15-03033통신판매업 신고번호 준비중주소 인천광역시 부평구 동수로120번길 11, 한국아파트 104동 210호이메일 devlsi1228@gmail.com전화 010-7395-5311

홈›회사별›라인›프론트엔드›질문 상세

問라인 · 프론트엔드 · 직무 역량 · 2026년

E2E 테스트 도구인 Playwright나 Cypress를 사용한 경험이 있다면, 어떻게 테스트를 설계하고 실행했는지 구체적으로 이야기해 주세요.

E2E 테스트를 실제로 설계하고 운영한 경험이 있는지, 그리고 품질과 속도 사이에서 어떤 기준으로 판단했는지를 확인합니다.

예상 답변

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

이 질문으로 모의면접 한 번 해보기

INTENT

면접관이 진짜로 보는 건 답이 아닙니다.

이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.

테스트 범위 설정

어떤 사용자 흐름을 E2E로 남기고 어떤 부분은 다른 테스트로 분리했는지 봅니다. 핵심 경로를 고르는 기준의 흔적을 확인합니다.

시나리오 설계

성공 경로와 실패 경로를 어떻게 나눴는지, 데이터 준비와 상태 전이를 어떻게 다뤘는지 살핍니다. 테스트 의도의 구체성을 봅니다.

안정성 관리

비동기 처리, 대기 전략, 셀렉터 선택 등으로 테스트의 불안정성을 얼마나 줄였는지 확인합니다. 재현성과 유지보수 감각을 봅니다.

실행과 운영

로컬과 CI에서 어떻게 실행했는지, 실패 시 원인 파악과 수정 과정을 어떻게 운영했는지 봅니다. 실제 도입과 지속 운영 경험을 살핍니다.

읽기만 해도 충분하지만, 한 번 말로 해보면 다릅니다.

이 질문 그대로 음성 면접으로 받아볼 수 있어요. 첫 면접은 무료입니다.

이 질문으로 면접 시작

Playwright E2E 테스트 경험

약 65초

핵심 경로 선정 + 시나리오 설계 + 플래키 테스트 제거 + Page Object 패턴 적용

E2E 테스트는 많이 만들기보다 핵심 경로를 믿을 수 있게 유지하는 것이 중요하다는 걸 배웠습니다.

예시 답변 2

약 67초

CI 통합 후 스크린샷/트레이스 자동 수집으로 실패 원인 원격 확인, 헤드리스 환경 뷰포트 맞춤, 실패율 측정해 플래키 테스트 우선 안정화 — E2E는 작성보다 CI에서 지속 통과시키는 것이 중요

E2E 테스트는 작성보다 CI에서 지속적으로 통과시키는 것이 더 어렵고 중요하다는 것을 이 경험에서 배웠습니다.

예시 답변 3

약 67초

data-testid + aria-label 셀렉터로 UI 리팩토링 내성, waitForResponse로 sleep 제거해 타이밍 의존 해소, 네트워크 모킹으로 외부 서비스 고정 — 안정성은 셀렉터+대기 방식에서 결정

E2E 테스트 안정성은 어떤 셀렉터를 쓰고 어떻게 대기하는지에서 결정된다는 것을 이 경험에서 배웠습니다.

WHAT OFTEN MISSES

이 질문에서 자주 빠지는 자리.

답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.

도구를 썼다는 사실만 말하고 어떤 흐름을 검증했는지까지는 짚지 않습니다

셀렉터 작성이나 대기 방식만 설명하고 실패 지점과 안정화 전략은 빠뜨립니다

로컬에서 잘 돌았다는 수준에 머물고 실행 환경과 유지보수 관점을 함께 말하지 않습니다

FOLLOW-UPS

진짜 면접은 두 번째 질문부터입니다.

이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.

壹

예상 꼬리질문 1

가장 먼저 어떤 사용자 흐름부터 E2E로 묶었는지 설명해 주시겠어요?

대응 포인트핵심 전환 경로를 먼저 잡는 기준과 비즈니스 영향도를 함께 풀어주는 결이 통합니다

貳

예상 꼬리질문 2

테스트가 자주 깨질 때는 어떤 방식으로 안정화했나요?

대응 포인트대기, 네트워크, 데이터 준비, 셀렉터 선택 등 불안정 요인을 어떻게 줄였는지 짚어두면 좋습니다

參

예상 꼬리질문 3

CI에서 돌릴 때 로컬 실행과 달라진 점은 무엇이었나요?

대응 포인트실행 시간, 병렬화, 테스트 데이터, 리포트 확인 방식 차이를 함께 설명하면 좋습니다

읽으셨다면, 한 번 말로 해보세요.

같은 질문으로 음성 면접을 받아보면 어디서 막히는지 바로 보입니다. 첫 면접은 무료입니다.

이 질문으로 면접 시작

3 크레딧 차감 · 첫 회 무료 · 음성 데이터는 종료 즉시 폐기됩니다

DISCLAIMER