ComfyUI에서 다른 사람이 만든 워크플로우를 불러왔는데 노드가 빨갛게 변하거나 Some Nodes Are Missing 메시지가 뜨는 경우가 있다. 그대로 따라 했는데 실행되지 않으니 처음에는 사용법을 잘못 익힌 것처럼 느껴진다.
하지만 이 오류에서는 프롬프트나 KSampler 설정을 만지기 전에 확인할 것이 따로 있다. 현재 PC의 ComfyUI 환경과 워크플로우를 만든 사람의 환경이 같은가부터 봐야 한다.
사람이 문제다에서 가장 먼저 볼 변화
ComfyUI Missing Nodes는 설정값 문제가 아니다
ComfyUI 워크플로우에는 어떤 노드를 사용했고 어떻게 연결했는지가 기록된다. 문제는 다른 사람이 사용한 모든 커스텀 노드의 실행 코드까지 워크플로우 파일 안에 들어가는 것은 아니라는 점이다.
그래서 워크플로우 제작자의 PC에는 존재하는 노드가 내 ComfyUI에는 없다면 해당 노드를 정상적으로 불러올 수 없다. 이때 흔히 보게 되는 것이 Missing Nodes와 빨간 노드다.
가장 먼저 볼 것은 누락된 노드 이름이다
오류가 나타나면 CFG나 Steps부터 바꾸지 말고 누락됐다고 표시되는 노드 타입을 확인하는 편이 빠르다.
대체로 다음 상황을 먼저 구분하면 된다.
커스텀 노드 패키지 자체가 설치되지 않은 경우
패키지는 있지만 필요한 노드가 없는 버전인 경우
업데이트 과정에서 노드 이름이나 구조가 바뀐 경우
ComfyUI 본체와 커스텀 노드의 버전 조합이 맞지 않는 경우
사람이 문제다가 ComfyUI 워크플로우에 미치는 영향
즉 같은 JSON 파일을 불러왔다고 해서 같은 실행 환경이 만들어지는 것은 아니다.
기존 방식과 비교해야 할 부분
다른 PC에서는 잘 돌아간다는 말만 믿고 내 프롬프트를 계속 수정하면 문제와 관계없는 부분만 바꾸게 된다. 워크플로우를 전달받았다면 먼저 어떤 커스텀 노드와 버전을 전제로 만들어졌는지 확인해야 한다.
최신 ComfyUI에서도 Missing Nodes 오류가 날 수 있다
여기서 더 헷갈리는 상황이 있다. ComfyUI를 최신 버전으로 업데이트했는데도 워크플로우가 계속 특정 노드를 찾지 못하는 경우다.
실제로 ComfyUI 관련 이슈에서도 현재 설치 버전이 요구 버전보다 높은데 Some nodes require a newer version of ComfyUI 메시지가 표시되는 사례가 보고된 적이 있다. 따라서 화면의 업데이트 안내만 보고 무조건 본체가 오래됐다고 단정해서는 안 된다.
ComfyUI 본체와 커스텀 노드는 따로 확인한다
ComfyUI는 본체 하나만으로 구성된 프로그램처럼 생각하기 쉽지만 실제 워크플로우에서는 여러 커스텀 노드와 Python 의존성이 함께 움직인다.
본체만 업데이트하고 특정 커스텀 노드는 예전 버전으로 남아 있거나, 반대로 커스텀 노드가 새로운 구조를 요구하는데 본체 쪽 구성이 맞지 않으면 같은 워크플로우라도 문제가 생길 수 있다.
성능과 결과 품질에서 확인할 차이
따라서 업데이트 여부를 확인할 때는 단순히 'ComfyUI 최신 버전인가'가 아니라 본체와 해당 노드 패키지가 서로 맞는 상태인가를 봐야 한다.
워크플로우 구성에서 놓치기 쉬운 부분
여기서 모든 커스텀 노드를 한꺼번에 업데이트하는 방식은 주의할 필요가 있다. 기존에 정상 작동하던 다른 워크플로우까지 영향을 받을 수 있기 때문이다.
Missing Nodes 해결 뒤에는 모델 호환성을 확인한다
Missing Nodes를 해결했다고 작업이 끝나는 것도 아니다. 빨간 노드가 사라졌는데 Queue Prompt 이후 tensor shape 오류나 모델 로딩 오류가 발생한다면 이번에는 모델 계열을 확인해야 한다.
예를 들어 서로 다른 아키텍처를 전제로 하는 모델 구성요소를 섞으면 tensor dimension이나 channel mismatch가 발생할 수 있다. ControlNet 역시 기본 checkpoint의 계열에 맞는 모델을 사용하는 것이 중요하다.
models 폴더에 파일이 있다는 것과 호환되는 것은 다르다
models 폴더에 필요한 safetensors 파일이 존재한다고 해서 워크플로우가 반드시 정상 작동하는 것은 아니다.
체크포인트, VAE, Text Encoder, ControlNet처럼 연결되는 구성요소가 해당 모델 구조에 맞아야 한다. 따라서 모델 관련 오류가 나오면 파일을 다시 다운로드하기 전에 먼저 어떤 모델 계열을 위한 워크플로우인지 확인하는 것이 효율적이다.
실제로 적용할 때 체크할 점
특히 여러 모델을 테스트하는 ComfyUI 환경에서는 파일 이름에도 모델 계열과 버전을 구분해 두는 것이 좋다. 이름이 비슷한 모델을 잘못 선택하는 실수를 줄일 수 있기 때문이다.
다른 사람의 ComfyUI 워크플로우는 환경까지 맞춰야 한다
ComfyUI에서 '저 사람은 되는데 나는 안 된다'는 상황이 생기는 이유는 결과 이미지나 JSON만 공유되고 실행 환경 정보는 빠지는 경우가 많기 때문이다.
워크플로우를 재현하려면 최소한 커스텀 노드, 모델 파일, 주요 버전 정보를 함께 보는 편이 안전하다. 특히 새로운 영상 모델이나 최근 추가된 노드가 포함된 워크플로우일수록 버전 차이에 민감할 수 있다.
문제가 생겼다면 처음부터 전체 환경을 갈아엎기보다 오류 지점을 기준으로 범위를 줄인다. Missing Nodes라면 노드 패키지부터, 모델 로딩 오류라면 경로와 파일명부터, tensor shape 오류라면 모델 아키텍처 조합부터 확인하는 방식이다.
ComfyUI 워크플로우 오류의 마지막 확인 순서
ComfyUI 워크플로우가 작동하지 않을 때 곧바로 내 설정이 틀렸다고 판단할 필요는 없다. 먼저 누락된 노드 이름을 확인하고, 해당 커스텀 노드의 설치·버전 상태와 ComfyUI 본체의 조합을 점검한다.
노드가 정상적으로 로드된 뒤 오류가 발생한다면 그다음에 모델 계열과 경로를 확인하면 된다. 사람이 만든 설정을 의심하기 전에 환경 차이부터 지우는 것, 이것이 다른 사람의 ComfyUI 워크플로우를 가장 빠르게 재현하는 순서다.