feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,16 +1,29 @@
|
||||
---
|
||||
category: Unified
|
||||
id: wiki-2026-0508-conway-s-law
|
||||
title: "Conway's Law"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
title: [[Conway's Law (콘웨이의 법칙)]]
|
||||
last_updated: 2026-05-02
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Conway's Law (콘웨이의 법칙)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
콘웨이의 법칙(Conway's Law)은 1967년 컴퓨터 프로그래머 멜빈 콘웨이(Melvin Conway)가 처음 관찰한 개념으로, 시스템을 설계하는 조직은 해당 조직의 의사소통 구조를 그대로 복제한 설계를 만들어내도록 제약을 받는다는 인지적 제약(Cognitive constraints)을 의미합니다 [1]. 이 용어는 프레드 브룩스(Fred Brooks)가 자신의 저서 '맨먼스 미신(The Mythical Man-Month)'에서 인용하면서 대중적으로 널리 알려지게 되었습니다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **조직 구조와 아키텍처의 동기화:** 콘웨이의 법칙의 관점에서 볼 때, 소프트웨어 아키텍처는 단순히 내부 설계 방식에 그치는 것이 아니라 **코드베이스와 팀 구조를 모두 형성하는 거시적 아키텍처(macro-architecture)의 성격**을 띱니다 [2].
|
||||
* **계층형 아키텍처와의 매핑 사례:** 이 법칙이 적용되는 대표적인 예가 계층형 아키텍처(Layered Architecture)입니다. 아키텍처의 수평적 분할(horizontal slices)은 종종 실제 조직의 업무 그룹과 직접적으로 매핑됩니다 [2].
|
||||
* **프레젠테이션 계층(Presentation Layer):** UI/UX 팀 (예: React 개발자) [2]
|
||||
@@ -26,7 +39,7 @@ last_updated: 2026-05-02
|
||||
* **실제 팀 구조와의 매핑 사례 (계층형 아키텍처)**:
|
||||
이 법칙이 실제로 나타나는 대표적인 예가 [[Layered Architecture]](계층형 아키텍처)입니다. 계층형 아키텍처의 수평적 분할은 종종 조직 내 그룹과 직접적으로 매핑됩니다. 예를 들어, 프레젠테이션 계층(Presentation layer)은 React 개발자로 구성된 UI/UX 팀과 연결되고, 비즈니스 계층(Business layer)은 Java 개발자로 구성된 백엔드 팀과 매핑되며, 데이터베이스 계층(Database layer)은 DBA(데이터베이스 관리자) 팀으로 나뉘어 구성되는 형태를 띠게 됩니다 [2].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
소스에 관련 정보가 부족합니다.
|
||||
|
||||
(다만, 제공된 소스의 맥락에 따르면, 시스템을 설계하는 조직은 **자신들의 의사소통 구조를 복제한 설계를 만들도록 인지적으로 '제약(constrained)'을 받는다는 점 자체**가 가장 큰 제약 사항입니다 [1]. 즉, 기술적으로 다른 아키텍처 패턴이 더 적합한 상황이라 하더라도, 개발 조직이 UI, 백엔드, DB 부서로 분리되어 있다면 조직 구조의 한계로 인해 자연스럽게 계층형 아키텍처(Layered Architecture)와 같은 형태로 설계가 고착화될 수 있다는 부작용을 내포하고 있습니다 [1, 2].)
|
||||
@@ -37,7 +50,7 @@ last_updated: 2026-05-02
|
||||
|
||||
(다만 제공된 소스에 한정하여 유추할 때, 콘웨이의 법칙에 따라 [[Layered Architecture]] 등의 패턴이 기술적 구조와 조직 구조를 동일하게 고착화시키는 경우, 설계가 조직의 구조적 한계와 제약(Cognitive constraints)에 종속된다는 점을 주의해야 합니다. 조직의 그룹 분할이 코드의 분할을 강제하게 되어, 순수한 비즈니스 도메인 중심의 유연한 마이크로(Micro) 설계를 가로막는 요소로 작용할 가능성을 시사합니다 [1, 2].)
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
|
||||
#### [조직 및 아키텍처 설계 구조]
|
||||
@@ -114,4 +127,53 @@ last_updated: 2026-05-02
|
||||
|
||||
|
||||
## 📌 Brief 소스
|
||||
**Conway's Law(콘웨이의 법칙)**는 1967년 컴퓨터 프로그래머 멜빈 콘웨이(Melvin Conway)가 처음 관찰하여 제기한 인지적 제약(Cognitive constraints)에 관한 법칙입니다 [1]. 이 법칙은 "시스템을 설계하는 조직은 필연적으로 그 조직의 의사소통 구조를 복제한 형태의 설계를 만들어내게 된다"는 원리를 뜻합니다 [1]. 프레드 브룩스(Fred Brooks)가 자신의 저서인 *The Mythical Man-Month*에서 이 논문과 아이디어를 인용하면서 '콘웨이의 법칙'이라는 이름으로 널리 알려졌습니다 [1].
|
||||
**Conway's Law(콘웨이의 법칙)**는 1967년 컴퓨터 프로그래머 멜빈 콘웨이(Melvin Conway)가 처음 관찰하여 제기한 인지적 제약(Cognitive constraints)에 관한 법칙입니다 [1]. 이 법칙은 "시스템을 설계하는 조직은 필연적으로 그 조직의 의사소통 구조를 복제한 형태의 설계를 만들어내게 된다"는 원리를 뜻합니다 [1]. 프레드 브룩스(Fred Brooks)가 자신의 저서인 *The Mythical Man-Month*에서 이 논문과 아이디어를 인용하면서 '콘웨이의 법칙'이라는 이름으로 널리 알려졌습니다 [1].
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user