Merge pull request #63 from KOOMINSEOK/main

[5,6주차/민] 5주차 워크북 제출합니다

keyword/chapter06/keyword.md

@@ -0,0 +1,177 @@
+- Debounce & Throttling 🍠
+    - Debounce는 무엇일까요?
+        - 연속적으로 발생한 이벤트를 하나로 처리하는 방식
+        - 주로 **처음**이나 **마지막**으로 실행된 함수만을 실행
+    - Debounce는 주로 어디에 사용하나요?
+        - 키워드 검색 혹은 자동완성 기능에서 api 함수 호출 횟수를 최대한 줄이고 싶을때
+        - 사용자가 창크기 조정을 멈출때까지 기다렸다가 resizing Event 를 반영하고 싶을때
+    - Throttling은 무엇일까요?
+        - 이벤트를 일정주기마다 발생하도록 하는 기술
+        - 즉, 마지막 함수가 호출된 후 일정시간이 지나기전에 다시 호출되지 않도록함
+    - Throttling은 주로 어디에 사용하나요?
+        - 스크롤에 많이 사용 (모든 스크롤을 기록하는것 → 성능문제가 있음 , 따라서 특정 시간마다의 스크롤의 위치를 찍어줌)
+    - Debounce와 Throttling의 차이점은 무엇일까요?
+        - Debounce
+
+            입력주기가 끝나면, 출력
+
+            입력이 끝날때까지 무한적으로 대기
+
+        - Throttle
+
+            입력 주기를 방해하지 않고, 일정 시간 동안의 입력을 모아서 한번에 출력
+
+            입력이 시작되면 입력이 끝나지 않아도 일정주기로 실행
+
+
+        ex)
+
+        **Throttle** 는 200ms 마다 api 값을 가져옴 vs **Debounce** 는 입력이 끝난후 api 값을 가져옴 
+
+    - 어떤 기능을 구현할 때 Debounce를 적용하고, Throttling을 적용하는 것이 좋을까요?
+        - Debounce
+            - 리사이즈 이벤트
+            - 검색어 자동완성
+        - Throttling
+            - 스크롤
+            - 무한스크롤 페이지
+            - 애니메이션 프레임
+- 쿠키 🍠
+    - 쿠키란 무엇이고, 어떤 특징을 가지고 있을까요?
+
+        사용자 이름과 비밀번호 등과 같은 작은 데이터 조각이 있는 텍스트 파일로, 사용자가 네트워크를 이용할 때 사용자의 컴퓨터를 식별하기 위해 사용
+
+        - 특징
+            - 쿠키는 클라이언트 로컬에 저장되는 key-value 형태의 데이터 ( 이름, 값, 유효시간, 도메인, 경로 )
+            - 클라이언트 로컬에 저장되기 때문에 상대적으로 변조되기 쉬움
+            - 클라이언트의 상태 정보를 로컬에 저장했다가 request 할 때 참조
+            - **브라우저가 종료되도 유지**(HTTP의 비연결지향 보완)
+        - 종류
+            - 세션 쿠키 ( Session Cookie ) : 웹 브라우저가 종료될 때 제거되는 쿠키
+            - 지속 쿠키 ( Persistent Cookie ) : 유효시간을 정하지 않은 경우 브라우저가 종료되어도 남아 있는 쿠키
+    - 쿠키를 어떻게 사용할 수 있을까요?
+        1. **세션 관리:** 쿠키를 사용하면 웹사이트가 사용자를 인식하고 사용자의 개인 로그인 정보와 기호(스포츠 뉴스 대 정치 등)를 다시 불러올 수 있음
+        2. **개인화:**  맞춤 광고는 쿠키가 세션을 개인화하는 데 사용되는 주된 방법. 사용자는 사이트의 특정 항목이나 부분을 볼 수 있으며, 쿠키는 이 데이터를 사용하여 사용자가 좋아할 수 있는 표적 광고를 만드는 데 도움이 됨. 쿠키는 언어 설정에도 사용
+        3. **추적:** 쇼핑 사이트에서는 쿠키를 사용해 사용자가 이전에 봤던 품목을 추적하여 사용자가 좋아할 수 있는 다른 상품을 제안하고 사용자가 웹사이트의 다른 부분에서 계속 쇼핑하는 동안 상품을 장바구니에 계속 보관할 수 있음. 사용자가 페이지를 방문한 횟수나 사용자가 페이지에서 보낸 시간 같은 퍼포먼스 분석 정보도 추적하고 모니터링 가능
+- 토큰 🍠
+    - 토큰이 왜 필요할까요?
+        - 토큰이란?
+            - 보안 토큰은 사용자가 시스템에 액세스할 때 반드시 소유해야 하는 물리적 디바이스
+            - 아이덴티티와 액세스를 입증하는데 필요한 인증 데이터를 사용자와 시스템 사이에서 옮기는 전달자 역할을 함
+        - 토큰의 장점
+            - **Stateless**
+
+                토큰 기반 인증은 서버에서 사용자의 정보를 가지지 않기 때문에 무상태성을 가져서 서버가 확장을 하여도 문제가 생기지 않음
+
+                상태를 가지는 세션을 사용하는 방식에서 서버를 확장시
+
+                 사용자가 로그인 했을 때, 유저는 처음 로그인한 서버에만 요청하는 문제가 발생 가능
+
+                토큰을 사용시 → 어떠한 서버로 요청이 가도 상관이 없음
+
+            - **모바일 어플리케이션에 적합**
+
+                Android나 iOS 모바일 어플리케이션을 개발할 때, 안전한 API 를 만들기 위해서는 쿠키 컨테이너를 사용해야 하는 쿠키같은 인증시스템은 이상적이지 않음. 만약 토큰 기반 인증을 도입한다면 더욱 간단하게 이 번거로움을 해결 가능
+
+            - **인증정보를 다른 어플리케이션으로 전달**
+
+                페이스북/구글 같은 소셜 계정들을 이용하여 다른 웹서비스에서도 로그인 할 수 있음
+
+            - **보안**
+
+                토큰 기반 인증 시스템을 사용하여 어플리케이션의 보안을 높일 수 있음
+
+    - CORS 에러가 무엇이고, 이 에러를 어떻게 해결할 수 있을까요?
+        - CORS란?
+
+            Cross-Origin Resource Sharing로 '교차(다른) 출처 리소스 공유'를 의미로  Cross-Origin의 Resrouce를 공유하는 정책.
+
+            도메인이 다른 서버끼리 리소스를 주고 받을 때 보안을 위해 설정된 정책임
+
+            ex) 웹 사이트 A가 API 서버 B에서 데이터를 가져오려 할 때,
+
+            API 서버 B에서 CORS 허용 설정이 되어 있지 않으면 웹 브라우저에서 API 접근이 거부될 수 있음
+
+        - 해결방안
+            1. **Chrome 확장 프로그램 이용**
+
+                Chrome에서 CORS 문제를 해결하기 위한 확장프로그램 제공
+
+                설치 후, 로컬 환경에서 Api 테스트 시, CORS 문제 해결
+
+            2. **프록시 사이트 이용하기**
+
+                프록시란 클라이언트와 서버 사이의 중계 대리점으로 모든 출처를 허용한 서버 대리점을 통해 요청하면 문제 해결
+
+            3. **서버에서 Acess-Control-Allow-Origin 헤더 세팅하기**
+
+                직접 서벙에서 HTTP 헤더 설정을 통해 출처 허용하게 설정함
+
+    - JWT 토큰 기반 인증 방법이란 무엇일까요?
+        - JWT(Java Web Token) 토큰이란
+            - 객체에 인증에 필요한 정보들을 담은 후 비밀키로 서명한 토큰으로, **인터넷 표준 인증방식**
+            - 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰
+            - **서명된 토큰**으로. 공개/개인 키를 쌍으로 사용하여 토큰에 서명할 경우
+
+                개인 키를 보유한 서버가 서명된 토큰이 정상적인 토큰인지 인증할 수 있음
+
+        - 장점
+            - 이미 토큰 자체가 인증된 정보이기 때문에 세션 저장소와 같은 별도의 인증 저장소가 "필수적"으로 필요하지 않음
+            - 세션과는 다르게 클라이언트의 상태를 서버가 저장해두지 않아도 .
+            - signature를 공통키 개인키 암호화를 통해 막아두었기 때문에 데이터에 대한 보완성이 늘어남
+            - 다른 서비스에 이용할 수 있는 공통적인 스펙으로써 사용 가능
+        - 단점
+            - 네트워크 전달 시 많은 데이터량으로 부하가 생길 수 있음
+            - Payload에는 암호화가 되어있지 않기 때문에 민감 정보를 저장할 수 없음
+            - 토큰이 탈취당하면 만료될 때까지 대처가 불가능
+    - JWT 기반 로그인 동작 과정에 대해 알아보세요.
+
+        ![image.png](https://prod-files-secure.s3.us-west-2.amazonaws.com/f1912130-0409-4e90-a90f-6091ae253e73/a7930292-819d-4c3b-b374-f7b8b4390cce/image.png)
+
+        1. 사용자는 id(or email) 과 password를 입력하고 서버로 요청을 보냄
+        2. 서버는 db에서 회원을 조회하고 등록된 사용자인지 확인
+        3. 등록된 사용자라면 서버는 토큰(Access Token)을 생성하고 프론트로 토큰과 함께 응답을 보냄
+        4. 응답이 성공적으로 왔다면 로그인(인증)이 성공적으로 이루어 진 것이고 이후 요청에 token(JWT)함께 보냄
+        5. 서버는 로그인 이후의 요청에 함께 실려온 토큰을 검증하는 과정을 검증이 성공적으로 끝났다면 권한이 있는 사용자라고 생각하고 요청된 데이터를 응답해 줌
+    - AccessToken / RefreshToken의 차이에 대해 설명해주세요.
+        - **Access Token** :  인증된 유저인지 서버에서 검증하는 토큰. client 쪽에서 요청 헤더에 담아 보내는 토큰
+        - **Refresh Token :** access token이 만료되거나 잘못된 토큰일 경우 refresh token을 사용해 유저 검증. 만약 refresh token을 검증하여 인증된 유저일 경우 access token을 재발행 해줌
+
+        access token의 유효기간을 짧게 설정하고 refresh token의 유효기간을 길게 설정하여 access token 만료시 refresh token을 검증하여 access token을 재발행 해주는 것으로 보안적으로 안전하게 유저 인증을 관리
+
+- 웹 스토리지 🍠
+    - 웹 스토리지의 메소드와 프로퍼티는 어떤게 있을까요?
+        - **웹 스토리지의 주요 메소드**
+            - `setItem(key, value)`: 데이터를 저장합니다.
+            - `getItem(key)`: 저장된 데이터를 불러옵니다.
+            - `removeItem(key)`: 특정 데이터를 삭제합니다.
+            - `clear()`: 모든 데이터를 삭제합니다.
+        - **웹 스토리지의 주요 프로퍼티**
+            - `length`: 저장된 데이터의 개수를 반환합니다.
+    - 세션 스토리지에 대해 정리해 주세요!
+
+        **세션 스토리지(Session Storage)**는 **현재 세션 동안만 유지되는 데이터 저장소**입니다. 브라우저 창이나 탭이 닫히면 저장된 데이터는 자동으로 삭제됩니다. 각 창이나 탭은 개별 세션을 가지므로 독립적으로 저장됩니다.
+
+    - 로컬 스토리지에 대해 정리해 주세요!
+
+        **로컬 스토리지(Local Storage)**는 **브라우저에 영구적으로 저장되는 데이터 저장소**입니다. 세션이 종료되어도 데이터가 삭제되지 않으며, 사용자가 수동으로 삭제하거나 코드로 삭제하기 전까지 유지됩니다.
+
+    - 로컬 스토리지에서 JWT 토큰을 저장하고, 사용하고, 삭제하는 메소드에 대해 찾아보세요!
+        - **저장**: `localStorage.setItem('token', jwtToken)`
+        - **사용**: `localStorage.getItem('token')`
+        - **삭제**: `localStorage.removeItem('token')`
+    - 스토리지가 변경되었을 때 처리하는 방법을 조사해 주세요.
+
+        `storage` 이벤트를 사용하여 스토리지에 변화가 생겼을 때 이를 감지하고 특정 처리를 할 수 있습니다. 이벤트 리스너를 통해 다른 탭이나 창에서 일어난 스토리지 변경을 실시간으로 반영할 수 있습니다.
+
+    - Bearer Token이 무엇인지 찾아보고, 이를 통해 백엔드 서버와 어떠한 방식으로 통신하는지 조사해 보세요!
+        - **Bearer Token**은 HTTP `Authorization` 헤더에 포함되어 전송되는 인증 토큰입니다. 사용자는 JWT와 같은 토큰을 "Bearer" 타입으로 보내며, 서버는 이를 통해 사용자 인증을 수행합니다.
+        - **통신 방식**: 클라이언트는 각 요청의 `Authorization` 헤더에 `Bearer {토큰}`을 포함하여 백엔드 서버에 전송하며, 서버는 이를 검증하여 요청이 유효한지 확인합니다.
+- Context-API 🍠
+    - 전역 상태 관리는 왜 해야할까요?
+
+        여러 컴포넌트에서 동일한 데이터를 참조하거나 수정할 때, 데이터를 한곳에서 관리하여 **일관성**을 유지하고 **상태 전파를 쉽게** 하기 위해 전역 상태 관리가 필요합니다. 이를 통해 **코드 중복을 줄이고** 상태 변경 시 여러 컴포넌트에서 데이터를 쉽게 동기화할 수 있습니다.
+
+    - Context API란 무엇일까요?
+        - **Context API**는 React에서 전역적으로 데이터를 관리하고 제공하는 방법입니다. 데이터 공급자(Provider)와 데이터 소비자(Consumer)를 통해 컴포넌트 트리의 깊은 곳에 있는 컴포넌트에서도 손쉽게 상태나 함수를 전달할 수 있습니다.
+        - 주로 **Theme 설정, 로그인 정보**와 같이 여러 컴포넌트에서 공통으로 필요로 하는 상태를 제공할 때 유용하게 사용됩니다.