이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
스타트업 인턴 기간에 서비스 핵심 지표 체계를 처음부터 정리하는 작업에 참여했습니다. 당시 팀마다 각자 다른 숫자를 보고하다 보니 지금 서비스가 잘 되고 있냐는 질문에 일관된 답이 나오지 않는 상황이었습니다. 먼저 North Star Metric을 무엇으로 잡을지 팀과 논의하고, 그 아래 레이어별 분해 지표를 정의했습니다. 데이터는 BigQuery로 집계했고, 주간 리포트를 자동화해 팀 전체가 같은 숫자를 보는 구조를 만들었습니다. 지표 정의 문서도 노션에 정리해 지표명·계산식·담당자를 한 곳에 모았습니다. 가장 어려웠던 건 지표의 기준을 팀이 합의하는 과정이었습니다. 숫자보다 그 숫자가 의미하는 바에 대해 팀이 같은 언어를 쓰는 것이 더 중요하다는 걸 이 경험에서 배웠습니다.
전사 지표를 정의할 때 가장 힘든 부분은 각 팀이 이미 관리하던 숫자와 새 지표 체계 사이의 갭을 좁히는 과정이었습니다. 기술적인 파이프라인 작업보다 이해관계자가 같은 숫자를 신뢰하도록 만드는 작업이 더 오래 걸렸습니다. 저는 먼저 지표 용어집을 만들어 각 지표의 정의·계산식·집계 기준·담당자를 문서화했고, 변경이 생길 때마다 버전 관리를 했습니다. 지표 대시보드는 자동화된 집계 파이프라인을 구축해 수동 오류 가능성을 줄이고, 이상치가 발생하면 알림이 오도록 설정했습니다. 정의 완료 이후에도 분기마다 지표 유효성을 재점검하는 세션을 가졌는데, 사업 방향이 바뀌면 지표 체계도 함께 진화해야 한다는 걸 직접 경험했습니다. 지표는 한 번 정하면 끝이 아니라는 것이 그때 얻은 인식입니다.
전사 지표를 OKR 체계와 연동해 관리한 경험이 있습니다. Key Result로 지표를 연결하면 지표 달성 여부가 전사 목표와 직결되어 각 팀이 수치를 더 능동적으로 추적하는 문화가 자연스럽게 형성됐습니다. 중요했던 건 측정 가능하고 해석 가능한 지표를 고르는 것이었습니다. 수집은 쉽지만 의미 해석이 어려운 지표는 오히려 혼선을 만들었습니다. 이상 수치가 발생했을 때 빠르게 인지할 수 있도록 임계값 기반 알림 시스템을 연동했고, 알림 발생 시 원인 분석 담당자를 사전에 지정해 두었습니다. 주간 리포트에는 수치만이 아니라 해석과 시사점을 함께 담았고, 이 형식이 경영진이 지표를 의사결정에 실질적으로 활용하는 빈도를 높이는 데 영향을 미쳤습니다. 숫자보다 그 숫자가 만들어내는 대화의 질이 지표 관리의 진짜 성과라는 생각을 갖게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 데이터 분석가 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.