diff --git "a/week2/\352\260\225\352\262\275\353\246\274/2\354\243\274\354\260\250-\354\212\244\355\204\260\353\224\224\352\270\260\353\241\235(\355\224\204\353\241\240\355\212\270\355\214\200).md" "b/week2/\352\260\225\352\262\275\353\246\274/2\354\243\274\354\260\250-\354\212\244\355\204\260\353\224\224\352\270\260\353\241\235(\355\224\204\353\241\240\355\212\270\355\214\200).md"
new file mode 100644
index 0000000..6026820
--- /dev/null
+++ "b/week2/\352\260\225\352\262\275\353\246\274/2\354\243\274\354\260\250-\354\212\244\355\204\260\353\224\224\352\270\260\353\241\235(\355\224\204\353\241\240\355\212\270\355\214\200).md"
@@ -0,0 +1,38 @@
+### 2주차 스터디 정리(프론트팀) - 공통 질문 외에 알아두면 좋을 것
+
+- JWT 장점 (세션,쿠키와 비교):
+    - 간편함. 별도의 저장소 관리 필요 x. 발급하고 검증만 하면 됨. ⇒ stateless한 서버의 유지 보수에 유리.
+    - 확장성이 뛰어남. 토큰 기반의 다른 인증 시스템에 접근 가능.
+- JWT 단점 (세션,쿠키와 비교)
+    - 한번 발급된 건 돌이킬 수 없음. ⇒ 쿠키가 악용되는 경우, 해당하는 세션을 지우면 됨. 근데 JWT가 악용되는 경우, 유효기간이 남아있는 한 그걸 막을 수가 없는 것.
+- 크롬으로 남긴 쿠키를 인터넷 익스플로러에서 사용할 수 있을까?
+
+    ⇒ 아니다. 브라우저마다 저장되는 것이 다르기 때문에 쓸 수 없음.
+
+- 쿠키의 사용 목적
+    - 세션 관리: 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보 관리
+    - 개인화: 사용자 선호, 테마 등의 세팅
+    - 트래킹: 사용자 행등을 기록하고 분석하는 용도
+- 쿠키의 단점:
+    - 보안 취약 (세션이 상대적으로 보안성 높음)
+    - 허용 용량 제한 (세션은 서버 용량만 충분하면 제한 없음)
+    - 네트워크 부하 (쿠키가 한두개면 그렇다치는데, 많으면 네트워크 부하 큼)
+    - 웹 브라우저에 의존적 (세션은 서버에 저장되므로 웹 브라우저에 의존적X)
+- 세션의 단점:
+    - 서버에 부하 (서버가 데이터를 저장하므로 양이 많아 질수록 서버에 부하가 커짐)
+
+    ⇒ 쿠키나 세션 모두 각자 장단점이 있으므로, 둘 가지를 적절히 같이 써서 어떤 정보는 쿠키를 사용하고(클라이언트 쪽으로 넘기고) 어떤 정보는 세션을 사용할지(서버 쪽으로 넘기고) 이걸 판단하는 게 중요함.
+
+    ex) 장바구니 기록은 쿠키를 사용하고, 보안 상 중요한 로그인 정보는 세션을 사용한다든지..
+
+### +) 쿠키의 용량제한 관련(정확X 그냥 이런 얘기가 나왔다~)
+
+![image](https://user-images.githubusercontent.com/80836908/113498856-be234380-954b-11eb-98dc-41bc00928fb9.png)
+
+- 한 도메인 당 20개라는 게 어떤 의미일까
+
+    ⇒ 페북이라 치면, 아이디가 20개까지만 가능하다는 의미일 듯
+
+- 쿠키는 왜 용량 제한을 할까
+
+    ⇒ 파일의 형식으로 저장되기 때문(그 파일의 용량이 4KB). 사생활 침해 방지를 위해서이기도 함.
diff --git "a/week2/\352\260\225\352\262\275\353\246\274/\354\277\240\355\202\244&\354\204\270\354\205\230.md" "b/week2/\352\260\225\352\262\275\353\246\274/\354\277\240\355\202\244&\354\204\270\354\205\230.md"
new file mode 100644
index 0000000..e5e0d6e
--- /dev/null
+++ "b/week2/\352\260\225\352\262\275\353\246\274/\354\277\240\355\202\244&\354\204\270\354\205\230.md"
@@ -0,0 +1,76 @@
+## 세션과 쿠키를 활용한 인증(authentication)의 기본 원리
+
+1. 클라이언트가 아이디와 비번을 입력해서 요청 보냄
+2. 서버가 db에서 아이디와 비번이 일치하는 지 확인하고, 세션을 생성.
+3. 이때 응답으로 쿠키 안에 세션 아이디를 넣어서 응답을 보냄.
+4. 클라이언트 측에서 쿠키를 저장해야하는데, 이때 브라우저가 이걸 하드디스크에 저장.
+5. 그러면 그 후에 클라이언트 요청에는 응답으로 받은 세션 아이디가 같이 보내짐. (브라우저가 쿠키를 보내는 것)
+6. 클라이언트가 요청할 때마다 서버가 하는 일
+    1. 해당 세션 아이디가 있는지 확인
+    2. 그때마다 timeout 연장
+    3. 권한 확인하고 그에 맞는 웹페이지를 보여줌.
+  
+
+## 그 다음 단계
+
+트래픽 늘어나면 하나의 서버가 감당 불가 ⇒ 여러개의 서버를 만들어놓고(서버 분산), 클라이언트와 이들 서버 사이에 로드 밸런서 서버를 놓는다. (LB: 요청에 매칭되는 서버와 연결시켜줌)
+
+![Untitled](https://user-images.githubusercontent.com/80836908/113475970-53bec480-94b3-11eb-8465-09c4455d9772.png)
+
+이때, 발생하는 문제: 
+
+클라이언트가 처음 세션을 발급받은 서버가 아닌 경우에는 매번 로그인을 다시 해줘야 되는 문제
+
+(비디오 서버와 글쓰기 서버가 다른 경우, 글쓰다가 비디오 보려면 로그인 다시 해야됨..)
+
+⇒ 해결: 모든 서버가 공동으로 이용하는 세션 DB에서 세션을 전체적으로 관리 
+
+
+### +) 페이스북과 쿠키...
+
+쿠키의 룰
+
+1. 1개의 도메인에 한정. (페북은 페북 것만 보내고 읽을 수 있음)
+2. 자동으로 생성되고 설정됨.
+
+⇒ 페이스북이 내가 어떤 사이트를 방문하는지 알 수 있을까?
+
+도메인이 다르면 기본적으로 모름.
+
+하지만 내가 방문한 사이트에서 페북에 요청을 보내면, 알 수 있음
+
+** 세션의 이용자가 **사이트를 방문했구나.
+
+
+### +) 추가 공부
+
+JWT (JSON WEB TOKEN)
+
+세션처럼 따로 저장해서 있는지 없는지 확인하는 거 X
+
+매 요청마다 발급받은 토큰만 보내주고, 서버는 그게 올바른 토큰인지만 확인.
+
+
+### 예상 질문
+
+- 쿠키와 세션을 활용한 인증 과정을 설명할 수 있는가?
+- 쿠키와 세션의 차이는?
+    - 저장 위치(쿠키는 클라이언트가 저장하고 위치는 브라우저가 지정하는 메모리 OR 하드디스크. 세션은 서버가 저장하고 위치는 서버의 메모리)
+    - 보안성(세션이 나음)
+    - 속도(쿠키가 더 빠름)
+    - 라이프 사이클(쿠키: 브라우저 종료해도 계속 남아있음. 세션: 브라우저 종료시 삭제)
+
+
+### 참고
+
+세션,쿠키로 로그인을 어떻게 유지시키는가?
+
+[https://www.youtube.com/watch?v=cWUtMHTKdj0](https://www.youtube.com/watch?v=cWUtMHTKdj0)
+
+노마드 코더 - 페이스북과 쿠키의 상관관계? Cookie 기초개념 잡아드림.
+
+[https://youtu.be/1emZgLiGE4s](https://youtu.be/1emZgLiGE4s)
+
+쿠키와 세션 개념 블로그 글
+
+[https://interconnection.tistory.com/74](https://interconnection.tistory.com/74)