IDE를 떠나지 않고 GPU 클라우드에 배포하기 — RunPod Flash SDK
📺 원본 영상: GPU Cloud Deployment Without Leaving Your IDE — Audry Hsu, RunPod 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-06-10 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 코드, 슬라이드, 데모 화면 등은 포함되지 않을 수 있습니다.
개요
RunPod의 Developer Relations를 담당하는 Audrey Hsu가 AI Engineer 컨퍼런스에서 발표한 이 세션은 GPU 클라우드 인프라 회사 RunPod의 소개와 함께, 개발 이터레이션(iteration) 주기를 획기적으로 단축하는 Python SDK인 Flash의 실시간 데모를 중심으로 진행된다. 핵심 주제는 단순하다. 머신러닝 엔지니어가 코드를 수정할 때마다 Docker 이미지를 재빌드하고 컨테이너 레지스트리에 업로드하는 번거로운 과정을 없애고, Python 함수에 데코레이터 하나를 붙이는 것만으로 GPU 클라우드에 즉시 배포할 수 있게 한다는 것이다.
RunPod: 스팸 GPU에서 시작한 AI 인프라 회사
RunPod은 2022년에 Zen과 Pradeep이라는 두 명의 공동창업자가 설립했다. 회사의 시작은 다소 우연적이었는데, 실패한 암호화폐 채굴 사업의 잔재로 지하실에 쌓여 있던 여분의 GPU들이 그 씨앗이 되었다. 두 창업자는 RunPod의 초기 프로토타입을 만든 뒤 Reddit에 “피드백을 주는 대가로 GPU를 무료로 드립니다”라는 글을 올렸고, 이것이 회사의 시작이었다. 이 성장 방식은 처음부터 커뮤니티와 함께 공개적으로(in public) 제품을 만드는 문화로 이어졌고, 설립 초기부터 매출이 발생하는 구조를 만들었다는 점에서 스타트업 생태계에서 드문 사례로 꼽힌다.
현재 RunPod은 약 500명의 개발자가 활성 사용 중이며, 30개 이상의 데이터센터를 10개국에 보유하고 있다. 유럽 지역의 경우 프랑스, 루마니아, 아이슬란드에 거점이 있으며, 아시아태평양 지역도 커버하고 있다. 강연 시점 기준으로 연간 반복 매출(ARR)이 1억 2천만 달러($120M)를 돌파했다는 점에서 GPU 클라우드 시장에서 유의미한 존재감을 보여주고 있다. 고객 구성도 AI 네이티브 스타트업부터 대형 기업까지 다양하며, 이들의 공통점은 “유연하고 신뢰할 수 있는 GPU 인프라가 필요하다”는 것이다.
RunPod 제품 라인업: 사용 목적에 따른 선택
RunPod은 목적에 따라 여러 형태의 컴퓨팅 환경을 제공한다. 아래 네 가지 제품군이 핵심이다.
- Pods: 지속적인 VM 환경이 필요할 때. GPU를 예약해두고, 파드(pod)가 실행 중인 한 해당 GPU는 독점적으로 유지된다.
- Serverless: 배포 이후 워크로드의 빈도와 부하가 변동이 심할 때. RunPod이 워커(worker)를 자동 스케일 업/다운하며, 요청이 없을 때는 유휴 비용이 발생하지 않는다.
- Clusters: 멀티노드 분산 학습에 최적화된 환경.
- Hub: ComfyUI, Stable Diffusion, vLLM 등 RunPod이 검증한 오픈소스 AI 레포지토리를 클릭 몇 번으로 바로 실행할 수 있는 공간.
Pods와 Serverless의 차이는 실사용 맥락에서 중요하다. Pods는 GPU를 독점 예약하므로 실험 단계에서 GPU 하나 또는 두 개만 필요할 때 적합하며, 비용도 상대적으로 낮다. 반면 Serverless는 수백 개의 워커를 여러 데이터센터에 분산 배포해 가용성과 스케일링이 중요할 때 쓰는 구조로, 그에 상응하는 프리미엄이 붙는다.
Flash SDK: 개발 이터레이션의 병목을 제거하다
강연의 핵심은 Flash라는 RunPod의 Python SDK를 통한 라이브 데모다. Flash가 해결하려는 문제는 명확하다. 추론 모델(inference model) 코드를 개발하고 테스트하는 과정에서 기존의 워크플로는 다음과 같은 절차를 반복한다.
코드 변경 → Git 커밋 → Docker 이미지 빌드 → 컨테이너 레지스트리 푸시
→ 서버에서 이미지 풀(pull) → GPU 할당 → 테스트
이 사이클은 코드 한 줄을 바꿀 때마다 반복되어야 한다. Audrey는 이 구조가 개발자로 하여금 모델 자체보다 인프라 관리에 더 많은 시간을 쓰게 만드는 근본적인 비효율이라고 진단한다. CUDA 버전 정합성, PyTorch 버전 간 호환성, 새로운 GPU SKU의 버그 파악 등 이 모든 구성 문제를 RunPod이 추상화하여 개발자는 모델 훈련과 앱 빌딩에만 집중할 수 있게 하겠다는 것이 RunPod의 존재 이유이기도 하다.
Flash는 이 문제를 Python 데코레이터 하나로 해결한다. 일반적인 비동기(async) Python 함수에 @flash_endpoint 데코레이터를 추가하면, 해당 함수 내부의 모든 것이 패키징되어 GPU 클라우드에 배포된다. 함수 밖의 메인 로직이나 헬퍼 함수들은 로컬 개발 환경에서 계속 실행되고, GPU 컴퓨팅이 필요한 부분만 클라우드로 넘어가는 구조다. 여기에 더해 Hot File Reload 기능이 핵심인데, 애플리케이션 어느 곳에서든 코드를 수정하면 즉시 재패키징되어 업로드되고 테스트할 수 있다. Docker를 한 번도 직접 만질 필요가 없다.
06:53 - Flash SDK의 핵심 개념을 보여주는 코드 블록 — @flash_endpoint 데코레이터가 적용된 async Python 함수 전체 구조
@flash_endpoint 데코레이터 심층 분석
💡 [영상 참조] 강연자는 이 시점에서 IDE 화면을 미러링하여 데코레이터 코드를 직접 보여줍니다. 상세 내용은 원본 영상을 확인하세요.
강연자가 음성으로 설명한 @flash_endpoint 데코레이터의 주요 파라미터는 다음과 같다.
name: 엔드포인트의 이름을 지정한다.gpu_family: GPU 패밀리를 지정한다. 데모에서는 Ada 아키텍처 기반의 NVIDIA GPU (ADA, Ada Pro 계열)를 사용했다.max_workers: 동시에 실행 가능한 최대 워커 수. 데모에서는 5로 설정했다.active_workers: 항상 켜져 있는 워커 수. 1로 설정하면 요청 여부와 관계없이 워커 하나는 상시 대기한다. Cold Start 지연을 줄이는 데 유용하다.timeout: 워커가 요청 없이 유휴 상태를 유지할 수 있는 시간.
11:32 - @flash_endpoint 데코레이터의 파라미터 (name, gpu_family, max_workers, active_workers, timeout) 가 표시된 코드 화면
이 파라미터 조합은 비용과 응답성 사이의 트레이드오프를 직접 제어하는 수단이다. active_workers를 높일수록 응답 속도는 빨라지지만 상시 비용이 발생하고, max_workers를 높일수록 동시 처리 용량이 늘어나지만 그만큼 병렬 비용이 커진다.
실전 데모 1: Stable Diffusion 이미지 생성
강연자가 보여준 첫 번째 데모는 이미지 생성 함수다. PyTorch를 로드하고 사전 학습된 Stable Diffusion XL Turbo(SDXL Turbo) 모델을 불러와 이미지를 생성한 뒤, 결과를 Base64 인코딩으로 반환하는 비동기 Python 함수다. flash run image_generation.py 명령 하나로 로컬 개발 서버(내부적으로 FastAPI 서버)가 뜨고, 별도의 헬퍼 스크립트를 통해 해당 엔드포인트에 POST 요청을 보내 결과를 확인하는 방식이다.
청중의 제안으로 “런던의 흐린 하늘을 나는 고양이들”이라는 프롬프트를 입력했고, 생성된 이미지는 강연자 스스로 “별로다(terrible)“라고 평가할 만큼 추상적인 결과물이 나왔다. 이 상황을 계기로 바로 다음 핵심 기능인 모델 교체 데모로 자연스럽게 넘어간다.
실전 데모 2: 핫 리로드로 즉석 모델 교체
SDXL Turbo 코드를 주석 처리하고 DreamShaper로 교체하는 과정이 핵심이다. DreamShaper는 Stable Diffusion 1.5 기반의 파인튜닝 모델로, 빠른 생성보다는 아트 및 일러스트 스타일의 고품질 이미지 생성에 강점이 있다. 강연자는 추론 스텝 수를 25로 늘리고 해상도를 1024×1024로 조정했다. 코드 변경 후 별도의 빌드나 재배포 없이 같은 요청을 다시 전송했고, Flash의 Hot Reload가 자동으로 변경 사항을 감지해 재패키징·업로드한다.
이 데모가 전달하는 메시지는 간결하다. 모델을 바꾸는 것, 파라미터를 조정하는 것, 코드를 리팩터링하는 것 — 이 모든 변경이 Docker를 건드리지 않고 IDE 안에서 즉시 반영된다는 것이다. 이는 특히 모델 선택이나 하이퍼파라미터 탐색(hyperparameter search) 단계에서 반복 주기를 크게 단축시킨다.
12:30 - DreamShaper로 교체된 코드와 함께 생성된 고양이 이미지 결과물
실전 데모 3: 멀티 모델 오케스트레이션 파이프라인
Flash의 진정한 강점은 단일 모델 호출이 아니라 여러 모델을 연결하는 오케스트레이션 코드에서 드러난다는 것이 강연자의 주장이다. 세 번째 데모는 다음의 3단계 파이프라인으로 구성된다.
첫 번째 단계에서는 Qwen 3(Alibaba의 언어 모델)가 공개 엔드포인트로 호출되어 사용자의 간단한 프롬프트를 더 풍부하고 정교한 이미지 생성 프롬프트로 변환한다. 두 번째 단계에서는 앞서 데모한 DreamShaper가 RunPod의 엔드포인트에서 해당 프롬프트를 받아 이미지를 생성한다. 세 번째 단계에서는 Google의 이미지 합성 특화 모델(STT 음성에서 “NanoBanana2”로 기록되었으나 정확한 모델명 불명확 — 원본 영상 참조 권장)이 여러 이미지를 하나로 합성한다.
14:54 - Qwen 3 → DreamShaper → Google 이미지 합성 모델로 이어지는 3단계 파이프라인 코드
💡 [영상 참조] 강연자는 파이프라인 코드와 최종 합성 결과 이미지를 화면에 직접 보여줍니다. 📺 원본 영상에서 확인하세요.
데모의 입력 프롬프트는 청중 제안으로 “안경을 쓴 두 남성이 흐린 날 런던을 걷는 모습, 얼굴 클로즈업”이었고, 3장의 이미지를 생성해 합성하는 것으로 마무리되었다. Qwen 3가 재가공한 프롬프트는 “사려 깊은 표정과 세월이 담긴 얼굴, 배경 구름에 부드러운 포커스, 회색과 짙은 파란색의 절제된 도시 팔레트, 흐린 날 조명”과 같이 원본보다 훨씬 구체적이고 품질 높은 지시문으로 변환되었다.
18:43 - DreamShaper가 생성한 원본 이미지(왼쪽)와 Google 모델이 합성한 최종 이미지(오른쪽) 비교 화면
가격 정책: Serverless vs Pods
가격 구조는 요청이 실행되는 시간 단위로 과금되는 방식이다. 데모 도중 강연자가 RunPod 콘솔을 열어 보여준 바에 따르면, H100 기준 Serverless 가격은 초당 약 $0.00116(약 0.116센트)이다. 5명의 워커가 프로비저닝되었고, 3장의 이미지를 요청했기 때문에 3개의 워커가 동시에 실행되는 것을 확인할 수 있었다.
17:21 - RunPod 콘솔에서 프로비저닝된 워커 현황과 H100 초당 과금($0.00116) 가격 정보
Pods와 Serverless의 가격 차이는 스케일링 기능의 유무에 기인한다. Pods는 자동 스케일링이 없는 대신 가격이 낮고, Serverless는 수백 개의 워커를 여러 데이터센터에 걸쳐 분산·자동 확장할 수 있는 대신 프리미엄이 붙는다. 강연자는 실험 단계에서는 Pods 또는 아주 낮은 워커 수의 Serverless로 시작하고, 실제 배포 및 트래픽 수요가 생겼을 때 Serverless로 전환하는 것을 권장한다.
마무리 / 핵심 정리
이 강연이 던지는 메시지의 본질은 개발자 경험(Developer Experience, DX)에 있다. GPU 인프라를 다루는 일이 여전히 많은 팀에게 모델 개발만큼이나 큰 시간적 부담이 되고 있다는 현실 인식에서 출발하여, Flash SDK는 그 부담을 데코레이터 하나로 추상화하겠다는 접근이다. 로컬 환경에서의 개발 흐름을 유지하면서 GPU 컴퓨팅이 필요한 함수만 클라우드로 오프로드하고, 코드 변경이 즉시 반영되는 Hot Reload를 통해 반복 주기를 단축하는 것이 핵심 가치다.
단일 모델 호출을 넘어 Qwen 3 → DreamShaper → 이미지 합성 모델로 이어지는 멀티 스테이지 파이프라인 데모는, Flash가 단순한 배포 도구가 아니라 복잡한 AI 오케스트레이션 코드의 로컬 개발을 위한 플랫폼으로 포지셔닝하고 있음을 보여준다. 오픈소스 모델을 사용하든, 자체 파인튜닝 모델을 사용하든 같은 방식으로 적용된다는 범용성도 주목할 만하다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | GPU Cloud Deployment Without Leaving Your IDE — Audry Hsu, RunPod |
| 채널 | AI Engineer |
| 강연자 | Audrey Hsu (RunPod) |
| 리포트 작성 | 2026-06-10 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.