@EnableWebSecurity

1. 설명

   1. 스프링 시큐리티에서 웹 보안 설정을 활성화할때 붙이는 어노테이션
   2. 내부적으로 WebSecurityConfigurerAdapter 또는 SecurityFilterChain 기반 설정을 활성화
   3. 즉 Spring Security가 HTTP 요청 필터링 , 인증, 권한 체크 등을 적용하도록 해라는 의니

2. 특징

   1. 스프링 Security 기능 호라성화
      1. CSRF, 세션 관리, 권한 체크 등 필터 체인 구성
      2. HTTP 요청에 대한 보호 시작
   2. 커스터마이징 가능
      1. WebSecurityConfigurerAdapter 상속하거나
      2. Spring boot 2.7 + / 3.x에서는 SecurityFilterChain @Bean으로 대체 가능
      3. 이 어노테이션이 없으면 SecurityFilterChain을 등록해도 웹 보안이 적용되지 않을 수 있음
      4. 즉, 스프링 시큐리티 웹 모듈을 켜는 스위치라고 보면 됨

3. @Getter

   1. 특징
      1. 필드마다 getter 메서드를 자동 생성
   2. 장점
      1. 캡슐화된 데이터 읽기 편리
      2. 보일러 플레이트 코드 줄어듦
         1. 반복적이고 형식적으로 꼭 작성해야 하는 코드
   3. 단점
      1. 클래스 전체에 붙이면 모든 필드가 노출 → 민감 데이터까지 의도치 않게 외부 접근 가능

4. @Setter

   1. 특징
      1. 필드마다 setter 메서드 자동 생성
   2. 장점
      1. 값 변경이 간단해짐
      2. DTo 처럼 단순 데이터 담는 용도엔 편리
   3. 단점
      1. 무분별하게 쓰면 객체 불변성이 깨짐
         1. 객체불변성은 한번 만들어진 객체의 상태가 절대 바뀌지 않는 성질
      2. JPA Entity 같은 곳에서는 예측 불가능한 상태 변화를 일으킬 수 있음

5. @NoArgsConstructor

   1. 특징
      1. 파라미터 없는 기본 생성자 자동 생성
   2. 장점
      1. JPA/Hibernate 같은 프레임워크가 프록시 생성을 위해 필요할 때 유용
      2. DTO 직렬화 / 역직렬화(JSON 변환 등)에도 필수
   3. 단점
      1. 아무 제약 없는 빈 객체가 생길 수 있어, “불완전한 상태”의 객체 생성 위험

6. @AllArgsConstructor

   1. 특징
      1. 모든 필드를 파라미터로 받는 생성자 자동 생성
   2. 장점
      1. 빠르게 객체 초기화 가능
      2. 테스트 코드 작성 시 편리
   3. 단점
      1. 필드가 많아지면 생성자 파라미터 가독성 (생성자에 파라미터가 많아지면 각 값이 무슨 의미인지 직관적으로 알기 어렵다는 것)
      2. 의미 없는 조합으로 객체 생성될 수 있음(생성자 파라피터는 타입만 맞으면 순서를 틀려도 컴파일 에러가 안난다 즉 값이 이상한 곳에 들어갈 수 있다.)

7. @Builder

   1. 특징

      1. 빌더 패텅을 자동으로 구현해 줍니다.
      2. 객체를 생성할 때 필드명을 직접 지정하면서 값을 넣을 수 있어서, 생성자 파라미터 순서를 외우거나 헷깔릴 일이 없어진다.

   2. 비교

      1. 원래 생성자 방식

      @AllArgsContructor
      public class User{
      	private String username;
      	private String password;
      	private String email;
      	private int age;
      	private String address;
      }
      
      User u = new User("minsang", "1234", "[email protected]", 27, "Seoul");
      

      1. 단점
         1. “1234”가 패스워트인지 주소인지 헷깔림, 순서 틀려도 에러 안 잡힘
      2. @Builder방식

      import lombok.builder;
      
      @Builder
      public class User{
      	private String username;
      	private String password;
      	private String email;
      	private int age;
      	private String address;
      }
      
      User u = User.builder()
      			.username("minsang")
      			.password("1234")
      			.email("[email protected]")
      			.age(27)
      			.address("Seoul")
      			.build();
      

      1. 빌더의 단점
         1. 코드의 길이가 늘어남
         2. 빌더 객체가 만들어졌다가 다시 최존 객체가 만들어지는 구조라, 생성 비용이 조금 더 듦

8. @Service

   1. 스프링에서 서비스 계층 클래스임을 표시

   2. 비즈니스 로직을 담당하는 클래스 위에 붙임

   3. 기능

      1. 컴포넌트 스캔 대상이 된 → 스프링 컨테이너가 자동으로 빈으로 등록
      2. 기본적으로 클래스명을 기반으로 빈 이름 자동 생성

   4. 장점

      1. 비즈니스 로직을 담당하는 계층임을 명확하게 구분
      2. 다른 계층와 구조 구분 명확
      3. 스프링 DI에서 자동으로 인식

   5. 필요할 때만 괄호 사용

      1. 빈의 이름을 구체적으로 지정하고 싶을 때만

      @Service("joinService")
      
      

      1. 여러 구현체 중 특정 빈을 구분할 때 유용

9. 필드 주입과 생성자 주입 방식의 차이

   1. 필드 주입
      1. 장점
         1. 짧은 ,편함
      2. 단점
         1. 테스트 어려움, 객체 불변성 깨짐
   2. 생성자 주입
      1. 장점
      2. 단점