이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 실시간 사용자 행동 로그 파이프라인 구축에 참여했습니다. Kafka에서 수집한 이벤트를 Spark Streaming으로 처리해 DW에 적재하는 구조였는데, 초반에 중복 이벤트가 5~8% 섞여 들어와 집계 지표가 흔들렸습니다. 원인은 Kafka 파티션 리밸런싱 때 컨슈머가 오프셋을 재처리하는 문제였고, 이벤트에 uuid v4 기반 멱등 키를 붙이고 DW 적재 시 UPSERT로 처리하도록 바꿔 해결했습니다. 이후 중복률이 0.02% 이하로 떨어졌고, 일별 지표 편차도 안정됐습니다. 데이터 파이프라인에서 멱등성은 처음부터 설계에 넣지 않으면 나중에 고치기 매우 까다롭다는 것을 몸으로 배웠습니다.
데이터 파이프라인을 운영하면서 특정 시간대에 처리 지연이 발생하는 것을 발견했습니다. 이벤트가 수집되는 속도와 처리되는 속도를 비교하니 피크 트래픽 시간대에 수집 속도가 처리 속도를 앞서면서 파이프라인의 랙이 늘어나는 것이 원인이었습니다. Spark 처리 단계에서 파티션 수를 늘려서 병렬 처리를 확대하니 피크 시간대의 처리 지연이 줄었는데, 파티션 수를 늘리면서 리소스 사용량도 함께 늘어나는 트레이드오프가 있었습니다. 파이프라인의 성능 개선은 단순히 리소스를 늘리는 것이 아니라 어느 단계에서 병목이 생기는지를 먼저 파악하고 그 단계에 집중하는 것이 효과적이라는 것을 이 경험에서 배웠습니다. 데이터 파이프라인은 구축 후에도 지속적으로 성능을 관찰하고 조정하는 것이 필요하다는 것을 알게 됐습니다.
데이터 파이프라인에서 원본 이벤트 스키마가 변경됐을 때 하위 단계에 연쇄적으로 영향이 전파되는 것을 경험했습니다. 수집 단계에서 새 필드가 추가됐는데, 이후 변환 단계와 DW 적재 단계에서 해당 필드를 처리하지 않아서 데이터 유실이 발생했습니다. 스키마 변경이 파이프라인 전체에 어떤 영향을 주는지를 사전에 파악하는 프로세스가 없었던 것이 원인이었습니다. 이후에는 스키마 변경 시 파이프라인의 모든 단계를 함께 검토하는 체크리스트를 만들고, 테스트 환경에서 변경된 스키마로 전체 흐름을 확인한 후 운영에 반영하는 방식으로 바꿨습니다. 데이터 파이프라인에서 스키마 관리는 개별 단계의 문제가 아니라 전체 파이프라인의 문제이고, 변경이 파이프라인 전체에 미치는 영향을 함께 추적하는 것이 데이터 품질을 유지하는 핵심이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.