24.07.25
today 😉
[handler라는 용어는 뭘까❓]
프로그램에서 자동으로 호출되는 메서드를 handler라고 부른다.
[Exception 핸들러에서 parameter로 예외를 왜 받아야 할까❓]
@ResponseStatus(HttpStatus.NOT_FOUND)
@ExceptionHandler(value = UserNotFoundException.class)
public String handleUserNotFoundException(UserNotFoundException exception) {
log.info("exception class : {}", exception.getClass());
return "User Not Found!";
}위의 코드 처럼 로그 핸들링이나 에러에 대한 다른 작업을 하기위해서 parameter로 에러를 받는 것 같다. 그리고 어노테이션에 value없이 파라미터만 있어도 파라미터로만으로 잡을 에러를 추측하여 에러를 잡아 준다.
[ControllerAdivce 왜 필요할까❓]
"A 컨틀롤러에서 발생한 예외를 B 컨트롤러에서 잡을 수 있을까?" 대한 답을 생각해보면 전역적으로 예외를 핸들링해줄 클래스가 필요하다는 결론이 나온다.
[@RestControllerAdvice는 뭐야❓]
@RestController 처럼 @ResponseBody 붙은 아이라고 생각하면 된다. 애초에 Spring은 Full Stack을 지원하기 위해 나온 프레임워크 이기 때문에 컨트롤러는 View를 반환하는것이 default이다. @ResponseBody 어노테이션을 사용하여 뷰 리졸버를 사용하지 않게 하기 위하여 존재하는 Advice이다.
[유효성 검사 어디서 해야하는가❓]
프론트, 백 둘 다 필요하다고 생각한다.
클라이언트 단에서 유효성 검사를 진행할 시 서버와의 통신없이 사용자에게 빠른 피드백을 줄 수 있어 UX를 개선 시킬 수 있다. 그리고 유효하지 않은 요청은 클라이언트 단에서 1차적으로 걸러서 서버의 부하를 감소시킬 수 있다.
서버 단에서 유효성 검사를 진행할 시 클라이언트 단에서 악의적으로 우회한 요청에 대해 거를 수 있다. 이를 통해 클라이언트에서 요청한 데이터를 신뢰 할 수 있고 보안을 강화할 수 있다고 생각한다.
[MethodArgumentNotValidException이 뭘까❓]
주로 클라이언트에서 보낸 데이터가 유효성 검사를 통과하지 못했을 때 발생한다.
public class UserDTO {
@NotEmpty(message = "Name is required")
@Size(min = 2, max = 30, message = "Name must be between 2 and 30 characters")
private String name;
@NotEmpty(message = "Email is required")
private String email;
}예시 코드 처럼 DTO에 어노테이션을 달아서 유효성 로직을 표시하고
@PostMapping("/users")
public ResponseEntity<String> createUser(@Valid @RequestBody UserDTO userDTO) {
return ResponseEntity.ok("User created successfully");
}@Valid 애노테이션으로 유효성 검사를 하여 유효성검사를 통과하지 못했을 때 MethodArgumentNotValidException이 발생 한다.
[log 왜 사용하는가❓]
운영하고 있는 시스템이 잘 돌아가고 있는지 텍스트 문서로 문서화하기 가장 간편한 방법이기 때문에 사용한다고 한다. 대표적으로 사용되는 라이브러리로는 SLF4J가 있다.
[로그에도 레벨이 있다⁉️]
로그 레벨은 로그 메세지의 중요도를 나타낸다고 한다. 현업에서는 개발 서버는 보통 DEBUG
레벨까지 설정하고 운영 서버는 INFO레벨로 관리한다고 한다.
중요도
- TRACE: 중요도가 낮은 정보
- DEBUG: 진행 상황 체크 (중요도, 심각도 낮은 정보)
- INFO: 진행 상황
- WARN: 잠재적으로 유해한 이벤트
- ERROR: 오류 이벤트 (치명적인지 여부는 상관 없음)
Tomcat, Spring에서 모두 log에 대한 레벨을 설정할 수 있다.
Spring에서 레벨 설정은 application.properties에서 하고
logging.level.root = warnTomcat에서 레벨 설정은 logging.properties에서 설정한다.
[Lombok에서 annotationProcessor설정 없이 왜 컴파일이 안될까❓]
Lombok은 단순히 어노테이션을 제공하여 보일러플레이트 코드(중복 코드)를 줄이기 위해 어노테이션을 제공하는 라이브러리이고, annotationProcessor는 컴파일 타임에 어노테이션을 처리하여 필요한 소스코드를 .class파일에 추가해주는 역할을 하기 때문에 annotationProcessor설정 없이는 컴파일 에러가 난다.
[사용자 비밀번호 암호화는 클라이언트와 서버 둘 중 어디서 해야하는 가❓]
클라이언트, 서버 모두 암호화 할 수 있지만 서버단에서는 무조건 해야 한다고 생각한다.
클라이언트 측에서 암호화한 데이터를 바로 사용할 시 암호화 된 비밀번호 자체가 공격자에게 노출될 위험이 있다. 또한 서버에서 중앙 집중화하여 암호화 알고리즘 및 키관리를 한다면 조금 더 쉽게 관리할 수 있다는 장점이 있다.
클라이언트에서는 암호화도 좋지만, 서버간의 통신을 안전하게 보호하여 전송 중 데이터를 안전하게 보호해야한다고 생각한다. 하지만 암호화를 할 시 전송 중 탈취과정에서 고유 비밀번호가 아닌 암호화된 비밀번호를 탈취당하기 때문에 타 사이트에서 해킹 될 위험이 낮아질 수 있을 것 같다.
[서버간의 통신을 안전하게 보호하는 방법이 뭐가 있을까❓]
기본적으로 HTTPS를 사용하는 방법이 있다.
SSL/TLS(Secure Sockets Layer/Transport Layer Security) 프로토콜을 사용하여 데이터 전송을 암호화하고 데이터 무결성을 보장할 수 있다.
1️⃣ SSL/TLS 핸드쉐이크 과정
- 클라이언트 헬로(Client Hello):
클라이언트가 서버에 연결 요청을 보냅니다. 이 요청에는 클라이언트가 지원하는 SSL/TLS 버전, 암호화 알고리즘 목록, 무작위 데이터 등이 포함됩니다. - 서버 헬로(Server Hello):
서버가 클라이언트의 요청에 응답합니다. 이 응답에는 선택된 SSL/TLS 버전, 암호화 알고리즘, 무작위 데이터 등이 포함됩니다. - 서버 인증(Server Authentication) 및 키 교환(Key Exchange):
서버는 자신의 인증서를 클라이언트에게 보냅니다. 인증서에는 서버의 공개 키가 포함되어 있습니다.
클라이언트는 인증서를 검증하여 서버의 신원을 확인합니다. - 클라이언트 키 교환(Client Key Exchange):
클라이언트는 세션 키를 생성하고, 서버의 공개 키를 사용하여 이 세션 키를 암호화한 후 서버에 전송합니다. - 세션 키 생성(Session Key Creation):
서버는 자신의 개인 키를 사용하여 클라이언트로부터 받은 세션 키를 복호화합니다.
이제 클라이언트와 서버는 공통의 세션 키를 가지게 되며, 이를 사용하여 데이터를 암호화합니다. - 완료(Finalization):
클라이언트와 서버는 이제 암호화된 세션을 사용하여 안전하게 통신할 수 있습니다.
