AWS DEA-C01 문제로 공부하기 — Day 01
VPC 네트워킹, Lake Formation 거버넌스, Data Exchange, 데이터 메시, Lambda Layer까지 — 5문제로 Domain 1 핵심 개념을 한 번에 정리합니다.
AWS Glue를 VPC 환경에서 실행할 때 S3 연결 오류가 나는 원인 중 하나가 VPC Gateway Endpoint 라우팅 테이블 미설정입니다. 네트워크 경로 vs 권한 문제를 구분하는 것이 핵심이며, DEA-C01에서 Glue + VPC 트러블슈팅 유형으로 자주 출제됩니다.
데이터 엔지니어가 Amazon S3 버킷에서 데이터를 읽도록 AWS Glue 작업을 구성하고 있습니다. 필요한 AWS Glue 연결 정보와 관련 IAM 역할을 설정했지만, AWS Glue 작업을 실행하려고 하면 Amazon S3 VPC 게이트웨이 엔드포인트에 문제가 있다는 오류 메시지가 나타납니다. 데이터 엔지니어는 이 오류를 해결하고 AWS Glue 작업을 S3 버킷에 연결해야 합니다. 이 요구 사항을 충족하는 솔루션은 무엇일까요?
-
AAmazon S3 VPC 게이트웨이 엔드포인트에서 들어오는 트래픽을 허용하도록 AWS Glue 보안 그룹을 업데이트합니다.❌ 보안 그룹(Security Group) — 출입구 경비원. Gateway Endpoint에는 경비원이 없음. 보안 그룹은 Interface Endpoint(전용 직통 전화선)에만 붙는 개념. Gateway는 라우팅 테이블이 담당.
-
BAWS Glue 작업이 S3 버킷에 접근할 수 있도록 명시적으로 권한을 부여하는 S3 버킷 정책을 구성합니다.❌ S3 버킷 정책(Bucket Policy) — 창고 출입 명단. 문제에서 IAM(Identity and Access Management) 역할은 이미 설정됐다고 명시. 권한 문제가 아닌 네트워크 경로 문제. 명단 수정해봤자 길이 없으면 못 감.
-
CAWS Glue 작업 코드를 검토하여 AWS Glue 연결 세부 정보에 정규화된 도메인 이름이 포함되어 있는지 확인하십시오.❌ FQDN(Fully Qualified Domain Name) — 완전 정규화 도메인 이름 (예: s3.ap-northeast-2.amazonaws.com). Gateway Endpoint는 도메인이 아닌 Prefix List(IP 대역 묶음) 기반으로 라우팅. FQDN 수정은 이 오류와 무관.
-
DVPC의 라우팅 테이블에 Amazon S3 VPC 게이트웨이 엔드포인트에 대한 인바운드 및 아웃바운드 경로가 포함되어 있는지 확인합니다.✅ 라우팅 테이블(Routing Table) — 내비게이션 경로표. S3 Gateway Endpoint를 만들어도 VPC 서브넷의 라우팅 테이블에 "S3 → 엔드포인트" 경로가 등록되어야 트래픽이 흐름. 경로 없으면 차가 고속도로 무시하고 일반 인터넷으로 나가려다 차단 → 정확히 이 오류.
| 구분 | Gateway Endpoint | Interface Endpoint (PrivateLink) |
|---|---|---|
| 지원 서비스 | S3 DynamoDB | 그 외 대부분의 AWS 서비스 |
| 실생활 비유 | 🛣️ 전용 고속도로 내비게이션(라우팅 테이블)에 경로 등록 필수 |
📞 전용 직통 전화선(ENI) 경비원(보안 그룹)이 통제 |
| 트래픽 제어 | 라우팅 테이블 | 보안 그룹(Security Group) |
| 비용 | 무료 🎉 | 시간당 요금 💸 |
| 흔한 오류 원인 | 라우팅 테이블 경로 누락 | 보안 그룹 인바운드 차단 |
Gateway Endpoint (S3 · DynamoDB) → 라우팅 테이블 (내비게이션 경로)
Interface Endpoint (그 외 서비스) → 보안 그룹 (출입구 경비원)
"VPC 게이트웨이 엔드포인트 오류" = 라우팅 테이블 먼저 확인!AWS Lake Formation의 행 수준 보안(Row-Level Security)은 데이터 레이크에서 국가·부서별 접근 제어를 운영 부담 없이 구현하는 핵심 기능입니다. 테이블을 국가별로 나누거나 리전을 분리하지 않고도 단일 데이터셋에서 정책 기반으로 접근을 제한할 수 있어 DEA-C01 거버넌스·보안 도메인에서 자주 출제됩니다.
한 소매 회사가 아마존 S3 버킷에 고객 데이터 허브를 운영하고 있습니다. 여러 국가의 직원들이 이 데이터 허브를 사용하여 회사 전체의 분석을 지원합니다. 거버넌스 팀은 회사 데이터 분석가들이 자신과 같은 국가에 있는 고객의 데이터에만 접근할 수 있도록 해야 합니다. 이러한 요구 사항을 충족하면서 운영 노력을 최소화할 수 있는 솔루션은 무엇일까요?
-
A각 국가별 고객 데이터용 별도 테이블을 생성합니다. 각 분석가에게 담당 국가에 따라 해당 테이블에 대한 접근 권한을 부여합니다.❌ 🗂️ 국가별 서류함 따로 만들기. 국가가 늘어날 때마다 테이블 생성 → 권한 부여 작업이 반복됨. 운영 최소화와 반대 방향.
-
BAWS Lake Formation에서 S3 버킷을 데이터 레이크 위치로 등록합니다. Lake Formation의 행 수준 보안 기능을 사용하여 회사 액세스 정책을 적용합니다.✅ AWS Lake Formation — 데이터 레이크 중앙 거버넌스 서비스. 행 수준 보안(Row-Level Security, RLS) — 도서관 사서가 "이 직원은 한국 섹션만 열람 가능"이라고 출입증에 등록해두면 어느 책장을 열어도 자동 필터링되는 것. 데이터를 나누지 않고 정책 하나로 모든 접근을 제어. 국가 추가 시 조건값만 추가하면 끝.
-
C고객이 있는 국가와 가까운 AWS 리전으로 데이터를 이동합니다. 각 분석가에게 담당 국가에 따라 액세스 권한을 부여합니다.❌ 🌏 국가마다 창고 따로 짓기. 리전(Region) — AWS 물리 데이터센터 지역 단위. 리전별 데이터 이동 시 복제 비용 + 동기화 운영 발생. 접근 제어 문제를 인프라 분리로 해결하는 과도한 방법.
-
D데이터를 Amazon Redshift에 로드합니다. 각 국가별 뷰를 생성합니다. 각 국가의 데이터에 접근할 수 있도록 각 국가별로 별도의 IAM 역할을 생성합니다. 분석가에게 적절한 역할을 할당합니다.❌ Amazon Redshift — 완전 관리형 클라우드 데이터 웨어하우스. 기술적으로 작동하지만 국가 추가 시마다 뷰 생성 → IAM(Identity and Access Management) 역할 생성 → 역할 매핑 3단계 반복. 운영 최소화 기준 미달.
| 방법 | 실생활 비유 | 국가 추가 시 | 운영 부담 |
|---|---|---|---|
| A. 국가별 테이블 분리 | 🗂️ 국가별 서류함 따로 | 테이블 + 권한 매번 신규 생성 | 높음 |
| B. Lake Formation RLS | 🏢 출입증에 층별 권한 내장 | 정책 조건값만 추가 | 낮음 ✓ |
| C. 리전별 데이터 이동 | 🌏 국가마다 창고 따로 짓기 | 리전 인프라 전체 복제 | 매우 높음 |
| D. Redshift 뷰 + IAM 역할 | 📋 열람신청서 + 직원증 따로 발급 | 뷰 + IAM 역할 + 매핑 반복 | 중간~높음 |
"국가·부서별 행 단위 접근 제어 + 운영 최소화" → Lake Formation RLS
데이터를 쪼개지 말고, 정책으로 필터링하자.
테이블 / 리전 / IAM 역할을 국가별로 늘리면 = 운영 부담 증가 = 오답AWS Data Exchange는 타사(3rd-party) 데이터셋을 AWS 환경에 직접 구독·통합할 수 있는 데이터 마켓플레이스입니다. 별도 파이프라인 구축 없이 구독 즉시 S3로 전달되기 때문에 운영 오버헤드가 가장 낮으며, DEA-C01에서 "타사 데이터 + 운영 최소화" 조합으로 자주 출제됩니다.
한 미디어 회사가 사용자 행동 및 선호도에 기반하여 고객에게 미디어 콘텐츠를 추천하는 시스템을 개선하고자 합니다. 추천 시스템 개선을 위해 회사는 기존 분석 플랫폼에 타사 데이터 세트의 인사이트를 통합해야 합니다. 회사는 타사 데이터 세트를 통합하는 데 필요한 노력과 시간을 최소화하고자 합니다. 이러한 요구 사항을 충족하면서 운영 오버헤드를 최소화하는 솔루션은 무엇일까요?
-
AAPI 호출을 사용하여 AWS Data Exchange의 타사 데이터 세트에 액세스하고 통합합니다.✅ AWS Data Exchange — 타사 데이터 마켓플레이스. 마트에서 완제품을 사는 것처럼, 수백 개 데이터 공급자의 데이터셋을 구독 즉시 S3로 자동 전달받는 서비스. 파이프라인 구축·계약 협상·전송 인프라 관리 불필요. 타사 데이터 통합에 특화된 유일한 AWS 서비스.
-
BAWS DataSync에서 타사 데이터 세트에 액세스하고 통합하려면 API 호출을 사용하십시오.❌ AWS DataSync — 온프레미스 ↔ AWS 스토리지 간 대용량 파일 자동 동기화 트럭. NAS·NFS·SMB 같은 내부 파일 시스템을 S3/EFS로 이전·동기화하는 서비스. 외부 타사 데이터 마켓플레이스 접근 기능 없음.
-
CAmazon Kinesis Data Streams를 사용하여 AWS CodeCommit 리포지토리의 타사 데이터 세트에 액세스하고 통합합니다.❌ AWS CodeCommit — 소스 코드 저장소(Git 서버). Amazon Kinesis Data Streams — 실시간 스트리밍 데이터 컨베이어 벨트. 코드 저장소에 타사 데이터셋이 있을 이유가 없고, Kinesis는 실시간 이벤트 스트림 전용. 둘 다 이 시나리오와 무관.
-
DAmazon Kinesis Data Streams를 사용하여 Amazon Elastic Container Registry(Amazon ECR)의 타사 데이터 세트에 액세스하고 통합합니다.❌ Amazon ECR(Elastic Container Registry) — 도커 컨테이너 이미지 창고. 컨테이너 이미지(앱 실행 패키지)를 저장하는 곳이지 데이터셋 저장소가 아님. 타사 데이터 통합과 전혀 관련 없음.
| 서비스 | 실생활 비유 | 주 용도 | 타사 데이터? |
|---|---|---|---|
| AWS Data Exchange | 🛒 외부 데이터 마트 | 타사 데이터셋 구독 → S3 자동 전달 | ✓ 전용 |
| AWS DataSync | 🚛 사내 창고 이사 트럭 | 온프레미스 파일시스템 → S3/EFS 동기화 | ✗ 무관 |
| Amazon AppFlow | 🤝 SaaS 앱 자동 동기화 파이프 | Salesforce·Slack 등 SaaS ↔ S3 연동 | ✗ SaaS 전용 |
| Kinesis Data Streams | 🏭 실시간 컨베이어 벨트 | 클릭·로그·센서 실시간 스트림 수집 | ✗ 무관 |
"타사(3rd-party) 데이터셋 + 운영 최소화" → AWS Data Exchange
DataSync = 사내 파일 이사 트럭 (온프레미스 → AWS)
AppFlow = SaaS 앱 동기화 (Salesforce, Slack 등)
Kinesis = 실시간 이벤트 스트림 (클릭, 로그, 센서)데이터 메시(Data Mesh)는 도메인별로 데이터를 분산 소유하면서 중앙에서 거버넌스를 통제하는 아키텍처입니다. AWS에서 구현할 때는 S3 + Athena(분산 저장·쿼리)와 Lake Formation(중앙 거버넌스·접근 제어) 조합이 핵심입니다.
한 금융 회사가 데이터 메시를 구축하려고 합니다. 이 데이터 메시는 중앙 집중식 데이터 거버넌스, 데이터 분석 및 데이터 접근 제어를 지원해야 합니다. 회사는 데이터 카탈로그 및 ETL(추출, 변환, 로드) 작업에 AWS Glue를 사용하기로 결정했습니다. 어떤 AWS 서비스 조합을 사용해야 데이터 메시를 구현할 수 있을까요?
-
A데이터 저장에는 Amazon Aurora를 사용하고, 데이터 분석에는 Amazon Redshift 프로비저닝 클러스터를 사용하십시오.❌ Amazon Aurora — 완전 관리형 관계형 DB(트랜잭션 처리용). Redshift 프로비저닝 클러스터 — 중앙 집중식 데이터 웨어하우스. 둘 다 중앙 집중식 구조라 데이터 메시의 "도메인별 분산 소유" 철학과 맞지 않음.
-
B데이터 저장에는 Amazon S3를 사용하고, 데이터 분석에는 Amazon Athena를 사용하십시오.✅ Amazon S3(Simple Storage Service) — 무한 확장 객체 저장소. 각 도메인팀이 자기 버킷을 독립 소유 가능. Amazon Athena — S3 위에서 SQL을 바로 실행하는 서버리스 쿼리 엔진. Glue Data Catalog와 네이티브 연동. 데이터를 옮기지 않고 제자리에서 분석 → 데이터 메시의 분산 소유 + 중앙 쿼리 구조에 최적.
-
C중앙 집중식 데이터 관리 및 액세스 제어를 위해 AWS Glue DataBrew를 사용합니다.❌ AWS Glue DataBrew — 노코드(No-Code) 시각적 데이터 정제 도구. 요리사가 레시피 보며 재료 손질하는 것. 데이터 프로파일링·클렌징·변환을 GUI로 하는 도구이지, 거버넌스·접근 제어 서비스가 아님. 이름에 Glue가 들어가서 헷갈리기 쉬운 함정 보기.
-
D데이터 저장에는 Amazon RDS를 사용하고, 데이터 분석에는 Amazon EMR을 사용하십시오.❌ Amazon RDS(Relational Database Service) — 관계형 DB 관리 서비스. Amazon EMR(Elastic MapReduce) — EC2 기반 Spark/Hadoop 클러스터. RDS는 트랜잭션 DB라 데이터 메시 스토리지에 부적합. EMR은 클러스터 관리 부담이 크고 Glue Catalog와의 통합이 Athena보다 복잡.
-
E중앙 집중식 데이터 관리 및 액세스 제어를 위해 AWS Lake Formation을 사용하십시오.✅ AWS Lake Formation — 데이터 레이크 중앙 거버넌스 서비스. 건물 전체 출입 관리 시스템. Glue Data Catalog 위에서 테이블·컬럼·행 단위 접근 제어를 한곳에서 관리. 각 도메인팀은 데이터를 분산 소유하면서 거버넌스는 Lake Formation이 중앙 통제 → 데이터 메시 핵심 요건 충족.
| 역할 | 서비스 | 비유 | 데이터 메시 적합? |
|---|---|---|---|
| 분산 저장 | Amazon S3 | 🗄️ 도메인별 독립 창고 | ✓ 최적 |
| 서버리스 분석 | Amazon Athena | 🔍 창고에서 직접 검색 | ✓ 최적 |
| 중앙 거버넌스 | AWS Lake Formation | 🏢 건물 출입 관리 시스템 | ✓ 최적 |
| 중앙 웨어하우스 | Redshift | 🏛️ 단일 대형 도서관 | ✗ 중앙집중식 |
| 데이터 정제 GUI | Glue DataBrew | 🧑🍳 노코드 재료 손질 도구 | ✗ 거버넌스 아님 |
데이터 메시 = 분산 소유 + 중앙 거버넌스
저장·분석 → S3 + Athena (분산, 서버리스, Glue Catalog 연동)
거버넌스 → Lake Formation (중앙 접근 제어, 행·컬럼 단위 보안)
Glue DataBrew ≠ 거버넌스 (노코드 데이터 정제 도구일 뿐)AWS Lambda 레이어(Layer)는 여러 Lambda 함수가 공유하는 코드·라이브러리를 한 곳에서 관리하는 기능입니다. 공통 스크립트를 레이어로 패키징하면 레이어 한 번 수정으로 연결된 모든 함수에 즉시 반영되어, DEA-C01에서 Lambda 코드 중복 제거 및 유지보수 효율화 문제로 자주 출제됩니다.
데이터 엔지니어는 여러 AWS Lambda 함수에서 사용하는 데이터 포맷팅 프로세스를 수행하는 사용자 지정 Python 스크립트를 관리합니다. 데이터 엔지니어가 Python 스크립트를 수정해야 할 경우, 모든 Lambda 함수를 수동으로 업데이트해야 합니다. 데이터 엔지니어는 Lambda 함수를 보다 간편하게 업데이트할 수 있는 방법을 원합니다. 이 요구 사항을 충족하는 솔루션은 무엇일까요?
-
A사용자 지정 Python 스크립트에 대한 포인터를 Amazon S3 공유 버킷의 실행 컨텍스트 객체에 저장합니다.❌ 실행 컨텍스트(Execution Context) — Lambda 함수가 실행될 때 생성되는 임시 런타임 환경. 호출 간 재사용될 수 있지만 영구 저장소가 아님. 여기에 포인터를 저장해도 함수마다 컨텍스트가 분리되어 공유가 안 됨.
-
B사용자 지정 Python 스크립트를 Lambda 레이어로 패키징합니다. Lambda 레이어를 Lambda 함수에 적용합니다.✅ Lambda 레이어(Lambda Layer) — 여러 Lambda 함수가 공유하는 공통 코드 패키지. 건물 공용 화장실처럼 한 번 설치하면 모든 층(함수)이 사용. Python 스크립트를 레이어로 올리고 각 함수에 연결하면 레이어만 새 버전으로 업데이트하면 끝. 함수 코드는 손댈 필요 없음.
-
C사용자 지정 Python 스크립트에 대한 포인터를 공유 Amazon S3 버킷의 환경 변수에 저장합니다.❌ 환경 변수(Environment Variable) — Lambda 함수 설정에 key-value로 저장하는 구성값. 환경 변수는 각 Lambda 함수에 개별 설정되는 값. "S3에 있는 환경 변수"라는 개념 자체가 없고, 함수마다 일일이 수정해야 해서 문제가 그대로.
-
D각 Lambda 함수에 동일한 별칭을 지정합니다. 함수의 별칭을 지정하여 각 Lambda 함수를 호출합니다.❌ Lambda 별칭(Alias) — 특정 함수 버전을 가리키는 포인터 이름표. "prod", "dev" 같은 별칭으로 버전 전환에 사용. 배포 버전 관리·트래픽 분산용 기능이지, 공통 코드를 여러 함수에 공유하는 기능이 아님.
| 기능 | 실생활 비유 | 주 용도 | 코드 공유? |
|---|---|---|---|
| Lambda Layer | 🏢 건물 공용 시설 | 공통 코드·라이브러리 여러 함수에 공유 | ✓ 전용 |
| Lambda Alias | 🏷️ 버전 이름표 | prod/dev 버전 전환, 트래픽 분산 | ✗ 무관 |
| 환경 변수 | 📝 함수별 메모장 | 함수별 설정값(API 키, 경로 등) 저장 | ✗ 함수별 개별 |
| 실행 컨텍스트 | ⚡ 임시 작업 공간 | 호출 간 DB 연결 등 재사용 최적화 | ✗ 임시·함수별 |
"여러 Lambda 함수에서 공통 코드 공유" → Lambda Layer
Layer = 건물 공용 시설 (한 번 설치, 모든 함수 사용)
Alias = 버전 이름표 (prod ↔ dev 전환용)
환경변수 = 함수별 메모장 (공유 안 됨, 각자 설정)
레이어 업데이트 → 연결된 함수 전체에 즉시 반영!'Stack > AWS' 카테고리의 다른 글
| [AWS DEA] 개념정리 - Domain4 데이터 보안 및 거버넌스 (0) | 2026.03.20 |
|---|---|
| [AWS DEA] 개념정리 - Domain3 데이터 운영 및 지원 (1) | 2026.03.20 |
| [AWS DEA] 개념정리 - Domain2 데이터 스토어 관리 (0) | 2026.03.20 |
| [AWS DEA] 개념정리 - Domain1 데이터 수집·변환·오케스트레이션 (0) | 2026.03.20 |
| [AWS DEA] 실생활 비유로 전체 그림 잡기 (1) | 2026.03.18 |
