[8,9,10주차/밤하늘] 워크북 제출합니다.

keyword/chapter08/keyword.md

@@ -0,0 +1,95 @@
+- java의 Exception 종류들
+
+    ### Error와 Exception 정리
+
+    ---
+
+    1. **Error**
+    - **JVM 내부 오류**를 나타냄
+        - 메모리 부족
+        - 스택 오버플로우 등
+    - **회복 불가능**한 심각한 문제
+    - 애플리케이션 코드에서 **처리하거나 잡지 않음**
+
+    1. **Exception**
+    - java.lang.Exception를 상속
+    - 두 가지 종류로 나뉨:
+
+        ### 2.1. Checked Exception
+
+        - RuntimeException 을 제외한 Exception
+        - **컴파일 타임**에 처리(try–catch) 또는 선언(throws) 필수
+        - 외부 I/O, 네트워크, 파일 입출력 등 **회복 가능**한 예외 상황에 사용
+        - 예시: `IOException`, `ClassNotFoundException`
+
+        ### 2.2. Unchecked Exception (RuntimeException)
+
+        - RuntimeException을 상속
+        - **처리나 선언 강제 없음**
+        - 프로그래밍 버그(널 참조, 잘못된 타입 변환 등) 나타냄
+        - 스프링에서는 **기본 롤백 대상**
+        - 예시: `NullPointerException`, `IllegalArgumentException`
+
+
+    ---
+
+    **정리**
+
+    - **Error**: JVM 수준의 심각한 오류, 애플리케이션 코드에서 건드리지 않음
+    - **Checked Exception**: 반드시 처리·선언, 회복 가능한 상황
+    - **Unchecked Exception**: 자유롭게 던지고, 스프링 트랜잭션·글로벌 핸들러에서 처리
+- Custom 어노테이션(ExistCategory)
+
+    ### 과정
+
+    1. @ExistCategory 가 붙어 있으면, 클라이언트 요청이 컨트롤러에 도달하자마자 **Bean Validation** 단계에서 걸리고,
+    2. 이때 발생하는 **MethodArgumentNotValidException**은 프로젝트의 @ControllAdvice 가 공통 400 에러로 매핑하고
+
+    ![image.png](attachment:03dfd103-058c-4522-9e75-63a989d44e89:image.png)
+
+    1. 실패한 필드의 메시지 텔플릿(FOOD_CATEGORY_NOT_FOUND)을 result 객체 안에 담아 응답한다.
+
+    ![image.png](attachment:43dc953d-e146-4ec3-b7ba-9b0f869a2e00:image.png)
+
+    ![image.png](attachment:924c1195-90e3-4597-a566-f356190e5157:image.png)
+
+    ### Custom 어노테이션을 사용하는 이유
+
+    1. **중복 로직 제거**
+
+        서비스나 컨트롤러에서 매번 try-catch 등의 에러 처리를 사용하는 대신 어노테이션으로 한 번에 처리하도록 해준다.
+
+    2. **표현의 일관성**
+    3. **유지보수 편의성**
+
+        검증 로직을 한 곳에 모아 두면, 나중에 검사 기준이 바뀌어도 validator 클래스에서 로직을 수정하면 된다
+
+- @Valid
+    - **@Valid**
+        - **용도**: @RequestBody의 DTO 바인딩 직후 Bean Validation을 실행
+        - **사용처**: 파라미터 선언부(@RequestBody MyDTO myDTO) 또는 Custom 어노테이션
+        - **예외 타입**: 검증 실패 시 → **MethodArgumentNotValidException**
+    - **@Validated**
+        - **용도**: 메서드 진입 전 AOP 방식으로 파라미터(경로·쿼리·폼 등) 제약조건을 검사
+            - PathVariable, RequestParam 조사
+        - **사용처:** Custom 어노테이션
+        - **어디에 붙이나**: 컨트롤러(@RestController)나 서비스 클래스(@Service) 위
+        - **예외 타입**: 검증 실패 시 → **ConstraintViolationException**
+
+        ### 정리
+
+        | 대상 파라미터 | 바인딩 검증 어노테이션 | 필요 설정 | 예외 타입 |
+        | --- | --- | --- | --- |
+        | @RequestBody | @Valid | (컨트롤러에 @Valid만) | MethodArgumentNotValidException |
+        |  @PathVariable, @RequestParam  | (표준·커스텀) | 컨트롤러 또는 메서드에 @Validated | ConstraintViolationException |
+
+
+    ### 에러 비교
+
+    ![image.png](attachment:763e408a-9390-4468-b48c-5cd24fc8da37:image.png)
+
+    ![image.png](attachment:6070a608-da52-4639-843a-5fe222cd0638:image.png)
+
+    → 실제로 각각 ConstraintViolationException, MethodArgumentNotValidException 에러 부분이고 에러가 달라서 이와 같이 요청 결과도 다르게 처리된다.
+
+    **notion에** 각 image 원본이 저장되어있습니다!

keyword/chapter09/keyword.md

@@ -0,0 +1,76 @@
+- Spring Data JPA의 Paging
+
+    *Spring Data JPA는 **페이징**을 위해 두 가지 객체를 제공하는데 이것이 바로 Slice와 Page*
+
+    **페이징**
+
+    : 사용자가 어떠한 데이터를 요청했을 때, 전체 데이터 중 일부를 원하는 정렬 방식으로 보여주는 방식
+
+    **페이징은 적용 방법**
+
+    페이징 기법 구현을 위해 기본적으로 알아야 하는 파라미터들이 있습니다.
+
+    - **page** : 페이징 기법이 적용되었을 때, 원하는 페이지
+    - **size** : 해당 페이지에 담을 데이터 개수
+    - **sort** : 정렬 기준
+
+    이 파라미터들을 Pageable 구현체에 담아 페이징을 설정
+
+    - Page
+
+        Pageble을 파라미터로하여 가져온 결과물은 `Page<SomeObject>` 형태로 반환 되며, Page를 사용한다면 대부분 다수의 row를 가져오기 때문에 `Page<List<SomeObject>>`의 형태로 반환을 한다. 이 페이지 객체에는 Pagination을 구현할 때 사용하면 좋은 메서드가 있으며 이는 다음과 같다.
+
+        ### getTotalElements()
+
+        쿼리 결과물의 전체 데이터 개수이다. 즉, Pageable에 의해 `limit`키워드가 조건으로 들어가지 않는 쿼리 **결과의 수** 인데, 주의해야 할 점은 쿼리 **결과의 갯수만** 가져오지 **전체 데이터를 가져오지 않는다**는 점이다.
+
+        이 메서드는 게시판 기능 사용자에게 전체 데이터 개수를 알려주는 등에 사용하기 좋다.
+
+        ### getTotalPages()
+
+        쿼리를 통해 가져온 요소들을 size크기에 맞춰 페이징하였을 때 나오는 총 페이지의 갯수이다.
+
+        이를 활용해 쉽게 페이지 버튼의 생성이 가능하다.
+
+        ### getSize()
+
+        쿼리를 수행한 전체 데이터에 대해 일정 수 만큼 나눠 페이지를 구성하는데, 이 일정 수의 크기이다.
+
+        ### getNumber()
+
+        요소를 가져온 페이지의 번호를 의미한다.
+
+        ### getNumberOfElements()
+
+        페이지에 존재하는 요소의 개수이다. 최대 size의 수 만큼 나올 수 있다.
+
+    - Slice
+        - **다음 슬라이스 존재 여부**
+            - 요청한 페이지 크기보다 `+1` 만큼 더 조회해 보고, 그 결과로 `hasNext()` 판단
+        - **메서드**
+            - `List<T> getContent()`
+            - `boolean hasNext()`
+            - `boolean hasPrevious()`
+            - `Pageable getPageable()`, `Pageable nextPageable()`
+        - **장점**
+            - **count 쿼리 생략** → 빠른 응답
+        - **단점**
+            - 전체 건수·전체 페이지 수 정보가 필요할 때 사용 불가
+- 객체 그래프 탐색
+    - **객체(node)**: JPA 엔티티 클래스 하나하나
+    - **연관(edge)**: @OneToMany, @ManyToOne와 같은 필드 매핑
+    - 이 둘이 연결되어 마치 **트리(tree)** 또는 **네트워크(graph)**처럼 이루어진 구조
+
+    ![image.png](attachment:7485b147-b701-419d-99b6-6da4e8077df9:image.png)
+
+    **객체 그래프 탐색의 요소**
+
+    - **로딩 전략 (FetchType)**
+        - **EAGER**: 연관된 엔티티를 즉시 함께 조회
+        - **LAZY**: 실제 사용할 때(필드 호출 시) 조회
+    - **영속성 컨텍스트 (Persistence Context)**
+        - 한번 로드된 엔티티는 1차 캐시에 보관
+        - 동일 트랜잭션 내에 다시 조회하면 1차 캐시에서 반환 → 중복 쿼리 방지
+    - **프록시 (Proxy)**
+        - LAZY 연관관계일 때, 실제 엔티티 대신 가짜 객체를 미리 만들어 두고
+        - 접근 시점에 실제 데이터를 조회

keyword/chapter10/keyword.md

@@ -0,0 +1,21 @@
+- **Spring Security**
+
+    애플리케이션의 보안(인증 및 인가)을 담당하는 프레임워크. 복잡한 보안 로직을 간편하게 구현할 수 있도록 돕는다.
+
+- **인증(Authentication)과 인가(Authorization)**
+
+    인증 : 누가 누구인지 확인하는 절차
+
+    인가 : 인증된 사용자가 특정 리소스나 기능에 접근할 권한이 있는지 확인하는 절차
+
+- **세션과 토큰**
+
+    세션 : 클라이언트와 서버 간의 연결이 지속되는 동안 상태를 유지하는 방법, 주로 서버의 메모리에 저장된다
+
+    토큰 : 사용자의 인증 정보를 담고 있는 문자열. 세션 방식과 달리 서버가 상태를 저장하지 않는(Stateless) 방식
+
+- **액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)**
+
+    액세스 토큰 : 리소스에 접근하기 위한 권한을 부여하는 토큰. 만료 기간을 짧게 설정하여 탈취 시의 위험을 줄이는 것이 일반적이다.
+
+    리프레시 토큰 : 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰. 액세스 토큰보다 만료 기간을 길게 설정한다.