항해99 1주차 WIL

항해라는 이름을 참 잘 지은 것 같다. 

물론 실제로 항해를 해본 적은 없지만, 진짜 항해를 하면 이런 느낌일 것 같다. 

폭풍우가 겁나지만 결국 내가 이겨낼 것을 알기에 그 힘듦이 기대된다 해야 되나? ㅎㅎ

이번 주는 월요일부터 목요일까지 미니 프로젝트를 진행하고 금~토는 알고리즘 스터디를 진행했다.

알고리즘은 게임을 하듯이 정말 즐거웠다.

특히 "이상한 문자 만들기"라는 문제를 풀고 나서 map,forEach,3항연산자에 대해 배우게 되었다.

그 뒤로도 map, forEach, 3항연산자를 떠올려보면 코드가 짧아지고 문제가 쉽게 풀리는 경우가 많았다.

미니프로젝트는 '센스 있는 개발자를 위한 아이템 추천'이라는 서비스 페이지를 만들었다. 

첫 미니프로젝트에서 필수로 공부해야 할 개념은 서버사이트랜더링과 JWT방식의 로그인 구현이었다.

서버사이드 렌더링, JWT 그리고 첫 협업을 하면서 느낀 점을 남겨보려 한다.

1. 서버사이드 렌더링

서버사이드 렌더링(SSR)은 우리가 브라우저에서 보는 화면을 서버에서 다 만들어서 보내준다는 뜻이고

클라이언트사이드 렌더링(CSR)은 그 화면을 브라우저에서 만들어서 띄운다는 뜻이다.

일단 CSR은 서버에서 빈 html에 js링크를 담아서 보내게 된다. 처음에는 html을 가져왔지만 빈 html이기 때문에 텅텅 빈 화면이 보인다.

그 후 다시 브라우저는 그 js링크로 html을 동적으로 구성할 자바스크립트를 요청한다. html을 동적으로 구성하는 자바스크립트를 쉽게 하는 게 바로 리액트나 뷰 같은 프레임워크인 것 같다.

그럼 다시 서버에서 그 js파일을 브라우저로 보내주고 그제야 브라우저가 js를 받아서 동적으로 html을 생성해서 화면에 보여주게 된다.

csr은 처음에 완벽한 자바스크립트와 데이터를 가져오기 때문에 로딩에 시간이 소요되지만 한번 로딩하고 나면 아주 부드러운 화면 전환이 가능하다. 페이스북이나 인스타그램을 생각해보면 처음에 접속할 때 약간의 시간이 들지만 한번 접속하고 나면 화면 깜빡거림 없이 클릭할 때마다 부드럽게 넘어간다. 이게 바로 csr의 장점이다. 

반면에 SSR은 처음부터 잘 만들어진 html 파일을 보내준다. 그렇기 때문에 CSR보다 빨리 화면에 뭔가를 띄울 수가 있다.

일단 뭔가 잘 만들어진 html을 띄운 다음에 동적으로 만들어 줄 js를 요청하고 js를 서버에서 보내주면 html을 동적으로 만들 수 있다.

여기에서 TTV와 TTI에 대해서 알게 되는데 TTV(Time to View), TTI(Time to Interact)

CSR의 경우 어차피 화면에 뭔가 띄우려면 동적으로 만들어주는 js를 가져와야 하기 때문에 TTI와 TTV가 동일하다.

화면에 보이면 바로 클릭이 된다는 뜻이다.

그러나 SSR의 경우에는 갑자기 서버에 사람이 많아서 과부하가 걸리는 경우를 생각해보자.

html을 가져오는 타이밍과 다시 동적인 js파일을 요청하고 가져오는 타이밍이 차이 날 수 있다. 그러면 내 눈에는 버튼이 보이는데, 클릭을 해도 아무 일이 일어나지 않아서 사용자가 어리둥절해지는 상황이 올 수도 있다.

그리고 csr과 달리 매번 request를 보낼때마다 서버에서 새로운 html을 rendering해야하기 때문에 흰 화면이 깜빡거린다.

그렇다면 이런 단점만 있는가? 아니다 서버사이드 렌더링을 하면 첫 번째 화면 로딩이 빨라져서 어떤 면에서는 좋다고 볼수도 있다고 하는데... 나는 차라리 처음에 좀 기다리는 csr방식이 나은 것 같다.

그리고 확실한 장점으로는 검색엔진 최적화에 유리하다. 왜냐하면 대부분의 검색엔진들은 서버에 저장된 html을 돌아다니면서 정보를 수집하는데 csr처럼 동적으로 만들어지는 빈 html의 경우에는 아무런 텍스트나 링크가 없어서 검색엔진 검색에 불리할 수 있다. 

이러한 장단점을 이해하고 어떤 상황에서 csr, ssr을 적용할지, 어떻게 하면 csr, ssr의 단점을 최소화할 수 있을지 고민하는 것이 필요하다.

2. JWT 

jwt방식을 이용해서 로그인을 구현했는데 내 블로그에도 있는 노마드코더의 세션, 쿠키 이용 방식의 로그인 구현과 차이점을 비교해보면 좋을 것 같다. 세션이란 그 자체가 서버의 메모리에 생성되는 저장공간이다. 즉 서버와 브라우저의 관계는 항상 stateless 해서 매 req마다 인증을 확인해줘야 하는데 세션을 이용하면 서버의 메모리를 사용한다는 것이나 마찬가지다. 개발할 때는 나랑 내 팀원들 뿐이니 상관이 없겠지만 수백, 수천 명이 되면 아주 부담이 될 것이다. 그래서 이와 대조되게 jwt방식을 쓰는데, jwt라는 단어가 json web token의 약자이다.

json으로 저장된 토큰이라는 뜻인데, 로그인 정보를 세션에 저장해놓고 비교하는 게 아니라 정보를 json 형식으로 담아서 토큰을 만들어 발급하는 것이다. 우리는 프로젝트에서 이 토큰을 쿠키에 담아놓고 사용했다. req가 있을 때마다 쿠키에서 넘어온 토큰을 서버에서 처리해서 사용했다.

기본적으로 이렇게 세션 방식과 달리 jwt방식은 사용자 인증을 하는데 메모리를 사용하지 않고 json형식으로 토큰을 주고받아서 인증하기 때문에 가볍다는 느낌이 든다. 그래서 뭔가 보안상 취약하지 않을까? 걱정이 된다. 이 부분에 대한 해결책이 분명 있을 것이지만 아직 거기까지 공부해보지는 않았다.

이런 로그인 기능의 개념을 이해하고 각 방법의 장단점을 알고 있다가 프로젝트에 사용해보면 더 깊이 이해가 될 것이다.

3. 첫 협업을 하면서 느낀 점

인터넷 강의를 보면서 클론 코딩하는 게 아니라 처음으로 모르는 사람들과 만나서 실제 구글 검색을 해가며 아무것도 모르는 상태로 

첫 프로젝트를 해봤다.

https://youtu.be/y48IQ0Xce54

혹시라도 내가 맡은 부분에서 피해가 될까 봐 초집중 상태가 됐었고, 혼자 공부할 때 효율의 몇 배가 발휘됐었던 것 같다.

개발 공부는 이렇게 하는 게 맞는구나 싶은 생각이 들었다.

나 말고 다른 분들도 모두 첫 협업이다 보니 아쉬웠던 부분이 있다.

바로 api와 데이터베이스 구조 설계를 하지 않고 단순히 역할 분배만 하고 시작했다는 것이다.

한 번이라도 해보신 분들이라면 이 얼마나 비효율적인지, 저것도 하지 않고 완성이 될 수 있었는지조차 의심될 수도 있다.

다행히 3일 만에 완성해야 하는 첫 미니 프로젝트라 많이 복잡하지 않고 삭제, 수정 기능이 없는 부분도 있어서 가능했다.

하지만 유저 회원 탈퇴, 프로필 수정? 혹은 댓글 삭제 이런 기능을 넣을 생각을 하면 아찔하다.

실제로 내가 메인화면에 상품카드를 띄우는 역할을 맡았었는데 상품 상세페이지를 만드시는 분과 나중에 합쳤을 때 데이터베이스 구조가 달라서 코드가 깨지는 상황이 발생해서 수정하는데 시간이 좀 들었다.

그리고 api가 구조 없이 마구잡이로 생성되어 찾아 헤매는데 시간이 들었고 소통하기도 복잡했다.

검색을 해보니 api설계를 돕는 서비스나 도구들이 있어서 그것들을 활용하는 방법을 배워두면 프로젝트하는 데에 아주 유용할 것 같다.

 

5.15 추가

되돌아보니 몇 주 만에 많이 배웠네요 ㅋㅋ 

jwt에 대해 이해한 내용을 추가합니다.

https://pungwa.tistory.com/101

JWT인증, Access, Refresh token에 대하여