Rust의 일관성(coherence) 시스템은 왜 모순투성이인가

Rust 타입 시스템의 핵심 규칙, coherence란?

Rust를 어느 정도 써본 개발자라면 한 번쯤 이런 컴파일 에러를 마주친 적이 있을 겁니다. 외부 크레이트의 트레이트를 외부 타입에 구현하려 했더니 "orphan rule에 의해 허용되지 않는다"는 메시지가 뜨는 경우입니다. 이 규칙의 근간이 되는 것이 바로 Rust의 coherence 시스템입니다. Coherence란 간단히 말해, 어떤 타입에 대한 트레이트 구현이 프로그램 전체에서 단 하나만 존재하도록 보장하는 규칙입니다. 만약 같은 타입에 대해 같은 트레이트가 두 번 구현된다면, 컴파일러는 어떤 구현을 사용해야 할지 결정할 수 없게 됩니다. 이런 모호함을 원천 차단하기 위해 Rust는 꽤 엄격한 규칙을 두고 있죠.

그런데 Rust 컴파일러 팀의 핵심 기여자인 boxy가 최근 블로그를 통해 이 coherence 시스템이 사실은 내부적으로 상당히 비일관적(incoherent)이라는 문제를 조목조목 짚어냈습니다. 아이러니하게도 "일관성을 보장하는 시스템"이 그 자체로 일관적이지 않다는 이야기입니다.

고아 규칙(Orphan Rule)의 딜레마

Rust coherence의 가장 잘 알려진 규칙은 고아 규칙(orphan rule)입니다. 이 규칙은 트레이트 구현(impl Trait for Type)을 작성할 때, 트레이트 또는 타입 중 적어도 하나는 현재 크레이트에서 정의된 것이어야 한다고 요구합니다. 예를 들어, 내가 만든 크레이트에서 표준 라이브러리의 Display 트레이트를 Vec<T>에 대해 구현할 수 없습니다. 둘 다 내 크레이트 소유가 아니기 때문입니다.

이 규칙이 존재하는 이유는 명확합니다. 만약 크레이트 A와 크레이트 B가 각각 impl Display for Vec<i32>를 작성했다면, 이 두 크레이트를 동시에 의존성으로 가져오는 프로젝트에서 충돌이 발생합니다. 고아 규칙은 이런 상황을 아예 불가능하게 만듭니다.

문제는 이 규칙이 실무에서 너무 제한적이라는 점입니다. 이른바 "newtype 패턴"이라는 우회법이 일상적으로 사용됩니다. 외부 타입을 감싸는 새로운 구조체를 만들고, 그 구조체에 원하는 트레이트를 구현하는 방식이죠. 동작은 하지만, 보일러플레이트 코드가 늘어나고 타입 변환의 번거로움이 생깁니다.

구체적으로 어디가 비일관적인가

boxy가 지적하는 핵심은, Rust의 coherence 시스템이 여러 겹의 규칙과 예외로 구성되어 있는데, 이 규칙들 사이에 모순이 존재한다는 것입니다. 특히 제네릭 타입과 관련된 경우에서 문제가 두드러집니다.

예를 들어, impl<T> MyTrait for Vec<T> 같은 블랭킷 구현(blanket impl)은 downstream 크레이트에서 impl MyTrait for Vec<MyType>과 충돌할 수 있습니다. 컴파일러는 이 충돌을 감지하고 거부하는데, 그 판단 로직이 때로는 지나치게 보수적이고, 때로는 불충분합니다. 특정 조합에서는 실제로 충돌이 불가능한데도 거부하고, 다른 조합에서는 이론적으로 충돌 가능한데 허용하는 경우가 있다는 뜻입니다.

또한 부정 추론(negative reasoning)의 문제도 있습니다. Rust의 coherence 검사기는 "이 트레이트가 이 타입에 구현되어 있지 않다"는 사실을 근거로 판단을 내리는 경우가 있는데, 미래에 upstream 크레이트가 해당 구현을 추가하면 기존에 컴파일되던 코드가 깨질 수 있습니다. 이것은 세맨틱 버저닝(semver) 관점에서 심각한 문제입니다. 트레이트 구현을 추가하는 것이 breaking change가 될 수 있다는 의미이기 때문입니다.

기존 대안과 진행 중인 논의

Rust 커뮤니티에서는 이 문제를 해결하기 위한 여러 제안이 오래전부터 논의되어 왔습니다. 가장 대표적인 것이 specialization RFC입니다. Specialization은 더 구체적인 트레이트 구현이 더 일반적인 구현을 덮어쓸 수 있게 허용하는 기능인데, 사운드니스(soundness) 문제 때문에 수년째 nightly에만 머물러 있습니다.

또 다른 방향은 marker trait 기반 접근이나 negative impl 등을 통해 컴파일러에게 더 정확한 정보를 제공하는 것입니다. 하지만 이런 접근들은 타입 시스템의 복잡도를 크게 높이기 때문에 도입에 신중한 입장이 지배적입니다.

Haskell의 타입클래스 시스템과 비교하면, Haskell은 OverlappingInstances나 IncoherentInstances 같은 언어 확장을 통해 유사한 문제를 "개발자 책임"으로 넘기는 접근을 취합니다. Rust가 이런 escape hatch를 제공하지 않는 것은 의도적인 설계 결정이지만, 그만큼 규칙 자체의 완결성에 대한 기대치가 높아질 수밖에 없습니다.

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

Rust를 실무에서 사용하는 한국 개발자라면, 이 글에서 설명하는 문제가 당장의 코드 작성에 직접적인 변화를 가져오지는 않습니다. 하지만 크레이트 라이브러리를 설계하거나, 복잡한 제네릭 트레이트 바운드를 다루는 상황이라면 coherence 시스템의 한계를 이해하고 있는 것이 디버깅 시간을 크게 줄여줍니다.

특히 한국에서 Rust 채택이 늘어나고 있는 시스템 프로그래밍, 블록체인, 게임 서버 영역에서 라이브러리 간 호환성 문제는 실질적인 pain point입니다. coherence 에러가 발생했을 때 "왜 이게 안 되는지"를 이해하면, newtype 패턴이나 wrapper 크레이트 같은 우회법을 더 자신 있게 선택할 수 있습니다.

또한 Rust의 에디션(edition) 시스템이나 향후 coherence 규칙 완화 가능성에 관심을 두는 것도 좋습니다. 컴파일러 팀 내부에서 이런 근본적인 문제의식이 공유되고 있다는 것 자체가, 장기적으로 개선이 이뤄질 가능성이 있음을 시사합니다.