클라우드 컴퓨팅(Cloud computing)은 연산(compute)을 사용자에게는 더 가깝게, 그리고 당신이 "서버"라고 부를 수 있는 모든 것에서는 더 멀리 이동시키고 있습니다. 처음에는 컨테이너(containers)였습니다. 그다음은 서비스형 함수(Functions-as-a-Service, FaaS)였습니다. 이제는 전 세계 수백 개의 위치에서, 사용자가 어디에 있든 밀리초(milliseconds) 단위의 거리에서 당신의 코드를 실행하는 에지 런타임(edge runtimes)의 시대입니다.

만약 당신이 단 1년이라도 흐름을 놓쳤다면, 지형은 이미 바뀌었습니다. 지금 serverless and edge computing 분야에서 실제로 어떤 일이 일어나고 있는지, 오늘 바로 실행해 볼 수 있는 실제 코드를 통해 자세히 살펴보겠습니다.

왜 "Serverless"가 여전히 중요한가

Serverless는 서버의 부재를 의미하는 것이 아니었습니다. 그것은 서버에 대한 당신의 책임이 없음을 의미합니다. 패치(patching)도, 스케일링 그룹(scaling groups)도, 새벽 3시에 돈을 낭비하는 유휴 용량(idle capacity)도 없습니다. 당신은 함수(function)를 배포하기만 하면, 플랫폼이 나머지를 처리합니다.

현재 이 분야의 세 가지 주요 플레이어는 다음과 같습니다:

• AWS Lambda — 오리지널이며 여전히 가장 성숙하고, AWS 생태계에 깊이 통합되어 있습니다.
• Cloudflare Workers — 컨테이너 대신 V8 isolates를 사용하며, 거의 즉각적인 콜드 스타트(cold starts)를 제공하고, 300개 이상의 도시에 배포됩니다.
• Edge runtimes (Vercel Edge Functions, Deno Deploy, Fastly Compute) — 지연 시간(latency)에 민감한 웹 앱의 기본값으로 점점 더 많이 채택되고 있습니다.

AWS Lambda: 여전히 든든한 일꾼

Lambda는 특히 이미 AWS 환경을 사용 중이라면 여전히 안전하고 검증된 선택지입니다. 다음은 API Gateway 요청을 처리하는 최소한의 Lambda 함수입니다:

export const handler = async (event) => {
  const name = event.queryStringParameters?.name || "world";

...

AWS CLI 또는 SAM으로 배포하세요:

sam build
sam deploy --guided

Lambda의 강점은 깊이입니다 — VPC 액세스, 깊은 IAM 통합, EventBridge 트리거, Step Functions 오케스트레이션(orchestration) 등이 있습니다. 약점은 콜드 스타트(cold starts)와, 별도의 아키텍처를 설계하지 않는 한 함수가 여전히 특정 AWS 리전(region)에 묶여 있다는 점입니다.

Cloudflare Workers: 에지에서의 연산

Workers는 컨테이너(container)가 아닌 V8 isolates에서 실행되므로, 콜드 스타트(cold start)가 사실상 사라졌습니다. 우리는 밀리초 미만(sub-millisecond)의 시작 시간을 이야기하고 있습니다. 이는 지연 시간(latency)에 민감한 모든 작업에 대한 계산 방식을 변화시킵니다.

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
...

Wrangler를 사용하면 배포가 놀라울 정도로 간단합니다:

npm install -g wrangler
wrangler deploy

Workers는 또한 KV, Durable Objects, R2 스토리지(storage)를 제공합니다. 이 모든 것들은 동일한 isolate 내부에서 호출할 수 있으며, 별도의 클라우드 서비스로 이동하기 위한 추가적인 네트워크 홉(network hop)이 필요하지 않습니다.

Edge Runtimes: 모든 것이 수렴하는 지점

과거에 Cloudflare만의 기술이었던 것이 이제는 어디에나 존재합니다. Vercel의 Edge Functions, Deno Deploy, Fastly Compute 모두 유사한 isolate 기반 모델에서 실행됩니다. 새롭게 나타나고 있는 패턴은 다음과 같습니다:

// Vercel Edge Function 예시
export const config = { runtime: "edge" };

...

이것이 Workers 예시와 얼마나 유사한지 주목하십시오. 이는 우연이 아닙니다. Web 플랫폼의 Request/Response API가 에지 제공업체(edge providers) 전반에 걸쳐 사실상의 표준 인터페이스(de facto standard interface)가 되었음을 의미하며, 이는 기존의 클라우드 함수(cloud functions) 사이에서보다 제공업체 간의 이식성(portability)이 훨씬 더 쉬워졌음을 뜻합니다.

적절한 도구 선택하기

제가 유용하게 활용해 온 대략적인 멘탈 모델(mental model)은 다음과 같습니다:

만약 어떤 함수가 어디에 위치하고 어떻게 서로 연결되어 있는지 추적하기 위한 리소스 라이브러리나 내부 도구를 구축하고 있다면, 아키텍처가 여러 제공업체로 확산됨에 따라 팀의 정렬(aligned)을 유지하는 데 **software hub**가 진정으로 유용할 것입니다. Lambda 함수, Workers, 그리고 에지 미들웨어(edge middleware)가 모두 서로 다른 작업을 수행하게 되면 흐름을 놓치기 쉽기 때문입니다.

간단한 하이브리드 예시

하나만 선택할 필요는 없습니다. 2026년의 일반적인 패턴은 다음과 같습니다: 인증/캐싱/리다이렉트(auth/caching/redirects)를 위해 에지(edge)에서 Cloudflare Workers를 사용하고, 더 무거운 요청은 AWS Lambda로 전달하는 방식입니다.

export default {
  async fetch(request, env) {
    const cacheKey = new Request(request.url, request);
...

이를 통해 핵심 비즈니스 로직은 성숙하고 잘 알려진 환경에 유지하면서도, 에지(edge) 수준의 캐싱(caching)과 반복되는 요청에 대한 즉각적인 응답을 얻을 수 있습니다.

마무리 (Wrapping Up)

Serverless는 더 이상 단일한 개념이 아닙니다. 이는 "특정 리전(region) 내의 완전 관리형 함수"에서부터 "전 세계 모든 도시의 아이솔레이트(isolates)에서 실행되는 코드"에 이르는 스펙트럼입니다. 2026년의 대부분의 실제 아키텍처(architecture)는 두 가지를 혼합하는 방식으로 귀결됩니다. 즉, 무거운 작업에는 Lambda(또는 유사 서비스)를 사용하고, 지연 시간(latency)에 민감한 모든 것에는 에지 런타임(edge runtime)을 사용하는 것입니다.

작게 시작하십시오. 이미 보유하고 있는 함수 하나를 선택하여 Worker 또는 에지 함수(edge function)로 포팅(porting)해 보십시오. 콜드 스타트(cold-start)의 차이를 즉시 느낄 수 있을 것이며, 이는 나머지 아키텍처를 어디로 향하게 해야 할지에 대해 많은 것을 알려줄 것입니다.

자신만의 클라우드 아키텍처를 설계하고 있다면, 비용 모델링(cost modeling)과 멀티 프로바이더(multi-provider) 전략에 대해 더 깊이 알아볼 수 있는 저희의 *Serverless Architecture Guide*를 확인해 보세요._