이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 운영 경험은 없지만, 팀 프로젝트에서 처음으로 서비스 메트릭 수집 구조를 만들어 보았습니다. 앱 서버에서 응답 시간, 에러율, 요청 수를 수집하여 대시보드로 볼 수 있게 하는 것이 목표였습니다.
오픈소스 도구를 조합하여 메트릭 수집 에이전트를 서버에 심고, 수집된 데이터를 시계열 DB에 저장하는 구조를 만들었습니다. 처음에는 에이전트 설정이 복잡하여 일주일 이상 걸렸고, 도중에 포맷이 달라져서 파싱 오류가 계속 발생하였습니다.
완성하고 나서 실제로 특정 시간대에 응답 시간이 튀는 패턴을 발견하였는데, 이는 배치 작업이 겹치는 시간이었습니다. 데이터를 보지 않았더라면 알지 못했을 문제였습니다. 관측 가능성을 만드는 것 자체가 문제 발견 능력을 키우는 과정이라는 것을 그 경험이 가르쳐주었습니다.
졸업 프로젝트에서 여러 서비스에서 나오는 로그를 중앙에서 수집하는 구조를 만들었어요. 서비스가 3개였는데 각각 다른 서버에서 돌아가서, 로그가 각자 다른 곳에 쌓이면 문제 발생 시 추적이 어려웠거든요.
에이전트 방식으로 각 서버에서 로그를 수집해서 중앙 스토리지로 보내는 파이프라인을 구성했는데, 네트워크 지연이 있을 때 로그가 손실되는 문제가 생겼어요. 버퍼를 추가해서 재전송하는 방식으로 해결했습니다.
그 구조를 만들고 나서 에러가 어느 서비스에서 시작됐는지를 타임스탬프 기준으로 역추적할 수 있게 됐어요. 장애가 났을 때 원인을 찾는 시간이 확 줄었습니다. 로그가 그냥 파일이 아니라 시스템 상태를 보여주는 언어라는 걸 그때 처음 느꼈어요.
인턴 때 메트릭 수집 시스템이 이미 있었는데 알림이 너무 자주 와서 팀원들이 무시하는 문제가 있었어요. 오히려 중요한 알림을 놓치게 되는 역효과가 생긴 거예요.
알림 조건을 분석해보니 순간적인 스파이크에 모두 반응하도록 설정돼 있었어요. 5분 평균값 기준으로 임계값을 다시 잡고, 연속 3회 초과할 때만 알림이 가도록 바꿨어요. 알림 수가 80% 줄었고, 팀이 다시 알림을 신뢰하게 됐습니다.
이 경험이 '더 많은 모니터링이 더 좋은 게 아니라, 의미 있는 신호를 고르는 게 더 중요하다'는 걸 가르쳐줬어요. 데이터가 너무 많아도 노이즈가 돼서 판단을 방해해요. 관측 시스템은 데이터를 모으는 것보다 어떤 신호에 반응할지 설계하는 게 핵심이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.