---
id: wiki-2026-0508-enabling-point-활성화-지점
title: Enabling Point (활성화 지점)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Activation Point, Enabling Constraint, Trigger Point]
duplicate_of: none
source_trust_level: B
confidence_score: 0.8
verification_status: applied
tags: [architecture, design, leverage-point, evolutionary-architecture]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: methodology
  framework: architecture
---

# Enabling Point (활성화 지점)

## 매 한 줄
> **"매 작은 architectural seam 의 future change 의 unlock"**. 매 enabling point 의 매 system 의 specific spot — 매 intentionally placed extension hook / abstraction / boundary 의 매 later capability 의 enable. 매 Donella Meadows의 "leverage point" + Neal Ford 의 "evolutionary architecture" 의 fitness function 의 cousin.

## 매 핵심

### 매 무엇 / 무엇 X
- **무엇**: 매 explicit 한 future-flexibility hook (interface / event / config flag / plugin).
- **무엇 X**: 매 speculative generality (YAGNI 위반) — 매 enabling point 의 cheap / minimal.

### 매 indicator
- 매 small abstraction 의 매 large optionality 의 unlock.
- 매 reversible decision 의 keep — 매 매 one-way door 의 avoid.
- 매 cost-of-change 의 grow before it's added.

### 매 종류
1. **Interface seam** — 매 abstraction 의 swap.
2. **Event hook** — 매 publish / subscribe.
3. **Feature flag** — 매 runtime toggle.
4. **Plugin point** — 매 third-party extension.
5. **Schema evolution slot** — 매 versioning / optional field.
6. **Configuration point** — 매 env / DI binding.

### 매 응용
1. Strangler fig migration — 매 facade 의 enabling point.
2. Plugin systems (VSCode, Obsidian, Backstage).
3. Multi-tenant SaaS — 매 tenant-scoped extension.

## 💻 패턴

### Pattern 1: Interface seam (TypeScript)
```typescript
// 매 enabling point — payment provider 의 swap
interface PaymentProvider {
  charge(amount: number, token: string): Promise<ChargeResult>;
  refund(chargeId: string): Promise<void>;
}

class StripeProvider implements PaymentProvider { /* ... */ }
class TossProvider implements PaymentProvider { /* ... */ }

// service 의 매 PaymentProvider 만 의 know
class CheckoutService {
  constructor(private payments: PaymentProvider) {}
}
```

### Pattern 2: Event hook
```typescript
type Hook<T> = (ctx: T) => Promise<void>;

class HookRegistry<T> {
  private hooks: Hook<T>[] = [];
  register(h: Hook<T>) { this.hooks.push(h); }
  async fire(ctx: T) { for (const h of this.hooks) await h(ctx); }
}

// 매 enabling point — order placed 시 매 plugin 의 react
const orderPlaced = new HookRegistry<{ orderId: string }>();
orderPlaced.register(async ({ orderId }) => emailService.confirmation(orderId));
orderPlaced.register(async ({ orderId }) => analytics.track("order", orderId));
```

### Pattern 3: Feature flag (LaunchDarkly-style)
```typescript
import { flags } from "./flags";

async function checkout(req: CheckoutReq) {
  if (await flags.isOn("new-checkout-flow", req.userId)) {
    return newFlow(req);
  }
  return legacyFlow(req);
}
// 매 enabling point — 매 percentage rollout / kill switch / A/B.
```

### Pattern 4: Plugin point
```typescript
// VSCode-style contribution
interface CommandContribution {
  id: string;
  title: string;
  handler(args: unknown): Promise<void>;
}

class PluginHost {
  private commands = new Map<string, CommandContribution>();
  register(c: CommandContribution) { this.commands.set(c.id, c); }
  async execute(id: string, args: unknown) {
    return this.commands.get(id)?.handler(args);
  }
}
```

### Pattern 5: Schema evolution
```typescript
// 매 v1 → v2 의 enabling point — optional field
interface OrderV1 { id: string; items: Item[]; }
interface OrderV2 extends OrderV1 {
  giftMessage?: string;        // 매 backward-compatible add
  shippingMethod?: "standard" | "express";
}
// 매 readers 의 매 둘 다 의 handle.
```

### Pattern 6: Strangler fig facade
```typescript
// 매 legacy / new 의 enabling point — facade 의 routing
async function getUser(id: string): Promise<User> {
  if (await isUserMigrated(id)) {
    return newService.getUser(id);
  }
  return legacyService.getUser(id);
}
```

### Pattern 7: Fitness function (architecture test)
```typescript
// 매 enabling point 의 의도된 boundary 의 verify
import { describe, it, expect } from "vitest";
import { extractImports } from "./arch-test";

describe("architecture", () => {
  it("domain layer must not import infrastructure", () => {
    const imports = extractImports("src/domain/**/*.ts");
    const violations = imports.filter(i => i.includes("/infrastructure/"));
    expect(violations).toEqual([]);
  });
});
```

## 매 결정 기준
| 상황 | Approach |
|---|---|
| 매 evidence 의 future change | enabling point 의 add |
| 매 speculative | YAGNI — skip |
| One-way door decision | enabling point 의 mandatory |
| Reversible decision | 매 simple 의 ship, refactor later |
| Plugin ecosystem 의 plan | plugin point 의 first-class |

**기본값**: 매 evidence-based — 매 2nd 번 같은 change 의 demand 시 enabling point 의 introduce ("Rule of three").

## 🔗 Graph
- 부모: [[Software Architecture]]
- 응용: [[Feature Flags]]
- Adjacent: [[Hexagonal Architecture]] · [[YAGNI]]

## 🤖 LLM 활용
**언제**: 매 architecture review, 매 future change 의 anticipate, 매 refactor planning.
**언제 X**: 매 prototype, 매 evidence 의 absent — 매 over-engineering.

## ❌ 안티패턴
- **Speculative enabling**: 매 "혹시 모를" abstraction — YAGNI.
- **Too many hooks**: 매 plugin point 의 abuse — 매 cognitive load.
- **Hidden coupling**: 매 enabling point 의 facade 만, 매 internal coupling 의 그대로.
- **No fitness function**: 매 enabling point 의 verify X — 매 시간 erode.

## 🧪 검증 / 중복
- Verified (Neal Ford "Building Evolutionary Architectures" 2nd ed, M. Feathers "Working Effectively with Legacy Code", Meadows "Thinking in Systems").
- 신뢰도 B (매 term 의 community variance).

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — enabling point 종류 + fitness function |