엣지 컴퓨팅과 서버리스 엣지 함수란?

엣지 컴퓨팅은 사용자나 데이터 소스 가까이에서 연산하는 모델이며, 엣지 함수는 CDN 거점에서 실행되는 서버리스 코드입니다. 넓은 의미의 용어는 Shi 등이 데이터 소스 가까이에 배치된 연산으로 정의한 것이 표준이며, 공장 현장의 IoT와 통신사의 MEC 인프라까지 아우릅니다. 백엔드 개발자에게는 더 구체적인 의미입니다. CDN이 사용하는 것과 같은 전 세계 PoP에 작은 함수를 배포하고, 각 요청에서 가장 가까운 PoP에서 실행하는 것입니다. 콘텐츠 캐싱에서 코드 실행으로 나아간 CDN의 진화입니다.

핵심 요약

엣지 함수, 그리고 엣지 함수가 사는 계층

// JavaScript — an edge function (web-standard APIs, runs at every POP)
// Gateway logic at the edge; the backend stays the source of truth
export default async function handler(request) {
  const url = new URL(request.url);
  const country = request.headers.get('x-user-country') ?? 'US';

  if (url.pathname === '/' && country !== 'US') {
    return Response.redirect(`${url.origin}/${country.toLowerCase()}/`, 302);
  }
  // Reject requests without credentials at the edge; full verification and data work go to the origin
  const auth = request.headers.get('Authorization');
  if (!auth) return new Response('Unauthorized', { status: 401 });

  return fetch(request); // pass through to the origin backend
}

// Flutter / Dart — Back4app Flutter SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..whereEqualTo('status', 'published')
  ..setLimit(20);
final response = await query.query();
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// iOS / Swift — Back4app Swift SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
let query = Post.query("status" == "published")
  .limit(20)
let posts = try await query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// Android / Kotlin — Back4app Android SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
val query = ParseQuery.getQuery<ParseObject>("Post")
query.whereEqualTo("status", "published")
query.limit = 20
val posts = query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

JavaScript 탭이 엣지 함수 그 자체입니다. 웹 표준 Request/Response만 쓰고 프레임워크 없이, 오리진에 닿기 전에 트래픽을 가로챕니다. 클라이언트 탭들은 아키텍처의 반대편을 보여 줍니다. 애플리케이션 데이터는 여전히 오리진 백엔드로 흐릅니다. 데이터베이스가 거기에 있기 때문이며, 이 글 전체가 계속 되돌아오는 문장이 바로 이것입니다.

아이솔레이트 vs. 컨테이너: 엣지가 밀리초 단위로 시작하는 이유

머신마다 오래 실행되는 프로세스 하나를 수천 개의 아이솔레이트가 공유합니다. 브라우저 탭을 서로 떼어 놓는 바로 그 메커니즘이므로, 함수를 “시작”한다는 것은 런타임을 부팅하는 것이 아니라 컨텍스트를 하나 만드는 것입니다. 엣지 플랫폼이 0에 가까운 콜드 스타트를 정직하게 주장할 수 있는 이유는 웜 풀이 아니라 이 아키텍처입니다. 그 대가는 세 번째와 네 번째 행입니다. 더 약한 격리 경계(신중한 완화책으로 보완됨)와 npm의 상당 부분이 실행되지 않는 런타임입니다. 파일시스템도, 네이티브 모듈도, 동적 평가도 없으며, 이식 가능한 API 범위는 이제 Minimum Common API(ECMA-429)로 표준화되어 있습니다.

엣지 vs. 오리진: 워크로드 분담

솔직한 부분: 데이터베이스는 여전히 한곳에 있습니다

벤더의 설명 자료가 빼먹는 섹션입니다. 연산을 엣지로 옮겨도 데이터는 옮겨지지 않습니다. 왕복이 사용자 → 서버에서 함수 → 데이터베이스로 자리를 옮길 뿐이며, 요청을 자주 주고받는 워크로드에서는 오히려 퇴보입니다. 사용자에게서 5 ms 떨어진 엣지 함수가 150 ms 떨어진 데이터베이스에 순차 쿼리를 다섯 번 보내면 750 ms를 쓰는데, 데이터베이스와 같은 곳에 있는 리전 함수라면 ~5 ms면 됩니다. 이 산술이 업계의 조용한 궤도 수정을 설명합니다. 일부 주요 엣지 플랫폼은 이제 대부분의 워크로드에 자사의 리전 런타임을 권장하고, 함수를 데이터베이스 가까이에 고정하는 옵션을 추가했습니다. 데이터 지역성이 연산 지역성을 이긴다는 것을 이보다 강하게 인정할 수는 없습니다. 부분적인 해법을 실용성 순서로 정리하면 이렇습니다. 데이터 비중이 큰 코드는 오리진에서 실행합니다(위의 분담 표). 엣지 코드가 데이터를 건드려야 한다면 왕복 한 번으로 배칭합니다. 그리고 엣지 키-값 캐시로 읽기를 바깥으로 복제합니다. 최종 일관성(eventual consistency)의 트레이드오프도 함께 따라옵니다. 엣지 함수는 엣지에서 일을 끝낼 수 있을 때 유리합니다. 요청마다 오리진까지 왕복하는 순간, 지리는 더 이상 유리하게 작용하지 않습니다.

엣지가 과잉 설계가 되는 경우

대부분의 애플리케이션은 사용자가 한 지역에 모여 있는 CRUD 백엔드입니다. 이런 앱에는 단일 리전 백엔드에 정적 자산용 CDN을 더한 구성이, 같은 데이터베이스까지 왕복하는 엣지 계층보다 단순하고 종단 간으로도 더 빠른 경우가 많습니다. 엣지 함수가 제자리를 찾는 것은 로직이 엣지에서 완결되고, 사용자가 전 세계에 분산되어 있으며, 경로의 지연 시간이 체감되는 경우입니다. 세 조건이 모두 필요합니다. 비용 모델도 반대편에서 같은 이야기를 합니다. 엣지 플랫폼은 요청 수와 CPU 밀리초로 과금하고(얇은 게이트웨이 로직에는 저렴합니다), 리전 함수는 실제 경과 시간으로 과금합니다. 바로 옆에 있어야 했던 데이터베이스를 기다리며 코드가 보내는 시간까지 포함해서입니다.

일반적인 사용 사례

• 인증 관문 – PoP에서 세션 토큰을 검증하므로 인증되지 않은 요청은 바다를 건너지 않습니다.
• 지역 기반 개인화 – 언어, 통화, 규정 준수 라우팅을 사용자에게서 밀리초 거리에서 결정합니다.
• A/B 및 기능 버킷 배정 – 엣지에서 쿠키를 할당하므로 페이지가 로드되기 전부터 일관됩니다.
• 속도 제한과 봇 방어 – 경계에서 남용을 흡수하며, PoP별 카운터는 엣지 KV에 둡니다.
• 넓은 의미의 엣지 컴퓨팅 – IoT/통신 맥락입니다. 공장 센서와 5G 인프라가 로컬에서 처리하는 영역으로, 별도 글에서 다룰 깊이라는 점만 한 줄로 짚어 둡니다.

엣지 함수를 사용해야 할까? 결정 매트릭스

한계와 트레이드오프

• 런타임은 부분집합입니다. 웹 표준 API만 쓸 수 있습니다. 네이티브 바인딩을 쓰는 ORM, 이미지 라이브러리, 파일시스템에 의존하는 코드는 실행되지 않으므로 도입 전에 의존성 트리를 확인해야 합니다.
• CPU 상한이 엄격합니다. 연산 예산은 수십 밀리초입니다. 엣지 함수는 트래픽을 다듬을 뿐, 처리하지는 않습니다.
• 상태는 설계상 다른 곳에 있습니다. 상태가 필요한 모든 일은 오리진이나 최종 일관성을 따르는 엣지 KV로 라우팅됩니다. 어느 쪽도 공짜가 아닙니다.
• 디버깅이 분산됩니다. 특정 지역의 PoP 한 곳에서만 일어나는 버그를 재현하는 것은 그 자체로 별도의 노하우가 필요한 일입니다. 모든 곳의 로그를 중앙에 모으는 것이 완화책입니다.
• 추는 흔들립니다. 엣지 우선 기본값은 이미 한 번 후퇴했습니다. 엣지를 아키텍처의 정체성이 아니라 게이트웨이 로직을 위한 정밀한 도구로 다뤄야 합니다.

Back4app에서의 엣지

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 글이 그리는 3계층 구조에서 Back4app은 제대로 만든 오리진입니다. 데이터베이스와 Cloud Code 비즈니스 로직이 함께 있어 데이터 작업을 빠르게 만드는 공동 배치가 이루어지고, 그 앞에는 엣지 계층이 사용할 것과 같은 PoP에서 파일과 정적 자산을 제공하는 CDN이 있습니다. 엣지 함수는 세 조건이 성립하는 곳에서 얇은 게이트웨이 로직으로 그 앞에 끼워 넣으면 됩니다. 여기서는 리디렉션, 저기서는 토큰 확인을 처리하고, 데이터를 소유하며 모든 요청에 ACL을 적용하는 오리진으로 넘깁니다. 솔직한 섹션이 가르치는 아키텍처의 교훈, 즉 연산은 사용자 가까이에서, 데이터 작업은 데이터 가까이에서라는 원칙이 정확히 이 분담이며, 각 계층은 지리가 유리하게 작용하는 부분을 맡습니다.