1. Bean 수동 등록
- @Component를 사용하면 @ComponentScan에 의해 자동으로 스캔되어 해당 클래스를 Bean으로 등록 해준다.
- 일반적으로 @Component를 사용하여 Bean을 자동으로 등록하는 것이 좋다.
- 프로젝트의 규모가 커질 수록 등록할 Bean들이 많아지기 때문에 자동등록을 사용하면 편리
- 비즈니스 로직과 관련된 클래스들은 그 수가 많기 때문에 @Controller, @Service와 같은 애너테이션들을 사용해서 Bean으로 등록하고 관리하면 개발 생산성에 유리
- 기술적인 문제나 공통적인 관심사를 처리할 때 사용하는 객체들을 수동으로 등록하는 것이 좋다.
- 공통 로그처리와 같은 비즈니스 로직을 지원하기 위한 부가 적이고 공통적인 기능들을 기술 지원 Bean이라 부르고 수동등록한다.
- 비즈니스 로직 Bean 보다는 그 수가 적기 때문에 수동으로 등록하기 부담스럽지 않다.
- 또한 수동등록된 Bean에서 문제가 발생했을 때 해당 위치를 파악하기 쉽다는 장점이 있다.
1-1. 같은 타입의 Bean
@SpringBootTest
public class BeanTest {
@Autowired
Food pizza;
@Autowired
Food chicken;
}
- 이렇게 등록된 Bean 이름 pizza, chicken을 정확하게 명시해주면 해결할 수 있다.
- 여기서 우리가 알 수 있는 점은 @Autowired가 기본적으로는 Bean Type(Food)으로 DI를 지원하며 연결이 되지않을 경우 Bean Name(pizza, chicken)으로 찾는 다는 것을 알 수 있다.
1) @Primary
@Component
@Primary
public class Chicken implements Food {
@Override
public void eat() {
System.out.println("치킨을 먹습니다.");
}
}
@Primary가 추가되면 같은 타입의 Bean이 여러 개 있더라도 우선 @Primary가 설정된 Bean 객체를 주입 해준다.
2) Qualifier
@SpringBootTest
public class BeanTest {
@Autowired
@Qualifier("pizza")
Food food;
@Test
@DisplayName("Primary 와 Qualifier 우선순위 확인")
void test1() {
// 현재 Chicken 은 Primary 가 적용된 상태
// Pizza는 Qualifier 가 추가된 상태입니다.
food.eat();
}
}
- 같은 타입의 Bean들에 Qualifier와 Primary가 동시에 적용되어있다면 Qualifier의 우선순위가 더 높다.
- 하지만 Qualifier는 적용하기 위해서 주입 받고자하는 곳에 해당 Qualifier를 반드시 추가해야한다.
- 따라서 같은 타입의 Bean이 여러 개 있을 때는 범용적으로 사용되는 Bean 객체에는 Primary를 설정하고 지엽적으로 사용되는 Bean 객체에는 Qualifier를 사용하는 것이 좋다.
2. 인증과 인가

인증(Authentication)
- 인증은 해당 유저가 실제 유저인지 인증하는 개념
- 여러분의 스마트폰에 지문인식, 이용하는 사이트에 로그인 등과 같이, 실제 그 유저가 맞는지를 확인하는 절차
인가(Authorization)
- 인가는 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인하는 개념
- 예를들어 관리자 페이지-관리자 권한 같은 것들을 들 수 있다.
1) "웹 애플리케이션 인증"의 특수성

- 일반적으로 서버-클라이언트 구조로 되어있고, 실제로 이 두가지 요소는 아주 멀리 떨어져 있다.
- 그리고 Http 라는 프로토콜을 이용하여 통신하는데, 그 통신은 비연결성(Connectionless) 무상태(Stateless)로 이루어진다.
비연결성(Connectionless)
- 비연결성(Connectionless)은 서버와 클라이언트가 연결되어 있지 않다는 것
- 서버는 실제로 하나의 요청에 하나의 응답을 내버리고 연결을 끊어버리고있다 라고 생각하면 좋다.
무상태(Stateless)
- 서버가 클라이언트의 상태를 저장하지 않는다는 것
2) 인증의 방식
2-1) 쿠키 세션 방식의 인증

쿠키-세션 방식은 서버가 ‘특정 유저가 로그인 되었다’는 상태를 저장하는 방식.
인증과 관련된 아주 약간의 정보만 서버가 가지고 있게 되고 유저의 이전 상태의 전부는 아니더라도 인증과 관련된 최소한의 정보는 저장해서 로그인을 유지시킨다는 개념
2-2) JWT 기반 인증

JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 토큰을 의미. JWT 기반 인증은 쿠키/세션 방식과 유사하게 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별
3. 쿠키와 세션
- 쿠키와 세션 모두 HTTP 에 상태 정보를 유지(Stateful)하기 위해 사용된다. 즉, 쿠키와 세션을 통해 서버에서는 클라이언트 별로 인증 및 인가를 할 수 있게된다.
1) 쿠키
- 클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일

- Name (이름): 쿠키를 구별하는 데 사용되는 키 (중복될 수 없음)
- Value (값): 쿠키의 값
- Domain (도메인): 쿠키가 저장된 도메인
- Path (경로): 쿠키가 사용되는 경로
- Expires (만료기한): 쿠키의 만료기한 (만료기한 지나면 삭제)
2) 세션
- 서버에서 일정시간 동안 클라이언트 상태를 유지하기 위해 사용
- 서버에서 클라이언트 별로 유일무이한 '세션 ID' 를 부여한 후 클라이언트 별 필요한 정보를 서버에 저장
- 서버에서 생성한 '세션 ID' 는 클라이언트의 쿠키값('세션 쿠키' 라고 부름)으로 저장되어 클라이언트 식별에 사용된다.

1. 클라이언트가 서버에 1번 요청
2. 서버가 세션ID 를 생성하고, 쿠키에 담아 응답 헤더에 전달
1. 세션 ID 형태: "SESSIONID = 12A345"
3. 클라이언트가 쿠키에 세션ID를 저장 ('세션쿠키')
4. 클라이언트가 서버에 2번 요청
- 쿠키값 (세션 ID) 포함하여 요청
5. 서버가 세션ID 를 확인하고, 1번 요청과 같은 클라이언트임을 인지
3) 쿠키와 세션 비교

4. JWT
JWT(Json Web Token)란 JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token 입니다. 즉, 토큰의 한 종류라고 생각하면 된다. 일반적으로 쿠키 저장소를 사용하여 JWT를 저장
1) 사용 이유
-
서버가 1대인 경우

Session1 이 모든 Client의 로그인 정보를 소유하고 있다.
-
서버가 2대인 경우

서버의 대용량 트래픽 처리를 위해 서버 2대 이상 운영이 필요할 수 있다.
-
세션 저장소 생성

Session storage 가 모든 Client 의 로그인 정보 소유하고 있기 때문에 모든 서버에서 모든 Client의 API 요청을 처리할 수 있다.
-
JWT 사용
로그인 정보를 Server 에 저장하지 않고, Client 에 로그인 정보를 JWT 로 암호화하여 저장 → JWT 통해 인증/인가

모든 서버에서 동일한 Secret Key 소유합니다. / Secret Key 통한 암호화 / 위조 검증 (복호화 시)

2) JWT 장/단점
1) 장점
- 동시 접속자가 많을 때 서버 측 부하 낮춤
- Client, Sever 가 다른 도메인을 사용할 때
- 예) 카카오 OAuth2 로그인 시 JWT Token 사용
2) 단점
- 구현의 복잡도 증가
- JWT 에 담는 내용이 커질 수록 네트워크 비용 증가 (클라이언트 → 서버)
- 기 생성된 JWT 를 일부만 만료시킬 방법이 없음
- Secret key 유출 시 JWT 조작 가능