Merge branch 'main' into typo-data

Author: lumirlumir

src/content/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022.md

@@ -69,9 +69,9 @@ Vercel 및 Shopify와 협력하여 Webpack 및 Vite 모두에서 공유 시맨
 
 개발자가 각각의 느린 커밋 그 자체의 발생 여부나, context에서 벗어난 컴포넌트에 대해 아는 것은 그다지 유용하지 않다는 것을 깨달았습니다. 실제로 느린 커밋의 원인을 아는 것이 더 유용합니다. 그리고 개발자는 특정 상호 작용(예: 버튼 클릭, 초기 로드 또는 페이지 탐색)을 추적하여 성능을 회귀적으로 관찰하고 상호 작용이 느린 이유와 해결 방법을 이해할 수 있기를 원합니다.
 
-이전에는 [인터랙션 추적 API](https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16)를 만들어 이 문제를 해결하려고 했지만, 이 API는 근본적인 설계 결함으로 인해 인터랙션이 느린 이유를 추적하는 정확도가 떨어지고 때로는 인터랙션이 끝나지 않는 경우가 있었습니다. 결국 이러한 문제로 인해 이 [API를 제거](https://github.com/facebook/react/pull/20037)하게 되었습니다.
+이전에는 [상호작용 추적 API](https://gist.github.com/bvaughn/8de925562903afd2e7a12554adcdda16)를 만들어 이 문제를 해결하려고 했지만, 이 API는 근본적인 설계 결함으로 인해 상호작용이 느린 이유를 추적하는 정확도가 떨어지고 때로는 상호작용이 끝나지 않는 경우가 있었습니다. 결국 이러한 문제로 인해 이 [API를 제거](https://github.com/facebook/react/pull/20037)하게 되었습니다.
 
-이러한 문제를 해결하는 새로운 버전의 인터랙션 추적 API(`startTransition`을 통해 시작되므로 가칭 트랜지션 추적이라고 함)를 개발 중입니다.
+이러한 문제를 해결하는 새로운 버전의 상호작용 추적 API(`startTransition`을 통해 시작되므로 가칭 트랜지션 추적이라고 함)를 개발 중입니다.
 
 ## 새로운 React 문서 {/*new-react-docs*/}
 

src/content/community/versioning-policy.md

@@ -29,7 +29,7 @@ Breaking Changes는 모두에게 불편하기에 우리는 메이저 릴리즈
 
 ### 안정성에 기여하기 {/*commitment-to-stability*/}
 
-시간이 지남에 따라 React를 변경할 때, 새로운 기능을 활용하는 데 필요한 노력을 최소화하려고 노력합니다. 가능한 경우, 오래된 API를 별개의 패키지에 넣는 한이 있더라도 작동하도록 합니다. 예를 들어, [믹스인은 몇 년 동안 권장되지 않았지만](https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html) [create-react-class를 통해](https://legacy.reactjs.org/docs/react-without-es6.html#mixins) 지금까지 지원되고 있으며, 많은 코드베이스가 이를 안정적인 레거시 코드로 계속 사용하고 있습니다.
+시간이 지남에 따라 React를 변경할 때, 새로운 기능을 활용하는 데 필요한 노력을 최소화하려고 노력합니다. 가능한 경우, 오래된 API를 별개의 패키지에 넣는 한이 있더라도 작동하도록 합니다. 예를 들어, [믹스인은 몇 년 동안 권장되지 않았지만](https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html) [`create-react-class`를 통해](https://legacy.reactjs.org/docs/react-without-es6.html#mixins) 지금까지 지원되고 있으며, 많은 코드베이스가 이를 안정적인 레거시 코드로 계속 사용하고 있습니다.
 
 100만 명 이상의 개발자가 React를 사용하며 수백만 개의 컴포넌트를 일괄적으로 유지 관리합니다. 페이스북 코드베이스에만 5만개가 넘는 React 컴포넌트가 있습니다. 이는 우리가 새로운 React 버전으로 업그레이드하는 것을 가능한 한 쉽게 만들어야 한다는 것을 의미합니다. 만약 마이그레이션 과정 없이 큰 변화를 만든다면, 사람들은 오래된 버전에 갇히게 될 것입니다. 페이스북에서는 이러한 업그레이드 과정을 테스트합니다. 10 명이 되지 않는 우리 팀이 5만 개가 넘는 컴포넌트를 업데이트할 수 있다면, React를 사용하는 사람이라면 누구나 업그레이드를 관리할 수 있을 것입니다. 대부분의 경우, 우리는 컴포넌트 문법을 업그레이드하기 위해 [자동화된 명령문](https://github.com/reactjs/react-codemod)을 작성하고, 이를 오픈소스 릴리즈에 포함해 모두가 사용할 수 있도록 합니다.
 

src/content/learn/escape-hatches.md

@@ -197,7 +197,7 @@ Effect는 React 패러다임에서 벗어날 수 있는 탈출구입니다. Effe
 
 Effect가 필요하지 않은 두 가지 일반적인 경우가 있습니다.
 - **렌더링을 위해 데이터를 변환하는 데 Effect가 필요하지 않습니다.**
-- **사용자 이벤트를 핸들링하는 데 Effect가 필요하지 않습니다.**
+- **사용자 이벤트를 처리하는 데 Effect가 필요하지 않습니다.**
 
 예를 들어 다른 state에 따라 일부 state를 조정하는 데는 Effect가 필요하지 않습니다.
 

src/content/learn/index.md

@@ -96,7 +96,7 @@ JSX로 변환할 HTML이 많은 경우 [온라인 변환기](https://transform.t
 
 ## 스타일 추가하기 {/*adding-styles*/}
 
-React에서는 `className`으로 CSS class를 지정합니다. 이것은 HTML의 [`class`](https://developer.mozilla.org/ko/docs/Web/HTML/Global_attributes/class) 어트리뷰트와 동일한 방식으로 동작합니다.
+React에서는 `className`으로 CSS 클래스를 지정합니다. 이것은 HTML의 [`class`](https://developer.mozilla.org/ko/docs/Web/HTML/Global_attributes/class) 어트리뷰트와 동일한 방식으로 동작합니다.
 
 ```js
 <img className="avatar" />

src/content/learn/javascript-in-jsx-with-curly-braces.md

@@ -67,7 +67,7 @@ export default function Avatar() {
 
 </Sandpack>
 
-이미지를 둥글게 만드는 `"avatar"` CSS class 이름을 지정하는 `className="avatar"`와 `avatar`라는 JavaScript 변수의 값을 읽는 `src={avatar}`의 차이점에 주목해야 합니다. 중괄호를 사용하면 마크업에서 바로 JavaScript를 사용할 수 있기 때문입니다.
+이미지를 둥글게 만드는 `"avatar"` CSS 클래스 이름을 지정하는 `className="avatar"`와 `avatar`라는 JavaScript 변수의 값을 읽는 `src={avatar}`의 차이점에 주목해야 합니다. 중괄호를 사용하면 마크업에서 바로 JavaScript를 사용할 수 있기 때문입니다.
 
 ## 중괄호 사용하기: JavaScript 세계로 연결하는 창 {/*using-curly-braces-a-window-into-the-javascript-world*/}
 

src/content/learn/lifecycle-of-reactive-effects.md

@@ -60,7 +60,7 @@ effect의 본문에는 **동기화 시작** 방법이 명시되어 있습니다.
     // ...
 ```
 
-effect에서 반환되는 cleanup function는 **동기화를 중지**하는 방법을 지정합니다.
+effect에서 반환되는 cleanup 함수는 **동기화를 중지**하는 방법을 지정합니다.
 
 ```js {5}
     // ...
@@ -78,7 +78,7 @@ effect에서 반환되는 cleanup function는 **동기화를 중지**하는 방
 
 <Note>
 
-일부 effects는 cleanup function를 전혀 반환하지 않습니다. [대부분의 경우]((/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development)) 함수를 반환하고 싶겠지만, 그렇지 않은 경우 React는 빈 cleanup function를 반환한 것처럼 동작합니다.
+일부 effects는 cleanup 함수를 전혀 반환하지 않습니다. [대부분의 경우]((/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development)) 함수를 반환하고 싶겠지만, 그렇지 않은 경우 React는 빈 cleanup 함수를 반환한 것처럼 동작합니다.
 
 </Note>
 
@@ -127,13 +127,13 @@ function ChatRoom({ roomId /* "travel" */ }) {
 1. 이전 roomId와의 동기화를 중지합니다(`"general"` 방에서 연결 끊기).
 2. 새 roomId와 동기화 시작(`"travel"` 방에 연결)
 
-**다행히도, 여러분은 이미 이 두 가지를 수행하는 방법을 React에 가르쳤습니다!** effect의 본문에는 동기화를 시작하는 방법이 명시되어 있고, cleanup function에는 동기화를 중지하는 방법이 명시되어 있습니다. 이제 React가 해야 할 일은 올바른 순서로 올바른 props와 state로 호출하기만 하면 됩니다. 정확히 어떻게 일어나는지 살펴보겠습니다.
+**다행히도, 여러분은 이미 이 두 가지를 수행하는 방법을 React에 가르쳤습니다!** effect의 본문에는 동기화를 시작하는 방법이 명시되어 있고, cleanup 함수에는 동기화를 중지하는 방법이 명시되어 있습니다. 이제 React가 해야 할 일은 올바른 순서로 올바른 props와 state로 호출하기만 하면 됩니다. 정확히 어떻게 일어나는지 살펴보겠습니다.
 
 ### React가 effect를 재동기화하는 방법 {/*how-react-re-synchronizes-your-effect*/}
 
 `ChatRoom` 컴포넌트가 `roomId` prop에 새로운 값을 받았다는 것을 기억하세요. 이전에는 `"general"`이었지만 이제는 `"travel"`입니다. 다른 방에 다시 연결하려면 React가 effect를 다시 동기화해야 합니다.
 
-**동기화를 중지**하기 위해 React는 `"general"` 방에 연결한 후 effect가 반환한 cleanup function를 호출합니다. `roomId`가 `"general"`이었기 때문에, cleanup function는 `"general"` 방에서 연결을 끊습니다.
+**동기화를 중지**하기 위해 React는 `"general"` 방에 연결한 후 effect가 반환한 cleanup 함수를 호출합니다. `roomId`가 `"general"`이었기 때문에, cleanup 함수는 `"general"` 방에서 연결을 끊습니다.
 
 ```js {6}
 function ChatRoom({ roomId /* "general" */ }) {
@@ -146,7 +146,7 @@ function ChatRoom({ roomId /* "general" */ }) {
     // ...
 ```
 
-그러면 React는 이 렌더링 중에 여러분이 제공한 effect를 실행합니다. 이번에는 `roomId`가 `"travel"`이므로 `"travel"` 채팅방과 **동기화되기 시작**합니다(결국 cleanup function도 호출될 때까지).
+그러면 React는 이 렌더링 중에 여러분이 제공한 effect를 실행합니다. 이번에는 `roomId`가 `"travel"`이므로 `"travel"` 채팅방과 **동기화되기 시작**합니다(결국 cleanup 함수도 호출될 때까지).
 
 ```js {3,4}
 function ChatRoom({ roomId /* "travel" */ }) {
@@ -158,7 +158,7 @@ function ChatRoom({ roomId /* "travel" */ }) {
 
 덕분에 이제 사용자가 UI에서 선택한 방과 동일한 방에 연결됩니다. 재앙을 피했습니다!
 
-컴포넌트가 다른 `roomId`로 다시 렌더링할 때마다 effect가 다시 동기화됩니다. 예를 들어 사용자가 `roomId`를 `"travel"`에서 `"music"`으로 변경한다고 가정해 봅시다. React는 다시 cleanup function를 호출하여 effect **동기화를 중지**합니다(`"travel"` 방에서 연결을 끊습니다). 그런 다음 새 `roomId` prop로 본문을 실행하여 **동기화를 다시 시작**합니다(`"music"` 방에 연결).
+컴포넌트가 다른 `roomId`로 다시 렌더링할 때마다 effect가 다시 동기화됩니다. 예를 들어 사용자가 `roomId`를 `"travel"`에서 `"music"`으로 변경한다고 가정해 봅시다. React는 다시 cleanup 함수를 호출하여 effect **동기화를 중지**합니다(`"travel"` 방에서 연결을 끊습니다). 그런 다음 새 `roomId` prop로 본문을 실행하여 **동기화를 다시 시작**합니다(`"music"` 방에 연결).
 
 마지막으로 사용자가 다른 화면으로 이동하면 `ChatRoom`이 마운트를 해제합니다. 이제 연결 상태를 유지할 필요가 전혀 없습니다. React는 마지막으로 effect **동기화를 중지**하고 `"music"` 채팅방에서 연결을 끊습니다.
 
@@ -764,7 +764,7 @@ useEffect(() => {
 <Recap>
 
 - 컴포넌트는 마운트, 업데이트, 마운트 해제할 수 있습니다.
-- 각 effect는 주변 컴포넌트와 별도의 라이프사이클을 가집니다.
+- 각 effect는 주변 컴포넌트와 별도의 생명주기를 가집니다.
 - 각 effect는 시작 및 중지할 수 있는 별도의 동기화 프로세스를 설명합니다.
 - effect를 작성하고 읽을 때는 컴포넌트의 관점(마운트, 업데이트 또는 마운트 해제 방법)이 아닌 개별 effect의 관점(동기화 *시작* 및 *중지* 방법)에서 생각하세요.
 - 컴포넌트 본문 내부에 선언된 값은 "반응형"입니다.

src/content/learn/reacting-to-input-with-state.md

@@ -18,14 +18,14 @@ title: State를 사용해 Input 다루기
 
 ## 선언형 UI와 명령형 UI 비교 {/*how-declarative-ui-compares-to-imperative*/}
 
-UI 인터랙션을 디자인할 때 유저가 액션을 하면 어떻게 UI를 *변경* 해야 할지 고민해본 적이 있을 것입니다. 유저가 폼을 제출한다고 생각해봅시다.
+UI 상호작용을 디자인할 때 유저가 액션을 하면 어떻게 UI를 *변경* 해야 할지 고민해본 적이 있을 것입니다. 유저가 폼을 제출한다고 생각해봅시다.
 
 * 폼에 무언가를 입력하면 "제출" 버튼이 **활성화될** 것입니다.
 * "제출" 버튼을 누르면 폼과 버튼이 **비활성화되고** 스피너가 **나타날** 것입니다.
 * 네트워크 요청이 성공하면 폼은 **숨겨질** 것이고 "감사합니다." 메시지가 **나타날** 것입니다.
 * 네트워크 요청이 실패하면 오류 메시지가 **보일** 것이고 폼은 다시 **활성화될** 것입니다.
 
-위 내용은 **명령형 프로그래밍**에서 인터랙션을 구현하는 방법입니다. UI를 조작하기 위해서는 발생한 상황에 따라 정확한 지침을 작성해야만 합니다. 다른 방법을 한번 생각해봅시다. 옆에 누군가를 태우고 차례대로 어디를 가야 할지 말해준다고 상상해보세요.
+위 내용은 **명령형 프로그래밍**에서 상호작용을 구현하는 방법입니다. UI를 조작하기 위해서는 발생한 상황에 따라 정확한 지침을 작성해야만 합니다. 다른 방법을 한번 생각해봅시다. 옆에 누군가를 태우고 차례대로 어디를 가야 할지 말해준다고 상상해보세요.
 
 <Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="In a car driven by an anxious-looking person representing JavaScript, a passenger orders the driver to execute a sequence of complicated turn by turn navigations." />
 
@@ -131,7 +131,7 @@ body { font-family: sans-serif; margin: 20px; padding: 0; }
 
 </Sandpack>
 
-위의 예시에서는 문제가 없겠지만 위와 같이 UI를 조작하면 더 복잡한 시스템에서는 난이도가 기하급수적으로 올라갑니다. 여러 다른 폼으로 가득 찬 페이지를 업데이트해야 한다고 생각해보세요. 새로운 UI 요소나 새로운 인터랙션을 추가하려면 버그의 발생을 막기 위해 기존의 모든 코드를 주의 깊게 살펴봐야만 할 겁니다. (예를 들면 어떤 것을 보여주거나 숨기거나 하는 것을 잊을지도 모릅니다).
+위의 예시에서는 문제가 없겠지만 위와 같이 UI를 조작하면 더 복잡한 시스템에서는 난이도가 기하급수적으로 올라갑니다. 여러 다른 폼으로 가득 찬 페이지를 업데이트해야 한다고 생각해보세요. 새로운 UI 요소나 새로운 상호작용을 추가하려면 버그의 발생을 막기 위해 기존의 모든 코드를 주의 깊게 살펴봐야만 할 겁니다. (예를 들면 어떤 것을 보여주거나 숨기거나 하는 것을 잊을지도 모릅니다).
 
 리액트는 이러한 문제점을 해결하기 위해 만들어졌습니다.
 
@@ -481,7 +481,7 @@ function submitForm(answer) {
 
 </Sandpack>
 
-이러한 코드가 기존의 명령형 프로그래밍 예제보다는 길지만 그래도 조금 더 견고합니다. 모든 인터랙션을 state로 표현하게 되면 이후에 새로운 시각적 state가 추가되더라도 기존의 로직이 손상되는 것을 막을 수 있습니다. 또한 인터랙션 자체의 로직을 변경하지 않고도 각각의 state에 표시되는 항목을 변경할 수 있습니다.
+이러한 코드가 기존의 명령형 프로그래밍 예제보다는 길지만 그래도 조금 더 견고합니다. 모든 상호작용을 state로 표현하게 되면 이후에 새로운 시각적 state가 추가되더라도 기존의 로직이 손상되는 것을 막을 수 있습니다. 또한 상호작용 자체의 로직을 변경하지 않고도 각각의 state에 표시되는 항목을 변경할 수 있습니다.
 
 <Recap>
 
@@ -499,9 +499,9 @@ function submitForm(answer) {
 
 <Challenges>
 
-#### CSS class를 추가하고 제거하기 {/*add-and-remove-a-css-class*/}
+#### CSS 클래스를 추가하고 제거하기 {/*add-and-remove-a-css-class*/}
 
-사진을 클릭하면 바깥에 있는 `<div>`의 `background--active` CSS class를 *제거*하고 `<img>`에 `picture--active` class를 추가합니다. 그리고 배경을 다시 클릭하면 원래 CSS class로 돌아와야 합니다.
+사진을 클릭하면 바깥에 있는 `<div>`의 `background--active` CSS 클래스를 *제거*하고 `<img>`에 `picture--active` 클래스를 추가합니다. 그리고 배경을 다시 클릭하면 원래 CSS 클래스로 돌아와야 합니다.
 
 화면상으로는 사진을 클릭하면 보라색 배경은 제거되고 사진의 테두리는 강조 표시됩니다. 사진 외부를 클릭하면 배경이 강조 표시되고 사진의 테두리 강조 표시는 제거됩니다.
 
@@ -555,10 +555,10 @@ body { margin: 0; padding: 0; height: 250px; }
 
 이 컴포넌트는 두 가지 시각적 state를 가지고 있습니다. 이미지가 활성화되었을 때와 비활성화되었을 때입니다.
 
-* 이미지가 활성화되었을 때 CSS class는 `background`와 `picture picture--active`가 됩니다.
-* 이미지가 비활성화되었을 때 CSS class는 `background background--active`와 `picture`가 됩니다.
+* 이미지가 활성화되었을 때 CSS 클래스는 `background`와 `picture picture--active`가 됩니다.
+* 이미지가 비활성화되었을 때 CSS 클래스는 `background background--active`와 `picture`가 됩니다.
 
-이미지의 활성화 state를 기억하기 위해서는 하나의 boolean state 변수로 충분합니다. 원래 하려고 했던 것은 CSS class를 제거하거나 추가하는 것이었습니다. 하지만 리액트에서는 UI 요소를 *조작하는 것* 보다는 무엇을 보여주길 원하는지 *묘사하는 것*이 필요합니다. 그렇기 때문에 현재 state를 기반으로 두 CSS class 모두를 계산해야 합니다. 그리고 이미지를 클릭했을 때 배경이 클릭되지 않도록 이벤트의 [전파를 막을](/learn/responding-to-events#stopping-propagation) 필요가 있습니다.
+이미지의 활성화 state를 기억하기 위해서는 하나의 boolean state 변수로 충분합니다. 원래 하려고 했던 것은 CSS 클래스를 제거하거나 추가하는 것이었습니다. 하지만 리액트에서는 UI 요소를 *조작하는 것* 보다는 무엇을 보여주길 원하는지 *묘사하는 것*이 필요합니다. 그렇기 때문에 현재 state를 기반으로 두 CSS 클래스 모두를 계산해야 합니다. 그리고 이미지를 클릭했을 때 배경이 클릭되지 않도록 이벤트의 [전파를 막을](/learn/responding-to-events#stopping-propagation) 필요가 있습니다.
 
 이미지를 클릭한 다음 이미지 외부도 클릭해 잘 작동하는지 확인해봅시다.