From 91d6037f4259db6551f017b3c46f6ffc6d29997e Mon Sep 17 00:00:00 2001
From: Mr-Sung98 <109071565+Mr-Sung98@users.noreply.github.com>
Date: Fri, 31 Mar 2023 19:46:32 +0900
Subject: [PATCH 01/29] Update README.md

Quest complete
---
 Quest00/README.md | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/Quest00/README.md b/Quest00/README.md
index 006bc98ad..f216b1979 100644
--- a/Quest00/README.md
+++ b/Quest00/README.md
@@ -16,10 +16,26 @@
 
 ## Checklist
 * 형상관리 시스템은 왜 나오게 되었을까요?
+
+형상관리 시스템은 특정 시점에 대해 상태를 기록해 놓으면 이후라도 언제든지 그 환경으로 돌아갈 수 있게 도와주는것
+인데 왜 이 시스템이 나왔냐면 협업의 특성상 여러 사람들이 프로젝트를 함께 참여하게 되는데 이 때 누군가의 실수로 잘못된 버전이나 버그들이 생길경우들이 많아서
+그러한 일들을 막기위해 생긴 시스템이다.
+
 * git은 어떤 형상관리 시스템이고 어떤 특징을 가지고 있을까요? 분산형 형상관리 시스템이란 무엇일까요?
+git의 경우 버전별로 관리할 수 있는 형상관리 시스템이다.
+분산형 형상관리 시스템은 마지막 저장한 것을 전부 복제하는것.(이와 반대되는것이 중앙집중식 버전 관리 시스템이다.)
+
   * git은 어떻게 개발되게 되었을까요? git이 분산형 시스템을 채택한 이유는 무엇일까요?
+  git은 Linux 커널이 BitKeeper을 만들면서 이익을 추구하는 회사와 관계가 틀어져 무료 사용이 재고된 후,자체 도구를 만드는 계기가 되었는데 이 도구가 Git이다.
+  git이 분산형 시스템을 채택한 이유는 빠른 속도,단순한 구조, 비선형적인 개발,완벽한 분산,대형 프로젝트에서도 유용하기 때문이다.
+  
 * git과 GitHub은 어떻게 다를까요?
+git과 Github와 차이점은 Local git/Remote git, 터미널을 사용하는git/UI를 지원하는 Github, PR(Pull Request) 기능을 지원하는 Github
+Github는 git을 서비스하지만 추가적인 여러 기능들을 지원하는 시스템이다.
+
 * git의 clone/add/commit/push/pull/branch/stash 명령은 무엇이며 어떨 때 이용하나요? 그리고 어떻게 사용하나요?
+
+
 * git의 Object, Commit, Head, Branch, Tag는 어떤 개념일까요? git 시스템은 프로젝트의 히스토리를 어떻게 저장할까요?
 * 리모트 git 저장소에 원하지 않는 파일이 올라갔을 때 이를 되돌리려면 어떻게 해야 할까요?
 
@@ -29,6 +45,13 @@
   * 앞으로의 git 작업은 되도록 커맨드라인을 통해 하는 것을 권장합니다.
 * 이 문서가 있는 폴더 바로 밑에 있는 sandbox 폴더에 파일을 추가한 후 커밋해 보기도 하고, 파일을 삭제해 보기도 하고, 수정해 보기도 하면서 각각의 단계에서 커밋했을 때 어떤 것들이 저장되는지를 확인합니다.
 * `clone`/`add`/`commit`/`push`/`pull`/`branch`/`stash` 명령을 충분히 익혔다고 생각되면, 자신의 저장소에 이력을 push합니다.
+clone(현재 자신이 있는 디렉토리 하위에 그 repository가 저장. 클라우드에 저장된 repository를 로컬에 저장하는 것.)
+add(repository(Working directory)에 변경된 내용을 Staging Area에 저장한다.)
+commit(Staging Area에 있는 내용들을 local repository에 전달한다.)
+push(local repository의 파일을 remote repository에 저장한다.)
+pull(원격 repository에 있는 내용을 로컬 repository로 다운로드 하는 명령어.)
+branch(브랜치 생성, 수정, 삭제를 하는 명령어)
+stash(아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어이다. 이를 통해 아직 완료하지 않은 일을 commit하지 않고 나중에 다시 꺼내와 마무리할 수 있다.)
 
 ## Advanced
 * Mercurial은 어떤 형상관리 시스템일까요? 어떤 장점이 있을까요?

From c9d1b1cbd70e7a54fceef5ce45ad99483c1acd55 Mon Sep 17 00:00:00 2001
From: Mr-Sung98 <109071565+Mr-Sung98@users.noreply.github.com>
Date: Fri, 31 Mar 2023 23:48:53 +0900
Subject: [PATCH 02/29] Update README.md

---
 Quest01/README.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Quest01/README.md b/Quest01/README.md
index f3741ed0a..4de7e913d 100644
--- a/Quest01/README.md
+++ b/Quest01/README.md
@@ -28,9 +28,23 @@
 
 ## Checklist
 * HTML 표준의 역사는 어떻게 될까요?
+HTML 1.0 = 거의 텍스트위주의 정보전달 목적
+W3C 웹의 표준을 정의하는 국제 컨소시엄
+HTML 2.0 ~ HTML 3.2 = 표준화를 위한 노력 
+HTML 4.01 안정된 표준의 HTML, CSS사용으로 디자인적 요소 구분. 그러나 W3C에서 더 이상은 기술적인 한계에 부딛혔다고 판단,HTML을 발전시키지 않을 것을 공표.
+XHTML XML과 HTML을 합성, 정확한 문법 사용 *XML W3C에서 개발한 특수한 목적을 갖는 마크업 언어를 만드는데 사용하도록 권장하는 다목적 마크업 언어.
+WHATWG(Web Hypertext Application Techology Working Group) HTML 5의 시초
+HTML 5 완벽한 표준의 정착.
+결국 W3C도 자세를 낮추고 XHTML을 표준에서 탈락시키게 되고, WHATWG에서 정의한 표준을 따르기로 한다. 결론적으로 HTML5와 CSS3가 표준으로 확정되게 되고, 지금의 HTML5 표준이 완성된 것이다.
+
   * HTML 표준을 지키는 것은 왜 중요할까요?
+  인류가 단위를 통일한 것이 공학의 발전 산업에 전반적인 효율성을 증가시킨것 처럼 웹표준역시 웹개발에서 효율성을 증대시키기 때문이다. 웹표준에대한 이해를 가지고 웹개발을 하는 것이 중요하다.
+  
   * XHTML 2.0은 왜 세상에 나오지 못하게 되었을까요?
+  XHTML2의 가장 큰 문제점은 HTML4와 XHTML1.0과 전혀 다른 새로운 표준이라는 것입니다. 한마디로 웹 브라우저 업체들에게는 렌더링 엔진을 바닥 부터 새로 짜야 할 만큼 하위 호환성에 대한 보장이 거의 없음.
+  
   * HTML5 표준은 어떤 과정을 통해 정해질까요?
+  
 * 브라우저의 역사는 어떻게 될까요?
   * Internet Explorer가 브라우저 시장을 독점하면서 어떤 문제가 일어났고, 이 문제는 어떻게 해결되었을까요?
   * 현재 시점에 브라우저별 점유율은 어떻게 될까요? 이 브라우저별 점유율을 알아보는 것은 왜 중요할까요?

From 98d09ffbc6d32c327a98c4e8f547b9494ef94131 Mon Sep 17 00:00:00 2001
From: Mr-Sung98 <109071565+Mr-Sung98@users.noreply.github.com>
Date: Sat, 1 Apr 2023 11:41:08 +0900
Subject: [PATCH 03/29] Update README.md

Quest 01 Complete
---
 Quest01/README.md | 110 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 110 insertions(+)

diff --git a/Quest01/README.md b/Quest01/README.md
index 4de7e913d..5716d0d24 100644
--- a/Quest01/README.md
+++ b/Quest01/README.md
@@ -44,18 +44,128 @@ HTML 5 완벽한 표준의 정착.
   XHTML2의 가장 큰 문제점은 HTML4와 XHTML1.0과 전혀 다른 새로운 표준이라는 것입니다. 한마디로 웹 브라우저 업체들에게는 렌더링 엔진을 바닥 부터 새로 짜야 할 만큼 하위 호환성에 대한 보장이 거의 없음.
   
   * HTML5 표준은 어떤 과정을 통해 정해질까요?
+표준화 단체인 W3C(World Wide Web Consortium)에서 HTML5 표준 작업 그룹을 구성합니다.
+HTML5 표준 작업 그룹에서 초안을 작성하고, 이를 공개적으로 검토 및 토론합니다.
+작업 그룹에서 검토 및 토론을 거친 최종 초안을 W3C에 제출합니다.
+W3C에서는 해당 초안을 검토하고, 표준화 과정을 진행합니다.
+W3C의 표준화 과정을 거친 후, 최종적으로 HTML5 표준이 발표됩니다.
   
 * 브라우저의 역사는 어떻게 될까요?
+웹 브라우저의 역사는 인터넷의 발전과 함께 시작되었습니다. 초기 인터넷에서는 텍스트 기반의 터미널 환경에서만 이용이 가능했습니다. 하지만 1990년대 중반, 그래픽 사용자 인터페이스(GUI)를 지원하는 웹 브라우저의 등장으로 인터넷의 사용이 대폭 증가하게 되었습니다.
+
+이후, 다양한 웹 브라우저가 등장하였으며, 이들은 서로 다른 렌더링 엔진을 사용하여 동작하였습니다. 이때 사용되는 렌더링 엔진은 HTML, CSS, JavaScript 등의 웹 페이지를 해석하고 브라우저 창에 렌더링하는 역할을 합니다.
+
+1995년, 마이크로소프트에서는 인터넷 익스플로러(IE)를 출시하여 대규모로 보급되었으며, 이는 넷스케이프(Netscape)와의 브라우저 전쟁을 일으키기도 했습니다.
+
+하지만 이후, 오픈 소스 기반의 모질라 스위트(Netscape Navigator의 코드를 기반으로 한)에서 파생된 파이어폭스(Firefox)와, 사파리(Safari), 오페라(Opera) 등 다양한 브라우저가 등장하게 되었습니다.
+
+2010년대 이후로는 구글에서 개발한 크롬(Chrome)이 대세가 되었으며, 모바일 기기용 브라우저인 안드로이드 기본 브라우저에서도 크롬 기반으로 변경되었습니다.
+
+최근에는 웹 표준을 준수하며 보안과 성능에 중점을 둔 브라우저의 필요성이 부각되면서, 모든 브라우저에서 웹 표준을 따르도록 노력하고 있습니다.
+
+
   * Internet Explorer가 브라우저 시장을 독점하면서 어떤 문제가 일어났고, 이 문제는 어떻게 해결되었을까요?
+웹 표준 준수 문제
+IE는 표준을 따르지 않는 비표준 기술을 많이 사용하여, 다른 브라우저에서는 정상적으로 작동하지 않는 웹 사이트가 많았습니다. 이로 인해 웹 개발자들은 IE에 맞춰 웹 페이지를 개발해야 하는 번거로움이 있었습니다.
+
+보안 문제
+IE는 보안 취약점이 많이 발견되어 사용자의 개인정보가 유출될 위험이 있었습니다. 이러한 보안 취약점은 해결되어야 하는 중요한 문제였습니다.
+
+이러한 문제를 해결하기 위해, 다양한 브라우저의 등장과 함께 웹 표준화의 중요성이 부각되었습니다. 특히, 오픈 소스 기반의 파이어폭스(Firefox)와 구글에서 개발한 크롬(Chrome) 등의 브라우저가 웹 표준을 준수하며 보안과 성능에 중점을 둔 브라우저를 제공하면서, IE의 독점 지배력은 낮아졌습니다.
+
+또한, 마이크로소프트도 웹 표준과 보안에 더 많은 관심을 기울이며, 최신 버전의 IE에서는 웹 표준을 준수하도록 노력하고 있습니다. 하지만, 이전 버전의 IE에서는 여전히 웹 표준 준수에 어려움이 있기 때문에, 이를 대응하기 위해 웹 개발자들은 여전히 추가 작업이 필요합니다.
+
   * 현재 시점에 브라우저별 점유율은 어떻게 될까요? 이 브라우저별 점유율을 알아보는 것은 왜 중요할까요?
+크롬(Chrome): 약 62%
+사파리(Safari): 약 19%
+파이어폭스(Firefox): 약 8%
+엣지(Edge): 약 6%
+기타 브라우저: 약 5%
+
+웹 사이트 개발에 영향을 미칩니다.
+브라우저별로 웹 표준을 준수하는 정도가 다르기 때문에, 브라우저별 점유율을 고려하지 않고 웹 사이트를 개발할 경우 특정 브라우저에서는 정상적으로 작동하지 않을 수 있습니다.
+
+마케팅에 영향을 미칩니다.
+브라우저별 점유율은 사용자들이 어떤 브라우저를 선호하는지를 보여주기 때문에, 해당 브라우저를 이용한 마케팅 전략을 세울 수 있습니다.
+
+보안에 영향을 미칩니다.
+점유율이 높은 브라우저일수록 악성코드 등의 보안 위협을 받을 가능성이 높습니다. 따라서 브라우저별 보안 취약점을 파악하고 이를 개선하는 것이 중요합니다.
+
+브라우저 경쟁력을 분석할 수 있습니다.
+브라우저별 점유율을 분석하면, 각 브라우저의 경쟁력을 파악할 수 있습니다. 이를 통해, 브라우저 개발자들은 경쟁에서 우위에 서기 위해 어떤 전략을 세워야 하는지를 파악할 수 있습니다.
+
   * 브라우저 엔진(렌더링 엔진)이란 무엇일까요? 어떤 브라우저들이 어떤 엔진을 쓸까요?
+브라우저 엔진 또는 렌더링 엔진은 HTML, CSS 및 JavaScript와 같은 웹 페이지의 코드를 브라우저가 이해할 수 있는 형태로 변환하여 화면에 표시하는 역할을 수행하는 소프트웨어입니다. 브라우저 엔진은 웹 브라우저의 핵심 부분 중 하나이며, 사용자가 보는 웹 페이지의 레이아웃, 스타일, 콘텐츠 및 기능을 처리합니다.
+
+다양한 브라우저가 있지만, 주요 브라우저의 엔진은 다음과 같습니다.
+
+크롬(Chrome): Blink 엔진 (Google에서 개발)
+파이어폭스(Firefox): Gecko 엔진 (Mozilla에서 개발)
+사파리(Safari): WebKit 엔진 (Apple에서 개발)
+엣지(Edge): Blink 엔진 (Microsoft에서 개발)
+브라우저 엔진은 각각의 브라우저에서 지원하는 웹 표준과 기능, 성능, 안정성 등이 다르기 때문에, 웹 개발자들은 다양한 엔진을 이해하고 각각의 특성을 고려하여 웹 페이지를 개발해야 합니다.
+
   * 모바일 시대 이후, 최근에 출시된 브라우저들은 어떤 특징을 가지고 있을까요?
+모바일 최적화: 모바일 기기에서의 사용성을 고려한 최적화가 이루어졌습니다. 모바일 환경에서의 터치 인터페이스, 제스처 제어, 반응형 레이아웃 등을 지원하여 모바일 사용자들에게 더 나은 경험을 제공합니다.
+
+속도 향상: 브라우저 엔진의 발전과 함께 더욱 빠른 속도를 제공합니다. 특히, 브라우저 캐시 및 프리페칭 기술 등을 이용하여 페이지 로딩 속도를 높였습니다.
+
+보안성 강화: 웹 상에서의 보안 위협이 증가함에 따라 보안성이 강화되었습니다. HTTPS 프로토콜을 강제화하고, XSS, CSRF 등의 공격 방어 기능을 탑재하여 사용자 정보를 보호합니다.
+
+확장성: 브라우저 확장 프로그램 등을 통해 다양한 기능을 추가할 수 있으며, 웹 표준을 지원하여 다양한 웹 사이트와 호환됩니다.
+
+인공지능 기술 도입: 최근에는 인공지능 기술을 이용하여 더욱 편리하고 개인화된 웹 서비스를 제공합니다. 예를 들어, 취향에 맞는 콘텐츠 추천, 음성 인식 검색 기능 등이 있습니다.
+
+에코 시스템: 브라우저 제작사들은 자사의 생태계를 강화하기 위해 다양한 기술과 서비스를 제공합니다. 이를 통해 브라우저 사용자들에게 더욱 편리한 환경을 제공하고, 생태계의 확장을 위한 시너지 효과를 기대할 수 있습니다.
+
 * HTML 문서는 어떤 구조로 이루어져 있나요?
+구조를 담당하는 요소 (Semantic Elements)
+HTML 문서는 마크업 언어로 웹 페이지의 구조를 정의합니다. 이를 담당하는 요소들은 시맨틱 요소(Semantic Elements)라고 하며, 웹 페이지의 의미와 구조를 명확하게 전달합니다.
+콘텐츠를 담당하는 요소
+콘텐츠를 담당하는 요소는 HTML 문서에서 실제로 보여지는 내용을 담당합니다. 예를 들면 <h1>~<h6>, <p>, <img>, <a>, <ul>, <ol>, <li>, <table>, <form> 등이 있습니다.
+
   * `<head>`에 자주 들어가는 엘리먼트들은 어떤 것이 있고, 어떤 역할을 할까요?
+<title> 요소
+<title> 요소는 웹 페이지의 제목을 정의합니다. 브라우저의 제목 표시줄에 표시되며, 검색 엔진에서 페이지 제목으로 사용됩니다.
+
+<meta> 요소
+<meta> 요소는 다양한 메타데이터를 정의합니다. 예를 들어, 문서의 문자 인코딩, 검색 엔진에 대한 설명, 페이지의 설명 등을 정의할 수 있습니다.
+
+<link> 요소
+<link> 요소는 웹 페이지에서 사용할 외부 파일, 예를 들어 스타일 시트 파일, 아이콘 파일 등을 연결합니다.
+
+<script> 요소
+<script> 요소는 자바스크립트 코드를 정의합니다. 이를 통해 웹 페이지의 동작을 제어하거나, 서버와의 데이터 통신 등을 수행할 수 있습니다.
+
   * 시맨틱 태그는 무엇일까요?
+시맨틱 태그는 웹 페이지의 구조와 의미를 나타내는 태그를 말합니다. 즉, 해당 태그가 어떤 내용을 포함하고 있는지를 의미하는 것입니다.
+
+시맨틱 태그를 사용하면 웹 페이지의 구조가 명확하게 나타나기 때문에, 검색 엔진이 페이지의 내용을 더 잘 이해하고 분석할 수 있으며, 웹 페이지의 접근성이 향상됩니다. 또한, 시맨틱 태그를 사용하면 CSS 스타일링이 더욱 쉬워지고, 웹 페이지의 가독성도 향상됩니다.
+
+시맨틱 태그의 예시로는 <header>, <nav>, <main>, <article>, <section>, <aside>, <footer> 등이 있습니다. 이러한 태그들은 해당하는 영역의 내용을 더 명확하게 정의하며, 웹 페이지의 구조와 의미를 더욱 분명하게 표현합니다
+
     * 시맨틱 엘리먼트를 사용하면 어떤 점이 좋을까요?
+검색 엔진 최적화 (SEO): 시맨틱 엘리먼트를 사용하면 웹 페이지의 내용과 구조를 검색 엔진이 더욱 잘 이해할 수 있습니다. 이는 검색 엔진 최적화를 향상시키는데 도움을 줄 수 있습니다.
+
+웹 접근성: 시맨틱 엘리먼트를 사용하면 웹 페이지의 구조와 내용을 보다 명확하게 표현할 수 있어, 스크린 리더 등의 보조 기술을 사용하는 사용자들에게 웹 페이지를 이해하기 쉽게 만들어줍니다.
+
+유지보수: 시맨틱 엘리먼트를 사용하면 다른 개발자들이 나의 작성한 코드를 이해하고 수정하기 쉬워집니다. 이는 코드의 유지보수를 보다 쉽게 할 수 있게 만들어줍니다.
+
+가독성: 시맨틱 엘리먼트를 사용하면 코드의 가독성이 향상됩니다. 이는 코드의 가독성을 높이고 유지보수를 쉽게 하는데 도움을 줍니다.
+
     * `<section>`과 `<div>`, `<header>`, `<footer>`, `<article>` 엘리먼트의 차이점은 무엇인가요?
   * 블록 레벨 엘리먼트와 인라인 엘리먼트는 어떤 차이가 있을까요?
+<section>: 문서의 일반적인 구획을 표시합니다. 보통 제목(<h1>~<h6>)과 함께 사용됩니다.
+<div>: 구획을 나누기 위해 사용되며, 목적에 따라 다양한 방식으로 사용될 수 있습니다.
+<header>: 섹션 또는 페이지의 제목을 나타냅니다. 로고, 검색 폼, 작성자 이름 등과 함께 사용될 수 있습니다.
+<footer>: 섹션 또는 페이지의 바닥글을 나타냅니다. 저작권 정보, 연락처 정보, 사이트 맵 등이 포함될 수 있습니다.
+<article>: 문서, 페이지, 사이트 안에서 독립적으로 구분되거나 재사용 가능한 영역을 나타냅니다. 뉴스 기사, 블로그 글, 포럼 게시글 등과 함께 사용될 수 있습니다.
+인라인 엘리먼트와 블록 레벨 엘리먼트의 차이점은 다음과 같습니다.
+
+블록 레벨 엘리먼트는 새로운 줄에서 시작하여 새로운 블록을 만들고, 전체 너비를 차지합니다. 반면 인라인 엘리먼트는 줄 안에서만 사용되며, 컨텐츠의 너비만큼만 차지합니다.
+블록 레벨 엘리먼트는 다른 블록 레벨 엘리먼트나 인라인 엘리먼트를 포함할 수 있습니다. 반면 인라인 엘리먼트는 다른 인라인 엘리먼트를 포함할 수 있지만, 블록 레벨 엘리먼트를 포함할 수는 없습니다.
+블록 레벨 엘리먼트는 컨텐츠를 구성하기 위해 사용되며, 인라인 엘리먼트는 텍스트와 같은 컨텐츠의 일부분을 나타내기 위해 사용됩니다.
+
 
 ## Quest
 * [이 화면](screen.png)의 정보를 HTML 문서로 표현해 보세요. 다만 CSS를 전혀 사용하지 않고, 문서의 구조가 어떻게 되어 있는지를 파악하여 구현해 보세요.

From edd7b4febccb02aa9898c8b653e16569301a98d6 Mon Sep 17 00:00:00 2001
From: Mr-Sung98 <109071565+Mr-Sung98@users.noreply.github.com>
Date: Sat, 1 Apr 2023 11:51:48 +0900
Subject: [PATCH 04/29] Update README.md

Quest 02 Complete
---
 Quest02/README.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/Quest02/README.md b/Quest02/README.md
index 6a76991ba..d4ac9e20e 100644
--- a/Quest02/README.md
+++ b/Quest02/README.md
@@ -22,12 +22,93 @@
 
 ## Checklist
 * CSS를 HTML에 적용하는 세 가지 방법은 무엇일까요?
+내부 스타일 시트 (Internal Style Sheet) : HTML 문서 안에서 <style> 태그를 사용하여 스타일 정보를 작성하는 방법입니다. 이 방법은 한 페이지에서만 스타일을 적용하고, 해당 페이지에서만 사용되는 스타일을 작성할 때 유용합니다.
+외부 스타일 시트 (External Style Sheet) : CSS 파일을 작성하여 HTML 문서에서 <link> 태그를 사용하여 CSS 파일을 불러오는 방법입니다. 이 방법은 여러 페이지에서 공통적으로 사용되는 스타일을 작성할 때 유용합니다.
+인라인 스타일 (Inline Style) : HTML 태그 안에서 style 속성을 사용하여 스타일 정보를 작성하는 방법입니다. 이 방법은 특정 요소에만 스타일을 적용하고, 다른 요소와 구분하여 스타일을 작성할 때 유용합니다.
+
   * 세 가지 방법 각각의 장단점은 무엇일까요?
+Inline Style
+장점: 스타일을 적용하려는 HTML 요소에 직접 스타일을 적용할 수 있어 간단하고 빠르게 스타일링이 가능합니다.
+단점: 유지보수와 확장이 어려워지며, 스타일링을 많이 하게 될 경우 코드가 복잡해지고 HTML 코드가 지저분해질 수 있습니다.
+Internal Style
+장점: HTML 문서 내부에서 CSS 코드를 작성하여 관리가 용이합니다.
+단점: 여러 페이지에 같은 스타일을 적용하고자 할 경우, 중복되는 스타일 코드를 일일이 작성해야 하므로 코드의 중복이 발생할 수 있습니다.
+External Style
+장점: 여러 HTML 문서에서 공통적으로 사용되는 스타일을 별도의 CSS 파일로 분리하여 관리할 수 있습니다. HTML 문서 내부의 스타일 코드가 줄어들어 가독성이 좋아지며, 스타일을 변경할 경우 CSS 파일만 수정하면 되므로 유지보수와 확장이 용이합니다.
+단점: 외부 CSS 파일을 로드해야 하기 때문에 HTML 문서를 렌더링하는 데 시간이 조금 더 걸립니다.
+
 * CSS 규칙의 우선순위는 어떻게 결정될까요?
+명시도(Specificity): 선택자의 구체성에 따라 우선순위가 결정됩니다. 선택자의 구체성은 아이디 선택자의 개수, 클래스 선택자와 속성 선택자의 개수, 태그 선택자의 개수 등으로 결정됩니다. 예를 들어, 아이디 선택자가 클래스 선택자보다 우선순위가 높습니다.
+
+중요도(Importance): !important 키워드가 사용된 규칙은 다른 규칙보다 우선시됩니다.
+
+소스 순서: 동일한 명시도와 중요도를 가진 규칙은 나중에 나온 규칙이 우선시됩니다.
+
 * CSS의 박스모델은 무엇일까요? 박스가 화면에서 차지하는 크기는 어떻게 결정될까요?
+콘텐츠 영역(Content Area): 요소에 실제로 들어가는 텍스트나 이미지 등의 콘텐츠가 들어가는 영역입니다.
+
+패딩 영역(Padding Area): 콘텐츠 영역과 테두리(Border) 사이의 여백 영역입니다.
+
+테두리 영역(Border Area): 요소를 둘러싸고 있는 테두리 영역입니다.
+
+마진 영역(Margin Area): 테두리(Border)와 다른 요소와의 간격을 나타내는 영역입니다.
+
+이 4개의 영역은 서로 독립적으로 크기를 지정할 수 있습니다.
+
+박스가 화면에서 차지하는 크기는 다음과 같이 결정됩니다.
+
+콘텐츠 영역의 크기는 콘텐츠의 크기에 따라 결정됩니다. 예를 들어, <div> 요소 안에 들어있는 텍스트의 길이나 이미지의 크기에 따라 콘텐츠 영역의 크기가 결정됩니다.
+
+패딩 영역과 테두리 영역의 크기는 CSS 속성을 이용해 지정할 수 있습니다. 예를 들어, padding 속성과 border 속성을 이용해 패딩 영역과 테두리 영역의 크기를 지정할 수 있습니다.
+
+마진 영역의 크기는 다른 요소와의 간격을 나타내는 영역으로, CSS 속성을 이용해 지정할 수 있습니다. 예를 들어, margin 속성을 이용해 마진 영역의 크기를 지정할 수 있습니다.
+
 * `float` 속성은 왜 좋지 않을까요?
+의도하지 않은 요소에도 영향을 미침
+float 속성이 적용된 요소는 주변의 다른 요소들과 위치 상태를 변경할 수 있습니다. 이러한 특성은 원치 않는 결과를 초래할 수 있습니다. 또한, float 속성이 적용된 요소와 주변 요소 간에 간격이 자동으로 생기기 때문에 레이아웃을 유연하게 조절하기 어렵습니다.
+
+높이가 적용되지 않음
+float 속성을 사용하면 요소의 높이가 자동으로 계산되지 않습니다. 이로 인해 요소가 깨져서 보이는 문제가 발생할 수 있습니다.
+
+코드의 가독성이 떨어짐
+float 속성은 요소를 위치시키기 위한 목적으로만 사용하기 때문에 코드의 의미를 파악하기 어렵게 만들 수 있습니다. 코드의 유지보수나 수정 시 어려움을 겪을 수 있습니다.
+
+접근성 문제
+float 속성은 화면 낭독기 등의 보조 기기에서 레이아웃을 이해하는 데 문제가 생길 수 있습니다. 또한, 키보드 네비게이션 등에도 영향을 미칠 수 있습니다.
+
 * Flexbox(Flexible box)와 CSS Grid의 차이와 장단점은 무엇일까요?
+Flexbox(Flexible box)
+단일 차원(행 또는 열)에서 요소들의 위치를 지정하는 데 사용됩니다.
+요소들을 정렬하고, 간격을 조절하며, 순서를 변경하는 데 유용합니다.
+주로 UI 컴포넌트(예: 메뉴, 버튼, 카드 등)의 레이아웃 구성에 사용됩니다.
+구형 브라우저에서도 사용 가능합니다.
+장점
+간단하고 쉽게 구현할 수 있습니다.
+단일 차원에서 요소를 배치하므로 빠르게 렌더링됩니다.
+순서 변경과 같은 유연한 레이아웃 제공합니다.
+단점
+복잡한 레이아웃에 대한 지원이 부족합니다.
+요소 간의 간격을 동적으로 조절하는 것이 어렵습니다.
+다양한 크기와 형태의 요소들을 다루기 어렵습니다.
+CSS Grid
+2차원 레이아웃(행과 열)을 지정하는 데 사용됩니다.
+요소들을 위치 지정하고, 간격을 조절하며, 배치하는 데 유용합니다.
+주로 전체 페이지 레이아웃 구성에 사용됩니다.
+구형 브라우저에서는 일부 기능만 사용 가능합니다.
+장점
+복잡한 레이아웃에 대한 지원이 우수합니다.
+요소 간의 간격을 동적으로 조절하는 것이 쉽습니다.
+다양한 크기와 형태의 요소들을 다루기 쉽습니다.
+단점
+간단한 레이아웃에서는 사용하기에 적합하지 않습니다.
+2차원 레이아웃을 다루므로 빠르게 렌더링되지 않을 수 있습니다.
+모든 브라우저에서 완전히 지원되지 않을 수 있습니다.
+
 * CSS의 비슷한 요소들을 어떤 식으로 정리할 수 있을까요?
+Selectors: 선택자를 사용하여 비슷한 스타일을 적용할 요소들을 그룹화할 수 있습니다. 예를 들어, 모든 <h1> 요소에 스타일을 적용하고 싶다면, 다음과 같이 선택자를 사용합니다.
+Classes: 클래스를 사용하여 HTML 요소를 그룹화할 수 있습니다. 클래스는 여러 요소에서 재사용할 수 있습니다. 예를 들어, 모든 제목에 대해 같은 스타일을 적용하지만, 다른 스타일을 적용하고 싶은 경우, 다음과 같이 클래스를 사용합니다.
+ID: ID는 HTML 요소를 고유하게 식별하는 데 사용됩니다. ID는 한 번만 사용할 수 있으며 CSS에서 특정 요소에 스타일을 적용하려는 경우 사용됩니다. 예를 들어, 한 요소에 대해 특정 스타일을 적용하고 싶은 경우, 다음과 같이 ID를 사용합니다.
+Inheritance: 부모 요소에 적용된 스타일이 자식 요소에도 적용되는 특성을 이용하여, 비슷한 스타일을 적용할 요소들을 그룹화할 수 있습니다. 예를 들어, 모든 제목 요소에 대해 글꼴 색상을 빨강색으로 지정하고 싶은 경우, 다음과 같이 적용할 수 있습니다.
 
 ## Quest
 * Quest 01에서 만들었던 HTML을 바탕으로, [이 그림](screen.png)의 레이아웃과 CSS를 최대한 비슷하게 흉내내 보세요. 꼭 완벽히 정확할 필요는 없으나 align 등의 속성은 일치해야 합니다.

From fdda52273455e20b38b16e6d80280c96268562ac Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Sun, 2 Apr 2023 00:03:45 +0900
Subject: [PATCH 05/29] com

---
 Quest00/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Quest00/README.md b/Quest00/README.md
index f216b1979..a93c1f642 100644
--- a/Quest00/README.md
+++ b/Quest00/README.md
@@ -55,4 +55,4 @@ stash(아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있
 
 ## Advanced
 * Mercurial은 어떤 형상관리 시스템일까요? 어떤 장점이 있을까요?
-* 실리콘밸리의 테크 대기업들은 어떤 형상관리 시스템을 쓰고 있을까요?
+* 실리콘밸리의 테크 대기업들은 어떤 형상관리 시스템을 쓰고 있을까요?
\ No newline at end of file

From c8928775286fa58dc463fec80768f5f491d42b37 Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Mon, 3 Apr 2023 00:41:55 +0900
Subject: [PATCH 06/29] =?UTF-8?q?=EC=A4=91=EA=B0=84=20=EC=A0=80=EC=9E=A5(C?=
 =?UTF-8?q?heckList)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest03/README.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Quest03/README.md b/Quest03/README.md
index c0b5cbb9d..abca00570 100644
--- a/Quest03/README.md
+++ b/Quest03/README.md
@@ -20,7 +20,17 @@
 
 ## Checklist
 * 자바스크립트는 버전별로 어떻게 변화하고 발전해 왔을까요?
+
+자바스크립트(JavaScript)는 초기에는 웹 페이지의 동적인 기능을 구현하는 데 주로 사용되었습니다. 하지만 시간이 지남에 따라 자바스크립트는 웹 개발 분야에서 매우 중요한 언어로 자리 잡았습니다.
+
   * 자바스크립트의 버전들을 가리키는 ES5, ES6, ES2016, ES2017 등은 무엇을 이야기할까요?
+  ES란 Ecma Script의 준말로 JavaScript명세서(표준,규격)를 의미함
+  ES5는 "use strict"선언을 추가하여 코드 실행을 엄격하게함
+  ES6는 클래스,모듈,템플릿 리터럴 등의 새로운 기능 추가.
+  ES2016은 includes(배열 내장 함수 EX.['a','b','c'].indexOf('a') > -1가 ['a', 'b', 'c'].includes('a') 처럼 간결해짐),Exponentiation operator추가(제곱 연산자 EX.Math와 pow함수 대신 ** 연산자로 가능)
+  ES2017은 문자 여백 기능,Object.values(),Object.entries(),Object.getOwnPropertyDescriptors(),Trailing commas,async/await(기존의 Promise보다 가독성이 좋은 코드 작성 가능) 추가
+  https://junhobaik.github.io/es2016-es2020/#objectgetownpropertydescriptors 자료 참조
+  
   * 자바스크립트의 표준은 어떻게 제정될까요?
 * 자바스크립트의 문법은 다른 언어들과 비교해 어떤 특징이 있을까요?
   * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?

From b5f4b9ad7a1630f159e1438d63ac82b57b1ec1b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Mon, 3 Apr 2023 15:44:30 +0900
Subject: [PATCH 07/29] Quest3 CheckList

---
 Quest02/Quest03/README.md                |  58 ++++++++++++++++++++
 {Quest03 => Quest02/Quest03}/jsStars.png | Bin
 Quest02/Quest03/skeleton/quest.html      |  65 +++++++++++++++++++++++
 Quest03/README.md                        |  43 +++++++++++++++
 Quest03/skeleton/quest.html              |   1 +
 5 files changed, 167 insertions(+)
 create mode 100644 Quest02/Quest03/README.md
 rename {Quest03 => Quest02/Quest03}/jsStars.png (100%)
 create mode 100644 Quest02/Quest03/skeleton/quest.html

diff --git a/Quest02/Quest03/README.md b/Quest02/Quest03/README.md
new file mode 100644
index 000000000..abca00570
--- /dev/null
+++ b/Quest02/Quest03/README.md
@@ -0,0 +1,58 @@
+# Quest 03. 자바스크립트와 DOM
+
+## Introduction
+* 자바스크립트는 현재 웹 생태계의 근간인 프로그래밍 언어입니다. 이번 퀘스트에서는 자바스크립트의 기본적인 문법과, 자바스크립트를 통해 브라우저의 실제 DOM 노드를 조작하는 법에 대하여 알아볼 예정입니다.
+
+## Topics
+* 자바스크립트의 역사
+* 기본 자바스크립트 문법
+* DOM API
+  * `document` 객체
+  * `document.getElementById()`, `document.querySelector()`, `document.querySelectorAll()` 함수들
+  * 기타 DOM 조작을 위한 함수와 속성들
+* 변수의 스코프
+  * `var`, `let`, `const`
+
+## Resources
+* [자바스크립트 첫걸음](https://developer.mozilla.org/ko/docs/Learn/JavaScript/First_steps)
+* [자바스크립트 구성요소](https://developer.mozilla.org/ko/docs/Learn/JavaScript/Building_blocks)
+* [Just JavaScript](https://justjavascript.com/)
+
+## Checklist
+* 자바스크립트는 버전별로 어떻게 변화하고 발전해 왔을까요?
+
+자바스크립트(JavaScript)는 초기에는 웹 페이지의 동적인 기능을 구현하는 데 주로 사용되었습니다. 하지만 시간이 지남에 따라 자바스크립트는 웹 개발 분야에서 매우 중요한 언어로 자리 잡았습니다.
+
+  * 자바스크립트의 버전들을 가리키는 ES5, ES6, ES2016, ES2017 등은 무엇을 이야기할까요?
+  ES란 Ecma Script의 준말로 JavaScript명세서(표준,규격)를 의미함
+  ES5는 "use strict"선언을 추가하여 코드 실행을 엄격하게함
+  ES6는 클래스,모듈,템플릿 리터럴 등의 새로운 기능 추가.
+  ES2016은 includes(배열 내장 함수 EX.['a','b','c'].indexOf('a') > -1가 ['a', 'b', 'c'].includes('a') 처럼 간결해짐),Exponentiation operator추가(제곱 연산자 EX.Math와 pow함수 대신 ** 연산자로 가능)
+  ES2017은 문자 여백 기능,Object.values(),Object.entries(),Object.getOwnPropertyDescriptors(),Trailing commas,async/await(기존의 Promise보다 가독성이 좋은 코드 작성 가능) 추가
+  https://junhobaik.github.io/es2016-es2020/#objectgetownpropertydescriptors 자료 참조
+  
+  * 자바스크립트의 표준은 어떻게 제정될까요?
+* 자바스크립트의 문법은 다른 언어들과 비교해 어떤 특징이 있을까요?
+  * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?
+* 자바스크립트를 통해 DOM 객체에 CSS Class를 주거나 없애려면 어떻게 해야 하나요?
+  * IE9나 그 이전의 옛날 브라우저들에서는 어떻게 해야 하나요?
+* 자바스크립트의 변수가 유효한 범위는 어떻게 결정되나요?
+  * `var`과 `let`으로 변수를 정의하는 방법들은 어떻게 다르게 동작하나요?
+* 자바스크립트의 익명 함수는 무엇인가요?
+  * 자바스크립트의 Arrow function은 무엇일까요?
+
+## Quest
+* (Quest 03-1) 초보 프로그래머의 영원한 친구, 별찍기 프로그램입니다.
+  * [이 그림](jsStars.png)과 같이, 입력한 숫자만큼 삼각형 모양으로 콘솔에 별을 그리는 퀘스트 입니다.
+    * 줄 수를 입력받고 그 줄 수만큼 별을 그리면 됩니다. 위의 그림은 5를 입력받았을 때의 결과입니다.
+  * `if`와 `for`와 `function`을 다양하게 써서 프로그래밍 하면 더 좋은 코드가 나올 수 있을까요?
+  * 입력은 `prompt()` 함수를 통해 받을 수 있습니다.
+  * 출력은 `console.log()` 함수를 통해 할 수 있습니다.
+* (Quest 03-2) skeleton 디렉토리에 주어진 HTML을 조작하는 스크립트를 완성해 보세요.
+  * 첫째 줄에 있는 사각형의 박스들을 클릭할 때마다 배경색이 노란색↔흰색으로 토글되어야 합니다.
+  * 둘째 줄에 있는 사각형의 박스들을 클릭할 때마다 `enabled`라는 이름의 CSS Class가 클릭된 DOM 노드에 추가되거나 제거되어야 합니다.
+* 구현에는 여러 가지 방법이 있으나, 다른 곳은 건드리지 않고 TODO 부분만 고치는 방향으로 하시는 것을 권장해 드립니다.
+
+## Advanced
+* Quest 03-1의 코드를 더 구조화하고, 중복을 제거하고, 각각의 코드 블록이 한 가지 일을 전문적으로 잘하게 하려면 어떻게 해야 할까요?
+* Quest 03-2의 스켈레톤 코드에서 `let` 대신 `var`로 바뀐다면 어떤 식으로 구현할 수 있을까요?
diff --git a/Quest03/jsStars.png b/Quest02/Quest03/jsStars.png
similarity index 100%
rename from Quest03/jsStars.png
rename to Quest02/Quest03/jsStars.png
diff --git a/Quest02/Quest03/skeleton/quest.html b/Quest02/Quest03/skeleton/quest.html
new file mode 100644
index 000000000..45853d381
--- /dev/null
+++ b/Quest02/Quest03/skeleton/quest.html
@@ -0,0 +1,65 @@
+<!DOCTYPE html>
+<html>
+	<head>
+		<meta charset="UTF-8">
+		<style>
+			.square {
+				width: 100px;
+				height: 100px;
+				border: 1px dashed black;
+				display: inline-block;
+				margin: 20px;
+			}
+
+			.enabled {
+				background-color: limegreen;
+				border: 1px solid black;
+			}
+		</style>
+	</head>
+	<body>
+		<section class="row1">
+			<div class="square"></div>
+			<div class="square"></div>
+			<div class="square"></div>
+			<div class="square"></div>
+		</section>
+
+		<section class="row2">
+			<div class="square"></div>
+			<div class="square"></div>
+			<div class="square"></div>
+			<div class="square"></div>
+		</section>
+
+		<script>
+			let row1Squares = document.querySelectorAll('.row1 .square');
+			for(let node of row1Squares) {
+				/* TODO: node 변수를 어떻게 조작해야 할까요? */
+			}
+
+			let row2Squares = document.querySelectorAll('.row2 .square');
+			for(let node of row2Squares) {
+				/* TODO: node 변수를 어떻게 조작해야 할까요? */
+			}
+			function drawTriangle() {
+  const num = prompt("숫자를 입력하세요:");
+
+  if (num < 1) {
+    console.log("1 이상의 숫자를 입력해주세요.");
+    return;
+  }
+
+  for (let i = 1; i <= num; i++) {
+    let stars = "";
+    for (let j = 1; j <= i; j++) {
+      stars += "*";
+    }
+    console.log(stars);
+  }
+}
+
+drawTriangle();
+		</script>
+	</body>
+</html>
diff --git a/Quest03/README.md b/Quest03/README.md
index abca00570..23ad7a3ba 100644
--- a/Quest03/README.md
+++ b/Quest03/README.md
@@ -32,14 +32,57 @@
   https://junhobaik.github.io/es2016-es2020/#objectgetownpropertydescriptors 자료 참조
   
   * 자바스크립트의 표준은 어떻게 제정될까요?
+  자바스크립트의 표준은 Ecma International이라는 국제 표준화 기구에서 관리됩니다.
+
+Ecma International은 다양한 프로그래밍 언어의 표준을 제정하는 비영리 표준화 기구 중 하나입니다. Ecma International은 자바스크립트 표준을 제정하기 위해 Technical Committee 39 (TC39)이라는 특별위원회를 운영하고 있습니다.
+
+TC39은 자바스크립트 언어의 발전과 향후 버전의 표준 제정을 위해 회의를 진행하고 논의하며, 새로운 기능이나 구문을 추가하거나 변경하는 등의 작업을 수행합니다. TC39에서 결정된 내용은 Ecma International의 공식 문서인 ECMA-262 표준 문서로 반영됩니다.
+
+ECMA-262는 자바스크립트 언어의 표준 사양을 정의하는 문서이며, 최초 버전인 ECMAScript 1부터 최신 버전인 ECMAScript 2022까지 총 12개의 버전이 존재합니다. 자바스크립트 엔진은 이 표준 사양을 준수하여 구현됩니다.
+
 * 자바스크립트의 문법은 다른 언어들과 비교해 어떤 특징이 있을까요?
+객체기반언어
+동적 타이핑
+클로저(함수가 호출될 때마다 함수 내부에 새로운 스코프(scope)가 생성, 내부함수에서 외부 함수의 변수를 참조시 해당 변수를 계속해서 참조가능 이것이 클로저(closure).스코프 체인(scope chain)으로 표현되기도 함.)
+
   * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?
+  for문: 가장 기본적인 반복문으로, 정해진 횟수만큼 반복합니다.
+  while문: 조건식이 참일 때 계속 반복합니다.
+  do-while문: while문과 유사하지만, 조건식을 맨 뒤에 작성합니다. 이 경우, 조건식이 참일 때 실행이 되는 최소한 한 번은 실행됩니다.
+  for...in문: 객체의 속성을 반복해서 순회합니다.
+  for...of문: 배열의 요소를 반복해서 순회합니다.
+  forEach() 메서드: 배열의 요소를 반복해서 순회합니다. for...of문과 유사하지만, 각 요소에 대해 콜백 함수를 실행하는 방식으로 작동합니다.
+  map() 메서드: 배열의 요소를 반복해서 순회하며, 각 요소에 대해 변환 작업을 수행합니다. 변환 작업을 마친 새로운 배열을 반환합니다.
+  filter() 메서드: 배열의 요소를 반복해서 순회하며, 각 요소에 대해 조건식을 적용합니다. 조건식을 만족하는 요소만 모아서 새로운 배열을 반환합니다.
+  reduce() 메서드: 배열의 요소를 반복해서 순회하며, 각 요소를 하나의 값으로 줄여나가는 작업을 수행합니다. 최종적으로 하나의 값을 반환합니다.
+
 * 자바스크립트를 통해 DOM 객체에 CSS Class를 주거나 없애려면 어떻게 해야 하나요?
+classList 프로퍼티와 add(), remove(), toggle() 메서드를 사용합니다.
+
   * IE9나 그 이전의 옛날 브라우저들에서는 어떻게 해야 하나요?
+  폴리필(Polyfill) 사용하기
+  폴리필은 구형 브라우저에서 최신 웹 기술을 사용할 수 있도록 지원하는 코드.
+  기능 점진적 향상(Progressive Enhancement) 적용하기
+  브라우저 업그레이드 유도하기
+
 * 자바스크립트의 변수가 유효한 범위는 어떻게 결정되나요?
+전역 범위(Global Scope)
+함수 바깥에서 선언된 변수
+지역 범위/함수 범위(Local Scope/Function Scope)
+함수 내에서 선언된 변수
+블록 범위(Block Scope)
+ES6부터 도입된 let와 const키워드로 선언된 변수
   * `var`과 `let`으로 변수를 정의하는 방법들은 어떻게 다르게 동작하나요?
+  'var'변수는 선언 위치에 따라 범위가 다른데 함수 외부에서 선언될 때는 전역,내에서는 함수 범위
+  'let'는 블록 범위이며 변수가 선언된 중괄호{}내 에서만 접근이 가능합니다.
+
 * 자바스크립트의 익명 함수는 무엇인가요?
+일반적으로 익명 함수는 즉시 실행 함수(IIFE, Immediately Invoked Function Expression)로 사용됩니다. 즉시 실행 함수는 함수 정의와 동시에 호출되는 함수로, 한 번만 실행되는 코드 블록을 생성하는 데 사용됩니다. 이는 전역 스코프의 오염을 방지하고, 모듈화를 위한 네임스페이스로 사용됩니다.
+
   * 자바스크립트의 Arrow function은 무엇일까요?
+  Arrow function은 ES6(ECMAScript 2015)에서 추가된 새로운 함수 표현 방식입니다. 함수를 좀 더 간결하고 명확하게 표현할 수 있게 해주는 기능입니다.
+
+Arrow function은 => 기호로 표현되며, 함수를 정의하는 데에 사용됩니다. 일반적인 함수와 달리, this와 arguments의 바인딩 방식이 다르며, this가 lexical scope(정적 유효범위)를 가집니다.
 
 ## Quest
 * (Quest 03-1) 초보 프로그래머의 영원한 친구, 별찍기 프로그램입니다.
diff --git a/Quest03/skeleton/quest.html b/Quest03/skeleton/quest.html
index 546c53e13..7916d9c5b 100644
--- a/Quest03/skeleton/quest.html
+++ b/Quest03/skeleton/quest.html
@@ -42,6 +42,7 @@
 			for(let node of row2Squares) {
 				/* TODO: node 변수를 어떻게 조작해야 할까요? */
 			}
+			
 		</script>
 	</body>
 </html>

From af88038571c052d0e8431ac374c7d60856a75fc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Mon, 3 Apr 2023 15:47:58 +0900
Subject: [PATCH 08/29] =?UTF-8?q?=EC=88=98=EC=A0=95?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest02/Quest03/README.md           |  58 -------------------------
 Quest02/Quest03/jsStars.png         | Bin 1327 -> 0 bytes
 Quest02/Quest03/skeleton/quest.html |  65 ----------------------------
 3 files changed, 123 deletions(-)
 delete mode 100644 Quest02/Quest03/README.md
 delete mode 100644 Quest02/Quest03/jsStars.png
 delete mode 100644 Quest02/Quest03/skeleton/quest.html

diff --git a/Quest02/Quest03/README.md b/Quest02/Quest03/README.md
deleted file mode 100644
index abca00570..000000000
--- a/Quest02/Quest03/README.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Quest 03. 자바스크립트와 DOM
-
-## Introduction
-* 자바스크립트는 현재 웹 생태계의 근간인 프로그래밍 언어입니다. 이번 퀘스트에서는 자바스크립트의 기본적인 문법과, 자바스크립트를 통해 브라우저의 실제 DOM 노드를 조작하는 법에 대하여 알아볼 예정입니다.
-
-## Topics
-* 자바스크립트의 역사
-* 기본 자바스크립트 문법
-* DOM API
-  * `document` 객체
-  * `document.getElementById()`, `document.querySelector()`, `document.querySelectorAll()` 함수들
-  * 기타 DOM 조작을 위한 함수와 속성들
-* 변수의 스코프
-  * `var`, `let`, `const`
-
-## Resources
-* [자바스크립트 첫걸음](https://developer.mozilla.org/ko/docs/Learn/JavaScript/First_steps)
-* [자바스크립트 구성요소](https://developer.mozilla.org/ko/docs/Learn/JavaScript/Building_blocks)
-* [Just JavaScript](https://justjavascript.com/)
-
-## Checklist
-* 자바스크립트는 버전별로 어떻게 변화하고 발전해 왔을까요?
-
-자바스크립트(JavaScript)는 초기에는 웹 페이지의 동적인 기능을 구현하는 데 주로 사용되었습니다. 하지만 시간이 지남에 따라 자바스크립트는 웹 개발 분야에서 매우 중요한 언어로 자리 잡았습니다.
-
-  * 자바스크립트의 버전들을 가리키는 ES5, ES6, ES2016, ES2017 등은 무엇을 이야기할까요?
-  ES란 Ecma Script의 준말로 JavaScript명세서(표준,규격)를 의미함
-  ES5는 "use strict"선언을 추가하여 코드 실행을 엄격하게함
-  ES6는 클래스,모듈,템플릿 리터럴 등의 새로운 기능 추가.
-  ES2016은 includes(배열 내장 함수 EX.['a','b','c'].indexOf('a') > -1가 ['a', 'b', 'c'].includes('a') 처럼 간결해짐),Exponentiation operator추가(제곱 연산자 EX.Math와 pow함수 대신 ** 연산자로 가능)
-  ES2017은 문자 여백 기능,Object.values(),Object.entries(),Object.getOwnPropertyDescriptors(),Trailing commas,async/await(기존의 Promise보다 가독성이 좋은 코드 작성 가능) 추가
-  https://junhobaik.github.io/es2016-es2020/#objectgetownpropertydescriptors 자료 참조
-  
-  * 자바스크립트의 표준은 어떻게 제정될까요?
-* 자바스크립트의 문법은 다른 언어들과 비교해 어떤 특징이 있을까요?
-  * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?
-* 자바스크립트를 통해 DOM 객체에 CSS Class를 주거나 없애려면 어떻게 해야 하나요?
-  * IE9나 그 이전의 옛날 브라우저들에서는 어떻게 해야 하나요?
-* 자바스크립트의 변수가 유효한 범위는 어떻게 결정되나요?
-  * `var`과 `let`으로 변수를 정의하는 방법들은 어떻게 다르게 동작하나요?
-* 자바스크립트의 익명 함수는 무엇인가요?
-  * 자바스크립트의 Arrow function은 무엇일까요?
-
-## Quest
-* (Quest 03-1) 초보 프로그래머의 영원한 친구, 별찍기 프로그램입니다.
-  * [이 그림](jsStars.png)과 같이, 입력한 숫자만큼 삼각형 모양으로 콘솔에 별을 그리는 퀘스트 입니다.
-    * 줄 수를 입력받고 그 줄 수만큼 별을 그리면 됩니다. 위의 그림은 5를 입력받았을 때의 결과입니다.
-  * `if`와 `for`와 `function`을 다양하게 써서 프로그래밍 하면 더 좋은 코드가 나올 수 있을까요?
-  * 입력은 `prompt()` 함수를 통해 받을 수 있습니다.
-  * 출력은 `console.log()` 함수를 통해 할 수 있습니다.
-* (Quest 03-2) skeleton 디렉토리에 주어진 HTML을 조작하는 스크립트를 완성해 보세요.
-  * 첫째 줄에 있는 사각형의 박스들을 클릭할 때마다 배경색이 노란색↔흰색으로 토글되어야 합니다.
-  * 둘째 줄에 있는 사각형의 박스들을 클릭할 때마다 `enabled`라는 이름의 CSS Class가 클릭된 DOM 노드에 추가되거나 제거되어야 합니다.
-* 구현에는 여러 가지 방법이 있으나, 다른 곳은 건드리지 않고 TODO 부분만 고치는 방향으로 하시는 것을 권장해 드립니다.
-
-## Advanced
-* Quest 03-1의 코드를 더 구조화하고, 중복을 제거하고, 각각의 코드 블록이 한 가지 일을 전문적으로 잘하게 하려면 어떻게 해야 할까요?
-* Quest 03-2의 스켈레톤 코드에서 `let` 대신 `var`로 바뀐다면 어떤 식으로 구현할 수 있을까요?
diff --git a/Quest02/Quest03/jsStars.png b/Quest02/Quest03/jsStars.png
deleted file mode 100644
index 1eb5e9f82d7e9c402fa6196b733b76559f1284ec..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 1327
zcmeAS@N?(olHy`uVBq!ia0vp^89<!F!2~2Z-zPi(QjEnx?oJHr&dIz4a#+$GeH|GX
zHuiJ>Nn{17De#CaW?&Fg1z|?dAe9e5HAg&M978JN-p+ihU0f(}{Qds(+&|g>Fve9Z
z)HyHo_~@+MMIxRjm5e4Pc`AB4&zQJ7;>xE9?K1q*#{A#6|DJQr_j%0syQSM6r+@!i
zskr?8t)Fwx|Fk{v{rK(!PDcy{3w>N<gawbgfSDm8<+Zi8rlwzi{K$yW?sR$-7aza)
z;)|CrUw-^pSX%n^?c2BK?@Me<(olK#^l55N&YIP$v#Y9hEnCKBZ*65YZQ8V+2tyH}
z@87<)?G)o-yPH?;>DhVwv824by}iA8($N6FJ0Ct2L`O>>*}8pu^77q#_Lu+#Jz~se
z%SuXevM?<SIPtW|*T<(~@4cf(T{%qc77As(Eu84V((bG@amA`tmrQuooo(bmCV9m0
z{XIXi#3~o)%&tfKSe5!ZJCc<i&FHXD!_JIXe)scdWm(y`Cr^&-_{R}@O(W>3h3>l-
zFEY~8)#v(|o0}hh{BiZ_)gCHL{T(khxoy=to>_SN_U*ZI=T4qH+1J+>=(zXafxzC@
zR&mj3sjI7GmLJWWCC1nO@lR@MYH4X{ZEbCJb@ha%4!!J<)kXW<=A3`tY%%>bYhinP
zdwthtEs*FOvF#f-HZJWt85AGizqEa+m4(F&ucZPPQ+u;Q`z}A?<Kru^I1u9O?5rbp
z_~C{<d*+->0ZQ`Dwd%k8sHC9h+}X3LlRY2*QZ9*H>@oGT>7y<NSkxiKA_{Y|Q|IE>
zGY(BP?F+U1Deiv7uq12wn!<gjPVTo@)VDBrSKr3TVoiU#m0w9%EqyIvovElX#p1G6
zo8Q;==Tl8fqBuV3_pL~Nam6q4an01p^@T37&dX<%zuDC0$L;v<=*tVGJacbpX1_4$
z7x9X@sEjB4!LgF$edpAvQ~&<$EBq+93uwDFP`ldXlLZ!Y&ZhNdOBWo8jfrtt9B5PH
z?|=T!pFe;9+Va@h*t}TTl<KQC`5;GrUY?n`d31Di;m)mFQ@{GJt#480<A4A8r<=RG
zt(?Ds#GAKozyAI^YuQVX4y~zD5)ub2KF*vrP3+F~w`K3&y?dp}-)GUotS@kR?Vde*
zHf<8xzh>>)r_ZL`)6xjN_TabS?+5F)Z4>*>%fe)AY`oL_Y_mQeKYyX9sHi~u)$g8j
zf>L|+_`WyoxO6FK{q@}&HZ(k4v)snwkx(bgG-<cakG#CRiJT?n<;mgKf>}>Xz1hE^
zO}yvr(v2Gh%iX2Aj|yyj*kNsL9UU8cROE1S@~;O42Lym_`Vw+*6I;8ETgTzV+FIFm
zp=}{^gl??-I)&XmhEFGAwXRr{s7`i)`yKP`t8W~fw&TAf!5H7)5xsF;GQ&i>`oq9@
zvQO0OTbJCmX3fH2?K4L&mikNt#%osVPKz4xI3~3znZO7&=-|wcI(}j0J!y;hYZq3E
zPO-3=2NK^kD?bFpfA;8w)v^<(q~fL~L(O^^YWeI@QG%z?ZIy{mueWPwzxX0tFQ^`&
gh&2U#{P&OB=#8MB%Z~H|z(S6})78&qol`;+04~92OaK4?

diff --git a/Quest02/Quest03/skeleton/quest.html b/Quest02/Quest03/skeleton/quest.html
deleted file mode 100644
index 45853d381..000000000
--- a/Quest02/Quest03/skeleton/quest.html
+++ /dev/null
@@ -1,65 +0,0 @@
-<!DOCTYPE html>
-<html>
-	<head>
-		<meta charset="UTF-8">
-		<style>
-			.square {
-				width: 100px;
-				height: 100px;
-				border: 1px dashed black;
-				display: inline-block;
-				margin: 20px;
-			}
-
-			.enabled {
-				background-color: limegreen;
-				border: 1px solid black;
-			}
-		</style>
-	</head>
-	<body>
-		<section class="row1">
-			<div class="square"></div>
-			<div class="square"></div>
-			<div class="square"></div>
-			<div class="square"></div>
-		</section>
-
-		<section class="row2">
-			<div class="square"></div>
-			<div class="square"></div>
-			<div class="square"></div>
-			<div class="square"></div>
-		</section>
-
-		<script>
-			let row1Squares = document.querySelectorAll('.row1 .square');
-			for(let node of row1Squares) {
-				/* TODO: node 변수를 어떻게 조작해야 할까요? */
-			}
-
-			let row2Squares = document.querySelectorAll('.row2 .square');
-			for(let node of row2Squares) {
-				/* TODO: node 변수를 어떻게 조작해야 할까요? */
-			}
-			function drawTriangle() {
-  const num = prompt("숫자를 입력하세요:");
-
-  if (num < 1) {
-    console.log("1 이상의 숫자를 입력해주세요.");
-    return;
-  }
-
-  for (let i = 1; i <= num; i++) {
-    let stars = "";
-    for (let j = 1; j <= i; j++) {
-      stars += "*";
-    }
-    console.log(stars);
-  }
-}
-
-drawTriangle();
-		</script>
-	</body>
-</html>

From d0f943f1ed9f09be9a451dfd53d67f1e0c6be608 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Mon, 3 Apr 2023 16:23:47 +0900
Subject: [PATCH 09/29] =?UTF-8?q?Quest=20=EC=99=84=EB=A3=8C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest03/skeleton/quest.html | 56 ++++++++++++++++++++++++++++++-------
 1 file changed, 46 insertions(+), 10 deletions(-)

diff --git a/Quest03/skeleton/quest.html b/Quest03/skeleton/quest.html
index 7916d9c5b..61ff3929e 100644
--- a/Quest03/skeleton/quest.html
+++ b/Quest03/skeleton/quest.html
@@ -10,11 +10,14 @@
 				display: inline-block;
 				margin: 20px;
 			}
+			.yellow {
+			background-color: yellow;
+		    }
 
 			.enabled {
-				background-color: limegreen;
-				border: 1px solid black;
-			}
+			background-color: lightblue;
+			color: white;
+		    }
 		</style>
 	</head>
 	<body>
@@ -34,15 +37,48 @@
 
 		<script>
 			let row1Squares = document.querySelectorAll('.row1 .square');
-			for(let node of row1Squares) {
-				/* TODO: node 변수를 어떻게 조작해야 할까요? */
-			}
+		for (let node of row1Squares) {
+			node.addEventListener('click', function() {
+				/* 배경색 토글 */
+				if (this.style.backgroundColor === 'yellow') {
+					this.style.backgroundColor = 'white';
+				} else {
+					this.style.backgroundColor = 'yellow';
+				}
+			});
+		}
 
-			let row2Squares = document.querySelectorAll('.row2 .square');
-			for(let node of row2Squares) {
-				/* TODO: node 변수를 어떻게 조작해야 할까요? */
+		let row2Squares = document.querySelectorAll('.row2 .square');
+		for (let node of row2Squares) {
+			node.addEventListener('click', function() {
+				/* CSS 클래스 토글 */
+				if (this.classList.contains('enabled')) {
+					this.classList.remove('enabled');
+				} else {
+					this.classList.add('enabled');
+				}
+			});
+		}
+			function drawStars(num) {
+			var star = '';
+			for (var i = 1; i <= num; i++) {
+				star += ' '.repeat(num - i); // 각 줄의 시작부분에 공백 추가
+				star += '* '.repeat(i); // 별과 공백 번갈아가며 추가
+				star += '\n'; // 다음 줄로 넘어감
 			}
-			
+			console.log(star);
+		}
+
+		// 사용자로부터 입력받은 숫자로 정삼각형 별 그리기 실행
+		var num = prompt('몇 줄의 정삼각형 별을 그리시겠습니까?');
+		if (num > 0 && Number.isInteger(+num)) {
+			drawStars(+num);
+		} else {
+			console.log('양의 정수를 입력해주세요.');
+		}
+
+
+      
 		</script>
 	</body>
 </html>

From 217252a6277e4dc49dd4f30d6e10f7ec19a9d9b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Mon, 3 Apr 2023 17:45:17 +0900
Subject: [PATCH 10/29] =?UTF-8?q?CheckList=20=EC=A4=91=EA=B0=84=20?=
 =?UTF-8?q?=EC=A0=80=EC=9E=A5?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest04/README.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/Quest04/README.md b/Quest04/README.md
index c44fbb1c1..6ee515d21 100644
--- a/Quest04/README.md
+++ b/Quest04/README.md
@@ -24,12 +24,67 @@
 
 ## Checklist
 * 객체지향 프로그래밍은 무엇일까요?
+객체지향 프로그래밍(Object-Oriented Programming, OOP)은 프로그램을 여러 개의 독립된 객체(Object)로 나누고, 이러한 객체들간의 상호작용을 통해 프로그래밍 하는 방법론입니다. 객체는 속성(Attribute)와 메서드(Method)로 이루어져 있으며, 속성은 객체의 상태를 나타내고, 메서드는 객체가 수행할 수 있는 행동을 나타냅니다. 이러한 객체들은 클래스(Class)라는 틀을 이용해 생성됩니다.
+
+객체지향 프로그래밍의 핵심 개념으로는 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism)이 있습니다. 캡슐화는 객체의 속성과 메서드를 외부로부터 보호하기 위해 사용되며, 상속은 부모 클래스의 속성과 메서드를 자식 클래스에서 재사용하는 것을 말하며, 다형성은 객체지향에서 한 객체가 다른 객체와 다르게 동작할 수 있는 능력을 말합니다.
+
+객체지향 프로그래밍은 모듈성과 재사용성이 높으며, 대규모 프로그램을 개발하는데 매우 유용합니다. 또한, 객체 간의 의존성을 줄이기 때문에 유지보수와 개발이 용이하며, 소프트웨어 개발 생산성과 품질을 향상시킬 수 있습니다.
+
+https://www.codestates.com/blog/content/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%ED%8A%B9%EC%A7%95 참조
+
   * `#`로 시작하는 프라이빗 필드는 왜 필요한 것일까요? 정보를 은폐(encapsulation)하면 어떤 장점이 있을까요?
+
+#로 시작하는 프라이빗 필드(Private Field)는 해당 필드를 클래스 외부에서 접근할 수 없도록 접근 제어를 하는 것을 말합니다. 이는 정보 은폐(Encapsulation)의 한 예로, 클래스 내부의 데이터와 동작을 외부로부터 보호하기 위해 사용됩니다.
+
+정보 은폐는 객체지향 프로그래밍의 핵심 개념 중 하나로, 객체 내부의 구현 상세를 외부로부터 숨기고, 필요한 기능만을 외부로 노출함으로써 객체의 안정성과 유지보수성을 높이는 데 큰 역할을 합니다.
+
+정보 은폐가 제공하는 장점으로는 다음과 같은 것들이 있습니다.
+
+객체의 안정성과 유지보수성 향상: 클래스 외부에서 접근할 수 없는 정보를 은폐함으로써 객체의 안정성과 유지보수성을 높일 수 있습니다.
+
+코드의 재사용성 향상: 정보 은폐는 객체의 내부 구현 상세를 감추고, 외부에 제공하는 인터페이스만을 노출시키기 때문에, 코드의 재사용성을 높일 수 있습니다.
+
+유연성과 확장성: 정보 은폐를 통해 객체의 내부 구현 상세를 숨기면, 내부 구현 상세가 변경되어도 외부 인터페이스는 변경되지 않습니다. 이는 유연성과 확장성을 높일 수 있습니다.
+
+따라서, #로 시작하는 프라이빗 필드를 사용하여 정보 은폐를 구현함으로써, 안정성과 유지보수성을 높이고, 코드의 재사용성과 유연성, 확장성을 향상시킬 수 있습니다.
+
   * 다형성이란 무엇인가요? 다형성은 어떻게 코드 구조의 정리를 도와주나요?
+  다형성(polymorphism)은 객체지향 프로그래밍의 중요한 특징 중 하나로, 같은 코드가 다른 타입의 객체에 대해서 다른 방식으로 동작할 수 있는 능력을 의미합니다. 즉, 다형성은 같은 이름의 메서드나 연산자가 다른 객체에서 서로 다른 방식으로 작동할 수 있도록 함으로써 객체의 타입에 종속되지 않는 코드를 작성할 수 있게 합니다.
+  다형성은 코드 구조의 정리를 도와줍니다. 예를 들어, 상속 관계에 있는 클래스들이 같은 메서드를 구현하지만 각각의 클래스에서 메서드가 다르게 동작하는 경우, 부모 클래스에 공통된 메서드를 작성하고 자식 클래스에서 메서드를 오버라이딩(override)함으로써 코드 중복을 제거할 수 있습니다. 또한, 인터페이스를 사용하여 다형성을 구현하면 인터페이스를 구현하는 다양한 클래스에서 동일한 메서드를 구현함으로써 코드의 재사용성을 높일 수 있습니다.
+  다형성은 또한 유지보수성을 향상시키는데도 도움이 됩니다. 만약 새로운 객체 타입이 추가될 경우, 해당 객체의 메서드를 구현하면 기존의 코드를 수정하지 않고도 새로운 타입에 대한 지원이 가능합니다. 이는 객체 지향 프로그래밍에서 개방-폐쇄 원칙(Open-Closed Principle)을 준수하는 것에도 도움이 됩니다.
+
   * 상속이란 무엇인가요? 상속을 할 때의 장점과 단점은 무엇인가요?
+상속(Inheritance)이란 객체 지향 프로그래밍에서 기존의 클래스를 재사용하여 새로운 클래스를 작성하는 것을 말합니다. 새로운 클래스는 상속받은 클래스의 특징을 그대로 가지면서 새로운 특성을 추가하거나 기존 특성을 변경할 수 있습니다.
+
+상속의 장점
+
+코드 재사용성이 높아진다: 상속을 통해 기존 클래스를 재사용할 수 있기 때문에 코드의 중복을 피하고 코드의 재사용성이 높아집니다.
+코드의 확장성이 높아진다: 상속을 통해 새로운 클래스를 만들 때 기존 클래스의 기능을 유지하면서 새로운 기능을 추가할 수 있기 때문에 코드의 확장성이 높아집니다.
+유지보수가 용이해진다: 기존 클래스의 수정이 필요한 경우, 상속을 받은 클래스에서만 수정하면 되기 때문에 유지보수가 용이해집니다.
+
+상속의 단점
+
+상속 구조가 복잡해진다: 클래스 간의 상속 구조가 복잡해지면 코드의 가독성이 떨어지고, 코드의 이해와 디버깅이 어려워집니다.
+상위 클래스의 변경이 하위 클래스에 영향을 미칠 수 있다: 상위 클래스의 변경이 하위 클래스에 영향을 미칠 수 있기 때문에, 상위 클래스를 변경할 경우 하위 클래스를 일일이 검토해야 하는 번거로움이 있습니다.
+상속 관계가 많아질수록 설계가 복잡해진다: 상속 관계가 많아질수록 설계가 복잡해지고 유지보수가 어려워집니다. 이를 해결하기 위해서는 상속보다는 인터페이스를 활용하는 것이 더 적합할 수 있습니다.
+
   * OOP의 합성(Composition)이란 무엇인가요? 합성이 상속에 비해 가지는 장점은 무엇일까요?
+  OOP에서 합성(Composition)은 객체가 다른 객체를 포함하는 것을 의미합니다. 즉, 객체가 다른 객체를 조립하여 새로운 기능을 제공하거나, 객체 간의 관계를 형성하는 것입니다.
+
+  합성은 상속과는 다른 객체 간의 관계를 형성하는 방법입니다. 상속은 is-a 관계를 형성하는 반면, 합성은 has-a 관계를 형성합니다. 예를 들어, 자동차는 엔진을 가지고 있으므로 자동차와 엔진은 합성 관계입니다. 이러한 관계를 코드에서는 클래스 간의 객체를 생성하거나 메소드를 호출하는 방식으로 구현할 수 있습니다.
+  
+  합성의 장점은 상속과 비교하여 더 유연하고 확장성이 높다는 것입니다. 상속은 부모 클래스의 변경이 자식 클래스에 영향을 미치며, 하위 클래스에서 재정의한 메서드가 상위 클래스에서 변경되면 예상치 못한 결과를 초래할 수 있습니다. 하지만 합성은 객체를 조립하여 기능을 확장하기 때문에 변경이 발생해도 영향이 덜하며, 객체 간의 결합도를 낮출 수 있습니다. 또한 합성을 이용하면 코드 재사용성도 높아집니다.
+
 * 자바스크립트의 클래스는 어떻게 정의할까요?
+JavaScript에서 클래스를 정의하는 방법은 ES6(ES2015)에서 추가된 class 키워드를 사용하는 것입니다. 클래스는 객체를 생성하기 위한 템플릿으로서, 속성과 메소드를 정의할 수 있습니다.
+
   * 프로토타입 기반의 객체지향 프로그래밍은 무엇일까요?
+  프로토타입 기반의 객체지향 프로그래밍(Prototype-based Object-Oriented Programming)은 클래스(class)가 없는 객체지향 프로그래밍 패러다임입니다. 대신, 객체(object)를 직접 생성하거나 다른 객체를 복제하여 새로운 객체를 만듭니다. 이러한 객체를 프로토타입(prototype)이라고 부릅니다.
+  
+  객체는 다른 객체를 상속받아 새로운 기능을 추가할 수 있으며, 객체는 객체를 생성할 때 프로토타입을 지정할 수 있습니다. 이를 통해 객체들은 프로토타입의 속성과 메서드를 상속받아 사용할 수 있습니다.
+  
+  JavaScript는 프로토타입 기반의 객체지향 프로그래밍을 기본적으로 지원합니다. 다른 언어들 역시 이러한 패러다임을 지원하며, 프로토타입 기반의 객체지향 프로그래밍은 함수형 프로그래밍과 함께 최근에는 인기 있는 프로그래밍 패러다임 중 하나입니다.
+
   * 자바스크립트의 클래스는 이전의 프로토타입 기반의 객체지향 구현과 어떤 관계를 가지고 있나요?
 
 ## Quest

From 91892597ad72ec96740d704f2f6aa98abad16c47 Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Tue, 4 Apr 2023 15:05:13 +0900
Subject: [PATCH 11/29] =?UTF-8?q?CheckList=20=EC=99=84?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest03/README.md             | 58 +++++++++--------------------------
 Quest04/README.md             |  5 +++
 Quest04/skeleton/desktop.css  | 46 +++++++++++++++++++++++++++
 Quest04/skeleton/desktop.html |  4 ++-
 Quest04/skeleton/desktop.js   |  1 +
 Quest05/README.md             | 49 +++++++++++++++++++++++++++++
 6 files changed, 119 insertions(+), 44 deletions(-)

diff --git a/Quest03/README.md b/Quest03/README.md
index 23ad7a3ba..fe09710e1 100644
--- a/Quest03/README.md
+++ b/Quest03/README.md
@@ -30,59 +30,31 @@
   ES2016은 includes(배열 내장 함수 EX.['a','b','c'].indexOf('a') > -1가 ['a', 'b', 'c'].includes('a') 처럼 간결해짐),Exponentiation operator추가(제곱 연산자 EX.Math와 pow함수 대신 ** 연산자로 가능)
   ES2017은 문자 여백 기능,Object.values(),Object.entries(),Object.getOwnPropertyDescriptors(),Trailing commas,async/await(기존의 Promise보다 가독성이 좋은 코드 작성 가능) 추가
   https://junhobaik.github.io/es2016-es2020/#objectgetownpropertydescriptors 자료 참조
-  
-  * 자바스크립트의 표준은 어떻게 제정될까요?
-  자바스크립트의 표준은 Ecma International이라는 국제 표준화 기구에서 관리됩니다.
-
-Ecma International은 다양한 프로그래밍 언어의 표준을 제정하는 비영리 표준화 기구 중 하나입니다. Ecma International은 자바스크립트 표준을 제정하기 위해 Technical Committee 39 (TC39)이라는 특별위원회를 운영하고 있습니다.
-
-TC39은 자바스크립트 언어의 발전과 향후 버전의 표준 제정을 위해 회의를 진행하고 논의하며, 새로운 기능이나 구문을 추가하거나 변경하는 등의 작업을 수행합니다. TC39에서 결정된 내용은 Ecma International의 공식 문서인 ECMA-262 표준 문서로 반영됩니다.
 
-ECMA-262는 자바스크립트 언어의 표준 사양을 정의하는 문서이며, 최초 버전인 ECMAScript 1부터 최신 버전인 ECMAScript 2022까지 총 12개의 버전이 존재합니다. 자바스크립트 엔진은 이 표준 사양을 준수하여 구현됩니다.
+  * 자바스크립트의 표준은 어떻게 제정될까요?
+  ECMA International에서는 ECMAScript라는 이름으로 자바스크립트의 표준을 제정합니다. 
+  ECMAScript는 자바스크립트를 포함하는 스크립트 언어의 표준 규격을 의미하며, 현재까지 ECMAScript 2022(ES12)까지 발표되었습니다.
+  ECMAScript 표준은 TC39(Technical Committee 39)이라는 위원회에서 제정됩니다. 
+  TC39 위원회는 ECMAScript의 표준을 개발, 유지 보수하고 향상시키는 데 중점을 둡니다. 
+  이 위원회는 모집적인 방식으로 구성되어 있으며, 인터넷 엔진 개발자, 브라우저 개발자, 프로그래밍 언어 전문가 등이 참여합니다.
+  ECMAScript 표준은 모든 브라우저에서 일관성 있게 자바스크립트를 구현할 수 있도록 합니다. 
+  따라서 개발자들은 ECMAScript 표준에 맞게 자바스크립트 코드를 작성하여, 모든 브라우저에서 동일한 결과를 얻을 수 있습니다.
 
 * 자바스크립트의 문법은 다른 언어들과 비교해 어떤 특징이 있을까요?
-객체기반언어
-동적 타이핑
-클로저(함수가 호출될 때마다 함수 내부에 새로운 스코프(scope)가 생성, 내부함수에서 외부 함수의 변수를 참조시 해당 변수를 계속해서 참조가능 이것이 클로저(closure).스코프 체인(scope chain)으로 표현되기도 함.)
+1.객체 기반 언어
+2.함수형 언어
+3.동적 타입 언어
+4.프로토타입 기반 언어
+5.세미콜론 생략 가능
+6.Hoisting
 
   * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?
-  for문: 가장 기본적인 반복문으로, 정해진 횟수만큼 반복합니다.
-  while문: 조건식이 참일 때 계속 반복합니다.
-  do-while문: while문과 유사하지만, 조건식을 맨 뒤에 작성합니다. 이 경우, 조건식이 참일 때 실행이 되는 최소한 한 번은 실행됩니다.
-  for...in문: 객체의 속성을 반복해서 순회합니다.
-  for...of문: 배열의 요소를 반복해서 순회합니다.
-  forEach() 메서드: 배열의 요소를 반복해서 순회합니다. for...of문과 유사하지만, 각 요소에 대해 콜백 함수를 실행하는 방식으로 작동합니다.
-  map() 메서드: 배열의 요소를 반복해서 순회하며, 각 요소에 대해 변환 작업을 수행합니다. 변환 작업을 마친 새로운 배열을 반환합니다.
-  filter() 메서드: 배열의 요소를 반복해서 순회하며, 각 요소에 대해 조건식을 적용합니다. 조건식을 만족하는 요소만 모아서 새로운 배열을 반환합니다.
-  reduce() 메서드: 배열의 요소를 반복해서 순회하며, 각 요소를 하나의 값으로 줄여나가는 작업을 수행합니다. 최종적으로 하나의 값을 반환합니다.
-
 * 자바스크립트를 통해 DOM 객체에 CSS Class를 주거나 없애려면 어떻게 해야 하나요?
-classList 프로퍼티와 add(), remove(), toggle() 메서드를 사용합니다.
-
   * IE9나 그 이전의 옛날 브라우저들에서는 어떻게 해야 하나요?
-  폴리필(Polyfill) 사용하기
-  폴리필은 구형 브라우저에서 최신 웹 기술을 사용할 수 있도록 지원하는 코드.
-  기능 점진적 향상(Progressive Enhancement) 적용하기
-  브라우저 업그레이드 유도하기
-
 * 자바스크립트의 변수가 유효한 범위는 어떻게 결정되나요?
-전역 범위(Global Scope)
-함수 바깥에서 선언된 변수
-지역 범위/함수 범위(Local Scope/Function Scope)
-함수 내에서 선언된 변수
-블록 범위(Block Scope)
-ES6부터 도입된 let와 const키워드로 선언된 변수
   * `var`과 `let`으로 변수를 정의하는 방법들은 어떻게 다르게 동작하나요?
-  'var'변수는 선언 위치에 따라 범위가 다른데 함수 외부에서 선언될 때는 전역,내에서는 함수 범위
-  'let'는 블록 범위이며 변수가 선언된 중괄호{}내 에서만 접근이 가능합니다.
-
 * 자바스크립트의 익명 함수는 무엇인가요?
-일반적으로 익명 함수는 즉시 실행 함수(IIFE, Immediately Invoked Function Expression)로 사용됩니다. 즉시 실행 함수는 함수 정의와 동시에 호출되는 함수로, 한 번만 실행되는 코드 블록을 생성하는 데 사용됩니다. 이는 전역 스코프의 오염을 방지하고, 모듈화를 위한 네임스페이스로 사용됩니다.
-
   * 자바스크립트의 Arrow function은 무엇일까요?
-  Arrow function은 ES6(ECMAScript 2015)에서 추가된 새로운 함수 표현 방식입니다. 함수를 좀 더 간결하고 명확하게 표현할 수 있게 해주는 기능입니다.
-
-Arrow function은 => 기호로 표현되며, 함수를 정의하는 데에 사용됩니다. 일반적인 함수와 달리, this와 arguments의 바인딩 방식이 다르며, this가 lexical scope(정적 유효범위)를 가집니다.
 
 ## Quest
 * (Quest 03-1) 초보 프로그래머의 영원한 친구, 별찍기 프로그램입니다.
@@ -92,7 +64,7 @@ Arrow function은 => 기호로 표현되며, 함수를 정의하는 데에 사
   * 입력은 `prompt()` 함수를 통해 받을 수 있습니다.
   * 출력은 `console.log()` 함수를 통해 할 수 있습니다.
 * (Quest 03-2) skeleton 디렉토리에 주어진 HTML을 조작하는 스크립트를 완성해 보세요.
-  * 첫째 줄에 있는 사각형의 박스들을 클릭할 때마다 배경색이 노란색↔흰색으로 토글되어야 합니다.
+  * 첫째 줄에 있는 사각형의 박스들을 클릭할 때마다 배경색이 노란색↔흰색으로git 토글되어야 합니다.
   * 둘째 줄에 있는 사각형의 박스들을 클릭할 때마다 `enabled`라는 이름의 CSS Class가 클릭된 DOM 노드에 추가되거나 제거되어야 합니다.
 * 구현에는 여러 가지 방법이 있으나, 다른 곳은 건드리지 않고 TODO 부분만 고치는 방향으로 하시는 것을 권장해 드립니다.
 
diff --git a/Quest04/README.md b/Quest04/README.md
index 6ee515d21..f675f89fe 100644
--- a/Quest04/README.md
+++ b/Quest04/README.md
@@ -86,6 +86,11 @@ JavaScript에서 클래스를 정의하는 방법은 ES6(ES2015)에서 추가된
   JavaScript는 프로토타입 기반의 객체지향 프로그래밍을 기본적으로 지원합니다. 다른 언어들 역시 이러한 패러다임을 지원하며, 프로토타입 기반의 객체지향 프로그래밍은 함수형 프로그래밍과 함께 최근에는 인기 있는 프로그래밍 패러다임 중 하나입니다.
 
   * 자바스크립트의 클래스는 이전의 프로토타입 기반의 객체지향 구현과 어떤 관계를 가지고 있나요?
+  자바스크립트의 클래스는 이전에 존재하던 프로토타입 기반의 객체지향 구현과 밀접한 관계를 가지고 있습니다. 클래스는 ES6(ECMAScript 2015)부터 새롭게 도입된 개념 중 하나로, 이전에는 프로토타입을 사용하여 객체를 생성하고 상속을 구현했었습니다.
+  
+  클래스는 생성자 함수와 프로토타입을 사용하여 객체를 생성하고 상속을 구현하는 것과 유사합니다. 클래스 내부에서 생성자 함수를 정의하고, 프로토타입 객체를 사용하여 메서드를 구현할 수 있습니다. 또한, 클래스 내부에서 상속을 구현할 수 있으며, 상속 관계를 형성하는 것도 이전과 동일합니다.
+  
+  하지만 클래스는 프로토타입 기반의 객체지향 구현과 달리, 클래스와 인스턴스를 명확하게 구분하고, 클래스 내부에서만 사용할 수 있는 private한 변수나 메서드를 구현할 수 있습니다. 또한, 클래스는 상속 구현 방식이 간단하고 직관적이어서, 이전의 프로토타입 기반 구현보다 코드의 가독성과 유지보수성을 높일 수 있습니다.
 
 ## Quest
 * 웹 상에서 동작하는 간단한 바탕화면 시스템을 만들 예정입니다.
diff --git a/Quest04/skeleton/desktop.css b/Quest04/skeleton/desktop.css
index 9ff365d6d..2f118d6ac 100644
--- a/Quest04/skeleton/desktop.css
+++ b/Quest04/skeleton/desktop.css
@@ -1 +1,47 @@
 /* TODO: 자유롭게 바탕화면 시스템의 CSS를 만들어 보세요! */
+#desktop {
+    width: 800px;
+    height: 600px;
+    background-color: #d9d9d9;
+    border: 1px solid #999;
+    position: relative;
+    margin: 50px auto;
+  }
+  
+  .icon {
+    width: 50px;
+    height: 50px;
+    background-color: #fff;
+    border: 1px solid #000;
+    position: absolute;
+    cursor: move;
+    z-index: 1;
+  }
+  
+  .folder-icon {
+    background-color: #ffa500;
+  }
+  
+  .folder-window {
+    width: 200px;
+    height: 150px;
+    background-color: #fff;
+    border: 1px solid #000;
+    position: absolute;
+    cursor: move;
+    z-index: 2;
+    display: none;
+  }
+  
+  .folder-window .title-bar {
+    width: 100%;
+    height: 20px;
+    background-color: #ffa500;
+    cursor: move;
+  }
+  
+  .folder-window .content {
+    width: 100%;
+    height: 130px;
+    padding: 10px;
+  }
\ No newline at end of file
diff --git a/Quest04/skeleton/desktop.html b/Quest04/skeleton/desktop.html
index e2fb160bb..50e0584a4 100644
--- a/Quest04/skeleton/desktop.html
+++ b/Quest04/skeleton/desktop.html
@@ -8,11 +8,13 @@
 	<body>
 		<section class="desktop">
 		</section>
-
+		div id="desktop"></div>
+        <script src="desktop.js"></script>
 		<script>
 			let myDesktop = new Desktop(
 				/* TODO: myDesktop 인스턴스의 생성자의 변수로 무엇이 들어가야 할까요? */
 			);
+			
 		</script>
 	</body>
 </html>
diff --git a/Quest04/skeleton/desktop.js b/Quest04/skeleton/desktop.js
index 210268fb0..7f145c210 100644
--- a/Quest04/skeleton/desktop.js
+++ b/Quest04/skeleton/desktop.js
@@ -1,5 +1,6 @@
 class Desktop {
 	/* TODO: Desktop 클래스는 어떤 멤버함수와 멤버변수를 가져야 할까요? */
+	
 };
 
 class Icon {
diff --git a/Quest05/README.md b/Quest05/README.md
index f55779419..61f5924da 100644
--- a/Quest05/README.md
+++ b/Quest05/README.md
@@ -17,8 +17,57 @@
 
 ## Checklist
 * 관심사의 분리 원칙이란 무엇인가요? 웹에서는 이러한 원칙이 어떻게 적용되나요?
+관심사의 분리(Separation of Concerns, SoC) 원칙은 소프트웨어 설계의 일반적인 원칙 중 하나로, 각각의 컴포넌트나 모듈이 자신의 역할에 집중하고, 다른 컴포넌트와 가능한 적은 결합도를 가지도록 설계하는 것입니다. 즉, 서로 다른 관심사를 가진 부분들을 서로 분리하여 각 부분을 독립적으로 변경할 수 있도록 만드는 것입니다.
+
+웹에서는 관심사의 분리 원칙을 다양한 방식으로 적용할 수 있습니다. 예를 들어, HTML은 문서의 구조를 정의하고, CSS는 문서의 스타일을 지정하며, JavaScript는 문서의 동작을 구현하는 등 각각의 역할에 맞추어 분리되어 있습니다. 또한, MVC(Model-View-Controller) 패턴을 적용하여, 데이터 모델, UI, 비즈니스 로직 등 서로 다른 관심사를 분리하여 개발할 수 있습니다. 또한, 모듈화를 통해 코드를 관심사 단위로 분리하여 유지보수성을 향상시킬 수 있습니다. 이러한 방식으로 웹에서 관심사의 분리 원칙을 적용하면 코드의 가독성과 유지보수성을 향상시킬 수 있습니다.
+
 * 객체지향의 SOLID 원칙이란 무엇인가요? 이 원칙을 구체적인 예를 들어 설명할 수 있나요?
+S (SRP: Single Responsibility Principle) : 단일 책임 원칙
+O (OCP: Open/Closed Principle) : 개방-폐쇄 원칙
+L (LSP: Liskov Substitution Principle) : 리스코프 치환 원칙
+I (ISP: Interface Segregation Principle) : 인터페이스 분리 원칙
+D (DIP: Dependency Inversion Principle) : 의존성 역전 원칙
+단일 책임 원칙의 예: 하나의 클래스는 하나의 책임(기능)만 가져야 한다는 원칙.
+Because 하나의 클래스에 여러가지 기능들을 넣을 시 업데이트가 필요할 때 이미 여러곳에서 그 클래스를 사용하고 있다면 예기치 않은 오류가 발생 할 수 있음.
+각각의 클래스가 단순하고 응집력 있게 유지되어 유지보수성 기능 향상됨.
+https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-SRP-%EB%8B%A8%EC%9D%BC-%EC%B1%85%EC%9E%84-%EC%9B%90%EC%B9%99 참조
+
+개방-폐쇄의 원칙의 예:기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계
+OCP를 확장에 대해서는 개방적(open)이고, 수정에 대해서는 폐쇄적(closed)이어야 한다는 의미.
+https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-OCP-%EA%B0%9C%EB%B0%A9-%ED%8F%90%EC%87%84-%EC%9B%90%EC%B9%99 참조
+
+리스코프 치원 원칙의 예: 서브타입은 언제나 기반 타입으로 교체할 수 있어야한다.
+교체할 수 있다는 말은,자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행이 보장되어야 한다는 뜻.
+부모 클래스의 인스턴스를 사용하는 위치에 자식 클래스의 인스턴스를 대신 사용했을 때 코드가 원래 의도대로 작동해야 한다는 의미.
+LSP 원칙 위반은 자식 클래스가 오버라이딩을 할 때, 잘못되게 재정의 하면 LSP 원칙을 위배할 수 있다는 의미.
+자식 클래스가 오버라이딩을 잘못하는 경우는 크게 2가지로 나뉜다.
+1.부모의 의도와 다르게 메소드 오버라이딩
+2.잘못된 상속 관계 구성으로 인한 메서드 정의
+https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-LSP-%EB%A6%AC%EC%8A%A4%EC%BD%94%ED%94%84-%EC%B9%98%ED%99%98-%EC%9B%90%EC%B9%99 참조
+
+인터페이스 분리 원칙의 예:인터페이스를 사용에 맞게 끔 각기 분리해야한다는 원칙.
+인터페이스를 잘게 분리함으로써 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공.
+SRP와 거의 유사하다고 보면 된다. SRP는 클래스의 단일 책임이면 ISP는 인터페이스의 단일 책임 강조.
+인터페이스를 분리하는 기준은 상황에 따라 다르다. 핵심은 관련 있는 기능끼리 하나의 인터페이스에 모으되 지나치게 커지지 않게 크기를 제한하라는 점.
+주의 할 점. 한번 인터페이스를 분리하여 구성해놓고 나중에 수정사항이 생겨 또 인터페이스를 분리하는 행위는 X.
+인터페이스는 한번 구성하였으면 왠만해선 변하면 안되는 정책같은 개념.
+https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-ISP-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4-%EB%B6%84%EB%A6%AC-%EC%9B%90%EC%B9%99 참조
+
+의존성 역천 원칙의 예: 대상의 상위 요소(추상 클래스 or 인터페이스)로 참조하라는 원칙.
+객체들이 서로 정보를 주고 받을 떄는 의존 관계가 형성되는데, 이 때 객체들은 나름대로의 원칙을 갖고 정보를 주고 받아야하는 약속이 있다. 나름대로의 원칙이란 추상성이 낮은 클래스보다 추상성이 높은 클래스와 통신을 한다는것을 의미 이것이 DIP 원칙.
+왜 그렇게 하느냐? 하위 모듈에 구체적인 내용에 클라이언트가 의존시 하위 모듈에 변화가 있을 떄마다 클라이언트나 상위 모듈의 코드를 자주 수정해야하기 때문.
+한마디로 정의시 "상위의 인터페이스 타입의 객체로 통신".
+DIP 원칙 위반 예제
+게임을 예로 들면 여러가지 무기들을 장착하는 캐릭터가 있는데, 캐릭터 클래스가 인스턴스화 될 때에 캐릭터 이름과 체력 그리고 장착하는 무기를 입력값으로 받아 초기화하고 캐릭터 클래스내에 필드 변수로서 클래스탑의 변수를 저장해놓고, 공격 매서드를 수행하면 무기 클래스의 메서드가 실행되어 데미지가 가하는 형태.
+즉, 캐릭터 인스턴스 생성 시 무기종류에 의존성을 가지게되어, 공격 메소드 역시 무기 종류에 의존성을 가지게 된다.
+https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-DIP-%EC%9D%98%EC%A1%B4-%EC%97%AD%EC%A0%84-%EC%9B%90%EC%B9%99 참조
+
 * 로컬 스토리지란 무엇인가요? 로컬 스토리지의 내용을 개발자 도구를 이용해 확인하려면 어떻게 해야 할까요?
+로컬 스토리지(Local Storage)는 HTML5에서 제공하는 웹 브라우저의 저장소입니다. 로컬 스토리지는 사용자가 웹 페이지를 방문하면 해당 웹 사이트에서 저장한 데이터를 브라우저에 저장할 수 있게 해줍니다.
+
+로컬 스토리지는 세션 스토리지(Session Storage)와 마찬가지로 키-값 쌍으로 데이터를 저장합니다. 하지만 세션 스토리지는 브라우저 세션이 종료되면 데이터가 삭제되지만, 로컬 스토리지는 사용자가 명시적으로 데이터를 삭제하지 않는 한 영구적으로 데이터를 보존합니다.
+
+로컬 스토리지의 내용을 개발자 도구를 이용해 확인하려면 브라우저의 개발자 도구를 열고, Application 탭으로 이동해야 합니다. 그리고 왼쪽 패널에서 Storage 항목을 선택하면 로컬 스토리지의 내용을 확인할 수 있습니다. 각 웹 사이트마다 로컬 스토리지에 저장한 데이터가 분리되어 저장되므로, 왼쪽 패널에서 해당 웹 사이트의 도메인을 선택해야 합니다. 선택한 도메인의 오른쪽 패널에서 로컬 스토리지에 저장된 키-값 쌍의 목록과 값을 확인할 수 있습니다. 또한 개발자 도구 콘솔에서도 로컬 스토리지의 내용을 확인하고 조작할 수 있습니다.
 
 ## Quest
 * 외부 라이브러리나 프레임워크를 사용하지 않고, 자바스크립트를 이용하여 간단한 웹브라우저 기반의 텍스트 에디터를 만들어 보겠습니다.

From 3527b0a9795861dcd64d1bcedfa28078f691eba2 Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Tue, 4 Apr 2023 17:40:22 +0900
Subject: [PATCH 12/29] Quest 03 Clear

---
 Quest03/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Quest03/README.md b/Quest03/README.md
index fe09710e1..7cd27da9c 100644
--- a/Quest03/README.md
+++ b/Quest03/README.md
@@ -51,7 +51,7 @@
   * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?
 * 자바스크립트를 통해 DOM 객체에 CSS Class를 주거나 없애려면 어떻게 해야 하나요?
   * IE9나 그 이전의 옛날 브라우저들에서는 어떻게 해야 하나요?
-* 자바스크립트의 변수가 유효한 범위는 어떻게 결정되나요?
+* 자바스크립트의 변수가 유효한 범위는 어떻게 결정되나요?g
   * `var`과 `let`으로 변수를 정의하는 방법들은 어떻게 다르게 동작하나요?
 * 자바스크립트의 익명 함수는 무엇인가요?
   * 자바스크립트의 Arrow function은 무엇일까요?

From e11115296a56419439ecdfb57de9a5de2d5300b3 Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Tue, 4 Apr 2023 17:55:05 +0900
Subject: [PATCH 13/29] CheckList Clear

---
 Quest06/README.md | 62 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/Quest06/README.md b/Quest06/README.md
index a518bd8f2..f6128dcca 100644
--- a/Quest06/README.md
+++ b/Quest06/README.md
@@ -24,13 +24,75 @@
 
 ## Checklist
 * 인터넷은 어떻게 동작하나요? Internet Protocol Suite의 레이어 모델에 입각하여 설명해 보세요.
+
+인터넷은 컴퓨터 네트워크들이 상호 연결되어 정보를 주고 받을 수 있도록 하는 글로벌한 네트워크입니다. 인터넷 프로토콜 스위트(Internet Protocol Suite)은 이러한 인터넷을 운영하기 위한 일련의 프로토콜과 규칙들의 집합입니다. 인터넷 프로토콜 스위트는 OSI 7계층 모델과 유사한 레이어 모델을 사용하며, 이는 데이터 통신을 위한 다양한 프로토콜을 계층별로 분리하여 설명하는 방식입니다.
+
+인터넷 프로토콜 스위트의 레이어 모델은 다음과 같습니다.
+
+물리 계층 (Physical layer) - 데이터를 전기적 신호로 변환하여 네트워크를 통해 전송하는 계층입니다.
+
+데이터 링크 계층 (Data Link layer) - 물리적인 매체를 통해 전송된 데이터를 인식하고, 오류 검출 및 복구를 수행하는 계층입니다. 예를 들어 이더넷 프로토콜이 이 계층에서 사용됩니다.
+
+네트워크 계층 (Network layer) - 데이터를 라우터를 통해 다른 네트워크로 전송하는 계층입니다. 이 계층에서는 IP 프로토콜이 사용됩니다.
+
+전송 계층 (Transport layer) - 애플리케이션 계층에서 전송되는 데이터를 송수신하는 호스트 간의 연결을 제어하는 계층입니다. TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol) 프로토콜이 이 계층에서 사용됩니다.
+
+세션 계층 (Session layer) - 네트워크에서 연결된 두 컴퓨터 간의 통신을 설정하고 유지하는 계층입니다.
+
+표현 계층 (Presentation layer) - 애플리케이션 계층에서 사용되는 데이터의 표현 방식을 정의하는 계층입니다. 예를 들어, MIME(Multipurpose Internet Mail Extensions)은 이 계층에서 사용됩니다.
+
+애플리케이션 계층 (Application layer) - 사용자가 사용하는 애플리케이션에서 사용되는 프로토콜을 정의하는 계층입니다. 예를 들어, HTTP(Hypertext Transfer Protocol)는 웹 브라우저와 웹 서버 간의 통신을 위해 이 계층에서 사용됩니다.
+
   * 근거리에서 서로 떨어진 두 전자기기가 유선/무선으로 서로 통신하는 프로토콜은 어떻게 동작할까요?
+
+  근거리에서 서로 떨어진 두 전자기기가 유선 또는 무선으로 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요합니다.
+  유선 통신의 경우, 일반적으로 Ethernet이나 USB 등의 케이블을 사용하여 두 기기를 연결합니다. 연결된 두 기기는 데이터 링크 계층의 프로토콜인 Ethernet 프로토콜 등을 사용하여 데이터를 주고 받습니다.
+  무선 통신의 경우, 두 기기가 무선으로 통신하기 위해서는 무선 통신을 지원하는 하드웨어와 무선 프로토콜을 사용합니다. 일반적으로 Wi-Fi, Bluetooth, NFC 등의 무선 통신 프로토콜이 사용됩니다.
+  예를 들어, Wi-Fi를 사용하여 무선으로 두 기기가 통신하는 경우, 먼저 두 기기는 무선 액세스 포인트(또는 라우터)에 연결됩니다. 이 때 사용되는 프로토콜은 IEEE 802.11 프로토콜입니다. 무선 액세스 포인트를 통해 연결된 두 기기는 IP 프로토콜을 사용하여 서로 통신합니다. 이때 사용되는 프로토콜은 TCP 또는 UDP 프로토콜 등이 있습니다.
+  Bluetooth를 사용하여 무선으로 두 기기가 통신하는 경우, 먼저 두 기기는 페어링을 통해 서로 연결됩니다. 이 때 사용되는 프로토콜은 Bluetooth 프로토콜입니다. Bluetooth를 통해 연결된 두 기기는 일반적으로 SPP(Serial Port Profile) 프로파일이나 A2DP(Advanced Audio Distribution Profile) 프로파일 등을 사용하여 데이터를 주고받습니다.
+  NFC를 사용하여 무선으로 두 기기가 통신하는 경우, 두 기기는 근접 상태에서 서로 통신합니다. 이 때 사용되는 프로토콜은 NFC 프로토콜입니다. NFC를 통해 연결된 두 기기는 NDEF(NFC Data Exchange Format) 등의 프로토콜을 사용하여 데이터를 주고받습니다.
+  이와 같이 유선 또는 무선으로 두 기기가 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요하며, 각각의 프로토콜마다 다양한 규칙과 규격이 있습니다.
+
   * 근거리에 있는 여러 대의 전자기기가 서로 통신하는 프로토콜은 어떻게 동작할까요?
+
+  근거리에 있는 여러 대의 전자기기가 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요합니다.
+  예를 들어, 근거리 무선 통신을 지원하는 기기들이 서로 통신하는 경우, 일반적으로 사용되는 프로토콜은 Wi-Fi, Bluetooth, Zigbee, Z-Wave 등이 있습니다. 각각의 프로토콜은 다양한 기능과 규격을 가지고 있습니다.
+  Wi-Fi를 사용하는 경우, 일반적으로 무선 액세스 포인트(또는 라우터)를 중심으로 여러 대의 기기들이 연결됩니다. Wi-Fi 기기들은 무선 액세스 포인트와 연결하여 IP 주소를 할당받고, TCP 또는 UDP 프로토콜 등을 사용하여 서로 통신합니다.
+  Bluetooth를 사용하는 경우, 여러 대의 기기들이 페어링하여 서로 연결됩니다. 페어링된 기기들은 Bluetooth 프로토콜을 사용하여 데이터를 주고받습니다. Bluetooth Mesh 프로토콜을 사용하는 경우, 여러 대의 기기들이 망 형태로 연결되어 데이터를 주고받을 수 있습니다.
+  Zigbee를 사용하는 경우, 여러 대의 기기들이 망 형태로 연결되어 서로 통신합니다. Zigbee 기기들은 IEEE 802.15.4 무선 프로토콜을 기반으로 하며, 주로 스마트 홈 등의 IoT 분야에서 사용됩니다.
+  Z-Wave를 사용하는 경우, 여러 대의 기기들이 망 형태로 연결되어 서로 통신합니다. Z-Wave 기기들은 Z-Wave 프로토콜을 사용하여 데이터를 주고받으며, 주로 스마트 홈 등의 IoT 분야에서 사용됩니다.
+  이와 같이 근거리에 있는 여러 대의 전자기기가 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요하며, 각각의 프로토콜마다 다양한 규칙과 규격이 있습니다.
+
   * 아주 멀리 떨어져 있는 두 전자기기가 유선/무선으로 서로 통신하는 프로토콜은 어떻게 동작할까요?
+
+  아주 멀리 떨어져 있는 두 전자기기가 유선/무선으로 서로 통신하기 위해서는 인터넷이나 전화망 등의 네트워크를 이용해야 합니다.
+  유선 통신의 경우, 두 전자기기 사이에 광케이블, 동축케이블, 전선 등의 물리적인 케이블이 연결되어 있어야 하며, 해당 케이블에 따라 데이터를 전송합니다. 이 때, 데이터 전송에는 TCP/IP 프로토콜을 사용합니다. TCP/IP는 인터넷을 비롯한 대부분의 네트워크에서 사용되는 프로토콜로, 데이터를 패킷으로 분할하여 전송하고, 패킷의 손실이나 손상을 검출하고 복구합니다.
+  무선 통신의 경우, 두 전자기기 사이에는 인터넷 기반의 네트워크가 필요합니다. 먼저, 무선 액세스 포인트(또는 라우터)를 통해 인터넷에 연결된 후, 해당 인터넷을 통해 다른 전자기기와 통신합니다. 무선 통신에서는 일반적으로 Wi-Fi, LTE, 5G 등의 프로토콜이 사용됩니다. 이 때, 데이터 전송에는 TCP/IP 프로토콜을 사용합니다.
+  따라서, 아주 멀리 떨어져 있는 두 전자기기가 유선/무선으로 서로 통신하기 위해서는 인터넷이나 전화망 등의 중계망을 통해 데이터를 전송하며, 해당 네트워크에서는 TCP/IP 프로토콜을 사용하여 데이터를 전송합니다.
+
   * 두 전자기기가 신뢰성을 가지고 통신할 수 있도록 하기 위한 프로토콜은 어떻게 동작할까요?
+
+  두 전자기기가 신뢰성을 가지고 통신하기 위해서는 데이터 전송 중에 발생할 수 있는 다양한 문제들에 대해 대처해야 합니다. 이를 위해 대표적인 신뢰성 프로토콜인 TCP(Transmission Control Protocol)가 사용됩니다.
+  TCP는 데이터를 안정적으로 전송하기 위해 여러 가지 기능을 제공합니다. 우선, TCP는 데이터 전송 중에 데이터를 손실하거나 손상된 데이터를 감지하고, 이를 복구하기 위해 다시 전송합니다. 또한, 데이터 전송 중에 데이터가 순서대로 도착하지 않는 문제를 해결하기 위해 순서를 지정하여 전송합니다. 또한, TCP는 데이터 전송 속도를 제어하기 위해 흐름 제어 기능을 제공합니다. 이를 통해 데이터 전송 속도가 느리거나 빠를 때 발생할 수 있는 문제들을 방지할 수 있습니다.
+  데이터를 안정적으로 전송하기 위해 TCP는 3-way handshake라고 불리는 과정을 거칩니다. 이 과정에서 클라이언트와 서버가 상호간에 정보를 교환하여 신뢰적인 연결을 설정합니다. 이후 데이터 전송 과정에서도 클라이언트와 서버는 계속해서 정보를 주고받으면서 신뢰적인 통신을 유지합니다.
+  따라서, 두 전자기기가 신뢰성을 가지고 통신하기 위해서는 TCP 프로토콜과 같은 신뢰성 프로토콜을 사용하여 안정적인 데이터 전송을 보장해야 합니다.
+
   * HTTP는 어떻게 동작할까요?
+
+  HTTP(HyperText Transfer Protocol)는 월드 와이드 웹(World Wide Web)에서 데이터를 주고받기 위한 통신 규약 중 하나입니다. HTTP는 클라이언트(Client)와 서버(Server) 간의 상호작용을 통해 데이터를 주고받습니다.
+  HTTP는 기본적으로 요청(Request)과 응답(Response)으로 구성됩니다. 클라이언트가 서버에 데이터를 요청하면, 서버는 요청을 받아 해당 데이터를 찾아서 클라이언트에게 응답합니다. 이 과정에서 HTTP 프로토콜은 요청과 응답에 대한 여러 가지 규칙과 방법을 정의합니다.
+  HTTP 요청은 메서드(Method), URL, 버전(Version), 헤더(Header), 본문(Body) 등으로 구성됩니다. 메서드는 요청의 종류를 나타내는데, 가장 많이 사용되는 메서드는 GET과 POST입니다. GET은 데이터를 가져오는 요청에, POST는 데이터를 서버에 보내는 요청에 사용됩니다. URL은 요청할 데이터의 주소를 나타내며, 버전은 HTTP의 버전을 나타냅니다. 헤더는 요청에 대한 부가적인 정보를 포함하며, 본문은 POST 요청과 같이 데이터를 서버에 전송해야 할 때 사용됩니다.
+  HTTP 응답은 상태코드(Status Code), 헤더, 본문으로 구성됩니다. 상태코드는 요청이 성공적으로 처리되었는지, 오류가 발생했는지 등을 나타내며, 헤더는 응답에 대한 부가적인 정보를 포함합니다. 본문은 요청 결과로 받은 데이터를 포함합니다.
+  HTTP는 기본적으로 TCP/IP 프로토콜 위에서 동작하며, 보안을 위해 HTTPS(HTTP Secure)를 사용할 수 있습니다. HTTPS는 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화하여 보안성을 높입니다.
+  따라서, HTTP는 웹에서 데이터를 주고받기 위한 기본적인 통신 규약이며, 요청과 응답에 대한 규칙과 방법을 정의하여 클라이언트와 서버 간의 효율적인 상호작용을 가능하게 합니다.
+
 * 우리가 브라우저의 주소 창에 www.knowre.com 을 쳤을 때, 어떤 과정을 통해 서버의 IP 주소를 알게 될까요?
 
+브라우저의 주소 창에 www.knowre.com을 입력하면, 브라우저는 먼저 입력한 주소가 유효한 도메인 이름인지 확인합니다. 이 과정에서 브라우저는 DNS(Domain Name System) 서버에 쿼리를 보내서 도메인 이름에 대응되는 IP 주소를 얻습니다.
+DNS 서버는 인터넷 상에서 도메인 이름과 IP 주소를 대응시키는 중요한 역할을 합니다. DNS 서버는 분산된 형태로 운영되며, 전 세계적으로 수많은 DNS 서버들이 서로 연결돼 있습니다. 브라우저는 이 중에서 자신과 가장 가까운 DNS 서버를 선택하여 쿼리를 보내고, 해당 DNS 서버는 쿼리에 대해 자신의 캐시(cache)에서 도메인 이름에 대응되는 IP 주소를 찾습니다. 만약 캐시에 정보가 없다면, DNS 서버는 계층 구조로 구성된 다른 DNS 서버들에게 쿼리를 전달하여 IP 주소를 찾으려고 시도합니다.
+결국, DNS 서버는 www.knowre.com에 대응되는 IP 주소를 찾아 브라우저에게 응답해줍니다. 브라우저는 이제 IP 주소를 통해 해당 서버에 접속하고, HTTP 요청을 보내서 해당 서버로부터 웹 페이지를 받아옵니다.
+
+
 ## Quest
 * tracert(Windows가 아닌 경우 traceroute) 명령을 통해 www.google.com 까지 가는 경로를 찾아 보세요.
   * 어떤 IP주소들이 있나요?

From bd1cf0bbeb77aca8f26f18df76392f619601fd4c Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Tue, 4 Apr 2023 18:22:01 +0900
Subject: [PATCH 14/29] =?UTF-8?q?Quest=2004=20=EC=A4=91=EA=B0=84=EC=A0=80?=
 =?UTF-8?q?=EC=9E=A5?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest04/skeleton/desktop.css  |  19 +-----
 Quest04/skeleton/desktop.html |  12 +++-
 Quest04/skeleton/desktop.js   | 117 +++++++++++++++++++++++++++++-----
 3 files changed, 112 insertions(+), 36 deletions(-)

diff --git a/Quest04/skeleton/desktop.css b/Quest04/skeleton/desktop.css
index 2f118d6ac..c0c221c13 100644
--- a/Quest04/skeleton/desktop.css
+++ b/Quest04/skeleton/desktop.css
@@ -18,24 +18,7 @@
     z-index: 1;
   }
   
-  .folder-icon {
-    background-color: #ffa500;
-  }
-  
-  .folder-window {
-    width: 200px;
-    height: 150px;
-    background-color: #fff;
-    border: 1px solid #000;
-    position: absolute;
-    cursor: move;
-    z-index: 2;
-    display: none;
-  }
-  
-  .folder-window .title-bar {
-    width: 100%;
-    height: 20px;
+  .folder {
     background-color: #ffa500;
     cursor: move;
   }
diff --git a/Quest04/skeleton/desktop.html b/Quest04/skeleton/desktop.html
index 50e0584a4..eee9d3381 100644
--- a/Quest04/skeleton/desktop.html
+++ b/Quest04/skeleton/desktop.html
@@ -4,17 +4,25 @@
 		<meta charset="UTF-8">
 		<link rel="stylesheet" href="./desktop.css">
 		<script src="./desktop.js"></script>
+		<div id="desktop1"></div>
+<div id="desktop2"></div>
 	</head>
 	<body>
 		<section class="desktop">
 		</section>
-		div id="desktop"></div>
+		
         <script src="desktop.js"></script>
+		
 		<script>
+			
 			let myDesktop = new Desktop(
 				/* TODO: myDesktop 인스턴스의 생성자의 변수로 무엇이 들어가야 할까요? */
 			);
-			
+			const desktop1 = document.getElementById('desktop1');
+  const desktop2 = document.getElementById('desktop2');
+
+  initializeDesktop(desktop1, 3, 2);
+  initializeDesktop(desktop2, 2, 1);
 		</script>
 	</body>
 </html>
diff --git a/Quest04/skeleton/desktop.js b/Quest04/skeleton/desktop.js
index 7f145c210..deb4c81d5 100644
--- a/Quest04/skeleton/desktop.js
+++ b/Quest04/skeleton/desktop.js
@@ -1,16 +1,101 @@
-class Desktop {
-	/* TODO: Desktop 클래스는 어떤 멤버함수와 멤버변수를 가져야 할까요? */
-	
-};
-
-class Icon {
-	/* TODO: Icon 클래스는 어떤 멤버함수와 멤버변수를 가져야 할까요? */
-};
-
-class Folder {
-	/* TODO: Folder 클래스는 어떤 멤버함수와 멤버변수를 가져야 할까요? */
-};
-
-class Window {
-	/* TODO: Window 클래스는 어떤 멤버함수와 멤버변수를 가져야 할까요? */
-};
+function initializeDesktop(numIcons, numFolders) {
+	const desktop = document.getElementById('desktop');
+  
+	// 생성자를 통해 받은 아이콘과 폴더의 개수만큼 아이콘과 폴더를 생성합니다.
+	for (let i = 1; i <= numIcons; i++) {
+	  const icon = document.createElement('div');
+	  icon.classList.add('icon');
+	  icon.style.top = `${i * 80}px`;
+	  icon.style.left = '50px';
+	  desktop.appendChild(icon);
+  
+	  // 각각의 아이콘에 이벤트 핸들러를 등록합니다.
+	  icon.addEventListener('mousedown', onIconMouseDown);
+	}
+  
+	for (let i = 1; i <= numFolders; i++) {
+	  const folder = document.createElement('div');
+	  folder.classList.add('folder');
+	  folder.style.top = `${i * 80}px`;
+	  folder.style.left = `${i * 80}px`;
+	  desktop.appendChild(folder);
+  
+	  // 각각의 폴더에 이벤트 핸들러를 등록합니다.
+	  folder.addEventListener('mousedown', onFolderMouseDown);
+	}
+  }
+
+let isDragging = false;
+let dragElement = null;
+let offset = { x: 0, y: 0 };
+
+function onIconMouseDown(event) {
+  isDragging = true;
+  dragElement = event.target;
+  offset.x = event.clientX - dragElement.offsetLeft;
+  offset.y = event.clientY - dragElement.offsetTop;
+
+  document.addEventListener('mousemove', onDrag);
+  document.addEventListener('mouseup', onDragEnd);
+}
+
+function onFolderMouseDown(event) {
+  isDragging = true;
+  dragElement = event.target;
+  offset.x = event.clientX - dragElement.offsetLeft;
+  offset.y = event.clientY - dragElement.offsetTop;
+
+  document.addEventListener('mousemove', onDrag);
+  document.addEventListener('mouseup', onDragEnd);
+}
+
+function onDrag(event) {
+  if (!isDragging) return;
+
+  dragElement.style.left = `${event.clientX - offset.x}px`;
+  dragElement.style.top = `${event.clientY - offset.y}px`;
+}
+
+function onDragEnd() {
+  isDragging = false;
+  dragElement = null;
+
+  document.removeEventListener('mousemove', onDrag);
+  document.removeEventListener('mouseup', onDragEnd);
+}
+function onFolderDoubleClick(event) {
+	const folder = event.target;
+	const folderWindow = document.createElement('div');
+	folderWindow.classList.add('window');
+	folderWindow.style.top = `${folder.offsetTop}px`;
+	folderWindow.style.left = `${folder.offsetLeft}px`;
+	desktop.appendChild(folderWindow);
+  
+	const folderContents = document.createElement('div');
+	folderContents.classList.add('folder-contents');
+	folderWindow.appendChild(folderContents);
+  
+	// 폴더의 내용물을 생성합니다.
+	// ...
+  
+	// 창을 드래그하여 이동할 수 있도록 이벤트 핸들러를 등록합니다.
+	folderWindow.addEventListener('mousedown', onWindowMouseDown);
+  }
+  
+  function onWindowMouseDown(event) {
+	isDragging = true;
+	dragElement = event.target.parentElement;
+	offset.x = event.clientX - dragElement.offsetLeft;
+	offset.y = event.clientY - dragElement.offsetTop;
+  
+	document.addEventListener('mousemove', onDrag);
+	document.addEventListener('mouseup', onDragEnd);
+  }
+  function initializeDesktop(rootElement, numIcons, numFolders) {
+	const desktop = document.createElement('div');
+	desktop.classList.add('desktop');
+	rootElement.appendChild(desktop);
+  
+	// ...
+  }
+  
\ No newline at end of file

From 5736d0bab2bfa1ff5994316a3a1bf79abaf09df3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Wed, 5 Apr 2023 15:40:18 +0900
Subject: [PATCH 15/29] CheckList Clear

---
 Quest06/README.md | 25 +++++++++++++++++++++++
 Quest07/README.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/Quest06/README.md b/Quest06/README.md
index f6128dcca..9315c8bd4 100644
--- a/Quest06/README.md
+++ b/Quest06/README.md
@@ -95,7 +95,32 @@ DNS 서버는 인터넷 상에서 도메인 이름과 IP 주소를 대응시키
 
 ## Quest
 * tracert(Windows가 아닌 경우 traceroute) 명령을 통해 www.google.com 까지 가는 경로를 찾아 보세요.
+
+1. 컴퓨터에서 명령 프롬프트를 엽니다. Windows에서는 검색 표시줄에 "cmd"를 입력하고 명령 프롬프트 앱을 선택하여 이 작업을 수행할 수 있습니다.
+2. 명령 프롬프트에 "tracert www.google.com"을 입력하고 Enter 키를 누릅니다.
+3. 명령이 완료될 때까지 기다리십시오. 네트워크 속도에 따라 몇 초에서 몇 분 정도 걸릴 수 있습니다.
+4. tracert 명령은 컴퓨터의 인터넷 트래픽이 Google 서버로 가는 도중에 통과하는 모든 라우터(홉이라고도 함) 목록을 표시합니다. 각 홉은 트래픽이
+라우팅되는 다른 네트워크 장치를 나타냅니다.
+5. tracert 명령은 각 홉이 응답하는 데 걸리는 시간도 표시합니다. RTT(Round-Trip Time)라고 하는 이 시간은 컴퓨터가 데이터 패킷을 홉으로 보내고 응답을 받는 데 걸리는 시간을 나타냅니다.
+6. tracert 명령의 마지막 홉은 트래픽이 목적지에 성공적으로 도달했음을 의미하는 Google 서버여야 합니다.
+
+tracert 명령을 실행하면 인터넷 트래픽이 특정 웹 사이트에 도달하는 데 걸리는 경로를 알 수 있습니다.
+
   * 어떤 IP주소들이 있나요?
+    1     3 ms     3 ms     4 ms  172.40.0.1
+  2     1 ms     4 ms     4 ms  192.168.10.1
+  3     2 ms     3 ms     4 ms  114.71.195.1
+  4   136 ms   207 ms   205 ms  175.194.7.181
+  5     *        *        *     요청 시간이 만료되었습니다.
+  6     6 ms     6 ms     5 ms  112.188.77.117
+  7     *        *        *     요청 시간이 만료되었습니다.
+  8    11 ms    24 ms     9 ms  112.174.90.150
+  9    11 ms    12 ms    10 ms  112.174.84.54
+ 10   141 ms   139 ms   138 ms  142.250.165.78
+ 11   248 ms   148 ms   154 ms  108.170.243.97
+ 12   142 ms   143 ms   143 ms  142.250.239.221
+ 13   144 ms   145 ms   143 ms  kix07s06-in-f4.1e100.net [142.250.76.132]
+ 
   * 그 IP주소들은 어디에 위치해 있나요?
 * Wireshark를 통해 www.google.com 으로 요청을 날렸을 떄 어떤 TCP 패킷이 오가는지 확인해 보세요
   * TCP 패킷을 주고받는 과정은 어떻게 되나요?
diff --git a/Quest07/README.md b/Quest07/README.md
index 8a77c24ec..54a2140be 100644
--- a/Quest07/README.md
+++ b/Quest07/README.md
@@ -21,13 +21,63 @@
 
 ## Checklist
 * node.js는 무엇인가요? node.js의 내부는 어떻게 구성되어 있을까요?
+Node.js는 개발자가 서버 측을 위한 확장 가능한 고성능 애플리케이션을 구축할 수 있는 오픈 소스 크로스 플랫폼 JavaScript 런타임 환경입니다. Node.js는 데이터 집약적인 실시간 애플리케이션을 구축하는 데 적합한 이벤트 중심의 비차단 I/O 모델을 사용합니다.
+핵심적으로 Node.js는 더 빠른 실행을 위해 JavaScript 코드를 머신 코드로 컴파일하는 Google의 V8 JavaScript 엔진 위에 구축됩니다. Node.js는 개발자가 파일 I/O, 네트워크 I/O 및 HTTP 처리와 같은 다양한 작업을 수행하는 데 사용할 수 있는 일련의 내장 모듈을 제공합니다. Node.js는 npm(노드 패키지 관리자)을 사용하여 설치할 수 있는 타사 모듈의 사용도 지원합니다.
+Node.js의 내부 구조는 모든 I/O 작업을 비동기적으로 처리하는 단일 스레드 이벤트 루프를 기반으로 합니다. I/O 작업이 시작되면 Node.js는 작업 완료 시 실행할 콜백 함수를 등록합니다. 작업이 완료되기를 기다리는 동안 Node.js는 다른 코드를 계속 실행할 수 있습니다. 작업이 완료되면 콜백 함수가 이벤트 큐에 추가되고 이벤트 루프에서 FIFO(선입선출) 순서로 처리됩니다.
+Node.js의 이벤트 루프는 타이머 단계, I/O 콜백 단계, 유휴, 준비, 폴링, 확인 및 콜백 닫기 단계를 포함한 여러 단계로 구성됩니다. 타이머 단계에서 Node.js는 만료된 타이머 콜백을 확인하고 이벤트 큐에 추가합니다. I/O 콜백 단계에서 Node.js는 완료된 모든 I/O 관련 콜백을 처리합니다. poll 단계는 I/O 이벤트가 발생하기를 기다리는 반면 check 단계는 setImmediate() 콜백을 처리합니다. 마지막으로 닫기 콜백 단계에서는 닫힌 연결 또는 리소스와 관련된 모든 콜백을 처리합니다.
+전반적으로 Node.js의 내부 구조는 가볍고 효율적으로 설계되어 고성능을 유지하면서 대량의 I/O 작업을 처리할 수 있습니다.
+
 * npm이 무엇인가요? `package.json` 파일은 어떤 필드들로 구성되어 있나요?
+npm은 노드 패키지 관리자를 나타냅니다. Node.js와 함께 제공되는 명령줄 유틸리티이며 개발자가 Node.js 애플리케이션용 패키지(즉, 재사용 가능한 코드 모듈)를 설치하고 관리할 수 있는 방법을 제공합니다.
+npm은 개발자가 애플리케이션에서 검색, 다운로드 및 사용할 수 있는 패키지 레지스트리를 유지 관리하여 작동합니다. 개발자가 npm을 사용하여 패키지를 설치하면 패키지와 해당 종속성(즉, 패키지가 의존하는 다른 패키지)을 다운로드하고 프로젝트의 "node_modules" 디렉토리에 설치합니다.
+package.json 파일은 npm이 Node.js 애플리케이션의 종속성 및 구성을 관리하는 데 사용하는 메타데이터 파일입니다. 이 파일은 응용 프로그램의 루트 디렉터리에 있으며 응용 프로그램의 이름과 버전, 응용 프로그램에 대한 설명, 해당 종속성, 실행할 스크립트 및 기타 메타데이터와 같은 정보를 포함합니다.
+
+package.json 파일의 가장 일반적인 필드 중 일부는 다음과 같습니다.
+
+이름: 애플리케이션의 이름입니다.
+version: 애플리케이션의 버전 번호입니다.
+description: 애플리케이션에 대한 간략한 설명입니다.
+main: 애플리케이션의 메인 파일.
+종속성: 애플리케이션에 필요한 종속성의 목록입니다.
+devDependencies: 개발 중에만 필요한 종속성 목록입니다.
+scripts: npm을 사용하여 실행할 수 있는 스크립트 집합입니다.
+author: 애플리케이션의 저자.
+라이센스: 애플리케이션이 배포되는 라이센스입니다.
+
+Node.js 애플리케이션에서 package.json 파일을 유지함으로써 개발자는 종속성을 쉽게 관리하고 다른 사람과 애플리케이션을 공유하며 애플리케이션을 다른 환경에서 쉽게 배포하고 실행할 수 있습니다.
+
 * npx는 어떤 명령인가요? npm 패키지를 `-g` 옵션을 통해 글로벌로 저장하는 것과 그렇지 않은 것은 어떻게 다른가요?
+
+npx는 버전 5.2.0부터 npm(Node Package Manager)과 함께 제공되는 명령줄 유틸리티입니다. 먼저 설치할 필요 없이 시스템에 전체적으로 설치되지 않은 Node.js 패키지를 실행하는 데 사용됩니다. npx로 패키지를 실행하면 패키지가 프로젝트의 node_modules 디렉토리에 로컬로 설치되어 있는지 확인합니다. 패키지를 찾을 수 없는 경우 npx는 패키지를 실행하기 전에 최신 버전의 패키지를 다운로드하여 설치합니다.
+-g 옵션을 통해 npm 패키지를 전역으로 저장하는 것과 그렇지 않은 것의 차이점은 전역으로 설치된 패키지는 시스템의 모든 프로젝트에서 사용할 수 있는 반면 로컬로 설치된 패키지는 프로젝트 디렉토리 내에서만 사용할 수 있다는 것입니다. 전역적으로 패키지를 설치하면 여러 프로젝트에 동일한 패키지를 설치할 필요가 없으므로 디스크 공간을 절약할 수 있습니다. 그러나 여러 프로젝트에 동일한 패키지의 다른 버전이 필요할 수 있으므로 다른 프로젝트 간에 버전 충돌이 발생할 수도 있습니다.
+반면에 패키지를 로컬로 설치하면 각 프로젝트가 필요한 패키지의 특정 버전에 액세스할 수 있습니다. 이를 통해 버전 충돌을 방지하고 프로젝트를 보다 안정적이고 예측 가능하게 만들 수 있습니다. 패키지를 로컬로 설치하면 해당 프로젝트에 특정한 프로젝트의 node_modules 디렉토리에 추가됩니다. 즉, 해당 프로젝트에 패키지를 다시 설치하지 않는 한 다른 프로젝트에서 패키지를 사용할 수 없습니다.
+요약하면 -g 옵션을 통해 npm 패키지를 전역적으로 저장하는 것과 그렇지 않은 것의 주요 차이점은 패키지의 가용성 범위입니다. 전역 패키지는 시스템 전체에서 사용할 수 있는 반면 로컬 패키지는 프로젝트 디렉터리 내에서만 사용할 수 있습니다. 패키지를 글로벌로 설치할지 로컬로 설치할지 선택하는 것은 특정 요구 사항과 프로젝트의 요구 사항에 따라 다릅니다.
+
 * 자바스크립트 코드에서 다른 파일의 코드를 부르는 시도들은 지금까지 어떤 것이 있었을까요? CommonJS 대신 ES Modules가 등장한 이유는 무엇일까요?
+
+스크립트 태그: 웹 초기에 개발자는 <script> 태그를 사용하여 JavaScript 파일을 로드했습니다. 그러나 이 접근 방식은 코드를 별도의 파일로 구성하거나 동적으로 코드를 로드하는 방법을 제공하지 않았습니다.
+CommonJS: CommonJS는 JavaScript 코드를 모듈화하는 표준 방식을 정의하려는 시도였습니다. 모듈을 로드하는 require() 함수와 내보내기를 정의하는 module.exports 객체를 도입했습니다. 그러나 CommonJS에는 모듈의 동기식 로드와 같은 몇 가지 제한 사항이 있어 더 큰 애플리케이션에서 성능 문제가 발생할 수 있습니다.
+AMD(비동기 모듈 정의): AMD는 모듈식 JavaScript 코드의 표준을 정의하려는 또 다른 시도였습니다. 모듈을 정의하는 define() 함수와 모듈을 비동기적으로 로드하는 require() 함수를 도입했습니다. 그러나 AMD는 개발자가 특정 구문을 사용하도록 요구했기 때문에 다른 솔루션보다 유연성이 떨어졌습니다.
+ES6 모듈: ECMAScript 모듈이라고도 하는 ES6 모듈은 ECMAScript 2015에서 JavaScript 코드를 모듈화하는 표준 방법으로 도입되었습니다. 그들은 export 키워드를 사용하여 내보내기를 정의하고 import 키워드를 사용하여 모듈을 로드하는 방법을 제공합니다. ES6 모듈은 별도의 라이브러리가 아닌 언어 자체의 일부이므로 이전 솔루션보다 더 유연하고 강력합니다.SSS
+ES 모듈은 CommonJS에 비해 몇 가지 장점을 제공하기 때문에 CommonJS 대신 등장했습니다. ES 모듈은 최신 브라우저와 Node.js에서 기본적으로 지원되므로 추가 라이브러리나 도구를 사용할 필요가 없습니다. 또한 모듈의 비동기 로드를 지원하여 더 큰 애플리케이션의 성능을 향상시킬 수 있습니다. ES 모듈은 명명된 내보내기와 기본 내보내기를 모두 허용하고 런타임 값에 따라 조건부로 로드될 수 있으므로 CommonJS보다 더 유연합니다. 마지막으로 ES 모듈은 CommonJS보다 간단하고 직관적인 구문을 가지고 있어 개발자가 사용하고 이해하기 쉽습니다.
+
 * ES Modules는 기존의 `require()`와 동작상에 어떤 차이가 있을까요? CommonJS는 할 수 있으나 ES Modules가 할 수 없는 일에는 어떤 것이 있을까요?
+
+ES 모듈과 require()의 주요 차이점은 종속성과 모듈 로드를 처리하는 방식입니다. 'require()'는 모듈을 로드하는 동기 방식으로, 모듈이 차단 방식으로 로드되고 실행된다는 것을 의미합니다. 대조적으로 ES Modules는 모듈 로딩 및 종속성에 대한 동적 및 비동기식 접근 방식을 사용하여 비동기식으로 로드되고 실행될 수 있습니다.
+또 다른 중요한 차이점은 내보내기가 정의되는 방식입니다. CommonJS에서 내보내기는 module.exports 객체를 사용하여 정의되는 반면 ES Modules에서는 export 키워드를 사용하여 정의됩니다. 구문의 이러한 차이로 인해 개발자는 특히 명명된 내보내기를 처리할 때 코드를 더 쉽게 작성하고 이해할 수 있습니다.
+CommonJS에 비해 ES Modules의 주요 이점 중 하나는 JavaScript 모듈 작업에 대해 보다 표준화되고 미래에 대비한 방식을 제공한다는 것입니다. ES 모듈은 ECMAScript 표준의 일부이며, 이는 최신 브라우저와 Node.js에서 기본적으로 지원됨을 의미합니다. 이를 통해 타사 라이브러리나 도구에 의존할 필요 없이 다양한 플랫폼과 환경에서 모듈로 작업하기가 더 쉬워집니다.
+그러나 CommonJS에 비해 ES 모듈에는 몇 가지 제한 사항이 있습니다. 예를 들어, ES 모듈은 대규모 애플리케이션에서 일반적인 기능일 수 있는 순환 종속성을 지원하지 않습니다. 또한 런타임에 조건부로 로드할 수 없지만 require() 함수를 사용하는 CommonJS에서는 가능합니다.
+전반적으로 ES Modules는 JavaScript 모듈을 사용하여 보다 현대적이고 유연한 작업 방식을 제공하는 반면 CommonJS는 보다 전통적이고 검증된 접근 방식을 제공합니다. 어느 것을 사용할지는 프로젝트의 특정 요구 사항과 사용 중인 도구 및 라이브러리에 따라 다릅니다.
+
 * node.js에서 ES Modules를 사용하려면 어떻게 해야 할까요? ES Modules 기반의 코드에서 CommonJS 기반의 패키지를 불러오려면 어떻게 해야 할까요? 그 반대는 어떻게 될까요?
 
-## Quest
+Node.js에서 ES 모듈을 사용하려면 모듈 파일에 .mjs 파일 확장자를 사용하거나 package.json 파일에서 "type": "module" 필드를 설정해야 합니다. 이 작업을 완료하면 import 문을 사용하여 다음과 같이 모듈을 로드하고 사용할 수 있습니다.
+ES 모듈 기반 코드에서 CommonJS 기반 패키지를 가져오려면 CommonJS 모듈 내보내기로 확인되는 Promise를 반환하는 import() 함수를 사용할 수 있습니다.
+esm과 같은 패키지를 사용하여 CommonJS 패키지에 대한 ES 모듈 지원을 활성화할 수도 있습니다. esm은 CommonJS 파일에서 ES 모듈 구문을 사용할 수 있게 해주는 패키지로, ES 모듈 기반 프로젝트에서 CommonJS 패키지를 사용하려는 경우 유용할 수 있습니다. esm을 사용하려면 npm으로 설치한 다음 -r esm 플래그로 스크립트를 실행해야 합니다.
+CommonJS 기반 코드에서 ES 모듈 기반 패키지를 가져오려면 require() 함수를 사용할 수 있습니다.
+그러나 require()는 개별적으로 명명된 내보내기가 아니라 전체 ES 모듈을 나타내는 객체를 반환한다는 점에 유의하십시오. 명명된 내보내기에 액세스하려면 ES Module 개체의 default 속성을 사용할 수 있습니다. 또는 cjs-es와 같은 패키지를 사용하여 ES 모듈에 대한 CommonJS 지원을 활성화할 수 있습니다. cjs-es는 ES 모듈 파일에서 CommonJS 구문을 사용할 수 있게 해주는 패키지로, ES 모듈 기반 프로젝트에서 CommonJS 패키지를 사용하려는 경우 유용할 수 있습니다. cjs-es를 사용하려면 npm으로 설치한 다음 --experimental-specifier-resolution=node 플래그로 스크립트를 실행해야 합니다.
+
+## QuestS
 * 스켈레톤 코드에는 다음과 같은 네 개의 패키지가 있으며, 용도는 다음과 같습니다:
   * `cjs-package`: CommonJS 기반의 패키지입니다. 다른 코드가 이 패키지의 함수와 내용을 참조하게 됩니다.
   * `esm-package`: ES Modules 기반의 패키지입니다. 다른 코드가 이 패키지의 함수와 내용을 참조하게 됩니다.

From 5a9614300c7951068f9c60c6e8e4a0ca6f538923 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Wed, 5 Apr 2023 16:37:17 +0900
Subject: [PATCH 16/29] CheckList Clear

---
 Quest08/README.md | 83 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/Quest08/README.md b/Quest08/README.md
index b19acb48b..b8a3d32bf 100644
--- a/Quest08/README.md
+++ b/Quest08/README.md
@@ -17,16 +17,99 @@
 
 ## Checklist
 * HTTP의 GET과 POST 메소드는 어떻게 다른가요?
+
+```
+HTTP(Hypertext Transfer Protocol)는 인터넷을 통해 데이터를 전송하는 데 사용되는 프로토콜입니다. 가장 일반적으로 사용되는 두 가지 HTTP 메서드는 서로 다른 용도로 사용되는 GET 및 POST입니다.
+GET 요청은 서버에서 데이터를 검색하는 데 사용됩니다. 웹 브라우저에 URL을 입력하면 웹 사이트를 호스팅하는 서버에 GET 요청을 보내 해당 URL에 있는 리소스(일반적으로 HTML 문서)를 요청합니다. GET 요청은 링크를 클릭하거나 이미지 또는 기타 리소스가 웹 페이지에 포함된 경우에도 사용됩니다.
+GET 요청은 멱등적으로 설계되어 서버 상태를 변경하지 않고 반복될 수 있습니다. 이는 GET 요청이 데이터를 검색할 뿐 수정하지 않기 때문입니다.
+반면에 POST 요청은 데이터를 서버로 보내는 데 사용됩니다. 웹 사이트에서 양식을 제출하면 양식 필드에 입력한 데이터와 함께 서버에 POST 요청을 보냅니다. POST 요청은 파일을 업로드하거나 서버에서 데이터를 수정하는 다른 작업을 수행하는 데에도 사용할 수 있습니다.
+POST 요청은 멱등적이지 않습니다. 즉, 동일한 요청을 여러 번 반복하면 서버 상태에 따라 다른 결과가 나올 수 있습니다. 이러한 이유로 POST 요청은 일반적으로 데이터베이스에 새 레코드를 추가하거나 기존 레코드를 업데이트하는 것과 같은 부작용이 있는 작업에 사용됩니다.
+요약하면 GET 요청은 데이터 검색에 사용되는 반면 POST 요청은 데이터를 수정하거나 작업을 수행하기 위해 서버로 데이터를 보내는 데 사용됩니다.
+```
+
   * 다른 HTTP 메소드에는 무엇이 있나요?
+```
+  GET: 일반적으로 웹 페이지 또는 이미지나 문서와 같은 리소스와 같은 서버에서 데이터를 검색하는 데 사용됩니다.
+  POST: 양식 제출, 파일 업로드 등 리소스를 생성하거나 업데이트하기 위해 서버에 데이터를 보내는 데 사용됩니다.
+  PUT: 일반적으로 기존 리소스를 완전히 대체하여 서버의 기존 리소스를 업데이트하는 데 사용됩니다.
+  DELETE: 서버의 리소스를 삭제할 때 사용합니다.
+  HEAD: GET과 유사하지만 응답 본문이 아닌 응답의 헤더만 검색합니다.
+  OPTIONS: 리소스에 사용할 수 있는 통신 옵션에 대한 정보를 검색하는 데 사용됩니다.
+  PATCH: 서버의 기존 리소스를 부분적으로 업데이트하는 데 사용됩니다.
+```
 * HTTP 서버에 GET과 POST를 통해 데이터를 보내려면 어떻게 해야 하나요?
+```
+GET을 통해 데이터 보내기:
+method 속성이 "get"으로 설정되고 action 속성이 데이터를 보낼 서버의 URL로 설정된 HTML 양식을 만듭니다.
+보내려는 매개변수의 이름에 해당하는 '이름' 속성을 사용하여 텍스트 입력 또는 확인란과 같은 양식 필드를 양식에 추가합니다.
+제출 버튼을 클릭하거나 JavaScript를 사용하여 프로그래밍 방식으로 양식을 제출합니다.
+양식이 제출되면 데이터가 URL의 쿼리 매개변수로 인코딩되고 GET 요청을 통해 서버로 전송됩니다.
+
+POST를 통해 데이터 보내기:
+method 속성이 "post"로 설정되고 action 속성이 데이터를 보낼 서버의 URL로 설정된 HTML 양식을 만듭니다.
+GET 요청과 마찬가지로 양식 필드를 양식에 추가합니다.
+제출 버튼을 클릭하거나 JavaScript를 사용하여 프로그래밍 방식으로 양식을 제출합니다.
+양식이 제출되면 요청 본문의 데이터와 함께 POST 요청을 통해 데이터가 서버로 전송됩니다. JavaScript를 사용하여 POST를 통해 데이터를 전송하려면 fetch() API 또는 기타 AJAX 라이브러리를 사용하여 프로그래밍 방식으로 HTTP POST 요청을 할 수 있습니다.
+```
   * HTTP 요청의 `Content-Type` 헤더는 무엇인가요?
+  ```
+  Content-Type 헤더는 요청 또는 응답 본문에서 데이터의 MIME 유형을 지정하는 표준 HTTP 헤더입니다. 수신자가 데이터를 적절하게 구문 분석하고 처리할 수 있도록 전송되는 데이터 유형을 서버 또는 클라이언트에 알려줍니다.
+  예를 들어 요청의 Content-Type 헤더가 application/json으로 설정되어 있으면 요청 본문에 JSON 형식의 데이터가 포함되어 있음을 나타냅니다. 마찬가지로 응답의 Content-Type 헤더가 text/html로 설정되면 응답 본문에 HTML 콘텐츠가 포함되어 있음을 나타냅니다.
+  'Content-Type' 헤더는 일반적으로 요청을 보내는 클라이언트 또는 응답을 보내는 서버에 의해 설정됩니다. 경우에 따라 'Content-Type' 헤더는 파일 확장자 또는 데이터의 기타 특성에 따라 요청 또는 응답을 처리하는 소프트웨어에 의해 자동으로 설정될 수 있습니다.
+  'Content-Type' 헤더를 올바르게 설정하는 것이 중요합니다. 수신자가 데이터를 제대로 처리하고 표시하는 데 도움이 되기 때문입니다. 'Content-Type' 헤더가 올바르지 않거나 누락된 경우 수신자가 데이터를 제대로 처리할 수 없어 오류가 발생하거나 콘텐츠가 잘못 표시될 수 있습니다.
+  ```
   * Postman에서 POST 요청을 보내는 여러 가지 방법(`form-data`, `x-www-form-urlencoded`, `raw`, `binary`) 각각은 어떤 용도를 가지고 있나요?
+```
+  form-data: 이 방법은 일반적으로 파일을 업로드하거나 파일이 포함된 양식을 제출하는 데 사용되는 multipart/form-data 형식으로 데이터를 보내는 데 사용됩니다. 데이터는 키-값 쌍으로 전송되며 여기서 키는 양식 필드의 이름을 나타내고 값은 해당 필드에 입력된 데이터를 나타냅니다.
+  x-www-form-urlencoded: 이 방법은 HTTP POST 요청을 통해 데이터를 전송하기 위한 표준 형식인 application/x-www-form-urlencoded 형식으로 데이터를 전송하는 데 사용됩니다. 데이터는 키-값 쌍으로 전송되며 여기서 키는 양식 필드의 이름을 나타내고 값은 해당 필드에 입력된 데이터를 나타냅니다.
+  raw: 이 방법은 JSON 또는 XML과 같은 원시 형식으로 데이터를 보내는 데 사용됩니다. 데이터는 서식이나 인코딩 없이 요청 본문에 직접 입력됩니다.
+  binary: 이 메소드는 이미지나 오디오 파일과 같은 바이너리 데이터를 요청 본문으로 보내는 데 사용됩니다. 데이터는 이진 스트림으로 인코딩되어 요청 본문에 직접 전송됩니다.
+  일반적으로 사용할 방법의 선택은 전송되는 데이터 유형과 사용 중인 API의 요구 사항에 따라 다릅니다. 예를 들어 파일을 업로드해야 하는 경우에는 form-data 방식을 사용하고 JSON 데이터를 보내야 하는 경우에는 raw 방식을 사용합니다. x-www-form-urlencoded 방법은 일반적으로 파일을 포함하지 않는 간단한 양식에 사용되는 반면 binary 방법은 이진 데이터를 보내는 데 사용됩니다.
+```
 * node.js의 `http` 모듈을 통해 HTTP 요청을 처리할 때,
   * `req`와 `res` 객체에는 어떤 정보가 담겨있을까요?
+```
+  1. req: 클라이언트로부터 들어오는 요청에 대한 정보를 포함하는 HTTP 요청 객체입니다. 다음 속성을 포함합니다.
+  req.method: 요청을 만들기 위해 클라이언트가 사용하는 HTTP 메서드(예: GET, POST 등)
+  req.url: 요청된 리소스의 URL
+  req.headers: 요청 헤더를 포함하는 객체
+  req.body: 요청 본문(있는 경우)(이 속성은 기본적으로 사용할 수 없으며 원시 데이터에서 구문 분석해야 함)
+
+  2. res: 클라이언트에게 응답을 다시 보내는 데 사용되는 HTTP 응답 개체입니다. 여기에는 다음 속성 및 메서드가 포함됩니다.
+  res.statusCode: 클라이언트로 다시 보낼 HTTP 상태 코드(예: 200은 OK, 404는 찾을 수 없음 등)
+  res.setHeader(name, value): 클라이언트에 보낼 응답의 헤더를 설정합니다.
+  res.write(data): 응답 본문에 데이터 쓰기
+  res.end([data]): 선택적으로 응답 본문의 일부 데이터와 함께 클라이언트에 응답을 보냅니다.
+
   * GET과 POST에 대한 처리 형태가 달라지는 이유는 무엇인가요?
+  GET 요청은 서버에서 리소스를 검색하는 데 사용되며 일반적으로 요청 본문이 없습니다. 따라서 GET 요청을 처리할 때 서버는 URL에서 쿼리 매개변수를 읽고 요청된 리소스를 반환합니다. GET 요청 처리는 일반적으로 간단합니다.
+  POST 요청은 서버에 데이터를 제출하는 데 사용되며 일반적으로 제출할 데이터가 포함된 요청 본문이 있습니다. 따라서 POST 요청을 처리할 때 서버는 요청 본문에서 데이터를 읽고 구문 분석하고 그에 따라 처리해야 합니다. POST 요청 처리는 일반적으로 더 복잡하며 들어오는 데이터를 처리하기 위한 추가 작업이 필요합니다.
+  요약하면 GET 및 POST 요청에 대한 처리 유형은 용도와 특성이 다르기 때문에 서로 다릅니다. GET 요청은 리소스 검색에 사용되는 반면 POST 요청은 데이터 제출에 사용되며 각 유형에 대한 처리는 특정 사용 사례에 맞게 조정됩니다.
+```
 * 만약 API 엔드포인트(URL)가 아주 많다고 한다면, HTTP POST 요청의 `Content-Type` 헤더에 따라 다른 방식으로 동작하는 서버를 어떻게 정리하면 좋을까요?
+```
+1. 별도의 엔드포인트 사용: 지원해야 하는 각 Content-Type 헤더에 대해 별도의 API 엔드포인트를 생성할 수 있습니다. 이 접근 방식은 Content-Type 헤더에 따라 서버의 동작이 크게 달라지거나 지원할 헤더 수가 제한된 경우에 잘 작동합니다.
+
+2. 미들웨어 사용: 미들웨어를 사용하여 들어오는 요청을 처리하고 Content-Type 헤더를 기반으로 적절한 핸들러로 라우팅할 수 있습니다. 이 접근 방식은 지원할 헤더가 많거나 헤더에 따라 서버의 동작이 약간만 다른 경우에 적합합니다.
+
+3. 콘텐츠 협상 사용: 콘텐츠 협상을 사용하여 'Content-Type' 헤더를 기반으로 적절한 동작을 결정할 수 있습니다. 콘텐츠 협상은 클라이언트와 서버가 통신하여 반환할 리소스의 최상의 표현을 결정하는 프로세스입니다. 이 접근 방식은 지원할 헤더가 많고 헤더에 따라 서버의 동작이 약간만 다른 경우에 잘 작동합니다.
+
+어떤 접근 방식을 선택하든 개발자가 API와 상호 작용하는 방법과 Content-Type 헤더를 기반으로 예상되는 동작을 알 수 있도록 API가 잘 문서화되어 있는지 확인하는 것이 중요합니다.
+```
   * 그 밖에 서버가 요청들에 따라 공통적으로 처리하는 일에는 무엇이 있을까요? 이를 어떻게 정리하면 좋을까요?
+```
+요청을 처리하는 것 외에도 서버는 일반적으로 인증 처리, 로깅, 오류 처리 및 캐싱과 같은 다른 작업도 수행합니다. 이러한 작업을 정리하기 위해 미들웨어를 사용하는 것이 일반적입니다.
+
+미들웨어는 서버와 클라이언트 사이에 위치하며 다양한 작업을 수행하기 위해 요청과 응답을 가로챌 수 있는 소프트웨어입니다. 서버에 기능을 추가하거나 오류를 처리하거나 응답을 수정하는 데 사용할 수 있습니다.
+
+미들웨어를 구성하는 가장 일반적인 접근 방식은 미들웨어 스택을 사용하는 것입니다. 미들웨어 스택은 들어오는 각 요청에 대해 순서대로 실행되는 미들웨어 기능의 정렬된 목록입니다. 스택의 각 미들웨어 기능은 요청 및 응답 개체에 액세스할 수 있으며 필요에 따라 수정할 수 있습니다.
+
+미들웨어 기능은 인증 미들웨어, 오류 처리 미들웨어 및 로깅 미들웨어와 같은 목적에 따라 다른 그룹으로 구성할 수 있습니다. 미들웨어를 그룹으로 구성하면 코드를 체계적으로 유지하고 쉽게 유지 관리할 수 있습니다.
+
+미들웨어를 구성할 때 고려해야 할 또 다른 중요한 사항은 미들웨어 기능이 실행되는 순서입니다. 순서는 서버의 동작에 상당한 영향을 미칠 수 있으므로 실행 순서를 신중하게 고려하는 것이 중요합니다.
 
+요약하면 서버는 요청 처리 외에도 다양한 작업을 수행하며 미들웨어를 사용하여 이러한 작업을 구성할 수 있습니다. 미들웨어 스택을 사용하고 미들웨어 기능을 그룹으로 구성하면 코드를 체계적으로 유지 관리할 수 있습니다. 또한 미들웨어 기능이 실행되는 순서를 신중하게 고려하는 것이 중요합니다.
+```
 ## Quest
 * 다음의 동작을 하는 서버를 만들어 보세요.
   * 브라우저의 주소창에 `http://localhost:8080`을 치면 `Hello World!`를 응답하여 브라우저에 출력합니다.

From 83a2f03b2835354028c379e057ef25c816072e83 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Wed, 5 Apr 2023 16:51:34 +0900
Subject: [PATCH 17/29] =?UTF-8?q?=EA=B0=80=EC=8B=9C=EC=84=B1=20=EA=B0=9C?=
 =?UTF-8?q?=EC=84=A0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 Quest00/README.md | 12 ++++--
 Quest01/README.md | 98 ++++++++++++++++++++++++++---------------------
 Quest02/README.md | 38 ++++++++++--------
 Quest03/README.md | 13 ++++---
 Quest04/README.md | 49 +++++++++++++-----------
 Quest05/README.md |  9 +++--
 Quest06/README.md | 28 +++++++-------
 Quest07/README.md | 22 ++++++-----
 8 files changed, 153 insertions(+), 116 deletions(-)

diff --git a/Quest00/README.md b/Quest00/README.md
index a93c1f642..eb1bf3d8f 100644
--- a/Quest00/README.md
+++ b/Quest00/README.md
@@ -16,23 +16,27 @@
 
 ## Checklist
 * 형상관리 시스템은 왜 나오게 되었을까요?
-
+```
 형상관리 시스템은 특정 시점에 대해 상태를 기록해 놓으면 이후라도 언제든지 그 환경으로 돌아갈 수 있게 도와주는것
 인데 왜 이 시스템이 나왔냐면 협업의 특성상 여러 사람들이 프로젝트를 함께 참여하게 되는데 이 때 누군가의 실수로 잘못된 버전이나 버그들이 생길경우들이 많아서
 그러한 일들을 막기위해 생긴 시스템이다.
-
+```
 * git은 어떤 형상관리 시스템이고 어떤 특징을 가지고 있을까요? 분산형 형상관리 시스템이란 무엇일까요?
+```
 git의 경우 버전별로 관리할 수 있는 형상관리 시스템이다.
 분산형 형상관리 시스템은 마지막 저장한 것을 전부 복제하는것.(이와 반대되는것이 중앙집중식 버전 관리 시스템이다.)
-
+```
   * git은 어떻게 개발되게 되었을까요? git이 분산형 시스템을 채택한 이유는 무엇일까요?
+  ```
   git은 Linux 커널이 BitKeeper을 만들면서 이익을 추구하는 회사와 관계가 틀어져 무료 사용이 재고된 후,자체 도구를 만드는 계기가 되었는데 이 도구가 Git이다.
   git이 분산형 시스템을 채택한 이유는 빠른 속도,단순한 구조, 비선형적인 개발,완벽한 분산,대형 프로젝트에서도 유용하기 때문이다.
+  ```
   
 * git과 GitHub은 어떻게 다를까요?
+```
 git과 Github와 차이점은 Local git/Remote git, 터미널을 사용하는git/UI를 지원하는 Github, PR(Pull Request) 기능을 지원하는 Github
 Github는 git을 서비스하지만 추가적인 여러 기능들을 지원하는 시스템이다.
-
+```
 * git의 clone/add/commit/push/pull/branch/stash 명령은 무엇이며 어떨 때 이용하나요? 그리고 어떻게 사용하나요?
 
 
diff --git a/Quest01/README.md b/Quest01/README.md
index 5716d0d24..1751381ce 100644
--- a/Quest01/README.md
+++ b/Quest01/README.md
@@ -28,6 +28,7 @@
 
 ## Checklist
 * HTML 표준의 역사는 어떻게 될까요?
+```
 HTML 1.0 = 거의 텍스트위주의 정보전달 목적
 W3C 웹의 표준을 정의하는 국제 컨소시엄
 HTML 2.0 ~ HTML 3.2 = 표준화를 위한 노력 
@@ -36,21 +37,26 @@ XHTML XML과 HTML을 합성, 정확한 문법 사용 *XML W3C에서 개발한 
 WHATWG(Web Hypertext Application Techology Working Group) HTML 5의 시초
 HTML 5 완벽한 표준의 정착.
 결국 W3C도 자세를 낮추고 XHTML을 표준에서 탈락시키게 되고, WHATWG에서 정의한 표준을 따르기로 한다. 결론적으로 HTML5와 CSS3가 표준으로 확정되게 되고, 지금의 HTML5 표준이 완성된 것이다.
-
+```
   * HTML 표준을 지키는 것은 왜 중요할까요?
+  ```
   인류가 단위를 통일한 것이 공학의 발전 산업에 전반적인 효율성을 증가시킨것 처럼 웹표준역시 웹개발에서 효율성을 증대시키기 때문이다. 웹표준에대한 이해를 가지고 웹개발을 하는 것이 중요하다.
-  
+  ```
   * XHTML 2.0은 왜 세상에 나오지 못하게 되었을까요?
+  ```
   XHTML2의 가장 큰 문제점은 HTML4와 XHTML1.0과 전혀 다른 새로운 표준이라는 것입니다. 한마디로 웹 브라우저 업체들에게는 렌더링 엔진을 바닥 부터 새로 짜야 할 만큼 하위 호환성에 대한 보장이 거의 없음.
-  
+  ```
   * HTML5 표준은 어떤 과정을 통해 정해질까요?
-표준화 단체인 W3C(World Wide Web Consortium)에서 HTML5 표준 작업 그룹을 구성합니다.
-HTML5 표준 작업 그룹에서 초안을 작성하고, 이를 공개적으로 검토 및 토론합니다.
-작업 그룹에서 검토 및 토론을 거친 최종 초안을 W3C에 제출합니다.
-W3C에서는 해당 초안을 검토하고, 표준화 과정을 진행합니다.
-W3C의 표준화 과정을 거친 후, 최종적으로 HTML5 표준이 발표됩니다.
+  ```
+  표준화 단체인 W3C(World Wide Web Consortium)에서 HTML5 표준 작업 그룹을 구성합니다.
+  HTML5 표준 작업 그룹에서 초안을 작성하고, 이를 공개적으로 검토 및 토론합니다.
+  작업 그룹에서 검토 및 토론을 거친 최종 초안을 W3C에 제출합니다.
+  W3C에서는 해당 초안을 검토하고, 표준화 과정을 진행합니다.
+  W3C의 표준화 과정을 거친 후, 최종적으로 HTML5 표준이 발표됩니다.
+  ```
   
 * 브라우저의 역사는 어떻게 될까요?
+```
 웹 브라우저의 역사는 인터넷의 발전과 함께 시작되었습니다. 초기 인터넷에서는 텍스트 기반의 터미널 환경에서만 이용이 가능했습니다. 하지만 1990년대 중반, 그래픽 사용자 인터페이스(GUI)를 지원하는 웹 브라우저의 등장으로 인터넷의 사용이 대폭 증가하게 되었습니다.
 
 이후, 다양한 웹 브라우저가 등장하였으며, 이들은 서로 다른 렌더링 엔진을 사용하여 동작하였습니다. 이때 사용되는 렌더링 엔진은 HTML, CSS, JavaScript 등의 웹 페이지를 해석하고 브라우저 창에 렌더링하는 역할을 합니다.
@@ -62,7 +68,7 @@ W3C의 표준화 과정을 거친 후, 최종적으로 HTML5 표준이 발표됩
 2010년대 이후로는 구글에서 개발한 크롬(Chrome)이 대세가 되었으며, 모바일 기기용 브라우저인 안드로이드 기본 브라우저에서도 크롬 기반으로 변경되었습니다.
 
 최근에는 웹 표준을 준수하며 보안과 성능에 중점을 둔 브라우저의 필요성이 부각되면서, 모든 브라우저에서 웹 표준을 따르도록 노력하고 있습니다.
-
+```
 
   * Internet Explorer가 브라우저 시장을 독점하면서 어떤 문제가 일어났고, 이 문제는 어떻게 해결되었을까요?
 웹 표준 준수 문제
@@ -76,36 +82,36 @@ IE는 보안 취약점이 많이 발견되어 사용자의 개인정보가 유
 또한, 마이크로소프트도 웹 표준과 보안에 더 많은 관심을 기울이며, 최신 버전의 IE에서는 웹 표준을 준수하도록 노력하고 있습니다. 하지만, 이전 버전의 IE에서는 여전히 웹 표준 준수에 어려움이 있기 때문에, 이를 대응하기 위해 웹 개발자들은 여전히 추가 작업이 필요합니다.
 
   * 현재 시점에 브라우저별 점유율은 어떻게 될까요? 이 브라우저별 점유율을 알아보는 것은 왜 중요할까요?
-크롬(Chrome): 약 62%
-사파리(Safari): 약 19%
-파이어폭스(Firefox): 약 8%
-엣지(Edge): 약 6%
-기타 브라우저: 약 5%
-
-웹 사이트 개발에 영향을 미칩니다.
-브라우저별로 웹 표준을 준수하는 정도가 다르기 때문에, 브라우저별 점유율을 고려하지 않고 웹 사이트를 개발할 경우 특정 브라우저에서는 정상적으로 작동하지 않을 수 있습니다.
-
-마케팅에 영향을 미칩니다.
-브라우저별 점유율은 사용자들이 어떤 브라우저를 선호하는지를 보여주기 때문에, 해당 브라우저를 이용한 마케팅 전략을 세울 수 있습니다.
-
-보안에 영향을 미칩니다.
-점유율이 높은 브라우저일수록 악성코드 등의 보안 위협을 받을 가능성이 높습니다. 따라서 브라우저별 보안 취약점을 파악하고 이를 개선하는 것이 중요합니다.
-
-브라우저 경쟁력을 분석할 수 있습니다.
-브라우저별 점유율을 분석하면, 각 브라우저의 경쟁력을 파악할 수 있습니다. 이를 통해, 브라우저 개발자들은 경쟁에서 우위에 서기 위해 어떤 전략을 세워야 하는지를 파악할 수 있습니다.
-
+  ```
+  크롬(Chrome): 약 62%
+  사파리(Safari): 약 19%
+  파이어폭스(Firefox): 약 8%
+  엣지(Edge): 약 6%
+  기타 브라우저: 약 5%
+  
+  웹 사이트 개발에 영향을 미칩니다.
+  브라우저별로 웹 표준을 준수하는 정도가 다르기 때문에, 브라우저별 점유율을 고려하지 않고 웹 사이트를 개발할 경우 특정 브라우저에서는 정상적으로 작동하지 않을 수 있습니다.
+  마케팅에 영향을 미칩니다.
+  브라우저별 점유율은 사용자들이 어떤 브라우저를 선호하는지를 보여주기 때문에, 해당 브라우저를 이용한 마케팅 전략을 세울 수 있습니다.
+  보안에 영향을 미칩니다.
+  점유율이 높은 브라우저일수록 악성코드 등의 보안 위협을 받을 가능성이 높습니다. 따라서 브라우저별 보안 취약점을 파악하고 이를 개선하는 것이 중요합니다.
+  브라우저 경쟁력을 분석할 수 있습니다.
+  브라우저별 점유율을 분석하면, 각 브라우저의 경쟁력을 파악할 수 있습니다. 이를 통해, 브라우저 개발자들은 경쟁에서 우위에 서기 위해 어떤 전략을 세워야 하는지를 파악할 수 있습니다.
+  ```
   * 브라우저 엔진(렌더링 엔진)이란 무엇일까요? 어떤 브라우저들이 어떤 엔진을 쓸까요?
-브라우저 엔진 또는 렌더링 엔진은 HTML, CSS 및 JavaScript와 같은 웹 페이지의 코드를 브라우저가 이해할 수 있는 형태로 변환하여 화면에 표시하는 역할을 수행하는 소프트웨어입니다. 브라우저 엔진은 웹 브라우저의 핵심 부분 중 하나이며, 사용자가 보는 웹 페이지의 레이아웃, 스타일, 콘텐츠 및 기능을 처리합니다.
-
-다양한 브라우저가 있지만, 주요 브라우저의 엔진은 다음과 같습니다.
-
-크롬(Chrome): Blink 엔진 (Google에서 개발)
-파이어폭스(Firefox): Gecko 엔진 (Mozilla에서 개발)
-사파리(Safari): WebKit 엔진 (Apple에서 개발)
-엣지(Edge): Blink 엔진 (Microsoft에서 개발)
-브라우저 엔진은 각각의 브라우저에서 지원하는 웹 표준과 기능, 성능, 안정성 등이 다르기 때문에, 웹 개발자들은 다양한 엔진을 이해하고 각각의 특성을 고려하여 웹 페이지를 개발해야 합니다.
+  ```
+  브라우저 엔진 또는 렌더링 엔진은 HTML, CSS 및 JavaScript와 같은 웹 페이지의 코드를 브라우저가 이해할 수 있는 형태로 변환하여 화면에 표시하는 역할을 수행하는 소프트웨어입니다. 브라우저 엔진은 웹 브라우저의 핵심 부분 중 하나이며, 사용자가 보는 웹 페이지의 레이아웃, 스타일, 콘텐츠 및 기능을 처리합니다.
+  다양한 브라우저가 있지만, 주요 브라우저의 엔진은 다음과 같습니다.
+  
+  크롬(Chrome): Blink 엔진 (Google에서 개발)
+  파이어폭스(Firefox): Gecko 엔진 (Mozilla에서 개발)
+  사파리(Safari): WebKit 엔진 (Apple에서 개발)
+  엣지(Edge): Blink 엔진 (Microsoft에서 개발)
+  브라우저 엔진은 각각의 브라우저에서 지원하는 웹 표준과 기능, 성능, 안정성 등이 다르기 때문에, 웹 개발자들은 다양한 엔진을 이해하고 각각의 특성을 고려하여 웹 페이지를 개발해야 합니다.
+  ```
 
   * 모바일 시대 이후, 최근에 출시된 브라우저들은 어떤 특징을 가지고 있을까요?
+```
 모바일 최적화: 모바일 기기에서의 사용성을 고려한 최적화가 이루어졌습니다. 모바일 환경에서의 터치 인터페이스, 제스처 제어, 반응형 레이아웃 등을 지원하여 모바일 사용자들에게 더 나은 경험을 제공합니다.
 
 속도 향상: 브라우저 엔진의 발전과 함께 더욱 빠른 속도를 제공합니다. 특히, 브라우저 캐시 및 프리페칭 기술 등을 이용하여 페이지 로딩 속도를 높였습니다.
@@ -117,14 +123,17 @@ IE는 보안 취약점이 많이 발견되어 사용자의 개인정보가 유
 인공지능 기술 도입: 최근에는 인공지능 기술을 이용하여 더욱 편리하고 개인화된 웹 서비스를 제공합니다. 예를 들어, 취향에 맞는 콘텐츠 추천, 음성 인식 검색 기능 등이 있습니다.
 
 에코 시스템: 브라우저 제작사들은 자사의 생태계를 강화하기 위해 다양한 기술과 서비스를 제공합니다. 이를 통해 브라우저 사용자들에게 더욱 편리한 환경을 제공하고, 생태계의 확장을 위한 시너지 효과를 기대할 수 있습니다.
-
+```
 * HTML 문서는 어떤 구조로 이루어져 있나요?
+```
 구조를 담당하는 요소 (Semantic Elements)
 HTML 문서는 마크업 언어로 웹 페이지의 구조를 정의합니다. 이를 담당하는 요소들은 시맨틱 요소(Semantic Elements)라고 하며, 웹 페이지의 의미와 구조를 명확하게 전달합니다.
 콘텐츠를 담당하는 요소
 콘텐츠를 담당하는 요소는 HTML 문서에서 실제로 보여지는 내용을 담당합니다. 예를 들면 <h1>~<h6>, <p>, <img>, <a>, <ul>, <ol>, <li>, <table>, <form> 등이 있습니다.
+```
 
   * `<head>`에 자주 들어가는 엘리먼트들은 어떤 것이 있고, 어떤 역할을 할까요?
+```
 <title> 요소
 <title> 요소는 웹 페이지의 제목을 정의합니다. 브라우저의 제목 표시줄에 표시되며, 검색 엔진에서 페이지 제목으로 사용됩니다.
 
@@ -136,15 +145,17 @@ HTML 문서는 마크업 언어로 웹 페이지의 구조를 정의합니다. 
 
 <script> 요소
 <script> 요소는 자바스크립트 코드를 정의합니다. 이를 통해 웹 페이지의 동작을 제어하거나, 서버와의 데이터 통신 등을 수행할 수 있습니다.
-
+```
   * 시맨틱 태그는 무엇일까요?
+```
 시맨틱 태그는 웹 페이지의 구조와 의미를 나타내는 태그를 말합니다. 즉, 해당 태그가 어떤 내용을 포함하고 있는지를 의미하는 것입니다.
 
 시맨틱 태그를 사용하면 웹 페이지의 구조가 명확하게 나타나기 때문에, 검색 엔진이 페이지의 내용을 더 잘 이해하고 분석할 수 있으며, 웹 페이지의 접근성이 향상됩니다. 또한, 시맨틱 태그를 사용하면 CSS 스타일링이 더욱 쉬워지고, 웹 페이지의 가독성도 향상됩니다.
 
 시맨틱 태그의 예시로는 <header>, <nav>, <main>, <article>, <section>, <aside>, <footer> 등이 있습니다. 이러한 태그들은 해당하는 영역의 내용을 더 명확하게 정의하며, 웹 페이지의 구조와 의미를 더욱 분명하게 표현합니다
-
-    * 시맨틱 엘리먼트를 사용하면 어떤 점이 좋을까요?
+```
+  * 시맨틱 엘리먼트를 사용하면 어떤 점이 좋을까요?
+```
 검색 엔진 최적화 (SEO): 시맨틱 엘리먼트를 사용하면 웹 페이지의 내용과 구조를 검색 엔진이 더욱 잘 이해할 수 있습니다. 이는 검색 엔진 최적화를 향상시키는데 도움을 줄 수 있습니다.
 
 웹 접근성: 시맨틱 엘리먼트를 사용하면 웹 페이지의 구조와 내용을 보다 명확하게 표현할 수 있어, 스크린 리더 등의 보조 기술을 사용하는 사용자들에게 웹 페이지를 이해하기 쉽게 만들어줍니다.
@@ -152,9 +163,10 @@ HTML 문서는 마크업 언어로 웹 페이지의 구조를 정의합니다. 
 유지보수: 시맨틱 엘리먼트를 사용하면 다른 개발자들이 나의 작성한 코드를 이해하고 수정하기 쉬워집니다. 이는 코드의 유지보수를 보다 쉽게 할 수 있게 만들어줍니다.
 
 가독성: 시맨틱 엘리먼트를 사용하면 코드의 가독성이 향상됩니다. 이는 코드의 가독성을 높이고 유지보수를 쉽게 하는데 도움을 줍니다.
-
-    * `<section>`과 `<div>`, `<header>`, `<footer>`, `<article>` 엘리먼트의 차이점은 무엇인가요?
+```
+  * `<section>`과 `<div>`, `<header>`, `<footer>`, `<article>` 엘리먼트의 차이점은 무엇인가요?
   * 블록 레벨 엘리먼트와 인라인 엘리먼트는 어떤 차이가 있을까요?
+```
 <section>: 문서의 일반적인 구획을 표시합니다. 보통 제목(<h1>~<h6>)과 함께 사용됩니다.
 <div>: 구획을 나누기 위해 사용되며, 목적에 따라 다양한 방식으로 사용될 수 있습니다.
 <header>: 섹션 또는 페이지의 제목을 나타냅니다. 로고, 검색 폼, 작성자 이름 등과 함께 사용될 수 있습니다.
@@ -165,7 +177,7 @@ HTML 문서는 마크업 언어로 웹 페이지의 구조를 정의합니다. 
 블록 레벨 엘리먼트는 새로운 줄에서 시작하여 새로운 블록을 만들고, 전체 너비를 차지합니다. 반면 인라인 엘리먼트는 줄 안에서만 사용되며, 컨텐츠의 너비만큼만 차지합니다.
 블록 레벨 엘리먼트는 다른 블록 레벨 엘리먼트나 인라인 엘리먼트를 포함할 수 있습니다. 반면 인라인 엘리먼트는 다른 인라인 엘리먼트를 포함할 수 있지만, 블록 레벨 엘리먼트를 포함할 수는 없습니다.
 블록 레벨 엘리먼트는 컨텐츠를 구성하기 위해 사용되며, 인라인 엘리먼트는 텍스트와 같은 컨텐츠의 일부분을 나타내기 위해 사용됩니다.
-
+```
 
 ## Quest
 * [이 화면](screen.png)의 정보를 HTML 문서로 표현해 보세요. 다만 CSS를 전혀 사용하지 않고, 문서의 구조가 어떻게 되어 있는지를 파악하여 구현해 보세요.
diff --git a/Quest02/README.md b/Quest02/README.md
index d4ac9e20e..8f9ba4af7 100644
--- a/Quest02/README.md
+++ b/Quest02/README.md
@@ -22,29 +22,34 @@
 
 ## Checklist
 * CSS를 HTML에 적용하는 세 가지 방법은 무엇일까요?
+```
 내부 스타일 시트 (Internal Style Sheet) : HTML 문서 안에서 <style> 태그를 사용하여 스타일 정보를 작성하는 방법입니다. 이 방법은 한 페이지에서만 스타일을 적용하고, 해당 페이지에서만 사용되는 스타일을 작성할 때 유용합니다.
 외부 스타일 시트 (External Style Sheet) : CSS 파일을 작성하여 HTML 문서에서 <link> 태그를 사용하여 CSS 파일을 불러오는 방법입니다. 이 방법은 여러 페이지에서 공통적으로 사용되는 스타일을 작성할 때 유용합니다.
 인라인 스타일 (Inline Style) : HTML 태그 안에서 style 속성을 사용하여 스타일 정보를 작성하는 방법입니다. 이 방법은 특정 요소에만 스타일을 적용하고, 다른 요소와 구분하여 스타일을 작성할 때 유용합니다.
-
+```
   * 세 가지 방법 각각의 장단점은 무엇일까요?
-Inline Style
-장점: 스타일을 적용하려는 HTML 요소에 직접 스타일을 적용할 수 있어 간단하고 빠르게 스타일링이 가능합니다.
-단점: 유지보수와 확장이 어려워지며, 스타일링을 많이 하게 될 경우 코드가 복잡해지고 HTML 코드가 지저분해질 수 있습니다.
-Internal Style
-장점: HTML 문서 내부에서 CSS 코드를 작성하여 관리가 용이합니다.
-단점: 여러 페이지에 같은 스타일을 적용하고자 할 경우, 중복되는 스타일 코드를 일일이 작성해야 하므로 코드의 중복이 발생할 수 있습니다.
-External Style
-장점: 여러 HTML 문서에서 공통적으로 사용되는 스타일을 별도의 CSS 파일로 분리하여 관리할 수 있습니다. HTML 문서 내부의 스타일 코드가 줄어들어 가독성이 좋아지며, 스타일을 변경할 경우 CSS 파일만 수정하면 되므로 유지보수와 확장이 용이합니다.
-단점: 외부 CSS 파일을 로드해야 하기 때문에 HTML 문서를 렌더링하는 데 시간이 조금 더 걸립니다.
+  ```
+  Inline Style
+  장점: 스타일을 적용하려는 HTML 요소에 직접 스타일을 적용할 수 있어 간단하고 빠르게 스타일링이 가능합니다.
+  단점: 유지보수와 확장이 어려워지며, 스타일링을 많이 하게 될 경우 코드가 복잡해지고 HTML 코드가 지저분해질 수 있습니다.
+  Internal Style
+  장점: HTML 문서 내부에서 CSS 코드를 작성하여 관리가 용이합니다.
+  단점: 여러 페이지에 같은 스타일을 적용하고자 할 경우, 중복되는 스타일 코드를 일일이 작성해야 하므로 코드의 중복이 발생할 수 있습니다.
+  External Style
+  장점: 여러 HTML 문서에서 공통적으로 사용되는 스타일을 별도의 CSS 파일로 분리하여 관리할 수 있습니다. HTML 문서 내부의 스타일 코드가 줄어들어 가독성이 좋아지며, 스타일을 변경할 경우 CSS 파일만 수정하면 되므로 유지보수와 확장이 용이합니다.
+  단점: 외부 CSS 파일을 로드해야 하기 때문에 HTML 문서를 렌더링하는 데 시간이 조금 더 걸립니다.
+  ```
 
 * CSS 규칙의 우선순위는 어떻게 결정될까요?
+```
 명시도(Specificity): 선택자의 구체성에 따라 우선순위가 결정됩니다. 선택자의 구체성은 아이디 선택자의 개수, 클래스 선택자와 속성 선택자의 개수, 태그 선택자의 개수 등으로 결정됩니다. 예를 들어, 아이디 선택자가 클래스 선택자보다 우선순위가 높습니다.
 
 중요도(Importance): !important 키워드가 사용된 규칙은 다른 규칙보다 우선시됩니다.
 
 소스 순서: 동일한 명시도와 중요도를 가진 규칙은 나중에 나온 규칙이 우선시됩니다.
-
+```
 * CSS의 박스모델은 무엇일까요? 박스가 화면에서 차지하는 크기는 어떻게 결정될까요?
+```
 콘텐츠 영역(Content Area): 요소에 실제로 들어가는 텍스트나 이미지 등의 콘텐츠가 들어가는 영역입니다.
 
 패딩 영역(Padding Area): 콘텐츠 영역과 테두리(Border) 사이의 여백 영역입니다.
@@ -62,8 +67,9 @@ External Style
 패딩 영역과 테두리 영역의 크기는 CSS 속성을 이용해 지정할 수 있습니다. 예를 들어, padding 속성과 border 속성을 이용해 패딩 영역과 테두리 영역의 크기를 지정할 수 있습니다.
 
 마진 영역의 크기는 다른 요소와의 간격을 나타내는 영역으로, CSS 속성을 이용해 지정할 수 있습니다. 예를 들어, margin 속성을 이용해 마진 영역의 크기를 지정할 수 있습니다.
-
+```
 * `float` 속성은 왜 좋지 않을까요?
+```
 의도하지 않은 요소에도 영향을 미침
 float 속성이 적용된 요소는 주변의 다른 요소들과 위치 상태를 변경할 수 있습니다. 이러한 특성은 원치 않는 결과를 초래할 수 있습니다. 또한, float 속성이 적용된 요소와 주변 요소 간에 간격이 자동으로 생기기 때문에 레이아웃을 유연하게 조절하기 어렵습니다.
 
@@ -75,8 +81,9 @@ float 속성은 요소를 위치시키기 위한 목적으로만 사용하기 
 
 접근성 문제
 float 속성은 화면 낭독기 등의 보조 기기에서 레이아웃을 이해하는 데 문제가 생길 수 있습니다. 또한, 키보드 네비게이션 등에도 영향을 미칠 수 있습니다.
-
+```
 * Flexbox(Flexible box)와 CSS Grid의 차이와 장단점은 무엇일까요?
+```
 Flexbox(Flexible box)
 단일 차원(행 또는 열)에서 요소들의 위치를 지정하는 데 사용됩니다.
 요소들을 정렬하고, 간격을 조절하며, 순서를 변경하는 데 유용합니다.
@@ -103,13 +110,14 @@ CSS Grid
 간단한 레이아웃에서는 사용하기에 적합하지 않습니다.
 2차원 레이아웃을 다루므로 빠르게 렌더링되지 않을 수 있습니다.
 모든 브라우저에서 완전히 지원되지 않을 수 있습니다.
-
+```
 * CSS의 비슷한 요소들을 어떤 식으로 정리할 수 있을까요?
+```
 Selectors: 선택자를 사용하여 비슷한 스타일을 적용할 요소들을 그룹화할 수 있습니다. 예를 들어, 모든 <h1> 요소에 스타일을 적용하고 싶다면, 다음과 같이 선택자를 사용합니다.
 Classes: 클래스를 사용하여 HTML 요소를 그룹화할 수 있습니다. 클래스는 여러 요소에서 재사용할 수 있습니다. 예를 들어, 모든 제목에 대해 같은 스타일을 적용하지만, 다른 스타일을 적용하고 싶은 경우, 다음과 같이 클래스를 사용합니다.
 ID: ID는 HTML 요소를 고유하게 식별하는 데 사용됩니다. ID는 한 번만 사용할 수 있으며 CSS에서 특정 요소에 스타일을 적용하려는 경우 사용됩니다. 예를 들어, 한 요소에 대해 특정 스타일을 적용하고 싶은 경우, 다음과 같이 ID를 사용합니다.
 Inheritance: 부모 요소에 적용된 스타일이 자식 요소에도 적용되는 특성을 이용하여, 비슷한 스타일을 적용할 요소들을 그룹화할 수 있습니다. 예를 들어, 모든 제목 요소에 대해 글꼴 색상을 빨강색으로 지정하고 싶은 경우, 다음과 같이 적용할 수 있습니다.
-
+```
 ## Quest
 * Quest 01에서 만들었던 HTML을 바탕으로, [이 그림](screen.png)의 레이아웃과 CSS를 최대한 비슷하게 흉내내 보세요. 꼭 완벽히 정확할 필요는 없으나 align 등의 속성은 일치해야 합니다.
 * **주의사항: 되도록이면 원래 페이지의 CSS를 참고하지 말고 아무것도 없는 백지에서 시작해 보도록 노력해 보세요!**
diff --git a/Quest03/README.md b/Quest03/README.md
index 7cd27da9c..80bd5e64c 100644
--- a/Quest03/README.md
+++ b/Quest03/README.md
@@ -20,18 +20,20 @@
 
 ## Checklist
 * 자바스크립트는 버전별로 어떻게 변화하고 발전해 왔을까요?
-
+```
 자바스크립트(JavaScript)는 초기에는 웹 페이지의 동적인 기능을 구현하는 데 주로 사용되었습니다. 하지만 시간이 지남에 따라 자바스크립트는 웹 개발 분야에서 매우 중요한 언어로 자리 잡았습니다.
-
+```
   * 자바스크립트의 버전들을 가리키는 ES5, ES6, ES2016, ES2017 등은 무엇을 이야기할까요?
+  ```
   ES란 Ecma Script의 준말로 JavaScript명세서(표준,규격)를 의미함
   ES5는 "use strict"선언을 추가하여 코드 실행을 엄격하게함
   ES6는 클래스,모듈,템플릿 리터럴 등의 새로운 기능 추가.
   ES2016은 includes(배열 내장 함수 EX.['a','b','c'].indexOf('a') > -1가 ['a', 'b', 'c'].includes('a') 처럼 간결해짐),Exponentiation operator추가(제곱 연산자 EX.Math와 pow함수 대신 ** 연산자로 가능)
   ES2017은 문자 여백 기능,Object.values(),Object.entries(),Object.getOwnPropertyDescriptors(),Trailing commas,async/await(기존의 Promise보다 가독성이 좋은 코드 작성 가능) 추가
   https://junhobaik.github.io/es2016-es2020/#objectgetownpropertydescriptors 자료 참조
-
+  ```
   * 자바스크립트의 표준은 어떻게 제정될까요?
+  ```
   ECMA International에서는 ECMAScript라는 이름으로 자바스크립트의 표준을 제정합니다. 
   ECMAScript는 자바스크립트를 포함하는 스크립트 언어의 표준 규격을 의미하며, 현재까지 ECMAScript 2022(ES12)까지 발표되었습니다.
   ECMAScript 표준은 TC39(Technical Committee 39)이라는 위원회에서 제정됩니다. 
@@ -39,15 +41,16 @@
   이 위원회는 모집적인 방식으로 구성되어 있으며, 인터넷 엔진 개발자, 브라우저 개발자, 프로그래밍 언어 전문가 등이 참여합니다.
   ECMAScript 표준은 모든 브라우저에서 일관성 있게 자바스크립트를 구현할 수 있도록 합니다. 
   따라서 개발자들은 ECMAScript 표준에 맞게 자바스크립트 코드를 작성하여, 모든 브라우저에서 동일한 결과를 얻을 수 있습니다.
-
+  ```
 * 자바스크립트의 문법은 다른 언어들과 비교해 어떤 특징이 있을까요?
+```
 1.객체 기반 언어
 2.함수형 언어
 3.동적 타입 언어
 4.프로토타입 기반 언어
 5.세미콜론 생략 가능
 6.Hoisting
-
+```
   * 자바스크립트에서 반복문을 돌리는 방법은 어떤 것들이 있을까요?
 * 자바스크립트를 통해 DOM 객체에 CSS Class를 주거나 없애려면 어떻게 해야 하나요?
   * IE9나 그 이전의 옛날 브라우저들에서는 어떻게 해야 하나요?
diff --git a/Quest04/README.md b/Quest04/README.md
index f675f89fe..534173d83 100644
--- a/Quest04/README.md
+++ b/Quest04/README.md
@@ -24,6 +24,7 @@
 
 ## Checklist
 * 객체지향 프로그래밍은 무엇일까요?
+```
 객체지향 프로그래밍(Object-Oriented Programming, OOP)은 프로그램을 여러 개의 독립된 객체(Object)로 나누고, 이러한 객체들간의 상호작용을 통해 프로그래밍 하는 방법론입니다. 객체는 속성(Attribute)와 메서드(Method)로 이루어져 있으며, 속성은 객체의 상태를 나타내고, 메서드는 객체가 수행할 수 있는 행동을 나타냅니다. 이러한 객체들은 클래스(Class)라는 틀을 이용해 생성됩니다.
 
 객체지향 프로그래밍의 핵심 개념으로는 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism)이 있습니다. 캡슐화는 객체의 속성과 메서드를 외부로부터 보호하기 위해 사용되며, 상속은 부모 클래스의 속성과 메서드를 자식 클래스에서 재사용하는 것을 말하며, 다형성은 객체지향에서 한 객체가 다른 객체와 다르게 동작할 수 있는 능력을 말합니다.
@@ -31,9 +32,9 @@
 객체지향 프로그래밍은 모듈성과 재사용성이 높으며, 대규모 프로그램을 개발하는데 매우 유용합니다. 또한, 객체 간의 의존성을 줄이기 때문에 유지보수와 개발이 용이하며, 소프트웨어 개발 생산성과 품질을 향상시킬 수 있습니다.
 
 https://www.codestates.com/blog/content/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%ED%8A%B9%EC%A7%95 참조
-
+```
   * `#`로 시작하는 프라이빗 필드는 왜 필요한 것일까요? 정보를 은폐(encapsulation)하면 어떤 장점이 있을까요?
-
+```
 #로 시작하는 프라이빗 필드(Private Field)는 해당 필드를 클래스 외부에서 접근할 수 없도록 접근 제어를 하는 것을 말합니다. 이는 정보 은폐(Encapsulation)의 한 예로, 클래스 내부의 데이터와 동작을 외부로부터 보호하기 위해 사용됩니다.
 
 정보 은폐는 객체지향 프로그래밍의 핵심 개념 중 하나로, 객체 내부의 구현 상세를 외부로부터 숨기고, 필요한 기능만을 외부로 노출함으로써 객체의 안정성과 유지보수성을 높이는 데 큰 역할을 합니다.
@@ -47,51 +48,55 @@ https://www.codestates.com/blog/content/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%E
 유연성과 확장성: 정보 은폐를 통해 객체의 내부 구현 상세를 숨기면, 내부 구현 상세가 변경되어도 외부 인터페이스는 변경되지 않습니다. 이는 유연성과 확장성을 높일 수 있습니다.
 
 따라서, #로 시작하는 프라이빗 필드를 사용하여 정보 은폐를 구현함으로써, 안정성과 유지보수성을 높이고, 코드의 재사용성과 유연성, 확장성을 향상시킬 수 있습니다.
-
+```
   * 다형성이란 무엇인가요? 다형성은 어떻게 코드 구조의 정리를 도와주나요?
+  ```
   다형성(polymorphism)은 객체지향 프로그래밍의 중요한 특징 중 하나로, 같은 코드가 다른 타입의 객체에 대해서 다른 방식으로 동작할 수 있는 능력을 의미합니다. 즉, 다형성은 같은 이름의 메서드나 연산자가 다른 객체에서 서로 다른 방식으로 작동할 수 있도록 함으로써 객체의 타입에 종속되지 않는 코드를 작성할 수 있게 합니다.
   다형성은 코드 구조의 정리를 도와줍니다. 예를 들어, 상속 관계에 있는 클래스들이 같은 메서드를 구현하지만 각각의 클래스에서 메서드가 다르게 동작하는 경우, 부모 클래스에 공통된 메서드를 작성하고 자식 클래스에서 메서드를 오버라이딩(override)함으로써 코드 중복을 제거할 수 있습니다. 또한, 인터페이스를 사용하여 다형성을 구현하면 인터페이스를 구현하는 다양한 클래스에서 동일한 메서드를 구현함으로써 코드의 재사용성을 높일 수 있습니다.
   다형성은 또한 유지보수성을 향상시키는데도 도움이 됩니다. 만약 새로운 객체 타입이 추가될 경우, 해당 객체의 메서드를 구현하면 기존의 코드를 수정하지 않고도 새로운 타입에 대한 지원이 가능합니다. 이는 객체 지향 프로그래밍에서 개방-폐쇄 원칙(Open-Closed Principle)을 준수하는 것에도 도움이 됩니다.
-
+  ```
   * 상속이란 무엇인가요? 상속을 할 때의 장점과 단점은 무엇인가요?
-상속(Inheritance)이란 객체 지향 프로그래밍에서 기존의 클래스를 재사용하여 새로운 클래스를 작성하는 것을 말합니다. 새로운 클래스는 상속받은 클래스의 특징을 그대로 가지면서 새로운 특성을 추가하거나 기존 특성을 변경할 수 있습니다.
-
-상속의 장점
-
-코드 재사용성이 높아진다: 상속을 통해 기존 클래스를 재사용할 수 있기 때문에 코드의 중복을 피하고 코드의 재사용성이 높아집니다.
-코드의 확장성이 높아진다: 상속을 통해 새로운 클래스를 만들 때 기존 클래스의 기능을 유지하면서 새로운 기능을 추가할 수 있기 때문에 코드의 확장성이 높아집니다.
-유지보수가 용이해진다: 기존 클래스의 수정이 필요한 경우, 상속을 받은 클래스에서만 수정하면 되기 때문에 유지보수가 용이해집니다.
-
-상속의 단점
-
-상속 구조가 복잡해진다: 클래스 간의 상속 구조가 복잡해지면 코드의 가독성이 떨어지고, 코드의 이해와 디버깅이 어려워집니다.
-상위 클래스의 변경이 하위 클래스에 영향을 미칠 수 있다: 상위 클래스의 변경이 하위 클래스에 영향을 미칠 수 있기 때문에, 상위 클래스를 변경할 경우 하위 클래스를 일일이 검토해야 하는 번거로움이 있습니다.
-상속 관계가 많아질수록 설계가 복잡해진다: 상속 관계가 많아질수록 설계가 복잡해지고 유지보수가 어려워집니다. 이를 해결하기 위해서는 상속보다는 인터페이스를 활용하는 것이 더 적합할 수 있습니다.
-
+  ```
+  상속(Inheritance)이란 객체 지향 프로그래밍에서 기존의 클래스를 재사용하여 새로운 클래스를 작성하는 것을 말합니다. 새로운 클래스는 상속받은 클래스의 특징을 그대로 가지면서 새로운 특성을 추가하거나 기존 특성을 변경할 수 있습니다.
+  
+  상속의 장점
+  코드 재사용성이 높아진다: 상속을 통해 기존 클래스를 재사용할 수 있기 때문에 코드의 중복을 피하고 코드의 재사용성이 높아집니다.
+  코드의 확장성이 높아진다: 상속을 통해 새로운 클래스를 만들 때 기존 클래스의 기능을 유지하면서 새로운 기능을 추가할 수 있기 때문에 코드의 확장성이 높아집니다.
+  유지보수가 용이해진다: 기존 클래스의 수정이 필요한 경우, 상속을 받은 클래스에서만 수정하면 되기 때문에 유지보수가 용이해집니다.
+  
+  상속의 단점
+  상속 구조가 복잡해진다: 클래스 간의 상속 구조가 복잡해지면 코드의 가독성이 떨어지고, 코드의 이해와 디버깅이 어려워집니다.
+  상위 클래스의 변경이 하위 클래스에 영향을 미칠 수 있다: 상위 클래스의 변경이 하위 클래스에 영향을 미칠 수 있기 때문에, 상위 클래스를 변경할 경우 하위 클래스를 일일이 검토해야 하는 번거로움이 있습니다.
+  상속 관계가 많아질수록 설계가 복잡해진다: 상속 관계가 많아질수록 설계가 복잡해지고 유지보수가 어려워집니다. 이를 해결하기 위해서는 상속보다는 인터페이스를 활용하는 것이 더 적합할 수 있습니다.
+  ```
   * OOP의 합성(Composition)이란 무엇인가요? 합성이 상속에 비해 가지는 장점은 무엇일까요?
+  ```
   OOP에서 합성(Composition)은 객체가 다른 객체를 포함하는 것을 의미합니다. 즉, 객체가 다른 객체를 조립하여 새로운 기능을 제공하거나, 객체 간의 관계를 형성하는 것입니다.
 
   합성은 상속과는 다른 객체 간의 관계를 형성하는 방법입니다. 상속은 is-a 관계를 형성하는 반면, 합성은 has-a 관계를 형성합니다. 예를 들어, 자동차는 엔진을 가지고 있으므로 자동차와 엔진은 합성 관계입니다. 이러한 관계를 코드에서는 클래스 간의 객체를 생성하거나 메소드를 호출하는 방식으로 구현할 수 있습니다.
   
   합성의 장점은 상속과 비교하여 더 유연하고 확장성이 높다는 것입니다. 상속은 부모 클래스의 변경이 자식 클래스에 영향을 미치며, 하위 클래스에서 재정의한 메서드가 상위 클래스에서 변경되면 예상치 못한 결과를 초래할 수 있습니다. 하지만 합성은 객체를 조립하여 기능을 확장하기 때문에 변경이 발생해도 영향이 덜하며, 객체 간의 결합도를 낮출 수 있습니다. 또한 합성을 이용하면 코드 재사용성도 높아집니다.
-
+  ```
 * 자바스크립트의 클래스는 어떻게 정의할까요?
+```
 JavaScript에서 클래스를 정의하는 방법은 ES6(ES2015)에서 추가된 class 키워드를 사용하는 것입니다. 클래스는 객체를 생성하기 위한 템플릿으로서, 속성과 메소드를 정의할 수 있습니다.
-
+```
   * 프로토타입 기반의 객체지향 프로그래밍은 무엇일까요?
+  ```
   프로토타입 기반의 객체지향 프로그래밍(Prototype-based Object-Oriented Programming)은 클래스(class)가 없는 객체지향 프로그래밍 패러다임입니다. 대신, 객체(object)를 직접 생성하거나 다른 객체를 복제하여 새로운 객체를 만듭니다. 이러한 객체를 프로토타입(prototype)이라고 부릅니다.
   
   객체는 다른 객체를 상속받아 새로운 기능을 추가할 수 있으며, 객체는 객체를 생성할 때 프로토타입을 지정할 수 있습니다. 이를 통해 객체들은 프로토타입의 속성과 메서드를 상속받아 사용할 수 있습니다.
   
   JavaScript는 프로토타입 기반의 객체지향 프로그래밍을 기본적으로 지원합니다. 다른 언어들 역시 이러한 패러다임을 지원하며, 프로토타입 기반의 객체지향 프로그래밍은 함수형 프로그래밍과 함께 최근에는 인기 있는 프로그래밍 패러다임 중 하나입니다.
-
+  ```
   * 자바스크립트의 클래스는 이전의 프로토타입 기반의 객체지향 구현과 어떤 관계를 가지고 있나요?
+  ```
   자바스크립트의 클래스는 이전에 존재하던 프로토타입 기반의 객체지향 구현과 밀접한 관계를 가지고 있습니다. 클래스는 ES6(ECMAScript 2015)부터 새롭게 도입된 개념 중 하나로, 이전에는 프로토타입을 사용하여 객체를 생성하고 상속을 구현했었습니다.
   
   클래스는 생성자 함수와 프로토타입을 사용하여 객체를 생성하고 상속을 구현하는 것과 유사합니다. 클래스 내부에서 생성자 함수를 정의하고, 프로토타입 객체를 사용하여 메서드를 구현할 수 있습니다. 또한, 클래스 내부에서 상속을 구현할 수 있으며, 상속 관계를 형성하는 것도 이전과 동일합니다.
   
   하지만 클래스는 프로토타입 기반의 객체지향 구현과 달리, 클래스와 인스턴스를 명확하게 구분하고, 클래스 내부에서만 사용할 수 있는 private한 변수나 메서드를 구현할 수 있습니다. 또한, 클래스는 상속 구현 방식이 간단하고 직관적이어서, 이전의 프로토타입 기반 구현보다 코드의 가독성과 유지보수성을 높일 수 있습니다.
-
+  ```
 ## Quest
 * 웹 상에서 동작하는 간단한 바탕화면 시스템을 만들 예정입니다.
 * 요구사항은 다음과 같습니다:
diff --git a/Quest05/README.md b/Quest05/README.md
index 61f5924da..3b0383ad9 100644
--- a/Quest05/README.md
+++ b/Quest05/README.md
@@ -17,11 +17,13 @@
 
 ## Checklist
 * 관심사의 분리 원칙이란 무엇인가요? 웹에서는 이러한 원칙이 어떻게 적용되나요?
+```
 관심사의 분리(Separation of Concerns, SoC) 원칙은 소프트웨어 설계의 일반적인 원칙 중 하나로, 각각의 컴포넌트나 모듈이 자신의 역할에 집중하고, 다른 컴포넌트와 가능한 적은 결합도를 가지도록 설계하는 것입니다. 즉, 서로 다른 관심사를 가진 부분들을 서로 분리하여 각 부분을 독립적으로 변경할 수 있도록 만드는 것입니다.
 
 웹에서는 관심사의 분리 원칙을 다양한 방식으로 적용할 수 있습니다. 예를 들어, HTML은 문서의 구조를 정의하고, CSS는 문서의 스타일을 지정하며, JavaScript는 문서의 동작을 구현하는 등 각각의 역할에 맞추어 분리되어 있습니다. 또한, MVC(Model-View-Controller) 패턴을 적용하여, 데이터 모델, UI, 비즈니스 로직 등 서로 다른 관심사를 분리하여 개발할 수 있습니다. 또한, 모듈화를 통해 코드를 관심사 단위로 분리하여 유지보수성을 향상시킬 수 있습니다. 이러한 방식으로 웹에서 관심사의 분리 원칙을 적용하면 코드의 가독성과 유지보수성을 향상시킬 수 있습니다.
-
+```
 * 객체지향의 SOLID 원칙이란 무엇인가요? 이 원칙을 구체적인 예를 들어 설명할 수 있나요?
+```
 S (SRP: Single Responsibility Principle) : 단일 책임 원칙
 O (OCP: Open/Closed Principle) : 개방-폐쇄 원칙
 L (LSP: Liskov Substitution Principle) : 리스코프 치환 원칙
@@ -61,14 +63,15 @@ DIP 원칙 위반 예제
 게임을 예로 들면 여러가지 무기들을 장착하는 캐릭터가 있는데, 캐릭터 클래스가 인스턴스화 될 때에 캐릭터 이름과 체력 그리고 장착하는 무기를 입력값으로 받아 초기화하고 캐릭터 클래스내에 필드 변수로서 클래스탑의 변수를 저장해놓고, 공격 매서드를 수행하면 무기 클래스의 메서드가 실행되어 데미지가 가하는 형태.
 즉, 캐릭터 인스턴스 생성 시 무기종류에 의존성을 가지게되어, 공격 메소드 역시 무기 종류에 의존성을 가지게 된다.
 https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-DIP-%EC%9D%98%EC%A1%B4-%EC%97%AD%EC%A0%84-%EC%9B%90%EC%B9%99 참조
-
+```
 * 로컬 스토리지란 무엇인가요? 로컬 스토리지의 내용을 개발자 도구를 이용해 확인하려면 어떻게 해야 할까요?
+```
 로컬 스토리지(Local Storage)는 HTML5에서 제공하는 웹 브라우저의 저장소입니다. 로컬 스토리지는 사용자가 웹 페이지를 방문하면 해당 웹 사이트에서 저장한 데이터를 브라우저에 저장할 수 있게 해줍니다.
 
 로컬 스토리지는 세션 스토리지(Session Storage)와 마찬가지로 키-값 쌍으로 데이터를 저장합니다. 하지만 세션 스토리지는 브라우저 세션이 종료되면 데이터가 삭제되지만, 로컬 스토리지는 사용자가 명시적으로 데이터를 삭제하지 않는 한 영구적으로 데이터를 보존합니다.
 
 로컬 스토리지의 내용을 개발자 도구를 이용해 확인하려면 브라우저의 개발자 도구를 열고, Application 탭으로 이동해야 합니다. 그리고 왼쪽 패널에서 Storage 항목을 선택하면 로컬 스토리지의 내용을 확인할 수 있습니다. 각 웹 사이트마다 로컬 스토리지에 저장한 데이터가 분리되어 저장되므로, 왼쪽 패널에서 해당 웹 사이트의 도메인을 선택해야 합니다. 선택한 도메인의 오른쪽 패널에서 로컬 스토리지에 저장된 키-값 쌍의 목록과 값을 확인할 수 있습니다. 또한 개발자 도구 콘솔에서도 로컬 스토리지의 내용을 확인하고 조작할 수 있습니다.
-
+```
 ## Quest
 * 외부 라이브러리나 프레임워크를 사용하지 않고, 자바스크립트를 이용하여 간단한 웹브라우저 기반의 텍스트 에디터를 만들어 보겠습니다.
   * 기본적으로 VSCode와 같이 탭을 이용해 여러 개의 파일을 동시에 편집할 수 있습니다.
diff --git a/Quest06/README.md b/Quest06/README.md
index 9315c8bd4..c0fdfcdfe 100644
--- a/Quest06/README.md
+++ b/Quest06/README.md
@@ -24,7 +24,7 @@
 
 ## Checklist
 * 인터넷은 어떻게 동작하나요? Internet Protocol Suite의 레이어 모델에 입각하여 설명해 보세요.
-
+```
 인터넷은 컴퓨터 네트워크들이 상호 연결되어 정보를 주고 받을 수 있도록 하는 글로벌한 네트워크입니다. 인터넷 프로토콜 스위트(Internet Protocol Suite)은 이러한 인터넷을 운영하기 위한 일련의 프로토콜과 규칙들의 집합입니다. 인터넷 프로토콜 스위트는 OSI 7계층 모델과 유사한 레이어 모델을 사용하며, 이는 데이터 통신을 위한 다양한 프로토콜을 계층별로 분리하여 설명하는 방식입니다.
 
 인터넷 프로토콜 스위트의 레이어 모델은 다음과 같습니다.
@@ -42,9 +42,9 @@
 표현 계층 (Presentation layer) - 애플리케이션 계층에서 사용되는 데이터의 표현 방식을 정의하는 계층입니다. 예를 들어, MIME(Multipurpose Internet Mail Extensions)은 이 계층에서 사용됩니다.
 
 애플리케이션 계층 (Application layer) - 사용자가 사용하는 애플리케이션에서 사용되는 프로토콜을 정의하는 계층입니다. 예를 들어, HTTP(Hypertext Transfer Protocol)는 웹 브라우저와 웹 서버 간의 통신을 위해 이 계층에서 사용됩니다.
-
+```
   * 근거리에서 서로 떨어진 두 전자기기가 유선/무선으로 서로 통신하는 프로토콜은 어떻게 동작할까요?
-
+  ```
   근거리에서 서로 떨어진 두 전자기기가 유선 또는 무선으로 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요합니다.
   유선 통신의 경우, 일반적으로 Ethernet이나 USB 등의 케이블을 사용하여 두 기기를 연결합니다. 연결된 두 기기는 데이터 링크 계층의 프로토콜인 Ethernet 프로토콜 등을 사용하여 데이터를 주고 받습니다.
   무선 통신의 경우, 두 기기가 무선으로 통신하기 위해서는 무선 통신을 지원하는 하드웨어와 무선 프로토콜을 사용합니다. 일반적으로 Wi-Fi, Bluetooth, NFC 등의 무선 통신 프로토콜이 사용됩니다.
@@ -52,9 +52,9 @@
   Bluetooth를 사용하여 무선으로 두 기기가 통신하는 경우, 먼저 두 기기는 페어링을 통해 서로 연결됩니다. 이 때 사용되는 프로토콜은 Bluetooth 프로토콜입니다. Bluetooth를 통해 연결된 두 기기는 일반적으로 SPP(Serial Port Profile) 프로파일이나 A2DP(Advanced Audio Distribution Profile) 프로파일 등을 사용하여 데이터를 주고받습니다.
   NFC를 사용하여 무선으로 두 기기가 통신하는 경우, 두 기기는 근접 상태에서 서로 통신합니다. 이 때 사용되는 프로토콜은 NFC 프로토콜입니다. NFC를 통해 연결된 두 기기는 NDEF(NFC Data Exchange Format) 등의 프로토콜을 사용하여 데이터를 주고받습니다.
   이와 같이 유선 또는 무선으로 두 기기가 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요하며, 각각의 프로토콜마다 다양한 규칙과 규격이 있습니다.
-
+  ```
   * 근거리에 있는 여러 대의 전자기기가 서로 통신하는 프로토콜은 어떻게 동작할까요?
-
+  ```
   근거리에 있는 여러 대의 전자기기가 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요합니다.
   예를 들어, 근거리 무선 통신을 지원하는 기기들이 서로 통신하는 경우, 일반적으로 사용되는 프로토콜은 Wi-Fi, Bluetooth, Zigbee, Z-Wave 등이 있습니다. 각각의 프로토콜은 다양한 기능과 규격을 가지고 있습니다.
   Wi-Fi를 사용하는 경우, 일반적으로 무선 액세스 포인트(또는 라우터)를 중심으로 여러 대의 기기들이 연결됩니다. Wi-Fi 기기들은 무선 액세스 포인트와 연결하여 IP 주소를 할당받고, TCP 또는 UDP 프로토콜 등을 사용하여 서로 통신합니다.
@@ -62,36 +62,36 @@
   Zigbee를 사용하는 경우, 여러 대의 기기들이 망 형태로 연결되어 서로 통신합니다. Zigbee 기기들은 IEEE 802.15.4 무선 프로토콜을 기반으로 하며, 주로 스마트 홈 등의 IoT 분야에서 사용됩니다.
   Z-Wave를 사용하는 경우, 여러 대의 기기들이 망 형태로 연결되어 서로 통신합니다. Z-Wave 기기들은 Z-Wave 프로토콜을 사용하여 데이터를 주고받으며, 주로 스마트 홈 등의 IoT 분야에서 사용됩니다.
   이와 같이 근거리에 있는 여러 대의 전자기기가 서로 통신하기 위해서는 해당 프로토콜에 맞는 하드웨어와 소프트웨어가 필요하며, 각각의 프로토콜마다 다양한 규칙과 규격이 있습니다.
-
+  ```
   * 아주 멀리 떨어져 있는 두 전자기기가 유선/무선으로 서로 통신하는 프로토콜은 어떻게 동작할까요?
-
+  ```
   아주 멀리 떨어져 있는 두 전자기기가 유선/무선으로 서로 통신하기 위해서는 인터넷이나 전화망 등의 네트워크를 이용해야 합니다.
   유선 통신의 경우, 두 전자기기 사이에 광케이블, 동축케이블, 전선 등의 물리적인 케이블이 연결되어 있어야 하며, 해당 케이블에 따라 데이터를 전송합니다. 이 때, 데이터 전송에는 TCP/IP 프로토콜을 사용합니다. TCP/IP는 인터넷을 비롯한 대부분의 네트워크에서 사용되는 프로토콜로, 데이터를 패킷으로 분할하여 전송하고, 패킷의 손실이나 손상을 검출하고 복구합니다.
   무선 통신의 경우, 두 전자기기 사이에는 인터넷 기반의 네트워크가 필요합니다. 먼저, 무선 액세스 포인트(또는 라우터)를 통해 인터넷에 연결된 후, 해당 인터넷을 통해 다른 전자기기와 통신합니다. 무선 통신에서는 일반적으로 Wi-Fi, LTE, 5G 등의 프로토콜이 사용됩니다. 이 때, 데이터 전송에는 TCP/IP 프로토콜을 사용합니다.
   따라서, 아주 멀리 떨어져 있는 두 전자기기가 유선/무선으로 서로 통신하기 위해서는 인터넷이나 전화망 등의 중계망을 통해 데이터를 전송하며, 해당 네트워크에서는 TCP/IP 프로토콜을 사용하여 데이터를 전송합니다.
-
+  ```
   * 두 전자기기가 신뢰성을 가지고 통신할 수 있도록 하기 위한 프로토콜은 어떻게 동작할까요?
-
+  ```
   두 전자기기가 신뢰성을 가지고 통신하기 위해서는 데이터 전송 중에 발생할 수 있는 다양한 문제들에 대해 대처해야 합니다. 이를 위해 대표적인 신뢰성 프로토콜인 TCP(Transmission Control Protocol)가 사용됩니다.
   TCP는 데이터를 안정적으로 전송하기 위해 여러 가지 기능을 제공합니다. 우선, TCP는 데이터 전송 중에 데이터를 손실하거나 손상된 데이터를 감지하고, 이를 복구하기 위해 다시 전송합니다. 또한, 데이터 전송 중에 데이터가 순서대로 도착하지 않는 문제를 해결하기 위해 순서를 지정하여 전송합니다. 또한, TCP는 데이터 전송 속도를 제어하기 위해 흐름 제어 기능을 제공합니다. 이를 통해 데이터 전송 속도가 느리거나 빠를 때 발생할 수 있는 문제들을 방지할 수 있습니다.
   데이터를 안정적으로 전송하기 위해 TCP는 3-way handshake라고 불리는 과정을 거칩니다. 이 과정에서 클라이언트와 서버가 상호간에 정보를 교환하여 신뢰적인 연결을 설정합니다. 이후 데이터 전송 과정에서도 클라이언트와 서버는 계속해서 정보를 주고받으면서 신뢰적인 통신을 유지합니다.
   따라서, 두 전자기기가 신뢰성을 가지고 통신하기 위해서는 TCP 프로토콜과 같은 신뢰성 프로토콜을 사용하여 안정적인 데이터 전송을 보장해야 합니다.
-
+  ```
   * HTTP는 어떻게 동작할까요?
-
+  ```
   HTTP(HyperText Transfer Protocol)는 월드 와이드 웹(World Wide Web)에서 데이터를 주고받기 위한 통신 규약 중 하나입니다. HTTP는 클라이언트(Client)와 서버(Server) 간의 상호작용을 통해 데이터를 주고받습니다.
   HTTP는 기본적으로 요청(Request)과 응답(Response)으로 구성됩니다. 클라이언트가 서버에 데이터를 요청하면, 서버는 요청을 받아 해당 데이터를 찾아서 클라이언트에게 응답합니다. 이 과정에서 HTTP 프로토콜은 요청과 응답에 대한 여러 가지 규칙과 방법을 정의합니다.
   HTTP 요청은 메서드(Method), URL, 버전(Version), 헤더(Header), 본문(Body) 등으로 구성됩니다. 메서드는 요청의 종류를 나타내는데, 가장 많이 사용되는 메서드는 GET과 POST입니다. GET은 데이터를 가져오는 요청에, POST는 데이터를 서버에 보내는 요청에 사용됩니다. URL은 요청할 데이터의 주소를 나타내며, 버전은 HTTP의 버전을 나타냅니다. 헤더는 요청에 대한 부가적인 정보를 포함하며, 본문은 POST 요청과 같이 데이터를 서버에 전송해야 할 때 사용됩니다.
   HTTP 응답은 상태코드(Status Code), 헤더, 본문으로 구성됩니다. 상태코드는 요청이 성공적으로 처리되었는지, 오류가 발생했는지 등을 나타내며, 헤더는 응답에 대한 부가적인 정보를 포함합니다. 본문은 요청 결과로 받은 데이터를 포함합니다.
   HTTP는 기본적으로 TCP/IP 프로토콜 위에서 동작하며, 보안을 위해 HTTPS(HTTP Secure)를 사용할 수 있습니다. HTTPS는 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 데이터를 암호화하여 보안성을 높입니다.
   따라서, HTTP는 웹에서 데이터를 주고받기 위한 기본적인 통신 규약이며, 요청과 응답에 대한 규칙과 방법을 정의하여 클라이언트와 서버 간의 효율적인 상호작용을 가능하게 합니다.
-
+  ```
 * 우리가 브라우저의 주소 창에 www.knowre.com 을 쳤을 때, 어떤 과정을 통해 서버의 IP 주소를 알게 될까요?
-
+```
 브라우저의 주소 창에 www.knowre.com을 입력하면, 브라우저는 먼저 입력한 주소가 유효한 도메인 이름인지 확인합니다. 이 과정에서 브라우저는 DNS(Domain Name System) 서버에 쿼리를 보내서 도메인 이름에 대응되는 IP 주소를 얻습니다.
 DNS 서버는 인터넷 상에서 도메인 이름과 IP 주소를 대응시키는 중요한 역할을 합니다. DNS 서버는 분산된 형태로 운영되며, 전 세계적으로 수많은 DNS 서버들이 서로 연결돼 있습니다. 브라우저는 이 중에서 자신과 가장 가까운 DNS 서버를 선택하여 쿼리를 보내고, 해당 DNS 서버는 쿼리에 대해 자신의 캐시(cache)에서 도메인 이름에 대응되는 IP 주소를 찾습니다. 만약 캐시에 정보가 없다면, DNS 서버는 계층 구조로 구성된 다른 DNS 서버들에게 쿼리를 전달하여 IP 주소를 찾으려고 시도합니다.
 결국, DNS 서버는 www.knowre.com에 대응되는 IP 주소를 찾아 브라우저에게 응답해줍니다. 브라우저는 이제 IP 주소를 통해 해당 서버에 접속하고, HTTP 요청을 보내서 해당 서버로부터 웹 페이지를 받아옵니다.
-
+```
 
 ## Quest
 * tracert(Windows가 아닌 경우 traceroute) 명령을 통해 www.google.com 까지 가는 경로를 찾아 보세요.
diff --git a/Quest07/README.md b/Quest07/README.md
index 54a2140be..0bd31090e 100644
--- a/Quest07/README.md
+++ b/Quest07/README.md
@@ -21,13 +21,15 @@
 
 ## Checklist
 * node.js는 무엇인가요? node.js의 내부는 어떻게 구성되어 있을까요?
+```
 Node.js는 개발자가 서버 측을 위한 확장 가능한 고성능 애플리케이션을 구축할 수 있는 오픈 소스 크로스 플랫폼 JavaScript 런타임 환경입니다. Node.js는 데이터 집약적인 실시간 애플리케이션을 구축하는 데 적합한 이벤트 중심의 비차단 I/O 모델을 사용합니다.
 핵심적으로 Node.js는 더 빠른 실행을 위해 JavaScript 코드를 머신 코드로 컴파일하는 Google의 V8 JavaScript 엔진 위에 구축됩니다. Node.js는 개발자가 파일 I/O, 네트워크 I/O 및 HTTP 처리와 같은 다양한 작업을 수행하는 데 사용할 수 있는 일련의 내장 모듈을 제공합니다. Node.js는 npm(노드 패키지 관리자)을 사용하여 설치할 수 있는 타사 모듈의 사용도 지원합니다.
 Node.js의 내부 구조는 모든 I/O 작업을 비동기적으로 처리하는 단일 스레드 이벤트 루프를 기반으로 합니다. I/O 작업이 시작되면 Node.js는 작업 완료 시 실행할 콜백 함수를 등록합니다. 작업이 완료되기를 기다리는 동안 Node.js는 다른 코드를 계속 실행할 수 있습니다. 작업이 완료되면 콜백 함수가 이벤트 큐에 추가되고 이벤트 루프에서 FIFO(선입선출) 순서로 처리됩니다.
 Node.js의 이벤트 루프는 타이머 단계, I/O 콜백 단계, 유휴, 준비, 폴링, 확인 및 콜백 닫기 단계를 포함한 여러 단계로 구성됩니다. 타이머 단계에서 Node.js는 만료된 타이머 콜백을 확인하고 이벤트 큐에 추가합니다. I/O 콜백 단계에서 Node.js는 완료된 모든 I/O 관련 콜백을 처리합니다. poll 단계는 I/O 이벤트가 발생하기를 기다리는 반면 check 단계는 setImmediate() 콜백을 처리합니다. 마지막으로 닫기 콜백 단계에서는 닫힌 연결 또는 리소스와 관련된 모든 콜백을 처리합니다.
 전반적으로 Node.js의 내부 구조는 가볍고 효율적으로 설계되어 고성능을 유지하면서 대량의 I/O 작업을 처리할 수 있습니다.
-
+```
 * npm이 무엇인가요? `package.json` 파일은 어떤 필드들로 구성되어 있나요?
+```
 npm은 노드 패키지 관리자를 나타냅니다. Node.js와 함께 제공되는 명령줄 유틸리티이며 개발자가 Node.js 애플리케이션용 패키지(즉, 재사용 가능한 코드 모듈)를 설치하고 관리할 수 있는 방법을 제공합니다.
 npm은 개발자가 애플리케이션에서 검색, 다운로드 및 사용할 수 있는 패키지 레지스트리를 유지 관리하여 작동합니다. 개발자가 npm을 사용하여 패키지를 설치하면 패키지와 해당 종속성(즉, 패키지가 의존하는 다른 패키지)을 다운로드하고 프로젝트의 "node_modules" 디렉토리에 설치합니다.
 package.json 파일은 npm이 Node.js 애플리케이션의 종속성 및 구성을 관리하는 데 사용하는 메타데이터 파일입니다. 이 파일은 응용 프로그램의 루트 디렉터리에 있으며 응용 프로그램의 이름과 버전, 응용 프로그램에 대한 설명, 해당 종속성, 실행할 스크립트 및 기타 메타데이터와 같은 정보를 포함합니다.
@@ -45,38 +47,38 @@ author: 애플리케이션의 저자.
 라이센스: 애플리케이션이 배포되는 라이센스입니다.
 
 Node.js 애플리케이션에서 package.json 파일을 유지함으로써 개발자는 종속성을 쉽게 관리하고 다른 사람과 애플리케이션을 공유하며 애플리케이션을 다른 환경에서 쉽게 배포하고 실행할 수 있습니다.
-
+```
 * npx는 어떤 명령인가요? npm 패키지를 `-g` 옵션을 통해 글로벌로 저장하는 것과 그렇지 않은 것은 어떻게 다른가요?
-
+```
 npx는 버전 5.2.0부터 npm(Node Package Manager)과 함께 제공되는 명령줄 유틸리티입니다. 먼저 설치할 필요 없이 시스템에 전체적으로 설치되지 않은 Node.js 패키지를 실행하는 데 사용됩니다. npx로 패키지를 실행하면 패키지가 프로젝트의 node_modules 디렉토리에 로컬로 설치되어 있는지 확인합니다. 패키지를 찾을 수 없는 경우 npx는 패키지를 실행하기 전에 최신 버전의 패키지를 다운로드하여 설치합니다.
 -g 옵션을 통해 npm 패키지를 전역으로 저장하는 것과 그렇지 않은 것의 차이점은 전역으로 설치된 패키지는 시스템의 모든 프로젝트에서 사용할 수 있는 반면 로컬로 설치된 패키지는 프로젝트 디렉토리 내에서만 사용할 수 있다는 것입니다. 전역적으로 패키지를 설치하면 여러 프로젝트에 동일한 패키지를 설치할 필요가 없으므로 디스크 공간을 절약할 수 있습니다. 그러나 여러 프로젝트에 동일한 패키지의 다른 버전이 필요할 수 있으므로 다른 프로젝트 간에 버전 충돌이 발생할 수도 있습니다.
 반면에 패키지를 로컬로 설치하면 각 프로젝트가 필요한 패키지의 특정 버전에 액세스할 수 있습니다. 이를 통해 버전 충돌을 방지하고 프로젝트를 보다 안정적이고 예측 가능하게 만들 수 있습니다. 패키지를 로컬로 설치하면 해당 프로젝트에 특정한 프로젝트의 node_modules 디렉토리에 추가됩니다. 즉, 해당 프로젝트에 패키지를 다시 설치하지 않는 한 다른 프로젝트에서 패키지를 사용할 수 없습니다.
 요약하면 -g 옵션을 통해 npm 패키지를 전역적으로 저장하는 것과 그렇지 않은 것의 주요 차이점은 패키지의 가용성 범위입니다. 전역 패키지는 시스템 전체에서 사용할 수 있는 반면 로컬 패키지는 프로젝트 디렉터리 내에서만 사용할 수 있습니다. 패키지를 글로벌로 설치할지 로컬로 설치할지 선택하는 것은 특정 요구 사항과 프로젝트의 요구 사항에 따라 다릅니다.
-
+```
 * 자바스크립트 코드에서 다른 파일의 코드를 부르는 시도들은 지금까지 어떤 것이 있었을까요? CommonJS 대신 ES Modules가 등장한 이유는 무엇일까요?
-
+```
 스크립트 태그: 웹 초기에 개발자는 <script> 태그를 사용하여 JavaScript 파일을 로드했습니다. 그러나 이 접근 방식은 코드를 별도의 파일로 구성하거나 동적으로 코드를 로드하는 방법을 제공하지 않았습니다.
 CommonJS: CommonJS는 JavaScript 코드를 모듈화하는 표준 방식을 정의하려는 시도였습니다. 모듈을 로드하는 require() 함수와 내보내기를 정의하는 module.exports 객체를 도입했습니다. 그러나 CommonJS에는 모듈의 동기식 로드와 같은 몇 가지 제한 사항이 있어 더 큰 애플리케이션에서 성능 문제가 발생할 수 있습니다.
 AMD(비동기 모듈 정의): AMD는 모듈식 JavaScript 코드의 표준을 정의하려는 또 다른 시도였습니다. 모듈을 정의하는 define() 함수와 모듈을 비동기적으로 로드하는 require() 함수를 도입했습니다. 그러나 AMD는 개발자가 특정 구문을 사용하도록 요구했기 때문에 다른 솔루션보다 유연성이 떨어졌습니다.
 ES6 모듈: ECMAScript 모듈이라고도 하는 ES6 모듈은 ECMAScript 2015에서 JavaScript 코드를 모듈화하는 표준 방법으로 도입되었습니다. 그들은 export 키워드를 사용하여 내보내기를 정의하고 import 키워드를 사용하여 모듈을 로드하는 방법을 제공합니다. ES6 모듈은 별도의 라이브러리가 아닌 언어 자체의 일부이므로 이전 솔루션보다 더 유연하고 강력합니다.SSS
 ES 모듈은 CommonJS에 비해 몇 가지 장점을 제공하기 때문에 CommonJS 대신 등장했습니다. ES 모듈은 최신 브라우저와 Node.js에서 기본적으로 지원되므로 추가 라이브러리나 도구를 사용할 필요가 없습니다. 또한 모듈의 비동기 로드를 지원하여 더 큰 애플리케이션의 성능을 향상시킬 수 있습니다. ES 모듈은 명명된 내보내기와 기본 내보내기를 모두 허용하고 런타임 값에 따라 조건부로 로드될 수 있으므로 CommonJS보다 더 유연합니다. 마지막으로 ES 모듈은 CommonJS보다 간단하고 직관적인 구문을 가지고 있어 개발자가 사용하고 이해하기 쉽습니다.
-
+```
 * ES Modules는 기존의 `require()`와 동작상에 어떤 차이가 있을까요? CommonJS는 할 수 있으나 ES Modules가 할 수 없는 일에는 어떤 것이 있을까요?
-
+```
 ES 모듈과 require()의 주요 차이점은 종속성과 모듈 로드를 처리하는 방식입니다. 'require()'는 모듈을 로드하는 동기 방식으로, 모듈이 차단 방식으로 로드되고 실행된다는 것을 의미합니다. 대조적으로 ES Modules는 모듈 로딩 및 종속성에 대한 동적 및 비동기식 접근 방식을 사용하여 비동기식으로 로드되고 실행될 수 있습니다.
 또 다른 중요한 차이점은 내보내기가 정의되는 방식입니다. CommonJS에서 내보내기는 module.exports 객체를 사용하여 정의되는 반면 ES Modules에서는 export 키워드를 사용하여 정의됩니다. 구문의 이러한 차이로 인해 개발자는 특히 명명된 내보내기를 처리할 때 코드를 더 쉽게 작성하고 이해할 수 있습니다.
 CommonJS에 비해 ES Modules의 주요 이점 중 하나는 JavaScript 모듈 작업에 대해 보다 표준화되고 미래에 대비한 방식을 제공한다는 것입니다. ES 모듈은 ECMAScript 표준의 일부이며, 이는 최신 브라우저와 Node.js에서 기본적으로 지원됨을 의미합니다. 이를 통해 타사 라이브러리나 도구에 의존할 필요 없이 다양한 플랫폼과 환경에서 모듈로 작업하기가 더 쉬워집니다.
 그러나 CommonJS에 비해 ES 모듈에는 몇 가지 제한 사항이 있습니다. 예를 들어, ES 모듈은 대규모 애플리케이션에서 일반적인 기능일 수 있는 순환 종속성을 지원하지 않습니다. 또한 런타임에 조건부로 로드할 수 없지만 require() 함수를 사용하는 CommonJS에서는 가능합니다.
 전반적으로 ES Modules는 JavaScript 모듈을 사용하여 보다 현대적이고 유연한 작업 방식을 제공하는 반면 CommonJS는 보다 전통적이고 검증된 접근 방식을 제공합니다. 어느 것을 사용할지는 프로젝트의 특정 요구 사항과 사용 중인 도구 및 라이브러리에 따라 다릅니다.
-
+```
 * node.js에서 ES Modules를 사용하려면 어떻게 해야 할까요? ES Modules 기반의 코드에서 CommonJS 기반의 패키지를 불러오려면 어떻게 해야 할까요? 그 반대는 어떻게 될까요?
-
+```
 Node.js에서 ES 모듈을 사용하려면 모듈 파일에 .mjs 파일 확장자를 사용하거나 package.json 파일에서 "type": "module" 필드를 설정해야 합니다. 이 작업을 완료하면 import 문을 사용하여 다음과 같이 모듈을 로드하고 사용할 수 있습니다.
 ES 모듈 기반 코드에서 CommonJS 기반 패키지를 가져오려면 CommonJS 모듈 내보내기로 확인되는 Promise를 반환하는 import() 함수를 사용할 수 있습니다.
 esm과 같은 패키지를 사용하여 CommonJS 패키지에 대한 ES 모듈 지원을 활성화할 수도 있습니다. esm은 CommonJS 파일에서 ES 모듈 구문을 사용할 수 있게 해주는 패키지로, ES 모듈 기반 프로젝트에서 CommonJS 패키지를 사용하려는 경우 유용할 수 있습니다. esm을 사용하려면 npm으로 설치한 다음 -r esm 플래그로 스크립트를 실행해야 합니다.
 CommonJS 기반 코드에서 ES 모듈 기반 패키지를 가져오려면 require() 함수를 사용할 수 있습니다.
 그러나 require()는 개별적으로 명명된 내보내기가 아니라 전체 ES 모듈을 나타내는 객체를 반환한다는 점에 유의하십시오. 명명된 내보내기에 액세스하려면 ES Module 개체의 default 속성을 사용할 수 있습니다. 또는 cjs-es와 같은 패키지를 사용하여 ES 모듈에 대한 CommonJS 지원을 활성화할 수 있습니다. cjs-es는 ES 모듈 파일에서 CommonJS 구문을 사용할 수 있게 해주는 패키지로, ES 모듈 기반 프로젝트에서 CommonJS 패키지를 사용하려는 경우 유용할 수 있습니다. cjs-es를 사용하려면 npm으로 설치한 다음 --experimental-specifier-resolution=node 플래그로 스크립트를 실행해야 합니다.
-
+```
 ## QuestS
 * 스켈레톤 코드에는 다음과 같은 네 개의 패키지가 있으며, 용도는 다음과 같습니다:
   * `cjs-package`: CommonJS 기반의 패키지입니다. 다른 코드가 이 패키지의 함수와 내용을 참조하게 됩니다.

From 191a85f7d9486c030eccc9d205e84957c41c7b3d Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Fri, 7 Apr 2023 23:29:14 +0900
Subject: [PATCH 18/29] CheckList Clear

---
 Quest09/README.md | 155 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 155 insertions(+)

diff --git a/Quest09/README.md b/Quest09/README.md
index 7e2950c0c..4ba07b37b 100644
--- a/Quest09/README.md
+++ b/Quest09/README.md
@@ -20,16 +20,171 @@
 
 ## Checklist
 * 비동기 프로그래밍이란 무엇인가요?
+```
+비동기 프로그래밍은 기본 실행 스레드를 차단하지 않고 작업 또는 작업을 동시에 실행할 수 있는 프로그래밍 접근 방식입니다. 전통적인 동기식 프로그래밍에서는 작업이 차례대로 순차적으로 실행되며 프로그램은 다음 작업으로 이동하기 전에 각 작업이 완료될 때까지 기다립니다. 그러나 비동기식 프로그래밍에서는 작업을 독립적으로 시작하고 실행할 수 있으므로 프로그램이 이전 작업이 완료될 때까지 기다리지 않고 다른 작업을 계속 실행할 수 있습니다.
+
+비동기 프로그래밍은 API와 같은 외부 소스에서 데이터 가져오기, 데이터베이스 읽기 또는 쓰기, 시간 소모적인 계산 수행과 같이 작업을 완료하는 데 오랜 시간이 걸릴 수 있는 시나리오에서 특히 유용합니다. 비동기 프로그래밍을 사용하면 프로그램이 비동기 작업의 완료를 기다리는 동안 다른 작업을 계속 수행하거나 사용자 입력에 응답할 수 있으므로 개발자는 보다 효율적이고 반응이 빠른 코드를 작성할 수 있습니다.
+
+비동기 프로그래밍에서 작업은 일반적으로 즉시 반환되는 비동기 작업으로 시작되어 주 실행 스레드가 차단되지 않고 계속될 수 있습니다. 콜백, 약속 및 async/await는 비동기 작업의 결과 또는 오류를 처리하기 위해 비동기 프로그래밍에서 사용되는 일반적인 기술입니다. 비동기 프로그래밍은 최신 웹 개발, 서버 측 프로그래밍 및 동시 작업을 효율적으로 처리해야 하는 기타 응용 프로그램에서 널리 사용됩니다.
+```
+
   * 콜백을 통해 비동기적 작업을 할 때의 불편한 점은 무엇인가요? 콜백지옥이란 무엇인가요?
+  ```
+  1. 콜백 지옥: 비동기 작업에 콜백을 사용할 때의 주요 문제 중 하나는 "콜백 지옥"의 가능성입니다. 콜백 지옥은 여러 비동기 작업을 순서대로 실행하거나 서로의 결과에 의존해야 할 때 발생할 수 있는 콜백의 중첩 구조를 말합니다. 이로 인해 깊게 중첩되고 읽기 어려운 코드가 생성되어 관리 및 디버깅이 어려워질 수 있습니다.
+  2. 콜백 지옥의 예:
+  
+  javascript
+
+  asyncFunction1(function(result1) {
+    asyncFunction2(result1, function(result2) {
+      asyncFunction3(result2, function(result3) {
+        // ... and so on
+        });
+        });
+        });
+        
+  3. 가독성 부족: 콜백 기반 코드는 특히 복잡한 논리 또는 오류 처리를 처리할 때 중첩된 콜백의 여러 수준에서 실행 흐름을 정신적으로 추적해야 하기 때문에 읽고 이해하기 어려울 수 있습니다.
+  4. 오류 처리: 중첩된 콜백 내에서 발생하는 오류가 제대로 전파되지 않거나 일관되게 처리되지 않을 수 있으므로 오류 처리는 콜백에서 더 어려울 수 있습니다. 이로 인해 버그가 발생하고 디버깅이 더 어려워질 수 있습니다.
+  5. 코드 복제: 경우에 따라 콜백 기반 코드는 오류 처리 또는 공통 로직을 여러 콜백에서 반복해야 하므로 유지 관리 오버헤드가 증가하므로 코드 복제로 이어질 수 있습니다.
+  6. 확장성: 애플리케이션의 복잡성이 증가하고 비동기 작업의 수가 증가함에 따라 콜백 관리 및 조정이 어려워져 잠재적인 성능 및 확장성 문제가 발생할 수 있습니다.
+  
+  이러한 단점에도 불구하고 콜백은 특정 시나리오나 소규모 비동기 작업에 여전히 유용할 수 있습니다. 그러나 최신 프로그래밍 언어 및 프레임워크는 이러한 문제를 완화하고 비동기 작업을 처리하기 위한 보다 깨끗하고 유지 관리하기 쉬운 코드를 제공하는 데 도움이 되는 약속 또는 async/await와 같은 대체 접근 방식을 제공하는 경우가 많습니다.
+  ```
   * 자바스크립트의 Promise는 어떤 객체이고 어떤 일을 하나요?
+  ```
+  JavaScript에서 Promise는 비동기 작업의 최종 완료(또는 실패)를 나타내며 더 읽기 쉽고 관리하기 쉬운 비동기 코드를 허용하는 내장 개체입니다. 아직은 나오지 않았지만 언젠가는 해결될 미래의 가치를 담는 그릇입니다.
+  약속에는 세 가지 상태가 있습니다.
+  1. Pending: Promise가 생성될 때의 초기 상태. 비동기 작업이 아직 진행 중이고 Promise가 결과를 기다리고 있습니다.
+  2. 이행됨: 비동기 작업이 성공적으로 완료되고 Promise에 결과 값이 있는 상태입니다. 이행 상태는 "해결됨" 또는 "성공"이라고도 합니다.
+  3. 거부됨: 비동기 작업이 실패하거나 오류가 발생하고 Promise에 실패 이유가 있는 상태입니다. 거부된 상태는 "실패"라고도 합니다.
+
+  약속에는 두 가지 주요 방법이 있습니다.
+
+  1. then(): 이 메서드는 Promise가 이행될 때 호출될 Promise에 하나 이상의 콜백("핸들러"라고도 함)을 연결하는 데 사용됩니다. 비동기 작업을 연결하고 성공적인 결과를 처리할 수 있습니다.
+  2. catch(): 이 메서드는 Promise가 거부될 때 호출될 Promise에 콜백을 연결하는 데 사용됩니다. 비동기 작업 중에 발생할 수 있는 오류 또는 실패를 처리할 수 있습니다.
+  Promise는 JavaScript에서 비동기 작업을 처리하는 보다 체계적이고 조직적인 방법을 제공하여 콜백 지옥을 피하고 더 읽기 쉽고 유지 관리 가능한 코드를 허용합니다. Promise는 최신 JavaScript 개발에서 널리 사용되며 비동기 작업을 효과적으로 처리하기 위해 async/await와 같은 다른 비동기 프로그래밍 기술과 함께 자주 사용됩니다.
+  ```
   * 자바스크립트의 `async`와 `await` 키워드는 어떤 역할을 하며 그 정체는 무엇일까요?
+  ```
+  JavaScript에서 async 및 await는 비동기 프로그래밍을 용이하게 하고 비동기 코드를 더 쉽게 작성하고 읽고 관리할 수 있도록 함께 사용되는 키워드입니다.
+  
+  async: async 키워드는 함수를 비동기로 선언하는 데 사용됩니다. 비동기 함수는 기본적으로 비동기 작업의 최종 완료(또는 실패)를 나타내는 'Promise'를 반환합니다. 비동기 함수는 주 실행 스레드를 차단하지 않고 실행을 계속하기 전에 일시 중지하고 'Promise'의 해결을 기다릴 수 있는 'await' 표현식을 포함할 수 있습니다.
+  await: await 키워드는 async 함수 내에서 Promise의 해결을 기다리는 데 사용됩니다. 'await'가 'Promise'와 함께 사용되면 Promise가 이행되거나 거부될 때까지 비동기 함수의 실행을 일시 중단합니다. Promise가 이행되면 해결된 값이 반환됩니다. 약속이 거부되면 'try...catch' 블록을 사용하여 잡을 수 있는 오류가 발생합니다.
+  
+  async 및 await를 사용하면 명시적 콜백 또는 then() 메서드 체인이 필요하지 않으므로 비동기 코드를 더 간결하고 읽기 쉽고 구조가 동기 코드와 유사하게 만들 수 있습니다. 이는 콜백 지옥을 피하는 데 도움이 되며 전통적인 try...catch 블록을 사용하여 오류를 잡을 수 있으므로 오류 처리를 더 간단하게 만듭니다.
+  
+  다음은 JavaScript에서 async 및 await를 사용하는 방법의 예입니다.
+  
+  javascript
+  async function fetchData() {
+    try {
+      const response = await fetch('https://api.example.com/data'); // Wait for the fetch Promise to resolve
+      const data = await response.json(); // Wait for the JSON parsing Promise to resolve
+      console.log(data); // Use the resolved data
+      } catch (error) {
+      console.error('Error fetching data:', error); // Handle any errors that may occur
+      }
+    }
+  이 예에서 fetchData() 함수는 async 키워드를 사용하여 비동기 함수로 선언됩니다. 함수 내에서 await는 fetch() 및 response.json() 약속의 해결을 기다리는 데 사용되어 비동기 작업의 순차적이고 더 읽기 쉬운 실행을 허용합니다. 비동기 작업 중에 발생할 수 있는 모든 오류는 적절한 오류 처리를 위해 try...catch 블록을 사용하여 포착됩니다.
+  ```
 * 브라우저 내 스크립트에서 외부 리소스를 가져오려면 어떻게 해야 할까요?
+```
+JavaScript에서는 최신 웹 브라우저에 내장된 fetch() 함수를 사용하여 브라우저 내 스크립트에서 외부 리소스를 가져올 수 있습니다. fetch() 함수는 HTTP 요청을 만드는 데 사용되며 요청에 대한 응답으로 확인되는 Promise를 반환합니다.
+
+다음은 fetch() 함수를 사용하여 브라우저 내 스크립트에서 API의 데이터와 같은 외부 리소스를 가져오는 방법의 예입니다.
+
+javascript
+
+fetch('https://api.example.com/data') // Make a GET request to the specified URL
+  .then(response => {
+    if (!response.ok) {
+      throw new Error('Network response was not OK'); // Handle non-OK responses
+    }
+    return response.json(); // Parse the response as JSON and return the parsed data
+  })
+  .then(data => {
+    console.log(data); // Use the fetched data
+  })
+  .catch(error => {
+    console.error('Error fetching data:', error); // Handle any errors that may occur
+  });
+이 예제에서 fetch() 함수는 외부 리소스의 URL을 인수로 사용하여 호출됩니다. 이 함수는 요청에 대한 응답으로 확인되는 'Promise'를 반환합니다. 그런 다음 비동기 작업의 연결을 허용하는 then() 메서드를 사용하여 응답을 처리할 수 있습니다. 이 경우 먼저 응답 개체의 'ok' 속성을 사용하여 응답의 OK 상태를 확인합니다. 응답이 OK이면 json() 메서드가 호출되어 응답을 JSON으로 구문 분석하고 구문 분석된 데이터를 반환합니다. 마지막으로 가져온 데이터는 콘솔에 기록됩니다. 가져오기 작업 중에 발생할 수 있는 모든 오류는 적절한 오류 처리를 위해 catch() 블록을 사용하여 포착됩니다.
+```
   * 브라우저의 `XMLHttpRequest` 객체는 무엇이고 어떻게 동작하나요?
+  ```
+  XMLHttpRequest 개체는 웹 브라우저 내에서 HTTP 요청을 만들 수 있는 내장 JavaScript 개체입니다. HTTP 또는 HTTPS 프로토콜을 통해 데이터를 송수신하기 위한 인터페이스를 제공하며 일반적으로 서버에서 데이터를 가져오거나 서버에 데이터를 제출하거나 다른 유형의 HTTP 통신을 수행하는 데 사용됩니다.
+  
+  다음은 XMLHttpRequest 개체가 작동하는 방식에 대한 높은 수준의 개요입니다.
+  
+  1. 인스턴스 만들기: const xhr = new XMLHttpRequest();와 같이 생성자를 호출하여 새 XMLHttpRequest 개체를 만들 수 있습니다.
+  2. 요청 구성: XMLHttpRequest의 인스턴스를 생성한 후 개체에 대한 다양한 속성 및 메서드를 설정하여 요청을 구성할 수 있습니다. 예를 들어 HTTP 메서드(GET, POST, PUT, DELETE 등), 상호 작용하려는 리소스의 URL, 요청 헤더 및 요청 매개 변수를 설정할 수 있습니다.
+  3. 요청 보내기: 요청이 구성되면 XMLHttpRequest 개체에서 open() 및 send() 메서드를 호출하여 보낼 수 있습니다. open() 메소드는 HTTP 메소드와 요청 URL을 지정하고 send() 메소드는 요청을 시작하고 필요한 경우 요청 데이터를 보냅니다.
+  4. 응답 수신: 서버가 요청에 응답하면 XMLHttpRequest 개체는 요청 상태에 따라 load, progress, error, abort 등의 다양한 이벤트를 트리거합니다. 이벤트 리스너를 등록하여 이러한 이벤트를 처리하고 일반적으로 XMLHttpRequest 개체의 responseText 또는 responseXML 속성에서 사용할 수 있는 응답 데이터를 처리할 수 있습니다.
+  5. 오류 처리: 서버에서 오류 상태 코드(예: 4xx 또는 5xx)를 반환하거나 요청에 다른 문제가 있는 경우 XMLHttpRequest 개체의 onerror 이벤트가 트리거되고 처리할 수 있습니다. 코드의 오류.
+  6. 정리: 응답을 처리한 후 필요한 경우 XMLHttpRequest 객체를 닫고 사용했을 수 있는 모든 리소스를 해제하여 XMLHttpRequest 객체를 정리해야 합니다.
+  ```
   * `fetch` API는 무엇이고 어떻게 동작하나요?
+  ```
+  'fetch' API는 웹 브라우저 내에서 서버에서 데이터를 가져오는 것과 같은 HTTP 요청을 만드는 쉽고 현대적인 방법을 제공하는 내장 JavaScript API입니다. 이전 XMLHttpRequest 개체에 비해 더 유연하고 강력하게 설계되었으며 요청에 대한 응답으로 해석되는 Promise를 반환하여 비동기 작업을 보다 효율적으로 처리할 수 있습니다.
+  
+  다음은 fetch API 작동 방식에 대한 대략적인 개요입니다.
+  요청하기: 최신 웹 브라우저에서 사용할 수 있는 전역 함수인 fetch() 함수를 사용하여 HTTP 요청을 할 수 있습니다. fetch() 함수는 URL을 인수로 사용하고 URL에 있는 리소스를 가져오는 비동기 작업을 나타내는 Promise를 반환합니다.
+  응답 처리: fetch() 함수는 요청에 대한 응답으로 해석되는 Promise를 반환합니다. 'then()' 메서드를 사용하여 작업을 연결하고 응답을 처리할 수 있습니다. 예를 들어 response.json()을 호출하여 응답 본문을 JSON으로 구문 분석하고 response.text()를 호출하여 응답 본문을 텍스트로 가져오거나 response.blob()을 호출하여 응답 본문을 다음과 같이 가져올 수 있습니다. 바이너리 블롭.
+  오류 확인: fetch() 함수는 OK가 아닌(예: 4xx 또는 5xx) HTTP 상태 코드에 대해 Promise를 자동으로 거부하지 않습니다. 응답 객체의 ok 속성을 명시적으로 확인하거나 response.ok 부울 값을 사용하여 응답의 성공 여부를 결정해야 합니다. 또한 response.status 및 response.statusText 속성을 사용하여 각각 응답의 상태 코드 및 상태 텍스트를 가져올 수 있습니다.
+  오류 처리: 서버가 오류 상태 코드를 반환하거나 요청에 다른 문제가 있는 경우 fetch()에서 반환된 Promise는 여전히 성공적으로 해결되지만 catch() 오류를 처리하기 위한  메서드 또는 catch 블록. 예를 들어 오류를 발생시키거나 오류 메시지를 기록하거나 기타 적절한 오류 처리 작업을 수행할 수 있습니다.
+  정리: 응답을 처리한 후에는 항상 response 개체의 close() 메서드를 호출하여 리소스 누수를 방지하기 위해 네트워크 연결과 같은 응답과 관련된 모든 리소스를 해제해야 합니다.
+  ```
 * REST는 무엇인가요?
+```
+REST는 Representational State Transfer의 약자이며 네트워크 애플리케이션 설계에 사용되는 아키텍처 스타일입니다. REST는 확장 가능하고 효율적인 웹 서비스를 구축하는 데 일반적으로 사용되는 제약 조건 집합을 정의합니다.
+
+웹 서비스 및 API(응용 프로그래밍 인터페이스) 컨텍스트에서 RESTful API는 World Wide Web의 기반인 HTTP 프로토콜과 함께 작동하도록 설계되었습니다. RESTful API는 GET, POST, PUT, PATCH 및 DELETE와 같은 표준 HTTP 메서드를 사용하여 일반적으로 URL(Uniform Resource Locator)로 표시되는 URI(Uniform Resource Identifier)로 식별되는 리소스에 대한 작업을 수행합니다.
+
+RESTful API는 클라이언트(예: 웹 브라우저 또는 모바일 앱)가 서버에서 리소스를 요청하고 서버가 JSON(JavaScript Object Notation) 또는 XML(eXtensible Markup Language)과 같은 형식으로 요청된 데이터로 응답하는 클라이언트-서버 아키텍처를 따릅니다. . RESTful API는 stateless입니다. 즉, 클라이언트에서 서버로의 각 요청에는 요청을 이해하고 처리하는 데 필요한 모든 정보가 포함되어야 합니다. 서버는 요청 간에 클라이언트별 데이터를 저장하지 않으므로 RESTful API를 확장 가능하고 유지 관리하기 쉽습니다.
+
+RESTful API는 단순하고 확장 가능하며 이해하기 쉽도록 설계되었습니다. 표준 HTTP 메서드와 상태 코드를 사용하여 원하는 작업과 요청 결과를 나타냅니다. 시스템의 엔터티를 나타내는 리소스는 URI로 식별되며 리소스에 대한 작업은 적절한 HTTP 메서드를 사용하여 수행됩니다. RESTful API는 웹을 통해 리소스에 액세스하고 조작하는 일관되고 일관된 방법을 제공하므로 다양한 애플리케이션 및 시스템용 웹 서비스 및 API를 구축하는 데 널리 사용됩니다.
+```
   * REST API는 어떤 목적을 달성하기 위해 나왔고 어떤 장점을 가지고 있나요?
+  ```
+  RESTful API라고도 하는 REST(Representational State Transfer) API는 인터넷을 통해 서로 다른 소프트웨어 시스템 간의 통신 및 데이터 교환을 용이하게 하도록 설계된 API(응용 프로그래밍 인터페이스) 유형입니다. REST API의 주요 목적은 서버가 요청 간에 클라이언트 상태에 대한 정보를 저장하지 않는 상태 비저장 방식으로 클라이언트-서버 통신을 활성화하는 것입니다.
+  REST API 사용의 이점은 다음과 같습니다.
+  1. 확장성: REST API는 상태 비저장 클라이언트-서버 아키텍처를 기반으로 하므로 확장성이 뛰어나므로 필요에 따라 더 많은 서버를 추가하여 쉽게 수평적 확장이  가능합니다.
+  2. 단순성: REST API는 경량 설계와 데이터 작업을 위한 GET, POST, PUT 및 DELETE와 같은 표준 HTTP 메서드 사용으로 인해 이해하고 구현하기 쉽습니다.
+  3. 유연성: REST API는 XML, JSON 등과 같은 여러 데이터 형식을 지원하므로 다양한 클라이언트 및 플랫폼에 적응할 수 있습니다.
+  4. 상호 운용성: REST API는 플랫폼 및 언어에 구애받지 않으므로 기본 기술 스택에 관계없이 서로 다른 소프트웨어 시스템이 서로 통신할 수 있습니다.
+  5. 캐싱: REST API는 응답 캐싱을 지원하여 성능을 개선하고 서버의 부하를 줄일 수 있습니다.
+  6. 보안: REST API는 OAuth, SSL/TLS 등과 같은 다양한 인증 및 권한 부여 메커니즘을 사용하여 보안을 유지하여 클라이언트와 서버 간의 안전한 통신을 보장할 수 있습니다.
+  7. 테스트 가능성: REST API는 Postman과 같은 도구를 사용하여 쉽게 테스트할 수 있으므로 개발 중에 기능을 편리하게 확인하고 검증할 수 있습니다.
+  전반적으로 REST API는 인터넷을 통해 서로 다른 소프트웨어 시스템 간의 통신 및 데이터 교환을 가능하게 하는 강력하고 확장 가능하며 유연한 방법을 제공하므로 최신 웹 및 모바일 애플리케이션에서 널리 사용됩니다.
+  ```
   * RESTful한 API 설계의 단점은 무엇인가요?
+  ```
+  RESTful API에는 많은 장점이 있지만 잠재적인 단점도 있습니다.
+  1. 유연성 부족: RESTful API는 특정 사용 사례에서 유연성을 제한할 수 있는 REST 원칙의 제약을 받습니다. 예를 들어 RESTful API는 실시간 애플리케이션이나 높은 수준의 사용자 지정 또는 복잡한 상호 작용이 필요한 상황에는 적합하지 않을 수 있습니다.
+  2. 데이터의 과다 가져오기 또는 부족 가져오기: RESTful API는 때때로 필요한 것보다 더 많은 데이터를 반환하거나(과도하게 가져오기) 데이터가 충분하지 않아(과소 가져오기) 비효율적인 데이터 검색 또는 누락된 데이터를 가져오기 위한 추가 요청으로 이어질 수 있습니다. 성능에 영향을 미치고 네트워크 오버헤드를 증가시킬 수 있습니다.
+  3. 버전 관리 문제: RESTful API가 발전함에 따라 API 엔드포인트 또는 데이터 모델에 대한 변경 사항에는 버전 관리가 필요할 수 있으며 이로 인해 이전 버전과의 호환성을 유지하고 다양한 버전의 API를 관리하는 데 문제가 발생할 수 있습니다.
+  4. 표준화 부족: REST는 몇 가지 표준화된 원칙을 따르지만 RESTful API에 대한 엄격한 표준화가 없기 때문에 API 디자인, 문서 및 동작이 달라질 수 있으므로 개발자가 다른 API를 배우고 작업하는 것이 어려울 수 있습니다.
+  5. 실시간 통신에 대한 제한된 지원: RESTful API는 주로 요청-응답 스타일의 상호 작용을 위해 설계되었으며 채팅과 같이 짧은 대기 시간, 양방향 통신이 필요한 실시간 통신 시나리오에는 적합하지 않을 수 있습니다. 응용 프로그램 또는 실시간 게임.
+  6. 보안 문제: RESTful API는 인증 및 암호화와 같은 다양한 보안 메커니즘을 지원하지만 이러한 보안 조치를 구현하는 책임은 API 개발자에게 있습니다. 제대로 구현되지 않은 경우 RESTful API는 XSS(교차 사이트 스크립팅), CSRF(교차 사이트 요청 위조) 등과 같은 보안 위협에 취약할 수 있습니다.
+  7. 검색 가능성 부족: RESTful API는 사용 가능한 리소스 및 작업을 검색하기 위한 기본 제공 메커니즘을 제공하지 않을 수 있습니다. 사용 가능한 엔드포인트 및 해당 기능을 이해하려면 추가 문서 또는 API 공급자와의 통신이 필요할 수 있습니다.
+  이러한 단점에도 불구하고 RESTful API는 단순성, 확장성 및 상호 운용성으로 인해 계속 널리 사용됩니다. 그러나 RESTful API를 설계할 때 프로젝트의 특정 요구 사항을 신중하게 고려하고 개발 중인 애플리케이션의 요구 사항 및 제약 조건과 일치하는지 평가하는 것이 중요합니다.
+  ```
 * CORS란 무엇인가요? 이러한 기능이 왜 필요할까요? CORS는 어떻게 구현될까요?
+```
+CORS는 Cross-Origin Resource Sharing의 약자입니다. 원래 웹 페이지를 제공한 도메인이 아닌 다른 도메인에 대한 요청을 웹 페이지에서 제한하는 웹 브라우저에 구현된 보안 기능입니다. CORS는 웹 리소스에 대한 무단 액세스를 방지하고 XSS(교차 사이트 스크립팅) 및 CSRF(교차 사이트 요청 위조) 공격을 완화하는 보안 메커니즘입니다.
+
+한 도메인(원본)에서 제공되는 웹 페이지는 일반적으로 요청된 리소스를 호스팅하는 서버가 응답의 CORS 헤더를 통해 이를 명시적으로 허용하지 않는 한 다른 도메인에 대한 XMLHttpRequest 또는 Fetch 요청을 할 수 없습니다. 이는 사용자 데이터를 보호하고 악의적인 웹 사이트가 사용자를 대신하여 다른 도메인에 무단 요청을 하는 것을 방지하기 위해 수행됩니다.
+
+CORS 헤더는 서버 측에서 구현되며 웹 리소스를 호스팅하는 서버의 HTTP 응답에 포함됩니다. 이러한 헤더에는 리소스에 액세스할 수 있는 허용된 출처, HTTP 메서드, 헤더 및 자격 증명과 같은 정보가 포함됩니다. 가장 일반적으로 사용되는 CORS 헤더는 다음과 같습니다.
+
+Access-Control-Allow-Origin: 리소스에 액세스할 수 있는 원본 또는 원본을 지정합니다. 이는 특정 출처, "*"로 설정하여 모든 출처 또는 허용된 출처 목록을 허용할 수 있습니다.
+Access-Control-Allow-Methods: 리소스에 요청할 때 사용할 수 있는 HTTP 메서드를 지정합니다.
+Access-Control-Allow-Headers: 요청에 포함될 수 있는 헤더를 지정합니다.
+'Access-Control-Allow-Credentials': 쿠키 또는 HTTP 인증과 같은 자격 증명이 요청에 포함될 수 있는지 여부를 나타냅니다.
+Access-Control-Max-Age: 실행 전 요청(OPTIONS)이 브라우저에 의해 캐시되어야 하는 최대 시간(초)을 지정합니다.
+
+CORS는 웹 페이지와 서버 간의 보안 교차 출처 통신을 가능하게 하여 웹 사이트가 사용자 데이터를 보호하고 무단 액세스를 방지하면서 다른 도메인에서 리소스를 가져올 수 있도록 하기 때문에 중요합니다. 이는 웹 브라우저에서 동일 출처 정책을 시행하는 데 도움이 되며 서버가 필요할 때 교차 출처 요청을 명시적으로 허용하는 메커니즘을 제공합니다. CORS를 구현하려면 웹 리소스를 호스팅하는 서버의 HTTP 응답에 적절한 CORS 헤더를 설정하고 클라이언트 측 코드가 웹 브라우저의 CORS 제한 사항을 준수하는지 확인해야 합니다.
+```
 
 ## Quest
 * 이번 퀘스트는 Midterm에 해당하는 과제입니다. 분량이 제법 많으니 한 번 기능별로 세부 일정을 정해 보고, 과제 완수 후에 그 일정이 얼마나 지켜졌는지 스스로 한 번 돌아보세요.

From f8d99f65c9f71b1b24a1f98ea7e87945b28b87dc Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Fri, 7 Apr 2023 23:51:08 +0900
Subject: [PATCH 19/29] CheckList Clear

---
 Quest10/README.md | 87 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 87 insertions(+)

diff --git a/Quest10/README.md b/Quest10/README.md
index 613fbd17c..6e7055cdc 100644
--- a/Quest10/README.md
+++ b/Quest10/README.md
@@ -15,14 +15,101 @@
 
 ## Checklist
 * 쿠키란 무엇일까요?
+```
+쿠키는 사용자가 웹 사이트와 상호 작용할 때 웹 서버에 의해 사용자 컴퓨터에 저장되는 작은 텍스트 파일입니다. 사용자의 브라우징 동작 및 기본 설정에 대한 정보를 저장하는 데 사용됩니다. 쿠키는 일반적으로 사용자 설정을 기억하고 사용자 세션을 유지하며 콘텐츠를 개인화하여 웹 사이트에서 사용자 경험을 향상시키는 데 사용됩니다.
+
+쿠키는 웹서버가 이용자의 웹브라우저에게 보내는 것으로 이용자의 컴퓨터에 저장됩니다. 사용자가 향후 동일한 웹 사이트를 다시 방문하면 웹 브라우저는 쿠키를 웹 서버로 다시 전송하여 서버가 사용자를 인식하고 저장된 정보를 검색할 수 있도록 합니다. 쿠키는 영구적이거나 세션 기반일 수 있습니다.
+
+영구 쿠키: 이 쿠키는 사용자가 웹 브라우저를 닫은 후에도 사용자의 컴퓨터에 남아 있습니다. 쿠키는 웹 사이트에서 설정한 만료 날짜가 있으며 웹 사이트를 여러 번 방문하는 동안 사용자 기본 설정 또는 설정을 기억하는 데 사용됩니다.
+세션 쿠키: 이 쿠키는 일시적이며 사용자가 웹사이트를 사용하는 동안에만 사용자 컴퓨터의 메모리에 저장됩니다. 일반적으로 인증 자격 증명과 같은 사용자 세션 정보를 유지하는 데 사용되며 사용자가 웹 브라우저를 닫으면 삭제됩니다.
+
+쿠키는 다음과 같은 다양한 목적으로 사용됩니다.
+
+인증: 쿠키는 일반적으로 사용자 인증 세션을 유지하는 데 사용되어 사용자가 웹사이트에 로그인하고 여러 페이지 또는 방문에 걸쳐 로그인 상태를 유지할 수 있도록 합니다.
+개인화: 쿠키는 언어 기본 설정, 글꼴 크기 및 색 구성표와 같은 사용자 기본 설정 및 설정을 저장하여 웹 사이트에서 사용자 경험을 사용자 정의할 수 있습니다.
+분석: 쿠키는 웹사이트 성능을 분석하고 사용자 경험을 개선하기 위해 페이지 보기, 클릭 및 탐색 경로와 같은 웹사이트에서의 사용자 행동에 대한 익명 데이터를 수집하는 데 사용할 수 있습니다.
+광고: 쿠키는 사용자의 검색 기록 및 기본 설정을 기반으로 대상 광고를 제공하기 위해 사용자의 관심과 행동을 추적할 수 있습니다.
+
+쿠키는 잠재적으로 사용자 행동을 추적하고 개인 정보를 수집할 수 있으므로 개인 정보 보호 문제를 제기할 수도 있다는 점에 유의해야 합니다. 따라서 웹사이트는 쿠키 사용에 대한 명확한 정보를 제공하고 해당 개인 정보 보호법 및 규정에 따라 사용자 동의를 얻어야 합니다. 사용자는 원하는 경우 쿠키 삭제 또는 차단을 포함하여 웹 브라우저에서 쿠키 설정을 관리할 수도 있습니다.
+```
   * 쿠키는 어떤 식으로 동작하나요?
+  ```
+  쿠키는 사용자 컴퓨터의 웹 서버에 의해 생성되고 저장된 다음 동일한 사용자의 웹 브라우저에서 후속 요청과 함께 동일한 서버로 다시 전송되는 방식으로 작동합니다. 프로세스에는 일반적으로 다음 단계가 포함됩니다.
+  1. 생성: 사용자가 웹사이트를 방문하면 웹 서버는 하나 이상의 쿠키를 포함할 수 있는 HTTP 응답을 사용자의 웹 브라우저에 보냅니다. 쿠키는 일반적으로 고유 식별자, 사용자 기본 설정 또는 세션 데이터와 같은 정보가 포함된 작은 텍스트 파일입니다.
+  2. 저장: 웹 브라우저는 서버에서 쿠키를 수신하여 사용자 컴퓨터에 로컬로 저장합니다. 쿠키는 쿠키 유형 및 브라우저 설정에 따라 쿠키 파일 또는 브라우저 메모리와 같은 지정된 위치에 저장됩니다.
+  3. 전송: 사용자가 향후 동일한 웹 사이트를 다시 방문하면 웹 브라우저는 페이지 요청과 함께 웹 서버로 전송되는 HTTP 요청에 저장된 쿠키를 포함합니다. 쿠키는 요청 헤더의 일부로 전송되며 브라우저에 의해 자동으로 포함됩니다.
+  4. 검색: 웹 서버는 사용자의 브라우저에서 요청을 수신하고 요청 헤더에 포함된 쿠키에 액세스할 수 있습니다. 그런 다음 서버는 쿠키에 저장된 정보를 검색하고 이를 사용하여 사용자 경험을 개인화하고 사용자 세션을 유지하거나 다른 작업을 수행할 수 있습니다.
+  5. 만료: 쿠키는 웹 서버에 의해 설정된 만료 날짜를 가질 수 있습니다. 쿠키가 만료 날짜에 도달하면 웹 브라우저는 자동으로 사용자의 컴퓨터에서 쿠키를 삭제합니다. 세션 쿠키는 일반적으로 사용자가 웹 브라우저를 닫을 때 삭제되는 반면 영구 쿠키는 만료일까지 또는 사용자가 수동으로 삭제할 때까지 사용자의 컴퓨터에 남아 있을 수 있습니다.
+  쿠키는 쿠키를 만든 동일한 도메인으로만 전송되며 웹 브라우저는 일반적으로 쿠키에 대한 도메인 간 액세스를 방지하기 위해 이 동일 출처 정책을 시행하므로 사용자 개인 정보 및 보안을 보호하는 데 도움이 됩니다. 또한 쿠키는 많은 국가에서 개인 정보 보호 규정을 따르며 웹 사이트는 쿠키 사용에 대한 명확한 정보를 제공하고 해당 법률 및 규정에 따라 사용자 동의를 얻어야 합니다.
+  ```
   * 쿠키는 어떤 식으로 서버와 클라이언트 사이에 정보를 주고받나요?
+  ```
+  쿠키는 서버와 클라이언트 간에 교환되는 요청 및 응답 메시지의 HTTP 헤더를 사용하여 서버와 클라이언트(일반적으로 웹 브라우저) 간에 정보를 전달합니다. 프로세스는 다음과 같이 요약할 수 있습니다.
+  1. 서버 측: 사용자가 웹사이트를 방문하면 웹 서버는 하나 이상의 쿠키를 포함하는 응답을 생성합니다. 서버는 쿠키 값을 설정하고 응답 헤더에 포함합니다. 쿠키는 일반적으로 쿠키의 이름-값 쌍과 만료일, 도메인 및 경로와 같은 추가 속성을 포함하는 "Set-Cookie" 헤더로 전송됩니다.
+  2. 클라이언트 측: 클라이언트(웹 브라우저)는 "Set-Cookie" 헤더의 쿠키를 포함하여 서버로부터 응답을 받습니다. 클라이언트는 쿠키 유형 및 브라우저 설정에 따라 쿠키 파일 또는 브라우저 메모리와 같은 지정된 위치의 사용자 컴퓨터에 로컬로 쿠키를 저장합니다.
+  3. 보내기: 사용자가 동일한 웹 사이트를 다시 방문하거나 동일한 도메인에 대한 후속 요청을 할 때 클라이언트는 서버로 전송되는 HTTP 요청의 "Cookie" 헤더에 저장된 쿠키를 자동으로 포함합니다. "Cookie" 헤더에는 쿠키의 이름-값 쌍이 포함되어 있으며 서버는 이를 통해 쿠키에 저장된 정보에 액세스하고 검색할 수 있습니다.
+  4. 검색: 서버는 클라이언트로부터 요청을 받고 "Cookie" 헤더에 포함된 쿠키에 액세스할 수 있습니다. 서버는 사용자 기본 설정, 세션 데이터 또는 기타 데이터와 같이 쿠키에 저장된 정보를 검색하고 이를 사용하여 응답을 사용자 지정하거나 필요에 따라 다른 작업을 수행합니다.
+  5. 만료: 쿠키는 서버에 의해 설정된 만료 날짜를 가질 수 있으며, 클라이언트는 만료된 쿠키를 사용자의 컴퓨터에서 자동으로 삭제합니다. 이 프로세스는 일반적으로 후속 요청을 서버에 보내기 전에 클라이언트에서 수행합니다.
+  쿠키는 쿠키를 만든 동일한 도메인으로만 전송되며 웹 브라우저는 일반적으로 쿠키에 대한 도메인 간 액세스를 방지하기 위해 이 동일 출처 정책을 시행하므로 사용자 개인 정보 및 보안을 보호하는 데 도움이 됩니다. 또한 쿠키는 많은 국가에서 개인 정보 보호 규정의 적용을 받으며 웹 사이트는 쿠키 사용에 대한 명확한 정보를 제공하고 해당 법률 및 규정에 따라 사용자 동의를 얻어야 합니다.
+  ```
 * 웹 어플리케이션의 세션이란 무엇일까요?
+```
+웹 응용 프로그램의 맥락에서 세션은 사용자가 웹 응용 프로그램과 상호 작용하는 기간을 말하며 일반적으로 사용자가 로그인하거나 세션을 시작할 때 시작하여 사용자가 로그아웃하거나 세션 시간이 초과될 때 종료됩니다. 비활성으로.
+
+세션을 통해 웹 애플리케이션은 여러 요청 및 응답에서 사용자의 상호 작용에 대한 상태 저장 정보를 유지 관리하여 개인화되고 동적인 기능을 사용할 수 있습니다. 세션 중에 웹 애플리케이션은 사용자가 요청할 때마다 데이터를 다시 입력할 필요 없이 사용자 기본 설정, 인증 상태, 장바구니 내용 또는 기타 애플리케이션별 데이터와 같은 사용자별 데이터를 저장하고 검색할 수 있습니다.
+
+세션은 일반적으로 서버 측에서 구현되며 세션 식별자, 쿠키 또는 URL 재작성과 같은 세션 관리 기술을 사용합니다. 사용자가 세션을 시작하면 일반적으로 세션 식별자가 생성되고 서버 또는 데이터베이스에 저장되는 사용자의 세션 데이터와 연결됩니다. 그런 다음 세션 식별자는 클라이언트에 전송되고(예: 쿠키로 또는 URL에 추가됨) 클라이언트의 후속 요청에 포함되어 세션을 식별하고 관련 세션 데이터를 검색합니다.
+
+세션은 서버측 세션 관리, 클라이언트측 세션 관리 또는 이 둘의 조합과 같은 다양한 방법을 사용하여 관리할 수 있습니다. 서버측 세션 관리에는 세션 데이터를 서버에 저장하고 세션 식별자와 연결하는 것이 포함되며, 클라이언트측 세션 관리에는 클라이언트측에 세션 데이터를 저장(예: 쿠키 또는 로컬 저장소)하고 세션을 포함하는 작업이 포함됩니다. 후속 요청의 데이터.
+
+세션 관리는 민감한 사용자 데이터를 처리하고 인증 및 권한 부여를 관리하는 것과 관련되므로 웹 애플리케이션 보안의 중요한 측면이라는 점에 유의해야 합니다. 보안 세션 식별자 사용, 세션 데이터 암호화, 적절한 세션 시간 초과 및 만료 설정 지정과 같은 적절한 세션 관리 기술은 세션 하이재킹, 세션 고정 및 기타 보안 위협으로부터 보호하는 데 필수적입니다.
+```
   * 세션의 ID와 내용은 각각 어디에 저장되고 어떻게 서버와 교환되나요?
+  ```
+  세션의 ID와 내용은 일반적으로 서로 다른 위치에 저장되며 서버와의 교환 방법은 웹 애플리케이션에서 사용되는 세션 관리 기술에 따라 다릅니다. 두 가지 일반적인 접근 방식이 있습니다.
+  1. 서버 측 세션 관리: 이 접근 방식에서는 세션 ID와 내용이 서버에 저장됩니다. 사용자가 세션을 시작하면 서버는 고유한 세션 ID를 생성하고 이를 서버의 메모리나 데이터베이스에 저장된 세션 데이터와 연결합니다. 그런 다음 세션 ID는 클라이언트로 전송되고(일반적으로 쿠키로 또는 URL에 추가됨) 클라이언트에서 서버로의 후속 요청에 포함됩니다.
+  세션 ID는 서버에 저장된 세션 데이터에 대한 참조 역할을 합니다. 서버는 클라이언트로부터 요청을 받으면 요청에 포함된 세션 ID를 사용하여 해당 세션 데이터를 식별하고 세션의 내용을 검색합니다. 그런 다음 서버는 세션 내용을 사용하여 응답을 사용자 지정하거나 필요에 따라 다른 작업을 수행할 수 있습니다.
+  2. 클라이언트 측 세션 관리: 이 접근 방식에서 세션 ID와 콘텐츠는 일반적으로 쿠키 또는 로컬 스토리지에 있는 클라이언트 측에 저장됩니다. 사용자가 세션을 시작하면 세션 ID와 콘텐츠가 클라이언트의 브라우저에 저장됩니다. 세션 ID는 일반적으로 HTTP 요청의 "Cookie" 헤더에 쿠키로 서버에 전송되며 서버는 세션 ID를 사용하여 해당 세션 데이터를 식별하고 세션 내용을 검색합니다.
+  두 접근 방식 모두에서 세션 ID는 서버 또는 클라이언트 측에 저장된 세션 데이터를 참조하기 위해 서버와 클라이언트 간에 교환되는 고유 식별자 역할을 합니다. 세션 콘텐츠에는 일반적으로 사용자 기본 설정, 인증 상태 또는 기타 응용 프로그램 관련 데이터와 같은 사용자 또는 세션 관련 데이터가 포함됩니다.
+  세션 ID 및 콘텐츠를 포함한 세션 데이터의 교환은 무단 액세스로부터 보호하고 세션 데이터의 기밀성과 무결성을 보장하기 위해 암호화 및 인증과 같은 적절한 조치를 사용하여 보안을 유지해야 합니다. 적절한 세션 관리 기술 및 보안 조치는 사용자 데이터를 보호하고 세션 관련 취약점 및 공격으로부터 보호하는 데 중요합니다.
+  ```
 * JWT란 무엇인가요?
+```
+JWT는 JSON 웹 토큰을 나타냅니다. JSON 개체로 당사자 간에 전송될 클레임을 나타내는 컴팩트한 URL 안전 수단입니다. JWT는 종종 웹 애플리케이션 및 API에서 인증 및 권한 부여 목적으로 사용됩니다.
+
+JWT는 헤더, 페이로드 및 서명의 세 부분으로 구성됩니다. 헤더에는 일반적으로 토큰 유형(JSON 웹 토큰의 경우 "JWT") 및 토큰 서명에 사용되는 알고리즘에 대한 정보가 포함됩니다. 페이로드에는 사용자 ID, 만료 시간 및 기타 사용자 지정 클레임과 같이 인증 중인 사용자 또는 엔터티에 대한 클레임 또는 정보가 포함됩니다. 서명은 암호화된 헤더, 암호화된 페이로드, 비밀 키를 지정된 알고리즘으로 해싱하여 생성되며 토큰의 무결성 및 진위를 확인하는 데 사용됩니다.
+
+JWT는 상태 비저장 및 확장 가능한 방식으로 당사자 간에 인증 정보를 전송하는 수단으로 자주 사용됩니다. 사용자가 로그인하거나 인증하면 서버는 JWT를 생성하고 이를 응답에 포함합니다. 그런 다음 클라이언트는 일반적으로 로컬 스토리지 또는 쿠키에 JWT를 저장하고 "Authorization" 헤더의 서버에 대한 후속 요청에 포함할 수 있습니다. 그런 다음 서버는 JWT의 서명을 확인하고 페이로드를 디코딩하여 사용자 또는 엔티티 정보를 얻은 다음 이를 사용하여 요청된 작업을 인증하고 권한을 부여할 수 있습니다.
+
+JWT 사용의 이점 중 하나는 JWT가 독립적이라는 점입니다. 즉, 필요한 모든 정보가 토큰 자체에 포함되어 있고 세션 데이터를 서버에 저장할 필요가 없습니다. 따라서 JWT는 확장 가능하고 분산 시스템에 적합합니다. JWT는 또한 당사자 간에 URL 안전 문자열로 쉽게 전송할 수 있으므로 이식성이 있어 API 및 마이크로서비스에서 사용하기에 이상적입니다.
+
+그러나 JWT를 제대로 보호하지 않으면 잠재적으로 변조되거나 가로챌 수 있으므로 JWT를 안전하게 처리하는 것이 중요합니다. JWT의 기밀성, 무결성 및 신뢰성을 보장하기 위해 서명, 서명 유효성 검사 및 비밀 키의 안전한 저장을 위한 보안 알고리즘 사용과 같은 적절한 조치를 구현해야 합니다. 또한 JWT의 페이로드 콘텐츠는 토큰에 액세스할 수 있는 모든 사람이 볼 수 있으므로 적절한 암호화 또는 마스킹 없이 민감한 정보를 페이로드에 포함해서는 안 됩니다.
+```
   * JWT 토큰은 어디에 저장되고 어떻게 서버와 교환되나요?
+  ```
+  JWT 토큰은 상태 비저장 및 독립형으로 설계되었기 때문에 일반적으로 클라이언트 측 로컬 저장소, 세션 저장소 또는 쿠키에 저장됩니다. 서버는 성공적인 인증 또는 권한 부여 시 JWT 토큰을 생성하고 이를 클라이언트에 대한 응답에 포함합니다. 그런 다음 클라이언트는 JWT 토큰을 저장하고 추가 작업을 인증하고 승인하는 수단으로 서버에 대한 후속 요청에 포함합니다.
+  JWT 토큰을 서버와 교환하는 정확한 방법은 애플리케이션의 아키텍처 및 구현에 따라 다릅니다. 다음은 몇 가지 일반적인 접근 방식입니다.
+  1. 인증 헤더: JWT 토큰은 HTTP 요청의 "인증" 헤더에 포함될 수 있습니다. 클라이언트는 헤더 값을 "Bearer {JWT 토큰}"으로 설정합니다. 여기서 "{JWT 토큰}"은 실제 JWT 토큰입니다. 그런 다음 서버는 "Authorization" 헤더에서 토큰을 확인하고 페이로드를 디코딩하여 사용자 또는 엔터티 정보를 얻은 다음 이를 사용하여 요청된 작업을 인증하고 권한을 부여합니다.
+  2. 쿠키: JWT 토큰은 클라이언트의 브라우저에 쿠키로 저장될 수 있습니다. 서버는 응답에 JWT 토큰을 쿠키로 포함하고 클라이언트의 브라우저는 자동으로 쿠키를 후속 요청과 함께 서버로 다시 보냅니다. 그런 다음 서버는 쿠키에서 토큰을 확인하고 페이로드를 디코딩하여 인증 및 권한 부여에 사용합니다.
+  3. 쿼리 매개변수: JWT 토큰은 HTTP 요청의 URL에 쿼리 매개변수로 포함될 수 있습니다. 클라이언트는 "?token={JWT 토큰}"과 같은 쿼리 매개변수로 JWT 토큰을 URL에 추가합니다. 그런 다음 서버는 쿼리 매개변수에서 토큰을 추출하고 이를 확인하며 페이로드를 디코딩하고 인증 및 권한 부여에 사용합니다.
+  JWT 토큰을 서버와 교환할 때 무단 액세스로부터 보호하고 JWT의 기밀성, 무결성 및 신뢰성을 보장하기 위해 적절한 보안 조치를 구현해야 한다는 점에 유의해야 합니다. 여기에는 보안 통신 채널(예: HTTPS)을 사용하여 토큰을 전송하고, 서버 측에서 토큰을 적절하게 검증 및 확인하고, XSS(교차 사이트 스크립팅) 및 CSRF(교차 사이트 요청 위조) 공격으로부터 토큰을 보호하는 것이 포함됩니다.
+  ```
 * 세션에 비해 JWT가 가지는 장점은 무엇인가요? 또 JWT에 비해 세션이 가지는 장점은 무엇인가요?
+```
+세션에 비해 JWT의 장점:
+
+1. 상태 비저장: JWT는 상태 비저장이므로 필요한 모든 정보가 토큰 자체에 포함되어 있습니다. 이를 통해 서버 측 세션 스토리지가 필요하지 않으므로 JWT의 확장성이 향상되고 여러 서버 또는 마이크로 서비스가 포함될 수 있는 분산 시스템에 적합합니다.
+2. 이식성: JWT는 이식성이 있으며 당사자 간에 URL 안전 문자열로 쉽게 전송할 수 있습니다. 따라서 서로 다른 서비스 또는 도메인 간에 인증 및 권한 부여 정보를 전달해야 할 수 있는 API 및 마이크로 서비스에서 사용하기에 이상적입니다.
+3. 분산형: JWT는 분산형 인증 및 승인을 허용합니다. JWT를 생성하는 서버는 토큰에 사용자 지정 클레임을 포함하여 권한 및 역할을 세밀하게 제어할 수 있습니다. 이렇게 하면 데이터베이스를 자주 조회하거나 세션 상태를 공유할 필요가 없으므로 특정 시나리오에서 JWT가 더 효율적입니다.
+
+JWT에 비해 세션의 장점:
+
+1. 서버 측 제어: 세션은 서버 측에서 관리되므로 세션 상태 및 사용자 세션을 보다 세밀하게 제어할 수 있습니다. 이는 세션 관리를 위해 서버 측 처리 또는 사용자 지정이 필요한 시나리오에서 유용할 수 있습니다.
+2. 철회: 서버측에서 세션을 쉽게 철회할 수 있으므로 사용자 세션을 즉시 종료할 수 있습니다. 반대로 JWT는 일반적으로 사전 정의된 만료 시간이 있으며 토큰 취소 목록 또는 블랙리스트 작성과 같은 추가 조치가 구현되지 않는 한 만료 전에 쉽게 취소할 수 없습니다.
+3. 호환성: 세션은 쿠키 또는 기타 서버측 메커니즘에 의존하므로 대부분의 웹 브라우저에서 즉시 지원됩니다. 반면에 JWT는 토큰 생성, 유효성 검사 및 저장을 처리하기 위해 추가 클라이언트 측 구현 또는 라이브러리가 필요할 수 있습니다.
 
+JWT와 세션 간의 선택은 애플리케이션의 특정 요구 사항과 제약 조건에 따라 다릅니다. JWT는 일반적으로 API 및 마이크로 서비스와 같이 확장성과 이식성이 중요한 상태 비저장 및 분산 시스템에서 선호됩니다. 반면 세션은 서버 측 제어, 해지 또는 레거시 시스템이나 브라우저와의 호환성이 우선 순위인 시나리오에서 선호될 수 있습니다. 인증 및 권한 부여 메커니즘의 기밀성, 무결성 및 신뢰성을 보장하기 위해 적절한 보안 조치를 구현해야 합니다.
+```
 ## Quest
 * 이번에는 메모장 시스템에 로그인 기능을 넣고자 합니다.
   * 사용자는 딱 세 명만 존재한다고 가정하고, 아이디와 비밀번호, 사용자의 닉네임은 하드코딩해도 무방합니다.

From aa2016b9b331c8286fa87bebd89f251eb07ce4b6 Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Sat, 8 Apr 2023 00:43:42 +0900
Subject: [PATCH 20/29] CheckList Save

---
 Quest11/README.md | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Quest11/README.md b/Quest11/README.md
index b9ac1bd54..2505c325c 100644
--- a/Quest11/README.md
+++ b/Quest11/README.md
@@ -17,6 +17,20 @@
 
 ## Checklist
 * RDBMS 테이블의 정규화는 무엇인가요?
+```
+관계형 데이터베이스 관리 시스템(RDBMS) 맥락에서 정규화는 중복을 최소화하고 데이터 무결성을 보장하는 방식으로 데이터베이스 테이블을 구성하고 구조화하는 프로세스를 의미합니다. 정규화의 목표는 데이터 중복을 제거하고 불일치를 방지하며 테이블 간의 관계를 설정하여 체계적이고 효율적인 관계형 데이터베이스를 만드는 것입니다.
+
+정규화에는 일반적으로 큰 테이블을 각각 고유한 목적을 가진 더 작고 더 특수화된 테이블로 나눈 다음 기본 키 및 외래 키와 같은 키를 사용하여 이러한 테이블 간의 관계를 설정하는 작업이 포함됩니다. 중복을 최소화하고 데이터 무결성을 향상시키기 위해 테이블을 구조화하기 위한 지침을 제공하는 일반적으로 정규 형식(NF)이라고 하는 몇 가지 정규화 형식 또는 수준이 있습니다.
+
+RDBMS에서 정규화의 이점 중 일부는 다음과 같습니다.
+
+1. 데이터 중복 제거: 정규화는 데이터 중복을 제거하고 각 데이터 조각이 데이터베이스의 한 위치에만 저장되도록 합니다. 이것은 필요한 저장 공간을 줄이고 데이터의 불일치 또는 모순의 위험을 최소화합니다.
+2. 향상된 데이터 무결성: 정규화는 데이터가 일관되고 조직적인 방식으로 저장되도록 하여 데이터 무결성 제약 조건을 적용하는 데 도움이 됩니다. 이렇게 하면 삽입, 업데이트 및 삭제 이상과 같은 데이터 이상을 방지하여 데이터가 일관되지 않거나 잘못될 수 있습니다.
+3. 간소화된 데이터베이스 유지 관리: 정규화를 통해 데이터베이스 구조를 보다 모듈화하고 유지 관리하기가 더 쉬워집니다. 데이터 모델에 대한 변경 또는 업데이트는 데이터베이스의 다른 부분에 영향을 주지 않고 지역화된 방식으로 이루어질 수 있습니다. 따라서 요구 사항이 변화함에 따라 데이터베이스 구조를 보다 쉽게 ​​관리하고 수정할 수 있습니다.
+4. 향상된 쿼리 성능: 정규화는 처리해야 하는 데이터의 양을 줄이고 복잡한 조인 또는 중복 데이터 검색의 필요성을 제거하여 쿼리 성능을 향상시킬 수 있습니다. 이는 특히 데이터 무결성 수준이 높은 대규모 데이터베이스에서 보다 효율적이고 빠른 데이터베이스 쿼리를 생성할 수 있습니다.
+
+전반적으로 정규화는 RDBMS 설계에서 관계형 데이터베이스의 무결성, 효율성 및 유지 관리 가능성을 보장하는 데 도움이 되는 중요한 개념입니다. 1NF(1차 정규형), 2NF(2차 정규형), 3NF(3차 정규형) 및 상위 형식과 같은 다양한 정규화 형식은 특정 요구 사항을 충족하고 데이터 중복을 최소화하도록 데이터베이스 테이블을 구성하기 위한 지침을 제공합니다.
+```
 * MySQL 외의 RDB에는 어떤 것들이 있나요?
   * Relational Database 외에 다른 DB에는 어떤 것들이 있을까요?
 * RDBMS에서 테이블의 인덱싱은 무엇인가요? 인덱싱을 하면 어떤 점이 다르며, 어떤 식으로 동작하나요?

From f4e3569af50109b12bc38836ffa539df2b84f624 Mon Sep 17 00:00:00 2001
From: SungYeonJun <elwlahs60@gmail.com>
Date: Mon, 10 Apr 2023 01:35:36 +0900
Subject: [PATCH 21/29] Quest 11 CheckList Clear

---
 Quest11/README.md | 126 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

diff --git a/Quest11/README.md b/Quest11/README.md
index 2505c325c..aa14ff035 100644
--- a/Quest11/README.md
+++ b/Quest11/README.md
@@ -32,14 +32,140 @@ RDBMS에서 정규화의 이점 중 일부는 다음과 같습니다.
 전반적으로 정규화는 RDBMS 설계에서 관계형 데이터베이스의 무결성, 효율성 및 유지 관리 가능성을 보장하는 데 도움이 되는 중요한 개념입니다. 1NF(1차 정규형), 2NF(2차 정규형), 3NF(3차 정규형) 및 상위 형식과 같은 다양한 정규화 형식은 특정 요구 사항을 충족하고 데이터 중복을 최소화하도록 데이터베이스 테이블을 구성하기 위한 지침을 제공합니다.
 ```
 * MySQL 외의 RDB에는 어떤 것들이 있나요?
+```
+관계형 데이터베이스 관리 시스템(RDBMS)은 사용자가 관계형 데이터베이스를 생성, 관리 및 조작할 수 있도록 하는 소프트웨어 응용 프로그램입니다. 널리 사용되는 오픈 소스 RDBMS인 MySQL 외에도 시장에서 사용할 수 있는 몇 가지 잘 알려진 RDBMS 옵션이 있습니다. 이들 중 일부는 다음과 같습니다.
+
+Microsoft SQL Server: Microsoft에서 개발한 SQL Server는 견고성, 확장성 및 다른 Microsoft 제품과의 통합으로 잘 알려진 널리 사용되는 RDBMS입니다. 복잡한 쿼리 지원, 비즈니스 인텔리전스 도구 및 데이터 웨어하우징 기능과 같은 고급 기능을 제공합니다.
+Oracle Database: Oracle Corporation에서 개발한 Oracle Database는 가장 강력하고 기능이 풍부한 RDBMS 옵션 중 하나입니다. 고성능, 확장성 및 보안 기능으로 유명합니다. 미션 크리티컬 애플리케이션 및 데이터를 처리하기 위해 대기업에서 널리 사용됩니다.
+PostgreSQL: "Postgres"라고도 하는 PostgreSQL은 확장성, 안정성 및 SQL 표준 준수로 잘 알려진 널리 사용되는 오픈 소스 RDBMS입니다. 공간 데이터, 전체 텍스트 검색 및 JSON 데이터 유형 지원과 같은 고급 기능을 제공합니다.
+IBM Db2: IBM에서 개발한 Db2는 확장성, 보안 및 IBM의 다른 소프트웨어 제품과의 통합과 같은 엔터프라이즈급 기능으로 잘 알려진 RDBMS를 포함한 데이터 관리 제품군입니다. 복잡한 워크로드 및 데이터 집약적인 애플리케이션을 처리하기 위해 대기업에서 널리 사용됩니다.
+SQLite: SQLite는 모바일 장치, 웹 브라우저 및 내장형 시스템을 비롯한 많은 응용 프로그램에 내장된 경량 파일 기반 RDBMS입니다. 단순성, 효율성 및 자체 포함 특성으로 유명하여 모바일 앱 및 기타 소규모 애플리케이션의 로컬 스토리지로 널리 사용됩니다.
+
+이것은 MySQL 외에 다른 RDBMS 옵션의 몇 가지 예일 뿐입니다. 시장에는 각각 고유한 기능, 강점 및 사용 사례가 있는 다른 많은 RDBMS 옵션이 있습니다. RDBMS의 선택은 응용 프로그램의 특정 요구 사항, 확장성 요구 사항, 예산 및 개발 팀의 기술 집합과 같은 다양한 요소에 따라 달라집니다.
+```
   * Relational Database 외에 다른 DB에는 어떤 것들이 있을까요?
+  ```
+  관계형 데이터베이스 외에도 최신 소프트웨어 응용 프로그램에 사용되는 몇 가지 다른 유형의 데이터베이스가 있습니다. 이들 중 일부는 다음과 같습니다.
+  
+  1. NoSQL 데이터베이스: NoSQL("not only SQL"을 의미함) 데이터베이스는 기존의 관계형 데이터베이스 모델을 따르지 않는 데이터베이스 클래스입니다. 소셜 미디어 데이터, 센서 데이터 및 멀티미디어 콘텐츠와 같은 대량의 비정형 또는 반정형 데이터를 처리하도록 설계되었습니다. NoSQL 데이터베이스의 예로는 MongoDB(문서 기반 데이터베이스), Cassandra(열 형식 데이터베이스) 및 Redis(키-값 저장소)가 있습니다.
+  2. 그래프 데이터베이스: 그래프 데이터베이스는 그래프로 구성된 상호 연결된 노드 또는 정점의 형태로 데이터를 저장하고 관리하도록 설계되었습니다. 소셜 네트워크, 추천 엔진 및 사기 탐지와 같이 데이터 요소 간의 관계가 중요한 사용 사례에 특히 적합합니다. 그래프 데이터베이스의 예로는 Neo4j, Amazon Neptune 및 OrientDB가 있습니다.
+  3. 시계열 데이터베이스: 시계열 데이터베이스는 센서 데이터, 로그 파일 및 금융 데이터와 같은 대량의 타임스탬프 데이터를 처리하는 데 최적화되어 있습니다. 시간이 지남에 따라 변경되는 데이터를 효율적으로 저장, 관리 및 분석하도록 설계되었습니다. 시계열 데이터베이스의 예로는 InfluxDB, TimescaleDB 및 OpenTSDB가 있습니다.
+  4. 열형 데이터베이스: 열형 데이터베이스는 행이 아닌 열에 데이터를 저장하므로 빠른 쿼리 및 집계가 필요한 분석 워크로드에 적합합니다. 일반적으로 데이터 웨어하우징, 비즈니스 인텔리전스 및 분석 애플리케이션에 사용됩니다. 열 형식 데이터베이스의 예로는 Google Bigtable, Apache HBase 및 ClickHouse가 있습니다.
+  5. 객체 지향 데이터베이스: 객체 지향 데이터베이스는 복잡한 객체와 그 관계를 저장하고 관리하도록 설계되어 객체 지향 프로그래밍 언어와 객체 지향 데이터 모델을 다루는 애플리케이션에 적합합니다. 객체 지향 데이터베이스의 예로는 db4o, ObjectDB 및 Versant가 있습니다.
+  
+  이는 관계형 데이터베이스 외에 다른 유형의 데이터베이스에 대한 몇 가지 예일 뿐입니다. 각 유형의 데이터베이스에는 고유한 강점과 사용 사례가 있으며 데이터베이스 선택은 응용 프로그램의 특정 요구 사항, 데이터 모델, 성능 요구 사항 및 확장성 고려 사항에 따라 다릅니다.
+  ```
 * RDBMS에서 테이블의 인덱싱은 무엇인가요? 인덱싱을 하면 어떤 점이 다르며, 어떤 식으로 동작하나요?
+```
+RDBMS(관계형 데이터베이스 관리 시스템)의 인덱싱은 테이블에서 데이터 검색 및 쿼리를 최적화하는 데 사용되는 기술입니다. 여기에는 하나 이상의 열에 있는 값을 기반으로 테이블에서 행을 찾고 검색하는 더 빠르고 효율적인 방법을 제공하는 인덱스라고 하는 추가 데이터 구조를 만드는 작업이 포함됩니다.
+
+
+색인은 책 전체를 읽지 않고도 특정 주제를 빠르게 찾을 수 있는 책의 색인 섹션과 비슷합니다. 마찬가지로 데이터베이스 인덱스를 사용하면 RDBMS가 전체 테이블을 스캔하지 않고도 테이블에서 행을 빠르게 찾고 검색할 수 있습니다.
+
+인덱스는 테이블의 하나 이상의 열에 생성할 수 있으며 실제 테이블 데이터와 별도로 저장됩니다. 인덱스가 있는 열과 관련된 쿼리가 실행될 때 RDBMS는 인덱스를 사용하여 전체 테이블을 스캔하는 대신 쿼리 기준과 일치하는 행을 빠르게 찾을 수 있습니다. 이는 특히 수백만 또는 수십억 개의 행이 있는 대형 테이블의 경우 쿼리 성능을 크게 향상시킬 수 있습니다.
+
+다음을 포함하여 RDBMS에서 사용할 수 있는 다양한 유형의 인덱스가 있습니다.
+
+1. B-Tree 인덱스: RDBMS에서 가장 많이 사용되는 인덱스 유형입니다. 부울 또는 열거형 열과 같이 고유 값 수가 적은 열에 적합합니다.
+2. 해시 인덱스: 이 유형의 인덱스는 고유 값의 수가 많은 카디널리티가 높은 열에 사용됩니다. 해시 인덱스는 일반적으로 범위 쿼리 또는 패턴 일치에 대한 B-Tree 인덱스만큼 효율적이지 않습니다.
+3. 비트맵 인덱스: 이 유형의 인덱스는 부울 또는 열거형 열과 같이 소수의 고유 값이 있는 열에 사용됩니다. 비트맵 인덱스는 여러 열을 포함하는 쿼리 술어에 특히 효율적입니다.
+4. 전체 텍스트 인덱스: 이 유형의 인덱스는 대용량 텍스트 문서를 저장하는 열에 사용되며 키워드 또는 구문을 기반으로 텍스트 데이터를 효율적으로 검색하고 가져올 수 있습니다.
+5. 공간 인덱스: 이 유형의 인덱스는 지리적 또는 기하학적 데이터와 같은 공간 데이터를 저장하는 열에 사용됩니다. 공간 인덱스는 특정 거리 내의 점 찾기 또는 지정된 영역과 교차하는 다각형 찾기와 같은 공간 쿼리에 최적화되어 있습니다.
+
+RDBMS의 인덱싱은 추가 데이터 구조와 유지 관리 오버헤드가 수반되기 때문에 단순히 테이블에 데이터를 저장하는 것과는 다릅니다. 그러나 쿼리 성능을 크게 향상시키고 큰 테이블에서 데이터를 검색하는 데 필요한 시간을 줄일 수 있습니다. 최적의 성능을 달성하려면 응용 프로그램의 특정 요구 사항 및 쿼리 패턴을 기반으로 적절한 인덱스를 신중하게 계획하고 선택하는 것이 중요합니다.
+```
 * ORM을 사용하는 것은 사용하지 않는 것에 비해 어떤 장단점을 가지고 있나요?
+```
+ORM(Object-Relational Mapping)은 객체 지향 프로그래밍 언어 구조를 관계형 데이터베이스 개념에 매핑하기 위해 소프트웨어 개발에 사용되는 기술입니다. Hibernate, Entity Framework 및 Django ORM과 같은 ORM 프레임워크는 개발자가 원시 SQL 쿼리를 작성하는 대신 개체 지향 코드를 사용하여 데이터베이스와 상호 작용할 수 있는 추상화 계층을 제공합니다. 다음은 ORM을 사용하지 않을 때와 비교할 때 장단점입니다.
+
+ORM 사용의 장점:
+
+1. 단순화되고 추상화된 데이터베이스 상호 작용: ORM 프레임워크는 데이터베이스와 상호 작용하는 더 높은 수준의 추상화된 방법을 제공하여 개발자가 원시 SQL 쿼리를 처리하는 대신 객체 및 클래스로 작업할 수 있도록 합니다. 이렇게 하면 특히 개체 지향 프로그래밍에 더 익숙한 개발자의 경우 코드베이스를 보다 유지 관리하기 쉽고 이해하기 쉽게 만들 수 있습니다.
+2. 이식성 및 데이터베이스 독립성: ORM 프레임워크는 종종 개발자가 최소한의 코드 변경으로 다른 데이터베이스(예: MySQL, PostgreSQL 및 SQLite) 간에 전환할 수 있는 추상화 계층을 제공합니다. 이를 통해 프로젝트 또는 조직의 요구 사항에 따라 데이터베이스를 선택하고 전환할 때 유연성을 높일 수 있습니다.
+3. 생산성 및 더 빠른 개발: ORM 프레임워크는 CRUD(만들기, 읽기, 업데이트, 삭제) 작업, 트랜잭션 및 쿼리 작성과 같은 일반적인 데이터베이스 작업을 추상화하여 생산성 향상을 제공할 수 있습니다. 이는 개발자가 반복적인 데이터베이스 관련 코드를 작성할 필요가 없기 때문에 개발 시간과 노력을 절약할 수 있습니다.
+4. SQL 인젝션 취약점 감소: ORM 프레임워크는 일반적으로 원시 SQL 쿼리를 직접 실행하는 애플리케이션의 일반적인 보안 취약점일 수 있는 SQL 인젝션 공격으로부터 보호하기 위한 기본 제공 메커니즘을 제공합니다. ORM 프레임워크는 일반적으로 SQL 삽입 공격을 방지하기 위해 사용자 입력의 이스케이프를 자동으로 처리하는 매개변수화된 쿼리 또는 준비된 명령문을 사용합니다.
+
+ORM 사용의 단점:
+
+1. 성능 오버헤드: ORM 프레임워크는 원시 SQL 쿼리를 작성하는 것과 비교하여 성능 오버헤드를 추가할 수 있는 추가 추상화 계층을 도입합니다. ORM 프레임워크는 복잡한 SQL 쿼리를 생성하는 경우가 많으며 특정 경우, 특히 복잡한 쿼리 또는 트랜잭션 속도가 높은 애플리케이션의 경우 성능이 수동으로 최적화된 SQL 쿼리만큼 최적이 아닐 수 있습니다.
+2. 데이터베이스 최적화에 대한 제한된 제어: ORM 프레임워크는 기본 데이터베이스 최적화 및 기능을 추상화하여 데이터베이스별 인덱싱, 저장 프로시저 또는 고급 쿼리 최적화와 같은 고급 데이터베이스 기능을 활용하기 어렵게 만듭니다. 이로 인해 원시 SQL 쿼리로 달성할 수 있는 성능 최적화가 제한될 수 있습니다.
+3. 학습 곡선 및 복잡성: ORM 프레임워크에는 종종 학습 곡선이 있으며 특히 관계형 데이터베이스 또는 ORM 프레임워크의 개념에 익숙하지 않은 개발자의 경우 개발 프로세스에 복잡성을 추가할 수 있습니다. 개발 프로세스에 학습 곡선을 추가할 수 있는 ORM 프레임워크의 구문, 구성 및 사용법을 배워야 할 수도 있습니다.
+4. 사용자 지정 제한: ORM 프레임워크는 특정 데이터베이스의 모든 고급 또는 사용자 지정 기능을 지원하지 않거나 사용자 지정 또는 확장성 측면에서 제한이 있을 수 있습니다. 이로 인해 개발자는 복잡하고 오류가 발생하기 쉬운 경우에 원시 SQL 쿼리를 작성하거나 ORM 프레임워크를 우회해야 할 수 있습니다.
+
+요약하면 ORM을 사용하면 단순화된 데이터베이스 상호 작용, 이식성, 생산성 및 향상된 보안과 같은 이점을 제공할 수 있습니다. 그러나 성능 오버헤드, 사용자 지정 제한 및 추가 복잡성이 발생할 수도 있습니다. ORM 사용 여부에 대한 결정은 성능 고려 사항, ORM에 대한 팀의 친숙도, 사용자 지정 또는 고급 데이터베이스 기능의 필요성을 포함하여 프로젝트의 특정 요구 사항 및 장단점에 따라 달라집니다.
+```
   * 자바스크립트 생태계의 ORM에는 어떤 것들이 있나요?
+  ```
+  JavaScript 코드를 사용하여 데이터베이스와 상호 작용하기 위한 추상화 계층을 제공하는 JavaScript 에코시스템에서 사용할 수 있는 여러 ORM(Object-Relational Mapping) 라이브러리가 있습니다. JavaScript 생태계에서 인기 있는 ORM 라이브러리는 다음과 같습니다.
+  
+  1. Sequelize: Sequelize는 MySQL, PostgreSQL, SQLite 및 MSSQL을 비롯한 여러 데이터베이스를 지원하는 Node.js 및 JavaScript용으로 널리 사용되는 ORM입니다. 모델, 관계를 정의하고 CRUD 작업을 수행하기 위한 강력하고 유연한 API를 제공합니다.
+  2. TypeORM: TypeORM은 MySQL, PostgreSQL, SQLite 및 MSSQL을 비롯한 여러 데이터베이스를 지원하는 Node.js 및 JavaScript용으로 널리 사용되는 또 다른 ORM입니다. 엔터티, 관계를 정의하기 위한 데코레이터 기반 구문을 제공하고 마이그레이션, 캐싱 및 트랜잭션과 같은 고급 기능을 지원합니다.
+  3. 몽구스(Mongoose): 몽구스는 NoSQL 데이터베이스인 MongoDB용 인기 ORM입니다. 스키마, 모델을 정의하고 JavaScript 또는 TypeScript를 사용하여 MongoDB 데이터베이스를 쿼리하기 위한 간단하고 직관적인 API를 제공합니다.
+  4. Waterline: Waterline은 MySQL, PostgreSQL, MongoDB 등 여러 데이터베이스를 지원하는 Node.js용 다목적 ORM입니다. 모델, 관계를 정의하기 위한 데이터 기반 구문을 제공하고 다양한 데이터베이스에 연결하기 위한 유효성 검사, 수명 주기 후크 및 어댑터와 같은 고급 기능을 지원합니다.
+  5. Bookshelf: Bookshelf는 MySQL, PostgreSQL 및 SQLite와 같은 관계형 데이터베이스와 상호 작용하기 위한 간단하고 표현력이 풍부한 API를 제공하는 Node.js용 경량 ORM입니다. 모델 정의, 관계 및 트랜잭션과 같은 기능을 지원합니다.
+  6. Objection.js: Objection.js는 SQL 데이터베이스용 쿼리 빌더인 Knex.js를 기반으로 구축된 또 다른 인기 있는 Node.js용 ORM입니다. Objection.js는 JavaScript 또는 TypeScript를 사용하여 모델, 관계 및 쿼리 SQL 데이터베이스를 정의하기 위한 간단하고 강력한 API를 제공합니다.
+  
+  이는 JavaScript 생태계에서 사용할 수 있는 많은 ORM 라이브러리의 몇 가지 예일 뿐입니다. ORM의 선택은 프로젝트의 특정 요구 사항, 사용 중인 데이터베이스, ORM 및 해당 기능에 대한 개발 팀의 친숙도에 따라 다릅니다.
+  ```
 * 모델간의 1:1, 1:N, N:M 관계는 각각 무엇이고 어떨 때 사용하나요?
+```
+ORM(Object-Relational Mapping) 컨텍스트에서 1:1, 1:N 및 N:M은 관계형 데이터베이스의 모델 또는 엔터티 간의 서로 다른 유형의 관계를 설명하는 일반적으로 사용되는 용어입니다.
+
+1:1(일대일) 관계: 1:1 관계에서 한 테이블(테이블 A)의 각 레코드는 다른 테이블(테이블 B)의 정확히 하나의 레코드와 연관되며 그 반대의 경우도 마찬가지입니다. 이는 두 테이블 간의 관계가 고유하고 일대일임을 의미합니다. 예를 들어, 학교 데이터베이스에서 "Student" 테이블과 "StudentInfo" 테이블은 1:1 관계를 가질 수 있습니다. 여기서 각 학생은 고유한 학생 정보 레코드가 연결되어 있고 각 학생 정보 레코드는 다음과 연결되어 있습니다. 단 한 명의 학생. 이러한 유형의 관계는 두 엔터티가 엄격한 일대일 대응을 갖고 중복을 방지하고 데이터 무결성을 유지하기 위해 해당 속성을 별도의 테이블로 분리하는 것이 바람직할 때 사용됩니다.
+
+1:N(일대다) 관계: 1:N 관계에서 한 테이블(테이블 A)의 각 레코드는 다른 테이블(테이블 B)의 하나 이상의 레코드와 연결되지만 테이블 B의 각 레코드는 예를 들어 전자 상거래 사이트의 데이터베이스에서 "Customer" 테이블과 "Order" 테이블은 1:N 관계일 수 있습니다. 여기서 각 고객은 여러 주문을 할 수 있지만 각 주문은 한 명의 고객과만 연결됩니다. 이 유형의 관계는 하나의 엔터티가 여러 관련 엔터티를 가질 수 있지만 각 관련 엔터티는 하나의 엔터티에만 연결되는 경우에 사용됩니다.
+
+N:M(다대다) 관계: N:M 관계에서 한 테이블(테이블 A)의 레코드는 다른 테이블(테이블 B)의 여러 레코드와 연결될 수 있으며 그 반대의 경우도 마찬가지입니다. 이는 두 테이블 간의 관계가 다대다임을 의미합니다. 예를 들어 소셜 미디어 플랫폼용 데이터베이스에서 "사용자" 테이블과 "게시물" 테이블은 N:M 관계를 가질 수 있습니다. 여기서 각 사용자는 여러 게시물을 가질 수 있고 각 게시물은 여러 사용자(예: 좋아요)를 가질 수 있습니다. , 댓글, 공유). 이 유형의 관계는 여러 엔터티가 다른 여러 엔터티와 연결될 수 있는 경우에 사용됩니다.
+
+ORM은 개체 지향 프로그래밍 개념을 사용하여 데이터베이스의 모델 또는 엔터티 간의 이러한 관계를 정의하고 처리하는 기능을 제공합니다. 이러한 관계는 복잡한 데이터 시나리오를 모델링하고 데이터베이스에서 관련 데이터를 효율적으로 검색하는 데 도움이 됩니다.
+```
 * DB에 사용자의 암호를 평문으로 저장하지 않고도 사용자의 암호를 인증하는 것이 가능한 이유는 무엇일까요?
+```
+"해싱" 및 "솔팅"이라는 프로세스를 사용하여 데이터베이스에 일반 텍스트로 사용자 암호를 저장하지 않고도 사용자 암호를 인증할 수 있습니다.
+
+해싱은 입력(이 경우 사용자 암호)을 받아 고정 크기의 문자열(일반적으로 16진수 또는 base64 인코딩 문자열)을 생성하는 단방향 함수입니다. 해시라고 하는 출력은 입력에 대해 고유하므로 입력이 조금만 변경되어도 상당히 다른 해시가 생성됩니다. 그러나 동일한 입력은 항상 동일한 해시를 생성합니다.
+
+솔트는 각 사용자에 대해 생성된 임의의 값이며 해싱 전에 암호에 추가됩니다. 그런 다음 소금은 해시와 함께 데이터베이스에 저장됩니다. 사용자가 로그인을 시도하면 입력한 비밀번호에 동일한 솔트가 추가되고 결과 값이 해시되어 저장된 해시와 비교됩니다. 계산된 해시가 저장된 해시와 일치하면 암호가 유효한 것으로 간주되고 사용자가 인증됩니다.
+
+해싱 및 솔팅을 사용하면 다음과 같은 몇 가지 보안 이점이 있습니다.
+
+암호 공격으로부터 보호: 암호를 데이터베이스에 일반 텍스트로 저장하면 데이터 유출 시 공격자가 사용자 계정에 쉽게 액세스할 수 있으므로 보안 위험이 있습니다. 해싱 및 솔팅은 공격자가 저장된 해시에서 원래 비밀번호를 리버스 엔지니어링하는 것을 극도로 어렵게 만들어 레인보우 테이블 공격 또는 무차별 대입 공격과 같은 비밀번호 공격을 훨씬 더 어렵게 만듭니다.
+해시의 개별성: 각 사용자에 대해 고유한 솔트를 사용하여 해싱하면 두 명의 사용자가 동일한 암호를 가지고 있더라도 다른 솔트를 사용하기 때문에 저장된 해시가 달라집니다. 이는 동일한 암호를 사용하는 여러 계정을 대상으로 하는 공격으로부터 보호합니다.
+일반 텍스트 암호를 저장하지 않고 확인: 해싱을 사용하면 실제 암호를 일반 텍스트로 저장하지 않고 암호를 확인할 수 있으며 이는 보안 모범 사례로 간주됩니다. 이는 실제 암호가 데이터베이스에 저장되지 않도록 하여 데이터 위반 및 무단 액세스의 위험을 줄여 사용자 개인 정보를 보호합니다.
+
+요약하면 해싱과 솔팅을 사용하면 암호를 데이터베이스에 일반 텍스트로 저장하지 않고도 사용자의 암호를 인증할 수 있으므로 사용자 계정과 민감한 정보를 보호하기 위한 추가 보안 계층을 제공합니다.
+```
   * 해시 함수에는 어떤 것이 있나요?
+  ```
+  해시 함수는 입력(일반적으로 모든 크기의 메시지 또는 데이터)을 받아 고정 크기 출력, 일반적으로 고정 길이 문자열 또는 바이트를 생성하는 수학적 알고리즘 또는 단방향 함수입니다. 해시 또는 해시 값으로 알려진 출력은 입력 데이터의 고유한 표현이며 입력 데이터의 작은 변경조차도 상당히 다른 해시 값을 생성합니다.
+  
+  해시 함수는 데이터 무결성 확인, 디지털 서명, 암호 저장 및 메시지 인증을 포함하여 컴퓨터 과학 및 정보 보안의 다양한 영역에서 일반적으로 사용됩니다. 계산 속도가 빠르고 각각의 고유한 입력 데이터에 대해 고유한 해시 값을 생성하도록 설계되어 데이터 비교, 데이터 저장 및 데이터 검색과 같은 작업에 유용합니다.
+  
+  해시 함수에는 몇 가지 중요한 속성이 있습니다.
+  
+  1. 결정론적: 주어진 입력은 항상 동일한 해시 값을 생성합니다. 이 속성은 동일한 데이터를 여러 번 해싱할 때 일관되고 반복 가능한 결과를 허용합니다.
+  2. 고정 크기 출력: 해시 함수는 입력 데이터의 크기에 관계없이 고정 크기 출력을 생성합니다. 따라서 고정된 저장 공간을 사용하여 많은 양의 데이터를 저장하고 비교하는 데 효율적입니다.
+  3. 단방향: 해시 함수는 계산상 반전이 불가능하도록 설계되었습니다. 즉, 해시 값에서 원래 입력 데이터를 재구성하는 것이 불가능하지는 않더라도 극히 어렵습니다.
+  4. 고유한 해시 값: 해시 함수는 다른 입력 데이터에 대해 고유한 해시 값을 생성해야 합니다. 입력 데이터가 조금만 변경되어도 해시 값이 크게 달라집니다. 이 속성은 해시 함수를 데이터 무결성의 사소한 변화도 감지하는 데 적합하게 만듭니다.
+  5. 충돌 저항성: 해시 함수는 다른 입력 데이터에 대해 동일한 해시 값을 생성(충돌)하지 않아야 합니다. 두 개의 서로 다른 입력이 동일한 해시 값(충돌)을 생성하는 것이 이론적으로 가능하지만 좋은 해시 함수는 충돌 가능성을 최소화합니다.
+  
+  해시 함수는 데이터 무결성, 인증 및 디지털 서명을 안전하게 표현하고 확인하는 방법을 제공하는 많은 암호화 및 보안 응용 프로그램의 기본 빌딩 블록입니다.
+  ```
   * 사용자의 암호를 해싱하여 저장할 때 어떤 식으로 저장하는 것이 보안에 좋을까요?
+  ```
+  보안을 위해 사용자의 비밀번호를 해싱하여 저장할 때 강력한 해싱 알고리즘, 사용자별 고유 솔트, 여러 번의 해시 함수 반복을 조합하여 사용하여 보안을 강화하는 것이 좋습니다. 일반적으로 "해싱 및 솔팅(hashing and salting)"으로 알려진 이 접근 방식은 암호 공격으로부터 보호하고 저장된 암호 해시가 더 잘 깨지지 않도록 합니다.
+  
+  다음은 해싱 및 솔팅을 사용하여 사용자 비밀번호를 안전하게 저장하는 몇 가지 모범 사례입니다.
+  
+  1. 강력한 해싱 알고리즘 사용: bcrypt, scrypt 또는 Argon2와 같이 암호 해싱을 위해 특별히 설계되었으며 무차별 암호 대입 공격 및 레인보우 테이블 공격을 포함한 다양한 암호 공격에 저항하는 널리 인식되고 암호학적으로 안전한 해시 기능을 선택합니다. .
+  2. 각 사용자에 대해 고유한 솔트 생성: 각 사용자에 대해 임의의 고유한 솔트를 생성하고 암호 해시와 함께 저장합니다. 솔트는 길고 예측 불가능하며 암호학적으로 안전해야 합니다. 이렇게 하면 동일한 암호를 가진 사용자라도 다른 솔트를 사용하기 때문에 다른 해시를 갖게 되어 동일한 암호를 가진 여러 계정을 대상으로 하는 공격으로부터 보호할 수 있습니다.
+  3. 다중 반복(작업 요소) 사용: 암호를 해싱할 때 다중 반복 또는 "작업 요소"를 사용하여 해시 함수의 계산 비용을 증가시킵니다. 이로 인해 공격자가 무차별 암호 대입 공격이나 레인보우 테이블 공격을 통해 암호 해시를 크래킹하는 데 더 많은 시간과 리소스가 필요합니다.
+  4. "페퍼" 사용 고려: 페퍼는 해싱 전에 암호에 추가되고 데이터베이스에 저장되지 않는 비밀 키입니다. 이렇게 하면 공격자가 유효한 해시를 생성하기 위해 후추를 알아야 하므로 해시 값과 솔트에 대한 액세스 권한을 얻더라도 암호를 해독하기가 더 어려워지므로 추가 보안 계층이 추가됩니다.
+  5. 해싱 방법을 정기적으로 검토 및 업데이트: 암호 해싱에 대한 최신 모범 사례를 최신 상태로 유지하고 주기적으로 구현을 검토 및 업데이트하여 진화하는 암호 공격 및 암호화 취약점으로부터 안전하게 유지되도록 합니다.
+  6. 기타 보안 조치 구현: 해싱 및 솔팅만으로는 사용자 암호에 대한 완전한 보안을 제공할 수 없습니다. 보안 통신을 위해 HTTPS를 사용하고, 강력한 인증 메커니즘을 사용하고, 사용자 계정과 중요한 정보를 보호하기 위해 기타 보안 모범 사례를 따르는 것과 같은 다른 보안 조치를 구현하는 것이 필수적입니다.
+  
+  이러한 모범 사례를 따르면 사용자 암호를 안전하게 해시하고 저장하여 사용자 계정에 대한 무단 액세스 위험을 줄이고 중요한 사용자 정보를 보호할 수 있습니다.
+  ```
 
 ## Quest
 * 이번에는 메모장을 파일이 아닌 DB기반으로 만들어 보고자 합니다.

From ef07eff9e3d30c14b89e91856bc8b07d6189b03b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Mon, 10 Apr 2023 10:30:16 +0900
Subject: [PATCH 22/29] Quest 12 CheckList Clear

---
 Quest12/README.md | 83 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 82 insertions(+), 1 deletion(-)

diff --git a/Quest12/README.md b/Quest12/README.md
index 790143a43..71ca6ae30 100644
--- a/Quest12/README.md
+++ b/Quest12/README.md
@@ -16,14 +16,95 @@
 
 ## Checklist
 * 입력 데이터의 Validation을 웹 프론트엔드에서 했더라도 서버에서 또 해야 할까요? 그 이유는 무엇일까요?
+```
+예, 입력 데이터의 유효성 검사는 웹 프런트 엔드에서 유효성을 검사한 경우에도 서버에서 다시 수행해야 합니다. 웹 프런트 엔드에서 발생하는 클라이언트 측 유효성 검사는 악의적인 사용자가 쉽게 우회하거나 조작할 수 있기 때문입니다. 클라이언트 측 유효성 검사는 사용자의 브라우저에서 실행되는 JavaScript 및 기타 기술에 의존하며 악의적인 의도를 가진 사용자가 비활성화하거나 수정할 수 있습니다.
+
+반면에 서버 측 유효성 검사는 데이터의 실제 처리 및 저장이 발생하는 서버에서 수행됩니다. 클라이언트에서 보낸 데이터를 처리하거나 저장하기 전에 유효성을 검사하여 추가 보안 계층을 제공합니다. 서버 측 유효성 검사는 승인되지 않은 데이터나 악의적인 데이터가 서버에서 승인 및 처리되는 것을 방지하여 유효하고 안전한 데이터만 승인되고 처리되도록 합니다.
+
+또한 클라이언트 측 유효성 검사에만 의존하면 클라이언트마다 유효성 검사 로직의 구현이나 버전이 다를 수 있으므로 데이터 무결성의 불일치가 발생할 수 있습니다. 서버 측 유효성 검사는 모든 클라이언트에서 일관되고 표준화된 유효성 검사 프로세스를 보장하여 데이터 불일치의 위험을 줄입니다.
+
+요약하면 클라이언트 측 유효성 검사는 편리하고 사용자 친화적인 경험을 제공할 수 있지만 유일한 유효성 검사 메커니즘으로 의존해서는 안 됩니다. 서버 측 유효성 검사는 데이터 무결성을 보장하고 악의적인 활동을 방지하며 여러 클라이언트에서 일관된 유효성 검사 프로세스를 유지하는 데 필수적입니다.
+```
   * 서버로부터 받은 HTML 내용을 그대로 검증 없이 프론트엔드에 innerHTML 등을 통해 적용하면 어떤 문제점이 있을까요?
+  ```
+  서버에서 받은 HTML 콘텐츠가 적절한 유효성 검사 없이 innerHTML을 통해 프런트 엔드에 적용되면 다음과 같은 몇 가지 문제가 발생할 수 있습니다.
+  
+  1. XSS(Cross-Site Scripting) 공격: 유효성 검사가 없으면 서버는 잠재적으로 HTML 콘텐츠의 일부로 악성 스크립트가 포함된 악성 HTML 코드를 보낼 수 있습니다. 이 HTML을 innerHTML을 사용하여 프런트 엔드에 직접 적용하면 스크립트가 사용자의 브라우저에서 실행되어 XSS 공격이 발생할 수 있습니다. 이로 인해 공격자는 사용자를 대신하여 악성 코드를 삽입하거나 중요한 정보를 도용하거나 기타 승인되지 않은 작업을 수행할 수 있습니다.
+  2. 코드 주입 공격: 서버 측 유효성 검사가 수행되지 않으면 HTML 콘텐츠에 SQL 또는 JavaScript 코드와 같은 승인되지 않은 코드가 포함되어 프런트 엔드 애플리케이션에 주입될 수 있습니다. 이로 인해 공격자가 애플리케이션의 백엔드 데이터베이스에서 데이터를 조작 또는 검색하거나 사용자 브라우저에서 임의의 코드를 실행할 수 있는 코드 삽입 공격이 발생할 수 있습니다.
+  3. 깨진 HTML 구조: 수신된 HTML 콘텐츠에 형식이 잘못되었거나 유효하지 않은 HTML이 포함되어 있는 경우 유효성 검사 없이 프런트 엔드에 적용하면 HTML 구조가 깨질 수 있습니다. 이로 인해 프런트 엔드 애플리케이션에서 렌더링 문제, 손상된 기능 또는 예기치 않은 동작이 발생할 수 있습니다.
+  4. 데이터 무결성 문제: 유효성 검사가 없으면 수신된 HTML 콘텐츠가 예상 데이터 형식 또는 구조를 준수하지 않을 수 있습니다. 이로 인해 부정확하거나 일관성 없는 데이터를 표시하거나 유효하지 않은 데이터를 서버에 저장하는 등의 데이터 무결성 문제가 발생할 수 있습니다.
+  5. 보안 취약성: 서버에서 받은 HTML 콘텐츠의 유효성을 검사하지 않으면 잠재적인 보안 취약성이 눈에 띄지 않아 프런트 엔드 애플리케이션의 잠재적 악용 또는 취약성이 발생할 수 있습니다.
+  
+  요약하면 innerHTML을 사용하여 프런트 엔드에 적용하기 전에 서버에서 받은 HTML 콘텐츠의 적절한 유효성 검사를 수행하지 않으면 프런트 엔드 애플리케이션에서 보안 위험, 데이터 무결성 문제 및 기타 예기치 않은 동작이 발생할 수 있습니다. 프런트 엔드 애플리케이션의 무결성과 보안을 보장하려면 강력한 서버 측 유효성 검사를 구현하는 것이 중요합니다.
+  ```
   * XSS(Cross-site scripting)이란 어떤 공격기법일까요?
+  ```
+  XSS(Cross-Site Scripting)는 악성 스크립트가 웹사이트 또는 웹 애플리케이션에 삽입되고 이러한 스크립트가 영향을 받는 웹사이트를 방문하는 다른 사용자의 브라우저에서 실행되는 웹 기반 공격 기술의 한 유형입니다. XSS 공격은 응용 프로그램이 입력 필드 또는 주석과 같은 사용자 생성 콘텐츠를 적절한 유효성 검사 또는 삭제 없이 웹 페이지에 포함하도록 허용할 때 발생합니다.
+  
+  XSS 공격은 세 가지 주요 유형으로 분류할 수 있습니다.
+  
+  1. Reflected XSS: 이 유형의 XSS 공격에서는 웹 서버로 전송되는 URL 또는 양식 데이터에 악성 스크립트가 포함됩니다. 서버는 악성 스크립트를 사용자의 브라우저에 다시 반영한 다음 스크립트를 실행합니다. 이러한 유형의 XSS 공격은 일반적으로 악의적인 링크로 특정 사용자를 대상으로 하거나 사용자로부터 중요한 정보를 훔치는 데 사용됩니다.
+  2. 저장된 XSS: 이 유형의 XSS 공격에서는 악의적인 스크립트가 웹 서버(일반적으로 데이터베이스)에 저장되고 나중에 영향을 받는 페이지에 액세스할 때 다른 사용자에게 표시됩니다. 이러한 유형의 XSS 공격은 여러 사용자에게 영향을 미치고 악의적인 스크립트를 지속적으로 실행하여 잠재적인 데이터 도난, 무단 작업 또는 기타 악의적인 활동을 유발할 수 있으므로 특히 위험합니다.
+  3. DOM 기반 XSS: 이 유형의 XSS 공격에서는 악의적인 스크립트가 서버로 전송되지 않고 웹 페이지의 DOM(문서 개체 모델)의 클라이언트 측에서 주입 및 실행됩니다. 이러한 유형의 XSS 공격은 일반적으로 사용자 생성 데이터가 적절한 유효성 검사나 인코딩 없이 DOM에 직접 포함될 수 있도록 허용하는 안전하지 않은 JavaScript 코딩 방식으로 인해 발생합니다.
+  
+  XSS 공격은 민감한 정보 도용, 사용자 계정에 대한 무단 액세스, 맬웨어 또는 바이러스 확산, 웹사이트 콘텐츠 손상 또는 조작 등 심각한 결과를 초래할 수 있습니다. XSS 공격을 방지하고 이러한 유형의 취약성으로부터 웹 응용 프로그램을 보호하려면 적절한 입력 유효성 검사, 출력 인코딩 및 기타 보안 조치를 구현해야 합니다.
+  ```
   * CSRF(Cross-site request forgery)이란 어떤 공격기법일까요?
+  ```
+  CSRF(Cross-Site Request Forgery)는 악의적인 웹 사이트가 사용자의 브라우저를 속여 사용자가 인증된 다른 웹 사이트에 무단 요청을 하도록 하는 웹 기반 공격 기술의 한 유형입니다. CSRF 공격은 웹사이트가 사용자의 인증된 세션에서 갖고 있는 신뢰를 악용하여 사용자 대신 무단 작업을 수행합니다.
+  
+  CSRF 공격에서 피해자는 일반적으로 악의적인 웹 사이트를 방문하거나 악의적인 링크를 클릭하도록 유인됩니다. 그런 다음 악성 웹사이트는 피해자의 자격 증명과 피해자의 브라우저에 저장된 세션 쿠키를 사용하여 피해자가 인증된 다른 웹사이트에 승인되지 않은 요청을 보냅니다. 이러한 무단 요청은 피해자가 알지 못하거나 동의하지 않은 상태에서 피해자의 비밀번호 변경, 구매 또는 계정 설정 수정과 같은 작업을 수행할 수 있습니다.
+  CSRF 공격은 이미지 태그, 스크립트 태그, 숨겨진 양식 또는 XMLHttpRequests를 포함하여 다양한 방식으로 수행될 수 있습니다. 공격자가 피해자의 데이터를 직접 조작하거나 피해자 시스템의 취약점을 악용하도록 요구하지 않고 대신 다른 웹 사이트에서 피해자의 활성 세션에 의존합니다.
+  CSRF 공격을 방지하기 위해 웹 애플리케이션은 CSRF 토큰 사용, Referer 헤더 확인, 쿠키에 대한 Same-Site 속성 구현과 같은 적절한 안티 CSRF 방어를 구현해야 합니다. 이러한 방어는 웹 사이트에 대한 요청이 합법적이고 악의적인 제3자 웹 사이트가 아닌 웹 사이트에서 인증된 동일한 사용자에 의해 시작되도록 하는 데 도움이 될 수 있습니다.
+  CSRF 공격은 사용자 계정에 대한 무단 작업, 데이터 변조 및 재정적 손실을 포함하여 심각한 결과를 초래할 수 있습니다. CSRF 취약성으로부터 보호하고 웹 애플리케이션의 무결성과 보안을 보호하기 위해 적절한 보안 조치를 구현해야 합니다.
+  ```
   * SQL Injection이란 어떤 공격기법일까요?
+  ```
+  SQL 인젝션은 악성 SQL(Structured Query Language) 쿼리를 웹 애플리케이션의 입력 필드나 매개변수에 인젝션한 다음 적절한 검증이나 삭제 없이 기본 데이터베이스 관리 시스템(DBMS)에 의해 실행되는 웹 기반 공격 기술의 한 유형입니다. SQL 삽입 공격은 사용자 생성 입력 처리의 취약점을 악용하여 공격자가 데이터베이스에서 데이터를 조작 또는 검색하거나 데이터를 수정 또는 삭제하거나 임의의 SQL 명령을 실행할 수 있도록 합니다.
+  SQL 인젝션 공격은 다음과 같은 다양한 형태로 발생할 수 있습니다.
+  1. 인밴드 SQL 인젝션: 이러한 유형의 SQL 인젝션 공격에서는 인젝션된 SQL 쿼리의 결과가 애플리케이션의 응답에 직접 표시됩니다. 애플리케이션이 적절한 유효성 검사나 인코딩 없이 사용자 입력을 반향하여 공격자가 데이터를 검색하거나 임의의 SQL 명령을 실행할 수 있는 경우 이러한 상황이 발생할 수 있습니다.
+  2. 블라인드 SQL 인젝션: 이 유형의 SQL 인젝션 공격에서는 인젝션된 SQL 쿼리의 결과가 애플리케이션의 응답에 직접 표시되지 않습니다. 공격자는 오류 메시지, 타이밍 지연 또는 기타 단서와 같은 다른 수단을 통해 쿼리 결과를 유추해야 할 수 있습니다.
+  3. 대역 외 SQL 주입: 이러한 유형의 SQL 주입 공격에서 공격자는 주입된 SQL 쿼리의 결과를 애플리케이션의 응답으로 직접 수신하지 않습니다. 대신 공격자는 이메일 또는 DNS 요청과 같은 다른 통신 채널을 사용하여 쿼리 결과를 검색할 수 있습니다.
+  
+  SQL 주입 공격은 민감한 데이터에 대한 무단 액세스, 데이터 조작 또는 삭제, 기본 데이터베이스 서버의 완전한 손상을 포함하여 심각한 결과를 초래할 수 있습니다. SQL 인젝션 취약점을 방지하고 이러한 유형의 공격으로부터 웹 애플리케이션을 보호하려면 적절한 입력 유효성 검사, 매개 변수화된 쿼리 및 기타 보안 조치를 구현해야 합니다.
+  ```
+
 * 대부분의 최신 브라우저에서는 HTTP 대신 HTTPS가 권장됩니다. 이유가 무엇일까요?
+```
+HTTPS(Hypertext Transfer Protocol Secure)는 다음과 같은 몇 가지 이유로 대부분의 최신 브라우저에서 HTTP(Hypertext Transfer Protocol)보다 권장됩니다.
+
+1. 데이터 보안: HTTPS는 웹 브라우저와 웹 서버 간에 교환되는 데이터를 암호화하여 가로채는 사람이 데이터를 읽을 수 없도록 합니다. 이렇게 하면 로그인 자격 증명, 신용 카드 세부 정보 및 기타 개인 데이터와 같은 민감한 정보가 전송 중에 가로채거나 변조되지 않도록 보호할 수 있습니다.
+2. 인증 및 신뢰: HTTPS는 디지털 인증서를 사용하여 웹 서버의 ID를 인증하여 사용자가 사기성 웹사이트가 아닌 합법적인 웹사이트와 통신하고 있음을 확인할 수 있는 방법을 제공합니다. 이는 전자 상거래 사이트, 온라인 뱅킹 및 민감한 정보를 처리하는 기타 웹 사이트에 특히 중요한 웹 사이트의 신뢰성에 대한 신뢰와 신뢰를 구축하는 데 도움이 됩니다.
+3. 검색 엔진 순위: Google을 포함한 많은 검색 엔진은 검색 순위에서 HTTP보다 HTTPS를 사용하는 웹사이트를 우선 순위에 둡니다. 즉, HTTPS를 사용하는 웹사이트는 검색 결과에서 더 높은 위치에 표시될 가능성이 더 높으며 잠재적으로 가시성과 트래픽이 증가할 수 있습니다.
+4. 브라우저 지원: Chrome, Firefox, Safari 및 Edge를 포함한 대부분의 최신 웹 브라우저는 위치 정보, 카메라/마이크 액세스 및 푸시 알림과 같은 특정 기능에 대해 HTTPS 사용을 강력히 권장하거나 요구합니다. HTTP를 사용하는 웹사이트는 이러한 기능에 액세스할 때 제한 또는 제약이 발생할 수 있습니다.
+5. 산업 표준 및 규정 준수: HTTPS는 신용 카드 정보를 처리하기 위한 PCI DSS(Payment Card Industry Data Security Standard) 및 개인 정보 보호를 위한 GDPR(General Data Protection Regulation)과 같은 산업 표준 및 규정에서 요구하거나 권장하는 경우가 많습니다. 유럽 ​​연합의 사용자 데이터.
+
+전반적으로 HTTPS는 향상된 보안, 인증, 신뢰, 검색 엔진 순위, 브라우저 지원 및 업계 표준 준수를 제공하므로 인터넷을 통해 전송되는 데이터의 기밀성, 무결성 및 신뢰성을 보장하기 위해 최신 웹 브라우징에 권장되는 선택입니다.
+```
   * HTTPS와 TLS는 어떤 식으로 동작하나요? HTTPS는 어떤 역사를 가지고 있나요?
+  ```
+  HTTPS(Hypertext Transfer Protocol Secure)는 인터넷을 통한 통신에 사용되는 HTTP(Hypertext Transfer Protocol)의 보안 버전입니다. HTTPS는 암호화를 사용하여 웹 브라우저와 웹 서버 간에 전송되는 데이터를 보호하여 기밀성, 무결성 및 신뢰성을 보장합니다. TLS(전송 계층 보안)는 HTTPS가 보안 통신에 사용하는 암호화 프로토콜입니다.
+  
+  HTTPS 및 TLS 작동 방식은 다음과 같습니다.
+  1. 핸드셰이크: 사용자가 HTTPS로 웹 사이트에 액세스하려고 하면 웹 서버는 공개 키가 포함된 디지털 인증서를 웹 브라우저에 제공합니다. 그런 다음 웹 브라우저는 인증서의 진위를 확인하고 웹 서버와의 보안 연결을 설정합니다.
+  2. 암호화: 보안 연결이 설정되면 웹 브라우저와 웹 서버 간에 교환되는 데이터는 대칭 또는 비대칭 암호화 알고리즘을 사용하여 암호화됩니다. 이렇게 하면 데이터가 인터넷을 통해 이동할 때 데이터에 대한 무단 액세스를 방지할 수 있습니다.
+  3. 데이터 전송: 암호화된 데이터는 웹 브라우저와 웹 서버 간에 전송되어 기밀성과 무결성을 보장합니다. 웹 브라우저는 웹 서버로부터 받은 데이터를 복호화하고, 웹 서버는 웹 브라우저로 보낸 데이터를 암호화합니다.
+  4. 인증: TLS는 또한 인증을 제공하여 웹 서버가 사기꾼이 아닌 합법적인지 확인합니다. 이는 웹 서버의 ID를 확인하는 신뢰할 수 있는 인증 기관(CA)에서 발행한 디지털 인증서를 통해 이루어집니다.
+  HTTPS의 역사는 Netscape Communications Corporation이 온라인 통신을 보호하는 방법으로 HTTPS를 도입한 1990년대 중반으로 거슬러 올라갑니다. HTTPS의 원래 버전은 암호화 및 인증을 위해 SSL(Secure Sockets Layer)이라는 프로토콜을 사용했습니다. 나중에 SSL은 인터넷을 통한 보안 통신을 위한 현재 산업 표준인 TLS로 대체되었습니다.
+  수년 동안 HTTPS는 웹 통신 보안을 위한 사실상의 표준이 되었으며 로그인 자격 증명, 신용 카드 세부 정보 및 개인 데이터와 같은 중요한 정보를 보호하는 데 널리 사용됩니다. 많은 웹사이트, 특히 민감한 정보를 다루는 웹사이트는 인터넷을 통해 전송되는 데이터의 기밀성, 무결성 및 신뢰성을 보장하기 위해 HTTPS 사용을 요구하거나 권장합니다.
+  ```
   * HTTPS의 서비스 과정에서 인증서는 어떤 역할을 할까요? 인증서는 어떤 체계로 되어 있을까요?
-
+  ```
+  인증서는 HTTPS 서비스 프로세스에서 중요한 역할을 합니다. 웹 서버의 ID를 인증하고 웹 브라우저와 웹 서버 간의 보안 통신을 설정하는 데 사용됩니다. 인증서 시스템에는 몇 가지 주요 구성 요소가 포함됩니다.
+  
+  1. 인증 기관(CA): 인증 기관은 디지털 인증서를 발급하는 신뢰할 수 있는 엔터티입니다. CA는 웹 서버 ID의 진위를 확인하고 적법성을 증명하는 디지털 인증서를 발행할 책임이 있습니다.
+  2. 디지털 인증서: 디지털 인증서는 도메인 이름, 공개 키 및 기타 관련 세부 정보와 같은 웹 서버의 ID에 대한 정보가 포함된 디지털 문서입니다. 인증 기관에서 발행하고 무결성을 보장하기 위해 디지털 서명됩니다.
+  3. 공개 키: 공개 키는 HTTPS에서 사용되는 비대칭 암호화 알고리즘의 일부입니다. 디지털 인증서에 포함되어 있으며 웹 브라우저에서 웹 서버로 전송되는 데이터를 암호화하는 데 사용됩니다.
+  4. 개인 키: 개인 키는 공개 키에 대응하며 웹 서버에 의해 비밀로 유지됩니다. 해당 공개 키로 암호화된 데이터를 복호화하는 데 사용됩니다. 개인 키를 소유한 웹 서버만이 데이터를 해독할 수 있으므로 기밀성이 보장됩니다.
+  5. 핸드셰이크: TLS 핸드셰이크 프로세스 중에 웹 서버는 웹 브라우저에 디지털 인증서를 제공합니다. 그런 다음 웹 브라우저는 신뢰할 수 있는 루트 인증서로 웹 브라우저에 미리 설치된 CA의 공개 키를 사용하여 인증서의 진위를 확인합니다. 인증서가 유효한 경우 웹 브라우저와 웹 서버는 암호화된 통신을 위한 보안 연결을 설정합니다.
+ 
+  HTTPS의 인증서 시스템은 웹 브라우저와 웹 서버 간에 신뢰와 인증을 설정하는 데 도움이 됩니다. 웹 서버가 합법적이고 웹 서버와 웹 브라우저 간에 전송되는 데이터가 암호화되고 안전하도록 보장합니다. 신뢰할 수 있는 인증 기관에서 발급한 디지털 인증서는 HTTPS의 보안 통신 프로세스에서 중요한 역할을 합니다.
+  ```
 ## Quest
 * 메모장의 서버와 클라이언트에 대해, 로컬에서 발행한 인증서를 통해 HTTPS 서비스를 해 보세요.
 

From bc74d7b7dc3778fc7d3a1e25bf0a48c452843600 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:43:27 +0900
Subject: [PATCH 23/29] Quest 13 CheckList Clear

---
 Quest13/README.md | 89 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

diff --git a/Quest13/README.md b/Quest13/README.md
index 4f6fe2447..ec076844b 100644
--- a/Quest13/README.md
+++ b/Quest13/README.md
@@ -18,13 +18,102 @@
 
 ## Checklist
 * GraphQL API는 무엇인가요? REST의 어떤 단점을 보완해 주나요?
+```
+GraphQL API는 유연하고 효율적인 방식으로 서버와 상호 작용하고 데이터를 검색하기 위해 GraphQL 쿼리 언어를 사용하는 애플리케이션 프로그래밍 인터페이스(API)입니다. GraphQL은 Facebook에서 개발했으며 유연성, 효율성 및 사용 용이성으로 인해 인기를 얻었습니다.
+
+엔드포인트와 응답의 고정된 구조를 따르는 REST(Representational State Transfer) API와 달리 GraphQL은 클라이언트가 필요한 데이터만 요청하고 응답의 형태를 지정할 수 있도록 합니다. 따라서 GraphQL API는 REST API에 비해 여러 면에서 더 유연하고 효율적입니다.
+
+1. Over-fetching: REST API는 종종 클라이언트가 필요로 하는 것보다 더 많은 데이터를 반환하여 데이터를 과도하게 가져옵니다. 클라이언트는 GraphQL을 사용하여 필요한 정확한 데이터를 지정하여 네트워크를 통해 전송되는 불필요한 데이터의 양을 줄일 수 있습니다.
+2. Under-fetching: REST API는 관련 데이터를 가져오기 위해 서로 다른 엔드포인트에 대한 여러 요청을 요구할 수 있으므로 데이터의 under-fetching이 발생할 수 있습니다. GraphQL은 클라이언트가 단일 쿼리에서 모든 관련 데이터를 요청할 수 있도록 하여 요청 수를 줄이고 성능을 향상시킵니다.
+3. 버전 관리: REST API는 API의 변경 사항을 처리하기 위해 버전 관리가 필요할 수 있으며, 이로 인해 동일한 엔드포인트의 여러 버전이 생성될 수 있습니다. GraphQL은 클라이언트가 필요한 데이터만 요청할 수 있도록 하여 버전 관리를 피하고 서버는 기존 클라이언트를 손상시키지 않고 필드를 추가하거나 변경할 수 있습니다.
+4. 클라이언트 기반 쿼리: GraphQL을 사용하면 클라이언트가 데이터 검색 프로세스를 구동하여 수신하는 데이터에 대해 더 많은 유연성과 제어를 제공할 수 있습니다. 클라이언트는 단일 쿼리에서 필요한 데이터만 요청할 수 있으므로 오버페칭 및 언더페칭 문제가 줄어듭니다.
+
+그러나 GraphQL은 리졸버 기능으로 인해 서버 측에서 복잡성이 증가하고 제대로 구현되지 않을 경우 잠재적인 보안 위험이 있으며 GraphQL에 익숙하지 않은 개발자의 경우 REST에 비해 학습 곡선이 가파르다는 단점도 있습니다. . 또한 GraphQL은 모든 사용 사례에 적합하지 않을 수 있으며 REST는 프로젝트의 요구 사항에 따라 특정 시나리오에서 여전히 실행 가능한 옵션일 수 있습니다.
+```
 * GraphQL 스키마는 어떤 역할을 하며 어떤 식으로 정의되나요?
+```
+GraphQL 스키마는 GraphQL API에서 쿼리, 변경 또는 구독할 수 있는 데이터의 구조를 정의합니다. 클라이언트와 서버 간의 계약 역할을 하여 요청할 수 있는 데이터 유형과 지원되는 작업을 지정합니다.
+
+GraphQL 스키마는 API의 유형, 필드 및 관계를 설명하기 위해 사람이 읽을 수 있는 구문인 GraphQL 스키마 정의 언어(SDL)를 사용하여 정의됩니다. GraphQL 스키마의 주요 구성 요소는 다음과 같습니다.
+
+1. 유형: 유형은 GraphQL API에서 쿼리하거나 변경할 수 있는 데이터의 모양을 정의합니다. 개체, 스칼라 값(예: 문자열 또는 숫자), 열거형(미리 정의된 값 집합) 또는 다른 형식으로 구성된 사용자 지정 형식을 나타낼 수 있습니다.
+2. 필드: 필드는 유형 내에서 요청하거나 변경할 수 있는 개별 데이터 조각을 정의합니다. 이름과 유형이 있으며 클라이언트가 필터링, 정렬 또는 기타 작업을 위해 값을 전달할 수 있도록 하는 인수도 있을 수 있습니다.
+3. 쿼리: 쿼리는 클라이언트가 API에서 수행할 수 있는 읽기 작업을 정의합니다. 요청할 수 있는 데이터 유형과 응답 형태를 지정합니다. 쿼리는 REST의 HTTP GET 요청과 유사하지만 필요한 데이터만 요청할 수 있는 유연성이 있습니다.
+4. 돌연변이: 돌연변이는 클라이언트가 API에서 수행할 수 있는 쓰기 작업을 정의합니다. 이를 통해 클라이언트는 GraphQL API에서 데이터를 수정하거나 생성할 수 있습니다. 변형은 REST의 HTTP POST, PUT, DELETE 또는 PATCH 요청과 유사합니다.
+5. 구독: 구독은 클라이언트가 구독하고 데이터가 변경될 때 업데이트를 받을 수 있는 실시간 데이터 스트림을 정의합니다. 구독을 통해 클라이언트는 변경 사항에 대해 지속적으로 서버를 폴링하지 않고도 실시간 업데이트를 받을 수 있습니다.
+
+GraphQL 스키마는 일반적으로 GraphQL 스키마 언어를 사용하여 서버 측에서 정의되며 API에서 사용 가능한 데이터 및 작업을 정의하는 계약 역할을 합니다. 그런 다음 클라이언트는 이 스키마를 사용하여 API와 상호 작용하고 유연하고 효율적인 방식으로 데이터를 요청하거나 수정할 수 있습니다.
+```
 * GraphQL 리졸버는 어떤 역할을 하며 어떤 식으로 정의되나요?
+```
+GraphQL 해석기는 GraphQL API의 필드 값을 해석하는 기능입니다. 클라이언트가 쿼리 또는 변형 요청을 할 때 특정 필드에 대한 데이터를 검색하거나 계산하는 방법을 결정하는 데 사용됩니다. 리졸버는 GraphQL API의 서버측 구현에서 필수적인 부분입니다.
+
+리졸버는 서버 측의 함수로 정의되며 GraphQL 스키마의 특정 필드와 연결됩니다. 클라이언트가 쿼리 또는 변형 요청을 하면 GraphQL 런타임은 적절한 해석기를 실행하여 요청된 필드의 값을 검색하거나 계산합니다.
+
+리졸버는 일반적으로 JavaScript, Python, Ruby 또는 기타 언어와 같이 GraphQL 서버에서 지원하는 프로그래밍 언어를 사용하여 정의됩니다. 정확한 구문 및 구현 세부 정보는 사용 중인 GraphQL 서버 라이브러리 또는 프레임워크에 따라 다를 수 있습니다.
+
+확인자는 데이터베이스에서 데이터 가져오기, 외부 API 호출, 계산 수행 또는 하드코딩된 값 반환과 같은 다양한 작업을 수행할 수 있습니다. Resolver는 네트워크 요청 또는 데이터베이스 쿼리와 같은 I/O 관련 작업을 처리하기 위해 비동기식일 수도 있습니다.
+
+리졸버는 부모 개체(확인할 필드를 포함하는 개체), 쿼리 또는 변형에 전달된 인수, 컨텍스트(모두가 액세스할 수 있는 데이터를 저장하는 데 사용할 수 있는 공유 개체)를 포함하여 몇 가지 중요한 정보에 액세스할 수 있습니다. 확인자, 사용자의 인증 및 권한 부여 정보.
+
+확인자는 추상 GraphQL 쿼리 및 변형을 서버에서 구체적인 데이터 검색 또는 수정 작업으로 변환하는 데 중요한 역할을 합니다. GraphQL API의 필드 값을 검색하거나 계산하기 위한 로직을 제공하며 GraphQL API를 구축하고 구현하는 데 있어 기본이 되는 부분입니다.
+```
   * GraphQL 리졸버의 성능 향상을 위한 DataLoader는 무엇이고 어떻게 쓰나요?
+  ```
+  DataLoader는 데이터 검색 작업을 일괄 처리 및 캐싱하여 GraphQL 리졸버의 성능을 개선하는 데 도움이 되는 GraphQL 에코시스템의 인기 있는 유틸리티 라이브러리입니다. 데이터베이스, API 또는 기타 원격 서비스와 같은 외부 데이터 소스에서 데이터를 효율적으로 가져오기 위해 GraphQL 서버에서 일반적으로 사용됩니다.
+  
+  DataLoader의 주요 목적은 GraphQL 쿼리로 인해 여러 개별 데이터 검색 작업이 발생하여 중복되고 비효율적인 데이터베이스 또는 API 쿼리가 발생할 때 발생하는 "N+1" 문제를 해결하는 것입니다. DataLoader는 여러 데이터 검색 작업을 단일 요청으로 일괄 처리하여 왕복 횟수를 줄이고 전반적인 성능을 개선하여 이 문제를 해결합니다.
+  DataLoader는 확인자가 만든 데이터 검색 요청을 가로채서 배치로 수집하는 방식으로 작동합니다. 그런 다음 외부 데이터 소스에 대한 단일 요청에서 이러한 배치를 결합하고 실행하여 요청 수를 효과적으로 줄이고 데이터 검색을 최적화합니다. DataLoader는 또한 캐싱 기능을 제공하여 이전에 가져온 데이터를 재사용할 수 있도록 하고 중복 데이터 가져오기를 방지하여 성능을 더욱 향상시킵니다.
+  GraphQL 해석기에서 DataLoader를 사용하려면 일반적으로 다음 단계가 필요합니다.
+
+  1. DataLoader 가져오기 및 초기화: DataLoader는 일반적으로 별도의 라이브러리로 설치되며 리졸버 코드로 가져와야 합니다. 그런 다음 주어진 키 세트에 대한 데이터를 가져오는 방법을 지정하는 데이터 검색 기능으로 초기화됩니다.
+  2. 리졸버 함수에서 DataLoader 사용: 리졸버 함수 내에서 DataLoader를 사용하여 데이터 검색 작업을 일괄 처리하고 캐시할 수 있습니다. 데이터 원본에서 데이터를 직접 가져오는 대신 리졸버는 요청을 수집하고 일괄 처리할 원하는 키를 사용하여 DataLoader 인스턴스를 호출할 수 있습니다. 확인자는 요청된 데이터로 확인되는 Promise를 반환할 수 있습니다.
+  3. DataLoader에서 데이터 검색: DataLoader는 요청된 데이터로 확인되는 Promise를 반환합니다. 해석기는 해당 필드에 대해 해석된 값으로 이 데이터를 GraphQL 클라이언트에 반환할 수 있습니다.
+  GraphQL 리졸버에서 DataLoader를 사용하면 중복되고 비효율적인 데이터 검색 작업을 최소화할 수 있으므로 성능이 향상되고 외부 데이터 소스에 대한 부하가 감소합니다. DataLoader는 GraphQL API에서 데이터 검색을 최적화하기 위한 강력한 도구이며 많은 GraphQL 서버 구현에서 널리 사용됩니다.
+  ```
 * 클라이언트 상에서 GraphQL 요청을 보내려면 어떻게 해야 할까요?
+```
+클라이언트에서 GraphQL 요청을 보내려면 일반적으로 다음 단계를 따라야 합니다.
+
+1. HTTP 라이브러리 선택: 클라이언트 측 애플리케이션에서 HTTP 요청을 할 수 있는 HTTP 라이브러리 또는 클라이언트를 선택해야 합니다. 인기 있는 옵션으로는 Axios, Fetch 또는 Apollo Client 또는 Relay와 같은 GraphQL 전용 클라이언트가 있습니다.
+2. GraphQL 쿼리 구성: 서버로 보내려는 GraphQL 쿼리 또는 변형을 작성합니다. 여기에는 작업 유형(쿼리, 변형 또는 구독), 요청하려는 필드 및 전달해야 하는 인수 또는 변수를 지정하는 작업이 포함됩니다.
+3. 요청 형식 지정: GraphQL 요청은 일반적으로 서버의 GraphQL 엔드포인트에 대한 POST 요청으로 전송됩니다. GraphQL 쿼리 또는 변형을 요청 본문으로 사용하여 요청 형식을 POST 요청으로 지정해야 합니다. 값이 "application/json"인 "Content-Type" 헤더와 같은 적절한 헤더를 설정해야 할 수도 있습니다.
+4. 요청 보내기: 선택한 HTTP 라이브러리 또는 클라이언트를 사용하여 GraphQL 요청을 서버로 보냅니다. 여기에는 일반적으로 GraphQL 서버에 대한 끝점 URL, 형식화된 요청 본문 및 필요할 수 있는 모든 헤더 또는 인증 정보를 제공하는 것이 포함됩니다.
+5. 응답 처리: 요청이 전송되면 서버는 요청된 데이터 또는 오류 응답으로 응답합니다. 일반적으로 JSON 응답을 구문 분석하고 관련 데이터 또는 오류 정보를 추출하여 클라이언트 측 코드에서 응답을 처리해야 합니다.
+6. UI 업데이트: 응답을 받은 후 검색된 데이터로 클라이언트 측 UI 또는 애플리케이션 상태를 업데이트하거나 발생한 오류를 처리할 수 있습니다. 여기에는 구성 요소 업데이트, 사용자에게 데이터 표시 또는 검색된 데이터를 기반으로 추가 작업 트리거가 포함될 수 있습니다.
+
+정확한 구현 세부 정보 및 구문은 사용 중인 HTTP 라이브러리 또는 클라이언트와 클라이언트 측 애플리케이션의 프로그래밍 언어 또는 프레임워크에 따라 다를 수 있습니다. 클라이언트에서 GraphQL 요청을 올바르게 사용하려면 선택한 라이브러리 또는 클라이언트에서 제공하는 문서 및 예제를 참조하는 것이 중요합니다.
+```
   * Apollo 프레임워크(서버/클라이언트)의 장점은 무엇일까요?
+  ```
+  Apollo 서버(GraphQL 서버 구축용)와 Apollo 클라이언트(클라이언트 측에서 GraphQL API 사용용)를 모두 포함하는 Apollo 프레임워크는 개발자에게 다음과 같은 몇 가지 이점을 제공합니다.
+  
+  1. 포괄적인 도구: Apollo는 GraphQL 애플리케이션을 개발하고 디버깅하기 위한 다양한 도구 세트를 제공합니다. 여기에는 GraphQL 내부 검사, 대화형 쿼리 테스트를 위한 GraphQL Playground, 클라이언트 측 캐싱, 오류 처리 및 성능 모니터링에 대한 기본 제공 지원과 같은 기능이 포함됩니다.
+  2. 유연하고 확장 가능: Apollo를 사용하면 개발자가 유연하고 확장 가능한 방식으로 GraphQL API 및 클라이언트를 구축할 수 있습니다. 맞춤형 리졸버, 미들웨어 및 플러그인을 지원하여 GraphQL API 및 클라이언트의 동작을 세밀하게 제어할 수 있습니다.
+  3. 확장성: Apollo는 확장 가능하도록 설계되어 다양한 크기와 복잡성의 애플리케이션 구축에 적합합니다. Apollo 서버는 성능을 최적화하기 위해 일괄 처리 및 캐싱과 같은 기능을 지원하고, Apollo 클라이언트는 고급 캐싱 및 상태 관리 옵션을 제공하여 클라이언트 측 성능을 향상시킵니다.
+  4. 강력한 커뮤니티 및 생태계: Apollo에는 대규모의 활발한 개발자 커뮤니티가 있습니다. 즉, 풍부한 리소스, 문서, 자습서 및 커뮤니티 기반 확장에 대한 액세스를 의미합니다. 또한 React, Angular 및 Vue와 같은 인기 있는 웹 프레임워크 및 라이브러리와 잘 통합되어 GraphQL을 기존 프로젝트에 쉽게 통합할 수 있습니다.
+  5. 교차 플랫폼 호환성: Apollo는 JavaScript, TypeScript 및 Kotlin과 같은 다양한 프로그래밍 언어와 함께 사용할 수 있는 교차 플랫폼 프레임워크로, 개발자가 다양한 서버 및 클라이언트 플랫폼에서 GraphQL 애플리케이션을 구축할 수 있도록 합니다.
+  6. GraphQL 우선 접근 방식: Apollo는 "GraphQL 우선" 접근 방식을 취합니다. 즉, GraphQL 작업에 특별히 최적화된 전용 도구와 기능을 제공합니다. 여기에는 개발 프로세스를 간소화하고 개발자 생산성을 향상시키는 자동 스키마 생성, 유형 검사 및 코드 생성과 같은 기능이 포함됩니다.
+  7. 클라이언트측 캐싱 및 상태 관리: Apollo 클라이언트는 고급 클라이언트측 캐싱 및 상태 관리 기능을 제공하여 개발자가 데이터 가져오기를 최적화하고 불필요한 네트워크 요청을 최소화할 수 있도록 합니다. 이를 통해 클라이언트 측 애플리케이션의 성능과 응답성을 크게 향상시킬 수 있습니다.
+  
+  전반적으로 Apollo 프레임워크는 포괄적인 도구, 확장성, 플랫폼 간 호환성 및 강력한 커뮤니티 에코시스템을 통해 GraphQL API 및 클라이언트를 구축하기 위한 강력하고 유연한 도구 세트를 제공하므로 최신 GraphQL 애플리케이션을 구축하기 위해 개발자들 사이에서 인기 있는 선택입니다.
+  ```
   * Apollo Client를 쓰지 않고 Vanilla JavaScript로 GraphQL 요청을 보내려면 어떻게 해야 할까요?
+  ```
+  Apollo 클라이언트를 사용하지 않고 바닐라 JavaScript에서 GraphQL 요청을 하려면 내장 fetch() 함수 또는 다른 HTTP 클라이언트 라이브러리를 사용하여 적절한 헤더 및 페이로드와 함께 POST 요청을 GraphQL 끝점으로 보낼 수 있습니다.
+  ```
 * GraphQL 기반의 API를 만들 때 에러처리와 HTTP 상태코드 등은 어떻게 하는게 좋을까요?
+```
+GraphQL 기반 API를 생성할 때 오류 처리 및 HTTP 상태 코드는 일관되고 신중한 방식으로 접근해야 합니다. 다음은 몇 가지 일반적인 모범 사례입니다.
+
+1. GraphQL 오류 사용: GraphQL에는 응답 페이로드에 포함된 "오류"라는 자체 오류 처리 메커니즘이 내장되어 있습니다. GraphQL 쿼리 또는 변형을 실행하는 동안 오류가 발생하면 응답 페이로드의 'errors' 필드에 오류 개체를 포함할 수 있습니다. 오류 메시지, 오류 코드 및 필드 경로와 같은 오류에 대한 세부 정보를 제공합니다. 오류가 발생했습니다. 이를 통해 클라이언트는 구조화된 오류 정보를 수신하고 통합된 방식으로 오류를 처리할 수 있습니다.
+2. 적절한 HTTP 상태 코드 사용: GraphQL은 자체 오류 처리 메커니즘을 사용하지만 적절한 HTTP 상태 코드를 사용하여 요청의 전체 상태를 나타내는 것도 중요합니다. 성공적인 GraphQL 작업의 경우 HTTP 200 OK 상태 코드를 사용할 수 있으며, 오류의 경우 오류의 특성에 따라 400 Bad Request, 401 Unauthorized, 403 Forbidden 또는 500 Internal Server Error와 같은 다른 적절한 HTTP 상태 코드를 사용할 수 있습니다. 오류. 이를 통해 클라이언트는 GraphQL 오류 외에도 HTTP 상태 코드를 기반으로 요청의 전체 결과를 해석할 수 있습니다.
+3. 오류 메시지에 일관성 있고 구체적: GraphQL 오류 또는 HTTP 응답에 오류 메시지를 포함할 때 오류 메시지의 형식과 구조가 일관되어야 합니다. 클라이언트가 오류의 특성을 이해하고 적절한 조치를 취할 수 있도록 충분한 정보를 제공하는 명확하고 의미 있는 오류 메시지를 사용하십시오. 잠재적인 보안 위험을 방지하기 위해 오류 메시지에 민감한 정보를 노출하지 마십시오.
+4. 필드 수준 오류 고려: GraphQL은 필드 수준 오류를 허용합니다. 즉, 작업 수준이 아닌 개별 필드 수준에서 오류를 지정할 수 있습니다. 이를 통해 보다 세분화된 오류 정보를 제공하고 클라이언트가 특정 필드 수준에서 오류를 식별하고 처리하는 데 도움을 줄 수 있습니다. 그러나 필드 수준 오류에 민감한 정보를 노출하지 않도록 주의하십시오.
+5. 테스트 오류 시나리오: 잘못된 쿼리 또는 변형, 인증 실패, 권한 부여 실패 및 기타 잠재적 오류 시나리오를 포함한 다양한 오류 시나리오로 GraphQL API를 철저하게 테스트합니다. 오류 메시지의 형식, HTTP 상태 코드 및 API의 전반적인 동작을 포함하여 API가 이러한 시나리오에 어떻게 응답하는지 테스트하십시오.
+
+이러한 모범 사례를 따르면 강력한 오류 처리 및 적절한 HTTP 상태 코드를 사용하여 GraphQL 기반 API를 생성할 수 있습니다. 이를 통해 클라이언트는 효과적으로 오류를 처리하고 요청의 전체 상태를 해석할 수 있습니다.
+```
 
 ## Quest
 * 메모장의 서버와 클라이언트 부분을 GraphQL API로 수정해 보세요.

From b5aeeca1227965e8965b7460cede3c28831adea7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:44:08 +0900
Subject: [PATCH 24/29] Quest 14 CheckList Clear

---
 Quest14/README.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/Quest14/README.md b/Quest14/README.md
index 835469b61..a3297775f 100644
--- a/Quest14/README.md
+++ b/Quest14/README.md
@@ -14,12 +14,86 @@
 
 ## Checklist
 * 코드를 린팅하는 것의 장점은 무엇일까요?
+```
+1. 오류 조기 감지: Linting은 개발 프로세스 초기에 코드의 잠재적인 문제와 오류를 식별하는 데 도움이 됩니다. 코드가 실행되기 전에 코딩 실수, 구문 오류 및 기타 문제를 포착하여 코드에 버그나 예기치 않은 동작이 발생할 가능성을 줄일 수 있습니다.
+2. 일관된 코드 스타일: Linting은 코드가 확립된 코딩 규칙 및 모범 사례를 준수하도록 보장하여 코드베이스 전체에서 일관된 코딩 스타일을 촉진합니다. 모든 사람이 공통 코딩 스타일을 따르기 때문에 팀 구성원 간의 코드 가독성, 유지 관리 및 공동 작업을 개선하는 데 도움이 될 수 있습니다.
+3. 코드 품질 개선: Linting 도구는 일반적인 프로그래밍 실수, 안티 패턴 및 잠재적인 성능 문제에 대해 코드를 분석할 수 있습니다. 이러한 문제를 식별하고 수정함으로써 linting은 코드베이스의 전반적인 품질을 개선하여 보다 강력하고 유지 관리 가능한 코드를 만드는 데 도움이 됩니다.
+4. 향상된 개발자 생산성: Linting은 개발자가 문제를 더 빨리 식별하고 수정하여 디버깅 및 문제 해결에 소요되는 시간을 줄이는 데 도움이 될 수 있습니다. 이는 수동 코드 검토 또는 버그 수정에 시간을 소비하는 대신 고품질 코드 작성에 집중할 수 있으므로 개발자 생산성 및 효율성 향상으로 이어질 수 있습니다.
+5. 보안 취약성 방지: Linting은 안전하지 않은 코드 관행, 주입 공격 또는 기타 보안 위험과 같은 잠재적인 보안 취약성을 감지하는 데 도움이 될 수 있습니다. Linting은 개발 프로세스 초기에 이러한 취약점을 해결함으로써 코드베이스의 보안을 개선하고 보안 위반 위험을 줄이는 데 도움이 될 수 있습니다.
+6. 개발 워크플로와의 통합: Linting은 빌드 시스템, CI(지속적인 통합) 파이프라인 및 코드 편집기를 통해 개발 워크플로에 쉽게 통합될 수 있습니다. 이를 통해 자동화된 코드 분석 및 피드백이 가능하므로 개발자가 코딩 표준을 준수하고 코드를 작성할 때 문제를 포착하기가 더 쉬워집니다.
+
+전반적으로 Linting 코드는 오류의 조기 감지, 일관된 코드 스타일, 향상된 코드 품질, 향상된 개발자 생산성, 보안 취약성 방지, 개발 워크플로와의 원활한 통합을 포함하여 다양한 이점을 제공하여 보다 강력하고 유지 관리 가능하며 안전한 코드를 제공합니다.
+```
   * 린트 규칙은 어떻게 설정하는 것이 좋을까요? 너무 빡빡한 규칙과 너무 헐거운 규칙 사이에서 어떻게 밸런스를 잡아야 할까요?
+  ```
+  Lint 규칙을 설정하려면 너무 엄격한 규칙과 너무 느슨한 규칙 사이의 균형을 찾아야 합니다. 다음은 균형을 유지하기 위한 몇 가지 일반적인 팁입니다.
+  
+  1. 확립된 코딩 표준을 따르십시오: 린트 규칙을 설정하기 위한 출발점으로 커뮤니티 또는 조직 내에서 널리 인정되는 확립된 코딩 표준 또는 스타일 가이드를 사용하십시오. 이러한 표준은 일반적으로 코드 형식, 명명 규칙 및 모범 사례에 대한 권장 사항을 제공합니다.
+  2. 프로젝트 요구 사항 고려: Lint 규칙을 설정할 때 복잡성, 크기 및 팀 구성과 같은 프로젝트의 특정 요구 사항을 고려하십시오. 소규모 팀이 있는 소규모 프로젝트에는 덜 엄격한 규칙이 필요할 수 있는 반면, 여러 팀이 있는 대규모 프로젝트에는 일관성과 유지 관리성을 보장하기 위해 더 엄격한 규칙이 필요할 수 있습니다.
+  3. 개발팀 참여: Lint 규칙을 설정할 때 의사 결정 프로세스에 개발팀을 참여시킵니다. 팀원들로부터 피드백을 수집하고 프로젝트에 가장 적합한 규칙에 대한 의견을 고려하십시오. 이를 통해 팀 구성원 간의 소유권과 공동 작업을 촉진하고 규칙이 실용적이고 현실적임을 확인할 수 있습니다.
+  4. 중요한 문제의 우선 순위 지정: 구문 오류, 잠재적인 보안 취약성 또는 일반적인 코딩 실수와 같은 중요한 문제를 포착하는 규칙에 집중합니다. 이러한 규칙은 심각한 문제가 틈 사이로 빠져나가는 것을 방지하기 위해 더 엄격해야 합니다.
+  5. 일관성과 유연성 사이의 균형: 코딩 스타일과 모범 사례의 일관성을 목표로 하지만 다른 코딩 선호도와 관행을 수용할 수 있는 유연성도 어느 정도 허용합니다. 일관성을 유지하는 것과 코딩 스타일 또는 관행의 합리적인 변형을 허용하는 것 사이에서 균형을 이루는 규칙을 위해 노력하십시오.
+  6. 점진적 구현: 적당히 엄격한 일련의 Lint 규칙으로 시작하여 피드백과 실제 경험을 기반으로 시간이 지남에 따라 점진적으로 규칙을 강화합니다. 처음부터 지나치게 엄격한 규칙을 설정하지 마십시오. 높은 오탐지, 팀원 간의 불만, 생산성 저하를 초래할 수 있습니다.
+  7. 정기 검토 및 반복: 피드백, 코드 검토 및 진화하는 프로젝트 요구 사항을 기반으로 lint 규칙을 정기적으로 검토하고 반복합니다. 프로젝트 및 개발 팀의 변화하는 요구 사항에 맞게 규칙을 지속적으로 개선합니다.
+  
+  너무 엄격한 린트 규칙과 너무 느슨한 린트 규칙 사이에서 올바른 균형을 찾는 것은 어려울 수 있지만 코드 품질과 일관성을 보장하는 동시에 개발 프로세스에서 유연성과 실용성을 허용하는 균형을 맞추는 것이 중요합니다. 팀원 간의 정기적인 커뮤니케이션, 공동 작업 및 피드백은 특정 프로젝트에 적합한 균형을 찾는 데 중요합니다.
+  ```
 * 타입스크립트는 어떤 언어인가요?
+```
+TypeScript는 JavaScript의 상위 집합인 프로그래밍 언어입니다. 즉, 정적 타이핑, 인터페이스, 데코레이터 등과 같은 추가 기능으로 JavaScript를 확장하고 향상시킵니다. TypeScript 코드는 결국 JavaScript로 트랜스파일되며 웹 브라우저, Node.js 및 기타 JavaScript 런타임 환경을 포함한 모든 JavaScript 환경에서 실행될 수 있습니다. TypeScript는 기존 JavaScript 코드와 호환되도록 설계되어 프런트엔드 및 백엔드 개발 모두에서 확장 가능하고 유지 관리 가능한 애플리케이션을 구축하는 데 널리 사용됩니다.
+```
   * 타입스크립트를 사용했을 때 얻을 수 있는 장점은 무엇인가요?
+  ```
+  TypeScript는 개발자에게 다음과 같은 몇 가지 이점을 제공하는 강력한 유형의 JavaScript 상위 집합입니다.
+  
+  1. 정적 타이핑: TypeScript는 정적 타이핑을 시행하여 개발자가 런타임이 아닌 컴파일 타임에 유형 관련 오류를 포착할 수 있도록 합니다. 이를 통해 개발 프로세스 초기에 잠재적인 버그를 식별하고 수정하여 보다 강력하고 안정적인 코드를 생성할 수 있습니다.
+  2. 향상된 툴링: TypeScript는 자동 완성, 코드 탐색, 리팩토링을 비롯한 풍부한 툴링을 제공하여 생산성을 높이고 개발 시간을 단축합니다. TypeScript의 유형 주석은 문서의 역할도 하므로 코드를 더 쉽게 이해하고 유지 관리할 수 있습니다.
+  3. 확장성 향상: TypeScript는 개발자가 확장 가능하고 유지 관리 가능한 코드를 작성할 수 있도록 하는 인터페이스, 제네릭 및 데코레이터와 같은 기능을 지원합니다. 이러한 기능은 코드 재사용성, 코드 구성 및 확장성을 촉진하여 버그가 적은 복잡한 애플리케이션을 보다 쉽게 ​​구축할 수 있도록 합니다.
+  4. 생태계 호환성: TypeScript는 JavaScript의 상위 집합입니다. 즉, 기존 JavaScript 코드를 TypeScript 프로젝트에 쉽게 통합할 수 있습니다. TypeScript는 또한 표준 JavaScript로 컴파일할 수 있으므로 개발자는 이전 브라우저 및 환경과의 하위 호환성을 보장하면서 최신 JavaScript 기능을 활용할 수 있습니다.
+  5. 강력한 커뮤니티 및 도구 지원: TypeScript에는 크고 활발한 개발자 커뮤니티가 있으므로 학습, 문제 해결 및 지원에 사용할 수 있는 리소스가 풍부합니다. 또한 TypeScript는 Visual Studio Code, React, Angular 및 Node.js와 같은 널리 사용되는 개발 도구 및 프레임워크와 완벽하게 통합되어 최신 웹 개발을 위한 강력한 선택입니다.
+  6. 런타임 오류 감소: TypeScript의 정적 타이핑은 코드가 실행되기 전에 유형 불일치 오류와 같은 일반적인 프로그래밍 실수를 포착하여 런타임 오류 가능성을 줄이고 코드를 보다 강력하고 안정적으로 만듭니다.
+  7. 더 나은 협업: TypeScript의 유형 주석은 함수와 모듈 간의 명확한 계약을 제공하여 개발자가 프로젝트에서 더 쉽게 협업할 수 있도록 합니다. 이렇게 하면 팀 구성원 간의 의사 소통을 개선하고 코드 동작의 오해나 해석으로 인해 버그가 발생할 위험이 줄어듭니다.
+  
+  전반적으로 TypeScript는 향상된 유형 검사, 향상된 도구, 더 나은 확장성, 에코시스템 호환성, 강력한 커뮤니티 지원, 런타임 오류 감소, 향상된 공동 작업 등 수많은 이점을 제공하므로 최신 웹 개발 프로젝트에서 널리 사용됩니다.
+  ```
   * 타입스크립트를 사용하면서 타입이 없는 라이브러리나 프레임워크를 사용해야 할 경우에는 어떻게 해야 할까요?
+  ```
+  정적 유형 언어인 TypeScript를 유형 주석이 없거나 유형 정의가 없는 라이브러리 또는 프레임워크와 함께 사용할 때 몇 가지 문제가 발생할 수 있습니다. 그러나 이러한 시나리오를 처리하는 몇 가지 옵션이 있습니다.
+  
+  1. "모든" 유형 사용: TypeScript를 사용하면 특정 변수 또는 값에 대한 유형 검사를 기본적으로 비활성화하는 "모든" 유형을 사용할 수 있습니다. 이는 유형이 없는 라이브러리나 프레임워크로 작업할 때 유용할 수 있습니다. 코드의 특정 부분에 대한 유형 검사를 우회할 수 있기 때문입니다. 그러나 이 접근 방식은 정적 유형 지정의 이점을 상실하고 잠재적인 런타임 오류를 유발할 수 있으므로 주의해서 사용해야 합니다.
+  2. 사용자 정의 유형 정의 작성: TypeScript를 사용하면 공식적인 유형 지원이 부족한 라이브러리 또는 프레임워크에 대해 "타이핑"이라고도 하는 사용자 정의 유형 정의를 작성할 수 있습니다. 이러한 타이핑은 라이브러리 또는 프레임워크에 대한 유형 정보를 제공하는 데 사용할 수 있으므로 TypeScript가 유형 검사를 수행하고 더 나은 코드 완성 및 문서화를 제공할 수 있습니다. 타이핑은 TypeScript 또는 별도의 ".d.ts" 파일로 작성될 수 있으며 유형 없는 라이브러리 또는 프레임워크에 대한 유형 검사를 활성화하기 위해 프로젝트에 포함될 수 있습니다.
+  3. "as" 유형 어설션 사용: TypeScript를 사용하면 "as" 키워드를 사용하여 값의 유형을 명시적으로 지정하는 유형 어설션을 사용할 수 있습니다. 이는 라이브러리가 유형 정보를 제공하지 않더라도 TypeScript에 값의 예상 유형을 알려주는 방법을 제공하므로 유형 없는 라이브러리 또는 프레임워크로 작업할 때 유용할 수 있습니다. 그러나 유형 검사를 우회하고 어설션된 유형이 실제 값과 일치하지 않는 경우 런타임 오류가 발생할 수 있으므로 유형 어설션을 사용할 때는 주의해야 합니다.
+  4. 라이브러리 또는 프레임워크 래핑: 또 다른 접근 방식은 유형이 없는 라이브러리 또는 프레임워크 주위에 TypeScript 래퍼를 만드는 것입니다. 여기에는 유형이 없는 라이브러리 또는 프레임워크와 상호 작용하기 위해 유형이 지정된 인터페이스를 제공하는 TypeScript 모듈 또는 클래스를 만드는 작업이 포함됩니다. 이렇게 하면 TypeScript 래퍼에서 라이브러리 또는 프레임워크와의 상호 작용을 캡슐화하고 TypeScript 코드 내에서 형식 안전성을 보장할 수 있습니다.
+  5. 문서 및 커뮤니티 참조: 유형 없는 라이브러리 또는 프레임워크의 문서 및 커뮤니티 리소스를 확인하여 사용 가능한 권장 사례 또는 커뮤니티 기여 유형이 있는지 확인하는 것도 좋습니다. 경우에 따라 다른 개발자가 이미 타이핑을 생성했거나 TypeScript와 함께 라이브러리 또는 프레임워크를 효과적으로 사용하는 방법에 대한 지침을 제공했을 수 있습니다.
+  
+  TypeScript는 강력한 정적 타이핑을 제공하지만 유형이 없는 라이브러리 또는 프레임워크와 함께 사용하려면 추가적인 노력이 필요할 수 있습니다. 위에서 언급한 옵션을 신중하게 고려하고 프로젝트의 유형 안전성과 유연성 간의 장단점을 고려하여 특정 사용 사례에 가장 적합한 접근 방식을 선택하는 것이 중요합니다.
+  ```
   * any 타입을 남용하는 것은 왜 좋지 않을까요?
+  ```
+  TypeScript에서 "any" 유형을 과도하게 사용하면 다음과 같은 몇 가지 단점이 있을 수 있습니다.
+  
+  1. 유형 안전성 손실: TypeScript를 사용하는 주된 목적은 정적 타이핑을 제공하고 컴파일 타임에 유형 관련 오류를 포착하는 것입니다. 그러나 "any" 유형이 과도하게 사용되면 코드의 특정 부분에 대한 TypeScript의 유형 검사를 효과적으로 비활성화합니다. 이는 유형 관련 오류가 런타임에만 포착되어 적절한 유형 검사로 방지할 수 있는 잠재적인 런타임 오류 및 버그로 이어지기 때문에 정적 유형 지정의 이점을 잃을 수 있습니다.
+  2. 코드 문서 부족: TypeScript의 유형 주석은 코드에 대한 문서화 역할을 하여 이해하고 유지 관리하기가 더 쉽습니다. 그러나 "any"를 과도하게 사용하면 코드 작업이 필요한 다른 개발자에게 의도한 유형 정보를 전달하지 못합니다. 이로 인해 코드베이스를 이해하기가 더 어려워져 유지 관리가 줄어들고 버그가 발생하거나 실수할 가능성이 높아집니다.
+  3. 개발 도구의 이점 감소: TypeScript는 유형 정보에 의존하는 자동 완성, 코드 탐색 및 리팩터링과 같은 풍부한 개발 도구를 제공합니다. 그러나 "any"를 과도하게 사용하면 유용한 제안과 피드백을 제공하기 위해 정확한 유형 주석에 의존하기 때문에 이러한 도구의 효율성이 제한될 수 있습니다. 이로 인해 생산성과 개발 시간이 단축될 수 있습니다.
+  4. 런타임 오류 위험 증가: "any"가 과도하게 사용되면 TypeScript의 유형 검사를 우회하고 런타임에 유형 관련 오류가 발생할 수 있습니다. 이로 인해 진단 및 수정이 어려울 수 있는 예기치 않은 동작, 충돌 및 기타 런타임 오류가 발생하여 코드베이스의 안정성과 안정성이 저하될 수 있습니다.
+  5. 코드 유지 관리 가능성 및 리팩터링 가능성 감소: "any"를 과도하게 사용하면 잠재적인 문제를 식별하고 수정하는 데 도움이 되는 적절한 유형 정보가 부족하기 때문에 코드베이스를 유지 관리하고 리팩터링하기가 더 어려워질 수 있습니다. 이로 인해 기술 부채가 증가하고 코드 품질이 저하되며 향후 코드 변경 및 업데이트에 필요한 노력이 증가할 수 있습니다.
+  
+  "any" 유형은 유형 정보를 알 수 없거나 의도적으로 생략된 특정 시나리오에서 유용할 수 있지만, 이를 과도하게 사용하면 유형 안전성 손실, 코드 문서 감소, 도구 이점 감소, 런타임 오류 위험 증가 및 코드 유지 관리 가능성 감소로 이어질 수 있습니다. 리팩터링 TypeScript의 정적 타이핑의 이점을 최대한 활용하려면 "any"를 신중하게 사용하고 가능한 한 정확한 유형 주석을 제공하기 위해 노력하는 것이 중요합니다.
+  ```
 * 린트와 빌드 등의 과정을 개발 싸이클에서 편하게 수행하려면 어떻게 하는 것이 좋을까요?
+```
+개발 주기에서 linting 및 빌드 프로세스를 더 쉽게 만들기 위해 다음 모범 사례를 따를 수 있습니다.
+
+1. Linting 및 빌드 자동화: 작업 실행기 또는 빌드 시스템과 같은 자동화 도구를 설정하여 개발 워크플로의 일부로 린터 및 빌드 프로세스를 자동으로 실행합니다. 이를 통해 린팅 및 빌드가 일관되게 수행되고 잠재적인 문제가 개발 프로세스 초기에 발견됩니다. 이를 위한 인기 있는 도구는 Grunt, Gulp 및 npm 스크립트입니다.
+2. 엄격한 린팅 규칙 구성: 프로젝트의 코딩 표준 및 모범 사례에 부합하는 엄격한 규칙을 사용하도록 린터를 구성합니다. 이를 통해 잠재적인 문제를 파악하고 코딩 규칙을 적용하여 일관되고 유지 관리 가능한 코드를 생성할 수 있습니다. JavaScript/TypeScript용 ESLint 및 TypeScript용 TSLint와 같은 린터에는 프로젝트의 요구에 맞게 조정할 수 있는 광범위한 구성 옵션이 있습니다.
+3. LINT 및 빌드를 IDE/편집기와 통합: 개발에 사용되는 IDE 또는 코드 편집기와 린터 및 빌드 프로세스를 통합합니다. 많은 최신 IDE 및 편집기에는 린터를 실시간으로 실행할 수 있는 플러그인 또는 확장 기능이 있어 코딩 문제에 대한 즉각적인 피드백을 제공합니다. 이를 통해 개발자는 개발 중에 문제를 신속하게 파악하고 수정할 수 있으므로 수동 린팅 및 빌드의 필요성이 줄어듭니다.
+4. CI/CD 파이프라인에 Linting 및 빌드 포함: Linting 및 빌드를 CI/CD(지속적인 통합 및 지속적인 배포) 파이프라인의 일부로 포함합니다. 이렇게 하면 빌드 및 배포 프로세스 중에 linting 및 빌드가 일관되고 자동으로 수행됩니다. 이렇게 하면 문제를 조기에 파악하고 코드베이스에 새로운 문제가 발생하는 것을 방지하며 코드베이스가 항상 깨끗하고 빌드 가능한 상태인지 확인할 수 있습니다.
+5. 명확한 문서 제공: 모든 구성 또는 설정 요구 사항을 포함하여 린팅 및 빌드 프로세스를 실행하는 방법에 대한 명확한 문서를 제공합니다. 이를 통해 개발자는 린팅 및 빌드 프로세스를 이해하고 따를 수 있으므로 이러한 프로세스를 개발 워크플로에 더 쉽게 통합할 수 있습니다.
+6. Enable Linting and Build as Pre-Commit Hooks: 코드 커밋을 허용하기 전에 Linting 및 빌드 프로세스를 실행하는 사전 커밋 후크를 설정합니다. 이렇게 하면 커밋되는 코드가 프로젝트의 코딩 표준을 준수하고 빌드 프로세스를 통과합니다. 이렇게 하면 버전 제어에 커밋되기 전에 문제를 포착하여 코드베이스에 문제가 발생할 가능성을 줄일 수 있습니다.
+7. Linting 및 건물 구성을 정기적으로 검토 및 업데이트: Linting 및 건물 구성을 정기적으로 검토하고 업데이트하여 최신 코딩 표준, 모범 사례 및 프로젝트 요구 사항을 최신 상태로 유지하십시오. 이렇게 하면 Linting 및 빌드 프로세스의 효율성을 유지하고 코드베이스에서 잠재적인 문제를 계속 포착할 수 있습니다.
+
+이러한 모범 사례를 따르고 linting과 빌드를 개발 워크플로우에 통합함으로써 개발자는 문제를 조기에 파악 및 수정하고 일관된 코딩 표준을 유지하며 코드베이스가 항상 깨끗하고 빌드 가능한 상태인지 확인하여 보다 원활하고 효율적인 개발을 수행할 수 있습니다. 프로세스.
+```
 
 ## Quest
 * 메모장 시스템에 린트 시스템을 적용해 보세요.

From 0f3f5276c2ab398a85f570bbaef42b45efbb249d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:44:32 +0900
Subject: [PATCH 25/29] Quest 15 CheckList Clear

---
 Quest15/README.md | 113 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 113 insertions(+)

diff --git a/Quest15/README.md b/Quest15/README.md
index 4ab6da6c8..ae63ec3ac 100644
--- a/Quest15/README.md
+++ b/Quest15/README.md
@@ -21,13 +21,126 @@
 
 ## Checklist
 * 자동화된 테스트를 만드는 것에는 어떤 장점과 단점이 있을까요?
+```
+자동화된 테스트 또는 테스트 자동화라고도 하는 자동화된 테스트는 소프트웨어 애플리케이션 또는 시스템에 대한 테스트를 자동으로 실행하는 코드 작성과 관련된 소프트웨어 개발 방식입니다. 다음은 자동화된 테스트 생성의 장단점입니다.
+
+자동화 테스트의 장점:
+
+1. 향상된 소프트웨어 품질: 자동화된 테스트를 통해 버그, 오류 및 회귀가 생산 단계로 들어가기 전에 개발 프로세스 초기에 발견할 수 있습니다. 결과적으로 문제를 신속하게 식별하고 수정하여 소프트웨어 품질을 개선하고 결함이 있는 소프트웨어를 출시할 가능성을 줄입니다.
+2. 더 빠르고 효율적인 테스트: 자동화된 테스트를 반복적이고 일관되게 실행할 수 있으므로 소프트웨어 애플리케이션 또는 시스템을 빠르고 효율적으로 테스트할 수 있습니다. 이렇게 하면 시간이 많이 걸리고 사람이 실수하기 쉬운 수동 테스트에 비해 시간과 노력이 절약됩니다.
+3. 증가된 테스트 범위: 자동화된 테스트는 극단적인 경우와 복잡한 상호 작용을 포함하여 수동으로 테스트할 수 없는 많은 테스트 시나리오를 다룰 수 있습니다. 이를 통해 더 높은 테스트 범위를 달성하고 소프트웨어의 다른 부분을 철저히 테스트할 수 있습니다.
+4. 회귀 조기 감지: 코드베이스를 변경한 후 자동화된 테스트를 쉽게 다시 실행할 수 있으므로 회귀, 즉 새로운 버그를 도입하거나 기존 기능을 손상시키는 의도하지 않은 변경을 조기에 감지할 수 있습니다. 이렇게 하면 회귀 문제가 눈에 띄지 않게 되는 것을 방지하고 소프트웨어를 안정적이고 신뢰할 수 있게 유지할 수 있습니다.
+5. 빠른 출시 시간: 자동화된 테스트를 통해 문제를 조기에 파악하여 소프트웨어 릴리스에 대한 빠른 버그 수정 및 처리 시간을 단축할 수 있습니다. 이를 통해 소프트웨어 애플리케이션 또는 시스템의 시장 출시 시간을 단축하여 조직에 경쟁 우위를 제공합니다.
+
+자동화 테스트의 단점:
+
+1. 시간과 노력의 초기 투자: 자동화된 테스트를 만들고 유지 관리하려면 테스트 프레임워크를 설정하고 테스트 스크립트를 작성하고 소프트웨어가 발전함에 따라 유지 관리하기 위한 초기 시간과 노력이 필요합니다. 이것은 특히 복잡한 응용 프로그램이나 시스템의 경우 까다롭고 시간이 많이 소요될 수 있습니다.
+2. 유지 관리 오버헤드: 자동 테스트는 사용자 인터페이스의 업데이트 또는 기본 기술 스택의 변경과 같은 소프트웨어 변경 사항을 최신 상태로 유지하기 위해 정기적인 유지 관리가 필요할 수 있습니다. 이로 인해 시간, 노력 및 리소스 측면에서 오버헤드가 추가될 수 있습니다.
+3. 가양성 및 거짓음성: 자동화된 테스트는 소프트웨어가 실제로 올바르게 작동할 때 오류를 나타내는 가양성 또는 실제 문제를 감지하지 못하는 가음성을 생성할 수 있습니다. 이로 인해 잘못된 결과를 조사하고 해결하는 데 시간과 노력이 낭비될 수 있습니다.
+4. 인간의 판단이 제한됨: 자동 테스트는 미리 정의된 스크립트를 기반으로 하며 수동 테스트가 제공할 수 있는 인간의 판단과 직관이 부족할 수 있습니다. 소프트웨어 테스트의 일부 복잡한 시나리오 또는 주관적인 측면은 정확한 평가를 위해 사람의 개입이 필요할 수 있습니다.
+5. 모든 것을 테스트할 수 없음: 자동화된 테스트는 많은 시나리오를 다룰 수 있지만 특히 소프트웨어가 매우 복잡하거나 동적 동작이 있는 경우 모든 것을 테스트하지 못할 수 있습니다. 특정 유형의 문제를 발견하려면 여전히 수동 테스트가 필요할 수 있습니다.
+
+결론적으로 자동화된 테스트는 소프트웨어 품질 향상, 더 빠르고 효율적인 테스트, 테스트 적용 범위 증가, 회귀 조기 감지와 같은 많은 이점을 제공합니다. 그러나 초기 시간과 노력의 투자, 지속적인 유지 관리가 필요하며 잘못된 결과 및 인간의 판단 측면에서 한계가 있을 수 있습니다. 조직은 소프트웨어 개발 사례의 일부로 자동화된 테스트를 채택하기로 결정하기 전에 특정 요구 사항과 리소스를 신중하게 고려해야 합니다.
+```
   * TDD(Test-Driven Development)란 무엇인가요? TDD의 장점과 단점은 무엇일까요?
+  ```
+  TDD(Test-Driven Development)는 소프트웨어 기능을 구현하기 위한 코드를 작성하기 전에 소프트웨어 기능에 대한 테스트를 작성하는 소프트웨어 개발 접근 방식입니다. TDD의 개발 프로세스는 일반적으로 다음 단계를 따릅니다.
+  
+  1. 테스트 작성: 개발자는 소프트웨어가 표시해야 하는 특정 기능 또는 동작에 대한 테스트 케이스를 작성합니다.
+  2. 테스트 실행: 테스트가 실행되고 기능을 구현하는 코드가 아직 작성되지 않았기 때문에 처음에는 실패해야 합니다.
+  3. 코드 작성: 개발자는 테스트에서 확인하는 기능을 구현하기 위한 코드를 작성합니다.
+  4. 테스트 다시 실행: 테스트가 다시 실행되고 구현된 코드가 올바른 경우 통과해야 합니다.
+  5. 리팩터링: 개발자는 코드를 리팩터링하여 개선하거나 최적화하면서 테스트가 계속 통과되도록 합니다.
+  6. 반복: 구현해야 하는 각각의 새로운 기능이나 동작에 대해 프로세스가 반복됩니다.
+  
+  테스트 주도 개발(TDD)의 장점:
+  
+  1. 개선된 코드 품질: TDD는 코드가 예상 요구 사항을 충족하고 정의된 테스트에 따라 올바르게 작동하는지 확인하는 데 도움이 됩니다. 그 결과 코드 품질이 향상되고 버그나 회귀가 발생할 가능성이 줄어듭니다.
+  2. 빠른 버그 감지 및 수정: TDD는 코드를 작성하기 전에 테스트를 작성하여 개발 프로세스 초기에 버그를 잡아내어 문제가 생산에 들어가기 전에 문제를 더 쉽고 빠르게 식별하고 수정할 수 있도록 합니다.
+  3. 요구 사항에 대한 명확한 이해: 테스트를 작성하면 개발자가 소프트웨어의 요구 사항과 예상되는 동작을 명확하게 이해하여 오해나 오해를 방지할 수 있습니다.
+  4. 쉬운 리팩토링: TDD는 테스트가 의도하지 않은 동작 변경을 포착하는 안전망 역할을 하므로 정기적인 코드 리팩토링을 권장합니다. 이렇게 하면 리팩토링이 쉬워지고 시간이 지남에 따라 코드 품질을 유지하는 데 도움이 됩니다.
+  5. 문서화 및 회귀 테스트: TDD의 테스트는 소프트웨어의 예상 동작에 대한 문서화 역할을 하므로 개발자가 코드베이스를 더 쉽게 이해하고 유지 관리할 수 있습니다. 또한 테스트는 회귀 테스트 역할을 하여 변경 사항이 적용된 후에도 기존 기능이 예상대로 계속 작동하는지 확인합니다.
+  
+  테스트 주도 개발(TDD)의 단점:
+  
+  1. 초기 시간 및 노력 투자: 코드를 작성하기 전에 테스트를 작성하려면 초기에 시간과 노력을 투자해야 하므로 초기에 개발 프로세스가 느려질 수 있습니다.
+  2. 개발자를 위한 학습 곡선: TDD는 개발자에게 학습 곡선이 있을 수 있는 효과적인 테스트 작성 및 테스트 프레임워크 사용과 같은 새로운 기술과 기술을 배우도록 요구할 수 있습니다.
+  3. 불완전한 테스트 범위: 가능한 모든 시나리오에 대한 테스트를 작성하는 것은 시간이 많이 걸리고 복잡하여 테스트에 잠재적인 격차가 생길 수 있으므로 완전한 테스트 범위를 달성하는 것은 어려울 수 있습니다.
+  4. 유지 관리 오버헤드: 테스트는 소프트웨어가 발전함에 따라 정기적인 유지 관리가 필요할 수 있으며 이로 인해 시간, 노력 및 리소스 측면에서 오버헤드가 추가될 수 있습니다.
+  5. 테스트 도구 및 프레임워크에 대한 종속성: TDD는 테스트 도구 및 프레임워크에 크게 의존하며 이러한 도구의 문제 또는 제한 사항은 TDD 접근 방식의 효율성에 영향을 미칠 수 있습니다.
+  
+  결론적으로 TDD는 향상된 코드 품질, 더 빠른 버그 감지 및 수정, 요구 사항에 대한 명확한 이해, 더 쉬운 리팩토링 및 문서화로 이어질 수 있습니다. 그러나 초기 시간과 노력 투자가 필요하고 개발자를 위한 학습 곡선이 있으며 전체 테스트 범위를 달성하는 데 어려움이 있을 수 있으며 유지 관리 오버헤드가 포함될 수 있습니다. 조직은 소프트웨어 개발 접근 방식의 일부로 TDD를 채택하기로 결정하기 전에 특정 개발 사례, 팀 기술 및 프로젝트 요구 사항을 신중하게 고려해야 합니다.
+
+  ```
 * 테스트들 간의 계층에 따라 어떤 단계들이 있을까요?
+```
+소프트웨어 테스트에는 다양한 수준의 테스트를 나타내는 계층 구조 또는 테스트 피라미드가 있으며 각 수준에는 고유한 범위와 목적이 있습니다. 가장 낮은 수준에서 가장 높은 수준까지 일반적인 테스트 계층 구조에는 다음이 포함됩니다.
+
+1. 단위 테스트: 이는 함수, 메서드 또는 클래스와 같은 개별 코드 단위를 시스템의 나머지 부분과 격리하여 테스트하는 데 중점을 둔 테스트입니다. 단위 테스트는 일반적으로 작은 범위를 가지며 개별 코드 단위가 사양에 따라 올바르게 작동하는지 확인하기 위해 개발자가 작성합니다.
+2. 통합 테스트: 시스템 내의 서로 다른 코드 단위 또는 모듈 간의 상호 작용 및 통합을 확인하는 테스트입니다. 통합 테스트는 서로 다른 장치 또는 구성 요소가 전체적으로 함께 작동하는 방식을 테스트하고 올바르게 통합되고 예상 결과를 생성하는지 확인하는 데 중점을 둡니다.
+3. 시스템 테스트: 전체 시스템 또는 애플리케이션의 기능과 동작을 확인하는 테스트입니다. 시스템 테스트는 전체 시스템에서 수행되며 일반적으로 품질 보증(QA) 팀 또는 테스터가 수행하여 시스템이 지정된 요구 사항을 충족하고 다양한 시나리오에서 예상대로 작동하는지 확인합니다.
+4. 승인 테스트: 시스템 또는 애플리케이션이 최종 사용자 또는 이해 관계자의 요구 사항 및 기대치를 충족하는지 확인하는 테스트입니다. 수락 테스트는 일반적으로 이해 관계자, 클라이언트 또는 최종 사용자가 수행하여 시스템이 원하는 결과를 충족하고 기대 가치를 제공하는지 확인합니다.
+
+테스트의 계층 구조는 피라미드 모양을 따르며 단위 테스트가 기본을 형성하고 가장 많으며 통합 테스트, 시스템 테스트 및 승인 테스트가 맨 위에 있습니다. 이 계층 구조는 더 비용 효율적이고 개발 프로세스 초기에 문제를 파악하는 데 도움이 되는 단위 수준에서 초기 및 빈번한 테스트의 중요성을 강조합니다. 계층 구조를 위로 이동하면 테스트 범위가 증가하지만 실행하는 데 더 많은 비용과 시간이 소요되는 경향이 있으므로 테스트 수는 일반적으로 감소합니다. 서로 다른 수준의 테스트 조합은 소프트웨어가 철저히 테스트되고 원하는 품질 표준을 충족하는지 확인하는 데 도움이 됩니다.
+```
   * 유닛 테스트, 통합 테스트, E2E 테스트는 각각 어떤 것을 뜻하나요?
+  ```
+  단위 테스트, 통합 테스트 및 E2E(End-to-End) 테스트는 소프트웨어 개발 프로세스에서 일반적으로 사용되는 다양한 유형의 소프트웨어 테스트입니다.
+  
+  단위 테스트: 단위 테스트는 함수, 메서드 또는 클래스와 같은 개별 코드 단위를 나머지 시스템과 분리하여 테스트하는 데 중점을 둔 테스트입니다. 단위 테스트는 일반적으로 개발자가 작성하며 개발 프로세스 중에 실행되어 개별 코드 단위가 사양에 따라 올바르게 작동하는지 확인합니다. 단위 테스트는 개발 프로세스 초기에 문제를 파악하고 각 코드 단위가 예상대로 작동하는지 확인하는 데 도움이 됩니다.
+  통합 테스트: 통합 테스트는 시스템 내의 서로 다른 코드 단위 또는 모듈 간의 상호 작용 및 통합을 확인하는 테스트입니다. 통합 테스트는 서로 다른 장치 또는 구성 요소가 전체적으로 함께 작동하는 방식을 테스트하고 올바르게 통합되고 예상 결과를 생성하는지 확인하는 데 중점을 둡니다. 통합 테스트는 일반적으로 통합 시스템이 예상대로 작동하는지 확인하기 위해 단위 테스트 후에 수행됩니다.
+  E2E(End-to-End) 테스트: 시스템 테스트 또는 승인 테스트라고도 하는 E2E 테스트는 전체 시스템 또는 애플리케이션의 기능과 동작을 검증하는 테스트입니다. E2E 테스트는 전체 시스템에서 수행되며 실제 사용자 시나리오를 시뮬레이션하여 시스템이 지정된 요구 사항을 충족하고 예상대로 작동하는지 확인합니다. E2E 테스트는 일반적으로 품질 보증(QA) 팀 또는 테스터가 수행하며 시스템이 원하는 결과를 충족하고 최종 사용자에게 예상 가치를 제공하는지 확인합니다.
+  
+  요약하면 단위 테스트는 개별 코드 단위 테스트에 중점을 두고 통합 테스트는 서로 다른 코드 단위 간의 상호 작용을 확인하며 E2E 테스트는 전체 시스템 또는 애플리케이션의 기능 및 동작을 확인합니다. 이러한 유형의 테스트는 소프트웨어가 철저히 테스트되고 원하는 품질 표준을 충족하는지 확인하기 위해 소프트웨어 개발 프로세스의 여러 단계에서 사용됩니다.
+  ```
   * 테스트에 있어서 Stub과 Mock은 어떤 개념을 가리키는 것일까요?
+  ```
+  소프트웨어 테스팅의 맥락에서 스텁과 모의는 실제 종속성 또는 협력자의 동작을 대체하거나 모방하기 위해 테스트에 사용되는 개체 또는 구성 요소인 테스트 더블과 관련된 개념입니다.
+  
+  스텁: 스텁은 테스트 중에 메서드 호출에 대해 미리 정의된 응답을 제공하는 테스트 더블입니다. 스텁은 특정 테스트 시나리오에 필요하지 않거나 테스트 목적으로 설정하기 어려운 실제 종속성 또는 협력자를 대체하는 데 사용됩니다. 스텁을 통해 테스터는 테스트 더블의 동작을 제어하고 예상되는 응답을 제공하여 테스트 프로세스를 단순화하고 일관된 결과를 보장할 수 있습니다.
+  Mocks: Mocks는 테스트 중인 시스템과 해당 종속성 또는 협력자 간의 상호 작용을 캡처하고 확인하는 테스트 더블입니다. 모의는 실제 종속성 또는 협력자를 대체하고 테스터가 메서드 호출에 대한 기대치를 설정하고 테스트 중에 예상되는 상호 작용이 발생하는지 확인하는 데 사용됩니다. 모의는 테스터가 테스트 중인 시스템이 종속성 또는 협력자와 올바르게 상호 작용하고 예상되는 상호 작용이 발생하는지 확인하는 데 도움이 됩니다.
+  
+  요약하면 스텁과 목은 실제 종속성 또는 협력자의 동작을 대체하거나 모방하기 위해 소프트웨어 테스트에서 사용되는 테스트 이중 개념입니다. 스텁은 메서드 호출에 대해 미리 정의된 응답을 제공하는 반면 모의는 테스트 중인 시스템과 해당 종속성 또는 협력자 간의 상호 작용을 캡처하고 확인합니다. 이러한 개념은 테스터가 테스트 시나리오에서 종속성 또는 협력자의 동작을 제어하고 확인하여 소프트웨어의 철저하고 안정적인 테스트를 보장하는 데 도움이 됩니다.
+  ```
 * Jest는 어떤 일을 하며 어떻게 사용하는 테스트 프레임워크일까요?
+```
+Jest는 응용 프로그램, 특히 React JavaScript 라이브러리로 구축된 응용 프로그램을 테스트하는 데 사용되는 인기 있는 JavaScript 테스트 프레임워크입니다. Jest는 테스트 작성, 실행 및 관리를 위한 포괄적이고 사용하기 쉬운 도구 세트를 제공하므로 JavaScript 개발자를 위한 강력한 테스트 프레임워크가 됩니다.
+
+Jest는 Jest를 테스트 프레임워크로 만드는 몇 가지 주요 기능을 제공합니다.
+
+1. 테스트 러너: Jest에는 테스트를 병렬로 실행할 수 있는 내장 테스트 러너가 포함되어 있어 테스트를 빠르고 효율적으로 실행할 수 있습니다. 테스트 결과의 명확하고 자세한 출력을 제공하여 문제를 쉽게 식별하고 수정할 수 있습니다.
+2. 어설션 라이브러리: Jest는 개발자가 테스트에서 예상되는 결과를 정의하기 위해 어설션을 작성할 수 있는 어설션 라이브러리와 함께 제공됩니다. 이렇게 하면 코드 실행의 실제 결과가 예상 결과와 일치하는지 쉽게 확인할 수 있습니다.
+3. 모킹 및 스파이: Jest는 기능, 모듈 및 종속성에 대한 모의 및 스파이를 위한 내장 지원을 제공하여 개발자가 스텁 또는 모의와 같은 테스트 더블로 실제 종속성을 대체할 수 있도록 합니다. 이를 통해 테스트 중에 종속성 동작을 쉽게 격리하고 제어할 수 있습니다.
+4. 코드 커버리지: Jest는 자동으로 코드 커버리지 보고서를 생성하여 테스트된 코드가 테스트에 의해 커버되는 정도를 보여줍니다. 이를 통해 개발자는 적절하게 테스트되지 않은 코드 영역을 식별하고 전반적인 코드 품질을 개선할 수 있습니다.
+5. 스냅샷 테스트: Jest에는 개발자가 렌더링된 UI 구성 요소 또는 데이터 구조의 스냅샷을 캡처하고 비교할 수 있는 스냅샷 테스트가 포함되어 있습니다. 이를 통해 UI 또는 데이터 구조에 대한 의도하지 않은 변경을 쉽게 감지하고 예상 출력이 유지되도록 할 수 있습니다.
+6. 구성 및 확장성: Jest는 개발자가 필요에 따라 테스트 환경과 동작을 사용자 정의할 수 있는 유연한 구성 시스템을 제공합니다. 또한 플러그인 및 다른 테스트 도구 및 라이브러리와의 통합을 통한 확장성을 지원합니다.
+
+요약하면 Jest는 테스트 러너, 어설션 라이브러리, 모킹 및 스파이 기능, 코드 커버리지 보고, 스냅샷 테스트, 구성 및 확장성 옵션을 제공하는 포괄적인 JavaScript 테스트 프레임워크입니다. 테스트 작성, 실행 및 관리 프로세스를 단순화하여 JavaScript 애플리케이션 테스트를 위한 강력한 도구로 만듭니다.
+```
   * Jest 이외의 테스트 프레임워크는 어떤 것이 있고 어떤 장단점이 있을까요?
+  ```
+  Jest 외에도 널리 사용되는 JavaScript용 테스트 프레임워크가 여러 개 있습니다. 다음은 장단점과 함께 그 중 일부입니다.
+  
+  Mocha: Mocha는 유연하고 확장 가능한 테스트 환경을 제공하는 널리 사용되는 테스트 프레임워크입니다. 이를 통해 개발자는 자신의 어설션 라이브러리와 모의 라이브러리를 선택할 수 있으므로 고도로 사용자 정의할 수 있습니다. Mocha는 또한 비동기 테스트를 지원하고 비동기 코드 테스트를 위한 다양한 기능을 제공합니다. 그러나 Mocha는 모킹 및 코드 커버리지와 같은 기능에 대한 추가 설정 및 구성이 필요하며 Jest에 비해 학습 곡선이 더 가파를 수 있습니다.
+  Jasmine: Jasmine은 테스트 작성을 위한 BDD 스타일(행동 주도 개발) 구문을 제공하는 인기 있는 또 다른 테스트 프레임워크입니다. 자체 어설션 라이브러리가 포함되어 있으며 모의 및 감시에 대한 기본 제공 지원을 제공합니다. Jasmine은 대규모 커뮤니티를 보유하고 있으며 잘 문서화되어 있어 리소스와 지원을 쉽게 찾을 수 있습니다. 그러나 Jasmine은 BDD 스타일 구문에 익숙하지 않은 개발자의 경우 학습 곡선이 더 가파를 수 있으며 코드 적용 범위와 같은 기능에 대한 추가 구성이 필요할 수 있습니다.
+  Enzyme: Enzyme은 React 구성 요소를 테스트하기 위해 특별히 설계된 널리 사용되는 테스트 유틸리티입니다. 구성 요소 동작 시뮬레이션, 구성 요소 렌더링 및 출력 조작을 위한 일련의 테스트 유틸리티를 제공합니다. Enzyme에는 얕은 렌더링 모드와 깊은 렌더링 모드가 있어 개발자가 다양한 방식으로 구성 요소를 테스트할 수 있습니다. Enzyme은 Mocha 및 Jasmine과 같은 다른 테스트 프레임워크와도 잘 통합됩니다. 그러나 Enzyme은 React 구성 요소만 테스트하는 것으로 제한되며 모의 및 코드 적용 범위와 같은 기능에 대한 추가 설정 및 구성이 필요할 수 있습니다.
+  AVA: AVA는 성능과 단순성을 강조하는 가볍고 빠른 테스트 프레임워크입니다. 테스트 작성을 위한 간단하고 직관적인 구문을 제공하고 테스트를 동시에 실행하여 빠르고 효율적으로 만듭니다. AVA는 또한 내장된 어설션 라이브러리를 제공하고 즉시 사용 가능한 ES 모듈을 지원합니다. 그러나 AVA는 Jest 또는 Mocha와 같은 다른 테스트 프레임워크에 비해 더 작은 커뮤니티 및 생태계를 가질 수 있으며 내장 모킹 또는 스냅샷 테스트와 같은 모든 고급 기능이 없을 수 있습니다.
+  Cypress: Cypress는 웹 애플리케이션을 위한 포괄적이고 강력한 테스트 솔루션을 제공하는 널리 사용되는 엔드 투 엔드 테스트 프레임워크입니다. 이를 통해 개발자는 실제 브라우저에서 실행되는 테스트를 작성할 수 있으며 UI 상호 작용, API 호출 등을 테스트하기 위한 다양한 기능을 제공합니다. 또한 Cypress는 시각적인 테스트 러너와 강력한 디버깅 및 로깅 시스템을 제공합니다. 그러나 Cypress는 종단 간 테스트에 중점을 두고 있으며 단위 또는 통합 테스트에 적합하지 않을 수 있으며 일부 테스트 시나리오에 대한 추가 설정 및 구성이 필요할 수 있습니다.
+  
+  요약하면 Jest 외에도 JavaScript용 테스트 프레임워크가 몇 가지 더 있으며 각각 고유한 장단점이 있습니다. 테스트 프레임워크의 선택은 프로젝트의 특정 요구 사항, 개발 팀의 전문성 및 친숙성, 수행할 테스트 유형(단위, 통합, 엔드 투 엔드) 및 전체 프로젝트 요구 사항과 같은 요소에 따라 달라집니다. .
+  ```
 * Puppeteer는 어떤 일을 하며 어떻게 사용하는 테스트 프레임워크일까요?
+```
+Puppeteer는 헤드리스(즉, 브라우저 UI가 표시되지 않음) Chromium 또는 Chrome 브라우저 인스턴스를 제어하고 자동화하기 위한 고급 API를 제공하는 Node.js 라이브러리입니다. 이를 통해 개발자는 웹 페이지 탐색, 웹 요소와의 상호 작용, 스크린샷 촬영 및 PDF 생성과 같은 다양한 작업을 수행할 수 있습니다.
+
+Puppeteer는 전통적인 테스트 프레임워크가 아니지만 테스트 프레임워크를 구축하기 위한 기반으로 사용하거나 웹 테스트 자동화를 위한 도구로 사용할 수 있습니다. Puppeteer는 실제 브라우저 환경에서 웹 애플리케이션과의 사용자 상호 작용을 시뮬레이션하는 종단 간(E2E) 테스트를 작성하는 데 활용할 수 있는 강력한 API 세트를 제공합니다. Puppeteer는 Jest, Mocha 또는 Jasmine과 같은 널리 사용되는 테스트 프레임워크와 통합되어 다양한 테스트 환경에서 E2E 테스트를 작성하고 실행할 수 있습니다.
+
+사용자 상호 작용 시뮬레이션, 스크린샷 캡처, PDF 생성 기능과 같은 Puppeteer의 주요 기능은 웹 응용 프로그램의 시각적 모양, 동작 및 기능을 테스트하는 데 적합합니다. 헤드리스 브라우저 환경을 제공하여 눈에 보이는 사용자 인터페이스를 표시하지 않고 백그라운드에서 테스트를 실행할 수 있으므로 빌드 시스템 또는 CI/CD(지속적인 통합/지속적인 배포) 파이프라인에서 자동화된 테스트에 적합합니다.
+
+또한 Puppeteer는 쿠키 처리, 네트워크 요청 가로채기, DOM 조작과 같은 기능을 제공하여 개발자가 복잡한 테스트 시나리오 및 유효성 검사를 수행할 수 있도록 합니다. UI 테스트, 회귀 테스트, 성능 테스트 및 브라우저 간 테스트와 같은 다양한 사용 사례에 대한 테스트를 작성하는 데 사용할 수 있습니다.
+
+그러나 Puppeteer는 주로 종단 간 테스트를 위해 설계되었으며 일반적으로 다른 테스트 접근 방식과 도구가 필요한 단위 또는 통합 테스트에 이상적인 선택이 아닐 수 있습니다. 또한 Puppeteer는 Chromium 또는 Chrome 브라우저에만 적용되므로 다른 브라우저와의 호환성이 제한될 수 있습니다. 그럼에도 불구하고 Puppeteer는 웹 테스트 작업을 자동화하는 강력한 도구가 될 수 있으며 더 큰 테스트 프레임워크 또는 도구 집합의 일부로 사용할 수 있습니다.
+```
 
 ## Quest
 * 직전 퀘스트의 메모장의 서버와 클라이언트 각 부분에 유닛 테스트, 통합 테스트, E2E 테스트 등을 추가해 보세요.

From 8fbd488f54494e9536e5cf564ec6c28a6653b4af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:45:09 +0900
Subject: [PATCH 26/29] Quest 16-B CheckList Clear

---
 Quest16-B/README.md | 65 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/Quest16-B/README.md b/Quest16-B/README.md
index 8e112e70a..352640149 100644
--- a/Quest16-B/README.md
+++ b/Quest16-B/README.md
@@ -15,10 +15,75 @@
 
 ## Checklist
 * 컨테이너는 어떻게 동작하나요? 다른 배포판을 사용할 수 있게 하는 원리가 무엇일까요?
+```
+컨테이너는 라이브러리, 런타임 및 시스템 도구를 포함하여 응용 프로그램 및 해당 종속성을 단일 실행 가능 단위로 캡슐화하는 가볍고 휴대 가능하며 자급자족할 수 있는 소프트웨어 패키지입니다. 컨테이너는 Docker와 같은 컨테이너화 기술을 사용하여 애플리케이션이 개발 머신, 테스트 환경 및 프로덕션 서버와 같은 다양한 컴퓨팅 환경에서 일관되게 실행될 수 있는 격리된 환경을 만듭니다.
+
+컨테이너가 다른 배포판(또는 운영 체제)에서 작동하도록 허용하는 원칙을 "컨테이너화" 또는 "OS 수준 가상화"라고 합니다. 컨테이너화는 컨테이너가 동일한 호스트 OS 커널을 공유하지만 별도의 사용자 공간 인스턴스를 갖는 운영 체제(OS) 수준에서 작동하는 가상화의 한 형태입니다. 컨테이너는 호스트 OS 커널을 활용하여 격리된 파일 시스템, 네트워크 인터페이스 및 각 컨테이너에 대한 프로세스 트리를 제공하는 동시에 CPU, 메모리 및 스토리지와 같은 기본 OS 리소스를 효율적으로 공유합니다.
+
+컨테이너는 작업을 위해 호스트 OS 커널에 의존하기 때문에 특정 배포 또는 OS에 연결되지 않습니다. 이는 컨테이너가 수정 없이 Ubuntu, CentOS 또는 Debian과 같은 다양한 배포에서 일관된 방식으로 종속성과 함께 패키징된 애플리케이션을 실행할 수 있음을 의미합니다. 컨테이너는 기본 호스트 OS에 관계없이 애플리케이션에 일관된 런타임 환경을 제공하므로 이식성이 뛰어나고 다양한 배포 또는 다양한 클라우드 플랫폼에 애플리케이션을 유연하게 배포할 수 있습니다.
+
+컨테이너가 다양한 배포판에서 작동하도록 하는 핵심 기술은 컨테이너 이미지를 사용하는 것입니다. 컨테이너 이미지는 애플리케이션 코드, 런타임, 라이브러리 및 시스템 도구를 포함하여 소프트웨어를 실행하는 데 필요한 모든 것을 포함하는 경량의 독립 실행형 및 이식 가능한 소프트웨어 패키지입니다. 컨테이너 이미지는 Docker와 같은 컨테이너화 도구에서 생성됩니다. 이를 통해 개발자는 호환 가능한 컨테이너 런타임 환경이 있는 한 애플리케이션과 해당 종속성을 다양한 배포 또는 운영 체제에서 일관되게 실행할 수 있는 단일 이미지로 패키징할 수 있습니다.
+
+컨테이너 이미지는 일반적으로 Docker Hub 또는 Google Container Registry와 같은 컨테이너 레지스트리에 저장되며 호환되는 컨테이너 런타임이 설치된 모든 호스트 시스템에서 쉽게 가져와서 실행할 수 있습니다. 이를 통해 응용 프로그램을 컨테이너 이미지로 패키징하고 배포할 수 있으므로 종속성이나 호환성 문제에 대한 걱정 없이 다양한 배포 또는 운영 체제에서 일관되게 배포하고 실행할 수 있습니다. 컨테이너의 이러한 유연성과 이식성 덕분에 최신 소프트웨어 개발 및 배포 워크플로우에 널리 사용됩니다.
+```
 * 도커 컨테이너에 호스트의 파일시스템이나 네트워크 포트를 연결하려면 어떻게 해야 할까요?
+```
+호스트의 파일 시스템을 Docker 컨테이너에 연결:
+docker run 명령을 실행할 때 -v 또는 --volume 옵션을 사용하여 호스트의 파일 시스템을 Docker 컨테이너에 연결할 수 있습니다. 이를 통해 호스트의 파일 시스템에서 컨테이너로 디렉터리 또는 파일을 마운트할 수 있으므로 컨테이너에서 읽기/쓰기 작업에 액세스할 수 있습니다.
+
+호스트의 파일 시스템을 Docker 컨테이너에 연결:
+docker run 명령을 실행할 때 -v 또는 --volume 옵션을 사용하여 호스트의 파일 시스템을 Docker 컨테이너에 연결할 수 있습니다. 이를 통해 호스트의 파일 시스템에서 컨테이너로 디렉터리 또는 파일을 마운트할 수 있으므로 컨테이너에서 읽기/쓰기 작업에 액세스할 수 있습니다. 
+
+이러한 옵션을 사용하면 호스트의 파일 시스템 또는 네트워크 포트를 Docker 컨테이너에 쉽게 연결할 수 있으므로 호스트와 컨테이너 간에 원활한 통신 및 데이터 공유가 가능합니다. 그러나 잠재적으로 보안 위험이나 충돌이 발생할 수 있으므로 호스트 리소스를 컨테이너에 연결할 때 주의하는 것이 중요하며 Docker 컨테이너로 작업할 때 모범 사례 및 보안 지침을 따르는 것이 좋습니다.
+```
 * 도커 컨테이너에서 런타임에 환경변수를 주입하려면 어떻게 해야 할까요?
+```
+Docker에서는 docker run 명령을 실행할 때 -e 또는 --env 옵션을 사용하여 런타임 시 환경 변수를 컨테이너에 주입할 수 있습니다. 방법은 다음과 같습니다.
+
+명령줄에서 환경 변수 주입:
+'-e' 옵션 뒤에 변수 이름과 해당 값을 사용하여 명령줄에서 Docker 컨테이너로 환경 변수를 전달할 수 있습니다. 
+
+파일에서 환경 변수 주입:
+--env-file 옵션 뒤에 변수가 포함된 파일 경로를 사용하여 파일에서 Docker 컨테이너로 환경 변수를 전달할 수도 있습니다.
+
+이러한 옵션을 사용하면 런타임에 환경 변수를 Docker 컨테이너에 동적으로 주입하여 컨테이너 이미지 자체를 수정하지 않고도 컨테이너의 동작 또는 구성을 사용자 지정할 수 있습니다. 런타임에 삽입된 환경 변수는 현재 세션의 컨테이너 내에서만 사용할 수 있으며 컨테이너를 다시 시작할 때에도 변수를 유지해야 하는 경우 Docker 볼륨 또는 구성 파일과 같은 다른 메커니즘을 사용해야 할 수 있습니다.
+```
 * 도커 컨테이너의 stdout 로그를 보려면 어떻게 해야 할까요?
+```
+docker logs 명령을 사용하여 Docker 컨테이너의 stdout(표준 출력) 로그를 볼 수 있습니다. 방법은 다음과 같습니다.
+
+실행 중인 컨테이너에 대한 stdout 로그 보기:
+Docker 컨테이너가 현재 실행 중인 경우 다음 명령을 사용하여 해당 stdout 로그를 볼 수 있습니다.
+
+>> docker logs <container_name_or_id>
+<container_name_or_id>를 보려는 stdout 로그가 있는 컨테이너의 이름 또는 ID로 바꿉니다.
+
+중지된 컨테이너에 대한 stdout 로그 보기:
+Docker 컨테이너가 이미 중지된 경우에도 docker logs 명령을 사용하여 stdout 로그를 볼 수 있습니다. 그러나 --since 옵션 뒤에 타임스탬프를 지정하여 로그를 보려는 시간 범위를 지정해야 합니다.
+
+>> docker logs --since <timestamp> <container_name_or_id>
+<timestamp>를 로그 보기 시작 시간을 나타내는 유효한 타임스탬프로 바꾸고 <container_name_or_id>를 stdout 로그를 보려는 중지된 컨테이너의 이름 또는 ID로 바꿉니다.
+
+docker logs 명령을 사용하면 컨테이너의 출력 및 동작을 문제 해결, 디버깅 또는 모니터링하는 데 도움이 될 수 있는 Docker 컨테이너의 stdout 로그를 쉽게 볼 수 있습니다. stdout 로그는 컨테이너의 표준 출력 스트림만 캡처하며 stderr(표준 오류) 또는 컨테이너 내에서 실행 중인 특정 프로세스의 로그와 같은 다른 로그를 확인해야 하는 경우 컨테이너와 같은 다른 메커니즘을 사용해야 할 수 있습니다. 로깅 드라이버 또는 구성 옵션.
+```
 * 실행중인 도커 컨테이너에 들어가 bash 등의 쉘을 실행하고 로그 등을 보려면 어떻게 해야 할까요?
+```
+실행 중인 Docker 컨테이너에 들어가 Bash와 같은 셸을 실행하고 로그를 보려면 docker exec 명령을 사용할 수 있습니다. 방법은 다음과 같습니다.
+
+실행 중인 컨테이너에 들어가기:
+다음 명령을 사용하여 실행 중인 Docker 컨테이너에 들어가 Bash와 같은 셸을 열 수 있습니다.
+
+>> docker exec -it <container_name_or_id> bash
+<container_name_or_id>를 액세스하려는 실행 중인 컨테이너의 이름 또는 ID로 바꿉니다. -it 옵션은 pseudo-TTY를 할당하고 컨테이너의 stdin, stdout 및 stderr에 연결하는 데 사용되며 bash 명령은 컨테이너 내에서 Bash 셸을 시작하는 데 사용됩니다.
+
+실행 중인 컨테이너에서 로그 보기:
+실행 중인 Docker 컨테이너의 로그를 보려면 다음 명령을 사용할 수 있습니다.
+
+>> docker logs -f <container_name_or_id>
+<container_name_or_id>를 로그를 보려는 실행 중인 컨테이너의 이름 또는 ID로 바꿉니다. -f 옵션은 실시간으로 로그를 스트리밍하는 데 사용되며 생성된 최신 로그를 볼 수 있습니다.
+
+docker exec 및 docker logs 명령을 사용하면 실행 중인 Docker 컨테이너에 쉽게 액세스하고 Bash와 같은 셸을 실행하여 명령을 실행하고 문제 해결 또는 모니터링 목적으로 로그를 보는 등 컨테이너와 상호 작용할 수 있습니다. 이러한 명령을 사용하려면 컨테이너에 대한 적절한 권한 및 액세스 권한이 있어야 하며 특정 기능 또는 로그의 가용성은 컨테이너 이미지 또는 Docker 런타임 환경의 구성에 따라 달라질 수 있습니다.
+```
 
 ## Quest
 * 도커를 설치하고 그 사용법을 익혀 보세요.

From 70f8cc960b9c30f72fd910fd419c53e70ffb00de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:45:38 +0900
Subject: [PATCH 27/29] Quest 17-B CheckList Clear

---
 Quest17-B/README.md | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Quest17-B/README.md b/Quest17-B/README.md
index c04321dcf..3ad1cab62 100644
--- a/Quest17-B/README.md
+++ b/Quest17-B/README.md
@@ -15,7 +15,46 @@
 
 ## Checklist
 * CI/CD는 무엇일까요? CI/CD 시스템을 구축하면 어떤 장점이 있을까요?
+```
+CI/CD는 지속적인 통합 및 지속적인 배포(또는 지속적인 제공)를 나타냅니다. 연속적이고 능률적인 방식으로 생산에 대한 소프트웨어 변경 사항의 빌드, 테스트 및 배포를 자동화하는 것과 관련된 일련의 소프트웨어 개발 사례입니다.
+
+CI/CD 시스템 구축의 이점은 다음과 같습니다.
+
+1. 더 빠른 피드백: CI/CD는 코드가 자동으로 빌드, 테스트 및 프로덕션에 배포되므로 코드 변경에 대한 신속한 피드백을 허용합니다. 이를 통해 개발 프로세스 초기에 버그, 오류 및 기타 문제를 포착하여 더 빠르게 해결할 수 있고 프로덕션 환경에 결함이 발생할 위험을 줄일 수 있습니다.
+2. 향상된 코드 품질: CI/CD 파이프라인의 자동화된 테스트 및 기타 품질 검사는 코드 변경이 미리 정의된 표준 및 요구 사항을 충족하는지 확인하는 데 도움이 됩니다. 구문 오류, 단위 테스트 실패 및 코드 스타일 위반과 같은 문제를 조기에 발견하고 프로덕션에 도달하기 전에 수정할 수 있으므로 코드 품질이 향상됩니다.
+3. 출시 시간 단축: CI/CD를 사용하면 프로덕션에 더 빠르고 더 자주 배포할 수 있으므로 새로운 기능, 버그 수정 및 개선 사항을 더 빨리 제공할 수 있습니다. 이를 통해 조직은 소프트웨어 업데이트를 사용자에게 더 빨리 제공하여 경쟁력을 유지할 수 있으며, 이를 통해 고객 만족도를 높이고 비즈니스 민첩성을 높일 수 있습니다.
+4. 협업 및 책임: CI/CD는 빈번한 코드 커밋을 장려하고 소프트웨어 상태에 대한 가시성을 항상 제공하므로 협업 개발 환경을 촉진합니다. 또한 변경, 테스트 및 배포를 추적하여 특정 변경 또는 기여자로 인해 발생한 문제나 오류를 쉽게 식별하고 해결할 수 있으므로 책임을 장려합니다.
+5. 자동화되고 일관된 배포: CI/CD는 소프트웨어 변경 사항을 구축, 테스트 및 배포하는 프로세스를 자동화하여 인적 오류 가능성을 줄이고 다양한 환경에서 일관성을 보장합니다. 이를 통해 보다 안정적이고 예측 가능한 배포가 가능하고 구성 드리프트의 위험이 줄어들고 필요한 경우 변경 사항을 쉽게 해결하고 롤백할 수 있습니다.
+6. 확장성 및 신뢰성: CI/CD 시스템은 대규모의 복잡한 소프트웨어 개발 프로젝트를 처리하도록 설계되어 조직이 개발 프로세스를 효율적으로 확장할 수 있도록 합니다. 또한 자동화된 테스트 및 배포가 가동 중지 시간이나 생산 중단을 유발할 수 있는 인적 오류의 가능성을 줄이기 때문에 소프트웨어 배포의 안정성을 개선하는 데 도움이 됩니다.
+
+CI/CD 시스템을 구현함으로써 조직은 소프트웨어 개발 프로세스에서 더 빠른 피드백, 향상된 코드 품질, 더 빠른 시장 출시, 더 나은 협업, 자동화되고 일관된 배포, 확장성 및 안정성을 달성할 수 있습니다. 전개.
+```
 * CI 시스템인 Travis CI, Jenkins, Circle CI, Github Actions, AWS Codebuild 의 차이점과 장단점은 무엇일까요?
+```
+Travis CI, Jenkins, CircleCI, GitHub Actions 및 AWS CodeBuild는 소프트웨어 개발 프로젝트에서 널리 사용되는 CI/CD 시스템입니다. 다음은 이러한 시스템의 몇 가지 주요 차이점, 강점 및 약점입니다.
+
+트래비스 CI:
+강점: 클라우드 기반의 CI/CD 시스템으로 설정 및 GitHub 리포지토리와의 통합이 용이합니다. 광범위한 프로그래밍 언어와 프레임워크를 지원하고 우수한 문서와 커뮤니티 지원을 제공합니다.
+단점: Travis CI는 커스터마이징 및 확장성 측면에서 한계가 있으며 대규모 또는 복잡한 프로젝트에 적합하지 않을 수 있습니다. 또한 프리 티어의 개인 리포지토리에 대한 지원이 제한적입니다.
+
+젠킨스:
+장점: Jenkins는 광범위한 플러그인 및 다른 도구와의 통합을 지원하는 고도로 사용자 지정 가능하고 확장 가능한 CI/CD 시스템입니다. 크고 활동적인 커뮤니티가 있으며 온프레미스에서 호스팅할 수 있으므로 특정 보안 또는 규정 준수 요구 사항이 있는 조직에 적합합니다.
+약점: Jenkins는 다른 CI/CD 시스템에 비해 학습 곡선이 더 가파르고 설정 및 유지 관리에 더 많은 노력이 필요합니다. 전용 DevOps 리소스가 없는 소규모 프로젝트나 팀에는 최선의 선택이 아닐 수 있습니다.
+
+서클 CI:
+강점: CircleCI는 클라우드 기반의 CI/CD 시스템으로 단순성과 사용 편의성으로 유명합니다. 깔끔하고 직관적인 UI를 제공하며, 다양한 프로그래밍 언어와 프레임워크를 지원합니다. 또한 Docker 컨테이너에 대한 훌륭한 문서 및 지원이 있습니다.
+단점: CircleCI는 확장성 및 사용자 정의 측면에서 제한이 있을 수 있으며 고급 구성 또는 다른 도구와의 통합이 필요한 대규모 또는 복잡한 프로젝트에 적합하지 않을 수 있습니다.
+
+GitHub 작업:
+강점: GitHub Actions는 GitHub 리포지토리와 긴밀하게 통합되어 GitHub UI에서 직접 CI/CD 파이프라인을 쉽게 설정하고 구성할 수 있습니다. 광범위한 프로그래밍 언어와 프레임워크를 지원하고 우수한 유연성과 사용자 정의 가능성을 제공합니다.
+단점: GitHub Actions는 대규모 또는 복잡한 프로젝트의 확장성 및 성능 측면에서 제한이 있을 수 있습니다. 또한 GitHub 또는 Git 워크플로에 익숙하지 않은 사용자에게는 더 가파른 학습 곡선이 있을 수 있습니다.
+
+AWS 코드빌드:
+장점: AWS CodeBuild는 Amazon Web Services(AWS)에서 제공하는 클라우드 기반 CI/CD 서비스입니다. 다른 AWS 서비스와 잘 통합되어 이미 AWS를 인프라로 사용하고 있는 조직에 적합합니다. 우수한 확장성과 사용자 정의 가능성을 제공하며 광범위한 프로그래밍 언어와 프레임워크를 지원합니다.
+약점: AWS CodeBuild는 AWS 서비스나 개념에 익숙하지 않은 사용자에게 더 높은 학습 곡선을 제공할 수 있습니다. 또한 일부 다른 클라우드 기반 CI/CD 시스템에 비해 설정 및 구성에 더 많은 노력이 필요할 수 있습니다.
+
+요약하면 Travis CI, Jenkins, CircleCI, GitHub Actions 및 AWS CodeBuild는 모두 고유한 장단점이 있는 인기 있는 CI/CD 시스템입니다. 최선의 선택은 프로젝트의 크기와 복잡성, 필요한 사용자 정의 수준, 기존 도구 및 워크플로에 대한 친숙도, 호스팅 기본 설정(클라우드 기반 vs. 온프레미스).
+```
 
 ## Quest
 * AWS Codebuild를 이용하여, 특정 브랜치에 푸시를 하면 린트와 테스트를 거쳐 서버 이미지를 빌드한 뒤, 직전 퀘스트의 EC2 인스턴스에 배포되는 시스템을 만들어 보세요.

From ca185e4ff4c645725f6f4ce63c0224e5f0b596c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:46:18 +0900
Subject: [PATCH 28/29] Quest 18-B CheckList Clear

---
 Quest18-B/README.md | 52 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/Quest18-B/README.md b/Quest18-B/README.md
index 6b9134541..56809f0c3 100644
--- a/Quest18-B/README.md
+++ b/Quest18-B/README.md
@@ -15,8 +15,60 @@
 
 ## Checklist
 * ElasticSearch는 어떤 DB인가요? 기존의 RDB와 어떻게 다르고 어떤 장단점을 가지고 있나요?
+```
+Elasticsearch는 NoSQL 데이터베이스로 분류되는 스키마가 없는 분산형 전체 텍스트 검색 및 분석 엔진입니다. 대규모 데이터를 처리하도록 설계되었으며 로깅, 모니터링, 전자 상거래 및 실시간 분석과 같은 사용 사례에 자주 사용됩니다. 다음은 Elasticsearch와 기존 관계형 데이터베이스(RDB) 간의 몇 가지 주요 차이점과 장단점입니다.
+
+데이터 모델: Elasticsearch는 스키마가 없는 데이터베이스입니다. 즉, 미리 정의된 스키마나 테이블 없이도 데이터를 인덱싱하고 저장할 수 있습니다. 이는 데이터 구조가 미리 정의되고 적용되는 RDB에 비해 보다 동적이고 민첩한 방식으로 데이터를 저장하고 쿼리할 수 있는 유연성을 제공합니다.
+검색 및 쿼리: Elasticsearch는 빠르고 효율적인 전체 텍스트 검색 및 분석을 위해 특별히 설계되었습니다. Apache Lucene 라이브러리를 기반으로 하는 강력한 검색 엔진을 사용하여 복잡한 쿼리, 스코어링 및 관련성 기반 검색 결과를 허용합니다. 반면에 RDB는 일반적으로 검색 기능이 제한되어 있으며 전체 텍스트 검색 기능을 위해 추가 도구나 플러그인이 필요할 수 있습니다.
+확장성 및 배포: Elasticsearch는 분산되고 수평 확장이 가능하도록 설계되어 여러 노드 및 클러스터에서 대량의 데이터를 처리할 수 있습니다. 고가용성 및 내결함성을 위해 자동 샤딩 및 데이터 복제를 제공합니다. 반면에 RDB는 일반적으로 수직 확장이 가능하며 용량을 늘리려면 단일 서버에 더 많은 리소스를 추가해야 할 수 있습니다.
+실시간 분석: Elasticsearch는 실시간 데이터 처리 및 분석에 최적화되어 있어 대규모 데이터 세트의 거의 즉각적인 검색 및 집계가 가능합니다. 따라서 로그 모니터링 및 비즈니스 인텔리전스와 같이 실시간 인사이트 및 분석이 필요한 사용 사례에 적합합니다. RDB는 대규모 실시간 데이터 분석을 처리하는 데 효율적이지 않을 수 있습니다.
+
+Elasticsearch의 장점:
+
+1. 확장성 및 성능: Elasticsearch는 대량의 데이터를 처리하고 빠른 검색 및 분석 기능을 제공하도록 설계되었습니다.
+2. 유연성: Elasticsearch의 스키마 없는 특성으로 인해 동적이고 민첩한 데이터 저장 및 쿼리가 가능합니다.
+3. 분산 및 내결함성: Elasticsearch는 고가용성 및 내결함성을 위해 자동 샤딩 및 복제를 제공합니다.
+4. 실시간 분석: Elasticsearch는 실시간 데이터 처리 및 분석에 최적화되어 있어 거의 즉각적인 통찰력이 필요한 사용 사례에 적합합니다.
+
+Elasticsearch의 단점:
+
+1. 학습 곡선: Elasticsearch에는 고유한 쿼리 구문 및 구성 설정이 있으므로 새로운 기술을 배우고 적응해야 할 수 있습니다.
+2. 데이터 일관성: Elasticsearch는 확장성과 성능을 위해 일정 수준의 데이터 일관성을 희생하므로 엄격한 데이터 일관성이 필요한 모든 사용 사례에 적합하지 않을 수 있습니다.
+3. 하드웨어 요구 사항: Elasticsearch에는 CPU, 메모리 및 스토리지를 포함하여 상당한 양의 리소스가 필요하며 신중한 계획 및 프로비저닝이 필요할 수 있습니다.
+4. 복잡한 설정 및 유지 관리: Elasticsearch 클러스터 설정 및 유지 관리는 복잡할 수 있으며 여러 노드 및 클러스터의 구성, 모니터링 및 관리가 필요합니다.
+```
 * AWS의 ElasticSearch Service는 어떤 서비스인가요? ElasticSearch를 직접 설치하거나 elastic.co에서 직접 제공하는 클라우드 서비스와 비교하여 어떤 장단점이 있을까요?
+```
+AWS Elasticsearch Service는 Amazon Web Services(AWS)에서 제공하는 관리형 Elasticsearch 서비스로, 클라우드에서 Elasticsearch 클러스터를 쉽게 배포, 운영 및 확장할 수 있습니다. 다음은 Elasticsearch를 직접 설치하거나 elastic.co에서 직접 제공하는 클라우드 서비스를 사용하는 것과 비교하여 AWS Elasticsearch Service를 사용할 때의 몇 가지 장단점입니다.
+
+AWS Elasticsearch Service의 장점:
+
+1. 관리형 서비스: AWS Elasticsearch Service는 완전 관리형 서비스입니다. 즉, AWS가 확장, 패치 적용, 모니터링 및 백업과 같은 운영 측면을 처리하므로 광범위한 작업 없이 애플리케이션에 Elasticsearch를 사용하는 데 집중할 수 있습니다. 운영 오버헤드.
+2. AWS 에코시스템과의 통합: AWS Elasticsearch Service는 Amazon CloudWatch, AWS Identity and Access Management(IAM), Amazon VPC 및 Amazon S3와 같은 다른 AWS 서비스와 통합되어 AWS 에코시스템 내에서 원활한 통합과 향상된 기능을 제공합니다.
+3. 손쉬운 배포 및 확장: AWS Elasticsearch Service는 손쉬운 배포 및 확장 옵션을 제공하므로 개별 노드를 수동으로 구성하거나 관리할 필요 없이 요구 사항에 따라 Elasticsearch 클러스터를 신속하게 프로비저닝하고 확장할 수 있습니다.
+4. 고가용성 및 내결함성: AWS Elasticsearch Service는 고가용성 및 내결함성을 위해 여러 가용 영역(AZ)에서 데이터의 복제 및 샤딩을 자동으로 처리하여 하드웨어 장애 또는 장애가 발생하더라도 Elasticsearch 클러스터가 계속 액세스 가능하고 탄력적으로 유지되도록 합니다. AZ 중단.
+
+AWS Elasticsearch Service의 단점:
+
+1. 비용: AWS Elasticsearch Service는 유료 서비스이며 인스턴스 사용, 저장 및 데이터 전송에 대한 시간당 요금을 포함하여 관련 비용이 발생합니다. AWS Elasticsearch Service 사용 비용은 사용 패턴 및 요구 사항에 따라 자체 인프라에 Elasticsearch를 직접 설치하거나 elastic.co에서 직접 제공하는 클라우드 서비스를 사용하는 것보다 높을 수 있습니다.
+2. 버전 제한: AWS Elasticsearch Service는 릴리스 직후 항상 최신 Elasticsearch 버전을 지원하지 않을 수 있으므로 버전 제한이 있을 수 있습니다. 이는 Elasticsearch에서 제공하는 최신 기능 및 개선 사항을 활용하는 능력에 영향을 미칠 수 있습니다.
+3. 사용자 지정 제한: AWS Elasticsearch Service는 자체 설치 Elasticsearch 또는 elastic.co에서 직접 제공하는 클라우드 서비스에 비해 사용자 지정 옵션 및 구성 설정에 제한이 있을 수 있습니다. 이는 특정 요구 사항에 맞게 Elasticsearch 설정을 미세 조정하는 능력에 영향을 미칠 수 있습니다.
+
+요약하면 AWS Elasticsearch Service는 배포, 확장 및 AWS 에코시스템과의 통합을 용이하게 하는 관리형 Elasticsearch 서비스입니다. 그러나 자체 설치 Elasticsearch 또는 elastic.co에서 직접 제공하는 클라우드 서비스에 비해 관련 비용이 발생하고 버전 지원 및 사용자 지정 옵션 측면에서 제한이 있을 수 있습니다. 요구 사항을 신중하게 평가하고 AWS Elasticsearch Service의 장단점을 다른 옵션과 비교하여 특정 사용 사례에 가장 적합한 것을 결정하는 것이 중요합니다.
+```
 * Grafana의 Panel 형식에는 어떤 것이 있을까요? 로그를 보기에 적합한 판넬은 어떤 형태일까요?
+```
+Grafana는 데이터 표시를 위한 다양한 유형의 패널을 지원하는 인기 있는 오픈 소스 데이터 시각화 및 모니터링 도구입니다. Grafana의 패널 유형은 다음과 같습니다.
+
+1. 그래프: 그래프 패널은 라인 차트, 막대 차트, 누적 영역 차트 등의 형태로 시계열 데이터를 표시하는 데 사용됩니다. 시간 경과에 따른 수치 데이터를 시각화하는 데 적합하며 일반적으로 CPU와 같은 메트릭 모니터링에 사용됩니다. 사용량, 네트워크 트래픽 또는 센서 데이터.
+2. Singlestat: singlestat 패널은 단일 값을 게이지, 스파크라인 또는 기타 그래픽 표현으로 표시하는 데 사용됩니다. 특정 메트릭의 현재 값, 총 이벤트 수 또는 서비스의 최신 상태와 같은 요약 통계 또는 집계된 값을 표시하는 데 적합합니다.
+3. 표: 표 패널은 표 형식의 데이터를 그리드 형식으로 표시하는 데 사용됩니다. 로그 데이터, 이벤트 데이터 또는 기타 구조화된 데이터를 사용자 정의 가능한 열 및 정렬 옵션이 있는 표 형식으로 표시하는 데 적합합니다.
+4. 텍스트: 텍스트 패널은 정적 텍스트, 마크다운 또는 HTML 콘텐츠를 표시하는 데 사용됩니다. 정적 정보, 주석 또는 설명을 대시보드에 표시하는 데 적합합니다.
+5. 히트맵: 히트맵 패널은 데이터를 히트맵으로 표시하는 데 사용되며 여기서 값은 그리드의 색상으로 표시됩니다. 온도, 습도 또는 지리적 데이터에 대한 히트맵과 같은 2차원 좌표 및 색상 코드 값으로 데이터를 시각화하는 데 적합합니다.
+6. 경고 목록: 경고 목록 패널은 Grafana의 경고 시스템에서 생성된 활성 경고 목록을 표시하는 데 사용됩니다. 정의된 임계값 또는 조건에 의해 트리거되는 경고를 모니터링하고 관리하는 데 적합합니다.
+
+Grafana에서 로그를 보려면 테이블 패널이 일반적으로 적합합니다. 테이블 패널은 구조화된 로그 데이터를 사용자 정의 가능한 열 및 정렬 옵션이 있는 표 형식으로 표시할 수 있기 때문입니다. 이를 통해 사용자는 로그 데이터를 표 형식으로 쉽게 보고 분석할 수 있어 로그 분석 및 문제 해결 작업에 편리합니다.
+```
 
 ## Quest
 * 우리의 웹 서버가 stdout으로 적절한 로그를 남기도록 해 보세요.

From 66557889b606c685d9678c70a079d5badbed7b45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EC=84=B1=EC=97=B0=EC=A4=80?= <elwlahs60@gmail.com>
Date: Tue, 11 Apr 2023 13:46:42 +0900
Subject: [PATCH 29/29] Quest 19-B CheckList Clear

---
 Quest19-B/README.md | 87 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 87 insertions(+)

diff --git a/Quest19-B/README.md b/Quest19-B/README.md
index b235fdb50..fd90d65a2 100644
--- a/Quest19-B/README.md
+++ b/Quest19-B/README.md
@@ -17,10 +17,97 @@
 
 ## Checklist
 * 마이크로서비스 아키텍쳐란 무엇일까요? 어떤 식으로 서비스를 구성할 수 있을까요? 어떤 장점을 가지고 있을까요?
+```
+마이크로서비스 아키텍처는 애플리케이션이 느슨하게 결합되고 독립적으로 배포 가능한 소규모 서비스 모음으로 분할되는 소프트웨어 개발 접근 방식입니다. 각 서비스는 특정 기능을 담당하며 일반적으로 API(응용 프로그래밍 인터페이스)를 통해 네트워크를 통해 다른 서비스와 통신합니다. 마이크로서비스는 자체 프로세스에서 실행되고 자체 데이터 저장소가 있는 각 서비스와 함께 모듈식 및 자율적으로 설계되었습니다.
+
+마이크로 서비스를 구성하려면 일반적으로 데이터베이스 연결 설정, API 끝점, 로깅 수준, 인증 설정 등과 같은 서비스에 대한 구성 매개 변수 또는 설정을 정의합니다. 이러한 구성 설정은 구성 파일, 환경 변수 또는 중앙 집중식 마이크로 서비스에 사용되는 기술 스택 및 인프라에 따라 구성 관리 시스템.
+
+마이크로서비스 아키텍처의 장점은 다음과 같습니다.
+
+1. 확장성: 마이크로서비스는 특정 요구 사항에 따라 개별 서비스를 독립적으로 확장할 수 있으므로 효율적인 리소스 활용과 수평적 확장이 가능합니다.
+2. 유연성: 마이크로서비스는 모놀리식 아키텍처에 얽매이지 않고 특정 요구 사항에 따라 각 서비스에 대해 서로 다른 기술, 프로그래밍 언어 및 프레임워크를 선택할 수 있는 유연성을 제공합니다.
+3. 모듈성: 마이크로서비스는 느슨하게 결합되도록 설계되어 다른 서비스에 영향을 주지 않고 각 서비스를 독립적으로 개발, 테스트, 배포 및 유지 관리하기가 더 쉽습니다.
+4. 복원력: 마이크로서비스는 서로 격리되어 있으므로 하나의 서비스에 오류가 발생하거나 문제가 발생하더라도 다른 서비스에 반드시 영향을 미치지 않으므로 단일 지점 오류의 위험이 줄어듭니다.
+5. 지속적인 전달: 마이크로서비스는 각 서비스를 독립적으로 테스트, 구축 및 배포할 수 있으므로 반복 및 릴리스 주기를 더 빠르게 할 수 있으므로 지속적인 전달 및 배포 관행을 촉진합니다.
+6. 팀 자율성: 마이크로서비스는 서로 다른 팀이 자체 개발, 테스트 및 배포 프로세스를 통해 서로 다른 서비스에 대해 독립적으로 작업할 수 있도록 하여 개발 프로세스에서 더 큰 자율성과 민첩성을 제공합니다.
+
+그러나 마이크로서비스 아키텍처에는 분산 시스템 관리의 복잡성 증가, 서비스 간 통신의 추가 오버헤드, 효과적인 모니터링, 로깅 및 디버깅 관행의 필요성과 같은 몇 가지 문제도 있습니다. 소프트웨어 개발 프로젝트에서 마이크로서비스 아키텍처를 성공적으로 채택하려면 적절한 설계, 구현 및 관리가 중요합니다.
+```
 * 서버리스 아키텍쳐란 무엇일까요? 어떤 식으로 서비스를 구성할 수 있을까요? 어떤 장점을 가지고 있을까요?
+```
+FaaS(Function-as-a-Service)라고도 하는 서버리스 아키텍처는 서버 관리 책임을 개발자로부터 추상화하고 이벤트에 의해 트리거되는 서버리스 기능을 구성하여 애플리케이션을 구축하는 클라우드 컴퓨팅 패러다임입니다. 서버리스 아키텍처에서 개발자는 HTTP 요청, 데이터베이스 변경 또는 예약된 이벤트와 같은 특정 이벤트 또는 트리거에 대한 응답으로 실행되는 작은 상태 비저장 기능을 작성하는 데 중점을 둡니다.
+
+서버리스 아키텍처에서 서비스를 구성하려면 일반적으로 함수의 이벤트 소스 정의, 필요한 리소스 지정, 적절한 트리거 설정, 서버리스 컴퓨팅에 사용되는 함수 또는 플랫폼에 특정한 기타 매개변수 구성이 포함됩니다. 이는 사용 중인 플랫폼 및 서비스에 따라 클라우드 공급자의 관리 콘솔, 명령줄 인터페이스(CLI) 또는 코드형 인프라(IaC) 도구를 통해 수행할 수 있습니다.
+
+서버리스 아키텍처의 장점은 다음과 같습니다.
+
+1. 비용 효율성: 서버리스 컴퓨팅은 기존의 서버 기반 아키텍처에서 미리 할당된 리소스에 대한 비용을 지불하는 것과는 반대로 기능의 실제 사용량을 기반으로 세분화된 청구를 허용합니다. 이로 인해 특히 간헐적으로 사용되거나 가변적인 워크로드 애플리케이션의 경우 비용을 절감할 수 있습니다.
+2. 확장성: 서버리스 기능은 들어오는 이벤트 또는 트리거 수에 따라 자동으로 확장되어 애플리케이션이 수동 개입 없이 다양한 워크로드를 처리할 수 있도록 합니다.
+3. 단순화된 운영: 서버리스 아키텍처를 사용하면 개발자는 서버, 네트워킹 또는 기타 인프라 구성 요소를 관리할 필요가 없습니다. 이러한 책임은 클라우드 공급자에 의해 추상화되기 때문입니다. 이를 통해 개발자는 인프라 관리가 아닌 코드 작성에 집중할 수 있습니다.
+4. 신속한 개발: 서버리스 아키텍처는 개발에 대한 모듈식 및 이벤트 중심 접근 방식을 촉진하여 개발자가 쉽게 테스트하고 반복할 수 있는 작고 집중적인 기능을 신속하게 구축하고 배포하여 개발 주기를 단축할 수 있도록 합니다.
+5. 유연성: 서버리스 아키텍처는 기능이 기본 인프라에서 분리되어 기술 선택의 유연성을 제공하므로 다양한 언어, 프레임워크 및 서비스의 혼합을 사용하여 애플리케이션을 구축할 수 있습니다.
+6. 자동 크기 조정: 서버리스 기능은 들어오는 이벤트 또는 트리거 수에 따라 자동으로 확장 또는 축소할 수 있으므로 애플리케이션이 수동 개입 없이 다양한 워크로드를 처리할 수 있습니다.
+
+그러나 서버리스 아키텍처에는 자주 사용하지 않는 기능에 대한 잠재적인 콜드 스타트 ​​대기 시간, 개별 기능에 대한 제한된 실행 시간, 분산 상태 또는 복잡한 워크플로 관리 문제와 같은 몇 가지 제한 사항도 있습니다. 소프트웨어 개발 프로젝트에서 서버리스 아키텍처를 성공적으로 채택하려면 적절한 설계, 테스트 및 모니터링 방식이 중요합니다.
+```
 * AWS Lambda는 어떤 서비스일까요? 이러한 서비스는 어떤 특징을 가지고, 어디에 쓰일 수 있을까요?
+```
+AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이 클라우드에서 코드를 실행할 수 있도록 하는 Amazon Web Services(AWS)에서 제공하는 서버리스 컴퓨팅 서비스입니다. AWS Lambda를 사용하면 이벤트에 의해 트리거되는 작은 상태 비저장 함수를 작성하고 수신 이벤트 수에 따라 자동으로 확장할 수 있습니다.
+
+AWS Lambda의 특징은 다음과 같습니다.
+
+1. 이벤트 기반 컴퓨팅: AWS Lambda 함수는 HTTP 요청, S3 버킷의 변경 또는 CloudWatch 이벤트와 같은 이벤트에 의해 트리거되므로 특정 이벤트에 실시간으로 응답하는 서버리스 애플리케이션을 구축할 수 있습니다.
+2. 자동 조정: AWS Lambda는 들어오는 이벤트 수에 따라 함수 인스턴스 수를 자동으로 조정하므로 애플리케이션이 수동 개입 없이 다양한 워크로드를 처리할 수 있습니다.
+3. 사용한 만큼만 지불: AWS Lambda는 선결제 비용이나 장기 약정 없이 함수의 실제 사용량에 대해서만 비용을 지불하는 종량제 가격 모델을 제공합니다. 이를 통해 실제 워크로드를 기반으로 비용 효율적인 확장이 가능합니다.
+4. 상태 비저장 실행: AWS Lambda 함수는 상태 비저장이므로 호출 간에 데이터나 컨텍스트를 유지하지 않습니다. 이것은 서로 독립적이고 공유 상태에 의존하지 않는 작고 집중적인 기능을 작성하는 "서버리스" 사고 방식을 촉진합니다.
+5. 다른 AWS 서비스와의 손쉬운 통합: AWS Lambda는 Amazon S3, Amazon DynamoDB, Amazon SNS 및 Amazon SQS와 같은 다른 AWS 서비스와 쉽게 통합할 수 있으므로 서버리스 기능 및 기타 관리 서비스의 조합을 사용하여 복잡한 애플리케이션을 구축할 수 있습니다. .
+
+AWS Lambda는 다음을 비롯한 다양한 사용 사례에서 사용할 수 있습니다.
+
+1. 실시간 데이터 처리: AWS Lambda를 사용하여 IoT 장치에서 데이터 스트림 처리, 로그 분석 또는 다운스트림 처리를 위한 데이터 변환과 같이 들어오는 데이터를 실시간으로 처리할 수 있습니다.
+2. 서버리스 API: AWS Lambda를 사용하여 서버리스 API를 구축할 수 있습니다. 여기서 Lambda 함수는 들어오는 API 요청 처리를 처리하여 비용 효율적이고 확장 가능한 API 아키텍처를 허용합니다.
+3. 데이터 변환 및 보강: AWS Lambda는 데이터 처리 파이프라인의 일부로 데이터 검증, 필터링 또는 보강과 같은 전송 중인 데이터를 변환하고 보강하는 데 사용할 수 있습니다.
+4. 자동화 및 DevOps 작업: AWS Lambda를 사용하여 DevOps 워크플로의 일부로 백업, 데이터 동기화 및 배포 작업과 같은 작업을 자동화할 수 있습니다.
+5. 챗봇 및 메시징 애플리케이션: AWS Lambda를 사용하여 메시징 및 챗봇 상호 작용을 처리하고 수신 메시지를 처리하고 적절한 응답 또는 작업을 트리거할 수 있습니다.
+6. 이미지 및 비디오 처리: AWS Lambda는 미디어 처리 워크플로의 일부로 크기 조정, 자르기 또는 트랜스코딩과 같은 이미지 또는 비디오를 처리하는 데 사용할 수 있습니다.
+7. 기계 학습 추론: AWS Lambda는 추론을 위한 기계 학습 모델을 호출하는 데 사용할 수 있으므로 서버리스 애플리케이션에서 실시간 예측이 가능합니다.
+
+이는 AWS Lambda를 활용하여 서버리스 애플리케이션을 구축하고 클라우드에서 이벤트 중심의 확장 가능하며 비용 효율적인 컴퓨팅을 가능하게 하는 많은 사용 사례 중 일부에 불과합니다.
+```
 * API Gateway는 어떤 서비스인가요? 어떤 설정을 할 수 있을까요?
+```
+API Gateway는 애플리케이션용 API(애플리케이션 프로그래밍 인터페이스)를 생성, 배포 및 관리할 수 있도록 Amazon Web Services(AWS)에서 제공하는 완전 관리형 서비스입니다. 웹 또는 모바일 애플리케이션과 같은 클라이언트와 AWS Lambda, Amazon EC2 인스턴스 또는 기타 HTTP 엔드포인트와 같은 백엔드 서비스 간의 통신을 가능하게 하는 "게이트웨이" 역할을 합니다.
+
+API Gateway는 다음을 포함하여 애플리케이션의 요구 사항에 맞게 사용자 지정할 수 있는 광범위한 설정 및 구성을 제공합니다.
+
+API 생성 및 관리: API Gateway 콘솔, AWS CLI(Command Line Interface) 또는 AWS SDK(Software Development Kits)를 사용하여 API를 생성하고 관리할 수 있습니다. 인증 및 권한 부여, 캐싱, 제한 및 로깅과 같은 API 설정을 구성할 수 있습니다.
+API 배포: API Gateway를 사용하면 프로덕션, 스테이징 또는 개발과 같은 다양한 환경에 API를 배포하고 여러 API 버전을 관리할 수 있습니다. 사용자 지정 배포 단계를 생성하고, API 수명 주기를 관리하고, API 버전 관리를 처리할 수도 있습니다.
+인증 및 권한 부여: API Gateway는 AWS Identity and Access Management(IAM), Amazon Cognito 또는 Lambda 함수를 사용한 사용자 지정 권한 부여와 같은 다양한 메커니즘을 사용하여 인증 및 권한 부여에 대한 기본 제공 지원을 제공합니다. 인증 및 승인 설정을 구성하여 API에 대한 액세스를 제어할 수 있습니다.
+요청 및 응답 변환: API Gateway를 사용하면 매핑 템플릿을 사용하여 요청 및 응답을 변환할 수 있으므로 요청 및 응답 페이로드, 헤더 및 쿼리 매개 변수를 수정할 수 있습니다. 이는 데이터 유효성 검사, 데이터 보강 또는 페이로드 수정에 유용할 수 있습니다.
+캐싱 및 조절: API Gateway는 API의 성능과 확장성을 제어하기 위한 캐싱 및 조절 설정을 제공합니다. 백엔드 서비스의 응답을 캐시하도록 캐싱 설정을 구성하여 백엔드 리소스에 대한 로드를 줄일 수 있습니다. 또한 제한 설정을 구성하여 API에 대한 요청 속도를 제한하여 서비스 남용 또는 과부하를 방지할 수 있습니다.
+모니터링 및 로깅: API Gateway는 모니터링 및 로깅 기능을 제공하므로 API의 성능 및 사용을 모니터링할 수 있습니다. 분석 및 문제 해결을 위해 API Gateway 로그를 Amazon CloudWatch Logs로 캡처하도록 로깅 설정을 구성할 수 있습니다. CloudWatch 지표를 활성화하여 API Gateway 사용량, 오류 및 지연 시간을 모니터링할 수도 있습니다.
+사용자 지정 도메인 이름 및 SSL 인증서: API Gateway를 사용하면 API에 대한 사용자 지정 도메인 이름을 구성하여 사용자 지정 URL을 통해 API를 노출할 수 있습니다. 클라이언트와 API 간의 통신을 보호하기 위해 SSL(Secure Sockets Layer) 인증서를 구성할 수도 있습니다.
+API 설명서 및 테스트: API Gateway는 API 설명서를 생성하는 기능을 제공하므로 OpenAPI(이전의 Swagger) 형식으로 API 설명서를 생성할 수 있습니다. 내장된 API Gateway 테스트 콘솔을 사용하여 API를 테스트하고 API 요청 및 응답을 시뮬레이션할 수도 있습니다.
+
+이는 AWS API Gateway로 수행할 수 있는 설정 및 구성 중 일부에 불과합니다. API Gateway는 특정 요구 사항에 맞게 사용자 지정할 수 있는 다양한 기능과 설정을 통해 애플리케이션용 API를 생성, 배포 및 관리하기 위한 유연하고 확장 가능한 솔루션을 제공합니다.
+```
 * 많은 마이크로서비스들을 복잡하게 연결할 경우 관리상에 어떤 난점이 생길 수 있을까요? 서비스 메쉬는 무엇이고 이러한 난점을 어떻게 해결하려는 시도일까요?
+```
+많은 마이크로서비스가 복잡한 방식으로 연결되면 다음과 같은 몇 가지 관리 문제가 발생할 수 있습니다.
+
+1. 서비스 검색 및 라우팅: 마이크로서비스의 수가 증가함에 따라 특히 서비스가 자주 오고 갈 수 있는 동적 환경에서 서비스 간 요청을 검색하고 라우팅하는 것이 어려워집니다. 서비스 검색 및 라우팅을 수동으로 관리하는 것은 번거롭고 오류가 발생하기 쉽습니다.
+2. 로드 밸런싱: 최적의 리소스 활용을 보장하고 개별 인스턴스의 과부하를 방지하기 위해 수신 요청을 여러 마이크로서비스 인스턴스에 고르게 분배하는 것은 특히 마이크로서비스 및 해당 인스턴스의 수가 증가함에 따라 어려울 수 있습니다.
+3. 복원력 및 내결함성: 복잡한 마이크로서비스 아키텍처에서 복원력과 내결함성을 관리하는 것은 어려울 수 있습니다. 서비스가 실패하거나 네트워크 문제가 발생하거나 예기치 않은 오류가 발생할 수 있습니다. 이러한 오류를 적절하게 처리하고 재시도, 회로 차단기 및 기타 내결함성 패턴을 적용하는 것은 마이크로 서비스 수가 증가함에 따라 복잡해질 수 있습니다.
+4. 관찰 가능성 및 모니터링: 마이크로서비스의 동작 및 성능에 대한 가시성 확보, 상태 모니터링 및 문제 해결은 복잡한 마이크로서비스 아키텍처에서 어려울 수 있습니다. 기존의 모니터링 접근 방식은 확장성이 좋지 않을 수 있으며 마이크로 서비스의 분산 특성에 대한 적절한 가시성을 제공하지 못할 수 있습니다.
+
+서비스 메시는 마이크로서비스 아키텍처 관리에서 이러한 문제를 해결하도록 설계된 전용 인프라 계층입니다. 개별 마이크로서비스에서 추상화된 일련의 공통 네트워킹 및 관찰 가능성 기능을 제공하여 이러한 교차 절단 문제를 개별적으로 관리할 필요 없이 핵심 기능에 집중할 수 있습니다.
+
+서비스 메시에는 일반적으로 각 마이크로 서비스 인스턴스와 함께 Envoy 또는 Istio와 같은 사이드카 프록시 집합을 주입하여 데이터 평면을 형성하는 작업이 포함됩니다. 이러한 프록시는 서비스 검색, 로드 밸런싱, 트래픽 라우팅, 내결함성 및 관찰 가능성과 같은 작업을 처리하는 반면 마이크로 서비스 자체는 이러한 문제에서 분리된 상태로 유지됩니다.
+
+서비스 메시는 프록시 구성 및 관리를 위한 중앙 집중식 관리 평면인 제어 평면도 제공합니다. 컨트롤 플레인을 통해 운영자는 정책을 정의 및 시행하고, 라우팅 규칙을 구성하고, 인증 및 승인과 같은 보안 기능을 관리하고, 마이크로서비스의 동작 및 성능을 모니터링할 수 있습니다.
+
+서비스 메시는 교차 절단 문제를 처리하기 위한 통합되고 표준화된 접근 방식을 제공하여 각 마이크로 서비스에 대해 이러한 문제를 개별적으로 관리하는 복잡성을 줄임으로써 복잡한 마이크로 서비스 아키텍처 관리의 어려움을 해결하는 것을 목표로 합니다. 관찰 가능성을 개선하고, 관리를 간소화하고, 탄력성을 강화하고, 마이크로서비스 통신을 관리하는 일관된 방법을 제공하여 규모에 맞게 마이크로서비스 기반 애플리케이션을 더 쉽게 운영하고 관리할 수 있도록 합니다.
+```
 
 ## Quest
 * 메모장 시스템을 JWT 발급을 위한 마이크로서비스와 실제 비즈니스 로직을 처리하는 마이크로서비스로 나누어 보세요.