diff --git a/keyword/chapter00/keyword.md b/keyword/chapter00/keyword.md
new file mode 100644
index 0000000..3058433
--- /dev/null
+++ b/keyword/chapter00/keyword.md
@@ -0,0 +1,220 @@
+
+# 🎯 핵심 키워드
+
+### **IP**
+- 인터넷 망 내에서 특정 컴퓨터 식별자 역할을 한다.
+- OSI 7계층에서 network Layer에서 필요
+- TCP/IP 4계층에서 internet Layer에서 필요
+---
+### **PORT**
+* 하나의 컴퓨터 내에서 프로세스를 식별하는 역할을 한다.
+* OSI 7계층에서 transport Layer에서 필요
+- TCP/IP 4계층에서 transport Layer에서 필요
+- --
+### **CIDR**
+* Classless Inter-Domain Routing
+
+인터넷 상의 데이터 라우팅 효율성을 향상시키는 **IP 주소 할당 방법**이다. 조직에서 CIDR을 사용하여 네트워크에 유연하고 효율적으로 IP 주소를 할당한다.
+
+**다른 IP 주소형식으로는 어떤 것?**
+- 클래스 기반 주소 지정 시스템
+- IP 주소는 네트워크 주소, 호스트 주소로 나뉜다.
+- 클래스 기반 주소 방식은 클래스 A,B,C로 나뉘어 네트워크 주소, 호스트 주소의 비트 수가 고정된다.
+
+CIDR은 가변 길이 서브넷 마스킹(VLSM)을 사용하여 네트워크 주소와 호스트 주소 비트 비율을 변경한다.
+서브넷 마스크는 호스트 주소를 0으로 변환하여 네트워크 주소 값을 반환하는 값이다.
+
+
+#### CIDR의 장점
+
+- **IP 주소 낭비 감소**
+  VLSM을 이용하여 네트워크 관리자는 다양한 크기의 서브넷을 부여 가능하다. 네트워크 주소 접두사 비트 수를 나타내는 접미사 값을 일반 IP 주소에 추가한다.
+  ex. 192.0.2.0/24
+  192.0.2 -> 네트워크 주소
+  클래스 기반 배치는 IP 주소 공간의 낭비로 이어진다. CIDR은 이를 해결할 수 있다. 네트워크 주소의 길이를 지정가능하기 때문에 특정 네트워크에 필요한 IP 주소 개수를 유연하게 할당 가능 하다.
+
+- **슈퍼넷을 유연하게 생성**
+  VPC는 연결된 디바이스 간에 데이터 패킷을 전송할 때 CIDR IP 주소를 사용한다.
+
+----
+### **TCP와 UDP 차이**
+* TCP는 IP 만으로 통신했을 때 부족한 점을 보완한다.
+  * 연결 지향
+  * 순서 보장
+  * 전달 보장
+* UDP는 TCP에서 많은 기능이 제외된다.
+  * IP, Port, Checksum 정도만 포함한다.
+  * application Layer에서 많은 부분을 담당해야 한다.
+
+---
+### **Web Server와 WAS의 차이**
+- Web Server
+  - 정적 리소스 제공
+- WAS
+  - 동적 리소스 제공
+  - Web Server의 기능 수행 가능
+* Web Server와 WAS의 혼용
+  * Web Server는 보안, reverse proxy, 정적 리소스 제공, WAS의 에러 발생 시 클라이언트에게 에러 페이지 전달 등 여러 기능을 대신 수행한다.
+  - WAS는 무겁고 에러가 빈번하며 비싼 서버이다. 따라서 WAS가 할 수 있더라도, Web Server가 잘 담당할 수 있는 기능은 Web Server에게 책임 분리한다.
+
+---
+## 추가 정리
+
+### **OSI 7계층과 TCP/IP 4계층 모델**
+
+**웹 브라우저 통신과정**
+* 크롬 브라우저 검색창에서 url 을 입력
+* 크롬 브라우저는 이를 네트워크에서 http 형식에 맞게 데이터 생성
+* 인터넷을 통해 네이버 서버로 전달된다.
+* 네이버 서버는 이 패킷을 풀어서, 데이터를 해석한다.
+
+**송신 호스트**
+- 우리는 브라우저라는 응용 계층을 통해서 요청한다.
+- 각 데이터들은 순서를 지키면서 한 계층씩 내려간다.
+  - 각 계층에서 필요한 데이터를 기존 데이터에 추가하면서 내려간다.
+
+**수신 호스트**
+- 인터넷을 통해서 서버 컴퓨터에 데이터가 전달된다.
+- 그러면 송신 호스트와 **역순으로** 각 계층에서 필요한 데이터를 분리하여 해석한다.
+- 실제 서버 어플리케이션에서는 클라이언트가 요청한 http 형식의 데이터가 전달된다.
+- 그리고 http 형식의 데이터를 서버가 해석하고, 그에 따른 응답 메세지를 http 형식으로 다시 만들어서 클라이언트에게 응답한다.
+
+
+### 프로토콜이란?
+- 규약
+
+네트워크에서 필요한 프로토콜은 크게 HTTP, TCP, UDP 가 있을 것이다.
+해당 프로토콜들은 각각 다른 계층에서 필요한 규약이다.
+
+
+
+### OSI 7계층 모델이란?
+- 각 계층에서 해야할 일을 책임분리한다.
+
+**응용 계층(Application Layer)**
+- 최상위 계층
+
+**표현 계층(Presentation Layer)**
+- 계층 간 데이터를 적절히 표현하는 부분을 담당한다.
+- 이미지를 압축, 데이터를 암호화
+
+**세션 계층(Session Layer)**
+- 통신 세션을 구성
+
+**전송 계층(Transport Layer)**
+- 컴퓨터로 들어온 네트워크 데이터를 어느 포트(어느 프로세스)로 보낼지 담당
+- TCP protocol을 사용한다면?
+  - 신뢰성 있는 데이터를 보장하는 역할
+    - 논리적으로 연결 - 3 way handshake
+    - 데이터 순서 보장
+
+**네트워크 계층(Network Layer)**
+- IP 주소를 통해 어느 컴퓨터로 보낼지 담당
+
+**데이터링크 계층(Data Link Layer)**
+- Mac 주소
+
+**물리 계층(Physical Layer)**
+- 디지털 신호
+
+
+
+### TCP/IP 4계층 모델이란?
+- 실제 대부분의 인터넷 통신은 TCP/IP 통신을 사용한다. OSI 7계층을 단순화 한다.
+
+**응용 계층(Application Layer)**
+- Http, Telnet, ssh, ftp 같은 프로토콜이 여기에서 사용
+
+> **개인적인 생각 정리**
+> 
+> 우리가 개발하고 있는 Spring Boot Server는 tomcat을 내장하고 있다.
+> 개발자는 tomcat 및 Spring Web을 기능을 이용해 코드 수준에서 Session(tomcat이 지원하는 session), Presentation(데이터 압축), Application(thymeleaf, tomcat의 데이터 입출력) 를 건드릴 수 있다.
+> 그래서 경계가 모호하다. 따라서 OSI 7 계층에서 5,6,7의 계층이 하나로 합쳐진 것 같다.
+
+
+**전송 계층(Transport Layer)**
+- 신뢰성 있는 데이터 전송 -> **TCP 를 사용해야만**
+- UDP는 TCP의 많은 기능들이 제외된다. 신뢰성을 확보하지 못하며 Application 계층에서 이를 담당 해야한다.
+
+**인터넷 계층(Internet Layer)**
+- IP
+- 컴퓨터간 라우팅을 담당한다.
+
+**네트워크 인터페이스 계층(Network Interface Layer)**
+- 물리적 계층
+
+
+### HTTP vs HTTPS
+- Application Layer와 Transport Layer 사이에 SSL/TLS 계층이 존재한다.
+- HTTP는 보안에 취약하기 때문에 HTTPS가 이를 보완한다.
+
+
+---
+### 인터넷
+- 데이터를 전달해주는 거대한 network 망
+
+**인터넷 구성**
+- 인터넷은 여러가지 형태의 network와 그 안의 sub-network로 구성된다.
+- network edge, access network, network core
+
+**network edge**
+- 끝에 있는 entity
+- end system
+- web browser, 스마트폰, 개발할 server
+
+**access network**
+- internet과 연결되는 첫 부분
+- 랜선, 와이파이 등
+
+**network core**
+- 데이터를 실어 나르는 역할
+- router
+
+---
+### 인터넷 통신
+- end system 간 데이터(Packet)를 주고 받는 것
+- 주고 받는 데이터 형식은 TCP or UDP, IPv4 or IPv6 에 따라 형태가 달라진다.
+
+**IP**
+- 인터넷 상에서 대상을 식별하는 수단
+- 문제점
+  - 라우터들은 OSI 7계층에서 3계층까지만 보고 데이터를 응답 요청.
+  - 패킷이 소실된다면?
+
+**Port**
+- 같은 IP 내 프로세스 구분 용도
+
+**TCP**
+- 3 way-handshake를 통해 상태확인을 함으로써 논리적 연결 확인
+- 데이터 전달 보증
+  - 패킷이 손실될 수 있기 때문에 데이터를 받았다는 것을 상대에게 알려줌
+- 데이터 순서 보장
+  - 패킷에 sequence number를 붙히고 패킷 간의 순서를 특정한다.
+  - 도착 순서가 잘못되었다면 잘못된 곳부터 다시 달라고 요청한다.
+
+**UDP**
+- IP, PORT, checksum 정도만 있다.
+- TCP와 같은 계층이지만 많은 기능이 제외
+- Application에서 많은 제어가 필요
+- HTTP/3는 UDP 기반
+
+
+---
+### Web Server와 WAS
+
+**web server**
+- 정적인 자원 제공
+- Apache, Nginx
+
+**WAS**
+- 동적 리소스 제공
+- web server 기능도 제공
+- Tomcat
+
+요즘은 web server와 WAS를 혼용한다.
+Web Server는 WAS 앞단에 위치하여 많은 역할을 담당한다.
+- reverse proxy
+- 로드 밸런싱
+- 보안
+- 정적 리소스 제공
+- WAS 에러 시 클라이언트에게 에러 페이지 제공 등
\ No newline at end of file
diff --git a/keyword/chapter01/keyword.md b/keyword/chapter01/keyword.md
new file mode 100644
index 0000000..d75bf4d
--- /dev/null
+++ b/keyword/chapter01/keyword.md
@@ -0,0 +1,124 @@
+# 🎯 핵심 키워드
+
+- 외래키
+- 기본키
+- ER 다이어그램
+- 복합 키
+- 연관관계
+- 정규화
+- 반 정규화
+---
+### **외래키**
+
+- 한 테이블의 컬럼이 다른 테이블의 Unique한 Key(보통 기본키)를 참조
+- 테이블 간 연관관계를 나타냄
+- Nullable
+
+**특징**
+- 참조 데이터가 삭제되거나, 수정 발생 시 연관된 테이블의 데이터를 함께 수정가능
+    - ex. cascade
+- 연관된 테이블에 없는 데이터가 입력되는 것을 방지
+    - 참조 무결성
+
+> 참고: 외래키로 인한 성능저하로, 현업에서는 외래키를 사용하지 않는 경우도 있다.
+
+
+---
+### **기본키**
+
+- 각 행에서 Unique 하게 식별할 수 있는 값
+- Not Null
+- 주로 인조키를 만들어서 사용
+
+- --
+### **ER 다이어그램**
+
+- 데이터베이스 설계 시 사전에 그리는 diagram
+- 실제 관계형 데이터베이스의 청사진
+
+**구성요소**
+- **entity**
+    - 테이블에 대응
+- **attritbute**
+    - 테이블 내의 컬럼에 대응
+- **relationship**
+    - 엔터티 간 연관성
+    - entity 간 상호작용
+
+---
+### 복합 키
+- 두 개 이상의 컬럼을 조합한 **고유 식별자**
+- 하나의 컬럼만으로 고유성을 보장 못할 때 사용 가능
+
+----
+### **연관관계**
+- 테이블 간 상호작용을 정의
+- 주로 외래키를 통해 구현
+
+**종류**
+- **1:1**
+    - 한 엔터티가 다른 하나의 엔터티만을 가질 때
+    - 하나의 테이블을 골라서 외래키 설정
+
+- **1:N**
+    - 한 엔터티가 다른 엔터티를 여러 개 가질 때
+    - 하나의 테이블을 골라서 외래키 설정
+
+- **N:M**
+    - 하나의 엔터티는 다른 엔터티를 여러개 가질 수 있고, 그의 역도 존재할 때
+    - 보통 새로운 연관관계 테이블을 생성하여 두 개의 1:N 관계로 풀어낸다.
+
+**연관관계 관리 종류**
+- 단방향 연관관계
+- 양방향 연관관계
+
+---
+### **정규화**
+
+- **목적**
+    - 중복 제거
+        - 중복이 있으면, 수정 시 일관성있는 데이터 유지하기 어려움
+    - 데이터 무결성 유지
+        - 데이터 변경 시 발생하는 이상 현상을 방지
+
+- **이상 현상**
+    - 보통 데이터의 중복으로 발생
+    - 삽입, 갱신, 삭제 시 정규화되지 않은 데이터로 인해 발생하는 의도치 않은 상황을 의미
+
+- **단계**
+    - **1NF**
+        - 각 컬럼이 더 이상 분해되지 않음
+    - **2NF**
+        - 1NF 만족
+        - 부분 함수 종속성을 제거
+    - **3NF**
+        - 2NF 만족
+        - 이행적 종속성을 제거
+        - 기본 키가 아닌 컬럼이 기본 키가 아닌 컬럼에 종속되지 않아야한다.
+    - **BCNF**
+        - 3NF 만족
+        - 후보키에 의한 함수 종속성 제거
+
+> 참고: **부분함수 종속성**
+> 기본키의 일부에 종속되는 컬럼이 있는 상황
+
+> 참고: **이행적 종속성**
+> 기본키가 아닌 속성이 다른 속성에 종속성을 가질 때
+
+- **주의사항**
+    - 지나친 정규화는 Join으로 인한 복잡한 쿼리가 필요하고, 성능저하로 이어짐
+    - 따라서 조회 성능을 향상 시키기 위해 반정규화가 가능
+
+---
+
+### **반정규화**
+- 정규화된 데이터베이스에서 복잡한 Join 연산으로 인해 성능저하 시 고려
+- 테이블 병합
+- 컬럼으로 계산된 값 및 중복된 값을 추가
+
+**목적**
+- Query 성능 최적화
+
+
+**고려사항**
+- 데이터 중복 및 이상현상 발생 가능
\ No newline at end of file
diff --git a/keyword/chapter03/keyword.md b/keyword/chapter03/keyword.md
new file mode 100644
index 0000000..c89210d
--- /dev/null
+++ b/keyword/chapter03/keyword.md
@@ -0,0 +1,159 @@
+# REST API
+
+기본적으로 API를 설계할 때, **리소스를 식별하고, URI 계층 구조를 활용**한다.
+리소스와 행위를 분리하라. 가장 중요한 것은 리소스를 식별하는 것.
+리소스와 해당 리소스를 대상으로 하는 행위를 분리하라.
+그렇다면 이 행위는 어떻게 구분할까? 바로 메서드를 사용하는 것이다.
+
+
+## HTTP 메서드 종류
+- GET
+    - 리소스 조회
+    - 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리스트링)을 통해서 전달
+    - 메세지 바디가 가능은 하지만 지원하지 않는 곳이 많아서 권장하지 않는다.
+- POST
+    - 메세지 바디를 통해 서버로 요청 데이터를 전달
+    - 서버는 요청 데이터를 처리
+    - 만능 -> 요청 데이터를 어떻게 처리할 지 정해진 것이 없음
+    - 컨트롤 URI
+    - 다른 메서드로 처리하기 애매한 경우에도 사용
+- PUT
+    - 리소스를 대체, 해당 리소스가 없으면 생성, 쉽게 이야기 해서 덮어쓰기
+    - **클라이언트가 리소스 위치를 알고 URI 지정**
+        - 이게 POST와의 차이점
+- PATCH
+    - 리소스 부분 변경
+- DELETE
+    - 리소스 삭제
+- HEAD
+    - GET과 동일하지만, 메세지 부분이 없고 상태 줄과 헤더만 반환
+- OPTIONS
+    - 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명
+    - 주로 CORS에서 사용
+- CONNECT
+    - 대상 리소스로 식별되는 서버에 대한 터널을 설정
+- TRACE
+    - 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행
+
+
+
+## HTTP 메서드의 속성
+- 안전
+    - 호출해도 리소스를 **변경하지 않는다.**
+- 멱등
+    - 여러 번 호출해도 결과가 똑같다
+        - GET -> O
+        - PUT -> O
+        - DELETE -> O
+        - POST -> X
+    - 자동 복구 메커니즘
+        - 서버가 정상응답을 못주었을 때 클라이언트가 같은 요청을 다시 해도 되는가?
+    - 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다.
+- 캐시가능
+    - 응답 결과 리소스를 캐시해서 사용해도 되는가?
+    - GET, HEAD, POST, PATCH 캐시 가능
+    - 실제로는 GET, HEAD 정도만 캐시로 사용
+        - POST, PATCH는 본문 내용까지 캐시 키로 고려해야하는데, 구현이 쉽지 않음
+
+
+## HTTP 메서드 활용
+
+**데이터 전달방식은 크게 2가지**
+- 쿼리 파라미터를 통한 데이터 전송
+    - GET
+    - 주로 정렬 필터(검색어)
+- 메세지 바디를 통한 데이터 전송
+    - POST, PUT, PATCH
+    - 회원 가입, 상품 주문, 리소스 등록, 리소스 변경 …
+
+**클라이언트가 서버에게 요청하는 방식은 크게 4가지**
+- 정적 데이터 조회
+    - 이미지, 정적 텍스트 문서
+    - GET
+    - 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능
+- 동적 데이터 조회
+    - 주로 검색, 게시판 목록에서 정렬 필터(검색어)
+    - 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
+    - GET
+    - 쿼리 파라미터를 사용해서 데이터를 전달
+- HTML FORM을 통한 데이터 전송
+    - GET, POST만 지원
+    - GET
+        - 조회 가능
+        - 전송 데이터를 url encoding 처리한다.
+            - 예) abc김 -> abc%EA%B9%80
+    - POST
+        - 쿼리 파라미터와 같은 형식(key,value)의 데이터가 Body에 포함되어 전달된다.
+    - 파일업로드
+        - POST
+        - multipart/form-data
+        - 다른 종류의 여러 파일과 폼의 내용 함께 전송
+
+
+- HTML API를 통한 데이터 전송
+    - 서버 to 서버
+        - 백엔드 시스템 통신
+    - 앱 클라이언트
+    - 웹 클라이언트
+        - React, VueJs 같은 웹 클라이언트와 API 통신
+        - 자바 스크립트를 통한 통신 (Ajax)
+
+
+## HTTP API 설계 예시
+- HTTP API - 컬렉션
+    - POST 기반 등록
+    - 보통 컬렉션 사용
+- HTTP API - 스토어
+    - PUT 기반 등록
+    - 정적 컨텐츠, 원격 파일 관리
+- HTML FORM
+    - 웹 페이지
+    - GET, POST만 지원
+
+
+**회원 관리 시스템 예시**
+
+1. API 설계 - POST 기반 등록 (**컬렉션**) -> 주로 사용
+- 회원 목록
+    - GET
+    - /members
+- 회원 등록
+    - POST
+    - /members
+    - **서버가 새로 등록된 리소스 URI을 관리한다.**
+        - ex. Location: /members/100
+- 회원 조회
+    - GET
+    - /members/{id}
+- 회원 수정
+    - PATCH, PUT, POST
+    - members/{id}
+- 회원 삭제
+    - DELETE
+    - members/{id}
+
+컬렉션은 서버가 관리하는 리소스 디렉토리이다. 서버가 리소스의 URI을 생성하고 관리한다.
+여기서 컬렉션은 /members 이다.
+
+
+2. API 설계 - PUT 기반 등록 (**스토어**)
+
+- 파일 목록
+    - GET
+    - /files
+- 파일 조회
+    - GET
+    - /files/{filename}
+- 파일 등록
+    - PUT
+    - /files/{filename}
+- 파일 삭제
+    - DELETE
+    - /files/{filename}
+- 파일 대량 등록
+    - POST
+    - /files
+
+클라이언트가 리소스 URI을 알고 있어야 한다.
+**클라이언트가 직접 리소스의 URI을 지정하는 것이다.**
+즉, 스토어는 클라이언트가 관리하는 리소스 저장소이다.
\ No newline at end of file
diff --git a/keyword/chapter05/keyword.md b/keyword/chapter05/keyword.md
new file mode 100644
index 0000000..ab26fbe
--- /dev/null
+++ b/keyword/chapter05/keyword.md
@@ -0,0 +1,50 @@
+### Domain
+도메인의 정의는 보통 비즈니스 로직과 관련된 객체를 의미합니다.
+Java는 객체지향 언어로 객체지향적으로 작성된 프로그램의 객체를 보통 Domain이라고 칭합니다.
+
+Spring Boot + RDBMS 로 개발을 진행할 때 문제가 발생할 수 있습니다.
+보통 편리한 Mapping을 위해서 Table 형식에 맞게 Java 객체를 만들어서 조회를 하게 됩니다.
+Table 형태와 객체지향의 Domain 형태는 목적이 다르기 때문에 각각의 형태가 불일치할 수 밖에 없습니다.
+
+이를 해결하기 위해서 만들어진 기술이 바로 ORM 입니다. 대표적으로 Spring에는 JPA 기술을 사용하는데,
+ORM을 사용함으로써 Domain 객체를 RDBMS의 table에 잘 매핑하면 이 둘의 부조화를 해결할 수 있습니다.
+
+### 양방향 매핑
+
+Spring ORM 기술인 JPA를 사용할 때 서로 참조할 수 있는 mapping 기술입니다.
+
+예를 들어, `Member`와 `Team`이라는 Table이 존재한다고 가정합니다. RDBMS의 관점으로 바라보면, `Member` : `Team` 은 **N:1** 의 관계입니다. Member table에 Team의 foregin key가 존재한다는 것입니다.
+
+이 때, 단방향 매핑만 사용한다면 `Member` 객체에 `Team`이라는 객체만 생성되고, `Team`이라는 객체에는 `Member`와 관련된 정보가 존재하지 않습니다.
+
+만약 `Team`에도 `List<Member>` 와 같은 자료형을 통해 해당 팀에 존재하는 Member들을 가지고 있는 형태를 원할 수도 있습니다. 이 때 사용하는 것이 바로 양방향 매핑입니다.
+
+양방향 매핑은 주의할 점이 존재하는데, 무한루프가 발생할 수 있습니다. `toString()`, `equals()`, `hashCode()` 메서드를 사용할 때 주의해야 합니다. 조회할 때 또한 무한 루프가 발생할 수 있으니 주의하여 사용해야 합니다.
+
+양방향 매핑은 `mappedBy` 를 통해 연관관계의 주인을 정할 수 있습니다. 위의 예시를 다시 가져온다면 Team에 `List<Member>`가 존재할 때, `mappedBy = team` 을 `@OneToMany` 의 어노테이션에 적어준다면 어떤 일이 일어날까요?
+
+위의 의미는 `Member` 객체에 있는 `Team team`에 따라서  `List<Member>` 가 거울처럼 사용된다는 것으로 Member가 연관관계의 주인이 되어 Member의 Team team을 수정해야만 연관관계가 수정될 수 있다는 것입니다. `Team` 객체의 `List<Member>`를 수정하더라도 연관관계는 변동되지 않습니다.
+
+cascade 옵션도 알아야 합니다. 만약 ALL로 설정이 되어있다면 위의 예시에서 Team을 삭제하면 Team에 소속된 Member들이 삭제되는 현상이 발생합니다. 따라서 매우 주의해서 사용해야하는 옵션입니다.
+
+
+### N + 1 문제
+
+하나의 쿼리로 인해서 N개의 쿼리가 수행되어 성능저하가 발생하는 것을 N+1 문제라고 이야기 합니다.
+JPA를 사용하면 N + 1 문제가 발생할 수 있습니다.
+
+예를 들어 Member와 Team의 예시로 다시 가보면, 만약 모든 Member들을 조회하는 쿼리를 수행했다고 합니다. 그리고 이때 Lazy 로딩 방식으로 설정해놓은 상황입니다.
+
+Lazy 로딩으로 하였을 때는, Member의 Team 객체는 프록시로 들어가 있습니다. 만약 가져온 모든 Member list를 for문을 돌면서 Team의 필드에 접근하게 된다면 이 때 지연로딩이 수행되면서 JPA는 DB에 접근해 Team을 조회해서 가져오게 됩니다. Member가 10000명이라면 10000번의 쿼리가 수행되게 되는 것입니다. 물론 JPA가 영속성 컨텍스트가 존재하기 때문에 영속성 컨텍스트에 존재하는 Team이라면 DB에 접근하지 않아 실제로 10000번을 수행하진 않겠지만, 이는 N+1 문제라고 이야기 할 수 있습니다.
+
+이 때 해결할 수 있는 대표적인 방법으로는 Fetch Join과 @EntityGraph가 있습니다. 바로 Join을 수행해서 미리 Member에 관련된 Team 객체들을 가져오는 것입니다. 이렇게 되면 Member의 Team 객체 내에는 이미 데이터가 존재하기 때문에 쿼리를 추가로 수행하지 않습니다.
+
+추가적으로 Lazy 방식을 사용하게 되면 무조건 프록시 방식을 사용하는 것이 아닙니다.
+Member의 Team 객체가 @ManyToOne으로 되어있고, Lazy 방식으로 설정되어있어도,
+
+```java
+@Query("SELECT m FROM Member m JOIN FETCH m.team")
+List<Member> findAllMembersWithTeams();
+
+```
+만약 아래처럼 JPQL fetch join을 사용해서 가져온다면 Member 내부의 Team 객체는 프록시 객체가 아닌 실제 객체가 들어갑니다.
\ No newline at end of file
diff --git a/keyword/chaptor04/keyword.md b/keyword/chaptor04/keyword.md
new file mode 100644
index 0000000..22bc484
--- /dev/null
+++ b/keyword/chaptor04/keyword.md
@@ -0,0 +1,119 @@
+# IoC (Inversion of Control)
+
+IoC는 제어의 역전(Inversion of Control)입니다.
+
+일반적인 코딩 방식에서는 객체 간 의존관계가 존재할 때, 객체 내에서 필요한 객체를 직접 생성합니다.
+
+**기존 코드**
+
+```java
+public class MemberService {
+    // MemberRepository는 interface 라고 가정합니다.
+    private final MemberRepository memberRepository = new MemoryMemberRepository();
+
+    ...
+}
+```
+
+MemberService에서 직접 `MemoryMemberRepository`라는 인스턴스를 생성합니다. 이는 사실 SOLID에서 DIP(Dependency Inversion Principle)를 위반하고 있는 코드입니다.
+
+- **DIP**: 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다."
+
+`MemberRepository`가 interface일 때, MemberService라는 클라이언트는 `new MemoryMemberRepository();`라는 코드로 구체화에 의존하고 있습니다. 이는 `MemberRepository`라는 인터페이스의 구현체를 바꿔야 하는 상황에서 Client Code가 수정되어야 하는 문제를 야기합니다. 즉, `new MemoryMemberRepository();` 코드를 수정해야 하는 것입니다. 이는 SOLID의 OCP(Open/Closed Principle) 위반으로도 이어집니다.
+
+- **OCP**: 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
+
+이를 극복하기 위해 IoC를 적용할 수 있습니다.
+
+**IoC가 적용된 코드**
+
+```java
+public class MemberService {
+    private final MemberRepository memberRepository;
+    
+    public MemberService(MemberRepository memberRepository) {
+        this.memberRepository = memberRepository;
+    }
+    
+    ...
+}
+
+public class AppConfig {
+    public MemberService memberService() {
+        return new MemberService(memberRepository());
+    }
+    
+    public MemberRepository memberRepository() {
+        return new MemoryMemberRepository();
+    }
+}
+```
+
+객체를 생성하고 필요한 의존관계를 설정해주는 작업을 외부 코드에서 제어하게 됩니다. 이렇게 객체를 생성하고 설정하는 작업을 외부에서 하는 것이 바로 IoC입니다. `AppConfig` 클래스에서 객체를 생성하고 관리하는 책임을 담당하며, 기존의 `MemberService`에서 객체를 생성하고 주입하는 책임을 분리함으로써 SRP(Single Responsibility Principle) 개념도 적용된 것입니다.
+
+---
+
+# 프레임워크와 API의 차이
+
+- **프레임워크**: 코드의 실행 흐름이 이미 정해져 있는 프로그램입니다.
+- **API**: 특정 기능을 사용하기 위한 interface입니다.
+
+우리는 Spring Framework의 정해진 동작 흐름에 맞춰서 코드 작업을 해야 합니다. 따라서 Framework를 사용해서 개발할 때는 Framework의 동작 방식을 이해하고 사용하는 것이 중요합니다.
+
+API라는 말은 다양한 곳에서 쓰입니다. 예를 들어, 백엔드 개발 시 API 명세서를 작성할 때, 외부 API를 사용할 때, Java에서 제공하는 기능을 말할 때 등입니다. 이들의 공통점은 개발자가 API가 제공하는 인터페이스를 사용하여 특정 기능을 제공받는다는 것입니다.
+
+- **Framework**: 동작 흐름에 맞춰서 개발해야 함.
+- **API**: 특정 기능을 제공받기 위해 자유롭게 인터페이스를 사용함.
+
+---
+
+# AOP (Aspect-Oriented Programming)
+
+AOP는 관점 지향 프로그래밍입니다. 여러 클래스에서 반복적으로 나타나는 공통적인 기능을 **횡단 관심사**라고 하며, 일반적으로 로깅, 보안, 트랜잭션 관리가 포함됩니다. AOP를 사용하면 이러한 공통 기능을 분리하여 코드의 유지보수성과 재사용성을 높일 수 있습니다.
+
+- **Aspect**: 관심사를 의미합니다. 예: 로깅, 트랜잭션
+- **JoinPoint**: Aspect가 삽입될 수 있는 지점. 예: 메서드 호출, 예외 발생
+- **Pointcut**: JoinPoint 중 Aspect가 적용될 곳을 선정하는 표현식
+- **Advice**: Aspect가 실제로 수행할 작업. 특정 Pointcut에서 실행됩니다.
+    - **Before Advice**: 메서드 실행 전
+    - **After Returning Advice**: 메서드 정상 실행 후
+    - **After Throwing Advice**: 메서드 실행 중 예외 발생 후
+    - **After (Finally) Advice**: 메서드 실행 후 (정상이든 예외든)
+    - **Around Advice**: 메서드 실행 전후, 실행 여부 결정 가능
+- **Weaving**: Aspect를 실제 코드에 적용하는 과정
+
+**AOP의 장점**
+
+- **모듈화**: 횡단 관심사를 Aspect로 분리해 코드의 응집도를 높이고, 특정 기능 변경이나 추가가 쉬워짐.
+- **유지보수성**: 코드가 간결해지고, 핵심 로직과 부가적인 관심사가 분리되어 유지보수가 용이함.
+- **재사용성**: 공통 기능을 재사용해 코드 중복을 줄일 수 있음.
+
+**Spring AOP**
+
+Spring Framework는 주로 **프록시 기반 AOP**를 사용합니다. **@Aspect** 어노테이션을 사용하여 정의합니다.
+
+---
+
+# 서블릿
+
+Servlet는 공식 Java API로, 동적 웹 애플리케이션을 구축하는 데 주요 역할을 합니다. 이러한 Servlet을 편리하게 실행할 수 있는 환경을 제공하는 라이브러리가 Tomcat입니다. 따라서 Tomcat은 Servlet Container라고도 불립니다.
+
+Tomcat은 크게 두 가지 작업을 수행합니다: **catalina**와 **coyote**.
+
+1. **네트워크 요청을 받고 응답**: coyote
+2. **요청을 받아 Servlet을 통해 동적 작업을 실행**: catalina (Servlet Container)
+
+HTTP Protocol 형식에 맞게 요청 메시지를 파싱하고, 응답 메시지를 쉽게 생성하도록 돕는 역할을 하는 것이 Servlet Java API입니다. 이러한 Servlet을 관리하는 Servlet Container가 Tomcat의 catalina입니다.
+
+Tomcat의 **coyote**는 네트워크 요청과 응답을 관리하며, 스레드를 이용해 다수의 클라이언트와 동시에 통신할 수 있는 기능을 제공합니다.
+
+Spring Boot는 Tomcat을 내장하고, Servlet을 상속받은 `DispatcherServlet`을 제공하여 개발자가 편리하게 서버 개발을 할 수 있도록 많은 기능을 제공합니다. `DispatcherServlet`은 Spring Container와 연결되어, 등록된 `Controller` Bean 중 하나를 선택해 동작을 수행합니다.
+
+---
+
+**Servlet Container의 역할**
+
+- HTTP Protocol 형식에 맞춰 요청 메시지를 쉽게 관리
+- `HttpServletRequest`, `HttpServletResponse` 객체 제공
+- Thread Pool을 이용해 다수의 클라이언트 요청 처리
+
diff --git a/keyword/chatper06/keyword.md b/keyword/chatper06/keyword.md
new file mode 100644
index 0000000..1fef61c
--- /dev/null
+++ b/keyword/chatper06/keyword.md
@@ -0,0 +1,21 @@
+### 지연로딩과 즉시로딩의 차이
+
+지연로딩은 위의 설명과 일치합니다. Lazy 옵션을 주어서 실제로 객체의 “필드” 에 접근할 때 그 때 쿼리가 나가는 방식으로 동작합니다. 물론 fetch join을 사용하면 미리 join하여 가져옵니다.
+
+즉시로딩은 연관이 있는 객체를 조회할 때 eager로 설정 되어있는 객체들을 모두 타고 들어가서 전부 join을 한 뒤에 데이터를 가져옵니다. eager 설정은 예상치 못한 쿼리가 돌아갈 가능성이 있기 때문에 일단 lazy로 설정하고 필요할 경우 fetch join을 사용하는 방식이 선호된다고 합니다.
+
+### Fetch Join
+Fetch Join이 바로 N+1 문제를 해결할 수 있는 해결책 중 하나가 되는 것입니다.
+JPQL의 Fetch Join을 사용한다면, 조회할 때 미리 객체들을 join을 해서 가져오기 때문에
+Lazy로 설정을 했더라도 N+1 문제가 발생하지 않습니다.
+
+### @EntityGraph
+Fetch Join과 함께 N+1 문제를 해결할 수 있는 다른 방식입니다.
+
+### JPQL
+JPA의 객체지향 쿼리 언어로 엔터티 객체를 대상으로 작성합니다. SQL로 결국 번역되어 데이터베이스에 쿼리가 보내지게 됩니다. SQL과 다른 점은 엔터티를 대상으로 쿼리를 작성할 수 있는 것입니다.
+
+### QueryDSL
+JPA를 사용하면 동적쿼리를 작성하는데 어려움이 존재합니다. 이를 해결하기 위해서 사용하는 방식이고 Spring 공식스펙은 아니며, 외부 라이브러리입니다. 따라서 처음 사용할 때 설정이 다소 까다로운 면이 있습니다.
+
+Java 코드를 통해서 동적으로 쿼리를 작성할 수 있습니다. 여기서 오는 아주 큰 이점이 있는데 컴파일 시점에 오류를 방지할 수 있다는 것입니다.
\ No newline at end of file
diff --git a/mission/chapter00/mission.md b/mission/chapter00/mission.md
new file mode 100644
index 0000000..66ac3c7
--- /dev/null
+++ b/mission/chapter00/mission.md
@@ -0,0 +1,51 @@
+🔥 **미션**
+---
+- 1번 (너디너리 홈페이지 접속하는 과정 적어보기)
+1. **URL 입력 및 리다이렉트 확인**
+   - 리다이렉트를 확인
+      - 예를 들어 HTTP -> HTTPS 리다이렉트 처리
+2. **캐시 확인**
+   - 브라우저 내 캐싱 가능한 데이터인지 확인한다. 캐싱 불가능 데이터는 요청한다.
+3. **HTTP 요청 메세지 생성**
+   - 현재 예시는 너디너리 홈페이지 접속이기 때문에 GET 요청 메세지 생성
+   - 사용자의 요청에 따라 POST 요청, key value 형태의 쿼리 파라미터 생성 가능
+4. **DNS 조회**
+   - 도메인 이름을 통해서 IP 주소를 가져온다.
+   - DNS 또한 캐싱이 일어날 수 있다. 브라우저 캐싱과 OS 캐싱이 있다.
+5. **TCP 3 way handshake**
+   - 클라이언트 서버 간 연결 확인
+6. **SSL/TLS handshake**
+   - HTTPS 인 경우 수행
+7. **HTTP 요청 메세지 전송**
+   - Internet Layer, Network Interface Layer 순서대로 내려가서 필요 데이터를 추가한다.
+   - IP 라우팅과 ARP 프로세스 등이 발생
+   - 인터넷 망을 통해 요청 데이터가 서버에게 도달된다.
+8. **서버 컴퓨터에게 요청 데이터 도달**
+   - 서버 컴퓨터는 요청 데이터를 아랫 계층에서 윗 계층 순으로 확인
+   - 너디너리 서버 어플리케이션에게 필요한 요청 데이터 전달
+9. **너디너리 서버의 응답 메세지 생성**
+   - 너디너리 서버는 응답 HTTP 데이터를 생성하고, 아래 계층으로 보냄
+   - 각 계층들은 필요한 데이터를 추가
+   - 인터넷 망으로 보내짐
+10. **클라이언트에게 응답 데이터 도달**
+   - 최하위 계층부터 위 계층 순으로 필요한 데이터를 추출하고 웹 브라우저는 HTTP 응답 메세지 확인
+11. **브라우저 렌더링**
+   - 혹시 필요한 추가 데이터가 있다면 추가 요청을 보냄.
+   - HTTP/1.1 기준으로 연결을 끊지 않고(keep-alive), 이미지, JS, CSS를 추가 요청
+
+
+**캐싱이란?**
+- 크게 브라우저캐시와 공유캐시로 나뉜다.
+
+1. 브라우저 캐시
+   - 쿠키, 로컬스토리지 등을 포함한 캐시(private cache)
+   - 브라우저 자체가 사용자를 위해 가지고 있는 데이터를 의미한다.
+2. 공유 캐시
+   - 클라이언트와 서버 사이에 사용자 간 공유할 수 있는 응답을 저장
+   - 대표적 예로는 프록시 서버가 캐싱하는 것
+      - 리버스 프록시를 둬서 내부서버로 포워드 한다고 호칭
+   - CDN 서버를 둬서 캐싱 가능
+
+---
+- 2번
+  <img width="1016" alt="스크린샷 2024-09-16 오후 6 00 33(2)" src="https://github.com/user-attachments/assets/ae8b4f0b-9db8-4846-8c38-7323de0d559f">
\ No newline at end of file
diff --git a/mission/chapter02/java_mission.md b/mission/chapter02/java_mission.md
new file mode 100644
index 0000000..9b73e11
--- /dev/null
+++ b/mission/chapter02/java_mission.md
@@ -0,0 +1,82 @@
+# 추가과제
+
+### 1. Static, JVM Memory, ClassLoader
+
+### JVM Memory
+
+**JVM memory** 구조는 **메서드 영역, 스택 영역, 힙 영역**으로 구성된다.
+
+- **메서드 영역**
+    - 프로그램을 실행하는데 필요한 공통 데이터를 관리한다. 프로그램의 모든 영역에서 공유한다.
+        - 클래스 정보 : 클래스의 실행코드(바이트 코드), 필드, 메서드, 생성자 코드 등 모든 실행코드가 존재
+        - static 영역 : static 변수들을 보관한다.
+        - 런타임 상수 풀 : 공통 리터럴 상수를 보관한다. 프로그램을 효율적으로 관리하기 위한 상수들과 리터럴 문자가 있으면 공통으로 묶어서 관리한다.
+- **스택 영역**
+    - 실제 프로그램이 실행되는 영역이다. 메서드를 실행할 때마다 하나씩 스택 영역에 쌓이게 된다.
+    - 자바 실행 시, 하나의 실행 스택이 생성된다. 각 스택 프레임은 지역 변수, 중간 연산 결과, 메서드 호출 정보 등을 포함한다.
+    - 스택 영역은 각 스레드 별로 하나의 실행 스택이 생성된다. 따라서 스레드 수 만큼 스택 영역이 생성된다.
+- **힙 영역**
+    - 객체(인스턴스)가 생성되는 영역이다. new 명령어를 사용하면 이 영역에 존재하게 된다. 배열도 이 영역에 생성된다.
+
+### static
+
+**static 변수**
+
+- **클래스 공용 변수**
+    - 클래스에서 공용으로 사용되는 변수
+
+      **참고:**  인스턴스 변수(heap 영역), 지역변수(stack 영역)
+
+
+**static method**
+
+- 인스턴스 생성 없이 바로 메소드를 호출해서 사용 가능하다.
+- 정적 메소드 내부에서는 인스턴스 변수에 접근 불가능하다.
+    - 정적 메서드는 참조 값의 개념이 없다. 특정 인스턴스의 기능을 사용하려면 참조 값을 알아야 하는데, 정적 메서드는 참조값 없이 호출한다. 따라서 정적 메서드 내부에서 인스턴스 변수나 인스턴스 메서드를 사용할 수 없다.
+- 유틸리티성 메소드에서 많이 활용된다.
+
+### ClassLoader
+
+클래스 로더는 클래스 파일을 메모리에 로드하는 역할을 하며, 이 과정에서 static 요소도 함께 Method 영역에 할당된다.
+
+static 맴버는 클래스 로더가 해당 클래스를 로드한 후 초기화 되기 때문에, 클래스 로딩 시점와 static 초기화 시점은 밀접한 관계가 있다.
+
+### 2. Collection interface
+
+컬렉션 프레임워크는 객체를 저장하고 처리하기 위해 사용된다.
+
+Collection Interface가 최상단에 존재하기 때문에 이를 구현한 다양한 컬렉션들은 기본적으로 공통적인 메소드를 제공한다. 또한 다형성을 사용하여, 다양한 컬렉션 타입들을 같은 타입으로 다룰 수 있다.
+
+add, remove, size, isEmpty, contains, iterator, clear와 같은 메소드가 collection 인터페이스에 제공된다.
+
+주의할 점은 Map은 Collection 인터페이스가 아니다. 그러나, keyset()과 같은 메소드를 호출하여 Collection의 기능을 사용가능하다.
+
+### **컬렉션이 제공하는 인터페이스**
+
+- Collection
+    - 루트 인터페이스로 메소드를 제공한다. 대부분의 컬렉션 클래스가 이 인터페이스를 상속받는다.
+- List
+    - 순서가 있어, 인덱스를 통해 접근 가능. 중복 허용
+- Set
+    - 중복 요소를 허용하지 않는다. 인덱스를 통해 접근 불가하다.
+- Queue
+    - 주로 요소가 처리되기 전에 보관하는 컬렉션이다.
+- Map
+    - 키와 쌍으로 요소를 저장하고, Collection 인터페이스를 상속받지 않는다.
+
+### 구현체
+
+- List
+    - ArrayList → 내부적으로 배열을 사용한다.
+    - LinkedList → 연결 리스트를 사용한다.
+- Set
+    - HashSet → 해시 테이블
+    - LinkedHashSet → 해시 테이블과 연결 리스트
+    - TreeSet → 레드-블랙트리
+- Queue
+    - LinkedList → 연결 리스트
+    - ArrayDeque → 배열 기반의 원형 큐
+- Map
+    - HashMap → 해시 테이블
+    - LinkedHashMap → 해시 테이블 + 연결 리스트
+    - TreeMap → 레드-블랙트리
\ No newline at end of file
diff --git a/mission/chapter02/misson.md b/mission/chapter02/misson.md
new file mode 100644
index 0000000..f154f5c
--- /dev/null
+++ b/mission/chapter02/misson.md
@@ -0,0 +1,90 @@
+## 1
+
+```sql
+SELECT 
+    r.name AS restaurant_name,
+    m.content AS mission_content,
+    mm.status AS mission_status,
+    m.point
+FROM 
+    member_mission mm
+JOIN 
+    mission m ON mm.id2 = m.id
+JOIN 
+    restaurant r ON m.id2 = r.id
+WHERE 
+    mm.member_id = (사용자의 id)
+ORDER BY 
+    mm.updated_at DESC
+LIMIT ? OFFSET ?;
+```
+
+## 2 
+```sql
+INSERT INTO review (
+    restaurant_id, 
+    member_id, // erd에 누락되었지만, 있어야 할 것 같음
+    score, 
+    content, 
+    created_at, 
+    updated_at
+) VALUES (
+    (가게의 ID),
+    (사용자의 ID),
+    (리뷰 점수),
+    (리뷰 내용),
+    NOW(),
+    NOW()
+);
+
+```
+## 3
+```sql
+// 선택한 지역 내에서 성공한 미션 개수
+
+SELECT 
+    COUNT(*)
+FROM 
+    member_mission mm
+JOIN 
+    mission m ON mm.id2 = m.id
+JOIN 
+    restaurant r ON m.id2 = r.id
+WHERE 
+    r.address = (지역의 이름)
+    AND mm.member_id = (회원의 id)
+    AND mm.status = '완료';
+    
+
+// (현재 선택 된 지역에서 도전이 가능한 미션 목록, 페이징 포함)
+
+SELECT 
+    r.name AS restaurant_name,
+    r.type AS restaurant_type,
+    m.content AS mission_content
+FROM 
+    restaurant r
+JOIN 
+    mission m ON r.id = m.id2
+LEFT JOIN 
+    member_mission mm ON m.id = mm.id2 AND mm.status != '완료'
+WHERE 
+    r.address = (지역의 이름)
+ORDER BY 
+    m.created_at DESC
+LIMIT ? OFFSET ?;
+
+```
+
+## 4
+```sql
+SELECT 
+    m.name,
+    m.email,
+    m.phone_number,
+    m.point
+FROM 
+    member m
+WHERE 
+    m.id = (memberId);
+```
\ No newline at end of file
diff --git a/mission/chaptor01/java_mission.md b/mission/chaptor01/java_mission.md
new file mode 100644
index 0000000..a27a0c2
--- /dev/null
+++ b/mission/chaptor01/java_mission.md
@@ -0,0 +1,125 @@
+ 🔥 추가미션
+---
+### 자바의 접근 제어자 4가지
+- **public**
+    - 모든 파일에서 접근 허용
+- **protected**
+    - 같은 패키지에서 접근 허용
+    - 상속받은 클래스에서 접근 허용
+- **default(package-private)**
+    - 접근 제어자를 명시하지 않으면 default
+    - 같은 패키지에서 접근 허용
+- **private**
+    - 클래스 내에서만 접근 가능
+
+
+**protected 사용 예시**
+```java
+
+@SuperBuilder
+@NoArgsConstructor(access = PROTECTED)
+public abstract class AdditionalInfo {
+
+    @JsonProperty("추가정보")
+    @Builder.Default
+    protected Map<String, Object> addtionalInfoMap = new HashMap<>();
+
+    public Optional<Object> getAdditionalInfo(String key) {
+        return Optional.ofNullable(addtionalInfoMap.get(key));
+    }
+}
+
+@SuperBuilder
+@NoArgsConstructor(access = PROTECTED)
+@ToString
+public class CurriculumCode extends AdditionalInfo {
+
+    @JsonProperty("교과과정")
+    @Builder.Default
+    private Map<Category, Set<String>> codeMap = new HashMap<>();
+
+...
+}
+
+```
+
+
+---
+### 클래스와 인터페이스
+
+- **클래스**
+    - 인스턴스 객체의 설계도
+    - 필드, 메소드를 정의
+    - 상속을 통해 확장 가능
+
+> 참고: 추상클래스
+> 추상클래스는 해당 클래스를 인스턴스화 할 수 없으며, 반드시 상속 받은 클래스만 인스턴스화 가능하다.
+
+- **인터페이스**
+    - 구현되지 않은 메소드들의 집합
+    - 메소드의 접근제어자는 자동으로 public
+    - 다중 상속 지원
+
+> 참고: 인터페이스는 ‘**default 메소드**’ 구현 가능
+>
+> Java의 Function package -> 추상 메소드 하나와 default 메소드를 가지고 있는 인터페이스
+> 객체화된 함수형 인터페이스에 default 메소드가 존재하여 추가 기능을 제공한다.
+
+---
+### 상속
+- 상위 클래스의 필드, 메소드들을 물려받을 수 있음
+- 확장성, 코드의 재사용성, 다형성 제공
+- 클래스는 다중 상속이 불가능
+- 인터페이스는 다중 상속이 가능
+- 상위 클래스의 필드, 메소드에 접근할 때 **super** 가 사용된다. 특히 생성자 호출 시 사용된다.
+
+
+---
+### 면접 예상 질문
+
+**Q. protected 접근 제어자를 사용할 때 어떤 상황에서 유용할까요?**
+- 상속 시, 하위 클래스에서 상위 클래스의 필드, 메소드에 접근가능 하도록 할 때 유용합니다.
+
+
+**Q. 자바에서 다중 상속을 직접 지원하지 않는 이유는 무엇인가요?**
+
+- **다이아몬드 문제**가 발생 가능합니다.
+- 두 부모 클래스가 동일한 메소드를 가지고 있고, 하위 클래스가 두 부모 클래스를 모두 상속 받으면, 어떤 부모의 메소드를 상속받을 지 모호해집니다.
+
+**다이아몬드**
+```
+       A
+     /   \
+    B     C
+     \   /
+       D
+
+```
+
+상위클래스 A를 상속받는 B,C가 있고, B,C를 상속받는 D가 있다고 가정합니다.
+D 클래스는 A 클래스의 메소드를 두 번 상속받아 B와 C중 어떤 것을 상속받아야 할 지 곤란해집니다.
+
+java interface는 **super** 키워드를 통해서 어떤 부모 클래스의 메소드를 상속받을 지 선택가능합니다.
+
+```java
+interface A {
+    default void method() {
+	...
+    }
+}
+
+interface B extends A {
+}
+
+interface C extends A {
+}
+
+class D implements B, C {
+
+    @Override
+    public void method() {
+        B.super.method();
+    }
+}
+
+```
\ No newline at end of file
diff --git a/mission/chaptor01/mission.md b/mission/chaptor01/mission.md
new file mode 100644
index 0000000..e1c2931
--- /dev/null
+++ b/mission/chaptor01/mission.md
@@ -0,0 +1,3 @@
+🔥 **미션**
+---
+![KakaoTalk_Photo_2024-09-27-14-48-50](https://github.com/user-attachments/assets/b8cb3acd-51b2-4519-99f8-6223fa3ae491)
diff --git a/mission/chaptor03/java_mission.md b/mission/chaptor03/java_mission.md
new file mode 100644
index 0000000..6c2eda2
--- /dev/null
+++ b/mission/chaptor03/java_mission.md
@@ -0,0 +1,410 @@
+# ✚ 추가미션
+
+## **1. 제네릭과 와일드카드**
+
+### 제네릭이 필요한 이유
+
+중복코드를 제거하기 위해서, 다형성을 통해 중복 해결을 시도할 수 있다.
+```java
+ public class ObjectBox {
+     private Object value;
+     public void set(Object object) {
+         this.value = object;
+	} 
+     public Object get() {
+         return value;
+	} 
+} 
+```
+
+- 위와 같은 코드는 **타입 안정성**이 매우 떨어지게 된다.
+- 실제 데이터를 ObjectBox에 담고 이를 가져오면 리턴타입은 Object 여서 이를 다운캐스팅을 통해서 사용해야 한다.
+- 매개변수도 Object 이기 때문에 컴파일 타임에 어떤 값이 들어오더라도 컴파일 에러가 발생하지 않는다.
+
+
+### 제네릭 적용
+
+```java
+ public class GenericBox<T> {
+     private T value;
+     public void set(T value) {
+         this.value = value;
+	}	 
+     public T get() {
+         return value;
+	} 
+} 
+```
+
+- T라는 타입 매개 변수를 지정해서 객체를 생성하게 되면, 컴파일 타임에 타입 안정성 보장이 가능하다.
+  우리는 제네릭을 통해서 **코드 재사용과 타입 안정성** 두 마리 토끼를 잡을 수 있다.
+- **제네릭을 통해서 사용할 타입에 대한 결정을 나중으로 미루는 것이다.**
+
+
+**제네릭 타입을 지정하지 않을 경우**
+```java
+GenericBox integerBox = new GenericBox(); // 비추천
+
+GenericBox<Object> integerBox = new GenericBox<>(); // 동일한 코드
+```
+- 제네릭 타입을 지정하지 않고 사용가능하긴 하지만, 추천하지 않는다.
+
+
+
+### 타입 추론
+
+- 제네릭 타입
+```java
+GenericBox<Integer> integerBox = new GenericBox<Integer>() // 타입 직접 입력 GenericBox<Integer> integerBox2 = new GenericBox<>() // 타입 추론 
+
+```
+- 제네릭 메서드
+```java
+Integer i = 10;
+
+Integer result = GenericMethod.<Integer>genericMethod(i); // 타입 직접 입력
+Integer result2 = GenericMethod.genericMethod(i); // 타입 추론
+
+```
+
+
+### 타입 매개변수 상한 제한
+```java
+public class AnimalHospitalV2<T> {
+
+     private T animal;
+
+     public void set(T animal) {
+         this.animal = animal;
+	}
+ 
+	public void checkup() {
		// T의 타입을 메서드를 정의하는 시점에는 알 수 없다. Object의 기능만 사용 가능	

		System.out.println("동물 이름: " + animal.getName()); // 컴파일 오류
+		animal.sound(); // 컴파일 오류
+	}
+ 
+	public T getBigger(T target) { 
+		// 컴파일 오류 
+		return animal.getSize() > target.getSize() ? animal : target;
+    }
+} 
+
+```
+
+위와 같은 제네릭 클래스를 만들면, `Animal` 이라는 클래스의 `getName`, `sound`, `getSize` 와 같은 기능들은 사용하지 못한다. 실제 객체가 생성될 때, 어떤 타입 인자가 들어올지 모르기 때문이다.
+
+
+따라서 우리는 `extends` 를 통해 **타입 매개변수의 상한선을 지정**한다.
+```java
+ public class AnimalHospitalV3<T extends Animal> {
+
+...
+```
+
+이를 통해, 타입 인자로 들어오는 객체는 Animal의 기능을 가지고 있다는 보장이 생기기 때문에 Animal이 제공하는 기능들을 사용 가능하다.
+
+
+### 제네릭 메서드
+```java
+     public static <T> T genericMethod(T t) {
+         System.out.println("generic print: " + t);
+         return t;
+	}
+ 
+     public static <T extends Number> T numberMethod(T t) {
+         System.out.println("bound print: " + t);
+         return t;
+	} 
+
+```
+
+제네릭 타입과 제네릭 메서드는 별개의 기능이다. 하지만 함께 사용은 가능하다.
+
+**제네릭 메서드의 특징**
+- 제네릭 메서드는 메서드 내에서 제네릭을 도입할 때 사용한다.
+- 리턴 타입 왼쪽에 제네릭 타입을 명시한다.
+- static 메소드를 제네릭 메소드로 만들 때, (클래스)제네릭 타입과 호환 불가능하다.
+    - 왜냐하면, 실제 제네릭 클래스가 생성되기 전까지는 (클래스)제네릭 타입에 어떤 타입이 들어올 지 모르기 때문이다.
+- 인스턴스 메서드는 (클래스)제네릭 타입과 호환 가능하다. 우선순위는 인스턴스 메서드가 먼저 가져간다. 그러나 혼동을 줄이기 위해 중복해서 사용하지 않도록 하자.
+- 제네릭 메서드도 동일하게 `extends` 로 상한을 지정가능하다.
+    - 상한을 지정하면 지정한 클래스의 기능을 사용가능하다.
+
+
+
+### 와일드 카드
+
+- 제네릭 타입을 조금 더 편리하게 사용할 수 있도록 제공하는 기능이다.
+- `?` 을 통해서 정의한다.
+- 동일하게 상한선 지정이 가능하다.
+- 와일드카드는 하한선 지정도 가능하다.
+
+**제네릭 메서드 vs 와일드 카드**
+```java
+    static <T> void printGenericV1(Box<T> box) {
+        System.out.println("T = " + box.get());
+	} 
+
+    static void printWildcardV1(Box<?> box) {
+        System.out.println("? = " + box.get());
+	} 
+
+	// 상한선 지정
+   	static <T extends Animal> T printAndReturnGeneric(Box<T> box) {
+        T t = box.get();
+		System.out.println("이름 = " + t.getName()); 
+		return t; 
+	} 
+
+	// 상한선 지정
+    static Animal printAndReturnWildcard(Box<? extends Animal> box) {
+        Animal animal = box.get();
+		System.out.println("이름 = " + animal.getName()); 
+        return animal;
+    }
+} 
+
+```
+
+**와일드 카드는 제네릭 타입이나, 제네릭 메서드를 선언하는 것이 아니다. 와일드 카드는 이미 만들어진 제네릭 타입을 활용할 때 사용한다.**
+
+그렇다면 와일드 카드, 제네릭 메소드 중 무엇을 써야할까? 보통 단순한 와일드 카드를 사용하되, 제네릭 메서드가 필요한 경우가 있다. 이럴 땐 제네릭 메서드를 써야한다.
+
+**타입 매개변수가 꼭 필요한 경우**
+```java
+ static <T extends Animal> T printAndReturnGeneric(Box<T> box) {
+     T t = box.get();
+	System.out.println("이름 = " + t.getName()); 
+	return t; 
+} 
+
+static Animal printAndReturnWildcard(Box<? extends Animal> box) { 
+	Animal animal = box.get();
	System.out.println("이름 = " + animal.getName());
	return animal; 
+} 
+
+...
+
+Dog dog = WildcardEx.printAndReturnGeneric(dogBox) 
+
+Animal animal = WildcardEx.printAndReturnWildcard(dogBox) 
+
+```
+
+와일드 카드는 리턴타입을 명확하게 지정할 수 없는 반면, 제네릭 메서드는 명확한 타입을 리턴할 수 있다.
+
+
+## 하한 와일드 카드
+```java
+ public class WildcardMain2 {
+     public static void main(String[] args) {
+         Box<Object> objBox = new Box<>();
+         Box<Animal> animalBox = new Box<>();
+         Box<Dog> dogBox = new Box<>();
+         Box<Cat> catBox = new Box<>();
+
+		// Animal 포함 상위 타입 전달 가능 
+		 writeBox(objBox); 
+		 writeBox(animalBox); 
+		 writeBox(dogBox); // 컴파일 에러, 하한이 Animal 
+		 writeBox(catBox); // 컴파일 에러, 하한이 Animal 
+
+         Animal animal = animalBox.get();
+         System.out.println("animal = " + animal);
+     }
+
+	static void writeBox(Box<? super Animal> box) {
+		  box.set(new Dog("멍멍이", 100)); 
+	} 
+} 
+
+```
+
+- 하한을 Animal로 제한했기 때문에, Animal의 하위 타입인 Dog, Cat은 전달할 수 없다.
+
+
+### 타입 이레이저
+
+제네릭은 자바 컴파일 단계에서만 사용되고, 컴파일 이후에는 제네릭 정보가 삭제된다. 컴파일 전인 `.java`
+에는 제네릭의 타입 매개변수가 존재하지만, 컴파일 이후인 자바 바이트코드 `.class`에는 타입 매개변수가 존재하지 않는 것이다.
+
+**컴파일 전**
+```java
+ public class GenericBox<T> {
+
+     private T value;
+
+     public void set(T value) {
+         this.value = value;
+	}
+ 
+     public T get() {
+         return value;
+	} 
+} 
+
+```
+
+**컴파일 이후**
+```java
+ public class GenericBox {
+
+     private Object value;
+
+     public void set(Object value) {
+         this.value = value;
+	} 
+
+     public Object get() {
+         return value;
+} 
+
+```
+- 컴파일 이후에는 T가 Object 타입으로 대체된다.
+- 상한 제한이 있을 경우, T가 명시한 상한으로 대체된다.
+
+
+```java
+Integer result = (Integer) box.get(); //컴파일러가 캐스팅 추가 
+```
+
+- 그리고 실제로 이를 생성한 클래스에서는 지정한 타입으로 캐스팅한 코드를 추가해준다.
+- 자바 컴파일러는 컴파일 시점에 제네릭을 사용한 코드에 문제가 없는지 검증을 하기 때문에 문제가 발생하지 않는다.
+- 런타임 시에는 제네릭 정보가 지워지는 것을 타입 이레이저라고 한다.
+
+### 타입 이레이저 방식의 한계
+자바는 자바 아래버전과 호환성을 위해서 제네릭을 타입 이레이저 방식으로 지원한다. 이에 따라서 발생하는 한계점이 존재한다.
+
+```java
+ class EraserBox<T> {
+
+	public boolean instanceCheck(Object param) { 
+		return param instanceof T; // 오류 
+	}
+ 
+	public void create() { 
+		return new T(); // 오류 
+	} 
+} 
+
+```
+
+- `instance of T` 는 결국 런타임에는 `instance of Object`로 바뀌어버리기 때문에 모든 값이 true로 반환되어 버린다. 따라서 instance of 를 허용하지 않는다.
+- `new T()` 는 결국 런타임에는 `new Object()` 로 바뀌어버리기 때문에 개발자가 의도한 바와 달라서 `new`를 허용하지 않는다.
+
+
+----
+## **2. 래퍼 클래스**
+
+### 기본형의 한계
+자바는 객체 지향 언어이다. 자바에는 객체가 아닌 기본형이 존재하는데, 기본형에는 한계가 존재한다.
+- **객체가 아님**
+    - 메서드를 제공하지 못한다.
+    - 객체 참조가 필요한 컬렉션 프레임워크, 제네릭을 사용하지 못한다.
+- **null 값을 가질 수 없음**
+    - 때로는 데이터가 없는 상태를 표현하고 싶지만 이를 표현하지 못한다.
+
+### 래퍼 클래스의 특징
+- 기본형의 객체 버전
+- 불변
+- equals로 비교해야함
+
+int, Integer를 예시로 들어 설명한다.
+
+**래퍼 클래스 생성 - 박싱(Boxing)**
+```java
+Integer i = Integer.valueof(10);
+```
+- 최적화: 개발자들이 일반적으로 자주 사용되는 -128 ~ 127 범위의 Integer 클래스를 미리 생성해두고, 해당 범위의 값을 조회하면 미리 생성된 Integer 객체를 반환한다.
+    - 마치 문자열 풀과 비슷하게 자주 사용되는 숫자를 미리 생성하고 재사용한다.
+
+**언박싱(UnBoxing)**
+```java
+Integer i = Integer.valueof(10);
+int unBoxedInt = i.intValue();
+```
+
+
+**비교는 equals() 사용**
+- 래퍼 클래스는 객체이기 때문에 == 비교를 하면 인스턴스의 참조값을 비교
+- 래퍼 클래스는 객체 내부의 값을 비교하도록 equals()를 재정의해두었다. 값 비교를 위해서는 equals()를 사용해야 한다.
+
+
+### 오토 박싱, 언박싱
+- 자바 1.5부터 오토 박싱, 오토 언박싱을 지원한다.
+```java
+int value = 7;
+Integer boxedValue = value // 오토 박싱
+
+int unboxedValue = boxedValue // 오토 언박싱
+```
+- 컴파일러가 valueOf, xxxValue() 등의 코드를 추가해주는 기능이다.
+
+
+### 래퍼 클래스의 주요 메서드
+
+- `valueOf()` : 래퍼 타입을 반환한다. 숫자, 문자열을 모두 지원한다.
+- `parseInt()` : 문자열을 기본형으로 변환한다.
+- `compareTo()` : 값 비교를 지원한다. 내 값이 크면 1, 같으면 0, 내 값이 작으면 -1
+- `sum(), min(), max()` : 간단한 덧셈, 작은 값, 큰 값을 비교하는 static 메소드를 지원
+
+
+### 래퍼 클래스와 성능
+래퍼 클래스가 기본형보다 좋은 것 같은데, 굳이 기본형이 존재하는 이유는?
+성능차이를 비교해보자.
+
+```java
+// 기본형
+int iterations = 1_000_000_000;
+long sumPrimitive = 0;
+for(int i = 0; i < iterations; i++) {
+	sumPrimitive += i;
+}
+
+// 래퍼 클래스
+Long sumWrapper = 0L;
+for(int i = 0; i < iterations; i++) {
+	sumPrimitive += i; // 오토 박싱 박생
+}
+
+```
+
+- 이 둘의 성능차이를 비교해보면, 시스템마다 다르겠지만 기본형 계산이 5배 정도 빠르다.
+- 래퍼 클래스는 객체이기 때문에 객체 메타데이터를 포함한다. 따라서 메모리를 추가로 사용한다.
+
+사실 그렇게 유의미한 차이는 아니지만, CPU 연산을 아주 많이 수행하는 특수한 상황에는 기본형을 고려해보자. 일반적인 경우는 유지보수하기 더 나은 것을 선택하자.
+
+
+---
+## **3. Optional**
+
+> **공식 API 문서 : Optional을 만든 의도**
+>
+> 메소드가 반환할 결과 값이 '없음'을 명백하게 표현할 필요가 있고, **null을 반환하면 에러가 발생할 가능성이 높은 상황에서 메소드의 반환 타입으로 Optional을 사용하자**는 것이 Optional을 만든 주된 목적이다.
+
+
+### Optional 올바르게 사용하기
+
+- `Optional`에 절대 `null`을 할당하지 않는다. 비어있다면 `Optional.empty()`를 사용
+- `Optional.get()` 호출전에 반드시 객체가 값이 있는지 확인할 것
+- 값이 없는 경우, `orElse()`를 통해 디폴트 값을 설정할 수 있다.
+    - 주의할 점으로는 `orElse()`의 괄호 안에서 새로운 값을 생성하지 말자. 왜냐하면 이 코드는 항상 실행되기 때문에 값이 있는 상황에도 의미없는 객체가 계속 생성될 수 있다.
+- `orElseGet(Supplier)` 는 `Optional`의 값이 없을 때만 실행된다. 따라서 새로운 값을 생성해도 된다.
+- 값이 없는 경우, `orElseThrow()`를 통해서 예외를 던질 수 있따.
+- `ifPresent()` : 값이 있는 경우에 이를 사용하고, 없는 경우에 아무 동작도 수행하지 않을 경우
+- `Optional`을 필드 타입으로 사용하지 말자.
+    - **`Optional`은 반환 타입을 위해 설계된 타입**이다.
+    - 클래스의 필드, 혹은 메소드의 인자로 사용하는 것은 `Optional` 도입 의도에 반하는 패턴
+- 단지 값을 얻을 목적이라면 `Optional` 대신 `null` 비교를 하자.
+    - `Optional`은 비싼 연산이기 때문에 과도하게 사용하지 말아야 한다. 단순값 혹은 `null`을 얻을 목적이라면 `Optinoal` 대신 `null` 비교로도 충분하다.
+- `Optinoal`을 빈 컬렉션이나 배열을 반환하는데 사용하지 말 것
+    - 값이 없는 경우는 비어있는 컬렉션과 배열을 반환하면 된다.
+- `Optional`을 컬렉션의 원소로 사용하지 말 것
+    - 특히 `Map`과 같은 경우 `getOrDefault()` 와 같은 메소드로 `null` 방지를 충분히 할 수 있다.
+- `Optional.of()`는 null이 아닌게 확실할 때, `Optinal.ofNullable()`은 `null`일 가능성이 있을 때 사용
+- 내부 값 비교 시, `Optional.equals` 사용 고려
+    - 내부 값 비교 가능하도록 이미 구현이 되어있다. 따라서 굳이 꺼내서 비교할 필요 없음
+- 값에 대해 미리 정의된 규칙이 있는 경우 `filter` 사용 고려
+    - `stream` 처럼 필터를 제공하여 내부에 사용자가 구현한 함수를 사용가능하다.
+
+출처:
+1. ****김영한의 실전 자바 중급 1편 - 자바의 다양한 중급 기능****
+2. https://dev-coco.tistory.com/178
+
diff --git a/mission/chaptor03/mission.md b/mission/chaptor03/mission.md
new file mode 100644
index 0000000..ca8012a
--- /dev/null
+++ b/mission/chaptor03/mission.md
@@ -0,0 +1,167 @@
+**1. 홈 화면**  
+**GET /api/v1/home**
+* **설명**: 홈 화면을 조회합니다.
+* **URL**: /api/v1/home
+* **Method**: GET
+* **요청 헤더**:
+    * Authorization: token
+* **응답**
+```javascript
+{
+  "isSuccess": true,
+  "code": "COMMON200",
+  "message": "성공",
+  "result": {
+    "completedMissionCount": 7,
+    "missions": [
+      {
+        "restaurantName": "식당이름",
+        "restaurantCategory": "중식",
+        "missionExpirationDate": "2024-12-31",
+        "missionDescription": 10000,
+        "points": 500
+      },
+      {
+        "restaurantName": "식당이름",
+        "restaurantCategory": "중식",
+        "missionExpirationDate": "2024-12-31",
+        "missionDescription": 10000,
+        "points": 500
+      },
+    ]
+  }
+}
+
+```
+<br></br>
+**2. 마이 페이지 리뷰 작성**  
+**POST /api/v1/my-page/reviews**
+* **설명**: 마이 페이지 리뷰를 작성합니다.
+* **URL**:  /api/v1/my-page/reviews
+* **Method**: POST
+* **요청 헤더**:
+    * Authorization: token
+- **요청 BODY**:
+```javascript
+{
+  "missionId": 1,
+  "restaurantId" : 1
+  "rating": 5,
+  "content": "내용"
+}
+
+```
+* **응답**
+```javascript
+{
+  "isSuccess": true,
+  "code": "COMMON200",
+  "message": "성공",
+  "result": {
+    "reviewId": 1
+  }
+}
+
+```
+<br></br>
+**3. 미션 목록 조회(진행중, 진행 완료)**  
+**GET /api/v1/missions**
+* **설명**: 미션 목록을 조회합니다.
+* **URL**: /api/v1/missions
+* **Method**: GET
+* **요청 헤더**:
+    * Authorization: token
+- **요청 쿼리 파라미터:**
+    - status : progress or completed
+- **요청 BODY**:
+```javascript
+{
+  "regionName": "안암동"
+}
+```
+* **응답**
+```javascript
+{
+  "isSuccess": true,
+  "code": "COMMON200",
+  "message": "성공",
+  "result": {
+    "missions": [
+      {
+        "restaurantId": 1,
+        "restaurantName": "식당이름",
+        "restaurantCategory": "한식",
+        "missionPoints": 500
+      },
+      {
+        "restaurantId": 2,
+        "restaurantName": "식당이름",
+        "restaurantCategory": "양식",
+        "missionPoints": 500
+      }
+    ]
+  }
+}
+
+
+```
+<br></br>
+**4. 미션 성공 누르기**  
+**POST /api/v1/missions/{mission-id}/completed**
+* **설명**: 특정 미션의 성공 후 사장님께 요청합니다.
+* **URL**: /api/v1/missions/{mission-id}/completed
+* **Method**: POST
+* **요청 헤더**:
+    * Authorization: token
+* **응답**
+```javascript
+{
+  "isSuccess": true,
+  "code": "COMMON200",
+  "message": "성공",
+  "result": {
+    "missionId": 1,
+    "bossAuthCode": "9201982309"
+  }
+}
+```
+<br></br>
+**5. 회원 가입 하기(소셜 로그인 고려 X)**  
+**POST /api/v1/users/sign-up**
+* **설명**: 회원 가입 하기
+* **URL**: /api/v1/users/sign-up
+* **Method**: POST
+* **요청 BODY**
+```javascript
+{
+  "name": "홍길동",
+  "gender": "남자",
+  "birthYear": 2000,
+  "birthMonth": 1,
+  "birthDay": 1,
+  "address": "인천광역시 OO구 OO길 OO",
+  "detailedAddress": "OOO호",
+  "preferredFoodCategories": ["한식", "양식", "일식"]
+}
+```
+- **응답 BODY**
+```javascript
+{
+  "isSuccess": true,
+  "code": "COMMON200",
+  "message": "성공",
+  "result": {}
+}
+```
+<br></br>
+**6. 에러**
+- **설명:** 에러 응답 형식을 설명
+- **응답 BODY**
+```javascript
+{
+  "isSuccess": false,
+  "code": "COMMON500",
+  "message": "서버 에러, 관리자에게 문의 바랍니다.",
+  "result": null
+}
+```
diff --git a/mission/chaptor04/code/functionalinterface/anonymousclass/Converter.java b/mission/chaptor04/code/functionalinterface/anonymousclass/Converter.java
new file mode 100644
index 0000000..4dac5b1
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/anonymousclass/Converter.java
@@ -0,0 +1,10 @@
+package functionalinterface.anonymousclass;
+
+import java.util.function.Function;
+
+public interface Converter extends Function<Integer, String> {
+
+    @Override
+    String apply(Integer t);
+
+}
\ No newline at end of file
diff --git a/mission/chaptor04/code/functionalinterface/anonymousclass/Main.java b/mission/chaptor04/code/functionalinterface/anonymousclass/Main.java
new file mode 100644
index 0000000..517420e
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/anonymousclass/Main.java
@@ -0,0 +1,25 @@
+package functionalinterface.anonymousclass;
+
+public class Main {
+
+    public static void main(String[] args) {
+        // given
+        Integer value = 3;
+        String expected = "3";
+
+        Converter converter = new Converter() {
+            @Override
+            public String apply(Integer value) {
+                return String.valueOf(value);
+            }
+        };
+
+        // when
+        String result = converter.apply(value);
+
+        // then
+        boolean output = result.equals(expected);
+        System.out.println("output = " + output);
+    }
+
+}
diff --git a/mission/chaptor04/code/functionalinterface/inheritance/Converter.java b/mission/chaptor04/code/functionalinterface/inheritance/Converter.java
new file mode 100644
index 0000000..32e3415
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/inheritance/Converter.java
@@ -0,0 +1,12 @@
+package functionalinterface.inheritance;
+
+import java.util.function.Function;
+
+public class Converter implements Function<Integer, String> {
+
+    @Override
+    public String apply(Integer t) {
+        return String.valueOf(t);
+    }
+
+}
\ No newline at end of file
diff --git a/mission/chaptor04/code/functionalinterface/inheritance/Main.java b/mission/chaptor04/code/functionalinterface/inheritance/Main.java
new file mode 100644
index 0000000..3511b2f
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/inheritance/Main.java
@@ -0,0 +1,22 @@
+package inheritanceclass;
+
+import functionalinterface.inheritance.Converter;
+
+public class Main {
+
+    public static void main(String[] args) {
+        // given
+        Integer value = 3;
+        String expected = "3";
+
+        Converter converter = new Converter();
+
+        // when
+        String result = converter.apply(value);
+
+        // then
+        boolean output = result.equals(expected);
+        System.out.println("output = " + output);
+    }
+
+}
diff --git a/mission/chaptor04/code/functionalinterface/lamda/Converter.java b/mission/chaptor04/code/functionalinterface/lamda/Converter.java
new file mode 100644
index 0000000..c06eca1
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/lamda/Converter.java
@@ -0,0 +1,10 @@
+package functionalinterface.lamda;
+
+import java.util.function.Function;
+
+@FunctionalInterface
+public interface Converter extends Function<Integer, String> {
+
+    String apply(Integer t);
+
+}
diff --git a/mission/chaptor04/code/functionalinterface/lamda/Main.java b/mission/chaptor04/code/functionalinterface/lamda/Main.java
new file mode 100644
index 0000000..822608f
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/lamda/Main.java
@@ -0,0 +1,21 @@
+package functionalinterface.lamda;
+
+public class Main {
+
+
+    public static void main(String[] args) {
+        // given
+        Integer value = 3;
+        String expected = "3";
+
+        Converter converter = (i) -> String.valueOf(i);
+
+        // when
+        String result = converter.apply(value);
+
+        // then
+        boolean output = result.equals(expected);
+        System.out.println("output = " + output);
+    }
+
+}
diff --git a/mission/chaptor04/code/functionalinterface/methodreference/Converter.java b/mission/chaptor04/code/functionalinterface/methodreference/Converter.java
new file mode 100644
index 0000000..1c00171
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/methodreference/Converter.java
@@ -0,0 +1,10 @@
+package functionalinterface.methodreference;
+
+import java.util.function.Function;
+
+@FunctionalInterface
+public interface Converter extends Function<Integer, String> {
+
+    String apply(Integer t);
+
+}
diff --git a/mission/chaptor04/code/functionalinterface/methodreference/Main.java b/mission/chaptor04/code/functionalinterface/methodreference/Main.java
new file mode 100644
index 0000000..fcb067f
--- /dev/null
+++ b/mission/chaptor04/code/functionalinterface/methodreference/Main.java
@@ -0,0 +1,21 @@
+package functionalinterface.methodreference;
+
+public class Main {
+
+
+    public static void main(String[] args) {
+        // given
+        Integer value = 3;
+        String expected = "3";
+
+        Converter converter = String::valueOf;
+
+        // when
+        String result = converter.apply(value);
+
+        // then
+        boolean output = result.equals(expected);
+        System.out.println("output = " + output);
+    }
+
+}
diff --git a/mission/chaptor04/code/stream/Main.java b/mission/chaptor04/code/stream/Main.java
new file mode 100644
index 0000000..9bc7c72
--- /dev/null
+++ b/mission/chaptor04/code/stream/Main.java
@@ -0,0 +1,33 @@
+package stream;
+
+import java.util.Arrays;
+import java.util.List;
+
+public class Main {
+
+    public static void main(String[] args) {
+        // given
+        List<Integer> collectionList = List.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
+        Integer[] array = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
+
+        // when
+        List<Integer> collectionResult = collectionList.stream()
+            .map(i -> 2 * i) // Function <T,T>
+            .toList();
+
+        List<Integer> arrayResult = Arrays.stream(array)
+            .map(i -> 2 * i) // Function <T,T>
+            .toList();
+
+        // then
+        System.out.println("collectionList = " + collectionList);
+        System.out.println("collectionResult = " + collectionResult);
+
+        Arrays.stream(array)
+            .forEach(System.out::print);
+        System.out.println();
+
+        System.out.println("arrayResult = " + arrayResult);
+    }
+
+}
\ No newline at end of file
diff --git a/mission/chaptor04/java_mission.md b/mission/chaptor04/java_mission.md
new file mode 100644
index 0000000..eace106
--- /dev/null
+++ b/mission/chaptor04/java_mission.md
@@ -0,0 +1,110 @@
+
+## 함수형 인터페이스
+
+함수형 인터페이스는 단 하나의 추상메서드만을 가지는 인터페이스이다.
+
+> 참고: default, static 메서드 개수에는 제약이 없다.
+
+일반 인터페이스와 함수형 인터페이스의 규약이 다르다. `@FunctionalInterface` 라는 어노테이션을 선언하여 interface 코드가 함수형 인터페이스의 규약에 안 맞을 경우 미리 컴파일 에러를 낼 수 있다.
+
+함수형 인터페이스는 람다식을 다루기 위해 사용되는 인터페이스라고 생각하면 된다.
+람다 표현식은 하나의 객체로 볼 수 있으며, 이를 담을 수 있는 참조변수가 필요한데 이것이 함수형 인터페이스가 되는 것이다.
+
+
+### 함수형 인터페이스의 4가지 종류
+
+- Supplier<T> : T get()을 추상 메서드로 갖는다. 매개변수 없이 반환 값만 존재한다.
+- Consumer<T> : void accept(T t)를 추상 메서드로 갖는다. 매개변수만 있고 반환 값이 없다.
+- Function<T, R> : R apply(T t)를 추상메서드로 갖는다. 매개변수를 받아서 반환 값이 존재한다.
+- Predicate<T> : Boolean test(T t)를 추상메서드로 갖는다. 매개변수를 받아서 Boolean을 반환한다.
+
+이런 함수형 인터페이스를 구현하는 방법 4가지를 이번 과제해서 수행해본 것이다.
+
+
+**과제에서 한 구현방법 4가지**
+- 익명 클래스
+- 실제 상속한 클래스
+- 람다
+- 메서드 참조
+
+
+### **익명 클래스**
+함수형 인터페이스도 인터페이스이기 때문에, 해당 인터페이스를 이를 일회성으로 사용하는 익명클래스로 구현을 한 것이다.
+
+
+### **실제 상속한 클래스**
+함수형 인터페이스도 인터페이스이기 때문에, 해당 인터페이스를 이를 인스턴스화해서 구현을 한 것이다.
+
+
+### **람다**
+람다식은 익명객체를 생성하기 위한 표현식을 말한다.
+메서드를 하나의 간결한 식으로 표현한 것이라고 할 수 있다.
+Java 8 부터 지원하며, 람다를 통해 자바도 함수형 프로그래밍이 가능하게 되었다.
+
+**특징**
+- 메서드 이름과 반환타입은 생략가능하다
+- 매개변수의 타입을 추론할 수 있는 경우에는 타임을 생략할 수 있다.
+- 매개변수가 하나인 경우 괄호를 생략할 수 있다.
+- 함수의 몸체가 하나의 명령문으로 이루어진 경우 중괄호를 생략할 수 있다.
+    - 이 때 세미콜론은 붙이지 않는다.
+- 함수의 몸체가 return 문이 있는 경우 중괄호를 생략할 수 없다.
+- return 대신 표현식을 사용할 수 있으며, 반환값은 표현식의 결괏값이 된다.
+
+
+### **메서드 참조**
+
+람다 표현식이 단 하나의 메서드만을 호출하는 경우에 해당 람다 표현식에서 불필요한 **매개변수를 제거**하고 사용할 수 있도록 한다.
+
+함수형 인터페이스를 람다식이 아닌 일반 메서드를 참조시켜 선언하는 방법이다.
+참조가능한 메서드는 일반 메서드, static 메서드, 생성자가 있다.
+메서드 참조를 사용하면 람다식과 마찬가지로 함수형 인터페이스로 반환된다.
+
+함수형 인터페이스의 추상 메서드와 사용하려는 메서드의 **매개변수 타입, 개수, 반환형**이 일치한다면 간결하게 메서드 참조를 활용할 수 있다.
+
+---
+## Stream API
+
+Java 8부터 추가된 기능으로, 컬랙션이나 배열과 같은 데이터 소스를 처리하는 데 사용됩니다.
+함수형 프로그래밍 스타일을 채택하여 직관적으로 코드를 작성할 수 있습니다.
+
+### 특징
+- 데이터 처리 로직이 추상화되어 있어 내부적으로 병렬 처리를 수행할 수 있습니다.
+    - parallelStream()을 사용하면 가능
+- 연산이 실제로 필요할 때까지 수행되지 않고, 최종 연산이 호출될 때 수행됩니다.
+
+### 연산
+- **중간 연산**
+    - 스트림을 변환하거나 필터링이 가능하다. 여러 개를 연결할 수 있다.
+    - `filter`, `map`, `sorted`  등
+    - filter(Predicate<T> predicate): 조건에 맞는 요소만 필터링
+        - Predicate는 리턴 값이 Boolean, 인자 존재
+    -
+- **최종 연산**
+    - 결과를 생성하거나 처리를 완료하는 연산
+    - 스트림이 닫히고 더 이상 사용할 수 없다.
+    - `forEach`, `collect`, `count` 등
+    - forEach(Consumer<T> action): 각 요소에 대해 작업 수행
+        - Consumer는 리턴값이 없고 인자만 존재
+
+### 생성
+- `Stream.of()`, `Arrays.stream()`, `Collection.stream()`
+
+
+
+
+---
+
+### Q1. 함수형 인터페이스란 무엇인가요?
+**Answer**
+함수형 인터페이스는 단 하나의 추상 메서드만을 가지는 인터페이스입니다. Java 8에서 도입되었으며, 람다 표현식을 사용할 수 있도록 지원합니다. @FunctionalInterface라는 어노테이션을 사용하여 해당 인터페이스가 함수형 인터페이스 규칙을 준수하는지 검증할 수 있습니다. Java는 Supplier, Consumer, Function, Predicate 와 같은 함수형 인터페이스를 대표적으로 지원합니다.
+
+### Q2. 메서드 참조란 무엇이며, 언제 사용하는 것이 좋나요?
+**Answer**
+메서드 참조는 람다 표현식이 단 하나의 메서드만 호출하는 경우에 사용할 수 있는 간결한 문법입니다.  일반 메서드, 정적 메서드, 생성자를 참조할 수 있으며, 함수형 인터페이스의 추상 메서드와 참조할 메서드의 매개변수 타입, 개수, 반환형이 일치할 때 사용할 수 있습니다.
+
+### Q3. Predicate, Supplier, Consumer, Function 인터페이스의 역할과 차이점에 대해 설명해 주세요.
+**Answer**
+**Predicate<T>**: Boolean test(T t)라는 추상 메서드를 가지며, 주어진 인자를 평가하여 true 또는 false를 반환합니다. 주로 조건을 검사하는 데 사용됩니다.
+**Supplier<T>**: T get() 메서드를 가지며, 매개변수를 받지 않고 값을 반환합니다. 주로 값을 생성하거나 제공할 때 사용됩니다.
+**Consumer<T>**: void accept(T t) 메서드를 가지며, 매개변수를 받아서 처리하지만 값을 반환하지 않습니다. 주로 인자를 소비(출력, 로깅 등)하는 데 사용됩니다.
+**Function<T, R>**: R apply(T t) 메서드를 가지며, 입력값을 받아서 변환하거나 가공한 결과를 반환합니다. 주로 변환 작업에 사용됩니다.