diff --git a/week07/mission/mission.md b/week07/mission/mission.md
index e69de29..fa58609 100644
--- a/week07/mission/mission.md
+++ b/week07/mission/mission.md
@@ -0,0 +1,22 @@
+![image.png](attachment:27084a4a-1817-4b3c-bfc4-77e680ed9439:image.png)
+
+![image.png](attachment:1db38a13-d835-4e5b-8fe2-f6cb584f1fa9:image.png)
+
+![image.png](attachment:6c292aa5-8cf7-4b0f-9021-d6fbc282484a:image.png)
+
+미들웨어가 무엇인가
+
+Express에서 요청(req)과 응답(res) 사이에 끼워 넣는 함수들.
+
+app.use((req, res, next) => { ...; next(); }) 형태로 등록하고, 순차적으로 실행되며 필요하면 응답을 끝내거나 next()로 다음 단계로 넘김.
+
+공통 로깅, 인증, 파서(express.json), 쿠키 파서, 정적 파일 제공, 에러 처리 등을 각각 독립 함수로 두고 체인처럼 묶어두는 것임
+
+- morgan: 요청 로그 미들웨어
+- cookieParser: 쿠키를 req.cookies 로 파싱
+- express.json, express.urlencoded: 바디 파싱 미들웨어
+- 커스텀 404 핸들러와 errorHandler: 라우트 이후 실행되는 에러 처리 미들웨어
+
+![image.png](attachment:b92a70fa-a400-4088-883d-7fc5d3ea8bce:image.png)
+
+에러 미들웨어는 서버 라우팅 체인 맨 끝에 붙어서 모든 예외를 한 번에 처리하는 안전장치이이다. 먼저 AppError 계열인지 확인해서, 우리가 의도적으로 던진 에러라면 그대로 쓰고, 그렇지 않으면 new AppError 로 감싸서 메시지·상태코드를 표준 형태로 바꿔준다. 개발 모드에서는 원본 스택을 details 로 남기고 console.error 로 로그를 찍지만, 운영 모드에서는 메시지만 노출하도록 구분했다. 최종적으로 { success: false, code, message } 구조의 JSON을 내려주기 때문에, 컨트롤러 어디에서 오류가 나도 클라이언트는 동일한 실패 응답 포맷을 받을 수 있다.
\ No newline at end of file
diff --git a/week08/keyword/keyword.md b/week08/keyword/keyword.md
new file mode 100644
index 0000000..b250cf4
--- /dev/null
+++ b/week08/keyword/keyword.md
@@ -0,0 +1,52 @@
+- Swagger
+    - **API 설명서를 자동으로 만들어주는 도구**
+    - 백엔드에서 만든 API를 시각화해 문서처럼 보여줌
+    - Swagger UI를 통해 브라우저에서 API 목록, 파라미터, 응답 구조 등을 확인 가능
+    - 코드에 주석만 달아도 문서가 자동 생성됨
+    (`swagger-jsdoc`, `swagger-ui-express` 등 사용)
+    - 프론트엔드, 기획자, QA와 협업 시 커뮤니케이션 비용 절감
+    - API를 직접 테스트할 수 있는 UI 제공
+    
+    **장점**
+    
+    - 문서 자동 생성 → 유지보수 편함
+    - UI로 한눈에 확인 가능
+    - 팀 협업에 최적화
+    
+    **단점**
+    
+    - OpenAPI 3.1 완전 지원 부족
+    - 복잡한 커스터마이징 어려움
+- OpenAPI
+    - **REST API 명세를 위한 표준 포맷 (YAML 또는 JSON)**
+    - Swagger는 이 OpenAPI 명세를 읽고 문서를 생성함
+    → OpenAPI는 “언어”, Swagger는 “뷰어” 역할
+    - `paths`, `parameters`, `requestBody`, `responses` 등 구조화된 형태로 API를 정의함
+    - 도구와 언어 상관없이 동일한 규칙으로 API를 문서화 가능
+    
+    **장점**
+    
+    - 문서 표준화
+    - 다양한 툴과 연동 쉬움
+    - Git 등으로 버전 관리 가능
+    
+    **단점**
+    
+    - 문법이 복잡하게 느껴질 수 있음
+    - 작성 규칙에 익숙해지는데 시간 필요
+- OpenAPI Component
+    - **OpenAPI 문서에서 공통되는 항목을 재사용 가능하게 묶어둔 곳**
+    - 중복된 객체(예: `User`, `ErrorResponse`)를 하나만 정의하고 참조 가능
+    - 유지보수 편리, 문서 가독성 향상
+    
+    ```yaml
+    components:
+      schemas:
+        User:
+          type: object
+          properties:
+            id:
+              type: integer
+            name:
+              type: string
+    ```
\ No newline at end of file
diff --git a/week08/mission/mission.md b/week08/mission/mission.md
new file mode 100644
index 0000000..d28a522
--- /dev/null
+++ b/week08/mission/mission.md
@@ -0,0 +1,5 @@
+https://github.com/sojung0628/UMC_node_mission
+
+![image.png](attachment:144a9ac7-6e91-4216-a79f-08a66ccc4d84:image.png)
+
+![image.png](attachment:d3806539-9630-49a8-99ea-f5d472a1164f:image.png)
\ No newline at end of file