서버리스

서버리스란?

서버리스를 도입하면 팀의 일 목록에서 항목 몇 개가 통째로 사라집니다. 서버를 몇 대로 잡을지 계산하고, 보안 패치를 붙이고, 새벽에 트래픽이 몰리면 인스턴스를 늘리는 일이 클라우드 쪽으로 넘어갑니다. 대신 개발자가 다루는 배포 단위가 '서버 한 대'에서 '함수 하나'로 바뀝니다. 기능마다 독립된 함수로 쪼개 올리기 때문에 하나를 고칠 때 전체를 재배포하지 않아도 되고, 기능 단위로 장애가 격리된다는 점을 실무에서 더 크게 체감합니다. 월 고정비로 나가던 서버 비용도 호출 횟수와 실행 시간에 따라 움직이는 변동비로 성격이 바뀝니다.

서버리스는 크게 둘로 나뉩니다. 코드를 함수 단위로 올리는 FaaS(AWS 람다, 클라우드 함수)와, 인증·DB·파일 저장 같은 뒷단을 통째로 빌려 쓰는 BaaS(파이어베이스, 수파베이스)입니다. 컨테이너나 PaaS와의 경계는 요청이 0일 때 자원도 0으로 줄어드느냐에서 갈립니다. 상시 한 대를 띄워 두는 구조라면 이름만 클라우드일 뿐 서버리스가 아닙니다. 조건도 분명합니다. 함수 한 번의 실행 시간에 상한이 있고(람다는 최대 15분), 함수는 상태를 기억하지 못해 세션·업로드 파일은 바깥 저장소에 따로 두어야 합니다. 긴 영상 인코딩처럼 무겁고 오래 도는 작업은 애초에 맞지 않습니다.

가장 흔한 오해는 '무조건 싸다'입니다. 요청이 뜸할 때는 압도적으로 유리하지만, 트래픽이 상시 일정 수준을 넘으면 비용이 역전됩니다. 초당 수십 건이 꾸준히 들어오는 서비스라면 작은 상시 서버 한 대가 오히려 저렴한 경우가 많습니다. 더 위험한 건 실수로 만든 무한 반복입니다. 함수가 자기 자신을 다시 호출하거나 실패 시 재시도가 끝없이 돌면 하룻밤 사이 요금이 수백만 원으로 찍히고, 대부분 청구서를 받고서야 알게 됩니다. 예산 경보와 재시도 횟수 제한은 배포 전에 걸어 두는 게 순서입니다. 여기에 오랜만에 호출될 때 첫 응답이 늦는 콜드 스타트, 특정 클라우드 문법에 코드가 묶이는 종속까지 함께 계산해야 합니다.