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

---
id: defensive-copying
title: 방어적 복사 (Defensive Copying)
category: Coding
status: draft
canonical_id: defensive-copying
aliases: [defensive copy, immutable input, cloning, structuredClone, 방어적 복사]
duplicate_of: null
source_trust_level: B
confidence_score: 0.85
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
last_reinforced: 2026-05-09
review_reason: ""
merge_history: []
tags: [coding, immutability, references, mutation, vibe-coding]
raw_sources: ["P-Reinforce session 2026-05-09 — bulk Coding seed batch 1"]
tech_stack:
  language: "TypeScript / JavaScript / Java / Python"
  applicable_to: ["모든 도메인"]
applied_in: []
---

# 방어적 복사 (Defensive Copying)

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

## 📖 핵심 개념

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

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

## 💻 코드 패턴

### 나쁜 예 — 외부 mutation 누수

```ts
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
```

### 방어적 복사 적용

```ts
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)

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

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

### Java — Collections.unmodifiableList

```java
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]]