React 19 릴리스 후 몇 주가 지났다. 초기의 혼란과 논쟁은 점차 잦아들고, 그 자리에는 새로운 패러다임을 탐험하고 적용하려는 건설적인 움직임이 자리 잡기 시작했다. 그리고 그 변화의 중심에는, 이전 시대의 복잡성을 경험하지 못한 ‘새로운 시대의 개발자들’이 있었다.
한 코딩 부트캠프의 강의실.
강사는 이제 막 웹 개발에 입문한 학생들에게 React의 기본을 가르치고 있었다.
“자, 오늘은 사용자의 입력을 받아 서버에 저장하는 폼을 만들어 보겠습니다.”
강사가 화면에 보여준 코드는 React 19의 서버 액션을 사용하는 방식이었다. 학생들은 자연스럽게 <form action={...}>을 작성하고, useFormState로 서버의 응답을 받아 화면에 표시하는 방법을 배웠다.
한 학생이 손을 들고 질문했다.
“선생님, 제가 예전에 찾아본 다른 React 강의에서는 e.preventDefault()라는 걸 쓰던데, 우리는 왜 안 쓰나요?”
강사는 미소를 지으며 답했다.
“아주 좋은 질문이에요. 그건 React 19 이전에 사용하던 ‘오래된 방식’입니다. 이제 React가 그 모든 복잡한 과정을 알아서 처리해주기 때문에, 우리는 더 이상 그런 코드를 작성할 필요가 없어요. 여러분은 훨씬 더 쉽고 직관적인 방법으로 개발을 시작하게 된 행운아들입니다.”
학생들은 고개를 끄덕였다. 그들에게 useState 여러 개와 useEffect를 조합해 폼을 만드는 복잡한 패턴은, 마치 흑백 TV 시절의 이야기처럼 낯설고 멀게만 느껴졌다. 그들에게 React는 원래부터 ‘이렇게 쉬운 것’이었다.
온라인 학습 플랫폼에서도 비슷한 변화가 일어나고 있었다. 유명 React 강사들은 앞다투어 자신들의 강의를 React 19 버전으로 업데이트했다.
‘React 완전 정복 2024 에디션’이라는 제목의 새로운 강의 커리큘럼에서, ‘데이터 페칭’ 챕터는 더 이상 useEffect의 함정을 설명하는 데 시간을 쏟지 않았다. 대신, 서버 컴포넌트에서 async/await를 사용하고, 클라이언트 컴포넌트에서 use 훅과 Suspense를 사용하는 방법을 중심으로 가르쳤다. isLoading과 error 상태를 수동으로 관리하는 개념은 ‘레거시 패턴’으로 짧게 언급되고 지나갈 뿐이었다.
이 새로운 시대의 개발자들은,
- 번들 사이즈를 줄이기 위해 무거운 라이브러리 사용을 망설였던 과거를 알지 못했다. 서버 컴포넌트가 그 부담을 덜어주었기 때문이다.
- 네트워크 폭포수를 최적화하기 위해 컴포넌트 구조를 비틀었던 고통을 경험하지 못했다. React가 알아서 데이터 요청을 병렬화해주었기 때문이다.
- 하이드레이션 오류와 싸우며 ‘죽은 화면’을 디버깅했던 좌절감을 겪지 않았다. 선택적 하이드레이션이 그 문제를 해결해주었기 때문이다.
그들에게 React는 복잡성의 주범이 아니라, 복잡성의 해결사였다.
React Core Team은 이러한 변화를 조용히, 그리고 깊은 만족감과 함께 지켜보았다. 그들이 지난 몇 년간 싸워왔던 모든 문제들이, 다음 세대의 개발자들에게는 더 이상 ‘문제’로 인식조차 되지 않는 세상. 그것이 바로 그들이 꿈꿔왔던 진정한 성공이었다.
React 19는 단순히 기존 개발자들의 코드를 개선한 것이 아니었다. 그것은 미래의 개발자들이 딛고 설 새로운 땅을 만들어낸 것이었다. 더 높고, 더 단단하고, 더 평탄한 땅 위에서, 새로운 시대의 개발자들은 이제 과거의 문제들에 발목 잡히지 않고, 오직 더 창의적이고 가치 있는 것을 만드는 데에만 자신들의 열정을 쏟을 수 있게 될 터였다.
