2025년 서버리스 혁신: CoreWeave 강화학습과 Unkey 아키텍처 전환 사례 분석

서버리스 컴퓨팅과 강화 학습, 서로 어울리지 않을 것 같은 두 기술이 만났습니다. CoreWeave가 2025년 10월에 선보인 ‘Serverless RL’은 AI 에이전트 개발에 어떤 혁명을 가져왔을까요?

Serverless 강화 학습의 혁신적 등장

지난 2025년 10월, 클라우드 인프라 제공업체인 CoreWeave는 산업에 큰 파장을 일으킨 발표를 했습니다. 바로 ‘Serverless Reinforcement Learning’ 서비스의 공개였습니다. 이는 단순히 새로운 기능의 추가가 아닌, AI 에이전트 개발 분야에서의 패러다임 전환으로 평가받고 있습니다.

전통적으로 Serverless 아키텍처는 API 백엔드나 이벤트 처리와 같은 단순한 작업에만 적합하다고 여겨졌습니다. 강화 학습은 계산 집약적이며 복잡한 상태 관리가 필요한 작업이기 때문에, Serverless 컴퓨팅과는 상충되는 특성을 가진 것으로 인식되어 왔습니다. 그러나 CoreWeave는 이 한계를 극복하고, 상태 유지가 필요한 AI 훈련 작업을 Serverless 방식으로 구현하는 데 성공했습니다.

CoreWeave의 Serverless RL: 핵심 기술 분석

Serverless 강화 학습의 주요 특징

CoreWeave의 Serverless RL 서비스는 Weights & Biases와 OpenPipe라는 강력한 파트너사들과의 협력을 통해 개발되었습니다. 이 플랫폼은 완전 관리형 강화 학습 환경을 제공하며, 사용자는 사용한 만큼만 비용을 지불하는 Pay-as-you-go 모델의 혜택을 누릴 수 있습니다.

기술적 구현의 핵심

Serverless RL이 실현 가능한 이유는 다음의 세 가지 기술적 혁신에 있습니다:

첫째, 자동 확장 GPU 클러스터입니다. RL 훈련의 변동하는 컴퓨팅 요구에 따라 GPU 자원이 자동으로 확장되고 축소됩니다. 이는 사용자가 인프라 용량을 미리 예측하고 준비할 필요가 없다는 의미입니다.

둘째, 통합 실험 관리 시스템입니다. Weights & Biases와의 통합을 통해 RL 실험의 진행 과정을 실시간으로 추적하고, 결과를 효과적으로 분석할 수 있습니다.

셋째, 데이터 파이프라인 최적화입니다. OpenPipe와의 협력을 통해 학습 데이터의 수집, 처리, 전달이 효율적으로 이루어집니다.

Serverless 강화 학습이 가져오는 혁신

개발 속도와 생산성의 획기적 향상

Serverless RL의 가장 주목할 만한 성과는 개발 속도의 3-5배 향상입니다. 이는 단순한 숫자가 아닙니다. 인프라 설정과 관리에 소요되던 시간이 80% 감소했다는 의미입니다.

기존의 강화 학습 개발 방식에서는 개발팀이 GPU 클러스터 구성, 네트워크 설정, 모니터링 도구 설치 등 수많은 인프라 작업을 직접 수행해야 했습니다. 그러나 Serverless RL의 등장으로, AI 연구자와 개발자는 알고리즘 개선과 모델 최적화에만 집중할 수 있게 되었습니다.

비용 효율성과 민주화

Serverless 기반의 과금 모델은 강화 학습의 접근성을 대폭 높였습니다. 기존에는 고성능 RL 훈련을 위해 상당한 초기 투자가 필요했습니다. 그러나 Serverless RL을 통해 작은 팀도 대규모 AI 에이전트를 훈련할 수 있게 된 것입니다. 비활성 기간에는 비용이 발생하지 않기 때문에, 프로젝트의 초기 단계나 실험 단계에서 매우 경제적입니다.

인프라 관리 부담의 대폭 감소

AI 연구자와 개발자가 인프라 관리에 소요하던 시간을 70% 이상 절감할 수 있다는 것은, 전체 프로젝트 타임라인에서 상당한 변화를 의미합니다. 이는 단순히 개인의 생산성 향상을 넘어, 조직 전체의 혁신 속도를 가속화합니다.

Serverless RL의 실무적 의미

CoreWeave의 기술 책임자는 다음과 같이 언급했습니다:

“이제 AI 연구자들은 서버 관리나 인프라 확장에 신경 쓰지 않고, 오직 알고리즘과 모델 개선에만 집중할 수 있습니다. Serverless RL은 AI 개발의 민주화를 가속화할 것입니다.”

이 발언은 단순한 마케팅 메시지가 아닙니다. 이는 AI 개발 생태계에서 기술적 진입장벽이 낮아지고 있다는 의미입니다. 지금까지 대규모 자본을 가진 기업들의 특권이었던 고성능 RL 훈련이, 이제는 개별 연구자나 소규모 스타트업도 접근 가능한 영역이 되었습니다.

Serverless 강화 학습의 미래 전망

Serverless RL의 등장은 클라우드 컴퓨팅 분야에서 새로운 질문을 던졌습니다. “서버리스는 정말 모든 워크로드에 적합한가?” 이 질문에 대한 답은 더 이상 단순한 ‘Yes’ 또는 ‘No’가 아닙니다.

CoreWeave의 사례는 Serverless 기술의 경계를 확장할 수 있음을 증명했습니다. 계산 집약적이고 상태 관리가 필요한 강화 학습 작업도 Serverless 방식으로 구현 가능한 것입니다. 이는 향후 더 많은 고도화된 AI/ML 워크로드가 Serverless 형태로 제공될 가능성을 열어두었습니다.

앞으로 우리는 단순한 API 처리나 데이터 변환에만 국한되지 않는, 다양한 산업과 분야에 최적화된 Serverless 서비스들을 목격하게 될 것입니다. Serverless RL은 이러한 변화의 시작점이 될 가능성이 높습니다.

서버리스 RL의 핵심 기술과 구현 방식

강화 학습의 계산 집약적 특성과 서버리스의 무상태성은 어떻게 조화를 이루었을까요? 자동 확장 GPU 클러스터와 데이터 파이프라인 최적화를 통한 기술 혁신의 비밀을 살펴봅니다.

서버리스 RL이 극복해야 했던 기술적 난제

전통적으로 강화 학습은 서버리스 아키텍처와 양립하기 어려운 분야로 인식되었습니다. 강화 학습 모델을 훈련하기 위해서는 지속적인 상태 유지, 대규모 GPU 자원의 할당, 그리고 수 시간에서 수일에 걸친 장시간 계산이 필수적이기 때문입니다. 반면 전통적인 서버리스 컴퓨팅은 상태 비저장(stateless) 방식으로 설계되어, 함수 호출이 종료되면 이전의 메모리 상태를 보존하지 않습니다. 이는 AI 에이전트 훈련 과정에서 중단되는 치명적인 문제가 될 수 있었습니다.

CoreWeave의 Serverless RL은 이 모순을 해결하기 위해 서버리스 컴퓨팅의 개념을 근본적으로 재정의했습니다. 단순히 함수 실행의 관점에서 벗어나, 확장성 있는 인프라 관리와 완전 관리형 서비스라는 서버리스의 본질적 가치에 초점을 맞춘 것입니다.

자동 확장 GPU 클러스터: 탄력성 있는 자원 할당

서버리스 RL의 핵심 기술 중 하나는 자동 확장 GPU 클러스터(Auto-scaling GPU Cluster) 입니다. 이는 강화 학습 훈련의 변동하는 컴퓨팅 요구에 따라 GPU 자원을 동적으로 할당 및 해제하는 기술입니다.

강화 학습 작업의 특성을 살펴보면, 에이전트가 환경과 상호작용하며 경험을 축적하는 초기 단계에서는 높은 컴퓨팅 파워가 필요합니다. 그러나 훈련이 진행되어 수렴 단계에 접어들면, 필요한 리소스가 상대적으로 감소합니다. 또한 실험마다 요구되는 GPU 개수도 달라집니다. 모델의 복잡도에 따라 8개부터 수십 개의 GPU가 필요할 수 있으며, 이를 모두 미리 확보해 두면 비용 낭비가 심각합니다.

CoreWeave의 자동 확장 GPU 클러스터는 이러한 변동성을 실시간으로 감지하고, 필요한 만큼의 GPU를 자동으로 프로비저닝합니다. 훈련 작업이 완료되거나 리소스 요구가 감소하면, 할당된 GPU는 자동으로 반환됩니다. 이를 통해 연구팀은 사용한 만큼만 비용을 지불하게 되며, 인프라 관리의 복잡성은 제거됩니다.

기술적으로, 이는 Kubernetes 기반의 오토스케일링 메커니즘에 GPU 리소스 매니지먼트 레이어를 추가한 것으로 볼 수 있습니다. 강화 학습 프레임워크(PyTorch, TensorFlow 등)의 메트릭을 모니터링하면서, 메모리 사용률, 계산 대기 시간, 배치 처리 크기 등을 종합적으로 분석하여 최적의 확장 정책을 결정합니다.

통합 실험 관리: Weights & Biases와의 협력

서버리스 RL의 두 번째 핵심 혁신은 Weights & Biases와의 네이티브 통합입니다. 강화 학습 프로젝트에서 실험 관리는 매우 중요한 과제입니다. 수십 개의 서로 다른 하이퍼파라미터 조합으로 진행되는 실험들을 추적하고, 각 실험의 성능 지표를 비교하며, 최적의 모델을 선별하는 과정은 매우 복잡합니다.

전통적으로는 연구자들이 텍스트 파일이나 스프레드시트에 실험 결과를 수동으로 기록하거나, 별도의 모니터링 도구를 구축해야 했습니다. 이는 시간이 걸릴 뿐 아니라 오류가 발생할 가능성이 높습니다. Weights & Biases의 통합을 통해 강화 학습 훈련 중 생성되는 모든 메트릭(에피소드 리워드, 정책 손실, 가치 함수 손실, 엔트로피 등)이 자동으로 수집되고 시각화됩니다.

이러한 통합은 단순한 데이터 수집을 넘어, 실험 결과의 재현성 확보와 버전 관리를 가능하게 합니다. 어떤 데이터, 어떤 코드 버전, 어떤 하이퍼파라미터로 훈련된 모델인지가 명확히 기록되므로, 나중에 유사한 결과를 다시 얻거나 특정 실험을 분석하는 것이 용이합니다. 또한 팀 구성원들이 서로의 실험 진행 상황을 실시간으로 모니터링할 수 있어, 협업 효율이 대폭 향상됩니다.

데이터 파이프라인 최적화: OpenPipe와의 전략적 협력

서버리스 RL의 세 번째 기술적 기둥은 OpenPipe와의 협력을 통한 데이터 파이프라인 최적화입니다. 강화 학습 훈련 프로세스에서 데이터 처리는 전체 계산 시간의 상당 부분을 차지합니다. 환경으로부터 수집된 원시 경험 데이터(상태, 액션, 리워드 등)를 정규화하고, 배치로 샘플링하고, 강화 학습 알고리즘에 입력할 수 있는 형태로 변환하는 과정이 효율적이지 못하면, 전체 훈련 속도가 GPU의 능력보다 훨씬 낮은 수준에서 머물게 됩니다.

OpenPipe와의 협력을 통해 CoreWeave는 다음과 같은 데이터 파이프라인 최적화를 구현했습니다:

병렬 데이터 처리: 원시 데이터 수집, 정규화, 배치 샘플링 등의 작업이 서로 다른 CPU 클러스터에서 병렬로 수행됩니다. 이를 통해 GPU는 항상 처리할 데이터가 준비된 상태를 유지하게 되어, GPU 유휴 시간을 최소화합니다.

적응형 배치 크기 조정: 현재의 시스템 부하와 메모리 상황에 따라 배치 크기를 동적으로 조정합니다. 메모리 여유가 충분할 때는 배치를 크게 하여 처리량을 높이고, 메모리 부담이 클 때는 자동으로 축소합니다.

캐싱 및 프리페칭: 자주 사용되는 데이터는 고속 메모리에 캐싱하고, 다음 에포크에서 필요할 데이터를 미리 준비(프리페칭)하여 대기 시간을 제거합니다.

이러한 최적화를 통해 데이터 처리로 인한 병목 현상이 크게 완화되며, 훈련 속도가 3-5배 향상됩니다.

서버리스 인프라의 실제 구현 아키텍처

CoreWeave의 Serverless RL 아키텍처는 다음과 같은 계층으로 구성됩니다:

사용자 인터페이스 계층: 연구자는 단순한 Python API나 CLI를 통해 강화 학습 훈련 작업을 제출합니다. 복잡한 클러스터 설정이나 리소스 할당 명령어를 입력할 필요가 없습니다.

작업 스케줄러 계층: 제출된 작업을 큐에 대기시키고, 현재 클러스터 상태와 작업의 우선순위를 고려하여 실행 일정을 결정합니다. 동일한 하드웨어 요구사항을 가진 작업들을 그룹화하여 효율성을 높입니다.

리소스 오케스트레이션 계층: Kubernetes를 기반으로 GPU 리소스의 할당, 재배치, 회수를 관리합니다. 컨테이너 이미지를 배포하고, 네트워킹과 스토리지를 설정합니다.

강화 학습 런타임 계층: 실제 강화 학습 프레임워크가 실행되는 계층으로, PyTorch Lightning이나 Ray RLlib 같은 분산 강화 학습 라이브러리를 지원합니다.

모니터링 및 로깅 계층: Weights & Biases, Prometheus, ELK Stack 등과 통합되어 실시간 모니터링 및 사후 분석을 지원합니다.

기술적 혁신의 실제 효과

CoreWeave의 기술 혁신은 수치로 입증됩니다:

• 개발 속도 향상: 인프라 설정에 소요되던 시간이 80% 감소하여, 연구팀은 실제 모델 개발에 집중할 수 있게 되었습니다.
• 비용 효율성: 종전의 상태 유지 클러스터와 비교할 때, 사용하지 않는 시간의 비용을 절감하여 총 운영 비용을 40-60% 감소시킵니다.
• 시간당 비용 단위의 투명성: 종전의 복잡한 가격 모델에서 벗어나, 사용한 GPU 시간만큼만 과금하는 명확한 비용 구조를 제공합니다.

이러한 개선사항들이 결합되면서, 소규모 AI 연구팀도 대기업 수준의 인프라를 활용할 수 있게 되었습니다. 서버리스 RL은 단순한 기술 혁신이 아니라, AI 개발의 민주화를 실현하는 기술적 기반이 되고 있습니다.

서버리스에 대한 현장 반응: Unkey의 상태 유지 서버 전환 이야기

한편에서는 CoreWeave가 강화 학습까지 서버리스로 확장하고 있을 때, 흥미로운 반대의 움직임이 일어나고 있습니다. API 인증 서비스를 제공하는 Unkey는 기존의 Serverless 아키텍처를 과감하게 포기하고 Go 기반의 상태 유지 서버로 전환했습니다. 이 결정은 단순한 기술 선택이 아니라, Serverless 기술이 모든 워크로드에 최적이 아니라는 실질적인 증거를 제시합니다.

왜 Unkey는 Serverless를 떠났을까?

Unkey의 기술팀이 직면한 문제는 명확했습니다. 기존에 Cloudflare Workers 기반의 Serverless 아키텍처를 사용하고 있었지만, 점차적으로 성능 병목현상에 부딪히게 되었습니다. 특히 API 인증이라는 워크로드의 특성상, 매 요청마다 일관되고 빠른 응답이 필수적이었습니다.

Serverless의 핵심 특징인 “무상태성”은 일반적으로 비용 효율성과 자동 확장 측면에서 장점으로 작용합니다. 하지만 API 인증과 같이 영속적인 상태 관리와 극도로 낮은 지연 시간이 필요한 작업에서는 오히려 성능 저하의 원인이 되었습니다.

성능 개선의 수치가 말해주는 것

Unkey의 전환이 가져온 성능 개선은 수치로 명확하게 드러납니다:

응답 속도 개선: p99 기준으로 30ms에서 5ms로 개선 – 무려 6배의 성능 향상이 달성되었습니다. 이는 단순한 최적화를 넘어선 근본적인 아키텍처 변화의 효과입니다.

이러한 극적인 개선이 가능했던 이유는 상태 유지 서버 도입에 있습니다. Go 기반 상태 유지 서버는 로컬 메모리 기반의 캐싱을 활용하여, Serverless 환경에서 필요했던 네트워크 기반 외부 캐싱 라이브러리를 완전히 제거할 수 있었기 때문입니다.

아키텍처 단순화의 가치

성능 개선만큼 중요한 것은 아키텍처의 단순화였습니다. 기존 Serverless 아키텍처에서는 무상태성의 한계를 극복하기 위해 다음과 같은 복잡한 구조가 필요했습니다:

• 분산 캐싱 레이어 (Redis 등)
• 데이터 파이프라인의 중간 처리 단계
• 요청 간 상태 동기화 메커니즘
• 여러 외부 서비스 간의 통합 로직

Serverless 아키텍처에서 벗어나 상태 유지 서버로 전환하면서, 이러한 모든 보조 시스템이 필요 없어졌습니다. 결과적으로 개발팀은 더 단순하고 이해하기 쉬운 애플리케이션 구조를 갖게 되었고, 이는 곧 유지보수 비용 절감과 개발 생산성 향상으로 이어졌습니다.

Serverless 대 상태 유지 서버: 워크로드별 비교

Unkey의 경험은 두 아키텍처의 특성 차이를 명확하게 보여줍니다:

지연 시간 측면: Serverless는 함수 호출 간 영속적 메모리가 없어 매번 네트워크를 통해 데이터를 가져와야 하므로 고유의 지연이 발생합니다. 반면 상태 유지 서버는 로컬 메모리 기반 캐싱으로 초저지연을 달성할 수 있습니다.

아키텍처 복잡도: Serverless는 무상태성을 우회하기 위해 복잡한 보조 서비스들이 필요하지만, 상태 유지 서버는 단순한 애플리케이션 구조로 동일한 기능을 구현할 수 있습니다.

비용 모델: Serverless는 요청당 과금되며 비활성 시 자동 일시중지되지만, 상태 유지 서버는 고정 비용 구조입니다. 트래픽이 일정한 수준 이상이라면, 상태 유지 서버가 더 경제적일 수 있습니다.

적합한 워크로드: API 인증처럼 일관된 저지연이 필수적이거나 영속적 상태 관리가 필요한 워크로드는 상태 유지 서버가 더 적합합니다. 반면 비정기적이고 예측 불가능한 트래픽 패턴의 워크로드는 Serverless가 여전히 이상적입니다.

Unkey의 추가 이점: 플랫폼 독립성

Go 기반 상태 유지 서버로의 전환은 성능과 단순성 외에도 또 다른 자유도를 제공했습니다. 바로 플랫폼 독립성입니다. 이전의 Serverless 아키텍처는 특정 클라우드 제공업체(Cloudflare)에 종속되어 있었지만, Go 기반 서버는 어디서나 호스팅할 수 있습니다.

개발자들은 이제 Unkey를 셀프 호스팅할 수 있게 되었고, 이는 기업 고객들에게 더 많은 제어권과 유연성을 제공합니다. 이러한 유연성은 단순히 기술적 이점을 넘어, 비즈니스 차원에서도 중요한 가치를 창출합니다.

Serverless 기술에 대한 재고찰

Unkey의 사례는 중요한 교훈을 제공합니다. Serverless는 모든 워크로드의 만능 솔루션이 아니라, 특정 유형의 워크로드에 최적화된 도구라는 사실입니다.

기술 선택은 추상적인 아키텍처 철학보다는 실제 비즈니스 요구사항과 기술적 제약조건을 중심으로 이루어져야 합니다. Unkey가 Serverless에서 떠난 것은 기술의 한계를 인정하고, 자신들의 워크로드에 더 적합한 솔루션을 선택한 현명한 결정이었습니다.

CoreWeave가 강화 학습까지 Serverless로 확장하고 있는 동시에, Unkey는 Serverless에서 벗어나고 있습니다. 이 두 사례는 2025년 서버리스 기술의 현주소를 가장 잘 대표합니다. 더 이상 Serverless 또는 아님의 선택이 아니라, “어떤 워크로드에 어떤 아키텍처를 적용할 것인가”라는 더 정교한 기술 의사결정이 필요한 시점입니다.

섹션 4. 서버리스와 상태 유지 서버: 장단점과 하이브리드 전략의 부상

서버리스와 상태 유지 서버는 각각 어떤 업무에 더 적합할까요? 지연 시간, 아키텍처 복잡도, 비용 모델까지 완벽 비교하며, 하이브리드 아키텍처가 왜 주목받는지 이해해 봅시다.

Serverless와 상태 유지 서버의 핵심 차이

클라우드 컴퓨팅의 역사 속에서 Serverless는 혁신적인 패러다임으로 등장했습니다. 개발자가 인프라를 관리할 필요 없이 코드 실행에만 집중할 수 있다는 약속은 많은 조직에 큰 매력이었습니다. 그러나 최근 몇 년간의 실전 경험은 흥미로운 진실을 드러냈습니다. 바로 Serverless가 모든 워크로드에 최적의 해결책은 아니라는 점입니다.

실제로 API 인증 서비스를 제공하는 Unkey의 사례는 이를 명확히 보여줍니다. Unkey는 처음에 Cloudflare Workers 기반의 Serverless 아키텍처를 선택했지만, 나중에 Go 기반의 상태 유지 서버로 전환하면서 놀라운 성과를 얻었습니다. 응답 속도는 6배나 개선되었고, p99 기준으로 30ms에서 5ms로 단축되었습니다.

이러한 사례들이 보여주는 것은 기술 선택이 단순한 유행을 따르는 것이 아니라, 실제 요구사항을 기반으로 한 전략적 결정이어야 한다는 점입니다.

성능과 비용: 상황별 비교 분석

지연 시간(Latency) 측면에서 두 아키텍처는 뚜렷한 차이를 보입니다. Serverless 아키텍처는 함수 호출 간에 영속적 메모리를 유지하지 않기 때문에, 매번 네트워크 기반 캐싱에 의존해야 합니다. 반면 상태 유지 서버는 로컬 메모리 기반 캐싱을 통해 초저지연을 달성합니다. 이는 Unkey의 성능 개선 사례에서 명확히 드러났습니다.

아키텍처 복잡도 역시 중요한 고려사항입니다. Serverless 모델에서 무상태성을 우회하려면 복잡한 보조 서비스들이 필요합니다. 데이터베이스 연결 풀, 분산 캐싱 시스템, 메시지 큐 등 다양한 외부 서비스를 조율해야 하는데, 이는 시스템 복잡도를 크게 증가시킵니다. 반면 상태 유지 서버는 이러한 복잡성을 상당 부분 줄일 수 있으며, 더 단순하고 이해하기 쉬운 애플리케이션 구조를 유지할 수 있습니다.

비용 모델에서도 특성이 다릅니다. Serverless는 요청당 과금되며 비활성 시 자동으로 일시중지되어, 트래픽이 불규칙한 워크로드에는 경제적입니다. 그러나 일관된 트래픽을 처리해야 한다면, 고정 비용의 상태 유지 서버가 더 효율적일 수 있습니다. 특히 대규모 트래픽을 처리하는 경우, Serverless의 누적 과금이 예상 외로 높아질 수 있습니다.

워크로드 특성에 따른 선택 기준

Unkey의 기술 블로그는 명확한 결론을 제시합니다. Serverless는 비정기적 워크로드나 단순한 요청/응답 패턴에 이상적이지만, 일관된 저지연이 필요하거나 영속적 상태 관리가 필수적인 경우에는 상태 유지 서버가 더 효과적이라는 것입니다.

실제로 두 기술의 적합한 워크로드는 명확하게 구분됩니다. 예약 시스템, 데이터 처리 배치 작업, 이벤트 기반 자동화 같은 비정기적 업무는 Serverless가 탁월합니다. 반면 고객 요청이 실시간으로 들어오는 결제 시스템, API 게이트웨이, 또는 실시간 데이터 분석이 필요한 서비스는 상태 유지 서버가 적합합니다.

하이브리드 아키텍처: 최고의 선택지

현대적인 클라우드 아키텍처의 트렌드는 명확합니다. “모든 것을 Serverless로” 또는 “모든 것을 상태 유지 서버로”라는 이분법적 접근은 더 이상 유효하지 않다는 것입니다. 대신 하이브리드 아키텍처가 부상하고 있습니다.

하이브리드 아키텍처의 핵심 개념은 각 컴포넌트의 특성에 맞는 최적의 컴퓨팅 모델을 선택하는 것입니다. 예를 들어, API 게이트웨이와 인증 로직은 Serverless로 처리하되, 핵심 비즈니스 로직과 데이터 처리는 상태 유지 서버에서 담당하는 식입니다. 이러한 접근은 Serverless의 운영 편의성과 상태 유지 서버의 성능, 비용 효율성을 모두 활용할 수 있습니다.

실전 기업들의 선택

흥미롭게도, 최신 기술 발전은 이러한 하이브리드 전략의 필요성을 더욱 강조합니다. CoreWeave의 Serverless 강화 학습 서비스는 AI/ML 워크로드를 Serverless로 제공하려는 혁신적 시도이며, 이는 Serverless의 영역이 계속 확장되고 있음을 보여줍니다. 동시에 Unkey 같은 기업들의 아키텍처 전환 사례는 Serverless만으로는 충분하지 않은 상황들이 분명히 존재한다는 것을 증명합니다.

성공적인 기업들은 더 이상 이론적 최적성을 추구하지 않습니다. 대신 실제 비즈니스 요구사항, 성능 목표, 비용 제약을 종합적으로 고려하여 각 워크로드에 최적의 아키텍처를 설계합니다. 이것이 현대 클라우드 개발의 진정한 성숙함이라 할 수 있습니다.

의사결정 프레임워크: 언제 무엇을 선택할 것인가

기술 선택을 위한 실질적 가이드라인을 제시하면 다음과 같습니다. 먼저 지연 시간 요구사항을 평가하세요. 100ms 이상의 지연이 허용된다면 Serverless도 고려 대상이 되지만, 10-50ms 이하의 초저지연이 필요하다면 상태 유지 서버가 필수입니다.

다음으로 상태 관리의 필요성을 검토하세요. 세션 정보, 사용자 프로필 캐시, 실시간 상태 데이터 등 영속적 상태를 메모리에 유지해야 한다면, 상태 유지 서버가 더 적합합니다.

마지막으로 운영 복잡도와 비용의 균형을 고려하세요. 개발 리소스가 제한적이고 트래픽이 불규칙하다면 Serverless의 운영 편의성이 큰 가치입니다. 하지만 안정적이고 예측 가능한 트래픽이 있으며, 저지연 성능이 중요하다면 상태 유지 서버의 선택은 전략적으로 타당합니다.

서버리스 기술은 여전히 클라우드 컴퓨팅의 중요한 패러다임이지만, 이제는 “서버리스 또는 아님“의 단순한 이분법에서 벗어나 “어떤 워크로드에 서버리스를 어떻게 적용할 것인가“라는 더 정교한 고민이 필요합니다. 기술 선택은 더 이상 유행을 따르는 것이 아니라, 비즈니스 요구사항과 기술적 제약조건을 종합적으로 고려한 전략적 결정이 되어야 할 것입니다.

서버리스 기술의 미래: 정교한 워크로드 적용과 새로운 기회의 문

서버리스가 만능 열쇠가 아닌 ‘맞춤형 도구’로 진화하고 있습니다. 2024년부터 2025년 현재에 이르기까지, 클라우드 생태계에서는 흥미로운 두 가지 현상이 동시에 일어나고 있습니다. 한편으로는 CoreWeave의 Serverless RL처럼 기존의 경계를 넘어 새로운 영역으로 확장하는 사례들이 등장하고, 다른 한편으로는 Unkey처럼 Serverless 아키텍처에서 의도적으로 벗어나는 기업들이 나타나고 있습니다. 이러한 대비되는 움직임들이 시사하는 바는 명확합니다. 더 이상 업계는 단순히 “Serverless를 도입할 것인가, 말 것인가”라는 이분법적 질문에 머물러 있지 않다는 뜻입니다.

Serverless 기술의 다층적 확장: 혁신적 경계의 재설정

2025년 10월, CoreWeave의 Serverless Reinforcement Learning 출시는 이 변화의 정점을 보여줍니다. 강화 학습은 전통적으로 Serverless 컴퓨팅의 약점으로 간주되어 왔습니다. 계산 집약적인 작업, 영속적인 상태 관리, 예측 불가능한 리소스 수요—이 모든 요소들이 Serverless의 무상태(stateless) 철학과 상충되기 때문입니다.

그런데 CoreWeave는 이 한계를 기술적 혁신으로 극복했습니다. 자동 확장 GPU 클러스터, Weights & Biases와의 통합 실험 관리, OpenPipe를 통한 데이터 파이프라인 최적화—이러한 기술적 기반 위에서 Serverless RL은 다음과 같은 실질적 가치를 제공합니다:

• 개발 속도 3-5배 향상: 인프라 설정에 소요되던 시간이 80% 감소하여, AI 연구자들은 알고리즘 개선에만 집중 가능
• 비용 효율성 극대화: 사용한 만큼만 과금하는 모델로 소규모 팀도 엔터프라이즈급 RL 훈련 수행 가능
• 시간 절감: 인프라 관리에 소요되던 시간을 70% 이상 절감

CoreWeave의 기술 책임자는 이를 “AI 개발의 민주화 가속화”라 표현했습니다. Serverless가 더 이상 단순한 API 백엔드나 이벤트 처리에만 국한되지 않는다는 증거입니다.

Serverless 아키텍처의 한계 인식: Unkey 사례로 배우는 현실적 고찰

그러나 같은 시기에 다른 기업들은 정반대의 결정을 내렸습니다. API 인증 서비스 Unkey의 아키텍처 전환은 Serverless 기술에 대한 업계의 성숙한 이해를 보여주는 사례입니다.

Unkey는 Cloudflare Workers 기반의 Serverless 아키텍처에서 Go 기반 상태 유지 서버로 이동했습니다. 결과는 극적이었습니다:

• 응답 속도 6배 향상: p99 기준 30ms에서 5ms로의 개선
• 아키텍처 복잡도 감소: 복잡한 캐싱 라이브러리와 다중 데이터 파이프라인 제거
• 플랫폼 독립성 확보: 셀프 호스팅 가능으로 특정 제공업체 종속성 탈피

이 결정의 근본 원인은 무엇일까요? Unkey의 분석에 따르면, 그들의 워크로드는 Serverless의 특성과 맞지 않았습니다. API 인증 서비스는 일관된 저지연 응답과 영속적 상태 관리를 요구하는 작업입니다. Serverless는 함수 호출 간에 메모리를 유지하지 않기 때문에, 이를 보충하기 위해 외부 캐싱 서비스(Redis 등)와 복잡한 데이터 파이프라인이 필수적이 됩니다. 결국 Serverless의 “단순성”이라는 장점이 역설적으로 아키텍처를 복잡하게 만들었던 것입니다.

Serverless 워크로드의 적합성 기준: 정교한 선택의 프레임워크

두 사례의 대비를 통해 보면, Serverless 기술 선택의 핵심은 워크로드의 특성 분석에 있습니다. 다음 표는 어떤 상황에서 Serverless가 적합하고, 언제 상태 유지 서버가 더 나은지를 명확히 보여줍니다:

평가 기준	Serverless 아키텍처	상태 유지 서버
지연 시간 요구사항	수십~수백 ms 허용	단일 자릿수 ms 필수
상태 관리	무상태 또는 외부 저장소 기반	로컬 메모리 기반 영속성
아키텍처 복잡도	보조 서비스 필요로 실제로는 복잡	단순하고 자체 포함적
비용 모델	요청당 과금, 비활성 시 절감	고정 비용 + 선형 확장
적합 워크로드	비정기적 트래픽, 배치 작업	일관된 트래픽, 실시간 처리
개발 시간	빠른 프로토타이핑	인프라 관리 오버헤드

이 기준들을 바탕으로 보면:

• Serverless가 탁월한 분야: 데이터 처리, 이벤트 트리거 기반 작업, ML 모델 추론(CoreWeave의 RL처럼 최적화될 경우), 간헐적 API 호출
• 상태 유지 서버가 나은 분야: 실시간 인증/인가, 연속적인 데이터 스트림 처리, 일관된 저지연이 필수인 시스템

Serverless 보안 이슈: 확장 속에서 간과될 수 없는 위험

Serverless 기술이 확장되고 있는 가운데, 보안 문제도 함께 대두되고 있습니다. 학계의 최근 연구에 따르면, 공개 Serverless 저장소의 37%가 API 키, 데이터베이스 자격증명, 개인 정보 등 민감한 정보 노출 위험을 안고 있습니다. 이는 Serverless 아키텍처의 분산 특성이 보안 관리를 어렵게 만들기 때문입니다.

Serverless 환경에서의 보안 모범 사례:

1. 환경 변수 관리: 민감한 정보는 환경 변수나 전담 시크릿 관리 서비스(AWS Secrets Manager, HashiCorp Vault 등)에 저장
2. 함수 권한 최소화: 각 함수는 필요한 최소 권한(Principle of Least Privilege)만 부여
3. 감시 및 모니터링: Serverless 함수의 호출 패턴과 리소스 접근을 지속적으로 모니터링
4. 정기적인 감사: 공개 저장소에 민감한 정보가 커밋되지 않았는지 자동화된 스캔 실시

2025년의 Serverless 생태계: 새로운 기회와 전문화의 바람

Elastic Cloud Serverless의 새로운 AWS 리전 확장(ap-northeast-1, eu-west-2)과 Together AI의 LLM 특화 Serverless 모델은 한 가지 명확한 신호를 보내고 있습니다. Serverless는 점점 더 전문화되고 있다는 점입니다.

더 이상 범용 Serverless 플랫폼만 존재하는 것이 아닙니다. 대신 다음과 같은 특화된 Serverless 서비스들이 등장하고 있습니다:

• Serverless RL: AI 에이전트 훈련에 최적화
• Serverless Search & Analytics: 검색 및 분석 워크로드 가속화
• Serverless LLM: 대규모 언어 모델 개발 및 실험 지원
• Serverless Database: 데이터베이스 스케일링 자동화

이러한 전문화는 Serverless 기술이 성숙해지고 있다는 증거입니다. 초기의 “일반적인 문제를 해결하는” Serverless 플랫폼에서 벗어나, 이제는 특정 도메인의 고유한 요구사항에 맞춘 최적화된 솔루션들이 나타나는 것입니다.

2025년 이후의 기술 선택: 현명한 의사결정을 위한 체크리스트

Serverless와 관련된 기술 결정을 내릴 때는 다음의 질문들을 자문해보세요:

1. 지연 시간 요구사항이 명확한가? (ms 단위 응답이 필수인가, 아니면 초 단위도 허용되는가?)
2. 상태 관리의 필요성은? (무상태로 처리 가능한가, 아니면 빈번한 상태 접근이 필요한가?)
3. 트래픽 패턴이 어떻게 분포하는가? (예측 불가능한 스파이크인가, 아니면 일정한가?)
4. 비용 효율성의 우선순위는? (요청 기반 과금의 절감이 주 목표인가, 아니면 안정성이 더 중요한가?)
5. 벤더 독립성이 얼마나 중요한가? (멀티 클라우드 전략을 고려하는가?)
6. 팀의 운영 역량은? (인프라 관리 인원을 할당할 수 있는가?)

이 질문들에 대한 답변이 곧 당신의 아키텍처 선택을 결정할 것입니다.

결론: “Serverless 또는 아님”에서 “적절한 Serverless 적용”으로

2025년의 클라우드 업계는 Serverless에 대해 더욱 성숙한 관점을 취하고 있습니다. CoreWeave는 기존에 불가능해 보였던 영역(강화 학습)에 Serverless를 성공적으로 적용했고, Unkey는 Serverless가 항상 최선의 선택이 아니라는 것을 증명했습니다. 이 두 사례는 모순적으로 보이지만, 사실은 같은 교훈을 가르칩니다.

기술은 도구일 뿐, 문제 해결 방법이 아닙니다.

Serverless는 특정 워크로드에 탁월한 효율성을 제공하지만, 모든 상황에 맞는 만능 열쇠는 아닙니다. 중요한 것은 당신의 비즈니스 요구사항, 기술적 제약조건, 팀의 역량을 종합적으로 고려하여 가장 적절한 컴퓨팅 모델을 선택하는 것입니다.

하이브리드 접근법은 더 이상 선택지가 아닌 필수입니다. API 게이트웨이는 Serverless로 관리하되, 핵심 비즈니스 로직은 상태 유지 서버로 구현하고, 배치 작업은 Serverless 함수로 처리하는 식의 다층적 아키텍처 구축이 현실적인 해법입니다.

2025년 이후의 클라우드 아키텍처 선택은 “이것이냐 저것이냐”의 단순한 이분법이 아닙니다. 대신 워크로드의 특성을 정확히 파악하고, 각 컴포넌트에 최적의 기술을 대응시키는 정교하고 전략적인 결정이 될 것입니다. 그리고 그것이 바로 클라우드 시대의 성숙함을 보여주는 신호입니다.