23장. 트러블슈팅과 성능 최적화
23장. 트러블슈팅과 성능 최적화
잘 되는 날에는 누구나 ComfyUI가 좋다고 말한다. 진짜 실력은 안 되는 날 드러난다. 어제까지 멀쩡하던 워크플로우가 오늘 OOM을 띄우고, 생성은 끝났는데 결과가 검게 나오고, 노드는 분명 설치했는데 캔버스에서는 사라져 있다. 프로덕션에서는 이런 날이 예외가 아니라 운영의 일부다.
이 장의 목적은 단순하다. 문제를 덜 겪는 법이 아니라, 문제가 생겼을 때 더 빨리 원인을 좁히고 더 안정적으로 복구하는 법을 익히는 것이다. 좋은 운영자는 "잘 돌면 된다"가 아니라 "망가져도 다시 살린다"를 기준으로 일한다.
23.1 OOM 에러 진단과 해결
ComfyUI에서 가장 흔한 장애는 OOM, 즉 Out Of Memory다. 하지만 OOM은 하나의 증상이 아니라 여러 원인의 집합이다. VRAM이 모자랄 수도 있고, 시스템 RAM이 가득 찼을 수도 있고, 모델은 들어가는데 마지막 VAE 디코드 순간에만 메모리 피크가 튈 수도 있다. 그래서 첫 번째 원칙은 "메모리가 부족하다"에서 멈추지 않는 것이다.12
가장 먼저 할 일은 에러 메시지의 첫 줄이 아니라 첫 번째 실제 실패 지점을 찾는 것이다. CUDA out of memory라면 거의 항상 GPU VRAM 문제다. 반대로 GPU 언급 없이 메모리 부족이 나오면 RAM이나 가상 메모리일 가능성이 크다. size mismatch, NoneType, missing key 같은 메시지는 메모리보다 그래프 구조나 모델 호환성 문제일 때가 많다.1
OOM을 잡을 때는 감으로 여러 옵션을 한꺼번에 바꾸지 말고, 아래 순서대로 한 단계씩 줄여야 한다.
해상도를 먼저 낮춘다.
배치를 1로 고정한다.
정밀도를 fp16, bf16, fp8, 양자화 모델 순으로 검토한다.
마지막으로 그래프 구조와 캐시 방식을 손본다.
이 순서가 중요한 이유는 해상도가 메모리 사용량에 가장 큰 영향을 주는 경우가 많기 때문이다. 특히 UNet 어텐션은 해상도 면적에 민감하고, 겉으로는 샘플링이 시작되지만 내부적으로 특정 단계에서 메모리 피크가 갑자기 치솟을 수 있다.2 1024×1024에서 터진다면 곧바로 512×512까지 떨어뜨리기보다 896×896, 832×832처럼 20~30%씩 줄여 보는 편이 좋다. 비디오 계열 모델은 8이나 16의 배수를 맞추지 않으면 숨은 패딩 때문에 오히려 비효율이 생기기도 한다.3
배치는 특히 자주 오해된다. batch_count는 여러 번 순차 실행이지만, batch_size는 동시에 여러 장을 들고 뛰는 것이다. VRAM이 빠듯한 환경에서는 batch_size=1이 기본값이다. 여러 결과가 필요하면 큐를 여러 번 돌리는 편이 안전하다.4
다음은 정밀도와 모델 크기다. fp16은 사실상 기본 선택지이고, 지원 환경이라면 bf16도 좋다. 더 공격적으로 줄여야 한다면 fp8, GGUF, NF4 같은 양자화 모델을 고려할 수 있다. 품질 손실이 아주 없다고 말할 수는 없지만, 워크플로우가 아예 죽는 것보다 약간 가벼운 모델이 훨씬 낫다. 프로덕션에서는 "최고 품질"보다 "예측 가능한 품질"이 더 비싸다.4
생성은 되는데 마지막 저장 직전에만 OOM이 난다면 범인은 종종 VAE다. 이때는 일반 VAE Decode 대신 타일 기반 디코드를 쓰면 된다. 큰 이미지를 한 번에 풀지 않고 작은 조각으로 나눠 복원하기 때문에 VRAM 피크를 크게 낮출 수 있다. 2K 이상 해상도에서 타일드 VAE는 선택이 아니라 보험에 가깝다.4
또 하나 자주 놓치는 것은 "동시에 올라가 있는 모델 수"다. SDXL, ControlNet, IP-Adapter, 업스케일러, 얼굴 복원 모델이 한 그래프에 줄줄이 붙으면 각각은 버텨도 합산 피크에서 무너진다. 이럴 때는 두 가지를 기억하면 된다. 첫째, 병렬보다 순차 로딩이 유리하다. 둘째, 중간에 메모리 해제 노드를 넣어 다음 단계 전에 숨을 쉬게 해야 한다.4
낮은 VRAM 환경에서는 실행 옵션도 꽤 큰 차이를 만든다. ComfyUI 공식 문서는 --lowvram, --novram, --force-fp16, --preview-method none, --use-pytorch-cross-attention, --use-flash-attention, --async-offload, --reserve-vram 같은 런치 옵션을 상황에 맞게 쓰라고 권한다. 특히 미리보기를 끄는 것만으로도 간헐적인 VRAM 압박이 줄어드는 경우가 있다.1
NVIDIA 사용자라면 2025년 말부터 기본 활성화된 async offloading과 pinned memory의 의미도 알아둘 필요가 있다. 이 최적화는 VRAM에 다 못 들어가는 모델을 RAM과 오가며 돌릴 때 속도 손실을 줄여 준다. 다시 말해, VRAM이 넉넉한 상황에서는 체감이 적지만, 8GB·12GB 카드에서는 "아예 안 되던 게 된다" 혹은 "되긴 되는데 너무 느리다"의 차이를 만들어 준다. 다만 NVFP4 가속은 Blackwell 계열과 CUDA 13.0 기반 PyTorch가 맞아야 제대로 이득을 본다. 조합이 어긋나면 오히려 fp8보다 느릴 수 있다.5
영상 워크플로우에서는 OOM 진단이 더 섬세해야 한다. 같은 해상도라도 프레임 수, FPS, 컨텍스트 길이, 모션 강도, 가이던스, 오디오 조건까지 얹히면 피크가 달라진다. 이때는 10초짜리 렌더를 붙잡고 씨름하지 말고 2~3초 클립으로 잘라 재현하는 것이 정답이다. 시드를 고정한 채 해상도, 정밀도, 배치만 한 번에 하나씩 바꾸면 원인을 훨씬 빨리 잡을 수 있다.3
여기서 아주 실무적인 팁 하나를 더하자. OOM 뒤에 같은 워크플로우가 갑자기 더 불안정해졌다면, 괜히 귀신을 찾지 말고 ComfyUI를 재시작하자. PyTorch 캐시와 메모리 단편화 때문에 같은 그래프도 재시작 전후 거동이 달라질 수 있다.6
23.2 EasyCache, LazyCache 활용
성능 최적화라는 말을 들으면 많은 사용자가 제일 먼저 GPU 업그레이드를 떠올린다. 하지만 실제 운영에서는 "계산을 덜 하게 만드는 것"이 "계산을 더 빨리 하게 만드는 것"만큼 중요하다. EasyCache와 LazyCache는 바로 이 지점에서 등장한다.
EasyCache는 샘플링 과정에서 이미 계산한 일부 단계를 재사용해 속도를 높이는 기본 캐싱 시스템이다. 쉽게 말해 매 스텝마다 처음부터 전부 다시 계산하지 않고, 재사용 가능한 구간은 건너뛰게 도와준다. LazyCache는 이를 더 간단하게 일반화한 버전으로, 보편적인 호환성이 장점이지만 일반적으로는 EasyCache 쪽이 더 효율적이다.78
중요한 점은 이것들이 "공짜 점심"은 아니라는 사실이다. 두 기능은 속도를 얻는 대신 세밀한 디테일이나 안정성을 조금 희생할 수 있다. 그래서 프로덕션에서는 항상 같은 질문을 해야 한다. "지금 내가 원하는 건 최대 품질인가, 충분히 좋은 품질로 더 많은 샷을 만드는 것인가?" 콘셉트 탐색, 썸네일 후보 생성, A/B 시안 대량 생성에는 잘 맞지만, 최종 납품 원본에서는 지나친 캐시 설정이 오히려 수정 비용을 늘릴 수 있다.8
설정에서 핵심은 세 가지다.
reuse_threshold는 얼마나 공격적으로 이전 계산을 재사용할지 정한다.start_percent는 샘플링의 어느 시점부터 캐시를 쓰기 시작할지 정한다.end_percent는 어디까지 캐시를 허용할지 정한다.79
실무적으로는 처음부터 큰 값을 주지 않는 편이 좋다. 기본값 근처에서 시작해, 콘셉트가 흔들리지 않는 범위까지만 올리는 식이 안전하다. 초반 구간은 큰 구조를 잡는 단계이고 후반 구간은 미세 디테일을 다듬는 단계인 경우가 많으므로, 캐시를 언제 켜고 언제 끌지에 따라 결과의 성격이 달라진다. 속도가 필요해도 마지막까지 전부 스킵하게 두면 "왜 이렇게 미묘하게 흐리죠?"라는 질문이 돌아오기 쉽다.
EasyCache와 LazyCache는 메모리 절약 도구라기보다 시간 절약 도구에 가깝다. 다만 계산량이 줄어들면 간접적으로 전체 시스템 압박도 완화될 수 있다. 특히 영상이나 장문 컨텍스트 샘플링처럼 시간이 긴 워크플로우에서는 체감이 크다. 반대로 아주 짧고 단순한 이미지 생성에서는 이득이 제한적일 수 있다.8
운영 관점에서 추천하는 방식은 이렇다. 초안 생성 파이프라인에는 EasyCache를 켜고, 최종 선별 후 리렌더 파이프라인에서는 보수적으로 쓰거나 끈다. 즉, 속도와 품질을 하나의 그래프 안에서 동시에 해결하려 하지 말고, 용도별로 파이프라인을 분리하는 것이다. 이것이 프로덕션식 사고다.
23.3 GPU 활용률 모니터링
느리다고 해서 항상 GPU가 부족한 것은 아니다. 어떤 날은 GPU가 98%로 꽉 차 있고, 어떤 날은 체감상 멈춘 것 같은데 GPU 사용률이 20%도 안 된다. 둘은 전혀 다른 문제다. 전자는 계산 병목일 가능성이 높고, 후자는 메모리 스와핑, CPU 대기, 디스크 I/O, 프론트엔드 렌더링, 혹은 특정 노드의 비효율일 수 있다.1
가장 기본적인 관찰 도구는 여전히 시스템 모니터다. NVIDIA라면 nvidia-smi와 nvidia-smi dmon만으로도 꽤 많은 것을 알 수 있다. 메모리 사용량이 거의 꽉 찬 상태에서 GPU 사용률이 출렁이면 메모리 압박이나 오프로딩이 의심된다. GPU 사용률은 낮은데 CPU만 바쁘면 전처리 노드, 인코딩, 파일 저장, 혹은 Python 레벨 병목을 먼저 의심해야 한다.1
여기에 ComfyUI 내부용 모니터를 더하면 훨씬 편해진다. ProfilerX는 워크플로우 전체 시간, 노드별 실행 시간, VRAM/RAM 변화량, 캐시 적중 여부를 수집해 병목을 눈으로 보여준다. "느리다"를 감정이 아니라 숫자로 바꿔 준다는 점에서 아주 유용하다.10 XPUSYS-Monitor는 메뉴 바에서 CPU, RAM, GPU, VRAM, PyTorch reserved 메모리까지 실시간으로 보여 주고, 실행 전 성공 가능성을 예측하는 기능도 제공한다. 특히 현재 여유 VRAM과 캐시된 VRAM을 함께 보게 해 준다는 점이 좋다.6
모니터링에서 봐야 할 값은 많지 않다. 정말 중요한 것은 네 가지다.
현재 VRAM 사용량과 피크 시점
GPU 사용률의 지속성
PyTorch reserved 메모리의 증가 패턴
특정 노드의 실행 시간 편차
예를 들어 GPU 사용률은 높은데 전체 시간이 길다면, 그건 대체로 "열심히 계산 중"이다. 반면 GPU 사용률이 낮고 VRAM만 높다면, 이미 메모리 압박으로 오프로딩과 대기가 반복되고 있을 가능성이 높다. 또 어떤 노드의 실행 시간이 매번 크게 흔들린다면, 그 노드는 입력 크기 변화에 민감하거나 외부 리소스를 기다리는 노드일 수 있다. 프로파일러가 없으면 이런 차이를 체감으로만 추측하게 된다.
프론트엔드 자체가 병목이 되는 경우도 있다. 특히 큰 그래프에서 노드가 많고 연결선이 복잡하면, 생성이 느린 게 아니라 캔버스 조작이 느린 것일 수 있다. Nodes 2.0 전환 이후 대형 워크플로우에서 드래그, 줌, 패닝이 버벅인다는 보고가 실제로 있었다.11 이런 경우 해결책은 GPU 교체가 아니라 그래프 분해다. 서브그래프를 나누고, 그룹을 접고, 자주 안 쓰는 분기는 바이패스하며, "한 화면에 모든 것을 다 올리지 않는 것"이 성능 최적화가 된다.
23.4 자주 발생하는 노드 충돌과 해결법
ComfyUI에서 가장 사람을 지치게 만드는 문제는 에러 자체보다 모호함이다. 노드가 없다고 나오는데 분명 설치했고, 워크플로우는 열리는데 일부 입력이 비어 있으며, UI는 보이는데 연결이 이상하게 끊어진다. 이럴 때는 감으로 다시 설치하지 말고 원인을 네 갈래로 나눠 본다.
프론트엔드 확장 충돌
Python 의존성 충돌
모델 파일/포맷 불일치
워크플로우 구조 문제
가장 먼저 의심할 것은 커스텀 노드다. 공식 문서도 문제 분리의 첫 단계로 --disable-all-custom-nodes 실행을 권한다. 이 상태에서 문제가 사라지면, 코어 문제가 아니라 커스텀 노드 문제다. 그다음에는 이진 탐색처럼 절반씩 다시 켜면서 범인을 좁히면 된다. 느리지만 가장 빨리 끝나는 방법이다.12
프론트엔드 확장을 건드리는 노드는 특히 주의해야 한다. 2025년 5월 이후 프런트엔드 변화와 함께 Easy Use, Impact Pack, cg-use-everywhere 같은 노드들이 UI 정렬 오류, 연결 이상, 워크플로우 로딩 실패를 일으킬 수 있다는 공지가 있었다. 반대로 AIGODLIKE 번역 플러그인은 유지보수가 중단되어 제거 권고까지 나왔다.13 즉, "노드가 설치되어 있다"와 "현재 프론트엔드와 호환된다"는 같은 말이 아니다.
오류 메시지별로 보면 패턴은 생각보다 단순하다. missing key나 state_dict 관련 오류는 대개 잘못된 체크포인트 변형을 로드했을 때 생긴다. NoneType은 이전 노드가 출력을 못 냈다는 뜻이므로, 실제 범인은 에러가 난 노드의 바로 앞에 있다. size mismatch는 한쪽 분기에서 리사이즈가 일어났는데 다른 분기에서는 안 일어났다는 신호일 때가 많다. 이 세 가지는 ComfyUI를 오래 쓸수록 언젠가 반드시 만난다.112
프로덕션에서는 업데이트 방식도 문제 해결의 일부다. 오늘 새 기능이 필요해서 코어를 업데이트했는데 내일 납품 워크플로우가 깨지면, 그건 기술 문제가 아니라 운영 실패다. 그래서 다음 원칙을 지켜야 한다.
업데이트 전 스냅샷 또는 백업을 남긴다.
코어, 프론트엔드, 커스텀 노드, Python 패키지를 한 번에 다 바꾸지 않는다.
바꿨다면 환경 카드를 함께 기록한다.
환경 카드는 거창할 필요가 없다. GPU 모델, VRAM, 드라이버 버전, PyTorch 버전, CUDA/ROCm 버전, ComfyUI 커밋, 핵심 커스텀 노드 버전, 사용 모델 해시만 적어도 된다. 문제가 생겼을 때 "어제와 오늘 뭐가 다른가"를 말로 추측하지 않고 눈으로 비교할 수 있어야 한다. 이 한 장이 디버깅 시간을 절반으로 줄여 준다.
23.5 느린 워크플로우를 진짜로 빠르게 만드는 진단 순서
속도가 느릴 때 많은 사람이 바로 샘플러나 스텝을 줄인다. 물론 효과는 있다. 하지만 그 전에 병목이 어디인지부터 확인해야 한다. 병목이 다른데 스텝만 줄이면 품질만 나빠지고 시간은 생각만큼 줄지 않는다.
실무에서는 다음 순서가 가장 효율적이다.
첫째, GPU 사용률과 VRAM 피크를 본다. VRAM이 꽉 찬 상태에서 사용률이 들쭉날쭉하면 메모리 병목이다. 이때는 해상도, 배치, 모델 수, 정밀도, 타일드 VAE를 우선 본다.
둘째, 노드별 시간을 본다. 전처리 노드나 업스케일 노드 하나가 전체 시간의 절반을 먹고 있다면, 샘플러를 조정하는 건 핵심 해결책이 아니다. ProfilerX 같은 도구를 쓰면 이 단계가 특히 빨라진다.10
셋째, 입출력 경로를 본다. 대형 비디오 저장, 네트워크 API 호출, 클라우드 경유 다운로드는 GPU와 상관없이 작업을 지연시킨다. 생성이 느린 줄 알았는데 사실 저장이 느렸던 경우도 많다.
넷째, UI 병목을 본다. 대형 그래프에서 화면 조작이 느리면 실행 속도까지 느린 것처럼 느껴진다. 이때는 브라우저 탭 정리, 캔버스 축소, 그래프 분해가 약보다 낫다.11
다섯째, 속도용 파이프라인과 품질용 파이프라인을 분리한다. 탐색 단계에서는 낮은 해상도, 캐시, 가벼운 모델, 배치 큐를 쓰고, 최종 렌더 단계에서는 고해상도와 보수적 설정으로 넘어간다. 하나의 그래프에 모든 욕심을 담으면 결국 느리고 불안정해진다.
23.6 운영 체크리스트: 안 되는 날을 위한 습관
마지막으로, 문제를 줄이는 가장 좋은 방법은 디버깅 실력보다 운영 습관이다. 아래 항목은 눈에 띄지 않지만, 실제로 가장 강력한 안정화 장치다.
새 워크플로우는 항상 짧은 프롬프트, 낮은 해상도, 짧은 클립으로 먼저 검증한다.
수정은 한 번에 하나만 한다.
잘 되는 조합은 스크린샷이 아니라 JSON, 모델명, 버전까지 함께 기록한다.
주기적으로 사용하지 않는 커스텀 노드와 모델을 정리한다.
OOM 뒤에는 재시작을 습관화한다.
납품용 환경과 실험용 환경을 분리한다.
결국 ComfyUI 운영은 마법이 아니다. 관찰, 기록, 분리, 재현의 반복이다. 잘 되는 날보다 안 되는 날이 더 중요하다는 말은 비관이 아니다. 바로 그 안 되는 날에 파이프라인의 수준이 드러나기 때문이다. 프로덕션은 화려한 데모보다 조용한 복구에서 완성된다.
참고
1ComfyUI Troubleshooting Overview
2SDXL+ComfyUI VRAM OOM 메모리 최적화
3ComfyUI에서 LTX-2 오류 해결: OOM, 검은 프레임 및 깜빡임 솔루션
4ComfyUI Memory Optimization Guide
5New ComfyUI Optimizations for NVIDIA GPUs
7EasyCache - ComfyUI Built-in Node Documentation
8Qwen Image ControlNet & LoRA, EasyCache and Context Window in ComfyUI
9LazyCache - ComfyUI Built-in Node Documentation
11Nodes 2.0 Performance and usability issues
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.