이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
광고 클릭·노출 이벤트를 실시간 집계하려면 이벤트 수집, 스트림 처리, 저장 세 단계를 각각 설계해야 합니다. 이벤트가 초당 수천 건 발생할 수 있기 때문에 Kafka 같은 메시지 큐로 버퍼를 두고 소비자가 처리하는 구조가 기본입니다. 스트림 처리는 Flink나 Spark Streaming으로 윈도우 기반 집계를 하고, 결과는 저지연 조회가 가능한 Redis나 ClickHouse에 씁니다. 데이터 엔지니어링 수업에서 이 아키텍처를 다이어그램으로 설계하면서, 중복 이벤트 처리가 가장 까다로운 문제라는 걸 배웠습니다. 멱등성 있는 집계 로직과 이벤트 ID 기반 중복 제거를 함께 고려해야 정확한 카운트가 가능합니다. 이 설계 경험으로 대용량 스트리밍 시스템의 핵심은 정확성과 지연 사이의 균형이라는 걸 배웠습니다.
집계 정확도를 유지하면서 레이턴시를 낮추는 것이 실무 설계의 핵심 과제입니다.
광고 이벤트 집계에서 중복 클릭 제거가 정합성의 핵심 문제입니다. 사용자가 같은 광고를 짧은 시간에 여러 번 클릭하면 중복 과금이 발생할 수 있고, 네트워크 재전송으로 같은 이벤트가 두 번 들어오는 경우도 있습니다. 이벤트에 고유 ID를 부여하고, 스트림 처리 단계에서 단시간 내 같은 ID가 들어오면 무시하는 방식이 기본 접근입니다. Redis 같은 인메모리 스토어에 처리된 이벤트 ID를 단기 캐시로 관리하면 중복 체크 속도를 높일 수 있습니다.
처리 속도와 정합성의 트레이드오프에서 윈도우 크기가 핵심 파라미터입니다. 이벤트 ID가 중복 방지의 기반입니다. 단기 캐시가 중복 체크 속도를 결정합니다. 멱등성 처리가 정합성을 보장합니다.
광고 클릭·노출 집계 시스템을 설계할 때 Lambda 방식(배치+스트림)과 Kappa 방식(스트림 단일) 중 하나를 선택하는 판단이 필요합니다. 광고 집계는 실시간 과금과 일별 리포팅 둘 다 필요한 경우가 많은데, Lambda는 정확한 배치 집계를 보장하지만 운영 복잡도가 높고, Kappa는 구조가 단순하지만 히스토리 재처리 시 전체 스트림을 다시 돌려야 합니다. 광고 환경처럼 지연 이벤트(late arriving events)가 빈번하다면 Lambda가 유리합니다. 설계 결정은 재처리 빈도와 운영 역량에 따라 달라집니다.
재처리 요건이 아키텍처 선택을 결정합니다. 운영 복잡도와 정확도는 트레이드오프입니다. 요구사항이 구조를 결정합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.