러스트의 Pin

2026-04-06T00:00:00+00:00
러스트에서 범용적인 애플리케이션 코드를 작성할 때는 잘 쓰이지 않는 메모리 고정 Pin</code>에 대해서 알아보자.</p>
일반적인 상황에서는 별로 접할 기회가 없지만, 러스트의 핵심 동작을 이해하려면 반드시 짚고 넘어가야 하는 개념이다. 보통 이 Pin</code>을 마주치게 되는 케이스는 크게 두 가지다.</p>

비동기 (async/await</code>) 생태계</li>
극단적인 성능 최적화 (e.g Zero Allocation Something)</li>
</ol>
우선 비동기부터 빠르게 알아보자.</p>
비동기에서의 Pin</code>#</a>
</h2>
좀 복잡하다. 러스트의 비동기 동작 원리를 이해해야 Pin</code>이 왜 필요한지 알 수 있다. 예를 들어 다음과 같은 비동기 함수가 있다고 가정하자:</p>
async</span> fn</span> foo</span>(</span>)</span> {</span></span>
    let</span> mut</span> buffer</span> =</span> [</span>0</span>u8</span>;</span> 2048</span>]</span>;</span></span>
    let</span> ptr</span> =</span> &</span>mut</span> buffer</span>;</span></span>
    </span></span>
    some_io_action</span>(</span>ptr</span>)</span>.</span>await</span>;</span></span>
    </span></span>
    println!</span>(</span>"</span>bar</span>"</span>)</span>;</span></span>
}</span></span></code></pre>
비동기 함수 내부를 보면, ptr</code>이 동일한 스택 내의 buffer</code>를 가리키는 자기 참조(Self-referential)</strong> 구조를 띠고 있다.</p>
컴파일러는 이 async</code> 블록을 다음과 같은 상태 머신(State Machine)으로 변환한다 (이해를 돕기 위한 의사 코드, 실제로는 Gen된 코드가 더 복잡하다):</p>
enum</span> FooStateMachine</span> {</span></span>
    Start</span>,</span></span>
    //</span> await 지점의 상태를 저장</span></span>
    YieldedAtSomeIo</span> {</span></span>
        buffer</span>:</span> [</span>0</span>u8</span>;</span> 2048</span>]</span>,</span></span>
        ptr</span>:</span> *</span>mut</span> [</span>0</span>u8</span>;</span> 2048</span>]</span>,</span> //</span> 구조체 내부의 buffer를 가리키는 자기 참조</span></span>
    }</span>,</span></span>
    Done</span>,</span></span>
}</span></span></code></pre>
만약 이 foo</code> 상태 머신 객체 자체가 메모리상에서 다른 곳으로 이동(Move)되면 어떻게 될까? buffer</code>의 메모리 주소는 새로운 곳으로 바뀌지만, ptr</code>은 여전히 옛날 주소를 가리키고 있을 것이다. 이 상태에서 ptr</code>을 참조하면 UB가 발생한다.</p>
예를 들어 Vec</code> 내에 Future</code>를 넣는다고 가정해 보자.</p>
let</span> mut</span> foo</span> =</span> Vec</span>::</span>new</span>(</span>)</span>;</span></span>
</span>
//</span> 작업 큐에 비동기 작업을 넣음</span></span>
foo</span>.</span>push</span>(</span>bar</span>(</span>)</span>)</span>;</span></span>
foo</span>[</span>0</span>]</span>.</span>poll</span>(</span>)</span>;</span> //</span> 첫 번째 작업 실행 내부적으로 참조 포인터 생성됨</span></span>
</span>
//</span> 새로운 작업이 들어와서 벡터의 용량(Capacity)이 초과됨</span></span>
foo</span>.</span>push</span>(</span>bar</span>(</span>)</span>)</span>;</span> </span></span>
</span>
//</span> 메모리 재배치가 일어난 후 다시 poll을 시도하면 UB</span></span>
foo</span>[</span>0</span>]</span>.</span>poll</span>(</span>)</span>;</span></span></code></pre>
벡터는 용량이 꽉 차면 더 큰 메모리를 할당받아 기존 요소들을 통째로 새로운 주소로 재배치(Reallocation)한다. 이때 자기 참조 포인터들이 모두 망가진다.</p>
그럼 단순히 Box</code>로 감싸서 힙에 올리면 원본 데이터는 이동하지 않으니까 문제가 없지 않나? 라고 생각할 수 있다. 절반은 맞다. 하지만 Box<T></code>는 내부 데이터에 대한 순수한 가변 참조자(&mut T</code>)를 제공한다. 악의적이거나 실수로 누군가 std::mem::swap(&mut box1, &mut box2)</code>를 때려버리면 힙 위에서도 내부 데이터가 뒤바뀌며 프로그램이 터질 것이다.</p>
그래서 러스트는 Pin<P></code>이라는 구조체를 제공한다. 이건 마법이 아니라, **개발자가 순수한 &mut T</code>를 마음대로 빼내지 못하게 막아버리는 포인터 래퍼(Wrapper)**다. 이게 Future</code> 트레잇의 poll</code> 메서드가 &mut Self</code> 대신 Pin<&mut Self></code>를 인자로 받는 이유다.</p>

Pin</code>의 핵심 동작 원리#</a>
</h2>
최적화 기법을 보기 전에, Pin</code> 자체가 어떻게 동작하는지 톺아보자.</p>
Pin 자체는 이동할 수 있다#</a>
</h3>
헷갈리는 부분인데, Pin</code> 구조체 자체는 자유롭게 이동 가능한 Unpin</code> 타입이다.</strong> Pin<&mut T></code>를 함수 인자로 넘기거나 변수에 재할당하는 행위는 메모리 주소를 담고 있는 8바이트짜리 wrapper를 넘겨주는 것일 뿐이다. 이리저리 move 돼도 결국 가리키는 T</code>의 메모리 주소는 절대 변하지 않는다.</p>
Pin::new</code>와 Pin::new_unchecked</code>#</a>
</h3>
어떤 데이터를 Pin</code>으로 묶을 때는 두 가지 방법이 있다.</p>

Pin::new</code> (safe):</strong> 대상이 Unpin</code> 타입(예: i32</code>, String</code>, 평범한 구조체)일 때만 쓸 수 있다. 애초에 메모리에서 이동해도 아무 문제 없는 타입들이라 컴파일러가 Auto Impl 해준다.</li>
Pin::new_unchecked</code> (unsafe):</strong> 대상이  이동하면 안 되는 !Unpin</code> 타입(예: Future</code>나 아래에서 다룰 침투형 노드)일 때 사용한다. 컴파일러가 안전을 보장할 수 없다.  unsafe</code> 블록을 열고 개발자가 보장의 책임을 져야 한다.</li>
</ol>

극단적인 최적화: 침투형 연결 리스트#</a>
</h2>
이제 극단적인 최적화 케이스에서 Pin</code>이 어떻게 활용되는지 알아보자. 할당 비용을 빡세게 최적화한 **침투형 연결 리스트(Intrusive Linked List)**가 예시로 꼽을 수 있겠다.</p>
일반적인 Linked List</code>는 보통 다음과 같이 구현된다.</p>
struct</span> Node</span><</span>T</span>></span> {</span></span>
    data</span>:</span> T</span>,</span></span>
    prev</span>:</span> *</span>mut</span> Node</span><</span>T</span>></span>,</span></span>
    next</span>:</span> *</span>mut</span> Node</span><</span>T</span>></span>,</span></span>
}</span></span></code></pre>
노드가 하나 추가될 때마다 힙 할당(Box::new</code> 등)이 발생한다. 비용적으로 별로 좋지 않기 때문에 아래와 같은 침투형 연결 리스트를 사용할 수 있다.</p>
use</span> std</span>::</span>marker</span>::</span>PhantomPinned</span>;</span></span>
use</span> std</span>::</span>pin</span>::</span>Pin</span>;</span></span>
</span>
struct</span> ListLink</span> {</span></span>
    prev</span>:</span> *</span>mut</span> ListLink</span>,</span></span>
    next</span>:</span> *</span>mut</span> ListLink</span>,</span></span>
}</span></span>
</span>
struct</span> Order</span> {</span></span>
    price</span>:</span> u64</span>,</span></span>
    link</span>:</span> ListLink</span>,</span></span>
    </span></span>
    //</span> 컴파일러에게 이 타입은 이동 불가(!Unpin)임을 알림</span></span>
    _marker</span>:</span> PhantomPinned</span>,</span> </span></span>
}</span></span></code></pre>
여기서 PhantomPinned</code>라는 마커 타입이 나온다.</p>
현재 Stable Rust에서는 impl !Unpin for Order {}</code> 처럼 명시적인 Negative Impl 문법을 지원하지 않는다. 그래서 러스트에서 지원해주는 !Unpin</code>인 PhantomPinned</code> 더미 필드를 집어넣어서 구조체 전체를 전염시켜 강제로 !Unpin</code> 타입으로 만드는 꼼수를 쓴다.</p>
구조체가 !Unpin</code>이 되면, 안전한 Rust 내에서는 절대 Pin</code>을 벗겨내고 &mut Order</code>를 가져올 수 없다. 즉, 누군가 std::mem::swap</code>으로 주문을 섞어버리는 것을 원천 차단한다. 실제로 마커 타입 넣고 std::mem::swap</code> 돌려보면 Unpin</code> 트레잇을 만족하지 않는다면서 컴파일 삐꾸낸다.</p>
리스트를 순회할 때 Order</code>의 포인터가 아니라 내부 필드인 ListLink</code>의 포인터를 얻게 된다. 원본 Order</code> 객체를 다루려면 포인터 역산을 해야 한다. 다행히 러스트 1.77부터 offset_of!</code> 매크로를 지원하여 일일이 바이트를 계산할 필요가 없어졌다.</p>
use</span> std</span>::</span>mem</span>::</span>offset_of</span>;</span></span>
</span>
impl</span> ListLink</span> {</span></span>
    unsafe</span> fn</span> get_parent</span>(</span>&</span>self</span>)</span> -></span> *</span>mut</span> Order</span> {</span></span>
        //</span> 포인터 주소 구하기</span></span>
        let</span> link_ptr</span> =</span> self</span> as</span> *</span>const</span> ListLink</span> as</span> *</span>const</span> u8</span>;</span></span>
        </span></span>
        //</span> offset_of! 매크로를 사용해서 Order 내의 link 필드 오프셋 구하기</span></span>
        let</span> offset</span> =</span> offset_of!</span>(</span>Order</span>,</span> link</span>)</span>;</span></span>
        </span></span>
        //</span> link 주소에서 오프셋만큼 빼서 본체의 시작 주소로 이동</span></span>
        let</span> parent_ptr</span> =</span> link_ptr</span>.</span>sub</span>(</span>offset</span>)</span>;</span></span>
        </span></span>
        //</span> 원본 Order 캐스팅</span></span>
        parent_ptr</span> as</span> *</span>mut</span> Order</span></span>
    }</span></span>
}</span></span></code></pre>
unsafe</code>하긴 하지만, ListLink</code>가 무조건 Order</code> 내부에 존재한다는 것을 API 설계자가 캡슐화로 보장한다면 문제없이 동작한다.</p>
이거 외에 개발자가 신경써줘야할 게 좀 있다.</p>
1. Pin 투영 (Pin Projection)#</a>
</h3>
Pin<&mut Order></code> 상태인 구조체에서 내부 필드를 가져오는 헬퍼 함수를 작성할 때 주의해야 한다. **Pin 투영(Projection)**이라고 하는데, 구조체 설계자가 다음 두 가지 중 하나를 선택해야 한다.</p>

Structural Pinning:</strong> 내부 필드(link</code>)도 절대로 메모리에서 재배치되면 안 된다. 따라서 getter는 반드시 Pin<&mut ListLink></code>를 반환해야 한다.</li>
Non-Structural Pinning:</strong> 내부 필드(price</code>)는 값만 빼서 바꿔도 리스트에 타격이 없다. 따라서 내부 타입인 &mut u64</code>를 반환해도 된다.</li>
</ul>
조심해야할 부분은 동일한 필드에 대해 묶인 참조(Pin<&mut T></code>)와 풀린 참조(&mut T</code>)를 동시에 노출하는 것</strong>이다. 이렇게 되면 풀린 참조를 통해 swap</code>을 해버릴 수 있어 Pin</code>이 보장하던 불변성이 파괴되며 UB가 된다. Pin 투영의 모든 보장의 책임은 전부 개발자에게 있어서 꽤 까다롭다.</p>
2. Drop 보장성#</a>
</h3>
객체가 메모리에서 해제될 때 호출되는 Drop</code> 트레이트도 고려해줘야한다.
구조체가 묶여(Pin</code>) 있더라도 소멸자 함수인 drop(&mut self)</code> 함수의 인자로 순수한 &mut self</code>를 던져준다.</p>
이때 Structural하게 묶어둔 필드(link</code>)를 replace</code>하거나 재배치해버리면 UB가 발생한다. 따라서 Drop</code> 내부에서는 Pin::new_unchecked(self)</code>를 사용해 강제로 다시 족쇄를 채운 뒤, 안전하게 리스트 연결을 해제(Unlink)하는 로직을 작성해야 한다.</p>
추가로, 메모리 압축을 위한 #[repr(packed)]</code> attribute를 걸면 내부 필드 메모리 정렬이 깨져 포인터 연산 시 CPU 예외가 발생할 수 있다.</p>

참조</strong></p>

https://medium.com/intro-to-rust/2020-04-24-pin-3500b145cca</a></li>
https://doc.rust-lang.org/std/pin/index.html</a></li>
</ul>
CWLog - unsafe

러스트의 Pin
