이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 캠페인 발송 백엔드를 처음 설계해봤습니다. 발송 요청이 들어오면 바로 외부 API를 호출하는 구조로 시작했는데, 대규모 발송 시 동기 호출로 타임아웃이 발생하는 문제가 생겼습니다. 이후 발송 요청을 DB에 먼저 쌓고 별도 워커가 처리하는 큐 기반 아키텍처로 바꾸면서 안정성이 올라갔습니다. 캠페인 조건(대상 세그먼트·발송 시각·채널)은 campaign_rules 테이블에 분리해서 코드 변경 없이 조건을 수정할 수 있게 했습니다. 발송 결과는 클릭·오픈·수신 거부 이벤트를 별도로 수집해서 캠페인 성과를 추적할 수 있도록 설계했습니다. 동일 사용자에게 중복 발송이 되지 않도록 발송 이력 테이블도 함께 설계했습니다.
마케팅 백엔드는 발송 속도보다 정확성과 추적이 더 중요한 자리라는 걸 그때 배웠습니다.
마케팅 플랫폼 과제에서 A/B 테스트 집계 로직을 설계해봤습니다. 사용자마다 어떤 실험 그룹에 속하는지 결정하는 것이 먼저였는데, 해시 기반 분기로 같은 사용자는 항상 같은 그룹에 배정되도록 했습니다. 초기 설계에서 놓쳤던 것은 한 사용자가 동시에 여러 실험에 노출될 때 결과가 오염될 수 있다는 점이었습니다. 배너 색상 실험과 문구 실험이 동시에 돌고 있으면, 전환율 변화가 어느 실험 때문인지 알 수 없어집니다. 실험 간 독립성 조건을 설정하고, 중복 노출 사용자를 결과 집계에서 제외하는 방식을 추가했습니다. 노출·클릭·전환 이벤트는 OLTP와 분리된 읽기 전용 집계 테이블에 따로 쌓아 실험 분석 쿼리가 서비스 DB를 건드리지 않도록 했습니다.
마케팅 데이터는 수집보다 집계 설계가 더 어렵다는 것을 이 경험에서 배웠습니다.
캠페인 시스템에서 처음에는 단순 사용자 목록으로 시작했다가 세그먼트 조건이 복잡해지는 상황을 겪었습니다. 특정 기간 구매·특정 지역·특정 등급 조건이 AND/OR로 조합되기 시작하면서 쿼리가 복잡해졌습니다. 세그먼트 조건을 JSON으로 직렬화해 DB에 저장하고 런타임에 파싱하는 방식으로 바꾸자 코드 변경 없이 조건을 추가할 수 있었습니다. 운영 측면에서는 발송 실패율이 급증하는 시점을 자동으로 감지하는 것이 중요했습니다. 발송 건별 상태를 기록해 실패율 임계치를 넘으면 해당 캠페인 실행을 일시 중지하고 알림을 보내는 자동화를 추가했습니다. Kafka를 쓸 경우 소비자 그룹 지연(Consumer Lag)을 모니터링해 처리 적체를 조기에 감지할 수 있다는 것도 이 설계에서 배웠습니다.
마케팅 플랫폼은 확장성보다 운영 가시성이 먼저라는 것을 이 경험에서 얻었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.