Azure Functions

파일이 업로드되면 썸네일을 만들고, 매일 새벽 2시에 보고서를 생성하고, 결제 이벤트가 들어오면 알림을 보내는 작업들이 있습니다. 공통점은 하나입니다. 어떤 일이 발생했을 때만 실행되고, 그 외에는 아무것도 할 필요가 없습니다. 그런데 이 작업들을 위해 VM을 띄우면 아무 일도 없는 22시간 동안에도 서버가 돌아가면서 비용이 발생합니다. 트래픽이 갑자기 몰리면 스케일아웃을 직접 결정해야 하고, 빠져나가면 남은 인스턴스가 놀고 있습니다. OS 패치, 런타임 업데이트, 장애 복구까지 더하면 '몇 줄짜리 처리 로직'을 위해 운영 비용이 지나치게 커집니다.

초기 클라우드는 VM을 직접 관리하는 IaaS 방식이었습니다. 기능 하나를 추가해도 서버를 프로비저닝하고 런타임을 설치해야 했고, 트래픽 예측이 틀리면 과잉 확보로 비용이 낭비되거나 부족해서 장애가 났습니다. PaaS가 나오면서 OS와 미들웨어 관리는 줄었지만, 인스턴스가 항상 켜져 있어야 한다는 구조 자체는 바뀌지 않았습니다. 실제 워크로드를 보면 꽤 많은 작업이 '이벤트가 왔을 때만 짧게 처리하는' 패턴이었는데, 이런 워크로드를 위해 24시간 서버를 유지하는 것이 맞지 않는다는 인식이 퍼지기 시작했습니다. 실행한 시간만큼만 비용을 내고, 인프라 관리는 플랫폼이 맡는 방향으로 클라우드가 진화했고, Functions는 그 흐름 위에서 만들어졌습니다.

Functions는 트리거, 실행, 바인딩 세 단계로 움직입니다. 트리거가 함수를 깨웁니다. HTTP 요청이 들어오거나, 큐에 메시지가 쌓이거나, Blob Storage에 파일이 올라오거나, 타이머 시각이 되면 플랫폼이 함수 인스턴스를 생성합니다. 인스턴스가 뜨는 데는 보통 수백 밀리초, 콜드 스타트 시에는 몇 초가 걸립니다. 실행 단계에서 함수 코드는 이벤트 데이터를 받아 비즈니스 로직을 처리합니다. 출력 바인딩을 선언하면 코드 안에서 SDK를 직접 다루지 않아도 결과를 Cosmos DB에 쓰거나 다른 큐에 메시지를 보낼 수 있습니다. 요청이 급증하면 플랫폼이 인스턴스를 수평으로 늘리고, 줄어들면 0까지 내려갑니다. 소비 플랜 기준으로 비용은 실행 횟수와 실행 시간(GB-초 단위)으로 계산됩니다.

Functions와 App Service는 둘 다 Azure에서 코드를 실행하지만 운영 모델이 다릅니다. App Service는 인스턴스가 항상 켜져 있어서 지속적인 HTTP 요청을 받거나 상태를 유지하는 서비스에 맞습니다. Functions는 이벤트가 올 때만 인스턴스가 생기고 사라지는 방식이라 산발적인 처리에 유리합니다. 요청이 없는 시간이 많고 이벤트마다 독립 처리가 가능하다면 Functions의 소비 기반 과금이 훨씬 효율적입니다. 반면 하루 종일 일정하게 트래픽이 들어오는 서비스라면 항상 켜진 인스턴스 하나를 유지하는 App Service가 오히려 비용이 낮을 수 있습니다. 실행 시간 제한(소비 플랜 기본 5분, 최대 10분)도 고려해야 합니다. 처리 시간이 길거나 웹소켓처럼 지속 연결이 필요한 패턴에는 Functions가 맞지 않습니다.

이벤트 기반 처리가 뚜렷한 팀에서 Functions가 등장합니다. 사용자가 이미지를 업로드하면 리사이징 함수가 트리거되고, 결제가 완료되면 알림 함수가 실행되는 구조입니다. 트래픽 예측이 어려운 초기 서비스나 사내 자동화 도구에서도 자주 선택합니다. 인프라를 관리할 여력이 없는 소규모 팀이 빠르게 API 엔드포인트를 만들어야 할 때도 좋은 출발점이 됩니다. 다만 함수 수가 수십 개를 넘기 시작하면 모니터링, 배포 파이프라인, 버전 관리 비용이 커집니다. 콜드 스타트 지연이 허용되지 않는 레이턴시 민감한 API라면 Premium 플랜이나 다른 호스팅 옵션을 검토해야 합니다.