[문서] C20 충돌 해결 및 번역 진행 by seoyoonyi · Pull Request #1869 · javascript-tutorial/ko.javascript.info

seoyoonyi · 2026-05-16T16:37:27Z

요약

upstream 동기화 과정에서 발생한 C20 담당 범위의 충돌을 작업했습니다.
원문에서 추가·변경된 내용은 기존 번역에 반영했습니다.
충돌 마커를 모두 제거했습니다.

변경 파일 (5개)

1-js/11-async/

01-callbacks/article.md — 콜백 문서 충돌 정리
02-promise-basics/article.md — 프라미스 기본 문서 충돌 정리 및 finally, Promise.any 관련 변경 반영
03-promise-chaining/article.md — 프라미스 체이닝 문서 충돌 정리
04-promise-error-handling/article.md — 에러 처리 요약 변경 반영
05-promise-api/article.md — Promise API 문서 충돌 정리 및 Promise.any 내용 추가

연관 이슈

이슈 미생성

Pull Request 체크리스트

TODO

번역 규칙을 확인하셨나요?
- 줄 바꿈과 단락을 '원문과 동일하게' 유지하셨나요?
- 맞춤법 검사기로 맞춤법을 확인하셨나요?
- 마크다운 문법에 사용되는 공백(스페이스), 큰따옴표("), 작은따옴표('), 대시(-), 백틱(`) 등의 특수문자는 그대로 두셨나요?
로컬 서버 세팅 후 최종 결과물을 확인해 보셨나요?
PR 하나엔 번역문 하나만 넣으셨나요?
의미 있는 커밋 메시지를 작성하셨나요?
- 예시
  - [프락시] 번역
  - [프락시] 과제 번역
  - [if문과 조건부 연산자 '?'] 리뷰
  - [주석] 2차 리뷰
  - [Date 객체와 날짜] 번역

CLAassistant · 2026-05-16T16:37:34Z

All committers have signed the CLA.

hyemimi · 2026-05-22T05:45:22Z

  alert(`${script.src}가 로드되었습니다.`);
-  alert( _ ); // 스크립트에 정의된 함수
-=======
-  alert(`Cool, the script ${script.src} is loaded`);


요 부분 번역 누락된 것 같아 보이는데 확인 부탁드립니다!

hyemimi · 2026-05-22T06:10:35Z

 2. executor는 인자로 `resolve`와 `reject` 함수를 받습니다. 이 함수들은 자바스크립트 엔진이 미리 정의한 함수이므로 개발자가 따로 만들 필요가 없습니다. 다만, `resolve`나 `reject` 중 하나는 반드시 호출해야 합니다.

-<<<<<<< HEAD
    executor '처리'가 시작 된 지 1초 후, `resolve("완료")`이 호출되고 결과가 만들어집니다. 이때 `promise` 객체의 상태는 다음과 같이 변합니다.


시작 된 지 -> 시작된 지로 맞춤법 수정 부탁드립니다!

Suggested change

executor '처리'가 시작 된 지 1초 후, `resolve("완료")`이 호출되고 결과가 만들어집니다. 이때 `promise` 객체의 상태는 다음과 같이 변합니다.

executor '처리'가 시작된 지 1초 후, `resolve("완료")`이 호출되고 결과가 만들어집니다. 이때 `promise` 객체의 상태는 다음과 같이 변합니다.

hyemimi · 2026-05-22T06:26:02Z

-<<<<<<< HEAD
 프라미스가 처리되면(이행이나 거부) `f`가 항상 실행된다는 점에서 `.finally(f)` 호출은 `.then(f, f)`과 유사합니다.

+`finally`의 목적은 이전 작업이 완료된 후 정리/마무리 작업을 수행하는 핸들러를 설정하는 것입니다.


짝을 이루는 단어의 경우 한글 번역에서는 가운뎃점 혹은 쉼표/연결어로 작성한다고 합니다. 번역모범사례-짝을이루는단어

'정리/마무리 작업을 수행하는 핸들러' -> '정리·마무리 작업을 수행하는 핸들러' 로 제안드리고 싶은데 어떻게 생각하시나요?

Suggested change

`finally`의 목적은 이전 작업이 완료된 후 정리/마무리 작업을 수행하는 핸들러를 설정하는 것입니다.

`finally`의 목적은 이전 작업이 완료된 후 정리·마무리 작업을 수행하는 핸들러를 설정하는 것입니다.

혹은 연결어 사용도 좋아보입니다.

hyemimi · 2026-05-22T06:33:11Z

 ```

-<<<<<<< HEAD
 그런데 finally는 `.then(f, f)`과 완전히 같진 않습니다. 차이점은 다음과 같습니다.


Please note that finally(f) isn't exactly an alias of then(f,f) though.
위의 영어 원문처럼 finally → finally(f) 로 변경하면 더 정확할 것 같습니다.

hyemimi · 2026-05-22T06:34:27Z

    ```js run
    new Promise((resolve, reject) => {
-      setTimeout(() => resolve("value"), 2000);
+      setTimeout(() => resolve("값"), 2000)


코드 영역이니 세미 콜론을 없애는 쪽보단 있는 쪽이 더 정확할 것 같습니다.

hyemimi · 2026-05-22T06:37:31Z

-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` 핸들러는 결과와 에러를 다음 핸들러로 그대로 전달합니다.


영어 원문에서는

A finally handler "passes through" the result or error to the next suitable handler.

'or'로 연결하고 있기 때문에 '결과나 에러'로 수정 부탁드립니다.

hyemimi · 2026-05-22T06:45:51Z

+  보다시피 첫 번째 프라미스가 반환한 `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`는 프라미스 결과를 처리하기 위한 메서드가 아니기 때문입니다. 앞서 설명했듯 결과와 관계없이 공통적인 정리 작업을 수행하는 곳입니다.


해당 문장이 제가 읽기엔 살짝 어색하게 느껴져서, 아래와 같이 제안드립니다~

Suggested change

이는 매우 편리한 동작입니다. `finally`는 프라미스 결과를 처리하기 위한 메서드가 아니기 때문입니다. 앞서 설명했듯 결과와 관계없이 공통적인 정리 작업을 수행하는 곳입니다.

`finally`는 프라미스의 결과를 처리하는 용도가 아니기 때문에 이런 동작은 결과와 관계없이 마무리 작업이 필요할 때 유용합니다.

hyemimi · 2026-05-22T06:56:58Z

- When `finally` throws an error, then the execution goes to the nearest error handler.
+- `finally` 핸들러는 이전 핸들러의 결과를 받지 않습니다(인수가 없습니다). 결과는 대신 다음 적절한 핸들러로 전달됩니다.
+- `finally` 핸들러가 무언가를 반환하면 무시됩니다.
+- `finally`에서 에러가 발생하면 가장 가장 가까운 에러 핸들러로 전달됩니다.


Suggested change

- `finally`에서 에러가 발생하면 가장 가장 가까운 에러 핸들러로 전달됩니다.

- `finally`에서 에러가 발생하면 가장 가까운 에러 핸들러로 전달됩니다.

'가장 가장 가까운' 오타가 있는 것 같습니다!

hyemimi · 2026-05-22T06:58:01Z

-In such case, these handlers just run immediately:
->>>>>>> upstream/master
+````smart header="처리된 프라미스에도 핸들러를 등록할 수 있습니다"
+프라미스가 대기 상태라면 .then/catch/finally 핸들러는 결과를 기다립니다.


영어 원문과 비교해볼 때, 백틱이 빠진 것 같습니다!

If a promise is pending, .then/catch/finally handlers wait for its outcome.

Suggested change

프라미스가 대기 상태라면 .then/catch/finally 핸들러는 결과를 기다립니다.

프라미스가 대기 상태라면 `.then/catch/finally` 핸들러는 결과를 기다립니다.

hyemimi · 2026-05-22T07:01:04Z

+가수와 팬, 구독리스트 시나리오보다 프라미스가 더 강력하게 만드는 이유가 바로 이런 기능 때문입니다. 가수가 신곡을 발표한 이후에 구독 리스트에 이름을 올리는 팬은 신곡 발표 여부를 알 수 없습니다. 구독 리스트에 이름을 올리는 것이 선행되어야 새로운 소식을 받을 수 있기 때문이죠. 

 그런데 프라미스는 핸들러를 언제든 추가할 수 있다는 점에서 구독리스트 시나리오보다 더 유연합니다. 결과가 나와 있는 상태에서도 핸들러를 등록하면 결과를 바로 받을 수 있습니다.


'구독 리스트', '구독리스트'

사소하지만 띄어쓰거나 붙여쓰는 것 둘 중 하나로 통일하는 것을 제안드립니다! (개인적으로 띄어쓰는 게 적절해보입니다!)

hyemimi · 2026-05-22T07:06:01Z

-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`을 호출할 수 있습니다.
+


혹시 요 줄바꿈은 없어도 되는 건가욥 !?

hyemimi · 2026-05-22T07:07:46Z

-=======
-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`를 순차적으로 전달하지 않고 독립적으로 처리합니다.


Suggested change

예시의 프라미스는 하나인데 여기에 등록된 핸들러는 여러 개입니다. 이 핸들러들은 `result`를 순차적으로 전달하지 않고 독립적으로 처리합니다.

예시의 프라미스는 하나인데 여기에 등록된 핸들러는 여러 개입니다. 이 핸들러들은 결과를 순차적으로 전달하지 않고 독립적으로 처리합니다.

영어 원문에서도 result는 백틱으로 감싸져 있지 않아서 저는 '결과'로 번역해보았는데 어떻게 생각하시나요 !?

hyemimi · 2026-05-22T07:15:03Z

 - `.catch` 는 프라미스에서 발생한 모든 에러를 다룹니다. `reject()`가 호출되거나 에러가 던져지면 `.catch`에서 이를 처리합니다.
+- `.then`도 두 번째 인수(에러 핸들러)가 주어지면 같은 방식으로 에러를 잡을 수 있습니다.
 - `.catch`는 에러를 처리하고 싶은 지점에 정확히 위치시켜야 합니다. 물론 어떻게 에러를 처리할지 알고 있어야 하죠. 핸들러에선 에러를 분석하고(커스텀 에러 클래스가 이때 도움이 됩니다) 알 수 없는 에러(프로그래밍 실수로 발생한 에러일 확률이 높습니다)는 다시 던질 수 있습니다.   
 - 에러 발생 시, 회복할 방법이 없다면 `.catch`를 사용하지 않아도 괜찮습니다.


Suggested change

- 에러 발생 시, 회복할 방법이 없다면 `.catch`를 사용하지 않아도 괜찮습니다.

- 에러가 발생했을 때 복구할 방법이 없다면 `.catch`를 아예 사용하지 않아도 됩니다.

'회복' 이라는 단어보다는 '복구'가 조금 더 자연스럽게 느껴지는데 어떻게 생각하시나요?!
사소하지만 위와 같이 제안드립니다!

hyemimi · 2026-05-22T07:23:01Z

-The new promise resolves when all listed promises are resolved, and the array of their results becomes its result.
->>>>>>> upstream/master
+`Promise.all`은 이터러블(보통은 프라미스 배열)을 받고 새로운 프라미스를 반환합니다. 
+배열 안 프라미스가 모두 성공적으로 처리되면 새로운 프라미스가 이행되는데, 배열 안 프라미스의 결괏값을 담은 배열이 새로운 프라미스의 `result`가 됩니다.


영어 원문에서도 백틱으로 result를 감싸고 있지 않은데,
아래와 같이 결과로 대체하는 건 어떻게 생각하시나요?

Suggested change

배열 안 프라미스가 모두 성공적으로 처리되면 새로운 프라미스가 이행되는데, 배열 안 프라미스의 결괏값을 담은 배열이 새로운 프라미스의 `result`가 됩니다.

배열 안 프라미스가 모두 성공적으로 처리되면 새로운 프라미스가 이행되는데, 배열 안 프라미스의 결괏값을 담은 배열이 새로운 프라미스의 결과가 됩니다.

hyemimi · 2026-05-22T07:25:16Z

 ## 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` 프로퍼티에 저장하는 특별한 에러 객체입니다.


오류 -> 에러 교체 제안드립니다!

Suggested change

`Promise.race`와 비슷하지만, 가장 먼저 이행된 프라미스의 결과만 기다린다는 점이 다릅니다. 전달받은 프라미스가 모두 거부되면 반환된 프라미스는 [`AggregateError`](mdn:js/AggregateError)와 함께 거부됩니다. `AggregateError`는 모든 프라미스 오류를 `errors` 프로퍼티에 저장하는 특별한 에러 객체입니다.

`Promise.race`와 비슷하지만, 가장 먼저 이행된 프라미스의 결과만 기다린다는 점이 다릅니다. 전달받은 프라미스가 모두 거부되면 반환된 프라미스는 [`AggregateError`](mdn:js/AggregateError)와 함께 거부됩니다. `AggregateError`는 모든 프라미스 에러를 `errors` 프로퍼티에 저장하는 특별한 에러 객체입니다.

hyemimi · 2026-05-22T07:26:22Z

 ```

-As you can see, error objects for failed promises are available in the `errors` property of the `AggregateError` object.
+위 예시에서 볼 수 있듯 실패한 프라미스의 에러 객체는 `AggregateError` 객체의 errors 프로퍼티에서 확인할 수 있습니다.


백틱 추가 요청드립니다~

Suggested change

위 예시에서 볼 수 있듯 실패한 프라미스의 에러 객체는 `AggregateError` 객체의 errors 프로퍼티에서 확인할 수 있습니다.

위 예시에서 볼 수 있듯 실패한 프라미스의 에러 객체는 `AggregateError` 객체의 `errors` 프로퍼티에서 확인할 수 있습니다.

hyemimi

번역 수고 많으셨습니다👍👍

일단 1차적으로 리뷰 완료했습니다. 논의 필요한 부분이나 수정 필요한 부분은 코멘트로 남겨두었습니다!
리뷰 관련해서 궁금하신 점이나, 이견 있으시면 편하게 남겨주세요~!
개인적으로 리뷰 하면서 새롭게 추가된 프로미스 메소드도 알게 된 것 같아서 너무 유익한 것 같네요 ㅎㅎ

javascript-translate-bot · 2026-05-22T07:38:26Z