ComfyUI 업데이트 뒤 안 켜질 때 — 되돌리기와 커스텀 노드 가르기

업데이트 한 번에 바뀌는 세 층

공식 문서는 ComfyUI 업데이트를 두 부분으로 나눈다. 하나는 새 노드 · 새 모델 지원이 들어가는 본체 코드이고, 다른 하나는 화면(프런트엔드) · 워크플로 템플릿 · 노드 도움말 같은 «코어 의존 패키지»다. 코어 의존 패키지는 본체와 다른 저장소에서 따로 만들어져 pip 패키지로 설치된다. 본체 저장소의 requirements.txt는 그 가운데 comfyui-frontend-package · comfyui-workflow-templates · comfyui-embedded-docs 세 줄을 «==»로 판을 못 박아 두었다. 본체 코드가 바뀌면 그 코드가 기대하는 화면 패키지의 판도 함께 바뀐다는 뜻이다.

여기에 업데이트가 건드리지 않는 세 번째 층이 있다. custom_nodes 폴더에 직접 넣은 커스텀 노드다. 공식 문서는 커스텀 노드 문제의 흔한 원인으로 «업데이트 때 바뀐 프런트엔드에 커스텀 노드가 아직 맞추지 못한 경우»와 «작성자가 맞춘 판을 냈는데도 사용자가 ComfyUI만 올리고 커스텀 노드는 올리지 않은 경우»를 함께 적었다.

릴리스 주기도 알아 둘 만하다. README는 ComfyUI가 월요일을 목표로 한 주간 릴리스 주기를 따르되 자주 바뀐다고 적었고, 새 안정판은 대략 2주마다 낸다고 했다. 같은 문단에서 «안정판 태그 밖의 커밋은 매우 불안정할 수 있고 커스텀 노드를 여럿 깨뜨릴 수 있다»고 경고한다. 2026년 10월 13일에 릴리스 목록을 열었을 때 가장 새 판은 v0.39.0(2026-10-05 UTC)이었고, 그 앞 판은 v0.38.0(2026-09-29 UTC)이었다.

포터블 배치 파일 속 — update.py의 다섯 단계

포터블의 update 폴더에 있는 배치 파일 두 개는 같은 update.py를 부른다. 다른 점은 update_comfyui_stable.bat만 --stable을 붙인다는 것 하나다. update.py를 줄 단위로 따라가면 순서는 이렇다.

1. ComfyUI 폴더 안에서 손댄 파일이 있으면 git stash로 치워 둔다.
2. 지금 자리에 backup_branch_날짜_시_분_초 이름의 브랜치를 만든다.
3. master 브랜치로 옮겨 원격 저장소의 새 커밋을 받는다.
4. --stable이 붙어 있으면 저장소의 v로 시작하는 태그 가운데 판 번호가 가장 높은 것으로 checkout한다.
5. requirements.txt가 지난번에 설치한 것과 다르면 포터블 파이썬으로 pip install -r requirements.txt를 실행한다.

이 다섯 단계에서 문제 해결에 쓸 사실이 두 가지 나온다. 첫째, 2번의 백업 브랜치다. 업데이트 직전의 정확한 자리가 저장소 안에 이름표를 달고 남아 있으므로, 바로 전 상태로 돌아갈 길이 이미 마련돼 있다. 둘째, 5번의 처리 방식이다. pip install이 실패하면 update.py는 예외를 받아 아무것도 하지 않고 넘어간다. 대신 설치가 성공했을 때만 current_requirements.txt를 새 파일로 갈아 두므로, 다음 실행에서 다시 설치를 시도한다. 결과적으로 네트워크가 끊겼거나 권한이 막혔던 날에는 «코드는 새 판, 화면 패키지는 옛 판»인 채로 업데이트가 «Done!»으로 끝날 수 있다.

update.py 자신이 바뀐 판이 올라오면 5번 전에 update_new.py를 남기고 끝나고, 배치 파일이 그 파일을 update.py로 바꿔 놓은 뒤 한 번 더 실행한다. 업데이트 창에 «Running updater again since it got updated.»가 보이면 이 경우다.

명령 창이 말해 주는 세 갈래

켜지지 않을 때 가장 먼저 볼 곳은 브라우저가 아니라 명령 창이다. 포터블은 run_nvidia_gpu.bat 등을 두 번 눌러 뜨는 창, 수동 설치는 python main.py를 실행한 터미널, 데스크톱은 설치본 Manage 패널의 Terminal 탭이 시작 로그를 보는 자리다. 창이 바로 닫혀 버린다면 포터블 폴더에서 터미널을 열고 실행 배치 파일을 직접 입력해 실행하면 창이 남는다.

시작 코드에서 업데이트와 관계된 출력 문구를 모으면 세 갈래로 나뉜다.

A — 코어 패키지가 코드와 어긋났을 때

app/frontend_management.py는 화면 패키지를 불러오지 못하면 «comfyui-frontend-package is not installed.»를 별표 줄 사이에 출력하고 프로그램을 끝낸다. 업데이트 뒤 «켜지지 않는다»의 가장 직접적인 경우다. 패키지가 있기는 한데 판이 낮으면 멈추지는 않고, 시작할 때 «Installed comfyui-frontend-package version … is lower than the recommended version ….» 같은 경고를 WARNING 줄로 둘러 출력한다. 이 경우 ComfyUI는 켜지지만 화면은 옛 판이라 새 노드 칸이 비거나 화면 일부가 이상하게 보인다. 공식 문서도 git pull만 하고 패키지를 올리지 않으면 프런트엔드 기능이 빠지거나 이상해지고 새 템플릿이 보이지 않는다고 적었다.

본체에 함께 들어 있는 노드(comfy_extras)를 불러오다 실패한 경우에는 «IMPORT FAILED: 파일 이름» 줄 아래에 «This issue might be caused by new missing dependencies added the last time you updated ComfyUI.»라는 문장이 붙는다. 코드 스스로 «지난 업데이트에서 새로 추가된 의존성이 빠졌을 수 있다»고 알려 주는 셈이다.

B — 커스텀 노드가 걸렸을 때

커스텀 노드는 시작 과정에서 두 번 실행될 기회가 있다. 서버가 뜨기 전에 각 노드 폴더의 prestartup_script.py를 먼저 실행하고, 그 뒤에 노드 본체를 불러온다. 앞쪽이 실패하면 «Failed to execute startup-script»와 «(PRESTARTUP FAILED)», 뒤쪽이 실패하면 «Import times for custom nodes:» 목록에서 그 폴더 줄에 «(IMPORT FAILED)»가 붙는다.

코드에서 이 두 실패는 경고로만 남고 시작은 이어진다. 그러니 IMPORT FAILED 줄이 몇 개 있어도 화면이 열린다면 그 노드만 빠진 채 돌아가는 상태다. 문제는 커스텀 노드가 공유하는 파이썬 환경을 바꿔 버리는 경우다. 공식 문서는 일반 커스텀 노드의 문제로 «시작 중 멈춤 · 켜지지 않음»을 들고, 원인으로 노드마다 torch 같은 패키지의 판을 엄격하게 못 박아 서로 부딪히는 경우를 예로 들었다. 화면은 열리는데 빈 화면이거나 노드 연결이 안 되는 쪽은 커스텀 노드의 프런트엔드 확장이 바뀐 화면과 맞지 않는 경우가 가장 많다고 문서는 설명한다.

C — 되돌린 뒤 · 다른 프로그램과 겹쳤을 때

main.py에는 업데이트 자체보다 «되돌린 뒤»에 만나기 쉬운 멈춤이 하나 있다. 자산 시스템이 켜져 있으면 시작할 때 자산 데이터베이스를 여는데, 실패하면 «ASSETS_STARTUP_FAILED: 종류»를 출력하고 끝낸다. 종류가 newer_revision이면 «이 데이터베이스는 더 새 판의 ComfyUI가 마지막으로 썼다»는 뜻이고, 코드가 내놓는 해결은 «ComfyUI를 업데이트하거나, 그 파일을 옆으로 옮기고 다시 시작해 새 데이터베이스를 만들라»는 것이다. in_use · locked는 다른 ComfyUI나 데이터베이스 보기 프로그램이 그 파일을 열고 있다는 뜻이다. 어느 경우든 안내 문구 끝에는 «--disable-assets로 자산 시스템 없이 켜라»는 줄이 붙는다. 포터블 실행에 쓰이는 --windows-standalone-build 옵션은 설명에 «자산 시스템을 켠다»고 적혀 있다.

A 갈래 — 같은 파이썬으로 requirements.txt를 다시

A 갈래의 해법은 코드가 직접 적어 두었다. 패키지가 없거나 판이 낮을 때 utils/install_util.py가 만드는 안내 문구는 «지금 ComfyUI를 돌리는 파이썬 실행 파일 -m pip install -r requirements.txt 경로»를 그대로 찍어 주고, 포터블이라면 update\update_comfyui.bat를 실행하라고 덧붙인다. 파이썬을 -s 옵션으로 띄웠다면 명령에도 -s가 함께 붙는다. 이 줄을 복사해 그대로 실행하는 것이 가장 정확하다. 다른 파이썬으로 설치하면 ComfyUI가 쓰는 환경에는 아무것도 바뀌지 않기 때문이다.

설치 방식별로 정리하면 이렇다.

• 포터블: 안내 문구대로 update_comfyui.bat를 다시 돌리거나, 포터블 폴더에서 .\python_embeded\python.exe -s -m pip install -r ComfyUI\requirements.txt를 실행한다. update.py는 pip 실패를 멈춤으로 올리지 않으므로, 이번에는 창에 출력되는 pip 오류 줄을 끝까지 읽는다.
• 수동 설치: 가상 환경을 켠 상태에서 ComfyUI 폴더에서 pip install -r requirements.txt를 실행한다. 공식 문서는 가상 환경 밖에서 실행해 시스템 파이썬을 더럽히지 말라고 경고한다.
• 데스크톱: 설치본을 앱이 관리하므로 위 명령을 직접 치기보다 아래 «되돌리기»의 스냅샷 복원을 먼저 쓴다.

한꺼번에 설치가 실패하면 공식 문서는 requirements.txt에 적힌 판 번호 그대로 패키지를 하나씩 설치해 보라고 하면서, 독자적으로 최신 판으로 올리지 말라고 못 박았다. update 폴더의 세 번째 배치 파일 update_comfyui_and_python_dependencies.bat는 PyTorch까지 다시 설치하는 강한 도구라, 문서는 의존성 문제를 고칠 때만 쓰고 그 전에 설치 폴더 전체를 백업하라고 적었다. 평소 업데이트용이 아니다.

B 갈래 — 커스텀 노드를 빼고 켜 본다

B 갈래가 의심되거나 갈래를 모르겠다면 커스텀 노드를 하나도 불러오지 않은 채 켜 본다. 공식 문제 해결 문서가 맨 앞에 두는 순서이고, 문서 첫머리는 접수되는 문제 대부분이 커스텀 노드와 관계있다고 적었다.

• 수동 설치: python main.py --disable-all-custom-nodes
• 포터블: run_nvidia_gpu.bat를 복사해 새 이름으로 저장하고, 줄 끝에 --disable-all-custom-nodes를 더한다. 문서가 보여 주는 내용은 .\python_embeded\python.exe -s ComfyUI\main.py --disable-all-custom-nodes --windows-standalone-build 다음 줄에 pause다.
• 데스크톱: 설정 메뉴에서 커스텀 노드를 끈 채 시작하는 항목을 쓴다.

코드로 보면 이 옵션은 노드 본체를 불러오지 않는 데서 끝나지 않는다. main.py는 --disable-all-custom-nodes가 켜져 있고 예외 목록이 비어 있으면 prestartup_script.py 실행 단계 자체를 통째로 건너뛴다. 서버가 뜨기도 전에 멈추는 커스텀 노드까지 함께 빠진다는 뜻이다. ComfyUI-Manager처럼 꼭 살려야 할 노드가 있으면 --whitelist-custom-nodes 뒤에 그 폴더 이름을 적는다.

이 상태로 켜지면 원인은 커스텀 노드 쪽이다. 노드가 몇 개 안 된다면 폴더 이름 끝에 .disabled를 붙이는 방법이 빠르다. main.py와 nodes.py는 custom_nodes 안에서 이름이 .disabled로 끝나는 폴더를 prestartup 단계와 불러오기 단계 모두에서 건너뛴다. 폴더를 다른 곳으로 옮기지 않고 이름만 바꿔 한 개씩 끄고 켤 수 있다. 노드가 많아 절반씩 나눠 좁혀 가는 방법과 comfy-cli의 node bisect 명령은 오류 메시지 읽는 법의 «반씩 끄기» 절에 정리했으므로 여기서는 반복하지 않는다. 손으로 폴더를 옮기거나 이름을 바꾸기 전에 custom_nodes 폴더를 통째로 복사해 두라는 것은 공식 문서의 경고다.

화면은 열리는데 빈 화면 · 어긋난 칸 · 연결 안 되는 선이 문제라면 다시 켤 필요도 없다. 공식 문서는 설정의 Extensions 메뉴에서 서드파티 프런트엔드 확장을 모두 끈 뒤 화면을 새로 고쳐 보라고 안내한다. 범인을 찾은 다음의 길은 네 가지로, 그 노드를 업데이트하거나, 비슷한 노드로 바꾸거나, 작성자 저장소에 이슈를 남기거나, 필요 없으면 빼는 것이다.

설치 방식별 되돌리기

원인을 고칠 시간이 없거나, 고쳐도 안 될 때는 업데이트 전 상태로 돌아간다. 길은 설치 방식마다 다르다.

데스크톱 — 업데이트 전 스냅샷으로 복원

데스크톱이 가장 쉽다. 공식 문서에 따르면 Comfy Desktop은 시작 · 재시작 · 업데이트 전후 · 복원 뒤에 스냅샷을 자동으로 만들고, 스냅샷에는 ComfyUI 판, 커스텀 노드마다의 판 또는 커밋, 환경의 pip 패키지 전부가 들어간다. 설치본 카드의 ⋮ 메뉴에서 Restore Snapshot을 고르거나 Manage 패널의 Snapshots 탭을 연다. 업데이트 직전 스냅샷을 펼치면 복원했을 때 무엇이 바뀌는지 미리 보이고, 확인하면 기록된 ComfyUI 판으로 옮기고 커스텀 노드를 맞추고 pip 패키지를 동기화한다. 도중에 취소하거나 패키지 설치가 실패하면 복원 전 상태로 스스로 되돌리고, 성공하면 post-restore 스냅샷을 남겨 복원 자체도 되돌릴 수 있다. 데스크톱이 직접 만든 Standalone 설치본에서만 스냅샷이 된다는 점은 데스크톱 vs 포터블 편에 적었다.

다음 업데이트부터는 Manage 패널 Update 탭의 채널이 Stable(기본값)인지 확인한다. Latest on GitHub는 master 브랜치의 새 커밋을 받는 채널이다.

포터블 — stable 배치 파일, 또는 백업 브랜치

포터블은 상황에 따라 두 길이 있다.

첫째, update_comfyui.bat로 새 커밋을 받은 뒤 깨졌다면 update_comfyui_stable.bat를 실행한다. update.py는 --stable일 때 master를 받은 다음 판 번호가 가장 높은 v 태그로 checkout하고, requirements.txt가 바뀌었으면 그 판에 맞춰 다시 설치한다. README가 «불안정할 수 있다»고 한 안정판 태그 밖의 커밋에서 안정판으로 내려오는 길이다. 다만 이 길은 «가장 새 안정판»으로 옮길 뿐, 업데이트 직전 자리로 정확히 돌아가는 것은 아니다.

둘째, 업데이트 직전 자리로 정확히 돌아가려면 update.py가 만든 backup_branch를 쓴다. update.py는 git 명령을 부르지 않고 파이썬 pygit2 라이브러리로 저장소를 다루므로, 이 브랜치를 꺼내려면 PC에 git이 따로 깔려 있어야 한다. git이 있다면 순서는 이렇다.

1. 포터블 폴더 안의 ComfyUI 폴더에서 터미널을 연다.
2. git branch로 backup_branch_로 시작하는 이름을 확인한다. 업데이트를 돌린 날짜와 시각이 이름에 들어 있다.
3. git checkout backup_branch_날짜_시_분_초 로 옮긴다.
4. 포터블 폴더로 나와 .\python_embeded\python.exe -s -m pip install -r ComfyUI\requirements.txt로 그 판의 패키지를 맞춘다. requirements.txt가 화면 패키지 판을 «==»로 못 박아 두었으므로, 이 단계에서 화면 패키지도 옛 판으로 내려간다.

update.py가 첫 단계에서 stash로 치워 둔 «사용자가 직접 고친 파일»은 지워진 것이 아니라 git stash list에 남아 있다. 그리고 되돌린 상태에서 update 배치 파일을 다시 누르면 update.py가 master로 돌아가 새 커밋을 다시 받는다. 원인이 고쳐진 판이 나올 때까지는 배치 파일을 누르지 않는 편이 낫다.

수동 설치 — git checkout과 pip

수동 설치는 공식 문서가 판 바꾸기 명령을 그대로 적어 두었다. ComfyUI 폴더에서 git log --oneline으로 커밋을 보고, git checkout 커밋 해시로 옮기고, 돌아올 때는 git checkout master를 쓴다. 릴리스 태그로 옮기려면 git fetch --tags 뒤 git checkout v0.38.0처럼 태그 이름을 쓰면 된다. 태그 이름과 날짜는 릴리스 페이지에서 확인한다. 판을 옮긴 뒤에는 가상 환경을 켜고 pip install -r requirements.txt로 패키지를 그 판에 맞춘다. 이 단계를 빼먹으면 코드만 옛 판이고 화면 패키지는 새 판인, 위 A 갈래의 반대 상황이 된다.

커스텀 노드까지 되돌리기 — ComfyUI-Manager 스냅샷

포터블과 수동 설치에서 위 과정은 본체 코드와 코어 패키지만 되돌린다. 업데이트 때 커스텀 노드까지 함께 올렸다면 그쪽은 ComfyUI-Manager의 스냅샷이 맡는다. Manager README에 따르면 Manager 메뉴에서 Save snapshot을 누르거나 Update All을 쓸 때 지금 설치 상태가 스냅샷으로 저장되고, Restore를 누르면 다음 시작 때 그 스냅샷이 적용된다. Git으로 관리하지 않는 커스텀 노드는 스냅샷 지원이 불완전하다는 단서도 함께 적혀 있다.

ComfyUI 화면이 열리지 않아 Manager 메뉴를 쓸 수 없다면 명령줄 도구 cm-cli를 쓴다. show snapshot-list로 저장된 스냅샷 목록을 보고, restore-snapshot 파일 이름으로 되돌린다. cm-cli는 ComfyUI와 같은 파이썬에서 실행해야 하고, 포터블이라면 실행 배치 파일이 있는 폴더에서 .\python_embeded\python.exe ComfyUI\custom_nodes\ComfyUI-Manager\cm-cli.py 뒤에 명령을 붙이는 모양이 문서의 예다. 다만 ComfyUI README는 Manager를 manager_requirements.txt로 설치하고 --enable-manager 옵션으로 켜는 방식도 안내한다. 이 방식이라면 custom_nodes 안에 ComfyUI-Manager 폴더가 없을 수 있으므로, 쓰는 판의 Manager 문서에서 명령 위치를 다시 확인한다.

되돌렸더니 ASSETS_STARTUP_FAILED가 뜰 때

판을 내린 뒤 «ASSETS_STARTUP_FAILED: newer_revision»이 뜨면 위 C 갈래다. 더 새 판이 자산 데이터베이스의 형식을 올려 둔 상태라 옛 판이 그 파일을 열지 못한 것이다. 코드의 안내대로 메시지에 적힌 데이터베이스 파일을 다른 폴더로 옮겨 두고 다시 켜면 새 데이터베이스가 만들어지고, 안내 문구에 따르면 자산 목록은 파일을 다시 훑어 새로 만든다. 지우지 말고 옮겨 두면 다시 새 판으로 올라갈 때 되살릴 수 있다. 데이터베이스를 건드리기 싫다면 --disable-assets를 붙여 자산 시스템 없이 켜는 길도 코드가 함께 적어 두었다.

다음 업데이트 전에 해 둘 다섯 가지

되돌리는 법을 알아도 가장 편한 것은 되돌릴 일이 없게 만드는 것이다. 위에서 확인한 코드와 문서를 업데이트 전 점검표로 옮기면 이렇다.

데스크톱은 앱 업데이트와 ComfyUI 엔진 업데이트가 따로라는 점도 기억해 둔다. 공식 문서는 앱 자체는 자동으로 업데이트되고 엔진은 Manage 패널의 Update 탭에서 따로 올린다고 적었다. 워크플로를 잃을까 걱정된다면 업데이트 전에 자주 쓰는 워크플로를 JSON으로 저장해 두는 법을 워크플로 불러오기 편에서 볼 수 있다.

자주 묻는 것

업데이트하고 나니 «comfyui-frontend-package is not installed.»가 뜨고 꺼져요.

본체 코드는 새 판으로 바뀌었는데 화면 패키지가 설치되지 않은 상태입니다. 포터블 업데이트 스크립트는 패키지 설치가 실패해도 멈추지 않고 넘어가기 때문에 이런 일이 생깁니다. 오류 메시지에 함께 찍힌 pip install -r 명령을 그대로 실행하거나, 포터블이라면 update_comfyui.bat를 다시 돌리고 이번에는 창에 나오는 pip 오류를 끝까지 읽습니다.

명령 창에 IMPORT FAILED 줄이 여러 개 있는데 화면은 열려요. 괜찮은가요?

ComfyUI는 커스텀 노드를 불러오다 실패해도 경고만 남기고 시작을 이어 가므로, 그 노드들만 빠진 채 돌아가는 상태입니다. 그 노드를 쓰는 워크플로를 열면 노드가 빨갛게 표시됩니다. Manager에서 해당 노드를 업데이트해 보고, 그래도 실패하면 폴더 이름 끝에 .disabled를 붙여 꺼 둔 채 작성자 저장소의 이슈를 확인합니다.

update_comfyui.bat와 update_comfyui_stable.bat 가운데 무엇을 다시 돌려야 하나요?

빠진 패키지를 채우는 것이 목적이면 오류 안내 문구가 권하는 update_comfyui.bat입니다. 새 커밋을 받은 뒤 깨져서 안정판으로 내려오고 싶다면 update_comfyui_stable.bat입니다. 이 배치 파일은 master를 받은 다음 가장 높은 v 태그로 옮기고 그 판에 맞춰 패키지를 설치합니다. 업데이트 직전 자리로 정확히 돌아가는 것은 둘 다 아니고, 그것은 backup_branch를 git으로 꺼내야 합니다.

데스크톱에서 스냅샷을 복원하면 커스텀 노드도 돌아가나요?

네. 공식 문서에 따르면 데스크톱 스냅샷에는 ComfyUI 판, 커스텀 노드마다의 판 또는 커밋, pip 패키지가 모두 기록되고, 복원은 이 셋을 함께 맞춥니다. 복원 중 패키지 설치가 실패하면 복원 전 상태로 스스로 돌아가고, 성공하면 post-restore 스냅샷이 남아 복원도 되돌릴 수 있습니다.

옛 판으로 되돌렸더니 이번엔 ASSETS_STARTUP_FAILED: newer_revision이 떠요.

더 새 판의 ComfyUI가 자산 데이터베이스를 마지막으로 쓴 탓에 옛 판이 그 파일을 열지 못하는 경우입니다. 메시지에 적힌 데이터베이스 파일을 다른 폴더로 옮긴 뒤 다시 켜면 새 데이터베이스가 만들어집니다. 파일을 건드리고 싶지 않다면 실행 옵션에 --disable-assets를 붙여 자산 시스템 없이 켭니다.

참고 자료

1. ComfyUI 소스 코드 .ci/update_windows(update.py · update_comfyui.bat · update_comfyui_stable.bat) — stash · backup_branch_날짜 브랜치 생성 · master 받기 · --stable일 때 가장 높은 v 태그로 checkout · requirements.txt가 바뀌었을 때 pip install과 실패 시 그냥 넘어가는 부분 · update.py 자기 갱신 뒤 다시 실행하는 배치 파일. github.com
2. ComfyUI 소스 코드 main.py — prestartup_script.py 실행과 PRESTARTUP FAILED 출력, --disable-all-custom-nodes일 때 prestartup을 건너뛰는 부분, .disabled 폴더 건너뛰기, 자산 데이터베이스 실패 시 ASSETS_STARTUP_FAILED 출력과 종료, newer_revision · in_use · locked 안내 문구. github.com
3. ComfyUI 소스 코드 nodes.py — 커스텀 노드 불러오기와 Import times for custom nodes · (IMPORT FAILED) 출력, 불러오기 실패를 경고로만 남기는 부분, .disabled 폴더 건너뛰기, comfy_extras 불러오기 실패 시 «지난 업데이트에서 추가된 의존성» 안내 문구. github.com
4. ComfyUI 소스 코드 app/frontend_management.py — comfyui-frontend-package가 없으면 오류를 내고 종료하는 부분, 설치된 판이 requirements.txt보다 낮을 때의 경고 문구, Falling back to the default frontend. github.com
5. ComfyUI 소스 코드 utils/install_util.py — 패키지가 없을 때 안내하는 pip install -r 명령과 포터블 update_comfyui.bat 안내 문구. github.com
6. ComfyUI 소스 코드 comfy/cli_args.py — --disable-all-custom-nodes · --whitelist-custom-nodes · --windows-standalone-build(자산 시스템 켬) · --enable-manager 옵션 설명. github.com
7. ComfyUI requirements.txt — comfyui-frontend-package · comfyui-workflow-templates · comfyui-embedded-docs를 == 로 판을 못 박아 둔 부분. github.com
8. ComfyUI README — 주간 릴리스 주기, 안정판 약 2주마다, 안정판 태그 밖의 커밋은 매우 불안정하고 커스텀 노드를 깨뜨릴 수 있다는 경고, 프런트엔드가 2주마다 본체에 합쳐진다는 설명, manager_requirements.txt 설치와 --enable-manager로 Manager를 켜는 방식. github.com
9. ComfyUI Releases — 2026-10-13 확인 시 가장 새 릴리스 v0.39.0(2026-10-05 UTC) · 그 앞 v0.38.0(2026-09-29 UTC). github.com
10. ComfyUI 공식 문서. How to Update ComfyUI — 업데이트 = 본체 코드 + 코어 의존 패키지, git pull만 하고 pip install을 빼먹을 때의 증상, update_comfyui_and_python_dependencies.bat 경고, 수동 설치 git checkout으로 판 바꾸기, 판을 독자적으로 최신으로 올리지 말라는 경고. docs.comfy.org
11. ComfyUI 공식 문서. Troubleshooting Custom Node Issues — 커스텀 노드 모두 끄기(데스크톱 설정 · 수동 · 포터블 배치 파일), 프런트엔드 확장이 가장 많은 문제를 일으킨다는 설명, 일반 커스텀 노드의 의존성 충돌로 시작이 안 될 수 있다는 설명, 고치는 네 가지 길. docs.comfy.org
12. ComfyUI 공식 문서. Troubleshooting Overview — 접수되는 문제 대부분이 커스텀 노드 관련이라는 안내, git으로 업데이트한 뒤 프런트엔드 패키지 미갱신 시 pip install -r requirements.txt, 설정의 About 화면에서 ComfyUI 판 확인. docs.comfy.org
13. ComfyUI 공식 문서. Desktop Snapshots — 업데이트 전후 자동 스냅샷, 스냅샷이 담는 것(ComfyUI 판 · 커스텀 노드 판 · pip 패키지), 복원 미리 보기와 실패 시 자동 되돌림, post-restore 스냅샷. docs.comfy.org
14. ComfyUI 공식 문서. Managing Installations — Update 탭의 Stable(기본) · Latest on GitHub 채널, Snapshots 탭, 시작 로그를 볼 수 있는 Terminal 탭, About 탭의 판 정보. docs.comfy.org
15. ComfyUI-Manager README — Save snapshot · Update All 때 스냅샷 저장, Restore는 다음 시작 때 적용, Git으로 관리하지 않는 노드는 스냅샷 지원이 불완전하다는 설명. github.com
16. ComfyUI-Manager cm-cli 문서 — save-snapshot · restore-snapshot · show snapshot-list 명령, ComfyUI와 같은 파이썬에서 실행해야 한다는 조건과 포터블 실행 예. github.com