서버리스 아키텍처는 언제 쓰면 좋을까

게시 2026.07.09 · 최종 업데이트 2026.07.14 · 약 6분 분량

서버리스 아키텍처는 개발자가 서버를 직접 준비하거나 관리하지 않고, 코드 실행에 필요한 환경을 클라우드 사업자가 대신 맡는 방식이다. 코드를 올려두면 요청이 들어올 때만 잠깐 실행되고, 실제 사용한 만큼만 비용을 내는 구조다. 서버 운영 부담을 덜고 싶은 소규모 팀이나, 트래픽이 시간대별로 크게 출렁이는 서비스에서 특히 관심을 받는다.

서버리스라는 이름의 진짜 의미

'서버가 없다'는 말은 오해를 부르기 쉽다. 서버는 여전히 어딘가에서 돌아가지만, 그 서버를 개발자가 신경 쓸 필요가 없다는 뜻에 가깝다. 물리 장비나 가상 머신을 직접 빌리고 설정하고 관리하던 과정을 클라우드 쪽에 넘긴다. 개발자는 실행할 코드와 그 코드가 언제 돌아갈지만 정의하면 된다.

대표적인 형태는 함수 단위로 코드를 실행하는 방식이다. 애플리케이션 전체를 항상 켜두는 대신, 필요한 기능을 작은 함수로 나눠 올려두고 특정 조건이 맞을 때만 불러 쓴다. 서버 준비와 확장, 보안 패치 같은 뒷일은 사업자가 처리한다. 이런 함수 단위 실행 방식은 FaaS(서비스형 함수)라는 이름으로도 불린다. 이 방식을 대중화한 상품이 AWS가 2014년 11월 리인벤트(re:Invent) 행사에서 공개한 람다이고, 이듬해 4월 정식 서비스가 됐다.

• 서버 임대와 설정, 유지보수를 직접 하지 않는다
• 코드는 대체로 작은 함수 단위로 쪼개 배포한다
• 확장과 패치 같은 운영은 사업자 몫으로 넘어간다

함수 하나가 어떻게 생겼는지 감을 잡는 데는 AWS 람다의 Node.js 핸들러가 좋은 예다. 요청을 받아 JSON을 돌려주는 최소 형태는 이렇다.

// AWS 람다(Node.js) 최소 핸들러 — 요청이 올 때만 실행된다
export const handler = async (event) => {
 const name = event.queryStringParameters?.name ?? "world";
 return {
  statusCode: 200,
  body: JSON.stringify({ message: `hello, ${name}` }),
 };
};

핸들러 형식과 실행 모델의 세부는 AWS 람다 공식 페이지에서 확인할 수 있다.

서버리스는 어떻게 동작하나

핵심은 이벤트가 생기면 그때 실행된다는 점이다. 사용자가 웹 요청을 보내거나, 파일이 올라오거나, 정해둔 시간이 되면 그에 연결된 함수가 깨어나 잠깐 일하고, 끝나면 자원이 회수된다.

요청이 몰리면 실행 단위가 자동으로 여러 개 늘어나 나눠 처리하고, 요청이 잦아들면 다시 줄어든다. AWS 람다 공식 문서에 따르면 함수 하나가 10초마다 실행 환경을 최대 1,000개씩 더 늘릴 수 있다. 개발자가 미리 서버 대수를 가늠해 준비해 둘 필요가 줄어드는 셈이다. 호출이 전혀 없는 동안에는 실행 요금이 거의 발생하지 않아, 사용량이 들쭉날쭉한 작업에 잘 맞는다는 평가를 받는다.

• 웹 요청, 파일 업로드, 예약 시간 같은 이벤트가 실행을 촉발한다
• 요청량에 맞춰 실행 단위가 자동으로 늘고 준다
• 쉬는 동안에는 자원과 비용 부담이 크지 않은 편이다

요금은 어떻게 계산되나

요금은 대체로 함수가 호출된 횟수와 한 번 돌 때 쓴 실행 시간·메모리를 곱해 계산된다. AWS 요금 페이지 기준으로 람다는 요청 100만 건당 0.20달러에 실행량 요금(x86 기준 GB-초당 0.0000166667달러)을 더해 청구하고, 실행 시간은 1ms 단위로 계산한다. 요청이 없는 시간에는 함수가 놀고 있으므로 그 시간에는 비용이 붙지 않는 편이라, 서버를 하루 종일 켜 두는 방식과 견주면 사용량이 들쭉날쭉한 서비스에서 요금을 아끼기 유리하다. 대표적인 상품으로는 AWS 람다, 구글 클라우드 펑션, 애저 펑션이 있으며, 세부 요금 체계와 실행 한도는 사업자마다 다르므로 도입 전에 각 공식 문서에서 최신 조건을 확인하는 편이 안전하다.

그 실행 한도가 실제로 얼마나 다른지, 한 번 실행에 허용되는 최대 시간을 각 사 공식 문서 기준으로 견주면 다음과 같다.

어떤 점이 매력으로 꼽히나

가장 자주 언급되는 장점은 운영 부담이 줄어든다는 것이다. 서버를 24시간 지키고, 사양을 늘리고, 보안 업데이트를 챙기던 일을 상당 부분 사업자에게 맡기기 때문이다. 그만큼 팀은 기능 개발과 개선에 더 집중할 여지가 생긴다.

비용 구조도 눈에 띈다. 서버를 늘 켜두고 고정 요금을 내는 대신, 실제 실행된 양에 맞춰 요금이 매겨지는 방식이라 쉬는 시간이 많은 서비스라면 지출을 아낄 여지가 있다. AWS 요금 페이지에 따르면 람다는 매달 요청 100만 건과 40만 GB-초의 무료 사용량을 제공해, 이 범위 안에서 도는 작은 서비스는 실행 요금이 0원이다. 새 기능을 함수 하나 단위로 올려 시험해 보고 아니다 싶으면 걷어내기도 수월해, 초기 아이디어를 검증하려는 팀에게 유용하다는 이야기가 많다.

• 서버 관리와 확장 부담을 줄여 개발에 집중하기 쉽다
• 실행한 만큼 과금돼 쉬는 자원의 낭비를 줄일 수 있다
• 함수 하나 단위로 따로 배포하고 실험하기 좋다

도입 전에 알아둘 한계는

장점만 있는 것은 아니다. 대표적으로 콜드 스타트가 있다. 한동안 호출이 없던 함수는 다시 불릴 때 실행 환경을 새로 준비하느라 첫 응답이 평소보다 느려질 수 있다. AWS 컴퓨트 블로그가 운영 환경의 람다 호출을 분석한 글에 따르면 콜드 스타트는 전체 호출의 1% 미만에서 생기지만, 발생하면 지연이 100ms 미만에서 1초 이상까지 벌어진다 — 같은 글은 지연을 가장 낮게 묶는 수단으로 실행 환경을 미리 준비해 두는 프로비저닝된 동시성을 권한다. 응답 속도가 예민한 서비스라면 미리 짚어봐야 할 지점이다.

특정 사업자의 기능에 맞춰 설계하다 보면 나중에 다른 환경으로 옮기기가 까다로워지는 종속 문제도 거론된다. 함수 한 번 실행에 허용되는 시간이나 자원에 제한이 걸리는 경우도 있어, 오래 걸리는 무거운 연산에는 맞지 않을 수 있다. AWS 람다 공식 문서 기준으로 한 번 호출은 최대 900초(15분), 메모리는 128MB에서 10,240MB 사이로 제한된다. 여러 함수로 잘게 나뉜 구조는 문제를 추적하고 전체 흐름을 살피는 과정이 기존 방식과 달라, 모니터링과 디버깅 방법을 새로 익혀야 하는 부담이 따른다.

• 오래 쉬던 함수는 첫 호출이 느려지는 콜드 스타트가 생길 수 있다
• 특정 사업자 기능에 묶이는 종속이 부담될 수 있다
• 실행 시간과 자원에 제한이 있어 장시간 작업에는 부적합할 수 있다
• 분산된 구조라 추적과 모니터링 방식을 새로 익혀야 한다

어떤 서비스에 잘 맞나

트래픽이 시간대나 이벤트에 따라 크게 오르내리는 서비스라면 서버리스가 잘 어울린다는 평가가 많다. 평소엔 조용하다가 특정 순간에만 요청이 몰리는 작업일수록, 늘 켜둔 서버보다 필요할 때만 깨어나는 방식이 자연스럽다.

흔히 어울린다고 꼽히는 사례는 요청 한 건 처리가 몇 초 안에 끝나는 API 백엔드, 이미지나 파일 가공, 정해진 시간에 도는 예약 작업, 알림 발송 같은 것이다. 실제로 AWS 람다 공식 문서는 S3 버킷에 이미지가 올라오면 함수가 깨어나 썸네일을 만들어 다른 버킷에 저장하는 튜토리얼을 대표 예제로 제공한다. 반대로 트래픽이 늘 일정하게 높거나, 한 번에 오래 돌려야 하는 연산이 중심이라면 기존 방식과 견주어 득실을 다시 따져보는 편이 낫다. 결국 서비스의 성격과 트래픽 패턴을 먼저 살핀 뒤 선택하는 것이 바람직하다.

처음부터 모든 것을 서버리스로 바꾸기보다, 요청이 뜸하거나 독립적으로 떼어 내기 쉬운 기능부터 함수로 옮겨 요금과 응답 속도를 지켜보는 방식이 무난하다. 작은 함수 하나로 시작해 감을 잡은 뒤 범위를 넓히면 전환 위험을 줄일 수 있다. 트래픽이 늘 높고 인프라를 직접 통제해야 하는 서비스라면, 컨테이너를 직접 운영하는 쿠버네티스 구조를 먼저 이해해 보는 편이 판단에 도움이 된다.