Garbage collection이란 무엇이며, 앱 개발에 왜 중요합니까?

Garbage collection은 프로그램이 더 이상 사용하지 않는 메모리를 식별하고 해제하여 메모리 관리를 처리하는 소프트웨어 개발의 자동화된 과정입니다. 이 과정은 프로그램이 메모리를 해제하지 않고 계속 할당할 때 발생하는 memory leak을 예방하는 데 도움이 되므로 필수적입니다. Memory leak은 비효율적인 자원 사용과 잠재적 crash로 이어질 수 있습니다.

Garbage collection은 메모리의 객체를 추적하고 실행 중인 프로그램에서 더 이상 도달할 수 없는 객체를 식별하는 방식으로 작동합니다. 객체에 더 이상 도달할 수 없으면 “garbage”로 취급되어 제거될 수 있으며, 이를 통해 새 객체를 위한 메모리가 확보됩니다. 이는 보통 background에서 자동으로 이루어지므로 개발자가 메모리를 수동으로 관리할 필요가 없어 오류 위험이 줄고 프로그램의 안정성이 향상됩니다.

수동 메모리 관리에서는 개발자가 직접 메모리를 할당하고 해제합니다. 이에 반해 garbage collection은 어느 정도의 runtime overhead가 있지만 훨씬 더 안전합니다. Codebase의 복잡성을 줄이고 메모리 관련 오류의 위험을 최소화하므로 현대 소프트웨어 개발, 특히 이 기능을 중심으로 설계된 Java와 C# 같은 언어의 핵심 구성 요소입니다. Rust 같은 언어는 세 번째 접근 방식을 택하여, compiler가 검사하는 소유권 규칙을 통해 garbage collector 없이 메모리 안전성을 보장합니다.

Java와 C# 모두 자동 세대별 garbage collection을 사용합니다. 대부분의 객체는 수명이 짧으므로 새 객체는 자주 수집되는 young 세대에 배치됩니다. 살아남은 객체는 덜 자주 수집되는 older 세대로 이동합니다.

차이는 주로 구현과 사용 가능한 옵션에 있습니다. Java Virtual Machine은 G1, ZGC, Shenandoah처럼 필요에 따라 선택할 수 있는 여러 garbage collector를 제공하며, 높은 처리량이나 짧은 일시 정지 중 하나에 초점을 둡니다. .NET은 세 개의 세대를 가진 garbage collector를 사용하며, 주요 선택지는 workstation 모드와 server 모드, 그리고 background 수집입니다. 두 플랫폼 모두 더 짧은 일시 정지 쪽으로 발전해 왔습니다.

기본 기법은 mark-and-sweep으로, garbage collector가 먼저 프로그램에서 아직 도달할 수 있는 모든 객체를 표시한 다음 나머지를 제거합니다. 한 변형은 이후 메모리를 압축하여 빈틈이 남지 않도록 합니다.

세대별 수집은 객체를 나이에 따라 나누고 새 객체들 사이에서 가장 자주 수집합니다. Copying collector는 살아 있는 객체를 새 영역으로 옮기고 이전 영역 전체를 해제합니다. Reference counting은 각 객체에 대한 참조 수를 추적하여 그 수가 0이 되면 객체를 해제하지만, 순환 참조는 단독으로 처리할 수 없습니다. 현대 collector는 일시 정지를 줄이기 위해 프로그램과 동시에 작동하는 경우가 많습니다.

Garbage collector가 작동하면 처리 능력을 사용하며, 일부 유형은 프로그램을 잠시 멈춥니다. 사용자가 scroll하거나 animation을 보는 동안 이런 일이 생기면 화면이 제때 업데이트되지 않아 작은 끊김이 발생할 수 있습니다.

예를 들어 loop 안이나 각 frame을 그리는 동안 임시 객체를 많이 만드는 앱은 garbage collector를 더 자주 실행하게 합니다. 이로 인해 앱이 덜 부드러워지고 mobile 기기의 전력 소비가 늘 수 있습니다. Android Runtime과 브라우저의 JavaScript engine 같은 현대 runtime은 짧은 일시 정지에 최적화되어 있지만, 성능이 중요한 코드에서는 여전히 불필요한 객체를 피하는 것이 좋습니다.

아니요. Swift와 Objective-C로 작성된 앱은 기본적으로 garbage collection을 사용하지 않습니다. 그 대신 Apple은 ARC로 줄여 쓰는 Automatic Reference Counting을 사용합니다. 여기서는 시스템이 각 객체를 가리키는 참조 수를 추적하고 남은 참조가 없으면 즉시 객체를 해제합니다.

장점은 garbage collector가 일으킬 수 있는 일시 정지 없이 메모리가 예측 가능하게 해제된다는 점입니다. 단점은 객체들이 서로를 붙잡는 순환 참조를 ARC가 스스로 감지할 수 없다는 점입니다. 따라서 개발자는 이러한 경우 약한 참조를 사용해야 합니다. 그러나 Flutter나 React Native 같은 framework로 만든 앱은 자체 runtime에서 garbage collection을 사용합니다.

Garbage collection 문제는 보통 사용자 interface의 끊김, 증가하는 메모리 사용량, 메모리 부족으로 인한 crash로 나타납니다. Android Studio Profiler, Chrome DevTools, Java와 .NET용 profiling 도구 같은 도구는 garbage collector가 언제 실행되고 메모리가 얼마나 사용되는지 보여 줄 수 있습니다.

해결책은 흔히 임시 객체의 수를 줄이는 것입니다. 예를 들어 loop에서 객체를 재사용하고 그리는 동안 새 객체 생성을 피합니다. 대량의 데이터는 더 작은 단위로 불러와야 합니다. 메모리가 계속 증가한다면 원인은 memory leak일 수 있으며, 이는 heap 분석으로 찾아야 합니다.