AirCloud(AIEEV) 후기 - GPU 비용 1/10로 줄인 SQS 오케스트레이션

AIEEV / AirCloud / 분산형 GPU 클라우드 / GPU 비용 절약 / SQS / OpenAI 호환 LLM API / DevOps 인턴

저희 회사가 도입한 AirCloud 환경에서 인턴 KPI를 진행하며 함께 조금이나마 운영해본 후기입니다.

도입 의사결정은 대표·시니어 라인에서 이루어졌고, 저는 그 위에서 패턴 이식과 트러블슈팅을 맡았습니다.

그래서 이 후기에서 본인이 직접 다룬 부분은:

• 사내 SDK의 gpu_orchestrator 패턴을 playground 환경에 이식 (Phase 0~2 완료)
• Settings 컨벤션 어댑터, SDK 버전 호환성, 필드명 매핑 등 트러블슈팅 3건
• 운영하면서 분산형 클라우드에 대한 의심이 해소된 경험

이 분리만 명확히 짚고 가면, 인턴 입장에서 보고 배운 것을 가감 없이 전할 수 있을 것 같습니다.

AIRCLOUD가 뭔지, 분산형 클라우드는 뭔지 인턴의 시각에서 함께 이해해보시죠.

이미지 클릭 시 https://www.aieev.com/ko 연결

1. AIRCLOUD를 처음 접한 순간

저는 주식회사 HEIMDEX(영상분석 멀티모달 AI 파인튜닝 업계 최고)에서 주니어 DevOps 엔지니어 인턴으로 일하고 있습니다. 목표는 시니어 DevOps 트랙.

처음 입사하고 나서 거의 제일 먼저 듣게 된 것은 AIRCLOUD MIGRATION을 위한 회의 미팅 참석이었습니다.

분명 클라우드에 대해서 배우긴 배웠는데 그 미팅에서 제가 이해할 수 있는 말은 극소수.. 였죠.

특히 막혔던 단어 하나가 "분산형 GPU 클라우드"였습니다. 그게 뭔지부터 풀고 가는 게 이 글의 시작점일 것 같아요.

---

2. 분산형 클라우드란?

보통 떠올리는 클라우드(AWS / GCP / Azure)는 집중형입니다. 거대한 자체 데이터센터에 GPU를 박아놓고 그걸 빌려주는 모델이죠.

분산형 클라우드는 그 반대입니다. 전 세계에 흩어져 있는 GPU 자원 - 개인 PC, 작은 데이터센터, 사용 안 하는 기업 자산 등 을 하나의 풀로 묶어서 활용하는 구조예요. AirCloud는 이런 100% 분산형 inference 전용 AI 클라우드로 출시됐고, AIEEV는 2026년까지 전 세계 idle GPU 노드 10만대 이상 확보를 목표로 잡고 있습니다.

AIEEV라는 이름 자체가 의미가 있는데, "AI Equality, Everyone's Value" 의 약자라고 합니다. AI 자원을 누구나 접근할 수 있도록 평등하게 — 이 비전이 분산형이라는 구조 자체에 들어가 있는 느낌이에요.

AirCloud 자체도 모드가 나뉘어 있습니다.

• Community Cloud - idle GPU 풀에서 자동 매칭. 가격이 가장 저렴하고 PoC/실험에 적합.
• Dedicated Cloud - 자체 노드 위에서 운영. 안정성·일관성이 더 필요할 때.
• AirCloud+ - 엔터프라이즈 옵션. ISO 27001 Certified.

그리고 그 위에 제품 라인이 세 갈래로 갈립니다.

• Air API - OpenAI 호환 LLM 추론 API.
• Air Model - ONNX 모델 호스팅.
• Air Container - 사용자가 직접 준비한 컨테이너 이미지 배포.

처음 듣고 든 의심: "그럼 PC방 컴퓨터 빌리는 거랑 뭐가 다른 건가?" - 이건 섹션 4에서 풀게요.

---

3. 회사가 AirCloud를 선택한 배경 (관찰·추측한 부분)

도입 결정은 제가 한 게 아니라서 정확한 의사결정 맥락은 모릅니다.
다만 운영하면서 보니 AirCloud가 우리 워크로드와 잘 맞는 이유가 셋 정도 있어 보였어요.

3-1. GPU 컨테이너 + LLM API가 같은 콘솔

우리 영상 enrichment 파이프라인은 GPU 워커 6종(reranker / visual embedding / caption / OCR / STT / face)이 fan-out으로 돌아갑니다. 동시에 텍스트 LLM 호출도 있고요. AWS면 EC2 + Bedrock(or OpenAI 직결) 따로 관리해야 하는데, AirCloud는 Air Container + Air API를 한 콘솔 한 크레딧 한 청구서로 묶을 수 있습니다.

LLM API가 OpenAI 호환이라 기존 openai SDK 코드를 그대로 쓰는 점도 컸어요.

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AIRCLOUD_API_KEY"],
    base_url="https://api.aieev.example/v1",  # 실제 콘솔 값으로 교체
)

3-2. 시간 단위 (GPU hours) 과금 + SDK로 start() / stop()

공식 약관에 따르면 청구 단위는 GPU hours + egress + storage 기반. 즉 시간 단위 종량 과금입니다. (제가 처음에 "분 단위"라고 잘못 알고 있었던 부분 - 글 정리하면서 공식 페이지 다시 확인하니 시간 단위였습니다.)

그리고 SDK에서 직접 start/stop을 부를 수 있다는 점. 이게 뒤에 나올 SQS 기반 wake/sleep 오케스트레이션의 전제 조건입니다. AWS EC2 API + 직접 로직 + CloudWatch + cooldown + 비용 알람을 일일이 엮는 것보다 진입이 훨씬 가볍습니다.

다만 한 가지 짚어두면 좋을 부분 - 결제 정책은 final sale이에요. 사용하지 않은 시간이나 크레딧도 환불 불가. 분쟁은 청구서 발급일로부터 15일 이내 이의 제기. 도입 전에 충분히 PoC로 검증하라는 신호입니다.

3-3. 진입 마찰이 낮다 - 학생/연구생 프로그램은 명확하게 안내됨

AirCloud는 GitHub OAuth로 가입 (Air ID), 결제는 Stripe / Payoneer 기반.

공식 페이지에 명확하게 공개된 혜택은 학생·대학 연구실 대상 "Air Cloud Research Program" 입니다 (글 작성 시점 기준 ~5/31 진행). 기본 1만원 크레딧 + 후기 작성 선착순 5명 AirPod 4 증정이 명시되어 있어요. 자격이 되면 결제 카드 없이도 PoC와 실험이 가능합니다.

벤처기업 인증 받은 스타트업 대상의 추가 크레딧 지원 같은 프로그램도 사내에서 들은 적은 있는데, 공식 페이지에서 직접 확인되는 건 위 학생/연구자 프로그램입니다. 자세한 조건은 직접 문의하는 게 정확하겠지요..?

3-4. Air API의 모델 라인업 - 멀티모달 워크로드와 결이 맞음

우리 영상 enrichment 파이프라인은 텍스트 LLM 하나로 끝나지 않고 음성·이미지·텍스트를 함께 다루는 멀티모달 워크로드입니다. Air API 라인업: Qwen3.5-35B-A3B, Qwen3.5-9B, Qwen3-TTS Beta (글 작성 시점 모두 Coming Soon). 한국어/멀티모달/음성을 한 콘솔 아래에서 다룰 수 있는 로드맵이 회사 영상 enrichment 컨텍스트와 결이 맞습니다.

OpenAI 호환 API 위에서 LLM 호출 코드 그대로 두면서, 모델만 회사 워크로드에 더 맞는 sLLM/멀티모달로 갈아탈 수 있는 옵션이 열려있는 것

---

4. 솔직히 처음엔 의심했..죠 - "PC방 컴퓨터 빌리는 거 아닌가...?"

분산형 GPU 클라우드라는 단어를 처음 들었을 때 솔직한 감정.

회사가 도입한 거라 일단 운영은 시작했지만, "어… 분산형이면 누가 어느 PC에서 돌리는 건지 모르는 거 아닌가? 보안은? 데이터는?" 막연한 의심이 있었습니다. 솔직히 신뢰도가 인상상 조금 낮게 시작했어요.

근데 운영하고 공부해보면서 이 느낌은 인상의 문제지 실체의 문제가 아니라는 걸 알게 됐습니다.

• 컨테이너 격리 - GPU 노드 위에서 컨테이너 단위로 작업이 돌아갑니다. 같은 노드의 다른 작업과는 격리돼요. AWS EC2가 underlying 하드웨어를 다른 고객과 공유한다고 해서 "공용 PC 같은데?"라고 하지 않는 거랑 같은 결입니다.
• API 키 + endpoint별 워커 분리 - 우리 쪽 큐와 모델만 우리 endpoint에 붙고, 결과는 우리 S3/DB로 떨어집니다. 노드 공급자 쪽에서 무슨 모델이 도는지조차 확인 안 됩니다.
• AirCloud+ 엔터프라이즈 옵션이 ISO 27001 인증 - 분산형이라는 단어 때문에 거버넌스가 약할 거라는 추측은 사실과 다릅니다. 보안 민감한 워크로드를 위한 옵션 라인이 별도로 있어요.
• 퀄리티 - 공식적으로 지원하는 GPU 범위는 NVIDIA RTX 3070부터 RTX 6000 Ada Generation, A100 등 다양. 추론 지연도 AWS g5 시리즈 대비 체감 차이 없어요. 가벼운 OCR과 무거운 reranker를 GPU 등급별로 매칭하기가 오히려 더 쉬웠습니다.

결론적으로, "분산형"은 가격을 낮추는 메커니즘이지 보안/품질을 낮추는 메커니즘이 아닙니다. 그렇게 만들어져 있으면 애초에 B2B 고객을 못 받겠죠. 인상만 가지고 미루지 마세요 - 저처럼 시작 전에 괜히 마음의 비용을 들였습니다.

---

5. 본인 기여 - gpu_orchestrator 패턴을 playground에 이식한 기록

여기부터가 진짜 본인이 직접 한 일입니다. (부풀리기..)

사내 worker-sdk에 이미 gpu_orchestrator 모듈이 있었고, 메인 서비스에서는 잘 굴러가고 있었어요. KPI 항목 중 "playground 환경에서도 같은 효율을 얻을 수 있는가" 라는 과제가 떨어졌고, 그걸 Phase 0~2까지 진행했습니다.

5-1. 기본 루프

# 사내 worker-sdk의 gpu_orchestrator 패턴 — 의사 코드
def check_and_manage(queue_name: str):
    depth = sqs.get_queue_depth(queue_name)

    if depth > 0:
        aircloud.start(endpoint=worker_endpoint)   # GPU ON
        return "WOKEN"

    # cooldown_checks 횟수 연속 idle이면 stop
    if idle_streak >= COOLDOWN_CHECKS:  # 3회 × 5분 = 15분 idle
        aircloud.stop(endpoint=worker_endpoint)    # GPU OFF
        return "STOPPED"

스케줄러가 5분마다 큐 길이를 보고, 있으면 깨우고 없으면 재운다. 단순한 루프지만 효과는 큽니다.

5-2. 운영하면서 짜낸 절약 디자인 결정들

이식 과정에서 메인 서비스 설정값을 그대로 옮기지 않고, playground 워크로드 특성에 맞춰 다음을 조정했습니다.

① wake debounce (5분)
SQS depth가 출렁이면 GPU도 같이 출렁이는 flapping이 생깁니다. 5분 안에는 중복 wake 차단. stop → 곧바로 start 같은 낭비를 막아요.

② cooldown_checks 튜닝
3회 × 5분 = 15분 idle 이후에야 stop. 짧은 휴식 후 다시 켜는 cold-start 비용과 idle 15분 추가 발생 비용 중 어느 쪽이 싼지 비교하고 큐 종류별로 조정. reranker처럼 사용자 응답 경로는 더 길게, 야간 배치성 큐는 더 짧게.

③ 워커 그룹 분리
무거운 reranker / 가벼운 OCR을 같은 GPU에서 굴리지 않게, endpoint별 컨테이너를 다른 GPU 등급에 매칭. 가벼운 큐는 더 싼 GPU만 깨우니까 자연스럽게 추가 절약.

④ LLM API 통합 크레딧 - 버퍼 줄이기
GPU 컨테이너(Air Container)와 LLM API(Air API)가 같은 크레딧 풀에서 빠지니까, 한쪽에 여유분 잡아둘 필요가 없어요. AWS면 EC2 prepaid + Bedrock prepaid 둘 다 따로 버퍼 잡아야 하는데, AirCloud는 한 풀이라 미사용 버퍼 자체가 줄어듭니다.

⑤ fail-open + 명확한 error 로그
멘토 코드 리뷰에서 짚어준 부분. AirCloud 호출 실패 시 워커를 죽이지 않습니다 - 검색 SLA가 더 중요하니까. 대신 logger.error로 명확하게 남기고 startup probe에 걸리게 해요. silent fail은 절대 금지.

5-3. 체감 절약

정확한 숫자는 회사 정보라 적을 수 없지만, 자릿수 수준으로 말하면

24/7 켜놨을 때 대비 실가동 시간 기준으로 거의 한 자릿수 분의 일까지 떨어졌습니다.

여기에 AirCloud의 시간 단위 종량 단가가 AWS GPU 온디맨드 대비 더 저렴하고, GPU hours 기반이라 24시간 풀가동이 아니라면 절약 폭이 더 커집니다.

이 절약 자체는 메인 서비스가 이미 보고 있던 효과지만, playground 환경에서도 동일한 효과를 재현해낸 게 본인 KPI 산출물이었습니다 (부풀리기..).

---

6. 트러블슈팅 - 이식 과정에서 부딪힌 3건

이게 인턴 입장에서 가장 학습 가치가 컸던 부분입니다.

① Pydantic Settings 대소문자 불일치

SDK는 getattr(settings, "aircloud_enabled") (소문자), playground 환경변수는 AIRCLOUD_ENABLED (대문자). Python getattr은 case-sensitive라 항상 None. @property alias로 해결.

@property
def aircloud_enabled(self) -> bool:
    return self.AIRCLOUD_ENABLED

② SDK 버전 호환성

gpu_orchestrator 모듈은 사내 worker-sdk 0.3.3+ 부터 포함. playground는 0.1.0이라 import부터 실패. requirements.txt에 >=0.3.3 명시 + CI에 import 스모크 테스트 추가.

③ 필드명 컨벤션 차이

기존 환경변수 AWS_SQS_*_QUEUE_URL ↔ SDK 기대 sqs_*_queue_url. 운영 환경변수 일괄 변경은 위험하니 Settings @property 매핑으로 흡수.

세 건 공통점: SDK 자체는 깔끔, 기존 코드베이스 컨벤션과 만나는 지점에 어댑터 한 겹이 필요합니다. 이게 인턴 입장에서 정말 좋은 학습이었어요 — "SDK 그대로 도입" 같은 건 현실에 없습니다. 컨벤션 차이를 흡수하는 게 사실상 DevOps 일의 절반이라는 걸 체감.

---

7. AWS vs AirCloud - 회사 입장이 아니라 인턴이 본 일반적 비교

(이건 의사결정 톤이 아니라, 운영자 관점에서 두 플랫폼이 어떻게 다르게 느껴지는지 정리입니다. 공식 페이지에서 직접 확인 가능한 사실 위주로.)

항목	AWS	AirCloud(AIEEV)
가입 인증	AWS 계정 + 카드 등록	GitHub OAuth (카드 없이도 PoC 가능)
결제 처리	AWS Billing	Stripe / Payoneer
학생/연구자 프로그램	AWS Educate, 별도 신청	Air Cloud Research Program (1만원 크레딧 + 후기 작성 선착순 5명 AirPod 4)
GPU 과금 단위	시간 단위 (Savings Plan 외)	시간 단위 (GPU hours)
환불 정책	일부 환불 가능	Final sale, 환불 불가 (15일 내 이의 제기)
start/stop API	EC2 API + 직접 로직	SDK 단일 함수
LLM API 통합	별도(Bedrock 등)	Air API (OpenAI 호환) + 같은 콘솔
분산/집중 구조	집중형 (자체 데이터센터)	분산형 (Community) + 자체 노드 (Dedicated) + 엔터프라이즈(ISO 27001)
지원 GPU	g4/g5/p4 등 인스턴스 타입 사전 결정	RTX 3070 ~ RTX 6000 Ada Generation, A100 등
자본/시간이 충분할 때	매니지드 생태계 압도적	진입 비용 낮음
학생/PoC 단계일 때	진입 부담 큼	명확한 우위

AWS를 부정하는 글이 아닙니다. 시리즈 B+ 이상 단계 회사라면 AWS의 매니지드 생태계가 여전히 1순위라고 생각해요.

다만 시드~프리A 단계나 PoC, 학생/연구자 환경에서는 AirCloud가 진입 비용 측면에서 합리적이라는 걸 운영하면서 체감했습니다.

---

8. 정리

항목	평가	메모
가입/PoC 마찰	★★★★★	GitHub OAuth + 학생/연구자 프로그램 1만원 크레딧
GPU 컨테이너 UX	★★★★☆	SDK 깔끔, 어댑터 한 겹 필요
LLM API 호환성	★★★★★	OpenAI base_url 한 줄 교체
가격 경쟁력	★★★★☆	시간 단위 + Community Cloud 효과 큼
보안/품질 (분산형이라고 떨림 X)	★★★★☆	컨테이너 격리 + ISO 27001 옵션
결제·환불 유연성	★★★☆☆	Final sale 정책 — 도입 전 충분한 PoC 필요
인턴/주니어 학습 가치	★★★★★	gpu_orchestrator + 트러블슈팅 실전 자산

 

AirCloud가 깔려 있는 환경에서 인턴이 GPU 오케스트레이션 패턴을 실제 프로덕션 수준으로 운영해보고, 컨벤션 차이를 어댑터로 흡수하는 일까지 경험할 수 있었습니다. 무지성으로 좋다고만 하기보다는, 환불 불가 같은 정책은 미리 알고 들어가는 게 좋고, GPU hours 기반이라 워크로드가 24시간 풀가동에 가깝다면 절약 효과는 줄어들 수 있다는 점도 고려해야 합니다.

그래도 처음의 "PC방 컴퓨터 빌리는 거 아냐?" 라는 막연한 의심은 운영해보고 공부해보면서 깔끔하게 사라졌습니다. 분산형이라는 단어가 주는 인상 때문에 미루기 아까운 플랫폼이에요. 도입 결정은 위에서 내렸지만, 그 위에서 굴려본 인턴 입장에서도 - 기존 AWS를 쓰던 회사가 AIRCLOUD로 migration 할만큼 매력적인 퀄리티와 가성비가 있다고 느꼈습니다.