TIL 4: MRC는 괴로워

TL;DR

• MRC는 매우 특별한 경우가 아니라면 쓰지말자.

MRC란? 🤔

현재 사내에서 레거시 코드를 유지보수하고 있어서 그런지 겪고 있는 어려움이 있다.
특히, 지금은 자동으로 메모리를 관리해주는 GC(Garbage Collection), ARC(Automatic Reference Counting) 등의 환경이 당연하다시피 여겨지고 있기 때문에 더 와 닿는다.

바로 MRC(Manual Reference Counting) 환경이다.

MRC는 iOS의 자동 메모리 관리 환경인 ARC의 반대되는 개념이다.
말그대로 개발자가 수동으로 메모리를 관리해줘야 한다. C, C++ 등과 함께 코딩을 해 본 사람이라면, 뭔지 바로 알 것이다. 개발자가 사용하기 위해 메모리에 공간을 할당했으면, 다 사용한 후에 직접 제거해줘야 한다. 그래야 해당 공간을 재활용할 수 있기 때문이다. 이것을 꼼꼼하게 하지 않고 놓치면, 메모리 누수 지옥이 시작되는 것이다.
과거에는 성능 최적화를 위해 직접 메모리 관리를 하는 경우가 있었지만, 현재는 세월이 많이 흘러 자동 메모리 관리 환경이 매우 잘 되어 있다. 따라서 특별한 경우를 제외한 일반적인 경우에서는 굳이 직접 메모리 관리를 할 필요가 없다.

메모리 누수 지옥 🔥

현재 사내에서 내가 맡고 있는 앱 일부는 Objective-C(이하 Obj-C)를 MRC 환경에서 사용하고 있어 직접 메모리 관리를 해야 한다. 수동 메모리 관리가 필요한 중요한 처리를 하지 않는 데도 말이다.

기존 앱들이 잘 되어 있었으면 괜찮지만, 메모리 누수가 다수 발견되어 해결하는 데 많은 고생을 하곤 했다.
Obj-C도 ARC 환경을 사용하는 데 무리가 없는데, 굳이 메모리 누수를 만들어 내며 MRC를 고수했는지 알 수가 없다. (물론, ARC 환경도 메모리 누수 방지를 위한 처리가 필요하지만, MRC는 더 꼼꼼하게 처리해야 한다.)
실제로 생산성도 떨어지고 메모리 누수와 버그도 발생하기 쉬워 비효율적이었다. (그래서 어떤 앱의 경우, 나에게 기회가 생겨 추후 유지보수를 위해 한 달의 시간을 투자해 Swift 및 ARC 환경으로 완전 포팅했다. 😂)

앞으로는 웬만하면 무조건 ARC

그렇게 기존처럼 오늘도 메모리 누수 지옥을 해결하기 위해 많은 노력을 했다. (아직 남아있을 수도 있겠지만 😤)
앞으로 가능하면 새 프로젝트는 무조건 (정말 특별한 경우를 제외하곤) ARC 환경으로 시작하려 한다. 메모리 누수 지옥을 해결하는 노력을 다른 데 쓰면 앱의 퀄리티를 더 높일 수 있을 것 같다. 😇