저는 RTX PRO 6000 Blackwell Max-Q를 구매했습니다. 96GB VRAM, Blackwell 아키텍처, 전문가용 워크스테이션 GPU입니다. Max-Q 변형 모델임에도 불구하고, 개인에게는 터무니없이 큰 구매입니다. 솔직히 말씀드리겠습니다. 이것은 언박싱(unboxing) 포스트가 아닙니다. 그런 글은 이미 차고 넘칩니다. 벤치마크(Benchmark) 기사도 마찬가지고요. 제가 쓰고 싶은 내용은, 96GB를 가졌을 때 실제로 무엇을 설계할 수 있는가에 대한 것입니다 — 제 자체 서비스(Kotonia)와 비디오 자동 생성 파이프라인을 기준으로 말씀드리겠습니다. 기술적인 부분을 먼저 다루겠습니다. 배경 이야기는 마지막에 배치하겠습니다. 시(poem)부터 나오면 여러분은 탭을 닫아버릴 테니까요.

96GB는 단순히 "여러 모델을 수용할 수 있음"을 의미하는 것이 아닙니다 — 그것은 "에이전트 루프(Agent Loops)를 실행할 수 있음"을 의미합니다.

대부분의 GPU 리뷰 기사는 단일 모델 벤치마크에서 끝납니다: LLM 토큰/초(tokens/s), Stable Diffusion 이미지당 소요 시간 등입니다. 그것이 틀린 것은 아니지만, 개인 개발자가 96GB를 구매하는 진짜 이유는 아닙니다. 제가 실행 중인 음성 역할극(voice roleplay) + 스토리보드-to-비디오 파이프라인을 예로 들어보겠습니다. 하나의 요청 타임라인에 걸쳐 여러 개의 무거운 모델들이 작동합니다.

타임라인 →
[Stage A] Gemma 4 31B NVFP4 (38 GB) ← 구조 생성 (오케스트레이터 (orchestrator))
[Stage B] HiDream-O1-Image (~20 GB) ← 5비트 일관된 이미지 (T2I + 편집 x5)
[Stage C-1] Irodori-TTS / Qwen3-TTS ← 6비트 분량의 오디오
[Stage C-2] Ditto talkinghead (3 GB) ← 대화 비트
[Stage C-3] LTX-2 A2V (피크 24 GB) ← 반응 비트
[Stage C-4] Qwen3-ASR ← 생성된 비디오에 대한 오디오 체크
[Stage C-5] Gemini 3.1 Pro Preview (API) ← 멀티모달(multimodal) 편집
↓ 피드백 [--regen-beats N]
비트당 재생성 ← 루프(loop)

여기서 핵심은 리뷰어(reviewer) → 재생성 피드백 루프입니다. 시스템이 출력을 보고 "3번 장면을 다시 하라"고 결정하면, 오케스트레이터, 이미지 참조, TTS

실시간 서비스 운영 중에 제 RTX PRO 6000 Blackwell Max-Q (96GB)에서 1 Hz 주기로 nvidia-smi를 실행하여 세 가지 사례를 포착했습니다.

사례 D: Warm Idle Baseline (프로덕션 서비스 실행 중)

• TTS 서버 (Kokoro + Whisper): 8.9 GiB
• Qwen3-TTS standard (vllm-omni): 20.1 GiB
• HiDream-O1-Image: 19.4 GiB
• Ditto talkinghead: 3.0 GiB
• LTX-2 A2V (cold-start 모드): 1.5 GiB
  ─────────────────────────────────────────
• 합계: 52.8 GiB

30초 동안 완전히 평탄하게 유지되었습니다 (GPU 사용률 0%). 이는 들어오는 요청이 없는 상태에서의 상주 비용 (resident cost)입니다. 로컬 LLM (Gemma 4 31B)은 아직 여기에 없습니다. 이는 사례 B에서 나타납니다.

사례 A: 단일 장면 A2V 생성
최소 흐름 — "귀여운 소녀가 유혹적으로 속삭인다":
HiDream이 이미지 1장을 생성 → Qwen3-TTS가 속삭이는 오디오를 생성 → LTX-2 A2V가 이를 결합합니다. 총 소요 시간: 138초. VRAM 패턴이 흥미롭습니다: 최소 52.8 GiB (베이스라인) → 피크 75.0 GiB → 다시 52.8 GiB로 복귀.

델타(Delta): +22.2 GiB, 이는 LTX-2가 자체적으로 보고한 peak_vram_gib=23.9 GiB와 거의 정확히 일치합니다. LTX-2의 스파이크는 3가지 연산 단계로 나뉩니다: stage_1 (denoiser) → 해제 → stage_2 (high-res denoiser) → 해제 → spatial upscaler.

Cold-start + fp8-cast 설계 덕분에, LTX-2는 각 단계 직전에 로드되고 직후에 언로드되어 피크를 24 GiB로 유지합니다. (지속적인 bf16 모드를 사용하면 86 GiB의 상주 메모리가 필요합니다 — 제 이전 포스트인 '단일 96GB GPU에서 LTX-2.3 cold-start와 TTS의 공존'을 참조하세요.) 이로 인해 96 GiB 한도 아래에 21 GiB의 여유 공간(headroom)이 남습니다.

사례 B: 로컬 LLM (31B) + 스토리보드 생성, 병렬 실행
20 GiB를 확보하기 위해 Qwen3-TTS를 종료한 다음, Gemma 4 31B NVFP4 (42.8 GiB)를 시작합니다. 그런 다음 storyboard.run을 실행합니다. —

• Stage A: 31B가 5비트 구조를 생성 →
• Stage B: HiDream이 1개의 베이스 이미지 + 5개의 비트 편집본을 생성합니다.

이것이 제가 여러분께 가장 보여드리고 싶은 그래프입니다. VRAM은 거의 움직이지 않습니다 — 74.5 GiB에서 76.4 GiB로 +1.9 GiB 증가했으며, 본질적으로 평탄합니다. 왜일까요? 31B, HiDream, TTS, Ditto, 그리고 LTX-2가 모두 전체 시간 동안 상주(resident)하고 있기 때문입니다. 오직 HiDream의 작업당 할당량만이 총량에 추가됩니다.

GPU 사용량 추적(utilization trace)을 보면 6번의 급격한 스파이크(1번의 베이스 + 5번의 비트 연산)가 나타나는데, 이는 상주형 에이전트(resident-agent) 설정에서 "VRAM을 건드리지 않고 연산(compute)만 실행되는" 교과서적인 모습입니다. 이것이 바로 96GB가 실제로 제공하는 가치입니다. 리뷰어가 "다시 해봐"라고 말하는 순간, 모든 모델이 예열(warm)되어 즉시 실행될 준비가 되어 있습니다.

한계점 (Where the Limits Are)
96GB가 무한한 것은 아닙니다. 세 가지 실질적인 경계가 나타났습니다.

1. 비디오 생성 + 로컬 LLM (31B) + 편집 리뷰어(editorial reviewer) 동시 실행 = 용량 초과
   계산: 31B: 42 GiB / LTX-2 피크: +22 GiB / HiDream + TTS + Ditto: ~22 GiB / 편집 리뷰어 (Gemma 4 E4B): 20 GiB / 총합: 106 GiB → 96 GiB 한도 초과. 이를 맞출 깔끔한 방법이 없습니다. 이것이 바로 제가 편집 리뷰어를 Gemini 3.1 Pro Preview로 오프로드(offload)하기로 결정한 정확한 이유입니다.

2. 편집 신호(Editorial signals)를 포착하려면 프런티어 모델(frontier model)이 필요함
   VRAM 제약을 넘어 품질 문제가 존재합니다. 비디오의 미세한 버그들—오디오 잘림, 캐릭터 목소리 불일치, 페이싱(pacing) 문제 등—은 로컬 4B 모델에 의해 그냥 승인(rubber-stamped)되어 버리는 경향이 있습니다. 프런티어 멀티모달 모델(Gemini 3.x Pro 등)은 동일한 비디오를 보고 "5번 장면이 'I ate p-'에서 잘렸습니다"와 같은 피드백을 줍니다. 저는 이에 대해 'Reproducing Language-Learning Short Videos with Claude Code'에서 작성한 바 있습니다. 한 달에 100~500번의 리뷰를 수행할 때 비용은 몇 달러 수준이므로, 편집 레이어(editorial layer)를 위해 프런티어 API를 사용하는 것은 완전히 합리적입니다.

3. Qwen3-TTS Base (음성 복제)와 CustomVoice (사전 설정 화자)를 동시에 실행할 수 없음
   이상적으로는 사전 설정 화자(예: "속삭임", "화남" 등의 지시어 스타일 제어 포함)와 음성 복제(임의의 음성 샘플 복제)를 모두 제공하고 싶습니다. 두 가지를 모두 상주(resident)시키면 +40 GiB가 추가됩니다. Case D의 52.8 GiB 워밍 아이들(warm idle) 상태에 이를 더하면 대기 상태에서만 73 GiB가 됩니다. 여기에 Case A의 LTX-2 피크(+22.2 GiB)를 더하면 95 GiB가 되어 한도에 간신히 걸치게 되는데, 이는 실용적이지 않습니다. 이는 "96 GiB가 있더라도, 제공하고 싶은 모든 기능이 다 들어갈 수는 없다"는 구체적인 사례입니다. Kotonia는 현재 사전 설정 화자만 제공하며, 음성 복제는 의도적으로 제외되었습니다. 이는 실수(oversight)가 아닌 설계상의 결정(design call)입니다.

결론: "모든 것을 로컬에서"가 아니라, "각각의 용도에 맞게 사용하라"

96GB는 모든 것을 로컬에서 실행하기 위한 것이 아닙니다. 그것은 로컬에서 실행되어야 하는 것들을 집중시키기 위한 그릇입니다.

로컬에서 실행할 것: 오디오 생성 (audio generation), 이미지 생성 (image generation), 비디오 생성 (video generation), 립싱크 (lip sync) — 지연 시간 (latency)이 중요하며, 호출당 비용이 들지 않고, 루프 (loops)가 빠르게 반복되어야 합니다.

API로 오프로드 (Offload)할 것: 편집 리뷰어 (editorial reviewer), 장문 추론 (long-form reasoning) — 프론티어 (frontier) 모델이 품질과 VRAM 비용 측면 모두에서 승리합니다.

트레이드오프 (tradeoff)를 수용할 것: 동시 음성 복제 (simultaneous voice cloning) + 프리셋 화자 지원 — 물리적으로 들어가지 않습니다.

클라우드 GPU를 대여하는 것도 하나의 옵션이었습니다. 하지만 시간 기반 과금 방식은 "루프를 더 많이 실행할수록, 더 많은 돈을 잃는다"는 것을 의미합니다. 96GB를 소유하면서 프론티어 API를 선택적으로 사용하는 것이, 개인 개발자가 반복 속도 (iteration speed) 측면에서 싸울 수 있는 유일한 방법이라고 저는 생각합니다.

내가 여기까지 오게 된 과정

아래 내용은 모두 개인적인 뒷이야기입니다. 기술에만 관심이 있다면 지금 탭을 닫으셔도 좋습니다.

200달러짜리 Chromebook으로 코딩 배우기

제가 프로그래밍을 배울 때 사용했던 기기는 200달러짜리 Chromebook이었습니다. 그것이 당시 제가 선택할 수 있는 현실적인 옵션이었습니다. 하지만 AI 작업을 하고 싶어 하는 사람에게 200달러짜리 Chromebook은 고통스러울 정도로 성능이 낮았습니다. 로컬 LLM (Local LLMs)은커녕, 적당히 무거운 개발 환경 (dev environment)을 돌리는 것조차 고역이었습니다. "언젠가는 진짜 GPU를 갖고 싶다"라는 생각이 오랫동안 머릿속을 떠나지 않았습니다.

Colab으로 버티기

저는 Google Colab을 사용했습니다. 무료 티어와 저렴한 런타임(runtimes), 그저 그럴듯하게 흉내 내기에는 충분한 수준이었습니다. 저는 사양에 맞는 모델을 골랐고, 사양에 맞는 코드를 짰으며, 사양에 맞는 실험을 수행했습니다. 그것은 항상 임시방편처럼 느껴졌습니다. 제가 실제로 다루고 싶었던 것들은 로드되지 않았습니다. 조금만 무리하게 밀어붙이면 충돌(crash)이 발생했습니다. 세션은 타임아웃(time out)되었습니다. 환경 설정 (environment setup)은 매 실행마다 시간을 잡아먹었습니다. 빌려온 GPU, 빌려온 시간, 빌려온 작업 공간. 마치 나의 야망을 다른 사람의 일정에 맡겨버리는 것과 같았습니다.

그동안 AI는 계속해서 가속화되었습니다. GPT가 등장했고, LLM이 폭발적으로 늘어났으며, 오픈 소스 (OSS) 모델들이 강력해졌습니다. 저의 타임라인은 강력한 기기를 가진 사람들이 실제 연구 결과들을 게시하는 사람들로 가득했습니다. 저도 그 편에 서고 싶었습니다.

저는 AI 스타트업에 합류했습니다. 하지만 잘 되지 않았습니다.

저는 마침내 AI 스타트업에 합류했습니다. 하지만 조직 환경이 너무 험난하여 지속 가능하지 않았습니다. 기술이 아무리 흥미롭더라도, 망가진 환경은 사람을 무너뜨립니다. 저는 드디어 AI 작업에 가까워졌지만, 그 과정에서 마모되어 가고 있었습니다. 하지만 AI 자체에 대한 관심은 결코 떠나지 않았습니다. 오히려 제 방식대로 해보고 싶다는 열망은 더 강해졌습니다. 프리랜서, 그리고 떨리는 손으로 결제하기. 저는 프리랜서가 되었습니다. 약 6개월이 지났을 때, 저는 마침내 큰 개인적 투자를 고민할 수 있는 정신적 여유를 갖게 되었습니다. 가장 먼저 떠오른 것은 GPU였습니다. 물론 그 돈을 더 보수적으로 사용할 방법들—저축, 세금, 비상금, 업무용 하드웨어—도 있었습니다. 하지만 저는 수년 동안 "언젠가, 더 좋은 장비를 갖게 되면"이라고 말해왔습니다. 여기서 다시 말하자면, 그 "언젠가"는 계속해서 멀어지기만 할 것이었습니다. 결제 버튼을 클릭할 때 제 손은 말 그대로 떨리고 있었습니다. "내가 정말 이걸 하는 건가? 이게 제정신인가? 잘못되면 어떡하지?" 돈을 이체하려고 했을 때, 은행은 이를 의심스러운 거래로 간주하고 차단했습니다. 그럴 만도 했습니다—갑자기 고사양 GPU를 구매하는 것이니까요. 하지만 저는 이 결정에 실질적인 것을 걸어둔 상태였기에, 그 순간 막히는 것이 진심으로 당혹스럽게 느껴졌습니다. 결국 결제는 완료되었습니다. 박스가 도착했을 때, 저는 "GPU"라고 생각하지 않았습니다. 저는 이렇게 생각했습니다: 이것은 내가 포기하지 않았던 모든 시간에 대한 물리적 형태이다.

지금 무엇이 돌아가고 있는가 (몇 주 경과 후)

Kotonia (Voice Roleplay)
kotonia.ai의 저의 주요 제품입니다. 실시간 대화 파이프라인: VAD + STT + LLM + 다국어 TTS + Ditto 립싱크(lip sync). Qwen3-TTS (10개 언어, 프리셋 화자 + 지시어) 및 Ditto 토킹헤드(talkinghead)를 사용하여 데이트, 판타지 동반자, 언어 학습 파트너와 같은 역할극(roleplay) 사용 사례를 목표로 합니다.

스토리보드-투-비디오(Storyboard-to-Video) 자동 생성 파이프라인
아이디어 하나 → 약 4분 만에 5비트 구조의 코미디 숏폼 영상 제작. Case B의 확장 버전입니다. 일관된 5개의 이미지를 위한 HiDream, 오디오를 위한 Irodori-TTS / Qwen3-TTS, 비디오를 위한 Ditto + LTX-2, 편집 검토를 위한 Gemini 3.1 Pro를 사용합니다.

HiDream Studio (무료): kotonia.ai/studio 에서 제공되는 Adobe Firefly 스타일의 3분할 UI. 다섯 가지 기능: 텍스트 투 이미지 (T2I), 편집, 캐릭터 일관성 (character consistency), 가상 시착 (virtual try-on), 그룹 사진 구성. 96GB GPU에 상주하며 실행되는 HiDream-O1-Image (2026-05 기준 최고의 오픈 웨이트 (open-weight) T2I). Codex CLI + Local Gemma 4 codex exec -p gemma4는 OpenAI 호환 API를 통해 로컬 LLM을 서브 에이전트 (sub-agent)로 전환합니다. CLI 에이전트는 API 비용 없이 실행됩니다. Case B 31B 설정이 바로 이 구성입니다.

관련 포스트: 이 머신을 중심으로 작성한 기술 문서들:

• LTX-2 22B: fp8_cast를 통한 피크 VRAM 40% 감소
• 단일 96GB GPU에서 LTX-2.3과 TTS의 콜드 스타트 (Cold-Start) 공존
• Claude Code로 언어 학습 숏폼 영상 재현하기 — Gemini를 서브 에이전트로 사용하는 멀티모달 (Multimodal) 확장
• HiDream-O1-Image를 3~8배 더 빠르게 사용하기: 스텝 (Steps), CFG 및 해상도 벤치마킹
• HiDream Skeleton: 프롬프트가 OpenPose 참조를 압도함 (8가지 패턴 증거)

요약: 나는 RTX PRO 6000 Blackwell Max-Q를 구매했습니다. 이것은 언박싱 리뷰가 아닙니다. 1인 개발 과정에서의 컴퓨팅 아키텍처 결정 사항을 기록하기 위해 작성했습니다. 96GB의 진정한 가치는 용량이 아니라 상주성 (residency)에 있습니다. 이는 실행되는 에이전트 루프 (agent loops)와 정체되는 루프 사이의 차이입니다. 여전히 물리적 한계는 존재합니다 (로컬 LLM + 비디오 + 리뷰어를 동시에 실행하는 것은 불가능합니다). 로컬 대신 프론티어 API (frontier API)를 언제 사용해야 하는지 아는 것이