모던 데이터 파이프라인 해부 퀴즈
마지막 업데이트: 2026년 8월 28일
데이터 파이프라인 5개 계층(소스·수집·저장·처리·소비)과 계층 간 계약에 대한 이해도를 테스트합니다.
객관식 문제
- 스트리밍 큐(Kafka 등)가 단순 전송로 이상의 역할을 한다고 평가받는 핵심 이유는 무엇인가요?
- A) 데이터를 자동으로 정제해 웨어하우스 스키마에 맞춰주기 때문에
- B) 보존 기간 안에서 컨슈머 오프셋을 되감아 재소비할 수 있어 재처리의 기준점이 되기 때문에
- C) 배치 커넥터보다 처리량이 항상 높기 때문에
- D) 저장 계층을 대체할 수 있기 때문에
정답 보기
정답: B) 보존 기간 안에서 컨슈머 오프셋을 되감아 재소비할 수 있어 재처리의 기준점이 되기 때문에
설명: 스트리밍 큐는 이벤트를 보존 기간 동안 유지하므로, 장애나 로직 수정 후 오프셋을 되감아 재소비할 수 있습니다. 처리 계층의 정확성 보장(exactly-once 등)이 이 재처리 능력 위에 성립합니다.
- 데이터 레이크와 웨어하우스의 역할 분담으로 가장 일반적인 흐름은 무엇인가요?
- A) 웨어하우스에 원본을 먼저 적재하고, 레이크에는 백업만 둔다
- B) 원본은 레이크에 먼저 보존해 재처리 가능성을 확보하고, 정제본을 웨어하우스로 적재(ELT)한다
- C) 레이크와 웨어하우스에 동일한 데이터를 이중 기록한다
- D) 스트리밍 데이터는 웨어하우스로, 배치 데이터는 레이크로만 보낸다
정답 보기
정답: B) 원본은 레이크에 먼저 보존해 재처리 가능성을 확보하고, 정제본을 웨어하우스로 적재(ELT)한다
설명: 원본을 저비용 레이크에 그대로 남겨두면 이후 로직 변경 시 언제든 재처리할 수 있습니다. 정제본만 쿼리 성능이 좋은 웨어하우스로 올리는 ELT 패턴이 표준이며, 최근에는 Iceberg 같은 테이블 포맷으로 레이크 하나가 두 역할을 겸하는 레이크하우스도 늘고 있습니다.
- 같은 지표를 스트림 처리와 배치 처리 양쪽에서 계산하는 전형적인 패턴의 목적은 무엇인가요?
- A) 두 결과를 비교해 버그를 찾기 위해
- B) 스트림으로 실시간 근사치를 제공하고, 배치로 정확한 값을 재계산해 서로 다른 신선도·정확도 요구를 함께 충족하기 위해
- C) 스트림 처리가 실패할 때만 배치를 돌리기 위해
- D) 처리 비용을 두 팀에 나누기 위해
정답 보기
정답: B) 스트림으로 실시간 근사치를 제공하고, 배치로 정확한 값을 재계산해 서로 다른 신선도·정확도 요구를 함께 충족하기 위해
설명: 실시간 대시보드는 초 단위 신선도가, 정산은 정확성이 우선입니다. 배치와 스트림은 대체 관계가 아니라 지연 요구사항에 따른 분업이며, 소비자별 신선도·정확도 계약이 이 설계를 역으로 결정합니다.
- 파이프라인 장애의 단골 원인으로 꼽히는 "조용한 스키마 전파 사고"를 막는 대표적 방어선은 무엇인가요?
- A) 모든 계층을 하나의 데이터베이스로 통합
- B) 스키마 레지스트리와 호환성 규칙으로 소스 스키마 변경을 계약으로 관리
- C) 소비 계층에서 매일 수동 검수
- D) CDC를 끄고 전체 스냅샷만 사용
정답 보기
정답: B) 스키마 레지스트리와 호환성 규칙으로 소스 스키마 변경을 계약으로 관리
설명: 소스의 스키마 변경이 알림 없이 하류로 전파되면 소비 계층에서야 깨진 채 발견됩니다. 스키마 레지스트리에 스키마를 등록하고 호환성 규칙(후방/전방 호환)을 강제하면 비호환 변경이 배포 시점에 차단됩니다.