diff --git a/6-data-storage/01-cookie/article.md b/6-data-storage/01-cookie/article.md
index de532a1b4..13f684fdc 100644
--- a/6-data-storage/01-cookie/article.md
+++ b/6-data-storage/01-cookie/article.md
@@ -1,39 +1,23 @@
 # 쿠키와 document.cookie
 
-<<<<<<< HEAD
 쿠키는 브라우저에 저장되는 작은 크기의 문자열로, [RFC 6265](https://tools.ietf.org/html/rfc6265) 명세에서 정의한 HTTP 프로토콜의 일부입니다.
 
-쿠키는 주로 웹 서버에 의해 만들어집니다. 서버가 HTTP 응답 헤더(header)의 `Set-Cookie`에 내용을 넣어 전달하면, 브라우저는 이 내용을 자체적으로 브라우저에 저장합니다. 이게 바로 쿠키입니다. 브라우저는 사용자가 쿠키를 생성하도록 한 동일 서버(사이트)에 접속할 때마다 쿠키의 내용을 `Cookie` 요청 헤더에 넣어서 함께 전달합니다. 
-=======
-Cookies are small strings of data that are stored directly in the browser. They are a part of the HTTP protocol, defined by the [RFC 6265](https://tools.ietf.org/html/rfc6265) specification.
-
-Cookies are usually set by a web server using the response `Set-Cookie` HTTP header. Then, the browser automatically adds them to (almost) every request to the same domain using the `Cookie` HTTP header.
->>>>>>> upstream/master
+쿠키는 주로 웹 서버에 의해 만들어집니다. 서버가 HTTP 응답 헤더의 `Set-Cookie`에 내용을 넣어 전달하면, 브라우저는 이 내용을 저장합니다. 이게 바로 쿠키입니다. 이후 브라우저는 같은 도메인에 요청을 보낼 때마다 쿠키의 내용을 `Cookie` 요청 헤더에 넣어 함께 전달합니다.
 
 쿠키는 클라이언트 식별과 같은 인증에 가장 많이 쓰입니다.
 
-<<<<<<< HEAD
-1. 사용자가 로그인하면 서버는 HTTP 응답 헤더의 `Set-Cookie`에 담긴 "세션 식별자(session identifier)" 정보를 사용해 쿠키를 설정합니다.
-2. 사용자가 동일 도메인에 접속하려고 하면 브라우저는 HTTP `Cookie` 헤더에 인증 정보가 담긴 고윳값(세션 식별자)을 함께 실어 서버에 요청을 보냅니다.
+1. 사용자가 로그인하면 서버는 HTTP 응답 헤더의 `Set-Cookie`에 담긴 "세션 식별자" 정보를 사용해 쿠키를 설정합니다.
+2. 사용자가 동일 도메인에 접속하려고 하면 브라우저는 HTTP `Cookie` 헤더에 인증 정보가 담긴 고윳값인 세션 식별자를 함께 실어 서버에 요청을 보냅니다.
 3. 서버는 브라우저가 보낸 요청 헤더의 세션 식별자를 읽어 사용자를 식별합니다.
-=======
-1. Upon sign-in, the server uses the `Set-Cookie` HTTP header in the response to set a cookie with a unique "session identifier".
-2. Next time the request is sent to the same domain, the browser sends the cookie over the net using the `Cookie` HTTP header.
-3. So the server knows who made the request.
->>>>>>> upstream/master
 
 `document.cookie` 프로퍼티를 이용하면 브라우저에서도 쿠키에 접근할 수 있습니다.
 
-<<<<<<< HEAD
 쿠키와 다양한 쿠키의 옵션을 다루는 일은 쉽지 않습니다. 이 챕터에선 이에 대해 자세히 알아보도록 하겠습니다.
-=======
-There are many tricky things about cookies and their attributes. In this chapter, we'll cover them in detail.
->>>>>>> upstream/master
 
 ## 쿠키 읽기
 
 ```online
-지금 보고 있는 이 사이트와 관련된 쿠키가 브라우저에 저장되어있는지 알아봅시다.
+지금 보고 있는 이 사이트와 관련된 쿠키가 브라우저에 저장되어 있는지 알아봅시다.
 ```
 
 ```offline
@@ -41,37 +25,23 @@ There are many tricky things about cookies and their attributes. In this chapter
 ```
 
 ```js run
-// javascript.info에선 Google Analytics(GA)를 사용해 데이터를 수집하고 있습니다.
+// javascript.info에선 Google Analytics를 사용해 데이터를 수집하고 있습니다.
 // 이와 관련된 쿠키를 확인해 봅시다.
 alert( document.cookie ); // cookie1=value1; cookie2=value2;...
 ```
 
 
-<<<<<<< HEAD
-`document.cookie`는 `name=value` 쌍으로 구성되어있고, 각 쌍은 `;`로 구분합니다. 이때, 쌍 하나는 하나의 독립된 쿠키를 나타냅니다.
+`document.cookie`는 `name=value` 쌍으로 구성되어 있고, 각 쌍은 `;`로 구분합니다. 이때, 쌍 하나는 하나의 독립된 쿠키를 나타냅니다.
 
 `;`을 기준으로 `document.cookie`의 값을 분리하면 원하는 쿠키를 찾을 수 있습니다. 정규 표현식이나 배열 관련 함수를 함께 사용해서 말이죠.
 
-이에 관한 연습문제를 아래에서 풀어보길 권유합니다. 쿠키 조작에 쓰이는 몇 가지 헬퍼(도우미) 함수를 챕터 끝에 명시해 놓았으니, 이를 참고하셔도 좋습니다.
-=======
-The value of `document.cookie` consists of `name=value` pairs, delimited by `; `. Each one is a separate cookie.
-
-To find a particular cookie, we can split `document.cookie` by `; `, and then find the right name. We can use either a regular expression or array functions to do that.
-
-We leave it as an exercise for the reader. Also, at the end of the chapter, you'll find helper functions to manipulate cookies.
->>>>>>> upstream/master
+이에 관한 연습문제를 아래에서 풀어보길 권유합니다. 쿠키 조작에 쓰이는 몇 가지 도우미 함수를 챕터 끝에 명시해 놓았으니, 이를 참고하셔도 좋습니다.
 
 ## 쿠키 쓰기
 
-<<<<<<< HEAD
-`document.cookie`에 직접 값을 쓸 수 있습니다. 이때 `cookie`는 데이터 프로퍼티가 아닌 접근자(accessor) 프로퍼티입니다. 앞서 <info:property-accessors>에서 학습한 바와 같이, 접근자 프로퍼티에 값을 할당하는 것은 데이터 프로퍼티에 값을 할당하는 것과는 조금 다르게 처리됩니다.
+`document.cookie`에 직접 값을 쓸 수 있습니다. 이때 `cookie`는 데이터 프로퍼티가 아닌 접근자 프로퍼티입니다. 앞서 <info:property-accessors>에서 학습한 바와 같이, 접근자 프로퍼티에 값을 할당하는 것은 데이터 프로퍼티에 값을 할당하는 것과는 조금 다르게 처리됩니다.
 
 **`document.cookie`에 값을 할당하면, 브라우저는 이 값을 받아 해당 쿠키를 갱신합니다. 이때, 다른 쿠키의 값은 변경되지 않습니다.**
-=======
-We can write to `document.cookie`. But it's not a data property, it's an [accessor (getter/setter)](info:property-accessors). An assignment to it is treated specially.
-
-**A write operation to `document.cookie` updates only the cookie mentioned in it and doesn't touch other cookies.**
->>>>>>> upstream/master
 
 아래와 같이 코드를 작성하면 이름이 `user`인 쿠키를 찾아 그 값을 `John`으로 갱신합니다.
 
@@ -80,21 +50,12 @@ document.cookie = "user=John"; // 이름이 'user'인 쿠키의 값만 갱신함
 alert(document.cookie); // 모든 쿠키 보여주기
 ```
 
-<<<<<<< HEAD
 코드를 실행하면 여러 개의 쿠키가 출력되는 것을 확인할 수 있습니다. 이를 통해 `document.cookie=` 연산은 모든 쿠키를 덮어쓰지 않고, 명시된 쿠키인 `user`의 값만 갱신한 것을 알 수 있습니다.
 
 쿠키의 이름과 값엔 특별한 제약이 없기 때문에 모든 글자가 허용됩니다. 하지만 형식의 유효성을 일관성 있게 유지하기 위해 반드시 내장 함수 `encodeURIComponent`를 사용하여 이름과 값을 이스케이프 처리해 줘야 합니다.
 
 ```js run
-// 특수 값(공백)은 인코딩 처리해 줘야 합니다.
-=======
-If you run it, you will likely see multiple cookies. That's because the `document.cookie=` operation does not overwrite all cookies. It only sets the mentioned cookie `user`.
-
-Technically, name and value can have any characters. To keep the valid formatting, they should be escaped using a built-in `encodeURIComponent` function:
-
-```js run
-// special characters (spaces) need encoding
->>>>>>> upstream/master
+// 공백 같은 특수 값은 인코딩 처리해 줘야 합니다.
 let name = "my name";
 let value = "John Smith"
 
@@ -105,9 +66,9 @@ alert(document.cookie); // ...; my%20name=John%20Smith
 ```
 
 
-<<<<<<< HEAD
 ```warn header="쿠키의 한계"
 쿠키엔 몇 가지 제약 사항이 있습니다.
+- `document.cookie`를 사용하면 한 번에 쿠키 하나만 설정하거나 갱신할 수 있습니다.
 - `encodeURIComponent`로 인코딩한 이후의 `name=value` 쌍은 4KB를 넘을 수 없습니다. 이 용량을 넘는 정보는 쿠키에 저장할 수 없습니다.
 - 도메인 하나당 저장할 수 있는 쿠키의 개수는 20여 개 정도로 한정되어 있습니다. 개수는 브라우저에 따라 조금씩 다릅니다.
 ```
@@ -115,95 +76,43 @@ alert(document.cookie); // ...; my%20name=John%20Smith
 쿠키엔 몇 가지 옵션이 있습니다. 몇몇 옵션은 아주 중요하기 때문에 꼭 지정해 줘야 합니다.
 
 옵션은 `key=value` 뒤에 나열하고 `;`로 구분합니다. 아래와 같이 말이죠.
-=======
-```warn header="Limitations"
-There are a few limitations:
-- You can only set/update a single cookie at a time using `document.cookie`.
-- The `name=value` pair, after `encodeURIComponent`, should not exceed 4KB. So we can't store anything huge in a cookie.
-- The total number of cookies per domain is limited to around 20+, the exact limit depends on the browser.
-```
-
-Cookies have several attributes, many of which are important and should be set.
-
-The attributes are listed after `key=value`, delimited by `;`, like this:
->>>>>>> upstream/master
 
 ```js run
 document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"
 ```
 
-<<<<<<< HEAD
-## path
-
-- **`path=/mypath`**
-
-URL path(경로)의 접두사로, 이 경로나 이 경로의 하위 경로에 있는 페이지만 쿠키에 접근할 수 있습니다. 절대 경로이어야 하고, (미 지정시) 기본값은 현재 경로입니다.
-
-`path=/admin` 옵션을 사용하여 설정한 쿠키는 `/admin`과 `/admin/something`에선 볼 수 있지만, `/home` 이나 `/adminpage`에선 볼 수 없습니다.
-
-특별한 경우가 아니라면, `path` 옵션을 `path=/`같이 루트로 설정해 웹사이트의 모든 페이지에서 쿠키에 접근할 수 있도록 합시다.
-
-=======
->>>>>>> upstream/master
 ## domain
 
 - **`domain=site.com`**
 
-<<<<<<< HEAD
-쿠키에 접근 가능한 domain(도메인)을 지정합니다. 다만, 몇 가지 제약이 있어서 아무 도메인이나 지정할 수 없습니다. 
+쿠키에 접근 가능한 `domain`을 지정합니다. 다만, 몇 가지 제약이 있어서 아무 도메인이나 지정할 수 없습니다.
+
+**다른 2단계 도메인에서 쿠키에 접근하게 할 방법은 없습니다. 따라서 `other.com`은 `site.com`에서 설정한 쿠키를 절대 받지 못합니다.**
 
-`domain` 옵션에 아무 값도 넣지 않았다면, 쿠키를 설정한 도메인에서만 쿠키에 접근할 수 있습니다. `site.com`에서 설정한 쿠키는 `other.com`에서 얻을 수 없죠.
+이런 제약사항은 안전성을 높이기 위해 만들어졌습니다. 민감한 데이터가 저장된 쿠키는 관련 페이지에서만 볼 수 있도록 하기 위해서 말이죠.
 
-이 외에 까다로운 제약사항이 하나 더 있습니다. 서브 도메인(subdomain)인 `forum.site.com`에서도 쿠키 정보를 얻을 수 없다는 점입니다.
+기본적으로 쿠키는 쿠키를 설정한 도메인에서만 접근할 수 있습니다.
+
+기본적으로 쿠키는 `forum.site.com` 같은 서브 도메인과 공유되지 않는다는 점에 유의하세요.
 
 ```js
 // site.com에서 쿠키를 설정함
 document.cookie = "user=John"
 
-// site.com의 서브도메인인 forum.site.com에서 user 쿠키에 접근하려 함
+// site.com의 서브 도메인인 forum.site.com에서 user 쿠키에 접근하려 함
 alert(document.cookie); // 찾을 수 없음
 ```
-=======
-A domain defines where the cookie is accessible. In practice though, there are limitations. We can't set any domain.
->>>>>>> upstream/master
 
-**서브 도메인이나 다른 도메인에서 쿠키에 접속할 방법은 없습니다. `site.com`에서 생성한 쿠키를 `other.com`에선 절대 전송받을 수 없습니다.**
+...하지만 변경할 수 있습니다. `forum.site.com` 같은 서브 도메인이 `site.com`에서 설정한 쿠키를 가져오도록 허용하고 싶다면 가능합니다.
 
-<<<<<<< HEAD
-이런 제약사항은 안정성을 높이기 위해 만들어졌습니다. 민감한 데이터가 저장된 쿠키는 관련 페이지에서만 볼 수 있도록 하기 위해서 말이죠.
+그렇게 하려면 `site.com`에서 쿠키를 설정할 때 `domain` 속성을 루트 도메인인 `domain=site.com`으로 명시적으로 설정해야 합니다. 그러면 모든 서브 도메인에서 해당 쿠키를 볼 수 있습니다.
 
-그런데 정말 `forum.site.com`과 같은 서브 도메인에서 `site.com`에서 생성한 쿠키 정보를 얻을 방법이 없는 걸까요? 방법이 있습니다. `site.com`에서 쿠키를 설정할 때 `domain` 옵션에 루트 도메인인 `domain=site.com`을 명시적으로 설정해 주면 되죠. 
+예를 들어:
 
 ```js
 // site.com에서
-// 서브 도메인(*.site.com) 어디서든 쿠키에 접속하게 설정할 수 있습니다.
-document.cookie = "user=John; domain=site.com"
-=======
-It's a safety restriction, to allow us to store sensitive data in cookies that should be available only on one site.
-
-By default, a cookie is accessible only at the domain that set it.
-
-Please note, by default, a cookie is not shared with a subdomain, such as `forum.site.com`.
-
-```js
-// if we set a cookie at site.com website...
-document.cookie = "user=John"
-
-// ...we won't see it at forum.site.com
-alert(document.cookie); // no user
-```
-
-...But this can be changed. If we'd like to allow subdomains like `forum.site.com` to get a cookie set at `site.com`, that's possible.
-
-For that to happen, when setting a cookie at `site.com`, we should explicitly set the `domain` attribute to the root domain: `domain=site.com`. Then all subdomains will see such a cookie.
-
-For example:
-
-```js
-// at site.com
-// make the cookie accessible on any subdomain *.site.com:
+// 서브 도메인 *.site.com 어디서든 쿠키에 접근할 수 있게 합니다.
 document.cookie = "user=John; *!*domain=site.com*/!*"
->>>>>>> upstream/master
 
 // 이렇게 설정하면
 
@@ -211,51 +120,33 @@ document.cookie = "user=John; *!*domain=site.com*/!*"
 alert(document.cookie); // user=John 쿠키를 확인할 수 있습니다.
 ```
 
-<<<<<<< HEAD
-하위 호환성 유지를 위해 (`site.com` 앞에 점을 붙인) `domain=.site.com`도 `domain=site.com`과 동일하게 작동합니다. 오래된 표기법이긴 하지만 구식 브라우저를 지원하려면 이 표기법을 사용하는 것이 좋습니다. 
-
-이렇게 `domain` 옵션값을 적절히 사용하면 서브 도메인에서도 쿠키에 접근할 수 있습니다.
-=======
-```warn header="Legacy syntax"
-Historically, `domain=.site.com` (with a dot before `site.com`) used to work the same way, allowing access to the cookie from subdomains. Leading dots in domain names are now ignored, but some browsers may decline to set the cookie containing such dots.
+```warn header="레거시 문법"
+예전에는 (`site.com` 앞에 점을 붙인) `domain=.site.com`도 `domain=site.com`과 동일하게 동작해 서브 도메인에서 쿠키에 접근할 수 있게 했습니다. 이제 도메인 이름 앞의 점은 무시되지만, 일부 브라우저는 이런 점이 포함된 쿠키 설정을 거부할 수 있습니다.
 ```
 
-To summarize, the `domain` attribute allows to make a cookie accessible at subdomains.
+이렇게 `domain` 옵션값을 적절히 사용하면 서브 도메인에서도 쿠키에 접근할 수 있습니다.
 
 ## path
 
 - **`path=/mypath`**
 
-The URL path prefix must be absolute. It makes the cookie accessible for pages under that path. By default, it's the current path.
+URL 경로의 접두사입니다. 이 경로나 이 경로의 하위 경로에 있는 페이지만 쿠키에 접근할 수 있습니다. 절대 경로이어야 하고, 미지정 시 기본값은 현재 경로입니다.
 
-If a cookie is set with `path=/admin`, it's visible on pages `/admin` and `/admin/something`, but not at `/home`, `/home/admin` or `/`.
+`path=/admin` 옵션을 사용하여 설정한 쿠키는 `/admin`과 `/admin/something`에선 볼 수 있지만, `/home`, `/home/admin`, `/`에선 볼 수 없습니다.
 
-Usually, we should set `path` to the root: `path=/` to make the cookie accessible from all website pages. If this attribute is not set the default is calculated using [this method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#path_default_value).
->>>>>>> upstream/master
+특별한 경우가 아니라면, `path` 옵션을 `path=/`같이 루트로 설정해 웹사이트의 모든 페이지에서 쿠키에 접근할 수 있도록 합시다. 이 속성을 설정하지 않으면 기본값은 [이 방식](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#path_default_value)에 따라 계산됩니다.
 
 ## expires와 max-age
 
-<<<<<<< HEAD
-expires(유효 일자)나 max-age(만료 기간) 옵션이 지정되어있지 않으면, 브라우저가 닫힐 때 쿠키도 함께 삭제됩니다. 이런 쿠키를 "세션 쿠키(session cookie)"라고 부릅니다.
+`expires`나 `max-age` 옵션이 지정되어 있지 않으면, 브라우저나 탭이 닫힐 때 쿠키도 함께 삭제됩니다. 이런 쿠키를 "세션 쿠키"라고 부릅니다.
 
-`expires` 나 `max-age` 옵션을 설정하면 브라우저를 닫아도 쿠키가 삭제되지 않습니다.
+브라우저를 닫아도 쿠키가 살아남게 하려면 `expires`나 `max-age` 속성을 설정하면 됩니다. 둘 다 설정되어 있다면 `max-age`가 우선합니다.
 
 - **`expires=Tue, 19 Jan 2038 03:14:07 GMT`**
 
 브라우저는 설정된 유효 일자까지 쿠키를 유지하다가, 해당 일자가 도달하면 쿠키를 자동으로 삭제합니다.
 
-쿠키의 유효 일자는 반드시 GMT(Greenwich Mean Time) 포맷으로 설정해야 합니다. `date.toUTCString`을 사용하면 해당 포맷으로 쉽게 변경할 수 있습니다. 아래는 유효 기간이 하루인 쿠키를 만드는 예시입니다.
-=======
-By default, if a cookie doesn't have one of these attributes, it disappears when the browser/tab is closed. Such cookies are called "session cookies"
-
-To let cookies survive a browser close, we can set either the `expires` or `max-age` attribute. `max-Age` has precedence if both are set.
-
-- **`expires=Tue, 19 Jan 2038 03:14:07 GMT`**
-
-The cookie expiration date defines the time when the browser will automatically delete it (according to the browser's time zone).
-
-The date must be exactly in this format, in the GMT timezone. We can use `date.toUTCString` to get it. For instance, we can set the cookie to expire in 1 day:
->>>>>>> upstream/master
+쿠키의 유효 일자는 반드시 GMT 포맷으로 설정해야 합니다. `date.toUTCString`을 사용하면 해당 포맷으로 쉽게 변경할 수 있습니다. 아래는 유효 기간이 하루인 쿠키를 만드는 예시입니다.
 
 ```js
 // 지금으로부터 하루 후
@@ -266,23 +157,14 @@ document.cookie = "user=John; expires=" + date;
 
 `expires` 옵션값을 과거로 지정하면 쿠키는 삭제됩니다.
 
--  **`max-age=3600`**
+- **`max-age=3600`**
 
-<<<<<<< HEAD
 `max-age`는 `expires` 옵션의 대안으로, 쿠키 만료 기간을 설정할 수 있게 해줍니다. 현재부터 설정하고자 하는 만료일시까지의 시간을 초로 환산한 값을 설정합니다.
 
 0이나 음수값을 설정하면 쿠키는 바로 삭제됩니다.
 
 ```js
 // 1시간 뒤에 쿠키가 삭제됩니다.
-=======
-It's an alternative to `expires` and specifies the cookie's expiration in seconds from the current moment.
-
-If set to zero or a negative value, the cookie is deleted:
-
-```js
-// cookie will die in +1 hour from now
->>>>>>> upstream/master
 document.cookie = "user=John; max-age=3600";
 
 // 만료 기간을 0으로 지정하여 쿠키를 바로 삭제함
@@ -295,155 +177,91 @@ document.cookie = "user=John; max-age=0";
 
 이 옵션을 설정하면 HTTPS로 통신하는 경우에만 쿠키가 전송됩니다.
 
-**`secure` 옵션이 없으면 기본 설정이 적용되어 `http://site.com`에서 설정(생성)한 쿠키를 `https://site.com`에서 읽을 수 있고, `https://site.com`에서 설정(생성)한 쿠키도 `http://site.com`에서 읽을 수 있습니다.**
+**`secure` 옵션이 없으면 기본 설정이 적용되어 `http://site.com`에서 설정한 쿠키를 `https://site.com`에서 읽을 수 있고, `https://site.com`에서 설정한 쿠키도 `http://site.com`에서 읽을 수 있습니다.**
 
 쿠키는 기본적으로 도메인만 확인하지 프로토콜을 따지진 않기 때문입니다.
 
-<<<<<<< HEAD
 하지만 `secure` 옵션이 설정된 경우, `https://site.com`에서 설정한 쿠키는 `http://site.com`에서 접근할 수 없습니다. 쿠키에 민감한 내용이 저장되어 있어 암호화되지 않은 HTTP 연결을 통해 전달되는 걸 원치 않는다면 이 옵션을 사용하면 됩니다.
 
 ```js
-// (https:// 로 통신하고 있다고 가정 중)
+// https:// 로 통신하고 있다고 가정 중
 // 설정한 쿠키는 HTTPS 통신시에만 접근할 수 있음
-=======
-With this attribute, if a cookie is set by `https://site.com`, then it doesn't appear when the same site is accessed by HTTP, as `http://site.com`. So if a cookie has sensitive content that should never be sent over unencrypted HTTP, the `secure` flag is the right thing.
-
-```js
-// assuming we're on https:// now
-// set the cookie to be secure (only accessible over HTTPS)
->>>>>>> upstream/master
 document.cookie = "user=John; secure";
 ```
 
 ## samesite
 
-<<<<<<< HEAD
 또 다른 보안 속성인 `samesite` 옵션은 크로스 사이트 요청 위조(cross-site request forgery, XSRF) 공격을 막기 위해 만들어진 옵션입니다.
-=======
-This is another security attribute `samesite`. It's designed to protect from so-called XSRF (cross-site request forgery) attacks.
->>>>>>> upstream/master
 
 아래 XSRF 공격 시나리오를 통해 이 속성의 동작 방식과 언제 이 속성을 유용하게 사용할 수 있는지 알아보도록 합시다.
 
 ### XSRF 공격
 
-<<<<<<< HEAD
-현재 `bank.com`에 로그인되어있다고 가정해 봅시다. 해당 사이트에서 사용되는 인증 쿠키가 브라우저에 저장되고, 브라우저는 `bank.com`에 요청을 보낼 때마다 인증 쿠키를 함께 전송할 것입니다. 서버는 전송받은 쿠키를 이용해 사용자를 식별하고, 보안이 필요한 재정 거래를 처리합니다.
-=======
-Imagine, you are logged into the site `bank.com`. That is: you have an authentication cookie from that site. Your browser sends it to `bank.com` with every request so that it recognizes you and performs all sensitive financial operations.
->>>>>>> upstream/master
+현재 `bank.com`에 로그인되어 있다고 가정해 봅시다. 해당 사이트에서 사용되는 인증 쿠키가 브라우저에 저장되고, 브라우저는 `bank.com`에 요청을 보낼 때마다 인증 쿠키를 함께 전송할 것입니다. 서버는 전송받은 쿠키를 이용해 사용자를 식별하고, 보안이 필요한 재정 거래를 처리합니다.
 
-이제 (로그아웃하지 않고) 다른 창을 띄워서 웹 서핑을 하던 도중에 뜻하지 않게 `evil.com`에 접속했다 가정해 봅시다. 이 사이트엔 해커에게 송금을 요청하는 폼(form) `<form action="https://bank.com/pay">`이 있고, 이 폼은 자동으로 제출되도록 설정되어 있습니다. 
+이제 로그아웃하지 않고 다른 창을 띄워서 웹 서핑을 하던 도중에 뜻하지 않게 `evil.com`에 접속했다 가정해 봅시다. 이 사이트엔 해커에게 송금을 요청하는 폼 `<form action="https://bank.com/pay">`이 있고, 이 폼은 자동으로 제출되도록 설정되어 있습니다.
 
-<<<<<<< HEAD
-폼이 `evil.com`에서 은행 사이트로 바로 전송될 때 인증 쿠키도 함께 전송됩니다. `bank.com`에 요청을 보낼 때마다 `bank.com`에서 설정한 쿠키가 전송되기 때문입니다. 은행은 전송받은 쿠키를 읽어 (해커가 아닌) 계정 주인이 접속한 것이라 생각하고 해커에게 돈을 송금합니다.
+폼이 `evil.com`에서 은행 사이트로 바로 전송될 때 인증 쿠키도 함께 전송됩니다. `bank.com`에 요청을 보낼 때마다 `bank.com`에서 설정한 쿠키가 전송되기 때문입니다. 은행은 전송받은 쿠키를 읽어 해커가 아니라 계정 주인이 접속한 것이라 생각하고 해커에게 돈을 송금합니다.
 
 ![](cookie-xsrf.svg)
 
 이런 공격을 크로스 사이트 요청 위조라고 부릅니다.
 
-실제 은행은 당연히 이 공격을 막을 수 있도록 시스템을 설계합니다. `bank.com`에서 사용하는 모든 폼에 "XSRF 보호 토큰(protection token)"이라는 특수 필드를 넣어서 말이죠. 이 토큰은 악의적인 페이지에서 만들 수 없고, 원격 페이지에서도 훔쳐 올 수 없도록 구현되어 있습니다. 따라서 악의적인 페이지에서 폼을 전송하더라도 보호 토큰이 없거나 서버에 저장된 값과 일치하지 않기 때문에 요청이 무용지물이 됩니다.
+실제 은행은 당연히 이 공격을 막을 수 있도록 시스템을 설계합니다. `bank.com`에서 사용하는 모든 폼에 "XSRF 보호 토큰"이라는 특수 필드를 넣어서 말이죠. 이 토큰은 악의적인 페이지에서 만들 수 없고, 원격 페이지에서도 훔쳐 올 수 없도록 구현되어 있습니다. 따라서 악의적인 페이지에서 폼을 전송하더라도 보호 토큰이 없거나 서버에 저장된 값과 일치하지 않기 때문에 요청이 무용지물이 됩니다.
 
 하지만 이런 절차는 구현에 시간이 걸린다는 단점을 수반합니다. 모든 폼에 보호 토큰을 세팅해줘야 하죠. 또한 요청 전부를 검수해야 합니다. 
 
 ### samesite 옵션
 
-쿠키의 `samesite` 옵션을 이용하면 "XSRF 보호 토큰" 없이도 (이론상으로) 크로스 사이트 요청 위조를 막을 수 있습니다.
-=======
-The browser sends cookies every time you visit the site `bank.com`, even if the form was submitted from `evil.com`. So the bank recognizes you and performs the payment.
-
-![](cookie-xsrf.svg)
-
-This is a so-called "Cross-Site Request Forgery" (in short, XSRF) attack.
-
-Real banks are protected from it of course. All forms generated by `bank.com` have a special field, a so-called "XSRF protection token", that an evil page can't generate or extract from a remote page. It can submit a form there, but can't get the data back. The site `bank.com` checks for such a token in every form it receives.
-
-Such a protection takes time to implement though. We need to ensure that every form has the required token field, and we must also check all requests.
-
-### Use cookie samesite attribute
-
-The cookie `samesite` attribute provides another way to protect from such attacks, that (in theory) should not require "xsrf protection tokens".
->>>>>>> upstream/master
+쿠키의 `samesite` 옵션을 이용하면 이론상 "XSRF 보호 토큰" 없이도 크로스 사이트 요청 위조를 막을 수 있습니다.
 
 이 옵션엔 두 가지 값을 설정할 수 있습니다.
 
-<<<<<<< HEAD
-- **`samesite=strict`(값을 설정하지 않고 그냥 `samesite` 옵션만 써줘도 동일하게 동작함)**
-=======
 - **`samesite=strict`**
->>>>>>> upstream/master
 
 사용자가 사이트 외부에서 요청을 보낼 때, `samesite=strict` 옵션이 있는 쿠키는 절대로 전송되지 않습니다. 
 
-<<<<<<< HEAD
 메일에 있는 링크를 따라 접속하거나 `evil.com`과 같은 사이트에서 폼을 전송하는 경우 등과 같이 제3의 도메인에서 요청이 이뤄질 땐 쿠키가 전송되지 않죠.
 
 인증 쿠키에 `samesite` 옵션이 있는 경우, XSRF 공격은 절대로 성공하지 못합니다. `evil.com`에서 전송하는 요청엔 쿠키가 없을 것이고, `bank.com`은 미인식 사용자에게 지급을 허용하지 않을 것이기 때문입니다.
 
-이 보호장치는 꽤 믿을 만합니다. `bank.com`에서 수행하는 모든 작업은 samesite 쿠키를 함께 전송하기 때문이죠.
-=======
-In other words, whether a user follows a link from their email, submits a form from `evil.com`, or does any operation that originates from another domain, the cookie is not sent.
-
-If authentication cookies have the `samesite=strict` attribute, then an XSRF attack has no chance of succeeding, because a submission from `evil.com` comes without cookies. So `bank.com` will not recognize the user and will not proceed with the payment.
-
-The protection is quite reliable. Only operations that come from `bank.com` will send the `samesite=strict` cookie, e.g. a form submission from another page at `bank.com`.
->>>>>>> upstream/master
+이 보호장치는 꽤 믿을 만합니다. `bank.com`에서 수행하는 모든 작업은 `samesite=strict` 쿠키를 함께 전송하기 때문이죠.
 
 하지만 약간의 불편함도 감수해야 합니다.
 
-<<<<<<< HEAD
 만약 사용자가 메모장 등에 `bank.com`에 요청을 보낼 수 있는 링크를 기록해 놓았다가 이 링크를 클릭해 접속하면 `bank.com`이 사용자를 인식하지 못하는 상황이 발생하기 때문입니다. 실제로 이런 경우 `samesite=strict` 옵션이 설정된 쿠키는 전송되지 않습니다.
 
-이런 문제는 쿠키 두 개를 함께 사용해 해결할 수 있습니다. "Hello, John"과 같은 환영 메시지를 출력해주는 "일반 인증(general recognition)"용 쿠키, 데이터 교환 시 사용하는 `samesite=strict` 옵션이 있는 쿠키를 따로 둬서 말이죠. 이렇게 하면 외부 사이트를 통해 접근한 사용자도 정상적으로 환영 메시지를 볼 수 있습니다. 지급은 무조건 은행의 사이트를 통해서만 수행되도록 만들면 됩니다.
-=======
-When a user follows a legitimate link to `bank.com`, like from their notes, they'll be surprised that `bank.com` does not recognize them. Indeed, `samesite=strict` cookies are not sent in that case.
-
-We could work around that by using two cookies: one for "general recognition", only to say: "Hello, John", and the other one for data-changing operations with `samesite=strict`. Then, a person coming from outside of the site will see a welcome, but payments must be initiated from the bank's website, for the second cookie to be sent.
->>>>>>> upstream/master
+이런 문제는 쿠키 두 개를 함께 사용해 해결할 수 있습니다. "Hello, John"과 같은 환영 메시지를 출력해주는 "일반 인증"용 쿠키와 데이터 교환 시 사용하는 `samesite=strict` 옵션이 있는 쿠키를 따로 둬서 말이죠. 이렇게 하면 외부 사이트를 통해 접근한 사용자도 정상적으로 환영 메시지를 볼 수 있습니다. 결제는 무조건 은행의 사이트를 통해서만 수행되도록 만들면 됩니다.
 
-- **`samesite=lax` (same as `samesite` without value)**
+- **`samesite=lax` (값 없이 `samesite`만 쓴 경우와 동일합니다)**
 
-<<<<<<< HEAD
 `samesite=lax`는 사용자 경험을 해치지 않으면서 XSRF 공격을 막을 수 있는 느슨한 접근법입니다.
-=======
-A more relaxed approach that also protects from XSRF and doesn't break the user experience.
->>>>>>> upstream/master
 
 `strict`와 마찬가지로 `lax`도 사이트 외부에서 요청을 보낼 때 브라우저가 쿠키를 보내는 걸 막아줍니다. 하지만 예외사항이 존재합니다. 
 
 아래 두 조건을 동시에 만족할 때는 `samesite=lax` 옵션을 설정한 쿠키가 전송됩니다.
-1. "안전한" HTTP 메서드인 경우(예: GET 방식. POST 방식은 해당하지 않음). 
+1. "안전한" HTTP 메서드인 경우입니다. 예를 들어 GET 방식은 해당하지만, POST 방식은 해당하지 않습니다.
 
-<<<<<<< HEAD
-    안전한 HTTP 메서드 목록은 [RFC7231 명세](https://tools.ietf.org/html/rfc7231)에서 확인할 수 있습니다. 안전한 메서드는 읽기 작업만 수행하고 쓰기나 데이터 교환 작업은 수행하지 않습니다. 참고로, 링크를 따라가는 행위는 항상 GET 방식이기 때문에 안전한 메서드만 쓰입니다. 
-    
-2. 작업이 최상위 레벨 탐색에서 이루어질 때(브라우저 주소창에서 URL을 변경하는 경우).
+    안전한 HTTP 메서드 목록은 [RFC7231 명세](https://tools.ietf.org/html/rfc7231)에서 확인할 수 있습니다. 안전한 메서드는 읽기 작업만 수행하고 쓰기나 데이터 교환 작업은 수행하지 않습니다. 참고로, 링크를 따라가는 행위는 항상 GET 방식이기 때문에 안전한 메서드만 쓰입니다.
+
+2. 작업이 최상위 레벨 탐색에서 이루어질 때입니다. 브라우저 주소창에서 URL을 변경하는 경우가 여기에 해당합니다.
 
     대다수의 작업은 이 조건을 충족합니다. 하지만 `<iframe>`안에서 탐색이 일어나는 경우는 최상위 레벨 탐색이 아니기 때문에 이 조건을 충족하지 못합니다. AJAX 요청 또한 탐색 행위가 아니므로 이 조건을 충족하지 못합니다.
-    
+
 브라우저를 이용해 자주 하는 작업인 "특정 URL로 이동하기"를 실행하는 경우, `samesite=lax` 옵션이 설정되어 있으면 쿠키가 서버로 전송됩니다. 노트에 저장된 링크를 여는 것도 특정 URL로 이동하는 행위이므로 위 조건들을 충족합니다.
 
 하지만 외부 사이트에서 AJAX 요청을 보내거나 폼을 전송하는 등의 복잡한 작업을 시도할 때는 쿠키가 전송되지 않습니다.
 
 이런 제약사항이 있어도 괜찮다면, `samesite=lax` 옵션은 사용자 경험을 해치지 않으면서 보안을 강화해주는 방법으로 활용할 수 있을 것입니다.
 
-`samesite`는 좋은 옵션이긴 하지만, 한가지 문제점이 있습니다.
-- 오래된 브라우저(2017년 이전 버전)에선 `samesite` 옵션을 지원하지 않습니다.
-=======
-    The full list of safe HTTP methods is in the [RFC7231 specification](https://tools.ietf.org/html/rfc7231#section-4.2.1). These are the methods that should be used for reading, but not writing the data. They must not perform any data-changing operations. Following a link is always GET, the safe method.
-
-2. The operation performs a top-level navigation (changes URL in the browser address bar).
+전반적으로 `samesite`는 좋은 옵션입니다.
 
-    This is usually true, but if the navigation is performed in an `<iframe>`, then it is not top-level. Additionally, JavaScript methods for network requests do not perform any navigation.
+그러나 한 가지 단점이 있습니다.
 
-So, what `samesite=lax` does, is to allow the most common "go to URL" operation to have cookies. E.g. opening a website link from notes that satisfy these conditions.
-
-But anything more complicated, like a network request from another site or a form submission, loses cookies.
->>>>>>> upstream/master
+- 오래된 브라우저(2017년 이전 버전)에선 `samesite` 옵션을 지원하지 않습니다.
 
 **따라서 `samesite` 옵션으로만 보안 처리를 하게 되면, 구식 브라우저에서 보안 문제가 발생할 수 있습니다.**
 
-<<<<<<< HEAD
 구식 브라우저에 대응하지 못한다는 문제가 있긴 하지만, `samesite` 옵션을 XSRF 토큰 같은 다른 보안 기법과 함께 사용하면 보안을 강화할 수 있습니다. 구식 브라우저를 더는 사용하지 않는 때가 오면 XSRF 토큰 역시 필요하지 않겠죠.
 
 ## httpOnly
@@ -458,30 +276,6 @@ But anything more complicated, like a network request from another site or a for
 
 
 이런 상황이 만에 하나 발생하면, 사용자가 웹 페이지에 방문할 때 `document.cookie`를 볼 수 있고 조작도 할 수 있는 해커의 코드도 함께 실행됩니다. 물론 쿠키엔 인증 정보가 있어서 해커가 이 정보를 훔치거나 조작할 수 있게 됩니다. 좋지 않은 상황이 발생하죠.
-=======
-Overall, `samesite` is a great attribute.
-
-There's a drawback:
-
-- `samesite` is ignored (not supported) by very old browsers, the year 2017 or so.
-
-**So if we solely rely on `samesite` to provide protection, then old browsers will be vulnerable.**
-
-But we can use `samesite` together with other protection measures, like xsrf tokens, to add a layer of defence and then, in the future, when old browsers die out, we'll probably be able to drop xsrf tokens.
-
-## httpOnly
-
-This attribute has nothing to do with JavaScript, but we have to mention it for completeness.
-
-The web server uses the `Set-Cookie` header to set a cookie. Also, it may set the `httpOnly` attribute.
-
-This attribute forbids any JavaScript access to the cookie. We can't see such a cookie or manipulate it using `document.cookie`.
-
-This is used as a precautionary measure, to protect from certain attacks when a hacker injects his own JavaScript code into a page and waits for a user to visit that page. That shouldn't be possible at all, hackers should not be able to inject their code into our site, but there may be bugs that let them do it.
-
-
-Normally, if such a thing happens, and a user visits a web-page with a hacker's JavaScript code, then that code executes and gains access to `document.cookie` with user cookies containing authentication information. That's bad.
->>>>>>> upstream/master
 
 하지만 `httpOnly` 옵션이 설정된 쿠키는 `document.cookie`로 쿠키 정보를 읽을 수 없기 때문에 쿠키를 보호할 수 있습니다.
 
@@ -493,11 +287,7 @@ Normally, if such a thing happens, and a user visits a web-page with a hacker's
 
 ### getCookie(name)
 
-<<<<<<< HEAD
-쿠키에 접근하는 가장 짧은 방법은 [정규 표현식(regular expression)](info:regular-expressions) 을 사용하는 것입니다.
-=======
-The shortest way to access a cookie is to use a [regular expression](info:regular-expressions).
->>>>>>> upstream/master
+쿠키에 접근하는 가장 짧은 방법은 [정규 표현식](info:regular-expressions)을 사용하는 것입니다.
 
 아래 `getCookie(name)` 함수는 주어진 `name`의 쿠키를 반환합니다.
 
@@ -514,28 +304,19 @@ function getCookie(name) {
 
 위 코드에서 `new RegExp`는 `; name=<value>` 패턴을 찾기 위해 동적으로 생성됩니다.
 
-주의할 점은 쿠키값은 인코딩되어있는 상태이기 때문에 `getCookie`는 내장 함수인 `decodeURIComponent`를 이용해 쿠키값을 디코딩한다는 점입니다.
+주의할 점은 쿠키값은 인코딩되어 있는 상태이기 때문에 `getCookie`는 내장 함수인 `decodeURIComponent`를 이용해 쿠키값을 디코딩한다는 점입니다.
 
 ### setCookie(name, value, attributes)
 
-<<<<<<< HEAD
-현재 경로(`path=/`)를 기본으로, 주어진 `name`과 `value`를 가진 쿠키를 설정합니다(다른 기본값을 추가할 수 있습니다).
-=======
-Sets the cookie's `name` to the given `value` with `path=/` by default (can be modified to add other defaults):
->>>>>>> upstream/master
+현재 경로(`path=/`)를 기본으로, 주어진 `name`과 `value`를 가진 쿠키를 설정합니다. 다른 기본값을 추가할 수도 있습니다.
 
 ```js run
 function setCookie(name, value, attributes = {}) {
 
   attributes = {
     path: '/',
-<<<<<<< HEAD
     // 필요한 경우, 옵션 기본값을 설정할 수도 있습니다.
-    ...options
-=======
-    // add other defaults here if necessary
     ...attributes
->>>>>>> upstream/master
   };
 
   if (attributes.expires instanceof Date) {
@@ -555,7 +336,7 @@ function setCookie(name, value, attributes = {}) {
   document.cookie = updatedCookie;
 }
 
-// Example of use:
+// 사용 예시:
 setCookie('user', 'John', {secure: true, 'max-age': 3600});
 ```
 
@@ -571,13 +352,8 @@ function deleteCookie(name) {
 }
 ```
 
-<<<<<<< HEAD
-```warn header="갱신이나 삭제는 동일한 도메인과 경로에서만 해야 합니다."
-주의: 쿠키를 갱신하거나 삭제할 때는, 쿠키를 설정할 때 지정했던 도메인이나 경로를 사용해야 합니다. 
-=======
-```warn header="Updating or deleting must use same path and domain"
-Please note: when we update or delete a cookie, we should use exactly the same path and domain attributes as when we set it.
->>>>>>> upstream/master
+```warn header="갱신이나 삭제 시 같은 경로와 도메인을 사용해야 합니다."
+주의: 쿠키를 갱신하거나 삭제할 때는 쿠키를 설정할 때 지정했던 것과 정확히 같은 `path`와 `domain` 속성을 사용해야 합니다.
 ```
 
 함께 보면 좋은 자료: [cookie.js](cookie.js)
@@ -585,19 +361,11 @@ Please note: when we update or delete a cookie, we should use exactly the same p
 
 ## 부록: 서드 파티 쿠키
 
-<<<<<<< HEAD
-사용자가 방문 중인 도메인이 아닌 다른 도메인에서 설정한 쿠키를 "서드 파티 쿠키(third-party cookie)"라고 부릅니다. 
+사용자가 방문 중인 도메인이 아닌 다른 도메인에서 설정한 쿠키를 "서드 파티 쿠키"라고 부릅니다.
 
 예시:
-1. `site.com`의 특정 페이지에서 이미지 배너(banner)를 불러옵니다. 배너는 다른 도메인 `<img src="https://ads.com/banner.png">` 에서 가져옵니다.
+1. `site.com`의 특정 페이지에서 다른 사이트의 이미지 배너를 불러옵니다. 예를 들어 `<img src="https://ads.com/banner.png">`와 같이 말이죠.
 2. `ads.com`에 있는 원격 서버는 배너와 함께 `Set-Cookie` 헤더를 전송해 브라우저가 `id=1234`와 같은 쿠키를 설정하도록 합니다. 이 쿠키는 `ads.com` 도메인에서 설정한 것이기 때문에 `ads.com`에서만 볼 수 있습니다.
-=======
-A cookie is called "third-party" if it's placed by a domain other than the page the user is visiting.
-
-For instance:
-1. A page at `site.com` loads a banner from another site: `<img src="https://ads.com/banner.png">`.
-2. Along with the banner, the remote server at `ads.com` may set the `Set-Cookie` header with a cookie like `id=1234`. Such a cookie originates from the `ads.com` domain, and will only be visible at `ads.com`:
->>>>>>> upstream/master
 
     ![](cookie-third-party.svg)
 
@@ -605,59 +373,39 @@ For instance:
 
     ![](cookie-third-party-2.svg)
 
-<<<<<<< HEAD
 4. 사용자가 `site.com`을 떠나 `other.com`에 접속하고 이 사이트에도 배너가 있으면 `ads.com`은 또 쿠키를 전송받습니다. 이 쿠키는 `ads.com`에서 설정한 것이기 때문이죠. 이를 이용해 `ads.com`은 사용자를 인식하고, 이 사용자가 어떤 사이트로 이동했는지를 추적합니다.
-=======
-4. What's even more important is, when the user moves from `site.com` to another site `other.com`, which also has a banner, then `ads.com` gets the cookie, as it belongs to `ads.com`, thus recognizing the visitor and tracking him as he moves between sites:
->>>>>>> upstream/master
 
     ![](cookie-third-party-3.svg)
 
 
-광고회사는 사용자의 이용 행태를 추적하고, 광고를 제공하기 위해 오래전부터 서드 파티 쿠키를 사용하고 있습니다. 서드파티 쿠키는 쿠키를 설정한 도메인에 종속되기 때문에 `ads.com`은 사용자가 어떤 사이트를 방문했는지 추적할 수 있습니다.
+광고회사는 사용자의 이용 행태를 추적하고, 광고를 제공하기 위해 오래전부터 서드 파티 쿠키를 사용하고 있습니다. 서드 파티 쿠키는 쿠키를 설정한 도메인에 종속되기 때문에 `ads.com`은 사용자가 어떤 사이트를 방문했는지 추적할 수 있습니다.
 
-<<<<<<< HEAD
-그런데 사람들은 누군가 자신을 감시하는 걸 좋아하진 않습니다. 브라우저엔 이런 쿠키를 비활성화 할 수 있는 기능이 있는데, 이 기능을 사용하면 추적을 막을 수 있습니다.
-=======
-Naturally, some people don't like being tracked, so browsers allow them to disable such cookies.
->>>>>>> upstream/master
+그런데 사람들은 누군가 자신을 감시하는 걸 좋아하진 않습니다. 브라우저엔 이런 쿠키를 비활성화할 수 있는 기능이 있는데, 이 기능을 사용하면 추적을 막을 수 있습니다.
 
 여기에 더하여 몇몇 모던 브라우저는 서드 파티 쿠키를 위한 특별한 정책을 도입하여 광고회사의 추적을 막을 수 있게 합니다.
-- Safari는 서드파티 쿠키를 전면적으로 허용하지 않습니다.
-- Firefox는 서드 파티 도메인 "블랙 리스트(black list)"를 만들어 리스트에 오른 도메인의 서드 파티 쿠키를 차단합니다. 
+- Safari는 서드 파티 쿠키를 전면적으로 허용하지 않습니다.
+- Firefox는 서드 파티 도메인 "블랙리스트"를 만들어 리스트에 오른 도메인의 서드 파티 쿠키를 차단합니다.
 
 
 ```smart
-`<script src="https://google-analytics.com/analytics.js">`같은 태그로 서드 파티 도메인에서 스크립트를 읽어오고, 이 스크립트 안에 `document.cookie`로 쿠키를 설정하는 코드가 있다면, 이때 만들어진 쿠키는 서드파티 쿠키가 아닙니다.
+`<script src="https://google-analytics.com/analytics.js">`같은 태그로 서드 파티 도메인에서 스크립트를 읽어오고, 이 스크립트 안에 `document.cookie`로 쿠키를 설정하는 코드가 있다면, 이때 만들어진 쿠키는 서드 파티 쿠키가 아닙니다.
 
 스크립트에서 쿠키를 설정한 경우에 만들어지는 쿠키는 현재 페이지의 도메인에 속하게 됩니다. 스크립트의 유래와 상관없이 말이죠.
 ```
 
 ## 부록: GDPR
 
-<<<<<<< HEAD
 이 주제는 자바스크립트와 전혀 관계가 없지만, 쿠키를 설정할 때 명심해야 할 사항입니다.
 
-EU(유럽연합)에는 사용자 개인 정보 보호를 강제하는 법령인 GDPR이 있습니다. 쿠키를 추적하는 경우 사용자로부터 명시적인 허가를 얻어야 한다는 것이 이 법령의 중요 요건 중 하나입니다. 
-=======
-This topic is not related to JavaScript at all, it is just something to keep in mind when setting cookies.
-
-There's a legislation in Europe called GDPR, that enforces a set of rules for websites to respect the users' privacy. One of these rules is to require explicit permission for tracking cookies from the user.
->>>>>>> upstream/master
+유럽연합에는 사용자 개인 정보 보호를 강제하는 법령인 GDPR이 있습니다. 쿠키를 추적하는 경우 사용자로부터 명시적인 허가를 얻어야 한다는 것이 이 법령의 중요 요건 중 하나입니다.
 
 이 요건은 쿠키를 이용한 사용자 추적, 식별에 관한 내용을 담고 있습니다.
 
 따라서 쿠키를 설정하고, 이 쿠키를 정보 저장의 용도로만 사용한다면 이 법령이 강제하는 사항을 지킬 필요가 없습니다. 사용자를 추적하거나 식별하지 않는다면 말이죠.
 
-<<<<<<< HEAD
 하지만, 인증 세션과 함께 쿠키를 설정하거나 id를 추적한다면 사용자의 동의를 반드시 얻어야 합니다.
 
-웹 사이트는 다음과 같은 방법으로 GDPR에 대응할 수 있습니다. 이 방법이 적용된 사이트를 접속해 보신 경험이 있으리라 생각합니다.
-=======
-But if we are going to set a cookie with an authentication session or a tracking ID, then a user must allow that.
-
-Websites generally have two variants of complying with GDPR. You are likely to have seen them both on the web:
->>>>>>> upstream/master
+웹사이트는 다음과 같은 방법으로 GDPR에 대응할 수 있습니다. 이 방법이 적용된 사이트를 접속해 보신 경험이 있으리라 생각합니다.
 
 1. 인증된 사용자에 대해서만 추적 쿠키를 설정하려는 경우
 
@@ -665,51 +413,26 @@ Websites generally have two variants of complying with GDPR. You are likely to h
 
 2. 모든 사용자를 대상으로 추적 쿠키를 설정하려는 경우
 
-<<<<<<< HEAD
-    최초 방문자에게 쿠키설정에 대한 동의를 요구하는 "작은 창"을 보여주고, 사용자가 이에 동의한 경우에만 콘텐츠를 표시하고, 추적 쿠키를 설정합니다. 새로운 방문자는 이런 절차가 번거롭다고 생각할 수 있습니다. 콘텐츠를 가리면서 "무조건 클릭해야 하는 창"을 그 누구도 달가워하지 않죠. 하지만 GDPR을 준수하려면 이 창이 반드시 있어야 합니다.
+    최초 방문자에게 쿠키 설정에 대한 동의를 요구하는 "작은 창"을 보여주고, 사용자가 이에 동의한 경우에만 콘텐츠를 표시하고, 추적 쿠키를 설정합니다. 새로운 방문자는 이런 절차가 번거롭다고 생각할 수 있습니다. 콘텐츠를 가리면서 "무조건 클릭해야 하는 창"을 그 누구도 달가워하지 않죠. 하지만 GDPR을 준수하려면 이 창이 반드시 있어야 합니다.
 
 
 GDPR은 쿠키에 대해서만 다루진 않고, 전반적인 보안 이슈에 관한 내용을 다룹니다. 자세한 사항은 이 튜토리얼의 범위를 벗어나기 때문에 GDPR에 대한 이야기는 여기서 마치도록 하겠습니다.
-=======
-    To do so legally, a website shows a modal "splash screen" for newcomers and requires them to agree to the cookies. Then the website can set them and let people see the content. That can be disturbing for new visitors though. No one likes to see such "must-click" modal splash screens instead of the content. But GDPR requires an explicit agreement.
-
-
-GDPR is not only about cookies, it is about other privacy-related issues too, but that is beyond our scope.
->>>>>>> upstream/master
 
 
 ## 요약
 
-<<<<<<< HEAD
 `document.cookie`는 쿠키에 접근할 수 있도록 해줍니다.
 - 쓰기는 해당 쿠키의 값만 갱신합니다.
 - 쿠키 이름과 값은 꼭 인코딩해야 합니다.
-- 쿠키 하나가 차지하는 용량은 최대 4KB까지이고, 사이트 하나당 약 20여 개를 허용합니다(브라우저에 따라 다름).
+- 쿠키 하나가 차지하는 용량은 최대 4KB까지이고, 사이트 하나당 약 20여 개를 허용합니다. 개수는 브라우저에 따라 다릅니다.
 
 쿠키 옵션:
 - `path=/`의 기본값은 현재 경로이고, 설정한 경로나 그 하위 경로에서만 쿠키 정보를 볼 수 있습니다.
 - `domain=site.com` 옵션에 아무런 값을 입력하지 않았다면 쿠키를 설정한 도메인에서만 쿠키 정보를 얻을 수 있습니다. 명시적으로 도메인 주소를 설정한 경우엔, 해당 도메인의 서브 도메인에서도 쿠키 정보를 얻을 수 있습니다.
-- `expires/max-age` 는 쿠키의 만료 시간을 정해줍니다. 이 옵션이 없으면 브라우저가 닫힐 때 쿠키도 같이 삭제됩니다.
-- `secure` 는 HTTPS 연결에서만 쿠키를 사용할 수 있게 합니다.
-- `samesite` 는 요청이 외부 사이트에서 일어날 때, 브라우저가 쿠키를 보내지 못하도록 막아줍니다. XSRF 공격을 막는 데 유용합니다.
+- `expires/max-age`는 쿠키의 만료 시간을 정해줍니다. 이 옵션이 없으면 브라우저가 닫힐 때 쿠키도 같이 삭제됩니다.
+- `secure`는 HTTPS 연결에서만 쿠키를 사용할 수 있게 합니다.
+- `samesite`는 요청이 외부 사이트에서 일어날 때, 브라우저가 쿠키를 보내지 못하도록 막아줍니다. XSRF 공격을 막는 데 유용합니다.
 
 추가 사항:
-- 브라우저에 따라 서드 파티 쿠키를 허용하지 않을 수 있습니다. Safari는 기본적으로 서드 파티 쿠키를 금지합니다.
+- 브라우저에 따라 서드 파티 쿠키를 허용하지 않을 수 있습니다. Safari는 기본적으로 서드 파티 쿠키를 금지하며, Chrome에서도 이를 구현하기 위한 작업이 진행 중입니다.
 - 사용자가 EU 국가 거주자인 경우 GDPR을 준수해야 합니다. 따라서, 사용자 추적 시 반드시 동의를 얻어야 합니다.
-=======
-`document.cookie` provides access to cookies.
-- Write operations modify only the cookie mentioned in it.
-- Name/value must be encoded.
-- One cookie may not exceed 4KB in size. The number of cookies allowed on a domain is around 20+ (varies by browser).
-
-Cookie attributes:
-- `path=/`, by default current path, makes the cookie visible only under that path.
-- `domain=site.com`, by default a cookie is visible on the current domain only. If the domain is set explicitly, the cookie becomes visible on subdomains.
-- `expires` or `max-age` sets the cookie expiration time. Without them, the cookie dies when the browser is closed.
-- `secure` makes the cookie HTTPS-only.
-- `samesite` forbids the browser to send the cookie with requests coming from outside the site. This helps to prevent XSRF attacks.
-
-Additionally:
-- The browser may forbid third-party cookies, e.g. Safari does that by default. There is also work in progress to implement this in Chrome.
-- When setting a tracking cookie for EU citizens, GDPR requires to ask for permission.
->>>>>>> upstream/master
diff --git a/6-data-storage/02-localstorage/article.md b/6-data-storage/02-localstorage/article.md
index 063399362..31d2e492c 100644
--- a/6-data-storage/02-localstorage/article.md
+++ b/6-data-storage/02-localstorage/article.md
@@ -1,35 +1,27 @@
 # localStorage와 sessionStorage
 
-웹 스토리지 객체(web storage object)인 `localStorage`와 `sessionStorage`는 브라우저 내에 키-값 쌍을 저장할 수 있게 해줍니다.
+웹 스토리지 객체인 `localStorage`와 `sessionStorage`는 브라우저 내에 키-값 쌍을 저장할 수 있게 해줍니다.
 
-이 둘을 사용하면 페이지를 새로 고침하고(`sessionStorage`의 경우) 심지어 브라우저를 다시 실행해도(`localStorage`의 경우) 데이터가 사라지지 않고 남아있습니다. 이 부분은 조만간 뒤에서 살펴보기로 합시다.
+`sessionStorage`에 저장한 데이터는 페이지를 새로 고침해도 사라지지 않고, `localStorage`에 저장한 데이터는 심지어 브라우저를 다시 실행해도 남아있습니다. 이 부분은 조만간 뒤에서 살펴보기로 합시다.
 
 그런데 "쿠키를 사용하면 브라우저에 데이터를 저장할 수 있는데, 왜 또 다른 객체를 사용해 데이터를 저장하는 걸까요?"라는 의문이 들 수 있습니다. 쿠키 이외에도 다른 방식을 사용하는 이유는 다음과 같습니다.
 
-<<<<<<< HEAD
-- 쿠키와 다르게 웹 스토리지 객체는 네트워크 요청 시 서버로 전송되지 않습니다. 이런 특징 때문에 쿠키보다 더 많은 자료를 보관할 수 있습니다. 대부분의 브라우저가 최소 2MB 혹은 그 이상의 웹 스토리지 객체를 저장할 수 있도록 해줍니다. 또한 개발자는 브라우저 내 웹 스토리지 구성 방식을 설정할 수 있습니다.
+- 쿠키와 다르게 웹 스토리지 객체는 네트워크 요청 시 서버로 전송되지 않습니다. 이런 특징 때문에 쿠키보다 더 많은 자료를 보관할 수 있습니다. 대부분의 모던 브라우저는 최소 5MB 혹은 그 이상의 데이터를 저장할 수 있도록 해주며, 브라우저 설정에서 이를 조정할 수도 있습니다.
 - 쿠키와 또 다른 점은 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없다는 것입니다. 웹 스토리지 객체 조작은 모두 자바스크립트 내에서 수행됩니다.
-- 웹 스토리지 객체는 도메인·프로토콜·포트로 정의되는 오리진(origin)에 묶여있습니다. 따라서 프로토콜과 서브 도메인이 다르면 데이터에 접근할 수 없습니다.
+- 웹 스토리지 객체는 도메인·프로토콜·포트로 정의되는 오리진에 묶여있습니다. 따라서 프로토콜과 서브 도메인이 다르면 데이터에 접근할 수 없습니다.
 
 두 스토리지 객체는 동일한 메서드와 프로퍼티를 제공합니다.
-=======
-- Unlike cookies, web storage objects are not sent to server with each request. Because of that, we can store much more. Most modern browsers allow at least 5 megabytes of data (or more) and have settings to configure that.
-- Also unlike cookies, the server can't manipulate storage objects via HTTP headers. Everything's done in JavaScript.
-- The storage is bound to the origin (domain/protocol/port triplet). That is, different protocols or subdomains infer different storage objects, they can't access data from each other.
-
-Both storage objects provide the same methods and properties:
->>>>>>> upstream/master
 
 - `setItem(key, value)` -- 키-값 쌍을 보관합니다.
 - `getItem(key)` -- 키에 해당하는 값을 받아옵니다.
 - `removeItem(key)` -- 키와 해당 값을 삭제합니다.
 - `clear()` -- 모든 것을 삭제합니다.
-- `key(index)` -- 인덱스(`index`)에 해당하는 키를 받아옵니다.
+- `key(index)` -- 인덱스에 해당하는 키를 받아옵니다.
 - `length` -- 저장된 항목의 개수를 얻습니다.
 
 두 스토리지 객체는 `Map`과 유사합니다. `setItem/getItem/removeItem`을 지원하죠. 하지만 인덱스를 사용해 키에 접근할 수 있다는 점(`key(index)`)에서 차이가 있습니다. 
 
-이제 본격적으로 localStorage와 sessionStorage가 어떻게 동작하는지 살펴봅시다.
+이제 본격적으로 `localStorage`와 `sessionStorage`가 어떻게 동작하는지 살펴봅시다.
 
 ## localStorage 데모
 
@@ -50,7 +42,7 @@ localStorage.setItem('test', 1);
 alert( localStorage.getItem('test') ); // 1
 ```
 
-오리진(domain/port/protocol)만 같다면 url 경로는 달라도 동일한 결과를 볼 수 있습니다.
+도메인·포트·프로토콜로 정의되는 오리진만 같다면 URL 경로는 달라도 동일한 결과를 볼 수 있습니다.
 
 `localStorage`는 동일한 오리진을 가진 모든 창에서 공유되기 때문입니다. 따라서 한 창에 데이터를 설정하면 다른 창에서 변동 사항을 볼 수 있습니다.
 
@@ -71,12 +63,8 @@ delete localStorage.test;
 
 하위 호환성 때문에 아직 이런 방법이 지원되기는 하지만, 다음과 같은 이유로 추천하지 않습니다.
 
-<<<<<<< HEAD
 1. 사용자는 `length`나 `toString`, `localStorage`의 내장 메서드를 키로 설정할 수 있습니다. 이렇게 되면 `getItem`, `setItem`은 정상적으로 작동해도, 일반 객체처럼 다룰 때 에러가 발생할 수 있습니다.
-=======
-1. If the key is user-generated, it can be anything, like `length` or `toString`, or another built-in method of `localStorage`. In that case `getItem/setItem` work fine, while object-like access fails:
 
->>>>>>> upstream/master
     ```js run
     let key = 'length';
     localStorage[key] = 5; // TypeError: Cannot assign to read only property 'length'...
@@ -88,7 +76,7 @@ delete localStorage.test;
 
 `localStorage`는 '키'를 사용해 값을 얻고, 설정하고, 삭제할 수 있게 해줍니다. 그렇다면 키나 값 전체는 어떻게 얻을 수 있을까요?
 
-아쉽게도 스토리지 객체는 iterable 객체가 아닙니다.
+아쉽게도 스토리지 객체는 이터러블 객체가 아닙니다.
 
 대신 배열처럼 다루면 전체 키-값을 얻을 수 있습니다.
 
@@ -132,20 +120,11 @@ for(let key of keys) {
 
 `Object.keys`는 해당 객체에서 정의한 키만 반환하고 프로토타입에서 상속받은 키는 무시하기 때문입니다. 
 
-<<<<<<< HEAD
-
 ## 문자열만 사용
-=======
-## Strings only
->>>>>>> upstream/master
 
 `localStorage`의 키와 값은 반드시 문자열이어야 합니다.
 
-<<<<<<< HEAD
 숫자나 객체 등 다른 자료형을 사용하게 되면 문자열로 자동 변환됩니다.
-=======
-If they were any other type, like a number, or an object, they would get converted to a string automatically:
->>>>>>> upstream/master
 
 ```js run
 localStorage.user = {name: "John"};
@@ -157,11 +136,7 @@ alert(localStorage.user); // [object Object]
 ```js run
 localStorage.user = JSON.stringify({name: "John"});
 
-<<<<<<< HEAD
-// 잠시 후 
-=======
-// sometime later
->>>>>>> upstream/master
+// 잠시 후
 let user = JSON.parse( localStorage.user );
 alert( user.name ); // John
 ```
@@ -198,29 +173,25 @@ sessionStorage.setItem('test', 1);
 alert( sessionStorage.getItem('test') ); // 새로 고침 후: 1
 ```
 
-하지만 다른 탭에서 본 페이지를 열고 바로 위 예시만 실행해보면 '아무것도 찾을 수 없다'는 뜻을 가진 `null`이 반환되는것을 확인할 수 있습니다.
+하지만 다른 탭에서 본 페이지를 열고 바로 위 예시만 실행해보면 '아무것도 찾을 수 없다'는 뜻을 가진 `null`이 반환되는 것을 확인할 수 있습니다.
 
 이렇게 `sessionStorage`는 오리진뿐만 아니라 브라우저 탭에도 종속되어 있습니다. 이런 제약 때문에 `sessionStorage`는 잘 사용되지 않습니다.
 
 ## storage 이벤트
 
-<<<<<<< HEAD
-`localStorage`나 `sessionStorage`의 데이터가 갱신될 때, [storage](https://www.w3.org/TR/webstorage/#the-storage-event) 이벤트가 실행됩니다. storage 이벤트는 다음과 같은 프로퍼티를 지원합니다.
-=======
-When the data gets updated in `localStorage` or `sessionStorage`, [storage](https://html.spec.whatwg.org/multipage/webstorage.html#the-storageevent-interface) event triggers, with properties:
->>>>>>> upstream/master
+`localStorage`나 `sessionStorage`의 데이터가 갱신될 때, [storage](https://html.spec.whatwg.org/multipage/webstorage.html#the-storageevent-interface) 이벤트가 실행됩니다. `storage` 이벤트는 다음과 같은 프로퍼티를 지원합니다.
 
 - `key` -- 변경된 데이터의 키(`.clear()`를 호출했다면 `null`)
 - `oldValue` -- 이전 값(키가 새롭게 추가되었다면 `null`)
 - `newValue` -- 새로운 값(키가 삭제되었다면 `null`)
-- `url` -- 갱신이 일어난 문서의 url
+- `url` -- 갱신이 일어난 문서의 URL
 - `storageArea` -- 갱신이 일어난 `localStorage`나 `sessionStorage` 객체
 
 여기서 중요한 점은 storage 이벤트가 이벤트를 발생시킨 스토리지를 제외하고 스토리지에서 접근 가능한 `window` 객체 전부에서 일어난다는 사실입니다.
 
 좀 더 구체적으로 설명을 이어나가 보겠습니다.
 
-두 개의 창에 같은 사이트를 띄워놨다고 가정해봅시다. 창은 다르지만 `localStorage`는 서로 공유됩니다.
+두 개의 창에 같은 사이트를 띄워놨다고 가정해 봅시다. 창은 다르지만 `localStorage`는 서로 공유됩니다.
 
 ```online
 실제 본 페이지를 두 개의 브라우저 창에 띄워 봅시다.
@@ -229,13 +200,8 @@ When the data gets updated in `localStorage` or `sessionStorage`, [storage](http
 두 창에서 모두 `storage` 이벤트를 수신하고 있기 때문에 한 창에서 아래 예시를 실행해 데이터를 갱신하면 다른 창에 해당 사항이 반영되는 것을 확인할 수 있습니다.
 
 ```js run
-<<<<<<< HEAD
 // 문서는 다르지만, 갱신은 같은 스토리지에 반영됩니다.
-window.onstorage = event => { // window.addEventListener('storage', () => {와 같습니다.
-=======
-// triggers on updates made to the same storage from other documents
-window.onstorage = event => { // can also use window.addEventListener('storage', event => {
->>>>>>> upstream/master
+window.onstorage = event => { // window.addEventListener('storage', event => {도 사용할 수 있습니다.
   if (event.key != 'now') return;
   alert(event.key + ':' + event.newValue + " at " + event.url);
 };
@@ -243,34 +209,22 @@ window.onstorage = event => { // can also use window.addEventListener('storage',
 localStorage.setItem('now', Date.now());
 ```
 
-storage 이벤트의 또 다른 중요한 특징은 `event.url`이 있어 데이터가 갱신된 문서의 URL을 알 수 있다는 점입니다.
+`storage` 이벤트의 또 다른 중요한 특징은 `event.url`이 있어 데이터가 갱신된 문서의 URL을 알 수 있다는 점입니다.
 
 또한 `event.storageArea`에는 스토리지 객체가 포함되어 있는데, storage 이벤트는 `sessionStorage`나 `localStorage`가 변경될 때 모두 발생하기 때문에 `event.storageArea`는 스토리지 종류에 상관없이 실제 수정이 일어난 것을 참조한다는 것 역시 중요한 특징입니다. 변경이 일어났을 때 우리는 `event.storageArea`에 무언가를 설정해 '응답'이 가능하도록 할 수 있죠.
 
 **이런 특징을 이용하면 오리진이 같은 창끼리 메시지를 교환하게 할 수 있습니다.**
 
-<<<<<<< HEAD
-모던 브라우저는 오리진이 같은 창끼리 통신할 수 있도록 해주는 [브로드캐스트 채널 API(broadcast channel API)](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API)를 지원합니다. 그런데 이 API는 기능은 풍부하지만, 아직 많은 곳에서 지원하지 않는다는 단점이 있습니다. 단점을 극복하게 해주는 `localStorage` 기반한 폴리필들이 있는데, 이런 라이브러리들은 브라우저와 관계없이 어디서든 창 간 메시지를 교환할 수 있게 해준다는 장점이 있습니다.
-=======
-Modern browsers also support [Broadcast channel API](mdn:/api/Broadcast_Channel_API), the special API for same-origin inter-window communication, it's more full featured, but less supported. There are libraries that polyfill that API, based on `localStorage`, that make it available everywhere.
->>>>>>> upstream/master
+모던 브라우저는 오리진이 같은 창끼리 통신할 수 있도록 해주는 특별한 API인 [Broadcast Channel API](mdn:/api/Broadcast_Channel_API)도 지원합니다. 이 API는 기능이 더 풍부하지만 지원 범위는 더 좁습니다. `localStorage` 기반으로 이 API를 폴리필하는 라이브러리도 있어, 어디서든 창 간 메시지를 교환할 수 있게 해줍니다.
 
 ## 요약
 
-<<<<<<< HEAD
-웹 스토리지 객체 `localStorage`와 `sessionStorage`를 사용하면 브라우저에 키-값 쌍을 저장할 수 있습니다. 이때,
+웹 스토리지 객체 `localStorage`와 `sessionStorage`를 사용하면 브라우저에 키-값 쌍을 저장할 수 있습니다.
+
 - `키`와 `값`은 반드시 문자열이어야 합니다.
 - 제한 용량은 5MB 이상인데, 브라우저에 따라 다를 수 있습니다.
-- 파기되지 않습니다.
-- 오리진(도메인·포트·프로토콜)에 묶여있습니다.
-=======
-Web storage objects `localStorage` and `sessionStorage` allow to store key/value pairs in the browser.
-
-- Both `key` and `value` must be strings.
-- The limit is 5mb+, depends on the browser.
-- They do not expire.
-- The data is bound to the origin (domain/port/protocol).
->>>>>>> upstream/master
+- 데이터는 만료되지 않습니다.
+- 도메인·포트·프로토콜로 정의되는 오리진에 묶여있습니다.
 
 | `localStorage` | `sessionStorage` |
 |--------------|--------------|
@@ -283,13 +237,13 @@ API:
 - `getItem(key)` -- 키에 해당하는 값을 받아옵니다.
 - `removeItem(key)` -- 키와 해당 값을 삭제합니다.
 - `clear()` -- 모든 것을 삭제합니다.
-- `key(index)` -- `인덱스`에 해당하는 키를 받아옵니다.
+- `key(index)` -- 인덱스에 해당하는 키를 받아옵니다.
 - `length` -- 저장된 항목의 개수를 얻습니다.
 - `Object.keys`를 사용해 키 전체를 얻을 수 있습니다.
 - 객체 프로퍼티처럼 키에 접근할 수 있는데, 이 경우 `storage` 이벤트가 발생하지 않습니다.
 
-storage 이벤트:
+`storage` 이벤트:
 
 - `setItem`, `removeItem`, `clear`를 호출할 때 발생합니다.
 - 연산(`key/oldValue/newValue`)과 관련된 데이터 전체와 문서 `url`, 스토리지 객체 `storageArea`를 가지고 있습니다.
-- 이벤트가 생성된 곳을 제외하고 스토리지에 접근하는 모든 `window` 객체에서 일어납니다(`sessionStorage`는 탭 내에서, `localStorage`에서는 전역에서).
+- 이벤트가 생성된 곳을 제외하고 스토리지에 접근하는 모든 `window` 객체에서 일어납니다. `sessionStorage`는 탭 내에서, `localStorage`에서는 전역에서 일어납니다.
diff --git a/6-data-storage/03-indexeddb/article.md b/6-data-storage/03-indexeddb/article.md
index 0f6ad5454..b75489df1 100644
--- a/6-data-storage/03-indexeddb/article.md
+++ b/6-data-storage/03-indexeddb/article.md
@@ -5,71 +5,63 @@ libs:
 
 # IndexedDB
 
-IndexedDB is a database that is built into a browser, much more powerful than `localStorage`.
+IndexedDB는 `localStorage`보다 훨씬 강력한 브라우저 내장 데이터베이스입니다.
 
-- Stores almost any kind of values by keys, multiple key types.
-- Supports transactions for reliability.
-- Supports key range queries, indexes.
-- Can store much bigger volumes of data than `localStorage`.
+- 여러 타입의 키를 사용해 거의 모든 종류의 값을 저장할 수 있습니다.
+- 신뢰성을 위한 트랜잭션을 지원합니다.
+- 키 범위 질의와 인덱스를 지원합니다.
+- `localStorage`보다 훨씬 많은 양의 데이터를 저장할 수 있습니다.
 
-That power is usually excessive for traditional client-server apps. IndexedDB is intended for offline apps, to be combined with ServiceWorkers and other technologies.
+이런 강력함은 일반적인 클라이언트-서버 앱에는 대개 과합니다. IndexedDB는 서비스 워커와 기타 기술을 함께 사용하는 오프라인 앱을 위해 만들어졌습니다.
 
-The native interface to IndexedDB, described in the specification <https://www.w3.org/TR/IndexedDB>, is event-based.
+설명서 <https://www.w3.org/TR/IndexedDB>에 기술된 IndexedDB에 대한 기본 인터페이스는 이벤트 기반입니다.
 
-<<<<<<< HEAD
-We can also use `async/await` with the help of a promise-based wrapper, like <https://github.com/jakearchibald/idb>. That's pretty convenient, but the wrapper is not perfect, it can't replace events for all cases. So we'll start with events, and then, after we gain an understanding of IndexedDb, we'll use the wrapper.
-=======
-We can also use `async/await` with the help of a promise-based wrapper, like <https://github.com/jakearchibald/idb>. That's pretty convenient, but the wrapper is not perfect, it can't replace events for all cases. So we'll start with events, and then, after we gain an understanding of IndexedDB, we'll use the wrapper.
+<https://github.com/jakearchibald/idb>와 같은 프라미스 기반 래퍼의 도움을 받아 `async/await`도 사용할 수 있습니다. 꽤 편리하긴 하지만 래퍼가 완벽하지는 않아 모든 경우에 대한 이벤트를 대체할 수는 없습니다. 먼저 이벤트부터 시작하고, IndexedDB에 대한 이해를 얻은 후 래퍼를 사용할 것입니다.
 
-```smart header="Where's the data?"
-Technically, the data is usually stored in the visitor's home directory, along with browser settings, extensions, etc.
+```smart header="데이터는 어디에 저장될까요?"
+기술적으로 데이터는 대개 브라우저 설정, 확장 프로그램 등과 함께 방문자의 홈 디렉터리에 저장됩니다.
 
-Different browsers and OS-level users have each their own independant storage.
+브라우저마다, 그리고 운영체제 사용자마다 각자 독립적인 저장소를 가집니다.
 ```
->>>>>>> upstream/master
 
-## Open database
+## 데이터베이스 열기
 
-To start working with IndexedDB, we first need to `open` (connect to) a database.
+IndexedDB로 작업을 시작하려면 먼저 데이터베이스를 열어야 합니다.
 
-The syntax:
+구문:
 
 ```js
 let openRequest = indexedDB.open(name, version);
 ```
 
-- `name` -- a string, the database name.
-- `version` -- a positive integer version, by default `1` (explained below).
+- `name` -- 데이터베이스 이름인 문자열입니다.
+- `version` -- 양수 버전입니다. 기본값은 `1`이며 아래에서 설명합니다.
 
-We can have many databases with different names, but all of them exist within the current origin (domain/protocol/port). Different websites can't access each other's databases.
+서로 다른 이름을 가진 데이터베이스를 여러 개 만들 수 있지만, 이 데이터베이스들은 모두 현재 도메인·프로토콜·포트로 정의되는 오리진 안에 존재합니다. 서로 다른 웹사이트는 서로의 데이터베이스에 접근할 수 없습니다.
 
-The call returns `openRequest` object, we should listen to events on it:
-- `success`: database is ready, there's the "database object" in `openRequest.result`, we should use it for further calls.
-- `error`: opening failed.
-- `upgradeneeded`: database is ready, but its version is outdated (see below).
+호출은 `openRequest` 객체를 반환하므로 이 객체의 이벤트를 감시해야 합니다.
+- `success`: 데이터베이스가 준비되면 `openRequest.result`에 "데이터베이스 객체"가 들어 있습니다. 이후 호출에는 이 데이터베이스 객체를 사용해야 합니다.
+- `error`: 열기 실패입니다.
+- `upgradeneeded`: 데이터베이스가 준비되었지만, 데이터베이스 버전이 오래되었습니다. 아래에서 설명합니다.
 
-**IndexedDB has a built-in mechanism of "schema versioning", absent in server-side databases.**
+**IndexedDB에는 서버 측 데이터베이스에는 없는 "스키마 버전 관리" 메커니즘이 내장되어 있습니다.**
 
-Unlike server-side databases, IndexedDB is client-side, the data is stored in the browser, so we, developers, don't have full-time access to it. So, when we have published a new version of our app, and the user visits our webpage, we may need to update the database.
+서버 측 데이터베이스와 달리 IndexedDB는 클라이언트 쪽에 있고 데이터는 브라우저에 저장되므로 개발자가 데이터베이스에 "언제든지" 접근할 수 없습니다. 그래서 새 버전의 앱을 배포한 후 사용자가 웹페이지를 방문하면 데이터베이스를 업데이트해야 할 수도 있습니다.
 
-If the local database version is less than specified in `open`, then a special event `upgradeneeded` is triggered, and we can compare versions and upgrade data structures as needed.
+로컬 데이터베이스 버전이 `open`에 명시된 것보다 작을 경우, 특별한 이벤트 `upgradeneeded`가 발생하며 필요에 따라 버전을 비교하고 데이터 구조를 업그레이드할 수 있습니다.
 
-<<<<<<< HEAD
-The `upgradeneeded` event also triggers when the database doesn't yet exist (technically, it's version is `0`), so we can perform the initialization.
-=======
-The `upgradeneeded` event also triggers when the database doesn't yet exist (technically, its version is `0`), so we can perform the initialization.
->>>>>>> upstream/master
+데이터베이스가 아직 존재하지 않을 때도, 즉 기술적으로 버전 `0`인 경우에도 `upgradeneeded` 이벤트가 발생하여 초기화를 수행할 수 있습니다.
 
-Let's say we published the first version of our app.
+우리 앱의 첫 번째 버전을 배포했다고 합시다.
 
-Then we can open the database with version `1` and perform the initialization in an `upgradeneeded` handler like this:
+그런 다음 버전 `1`로 데이터베이스를 열고 다음과 같이 `upgradeneeded` 핸들러에서 초기화를 수행할 수 있습니다.
 
 ```js
 let openRequest = indexedDB.open("store", *!*1*/!*);
 
 openRequest.onupgradeneeded = function() {
-  // triggers if the client had no database
-  // ...perform initialization...
+  // 클라이언트에 데이터베이스가 없는 경우 발생합니다.
+  // ...초기화를 수행합니다...
 };
 
 openRequest.onerror = function() {
@@ -78,78 +70,68 @@ openRequest.onerror = function() {
 
 openRequest.onsuccess = function() {
   let db = openRequest.result;
-  // continue working with database using db object
+  // db 객체를 사용하여 데이터베이스 작업을 계속합니다.
 };
 ```
 
-Then, later, we publish the 2nd version.
+그러고 나서 나중에 두 번째 버전을 배포합니다.
 
-We can open it with version `2` and perform the upgrade like this:
+버전 `2`로 데이터베이스를 열고 다음과 같이 업그레이드를 수행할 수 있습니다.
 
 ```js
 let openRequest = indexedDB.open("store", *!*2*/!*);
 
 openRequest.onupgradeneeded = function(event) {
-  // the existing database version is less than 2 (or it doesn't exist)
+  // 기존 데이터베이스 버전이 2보다 작거나 존재하지 않습니다.
   let db = openRequest.result;
-  switch(event.oldVersion) { // existing db version
+  switch(event.oldVersion) { // 기존 db 버전
     case 0:
-      // version 0 means that the client had no database
-      // perform initialization
+      // 버전 0은 클라이언트에 데이터베이스가 없음을 의미합니다.
+      // 초기화를 수행합니다.
     case 1:
-      // client had version 1
-      // update
+      // 클라이언트에 버전 1이 있습니다.
+      // 갱신합니다.
   }
 };
 ```
 
-<<<<<<< HEAD
-Please note: as our current version is `2`, `onupgradeneeded` handler has a code branch for version `0`, suitable for users that are accessing for the first time and have no database, and also for version `1`, for upgrades.
-=======
-Please note: as our current version is `2`, the `onupgradeneeded` handler has a code branch for version `0`, suitable for users that are accessing for the first time and have no database, and also for version `1`, for upgrades.
->>>>>>> upstream/master
+참고: 현재 버전이 `2`이므로 `onupgradeneeded` 핸들러에는 버전 `0`에 대한 코드 분기가 있습니다. 이는 처음 방문해서 데이터베이스가 없는 사용자에게 필요합니다. 또한 업그레이드를 위한 버전 `1` 분기도 있습니다.
 
-And then, only if `onupgradeneeded` handler finishes without errors, `openRequest.onsuccess` triggers, and the database is considered successfully opened.
+그런 다음 에러 없이 `onupgradeneeded` 핸들러가 끝나야 `openRequest.onsuccess`가 발생하고 데이터베이스가 성공적으로 열린 것으로 간주합니다.
 
-To delete a database:
+데이터베이스를 삭제하려면 다음과 같이 해야 합니다.
 
 ```js
 let deleteRequest = indexedDB.deleteDatabase(name)
-// deleteRequest.onsuccess/onerror tracks the result
+// deleteRequest.onsuccess/onerror가 결과를 추적합니다.
 ```
 
-```warn header="We can't open a database using an older open call version"
-If the current user database has a higher version than in the `open` call, e.g. the existing DB version is `3`, and we try to `open(...2)`, then that's an error, `openRequest.onerror` triggers.
+```warn header="이전 open 호출 버전으로 데이터베이스를 열 수 없습니다"
+현재 사용자 데이터베이스의 버전이 `open` 호출에 지정한 버전보다 높다면, 예를 들어 기존 DB 버전이 `3`인데 `open(...2)`를 시도한다면 이는 에러이며 `openRequest.onerror`가 발생합니다.
 
-That's rare, but such a thing may happen when a visitor loads outdated JavaScript code, e.g. from a proxy cache. So the code is old, but his database is new.
+드문 일이지만 방문자가 프록시 캐시 등에서 오래된 자바스크립트 코드를 로드하면 이런 일이 발생할 수 있습니다. 코드는 오래되었지만 방문자의 데이터베이스는 새로운 상태인 것이죠.
 
-To protect from errors, we should check `db.version` and suggest a page reload. Use proper HTTP caching headers to avoid loading the old code, so that you'll never have such problems.
+이런 에러를 막으려면 `db.version`을 확인하여 페이지를 다시 로드하라고 안내해야 합니다. 오래된 코드가 로드되지 않도록 올바른 HTTP 캐싱 헤더를 사용합시다.
 ```
 
-### Parallel update problem
+### 병렬 업데이트 문제
 
-As we're talking about versioning, let's tackle a small related problem.
+버전 관리 이야기가 나온 김에 관련된 작은 문제도 다뤄 봅시다.
 
-Let's say:
-1. A visitor opened our site in a browser tab, with database version `1`.
-2. Then we rolled out an update, so our code is newer.
-3. And then the same visitor opens our site in another tab.
+다음과 같이 한다고 합시다.
+1. 방문자가 데이터베이스 버전 `1`로 브라우저 탭에서 사이트를 열었습니다.
+2. 그러고 나서 업데이트를 배포해서 코드가 최신 상태가 되었습니다.
+3. 그리고 같은 방문자가 같은 사이트를 다른 탭에서 엽니다.
 
-So there's a tab with an open connection to DB version `1`, while the second one attempts to update it to version `2` in its `upgradeneeded` handler.
+DB 버전 `1`에 대한 열린 연결을 가진 탭이 있고, 두 번째 탭은 `upgradeneeded` 핸들러에서 데이터베이스를 버전 `2`로 업데이트하려고 합니다.
 
-The problem is that a database is shared between two tabs, as it's the same site, same origin. And it can't be both version `1` and `2`. To perform the update to version `2`, all connections to version 1 must be closed, including the one in the first tab.
+문제는 데이터베이스가 동일한 사이트, 동일한 오리진에 속하므로 두 탭에서 공유된다는 점입니다. 하나의 데이터베이스가 버전 `1`이면서 동시에 버전 `2`일 수는 없습니다. 버전 `2`로 업데이트하려면 첫 번째 탭에 있는 연결을 포함하여 버전 `1`에 대한 모든 연결을 닫아야 합니다.
 
-In order to organize that, the `versionchange` event triggers on the "outdated" database object. We should listen for it and close the old database connection (and probably suggest a page reload, to load the updated code).
+이를 처리하기 위해 "오래된" 데이터베이스 객체에서 `versionchange` 이벤트가 발생합니다. 이 이벤트를 감시하고 이전 데이터베이스 연결을 닫아야 합니다. 방문자에게 페이지를 다시 로드하여 업데이트된 코드를 불러오라고 안내할 수도 있습니다.
 
-If we don't listen for the `versionchange` event and don't close the old connection, then the second, new connection won't be made. The `openRequest` object will emit the `blocked` event instead of `success`. So the second tab won't work.
+`versionchange` 이벤트를 감시하지 않고 기존 연결도 닫지 않으면 두 번째 연결은 만들어지지 않습니다. `openRequest` 객체는 `success` 대신 `blocked` 이벤트를 내보냅니다. 따라서 두 번째 탭은 동작하지 않습니다.
 
-<<<<<<< HEAD
-Here's the code to correctly handle the parallel upgrade.
-
-It installs an `onversionchange` handler after the database is opened, that closes the old connection:
-=======
-Here's the code to correctly handle the parallel upgrade. It installs the `onversionchange` handler, that triggers if the current database connection becomes outdated (db version is updated elsewhere) and closes the connection.
->>>>>>> upstream/master
+여기에 병렬 업그레이드를 올바르게 처리하기 위한 코드가 있습니다. 현재 데이터베이스 연결이 오래된 상태가 되었을 때, 즉 다른 곳에서 DB 버전이 업데이트되었을 때 실행되는 `onversionchange` 핸들러를 설치하고, 이 핸들러에서 연결을 닫습니다.
 
 ```js
 let openRequest = indexedDB.open("store", 2);
@@ -167,171 +149,148 @@ openRequest.onsuccess = function() {
   };
   */!*
 
-  // ...the db is ready, use it...
+  // ...db가 준비되었으니 사용해 봅시다...
 };
 
 *!*
 openRequest.onblocked = function() {
-  // this event shouldn't trigger if we handle onversionchange correctly
+  // onversionchange를 올바르게 처리한다면 이 이벤트는 발생하지 않아야 합니다.
 
-  // it means that there's another open connection to the same database
-  // and it wasn't closed after db.onversionchange triggered for it
+  // 같은 데이터베이스에 대한 다른 개방된 연결이 있다는 뜻입니다.
+  // db.onversionchange가 발생한 후에도 닫히지 않았다는 뜻입니다.
 };
 */!*
 ```
 
-...In other words, here we do two things:
-
-1. The `db.onversionchange` listener informs us about a parallel update attempt, if the current database version becomes outdated.
-2. The `openRequest.onblocked` listener informs us about the opposite situation: there's a connection to an outdated version elsewhere, and it doesn't close, so the newer connection can't be made.
+다시 말해, 여기서는 두 가지 일을 합니다.
 
-<<<<<<< HEAD
-There are other variants. For example, we can take the time to close things gracefully in `db.onversionchange`, and prompt the visitor to save the data before the connection is closed. The new updating connection will be blocked immediately after `db.onversionchange` has finished without closing, and we can ask the visitor in the new tab to close other tabs for the update.
+1. `db.onversionchange` 리스너는 현재 데이터베이스 버전이 오래된 상태가 되었을 때 병렬 업데이트 시도를 알려줍니다.
+2. `openRequest.onblocked` 리스너는 반대 상황, 즉 어딘가에 오래된 버전 연결이 있고 그 연결이 닫히지 않아 새 연결을 만들 수 없는 상황을 알려줍니다.
 
-These update collisions happen rarely, but we should at least have some handling for them, e.g. `onblocked` handler, so that our script doesn't surprise the user by dying silently.
-=======
-We can handle things more gracefully in `db.onversionchange`, prompt the visitor to save the data before the connection is closed and so on. 
+`db.onversionchange`에서 더 부드럽게 처리할 수도 있습니다. 예를 들어 연결을 닫기 전에 방문자에게 데이터를 저장하라고 안내할 수 있습니다.
 
-Or, an alternative approach would be to not close the database in `db.onversionchange`, but instead use the `onblocked` handler (in the new tab) to alert the visitor, tell him that the newer version can't be loaded until they close other tabs.
+또 다른 방법으로는 `db.onversionchange`에서 데이터베이스를 닫지 않고, 대신 새 탭의 `onblocked` 핸들러에서 방문자에게 새 버전을 불러오려면 다른 탭을 닫아야 한다고 알려줄 수도 있습니다.
 
-These update collisions happen rarely, but we should at least have some handling for them, at least an `onblocked` handler, to prevent our script from dying silently.
->>>>>>> upstream/master
+이러한 업데이트 충돌은 거의 발생하지 않지만, 스크립트가 조용히 죽어서 사용자를 놀라게 하지 않도록 적어도 `onblocked` 핸들러 정도는 마련해야 합니다.
 
-## Object store
+## 객체 저장소
 
-To store something in IndexedDB, we need an *object store*.
+IndexedDB에 저장하려면 *객체 저장소*가 필요합니다.
 
-An object store is a core concept of IndexedDB. Counterparts in other databases are called "tables" or "collections". It's where the data is stored. A database may have multiple stores: one for users, another one for goods, etc.
+객체 저장소는 IndexedDB의 핵심 개념입니다. 다른 데이터베이스에서 이에 대응하는 개념은 "테이블" 또는 "컬렉션"이라고 불립니다. 이곳이 데이터가 저장되는 장소입니다. 데이터베이스에는 사용자용, 상품용 등 여러 저장소가 있을 수 있습니다.
 
-Despite being named an "object store", primitives can be stored too.
+"객체 저장소"로 이름 붙여졌음에도 불구하고 원시 요소도 저장될 수 있습니다.
 
-**We can store almost any value, including complex objects.**
+**복잡한 객체를 포함한 거의 모든 값을 저장할 수 있습니다.**
 
-IndexedDB uses the [standard serialization algorithm](https://www.w3.org/TR/html53/infrastructure.html#section-structuredserializeforstorage) to clone-and-store an object. It's like `JSON.stringify`, but more powerful, capable of storing much more datatypes.
+IndexedDB는 [표준 직렬화 알고리즘](https://www.w3.org/TR/html53/infrastructure.html#section-structuredserializeforstorage)을 사용하여 객체를 복제하고 저장합니다. `JSON.stringify` 같지만, 더 강력하고 훨씬 더 많은 데이터 타입을 저장할 수 있습니다.
 
-An example of an object that can't be stored: an object with circular references. Such objects are not serializable. `JSON.stringify` also fails for such objects.
+원형 참조가 있는 객체는 저장할 수 없고 직렬화할 수 없습니다. `JSON.stringify`도 원형 참조가 있는 객체에 실패합니다.
 
-**There must be a unique `key` for every value in the store.**     
+**저장소에 있는 모든 값에는 고유한 `key`가 있어야 합니다.**
 
-<<<<<<< HEAD
-A key must be one of the these types - number, date, string, binary, or array. It's a unique identifier, so we can search/remove/update values by the key.
+키에는 숫자, 날짜, 문자열, 이진 또는 배열 중 하나의 유형이 있어야 합니다. 키는 값을 검색/삭제/갱신할 수 있는 고유 식별자입니다.
 
 ![](indexeddb-structure.svg)
 
+곧 알게 되겠지만 `localStorage`와 비슷하게 값을 저장소에 추가할 때 키를 제공할 수 있습니다. 그러나 객체를 저장할 때 IndexedDB는 객체 프로퍼티를 키로 설정할 수 있게 해주므로 훨씬 편리합니다. 또는 키를 자동으로 생성할 수도 있습니다.
 
-=======
-A key must be one of these types - number, date, string, binary, or array. It's a unique identifier, so we can search/remove/update values by the key.
-
-![](indexeddb-structure.svg)
+그러나 첫 번째로 객체 저장소를 생성해야 합니다.
 
->>>>>>> upstream/master
-As we'll see very soon, we can provide a key when we add a value to the store, similar to `localStorage`. But when we store objects, IndexedDB allows setting up an object property as the key, which is much more convenient. Or we can auto-generate keys.
-
-But we need to create an object store first.
-
-The syntax to create an object store:
+객체 저장소를 생성하는 구문입니다.
 
 ```js
 db.createObjectStore(name[, keyOptions]);
 ```
 
-Please note, the operation is synchronous, no `await` needed.
+이 연산은 동기식이기 때문에 `await`가 필요하지 않다는 점에 유의합니다.
 
-- `name` is the store name, e.g. `"books"` for books,
-- `keyOptions` is an optional object with one of two properties:
-  - `keyPath` -- a path to an object property that IndexedDB will use as the key, e.g. `id`.
-  - `autoIncrement` -- if `true`, then the key for a newly stored object is generated automatically, as an ever-incrementing number.
+- `name`은 저장소 이름입니다. 예를 들어 book을 위한 저장소라면 `"books"`입니다.
+- `keyOptions`는 다음 두 가지 속성 중 하나를 가진 선택적 객체입니다.
+  - `keyPath` -- IndexedDB가 키로 사용할 객체 프로퍼티의 경로입니다. 예를 들어 `id`를 사용할 수 있습니다.
+  - `autoIncrement` -- `true`라면 새로 저장된 객체의 키는 계속 증가하는 숫자로 자동 생성됩니다.
 
-If we don't supply `keyOptions`, then we'll need to provide a key explicitly later, when storing an object.
+`keyOptions`를 제공하지 않으면 나중에 객체를 저장할 때 명시적으로 키를 제공해야 합니다.
 
-For instance, this object store uses `id` property as the key:
+예를 들어 이 객체 저장소는 `id` 속성을 키로 사용합니다.
 
 ```js
 db.createObjectStore('books', {keyPath: 'id'});
 ```
 
-**An object store can only be created/modified while updating the DB version, in `upgradeneeded` handler.**
-
-That's a technical limitation. Outside of the handler we'll be able to add/remove/update the data, but object stores can only be created/removed/altered during a version update.
-<<<<<<< HEAD
+**객체 저장소는 `upgradeneeded` 핸들러에서 DB 버전을 업데이트하는 동안에만 생성/수정될 수 있습니다.**
 
-To perform a database version upgrade, there are two main approaches:
-=======
+이는 기술적인 제한입니다. 핸들러 외부에서 데이터를 추가/삭제/갱신할 수 있지만, 객체 저장소를 생성/삭제/변경할 수 있는 시점은 버전 업데이트 중뿐입니다.
 
-To perform a database version upgrade, there are two main approaches:
+데이터베이스 버전 업그레이드를 수행하기 위해 다음 두 가지 처리 방법이 있습니다.
 
->>>>>>> upstream/master
-1. We can implement per-version upgrade functions: from 1 to 2, from 2 to 3, from 3 to 4 etc. Then, in `upgradeneeded` we can compare versions (e.g. old 2, now 4) and run per-version upgrades step by step, for every intermediate version (2 to 3, then 3 to 4).
-2. Or we can just examine the database: get a list of existing object stores as `db.objectStoreNames`. That object is a [DOMStringList](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#domstringlist) that provides `contains(name)` method to check for existance. And then we can do updates depending on what exists and what doesn't.
+1. 버전별로 1에서 2로, 2에서 3으로, 3에서 4로 업그레이드 기능을 구현할 수 있습니다. 그런 다음 `upgradeneeded`에서 버전을 비교하고, 예를 들어 기존 버전이 2이고 현재 버전이 4라면 모든 중간 버전 업그레이드를 단계적으로 실행할 수 있습니다.
+2. 또는 `db.objectStoreNames`로 기존 객체 저장소 목록을 얻어 데이터베이스를 살펴볼 수 있습니다. 이 객체는 존재 여부를 확인할 수 있는 `contains(name)` 메서드를 제공하는 [DOMStringList](https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#domstringlist)입니다. 존재 여부에 따라 업데이트할 수 있습니다.
 
-For small databases the second variant may be simpler.
+작은 데이터베이스의 경우 두 번째 변형이 더 단순할 수 있습니다.
 
-Here's the demo of the second approach:
+여기에 두 번째 처리 방법의 데모가 있습니다.
 
 ```js
 let openRequest = indexedDB.open("db", 2);
 
-// create/upgrade the database without version checks
+// 버전 확인 없이 데이터베이스를 생성/갱신합니다.
 openRequest.onupgradeneeded = function() {
   let db = openRequest.result;
-  if (!db.objectStoreNames.contains('books')) { // if there's no "books" store
-    db.createObjectStore('books', {keyPath: 'id'}); // create it
+  if (!db.objectStoreNames.contains('books')) { // "books" 저장소가 없는 경우입니다.
+    db.createObjectStore('books', {keyPath: 'id'}); // "books" 저장소를 생성합니다.
   }
 };
 ```
 
-To delete an object store:
+객체 저장소를 지우려면 다음과 같이 해야 합니다.
 
 ```js
 db.deleteObjectStore('books')
 ```
 
-## Transactions
+## 트랜잭션
 
-The term "transaction" is generic, used in many kinds of databases.
+"트랜잭션"이라는 용어는 일반적이며 많은 종류의 데이터베이스에서 사용됩니다.
 
-A transaction is a group of operations, that should either all succeed or all fail.
+트랜잭션은 그룹 연산으로, 모두 성공하거나 모두 실패해야 합니다.
 
-For instance, when a person buys something, we need to:
+예를 들어 사람이 무언가를 살 때 다음이 요구됩니다.
 
-<<<<<<< HEAD
-For instance, when a person buys something, we need to:
-=======
->>>>>>> upstream/master
-1. Subtract the money from their account.
-2. Add the item to their inventory.
+1. 계좌에서 돈을 뺍니다.
+2. 인벤토리에 아이템을 추가합니다.
 
-It would be pretty bad if we complete the 1st operation, and then something goes wrong, e.g. lights out, and we fail to do the 2nd. Both should either succeed (purchase complete, good!) or both fail (at least the person kept their money, so they can retry).
+첫 번째 단계를 완수하고 나서 불이 꺼지는 것과 같이 뭔가 잘못돼서 두 번째 단계에 실패하면 꽤 안 좋을 것입니다. 둘 다 성공해 구매가 완료되거나, 최소한 돈을 보관한 사람이 재시도할 수 있도록 둘 다 실패해야 합니다.
 
-Transactions can guarantee that.
+트랜잭션은 다음을 보장할 수 있습니다.
 
-**All data operations must be made within a transaction in IndexedDB.**
+**모든 데이터 연산은 IndexedDB 내의 트랜잭션에서 수행되어야 합니다.**
 
-To start a transaction:
+트랜잭션을 시작하려면 다음과 같이 해야 합니다.
 
 ```js
 db.transaction(store[, type]);
 ```
 
-- `store` is a store name that the transaction is going to access, e.g. `"books"`. Can be an array of store names if we're going to access multiple stores.
-- `type` – a transaction type, one of:
-  - `readonly` -- can only read, the default.
-  - `readwrite` -- can only read and write the data, but not create/remove/alter object stores.
+- `store`은 트랜잭션이 접근하려는 `"books"`와 같은 저장소 이름입니다. 여러 저장소에 접근하려면 저장소 이름의 배열이 되어야 합니다.
+- `type` – 다음 중 하나인 트랜잭션 타입입니다.
+  - `readonly` -- 기본값인 읽기만 가능합니다.
+  - `readwrite` -- 데이터를 읽고 쓸 수 있을 뿐 객체 저장소를 생성/삭제/변형할 수는 없습니다.
 
-There's also `versionchange` transaction type: such transactions can do everything, but we can't create them manually. IndexedDB automatically creates a `versionchange` transaction when opening the database, for `upgradeneeded` handler. That's why it's a single place where we can update the database structure, create/remove object stores.
+또한 `versionchange` 트랜잭션 타입도 있는데 이러한 트랜잭션은 모든 것을 할 수 있지만, 수동으로 만들 수 없습니다. IndexedDB는 데이터베이스를 열 때 `upgradeneeded` 핸들러를 위해 `versionchange` 트랜잭션을 자동으로 생성합니다. 데이터베이스 구조를 업데이트하고 객체 저장소를 생성/삭제할 수 있는 유일한 장소인 것도 이러한 이유 때문입니다.
 
-```smart header="Why are there different types of transactions?"
-Performance is the reason why transactions need to be labeled either `readonly` and `readwrite`.
+```smart header="다양한 타입의 트랜잭션이 존재하는 이유는 무엇일까요?"
+성능은 트랜잭션이 `readonly`와 `readwrite`로 분류되어야 하는 이유입니다.
 
-Many `readonly` transactions are able to access the same store concurrently, but `readwrite` transactions can't. A `readwrite` transaction "locks" the store for writing. The next transaction must wait before the previous one finishes before accessing the same store.
+많은 `readonly` 트랜잭션은 같은 저장소에 동시에 접근할 수 있지만, `readwrite` 트랜잭션은 그렇지 못합니다. `readwrite` 트랜잭션은 저장소를 쓰기 작업을 위해 "잠급니다". 다음 트랜잭션은 동일한 저장소에 접근하기 전에 이전 트랜잭션이 끝날 때까지 기다려야 합니다.
 ```
 
-After the transaction is created, we can add an item to the store, like this:
+트랜잭션이 생성된 후에는 다음과 같은 아이템을 저장소에 추가할 수 있습니다.
 
 ```js
 let transaction = db.transaction("books", "readwrite"); // (1)
 
-// get an object store to operate on it
+// 저장소 객체에서 연산하기 위해 저장소 객체를 얻습니다.
 *!*
 let books = transaction.objectStore("books"); // (2)
 */!*
@@ -355,47 +314,43 @@ request.onerror = function() {
 };
 ```
 
-There were basically four steps:
+기본적으로 네 가지 단계가 있습니다.
 
-1. Create a transaction, mentioning all the stores it's going to access, at `(1)`.
-2. Get the store object using `transaction.objectStore(name)`, at `(2)`.
-3. Perform the request to the object store `books.add(book)`, at `(3)`.
-4. ...Handle request success/error `(4)`, then we can make other requests if needed, etc.
+1. `(1)`에서 접근할 모든 저장소를 지정하면서 트랜잭션을 생성합니다.
+2. `(2)`에서 `transaction.objectStore(name)`을 사용하여 저장소 객체를 얻습니다.
+3. `(3)`에서 저장소 객체 `books.add(book)`에 요청을 수행합니다.
+4. `(4)`에서 성공/에러 이벤트를 처리하면 필요한 경우 다른 요청도 할 수 있습니다.
 
-Object stores support two methods to store a value:
+객체 저장소는 값을 저장하는 두 가지 함수를 지원합니다.
 
 - **put(value, [key])**
-    Add the `value` to the store. The `key` is supplied only if the object store did not have `keyPath` or `autoIncrement` option. If there's already a value with the same key, it will be replaced.
+    저장소에 `value`를 추가합니다. `key`는 객체 저장소에 `keyPath` 또는 `autoIncrement` 옵션이 없는 경우에만 제공됩니다. 이미 같은 키를 가진 값이 있으면 교체될 수 있습니다.
 
 - **add(value, [key])**
-    Same as `put`, but if there's already a value with the same key, then the request fails, and an error with the name `"ConstraintError"` is generated.
+    `put`과 동일하지만 같은 키를 가진 값이 이미 있으면 요청이 실패하고 `"ConstraintError"` 라는 이름의 에러가 발생합니다.
 
-Similar to opening a database, we can send a request: `books.add(book)`, and then wait for `success/error` events.
+데이터베이스를 여는 것과 마찬가지로 `books.add(book)` 요청을 보낸 다음 `success/error` 이벤트를 기다릴 수 있습니다.
 
-- The `request.result` for `add` is the key of the new object.
-- The error is in `request.error` (if any).
+- `add`에 대한 `request.result`는 새로운 객체의 키입니다.
+- 에러가 있다면 `request.error`에 담깁니다.
 
-## Transactions' autocommit
+## 트랜잭션의 자동 커밋
 
-In the example above we started the transaction and made `add` request. But as we stated previously, a transaction may have multiple associated requests, that must either all succeed or all fail. How do we mark the transaction as finished, with no more requests to come?
+위의 예에서 트랜잭션을 시작했고 `add` 요청을 했습니다. 그러나 앞에서 언급한 바와 같이 트랜잭션에는 모두 성공 또는 모두 실패해야 하는 여러 가지 관련 요청이 있을 수 있습니다. 더 이상의 요청은 없고 트랜잭션을 완료된 것으로 어떻게 표시할까요?
 
-The short answer is: we don't.
+짧은 대답으로는 그렇게 하지 않습니다.
 
-In the next version 3.0 of the specification, there will probably be a manual way to finish the transaction, but right now in 2.0 there isn't.
+설명서의 다음 버전 3.0에서는 트랜잭션을 마칠 수 있는 수동적인 방법이 있겠지만, 현재 버전 2.0에서는 그렇지 않습니다.
 
-**When all transaction requests are finished, and the [microtasks queue](info:microtask-queue) is empty, it is committed automatically.**
+**모든 트랜잭션 요청이 완료되고 [microtasks queue](info:microtask-queue)가 비어있으면 자동으로 커밋됩니다.**
 
-Usually, we can assume that a transaction commits when all its requests are complete, and the current code finishes.
+흔히 모든 요청이 완료되고 현재 코드가 완료될 때 트랜잭션이 커밋된다고 가정할 수 있습니다.
 
-So, in the example above no special call is needed to finish the transaction.
+따라서 위의 예에서 트랜잭션을 완료하기 위해 특별한 호출이 필요하지 않습니다.
 
-Transactions auto-commit principle has an important side effect. We can't insert an async operation like `fetch`, `setTimeout` in the middle of a transaction. IndexedDB will not keep the transaction waiting till these are done.
+트랜잭션 자동 커밋 원칙에는 중요한 부작용이 있습니다. 트랜잭션 중간에 `fetch`, `setTimeout` 같은 비동기 연산은 삽입할 수 없습니다. IndexedDB는 이런 연산이 끝날 때까지 트랜잭션을 유지하지 않습니다.
 
-<<<<<<< HEAD
-In the code below, `request2` in line `(*)` fails, because the transaction is already committed, and can't make any request in it:
-=======
-In the code below, `request2` in the line `(*)` fails, because the transaction is already committed, and can't make any request in it:
->>>>>>> upstream/master
+아래 코드 `(*)`줄에서 `request2`가 실패하면 트랜잭션이 이미 커밋되었기 때문에 해당 코드에서 어떠한 요청도 할 수 없습니다.
 
 ```js
 let request1 = books.add(book);
@@ -412,54 +367,54 @@ request1.onsuccess = function() {
 };
 ```
 
-That's because `fetch` is an asynchronous operation, a macrotask. Transactions are closed before the browser starts doing macrotasks.
+`fetch`는 비동기 연산인 매크로태스크이기 때문입니다. 트랜잭션은 브라우저가 매크로태스크를 시작하기 전에 닫힙니다.
 
-Authors of IndexedDB spec believe that transactions should be short-lived. Mostly for performance reasons.
+IndexedDB 명세 작성자는 대부분 성능상의 이유로 트랜잭션이 짧게 유지되어야 한다고 봅니다.
 
-Notably, `readwrite` transactions "lock" the stores for writing. So if one part of the application initiated `readwrite` on `books` object store, then another part that wants to do the same has to wait: the new transaction "hangs" till the first one is done. That can lead to strange delays if transactions take a long time.
+특히 `readwrite` 트랜잭션은 쓰기 작업을 위해 저장소를 "잠급니다". 따라서 애플리케이션의 한 부분이 `books` 객체 저장소에 대해 `readwrite` 트랜잭션을 시작했다면, 같은 작업을 하려는 다른 부분은 첫 번째 트랜잭션이 끝날 때까지 기다려야 합니다. 트랜잭션이 오래 걸리면 예상치 못한 지연이 생길 수 있습니다.
 
-So, what to do?
+그래서 무엇을 해야 할까요?
 
-In the example above we could make a new `db.transaction` right before the new request `(*)`.
+위의 예에서, 새로운 요청 `(*)` 직전에 새로운 `db.transaction`을 생성할 수 있습니다.
 
-But it will be even better, if we'd like to keep the operations together, in one transaction, to split apart IndexedDB transactions and "other" async stuff.
+하지만 연산을 한 번의 트랜잭션으로 묶어야 한다면, IndexedDB 트랜잭션과 "다른" 비동기 작업을 분리하는 편이 훨씬 낫습니다.
 
-First, make `fetch`, prepare the data if needed, afterwards create a transaction and perform all the database requests, it'll work then.
+먼저 `fetch`를 실행하고 필요하면 데이터를 준비한 다음, 트랜잭션을 생성하여 모든 데이터베이스 요청을 수행하면 동작합니다.
 
-To detect the moment of successful completion, we can listen to `transaction.oncomplete` event:
+성공적으로 완료되는 시점을 잡으려면 `transaction.oncomplete` 이벤트를 사용할 수 있습니다.
 
 ```js
 let transaction = db.transaction("books", "readwrite");
 
-// ...perform operations...
+// ...연산을 수행합니다...
 
 transaction.oncomplete = function() {
   console.log("Transaction is complete");
 };
 ```
 
-Only `complete` guarantees that the transaction is saved as a whole. Individual requests may succeed, but the final write operation may go wrong (e.g. I/O error or something).
+오직 `complete`만 트랜잭션 전체가 저장되었음을 보장합니다. 개별 요청은 성공할 수 있지만, 최종 쓰기 연산이 실패할 수 있습니다. 예를 들어 I/O 에러가 발생할 수 있습니다.
 
-To manually abort the transaction, call:
+트랜잭션을 수동적으로 중단하려면 다음을 호출해 봅시다.
 
 ```js
 transaction.abort();
 ```
 
-That cancels all modification made by the requests in it and triggers `transaction.onabort` event.
+위는 요청에 따라 이루어진 모든 수정을 취소하고 `transaction.onabort` 이벤트를 유발합니다.
 
 
-## Error handling
+## 에러 처리
 
-Write requests may fail.
+쓰기 요청은 실패할 수 있습니다.
 
-That's to be expected, not only because of possible errors at our side, but also for reasons not related to the transaction itself. For instance, the storage quota may be exceeded. So we must be ready to handle such case.
+에러는 우리 코드뿐만 아니라 트랜잭션 자체와 관련이 없는 이유로도 발생할 수 있습니다. 예를 들어 저장소 쿼터가 초과될 수 있습니다. 따라서 이런 경우를 처리할 준비가 되어 있어야 합니다.
 
-**A failed request automatically aborts the transaction, canceling all its changes.**
+**실패한 요청은 트랜잭션을 자동으로 중단하여 모든 변경사항을 취소합니다.**
 
-In some situations, we may want to handle the failure (e.g. try another request), without canceling existing changes, and continue the transaction. That's possible. The `request.onerror` handler is able to prevent the transaction abort by calling `event.preventDefault()`.
+때에 따라서는 기존 변경사항을 취소하지 않고 실패를 처리한 뒤, 예를 들어 다른 요청을 시도한 다음 트랜잭션을 계속하고 싶을 수 있습니다. 가능합니다. `request.onerror` 핸들러는 `event.preventDefault()`를 호출하여 트랜잭션 중단을 방지할 수 있습니다.
 
-In the example below a new book is added with the same key (`id`) as the existing one. The `store.add` method generates a `"ConstraintError"` in that case. We handle it without canceling the transaction:
+아래 예시에서는 새로운 book이 기존과 같은 키(`id`)로 추가됩니다. `store.add` 함수는 이럴 때 `"ConstraintError"`를 발생시키죠. 트랜잭션을 취소하지 않고 처리합니다.
 
 ```js
 let transaction = db.transaction("books", "readwrite");
@@ -469,14 +424,14 @@ let book = { id: 'js', price: 10 };
 let request = transaction.objectStore("books").add(book);
 
 request.onerror = function(event) {
-  // ConstraintError occurs when an object with the same id already exists
+  // 동일한 id를 가진 객체가 이미 있는 경우 ConstraintError가 발생합니다.
   if (request.error.name == "ConstraintError") {
-    console.log("Book with such id already exists"); // handle the error
-    event.preventDefault(); // don't abort the transaction
-    // use another key for the book?
+    console.log("Book with such id already exists"); // 에러를 처리합니다.
+    event.preventDefault(); // 트랜잭션을 중단하지 않습니다.
+    // book을 위한 다른 key를 사용할까요?
   } else {
-    // unexpected error, can't handle it
-    // the transaction will abort
+    // 예기치 않은 에러로, 처리할 수 없습니다.
+    // 트랜잭션이 중단됩니다.
   }
 };
 
@@ -485,126 +440,126 @@ transaction.onabort = function() {
 };
 ```
 
-### Event delegation
+### 이벤트 위임
 
-Do we need onerror/onsuccess for every request? Not every time. We can use event delegation instead.
+모든 요청에 대해 `onerror/onsuccess`를 설정해야 할까요? 매번 그럴 필요는 없습니다. 대신 이벤트 위임을 사용할 수 있습니다.
 
-**IndexedDB events bubble: `request` -> `transaction` -> `database`.**
+**IndexedDB 이벤트는 버블링됩니다. `request` -> `transaction` -> `database`.**
 
-All events are DOM events, with capturing and bubbling, but usually only bubbling stage is used.
+모든 이벤트는 캡처링과 버블링을 가진 DOM 이벤트이지만, 흔히 버블링 단계만 사용됩니다.
 
-So we can catch all errors using `db.onerror` handler, for reporting or other purposes:
+따라서 보고나 다른 목적을 위해 `db.onerror` 핸들러를 사용하여 모든 에러를 잡아낼 수 있습니다.
 
 ```js
 db.onerror = function(event) {
-  let request = event.target; // the request that caused the error
+  let request = event.target; // 에러를 발생시키는 request
 
   console.log("Error", request.error);
 };
 ```
 
-...But what if an error is fully handled? We don't want to report it in that case.
+하지만 에러가 완전히 처리된다면? 그런 경우에는 알리고 싶지 않죠.
 
-We can stop the bubbling and hence `db.onerror` by using `event.stopPropagation()` in `request.onerror`.
+`request.onerror`에서 `event.stopPropagation()`을 사용하면 버블링을 막아 `db.onerror`까지 이벤트가 올라가지 않게 할 수 있습니다.
 
 ```js
 request.onerror = function(event) {
   if (request.error.name == "ConstraintError") {
-    console.log("Book with such id already exists"); // handle the error
-    event.preventDefault(); // don't abort the transaction
-    event.stopPropagation(); // don't bubble error up, "chew" it
+    console.log("Book with such id already exists"); // 에러를 처리합니다.
+    event.preventDefault(); // 트랜잭션을 중단하지 않습니다.
+    event.stopPropagation(); // 에러가 위로 전파되지 않도록 여기서 처리합니다.
   } else {
-    // do nothing
-    // transaction will be aborted
-    // we can take care of error in transaction.onabort
+    // 아무것도 하지 않습니다.
+    // 트랜잭션이 중단됩니다.
+    // transaction.onabort에서 에러를 처리할 수 있습니다.
   }
 };
 ```
 
-## Searching
+## 검색하기
 
-There are two main types of search in an object store:
+객체 저장소에는 다음과 같은 두 가지 유형의 검색이 있습니다.
 
-1. By a key value or a key range. In our "books" storage that would be a value or range of values of `book.id`.
-2. By another object field, e.g. `book.price`. This required an additional data structure, named "index".
+1. 키 값 또는 키 범위로 검색합니다. "books" 저장소에서는 `book.id`의 값 또는 값 범위로 검색하는 것입니다.
+2. `book.price` 같은 다른 객체 필드로 검색합니다. 이 경우 "인덱스"라는 추가 데이터 구조가 필요합니다.
 
-### By key
+### 키로 검색하기
 
-First let's deal with the first type of search: by key.
+먼저 첫 번째 유형인 키를 사용한 검색부터 다뤄 봅시다.
 
-Searching methods support both exact key values and so-called "ranges of values" -- [IDBKeyRange](https://www.w3.org/TR/IndexedDB/#keyrange) objects that specify an acceptable "key range".
+검색 메서드는 정확한 키 값과 이른바 "값 범위"를 모두 지원합니다. [IDBKeyRange](https://www.w3.org/TR/IndexedDB/#keyrange) 객체는 허용되는 "키 범위"를 지정합니다.
 
-`IDBKeyRange` objects are created using following calls:
+`IDBKeyRange` 객체는 다음 호출로 생성합니다.
 
-- `IDBKeyRange.lowerBound(lower, [open])` means: `≥lower` (or `>lower` if `open` is true)
-- `IDBKeyRange.upperBound(upper, [open])` means: `≤upper` (or `<upper` if `open` is true)
-- `IDBKeyRange.bound(lower, upper, [lowerOpen], [upperOpen])` means: between `lower` and `upper`. If the open flags is true, the corresponding key is not included in the range.
-- `IDBKeyRange.only(key)` -- a range that consists of only one `key`, rarely used.
+- `IDBKeyRange.lowerBound(lower, [open])` 의미: `≥lower`. 또는 `open`이 true이면 `>lower`
+- `IDBKeyRange.upperBound(upper, [open])` 의미: `≤upper`. 또는 `open`이 true이면 `<upper`
+- `IDBKeyRange.bound(lower, upper, [lowerOpen], [upperOpen])` 의미: `lower`와 `upper` 사이. open 플래그가 true일 경우 해당 키는 범위에 포함되지 않습니다.
+- `IDBKeyRange.only(key)` -- 거의 사용되지 않는 하나의 `key`로만 구성된 범위입니다.
 
-We'll see practical examples of using them very soon.
+이들을 사용하는 실제 예시는 곧 살펴보겠습니다.
 
-To perform the actual search, there are following methods. They accept a `query` argument that can be either an exact key or a key range:
+실제 검색을 수행할 때 사용하는 메서드는 다음과 같습니다. 각 메서드는 정확한 키나 키 범위를 담은 `query` 인수를 받습니다.
 
-- `store.get(query)` -- search for the first value by a key or a range.
-- `store.getAll([query], [count])` -- search for all values, limit by `count` if given.
-- `store.getKey(query)` -- search for the first key that satisfies the query, usually a range.
-- `store.getAllKeys([query], [count])` -- search for all keys that satisfy the query, usually a range, up to `count` if given.
-- `store.count([query])` -- get the total count of keys that satisfy the query, usually a range.
+- `store.get(query)` -- 키 또는 범위로 첫 번째 값을 검색합니다.
+- `store.getAll([query], [count])` -- 모든 값을 검색합니다. `count`가 주어지면 그 개수까지만 가져옵니다.
+- `store.getKey(query)` -- `query`를 만족시키는 첫 번째 키를 검색합니다. 일반적으로 범위를 사용합니다.
+- `store.getAllKeys([query], [count])` -- `query`를 만족시키는 모든 키를 검색합니다. `count`가 주어지면 그 개수까지만 가져옵니다. 일반적으로 범위를 사용합니다.
+- `store.count([query])` -- `query`를 충족시키는 키의 총 개수를 가져옵니다. 일반적으로 범위를 사용합니다.
 
-For instance, we have a lot of books in our store. Remember, the `id` field is the key, so all these methods can search by `id`.
+예를 들어 저장소에 많은 books가 있습니다. `id` 필드가 키이기 때문에 이 모든 메서드는 `id`로 검색할 수 있다는 점을 기억합시다.
 
-Request examples:
+요청 예제입니다.
 
 ```js
-// get one book
+// book을 얻습니다.
 books.get('js')
 
-// get books with 'css' <= id <= 'html'
+// 'css' <= id <= 'html'로 books를 얻습니다.
 books.getAll(IDBKeyRange.bound('css', 'html'))
 
-// get books with id < 'html'
+// id < 'html'로 books를 얻습니다.
 books.getAll(IDBKeyRange.upperBound('html', true))
 
-// get all books
+// 모든 books를 얻습니다.
 books.getAll()
 
-// get all keys, where id > 'js'
+// id > 'js'인 모든 키를 얻습니다.
 books.getAllKeys(IDBKeyRange.lowerBound('js', true))
 ```
 
-```smart header="Object store is always sorted"
-An object store sorts values by key internally.
+```smart header="저장소 객체는 항상 정렬됩니다."
+객체 저장소는 내부적으로 키를 기준으로 값을 정렬합니다.
 
-So requests that return many values always return them in sorted by key order.
+따라서 많은 값을 반환하는 요청은 항상 키 순서에 따라 정렬된 값을 반환합니다.
 ```
 
-### By a field using an index
+### 인덱스로 필드 검색하기
 
-To search by other object fields, we need to create an additional data structure named "index".
+다른 객체 필드로 검색하려면 "인덱스"라는 이름의 추가적인 데이터 구조를 생성해야 합니다.
 
-An index is an "add-on" to the store that tracks a given object field. For each value of that field, it stores a list of keys for objects that have that value. There will be a more detailed picture below.
+인덱스는 지정된 객체 필드를 추적하는 저장소의 부가 구조입니다. 이 필드의 각 값에 대해 해당 값을 가진 객체의 키 목록을 저장합니다. 아래에 좀 더 자세한 그림이 있습니다.
 
-The syntax:
+구문입니다.
 
 ```js
 objectStore.createIndex(name, keyPath, [options]);
 ```
 
-- **`name`** -- index name,
-- **`keyPath`** -- path to the object field that the index should track (we're going to search by that field),
-- **`option`** -- an optional object with properties:
-  - **`unique`** -- if true, then there may be only one object in the store with the given value at the `keyPath`. The index will enforce that by generating an error if we try to add a duplicate.
-  - **`multiEntry`** -- only used if the value on `keyPath` is an array. In that case, by default, the index will treat the whole array as the key. But if `multiEntry` is true, then the index will keep a list of store objects for each value in that array. So array members become index keys.
+- **`name`** -- 인덱스 이름입니다.
+- **`keyPath`** -- 인덱스가 추적해야 하는 객체 필드의 경로입니다. 이 필드를 기준으로 검색합니다.
+- **`options`** -- 아래 특징을 가진 선택적 객체입니다.
+  - **`unique`** -- true일 경우 `keyPath`에 지정된 값을 가진 객체가 저장소에 하나만 있을 수 있습니다. 중복 값을 추가하려고 하면 인덱스가 에러를 발생시켜 이를 막습니다.
+  - **`multiEntry`** -- `keyPath`의 값이 배열인 경우에만 사용됩니다. 이 경우 기본적으로 인덱스는 전체 배열을 키로 처리하죠. 그러나 `multiEntry`가 true이면 인덱스는 해당 배열의 각 값에 대한 저장소 객체 목록을 보관합니다. 따라서 배열 원소는 인덱스 키가 됩니다.
 
-In our example, we store books keyed by `id`.
+예시에서 `id` 키로 된 books를 저장합니다.
 
-Let's say we want to search by `price`.
+`price`로 검색하길 원한다고 합시다.
 
-First, we need to create an index. It must be done in `upgradeneeded`, just like an object store:
+우선 인덱스를 생성해야 합니다. 객체 저장소와 마찬가지로 반드시 `upgradeneeded`에서 생성해야 합니다.
 
 ```js
 openRequest.onupgradeneeded = function() {
-  // we must create the index here, in versionchange transaction
+  // versionchange 트랜잭션에서 인덱스를 생성해야 합니다.
   let books = db.createObjectStore('books', {keyPath: 'id'});
 *!*
   let index = books.createIndex('price_idx', 'price');
@@ -612,22 +567,22 @@ openRequest.onupgradeneeded = function() {
 };
 ```
 
-- The index will track `price` field.
-- The price is not unique, there may be multiple books with the same price, so we don't set `unique` option.
-- The price is not an array, so `multiEntry` flag is not applicable.
+- 인덱스는 `price` 필드를 추적합니다.
+- `price`는 유일하지 않고 같은 `price`를 가진 book이 여러 개 있을 수 있기 때문에 `unique` 옵션을 설정하지 않습니다.
+- `price`는 배열이 아니기 때문에 `multiEntry` 플래그는 적용할 수 없습니다.
 
-Imagine that our `inventory` has 4 books. Here's the picture that shows exactly what the `index` is:
+`inventory`에 book 네 개가 있다고 상상해 봅시다. 다음 그림은 `index`가 정확히 무엇인지 보여줍니다.
 
 ![](indexeddb-index.svg)
 
-As said, the index for each value of `price` (second argument) keeps the list of keys that have that price.
+앞서 말했듯이, 인덱스는 두 번째 인수인 `price`의 각 값에 대해 그 `price`를 가진 객체의 키 목록을 유지합니다.
 
-The index keeps itself up to date automatically, we don't have to care about it.
+인덱스는 자동으로 최신 상태를 유지하므로 따로 신경 쓰지 않아도 됩니다.
 
-Now, when we want to search for a given price, we simply apply the same search methods to the index:
+이제 지정된 `price`를 검색하고자 할 때 동일한 검색 메서드를 인덱스에 적용하면 됩니다.
 
 ```js
-let transaction = db.transaction("books"); // readonly
+let transaction = db.transaction("books"); // 읽기 전용입니다.
 let books = transaction.objectStore("books");
 let priceIndex = books.index("price_idx");
 
@@ -637,39 +592,39 @@ let request = priceIndex.getAll(10);
 
 request.onsuccess = function() {
   if (request.result !== undefined) {
-    console.log("Books", request.result); // array of books with price=10
+    console.log("Books", request.result); // price=10인 books 배열
   } else {
     console.log("No such books");
   }
 };
 ```
 
-We can also use `IDBKeyRange` to create ranges and looks for cheap/expensive books:
+또한 `IDBKeyRange`를 사용하여 범위를 생성하고 저렴한 book이나 비싼 book을 찾을 수 있습니다.
 
 ```js
-// find books where price <= 5
+// price <= 5인 books를 찾습니다.
 let request = priceIndex.getAll(IDBKeyRange.upperBound(5));
 ```
 
-Indexes are internally sorted by the tracked object field, `price` in our case. So when we do the search, the results are also sorted by `price`.
+이 예시에서 인덱스는 추적하는 객체 필드인 `price`에 따라 내부적으로 정렬됩니다. 그래서 검색 결과도 `price`에 따라 정렬되죠.
 
-## Deleting from store
+## 저장소로부터 삭제하기
 
-The `delete` method looks up values to delete by a query, the call format is similar to `getAll`:
+`delete` 메서드는 쿼리에 의해 삭제되는 값을 검색하며 호출 형식은 `getAll`과 유사합니다.
 
-- **`delete(query)`** -- delete matching values by query.
+- **`delete(query)`** -- query에 일치하는 값을 삭제합니다.
 
-For instance:
+예시입니다.
 
 ```js
-// delete the book with id='js'
+// id='js'인 book을 삭제합니다.
 books.delete('js');
 ```
 
-If we'd like to delete books based on a price or another object field, then we should first find the key in the index, and then call `delete`:
+`price` 또는 다른 객체 필드를 기준으로 book을 삭제하려면, 먼저 인덱스에서 키를 찾은 다음 `delete`를 호출합니다.
 
 ```js
-// find the key where price = 5
+// price = 5인 키를 찾습니다.
 let request = priceIndex.getKey(5);
 
 request.onsuccess = function() {
@@ -678,44 +633,44 @@ request.onsuccess = function() {
 };
 ```
 
-To delete everything:
+모든 것을 지우려면 다음과 같이 해야 합니다.
 
 ```js
-books.clear(); // clear the storage.
+books.clear(); // 저장소를 지웁니다.
 ```
 
-## Cursors
+## 커서
 
-Methods like `getAll/getAllKeys` return an array of keys/values.
+`getAll/getAllKeys`와 같은 메서드는 키/값의 배열을 반환합니다.
 
-But an object storage can be huge, bigger than the available memory. Then `getAll` will fail to get all records as an array.
+그러나 객체 저장소가 사용 가능한 메모리보다 더 클 수 있습니다. 그러면 `getAll`은 모든 레코드를 배열로 가져오는 데 실패하게 되죠.
 
-What to do?
+무엇을 해야 할까요?
 
-Cursors provide the means to work around that.
+커서는 이런 상황을 처리하는 방법을 제공합니다.
 
-**A *cursor* is a special object that traverses the object storage, given a query, and returns one key/value at a time, thus saving memory.**
+**커서는 주어진 쿼리에 맞춰 객체 저장소를 순회하며 키/값을 한 번에 하나씩 반환해 메모리를 절약하는 특수 객체입니다.**
 
-As an object store is sorted internally by key, a cursor walks the store in key order (ascending by default).
+객체 저장소는 내부적으로 키에 따라 정렬되므로, 커서는 기본적으로 오름차순인 키 순서로 저장소를 순회합니다.
 
-The syntax:
+구문입니다.
 
 ```js
-// like getAll, but with a cursor:
+// getAll과 유사하지만 커서가 있는 경우입니다.
 let request = store.openCursor(query, [direction]);
 
-// to get keys, not values (like getAllKeys): store.openKeyCursor
+// getAllKeys처럼 값이 아닌 키를 얻으려면 store.openKeyCursor를 사용합니다.
 ```
 
-- **`query`** is a key or a key range, same as for `getAll`.
-- **`direction`** is an optional argument, which order to use:
-  - `"next"` -- the default, the cursor walks up from the record with the lowest key.
-  - `"prev"` -- the reverse order: down from the record with the biggest key.
-  - `"nextunique"`, `"prevunique"` -- same as above, but skip records with the same key (only for cursors over indexes, e.g. for multiple books with price=5 only the first one will be returned).
+- **`query`**는 `getAll`과 같은 키 또는 키 범위입니다.
+- **`direction`**은 어떤 순서를 사용할지 지정하는 선택적 인수입니다.
+  - `"next"` -- 기본값입니다. 커서는 가장 낮은 키를 가진 레코드부터 올라갑니다.
+  - `"prev"` -- 역순입니다. 가장 큰 키를 가진 레코드부터 내려갑니다.
+  - `"nextunique"`, `"prevunique"` -- 위와 같지만, 동일한 키를 가진 레코드는 건너뜁니다. 예를 들어 `price=5`인 book이 여러 개 있어도 첫 번째 것만 반환됩니다. 인덱스에 대한 커서에서만 사용할 수 있습니다.
 
-**The main difference of the cursor is that `request.onsuccess` triggers multiple times: once for each result.**
+**커서의 주요 차이점은 `request.onsuccess`가 각 결과에 대해 한 번씩 여러 번 발생한다는 점입니다.**
 
-Here's an example of how to use a cursor:
+커서 사용 예시는 다음과 같습니다.
 
 ```js
 let transaction = db.transaction("books");
@@ -723,12 +678,12 @@ let books = transaction.objectStore("books");
 
 let request = books.openCursor();
 
-// called for each book found by the cursor
+// 커서로 찾은 각 book에 대해 호출합니다.
 request.onsuccess = function() {
   let cursor = request.result;
   if (cursor) {
-    let key = cursor.key; // book key (id field)
-    let value = cursor.value; // book object
+    let key = cursor.key; // id 필드인 book 키
+    let value = cursor.value; // book 객체
     console.log(key, value);
     cursor.continue();
   } else {
@@ -737,29 +692,29 @@ request.onsuccess = function() {
 };
 ```
 
-The main cursor methods are:
+주된 커서 메서드는 다음과 같습니다.
 
-- `advance(count)` -- advance the cursor `count` times, skipping values.
-- `continue([key])` -- advance the cursor to the next value in range matching (or immediately after `key` if given).
+- `advance(count)` -- 값을 건너뛰며 커서를 `count`번 앞으로 이동시킵니다.
+- `continue([key])` -- 일치하는 범위 내에서 커서를 다음 값으로 이동시킵니다. `key`가 주어지면 해당 키 바로 다음 값으로 이동합니다.
 
-Whether there are more values matching the cursor or not -- `onsuccess` gets called, and then in `result` we can get the cursor pointing to the next record, or `undefined`.
+커서 조건에 일치하는 값이 더 있든 없든 `onsuccess`는 호출됩니다. 이때 `result`에는 다음 레코드를 가리키는 커서가 들어 있거나, 더 이상 값이 없다면 `undefined`가 들어 있습니다.
 
-In the example above the cursor was made for the object store.
+위의 예시에서 커서는 객체 저장소로 만들어졌습니다.
 
-But we also can make a cursor over an index. As we remember, indexes allow to search by an object field. Cursors over indexes do precisely the same as over object stores -- they save memory by returning one value at a time.
+그러나 인덱스에 대한 커서를 만들 수도 있습니다. 앞서 봤듯이, 인덱스를 사용하면 객체 필드로 검색할 수 있습니다. 인덱스에 대한 커서는 객체 저장소에 대한 커서와 같은 역할을 합니다. 한 번에 하나의 값을 반환해 메모리를 절약하죠.
 
-For cursors over indexes, `cursor.key` is the index key (e.g. price), and we should use `cursor.primaryKey` property for the object key:
+인덱스에 대한 커서의 경우 `cursor.key`는 `price` 같은 인덱스 키이며, 객체 키로는 `cursor.primaryKey` 프로퍼티를 사용해야 합니다.
 
 ```js
 let request = priceIdx.openCursor(IDBKeyRange.upperBound(5));
 
-// called for each record
+// 각 레코드에 대해 호출합니다.
 request.onsuccess = function() {
   let cursor = request.result;
   if (cursor) {
-    let primaryKey = cursor.primaryKey; // next object store key (id field)
-    let value = cursor.value; // next object store object (book object)
-    let key = cursor.key; // next index key (price)
+    let primaryKey = cursor.primaryKey; // id 필드인 다음 객체 저장소 키
+    let value = cursor.value; // 다음 객체 저장소 객체인 book 객체
+    let key = cursor.key; // 다음 인덱스 키인 price
     console.log(key, value);
     cursor.continue();
   } else {
@@ -768,18 +723,18 @@ request.onsuccess = function() {
 };
 ```
 
-## Promise wrapper
+## 프라미스 래퍼
 
-Adding `onsuccess/onerror` to every request is quite a cumbersome task. Sometimes we can make our life easier by using event delegation, e.g. set handlers on the whole transactions, but `async/await` is much more convenient.
+모든 요청에 `onsuccess/onerror`를 추가하는 것은 상당히 번거로운 일입니다. 때로는 전체 트랜잭션에 핸들러를 설치하는 등 이벤트 위임을 이용해 작업을 더 쉽게 만들 수 있지만, `async/await`이 훨씬 편리합니다.
 
-Let's use a thin promise wrapper <https://github.com/jakearchibald/idb> further in this chapter. It creates a global `idb` object with [promisified](info:promisify) IndexedDB methods.
+이 장의 남은 부분에서는 얇은 프라미스 래퍼 <https://github.com/jakearchibald/idb>를 사용해 봅시다. 이 래퍼는 [프라미스화된](info:promisify) IndexedDB 메서드를 가진 전역 `idb` 객체를 생성합니다.
 
-Then, instead of `onsuccess/onerror` we can write like this:
+그러면 `onsuccess/onerror` 대신 다음과 같이 쓸 수 있습니다.
 
 ```js
 let db = await idb.openDB('store', 1, db => {
   if (db.oldVersion == 0) {
-    // perform the initialization
+    // 초기화를 수행합니다.
     db.createObjectStore('books', {keyPath: 'id'});
   }
 });
@@ -799,31 +754,31 @@ try {
 }
 ```
 
-So we have all the sweet "plain async code" and "try..catch" stuff.
+이제 깔끔한 "일반적인 비동기 코드"와 "try..catch"를 모두 사용할 수 있습니다.
 
-### Error handling
+### 에러 처리
 
-If we don't catch an error, then it falls through, till the closest outer `try..catch`.
+에러를 잡아내지 않으면 가장 가까운 바깥 `try..catch`까지 전파됩니다.
 
-An uncaught error becomes an "unhandled promise rejection" event on `window` object.
+잡히지 않은 에러는 `window` 객체의 "unhandled promise rejection" 이벤트가 됩니다.
 
-We can handle such errors like this:
+이런 에러는 다음과 같이 처리할 수 있습니다.
 
 ```js
 window.addEventListener('unhandledrejection', event => {
-  let request = event.target; // IndexedDB native request object
-  let error = event.reason; //  Unhandled error object, same as request.error
-  ...report about the error...
+  let request = event.target; // IndexedDB 네이티브 request 객체입니다.
+  let error = event.reason; // request.error와 같은 처리되지 않은 error 객체입니다.
+  ...에러에 대하여 알립니다...
 });
 ```
 
-### "Inactive transaction" pitfall
+### "비활성 트랜잭션" 함정
 
-As we already know, a transaction auto-commits as soon as the browser is done with the current code and microtasks. So if we put a *macrotask* like `fetch` in the middle of a transaction, then the transaction won't wait for it to finish. It just auto-commits. So the next request in it would fail.
+이미 알고 있는 바와 같이, 브라우저가 현재 코드와 마이크로태스크 처리를 끝내는 즉시 트랜잭션은 자동 커밋됩니다. 그래서 트랜잭션 중간에 `fetch`와 같은 *매크로태스크*를 넣으면 트랜잭션은 그 작업이 끝날 때까지 기다리지 않습니다. 그냥 자동 커밋될 뿐이죠. 따라서 다음 요청은 실패합니다.
 
-For a promise wrapper and `async/await` the situation is the same.
+프라미스 래퍼와 `async/await`도 상황은 마찬가지입니다.
 
-Here's an example of `fetch` in the middle of the transaction:
+다음은 트랜잭션 중간에서 `fetch`를 사용하는 예시입니다.
 
 ```js
 let transaction = db.transaction("inventory", "readwrite");
@@ -836,50 +791,50 @@ await fetch(...); // (*)
 await inventory.add({ id: 'js', price: 10, created: new Date() }); // Error
 ```
 
-The next `inventory.add` after `fetch` `(*)` fails with an "inactive transaction" error, because the transaction is already committed and closed at that time.
+`fetch` `(*)` 이후 다음 `inventory.add`는 트랜잭션이 이미 커밋되고 종료되었기 때문에 "비활성 트랜잭션" 에러로 실패합니다.
 
-The workaround is the same as when working with native IndexedDB: either make a new transaction or just split things apart.
+해결 방법은 네이티브 IndexedDB로 작업할 때와 같습니다. 새로운 트랜잭션을 만들거나 작업을 나누면 됩니다.
 
-1. Prepare the data and fetch all that's needed first.
-2. Then save in the database.
+1. 데이터를 준비하고 필요한 모든 것을 먼저 가져옵니다.
+2. 그런 다음 데이터베이스에 저장합니다.
 
-### Getting native objects
+### 네이티브 객체 얻기
 
-Internally, the wrapper performs a native IndexedDB request, adding `onerror/onsuccess` to it, and returns a promise that rejects/resolves with the result.
+내부적으로 래퍼는 네이티브 IndexedDB 요청을 수행하고 여기에 `onerror/onsuccess`를 추가한 뒤, 결과에 따라 거부되거나 이행되는 프라미스를 반환합니다.
 
-That works fine most of the time. The examples are at the lib page <https://github.com/jakearchibald/idb>.
+대부분의 경우 잘 동작합니다. 예시는 라이브러리 페이지 <https://github.com/jakearchibald/idb>에서 볼 수 있습니다.
 
-In few rare cases, when we need the original `request` object, we can access it as `promise.request` property of the promise:
+드물지만, 원래의 `request` 객체가 필요할 때 프라미스의 `promise.request` 속성으로 접근할 수 있습니다.
 
 ```js
-let promise = books.add(book); // get a promise (don't await for its result)
+let promise = books.add(book); // 프라미스를 얻고 결과를 기다리지 않습니다.
 
-let request = promise.request; // native request object
-let transaction = request.transaction; // native transaction object
+let request = promise.request; // 네이티브 request 객체입니다.
+let transaction = request.transaction; // 네이티브 transaction 객체입니다.
 
-// ...do some native IndexedDB voodoo...
+// ...네이티브 IndexedDB 관련 작업을 수행합니다...
 
-let result = await promise; // if still needed
+let result = await promise; // 여전히 필요하다면
 ```
 
-## Summary
+## 요약
 
-IndexedDB can be thought of as a "localStorage on steroids". It's a simple key-value database, powerful enough for offline apps, yet simple to use.
+IndexedDB는 "강력해진 localStorage"라고 생각할 수 있습니다. 단순한 키-값 데이터베이스로, 오프라인 앱에 적합하면서도 사용이 간편합니다.
 
-The best manual is the specification, [the current one](https://www.w3.org/TR/IndexedDB-2/) is 2.0, but few methods from [3.0](https://w3c.github.io/IndexedDB/) (it's not much different) are partially supported.
+가장 좋은 매뉴얼은 명세입니다. [현재 명세](https://www.w3.org/TR/IndexedDB-2/)는 2.0이지만 [3.0](https://w3c.github.io/IndexedDB/)의 일부 메서드도 부분적으로 지원됩니다. 3.0도 크게 다르지는 않습니다.
 
-The basic usage can be described with a few phrases:
+기본적인 사용법은 다음과 같이 몇 가지 단계로 설명할 수 있습니다.
 
-1. Get a promise wrapper like [idb](https://github.com/jakearchibald/idb).
-2. Open a database: `idb.openDb(name, version, onupgradeneeded)`
-    - Create object storages and indexes in `onupgradeneeded` handler or perform version update if needed.
-3. For requests:
-    - Create transaction `db.transaction('books')` (readwrite if needed).
-    - Get the object store `transaction.objectStore('books')`.
-4. Then, to search by a key, call methods on the object store directly.
-    - To search by an object field, create an index.
-5. If the data does not fit in memory, use a cursor.
+1. [idb](https://github.com/jakearchibald/idb)와 같은 프라미스 래퍼를 얻습니다.
+2. 데이터베이스 열기: `idb.openDb(name, version, onupgradeneeded)`
+    - `onupgradeneeded` 핸들러에 객체 저장소 및 인덱스를 생성하거나 필요한 경우 버전 업데이트를 수행합니다.
+3. 요청하려면 다음과 같이 합니다.
+    - 트랜잭션 `db.transaction('books')`를 생성합니다. 필요하다면 `readwrite`로 생성합니다.
+    - 저장소 객체 `transaction.objectStore('books')`를 얻습니다.
+4. 그런 다음, 키로 검색하려면 객체 저장소의 메서드를 직접 호출합니다.
+    - 객체 필드로 검색하려면 인덱스를 생성합니다.
+5. 데이터가 메모리에 맞지 않으면 커서를 사용합니다.
 
-Here's a small demo app:
+여기에 작은 데모 앱이 있습니다.
 
 [codetabs src="books" current="index.html"]
diff --git a/8-web-components/1-webcomponents-intro/article.md b/8-web-components/1-webcomponents-intro/article.md
index c8080ed96..519fe31c7 100644
--- a/8-web-components/1-webcomponents-intro/article.md
+++ b/8-web-components/1-webcomponents-intro/article.md
@@ -1,10 +1,10 @@
 # 궤도의 높이에서
 
-이 섹션에서는 '웹 컴포넌트(Web components)'에 대한 최신 표준 집합을 설명합니다.
+이 섹션에서는 '웹 컴포넌트'에 대한 최신 표준 집합을 설명합니다.
 
-현재로서 이 표준 규격은 개발 중입니다. 일부 기능은 잘 지원되고 최신 HTML/DOM 표준규격에 통합되어 있으며 일부 기능은 아직 초안 단계에 있습니다. 모든 브라우저에서 예제를 시도할 수 있으며, Google Chrome이 이러한 기능을 갖춘 최신 버전일 것입니다. Google 동료들이 많은 관련 사항을 따른다는 것이 그 이유입니다.
+현재 이 표준 규격은 개발 중입니다. 일부 기능은 잘 지원되고 최신 HTML/DOM 표준 규격에 통합되어 있으며, 일부 기능은 아직 초안 단계에 있습니다. 모든 브라우저에서 예제를 시도할 수 있지만, 이런 기능을 가장 잘 갖춘 브라우저는 최신 Google Chrome일 가능성이 높습니다. Google 동료들이 관련 표준을 적극적으로 따르고 있기 때문입니다.
 
-## 국제 우주정거장과 웹 컴포넌트(Web components) 사이의 공통점
+## 국제 우주정거장과 웹 컴포넌트 사이의 공통점
 
 전체 컴포넌트에 대한 아이디어는 새로운 것이 아닙니다. 이미 많은 프레임워크와 그 밖의 다른 곳에서 사용되고 있습니다.
 
@@ -12,7 +12,7 @@
 
 ![](satellite.jpg)
 
-국제 우주정거장의 모습입니다(ISS).
+국제 우주정거장의 모습입니다.
 
 국제 우주정거장의 대략적인 내부 구성은 다음과 같습니다.
 
@@ -21,20 +21,14 @@
 국제 우주정거장에 대한 설명입니다.
 - 많은 부품으로 이루어져 있습니다.
 - 각 부품은 그 안에 더 작고 많은 부품이 있습니다.
-- 부품들은 매우 복잡한데, 대부분의 웹사이트 보다 훨씬 복잡합니다.
+- 부품들은 매우 복잡한데, 대부분의 웹사이트보다 훨씬 복잡합니다.
 - 부품은 서로 다른 국가들의 팀이 다른 언어를 사용하여 개발합니다.
 
 그리고 우주정거장은 인간이 우주에서 날고, 살아있을 수 있게 해줍니다.
 
-<<<<<<< HEAD
 어떻게 이렇게 복잡한 장치가 만들어졌을까요?
 
-개발을 안정적이고 확장 가능한 수준으로 만들기 위해 또는 그에 가깝게 만들기 위해 어떤 원칙을 빌려올 수 있을까요?
-=======
-How are such complex devices created?
-
-Which principles could we borrow to make our development same-level reliable and scalable? Or, at least, close to it?
->>>>>>> upstream/master
+우리의 개발도 그에 못지않게 안정적이고 확장 가능하게, 적어도 그에 가깝게 만들려면 어떤 원칙을 빌려올 수 있을까요?
 
 ## 컴포넌트 아키텍처
 
@@ -56,27 +50,27 @@ Which principles could we borrow to make our development same-level reliable and
 2. 사용자 정보
 3. 추천 팔로우
 4. 글쓰기 양식
-5. 메시지들(6, 7 포함)
+5. 6, 7을 포함한 메시지들
 
-컴포넌트에는 하위 컴포넌트가 있을 수 있습니다. 예를 들어 메시지는 상위 '메시지 목록' 컴포넌트의 일부일 수 있습니다. 클릭 가능한 사용자 사진 자체는 컴포넌트 등일 수 있습니다.
+컴포넌트에는 하위 컴포넌트가 있을 수 있습니다. 예를 들어 메시지는 상위 '메시지 목록' 컴포넌트의 일부일 수 있습니다. 클릭 가능한 사용자 사진 자체도 컴포넌트일 수 있습니다.
 
 무엇이 컴포넌트인지 어떻게 결정하겠습니까? 그것은 직관, 경험 및 상식에서 비롯됩니다. 일반적으로 컴포넌트는 기능과 페이지의 상호 작용 방식으로 설명할 수 있는 별도의 시각적 개체입니다. 위의 경우 페이지에는 블록이 있으며 각 블록은 고유한 역할을 수행하기에 이러한 컴포넌트를 만드는 것이 논리적입니다.
 
 컴포넌트가 갖춰야 할 것은 다음과 같습니다.
 - 고유한 자바스크립트 클래스
-- 외부코드가 접근할 수 없으며 해당 클래스에서만 관리되는 DOM 구조('캡슐화' 원칙)
-- 구성요소에 적용되는 CSS 스타일
-- 다른 구성요소와 상호작용하기 위한 이벤트, 클래스, 메서드 등을 일컫는 API
+- 외부코드가 접근할 수 없으며 해당 클래스에서만 관리되는 캡슐화된 DOM 구조
+- 컴포넌트에 적용되는 CSS 스타일
+- 다른 컴포넌트와 상호작용하기 위한 이벤트, 클래스, 메서드 등을 일컫는 API
 
 다시 한번 말하지만, 전체 '컴포넌트'는 특별한 것이 아닙니다.
 
-컴포넌트를 구축하기 위한 많은 프레임워크와 개발 방법론이 존재하는데, 각각은 특수한 기능이 있습니다. 일반적으로 CSS 범위지정과 DOM 캡슐화와 같은 '컴포넌트 느낌'을 제공하기 위해 특수 CSS 클래스 및 규칙이 사용됩니다.
+컴포넌트를 구축하기 위한 많은 프레임워크와 개발 방법론이 존재하는데, 각각은 특수한 기능이 있습니다. 일반적으로 CSS 범위 지정과 DOM 캡슐화와 같은 '컴포넌트 느낌'을 제공하기 위해 특수 CSS 클래스 및 규칙이 사용됩니다.
 
-'웹 컴포넌트(Web components)'는 특수 CSS 클래스 및 규칙을 위해 내장된 브라우저 기능을 제공하므로 더 모방할 필요가 없습니다.
+'웹 컴포넌트'는 특수 CSS 클래스와 규칙을 대신할 내장 브라우저 기능을 제공하므로, 더 이상 이를 흉내 낼 필요가 없습니다.
 
 - [Custom elements](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements) -- 사용자 정의 HTML 요소를 정의하는 데 사용됩니다.
 - [Shadow DOM](https://dom.spec.whatwg.org/#shadow-trees) -- 다른 컴포넌트에 대해 숨겨져 있는 내부 DOM을 생성하는 데 사용됩니다.
 - [CSS Scoping](https://drafts.csswg.org/css-scoping/) -- 컴포넌트의 Shadow DOM 내부에만 적용되는 스타일을 선언하는 데 사용됩니다.
 - [Event retargeting](https://dom.spec.whatwg.org/#retarget)과 사용자 정의 컴포넌트를 개발 환경에 더욱 적합하게 만드는 다른 사소한 것들도 있습니다.
 
-다음 챕터에서는 웹 컴포넌트(Web components)의 기본적이고 잘 지원되는 기능인 '커스텀 엘리먼트'에 대해 자세히 살펴보겠습니다.
+다음 챕터에서는 웹 컴포넌트의 기본적이고 잘 지원되는 기능인 '커스텀 엘리먼트'에 대해 자세히 살펴보겠습니다.