서버리스 아키텍처가 무엇이고 언제 유용한가
서버리스 아키텍처는 개발자가 서버를 직접 준비하거나 관리하지 않고, 코드 실행에 필요한 환경을 클라우드 사업자가 대신 맡는 방식이다. 코드를 올려두면 요청이 들어올 때만 잠깐 실행되고, 실제 사용한 만큼만 비용을 내는 구조로 알려져 있다. 서버 운영 부담을 덜고 싶은 소규모 팀이나, 트래픽이 시간대별로 크게 출렁이는 서비스에서 특히 관심을 받는다.
서버리스라는 이름의 진짜 의미
'서버가 없다'는 말은 오해를 부르기 쉽다. 서버는 여전히 어딘가에서 돌아가지만, 그 서버를 개발자가 신경 쓸 필요가 없다는 뜻에 가깝다. 물리 장비나 가상 머신을 직접 빌리고 설정하고 관리하던 과정을 클라우드 쪽에 넘긴다. 개발자는 실행할 코드와 그 코드가 언제 돌아갈지만 정의하면 된다.
대표적인 형태는 함수 단위로 코드를 실행하는 방식이다. 애플리케이션 전체를 항상 켜두는 대신, 필요한 기능을 작은 함수로 나눠 올려두고 특정 조건이 맞을 때만 불러 쓴다. 서버 준비와 확장, 보안 패치 같은 뒷일은 사업자가 처리하는 것으로 알려져 있다.
- 서버 임대와 설정, 유지보수를 직접 하지 않는다
- 코드는 대체로 작은 함수 단위로 쪼개 배포한다
- 확장과 패치 같은 운영은 사업자 몫으로 넘어간다
서버리스는 어떻게 동작하나
핵심은 이벤트가 생기면 그때 실행된다는 점이다. 사용자가 웹 요청을 보내거나, 파일이 올라오거나, 정해둔 시간이 되면 그에 연결된 함수가 깨어나 잠깐 일하고, 끝나면 자원이 회수된다.
요청이 몰리면 실행 단위가 자동으로 여러 개 늘어나 나눠 처리하고, 요청이 잦아들면 다시 줄어든다. 개발자가 미리 서버 대수를 가늠해 준비해 둘 필요가 줄어드는 셈이다. 호출이 전혀 없는 동안에는 비용이 거의 발생하지 않는 것으로 알려져 있어, 사용량이 들쭉날쭉한 작업에 잘 맞는다는 평가를 받는다.
- 웹 요청, 파일 업로드, 예약 시간 같은 이벤트가 실행을 촉발한다
- 요청량에 맞춰 실행 단위가 자동으로 늘고 준다
- 쉬는 동안에는 자원과 비용 부담이 크지 않은 편이다
어떤 점이 매력으로 꼽히나
가장 자주 언급되는 장점은 운영 부담이 줄어든다는 것이다. 서버를 24시간 지키고, 사양을 늘리고, 보안 업데이트를 챙기던 일을 상당 부분 사업자에게 맡기기 때문이다. 그만큼 팀은 기능 개발과 개선에 더 집중할 여지가 생긴다.
비용 구조도 눈에 띈다. 서버를 늘 켜두고 고정 요금을 내는 대신, 실제 실행된 양에 맞춰 요금이 매겨지는 방식이라 쉬는 시간이 많은 서비스라면 지출을 아낄 여지가 있다. 새 기능을 빠르게 올려 시험해 보고 아니다 싶으면 걷어내기도 수월해, 초기 아이디어를 검증하려는 팀에게 유용하다는 이야기가 많다.
- 서버 관리와 확장 부담을 줄여 개발에 집중하기 쉽다
- 실행한 만큼 과금돼 쉬는 자원의 낭비를 줄일 수 있다
- 작은 단위로 빠르게 배포하고 실험하기 좋다
도입 전에 알아둘 한계는
장점만 있는 것은 아니다. 대표적으로 콜드 스타트가 있다. 한동안 호출이 없던 함수는 다시 불릴 때 실행 환경을 새로 준비하느라 첫 응답이 평소보다 느려질 수 있다. 응답 속도가 예민한 서비스라면 미리 짚어봐야 할 지점이다.
특정 사업자의 기능에 맞춰 설계하다 보면 나중에 다른 환경으로 옮기기가 까다로워지는 종속 문제도 거론된다. 함수 한 번 실행에 허용되는 시간이나 자원에 제한이 걸리는 경우도 있어, 오래 걸리는 무거운 연산에는 맞지 않을 수 있다. 여러 함수로 잘게 나뉜 구조는 문제를 추적하고 전체 흐름을 살피는 과정이 기존 방식과 달라, 모니터링과 디버깅 방법을 새로 익혀야 하는 부담이 따른다.
- 오래 쉬던 함수는 첫 호출이 느려지는 콜드 스타트가 생길 수 있다
- 특정 사업자 기능에 묶이는 종속이 부담될 수 있다
- 실행 시간과 자원에 제한이 있어 장시간 작업에는 부적합할 수 있다
- 분산된 구조라 추적과 모니터링 방식을 새로 익혀야 한다
어떤 서비스에 잘 맞나
트래픽이 시간대나 이벤트에 따라 크게 오르내리는 서비스라면 서버리스가 잘 어울린다는 평가가 많다. 평소엔 조용하다가 특정 순간에만 요청이 몰리는 작업일수록, 늘 켜둔 서버보다 필요할 때만 깨어나는 방식이 자연스럽다.
흔히 어울린다고 꼽히는 사례는 가벼운 API 백엔드, 이미지나 파일 가공, 정해진 시간에 도는 예약 작업, 알림 발송 같은 것이다. 반대로 트래픽이 늘 일정하게 높거나, 한 번에 오래 돌려야 하는 연산이 중심이라면 기존 방식과 견주어 득실을 다시 따져보는 편이 낫다. 결국 서비스의 성격과 트래픽 패턴을 먼저 살핀 뒤 선택하는 것이 바람직하다.