이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
서비스 신뢰성을 높이는 작업을 처음 맡았을 때 가장 먼저 한 건 현재 상태를 숫자로 보는 것이었습니다. Prometheus와 Grafana로 에러율과 p99 레이턴시, 가용성을 대시보드에 올렸고, 그때서야 "잘 되는 것 같다"는 감각이 아니라 실제로 어디가 흔들리는지 보이기 시작했습니다. 우선순위는 SLO 위반 여부를 기준으로 잡았는데, 에러율이 0.5%를 넘기는 엔드포인트를 먼저 고치기로 합의했습니다. 알람 임계값은 처음에 너무 낮게 설정해서 노이즈가 많았고, 실제 사용자 영향이 있을 때만 울리도록 조정하는 데 두 주가 걸렸습니다. MTTR 기록을 쌓기 시작하면서 재발 유형이 보였고, 반복 장애의 60%가 특정 DB 쿼리 패턴에서 나온다는 걸 찾아냈습니다.
서비스 응답이 간헐적으로 느려진다는 신고가 들어왔는데, 로그만 봐서는 어느 구간에서 시간이 쌓이는지 알 수 없었습니다. Jaeger를 처음 도입해 분산 트레이스를 연결했는데, 요청 하나가 마이크로서비스 4개를 거치면서 특정 구간에서 800ms 이상 지연이 쌓이는 패턴이 보였습니다. 로그에서는 각 서비스가 멀쩡해 보였는데, 트레이스로 연결하니 외부 캐시 서버 응답이 느린 구간이 드러났습니다. 캐시 TTL을 조정하고 타임아웃을 분리 설정하는 방향으로 수정했고, p99 레이턴시가 1.2초에서 340ms로 줄었습니다.
메트릭만으로는 보이지 않던 경계가 트레이스로 연결되면서 보이기 시작했고, 그 이후로는 새 서비스를 붙일 때 트레이싱 계측을 먼저 붙이는 편입니다. 관찰 가능성은 구조를 미리 갖춰야 문제가 생겼을 때 보이는 것임을 그때 배웠습니다.
인턴 기간에 온콜 로테이션에 처음 들어갔는데, 알람이 울리면 무엇을 봐야 하는지 적힌 문서가 없었습니다. 선배가 직접 구두로 알려줬는데 다음 번 같은 알람에 혼자 대응할 때 이미 해결한 방법을 다시 찾는 데 시간을 낭비하는 걸 경험했습니다. 이후 알람별로 런북을 직접 작성하기 시작했습니다. '이 알람이 울리면 먼저 어디를 확인하고 어떤 조치를 취한다' 흐름을 간결하게 정리했고, 팀에 공유하자 MTTR이 평균 40분에서 18분으로 줄었다는 피드백을 받았습니다. 장애가 해결된 뒤에는 짧은 포스트모템을 작성해 재발 방지 액션을 하나씩 남겼는데, 같은 유형의 장애가 반복되는 빈도가 줄어드는 것이 보였습니다. 신뢰성은 장애를 막는 것보다 빠르게 회복하고 다시 안 나게 하는 흐름이 핵심임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.