다 같은 개념인 줄 알았다 — on-demand · serverless · Edge Function · 콜드 스타트

"이거 다 비슷한 말 아니에요?"라는 질문에서 시작한, 네 단어가 사실은 서로 다른 '층'이라는 정리.

2026-06-01 · 약 8분 소요 · 이전 글: 화면은 누가 그리나 — SSR · CSR

들어가며: "이거 다 같은 거 아니에요?"

지난 글에서 "앱인토스 앱은 CSR이고, 짝이 되는 백엔드는 serverless"라는 얘기를 하다가, 꼬리에 꼬리를 무는 질문이 나왔어요. on-demand, serverless, Edge Function, 콜드 스타트 — 글을 보다 보면 이 넷이 거의 한 묶음으로 같이 등장하거든요. 그래서 자연스럽게 이런 의문이 들죠. "이거 다 같은 개념 아니에요? 그냥 부르는 이름만 다른 거 아니에요?"

결론부터 말하면 전부 다른 층위의 단어예요. 같은 문맥에서 자주 붙어 다닐 뿐, 각자 답하는 질문이 다릅니다. 이걸 한 번 분리해두면 클라우드 문서를 읽을 때 머리가 훨씬 가벼워져요.

이 글의 결론을 먼저: 네 단어는 방식 → 모델 → 구현체 → 현상이라는 서로 다른 층에 있습니다. "어떤 방식으로?"가 on-demand, "어떤 모델로?"가 serverless, "어디서 도는 종류?"가 Edge Function, "그래서 무슨 일이 생겨?"가 콜드 스타트예요.

한 장으로 보는 층위

말로 풀기 전에 그림으로 보면 관계가 한눈에 들어와요. 포함 관계라는 게 핵심이에요 — 셋은 큰 것 안에 작은 것이 들어가는 구조고, 콜드 스타트만 그 바깥에서 생기는 '현상'입니다.

셋은 포함 관계(방식 ⊃ 모델 ⊃ 구현체), 콜드 스타트는 그 방식을 쓸 때 바깥에서 생기는 현상

네 단어, 하나의 표

같은 축으로 나란히 놓으면 "층이 다르다"는 게 분명해져요. 제일 왼쪽 칸 — 각자 답하는 질문이 다르다는 게 핵심이에요.

개념	층위	답하는 질문	정체	예시
On-demand	방식 · 원칙	어떤 방식으로?	필요할 때만 자원을 쓰는 전략. 제품이 아니라 아이디어.	(센서등 방침)
Serverless	모델 · 카테고리	어떤 모델로?	on-demand를 클라우드로 구현한 컴퓨팅 모델 전체. 서버를 직접 관리 안 함.	AWS Lambda, Vercel Functions
Edge Function	구현체 · 종류	어디서 도는 종류?	serverless 중에서도 사용자와 가까운 엣지에서 도는 함수. (serverless ⊃ Edge Function)	Cloudflare Workers, Supabase Edge Functions
콜드 스타트	현상 · 부작용	그래서 무슨 일이?	위 방식을 쓰면 나타나는 증상. 안 쓰던 함수를 깨울 때의 지연.	오랜만 호출 시 첫 응답 지연

표를 한 문장으로: 앞의 셋은 "큰 것 안에 작은 것"(방식 ⊃ 모델 ⊃ 종류)이고, 콜드 스타트만 차원이 달라요 — 나머지 셋이 무엇이라면, 콜드 스타트는 그것들을 쓸 때 벌어지는 일입니다.

센서등 비유로 묶기

추상적인 게 싫으면 이 비유 하나면 충분해요. 네 단어를 전등 하나에 다 끼워 넣을 수 있어요.

On-demand = "사람 있을 때만 켜자"는 방침
Serverless = 그 방침으로 만든 센서등 시스템
Edge Function = 그 시스템 중 현관에 단(=사용자 근처) 센서등
콜드 스타트 = 센서등이 오랜만에 켜질 때의 깜빡임

그 반대편엔 상시 서버 = 24시간 켜둔 전등이 있어요. 사람이 없어도 계속 켜져 있어 전기세(서버 비용)가 쭉 나가지만, 들어오는 순간 이미 환하니 깜빡임(콜드 스타트)이 없죠.

그래서 scale to zero vs scale to one

여기서 한 칸 더 들어가면 실무에서 자주 보는 갈래가 나와요. on-demand serverless도 "안 쓸 때 어디까지 끄느냐"가 갈립니다.

scale to zero — 트래픽 없으면 인스턴스를 0개로 완전히 꺼요. 비용 0에 수렴하지만, 오랜만에 온 사용자는 콜드 스타트를 맞습니다. (Supabase Edge Functions 등 기본 동작)
scale to one — 0으로 안 내리고 인스턴스 하나는 늘 깨워둬요. 첫 사용자도 깜빡임 없이 바로 응답하지만, 그 하나를 켜두는 비용이 듭니다. (Vercel Fluid Compute의 Pro 동작)

비용으로 번역하면: scale to zero는 "공짜에 가깝지만 오랜만 사용자가 느림", scale to one은 "약간의 상시 비용으로 오랜만 사용자도 빠름". 트래픽이 띄엄띄엄한 앱일수록 이 차이가 체감 속도를 가릅니다.

그래서 내 스택에 대입하면

이 층위를 알고 내 환경을 다시 보면 용어가 깔끔하게 정리돼요.

앱인토스 앱 = CSR(클라이언트가 그림) + serverless 백엔드. 화면은 React가 브라우저에서 그리고, 데이터는 serverless 함수가 호출될 때만 내려줘요.
Vercel에 올린 백엔드도 사실 serverless다. 상시 서버라고 착각하기 쉽지만 Function Invocations 단위로 도는 on-demand 모델이에요. 다만 Vercel Fluid는 scale to one이라 인스턴스 하나를 warm하게 유지해, 오랜만에 온 사용자도 콜드 스타트를 거의 안 맞습니다.
Supabase Edge Function = 엣지에서 도는 serverless의 한 종류. 고양이 타로에서 서버를 뺀 그 선택이 정확히 "상시 서버 대신 on-demand serverless로" 옮긴 거였어요. 카드 뽑기는 1초쯤 기다려도 되는 동작이라, scale to zero의 콜드 스타트가 흠이 안 됐고요.

같은 "함수를 호출한다"인데, 어떤 방식(on-demand)으로 어떤 모델(serverless) 위에서 어떤 종류(Edge / 리전)의 함수를 쓰고, 그때 어떤 현상(콜드 스타트)을 감수하느냐 — 네 단어가 이렇게 한 문장에 자연스럽게 다 들어갑니다.

마무리: 같이 다닌다고 같은 말은 아니다

기술 문서가 어렵게 느껴지는 이유 중 하나가, 이렇게 층위가 다른 단어들이 한 문장에 뭉쳐 나오는데 다 같은 급으로 읽으려 하기 때문이더라고요. on-demand·serverless·Edge Function·콜드 스타트는 친한 단어들이지만 동의어가 아니에요.

읽다가 헷갈리면 질문을 하나씩 떼어보면 돼요 — "이건 방식 얘기야, 모델 얘기야, 구현체 얘기야, 아니면 현상 얘기야?" 네 칸 중 어디에 들어가는지만 잡으면, 나머지 문장은 저절로 풀립니다.

다음 글 예고: scale to zero인 Supabase Edge Function에서 콜드 스타트를 실제로 줄이는 방법 — warm-up 핑, 함수 가볍게 유지하기, 그리고 "굳이 줄일 필요가 없는 경우"를 내 앱 기준으로 정리해볼 예정이에요.

728x90