이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
첫 인턴 팀에서 SLO 개념조차 정착되지 않은 상태를 보고, 개인 학습 후 SLO·에러 버짓 개념을 팀 내 발표로 공유했습니다. 처음에는 '운영 지표를 왜 개발팀이 신경 써야 하냐'는 반응이 있었고, 저는 에러 버짓 소진 속도를 기능 배포 속도와 연결한 사례를 가져와 실익을 설명했습니다. 이후 시범으로 99.5% SLO를 정의하고 알림 임계값을 함께 세팅했습니다. 결과적으로 온콜 알림의 노이즈가 40% 줄었고, 실제 사용자 영향이 있는 알림만 남아 대응 속도가 빨라졌습니다. 방법론 전파는 개념 설명보다 팀이 체감할 수 있는 숫자를 같이 만드는 것이 더 효과적임을 배웠습니다.
신뢰성 엔지니어링 방법론을 팀에 전파했을 때 일부는 정착됐는데, 기대했던 것보다 덜 사용되는 부분도 있었습니다. 에러 버짓 개념은 팀에서 관심을 갖고 도입했는데, 정기적으로 에러 버짓 소진 속도를 검토하는 습관은 지속되지 않았습니다. 발표와 시범 설정까지는 했는데, 그것이 팀의 일상적인 업무 흐름에 들어오게 만드는 부분을 충분히 설계하지 못했다는 것을 나중에 알게 됐습니다. 리뷰 미팅에서 짧게라도 에러 버짓 현황을 함께 보는 구조를 초기에 만들었다면 습관으로 정착됐을 가능성이 높다는 것을 돌이켜 보게 됐습니다. 방법론 전파는 개념을 이해시키는 것과 팀의 일상 업무에 어떻게 녹아들게 할 것인지를 함께 설계하는 것이 두 개의 다른 과제라는 것을 이 경험에서 배웠습니다.
신뢰성 엔지니어링 방법론을 전파할 때 처음에는 개념부터 설명하는 방식을 사용했는데, 일부 팀원은 이미 일이 많은 상황에서 새로운 것을 또 배워야 하는 부담으로 받아들였습니다. 개념 설명보다 현재 팀이 겪고 있는 문제에서 시작해서 그 문제에 이 방법론이 어떤 도움이 되는지를 연결하는 방식으로 바꿨습니다. 팀이 이미 불편하게 생각하던 알림 노이즈 문제를 에러 버짓 기반 알림 임계값 설정으로 해결해 보여주니, 추상적인 개념보다 실제로 불편함이 줄어드는 경험이 관심을 만드는 데 더 효과적이었습니다. 방법론 전파에서 저항이 있을 때 설득하려 할수록 더 저항이 생기는 경우가 있는데, 작은 성공 경험을 먼저 만들어주는 것이 더 효과적이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.