2nd/10_Wiki/Topics/Architecture/Enabling Point (활성화 지점).md

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-enabling-point-활성화-지점	Enabling Point (활성화 지점)	10_Wiki/Topics	verified	self	Activation Point Enabling Constraint Trigger Point	none	B	0.8	applied	architecture design leverage-point evolutionary-architecture		2026-05-10	pending	language framework methodology 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)

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

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)

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

// 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

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

// 매 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)

// 매 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 · Evolutionary Architecture
• 변형: Leverage Point (Meadows) · Seam (Working Effectively with Legacy Code)
• 응용: Strangler Fig Pattern · Plugin Architecture · Feature Flags
• Adjacent: Hexagonal Architecture · Fitness Function · 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