요즘 사이드 프로젝트를 하다 보면 "서버리스(Serverless)"라는 단어, 정말 많이 보이죠.
저는 프로젝트를 진행하면서 여러 번 **AWS Lambda를 통해 사용해봤습니다. 익숙한 개념이긴 한데, 문득 이런 생각이 들었습니다.
“이 서버리스, 대체 왜 생긴 걸까? 왜 다들 이걸 써보라고 하는 걸까?”
저도 직접 써보고 나서 느낀 장단점이 분명 있었기에, 이번 기회에 서버리스에 대해 좀 더 깊이 리서치해봤습니다.
결과적으로 ‘철학’에 가까운 구조라는 걸 새삼 깨닫게 되었어요.
예전에는 웹서비스 하나 돌리려면 서버 셋팅부터 시작했죠.
직접 인스턴스 띄우고, OS 설치하고, 웹서버 올리고, 도메인 붙이고… 정말 일이 많았습니다.
그런데 이런 인프라 작업이 서비스의 본질과 무관한 일이라는 점에서 서버리스는 이런 고민에서 시작됐다고 합니다.
"서버는 신경 쓰지 마. 네 로직만 올려."
"나머진 우리가 해줄게."
그게 바로 서버리스의 출발점이더라고요.
AWS Lambda
, GCP Functions
, Azure Functions
장점은 단연 "필요할 때만 실행", 그리고 자동 스케일링이라는 점이에요.
단점은 콜드 스타트. 특히 슬랙 알림 같은 민감한 작업에서 지연이 체감된 적이 있었어요. (AWS Lambda 기준 15초 정도 걸립니다. 서버 처럼 사용하려면 지속적으로 트리거해서 살려두는 방법이 있기는 합니다!)
찾아보니 유명한 기업들도 서버리스를 제대로 활용하고
저도 일정 시간마다 반복적으로 데이터를 처리하는 로직을 Lambda에 등록해 활용한 적이 있는데,
정말 코드 몇 줄로 동작하는 걸 보면서 감탄했던 기억이 납니다.
그래서 저는 단일 기능 단위로 명확한 역할이 있는 작업에 서버리스를 많이 쓰게 되는 것 같아요.
서버리스는 개발자에게 너무 좋은 '레버리지' 도구라고 생각합니다.
초기 비용, 운영 부담 없이도 바로 기능 구현에 집중할 수 있으니까요.
저처럼 Lambda로 작은 기능부터 시작해보고,
점점 서버리스를 확장해보는 방식도 꽤 추천할만합니다.
완전한 대체재는 아니지만,
적재적소에 쓴다면 정말 날개를 달아주는 기술임은 분명하다고 생각합니다.