Flux 2.9와 Weaveworks 이후 2년 — 스폰서를 잃은 GitOps 프로젝트는 어떻게 유지되고 있나

들어가며 — "이 프로젝트의 미래는 위험한가?"
타임라인 — 검증 가능한 사실만
릴리스 케이던스 실측 — 흔들렸지만 끊기지 않았다
지금 Flux는 누가 만드는가 — CORE-MAINTAINERS 파일 읽기
돈은 어디서 나오나 — 오픈코어 모델과 그 경계선
Flux 2.9에 실제로 담긴 것
정직한 리스크 평가 — 남아 있는 것
도입자 입장에서 — 무엇을 확인하고 결정할까
마치며
참고 자료

들어가며 — "이 프로젝트의 미래는 위험한가?"

2024년 1월 14일, fluxcd/flux2 저장소에 이런 제목의 디스커션이 올라왔습니다 — "Is the project future at risk?". 본문은 짧고 직설적이었습니다. Weaveworks가 프로젝트 예산을 소진했고, Flux에 풀타임으로 일하던 개발자들이 다른 일자리를 찾거나 사비로 기여를 이어가야 할 판이라는 것. 다음 날 코어 메인테이너 Stefan Prodan이 직접 답했습니다 — "네, 정확한 상황입니다(Yes this is accurate)." 그리고 덧붙였습니다. 공식적인 응답을 곧 기대해 달라고.

몇 주 뒤 실제로 일어난 일은 더 나빴습니다. Flux를 만든 회사 Weaveworks가 2024년 2월 초 상업 운영을 중단한다고 발표한 것입니다. GitOps라는 용어를 만든 회사이자, Flux 메인테이너 대부분의 고용주가 사라졌습니다.

이 글은 그 후 2년 반 동안 실제로 일어난 일의 기록입니다. 계기는 2026년 6월 30일에 나온 Flux v2.9.0입니다 — 스폰서 붕괴 이후 여섯 번째 마이너 릴리스. "오픈소스 프로젝트가 기업 스폰서를 잃으면 죽는가?"라는 질문에 대해, Flux는 지금 시점에서 가장 데이터가 풍부한 사례 연구입니다. 추측 대신 릴리스 날짜, 메인테이너 명단, 공식 발표문 같은 1차 자료만으로 재구성해 보겠습니다.

타임라인 — 검증 가능한 사실만

날짜는 모두 공개 자료에서 직접 확인한 것입니다.

2022-11-30 — Flux, CNCF 졸업(Graduated) 프로젝트가 됨. 이때는 아무도 몰랐지만, 이 거버넌스 지위가 1년 뒤 생존에 결정적이었습니다.
2024-01-14 — 커뮤니티에서 "프로젝트 미래가 위험한가" 디스커션 제기. 다음 날 Stefan Prodan이 사실임을 인정.
2024년 2월 초 — Weaveworks 상업 운영 중단 발표(CNCF 발표문의 표현: "announced that it would cease commercial operations at the start of February").
2024-02-15 — 영국 보안 컨설팅사 ControlPlane이 코어 메인테이너 Stefan Prodan과 Soule Ba를 정직원으로 고용한다고 발표. 동시에 FIPS 준수 엔터프라이즈 Flux 배포판 사업을 시작.
2024-03-19 — CNCF가 KubeCon EU에서 Flux 지원 기업 명단을 발표. Aenix, Aviator, Microsoft Azure, ControlPlane, Edgecell, Fairwinds, Giant Swarm, Gimlet, GitLab, Nearform, OpsMx, OpsWorks, OSO, Teracloud, TNG — 15개사. Microsoft의 코멘트가 특히 실질적이었습니다: "Flux는 Azure의 여러 GitOps 경험을 구동하는 엔진이다(Flux is the engine that powers several GitOps experiences on Azure)."
2024-05-13 — 셧다운 이후 첫 마이너 릴리스 v2.3.0.
2026-06-30 — v2.9.0 릴리스. 셧다운 이후 여섯 번째 마이너.

여기서 눈여겨볼 대목이 있습니다. GitLab은 Weaveworks가 무너지기 전인 2023년 초에 이미 자사 Kubernetes 에이전트의 권장 GitOps 솔루션으로 Flux를 통합했고, Microsoft는 Azure(AKS의 GitOps 애드온)의 기반으로 쓰고 있었습니다. 즉 Flux는 "한 회사의 제품"이 아니라 이미 여러 대기업 제품의 부품이 되어 있었고, 그 의존이 구조 작업의 동기가 됐습니다. 프랑스 통신사 Orange도 CNCF 발표문에서 자사 텔코 네트워크의 GitOps 프레임워크가 Flux라고 못박았습니다.

릴리스 케이던스 실측 — 흔들렸지만 끊기지 않았다

"프로젝트가 살아 있는가"에 대한 가장 조작하기 어려운 지표는 릴리스 케이던스입니다. v2.0 GA부터 모든 마이너 릴리스의 날짜와 간격을 GitHub Releases에서 직접 뽑았습니다(같은 날짜를 endoflife.date가 독립적으로 확인해 줍니다).

버전	릴리스 날짜	직전 마이너와의 간격
v2.0.0	2023-07-05	— (GA)
v2.1.0	2023-08-24	50일
v2.2.0	2023-12-12	110일
v2.3.0	2024-05-13	153일 ← 셧다운 구간
v2.4.0	2024-09-30	140일
v2.5.0	2025-02-20	143일
v2.6.0	2025-05-29	98일
v2.7.0	2025-09-30	124일
v2.8.0	2026-02-24	147일
v2.9.0	2026-06-30	126일

읽어낼 수 있는 것:

가장 긴 공백(153일)은 정확히 셧다운을 관통하는 구간입니다. v2.2.0(2023년 12월)과 v2.3.0(2024년 5월) 사이 — 메인테이너들이 고용주를 잃고 새 둥지를 찾던 바로 그 기간입니다.
다만 그 최악의 구간도 다음으로 긴 간격(2.7→2.8의 147일)보다 겨우 6일 길 뿐입니다. 붕괴라기보다 "한 사이클 지연" 수준이었습니다.
연 단위로 보면 2023년 3개(2.0, 2.1, 2.2), 2024년 2개(2.3, 2.4), 2025년 3개(2.5, 2.6, 2.7), 2026년 상반기에만 2개(2.8, 2.9)입니다. Flux의 공식 릴리스 정책은 "최소한 Kubernetes와 같은 속도(연 3회 마이너)"를 표방하는데, 셧다운이 있던 2024년에만 이 목표에 못 미쳤고 2025년부터 회복했습니다.

숫자만 보면 "살아남았다"가 아니라 "거의 흔들리지도 않았다"에 가깝습니다. 하지만 이 매끄러운 표면 아래의 구조를 봐야 합니다.

지금 Flux는 누가 만드는가 — CORE-MAINTAINERS 파일 읽기

Flux 프로젝트의 CORE-MAINTAINERS 파일(2026년 7월 현재 기준)에는 9명이 올라 있습니다. 소속을 세어 보면:

ControlPlane 3명 — Stefan Prodan, Matheus Pimenta, Leigh Capili
SUSE 1명 — Paulo Gomes
NexHealth 1명 — Aurel Canciu
Associmates 1명 — Max Jonas Werner
무소속(Independent) 3명 — Hidde Beydals, Sanskar Jaiswal, Soule BA

두 가지가 눈에 띕니다.

첫째, 서류상으로는 다변화되어 있지만 활동량은 그렇지 않습니다. v2.9.0의 체인지로그를 열어 PR 목록을 훑어 보면, 기능 개발의 상당수가 Stefan Prodan과 Matheus Pimenta — 둘 다 ControlPlane 소속 — 의 손에서 나옵니다. CLI 플러그인 시스템(RFC-0013)의 제안과 구현 모두 Prodan입니다. 파일에 적힌 9명과, 실제로 로드맵을 끌고 가는 사람의 수는 다릅니다.

둘째, 고용 관계는 계속 움직입니다. 2024년 2월 ControlPlane에 함께 고용됐다고 발표된 Soule Ba는 2026년 7월 현재 파일상 무소속으로 표기돼 있습니다. "회사가 메인테이너를 고용했다"는 뉴스는 스냅샷일 뿐, 2년 뒤에도 그 구조가 유지된다는 보장은 없다는 걸 이 파일이 그대로 보여 줍니다.

돈은 어디서 나오나 — 오픈코어 모델과 그 경계선

Weaveworks의 실패에서 커뮤니티가 얻은 교훈은 "굿윌만으로는 풀타임 메인테이너를 유지할 수 없다"였습니다. 지금 Flux의 자금 구조는 크게 이렇게 요약됩니다.

업스트림은 CNCF 프로젝트로 남되, 상업 배포판이 메인테이너의 급여를 댑니다. ControlPlane은 Enterprise for Flux CD라는 이름으로 FIPS 준수 빌드, 구버전 호환, 24/7 지원을 파는 회사가 됐고, 그 매출로 메인테이너를 고용합니다. 이 경계선은 공식 릴리스 노트에도 명시적으로 등장합니다 — v2.9.0 릴리스 노트는 "Flux 프로젝트는 최신 3개 Kubernetes 마이너 버전만 지원하며, 더 오래된 Kubernetes와 OpenShift의 하위 호환은 ControlPlane 같은 벤더가 제공한다"고 적고 있습니다.

경계선의 위치를 구체적으로 확인해 두는 게 좋습니다. 업스트림(무료) 쪽은:

CLI와 컨트롤러의 최근 3개 마이너 릴리스 지원 — 단, 문서의 표현을 그대로 옮기면 백포트는 "커뮤니티가 최선 노력 기반으로(best-effort basis) 제공"합니다. SLA가 아닙니다.
최신 3개 Kubernetes 마이너 버전 호환(v2.9 기준 1.34/1.35/1.36).

상업(유료) 쪽은:

구버전 Kubernetes/OpenShift 호환 빌드, FIPS, 지원 계약.
Flux Operator — Flux 설치·수명주기를 관리하고 Web UI를 제공하는 오퍼레이터. 이건 CNCF Flux 프로젝트가 아니라 ControlPlane의 GitHub 조직(controlplaneio-fluxcd)에 있는 AGPL-3.0 프로젝트이고, 엔터프라이즈 배포판에는 상업 라이선스로 묶여 나갑니다.

이 구조를 비판하려는 게 아닙니다 — Weaveworks 방식(VC 자금으로 무료 개발을 보조)보다 정직하고 지속 가능해 보입니다. 다만 도입자는 "Flux"라고 부르는 것 안에 CNCF 거버넌스 아래 있는 부분과 한 회사의 제품인 부분이 섞여 있다는 걸 알고 선을 그어야 합니다. UI가 필요해서 Flux Operator에 기대기 시작하면, 그 부분은 CNCF가 아니라 ControlPlane의 지속성에 베팅하는 것입니다.

Flux 2.9에 실제로 담긴 것

거버넌스 이야기에서 벗어나, 릴리스 자체도 볼만합니다. v2.9.0 릴리스 노트와 공식 블로그 기준 주요 항목:

CLI 플러그인 시스템 — RFC-0013으로 제안된 kubectl/krew 스타일 확장. flux-<name> 실행 파일을 플러그인 디렉터리에 두면 flux <name> 서브커맨드가 됩니다. GitHub에 호스팅된 중앙 카탈로그에서 flux plugin install로 설치하고 SHA-256 체크섬을 검증합니다. 첫 플러그인은 Mirror(차트·OCI 아티팩트·이미지 레지스트리 미러링)와 Schema(JSON 스키마·CEL 규칙 기반 매니페스트 검증)입니다. 주의할 점: RFC 문서가 스스로 밝히듯 v1beta1에서는 체크섬 검증뿐, Cosign/SLSA 서명 검증은 없습니다. 그리고 Operator 플러그인은 Flux 프로젝트가 아니라 ControlPlane이 관리합니다 — 위에서 말한 경계선이 CLI 안까지 들어와 있는 셈입니다.
Server-Side Apply 필드 무시 규칙 — Kustomization에서 특정 관리 필드를 드리프트 감지에서 제외할 수 있습니다. HPA가 만지는 replicas 같은 필드 때문에 영원히 드리프트가 뜨던 고전적인 고통에 대한 공식 해법입니다.
SOPS의 Age 포스트퀀텀 암호 지원 — 시크릿 복호화 경로에 양자내성 암호 옵션이 들어왔습니다.
OpenBao/Vault의 Workload Identity 인증, SSH 키 기반 Git 커밋 서명·검증, 시크릿 없는 OIDC 웹훅 Receiver — 셋 다 "장기 보관되는 시크릿을 줄인다"는 같은 방향의 변화입니다.
Helm 포스트 렌더 전략과 차트 훅 지원, helm --set-literal에 해당하는 리터럴 값 모드.
API 제거 — image.toolkit.fluxcd.io/v1beta2와 notification.toolkit.fluxcd.io/v1beta2가 CRD에서 제거됐습니다. 이 구버전 API를 쓰고 있다면 업그레이드 전에 마이그레이션이 필요합니다.

기능 목록에서 읽히는 프로젝트의 방향은 뚜렷합니다 — 새 영역 확장보다 보안 체인(서명, 신원 기반 인증, 시크릿 제거)과 운영 엣지 케이스(드리프트, 훅, 모노레포)를 메우는 성숙기 릴리스입니다. 스폰서 붕괴 2년 뒤의 릴리스로는 건강한 모습입니다.

정직한 리스크 평가 — 남아 있는 것

살아남았다는 사실이 리스크가 사라졌다는 뜻은 아닙니다. 2026년 7월 시점에서 제가 보는 잔여 리스크:

단일 기업 집중이 형태를 바꿔 재현되고 있습니다. Weaveworks 시절의 문제는 "메인테이너 대부분이 한 회사 소속"이었습니다. 지금 코어 메인테이너 9명 중 ControlPlane 소속은 3명이지만, 커밋과 RFC의 무게중심은 그 3명 쪽에 있습니다. ControlPlane의 엔터프라이즈 사업이 흔들리면 같은 영화를 다시 보게 될 수 있습니다. 차이가 있다면 — 이번에는 Microsoft와 GitLab이 자사 제품의 부품으로 Flux를 쓰고 있어서, 최악의 경우에도 받아 줄 손이 더 많다는 점입니다.

"커뮤니티 best-effort"는 SLA가 아닙니다. 3개 마이너 지원·백포트 정책은 문서에 명시적으로 최선 노력 기반이라고 적혀 있습니다. 규제 산업에서 패치 보증이 필요하다면 결국 상업 계약으로 가게 되는데, 그 계약 상대는 사실상 한 곳입니다.

생태계 편중도 여전합니다. 같은 기간 Argo CD는 3.3.0(2026-02-02), 3.4.0(2026-05-05)을 내며 여러 벤더가 나눠 든 개발 체제를 유지하고 있습니다. 도구 선택 관점의 비교는 ArgoCD vs FluxCD 비교 글에서 다뤘으니 여기서는 반복하지 않겠습니다만, "메인테이너 고용 구조"라는 축에서는 두 프로젝트의 모양이 지금 꽤 다르다는 것만 짚어 둡니다.

UI·수명주기 관리 같은 편의 계층은 CNCF 바깥에 있습니다. 순수 업스트림 Flux는 여전히 CLI와 컨트롤러 묶음이고, 대시보드가 필요하면 ControlPlane의 Flux Operator(AGPL + 상업 라이선스)나 서드파티로 가야 합니다. Weave GitOps라는 무료 UI가 있던 시절보다 이 부분은 오히려 후퇴했습니다.

도입자 입장에서 — 무엇을 확인하고 결정할까

이 사례에서 얻을 수 있는 실무적 체크리스트를 정리하면:

의존하는 오픈소스의 메인테이너 고용 구조를 확인하십시오. MAINTAINERS 파일에 소속이 적혀 있는 프로젝트가 생각보다 많습니다. "CNCF 졸업 프로젝트냐"보다 "풀타임 기여자의 월급이 어디서 나오냐"가 더 예민한 선행 지표입니다. Flux가 살아남은 건 CNCF 거버넌스 덕이 절반, 대기업 제품들이 이미 부품으로 쓰고 있었던 덕이 절반입니다.
업스트림 지원 창을 운영 계획에 반영하십시오. Flux는 최근 3개 마이너만 지원하고 연 2~3회 마이너가 나옵니다. 대략 1년 안팎이면 지원 창에서 밀려난다는 뜻입니다. v2.9 릴리스와 함께 v2.6은 EOL이 됐습니다. "설치하고 잊는" 운영과는 양립하지 않습니다.
무료/유료 경계선 위에 있는 컴포넌트를 구분해 두십시오. CNCF Flux(CLI + 컨트롤러)와 ControlPlane 제품(Flux Operator, 구버전 호환 빌드)을 아키텍처 문서에서 다른 색으로 칠해 두면, 나중에 벤더 협상이나 리스크 평가가 훨씬 깨끗해집니다.
이미 Flux를 잘 쓰고 있다면 갈아탈 이유는 없습니다. 2024년의 공포가 무색하게 케이던스는 회복됐고, 2.9는 알맹이 있는 릴리스입니다. "Weaveworks가 망했으니 Flux는 위험하다"는 판단은 2026년 현재의 데이터와 맞지 않습니다.

마치며

2024년 1월의 "이 프로젝트의 미래는 위험한가?"라는 질문에 대한 2026년 7월의 답은 이렇게 정리할 수 있습니다 — 프로젝트는 위험하지 않았다. 다만 그 생존은 공짜가 아니라, 오픈코어 사업 모델과 대기업들의 제품 의존이라는 두 개의 기둥 위에 재건축된 것이다.

릴리스 간격 데이터가 보여 주듯 Flux는 최악의 구간에도 한 사이클 지연 정도로 버텼고, 지금은 정책 케이던스를 회복했습니다. 동시에 CORE-MAINTAINERS 파일과 릴리스 노트의 행간이 보여 주듯, 유지보수 동력의 무게중심은 여전히 한 회사에 쏠려 있습니다. 오픈소스 인프라의 지속 가능성이란 이렇게 — 극적인 사망 선고도, 완전한 해피엔딩도 아닌 — 구조와 돈의 문제로 계속 관리되는 것입니다. 도입 판단도 그 눈으로 하면 됩니다.