docs: understanding knowledge, naming page translated into Korean

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

@@ -0,0 +1,29 @@
+---
+sidebar_position: 3
+sidebar_label: 지식 유형
+---
+
+# 프로젝트에서 다루는 지식의 유형
+
+프로젝트에서는 다음과 같은 세 가지 주요 지식 유형을 구분할 수 있습니다:
+
+* **기본 지식**  
+  시간이 지나도 크게 변하지 않는 핵심 지식입니다. 예를 들어, 알고리즘, 컴퓨터 과학의 기본 개념, 프로그래밍 언어의 작동 원리와 API 등이 이에 포함됩니다.
+
+* **기술 스택**  
+  프로젝트에서 사용되는 기술 솔루션들에 대한 지식입니다. 여기에는 프로그래밍 언어, 프레임워크, 라이브러리 등 다양한 기술적 도구와 관련된 내용이 포함됩니다.
+
+* **프로젝트 지식**  
+  해당 프로젝트에만 국한된 정보입니다. 이 지식은 외부에서는 크게 활용되지 않지만, 새로 합류한 개발자가 프로젝트에 빠르게 적응하고 효과적으로 기여하기 위해 꼭 알아야 하는 내용입니다.
+
+:::note
+
+**Feature-Sliced Design** 은 "프로젝트 지식"의 의존도를 줄이고, 역할과 책임을 더 명확히 분배하며, 새로운 팀원들이 프로젝트에 보다 쉽게 적응할 수 있도록 돕는 설계 방식입니다.
+
+:::
+
+## See also {#see-also}
+
+- [(영상 🇷🇺) 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,48 @@
+---
+sidebar_position: 4
+---
+
+# 네이밍
+
+개발자는 각자의 경험과 관점에 따라 동일한 개체를 다르게 부르는 경우가 많아 팀 내에서 오해가 발생할 수 있습니다. 예를 들어:
+
+- 화면에 보이는 컴포넌트를 "ui", "components", "ui-kit", "views" 등으로 부를 수 있습니다.
+- 애플리케이션 전반에서 재사용되는 코드를 "core", "shared", "app" 등으로 표현할 수 있습니다.
+- 비즈니스 로직 코드를 "store", "model", "state" 등으로 지칭할 수 있습니다.
+
+## Feature-Sliced Design에서의 네이밍 {#naming-in-fsd}
+
+방법론에서는 네이밍을 다음과 같이 체계적으로 정의합니다:
+
+- 레이어 이름: "app", "process", "page", "feature", "entity", "shared"
+- 세그먼트 이름: "ui", "model", "lib", "api", "config"
+
+이 표준 용어를 따르는 것은 팀 내에서, 특히 새로 합류한 개발자와의 협업에서 혼란을 줄이는 데 필수적입니다. 또한, 커뮤니티에 도움을 요청하거나 자료를 공유할 때도 표준화된 네이밍은 큰 장점이 됩니다.
+
+## 네이밍 충돌 {#when-can-naming-interfere}
+
+FSD에서 사용하는 용어가 비즈니스 용어와 겹치는 경우, 네이밍 충돌이 발생할 수 있습니다. 예를 들어:
+
+- `FSD#process` vs 애플리케이션의 시뮬레이션 프로세스,
+- `FSD#page` vs 로그 페이지,
+- `FSD#model` vs 자동차 모델.
+
+예를 들어, 개발자가 코드에서 "process"라는 단어를 봤을 때, 그것이 정확히 어떤 프로세스를 의미하는지 파악하는 데 시간이 더 걸릴 수 있습니다.  이러한 **용어 충돌은 개발 과정을 방해할 수 있습니다.**
+
+만약 프로젝트 용어집에 FSD에서 사용하는 고유 용어가 포함되어 있다면, 팀원들 간의 커뮤니케이션뿐만 아니라, 비기술적 이해관계자와의 소통에서도 용어 사용에 세심한 주의가 필요합니다.
+
+효율적인 의사소통을 위해, FSD 방법론에서는 사용되는 용어 앞에 "FSD"라는 접두사를 붙이는 방식을 권장합니다. 예를 들어, 특정 프로세스를 논의할 때 "우리가 이 프로세스를 FSD features 레이어에 배치할 수 있습니다."라고 말하면 더 명확하게 전달할 수 있습니다.
+
+하지만, 비기술적 이해관계자와 대화할 때는 FSD 고유 용어를 사용하지 않는 것이 좋습니다. 이 경우, 코드베이스의 내부 구조를 언급하기보다는 더 쉽게 이해할 수 있는 일반적인 용어로 설명하는 것이 바람직합니다.
+
+## 참고 {#see-also}
+
+- [(토론) 네이밍의 적응성][disc-src]
+- [(토론) 엔티티 네이밍 설문조사][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