diff --git a/config/docusaurus/i18n.js b/config/docusaurus/i18n.js
index c9c525b406..bea96e6a50 100644
--- a/config/docusaurus/i18n.js
+++ b/config/docusaurus/i18n.js
@@ -3,7 +3,7 @@ const { DEFAULT_LOCALE } = require("./consts");
 /** @type {import('@docusaurus/types').DocusaurusConfig["i18n"]} */
 const i18n = {
     defaultLocale: DEFAULT_LOCALE,
-    locales: ["ru", "en", "uz"],
+    locales: ["ru", "en", "uz", "kr"],
     localeConfigs: {
         ru: {
             label: "Русский",
@@ -14,6 +14,9 @@ const i18n = {
         uz: {
             label: "O'zbekcha",
         },
+        kr: {
+            label: "한국어",
+        },
     },
 };
 
diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/get-started/index.mdx b/i18n/kr/docusaurus-plugin-content-docs/current/get-started/index.mdx
new file mode 100644
index 0000000000..39f2ac22a7
--- /dev/null
+++ b/i18n/kr/docusaurus-plugin-content-docs/current/get-started/index.mdx
@@ -0,0 +1,38 @@
+---
+hide_table_of_contents: true
+pagination_prev: intro
+---
+
+import { PlaySquareOutlined, QuestionCircleOutlined, RocketOutlined } from "@ant-design/icons";
+import NavCard from "@site/src/shared/ui/nav-card/tmpl.mdx";
+
+# 🚀 Get Started
+
+<p class="summary">
+환영합니다! 이 섹션은 Feature-Sliced Design의 적용과 방법론의 기본을 익히는 데 도움을 줍니다. 또한 이 방법론의 주요 장점과 그것이 만들어진 이유를 이해하게 될 것입니다.
+</p>
+
+<NavCard
+    title="개요"
+    description="방법론의 개념과 사용에 대한 간단한 개요"
+    to="/docs/get-started/overview"
+    Icon={RocketOutlined}
+/>
+<NavCard
+    title="튜토리얼"
+    description="FSD 사용에 대한 입문 튜토리얼"
+    to="/docs/get-started/tutorial"
+    Icon={PlaySquareOutlined}
+/>
+<NavCard
+    title="FAQ"
+    description="자주 묻는 질문"
+    to="/docs/get-started/faq"
+    Icon={QuestionCircleOutlined}
+/>
+{/* <NavCard
+    title="Decomposition cheatsheet"
+    description="A memo on the decomposition of logic with examples and criteria"
+    to="/docs/get-started/cheatsheet"
+    Icon={BuildOutlined}
+/> */}
diff --git a/i18n/kr/docusaurus-plugin-content-docs/current/get-started/overview.mdx b/i18n/kr/docusaurus-plugin-content-docs/current/get-started/overview.mdx
new file mode 100644
index 0000000000..75d7f69a32
--- /dev/null
+++ b/i18n/kr/docusaurus-plugin-content-docs/current/get-started/overview.mdx
@@ -0,0 +1,137 @@
+---
+sidebar_position: 1
+---
+
+# 둘러보기
+
+**Feature-Sliced Design** (FSD)는 프론트엔드 애플리케이션의 구조를 잡는 아키텍처 방법론입니다. 간단히 말해, 코드 구성에 관한 규칙과 관례를 모아놓은 것입니다. 이 방법론의 주요 목적은 계속 변화하는 비즈니스 요구사항에 직면했을 때 프로젝트를 더 이해하기 쉽고 안정적으로 만드는 것입니다.
+
+FSD는 규칙을 제시할 뿐만 아니라, 실제 개발 과정을 돕는 다양한 도구들을 함께 제공합니다. 프로젝트 아키텍처를 확인하는 [린터][ext-steiger], CLI나 IDE를 통한 [폴더 생성기][ext-tools], 그리고 다양한 [예제][examples] 라이브러리를 제공합니다.
+
+## 내 프로젝트에 적합할까? {#is-it-right-for-me}
+
+FSD는 규모에 관계 없이 모든 팀과 프로젝트에서 사용할 수 있습니다. 다음과 같은 경우 여러분의 프로젝트에 적합합니다:
+
+- 여러분이 **프론트엔드**를 개발하고 있다면 (웹, 모바일, 데스크톱 등의 UI)
+- 여러분이 라이브러리가 아닌 **애플리케이션**을 만들고 있다면
+
+그게 다예요! 사용하는 프로그래밍 언어, UI 프레임워크, 상태 관리의 제한은 없습니다. FSD를 점진적으로 도입할 수 있고, 모노레포에서 사용할 수 있으며, 앱을 패키지로 분할하고 각각에 FSD를 개별적으로 적용하여 큰 규모로 확장할 수 있습니다.
+
+이미 아키텍처가 있고 FSD로의 전환을 고려 중이라면, 현재 아키텍처가 **문제를 일으키고 있는지** 확인하세요. 예를 들어, 프로젝트가 너무 커지고 상호 연결되어 새로운 기능을 효율적으로 구현하기 어려워졌거나, 많은 사람이 새롭게 팀에 합류할 것으로 예상되는 경우입니다. 현재 아키텍처가 잘 작동한다면 변경할 필요가 없을 수도 있습니다. 하지만 마이그레이션을 결정했다면, [마이그레이션][migration] 가이드를 확인하세요.
+
+## 간단한 예제 {#basic-example}
+
+다음은 FSD를 구현한 간단한 프로젝트입니다:
+
+- `📁 app`
+- `📁 pages`
+- `📁 shared`
+
+이 최상위 폴더들을 *레이어*(layers)라고 합니다. 더 자세히 살펴보겠습니다:
+
+- `📂 app`
+   - `📁 routes`
+   - `📁 analytics`
+- `📂 pages`
+   - `📁 home`
+   - `📂 article-reader`
+      - `📁 ui`
+      - `📁 api`
+   - `📁 settings`
+- `📂 shared`
+   - `📁 ui`
+   - `📁 api`
+
+📂 pages 내부의 폴더들을 *슬라이스*(slices)라고 합니다. 슬라이스는 도메인에 따라 레이어를 나눕니다.(이 경우에는 페이지별로)
+
+`📂 app`, `📂 shared`, 그리고 `📂 pages/article-reader` 내부의 폴더들을 *세그먼트*(segments)라고 합니다. 세그먼트는 코드의 기능적 목적, 다시말해 코드가 수행하는 역할 따라 슬라이스(또는 레이어)를 나눕니다.
+
+## 개념 {#concepts}
+
+레이어, 슬라이스, 세그먼트는 다음과 같은 계층 구조를 형성합니다:
+
+<figure>
+   ![아래에 설명된 FSD 개념의 계층 구조](/img/visual_schema.jpg)
+
+   <figcaption style={{ fontStyle: "italic", fontSize: "0.9em" }}>
+      <p>위 그림: 세 개의 수직 구조가 있으며, 왼쪽부터 오른쪽으로 각각 "레이어", "슬라이스", "세그먼트"로 표시되어 있습니다.</p>
+      <p>"레이어"에는 위에서 아래로 7개의 구분이 있으며, "app", "processes", "pages", "widgets", "features", "entities", "shared"로 표시되어 있습니다. "processes" 구분은 취소선이 그어져 있습니다. "entities" 구분은 두 번째 기둥인 "슬라이스"와 연결되어 있어, 두 번째 기둥이 "entities"의 내용이라는 것을 나타냅니다.</p>
+      <p>"슬라이스"에는 위에서 아래로 3개의 구분이 있으며, "user", "post", "comment"로 표시되어 있습니다. "post" 구분은 세 번째 기둥인 "세그먼트"와 연결되어 있어, 세 번째 기둥이 "post"의 내용임을 나타냅니다.</p>
+      <p>"세그먼트"에는 위에서 아래로 3개의 구분이 있으며, "ui", "model", "api"로 표시되어 있습니다.</p>
+   </figcaption>
+</figure>
+
+### 레이어 {#layers}
+
+레이어는 모든 FSD 프로젝트에서 표준화되어 있습니다. 모든 레이어를 사용할 필요는 없지만, 이름은 중요합니다. 현재(위에서 아래로) 7개가 있습니다:
+
+1. App\* - 앱을 실행하는 모든 것 - 라우팅, 진입점, 전역 스타일, 프로바이더.
+2. Processes(더 이상 사용되지 않음) - 페이지 간 복잡한 시나리오.
+3. Pages - 전체 페이지 또는 중첩 라우팅에서 페이지의 주요 부분.
+4. Widgets - 독립적으로 작동하는 대규모 기능 또는 UI 컴포넌트, 보통 하나의 완전한 기능.
+5. Features - 제품 전반에 걸쳐 재사용되는 기능 구현체로, 사용자에게 실질적인 비즈니스 가치를 제공하는 동작.
+6. Entities - 프로젝트가 다루는 비즈니스 엔티티, 예를 들어 user 또는 product.
+7. Shared* - 재사용 가능한 기능, 특히 프로젝트/비즈니스의 특성과 분리되어 있을 때 (반드시 그럴 필요는 없음).
+
+_\* - App과 Shared는 다른 레이어들과 달리 슬라이스를 가지지 않으며, 직접 세그먼트로 구성됩니다._  
+
+레이어를 다룰 때의 중요한 점은 한 레이어의 구성 요소는 반드시 아래에 있는 레이어의 구성 요소만 알수있고 임포트할 수 있다는 것입니다.
+
+
+### 슬라이스 {#slices}
+
+다음은 슬라이스입니다. 슬라이스는 비즈니스 도메인별로 코드를 분할합니다. 여러분은 자유롭게 이름을 선택할 수 있고, 원하는 만큼 많이 만들 수 있습니다. 슬라이스는 논리적으로 관련된 모듈들을 가까이 유지함으로써 코드베이스를 더 쉽게 탐색할 수 있게 해줍니다.
+
+슬라이스는 같은 레이어 안에서 다른 슬라이스를 참조할 수 없으며, 이 규칙은 높은 응집도와 낮은 결합도를 유지하는 데 도움이 됩니다.
+
+### 세그먼트 {#segments}
+
+슬라이스와 App, Shared 레이어는 세그먼트로 구성되며, 세그먼트는 목적에 따라 코드를 그룹화합니다. 세그먼트 이름은 표준에 의해 제한되지 않지만, 가장 일반적인 목적을 위한 몇 가지 관례적인 이름이 있습니다.:
+
+- `ui` - UI와 관련된 모든 것: UI 컴포넌트, 날짜 포맷터, 스타일 등.
+- `api` - 백엔드 상호작용: request 함수, 데이터 타입, mapper 등.
+- `model` - 데이터 모델: 스키마, 인터페이스, 스토어, 비즈니스 로직.
+- `lib` - 슬라이스 안에 있는 다른 모듈이 필요로 하는 라이브러리 코드.
+- `config` - 설정 파일과 기능 플래그.
+
+대부분의 레이어에서는 이 세그먼트들로 충분하며, Shared나 App에서만 자신만의 세그먼트를 만들 것입니다. 하지만 이건 꼭 지켜야하는 규칙은 아닙니다.
+
+## 장점 {#advantages}
+
+- **균일성**  
+  구조가 표준화되어 있어, 프로젝트가 더 균일해지며, 이는 새로운 멤버가 팀에 적응하는 것을 더 쉽게 만듭니다.
+
+- **변경과 리팩토링에 대한 안정성**  
+  한 레이어의 구성 요소는 같은 레이어나 상위 레이어의 다른 구성 요소를 사용할 수 없습니다. 이로 인해 앱의 사이드 이펙트 없이 격리된 수정을 할 수 있습니다.
+
+- **로직 재사용을 통제**  
+  레이어에 따라 코드를 매우 재사용 가능하게 또는 매우 지역적으로 만들 수 있습니다. 이는 **DRY** 원칙과 실용성 사이의 균형을 유지합니다.
+
+- **비즈니스와 사용자 요구에 대한 지향성**  
+  앱은 비즈니스 도메인으로 분할되며, 이름을 지을 때 비즈니스 언어 사용이 권장됩니다. 이로 인해 프로젝트와 무관한 부분을 완전히 이해하지 않고도 유용한 개발을 할 수 있습니다.
+
+## 점진적 도입 {#incremental-adoption}
+
+FSD로 마이그레이션하고자 하는 기존 코드베이스가 있다면, 다음과 같은 전략을 제안합니다. 이는 우리의 마이그레이션 경험에서 유용했던 방법입니다.
+
+1. App과 Shared 레이어를 모듈별로 천천히 구성하여 기반을 만드는 것으로 시작하세요.
+
+2. 기존의 모든 UI를 Widgets와 Pages에 큰 틀에서 분배하세요. FSD 규칙을 위반하는 의존성이 있더라도 괜찮습니다.
+
+3. 점진적으로 임포트 위반을 해결하고, Entities와 가능하다면 Features도 추출하기 시작하세요.
+
+리팩토링 중이거나 프로젝트의 특정 부분만 리팩토링할 때는 새로운 대규모 엔티티를 추가하지 않는 것이 좋습니다.
+
+## 다음 단계 {#next-steps}
+
+- **FSD로 사고하는 방법을 잘 이해하고 싶으신가요?** [튜토리얼][tutorial]을 확인해보세요.
+- **예제를 통해 배우는 것을 선호하시나요?** [예제][examples] 섹션에 많은 예제가 있습니다.
+- **질문이 있으신가요?** 우리의 [텔레그램 채팅방][ext-telegram]에 들러 커뮤니티의 도움을 받으세요.
+
+[tutorial]: /docs/get-started/tutorial
+[examples]: /examples
+[migration]: /docs/guides/migration/from-legacy
+[ext-steiger]: https://github.com/feature-sliced/steiger
+[ext-tools]: https://github.com/feature-sliced/awesome?tab=readme-ov-file#tools
+[ext-telegram]: https://t.me/feature_sliced
+
diff --git a/package.json b/package.json
index a123b49f85..aa67f23134 100644
--- a/package.json
+++ b/package.json
@@ -8,6 +8,7 @@
         "start:ru": "docusaurus start --locale ru",
         "start:en": "docusaurus start --locale en",
         "start:uz": "docusaurus start --locale uz",
+        "start:kr": "docusaurus start --locale kr",
         "build": "docusaurus build",
         "swizzle": "docusaurus swizzle",
         "test": "pnpm run test:lint && pnpm run build",