fix: typo 'user' linted by textlint (#996)

Co-authored-by: Haegul Pyun <[email protected]>

Author: lumirlumir

src/content/learn/keeping-components-pure.md

@@ -117,7 +117,7 @@ export default function TeaSet() {
 
 이 컴포넌트는 컴포넌트 바깥에 선언된 `guest`라는 변수를 읽고 수정하고 있습니다. 이건 **컴포넌트가 여러번 불리면 다른 JSX를 생성한다는 것을 의미합니다!** 그리고 더욱이 _다른_ 컴포넌트 가 `guest`를 읽었다면 언제 렌더링 되었는지에 따라 그 컴포넌트 또한 다른 JSX를 생성할 겁니다! 이건 예측할 수 없습니다.
 
-우리의 공식으로 다시 돌아가봅시다 <Math><MathI>y</MathI> = 2<MathI>x</MathI></Math>, 이제 <Math><MathI>x</MathI> = 2</Math>라 하더라도 우리는 <Math><MathI>y</MathI> = 4</Math>를 믿을 수 없습니다. 우리의 테스트는 실패하고 유저는 당황할 것이고 비행기는 추락할지도 모릅니다-이것이 얼마나 혼란스러운 버그로 이어지는지를 볼 수 있습니다!
+우리의 공식으로 다시 돌아가봅시다 <Math><MathI>y</MathI> = 2<MathI>x</MathI></Math>, 이제 <Math><MathI>x</MathI> = 2</Math>라 하더라도 우리는 <Math><MathI>y</MathI> = 4</Math>를 믿을 수 없습니다. 우리의 테스트는 실패하고 사용자는 당황할 것이고 비행기는 추락할지도 모릅니다-이것이 얼마나 혼란스러운 버그로 이어지는지를 볼 수 있습니다!
 
 [`guest` 변수를 대신 프로퍼티로 넘겨](/learn/passing-props-to-a-component) 이 컴포넌트를 고칠 수 있습니다.
 

src/content/learn/managing-state.md

@@ -22,7 +22,7 @@ title: State 관리하기
 
 ## State를 사용해 input 다루기 {/*reacting-to-input-with-state*/}
 
-React를 사용하면 코드에서 직접 UI를 수정하지 않습니다. 예를 들어 "버튼 비활성화", "버튼 활성화", "성공 메시지 표시" 등의 명령을 작성하지 않습니다. 대신 컴포넌트의 여러 시각적 상태("초기 상태", "입력 상태", "성공 상태")에 대해 보고 싶은 UI를 설명하고, 유저 입력에 따라 state 변경을 유발합니다. 이는 디자이너가 UI를 바라보는 방식과 비슷합니다.
+React를 사용하면 코드에서 직접 UI를 수정하지 않습니다. 예를 들어 "버튼 비활성화", "버튼 활성화", "성공 메시지 표시" 등의 명령을 작성하지 않습니다. 대신 컴포넌트의 여러 시각적 상태("초기 상태", "입력 상태", "성공 상태")에 대해 보고 싶은 UI를 설명하고, 사용자 입력에 따라 state 변경을 유발합니다. 이는 디자이너가 UI를 바라보는 방식과 비슷합니다.
 
 여기 React로 구현된 퀴즈 폼이 있습니다. `status` state 변수를 사용해 제출 버튼을 활성화 혹은 비활성화할지, 또는 성공 메시지를 대신 표지할지 여부를 결정하는 것에 주목해 주세요.
 
@@ -304,7 +304,7 @@ State를 끌어올려 컴포넌트들을 동기화하는 방법을 배우려면
 
 컴포넌트가 리렌더링 될 때, React는 트리에서 유지(및 업데이트) 할 부분과, 버리거나 다시 생성할 부분을 결정해야 합니다. 대부분의 경우 React의 자동화된 동작이 충분히 잘 작동합니다. 기본적으로 React는 기존에 렌더링 된 컴포넌트 트리와 "일치하는" 트리 부분을 보존합니다.
 
-하지만 때로는 이것이 바람직한 동작이 아닐 수 있습니다. 아래 채팅 앱에서는 메시지를 입력한 후에 수신자를 변경하더라도 입력이 초기화되지 않습니다. 따라서 유저가 실수로 잘못된 사람에게 메시지를 보낼 수도 있습니다.
+하지만 때로는 이것이 바람직한 동작이 아닐 수 있습니다. 아래 채팅 앱에서는 메시지를 입력한 후에 수신자를 변경하더라도 입력이 초기화되지 않습니다. 따라서 사용자가 실수로 잘못된 사람에게 메시지를 보낼 수도 있습니다.
 
 <Sandpack>
 
@@ -502,7 +502,7 @@ State의 생명주기, 그리고 생명주기를 컨트롤하는 방법을 배
 
 ## State 로직을 reducer로 작성하기 {/*extracting-state-logic-into-a-reducer*/}
 
-여러 이벤트 핸들러를 통해 많은 state 업데이트가 이루어지는 컴포넌트는 감당하기 힘들 수 있습니다. 이 때 컴포넌트 외부에서 "reducer"라는 단일 함수를 사용하여 모든 state 업데이트 로직을 통합할 수 있습니다. 이벤트 핸들러는 오로지 유저의 "action"만을 명시하므로 간결해집니다. 각 action에 대한 state 업데이트 방법은 파일 맨 마지막 부분의 reducer 함수에 명시되어 있습니다.
+여러 이벤트 핸들러를 통해 많은 state 업데이트가 이루어지는 컴포넌트는 감당하기 힘들 수 있습니다. 이 때 컴포넌트 외부에서 "reducer"라는 단일 함수를 사용하여 모든 state 업데이트 로직을 통합할 수 있습니다. 이벤트 핸들러는 오로지 사용자의 "action"만을 명시하므로 간결해집니다. 각 action에 대한 state 업데이트 방법은 파일 맨 마지막 부분의 reducer 함수에 명시되어 있습니다.
 
 <Sandpack>
 

src/content/learn/preserving-and-resetting-state.md

@@ -1113,7 +1113,7 @@ textarea {
 
 입력란에 타이핑한 후에 "Alice"나 "Bob"을 눌러 다른 수신자를 선택해보세요. `<Chat>`이 트리의 같은 곳에서 렌더링되기 때문에 입력값이 유지되는 것을 볼 수 있습니다.
 
-**많은 앱에서 이런 동작을 원하겠지만 채팅 앱에서는 아닙니다!** 유저가 실수로 클릭해서 이미 입력한 내용을 잘못된 사람에게 보내는 것은 바람직하지 않습니다. 이것을 고치기 위해 `key`를 추가해봅시다.
+**많은 앱에서 이런 동작을 원하겠지만 채팅 앱에서는 아닙니다!** 사용자가 실수로 클릭해서 이미 입력한 내용을 잘못된 사람에게 보내는 것은 바람직하지 않습니다. 이것을 고치기 위해 `key`를 추가해봅시다.
 
 ```js
 <Chat key={to.id} contact={to} />
@@ -1224,7 +1224,7 @@ textarea {
 
 - 현재 채팅만 렌더링하는 대신 _모든_ 채팅을 렌더링하고 CSS로 안 보이게 할 수 있습니다. 채팅은 트리에서 사라지지 않을 것이고 따라서 그들의 state는 유지됩니다. 이 방법은 간단한 UI에서 잘 작동합니다. 하지만 숨겨진 트리가 크고 많은 DOM 노드를 가지고 있다면 매우 느려질 것입니다.
 - [state를 상위로 올리고](/learn/sharing-state-between-components) 각 수신자의 임시 메시지를 부모 컴포넌트에 가지고 있을 수 있습니다. 이 방법에서 부모가 중요한 정보를 가지고 있기 때문에 자식 컴포넌트가 제거되어도 상관이 없습니다. 이것이 가장 일반적인 해법입니다.
-- React state 이외의 다른 저장소를 이용할 수도 있습니다. 예를 들어 유저가 페이지를 실수로 닫아도 메시지를 유지하고 싶을 수도 있습니다. 이때 [`localStorage`](https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage)에 메시지를 저장하고 이를 이용해 `Chat` 컴포넌트를 초기화할 수 있습니다.
+- React state 이외의 다른 저장소를 이용할 수도 있습니다. 예를 들어 사용자가 페이지를 실수로 닫아도 메시지를 유지하고 싶을 수도 있습니다. 이때 [`localStorage`](https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage)에 메시지를 저장하고 이를 이용해 `Chat` 컴포넌트를 초기화할 수 있습니다.
 
 어떤 방법을 선택하더라도 _Alice와의_ 채팅은 _Bob과의_ 채팅과 개념상 구별되기 때문에 현재 수신자를 기반으로 `<Chat>` 트리에 `key`를 주는 것이 타당합니다.
 

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

@@ -18,7 +18,7 @@ title: State를 사용해 Input 다루기
 
 ## 선언형 UI와 명령형 UI 비교 {/*how-declarative-ui-compares-to-imperative*/}
 
-UI 상호작용을 디자인할 때 유저가 액션을 하면 어떻게 UI를 *변경* 해야 할지 고민해본 적이 있을 것입니다. 유저가 폼을 제출한다고 생각해봅시다.
+UI 상호작용을 디자인할 때 사용자가 액션을 하면 어떻게 UI를 *변경* 해야 할지 고민해본 적이 있을 것입니다. 사용자가 폼을 제출한다고 생각해봅시다.
 
 * 폼에 무언가를 입력하면 "제출" 버튼이 **활성화될** 것입니다.
 * "제출" 버튼을 누르면 폼과 버튼이 **비활성화되고** 스피너가 **나타날** 것입니다.

src/content/learn/referencing-values-with-refs.md

@@ -236,7 +236,7 @@ export default function Counter() {
 
 <DeepDive>
 
-#### useRef는 내부적으로 어떻게 동작하나요? {/*how-does-useref-work-inside*/}
+#### `useRef`는 내부적으로 어떻게 동작하나요? {/*how-does-useref-work-inside*/}
 
 `useState`와 `useRef`가 모두 React에 의해 제공되지만, 원칙적으로 `useRef`는 `useState` 위에 구현될 수 있습니다. React 내부에서 `useRef`가 이렇게 구현되는 것을 상상할 수 있습니다.
 

src/content/learn/reusing-logic-with-custom-hooks.md

@@ -19,7 +19,7 @@ React는 `useState`, `useContext`, 그리고 `useEffect`같이 몇몇 내재하
 
 ## 커스텀 Hook: 컴포넌트간 로직 공유하기 {/*custom-hooks-sharing-logic-between-components*/}
 
-네트워크에 크게 의존하는 앱 (대부분의 앱이 그렇듯)을 개발 중이라고 생각해 보세요. 유저가 앱을 사용하는 동안 네트워크가 갑자기 사라진다면, 유저에게 경고하고 싶을 겁니다. 이런 경우 어떻게 하실 건가요? 컴포넌트에는 다음 두 가지가 필요할 것입니다.
+네트워크에 크게 의존하는 앱 (대부분의 앱이 그렇듯)을 개발 중이라고 생각해 보세요. 사용자가 앱을 사용하는 동안 네트워크가 갑자기 사라진다면, 사용자에게 경고하고 싶을 겁니다. 이런 경우 어떻게 하실 건가요? 컴포넌트에는 다음 두 가지가 필요할 것입니다.
 
 1. 네트워크가 온라인 상태인지 아닌지 추적하는 하나의 state
 2. 전역 [`online (온라인)`](https://developer.mozilla.org/en-US/docs/Web/API/Window/online_event), [`offline (오프라인)`](https://developer.mozilla.org/en-US/docs/Web/API/Window/offline_event) 이벤트를 구독하고, 이에 맞춰 state를 업데이트하는 Effect

src/content/reference/react-dom/client/hydrateRoot.md

@@ -186,7 +186,7 @@ function Counter() {
 
 `hydrateRoot`에 전달한 React 트리는 서버에서 만들었던 React 트리 결과물과 동일해야 합니다.
 
-이는 사용자 경험을 위해서 중요합니다. 유저는 서버에서 만들어진 HTML을 JavaScript 코드가 로드될 때까지 둘러보게 됩니다. 앱의 로딩을 더 빠르게 하기 위해 서버는 일종의 신기루로서 React 결과물인 HTML 스냅샷을 만들어 보여줍니다. 갑자기 다른 컨텐츠를 보여주게 되면 신기루가 깨져버리게 됩니다. 이런 이유로 서버에서 렌더링한 결과물과 클라이언트에서 최초로 렌더링한 결과물이 같아야 합니다.
+이는 사용자 경험을 위해서 중요합니다. 사용자는 서버에서 만들어진 HTML을 JavaScript 코드가 로드될 때까지 둘러보게 됩니다. 앱의 로딩을 더 빠르게 하기 위해 서버는 일종의 신기루로서 React 결과물인 HTML 스냅샷을 만들어 보여줍니다. 갑자기 다른 컨텐츠를 보여주게 되면 신기루가 깨져버리게 됩니다. 이런 이유로 서버에서 렌더링한 결과물과 클라이언트에서 최초로 렌더링한 결과물이 같아야 합니다.
 
 주로 아래와 같은 원인으로 hydration 에러가 일어납니다.
 
@@ -320,7 +320,7 @@ export default function App() {
 
 <Pitfall>
 
-이 방법은 2번 렌더링해야 하기 때문에 hydration을 느리게 합니다. 느린 통신 상태일 경우에 사용자 경험을 염두하세요. 초기 HTML이 렌더된 한참 이후에야 JavaScript 코드를 불러오게 됩니다. 따라서 hydration 이후에 바로 다른 UI를 렌더링하는 것은 유저에게 UI가 삐걱거리는 것처럼 보일 수 있습니다.
+이 방법은 2번 렌더링해야 하기 때문에 hydration을 느리게 합니다. 느린 통신 상태일 경우에 사용자 경험을 염두하세요. 초기 HTML이 렌더된 한참 이후에야 JavaScript 코드를 불러오게 됩니다. 따라서 hydration 이후에 바로 다른 UI를 렌더링하는 것은 사용자에게 UI가 삐걱거리는 것처럼 보일 수 있습니다.
 
 </Pitfall>
 

src/content/reference/react-dom/components/form.md

@@ -96,7 +96,7 @@ export default function Search() {
 
 입력과 제출 버튼과 함께 `<form>`을 렌더하세요. 폼이 제출될 때 해당 함수를 실행하기 위해 Server Action([`'use server'`](/reference/rsc/use-server)가 표시된 함수)를 폼의 `action`의 프로퍼티로 전달하세요.
 
-`<form action>`에 Server Action을 전달하면 자바스크립트가 활성화되기 전이나 코드가 로드되기 전에 유저가 폼을 제출할 수 있습니다. 이는 연결 상태나 기계가 느리거나 자바스크립트가 비활성화된 유저에게 유용하고, `action` 프로퍼티에 URL이 전달될 때와 폼이 동작하는 방식은 비슷합니다.
+`<form action>`에 Server Action을 전달하면 자바스크립트가 활성화되기 전이나 코드가 로드되기 전에 사용자가 폼을 제출할 수 있습니다. 이는 연결 상태나 기계가 느리거나 자바스크립트가 비활성화된 사용자에게 유용하고, `action` 프로퍼티에 URL이 전달될 때와 폼이 동작하는 방식은 비슷합니다.
 
 `<form>`의 액션에 데이터를 제공하기 위해 폼 필드의 `hidden`을 사용할 수 있습니다. Server Action은 [`formData`](https://developer.mozilla.org/ko/docs/Web/API/FormData) 대신 `hidden`이 적용된 폼 필드 데이터를 불러 올 수 있습니다.
 
@@ -198,9 +198,9 @@ export async function submitForm(query) {
 
 ### 낙관적으로 폼 데이터 업데이트하기 {/*optimistically-updating-form-data*/}
 
-`useOptimistic` hook은 네트워크 요청과 같은 백그라운드의 작업이 끝나기 전에 유저 인터페이스에 낙관적으로 업데이트하는 방법을 제공합니다. 폼의 맥락에서 이 기술은 앱을 더욱 반응형으로 느끼게 해줍니다. 유저가 폼을 제출하면 인터페이스는 유저가 기대하는 결과물로 즉시 업데이트됩니다. 
+`useOptimistic` hook은 네트워크 요청과 같은 백그라운드의 작업이 끝나기 전에 사용자 인터페이스에 낙관적으로 업데이트하는 방법을 제공합니다. 폼의 맥락에서 이 기술은 앱을 더욱 반응형으로 느끼게 해줍니다. 사용자가 폼을 제출하면 인터페이스는 사용자가 기대하는 결과물로 즉시 업데이트됩니다. 
 
-예를 들어, 유저가 폼에 메시지를 입력하고 "제출" 버튼을 클릭하면 `useOptimistic` hook은 "제출중..." 라벨과 함께 메시지가 서버에 보내지기 전에 리스트에 즉시 보입니다. 이러한 '낙관적인' 접근 방식은 속도와 반응성이 뛰어나다는 인상을 줍니다. 그다음 폼은 실제로 백그라운드에 메시지 보내기를 시도합니다. 서버에 메시지가 잘 도착하면, "제출중..." 라벨은 사라집니다.
+예를 들어, 사용자가 폼에 메시지를 입력하고 "제출" 버튼을 클릭하면 `useOptimistic` hook은 "제출중..." 라벨과 함께 메시지가 서버에 보내지기 전에 리스트에 즉시 보입니다. 이러한 '낙관적인' 접근 방식은 속도와 반응성이 뛰어나다는 인상을 줍니다. 그다음 폼은 실제로 백그라운드에 메시지 보내기를 시도합니다. 서버에 메시지가 잘 도착하면, "제출중..." 라벨은 사라집니다.
 
 
 <Sandpack>

src/content/reference/react-dom/server/renderToReadableStream.md

@@ -322,7 +322,7 @@ function ProfilePage() {
 }
 ```
 
-이는 유저가 보는 최초의 로딩 상태를 정해줍니다:
+이는 사용자가 보는 최초의 로딩 상태를 정해줍니다:
 
 ```js {3-5,13}
 <ProfileLayout>
@@ -441,7 +441,7 @@ function ProfilePage() {
 2. 서버에서 더이상의 `Posts`와 그 내부를 렌더링하는 것을 "포기"합니다.
 3. 클라이언트에서 자바스크립트 코드가 로딩되었을 때, React는 `Posts`를 다시 렌더링하려고 시도할 것입니다.
 
-만약 클라이언트에서도 `Posts` 렌더링 재시도가 실패한다면, React는 클라이언트에서 에러를 던지게 됩니다. 렌더링 중에 일어난 모든 에러과 함께, [가장 가까운 부모 에러 경계](/reference/react/Component#static-getderivedstatefromerror)로 유저에게 어떤 에러를 보여줘야할 지를 결정하게 됩니다. 실제로는, 사용자가 에러가 복구될 수 없다는 것이 확실시 될 때까지 로딩 표시기를 보고있어야 한 다는 것을 의미합니다.
+만약 클라이언트에서도 `Posts` 렌더링 재시도가 실패한다면, React는 클라이언트에서 에러를 던지게 됩니다. 렌더링 중에 일어난 모든 에러과 함께, [가장 가까운 부모 에러 경계](/reference/react/Component#static-getderivedstatefromerror)로 사용자에게 어떤 에러를 보여줘야할 지를 결정하게 됩니다. 실제로는, 사용자가 에러가 복구될 수 없다는 것이 확실시 될 때까지 로딩 표시기를 보고있어야 한 다는 것을 의미합니다.
 
 클라이언트에서 `Posts` 렌더링 재시도가 성공하면, 서버에서 온 로딩 대체 HTML이 클라이언트에서 렌더링된 결과로 교체됩니다. 사용자는 서버에서 에러가 있었는지 모를 것입니다. 하지만, 서버의 `onError` 콜백과 클라이언트의 [`onRecoverableError`](/reference/react-dom/client/hydrateRoot#hydrateroot) 콜백은 그대로 실행됩니다. 이를 통해 에러 내용을 받아서 로깅할 수 있습니다.
 

src/content/reference/react/cache.md

@@ -232,7 +232,7 @@ async function Profile({id}) {
 }
 
 function Page({id}) {
-  // ✅ Good: 유저 데이터 가져오기를 시작합니다.
+  // ✅ Good: 사용자 데이터 가져오기를 시작합니다.
   getUser(id);
   // ... 몇몇의 계산 작업들
   return (
@@ -245,7 +245,7 @@ function Page({id}) {
 
 `Page`를 렌더링할 때, 컴포넌트는 <CodeStep step={1}>`getUser`</CodeStep>를 호출하지만, 반환된 데이터를 사용하지 않는다는 점에 유의하세요. 이 초기 <CodeStep step={1}>`getUser`</CodeStep> 호출은 페이지가 다른 계산 작업을 수행하고 자식을 렌더링하는 동안 발생하는, 비동기 데이터베이스 쿼리를 시작합니다. 
 
-`Profile`을 렌더링할 때, <CodeStep step={2}>`getUser`</CodeStep>를 다시 호출합니다. 초기 <CodeStep step={1}>`getUser`</CodeStep> 호출이 이미 유저 데이터에 반환되고 캐싱 되었다면, `Profile`이 <CodeStep step={2}>해당 데이터를 요청하고 기다릴 때</CodeStep>, 다른 원격 프로시저 호출 없이 쉽게 캐시에서 읽어올 수 있습니다. <CodeStep step={1}> 초기 데이터 요청</CodeStep>이 완료되지 않은 경우, 이 패턴으로 데이터를 미리 로드하면 데이터를 받아올 때 생기는 지연이 줄어듭니다.
+`Profile`을 렌더링할 때, <CodeStep step={2}>`getUser`</CodeStep>를 다시 호출합니다. 초기 <CodeStep step={1}>`getUser`</CodeStep> 호출이 이미 사용자 데이터에 반환되고 캐싱 되었다면, `Profile`이 <CodeStep step={2}>해당 데이터를 요청하고 기다릴 때</CodeStep>, 다른 원격 프로시저 호출 없이 쉽게 캐시에서 읽어올 수 있습니다. <CodeStep step={1}> 초기 데이터 요청</CodeStep>이 완료되지 않은 경우, 이 패턴으로 데이터를 미리 로드하면 데이터를 받아올 때 생기는 지연이 줄어듭니다.
 
 <DeepDive>