새벽 3시, 파서를 고치는 사람
오케스트레이터에 빨간 태스크가 없습니다. 재시도 카운트도 깨끗하고, dbt run은 초록불로 끝났고, 데이터 품질 테스트도 다 통과했습니다. 그런데 아침에 출근한 현업이 묻습니다. "어제 평균가가 왜 이렇게 떨어졌어요?"
로그를 열어 봐도 예외가 없습니다. 파서가 죽지 않았거든요. 대상 사이트가 어느 영역을 예고 없이 리액트로 갈아엎었고, 어젯밤부터 그 필드가 빈 값으로 들어왔고, 적재 테이블은 빈 값을 정상값처럼 받았고, dbt 모델은 NULL을 조용히 걸러 집계했고, 대시보드는 축소된 표본 위에서 멀쩡한 그래프를 그렸습니다. 값만 틀렸을 뿐입니다. 그 질문에 답하려고 엔지니어는 새벽에 일어나 셀렉터를 맞춥니다.
DAG를 직접 짜고 dbt 모델을 관리하는 사람이라면 이 장면이 낯설지 않을 겁니다. 사내 소스라면 컬럼을 지우기 전에 예고가 오지만, 외부 웹 소스는 통지도 롤백 요청도 없습니다. 대상 사이트는 우리 파이프라인 사정을 봐주지 않습니다.
그래서 문제는 "안 깨지게 만드는 법"이 아닙니다. 외부 웹은 반드시 바뀝니다. 진짜 문제는 바뀔 때 하류가 조용히 오염되지 않게 막는 엔지니어링, 그리고 이 상시 유지보수를 누가 떠안느냐입니다.
값의 의미가 조용히 바뀌는 지점
외부 웹이 깨지는 방식은 크게 세 가지고, 각각 파이프라인에 다른 오염을 남깁니다. 원인 나열이 목적은 아니라 실무자에게 중요한 결과만 봅니다.
예고 없는 개편. 마케팅 리뉴얼이나 프레임워크 교체로 DOM 구조와 렌더링 방식(SSR→CSR)이 하루아침에 바뀝니다. 셀렉터 기반 파싱은 이 순간 예외 없이 빈 값을 집기 시작합니다.
조건별 화면. 같은 URL이 접속마다 다른 화면을 반환합니다. A/B 테스트, 지역, 로그인 여부에 따라 노출 항목이 달라집니다. 어느 조건에서 본 데이터인지를 함께 기록하지 않으면, 같은 필드인데 값의 의미가 조용히 달라집니다.
안티봇으로 인한 부분 결측. 차단·캡차·레이트리밋이 걸리면 데이터가 통째로 안 오는 게 아니라 일부만 빠집니다. 정상처럼 보이는 축소된 표본을 하류가 그대로 통과시킵니다.
세 경우 모두 파이프라인은 초록불입니다. 값의 의미가 조용히 바뀌고, 부분 결측이 정상처럼 통과해 잘못된 집계를 낳는다. 위험한 건 예외로 멈추는 파이프라인이 아니라, 아무 소리 없이 틀린 숫자가 흘러가는 경우입니다.
깨져도 하류가 안 무너지게 하는 완충층
한 사이트의 작은 개편이 조직 전체 문제가 되는 데는 두 가지 증폭 요인이 있습니다. 첫째는 조용한 실패입니다. 파싱이 예외를 던지고 멈추면 태스크가 빨갛게 떠 사람이 바로 보니 오히려 다행입니다. 진짜 위험한 건 파서가 빈 문자열이나 NULL을 정상값처럼 반환하는 경우로, 하류가 그대로 통과시키고 dbt 모델을 타고 NULL이 전파돼 최종 지표만 틀립니다. 둘째는 하류가 넓게 의존할 때입니다. 수집한 모든 필드를 하류가 그대로 참조하면, 사이트가 늘 먼저 바꾸는 부수 요소 하나에도 거기 물린 산출물이 전부 흔들립니다.
외부 웹의 불안정성은 없앨 수 없으니, 그것이 하류로 번지지 않게 사이에 완충층을 둡니다. 이 두 요인을 겨냥한 네 가지 장치가 그 층을 만듭니다.
수집 원본을 따로 보존한다. 파싱 결과와 별개로, 수집한 원본(HTML 스냅샷·원 응답·OCR 이전 이미지)을 그대로 남깁니다. 나중에 파싱이 틀린 것으로 밝혀져도 원본이 있으면 재수집 없이 재파싱만으로 과거 데이터를 복구할 수 있습니다. 원본을 버리면 파싱 버그가 곧 영구 데이터 손실입니다. 이 원본은 감사와 리니지 추적의 공통 기반이기도 합니다.
하류가 의존하는 필드를 핵심만 좁힌다. 하류가 실제로 쓰는 필드만 좁게 추려 타입·필수 여부·값 범위를 검증하고, 위반한 레코드는 하류로 흘리지 않습니다. dbt에서 뒤늦게 걸러내는 것과 달리 오염이 모델에 도달하기 전 수집 단계에서 막습니다. 사이트가 자주 바꾸는 부수 요소는 이 좁은 의존 집합에 넣지 않고 raw에만 남깁니다. 의존이 좁을수록 폭발 반경도 좁아집니다.
예외가 아니라 데이터의 모양을 감시한다. "파싱이 예외를 던졌는가"만 보면 조용한 실패를 놓칩니다. 그래서 결과물의 모양 자체를 감시합니다. 레코드 수가 평소 대비 급변했는지, 핵심 필드 결측률이 갑자기 올랐는지, 값 분포가 정상 범위를 벗어났는지(가격이 0이거나 비정상적으로 큼). 하나라도 걸리면 데이터팀 채널로 알립니다. 앞의 새벽 사례에서, 필드가 빈 값으로 들어온 순간 이 결측률 급등 알림이 현업의 질문보다 먼저 떴어야 했습니다. 사람이 개편을 눈치채기 전에 데이터 모양 변화로 먼저 잡는 것이 목적입니다.
스키마를 일방적으로 갈아 끼우지 않는다. 수집 스키마를 하루아침에 교체하면, 하류 입장에서는 외부 사이트 개편과 다를 게 없습니다. 그래서 변경을 사전에 통지하고 deprecation 기간을 두며, 그 기간 동안 구·신 버전을 병행 제공합니다. 하류는 예고된 창 안에서 자기 릴리스 주기에 맞춰 옮겨 타고, 스키마 변경이 곧바로 대시보드 구멍으로 직결되지 않습니다.
되메우기를 표준 절차로 만든다
깨진 구간을 발견하면 결국 되메워야 합니다. 재수집을 예외가 아니라 표준 절차로 설계해두면, 새벽 호출이 즉흥적인 수동 작업으로 번지지 않습니다.
멱등 재수집(backfill). 기간·조건을 지정해 구멍을 되메우되, 같은 키에 여러 번 적재해도 중복이 쌓이지 않도록 멱등 적재를 전제로 합니다. 워터마크·증분 커서로 되메운 구간만 정확히 채워, 전체 재수집 없이 필요한 창만 복구합니다.
완료 마커. 적재가 온전히 끝났음을 하류가 판단하도록 완료 마커(manifest/_SUCCESS)를 남깁니다. 마커가 없으면 오케스트레이션이 절반만 채워진 파티션 위로 변환을 돌립니다.
함께 실려 오는 메타. 되메운 데이터에는 해석과 검증에 필요한 메타를 같이 붙입니다. 수집 시각과 수집 조건(지역·로그인)은 값 의미를 해석하는 근거가 되고, 소스 URL·수집 주기는 카탈로그·리니지 등록에 쓰이며, 레코드 수·결측/이상 플래그는 자동 검증 게이트로 들어갑니다. 감사 때 "이 숫자 어디서 왔냐"는 질문에 이 메타가 답합니다.
깨졌을 때 무엇을 미리 정해둬야 하나
기술적 완충만으로는 부족합니다. 실무를 무너뜨리는 건, 깨졌을 때 누가 움직일지가 정해져 있지 않은 상황입니다. 결측 알림이 누구 폰을 울리는지, 파서 수리와 되메우기는 누가 하는지를 사고가 난 다음에 정하면 이미 늦습니다.
무엇을미리 정해둘 것감지데이터 모양 이상 신호를 누가 운영하고 어느 채널로 알리는가. 감지 주체는 데이터를 쓰는 소비자가 아니라 수집을 운영하는 쪽이어야 한다수정사이트 개편으로 파서가 깨졌을 때 셀렉터·파싱 규칙을 고치는 책임이 누구인가. 위탁했다면 위탁처재수집깨진 기간을 되메우는 표준 절차(멱등·워터마크·완료 마커)가 준비돼 있는가
핵심은 감지 주체입니다. 조용한 실패는 소비자가 대시보드에서 발견하면 이미 늦으니, 데이터 모양 변화를 수집 운영 쪽이 먼저 잡아야 하류가 오염되기 전에 차단됩니다. 그리고 이 세 가지를 누가 맡느냐가, 결국 새벽 3시에 누가 일어나느냐를 결정합니다.
이 상시 유지보수를 누가 떠안을 것인가
이 장치를 다 갖춰도, 매일 운영하는 부담은 사라지지 않습니다. 차단 대응, 사이트 변경 추적, 파서 수리, 데이터 모양 감시는 사이트가 살아 있는 한 계속됩니다. 이 부담을 DAG를 운영하는 엔지니어가 떠안고, 새벽 호출을 받는 것도 그 사람입니다.
해시스크래퍼는 이 상시 유지보수를 월정액 위탁으로 넘겨받습니다. 스키마는 처음에 데이터팀과 함께 정의하고, 변경은 사전 통지·버전 병행으로 넘기며, 재수집은 멱등 적재·워터마크 기반 표준 절차로 처리하고, 리니지·데이터 품질 메타와 완료 마커를 함께 전달합니다. 개발·유지보수·차단 대응·수집 감시가 월정액에 포함되고 정기(배치) 파이프라인 기준으로 설계하므로, 데이터팀은 외부 수집 유지보수에 갈려 나가지 않고 적재·모델링·활용에 집중할 수 있습니다.
규모 면에서도, 한 규제기관의 대규모 온라인 모니터링을 정기 파이프라인으로 위탁 운영하며 수집 감시부터 재수집·전달 규격까지 상시 다뤄 왔습니다.
외부 웹 수집·유지보수는 위탁해 잘 관리된 사내 소스처럼 다루고, 데이터팀은 그 위에서 모델을 짜는 것. 사이트가 계속 바뀌는 환경에서 새벽 호출을 줄이는 현실적인 경로입니다.
함께 보면 좋은 글
지금 바로 시작하기
지금 파이프라인에 물려 있는 외부 웹 소스가 개편 한 번에 대시보드를 비우지 않으려면, 완충층과 감지·재수집 절차를 어떻게 설계할지 함께 점검해 드립니다. 스키마 정의부터 변경 통지·되메우기·전달 메타까지 데이터팀 파이프라인에 맞춥니다.
