2026년 Flux.1 맥 로컬 배포: 네이티브 UI인가 노드 UI인가?

맥에서 Flux.1을 실행했지만 모델을 불러오는 동안 스왑이 늘고, 첫 이미지가 나오기 전에 앱이 멈춥니다. 이번 주에는 같은 Flux.1 검사점으로 Schnell을 먼저 시험하고, 단일 이미지 제작이면 Draw Things, 복잡한 노드와 반복 작업이면 ComfyUI를 선택하는 것이 가장 빠른 판단입니다.

이 글을 읽어야 하는 대상

낮은 통합 메모리의 Apple Silicon 맥에서 Flux.1이 안정적으로 실행되는지 확인하려는 개인 창작자를 위한 글입니다.
Draw Things와 ComfyUI 중 제작 도구를 골라야 하는 디자이너와 스튜디오, 대량 이미지 작업을 위해 맥 장비를 구매하거나 대여하려는 기술 책임자도 대상입니다.

마지막 업데이트: 2026년 8월 29일. Flux.1 공식 모델 자료, ComfyUI 예제, Draw Things 공개 저장소를 기준으로 내용을 확인했습니다. 앱과 추론 방식이 바뀌면 같은 조건으로 다시 측정해야 합니다.

속도보다 먼저 작업 장면을 나눠야 합니다

Flux.1 맥 로컬 배포에서 가장 흔한 실수는 한 장의 생성 시간만 캡처해 승자를 정하는 것입니다. 실제 제작 시간은 모델을 불러오는 냉시작, 첫 이미지, 예열 뒤 연속 생성, 고해상도 작업 중 최고 메모리 사용량으로 나뉩니다.

또한 맥은 그래픽 메모리와 시스템 메모리를 완전히 분리하지 않는 통합 메모리 구조를 사용합니다. Apple은 Metal 장치의 통합 메모리 여부를 별도 속성으로 설명합니다. 따라서 모델, 텍스트 인코더, 샘플러, 자동 인코더가 같은 자원을 두고 경쟁할 수 있습니다. Apple의 통합 메모리 설명을 확인한 뒤 활동 모니터에서 스왑 증가를 함께 봐야 합니다.

선택 기준은 다음처럼 정리됩니다.

• 설치와 관리 시간을 줄이고 단일 이미지와 프롬프트 반복을 빠르게 처리하면 Draw Things를 우선합니다.
• 지역 재생성, 구조 제어, 여러 모델 연결, 일괄 후처리가 필요하면 ComfyUI를 우선합니다.
• 지속적인 스왑, 앱 종료, 시스템 반응 저하가 생기면 설정을 더 낮추기보다 로컬 실행을 중단합니다.
• 검사점과 양자화 방식이 다르면 두 앱의 속도 비교를 무효로 봅니다.

낮은 메모리 맥에서는 안정성부터 확인합니다

Flux.1은 모델 분기부터 구분해야 합니다. Schnell과 Dev는 같은 이름의 단순한 설정 차이가 아닙니다. Schnell 공식 모델 자료와 Dev 공식 저장소를 각각 확인하고, 공식 가중치인지 제삼자 양자화 파일인지 기록해야 합니다.

낮은 메모리 환경에서 문제가 생기는 지점은 모델 로딩 하나로 끝나지 않습니다.

• 모델 본체를 불러오는 순간 통합 메모리 여유가 줄어듭니다.
• 텍스트 인코더가 프롬프트 처리에 자원을 추가로 사용합니다.
• 샘플링 중 중간 데이터가 유지되며 다른 앱과 자원을 나눕니다.
• 자동 인코더가 이미지를 복원할 때 순간적인 메모리 압박이 생길 수 있습니다.
• ComfyUI는 파이썬 실행 환경, 노드, 모델 구성 요소를 함께 관리해야 하므로 설치 요소가 늘어납니다.

따라서 처음부터 Dev와 큰 작업 흐름을 동시에 올리지 않습니다. Schnell 또는 해당 맥과 호환된 양자화 검사점으로 기본 생성부터 확인합니다. 그다음 동일한 해상도와 샘플링 단계에서 Dev를 별도 시험합니다. 커뮤니티 이슈에는 Draw Things에서 Flux 계열을 실행하며 생긴 사례가 기록되어 있지만, 개별 환경의 보고는 모든 맥의 성능 보증이 아닙니다. Draw Things 커뮤니티 이슈는 문제를 찾는 참고 자료로만 사용해야 합니다.

주의: Q4와 Q8처럼 양자화 단계가 다른 파일은 이름이 같은 Flux.1이라도 메모리와 결과가 달라질 수 있습니다. 파일명만 보고 비교하지 말고 실제 검사점의 출처와 형식을 작업 기록에 남겨야 합니다.

단일 이미지 제작은 조작 흐름이 비용을 좌우합니다

개인 창작자가 프롬프트를 여러 번 바꾸는 작업에서는 샘플러의 초당 처리량보다 실패 없이 다음 이미지를 시작하는 과정이 중요합니다. 모델 다운로드, 파일 가져오기, 기본 설정, 결과 저장까지의 단계가 길어지면 한 장마다 사람이 개입하는 시간이 늘어납니다.

Draw Things는 앱 중심의 실행 흐름을 선호하는 작업에 맞습니다. 노드 연결과 파이썬 환경을 먼저 정리하지 않아도 되므로 학습과 복구 부담이 상대적으로 작습니다. 프롬프트 기록, 이전 결과 확인, 로라 호출, 자주 쓰는 설정 변경이 한 화면에서 이어지는지도 실제 버전에서 확인해야 합니다. Draw Things 공개 저장소의 최신 기록과 설치 방식이 현재 사용하려는 모델 파일을 지원하는지 먼저 살펴보는 것이 좋습니다.

다만 편리한 UI가 곧 빠른 생성이라는 뜻은 아닙니다. 같은 맥에서 다음 조건을 고정해야 합니다.

• Flux.1 Schnell 또는 Dev의 구체적인 분기
• 공식 가중치인지 제삼자 양자화인지
• 양자화 형식
• 해상도와 샘플링 단계
• 같은 난수 씨앗
• 냉시작과 연속 생성 시간
• 생성 중 최고 통합 메모리와 스왑 변화

이 항목을 기록하지 않으면 Draw Things Flux 속도와 ComfyUI의 결과를 비교해도 재현할 수 없습니다.

복잡한 제작은 노드 재사용성이 앞섭니다

지역 재생성, 포즈와 깊이 같은 구조 제어, 여러 모델 연결, 생성 뒤 일괄 보정이 필요한 경우에는 ComfyUI의 노드 그래프가 유리할 수 있습니다. 한 번 만든 흐름을 저장하고 다시 불러오면 작업 순서를 팀원에게 전달하기도 쉽습니다. ComfyUI의 Flux 예제를 기준으로 기본 흐름을 먼저 재현한 뒤 필요한 기능을 추가해야 합니다.

여기서 원래 제공되는 노드와 제삼자 노드를 구분해야 합니다. 커뮤니티 패치나 보조 노드는 특정 버전에서만 작동할 수 있고, 업데이트 뒤 의존성 충돌을 일으킬 수 있습니다. GitHub 이슈나 사용자 속도 보고는 문제의 단서이지만 보편적인 성능 결론으로 쓰면 안 됩니다.

노드 작업의 효율은 생성 시간만으로 계산하지 않습니다.

• 처음 작업 흐름을 구성하는 시간
• 잘못 연결했을 때 실패하고 다시 실행하는 시간
• 모델과 노드 버전을 맞추는 관리 시간
• 다른 사람이 같은 결과를 재현하는 데 필요한 설명 시간
• 여러 이미지를 큐에 넣었을 때의 대기 시간

이 항목의 합계가 Draw Things에서 매번 수동으로 설정하는 시간보다 작을 때 ComfyUI의 장점이 나타납니다.

두 UI의 선택 점수는 작업 조건으로 매깁니다

아래 표는 특정 맥의 속도 순위가 아닙니다. 설치 부담, 반복 작업, 흐름 재사용, 장애 대응을 기준으로 한 의사결정용 비교입니다.

조건별 선택 목록

• 설치 후 곧바로 프롬프트를 바꾸며 단일 이미지를 만들면 Draw Things를 선택합니다.
• 노드 그래프를 저장하고 여러 모델을 연결해야 하면 ComfyUI를 선택합니다.
• 통합 메모리가 부족하고 모델 파일도 확정되지 않았다면 Schnell과 가벼운 호환 검사점으로 두 UI 중 하나만 먼저 시험합니다.
• ComfyUI에서 제삼자 노드를 많이 사용해야 한다면, 먼저 기본 Flux 흐름이 작동하는지 확인한 뒤 노드를 하나씩 추가합니다.
• 냉시작보다 연속 생성이 중요한 팀이라면 예열 뒤 큐 처리와 실패 재실행 시간을 따로 기록합니다.
• 스왑이 계속 증가하거나 시스템이 응답하지 않으면 로컬 고집을 멈추고 장비 업그레이드 또는 클라우드 맥 대여를 비교합니다.

실제 시험은 일곱 단계로 고정합니다

1. 맥 칩, 통합 메모리, 운영 체제, Draw Things 또는 ComfyUI 버전을 기록합니다.
2. Flux.1의 Schnell 또는 Dev 분기와 검사점 출처를 적습니다.
3. Q4, Q8 등 양자화 형식과 모델 구성 요소를 확인합니다.
4. 두 UI에서 같은 해상도, 샘플링 단계, 프롬프트, 난수 씨앗을 사용합니다.
5. 앱을 완전히 종료한 뒤 냉시작 시간을 측정하고 첫 이미지가 완성될 때까지 기록합니다.
6. 예열 뒤 연속 생성 시간을 재고, 생성 중 최고 메모리와 스왑 변화를 활동 모니터에서 적습니다.
7. 해상도를 올리는 압박 시험은 마지막에 진행하고, 앱 종료나 시스템 정지가 나타나면 즉시 중단합니다.

압박 시험을 먼저 하면 실패 원인을 모델, UI, 해상도 중 무엇으로 봐야 하는지 알기 어렵습니다. 낮은 설정에서 안정성을 확보한 뒤 한 항목씩 높여야 합니다.

개인 작업에서 배치 생산으로 넘어가는 기준

하루에 몇 장을 만드는지는 장비 선택의 충분한 기준이 아닙니다. 작업이 얼마나 오래 지속되는지, 큐 대기 시간이 납기를 넘기는지, 같은 환경을 팀원이 다시 만들 수 있는지, 로컬 파일을 옮기는 시간이 얼마나 드는지를 함께 계산해야 합니다.

• 로컬 유지: 작업량이 일정하고 현재 흐름이 중단 없이 끝나며, 외부 서버로 파일을 보내기 어려울 때 적합합니다.
• 장비 업그레이드: 매일 장시간 실행하고 새 장비의 비용을 여러 작업에 나누어 회수할 수 있을 때 검토합니다.
• 클라우드 맥 대여: 단기 캠페인, 납기 직전의 큐 증가, 특정 모델의 일시적인 시험처럼 사용 기간이 짧을 때 검토합니다.

대량 작업을 맡은 팀은 응용 프로그램 화면만 보지 말고 명령 줄 실행, 작업 흐름 버전 관리, 대기열과 동시 작업 수를 확인해야 합니다. ComfyUI의 흐름을 팀 표준으로 삼더라도 노드 버전과 모델 파일을 함께 보관하지 않으면 재현성이 무너집니다.

Flux.1 로컬 실행이 필요한 메모리와 맞는지 먼저 계산하려면 맥 인공지능 그림용 통합 메모리 점검 글에서 작업 조건을 정리할 수 있습니다. 여러 작업을 임시로 처리해야 한다면 클라우드 맥 구성과 대여 기간 안내에서 사용 기간과 환경 재현 조건을 함께 확인하는 편이 낫습니다.

자주 확인하는 문제

낮은 메모리 맥에서 Flux.1은 항상 실행되지 않나요?

항상 그렇다고 단정할 수 없습니다. 같은 맥이라도 Schnell과 Dev, 공식 가중치와 양자화 파일, 텍스트 인코더 구성에 따라 필요한 자원이 달라집니다. 낮은 설정의 기본 흐름으로 시작하고 스왑과 앱 상태를 확인해야 합니다. 안정적으로 끝나지 않으면 더 큰 모델을 억지로 올리지 말고 원격 환경에서 같은 파일을 재현하는 편이 안전합니다.

Draw Things와 ComfyUI의 차이는 속도뿐인가요?

아닙니다. Draw Things는 설치와 단일 이미지 반복에 드는 관리 비용을 줄이기 쉽고, ComfyUI는 노드 그래프를 저장해 복잡한 작업을 재사용하는 데 강점이 있습니다. 따라서 작업량이 적은 개인 창작자는 사람의 설정 시간을, 스튜디오는 흐름 재현과 실패 복구 시간을 중심으로 비교해야 합니다.

Schnell에서 Dev로 바꾸는 시점은 언제인가요?

Schnell의 기본 생성이 끝난다는 사실만으로 Dev 전환을 결정하지 않습니다. 원하는 품질 제어가 실제로 필요한지, 현재 통합 메모리에서 Dev의 모델과 보조 구성 요소를 함께 감당할 수 있는지 확인해야 합니다. 먼저 같은 프롬프트와 같은 검사점 조건을 유지한 별도 시험을 하고, 스왑이 지속되면 전환을 보류합니다.

ComfyUI의 메모리 문제를 줄일 때 가장 먼저 할 일은 무엇인가요?

제삼자 노드를 지우기 전에 기본 Flux 예제를 단독으로 실행해 기준 상태를 만듭니다. 이후 보조 모델과 노드를 하나씩 추가하면서 어느 단계에서 메모리가 급증하는지 기록합니다. 미리보기, 불필요한 모델 상주, 동시에 열린 다른 앱도 줄여야 합니다. 사용자 보고만으로 특정 노드가 모든 환경에서 문제라고 결론 내리면 안 됩니다.

로컬 실행을 계속할지 대여할지 판단하는 기준은 무엇인가요?

한 번의 실패보다 반복되는 운영 비용을 봐야 합니다. 매번 모델을 다시 불러오고 큐가 납기를 넘기거나 스왑 때문에 작업을 재시작한다면 클라우드 맥 대여가 단기적으로 더 합리적일 수 있습니다. 반대로 장기간 일정한 부하와 물리 파일 접근이 필요하면 구매 또는 업그레이드를 검토하고, 먼저 실제 작업 흐름의 재현 시험을 진행합니다.

현재 방식이 낮은 메모리의 개인 맥에만 의존하면 모델 로딩 실패, 스왑으로 인한 대기, 팀 작업 흐름의 재현 실패가 반복될 수 있습니다. 반대로 고정 장비를 바로 구매하면 단기 프로젝트가 끝난 뒤 사용하지 않는 비용이 남고, 필요한 모델이 바뀔 때 다시 장비를 바꿔야 합니다. 이런 조건이라면 JexMac에서 실제 모델 분기와 작업량을 기준으로 클라우드 맥 환경을 임시 대여해 검증하는 편이 더 유연합니다. 대여 가능 환경은 JexMac의 맥 대여 안내에서 확인하고, 구매 전에는 같은 작업 흐름이 끝까지 재현되는지 먼저 점검하는 것이 좋습니다.

자주 묻는 질문