dasomel
EN
STORY / ENGINEERING EVOLUTION

도구는 바뀌었고,
판단 기준은 더 선명해졌습니다.

이 Story는 경력 홍보보다 어떤 제약·시스템·의사결정·검증 경험이 엔지니어링 판단을 바꿨는지 따라가는 timeline입니다.

CONTEXTOSS를 만드는 이유는 Why OSS에서, 실제 개발 지속성과 릴리스·활동 신호는 Evidence에서 확인할 수 있습니다.Why OSS →Evidence →
01 / Framework→02 / DevOps→03 / Cloud Native→04 / Platform→05 / OSS→06 / AI-assisted Engineering
OSS STORY01 / 08
01OPEN SOURCE ENGINEERING

OSS는 저장소가 아니라 시스템입니다.

Repository는 결과가 보이는 표면일 뿐입니다. 문제 정의부터 재현 가능한 기반, 통합, 검증, 문서화, 피드백까지 연결되어야 Engineering이 됩니다.

01Problem왜 만드는가 · 반복되는 운영 문제
02Standards어떻게 만들까 · 구조 · docs · CI
03Build작동하게 · working slice
04Verify증명하기 · 통합 · 회귀 · 재현성
05Share다시 쓰게 · release · lesson
핵심좋은 OSS는 기능뿐 아니라 왜 존재하는지, 다른 엔지니어가 어떻게 다시 검증할 수 있는지까지 설명합니다.
위로 넘겨 다음 장면
02SIGNALS

왜 지금 OSS Engineering인가

Kubernetes와 AI가 인프라의 기본 선택지가 될수록 “무엇을 설치했는가”보다 “서로 얼마나 안정적으로 연결되는가”가 차이를 만듭니다.

82%
Kubernetes production

Cloud Native → production infrastructure

66%
GenAI inference on K8s

AI workload ↔ platform engineering

~1B
OSS / public contributions

public engineering artifacts at scale

핵심이제 어려운 문제는 설치 자체보다 통합된 시스템을 설명 가능하고 반복 가능하게 만드는 것입니다.
위로 넘겨 다음 장면
03COMPLEXITY MAP

복잡성은 기술 수가 아니라 경계에서 생깁니다.

실제 운영 문제는 한 제품 내부보다 Identity·Network·Storage·Delivery가 만나는 경계에서 더 자주 드러납니다.

ExperiencePortal / API
DeliveryGitOps / CI
PlatformKubernetes / Mesh
FoundationNode / Network / Storage
IDENTITYSSO ↔ RBAC
NETWORKIngress ↔ Mesh
STORAGEPVC ↔ Backend
DELIVERYGit ↔ Runtime
핵심검증도 개별 제품보다 인증 흐름, 트래픽 경로, 데이터 영속성, Git→Runtime seam에 집중합니다.
위로 넘겨 다음 장면
04GOVERNANCE

코드만으로 지속 가능한 OSS가 되지는 않습니다.

Release, dependency, security, documentation 규칙을 구현과 함께 설계해야 다른 사람이 반복해서 사용할 수 있는 프로젝트가 됩니다.

LICENSELicense / NOTICE

사용·배포 조건

RELEASETag / Pin / Artifact

재현 가능한 버전

SECURITYReview / Scan / Verify

dependency · supply chain

DOCSState / ADR / Guide

판단 · 상태 · 사용법

핵심Governance는 첫 성공 이후에도 프로젝트를 재사용 가능하게 유지하는 장치입니다.
위로 넘겨 다음 장면
05ENGINEERING LOOP

Build → Verify → Learn → Share

기능 구현은 중간 지점입니다. 통합 검증, evidence, 의사결정 기록과 실패에서 얻은 lesson까지 남겨야 다음 iteration이 좋아집니다.

01Define

problem + criteria

02Build

working slice

03Integrate

real boundaries

04Verify

automated checks

05Document

decision + state

06Share

release + lesson

핵심통합 실패도 원인이 다음 release의 check·문서·기본값으로 남는다면 Engineering 자산이 됩니다.
위로 넘겨 다음 장면
06SYSTEM ARCHITECTURE

하나의 Workbench, 서로 다른 역할

각 프로젝트는 특정 문제를 독립적으로 해결하지만 전체로 보면 재사용 가능한 Cloud Native engineering system을 구성합니다.

STANDARDSOpenForge
OSS blueprint
↓
BASELINEkube-ready-box
repeatable environment
↓
PLATFORMNarwhal + Portal
IDP · GitOps · SSO · Observability
↓
CAPABILITYldapium · quota · Beluga · KubeMetal
핵심각 capability는 독립적으로 발전시키되 같은 Engineering 규칙 안에서 다시 조합할 수 있도록 분리합니다.
위로 넘겨 다음 장면
07ENGINEERING EVIDENCE

Evidence가 Engineering을 설명합니다.

자동 검증, integration lesson, 재현 가능한 환경을 남기면 “동작한다”는 주장을 다른 사람도 다시 확인할 수 있습니다.

35
Narwhal GitOps apps

platform breadth

51
CI regression checks

repeatable verification

263
integration / incident lessons

operational learning

핵심숫자보다 중요한 것은 그 뒤에 manifests, tests, automation, lesson처럼 직접 확인 가능한 산출물이 있다는 점입니다.
위로 넘겨 다음 장면
08OSS WORKBENCH MAP

포트폴리오가 아니라 하나의 Workbench

각 Repository는 실험이자 재사용 가능한 building block이며, 실제 통합에서 살아남은 판단을 기록하는 공간입니다.

StandardsOpenForge

OSS 시작 규칙 · docs · CI/CD

OPEN →Baselinekube-ready-box

재현 가능한 K8s 기반

OPEN →PlatformNarwhal

Kubernetes IDP · GitOps · SSO

OPEN →ExperienceNarwhal Portal

developer self-service

OPEN →Storagenfs-quota-agent

NFS PV project quota

OPEN →Identityldapium

LDAP identity service

OPEN →DataBeluga

Cloud Native data platform

OPEN →AI / EdgeKubeMetal

Apple Silicon local MLOps

OPEN →
핵심공통된 기준은 실제로 만들고, 경계를 검증하고, 살아남은 판단을 공개하는 것입니다.
STORY END · 계속 만드는 중