docs: architecture page feedback

Author: Gaic4o

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

@@ -10,76 +10,74 @@ sidebar_position: 1
 
 ### Bus-factor & 온보딩
 
-제한된 수의 사람들만이 프로젝트와 그 아키텍처를 이해합니다.
+제한된 인원만이 프로젝트와 그 아키텍처를 이해합니다.
 
 **예시:**
 
-- *"개발에 새로운 인력을 추가하기가 어렵습니다""*
-- *"모든 문제에 대해 각자가 해결 방법에 대한 자신만의 의견을 가지고 있습니다 (앵귤러가 부러워요)"*
+- *"개발에 새로운 인력을 추가하기가 어렵습니다"*
+- *"문제 해결 방식에 대한 명확한 가이드라인이 없어 개발자마다 각기 다른 접근 방식을 사용합니다"*
 - *"이 거대한 모놀리스에서 무슨 일이 일어나고 있는지 이해할 수 없습니다"*
 
-### 암묵적이고 통제되지 않는 결과들
+### 의도치 않은 부작용과 통제되지 않는 영향
 
-개발/리팩토링 중 많은 암묵적인 부작용들이 있습니다 *("모든 것이 모든 것에 의존합니다")*
+개발/리팩토링 중 많은 의도치 않은 부작용들이 있습니다 *("모든 것이 모든 것에 의존합니다")*
 
 **예시:**
 
-- *"기능이 다른 기능을 임포트합니다"*
-- *"한 페이지의 스토어를 업데이트했더니 다른 페이지의 기능이 작동하지 않습니다*
-- *"로직이 애플리케이션 전체에 퍼져있어서 어디가 시작이고 어디가 끝인지 추적할 수 없습니다"*
+- *"기능 간의 부적절한 의존성이 발생하고 있습니다"*
+- *"한 페이지의 상태(store) 변경이 다른 페이지의 기능에 예기치 않은 영향을 미칩니다"*
+- *"비즈니스 로직이 애플리케이션 전반에 분산되어 있어 로직의 흐름을 추적하기 어렵습니다"*
 
 ### 통제되지 않는 로직의 재사용
 
 기존 로직을 재사용하거나 수정하기 어렵습니다.
 
 동시에, 보통 [두 가지 극단적인 경우](https://github.com/feature-sliced/documentation/discussions/14)가 나타납니다:
 
-- 각 모듈에 대해 로직을 완전히 처음부터 작성하거나 *(기존 코드베이스에서 반복 가능한 부분을 포함하여)*
-- 또는 모든 구현된 모듈을 `shared` 폴더로 옮기려는 경향이 있어, *대부분 한 곳에서만 사용되는 모듈들로 이루어진 커다란 코드 dump 만들어집니다.*
+- 각 모듈에 대해 로직을 완전히 처음부터 작성하거나 *(기존 코드베이스에서 재사용 가능한 부분까지 포함하여)*
+- 또는 모든 구현된 모듈을 `shared` 폴더로 이동하려는 경향이 있어, *대부분 단일 사용 목적의 모듈들이 무분별하게 축적되는 현상이 발생합니다.*
 
 **예시:**
 
-- *"프로젝트에 동일한 비즈니스 로직이 **N**개 구현되어 있으며, 이를 유지하는 데 지속적으로 비용이 발생하고 있습니다."*
-- *"button/pop-up/... 의 6가지 같은 형태의 컴포넌트가 있습니다"*
-- *"Dump of helpers"*
+- *"프로젝트 내에 동일한 비즈니스 로직이 **N**번 중복 구현되어 있어 유지보수 비용이 지속적으로 발생합니다"*
+- *"동일한 기능의 버튼/팝업 등 UI 컴포넌트가 여러 버전으로 존재합니다"*
+- *"유틸리티 함수들이 체계 없이 누적되어 있습니다"*
 
 ## 요구사항
 
-따라서 이상적인 아키텍처를 위한 *필요 요건*을 정의하는 것이 합리적일 것입니다.
+이상적인 아키텍처를 위한 *핵심 요구사항*을 다음과 같이 정의할 수 있습니다.
 
 :::note
-
-"쉽다"는 대부분의 개발자들이 상대적으로 쉽게 이해할 수 있다는 의미입니다. [모든 사람에게 완벽한 솔루션을 제공하는 것은 현실적으로 불가능하기 때문입니다.](/docs/about/mission#limitations)
-
+여기서 "쉽다"라는 표현은 "대다수의 개발자들이 합리적인 시간 내에 이해하고 적용할 수 있다"는 의미입니다. [모든 개발자와 상황에 완벽하게 부합하는 솔루션은 현실적으로 불가능하기 때문입니다.](/docs/about/mission#limitations)
 :::
 
 ### 명시성
 
-- 팀이 프로젝트와 아키텍처를 **쉽게 이해하고 설명할 수 있어야** 합니다.
-- 구조는 프로젝트의 **비즈니스 가치를 반영**해야 합니다.
-- 추상화 간의 **연결과 부작용**이 명확히 드러나야 합니다.
-- **중복된 로직을 쉽게 탐지**할 수 있어야 합니다.
+- 팀원들이 프로젝트 구조와 아키텍처를 **직관적으로 이해하고 설명할 수 있어야** 합니다.
+- 아키텍처는 프로젝트의 **비즈니스 도메인과 가치를 명확히 반영**해야 합니다.
+- 추상화 계층 간의 **의존성과 부작용**이 명확히 파악되어야 합니다.
+- **중복 로직을 효과적으로 식별**할 수 있어야 합니다.
 - 프로젝트 전반에 걸쳐 **로직이 분산**되지 않도록 해야 합니다.
-- **너무 많은 이질적인 추상화와 규칙**이 생기지 않도록 해야 합니다.
+- **불필요한 추상화와 복잡한 규칙**을 최소화해야 합니다.
 
 ### 제어
 
-- 좋은 아키텍처는 **기능 추가와 문제 해결 속도를 높여야** 합니다.
-- 프로젝트의 전반적인 개발 과정을 효율적으로 제어할 수 있어야 합니다.
-- **코드를 확장, 수정, 삭제하기** 쉽게 만들어야 합니다.
-- 기능별로 **분리와 격리**가 명확히 이루어져야 합니다.
-- 각 컴포넌트는 **쉽게 교체하고 제거할 수 있어야** 합니다.
-  - *[변경을 대비한 최적화는 필수가 아닙니다][ext-kof-not-modification] - 미래를 정확히 예측할 수 없기 때문입니다.*
-  - *[삭제를 용이하게 하는 최적화가 더 중요합니다][ext-kof-but-removing] - 이미 존재하는 컨텍스트를 기반으로 작업하는 것이 더 현실적입니다.*
+- 효과적인 아키텍처는 **새로운 기능 개발과 문제 해결의 생산성을 향상**시켜야 합니다.
+- 프로젝트의 전반적인 개발 흐름을 효율적으로 관리할 수 있어야 합니다.
+- **코드의 확장성, 유지보수성, 제거 용이성**을 보장해야 합니다.
+- 기능 단위의 **명확한 경계와 격리**가 보장되어야 합니다.
+- 각 컴포넌트는 **높은 교체성과 제거 용이성**을 가져야 합니다.
+  - *[변경을 위한 과도한 최적화는 지양합니다][ext-kof-not-modification] - 미래의 변경사항을 정확히 예측하기 어렵기 때문입니다.*
+  - *[제거 용이성을 위한 설계가 더 중요합니다][ext-kof-but-removing] - 현재의 컨텍스트를 기반으로 한 의사결정이 더 실용적이기 때문입니다.*
 
 ### 적응성
 
-- 좋은 아키텍처는 **대다수의 프로젝트**에서 활용 가능해야 합니다.
-  - *기존 인프라와 잘 연동될 수 있어야 합니다.*
-  - *개발의 모든 단계에서 유연하게 적용될 수 있어야 합니다.*
-- 특정 프레임워크나 플랫폼에 의존하지 않아야 합니다.
-- 개발이 병렬로 진행될 수 있도록 하며, **프로젝트와 팀을 쉽게 확장**할 수 있어야 합니다.
-- **변화하는 요구사항과 상황에도 쉽게 적응**할 수 있어야 합니다.
+- 효과적인 아키텍처는 **다양한 규모와 유형의 프로젝트**에 적용 가능해야 합니다.
+  - *기존 시스템 및 인프라와의 원활한 통합이 가능해야 합니다.*
+  - *프로젝트의 모든 개발 단계에서 일관되게 적용될 수 있어야 합니다.*
+- 특정 기술 스택이나 플랫폼에 종속되지 않아야 합니다.
+- **병렬 개발과 팀 확장**이 용이해야 합니다.
+- **비즈니스 요구사항과 기술 환경의 변화**에 유연하게 대응할 수 있어야 합니다.
 
 ## See also