[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,71 +2,160 @@
|
||||
id: wiki-2026-0508-theory-of-constraints-toc
|
||||
title: Theory of Constraints (TOC)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-TOCL-001]
|
||||
aliases: [TOC, Bottleneck Theory, Goldratt]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, theory-of-constraints, bottleneck, Optimization, Efficiency, project-Management]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [management, optimization, systems-thinking, ops]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: N/A
|
||||
framework: TOC methodology
|
||||
---
|
||||
|
||||
# [[Theory of Constraints (TOC)|Theory of Constraints (TOC)]]
|
||||
# Theory of Constraints (TOC)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "사슬의 강도는 가장 약한 고리가 결정한다: 시스템 전체의 성능을 갉아먹는 단 하나의 '병목(Bottleneck)'을 찾아내어 이를 집중 타격함으로써, 최소 비용으로 최대 효과를 거두는 전략적 최적화 이론."
|
||||
## 매 한 줄
|
||||
> **"매 system throughput 매 single bottleneck 의 결정"**. Goldratt 의 1984 *The Goal* 에서 정립. 매 system 의 weakest link (constraint) 가 전체 throughput 의 제한 → 매 다른 모든 부분의 optimization 매 wasted. 매 manufacturing 에서 시작, 매 software (DevOps, ML pipeline, LLM agent throughput) 까지 broad applicable.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
제약 이론(Theory of Constraints, TOC)은 엘리 골드렛(Eliyahu Goldratt)이 제안한 경영 철학으로, 어떤 목표를 달성하는 데 있어 극소수의 제약 요인이 전체 시스템의 출력을 결정한다는 원리입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **5단계 집중 프로세스 (POOGI)**:
|
||||
1. **Identify**: 시스템의 제약 요인(병목)을 찾아낸다.
|
||||
2. **Exploit**: 현재 자원 내에서 제약 요인이 낭비 없이 굴러가도록 최선을 다한다.
|
||||
3. **Subordinate**: 병목의 속도에 맞춰 다른 모든 공정의 속도를 조절한다 (전체 최적화).
|
||||
4. **Elevate**: 병목의 처리 용량 자체를 물리적으로 늘린다 (투자).
|
||||
5. **Repeat**: 제약이 해결되면 다음으로 이동한다. 절대로 타성에 젖지 마라.
|
||||
2. **핵심 개념 - 드럼-버퍼-로프 (DBR)**:
|
||||
* **Drum (병목)**: 전체 시스템의 박자를 결정.
|
||||
* **Buffer**: 병목이 쉬지 않게 앞에 두는 재고/시간 여유.
|
||||
* **Rope**: 병목의 속도 이상으로 앞 공정이 과잉 생산하지 못하게 묶어주는 신호 체계.
|
||||
3. **전환 포인트**:
|
||||
* 부분 최적화(개별 팀의 효율 증대)가 전체 시스템의 비효율(재고 누적)을 초래할 수 있음을 경고함.
|
||||
### 매 5-step focusing process
|
||||
1. **Identify** the constraint.
|
||||
2. **Exploit** it (maximize utilization without extra investment).
|
||||
3. **Subordinate** everything else to the constraint.
|
||||
4. **Elevate** the constraint (invest to expand capacity).
|
||||
5. **Repeat** — 매 constraint 매 moves elsewhere.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 제조 정책은 '모든 공정의 풀 가동'을 미덕으로 보았으나, TOC 정책은 '병목이 아닌 곳에서의 유휴 시간(Idle time)'을 시스템 전체의 안정을 위한 필수 여유로 인정함(RL Update).
|
||||
- **정책 변화(RL Update)**: 현대의 소프트웨어 개발 정책(DevOps)에서 TOC는 배포 파이프라인의 병목을 찾는 도구로 쓰이며, '지속적 개선' 정책의 일환으로 모든 개발 프로세스의 리드 타임(Lead Time)을 병목 기준으로 재배치하는 정책이 대중화됨.
|
||||
### 매 핵심 metrics (Throughput Accounting)
|
||||
- **Throughput (T)** — 매 sales rate of new revenue.
|
||||
- **Inventory / Investment (I)** — 매 money tied in the system.
|
||||
- **Operating Expense (OE)** — 매 money spent to convert I → T.
|
||||
- 매 priority: maximize T, minimize I, control OE.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Operations-Research|Operations-Research]], [[Systems Thinking|Systems Thinking]], [[Resource-Management|Resource-Management]], [[Standardization vs Innovation|Standardization vs Innovation]], Performance Managementsystems
|
||||
- **Modern Tech/Tools**: Kanban, Critical Chain Project Management (CCPM), Value Stream Mapping.
|
||||
---
|
||||
### 매 modern applications (2026)
|
||||
- **DevOps** — 매 *The Phoenix Project* (Kim 2013) 매 TOC + Lean 매 IT ops 에 적용.
|
||||
- **ML pipeline** — 매 GPU bottleneck (training), tokenizer (inference batch), vector store (RAG retrieval).
|
||||
- **LLM agent** — 매 sequential tool call 의 dominant latency contributor 의 identify → parallel.
|
||||
- **Org / Team** — 매 single approval bottleneck → workflow change.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Factory floor scheduling (DBR — Drum-Buffer-Rope).
|
||||
2. Software delivery (CI bottleneck, code review queue).
|
||||
3. ML inference cost (which stage 매 dominant?).
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 매 inference pipeline profiling
|
||||
```python
|
||||
import time
|
||||
def profile_pipeline(stages, inp):
|
||||
timings = {}
|
||||
out = inp
|
||||
for name, fn in stages:
|
||||
t0 = time.perf_counter()
|
||||
out = fn(out)
|
||||
timings[name] = time.perf_counter() - t0
|
||||
bottleneck = max(timings, key=timings.get)
|
||||
return out, timings, bottleneck
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
# 매 result: {"tokenize": 0.001, "embed": 0.04, "vector_search": 0.32, "rerank": 0.18}
|
||||
# 매 bottleneck: vector_search → 매 elevate (HNSW tune, GPU index, shard).
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### 매 LLM agent: serialize → parallelize
|
||||
```python
|
||||
# 매 BEFORE (serial — bottleneck = sum)
|
||||
ctx = await fetch_user(uid)
|
||||
weather = await get_weather(ctx.city)
|
||||
calendar = await fetch_calendar(uid)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
# 매 AFTER (parallel — bottleneck = max)
|
||||
ctx, weather, calendar = await asyncio.gather(
|
||||
fetch_user(uid), get_weather_for_user(uid), fetch_calendar(uid),
|
||||
)
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### 매 DBR (Drum-Buffer-Rope) for queue
|
||||
```python
|
||||
# 매 Drum: bottleneck stage paces the system
|
||||
# 매 Buffer: small queue before bottleneck (의 starvation 방지)
|
||||
# 매 Rope: feedback to release new work only when buffer drains
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
import asyncio
|
||||
buffer = asyncio.Queue(maxsize=8) # 매 Buffer
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
async def producer():
|
||||
while True:
|
||||
item = next_work()
|
||||
await buffer.put(item) # 매 Rope (blocks when full)
|
||||
|
||||
async def bottleneck_consumer(): # 매 Drum
|
||||
while True:
|
||||
item = await buffer.get()
|
||||
await expensive_step(item)
|
||||
```
|
||||
|
||||
### 매 throughput accounting (simple)
|
||||
```python
|
||||
def evaluate_change(before, after):
|
||||
delta_T = after["throughput"] - before["throughput"]
|
||||
delta_I = after["inventory"] - before["inventory"]
|
||||
delta_OE = after["op_expense"] - before["op_expense"]
|
||||
net = delta_T - delta_OE
|
||||
return {"net_value": net, "OK": net > 0 and delta_I <= 0}
|
||||
```
|
||||
|
||||
### 매 5-step driver (pseudocode)
|
||||
```python
|
||||
def toc_loop(system, n_iterations=5):
|
||||
for _ in range(n_iterations):
|
||||
c = identify_constraint(system) # 1
|
||||
exploit(c) # 2
|
||||
subordinate_others_to(c, system) # 3
|
||||
if not enough_capacity(c, target=system.target):
|
||||
elevate(c) # 4
|
||||
# 5: repeat — 매 constraint 매 shift
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Multi-stage pipeline | Profile → identify slowest → optimize that |
|
||||
| LLM agent latency | Parallel tool calls + cache hot path |
|
||||
| Batch ML training | GPU util check (nvidia-smi) — 매 if low, IO bottleneck |
|
||||
| Software delivery | Value stream map → find single bottleneck |
|
||||
| Cost optimization | Throughput accounting (T - OE), not unit cost |
|
||||
|
||||
**기본값**: 매 measure 먼저, 매 single biggest bottleneck 의 fix, 매 repeat — 매 premature optimization 의 X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Systems-Thinking]] · [[Operations-Management]]
|
||||
- 변형: [[Lean]] · [[Six-Sigma]] · [[DevOps]]
|
||||
- 응용: [[ML-Pipeline-Optimization]] · [[Agent-Latency]] · [[Software-Delivery]]
|
||||
- Adjacent: [[Queue-Theory]] · [[Little-Law]] · [[Amdahl-Law]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 multi-stage pipeline 의 latency / cost 의 분석, ML / agent system optimization, team workflow bottleneck.
|
||||
**언제 X**: 매 single-step task — 매 TOC framing 매 overhead.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Local optimization**: 매 non-bottleneck 의 optimize 매 system throughput 의 0% 변화.
|
||||
- **Multiple "bottlenecks"**: 매 일반적으로 single dominant — 매 measure 안 하고 guess 매 wrong.
|
||||
- **Ignoring the shift**: 매 bottleneck fix 후 다른 stage 가 새 constraint — 매 repeat 안 하면 stuck.
|
||||
- **Capacity addition without exploit**: 매 step 4 (elevate) 의 step 2 (exploit) 전에 — 매 expensive 하게 hardware buy 후 underutilized.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Goldratt 1984 *The Goal*, Kim *Phoenix Project* 2013, *Beyond the Phoenix Project* 2018).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — TOC + DevOps/ML pipeline modern application |
|
||||
|
||||
Reference in New Issue
Block a user