이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
로그 설계에서 가장 중요한 것은 무엇을 위한 로그인지 먼저 정하는 것이라고 생각합니다. 디버깅용인지, 사용자 행동 분석용인지, 성능 모니터링용인지에 따라 수집해야 할 항목이 완전히 달라집니다. PM 인턴에서 이벤트 로그 정의서를 작성할 때, 먼저 분석 목적을 팀과 합의하고 그 기준으로 항목을 역산하였습니다.
목적 없이 항목부터 정하면 나중에 쓸 수 없는 로그가 쌓인다는 것을 그때 배웠습니다. 개인정보가 포함될 수 있는 항목은 보안 검토를 설계 단계부터 반영하였습니다. 로그는 나중에 분석할 사람이 읽는 문서라는 관점으로 접근하니 항목 선택이 훨씬 명확해졌습니다. 목적이 설계를 결정합니다.
서비스 운영에서 로그가 일관되지 않으면 분석이 불가능해진다는 걸 인턴 때 직접 겪었어요. 팀마다 이벤트 명칭이 달라서 같은 행동을 보는 지표가 다르게 나왔습니다. 이후 로그 네이밍 컨벤션을 만들고, 신규 이벤트를 추가할 때 정의서를 먼저 작성하는 프로세스를 제안했어요.
화면명_액션명_대상 구조로 통일했더니 집계 오류가 줄었습니다. 일관성이 없는 로그는 데이터가 아니라 노이즈라는 말이 그때 이해됐어요. 로그는 설계할 때 한 번 제대로 하면 오래 쓸 수 있고, 나중에 바꾸면 히스토리가 끊긴다는 것도 배웠습니다. 초반에 표준화에 시간을 쓰는 게 아깝게 느껴졌는데, 그게 나중에 분석 시간을 훨씬 더 많이 아껴줬어요. 초반 투자가 결국 더 효율적이에요.
AI 추천 기능 기획 프로젝트에서 어떤 사용자 행동 데이터를 수집할지가 기능 품질을 결정한다는 걸 배웠어요. 처음엔 클릭 수만 보려고 했는데, 클릭 후 체류 시간과 스크롤 깊이가 더 의미 있는 신호라는 걸 데이터팀과 협의하면서 알게 됐습니다. 로그 설계 단계에서 분석 팀과 함께 검토하지 않으면, 나중에 쓸 수 없는 로그가 쌓이더라고요. 무엇을 수집하느냐가 AI 모델 품질을 좌우한다고 봐요.
로그가 데이터가 되고, 데이터가 기능이 된다는 연결을 이 프로젝트에서 처음 실감했습니다. 설계 초기에 분석 목적을 함께 논의하는 게 가장 중요한 단계였어요. 수집하지 않은 건 분석할 수 없어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 서비스 오너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.