---
title: Notebook이 켜지는 데 왜 이렇게 걸리죠? Starter pool과 세션 이야기
description: Starter pool이 Spark 세션을 몇 초 만에 띄워주는 원리, 커스텀 pool·환경을 쓰면 왜 느려지는지, 세션 만료 같은 초심자가 자주 부딪히는 부분을 정리했어요.
date: 2026-10-15
  tags: [Spark, Starter pool, Notebook, 세션, Fabric]
cards:
  - /cards/fabric-spark-starter-pool-session-startup/card-01.png
  - /cards/fabric-spark-starter-pool-session-startup/card-02.png
  - /cards/fabric-spark-starter-pool-session-startup/card-03.png
  - /cards/fabric-spark-starter-pool-session-startup/card-04.png
  - /cards/fabric-spark-starter-pool-session-startup/card-05.png
  - /cards/fabric-spark-starter-pool-session-startup/card-06.png
  - /cards/fabric-spark-starter-pool-session-startup/card-07.png
author: Lissa
source: https://interlinear.work/notes/fabric-spark-starter-pool-session-startup/
---

> **원문:** [Apache Spark compute for Data Engineering and Data Science](https://learn.microsoft.com/en-us/fabric/data-engineering/spark-compute)
> **게시일:** 2026-03-05 · **Microsoft Fabric 설명서**

Fabric에서 처음 Notebook을 열고 셀을 실행하면 몇 초 만에 바로 결과가 나올 때가 있고, 어떤 날은 몇 분씩 "세션 준비 중" 상태로 멈춰 있을 때가 있어요. 같은 Notebook인데 왜 이렇게 다를까요? 답은 Fabric이 Spark 세션을 띄우는 방식, 그중에서도 **Starter pool**의 동작 원리에 있어요.

## Starter pool: 미리 켜둔 클러스터를 나눠 쓰는 것

전통적인 Spark 환경(Synapse의 Spark pool 포함)에서는 세션을 요청할 때마다 클러스터 노드를 새로 프로비저닝했어요. 이 과정만 몇 분씩 걸리죠. Fabric의 **Starter pool**은 이 대기 시간을 없애기 위해 접근 방식을 바꿨어요. Medium 노드 크기의 Spark 클러스터를 미리 켜둔 채로 대기시켜두고, 사용자가 세션을 요청하면 그 준비된 클러스터에서 즉시 세션을 배정해줘요.

추가 라이브러리나 커스텀 Spark 속성 없이 기본 설정만 쓰는 경우, 세션은 보통 **5~10초** 안에 시작돼요. 클러스터를 새로 만드는 게 아니라 이미 돌고 있는 클러스터를 나눠 쓰는 것이기 때문에 가능한 속도예요.

다만 이건 어디까지나 **Microsoft가 관리하는 최선형(best-effort) 최적화**라는 점을 알아둘 필요가 있어요. 미리 데워둔(prewarmed) 용량이 남아 있을 때만 몇 초짜리 시작이 보장돼요. 그 용량이 부족하면 Fabric은 표준 온디맨드 방식으로 세션을 만드는데, 이때는 시간이 더 걸려요.

## 그런데 왜 이렇게 느려질 때가 있죠?

Starter pool의 빠른 시작이 항상 보장되지는 않아요. 느려지는 원인은 대체로 다음 몇 가지로 좁혀져요.

- **커스텀 라이브러리나 Spark 속성**: 환경(Environment)에 라이브러리나 설정을 추가해뒀다면, 세션이 만들어진 뒤 그걸 다시 개인화(personalization)하는 시간이 붙어요. **Quick 모드**는 세션 시작 시점에 라이브러리를 설치해서 30초~5분이 더 걸리고, **Full 모드**는 미리 만들어둔 환경 스냅샷을 배포하는 방식이라 보통 1~3분이 추가돼요.
- **다른 노드 크기나 커스텀 compute 설정**: Starter pool은 **Medium 노드만 지원**해요. 다른 노드 크기를 고르거나 compute 설정을 바꾸면 그 순간부터는 온디맨드 세션 시작 방식으로 넘어가서 2~5분이 걸릴 수 있어요.
- **지역 내 Starter pool 소진**: 드물지만 특정 지역의 트래픽이 몰리면 미리 데워둔 pool이 바닥날 수 있어요. 이때 Fabric은 새 클러스터를 띄우는데, 여기에 2~5분이 걸려요.
- **Private Link나 Managed VNet 같은 고급 네트워킹**: 이런 네트워크 격리 기능을 쓰는 워크스페이스에서는 Starter pool 자체가 지원되지 않아서, 항상 온디맨드로 클러스터를 새로 만들어요(2~5분).

정리하면, 시작 시간이 늘어나는 원인은 거의 항상 **사용자 쪽 설정** 때문이지 플랫폼이 갑자기 느려진 게 아니에요. 원문에 실린 예시 표로 보면 감이 잘 와요.

| 상황 | 대략적인 시작 시간 |
| --- | --- |
| 기본 설정, 라이브러리 없음 | 5~10초 |
| 기본 설정 + 라이브러리 의존성 | 5~10초 + 라이브러리 설치 30초~5분 |
| 지역 내 트래픽 과다, 라이브러리 없음 | 2~5분 |
| 네트워크 보안(Private Link/VNet), 라이브러리 없음 | 2~5분 |

## 커스텀 Pool과 환경을 쓰면 왜 더 느려지나요

Starter pool 대신 **커스텀 Spark pool**을 만들어 쓰면, 노드 크기·오토스케일 범위·Spark 속성을 세밀하게 조정할 수 있어요. 하지만 그 대가로 커스텀 pool은 클러스터를 Azure에서 새로 확보해야 해서 시작하는 데 대략 **3분** 정도 걸려요. 여기에 Full 모드 환경까지 붙어 있으면 라이브러리 배포 시간이 더 얹혀요.

빠르면서도 커스텀 라이브러리를 미리 깔아두고 싶다면 **custom live pool**이라는 선택지도 있어요. 정해둔 활성 구간(active window) 동안 전용 클러스터를 계속 켜두고 라이브러리 스냅샷까지 미리 심어둬서, 그 구간 안에서는 매번 약 5초 만에 세션이 시작돼요. 예약된 Spark job처럼 시작 시간이 들쭉날쭉하면 곤란한 워크로드에 적합한 방식이에요.

## 세션 만료도 같이 알아두면 좋아요

세션은 켜놓기만 하면 계속 살아 있는 게 아니에요. 아무 활동 없이 방치되면 정해진 세션 만료 시간(기본 20분)이 지난 뒤 자동으로 내려가고, 그 뒤로 2분이 더 지나면 pool 자체도 할당이 해제돼요. 다음에 다시 셀을 실행하면 처음부터 새 세션을 잡는 과정을 다시 거치게 되죠. 비용은 세션이 실제로 활성 상태인 시간에 대해서만 청구되고, pool이 대기(idle) 상태로 떠 있는 시간이나 세션을 개인화하는 시간에는 과금되지 않아요.

## 정리

Notebook 세션이 몇 초 만에 뜬다면 Starter pool의 미리 데워둔 Medium 클러스터를 그대로 받은 거고, 몇 분씩 걸린다면 커스텀 라이브러리·다른 노드 크기·네트워크 격리 설정·지역 내 용량 부족 중 하나에 걸린 거예요. 시작 속도가 계속 중요한 워크로드라면 기본 Starter pool 설정을 최대한 유지하거나, 예측 가능한 시작이 필요하면 custom live pool을 검토해볼 만해요.

---

## 어휘 주석

1. **Starter pool:** Fabric이 미리 켜서 대기시켜 둔 공용 Spark 클러스터. 별도 설정 없이 Notebook을 열면 기본으로 여기서 세션을 받아요.
2. **개인화(personalization):** 세션이 만들어진 뒤 사용자가 지정한 라이브러리나 설정을 그 세션에 적용하는 과정. 이 과정이 길수록 실제로 코드를 실행할 수 있게 되기까지 시간이 늘어나요.