이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 경영 수업에서 팀 프로젝트 진행 상황을 시각화하는 과제를 받았는데, 처음엔 측정할 수 있는 걸 전부 넣으려고 12개 지표를 나열했습니다. 교수님이 "이걸 보고 뭘 판단하냐"고 물으셨는데, 저는 대답을 못 했습니다. 그래서 저는 "지금 일정 대비 어디쯤 와 있나"를 한눈에 보여주는 3개 지표(완료 태스크 수·잔여 태스크 수·이번 주 예정 대비 달성률)만 남겼습니다. 스프레드시트에 색상 조건부 서식을 써서 달성률이 70% 미만이면 빨간색으로 바뀌게 만들었더니 팀원들이 주간 회의 때 "저 빨간 칸 얘기해야겠다"고 먼저 말하기 시작했습니다. 지표가 많으면 아무도 안 본다는 걸 그때 처음 실감했습니다.
인턴 때 주간 업무 현황 보고를 보조했는데, 기존 보고서는 이번 주 완료 건수만 나열돼 있어서 "잘 가고 있는 건지" 알 수가 없었습니다. 저는 팀장님께 지난 4주 평균을 기준선으로 추가하는 게 어떻냐고 제안했습니다. 팀장님이 "그게 의미가 있냐"고 물으셔서, 저는 지난 4주치 데이터를 직접 집계해 평균을 계산해서 보고서에 추가한 초안을 가져갔습니다. 그 이후 팀장님이 "이주는 평균보다 낮네"라며 원인을 찾기 시작하셨고, 기준선이 생기니까 주간 완료 건수가 의미 있는 숫자가 됐습니다. 처음에 "데이터가 있으면 된다"고 생각했는데, 비교할 기준이 없으면 데이터는 숫자일 뿐이라는 걸 그때 배웠습니다.
학부 졸업 프로젝트에서 웹 기반 소규모 데이터 대시보드를 만들었는데, 처음엔 모든 지표를 한 화면에 다 넣었습니다. 팀 내에서 제가 테스트용으로 보여줬더니 기획 쪽 팀원은 "숫자가 너무 많아서 뭘 봐야 할지 모르겠다"고 했고, 개발 쪽 팀원은 "이 정도면 충분한데"라고 했습니다. 저는 이 반응을 보고 역할별로 필요한 지표가 다르다는 걸 처음 알았고, 기획용 요약 뷰(4개 핵심 지표)와 개발용 상세 뷰를 분리했습니다. 기획 팀원이 요약 뷰를 보고 "이제 한눈에 보인다"고 했을 때 내심 뿌듯했는데, 처음부터 이렇게 설계했으면 수정 시간을 줄일 수 있었겠다는 생각도 들었습니다. 지금도 대시보드를 설계할 때 누가 어떤 결정을 위해 보는지를 먼저 묻는 게 습관이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 경영기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.