Enjoy, savor, and love debugging

네이버 인플루언서 마케팅 플랫폼 구축

10 min read

포트폴리오 소개

네이버 인플루언서의 상위노출 확률에 기반한 빅데이터 구축 및 이메일 발송 시스템 구축

네이버 인플루언서 마케팅의 핵심은 상위노출 입니다.
  • 블로거는 1500만개가 넘는 것으로 조사되고 있지만, 이 중에서 유의미한 키워드에서 상위노출이 가능하고 유지할 수 있는 인플루언서는 많지 않습니다.
  • 해당 웹 어드민은 상위노출 이력을 수집해, DB화 하고, 해당 데이터를 통해 특정 계정의 특정 카테고리에서의 노출 확률을 분석하고, 특정 확률 이상의 사람들에게 이메일을 보내, 광고를 원하는 클라이언트와 영향력 있는 인플루언서를 연결해주는 시스템 입니다.

기능 명세

  • 캠페인 그룹 관리
  • 메일 본문 템플릿 관리
  • 검색 키워드 템플릿 관리
  • 발송 수신거부 필터링
  • 발송한 메일 열람 체크 (+ 읽은 비율 통계)
  • 네이버 스팸 대응
  • 스팸 되었을 때 다른 발송 메일 변경
  • 메일 예약 발송
  • 원클릭 발송 메일 할당
  • 다계정 사용시에 특정 메일이 중복 할당 되지 않도록 방지
  • 발송 봇을 따로 분리, 클라우드(CloudType)를 활용한 다중화
  • 가용중인 백엔드 서버 헬스 체크 및 신규 서버 기동시 자동 DB 등록

작업 범위 - 개발에 참여한 범위 및 지원환경

  • Node.js를 활용해 백엔드를 구축 했으며
  • UI는 html/ javascript / ajax / CSS 를 사용해 거의 순수한 자바스크립트를 활용해 100% 구축했습니다
  • 복잡한 라이브러리를 사용하지 않아 추후 유지보수 인력을 구하더라도 쉽게 구할 수 있게 장벽을 낮췄습니다

주안점 - 서비스 구축 시 중점이 되었던 사항

1. 시스템의 문제점 및 극복 방안과 성능 개선

대량 메일 발송 시 발생하는 문제점과 해결 방안

현재 시스템에서는 대량의 마케팅 이메일을 발송할 때 다음과 같은 주요 문제점이 있었습니다

  1. 발송량 제한
    • 이메일 서비스 제공자(이하 하이웍스)에서 단일 계정당 대량 발송 제한있음
    • 단시간 내 많은 메일 발송 시 네이버 스팸으로 간주되어 계정이 차단될 가능성 매우 높음
  2. 처리 속도 제한
    • DB 쿼리 및 메일 발송 작업을 단일 스레드에서 처리할 경우 병목 현상 발생
  3. 시간대 제약
    • 일반적인 일상 시간 외 메일은 스팸 처리 가능성 높고 읽지 않을 확률이 높음
문제 해결 방안

이러한 문제점을 해결하기 위해 다음과 같은 아키텍처 설계로 극복했습니다

  1. DB 폴링 기반 분산 처리 시스템

    • 여러 서버가 동시에 DB 폴링을 통해 발송 작업을 분담
    • 각 서버는 mail_server_status 테이블에 자신의 MAC 주소를 등록하고 주기적으로 상태 업데이트
    • 코드에서는 setInterval(async () => { ... }, 10000) 함수로 10초마다 서버 생존신호 업데이트

  2. 발송 스케줄링 및 지연 전략

    regularMailJob = schedule.scheduleJob("*/3 * * * * *", async function () {
  // 3초마다 메일 발송 작업 수행
  // 순차 지연 발송으로 하이웍스/네이버의 스팸 필터링 회피
});

  3. 발송 작업 교차 처리

    // flag 값에 따라 즉시 발송과 예약 발송 순서를 번갈아가며 처리
if (flag === 1) {
  await mailSendProcess();
}
if (flag === -1) {
  await mailSendProcessReverse();
}
flag *= -1;

  4. 시간대 제약 관리

    • DB에서 허용된 발송 시간대를 일상 시간대에 맞춰 효과적인 시간에만 발송
    • 비허용 시간대에는 작업 자동 종료
    const { isNowInRange } = await checkMailDeliveryTimeZone();
if (!isNowInRange) {
  logger.warn("This is not an acceptable time to send mail.");
  finishJob();
}
성능 개선 결과

이러한 아키텍처를 통해

  • 단일 서버에서 시간당 약 1,200건의 메일 발송 가능
    • 3초마다 1건 처리 → 1분에 20건 처리 가능 (60초 ÷ 3초 = 20건)
    • 1시간에 1,200건 처리 가능 (20건 × 60분 = 1,200건)
  • 여러 서버 분산 배치 시 동시에 수천 건의 메일 처리 가능
  • 각 메일 서버는 독립적으로 작동하면서 동일한 DB를 참조하여 중복 발송 방지
  • 하이웍스/네이버의 발송 제한을 회피하면서도 대량 발송 구현

2. DB 폴링 방식의 분석 및 대안 고찰

현재 DB 폴링 방식의 특징

  1. 구현 방식

    • 여러 서버가 일정 주기(3초)마다 DB를 쿼리하여 처리할 메일 작업이 있는지 확인
    • FOR UPDATE 락을 사용하여 동시에 여러 서버가 같은 작업을 처리하지 않도록 보장

  2. 장점

    • 구현이 간단하고 직관적
    • 서버 확장이 용이 (새 서버 추가 시 별도 설정 없이 자동으로 작업 분담)
    • 서버 장애 시 해당 서버의 상태 업데이트가 중단되어 DB에서 자동으로 비활성 처리되고, 다른 서버가 해당 작업을 가져가 처리
    • 트랜잭션 처리와 롤백이 용이하여 작업의 원자성 보장

  3. 단점

    • 주기적 폴링으로 인한 DB 부하 발생
    • 일정한 지연 시간(최대 3초) 발생
    • 작업량이 많지 않을 때도 지속적으로 DB 쿼리 실행
메시지 큐 방식과의 비교

메시지 큐(RabbitMQ, Kafka 등)를 사용한다면

  1. 장점

    • 실시간 작업 처리로 지연 시간 최소화
    • DB 부하 감소
    • 더 복잡한 메시지 라우팅 및 필터링 가능
    • 작업량에 따른 자동 스케일링에 더 적합

  2. 단점

    • 추가 인프라 구성 필요 (메시지 브로커 서버)
    • 구현 및 유지보수 복잡도 증가
    • 장애 시 복구 절차가 더 복잡
    • DB 트랜잭션과 메시지 큐 간의 분산 트랜잭션 처리가 복잡하여 일관성 보장이 더 어려움

현재 방식 선택 이유

DB 폴링 방식을 선택한 핵심 이유

  1. 신뢰성 중시

    • 메일 발송은 실시간성보다 안정적인 발송과 중복 방지가 더 중요
    • DB 트랜잭션을 통한 ACID 특성 보장 가능

  2. 운영 환경 제약

    • 제한된 서버 자원에서 추가 인프라 없이 구현 가능
    • 기존 DB 인프라를 최대한 활용

  3. 유지보수 용이성

    • 단순한 아키텍처로 문제 발생 시 디버깅이 용이

  4. 요구사항 충족

    • 3초 내외의 지연은 마케팅 메일 발송에 큰 영향이 없음
    • 현재 발송량(시간당 ~1,200건)을 충분히 처리 가능

이와 같은 아키텍처 선택을 통해 안정적이고 확장 가능한 메일 발송 시스템을 구축했으며, 네이버 인플루언서 마케팅 플랫폼의 핵심 기능을 성공적으로 지원하고 있습니다.

그래프 뷰

백링크