러스트 프로젝트가 2026년 프로젝트 목표 중 하나로 Move와 Forget이라는 새 트레이트 도입을 승인했다. rust-lang/rust-project-goals 저장소에 올라온 2026/move-trait.md 문서에 따르면, 담당자는 컴파일러 팀의 @lcnr이고 상태는 이미 "Accepted"이다. 목표는 타입이 "이동 가능하다"거나 "소멸자 없이 버려질 수 있다"는, 지금까지 러스트가 모든 타입에 당연하게 적용해 온 두 가정에서 벗어날 수 있게 하는 것이다. 작업 기간은 2026년부터 2027년까지로 잡혀 있고, lang팀과 types팀 모두 "Large" 수준의 지원을 확정했다.
Pin은 왜 지금 문제가 되나
러스트는 지금까지 값을 메모리에서 옮기는 이동(move)과 소멸자를 건너뛰는 mem::forget을 모든 타입에서 안전하다고 가정했다. 그런데 비동기 퓨처처럼 자기 자신을 참조하는(self-referential) 타입은 안전하게 이동시킬 수 없다. 현재 해법인 Pin은 이동 불가라는 성질을 타입이 아니라 "그 값이 놓인 자리"에 붙인다. 문서는 이 방식이 리눅스 커널처럼 자기참조 구조체를 많이 쓰는 환경에서 안전한 초기화를 특히 어렵게 만든다고 지적한다. rust-for-linux.com에 정리된 "The Safe Pinned Initialization Problem" 글이 그 구체적인 어려움을 다룬다.
Move 트레이트는 정확히 무엇을 바꾸나
제안의 핵심은 이동 불가 여부를 장소가 아니라 타입 자체의 속성으로 옮기는 것이다. 문서에 실린 선언은 #[lang = "move"] unsafe auto trait Move {} 형태다. 어떤 타입이 !Move를 구현하면 그 값은 존재하는 동안 주소가 절대 바뀌지 않아야 한다. 이렇게 하면 &pin mut self 같은 새 문법을 언어에 추가하지 않고도 자기참조 타입을 표현할 수 있다. 이 접근은 2025년에 진행된 Sized 트레이트 계층 작업과 같은 패턴을 따릅니다. 그 작업이 "모든 타입은 컴파일 시점에 크기를 알 수 있다"는 가정을 완화해 스케일러블 벡터를 지원했던 것처럼, 이번 목표는 "모든 타입은 이동 가능하다"는 가정을 완화한다. !Move 타입을 생성하는 구체적인 방법은 별도로 진행 중인 in-place-init 관련 작업에 의존한다.
왜 소멸자 실행을 강제해야 하나
두 번째 갈래는 소멸자를 강제하는 Forget 트레이트다. 지금은 mem::forget이 어떤 타입에도 안전하게 적용되기 때문에, 커밋(commit)이나 롤백(rollback)을 반드시 거쳐야 하는 트랜잭션 타입, 또는 스코프를 벗어나기 전에 반드시 조인(join)해야 하는 스코프드 태스크 핸들 같은 타입도 소멸자 실행을 보장받지 못한다. 문서가 든 예시는 unsafe impl !Forget for ScopedTaskHandle {}이다. 핸들이 !Forget이면 mem::forget 호출 자체가 막히므로, 핸들의 소멸자가 부모 스코프가 끝나기 전에 반드시 실행되어 태스크를 조인한다. 지금 안전한 러스트에서는 만들 수 없는 비동기용 안전한 스코프드 스폰(scoped spawn)이 이 방식으로 가능해집니다.
올해 실제로 진행되는 작업은 무엇인가
Move 트레이트 갈래는 컴파일러 구현(@lcnr, @nia-e), RFC 작성(@yoshuawuyts), 리눅스 커널에서의 실증(@BennoLossin), Iterator와 !Move의 상호작용 검증(@yoshuawuyts) 네 가지 작업으로 나뉜다. 리눅스 커널 검증은 자기참조 자료구조를 많이 쓰는 실제 대규모 사용자를 대상으로 이 설계가 통하는지 확인하는 절차이다. 보장된 소멸자 갈래는 아직 트레이트 계층과 기존 기능과의 상호작용을 탐색하는 설계 단계(@nikomatsakis)에 머물러 있어, Move보다 진행 속도가 느리다.
Future 트레이트는 왜 이번 범위에서 빠졌나
문서는 올해 범위에서 명시적으로 제외한 것도 밝힌다. Future는 안정화된 트레이트 중 유일하게 Pin에 의존하는 트레이트라서, Move로 옮기려면 별도의 마이그레이션 경로가 필요하다. 게다가 Pin 의존은 Future가 가진 여러 한계 중 하나일 뿐이라, 담당자들은 Future 자체를 고치는 일을 이번 목표와 분리된 독립 프로젝트로 다루기로 했다. 또한 이 작업은 2025년 하반기부터 진행되던 "Pin 인체공학(pin ergonomics)" 구상과 경쟁 관계에 있다. 문서는 &pin 같은 새 문법을 추가해 Pin을 계속 쓰는 방향 대신, Pin 자체를 장기적으로 폐기하는 쪽을 명시적 목표로 제시한다. 러스트가 영원한 하위 호환을 약속하는 언어인 만큼, pin을 &나 mut처럼 문법 차원에 새로 박아 넣는 결정은 향후 계속 짊어져야 할 부담이라는 것이 그 이유다.