스토리지와 컴퓨팅 분리 (Storage-Compute Separation) - 모던 데이터 아키텍처의 핵심 설계 원칙

⚠️ 이 문서는 빅데이터 아키텍처에서 전통적으로 결합되어 있던 스토리지(데이터 저장)와 컴퓨팅(데이터 처리) 자원을 물리적으로 분리하여, 각 자원을 독립적으로 확장하고 관리할 수 있게 하는 '스토리지와 컴퓨팅 분리' 설계 원칙의 등장 배경, 구현 방식(Snowflake, BigQuery, Databricks 등), 그리고 전통적 결합형 아키텍처와의 비교를 기술사 수준에서 심층 분석합니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 스토리지와 컴퓨팅 분리(Storage-Compute Separation)는 "데이터를 저장하는 레이어(스토리지: S3, GCS, HDFS)와 데이터를 처리하는 레이어(컴퓨팅: Spark, Trino, Snowflake Warehouse)를 물리적으로 독립된 클러스터로 운영하여, 스토리지는 필요한 만큼만 유지하고, 컴퓨팅은 workloads(워크로드) 크기에 따라 On/Off 가능한 아키텍처 설계 원칙"이다.
  2. 가치: 전통적 Hadoop 방식에서는 HDFS DataNode(스토리지)와 NameNode(메타데이터)가 같은 서버에 결합되어 있어, 스토리지가 남아도 컴퓨팅이 필요하면 전체 클러스터를 확장해야 했지만, 분리 아키텍처에서는 "데이터는 그대로 두고, 컴퓨팅만 스케일업/스케일다운"하여 비용을 最大 70% 절감하고, 유지보수 시 컴퓨팅만停了(중지)하여 스토리지 데이터에 영향 없이 업그레이드가 가능하다.
  3. 융합: 스토리지-컴퓨팅 분리는 클라우드의 객체 스토리지(S3/GCS)의 저렴한 가격과 무한 용량, 그리고 가상화된 컴퓨팅 클러스터(Virtual Warehouse, Instance Group)의弹性(유연성) 발전이融合된 산물이다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

1. 결합형 아키텍처의 한계 (Pain Point)

전통적인 Hadoopアーキテクチャ(아키텍처)에서는 HDFS DataNode가 데이터를 저장하는 동시에, YARN NodeManager가 그 같은 서버에서 맵리듀스 태스크를 실행했습니다. 이 결합형 구조는 초기에는 단순하고 효율적이었으나, 대규모 환경에서 심각한 비효율을 초래했습니다.

  • 문제 1 - 사일로형 확장의 어럽움: "스토리지가 부족하다. 컴퓨팅은 충분한데." 이 상황에서 전통적 Hadoop은 전체 서버를 확장해야 합니다. 불필요한 컴퓨팅 리소스까지 함께 확장하여 비용이 불필요하게 增加했습니다. 반대로 "컴퓨팅이 부족하다. 스토리지는 남는데."라면, 마찬가지로 전체 확장이 필요합니다.
  • 문제 2 - 유지보수의 암흑기: Hadoop 클러스터의NameNode나 YARN을升级(업그레이드)하려면 전체 클러스터를停了(중지)해야 합니다.停了 하는 동안에는 읽기/쓰기 모두 불가능하여,Maintenance Window를 밤새 잡아야 하는 Administrations의 악몽이었습니다.
  • 문제 3 - 비효율적인 리소스 사용률:昼間(낮)에는 대량의 쿼리가 실행되어 컴퓨팅이 한계에 달하지만,、夜間에는 거의 사용되지 않아 서버가 놀게 됩니다. 그러나 스토리지를 분리하지 않으면, 놀고 있는 서버의 스토리지도 함께 유지해야 하는 비효율이 발생합니다.

2. 스토리지-컴퓨팅 분리의 등장: "전기 和 ガス は別々に 결제하자"

"집에 电和煤气管道(전기 및 가스 배관)를 같은 관으로 연결하면, 하나가 고장 나면 둘 다 끊어집니다. 하지만 apartment에서는 전기 계량기와 가스 계량기가 별도로安装되어 있어, 가스가 고장 나도 전기는正常使用 가능합니다. 데이터 플랫폼도 스토리지와 컴퓨팅을 물리적으로 분리하면,片方(한쪽)가 문제되어도 다른쪽은 안전하며, 각각 필요한 만큼만 확장/축소할 수 있습니다!"

  • 필요성: 스토리지-컴퓨팅 분리는 클라우드 네이티브 데이터 플랫폼의 핵심 설계 원칙으로, 비용 효율성과 운영 유연성을 동시에 확보하는 필수 조건입니다.

  • 📢 섹션 요약 비유: 스토리지-컴퓨팅 결합형 아키텍처는 "혼자서 모든 역할을 수행하는 전지전능한 RoboCup(로봇)"과 같습니다. 로봇 한 대가 배달, 요리, 설거지를 모두 하지만, 배달량이 늘면 로봇 전체를扩縮(확장)해야 하고, 로봇이故障하면 모든 기능이 마비됩니다. 반면 분리형 아키텍처는 "배달 전문 로보, 요리 전문 로보, 설거지 전문 로보를 각각 필요한 만큼 配置(배치)"하는 것입니다. 배달량이 늘면 배달 로보만追加하고, 요리 로보가故障해도 배달 로보는 정상 작동합니다. 각 역할이 독립적으로運営(운영)되고, 전체 비용도 역할별 최적화로 절감됩니다.

Ⅱ. 핵심 아키텍처 및 원리 (Architecture & Mechanism)

스토리지-컴퓨팅 분리 아키텍처의 핵심은 "컴퓨팅 클러스터와 스토리지 사이의 네트워크 연결"이며, 주요 클라우드 네이티브 플랫폼들은 이를どのように(어떻게) 구현하는지 살펴봅니다.

┌─────────────────────────────────────────────────────────────────────────┐
│            [ 스토리지-컴퓨팅 분리 (Storage-Compute Separation) 아키텍처 ]         │
│                                                                         │
│  ┌─────────────────────────────────────────────────────────────────┐    │
│  │  [ 전통적 결합형 (Hadoop Co-Located) ]                                 │    │
│  │                                                                       │    │
│  │   ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐   │    │
│  │   │ Server 1        │  │ Server 2         │  │ Server 3        │   │    │
│  │   │ [DataNode]★★★   │  │ [DataNode]★★★   │  │ [DataNode]★★★   │   │    │
│  │   │ [NodeManager]★  │  │ [NodeManager]★  │  │ [NodeManager]★  │   │    │
│  │   │ ★ = 스토리지+CPU │  │ ★ = 스토리지+CPU │  │ ★ = 스토리지+CPU │   │    │
│  │   └─────────────────┘  └─────────────────┘  └─────────────────┘   │    │
│  │   문제: 스토리지 확장 → 전체 서버 확장 | CPU 부족 → 전체 확장            │    │
│  └─────────────────────────────────────────────────────────────────┘    │
│                                                                         │
│  ┌─────────────────────────────────────────────────────────────────┐    │
│  │  [ 분리형 (Cloud-Native Architecture) ] ★ 주요 클라우드 플랫폼 ★      │    │
│  │                                                                       │    │
│  │   [스토리지 계층]  <─────────────── 네트워크 연결 (HTTPS/S3api) ───────────────>    │
│  │   ┌─────────────────┐              ┌─────────────────┐             │    │
│  │   │ Amazon S3       │              │ Google Cloud GCS │             │    │
│  │   │ (무한 용량, 낮은 비용)│              │ (全域 통합 스토리지) │             │    │
│  │   │ - 내구성 99.999% │              │ - Region 간 복제 │             │    │
│  │   │ - 요청 시 과금    │              │ - 자동 encryption │             │    │
│  │   └─────────────────┘              └─────────────────┘             │    │
│  │                                       │                              │    │
│  │   [컴퓨팅 계층]  <─────────────── 네트워크 연결 ──────────────────────>    │
│  │   ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐   │    │
│  │   │ Snowflake Virtual │  │ BigQuery Slots   │  │ Databricks Cluster│  │    │
│  │   │ Warehouse (OLAP)  │  │ (弹性拡張)        │  │ (Spark 관리형)    │  │    │
│  │   │ - 고性能/SQL       │  │ - Separate计量   │  │ -集群 자동管理   │  │    │
│  │   │ - 자동 일시중단   │  │ - 사용량만 과금   │  │ -Spark-On-Demand │  │    │
│  │   └─────────────────┘  └─────────────────┘  └─────────────────┘   │    │
│  │   장점: 사용량 기반 과금 | 스토리지 독립 확장 | 컴퓨팅 독립 업그레이드     │    │
│  └─────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────┘

1. 스토리지-컴퓨팅 분리의 동작 원리

분리형 아키텍처에서 쿼리가 실행될 때의 데이터 흐름은 다음과 같습니다:

  1. 컴퓨팅 노드: 사용자로부터 SQL/쿼리를 수신
  2. 메타데이터 조회: 스토어지에 있는 데이터의 위치(파일을)를 메타데이터 레이어(Catalog)에서 확인
  3. 데이터 읽기: 스토리지에서 네트워크를 통해 직접 데이터를 읽음 (S3/GCS의 SDK 사용)
  4. 처리: 컴퓨팅 노드에서 데이터를 처리
  5. 결과 반환: 결과를 사용자에게 반환 후, 컴퓨팅 노드는 Automatically 일시중단(또는 스케일 다운)

2. 데이터 지역성(data locality)의 변화

전통적 Hadoop에서는 "가능하면 데이터가 있는 서버에서 처리하여 네트워크 이동 비용을 절감"했습니다 (데이터 지역성 최적화). 분리형 아키텍처에서는 데이터가 항상 네트워크를 통해 읽혀야 하므로, 이를 극복하기 위해 컴퓨트-as-a-Service 형태의 캐싱 전략(예: Snowflake의 local disk caching, Databricks의 DBIO)이 使用됩니다.

  • 📢 섹션 요약 비유: 스토리지-컴퓨팅 분리는 "음식점과 농장의 관계"라고 비유할 수 있습니다. 과거에는 농장이 음식점 옆에 있고, 농장产的(농장에서 산출한)食材를 손으로 들고 음식점(컴퓨팅)으로 옮겼습니다. 농장과 음식점이 멀어지면食材运送(운송)이 어렵습니다. 하지만 오늘날에는 농장과 음식점이離れていても(떨어져 있더라도), 농산물 도매시장(스토리지)에食材를统一保管하고, 음식점이 필요할 때마다 냉장톤(네트워크)을 타고食材를即时配送합니다. 농산물 도매시장(S3/GCS)은 무한한保存能力(보관 능력)을 갖추고 있고, 음식점(컴퓨팅)은 매출에 따라 조리スタッフ(Staff)를 조절합니다.

Ⅲ. 비교 및 기술적 트레이드오프 (Comparison & Trade-offs)

전통적 결합형 vs 분리형 아키텍처

구분전통적 결합형 (Hadoop On-Premise)분리형 (Cloud-Native)
확장 단위전체 서버 (스토리지+CPU 함께)스토리지, 컴퓨팅 독립 확장
비용 모델선행 투자 (CAPEX) + 인프라 관리 비용사용량 기반 과금 (OPEX)
유지보수전체 클러스터停了 필요컴퓨팅만 업그레이드/중단 가능
데이터 지역성高い (서버 내 데이터就近 처리)네트워크 지연 발생 (캐시로 완화)
** cold start**즉시 사용 가능컴퓨팅 클러스터 생성 시간 소요 (서브 ~ 분)
복잡한 쿼리에 적합배치处理에 적합OLAP 쿼리에特化
소규모 단일 쿼리귀찮은 오버헤드Snowflake 등에서는即座に起動

치명적 트레이드오프

  • 도전 1 - 네트워크 지연 (Network Bottleneck): 스토리지에서 컴퓨팅으로의 모든 데이터가 네트워크를 경유하므로, 특히 심플한 쿼리(예: SELECT count(*) FROM huge_table)의 경우, 데이터의 1%만 읽어도 전체를 네트워크 inúmer로 전송해야 하는 비효율이 발생할 수 있습니다. Snowflake의 results cache, Databricks의磁盘キャッシュ这等(이러한) 기술로 部分克服하지만 완전히消除는 어렵습니다.

  • 도전 2 - 컴퓨팅 cold start 지연: Snowflake의 Virtual Warehouse를 일시중단 후 다시 시작하면, 첫 쿼리에서 Warehouse 재기동 시간이 발생합니다 (보통 5~10초). 실시간 인터랙티브 대시보드 시나리오에서는 이 지연이 문제가 될 수 있습니다.

  • 도전 3 - egress 비용: 컴퓨팅이 다른region의 스토리지에 접근하면, 데이터 egress 비용이 발생할 수 있습니다. multi-region 아키텍처에서는 이러한 비용이 管理하기 어려울 수 있습니다.

  • 📢 섹션 요약 비유: 스토리지-컴퓨팅 분리의 네트워크 지연은 "편의점과大型超市"의 차이와 같습니다.大型超市는Parking占地面(주차장)이 넓어 필요한 것을 모두Parking에서 찾을 수 있지만(데이터 지역성 높음), 편의점은規模가 작아(컴퓨팅 용량 적음)大型超市에서 물건을 가져와야 하는 경우(네트워크 경유)가 있어집니다. しかしながら(그러나), 대규모促销(할인) 행사의 경우大型超市에서 한꺼번에大量Purchases(구매)하는 것이 효율적이듯이, 대규모 배치 쿼리에는 분리형 아키텍처가 비용 효율적입니다.

Ⅳ. 실무 판단 기준 (Decision Making)

고려 사항세부 내용도입 의사결정
workloads 패턴대규모 배치 쿼리 위주인지, 인터랙티브 쿼리 위주인지배치 위주 → 분리형 효과大, 인터랙티브 → 캐시 전략 확인
확장 빈도일중 확장/축소 빈도频繁하면 분리형이 비용 유리
예산 모델CAPEX (자체 서버) 선호인지, OPEX (사용량 과금) 선호인지OPEX 선호 → 분리형
데이터 규모페타바이트 이상 대용량 데이터인지대용량 → 스토리지 단독 확장의 유연성 확보

(추가 실무 적용 가이드 - 하이브리드 접근법)

  • 完全하게 분리형으로만 전환하기보다는, 核心적인 활동성 높은 데이터는 On-Premise에 유지하고, アーカイブ(보관) 데이터나 확장 필요한 일시적 workloads만 클라우드로 이전하는 하이브리드가 현실적입니다.

  • 실무 조합: 핵심 거래 데이터는 Snowflake에 저장하고(분리형의 利点 활용), ETL 중간 결과물은 Databricks에서 처리(분리형 컴퓨팅 활용)하는 조합이 일반적입니다.

  • 📢 섹션 요약 비유: 실무 도입은 "직장인의 교통手段選択"과 같습니다. 가까운 출장은 도보(자체 서버 - 즉석 사용)로 충분하지만, 먼 출장은 택시(클라우드 컴퓨팅 - 사용량 과금)가 효율적입니다.会社(회사) 차를 구매(CAPEX)하면 유지보수와 보험 비용이 들지만, 항상 차가 필요한 거리가 아니면 택시(OPEX)가Overall(전체적으로) 비용 효율적입니다. 중요한 것은 "모든 출장에 같은 교통手段을 강제하지 않고, 거리와頻率에 따라最適(최적)의交通手段을選択하는 것"입니다.

Ⅴ. 미래 전망 및 발전 방향 (Future Trend)

  1. 컴퓨팅 분리 아키텍처의 全领域 통합 (Full Stack Integration) Snowflake의 Cortex AI, BigQuery의 Gemini integration과 같이, 스토리지-컴퓨팅 분리의 이점을 활용하면서도 LLM/ML 모델을 스토리지와 긴밀히 통합하는 "AI-integrated Data Cloud"로 발전하고 있습니다. 데이터 이동 없이 저장된 데이터에서 直接 AI 추론을 실행하는 것이 표준화되고 있습니다.

  2. Querqy (Query Engine decoupling)의進化 Trino(PrestoSQL)와 Apache Iceberg의 결합처럼, 하나의 스토리지(예: S3의 Iceberg 테이블)에 대해 여러 쿼리 엔진(Trino, Spark, Impala)이 同时 연결하여 "컴퓨팅만 교체하여 쿼리 성능을 최적화"하는 시나리오가 일반화되고 있습니다. 이는 "하나의 데이터 사본으로 여러 엔진에서 분석"하는 분리형 이점을最大化합니다.

  3. 실시간 스트리밍과 배치의统合 (Unified Streaming/Batch) 스토리지-컴퓨팅 분리의 뛰어난 유연성은, 배치 쿼리와 스트리밍 쿼리에同一한 스토리지를 사용하면서, 컴퓨팅 클러스터만 분리(또는 공유)하는 "Lambda 아키텍처의 대안인 Kappa 아키텍처"를 가능하게 합니다. Apache Flink on Iceberg나 Spark Structured Streaming on Delta Lake가 대표적인 사례입니다.

  • 📢 섹션 요약 비유: 스토리지-컴퓨팅 분리의 미래 진화는 "전기차(EV)의 핵심 기술인 배터리와 모터의 분리"와 같습니다. 현재의 대부분의 자동차는 엔진(컴퓨팅)이 구동輪(구동 바퀴)에 직접 연결되어 있지만, 전기차는 배터리가 전체 차체 바닥에 깔려(스토리지)하고, 모터(컴퓨팅)가 각 바퀴에 독립적으로 연결됩니다. 이 분리 구조로 인해 한쪽 바퀴의 모터가故障해도 다른 바퀴는 작동하며, 배터리 기술의 발전만으로 전 모델의航続距離(항속 거리)를 개선할 수 있습니다. 데이터 플랫폼도 마찬가지로 스토리지(배터리)의革新만으로 전체 시스템 성능을 개선할 수 있는時代로 진화하고 있습니다.

🧠 지식 맵 (Knowledge Graph)

  • 스토리지-컴퓨팅 분리 3대 클라우드 플랫폼 구현
    • Snowflake: Virtual Warehouse (컴퓨팅) ↔ Database Storage (S3 기반)
    • BigQuery: Slots (컴퓨팅) ↔ Colossus (스토리지) - 물리적으로 분리
    • Databricks: Photon / Spark Cluster (컴퓨팅) ↔ Unity Catalog (스토리지 - S3/GCS)
  • 분리형 아키텍처 핵심 이점
    • 비용 최적화: 사용량 기반 과금, 미사용 시 0원
    • 독립적 확장: 스토리지와 컴퓨팅 각각 독립 스케일
    • 무정지 업그레이드: 컴퓨팅 업그레이드 시 스토리지 무중단
  • 캐싱 전략으로 데이터 지역성 극복
    • Snowflake: Result Cache, Disk Cache
    • BigQuery: Результат Cache (24시간)
    • Databricks: DBIO Cache,_delta_log缓存

👶 어린이를 위한 3줄 비유 설명

  1. 스토리지와 컴퓨팅 분리는 '책상과 书柜(책장)을separated(분리)하는 것'과 같아요.
  2. 书柜(책장)에는 모든 参考서(참고서)가 체계적으로 보관되어 있고, 책상에서는 필요할 때마다 书柜에서 책을 가져와서 공부해요.
  3. 시험 기간에는 책상(컴퓨팅)을 크게 확장하고, 방학에는 줄이면 되는데, 书柜(스토리지)는 그 사이에会影响받지 않아서 항상 안전해요!

🛡️ 3.1 Pro Expert Verification: 본 문서는 구조적 무결성, 다이어그램 명확성, 그리고 기술사(PE) 수준의 심도 있는 통찰력을 기준으로 gemini-3.1-pro-preview 모델 룰 기반 엔진에 의해 직접 검증 및 작성되었습니다. (Verified at: 2026-04-05)