데이터 엔지니어링은 다양한 요구사항에 맞춰 데이터 파이프라인을 설계합니다. 각 회사가 자주 사용하는 방식은 자사 소스의 특성과 운영 환경에 최적화되어 있으며, 이를 추상화해 다른 요구사항에도 재사용하곤 합니다.
문제는 새로운 소스가 들어올 때입니다. 매번 PoC를 진행하고, 거기에 맞춘 정책을 새로 만드는 방식은 시간이 오래 걸리고 운영 복잡도를 키웁니다. 대신 소스 특성에 맞춘 기본 패턴을 표준화해 두면, 초기 설계 속도를 높이고 품질과 비용을 예측 가능하게 만들 수 있습니다.
데이터 소스는 형태, 신뢰도, 지연 허용치가 제각각입니다. 모든 소스에 하나의 수집 방식만 적용하면 비용 과다, 누락/중복, 삭제 미처리 같은 문제가 발생하기 쉽습니다. 따라서 소스별 특성을 표준화해 분류하고, 이에 맞춘 선택 가이드와 운영 체크리스트를 제공하는 것이 합리적입니다.
이번 글에서는 제가 데이터 엔지니어로 다양한 소스를 다루어 온 경험을 바탕으로, 데이터 소스에 대한 패턴을 정리해서 공유하려고 합니다. 이를 통해 새 소스가 들어왔을 때 "어떤 패턴을 고를지"부터 빠르게 결정하고, 비용/품질/리스크를 미리 가늠하는 것을 목표로 합니다.
패턴 카탈로그
A. 전체 스냅샷 (Full Snapshot)
•
개념
◦
매 수집 주기마다, 소스 시스템이 가진 해당 데이터셋의 '전체 활성 목록' (예: 특정 테이블의 모든 레코드, 특정 API 엔드포인트의 전체 페이지네이션 결과)을 가져오는 방식
◦
'어제' 적재된 전체 목록과 '오늘' 가져온 전체 목록을 비교하여 신규, 변경, 삭제 건을 정확히 식별하여 데이터 저장소(Data Lake/DW)에 반영
•
언제 쓰나
◦
누락이나 삭제를 반드시 감지해야 할 때 (데이터 정합성이 중요할 때)
◦
소스 시스템의 전체 데이터량이 감당 가능한 크기일 때 (예: 수백만 건 이하)
•
운영 포인트
◦
[신규/변경 감지] '오늘' 스냅샷의 모든 항목을 고유 키(Identity Key)로 '어제'의 데이터와 비교
◦
[신규 INSERT] '어제'에는 없던 고유 키가 '오늘' 목록에 있으면 신규로 처리
◦
[변경 UPDATE] 고유 키는 동일하지만 '오늘'의 콘텐츠 해시가 '어제'와 다르면 '변경'으로 처리합니다. (각 소스 특징에 맞게 콘텐츠 해시 구성 후 해시 비교를 통해 변경된 값 추적)
◦
[삭제 Soft Delete] '어제' 목록에는 있었으나 '오늘' 목록에 없는 고유 키는 '삭제'로 간주, is_active=false 또는 deleted_at 타임스탬프를 기록
•
예
◦
파트너사 “전체 상품 카탈로그” 일일 동기화
•
참고
◦
전량이 수십 GB인데 매일 풀다운하는 방식은 API 한도와 비용을 폭증
◦
전량 수집은 병렬로 처리하고, 소스가 증분(최근 N일만) 옵션을 제공한다면 혼합 적용하는 것이 좋음
B. 주요 목록 스냅샷 (List Snapshot)
•
개념
◦
'오늘의 인기 상품 100'처럼, 소스 시스템의 전체 데이터가 아닌 '특정 시점의 목록' 자체를 수집하는 방식
◦
소스가 랭킹, 추천, 트렌드 등의 이유로 선별한 Top-N 리스트가 수집 대상이며, 목록에 포함되지 않은 나머지 데이터(롱테일)는 의도적으로 버림
•
언제 쓰나
◦
데이터의 전체 정합성('전체 스냅샷'의 목적)이 아닌, *'현재 시점의 트렌드'*나 '추천 보드'를 추적하는 것이 목적일 때
◦
순위 변동, 목록 진입/이탈 현황을 시계열로 저장하고 싶을 때
•
운영 포인트
◦
[시점성 저장] 수집한 목록(예: 100개)에 snapshot_date (수집 일자/파티션)와 rank (순위) 정보를 태깅하여 저장
◦
[상태 해석] 목록에서 제외된 항목은 '삭제'가 아니라 '순위 이탈' 또는 '추천 종료'로 해석합니다. 이는 '전체 스냅샷' 패턴과의 가장 큰 차이점 (즉, is_active=false 같은 처리를 하지 않음)
◦
[플래그 활용] '오늘' 수집된 목록에 is_recent_highlight=true 같은 플래그를 부여하여, 다운스트림(서비스 API 등)에서 최신 목록을 쉽게 필터링할 수 있게 함 / 또는 수집 주기에 맞게 파티션을 두어서 최근 파티션만 접근하게 함
•
예
◦
커머스 - 카테고리별 베스트 100
◦
뉴스 - 많이 본 기사 20
•
참고
◦
상위 100 목록만 필요함에도 모든 상품의 상세 정보까지 매번 크롤링하면 과도한 비용이 발생
◦
상위 100의 ID 리스트만 저장하고, 필요 시 세부 정보는 조인(Join) 또는 지연 수집(Lazy Ingestion)하는 것이 효율적
C. 증분 수집 (Incremental / Updated-Since)
•
개념
◦
매번 전체 데이터를 가져오지 않고 소스 API가 제공하는 파라미터(예: updated_since, since_id, pageToken)를 활용하여, 마지막 수집 시점 이후 '추가'되거나 '변경'된 데이터만 효율적으로 수집하는 방식
•
언제 쓰나
◦
API가 updated_since나 since_id 같은 증분 수집용 파라미터를 명확히 제공할 때
◦
'전체 스냅샷' 방식의 비용(시간, API 호출 수, 네트워크)이 부담스러울 때
◦
실시간은 아니더라도, 비교적 짧은 지연 시간(Low Latency)으로 데이터를 동기화하고 싶을 때
•
운영 포인트
◦
[상태 저장 및 멱등성] 마지막으로 성공한 수집 시점(last_timestamp) 또는 마지막 레코드 ID(last_id)를 반드시 저장해야 함. 다음 수집 시 이 값을 파라미터로 사용하여, 작업이 실패 후 재시도될 때도 동일한 결과를 보장(멱등성)
◦
[누락 방지: Safety Window (필수)] updated_at 기반 수집 시, 서버 간 시계 불일치나 트랜잭션 지연으로 경계 값의 데이터를 누락할 수 있음. 이를 방지하기 위해 updated_at >= last_ts - 2분처럼 '안전 여유 시간(Safety Window)'을 두고 의도적으로 겹치게 수집하는 것이 안전
◦
[중복 제거] 'Safety Window'로 인해 필연적으로 중복 데이터가 수집. 따라서 저장소(DW)에 적재할 때 고유 키(Identity Key) 기준으로 중복을 제거하는 로직(예: MERGE, UPSERT)이 반드시 포함되어야 함
◦
[삭제 감지 한계] 이 패턴은 '추가'와 '변경'은 잘 감지하지만, 소스에서 **'삭제(Delete)'**된 데이터는 API가 명시적인 삭제 이벤트(예: status: "deleted")를 주지 않는 한 감지할 수 없음
•
예
◦
GET /api/orders?updated_since=2025-11-09T11:00:00Z (신규 주문/티켓 수집)
◦
GET /api/issues?page_token=... (이슈 트래커, 게시판 등 목록형 데이터 수집)
•
참고
◦
서버 시계나 타임존 차이로 updated_at 경계 값에서 데이터가 누락될 수 있음
◦
updated_at >= last_ts - safety_window(예: 2분) 처럼 시간을 겹치게 수집하고, 고유키로 중복을 제거하는 것이 안전
◦
이 패턴의 가장 큰 약점은 '삭제'를 감지하기 어렵다는 것
D. 고정 목록 점검 (Whitelist)
•
개념
◦
'전체'나 '증분'이 아닌, 우리가 미리 정의한 고정된 URL/ID 목록(Whitelist)을 대상으로 주기적으로 '변경' 여부만 점검하는 방식
•
언제 쓰나
◦
수집 대상의 숫자는 적지만 비즈니스 중요도가 높을 때
◦
'신규' 데이터를 발견하는 것이 아니라, '기존' 자산의 상태 변경을 모니터링하는 것이 목적일 때
◦
데이터 변경 빈도가 매우 낮은 자산(예: 하루 1~2회 변경)을 효율적으로 수집할 때
•
운영 포인트
◦
[목록 관리] 점검할 대상 목록(Whitelist)을 DB나 설정 파일(JSON, YAML 등)을 통해 별도 관리. 이 파이프라인은 이 목록을 '입력'으로 받음
◦
[순회 점검] 목록을 순회하며(예: for id in whitelist:) 각 항목의 최신 데이터를 소스(API, DB, 웹페이지)로부터 개별 조회
◦
[변경 감지] 가져온 '최신 데이터'와 우리 저장소(DB/Lake)에 저장된 '이전 데이터'를 비교하여 변경 여부를 판단
◦
[갱신] 변경이 감지된 항목만 저장소에 갱신(UPDATE 또는 새 버전 INSERT)
•
예
◦
[API] 관리 DB에 저장된 VIP 고객 ID 100명의 목록을 기반으로, API를 개별 호출(GET /users/{id})하여 최신 포인트 정보를 갱신
◦
[DB] 설정 파일에 정의된 주요 상품 코드 50개에 대해서만 운영 DB를 조회(WHERE product_id IN (...))하여 재고 상태를 DW로 동기화
◦
[웹 크롤링] 10개의 경쟁사 공지사항 URL 목록을 기반으로 해당 페이지만 순회하며, 페이지 내용의 해시(Hash) 값이 변경되었는지 점검
•
참고
◦
목록(Whitelist)의 크기가 수천 개 이상으로 커지면, 개별 순회 점검 (for id in whitelist:) 방식은 소스 시스템에 N+1 쿼리 부하를 주거나 API 속도 제한(Rate Limit)에 쉽게 도달할 수 있음
◦
이 경우, 소스가 GET /api/items?ids=1,2,3...과 같은 배치(Batch) 조회를 지원하는지 반드시 확인하고, 지원한다면 개별 조회가 아닌 배치 조회로 전환 필요
◦
이 파이프라인은 Whitelist가 '최신'이고 '정확'하다고 가정
◦
이 Whitelist 자체를 관리하고 갱신하는 별도의 프로세스 (예: 매일 1회 '전체 VIP 목록'을 가져와 Whitelist DB를 덮어쓰는 동기화 작업)가 반드시 병행되어야 함
E. 이벤트 기반 (Event-Driven / Feed)
•
개념
◦
앞선 패턴들이 우리가 소스에 데이터를 요청(Pull)하는 방식이었다면, 이 패턴은 반대로 소스 시스템이 변경 사항을 우리에게 능동적으로 밀어주는(Push) 방식
◦
Webhook 수신 엔드포인트(API)를 제공하거나, RSS/Pub/Sub 토픽을 구독함으로써 이벤트를 즉시(또는 버퍼링 후) 처리
•
언제 쓰나
◦
실시간성(Real-time)이 비즈니스의 핵심 요구사항일 때 (예: 결제 즉시 처리)
◦
소스 시스템이 Webhook, 이벤트 스트림, RSS Feed 등 Push 방식을 명시적으로 제공할 때
•
운영 포인트
◦
[수신 고가용성] 이벤트 수신 엔드포인트는 24/7 고가용성을 보장해야 함. 수신 서버가 일시적으로 다운되면 소스가 재시도해주지 않는 한 이벤트를 영구적으로 유실할 수 있음
◦
[중복 처리 (멱등성)] Push 시스템은 네트워크 안정성을 위해 "최소 1회 전달(At-least-once)"을 보장하는 경우가 많음. (즉, 중복 발생 가능) event_id나 idempotency_key 같은 고유 키를 검사하여, 동일 이벤트가 중복 처리되지 않도록 멱등성을 반드시 보장해야 함
◦
[일시적 장애 (재시도/DLQ)] 이벤트를 수신했으나 내부 로직(예: DB 저장)에서 일시적 오류가 발생할 수 있음. 이는 지수 백오프(Exponential Backoff) 기반의 재시도로 처리하고, 계속 실패하는 이벤트는 DLQ(Dead-Letter Queue)로 보내 나중에 분석하거나 수동 재처리해야 함
◦
[영구적 누락 (교정)] 소스 시스템의 버그나 네트워크 장애로 이벤트 자체가 아예 미수신될 수 있음. Push 방식의 신뢰도를 100% 믿을 수 없으므로, 주기적인 '전체 스냅샷' 또는 '하이브리드 교정'을 통한 백필(Backfill) 작업을 병행하여 누락된 데이터를 보정해야 함
•
예
◦
결제 완료 Webhook: PG사(Stripe, I'mport 등)가 결제 성공/실패 이벤트를 즉시 전송
◦
GitHub 이벤트: git push 발생 시 CI/CD 파이프라인을 트리거하는 Webhook
◦
RSS 새 글: 블로그나 뉴스 사이트의 RSS Feed를 구독하여 새 글 즉시 수집
•
참고
◦
'속도(Latency)'를 얻는 대신 '신뢰성(Reliability)'을 보장하기 위한 복잡성을 감수해야 함
◦
단순히 수신 엔드포인트 하나만 만드는 것이 아니라, 유실과 중복을 방지하기 위한 견고한 시스템(멱등 키 검사, 재시도, DLQ, 주기적 교정)을 모두 구축해야만 안정적으로 운영할 수 있음
F. 변경 데이터 캡처 (CDC)
•
개념
◦
'증분 수집(C)'처럼 API나 쿼리를 폴링(Pull)하는 방식이 아닙니다. 데이터베이스가 내부적으로 기록하는 트랜잭션 로그(Transaction Log) (예: MySQL의 binlog, MongoDB의 oplog)를 직접 구독(Subscribe)하는 방식
◦
소스 DB에서 발생하는 INSERT, UPDATE는 물론, 다른 패턴으로는 감지가 불가능한 DELETE 이벤트까지 포함된 변경 이벤트 스트림을 실시간으로 생성
•
언제 쓰나
◦
운영 데이터베이스(OLTP)의 변경 사항을 비즈니스 정합성을 유지하며, 거의 실시간(Near Real-time)으로 복제해야 할 때
◦
'증분 수집’방식의 잦은 폴링이 소스 DB에 부하를 주거나, updated_at 인덱스가 없어 비효율적일 때
◦
소스 데이터의 '삭제'를 명확하게 감지하여 타겟 시스템(DW, Data Lake)에 반영해야 할 때
•
운영 포인트
◦
[표준 아키텍처] Debezium(CDC 도구) → Kafka(이벤트 브로커) → Flink/Spark/ksqlDB(스트림 처리)로 이어지는 아키텍처가 업계 표준
◦
[삭제(DELETE) 처리] 소스에서 DELETE가 발생하면, Kafka에 Tombstone 레코드(삭제 신호)가 포함된 이벤트가 전송. 다운스트림(Flink, KSQL)은 이 신호를 인지하고 타겟 저장소에서 해당 데이터를 삭제(Hard Delete)하거나 비활성(Soft Delete) 처리할 수 있음
◦
[초기 적재 (Initial Snapshot)] CDC 스트리밍을 시작하기 전, '현재 시점'의 전체 데이터를 1회 가져오는 초기 적재(Initial Snapshot) 과정이 필요. Debezium 같은 대부분의 도구가 이 스냅샷 기능과 로그 스트리밍을 자동으로 연결 가능
•
예
◦
운영 DB(MySQL)의 '주문' 또는 '회원' 테이블 변경 사항을 데이터 웨어하우스(BigQuery, Snowflake)로 실시간 동기화
◦
'상품' 재고 테이블의 변경을 Elasticsearch로 즉시 반영하여 검색 색인(Index) 최신성 유지
•
참고
◦
이 패턴의 가장 큰 운영 허들은 소스 DB에서 DDL(예: ALTER TABLE ... ADD COLUMN ...)이 실행될 때임
◦
대용량 DDL(스키마 변경) 발생 시 처리가 어렵거나, 스키마 변이(Schema Evolution)를 미처리할 수 있음
◦
스키마 레지스트리(Schema Registry)를 사용하고 호환성 규칙(예: Avro의 BACKWARD)을 강제해서 운영
G. 초기 적재 / 백필 (Initial Load / Backfill)
•
개념
◦
다른 수집 패턴(예: 증분, 이벤트)이 '현재'의 변경분을 다루는 것과 달리, 이 패턴은 과거의 대용량 데이터를 한 번에(One-shot) 적재하는 데 특화된 방식
◦
신규 파이프라인의 '최초 데이터'를 채우거나, 장애로 유실된 '특정 과거 구간'을 다시 채우는(Backfill) 작업을 의미
•
언제 쓰나
◦
신규 데이터 파이프라인을 구축하고, 운영 시작 전 과거 전체 데이터(예: 3년 치 로그)를 적재해야 할 때
◦
기존 파이프라인의 장애나 로직 오류로 인해 특정 기간(예: 3일 치)의 데이터가 유실되거나 잘못되어 재수집이 필요할 때
◦
'변경 데이터 캡처(CDC)' 패턴을 적용하기 전, 초기 스냅샷(Initial Snapshot)을 수동으로 수행해야 할 때
•
운영 포인트
◦
[별도 설계 (필수)] 이 작업은 기존 증분 파이프라인과는 완전히 별개의 DAG(워크플로우)나 수동 스크립트로 구성해야 함
▪
증분 파이프라인(예: 5분 주기)은 낮은 지연 시간에 최적화되어 타임아웃이 짧고 리소스가 적게 할당되지만, 백필 파이프라인은 높은 처리량에 최적화되어 타임아웃이 매우 길고(예: 24시간), 더 많은 리소스(CPU/Memory)와 병렬 처리가 필요
◦
[소스 시스템 보호 (최우선)] 절대 운영(Production) DB에 직접적인 대량 쿼리를 실행하지 않음. 반드시 읽기 전용 복제본(Read Replica)을 사용하거나, DB 관리자와 협의된 시간(예: 트래픽이 적은 새벽)에 실행해야 함. API의 경우 분당 요청 수를 제한(Throttling)해야 함
◦
[분할 처리 (Chunking)] 수년 치 데이터를 한 번에 처리하면 메모리/디스크 부족으로 실패. "하루" 또는 "한 달" 단위로 작업을 작은 배치(Chunk)로 분할하고, 하나씩 순차적/병렬적으로 처리해야 함
◦
[수동 트리거 및 검증] 자동화된 스케줄이 아닌, 엔지니어가 수동으로 트리거(Manual Trigger)하는 것을 원칙으로 함. 작업 완료 후에는 원본 소스와 적재된 타겟의 건수를 반드시 비교하고, 주요 데이터를 샘플링하여 검수 필요
•
예
◦
신규 파이프라인 도입 시, 과거 3년치 '주문' 데이터를 월(Month) 단위로 36번 분할 실행하는 별도 스크립트 적재
◦
11월 5일~7일(3일간) 수집이 실패했을 때, 해당 3일의 기간만 파라미터로 받아 재처리하는 백필(Backfill) 전용 DAG 수동 실행
•
참고
◦
'증분 수집' 파이프라인은 '낮은 지연 시간(Low Latency)'에, '초기 적재' 파이프라인은 '높은 처리량(High Throughput)'에 최적화되어 있음
◦
두 작업은 목적과 리소스 요구량이 완전히 다르므로, 하나의 파이프라인으로 두 가지를 모두 처리하려 하면(예: 백필 작업 중 증분 작업이 멈춤) 운영이 복잡해지고 장애가 발생하기 쉽습니다. 반드시 별도로 설계하고 관리해야 함
H. 하이브리드 / 자가 교정 (Hybrid / Self-Reconciliation)
•
개념
◦
단일 수집 방식이 아닌, 두 개 이상의 패턴을 결합한 운영 전략
◦
[메인 파이프라인] 효율적인 패턴(예: '증분 수집', '이벤트 기반', 'CDC')을 짧은 주기로 실행하여 속도(Low-Latency) 확보
◦
[교정 파이프라인] 견고한 패턴(예: '전체 스냅샷')을 긴 주기로 실행하여 정합성(Accuracy)을 보장
•
언제 쓰나
◦
거의 모든 실전 케이스에 해당
◦
'증분 수집'이나 '이벤트 기반’ 패턴을 메인으로 사용하지만, 소스 측의 '삭제'를 감지할 방법이 없을 때 (필수)
◦
네트워크나 소스 시스템의 일시적 장애로 인한 데이터 누락(Event Loss) 가능성을 원천적으로 차단하고 싶을 때
◦
효율성(비용, 속도)과 데이터 정합성(100% 신뢰) 두 마리 토끼를 모두 잡아야 할 때
•
운영 포인트
◦
[평시 운영 (메인)] '증분 수집' 또는 '이벤트 기반' 파이프라인이 (예: 5분~1시간 주기) 99%의 변경 사항을 신속하게 처리
◦
[주기적 감사 (교정)] '전체 스냅샷' 파이프라인이 (예: 매주 일요일 새벽) 실행되어 소스의 100% 최신 상태를 가져옴
◦
[교정 실행] 이 '전체 스냅샷'(Source of Truth)과 현재 우리 저장소(DW/Lake)의 상태를 비교(Diff)
▪
[삭제 감지] 저장소에는 is_active=true인데 '전체 스냅샷'에 없는 데이터 → '좀비 데이터(Zombie Data)'로 식별하고 is_active=false로 교정
▪
[누락 감지] '전체 스냅샷'에는 있는데 저장소에 없는 데이터 → 메인 파이프라인이 누락한 데이터로 식별하고 INSERT
◦
[리포트] 교정 작업(삭제/누락)이 몇 건 발생했는지 리포트/알림을 생성하여 데이터 품질을 모니터링
•
예
◦
상품 정보는 '증분 수집'(매일)으로 수집 + '전체 스냅샷'(일요일)을 실행하여 삭제/누락분 교정
•
참고
◦
우리 파이프라인은 완벽해서 누락이 없어요라고 가정하는 것은 위험
◦
소스 시스템의 버그, 네트워크의 일시적 단절, 이벤트 큐의 장애 등으로 인해 데이터 유실은 반드시 발생
◦
'하이브리드 / 자가 교정' 패턴은 선택이 아닌, 신뢰할 수 있는 데이터 파이프라인을 구축하기 위한 필수적인 안전장치 전략
운영 표준 (멱등성/삭제/재시도/관측성)
1) 멱등성(Idempotency)
파이프라인이 여러 번 재시도되어도 결과가 동일해야 합니다.
•
식별자
◦
identity_key를 명확히 정의
•
중복 방지
◦
같은 아이템에 대해서 hash 값을 뽑아서 hash(SHA256) 로 저장 → 동일 해시 스킵
•
업서트 기준
◦
한 가지 기준(예: updated_at) 또는 명확한 우선순위 규칙으로 고정
-- BigQuery 예시(업서트)
MERGE target t
USING staging s
ON t.identity_key = s.identity_key
WHEN MATCHED AND s.updated_at > t.updated_at THEN
UPDATE SET ...
WHEN NOT MATCHED THEN
INSERT (...);
SQL
복사
2) 삭제/비활성화
•
소프트 삭제 권장
◦
is_active (BOOL), deleted_at (TIMESTAMP) 필드 사용
◦
하드 삭제는 회귀 분석, 감사(Audit)를 어렵게 하므로 지양합니다.
•
패턴별 처리
◦
전체 스냅샷' / '하이브리드: 오늘 스냅샷에 없는 키 = 비활성 후보
◦
증분 수집' / '이벤트 기반' / '변경 데이터 캡처: 삭제 이벤트(DELETE, Tombstone) 수신 시 즉시 반영
3) 재시도·순서 보장
•
재시도
◦
지수 백오프(Exponential Backoff) + Jitter 적용으로 서버 부담 완화
•
순서 보장
◦
since_id, offset 또는 CDC의 LSN/GTID 같은 명확한 순서 기준을 사용
•
Exactly-once 어려우면
◦
구현이 어렵다면, At-least-once (최소 1회 전달) + 멱등성 조합으로 실질적인 1회 처리를 달성
4) 관측성(Observability)
데이터는 '쌓는 것'이 아니라 '관리하는 것'입니다.
•
메트릭
◦
파이프라인 지표: 수집 건수, 변경/삭제 건수, API 응답(2xx/4xx/5xx), 재시도 횟수, 처리 지연(ms)
◦
증분 지연: 현재 시각 - 최신 처리된 데이터의 시각 (소스 침묵 감지)
◦
데이터 품질 지표: Null/Empty 비율, 고유 키(Unique Key) 중복 건수, 패턴/타입 불일치 건수
•
알림 룰
◦
장시간 수집 건수 0 (소스 침묵)
◦
오류율(4xx/5xx) 급증
◦
증분 지연 시간 임계치 초과
◦
교정 작업에서 불일치 비율 임계치 초과
마무리
여러 패턴을 봤지만, 현실에서 데이터 수집에 '만능 공식'이나 '실버 불렛' 같은 건 없습니다. 소스 API나 DB마다 성격이 다 다르고, 요구사항도 제각각입니다. "무조건 실시간이 최고야" 또는 "무조건 전체 수집이 안전해" 같은 단편적인 접근은 거의 항상 문제를 일으킵니다.
이번 글에서 정리한 수집 패턴은 이런 복잡한 상황에서 **‘무엇을 기준으로 선택할지’**를 명확히 하는 데 목적이 있습니다. 회사에서 익숙하게 쓰던 방식을 무조건 적용하기보다는, 소스의 특성과 목적에 맞는 패턴을 의식적으로 선택하는 것이 중요합니다. 그리고 모든 파이프라인은 결국 시간이 지나면 변화할 수밖에 없습니다. 중요한 것은 처음부터 완벽하게 만드는 것이 아니라, 문제를 잘 관찰하고 점진적으로 고도화해 나가는 태도입니다.
데이터 엔지니어의 역할은 단순히 데이터를 수집하는 것에 그치지 않습니다. 수집 과정에서 그에 맞는 정책을 명확히 정의하고, 가시성을 확보하는 것이 중요합니다. 이러한 가시성을 통해 파이프라인의 품질을 검증하고, 문제를 조기에 감지하며, 결국에는 데이터 플랫폼 전체의 신뢰성을 높일 수 있습니다.
신뢰할 수 없는 데이터는 정확한 분석도, 안정적인 서비스도 불가능하게 만듭니다. 다음 글에서는 이러한 데이터 가시성(Observability) 을 어떻게 확보하고 실제 파이프라인 품질 관리에 활용할 수 있는지 구체적으로 살펴보겠습니다.