Azure App Service

웹 앱을 만들고 나면 '어디에 올리지?'라는 질문이 바로 따라옵니다. 서버를 직접 세팅하면 OS 설치, 런타임 구성, 웹 서버 설정, SSL 인증서 발급, 배포 스크립트 작성을 모두 해야 합니다. 앱 코드는 한 줄도 안 바뀌었는데 서버 관리에 시간이 더 들어가는 상황이 흔하고, 트래픽이 늘면 서버 추가와 로드 밸런서 구성까지 따라옵니다. 개발자가 인프라보다 애플리케이션 로직에 집중하려면, 서버 관리를 플랫폼이 대신 해주는 환경이 필요합니다.

초기 웹 호스팅은 물리 서버에 Apache나 IIS를 설치하고 FTP로 파일을 올리는 방식이었습니다. 서버가 늘면 설정을 복제해야 했고, 배포 중 서비스가 잠시 끊기는 것도 당연하게 여겨졌습니다. 클라우드 VM이 나오면서 서버를 빠르게 만들 수 있게 됐지만, OS 패치·런타임 업데이트·배포 자동화·SSL 갱신은 여전히 운영자의 반복 작업이었습니다. 서비스 수가 늘고 배포 빈도가 높아지면서, 개발자는 '코드를 올리면 나머지는 알아서 처리돼야 한다'는 수준의 추상화를 원하게 됐습니다. PaaS는 이 요구에 대한 응답으로, 인프라 관리를 플랫폼 뒤로 숨기고 애플리케이션 코드에만 집중할 수 있는 환경을 만들었습니다. App Service는 Azure에서 이 PaaS 모델의 가장 기본적인 형태입니다.

App Service의 핵심은 App Service Plan과 Web App 두 계층으로 나뉜 구조입니다. App Service Plan은 VM의 크기와 개수를 정하는 인프라 계층입니다. 여기서 CPU, 메모리, 디스크 성능이 결정되고, 같은 Plan 위에 여러 Web App을 올릴 수 있어 자원을 공유합니다. Web App은 실제 애플리케이션이 올라가는 단위이며, 런타임 선택, 환경 변수, 연결 문자열 같은 앱 수준 설정을 담당합니다. 배포는 Git push, GitHub Actions, Azure DevOps, ZIP 배포 등 여러 방식을 지원하고, 배포 슬롯을 쓰면 스테이징 환경에 먼저 올려 검증한 뒤 트래픽을 전환하는 무중단 배포가 됩니다. 트래픽이 늘면 Plan의 인스턴스 수를 수동 또는 자동으로 늘리는 수평 스케일링이 가능하고, Plan 등급을 올리는 수직 스케일링도 지원됩니다. SSL 인증서와 커스텀 도메인은 플랫폼에서 바로 연결할 수 있어, 별도의 리버스 프록시나 인증서 관리 도구 없이도 HTTPS가 기본 적용됩니다.

App Service와 Azure Functions는 둘 다 서버를 직접 관리하지 않는 관리형 서비스라는 점에서는 같습니다. 차이는 실행 모델에 있습니다. App Service는 항상 떠 있는 프로세스로 동작하며 HTTP 요청을 지속적으로 처리하는 웹 앱이나 API에 맞습니다. Functions는 이벤트가 발생할 때만 코드가 실행되고 유휴 시간에는 비용이 발생하지 않는 이벤트 드리븐 모델입니다. 지속적인 트래픽을 받는 웹사이트나 API 서버에는 App Service가 적합하고, 간헐적인 이벤트 처리나 짧은 작업 단위에는 함수 기반 모델이 더 효율적입니다. App Service 안에서 컨테이너를 배포할 수도 있지만, 수십 개 이상의 컨테이너를 오케스트레이션하고 세밀하게 제어해야 하는 규모에서는 맞지 않습니다.

App Service는 팀이 웹 앱이나 API를 빠르게 배포하고, 인프라 관리보다 기능 개발에 시간을 쓰고 싶을 때 가장 먼저 고려되는 선택지입니다. 특히 스타트업이나 소규모 팀에서 프로덕션 환경을 처음 구성할 때, 배포 슬롯과 자동 스케일이 이미 갖춰진 관리형 플랫폼을 쓰는 편이 운영 부담을 크게 줄입니다. 사내 도구, 관리자 페이지, 프로토타입처럼 빠르게 올리고 자주 바꿔야 하는 애플리케이션에도 잘 맞습니다. 반면 OS 커널 설정을 변경해야 하거나, 플랫폼이 지원하지 않는 런타임이나 네이티브 라이브러리를 설치해야 하는 경우에는 이 서비스의 제약에 부딪힙니다. 또한 Plan 위에서 돌아가는 구조이므로, 유휴 시간에도 기본 비용이 발생한다는 점은 트래픽 패턴에 따라 비효율이 될 수 있습니다.

다음에 볼 개념

함께 보면 좋은 개념