예시 답변 1
약 65초
경험 기반 구체화
서비스 성능 메트릭을 직접 측정한 실무 경험은 없습니다. 수업에서 성능 메트릭의 기본 3가지로 지연(Latency), 처리량(Throughput), 가용성(Availability)을 배웠고, 이 세 지표를 함께 보지 않으면 한 지표가 좋아도 서비스 전체 품질이 낮을 수 있다는 케이스를 분석했습니다.
팀 프로젝트에서 API 응답이 느리다는 피드백을 받았을 때, 처음엔 응답 시간 평균만 봤는데 p95·p99 수치가 평균보다 훨씬 높다는 걸 뒤늦게 발견했습니다. 평균이 성능 문제를 가릴 수 있다는 걸 그 경험에서 배웠습니다.
체계적인 성능 분석 경험은 없지만, 메트릭은 "숫자를 수집하는 것"보다 "어떤 숫자가 왜 중요한가"를 먼저 이해하는 것이 핵심이라고 봅니다. 임계값 기준과 알람 조건을 함께 설계해야 수집한 데이터가 의미를 갖는다고 생각합니다.
이 결의 특징
API 응답 평균만 봤는데 p95·p99가 훨씬 높다는 것을 뒤늦게 발견한 경험에서 평균이 성능 문제를 가릴 수 있다는 인식이 이 답에 남아 있습니다. 숫자를 수집하는 것보다 어떤 숫자가 왜 중요한가를 먼저 이해하는 것이 핵심이라는 흔적이 이 결의 특징입니다.
이 결이 통하는 자리
성능 메트릭 이해의 깊이를 확인하는 자리에서 통합니다. 평균 지표의 한계와 백분위 지표의 필요성이 실제 경험에서 도출된 형태로 남아 있을 때 면접관의 꼬리질문이 줄어드는 결이 보입니다.