프레임워크 추천 뒤에 숨은 이해관계
프론트엔드 개발자라면 한 번쯤 느꼈을 불편함이 있다. React 공식 문서를 열면 첫 번째 권장 사항으로 Next.js가 등장하고, Next.js를 깊이 쓰다 보면 자연스럽게 Vercel 배포를 고민하게 된다. 이 흐름이 단순한 '좋은 DX 경험'인지, 아니면 의도된 생태계 설계인지를 정면으로 묻는 글이 dev.to에서 주목받고 있다.
해당 글의 주장은 명확하다. React Server Components는 훌륭한 개념이지만, 프로덕션에서 제대로 작동하는 첫 번째 구현은 Vercel의 Next.js였다. Vercel은 핵심 React 팀원을 고용했고, React의 로드맵은 점점 서버 사이드 로직과 엣지 런타임 쪽으로 기울었다. 서버에서 실행될수록 '어디에 배포하느냐'가 중요해지고, 그 자리에 Vercel이 있다. React 기능 → Next.js 구현 → Vercel 배포로 이어지는 이 퍼널은 음모론이 아니라 합리적인 비즈니스 모델이다.
문제는 이 구조가 개발자의 선택권을 조용히 좁힌다는 점이다. 클라이언트 사이드 SPA 패턴은 점점 이류 취급을 받고, 간단한 Vite + React Router 조합이면 충분한 프로젝트도 Next.js를 고려하게 된다. 기술적 불만이 아니라 구조적 불편함—이것이 "React가 싫어졌다"는 말의 진짜 의미다. 오픈소스 프로젝트의 로드맵이 단일 VC 지원 기업의 수익 모델과 정렬될 때, 수백만 개발자의 선택지는 그 기업이 원하는 방향으로 수렴한다.
로컬 LLM으로 프로덕션급 UI를 만든다는 것
스택 선택의 자율성이 흔들리는 것과 반대로, AI 개발 도구의 민주화는 빠르게 진행 중이다. 최근 한 개발자가 클라우드 AI 없이 로컬 LLM만으로 프로덕션급 개발자 도구 사이트를 구축한 경험을 공유했다. 스택은 단순했다. Ollama 위에서 Gemma 4:12B를 돌리고, VS Code Copilot Agent와 연결한 뒤, React도 빌드 도구도 없이 HTML + CSS + Vanilla JS로 완성했다.
흥미로운 지점은 모델의 성능보다 '어떻게 지시했느냐'가 결과를 갈랐다는 것이다. 초반에는 페이지마다 레이아웃이 제각각이고, 색상 팔레트가 달랐으며, SEO 메타데이터가 빠지는 일이 반복됐다. 전환점은 VS Code Copilot Skill을 작성한 순간이었다. 폴더 구조, 디자인 시스템, 색상 팔레트, glassmorphism 스타일 가이드, 접근성 기준, 성능 기대치까지—프로젝트의 의사결정을 한 곳에 집약한 '재사용 가능한 엔지니어링 블루프린트'를 만들자, 12B짜리 모델도 일관된 결과물을 내기 시작했다.
이 경험은 AI 도구 선택에 대한 흔한 오해를 뒤집는다. 더 크고 비싼 모델이 항상 답은 아니다. 모델에게 '더 긴 프롬프트'를 주는 것보다, '더 명확한 제약 조건과 구조'를 주는 것이 훨씬 강력하다. 그리고 그 구조를 설계하는 능력은 여전히 개발자의 몫이다. 로컬 LLM이 프라이버시와 비용 측면에서 클라우드 API를 대체할 수 있다는 실증이기도 하다.
오버빌딩은 코드가 아닌 첫 대화에서 시작된다
AI가 코드를 빠르게 생성할수록 역설적으로 더 큰 위험이 따라온다. "로컬 뮤지션이 곡 아이디어를 녹음할 수 있는 앱을 만들어줘"라는 한 줄 프롬프트가 사용자 계정, 팀 협업, 클라우드 동기화, AI 마스터링, 구독 대시보드, 관리자 패널까지 달린 시스템을 반환하는 일은 이미 흔한 경험이 됐다.
dev.to의 한 가이드는 이 문제의 근원을 정확히 짚는다. 오버빌딩은 코드가 많아진 뒤에 일어나는 게 아니라, AI와의 첫 대화에서 시작된다. 제약이 없는 프롬프트를 받은 AI는 '더 완전한 시스템'을 설계하려 한다. 더 큰 시스템이 더 완성된 것처럼 보이기 때문이다. 이를 막는 가장 효과적인 방법은 피처 리스트가 아니라 익스클루전 리스트—즉, 버전 1에서 만들지 않을 것들의 목록—를 먼저 작성하는 것이다.
제안하는 접근법은 간결하다. "버전 1은 [한 명의 사용자]가 [하나의 작업]을 처음부터 끝까지 완료하는 것만 책임진다"는 원 워크플로우 계약(One-Workflow Contract)을 AI에게 먼저 선언하라. 화면 수는 4개를 넘기지 말고, 모든 화면은 그 워크플로우 완료에 기여해야만 존재 이유가 생긴다. 데이터 모델도 마찬가지다—20개 테이블짜리 스키마는 첫 앱에서 완성의 징표가 아니라 매몰의 신호다.
세 신호가 함께 가리키는 것
이 세 가지 흐름은 표면적으로는 서로 다른 이야기처럼 보이지만, 하나의 공통된 질문으로 수렴한다. "이 스택, 이 도구, 이 기능은 누구의 문제를 해결하기 위해 여기 있는가?"
React 생태계의 거버넌스 문제는 특정 기업의 수익 목표가 오픈소스 로드맵을 조용히 밀어낼 때 개발자가 치르는 비용을 보여준다. 로컬 LLM 프로토타이핑 경험은 '더 비싼 도구'보다 '더 명확한 설계'가 결과를 결정한다는 것을 증명한다. 오버빌딩 방지 가이드는 AI가 빠르게 생성할수록 개발자가 먼저 범위를 좁히는 능력이 더 중요해진다는 것을 상기시킨다.
세 신호가 함께 가리키는 방향은 결국 같다. AI 시대의 프론트엔드 스택 선택은 기술적 성숙도만이 아니라 이해관계의 정렬과 제약 설계 능력을 함께 따져야 한다. Next.js가 나쁜 선택이라는 것이 아니다. 그것이 왜 추천되는지, 그 추천이 누구의 이익과 연결되는지, 그리고 이 프로젝트에 실제로 필요한 최소한의 구조가 무엇인지를 먼저 물어야 한다는 것이다.
지금 당장 바꿀 수 있는 것
프레임워크 선택 전에 "이 기능이 없는 더 단순한 스택으로 시작할 수 있는가"를 한 번 더 묻는 것, AI에게 코드 생성을 맡기기 전에 익스클루전 리스트를 먼저 작성하는 것, 그리고 로컬 LLM이 충분한 프로젝트에서 굳이 클라우드 API를 고집하지 않는 것—이 세 가지 습관은 어떤 스택을 쓰든 지금 바로 적용할 수 있다. 속도가 올라갈수록, 도구가 많아질수록, 첫 번째 질문은 더 단단해야 한다.