이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
이벤트 로깅 자동화에서 가장 먼저 해야 하는 것은 어떤 이벤트를 어떤 구조로 수집할지를 먼저 정의하는 것이라고 생각합니다. 코드마다 제각각 넣으면 나중에 분석이 불가능해지기 때문입니다.
팀 프로젝트에서 클릭·페이지 뷰·폼 제출 이벤트를 중앙에서 관리하는 구조를 만들었습니다. 이벤트 이름, 속성 키, 타입을 스프레드시트에 등록해두고, 코드에서는 그 이름만 참조하는 방식이었습니다. 처음에는 팀원마다 다른 이름으로 로깅하다가 분석 단계에서 같은 이벤트가 3가지 이름으로 쌓인 것을 발견하여 마이그레이션을 해야 했습니다. 실패는 스키마 문서 없이 시작한 것이었고, 그 이후로 로깅 이벤트는 문서에 먼저 등록하는 규칙을 만들었습니다.
로깅 자동화는 코드보다 이벤트 이름과 속성 정의가 먼저여야 합니다.
이벤트 로깅 자동화를 처음 시도했을 때 가장 큰 문제는 컴포넌트마다 로깅 코드가 반복된다는 것이었습니다. 하나를 바꾸면 여러 곳을 다 바꿔야 하는 구조였어요.
리액트 프로젝트에서 로깅 로직을 커스텀 훅으로 분리하고, 클릭 이벤트에 로깅이 필요한 컴포넌트는 그 훅만 import해서 쓰는 방식으로 바꿨습니다. 공통 속성(세션 ID, 타임스탬프, 사용자 상태)은 훅 내부에서 자동으로 붙이도록 했어요. 전체 로깅 코드 라인이 약 40% 줄었고, 나중에 공통 속성을 바꿔야 할 때 한 곳만 수정하면 됐습니다. 실패는 처음에 훅을 너무 범용으로 만들려다가 파라미터가 복잡해져서 오히려 쓰기 어려워진 것이었어요.
자동화 코드는 범용성보다 팀이 실제로 쓸 수 있는 단순함이 더 중요합니다.
이벤트 로깅에서 반복적으로 겪은 문제는 새 기능을 배포했는데 로깅이 빠진 것을 나중에 발견하는 것이었습니다. 분석하려고 보면 데이터가 없는 상황이에요.
팀 프로젝트에서 주요 이벤트에 대한 로깅 호출 여부를 테스트로 검증하는 구조를 추가했습니다. 특정 버튼 클릭 시 로깅 함수가 호출됐는지를 단위 테스트로 확인하는 방식이었어요. 처음 적용하고 나서 신규 기능 2개에서 로깅이 빠진 케이스를 배포 전에 잡았습니다. 실패는 모든 이벤트에 테스트를 넣으려다가 유지보수 비용이 너무 커진 것이었고, 핵심 전환 이벤트만 테스트로 커버하는 방향으로 범위를 좁혔어요.
로깅 자동화는 수집 구조를 만드는 것만큼, 누락 없이 쌓이는지를 검증하는 구조도 함께 있어야 신뢰할 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.