docs: lnowledge-types, naming page feedback

Author: Gaic4o

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

@@ -1,25 +1,35 @@
 ---
 sidebar_position: 3
-sidebar_label: 지식 유형
+sidebar_label: 프로젝트 지식의 세 가지 유형
 ---
 
-# 프로젝트에서 다루는 지식의 유형
+# 프로젝트 지식의 세 가지 유형
 
-프로젝트에서는 다음과 같은 세 가지 주요 지식 유형을 구분할 수 있습니다:
+소프트웨어 프로젝트를 개발할 때 다루게 되는 지식은 크게 세 가지로 나눌 수 있습니다:
 
-* **기본 지식**  
-  시간이 지나도 크게 변하지 않는 핵심 지식입니다. 예를 들어, 알고리즘, 컴퓨터 과학의 기본 개념, 프로그래밍 언어의 작동 원리와 API 등이 이에 포함됩니다.
+### 기반 지식 (Fundamental Knowledge)
+프로그래밍의 기본이 되는 지식으로, 시간이 지나도 크게 변하지 않습니다:
+- 알고리즘과 자료구조
+- 컴퓨터 과학의 핵심 개념
+- 프로그래밍 언어의 기본 원리
 
-* **기술 스택**  
-  프로젝트에서 사용되는 기술 솔루션들에 대한 지식입니다. 여기에는 프로그래밍 언어, 프레임워크, 라이브러리 등 다양한 기술적 도구와 관련된 내용이 포함됩니다.
+### 기술 스택 (Technical Stack)
+프로젝트 개발에 직접적으로 사용되는 도구들에 대한 지식입니다:
+- 프로그래밍 언어와 프레임워크
+- 라이브러리와 개발 도구
+- 개발 환경과 배포 도구
 
-* **프로젝트 지식**  
-  해당 프로젝트에만 국한된 정보입니다. 이 지식은 외부에서는 크게 활용되지 않지만, 새로 합류한 개발자가 프로젝트에 빠르게 적응하고 효과적으로 기여하기 위해 꼭 알아야 하는 내용입니다.
+### 프로젝트 도메인 지식 (Project Domain Knowledge)
+특정 프로젝트에만 해당하는 고유한 지식입니다:
+- 비즈니스 로직과 규칙
+- 프로젝트만의 아키텍처 결정사항
+- 팀 내 개발 규칙과 관례
 
 :::note
-
-**Feature-Sliced Design** 은 "프로젝트 지식"의 의존도를 줄이고, 역할과 책임을 더 명확히 분배하며, 새로운 팀원들이 프로젝트에 보다 쉽게 적응할 수 있도록 돕는 설계 방식입니다.
-
+**Feature-Sliced Design**은 이러한 지식 유형을 고려하여 설계되었습니다:
+- 프로젝트 도메인 지식에 대한 의존도를 최소화
+- 기술 스택 지식을 체계적으로 구조화
+- 새로운 팀원의 적응 과정을 단순화
 :::
 
 ## See also {#see-also}

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

@@ -2,43 +2,60 @@
 sidebar_position: 4
 ---
 
-# 네이밍
+# 네이밍 (Naming)
 
-개발자는 각자의 경험과 관점에 따라 동일한 개체를 다르게 부르는 경우가 많아 팀 내에서 오해가 발생할 수 있습니다. 예를 들어:
+개발자들은 같은 대상을 각자의 경험과 관점에 따라 다르게 부르곤 합니다. 예를 들어:
 
-- 화면에 보이는 컴포넌트를 "ui", "components", "ui-kit", "views" 등으로 부를 수 있습니다.
-- 애플리케이션 전반에서 재사용되는 코드를 "core", "shared", "app" 등으로 표현할 수 있습니다.
-- 비즈니스 로직 코드를 "store", "model", "state" 등으로 지칭할 수 있습니다.
+- UI 컴포넌트를 "ui", "components", "ui-kit", "views" 등으로 표현
+- 공통 코드를 "core", "shared", "app" 등으로 지칭
+- 비즈니스 로직을 "store", "model", "state" 등으로 명명
 
-## Feature-Sliced Design에서의 네이밍 {#naming-in-fsd}
+## Feature-Sliced Design의 표준 네이밍 {#naming-in-fsd}
 
-방법론에서는 네이밍을 다음과 같이 체계적으로 정의합니다:
+FSD는 다음과 같이 명확한 네이밍 규칙을 제시합니다:
 
-- 레이어 이름: "app", "process", "page", "feature", "entity", "shared"
-- 세그먼트 이름: "ui", "model", "lib", "api", "config"
+### Layers (계층)
+- `app`
+- `processes`
+- `pages`
+- `features`
+- `entities`
+- `shared`
 
-이 표준 용어를 따르는 것은 팀 내에서, 특히 새로 합류한 개발자와의 협업에서 혼란을 줄이는 데 필수적입니다. 또한, 커뮤니티에 도움을 요청하거나 자료를 공유할 때도 표준화된 네이밍은 큰 장점이 됩니다.
+### Segments (세그먼트)
+- `ui`
+- `model`
+- `lib`
+- `api`
+- `config`
 
-## 네이밍 충돌 {#when-can-naming-interfere}
+이러한 표준 용어를 사용하면:
+- 팀 내 의사소통이 명확해집니다
+- 새로운 팀원의 적응이 쉬워집니다
+- 커뮤니티와의 지식 공유가 용이해집니다
 
-FSD에서 사용하는 용어가 비즈니스 용어와 겹치는 경우, 네이밍 충돌이 발생할 수 있습니다. 예를 들어:
+## 네이밍 충돌 해결 {#when-can-naming-interfere}
+
+FSD 용어가 프로젝트의 비즈니스 용어와 중복될 수 있습니다. 예시:
 
 - `FSD#process` vs 애플리케이션의 시뮬레이션 프로세스,
 - `FSD#page` vs 로그 페이지,
 - `FSD#model` vs 자동차 모델.
 
-예를 들어, 개발자가 코드에서 "process"라는 단어를 봤을 때, 그것이 정확히 어떤 프로세스를 의미하는지 파악하는 데 시간이 더 걸릴 수 있습니다.  이러한 **용어 충돌은 개발 과정을 방해할 수 있습니다.**
-
-만약 프로젝트 용어집에 FSD에서 사용하는 고유 용어가 포함되어 있다면, 팀원들 간의 커뮤니케이션뿐만 아니라, 비기술적 이해관계자와의 소통에서도 용어 사용에 세심한 주의가 필요합니다.
+### 용어 사용 가이드
 
-효율적인 의사소통을 위해, FSD 방법론에서는 사용되는 용어 앞에 "FSD"라는 접두사를 붙이는 방식을 권장합니다. 예를 들어, 특정 프로세스를 논의할 때 "우리가 이 프로세스를 FSD features 레이어에 배치할 수 있습니다."라고 말하면 더 명확하게 전달할 수 있습니다.
+1. 기술적 커뮤니케이션
+   - FSD 용어 사용 시 "FSD" 접두어 사용을 권장합니다
+   - 예: "이 기능을 FSD features 계층으로 이동하는 것이 좋겠습니다"
 
-하지만, 비기술적 이해관계자와 대화할 때는 FSD 고유 용어를 사용하지 않는 것이 좋습니다. 이 경우, 코드베이스의 내부 구조를 언급하기보다는 더 쉽게 이해할 수 있는 일반적인 용어로 설명하는 것이 바람직합니다.
+2. 비기술적 커뮤니케이션
+   - FSD 관련 용어 사용을 피하고 일반적인 비즈니스 용어 사용
+   - 예: 코드 구조 대신 기능이나 목적 중심으로 설명
 
 ## 참고 {#see-also}
 
-- [(토론) 네이밍의 적응성][disc-src]
-- [(토론) 엔티티 네이밍 설문조사][disc-naming]
+- [(토론) Naming의 적응성][disc-src]
+- [(토론) Entities Naming 설문조사][disc-naming]
 - [(토론) "processes" vs "flows" vs ...][disc-processes]
 - [(토론) "model" vs "store" vs ...][disc-model]