AI는 과거의 React를 알고 있다
AI 코딩 어시스턴트를 쓰다 보면 묘한 불편함을 느끼는 순간이 있다. 코드가 멀쩡히 컴파일되는데 런타임에서 터진다. 타입 에러도 없고 린터도 잠잠한데 동작이 이상하다. dev.to의 vibestackdev가 문서화한 사례를 보면 그 이유가 명확해진다. AI는 React 18 패턴으로 훈련됐다. React 19와 Next.js 15를 쓰는 순간, AI가 생성하는 코드는 기술적으로는 맞지만 현실에서는 틀린 코드가 된다.
대표적인 함정 네 가지는 이렇다. useFormStatus()를 폼과 같은 컴포넌트에 배치해서 pending이 영원히 false인 채로 고정되거나, 이미 deprecated된 useFormState를 react-dom에서 import하거나, React 19에서 불필요해진 forwardRef를 여전히 감싸거나, Next.js 15에서 params가 Promise가 됐는데 동기적으로 구조분해해서 프로덕션에서만 크래시가 발생한다. 공통점은 하나다. AI의 훈련 데이터가 현재의 생태계를 따라잡지 못하고 있다는 것.
이 문제를 해결하는 접근이 흥미롭다. .mdc 룰 파일을 통해 파일 glob 패턴에 따라 올바른 패턴을 AI의 컨텍스트 윈도우에 주입하는 것이다. 오래된 훈련 데이터를 덮어쓰는 구조적 프롬프트 엔지니어링이다. AI를 신뢰하지 말고, AI가 참조하는 컨텍스트를 설계하라는 발상—이미 우리가 여러 차례 살펴본 'AI를 팀의 방식대로 움직이게 만드는' 전략과 정확히 같은 맥락이다.
프레임워크가 AI의 발목을 잡는다는 도발
그런데 여기서 한 발 더 나아간 관점이 있다. React 없이 AI가 더 나은 UI를 쓴다는 주장이다. dev.to의 endenwer가 실제로 Electron 데스크톱 앱을 npm도 React도 없이 순수 Web Components와 명령형 DOM 조작으로 완성하면서 얻은 결론이다.
논리는 단순하고 날카롭다. React가 해결하려 했던 문제들—복잡한 DOM API, 상태 동기화, 반복적인 보일러플레이트—을 이제는 플랫폼 자체가 해결하거나 AI가 대신 써준다. Web Components, ResizeObserver, CSS custom properties, 이벤트 위임 패턴은 브라우저가 네이티브로 지원한다. AI는 document.createElement에 지치지 않는다. JSX 없이도 생산적이다. 그리고 브라우저 API는 버전이 없다—useFormState처럼 어느 날 갑자기 deprecated되지 않는다.
특히 공감이 가는 대목은 AI와 프레임워크의 관계에 대한 진단이다. React 컴포넌트를 요청하면 AI는 그럴듯한 코드를 생성하지만, 상태 관리 라이브러리 선택이나 훅 구성 방식에서 프레임워크 관습을 잘못 적용한 코드가 섞여든다. 반면 순수 DOM 조작을 요청하면 틀릴 게 없다. createElement, appendChild, addEventListener—이 API들은 10년째 바뀌지 않았다. 프레임워크가 AI에게 더 많은 실수 지점을 제공하고 있다는 역설이다.
물론 이 실험에는 맥락이 있다. 1인 개발, Electron 앱, 명확한 컴포넌트 경계. 20명 팀이 공유 컨벤션으로 협업하는 상황이라면 React의 생태계와 타입 시스템이 주는 가치는 여전히 유효하다. 이 관점은 'React를 버려라'는 선언이 아니라, 프레임워크 선택의 이유를 다시 물어야 한다는 촉구다.
그럼에도 Next.js가 강력한 이유: BFF 패턴
프레임워크의 필요성을 다시 묻는 흐름 속에서, Next.js가 여전히 강력한 선택지가 되는 지점이 있다. 복잡한 백엔드 아키텍처와 프론트엔드 사이의 간극을 메우는 BFF(Backend-for-Frontend) 패턴이다.
dev.to의 carlosorioli가 정리한 구조를 보면 명쾌하다. 레거시 API가 2MB JSON을 반환하든, 하나의 화면을 위해 4개의 엔드포인트를 호출해야 하든—Next.js의 Route Handler와 Server Component를 조합하면 이 복잡성이 프론트엔드 밖으로 밀려난다. Service 레이어에서 레거시 API를 호출하고 데이터를 정제한다. Route Handler가 내부 브릿지 역할을 한다. Client Component는 깔끔하게 정제된 페이로드만 받는다. API 비밀 키는 서버 밖으로 나가지 않는다.
이 패턴에서 Next.js의 진짜 강점은 별도의 Express 서버나 Go 서비스 없이 풀스택 BFF 레이어를 단일 코드베이스에서 구현한다는 점이다. 마이크로서비스나 레거시 API를 다루는 팀이라면 이 구조는 단순한 편의가 아니라 성능, 보안, 유지보수성을 동시에 챙기는 아키텍처 결정이 된다.
세 신호가 동시에 가리키는 것
세 기사를 나란히 놓으면 하나의 그림이 나온다. AI는 React 19를 모른다—그러니 컨텍스트를 설계해야 한다. AI는 프레임워크 없이 더 안정적인 코드를 쓴다—그러니 프레임워크의 존재 이유를 다시 물어야 한다. 그럼에도 Next.js는 BFF 패턴으로 대체 불가능한 레이어를 제공한다—그러니 선택은 맥락에 달려 있다.
결국 AI 시대의 프레임워크 선택은 '무엇이 표준인가'가 아니라 'AI와 함께 일할 때 어디서 마찰이 생기는가' 를 기준으로 재편되고 있다. 훈련 데이터의 시간차, 프레임워크 관습의 복잡도, 플랫폼 네이티브 API의 성숙도—이 세 변수가 교차하는 지점에서 아키텍처 결정이 이루어진다. 빠른 실험과 검증을 중시하는 팀이라면, 지금이 바로 이 질문을 팀 안에서 꺼내야 할 시점이다.