docs: understanding knowledge, naming page translated into Korean (#762)

* docs: understanding knowlege-types, naming page translated into Korean

* docs: lnowledge-types, naming  page feedback

* fix: knownledge-types page text link add

i18n/kr/docusaurus-plugin-content-docs/current/about/understanding/knowledge-types.md

@@ -5,25 +5,37 @@ sidebar_label: 프로젝트의 지식 유형
 
 # 프로젝트의 지식 유형
 
-소프트웨어 프로젝트에서 필요한 지식은 다음과 같은 유형으로 분류할 수 있습니다:
-
-* **기반 지식 (Fundamental Knowledge)**  
-  컴퓨터 과학의 기본 원리, 자료구조, 알고리즘, 프로그래밍 언어의 동작 원리, API 설계 패턴 등 시간이 지나도 본질적 가치가 변하지 않는 지식을 의미합니다.
-
-* **기술 스택 (Technical Stack)**  
-  프로그래밍 언어, 프레임워크, 라이브러리 등 프로젝트에서 사용되는 기술 도구들에 대한 전문 지식을 의미합니다. 이는 프로젝트의 기술적 기반을 구성합니다.
-
-* **프로젝트 도메인 지식 (Project Domain Knowledge)**  
-  특정 프로젝트의 비즈니스 로직, 아키텍처 결정사항, 개발 규칙 등 해당 프로젝트에 고유한 지식을 의미합니다. 이는 프로젝트 외부에서의 재사용성은 낮지만, 팀원들의 효과적인 협업을 위해 필수적입니다.
+소프트웨어 프로젝트를 개발할 때 다루게 되는 지식은 크게 세 가지로 나눌 수 있습니다:
+
+### 기반 지식 (Fundamental Knowledge)
+프로그래밍의 기본이 되는 지식으로, 시간이 지나도 크게 변하지 않습니다:
+- 알고리즘과 자료구조
+- 컴퓨터 과학의 핵심 개념
+- 프로그래밍 언어의 기본 원리
+
+### 기술 스택 (Technical Stack)
+프로젝트 개발에 직접적으로 사용되는 도구들에 대한 지식입니다:
+- 프로그래밍 언어와 프레임워크
+- 라이브러리와 개발 도구
+- 개발 환경과 배포 도구
+
+### 프로젝트 도메인 지식 (Project Domain Knowledge)
+특정 프로젝트에만 해당하는 고유한 지식입니다:
+- 비즈니스 로직과 규칙
+- 프로젝트만의 아키텍처 결정사항
+- 팀 내 개발 규칙과 관례
 
 :::note
-
-**Feature-Sliced Design**은 "프로젝트 도메인 지식"에 대한 의존도를 최소화하고, 지식과 책임을 팀 전체에 효율적으로 분산시키는 것을 지향합니다. 이를 통해 새로운 팀원의 적응 과정을 체계화하고 가속화할 수 있습니다.
-
+**Feature-Sliced Design**은 이러한 지식 유형을 고려하여 설계되었습니다:
+- 프로젝트 도메인 지식에 대한 의존도를 최소화
+- 기술 스택 지식을 체계적으로 구조화
+- 새로운 팀원의 적응 과정을 단순화
 :::
 
 ## 참고 자료 {#see-also}
 
-- [(비디오) Ilya Klimov — 지식의 유형에 대하여][ext-klimov]
+- [(영상 🇷🇺) Ilya Klimov - 지식 유형에 관하여][ext-klimov]
 
 [ext-klimov]: https://youtu.be/4xyb_tA-uw0?t=249
+
+

i18n/kr/docusaurus-plugin-content-docs/current/about/understanding/naming.md

@@ -0,0 +1,65 @@
+---
+sidebar_position: 4
+---
+
+# 네이밍 (Naming)
+
+개발자들은 같은 대상을 각자의 경험과 관점에 따라 다르게 부르곤 합니다. 예를 들어:
+
+- UI 컴포넌트를 "ui", "components", "ui-kit", "views" 등으로 표현
+- 공통 코드를 "core", "shared", "app" 등으로 지칭
+- 비즈니스 로직을 "store", "model", "state" 등으로 명명
+
+## Feature-Sliced Design의 표준 네이밍 {#naming-in-fsd}
+
+FSD는 다음과 같이 명확한 네이밍 규칙을 제시합니다:
+
+### Layers (계층)
+- `app`
+- `processes`
+- `pages`
+- `features`
+- `entities`
+- `shared`
+
+### Segments (세그먼트)
+- `ui`
+- `model`
+- `lib`
+- `api`
+- `config`
+
+이러한 표준 용어를 사용하면:
+- 팀 내 의사소통이 명확해집니다
+- 새로운 팀원의 적응이 쉬워집니다
+- 커뮤니티와의 지식 공유가 용이해집니다
+
+## 네이밍 충돌 해결 {#when-can-naming-interfere}
+
+FSD 용어가 프로젝트의 비즈니스 용어와 중복될 수 있습니다. 예시:
+
+- `FSD#process` vs 애플리케이션의 시뮬레이션 프로세스,
+- `FSD#page` vs 로그 페이지,
+- `FSD#model` vs 자동차 모델.
+
+### 용어 사용 가이드
+
+1. 기술적 커뮤니케이션
+   - FSD 용어 사용 시 "FSD" 접두어 사용을 권장합니다
+   - 예: "이 기능을 FSD features 계층으로 이동하는 것이 좋겠습니다"
+
+2. 비기술적 커뮤니케이션
+   - FSD 관련 용어 사용을 피하고 일반적인 비즈니스 용어 사용
+   - 예: 코드 구조 대신 기능이나 목적 중심으로 설명
+
+## 참고 {#see-also}
+
+- [(토론) Naming의 적응성][disc-src]
+- [(토론) Entities Naming 설문조사][disc-naming]
+- [(토론) "processes" vs "flows" vs ...][disc-processes]
+- [(토론) "model" vs "store" vs ...][disc-model]
+
+[disc-model]: https://github.com/feature-sliced/documentation/discussions/68
+[disc-naming]: https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-464894
+[disc-processes]: https://github.com/feature-sliced/documentation/discussions/20
+[disc-src]: https://github.com/feature-sliced/documentation/discussions/16