서버리스(Serverless)라는 말을 처음 들으면 자연스럽게 드는 의문이 있습니다. 서버가 없다는 건데, 그러면 데이터는 어디서 처리되는 걸까요. 사실 서버리스는 서버가 진짜로 없는 것이 아닙니다. 서버는 분명히 존재하지만, 개발자가 서버를 직접 관리하지 않아도 된다는 의미입니다. 이름이 다소 오해를 불러일으키는 측면이 있지만, 실제 개념은 꽤 실용적입니다. 이 글에서는 서버리스가 무엇인지, 왜 주목받는지, 어떤 상황에서 유용한지 살펴보겠습니다.

서버리스 이전의 상황

서버리스를 이해하려면 기존 방식과 비교하는 것이 도움이 됩니다. 전통적인 서버 운영 방식에서 개발자나 운영팀은 서버를 직접 관리해야 했습니다. 서버를 구매하거나 클라우드에서 가상 서버를 빌리고, 운영체제를 설치하고, 보안 패치를 적용하고, 트래픽에 맞게 서버 수를 조절하는 작업이 모두 필요했습니다.

7편과 8편에서 살펴본 클라우드 IaaS와 PaaS도 이 부담을 상당히 줄여줬지만, 여전히 서버 인스턴스를 직접 관리하고 항상 켜두어야 하는 부분이 남아 있었습니다. 사용자가 없는 새벽 시간에도 서버는 돌아가고 비용은 발생합니다. 서버리스는 이 부분까지 해결하려는 접근입니다.

서버리스의 핵심 개념

서버리스 컴퓨팅의 핵심은 코드 실행 단위로 서비스를 운영하는 방식입니다. 개발자는 특정 작업을 수행하는 함수(function) 단위의 코드를 작성해서 클라우드 플랫폼에 올려둡니다. 이 코드는 평소에는 실행되지 않고 대기 상태에 있다가, 특정 이벤트가 발생했을 때만 실행됩니다. 실행이 끝나면 다시 대기 상태로 돌아갑니다.

자판기에 비유할 수 있습니다. 자판기는 누군가 버튼을 누를 때만 음료를 뽑는 동작을 합니다. 아무도 없는 시간에도 전기는 조금 쓰지만, 실제 동작은 요청이 있을 때만 일어납니다. 서버리스도 요청이 왔을 때만 코드가 실행되고, 요청이 없으면 자원을 거의 소비하지 않습니다.

이 방식을 FaaS(Function as a Service)라고 부르기도 합니다. 함수 단위로 서비스를 제공한다는 의미입니다. AWS Lambda, Google Cloud Functions, Microsoft Azure Functions가 대표적인 FaaS 서비스입니다.

서버리스의 작동 방식

서버리스가 실제로 어떻게 작동하는지 구체적인 흐름을 살펴보겠습니다. 이미지 업로드 서비스를 예로 들어보겠습니다.

사용자가 이미지를 업로드하면 이벤트가 발생합니다. 이 이벤트가 서버리스 함수를 트리거합니다. 클라우드 플랫폼이 이 함수를 실행할 서버를 자동으로 준비합니다. 함수가 실행되면서 이미지를 리사이징하거나 썸네일을 생성하는 작업을 처리합니다. 작업이 완료되면 함수 실행이 종료되고, 서버 자원은 반납됩니다. 개발자는 이 과정에서 서버를 준비하거나 관리하는 작업을 전혀 하지 않아도 됩니다.

트리거가 될 수 있는 이벤트의 종류도 다양합니다. HTTP 요청, 파일 업로드, 데이터베이스 변경, 스케줄(특정 시간마다 실행), 메시지 큐 이벤트 등이 서버리스 함수를 실행시키는 트리거로 활용됩니다.

서버리스의 주요 장점

서버리스가 주목받는 이유는 몇 가지 실질적인 장점 때문입니다.

운영 부담의 획기적인 감소가 가장 큰 장점입니다. 서버 설정, 운영체제 관리, 보안 패치, 스케일링 설정 같은 인프라 작업을 클라우드 사업자가 전담합니다. 개발자는 비즈니스 로직을 담은 코드 작성에만 집중할 수 있습니다. 소규모 팀이나 인프라 전문 인력이 없는 조직에서 특히 유용할 수 있습니다.

사용한 만큼만 비용을 내는 구조도 매력적입니다. 기존 서버 방식에서는 사용자가 없어도 서버가 켜져 있는 동안 비용이 발생합니다. 서버리스는 함수가 실행된 횟수와 실행 시간에 따라 과금됩니다. 트래픽이 거의 없는 서비스나 간헐적으로 실행되는 작업에서는 비용을 크게 줄일 수 있습니다.

자동 확장도 서버리스의 강점입니다. 요청이 갑자기 몇 배로 늘어나도 클라우드 플랫폼이 자동으로 필요한 만큼 함수를 병렬 실행합니다. 개발자가 스케일링 설정을 미리 해두거나 트래픽을 예측할 필요가 없습니다.

비교 항목 전통적 서버 클라우드 IaaS 서버리스
서버 관리 직접 관리 일부 관리 관리 불필요
비용 구조 고정 비용 시간 기반 실행 횟수 기반
확장 방식 수동 확장 수동·반자동 자동 확장
유휴 비용 발생 발생 거의 없음

서버리스의 한계와 주의할 점

서버리스가 장점만 있는 것은 아닙니다. 실제로 도입을 검토할 때 고려해야 할 한계들이 있습니다.

콜드 스타트(Cold Start) 문제가 대표적입니다. 서버리스 함수는 평소에 실행되지 않고 대기하다가 요청이 오면 실행됩니다. 이때 함수를 실행할 환경을 새로 준비하는 시간이 필요한데, 이를 콜드 스타트라고 합니다. 첫 번째 요청이나 오랫동안 호출되지 않았던 함수가 실행될 때 수백 밀리초에서 수 초의 지연이 발생할 수 있습니다. 빠른 응답 시간이 중요한 서비스에서는 이 부분이 문제가 될 수 있습니다.

실행 시간 제한도 있습니다. 대부분의 서버리스 플랫폼은 함수 하나가 실행될 수 있는 최대 시간을 제한합니다. AWS Lambda의 경우 최대 15분입니다. 장시간 실행이 필요한 복잡한 작업에는 적합하지 않을 수 있습니다.

벤더 종속성도 고려해야 할 부분입니다. 서버리스 함수는 특정 클라우드 플랫폼의 방식에 맞게 작성되는 경우가 많아, 다른 플랫폼으로 이전하기가 어려울 수 있습니다. AWS Lambda로 개발된 함수를 Google Cloud Functions로 옮기려면 상당한 수정이 필요할 수 있습니다.

디버깅과 모니터링의 어려움도 있습니다. 서버에 직접 접속해서 로그를 확인하거나 문제를 추적하는 방식이 제한적이기 때문에, 서버리스 환경에 맞는 별도의 모니터링 도구와 방식이 필요합니다.

서버리스가 잘 맞는 상황

서버리스가 모든 상황에 최적인 것은 아닙니다. 어떤 상황에서 서버리스가 특히 유용한지 알아두면 실제 활용에 도움이 됩니다.

이벤트 기반의 간헐적 작업에 적합합니다. 파일 업로드 후 처리, 알림 발송, 정기적인 데이터 집계, 웹훅 처리 같은 작업이 여기에 해당합니다. 24시간 내내 실행될 필요가 없고 특정 조건에서만 실행되는 작업이라면 서버리스의 비용 효율이 극대화됩니다.

트래픽 예측이 어렵거나 변동이 큰 서비스에도 유리합니다. 이벤트성 캠페인, 계절성 서비스처럼 트래픽이 불규칙하게 변하는 경우, 서버리스의 자동 확장 특성이 장점으로 작용합니다.

반면 응답 속도가 매우 중요하거나, 장시간 실행이 필요하거나, 상태를 지속적으로 유지해야 하는 서비스에는 적합하지 않을 수 있습니다. 서버리스는 기존 서버 방식을 완전히 대체하는 것이 아니라, 특정 용도에서 효율적인 보완적 선택지로 보는 것이 현실적입니다.

서버리스의 현재와 앞으로의 전망

서버리스는 클라우드 컴퓨팅의 발전 방향 중 하나로 꾸준히 성장하고 있습니다. AWS Lambda가 2014년 출시된 이후 Google Cloud Functions, Azure Functions 등이 뒤를 이었고, 현재는 대부분의 주요 클라우드 사업자가 서버리스 서비스를 제공하고 있습니다.

콜드 스타트 문제를 줄이기 위한 기술 개선도 계속되고 있습니다. 사전 워밍(pre-warming) 기능, 최소 실행 인스턴스 유지 옵션 등이 도입되면서 실용성이 높아지고 있습니다. 서버리스와 컨테이너 기술이 결합된 형태도 등장하면서 기존 한계를 보완하는 방향으로 발전하고 있습니다.

정리하며

서버리스는 서버가 없는 것이 아니라, 개발자가 서버를 관리하지 않아도 되는 방식입니다. 코드를 함수 단위로 작성해 올려두면, 이벤트 발생 시에만 자동으로 실행되고 사용한 만큼만 비용이 청구됩니다. 운영 부담 감소, 비용 효율, 자동 확장이 주요 장점이지만 콜드 스타트, 실행 시간 제한, 벤더 종속성 같은 한계도 함께 고려해야 합니다. 모든 상황에 맞는 해결책이라기보다, 적합한 상황에서 효율적인 선택지로 활용하는 것이 현실적인 접근입니다.