4.3 설계 철학 비교: 소유권 모델과 계약 기반 설계

프로그래밍 언어는 정확성(correctness)을 보장하기 위해 각기 다른 설계 철학을 채택합니다. 러스트가 사용하는 소유권(ownership) 및 빌림(borrowing) 모델은 컴파일 시점에 특정 유형의 오류를 자동으로 방지하는 데 중점을 둡니다. 반면, Ada/SPARK와 같은 언어에서 활용하는 계약 기반 설계(design by contract)는 개발자가 명시한 논리적 '계약'을 도구가 검증하는 방식을 사용합니다.

이 두 철학의 차이점과 각각의 공학적 상충 관계를 분석하기 위해, 컴퓨터 과학의 기초적인 자료구조인 이중 연결 리스트(doubly-linked list) 구현을 사례 연구로 사용하고자 합니다.

1. 접근법 1: Rust의 소유권 모델

이중 연결 리스트는 각 노드(Node)가 이전 노드와 다음 노드를 상호 참조하는 구조를 가집니다. 다른 언어에서 포인터나 참조를 사용해 비교적 직관적으로 구현되는 이 구조는, 러스트의 기본 규칙과 직접적으로 충돌합니다. 러스트의 소유권 시스템은 기본적으로 순환 참조(reference cycle)나 단일 데이터에 대한 다중 가변 참조를 허용하지 않기 때문입니다.

따라서 가장 직관적인 형태의 노드 정의는 빌림 검사기(borrow checker)에 의해 컴파일 오류로 처리됩니다.

// 컴파일되지 않는 직관적 형태의 코드
struct Node<'a> {
    value: i32,
    prev: Option<&'a Node<'a>>,
    next: Option<&'a Node<'a>>,
}

이러한 제약을 '안전한(safe)' 러스트 코드 내에서 해결하기 위해서는, 언어가 제공하는 명시적인 '탈출구'를 사용해야 합니다. 즉, 공유 소유권을 위한 Rc<T>, 내부 가변성(interior mutability)을 위한 RefCell<T>, 그리고 순환 참조를 끊기 위한 Weak<T>를 조합하여 사용합니다.

// Rc, RefCell, Weak를 사용한 구현 예시
use std::rc::{Rc, Weak};
use std::cell::RefCell;

type Link<T> = Option<Rc<Node<T>>>;

struct Node<T> {
    value: T,
    next: RefCell<Link<T>>,
    prev: RefCell<Option<Weak<Node<T>>>>,
}

• 분석: 이 접근법은 컴파일러가 데이터 경쟁(data race)과 같은 특정 유형의 동시성 문제를 자동으로 방지하는 강력한 이점을 제공합니다. 소유권 규칙은 기본적으로 가장 안전한 상태를 강제하며, 이중 연결 리스트와 같이 복잡한 공유 상태가 필요한 경우는 개발자가 Rc, RefCell 등을 사용하여 복잡성을 명시적으로 선택(opt-in)하도록 유도합니다. 이 과정에서 발생하는 인지적 비용(cognitive cost)과 코드의 장황함(verbosity)이 이 설계 철학의 주요 비용이라고 할 수 있습니다. 개발자의 초점은 문제의 논리적 구조보다, 컴파일러의 규칙을 만족시키는 방법에 더 집중될 수 있습니다.

2. 접근법 2: Ada/SPARK의 포인터 및 계약 기반 설계

Ada는 access 타입을 통해 C/C++과 유사한 포인터 사용을 지원하므로, 이중 연결 리스트의 구조를 더 직접적으로 표현할 수 있습니다.

-- Ada를 사용한 직관적 표현
type Node;
type Node_Access is access all Node;
type Node is record
   Value : Integer;
   Prev  : Node_Access;
   Next  : Node_Access;
end record;

기본적으로 Ada는 널 포인터(null access) 역참조와 같은 오류를 런타임에 검사하여 Constraint_Error 예외를 발생시킴으로써 안전성을 확보합니다.

여기서 더 나아가, Ada의 서브셋인 SPARK는 계약 기반 설계를 통해 런타임 오류의 부재를 컴파일 시점에 수학적으로 증명하는 방법을 제공합니다. 개발자는 프로시저(procedure)나 함수에 사전 조건(precondition, Pre)과 사후 조건(postcondition, Post)을 명시하고, 정적 분석 도구는 이 계약을 코드가 항상 만족시키는지를 검증합니다.

-- SPARK 계약을 통한 안전성 증명 예시
procedure Process_Node (Item : in Node_Access)
  with Pre => Item /= null; -- 'Item은 null이 아니다'라는 계약을 명시

• 분석: 이 접근법은 C/C++과 유사한 포인터 모델을 통해 개발자가 자료구조를 더 직접적으로 표현할 수 있는 유연성을 제공합니다. 안전성은 런타임 검사 또는 개발자가 직접 작성하는 명시적 계약과 정적 분석 도구의 증명을 통해 확보됩니다. 이 설계 철학의 비용은 개발자가 모든 잠재적 오류 경로를 고려하고, 이를 형식화된 계약으로 작성해야 하는 책임과 노력입니다. 계약이 누락되거나 잘못 작성될 경우, 안전성 보증은 불완전해질 수 있으며, 이는 자동화된 규칙에 의존하는 방식과는 다른 종류의 위험을 내포합니다.

3. 설계 철학 비교 및 결론

두 접근법은 소프트웨어의 정확성을 확보하기 위한 책임과 비용을 각기 다른 주체와 시점에 배분합니다.

결론적으로, 러스트의 소유권 모델을 '혁신' 또는 '결함'이라는 이분법적 시각으로 평가하기는 어렵습니다. 이는 뚜렷한 장점과 그에 상응하는 비용을 가진 하나의 독자적인 설계 철학입니다. 이 철학은 특정 유형의 버그를 예방하는 데 매우 효과적이지만, 그 과정에서 개발자에게 높은 학습 비용과 특정 문제에 대한 비직관적인 해결 방식을 요구하는 상충 관계를 내포하고 있습니다. 언어의 적합성은 해결하려는 문제의 종류, 팀의 역량, 그리고 프로젝트가 우선시하는 가치(예: 자동화된 안전성 보증 vs. 설계 유연성)에 따라 다르게 평가될 수 있습니다.

님프소프트 - 러스트 담론을 해체하다

님프소프트 - 러스트 담론을 해체하다

nimfsoft.art

https://nimfsoft.art/ko/books/deconstructing-the-rust-discourse