마케팅 자동화를 위한 비동기 멀티 API 파이프라인 구축 방법

Google Ads, GA4, Meta Ads, 그리고 Google Search Console의 데이터를 통합하도록 설계된 플랫폼을 구축하다 보면, 곧 거대한 병목 현상에 직면하게 됩니다. 바로 **API 지연 시간 (Latency) 및 속도 제한 (Rate Limiting)**입니다.

만약 한 대행사가 50개의 클라이언트를 보유하고 있고, 각 클라이언트마다 4개의 서로 다른 광고 네트워크에서 데이터를 가져와야 한다면, 순차적인 추출 루프 (Chronological extraction loop)는 애플리케이션을 완전히 멈추게 할 것입니다. 서버는 타임아웃 (Time out)이 발생하고, 데이터베이스 연결 풀 (Database connection pools)은 고갈되며, 사용자는 영원히 돌아가는 로딩 화면만 보게 될 것입니다.

우리 플랫폼의 핵심 엔진인 RaiseReturn은 독점적인 비공개 코드베이스로 유지되지만, Node.js에서 비동기 페칭 (Asynchronous fetching) 문제를 해결하기 위해 우리가 사용한 정확한 아키텍처 로직을 공유하고자 합니다.

병목 현상: 순차 처리 (Chronological Processing) vs 병렬 처리 (Parallel Processing)

대부분의 표준 API 래퍼 (API wrappers)는 데이터를 순차적으로 가져오도록 유도합니다:

• Google Ads의 응답을 기다립니다.
• 해당 데이터를 가져온 후, Meta Ads의 응답을 기다립니다.
• GA4의 응답을 기다립니다.

이는 멀티 테넌트 확장성 (Multi-tenant scalability) 측면에서 매우 좋지 않은 접근 방식입니다. 만약 하나의 API에서 3초의 네트워크 지연이 발생하면, 전체 파이프라인이 밀리게 됩니다. 대신, 이러한 네트워크 요청을 동시에 실행(Concurrently)해야 하며, 전체 시퀀스를 중단시키지 않고 개별 실패를 우아하게 처리(Handle gracefully)해야 하고, 데이터베이스에 쓰기 전에 서로 다른 페이로드 (Payloads)를 통일된 스키마 (Schema)로 정규화 (Normalize)해야 합니다.

정제된 예시: 비동기 배치 워커 (Asynchronous Batch Worker)

아래는 Promise.allSettled를 사용하여 완전히 다른 API 엔드포인트로부터 메트릭 (Metrics)을 동시에 가져오도록 데이터 워커 (Data worker)를 구조화하는 가볍고 깔끔한 추상화 예시입니다.

allSettled를 사용하면 Meta Ads API에서 무작위로 인증 오류나 500 타임아웃이 발생하더라도, 스크립트가 해당 클라이언트에 대한 Google Ads 및 GA4 데이터를 성공적으로 캡처하고 처리할 수 있음을 보장합니다.

// 동시 데이터 추출 워커의 가벼운 추상화
const fetchClientMetrics = async (clientConfig) => {
  const providers = [
...

프로덕션 환경으로의 확장

실제 프로덕션 환경 (Production environment)에서는 수백 개의 이러한 태스크를 Express 컨트롤러 내부에서 단순히 무작위로 실행하게 둘 수 없습니다. 또한, 이를 뒷받침할 견고한 메시지 브로커 (Message broker) 또는 워커 레이어 (Worker layer)가 반드시 필요합니다:

• 작업 큐잉 (Job Queuing): 데이터 동기화 태스크를 큐 백엔드 (AWS SQS 또는 BullMQ와 같은)로 푸시합니다.
• 상태 관리 (State Management): 실패한 API 응답에 대한 재시도 (Retry)를 처리하기 위해 MongoDB 또는 PostgreSQL과 같은 데이터베이스에서 추출 상태를 동적으로 추적합니다.
• 페이로드 정제 (Payload Sanitization): 들어오는 배열을 전용 트랜스포머 레이어 (Transformer layer)에 통과시켜 서로 다른 통화 코드, 시간대 변형, 지표 명명 규칙을 통일된 대시보드 레이아웃으로 매핑합니다.

리포팅의 미래 구축하기

변동성이 큰 외부 API를 지속적으로 모니터링하는 신뢰할 수 있고 결함 허용 (Fault-tolerant) 능력을 갖춘 인프라를 구축하는 데는 상당한 시간과 아키텍처 설계가 필요합니다. 그렇기 때문에 저희는 RaiseReturn을 구축했습니다. 에이전시들이 맞춤형 ETL 파이프라인을 작성하는 데 수개월을 소비하게 만드는 대신, 엔터프라이즈급 리포팅 인프라를 즉시 사용할 수 있도록 하기 위해서입니다.

현재 데이터 파이프라인을 구축 중이거나 마케팅 API 스키마 (Schema)로 고군분투하고 있다면, 아래 댓글에서 아키텍처에 대해 이야기해 봅시다!