Selenium 면접 질문
작성자 Aaron Cao · 업데이트

Selenium 면접은 대기, 로케이터, Page Object Model, 그리고 테스트가 왜 불안정해지는지에 초점을 맞춥니다. 암묵적 대기와 명시적 대기의 차이를 설명하고, XPath 대신 CSS를 선택하는 이유를 말하고 방어할 수 있어야 하며, 오래된 요소 참조 오류를 해결하고, 프레임워크가 어떻게 병렬로 실행되는지 설명할 수 있어야 합니다.
면접관은 대기와 로케이터에 대해 무엇을 묻나요?
로컬에서는 통과하는데 파이프라인에서는 실패하는 테스트를 작성해 본 적이 있고, 답이 대기와 관련 있다고 짐작은 하지만 깔끔하게 설명하지는 못한다. 면접관도 이를 알고 있기 때문에, 대기는 대부분의 Selenium 면접에서 첫 화두로 등장합니다. 이 섹션에서는 완전한 답변이 어떤 모습인지 다룹니다.
- 암묵적 대기와 명시적 대기. 암묵적 대기는 전역 설정으로, 조회할 때마다 요소가 나타날 때까지 폴링합니다. 명시적 대기는 하나의 요소와 하나의 조건, 예를 들어 클릭 가능 여부나 표시 여부만을 대상으로 합니다. 명시적 대기가 선호되는 이유는 무엇을 기다리는지 명확히 드러내기 때문입니다.
- 왜 두 가지를 섞으면 안 되나요? 둘을 함께 쓰면 예측하기 어려운 방식으로 타임아웃이 누적될 수 있어서, 대부분의 팀은 암묵적 대기를 제로로 설정하고 명시적 대기만 사용합니다.
- fluent wait란 무엇인가요? 폴링 간격을 설정할 수 있고 특정 예외 유형을 무시할 수 있는 명시적 대기입니다.
Thread.sleep이 왜 잘못됐나요? 무조건적이기 때문입니다. 통과할 테스트를 느리게 만들면서도, 느린 테스트는 여전히 실패시킵니다.- CSS 선택자와 XPath 중 무엇을 써야 하나요? 안정적인 테스트 전용 식별 속성을 우선하고, 그다음으로 가독성이 좋은 CSS를 사용하세요. 부모 노드까지 탐색하거나 텍스트로 매칭해야 할 때 XPath가 제 역할을 합니다.
- 무엇이 로케이터를 취약하게 만드나요? 자동 생성된 클래스 이름, 절대 경로 XPath, 인덱스 기반 선택입니다. 대신 개발자에게 무엇을 추가해 달라고 요청할지 말할 수 있어야 합니다.
면접관이 듣고 싶어 하는 것은 각 선택 뒤에 있는 이유입니다. 비용을 언급하지 않고 선호만 말하면 외운 답변처럼 들립니다.
예외와 테스트 불안정성 관련 질문에는 어떻게 답하나요?
테스트 불안정성이야말로 대부분의 시니어 자동화 면접에서 진짜로 다루는 주제입니다. 아무도 신뢰하지 않는 테스트 스위트는 스위트가 아예 없는 것보다 나쁘기 때문입니다.
StaleElementReferenceException은 왜 발생하나요? 요소 참조가 더 이상 붙어 있지 않은 노드를 가리키는 상태로, 보통 프레임워크가 페이지의 그 부분을 다시 렌더링했기 때문에 발생합니다. 저장해 둔 참조를 재사용하지 말고 요소를 다시 찾으세요.ElementNotInteractableException은 어떤가요? 요소는 존재하지만 조작할 수 없는 상태입니다. 숨겨져 있거나, 비활성화되어 있거나, 다른 요소에 가려져 있거나, 화면 밖에 있는 경우입니다.NoSuchElementException은 어떻게 처리하나요? 타이밍 문제인지 요소가 정말로 없는 것인지 구분하고, 대기 시간을 늘리는 것으로 문제를 덮지 마세요.- 왜 테스트가 파이프라인에서만 실패하나요? 뷰포트 크기 차이, 더 느린 환경, 테스트 데이터 부족, 더 늦게 끝나는 애니메이션, 그리고 공유 상태를 두고 충돌하는 병렬 테스트 때문입니다.
- 불안정한 테스트는 어떻게 고치나요? 먼저 원인 범주를 진단한 다음 근본 원인을 고칩니다. 자동 재시도는 실패를 감출 뿐이므로, 최후의 수단이라고 분명히 말해야 합니다.
- 프레임, 새 창, 알림창은 어떻게 처리하나요? 컨텍스트를 명시적으로 전환하고, 이후 다시 되돌립니다.
중급 자동화 직무에 지원한 한 QA 엔지니어는 코드를 전혀 바꾸지 않았는데도 특정 스위트가 매주 두 번씩 실패하는 이유를 질문받았습니다. 좋은 평가를 받은 답변은 Selenium API의 세부 사항이 아니라, 테스트들이 미리 만들어 둔 계정 하나를 공유하면서 서로 경쟁하고 있었다는 점이었습니다. 면접관이 높이 평가하는 것은 바로 이 진단 순서입니다. 먼저 환경과 데이터, 그다음이 API입니다.
역할과 도구별로 더 많은 문제 모음은 직무별 면접 질문에서 볼 수 있습니다.
프레임워크와 아키텍처 관련 질문에는 무엇이 나오나요?
API를 넘어서, 면접 패널은 당신이 테스트 스위트 전체를 책임질 수 있는지 알고 싶어 합니다. 이 질문들은 시니어 직무에서 가장 비중이 큽니다.
- Page Object Model을 설명해 보세요. Page 클래스는 동작을 노출하고 로케이터를 숨기므로, UI가 바뀌어도 파일 하나만 고치면 됩니다. 어떤 문제를 해결하는지를 말해야 하며, 폴더 구조만 설명하는 것은 핵심을 놓치는 것입니다.
- Page Object는 어떤 문제가 생기나요? 수천 줄짜리 클래스로 비대해지고, 페이지 메서드 안에서 검증을 시작하게 됩니다. 검증은 테스트 안에 있어야 합니다.
- 당신의 프레임워크는 테스트를 어떻게 병렬로 실행하나요? 인스턴스가 스레드 간에 공유되지 않도록 스레드 안전한 드라이버 관리를 하고, 여기에 테스트마다 독립적인 테스트 데이터를 더합니다.
- Selenium Grid는 무엇을 위한 것인가요? 여러 대의 머신과 브라우저 버전에 테스트를 분산시키는 것으로, hub와 node 구조를 쓰거나 클라우드 제공업체가 같은 역할을 대신하기도 합니다.
- Selenium 4에서는 무엇이 바뀌었나요? W3C WebDriver 프로토콜이 표준이 되었고 예전 JSON wire protocol이 제거되었으며, 상대 로케이터가 추가되고 Chrome DevTools Protocol 접근이 열렸습니다.
- Selenium을 쓰지 말아야 할 때는 언제인가요? API 수준의 검사, 단위 테스트로 가능한 로직, 그리고 브라우저 밖의 모든 것입니다. 이 경계를 아는 것 자체가 시니어라는 신호입니다.
- 무엇을 자동화할지는 어떻게 정하나요? 안정적이고, 가치가 높고, 반복적으로 실행되는 경로입니다. 모든 것을 자동화하는 것도 아니고, 아직 재설계 중인 화면도 대상이 아닙니다.
면접 전에는 어떻게 연습해야 하나요?
Selenium에 대한 답변은 알고는 있지만 말로 꺼내기는 유난히 어려운 유형입니다. 특히 대기 질문은 정의와 이유라는 두 부분으로 이루어져 있는데, 자료만 읽은 지원자는 앞부분만 말하고 흐지부지되곤 합니다.
여기 나온 질문 중 가장 마주치고 싶지 않은 것을 다섯 개 골라, 편집기를 열지 않은 채로 구십 초 안에 소리 내어 답해 보세요. 그다음 누군가에게 “왜”냐고 되묻게 하세요. 이 되물음은 거의 매번 나옵니다. 반박을 던지는 AI 면접관을 상대로 같은 질문을 반복 연습하는 것은 목록을 다시 읽는 것보다 실제 면접에 훨씬 가깝고, 그것이 바로 모의 면접 모드가 존재하는 이유입니다.
SubcueAI 창립자 Aaron Cao는 문제를 더 많이 제공하는 것이 아니라 바로 이 “말로 표현하는 능력의 차이”를 메우는 데 초점을 맞춰 연습을 설계했습니다. 실제 면접에서는 데스크톱 앱과 브라우저 확장 프로그램의 사이드 패널이 면접관이 말하는 동안 구조를 보여줄 수 있으며, 이는 이미 연습해 둔 내용에서 가장 도움이 됩니다. 이 제품이 무엇을 하는지, 그리고 절대 넘지 않는 한계가 무엇인지는 보안 페이지에 나와 있습니다.