정의
내 코드를 "항상 켜진 서버"에 올려두는 대신, 요청이 올 때만 클라우드가 잠깐 실행 환경을 띄워 돌리고 끝나면 꺼버리는 방식(AWS Lambda 등)을 이해하기 위한 개념이다. 서버 관리를 클라우드에 맡기는 대신, 코드가 지켜야 할 제약(상태를 기억 못 함, 첫 실행이 느림)이 생긴다.
용어부터 풀면: 무상태(stateless) 는 함수가 이전 호출의 기억(메모리에 저장한 값)을 다음 호출에서 못 쓴다는 뜻, 단명(ephemeral) 은 실행 환경이 잠깐 살았다 사라진다는 뜻, 콜드 스타트(cold start) 는 새 실행 환경을 처음 띄우고 코드를 초기화하느라 첫 요청이 느려지는 현상이다.
정리하면 Serverless 함수는 요청마다 단명하는 격리된 실행 환경에서 동작하는 무상태 프로세스다. 새 인스턴스를 부팅하고 런타임(코드 실행에 필요한 환경)을 초기화하는 첫 호출의 지연이 콜드 스타트다. 이는 항상 메모리에 떠 있는 상주 서버(long-running process — 계속 켜져 상태를 유지하는 전통적 서버)와 대비된다.
왜 필요한가
상주 서버는 메모리에 인덱스·연결 풀·캐시를 계속 들고 있을 수 있지만, 서버리스 플랫폼은 비용·확장성을 위해 인스턴스를 "필요할 때 만들고 유휴 시 회수"한다. 따라서 "메모리에 계속 떠 있어야 하는 것"(검색 엔진, 인메모리 DB, 파일 기반 DB의 쓰기 핸들 등)을 함수 안에 두면 기대대로 동작하지 않는다. 이 모델을 이해해야 "무엇을 함수 안에 둘 수 있고 무엇을 외부에 둬야 하는가"를 올바르게 가를 수 있다.
동작 원리
- 요청이 들어오면 플랫폼은 warm 인스턴스가 있으면 재사용하고, 없으면 새 인스턴스를 부팅한다(콜드 스타트).
- 모듈 레벨 코드는 인스턴스가 살아있는 동안 한 번만 실행된다 → 무거운 불변 객체는 여기서 lazy singleton으로 초기화해 warm 재사용을 노린다.
- 임시 파일시스템은 실행 중 읽기는 가능하지만 인스턴스가 죽으면 사라진다. 영속 쓰기는 외부 스토리지로 보낸다.
- 함수에 포함될 파일은 빌드 시 정적으로 결정(file tracing)되므로, 런타임에 동적으로 읽는 빌드 산출물은 명시적으로 포함시켜야 한다.
실무 적용
런타임에 읽는 빌드 산출물(예: 사전 빌드한 인덱스 파일)은 번들 추적 설정에 경로를 명시해 콜드 스타트에서 누락되지 않게 한다. 요청 고유 데이터는 모듈 전역이 아니라 인자/요청 컨텍스트로 흘린다.
트레이드오프
상주 서버는 메모리 상태를 자유롭게 유지하지만 운영·스케일 비용이 크다. 서버리스는 스케일·비용에 유리하지만 콜드 스타트 지연과 무상태 제약을 받는다. 라이브러리형 인덱스를 함수에 넣으면 외부 호스팅 없이 가볍게 배포되지만, 대규모·고급 토크나이징은 별도 상주 엔진이 필요하다.
사용하면 안 되는 경우
상시 떠 있어야 하는 검색 엔진·DB 프로세스, 인스턴스 간 공유가 필요한 가변 상태, 큰 영속 쓰기 워크로드는 함수 안에 두면 안 된다. 이런 의존성은 관리형 서비스/전용 서버로 분리한다.
흔한 실수
- 요청 고유 데이터를 모듈 전역 변수에 저장 → 동시성 오염·데이터 유실(인스턴스 공유 시).
- 런타임에 읽는 빌드 산출물을 번들 추적에 넣지 않아 콜드 스타트에서 파일 누락.
- 임시 파일시스템에 영속 데이터를 쓰고 사라지길 기대.
관련 개념
- inverted-index-full-text-search — 상주 엔진 대신 함수 내 라이브러리형 인덱스를 고를 때의 데이터 구조 배경.
- single-source-of-truth-content-metadata — 런타임 DB를 피하고 빌드 산출물로 결정하는 선택과 맞닿음.