내가 SSR은 풀스택이 아니다 라는 글을 적었는데, 좀 어수선하게 적어서 명확하게 알려주고자 다시한번 싸지르도록 하겠다. 특히 애초에 프론트엔드에 입문하거나, 구직 중이거나, 혹은 소속 중인 프론트엔드 개발자에게 확실히 좋은 양식이 될 것이다. 뭐? 10년 물먹은 코더 주제에 프론트엔드 얼마나 쳐했다고 감히 이딴글을 쓰냐? 실제로 누가 이런 맨션을 나한테 싸질렀다... 그래... 기술 부채가 심한 SI/SM 위주로 했으니 그럴 만도 하다. 하지만 알아둬야 할 것은, 10년도 못채우고 그만둔 개발자가 많다 보니, 10년 이상 개발자가 생각보다 별로 없다. (공급도 줄었는데 수요도 줄었다) 따라서 10년 웹을 해왔다는 건 본인이 혐오하거나 그러지 않는 이상은 척 보면 알고 개발하니

내가 지금 Next.js 프로젝트로 삽질하고 있었는데, 내가 여태까지 SSR에 대해 알고있는 지식과 달리 진실은 오히려 좁았다. 일단 너희들이 알고 있는 대략적인 SSR 특징에서 딱히 벗어난 건 아니지만, 나처럼 오바하지 말라는 의미에서 글을 싸지르도록 하겠다. SSR은 풀스택이 아니다. 내가 가장 많이 착각한 부분이다. 그럼 뭐냐? 당연히 프론트엔드다. 그럼 서버단 렌더링이라면 서버단 코드가 돌아가는 건 당연한 거 아니냐고? 서버단 렌더링은 JSP, PHP, ASP 처럼 말 그대로 서버단에서 처리해 주는 게 아니다. 만약 이렇게 이해하고 있다면 너는 SSR을 상당히 잘못 이해하고 있는 것이다. SSR 원리를 대충 설명하겠다. 상세한 설명은 구글링 해서 찾아라. 이 SSR을 언급할 때 가장 많이 쓰는 용어가 Hydrate인데, 우리말로 하면 수화(水化). 화학 용어다. 한자 그대로 물같이 변한다는 뜻이다. 너희들이 생각하는 뉴스같은 방송에서 오른쪽 아래에 손으로 까딱하는

자, CSR과 SSR 이 있다. 이 둘의 차이점은 기본적으로 알고 있을 거라 믿고 시작하겠다. 몰라? 화면 표현을 클라이언트에게 모두 전가하느냐, 아니면 서버가 어느정도 개입하느냐 그 차이잖아. 둘의 장단점이 있다면, CSR 장점 정적 파일만 제공하는 웹 서버 게시가 가능해져 더 다양한 게시 제공자(특히 Github Pages)에 서비스가 가능하다. 클라이언트와 서버의 경계가 명확해 확실한 업무분리가 가능하다. CSR 단점 트래픽 유발이 많아진다 (그래서 캐시관리가 중요하지) 클라이언트 환경에 따라 차이가 크다 (흔히 말하는 누군 되고 안되고) SSR 장점 서버의 트래픽을 절약할 수 있다. (필요한 정보만 뿌리면 되니까) SEO에 유리하다 SSR 단점 클라이언트와 서버의 경계가 모호하다 (거의 풀스택이 요구된다) 정적 파일만 게시 가능한 제공자에 서비스가 불가능하다. CSR에 유리한 분야 관리 패