기준일 2026-08-07 대상 리멤버앤컴퍼니 Data Engineer 1차 면접 예상 질문
이 표의 목적은 답변에 기술 용어를 더 붙이는 데 있지 않다. 이미 준비한 답변의 판단 근거를 스터디 글로 다시 확인하고, 질문을 받았을 때 선택 이유와 한계를 자기 말로 설명하기 위한 경로다.
Spark·Kafka 등 스터디로 학습한 내용은 프로덕션 경험으로 바꾸어 말하지 않는다. 면접에서는
경험,과제에서 검증한 것,학습한 개념을 구분한다.
먼저 읽을 6편
면접 전 시간이 부족하면 아래 순서만 먼저 본다.
- 오케스트레이션 설계 원칙 — DAG 경계와 멱등성
- 배치 파이프라인 운영 — backfill·retry·checkpoint
- 데이터 품질 — 차단 조건과 reconciliation
- 데이터 계약 — schema·SLA·owner
- 쿼리 옵티마이저와 실행계획 —
EXPLAIN근거 - 인시던트 관리와 포스트모텀 — 장애 대응과 재발 방지
리멤버 공개 자료에서 추가로 확인한 7편
채용 공고와 2025년 AWS 기술 블로그의 리멤버 아키텍처를 기존 스터디와 대조했다. Airflow·Spark·Kafka·Iceberg 기본·데이터 품질·이관·MySQL·Kubernetes는 이미 있어 새로 만들지 않았다. 아래는 실제 공백만 보강한 글이다.
| 새로 보강한 주제 | 읽으면 답할 수 있는 질문 |
|---|---|
| 식별·매핑·MDM | 같은 사람·회사를 어떻게 연결하고, false merge·false split을 어떻게 줄이며, 잘못 합친 결정을 어떻게 풀 것인가? |
| Full Load와 CDC 접속점 | 초기 이관 중 생긴 변경을 누락·중복 없이 어떻게 이어 붙일 것인가? |
| S3 Tables 운영 | CDC가 만드는 small file·snapshot·orphan file을 어떻게 정리하고 복구 기간을 지킬 것인가? |
| PyIceberg 관측 | 관리형 maintenance가 실제로 작동하는지 파일·스냅샷 metadata로 어떻게 확인할 것인가? |
| Lake Formation 권한 | IAM과 데이터 수준 권한을 어떻게 나누고 컬럼·행·재처리 산출물까지 보호할 것인가? |
| Glue·PySpark Full Load | 운영 DB를 보호하며 수십억 행을 병렬 이관하고 타입·행 수·키를 어떻게 검증할 것인가? |
| StarRocks·Iceberg 서빙 | 운영 DB·레이크하우스·저지연 분석 계층의 책임과 freshness를 어떻게 나눌 것인가? |
시리즈를 처음부터 읽으려면 리멤버 공개 자료로 보는 Data Engineering에서 시작한다.
예상 질문별 연결표
| 예상 질문 | 연결 스터디 | 답변에서 확인할 기준 |
|---|---|---|
P0-10, P0-18, P0-19 과제 구조·Airflow·멱등성 | 오케스트레이션 설계 원칙 · 배치 파이프라인 운영 | DAG가 맡는 데이터 경계, 재실행 시 같은 상태로 수렴하는 이유, checkpoint와 publish 경계를 설명한다. |
P0-20 exactly-once의 실제 범위 | Exactly-once의 실제 경계 · 분산 트랜잭션 | 업무 데이터 트랜잭션과 ops_sync_run 기록 사이의 seam을 숨기지 않는다. |
P0-21, P1-26 DQ·모니터링·중단선 | 데이터 품질 · 운영 대시보드 | completeness·freshness·uniqueness·validity·reconciliation 중 무엇을 막고 무엇을 경고할지 나눈다. |
P0-13~P1-17 키·NULL·부재·MDM 확장 | 데이터 계약 · 분석 모델링과 SCD | 원천 사실과 정책값을 분리하고, 식별 근거·이력·수동 판정·되돌림 경계를 둔다. 전용 MDM 운영 경험이 있다고 말하지 않는다. |
P0-22, P1-27 문서·구현 차이와 스키마 변경 | 데이터 파이프라인 테스트 전략 · 스키마 변경 안전 배포 | unit·integration·E2E가 각각 무엇을 막는지, breaking change를 expand-contract와 dual-read로 어떻게 검증할지 말한다. |
P0-24 동시 backfill | Backfill 안전장치 · Airflow scheduling과 backfill | data_interval, catchup, replay 범위, 중복 방지와 max_active_runs의 한계를 연결한다. |
P0-11, P1-23 DuckDB 선택과 규모 확장 | OLTP와 OLAP · Spark 아키텍처 | 현재 단일 노드의 메모리·I/O 경계를 먼저 측정하고, 분산 비용이 정당화될 때 Spark를 검토한다고 답한다. |
P1-06 Spark·Kafka 경험 부족 | Spark 아키텍처 · Kafka 아키텍처 | Driver·Executor와 topic·partition·consumer group의 역할만 정확히 설명한다. 학습 내용을 운영 경험처럼 말하지 않는다. |
P1-09 개인정보 데이터 운영 | 개인정보·보안 · masking·tokenization·retention | 수집 목적, 최소 권한, 마스킹, 보존·삭제, 재처리 산출물과 감사 로그를 같은 정책 경계로 본다. |
P0-25 대규모 이관 | Cloud DB 마이그레이션 전략 · 배포 후 모니터링과 rollback | 대상 집합과 기준 시점 고정 → dry-run·canary → go/no-go → rollback → reconciliation 순서를 확인한다. |
P0-28, P0-30 실행계획·인덱스 변경 | 쿼리 옵티마이저와 실행계획 · 튜닝 검증 | 130만→6,000은 스캔 행 수라는 단위를 유지하고, before/after plan과 쓰기 부작용까지 본다. |
P0-29 connection·queue·backpressure | Connection storm과 pool 운영 · 실패 감지와 복구 패턴 | bounded queue, pool, timeout, 429 + Retry-After, circuit breaker가 숨기지 않는 실패 경계를 설명한다. |
P0-31, P0-32 장애와 협업 | 인시던트 관리와 포스트모텀 · 팀 리뷰·배포 권한 | 탐지·완화·원인·재발 방지 순서와 본인·팀원·팀장·CTO의 실제 책임 범위를 함께 말한다. |
| 배치형 CDC 추가 질문 | CDC와 binlog 기반 동기화 · binlog 운영과 모니터링 | 약 1시간 단위 파일 동기화라는 실제 경계를 유지하고 실시간 Kafka CDC로 표현하지 않는다. |
읽은 뒤 말로 확인할 질문
- 이 설계에서 멱등성을 보장하는 키와 트랜잭션 경계는 어디인가?
- 재시도·backfill·동시 실행은 각각 어떤 중복 위험을 만드는가?
- 품질 규칙 중 즉시 중단할 것과 경고만 남길 것은 무엇인가?
- 단일 노드에서 중앙 DB나 분산 처리로 옮기는 측정 기준은 무엇인가?
- 실제 수행한 일과 운영에서 보완할 설계를 한 문장 안에서 구분했는가?
- Spark·Kafka·개인정보·MDM 질문에서 경험하지 않은 범위를 먼저 밝혔는가?