썸네일 출처: React 19: A Game-Changer? What Messy Problems Did React Just Fix? | Stackademic
올해 2월에, 리액트 공식에서 11개월만에 근황 블로그를 게시했다. 리액트 개발자들 다들 근질근질 했을 것이다.
그런 근질근질 닭살돋는 개발자들 지켜보는 게 내 취미이고 말이지. 징그럽다고?
후훗 귀여운것들.
뭐 됐고, 본문 시작하겠다.
Next.js 가 13부터 앱 라우터 기능을 추가하면서, 아래 기능이 추가됐다.
이 두 가지 기능에 대해 아직까지는 캐시 문제 때문에 망설이고 페이지 라우터를 쓰는 개발자도 아직 많을 테고,
나처럼 에라이 모르겠다 질러보자 해서 써서 납품까지 해놓은 미친놈도 있을 것이다.
지금 나같은 경우, 잘~만 운영 중이다.
어쨌든, 위 둘이 뭐 많이들 알았겠지만 둘 다 리액트 차기 버전에 정식으로 추가될 것들이다.
다들 알다시피 Vercel 과 React 팀과 긴밀한 협력 관계를 가지면서, Vercel 에서 리액트 핵심 개발자 몇몇 들여서 이렇게 앞서서 사용할 수 있도록 프레임워크에서 이렇게 친히 "이럴 것이다"라는 기능을 선보여서 아마 누구는 기대할 것이고, 누구는 걱정할 것이다.
지금 리액트가 서버단(Server-side)로 가는 이유를 스스로 인증해줬다.
물론 리액트 팀이 지금 현 상태가지고는 성능 향상을 기대할 수 없는 사실도 알고 있고,
그래서 이를 타파하기 위해 노력을 한 결과가 바로 리액트 컴파일러일 것이다. 하지만 지금은 못 쓰기 때문에 이건 후술하겠다.
지금까지의 프론트엔드 기술 중 공식적으로 풀스택까지 바라보는 기술은 현재 없다. 단지 프레임워크에서 지원할 뿐.
그리고 그 첫 발을 리액트가 밟는다고 보면 된다. 기술 차원에서 프론트엔드를 넘어 아우르는 스택을 지원할 리액트.
설레이지 않겠는가?
현재 진정한 풀스택을 공식 프레임워크 차원에서 지원하는 기술이 있다면, 바로 스벨트(Svelte)다.
스벨트는 애초에 간단한 문법을 제공하고, 컴파일하여 번들링한 결과물을 사용해서, 편의성과 생산성, 성능 하나는 끝내준다.
단지 역사가 그리 길지는 않다보니 그나마 유럽에서 관심이 많지 미국과 아시아에서는 리액트와 뷰 양자택일이다.
스벨트 팀에서 직접 프레임워크를 만들었다. 바로 스벨트킷(SvelteKit). 이 프레임워크는, 데이터 조회와 양식 액션을 프레임워크 차원에서 지원해주고 있다.
즉, 현재 Next.js 앱 라우터와 유사한 기능을 Next.js 보다 더 빨리 제공하고 있다.
이건 당시 SvelteKit 가 풀스택 프레임워크 중 후발주자인 데다가 뒤도 안돌아보고 바로 하위 호환성 버리고 안정화 단계에서 바로 과감한 결정을 내린 신의 한수라 할 수 있다.
하지만 리액트는 이런 프레임워크 단에서 지원하는 것들을 기술 차원에서 지원해준다.
리액트의 성능에 대해서는 말이 많다. 게다가 해외에서는 당시 독자 라이선스로 가려는 행보, 기대하기 어려운 공식 피드백 등등,
이런저런 감정들이 겹쳐 리액트를 빠져나간 개발자들도 있다. 물론 한국 이야기는 아니다. 만약 한국에서 그랬으면 이미 한국은 탈자바 하고도 남는다.
하지만 JSX 기술에 대해서는 다들 정말 혁신적이고 꿈의 기술이라고 칭하는 듯 하다. 오죽했으면 아래 JSX 위주의 프론트엔드 기술들이 나왔을까.
게다가 뷰(Vue)같은 경우는 JSX 문법을 지원할 수 있도록 밑밥을 깔았지만 물론 쓰는 이들이 얼마나 있겠냐만은...
어쨌든, 리액트의 훅은 점점 빛보다는 그림자가 더 많아지고 있는 현실이다.
다른 프론트엔드 기술들은 빠른 업데이트로 트랜드를 선도하려 하는데, 리액트는 최근 업데이트가 2022년 6월이다.
물론 이런 상황에 두가지 의견으로 엇갈리는데, 바로 개발 트랜드냐 안정성이냐다.
하위 호환성을 끔찍하게 챙겨주는 자바가 생각나는 경우다.
여기 벨로그에서도 React 방향성에 대해 우려하는 글을 점점 볼 수 있어서 좋구먼.
내가 리액트 좋아서 쓰는 거 아니야. 그냥 내가 마음에 드는 기능 때문에 쓸 뿐이지.
얘들아. 내가 예전에 이렇게 말했어. 그 기술을 좋아한다면, 되기 때문에 향상이 가능하고, 안되기 때문에 보완할 수 있다.
It can be enchanced because it works, also it can be fixed because it dosen't.
나같은 듣보잡이 나만 아는 명언 가져와봐야 너희들 관심 안가질 거 아니 그만 할게.
다시 본문으로 돌아가서, 현재 React 주관사에 대해 말이 많은데, Meta 보다는 Vercel 의 입김이 강하다는 의견이 국내외에서 제기되고 있다. 물론 나도 Next.js 앱 라우터 나오면서 바로 동감하는 바다.
물론 Meta는 대기업이고, Vercel은 신생 스타트업이긴 하지만 꽤 선방하는 기업이다.
이정도면 그냥 React 기술을 그냥 Vercel 로 이관하지 그러냐 시발롬아 이런 의견도 눈에 띄기는 한데,
그렇다고 Meta가 마냥 손 놓고 있지는 않나 보다. 가장 큰 이유가 바로 리액트 공식 팀이 언급했던 리액트 컴파일러와 인스타그램 사례다.
그리고 이 논란은 현재진행형이다.
일단 차기 리액트를 보아 하니, 일단 Next.js 입장에서는 많이 신경 쓰일 것이다. 바로 최소한의 수정으로 바로 React 19를 적용할 수 있느냐다. 아마 내가 봤을 땐 쉽지는 않을 것 같다. 왜냐면,
React 18 출시 당시, Next.js 는 차기 버전 적용에 꽤 곤욕을 치뤘던 적이 있었다. 그에 반해 Remix 는 공식상에서 '우린 버전을 바꾼 것으로 React 18에 대응 완료' 라고 발표했었지.
그래. 아마 React 19의 서버 컴포넌트가 지원되면 Remix는 왠지 Next.js 보다 오히려 안정적이고 유연한 선택이 될 것 같다.
오죽했으면 Remix의 라우팅 시스템을 Next.js 가 앱 라우터를 적용하면서 그대로 따라했을까 싶다.
나도 그런 안정적인 철학 때문에 한때 Next.js 보단 Remix를 실무에 구축하려고 했는데... MUI가 말을 안들어줘서... 쩝...
당시 React 18 초창기라 서로 호환성이 왔다갔다 카오스였던 시절에 잘못된 선택이 아니었을까 싶고...
지금 Next.js 사이트 운영하면서 리액트 19가 나오면, 나야 뭐 서버 컴포넌트와 서버 액션을 적극적으로 활용하니 나머지는 버전업 하면서 나오는 오류 해결이겠지만 이게 생각보다 크니까 말이지.
그래서 차기 리액트 기반의 사이트를 구축한다면, 다시 Remix를 선택할까 싶은 생각이 꽤 든다.
너희들은 준비 됐는가? 사실 뭐 딱히 준비할 건 없을 것이다. 서버 컴포넌트 쓸 생각이 없다면 말이지.
서버 컴포넌트가 ASP, PHP 시절의 스파게티 코드를 유발할 것이란 우려가 있는데, 내 경험상 그런 경험은 없었다.
오히려 아토믹 디자인을 요구하게 만드는 패턴이라 이건 취향이라고 본다.
일단 이건 내 주관적인 사견만 가득한 내용이기 때문에 그냥 그렇구나 네놈의 의견은 그렇구나 라고 이해해주기 바란다.
내가 예상하는 리액트 19는 빠르면 올해 말로 예측한다.
물론 리액트는 죽지 않는다. 그럴 일도 없다. 하지만 한 번 식기 시작하면 쓰는 기업만 쓰는 꼰대같은 기술로 남을 지도 모른다.
마치 Java 처럼 말이지.
애플의 Ember.js 사랑은 유명하듯이 말이지.
그래서 나는 차기 리액트가 나와도 기대 반 우려 반이다. 느린 업데이트, 프레임워크 스러운 기술 매커니즘 등이 프론트엔드 개발자를 질리게 만드는 요소이기도 하니까.
나? 글쎄다... 나는 Solid와 Svelte가 가장 마음에 들지. 서버 컴포넌트 아니었으면 리액트 쳐다도 안봤거든.
끗.
저는 svelte, lit, 웹컴포넌트로 주로 작업하는 퍼블리셔인데 nextjs가 워낙 커지면서 리액트 방향이 어디로 갈가 궁금하긴하네요 기본 기능을 모르면 안되긴해서요. 모든 프레임워크가 웹컴포넌트를.지원하면 너무 좋을거같습니다.