이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대량 데이터 처리를 처음 다룬 것은 학교 프로젝트에서 로그 데이터를 분석할 때였습니다. 데이터가 많아지니까 한꺼번에 올려서 처리하는 방식은 금방 메모리 한계에 부딪혔습니다. 그래서 청크 단위로 나눠서 처리하는 방식으로 바꾸었습니다. 이후로 데이터 파이프라인을 설계할 때 배치 크기와 병렬 처리 가능 여부를 먼저 확인하는 습관이 생겼습니다.
파이프라인 설계는 데이터를 어디서 어떻게 흘려보낼지를 먼저 그려야 한다는 것을 배웠습니다. 처리 속도보다 데이터 정합성이 우선입니다. 빠른 처리가 목표지만 잘못된 변환이 나중에 더 큰 비용을 만듭니다.
사용자 상호작용 데이터는 실시간 스트림과 배치 처리 두 가지 요구가 공존하는 경우가 많아요. 실시간 알림이나 추천에는 스트림 처리가 맞고, 일별 통계나 리포트는 배치가 적합해요. 수업에서 Kafka 기반 파이프라인 설계를 배웠는데, 이벤트를 발행하고 소비하는 구조가 확장성에 유리하다는 걸 이해했어요. 변환 단계에서는 스키마 정의가 먼저예요. 필드 이름, 타입, null 처리 방식이 정해져야 이후 분석이 안정적이에요.
데이터 신뢰성은 수집보다 변환 단계에서 결정돼요. 데이터 신뢰성은 변환 단계에서 결정돼요. 스키마 정의와 기준 설정이 먼저입니다. 그 원칙으로 설계하겠습니다.
데이터 처리를 설계할 때 가장 먼저 묻는 건 어떤 질문에 답해야 하는 데이터인가예요. 목적이 명확해야 어떤 필드를 추출하고, 어떻게 집계할지가 결정되거든요. 실습에서 클릭·스크롤·구매 이벤트 로그를 처리할 때, 동일한 사용자의 세션을 묶는 것이 가장 어려웠어요. 타임아웃 기준을 어떻게 잡느냐에 따라 세션 수가 달라졌거든요.
집계 기준을 명확히 하지 않으면 분석 결과 자체가 달라진다는 걸 그때 배웠어요. 처리 로직보다 기준 정의가 먼저예요. 그 원칙은 어떤 도구를 쓰든 유효하다고 생각합니다. 집계 기준을 명확히 하지 않으면 분석 결과가 달라져요. 기준 정의가 처리 로직보다 먼저입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.