2025년 7월 14일·7분
메모리 관리 전략: 성능 vs 안전성
가비지 컬렉션, 소유권, 참조 카운팅이 성능·지연·보안에 미치는 영향과 목표에 맞는 언어를 선택하는 방법을 알아보세요.
가비지 컬렉션, 소유권, 참조 카운팅이 성능·지연·보안에 미치는 영향과 목표에 맞는 언어를 선택하는 방법을 알아보세요.
메모리 관리는 프로그램이 메모리를 요청하고 사용하며 반환하는 규칙과 메커니즘의 집합입니다. 모든 실행 중인 프로그램은 변수, 사용자 데이터, 네트워크 버퍼, 이미지, 중간 결과물 같은 것들을 위해 메모리가 필요합니다. 메모리는 제한적이고 운영체제 및 다른 애플리케이션과 공유되므로, 언어는 누가 메모리를 해제할지와 언제 해제할지를 결정해야 합니다.
그 결정은 대부분의 사람들이 신경 쓰는 두 가지 결과를 만듭니다: 프로그램이 얼마나 빠르게 느껴지는지, 그리고 부하가 걸릴 때 얼마나 신뢰성 있게 동작하는지입니다.
성능은 단일 숫자가 아닙니다. 메모리 관리는 다음에 영향을 줍니다:
빠르게 할당하지만 가끔 정리 때문에 멈추는 언어는 벤치마크에선 좋아 보이지만 인터랙티브 앱에서는 버벅거릴 수 있습니다. 반면 일시중단을 피하는 모델은 누수와 수명 실수를 막기 위해 더 신중한 설계가 필요할 수 있습니다.
안전은 다음과 같은 메모리 관련 실패를 예방하는 것입니다:
많은 고프로파일 보안 이슈는 use-after-free나 버퍼 오버플로 같은 메모리 실수에서 비롯됩니다.
이 가이드는 인기 있는 언어들이 사용하는 주요 메모리 모델을 비기술적으로 소개하고, 각 모델이 무엇을 최적화하는지와 어떤 트레이드오프를 수용하는지 설명합니다.
메모리는 프로그램이 실행되는 동안 데이터를 저장하는 장소입니다. 대부분의 언어는 이를 두 가지 주요 영역인 스택과 힙으로 구성합니다.
스택을 현재 작업을 위한 깔끔한 포스트잇 더미로 생각하세요. 함수가 시작되면 그 함수용으로 작은 “프레임”이 스택에 생기고, 함수가 끝나면 그 전체 프레임이 한 번에 제거됩니다.
이 방식은 빠르고 예측 가능하지만, 크기가 알려져 있고 수명이 함수 호출과 함께 끝나는 값에만 적용됩니다.
힙은 필요할 때까지 객체를 길게 보관할 수 있는 보관실과 같습니다. 동적으로 크기가 변하는 리스트, 문자열, 여러 부분에서 공유되는 객체 등에 적합합니다.
힙 객체는 단일 함수보다 오래 살 수 있기 때문에 핵심 질문은: **누가 해제를 담당하고 언제 할 것인가?**가 됩니다. 이 책임이 언어의 “메모리 관리 모델”입니다.
포인터나 참조는 객체에 간접적으로 접근하는 방법입니다—보관실에서 상자의 선반 번호를 아는 것과 비슷합니다. 상자가 버려졌는데 여전히 선반 번호가 있다면, 쓰레기 데이터를 읽거나 충돌이 날 수 있습니다(전형적인 use-after-free 버그).
반복문이 고객 레코드를 만들고 메시지를 포맷한 뒤 버린다고 가정해봅시다:
어떤 언어는 이러한 세부를 숨기고(자동 정리), 다른 언어는 노출시켜(명시적으로 메모리를 해제하거나 누가 객체의 소유자인지 규칙을 따르게 함) 개발자가 직접 관리하게 합니다. 이하에서는 이러한 선택이 속도, 일시중단, 안전에 어떤 영향을 미치는지 살펴봅니다.
수동 메모리 관리는 프로그램(즉 개발자)이 명시적으로 메모리를 요청하고 나중에 반환하는 방식입니다. 실제로는 C의 malloc/free나 C++의 new/delete처럼 보입니다. 정밀한 메모리 취득/반환 시점을 제어해야 하는 시스템 프로그래밍에서 여전히 흔히 사용됩니다.
객체가 현재 함수 호출보다 오래 살아야 하거나 동적으로 커져야 하거나(예: 크기 조절 버퍼), 하드웨어나 OS, 네트워크 프로토콜과의 상호운용을 위해 특정 레이아웃이 필요할 때 주로 할당합니다.
백그라운드에서 GC가 실행되지 않으므로 놀라운 일시중단이 적습니다. 맞춤형 할당자, 풀, 고정 크기 버퍼와 결합하면 할당/해제 비용을 매우 예측 가능하게 만들 수 있습니다.
수동 제어는 오버헤드를 줄일 수 있습니다: 추적 단계가 없고, 쓰기 장벽(write barrier)이 없으며, 객체당 메타데이터도 적습니다. 코드가 신중히 설계되면 긴밀한 지연 목표를 달성하고 메모리 사용을 엄격히 제한할 수 있습니다.
대신 런타임이 자동으로 막아주지 않는 실수를 프로그램이 저지를 수 있습니다:
이 버그들은 충돌, 데이터 손상, 보안 취약점을 초래할 수 있습니다.
팀은 원시 할당을 허용하는 범위를 좁히고 다음과 같은 패턴에 의존해 위험을 줄입니다:
std::unique_ptr)수동 메모리 관리는 임베디드 소프트웨어, 실시간 시스템, OS 구성요소, 성능에 민감한 라이브러리에서 강한 선택입니다—정밀 제어와 예측 가능한 지연이 개발자 편의성보다 중요한 경우입니다.
가비지 컬렉션(GC)은 자동 메모리 정리입니다: 개발자가 직접 free하지 않아도 런타임이 객체를 추적하고 도달 불가능한 객체를 회수합니다. 이는 동작과 데이터 흐름에 집중하게 해주고 대부분의 할당/해제 결정을 시스템이 처리합니다.
대부분의 수집기는 먼저 살아 있는(live) 객체를 식별한 다음 나머지를 회수합니다.
추적형 GC(tracing GC) 는 루트(스택 변수, 전역 참조, 레지스터)로부터 시작해 참조를 따라 모든 도달 가능한 것을 표시하고, 이후 스윕하여 표시되지 않은 객체를 해제합니다. 어떤 것도 객체를 가리키지 않으면 그 객체는 수집 대상이 됩니다.
세대별 GC(generational GC) 는 많은 객체가 빨리 사라진다는 관찰에 기반합니다. 힙을 세대로 나누고 젊은 세대를 자주 수집하면 비용을 줄이고 전체 효율을 높입니다.
동시형 GC(concurrent GC) 는 수집 작업의 일부를 애플리케이션 스레드와 병행하여 실행해 긴 일시중단을 줄이는 것을 목표로 합니다. 이 경우 메모리의 일관된 뷰를 유지하기 위해 더 많은 부가작업이 필요할 수 있습니다.
GC는 일반적으로 수동 제어를 런타임 작업으로 교환합니다. 일부 시스템은 안정적 처리량을 우선시하지만 정지-세계(stop-the-world) 일시중단을 도입할 수 있습니다. 다른 시스템은 지연을 최소화하려고 노력하지만 정상 실행 중 추가 오버헤드를 가질 수 있습니다.
GC는 수명 관련 버그(특히 use-after-free)를 대부분 제거합니다. 또한 누락된 해제로 인한 누수를 줄여줍니다(물론 참조를 불필요하게 오래 유지하면 누수처럼 보이는 상태는 여전히 발생할 수 있음). 대규모 코드베이스에서 소유권을 수동으로 추적하기 어려운 경우 생산성을 크게 높여줍니다.
JVM(Java, Kotlin), .NET(C#, F#), Go, 브라우저 및 Node.js의 JavaScript 엔진 등에서 가비지 컬렉션 런타임을 흔히 볼 수 있습니다.
참조 카운팅은 각 객체가 자신을 가리키는 “소유자” 수를 추적하는 전략입니다. 카운트가 0이 되면 객체가 즉시 해제됩니다. 이 즉시성은 직관적으로 느껴질 수 있습니다: 더 이상 아무 것도 객체에 도달하지 않으면 메모리가 바로 회수됩니다.
객체에 대한 참조를 복사하거나 저장할 때마다 런타임이 카운트를 증가시키고, 참조가 사라질 때 감소시킵니다. 0이 되면 즉시 정리 트리거가 발생합니다.
이로 인해 자원을 사용하는 시점과 해제 시점이 가까워져 피크 메모리 사용량을 줄이고 지연된 회수를 피할 수 있습니다.
참조 카운팅은 일관된 상시 오버헤드를 가지는 경향이 있습니다: 많은 대입과 함수 호출에서 증가/감소 연산이 일어납니다. 이 오버헤드는 보통 작지만 어디서나 발생합니다.
장점은 일반적으로 대규모 정지 일시중단이 없다는 점입니다. 지연은 보다 매끄럽지만, 큰 객체 그래프가 마지막 소유자를 잃는 순간 해제가 폭발적으로 일어나 순간적인 작업량이 생길 수 있습니다.
참조 카운팅은 순환에 포함된 객체를 회수하지 못합니다. A가 B를 가리키고 B가 A를 가리키면, 둘 다 카운트가 0보다 크므로 아무도 회수되지 않아 메모리 누수가 발생합니다.
해결책:
소유권과 차용 모델은 Rust와 가장 밀접하게 연관되어 있습니다. 아이디어는 간단합니다: 컴파일러가 규칙을 강제하여 dangling pointer, 이중 해제, 많은 데이터 레이스를 런타임 GC 없이 어렵게 만듭니다.
각 값은 한 번에 정확히 하나의 “소유자”를 가집니다. 소유자가 스코프를 벗어나면 값이 즉시 정리됩니다. 이렇게 하면 파일 핸들, 소켓 같은 자원을 수동으로 정리하는 것과 유사한 결정론적 자원 관리를 얻을 수 있지만 실수를 만들 가능성이 크게 줄어듭니다.
소유권은 이동(move)될 수도 있습니다: 값을 다른 변수에 할당하거나 함수로 넘길 때 책임이 이전됩니다. 이동 후에는 이전 바인딩을 사용할 수 없어서 해제 후 사용을 구조적으로 방지합니다.
차용은 값을 소유하지 않고 사용하는 방법입니다.
공유 차용(shared borrow) 은 읽기 전용 접근을 허용하며 자유롭게 복사될 수 있습니다.
가변 차용(mutable borrow) 은 업데이트를 허용하지만 배타적이어야 합니다: 존재하는 동안 동일 값을 읽거나 쓰는 다른 접근은 허용되지 않습니다. 이 "하나의 작성자 또는 다수의 읽기자" 규칙은 컴파일 타임에 검증됩니다.
수명이 추적되기 때문에 컴파일러는 데이터가 가리키는 대상보다 오래 살아남는 코드를 거부할 수 있어 많은 dangling-reference 버그를 제거합니다. 동일 규칙은 동시성 코드에서 많은 종류의 레이스 조건도 예방합니다.
트레이드오프는 학습 곡선과 설계 제약입니다. 데이터 흐름을 재구성하거나 소유권 경계를 명확히 하거나 공유 가변 상태를 위해 특수 타입을 도입해야 할 수 있습니다.
이 모델은 시스템 코드—서비스, 임베디드, 네트워킹, 성능 민감 구성요소—에 적합합니다. GC 일시중단 없이 예측 가능한 정리와 낮은 지연이 필요할 때 유리합니다.
많은 단명 객체를 생성할 때(파서의 AST 노드, 게임 프레임의 엔티티, 웹 요청 동안의 임시 데이터 등) 개별 객체를 하나하나 할당/해제하는 비용이 런타임을 지배할 수 있습니다. 아레나(리전)와 풀은 세밀한 해제를 포기하고 빠른 일괄 관리로 교환하는 패턴입니다.
아레나는 여러 객체를 시간차로 할당하고 나중에 아레나를 드롭하거나 리셋해 한 번에 모두 해제하는 메모리 "구역"입니다.
각 객체의 수명을 개별적으로 추적하는 대신, "이 요청 동안 할당한 모든 것"이나 "이 함수 컴파일 동안 할당한 모든 것" 같은 명확한 경계에 수명을 묶습니다.
아레나는 보통 빠른데 그 이유:
이를 통해 처리량이 개선되고 빈번한 해제나 할당자 경쟁으로 인한 지연 스파이크를 줄일 수 있습니다.
아레나와 풀은 다음에서 자주 사용됩니다:
주요 규칙은 간단합니다: 아레나가 소유한 메모리보다 참조가 오래 남지 않도록 하세요. 아레나에서 할당한 무언가가 전역에 저장되거나 아레나 수명 이후에 반환되면 use-after-free 버그 위험이 있습니다.
언어와 라이브러리는 이를 다르게 처리합니다: 일부는 규율과 API에 의존하고, 다른 일부는 리전 경계를 타입으로 인코딩할 수 있습니다.
아레나와 풀은 GC나 소유권의 대안이 아닙니다—보통 보완적으로 사용됩니다. GC 언어도 핫 패스에서 객체 풀을 사용하고, 소유권 기반 언어는 수명을 명확히 하기 위해 아레나를 사용합니다. 신중히 사용하면 명확한 메모리 해제 시점을 유지하면서도 기본적으로 빠른 할당을 제공합니다.
언어의 메모리 모델은 성능과 안전성 이야기의 일부일 뿐입니다. 현대 컴파일러와 런타임은 당신의 프로그램을 덜 할당하고, 더 빨리 해제하며, 불필요한 부가작업을 피하도록 재작성합니다. 그래서 “GC는 느리다”거나 “수동 관리가 가장 빠르다”는 일반화는 실제 애플리케이션에서 자주 깨집니다.
많은 할당은 함수들 사이에서 데이터 전달을 위해 존재합니다. 이스케이프 분석(escape analysis) 으로 컴파일러가 객체가 현재 스코프를 벗어나지 않는다는 것을 증명하면 스택에 유지할 수 있습니다.
이로 인해 힙 할당 자체가 제거되고 관련 비용(트래킹, 참조 카운트 업데이트, 할당자 잠금 등)도 사라집니다. 관리형 언어에서 작은 객체의 비용이 기대보다 작을 수 있는 주요 이유입니다.
컴파일러가 함수를 인라인하면(함수 호출을 본문으로 대체) 추상층을 투명하게 볼 수 있습니다. 이 가시성으로 다음과 같은 최적화가 가능해집니다:
잘 설계된 API는 최적화 후에 "제로 코스트"가 될 수 있습니다. 소스상으로는 할당이 많아 보여도 런타임에서는 제거될 수 있습니다.
JIT(just-in-time) 런타임은 실제 운영 데이터(핫 경로, 일반적인 객체 크기, 할당 패턴)를 이용해 최적화합니다. 이는 처리량을 개선하는 경향이 있지만 워밍업 시간과 재컴파일/GC로 인한 가끔의 일시중단을 초래할 수 있습니다.
사전 컴파일(AOT) 은 초기에 더 많이 추측해야 하지만 예측 가능한 시작 시간과 더 안정된 지연을 제공합니다.
GC 기반 런타임은 힙 크기, 일시중단 목표, 세대 임계치 같은 설정을 노출합니다. 측정된 증거(예: 지연 스파이크, 메모리 압력)가 있을 때만 조정하세요.
“같은” 알고리듬의 두 구현은 숨겨진 할당 횟수, 임시 객체, 포인터 추적에서 다를 수 있습니다. 이런 차이는 최적화, 할당자, 캐시 동작과 상호작용하므로 성능 비교는 가정이 아니라 프로파일링에 기반해야 합니다.
메모리 관리 선택은 코드 작성 방식을 바꿀 뿐 아니라 작업이 언제 일어나는지, 예약해야 할 메모리 양, 사용자에게 느껴지는 성능의 일관성에 영향을 줍니다.
처리량은 단위 시간당 처리할 수 있는 작업량입니다. 예: 야간 배치 작업이 1천만 레코드를 처리하는 경우, GC나 참조 카운팅이 소소한 오버헤드를 추가해도 개발 생산성이 높다면 전체 완료 시간은 더 짧을 수 있습니다.
지연은 한 작업이 끝나는 데 걸리는 시간입니다. 웹 요청의 경우 한 번의 느린 응답이 사용자 경험을 해칩니다. 메모리를 회수하느라 가끔 멈추는 런타임은 배치 처리에는 괜찮지만 인터랙티브 앱에서는 눈에 띕니다.
더 큰 메모리 풋프린트는 클라우드 비용을 높이고 프로그램 속도를 늦출 수 있습니다. 작업 집합이 CPU 캐시에 잘 맞지 않으면 CPU는 RAM에서 데이터를 기다리게 됩니다. 일부 전략은 속도를 위해 여분의 메모리를 쓰고(예: 해제된 객체를 풀에 유지), 다른 전략은 메모리를 줄이지만 부가 작업을 늘립니다.
단편화(fragmentation) 는 자유 메모리가 작은 간격으로 흩어져 있는 상태입니다—마치 주차장에 여기저기 작은 빈칸만 남아 큰 차를 댈 수 없는 상황과 같습니다. 할당자가 공간을 찾느라 더 많은 시간을 쓸 수 있고, 메모리는 "충분"해도 계속 증가할 수 있습니다.
캐시 지역성(cache locality) 은 관련 데이터가 서로 가까운 곳에 있는 것을 의미합니다. 풀/아레나 할당은 보통 지역성을 향상시키고(함께 할당된 객체들이 근처에 위치), 수명이 섞인 장수 힙은 캐시 친화적 레이아웃에서 멀어질 수 있습니다.
일관된 응답 시간이 필요하다면(게임, 오디오 앱, 트레이딩 시스템, 임베디드/실시간 제어), "대부분 빠르지만 가끔 느린" 것은 "약간 느리지만 일관된" 것보다 더 나쁠 수 있습니다. 이런 경우 예측 가능한 해제 패턴과 할당 제어가 중요합니다.
메모리 오류는 단순한 "개발자 실수"가 아닙니다. 많은 실제 시스템에서 이들은 보안 문제로 이어집니다: 갑작스러운 충돌(서비스 거부), 해제되었거나 초기화되지 않은 메모리 읽기로 인한 데이터 노출, 공격자가 프로그램을 의도치 않은 코드로 유도하는 취약점 등.
다른 메모리 관리 전략은 일반적으로 다른 방식으로 실패합니다:
동시성은 위협 모델을 바꿉니다: 한 스레드에서 괜찮던 메모리가 다른 스레드에서 해제되거나 변경되면 위험해집니다. 공유에 관한 규칙을 강제하거나 명시적 동기화를 요구하는 모델은 손상, 데이터 누출, 간헐적 충돌로 이어지는 레이스 조건 가능성을 줄입니다.
어떤 메모리 모델도 모든 위험을 제거하지는 않습니다—논리적 버그(인증 실수, 취약한 기본값, 부적절한 검증)는 여전히 발생합니다. 강한 팀은 여러 보호층을 둡니다: 테스트에서의 sanitizer, 안전한 표준 라이브러리, 엄격한 코드 리뷰, 퍼징, 그리고 unsafe/FFI 코드 주변의 엄격한 경계. 메모리 안전은 공격 표면을 크게 줄여주지만 보장은 아닙니다.
메모리 문제는 도입 변경과 가깝게 잡을수록 고치기 쉽습니다. 핵심은 먼저 측정하고, 적절한 도구로 문제를 좁히는 것입니다.
먼저 당신이 추적하는 것이 속도인지 메모리 증가인지 결정하세요.
성능을 위해서는 실측 시간, CPU 시간, 할당률(바이트/초), GC/할당자에 소요되는 시간을 측정하세요. 메모리를 위해서는 최대 RSS, 안정 시점의 RSS, 시간에 따른 객체 수를 추적하세요. 일관된 입력으로 같은 부하를 여러 번 실행하세요; 작은 변동이 할당 차이를 숨길 수 있습니다.
흔한 징후: 단일 요청이 예상보다 훨씬 많은 메모리를 할당하거나, 트래픽이 증가해도 메모리가 계속 상승한다면 할당률을 의심하세요. 해결책은 버퍼 재사용, 단명 객체에 대한 아레나/풀 사용, 더 적게 살아남도록 객체 그래프 단순화 등입니다.
최소 입력으로 재현하고, 가장 엄격한 런타임 검사(sanitizer/GC 검증)를 켠 뒤 다음을 캡처하세요:
첫 번째 수정은 실험으로 취급하세요; 변경 후 측정해 할당량이 줄었고 메모리가 안정되었는지(다른 곳으로 문제가 옮겨가지 않았는지) 확인하세요. 자세한 트레이드오프 해석은 /blog/performance-trade-offs-throughput-latency-memory-use를 참조하세요.
언어 선택은 문법이나 생태계뿐 아니라 메모리 모델이 일상 개발 속도, 운영 리스크, 실제 트래픽에서 성능 예측 가능성에 어떤 영향을 주는지도 포함합니다.
제품 요구를 메모리 전략에 매핑하려면 다음과 같은 실용적 질문에 답하세요:
모델을 바꾸려면 마찰을 계획하세요: 기존 라이브러리(FFI) 호출, 혼합된 메모리 규약, 도구 체인, 인력 시장 등. 프로토타입을 통해 숨은 비용(일시중단, 메모리 증가, CPU 오버헤드)을 조기에 발견하세요.
실용적 접근법은 고려 중인 환경 각각에서 동일한 기능을 프로토타이핑하고 대표 부하에서 할당률, 테일 지연, 최대 메모리를 비교하는 것입니다. 팀은 때때로 Koder.ai 같은 도구에서 이 "사과 대 사과" 비교를 수행합니다: 작은 React 프론트엔드와 Go + PostgreSQL 백엔드를 빠르게 스캐폴딩한 뒤 요청 형태와 데이터 구조를 반복하며 GC 기반 서비스가 실제 트래픽에서 어떻게 동작하는지 확인할 수 있습니다(원할 경우 소스 코드도 내보낼 수 있습니다).
상위 3–5개의 제약을 정의하고 얇은 프로토타입을 만들고 측정하세요(메모리 사용, 테일 지연, 실패 모드).
| 모델 | 기본 안전성 | 지연 예측 가능성 | 개발 속도 | 전형적 함정 |
|---|---|---|---|---|
| 수동 | 낮음–중간 | 높음 | 중간 | 누수, 해제 후 사용 |
| GC | 높음 | 중간 | 높음 | 일시중단, 힙 성장 |
| RC | 중간–높음 | 높음 | 중간 | 순환, 오버헤드 |
| 소유권 | 높음 | 높음 | 중간 | 학습 곡선 |
메모리 관리는 프로그램이 데이터(객체, 문자열, 버퍼 등)에 대해 메모리를 할당하고 더 이상 필요하지 않을 때 해제하는 방식입니다.
이것은 다음에 영향을 줍니다:
스택은 빠르고 자동적이며 함수 호출에 묶여 있는 저장소입니다. 함수가 반환되면 그 함수의 스택 프레임 전체가 한 번에 제거됩니다.
힙은 동적이거나 장기간 유지해야 하는 데이터를 위한 유연한 저장소입니다. 다만 힙의 경우 누가 언제 메모리를 해제할지에 대한 전략이 필요합니다.
간단한 규칙: 스택은 수명이 짧고 크기가 알려진 로컬 값에 적합하고, 힙은 수명이나 크기가 예측 불가능한 경우에 사용됩니다.
참조(또는 포인터)는 객체에 간접적으로 접근하는 방법입니다. 위험한 경우는 객체의 메모리가 해제되었는데 그 참조가 여전히 사용될 때입니다.
이로 인해 발생할 수 있는 문제:
프로그램이 명시적으로 메모리를 할당하고 해제합니다(예: malloc/free, new/delete).
다음과 같은 경우에 유용합니다:
대가로 소유권과 수명을 신중히 관리하지 않으면 버그 위험이 높아집니다.
수동 관리는 설계가 잘 되어 있으면 매우 예측 가능한 지연 시간을 제공할 수 있어 빠릅니다. 백그라운드 GC 사이클이 없으므로 예기치 않은 일시중단이 줄어듭니다.
최적화 기법:
하지만 쉽게 잘못 사용하면 단편화(fragmentation), 할당자 경쟁, 작은 할당/해제의 과다 발생 같은 비용이 생길 수 있습니다.
가비지 컬렉션(GC)은 더 이상 도달할 수 없는 객체를 찾아 자동으로 회수합니다.
대부분의 추적형 GC는 다음과 같이 동작합니다:
이 방식은 해제 후 사용 같은 클래스의 버그를 줄이지만 런타임 작업을 추가하고 수집기 설계에 따라 일시중단을 초래할 수 있습니다.
참조 카운팅은 객체에 가리키는 참조의 수를 세다가 카운트가 0이 되면 즉시 해제합니다.
장점:
단점:
많은 생태계는 순환을 끊기 위해 를 사용하거나 순환 검출(cycle detector)을 추가합니다.
소유권/차용(ownership & borrowing)은 컴파일 타임에 규칙을 적용해 런타임 GC 없이 많은 수명 실수를 막는 모델입니다(대표적으로 Rust).
핵심 아이디어:
런타임의 GC 일시중단 없이 예측 가능한 정리를 제공하지만, 컴파일러의 수명 규칙을 만족시키기 위해 설계나 데이터 흐름을 재구성해야 하는 학습 곡선이 있습니다.
아레나(arena)나 리전(region)은 많은 객체를 한 구역에 할당한 뒤 그 구역을 한 번에 해제하는 방식입니다.
적합한 경우:
안전 규칙: 아레나가 소유한 메모리보다 오래 참조가 남으면 안 됩니다(참조가 아레나 수명 밖으로 유출되면 해제 후 사용 버그 가능).
현실적인 부하에서 먼저 측정하세요:
도구:
런타임 설정(예: GC 파라미터)은 문제를 측정해 원인을 찾은 후 조정하세요.