Strong Reference(강한 참조): 정의, 작동 메커니즘 및 ARC

Strong Reference란?

Strong Reference는 채집기나 메모리 관리 시스템에 의한 객체 파괴를 막는 참조 유형입니다. 객체에 대한 강한 참조가 하나라도 존재하는 한, 그 메모리는 해제되지 않습니다. 이것은 Swift와 Objective-C의 ARC, 그리고 Java와 Kotlin의 채집기의 기초가 되는 메커니즘입니다.

강한 참조의 개념은 자동 메모리 관리를 사용하는 모든 언어에 기본적입니다. ARC를 사용하는 시스템에서, 각 강한 참조는 객체의 참조 카운터를 증가시킵니다. 카운터가 0이 되면 객체가 즉시 해제됩니다. Java와 Kotlin에서 채집기를 사용하는 경우, 강한 참조는 객체가 접근 가능하며 GC에 의해 수집되지 않도록 보장합니다.

WWDC 2021에 따르면, iOS 애플리케이션의 메모리 비우 중 약 35%가 강한 참조의 잘못된 사용과 retain cycles에 관련되어 있습니다. Android 개발에서는 closures와 callbacks에서의 명시적인 강한 참조를 통한 비우가 Context Leak 다음으로 둘째로 흔한 메모리 문제 원인입니다.

메모리를 효과적으로 작업하려면 strong, weak 그리고 unowned 참조의 차이를 이해하고 소유권과 객체 수명에 따라 올바른 참조 유형을 선택해야 합니다.

ARC가 메모리 관리를 어떻게 바꿴었나요?

ARC 이전에는 개발자가 각 객체에 대해 수동으로 retain과 release를 호출해야 했으며, 이로 인해 많은 오류가 발생했습니다. Apple이 2011년 LLVM 3.0과 함께 도입한 ARC는 콤파일 시점에 소유 그래프를 분석하여 이 과정을 자동화했습니다. 콤파일러가 필요한 위치에 retain, release 그리고 autorelease 호출을 자동으로 삽입합니다.

Clang Static Analyzer에 따르면, ARC 도입으로 iOS 애플리케이션의 메모리 관련 버그가 70% 감소했습니다. 개발자에게 이는 메모리 관리가 더 안전해졌지만, 동시에 retain cycles을 피하기 위해 강한 참조갌 내부적으로 어떻게 작동하는지 이해할 필요가 생기었음을 의미합니다.

Kotlin과 Java에서는 채집기가 ARC의 역할을 하지만, 강한 참조의 원칙은 같습니다: GC Roots는 객체가 강한 참조에 의해 유지되는 입구 짐입니다. 객체가 GC Root로부터 강한 참조 체인을 통해 접근 가능한 한, 그것은 수집되지 않습니다.

ARC에서 Strong Reference는 어떻게 작동하나요?

ARC(Automatic Reference Counting)는 힙의 각 객체에 대한 참조를 계산하여 작동합니다. 객체에 대한 새로운 강한 참조가 생성되면 카운터가 증가합니다(retain). 참조가 파괴되거나 겹쳐 쓰이면 카운터가 감소합니다(release). 카운터가 0에 도달하면 객체가 메모리에서 즉시 제거됩니다.

Swift 예제를 고려해 봅시다. 클래스 인스턴스가 생성되면 ARC가 메모리를 할당하고 retain count를 1로 설정합니다. 다른 변수에 새로운 할당이 이루어질 때마다 카운터가 증가합니다. 변수가 스코프를 벗으면 카운터가 감소합니다:

class ProfileViewController {
    var nameLabel: String?
    var avatarImage: UIImage?

    func loadProfile() {
        // 새 인스턴스에 대한 retain count = 1
        let user = User(name: "Ivan")
        // nameLabel 할당 후 retain count = 2
        nameLabel = user.name
        // 메소드 종료 — user가 스코프를 벗음, retain count = 1
    }
}

이 코드에서 ARC는 User 객체에 강한 참조가 하나라도 존재하는 한 메모리에 남아 있도록 보장합니다. loadProfile 함수가 종료되면 로컬 변수 user는 파괴되지만 nameLabel이 여전히 객체를 유지합니다. nameLabel이 더 이상 존재하지 않거나 겹쳐 쓰일 때비로소 메모리가 해제됩니다.

Kotlin에서는 GC Roots를 통해 비슷한 동작이 제공됩니다. 채집기 루트(예: 정적 필드 또는 활성 스레드)로부터 강한 참조의 추적 가능한 체인이 존재하는 한 객체는 메모리에 남아 있습니다. 차이점은 GC가 즐각 메모리를 해제하지 않는다는 것입니다 — 접근 가능성 분석 후 비동기적으로 발생합니다.

메모리 해제가 일어나는 시점

ARC에서는 카운터가 0에 도달했을 때 동기적으로 해제가 일어납니다. Swift와 Objective-C에서는 객체가 제거되는 정확한 시점을 알 수 있습니다. Kotlin과 Java에서는 해제 시점이 예측할 수 없지만, 채집기 레벨에서 순환 의존성을 감지하는 더 유연한 스키머로 보상됩니다.

Retain Cycles와 메모리 비우

Retain cycle(유지 순환)은 두 개 이상의 객체가 서로에 대해 강한 참조를 가지는 상황입니다. 결과적으로 retain count가 0이 되지 않고, 객체가 애플리케이션에 더 이상 필요없다드도 메모리가 해제되지 않습니다.

고전적인 예: 부모 뷰 컨트롤러가 강한 참조로 자식 객체를 유지하고, 자식이 다시 강한 참조로 부모를 유지하는 경우입니다. 이는 데리게이트, closures 그리고 중첩 lambda 표현식이 있는 상황에서 일반적입니다. Instruments Leaks에 따르면, retain cycles은 ARC를 사용하는 애플리케이션에서 메모리 비우의 60%까지 차지합니다.

class ParentViewController: UIViewController {
    var child: ChildViewController?

    func setupChild() {
        child = ChildViewController()
        // retain cycle: 부모가 child를 유지, child가 closure를 통해 부모를 유지
        child?.onEvent = {
            self.handleEvent()
        }
    }

    func handleEvent() {}
}

여기서 문제는 onEvent closure가 강한 참조로 self(ParentViewController)를 캡처하고, ParentViewController 자체가 강한 참조로 child를 유지하는 것입니다. 두 객체 모두 해제되지 않습니다. 해결 방법은 closure에서 weak self를 사용하여 순환을 끔는 것입니다.

Kotlin에서는 외부 객체를 캡처하는 lambda를 사용할 때 비슷한 순환이 발생합니다. JVM 채집기가 시간이 지나면 이러한 순환을 감지할 수 있지만, 객체가 GC Roots에서 접근 불가능한 경우에만 가능합니다. 순환이 활성 스레드 또는 UI 컨텍스트에 결속된 경우 비우는 애플리케이션 수명 동안 지속됩니다.

Strong vs Weak vs Unowned Reference

참조 유형간의 차이를 이해하는 것은 안전한 메모리 관리의 열쇠입니다. Strong Reference는 retain count를 증가시킵니다. Weak Reference는 retain count를 증가시키지 않고 객체가 해제될 때 자동으로 nil이 됩니다. Unowned Reference도 retain count를 증가시키지 않지만 0이 되지 않습니다 — 해제 후 접근하면 비트발생합니다.

참조 유형의 선택은 소유 관계에 의해 결정됩니다. 객체 B가 A의 일부이고 그 없이 존재할 수 없는 경우 — Strong을 사용하세요. B가 독립적으로 존재할 수 있고 알림을 위해 A를 참조하는 경우 — Weak을 사용하세요. Unowned는 거의 사용되지 않습니다 — 자식 객체의 수명이 부모의 수명을 초과하지 않는 경우에만 사용됩니다.

실용적인 선택 규칙

Apple Developer Documentation에서 권장하는 바: 기본적으로 모든 소유 관계에 strong을 사용하세요. retain cycle을 피해야 하는 경우 — 어떤 참조가 약해야 하는지 확인하세요. 일반적으로 계층 구조에서 역 참조(자식 → 부모)가 이에 해당합니다. Kotlin에서는 java.lang.ref의 WeakReference가 비슷한 역할을 하며, 캐시와 observer 패턴에 사용됩니다.

강한 참조 문제 해결 방법

Retain cycles을 감지하는 것이 첫 번째 단계입니다. 둘 째는 그것들을 올바르게 제거하는 것입니다. 강한 참조 순환을 끔는 주요 도구는 참조 중 하나를 weak 또는 unowned로 대체하는 것입니다. 채집기가 있는 언어에서는 각 접근 전에 null 수동 확인이 필요한 WeakReference가 추가로 사용됩니다.

Swift와 Objective-C에서 가장 일반적인 수정 방법은 closures에 [weak self]를 추가하는 것입니다. 이로써 closure가 객체가 해제된 후에도 그것을 유지하지 않도록 보장합니다. Kotlin에서는 WeakReference 래퍼 또는 onDestroy에서의 명시적인 참조 정리가 비슷한 목적으로 사용됩니다.

class NetworkService {
    func fetchData(completion: @escaping (Data?) -> Void) {
        // weak self를 통한 캡처 — retain cycle 제거됨
        URLSession.shared.dataTask(
            with: URL(string: "https://api.example.com")!
        ) { [weak self] data, response, error in
            guard let self else { return }
            completion(data)
        }.resume()
    }
}

이 예제에서 [weak self]는 NetworkService가 더 이상 필요 없을 때 closure에 의해 유지되지 않도록 보장합니다. 요청이 완료되기 전에 self가 해제되면 — guard let self else { return }이 completion을 호출하지 않고 closure에서 나갑니다.

Retain cycles 진단에는 iOS용 Instruments Leaks 또는 Android용 Android Profiler + LeakCanary를 사용하세요. 이 도구들은 정확한 유지 그래프를 보여주고 어떤 강한 참조가 객체 해제를 막고 있는지 표시합니다. 정기적인 메모리 프로파일링은 모든 모바일 프로젝트의 CI/CD 파이프라인의 일부여야 합니다.

Swift와 Kotlin에서의 Strong Reference — 비교

Swift와 Kotlin은 근본적으로 다른 메모리 관리 메커니즘을 사용하지만, 강한 참조의 개념은 둘 모두에 존재합니다. Swift는 retain count = 0에서 동기적 해제가 있는 ARC를 사용합니다. Kotlin은 접근 불가능한 객체를 비동기적으로 청소하는 추적 GC를 사용합니다.

주요 실용적 차이점: Swift에서 retain cycle은 확실한 비우입니다. Kotlin에서는 객체가 루트에서 접근 불가능한 경우 GC가 순환을 끔을 수 있지만, 비우된 객체의 수명은 여전히 예측하기 어렵습니다. 따라서 두 언어 모두에서 가장 좋은 전략은 설계 단계에서 강한 참조 순환을 피하는 것입니다.

Swift에서는 데리게이트 패턴과 closures에서 weak을 사용하세요. Kotlin에서는 WeakReference 또는 소유자가 파괴될 때 자동으로 참조를 정리하는 Lifecycle-aware 컴포넌트를 사용하세요. 두 접근 방식 모두에서 목표는 같습니다 — 끊어지지 않는 유지 체인이 형성되는 강한 참조를 제거하는 것입니다.