개요HTTP 상태코드는 클라이언트에게 요청 처리 결과를 명확하게 전달하는 중요한 수단입니다. Spring Boot에서는 ResponseEntity를 통해 개발자가 상황에 맞는 적절한 상태코드를 설정할 수 있습니다.HTTP 상태코드의 기본 분류2xx - 성공200 OK: 요청이 성공적으로 처리됨201 Created: 새로운 리소스가 성공적으로 생성됨204 No Content: 요청은 성공했지만 응답할 내용이 없음4xx - 클라이언트 오류400 Bad Request: 잘못된 요청401 Unauthorized: 인증이 필요함403 Forbidden: 권한이 없음404 Not Found: 요청한 리소스를 찾을 수 없음409 Conflict: 리소스 충돌5xx - 서버 오류500 Internal Server Er..

📋 문제 상황증상커스텀 예외 클래스의 생성자는 정상 실행됨GlobalExceptionHandler의 메서드가 실행되지 않음예외 발생 시 Spring의 기본 에러 응답만 반환됨환경Spring Boot 프로젝트커스텀 예외: DuplicateMemberException전역 예외 처리: @RestControllerAdvice 사용증상 재현 코드// Service에서 예외 발생throw new DuplicateMemberException("이미 존재하는 이메일입니다");// Exception 클래스 (정상 동작)public class DuplicateMemberException extends RuntimeException { public DuplicateMemberException(String messag..

현재 상황: 단일 DB 설정spring.datasource.url=jdbc:sqlite:product.dbspring.datasource.driver-class-name=org.sqlite.JDBC이 설정은 product.db 하나의 SQLite 파일만 사용한다는 뜻.별도 설정 클랜스 불필요! ✅Spring Boot가 자동으로 연결// 이런 코드를 Spring Boot가 자동으로 생성해줌!@Beanpublic DataSource dataSource() { // application.properties 설정을 읽어서 자동 생성}@Bean public EntityManagerFactory entityManagerFactory() { // JPA 설정도 자동으로}현재 방식 vs 다중 DB 방식 비교..

📁 설정 파일application.properties 또는 application.ymlSpring Boot가 자동으로 인식하는 설정 파일애플리케이션 시작 시 자동으로 로드됨🔧 Spring Boot Auto ConfigurationSpring Boot가 이 설정들을 보고 자동으로 Bean을 생성해준다.# 이 설정을 보고...spring.datasource.url=jdbc:sqlite:product.dbspring.datasource.driver-class-name=org.sqlite.JDBCSpring Boot가 자동으로 해주는 일// 이런 코드를 자동으로 생성해줌 (우리가 안 써도!)@Beanpublic DataSource dataSource() { HikariDataSource dataSour..

🎯 백엔드에서는 받을 정보에 대한 '명시'가 반드시 필요하다.핵심 원리Spring은 "있는 것만" 받아준다.// 이것만 받겠다고 명시public class OrderItemRequestDto { private Long productId; // ← 이것만 받음 private int quantity; // ← 이것만 받음}// 클라이언트가 더 많이 보내도...{ "productId": 1, // ✅ 받음 (명시됨) "quantity": 2, // ✅ 받음 (명시됨) "color": "red", // ❌ 무시됨 (명시 안됨) "discount": 1000 // ❌ 무시됨 (명시 안됨)}일종의 허가된 데이터의 형식이라고 볼 수도 있는데 명..

스프링에서 빈의 종류는 스코프(Scope)로 결정된다. 빈의 스코프는 "하나의 빈(객체)이 언제 생성되어 어디까지 공유되고, 언제 사라지는가"를 정의하는 규칙이다. 크게 두 그룹으로 나눌 수 있다.핵심 스코프웹 환경 전용 스코프핵심 스코프 (Core Scopes)웹 환경이 아니어도 스프링을 사용하는 곳이라면 어디서든 사용할 수 있는 기본적인 스코프다.싱글톤 (Singleton)설명: 스프링 컨테이너(IoC Container) 안에서 단 하나의 인스턴스만 생성되어 애플리케이션 전반에 걸쳐 공유된다.특징: 기본값(Default)으로 설정된 스코프다. 별도로 스코프를 지정하지 않으면 모든 빈은 싱글톤으로 만들어진다. 메모리 효율이 좋고 상태를 공유하지 않는(Stateless) 서비스나 DAO(Data Acce..

인스턴스(빈)의 생명 주기에 따라 어떤 애너테이션을 사용하는가?초기화 시점 (객체 생성 및 준비 완료 후): @PostConstruct소멸 시점 (객체 사라지기 직전): @PreDestroy이 두 가지가 인스턴스의 '탄생'과 '죽음' 시점에 직접 관여하는 핵심 애노테이션이다.📜 1단계 : "이 클래스를 스프링이 관리해줘!" - 빈 등록가장 먼저 스프링에게 "이 클래스는 평범한 클래스가 아니야. 네가 직접 관리하고 책임져야 할 소중한 '빈(Bean)'이야!"라고 알려줘야 한다.주요 애너테이션@Component: 가장 기본적인 빈 등록 애노테이션.@Service: 비즈니스 로직을 담당하는 서비스 계층에 사용. (@Component 포함)@Repository: 데이터 접근(DB 등)을 담당하는 영속 계층에 ..

메서드 호출 방식의 차이 (자바 vs 스프링)질문 : 순수 자바의 instance.method()와 스프링의 메서드 호출은 어떻게 다른가?정리 : 메서드를 호출하는 코드(instance.method()) 자체는 동일하다. 근본적인 차이는 인스턴스를 누가 만들고 관리하느냐에 있다. 자바는 개발자가 직접 new로 만들지만, 스프링은 프레임워크가 대신 만들어 주입(Inject)해준다.주입의 본질 (IoC/DI)질문 : new를 안 쓰는 게 핵심 차이인가?정리: 그렇다. 개발자가 객체를 직접 생성하고 제어하는 대신, 그 제어권을 스프링 프레임워크에게 넘기는 것, 이것이 바로 제어의 역전(IoC: Inversion of Control)이다. 그리고 필요한 객체를 외부(스프링 컨테이너)에서 넣어주는 행위가 의존성 ..

의존성 주입 동작 원리 : 스프링은 어떻게 빈(Bean)을 찾는가?객체와 타입 : Java에서는 클래스(Class)가 곧 타입(Type)이다. public class ItemRepository는 ItemRepository라는 새로운 타입을 정의하는 것이다.주입 대상 : DI는 클래스 내부의 특정 요소가 아닌, 클래스 설계도로 만들어진 객체(Object) 전체를 주입한다. 주입된 객체의 public 메서드를 통해 내부 기능에 접근한다.주입 원칙: 스프링은 기본적으로 타입(Type)을 보고 주입할 Bean을 찾는다.만약 해당 타입의 Bean이 여러 개라면(DiscountPolicy 예시), @Primary 어노테이션이 붙은 Bean을 우선적으로 선택하거나, @Qualifier를 통해 특정 이름의 Bean을 ..

의존성 주입의 3가지 방식과 권장 사항그렇다면 실제로 스프링에는 의존성 주입을 어떻게 할까? 크게 3가지 주입 방식이 있다.주입 방식특징권장 여부생성자 주입객체 생성 시점에 모든 의존성을 주입. final 키워드 사용 가능, 불변성 보장.*️⃣ 강력 권장 (표준)수정자(Setter) 주입Setter 메서드를 통해 주입. 선택적인 의존성이나 변경 가능성이 있을 때 사용.△ 제한적 사용필드 주입필드에 @Autowired를 직접 선언. 코드가 간결하지만 테스트가 어렵고 여러 단점이 있음.❌ 비권장의존성 주입을 위한 전제조건 : @Autowired와 스프링 빈위에서 의존성 주입의 3가지 방식을 살펴봤는데, 실제로 이것이 동작하려면 두 가지 핵심 전제조건이 필요하다.스프링 빈(Bean) 등록: "부품 상자에 부품..