주니어 PM의 AI 자습서: Flux.1 [dev]

📌 주니어 PM의 AI 자습서: Flux.1 [dev]

AI 이미지 생성의 SOTA

Flux.1 [dev] 는 Black Forest Labs(BFL)가 2024년 8월 발표한, 120억 개 파라미터 규모의 'rectified flow transformer' 를 기반으로 하는 텍스트-to-이미지 생성 모델입니다. 텍스트 프롬프트를 입력으로 받아 고해상도(최대 1,024x1,024) 이미지를 생성합니다.

 

기존 diffusion 모델의 한계를 넘어선 'flow matching' 기법을 사용해서 복잡한 노이즈 제거 과정을 단순화하여 적은 추론 단계로도 고품질의 이미지를 생성합니다.

 

이 모델은 AI 이미지 생성의 '스테이트-오브-더-아트'로, Midjourney나 DALL-E와 경쟁하고 있습니다. 오픈소스 생태계(ComfyUI, Replicate API)를 통해 실무 배포가 용이합니다.

 

✅ 2025년 12월 11일 기준, 이미 Flux.2 가 출시되었습니다. 하지만 Flux.1 에 대한 기본적인 내용을 아는 것이 디퓨전 기반 생성 ai 모델을 이해하는 데 중요하다고 생각해서 공부합니다. 🫠

 

 

주요 정의 및 특징

• 아키텍처:
  • Transformer와 rectified flow를 결합한 하이브리드 구조로, 기존 Stable Diffusion의 노이즈 제거 과정이 아닌 '직접 흐름 매칭'으로 이미지를 생성합니다.
  • 이는 텍스트 지시를 이미지에 반영하는 정확도(프롬프트 준수율)를 90% 이상으로 높여줍니다.
• 버전 차이:
  • Flux.1 시리즈 중 [dev]는 개발자/연구자용으로, 비상업 라이선스로 제공합니다.
  • [pro]보다 약간 낮은 품질이지만, 로컬에서 실행 가능합니다.
  • guidance distillation(지도 학습 압축)으로 GPU 효율이 높아졌습니다.
  • => e.g.) NVIDIA RTX에서 50스텝 생성 시 10-20초 소요.
• 기술 스펙:
  • 입력: 텍스트 프롬프트 (최대 512 토큰).
  • 출력: RGB 이미지.
  • 라이브러리: Hugging Face Diffusers로 쉽게 통합
  • => e.g.) FluxPipeline 클래스 사용.
• 라이선스:
  • 비상업적 사용 무료, 상업 시 별도 라이선스 필요.
  • Acceptable Use Policy로 해로운 콘텐츠 생성 금지. (엄격)

 

Flux. 1 모델 시리즈의 세 가지 버젼

• Flux.1 [schnell]은 속도와 효율성을 위해 설계된 가벼운 버전(오픈소스 Apache 2.0 라이선스)
• Flux.1 [dev]는 비상업용(non-commercial) 사용을 위한 오픈 웨이트 모델로 품질이 높고 효율성이 개선된 버전
• Flux.1 [pro]는 최고 품질의 폐쇄형 모델로, API 라이선스를 통해서만 접근 가능

 

출시 배경

"우리는 텍스트-to-이미지 분야의 새로운 SOTA를 만들고 싶었다."
“Stable Diffusion은 2022년 기준으로는 혁명이었지만, 이제는 2년이나 지난 기술이다. 우리는 그때부터 다음 단계를 준비해왔다."
“우리는 더 이상 UNet-diffusion 구조에 얽매이고 싶지 않았다. Transformer + Flow가 정답이었다.”

 

Stable Diffusion 을 만든 Stablitiy AI 의 핵심 연구원 10여 명이 2023년~2024년에 대거 이탈하여 BLF를 설립했습니다. 그들은 '진짜 차세대 모델' 을 세상에 보여주고 싶었다는 말과 함께 2024년 8월 Flux. 1 시리즈를 출시했습니다. 논문도 없이 바로 120억 개의 파라미터를 가진 모델을 세상에 던졌습니다.

BLF는 Flux. 1 [dev]의 출시로 Rectified Flow 라는 새로운 패러다임을 증명하며 커뮤니티와 개발자 생태계를 다시 살려내려고 했습니다. 스테이블 디퓨전 1.5 이후 오픈소스 이미지 모델이 너무 정체되어 있었던 상황에서, ComfyUI, Automatic1111, InvokeAI 등 생태계가 다시 폭발적으로 성장하도록 불쏘시개 역할을 했다는 평가입니다. “dev 웨이트를 공개해서 누구나 fine-tuning 할 수 있게 한다.”

다른 버전인 Flux. 1 [pro] 와 [ultra] 는 폐쇄형 API로만 제공했습니다. 오픈소스 [dev] 와 [schnell] 로 사용자를 모으고, 돈이 되는 고품질 버전을 API로만 판매하겠다는 전형적인 오픈코어 전략으로 수익 모델을 확보했습니다.

Flux.1 의 출시는, 2024년 이후 출시되는 텍스트-to-이미지는 4~8 step으로도 사진급의 품질이 나와야 하고, 손·글자·프롬프트 준수가 기본이어야 하며, 오픈소스로도 Midjourney v6를 압도할 수 있어야 한다는 메시지를 던졌습니다. 이 한 방으로 2022~2023년 동안 쌓였던 '오픈소스는 이제 폐쇄형한테 못 이긴다'는 업계 통념을 완전히 깨버렸습니다.

 

용도/특징

• Flux.1 [dev]는 주로 고품질 이미지 생성, 아트웍 제작, 이미지 편집 등의 연구·개발 및 크리에이티브 워크플로에 사용됩니다.
• 이전 모델들 대비 텍스트 프롬프트에 대한 이해도와 표현력이 개선되어, 복잡한 묘사에서 뛰어난 결과를 냅니다.
• 예를 들어, Flux.1은 사람 손의 손가락 개수나 위치를 정확히 표현해 과거 Stable Diffusion 모델들이 취약하던 손 묘사 문제를 해결했다는 평가가 있습니다 .

 

활용 사례/예시

• 2024년 8월, Elon Musk의 AI 챗봇 Grok에 Flux.1 모델이 통합되어 X에서 프리미엄 이미지 생성 기능으로 사용되었습니다.
• 또한 같은 해 11월에는 Mistral AI의 챗봇 Le Chat이 FLUX Pro를 도입했습니다.
• 2025년 초에는 NVIDIA가 차세대 GPU 아키텍처(Blackwell)에 Flux.1을 기반으로 채택했습니다.

---

📌 PM이 Flux.1 [dev] 관련 개발팀과 대화할 때 챙겨야 할 핵심 포인트

 

핵심 포인트 요약

• Flux.1 [dev]는 비상업용, 서비스 투입 전 라이선스 결정을 먼저 해야 합니다.
• GPU 메모리 요구량이 크므로 리소스/비용/속도 목표를 먼저 정해야 합니다.
• 모델 구조가 SD와 달라서 기존 파이프라인 호환성 점검이 필수입니다.
• 윤리·저작권·안전 정책을 기획 단계부터 반영해야 합니다.
• PM은 Flux를 다루는 멀티 팀 협업의 중심인 허브 역할을 맡아야 합니다.

 

핵심 포인트 상세

1. 라이선스 이슈: [dev] 는 상업용 불가

• Flux.1 [dev]는 비상업용 모델.
• 제품에 직접 적용 불가.
• 실 서비스에서는 Schnell(오픈소스) 또는 Pro(유료 라이선스) 고려해야 함.
• → 지금 연구용인지, PoC인지, 아니면 실제 서비스 예정인지를 명확히 할 것.

2) 성능 vs. 리소스: GPU 요구량 빡셈

• FP16 기준 32GB VRAM 필요.
• 로컬/온프렘 절대 가벼운 모델 아님.
• 양자화(Q4/Q8, FP8) 필요 여부도 개발팀이 판단해야 함.
• → PM은 얼마나 빠르게/얼마나 싸게/어떤 환경에서 돌릴 것인지를 처음부터 구체적으로 확인해야 함.

3) 텍스트 이해력 좋지만, 프롬프트 검증 프로세스 필요

• Flux.1의 최대 장점은 텍스트 이해력(프롬프트 파싱) + 사실적 표현력.
• 근데 너무 잘 그려서, 윤리/저작권/부적절 생성물 리스크도 커짐.
• → 개발팀과 함께 필터링 체인, 프롬프트 가이드라인, NSFW 안전장치 미리 협의해야 함.

4) 모델 구조 상 '전통 확산모델’과 다름 → 개발자 경험 달라짐

• Flux.1은 Rectified Flow + Transformer 전면 구성.
• SD계열(U-Net 기반)과 설정이 다름.
• →
• 개발팀: "기존 SD 파이프라인 재사용 가능?"
• PM: “호환성, 모델 튜닝 난이도, 속도 차이” 반드시 체크
• 미리 맞추지 않으면 일정에 악영향.

5) PoC 단계에서 세 가지 목표를 먼저 합의해야 함

• 결과물 품질 기준(Benchmark)
• 속도/비용 기준(Latency & Cost)
• 프롬프트 명령 정확도(Prompt adherence)
• → PM이 이 기준을 먼저 정리해줘야 개발팀이 '뭘 성공으로 볼지'를 이해함.

6) API 기반인지 로컬 기반인지 먼저 확정해야 함

• Pro 모델은 API → 빠르고 안정적이지만 비용과 벤더 종속성 증가
• dev 모델은 로컬 → 비용 효율적이지만 인프라 부담 증가
• → PM이 초기에 방향을 확실하게 잡아야 개발 방향성이 흔들리지 않음.

7) 이미지 생성 파이프라인은 실제로 ‘멀티 팀 협업 구조’

• 개발팀만의 일이 아님→ 디자인팀이 결과물 품질 점검→ 데이터팀이 프롬프트 로그 관리
• PM은 이 스쿼드를 묶어서 워킹 그룹 형태로 끌고 가는 게 핵심.
• → 법무/윤리팀: 안전성 검토
• → UX팀: 사용자 입력/편집 기능

8) 리스크 관리 포인트

• 저작권 리스크 (학습데이터 출처 공개 X)
• 딥페이크 악용 가능성
• 생성물 이슈 대응 프로세스 필요
• API 장애/지연 vs 로컬 GPU 장애
• PM이 미리 체크리스트 만들고 개발팀과 운영팀한테 공유해야 함.