우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›라인›프론트엔드›질문 상세
    問
    라라인프론트엔드직무 역량2026년 출제

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

    한 문장 요약

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

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    테스트 범위 설정
    어떤 사용자 흐름을 E2E로 남기고 어떤 부분은 다른 테스트로 분리했는지 봅니다. 핵심 경로를 고르는 기준의 흔적을 확인합니다.
    骨
    02
    시나리오 설계
    성공 경로와 실패 경로를 어떻게 나눴는지, 데이터 준비와 상태 전이를 어떻게 다뤘는지 살핍니다. 테스트 의도의 구체성을 봅니다.
    語
    03
    안정성 관리
    비동기 처리, 대기 전략, 셀렉터 선택 등으로 테스트의 불안정성을 얼마나 줄였는지 확인합니다. 재현성과 유지보수 감각을 봅니다.
    本
    04
    실행과 운영
    로컬과 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 테스트는 많이 만들기보다 핵심 경로를 믿을 수 있게 유지하는 것이 중요하다는 걸 배웠습니다.

    이 결의 특징
    로그인·장바구니·결제 같은 핵심 경로만 E2E로 남기고 세부는 단위 테스트에 맡기는 범위 분리를 짚고, Page Object 패턴으로 선택자를 한곳에 모은 흔적이 있습니다.
    이 결이 통하는 자리
    E2E 테스트는 많이 만들기보다 핵심 경로를 믿을 수 있게 유지하는 것이 중요하다는 결론이 구체 범위 판단으로 뒷받침될 때 통합니다. 플래키 테스트 정리 경험이 면접관에게 통합니다.
    예시 답변 2
    약 67초

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

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

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

    이 결의 특징
    로컬에서 통과하던 테스트가 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 테스트 안정성은 어떤 셀렉터를 쓰고 어떻게 대기하는지에서 결정된다는 것을 이 경험에서 배웠습니다.

    이 결의 특징
    CSS 클래스 셀렉터가 리팩토링마다 테스트를 깨뜨리던 문제를 data-testid와 aria-label로 해결하고, sleep 대신 waitForResponse로 타이밍 의존을 없앤 흔적이 있습니다.
    이 결이 통하는 자리
    E2E 테스트 안정성은 셀렉터와 대기 방식에서 결정된다는 결론이 구체 전환 사례로 뒷받침될 때 통합니다. 접근성 속성과 테스트 안정성을 동시에 얻은 선택이 면접관에게 통합니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕도구를 썼다는 사실만 말하고 어떤 흐름을 검증했는지까지는 짚지 않습니다
    • ✕셀렉터 작성이나 대기 방식만 설명하고 실패 지점과 안정화 전략은 빠뜨립니다
    • ✕로컬에서 잘 돌았다는 수준에 머물고 실행 환경과 유지보수 관점을 함께 말하지 않습니다
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹가장 먼저 어떤 사용자 흐름부터 E2E로 묶었는지 설명해 주시겠어요?
    대응핵심 전환 경로를 먼저 잡는 기준과 비즈니스 영향도를 함께 풀어주는 결이 통합니다
    貳테스트가 자주 깨질 때는 어떤 방식으로 안정화했나요?
    대응대기, 네트워크, 데이터 준비, 셀렉터 선택 등 불안정 요인을 어떻게 줄였는지 짚어두면 좋습니다
    參CI에서 돌릴 때 로컬 실행과 달라진 점은 무엇이었나요?
    대응실행 시간, 병렬화, 테스트 데이터, 리포트 확인 방식 차이를 함께 설명하면 좋습니다
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 라인 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    라인 · 풀스택
    E2E 테스트 도구를 사용한 경험이 있다면, 어떤 점이 유용했는지 설명해 주세요.
    이 질문 보기
    라인 · 프론트엔드
    단위 테스트 및 E2E 테스트를 진행한 경험이 있다면, 어떤 도구를 사용했는지 설명해주실 수 있나요?
    이 질문 보기
    넥스트증권 · 프론트엔드
    테스트 자동화 도구(Jest나 Cypress 등)를 사용해본 경험이 있다면, 어떤 프로젝트에서 어떻게 활용했는지 말씀해 주세요.
    이 질문 보기
    라인 · 품질보증
    자동화 테스트 개발 경험이 있다면, 어떤 도구를 사용했는지 설명해보세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 라인 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기