플랫폼 13개, 상품 하나를 표현하는 방식도 13가지.

통화가 다릅니다. 무엇을 "옵션"으로 볼지도 다릅니다. 한 플랫폼에서는 사이즈가 고정 필드로 정해져 있는데, 다른 플랫폼에서는 그냥 자유 텍스트입니다. 카테고리 체계는 서로 다른 팀이 서로 다른 시장을 보고 몇 년 간격을 두고 따로 만든 겁니다. 어느 쪽도 잘못된 게 아닙니다. 서로 무관한 플랫폼 13개가 자연스럽게 이렇게 될 뿐입니다. 열세 곳에서 그대로 끌어온 원시 데이터는 아직 비교 가능한 상태가 아닙니다. 그냥 열세 무더기일 뿐입니다.

화려하지 않은 가운데 단계, 정규화가 나머지를 가능하게 만듭니다. 다국어 상품명, 옵션 구조, 통화, 카테고리 체계를 전부 하나의 공통 스키마로 접어 넣는 작업이죠. 누가 자랑하고 싶어 하는 부분은 아니지만, 이걸 건너뛰면 그 위에 쌓는 모든 것이 조금씩 다른 열세 개의 기반 위에 서게 됩니다.

이건 한 번 돌리고 끝내는 작업도 아닙니다. 가격·재고·리뷰·순위 같은 커머스 데이터는 계속 움직이는 표적이라, 파이프라인은 13개 플랫폼에 걸쳐 계속 돌아갑니다. 지난달 스냅샷은 지난달 이야기밖에 해주지 않으니까요.

여기서 얕보기 쉬운 부분이 있습니다. 열세 개 소스가 각자 알아서, 예고 없이 구조나 접근 규칙을 바꿀 수 있다는 점입니다. 그래서 정규화 로직은 한 번 짜고 마는 스크립트보다는, 계속 붙잡고 관리해야 하는 시스템에 더 가깝습니다.

그래서 실무에서는 파이프라인을 만드는 일만큼이나 스키마 드리프트를 감시하는 일이 중요해집니다. 필드 타입이 조용히 바뀌거나, 카테고리명이 변경되거나, 요청 제한이 어느 날 갑자기 강화되는 식입니다. 이런 변화는 눈치채지 못하면 시스템을 바로 멈추게 하지는 않습니다. 대신 하류의 데이터 품질을 조용히 갉아먹다가, 리포트나 가격 비교가 어딘가 미묘하게 이상해 보이는 순간에야 드러납니다. 이걸 일찍 잡으려면 파이프라인 상태를 한 번 배포하고 끝내는 체크리스트가 아니라 계속 지켜봐야 하는 대상으로 다뤄야 합니다.