fix: typo 'interaction' linted by textlint (#997)

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/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>
 

src/content/reference/react/memo.md

@@ -111,7 +111,7 @@ label {
 
 #### 모든 곳에 memo를 추가해야할까요? {/*should-you-add-memo-everywhere*/}
 
-이 사이트와 같이 대부분의 인터랙션이 투박한 앱의 경우(페이지 또는 전체 섹션 교체 등) 일반적으로 memoization는 불필요합니다. 반면 앱이 그림 편집기이고 도형 이동과 같이 대부분의 인터랙션이 세분되어 있다면, memoization가 유용할 수 있습니다.
+이 사이트와 같이 대부분의 상호작용이 투박한 앱의 경우(페이지 또는 전체 섹션 교체 등) 일반적으로 memoization는 불필요합니다. 반면 앱이 그림 편집기이고 도형 이동과 같이 대부분의 상호작용이 세분되어 있다면, memoization가 유용할 수 있습니다.
 
 `memo`로 최적화하는 것은 컴포넌트가 정확히 동일한 props로 자주 리렌더링 되고, 리렌더링 로직이 비용이 많이 드는 경우에만 유용합니다. 컴포넌트가 리렌더링 될 때 인지할 수 있을 만큼의 지연이 없다면 `memo`가 필요하지 않습니다. `memo`는 객체 또는 렌더링 중에 정의된 일반 함수처럼 *항상 다른* props가 컴포넌트에 전달되는 경우에 완전히 무용지물입니다. 따라서 `memo`와 함께 [`useMemo`](/reference/react/useMemo#skipping-re-rendering-of-components)와 [`useCallback`](/reference/react/useCallback#skipping-re-rendering-of-components)이 종종 필요합니다.
 
@@ -125,7 +125,7 @@ label {
 4. [state를 업데이트하는 불필요한 Effect](/learn/you-might-not-need-an-effect)를 피하세요. React 앱에서 대부분의 성능 문제는 컴포넌트를 반복해서 렌더링하게 만드는 Effect에서 발생하는 일련의 업데이트로 인해 발생합니다.
 5. [Effect에서 불필요한 의존성을 제거](/learn/removing-effect-dependencies)하세요. 예를 들어, memoization 대신에 일부 객체나 함수를 Effect 내부나 컴포넌트 외부로 이동하는 것이 더 간단할 때가 많습니다.
 
-특정 인터랙션이 여전히 느리게 느껴진다면 [React 개발자 도구 profiler](https://legacy.reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)를 사용해 어떤 컴포넌트가 memoization를 통해 가장 큰 이점을 얻을 수 있는지 확인하고 필요한 경우에 memoization 하세요. 이러한 원칙은 컴포넌트를 더 쉽게 디버깅하고 이해할 수 있게 해주므로 어떤 경우든 이 원칙을 따르는 것이 좋습니다. 장기적으로는 이 문제를 완전히 해결하기 위해 [세분된 memoization를 자동으로 수행하는 방법](https://www.youtube.com/watch?v=lGEMwh32soc)을 연구하고 있습니다.
+특정 상호작용이 여전히 느리게 느껴진다면 [React 개발자 도구 profiler](https://legacy.reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)를 사용해 어떤 컴포넌트가 memoization를 통해 가장 큰 이점을 얻을 수 있는지 확인하고 필요한 경우에 memoization 하세요. 이러한 원칙은 컴포넌트를 더 쉽게 디버깅하고 이해할 수 있게 해주므로 어떤 경우든 이 원칙을 따르는 것이 좋습니다. 장기적으로는 이 문제를 완전히 해결하기 위해 [세분된 memoization를 자동으로 수행하는 방법](https://www.youtube.com/watch?v=lGEMwh32soc)을 연구하고 있습니다.
 
 </DeepDive>