docs: slices-segments page translated into Korean

i18n/kr/docusaurus-plugin-content-docs/current/reference/slices-segments.mdx

@@ -0,0 +1,58 @@
+---
+title: 슬라이스와 세그먼트
+sidebar_position: 2
+pagination_next: reference/public-api
+---
+
+# 슬라이스와 세그먼트
+
+## 슬라이스
+
+슬라이스는 Feature-Sliced Design의 조직 계층 구조에서 두 번째 레벨에 해당하며, 제품, 비즈니스, 애플리케이션의 의미에 따라 코드를 그룹화하는 것을 목표로 합니다.
+
+각 슬라이스는 애플리케이션의 비즈니스 도메인을 기준으로 정의되며, 정해진 고정 표준은 없습니다. 예를 들어, 사진 갤러리 애플리케이션에서는 `photo`, `create-album`, `gallery-page` 와 같은 슬라이스가 있을 수 있습니다. 소셜 네트워크 애플리케이션에서는 `post`, `add-user-to-friends`, `news-feed` 등의 슬라이스가 필요할 수 있습니다.
+
+슬라이스들은 연관성이 높은 경우 특정 디렉토리 내에서 그룹화할 수 있습니다. 하지만 이 경우에도 코드 격리 규칙은 반드시 지켜야 합니다. 즉, 같은 디렉토리 안에 있더라도 **코드 공유는 금지**됩니다.
+
+!["post" 디렉토리 내부에는 "compose", "like", "delete"와 같은 기능들이 그룹화된 예시가 있습니다. 하지만, 이 디렉토리 안에 위치한 "some-shared-code.ts" 파일은 규칙 위반임을 나타내기 위해 취소선으로 표시되어 있습니다.](/img/graphic-nested-slices.svg)
+
+Shared 계층은 비즈니스 로직을 포함하지 않으며, 제품의 구체적인 의미를 담지 않습니다, App 계층은 애플리케이션 전체와 관련된 코드를 관리하며, 별도로 세분화할 필요가 없어 슬라이스를 포함하지 않습니다.
+
+### 슬라이스의 공개 API 규칙
+
+슬라이스 내부에서는 코드를 자유롭게 구성할 수 있습니다. 하지만 슬라이스가 적절한 공개 API를 제공하면 이러한 유연성이 문제가 되지 않습니다. **이는 슬라이스의 공개 API 규칙을 통해 보장됩니다.**
+
+> _모든 슬라이스(또는 슬라이스가 없는 계층의 세그먼트)는 반드시 공개 API를 정의해야 합니다._
+>
+> _슬라이스/세그먼트 외부의 모듈은 슬라이스/세그먼트 내부의 파일 구조를 참조할 수 없으며, 공개 API만 사용할 수 있습니다._ 
+
+공개 API의 중요성과 이를 생성하는 방법에 대한 모범 사례는 [공개 API 참조][ref--public-api]에서 자세히 확인할 수 있습니다.
+
+## 세그먼트
+
+세그먼트는 조직 계층 구조에서 세 번째이자 마지막 레벨로, 기술적인 성격에 따라 코드를 체계적으로 그룹화하는 역할을 합니다.
+
+다음은 표준화된 세그먼트 이름과 그 역할입니다:
+* `ui` — 사용자 인터페이스(UI) 구성 요소 및 데이터 포맷팅 함수
+* `model` — 비즈니스 로직, 데이터 저장소 및 데이터를 조작하는 함수
+* `lib` — 보조 기능 및 인프라 관련 코드
+* `api` — 외부 API와의 통신, 백엔드 API 메서드 호출
+
+사용자 정의 세그먼트를 만들 수도 있지만, 이는 정말 필요한 경우에만 생성하는 것이 좋습니다. 사용자 정의 세그먼트는 보통 슬라이스의 구조가 명확히 정의되지 않는 App 계층이나 공유 기능이 포함된 Shared 계층에서 주로 사용됩니다.
+
+
+### 예시
+
+| Layer    | `ui`         | `model`      | `lib`        | `api`        |
+| :------- | :----------- | :----------- | :----------- | :----------- |
+| Shared   | UI 키트를 정의하는 데 사용됩니다.      | 일반적으로 사용되지 않습니다. | 여러 관련 파일로 구성된 유틸리티 모듈을 포함합니다. <br /> 단, 간단한 도우미 함수가 필요하다면 [lodash-es][ext--lodash]와 같은 외부 유틸리티 라이브러리를 사용하는 것이 더 적합합니다. | 인증이나 캐싱과 같은 추가 기능을 제공하는 간단한 API 클라이언트를 포함합니다. |
+| Entities | 상호작용 요소를 위한 슬롯이 포함된 비즈니스 엔터티의 스켈레톤 구조를 정의합니다. | 엔터티 인스턴스의 데이터를 저장하거나 조작하는 함수가 포함됩니다. <br /> 특히 서버에서 제공받은 데이터를 저장하는 데 적합합니다. <br /> 단, [TanStack Query][ext--tanstack-query] 또는 다른 암시적 데이터 관리 방식을 사용한다면 이 세그먼트를 생략할 수도 있습니다. | 데이터 저장소와 관련되지 않은 엔터티 인스턴스를 조작하는 데 필요한 함수를 정의합니다. | Shared 계층의 API 클라이언트를 활용하여 백엔드와 통신하는 API 메서드를 포함합니다. |
+| Features | 사용자가 특정 기능을 사용할 수 있도록 돕는 인터랙티브 요소를 포함합니다. | 비즈니스 로직과 인프라 데이터 저장소를 관리합니다. <br /> 예를 들어, 현재 앱 테마 관리처럼 실제로 사용자에게 가치를 제공하는 코드를 이 세그먼트에 작성합니다. | `model` 세그먼트에서 비즈니스 로직을 간결하게 설명하고 보조하는 인프라 코드를 포함합니다. | 특정 기능을 백엔드에서 구현하는 API 메서드를 정의하며, 필요시 Entities 계층의 API 메서드들을 조합하여 사용할 수 있습니다. |
+| Widgets  | Entities와 Features를 통합하여 독립적인 UI 블록을 구성합니다. <br /> 여기에 오류 경계나 로딩 상태도 포함될 수 있습니다. | 필요한 경우 인프라 데이터 저장소를 관리합니다. | 비즈니스 로직과 무관한 상호작용(예: 제스처)이나 페이지에서 필요한 기타 코드를 포함합니다. | 일반적으로 사용되지 않지만, 특정 경우 중첩된 라우팅 컨텍스트(예: [Remix][ext--remix])에서 데이터 로더를 포함할 수 있습니다.
+| Pages    | Entities, Features, Widgets를 결합하여 완전한 페이지를 구성하며, 여기에도 오류 경계와 로딩 상태를 포함할 수 있습니다. | 일반적으로 사용되지 않습니다. | 비즈니스와 무관한 상호작용(예: 제스처)이나 전체적인 사용자 경험을 제공하기 위해 필요한 코드를 포함합니다. | SSR(Server-Side Rendering) 지향 프레임워크를 위한 데이터 로더를 포함합니다. |
+
+
+[ref--public-api]: /docs/reference/public-api
+[ext--lodash]: https://www.npmjs.com/package/lodash-es
+[ext--tanstack-query]: https://tanstack.com/query/latest
+[ext--remix]: https://remix.run