데이터 레이크라는 단어는 묘하게 낭만적이다. "모든 데이터를 한곳에 던져두면 나중에 필요할 때 꺼내 쓴다"는 약속은 깔끔하게 들린다. 그런데 production에서 데이터 레이크를 운영해 본 사람은 안다. 잘못 설계한 레이크는 "데이터 늪(data swamp)"이 되고, 누구도 스키마를 모르고, Athena 쿼리 한 번에 $40씩 청구되며, 작은 파일 수백만 개가 S3 LIST 비용만 매달 수백 달러씩 먹는다. 데이터 레이크의 진짜 기술은 "데이터를 어디에 던지느냐"가 아니라 "어떤 포맷으로, 어떻게 파티셔닝해서, 어떤 메타데이터 카탈로그로 묶느냐"에 있다.
SAP-C02 시험에서 데이터 레이크는 분석(Analytics) 도메인의 중심이다. 단순히 "S3에 저장하고 Athena로 쿼리한다" 수준의 문제는 거의 없다. 대부분은 "페타바이트급 로그를 가장 비용 효율적으로 쿼리하는 방법", "여러 계정·여러 팀이 같은 데이터 레이크를 안전하게 공유하는 거버넌스", "스트리밍과 배치를 하나의 카탈로그로 통합하는 아키텍처" 같은 운영·비용·거버넌스 관점이다. 오늘은 그 관점을 만드는 내부 동작을 본다. 왜 Parquet이 비용을 90% 줄이는지, Athena가 실제로 S3에서 무엇을 스캔하는지, Glue Catalog가 어떻게 Hive Metastore의 유산을 이어받았는지를 분해한다.