diff --git a/keyword/chapter09/README.md b/keyword/chapter09/README.md
new file mode 100644
index 0000000..88c57b5
--- /dev/null
+++ b/keyword/chapter09/README.md
@@ -0,0 +1,196 @@
+- OAuth 2.0
+  https://engineerinsight.tistory.com/163#google_vignette
+  https://ksh-coding.tistory.com/62
+  ***
+  ## OAuth 2.0이란
+  OAuth(”Open Authorization”)는 인터넷 사용자들이 **비밀번호를 제공하지 않고** 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 **접근 권한을 부여할 수 있는 공통적인 수단으로 사용되는, 접근 위임을 위한 개방형 표준**이다.
+  - 사용자가 자신의 계정 정보를 공유하지 않고, 다른 서비스에 대한 접근 권한을 안전하게 제공하는 서비스
+  - OAuth를 지원하는 서비스는 사용자로부터 인증을 받은 후, 해당 서비스에 대한 접근 권한을 받는다.
+    > **‘인증은 유저가 직접, 권한은 서비스에게’**
+  ### 탄생 이유
+  | 주체      | 문제                    |
+  | --------- | ----------------------- |
+  | 사용자    | ID/PW를 못 믿고 넘김    |
+  | 서비스(A) | 비밀번호 유출 책임 100% |
+  | 네이버    | 외부 서비스 신뢰 불가   |
+  - **ID/PW는 인증 서버만 알게 하고**
+  - 서비스는 토큰만 받게 만들자 → OAuth 탄생
+  ***
+  ### OAuth 내 역할
+  ![image.png](attachment:1a140bc2-c0be-437e-9524-cfb8ebf37e8d:image.png)
+  **1. Resource Owner (자원 소유자) == 실제 사용자**
+  > 자기 리소스를 가진 사람 = 사용자
+  - 네이버, 구글, 카카오 계정을 실제로 가진 사람
+  - 아이디/비밀번호 입력 주체
+  - "이 서비스에게 접근 권한 줄래?" 결정 주체
+    **2. Client (클라이언트) == 내 서비스**
+    > 정보가 필요한 나의 서비스 서버
+  - 사용자 정보가 필요한 서비스
+  - 직접 로그인하지 않음
+  - Authorization Server에 인증 위임
+  - 토큰 받아서 Resource Server 호출
+    **3. Authorization Server == 네이버 소셜 로그인 인증 서버**
+    > 로그인 담당 서버
+  - 사용자 인증 담당
+  - scope 동의 관리
+  - 토큰 발급
+    **4. Resource Server == 네이버에서 사용자 리소스를 관리/제공하는 서버**
+    > 사용자 데이터가 있는 서버
+  - 프로필 제공
+  - 이메일 제공
+  - 캘린더 제공
+  - 친구 목록 제공
+    > **Authorization Server ≠ Resource Server
+    > 둘은 같을 수도 있고 다를 수도 있음**
+    > Authorization Server는 토큰 발급자
+    >
+    > Resource Server는 **API 제공자**
+  ***
+  ### 흐름
+  ![image.png](attachment:07e0addb-972d-45c7-8184-70d6b51f7c58:image.png)
+  ![image.png](attachment:55e7026a-f806-47dc-b0e6-f4f718dfb06a:image.png)
+  - **사용자 - Resource Owner**
+  - **서비스(사용자가 이용하려는 서비스) - Client**
+  - **PAYCO 인증 서비스 - Authorization Server**
+  - **PAYCO API 서비스 - Resource Server**
+  ***
+  ### ETC.
+  ### **OAuth 는 로그인에 한정된 것이 아니다.**
+  OAuth 프로토콜은 로그인을 하기 위해 만들어진 것이 아니다. 이름부터 OpenAuthorization (인가) 이기 때문에 로그인 뿐만 아니라 Client 가 Resource Server 에서 사용할 수 있는 권한이 포함되어 있다. 로그인 접근 권한도 그 권한 중에 하나인 것이다. 필요에 따라 Resource Owner 가 허용하면 Resource Server 로부터 데이터파일 등 다른 권한도 부여받을 수 있다.
+  (어디에 쓸수있는지는 더 알아볼것)
+  ### **OAuth 1.0 vs. OAuth 2.0**
+  Auth 2.0 은 OAuth 1.0 에서 보안적인 부분이 개선되었다.
+  - 만료 기한이 없었던 Access Token 은 만료 기한이 생겼다. Client 가 관리하는 Access Token 이 만료되면 다시 사용자에게 권한을 부여받아야 하는데, 매번 만료될 때마다 물어보는 것은 불필요하다. 따라서 Refresh Token 개념이 나오게 되었고, Access Token 이 만료되면 Refresh Token 으로 Resource Server 로부터 새로운 Access Token 을 발급받을 수 있다.
+  ***
+- JWT
+  https://ivory-room.tistory.com/88
+
+  ***
+
+  ### **JWT란?**
+
+  > JWT는 authentication 상태를 저장하지 않고
+  >
+  > 사용자 신원을 증명하는 stateless 인증 토큰이다.
+  > JWT = 위조 불가능한 인증 토큰
+  > **JWT = 서명(Signature) 기반 토큰이다.**
+  > | 특징 | 설명 |
+  > | -------------- | ---------------------------------- |
+  > | Stateless | 서버가 로그인 상태를 저장하지 않음 |
+  > | Self-contained | 토큰 안에 인증 정보 포함 |
+  > | Tamper-proof | 위변조 여부 검증 가능 |
+  > | Portable | 어디든 전송 가능 (Header / Cookie) |
+  > ![image.png](attachment:5ab9c181-ff90-4161-b356-603acf9dc69f:image.png) > **JWT는 "암호화된 데이터"가 아니다.**
+  > JWT의 payload는:
+  > 단순한 Base64 인코딩일 뿐
+  >
+  > → 누구나 디코딩 가능
+
+  ### 그럼 JWT 보안은 어디서 나오냐?
+
+  JWT의 보안은 서명(Signature)에서 나온다.
+  **서명이 하는 일:**
+  | 기능 | 설명 |
+  | ----------- | ------------------------ |
+  | 위조 방지 | payload 조작 불가 |
+  | 무결성 검증 | 데이터가 바뀌었는지 확인 |
+  | 발급자 인증 | 서버가 발급했는지 증명 |
+
+  ### but…
+
+  **서명은 내용을 숨기지 않는다.**
+
+  ### 그래서…
+
+  JWT가 보장하는 것
+
+  - 변조 감지
+  - 발급자 확인
+    JWT가 보장 안 하는 것
+  - 내용 비공개
+
+  - 기밀성
+
+  - 데이터 숨김
+
+  ### 실제 운영 환경에서는 HTTPS가 암호화 담당
+
+  > TLS가 네트워크 암호화
+  >
+  > JWT는 무결성 담당
+  > ⇒ 만약 JWT 자체를 암호화 해야된다면 JWE 사용
+
+  ### 그래서 결론적으로
+
+  > JWT는 기본적으로 암호화가 아니라 서명 기반 무결성 토큰이다.
+  >
+  > Payload는 누구나 디코딩 가능하고, 위변조만 방지한다.
+  >
+  > 내용 보호가 필요할 경우 JWE를 사용한다.
+
+  ***
+
+  ### ETC.
+
+  > 해시 ≠ 암호화
+  >
+  > 해시 ≠ 서명
+  >
+  > 서명은 "해시 + 비밀키"
+  > **같은거라 생각했는데, 서로 살짝 다른 느낌.**
+  > 암호화는 데이터 내용을 보호하는 기술이며,
+  >
+  > 해시와 서명은 무결성과 위변조 방지를 위한 기술이다.
+  > ⇒ 해쉬 + 비밀키는 **확인용**이지, **보기용**이 아니다.
+  > | 개념 | 목적 | 되돌림 | 숨김 |
+  > | ------ | ----------- | ------ | ---- |
+  > | 해시 | 무결성/지문 | 불가 | X |
+  > | 암호화 | 기밀성 | 가능 | O |
+  > | 서명 | 위조 방지 | 불가 | X |
+
+  ***
+
+- Bearer Token
+  https://apidog.com/kr/blog/jwt-vs-bearer-token-2/
+  ***
+  > JWT는 무엇을 담았느냐,
+  >
+  > Bearer는 **어떻게 보내느냐**의 차이다.
+  ### Bearer 토큰이란?
+  Bearer Token은 **토큰 전달 방식**이다.
+  ```
+  Authorization: Bearer <Token>
+  ```
+  이 말의 의미는:
+  > 이 토큰을 가진 자를 사용자로 인정한다.
+  ***
+  ### Bearer Token의 특징
+  - 토큰을 들고 있으면 권한 인정 (**Bearer Token은 소유 기반 인증이다)**
+  - 토큰 안 구조는 중요하지 않음
+  - JWT도 Bearer 토큰으로 전달 가능
+  - OAuth Access Token도 Bearer 방식 사용
+  ### 장단점
+  장점:
+  - 구현 단순
+  - 다양한 토큰 형식과 호환
+  - API 인증 표준 방식
+    단점:
+  - 유출 시 바로 계정 탈취 가능
+  - 서버 측 제어 없으면 폐기 어려움
+  - HTTPS 없으면 매우 위험 (자체 암호화 X)
+  ***
+  Bearer Token은 소유한 사람이 주인이라고 생각하는 방식.
+  > 즉, 훔친 사람도 주인이다.
+  ### 그래서 필수
+  - HTTPS
+  - 만료 시간(exp)
+  - Refresh Token
+  ## 보안 핵심 원칙
+  Bearer든 JWT든 **보안을 지키는 것은 HTTPS**이다.
+  토큰 자체가 안전한 것이 아니다.
+  전달 경로가 안전해야 한다.
+  ***
+  ### 결론
+  > Bearer Token은 Authorization 헤더에 포함되는 토큰 전달 정책이며, 토큰 소유 여부만으로 인증을 수행하는 방식이다.
+  > 기존에는 비밀번호를 직접 전달하는 인증 방식이라 위험했지만, Bearer Token 방식은 만료 가능한 권한만 전달하므로 안전!
+  ***
diff --git a/keyword/chapter10/README.md b/keyword/chapter10/README.md
new file mode 100644
index 0000000..673cde6
--- /dev/null
+++ b/keyword/chapter10/README.md
@@ -0,0 +1,468 @@
+- CI/CD
+  https://ccomccomhan.tistory.com/297
+  ***
+  # CI/CD
+  ## 1. 기존 개발·배포 방식의 문제점
+  전통적인 개발 환경에서는 다음과 같은 흐름이 일반적이었다.
+  - 개발자가 각자 코드를 작성
+  - 일정 시점에 수동으로 코드 병합
+  - 사람이 직접 빌드, 테스트, 배포 수행
+    이 방식의 문제점은 다음과 같다.
+  - 코드 병합 시 충돌 발생 가능성 큼
+  - 테스트 누락으로 인한 오류가 운영 환경에서 발견됨
+  - 배포 과정이 복잡하고 사람 실수에 의존
+  - 배포가 야간이나 특정 인력에게 집중됨
+  - 장애 발생 시 원인 추적과 복구가 느림
+    이러한 문제로 인해 개발 속도는 느려지고, 배포는 위험한 작업이 되었다.
+  ***
+  ## 2. CI/CD의 목적
+  CI/CD는 위와 같은 문제를 해결하기 위해 등장한 **개발·배포 자동화 방식**이다.
+  핵심 목적은 다음과 같다.
+  - 코드 통합 과정에서의 오류를 조기에 발견
+  - 반복적인 수작업 제거
+  - 배포 속도 향상
+  - 운영 안정성 확보
+  ***
+  # CI (Continuous Integration, 지속적 통합)
+  ### 정의
+  CI는 개발자가 작성한 코드를 **자주 저장소에 병합하고**,
+  그때마다 **자동으로 빌드와 테스트를 수행하는 과정**이다.
+  ### CI의 핵심 개념
+  1. **빈번한 코드 병합**
+     - 작은 단위로 개발
+     - 자주 merge하여 충돌 최소화
+  2. **통합 과정의 자동화**
+     - 코드 변경 시 자동으로 빌드
+     - 자동 테스트(Unit Test, Integration Test 등) 수행
+     - 실패 시 병합 차단
+     -
+  ### CI 흐름
+  1. 개발자가 코드 수정
+  2. Git 저장소에 push 또는 PR 생성
+  3. CI 파이프라인 실행
+     - 빌드
+     - 테스트
+  4. 성공 시 병합 가능, 실패 시 병합 불가
+  ### CI의 효과
+  - 코드 충돌 조기 발견
+  - 오류의 원인을 빠르게 특정 가능
+  - 코드 품질 유지
+  - 통합 과정에 대한 신뢰성 확보
+  ***
+  ***
+  ***
+  # CD (Continuous Delivery / Continuous Deployment)
+  CD는 CI를 통과한 코드를 **배포 단계까지 자동으로 연결하는 개념**이다.
+  CD는 두 가지로 구분된다.
+  ### Continuous Delivery (지속적 전달)
+  - 빌드, 테스트, 스테이징 배포까지 자동화
+  - 운영 서버 배포는 **수동 승인**
+    특징:
+  - 안정성 중시
+  - QA 또는 검증 단계 필요
+  - 배포 자체는 버튼 한 번으로 가능
+  ### 4-2. Continuous Deployment (지속적 배포)
+  - 테스트를 통과한 코드가 **자동으로 운영 서버에 배포**
+  - 사람의 개입 없음
+    특징:
+  - 배포 속도 중시
+  - 잦은 기능 개선에 적합
+  - 자동 롤백, 모니터링 체계 중요
+  ***
+  ## 5. CI와 CD의 차이
+  - CI: 코드 **통합과 검증**에 초점
+  - CD: 검증된 코드를 **배포 또는 배포 직전까지 전달**하는 단계
+    CI는 CD의 전제 조건이며,
+    CI → CD로 이어지는 전체 흐름을 **CI/CD 파이프라인**이라고 한다.
+  ***
+  ## 6. CI/CD 파이프라인 전체 흐름
+  1. 코드 작성
+  2. Git 저장소 반영
+  3. CI
+     - 자동 빌드
+     - 자동 테스트
+  4. CD
+     - 스테이징 배포
+     - 운영 배포(수동 또는 자동)
+  5. 배포 후 모니터링
+  6. 문제 발생 시 자동 감지 및 롤백 가능
+     모든 과정은 미리 정의된 규칙에 따라 자동으로 수행되며, 로그로 기록된다.
+  ***
+  ## 7. CI/CD가 필요한 이유 정리
+  - 반복 작업 자동화 → 실수 감소
+  - 배포 주기 단축
+  - 장애 대응 속도 향상
+  - 개발자는 기능 개발에 집중 가능
+  - 배포가 위험한 이벤트가 아닌 일상적인 작업이 됨
+  ***
+- GitHub Actions
+  https://velog.io/@ggong/Github-Action%EC%97%90-%EB%8C%80%ED%95%9C-%EC%86%8C%EA%B0%9C%EC%99%80-%EC%82%AC%EC%9A%A9%EB%B2%95
+
+  ***
+
+  ## GitHub Actions란
+
+  - GitHub에서 공식 제공하는 **CI/CD 자동화 도구**
+  - GitHub Repository에서 발생하는 이벤트를 기준으로
+    - 빌드
+    - 테스트
+    - 배포
+    - 기타 반복 작업
+      을 **자동으로 실행**할 수 있게 해줌
+  - 설정은 **YAML 파일**로 작성
+    설정 파일 위치:
+
+  ```yaml
+  .github/workflows/*.yaml
+  ```
+
+  ***
+
+  ### **GitHub Actions 전체 구조 개요**
+
+  ```yaml
+  Event
+  ↓
+  Workflow
+  ↓
+  Job
+  ↓
+  Step
+  ↓
+  Action / Command
+  ```
+
+  ### Work Flow 전체 설정 예시
+
+  ```yaml
+  # ================================
+  # Workflow 전체 설정
+  # ================================
+
+  # GitHub Actions 탭에 표시될 workflow 이름
+  name: example-github-actions-workflow
+
+  # ================================
+  # Event (Workflow 트리거 조건)
+  # ================================
+  # 어떤 이벤트가 발생했을 때 이 workflow를 실행할지 정의
+  on:
+    # main 브랜치에 push가 발생하면 실행
+    push:
+      branches: [ main ]
+
+    # main 브랜치로 pull request가 생성되면 실행
+    pull_request:
+      branches: [ main ]
+
+  # ================================
+  # Job 정의
+  # ================================
+  jobs:
+    build-and-test:
+      # 이 job이 실행될 Runner(OS)
+      runs-on: ubuntu-latest
+
+      # ================================
+      # Step 정의 (순차 실행)
+      # ================================
+      steps:
+        # Step 1: 레포지토리 코드 체크아웃
+        # GitHub Actions에서 제공하는 공식 Action
+        - name: Checkout repository
+          uses: actions/checkout@v4
+
+        # Step 2: Node.js 환경 설정
+        # Marketplace Action 사용
+        - name: Setup Node.js
+          uses: actions/setup-node@v4
+          with:
+            node-version: 18
+
+        # Step 3: 의존성 설치
+        # run은 Runner의 shell에서 명령 실행
+        - name: Install dependencies
+          run: npm install
+
+        # Step 4: 테스트 실행
+        - name: Run tests
+          run: npm test
+
+        # Step 5: 빌드 실행
+        - name: Build project
+          run: npm run build
+
+        # Step 6: 실행 확인용 로그 출력
+        - name: Print job status
+          run: echo "Job finished with status: ${{ job.status }}"
+  ```
+
+  ## workflow 구조 정리
+
+  ### 1. Workflow
+
+  ```yaml
+  name:
+  on:
+  jobs:
+  ```
+
+  - YAML 파일 하나 = Workflow 하나
+  - 자동화 전체 흐름 정의
+
+  ***
+
+  ### 2. Event
+
+  ```yaml
+  on:
+  push:
+  pull_request:
+  ```
+
+  - Workflow를 실행시키는 트리거
+  - push, PR, schedule 등 가능
+
+  ***
+
+  ### 3. Job
+
+  ```yaml
+  jobs:
+  build-and-test:
+  runs-on:
+  ```
+
+  - Workflow 안의 실행 단위
+  - 하나의 Runner에서 실행됨
+  - 여러 Job 만들면 병렬 실행 가능
+
+  ***
+
+  ### 4. Runner
+
+  ```yaml
+  runs-on:ubuntu-latest
+  ```
+
+  - Job이 실제로 실행되는 가상 머신
+  - GitHub에서 제공
+
+  ***
+
+  ### 5. Step
+
+  ```yaml
+  steps:
+  -name:
+  run/uses
+  ```
+
+  - Job 내부에서 순서대로 실행
+  - 실패하면 Job 전체 실패
+
+  ***
+
+  ### 6. Action
+
+  ```yaml
+  uses:actions/checkout@v4
+  ```
+
+  - Step에서 사용하는 재사용 가능한 작업
+  - Marketplace 또는 커스텀 Action 가능
+
+  ***
+
+  ### 7. run vs uses 차이
+
+  - `run`
+    → 쉘 명령 직접 실행
+  - `uses`
+    → 이미 만들어진 Action 실행
+
+  ***
+
+  ### ETC) **Managed CI/CD**
+
+  - **내부적으로는 전부 CI/CD 도구**를 쓰되
+  - **사용자가 설정 파일을 거의 안 만지게** 추상화해둔 것임
+    | 항목 | GitHub Actions | Vercel / Cloud Build |
+    | --------- | -------------------- | -------------------- |
+    | 설정 | 내가 YAML 직접 작성 | 대부분 자동 |
+    | 유연성 | 최강 | 제한적 |
+    | 러너 | GitHub / Self-hosted | 플랫폼 전용 |
+    | 배포 대상 | 아무 데나 | 자기 플랫폼 최적화 |
+    | 난이도 | 중~상 | 하 |
+
+- Reverse Proxy
+  https://velog.io/@jmjmjmz732002/Infra-Reverse-Proxy..-%EA%B3%BC%EC%97%B0-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C%EC%9A%94
+  ***
+  # Reverse Proxy & Nginx
+  ***
+  ## Proxy 개념
+  ### Proxy란
+  - ‘대리’라는 의미
+  - **클라이언트와 서버 사이에서 요청과 응답을 중계하는 서버**
+  - 네트워크 상에서 **중간 게이트 역할**
+    프록시 서버의 기본 역할:
+  - 요청 중계
+  - 응답 캐싱
+  - 보안 및 접근 제어
+  - 트래픽 제어
+  ***
+  ***
+  ## Proxy 서버의 종류
+  프록시 서버는 **위치 기준**으로 두 가지로 나뉜다.
+  ### Forward Proxy
+  ![image.png](attachment:a093110a-eee3-4c86-8612-c83fb1095062:image.png)
+  ### 위치
+  - **클라이언트 앞단**
+  ### 동작 방식
+  1. 클라이언트 → Forward Proxy
+  2. Forward Proxy → 실제 서버
+  3. 서버 → Forward Proxy → 클라이언트
+  ### 특징
+  - 서버 입장에서 **클라이언트가 보이지 않음**
+  - 서버가 인식하는 IP는 프록시 서버의 IP
+  ### 사용 목적
+  - 클라이언트 IP 은닉
+  - 내부 네트워크 보안
+  - 접근 제어 및 필터링
+  - 캐싱을 통한 응답 속도 개선
+  ### 대표 사용 사례
+  - 회사·학교 내부망 인터넷 접근 제한
+  - 방화벽, 콘텐츠 필터링
+  ***
+  ### Reverse Proxy
+  ![image.png](attachment:1575d326-c97f-4d63-b955-f5e208a5251e:image.png)
+  ### 위치
+  - **서버 앞단**
+  ### 동작 방식
+  1. 클라이언트 → Reverse Proxy
+  2. Reverse Proxy → 내부 서버(Web/WAS)
+  3. 내부 서버 → Reverse Proxy → 클라이언트
+  ### 특징
+  - 클라이언트 입장에서 **실제 서버가 보이지 않음**
+  - 서버의 IP와 구조를 은닉
+  ### 사용 목적
+  - 서버 보안 강화
+  - 트래픽 분산
+  - 무중단 배포
+  - SSL 처리
+  - 캐싱
+  ***
+  ## Reverse Proxy가 필요한 이유
+  ### 보안
+  - 실제 서비스 서버 IP 은닉
+  - DDoS, 직접 공격 방어
+  - 요청 필터링 및 차단 가능
+  ### 서버 구조 분리
+  - Web Server와 WAS 분리
+  - 일반적인 구조:
+    ```
+    Client → Nginx → WAS → DB
+    ```
+  ### 트래픽 분산
+  - Load Balancing과 결합 가능
+  - 여러 서버로 요청 분산 처리
+  ### 확장성
+  - 서버 추가/제거 용이
+  - 무중단 서비스 확장 가능
+  ### 캐싱
+  - 자주 요청되는 리소스 캐싱
+  - 백엔드 서버 부하 감소
+  ### SSL 처리
+  - Reverse Proxy에서 SSL 종료
+  - 내부 서버의 SSL 부담 감소
+  ***
+  ## Reverse Proxy 활용 예
+  ### 점검 페이지 분기
+  - 외부 IP → 점검 페이지
+  - 내부 IP → 정상 서비스
+  ### 무중단 배포
+  - 신규 서버 기동
+  - 트래픽 전환
+  - 기존 서버 종료
+  ### Web / API 분리
+  - 정적 리소스와 API 서버 분리 처리
+  ***
+- HTTPS
+  https://yoon4360.tistory.com/50
+  ***
+  # HTTPS (Feat. Nginx)
+  ***
+  ## HTTPS란?
+  **HTTPS (Hypertext Transfer Protocol Secure)**
+  → HTTP에 **SSL/TLS 암호화가 추가된 통신 프로토콜**
+  → 클라이언트(브라우저)와 서버 간 데이터를 **암호화해서 안전하게 주고받는 구조**
+  HTTPS의 핵심 목적
+  - **데이터 기밀성 보장**
+    → 전송 중 데이터가 노출되거나 도청되는 것 방지
+  - **데이터 무결성 보장**
+    → 중간에서 내용이 변조되는 것을 방지
+  - **서버(사이트) 인증**
+    → 브라우저가 신뢰할 수 있는 CA(Certificate Authority)가 발급한 인증서를 이용해 서버가 진짜임을 검증 ([위키백과](https://en.wikipedia.org/wiki/HTTPS?utm_source=chatgpt.com))
+    HTTPS는 TCP 상에서 **기본 포트 443번**을 사용하며,
+    HTTP처럼 텍스트 자체를 전송하는 것이 아니라
+    **TLS/SSL 계층 위에 HTTP를 얹어 암호화 통신을 함**
+    SSL/TLS의 기본 과정:
+  1. 클라이언트가 HTTPS 접속 시도
+  2. 서버가 **인증서(Cert)** 전송
+  3. 클라이언트가 인증서를 검증
+  4. 클라이언트 ↔ 서버 간 **세션 키 교환**
+  5. 이후의 통신은 모두 **암호화된 채널로 교환됨**
+     이 구조 덕분에 비밀번호나 민감정보 같은 데이터가 네트워크 상에서 쉽게 노출되지 않게 된다.
+  ***
+  ## SSL 인증서의 구조와 역할
+  SSL/TLS 인증서는 다음 두 구성 요소로 이루어진다
+  - **Private Key (비밀키)**
+    → 서버만 알고 있는 키
+    → 암호화된 데이터의 복호화에 사용됨
+  - **Certificate (공개키 + 서명)**
+    → 클라이언트에게 전달되는 공개정보
+    → 도메인과 CA 서명이 포함됨
+    클라이언트는 이 공개키를 기반으로 암호화된 세션 연결을 수립하게 된다.
+    인증서를 발급받기 위해서는
+  - 공인 인증기관(CA)이 발급하는 SSL 인증서
+  - 무료 인증서 예: Let’s Encrypt 사용 가능
+  ***
+  ## Nginx란?
+  **Nginx**는 고성능 웹 서버 + 리버스 프록시 서버이다.
+  핵심 기능
+  - 정적 파일 제공 (HTML/CSS/JS)
+  - 리버스 프록시(백엔드 서버 대리 중계)
+  - 로드 밸런싱
+  - 캐시 제공
+  - HTTPS/TLS 처리
+    즉 Nginx는 단순히 정적 웹을 서비스하는 서버 이상의 역할을 한다.
+    특히 **Reverse Proxy + SSL 처리**는 Nginx를 많이 쓰는 주요 이유다.
+  ***
+  ## Nginx에서 HTTPS가 필요한 이유
+  ### SSL 처리(HTTPS Offloading)
+  HTTPS가 필요한 이유는 **보안 통신 보장**이지만,
+  실제 애플리케이션 서버가 직접 처리하면 부담이 커질 수 있다.
+  Nginx는 앞단에서 SSL/TLS 처리를 대신 수행함으로써
+  - 애플리케이션 서버는 **암호화 처리 로직에서 해방**
+  - 내부 서버는 HTTP 통신으로만 처리 가능
+  - 공인 인증서 갱신/관리도 중앙화 가능
+    즉 Nginx가 SSL 종료점(TLS termination point)가 된다.
+  ***
+  ## HTTPS + Reverse Proxy의 주요 역할
+  ### 클라이언트와 Nginx 간 암호화
+  - 브라우저 ↔ Nginx 사이가 HTTPS로 암호화
+  - Nginx가 인증서로 복호화 이후 내부 서버로 전달
+    → 내부 서버에는 꼭 HTTPS가 아니어도 허용 가능하지만
+    필요하면 프록시→백엔드 간에도 HTTPS 연결 구성 가능
+  ***
+  ## HTTPS + Reverse Proxy의 장점 요약
+  1. **보안 강화**
+     - 암호화된 통신으로 민감 정보 보호
+  2. **SSL 처리 분리**
+     - 애플리케이션 서버는 암호화 로직에서 분리
+  3. **단일 진입점**
+     - 하나의 도메인에서 모든 서비스 통합 처리
+  4. **보안 정책 중앙화**
+     - 인증/접근 제어/HTTPS 설정을 일관되게 적용
+  ***
+  **HTTPS는 HTTP에 TLS/SSL 암호화를 더한 안전한 통신 프로토콜이며, Nginx는 HTTPS를 처리하면서 Reverse Proxy 역할로 클라이언트 요청을 내부 서버로 중계하는 구조**다.
diff --git a/mission/chapter09/README.md b/mission/chapter09/README.md
new file mode 100644
index 0000000..402ae69
--- /dev/null
+++ b/mission/chapter09/README.md
@@ -0,0 +1,56 @@
+미션 실습 레포
+
+https://github.com/Jinacker/UMC_9th_Node_Practice/tree/feature/chapter09
+
+---
+
+- 미션 과정
+
+  1. 기존 req.body.userId에서 떼어오던 userId
+
+     ⇒ JWT 토큰에서 추천하는 [req.user.id](http://req.user.id) 사용으로 리팩토링 (passport - jwt)
+     ![스크린샷 2025-11-27 오후 12.28.50.png](attachment:9354e77e-1af0-4266-880e-4aa19e6678cc:스크린샷_2025-11-27_오후_12.28.50.png)
+     ![스크린샷 2025-11-27 오후 12.33.14.png](attachment:70f7901b-9354-47fb-a5f8-4854d07cd5af:스크린샷_2025-11-27_오후_12.33.14.png)
+
+  ***
+
+  1. 회원 정보 수정 API를 새로 만들었다
+     `http://localhost:3000/oauth2/login/google`
+     ![스크린샷 2025-11-27 오후 1.43.02.png](attachment:ca95e7a4-72fe-47dc-ab77-7007c63304de:스크린샷_2025-11-27_오후_1.43.02.png)
+     잘 작동한다~ 근데 응답이 왜 빈걸로 뜨지
+     ![스크린샷 2025-11-27 오후 1.52.09.png](attachment:6cf56245-0fbd-4425-89da-adca2ffb0b3c:스크린샷_2025-11-27_오후_1.52.09.png)
+     고침 ⇒ Service에서 DTO로 전달할때 객체로 감싸서 전달하는게 문제였음 ⇒ 다 undefined처리 ⇒ 그냥 직접 바로 전달하는걸로 고침
+
+  ***
+
+  1. 이 마지막 2개는 관리자만 접근하는게 맞는거같음(미션목록 조회 X 가게 추가 API ㅇ // 잘못 침 )
+
+     ![스크린샷 2025-11-27 오후 2.02.10.png](attachment:8fdaf368-7527-45ca-b22d-631a25f82df1:스크린샷_2025-11-27_오후_2.02.10.png)
+
+     유저 테이블에 ⇒ ROLE 컬럼 추가 ⇒ 데이터 정합성을 위해 DEFAULT == USER로 해둠.
+
+     ![스크린샷 2025-11-27 오후 2.03.18.png](attachment:5558f822-b111-4ff2-846f-a54c8cc7cbd9:스크린샷_2025-11-27_오후_2.03.18.png)
+
+     마이그레이션 완료!
+
+     ![스크린샷 2025-11-27 오후 2.05.41.png](attachment:4437b9d6-eba5-49b6-a66d-bc8b85041acf:스크린샷_2025-11-27_오후_2.05.41.png)
+
+     일단 임의 테스트를 위해 기무진진 계정에 ADMIN을 줬다.
+
+     어드민 체크용 미들웨어를 따로 만들어줬다.
+
+     어드민 권한 검증은 비즈니스 로직이 아니라 공통 보안 규칙이기 때문에 코드 중복과 보안 누락을 막기 위해 컨트롤러가 아닌 미들웨어로 분리한다. (지피티가 추천해줌)
+
+     ![스크린샷 2025-11-27 오후 2.18.38.png](attachment:1ad99f0d-5216-4cc0-8800-732c194dba15:스크린샷_2025-11-27_오후_2.18.38.png)
+
+     [설정 완료]
+
+     ![스크린샷 2025-11-27 오후 2.16.58.png](attachment:7e3923bb-d4ae-4a6c-b0d2-643d44c34015:스크린샷_2025-11-27_오후_2.16.58.png)
+
+     [ 어드민은 식당 등록 잘된다 ]
+
+     ![스크린샷 2025-11-27 오후 2.32.02.png](attachment:45c01d2d-651a-4b86-8bff-c453598cc02b:스크린샷_2025-11-27_오후_2.32.02.png)
+
+     [ 어드민 외 유저 접근시 403 Forbidden 에러 출력 ]
+
+     ![스크린샷 2025-11-27 오후 2.33.11.png](attachment:83448d4d-d615-4e5c-9258-fcf5675b4032:스크린샷_2025-11-27_오후_2.33.11.png)