Azure App Service

웹 앱 코드를 완성하고 나면 그다음이 문제입니다. VM을 직접 띄우면 OS 설치부터 시작해서 런타임 구성, 웹 서버 설정, SSL 인증서 발급, 배포 스크립트 작성까지 해야 합니다. 앱 코드는 한 줄도 바뀌지 않았는데 이 설정 작업들이 하루를 잡아먹는 일이 반복됩니다. 팀원이 늘거나 서비스가 많아지면 서버마다 같은 설정을 다시 하고, 트래픽이 급증하면 로드 밸런서와 추가 인스턴스를 수동으로 구성해야 합니다. 코드보다 인프라에 시간이 더 들어가는 상황이 고착됩니다.

초기 웹 호스팅은 물리 서버에 Apache나 IIS를 설치하고 FTP로 파일을 올리는 방식이었습니다. 서버가 늘면 설정을 일일이 복제했고, 배포 중 서비스가 잠깐 끊기는 것도 당연하게 여겨졌습니다. 클라우드 VM이 등장하면서 서버를 빠르게 프로비저닝할 수 있게 됐지만, OS 패치, 런타임 업데이트, 배포 자동화, SSL 갱신은 여전히 운영자의 반복 작업으로 남았습니다. 서비스 수가 늘고 배포 빈도가 높아지면서, 개발팀은 '코드를 올리면 나머지는 플랫폼이 처리해야 한다'는 수준의 추상화를 원하게 됐습니다. 이 요구에서 PaaS라는 접근이 나왔고, App Service는 Azure에서 그 모델을 가장 직접적으로 구현한 서비스입니다.

App Service는 App Service Plan과 Web App, 두 계층으로 나뉩니다. Plan은 인프라 단위입니다. CPU와 메모리 등급, 인스턴스 수를 여기서 결정합니다. 같은 Plan 위에 여러 Web App을 올릴 수 있어서 자원을 공유하고 비용을 나눌 수 있습니다. Web App은 실제 앱이 올라가는 단위로, 런타임 버전, 환경 변수, 연결 문자열 같은 앱 수준 설정이 여기에 속합니다. 배포는 Git push나 GitHub Actions 연동으로 처리하고, 배포 슬롯(Deployment Slot)을 쓰면 스테이징 환경에 먼저 올려 검증한 뒤 트래픽을 전환할 수 있습니다. 새 버전을 올리는 동안 서비스가 끊기지 않는 구조입니다. 트래픽이 늘면 Plan의 인스턴스 수를 자동으로 늘리고, 빠지면 줄입니다. SSL 인증서와 커스텀 도메인은 플랫폼에서 바로 연결할 수 있어 별도 프록시나 인증서 관리 도구 없이도 HTTPS가 적용됩니다.

App Service와 Azure Functions는 둘 다 인프라를 직접 관리하지 않아도 된다는 점에서 비슷해 보이지만, 실행 모델이 다릅니다. App Service는 항상 프로세스가 떠 있는 방식이라 지속적으로 요청을 받는 웹 앱이나 API에 맞습니다. Functions는 이벤트가 발생할 때만 실행되고 유휴 시간에는 비용이 0이 되는 모델입니다. 요청이 고르게 들어오는 서비스라면 App Service가 비용 예측이 쉽고, 트래픽이 간헐적이거나 이벤트 단위로 처리하는 작업이라면 함수 기반 모델이 더 효율적입니다. App Service 안에서 컨테이너를 배포할 수도 있지만, 수십 개 이상의 컨테이너를 각각 스케일링하고 세밀하게 제어해야 하는 규모에는 맞지 않습니다.

인프라 담당자 없이 팀이 처음 프로덕션 환경을 꾸릴 때, App Service는 배포 슬롯과 자동 스케일이 처음부터 갖춰진 상태로 시작할 수 있다는 점이 강점입니다. 백오피스 도구, 관리자 페이지, 내부 API처럼 트래픽은 적지만 자주 업데이트가 필요한 서비스도 잘 맞습니다. GitHub Actions 연동으로 PR 머지 후 자동 배포 파이프라인을 빠르게 구성할 수 있어서, 개발 속도가 빠른 팀에 적합합니다. 한계도 있습니다. OS 커널 설정을 바꿔야 하거나, 플랫폼이 지원하지 않는 네이티브 라이브러리를 설치해야 하는 경우에는 이 서비스의 제약에 부딪힙니다. Plan 단위로 과금되는 구조라 유휴 시간에도 기본 비용이 발생하고, 트래픽이 매우 산발적인 서비스에서는 비용 효율이 낮을 수 있습니다.