carsumin devlog 🍀

로깅 레벨 종류 (낮음 -> 높음)레벨의미사용 목적TRACE가장 상세내부 흐름, 변수 값 추적DEBUG디버깅용개발 중 문제 분석INFO일반 정보 정상 흐름 기록WARN경고비정상 상황이지만 동작은 가능ERROR오류예외 발생, 기능 실패 레벨별 정확한 사용 기준 TRACE메서드 진입 / 종료파라미터 값반복문 내부 상태운영에서는 거의 사용 안 함, 성능 저하 위험 있음log.trace("회원 조회 시작 - memberId={}", memberId); DEBUG쿼리 실행 전 / 후조건 분기 결과내부 계산 결과개발 서버까지만 활성화하는 게 일반적log.debug("토큰 생성 완료 - userId={}", userId); INFO중요한 비즈니스 이벤트로그인 성공결제 완료운영 환경 기본 레벨log.info("회원 ..

문제 상황 Spring Boot 애플리케이션에서 로그를 남기다 보면 이런 문제가 발생한다.동시에 여러 요청이 들어옴Controller, Service, Repository, Filter, ExceptionHandler에서 로그가 찍힘로그가 서로 섞임로그인 성공 - memberId=1회원가입 성공 - memberId=3닉네임 중복JWT 인증 성공 -> 어떤 요청에서 발생한 로그인지 구분할 수 없음 해결 전략 - 요청 단위 Trace ID요청마다 고유한 ID를 생성하고 해당 요청에서 발생하는 모든 로그에 동일한 ID를 포함시켜서 해결이를 Correlation ID, TraceId 라고 함스프링에서는 이를 구현하기 위해 MDC를 사용 MDC란 무엇인가?MDC (Mapped Diagnostic Context)..

BearerHTTP 인증 방식 중 하나HTTP 요청 헤더Authorization: Bearer {accessToken}Authorization : 인증 정보를 담는 헤더Bearer : 인증 방식 (Type){accessToken} : 실제 인증 토큰 왜 Bearer 라고 부르는가Bearer은 직역하면 '소지자' 라는 뜻이 토큰을 소지하고 있는 사람은 인증된 사용자로 간주서버는 토큰을 누가 들고 왔는지 확인하지 않음토큰 서명이 유효한지토큰이 만료되지 않았는지필요한 클레임이 포함되어 있는지 Bearer 인증 방식 특징Stateless서버는 세션을 저장하지 않음토큰 자체에 사용자 정보가 포함되어 있음단순 구조서버는 매 요청마다 다음과 같은 흐름으로 동작Authorization 헤더 추출Bearer 제거토큰 검..

인증 (Authentication) 정의"이 요청을 보낸 사용자가 누구인지 확인하는 과정"로그인JWT 토큰 검증세션 쿠키 검증API Key 검증인증의 결과사용자가 확인되면 SecurityContext에 사용자 정보(Authentication) 저장됨사용자가 확인되지 않으면 요청은 종료됨인증 실패 시HTTP Status : 401 Unauthorized-> 인증 = 신원 확인 인가 (Authorization) 정의"인증된 사용자가 이 행동을 할 권한이 있는지 판단하는 과정"Role (USER, ADMIN, CREATOR)Authority (WRITE_POST, DELETE_POST)리소스 소유자 여부 (내 글인지?)상태 (구독 여부, 결제 여부, 정지 여부)인가의 결과권한이 있으면 -> 요청 계속 진행권..

@RequiredArgsConstructor@RequiredArgsConstructorfinal 필드 또는 @NonNull 필드만을 파라미터로 받는 생성자를 자동 생성해주는 Lombok 어노테이션주로 의존성 주입 용도로 사용 @RequiredArgsConstructor + final 필드 (권장 패턴) @RestController@RequiredArgsConstructorpublic class MemberController { private final MemberService memberService;} 실제로 생성되는 코드public MemberController(MemberService memberService) { this.memberService = memberService;}생성자 ..

API Gateway란?MSA 에서 모든 클라이언트 요청의 단일 진입점 역할을 하는 서버Spring에서는 보통 Spring Cloud Gateway를 사용클라이언트 -> Gateway -> 내부 서비스들서비스들은 외부에 직접 노출되지 않음 API Gateway의 필요성서비스 직접 노출의 문제서비스가 많아질수록 엔드포인트 관리 어려움인증/인가 로직이 각 서비스에 중복CORS, 로깅, 모니터링 분산Gateway가 해결하는 것 공통 관심사 중앙화보안/인증 일관성 확보클라이언트는 Gateway만 알면 됨 Spring Cloud Gateway 핵심 역할요청 라우팅 (Routing)URL, Header, Method 기준으로 서비스 분기/members/** -> member-service인증/인가JWT 검증토큰 ..

Spring WebFlux 란?Spring 5 부터 도입된 비동기/논블로킹 웹 프레임워크Reactive Streams 기반, 적은 스레드로 많은 요청 처리-> 기존 Spring MVC = Blocking I/O-> WebFlux = Non-Blocking I/O + 이벤트 루프 WebFlux 의 등장 배경Spring MVC의 구조적 한계요청 1건 = 스레드 1개I/O 대기동안 스레드 점유트래픽 증가 -> 스레드 고갈 -> 응답 지연WebFlux의 해결 방식I/O 대기 중 스레드 반환이벤트가 오면 다시 이어서 처리적은 스레드로 동시성 처리WebFlux = CPU가 아니라 I/O 대기 시간이 병목인 서비스를 위한 모델 WebFlux 핵심 개념Reactive StreamsPublisher : 데이터 발행S..

JWT 란?JSON Web Token, JSON 객체를 안전하게 전송하기 위한 토큰 기반 인증 방식자기 포함 (Self-contained) : 토큰안에 유저 정보나 권한 같은 필요한 정보를 직접 담고 있어서 별도의 세션 저장소가 필요없음서명 (Signature) : 토큰은 서명되어 있어서 내용이 위조되지 않았는지 검증이 가능함Stateless : 서버는 클라이언트의 상태를 유지할 필요없이 토큰만 확인하면 됨 JWT 구조Header : 토큰의 타입과 해싱 알고리즘 (ex : HS256)Payload : 유저 정보 및 클레임(claims)이 포함되는 데이터 (ex : sub, name, exp 등)Signature : 헤더와 페이로드를 비밀키로 해싱한 서명 JWT util class 예제import io.j..

IAM(Identity and Access Management) 인증 서버사용자 또는 시스템의 인증과 권한 부여를 관리하는 컴포넌트사용자가 시스템 리소스에 접근하려고 할 때 사용자의 신원을 확인하고, 접근할 수 있는 권한을 평가하는 역할 IAM 인증 서버의 주요 기능인증 (Authentication)사용자가 시스템에 접근할 때 본인이 누구인지 증명하도록 함일반적으로 ID/비밀번호, 생체 인증, 인증 토큰 등을 통해 이루어짐권한 부여 (Authorization)인증된 사용자가 특정 리소스에 접근할 수 있는 권한이 있는지 확인역할(Role) 기반, 정책(Policy) 기반, 속성(Attribute) 기반의 접근 제어 모델을 활용세션 및 토큰 관리세션 관리 : 사용자 인증 후 세션을 생성하여 사용자의 로그인 ..

환경IDE : VScodeJava : 17SpringBoot : v3.4.0Gradle : v8.11.1DB : H2  1.Spring Initializr 이용해서 프로젝트 생성 Packaging : JarJava version : 17 (자신이 사용하고 있는 버전. 터미널에서 java -version 명령어로 확인)Dependencies : Spring Web, Spring Data JPA, H2 Database, LombokVScode Extensions : Spring Boot Extensions Pack, Java Extension Pack  2. application.properties (application.yml) 설정 나는 yml을 사용했다.application.properties : ke..