ODS 설계: 운영계와 DW 사이의 최신 데이터 완충층
ODS의 역할과 ER 모델, CDC·Upsert 적재 방식, DW 연계 구조를 운영 데이터 공급망 관점에서 정리합니다.
2026-08-14 · 최초 발행 2025-10-14
운영 데이터가 분석계에 닿기 전 필요한 완충층
ODS(Operational Data Store)는 운영계 트랜잭션 데이터의 현재값(current & near-current value)을 수집·통합·정제한 뒤, 분석계인 DW와 DM으로 보내기 전에 머무르게 하는 중간 저장소다. 운영계에서 직접 리포팅과 분석 처리를 수행할 때 생기는 부하를 분리하고, DW 적재 전에 데이터 표준화·전처리·키 해석을 수행하는 역할을 맡는다.
데이터 모델은 다차원 모델인 스타·스노플레이크보다 정규화된 ER 모델을 중심으로 구성한다. 전체 변경 이력을 보관하기보다 최신 상태를 유지하는 SCD Type 1 성격에 가깝다. 갱신은 이벤트 기반 또는 마이크로배치로 빈번하게 이뤄지며, 고정된 야간 배치 대신 유연한 트리거를 적용할 수 있다.
최신값을 유지하는 적재 방식
ODS는 Near real-time 또는 짧은 주기의 마이크로배치로 상태를 갱신한다. SLA에 따라 지연 예산을 5~15분으로 둘 수 있으며, 일부 속성만 바뀌는 상황에서도 현재값 기준의 정합성을 유지한다. 전체 이력 관리는 DW가 맡는다.
여러 운영계 소스를 하나로 모으려면 도메인 간 중복을 줄이고 참조 무결성을 지킬 수 있는 정규화 ER 모델이 필요하다. 비즈니스 키와 서로게이트 키를 매핑해 소스마다 다른 도메인 키를 표준화하는 것도 이 계층의 일이다.
변경 데이터는 로그 기반 또는 트리거 기반 CDC(Change Data Capture)로 수집한다. 이후 MERGE나 ON CONFLICT 같은 Upsert로 증분 반영하며, 중복과 이벤트 순서 불일치가 발생해도 허용 범위 안에서 멱등(idempotent) 처리할 수 있게 설계한다.
운영계 부하와 데이터 품질을 분리하는 구조
소스 시스템에는 최소한의 읽기 부하만 주고, 필요하면 리드 레플리카나 로그 테일링을 사용한다. Kafka 같은 큐·스트리밍 계층은 백프레셔를 흡수하며, ODS는 확장 가능한 수신단이 된다.
데이터가 ODS에 들어오기 전후로는 스키마 진화, 누락값, 참조 무결성, 도메인 값 검증을 확인한다. 라인리지와 메타데이터를 관리하고 수집 지연·실패율·보정 건수를 계속 관측해야 한다.
입력은 운영계 변경 로그·이벤트·배치 덤프다. 원본을 유지하는 스테이징을 거쳐 표준화와 정합성 검사를 수행하고 ODS에 Upsert한다. 품질 게이트를 통과한 데이터는 주기 또는 이벤트 기반으로 DW·DM에 적재된다.
수집에 실패한 데이터는 재시도·보정 큐로 격리한다. 스키마 불일치는 레지스트리의 Backward/Full 정책으로 차단하며, ODS 적재는 짧은 트랜잭션과 파티션·배치 크기 조절, 멱등 키를 통해 재처리 안전성을 확보한다.
ODS와 DW가 맡는 데이터의 시간대
| 구분 | 성능 | 확장성 | 일관성 | 안정성 | 운영 편의 |
|---|---|---|---|---|---|
| 운영계(OLTP) | 낮은 지연, 고TPS 쓰기 최적화 | 수직 확장 중심 | 강한 트랜잭션 일관성 | 애플리케이션 가용성 초점 | 변경에 민감 |
| ODS | 근실시간 읽기/쓰기, 증분 Upsert 최적 | 수평 확장 가능한 수집/저장 | 최신값 중심, 최종적 수렴(Eventual) 허용 | 실패 격리·재처리 설계 | 스키마 진화·멱등 처리 필요 |
| DW | 대용량 스캔·집계 최적화 | MPP/컬럼형 수평 확장 | 배치 단위 스냅샷 일관성 | 데이터 품질·재현성 초점 | 배치 운영 용이 |
ODS는 현재 데이터와 적시성에 무게를 둔다. 반면 DW는 이력, 집계, 재현성을 중심으로 안정된 스냅샷을 지향한다. ODS가 Volatile한 성격을 띠는 이유도 여기에 있다.
지연 요구에 맞춘 ODS 클래스 선택
Bill Inmon의 분류는 반영 지연과 운영 목적을 연결해 ODS의 형태를 나눈다.
- Class 1은 1~2시간 이내 반영이 필요하며, 운영 이벤트를 근실시간 의사결정에 활용하는 경우에 맞는다.
- Class 2는 약 4시간 지연을 두고 준실시간 운영 KPI와 모니터링에 사용한다.
- Class 3은 하룻밤, 즉 일 단위 지연을 허용하는 일상 운영 보고와 정산에 적합하다.
- Class 4는 분석가 검토 후 수동으로 반영하며, DW 결과와의 매칭·보정이 필요할 때 데이터 품질 통제를 강화한다.
- Class 5는 운영·분석 환경에서 온 집합적 데이터를 조합하는 복합 소스 통합 허브 역할을 한다.
선택 기준은 업무 SLA, 데이터 품질 요구, 인프라 비용, 운영 복잡도다.
최신 운영 상태가 필요한 업무
옴니채널 고객 현황판에서는 주문·배송·재고의 최신값을 통합해 콜센터와 물류 대시보드에 근실시간으로 제공할 수 있다. 금융 이상거래 대응에서는 카드 승인 로그를 CDC로 수집하고 ODS에서 집계한 뒤 룰 엔진 알림으로 연결한다.
가격·프로모션 운영은 ERP와 POS의 가격 최신값을 단일화하고, 사이트·앱 반영 레이턴시를 5~10분 수준으로 유지하는 방식으로 활용할 수 있다. IoT 환경에서는 센서 이벤트를 집계·정규화한 ODS가 운영 경보와 현장 조치의 연결점이 된다.
수집부터 권한 관리까지의 설계 선택
로그 기반 CDC는 Debezium 같은 도구를 활용해 소스 부하를 최소화하기 좋고, 리드 레플리카 분리에도 어울린다. 트리거 기반은 간편하지만 OLTP 영향이 커질 수 있으며, 로그 기반은 인프라 복잡도가 높아진다.
저장 모델은 SCD Type 1을 중심으로 두고 변경 추적은 DW에 맡길 수 있다. 비즈니스 키와 해시 체크섬을 이용해 변경을 검사한다. 다만 이력을 보존하지 않으므로 장기 추적이 어렵고, 필요하면 ODS-Change 테이블을 보조로 운영한다.
적재에서는 멱등 Upsert와 오프셋 커밋·디듀플을 통한 Exactly-once 유사 의미 보장이 필요하다. 마이크로배치는 1~5분으로 구성할 수 있다. 지연을 줄일수록 비용과 복잡도는 커지고, 재처리 윈도를 좁히면 오류 전파 위험도 높아진다.
일관성을 위해서는 짧은 트랜잭션, 파티션 키 기반 병렬화, 인덱스 최소화 후 주기적 최적화를 적용한다. 인덱스를 줄이면 쓰기에는 유리하지만 조회 성능은 낮아질 수 있다.
품질·관측성 영역에서는 스키마 레지스트리와 데이터 규칙 테스트를 둔다. 계수·널 비율·참조 무결성을 확인하고 메트릭과 SLA/SLO 알람을 운영한다. 강한 품질 게이트는 지연을 늘릴 수 있고, 약한 게이트는 DW로 오류를 전파할 수 있다.
권한과 보안은 최소 권한 원칙, PII 마스킹·토큰화, 전송·저장 암호화, 접근 로깅으로 구성한다. 규제 준수를 강화할수록 개발 속도와 운영 편의는 낮아질 수 있다.
PostgreSQL에서 멱등 Upsert 적용하기
전제는 PostgreSQL 13+, 트랜잭션 격리 Read Committed, 중복 방지를 위한 자연키 또는 고유 인덱스 존재다.
-- 고객 ODS 테이블
CREATE TABLE ods_customer (
customer_id TEXT PRIMARY KEY,
name TEXT,
email TEXT,
status TEXT,
updated_at TIMESTAMPTZ NOT NULL
);
-- 증분 데이터 머지(멱등)
INSERT INTO ods_customer AS t (customer_id, name, email, status, updated_at)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (customer_id) DO UPDATE
SET name = EXCLUDED.name,
email = EXCLUDED.email,
status = EXCLUDED.status,
updated_at = GREATEST(t.updated_at, EXCLUDED.updated_at)
WHERE EXCLUDED.updated_at >= t.updated_at; -- 이벤트 순서 뒤집힘 방지운영 시에는 배치 크기를 1k~10k 범위에서 조절하고, 장애가 나면 오프셋을 재처리한다. 지연을 측정하면서 느린 파티션을 분리한다.
ODS를 두었을 때의 변화
레포팅 쿼리를 ODS로 옮기는 기준에서 운영계 읽기 부하는 3070% 감소한다. 야간 배치에서 근실시간 방식으로 전환하면 데이터 지연은 7095% 단축되며, 멱등·디듀플을 적용하면 재처리 실패율은 50% 이상 감소한다.
최신 데이터를 바탕으로 즉시 의사결정할 수 있어 현업 만족도와 신뢰도를 높일 수 있다. 데이터 공급망이 표준화되면 변경 대응도 빨라지고, 소스 변경이나 일시 장애가 발생했을 때 운영 리스크를 격리하는 완충층으로 작동한다.