From f546551381e6e9ea2f177af35e7ca933392bf71a Mon Sep 17 00:00:00 2001 From: chadchan <112686545+coconutcococode@users.noreply.github.com> Date: Wed, 17 Jun 2026 15:16:34 +0900 Subject: [PATCH] =?UTF-8?q?docs:=20=ED=95=B5=EC=8B=AC=20=ED=82=A4=EC=9B=8C?= =?UTF-8?q?=EB=93=9C=20=EC=9E=91=EC=84=B1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Chanyeol/keyword-summary/ch09.md | 142 ------------------------------- Chanyeol/keyword-summary/ch10.md | 87 +++++++++++++++++++ 2 files changed, 87 insertions(+), 142 deletions(-) delete mode 100644 Chanyeol/keyword-summary/ch09.md create mode 100644 Chanyeol/keyword-summary/ch10.md diff --git a/Chanyeol/keyword-summary/ch09.md b/Chanyeol/keyword-summary/ch09.md deleted file mode 100644 index d3e2078..0000000 --- a/Chanyeol/keyword-summary/ch09.md +++ /dev/null @@ -1,142 +0,0 @@ -- 세션과 토큰의 차이는? - - ## **Session (세션)** - - 세션은 클라이언트의 인증 정보를 **서버 측에 저장하고 관리**하는 방식입니다. - - 사용자가 로그인할 때, 서버는 사용자의 아이디, 권한, 만료 시간 등의 정보를 서버의 메모리, 데이터베이스, 또는 Redis 같은 캐시 저장소에 보관합니다. 그리고 이 정보를 식별할 수 있는 **고유한 Session ID**만 클라이언트(브라우저)에게 쿠키 형태로 전달합니다. - - 클라이언트는 이후 요청마다 이 Session ID를 자동으로 서버에 보내고, 서버는 해당 ID를 통해 저장된 사용자 정보를 찾아 인증을 처리합니다. 즉, **서버가 클라이언트의 상태를 직접 관리**하기 때문에 **Stateful(상태 유지)** 방식이라고 합니다. - - ### 장점 - - - 민감한 정보(사용자 권한, 개인정보 등)를 클라이언트가 아닌 서버에 보관하여 비교적 안전하다. - - 세션을 서버에서 직접 삭제하면 **즉시 로그아웃** 처리(강제 로그아웃)가 가능하다. - - 토큰에 비해 데이터 크기가 작아 네트워크 부하가 적다. - - ### 단점 - - - 사용자가 증가하면 서버가 관리해야 할 세션 데이터가 많아져 **메모리 및 DB 부하**가 커진다. - - 서버를 여러 대로 확장(Scale-out)할 때, 세션 공유 문제가 발생한다. (세션 클러스터링, Sticky Session, Redis 등의 중앙 저장소 필요) - - 서버가 다운되면 모든 세션이 사라질 위험이 있다. - - --- - - ## **Token (토큰)** - - 토큰은 인증에 성공한 클라이언트에게 서버가 발급해주는 **디지털 서명된 문자열**입니다. - - 대표적으로 **JWT(JSON Web Token)**가 많이 사용되며, 이 토큰 안에 사용자 ID, 권한, 만료시간 등의 정보를 직접 포함하고 있습니다. 클라이언트는 이 토큰을 안전한 곳(보통 localStorage 또는 HttpOnly 쿠키)에 저장했다가, 이후 API 요청 시 Authorization: Bearer 헤더에 담아 서버로 보냅니다. - - 서버는 토큰의 **서명을 검증**하기만 하면 되며, 별도로 사용자 정보를 DB에서 조회할 필요가 없습니다. 즉, **서버가 클라이언트의 상태를 유지하지 않는 Stateless(무상태)** 방식입니다. - - ### 장점 - - - 서버가 세션 정보를 저장하지 않아 **서버 부하가 적고**, 확장성(Scale-out)이 뛰어나다. - - 마이크로 서비스, 모바일 앱, 외부 API 연동에 매우 적합하다. - - 토큰 자체에 필요한 정보를 모두 담고 있어 DB 조회 횟수가 줄어든다. - - ### 단점 - - - 토큰의 크기가 세션 ID보다 훨씬 커서, 요청이 많아질수록 **네트워크 트래픽이 증가**할 수 있다. - - 토큰이 탈취당하면 만료시간까지 유효하기 때문에 대처가 어렵다. (Refresh Token을 함께 사용하는 이유) - - 토큰을 무효화(강제 로그아웃)하기가 세션에 비해 복잡하다. (블랙리스트, 짧은 만료시간 + Refresh Token 조합 등으로 보완) -- 엑세스 토큰과 리프레시 토큰이란? - - ## **Access Token (엑세스 토큰)** - - Access Token은 클라이언트가 실제로 서버의 보호된 리소스(예: 사용자 정보 조회, 글 작성 등)에 접근할 때 사용하는 **짧은 수명의 토큰**입니다. - - 주로 JWT 형식으로 발급되며, 사용자 ID, 권한(Role), 만료시간(expiration) 등의 정보를 포함하고 있습니다. 클라이언트는 이 토큰을 Authorization: Bearer 헤더에 담아 API 요청을 보냅니다. 서버는 토큰의 서명만 검증하면 인증이 완료됩니다. - - 일반적으로 **15분 ~ 1시간** 정도의 매우 짧은 유효 기간을 가집니다. - - ### 장점 - - - 유효 기간이 짧아 토큰이 탈취당하더라도 피해를 최소화할 수 있다. - - 서버가 별도의 세션 저장소를 필요로 하지 않아 **확장성**이 뛰어나다. - - 요청마다 빠르게 인증 처리 가능 (Stateless) - - ### 단점 - - - 자주 만료되므로, 만료될 때마다 다시 로그인해야 하는 문제가 발생할 수 있다. - - 만료 시마다 새로운 Access Token을 발급받아야 하므로, Refresh Token과 함께 사용해야 한다. - - 토큰 크기가 커서 네트워크 트래픽에 약간의 영향을 줄 수 있다. - - --- - - ## **Refresh Token (리프레시 토큰)** - - Refresh Token은 **Access Token이 만료되었을 때**, 새로운 Access Token을 발급받기 위해 사용하는 **긴 수명의 토큰**입니다. - - Access Token과 달리 사용자 정보를 많이 포함하지 않고, 주로 토큰 식별자나 사용자 ID 정도만 담습니다. 보안을 위해 보통 **HttpOnly 쿠키**에 저장하며, JavaScript에서 접근할 수 없도록 처리합니다. - - 유효 기간은 보통 **7일 ~ 30일** 정도로 Access Token보다 훨씬 길게 설정합니다. Refresh Token을 이용해 Access Token을 갱신하는 과정을 **Token Refresh** 또는 **Silent Refresh**라고 합니다. - - ### 장점 - - - 사용자가 매번 재로그인하지 않고도 오랜 기간 로그인 상태를 유지할 수 있다. - - Access Token의 수명을 짧게 유지하면서도 사용자 편의성을 높일 수 있다. - - Refresh Token을 서버에서 관리(블랙리스트, Rotation)하면 보안성을 크게 강화할 수 있다. - - ### 단점 - - - 유효 기간이 길어 탈취당할 경우 피해가 크다. - - Refresh Token 자체를 안전하게 보관해야 하며, 탈취 방지를 위한 추가적인 보안 조치가 필요하다. - - 서버에서 Refresh Token을 무효화하거나 관리하는 로직이 추가로 필요하다. - - --- - - ### **현대적인 추천 방식 (Access + Refresh Token 조합)** - - 1. 로그인 성공 시 → **Access Token + Refresh Token** 동시 발급 - 2. 클라이언트는 Access Token으로 API 호출 - 3. Access Token 만료 → Refresh Token으로 새로운 Access Token 요청 - 4. Refresh Token도 만료되면 → 다시 로그인 유도 - - 이 방식은 **세션의 편의성**과 **토큰의 확장성**을 동시에 잡을 수 있는 현재 가장 많이 사용되는 아키텍처입니다. - -- OAuth 1.0과 OAuth 2.0의 차이는? - - ## **OAuth 1.0** - - OAuth 1.0은 2007년에 발표된 최초의 OAuth 버전으로, **외부 애플리케이션이 사용자 대신 서버의 리소스에 안전하게 접근**할 수 있도록 설계된 인증 프로토콜입니다. - - 사용자가 로그인하면 **Request Token** → **Access Token**으로 교환하는 복잡한 과정을 거칩니다. 가장 큰 특징은 **디지털 서명(Signature)**을 사용한다는 점입니다. 매 요청마다 HMAC-SHA1 등의 알고리즘으로 서명을 생성하여 전송합니다. - - ### 장점 - - - HTTPS를 필수로 요구하지 않아도 어느 정도 보안이 가능하다 (서명 기반). - - 서명이 포함되어 있어 토큰이 탈취당하더라도 요청 내용을 위변조하기 어렵다. - - 비교적 엄격한 보안 모델을 제공한다. - - ### 단점 - - - 구현이 매우 복잡하고 어렵다 (서명 생성, nonce, timestamp 등). - - 모바일 앱이나 JavaScript 환경에서 사용하기 불편하다. - - 토큰 만료와 갱신이 제대로 지원되지 않아 보안 및 사용자 경험이 떨어진다. - - 현재는 거의 사용되지 않을 정도로 구식이다. - - --- - - ## **OAuth 2.0** - - OAuth 2.0은 2012년에 발표된 OAuth 1.0의 후속 버전으로, **현대 웹과 모바일 환경에 최적화**된 인증 프레임워크입니다. - - OAuth 1.0의 복잡성을 크게 개선하여 **Bearer Token** 방식을 주로 사용합니다. 다양한 인증 방식(Grant Type)을 지원하며, Access Token + Refresh Token 조합을 표준적으로 활용합니다. - - 대표적인 Grant Type으로는 Authorization Code, Implicit, Client Credentials, Password, Refresh Token 등이 있다. - - ### 장점 - - - 구현이 OAuth 1.0에 비해 훨씬 간단하고 직관적이다. - - HTTPS를 기반으로 하여 보안성을 강화하면서도 개발 편의성이 높다. - - 다양한 클라이언트 환경(웹, 모바일, 서버 간 통신)에 적합한 Grant Type을 제공한다. - - Access Token의 짧은 수명 + Refresh Token으로 보안과 편의성을 동시에 달성할 수 있다. - - 현재 대부분의 서비스(Google, Kakao, Naver, GitHub 등)가 OAuth 2.0을 사용한다. - - ### 단점 - - - Bearer Token을 사용하므로 토큰이 탈취당하면 즉시 악용될 위험이 있다 (HTTPS 필수). - - OAuth 1.0보다 서버 측에서 상태 관리를 더 신경 써야 하는 경우가 있다 (Refresh Token 관리). - - 잘못 구현하면 보안 취약점이 발생하기 쉽다 (예: Implicit Grant의 보안 문제). \ No newline at end of file diff --git a/Chanyeol/keyword-summary/ch10.md b/Chanyeol/keyword-summary/ch10.md new file mode 100644 index 0000000..9f49e2a --- /dev/null +++ b/Chanyeol/keyword-summary/ch10.md @@ -0,0 +1,87 @@ +- 클라우드 컴퓨팅이란? + - 서버, 저장소, 데이터베이스, 네트워크 같은 IT 자원을 직접 구매하고 관리하지 않고, 인터넷을 통해 필요할 때 빌려 쓰는 방식 + - 서버를 안쓰는 것이 아닌 서버 운영 책임의 일부를 전문 업체에 맡기는 방식 + - 대표 유형 + - IaaS: 서버, 네트워크, 스토리지 같은 인프라를 빌림. 예: EC2, Compute Engine + - PaaS: 앱 실행 플랫폼까지 제공. 개발자는 코드와 설정에 집중. 예: App Engine, Elastic Beanstalk + - SaaS: 완성된 소프트웨어를 서비스로 사용. 예: Gmail, Slack, Notion + - 장점: 빠른 배포, 탄력적 확장, 초기 비용 절감, 글로벌 배포, 관리 부담 감소 + - 단점: 비용 구조 복잡, 특정 클라우드에 종속, 보안 설정을 잘못하는 경우 위험이 커짐 +- AWS? GCP? + - AWS는 Amazon Web Services의 약자로, Amazon이 제공하는 클라우드 플랫폼. 컴퓨팅, 스토리지, 데이터베이스, 네트워크, AI, 보안 등 폭넓은 서비스 제공 + - GCP: 공식적으로 Google Cloud라고 부름. Google 검색, Gmail, YouTube 등에 쓰이는 인프라 기반 위에서 컴퓨팅, 스토리지, 데이터 분석, 머신러닝 서비스를 제공 + + | 항목 | AWS | GCP | + | --- | --- | --- | + | 강점 | 서비스 종류가 많고 생태계가 큼 | 데이터, AI, Kubernetes, 네트워크 강점 | + | 대표 서비스 | EC2, S3, RDS, Lambda, ECS | Compute Engine, Cloud Storage, BigQuery, Cloud Run, GKE | + | 장점 | 자료 많음, 기업 도입 많음, 선택지 넓음 | BigQuery, GKE, Cloud Run 같은 관리형 서비스가 강력함 | + | 단점 | 서비스와 요금 체계가 복잡함 | AWS보다 국내 자료/레퍼런스가 적게 느껴질 수 있음 | +- 환경변수 처리 방법과 왜 환경변수로 민감 정보를 가려야 하는가? + - 환경변수는 실행 환경마다 달라지는 설정값을 코드 밖에서 주입하는 방법 + - 예를 들어 DB 주소, DB 계정, API Key, JWT Secret 같은 값이 여기에 해당 + - Spring Boot도 `application.properties`, `application.yml`, 환경변수, 커맨드라인 인자 등 외부 설정을 지원. 특히 OS 환경변수는 Spring 설정으로 바인딩 될 수 있음 + - 민감 정보를 환경변수로 분리해야 하는 이유 + - GitHub에 비밀번호, API Key가 올라가는 사고를 막기 위해 + - 개발, 테스트, 운영 환경마다 값을 다르게 주입하기 위해 + - 같은 코드로 여러 환경에 배포하기 위해 + - 비밀번호 교체 시 코드를 수정하지 않기 위해 +- yml 환경 분리 방법 + + Spring Boot에서는 보통 `application.yml`에 공통 설정을 두고, 환경별로 `application-dev.yml`, `application-prod.yml`을 나눌 수 있음 + + ``` + application.yml + application-dev.yml + application-prod.yml + ``` + + 실행 시 활성 프로필을 지정 + + ``` + SPRING_PROFILES_ACTIVE=dev java -jar app.jar + ``` + + 또는 + + ``` + java -jar app.jar --spring.profiles.active=prod + ``` + + Spring Boot 공식 문서에 따르면 `spring.profiles.active`로 활성 프로필을 지정할 수 있고, 프로필별 설정 파일도 로드됨 + + 다른 방법으로 하나의 `application.yml` 안에서 `---`로 문서를 나누는 방법 + + ``` + spring: + application: + name: my-app + + --- + spring: + config: + activate: + on-profile: dev + + server: + port: 8080 + + --- + spring: + config: + activate: + on-profile: prod + + server: + port: 80 + ``` + + Spring Boot는 YAML의 multi-document 문법을 지원하고, `spring.config.activate.on-profile`로 특정 프로필에서만 설정을 활성화 가능 + +- Docker와 .jar vs Docker 이미지 + + `Docker`는 애플리케이션을 컨테이너로 패키징하고 실행하게 해주는 플랫폼입니다. Docker 공식 문서에 따르면 컨테이너는 애플리케이션 컴포넌트를 격리된 환경에서 실행하는 프로세스이며, 독립적이고 이식성이 좋습니다. + + `.jar`는 Java Archive입니다. Oracle 공식 JAR 명세에 따르면 JAR 파일은 ZIP 기반 파일 형식이며 여러 파일을 하나로 묶는 데 사용됩니다. 실행 가능한 JAR은 `Main-Class`를 통해 `java -jar app.jar` 형태로 실행됩니다. + + `Docker image`는 컨테이너 실행에 필요한 파일, 바이너리, 라이브러리, 설정을 담은 표준 패키지입니다. Docker 이미지는 불변이며 여러 레이어로 구성됩니다. \ No newline at end of file