[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -1,139 +1,297 @@
|
||||
---
|
||||
id: wiki-2026-0508-cognitive-constraints
|
||||
title: Cognitive Constraints
|
||||
title: Cognitive Constraints (Conway's Law & Cognitive Load)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-0F145457]
|
||||
aliases: [Conway's Law, cognitive load, team topology, distributed cognition, mental model]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [cognitive-constraints, "conway's-law", layered-architecture, serverless-architecture, observability, cognitive-engineering]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [architecture, conway-law, team-topology, cognitive-load, distributed-systems, organization, devex]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-02
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: org / architecture
|
||||
applicable_to: [Team Design, System Architecture, Engineering Org]
|
||||
---
|
||||
|
||||
# [[Cognitive Constraints]]
|
||||
# Cognitive Constraints
|
||||
|
||||
## 📌 Brief 소스에 관련 정보가 부족합니다. (다만, 제공된 소스 내에서 조직적 구조 측면의 '콘웨이의 법칙'과 분산 시스템에서의 '인지적 부하'와 관련된 내용을 바탕으로 작성되었습니다.)
|
||||
## 매 한 줄
|
||||
> **"매 architecture 의 organization 의 communication 의 mirror"** (Conway 1967). 매 distributed system 의 cognitive load 의 explosion. 매 modern: Team Topologies (Skelton-Pais) — 매 stream-aligned + 매 platform + 매 enabling + 매 complicated subsystem.
|
||||
|
||||
인지적 제약(Cognitive Constraints)은 시스템을 설계하는 조직이 필연적으로 해당 조직의 의사소통 구조를 복제한 설계를 만들어낸다는 '콘웨이의 법칙(Conway's Law)'으로 대표되는 아키텍처 설계의 한계 및 원리를 의미한다 [1]. 또한, 이는 서버리스(Serverless)와 같은 고도의 분산 아키텍처 환경에서 로직이 여러 구성 요소로 파편화될 때 개발자가 시스템을 추적하고 디버깅하면서 겪게 되는 인지적 부하(Cognitive Load) 현상을 포함한다 [2, 3]. 즉, 이 개념은 소프트웨어 아키텍처가 단순한 기술적 구조를 넘어, 그것을 구축하고 유지보수하는 인간 및 조직의 인지적·구조적 한계와 깊이 결합되어 있음을 보여준다 [1, 4].
|
||||
## 매 핵심
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **콘웨이의 법칙(Conway's Law)과 조직적 제약:**
|
||||
인지적 제약의 핵심은 1967년 프로그래머 멜빈 콘웨이(Melvin Conway)가 처음 관찰한 조직적 현상으로 설명된다 [1]. 시스템을 설계하는 조직은 결국 그 조직 내부의 의사소통 구조를 그대로 모방한 설계를 산출하도록 제약을 받게 된다 [1]. 프레더릭 브룩스(Fred Brooks)는 자신의 저서인 *맨먼스 미신(The Mythical Man-Month)*에서 이 논문을 인용하며 이를 '콘웨이의 법칙'으로 대중화시켰다 [1].
|
||||
* **조직 구조와 거시적 아키텍처(Macro-Architecture)의 매핑:**
|
||||
조직 구조와 콘웨이의 법칙이라는 렌즈를 통해 바라보면, 계층형 아키텍처(Layered Architecture)는 단순한 기술적 계층 분리를 넘어 코드베이스와 팀을 형성하는 거시적 아키텍처로 기능한다 [4]. 이 패턴의 수평적 분할은 종종 조직 내 특정 그룹과 직접적으로 매핑된다. 예를 들어, 프레젠테이션(Presentation) 계층은 UI/UX 팀(React 개발자)에, 비즈니스(Business) 계층은 백엔드 팀(Java 개발자)에, 데이터베이스(Database) 계층은 DBA 팀에 상응하게 구성되는 인지적 및 구조적 동기화가 일어난다 [4].
|
||||
* **분산 시스템에서의 인지적 부하(Cognitive Load) 가중:**
|
||||
아키텍처 패턴에 따라 개발자가 시스템을 이해하고 디버깅하는 데 필요한 인지적 부하의 정도가 크게 달라진다. 예를 들어 모듈식 모놀리스(Modular Monolith)는 모든 로직이 한곳에 있어 코드를 단계별로 실행하고 로그를 추적하기 단순하지만, 서버리스(Serverless) 아키텍처에서는 로직이 다수의 함수로 파편화된다 [2, 3]. 특히 비동기적으로 트리거되는 함수들로 인해 에러 추적이 어려워지며, 이를 극복하기 위해 분산 추적(Distributed tracing) 및 에러 모니터링 도구를 도입해야 한다 [2, 3]. 이 과정은 시스템 관리를 가능하게는 하지만, 개발자의 인지적 부하(Cognitive Load)와 인프라 관리의 오버헤드를 크게 가중시키는 요인이 된다 [3].
|
||||
### Conway's Law (1967)
|
||||
> "Any organization that designs a system... will produce a design whose structure is a copy of the organization's communication structure."
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **조직 구조 매핑의 경직성 (Rigidity vs. Clarity):**
|
||||
계층형 아키텍처처럼 아키텍처가 기존 조직 구조와 강하게 매핑될 경우, 팀의 역할과 책임이 명확해진다는 장점이 있다 [4]. 그러나 이는 아키텍처와 조직 구조가 서로를 제약하게 되어(콘웨이의 법칙), 향후 시스템이 비즈니스 요구에 맞춰 유연하게 변해야 할 때 아키텍처뿐만 아니라 조직 구조까지 함께 개편해야 하는 커다란 반대 급부를 낳는다 [1, 4].
|
||||
* **독립적 배포 vs. 인지적 부하 (Agility vs. Cognitive Load):**
|
||||
서버리스 등 고도로 분산된 아키텍처는 개별 함수의 독립적인 배포와 자동화된 확장을 가능하게 하여 민첩성을 극대화한다 [5, 6]. 하지만 그 대가로 전체 시스템의 제어 흐름(Control flow)을 머릿속에 그리고 추적하기 어렵게 만들어 심각한 인지적 부하를 유발한다 [2, 3]. 이를 해결하기 위한 관측성(Observability) 툴 도입은 필수적이며, 이는 학습 곡선과 인프라 복잡도라는 또 다른 기술적 제약으로 이어진다 [3].
|
||||
→ 매 system 의 boundary = 매 team 의 boundary.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
### Inverse Conway Maneuver
|
||||
- 매 desired architecture 의 force → 매 team structure 의 reorganize.
|
||||
- 매 architecture-first organization design.
|
||||
- 매 Spotify model, 매 Amazon "two-pizza team".
|
||||
|
||||
#### [관계 유형 A (아키텍처 설계 원리)]
|
||||
- [[Conway's Law]]
|
||||
- 연결 이유: 인지적 제약(Cognitive Constraints)의 기원이 되는 법칙으로, 조직의 소통 구조가 시스템 아키텍처 설계에 미치는 필연적 제약을 설명하기 때문이다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 소프트웨어 아키텍처가 단순한 기술적 선택의 산물이 아니라, 해당 시스템을 구축하는 조직 구조의 거울이라는 사회-기술적(socio-technical) 관계를 이해할 수 있다.
|
||||
### Team Topologies (Skelton & Pais 2019)
|
||||
4 team type:
|
||||
1. **Stream-Aligned**: 매 user-facing capability 의 own.
|
||||
2. **Platform**: 매 internal infra service.
|
||||
3. **Enabling**: 매 stream-aligned 의 specialty 의 transfer.
|
||||
4. **Complicated Subsystem**: 매 specialist (ML, security).
|
||||
|
||||
#### [관계 유형 B (아키텍처 패턴 및 구조)]
|
||||
- [[Layered Architecture]]
|
||||
- 연결 이유: 콘웨이의 법칙이 투영되어 프레젠테이션(UI), 비즈니스(백엔드), 데이터베이스(DBA) 팀 등 조직 구조와 거시적 구조(Macro-architecture)가 일치하는 대표적인 사례이기 때문이다 [4].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 기능적 관심사의 분리가 실제 개발 조직의 분업화 및 인지적 한계와 어떻게 긴밀하게 연관되어 있는지 확인할 수 있다.
|
||||
- [[Serverless Architecture]]
|
||||
- 연결 이유: 모놀리스에 비해 분산된 아키텍처를 가짐으로써, 디버깅 및 전체 흐름 추적에 있어 개발자의 인지적 부하(Cognitive Load)를 가중시키는 직접적인 원인을 제공하기 때문이다 [2, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서비스 분산과 유연성이 개발자의 인지적 관리 용이성과 어떻게 트레이드오프 관계를 맺는지 명확히 파악할 수 있다.
|
||||
3 interaction:
|
||||
- **Collaboration**: 매 close partnership.
|
||||
- **X-as-a-Service**: 매 platform 의 consume.
|
||||
- **Facilitating**: 매 enabling 의 support.
|
||||
|
||||
#### [관계 유형 C (운영/관측성 도구)]
|
||||
- [[Observability]]
|
||||
- 연결 이유: 서버리스나 분산 시스템으로 인해 파편화된 로직이 초래하는 인지적 부하를 완화하기 위해 필수적으로 요구되는 모니터링 및 분산 추적(Distributed tracing) 기능이기 때문이다 [2, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처 구조의 한계와 개발자의 인지적 부담을 기술적인 도구를 통해 어떻게 상쇄하고 보완할 수 있는지 배울 수 있다.
|
||||
### Cognitive Load (3 type, Sweller 1988)
|
||||
1. **Intrinsic**: 매 task 의 inherent complexity.
|
||||
2. **Extraneous**: 매 unnecessary (poor doc, friction).
|
||||
3. **Germane**: 매 schema building (productive).
|
||||
|
||||
### Deeper Research Questions
|
||||
→ 매 team 의 capacity 의 finite — 매 design 의 reduce.
|
||||
|
||||
- 콘웨이의 법칙은 헥사고날(Hexagonal)이나 클린 아키텍처(Clean Architecture)와 같은 도메인 중심의 패턴을 도입할 때 조직 구조의 재편을 어떻게 강제하는가?
|
||||
- 서버리스(Serverless)나 이벤트 기반 아키텍처(EDA) 환경에서 개발자의 인지적 부하를 최소화하기 위한 분산 추적(Distributed Tracing)의 모범 사례는 무엇인가?
|
||||
- 거시적(Macro) 아키텍처가 팀 구조를 결정하는 상황에서, 마이크로서비스 도입 시 '두 판의 피자 팀(Two-pizza team)' 개념은 인지적 제약을 극복하는 데 어떤 기여를 하는가?
|
||||
- 역-콘웨이 법칙(Reverse Conway Maneuver)을 활용하여 목표하는 소프트웨어 아키텍처를 달성하기 위해 선제적으로 팀 조직을 구성하는 전략은 어떻게 적용되는가?
|
||||
- 시스템 장애나 에러 발생 시, 구조가 파편화된 서버리스 환경과 단일 구조인 모놀리식 환경에서 디버깅에 소요되는 인지적 오버헤드는 어떻게 정량적으로 비교할 수 있는가?
|
||||
### 매 architecture 의 cognitive load
|
||||
| Pattern | Cognitive Load |
|
||||
|---|---|
|
||||
| Monolith | Mid (one big mental model) |
|
||||
| Modular Monolith | Mid-Low |
|
||||
| Microservices (small) | Per-service Low + 매 cross-system High |
|
||||
| Serverless | Low per-function + 매 distributed High |
|
||||
| Distributed Monolith | High (worst) |
|
||||
|
||||
### Practical Application Contexts
|
||||
### 매 modern signal
|
||||
- **DevEx (Developer Experience)** 의 metric.
|
||||
- **Cognitive load survey** (DX scale).
|
||||
- **Build time, deploy time, time-to-first-PR**.
|
||||
- **Onboarding 의 weeks**.
|
||||
|
||||
- **Implementation:** 복잡성이 높은 로직을 구현할 때, 하나의 함수나 서비스가 가지는 역할을 명확히 제한하여 개발자가 코드를 이해하고 구현하는 데 필요한 인지적 부하를 줄여야 한다.
|
||||
- **System Design:** 소프트웨어의 아키텍처를 설계할 때 기술적인 완성도뿐만 아니라, 이 시스템을 유지보수할 팀의 구조, 소통 방식, 인력 구성 등 조직적 제약(콘웨이의 법칙)을 반드시 고려하여 설계해야 한다.
|
||||
- **Operation / Maintenance:** 운영 중인 서비스가 서버리스나 마이크로서비스 기반일 경우, 장애 발생 시 원인을 파악하는 데 드는 인지적 피로도를 줄이기 위해 로그 중앙화와 분산 추적(Observability) 시스템을 선제적으로 구축해야 한다.
|
||||
- **Learning Path:** 아키텍처 패턴의 기술적 장단점을 학습한 후, 해당 패턴이 개발 생태계와 조직 관리, 인간의 인지적 피로도에 미치는 영향 등 아키텍처의 사회-기술적(Socio-Technical) 영역으로 학습을 확장한다.
|
||||
- **My Project Relevance:** 현재 우리 프로젝트 팀의 구성(예: 프론트엔드 전문, 백엔드 전문)이 채택하려는 최신 아키텍처 패턴(예: 도메인별 수직 슬라이싱)과 불일치하지 않는지 점검하고, 인지적/구조적 제약에 따른 마찰을 예방하기 위한 기준점을 마련한다.
|
||||
### 매 응용
|
||||
1. **Org redesign**: 매 architecture follow.
|
||||
2. **Microservices boundary**: 매 team boundary 의 align.
|
||||
3. **Platform team**: 매 "as-a-service".
|
||||
4. **Documentation**: 매 reduce extraneous load.
|
||||
5. **Tooling**: 매 abstract complexity.
|
||||
|
||||
### Adjacent Topics
|
||||
### 매 anti-pattern
|
||||
- 매 fragmented team (matrix maze).
|
||||
- 매 god team (everyone everything).
|
||||
- 매 platform 의 stream-aligned 의 confuse.
|
||||
- 매 cognitive load 의 measure X.
|
||||
|
||||
- [[Domain-Driven Design (DDD)]]
|
||||
- 확장 방향: 복잡한 비즈니스 요구사항을 도메인 단위로 나누어 인지적 부하를 줄이고, 조직의 언어(Ubiquitous Language)를 코드와 일치시키는 설계 기법으로 확장하여 연구.
|
||||
- [[Team Topologies]]
|
||||
- 확장 방향: 콘웨이의 법칙을 역으로 활용하여, 빠르고 지속 가능한 소프트웨어 흐름을 만들기 위해 인지적 부하(Cognitive Load)를 고려하여 팀 구조와 상호작용을 설계하는 구체적인 조직 방법론으로 확장.
|
||||
## 💻 패턴 (응용)
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 🤖 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
|
||||
### Team Topologies design
|
||||
```yaml
|
||||
teams:
|
||||
- name: Checkout
|
||||
type: stream-aligned
|
||||
domain: checkout / payment / cart
|
||||
consumes: [Platform/Auth, Platform/Notifications]
|
||||
|
||||
- name: Search
|
||||
type: stream-aligned
|
||||
domain: search / recommendation
|
||||
consumes: [Platform/Data, Platform/ML]
|
||||
|
||||
- name: Platform/Auth
|
||||
type: platform
|
||||
api: 'auth.example.com (OAuth, SSO)'
|
||||
consumed_by: [all stream-aligned]
|
||||
|
||||
- name: Platform/Data
|
||||
type: platform
|
||||
api: 'event bus, data warehouse'
|
||||
|
||||
- name: ML/Recommendation
|
||||
type: complicated_subsystem
|
||||
consumed_by: [Search]
|
||||
|
||||
- name: SRE Enablement
|
||||
type: enabling
|
||||
works_with: [Checkout, Search] # 매 transfer SRE practice
|
||||
duration: 'temporary, 6-12 months'
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Cognitive load survey (DX)
|
||||
```python
|
||||
def dx_survey(team):
|
||||
questions = [
|
||||
('How easy is it to onboard new engineers?', 1, 5),
|
||||
('How easy to find an answer to a code question?', 1, 5),
|
||||
('How fast can you ship a small change end-to-end?', 1, 5),
|
||||
('How confident are you the change won't break unrelated parts?', 1, 5),
|
||||
('How clear are your team's responsibilities?', 1, 5),
|
||||
]
|
||||
|
||||
responses = collect_anonymous(team, questions)
|
||||
return {
|
||||
'avg_score': np.mean([r['score'] for r in responses]),
|
||||
'low_scores': [q for q, r in responses if r < 3], # 매 priority
|
||||
}
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Inverse Conway Maneuver
|
||||
```python
|
||||
def design_org_for_architecture(target_architecture):
|
||||
"""매 architecture → 매 team structure."""
|
||||
team_structure = []
|
||||
for service in target_architecture.services:
|
||||
if service.tier == 'product':
|
||||
team_structure.append({
|
||||
'name': f'{service.name} Team',
|
||||
'type': 'stream-aligned',
|
||||
'owns': service.bounded_context,
|
||||
})
|
||||
elif service.tier == 'platform':
|
||||
team_structure.append({
|
||||
'name': f'Platform/{service.name}',
|
||||
'type': 'platform',
|
||||
'sla': service.sla,
|
||||
})
|
||||
|
||||
# 매 communication path 의 explicit
|
||||
for service_a, service_b in target_architecture.dependencies:
|
||||
team_a = find_team(team_structure, service_a)
|
||||
team_b = find_team(team_structure, service_b)
|
||||
team_a['interacts_with'] = team_a.get('interacts_with', []) + [{
|
||||
'team': team_b['name'],
|
||||
'type': 'x-as-a-service',
|
||||
}]
|
||||
|
||||
return team_structure
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Cognitive load reduction (platform pattern)
|
||||
```ts
|
||||
// 매 BEFORE: 매 team 의 매 service 의 모두 의 manage
|
||||
class CheckoutTeamConcerns {
|
||||
// - DB connection pool config
|
||||
// - Kafka producer config
|
||||
// - Auth token refresh
|
||||
// - Logging / tracing setup
|
||||
// - Metric / alert setup
|
||||
// - K8s deployment YAML
|
||||
// - Secret rotation
|
||||
// - DR / backup
|
||||
// - ... + 매 actual checkout logic.
|
||||
}
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
// 매 AFTER: 매 platform 의 abstraction
|
||||
import { platform } from '@company/platform';
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
class Checkout {
|
||||
constructor(
|
||||
private auth = platform.auth,
|
||||
private db = platform.db.transactional,
|
||||
private events = platform.eventBus,
|
||||
) {}
|
||||
|
||||
async checkout(cart) {
|
||||
// 매 only domain logic.
|
||||
const user = await this.auth.requireUser();
|
||||
const order = await this.db.transaction(async (tx) => {
|
||||
const o = await tx.orders.create({ user, cart });
|
||||
await tx.payments.charge(o);
|
||||
return o;
|
||||
});
|
||||
await this.events.emit('order.created', order);
|
||||
return order;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Documentation as load reduction
|
||||
```markdown
|
||||
# Service: Checkout
|
||||
|
||||
## Why
|
||||
[1 sentence]
|
||||
|
||||
## Architecture (C4 container level)
|
||||
[diagram or link]
|
||||
|
||||
## How to run locally (5 min)
|
||||
1. ...
|
||||
2. ...
|
||||
|
||||
## Common questions
|
||||
- Where is auth handled? → see Platform/Auth.
|
||||
- How do I add a new payment method? → see ADR-0042.
|
||||
|
||||
## Who to ask
|
||||
- General: @checkout-team
|
||||
- Auth: @platform-auth
|
||||
- DB: @platform-data
|
||||
```
|
||||
|
||||
### Bounded context boundary check
|
||||
```python
|
||||
def check_team_alignment(team, services):
|
||||
"""매 team 의 own 의 service 가 매 single bounded context?"""
|
||||
contexts = set(s.bounded_context for s in services if s.team == team.name)
|
||||
|
||||
if len(contexts) > 2:
|
||||
return f'WARN: team {team.name} owns {len(contexts)} contexts — split risk'
|
||||
if len(contexts) == 0:
|
||||
return f'WARN: team {team.name} has no clear ownership'
|
||||
return 'OK'
|
||||
```
|
||||
|
||||
### Stream-aligned vs Platform decision
|
||||
```python
|
||||
def classify_capability(capability):
|
||||
"""매 stream vs platform 의 결정."""
|
||||
if capability.directly_user_facing and capability.differentiator:
|
||||
return 'stream-aligned' # 매 own
|
||||
if capability.commodity and capability.consumed_by_many:
|
||||
return 'platform' # 매 build platform OR 매 buy
|
||||
if capability.specialist_skill_required:
|
||||
return 'complicated-subsystem'
|
||||
return 'enabling-or-rotate'
|
||||
```
|
||||
|
||||
## 🤔 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| New product team | Stream-aligned + clear domain |
|
||||
| Common infra | Platform team |
|
||||
| Specialist (ML) | Complicated subsystem |
|
||||
| Skill transfer | Enabling team (temporary) |
|
||||
| Microservice mess | Modular monolith first |
|
||||
| High cognitive load | Platform abstraction |
|
||||
| Onboarding slow | Doc + golden path |
|
||||
|
||||
**기본값**: Inverse Conway + 매 team-topology-aware design + 매 platform 의 reduce 매 load.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software-Architecture]] · [[Team-Design]] · [[Organization-Design]]
|
||||
- 변형: [[Conway-Law]] · [[Team-Topologies]] · [[Inverse-Conway]] · [[Cognitive-Load-Theory]]
|
||||
- 응용: [[Bounded-Contexts]] · [[Microservices]] · [[Platform-Engineering]] · [[DevEx]]
|
||||
- Adjacent: [[Architecture-Styles]] · [[Architecture-Anti-Patterns]] · [[Bottlenecks]] · [[Asset-Specific-Knowledge]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 org redesign. 매 team boundary. 매 platform strategy. 매 onboarding optimization.
|
||||
**언제 X**: 매 single team / single product. 매 < 5 person.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Architecture without team thought**: 매 Conway 의 violate.
|
||||
- **Matrix team (no clear owner)**: 매 ambiguity.
|
||||
- **God team**: 매 cognitive load 폭발.
|
||||
- **Platform 의 ivory tower**: 매 stream 의 ignore.
|
||||
- **Microservices first (small team)**: 매 mismatch.
|
||||
- **No doc**: 매 extraneous load.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Conway 1967, Skelton-Pais 2019, Sweller cognitive load).
|
||||
- 신뢰도 A.
|
||||
- Related: [[Architecture-Styles]] · [[Bounded-Contexts]] · [[Architecture-Anti-Patterns]] · [[Codebase_Onboarding_Guide]] · [[Asset-Specific-Knowledge]].
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Conway + Team Topologies + cognitive load + 매 platform abstraction code |
|
||||
|
||||
Reference in New Issue
Block a user