Files
2nd/10_Wiki/Topics/Coding/Defensive_Copying.md
T
2026-05-09 21:08:02 +09:00

4.9 KiB

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 추가.

🔗 관련 문서