Files

T

Antigravity Agent f8b21af4be Wiki cleanup: error-doc removal, dedup merge, link normalization

10_Wiki/Topics 대규모 정리:
- 오류 캡처/미완성 stub 문서 227개 제거
- 교차폴더 중복 43클러스터 병합 (63파일 → redirect)
- 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건
- 카테고리 MOC 6개 신규 생성
- Graph 섹션 미해결 related-keyword 링크 10,058건 제거

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-20 23:52:15 +09:00

6.2 KiB

Raw Blame History

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

title

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.

매 종류

Interface seam — 매 abstraction 의 swap.
Event hook — 매 publish / subscribe.
Feature flag — 매 runtime toggle.
Plugin point — 매 third-party extension.
Schema evolution slot — 매 versioning / optional field.
Configuration point — 매 env / DI binding.

매 응용

Strangler fig migration — 매 facade 의 enabling point.
Plugin systems (VSCode, Obsidian, Backstage).
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
응용: 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

6.2 KiB Raw Blame History