왜 벨노라가 존재하는가 — 집착 이전의 침묵
Source: Dev.to
Background
오랫동안 나는 Docker, Kubernetes, CI와 같은 복잡성을 다스리겠다는 도구들에 초점을 맞춰 글을 써 왔습니다.
그리고 처음엔 정말 그렇게 되었습니다.
- 배포 파이프라인이 불안정한 스크립트를 대체했습니다.
- 컨테이너가 눈에 띄는 서버들을 대체했습니다.
- 인프라가 재현 가능해졌습니다.
하지만 더 깊이 파고들수록 뭔가 어색함을 느꼈습니다.
우리는 복잡성을 없애는 것이 아니라,
그 복잡성을 위로 옮기고 있었습니다.
프론트엔드 개발에서는 순수 HTML/CSS/JS가 React, Angular, Vue 같은 프레임워크로 대체되었습니다. 코드베이스는 깔끔해졌지만, 애플리케이션은 무거워졌습니다—도구가 더 많아지고, 설정이 늘어나고, 레이어가 추가되었습니다.
같은 패턴이 인프라에서도 나타났습니다.
내가 마스터한 각 레이어—컨테이너, 클러스터, 파이프라인—가 혼돈을 다른 곳으로 옮겼습니다:
- 배포를 고치면 → 통합이 깨짐
- 컨테이너를 고치면 → 설정이 폭발함
- 설정을 고치면 → 관측이 고통스러워짐
그때 침묵이 시작되었습니다.
나는 막힌 것이 아니라, 조사하고 있었습니다.
모든 것을 시작하게 만든 거부된 프로젝트
나는 “작동한다”는 말에 절대 만족하지 못한다.
Docker에 대해 글을 쓸 때, 나는 단순히 사용한 것이 아니라 실제 작동 방식을 파헤쳤다. 그 본능 때문에 나는 거의 2년 동안 블로깅을 떠나게 되었다.
간단한 답변만으로는 충분하지 않게 되었다.
우리 도구는 계속 개선되는데도 왜 소프트웨어를 만드는 것이 매년 더 무겁게 느껴졌을까?
그것은 거대한 아키텍처 비전으로 시작된 것이 아니다. 거절당한 졸업 프로젝트에서 시작되었다.
석사 과정 중에 나는 맞춤 번들러를 만들자고 제안했다. 교수님들은 받아들이지 않으셨다—아마도 너무 야심 차거나 범위가 넓었기 때문일 것이다. 그래서 나는 스스로 계속 진행했다.
현대 툴링이 실제로 어떻게 작동하는지 이해하려고 Vite를 다시 만들려고 시도했다. 그때 현실이 다가왔다:
번들러는 단순히 복잡한 것이 아니다. 무한히 깊다.
나는 문제를 다시 정의했다. Vite를 대체하는 대신, 나는 이렇게 물었다:
- 만약 내가 그 위에 구축한다면?
- 일반적으로 별개의 영역에 존재하는 Angular와 NestJS라는 두 프레임워크가 하나의 빌드 파이프라인을 공유한다면 어떨까?
나는 엔진이 되려는 시도를 멈추고, 접착제 역할을 하기 시작했다.
Source: …
Walking Away—and Coming Back Different
Obsession is rarely linear.
There were months when the glue didn’t stick. I convinced myself I had solved the problem—until I saw how much complexity still sat underneath. Tooling fighting tooling. Layers stacked on layers.
I stepped away. Went back to writing safer DevOps posts. Tried to convince myself that the industry stack was good enough. But the satisfaction was gone. The feedback felt quiet, like I was contributing noise instead of signal.
That’s when I realized something:
If I didn’t build this, I would spend my career managing complexity instead of removing it.
So I closed the blog, stopped chasing validation, and went back to code—this time with a different question:
- Why is DevOps a separate phase at all?
- Why does every project require developers to leave business logic behind just to configure Dockerfiles, pipelines, manifests?
Every time we do that, we’re not solving a user problem. We’re solving the computer’s.
That was the pivot.
What if infrastructure became a side effect of writing software?
What if a system understood your code deeply enough to generate containers, configs, and CI pipelines automatically?
In December 2024, I pushed the first commit. That was the real beginning.
떠나고, 다른 모습으로 돌아오다
집착은 드물게 직선적이다.
접착제가 제대로 붙지 않았던 몇 달이 있었다. 나는 문제를 해결했다고 스스로 설득했지만, 그 아래에 아직도 복잡성이 얼마나 남아 있는지 보게 되었다. 도구가 도구와 싸우고, 층이 층을 이루었다.
나는 물러섰다. 더 안전한 DevOps 글을 쓰기 시작했다. 산업 스택이 충분히 좋다고 스스로 설득하려 했지만, 만족감은 사라졌다. 피드백은 조용했으며, 나는 신호가 아닌 잡음만 내고 있는 느낌이었다.
그때 나는 깨달았다:
내가 이것을 만들지 않았다면, 복잡성을 제거하는 대신 관리하는 데 내 경력을 보냈을 것이다.
그래서 블로그를 닫고, 검증을 쫓는 것을 멈추고 다시 코딩으로 돌아갔다—이번엔 다른 질문을 가지고:
- 왜 DevOps가 별도의 단계가 되어야 할까?
- 왜 모든 프로젝트에서 개발자들이 비즈니스 로직을 뒤로하고 Dockerfile, 파이프라인, 매니페스트를 설정해야 할까?
우리가 그렇게 할 때마다 해결하는 것은 사용자 문제가 아니라 컴퓨터 문제이다.
그것이 전환점이었다.
인프라가 소프트웨어를 작성하는 부수 효과가 된다면 어떨까?
시스템이 코드를 충분히 깊이 이해해서 컨테이너, 설정 파일, CI 파이프라인을 자동으로 생성한다면 어떨까?
2024년 12월, 나는 첫 커밋을 푸시했다. 그것이 진정한 시작이었다.
Velnora란?
아키텍처에 들어가기 전에 고백 하나. 이 프로젝트는 항상 Velnora라고 불린 것은 아니었습니다. 원래는 Fluxora라는 이름이었죠. 들었을 때… 괜찮아 보였습니다. 너무 괜찮아서—다른 상태 관리 라이브러리와 비슷했거든요. 여기서는 상태가 아니라 오케스트레이션, 속도, 시스템 사고에 관한 것이었습니다. 그래서 Velnora가 탄생했습니다.
Velnora는 시스템을 위한 메타‑프레임워크입니다.
- React가 컴포넌트의 라이프사이클—마운트, 업데이트, 언마운트—을 관리한다면
- Velnora는 애플리케이션의 라이프사이클을 관리합니다: Resolve → Build → Deploy → Run.
프레임워크 위에, 인프라 아래에 위치합니다:
React / Angular / NestJS
↓
Velnora (meta‑framework)
↓
Docker / Kubernetes핵심은 계층형 플러그인 아키텍처입니다. 커널은 그래프와 라이프사이클을 이해합니다. 그 외의 모든 것—TypeScript 컴파일, 개발 서버, 클라우드 타깃—은 어댑터를 통해 구현됩니다. 현재는 Vite와 연동되고, 내일은? 또 다른 것이 될 수도 있습니다.
Velnora는 모노레포를 의존성 트리로 변환하고, 생태계 전반에 걸쳐 빌드를 통합하며, 인프라를 자동으로 생성합니다. 이 레이어가 구축되면 우리는 더 이상 글루 코드를 작성하지 않고 플랫폼을 구축하기 시작합니다.
여기가 기원 이야기가 끝나는 지점입니다. 이제 진짜 작업이 시작됩니다: 아키텍처, 오케스트레이션 엔진, 그리고 핵심 런타임에 대한 깊은 탐구.
아이디어를 가져오세요. 비판을 가져오세요. 소프트웨어 구축을 더 무겁게가 아니라 가볍게 만들어요.