ComfyUI 워크플로우를 보다 보면 Load Checkpoint에서 이미 VAE가 출력되는데도 별도의 Load VAE 노드를 연결한 구성을 자주 볼 수 있다. 그래서 처음에는 “체크포인트에 VAE가 있는데 왜 또 불러오는가?”라는 의문이 생긴다.
핵심부터 말하면 VAE는 이미지를 만드는 메인 확산 모델이 아니다. 이미지와 latent 사이를 변환하는 인코더·디코더에 가깝다. 따라서 같은 프롬프트와 같은 seed를 사용하더라도 마지막에 어떤 VAE로 디코딩하느냐에 따라 색감이나 세부 표현이 달라져 보일 수 있다.
vae에서 가장 먼저 볼 변화
ComfyUI에서 VAE가 하는 일
Stable Diffusion 계열 워크플로우는 모든 계산을 실제 RGB 이미지 위에서 진행하지 않는다. KSampler가 주로 다루는 것은 압축된 latent 표현이다.
생성 과정만 단순화하면 다음과 같다.
latent → KSampler → latent → VAE Decode → image
즉 KSampler가 샘플링을 끝냈다고 해서 바로 PNG 이미지가 만들어지는 것은 아니다. 마지막 latent 데이터를 사람이 볼 수 있는 픽셀 이미지로 변환하는 과정이 필요하며, 이를 담당하는 대표 노드가 VAE Decode다.
VAE Encode는 이미지 입력에서 반대로 동작한다
img2img처럼 기존 이미지를 워크플로우에 넣는 경우에는 반대 과정도 필요하다.
image → VAE Encode → latent
따라서 VAE는 단순히 결과 이미지를 저장하기 직전에 사용하는 부가 기능이 아니다. 픽셀 공간과 latent 공간 사이의 경계에서 계속 사용되는 구성 요소다.
vae가 ComfyUI 워크플로우에 미치는 영향
이 구조를 이해하면 VAE를 바꿨을 때 왜 결과가 달라지는지도 이해하기 쉬워진다. 확산 모델이 만든 latent 자체가 같아도 그것을 픽셀로 해석하는 디코더가 달라지면 최종 출력 역시 완전히 동일하다고 볼 수 없다.
기존 방식과 비교해야 할 부분
CheckpointLoaderSimple의 내장 VAE를 먼저 쓰는 이유
ComfyUI의 CheckpointLoaderSimple은 일반적으로 MODEL, CLIP, VAE를 각각 출력한다. 그래서 기본적인 text-to-image 워크플로우라면 체크포인트에서 나온 VAE를 그대로 VAE Decode에 연결해 사용할 수 있다.
별도의 VAE 파일이 반드시 필요한 것은 아니다. 모델 제작자가 체크포인트에 적절한 VAE를 포함했고 별도의 사용 지침도 없다면 우선 내장 VAE를 사용하는 편이 가장 단순하다.
외부 VAELoader가 필요한 경우
반대로 모델 제작자가 특정 VAE를 권장하는 경우에는 별도로 불러올 이유가 생긴다. ComfyUI에는 이를 위한 VAELoader가 있으며 기본적으로 ComfyUI/models/vae에 있는 VAE 모델을 선택해 불러올 수 있다.
실제 워크플로우에서는 다음처럼 연결한다.
Load VAE → VAE Decode
이렇게 하면 체크포인트가 출력한 VAE 대신 사용자가 지정한 VAE로 최종 latent를 디코딩할 수 있다.
성능과 결과 품질에서 확인할 차이
여기서 중요한 점은 “외부 VAE가 항상 더 좋다”가 아니라는 것이다. 특정 체크포인트와 함께 사용하도록 권장된 VAE이거나, 현재 출력에서 VAE와 관련된 문제가 의심될 때 교체하는 것이 합리적이다.
워크플로우 구성에서 놓치기 쉬운 부분
VAE를 바꾸면 최종 이미지에서 무엇이 달라지나
VAE는 이미지 구조를 처음부터 결정하는 diffusion model과 역할이 다르다. 따라서 VAE를 교체했다고 해서 프롬프트 이해 능력이 갑자기 향상되거나 인물의 포즈가 근본적으로 바뀌는 식으로 이해하면 곤란하다.
체감하기 쉬운 차이는 주로 최종 복원 단계에서 나타난다. 색의 표현, 명암, 미세한 디테일, 픽셀 공간으로 복원되는 방식이 달라지면서 같은 latent도 조금 다른 이미지로 보일 수 있다.
특히 특정 모델에서 결과가 지나치게 탁하거나 이상한 색으로 보인다면 프롬프트와 sampler만 계속 수정하기 전에 모델 제작자가 권장한 VAE가 따로 있는지 확인해볼 가치가 있다.
다만 VAE는 만능 품질 향상 옵션이 아니다. 구도 실패, 손가락 형태, 프롬프트 반영 실패처럼 diffusion 단계에서 발생한 문제를 VAE 교체만으로 해결하기는 어렵다.
VAE 호환성을 확인해야 하는 이유
VAE를 독립 파일로 불러올 수 있다고 해서 서로 다른 모델 계열의 VAE를 자유롭게 혼합할 수 있다는 뜻은 아니다.
ComfyUI 공식 문제 해결 문서에서도 모델 아키텍처가 맞지 않으면 VAE Decode 단계에서 latent 채널 수가 맞지 않는 오류가 발생할 수 있다고 안내한다. 예를 들어 서로 다른 아키텍처의 latent 표현은 동일한 형태라고 가정할 수 없다.
실제로 적용할 때 체크할 점
외부 VAE 사용 전 확인할 세 가지
외부 VAE를 사용한다면 최소한 다음 순서로 확인하는 것이 좋다.
현재 체크포인트가 어떤 모델 계열인지 확인한다.
모델 제작자가 별도 VAE 사용을 권장했는지 확인한다.
해당 VAE가 현재 모델 아키텍처와 호환되는지 확인한다.
새 모델을 처음 테스트할 때는 복잡한 커스텀 워크플로우보다 공식 예제나 모델 제작자가 제공한 기본 워크플로우에서 시작하는 편이 문제 원인을 찾기 쉽다.
VAE 교체가 필요한지 판단하는 기준
기본값은 간단하다. 체크포인트가 정상적인 VAE를 제공한다면 그 출력을 먼저 사용한다.
별도 VAE를 고려할 시점은 모델 배포 페이지에서 특정 VAE가 명시되어 있거나, 워크플로우 원본이 별도의 VAE를 요구하거나, VAE Decode 단계에서 호환성 또는 출력 문제가 의심되는 경우다.
ComfyUI에서 VAE가 헷갈린다면 먼저 Load Checkpoint → VAE Decode 연결을 확인해보자. 그다음 모델 제작자가 별도 VAE를 지정했을 때만 VAELoader로 교체하면 된다. VAE를 무조건 추가하는 것보다 현재 모델과 맞는 VAE를 사용하는 것이 더 중요하다.