> [!date] published: 2023-03-14 ## 세션이란 무엇인가 세션이란 명확하게 실체가 있는 것이 아니므로 세션의 기술적 실체를 알아보자 --- 로그인 : 신원을 증명. 이 때 Token을 사용하게 됨 (Token : 물리적인 데이터 조각) 매번 토큰을 들고 요청을 하게 되는 것이 이론적으로 맞는데, 실제로는 그렇게 하지 않는다. 대화의 Context가 유지되기 때문에 매번 Token을 내밀지 않아도 되는 것. --- 서비스가 브라우저에 표시를 해 두고. **브라우저에서 요청을 보낼 때 세션 아이디를 보내게 한다.** 서버가 유저를 세션 아이디로 식별하게 되는 것 ➡️ **세션 방식 로그인** --- 그래서 세션이란 (사실 명확한 정의는 없음) ➡️ 사용자의 로그인 이후부터 로그아웃 혹은 로그인 만료까지의 기간 세션 방식 로그인이란 사용자 로그인이 유효한 시간동안 서버에 세션 아이디를 저장해 두고 인증에 사용하는 방식 ## 쿠키란 무엇인가 [HTTP 쿠키 - HTTP \| MDN](https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies) **서버가 브라우저에 전송하는 작은 데이터 조각** 동일한 서버에 요청할 때 쿠키를 들고 요청합니다. 중요한 건 서버가 브라우저에 전송하고, 브라우저는 저장해뒀다가 쓰면 된다. ### 쿠키가 동작하는 방식 쿠키는 직접 넣어주는 값이 아닌 브라우저의 내장 기능으로만 사용합니다. 우리가 필요한 것은 값을 넣어주기 위한 설정을 해야 하는것 ### 쿠키 관련 정책 - Samesite : 같은 도메인에서만 저장하고 전송할것인가 ? - None : 아무데나 저장하고 전송함. 사랑의 쿠키 나눔 - Strict : 동일 출처만 신뢰한다. - Lax : 대부분 strict로 취급하지만 안전한 요청 (get, ...) 에는 CORS를 제공한다. 이래서 Strict이나 Lax인 경우에는 중간에 모아주는 작업을 해 줘야 (프록시 서버를 둔다거나) CORS 이슈가 발생하지 않는다. - Httponly : 자바스크립트로 쿠키에 접근할 수 없게 한다. 이 설정을 켜 두면 FE에서는 쿠키에 직접 접근할 방법이 없음. - Secure : HTTPS만 사용 ## CORS Cross-Origin-Resource-Sharing 내 도메인에서 온 게 아닌데 어떻게 신뢰하지? 출처가 다른 요청에 대해 처리하는 정책 ## 실전 ### 실제 서비스가 되기 위해서 더 필요한 것 - 로그아웃 : 들고 있는 세션을 버린다. - 세션 만료, 세션 연장 기능 - 권한 관리 : 유저마다 접근할 수 있는 정보가 달라야 할 수도 있다. (게시물 수정이라던가..) ### 세션 vs JWT - JWT - 서버 / 백엔드 비용이 감소한다. - 프론트엔드의 복잡도가 높아진다. - 보안상 세션보다 더 위험하다. (Refresh Token Rotation 같은 것들로 보완 가능할지도?) - Session - 서버 / 백엔드 비용이 대폭 증가한다. (Load Balancer ...) - 프론트엔드에서의 인증 과정이 간단해진다. - 보안이 JWT에 비해서는 좋음 (피싱사이트.. 는 만들 수 있다.) 무엇을 선택해야 하는가 - 동시접속자 수 - 서비스 규모 - 앱/웹 동시에? - 팀 내 인력의 구성.. - ... 이런 여러가지 상황을 고려해서 결정해야 합니다. ## ETC ### 이상적인 프로젝트 디렉토리 구조? (와 진짜 너무 궁금했음 감사합니다!!!!) 근데 이걸 왜 궁금해 했는지를 먼저 생각해 봅시다. ➡️ 내 경우에는 팀원들이 내가 구성한 디렉토리 구조 상에서 파일을 잘 찾지 못하길래.. 였음 근데 강의를 들어보니 국룰은 없고. 협의의 과정이 없었기 때문이 아니었을까... 하는 생각이 들었다... 어쨌든 기능상 문제가 없는 선에서라면 협의 하에 팀원들끼리 잘 알아볼 수 있는 방향으로 구조를 짜서 그걸 국룰로 삼는게 맞다 라는 의견... 인 것 같다. 어찌되었든 프로젝트 디렉토리 구조를 잘 짜기 위한 목적은 생산성을 위함이니까요. --- 폴더를 나누는 기준을 생각해봅시다. 강사님은 Src 폴더 안에서 (asset 들은 제외합시다! ) 내가 뭘 하려고 하는지를 생각해보는 편이라고 하심. ``` └── src ├── api ├── atoms ├── component ├── hooks ├── layout ├── pages ├── types ├── utils └── ... ``` 뭐 이런 식으로? ### 무물보 (를 빙자한 내생각) 전역상태 vs useState : 이 값이 여러 컴포넌트에 사용되는 값인지를 생각해서 결정합니다. 웹팩이란 ? 번들러입니다. tsx, ts : tsx 파일은 jsx 문법을 사용하는 파일입니다. asset을 src 아래에 두지 않는 이유 : src 아래에 두면 자바스크립트에 반응하는 ? 객체가 됩니다 ? 하지만 public 아래에 두면 경로에 상관 없이 바로 갖다 쓰게 된다는 장점이 있다... (잘 모르겠다면 webpack 이런 번들러에 대해서 공부해보도록 합시다.) ➡️ public 폴더 안에 넣으면 import 되지 않음. 이게 맞음. 이미지를 이미지 태그로 쓰느냐, 아니면 div 태그로 쓰고 js로 불러오느냐 의 차이인 것 같음... (공부해봐야겠다.) 리덕스를 모르는 채로 리코일만 알고 있어도... 근데 내 생각에는 시간 있으면 공부하는게 맞는 것 같은데 역시 알고 있는게 좋겠다고 말씀하심 에러만 잡다가 아무것도 못하는 신입이 있을까요 ? ➡️ 에러 잡다가 아무것도 못하는 5년차도 있습니다. 사실 내 능력껏 했는데 아무것도 못하는 경우에는 내 탓도 없다고는 할 수는 없지만 PM이 이런저런 전략으로 커버해줘도 됩니다. (신입이면 시니어를 붙여준다거나...) 잘 못해서 진행이 더뎌지는건 상관이 없지만 근데 잘 모르겠으면 바로바로 말을 해야 한다는건 중요합니다... (뭔가 위안이 된다.) TDD : 프론트에선 별로? 새로운 기술을 공부할 때? ➡️ 아는게 하나도 없다면 그냥 책을 하나 정독하는 것? ➡️ 만약에 아는게 조금 있다면 일단 써보는 것도 좋은 것 같습니다. 컴포넌트 설계 방식 : atomic 하게 하는 곳도 있고 암튼 다양함. 회사 전체에서 공통된 설계 방식은 사용하지 않는 것 같음 TS 짱인거같아여 (절대적으로 내 생각임) 프론트는 유저와의 커뮤니케이션이 중점이 되기 때문에 아무래도 백엔드와는 중점을 두고 있는 **개념**들이 다를 수 있습니다. --- 신입 프로젝트 - 완성도 (는 어느정도 있어야 합니다. (내가 생각해도..)) - 기획력 (은 사실 신입에겐 별 기대가 없을지도) - 많은 기술스택을 경험 (강사님 주관으로는 그렇게 많을 필요는 없을듯) - 하지만 너무 얕게 아는건 좀 별로인 것 같습니다. (강사님 주관으로는 오히려 깊게 공부하는 쪽이 좋다고 하심) --- 주니어 레벨인 경우 주어진 디자인을 CSS로 구현할 수 있는 정보만 충!분!합니다. (ㅜㅜ 블로그 디자인 짜야하는데) follower의 입장이라면 나의 능력에 대해서 너무 걱정하고 있을 필요는 없다는 것 같다... 내 능력을 판단해서 나를 써준 사람은 leader이기 때문에 일단 자부심을 갖고 있는것도... 좋은 것 같음 (전적으로 내 생각임) 하지만 뭔가 그래도 내가 뭔가 놓치고 있다는 생각이 든다면 leader와 의논해 봅시다. --- 뭔가 지금 무물보에 전반적으로 둘 중 하나만 공부해야 한다면? 이라는 질문이 많은데 전반적인 답변은 그냥 둘 다임... 솔직히 맞는 것 같음.