이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 서비스 로그를 처음 분석할 때 단순 에러 카운트보다 레이턴시 분포를 보는 것이 더 유용하다는 걸 배웠습니다. p99와 p50을 비교해 특정 사용자에게만 느린 경우와 전체가 느린 경우를 구분하니 원인이 다르게 보였습니다. 레이턴시가 급증하는 시간대를 특정하고 DB 슬로우 쿼리 로그와 시간축을 맞춰보니 특정 배치 작업이 실행될 때 I/O 경합이 발생하는 패턴을 찾았습니다. 로그를 서비스 → 미들웨어 → DB 계층 순서로 드릴다운하면서 각 구간의 소요 시간을 재니 실제 병목이 예상한 곳이 아니었습니다.
병목은 추측이 아니라 각 구간의 시간을 재서 찾아야 한다는 걸 그 경험으로 배웠습니다.
로그 분석에서 병목 구간을 찾은 뒤 그것이 실제 원인인지 검증하는 단계를 빠뜨리면 잘못된 최적화를 하게 됩니다. p99 레이턴시가 특정 API에 집중된 것을 발견했는데, 처음엔 DB 쿼리 때문이라고 추정했지만 단정하지 않았습니다. 분산 추적(Distributed Tracing) 데이터를 병합해 각 구간의 소요 시간을 실제로 재봤더니, 실제 병목은 외부 API 호출 대기가 연속으로 쌓이는 구간이었습니다. DB 쿼리는 빠른 편이었고 외부 I/O가 문제였다는 게 교차검증으로 확인됐습니다. 이후 동일 증상이 재현되는 조건을 부하 테스트로 만들어 최적화 후 p99가 개선됐는지 숫자로 비교했습니다. 로그 분석에서 추정과 검증은 반드시 분리해야 엉뚱한 곳을 최적화하는 데 시간을 쓰지 않는다는 걸 배웠습니다.
대규모 로그 분석에서 모든 로그를 다 보려고 하면 정작 중요한 신호를 놓치게 됩니다. 오류 로그가 하루 수백만 건 쌓이는 환경에서 단순 오류 카운트 알람은 사소한 에러에도 계속 발동돼 팀이 알람에 무뎌지는 문제가 생겼습니다. 알람 피로를 줄이기 위해 오류 예산(Error Budget) 소진율을 기준으로 알람을 재설정했습니다. 절대 건수가 아니라 전체 요청 대비 오류 비율이 임계값을 넘었을 때만 알람이 울리도록 바꿨더니, 의미 있는 경보만 남고 불필요한 노이즈가 줄었습니다. 로그는 많을수록 좋다는 게 아니라 어떤 신호가 중요한지를 먼저 정의하고 그것만 집중해서 보는 게 핵심이라는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코코네 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.