Files
2nd/10_Wiki/Topic_Programming/AI_and_ML/Theory of Constraints (TOC).md
T
Antigravity Agent 9148c358d0 docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
2026-07-05 00:33:48 +09:00

5.8 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-theory-of-constraints-toc Theory of Constraints (TOC) 10_Wiki/Topics verified self
TOC
Bottleneck Theory
Goldratt
none A 0.9 applied
management
optimization
systems-thinking
ops
2026-05-10 pending
language framework
N/A TOC methodology

Theory of Constraints (TOC)

매 한 줄

"매 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.

매 핵심

매 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.

매 핵심 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.

매 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.

매 응용

  1. Factory floor scheduling (DBR — Drum-Buffer-Rope).
  2. Software delivery (CI bottleneck, code review queue).
  3. ML inference cost (which stage 매 dominant?).

💻 패턴

매 inference pipeline profiling

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

# 매 result: {"tokenize": 0.001, "embed": 0.04, "vector_search": 0.32, "rerank": 0.18}
# 매 bottleneck: vector_search → 매 elevate (HNSW tune, GPU index, shard).

매 LLM agent: serialize → parallelize

# 매 BEFORE (serial — bottleneck = sum)
ctx = await fetch_user(uid)
weather = await get_weather(ctx.city)
calendar = await fetch_calendar(uid)

# 매 AFTER (parallel — bottleneck = max)
ctx, weather, calendar = await asyncio.gather(
    fetch_user(uid), get_weather_for_user(uid), fetch_calendar(uid),
)

매 DBR (Drum-Buffer-Rope) for queue

# 매 Drum: bottleneck stage paces the system
# 매 Buffer: small queue before bottleneck (의 starvation 방지)
# 매 Rope: feedback to release new work only when buffer drains

import asyncio
buffer = asyncio.Queue(maxsize=8)  # 매 Buffer

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)

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)

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

🤖 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