이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
End-to-End 테스트를 수행할 때 가장 먼저 한 것은 핵심 사용자 시나리오를 선정하는 것이었습니다. 모든 흐름을 E2E로 커버하면 유지 비용이 너무 커지기 때문에, 사용 빈도가 높고 장애 시 영향이 큰 흐름을 우선순위로 정했습니다.
테스트 환경 구성도 중요한 준비였습니다. 실제 서비스와 유사한 스테이징 환경에서 E2E 테스트를 실행하면 환경 차이로 인한 오탐을 줄일 수 있었고, 외부 서비스는 목으로 교체해 외부 의존성이 테스트 결과에 영향을 주지 않도록 했습니다.
실패 원인 추적이 E2E 테스트에서 가장 어려운 부분이었습니다. 여러 레이어를 거치기 때문에 어느 단계에서 문제가 생겼는지를 파악하기 위해, 실행 로그와 스크린샷을 자동으로 수집하고 요청 추적 ID를 통해 서버 로그와 연결했습니다.
E2E 테스트를 처음 구성할 때 가능한 많은 시나리오를 커버하려고 테스트를 많이 만들었는데, 유지 비용이 예상보다 높다는 것을 경험했습니다. UI 변경이 있을 때마다 여러 E2E 테스트가 실패했는데, 실제로 기능이 깨진 것이 아니라 테스트가 특정 UI 요소에 강하게 의존하고 있어서 변경에 취약했습니다. 테스트를 고치는 데 드는 시간이 테스트가 주는 안정감보다 크다는 인식이 생기면서 팀에서 E2E 테스트를 무시하는 경향이 생기기 시작했습니다. 이후에는 E2E 테스트의 범위를 핵심 사용자 플로우 몇 개로 줄이고, UI 구현보다 사용자 행동을 기준으로 테스트를 작성하는 방식으로 바꿨습니다. E2E 테스트는 많을수록 좋은 것이 아니라 유지 가능한 수준에서 중요한 플로우를 커버하는 것이 더 효과적이라는 것을 이 경험에서 배웠습니다.
E2E 테스트를 스테이징 환경에서 실행했는데, 스테이징 환경의 설정이 운영 환경과 다른 부분이 있어서 테스트가 통과해도 운영에서 문제가 발생하는 경우가 있었습니다. 외부 서비스 연동 설정이나 환경 변수가 스테이징과 운영에서 다르게 적용돼 있었는데, 이 차이가 테스트 결과와 실제 동작의 차이를 만들었습니다. E2E 테스트의 신뢰도는 테스트 로직만큼이나 테스트가 실행되는 환경이 실제 서비스를 얼마나 잘 모사하는지에 달려있다는 것을 알게 됐습니다. 이후에는 스테이징과 운영의 환경 설정 차이를 문서화하고, 환경 차이가 테스트 결과에 영향을 줄 수 있는 부분을 명시적으로 관리하는 방식을 도입했습니다. E2E 테스트가 실제로 유효하려면 테스트 코드와 환경 관리를 함께 신경 써야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.