서버리스, 만능 도구가 아닌 전문화된 도구로의 회귀: DenoDeploy 사례와 시사점

핵심 기술

서버리스(FaaS)의 이상적인 약속과 실제 구현 간의 괴리를 Deno Deploy의 지역 축소 사례를 통해 분석하며, 서버리스가 만능 해결책이 아닌 특정 사용 사례에 적합한 전문화된 도구임을 강조합니다.

기술적 세부사항

• 서버리스의 초기 약속: 관리할 서버 없음, 함수 배포 후 자동 확장, 사용한 만큼만 지불.
• 적합한 사용 사례: 웹훅, 스케줄된 작업, 백그라운드 작업, 소규모 API, 버스티 트래픽.
• 실제 앱에서의 한계: 데이터베이스 연동, 빠른/일관된 지연 시간 요구, 세션/인증, 장기 실행 로직 등에서 콜드 스타트, 지연 시간 스파이크, 복잡한 워크어라운드 발생.
• Deno Deploy의 변화: 전역 35개 리전에서 6개로 축소하며 성능 향상, '어디에나 동시' 함수 플랫폼에서 '전체 앱 호스팅' 플랫폼으로 전환.
• Deno의 새로운 기능 (앱 호스팅 지향): 리전 고정, KV 스토리지, 상태+컴퓨트(Durable Objects 스타일), 백그라운드 작업, 서브프로세스, 빌드 파이프라인.
• 타 플랫폼의 유사한 움직임: Cloudflare (KV, R2, Durable Objects, D1), Vercel (Fluid Compute).
• 벤더 종속성 문제: 각 플랫폼의 독자적인 서비스(KV, Durable Objects 등)는 해당 스택에만 작동하며, 자체 호스팅 불가 또는 인프라 종속성 발생.
• 전역 배포의 복잡성: 대부분의 앱은 단일 리전으로 충분하며, 전역 배포는 일관성, 복제, 지연 시간, CAP 이론 등의 복잡성 증가.
• 실질적인 서버리스 한계: 실행 시간/메모리/함수 크기 제한, 콜드 스타트, 불완전한 Node.js 호환성 등.
• 결론: 서버리스는 '빠른 API', '백그라운드 작업', '상태 없는 엣지 컴퓨트' 등 전문화된 도구로 사용해야 하며, 완전한 제품에는 컨테이너, 앱 서버, 예측 가능한 인프라가 더 적합.

개발 임팩트

• 불필요한 복잡성과 기술 부채를 줄이고, 애플리케이션의 실제 요구사항에 맞는 최적의 인프라스트럭처를 선택하는 데 도움을 줍니다.
• 서버리스의 강점을 정확히 이해하고 활용함으로써 개발 효율성을 높일 수 있습니다.
• 벤더 종속성을 최소화하고 더 유연한 개발 환경을 구축하는 데 기여합니다.

커뮤니티 반응

본문에서는 구체적인 커뮤니티 반응을 직접적으로 언급하지는 않았으나, Deno Deploy의 지역 축소 발표 자체가 서버리스 커뮤니티 내에서 'FaaS의 한계'에 대한 논의를 촉발하는 계기가 될 수 있음을 시사합니다.