부록 B: 동일 안전성 목표 하의 코드 비교 - Rust vs. Ada/SPARK

이 부록은 본문 5장에서 철학적 차원으로 다룬 ‘의도 중심’과 ‘규칙 중심’의 설계 방식이, 실제 코드에서는 어떻게 구현되는지 구체적으로 비교 분석합니다.

이를 위해, 컴퓨터 과학의 가장 기본적인 자료구조 중 하나를 구현하는 것을 목표로 설정하고, 각 언어가 이 문제를 해결하는 접근 방식과 그 과정에서 개발자가 겪는 경험이 어떻게 다른지 독자 여러분께서 직접 판단하실 수 있도록 구성했습니다.

비교 과제: ‘부모-자식 관계’를 가진 노드(Node) 구조 표현하기

우리의 목표는 간단한 트리(Tree) 구조를 만드는 것입니다. 이 구조에서 각 노드는 여러 자식 노드를 가질 수 있으며, 동시에 각 자식 노드는 자신의 부모 노드를 가리키는 참조를 가질 수 있어야 합니다.

접근법 1: 러스트 (Rust) - ‘규칙’이 ‘의도’를 가로막는 경우

1. 직관적이지만 ‘실패’하는 코드

다른 언어에 익숙한 개발자라면 누구나 떠올릴 법한, 가장 직관적인 코드입니다. 하지만 이 코드는 러스트의 빌림 검사기(Borrow Checker) 규칙 때문에 절대로 컴파일되지 않습니다.

// 이 코드는 컴파일되지 않습니다!

struct Node<'a> {

    parent: Option<&'a Node<'a>>, // 부모를 가리키는 참조

    // ... 다른 필드들

}

fn main() {

    let mut root = Node { parent: None, /* ... */ };

    // 컴파일 에러: `root`의 소유권과 빌림 규칙이 충돌합니다.

    // 빌림 검사기는 이처럼 데이터가 순환 참조 구조를 갖는 것을 허용하지 않습니다.

    let child = Node { parent: Some(&root), /* ... */ };

}

‘자식이 부모를 가리킨다’는 개발자의 단순하고 명확한 의도가, ‘데이터는 단 한 명의 소유자만 가져야 하며, 빌림 규칙은 순환을 만들 수 없다’는 컴파일러의 엄격한 규칙과 정면으로 충돌하는 상황입니다.

2. ‘성공’하지만 복잡한 우회로

이 문제를 ‘안전한(safe)’ 러스트로 해결하려면, 개발자는 자신의 단순한 의도를 포기하고, 컴파일러의 규칙을 통과하기 위해 Rc, RefCell, Weak라는 복잡한 개념들을 동원한 ‘우회로’를 설계해야 합니다.

use std::rc::{Rc, Weak};

use std::cell::RefCell;

// 부모를 가리키는 참조는 '소유권 없는' 약한 참조(Weak)를 사용해야 합니다.

// 내부의 값을 변경하기 위해 RefCell을 사용합니다.

struct Node {

    parent: RefCell<Weak<Node>>,

    children: RefCell<Vec<Rc<Node>>>,

}

fn main() {

    let root = Rc::new(Node {

        parent: RefCell::new(Weak::new()),

        children: RefCell::new(vec![]),

    });

    let child = Rc::new(Node {

        parent: RefCell::new(Rc::downgrade(&root)), // 부모를 '약한 참조'로 저장

        children: RefCell::new(vec![]),

    });

    // 자식 노드를 추가하기 위해 .borrow_mut()를 호출해야 합니다.

    root.children.borrow_mut().push(Rc::clone(&child));

    println!("트리 구조 생성 완료!");

}

러스트 방식 분석

단순한 부모-자식 관계를 표현하기 위해, 개발자는 Rc(참조 카운팅 포인터), RefCell(내부 가변성), Weak(약한 참조), borrow_mut()(가변 빌림), downgrade()(약한 참조로 변환) 등 수많은 난해한 개념과 마주해야 합니다. 개발자의 초점은 ‘트리 구조’라는 원래 문제에서 벗어나, ‘어떻게 하면 빌림 검사기를 통과할까’라는 러스트의 규칙 자체를 해결하는 문제로 변질됩니다. 안전성은 컴파일러가 강제하지만, 그 대가로 개발자는 비직관적인 코드와 씨름해야 합니다.

접근법 2: Ada/SPARK - ‘의도’를 코드로 직접 표현하는 경우

Ada/SPARK 생태계는 개발자의 의도를 존중하고, 안전성을 다층적으로 확보하는 길을 제시합니다.

1. Ada: 직관적인 구조 표현과 런타임 안전성

먼저, Ada 언어 자체는 access라는 ‘포인터’ 타입을 사용하여 개발자의 의도를 직접적으로 표현하도록 돕습니다.

-- `Node` 타입을 미리 선언하여 자기 참조 구조가 가능하게 합니다.

type Node;

-- `Node` 타입을 가리킬 수 있는 '포인터' 타입을 정의합니다.

type Node_Access is access all Node;

-- 실제 `Node` 타입을 정의합니다.

type Node is record

   -- 부모를 가리키는 포인터를 필드로 가집니다. (자연스러운 표현)

   Parent   : Node_Access;

   -- 자식들을 담는 자료구조...

end record;

-- 사용 예시

procedure Create_Tree is

   Root  : Node_Access := new Node;

   Child : Node_Access := new Node;

begin

   Root.Parent := null; -- 루트 노드의 부모는 없음

   -- 자식 노드의 Parent 필드가 부모 노드(Root)를 직접 가리킵니다.

   Child.Parent := Root;

   -- ... 자식 노드를 Root의 Children 리스트에 추가하는 로직 ...

end Create_Tree;

이처럼 개발자의 의도(“노드는 다른 노드를 가리킬 수 있다”)가 매우 간결하게 표현됩니다. 이때 Ada는 러스트와 다른 방식으로 안전성을 확보합니다. 만약 개발자가 Parent가 null인 상태에서 Parent.all과 같이 역참조를 시도하면, 컴파일러는 이 코드를 막는 대신 런타임에 Constraint_Error라는 예외를 발생시키는 코드를 기본적으로 삽입합니다. 즉, 런타임에서 안전장치가 작동하는 것입니다.

이처럼 Ada의 런타임 안전망은 훌륭하지만, 일부 고신뢰성 시스템에서는 이마저도 부족할 수 있습니다. 바로 이 지점에서 SPARK가 등장하여 안전성을 한 차원 더 끌어올립니다.

2. SPARK: 명시적 계약을 통한 ‘증명된’ 컴파일 타임 안전성

SPARK는 개발자가 자신의 ‘의도’를 ‘계약(Contract)’으로 명시하면, 정적 분석 도구(Prover)가 “이 코드는 런타임 에러가 절대 발생하지 않는다”는 것을 수학적으로 증명합니다.

-- 부모의 정보를 사용하는 프로시저

procedure Process_Parent (Item : in Node_Access)

  with

    -- 사전 조건(Pre-condition)으로 "Item의 부모는 null이 아니다"라고 명시합니다.

    -- 이것이 개발자의 '의도'이자, Prover에게 증명을 요청하는 '계약'입니다.

    Pre => Item.Parent /= null

is

begin

   -- 이 계약 덕분에, SPARK Prover는 아래 코드가 런타임 에러 없이

   -- 안전함을 100% 증명할 수 있습니다.

   Put_Line ("My Parent is: " & Image (Item.Parent.all));

end Process_Parent;

이처럼 SPARK는 개발자에게 자신의 코드가 안전하다는 것을 ‘스스로 증명’하도록 요구합니다. 도구는 개발자의 이 선언이 타당한지를 수학적으로 검증해 줄 뿐입니다.

결론: 두 방식의 비교

이 ‘그래프/트리’ 예시는 ‘개발자의 단순한 의도’(자식이 부모를 가리킨다)와 ‘컴파일러의 엄격한 규칙’(데이터는 단 한 명의 소유자만 가져야 한다)이 정면으로 충돌하는 상황을 극명하게 보여줍니다. 러스트의 방식이 왜 어떤 이들에게는 ‘불필요한 장벽’이자 ‘비정석적인 설계’로 평가받는지, 이 예시만큼 명확하게 보여주는 것은 없습니다.

이 비교를 통해, 우리는 두 언어가 ‘안전성’에 도달하는 길이 근본적으로 다름을 알 수 있습니다. 러스트는 개발자의 실수를 원천적으로 막는 엄격한 ‘자동화된 규칙’을 선택했고, Ada/SPARK는 개발자의 ‘명시적인 의도와 증명’을 통해 안전성을 확보하는 길을 선택했습니다. 어느 쪽이 더 합리적인지는, 결국 개발자의 철학에 달려있을 것입니다.