ARC를 심도 있게 설명하세요: weak vs unowned, 그리고 누수 감지 방법.

Question

IT Interview Practice · Accepted Answer

**ARC(Automatic Reference Counting)**는 컴파일 시점에 강한 참조를 추적하여 클래스 인스턴스의 메모리를 관리합니다. 컴파일러가 `retain`/`release` 호출을 삽입하고, 객체의 강한 카운트가 0에 도달하면 즉시 — 백그라운드 가비지 컬렉터가 아니라 결정론적으로 — 해제됩니다.

## 참조가 카운트에 미치는 영향

- **strong** (기본값) — 카운트를 증가시키고 객체를 살려 둡니다.
- **weak** — 카운트를 증가시키지 *않으며*, 해제 시 자동으로 `nil`로 설정됩니다. `var`이고 옵셔널이어야 합니다.
- **unowned** — 카운트를 증가시키지 *않으며*, 항상 유효하다고 가정합니다. 해제 후 접근하면 크래시(또는 `unowned(unsafe)`의 경우 더 나쁜 정의되지 않은 동작)가 발생합니다.

```swift
final class Customer {
    var card: Card?                 // strong: customer가 card를 소유
}
final class Card {
    unowned let owner: Customer     // unowned: card는 owner보다 오래 살지 않음
    init(owner: Customer) { self.owner = owner }
}
```

## weak vs unowned — 선택 기준

습관이 아니라 **수명 관계**로 선택하세요:

| | weak | unowned |
|--|------|---------|
| 옵셔널 | 예 (nil이 됨) | 아니오 |
| ARC 비용 | 약간 높음 (추적됨) | 낮음 |
| 다른 객체가 사라져도 안전 | 예 | **크래시** |
| 사용 시점 | 참조가 정당하게 nil이 *될 수 있을* 때 (delegate, 먼저 해제될 수 있는 부모) | 참조가 self보다 오래 산다고 보장될 때 (자식 → 필수 부모) |

## 누수 감지

1. **Xcode Memory Graph Debugger** — 일시 정지하고 사라졌어야 할 객체를 찾습니다. 보라색 `!` 마커가 순환을 표시합니다.
2. **Instruments → Leaks / Allocations** — 어떤 흐름을 반복할 때 메모리가 단조 증가하는지 관찰합니다.
3. **`deinit` 로깅** — 가장 빠른 온전성 검사입니다. 화면이 닫힐 때 `deinit`이 출력되지 않으면 그 객체가 누수된 것입니다.

```swift
deinit { print("released \(Self.self)") }  // 닫을 때 조용하면 누수
```

## 흔한 누수 원인

`self`를 캡처하는 탈출 클로저, 양방향 부모/자식 강한 참조, 타깃을 유지하는 `Timer`/`DispatchSourceTimer`, 해제되는 cancellable에 저장되지 않은 Combine 구독 등입니다.

## 왜 중요한가

ARC는 결정론적이므로 누수는 GC가 아니라 여러분의 책임입니다. 유지된 뷰 컨트롤러 하나가 수 메가바이트의 이미지와 전체 객체 그래프를 붙잡을 수 있습니다. 시니어 면접이 이를 파고드는 이유는, weak vs unowned를 올바르게 선택하고 메모리 그래프로 누수를 *증명*하는 방법을 아는 것이 장기 실행 앱이 부풀어 오르지 않게 하는 요소이기 때문입니다.

	weak	unowned
옵셔널	예 (nil이 됨)	아니오
ARC 비용	약간 높음 (추적됨)	낮음
다른 객체가 사라져도 안전	예	크래시
사용 시점	참조가 정당하게 nil이 될 수 있을 때 (delegate, 먼저 해제될 수 있는 부모)	참조가 self보다 오래 산다고 보장될 때 (자식 → 필수 부모)

참조가 카운트에 미치는 영향

weak vs unowned — 선택 기준

누수 감지

흔한 누수 원인

왜 중요한가

관련 질문