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

4.9 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, created_at, updated_at, last_reinforced, review_reason, merge_history, tags, raw_sources, tech_stack, applied_in

title

방어적 복사 (Defensive Copying)

외부에서 받은 객체를 그대로 보관하지 마라. 호출자가 나중에 그 객체를 수정하면 너의 내부 상태가 같이 바뀐다. 경계에서 복사, 내부에서 불변.

📖 핵심 개념

레퍼런스 시멘틱(JS/TS, Python, Java) 언어에서는 객체를 메서드 인자로 받으면 호출자와 같은 인스턴스를 가리킨다. 호출자가 후속 코드에서 그 객체를 수정하면 우리 객체도 바뀐다. 반대로 우리가 객체 필드를 노출하면 외부가 우리 내부 상태를 바꿀 수 있다.

해결: 두 경계에서 복사:

들어오는 경계: 생성자/setter 가 받은 객체를 deep copy 해서 보관
나가는 경계: getter가 내부 객체를 그대로 반환하지 말고 deep copy 또는 readonly 뷰 반환

💻 코드 패턴

나쁜 예 — 외부 mutation 누수

class Order {
  constructor(public items: Item[]) {} // 그대로 보관
  getItems() { return this.items; }    // 그대로 노출
}

const items = [{ id: 1, qty: 2 }];
const order = new Order(items);

items.push({ id: 99, qty: 999 });        // ⚠️ order 내부도 바뀜
order.getItems().pop();                   // ⚠️ 외부에서 내부 mutation

방어적 복사 적용

class Order {
  private readonly items: ReadonlyArray<Item>;

  constructor(items: Item[]) {
    // 들어오는 경계 — deep copy
    this.items = items.map(i => ({ ...i }));
    // 또는 structuredClone(items)
    Object.freeze(this.items as unknown as object);
  }

  getItems(): ReadonlyArray<Item> {
    // 나가는 경계 — readonly view 또는 deep copy
    return this.items;
  }

  withItem(item: Item): Order {
    return new Order([...this.items, item]); // 새 인스턴스 반환
  }
}

structuredClone 활용 (모던 JS)

function safeStore(state: AppState) {
  this.state = structuredClone(state); // 깊은 복사, 함수/Map/Set 일부 지원
}

structuredClone은 함수, DOM 노드, 일부 클래스 인스턴스 못 복사. JSON-like 객체에 안전.

Java — Collections.unmodifiableList

public class Order {
  private final List<Item> items;
  public Order(List<Item> items) {
    this.items = new ArrayList<>(items); // 들어오는 경계 복사
  }
  public List<Item> getItems() {
    return Collections.unmodifiableList(items); // 나가는 경계 readonly
  }
}

🤔 의사결정 기준

상황	방어적 복사 필요	불필요
외부에서 받은 array / object 를 인스턴스 필드로 보관	✅	—
primitive (number, string)	❌	✅
`readonly` / `Object.freeze` 만으로 충분한가	shallow면 부족	depth 1 OK
Date / Map / Set 받음	✅ (mutation 가능)	—
성능이 극단적으로 중요한 핫패스	trade-off — readonly view + 문서화	—
함수형 라이브러리(Immutable.js) 사용	❌ (이미 immutable)	✅

❌ 안티패턴

얕은 복사로 끝: [...arr] 는 1단계만. 안의 객체는 여전히 공유. nested 가 있으면 deep copy 필수.
JSON.parse(JSON.stringify(x)) 를 모든 곳에 사용: Date → string, undefined 손실, function 손실, circular ref 폭사. 알고 쓰면 OK 하지만 default 도구로는 부적합.
getter 가 내부 reference 반환 후 "수정하지 마세요" 라고 주석: 컴파일러 강제 안 됨. 결국 누군가 mutate. readonly 타입 또는 deep copy.
모든 곳에 deep clone: 메모리 / GC 부담. 정말 외부 경계만.
immutable 라이브러리 + 일반 객체 혼용: 일관성 깨짐. 한 도메인은 한 스타일.

🤖 LLM 활용 힌트

LLM에게 클래스 작성: "들어오는 array/object 는 deep copy, 반환은 ReadonlyArray 또는 deep copy" 명시.
도메인 모델 작성: "immutable record. mutation 메서드는 새 인스턴스 반환 (withX())" 패턴 요청.
일반 함수 작성: "입력 파라미터를 mutate 하지 마라" 명시.

🧪 검증 상태

verification_status: conceptual
Effective Java Item 50, Domain-Driven Design 의 표준 권고.
적용 사례 발견 시 applied_in 추가.

4.9 KiB Raw Blame History