Azure Functions

간단한 API 하나, 파일 업로드 후 썸네일 생성, 매일 자정에 도는 배치 작업 — 이런 일을 하려고 VM을 띄우면 24시간 서버가 대기하면서 비용을 먹습니다. 트래픽이 몰리면 직접 스케일링해야 하고, 빠지면 놀고 있는 서버에 돈을 냅니다. OS 패치, 런타임 업데이트, 장애 대응까지 코드 바깥의 운영 부담이 코드 자체보다 클 때가 많습니다. 더 복잡해지는 건 이런 작업들이 대부분 '어떤 이벤트가 생기면 짧게 실행하고 끝나는' 패턴인데, 이 패턴을 위해 상시 가동 인프라를 유지하는 것은 비용 대비 효율이 맞지 않는다는 점입니다.

클라우드 초기에는 코드를 실행하려면 VM을 직접 띄우고 관리해야 했습니다. 작은 기능 하나를 위해서도 OS, 런타임, 네트워크를 구성했고, 트래픽 예측이 빗나가면 과잉 프로비저닝으로 돈이 새거나 부족해서 장애가 났습니다. PaaS가 등장하면서 인프라 관리 부담은 줄었지만, 상시 가동 인스턴스에 대한 과금 구조는 그대로였습니다. 문제는 실제 워크로드의 상당수가 '이벤트가 발생했을 때만 짧게 실행되는' 패턴이었는데, 이 패턴을 위해 항상 켜져 있는 서버를 유지하는 것이 합리적이지 않다는 인식이 커졌습니다. '실행한 만큼만 비용을 내고, 나머지는 플랫폼이 알아서 처리하면 안 되나?'라는 요구가 서버리스 컴퓨팅의 출발점이었고, Azure Functions는 그 요구에 대한 Azure의 응답입니다.

Azure Functions는 트리거-실행-바인딩이라는 세 단계로 동작합니다. 트리거는 함수를 깨우는 이벤트입니다. HTTP 요청이 들어오거나, 큐에 메시지가 쌓이거나, 타이머 스케줄이 도달하면 해당 함수 인스턴스가 자동으로 생성됩니다. 함수 코드는 그 이벤트 데이터를 받아 비즈니스 로직을 실행하고, 출력 바인딩을 통해 결과를 Cosmos DB에 쓰거나 Blob Storage에 저장하거나 다른 큐에 메시지를 보냅니다. 바인딩은 연결 문자열과 데이터 매핑을 선언적으로 설정하는 방식이라, 함수 코드 안에서 SDK를 직접 다루지 않아도 됩니다. 요청이 급증하면 플랫폼이 함수 인스턴스를 수평으로 늘리고, 요청이 빠지면 0까지 줄여서 비용이 실행량에 비례합니다. 이 구조 덕분에 개발자는 이벤트에 반응하는 코드만 작성하면 되고, 인프라 수명 주기는 플랫폼이 대신 관리합니다.

Azure Functions와 App Service는 둘 다 Azure에서 코드를 실행하지만, 운영 모델이 다릅니다. Functions는 이벤트 단위로 깨어나서 실행하고 사라지는 방식이라, 짧은 작업을 산발적으로 처리할 때 비용과 운영 부담이 낮습니다. App Service는 항상 실행 중인 웹 앱이나 API를 호스팅하는 데 맞춰져 있어, 지속적으로 요청을 받거나 상태를 유지해야 하는 서비스에 적합합니다. 함수 하나의 실행 시간이 길어지거나, 여러 함수가 공유 상태를 관리해야 하거나, 웹소켓 같은 장시간 연결이 필요하다면 Functions의 실행 모델이 맞지 않습니다. 반대로 요청이 없을 때 비용이 0이어야 하고, 이벤트마다 독립적으로 실행되는 패턴이라면 Functions가 맞습니다.

API 엔드포인트를 빠르게 만들어야 하거나, 파일이 업로드되면 후처리를 돌리거나, 큐 메시지를 받아 데이터를 변환하는 것처럼 '이벤트 → 짧은 처리 → 결과 저장' 패턴이 뚜렷한 작업에서 Functions는 가장 자연스러운 선택입니다. 비동기 이벤트 소스와 바인딩을 조합하면 적은 코드로 파이프라인을 만들 수 있다는 점도 강점입니다. 반면 10분 이상 걸리는 무거운 연산, 지속적인 소켓 연결, 복잡한 상태 관리가 필요한 워크로드에는 함수의 실행 시간 제한과 무상태 특성이 걸림돌이 됩니다. 트래픽이 일정하게 높아서 상시 가동이 더 효율적인 경우에도, 소비 기반 과금이 오히려 비용 불리하게 작용할 수 있습니다.

다음에 볼 개념

함께 보면 좋은 개념