조은의 프론트엔드 개발 실무 가이드 : 요구사항 분석과 적정 기술 (2-1)

패스트캠퍼스 The Red

웹을 지탱하는 기술들 : 클라이언트 기술들

CH02_12. 웹 전체를 아우르는 문제 정리하기

• Web 브라우저에 대한 이해

ex) 유저가 사이트에 접속할 때 Node 서버를 통해 resources(js, img, data, cookie)를 가져온다

• 서버 구축 : 24시간 돌아가는 컴퓨터 (모니터링)
• 서버에 트래픽이 몰리면 어느 순간 죽는다 - 왜 사망했는지? 어느 시점에?
• Status Check : 실제로 살아있는지?
• Scaling : 서버를 유연하게 관리하는 것 (늘이고 줄이고)
• 서버가 죽지 않게 자동으로 관리해주는 것 - Cloud
• 대기열 - 게임사이트, 접종예약사이트 등

프론트엔드 개발자는 백엔드에 대한 이해가 없이 진행한다
Auto-Scaling, Logging 등등에 대한 지식은 없음
백엔드에 대한 지식을 쌓는다면?

Scaling > 서버 가용성 (AWS, Vercel)
서버 Scaling을 위한 정책 결정 > PO (트래픽 분석)

AWS는 비싸다. 
"서버 늘려"와 같은 단순한 문제 X

트래픽이란 서버에서 Response를 내려주면서 발생하는 것에 가깝다

리소스 최적화, 캐싱 문제, 트래픽 컨트롤
유저의 트래픽을 결정하는 것은 어떻게 보면 전체 리소스가 어느 정도 용량인지?
서버 가용에 대한 부분

근데 이거.. 백엔드 개발자하는 일 아니에요?

웹 브라우저, 클라이언트에서 일어나는 일에 대한 이해
그것을 바탕으로 백엔드 개발자와 협업

이런 게 컨트롤이 안되는 거 같아요
지금 이 부분에서 트래픽이 튀는데 이거 왜 이러는 걸까요? 
저희가 알림 푸시만 날리면 이상하게 트래픽이 튀네 이상하네.. 알림하면 무슨 일이 일어나고 있죠?

어떤 기술을 쓰더라도 웹 브라우저에서 일어나는 부분에 관해서는 이 기술은 왜 쓰는거지라는 생각을 할 수 밖에 없다. 웹에서 일어나는 트래픽 이슈를 인지하고 우리가 트래픽을 줄이기 위해 안정적인 서비스를 만들기 위해 대해서 아는 것이 클라이언트 사이드에서 웹을 지탱하는 기술이라고 생각한다.

React를 왜 쓰는지? MSA를 왜 하는지?에 대해 이해 

CH02_13. 브라우저 렌더링 101

Reflow는 CPU를, Repaint(필수)는 GPU를 많이 잡아먹는다.
1초당 60fps (약 0.024)
렌더트리
SPA, SSR 관련 연관되는 개념
CSS 레이아웃 과정을 줄이는 것만으로도 성능 최적화 가능

CSS animation을 만들면 60fps를 보장하기 어려워진다.
단, 같은 역할을 하는 transform(translate) 속성은 위치는 이동시키나 레이아웃을 발생시키지는 않는다.
(paint만 다시 동작하게 되므로 60fps 보장 가능)
will-change 속성은 GPU를 극대화해서 사용 가능

레이아웃을 발생시키는 CSS animation 속성을 사용하면 60fps를 보장하기 어렵다.

참고자료 - 브라우저 렌더링 이해

CH02_14. 클라이언트 사이드 렌더링

Client Side Rendering
JSX : JS로 DOM을 그린다 (필요한 DOM만 불러올 수 있다)
Component

JS 번들 사이즈 용량이 커진다
브라우저의 컴퓨팅 파워를 많이 쓰게 될 수 밖에 없다
=> 렌더링 퍼포먼스는 저하될 수 있다 (크롬 브라우저 메모리)
=> 한 번 렌더링하면 필요한 부분만 렌더링한다

React와 React-Router로 사이트를 구성한다?
정보를 전달하기 위한 목적의 사이트라면 실시간성을 굳이 보장할 필요가 없다

CSR을 하면 좋은 사이트
페이스북, 인스타그램, 트위터, Gmail, Google docs, 유튜브 (Feed 등으로 실시간성을 보장하는 SNS)

CSR에서는 얼마나 실시간성을 보장하는가?

💭 정보 조회, 현황보기의 목적보다는 유저 인터랙션이나 실시간성 업데이트가 강한 사이트에 도입하기 적합하다 (대규모 사용자가 있고 실시간 컨텐츠가 많이 올라와서 변경이 잦고, 활성도가 높아 페이지 전환 시 렌더링이 빨리 일어나야 하는 애플리케이션을 떠올려보자)

CH02_15. 서버 사이드 렌더링

CSR이든 SSR이든 둘다 웹에서 컨텐츠를 어디서 불러오는가를 생각해볼 수 있다

서버 내에서 HTML, Data, API, DB를 모두 불러오면 뭐가 좋은가
서버가 성능이 더 좋다
서버의 컴퓨팅 파워를 활용한

Next.js
Node Template Engine

HTML을 생성해서 내려주는 과정에서 느려지면 UX가 저하된다 (그려서 내려주기 때문에)
보통은 CSR과 SSR을 적절히 병행해서 쓰는 경우가 많고, 하나의 아키텍쳐로만 사고하지 말 것

유저만 브라우저에 들어오는가?
크롤러도 있다 (크롤링)

검색엔진 최적화 (SEO) : 상위 노출 목적이므로 이 측면에서는 SSR이 유리하다

React, ReactDOM
React hydrate (SSR처럼 렌더링해준다)

Next.js를 사용한다는 것은 이미지 최적화, 렌더링 최적화, 캐시, Node 환경, API proxy, Docker 등등 
React에서 SSR 환경을 만들 때 필요한 다양한 옵션들을 기본적으로 제공하는 프레임워크다라고 접근하는 시각

예전에는 SSR인 경우 페이지 지연 시 흰 화면을 노출시켜줬는데, 요즘에는 기존 화면을 유지시켜 놨다가 새로고침을 했을 때 거의 1초도 안되는 시간에 새로고침이 이루어진다. (순차 렌더링) SSR로 렌더링 시켜도 SPA(CSR)처럼 동작하는데 크게 문제가 없어 예전의 SSR과 현재의 SSR은 조금 다르다.

CH02_16. 정적 사이트 생성 (SSG)

유저가 어느 시점에 보내느냐 (Request를 날린 타이밍)

단순 뉴스기사나 상품소개 페이지에 유저가 접근할 때도 DB에 접근할 필요가 있을까?

SSG는 사이트를 생성하는 시점에(빌드 시점)에 HTML을 생성한다. 미리 HTML을 다 만들어 놓고 유저에게 전달한다. API 서버에 대한 부하가 줄어든다. Static 서버를 통해 사이트 한 번 빌드하는 시점에만.
유저는 CDN에서 컨텐츠를 받아온다. (CDN은 어지간하면 안 죽는다.)
대용량 트래픽

하나의 방식보다 여러가지 특징을 적절히 섞어서 활용하는 것이 좋다
3가지 아키텍쳐를 섞어서 만들면
페이지 특성을 고려해 활용할 수 있는 방식

장바구니를 만드는데 적절한 아키텍처는 뭘까? (상품, 수량)
상품 상세페이지는? (금액, 옵션, 품절)
블로그나 기사는?

각각의 렌더링 방식을 고려해서 조화롭게 아키텍쳐를 설계할 수 있을 것이다
해결할 문제를 고려해 기술 도입을 하는 것이 좋다.
단, 어떤 렌더링 방식을 사용하느냐에 따라 유저의 사용자 경험이 달라질 수 있기 때문에 항상 어떤 렌더링 방식을 쓸지에 대한 고민을 바탕으로 아키텍처를 잡아나가기를 바란다.

---

💬 강의가 총 4챕터로 구성되어 있어서 2챕터 시간인데 이 부분이 구성이 많아서 2-1,2-2로 나눠서..(시간이 넘 늦었군)

💬 생각보다 알아야 하고 범위가 넓구나 하는 생각이 드는데, 사실 웹이라는 범주 안에서 각각이 연관도가 있는 건데.. 그러면 결국 흔히 말하는 사용자 경험, 사용성을 개선하고 싶다면 어느 직군이든 개발에 대한 이해는 필수가 아닌가? 이런 생각이 든다. 나도 이 강의를 통해 서버에 대해서 가볍게 이해할 수 있었으니까..

💬 과거에 대한 되새김질은 좋진 않지만.. 디자이너도 개발을 알아야 하나요? 디자이너가 왜 코딩을 하냐 이런 말을 예전에 많이 들었다 (그건 퍼블리싱과 병행 직무였었기에 더 핸디캡이 있었을 수 밖에 없는데..) 그 해묵은 주제에 대해... 그냥 유명한 사람의 말을 좀 빌려서 내 생각을 말하자면...

”Most people make the mistake of thinking design is what it looks like,” says Steve Jobs, Apple’s C.E.O. ”People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.” - From The Guts of a New Machine, the 2003 New York Times article that profiled Apple just as the iPod was becoming recognized as a cultural phenomenon:
("대부분의 사람들은 디자인이 보이는 그대로라고 생각하는 실수를 합니다."라고 Apple의 CEO인 Steve Jobs는 말합니다. 그것은 우리가 생각하는 디자인이 아닙니다. 단순히 보이는 것과 느끼는 것이 아닙니다. 디자인은 작동 방식입니다.” - The Guts of a New Machine, iPod이 하나의 문화적 현상으로 인식되고 있는 시기에 Apple을 소개한 기사, 2003년 New York Times)
출처 : 스티브 잡스의 디자인 철학

애플의 디자인 철학 (Human Interface Guidelines)

• UX 디자인은 어떻게 보이는지 뿐만 아니라 그것이 작동하는 방식에 관한 것입니다.
• 제품이 아닌 사람을 위한 디자인입니다.
• 단순함은 창의성과 탐구를 장려합니다.

위 2개의 아티클은 디자이너를 위한 리액트라는 리액트 공식문서를 통해 발췌한 자료다.. 그래서 난.. 아는 것이 좋다고 생각한다. 그냥.. 정말 UX를 하고 싶은거고 그게 진짜라고 생각한다면... 지나고서 떠올리는 것도 웃기지만. 다행하게도 개발을 공부하면서 난 이제 디자인을 하고 싶은 생각이 없어졌다 😀 어렵지만 열심히..!!