MIGRATION

갈아타는 건 화면이지 모델이 아니다 — A1111에서 ComfyUI·Forge로 옮기기

junetapa 약 9분

AUTOMATIC1111 WebUI 의 개발이 사실상 멈췄다. 그래서 옮길지 말지를 고민하게 되는데, 막상 갈라 보면 덩치가 큰 짐은 옮길 필요조차 없다. 체크포인트도 LoRA 도 같은 .safetensors 파일이라 폴더만 가리켜 주면 그대로 읽힌다. 갈아타는 것은 모델이 아니라 화면이다.

이 글의 성격

설치 안내가 아니다. 이미 A1111 을 쓰고 있는 사람이 옮길 때 무엇이 따라오고 무엇이 안 따라오는지만 적었다. 처음 까는 순서와 최소 사양은 설치 편에, 노드 방식 입문은 ComfyUI 편에 따로 있다. 검색 수치는 2026년 9월 9일에 내 사이트 Search Console 에서 잰 값이다.

왜 지금 이사 이야기가 나오나

오랫동안 로컬 이미지 생성의 기본값은 AUTOMATIC1111 WebUI 였다. 검색해서 나오는 설치 안내도, 유튜브 강좌도 대부분 그 화면을 기준으로 만들어졌다. 그런데 그 저장소의 개발이 사실상 멈춘 상태다. 새 모델이 나와도 지원이 늦고, 늦은 만큼 다른 프런트엔드에서 먼저 돌아간다.

설치 수만 보면 아직 A1111 이 가장 많다. 다만 그건 이미 깔려 있는 것을 세는 숫자다. 새로 까는 사람이 어디로 가는지는 다른 문제고, 지금은 ComfyUI 와 Forge 계열로 간다.

검색에서도 같은 모양이 보였다

이 사이트의 Search Console 을 2026년 9월 9일에 열어 두 구간을 따로 받아 봤다. 「comfyui 사양」이라는 검색어는 90일 노출이 31인데 그 31이 전부 최근 28일에 몰려 있었다. 앞의 두 달은 0이다.

원래 있던 검색이 유지된 모양이 아니라 없던 검색이 새로 생긴 모양이다. 그리고 「사양」을 먼저 찾는다는 것은 처음 쓰는 사람보다 이미 로컬을 굴려 본 사람의 질문에 가깝다. 내 그래픽카드로 이쪽도 되는지를 먼저 확인하는 것이니까.

그래서 이 글은 설치 안내가 아니다. 이미 A1111 을 쓰고 있는 사람이 옮길 때 무엇이 따라오고 무엇이 안 따라오는지만 적는다. 처음 까는 순서는 설치 편에, 노드 방식이 처음이면 ComfyUI 입문 편에 따로 있다.

따라오는 것과 안 따라오는 것부터 가른다

이사를 망설이는 이유는 대개 하나다. 그동안 모아 둔 것을 버리게 될까 봐. 그런데 실제로 갈라 보면 덩치가 큰 쪽은 거의 다 따라온다.

A1111에서 ComfyUI나 Forge로 옮길 때 체크포인트와 LoRA는 그대로 따라오고 확장 기능과 화면 설정은 다시 맞춰야 한다는 것을 보여 주는 도해
용량을 차지하던 것은 그대로 따라온다. 다시 맞춰야 하는 것은 대부분 가볍다.

그대로 따라오는 것

체크포인트, LoRA, VAE, 임베딩, ControlNet 모델. 이것들은 전부 .safetensors 같은 모델 파일 형식이고, 특정 프런트엔드의 소유물이 아니다. 폴더만 가리켜 주면 어느 쪽에서든 읽는다.

대개 이 파일들이 수십 기가바이트를 차지한다. 즉 이사 짐의 대부분은 옮길 필요조차 없다.

다시 맞춰야 하는 것

확장 기능이 첫째다. Forge 는 A1111 의 갈래라 상당수가 그대로 동작하지만 전부는 아니고, ComfyUI 는 구조 자체가 달라서 같은 일을 하는 노드를 새로 찾아야 한다. 기능이 없어지는 것이 아니라 이름과 모양이 바뀐다고 보는 편이 맞다.

둘째는 화면 설정이다. 즐겨 쓰던 기본값, 프리셋, 단축키 배치는 넘어가지 않는다. 셋째가 생성 이력이다. 이건 이미지 파일로는 남아 있어도 「그 화면에서 다시 불러오기」는 안 된다.

먼저 적어 두면 편한 것

옮기기 전에 지금 쓰고 있는 확장 기능 목록자주 쓰는 설정값을 텍스트로 한 번 적어 둔다. 새 쪽에서 대응을 찾을 때 이 목록이 있는 것과 없는 것의 차이가 크다. 없으면 「뭔가 있었는데」로 끝난다.

Forge 인가 ComfyUI 인가 — 지금 쓰던 방식으로 고른다

둘 중 어느 쪽이 낫냐는 질문에는 답이 없다. 대신 지금 A1111 을 어떻게 쓰고 있었는지를 보면 갈린다.

지금 A1111을 쓰는 방식에 따라 Forge와 ComfyUI 중 어디로 옮길지 갈라지는 결정 흐름을 보여 주는 도해
「무엇이 더 좋은가」가 아니라 「지금 무엇을 하고 있었나」로 고른다.

Forge 로 가는 쪽

지금 화면이 익숙하고 그대로 쓰고 싶다면 Forge 다. A1111 에서 갈라져 나온 것이라 화면 구성이 거의 같다. 프롬프트 칸에 넣고 버튼을 누르는 흐름이 그대로고, 확장 기능도 상당수 그대로 붙는다. 옮기는 데 드는 시간이 가장 짧다.

대신 얻는 것도 그만큼이다. 화면이 같으니 할 수 있는 일의 모양도 크게 달라지지 않는다.

ComfyUI 로 가는 쪽

같은 작업을 매번 반복하고 있거나, 여러 단계를 이어 붙이고 싶었다면 ComfyUI 다. 노드로 연결하는 방식이라 작업 순서 자체를 저장했다가 다시 부를 수 있다. 그리고 새 모델이 나왔을 때 대응이 빠른 쪽도 이쪽이다.

대신 첫날이 불편하다. 버튼 하나로 되던 것이 노드 대여섯 개가 된다. 익숙해지는 데 반나절쯤 든다고 보면 크게 틀리지 않는다.

둘 다 깔아도 된다

이게 의외로 흔한 답이다. 모델 폴더를 공유해 두면 디스크를 두 배로 쓰지 않는다. 익숙한 작업은 Forge 에서, 새로 짜야 하는 작업은 ComfyUI 에서 하는 식으로 나눌 수 있다. 방법은 다음 절이다.

모델 폴더는 한 곳에 두고 양쪽이 본다

이사에서 가장 아까운 실수가 같은 체크포인트를 두 번 받는 것이다. 수 기가짜리 파일이라 금방 디스크가 찬다. 그럴 필요가 없다.

모델 폴더를 앱 바깥 한 곳에 두고 A1111 Forge ComfyUI 세 프런트엔드가 같은 폴더를 바라보게 하는 구조를 보여 주는 도해
모델을 어느 앱 폴더 안에도 두지 않는 것이 요령이다. 앱을 지워도 모델이 안 지워진다.

ComfyUI 쪽에서 잡는 법

ComfyUI 폴더에 extra_model_paths.yaml.example 이라는 예시 파일이 들어 있다. 이것을 extra_model_paths.yaml 로 이름만 바꾼 뒤, base_path 를 기존 A1111 설치 위치로 적어 준다. 그러면 그 아래의 체크포인트, VAE, LoRA 폴더를 그대로 읽어 간다.

A1111 · Forge 쪽에서 잡는 법

실행 옵션에 --ckpt-dir 로 공용 폴더를 가리키면 된다. 모델 종류마다 비슷한 옵션이 따로 있어서, 체크포인트만 옮겨도 절반은 해결된다.

더 나은 방식은 「앱 바깥」이다

둘 중 하나를 기준으로 삼는 것보다, 어느 앱 폴더도 아닌 곳에 모델 창고를 하나 만들고 양쪽이 그것을 보게 하는 편이 낫다. 앱을 지우거나 다시 깔아도 모델이 딸려 지워지지 않기 때문이다. 윈도에서는 심볼릭 링크나 정션으로 각 앱의 기본 폴더를 창고에 연결하는 방법도 같이 쓰인다.

순서로 정리하면 이렇다. 창고 폴더를 먼저 정하고, 기존 모델을 그리로 옮기고, 그다음에 각 프런트엔드가 그 폴더를 보게 설정한다. 설정을 먼저 하고 파일을 옮기면 경로가 어긋난 채로 「모델이 없다」가 나온다.

옮긴 뒤에 반드시 달라지는 것 하나

여기서 놀라는 사람이 많다. 같은 프롬프트에 같은 시드를 넣어도 A1111 에서 나오던 그림이 그대로 안 나온다.

모델이 바뀐 것이 아니다. 프런트엔드마다 샘플러 구현과 기본값이 조금씩 다르고, 그 차이가 결과에 남는다. 노이즈를 만드는 방식, 프롬프트 가중치를 해석하는 규칙, 기본으로 켜져 있는 보정 같은 것들이다.

그래서 이사한 다음 날 「망했다」고 결론 내리기 쉬운데, 대개는 설정이 안 맞은 것이다. 확인할 순서는 이렇다.

  1. 같은 모델 파일을 읽고 있는지부터 본다 — 이름이 같아도 다른 파일일 수 있다
  2. 샘플러와 단계 수, CFG 값을 옛 화면과 하나씩 맞춰 본다
  3. VAE 가 자동으로 다른 것이 잡혀 있지 않은지 본다
  4. 그래도 다르면 같아지기를 포기하고 새로 맞춘다 — 여기서 시간을 가장 많이 쓴다

네 번째가 중요하다. 완전히 같은 그림을 재현하는 것이 목표라면 옮기지 않는 편이 낫다. 이사는 앞으로 만들 것을 위한 것이지, 과거를 복제하기 위한 것이 아니다.

안 옮겨도 되는 경우

모두가 옮겨야 하는 것은 아니다. 세 경우는 그냥 두는 편이 낫다.

첫째, 지금 하는 작업이 잘 돌아가고 새 모델이 필요 없을 때다. A1111 이 갑자기 못 쓰게 되는 것이 아니다. 이미 깔린 것은 계속 돈다.

둘째, 완성된 작업물을 계속 같은 조건으로 뽑아야 할 때다. 앞 절의 이유 그대로다.

셋째, 확장 기능 한두 개에 작업 전체가 걸려 있을 때다. 그 확장의 대응이 새 쪽에 없으면 옮기고 나서 막힌다. 이 경우는 옮기기 전에 그것부터 확인해야 한다.

바꿔 말하면 옮길 때는 새 모델을 쓰고 싶어졌을 때다. 그때가 되면 미루던 이유가 자연히 사라진다.

자주 묻는 것

A1111 을 지우고 옮겨야 하나요?

지울 필요 없다. 모델 폴더만 공유해 두면 셋이 같이 있어도 디스크를 더 쓰지 않는다. 오히려 한동안 같이 두고 결과를 비교하는 편이 낫다. 확신이 선 다음에 지워도 늦지 않다.

모아 둔 LoRA 를 다시 받아야 하나요?

아니다. 같은 .safetensors 파일이라 폴더만 가리켜 주면 그대로 읽는다. 이사에서 다시 받아야 하는 것은 거의 없고, 다시 맞춰야 하는 것은 확장 기능과 설정값 쪽이다.

Forge 와 ComfyUI 중 하나만 고르라면요?

지금 화면이 익숙하고 바꾸기 싫으면 Forge, 같은 작업을 반복하고 있어서 순서를 저장하고 싶으면 ComfyUI 다. 새 모델 대응이 빠른 쪽을 원한다면 ComfyUI 쪽이 유리하다.

옮긴 뒤에 그림이 달라졌는데 잘못한 건가요?

대개 잘못한 것이 아니다. 프런트엔드마다 샘플러 구현과 기본값이 달라서 같은 시드가 같은 결과를 주지 않는다. 모델·샘플러·단계·CFG·VAE 를 맞춰 보되, 완전히 같아지지 않는 것은 정상 범위로 본다.

확장 기능이 새 쪽에 없으면 어떻게 하나요?

같은 이름을 찾기보다 그 확장이 하던 일을 적어 놓고 대응을 찾는 편이 빠르다. ComfyUI 는 노드 조합으로 같은 결과를 만드는 경우가 많고, Forge 는 A1111 확장 상당수가 그대로 붙는다. 그래도 없으면 그 작업만 옛 설치에 남겨 두는 것도 방법이다.

참고 자료

  1. Google Search Console. junetapa.com 검색 성능 — 「comfyui 사양」의 90일·28일 노출은 2026년 9월 9일에 두 구간을 따로 조회해 비교한 값이다.
  2. AUTOMATIC1111. stable-diffusion-webui — 저장소 활동으로 개발 정체를 확인했다. github.com
  3. ComfyUI Docs. Modelsextra_model_paths.yaml 로 외부 모델 폴더를 연결하는 방법. docs.comfy.org
  4. Hugging Face. Safetensors — 체크포인트·LoRA 가 공유하는 파일 형식. huggingface.co
이 글은 A1111 에서 ComfyUI·Forge 로 옮길 때 무엇이 따라오고 무엇이 안 따라오는지를 정리한 것이다. 검색 노출·클릭 수치는 2026년 9월 9일에 내 사이트 Search Console 에서 90일과 28일 두 구간을 따로 조회해 비교한 값이라 다른 사이트에는 그대로 적용되지 않는다. 설정 파일 이름과 실행 옵션은 각 프로젝트의 공식 문서를 함께 확인하는 편이 안전하다.
A1111ComfyUIForgeStableDiffusionsafetensors로컬이미지생성
junetapa
junetapa
AI 도구를 직접 굴려 보고 남은 기록을 정리한다.
Twitter Facebook URL 복사