From 15cf21dbc12cbd1b8ccaf6118d40428f9def002d Mon Sep 17 00:00:00 2001
From: seoyoonyi <yiseoyoon@gmail.com>
Date: Sun, 17 May 2026 01:29:28 +0900
Subject: [PATCH 1/5] =?UTF-8?q?[=EC=BD=9C=EB=B0=B1]=20upstream=20=EB=B3=91?=
 =?UTF-8?q?=ED=95=A9=20=EC=B6=A9=EB=8F=8C=20=ED=95=B4=EA=B2=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 1-js/11-async/01-callbacks/article.md | 40 ++-------------------------
 1 file changed, 3 insertions(+), 37 deletions(-)

diff --git a/1-js/11-async/01-callbacks/article.md b/1-js/11-async/01-callbacks/article.md
index 50111613c..b9ff1c638 100644
--- a/1-js/11-async/01-callbacks/article.md
+++ b/1-js/11-async/01-callbacks/article.md
@@ -28,11 +28,7 @@ function loadScript(src) {
 }
 ```
 
-<<<<<<< HEAD
 함수 `loadScript(src)`는 `<script src="…">`를 동적으로 만들고 이를 문서에 추가합니다. 브라우저는 자동으로 태그에 있는 스크립트를 불러오고, 로딩이 완료되면 스크립트를 실행합니다.
-=======
-It inserts into the document a new, dynamically created, tag `<script src="…">` with the given `src`. The browser automatically starts loading it and executes when complete.
->>>>>>> upstream/master
 
 `loadScript(src)` 사용법은 다음과 같습니다.
 
@@ -81,13 +77,9 @@ function loadScript(src, *!*callback*/!*) {
 }
 ```
 
-<<<<<<< HEAD
-새롭게 불러온 스크립트에 있는 함수를 콜백 함수 안에서 호출하면 원하는 대로 외부 스크립트 안의 함수를 사용할 수 있습니다. 
-=======
-The `onload` event is described in the article <info:onload-onerror#loading-a-script>, it basically executes a function after the script is loaded and executed.
+`onload` 이벤트는 <info:onload-onerror#loading-a-script> 글에서 자세히 다룹니다. 기본적으로 스크립트가 로드되고 실행된 후 함수를 호출합니다.
 
-Now if we want to call new functions from the script, we should write that in the callback:
->>>>>>> upstream/master
+새롭게 불러온 스크립트에 있는 함수를 콜백 함수 안에서 호출하면 원하는 대로 외부 스크립트 안의 함수를 사용할 수 있습니다. 
 
 ```js
 loadScript('/my/script.js', function() {
@@ -111,13 +103,8 @@ function loadScript(src, callback) {
 
 *!*
 loadScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/3.2.0/lodash.js', script => {
-<<<<<<< HEAD
   alert(`${script.src}가 로드되었습니다.`);
-  alert( _ ); // 스크립트에 정의된 함수
-=======
-  alert(`Cool, the script ${script.src} is loaded`);
-  alert( _ ); // _ is a function declared in the loaded script
->>>>>>> upstream/master
+  alert( _ ); // _는 로드된 스크립트에 선언된 함수입니다
 });
 */!*
 ```
@@ -211,15 +198,9 @@ loadScript('/my/script.js', function(error, script) {
 
 ## 멸망의 피라미드
 
-<<<<<<< HEAD
 콜백 기반 비동기 처리는 언뜻 봤을 때 꽤 쓸만해 보이고, 실제로도 그렇습니다. 한 개 혹은 두 개의 중첩 호출이 있는 경우는 보기에도 나쁘지 않습니다. 
 
 하지만 꼬리에 꼬리를 무는 비동기 동작이 많아지면 아래와 같은 코드 작성이 불가피해집니다.
-=======
-At first glance, it looks like a viable approach to asynchronous coding. And indeed it is. For one or maybe two nested calls it looks fine.
-
-But for multiple asynchronous actions that follow one after another, we'll have code like this:
->>>>>>> upstream/master
 
 ```js
 loadScript('1.js', function(error, script) {
@@ -249,17 +230,10 @@ loadScript('1.js', function(error, script) {
 });
 ```
 
-<<<<<<< HEAD
 위 코드는 다음과 같이 동작합니다.
 1. `1.js`를 로드합니다. 그 후 에러가 없으면,
 2. `2.js`를 로드합니다. 그 후 에러가 없으면,
 3. `3.js`를 로드합니다. 그 후 에러가 없으면 `(*)`로 표시한 줄에서 또 다른 작업을 수행합니다.
-=======
-In the code above:
-1. We load `1.js`, then if there's no error...
-2. We load `2.js`, then if there's no error...
-3. We load `3.js`, then if there's no error -- do something else `(*)`.
->>>>>>> upstream/master
 
 호출이 계속 중첩되면서 코드가 깊어지고 있네요. 본문 중간중간 `...`로 표시한 곳에 반복문과 조건문이 있는 코드가 들어가면 관리는 특히나 더 힘들어질 겁니다.
 
@@ -327,11 +301,7 @@ function step3(error, script) {
 }
 ```
 
-<<<<<<< HEAD
 어떤가요? 새롭게 작성한 코드는 각 동작을 분리해 최상위 레벨의 함수로 만들었기 때문에 깊은 중첩이 없습니다. 그리고 콜백 기반 스타일 코드와 동일하게 동작하죠.
-=======
-See? It does the same thing, and there's no deep nesting now because we made every action a separate top-level function.
->>>>>>> upstream/master
 
 그런데 이렇게 작성하면 동작상의 문제는 없지만, 코드가 찢어진 종잇조각 같아 보인다는 문제가 생깁니다. 읽는 것도 어려워지죠. 눈을 이리저리 움직이며 코드를 읽어야 합니다. 코드에 익숙지 않아 눈을 어디로 옮겨야 할지 모르면 더욱더 불편할 것입니다.
 
@@ -339,8 +309,4 @@ See? It does the same thing, and there's no deep nesting now because we made eve
 
 지금쯤이면 더 나은 무언가가 필요하다는 생각이 강하게 들 겁니다.
 
-<<<<<<< HEAD
 운 좋게도, 멸망의 피라미드를 피할 방법이 몇 가지 있습니다. 가장 좋은 방법 중 하나는 다음 챕터에서 설명할 '프라미스(promise)'를 사용하는 것입니다.
-=======
-Luckily, there are other ways to avoid such pyramids. One of the best ways is to use "promises", described in the next chapter.
->>>>>>> upstream/master

From 09f7b410909bde763d0277e93283573102dbc7d3 Mon Sep 17 00:00:00 2001
From: seoyoonyi <yiseoyoon@gmail.com>
Date: Sun, 17 May 2026 01:29:38 +0900
Subject: [PATCH 2/5] =?UTF-8?q?[=ED=94=84=EB=9D=BC=EB=AF=B8=EC=8A=A4=20?=
 =?UTF-8?q?=EA=B8=B0=EC=B4=88]=20upstream=20=EB=B3=91=ED=95=A9=20=EC=B6=A9?=
 =?UTF-8?q?=EB=8F=8C=20=ED=95=B4=EA=B2=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 1-js/11-async/02-promise-basics/article.md | 179 +++++----------------
 1 file changed, 41 insertions(+), 138 deletions(-)

diff --git a/1-js/11-async/02-promise-basics/article.md b/1-js/11-async/02-promise-basics/article.md
index a96227562..e0a12db26 100644
--- a/1-js/11-async/02-promise-basics/article.md
+++ b/1-js/11-async/02-promise-basics/article.md
@@ -1,18 +1,10 @@
 # 프라미스
 
-<<<<<<< HEAD
-본인을 아주 유명한 가수라고 가정해 봅시다. 그리고 탑 가수인 본인이 밤, 낮으로 다음 싱글 앨범이 언제 나오는지 물어보는 팬들을 상대해야 한다고 해 봅시다. 
-=======
-Imagine that you're a top singer, and fans ask day and night for your upcoming song.
->>>>>>> upstream/master
+본인을 아주 유명한 가수라고 가정해 봅시다. 그리고 탑 가수인 본인이 밤, 낮으로 다음 곡이 언제 나오는지 물어보는 팬들을 상대해야 한다고 해 봅시다. 
 
 당신은 앨범이 출시되면 팬들이 자동으로 소식을 받아볼 수 있도록 해 부하를 덜 겁니다. 구독 리스트를 하나 만들어 팬들에게 전달해 이메일 주소를 적게 하고, 앨범이 준비되면 리스트에 있는 팬들에게 메일을 보내 앨범 관련 소식을 바로 받아볼 수 있게 하는 식으로 말이죠. 이렇게 하면 녹음 스튜디오에 화재가 발생해서 출시 예정인 앨범이 취소되는 불상사가 발생해도 관련 소식을 팬들에게 전달 할 수 있습니다.
 
-<<<<<<< HEAD
-이제 모두가 행복해졌습니다. 밤낮으로 질문을 하는 팬이 사라졌고, 팬들은 앨범 출시를 놓치지 않을 수 있게 되었으니까요.
-=======
-Everyone is happy: you, because the people don't crowd you anymore, and fans, because they won't miss the song.
->>>>>>> upstream/master
+이제 모두가 행복해졌습니다. 밤낮으로 질문을 하는 팬이 사라졌고, 팬들은 새 곡 출시를 놓치지 않을 수 있게 되었으니까요.
 
 이 비유는 코드를 작성하면서 자주 만나는 상황을 실제 일어날 법한 일로 바꾼 것입니다. 바로 아래 같은 상황 말이죠.
 
@@ -36,27 +28,15 @@ executor의 인수 `resolve`와 `reject`는 자바스크립트에서 자체 제
 
 대신 executor에선 결과를 즉시 얻든 늦게 얻든 상관없이 상황에 따라 인수로 넘겨준 콜백 중 하나를 반드시 호출해야 합니다.
 
-<<<<<<< HEAD
 - `resolve(value)` — 일이 성공적으로 끝난 경우 그 결과를 나타내는 `value`와 함께 호출
 - `reject(error)` — 에러 발생 시 에러 객체를 나타내는 `error`와 함께 호출
 
 요약하면 다음과 같습니다. executor는 자동으로 실행되는데 여기서 원하는 일이 처리됩니다. 처리가 끝나면 executor는 처리 성공 여부에 따라 `resolve`나 `reject`를 호출합니다.
-=======
-- `resolve(value)` — if the job is finished successfully, with result `value`.
-- `reject(error)` — if an error has occurred, `error` is the error object.
-
-So to summarize: the executor runs automatically and attempts to perform a job. When it is finished with the attempt, it calls `resolve` if it was successful or `reject` if there was an error.
->>>>>>> upstream/master
 
 한편, `new Promise` 생성자가 반환하는 `promise` 객체는 다음과 같은 내부 프로퍼티를 갖습니다.
 
-<<<<<<< HEAD
-- `state` — 처음엔 `"pending"`(보류)이었다 `resolve`가 호출되면 `"fulfilled"`, `reject`가 호출되면 `"rejected"`로 변합니다.
-- `result` — 처음엔 `undefined`이었다 `resolve(value)`가 호출되면 `value`로, `reject(error)`가 호출되면 `error`로 변합니다.
-=======
-- `state` — initially `"pending"`, then changes to either `"fulfilled"` when `resolve` is called or `"rejected"` when `reject` is called.
-- `result` — initially `undefined`, then changes to `value` when `resolve(value)` is called or `error` when `reject(error)` is called.
->>>>>>> upstream/master
+- `state` — 처음엔 `"pending"`(보류)이었다가 `resolve`가 호출되면 `"fulfilled"`, `reject`가 호출되면 `"rejected"`로 변합니다.
+- `result` — 처음엔 `undefined`이었다가 `resolve(value)`가 호출되면 `value`로, `reject(error)`가 호출되면 `error`로 변합니다.
 
 따라서 executor는 아래 그림과 같이 `promise`의 상태를 둘 중 하나로 변화시킵니다.
 
@@ -80,11 +60,7 @@ let promise = new Promise(function(resolve, reject) {
 1. executor는 `new Promise`에 의해 자동으로 그리고 즉각적으로 호출됩니다.
 2. executor는 인자로 `resolve`와 `reject` 함수를 받습니다. 이 함수들은 자바스크립트 엔진이 미리 정의한 함수이므로 개발자가 따로 만들 필요가 없습니다. 다만, `resolve`나 `reject` 중 하나는 반드시 호출해야 합니다.
 
-<<<<<<< HEAD
     executor '처리'가 시작 된 지 1초 후, `resolve("완료")`이 호출되고 결과가 만들어집니다. 이때 `promise` 객체의 상태는 다음과 같이 변합니다.
-=======
-    After one second of "processing", the executor calls `resolve("done")` to produce the result. This changes the state of the `promise` object:
->>>>>>> upstream/master
 
     ![](promise-resolve-1.svg)
 
@@ -151,15 +127,9 @@ let promise = new Promise(function(resolve, reject) {
 프라미스 객체의 `state`, `result` 프로퍼티는 내부 프로퍼티이므로 개발자가 직접 접근할 수 없습니다. `.then`/`.catch`/`.finally` 메서드를 사용하면 접근 가능한데, 자세한 내용은 아래에서 살펴보겠습니다.
 ```
 
-<<<<<<< HEAD
-## 소비자: then, catch, finally
-
-프라미스 객체는 executor('제작 코드' 혹은 '가수')와 결과나 에러를 받을 소비 함수('팬')를 이어주는 역할을 합니다. 소비함수는 `.then`, `.catch`, `.finally` 메서드를 사용해 등록(구독)됩니다.
-=======
-## Consumers: then, catch
+## 소비자: then, catch
 
-A Promise object serves as a link between the executor (the "producing code" or "singer") and the consuming functions (the "fans"), which will receive the result or error. Consuming functions can be registered (subscribed) using the methods `.then` and `.catch`.
->>>>>>> upstream/master
+프라미스 객체는 executor('제작 코드' 혹은 '가수')와 결과나 에러를 받을 소비 함수('팬')를 이어주는 역할을 합니다. 소비함수는 `.then`, `.catch` 메서드를 사용해 등록(구독)됩니다.
 
 ### then
 
@@ -174,15 +144,9 @@ promise.then(
 );
 ```
 
-<<<<<<< HEAD
 `.then`의 첫 번째 인수는 프라미스가 이행되었을 때 실행되는 함수이고, 여기서 실행 결과를 받습니다.
 
 `.then`의 두 번째 인수는 프라미스가 거부되었을 때 실행되는 함수이고, 여기서 에러를 받습니다.
-=======
-The first argument of `.then` is a function that runs when the promise is resolved and receives the result.
-
-The second argument of `.then` is a function that runs when the promise is rejected and receives the error.
->>>>>>> upstream/master
 
 아래 예시는 성공적으로 이행된 프라미스에 어떻게 반응하는지 보여줍니다.
 
@@ -252,128 +216,78 @@ promise.catch(alert); // 1초 뒤 "Error: 에러 발생!" 출력
 
 `try {...} catch {...}`에 finally 절이 있는 것처럼, 프라미스에도 `finally`가 있습니다.
 
-<<<<<<< HEAD
 프라미스가 처리되면(이행이나 거부) `f`가 항상 실행된다는 점에서 `.finally(f)` 호출은 `.then(f, f)`과 유사합니다.
 
+`finally`의 목적은 이전 작업이 완료된 후 정리/마무리 작업을 수행하는 핸들러를 설정하는 것입니다.
+
 쓸모가 없어진 로딩 인디케이터(loading indicator)를 멈추는 경우같이, 결과가 어떻든 마무리가 필요하면 `finally`가 유용합니다.
 
-사용법은 아래와 같습니다.
+예를 들면 로딩 인디케이터를 멈추거나 더 이상 필요 없는 연결을 닫는 작업 등이 있습니다.
+
+파티 뒷정리 담당자라고 생각해보세요. 파티가 즐거웠든 아니든, 친구가 얼마나 왔든 상관없이 파티가 끝나면 뒷정리는 해야 하니까요.
+
+코드는 아래와 같은 형태가 됩니다.
 
 ```js
 new Promise((resolve, reject) => {
-  /* 시간이 걸리는 어떤 일을 수행하고, 그 후 resolve, reject를 호출함 */
+  /* 시간이 걸리는 작업을 수행한 후 resolve 또는 reject를 호출 */
 })
 *!*
   // 성공·실패 여부와 상관없이 프라미스가 처리되면 실행됨
   .finally(() => 로딩 인디케이터 중지)
-=======
-The call `.finally(f)` is similar to `.then(f, f)` in the sense that `f` runs always, when the promise is settled: be it resolve or reject.
-
-The idea of `finally` is to set up a handler for performing cleanup/finalizing after the previous operations are complete.
-
-E.g. stopping loading indicators, closing no longer needed connections, etc.
-
-Think of it as a party finisher. Irresepective of whether a party was good or bad, how many friends were in it, we still need (or at least should) do a cleanup after it.
-
-The code may look like this:
+  // 다음 단계로 넘어가기 전에 로딩 인디케이터는 항상 중지됨
 
-```js
-new Promise((resolve, reject) => {
-  /* do something that takes time, and then call resolve or maybe reject */
-})
-*!*
-  // runs when the promise is settled, doesn't matter successfully or not
-  .finally(() => stop loading indicator)
-  // so the loading indicator is always stopped before we go on
->>>>>>> upstream/master
 */!*
   .then(result => result와 err 보여줌 => error 보여줌)
 ```
 
-<<<<<<< HEAD
 그런데 finally는 `.then(f, f)`과 완전히 같진 않습니다. 차이점은 다음과 같습니다.
 
-1. `finally` 핸들러엔 인수가 없습니다. `finally`에선 프라미스가 이행되었는지, 거부되었는지 알 수 없습니다. `finally`에선 절차를 마무리하는 '보편적' 동작을 수행하기 때문에 성공·실패 여부를 몰라도 됩니다.
-2. `finally` 핸들러는 자동으로 다음 핸들러에 결과와 에러를 전달합니다.
+1. `finally` 핸들러에는 인수가 없습니다. `finally`에서는 프라미스가 이행되었는지 거부되었는지 알 수 없습니다. 하지만 이는 문제가 되지 않습니다. `finally`의 목적은 보통 '공통적인' 마무리 작업을 수행하는 것이기 때문입니다.
 
-    result가 `finally`를 거쳐 `then`까지 전달되는 것을 확인해봅시다.
-    ```js run
-    new Promise((resolve, reject) => {
-      setTimeout(() => resolve("결과"), 2000)
-    })
-      .finally(() => alert("프라미스가 준비되었습니다."))
-      .then(result => alert(result)); // <-- .then에서 result를 다룰 수 있음
-    ```
+  위 예시를 보면 `finally` 핸들러에는 인수가 없습니다. 프라미스 결과는 다음 핸들러에서 처리됩니다.
 
-    프라미스에서 에러가 발생하고 이 에러가 `finally`를 거쳐 `catch`까지 전달되는 것을 확인해봅시다.
-=======
-Please note that `finally(f)` isn't exactly an alias of `then(f,f)` though.
-
-There are important differences:
-
-1. A `finally` handler has no arguments. In `finally` we don't know whether the promise is successful or not. That's all right, as our task is usually to perform "general" finalizing procedures.
-
-    Please take a look at the example above: as you can see, the `finally` handler has no arguments, and the promise outcome is handled by the next handler.
-2. A `finally` handler "passes through" the result or error to the next suitable handler.
-
-    For instance, here the result is passed through `finally` to `then`:
+2. `finally` 핸들러는 결과와 에러를 다음 핸들러로 그대로 전달합니다.
 
+    result가 `finally`를 거쳐 `then`까지 전달되는 것을 확인해봅시다.
     ```js run
     new Promise((resolve, reject) => {
-      setTimeout(() => resolve("value"), 2000);
+      setTimeout(() => resolve("값"), 2000)
     })
-      .finally(() => alert("Promise ready")) // triggers first
-      .then(result => alert(result)); // <-- .then shows "value"
+      .finally(() => alert("프라미스가 준비되었습니다.")) // 가장 먼저 실행
+      .then(result => alert(result)); // <-- .then이 "value" 출력
     ```
 
-    As you can see, the `value` returned by the first promise is passed through `finally` to the next `then`.
+  보다시피 첫 번째 프라미스가 반환한 `value`는 `finally`를 거쳐 다음 `then`으로 전달됩니다.
 
-    That's very convenient, because `finally` is not meant to process a promise result. As said, it's a place to do generic cleanup, no matter what the outcome was.
+  이는 매우 편리한 동작입니다. `finally`는 프라미스 결과를 처리하기 위한 메서드가 아니기 때문입니다. 앞서 설명했듯 결과와 관계없이 공통적인 정리 작업을 수행하는 곳입니다.
 
-    And here's an example of an error, for us to see how it's passed through `finally` to `catch`:
->>>>>>> upstream/master
+  아래는 에러가 `finally`를 거쳐 `catch`로 전달되는 예시입니다.
 
     ```js run
     new Promise((resolve, reject) => {
       throw new Error("에러 발생!");
     })
-<<<<<<< HEAD
-      .finally(() => alert("프라미스가 준비되었습니다."))
-      .catch(err => alert(err)); // <-- .catch에서 에러 객체를 다룰 수 있음
-    ```  
 
-    `finally`는 프라미스 결과를 처리하기 위해 만들어 진 게 아닙니다. 프라미스 결과는 `finally`를 통과해서 전달되죠. 이런 특징은 아주 유용하게 사용되기도 합니다. 
-
-    프라미스 체이닝과 핸들러 간 결과 전달에 대해선 다음 챕터에서 더 이야기 나누도록 하겠습니다.
-
-3. `.finally(f)`는 함수 `f`를 중복해서 쓸 필요가 없기 때문에 `.then(f, f)`보다 문법 측면에서 더 편리합니다.
-
-````smart header="처리된 프라미스의 핸들러는 즉각 실행됩니다."
-프라미스가 대기 상태일 때, `.then/catch/finally` 핸들러는 프라미스가 처리되길 기다립니다. 반면, 프라미스가 이미 처리상태라면 핸들러가 즉각 실행됩니다.
-=======
-      .finally(() => alert("Promise ready")) // triggers first
-      .catch(err => alert(err));  // <-- .catch shows the error
+      .finally(() => alert("프라미스가 준비되었습니다.")) // 먼저 실행됨
+      .catch(err => alert(err)); // <-- .catch에서 에러를 출력함
     ```
 
-3. A `finally` handler also shouldn't return anything. If it does, the returned value is silently ignored.
-
-    The only exception to this rule is when a `finally` handler throws an error. Then this error goes to the next handler, instead of any previous outcome.
+3. `finally` 핸들러는 아무것도 반환하지 않아야 합니다. 무언가를 반환하더라도 반환값은 무시됩니다.
+  단, `finally` 핸들러에서 에러를 던지는 경우는 예외입니다. 이 경우 에러는 이전 결과 대신 다음 핸들러로 전달됩니다.
 
-To summarize:
+요약하면 다음과 같습니다.
 
-- A `finally` handler doesn't get the outcome of the previous handler (it has no arguments). This outcome is passed through instead, to the next suitable handler.
-- If a `finally` handler returns something, it's ignored.
-- When `finally` throws an error, then the execution goes to the nearest error handler.
+- `finally` 핸들러는 이전 핸들러의 결과를 받지 않습니다(인수가 없습니다). 결과는 대신 다음 적절한 핸들러로 전달됩니다.
+- `finally` 핸들러가 무언가를 반환하면 무시됩니다.
+- `finally`에서 에러가 발생하면 가장 가장 가까운 에러 핸들러로 전달됩니다.
 
-These features are helpful and make things work just the right way if we use `finally` how it's supposed to be used: for generic cleanup procedures.
+이런 특징 덕분에 `finally`를 원래 목적대로 공통적인 정리 작업에 사용한다면 모든 것이 올바르게 동작합니다.
 
-````smart header="We can attach handlers to settled promises"
-If a promise is pending, `.then/catch/finally` handlers wait for its outcome.
-
-Sometimes, it might be that a promise is already settled when we add a handler to it.
-
-In such case, these handlers just run immediately:
->>>>>>> upstream/master
+````smart header="처리된 프라미스에도 핸들러를 등록할 수 있습니다"
+프라미스가 대기 상태라면 .then/catch/finally 핸들러는 결과를 기다립니다.
+핸들러를 등록할 때 프라미스가 이미 처리된 상태일 수도 있습니다.
+이런 경우 핸들러는 즉시 실행됩니다.
 
 ```js run
 // 아래 프라미스는 생성과 동시에 이행됩니다.
@@ -382,29 +296,18 @@ let promise = new Promise(resolve => resolve("완료!"));
 promise.then(alert); // 완료! (바로 출력됨)
 ```
 
-<<<<<<< HEAD
-가수와 팬, 구독리스트 시나리오보다 프라미스가 더 복잡하다고 말한 이유가 바로 이런 기능 때문입니다. 가수가 신곡을 발표한 이후에 구독 리스트에 이름을 올리는 팬은 신곡 발표 여부를 알 수 없습니다. 구독 리스트에 이름을 올리는 것이 선행되어야 새로운 소식을 받을 수 있기 때문이죠. 
+가수와 팬, 구독리스트 시나리오보다 프라미스가 더 강력하게 만드는 이유가 바로 이런 기능 때문입니다. 가수가 신곡을 발표한 이후에 구독 리스트에 이름을 올리는 팬은 신곡 발표 여부를 알 수 없습니다. 구독 리스트에 이름을 올리는 것이 선행되어야 새로운 소식을 받을 수 있기 때문이죠. 
 
 그런데 프라미스는 핸들러를 언제든 추가할 수 있다는 점에서 구독리스트 시나리오보다 더 유연합니다. 결과가 나와 있는 상태에서도 핸들러를 등록하면 결과를 바로 받을 수 있습니다.
 ````
 
-이제 실제 동작하는 예시를 보며 프라미스로 어떻게 비동기 동작을 처리하는지 살펴봅시다.
 
 ## 예시: loadScript [#loadscript]
 
-이전 챕터에서 스크립트 로딩에 사용되는 함수 `loadScript`를 작성해 보았습니다.
-=======
-Note that this makes promises more powerful than the real life "subscription list" scenario. If the singer has already released their song and then a person signs up on the subscription list, they probably won't receive that song. Subscriptions in real life must be done prior to the event.
-
-Promises are more flexible. We can add handlers any time: if the result is already there, they just execute.
-````
-
-## Example: loadScript [#loadscript]
+이제 실제 동작하는 예시를 보며 프라미스로 어떻게 비동기 동작을 처리하는지 살펴봅시다.
 
-Next, let's see more practical examples of how promises can help us write asynchronous code.
+이전 챕터에서 스크립트 로딩에 사용되는 함수 `loadScript`를 작성해 보았습니다.
 
-We've got the `loadScript` function for loading a script from the previous chapter.
->>>>>>> upstream/master
 
 복습 차원에서 콜백 기반으로 작성한 함수를 다시 살펴봅시다.
 

From ef692550f0b1c026ea094e1a7de1fae4cdf009fb Mon Sep 17 00:00:00 2001
From: seoyoonyi <yiseoyoon@gmail.com>
Date: Sun, 17 May 2026 01:29:50 +0900
Subject: [PATCH 3/5] =?UTF-8?q?[=ED=94=84=EB=9D=BC=EB=AF=B8=EC=8A=A4=20?=
 =?UTF-8?q?=EC=B2=B4=EC=9D=B4=EB=8B=9D]=20upstream=20=EB=B3=91=ED=95=A9=20?=
 =?UTF-8?q?=EC=B6=A9=EB=8F=8C=20=ED=95=B4=EA=B2=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 1-js/11-async/03-promise-chaining/article.md | 37 +++-----------------
 1 file changed, 5 insertions(+), 32 deletions(-)

diff --git a/1-js/11-async/03-promise-chaining/article.md b/1-js/11-async/03-promise-chaining/article.md
index 2f53760a9..c439e0cb6 100644
--- a/1-js/11-async/03-promise-chaining/article.md
+++ b/1-js/11-async/03-promise-chaining/article.md
@@ -34,29 +34,18 @@ new Promise(function(resolve, reject) {
 
 프라미스 체이닝은 `result`가 `.then` 핸들러의 체인(사슬)을 통해 전달된다는 점에서 착안한 아이디어입니다.
 
-<<<<<<< HEAD
 위 예시는 아래와 같은 순서로 실행됩니다.
 1. 1초 후 최초 프라미스가 이행됩니다. -- `(*)`
-2. 이후 첫번째 `.then` 핸들러가 호출됩니다. --`(**)`
-3. 2에서 반환한 값은 다음 `.then` 핸들러에 전달됩니다. -- `(***)`
+2. 이후 첫 번째 `.then` 핸들러가 호출됩니다. 결괏값이 2인 새로운 프라미스를 생성합니다. --`(**)`
+3. 다음 `.then`은 이전 결과를 받아 처리하고(두 배로 증가) 다음 핸들러에 전달합니다. -- `(***)`
 4. 이런 과정이 계속 이어집니다.
-=======
-Here the flow is:
-1. The initial promise resolves in 1 second `(*)`,
-2. Then the `.then` handler is called `(**)`, which in turn creates a new promise (resolved with `2` value).
-3. The next `then` `(***)` gets the result of the previous one, processes it (doubles) and passes it to the next handler.
-4. ...and so on.
->>>>>>> upstream/master
 
 `result`가 핸들러 체인을 따라 전달되므로, `alert` 창엔 `1`, `2`, `4`가 순서대로 출력됩니다.
 
 ![](promise-then-chain.svg)
 
-<<<<<<< HEAD
-프라미스 체이닝이 가능한 이유는 `promise.then`을 호출하면 프라미스가 반환되기 때문입니다. 반환된 프라미스엔 당연히 `.then`을 호출할 수 있습니다.
-=======
-The whole thing works, because every call to a `.then` returns a new promise, so that we can call the next `.then` on it.
->>>>>>> upstream/master
+프라미스 체이닝이 가능한 이유는 `.then`을 호출할 때마다 새로운 프라미스가 반환되기 때문입니다. 반환된 프라미스엔 당연히 `.then`을 호출할 수 있습니다.
+
 
 한편 핸들러가 값을 반환할 때엔 이 값이 프라미스의 `result`가 됩니다. 따라서 다음 `.then`은 이 값을 이용해 호출됩니다.
 
@@ -84,11 +73,7 @@ promise.then(function(result) {
 });
 ```
 
-<<<<<<< HEAD
-예시의 프라미스는 하나인데 여기에 등록된 핸들러는 여러 개 입니다. 이 핸들러들은 `result`를 순차적으로 전달하지 않고 독립적으로 처리합니다.
-=======
-What we did here is just adding several handlers to one promise. They don't pass the result to each other; instead they process it independently.
->>>>>>> upstream/master
+예시의 프라미스는 하나인데 여기에 등록된 핸들러는 여러 개입니다. 이 핸들러들은 `result`를 순차적으로 전달하지 않고 독립적으로 처리합니다.
 
 그림으로 표현하면 다음과 같습니다. 프라미스 체이닝을 묘사한 위 그림과 비교해 보세요.
 
@@ -136,12 +121,8 @@ new Promise(function(resolve, reject) {
 });
 ```
 
-<<<<<<< HEAD
 예시에서 첫 번째 `.then`은 `1`을 출력하고 `new Promise(…)`를 반환(`(*)`)합니다.   
 1초 후 이 프라미스가 이행되고 그 결과(`resolve`의 인수인 `result * 2`)는 두 번째 `.then`으로 전달됩니다. 두 번째 핸들러(`(**)`)는 `2`를 출력하고 동일한 과정이 반복됩니다.
-=======
-Here the first `.then` shows `1` and returns `new Promise(…)` in the line `(*)`. After one second it resolves, and the result (the argument of `resolve`, here it's `result * 2`) is passed on to the handler of the second `.then`. That handler is in the line `(**)`, it shows `2` and does the same thing.
->>>>>>> upstream/master
 
 따라서 얼럿 창엔 이전 예시와 동일하게 1, 2, 4가 차례대로 출력됩니다. 다만 얼럿 창 사이에 1초의 딜레이가 생깁니다.
 
@@ -245,11 +226,7 @@ new Promise(resolve => resolve(1))
 
 ## fetch와 체이닝 함께 응용하기
 
-<<<<<<< HEAD
 프론트 단에선, 네트워크 요청 시 프라미스를 자주 사용합니다. 이에 관련된 예시를 살펴봅시다. 
-=======
-In frontend programming, promises are often used for network requests. So let's see an extended example of that.
->>>>>>> upstream/master
 
 예시에선 메서드 [fetch](info:fetch)를 사용해 원격 서버에서 사용자 정보를 가져오겠습니다. `fetch`엔 다양한 선택 매개변수가 있는데 자세한 내용은  [별도의 챕터](info:fetch)에서 다루기로 하고, 여기선 기본 문법만 사용해 보겠습니다.
 
@@ -290,11 +267,7 @@ fetch('/article/promise-chaining/user.json')
 
 불러온 사용자 정보를 가지고 무언가를 더 해보겠습니다.
 
-<<<<<<< HEAD
 GitHub에 요청을 보내 사용자 프로필을 불러오고 아바타를 출력해 보는 것같이 말이죠.
-=======
-For instance, we can make one more request to GitHub, load the user profile and show the avatar:
->>>>>>> upstream/master
 
 ```js run
 // user.json에 요청을 보냅니다.

From 278b89400dffb5234575daf83bd65b05589e0fb0 Mon Sep 17 00:00:00 2001
From: seoyoonyi <yiseoyoon@gmail.com>
Date: Sun, 17 May 2026 01:30:12 +0900
Subject: [PATCH 4/5] =?UTF-8?q?[=ED=94=84=EB=9D=BC=EB=AF=B8=EC=8A=A4?=
 =?UTF-8?q?=EC=99=80=20=EC=97=90=EB=9F=AC=20=ED=95=B8=EB=93=A4=EB=A7=81]?=
 =?UTF-8?q?=20upstream=20=EB=B3=91=ED=95=A9=20=EC=B6=A9=EB=8F=8C=20?=
 =?UTF-8?q?=ED=95=B4=EA=B2=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 1-js/11-async/04-promise-error-handling/article.md | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/1-js/11-async/04-promise-error-handling/article.md b/1-js/11-async/04-promise-error-handling/article.md
index 3ed957999..d7542e6f8 100644
--- a/1-js/11-async/04-promise-error-handling/article.md
+++ b/1-js/11-async/04-promise-error-handling/article.md
@@ -198,15 +198,8 @@ Node.js같은 기타 호스트 환경에도 처리하지 못한 에러를 다루
 
 ## 요약
 
-<<<<<<< HEAD
 - `.catch` 는 프라미스에서 발생한 모든 에러를 다룹니다. `reject()`가 호출되거나 에러가 던져지면 `.catch`에서 이를 처리합니다.
+- `.then`도 두 번째 인수(에러 핸들러)가 주어지면 같은 방식으로 에러를 잡을 수 있습니다.
 - `.catch`는 에러를 처리하고 싶은 지점에 정확히 위치시켜야 합니다. 물론 어떻게 에러를 처리할지 알고 있어야 하죠. 핸들러에선 에러를 분석하고(커스텀 에러 클래스가 이때 도움이 됩니다) 알 수 없는 에러(프로그래밍 실수로 발생한 에러일 확률이 높습니다)는 다시 던질 수 있습니다.   
 - 에러 발생 시, 회복할 방법이 없다면 `.catch`를 사용하지 않아도 괜찮습니다.
 - `unhandledrejection` 이벤트 핸들러를 사용해 처리되지 않은 에러를 추적하고, 이를 사용자(혹은 서버에)에게 알려서 애플리케이션이 아무런 설명도 없이 '그냥 죽는걸' 방지합시다. 브라우저 환경에선 예방에 `unhandledrejection`을, 다른 환경에선 유사한 핸들러를 사용할 수 있습니다.
-=======
-- `.catch` handles errors in promises of all kinds: be it a `reject()` call, or an error thrown in a handler.
-- `.then` also catches errors in the same manner, if given the second argument (which is the error handler).
-- We should place `.catch` exactly in places where we want to handle errors and know how to handle them. The handler should analyze errors (custom error classes help) and rethrow unknown ones (maybe they are programming mistakes).
-- It's ok not to use `.catch` at all, if there's no way to recover from an error.
-- In any case we should have the `unhandledrejection` event handler (for browsers, and analogs for other environments) to track unhandled errors and inform the user (and probably our server) about them, so that our app never "just dies".
->>>>>>> upstream/master

From e2bb750298226ce84af7a8dd17840a44b18d4871 Mon Sep 17 00:00:00 2001
From: seoyoonyi <yiseoyoon@gmail.com>
Date: Sun, 17 May 2026 01:30:15 +0900
Subject: [PATCH 5/5] =?UTF-8?q?[=ED=94=84=EB=9D=BC=EB=AF=B8=EC=8A=A4=20API?=
 =?UTF-8?q?]=20upstream=20=EB=B3=91=ED=95=A9=20=EC=B6=A9=EB=8F=8C=20?=
 =?UTF-8?q?=ED=95=B4=EA=B2=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 1-js/11-async/05-promise-api/article.md | 59 +++++++------------------
 1 file changed, 15 insertions(+), 44 deletions(-)

diff --git a/1-js/11-async/05-promise-api/article.md b/1-js/11-async/05-promise-api/article.md
index 01a461b98..98e281bf3 100644
--- a/1-js/11-async/05-promise-api/article.md
+++ b/1-js/11-async/05-promise-api/article.md
@@ -1,10 +1,6 @@
 # 프라미스 API
 
-<<<<<<< HEAD
-`Promise` 클래스에는 5가지 정적 메서드가 있습니다. 이번 챕터에선 다섯 메서드의 유스 케이스에 대해서 빠르게 알아보겠습니다.
-=======
-There are 6 static methods in the `Promise` class. We'll quickly cover their use cases here.
->>>>>>> upstream/master
+`Promise` 클래스에는 6가지 정적 메서드가 있습니다. 이번 챕터에선 여섯 메서드의 유스 케이스에 대해서 빠르게 알아보겠습니다.
 
 ## Promise.all
 
@@ -20,15 +16,8 @@ There are 6 static methods in the `Promise` class. We'll quickly cover their use
 let promise = Promise.all(iterable);
 ```
 
-<<<<<<< HEAD
-`Promise.all`은 요소 전체가 프라미스인 배열(엄밀히 따지면 이터러블 객체이지만, 대개는 배열임)을 받고 새로운 프라미스를 반환합니다.
-
-배열 안 프라미스가 모두 처리되면 새로운 프라미스가 이행되는데, 배열 안 프라미스의 결괏값을 담은 배열이 새로운 프라미스의 `result`가 됩니다.
-=======
-`Promise.all` takes an iterable (usually, an array of promises) and returns a new promise.
-
-The new promise resolves when all listed promises are resolved, and the array of their results becomes its result.
->>>>>>> upstream/master
+`Promise.all`은 이터러블(보통은 프라미스 배열)을 받고 새로운 프라미스를 반환합니다. 
+배열 안 프라미스가 모두 성공적으로 처리되면 새로운 프라미스가 이행되는데, 배열 안 프라미스의 결괏값을 담은 배열이 새로운 프라미스의 `result`가 됩니다.
 
 아래 `Promise.all`은 3초 후에 처리되고, 반환되는 프라미스의 `result`는 배열 `[1, 2, 3]`이 됩니다.
 
@@ -227,20 +216,17 @@ Promise.race([
 첫 번째 프라미스가 가장 빨리 처리상태가 되기 때문에 첫 번째 프라미스의 결과가 result 값이 됩니다. 이렇게 `Promise.race`를 사용하면 '경주(race)의 승자'가 나타난 순간 다른 프라미스의 결과 또는 에러는 무시됩니다.
 
 
-<<<<<<< HEAD
-## Promise.resolve와 Promise.reject
-=======
 ## Promise.any
 
-Similar to `Promise.race`, but waits only for the first fulfilled promise and gets its result. If all of the given promises are rejected, then the returned promise is rejected with [`AggregateError`](mdn:js/AggregateError) - a special error object that stores all promise errors in its `errors` property.
+`Promise.race`와 비슷하지만, 가장 먼저 이행된 프라미스의 결과만 기다린다는 점이 다릅니다. 전달받은 프라미스가 모두 거부되면 반환된 프라미스는 [`AggregateError`](mdn:js/AggregateError)와 함께 거부됩니다. `AggregateError`는 모든 프라미스 오류를 `errors` 프로퍼티에 저장하는 특별한 에러 객체입니다.
 
-The syntax is:
+문법은 다음과 같습니다.
 
 ```js
 let promise = Promise.any(iterable);
 ```
 
-For instance, here the result will be `1`:
+아래 예시의 결과는 `1`입니다.
 
 ```js run
 Promise.any([
@@ -250,9 +236,9 @@ Promise.any([
 ]).then(alert); // 1
 ```
 
-The first promise here was fastest, but it was rejected, so the second promise became the result. After the first fulfilled promise "wins the race", all further results are ignored.
+첫 번째 프라미스가 가장 빨리 처리되었지만 거부되었기 때문에 두 번째 프라미스가 결과가 됩니다. 가장 먼저 이행된 프라미스가 '경주에서 승리'하면 이후 결과는 모두 무시됩니다.
 
-Here's an example when all promises fail:
+모든 프라미스가 실패하는 예시는 다음과 같습니다.
 
 ```js run
 Promise.any([
@@ -265,10 +251,9 @@ Promise.any([
 });
 ```
 
-As you can see, error objects for failed promises are available in the `errors` property of the `AggregateError` object.
+위 예시에서 볼 수 있듯 실패한 프라미스의 에러 객체는 `AggregateError` 객체의 errors 프로퍼티에서 확인할 수 있습니다.
 
 ## Promise.resolve/reject
->>>>>>> upstream/master
 
 프라미스 메서드 `Promise.resolve`와 `Promise.reject`는 `async/await` 문법([뒤에서](info:async-await) 다룸)이 생긴 후로 쓸모없어졌기 때문에 근래에는 거의 사용하지 않습니다.
 
@@ -323,29 +308,15 @@ let promise = new Promise((resolve, reject) => reject(error));
 
 ## 요약
 
-<<<<<<< HEAD
-`Promise` 클래스에는 5가지 정적 메서드가 있습니다.
+`Promise` 클래스에는 6가지 정적 메서드가 있습니다.
 
 1. `Promise.all(promises)` -- 모든 프라미스가 이행될 때까지 기다렸다가 그 결괏값을 담은 배열을 반환합니다. 주어진 프라미스 중 하나라도 실패하면 `Promise.all`는 거부되고, 나머지 프라미스의 결과는 무시됩니다.
 2. `Promise.allSettled(promises)` -- 최근에 추가된 메서드로 모든 프라미스가 처리될 때까지 기다렸다가 그 결과(객체)를 담은 배열을 반환합니다. 객체엔 다음과 같은 정보가 담깁니다.
     - `status`: `"fulfilled"` 또는 `"rejected"`
     - `value`(프라미스가 성공한 경우) 또는 `reason`(프라미스가 실패한 경우)
 3. `Promise.race(promises)` -- 가장 먼저 처리된 프라미스의 결과 또는 에러를 담은 프라미스를 반환합니다.
-4. `Promise.resolve(value)` -- 주어진 값을 사용해 이행 상태의 프라미스를 만듭니다.
-5. `Promise.reject(error)` -- 주어진 에러를 사용해 거부 상태의 프라미스를 만듭니다.
-
-실무에선 다섯 메서드 중 `Promise.all`을 가장 많이 사용합니다.
-=======
-There are 6 static methods of `Promise` class:
-
-1. `Promise.all(promises)` -- waits for all promises to resolve and returns an array of their results. If any of the given promises rejects, it becomes the error of `Promise.all`, and all other results are ignored.
-2. `Promise.allSettled(promises)` (recently added method) -- waits for all promises to settle and returns their results as an array of objects with:
-    - `status`: `"fulfilled"` or `"rejected"`
-    - `value` (if fulfilled) or `reason` (if rejected).
-3. `Promise.race(promises)` -- waits for the first promise to settle, and its result/error becomes the outcome.
-4. `Promise.any(promises)` (recently added method) -- waits for the first promise to fulfill, and its result becomes the outcome. If all of the given promises are rejected, [`AggregateError`](mdn:js/AggregateError) becomes the error of `Promise.any`.
-5. `Promise.resolve(value)` -- makes a resolved promise with the given value.
-6. `Promise.reject(error)` -- makes a rejected promise with the given error.
-
-Of all these, `Promise.all` is probably the most common in practice.
->>>>>>> upstream/master
+4. `Promise.any(promises)` -- 최근에 추가된 메서드로 가장 먼저 이행되는 프라미스를 기다렸다가 그 결괏값을 반환합니다. 주어진 프라미스가 모두 거부되면 [`AggregateError`](mdn:js/AggregateError)가 `Promise.any`의 에러가 됩니다.
+5. `Promise.resolve(value)` -- 주어진 값을 사용해 이행 상태의 프라미스를 만듭니다.
+6. `Promise.reject(error)` -- 주어진 에러를 사용해 거부 상태의 프라미스를 만듭니다.
+
+실무에선 이 중 `Promise.all`을 가장 많이 사용합니다.
\ No newline at end of file