이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
IT 시스템을 직접 분석한 실무 경험은 없습니다. 수업에서 시스템 성능 분석의 기본 지표로 CPU 사용률, 메모리 점유율, 디스크 I/O를 배웠고, 세 지표가 동시에 높으면 병목을 특정 계층에서 빠르게 격리하기 어렵다는 케이스를 분석했습니다.
개선점을 찾을 때 가장 중요한 건 단순 평균이 아니라 피크 구간의 지표를 보는 것이라고 배웠습니다. 평균은 일시적 급등을 숨기기 때문에, p99 같은 분위수 지표와 함께 봐야 실제 사용자가 경험하는 지연을 파악할 수 있다는 걸 케이스에서 확인했습니다.
직접 운영 경험이 없는 만큼, 실무에서 어떤 지표를 얼마나 자주 수집하고 어떻게 시각화하는가를 빠르게 익히는 것이 첫 단계라고 생각합니다. 지표보다 "이 지표가 무엇을 의미하는가"를 해석하는 능력이 분석의 핵심이라고 봅니다.
지표를 수집하는 것과 그 지표를 기반으로 결정을 내리는 것은 다른 결의 능력입니다. CPU 사용률이 80%라는 숫자 자체가 아니라, 그 수치가 '지금 조치가 필요한 상황인가'를 판단하는 것이 더 어렵습니다.
이 판단을 가능하게 하려면 기준선(baseline)이 필요합니다. 정상 범위가 어디인지를 먼저 파악해둬야 이상이 발생했을 때 얼마나 벗어났는지를 판단할 수 있습니다. 기준선 없이 지표를 보면 숫자가 높은지 낮은지 자체를 모르는 상태가 됩니다. 지표를 보는 것에서 시작해 결정으로 옮기려면, 평소 상태를 먼저 이해하는 것이 분석의 기반이 되는 결이라고 생각합니다.
수치 지표만으로 시스템 상태를 완전히 파악하기 어려운 자리가 있습니다. 메트릭 지표는 현재 상태를 보여주지만, 왜 그 상태가 됐는지의 맥락은 로그나 트레이스를 함께 봐야 알 수 있습니다.
특히 간헐적으로 발생하는 이상은 지표 평균에 묻혀 보이지 않는 경우가 많습니다. p99 지연처럼 상위 퍼센타일 지표를 보지 않으면 대부분의 시간에 정상처럼 보이다가 특정 순간에 사용자 불편이 발생합니다. 지표 선택 자체가 무엇을 감지하고 무엇을 놓치는지를 결정합니다. 모든 문제를 하나의 지표로 잡으려는 접근은 오히려 중요한 신호를 흐리게 만드는 경우가 있습니다.
좋은 지표 선택이 분석의 시작이고, 지표의 한계를 알고 보는 것이 실질적인 분석 역량의 결이라고 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 시스템 운영 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.