diff --git a/docs/documentation/ko/release-notes/TypeScript 4.9.md b/docs/documentation/ko/release-notes/TypeScript 4.9.md
index f62ebcd1..382ba5a9 100644
--- a/docs/documentation/ko/release-notes/TypeScript 4.9.md	
+++ b/docs/documentation/ko/release-notes/TypeScript 4.9.md	
@@ -106,14 +106,14 @@ const greenNormalized = palette.green.toUpperCase();
 For more examples, you can see the [issue proposing this](https://github.com/microsoft/TypeScript/issues/47920) and [the implementing pull request](https://github.com/microsoft/TypeScript/pull/46827).
 We'd like to thank [Oleksandr Tarasiuk](https://github.com/a-tarasyuk) who implemented and iterated on this feature with us.
 
-## Unlisted Property Narrowing with the `in` Operator
+## "in" 연산자를 사용하여 정의되지 않은 프로퍼티로 타입 좁히기
 
-As developers, we often need to deal with values that aren't fully known at runtime.
-In fact, we often don't know if properties exist, whether we're getting a response from a server or reading a configuration file.
-JavaScript's `in` operator can check whether a property 
-exists on an object.
+개발자들은 자주 런타임에서 알 수 없는 값을 처리해야 할 때가 있습니다.
+서버에서 응답받거나 설정 파일을 읽는 경우처럼 실제로 프로퍼티가 존재하는지 알 수 없는 경우가 흔하게 있습니다.
+JavaScript의 `in` 연산자를 사용하면
+객체에 프로퍼티가 존재하는지 알 수 있습니다.
 
-Previously, TypeScript allowed us to narrow away any types that don't explicitly list a property.
+이전 TypeScript 버전에서는 명시적으로 프로퍼티가 타입 목록에 없다면 범위를 좁힐 수 있었습니다.
 
 ```ts
 interface RGB {
@@ -130,24 +130,24 @@ interface HSV {
 
 function setColor(color: RGB | HSV) {
     if ("hue" in color) {
-        // 'color' now has the type HSV
+        // 이제 'color'의 타입은 HSV 입니다.
     }
     // ...
 }
 ```
 
-Here, the type `RGB` didn't list the `hue` and got narrowed away, and leaving us with the type `HSV`.
+여기서, `RGB` 타입에 정의되지 않은 `hue`에 의해 타입이 좁혀지게 되어, `HSV` 타입이 되었습니다.
 
-But what about examples where no type listed a given property?
-In those cases, the language didn't help us much.
-Let's take the following example in JavaScript:
+그러나 프로퍼티가 주어진 타입이 없는 경우에는 어떨까요?
+그런 경우, 언어는 큰 도움이 되지 않습니다.
+여기 JavaScript로 된 예시를 살펴보겠습니다.
 
 ```js
 function tryGetPackageName(context) {
     const packageJSON = context.packageJSON;
-    // Check to see if we have an object.
+    // 객체 여부를 확인합니다.
     if (packageJSON && typeof packageJSON === "object") {
-        // Check to see if it has a string name property.
+        // 문자열 타입의 name 프로퍼티를 가지고 있는지 확인합니다.
         if ("name" in packageJSON && typeof packageJSON.name === "string") {
             return packageJSON.name;
         }
@@ -157,8 +157,8 @@ function tryGetPackageName(context) {
 }
 ```
 
-Rewriting this to canonical TypeScript would just be a matter of defining and using a type for `context`;
-however, picking a safe type like `unknown` for the `packageJSON` property would cause issues in older versions of TypeScript.
+이것을 표준 TypeScript로 다시 작성한다면 `context` 타입을 정의해서 사용할 수 있습니다.
+하지만 `packageJSON`의 프로퍼티에 `unknown`과 같은 안전한 타입을 사용하면 이전 TypeScript 버전에서 문제가 발생할 수 있습니다.
 
 ```ts
 interface Context {
@@ -167,9 +167,9 @@ interface Context {
 
 function tryGetPackageName(context: Context) {
     const packageJSON = context.packageJSON;
-    // Check to see if we have an object.
+    // 객체 여부를 확인합니다.
     if (packageJSON && typeof packageJSON === "object") {
-        // Check to see if it has a string name property.
+        // 문자열 타입의 name 프로퍼티를 가지고 있는지 확인합니다.
         if ("name" in packageJSON && typeof packageJSON.name === "string") {
         //                                              ~~~~
         // error! Property 'name' does not exist on type 'object.
@@ -183,14 +183,14 @@ function tryGetPackageName(context: Context) {
 }
 ```
 
-This is because while the type of `packageJSON` was narrowed from `unknown` to `object`, the `in` operator strictly narrowed to types that actually defined the property being checked.
-As a result, the type of `packageJSON` remained `object`.
+`packageJSON`의 타입이 `unknown`에서 `object`로 좁혀졌지만, `in` 연산자는 실제 정의한 타입으로 엄격하게 좁혔기 때문입니다.
+결과적으로 `packageJSON`의 타입은 `object`가 되었습니다.
 
-TypeScript 4.9 makes the `in` operator a little bit more powerful when narrowing types that *don't* list the property at all.
-Instead of leaving them as-is, the language will intersect their types with `Record<"property-key-being-checked", unknown>`.
+TypeScript 4.9는 프로퍼티가 전혀 정의되지 _않은_ 타입으로 좁힐 때, `in` 연산자를 사용하여 조금 더 강력하게 만듭니다.
+이전과 차이는 없지만, 언어 내부적으로 `Record<"property-key-being-checked", unknown>` 타입을 교차합니다.
 
-So in our example, `packageJSON` will have its type narrowed from `unknown` to `object` to `object & Record<"name", unknown>`
-That allows us to access `packageJSON.name` directly and narrow that independently.
+따라서 위 예시에서, `packageJSON` 타입은 `unknown`에서 `object`로 그다음 `object & Record<"name", unknown>`로 타입이 좁혀집니다.
+이를 통해 `packageJSON.name`에 직접 접근이 가능해지고 독립적으로 좁혀집니다.
 
 ```ts
 interface Context {
@@ -199,11 +199,11 @@ interface Context {
 
 function tryGetPackageName(context: Context): string | undefined {
     const packageJSON = context.packageJSON;
-    // Check to see if we have an object.
+    // 객체 여부를 확인합니다.
     if (packageJSON && typeof packageJSON === "object") {
-        // Check to see if it has a string name property.
+        // 문자열 타입의 name 프로퍼티를 가지고 있는지 확인합니다.
         if ("name" in packageJSON && typeof packageJSON.name === "string") {
-            // Just works!
+            // 정상 동작합니다!
             return packageJSON.name;
         }
     }
@@ -212,15 +212,15 @@ function tryGetPackageName(context: Context): string | undefined {
 }
 ```
 
-TypeScript 4.9 also tightens up a few checks around how `in` is used, ensuring that the left side is assignable to the type `string | number | symbol`, and the right side is assignable to `object`.
-This helps check that we're using valid property keys, and not accidentally checking primitives.
+또한 TypeScript 4.9는`in`의 사용성에서 확인하는 부분을 강화하여 왼쪽에는 `string | number | symbol`, 오른쪽에는 `object`로만 할당할 수 있도록 보장합니다.
+이를 이용해서 프로퍼티 키가 유효한지, 실수로 프리미티브 검증을 놓쳤는지 확인할 수 있습니다.
 
-For more information, [read the implementing pull request](https://github.com/microsoft/TypeScript/pull/50666)
+더 많은 정보를 얻고 싶다면, [이를 구현한 pull request를 읽어보세요](https://github.com/microsoft/TypeScript/pull/50666)
 
-## <a name="auto-accessors-in-classes"> Auto-Accessors in Classes
+## <a name="auto-accessors-in-classes"> 클래스의 자동 접근자
 
-TypeScript 4.9 supports an upcoming feature in ECMAScript called auto-accessors.
-Auto-accessors are declared just like properties on classes, except that they're declared with the `accessor` keyword.
+TypeScript 4.9는 자동 접근자라고 하는 ECMAScript의 향후 기능을 지원합니다.
+자동 접근자는 `accessor` 키워드로 선언된다는 점을 제외하면 클래스의 속성처럼 선언됩니다.
 
 ```ts
 class Person {
@@ -232,7 +232,7 @@ class Person {
 }
 ```
 
-Under the covers, these auto-accessors "de-sugar" to a `get` and `set` accessor with an unreachable private property.
+내부적으로 이러한 자동 접근자는 도달할 수 없는 private 프로퍼티의 `get` 및 `set` 접근자로 "de-sugar"됩니다.
 
 ```ts
 class Person {
@@ -251,7 +251,7 @@ class Person {
 }
 ```
 
-You can [read up more about the auto-accessors pull request on the original PR](https://github.com/microsoft/TypeScript/pull/49705).
+[자세한 내용은 자동 접근자에 대한 원본 pull request](https://github.com/microsoft/TypeScript/pull/49705)에서 확인할 수 있습니다.
 
 ## Checks For Equality on `NaN`