러스트 없이도 '빌림 검사기'를 만들 수 있다 — 타입 없는 Borrow Checking 이야기

빌림 검사기, 꼭 타입 시스템에 묶여 있어야 할까?

Rust를 배우다 보면 제일 많이 듣는 말이 '빌림 검사기(borrow checker)'예요. 이게 뭐냐면 Rust 컴파일러가 '이 변수는 지금 누가 쓰고 있나?', '두 명이 동시에 고치려고 하진 않나?'를 컴파일 타임에 꼼꼼히 체크하는 장치거든요. 덕분에 C/C++에서 흔한 use-after-free나 data race 같은 메모리 버그가 실행 전에 잡혀요.

그런데 Rust의 borrow checker는 구조적으로 타입 검사기(type checker)와 깊게 얽혀 있어요. 수명(lifetime) 같은 개념이 타입 시그니처에 딸려 있고, 타입 추론이 끝나야 borrow 관계를 정확히 분석할 수 있거든요. 그래서 오래 전부터 많은 언어 설계자들이 이런 의문을 가졌어요. "꼭 타입 시스템이랑 붙여야 하나? 메모리 안전성만 독립적으로 체크할 순 없나?"

Jamie Brandon의 글 "Borrow-checking without type-checking"은 바로 이 질문에 답을 주는 실험이에요. 결론부터 말하면, 타입 정보 없이도 빌림 검사의 핵심은 구현 가능하다는 거예요.

어떻게 동작할까

아이디어의 핵심은 이래요. Borrow checker의 본질은 '타입이 뭔지 알아내는 것'이 아니라, '어떤 메모리 위치(place)에 누가 언제 접근하는지'를 추적하는 것이거든요. 타입이 i32든 String이든, 'x라는 변수에 대한 참조 하나와 가변 참조 하나가 동시에 존재하면 안 된다'는 규칙 자체는 타입과 무관해요.

그래서 이 글에서는 변수와 필드 접근 경로(place)를 추적하는 단순한 정적 분석기를 만들어요. 각 시점마다 '이 place는 현재 읽기 전용으로 빌려져 있다', '이 place는 가변으로 빌려져 있다', '이 place는 이동(move)됐다' 같은 상태를 계산하는 거죠. 타입이 없으니 구조체 필드 같은 건 이름 기반으로 처리하고요.

놀라운 건 이렇게만 해도 Rust의 핵심 규칙이 거의 다 잡힌다는 점이에요. 동시에 여러 가변 참조 금지, 이동된 값 재사용 금지, 빌림이 살아있는 동안 원본 수정 금지 같은 규칙들이 타입 정보 없이도 자연스럽게 표현돼요. 물론 제네릭이나 trait 기반 추론처럼 타입이 있어야만 가능한 고급 패턴은 못 다루지만, 기본기는 충분히 성립한다는 거죠.

왜 이게 중요한가

언어 설계 관점에서 의미가 커요. 지금까지 '메모리 안전한 시스템 언어'를 만들려면 Rust 수준의 복잡한 타입 시스템을 통째로 도입해야 한다는 인식이 강했거든요. 근데 이 글은 "메모리 안전성과 타입 복잡도는 분리할 수 있다"는 걸 보여줘요. 그러니까 더 단순한 타입 시스템을 가진 언어도 Rust 수준의 안전성을 확보할 수 있다는 가능성이 열리는 거예요.

비슷한 흐름의 시도들이 이미 있어요. Vale 언어는 generation reference라는 기법으로 런타임 체크를 섞어서 메모리 안전을 구현하고 있고요, Austral은 linear type 기반으로 더 단순한 소유권 모델을 제안해요. Microsoft가 밀고 있는 Verona도 지역(region) 기반 접근으로 복잡도를 줄이려고 하고요. Mojo 같은 새 언어들도 Rust보다 부드러운 소유권 모델을 목표로 해요.

이번 글은 이런 시도들에 이론적 근거를 더해주는 셈이에요. '타입과 borrow를 분리해서 설계하면 더 유연한 언어가 가능하다'는 아이디어를 실제 구현으로 보여준 거죠.

한국 개발자에게 주는 시사점

당장 실무에 쓰는 기술은 아니에요. 근데 관심 있게 봐둘 가치는 충분해요. 요즘 한국에서도 시스템 프로그래밍이나 컴파일러 만드는 분들이 점점 늘고 있거든요. 특히 네이버, 카카오, 토스 같은 곳에서 성능 민감한 백엔드 인프라를 Rust로 재작성하는 사례도 많아졌고요.

컴파일러나 정적 분석기를 직접 만들어보고 싶은 분들께 이 글은 훌륭한 교재예요. Rust의 borrow checker 구현은 너무 복잡해서 소스를 읽어도 길을 잃기 쉬운데, 이 글은 최소한의 아이디어로 핵심만 추출해서 보여주거든요. 학부 프로그래밍 언어 수업의 과제로 삼아도 좋을 만한 수준이에요.

또 하나, 이 접근을 TypeScript나 Python 같은 동적 언어의 정적 분석 도구에 응용할 여지도 있어요. 타입이 없거나 느슨한 환경에서도 '이 객체의 수명이 이상해' 같은 경고를 낼 수 있는 실용적인 린터를 만들 수 있다는 뜻이죠.