이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
시스템 성능 점검에서 가장 먼저 확인하는 지표는 응답 시간(latency)입니다. P95·P99 같은 고백분위 응답 시간이 느려지면 일부 사용자가 심각한 지연을 경험하고 있다는 신호이기 때문에, 평균값보다 이 지표를 더 신뢰합니다.
에러율도 함께 봅니다. 서버 에러 비율이 갑자기 올라가거나 특정 엔드포인트에서만 오류가 집중되는 패턴이 보이면 코드 변경이나 외부 의존성 문제를 의심합니다. 배포 이력과 에러 그래프를 겹쳐보면 원인을 좁히는 시간이 크게 줄었습니다.
CPU·메모리 사용률은 용량 계획에 유용한 지표입니다. 트래픽 증가 없이 CPU가 지속 상승하면 메모리 누수나 무한 루프를 의심하고, 메모리가 서서히 증가하면 GC 로그를 함께 분석해 원인을 파악했습니다.
성능 지표를 보는 것에서 멈추지 않고 원인을 좁히는 분석 과정이 더 중요하다는 것을 배운 경험이 있습니다. 응답 지연이 갑자기 올랐는데, CPU와 메모리 지표는 정상이어서 원인을 찾기 어려웠습니다. 분산 추적(Distributed Tracing)을 도입해 서비스 간 호출 흐름을 시각화했더니, 특정 외부 API 호출에서 지연이 집중되고 있다는 것이 보였습니다. 단일 지표로는 보이지 않던 병목이 호출 체인을 그려보니 바로 드러났습니다.
지표는 증상을 보여주지만, 추적은 원인의 위치를 특정한다는 차이를 그때 실감했습니다. RED 방법론과 USE 방법론을 함께 쓰면, 사용자 체감 문제와 리소스 병목 양쪽을 교차 검증할 수 있다는 것도 이후 정기 점검에 반영했습니다. 지금도 지표 하나가 이상할 때 다른 지표와 타임스탬프를 맞춰 교차 확인하는 것을 분석 루틴으로 유지하고 있습니다.
메모리 사용률이 서서히 올라가는 문제를 접했을 때, GC 로그를 처음으로 직접 분석한 경험이 있습니다. 단순히 메모리가 높다는 것만 알고 있었는데, GC 로그를 열어보니 Full GC가 너무 자주 발생해서 애플리케이션이 수초간 멈추는 현상이 반복되고 있었습니다. 어느 객체가 메모리를 많이 잡고 있는지 파악하기 위해 힙 덤프를 찍고 분석 도구로 열어보니, 캐시로 쓰려고 만든 컬렉션이 만료 정책 없이 무한히 증가하고 있었습니다. 원인을 파악하고 나서 메모리 기반 캐시에 TTL과 최대 크기 제한을 추가했고, GC 빈도가 줄면서 응답 지연도 안정화됐습니다.
GC 로그는 메모리 문제를 진단하는 가장 직접적인 수단인데, 처음에는 읽는 법 자체를 몰라서 시간이 걸렸습니다. 이후로는 서비스에 GC 로그 출력을 기본으로 켜두고, 메모리 이상 징후가 보이면 가장 먼저 여기를 확인하는 루틴을 만들었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 인프라 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.