[10주차/유리] 워크북 제출합니다

keyword/chapter10/keyword.md

@@ -0,0 +1,211 @@
+- 클라우드 컴퓨팅이란?
+
+  ### 클라우드 컴퓨팅
+
+    - 인터넷을 통해 온디맨드로 IT 리소스를 제공하고 종량제 요금을 지불하는것. 물리 서버를 직접 사고 관리하는 대신, AWS 같은 공급자한테서 필요에 따라 컴퓨팅 파워, 스토리지, 데이터베이스 같은 기술 서비스에 액세스 하는 방식.
+    - ⇒ 남의 서버를 인터넷으로 빌려 쓰고, 쓴 만큼만 냄.
+
+  ### 이점 4가지
+
+    1. **민첩성:**  컴퓨팅, 스토리지, DB로부터 ML분석까지 단 몇 분 만에 기술 서비스를 배포가능
+    2. **탄력성:**  미리 오버 프로비저닝할 필요 없이, 수요에 따라 즉시 확장/축소
+        - ⇒ **오버 프로비저닝(over-provisioning)** = 필요한 것보다 자원을 미리 너무 많이 마련해두는 것.
+    3. **비용 절감:** 고정 비용을 가변 비용으로 전환하고 사용량만큼만 지불
+    4. **글로벌 배포:** 클릭 몇 번으로 여러 물리적 위치에 애플리케이션을 배포, 사용자와 가까워 지연 시간 단축
+
+  ### 서비스 유형 (IaaS / PaaS / SaaS)
+
+    - 클라우드는 제어 범위에 따라 세 유형으로 나뉨. 위로 갈수록 직접 관리할 게 많고, 아래로 갈수록 다 맡김.
+
+  | 유형 | 제공 범위 | 신경 써야되는 부분 | 비유 |
+      | --- | --- | --- | --- |
+  | IaaS | 네트워킹, 컴퓨터(가상/전용 하드웨어), 데이터 스토리지 | OS, 런타임, 앱 전부 | 빈 땅 빌리기 |
+  | PaaS | 인프라+하드웨어와 운영체제까지 관리해줌 | 앱 배포, 관리에만 집중 | 골조 올린 집 |
+  | SaaS | 서비스 공급자가 실행, 관리하는 완전한 제품 | 사용법만 | 입주만하면 됨 |
+    - **IaaS**는 IT 리소스에 대한 최고 수준의 유연성과 관리 제어 기능을 줘서, 기존 IT 환경과 가장 비슷
+    - **PaaS**는 리소스 구매, 용량 계획, 소프트웨어 유지 관리, 패치 작업 같은 잡일에서 해방
+    - **SaaS**는 기본 인프라를 관리하는 방법에 대해 생각할 필요 없이 그냥 쓰면 되고, 웹 이메일이 대표 예시
+- AWS? GCP?
+
+  ### AWS
+
+    - 아마존이 만든 클라우드 서비스. 2006년에 시작한 가장 오래된 퍼블릭 클라우드로, 서버·저장소·DB 등을 빌려주는 종합 플랫폼
+    - **장점**
+        - 서비스가 제일 많음 (200개 이상)
+        - 가장 오래되고 커뮤니티가 가장 큼 - 자료, 강의가 압도적으로 많음
+        - 파트너 생태계가 넓고 안정적
+    - **단점**
+        - 과금 구조가 복잡 - 특히 데이터 전송 비용이 헷갈림
+        - 콘솔(화면) UX가 GCP보다 복잡 - 처음엔 어려움
+
+  ### GCP
+
+    - 구글이 만든 클라우드 서비스. 후발주자지만 빅쿼리 등 빅데이터, ML 영역에 특화
+    - **장점**
+        - 데이터 분석·AI/ML에 특 (BigQuery, Vertex AI)
+        - 쿠버네티스(GKE)가 가장 성숙
+        - 콘솔이 깔끔하고 문서가 좋음
+    - **단점**
+        - 서비스 범위가 AWS보다 좁음
+        - 서비스 폐기(없애는) 이력이 많아 신뢰도 우려
+
+  ### 언제 어떤 걸 사용?
+
+    - **데이터 분석·AI가 핵심** → GCP (BigQuery + Vertex AI 조합이 압도적)
+    - **쿠버네티스 중심** → GCP (GKE Autopilot이 최고의 K8s 경험 제공)
+    - **서비스 다양성·안정성·생태계 중요** → AWS
+    - **비용 최우선** → GCP(지속 사용 할인) 또는 AWS(Graviton + Spot)
+- 환경변수 처리 방법과 왜 환경변수로 민감 정보를 가려야 하는가?
+
+  ### 왜 민감 정보를 환경 변수로 가려야 하는가?
+
+    1. **깃허브 유출 위험 (제일 중요)**
+        - 코드에 DB 비밀번호나 JWT 시크릿을 직접 적어두면, 그 코드를 GitHub에 올리는 순간 **전 세계에 공개**
+    2. **환경마다 값이 다름**
+        - 개발할 때 쓰는 DB와 실제 서비스 DB는 주소·비밀번호가 다름
+        - 드에 박아두면 환경이 바뀔 때마다 코드를 고쳐야 하는데, 환경 변수로 빼두면 코드는 그대로 두고 값만 바꾸면 됨
+    3. **협업 시 안전**
+        - 팀원끼리 코드는 공유하되, 민감한 값은 각자 따로 관리
+
+  ### 환경 변수 처리 방법 (Spring Boot)
+
+    1. 1단계: application.yml에서 `${}`로 참조
+        - `${환경변수이름}`을 적어주면, 그 application 파일로 기동되는 Spring Boot 앱이 속한 OS의 환경 변수 값을 사용할 수 있음
+
+        ```jsx
+        jwt:
+          secret-key: ${JWT_SECRET_KEY}
+
+        spring:
+          datasource:
+            password: ${DB_PASSWORD}
+        ```
+
+    2. 2단계: 실제 값은 환경 변수로 설정
+        - `.env`파일: 파일을 별도로 정의해서 사용하는 흔한 방법
+        - `export` 명령: 리눅스 계열이면 매번 export로 설정하거나 쉘 설정 파일에 추가
+        - 컨테이너 파라미터: 도커 같은 컨테이너에서 파라미터로 넘겨주기
+        - IDE 설정: IntelliJ에서 실행 구성에 환경 변수 직접 입력
+    3. 3단계: `.gitignore`에 `.env` 추가 (필수)
+        - `.env` 파일 자체는 실제 비밀값이 들어있으니 절대 깃허브에 올라가면 안 된다. 그래서 `.gitignore`에 꼭 넣어야 함
+- yml 환경 분리 방법
+
+  ### 환경 분리(Profile)란?
+
+    - 환경 분리란 개발 단계(local/dev/prod)마다 설정을 따로 나눠두고, 실행할 때 골라 쓰는 것
+    - 같은 프로젝트라도 내 컴퓨터(local), 개발 서버(dev), 실제 운영 서버(prod)는 사용하는 DB가 모두 다르고, DB가 다르면 접속 정보(주소·비밀번호)도 전부 다름
+    - 설정을 하나로만 두면 환경이 바뀔 때마다 코드를 고쳐야 하므로, 환경별로 설정을 분리하여 관리
+    - **대표적인 환경 구분**
+        1. local: 내 컴퓨터에서 개발하는 환경
+        2. dev: 팀이 함께 테스트하는 개발 서버 환경
+        3. prod: 실제 사용자가 쓰는 운영 서버 환경
+
+  ### 환경 분리 방법
+
+    1. **파일을 나눠서 관리**
+        - resources 폴더에 환경별 설정 파일을 따로 둠
+            - application.yml은 공통 설정
+            - application-local.yml은 로컬 전용
+            - application-dev.yml은 개발 서버 전용
+            - application-prod.yml은 운영 서버 전용
+        - 환경별로 분리된 파일들은 application.yml을 오버라이딩(덮어쓰기)해서 사용
+        - 따라서 공통 설정은 application.yml에 작성하고, 필요한 부분만 환경별 파일에서 오버라이드
+
+        ```jsx
+        // 공통 파일(application.yml)에서는 어떤 환경을 켤지 지정
+        spring:
+          profiles:
+            active: local   # 기본으로 local 환경 사용
+        ```
+
+        ```jsx
+        // 환경별 파일(application-prod.yml)에서는 그 환경에서만 적용할 설정을 작성
+        spring:
+          config:
+            activate:
+              on-profile: prod
+          datasource:
+            url: jdbc:mysql://운영DB주소:3306/proddb
+            username: ${DB_USERNAME}
+            password: ${DB_PASSWORD}
+        ```
+
+    2. 한 파일 안에서 `---`로 나누기
+        - application.yml 파일 하나로 여러 프로파일을 관리할 수도 있으며, 환경별로 나눌 때는 `---` 구분자를 사용
+
+        ```jsx
+        # 기본(공통) 설정
+        spring:
+          profiles:
+            default: local
+        ---
+        # dev 환경
+        spring:
+          config:
+            activate:
+              on-profile: dev
+          datasource:
+            url: jdbc:mysql://dev주소:3306/devdb
+        ---
+        # prod 환경
+        spring:
+          config:
+            activate:
+              on-profile: prod
+          datasource:
+            url: jdbc:mysql://prod주소:3306/proddb
+        ```
+
+    - **실행할 환경을 정하는 법**
+        - IntelliJ에서는 Edit Configurations로 들어가 Active profiles 부분에 원하는 profile명을 입력하면 그 설정으로 실행
+        - 아무 설정 없이 실행하면 default로 지정해둔 환경으로 실행
+        - 빌드 후 명령줄에서는 실행 시점에 프로파일을 지정할 수 있음
+
+        ```jsx
+        java -jar myapp.jar --spring.profiles.active=prod
+        ```
+
+    - 주의사항
+        1. 민감 정보는 profile로 나눠도 여전히 환경 변수로 처리
+        2. properties와 yml을 동시에 사용하지 않음
+            - application.properties와 application.yml이 같이 있으면 properties가 나중에 로드되어 yml에 정의한 설정을 덮어쓸 수 있기 때문
+- Docker와 .jar vs Docker 이미지
+
+  ### .jar 배포란?
+
+    - .jar는 Spring Boot 프로젝트를 하나로 묶은 실행 파일
+    - Spring Boot에서의 배포는 보통 Maven이나 Gradle로 빌드한 application.jar를 Java 실행 환경(Java Runtime)이 구성된 서버에 복사해서 실행하기만 하면 됨
+    - 즉 `.\gradlew.bat bootJar`로 jar를 만들고, 서버에서 `java -jar app.jar`로 실행하는 방식
+    - **단점**
+        - 서버에 **Java가 미리 깔려 있어야** 함
+        - Java 버전이 다르거나 환경이 다르면 문제가 생길 수 있음
+
+  ### Docker 이미지란?
+
+    - Docker 이미지는 앱 + 실행 환경(Java 등)을 통째로 묶은 "박제된 상자”
+    - 도커 이미지는 읽기 전용 파일이라 처음 빌드한 이후로 상태값이 변하지 않으며, 에러가 발생하지 않을 때의 환경이 그대로 이미지로 박제
+    - **장점**
+        - 서버 환경에 구애받지 않고 실행이 가능함
+        - 즉, jar만 옮기는 게 아니라 Java 환경까지 같이 싸들고 가는 셈이라, 어느 서버에서든 똑같이 돌아감
+
+  ### **이미지 vs 컨테이너**
+
+    - 이미지와 컨테이너는 다른 개념
+    - 도커 컨테이너는 실행 중인 이미지를 의미함
+    - 실행 후 변경 사항(DB 변경, 서비스 추가 등)은 이미지와 별도로 컨테이너 안에 저장되며, 컨테이너를 삭제하면 함께 삭제됨
+    - 비유: 이미지는 붕어빵 틀, 컨테이너는 그 틀로 찍어낸 붕어빵 (틀 하나로 붕어빵 여러 개를 똑같이 찍어낼 수 있음)
+
+  ### **.jar vs Docker 이미지**
+
+  | 구분 | .jar 배포 | Docker 이미지 배포 |
+      | --- | --- | --- |
+  | 묶는 범위 | 앱 코드만 | 앱 + 실행 환경 전부 |
+  | 서버 준비 | Java 미리 설치 필요 | Java 설치 불필요 |
+  | 환경 일관성 | 서버마다 다를 수 있음 | 어디서든 동일하게 작동 |
+  | 실행 방법 | `java -jar app.jar` | `docker run 이미지명` |
+
+  ### **.jar와 Docker 이미지의 관계**
+
+    - 둘은 같은 게 아니라 jar가 Docker 이미지 안에 들어가는 포함 관계
+    - jar = 실행할 내용물, Docker = 그 내용물을 어디서든 똑같이 돌게 포장한 것
+    - 배포 흐름도 보통 jar를 먼저 만들고 → 그걸 Docker 이미지로 감싸는 순서