Edge Computing, 실제로 써볼 만한 사례들

Edge가 뭔지는 알겠는데 언제 쓰나

유저에게 물리적으로 가까운 서버에서 코드를 실행한다. 개념은 간단하다. 근데 "그래서 내 프로젝트에 쓸 일이 있나?"라는 질문에는 바로 답이 안 됐다. 그래서 직접 몇 가지를 테스트해봤다.

사용자의 지역에 따라 다른 백엔드 서버로 라우팅하는 로직이 있었다. 기존에는 싱가포르에 있는 API Gateway에서 처리했는데, 한국 사용자 기준 왕복 시간이 평균 89ms였다.

이걸 Cloudflare Workers로 옮겼더니 12ms로 줄었다. 한국 엣지 노드에서 바로 처리되니까. 이건 확실히 효과가 있었다.

A/B 테스트 분기를 서버에서 하면 응답이 느려지고, 클라이언트에서 하면 화면이 깜빡인다. Edge에서 하면 둘 다 해결된다.

Vercel Edge Middleware에서 쿠키를 확인하고 A/B 그룹에 따라 다른 페이지를 보여줬다. 깜빡임 없이 1ms 이내에 분기가 됐다. 이건 꽤 실용적이었다.

(이건 좀 감동이었다.)

사용자 디바이스에 따라 이미지 사이즈를 조절하는 걸 Edge에서 해봤다. User-Agent를 보고 모바일이면 작은 이미지, 데스크탑이면 큰 이미지를 내려주는 로직이다.

근데 여기서 문제를 만났다. 이미지 리사이징 자체가 CPU를 많이 쓰는데, Edge 환경은 CPU 제한이 빡세다. Cloudflare Workers 기준 CPU 시간 10ms 제한이 있다. 큰 이미지를 리사이징하면 이 제한에 걸린다.

결국 이미지 최적화는 Edge보다 CDN의 이미지 변환 기능(Cloudflare Image Resizing 같은)을 쓰는 게 맞았다. Edge가 만능이 아니라는 걸 여기서 배웠다.

런타임 제한이 크다. Node.js API를 전부 쓸 수 없다. fs, net 같은 모듈이 없다. 외부 패키지도 Edge 호환이 안 되는 게 많다. 한번은 bcrypt를 Edge에서 쓰려다가 안 돼서 @noble/hashes로 교체한 적이 있다.

그리고 실행 시간 제한. Vercel Edge Functions는 25초, Cloudflare Workers는 무료 플랜 기준 10ms CPU 시간이다. DB 쿼리 여러 개 날리는 복잡한 로직은 못 돌린다.

지역 기반 라우팅, A/B 테스트 분기, 인증 토큰 검증, 헤더 조작, 리다이렉트 로직. 이런 "가볍지만 빠르게 처리해야 하는" 로직에 Edge가 딱이다.

반대로 DB 접근이 필요하거나, 무거운 연산이 필요하거나, Node.js 특정 API에 의존하는 로직은 일반 서버가 맞다.

Edge를 쓸지 말지의 기준은 단순하다. "이 로직에 DB가 필요한가?" 필요하면 서버, 아니면 Edge를 검토해볼 만하다. 물론 이것도 케이스에 따라 다르지만.