Google I/O Extended 2023 Pangyo 후기

(사진 추후 추가 예정)

서론

처음으로 개발자 세미나라는 것을 경험하게 되었다.

내가 못 알아듣는 얘기만 듣다가 나오지 않을까 걱정되어 참가를 망설였는데, React 18을 다루는 세션이 있어서 참가하게 되었다.

세션 소개

1. Google I/O Connect @Miami 내용 공유 - 조희주 님

   GDG Pangyo

2. Keras Core(Keras 3.0): changes and challenges - 신정규 님

   래블업

3. Andorid Update 2023 (Android 14 업데이트 내용 및 Compose 소개) - 권태환 님

   레몬트리

4. **React18, 제로 번들을 향한 새로운 시작 - 이동규님

   당근마켓**

오늘 있었던 세션은 추후 편집 과정을 거친 뒤, GDG 판교 페이스북 등에서 다시 볼 수 있도록 공유될 예정이라고 한다!

가장 집중해서 들었던 React18 세션에 대한 내용을 정리하려고 한다.

React18, 제로 번들을 향한 새로운 시작

웹 개발의 역사

1. ajax와 V8 엔진의 등장

ajax 등장 이전

• 유저가 데이터를 입력하거나, 어떤 요소를 클릭 페이지 새로고침을 해야했다.
• 모든 웹페이지 상호 작용시 새로 페이지를 로딩해와야 하므로, 사용자는 매번 흰 화면을 봐야했고 비효율적인 전송이 이루어졌다.
• 이때까지만 해도 JS는 UI를 돕는 역할에 불과했다.

ajax 등장 후

• 페이지를 이동하지 않아도 비동기 처리를 통해 화면을 변경할 수 있게 되었다.
• JS를 통해 할 수 있는 것들이 많졌다.
• but… 코드 관리가 복잡해졌다. SSR(Server Side Rendering)로 인해 서버에서도 화면 렌더링을 위한 코드작성이 필요하게 되었다.

V8 엔진 등장 (NodeJS)

• NodeJS의 등장으로 JS가 발전하면서 모든 요소를 클라이언트에서 렌더링하는 CSR(Client Side Rendering)이 등장해 코드관리가 수월해졌다.
• API를 통해 서버에서는 데이터만 가져오고, 렌더링 관련 로직은 모두 클라이언트에서 차리하였다.
• SPA(Single Page Application) 개념이 본격적으로 등장하게 되었다.

2. SPA 단점 극복을 위한 노력

SPA(또는 CSR)의 단점

• SEO(검색 엔진 최적화)에 취약하다.
  • 검색 엔진은 정적 파일을 보는데 정적 파일은 사실상 비어있고, 모든 요소를 동적으로 서버에서 받아와 렌더링하기 때문
• 웹 서비스가 점점 커져가면서 FCP(First Contentful Paint)가 지연되기 시작했다.
  • FCP란 브라우저가 DOM으로 부터 첫 비트(처음으로 의미있는 화면)을 렌더링하기 까지 걸리는 시간이다.
• 웹 페이지 로딩시간이 길어지고, 이로인해 유저 사용성이 감소하였다.

Universal SSR

• 사용자가 볼 수 있는 화면 요소만 SSR을 통해서 처리한 뒤 HTML을 받아 즉각 렌더링하고, 나머지 상호작용을 위한 요소는 CSR 방식으로 렌더링하여 동작하는 방식을 말한다.
  • 이 과정을 Hydration이라고 한다. 메마른 정적 HTML 페이지에 JS라는 수분 보충을 해준다는 의미 같다.
• SSR의 장점, CSR의 장점을 모두 합쳐 FCP가 개선되었고, SEO 문제도 해결되었다.
• 단점
  • FIP(Frist Input Delay)에 대한 문제는 여전히 해결하지 못했다.
  • HTML -> React로 변환하기 위한 Hydration 과정에 걸리는 시간이 있기 때문

Streaming SSR - React18부터 정식 제공

• Streaming SSR은 서버에서 번들을 생성할 때, HTML을 여러 Chunk로 나누어 렌더링하고, 렌더링이 완료된 부분마다 바로바로 클라이언트에 응답해주는 방식이다.
• 이를 통해 TTFB(Time To First Bits)를 빠르게 할 수 있다.

3. Server Component 등장 (RSC)

• RSC(React Server Component)는 React 트리에서 일부는 클라이언트에서 렌더링하고, 일부는 서버에서 렌더링하여 양쪽의 자원을 모두 활용하기 위한 방법이다.
• SSR과 다른점은 서버에서 렌더링이 이루어지면 HTML이 아니라 JSX 컴포넌트로 변환되어 Hydration 과정없이 즉각 클라이언트에서 페이지에 표시할 수 있다. 이 과정은 스트리밍 형식으로 이루어지기 때문에, 전체 파일이 아니라 컴포넌트 단위로 렌더링이 되어 효율적이다.
• 서버 컴포넌트는 주로 데이터를 입출력, 전처리 및 파일 시스템이 필요한 부분, 클라이언트 컴포넌트는 주로 UI나 사용자 상호작용이 필요한 부분을 담당한다.
• 현재 RSC를 써보고 싶다면 Next.js를 배워보자

장점

• 강력한 서버 컴퓨팅 파워를 활용할 수 있다.
• 클라이언트에서 DB에 직접적으로 접근할 수 있다. (JSX 컴포넌트가 서버에 있으므로)
• Zero-Bundle이 가능해진다.
  • 서버 컴포넌트는 번들에 포함되지 않기 때문에 번들의 크기가 줄어든다.
  • 클라이언트에서는 매번 불러와 사용해야하는 라이브러리 중(번들 크기를 키우는 요인) 서버에서만 사용되는 라이브러리는 서버에서만 유지하고, 클라이언트에 보내 줄 필요가 없다.
• API 요청으로 처리해야할 데이터 전송을 서버 내부에서 숨긴채로 처리해버릴 수 있으니 보안성이 증가한다.

단점

• 서버 컴포넌트는 상태(state)를 가질 수 없다.
  • 이로인해 상태를 가지고 있는 라이브러리는 RSC에 쓸 수 없다.
• 오직 직렬화 가능한 데이터에만 적용가능하다. (함수 불가능)

4. RSC 이후의 미래?

만약 RSC가 ajax, v8 엔진처럼 게임체인저 역할을 하게되면, 현재의 생태계에 큰 영향을 줄 수 있다.

세션에서는 한 칼럼을 예시로 들며 앞으로 변화할 수 있는 미래에 대한 인사이트를 제공해주었다.

세션에서 소개된 칼럼 : https://leerob.io/blog/product-engineers

• 프론트엔드, 백엔드의 경계가 다시 모호해질 수 있다.
  • 프론트엔드 개발자가 DB를 만질 수 있어야하고, 백엔드 개발자가 렌더링 코드를 다룰 수 있어야 한다.
• 칼럼에서는 프론트엔드, 백엔드 대신 프로덕트 개발자와 플랫폼 개발자로 나누어지지 않을까 예상하고 있다.
  • 프로덕트 개발자 : 현재의 풀스택 개발자와 유사한 개념으로, 프론트엔드, 백엔드, 디자인 등 사용자 경험과 관련된 모든 것을 고려하여 개발한다. 대신 이들 각각에 대해 깊게 알지는 못하며, 플랫폼 개발자에 의해 개발된 Tool을 통해 이를 실현한다.
  • 플랫폼 개발자 : 프로덕트 개발자가 더욱 효율적으로 개발을 할 수 있는 Tool들을 개발한다.

소감

면접에서 CSR, SSR 개념에 대한 대답을 제대로 못한 직후였는데, 세미나에서 이런 내용의 강의를 듣게되서 매우 많은 것을 배운 것 같다.

마지막 주제였던 RSC 이후의 미래에 대한 내용도 인상적이었다. 사실 프론트엔드 개발자로써 커리어가 어떻게 될지 갈팡질팡하고 있었는데, 이런 가능성도 있겠구나~를 체험할 수 있었다.

일단 지금 배우고 있는 것을 잘하게 된다면 Next.js를 꼭 배워서 RSC를 경험해보고 싶다.