이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
SRE를 직접 맡은 것은 아니지만, 인턴 중 온콜 대응 과정을 옆에서 지켜보았습니다. SLI와 SLO를 기준으로 장애 심각도를 판단하는 방식이 인상적이었습니다. 단순히 '느리다'가 아니라 'SLO 위반 여부'로 우선순위가 정해지는 구조가 감정보다 기준을 앞에 두는 방식이라고 느꼈습니다. 제가 직접 기여한 것은 모니터링 대시보드 정비였는데, 지표가 불분명하여 장애 시 어디를 봐야 할지 파악이 어려웠습니다.
핵심 지표를 정리하고 나서 대응 속도가 빨라졌습니다. 데이터 없이 SRE를 한다는 것은 감각에만 의존하는 것이므로, 가시성이 전부입니다. SRE가 결국 시스템보다 팀의 대응 문화라는 것을 그때 느꼈습니다. 도구보다 어떻게 반응하는지가 서비스 신뢰를 결정합니다.
학교 프로젝트에서 부하 테스트를 돌리면서 서비스 병목 지점을 찾은 경험이 있어요. k6로 트래픽을 높여보니 DB 커넥션 고갈이 가장 먼저 나타났어요. 커넥션 풀 설정을 조정하고 쿼리 최적화를 병행하니 처리량이 눈에 띄게 올라갔어요. SRE 관점에서는 이게 SLO 지표 개선으로 연결된다고 이해해요. 실서비스에선 에러 예산 개념으로 개발 속도와 안정성을 균형 잡는 방식이 더 정교할 것 같아요. 지금은 공부 수준이지만 실제 대규모 서비스에서 이 원칙이 어떻게 적용되는지 배우고 싶어요. 실습 수준이지만 SLO와 에러 예산 개념을 배우고 나서, 운영과 개발의 관계를 다르게 보게 됐어요. 실무에서 더 깊이 배우고 싶어요.
SRE 원칙 중 가장 인상 깊었던 건 '장애를 없애는 게 아니라 빠르게 복구하는 구조를 만드는 것' 이에요. 인턴 때 배포 후 이상 지표를 CloudWatch로 확인하다 응답 지연을 발견한 적 있어요. 직접 원인을 찾지는 못했지만, 엔지니어에게 빠르게 전달해서 롤백이 이뤄졌어요. 사후에 포스트모텀을 작성하는 과정을 옆에서 봤는데, 원인보다 재발 방지 항목을 더 많이 다루는 게 인상적이었어요. 오류가 생긴 걸 탓하기보다 다음에 더 빠르게 잡는 구조를 만드는 쪽으로 에너지를 쓰는 문화가 맞는 방향이라고 느꼈어요. 장애 대응보다 장애를 빠르게 감지하는 구조가 더 중요하다는 걸 이 경험에서 배웠어요. 포스트모텀이 그 구조를 만들어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.