docs: about architecture page translated into Korean

Author: Gaic4o

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

@@ -0,0 +1,97 @@
+---
+sidebar_position: 1
+---
+
+# 아키텍처에 대하여
+
+## 문제점들
+
+일반적으로 아키텍처에 대한 논의는 프로젝트에서 특정 문제로 인해 개발이 중단될 때 제기됩니다.
+
+### Bus-factor & 온보딩
+
+제한된 수의 사람들만이 프로젝트와 그 아키텍처를 이해합니다.
+
+**예시:**
+
+- *"개발에 새로운 인력을 추가하기가 어렵습니다""*
+- *"모든 문제에 대해 각자가 해결 방법에 대한 자신만의 의견을 가지고 있습니다 (앵귤러가 부러워요)"*
+- *"이 거대한 모놀리스에서 무슨 일이 일어나고 있는지 이해할 수 없습니다"*
+
+### 암묵적이고 통제되지 않는 결과들
+
+개발/리팩토링 중 많은 암묵적인 부작용들이 있습니다 *("모든 것이 모든 것에 의존합니다")*
+
+**예시:**
+
+- *"기능이 다른 기능을 임포트합니다"*
+- *"한 페이지의 스토어를 업데이트했더니 다른 페이지의 기능이 작동하지 않습니다*
+- *"로직이 애플리케이션 전체에 퍼져있어서 어디가 시작이고 어디가 끝인지 추적할 수 없습니다"*
+
+### 통제되지 않는 로직의 재사용
+
+기존 로직을 재사용하거나 수정하기 어렵습니다.
+
+동시에, 보통 [두 가지 극단적인 경우](https://github.com/feature-sliced/documentation/discussions/14)가 나타납니다:
+
+- 각 모듈에 대해 로직을 완전히 처음부터 작성하거나 *(기존 코드베이스에서 반복 가능한 부분을 포함하여)*
+- 또는 모든 구현된 모듈을 `shared` 폴더로 옮기려는 경향이 있어, *대부분 한 곳에서만 사용되는 모듈들로 이루어진 커다란 코드 dump 만들어집니다.*
+
+**예시:**
+
+- *"프로젝트에 동일한 비즈니스 로직이 **N**개 구현되어 있으며, 이를 유지하는 데 지속적으로 비용이 발생하고 있습니다."*
+- *"button/pop-up/... 의 6가지 같은 형태의 컴포넌트가 있습니다"*
+- *"Dump of helpers"*
+
+## 요구사항
+
+따라서 이상적인 아키텍처를 위한 *필요 요건*을 정의하는 것이 합리적일 것입니다.
+
+:::note
+
+"쉽다"는 대부분의 개발자들이 상대적으로 쉽게 이해할 수 있다는 의미입니다. [모든 사람에게 완벽한 솔루션을 제공하는 것은 현실적으로 불가능하기 때문입니다.](/docs/about/mission#limitations)
+
+:::
+
+### 명시성
+
+- 팀이 프로젝트와 아키텍처를 **쉽게 이해하고 설명할 수 있어야** 합니다.
+- 구조는 프로젝트의 **비즈니스 가치를 반영**해야 합니다.
+- 추상화 간의 **연결과 부작용**이 명확히 드러나야 합니다.
+- **중복된 로직을 쉽게 탐지**할 수 있어야 합니다.
+- 프로젝트 전반에 걸쳐 **로직이 분산**되지 않도록 해야 합니다.
+- **너무 많은 이질적인 추상화와 규칙**이 생기지 않도록 해야 합니다.
+
+### 제어
+
+- 좋은 아키텍처는 **기능 추가와 문제 해결 속도를 높여야** 합니다.
+- 프로젝트의 전반적인 개발 과정을 효율적으로 제어할 수 있어야 합니다.
+- **코드를 확장, 수정, 삭제하기** 쉽게 만들어야 합니다.
+- 기능별로 **분리와 격리**가 명확히 이루어져야 합니다.
+- 각 컴포넌트는 **쉽게 교체하고 제거할 수 있어야** 합니다.
+  - *[변경을 대비한 최적화는 필수가 아닙니다][ext-kof-not-modification] - 미래를 정확히 예측할 수 없기 때문입니다.*
+  - *[삭제를 용이하게 하는 최적화가 더 중요합니다][ext-kof-but-removing] - 이미 존재하는 컨텍스트를 기반으로 작업하는 것이 더 현실적입니다.*
+
+### 적응성
+
+- 좋은 아키텍처는 **대다수의 프로젝트**에서 활용 가능해야 합니다.
+  - *기존 인프라와 잘 연동될 수 있어야 합니다.*
+  - *개발의 모든 단계에서 유연하게 적용될 수 있어야 합니다.*
+- 특정 프레임워크나 플랫폼에 의존하지 않아야 합니다.
+- 개발이 병렬로 진행될 수 있도록 하며, **프로젝트와 팀을 쉽게 확장**할 수 있어야 합니다.
+- **변화하는 요구사항과 상황에도 쉽게 적응**할 수 있어야 합니다.
+
+## See also
+
+- [(React Berlin Talk) Oleg Isonen - Feature Driven Architecture][ext-kof]
+- [(React SPB Meetup #1) Sergey Sova - Feature Slices][ext-slices-spb]
+- [(Article) 프로젝트 모듈화에 대하여][ext-medium]
+- [(Article) 관점 분리와 기능 기반 구조화에 대하여][ext-ryanlanciaux]
+
+[ext-kof-not-modification]: https://youtu.be/BWAeYuWFHhs?t=1631
+[ext-kof-but-removing]: https://youtu.be/BWAeYuWFHhs?t=1666
+
+[ext-slices-spb]: https://t.me/feature_slices
+[ext-kof]: https://youtu.be/BWAeYuWFHhs
+[ext-medium]: https://alexmngn.medium.com/why-react-developers-should-modularize-their-applications-d26d381854c1
+[ext-ryanlanciaux]: https://ryanlanciaux.com/blog/2017/08/20/a-feature-based-approach-to-react-development/