2nd/10_Wiki/Topic_Programming/Coding/Defensive_Copying.md

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

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
defensive-copying	방어적 복사 (Defensive Copying)	Coding	draft	defensive-copying	defensive copy immutable input cloning structuredClone 방어적 복사	null	B	0.85	conceptual	2026-05-09	2026-05-09	2026-05-09			coding immutability references mutation vibe-coding	P-Reinforce session 2026-05-09 — bulk Coding seed batch 1	language applicable_to TypeScript / JavaScript / Java / Python 모든 도메인

방어적 복사 (Defensive Copying)

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

📖 핵심 개념

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

해결: 두 경계에서 복사:

1. 들어오는 경계: 생성자/setter 가 받은 객체를 deep copy 해서 보관
2. 나가는 경계: 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 추가.

🔗 관련 문서

• Pure_Functions_in_Practice
• Tagged_Union_Discriminated_Types