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

작성일 | 분류 |
S3 스토리지 클래스와 성능, Glue와 EMR, Redshift 분산 설계, Kinesis와 MSK, IAM 권한 모델, 비용 최적화를 데이터 엔지니어 관점에서 정리합니다.

S3

S3의 일관성 모델은 어떻게 되나요

2020년 12월부터 강한 일관성(strong read-after-write consistency)을 제공합니다. PUT 직후 GET하면 항상 최신 객체가 보이고, 목록 조회에도 즉시 반영됩니다.

그 이전에는 최종 일관성이라 방금 쓴 파일이 목록에 안 보이는 문제가 있었고, EMRFS consistent view 같은 우회 장치가 필요했습니다. 지금은 필요 없습니다.

다만 원자적 rename이 없다는 점은 그대로입니다. S3의 “이동”은 복사 후 삭제이고, 디렉터리 개념도 없습니다(키 접두사일 뿐). Spark의 파일 커밋 프로토콜이 S3에서 느리고 위험한 이유이며, Iceberg·Delta 같은 테이블 포맷이 필요한 배경이기도 합니다.

스토리지 클래스를 어떻게 고르나요

클래스 용도 특징
Standard 자주 접근 기본
Intelligent-Tiering 접근 패턴이 불규칙 자동으로 계층 이동, 모니터링 비용 소량
Standard-IA / One Zone-IA 가끔 접근 저장 저렴, 조회 요금 발생, 최소 보관 30일
Glacier Instant / Flexible / Deep Archive 보관 매우 저렴, 복원 시간·비용

IA 계열은 최소 보관 기간과 최소 객체 크기가 있어, 작은 파일을 자주 바꾸면 오히려 비쌉니다. 라이프사이클 정책으로 자동 전환을 걸어두는 것이 일반적입니다.

S3 성능을 높이려면 어떻게 하나요

접두사(prefix) 단위로 초당 요청 한도가 적용되므로, 키를 여러 접두사에 분산하면 처리량이 올라갑니다. 예전에는 해시를 앞에 붙이라고 했는데, 지금은 S3가 자동으로 파티션을 나눠서 날짜 기반 접두사도 대체로 괜찮습니다.

더 중요한 것은 파일 크기입니다. 작은 파일이 많으면 요청 수가 폭증합니다. 요청 자체가 과금 대상이고 지연도 붙습니다. 128MB~1GB 정도로 맞추는 것이 일반적인 권장입니다.

대용량 업로드는 멀티파트로 병렬화하고, 실패한 멀티파트 업로드는 라이프사이클 규칙으로 정리해야 합니다. 안 그러면 보이지 않는 저장 비용이 계속 쌓입니다.

S3 비용은 어디서 발생하나요

  • 저장 용량 — 클래스별 단가
  • 요청 수 — PUT/GET/LIST. 작은 파일이 많으면 여기가 커집니다
  • 데이터 전송 — 리전 밖으로 나가는 트래픽. 같은 리전 내 S3↔EC2는 무료
  • 조회 요금 — IA·Glacier 계열
  • 버전 관리 — 버저닝을 켜두고 정리 안 하면 옛 버전이 계속 쌓입니다

크로스 리전 전송이 예상보다 비싼 경우가 많습니다. 컴퓨트와 스토리지를 같은 리전에 두는 것이 기본입니다.

처리 엔진

Glue와 EMR은 어떻게 다른가요

Glue는 서버리스 ETL입니다. 클러스터를 관리하지 않고 DPU 단위로 과금됩니다. 짧은 배치, 간헐적 작업에 적합합니다. 대신 Spark 버전과 설정 자유도가 제한적이고, 시작 지연(콜드 스타트)이 있습니다.

EMR은 관리형 Hadoop/Spark 클러스터입니다. 인스턴스 타입, Spark 설정, 부트스트랩 스크립트를 자유롭게 다룰 수 있고 스팟 인스턴스로 비용을 크게 줄일 수 있습니다. 대신 클러스터 수명주기를 직접 관리해야 합니다.

EMR Serverless가 그 중간입니다. 클러스터 관리 없이 EMR의 엔진을 쓰는 형태입니다.

기준을 단순화하면 — 오래 돌고 튜닝이 필요한 대용량 배치는 EMR, 가볍고 자주 도는 작업은 Glue입니다.

Glue Data Catalog는 무엇인가요

Hive Metastore 호환 메타데이터 저장소입니다. 테이블 스키마·파티션 정보를 두고, Athena·EMR·Redshift Spectrum·Glue Job이 공유합니다.

Glue Crawler가 S3를 스캔해 스키마를 추론하고 카탈로그에 등록합니다. 편하지만 추론이 틀리는 경우가 있고(숫자를 문자열로, 날짜를 문자열로), 파티션이 많으면 크롤링이 느리고 비쌉니다. 스키마가 안정적이라면 DDL로 직접 정의하고 파티션만 ALTER TABLE ADD PARTITION 또는 MSCK REPAIR TABLE로 추가하는 편이 예측 가능합니다.

Athena를 쓸 때 비용을 줄이려면

Athena는 스캔한 데이터 양으로 과금합니다. 그래서 줄이는 방법이 명확합니다.

  • 컬럼너 포맷(Parquet/ORC) — 필요한 컬럼만 읽음
  • 파티셔닝 — 조건에 맞는 파티션만 스캔. 파티션 컬럼을 WHERE에 반드시 포함
  • 압축 — 스캔량 자체가 줄어듦
  • SELECT * 지양

파티션 프루닝이 안 되면 전체를 스캔하므로, 파티션 컬럼을 가공한 조건(WHERE substr(dt,1,7) = '2026-08')은 피해야 합니다.

Redshift

분산 키(DISTKEY)와 정렬 키(SORTKEY)를 설명해보세요

Redshift는 데이터를 여러 노드·슬라이스에 나눠 저장합니다.

DISTSTYLE / DISTKEY는 어떻게 나눌지를 정합니다.

스타일 방식 적합한 경우
KEY 지정 컬럼 해시로 분산 조인 키. 같은 값이 같은 슬라이스에 모여 셔플 감소
ALL 모든 노드에 복제 작은 디멘전 테이블
EVEN 라운드로빈 조인에 안 쓰이는 테이블
AUTO Redshift가 판단 기본값

SORTKEY는 블록 내 정렬 순서입니다. 정렬되어 있으면 존 맵(블록별 min/max)으로 불필요한 블록을 건너뜁니다. 날짜 컬럼을 SORTKEY로 두는 경우가 많습니다.

VACUUM과 ANALYZE는 무엇인가요

VACUUM은 삭제된 행의 공간을 회수하고 정렬 순서를 복원합니다. Redshift는 UPDATE를 “삭제 표시 + 삽입”으로 처리하므로 갱신이 많으면 공간이 낭비되고 정렬이 흐트러집니다.

ANALYZE는 통계를 갱신합니다. 통계가 낡으면 옵티마이저가 잘못된 조인 순서를 고릅니다.

최근에는 자동 VACUUM·ANALYZE가 동작하지만, 대량 적재 직후에는 수동으로 돌리는 것이 안전합니다.

대량 적재는 어떻게 하나요

INSERT를 반복하면 매우 느립니다. COPY 명령으로 S3에서 병렬 적재하는 것이 정석입니다.

COPY events FROM 's3://bucket/prefix/'
IAM_ROLE 'arn:aws:iam::...:role/...'
FORMAT AS PARQUET;

파일을 슬라이스 수의 배수로 나눠두면 병렬도가 최대가 됩니다. 파일 하나만 있으면 슬라이스 하나만 일합니다.

Redshift Spectrum은 무엇인가요

S3의 외부 테이블을 Redshift에서 직접 쿼리하는 기능입니다. 자주 쓰는 데이터는 Redshift 안에, 오래된 데이터는 S3에 두고 필요할 때만 조인하는 구조를 만들 수 있습니다.

Athena처럼 스캔량 기준 과금이라 파티셔닝과 컬럼너 포맷이 그대로 중요합니다.

스트리밍

Kinesis Data Streams와 MSK를 비교해보세요

  Kinesis Data Streams MSK (관리형 Kafka)
프로토콜 AWS 고유 Kafka 호환
확장 단위 샤드 파티션
보관 기본 24시간, 최대 365일 설정에 따라
생태계 AWS 서비스 통합이 쉬움 Kafka 커넥터·도구 그대로
운영 완전 관리형(온디맨드 모드) 브로커·토픽 관리 필요

이미 Kafka 생태계를 쓰고 있거나 멀티 클라우드를 고려한다면 MSK, AWS 안에서 단순하게 가려면 Kinesis가 자연스럽습니다.

샤드와 파티션의 병렬도 개념은 같나요

비슷합니다. Kinesis에서 샤드 하나는 쓰기 1MB/s·1000 records/s, 읽기 2MB/s의 한도를 갖고, 컨슈머 병렬도의 단위이기도 합니다.

차이는 재파티셔닝 방식입니다. Kinesis는 샤드를 분할(split)·병합(merge)할 수 있어 줄이는 것도 가능한 반면, Kafka 파티션은 늘릴 수만 있습니다.

IAM과 비용

IAM 역할과 사용자의 차이는 무엇인가요

사용자는 장기 자격 증명(액세스 키)을 가진 주체이고, 역할은 임시 자격 증명을 발급받아 위임(assume)하는 방식입니다.

애플리케이션과 서비스는 역할을 써야 합니다. EC2 인스턴스 프로파일, EKS의 IRSA(ServiceAccount에 역할 연결), Lambda 실행 역할이 모두 이 방식입니다. 액세스 키를 코드나 환경변수에 넣는 것은 유출 시 회수가 어렵습니다.

권한 평가는 명시적 Deny > 명시적 Allow > 암묵적 Deny 순입니다. S3 버킷 정책, IAM 정책, SCP, VPC 엔드포인트 정책이 모두 겹쳐 적용되므로, 접근이 안 될 때는 어느 계층에서 막혔는지 순서대로 봐야 합니다.

크로스 계정으로 S3에 접근하려면

버킷 정책에서 상대 계정·역할을 허용하고, 접근하는 쪽 역할에도 해당 버킷 권한을 줍니다. 양쪽 모두 필요합니다.

한 가지 흔한 함정이 객체 소유권입니다. 다른 계정이 버킷에 객체를 쓰면 기본적으로 그 계정이 객체 소유자가 되어, 버킷 소유자가 읽지 못하는 상황이 생깁니다. bucket-owner-full-control ACL을 지정하거나 Bucket Ownership Enforced 설정을 켜서 해결합니다.

데이터 파이프라인 비용을 줄이는 방법은 무엇인가요

  • EMR 스팟 인스턴스 — Core 노드는 온디맨드, Task 노드는 스팟으로. 중단돼도 재계산 가능한 부분에만 스팟을 씁니다
  • 클러스터 수명 단축 — 상시 클러스터 대신 잡마다 뜨고 지는 transient 클러스터
  • S3 라이프사이클 — 오래된 파티션을 IA·Glacier로 이동
  • 스캔량 감소 — 파티셔닝과 Parquet. Athena·Spectrum 비용에 직접 영향
  • 작은 파일 정리 — 요청 수와 태스크 오버헤드를 동시에 줄임
  • 크로스 리전 전송 제거 — 컴퓨트와 데이터를 같은 리전에

비용 원인을 찾을 때는 Cost Explorer에서 서비스별로 나눈 뒤, S3라면 요청 수인지 저장인지 전송인지까지 내려가 봐야 합니다.