이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 API 서버의 성능 테스트를 처음으로 직접 담당했습니다. 부하 테스트는 k6로 구성했는데, 동시 사용자 수를 단계적으로 늘리면서 응답 시간과 에러율이 어느 지점에서 급격히 나빠지는지 확인했습니다. 코너 케이스 테스트에서는 잘못된 입력이나 빈 값을 보냈을 때 서버가 500 에러 대신 의미 있는 응답을 주는지를 체크했습니다. 안정성 검증에서는 낮은 부하로 장시간 실행하는 소크 테스트를 통해 메모리 누수 여부를 확인했습니다. 회귀 테스트는 핵심 API 응답 시간 기준을 CI에 넣어서 배포 때마다 자동으로 검증되도록 했습니다.
성능 테스트는 숫자를 얻는 게 아니라 어느 조건에서 어떻게 무너지는지를 이해하는 과정이라는 걸 그때 직접 배웠습니다.
성능 테스트는 한 번 통과했다고 끝나는 게 아니라는 걸 배포 이후 응답 시간이 서서히 느려지는 상황에서 배웠습니다. 초기 테스트 결과는 좋았는데, 2주 후 프로덕션에서 P99 응답 시간이 두 배 가까이 올라가 있었습니다. 그때까지 회귀를 잡는 자동화가 없었습니다.
이후 k6로 주요 엔드포인트의 기준선(baseline) 응답 시간을 커밋 단위로 기록하는 파이프라인을 만들었습니다. P95 응답 시간이 기준선에서 20% 이상 벗어나면 CI에서 빌드가 멈추도록 구성했습니다. 덕분에 성능 회귀가 생겼을 때 릴리즈 전에 알 수 있게 됐습니다.
이 경험으로 성능 지표는 측정하는 것보다 변화를 추적하고 기준선을 자동으로 지키는 것이 더 중요하다는 걸 배웠습니다.
시스템 안정성 평가에서 부하 테스트와 스트레스 테스트가 무엇이 다른지를 처음에는 잘 구분하지 못했습니다. 같은 k6 스크립트에 가상 유저 수만 늘렸는데, 시스템이 어디서 무너지는지가 아니라 얼마나 버티는지를 보는 것이 스트레스 테스트의 목적임을 뒤늦게 이해했습니다.
내구성 테스트에서는 4시간 동안 일정 부하를 유지했을 때 메모리 사용량이 계속 오르는 것을 발견했습니다. 해당 요청이 처리된 뒤에도 세션 객체가 해제되지 않고 쌓이는 누수가 원인이었습니다. 테스트 없이는 발견하기 어려운 패턴이었습니다.
이 경험으로 성능·안정성 평가에서 테스트 유형을 먼저 분별하고, 각각 다른 지표를 정해두는 것이 기준이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.