diff --git a/week09/keyword/Keyword.md b/week09/keyword/Keyword.md
new file mode 100644
index 0000000..3658598
--- /dev/null
+++ b/week09/keyword/Keyword.md
@@ -0,0 +1,95 @@
+- OAuth 2.0
+    
+    ### 📌 **정의**
+    
+    OAuth 2.0은 **사용자의 비밀번호를 노출하지 않고도** 제3자 앱이 제한된 접근 권한을 얻도록 해주는 **인증·인가 프로토콜**이다.
+    
+    예: Google 로그인, Naver 로그인, GitHub 로그인 등이 모두 OAuth 2.0 기반.
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - **인가(Authorization) 중심 프로토콜** → 로그인/인증 자체는 OpenID Connect(OIDC)가 담당.
+    - Access Token을 통해 권한 부여.
+    - 다양한 인증 플로우 제공
+        - Authorization Code Flow (가장 일반적)
+        - Implicit Flow
+        - Resource Owner Password Credentials Flow
+        - Client Credentials Flow
+    - 토큰 기반으로 작동 → 서버는 세션 유지 없이 인증 처리 가능.
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - 비밀번호를 외부 앱과 공유하지 않아도 된다 → **보안 강화**
+    - 다양한 플랫폼(웹, 모바일, 서버)에 유연하게 적용
+    - 확장성 높음 (SNS 로그인, 서드파티 API 호출 등)
+    
+    ### 📌 **단점**
+    
+    - 구현이 복잡함 (Redirect, Token Exchange 등)
+    - 올바른 Flow를 선택하지 않으면 보안 취약 가능
+    - Access Token 유출 시 위험
+- JWT
+    
+    ### 📌 **정의**
+    
+    JWT는 JSON 형식의 데이터를 **서명(Signature)** 하여 안전하게 전송하기 위한 **토큰 기반 인증 기술**이다.
+    
+    Access Token, ID Token 등에 주로 사용됨.
+    
+    `HEADER.PAYLOAD.SIGNATURE` 구조로 이루어짐.
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - 클라이언트에 저장되는 **Self-contained Token**
+    - 서버가 세션 정보를 저장하지 않아도 됨(Stateless)
+    - 보통 Base64URL 로 인코딩된 문자열 형태
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - 서버 확장성(Stateless) → 세션 저장소 필요 없음
+    - 다양한 플랫폼에서 쉽게 사용 가능
+    - 서명(Signature) 검증으로 데이터 위변조 방지
+    
+    ### 📌 **단점**
+    
+    - 토큰이 탈취되면 만료 전까지 계속 사용 가능
+    - Payload 내용이 평문(Base64URL)이라 **암호화된 게 아님**
+        
+        → 민감 정보를 절대 넣으면 안 됨!
+        
+    - 토큰 사이즈가 세션 ID보다 큼(대략 1KB+)
+- Bearer Token
+    
+    ### 📌 **정의**
+    
+    “Bearer”는 **소유하고 있는 것만으로 인증됨**을 의미하는 토큰 타입이다.
+    
+    즉, 토큰을 가진 사람은 누구든 요청을 보낼 수 있음.
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - OAuth 2.0의 Access Token 대부분이 Bearer 방식
+    - 별도 암호화나 인증 과정 없음 → **소유 = 권한**
+    - HTTPS 환경에서 사용해야 안전함
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - 단순하고 빠른 인증 방식
+    - 다양한 API에서 표준처럼 사용됨
+    
+    ### 📌 **단점**
+    
+    - 탈취되면 그대로 사용할 수 있어 위험도가 높음
+    - 반드시 HTTPS 사용해야 함
\ No newline at end of file
diff --git a/week09/mission/Mission.md b/week09/mission/Mission.md
new file mode 100644
index 0000000..3738164
--- /dev/null
+++ b/week09/mission/Mission.md
@@ -0,0 +1,84 @@
+## 해야할 미션
+
+1. 기존에 사용자의 정보를 하드 코딩 부분 수정
+2. 자기 자신의 정보를 수정하는 API 제작
+3. 기존 API에 JWT 인증 적용
+
+---
+
+## 1. 사용자 정보 하드코딩 부분 수정
+
+### 기존
+
+- `Bearer access-token-for-user-{id}` 로 access-token 설정 중
+- 해당 access-token에 대해 id를 가져오는 로직 보유 중
+
+### 수정
+
+- access-token을 자체적인 토큰 방식말고 jwt를 사용하여 sign진행
+
+### 결과
+
+- isLogin 미들웨어 추가
+
+<img width="446" height="47" alt="1" src="https://github.com/user-attachments/assets/d97607d1-d7f5-489b-b85e-6f9eb8d4cbfd" />
+
+- 작성자에 대한 올바른 응답
+
+<img width="518" height="395" alt="2" src="https://github.com/user-attachments/assets/b019750d-7467-43a4-88b4-73b9c35e4c1f" />
+
+---
+
+## 2. 자기 자신의 정보 수정 API 제작
+
+### 추가
+
+- Method: `POST`
+- EndPoint: `/mypage/edit`
+- Request Body
+    
+    ```json
+    {
+    	"name": "string",
+    	"gender": 0     // 0이면 남자, 1이면 여자
+    	"birth": "2025-11-25",
+    	"address": "string",
+    	"subaddr": "string"
+    }
+    ```
+    
+- Response Body
+    
+    ```json
+    {
+    	"success": true,
+    	"code": 200,
+    	"message": "사용자 정보가 수정되었습니다",
+    	"data": {
+    		"userId": 1
+    	}
+    }
+    ```
+    
+
+### 결과
+
+<img width="787" height="632" alt="3" src="https://github.com/user-attachments/assets/919ab4f1-3f35-42bd-a9c1-e8c2683e0ca0" />
+
+---
+
+## 3. 기존 API들에 JWT 인증 적용
+
+### 기존
+
+- `Bearer access-token-for-user-{id}` 로 access-token 설정 중
+
+### 수정
+
+- access-token을 자체적인 토큰 방식말고 jwt를 사용하여 인증받을 수 있도록 수정
+
+### 결과
+
+- isLogin 미들웨어를 통해 인증
+
+<img width="600" height="164" alt="4" src="https://github.com/user-attachments/assets/0064cadf-45a8-41ac-8877-42921faa6dde" />
diff --git a/week10/keyword/Keyword.md b/week10/keyword/Keyword.md
new file mode 100644
index 0000000..4a7dcda
--- /dev/null
+++ b/week10/keyword/Keyword.md
@@ -0,0 +1,136 @@
+- CI/CD
+    
+    ### 📌 **정의**
+    
+    CI/CD는 **지속적 통합(Continuous Integration)**, **지속적 배포(Continuous Delivery/Deployment)** 를 의미하는
+    
+    **자동화된 소프트웨어 개발 및 배포 프로세스**이다.
+    
+    코드 변경이 발생하면 자동으로 **빌드 → 테스트 → 배포**까지 진행되는 구조를 따른다.
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - **자동 파이프라인 기반**
+    - Git 이벤트(push, PR, release 등)를 트리거로 실행 가능
+    - 빌드/테스트 실패 시 즉각 피드백
+    - Stateless 테스트 환경에서 실행되는 것이 선호됨
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - 반복 작업 자동화 → **생산성 향상**
+    - 오류를 **초기 단계에서 발견**
+    - 팀 협업 표준화
+    - 배포 안정성 증가
+    
+    ### 📌 **단점**
+    
+    - 처음 구축이 복잡하다
+    - 테스트/배포 시나리오 부실 시 의미 감소
+    - 인프라 비용 및 실행 시간 고려 필요
+    
+    ---
+    
+    ### 📌 **사용 예시**
+    
+    - main 브랜치에 push → 자동 서버 배포
+    - Pull Request 병합 전 → 자동 빌드 & 테스트 실행
+    - 배포 실패 시 → 이전 버전으로 자동 롤백
+- GitHub Actions
+    
+    ### 📌 **정의**
+    
+    GitHub에서 제공하는 **워크플로우 자동 실행 플랫폼**이며,
+    
+    CI/CD 파이프라인 도구로 가장 많이 활용되는 서비스 중 하나이다.
+    
+    `.github/workflows/*.yml` 파일에 동작을 정의하여 실행한다.
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - **Runner 환경 제공 (기본: Ubuntu)**
+    - Git 이벤트 기반 트리거 (push, PR, cron 등)
+    - `GITHUB_TOKEN` 기반 권한 모델 사용
+    - Marketplace에 재사용 가능한 Action 다수
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - GitHub 내부에서 실행 → **연동 간편**
+    - 코드 품질 검사 규칙 강제 가능
+    - 참조할 레퍼런스가 매우 풍부함
+    - 서버 직접 접근 없이 자동 실행·배포 가능
+    
+    ### 📌 **단점**
+    
+    - 워크플로우 복잡 시 디버깅이 어렵다
+    - Free tier Runner 성능 제한 존재
+    - **토큰 권한 부족 → 실행 실패의 주요 원인**
+- Reverse Proxy
+    
+    ### 📌 **정의**
+    
+    외부 클라이언트의 요청을 **프록시 서버가 대신 받아 내부 서버로 전달해주는 중계 방식**이다.
+    
+    내부 서버는 노출되지 않고 **프록시 1개만 외부에 공개**된다.
+    
+    대표: NGINX, Caddy, Traefik 등
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - 외부에서는 **프록시만 접근**
+    - 내부에 여러 대의 애플리케이션 서버 연결 가능
+    - LB(로드밸런싱), 캐싱, 헤더 조작, 접근 제어 가능
+    - HTTPS 인증서 중앙 관리 가능
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - 내부 서버 은닉 → **보안 강화**
+    - 확장(Scale-out) 구조에 매우 적합
+    - 경로/도메인 기반 라우팅 가능
+    - HTTPS 인증서와 Redirect 설정을 중앙에서 처리
+    
+    ### 📌 **단점**
+    
+    - Reverse Proxy 장애 시 전체 영향
+    - 설정 파일 관리가 필요
+    - 네트워크 계층이 1개 추가되어 latency 증가 가능 (매우 미세)
+- HTTPS
+    
+    ### 📌 **정의**
+    
+    **HTTP + SSL/TLS 보안 레이어를 결합한 암호화된 통신 프로토콜**이다.
+    
+    서버–클라이언트 간 데이터가 **암호화되어 안전하게 전달**된다.
+    
+    ---
+    
+    ### 📌 **특징**
+    
+    - 표준 포트 = **443**
+    - 인증서 필요 (대표: Let’s Encrypt 무료 인증서)
+    - Authorization 토큰(Bearer/JWT) 탈취 방지의 **필수 전제조건**
+    - 브라우저에서 **🔒 안전 잠금 표시 제공**
+    
+    ---
+    
+    ### 📌 **장점**
+    
+    - 데이터 도청/변조 방지 (MITM 방지)
+    - 토큰 기반 인증 보안 강화
+    - 사용자와 서버 간 신뢰 인증 제공
+    
+    ### 📌 **단점**
+    
+    - 인증서 자동 갱신이 필요
+    - Handshake 추가됨 (하지만 HTTP/2~3에서는 오히려 빠를 수 있음)
\ No newline at end of file
diff --git a/week10/mission/Mission.md b/week10/mission/Mission.md
new file mode 100644
index 0000000..f2d4bcb
--- /dev/null
+++ b/week10/mission/Mission.md
@@ -0,0 +1,17 @@
+1. GitHub Actions와 AWS EC2를 이용하여 직접 CI/CD 배포 해보기!
+    - 완료
+2. EC2를 이용해 배포한 현재 상태에서 Google 로그인이 동작하지 않는 이유를 확인하고 수정해보기.
+    - 동작하지 않는 이유
+      
+        <img width="608" height="247" alt="01" src="https://github.com/user-attachments/assets/bc52bac8-27ba-4f57-8ac6-c852bc422802" />
+        
+        - 다만, 현재 서버는 내가 지정한 퍼블릭IP에서 진행 중이니 동작 X
+    - 수정 방안 1)
+        
+        <img width="545" height="142" alt="02" src="https://github.com/user-attachments/assets/b59cef21-d067-418d-a6ad-38596e6285d0" />
+
+        - google 설정 상 불가능
+    - 수정 방안 2)
+        - 퍼블릭 IP를 도메인을 통해 감싸서 진행
+
+        - 유료…..