diff --git a/keyword/chapter10/keyword.md b/keyword/chapter10/keyword.md
new file mode 100644
index 0000000..09cd7fd
--- /dev/null
+++ b/keyword/chapter10/keyword.md
@@ -0,0 +1,221 @@
+# Q1. 클라우드 컴퓨팅이란?
+
+## 정의
+
+인터넷을 통해 IT 자원(서버, 스토리지, 네트워크, 소프트웨어 등)을 필요한 만큼 빌려 쓰는 컴퓨팅 방식이다.
+
+## 왜 쓰는가
+
+전통적인 온프레미스(On-Premise) 환경에서는 서버를 직접 구매하고, 설치하고, 유지보수해야 한다.
+
+- 초기 인프라 구축 비용이 크다. (서버 구매, 네트워크 장비 등)
+- 트래픽이 급증하면 서버를 추가 구매해야 하고, 줄어들면 자원이 놀게 된다.
+- 물리 서버 관리(장애 대응,하드웨어 교체 등)에 여러 비용이 발생한다.
+- 클라우드를 사용하면 필요한 만큼만 자원을 할당받고, 사용한 만큼만 비용을 지불할 수 있다.
+
+## 온프레미스란?
+
+기업이 자체적으로 서버, 네트워크, 스토리지 같은 IT 인프라를 직접 구매해서 전용 데이터센터에 설치하고 운영하는 방식.
+
+클라우드가 "빌려 쓰는 것"이면, 온프레미스는 "직접 사서 갖고 있는 것"로 생각할 수 있고, 클라우드의 반대 개념으로 이해하고 있다.
+
+## 핵심 개념 (주요 특징)
+
+핵심은 **"소유"에서 "이용"으로의 전환**이다. 직접 인프라를 보유하지 않고, 클라우드 제공자(AWS, Azure, GCP 등)가 운영하는 데이터센터의 자원을 API나 콘솔을 통해 원격으로 사용한다.
+
+1. **On-Demand Self-Service**: 필요할 때 즉시 자원을 생성/삭제할 수 있다.
+2. **탄력성(Elasticity)**: 트래픽에 따라 자원을 자동으로 확장/축소할 수 있다.
+3. **종량제 과금**: 사용한 만큼만 비용을 지불한다.
+4. **고가용성(High Availability)**: 여러 리전/가용 영역에 분산 배치하여 장애에 대비할 수 있다.
+
+## 서비스 모델
+
+1. **IaaS** (Infrastructure as a Service): 서버, 네트워크, 스토리지 등 인프라 자체를 제공한다. 사용자가 OS부터 직접 관리한다.
+    - ex) AWS EC2, GCP Compute Engine
+2. **PaaS** (Platform as a Service): 인프라 + 런타임 환경까지 제공한다. 개발자는 애플리케이션 코드만 신경 쓰면 된다.
+    - ex) AWS Elastic Beanstalk, Google App Engine
+3. **SaaS** (Software as a Service): 완성된 소프트웨어를 서비스 형태로 제공한다. 사용자는 그냥 쓰기만 하면 된다.
+    - ex) Gmail, Notion, Slack
+
+## 배포 모델
+
+- **퍼블릭 클라우드** — AWS, Azure, GCP처럼 누구나 사용할 수 있는 공용 클라우드
+- **프라이빗 클라우드** — 특정 조직 전용으로 구축한 클라우드 (보안이 중요한 금융·공공기관 등)
+- **하이브리드 클라우드** — 퍼블릭 + 프라이빗을 혼합하여 사용하는 방식. 민감한 데이터는 프라이빗에, 일반 서비스는 퍼블릭에 배치하는 식으로 운영한다.
+
+---
+# Q2. AWS? GCP?
+
+## 정의
+
+대표적인 퍼블릭 클라우드 서비스 제공자이다.
+
+- **AWS** (Amazon Web Services): Amazon이 제공하는 클라우드 플랫폼.
+    - 현재 시장 점유율 1위
+- **GCP** (Google Cloud Platform): Google이 제공하는 클라우드 플랫폼.
+    - 데이터 분석·AI/ML 분야에 강점을 가진다.
+
+## 왜 쓰는가
+
+직접 서버를 구축하지 않고도, 이 플랫폼들이 제공하는 서비스로 인프라를 구성할 수 있다.
+
+- 서버, 데이터베이스, 스토리지, 네트워크, 보안 등 거의 모든 IT 인프라를 서비스 형태로 제공
+- 콘솔이나 CLI로 몇 분만에 서버 생성 & 배포 가능
+- 글로벌 리전을 통해 전 세계 사용자에게 낮은 지연 시간으로 서비스를 제공할 수 있다.
+    - 리전: 클라우드 제공자가 전 세계에 분산해서 운영하는 데이터센터의 지리적 단위
+    - ex) 한국 사용자 → 서울 리전, 일본 사용자 → 도쿄 리전 등
+    - 물리적으로 가까워서 응답 속도도 빠름
+
+## AWS 주요 서비스
+
+1. **EC2** (Elastic Compute Cloud): 가상 서버로, 원하는 사양의 인스턴스를 생성하여 사용.
+2. **S3** (Simple Storage Service): 객체 스토리지. 파일, 이미지, 백업 데이터 등을 저장.
+3. **RDS** (Relational Database Service): 관계형 데이터베이스를 제공.
+    - ex) MySQL, PostgreSQL 등
+4. **VPC** (Virtual Private Cloud): 사용자 전용 가상 네트워크를 구성.
+5. **IAM** (Identity and Access Management): 사용자 및 권한을 관리.
+6. **Lambda**: 서버 없이 코드를 실행하는 서버리스 컴퓨팅 서비스.
+
+## GCP 주요 서비스
+
+1. **Compute Engine**: 가상 서버로, ↔ AWS의 EC2 대응
+2. **Cloud Storage**: 객체 스토리지로, ↔ AWS의 S3 대응
+3. **Cloud SQL**: 관리형 관계형 데이터베이스로, ↔ AWS의 RDS 대응
+4. **BigQuery**: 대규모 데이터 분석에 특화된 서버리스 데이터 웨어하우스. GCP의 대표 강점.
+5. **Cloud Run**: 컨테이너 기반 서버리스 컴퓨팅. 도커 이미지만 올리면 자동으로 배포·스케일링된다.
+6. **IAM**: AWS와 마찬가지로 사용자 및 권한을 관리한다.
+
+---
+# Q3. 환경변수 처리 방법과 왜 환경변수로 민감 정보를 가려야 하는가?
+
+## 정의
+
+환경변수란 OS나 애플리케이션이 참조하는 key-value 형태의 변수이다.
+
+주로 DB 접속 정보, API 키, 시크릿 키 등 민감한 설정값을 코드 외부에서 관리할 때 사용한다.
+
+## 왜 환경변수로 민감 정보를 가려야 하는가
+
+소스 코드에 비밀번호나 API 키를 하드 코딩하면 다음과 같은 문제가 발생한다.
+
+- Github에 민감 정보가 그대로 노출된다.
+- 한번 커밋 히스토리에 남으면 삭제해도 기록이 남아 완전한 제거가 어렵다.
+- 개발 환경마다 설정 값이 다른데, 코드에 박아두면 환경 전환이 번거로워진다.
+    - ex) DB 접속 정보: 로컬에서 개발할 때, 운영 배포할 때 서로 다름
+
+핵심은 **코드와 민감 정보를 분리**하는 것이다. 코드에는 `${DB_PASSWORD}` 같은 참조만 남기고, 실제 값은 환경변수로 주입하면 코드가 유출되더라도 민감 정보는 안전하다.
+
+## 처리 방법
+
+1. **`.env` 파일 + `.gitignore`**: 로컬 개발 시 `.env` 파일에 환경변수를 정의하고, `.gitignore`에 등록하여 Git에 올라가지 않게 한다.
+2. **OS 환경변수 직접 설정**: `export DB_PASSWORD=1234` 처럼 서버에서 직접 설정하는 방식이다. 배포 스크립트나 CI/CD 파이프라인에서 주입하는 경우가 많다.
+3. **클라우드 시크릿 관리 서비스**: AWS Secrets Manager, GCP Secret Manager 등을 사용하면 암호화된 상태로 민감 정보를 저장하고, 애플리케이션이 런타임에 가져다 쓸 수 있다. 운영 환경에서 가장 권장되는 방식이다.
+
+## Spring Boot 기준 예시
+
+`application.yml`에서 환경변수를 참조하는 방식:
+
+```yaml
+spring:
+  datasource:
+    url: ${DB_URL}
+    username: ${DB_USER}
+    password: ${DB_PW}
+```
+
+실제 값은 `.env` 파일이나 서버 환경변수로 주입하므로, 코드에는 민감 정보가 남지 않는다.
+
+---
+# Q4. yml 환경 분리 방법
+
+## 정의
+
+Spring Boot에서 `application.yml` 파일을 환경별(로컬, 개발, 운영 등)로 분리하여 관리하는 방법이다.
+
+## 왜 분리하는가
+
+환경마다 DB 주소, 포트 번호, 외부 API 주소 등 설정 값이 다르다. 하나의 yml에 전부 넣으면 배포할 때마다 수정해야 하고, 실수로 로컬 환경에서 운영 DB에 접속하여 데이터를 변경하는 사고가 발생할 수 있다.
+
+ex) 로컬에서 테스트 하다가 실제 운영 DB인줄 모르고 DELETE 쿼리를 날리는 상황…
+
+## 분리 방법
+
+환경별로 yml 파일을 나눈다.
+
+- `application.yml` — 공통 설정
+- `application-local.yml` — 로컬 개발 환경
+- `application-dev.yml` — 개발 서버 환경
+- `application-prod.yml` — 운영 환경
+    - `prod` = production 줄임말
+
+`application.yml`에는 모든 환경에서 공통으로 쓰는 설정을 넣고, 각 환경 파일에는 해당 환경에만 해당하는 설정을 넣는다.
+
+## 프로파일 활성화 방법
+
+프로파일 = '지금 어떤 환경에서 실행 중인지'를 가리키는 것
+
+어떤 환경 파일을 적용할지는 `spring.profiles.active` 값으로 결정한다.
+
+```yaml
+# application.yml
+spring:
+  profiles:
+    active: local
+```
+
+또는 실행 시 옵션으로 지정할 수도 있다.
+
+```bash
+java -jar app.jar --spring.profiles.active=prod
+```
+
+`prod`를 지정하면 `application.yml` + `application-prod.yml`이 합쳐져서 적용되고, 같은 키가 있으면 환경 파일(`prod`)이 공통 설정을 덮어쓴다.
+
+---
+
+# Q5. Docker와 .jar vs Docker 이미지
+
+## 정의
+
+- **`.jar`**: Java 애플리케이션을 하나의 파일로 패키징한 실행 파일이다. `java -jar app.jar`로 실행한다.
+- **Docker 이미지**: 애플리케이션 + 실행에 필요한 모든 환경(OS, JDK, 설정 등)을 하나로 묶은 패키지이다. 이 이미지를 실행하면 **컨테이너**가 된다.
+
+---
+
+## `.jar` 단독 배포의 한계
+
+서버에 `.jar`만 올려서 실행하는 방식은 간단하지만 문제가 있다.
+
+- 서버에 맞는 JDK 버전이 설치되어 있어야 한다.
+- "내 PC에서는 되는데 서버에서는 안됨" 문제가 발생할 수 있다.
+- 서버가 여러 대일 경우, 각 서버마다 동일한 환경을 맞춰줘야 한다.
+
+---
+
+## Docker 이미지 배포의 장점
+
+Docker 이미지에는 JDK, OS, 설정 등이 전부 포함되어 있기 때문에, 어디서 실행하든 동일한 환경이 보장된다.
+
+- 환경 차이로 인한 에러 걱정을 안 해도 된다.
+- `docker run` 한 줄이면 어떤 서버에서든 바로 실행 가능하다.
+- 서버를 여러 대로 확장할 때도 같은 이미지를 통해 일관성이 유지된다.
+
+---
+
+## 비교 정리
+
+| 구분 | .jar 단독 배포 | Docker 이미지 배포 |
+| --- | --- | --- |
+| 실행 조건 | 서버에 JDK 필요 | Docker만 설치되어 있으면 됨 |
+| 환경 일관성 | 서버마다 직접 맞춰야 함 | 이미지에 포함되어 있어 보장됨 |
+| 확장성 | 서버 추가 시 환경 세팅 필요 | 같은 이미지로 바로 배포 가능 |
+
+---
+
+## 직관적 이해!
+
+`.jar` = 애플리케이션 코드만 담은 파일"
+
+Docker 이미지 = "코드 + 실행 환경을 통째로 담은 파일"
+
+---
\ No newline at end of file