ETL보다 중요한 것은 데이터 표준화: 올라핀테크 데이터 파이프라인 구축기 (1편)
2026.08.05
사이트마다 다른 데이터를, 하나의 신뢰할 수 있는 기준으로." 올라핀테크 데이터엔지니어링팀의 표준화 기록입니다.
Bronze+ 레이어 구축, Glue ETL 4단계 구조화, 실무 예외 처리 사례를 통해 탄탄한 데이터 거버넌스와 기반을 만들어가는 여정을 공유합니다.
들어가며
올라선정산은 여러 이커머스 플랫폼에 입점한 셀러에게 선정산 서비스를 제공합니다.
서비스가 성장하면서 데이터의 양과 종류도 함께 늘었고, 단순히 수집하고 저장하는 것만으로는 서비스를 고도화하기 어려운 시점이 찾아왔습니다.
데이터엔지니어링팀이 파이프라인을 구축하는 목표는 ETL(*) 자체가 아니라 리스크 관리를 위한 내·외부 데이터 통합, 운영 대시보드, 머신러닝 기반 판매자 평가 모델, 그리고 향후 AI 활용(AX)을 위한 데이터 기반을 만드는 것입니다.
하지만 플랫폼마다 데이터 구조와 표현 방식이 달라, 새 데이터를 추가하거나 분석하려면 같은 변환 작업을 반복해야 했습니다.
가장 먼저 해결해야 할 문제는 ETL 성능이나 저장소가 아니라 데이터 표준화였습니다.
*ETL: ETL은 추출(Extract), 변환(Transform), 적재(Load)의 약자로, 다양한 곳에 흩어진 데이터를 모아서 분석하기 좋은 상태로 바꾸어 안전하게 저장하는 기술 과정을 칭하는 약어.
사이트가 늘어날수록 커지는 과제
각 사이트는 같은 의미의 데이터를 전혀 다른 형태로 제공합니다.
- 컬럼명: 한글 헤더("상품주문번호") vs 영문 스네이크케이스(
product_order_number) - 날짜: ISO 8601,
/구분자,YYYY.MM.DD HH:MM:SS, Unix Timestamp 혼재 - 숫자·타입: 같은 컬럼에 정액
"1,000원"과 정률"5.5%"가 함께 저장
▲같은 데이터, 세 가지 모습 — 표준 스키마로 수렴하는 비교도
이를 사이트별 ETL에서 각각 처리하면 사이트가 하나 추가될 때마다 같은 버그를 반복하게 됩니다.
그래서 "수집 직후 가장 먼저 하는 일은 표준화"라는 결론을 내렸습니다.
레이어를 나누기까지
레이어는 처음부터 Bronze-Silver-Gold 3단계로 계획했습니다.
Bronze는 원본 보존이 목적이라 전처리를 의도적으로 제외했는데, 그 상태로는 분석에 쓸 수 없었던 것입니다.
그래서 표준화를 담당하는 Bronze+ 레이어를 추가했습니다.
▲레이어 아키텍처 — Raw → Bronze → Bronze+ → Silver/Gold
- Bronze: 컬럼명만 표준 스키마로 매핑하고 모든 값을 문자열 그대로 보존합니다. 변환은 언제든 다시 할 수 있지만, 변환에 실패해 원본을 잃으면 복구할 수 없기 때문입니다.
- Bronze+: 문자열→타입 변환, 날짜 정규화, NULL 통일, PK 기준 중복 제거, 컬럼 표기 통일을 수행합니다.
- Silver / Gold: 분석·모델링용 통합 데이터와 서비스·대시보드용 데이터로, 다음 단계로 구축할 예정입니다.
Glue ETL, 네 단계로 정리하다
사이트별 스크립트가 늘면서 처리 방식이 조금씩 어긋났고, 공통 로직을 유틸로 뽑아내며 네 단계로 정리됐습니다.
▲ETL 4단계 — Extract → Normalize → Validate → Load
Normalize
사이트별 스크립트에는 {원본 컬럼명: 표준 컬럼명} 매핑 테이블만 정의하고, 실제 변환은 공통 함수가 수행합니다.
컬럼명 매핑은 Bronze 잡이, 타입·날짜 변환은 Bronze+ 잡이 나눠 맡습니다.
새 사이트가 추가되어도 매핑 테이블만 작성하면 됩니다.
Validate
표준화에서 가장 중요한 단계입니다.
스키마 드리프트(매핑 안 된 신규 컬럼), PK 중복, 필수 컬럼 NULL, 타입 변환 실패, Bronze/Bronze+ 건수 비교를 검증합니다.
처음엔 모르는 컬럼을 무시하려 했지만, 그러면 사이트가 스키마를 바꿔도 아무도 모른 채 데이터가 유실됩니다.
그래서 미매핑 컬럼이 발견되면 ETL을 실패시키는 방식으로 바꿨습니다.
Extract는 S3 경로 규칙과 다운로드를 공통 유틸로 통일했고, Load는 배치 단위로 Iceberg 테이블에 Append/Merge합니다.
표준화하면서 부딪힌 문제들
규칙을 만드는 것보다 어려웠던 것은 운영에서 만나는 예외였습니다.
날짜 포맷
ISO 8601만 처리하면 될 줄 알았지만 새 포맷이 계속 등장했습니다.
가장 위험했던 건 Unix Timestamp 1744032200을 날짜 파서가 앞 8자리만 잘라 1744-03-22라는 18세기 날짜로 만든 사례였습니다.
정액/정률 혼재
같은 컬럼에 "1,000원"과 "5.5%"가 섞여 들어왔습니다.
둘 다 숫자라 티가 나지 않아, 다운스트림 계산이 이상해진 뒤에야 발견하고 컬럼을 분리했습니다.
MERGE Timeout
MERGE 조건에 파티션 필터가 없어 전체 데이터를 스캔하고 있었습니다.
dt 조건 한 줄로 해결됐지만, 작은 조건 하나가 성능을 좌우한다는 걸 배웠습니다.
이 밖에도 하이픈이 든 DB명이 Iceberg 카탈로그를 깨뜨린 문제, S3 스트리밍 연결 끊김, 배치 크기로 인한 Driver OOM을 하나씩 넘었습니다.
마치며
이번 프로젝트에서 가장 크게 느낀 점은, 데이터 파이프라인의 시작은 ETL이 아니라 표준화라는 것입니다.
ETL은 데이터를 옮기는 기술이지만, 표준화는 데이터를 누구나 같은 의미로 사용할 수 있게 만드는 작업입니다.
표준화가 되어 있어야 대시보드와 분석은 물론 머신러닝 모델과 AI 서비스까지 같은 기준의 데이터를 쓸 수 있습니다.
이런 데이터 품질과 거버넌스는 최근 데이터 플랫폼 구축에서 더욱 중요하게 다뤄지고 있습니다.
앞으로 Silver 레이어와 데이터 마트를 구축하고, 매핑 누락과 스키마 변경을 사전에 감지하는 자동 검증 체계, 신규 사이트 연동 체크리스트를 만들어갈 계획입니다.
완벽한 표준화는 없습니다.
하지만 데이터는 계속 늘어나고 서비스는 계속 변화합니다.
"데이터엔지니어링팀은 누구나 신뢰하고 활용할 수 있는 데이터 기반을 위해 표준화를 지속적으로 개선해 나가겠습니다."
write. 데이터엔지니어링팀 안지승, 서인덕, 정승주