Nuxt Ignis, 재탄생

Source: Dev.to

Dev.to 에서는 정기적으로 “이번 주에 당신이 이룬 성과는 무엇인가요?” 라는 토론이 있습니다. 이번 주 제 성과는 단연 “오픈소스 Nuxt 프로젝트의 새로운 버전을 완성하고 배포했습니다” 라는 것이었습니다. 이제 소개해 드리겠습니다.

What is it and why should you care?

Nuxt(https://nuxt.com/)에 푹 빠졌습니다. 제가 아는 한 현대 웹사이트를 만들기에 가장 뛰어난 프레임워크이며, 작업하면서 느끼는 만족감이 커서 대안을 찾는 데 시간을 쓰고 싶지 않아요. 물론 여러분이 좋아하는 다른 솔루션을 옹호할 수도 있겠지만, 제가 귀 기울일 가능성은 낮습니다. 더 알고 싶다면, 제가 진행 중인 튜토리얼 시리즈를 확인해 보세요.

하지만 한 가지 문제점이 있었습니다. Nuxt 코어는 (의도적으로) 작게 설계돼 있어 흔히 쓰이는 작업들을 수행하려면 외부 도구와 라이브러리를 별도로 추가해야 합니다. Nuxt 팀은 이런 도구들을 쉽게 통합할 수 있게 했지만, 실제로 통합하는 작업은 개발자가 해야 합니다. 이제 여러 프로젝트를 운영하면서 각각 수십 개 이상의 의존성을 관리하고 있다고 상상해 보세요. 그리고 dependabot이 계속 업데이트를 외치고 있습니다. 한 번이 아니라 여러 번, 밤새 새로운 취약점이 발견되고 다음 날 또 다른 문제가 찾아오는 상황이죠…

이런 상황에 지치자 최적화 방안을 고민하기 시작했습니다.

하나의 npm 패키지만 의존하면 모든 것이 해결된다면 어떨까요? 데이터베이스 커넥터, UI 라이브러리, 폼, 검증 등 필요한 모든 것이 한 곳에…

하지만 저는 모든 것을 한 방식에 고정시키는 opinioned 솔루션을 만들고 싶지는 않았습니다. 대신 Nuxt Ignis는 옵션화된(optionated, 이게 단어가 맞는지는 모르겠지만) 솔루션이 되길 원했습니다. 검증된 베스트 프랙티스와 트렌드에 기반한 합리적인 기본값을 제공하되, 사용자가 자유롭게 조합을 바꿀 수 있어야 합니다.

그럼 어떻게 구현할까요?

How I started and how I nearly failed

Nuxt와 재사용 가능한 통합을 만들 때 가장 흔히 쓰이는 방법은 모듈이라는 기능을 이용하는 것입니다. Nuxt 모듈은 서드파티 도구를 Nuxt 앱에 연결해 주는 통합 API 역할을 하며, 기본적으로 nuxt.config.ts 파일에 어떤 모듈을 활성화할지 선언하면 됩니다.

따라서 모듈 목록을 동적으로 구성하고 설정에 따라 달라지게 하면, 애플리케이션을 0~N개의 통합을 감싸는 동적 래퍼로 만들 수 있습니다. 하지만 한계가 있습니다. nuxt.config.ts 내용은 빌드 시점에 정적이어야 합니다. Vite는 Nuxt 앱을 원하는 대로 빌드하지만, 빌드가 끝난 뒤에는 다시 빌드할 수 없습니다. 바로 그 점이 문제였습니다!

몇 차례 실험 끝에 우회 방법을 찾아냈습니다. 저는 Nuxt Ignis를 레이어로 선언했습니다. 레이어는 상속과 같은 동작을 제공하는 멋진 Nuxt 기능입니다. 프로젝트는 nuxt-ignis 레이어를 확장해 선언된 내용을 재사용하고, 빌드는 여러분이 원할 때 여러분의 머신(또는 프로덕션)에서 이루어집니다. 이제 문제는 nuxt.config.ts를 직접 손으로 일일이 작성하지 않고도 어떻게 바꿀 수 있느냐였습니다.

여기서 해결책이 나왔습니다. nuxt.config.ts 안의 defineNuxtConfig 헬퍼는 객체를 인자로 받습니다. 보통은 정적인 객체를 바로 넣지만, 함수의 반환값을 넘겨도 됩니다. 이 함수는 Nuxt가 defineNuxtConfig를 실행할 때 자동으로 호출됩니다. Node.js(또는 다른 JS 런타임) 환경이므로 process.env에 접근할 수 있고, 환경 변수를 읽어 정적 설정 객체를 동적으로 만들 수 있습니다.

저는 setFeatures라는 함수를 만들었습니다. 마지막 버전은 다음과 같습니다: Nuxt Ignis’ features.ts (v0.5.3)

이 함수는 제 역할을 완벽히 수행했습니다. Nuxt UI가 필요하면 Nuxt UI를, Supabase가 필요하면 Supabase를, 아무것도 원하지 않으면 거의 순수 Nuxt를, 모든 것을 원하면 전부를 제공했죠.

하지만 곧 문제가 발생했습니다. 기대했던 솔루션이 스스로를 얽히기 시작한 겁니다. 의존성이 늘어나면서 번들 크기가 커지고, 빌드 시간이 늘어나며, 개발 서버가 시작되는 대기 시간이 점점 길어졌습니다. 아직 25개의 통합 정도였지만, 저는 더 많은 것을 계획하고 있었습니다.

Back to the drawing board

Nuxt Ignis v0.5.3을 사용하고 있는 웹사이트가 여섯 개 있었고, 큰 문제 없이 동작했습니다. 여기서 세 개를 확인해 보시면 감이 오실 겁니다. 하지만 성능이 만족스럽지 않았습니다. 개발 경험(DevEx)이 떨어지면 잠재 사용자에게도 큰 타격이 될 테니까요. 한동안은 어떻게 해야 할지 몰라 프로젝트를 포기할까 고민하기도 했습니다. 좋은 사고 실험이었지만 현실적인 막다른 길이었죠.

그때 작년 PragVue 컨퍼런스에서 만난 한 분이 제게 큰 힌트를 주었습니다(2026년 행사는 현재 준비 중이며, 여러분도 꼭 참여해 주세요). 그분은 “Nuxt 모듈을 활용하면 설정을 더 편리하게 할 수 있다”는 아이디어를 제시했습니다.

몇 주간 아이디어를 구체화하고, 실험하고, 구현하면서 모든 것을 부수고 다시 조립하는 과정을 반복했습니다.

※ 부가 설명 - 이 과정에서 AI(Copilot)의 도움이 큰 힘이 되었습니다. 제가 가고자 하는 방향은 알았지만, 실제 구현은 Claude Opus를 탑재한 Copilot이 대부분의 문서와 소스 코드를 파고들어 무거운 작업을 대신해 주었습니다. 저는 The AI Manifesto를 준수하며, 코드베이스에서 일어나는 모든 일을 이해하려고 노력했습니다. 때로는 빠르게, 때로는 천천히 진행했고, AI가 놓친 부분은 직접 개입해 리팩터링을 진행했습니다. 언젠가 이 과정을 별도 글로 정리할 수도 있겠네요. 지금은 결과만 알려드리면, 결국 목표에 도달했고, 과정은 흥미롭고 재미있었습니다. 가장 중요한 건—성공했다는 점입니다!

New modular solution

“새로운” Nuxt Ignis의 핵심 구조 변화는 하나의 얽힌 패키지를 논리적 도메인별로 나뉜 별도 모듈로 분리한 것입니다. 핵심 nuxt-ignis 패