본문으로 건너뛰기

Snowflake 아키텍처 설명, 그리고 어디에 쓰이는가

Snowflake는 스토리지, 컴퓨트, 조율을 세 개의 분리된 계층으로 유지하는 클라우드 데이터 플랫폼입니다. 이 아키텍처가 어떻게 작동하는지, 기업이 무엇에 쓰는지, 어디에는 맞지 않는지 설명합니다.

작업대와 천장 크레인이 있는 밝은 엔지니어링 조립 공장의 넓은 전경
목차
  1. 한 문단으로 보는 Snowflake
  2. Snowflake 아키텍처의 세 계층
  3. 스토리지
  4. 컴퓨트: 가상 웨어하우스
  5. 클라우드 서비스
  6. 아키텍처에서 나오는 기능
  7. Iceberg, 카탈로그, 하이브리드 테이블, Postgres: Snowflake가 향한 곳
  8. 규제 산업을 위한 에디션과 보안
  9. Snowflake는 어디에 쓰이고, 어디에는 이상적이지 않을까요
  10. 스노우플레이크 스키마 vs 스타 스키마: 다른 이야기입니다
  11. 제가 시작할 곳
  12. 자주 묻는 질문

Snowflake 아키텍처는 데이터 플랫폼을 독립적으로 확장되는 세 계층으로 나눕니다. 스토리지, 컴퓨트(가상 웨어하우스라고 부릅니다), 그리고 모든 것을 조율하는 클라우드 서비스 계층입니다. 기업은 Snowflake를 리포팅과 분석을 위한 클라우드 데이터 웨어하우스로 쓰며, 점점 더 데이터를 공유하고 Python을 실행하고 거버넌스가 적용된 데이터 위에 AI를 구축하는 곳으로도 씁니다.

스토리지와 컴퓨트를 분리한다는 그 하나의 설계 선택이 Snowflake가 잘하는 것의 대부분과 비용의 대부분을 설명합니다.

저는 제조와 방위 산업의 데이터 플랫폼 프로그램에서 Snowflake를 다뤄 왔습니다. 자주 보는 패턴이 있습니다. 경영진은 분석 때문에 Snowflake를 사고, 그다음에야 아키텍처 결정(웨어하우스를 몇 개 둘지, 어떤 에디션인지, 데이터가 어디에 있는지)이 청구서와 컴플라이언스 상태를 결정한다는 것을 알게 됩니다. 이 가이드는 계약 전에 그런 결정을 이해해야 하는 CIO, CDO, 아키텍트를 위한 글입니다.

Snowflake는 Amazon Web Services, Microsoft Azure, Google Cloud에서 실행되는 완전 관리형 데이터 플랫폼입니다. 설치하거나 패치하거나 인덱스를 튜닝할 필요가 없습니다. 데이터를 적재하고, SQL(또는 Python)을 작성하고, 스토리지와 컴퓨트 비용을 따로 냅니다.

Snowflake는 자사 설계를 공유 디스크와 비공유(shared-nothing) 아키텍처의 하이브리드라고 설명합니다. 데이터는 중앙 저장소 하나에 있고, 독립적인 컴퓨트 클러스터들이 이를 쿼리합니다. 방위 산업 구매자에게 일찍부터 중요한 사실이 하나 있습니다. Snowflake 자체 핵심 개념 및 아키텍처 가이드에 따르면, Snowflake는 로컬이나 프라이빗 클라우드 인프라에 설치할 수 없습니다.

아래에서 위로 쌓인 구성은 다음과 같습니다.

계층별로 보는 Snowflake 아키텍처스토리지와 컴퓨트는 따로 확장되고 따로 청구됩니다. 클라우드 서비스가 전체를 묶어 줍니다.
  1. 클라우드 서비스보안, 접근 통제, 메타데이터, 쿼리 최적화, 트랜잭션
  2. 컴퓨트가상 웨어하우스: SQL과 Python을 실행하는 독립 클러스터, 실행 중에만 크레딧으로 청구
  3. 스토리지클라우드 오브젝트 스토리지의 압축된 컬럼형 마이크로 파티션, TB 단위로 청구

스토리지

데이터를 적재하면 Snowflake는 이를 압축된 컬럼형 포맷으로 재구성해 클라우드 오브젝트 스토리지에 저장합니다. 모든 테이블을 마이크로 파티션으로 나누며, 각 파티션에는 압축 전 기준 50MB에서 500MB의 데이터가 담깁니다. Snowflake는 파티션마다 모든 열의 값 범위 같은 메타데이터를 기록합니다.

그 메타데이터가 영리한 부분입니다. 지난달 생산 오더로 필터링한 쿼리는 날짜 범위가 맞을 수 없는 마이크로 파티션을 모두 건너뜁니다.

이를 프루닝이라고 하며, Snowflake가 인덱스 없이도 성능이 좋은 이유입니다. 또한 매우 큰 테이블에서는 데이터가 도착하는 방식(날짜나 공장 순으로 정렬되어 있는지, 무작위인지)이 비용에 영향을 준다는 뜻이기도 합니다.

컴퓨트: 가상 웨어하우스

가상 웨어하우스는 쿼리와 코드를 실행하는 컴퓨트 클러스터입니다. 각각 독립적입니다. 재무의 월말 리포트를 한 웨어하우스에서 돌리는 동안 데이터 과학 팀이 다른 웨어하우스에서 무거운 작업을 돌려도, 서로 느려지지 않습니다.

웨어하우스는 티셔츠 사이즈처럼 크기가 나뉘며 실행 중일 때만 크레딧을 소모합니다. 유휴 상태가 되면 자동으로 일시 중지될 수 있습니다. 크기가 클수록 개별적인 무거운 쿼리가 빨라집니다.

클러스터가 많을수록 더 많은 사용자를 동시에 처리하며, 이것이 멀티 클러스터 웨어하우스의 역할입니다. Enterprise 에디션 이상에서는 쿼리가 대기하기 시작하면 웨어하우스가 클러스터를 자동으로 추가하고, 부하가 줄면 제거합니다. Snowflake는 멀티 클러스터가 동시성에 도움이 될 뿐, 느린 쿼리 하나를 빠르게 하지는 않는다고 분명히 밝힙니다. 그럴 때는 크기를 바꿉니다.

비용 측면은 Snowflake 크레딧과 청구서를 좌우하는 요인에 관한 제 가격 가이드에서 자세히 다룹니다.

클라우드 서비스

최상위 계층은 인증, 접근 통제, 메타데이터, 쿼리 최적화, 트랜잭션을 처리합니다. Time Travel과 클로닝은 대부분 메타데이터 작업이므로 이 계층이 그것을 가능하게 합니다. 이 계층을 의식할 일은 거의 없으며, 바로 그것이 핵심입니다.

흥미로운 기능들은 덧붙인 것이 아닙니다. 스토리지와 메타데이터 설계에서 자연스럽게 나옵니다.

  1. Time Travel. 과거 특정 시점의 데이터를 쿼리하고, 복제하고, 복원할 수 있습니다. Standard 에디션은 1일을 보관합니다. Time Travel 문서에 따르면 Enterprise 이상은 영구 테이블에 대해 최대 90일까지 보관할 수 있습니다.
  2. Fail-safe. Time Travel 기간이 끝나면 영구 테이블 데이터는 7일간의 Fail-safe 기간으로 넘어갑니다. 복구는 Snowflake만 할 수 있습니다. 귀사가 통제하는 백업이 아니라 재해 복구 수단으로 취급하십시오.
  3. 제로 카피 클로닝. 테이블, 스키마, 데이터베이스의 클론은 같은 마이크로 파티션을 가리키므로 생성 시점에는 추가 스토리지를 쓰지 않습니다. 이후 변경되는 데이터에 대해서만 비용을 냅니다. 팀이 몇 분 만에 실물 크기의 테스트 환경을 띄우는 방법이 이것입니다.
  4. 보안 데이터 공유. 제공자가 다른 Snowflake 계정과 실시간 테이블을 공유하며, 데이터는 복사되지 않습니다. 소비자는 쿼리에 사용한 컴퓨트 비용만 냅니다. 직접 공유는 한 리전 안에서 작동하며, 리전 간 공유는 자동 이행 기능이 있는 리스팅을 거칩니다.
  5. Snowflake Marketplace. 리스팅을 통해 특정 파트너에게 또는 공개적으로 데이터 제품을 게시할 수 있으며, 날씨나 시장 지수 같은 서드파티 데이터도 포함됩니다.
  6. Snowpark. 데이터를 밖으로 꺼내는 대신 처리를 Snowflake 안으로 밀어 넣는 Python, Java, Scala 라이브러리입니다. 데이터 옆에서 컨테이너화된 앱을 실행하는 Snowpark Container Services는 세 클라우드 모두의 상용 리전에서 정식 제공되고 있습니다.

제조업체라면 보안 데이터 공유는 파일럿해 볼 가치가 있습니다. 출발점은 현실적으로 보십시오. 제가 보는 공급업체 데이터 교환 대부분은 아직 파일 전송입니다.

거버넌스가 적용된 테이블을 공유하는 편이 더 깔끔하고, 공유를 철회할 수도 있습니다. 공급업체 하나와 데이터 세트 하나로 시작해, 더 계획하기 전에 효과를 증명하십시오.

예전에 Snowflake는 "Snowflake 포맷으로 된 귀사의 데이터"를 뜻했습니다. 그것이 바뀌었고, 이름도 바뀌었습니다. 2026년 10월 현재 상태입니다.

기능하는 일상태(2026년 10월)
Apache Iceberg 테이블개방형 Iceberg 포맷으로 귀사 또는 Snowflake의 클라우드 스토리지에 저장된 데이터2024년 6월부터 GA, Snowflake 관리형 스토리지 옵션은 2026년 6월 GA(상용 AWS 및 Azure)
Snowflake Horizon CatalogApache Polaris 기반의 거버넌스 및 카탈로그, 외부 엔진이 Iceberg REST API로 Snowflake 관리형 Iceberg 테이블을 읽음신규 고객에게 권장
Snowflake Open Catalog관리형 Apache Polaris 서비스(이전 Polaris Catalog)GA지만 신규 고객은 받지 않음, 기존 사용자는 계속 사용 가능
하이브리드 테이블(Unistore)분석 옆에서 저지연 트랜잭션 조회를 위한 행 기반 테이블상용 AWS 및 Azure 리전에서만 GA
Snowflake PostgresSnowflake 플랫폼 안의 완전 관리형 PostgreSQL2026년 2월 24일부터 AWS와 Azure에서 GA

실무적인 결론은 이렇습니다. Iceberg 테이블을 쓰면 Spark, Databricks 등 다른 엔진이 Snowflake가 쿼리하는 바로 그 파일로 작업할 수 있어 종속이 줄어듭니다. Snowflake의 Open Catalog 개요는 이제 신규 고객에게 대신 Horizon Catalog를 쓰라고 안내합니다.

누군가 하이브리드 테이블을 운영 데이터베이스로 내세우기 전에 그 한계를 읽으십시오. 데이터베이스당 하이브리드 테이블 데이터는 2TB로 제한되며, Fail-safe, 데이터 공유, 복제, 스트림을 지원하지 않습니다. 애플리케이션 조회 테이블로는 괜찮습니다.

운영 데이터베이스는 아닙니다. 애플리케이션이 분석 옆에 운영 데이터베이스를 필요로 한다면, 2026년 2월에 Snowflake Postgres가 정식 제공되었으며 이쪽이 더 정직한 선택입니다.

Snowflake 비용상의 놀라움 대부분은 아무도 문서로 남기지 않은 아키텍처 결정입니다.

Snowflake는 네 가지 에디션을 판매합니다. Standard, Enterprise, Business Critical, Virtual Private Snowflake(VPS)입니다. 에디션이 어떤 보안 기능을 받을지 결정하며, 크레딧 가격도 에디션에 따라 올라갑니다.

기능StandardEnterpriseBusiness CriticalVPS
Time Travel1일최대 90일최대 90일최대 90일
멀티 클러스터 웨어하우스아니요예예예
Tri-Secret Secure(고객 관리형 키)아니요아니요예예
프라이빗 연결(AWS PrivateLink, Azure Private Link, Google Private Service Connect)아니요아니요예예
HIPAA 및 PCI DSS 지원아니요아니요예예
전용 환경, 하드웨어 비공유아니요아니요아니요예

Tri-Secret Secure는 Snowflake 키와 귀사가 클라우드 사업자의 키 관리 서비스에 보관하는 키를 결합합니다. 귀사 키를 철회하면 Snowflake는 더 이상 데이터를 복호화할 수 없습니다. 방위 산업과 항공우주 공급업체에게는 이 통제가 어떤 분석 기능보다 중요합니다.

미국 정부 업무를 위해 Snowflake는 AWS GovCloud와 Azure Government에서 SnowGov 리전을 운영하며, 미국 정부 고객과 계약업체에 개방되어 있습니다. Snowflake의 지원 리전 페이지에는 해당 리전의 FedRAMP High, Impact Level 4, ITAR 지원과 AWS 리전 한 곳의 Impact Level 5가 나와 있으며, Business Critical 이상의 에디션이 필요합니다. 기능 제공 여부는 리전별로 확인하십시오. Open Catalog, 하이브리드 테이블, Snowpark Container Services 일부는 모든 정부 리전에서 제공되지는 않습니다.

제가 참여한 방위 산업 프로그램에서 첫 질문은 결코 "얼마나 빠른가"가 아니었습니다. "데이터가 어디에 있고, 누가 볼 수 있으며, 그것을 감사인에게 증명할 수 있는가"였습니다. 올바른 리전과 에디션이라면 Snowflake는 여기에 잘 답합니다.

자사 건물 안에 머물러야 하는 데이터에 대해서는 답할 수 없습니다. 온프레미스 처리가 필요한 기밀 또는 수출 통제 워크로드에는 다른 플랫폼이 필요하며, Snowflake는 비기밀 영역을 맡게 됩니다.

제가 보는 사례 대부분은 몇 가지 패턴으로 나뉩니다.

  1. 전사 리포팅과 BI. ERP 데이터(SAP, Oracle, Microsoft Dynamics 365)를 바탕으로 한 재무, 영업, 운영 리포팅이며, 그 위에 Power BI, Tableau 등이 올라갑니다. 지금도 핵심 용도입니다. 추출 방법은 제 ERP 데이터를 Snowflake로 가져오기 가이드에서 다룹니다.
  2. 제조 운영 데이터. 제가 본, Snowflake에 적재된 공장 및 운영 데이터는 생산 계획 데이터입니다. 히스토리안, MES, 품질, 정비 데이터를 그 옆에 둘 수 있으며, JSON 형식의 반정형 센서 데이터도 네이티브로 적재됩니다.
  3. 파트너와의 데이터 공유. 공급업체, 유통업체, 고객이 거버넌스가 적용된 테이블을 직접 쿼리할 수 있습니다. 실제로 제가 보는 공급업체 교환 대부분은 아직 파일 전송입니다.
  4. 거버넌스가 적용된 데이터 위의 데이터 과학과 AI. Snowpark를 통한 Python과 Snowflake의 AI 서비스이며, Snowflake Cortex AI와 Snowflake Intelligence에 관한 제 글에서 다룹니다.
  5. 인수 합병 후 통합. 여러 ERP에 리포팅 계층 하나를 두고, 안전한 테스트 환경에는 클로닝을 씁니다.

제가 망설일 곳은 다음과 같습니다.

  1. 대량 트랜잭션 시스템. 하이브리드 테이블과 Snowflake Postgres가 도움이 되지만, ERP와 MES 트랜잭션은 자체 데이터베이스에 있어야 합니다.
  2. 실시간 설비 제어. Snowflake는 밀리초가 아니라 분 단위에 맞습니다. 센서 데이터를 스트리밍으로 들여오는 것은 괜찮습니다. 제어 루프를 닫는 것은 아닙니다.
  3. 엄격한 온프레미스 요건. 온프레미스 설치판은 존재하지 않습니다.
  4. Spark 기반의 대규모 맞춤형 머신러닝과 데이터 엔지니어링. 가능은 하지만, 많은 팀이 Databricks를 더 자연스럽게 느낍니다. 제 Snowflake vs Databricks 비교에서 그 선택을 다룹니다.

스노우플레이크 스키마 vs 스타 스키마: 다른 이야기입니다

Snowflake를 검색하는 사람들이 "스노우플레이크 스키마"에 도착하는 경우가 많습니다. 제품과는 아무 관계가 없습니다. 스노우플레이크 스키마는 차원 테이블을 하위 테이블로 정규화하는 데이터 모델링 패턴으로, 다이어그램이 눈송이처럼 가지를 칩니다.

스타 스키마는 각 차원을 하나의 평평한 테이블에 둡니다. 어느 모델이든 Snowflake에서도, 다른 어떤 웨어하우스에서도 구축할 수 있습니다. 대부분의 BI 팀은 쿼리가 더 단순한 스타 스키마를 선호합니다.

계약하기 전에 네 가지 결정을 문서로 남기십시오. 컴플라이언스 상태에 맞는 에디션, 클라우드와 리전, 워크로드를 웨어하우스에 어떻게 나눌지, 그리고 데이터를 Snowflake 포맷으로 둘지 Iceberg로 둘지입니다. 벤더와 시스템 통합업체에게 연간 총액 하나가 아니라 웨어하우스별 크레딧 추정치를 보여 달라고 요청하십시오. Snowflake 비용상의 놀라움 대부분은 아무도 문서로 남기지 않은 아키텍처 결정입니다.

ERP 데이터가 범위에 포함된다면 먼저 SAP 데이터 마이그레이션이 실패하는 이유를 읽으십시오. 같은 데이터 품질 문제가 어떤 플랫폼으로든 따라옵니다. Snowflake 결정에 대해 제2의 의견이 필요하시면 연락 주십시오.

Snowflake는 어디에 쓰입니까?

주로 ERP, CRM, 운영 데이터 같은 비즈니스 데이터에 대한 리포팅과 분석을 위한 클라우드 데이터 웨어하우스로 쓰입니다. 기업은 파트너와 실시간 데이터를 공유하고, Snowpark로 Python 데이터 과학을 실행하고, 거버넌스가 적용된 데이터 위에 AI 애플리케이션을 구축하는 데에도 씁니다.

Snowflake 아키텍처의 세 계층은 무엇입니까?

스토리지, 컴퓨트, 클라우드 서비스입니다. 스토리지는 데이터를 압축된 컬럼형 마이크로 파티션에 보관합니다. 컴퓨트는 쿼리를 실행하는 가상 웨어하우스로 구성됩니다. 클라우드 서비스는 보안, 메타데이터, 쿼리 최적화, 트랜잭션을 처리합니다. 스토리지와 컴퓨트는 따로 확장되고 따로 청구됩니다.

Snowflake는 데이터베이스입니까, 데이터 웨어하우스입니까?

정의에 따라 둘 다입니다. 분석 워크로드를 위해 만든 SQL 데이터베이스이며, 그래서 보통 클라우드 데이터 웨어하우스라고 부릅니다. Iceberg 테이블, 하이브리드 테이블, Snowflake Postgres로 이제는 한계 안에서 레이크하우스와 일부 트랜잭션 용도까지 다룹니다.

Snowflake를 온프레미스에서 실행할 수 있습니까?

아닙니다. Snowflake는 AWS, Microsoft Azure, Google Cloud에서만 실행됩니다. 미국 정부와 방위 산업 워크로드를 위해 AWS GovCloud와 Azure Government에 SnowGov 리전을 제공하며, 이 리전에는 Business Critical 이상의 에디션이 필요합니다.

스노우플레이크 스키마는 Snowflake라는 회사와 관련이 있습니까?

아닙니다. 스노우플레이크 스키마는 정규화된 차원 테이블을 사용하는 데이터 모델링 패턴입니다. 회사보다 먼저 존재했으며 어떤 웨어하우스에서도 작동합니다.

규제 대상 기업에는 어떤 Snowflake 에디션이 필요합니까?

보통 Business Critical입니다. 고객 관리형 키를 사용하는 Tri-Secret Secure, 프라이빗 연결, HIPAA 및 PCI DSS 지원이 추가되며, 정부 리전의 최소 요건입니다. Virtual Private Snowflake는 하드웨어를 공유하지 않는 전용 환경을 더합니다.

Noel D'Costa

글쓴이

Noel D'Costa

항공, 정부, 금융, 유통, 제조 분야의 SAP 및 Oracle ERP 프로젝트에서 25년을 일했습니다. 재무 출신입니다. 경영진이 혁신의 범위를 현실적으로 정하고, 어려움에 처한 프로젝트를 정상화하며, 운영 첫해를 견뎌 내는 시스템을 구축하도록 돕습니다.

다음 단계

지금 ERP 프로젝트를 진행 중이십니까?

이 글이 지금 진행 중인 프로젝트와 맞닿아 있다면, 30분 대화가 일주일간의 내부 분석보다 대개 더 많은 진전을 가져옵니다.