데이터 레이크가 조직 전체로 퍼지면 곧바로 두 가지 문제가 터진다. 첫째는 권한이다. S3에 모든 데이터를 모았는데, 영업팀은 PII 컬럼을 보면 안 되고, 한국 지사는 한국 region 행만 봐야 하고, 새 테이블이 추가될 때마다 누구에게 권한을 줄지 일일이 손으로 관리하기 시작하면 거버넌스가 무너진다. 둘째는 실시간성이다. 배치로 하루 한 번 적재하던 데이터를 "초 단위로 흘러들어오는 스트림"으로 다뤄야 할 때, 어떤 스트림 플랫폼을 어떻게 운영하느냐가 아키텍처를 가른다.
SAP-C02 시험에서 이 영역은 "S3 버킷 정책·IAM만으로는 풀 수 없는 행·열·셀 단위 권한", "여러 AWS 계정이 하나의 데이터 레이크를 공유하는 cross-account 패턴", "Kafka 표준이 필요한 조직의 스트림 선택", "수만 TPS 스트림의 운영 부담 최소화" 같은 거버넌스·스트리밍 아키텍처로 출제된다. 오늘은 Lake Formation의 권한 모델이 IAM과 어떻게 다른지, MSK가 Kafka를 어떻게 매니지드로 감싸는지를 내부 원리부터 분해한다.
데이터 레이크 권한을 IAM과 S3 버킷 정책으로만 다루면 곧 한계에 부딪힌다. IAM 정책은 "이 역할은 이 버킷/객체에 접근 가능"이라는 객체 수준까지만 표현한다