800GB 모델 허브를 어떻게 0.1초 만에 배포할 것인가: Azure App Service 17MB 경량화와 HTTP 206 분할 스트리밍

1. 온디바이스 AI의 역설: "클라이언트는 가벼운데, 모델 허브가 너무 무겁다"

ZeliDesk의 모델 허브(Model Hub)는 Stable Diffusion Turbo, TripoSR(3D 메쉬), DeepSeek R1, Qwen 2.5 등 800GB가 넘는 방대한 오픈소스 sLM 및 비전 가중치와 PyTorch CUDA 12.8 런타임을 보관하고 관리합니다.

사용자는 필요할 때 단 한 번의 클릭으로 2.64GB 크기의 런타임과 모델을 다운로드받아 자신의 PC에서 오프라인으로 실행합니다. 하지만 이 아키텍처를 지탱하는 중앙 모델 서버(ZeliDesk.Server)는 기가바이트 단위의 초거대 파일들을 클라우드(Azure)에서 24시간 끊김 없이 안정적으로 서빙해야 하는 극단적인 인프라 과제를 안고 있었습니다.

2. 난제 1: 6.57GB 배포 괴물과 15초 원클릭 배포(17MB)로의 380배 다이어트

초기 개발 과정에서 ZeliDesk.Server를 Azure App Service에 배포하려 할 때 심각한 병목이 발생했습니다. 빌드 아티팩트의 용량이 무려 6.57 GB에 달해, 배포를 누르면 1시간 동안 진행되다가 Azure CLI 타임아웃이나 메모리 초과로 실패하기 일쑤였습니다.

원인은 .csproj의 기본 설정이었습니다:

<!-- [문제의 원인] Data\models 폴더의 기가바이트 단위 모델 파일이 배포 패키지에 번들링됨 -->
<ItemGroup>
    <None Update="Data\models\**" CopyToOutputDirectory="PreserveNewest" />
</ItemGroup>

서버 코드 자체는 수 메가바이트에 불과한데, 로컬 테스트용 모델 바이너리들이 함께 압축되면서 배포 패키지가 비정상적으로 부풀어 오른 것입니다.

그 결과 1시간씩 걸리던 클라우드 배포가 단 15초 만에 완료되는 원클릭 스크립트(deploy_server.ps1)를 완성할 수 있었습니다.

3. 난제 2: Azure 2GB 바디 리밋 충돌과 64비트 정밀 분할 병합(merge-parts)

서버를 17MB로 경량화한 후, 2.64GB(2,839,776,055 bytes) 크기의 필수 코어 런타임(python_env_cuda128.zip)을 모델 허브에 업로드해야 했습니다. 그러나 Azure App Service 및 IIS 역방향 프록시는 단일 HTTP 요청 바디 크기를 약 2GB로 엄격히 제한하고 있어, 업로드 도중 연결이 끊기며 413 Request Entity Too Large 오류가 발생했습니다.

이를 돌파하기 위해 멀티파트 청크 분할 전송 & 서버 측 스트림 병합(merge-parts) 파이프라인을 구축했습니다:

# upload_python_env_to_azure.ps1 의 64비트 정밀 분할 로직
# 32비트 int 오버플로를 방지하기 위해 [long] 강제 캐스팅 적용
[long]$part1Size = [long]1500 * 1024 * 1024; # 1.5 GB
[long]$part2Size = $totalSize - $part1Size;  # 1.14 GB

# 1. Part 1 & Part 2 개별 업로드 완료
# 2. 서버 측 merge-parts API 호출
POST /api/models/merge-parts?targetFileName=python_env_cuda128.zip&parts=python_env_cuda128.zip.part1,python_env_cuda128.zip.part2

서버는 64KB 스트림 버퍼를 활용해 메모리 누수 없이 두 파일을 D:\home\data\... 영구 저장소 상에서 직접 이어 붙였으며, 정확히 2,839,776,055 바이트의 완전한 바이너리 무결성을 단 1바이트의 손실 없이 검증해 냈습니다.

4. 난제 3: 불안정한 학교망을 위한 HTTP 206 Partial Content 이어받기 스트리밍

학교 컴퓨터실이나 군부대 환경은 여러 대의 PC가 한정된 대역폭을 공유하므로, 2GB가 넘는 모델을 내려받는 동안 네트워크 순단이 발생하기 쉽습니다. 전통적인 다운로드는 99%에서 연결이 끊기면 처음부터 다시 받아야 하므로 교사들에게 극심한 스트레스를 안겨줍니다.

ZeliDesk 클라이언트와 서버는 HTTP 206 Partial Content 및 Range 헤더를 전면 도입하여 이 문제를 해결했습니다:

5. 결론: "클라우드 비용 90% 절감과 전국 10,000개 교실을 향한 안정적 배포망"

ZeliDesk의 인프라 설계는 "가장 적은 클라우드 비용으로, 가장 거대한 AI 모델을, 가장 열악한 네트워크 환경에서도 안전하게 전달한다"는 명확한 철학 위에 세워졌습니다.

코드와 스토리지를 완벽히 분리하여 배포 시간은 1시간에서 15초로 단축되었고, HTTP 206 분할 스트리밍을 통해 전국의 어떤 학교 교실이든 단 한 번의 실패 없이 AI 모델을 완벽히 안착시킬 수 있는 튼튼한 데이터 고속도로를 완성했습니다.