💡 핵심 인사이트
서버리스(Serverless)는 진짜로 서버가 없는 것이 아닙니다.
개발자 입장에서 **"이 코드를 돌릴 OS가 리눅스인지 윈도우인지, 램이 몇 기가인지 같은 끔찍한 서버 인프라 관리(Server Management)를 1도 신경 쓸 필요 없이, 오직 비즈니스 '코드(함수)'만 짜서 클라우드에 툭 던져놓으면 아마존(AWS)이 알아서 실행해 주는 궁극의 클라우드 서비스 모델"**을 뜻합니다.

Ⅰ. 인프라 관리의 종말 (서버리스의 탄생)

소프트웨어 배포의 역사는 '서버(쇳덩이)와의 이별' 과정입니다.

  • 온프레미스 (옛날): 서버 사서 전원 꽂고 에어컨 틀고 리눅스 깔고 직접 다 함.
  • IaaS (클라우드 VM/EC2): 쇳덩이 관리는 아마존이 하지만, 여전히 내가 리눅스 깔고 보안 패치하고 톰캣 올려야 함. (귀찮음).
  • CaaS (도커/쿠버네티스): K8s가 알아서 배포해 주지만, 그 K8s 노드(서버)가 터지지 않게 관리하는 건 여전히 빡셈.
  • 서버리스 (Serverless / FaaS): "아 몰라 다 귀찮아! 그냥 내 코드 10줄만 줄 테니까 아마존 네가 알아서 서버 세팅하고 돌려! 난 신경 끌래!"

Ⅱ. FaaS (Function as a Service) - 함수의 마법

서버리스를 구현하는 가장 대표적인 모델이 FaaS (예: AWS Lambda)입니다.

FaaS의 동작 원리 (이벤트 주도)

  1. 업로드: 개발자는 쇼핑몰에서 '이미지 리사이징'을 하는 50줄짜리 파이썬 코드(Function)만 덜렁 짜서 AWS Lambda에 업로드합니다.
  2. 수면 상태 (비용 0원): 코드는 서버에 올라가 있지만, 아무도 사진을 안 올리면 이 코드는 그냥 잠들어 있습니다. CPU를 안 먹으므로 1달 내내 요금이 0원입니다.
  3. 이벤트 발생과 폭발적 확장:
    • 새벽 3시에 유저 1명이 사진을 올리면(이벤트), 람다가 0.1초 만에 깨어나서 코드를 딱 1번 실행하고 다시 푹 잡니다. (1번 깬 비용 0.1원 청구).
    • 블랙프라이데이에 10만 명이 동시에 사진을 올리면? 람다는 이 파이썬 함수를 서버 10만 대에 순식간에 **복제(무한 오토스케일링)**하여 동시에 처리하고, 다 끝나면 10만 대를 즉시 없애버립니다.
    • 쿠버네티스처럼 내가 스케일링 정책을 짤 필요도 없습니다. 아마존이 알아서 무한대로 늘려줍니다.

Ⅲ. 서버리스의 장단점

[극강의 장점]

  • 인프라 뇌 빼기 (NoOps): OS 업데이트, 디스크 용량, 방화벽 관리 등 운영팀(Ops)이 해야 할 일이 완전히 소멸합니다. 개발자는 오직 비즈니스 코드 창출에만 100% 집중합니다.
  • 완벽한 Pay-as-you-go: 서버를 켜둔 시간에 돈을 내는 게 아니라, 내 함수가 **'실행된 0.1초 단위(밀리초)'**로만 돈을 냅니다. 트래픽이 0이면 요금도 0원입니다.

[치명적 단점]

  • 콜드 스타트 (Cold Start): 람다가 며칠 동안 잠들어 있다가 갑자기 깨어날 때, 아마존이 뒤에서 컨테이너를 부팅하고 코드를 로딩하느라 초기 실행 속도가 1~2초 정도 버벅거리는 현상이 발생합니다. (실시간 초저지연이 필요한 게임 서버 등에는 절대 못 씁니다.)
  • 벤더 종속 (Lock-in): 코드를 AWS 람다 전용 규격에 맞춰 짜야 하므로, 구글 클라우드로 이사 가기가 끔찍하게 어렵습니다.

📢 섹션 요약 비유: 옛날 방식(서버 구매)이 1년에 한 번 타는 자가용을 사서 매달 주차비와 보험료(고정비)를 내고 엔진오일을 직접 가는 것이라면, 서버리스(FaaS)는 **'우버(Uber) 택시'**입니다. 차(서버)를 소유할 필요도, 주차장을 관리할 필요도 없습니다. 내가 길을 걷다 이동(이벤트)하고 싶을 때만 버튼을 누르면 딱 그 거리(실행 시간)만큼만 요금을 내고 목적지에 도착하는 궁극의 무소유 IT 아키텍처입니다.