오픈소스 프로젝트
단순 프로젝트 목록이 아니라, 실제 Kubernetes 플랫폼·스토리지·데이터 플랫폼·로컬 AI 환경을 만들면서 반복해서 생긴 문제를 각 프로젝트가 어떻게 해결하는지 하나의 포트폴리오로 정리합니다.
프로젝트는 서로 독립적이지만, 사용 사례와 기술 경계로 연결됩니다.
OpenForge
│ engineering standards / supply-chain / reusable templates
│
├── kube-ready-box ──→ local Kubernetes node baseline
│ │
│ ├── Narwhal ──→ Narwhal Portal
│ │ │
│ │ ├── nfs-quota-agent
│ │ └── ldapium
│ │
│ └── Beluga ──→ Beluga Manager
│
└── KubeMetal ──→ Apple Silicon / host-native MLX MLOps이 관계도는 런타임 의존성을 의미하지 않습니다. 각 프로젝트는 독립 OSS로 유지되며, 공통의 engineering practice와 실제 사용 시나리오를 통해 연결됩니다.
OSS 프로젝트를 반복 가능하게 만들고, 로컬 Kubernetes 노드와 공급망 기준을 표준화하는 기반 프로젝트
OpenForge
오픈소스 프로젝트를 일관된 품질과 구조로 만들고 운영하기 위한 Blueprint, Engineering Standards 및 Reusable Templates
새로운 OSS 프로젝트를 시작할 때마다 Repository 구조, 문서, GitHub 워크플로, CI/CD, Supply Chain 보안, AI 개발 안전성, 변경 영향 분석, 릴리스 거버넌스 기준을 매번 처음부터 구성해야 함
실제 OSS 개발 및 운영 경험을 기반으로 표준화된 Blueprint, 29개 세부 Engineering Standards, 15개 영역의 Reusable Implementation Templates, Maturity Scorecard를 제공하여 일관되고 검증 가능한 엔지니어링 토대 구축
Kube-Ready-Box
Kubernetes를 위한 Ubuntu 24.04/26.04 LTS Vagrant Base Box · ARM64/AMD64 · ext4/XFS
로컬 Kubernetes 클러스터를 반복해서 만들 때 OS 튜닝, kernel modules, networking, storage prerequisites를 매번 준비해야 하고 ARM64/AMD64와 provider별 차이까지 별도로 관리해야 함
Packer로 Kubernetes용 Ubuntu base image를 사전 구성하고 Vagrant Cloud로 배포해 동일한 OS baseline을 여러 로컬 클러스터 프로젝트에서 반복 사용
Kubernetes 기반 플랫폼, 관리 포털, 스토리지 enforcement, directory infrastructure를 구성하는 프로젝트
Narwhal
재현 가능하고 검증 가능한 Kubernetes Internal Developer Platform
수십 개 Cloud Native 프로젝트를 개별적으로 설치하면 DNS, TLS, identity, networking, startup order, version compatibility 같은 integration seam에서 반복적인 장애가 발생하고 업그레이드 때 다시 검증해야 함
35개 GitOps-managed application을 하나의 reproducible IDP로 통합하고, 263건의 incident knowledge를 51개 CI regression checks와 live verification suite로 연결
Narwhal Portal
Narwhal Kubernetes Internal Developer Platform을 위한 운영·개발자 워크벤치
Kubernetes IDP를 구성하는 GitOps, SSO, 모니터링, 스토리지, 보안 컴포넌트는 각각의 UI를 제공하지만 플랫폼 전체 상태와 사용자 작업 흐름을 하나의 운영 화면에서 이해하기 어려움
Narwhal 클러스터의 상태·애플리케이션·노드·카탈로그·보안·비용·거버넌스 정보를 하나의 Next.js 기반 포털로 통합하고, 백엔드 API와 Kubernetes 환경을 통해 day-2 운영 경험을 단순화
NFS Quota Agent
NFS 기반 Kubernetes PersistentVolume에 파일시스템 수준 Project Quota를 적용하는 에이전트
Kubernetes의 NFS 기반 PersistentVolume은 PVC 용량이 파일시스템의 실제 사용량 제한으로 자동 연결되지 않아 하나의 워크로드가 공유 저장소를 소진할 수 있음
NFS 서버 노드에서 PV를 감시하고 파일시스템 Project Quota를 자동 적용해 XFS, ext4, Btrfs 환경에서 실제 저장공간 사용량을 강제
ldapium
업스트림 OpenLDAP 소스를 직접 빌드하는 Kubernetes 디렉터리 스택 · 서버 · 관리 UI · Helm
기존 OpenLDAP Kubernetes 이미지와 Helm 선택지의 오래된 버전, 비일관적인 패키징, 기본 credential 위험, ARM64/air-gap 지원 부족으로 유지 가능한 표준 배포 경로를 만들기 어려움
OpenLDAP 2.6.14를 업스트림 tarball에서 직접 빌드하고 zero-default-password 원칙, multi-arch 이미지, 관리 UI, Helm, backup/restore, offline bundle, SBOM/provenance를 하나의 프로젝트로 묶음
CDC부터 lakehouse, query, orchestration까지 데이터 lifecycle을 통합하고 운영하는 프로젝트
Beluga
로컬 Kubernetes에서 Kafka·CDC·Flink·Iceberg·Trino·Superset·Airflow를 통합하는 데이터 플랫폼
모던 데이터 플랫폼의 핵심 컴포넌트는 각각 쉽게 설치할 수 있지만 CDC, streaming, lakehouse, query, BI, orchestration의 경계를 로컬 환경에서 일관되게 연결하고 검증하기가 어려움
Vagrant와 k3s 위에 Helm·Argo CD GitOps로 전체 데이터 플랫폼을 재현하고, synthetic clickstream과 PostgreSQL CDC 두 가지 end-to-end 시나리오로 실제 동작을 검증
Beluga Manager
Beluga Data Platform의 여러 OSS를 Pipeline·Data Asset·Service·Operations 도메인으로 연결하는 통합 Control Plane
Kafka, Flink, Iceberg, Trino, Airflow가 각각 자신의 UI와 API 모델을 가지므로 데이터 파이프라인 전체의 상태와 관계를 확인하려면 여러 시스템을 직접 탐색해야 함
각 OSS를 새로운 source of truth로 복제하지 않고 authoritative API를 adapter로 연결해 Pipeline, Data Asset, Service, Operations라는 플랫폼 도메인으로 상관관계를 제공
Apple Silicon의 native compute와 Kubernetes control plane을 결합하는 로컬 MLOps 프로젝트
문서화 기준
각 프로젝트 페이지는 개요만 나열하지 않고 문제 정의, 설계 원칙, 아키텍처, 주요 기술, 운영 모델, 검증 방식, 현재 상태, 프로젝트 간 관계를 함께 설명합니다. 세부 문서는 Overview · Architecture · Getting Started · Operations · Troubleshooting · ADR 등 주제로 분리합니다.