멀티채널 광고·정산 데이터 수집 파이프라인 소개 영상
문제
이 고객사는 대형 오픈마켓과 리테일 미디어 광고, 검색광고까지 여러 판매·광고 채널을 동시에 운영하는 이커머스 브랜드입니다. 정산과 광고 성과를 보려면 채널마다 각각의 포털에 따로 로그인해 엑셀이나 리포트를 손으로 내려받아야 했고 담당자는 매일 아침 이 반복 작업에 상당한 시간을 썼습니다.
문제는 시간만이 아니었습니다. 내려받은 파일은 담당자 PC에 흩어져 팀이 함께 보기 어려웠고 담당자가 자리를 비운 날에는 그날 데이터가 통째로 비었습니다. 채널이 늘어날수록 이 방식은 버티기 어려운 구조였습니다.
수집 자체도 채널마다 난이도가 전혀 달랐습니다. 어떤 채널은 로그인 페이지를 사람처럼 조작해야만 데이터에 닿을 수 있었고 어떤 채널은 깔끔한 REST API를 제공했으며 또 어떤 채널은 요청마다 서명을 계산해 붙여야 하는 인증을 요구했습니다. 게다가 로그인 과정에 문자 메시지 2차 인증이 걸린 채널이 있어 사람이 지켜보지 않으면 애초에 로그인 단계에서 멈추는 것이 가장 큰 벽이었습니다.
마지막 조건은 운영이었습니다. 이 파이프라인은 개발자가 상주하지 않는 환경에서 매일 스스로 돌아야 했고 한 채널이 실패해도 나머지 수집은 계속되어야 했으며 무엇이 왜 실패했는지 로그에 남아야 했습니다.
접근
채널을 하나의 방식으로 억지로 통일하지 않았습니다. 대신 채널마다 가장 안정적인 수집 경로를 따로 고르고 그 뒤의 정규화와 적재는 공통 규격으로 모으는 구조를 택했습니다.
기능
채널 특성에 맞춘 세 갈래 수집 전략
API가 없는 포털은 브라우저 자동화로 사람처럼 로그인해 엑셀을 내려받고 REST API를 제공하는 채널은 토큰 로그인 뒤 리포트를 바로 호출하며 서명 인증을 요구하는 채널은 요청마다 HMAC 서명을 계산해 붙입니다. 채널의 성격에 맞는 방식을 고른 덕에 각 수집기가 단순해지고 깨질 지점이 줄었습니다.
가장 까다로운 벽은 로그인 단계의 문자 2차 인증이었습니다. 사람이 문자를 확인해 코드를 입력해야 한다면 무인 운영은 불가능합니다. 그래서 인증 문자를 받는 휴대폰의 단축어가 코드를 콜백 서버로 보내고 수집기는 그 코드를 클라우드 스토리지에서 잠깐 폴링해 자동으로 입력하는 우회로를 만들었습니다.
기능
사람 개입 없는 SMS 2차 인증 자동화
인증 문자가 도착하면 휴대폰 단축어가 본문에서 여섯 자리 코드를 뽑아 콜백 서비스로 전송하고 콜백 서비스는 이를 스토리지에 저장합니다. 로그인 중인 수집기는 해당 채널의 코드를 짧은 만료 시간 안에서 폴링해 자동 입력합니다. 사람이 문자를 보고 옮겨 적는 왕복이 사라졌습니다.
서명 인증 채널에서는 비동기 리포트 API를 다뤄야 했습니다. 요청을 넣으면 즉시 데이터가 오는 것이 아니라, 리포트 생성을 요청하고 완료될 때까지 상태를 폴링한 뒤 다운로드 링크로 파일을 받아 파싱하는 흐름입니다. 여러 종류의 리포트를 이 방식으로 순차 수집하고 헤더가 없는 원본 표를 컬럼 정의에 맞춰 JSON으로 변환했습니다.
기능
비동기 리포트 API의 생성·폴링·변환
리포트 생성을 요청해 작업 번호를 받고 완료 상태가 될 때까지 일정 간격으로 폴링한 뒤 다운로드 링크에서 원본 파일을 받아옵니다. 헤더 없는 표 형식 데이터는 리포트 종류별 컬럼 정의로 해석해 JSON으로 변환하고 숫자 값은 자동으로 형 변환해 바로 쓸 수 있는 형태로 만듭니다.
수집한 원본은 채널·날짜별로 나뉜 구조화된 경로에 그대로 적재했습니다. 광고 플랫폼이 백만분의 일 단위로 돌려주는 금액은 원 단위로 환산하는 등 채널별 표기 차이를 이 단계에서 흡수했습니다. 전 과정은 서버 없이 매일 새벽 스케줄로 실행되며 채널 하나의 실패가 전체를 멈추지 않도록 격리했습니다.
기능
서버 없는 매일 새벽 무인 배치
각 수집기는 관리 서버 없이 스케줄 기반으로 실행되는 클라우드 배치 작업으로 돌아갑니다. 채널별로 실행을 분리해 한 곳의 장애가 다른 채널로 번지지 않게 하고 지수 백오프 재시도와 요청 제한 대응을 넣었으며 로그에 남는 인증 키 같은 민감 문자열은 출력 직전에 자동으로 가립니다.
전체 구조는 다음과 같습니다.
글로 요약하면 이렇습니다. 채널은 브라우저 자동화, 일반 REST, 서명 API 세 갈래로 각각 가장 안정적인 방식으로 수집되고 로그인 문턱의 문자 인증은 콜백 서비스가 무인으로 넘깁니다. 수집된 원본은 단위 환산과 형식 변환을 거쳐 채널·날짜로 나뉜 데이터 레이크에 쌓이고 분석과 BI는 이 적재된 원본만 바라봅니다. 전 과정은 서버 없이 매일 새벽 스케줄로 실행됩니다.
결과
담당자가 채널마다 로그인해 엑셀을 내려받던 아침 루틴이 사라졌습니다. 인증과 형식이 서로 다른 채널들의 정산·광고 데이터가 매일 새벽 무인으로 모여 팀 누구나 같은 경로에서 최신 데이터를 볼 수 있게 됐습니다. 담당자 부재로 데이터가 비던 문제도 함께 사라졌습니다.
운영 관점의 변화도 큽니다. 한 채널이 실패해도 나머지 수집은 계속되고 어느 채널이 왜 멈췄는지 로그에 남습니다. 새 계정이나 채널을 붙일 때도 파이프라인 전체를 다시 짜지 않고 설정과 스케줄을 더하는 수준으로 확장됩니다.
이 프로젝트에서 내린 기술적 결정들은 아래 글에서 더 자세히 풀었습니다.
- 채널별 수집 전략 선택 기준: 브라우저 자동화·REST·서명 API를 언제 쓰나
- HMAC 서명 API 클라이언트 설계: 요청마다 서명을 붙이는 인증 다루기
- 비동기 리포트 API 수집 패턴: 생성·폴링·다운로드·변환의 정석
- SMS 2차 인증 무인 자동화: 콜백 서버와 스토리지 폴링으로 로그인 넘기기
- 서버 없는 스케줄 배치 운영: 클라우드 배치로 매일 도는 파이프라인
- 원본 데이터 레이크 적재 설계: 채널·날짜 파티션과 단위 정규화
자주 묻는 질문
채널마다 수집 방식이 다른데 왜 하나로 통일하지 않았나요?
채널의 성격이 서로 다르기 때문입니다. API가 없는 포털은 브라우저로 조작할 수밖에 없고 좋은 API가 있는 채널을 굳이 브라우저로 다루면 오히려 더 잘 깨집니다. 그래서 수집 방식은 채널에 맞춰 따로 고르고 그 뒤의 정규화와 적재만 공통 규격으로 모았습니다. 덕분에 각 수집기는 단순하고 유지보수 지점이 분산됩니다.
문자 2차 인증이 걸린 로그인을 어떻게 사람 없이 통과하나요?
인증 문자를 받는 휴대폰의 단축어가 문자 본문에서 코드를 뽑아 콜백 서비스로 보내고 로그인 중인 수집기는 그 코드를 스토리지에서 짧은 만료 시간 안에 폴링해 자동으로 입력합니다. 사람이 문자를 확인해 옮겨 적는 과정 자체를 파이프라인이 대신하는 구조입니다.
한 채널이 실패하면 그날 수집이 전부 멈추나요?
아니요. 채널별로 실행을 분리해 장애를 격리했습니다. 한 채널이 로그인 실패나 서버 오류로 멈춰도 나머지 채널의 수집은 계속 진행되고 실패한 채널과 원인은 로그에 남아 다음 날 이어서 대응할 수 있습니다. 일시적인 오류는 지수 백오프로 재시도해 스스로 회복을 시도합니다.