이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
서비스 고도화를 시작할 때 가장 먼저 하는 것은 데이터로 병목을 찾는 것입니다. 퍼널 분석이나 이탈 지점 확인을 통해 어느 단계에서 사용자가 가장 많이 떨어지는지를 파악하면, 체감으로 느끼는 문제보다 실제로 임팩트가 큰 지점을 우선순위에 둘 수 있었습니다.
개선 방향이 정해지면 가설을 세우고 A/B 테스트로 검증하는 방식을 사용했습니다. 직관만으로 개선안을 전면 배포하면 오히려 지표가 떨어지는 경우가 있기 때문에, 소수 사용자에게 먼저 노출해 효과를 확인한 뒤 전체로 확장했습니다.
배포는 점진적 롤아웃으로 진행했습니다. 한 번에 전체 사용자에게 배포하면 문제 발생 시 영향 범위가 넓어지기 때문에, 10% → 50% → 100% 순서로 단계적으로 확대하면서 각 단계에서 핵심 지표를 모니터링했습니다. 이 방식이 고도화 작업의 안정성을 높이는 데 효과적이었습니다.
서비스 고도화 방향을 찾을 때 지표만으로는 안 보이는 것을 VOC에서 발견한 경험이 있습니다. 퍼널 수치는 어디서 이탈하는지 보여주지만, 왜 이탈하는지는 수치 뒤에 숨어 있었습니다. 앱 스토어 리뷰와 CS 문의를 직접 읽으면서 특정 기능 진입 시 로딩이 너무 길다는 불만이 집중돼 있다는 것을 발견했고, 지표상으로는 드러나지 않던 구간이었습니다.
피드백 400개를 분류 태깅해서 빈도와 사용자 영향도를 매겼더니, 개선 우선순위가 내부 팀의 체감과 다르다는 걸 확인할 수 있었습니다. 이후 해당 기능을 개선하고 VOC 분류 빈도가 줄었는지를 후속 주에 확인했습니다. 데이터와 VOC는 같은 현상을 서로 다른 각도에서 보여준다는 것을 이 경험으로 배웠습니다.
고도화 작업에서 측정 없이 진행한 개선은 효과가 있는지 확인할 방법이 없다는 것을 실패 경험으로 먼저 배웠습니다. 처음에 기능 하나를 리팩터링한 뒤 빨라진 것 같다는 체감만 있었는데, 다음 스프린트에 지표를 보니 오히려 p95 응답 시간이 늘어나 있었습니다.
체감과 지표가 일치하지 않을 수 있다는 것을 그때 처음 알았습니다. 이후에는 고도화 전에 현재 지표를 기록해두고, 변경 후 동일 기간 비교 값을 반드시 확인하는 방식을 잡았습니다. p50·p95·p99를 함께 보는 습관이 생겼고, 평균만 보면 놓치는 꼬리 지연을 추적할 수 있게 됐습니다.
지표를 먼저 정의하지 않으면 개선 방향이 흔들린다는 원칙을 이 경험에서 갖게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.