이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 서비스 장애 원인을 찾는 데 1시간 이상 걸린 경험이 관찰 가능성 설계에 관심을 갖게 된 계기였습니다. 당시에는 로그가 흩어져 있고 메트릭이 없었습니다. 이후 프로젝트에서는 로그·메트릭·트레이스 세 축을 처음부터 설계해서 들어갔습니다. 로그는 structlog로 JSON 형태로 남기고, 메트릭은 Prometheus 클라이언트로 요청 수와 응답 시간을 수집했습니다. 트레이스는 trace_id를 요청 헤더로 전파해서 마이크로서비스 간 요청 흐름을 한 줄로 연결할 수 있게 했습니다. 운영 중에 알림 임계값을 너무 낮게 잡으면 알림이 너무 자주 와서 무시하게 되는 문제도 경험했고, 임계값 설정 자체도 설계가 필요하다는 걸 배웠습니다.
관측 가능성은 만들 때가 아니라 장애가 났을 때 진짜 가치가 드러나는 자리라는 걸 그때 알았습니다.
관찰 가능성 체계를 도입한 뒤 가장 뚜렷하게 달라진 것은 장애 대응 시간이었습니다. 이전에는 문제가 생기면 로그를 grep하거나 배포 이력을 뒤지는 데 시간을 썼는데, 구조화된 로그와 트레이스를 붙이고 나서는 어느 서비스, 어느 엔드포인트에서 오류가 시작됐는지를 첫 5분 안에 좁힐 수 있었습니다.
OpenTelemetry로 trace_id를 서비스 간에 전파하면서 분산 환경에서 요청 흐름을 한 줄로 연결하는 구조를 만들었고, 응답 시간 P99 지표를 SLO 기준으로 정해 알림 임계값을 설정했습니다. SLO를 99.5%로 설정하고 에러 버짓을 계산해보니 월간 허용 가동 중단 시간이 약 3.6시간이라는 것이 구체적으로 잡혔고, 알림이 실제 예산 소비와 연결된다는 느낌이 생겼습니다.
지표를 보기 전까지는 장애 복구가 잘 됐는지 나쁘게 됐는지 감으로만 판단했는데, 측정 결과가 쌓이고 나서야 '이번은 MTTR이 줄었다'고 말할 수 있는 자리가 생겼습니다.
관찰 가능성 체계를 운영하면서 처음 맞닥뜨린 현실적인 문제는 알람 피로였습니다. 임계값을 조금 낮게 설정하자 자정에도 알람이 오는 상황이 됐고, 팀원들이 알람을 습관적으로 무시하기 시작했습니다.
이 경험에서 알람 설계도 별도의 관리가 필요하다는 것을 배웠습니다. 알람을 긴급·경고·정보 세 단계로 나누고, 긴급 알람만 즉시 호출로 연결하고 나머지는 집계 후 배치로 전달하는 방식으로 바꾸자 팀 내 알람 피로가 크게 줄었습니다.
용량 계획도 메트릭이 쌓이고 나서야 의미 있게 할 수 있었습니다. 월별 요청 증가율을 메트릭에서 추출하고 현재 인프라가 언제 병목에 걸릴지를 역산해보니, 단순히 '느려지면 늘린다' 방식보다 훨씬 여유 있게 대응할 수 있었습니다. 관찰 가능성이 문제 탐지 이상으로 용량 계획·팀 운영까지 이어지는 자리라는 것을 그 경험에서 처음 느꼈습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.