WHY OSS / ENGINEERING PRACTICE

왜 OSS를
계속 만드는가?

목표는 저장소 수를 늘리는 것이 아닙니다. 실제 플랫폼 문제를 재현 가능한 시스템으로 만들고, 검증하고, 그 과정에서 얻은 판단과 기준을 다시 사용할 수 있게 남기기 위해 OSS를 만듭니다.

출발점

기능보다 경계가 살아남아야 합니다.

Platform Engineering의 문제는 하나의 도구 안에서 끝나지 않습니다. Identity와 RBAC, Git과 Runtime, PVC와 Storage, Ingress와 Service Mesh 사이의 경계에서 실제 문제가 생깁니다.

OSS로 만들면 이 경계를 공개적으로 확인할 수 있습니다. 코드를 검토할 수 있고, 환경을 재현할 수 있으며, 실패를 기록하고, 설계 판단이 시간에 따라 어떻게 바뀌었는지도 남길 수 있습니다.

ENGINEERING LOOP
01
Problem

실제 운영 문제에서 시작합니다.

02
Build

설명보다 재현 가능한 구현을 남깁니다.

03
Verify

통합 경계와 실패 지점을 반복 검증합니다.

04
Evolve

릴리스와 변경 이력을 통해 계속 발전시킵니다.

05
Share

문서와 기준을 다시 사용할 수 있는 형태로 공개합니다.

설계 원칙

무엇을 최적화하는가

Star 수, 저장소 수, 기술 개수보다 오래 남는 engineering evidence를 우선합니다.

Evidence 측정 기준 보기 →
Reproducible

다른 사람도 같은 환경을 다시 만들 수 있어야 합니다.

Observable

성공과 실패를 확인할 수 있는 신호가 있어야 합니다.

Evolvable

Commit과 Release로 변화가 시간축에 남아야 합니다.

Reusable

한 저장소의 교훈이 다른 프로젝트에서도 재사용되어야 합니다.

Standards

OpenForge

반복되는 OSS 의사결정을 재사용 가능한 표준으로 정리합니다.

Platform

Narwhal

Identity, Delivery, Network, Observability, Storage를 하나의 시스템으로 통합하고 검증합니다.

Workloads

Beluga · KubeMetal

Data와 AI/Edge workload 제약을 통해 플랫폼을 다시 검증합니다.

두 페이지의 역할을 분리합니다

Why OSS는 이유를, Story는 변화 과정을 설명합니다.

Framework에서 DevOps, Cloud Native, Platform, OSS, AI-assisted Engineering으로 판단 기준이 어떻게 바뀌었는지는 Engineering Story에서 이어집니다.