ComfyUI 워크플로 재사용 완전 가이드: 가져오기부터 재현까지의 점검표

다른 사람의 ComfyUI 워크플로를 가져온 뒤 화면이 빨간 노드로 가득 차고 모델 목록도 비어 있을 수 있습니다. 처음 이 상황을 겪었을 때 저는 문제를 이해하는 데 30분쯤 걸렸습니다. 원인은 세 가지였습니다. 노드가 없거나, 모델 경로가 맞지 않거나, Python 의존성이 설치되지 않은 것입니다. 이 글은 ComfyUI 설치법을 설명하지 않습니다. 질문은 하나입니다. workflow JSON이나 PNG를 받았을 때 무엇을 보완하고, 어떤 순서로 디버깅하며, 어떻게 예시 이미지에 가까운 결과를 재현할 것인가입니다. 핵심은 가져오기부터 아카이브까지 반복해서 쓸 수 있는 점검표입니다.

다른 사람의 Workflow가 왜 실행되지 않을까요?

ComfyUI의 workflow는 본질적으로 노드 연결 그래프입니다. JSON이나 PNG metadata는 노드 유형, 파라미터 값, 연결 관계를 기록하지만 모델 파일, custom nodes 플러그인, Python 의존성을 포함하지 않습니다. 그래서 공유된 workflow를 가져오면 로컬 환경에 없는 것이 바로 드러납니다.

빨간 노드는 ComfyUI가 해당 노드 유형을 찾지 못했다는 뜻입니다. 일부는 내장 노드인 core node라 보통 빠지지 않습니다. 다른 일부는 타사 확장인 custom node라 로컬에 설치되어 있지 않을 수 있습니다. 노드를 보완한 뒤에도 Load Checkpoint나 Load LoRA 드롭다운이 비어 있을 수 있습니다. 모델 파일이 기본 디렉터리에 없거나 경로 설정이 틀린 것입니다. 이것까지 해결해도 어떤 custom node는 insightface, onnxruntime 같은 Python 패키지가 없다고 오류를 낼 수 있습니다.

이 세 가지 문제는 서로 겹칩니다. 하나의 workflow가 custom node 세 개, checkpoint 모델 두 개, Python 패키지 하나를 동시에 요구할 수 있습니다. 체계적인 점검 순서가 없으면 한 단계에서 막히고 관계없는 패키지를 잔뜩 설치하기 쉽습니다. 아래 점검표는 이 문제를 분리해 우선순위대로 처리합니다.

Workflow의 두 가지 출처: JSON vs PNG Metadata

다른 사람이 workflow를 공유할 때는 보통 두 가지 형태를 씁니다. 독립 JSON 파일이거나 metadata가 들어 있는 PNG 이미지입니다. JSON은 ComfyUI가 내보내는 기본 형식이며 노드 정보를 온전히 기록합니다. PNG metadata는 임베딩 방식입니다. 일부 생성 이미지는 파일 안에 workflow 데이터를 포함하지만, 만든 사람이 그 metadata를 보존했을 때만 가능합니다.

JSON 파일 드래그하기

JSON 파일을 받았다면 ComfyUI 인터페이스에 그대로 끌어다 놓습니다. 인터페이스가 노드 그래프를 자동으로 불러오고 모든 연결 관계를 표시합니다. 가장 신뢰할 수 있는 방식입니다. JSON은 이미지 압축의 영향을 받지 않고 노드 정보를 그대로 보존합니다.

그 JSON이 ComfyUI에서 내보낸 파일이라면 가져온 뒤의 노드 배치는 작성자의 화면과 같아야 합니다. 배치가 흐트러져 있다면 내보낸 시점의 ComfyUI 버전이 다르거나 JSON이 수동으로 편집되었을 수 있습니다.

PNG Metadata를 불러오기 위한 조건

일부 AI 생성 PNG 이미지는 workflow metadata를 포함합니다. 이미지를 ComfyUI 인터페이스에 끌어다 놓거나 메뉴에서 “Load”를 선택한 뒤 PNG 파일을 고르면 됩니다.

조건은 간단합니다. 이미지가 metadata를 보존하고 있어야 합니다. 많은 소셜 플랫폼과 이미지 호스팅 서비스는 업로드할 때 이미지를 압축하거나 metadata를 제거합니다. 그러면 workflow 데이터가 사라집니다. 소셜 게시물에서 받은 이미지라면 metadata가 이미 삭제되었을 가능성이 높고, 끌어다 놓아도 빈 캔버스만 나올 수 있습니다.

가능하면 JSON 파일을 우선 사용합니다. PNG metadata는 작성자가 자신의 생성 기록을 저장할 때는 유용하지만, 플랫폼을 넘나드는 공유 형식으로는 안정적이지 않습니다.

JSON vs PNG Metadata 비교

workflow를 받으면 먼저 출처를 확인합니다. 노드 목록, 모델 목록, README가 함께 있으면 JSON이나 PNG만 받는 것보다 훨씬 안전합니다.

빨간 노드가 보일 때: Core Node와 Custom Node 구분하기

workflow를 가져온 뒤 빨간 노드가 나타나고 제목에 “Missing” 또는 “Unknown node type”이 보일 수 있습니다. 이때 바로 패키지를 설치하지 말고 노드 유형부터 구분합니다. 그래야 어디서 찾아야 할지 결정할 수 있습니다.

Core Node와 Custom Node의 차이

Core node는 ComfyUI 내장 노드입니다. 메인 프로그램 설치와 함께 들어오므로 보통 누락되지 않습니다. 흔한 예는 Load Checkpoint, KSampler, VAE Decode, Save Image입니다. 이런 노드가 빨갛게 보인다면 ComfyUI 설치가 불완전하거나 버전 문제가 있을 수 있습니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

Custom node는 별도로 설치해야 하는 타사 확장 노드입니다. 흔한 예는 IP-Adapter Apply, ControlNet Apply, FaceDetailer입니다. 빨간 노드의 대부분은 custom node 누락에서 옵니다.

판단 방법은 노드 이름을 보는 것입니다. 이름에 IPAdapter, ControlNet, Impact처럼 알려진 확장 접두어가 들어 있으면 거의 custom node입니다. 확실하지 않다면 ComfyUI 인터페이스에서 우클릭한 뒤 “Add Node”에서 노드 이름을 검색합니다. Core node는 기본 목록에 있고, 설치되지 않은 custom node는 없습니다.

Custom Node를 찾는 방법

custom node라고 확인했다면 세 가지 경로로 찾습니다.

ComfyUI Registry: 프로젝트에서 권장하는 노드 등록 플랫폼입니다. registry.comfy.org에 접속해 노드 이름이나 확장 패키지 이름을 검색합니다. Registry는 보통 출처, 설치 방법, 의존성 요구사항을 표시합니다. 일부 노드는 ComfyUI 버전에 따라 원클릭 설치를 지원합니다.

ComfyUI Manager: 커뮤니티에서 유지하는 타사 확장 관리 도구입니다. 로컬에 Manager를 설치했다면 ComfyUI 메뉴에서 “Manager” -> “Install Custom Nodes”로 들어가 노드 이름을 검색합니다. Manager는 일치하는 확장 패키지와 설치 상태를 보여 줍니다. Manager는 ComfyUI core 기능이 아니며 안정성은 커뮤니티 유지보수에 따라 달라집니다.

GitHub 검색: Registry와 Manager에서 찾지 못했다면 GitHub에서 노드 이름을 검색합니다. 많은 custom node 작성자가 README에 노드 이름을 적어 둡니다. 저장소를 찾으면 README의 설치 절차에 따라 custom_nodes 디렉터리에 클론합니다.

Python 의존성 문제

일부 custom node는 추가 Python 패키지를 요구합니다. 예를 들어 IP-Adapter는 insightface가 필요할 수 있고, 일부 ControlNet 확장은 onnxruntime이 필요할 수 있습니다.

설치 방법은 custom node 저장소 디렉터리로 들어가 README나 requirements.txt를 확인하는 것입니다. ComfyUI 루트에서 다음 명령을 실행합니다.

pip install -r custom_nodes/node-directory/requirements.txt

어떤 README는 pip install 패키지명을 직접 적어 둡니다. 해당 프로젝트의 안내를 따르면 됩니다.

실제로 어떤 노드가 빠졌는지 먼저 확인하기

하나의 workflow가 여러 custom nodes를 참조할 수 있지만, 실제로 설치해야 하는 것은 가져온 뒤 빨갛게 표시된 몇 개일 수 있습니다. 빨간 노드 목록이 실제 누락 목록입니다. 인기 노드 패키지를 전부 설치하지 마세요. 패키지가 늘어날수록 시작 시간이 길어지고 충돌 위험도 커집니다.

모델을 찾지 못할 때: 디렉터리와 외부 모델 라이브러리 확인

노드를 보완한 뒤에도 Load Checkpoint, Load LoRA, Load VAE 같은 노드의 드롭다운이 비어 있을 수 있습니다. workflow가 참조하는 모델 파일은 JSON과 함께 공유되지 않습니다. 직접 ComfyUI의 models 디렉터리에 넣어야 합니다.

ComfyUI models 디렉터리 구조

ComfyUI는 시작할 때 models 아래의 하위 폴더를 스캔하고 유형별로 모델을 로드합니다. 흔한 하위 폴더는 다음과 같습니다.

workflow의 Load Checkpoint 노드가 sdxl_base.safetensors를 지정한다면 이 파일을 models/checkpoints/sdxl_base.safetensors에 넣어야 합니다. 노드 드롭다운은 해당 디렉터리의 모델을 자동으로 표시합니다.

extra_model_paths.yaml의 용도

모델 라이브러리가 다른 위치에 있다면, 예를 들어 공유 NAS나 통합 모델 폴더에 있다면 매번 models로 복사할 필요가 없습니다. extra_model_paths.yaml로 외부 경로를 지정할 수 있습니다.

설정 파일은 ComfyUI 루트에 있으며 YAML 형식입니다. 예시는 다음과 같습니다.

my_custom_config:
  base_path: /path/to/external
  checkpoints: models/checkpoints
  loras: models/loras
  vae: models/vae
  controlnet: models/controlnet

ComfyUI는 시작할 때 설정된 경로를 스캔하고 기본 models 디렉터리와 합쳐 보여 줍니다. 설정 형식은 버전에 따라 달라질 수 있으므로 공식 문서나 시작 로그를 확인하세요.

모델 버전 확인

workflow 안의 모델명이 sdxl_base처럼 짧게만 적혀 있을 수 있습니다. 하지만 실제로는 공식 버전, 커뮤니티 fine-tune, fp16 버전, pruned 버전처럼 여러 변형이 있을 수 있습니다. 다른 버전은 출력 차이를 크게 만들 수 있습니다.

workflow를 받으면 먼저 작성자에게 모델의 출처와 버전을 물어봅니다. 설명이 없다면 Civitai나 Hugging Face 같은 모델 라이브러리에서 이름을 검색하고 공개 버전 표시가 있는지 확인합니다. 같은 이름의 아무 파일이나 받지 말고 작성자가 표시한 버전을 우선합니다.

이 글은 구체적인 다운로드 링크를 제공하지 않습니다. 모델 라이선스는 복잡합니다. 이름과 출처는 기록하되, 사용 권한은 직접 확인하는 편이 안전합니다.

왜 결과가 예시 이미지와 다를까요?

노드와 모델을 모두 보완했고 workflow도 실행되지만 생성 결과가 예시 이미지와 크게 다를 수 있습니다. 이것이 항상 조작 실수라는 뜻은 아닙니다. 파라미터 차이, 모델 버전 차이, 실행 backend 차이가 원인일 수 있습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

파라미터 영향도 표

아래 표는 흔한 파라미터가 결과에 미치는 영향을 정리한 것입니다. 영향도가 높은 항목은 엄격히 맞춰야 하고, 낮은 항목은 어느 정도 조정할 수 있습니다.

모델 버전이 가장 큰 변수입니다

같은 이름의 모델을 받았더라도 버전이 맞지 않으면 결과가 완전히 빗나갈 수 있습니다. 예를 들어 sdxl_base는 공식 원본일 수도 있고, 커뮤니티 fp16 변형일 수도 있으며, 애니메이션 fine-tune일 수도 있습니다. 작성자는 원본을 썼는데 사용자가 애니메이션 버전을 받았다면 그림체는 완전히 달라집니다.

workflow를 받으면 모델 출처와 버전을 가장 먼저 확인합니다. 작성자가 설명하지 않았다면 모델 페이지에서 버전 표기를 봅니다. 확실하지 않으면 추측하지 말고 작성자에게 묻는 편이 낫습니다.

목표는 완전 복제가 아니라 스타일과 구도에 가깝게 맞추는 것

이미지를 완전히 재현하려면 모델 버전, seed, 모든 파라미터, 실행 환경이 모두 일치해야 합니다. 특히 seed와 모델 버전이 빠져 있으면 이 조건을 맞추기 어렵습니다.

현실적인 목표는 예시 이미지의 스타일과 구도에 가까워지는 것입니다. 피사체, 색감, 구도 구조가 대체로 맞으면 재현은 성공한 편입니다. 얼굴 디테일이나 질감 같은 작은 차이는 받아들여야 합니다.

ComfyUI Workflow 재사용 점검표

아래 점검표는 가져오기부터 아카이브까지의 전체 과정을 다룹니다. 저장해 두고 다른 사람의 workflow를 재사용할 때마다 항목별로 확인하는 것을 권합니다.

단계 1: 출처 확인

workflow를 받으면 먼저 형식과 보조 정보를 확인합니다.

• JSON 파일인지 PNG 이미지인지 확인합니다. JSON을 우선 사용하고, PNG metadata는 플랫폼에서 삭제될 수 있음을 염두에 둡니다.
• 노드 목록, 모델 목록, README, 작성자 메모 같은 설명이 있는지 봅니다.
• PNG만 있다면 metadata 로드를 시도합니다. 실패하면 metadata가 사라진 것이므로 작성자에게 JSON을 요청하거나 포기합니다.
• 출처가 불명확하거나 커뮤니티 공유가 12개월 이상 된 경우 신뢰도가 낮으므로 조심해서 사용합니다.

단계 2: 노드 보완

workflow를 가져온 뒤 빨간 노드를 확인합니다.

• 모든 빨간 노드 이름을 적고 core node인지 custom node인지 확인합니다.
• Core node가 없다면 ComfyUI 설치가 완전한지, 버전이 너무 오래되지 않았는지 확인합니다.
• Custom node가 없다면:
  • ComfyUI Registry에서 노드 이름이나 확장 패키지 이름을 검색합니다.
  • Manager를 설치했다면 “Install Custom Nodes”에서 검색합니다.
  • 둘 다 못 찾으면 GitHub에서 노드 이름을 검색하고 README에 따라 설치합니다.
• custom node 설치 후 ComfyUI를 재시작합니다.
• 빨간 노드가 사라졌는지 확인합니다. 여전히 빨갛다면 Python 의존성이 빠졌을 수 있으므로 custom node 디렉터리의 requirements.txt를 보고 pip install -r requirements.txt를 실행합니다.

실제로 누락된 노드부터 설치합니다. 인기 패키지를 전부 설치하지 마세요.

단계 3: 모델 매핑

노드를 보완한 뒤 모델 노드를 확인합니다.

• workflow 안의 모든 모델 참조를 나열합니다. checkpoint, LoRA, VAE, ControlNet, IP-Adapter 등이 여기에 포함됩니다.
• 각 모델 유형을 확인해 models/ 아래 어느 하위 폴더에 넣어야 하는지 결정합니다.
• 로컬에 같은 이름의 모델이 있는지 확인합니다. 있다면 버전이 같은지 확인합니다.
• 없다면 Civitai나 Hugging Face 같은 모델 라이브러리에서 모델명을 검색하고 출처와 버전을 확인합니다.
• 다운로드 후 올바른 디렉터리에 넣거나 extra_model_paths.yaml로 외부 경로를 설정합니다.
• ComfyUI를 재시작하고 모델 노드 드롭다운에 해당 모델이 표시되는지 확인합니다.

모델 버전 불일치는 재현에 가장 큰 영향을 주므로 우선 확인합니다.

단계 4: 파라미터 고정

모델이 준비되면 workflow 파라미터를 확인합니다.

• seed가 고정되어 있는지 봅니다. 고정되지 않았다면 같은 이미지를 재현할 수 없고 스타일만 맞출 수 있습니다.
• sampler, steps, CFG Scale, 이미지 크기를 확인합니다.
• VAE가 로드되는지, LoRA 가중치가 어떻게 설정되어 있는지 봅니다.
• 예시 이미지와 파라미터를 대조해 뚜렷한 차이가 있는지 확인합니다.
• 작성자가 파라미터 조정 메모를 남겼다면 그대로 반영합니다.

작성자가 파라미터를 직접 미세 조정했을 수 있습니다. 예시 이미지와 JSON 파라미터가 완전히 일치하지 않으면 수동으로 맞춰야 합니다.

단계 5: 최소 테스트

파라미터 확인 후에는 먼저 단순 테스트를 합니다.

• “a cat sitting on a chair”처럼 간단한 prompt로 한 번 실행합니다.
• 출력이 정상인지 확인합니다. 오류가 없어야 하고, 빈 이미지나 심한 붕괴가 없어야 합니다.
• 오류가 있다면 터미널 로그를 확인해 문제 노드나 모델을 찾습니다.
• 출력이 정상이라면 prompt와 파라미터를 조금씩 조정해 예시 효과에 가까워집니다.
• 처음부터 복잡한 prompt를 쓰지 마세요. 복잡한 prompt는 노드나 모델 문제를 가릴 수 있습니다.

단계 6: 이름 짓기와 아카이브

재현에 성공하면 workflow를 저장하고 정리합니다.

• workflow를 새 JSON 파일로 저장합니다.
• 권장 이름 형식은 [주제]-[모델명]-[날짜]-v1.json입니다. 예: portrait-sdxl-base-20260623-v1.json.
• 모델 버전 정보를 기록합니다. JSON 주석에 의존하지 말고 함께 두는 README.txt를 우선 사용합니다.
• 기록할 내용은 checkpoint 이름과 버전, LoRA 이름과 가중치, VAE, sampler 파라미터입니다.
• 나중에 공유한다면 노드 목록, 모델 목록, 예시 이미지, 파라미터 설명을 함께 제공합니다. 모델 파일 자체는 공유하지 않습니다.

이 점검표를 로컬에 복사해 두고 workflow를 재사용할 때마다 하나씩 체크하면 됩니다.

Workflow 관리: 이름 규칙과 공유 제안

재현에 성공한 뒤 정리와 아카이브를 해 두면 다음에 처음부터 다시 조사하지 않아도 됩니다. 다른 사람에게 공유할 때도 충분한 정보를 제공하면 상대방의 디버깅 시간을 줄일 수 있습니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

이름 규칙

파일명이 뒤섞이면 workflow가 수십 개 쌓였을 때 원하는 파일을 찾기 어렵습니다.

권장 형식: [주제]-[모델명]-[날짜]-v1.json

예시:

• portrait-sdxl-base-20260623-v1.json: 인물 주제, SDXL Base 모델, 2026년 6월 23일, 버전 1
• landscape-sd15-controlnet-20260620-v1.json: 풍경 주제, SD1.5 + ControlNet

주제는 용도를 쓰면 됩니다. portrait, landscape, anime, product, concept-art처럼요. 모델명은 주 checkpoint의 짧은 이름을 씁니다. 날짜는 YYYYMMDD 형식을 사용합니다. v1, v2는 반복 버전을 구분합니다.

모델 버전 기록 방법

workflow JSON 자체는 모델 파일의 실제 버전 번호를 기록하지 않습니다. 모델명을 기록할 뿐입니다. 모델 라이브러리에 같은 이름의 버전이 여러 개 있다면 다음에 열었을 때 어떤 버전을 썼는지 모를 수 있습니다.

두 가지 방법이 있습니다.

방법 1: 함께 두는 README.txt

workflow와 같은 디렉터리에 README-[파일명].txt를 만들고 다음을 기록합니다.

• checkpoint 이름과 출처 링크 (직접 다운로드 링크가 아니라 모델 라이브러리 페이지 URL)
• LoRA 이름, 가중치, 출처
• VAE 이름과 출처
• sampler, steps, CFG, 이미지 크기
• 기타 핵심 파라미터

모델 버전 기록의 주 출처는 README.txt로 두는 편이 좋습니다. 호환성이 좋고 JSON, 예시 이미지와 함께 공유하기도 쉽습니다.

Workflow 공유 제안

workflow를 공유할 때는 정보가 충분할수록 받는 사람이 빨리 시작할 수 있습니다.

필수 내용:

• JSON 파일: 완전한 workflow 파일이며 가장 중요합니다.
• 노드 목록: 모든 custom nodes 이름과 출처를 적습니다. Registry 링크나 GitHub 저장소가 좋습니다.
• 모델 목록: checkpoint, LoRA, VAE, ControlNet 등 모델 이름과 출처 제안을 적되 직접 다운로드 링크는 제공하지 않습니다.
• 예시 이미지: 생성 결과 한 장을 붙여 재현 목표를 확인하게 합니다.
• 파라미터 설명: JSON 파라미터와 예시 이미지가 다르다면 실제 사용한 파라미터를 표시합니다.

제공하지 않을 내용:

• 모델 파일 자체: 라이선스가 복잡하므로 모델 파일은 공유하지 않습니다.
• 직접 다운로드 링크: 모델 라이브러리 페이지 URL은 괜찮지만 직접 다운로드 링크는 위험이 큽니다.
• Python 패키지 설치 명령: custom node에 특수 의존성이 있다면 패키지명만 적고, 구체적인 명령은 받는 사람이 README를 보게 합니다.

짧은 README에 위 정보를 적어 함께 보내세요. 받는 사람은 점검표를 따라 항목별로 확인할 수 있고 훨씬 빠르게 실행까지 갈 수 있습니다.

다음 읽을거리

아직 ComfyUI를 설치하지 않았다면 먼저 ComfyUI 입문 완전 가이드에서 설치, 모델 디렉터리, 첫 이미지 생성을 확인하세요. prompt 최적화는 Prompt Engineering 비즈니스 실전을 참고하면 좋습니다. 여러 매체를 넘나드는 AI 창작 흐름은 매체를 넘나드는 창작에서 볼 수 있습니다. 로컬에서 대규모 언어 모델을 실행하려면 Ollama 입문으로 이어가면 됩니다.