시스템을 만들고,
계속 관찰하며 발전시킵니다.
아키텍처는 시작점일 뿐입니다. Commit, Release, Regression, Incident와 운영 과정에서 나온 지식까지 연결해 시스템이 어떻게 발전하는지 보여줍니다.
Standards → Baseline → Platform → Capabilities → Workloads
The map is intentionally read top-to-bottom on mobile: engineering rules create a reproducible baseline, the platform integrates shared capabilities, and workloads expose the seams that need verification.
관찰 중인 시스템
각 시스템에서 문제, 아키텍처, 주요 결정, Development Pulse, 검증 근거와 교훈을 함께 볼 수 있습니다.
All systems코드 생성이나 merge가 아니라 resolved invocation, CI, runtime evidence, post-state verification, portfolio status까지 연결해 OSS 변경의 완료를 증명한 OpenForge 적용 기록
Narwhal, Narwhal Portal, NFS Quota Agent, ldapium, kube-ready-box, ClusterDeck, Beluga, Beluga Manager, KubeMetal, OpenForge의 실제 소스와 문서 상태를 다시 검토하고, 문서 수가 아니라 Time to First Verified Success 중심으로 adoption journey를 재설계한 기록입니다.
Narwhal, NFS Quota Agent, KubeMetal, ldapium, OpenForge의 2026년 8월 현재 구현 상태를 실제 main과 검증 근거 기준으로 다시 정리했다.
여러 OSS의 공통 표준을 OpenForge로 관리하면서 ADR을 도입한 이유와 ADR → Standard → Automation → Adoption 구조를 정리합니다.
판단 기준이 어떻게 변해왔는가
Framework → DevOps → Cloud Native → Platform → OSS → AI-assisted engineering. 기술은 바뀌었지만, 운영 원칙은 더 명확해졌습니다.