diff --git a/src/content/learn/preserving-and-resetting-state.md b/src/content/learn/preserving-and-resetting-state.md
index e5b4b5d0d..91a754d4c 100644
--- a/src/content/learn/preserving-and-resetting-state.md
+++ b/src/content/learn/preserving-and-resetting-state.md
@@ -377,7 +377,7 @@ label {
 
 <Pitfall>
 
-**React는 JSX 마크업에서가 아닌 UI 트리에서의 위치에 관심이 있다는 것을** 기억하세요! 이 컴포넌트는 `if` 안과 밖에 다른 `<Counter />`를 가진 `return` 문을 두 개 가지고 있습니다.
+**React에서 중요한 것은 JSX 마크업에서가 아닌 UI 트리에서의 위치라는 점을** 기억하세요! 이 컴포넌트는 `if` 안과 밖에 다른 `<Counter />`를 가진 `return` 문을 두 개 가지고 있습니다.
 
 <Sandpack>
 
@@ -475,9 +475,9 @@ label {
 
 </Sandpack>
 
-체크 박스를 선택할 때 state가 초기화될 거라고 생각했을 수도 있지만 그렇지 않습니다! **두 `<Counter />` 태그가 같은 위치에 렌더링되기** 때문이죠. React는 함수 안 어디에 조건문이 있는지 모릅니다. React는 당신이 반환하는 트리만 "봅니다". 두 상황에서 `App` 컴포넌트는 `<Counter />`를 첫 번째 자식으로 가진 `<div>`를 반환합니다. 이것이 React가 두 `<Counter />`를 _같은_ 것으로 보는 이유입니다.
+체크 박스를 선택할 때 state가 초기화될 거라고 생각했을 수도 있지만 그렇지 않습니다! **두 `<Counter />` 태그가 같은 위치에 렌더링되기** 때문이죠. React는 함수 안 어디에 조건문이 있는지 모릅니다. React는 당신이 반환하는 트리만 "봅니다".
 
-그들이 같은 "주소"를 갖는다고 생각할 수도 있습니다. root의 첫 번째 자식의 첫 번째 자식으로요. 이것이 당신이 어떻게 로직을 만들었는지와 상관없이 React가 이전과 다음 렌더링 사이에 컴포넌트를 맞추는 방법입니다.
+두 상황에서 `App` 컴포넌트는 `<Counter />`를 첫 번째 자식으로 가진 `<div>`를 반환합니다. React에서는 이 두 카운터가 root의 첫 번째 자식의 첫 번째 자식이라는 동일한 "주소"를 가집니다. 이것이 당신이 어떻게 로직을 만들었는지와 상관없이 React가 이전과 다음 렌더링 사이에 컴포넌트를 맞추는 방법입니다.
 
 </Pitfall>
 
@@ -560,7 +560,7 @@ label {
 
 </Sandpack>
 
-여기서 당신은 같은 자리의 _다른_ 컴포넌트 타입으로 바꿉니다. 처음에는 `<div>`가 `Counter`를 갖고 있습니다. 하지만 `p`로 바꾸면 React는 UI 트리에서 `Counter`와 그 state를 제거합니다.
+여기서 같은 자리의 _다른_ 컴포넌트 타입으로 바꿉니다. 처음에는 `<div>`가 `Counter`를 갖고 있습니다. 하지만 `p`로 바꾸면 React는 UI 트리에서 `Counter`와 그 state를 제거합니다.
 
 <DiagramGroup>
 
@@ -671,7 +671,7 @@ label {
 
 </Sandpack>
 
-`Counter`의 State는 체크 박스를 선택할 때 초기화됩니다. 비록 `Counter`를 렌더링하지만, `div`의 첫 번째 자식이 `section`에서 `div`로 바뀝니다. 자식 `section`이 DOM에서 제거되었을 때, 그 아래 전체 트리(`Counter`와 그 State를 포함하여)도 함께 제거됩니다.
+`Counter`의 state는 체크 박스를 선택할 때 초기화됩니다. 비록 `Counter`를 렌더링하지만, `div`의 첫 번째 자식이 `section`에서 `div`로 바뀝니다. 자식 `section`이 DOM에서 제거되었을 때, 그 아래 전체 트리(`Counter`와 그 state를 포함하여)도 함께 제거됩니다.
 
 <DiagramGroup>
 
@@ -693,7 +693,7 @@ label {
 
 </DiagramGroup>
 
-경험상<sup>Rule of Thumb</sup> **리렌더링할 때 State를 유지하고 싶다면, 트리 구조가 "같아야" 합니다.** 만약 구조가 다르다면 React가 트리에서 컴포넌트를 지울 때 State로 지우기 때문에 State가 유지되지 않습니다.
+경험상<sup>Rule of Thumb</sup> **리렌더링할 때 state를 유지하고 싶다면, 트리 구조가 "같아야" 합니다.** 만약 구조가 다르다면 React가 트리에서 컴포넌트를 지울 때 state를 지우기 때문에 state가 유지되지 않습니다.
 
 <Pitfall>
 
@@ -734,13 +734,13 @@ export default function MyComponent() {
 </Sandpack>
 
 
-버튼을 누를 때마다 입력 State가 사라집니다! 이것은 `MyComponent`를 렌더링할 때마다 *다른* `MyTextField` 함수가 만들어지기 때문입니다. 따라서 같은 함수에서 *다른* 컴포넌트를 렌더링할 때마다 React는 그 아래의 모든 state를 초기화합니다. 이런 문제를 피하려면 **항상 컴포넌트를 중첩해서 정의하지 않고 최상위 범위에서 정의해야 합니다.**
+버튼을 누를 때마다 입력 state가 사라집니다! 이것은 `MyComponent`를 렌더링할 때마다 *다른* `MyTextField` 함수가 만들어지기 때문입니다. 같은 위치에서 *다른* 컴포넌트를 렌더링하기 때문에 React는 그 아래의 모든 state를 초기화합니다. 이로 인해 버그와 성능 문제가 발생합니다. 이런 문제를 피하려면 **항상 컴포넌트 함수를 중첩해서 정의하지 않고 최상위 범위에서 정의해야 합니다.**
 
 </Pitfall>
 
 ## 같은 위치에서 state를 초기화하기 {/*resetting-state-at-the-same-position*/}
 
-기본적으로 React는 컴포넌트가 같은 위치를 유지하면 state를 유지합니다. 보통 이것이 당신이 원하는 행동이기 때문에 기본 동작으로서 타당합니다. 그러나 가끔 컴포넌트 State를 초기화하고 싶을 때가 있습니다. 두 선수가 턴마다 자신의 점수를 추적하는 앱을 한번 봅시다.
+기본적으로 React는 컴포넌트가 같은 위치를 유지하면 state를 유지합니다. 보통 이것이 당신이 원하는 행동이기 때문에 기본 동작으로서 타당합니다. 그러나 가끔 컴포넌트 state를 초기화하고 싶을 때가 있습니다. 두 선수가 턴마다 자신의 점수를 추적하는 앱을 한번 봅시다.
 
 <Sandpack>
 
@@ -812,7 +812,7 @@ h1 {
 
 지금은 선수를 바꿀 때 점수가 유지됩니다. 두 `Counter`가 같은 위치에 나타나기 때문에 React는 그들을 `person` props가 변경된 *같은* `Counter`로 봅니다.
 
-하지만, 개념적으로 `app` 에는 두 개의 분리된 카운터가 있어야 합니다. 그들은 UI에 같은 위치에 나타나지만, 하나는 Taylor의 카운터이고, 다른 하나는 Sarah의 카운터입니다.
+하지만, 개념적으로 app에는 두 개의 분리된 카운터가 있어야 합니다. 그들은 UI에 같은 위치에 나타나지만, 하나는 Taylor의 카운터이고, 다른 하나는 Sarah의 카운터입니다.
 
 이 둘을 바꿀 때 state를 초기화하기 위한 두 가지 방법이 있습니다.
 
@@ -1119,7 +1119,7 @@ textarea {
 <Chat key={to.id} contact={to} />
 ```
 
-이것은 다른 수신자를 선택할 때 `Chat` 컴포넌트가 그 트리에 있는 모든 state를 포함해서 처음부터 다시 생성되는 것을 보장해줍니다. React는 DOM 엘리먼트도 다시 사용하는 대신 새로 만들 것입니다.
+이는 다른 수신자를 선택할 때 `Chat` 컴포넌트가 그 하위 트리에 있는 모든 state를 포함해서 처음부터 다시 생성되는 것을 보장해줍니다. React는 DOM 엘리먼트도 재사용하는 대신 다시 만들 것입니다.
 
 이제 수신자를 바꿀 때마다 입력란이 비워지게 됩니다.
 
@@ -1983,7 +1983,7 @@ img { width: 150px; height: 150px; }
 
 #### 배열에서 잘못 지정된 state 고치기 {/*fix-misplaced-state-in-the-list*/}
 
-다음 예시에서 배열의 각 `Contact`는 "Show email"이 눌렸는지에 대한 state를 갖고 있습니다. Alice의 "Show email"을 누르고 "Show in reverse order" 체크 박스를 선택해보세요. 아래쪽으로 내려간 Alice의 이메일은 닫혀있고 대신 _Taylor_의 이메일이 열려있는 것을 볼 수 있습니다.
+다음 예시에서 배열의 각 `Contact`는 "Show email"이 눌렸는지에 대한 state를 갖고 있습니다. Alice의 "Show email"을 누르고 "Show in reverse order" 체크 박스를 선택해보세요. 아래쪽으로 내려간 Alice의 이메일은 닫혀있고 대신 *Taylor*의 이메일이 열려있는 것을 볼 수 있습니다.
 
 순서와 관계없이 확장 state가 각 연락처와 연관되도록 고쳐보세요.
 
@@ -2082,7 +2082,7 @@ button {
   <li key={i}>
 ```
 
-하지만 우리는 state가 _각 특정 연락처_와 연관되기를 바랍니다.
+하지만 확장 state는 *각 특정 연락처*와 연관되어야 합니다.
 
 대신 연락처 ID를 `key`로 사용해서 문제를 해결할 수 있습니다.