"2026년, 바이브 코딩과 에이전트 프로그래밍의 시대에 어떤 웹 프레임워크를 쓰는지가 여전히 중요한가?" React Router와 Remix 등 오픈소스 프레임워크를 3년간 풀타임으로 개발해 온 Brooks Lybrand가 던지는 질문이다. 그는 이 질문을 단순한 도발이 아니라 진지하게 따져볼 문제로 제시한다. 모델이 충분히 똑똑해졌다면, 그리고 개발자들이 .tsx 파일 안에 무엇이 들어 있는지 점점 신경 쓰지 않게 됐다면, 과연 새로운 프레임워크를 만들 이유가 남아 있는가 하는 물음이다.
"React가 이겼으니 끝"이라는 통념
요즘 널리 퍼진 주장은 이렇다. 모델이 좋아진 이후로 코드 자체, 특히 대체로 표현 계층에 불과한 프런트엔드 코드는 덜 중요해졌다는 것이다. 보기에 괜찮으면 괜찮은 것이고, React가 이미 가장 지배적인 UI 라이브러리인 데다 세상에 React 코드가 압도적으로 많으니 모델도 React에 더 익숙하다. 따라서 다른 것을 시도할 이유가 없다는 논리다. 저자는 Cursor 팀처럼 진지한 사람들도 에이전트 시대에 React가 유리하다고 믿는다는 점을 인정하면서도, 이 통념이 사람들 사이에서 일종의 카고 컬트처럼 바이브 코딩 앱에 그대로 복제되고 있다고 지적한다.
저자가 정작 걸고넘어지는 지점은 "왜 하필 React인가"다. 만약 LLM이 프런트엔드 코드를 그렇게 잘 짜게 됐고 사람들이 HTML·JS·CSS의 세부를 신경 쓰지 않는다면, 애초에 LLM과 웹 사이에 추상화 계층을 둘 이유가 무엇인가. 그 논리를 끝까지 밀어붙이면 Web Components를 받아들일 때이거나, 더 극단적으로는 학습 데이터에 풍부한 jQuery를 그냥 에이전트에게 맡기자는 결론에 도달한다. 에이전트는 스파게티 코드를 개의치 않을 테니 말이다. 저자는 이 역방향 논리가 기존 통념만큼이나 많은 비약을 안고 있다고 본다.
프레임워크가 실제로 제공하는 가치
Lybrand는 프레임워크를 Flask와 jQuery와 React와 Next.js처럼 성격이 다른 것들로 정의하려는 시도 대신, 그것이 주는 가치로 접근한다. 그의 정의는 간결하다. 프레임워크는 웹사이트를 만들기 위한 추상화, 구조, 제약을 제공한다. 이는 사실 프레임워크만의 속성이 아니라 모든 라이브러리·모듈·클래스·함수에 해당한다. 코드는 의미와 의도를 표현하는 추상화의 연속이며, 과거에는 그 독자가 인간이었기에 변수명 같은 것에 신경을 썼다. 지금은 우리가 신경 쓰는 디테일의 수준이 이동하고 재정착하는 중이라는 것이다.
그는 React가 '이긴' 이유를 shadcn/ui 같은 컴포넌트 라이브러리 덕분이라고 보는 Vercel 측 시각에 선을 긋는다. shadcn/ui는 훌륭하지만 Radix, Reach UI, Material UI, Bootstrap으로 이어지는 긴 계보의 최신 진화일 뿐이며, 그런 생태계가 React 위에 쌓였다는 사실 자체가 React의 강점을 증명하는 것이지 그 반대가 아니라고 말한다. 저자가 꼽는 핵심은 React 팀이 즐겨 말하는 '컴포지션', 그리고 초기부터 제공된 SSR이 PHP처럼 스크립팅 언어 안에 HTML을 담는 경험을 가능케 했다는 점이다. 이 지점에서 backend-for-frontend 엔지니어와 Next.js·Remix 같은 메타프레임워크가 떠올랐다.
"쓰거나, 만들거나"
저자가 반복해 인용하는 말은 React Conf 2024 Q&A에서 Ricky Hanlon이 한 "당신은 프레임워크를 쓰고 있거나 만들고 있다. 그리고 프레임워크를 만드는 일은 정말 어렵다"는 문장이다. 그는 한 텍사스 식료품 체인의 웹 플랫폼 팀에서 'exo'라는 자체 메타프레임워크를 만들었던 경험을 든다. 초기 요청에 SSR을 처리하고 이후 React Router로 클라이언트 라우팅을 넘기는 구조였지만, 기능과 마케팅이 없어 아무도 그것을 프레임워크로 여기지 않았고, 유지 비용이 크고 내부에서 그 작동을 이해하는 엔지니어도 적어 결국 상당한 부채가 됐다. 그 조직은 Next.js로 옮기기 시작했고, 저자는 그 무렵 Shopify의 Remix 팀으로 이직했다.
흥미로운 결론은 Hanlon의 명제가 지금 더 맞으면서도 한편으로는 조금 틀렸다는 것이다. '프레임워크 만들기는 어렵다'는 더 이상 완전히 참이 아니다. 몇 번의 프롬프트로 틀은 잡힌다. 그러나 견고하고 버그 없고 안전한 풀스택 프레임워크를 원한다면 이야기가 다르다. 쓰다 보면 LLM이 프레임워크로 원하는 동작을 다 끌어내지 못해 조용히 해킹성 우회를 덧붙이고, 그 땜질이 어느새 프레임워크의 일부가 되어버린다. 좋은 추상화를 정하고 땜질을 피하는 일은 프런티어 모델을 써도 여전히 반복과 노력이 필요하다는 것이 그의 경험이다.
한국 실무자 입장에서 이 글의 쓸모는 기술 선택을 "모델이 가장 잘 아는 것"으로 환원하지 말라는 경고에 있다. 저자가 정말 원하는 것은 잘 테스트되고 안전하며 추론하기 쉬운 코드, 그리고 에이전트가 좋은 결과를 내도록 유도하는 '홈(groove)'을 제공하는 프레임워크다. 바꿔 말해 프레임워크의 가치는 사람이 코드를 읽느냐가 아니라 추상화·구조·제약이 변경 비용과 유지보수 부채를 줄여주느냐에 있다. 다만 이 글은 특정 벤치마크나 수치 없이 저자 개인의 관찰과 경험에 기대고 있다는 한계도 분명하다. 그린필드 프로젝트를 시작하는 팀이라면, React를 기본값으로 삼든 다른 선택을 하든, '모델 친숙도' 하나가 아니라 장기 유지보수와 추상화의 질을 함께 저울질하라는 것이 실천적 함의다.