[Swift-WWDC21] ARC in Swift: Basics and beyond

ARC in Swift: Basics and beyond

오늘은 WWDC21 세션 중에서 ARC에 대한 세션이 있길래 번역을 해보면서 ARC를 다시 정리해보려고 해요. 오역이나 의역이 있을 수 있으니 이 포스트가 애플과 스위프트팀의 공식적인 발표라고 생각하지 마시고 꼭 원본 영상을 보시면서 영어가 어려우신 부분에서 참고만 해주시면 될 것 같아요! 그럼 시작하겠습니다! 그나저나 요즘은 키노트를 안올려주나보네요ㅠ

ARC in Swift: Basics and beyond - WWDC21 - Videos - Apple Developer

Object Lifetimes and ARC

먼저 가볍게 스위프트에서 객체의 생명주기가 어떻게 되는지 정리해볼게요. 

 

객체는 생성자와 함께 시작되어서 사용이 완전히 완료되면 종료됩니다. 그리고 ARC는 이 생명주기가 끝나면 객체를 메모리에서 해제하는 역할을 담당하죠. ARC가 객체의 생명주기를 파악하는 방법이 Reference Count인데요, 스위프트 컴파일러는 객체가 시작될 때 retain 연산자를 코드에 삽입하고, 객체가 종료될 때 release 연산을 코드에 삽입합니다.

 

이렇게 해두면 스위프트 런타임은 어떤 객체의 Reference Count가 0이 되었을 때 객체를 메모리에서 해제합니다.

 

글로는 잘 와닿지 않죠? 리테인, 릴리즈, 컴파일러가 어쩌구.. 런타임이 어쩌구.. 

 

예시와 함께 살펴봅시다.

 

자, 여기에 Traveler 클래스와 이 클래스의 객체를 만들어 사용하는 test라는 함수가 있습니다.

 

test 함수 안에서는 traveler1 이라는 변수에 Traveler 객체의 인스턴스를 새로 만들어 할당하고, traveler2에 traveler1의 값을 복사합니다. 그리고 traveler2 변수가 가진 값에 접근해 destination 프로퍼티에 새로운 값을 할당해주고 있습니다.

 

그럼 여기서 생명주기가 어떻게 될까요? traveler1의 참조는 Traveler 인스턴스를 생성 했을 때 시작되고, traveler2 에 travler1을 복사한 뒤에 사용이 종료되어요.

 

참조를 해제하지 않았는데 왜 END 라고 표현하는지 헷갈리시죠? '사용'이라는 관점에서 보았을 때, travler1은 사용이 종료된거예요. 아까 객체의 생명주기에 대해 정리할 때 "사용이 완료되면 종료"라고 정의 했었어요 😎

 

 이제 컴파일러는 게으른 우리 대신에 사용이 완료된 traveler의 코드 아래에 release 코드를 추가해줍니다.

 

retain은 왜 없냐구요? 생성자는 reference count를 1로 설정하거든요. 그래서 컴파일러가 이 코드에서는 따로 retain을 넣어줄 필요가 없습니다.

 

다음은 이 코드에 하나 더 있는 객체인 traveler2 객체를 봅시다. 이번에는 생성자가 아니라 할당을 통해서 새로운 참조를 만들었죠? 이 순간에 참조가 시작되고, destination 프로퍼티를 업데이트하면 참조가 종료됩니다.

 

따라서 컴파일러는 이렇게 retain과 release 코드를 삽입하게 됩니다.

 

자 이제 컴파일러의 역할은 끝났습니다. 런타임으로 이동해서 어떤 일들이 일어나는지 봅시다.

 

Traveler 객체의 인스턴스가 생성되어서 힙에 저장되었고, 이와 함께 Reference count 가 1로 설정되었어요.

 

그리고 다음 라인에 있는 retain 코드를 실행하면, Reference count가 증가해 2가 되죠.

 

그리고 이제 traveler2도 Traveler 객체를 참조하게 됩니다.

 

이제 traveler1의 사용이 끝났습니다. 따라서 컴파일러가 넣어준 releasae 코드를 실행하고, reference count는 1로 줄어듭니다.

 

그 다음에는 destination 프로퍼티를 업데이트 하고,

 

이제 traveler2의 사용이 끝났네요. reference count를 하나 줄이게 됩니다.

 

Reference count가 0이 되었습니다! 그럼 이때는 인스턴스를 메모리에서 해제할 수 있게됩니다.

 

중요한 부분이라서 다시 설명해주시는 것 같아요! 스위프트의 객체 생명주기는 Use-based 입니다. 즉, 사용을 언제 시작하고 종료되는지에 따라서 retain과 release의 시점이 결정된다는 거예요. 이런 방식은 C++ 같은 다른 언어들과는 완전히 다른데요, 스위프트는 블록이 종료될 때 객체의 종료를 보장하게 됩니다.

 

스위프트는 retain과 release를 기준으로 객체를 해제하기 때문에 함수가 종료되지 않아도 객체가 해제될 수 있죠. 방금 예시에서 본 것 처럼요.

 

그리고 ARC 최적화에 따라서 위 방식이 아니라 마지막으로 사용되고 꽤 지난 이후에 객체가 해제될 수도 있어요. 

 

대부분의 경우에는 객체의 생명주기가 정확히 어떻게 되는지 중요하지는 않아요. 하지만 weak나 unowned를 사용하거나 deinitializer를 사용하면 문제가 생길 수 있어요. 저 친구들은 객체의 생명주기를 지켜보는 친구들이기 때문에 정확히 언제 해제되는지가 중요하니까요.

 

이렇게 객체의 생명주기의 의존적인 코드들은 버그가 일어날 가능성이 있어요. 지금 당장 잘 실행되더라도 그건 우연(Coincidence)이니까요. 만약 컴파일러가 변경되거나, 해당 코드와 관련이 없는 코드를 변경했을 때 오랜 시간동안 발견되지 않던 버그가 발견될 수도 있는거죠.

 

Observable object lifetimes

 이제 좀 더 딥하게 들어가볼게요. 객체의 생명주기를 관찰 가능하도록 만드는 요소들을 알아볼텐데요, 우리가 객체의 생명주기에 의존하면 어떤 일들이 일어나는지 알아보고, 문제가 생겼을 때 이를 해결할 수 있는 안전한 기법들도 소개할거예요.

 

먼저 weak과 unowned 부터 소개할게요. 약한 참조와 미소유 참조는 reference counting에 관여하지 않아요. 즉, reference count를 증가시키지 않는다는 것이죠. 그래서 이 친구들은 참조 사이클(reference cycle) 문제를 해결하기 위해서 흔하게 사용됩니다. 

 

더 자세하게 이야기 하기 전에, 참조 사이클이 무엇인지부터 짚자구요.

 

아까 만들었던 Traveler가 조금 더 확장되었어요. 이제 account라는 프로퍼티가 추가 되었고, account를 표현하기 위해서 Account 클래스도 만들어졌습니다. 그리고 이 둘은 서로를 프로퍼티로 가지고 있어요.

 

새로운 test 함수도 추가되었는데요, 여기서는 Traveler 인스턴스와 Account 인스턴스를 만들고, Traveler 인스턴스에 Account를 할당해주고 있습니다. 그리고 마지막으로 정보를 출력하고 종료되는 함수입니다. 

 

이제 ARC에서 어떤 일이 일어나는지 볼까요?

 

먼저 Traveler 인스턴스가 만들어지면서 reference count가 1인채로 생성됩니다.

그리고 Account 인스턴스가 만들어지면서 자신의 reference count를 1로 만들며 생성되고, 원래 있던 traveler 변수를 내부 프로퍼티에 할당하면서 traveler 객체의 reference count가 2로 증가하게 되죠.

 

그리고 traveler의 account 프로퍼티에 접근해 인스턴스를 할당했으니 account 객체의 reference count가 증가해 2가 됩니다.

 

account의 사용이 종료되었으니 traveler.count = account가 완료되면 Account의 카운트가 하나 줄어들고, 마지막으로 traveler 변수에서 printSummary를 하면 사용이 완료되어 카운트가 하나 더 줄어듭니다.

 

이제 두 인스턴스의 사용이 모두 완료되어서 Reference count까지 모두 정리가 되었는데, 힙의 두 인스턴스는 여전히 카운트를 1로 가지고 있네요. 이런 상황을 참조 사이클이라고 하고, 메모리에서 두 인스턴스가 절대 해제되지 않아 Memory Leak의 원인이 됩니다.

 

이 문제를 해결하기 위해서 사용하는 것이 weak이나 unonwned 였죠. Reference Count에 관여하지 않으니까요. weak으로 선언된 객체는 참조가 되었을 때 nil을 반환할 수 있고, unonwed 는 트랩을 발생시켜 런타임에러를 만들게됩니다.

 

Account 클래스의 traveler 프로퍼티를 weak으로 바꿔볼게요.

 

마지막으로 traveler를 사용하고나면 Traveler의 카운트가 0이 되겠죠? 이제 Account 는 Traveler가 사라지면서 카운트가 0이 되고 두 인스턴스가 모두 안전하게 해제됩니다.

 

이번엔 좀 다른 상황은 한 번 볼게요. 이번에는 printSummary를 account에서 해주고 있어요. 어쩌면 이 코드는 아무 문제없이 잘 실행될 수도 있습니다. 

 

하지만 그런 상황은 단순히 우연일 뿐이죠..

 

Traveler 객체가 모두 사용된 이후의 상황을 생각해볼게요.

 

traveler 객체의 사용은 account가 printSummary 함수를 호출하기 전에 종료됩니다. 그렇다면 함수가 호출되기 전에 Traveler 인스턴스의 카운트가 0이 되어서 메모리에서 해제될 수도 있는 것이죠.

 

만약 그렇다면 weak 으로 선언된 프로퍼티에는 nil이 들어가게 됩니다.

 

이런 상황에서 traver.name을 강제언래핑해서 사용하려고 한다면 크래시가 발생합니다.

 

물론 옵셔널 바인딩으로 크래시는 해결할 수 있지만, 크래시만 아닐 뿐 이런 코드는 여전히 버그입니다.

 

이번에는 weak과 unowned를 더 안전하게 사용할 수 있는 기술인 withExtendedLifetime을 소개하겠습니다.

 

스위프트는 withExtendedLifetime이라는 메서드를 제공하는데요, 명시적으로 특정한 객체의 생명주기를 늘리는 방법입니다. 위 예시처럼 사용하면, traveler 인스턴스의 생명주기가 printSummary가 끝날때까지로 연장되죠.

 

함수 스코프 가장 마지막에 메서드를 추가해서 같은 효과를 얻을 수도 있습니다.

 

더 복잡한 상황에서는 defer 안에 withExtendedLifetime을 넣어서 사용할 수도 있습니다.(와.. 여기서 소름돋았어요..)

 

이 기술을 사용하면 쉽게 객체의 생명주기에 대한 버그를 잡을 수 있지만, 단단한 기술은 아닙니다(fragile이라고 하셨는데 헛점이 많다고 해석할 수 있을 것 같아요.). 그리고 ARC가 하던 책임을 개발자에게 떠넘기게 되죠.

 

이런 방법을 사용한다면 약한 참조를 사용하는 모든 코드에 찾아가 코드를 넣어주어야 하고, 이건 너무 큰 유지비용을 요구합니다.

 

더 좋은 방법은 클래스를 더 나은 API들로 설계하는거예요.

 

객체의 생명주기 때문에 발생하는 문제는 만약 객체에 어딘가에서 접근을 받는 객체가 모두 강한 참조라면 예방이 가능합니다. 

 

이 코드에서는 printSummary를 다시 traveler로 옮겨주었어요. 그리고 Account의 traveler 인스턴스는 외부에서 사용할 수 없도록 숨겨주었습니다.

 

이제 printTest 메서드는 반드시 Account를 통해서만 호출이 되어야 하고 이것은 잠재적인 버그를 해결해줍니다. 

 

단순히 성능의 이슈를 떠나서 weak이나 unowned는 잠재적인 버그를 유발하기 때문에 여러분들은 클래스를 신중하게 설계해야합니다. 

 

weak 이나 unowned가 왜 필요한지, 단순히 참조 사이클을 해결하기 위해서만 사용하고 있는지 생각해보세요. 참조 사이킇은 클래스들의 순환관계를 트리구조로 변환하는 것을 통해서 해결이 가능합니다.

 

우리의 예시에서는 Traveler 클래스가 Account 클래스를 참조해야합니다. 하지만 사실 Account 클래스는 Traveler 클래스의 사용자 정보에만 접근하면 되죠.

 

그렇다면 우리는 Traveler 클래스가 가지고 있던 사용자 정보를 PersonalInfo라는 별도의 클래스로 분리할 수 있습니다. 이 클래스를 Traveler와 Account는 이 새로운 클래스를 참조하기만 하면 되죠. 이 과정에서 Account 클래스는 더이상 Traveler 클래스를 참조하지 않아도 되고, 참조사이클 문제가 weak이나 unowned를 사용하지 않아도 자연스럽게 해소됩니다.

 

이렇게 클래스를 다시 디자인하게 되면 구현비용이 더 발생하게 될거예요. 하지만 이 방법이 객체 생명주기와 관련된 버그를 해결할 수 있는 가장 확실한 방법이 됩니다.

 

객체의 생명주기로 인해 발생할 수 있는 또 다른 문제는 Deinitializer와 관련된 문제입니다. Deinitializer는 객체가 해제되기 직전에 호출되는데요, 이번에도 객체의 생명주기 때문에 발생할 수 있는 잠재적인 버그들이 있습니다.

 

버그에 대해서 더 자세히 보기전에, Deinitializer가 무엇인지부터 살펴보자구요.

 

아까와 같은 예제이지만 이번에는 Deinitializer가 추가되었습니다.

 

우리가 기대하는건 아마 Done traveling 이후에 Deinitializer가 호출되어서 추가적인 출력이 나오는 것이겠죠?

 

하지만 어떤 경우에는 Deinitializer가 "Done Traveling"이전에 출력될 수도 있습니다. 왜냐하면 traveler2 객체의 사용이 출력문 이전에 끝났으니까요.

 

이런 경우에는 외부에 영향을 주지는 않으니까 큰 문제는 없겠죠? 하지만 이런 경우는 어떨까요?

 

더 복잡한 케이스입니다. 이제 TravelMetrics라는 외부 클래스에 대한 의존성이 추가되었어요. Traveler객체는 해제되면서 이 TravelMetrics객체의 publish를 호출하고 이때 traveler에 대한 정보가 발행되는 구조입니다.

 

테스트 함수에요. 각 객체를 설정한 뒤에 목적지를 설정하고 computeTravelInterest를 호출하면, 업데이트한 목적지에 따라 카테고리가 부여되는 시나리오입니다.

 

우리는 두 목적지를 넣었고 이에 대해서 Natrue라는 카테고리가 생성되기를 기대합니다.

 

하지만 실제로 traveler 객체의 사용은 계산을 호출하는 함수 이전에 종료되고, 이때 deninitializer가 호출되면서 publish 메서드가 실행됩니다. 

 

아직 computeTravelInterest가 실행되지 않아서 카테고리가 부여되지 않았기 때문에 카테고리에 nil이 들어가는 버그가 발생합니다.

 

이미 설명했던 것 처럼 withExtendedLifetime 을 사용할 수 있겠지만, 이런 방법은 메모리 관리에 대한 책임을 개발자에게 맡기게 되는 문제가 발생합니다. 항상 withExtendedLifetime을 적절하고 확실하게 상요해주어야 합니다.

 

이번에도 로직을 재구성하는 방법이 있을 수 있겠죠? denitializer에 카테고리를 부여하는 함수를 publish와 함께 넣을 수 있겠지만 근본적인 해결방법은 아닙니다. 

 

이번에 시도할 수 있는 방법은 deinitializer에는 상태를 변경하는 메서드를 넣지 않는 것입니다. 대신 테스트 함수에 defer를 넣어서 함수가 종료되기 직전에 호출해줄 수 있죠. 상태를 변경하는 작업이 객체의 생명주기에 의존하지 않는다면 문제를 예방할 수 있게됩니다.

 

XCode13의  스위프트 컴파일러 세팅에 Optimize Object Lifetime에 대한 최적화가 추가되었어요. 이 옵션을 사용하면 객체들이 사용이 끝났을 때 메모리에서 해제되는 것이 더 일관성있게 지원됩니다. 

 

그러면 생명주기와 관련한 잠재적인 버그들을 더 쉽게 발견할 수 있게 되겠죠!

 

끝!

 

마무리

보는 내내 너무 유익하고 재미있는 세션이었어요..! ARC에 대해서 잘 모른다고 느낀게 저는 그냥 참조를 해제하는 코드 뒤에 release가 들어가는 줄 알았거든요.. 근데 Use-Based 였다는 것에 아직 배울게 더 많다고 느꼈습니다.. 그리고 애플 개발자들의 우아한 defer 사용도 그렇고.. 무지성 weak, unowned가 아니라 설계가 맞는지 고민해보라는 말도 아주아주 인상적이었습니다.

 

그냥 빌드 잘되고 nil 안나온다고 안심하지 말고 진짜 잠재적인 버그가 없는지 생각을 잘 해봐야겠어요!

 

근데 생각해보니까 결국 ARC랑 이것저것 다 설명한게 XCode13에 스위프트 컴파일 최적화 새로 만들어진거 홍보하려고 빌드업하신 것 같아요ㅋㅋㅋ 

 

발표해주신 분이 스위프트 컴파일러 엔지니어이신데 진짜 멋지네요.. 나도 저런 비슷한 수준까지 갈 수 있는 날이 올까..

 

중간중간에 제 생각도 들어가고 해서 이상한 내용이 있다면 알려주세요!