"경쟁사 데이터도 우리 대시보드에서 보고 싶다"가 데이터팀에 도착하면
사내 소스는 안정적입니다. 스키마를 우리가 통제하고, 변경은 릴리스 노트로 예고되며, 실패해도 재처리 절차가 있습니다. 그런데 경영진과 현업이 "경쟁사 가격, 리뷰, 시장 데이터도 같은 대시보드에서 보고 싶다"고 요구하는 순간, 통제권 밖의 소스를 파이프라인에 붙여야 하는 문제가 생깁니다.
외부 웹은 우리가 스키마를 소유하지 않습니다. 대상 사이트는 예고 없이 화면 구조를 바꾸고, 차단 정책은 수시로 강화됩니다. 어제 수집이 비면 오늘 대시보드에 구멍이 나고, 엑셀로 받은 데이터는 DAG에 붙일 수가 없습니다. 이 글은 외부 웹 수집을 어떻게 사내 DW·데이터레이크 파이프라인에 통합하는가 — 그 통합 방법을 다룹니다. 전제는 하나입니다. 수집 자체는 위탁하고, 데이터팀은 적재·모델링·활용에 집중하는 구조. 외부 웹을 "잘 관리되는 소스 시스템"처럼 다루려면, 그 소스가 데이터팀 언어로 계약을 맺어 줘야 하기 때문입니다.
1. 외부 웹 데이터는 사내 소스와 어디가 다른가
붙이기 전에 무엇이 다른지부터 알아야 통합 설계가 나옵니다. 사내 테이블은 컬럼 변경이 우리 릴리스 절차 안에 있지만, 외부 웹은 소스 사이트가 마음대로 바꿉니다. 어제 있던 필드가 오늘 사라지고, 같은 "가격"이 12,900원과 12900으로 섞여 들어옵니다. 갱신도 트랜잭션이 아니라 정해진 주기로 도는 정기 배치라, DAG 스케줄과 대시보드 신선도 SLA를 그 주기에 맞물려야 합니다.
가장 위험한 차이는 실패 모드입니다. 사내 잡은 실패하면 예외를 던지고 멈추지만, 외부 크롤러의 최악은 깨졌는데 성공한 척 빈 값을 쌓는 경우입니다. 사이트 구조가 바뀌어 셀렉터가 빗나가면 잡은 정상 종료되지만 레코드는 0건이거나 결측투성이입니다. 건수만 보는 검증으로는 안 잡히고, 지나간 웹 화면은 다시 수집되지 않으니 그 구멍은 영구적입니다. 그래서 외부 데이터 통합은 "적재만" 하면 끝이 아니라 적재 후 검증까지가 한 세트입니다.
2. 전달 형식별 통합 패턴 — 정답은 없고 규격에 맞춘다
외부 수집을 파이프라인에 붙이는 방법은 전달 형식에 따라 갈립니다. 크게 세 갈래이고, 어느 것이 옳다기보다 데이터팀 파이프라인 규격에 맞춰 고릅니다.
패턴DAG 트리거적합한 경우협의 포인트API 폴링스케줄+센서당겨올 타이밍을 데이터팀이 통제증분 커서·페이지네이션·인증DB·S3 직적재도착 센서대용량, 폴링 부하 회피완료 마커·테이블/프리픽스 규격파일 수신파일 센서저빈도, 엑셀→파이프라인 이행파일명·경로·시트 스키마
API 폴링형은 수집 데이터를 API로 제공받아 DAG가 마지막 워터마크 이후 증분만 조회해 랜딩 존에 적재합니다. 이미 받은 구간을 다시 받지 않도록 증분 커서를 데이터팀이 쥔다는 게 핵심입니다. DB·S3 직적재형은 수집 측이 DW·레이크에 직접 적재하고 DAG는 도착을 감지해 후속 처리만 합니다. 여기선 절반만 도착한 데이터를 물고 가지 않도록 완료 마커(manifest·_SUCCESS) 규약을 미리 합의해 둡니다. 파일 수신형은 표준 위치에 규격화된 파일로 떨어지면 파싱해 적재하는 방식으로, 엑셀 중심 운영을 파이프라인으로 넘기는 과도기에 맞습니다.
세 패턴 모두 우리(수집 측)와 데이터팀이 인터페이스 규격을 먼저 맞추는 것이 전제입니다. API 응답 형태·DB 테이블/S3 프리픽스·파일 규약을 데이터팀 파이프라인에 맞춰 협의하고, 어느 형식으로 낼지도 그 규격에서 거꾸로 정합니다. 전달 형식이 엑셀뿐 아니라 API·직적재·S3 드롭까지 열려 있어야 이 협의가 성립합니다.
3. 랜딩 존 — 외부 소스가 바뀌어도 하류가 안 깨지는 완충 장치
외부 데이터를 바로 모델링 레이어에 넣으면, 소스가 바뀌는 날 하류(dbt·대시보드)가 통째로 깨집니다. 완충 장치가 랜딩 존이고, 여기서 세 가지를 처리합니다.
첫째, raw 원본 보존입니다. 받은 그대로(API 응답 원문, 원본 파일)를 손대지 않고 한 벌 남깁니다. 파싱 로직이 틀렸거나 나중에 다른 필드가 필요해질 때 재수집 없이 원본에서 다시 파싱하기 위해서입니다. 지나간 웹 화면은 복구 불가라 이 원본 보존이 사실상의 안전망입니다.
둘째, 스키마 버저닝입니다. 저희가 데이터팀과 일하는 표준은 이렇습니다. 스키마 변경은 사전 통지(deprecation 기간)를 두고, 그 기간 동안 구/신 버전을 병행 제공해 하류가 자기 속도로 넘어오게 합니다. 예컨대 price_daily.v1을 계속 내보내면서 currency 컬럼이 추가된 v2를 같이 내보내고, 하류 dbt는 준비되면 참조를 옮긴 뒤 deprecation 종료 후 v1을 내립니다. 이렇게 하면 "소스가 어제 개편됐는데 오늘 대시보드가 죽었다"가 "다음 분기까지 병행, 그 안에 전환"으로 바뀝니다. 변경 책임과 완충 기간이 계약에 있으니 데이터팀이 불시에 소방수로 불려 가지 않습니다.
셋째, backfill을 표준 절차로 다룹니다. 수집이 며칠 비었거나 새 필드를 과거 구간에도 채워야 할 때, 저희가 기간·조건을 지정해 재수집하고 랜딩 존에 재적재하면 DAG가 그 구간만 다시 모델링합니다. 같은 구간을 다시 넣어도 중복이 쌓이지 않도록 파티션 교체·업서트 키로 멱등하게 설계하는 게 전제입니다. 재수집 창구가 저희 쪽에 있어, 데이터팀은 "어느 기간을 다시"만 지정하면 됩니다.
4. 적재 후 검증 — 조용한 결측을 DAG 안에서 잡기
1절의 "조용한 결측"은 적재 후 검증으로만 잡힙니다. publish 앞에 DQ 게이트를 두고, 통과하지 못하면 하류로 승격하지 않게 합니다. 깨진 데이터가 대시보드까지 흘러가는 대신 랜딩 존에서 멈추고 알림이 뜹니다. 게이트가 보는 것은 대체로 넷입니다. 레코드 수가 기대치 하한 밑으로 급감하지 않았는지(조용한 결측), 필수 필드 결측률이 임계치 이하인지(부분 수집), 파싱 이상 플래그가 없는지(구조 개편), 수집 시각이 freshness SLA 안인지(신선도).
데이터팀이 DQ 룰을 처음부터 짜지 않아도 되게, 저희는 데이터와 함께 검증용 메타를 같이 전달합니다. 수집 시각(freshness), 수집 조건(어떤 검색어·카테고리·범위), 소스 URL(리니지·감사), 레코드 수(기대 대비 급감), 결측/이상 플래그 정도입니다. 감시는 크롤러 한 곳이 아니라 소스(수집)와 파이프라인(적재) 양쪽에 둡니다. 수집 이상·지연이 감지되면 저희가 데이터팀 채널(슬랙·웹훅)로 알리고 복구 예상 시간을 함께 공유해, "왜 비었고 언제 채워지는가"에 답할 수 있는 상태를 만듭니다.
5. 카탈로그·리니지 — "이 숫자 어디서 왔냐"에 답하기
외부 데이터가 대시보드에 오르면 언젠가 감사나 경영 회의에서 "이 경쟁사 가격, 출처가 어디냐"는 질문이 옵니다. 답하려면 카탈로그와 리니지에 출처·주기 메타가 등록돼 있어야 합니다. 저희는 이 등록에 바로 쓸 수 있도록, 소스 도메인/URL, 수집 주기, 수집 조건(대상 범위), 현재 스키마 버전, 그리고 이 소스가 위탁 운영 소스임을 함께 냅니다. 검증용 메타와 겹치되 카탈로그 관점 항목이 더해진 형태입니다.
이 메타를 데이터셋 등록 시 채워 두면, 리니지 그래프에서 대시보드 지표를 소스 URL까지 거꾸로 추적할 수 있습니다. "이 숫자 어디서 왔냐"에 클릭 몇 번으로 답이 나오는 상태 — 그게 외부 데이터를 사내 소스와 동급으로 거버넌스에 편입한 상태입니다. 스키마·backfill·메타를 데이터팀과 맞추는 이유가 여기서 모입니다. 외부 소스를 카탈로그에 정식 등록 가능한 형태로 넘겨야, 그게 "관리되는 소스 시스템"이 됩니다.
마지막은 신선도입니다. 외부 수집은 정해진 주기로 도는 정기 배치라, 대시보드 SLA도 그 배치 주기에 맞춰 잡아야 합니다. 배치가 하루 한 번이면 대시보드도 "하루 단위로 갱신되는 지표"로 설계하고, 문구도 "○시 기준"처럼 배치 수집 시각을 명시하는 편이 운영과 어긋나지 않습니다. 신선도는 "얼마나 최신인가"가 아니라 "어느 배치 시점 기준인가"로 소통하는 게 데이터팀과 현업 모두에게 안전합니다.
이 통합이 데이터팀에게 남기는 것
외부 웹 수집을 파이프라인에 통합하는 일의 요점은, 통제 불가능한 소스를 통제 가능한 인터페이스 뒤에 두는 것입니다. 스키마는 버전 계약으로, 실패는 DQ 게이트로, 출처는 카탈로그 메타로, 재처리는 backfill 표준 절차로 감싸면 외부 데이터도 사내 소스처럼 다룰 수 있습니다.
그 인터페이스 뒤편의 상시 운영 — 차단 대응, 사이트 개편 추적, 수집 감시, 수리 — 을 누가 지느냐가 마지막 결정입니다. 이걸 데이터팀이 안으면 DAG 운영 인력이 외부수집 유지보수에 갈려 나갑니다. 저희는 개발·유지보수·차단 대응·수집 감시를 월정액에 포함해 위탁받고, 데이터팀에는 스키마 계약·검증 메타·카탈로그 메타가 갖춰진 소스로 넘깁니다. 수집→정제→AI 분석까지 거쳐 raw가 아니라 적재 가능한 정형으로 전달하니 랜딩 존 정리 부담도 줄어듭니다.
결론은 하나입니다. 외부 웹 수집·유지보수는 위탁해 잘 관리된 소스 시스템처럼 다루고, 데이터팀은 적재·모델링·활용에 집중하는 것. 실제로 한 규제기관의 대규모 온라인 모니터링을 정기 파이프라인으로 위탁 운영하고 있고, 대규모·다부서 수요도 이 방식으로 한 창구에 묶입니다.
함께 보면 좋은 글
지금 바로 시작하기
지금 파이프라인이 어떤 규격인지 — Airflow 오케스트레이션인지, S3 데이터레이크인지, DW 직적재인지 — 알려주시면, 외부 웹 수집을 그 규격에 맞춰 어떻게 붙일지 인터페이스부터 함께 설계해 드립니다. 스키마 계약·검증 메타·카탈로그 메타까지 데이터팀 언어로 맞춥니다.
