💻 computer science

A Trace-based Approach for Code Safety Analysis

이 논문은 Rust 의 안전성 설계와 실제 프로젝트를 분석하여 unsafe 코드와 정의되지 않은 동작에 대한 체계적인 프레임워크를 정립하고, Rust 코드의 건전성 기준과 건전한 캡슐화를 위한 실행 가능한 지침을 제시합니다.

원저자: Hui Xu

게시일 2026-02-27

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Hui Xu

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

🏗️ 1. 배경: Rust 라는 '안전한 도시'

Rust 는 메모리 (컴퓨터의 작업 공간) 를 안전하게 관리하는 언어로 유명합니다. 보통의 언어는 개발자가 실수하면 컴퓨터가 엉망이 되거나 해킹당할 수 있지만, Rust 는 **"안전한 코드 (Safe Code) 는 절대 사고 (Undefined Behavior) 를 내지 않는다"**고 약속합니다.

하지만 Rust 에는 예외가 하나 있습니다. 바로 **'불안전한 코드 (Unsafe Code)'**입니다. 이는 마치 도시 건설에서 "이곳은 위험하니, 전문가만 들어오세요"라고 표시된 구역과 같습니다. 개발자가 직접 위험을 감수하고 특수한 작업을 할 때 사용합니다.

🔍 2. 이 논문의 핵심 발견: "사고는 오직 위험 구역에서만 난다"

저자 (허이) 는 Rust 의 안전 시스템을 분석하며 아주 중요한 한 가지 법칙을 찾아냈습니다.

"컴퓨터가 사고 (Undefined Behavior) 를 내는 이유는 오직 '불안전한 코드' 때문이며, 그 사고는 해당 코드가 지켜야 할 '안전 수칙 (Safety Contract)'을 어겼을 때만 발생합니다."

이것은 마치 **"도시의 화재는 오직 '위험 구역'에서 시작되며, 그 구역의 안전 수칙을 지키지 않았을 때만 일어난다"**는 것과 같습니다. 만약 안전 구역 (안전한 코드) 에서 불이 난다면, 그것은 이미 그 구역이 안전 수칙을 어긴 '위험 구역'으로 변한 것입니다.

🕵️ 3. 해결책: 'trace(추적)'를 이용한 안전성 검증

이 논문의 핵심 아이디어는 **불안전한 코드를 '오염원 (Taint)'**으로 보는 것입니다.

비유: 불안전한 코드는 **'독이 든 물'**입니다.
안전한 코드: 이 독이 든 물을 안전하게 포장해서 다른 사람에게 넘겨주는 역할입니다.

이 논문의 제안은 다음과 같습니다:

안전한 함수 (Safe Function): 이 함수가 내부적으로 '독이 든 물 (불안전한 코드)'을 사용하더라도, 그 물이 함수 밖으로 새어 나오지 않도록 완벽하게 포장해야 합니다. 즉, 함수가 외부에 내놓는 결과물은 반드시 안전해야 합니다.
불안전한 함수 (Unsafe Function): 이 함수는 '독'을 직접 다룹니다. 이 함수를 부르는 사람이 **안전 수칙 (계약)**을 지키면, 그 함수는 안전합니다. 하지만 수칙을 어기면 사고가 납니다.

핵심 메시지: "네가 내게서 '독'을 가져가려면, 내가 정한 안전 수칙을 꼭 지키세요. 그리고 그 수칙을 지키는 한, 내 함수는 당신을 해치지 않습니다."

📦 4. 구조체 (Struct) 에 적용하기: '안전한 상자'

Rust 의 Struct는 데이터와 기능을 묶은 '상자'와 같습니다. 이 상자가 안전하려면 어떻게 해야 할까요?

안전 인자 (Safety Invariant): 상자 안의 물건들이 항상 '올바른 상태'를 유지해야 한다는 규칙입니다. (예: 금고의 문은 항상 잠겨 있어야 한다.)
규칙: 상자를 만드는 사람 (생성자) 이나 상자를 수정하는 사람 (메서드) 은 이 '올바른 상태'를 깨뜨리지 않아야 합니다.
- 만약 어떤 기능이 상자를 망가뜨릴 수 있다면, 그 기능은 **'불안전 (Unsafe)'**이라고 표시해야 합니다.
- 다른 기능들은 "이 상자는 항상 안전하다"는 전제하에 작동할 수 있게 됩니다.

🏢 5. 결론: 개발자를 위한 가이드

이 논문의 결론은 매우 실용적입니다.

계약서 (Safety Contract) 를 쓰세요: 불안전한 코드를 쓸 때는 "이걸 쓰려면 반드시 이 조건을 지켜야 해"라는 문서를 명확히 남겨야 합니다.
포장 (Encapsulation) 을 잘 하세요: 안전한 코드가 불안전한 코드를 쓸 때는, 그 위험이 밖으로 새지 않도록 철저히 막아야 합니다.
문제 추적: 만약 프로그램이 사고를 쳤다면, 그 원인은 반드시 '불안전한 코드' 중 '안전 수칙'을 어긴 부분일 것입니다. 이 원칙을 따르면 어디서 문제가 발생했는지 쉽게 찾을 수 있습니다.

💡 요약

이 논문은 **"Rust 의 안전성은 마법처럼 저절로 생기는 것이 아니라, 개발자가 불안전한 코드에 대한 '안전 수칙'을 명확히 하고, 그 수칙을 지키도록 코드를 포장 (Encapsulation) 할 때 비로소 완성된다"**는 것을 증명했습니다.

이는 마치 안전한 도시를 만들기 위해, 위험 구역의 안전 수칙을 명확히 하고, 그 구역 밖으로 위험이 퍼지지 않도록 방호벽을 치는 것과 같습니다. 이 원칙을 따르면 Rust 프로그램은 더욱 튼튼하고 신뢰할 수 있게 됩니다.

1. 연구 배경 및 문제 제기 (Problem)

Rust 의 안전성 약속: Rust 는 메모리 안전성을 보장하며, '안전한 코드 (Safe Code)'는 정의되지 않은 행동 (Undefined Behavior, UB) 을 유발하지 않는다는 약속을 합니다.
불안전 코드 (Unsafe Code) 의 위험: Rust 의 안전성 보장은 '불안전 코드' 영역에서는 성립하지 않습니다. 불안전 코드는 프로그래머가 직접 안전성 계약 (Safety Contract) 을 준수해야 하며, 이를 위반할 경우 UB 가 발생합니다.
현실적 문제: 실제 Rust 프로젝트 (표준 라이브러리 포함) 를 분석해 보면, 불안전 코드가 어떻게 UB 로 이어지는지에 대한 체계적인 프레임워크가 부족합니다. 또한, 안전한 함수와 불안전 함수가 혼재된 구조에서 안전성을 어떻게 격리 (Encapsulation) 하고 검증할지에 대한 명확한 기준이 필요합니다.

2. 방법론 (Methodology)

이 논문은 추적 기반 (Trace-based) 접근법을 제안하며, 안전성 분석을 위해 다음과 같은 논리적 체계를 구축합니다.

주요 정리 (Main Theorem) 도출:
- 핵심 명제: 정의되지 않은 행동 (UB) 은 오직 불안전 코드에서만 발생하며, 이는 해당 불안전 코드의 안전성 계약 (Safety Contract) 위반에 의해서만 결정됩니다.
- 수식적 표현: $P \Downarrow UB \Rightarrow P \supset UC \land P \not\models SC_{UC}$ (프로그램 $P$ 가 UB 를 발생시키려면 $P$ 는 불안전 코드 $UC $를 포함해야 하며, 해당 코드의 안전성 계약$ SC$ 를 위반해야 함).
타인 분석 (Taint Analysis) 유사성:
- 함수 내의 불안전 코드를 '오염원 (Taint Source)'으로, 함수의 진입/종점을 '싱크 (Sink)'로 간주합니다.
- 안전성 격리의 핵심은 불안전 코드로부터의 위험 전파가 격리 경계를 넘지 않도록 하는 것입니다.
구조체 (Struct) 를 위한 확장:
- 구조체의 내부 상태가 공유되므로 개별 함수만 분석하는 것은 부적절합니다.
- 안전성 불변량 (Safety Invariant, $SI$) 개념을 도입합니다. 이는 구조체의 모든 유효한 인스턴스가 지켜야 하는 속성을 정의합니다.
- 구조체의 메서드가 유효한 인스턴스를 생성하거나 유지하는지, 그리고 내부 불안전 코드의 계약을 준수하는지 분석합니다.

3. 주요 기여 (Key Contributions)

A. 안전성 격리 (Sound Encapsulation) 규칙 정립

함수 단위:
- 안전 함수 ( $f_s$ ): 내부에 불안전 코드가 없거나, 호출하는 모든 불안전 함수의 안전성 계약을 준수하면 안전합니다.
- 불안전 함수 ( $f_u$ ): 호출하는 모든 불안전 함수의 안전성 계약을 준수하면 안전합니다.
- 일반화: 모든 함수는 자신의 안전성 계약 (안전 함수는 빈 계약) 과 호출하는 불안전 함수들의 계약을 준수할 때 격리됩니다.
구조체 단위:
- 생성자 (Constructor): 생성된 인스턴스가 구조체의 안전성 불변량 ($SI$) 을 만족해야 합니다.
- 메서드 (Method): 메서드 실행 전후로 인스턴스가 $SI$ 를 유지해야 하며, 내부 불안전 코드의 계약을 준수해야 합니다.
- 리터럴 생성자 및 필드 접근: 모듈 외부에서 접근 가능한 경우, $SI$ 를 위반하지 않도록 제한하거나 보호해야 합니다.

B. 모듈 및 크레이트 (Crate) 수준의 안전성 정의

모듈의 안전성은 구성 요소 (함수, 구조체) 의 안전성으로 귀결됩니다.
정적 변수 (Static Variables) 나 함수 간 인터리빙에 대한 복잡한 분석 대신, 각 구성 요소가 자신의 안전성 계약과 불변량을 준수하면 모듈 전체가 안전하다고 간주합니다.

C. 형식적 정의 및 증명

안전성 약속 (Safety Promise), 안전 함수의 기준, 불안전 함수의 기준 등을 형식적으로 정의 (Definition 1~3) 하고, 이를 바탕으로 주요 정리 (Theorem 1) 를 증명했습니다.

4. 결과 및 적용 (Results & Applications)

실무 지침 제공: 개발자가 안전성 계약을 명확히 문서화하고, 이를 통해 안전한 격리를 달성할 수 있는 구체적인 가이드라인을 제시합니다.
오류 원인 규명: 하위 크레이트 (Downstream Crate) 에서 UB 가 발생했을 때, 어느 구성 요소 (함수 또는 구조체) 가 안전성 계약을 위반했는지 식별하는 데 유용합니다.
정적 분석 도구 지원: 제안된 추론 프레임워크는 프로그램 분석 도구가 Rust 코드의 안전성을 검증하는 데 활용될 수 있는 이론적 기반을 제공합니다.

5. 의의 (Significance)

이론적 기반 강화: Rust 의 안전성 모델이 단순히 "안전한 코드는 UB 를 일으키지 않는다"는 명제를 넘어, 불안전 코드가 어떻게 제어되어야 하는지에 대한 체계적인 수학적/논리적 근거를 제공합니다.
실용성: Rust-for-Linux 등 대규모 프로젝트에서 실제로 적용되고 있는 '안전성 불변량' 개념을 형식화하여, 시스템 프로그래밍 언어의 안전성 검증 방법론을 정립했습니다.
확장성: 이 프레임워크는 트레이트 (Trait) 구현이나 복잡한 모듈 구조에도 적용 가능하여, Rust 생태계의 전반적인 코드 품질 향상과 신뢰성 확보에 기여할 것으로 기대됩니다.

요약: 이 논문은 Rust 의 안전성 문제를 '불안전 코드의 안전성 계약 위반'으로 귀결시키고, 이를 추적 기반 분석을 통해 함수와 구조체 수준에서 격리하는 체계적인 프레임워크를 제안합니다. 이를 통해 개발자는 명확한 계약을 통해 안전성을 보장할 수 있으며, 분석 도구는 UB 발생 원인을 효과적으로 추적할 수 있게 됩니다.