여러 판매·광고 채널의 데이터를 모으는 파이프라인을 짜다 보면 가장 먼저 부딪히는 질문이 있습니다. 채널이 다섯 개, 여섯 개가 되면 수집 방식도 하나로 통일하고 싶어집니다. 코드가 깔끔해 보이니까요. 그런데 실제로 여러 채널을 운영해 보면, 통일하려는 그 욕심이 오히려 더 자주 깨지는 파이프라인을 만듭니다. 채널마다 데이터에 닿는 가장 안정적인 길이 다르기 때문입니다.
채널은 세 부류로 나뉜다
수집 대상 채널을 놓고 보면 대체로 세 부류로 갈립니다. 첫째는 쓸 만한 API가 아예 없어서 사람이 포털에 로그인해 화면에서 데이터를 받아야만 하는 채널입니다. 둘째는 토큰 로그인 한 번이면 깔끔한 REST API로 리포트를 바로 내주는 채널입니다. 셋째는 API는 있지만 요청마다 서명을 계산해 붙여야 하고 데이터도 즉시 주지 않고 리포트를 만들어 두면 나중에 받아가라는 방식의 채널입니다.
이 세 부류는 난이도가 다른 게 아니라 성격이 다릅니다. 첫째 부류에 REST를 기대할 수 없고 둘째 부류를 굳이 브라우저로 다루면 멀쩡한 API를 두고 화면을 긁는 셈이라 오히려 더 잘 깨집니다. 그래서 우리는 채널을 한 방식으로 억지로 맞추는 대신, 부류별로 다른 수집 경로를 두고 그 뒤 단계만 공통으로 모으는 구조를 택했습니다.
API가 없으면 브라우저 자동화
API가 없는 포털은 결국 사람이 하던 조작을 그대로 흉내 내는 수밖에 없습니다. 로그인 페이지에 접속해 계정을 입력하고 필요하면 2차 인증을 넘기고 리포트 화면으로 이동해 다운로드 버튼을 눌러 엑셀을 받는 흐름입니다. 이 부류는 브라우저 자동화 도구로 처리하되, 봇 탐지를 피하기 위한 스텔스 설정과 화면 표시가 필요한 요소를 위한 가상 디스플레이를 함께 씁니다.
브라우저 자동화는 화면 구조 변화에 민감하다는 약점이 있습니다. 그래서 이 부류일수록 선택자를 최소한으로 쓰고 다운로드가 실제로 끝났는지를 파일 등장으로 확인하는 등 조작의 각 단계를 명확히 검증하도록 짰습니다. 화면을 긁는 방식은 우아하지 않지만 API가 없는 채널에서는 이것이 유일하게 데이터에 닿는 길입니다.
좋은 API가 있으면 그대로 쓴다
REST API를 제공하는 채널은 가장 다루기 쉽습니다. 토큰 로그인으로 인증을 받고 조회 기간과 묶음 기준을 담아 리포트를 호출하면 정돈된 JSON이 돌아옵니다. 이런 채널을 브라우저로 다루는 것은 명백한 낭비입니다. 화면은 언제든 개편되지만 API 규격은 상대적으로 안정적이고 응답도 이미 구조화되어 있어 파싱 부담이 적습니다.
다만 API 채널에도 채널 고유의 표기 습관이 있습니다. 어떤 광고 플랫폼은 금액을 백만분의 일 단위로 돌려주고 어떤 채널은 직접·간접 성과를 나눠 담습니다. 이런 차이는 수집 직후 정규화 단계에서 흡수해, 다운스트림이 채널마다 다른 단위와 구조를 신경 쓰지 않도록 했습니다.
서명 인증과 비동기 리포트
세 번째 부류가 가장 손이 많이 갑니다. 요청마다 시각과 메서드, 경로를 묶어 서명을 계산해 헤더에 붙여야 하고 데이터도 한 번에 주지 않습니다. 리포트 생성을 요청해 작업 번호를 받고 완료될 때까지 상태를 폴링한 뒤, 다운로드 링크에서 파일을 받아 파싱하는 여러 단계를 거칩니다. 이 부류는 서명 생성기와 폴링 루프를 하나의 클라이언트로 잘 감싸 두면, 리포트 종류가 늘어도 같은 흐름을 재사용할 수 있습니다.
세 부류를 한데 통일하지 않은 대신, 우리는 정규화와 적재라는 뒷단만 공통으로 모았습니다. 어떤 방식으로 받았든 수집이 끝난 데이터는 같은 규격으로 정리되어 채널·날짜별 경로에 쌓입니다. 이 파이프라인의 전체 구조는 멀티채널 광고·정산 데이터 수집 파이프라인 사례에서 볼 수 있습니다.
자주 묻는 질문
처음부터 모든 채널을 API로 통일하는 게 낫지 않나요?
통일하고 싶어도 API가 없는 채널이 있으면 불가능합니다. 그리고 억지로 통일하면 오히려 더 취약해집니다. 좋은 API가 있는 채널을 브라우저로 다루면 화면 개편마다 깨지고 API가 없는 채널에 REST를 기대하면 아예 동작하지 않습니다. 수집 방식은 채널에 맞추고 그 뒤 단계만 공통으로 모으는 편이 더 튼튼합니다.
브라우저 자동화는 너무 잘 깨지지 않나요?
깨지기 쉬운 것은 맞습니다. 그래서 이 방식은 정말 API가 없는 채널에만 씁니다. 선택자를 최소한으로 유지하고 로그인과 다운로드의 각 단계를 명확히 검증하며 실패는 해당 채널만 격리되도록 설계해 영향 범위를 줄입니다. 화면 구조가 바뀌면 그 채널의 수집기만 손보면 됩니다.
채널이 늘어나면 파이프라인을 다시 짜야 하나요?
아니요. 새 채널은 세 부류 중 하나에 대체로 들어맞으므로, 해당 부류의 수집 패턴을 재사용해 붙입니다. 정규화와 적재는 이미 공통 규격이라 그대로 흐르고 새 계정 추가는 설정과 스케줄을 더하는 수준으로 끝납니다.