[Snowflake 101] Day 1: RDBMS와는 다르다, Snowflake 아키텍처의 비밀

데이터 파이프라인(Airflow)을 구축하고, 데이터를 가공(dbt)하는 방법을 다뤘다. 이제 그 데이터가 최종적으로 안착할 곳, ‘데이터 웨어하우스(Data Warehouse)’에 대해 이야기할 차례다.

모던 데이터 스택(Modern Data Stack)에서 데이터 웨어하우스는 단순한 저장소가 아니다. 모든 비즈니스 로직이 실행되는 엔진이다. 그중에서도 현재 엔터프라이즈 시장에서 가장 표준에 가깝게 자리 잡은 Snowflake(스노우플레이크)를 다룬다.

시리즈의 첫 날인 오늘은, 왜 우리가 기존의 DB(MySQL, PostgreSQL)가 아닌 DW를 써야 하는지, 그리고 Snowflake가 기술적으로 무엇이 다른지 구조(Architecture)를 뜯어본다.

1. OLTP vs OLAP: 왜 별도의 저장소가 필요한가?

개발자들이 흔히 하는 실수가 있다. 서비스 운영 DB(Production DB)에 분석 쿼리를 날리는 것이다.

“지난달 매출 합계 좀 뽑아주세요.”

이 요청을 수행하기 위해 운영 DB에서 SELECT SUM(amount) ...를 실행하는 순간, 서비스 속도는 느려지고 심하면 장애가 발생한다. 이는 DB의 설계 목적이 다르기 때문이다.

• OLTP (Online Transaction Processing): MySQL, PostgreSQL 등. ‘행(Row)’ 단위의 데이터 생성, 수정, 삭제가 빠르다. 특정 유저의 프로필을 조회하는 데 최적화되어 있다.
• OLAP (Online Analytical Processing): Snowflake, BigQuery, Redshift 등. ‘열(Column)’ 단위의 대용량 집계가 빠르다. 수억 건의 데이터에서 특정 컬럼의 평균을 구하는 데 최적화되어 있다.

분석을 하려면 분석 전용 DB, 즉 데이터 웨어하우스가 필요하다. 여기까지는 일반적인 이야기다.

2. 기존 DW의 한계와 Snowflake의 등장

Snowflake 이전의 데이터 웨어하우스(전통적인 On-premise나 초기 Redshift 등)는 ‘Shared Nothing’ 아키텍처를 주로 사용했다. 쉽게 말해 저장소(Storage)와 연산(Compute)이 한 몸으로 묶여 있었다.

이 구조의 단점은 명확하다.

1. 확장의 비효율: 데이터 용량만 늘리고 싶은데, 불필요하게 비싼 CPU(Compute)까지 증설해야 한다. 반대도 마찬가지다.
2. 동시성(Concurrency) 문제: 마케팅팀에서 무거운 쿼리를 돌리면, 재무팀의 대시보드가 멈춘다. 자원을 공유해서 쓰기 때문이다.

Snowflake는 이 문제를 ‘Multi-Cluster Shared Data’ 아키텍처로 해결했다. 핵심은 Storage와 Compute의 완전한 분리다.

3. Snowflake 3계층 아키텍처

Snowflake의 구조는 크게 세 가지 계층으로 나뉜다. 이 그림을 이해하는 것이 Snowflake 비용 최적화의 시작이다.

3.1. Database Storage (저장소)

데이터가 실제로 저장되는 곳이다.

• AWS S3, Azure Blob, Google Cloud Storage 같은 저렴한 Object Storage를 기반으로 한다.
• 사용자는 파일 시스템을 신경 쓸 필요가 없다. Snowflake가 데이터를 자체적인 압축 포맷(Micro-partitions)으로 변환하여 관리한다.
• 특징: 용량은 무제한이며, 쓴 만큼만(TB당) 비용을 낸다.

3.2. Query Processing (연산 - Virtual Warehouses)

실제 쿼리를 수행하는 ‘근육’이다. Snowflake에서는 이를 Virtual Warehouse(가상 웨어하우스)라고 부른다.

• Storage와 분리되어 있기 때문에 필요할 때만 켜서 쓰고, 안 쓸 때는 끌 수 있다.
• 각 부서(팀)마다 별도의 Warehouse를 할당할 수 있다. 즉, 마케팅팀이 쿼리를 아무리 무겁게 돌려도 데이터팀의 ETL 작업에는 전혀 영향을 주지 않는다.

3.3. Cloud Services (두뇌)

사용자가 직접 제어하지 않는 관리 계층이다.

• 인증 및 접근 제어: 누가 로그인했고 어떤 권한이 있는지 확인한다.
• 메타데이터 관리: 어떤 테이블이 어디에 저장되어 있는지 정보를 관리한다.
• Optimizer: 쿼리를 가장 효율적으로 수행할 경로를 계산한다.

4. 아키텍처가 가져온 변화

이러한 구조적 차이는 실무에서 다음과 같은 이점으로 나타난다.

1. 탄력성: 월말 정산처럼 부하가 클 때만 Warehouse 사이즈를 X-Large로 키우고, 작업이 끝나면 X-Small로 줄이거나 끌 수 있다. (Instant Elasticity)
2. 데이터 공유의 용이성: 데이터는 하나(Shared Storage)지만, 이를 조회하는 컴퓨팅은 여러 개다. 데이터를 복제(Copy)해서 줄 필요 없이 권한만 주면 된다.
3. 유지보수 제로: 인덱스 생성, 파티셔닝, 진공 청소(Vacuum) 등의 튜닝 작업이 거의 필요 없다. 마이크로 파티션 단위로 Snowflake가 알아서 최적화한다.

Summary

Snowflake는 클라우드 네이티브 환경에 맞춰 저장소와 연산을 분리한 아키텍처를 채택했다. 이를 통해 성능 간섭 없는 동시 작업과 비용 효율적인 확장이 가능하다.

하지만 “비용 효율적”이라는 말은 “관리를 잘했을 때”만 유효하다. 무턱대고 켜놓은 웨어하우스는 클라우드 비용 폭탄의 주범이 된다.