당신이 바깥에서 데이터를 받아 쓰는 일을 한다고 하자. 매일 공공데이터 API 로 거래·시설 목록을 모으는 수집기, GA4 로 어제 유입을 보는 아침 보고, 클라우드 DB 의 사용량 API 로 이번 달 요금을 어림하는 스크립트. 어느 날 GA4 최근 이틀 세션의 80% 가 (not set)·Unassigned 로 뭉쳐 보이고, 한 지역의 수집 건수가 오류 없이 0건이 되고, 같은 거래가 upsert 를 거쳤는데도 두 줄로 쌓이고, 사용량 API 가 0 을 돌려준다. 코드는 그대로다. 바뀐 것은 받은 데이터 쪽이다.
바깥 데이터는 왜 받은 뒤에도 바뀌나
바깥 원천이 준 값은 받은 순간이 완성이 아니다 — 어떤 칸은 나중에 채워지고, 어떤 칸은 원천이 규칙을 바꿔 다른 값이 되고, 어떤 숫자는 처리가 끝나야 익는다. 원천은 자기 사정(행정 절차, 집계 일정, 귀속 처리)에 따라 움직이고 당신에게 알리지 않는다. 그래서 받은 값을 처음 받은 모양 그대로 확정으로 다루면, 키는 중복을 만들고, 감시는 빈 결과를 놓치고, 보고는 덜 익은 숫자로 결론을 낸다.
바깥 데이터의 칸은 세 부류로 나뉜다.
- 처음부터 고정인 칸 — 계약일, 원천이 준 고유 번호, 이벤트가 일어난 시각
- 나중에 채워지는 칸 — 등기·승인·배송처럼 뒤 절차가 끝나야 생기는 값. 처음엔 빈칸이다
- 늦게 익는 집계 — 분석 도구의 채널 귀속, 사용량·청구 수치. 처음 본 값은 임시다
여기에 원천의 규칙 자체가 바뀌는 경우(지역 코드 개편, 상품 분류 개편)가 겹친다. 옛 코드로 물으면 오류가 아니라 빈 응답이 온다.
키·감시·판단을 어떻게 맞추나
1. 받는 칸마다 "언제 확정되나"를 적는다 (고정 / 나중에 채움 / 늦게 익음)
2. 멱등키(upsert 키)에는 고정 칸만 넣는다
- 나중에 채워지는 칸이 꼭 필요하면, 채워진 행이 오면 빈칸 행을 지우거나 갱신한다
- 취소·정정처럼 상태가 다른 행은 별개 기록으로 남긴다
3. 감시는 오류 수가 아니라 "단위별 건수의 급변"으로 한다
- 지역·카테고리별 일일 건수가 어제까지 있다가 0 이 되면 경보
4. 늦게 익는 숫자는 익는 기간이 지난 뒤에만 결론을 낸다
- 분석 도구의 최근 1~2일, 사용량 API 의 최근 며칠은 "임시"로 표시한다
- 청구액은 청구서가 정답이다
두 번째 줄의 근거는 단순하다. PostgreSQL 의 INSERT … ON CONFLICT 같은 upsert 는 키가 같을 때만 같은 행으로 본다. 빈칸이던 동 번호가 나중에 채워져 들어오면 키가 달라지고, 데이터베이스는 그것을 새 거래로 받는다.
쇼핑몰·블로그·사내 도구에서는 어떻게 보이나
- 주문 연동: 택배사 송장 번호를 주문 동기화 키에 넣으면, 송장이 붙는 순간 같은 주문이 두 줄이 된다. 키는 주문 번호만
- 블로그 유입 보고: 아침에 어제 유입을 보면 검색 유입이 비고 "출처 없음"이 크다. GA4 는 데이터 처리에 시간이 걸린다고 밝힌다. 이틀 뒤 같은 날짜를 다시 조회해 채널이 옮겨 갔는지 본 다음에만 태그를 의심한다
- 지역별 매장 목록: 지도·주소 API 가 행정구역 코드를 바꾸면 옛 코드로 묻는 매장 동기화가 조용히 0 개가 된다. "오류 0 건"은 정상이라는 뜻이 아니다
- 사내 비용 대시보드: 사용량 API 의 최근 값이 0 이거나 며칠 멈춰 있으면 요금 추정이 몇 배 틀린다. 기준점은 하루 뒤 콘솔에서, 확정액은 청구서에서
확인 목록
- 외부 데이터 표의 칸마다 확정 시점(고정·나중에 채움·늦게 익음)을 적어 두었나
- 멱등키에 나중에 채워지는 칸이 들어 있지 않나
- 같은 고정 키로 묶었을 때 두 줄 이상인 행을 세어 보았나
- 단위(지역·카테고리)별 건수가 0 으로 떨어지면 알리는 감시가 있나
- 보고서에서 익는 기간 안의 숫자를 "임시"로 표시하나
우리가 겪은 일
- upsert 가 중복을 쌓았다. 실거래 수집기의 멱등키에 등기 뒤에야 채워지는 동 번호가 들어 있었다. 같은 거래가 빈칸으로 한 번, 채워진 채로 한 번 들어와 두 줄이 됐다. 고정 칸으로 묶어 세어 보고 알았다.
- 한 지역이 오류 없이 0건이 됐다. 지역 코드로 묻는 공공 API 가 행정구역 개편 뒤 옛 코드에 빈 응답을 줬다. 오류 기록에는 아무것도 없었고, 지역별 건수를 보고 알았다.
- 최근 이틀 세션 80% 가 출처 없음이었다. 태그 고장을 의심했지만 이틀 뒤 같은 날짜를 다시 조회하자 검색 유입으로 옮겨 가 있었다. 다른 날·다른 속성에서도 두 번 더 같았다.
- 사용량 API 로 낸 요금 추정이 두 배 넘게 틀렸다. DB 사용량 수치가 며칠 갱신을 멈추거나 0 으로 나왔다. 콘솔의 청구서와 대조해서 알았다.