이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 API 서버를 배포하기 전에 locust로 부하 테스트를 처음 해보았습니다. 동시 사용자 100명 기준으로 테스트를 진행했는데, 50명을 넘어가면서 응답 시간이 갑자기 10배 이상 뛰는 지점이 있었습니다.
DB 쿼리 로그를 확인해보니 특정 API에서 N+1 쿼리가 발생하고 있었습니다. 리스트 조회 시 각 아이템마다 추가 쿼리가 나가고 있었는데, 단독으로는 빠르다 보니 기능 테스트에서 발견되지 않았습니다.
@EntityGraph로 Fetch Join을 추가하고 재테스트했더니 100명 동시 요청에서도 p95가 200ms 이내로 유지되었습니다. 비기능 테스트는 기능이 맞게 동작하는지와 별개로 꼭 해야 한다는 것을 이때 배웠습니다. 기능 테스트만으로는 이 병목을 절대 찾지 못했을 것 같습니다.
졸업 프로젝트 배포 전에 보안 점검을 처음 해봤어요. OWASP Top 10을 보면서 우리 서비스에서 해당되는 항목을 하나씩 확인했습니다.
SQL 인젝션 테스트를 해보니 검색 API에서 작은 따옴표를 넣었을 때 DB 에러 메시지가 그대로 노출되는 걸 발견했어요. 에러 메시지에 테이블명과 컬럼명이 포함돼 있어서 실제 공격에 활용될 수 있는 상태였습니다.
파라미터 바인딩으로 수정하고, 에러 응답을 일반 메시지로 덮도록 추가했어요. 또 XSS 가능성도 있어서 출력 이스케이프도 추가했습니다. 기능을 다 만든 것 같아도 비기능인 보안 영역을 안 보면 구멍이 생긴다는 걸 직접 경험했어요.
인턴 때 배포 중에 에러가 얼마나 나는지 측정하는 작업을 도왔어요. 배포 스크립트가 기존 프로세스를 죽이고 새 것을 시작하는 방식이라서, 5~10초 정도 서비스가 끊기는 걸 에러율 그래프에서 확인했습니다.
비기능 테스트 중 가용성 관점에서 배포 중 다운타임을 측정하는 게 이때였어요. 단순히 배포가 됐는지가 아니라, 배포 중에도 서비스가 유지되는지를 수치로 보는 게 의미 있었습니다.
이후 롤링 배포로 바꾸고 나서 같은 시간대에 에러율이 0%로 유지되는 걸 확인했어요. 비기능 테스트는 시스템이 얼마나 안정적으로 운영되는지 숫자로 말해주는 것이라고 느꼈습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 Tmap Mobility 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.