프레임워크 하나 고르면 평생 묶여야 할까요?
웹 개발 프로젝트를 시작할 때 가장 부담스러운 결정이 뭐냐고 물어보면, 많은 분들이 '프레임워크 선택'을 꼽는데요. Next.js를 고르면 React 생태계에, Nuxt를 고르면 Vue 생태계에 사실상 묶이게 되거든요. 나중에 '아, Svelte가 더 잘 맞았을 것 같은데' 싶어도 갈아타는 비용이 너무 커서 그냥 참고 쓰는 경우가 많아요.
Primate는 바로 이 지점을 파고드는 프레임워크예요. 스스로를 폴리글랏(polyglot) 웹 프레임워크라고 부르는데, 폴리글랏이 뭐냐면 '여러 언어를 구사한다'는 뜻이에요. 이름 그대로 한 프로젝트 안에서 React, Vue, Svelte, Solid, HTMX 같은 프론트엔드 프레임워크를 섞어 쓸 수 있고, 서버 쪽 코드도 JavaScript나 TypeScript뿐 아니라 Go, Python 같은 다른 언어로 작성할 수 있게 해줘요. 실행 환경도 Node, Deno, Bun 중 어디서든 돌아가고요. 이런 독특한 프레임워크가 이번에 0.40 버전을 내놓으면서 라우트 페이지, 스토어 enum, 비동기 스키마, 이벤트 시스템이라는 네 가지 기능을 추가했어요.
이번 릴리스의 핵심 기능들
하나씩 풀어볼게요. 먼저 라우트 페이지인데요. Primate는 파일 기반 라우팅을 쓰는 프레임워크예요. routes 폴더에 파일을 만들면 그 경로가 곧 URL이 되는 방식이죠. 지금까지는 앱 전체가 공통 HTML 틀을 공유하는 구조였다면, 이제는 라우트 단위로 페이지를 직접 지정하고 다룰 수 있게 됐어요. 특정 경로만 완전히 다른 레이아웃이나 문서 구조를 갖게 하고 싶을 때 유용한 기능이에요. 랜딩 페이지와 관리자 페이지처럼 성격이 전혀 다른 화면을 한 앱에 담아야 할 때를 떠올리시면 돼요.
두 번째는 스토어 enum이에요. Primate에는 스토어(store)라는 데이터 계층 개념이 있는데, 이게 뭐냐면 데이터베이스 테이블의 구조를 코드로 정의해두는 장치예요. 이번에 여기에 enum 타입이 들어왔어요. enum은 '이 필드에는 정해진 값들만 들어올 수 있다'고 못 박는 타입인데요. 예를 들어 주문 상태 필드에 pending, paid, shipped 세 가지만 허용하고 싶을 때, 그냥 문자열로 받으면 오타 하나로 데이터가 오염되지만 enum으로 선언해두면 프레임워크 차원에서 걸러주는 거죠.
세 번째 비동기 스키마도 실무에서 반가운 기능이에요. 스키마 검증이 뭐냐면 사용자가 보낸 데이터가 올바른 형태인지 확인하는 절차인데요. 지금까지 많은 검증 도구들이 동기 방식만 지원해서, '이 이메일이 이미 가입돼 있는지 DB에 물어보고 판단하기' 같은 검증은 스키마 바깥에서 따로 처리해야 했어요. 검증 함수 안에서 await를 쓸 수 있게 되면 이런 로직을 검증 단계 안에 자연스럽게 넣을 수 있게 돼요. Zod 같은 검증 라이브러리들이 비동기 검증을 지원해온 것과 같은 흐름이에요.
마지막으로 이벤트 시스템이 추가됐어요. 앱 안에서 '회원 가입이 일어났다' 같은 사건을 발행하고, 다른 코드가 그걸 구독해서 반응하는 구조를 만들 수 있는 건데요. 가입 처리 코드 안에 이메일 발송, 통계 기록까지 전부 욱여넣는 대신, 사건만 던지고 각자 알아서 반응하게 분리할 수 있어서 코드가 훨씬 깔끔해져요.
비슷한 시도들과 비교하면
'여러 프론트엔드 프레임워크를 섞는다'는 아이디어 자체는 Astro가 먼저 대중화했어요. Astro도 한 페이지 안에 React 컴포넌트와 Svelte 컴포넌트를 나란히 놓을 수 있거든요. 다만 Astro가 콘텐츠 중심 사이트에 초점을 맞춘 반면, Primate는 백엔드까지 폴리글랏으로 가져간다는 점이 달라요. 서버 라우트를 Go로 짜고 화면은 Vue로 그리는 조합이 가능한 프레임워크는 흔치 않죠. 반대로 Next.js나 SvelteKit 같은 주류 프레임워크들은 단일 스택에 깊게 통합해서 최적화하는 방향으로 가고 있으니, Primate는 그 반대편 극단에서 실험을 하고 있는 셈이에요.
우리에게 어떤 의미일까요
솔직히 말씀드리면 Primate는 아직 0.x 버전이라 프로덕션에 바로 올리기엔 이른 감이 있어요. 버전 번호가 1.0 미만이라는 건 API가 언제든 바뀔 수 있다는 뜻이거든요. 하지만 배워둘 가치는 충분하다고 봐요. 특히 레거시 프론트엔드를 점진적으로 다른 프레임워크로 옮겨야 하는 상황이나, 팀마다 선호 스택이 다른 조직에서는 이런 접근이 하나의 참고 모델이 될 수 있어요. 그리고 스토어 enum이나 비동기 스키마 같은 기능은 프레임워크와 무관하게 '데이터 검증을 어디서 어떻게 할 것인가'라는 보편적인 설계 질문을 다시 생각하게 해주고요.
정리하면
Primate 0.40은 '프레임워크 선택을 돌이킬 수 없는 결정으로 만들지 말자'는 철학을 데이터 계층과 이벤트까지 확장한 릴리스예요. 여러분은 어떠세요? 한 프로젝트에서 여러 프레임워크를 섞어 쓸 수 있다면 실제로 써보고 싶으신가요, 아니면 오히려 관리 복잡도만 올라갈 것 같나요? 댓글로 의견 나눠주세요.
🔗 출처: Hacker News