이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 고객센터 문의 로그 2주치를 분석하는 과제를 받았습니다. 2,000건이 넘는 데이터를 유형별로 분류했더니 배송 지연 관련이 43% 였습니다. 단순 빈도가 높다고 먼저 해결하는 게 맞는지 팀장님께 물었더니, 해결 비용과 반복 가능성을 같이 봐야 한다고 하셨습니다. 배송 지연 중 20%는 내부 처리 과정 오류였고, 수동 작업 하나를 자동화하면 해결된다는 걸 발견했습니다.
자동화 후 관련 문의가 2주 만에 40% 줄었습니다. 데이터가 많아도 분류 기준이 없으면 의사결정을 못 한다는 걸 그때 배웠습니다. 분류 기준이 없으면 데이터가 많아도 결정을 못 한다는 걸 배웠고, 이후에도 분석 전에 기준을 먼저 정합니다.
사이드 프로젝트에서 운영팀 직원 4명에게 인터뷰를 했는데, 다들 다른 불편을 말했습니다. 어디서 시작해야 할지 몰라서, 각자가 말한 불편을 실제 사용 로그에서 찾아봤습니다. 인터뷰에서 3명이 언급한 '검색이 느리다'는 불편은 로그상 평균 응답 시간 4.8초로 확인됐습니다. 그게 가장 자주 발생하고 개선 비용도 낮다고 판단해 먼저 해결했습니다.
응답 시간을 1.9초로 줄이고, 이후 인터뷰에서 불편 언급이 사라졌습니다. 인터뷰는 방향이고 로그가 증거라는 걸 그 경험으로 배웠습니다. 인터뷰는 방향이고 로그가 증거라는 걸 그 경험으로 배웠고, 이후에도 두 가지를 교차해서 확인하는 습관이 생겼습니다.
인턴 때 슬랙의 고객 문의 채널을 2주 동안 모니터링했는데, 같은 질문이 계속 반복되는 게 눈에 띄었습니다. 제가 태그를 붙여서 분류했더니 '결과가 안 나온다'는 유형이 30% 였습니다. 직접 재현해봤더니 특정 검색 조건에서 결과가 빈 화면만 나오는 버그였습니다.
처음엔 안내 문구를 고치면 된다고 생각했는데, 근본 원인이 쿼리 조건 오류라는 걸 발견했습니다. 버그를 수정한 뒤 같은 유형의 문의가 다음 주부터 사라졌습니다. 문의 데이터는 증상이 아니라 원인을 찾는 단서라는 걸 그때 배웠습니다. 문의 데이터가 증상이 아니라 원인을 찾는 단서라는 걸 배웠고, 이후에도 반복 패턴을 기록하는 습관을 유지합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.