Skip to main content

2장. 환경 구축

좋은 워크플로우는 좋은 아이디어에서만 나오지 않는다. 더 정확히 말하면, 좋은 워크플로우는 안정적인 작업 환경에서 나온다. 프롬프트를 아무리 잘 써도 PyTorch와 CUDA가 어긋나 있으면 시작 버튼 앞에서 멈추고, 멋진 영상 워크플로우를 구해와도 VRAM이 버티지 못하면 진행 바만 바라보게 된다. 이 장의 목표는 단순히 ComfyUI를 "켜는 것"이 아니라, 이후 장들에서 이미지와 영상을 꾸준히 뽑아낼 수 있는 프로덕션용 작업 기반을 만드는 것이다.

PART 1 / 2장. 환경 구축

2.1 하드웨어 요구사항 (NVIDIA / AMD / Apple Silicon)

ComfyUI는 가벼운 메모장 앱이 아니다. 사실상 GPU를 중심으로 돌아가는 작은 제작 스튜디오에 가깝다. 그래서 환경 구축의 첫 질문은 늘 같다. 내 장비로 어디까지 가능한가?

NVIDIA 기준으로는 SDXL이 대체로 6GB VRAM 이상에서 출발선이 보이고, FLUX 계열은 8GB 이상이 현실적이다. 영상 쪽으로 넘어가면 8GB에서도 입문은 가능하지만, 로컬 영상 생성의 체감 품질과 속도는 24GB 이상에서 훨씬 여유로워진다.12 즉, "실행 가능"과 "실무 가능"은 다르다.

AMD도 2026년에는 더 이상 변방이 아니다. AMD는 ROCm 7.1.1 기반의 ComfyUI 공식 통합 경험을 발표했고, Windows용 설치기, 포터블 빌드, 수동 설치까지 세 갈래를 제시했다.3 특히 Ryzen AI 계열이나 Radeon AI Pro 급 장비에서는 꽤 진지한 선택지가 되었다.

Apple Silicon은 조용하지만 꾸준하다. M1, M2도 돌아가지만 속도 면에서는 여전히 인내심 테스트에 가깝고, M3 이상에 16GB 이상 통합 메모리 구성이 입문선으로 더 적합하다. 중요한 점은 맥의 메모리가 VRAM과 시스템 메모리를 함께 쓴다는 사실이다. 즉, 브라우저 탭 47개를 열어 둔 상태에서 생성 버튼을 누르면, Mac이 당신을 원망할 수 있다.4

플랫폼입문 권장선실무 권장선한 줄 평가
NVIDIARTX 3060 12GB 또는 4060 8GB급4090 24GB 이상, 영상은 24GB+가장 호환성이 좋고 자료가 많다
AMD지원 ROCm 환경 + 넉넉한 시스템 메모리Radeon AI Pro / Ryzen AI 상위권2026년 들어 공식 지원이 빠르게 좋아졌다
Apple SiliconM3 + 16GBM3/M4 + 24GB 이상이동성과 편의성은 좋지만 대형 영상 모델은 제한적

GPU만 보면 절반만 맞는 답이다. 남은 절반은 시스템 RAM과 저장장치다. 이미지 중심이면 RAM 16GB로도 시작할 수 있지만, FLUX·영상·배치 생성까지 생각하면 32GB가 훨씬 편하다.2 저장장치는 NVMe SSD를 추천한다. 모델 파일 하나가 수 GB에서 수십 GB까지 가는데, 느린 디스크는 작업 시간을 야금야금 갉아먹는다.

2.2 VRAM별 전략: 6GB, 12GB, 24GB+

VRAM은 단순한 숫자가 아니라 작업 방식 자체를 바꾼다. 같은 ComfyUI라도 6GB 환경과 24GB 환경은 사실상 다른 스포츠다.

ComfyUI는 2026년 릴리스 흐름에서 메모리 효율을 계속 끌어올렸다. v0.16.0부터 Dynamic VRAM이 기본 동작으로 자리 잡았고, v0.18 계열에서는 --fp16-intermediates, --enable-dynamic-vram 같은 메모리 절약 옵션이 추가·강화되었다.56 덕분에 예전보다 낮은 사양에서도 "아예 불가능"이 "조금 느리지만 가능"으로 바뀌는 경우가 많다.

VRAM추천 전략잘 맞는 작업주의할 점
6GB저해상도 테스트, fp8/GGUF/경량 모델, 타일드 디코드SD1.5, 가벼운 SDXL, 초안 생성해상도 욕심과 배치 생성은 금물
12GBSDXL 본격 사용, 일부 FLUX 양자화 모델, 가벼운 영상 실험이미지 실무, 편집, 업스케일LoRA·ControlNet·업스케일을 한 번에 몰아넣지 말 것
24GB+FLUX 본격 운용, 고해상도 배치, 영상 워크플로우프로덕션 이미지/영상, 대량 생성속도보다 구조가 중요해지는 구간

6GB라면 핵심은 정면 승부를 피하는 것이다. 처음부터 1024 해상도, 고급 업스케일, 두 개의 ControlNet, 세 개의 LoRA를 한 번에 태우면 거의 확실하게 OOM으로 끝난다. 이 구간에서는 "작게 만든 뒤 나중에 키운다"가 정답이다. 베이스 이미지를 작게 만든 다음 최종 단계에서 업스케일하는 2단계 설계가 특히 유리하다.

12GB는 가장 재미있는 구간이다. "못 한다"와 "된다"가 계속 뒤집히기 때문이다. SDXL은 꽤 쾌적하고, FLUX도 양자화 모델이나 보수적인 해상도 설정으로 접근 가능하다. 실무에서는 이 구간이 가성비가 가장 좋다. 대신 워크플로우를 욕심내서 길게 늘리는 순간 갑자기 숨이 찬다. ControlNet, IP-Adapter, 업스케일, 얼굴 복원, 비디오 노드를 한 장면에 다 얹지 말고, 단계별로 분리하는 습관이 필요하다.

24GB 이상부터는 드디어 장비가 사용자를 덜 괴롭힌다. 하지만 이때부터는 다른 문제가 생긴다. "되니까 다 넣자"의 유혹이다. 프로덕션에서는 여유 VRAM이 생길수록 워크플로우를 더 복잡하게 꼬기 쉽다. 이 구간의 핵심은 성능이 아니라 재현성이다. 잘 되는 그래프를 여러 명이 반복 실행할 수 있게 정리해 두는 것이 더 중요하다.

실전 팁을 하나만 기억하자. VRAM이 부족할 때는 해상도보다 파이프라인 수를 먼저 줄여라. 해상도만 낮추고 노드를 마구 쌓아 두면 체감 개선이 생각보다 작다.

2.3 ComfyUI Desktop 설치 vs Portable vs 직접 설치

ComfyUI를 설치하는 방법은 여러 가지지만, 실무 관점에서는 세 가지로 정리하면 충분하다. Desktop, Portable, 직접 설치다. 여기에 서버 운영자라면 Docker가 추가된다.

방식추천 대상장점단점
Desktop가장 빨리 시작하고 싶은 사용자설치가 쉽고 의존성 관리 부담이 적다지원 하드웨어 범위를 꼭 확인해야 한다
Portable폴더째 옮기고 백업하고 싶은 사용자격리성이 좋고 복구가 쉽다관리가 쉬운 대신 구조를 이해하기 어렵다
직접 설치개발자, 서버 운영자, 고급 사용자PyTorch/CUDA/가상환경을 세밀하게 제어 가능가장 많이 배우는 대신 가장 많이 삽질한다

Desktop은 가장 편하다. 다만 지원 범위는 시점에 따라 바뀔 수 있다. 공식 문제해결 문서는 Windows용 Desktop 앱이 NVIDIA CUDA 중심이라고 설명하지만, AMD는 2026년에 ROCm 기반의 원클릭 ComfyUI 경험을 별도로 발표했다.73 결론은 단순하다. 블로그 글보다 공식 다운로드 페이지를 마지막으로 확인하라. 지원 정보는 생각보다 빨리 변한다.

Portable은 "깨끗한 폴더 하나로 시작하고 싶은 사람"에게 좋다. 공식 포터블/압축판은 풀어서 실행하기 쉽고, Windows에서는 배치 파일로 빠르게 시작할 수 있다.8 커스텀 노드를 잔뜩 넣었다가 환경이 흔들리면, 폴더를 통째로 백업하거나 복제해서 실험 브랜치를 만들기 좋다. 저는 초보자에게도 오히려 Portable을 자주 권한다. 이유는 간단하다. 망가졌을 때 되돌리기 쉽기 때문이다.

직접 설치는 가장 강력하다. Linux 서버, 원격 GPU, 사내 공용 머신, 독자적인 Python 환경, 특정 CUDA wheel 강제 적용 같은 요구가 생기면 결국 이 방식으로 온다. 공식 문제해결 문서도 가상환경 생성, requirements.txt 설치, NVIDIA용 PyTorch wheel 설치 같은 표준 흐름을 안내한다.7 장점은 모든 걸 통제할 수 있다는 것, 단점은 문제도 전부 내 것이 된다는 것이다.

서버나 팀 운영까지 생각한다면 Docker도 매우 유력하다. Docker는 Python 의존성 충돌을 줄이고, 업데이트와 재배포를 재현 가능하게 만들며, 원격 서버에 올리기에도 편하다.1 "내 노트북은 작업용, 생성은 서버에서"라는 구조를 생각한다면 처음부터 Docker 기반 운영을 고민해 볼 만하다.

2.4 StabilityMatrix를 활용한 통합 관리

ComfyUI를 오래 쓰다 보면 문제는 설치보다 증식이다. 모델은 늘어나고, UI는 늘어나고, 실험용 폴더는 번식한다. 어느 날 보면 final, final_real, final_really_final 같은 폴더가 세 개쯤 생긴다. 이 시점에서 StabilityMatrix 같은 통합 런처가 빛난다.

StabilityMatrix의 핵심 가치는 단순하다. 여러 생성 UI와 모델 자산을 한곳에서 관리하게 해 준다는 점이다. 특히 이미 Stable Diffusion WebUI, Forge, ComfyUI를 함께 쓰고 있다면 중복 설치와 중복 모델 폴더를 줄이기 좋다. 실무에서는 "어떤 앱을 쓰느냐"보다 "모델 경로를 어떻게 공유하느냐"가 더 중요할 때가 많다.

제가 추천하는 구조는 이렇다.

  • apps/에는 실행 환경만 둔다.

  • models/는 가능한 중앙 저장소로 통합한다.

  • workflows/는 프로젝트별로 분리한다.

  • outputs/는 날짜나 클라이언트 기준으로 관리한다.

핵심은 앱과 자산을 분리하는 것이다. ComfyUI를 갈아엎어도 모델은 남고, 모델을 정리해도 워크플로우는 남아야 한다. 이 분리가 되어 있으면 새 버전 테스트, 커스텀 노드 실험, 롤백이 훨씬 쉬워진다.

StabilityMatrix를 쓴다고 해서 ComfyUI의 구조를 몰라도 되는 것은 아니다. 오히려 반대다. 이런 도구는 구조를 잘 아는 사람에게 더 큰 효율을 준다. 하지만 초보자에게도 장점이 있다. "설치는 쉬운데 나중에 정리가 안 되는" 상황을 미리 막아 준다는 점이다.

2.5 ComfyUI Manager 설치와 모델 자동화 다운로드

ComfyUI를 기본 상태로만 쓰는 사람은 드물다. 얼마 지나지 않아 ControlNet 전처리기, 업스케일러, 영상 노드, 유틸리티 노드가 필요해진다. 이때 사실상 표준 관리 도구가 ComfyUI Manager다. Docker 가이드에서도 Manager를 커스텀 노드용 표준 패키지 관리자로 소개하고, 설치 후 재시작하면 우측 상단에 Manager 버튼이 나타난다고 설명한다.1

Manager의 진짜 가치는 "설치"보다 "정리"에 있다. 워크플로우를 불러왔는데 빨간 노드가 생겼을 때, 하나씩 GitHub를 뒤져서 수작업 설치하는 대신 누락된 커스텀 노드를 빠르게 찾는 출발점이 되어 준다. 초보자가 여기서 시간을 제일 많이 아낀다.

모델 폴더 구조도 초반에 익혀 두면 좋다. ComfyUI는 모델을 한 폴더에 마구 넣는 방식이 아니라, 역할별 디렉터리로 읽는다.1

  • models/checkpoints/ : 메인 생성 모델

  • models/vae/ : VAE 디코더

  • models/loras/ : LoRA 가중치

  • models/controlnet/ : ControlNet 모델

  • models/clip/ : 텍스트 인코더

  • models/upscale_models/ : 업스케일 모델

특히 FLUX 계열은 체크포인트만으로 끝나지 않고, 텍스트 인코더와 라이선스 동의가 함께 따라오는 경우가 있다.1 모델 파일 하나만 넣고 왜 안 되지 하고 멈추는 장면은 이제 너무 흔해서 거의 장르가 되었다.

초보자에게는 Templates도 의외로 유용하다. 일부 템플릿은 필요한 모델 다운로드를 제안해 주기 때문에, 처음부터 폴더 구조와 의존 관계를 전부 외우지 않아도 된다.4 다만 실무에서는 결국 수동 관리 능력이 필요하다. 템플릿은 자전거 보조바퀴처럼 시작을 쉽게 해 주지만, 오래 타려면 직접 균형을 잡아야 한다.

Docker 환경이라면 한 가지를 더 기억하자. Manager로 커스텀 노드를 설치한 뒤에는 이미지 재빌드가 필요한 경우가 있다. 특히 추가 노드가 Python 의존성을 요구하면, 코드만 내려받고 끝나는 게 아니라 컨테이너 이미지 안에 패키지가 실제로 설치되어야 한다.9 로컬 폴더에 파일이 있다고 해서 곧바로 실행 가능한 것은 아니다.

2.6 Comfy Cloud 활용법 — 로컬 GPU가 부족할 때

로컬 GPU가 약하다고 해서 ComfyUI를 포기할 필요는 없다. 중요한 건 "항상 로컬이냐, 항상 클라우드냐"가 아니라 어느 작업을 어디서 돌리느냐다.

ComfyUI는 원래 로컬 워크스테이션, 공유 서버, 클라우드 GPU 박스 같은 여러 운영 패턴에 잘 맞는 도구다.10 이 말은 곧, 작업을 나누기 좋다는 뜻이다. 예를 들면 프롬프트 실험과 워크플로우 설계는 로컬에서 하고, 최종 대량 생성이나 영상 렌더는 클라우드에서 처리할 수 있다.

이렇게 나누면 판단이 쉬워진다.

  • 학습과 실험은 로컬에서 한다.

  • 대량 생성과 긴 영상은 클라우드에서 한다.

  • 팀 공유가 필요하면 공용 서버나 클라우드 인스턴스로 옮긴다.

클라우드를 쓸 때의 기준은 세 가지다. 속도, 비용, 프라이버시다. 광고 배리에이션 300장을 오늘 밤 안에 뽑아야 한다면 클라우드가 맞다. 반대로 민감한 클라이언트 원본 이미지를 다룬다면 로컬이 더 낫다. 그리고 월 구독형 서비스가 아니라 GPU 인스턴스를 빌리는 방식이라면, 켜 둔 시간만큼 비용이 새어나간다는 점도 잊으면 안 된다.

Comfy Cloud나 원격 ComfyUI를 쓸 때 가장 좋은 습관은 워크플로우를 먼저 로컬에서 검증한 뒤 올리는 것이다. 클라우드에서 디버깅까지 하려 들면 비용이 가장 비싼 시간에 가장 생산성이 낮아진다. 로컬에서 JSON을 정리하고, 모델 의존성을 점검하고, 입력·출력 폴더 구조까지 맞춘 다음 올리면 훨씬 덜 아프다.

서버형 운영을 한다면 Docker Compose 같은 재현 가능한 배포 방식이 특히 유리하다.1 한 번 세팅해 두면 재시작, 업데이트, 볼륨 보존이 깔끔하다. 프로덕션에서 중요한 것은 "오늘도 되네"가 아니라 "다음 주에도 같은 방식으로 된다"는 안정감이다.

2.7 PyTorch, CUDA 버전 트러블슈팅 체크리스트

환경 구축에서 가장 흔한 적은 생각보다 화려하지 않다. 대개는 아주 소박한 형태로 나타난다. 예를 들면 이런 식이다.

"왜 GPU가 있는데 CPU로 돌지?"

"어제까지 됐는데 오늘 갑자기 CUDA가 없대?"

"화면은 뜨는데 생성이 지나치게 느려."

이때는 감으로 때리지 말고, 아래 순서대로 확인하면 된다. 공식 문제해결 문서도 비슷한 흐름을 권장한다.7

  1. Python 버전과 가상환경 확인

  2. GPU 드라이버 인식 확인

  3. PyTorch가 CUDA를 보는지 확인

  4. 맞는 wheel로 PyTorch 재설치

  5. 저사양 최적화 플래그 적용

  6. 커스텀 노드 문제 분리

가장 먼저 확인할 명령은 이것들이다.

python --version
nvidia-smi
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.version.cuda)"

공식 문서는 수동 설치 시 Python 3.12 권장, 가상환경 사용, 그리고 NVIDIA용 CUDA wheel 또는 AMD용 ROCm wheel 설치를 안내한다.7 직접 설치의 기본 형태는 보통 다음 흐름이다.

python -m venv comfyui_env
# Windows
comfyui_envScriptsactivate
# Linux / macOS
source comfyui_env/bin/activate

pip install -r requirements.txt
# NVIDIA 예시
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu128

AMD는 공식 Desktop/portable 경험이 확대되고 있지만, 수동 설치에서는 ROCm wheel 기반 설정이 여전히 기준점이 된다.73 Apple Silicon은 MPS 백엔드 사용 가능 여부를 확인하고, 문제가 있으면 CPU 모드로 진단하는 식으로 접근한다.7

증상별로 보면 더 쉽다.

증상가장 먼저 볼 것보통의 원인첫 조치
Torch not compiled with CUDA enabledtorch.cuda.is_available()PyTorch wheel 불일치CUDA 맞는 torch 재설치
GPU 사용률 0%, CPU 100%nvidia-smi와 torch 버전CUDA 인식 실패드라이버/torch 재점검
시작은 되는데 매우 느림해상도, 배치, VRAM메모리 부족으로 오프로딩 과다해상도 축소, 배치 1, 최적화 플래그
갑자기 빨간 노드 다수 발생최근 설치한 노드커스텀 노드 충돌노드 비활성화, Manager로 정리
Linux에서 라이브러리 에러LD_LIBRARY_PATHCUDA/NVIDIA 라이브러리 경로 문제공식 문서대로 경로 설정

메모리 부족이 의심되면 공식 문서의 최적화 옵션도 유용하다.7

python main.py --lowvram
python main.py --preview-method none
python main.py --async-offload
python main.py --reserve-vram 2

여기에 ComfyUI의 Dynamic VRAM과 --fp16-intermediates 흐름을 이해하고 있으면, "왜 VRAM은 남는데 RAM이 터지지?" 같은 질문도 훨씬 덜 당황스럽다.56 ComfyUI는 최근 버전에서 모델 가중치를 더 똑똑하게 다루기 때문에, 예전 경험만으로 현재 동작을 짐작하면 오히려 헷갈릴 수 있다.

마지막으로 가장 현실적인 원칙 하나를 남기겠다. 문제가 생기면 플러그인부터 의심하지 말고, 먼저 환경부터 단순화하라. 기본 워크플로우, 기본 모델, 기본 노드로 돌아가서 GPU 인식과 생성만 확인해 보라. ComfyUI 문제의 절반은 화려한 그래프가 아니라, 아주 기본적인 환경 불일치에서 시작한다.

이 장에서 만든 것은 단순한 설치 환경이 아니다. 앞으로의 모든 장을 받쳐 줄 제작 기반이다. 다음 장부터는 모델이 실제로 어떻게 작동하는지, 그리고 그 작동 원리를 ComfyUI의 노드 흐름으로 어떻게 이해해야 하는지 본격적으로 살펴보자.

참고

1How to Install ComfyUI with Docker (2026 Setup Guide)

2Run AI Video Locally: LTX-2, RTX, and ComfyUI in 2026

3AMD x ComfyUI: Advancing Professional Quality Generative AI on AI PCs

4Free AI generations locally: ComfyUI setup for beginners

5Changelog - ComfyUI

6Dynamic VRAM in ComfyUI: Saving Local Models from RAMmageddon

7How to Troubleshoot and Solve ComfyUI Issues

8ComfyUI 설치 방법? ComfyUI 설치에 대한 완벽한 가이드

9GitHub - mmontes11/docker-comfyui: A production-ready Docker setup for ComfyUI that unlocks the full potential of NVIDIA Blackwell GPUs through 4-bit quantization with NVFP4

10ComfyUI: The Workflow Engine for AI Production

책 목록

프로덕션 ComfyUI: 이미지에서 영상까지, 노드로 완성하는 AI 콘텐츠 파이프라인

전체 목차 보기

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기