[G1-Sync] Manual knowledge update

10_Wiki/Topics/Programming & Language/엔터프라이즈 소프트웨어 개발.md

@@ -1,5 +1,5 @@
 ---
-id: P-REINFORCE-AUTO-117851
+id: [[P-Reinforce]]-AUTO-117851
 category: "10_Wiki/💡 Topics/Programming & Language"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -17,7 +17,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 엔터프라이즈 소프트
   엔터프라이즈 소프트웨어의 견고한 기반은 '관심사의 분리(SoC)', DRY(Don't Repeat Yourself), SOLID 등 코드의 결합도를 낮추고 응집도를 높이는 설계 원칙에서 출발합니다 [6-8]. 시스템의 각 부분이 단일 책임을 갖도록 논리적 단위를 철저히 격리하면 여러 개발팀이 동시에 작업할 수 있는 모듈성이 확보되고, 변경에 유연하게 대응할 수 있는 유지보수성과 확장성이 보장됩니다 [9, 10].
 
 * **주요 아키텍처 패턴의 활용:**
-  * **계층형 아키텍처 (Layered Architecture):** 시스템을 프레젠테이션, 비즈니스 로직(도메인), 데이터 액세스 등의 수평적 계층으로 분리하여 인접한 계층과만 통신하도록 제한하는 전통적이고 필수적인 엔터프라이즈 패턴입니다 [3, 11].
+  * **계층형 아키텍처 (Layered [[Architecture]]):** 시스템을 프레젠테이션, 비즈니스 로직(도메인), 데이터 액세스 등의 수평적 계층으로 분리하여 인접한 계층과만 통신하도록 제한하는 전통적이고 필수적인 엔터프라이즈 패턴입니다 [3, 11].
   * **마이크로서비스 아키텍처 (Microservices Architecture):** 복잡한 단일 시스템을 특정 비즈니스 기능을 담당하는 작고 자율적인 서비스들로 분해합니다 [4, 12]. 이를 통해 팀 단위로 독립적인 기술 스택 선택과 지속적 배포가 가능해져 엔터프라이즈의 혁신 속도를 높입니다 [4, 13].
   * **이벤트 기반 아키텍처 (Event-Driven Architecture):** 컴포넌트 간에 비동기적으로 이벤트를 생산 및 소비하며 통신하게 하여, 고부하 환경이나 실시간 데이터 처리에서 시스템의 응답성과 결함 허용 능력을 크게 향상시킵니다 [14, 15].
   * **클린 아키텍처 (Clean Architecture) 및 도메인 주도 설계 (DDD):** 가장 핵심이 되는 비즈니스 로직과 규칙을 시스템의 중심에 두고 UI, 데이터베이스, 프레임워크와 같은 기술적 세부 사항으로부터 완전히 분리합니다 [16, 17]. 비즈니스 전문가와 개발자가 공유하는 '보편적 언어(Ubiquitous Language)'를 바탕으로 복잡한 도메인 모델을 구축합니다 [16, 18].
@@ -33,7 +33,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 엔터프라이즈 소프트
 - **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** 소프트웨어 아키텍처 모범 사례, 마이크로서비스 아키텍처, [[클린 아키텍처]], [[도메인 주도 설계 (DDD)]], [[관심사의 분리 (Separation of Concerns)]]
+- **Related Topics:** 소프트웨어 아키텍처 모범 사례, 마이크로서비스 아키텍처, [[클린 아키텍처]], [[도메인 주도 설계 (DDD)]], [[관심사의 분리 ([[Separation of Concerns]])]]
 - **Projects/Contexts:** 넷플릭스(Netflix)의 마이크로서비스 및 Cosmos 플랫폼 전환 사례, 스포티파이(Spotify)의 스쿼드 모델 및 마이크로 프론트엔드 아키텍처 도입
 - **Contradictions/Notes:** 복잡성을 완벽하게 제어하기 위한 고도의 아키텍처 경계 구축이나 마이크로서비스로의 분할이 항상 정답은 아닙니다. 초기 팀 규모가 작거나 단순한 요구사항일 경우 모놀리식 구조가 효율적일 수 있으며, 미래를 위해 과도하게 완벽한 경계를 만드는 것은 YAGNI(You Aren't Gonna Need It) 원칙에 어긋나는 오버 엔지니어링이 될 수 있으므로 비용과 이점을 신중하게 따져 부분적 경계를 활용하는 것이 권장됩니다 [28-31].