이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
테스트 자동화를 계층적으로 설계한다는 건 각 계층이 서로 다른 목적을 갖도록 나누는 것이라고 이해하고 있습니다. 단위 테스트는 빠르게 많이, 통합 테스트는 서비스 경계를 검증하고, E2E는 핵심 사용자 흐름만 좁게 커버하는 피라미드 구조입니다. 여기에 성능 테스트를 별도 레이어로 추가해 k6로 주요 API의 부하 테스트를 CI 단계에서 실행했습니다. 모든 레이어를 동시에 돌리면 피드백이 느려지므로, PR 단계엔 단위·통합만, 스테이징 배포 후엔 E2E·성능 순서로 실행하는 파이프라인을 구성했습니다. 계층 간 중복 커버리지를 줄이는 게 유지보수 비용을 낮추는 핵심이라고 생각합니다.
E2E 테스트를 처음 작성했을 때 테스트가 로컬에서는 통과하는데 CI에서 간헐적으로 실패하는 문제가 생겼습니다. 비동기 로딩 타이밍에 의존하는 셀렉터가 환경마다 달리 동작했습니다. Playwright로 작성한 테스트였는데, `waitForSelector` 대신 데이터 준비 완료를 기다리는 방식으로 바꾸니 안정성이 크게 올라갔습니다. 테스트 수가 늘면서 CI 실행 시간이 12분을 넘었고, 핵심 흐름 태그를 분리해서 PR 단계에서는 빠른 subset만 돌리는 구조를 만들었습니다. 전체 E2E는 야간 스케줄로 돌리고 실패 시 알람이 오도록 연결했습니다. 간헐적 실패가 3주간 0건으로 유지됐을 때 구조가 안정됐다는 걸 확인했습니다.
성능 테스트를 한 번만 돌리고 끝내면 기준이 없어서 배포할 때마다 괜찮은지 판단이 어렵다는 걸 경험했습니다. 처음엔 배포 전후 응답 시간을 수동으로 비교했는데, 사람마다 느려졌다는 기준이 달라 논의가 생겼습니다. 그래서 k6로 기준선 시나리오를 만들어 CI에 연결했습니다. 핵심 API 5개에 대해 95th percentile 응답 시간이 400ms를 넘으면 파이프라인이 실패하도록 임계값을 설정했습니다. 처음엔 임계값을 너무 엄격하게 잡아서 사소한 인프라 변동에도 실패가 나는 노이즈가 생겼고, 기준을 실측 p95의 1.5배로 완화했습니다. 수치 기준이 생기니 성능이 나빠졌을 때 감이 아니라 데이터로 대화할 수 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.