정글 6기 0주차 회고

정글 6기에 들어가게 되다

우여곡절 끝에 정글 6기에 들어가게 되었다. 맨 처음에 사정이 생겨 늦게 들어가게 되면서 어떻게 해야할까? 사람들과 친해질 수 있을까? 라는 생각을 많이 했다. 하지만 그 걱정은 팀원들이 다 좋아서 전혀 할 이유가 없었다.

처음부터 미니 프로젝트를?

다양한 프로젝트 경험이 있는 나는 프로젝트를 시작하고 만들어 내는 것이 얼마나 어려운지 알고 있다. 심지어 만난지 1시간도 안된 사람끼리 모여 프로젝트를 시작하였으니 걱정 반 설렘 반이었다. 이 사람들의 개발적인 수준이 얼마나 될까? 어떻게 프로젝트를 완성해 나갈까? 라는 생각을 했었다. 다행이 팀원들과 잘 협업하여 프로젝트는 잘 만들어졌다. 아래는 그동안 설명한 것을 정리한 내용이다.

지식의 공유

웹은 어떻게 발전해 왔을까?

개요

웹은 각자의 정보를 올리고 관리할 수 있는 문서 그 자체였다. 그래서 HTML를 통해 문서의 형태를 표현하고, 나중에 CSS가 나오면서 그 문서를 꾸밀 수 있게 되었다. 하지만 이 자체로만 사용하기에는 사용자의 반응에 대해 처리할 수 있는 수준이 적었다.

JS의 등장

그 수준들을 해결해 나가기 위해서 Javascript언어가 나왔다고 한다. 그렇기 때문에 간단하게 언어적인 기능만 발의가 되었고 다른 프로그래밍 언어와는 다르게 다양한 고급 기능 등을 배제하고 Script로서 기능을 충실하게 만들었다.

Big Tech 기업들의 싸움과 등 등터지는 개발자들

웹의 가능성을 본 Bit Tech기업들은 언젠간 표준이 필요하게 되리라는 것을 알고 있었을 것이다. 그래서 각자만의 방식으로 JS를 개발하기에 도달한다. 신기능이 늘어나는 것은 좋으나 각자 그 구현체를 다르게 구현하여 괜히 그 사이에 있는 개발자들은 고래싸움에 새우 등 터지듯 휘말려 왔다.

그와 동시에 등장한 jQuery

그 당시때는 jQuery는 Javascript 그 자체라고 한다고 하더라도 과언이 아니었다. 그 큰 Vender들 간의 다른 점들을 jQuery만 쓰면 모두 동일하게 쓰듯이 쓸 수 있다니, 또한 지금 HOF와 같은 형식이나 FP스러운 형태들을 보면 정말 대단하다고 생각된다.

Javascript의 발전과 jQuery의 몰락 하지만 개발자들은 어떤 들인가? 불편한점이라면 그것을 해결하는 종족들이 아닌가? Javascript의 개발을 선도하는 기업들이 모여 Javascript를 정의하는 [ECMA](https://ecma-international.org/)단체를 만들기 시작한다. 이때부터 대부분의 Vender들은 여기에 정의되어 있는 ECMAScript구현체를 구현하기 시작한다. 참고로 ECMAScript를 정의하는 단체는 TC39이며 [여기](https://github.com/tc39)에서 회의하고 있는 내용을 확인할 수 있다. 강력한 엔진등장 V8 Google에서 V8를 만들었다. 이게 얼마나 강력하게 작동하면 나중에 Node.js에도 들어가게 되어, 웹에서 돌아갈 뿐 아니라 데스크탑에서 Javascript를 실행하기에 이른다. 물론 Single Core(엄밀하게 하자면 아니라고 하긴 하지만)이지만 그렇기 때문에 간단함과 서버의 장점을 가져갈 수 있어서 Javascript개발자들은 Backend를 같이 사용하기도 한다. Frontend 개발자의 등장 여기서 Frontend 개발자라고 하니깐 이상하게 들리는 사람이 있을 수도 있으나, 올래는 웹 개발자 밖에 없었다. Java개발자가 Sprint에서 jsp을 이용하거나, C#개발자가 asp를 이용하는 등 Backend개발자가 temple engine을 이용하여 사이트를 개발하였다. 하지만 사용자의 인터렉션, 다루어야 하는 데이터가 많아짐에 따라 Client화면만을 개발하는 Frontend의 개발자의 필요성이 높았졌고 이는 backborn.js를 거쳐 React, Anguler, Vue로 넘어왔다. 현재는 이 3파전 중 React가 승리자가 되어 가장 사용자가 많다. ### JWT HTTP는 멍청하다 HTTP는 멍청하다. 이 프로토컬은 똑똑하게 이전의 모든 내용을 저장하는 애가 아니라, 한번 보내면 까먹는 마치 금붕어와 같다.(이에 관한 추가적인 내용은 [다음 사이트](https://stackoverflow.com/questions/236835/what-to-do-with-a-stupid-client-request)로 넘긴다.) 하지만 웹 서비스 개발자들은 이 기능 때문에 고통을 받으며 살아간다. 그래서 여기서부터 인증/인가의 방식이 나오게 된다. JWT는 편리함 원툴이다 JWT가 등장하기 이전에는 session방식의 기반으로 사용자를 구분했다고 한다. 하지만 session의 단점은 무엇인가, TCP/IP가 끊어지는 순간 즉 휴대폰의 인터넷이 다른 위성국으로 전환하는 순간 끊어지게 되는 것이 아닌가. 그러면 사용자는 다시 로그인을 하여 그 session에서 인증을 해야한다. 즉 다시 말하면 버스타고 이동하면서 웹툰을 보다가 "인증이 안되어 다시 로그인 해야 합니다."와 같은 것이다. JWT는 이거와 다르게 Client에서 Token을 주기만 하면 통과하게 한다. 얼마나 편한가? 심지어 Frontend개발자가 신경을 안쓰게 만들기 위해 Cookie로 통신을 하면 모든 내용은 Backend 개발자가 컨트롤 할 수 있다. 하지만 원대한 단점이 있으니... JWT는 보안에 취약하다 악의적인 개발자가 그 JWT를 탈취하면 그 탈취된 사용자의 모든 정보들은 빼앗기게 된다. 그러면 사용하면 안되는 것이 아닌가? 하지만 그 개발자들은 편리함에 눈이 멀어 JWT를 정의할 때 다양한 정책을 이용하기에 이른다. JWT는 사용시간이 정해져 있다. 악의적인 개발자가 탈취를 하였는데 귀찮다고(물론 그러진 않겠지만) 1시간 뒤에 시도한다고 가정하자. 하지만 그 Token의 사용 시간이 5분이라면? 어떻게 될까? 예상할 수 있듯이 그 악의적인 개발자는 Token을 이용할 수 없다. 하지만 만약 5분이라고 하면 사용자는 어떻게 로그인을 5분마다 다시 하지 않고 사용할 수 있을까? Access Token과 Refresh Token 사실 다른 보안 기법들이 있으며 편리하게 사용(단순 인증)만 한다면 한개의 Token을 이용해도 좋다. 위와 같이 취약한 보안을 조금이라도 강력하게 만들기 위해 Token을 5분 이라는 제한을 둔다면 2개의 토큰을 이용하면 좋다. Access Token을 일반적으로 인증하기 위한 경우, Refresh Token을 그 Access Token을 인가하기 위한 경우에 사용한다. 그렇다면 Refresh Token으로 인증을 할 수 있을까? 정답은 아니요이다. 개발의 보편적인 원칙인 SOLID에서 SRP에 위배가 된다. 위와 같이 다시 로그인 하는 것을 방지하기 위해서 보편적으로 Refresh Token은 Access Token보다 길게 한다. 참고로 Refresh Token을 다시 발급 받을 때는(정책마다 다르지만) Access Token과 Refresh Token을 같이 넘겨서 체크한 뒤에 구현하기도 한다. ### SSR vs CSR Server와 Client SSR과 CSR을 설명하기 전에 서버와 클라이언트는 Backend와 Frontend의 차이라고 하면 안된다. Client는 우리의 서비스가 최종적으로 사용하는 종단 단말기라고 생각해야한다. 단순히 웹 서비스를 많이 하기 때문에, 그리고 SSR, CSR은 웹 서비스에서 쓰이기 때문에 브라우져라고 말하는 것이다. 개념 SSR은 Server Side Rendering이라고 하며, 서버에서 모든 HTML/CSS를 만들어서 보내는 형태를 말한다. 그와 반대로 CSR은 Client Side Rendering이라고 하며, Server에서 데이터만을 받아 웹 브라우저에서 Javascript를 통해 HTML/CSS를 추가한다. 어라? CSR이 먼저 나온게 아니야? 일반적으로 생각해보았을때 웹을 그리기 위해서는 HTML/CSS가 있어야 하고, 이를 다루기 위해서는 Javascript를 사용하는 것으로 알고 있을 것이다. 하지만 실상는 Javascrip언어가 너무 구렸다. 개발자가 원하는 것을 만들기 위해서는 더 발전된 언어가 필요했다.(물론 보안도) 그 발전된 언어는 서버에서 쓰이는 언어에서 발전이 많이 되었다. 즉 Javascript는 보조적 도구로 사용하고 일반적으로 Java, C#과 같은 언어들을 주로 사용하였다. 장단점이 무엇일까? SSR은 서버에서 만들었기 때문에 초기 로딩 속도가 빠르다. 하지만 매 페이지를 이동할 때마다 화면이 흰색으로 덮였다가 이동하는 이동하는 현상이 있다. 그와 반대로 CSR은 이동할 때 마치 APP처럼(SPA도 결국 CSR를 극대화 한것이다.)이동할 수 있고, 초기 로딩이 끝나면 SSR보다 더 빠르게 이동할 수 있다는 장점이 있다. 하지만 초기 로딩 속도가 압도적으로 느리다는 단점이 있다. ## 회고 > 나는 너무나도 어린 개발자이다. Junior중에 Junior가 아닐까? 단순히 개발을 잘하고, 화면을 잘 그려주며, 많은 개념을 알고 있고, 물 흐르듯이 프로젝트의 맡은 부분을 잘 진행할 수 있는 것이 좋은 개발자는 아니라고 생각한다. 더 성숙한 개발자라면 사람들을 가르쳐주고, 다른 사람들에게 프로젝트를 잘 공유하며 진행해야 한다고 생각한다. 앞으로 다른 사람들에게 말을 할 때 한번 더 고민해보고, 더 친절하게, 자만심을 가지지 말고 공부하면 좋은 개발자로 성장하지 않을까?

Javascript의 발전과 jQuery의 몰락 하지만 개발자들은 어떤 들인가? 불편한점이라면 그것을 해결하는 종족들이 아닌가? Javascript의 개발을 선도하는 기업들이 모여 Javascript를 정의하는 [ECMA](https://ecma-international.org/)단체를 만들기 시작한다. 이때부터 대부분의 Vender들은 여기에 정의되어 있는 ECMAScript구현체를 구현하기 시작한다. 참고로 ECMAScript를 정의하는 단체는 TC39이며 [여기](https://github.com/tc39)에서 회의하고 있는 내용을 확인할 수 있다. 강력한 엔진등장 V8 Google에서 V8를 만들었다. 이게 얼마나 강력하게 작동하면 나중에 Node.js에도 들어가게 되어, 웹에서 돌아갈 뿐 아니라 데스크탑에서 Javascript를 실행하기에 이른다. 물론 Single Core(엄밀하게 하자면 아니라고 하긴 하지만)이지만 그렇기 때문에 간단함과 서버의 장점을 가져갈 수 있어서 Javascript개발자들은 Backend를 같이 사용하기도 한다. Frontend 개발자의 등장 여기서 Frontend 개발자라고 하니깐 이상하게 들리는 사람이 있을 수도 있으나, 올래는 웹 개발자 밖에 없었다. Java개발자가 Sprint에서 jsp을 이용하거나, C#개발자가 asp를 이용하는 등 Backend개발자가 temple engine을 이용하여 사이트를 개발하였다. 하지만 사용자의 인터렉션, 다루어야 하는 데이터가 많아짐에 따라 Client화면만을 개발하는 Frontend의 개발자의 필요성이 높았졌고 이는 backborn.js를 거쳐 React, Anguler, Vue로 넘어왔다. 현재는 이 3파전 중 React가 승리자가 되어 가장 사용자가 많다. ### JWT HTTP는 멍청하다 HTTP는 멍청하다. 이 프로토컬은 똑똑하게 이전의 모든 내용을 저장하는 애가 아니라, 한번 보내면 까먹는 마치 금붕어와 같다.(이에 관한 추가적인 내용은 [다음 사이트](https://stackoverflow.com/questions/236835/what-to-do-with-a-stupid-client-request)로 넘긴다.) 하지만 웹 서비스 개발자들은 이 기능 때문에 고통을 받으며 살아간다. 그래서 여기서부터 인증/인가의 방식이 나오게 된다. JWT는 편리함 원툴이다 JWT가 등장하기 이전에는 session방식의 기반으로 사용자를 구분했다고 한다. 하지만 session의 단점은 무엇인가, TCP/IP가 끊어지는 순간 즉 휴대폰의 인터넷이 다른 위성국으로 전환하는 순간 끊어지게 되는 것이 아닌가. 그러면 사용자는 다시 로그인을 하여 그 session에서 인증을 해야한다. 즉 다시 말하면 버스타고 이동하면서 웹툰을 보다가 "인증이 안되어 다시 로그인 해야 합니다."와 같은 것이다. JWT는 이거와 다르게 Client에서 Token을 주기만 하면 통과하게 한다. 얼마나 편한가? 심지어 Frontend개발자가 신경을 안쓰게 만들기 위해 Cookie로 통신을 하면 모든 내용은 Backend 개발자가 컨트롤 할 수 있다. 하지만 원대한 단점이 있으니... JWT는 보안에 취약하다 악의적인 개발자가 그 JWT를 탈취하면 그 탈취된 사용자의 모든 정보들은 빼앗기게 된다. 그러면 사용하면 안되는 것이 아닌가? 하지만 그 개발자들은 편리함에 눈이 멀어 JWT를 정의할 때 다양한 정책을 이용하기에 이른다. JWT는 사용시간이 정해져 있다. 악의적인 개발자가 탈취를 하였는데 귀찮다고(물론 그러진 않겠지만) 1시간 뒤에 시도한다고 가정하자. 하지만 그 Token의 사용 시간이 5분이라면? 어떻게 될까? 예상할 수 있듯이 그 악의적인 개발자는 Token을 이용할 수 없다. 하지만 만약 5분이라고 하면 사용자는 어떻게 로그인을 5분마다 다시 하지 않고 사용할 수 있을까? Access Token과 Refresh Token 사실 다른 보안 기법들이 있으며 편리하게 사용(단순 인증)만 한다면 한개의 Token을 이용해도 좋다. 위와 같이 취약한 보안을 조금이라도 강력하게 만들기 위해 Token을 5분 이라는 제한을 둔다면 2개의 토큰을 이용하면 좋다. Access Token을 일반적으로 인증하기 위한 경우, Refresh Token을 그 Access Token을 인가하기 위한 경우에 사용한다. 그렇다면 Refresh Token으로 인증을 할 수 있을까? 정답은 아니요이다. 개발의 보편적인 원칙인 SOLID에서 SRP에 위배가 된다. 위와 같이 다시 로그인 하는 것을 방지하기 위해서 보편적으로 Refresh Token은 Access Token보다 길게 한다. 참고로 Refresh Token을 다시 발급 받을 때는(정책마다 다르지만) Access Token과 Refresh Token을 같이 넘겨서 체크한 뒤에 구현하기도 한다. ### SSR vs CSR Server와 Client SSR과 CSR을 설명하기 전에 서버와 클라이언트는 Backend와 Frontend의 차이라고 하면 안된다. Client는 우리의 서비스가 최종적으로 사용하는 종단 단말기라고 생각해야한다. 단순히 웹 서비스를 많이 하기 때문에, 그리고 SSR, CSR은 웹 서비스에서 쓰이기 때문에 브라우져라고 말하는 것이다. 개념 SSR은 Server Side Rendering이라고 하며, 서버에서 모든 HTML/CSS를 만들어서 보내는 형태를 말한다. 그와 반대로 CSR은 Client Side Rendering이라고 하며, Server에서 데이터만을 받아 웹 브라우저에서 Javascript를 통해 HTML/CSS를 추가한다. 어라? CSR이 먼저 나온게 아니야? 일반적으로 생각해보았을때 웹을 그리기 위해서는 HTML/CSS가 있어야 하고, 이를 다루기 위해서는 Javascript를 사용하는 것으로 알고 있을 것이다. 하지만 실상는 Javascrip언어가 너무 구렸다. 개발자가 원하는 것을 만들기 위해서는 더 발전된 언어가 필요했다.(물론 보안도) 그 발전된 언어는 서버에서 쓰이는 언어에서 발전이 많이 되었다. 즉 Javascript는 보조적 도구로 사용하고 일반적으로 Java, C#과 같은 언어들을 주로 사용하였다. 장단점이 무엇일까? SSR은 서버에서 만들었기 때문에 초기 로딩 속도가 빠르다. 하지만 매 페이지를 이동할 때마다 화면이 흰색으로 덮였다가 이동하는 이동하는 현상이 있다. 그와 반대로 CSR은 이동할 때 마치 APP처럼(SPA도 결국 CSR를 극대화 한것이다.)이동할 수 있고, 초기 로딩이 끝나면 SSR보다 더 빠르게 이동할 수 있다는 장점이 있다. 하지만 초기 로딩 속도가 압도적으로 느리다는 단점이 있다. ## 회고 > 나는 너무나도 어린 개발자이다. Junior중에 Junior가 아닐까? 단순히 개발을 잘하고, 화면을 잘 그려주며, 많은 개념을 알고 있고, 물 흐르듯이 프로젝트의 맡은 부분을 잘 진행할 수 있는 것이 좋은 개발자는 아니라고 생각한다. 더 성숙한 개발자라면 사람들을 가르쳐주고, 다른 사람들에게 프로젝트를 잘 공유하며 진행해야 한다고 생각한다. 앞으로 다른 사람들에게 말을 할 때 한번 더 고민해보고, 더 친절하게, 자만심을 가지지 말고 공부하면 좋은 개발자로 성장하지 않을까?

Javascript의 발전과 jQuery의 몰락 하지만 개발자들은 어떤 들인가? 불편한점이라면 그것을 해결하는 종족들이 아닌가? Javascript의 개발을 선도하는 기업들이 모여 Javascript를 정의하는 [ECMA](https://ecma-international.org/)단체를 만들기 시작한다. 이때부터 대부분의 Vender들은 여기에 정의되어 있는 ECMAScript구현체를 구현하기 시작한다. 참고로 ECMAScript를 정의하는 단체는 TC39이며 [여기](https://github.com/tc39)에서 회의하고 있는 내용을 확인할 수 있다. 강력한 엔진등장 V8

Google에서 V8를 만들었다. 이게 얼마나 강력하게 작동하면 나중에 Node.js에도 들어가게 되어, 웹에서 돌아갈 뿐 아니라 데스크탑에서 Javascript를 실행하기에 이른다. 물론 Single Core(엄밀하게 하자면 아니라고 하긴 하지만)이지만 그렇기 때문에 간단함과 서버의 장점을 가져갈 수 있어서 Javascript개발자들은 Backend를 같이 사용하기도 한다.

Frontend 개발자의 등장

여기서 Frontend 개발자라고 하니깐 이상하게 들리는 사람이 있을 수도 있으나, 올래는 웹 개발자 밖에 없었다. Java개발자가 Sprint에서 jsp을 이용하거나, C#개발자가 asp를 이용하는 등 Backend개발자가 temple engine을 이용하여 사이트를 개발하였다.

하지만 사용자의 인터렉션, 다루어야 하는 데이터가 많아짐에 따라 Client화면만을 개발하는 Frontend의 개발자의 필요성이 높았졌고 이는 backborn.js를 거쳐 React, Anguler, Vue로 넘어왔다. 현재는 이 3파전 중 React가 승리자가 되어 가장 사용자가 많다.

JWT

HTTP는 멍청하다

HTTP는 멍청하다. 이 프로토컬은 똑똑하게 이전의 모든 내용을 저장하는 애가 아니라, 한번 보내면 까먹는 마치 금붕어와 같다.(이에 관한 추가적인 내용은 [다음 사이트](https://stackoverflow.com/questions/236835/what-to-do-with-a-stupid-client-request)로 넘긴다.) 하지만 웹 서비스 개발자들은 이 기능 때문에 고통을 받으며 살아간다. 그래서 여기서부터 인증/인가의 방식이 나오게 된다.

JWT는 편리함 원툴이다

JWT가 등장하기 이전에는 session방식의 기반으로 사용자를 구분했다고 한다. 하지만 session의 단점은 무엇인가, TCP/IP가 끊어지는 순간 즉 휴대폰의 인터넷이 다른 위성국으로 전환하는 순간 끊어지게 되는 것이 아닌가. 그러면 사용자는 다시 로그인을 하여 그 session에서 인증을 해야한다. 즉 다시 말하면 버스타고 이동하면서 웹툰을 보다가 "인증이 안되어 다시 로그인 해야 합니다."와 같은 것이다.

JWT는 이거와 다르게 Client에서 Token을 주기만 하면 통과하게 한다. 얼마나 편한가? 심지어 Frontend개발자가 신경을 안쓰게 만들기 위해 Cookie로 통신을 하면 모든 내용은 Backend 개발자가 컨트롤 할 수 있다. 하지만 원대한 단점이 있으니...

JWT는 보안에 취약하다

악의적인 개발자가 그 JWT를 탈취하면 그 탈취된 사용자의 모든 정보들은 빼앗기게 된다. 그러면 사용하면 안되는 것이 아닌가? 하지만 그 개발자들은 편리함에 눈이 멀어 JWT를 정의할 때 다양한 정책을 이용하기에 이른다.

JWT는 사용시간이 정해져 있다. 악의적인 개발자가 탈취를 하였는데 귀찮다고(물론 그러진 않겠지만) 1시간 뒤에 시도한다고 가정하자. 하지만 그 Token의 사용 시간이 5분이라면? 어떻게 될까? 예상할 수 있듯이 그 악의적인 개발자는 Token을 이용할 수 없다. 하지만 만약 5분이라고 하면 사용자는 어떻게 로그인을 5분마다 다시 하지 않고 사용할 수 있을까?

Access Token과 Refresh Token

사실 다른 보안 기법들이 있으며 편리하게 사용(단순 인증)만 한다면 한개의 Token을 이용해도 좋다. 위와 같이 취약한 보안을 조금이라도 강력하게 만들기 위해 Token을 5분 이라는 제한을 둔다면 2개의 토큰을 이용하면 좋다. Access Token을 일반적으로 인증하기 위한 경우, Refresh Token을 그 Access Token을 인가하기 위한 경우에 사용한다.

그렇다면 Refresh Token으로 인증을 할 수 있을까? 정답은 아니요이다. 개발의 보편적인 원칙인 SOLID에서 SRP에 위배가 된다. 위와 같이 다시 로그인 하는 것을 방지하기 위해서 보편적으로 Refresh Token은 Access Token보다 길게 한다.

참고로 Refresh Token을 다시 발급 받을 때는(정책마다 다르지만) Access Token과 Refresh Token을 같이 넘겨서 체크한 뒤에 구현하기도 한다.

SSR vs CSR

Server와 Client

SSR과 CSR을 설명하기 전에 서버와 클라이언트는 Backend와 Frontend의 차이라고 하면 안된다. Client는 우리의 서비스가 최종적으로 사용하는 종단 단말기라고 생각해야한다. 단순히 웹 서비스를 많이 하기 때문에, 그리고 SSR, CSR은 웹 서비스에서 쓰이기 때문에 브라우져라고 말하는 것이다.

개념

SSR은 Server Side Rendering이라고 하며, 서버에서 모든 HTML/CSS를 만들어서 보내는 형태를 말한다. 그와 반대로 CSR은 Client Side Rendering이라고 하며, Server에서 데이터만을 받아 웹 브라우저에서 Javascript를 통해 HTML/CSS를 추가한다.

어라? CSR이 먼저 나온게 아니야?

일반적으로 생각해보았을때 웹을 그리기 위해서는 HTML/CSS가 있어야 하고, 이를 다루기 위해서는 Javascript를 사용하는 것으로 알고 있을 것이다. 하지만 실상는 Javascrip언어가 너무 구렸다. 개발자가 원하는 것을 만들기 위해서는 더 발전된 언어가 필요했다.(물론 보안도)

그 발전된 언어는 서버에서 쓰이는 언어에서 발전이 많이 되었다. 즉 Javascript는 보조적 도구로 사용하고 일반적으로 Java, C#과 같은 언어들을 주로 사용하였다.

장단점이 무엇일까?

SSR은 서버에서 만들었기 때문에 초기 로딩 속도가 빠르다. 하지만 매 페이지를 이동할 때마다 화면이 흰색으로 덮였다가 이동하는 이동하는 현상이 있다.

그와 반대로 CSR은 이동할 때 마치 APP처럼(SPA도 결국 CSR를 극대화 한것이다.)이동할 수 있고, 초기 로딩이 끝나면 SSR보다 더 빠르게 이동할 수 있다는 장점이 있다. 하지만 초기 로딩 속도가 압도적으로 느리다는 단점이 있다.

회고

나는 너무나도 어린 개발자이다. Junior중에 Junior가 아닐까?

단순히 개발을 잘하고, 화면을 잘 그려주며, 많은 개념을 알고 있고, 물 흐르듯이 프로젝트의 맡은 부분을 잘 진행할 수 있는 것이 좋은 개발자는 아니라고 생각한다. 더 성숙한 개발자라면 사람들을 가르쳐주고, 다른 사람들에게 프로젝트를 잘 공유하며 진행해야 한다고 생각한다.

앞으로 다른 사람들에게 말을 할 때 한번 더 고민해보고, 더 친절하게, 자만심을 가지지 말고 공부하면 좋은 개발자로 성장하지 않을까?