왜 나는 ElysianDB를 만들었는가
Source: Dev.to
초기 백엔드 결정의 문제점
대부분의 프로젝트는 아이디어 부족 때문에 실패하지 않습니다.
구조적인 이유 때문에 속도가 느려집니다: 백엔드 결정이 너무 일찍 이루어지거나, 아무도 진정으로 신뢰하지 않는 목업 뒤에 미뤄지기 때문입니다.
프로젝트 초기에 팀은 모멘텀을 원합니다. 기능을 탐색하고, 사용자 흐름을 검증하며, 빠르게 반복하고 싶습니다. 하지만 인증, 권한, 관계가 등장하자마자 무너지는 취약한 목업이 아니라, 실제 시스템처럼 동작하는 백엔드가 필요합니다. 또한 아직 거의 존재하지 않는 제품에 대해 지나치게 가정하는 완전 설계된 아키텍처도 원하지 않습니다.
이러한 긴장은 흔하고 비용이 많이 듭니다:
- 목업은 보증이 없는 백엔드와 닮을 때까지 커집니다.
- 실제 구현은 나중에 잘못된 것으로 판명되는 제약 조건으로 시작되는 경우가 많습니다.
두 경우 모두 팀은 만든 부분을 크게 다시 작성하게 됩니다. 처음부터 지속될 의도가 없었거나, 너무 일찍 설계되었기 때문입니다.
ElysianDB 소개
ElysianDB는 그 격차에서 탄생했습니다. 이 프로젝트는 Go로 작성되었으며 간단한 아이디어를 중심으로 구축되었습니다: 팀이 제품이 명확해질 때까지 아키텍처 결정을 고정하지 않고, 첫 날부터 실제 백엔드로 시작할 수 있게 하는 것입니다.
즉시 사용 가능
- 원시 JSON에서 시작합니다.
- 즉시 사용 가능한 API로 문서를 저장합니다.
- 스캐폴딩 없이 CRUD 엔드포인트를 제공합니다.
- 쿼리는 실제이며, 영속성도 실제이며, 인증 및 접근 제어가 처음부터 적용됩니다.
- 프론트엔드는 자리표시자가 아닌 실제 시스템과 통신합니다.
조기 최적화보다 연속성
프로젝트 초기에 ElysianDB는 빠르고 가벼운 내부 스토리지 엔진에 의존합니다. 이는 빠른 반복, 최소 설정, 낮은 마찰을 위해 설계되었습니다. 이 단계에서의 우선순위는 피드백 속도와 안전하게 방향을 바꿀 수 있는 능력이며, 최대 내구성이나 수평 확장성은 아닙니다.
프로젝트가 진행됨에 따라:
- 데이터가 증가합니다.
- 신뢰성이 중요해집니다.
백엔드를 재설계하거나 API를 마이그레이션하는 대신, ElysianDB는 스토리지 레이어가 진화하도록 허용합니다. 설정을 전환하면 동일한 API를 MongoDB 위에서 실행할 수 있습니다. 엔드포인트는 동일하게 유지되고, 계약은 안정적이며, 프론트엔드는 조정할 필요가 없습니다. 시스템은 이미 구축된 것을 깨뜨리지 않고 성장합니다.
동작 및 권한 관리
ElysianDB는 훅(hooks) 과 액세스 제어 리스트(ACLs) 를 통해 동적 동작과 보안을 다룹니다.
훅(Hooks)
- JavaScript 로 작성됩니다.
- 읽기 시점에 실행됩니다.
- 저장된 문서를 변형하거나 비즈니스 로직을 너무 일찍 삽입하지 않고도 데이터를 동적으로 풍부하게 하거나 변환할 수 있습니다.
ACLs
- 권한을 명시적으로 정의합니다.
- 일관되게 적용하여 출시 후에 보안을 뒤늦게 추가하는 일을 방지합니다.
두 기능 모두 웹 기반 관리 인터페이스를 통해 관리되며, 시스템이 진화함에 따라 복잡성을 가시화하고 조정할 수 있습니다.
현재 상태
ElysianDB는 아직 활발히 개발 중입니다. 완전하고 포괄적인 백엔드 솔루션이라 주장하지 않으며, 아직 성숙하지도 않았습니다. 그 목적은 복잡성이 존재하지 않는다고 가장하지 않고 백엔드 마찰을 줄이는 것입니다.
- 신중하게 설계된 도메인‑주도 시스템을 대체하는 것이 아닙니다.
- 대형 백엔드 플랫폼과 경쟁하는 것이 아닙니다.
- 목표: 초기 단계에서 신뢰할 수 있는 백엔드를 제공하고, 프로젝트가 성장함에 따라 정직하게 유지하며, 정당화될 때까지 되돌릴 수 없는 결정을 미루는 것입니다.
행동 요청
이러한 방식의 구축이 마음에 든다면, 여러분이 ElysianDB를 어디에 사용하고 어디에 사용하지 않을지 알려주시면 정말 감사하겠습니다.