데이터 엔지니어 인터뷰 — GCP

작성일 | 분류 |
GCS 스토리지 클래스, Dataflow와 Dataproc, Pub/Sub, Composer, Datastream, IAM 계층과 서비스 계정, 네트워크와 비용 관리를 데이터 엔지니어 관점에서 정리합니다.

스토리지

GCS 스토리지 클래스를 설명해보세요

클래스 최소 보관 용도
Standard 없음 자주 접근
Nearline 30일 월 1회 정도
Coldline 90일 분기 1회 정도
Archive 365일 연 1회 이하, 백업

S3와 달리 모든 클래스가 밀리초 단위 접근을 제공합니다. Archive도 복원 대기 없이 바로 읽힙니다. 대신 조회 요금과 최소 보관 기간이 붙습니다.

최소 보관 기간 전에 삭제·변경하면 남은 기간만큼 조기 삭제 요금이 부과됩니다. 자주 바뀌는 데이터를 Coldline에 두면 오히려 손해입니다.

버킷 위치는 어떻게 고르나요

  • Region — 단일 리전. 가장 저렴하고 지연이 낮음
  • Dual-region — 두 리전에 복제. 고가용성 + 낮은 지연
  • Multi-region — 대륙 단위. 전역 배포용

데이터 처리 파이프라인은 컴퓨트와 같은 리전에 두는 것이 기본입니다. 리전이 다르면 전송 비용과 지연이 붙고, BigQuery는 아예 다른 리전의 GCS에서 로드할 수 없습니다.

GCS와 S3의 차이 중 실무에서 체감되는 것은 무엇인가요

가장 큰 차이는 강한 일관성입니다. GCS는 처음부터 객체 생성·삭제·목록 조회에 강한 일관성을 제공했습니다.

그리고 객체 컴포지션(여러 객체를 이어 붙이기)이나 재개 가능 업로드가 네이티브로 지원됩니다.

공통점도 많습니다. 디렉터리가 없고 접두사만 있다는 점, 원자적 rename이 없다는 점은 같아서, 파일 커밋 문제와 테이블 포맷의 필요성은 동일합니다.

처리 엔진

Dataflow와 Dataproc은 어떻게 다른가요

Dataflow는 Apache Beam 기반 서버리스 처리 서비스입니다. 클러스터를 관리하지 않고, 오토스케일링과 동적 작업 재분배(dynamic work rebalancing)를 제공합니다. 배치와 스트리밍을 같은 코드로 작성할 수 있는 것이 Beam의 특징입니다.

Dataproc은 관리형 Hadoop/Spark 클러스터입니다. 기존 Spark 코드를 그대로 옮길 수 있고 세밀한 튜닝이 가능합니다.

기준을 단순화하면 — 기존 Spark 자산이 있으면 Dataproc, 새로 만들고 운영 부담을 줄이려면 Dataflow입니다. Dataflow는 특히 스트리밍에서 오토스케일링과 워터마크 처리가 잘 되어 있습니다.

Beam의 핵심 개념을 설명해보세요

  • PCollection — 분산 데이터셋. 유한(배치)일 수도 무한(스트림)일 수도 있음
  • PTransform — 변환 연산
  • Pipeline — 전체 그래프
  • Window / Trigger / Watermark — 무한 스트림을 유한 단위로 자르고 언제 결과를 낼지 정함

배치와 스트리밍을 통합하는 지점이 윈도우입니다. 배치는 “전체가 하나의 윈도우”인 특수한 경우로 취급됩니다.

Runner를 바꾸면 같은 코드가 Dataflow, Flink, Spark 위에서 돌 수 있습니다. 다만 러너별로 지원 기능에 차이가 있습니다.

Dataflow의 오토스케일링이 잘 안 되는 경우는 언제인가요

  • 키 개수가 적을 때 — GroupByKey 이후 병렬도는 키 수에 묶입니다. 키가 10개면 워커를 늘려도 소용없습니다
  • 외부 시스템이 병목일 때 — DB 커넥션 한도에 걸리면 워커를 늘려도 대기만 늘어납니다
  • 핫 키(skew) — 특정 키에 데이터가 몰리면 그 키를 맡은 워커만 바쁩니다

스트리밍에서는 Streaming Engine을 켜면 상태 관리가 워커에서 분리되어 스케일링이 유연해집니다.

메시징

Pub/Sub과 Kafka의 차이는 무엇인가요

  Pub/Sub Kafka
모델 완전 관리형 큐/토픽 로그 기반
순서 보장 ordering key 지정 시 파티션 내
재처리 seek(스냅샷·타임스탬프) 오프셋 되감기
확장 자동 파티션 수 관리
보관 기본 7일 설정

Pub/Sub은 파티션 개념이 노출되지 않습니다. 확장을 신경 쓸 필요가 없는 대신, 파티션 단위로 병렬도를 통제하는 방식은 쓸 수 없습니다.

기본은 at-least-once입니다. exactly-once 전달 옵션이 있지만 리전 내에서만 보장되고, 결국 소비자 멱등성이 중요합니다.

Pub/Sub에서 메시지 중복과 순서를 어떻게 다루나요

중복은 기본적으로 발생할 수 있습니다. message_id나 비즈니스 키로 멱등 처리를 해야 합니다. ack 기한(ackDeadline) 안에 처리를 못 끝내면 재전송되므로, 처리 시간이 길면 기한을 늘리거나 modifyAckDeadline으로 연장해야 합니다.

순서는 orderingKey를 지정하면 같은 키끼리 순서가 보장됩니다. 대신 그 키의 메시지는 직렬 처리되므로 처리량이 떨어지고, 하나가 막히면 뒤가 밀립니다.

데드 레터 토픽은 왜 필요한가요

처리에 계속 실패하는 메시지가 무한 재전송되면 파이프라인 전체가 막힙니다. 최대 전달 횟수를 넘긴 메시지를 별도 토픽으로 보내 격리하고, 나중에 따로 분석·재처리합니다.

오케스트레이션과 CDC

Cloud Composer는 무엇인가요

관리형 Airflow입니다. GKE 위에서 동작하며 스케줄러·웹서버·워커를 GCP가 관리합니다.

주의할 점은 비용이 상시 발생한다는 것입니다. DAG가 없어도 환경이 떠 있으면 과금됩니다. 가벼운 스케줄링만 필요하다면 Cloud Scheduler + Cloud Run/Functions 조합이 훨씬 저렴합니다.

DAG는 GCS 버킷에 올리면 자동 동기화됩니다.

Datastream은 무엇인가요

관리형 CDC 서비스입니다. MySQL·PostgreSQL·Oracle의 변경 로그를 읽어 BigQuery나 GCS로 복제합니다.

BigQuery 대상일 경우 스트리밍 업서트로 반영되는데, 여기서 비용이 크게 나올 수 있습니다. 업서트가 대상 파티션을 재작성하므로, 파티셔닝 설계가 잘못되면 요금이 급증합니다. 소스 테이블에 갱신이 잦다면 append-only로 받아서 주기적으로 정리하는 구조도 검토할 만합니다.

소스 DB에 로그 보관 설정(binlog retention, WAL)이 충분해야 하고, 복제 지연이 그 보관 기간을 넘기면 초기 스냅샷부터 다시 해야 합니다.

IAM과 네트워크

GCP의 리소스 계층과 IAM 상속을 설명해보세요

Organization
  └── Folder
        └── Project
              └── Resource (버킷, 데이터셋, 인스턴스 …)

상위에서 부여한 권한은 하위로 상속됩니다. 조직 수준에서 준 역할은 모든 프로젝트에 적용되므로, 넓은 범위에 강한 역할을 주지 않는 것이 중요합니다.

역할은 세 종류입니다.

  • 기본 역할(Owner/Editor/Viewer) — 너무 광범위해서 운영에서는 지양
  • 사전 정의 역할 — 서비스별로 세분화됨(roles/bigquery.dataViewer 등)
  • 커스텀 역할 — 필요한 권한만 조합

서비스 계정을 안전하게 쓰려면

키 파일(JSON)을 만들지 않는 것이 원칙입니다. 유출되면 회수가 어렵고 만료도 없습니다.

대신 쓰는 방법들입니다.

  • Workload Identity (GKE) — 쿠버네티스 ServiceAccount를 GCP 서비스 계정에 연결
  • Workload Identity Federation — AWS·GitHub Actions 등 외부 워크로드가 키 없이 GCP 자격 증명을 얻음
  • Attached service account — GCE·Cloud Run에 서비스 계정을 붙이면 메타데이터 서버에서 토큰을 받음
  • ADC — 로컬 개발에서는 gcloud auth application-default login
gcloud auth application-default login
gcloud config set project <PROJECT_ID>

VPC Service Controls는 무엇인가요

프로젝트 경계를 넘는 데이터 반출을 막는 경계(perimeter)를 설정하는 기능입니다. IAM 권한이 있어도 경계 밖으로는 데이터를 가져갈 수 없게 합니다.

내부자 위협이나 자격 증명 유출에 대비하는 계층인데, 설정이 까다로워서 정상 파이프라인까지 막히는 경우가 많습니다. 도입할 때는 dry-run 모드로 영향을 먼저 확인해야 합니다.

비용

GCP 데이터 파이프라인 비용은 어디서 나오나요

  • BigQuery — 스캔량(on-demand) 또는 슬롯 예약. 대개 여기가 가장 큼
  • GCS — 저장, 클래스별 조회 요금, 리전 간 전송
  • Dataflow — 워커 vCPU·메모리 × 시간, Streaming Engine, Shuffle
  • Composer — 환경 상시 비용
  • Datastream — 처리 바이트

비용을 통제하는 방법은 무엇인가요

  • 예산과 알림 — 프로젝트별 예산을 걸고 임계치 알림
  • 커스텀 쿼터 — BigQuery는 사용자·프로젝트별 일일 쿼리 바이트 상한을 걸 수 있습니다. 실수로 큰 쿼리를 돌리는 사고를 막는 가장 확실한 장치입니다
  • 라벨링 — 리소스에 팀·용도 라벨을 붙여 청구서를 분해
  • 커밋 할인 — 예측 가능한 사용량에 CUD 적용
  • preemptible / Spot VM — Dataproc의 보조 워커에 적용

청구 데이터를 BigQuery로 내보내면 세부 분석이 가능합니다. 서비스·라벨·SKU 단위로 어디서 늘었는지 추적할 수 있습니다.

관련 글