넘버스
넘버스
"안전하지 않은" 러스트는 unsafe 키워드로 표시된 블록에 포함된 러스트 코드를 가리키는 용어다. unsafe 블록 내에서는 러스트의 안전 규칙 중 일부(전부는 아님)를 구부릴 수 있다(부러뜨리는 정도는 안 됨).
C 또는 다른 저수준 시스템 언어를 사용하다 러스트로 왔다면 저수준 조작을 위해 익숙한 패턴을 사용하고 싶을 때마다 unsafe를 사용하고 싶은 생각이 들 수 있다. 실제로 러스트에는 unsafe 코드를 통하지 않으면 할 수 없는 일이 몇 가지 있다. 그러나 많은 경우 필요한 기능이 러스트에 이미 있으므로 굳이 unsafe를 사용할 필요가 없다.
이 기사에서는 러스트에서 unsafe의 실제 용도, 할 수 있는 일과 없는 일, 현명하게 사용하는 방법을 알아본다.
'unsafe' 러스트로 할 수 있는 일
러스트에서 unsafe 키워드를 사용하면 코드 블록 또는 함수를 지정해서 러스트 언어의 특정 기능 하위 집합을 활성화할 수 있다. 러스트의 unsafe 블록 내에서 액세스할 수 있는 기능을 살펴보자.원시 포인터
러스트의 원시 포인터는 가변 또는 불변 값을 참조할 수 있으며, 러스트의 참조보다는 C의 포인터 개념에 더 가깝다. 원시 포인터를 사용하면 작업 차용 방법에 적용되는 일부 규칙을 무시할 수 있다.
- 원시 포인터는 null 값이 될 수 있다.
- 여러 개의 원시 가변 포인터가 메모리의 같은 공간을 가리킬 수 있다.
- 또한 불변 포인터와 가변 포인터 모두 같은 메모리를 참조하는 데 사용할 수 있다.
- 원시 포인터가 유효한 메모리 영역을 가리킨다고 보장할 필요가 없다.
원시 포인터는 하드웨어에 직접 액세스하거나(예를 들어 디바이스 드라이버), 다른 언어로 작성된 애플리케이션과 메모리의 원시 영역을 통해 통신해야 하는 경우 유용하다.
외부 함수 호출
unsafe의 또 다른 일반적인 용도는 외부 함수 인터페이스, 즉 FFI를 통한 호출이다. 이러한 호출에서 받는 것이 러스트의 규칙을 따른다는 보장은 없으며 이러한 규칙에 부합하지 않는 것을 제공해야 할 가능성도 있다(예를 들어 원시 포인터).
러스트 설명서에서 발췌한 다음 예제를 보자.
extern "C" {
fn abs(input: i32) -> i32;
}
fn main() {
unsafe {
println!("Absolute value of -3 according to C: {}", abs(-3));
}
}
extern "C" 블록을 통해 노출된 함수에 대한 모든 호출은 unsafe로 래핑해서, 이 함수로 보내는 것과 이를 통해 받은 것에 대해 적절한 책임을 져야 한다.
가변 정적 변수 변경하기
러스트에서 전역 또는 정적 변수는 고정 메모리 주소를 점유하므로 mutable로 설정할 수 있다. 다만 가변 정적 변수는 unsafe 블록 내에서만 수정할 수 있다.
가변 정적 변수를 변경하기 위해 unsafe가 필요한 가장 큰 이유는 데이터 경합이다. 동일한 가변 정적 변수가 여러 스레드에서 수정되도록 허용할 경우 예상치 못한 결과가 발생할 수 있다. 따라서 unsafe를 사용해서 변경할 수 있지만 그에 따르는 모든 데이터 경합 문제에 대한 책임은 러스트가 아닌 unsafe를 사용한 본인에게 있다. 일반적으로 러스트는 데이터 경합을 완전히 방지할 수는 없지만 unsafe 블록에서는 이 부분에 대해 두 배로 주의를 기울여야 한다.
unsafe 메서드와 트레잇 만들기
메서드(함수)는 unsafe fn <function_name>() 선언을 통해 unsafe로 설정할 수 있다. 이를 사용하면 해당 메서드에 대한 모든 호출도 unsafe 블록 내에서 수행되도록 보장할 수 있다.
예를 들어 인수로 원시 포인터가 필요한 함수가 있다면, 애초에 호출자가 호출이 수행되는 방식을 잘 살펴보도록 하는 것이 좋다. 함수 호출 경계에서 시작하고 끝나는 안전장치는 없다.
또한 트레잇과 해당 구현도 비슷한 구문을 사용해 unsafe로 선언할 수 있다. 트레잇의 경우 unsafe trait <trait_name>, 구현의 경우 unsafe impl <trait_name> 구문을 사용하면 된다.
다만 unsafe 메서드와 달리 unsafe 트레잇 구현은 unsafe 블록 내에서만 호출되어야 할 필요는 없다. 안전에 대한 부담은 구현을 호출하는 사람이 아니라 그 구현을 만드는 사람이 짊어진다.
유니온
러스트의 유니온(union)은 C의 유니온과 본질적으로 동일하다. 즉, 내용에 대해 가능한 유형 정의가 여러 개 있는 구조체다. 이와 같은 느슨한 동작은 C에서는 허용되지만 정확성과 안전성에 대한 더 엄격한 약속이 있는 러스트에서는 기본적으로 허용되지 않는다.
그러나 C 유니온에 매핑되는 러스트 구조를 만들어야 하는 경우가 간혹 있다. 예를 들어 유니온을 다루기 위해 C 라이브러리를 호출하는 경우가 그렇다. 이를 위해서는 unsafe를 사용해서 한 번에 하나의 특정 필드 정의에 액세스해야 한다.
다음은 종합 러스트(Comprehensive Rust) 가이드에 나온 예제다.
#[repr(C)]
union MyUnion {
i: u8,
b: bool,
}
fn main() {
let u = MyUnion { i: 42 };
println!("int: {}", unsafe { u.i });
println!("bool: {}", unsafe { u.b }); // Undefined behavior!
}
유니온에 대한 각 액세스에서 unsafe를 사용해야 한다. 또한 한 번에 하나의 유니온 필드에만 액세스하려는 경우에도 차용 검사기는 유니온의 모든 필드를 차용할 것을 요구한다.
참고로 유니온에 대한 쓰기에는 이와 같은 제약이 없다. 러스트 시각에서는 추적이 필요한 항목에 쓰고 있는 것이 아니기 때문이다. 같은 이유로, let 문을 사용해서 유니온의 내용을 정의할 때 unsafe를 사용할 필요가 없다.
러스트 'unsafe'로 할 수 없는 일
위에서 다룬 4개의 주 용도 외에 unsafe가 달리 유용한 상황은 없다.가장 큰 한계는 unsafe를 사용해서 차용 검사기를 피해갈 수 없다는 것이다. 차용은 다른 모든 부분과 마찬가지로 unsafe의 값에도 여전히 강제된다. 러스트에서 절대 불변의 원칙 중 하나는 차용과 참조의 작동 방식이며, unsafe 역시 이 둘을 바꿀 수는 없다.
좋은 예는 앞에서 설명했듯이 유니온에서 차용이 여전히 강제되는 방식에서 볼 수 있다. 이 주제에 관한 더 자세한 내용은 스티브 클랩닉의 블로그를 참조하라. unsafe는 러스트의 상위 집합이라고 생각하는 것이 좋다. 즉, 기존 기능을 그대로 둔 채 몇 가지 새로운 기능을 추가해준다.
unsafe 코드 모범 사례
unsafe는 다른 언어 기능과 마찬가지로 맞는 용도와 제약이 있으므로 신중하게, 주의를 기울여 사용해야 한다. 몇 가지 중요한 내용을 간추리면 다음과 같다.'unsafe'로 래핑하는 코드는 최대한 적게
unsafe 블록은 작을수록 좋다. 많은 경우 두 줄이 넘어가는 unsafe 블록은 만들 필요가 없다. unsafe가 필요한 코드가 실제로 얼만큼인지, 이 코드에 대해 경계와 인터페이스를 어떻게 강제할 것인지에 대해 생각해야 한다. 안전하지 않은 코드에는 안전한 인터페이스를 두는 것이 최선이다.
종종 인터페이스 자체가 안전하지 않아야 하는 경우가 있다. 앞서 언급했듯이 전체 함수를 예를 들어 unsafe fn <function_name>()과 같이 unsafe로 선언할 수 있다. 함수에 대한 인수에 unsafe가 필요하다면 해당 함수에 대한 모든 호출 역시 unsafe여야 한다.
그러나 전체적으로는 개별 unsafe 블록부터 시작하고 필요한 경우에만 함수로 승격하는 것이 최선이다.
정의되지 않은 동작에 유의
정의되지 않은 동작은 러스트에 존재하므로 unsafe에도 존재한다. 예를 들어 러스트의 기본 안전장치는 데이터 경합 또는 초기화되지 않은 메모리에서 읽기에 대한 보호 기능을 제공하지 않는다. unsafe 블록에서 정의되지 않은 동작이 발생할 수 있다는 점에 특별히 주의를 기울여야 한다.
피해야 할 정의되지 않은 동작 목록은 러스트 참조에 나와 있다. 상당히 많지만 이것도 전부는 아니다.
'unsafe'가 필요한 이유를 문서화
코드의 주석은 무엇을 하는 코드인지가 아니라 왜 하는지를 설명해야 한다는 말이 있다. 이는 unsafe 블록에 절대적으로 적용된다.
가능한 모든 경우 특정 시점에 unsafe가 왜 필요한지 명확히 문서화해야 한다. 그러면 다른 사람들이 unsafe를 사용한 근거를 알 수 있고, 경우에 따라서는 앞으로 unsafe가 필요하지 않도록 코드를 다시 쓸 방법도 떠올릴 수 있다.
러스토노미콘(Rustonomicon) 읽기
러스트의 문서는 최고 수준이다. 여기에는 "안전하지 않은 러스트 프로그램을 작성할 때 알아야 하는 모든 세부 사항"을 철저하게 문서화한, 책 한 권 분량의 문서인 러스토노미콘도 포함된다. 이 문서는 "안전하지 않은" 러스트와 "일반" 러스트가 상호작용하는 방법을 상세하게 다루므로 러스트에 익숙해진 다음에 보는 것이 좋다.
C 쪽에서 건너오는 사람이라면 위험한 방법으로 러스트 배우기(Learn Rust The Dangerous Way)라는 문서도 유용하다. 이 문서 모음은 러스트의 unsafe 기능을 사용하기 위한 모범 사례를 포함해 저수준 C 프로그래밍에 익숙한 사람이 이해할 수 있는 방식으로 러스트를 설명한다.
editor@itworld.co.kr
Tags
함께 보면 좋은 콘텐츠
Sponsored
Seagate
'반박 불가' 하드 드라이브와 SSD에 관한 3가지 진실
ⓒ Getty Images Bank 하드 드라이브가 멸종할 것이라는 논쟁이 10년 넘게 계속되고 있다. 빠른 속도와 뛰어난 성능이 필요한 애플리케이션에 적합한 플래시 스토리지의 연매출이 증가하고 있는 것은 자명한 사실이다. 하지만, 클라우드의 보편화 및 AI 사용 사례의 등장으로 인해 방대한 데이터 세트의 가치가 높아지는 시대에 하드 드라이브는 플래시 스토리지로 대체할 수 없는 가치를 가지고 있다. 전 세계 엑사바이트(EB) 규모 데이터의 대부분을 저장하는 하드 드라이브는 데이터센터에서 그 어느 때보다 필수적이다. 전 세계 데이터 세트의 대부분이 저장된 엔터프라이즈 및 대규모 클라우드 데이터센터는 데이터 성장에서 핵심이 될 것이다. 하드 드라이브와 SSD를 비교하자면, 하드 드라이브 스토리지는 2022년에서 2027년 사이 6,996EB 증가할 것으로 예상되는 반면, SSD는 1,363EB 증가할 것으로 보인다. ⓒ Seagate 생성형 AI 시대에는 콘텐츠를 경제적으로 저장해야 하기 때문에 플래시 기술과 밀접하게 결합된 컴퓨팅 클러스터는 더 큰 하드 드라이브 EB의 다운스트림 수요를 직간접적으로 촉진할 것이다. 하드 드라이브가 왜 데이터 스토리지 아키텍처의 중심이 될 수밖에 없는지는 시장 데이터를 근거로 설명 가능하다. 가격 책정 근거 없는 믿음 : SSD 가격이 곧 하드 드라이브 가격과 같아질 것이다. 사실 : SSD와 하드 드라이브 가격은 향후 10년간 어느 시점에도 수렴하지 않을 것이다. 데이터가 이를 명확하게 뒷받침한다. 하드 드라이브는 SSD에 비해 테라바이트당 비용 면에서 확고한 우위를 점하고 있으며, 이로 인해 하드 드라이브는 데이터센터 스토리지 인프라의 확고한 주춧돌 역할을 하고 있다. IDC 및 포워드 인사이트(Forward Insights)의 연구에 따르면, 하드 드라이브는 대부분의 기업 업무에 가장 비용 효율적인 옵션으로 유지될 것으로 전망된다. 엔터프라이즈 SSD와 엔터프라이즈 하드 드라이브의 TB당 가격 차이는 적어도 2027년까지 6대 1 이상의 프리미엄이 유지될 것으로 예상된다. ⓒ Seagate 이러한 TB당 가격 차이는 장치 구입 비용이 총소유비용(TCO)에서 가장 큰 비중을 차지하는 데이터센터에서 특히 두드러지게 드러난다. 장치 구입, 전력, 네트워킹, 컴퓨팅 비용을 포함한 모든 스토리지 시스템 비용을 고려하면 TB당 TCO는 하드 드라이브 기반 시스템이 훨씬 더 우수하게 나타난다. ⓒ Seagate 따라서, 플래시는 특정 고성능 작업의 수행에 탁월한 스토리지이지만, 하드 드라이브는 당분간 안정적이고 비용 효율적이며 널리 채택된 솔루션을 제공하는 데이터센터에서 계속해서 주류로 사용될 것이다. 공급과 확장의 관계 근거 없는 믿음 : NAND 공급이 모든 하드 드라이브 용량을 대체할 정도로 증가할 수 있다. 사실 : 하드 드라이브를 NAND로 완전히 교체하려면 감당할 수 없는 설비투자(CapEx)가 필요하다. NAND 산업이 모든 하드 드라이브 용량을 대체하기 위해 공급을 빠르게 늘릴 수 있다는 주장은 재정적, 물류적으로 엄청난 비용이 발생한다는 점을 간과한 낙관적인 생각이다. 산업 분석기관 욜 인텔리전스(Yole Intelligence)의 2023년 4분기 NAND 시장 모니터 리포트에 따르면, 전체 NAND 산업은 2015년~2023년 사이 3.1제타바이트(ZB)를 출하하면서 총 매출의 약 47%에 해당하는 2,080억 달러의 막대한 자본 지출을 투자해야 했다. 반면, 하드 드라이브 산업은 데이터센터 스토리지 수요의 거의 대부분을 매우 자본 효율적인 방식으로 해결하고 있다. 씨게이트가 2015년~2023년 사이 3.5ZB의 스토리지를 출하하며 투자한 자본은 총 43억 달러로, 전체 하드 드라이브 매출의 약 5%에 불과하다. 그러나 NAND 산업의 경우 ZB당 약 670억 달러에 해당하는 금액을 투자한 것으로 나타나 하드 드라이브가 데이터센터에 ZB를 공급하는 것이 훨씬 더 효율적임을 알 수 있다. ⓒ Seagate 작업 부하 근거 없는 믿음 : 올 플래시 어레이(AFA)만이 최신 엔터프라이즈 작업 부하의 성능 요구를 충족할 수 있다. 사실 : 엔터프라이즈 스토리지 아키텍처는 일반적으로 디스크 또는 하이브리드 어레이, 플래시, 테이프를 사용하여 특정 작업 부하의 비용, 용량, 성능 요구 사항에 최적화할 수 있도록 미디어 유형을 혼합한다. 기업이 플래시 없이는 최신 작업 부하의 성능 수요를 따라잡지 못할 위험이 있다는 주장은 다음과 같은 3가지 이유로 반박 가능하다. 첫째, 대부분의 최신 작업 부하에는 플래시가 제공하는 성능상의 이점이 필요하지 않다. 전 세계 데이터의 대부분은 클라우드와 대규모 데이터센터에 저장되어 있으며, 이러한 환경에서는 작업 부하 중 극히 일부에만 상당한 성능이 필요하다는 파레토 법칙을 따르고 있다. 둘째, 예산 제약이 있고 데이터 세트가 빠르게 증가하는 기업들은 성능뿐만 아니라 용량과 비용의 균형을 맞춰야 한다. 플래시 스토리지는 읽기 집약적인 시나리오에서는 탁월한 성능을 발휘하지만 쓰기 작업이 증가하면 내구성이 떨어져 오류 수정과 오버프로비저닝에 추가 비용이 발생한다. 또한, 대규모 데이터 세트나 장기 보존의 경우 영역 밀도가 증가하는 디스크 드라이브가 더 비용 효율적인 솔루션일 뿐만 아니라 수천 개의 하드 드라이브를 병렬로 활용하면 플래시를 보완하는 성능을 달성할 수 있다. 셋째, 수많은 하이브리드 스토리지 시스템은 다양한 미디어 유형의 강점을 단일 유닛에 원활하게 통합하고 최대한으로 활용할 수 있도록 세밀하게 조정된 소프트웨어 정의 아키텍처를 사용한다. 이러한 스토리지는 유연성을 제공하므로 기업은 지속적으로 변화하는 요구 사항에 따라 스토리지 구성을 조정할 수 있다. AFA와 SSD는 고성능의 읽기 집약적인 작업에 매우 적합하다. 하지만 하드 드라이브가 이미 훨씬 낮은 TCO로 제공하는 기능을 AFA로 불필요하게 비싼 방법으로 제공하는 것은 비용 효율적이지 않을 뿐만 아니라, AFA가 하드 드라이브를 대체할 수 있다고 주장하는 근거가 될 수 없다.
Seagate
“작지만 큰 영향력” 하드 드라이브의 나노 스케일 혁신
ⓒ Seagate 플래터당 3TB라는 전례 없는 드라이브 집적도를 자랑하는 새로운 하드 드라이브 플랫폼이 등장하며 디지털 시대의 새로운 이정표를 세웠다. 플래터당 3TB를 저장할 수 있다는 것은 동일한 면적에서 스토리지 용량을 기존 드라이브 대비 거의 두 배로 늘릴 수 있다는 것을 의미한다. 이러한 혁신은 데이터 스토리지의 미래와 데이터센터의 디지털 인프라에 괄목할 만한 영향을 미친다. AI의 발전과 함께 데이터의 가치가 그 어느 때보다 높아졌다. IDC에 따르면 2027년에는 전 세계에서 총 291ZB의 데이터가 생성될 것으로 예측되며, 이는 스토리지 제조 용량의 15배 이상일 것으로 보인다. 대부분의 데이터를 호스팅하는 대형 데이터 센터에 저장된 데이터 중 90%가 하드 드라이브에 저장된다. 즉, AI 애플리케이션의 주도로 데이터가 급증함에 따라 물리적 공간을 늘리지 않으면서도 데이터를 저장할 수 있는 스토리지 기술 혁신이 필요하다. 데이터 스토리지 인프라를 업그레이드하는 것은 단순히 기술적인 문제가 아니라 지금 시대가 직면한 규모, 총소유비용(TCO), 지속가능성이라는 과제에 대한 논리적 해답인 셈이다. 열 보조 자기 기록(HAMR) 기술은 선구적인 하드 드라이브 기술로 드라이브 집적도 향상을 위해 지난 20년 동안 수많은 연구를 거쳐 완성되어 왔다. 씨게이트 모자이크 3+ 플랫폼은 이러한 HAMR 기술을 씨게이트만의 방식으로 독특하게 구현한 것으로, 미디어(매체)부터 쓰기, 읽기 및 컨트롤러에 이르는 복잡한 나노 스케일 기록 기술과 혁신적인 재료 과학 역량을 집약한 결정체다. 이 플랫폼은 데이터 비트를 변환하고 자기 및 열 안정성을 유지하면서 더욱 촘촘하게 패킹해서 각 플래터에 훨씬 더 많은 데이터를 안정적이고 효율적으로 저장할 수 있다. 예를 들어, 기존 데이터센터에 있는 16TB 드라이브를 30TB 드라이브로 업그레이드하면 동일한 면적에서 스토리지 용량을 두 배로 늘릴 수 있다. 더 낮은 용량에서 업그레이드한다면 상승 폭은 더욱 커진다. 이 경우, 테라바이트당 전력 소비량이 40% 감소하는 등 스토리지 총소유비용(TCO)이 크게 개선된다. 또한 효율적인 자원 할당과 재활용 재료 사용으로 운영 비용을 절감하고 테라바이트당 탄소 배출량을 55% 감소시켜 데이터센터가 지속 가능성 목표를 달성할 수 있다. 드라이브 집적도 향상은 하이퍼스케일과 프라이빗 데이터센터의 판도를 바꿀 수 있다. 데이터센터가 급증하며 전력사용량과 탄소배출량 역시 늘어나 데이터센터의 지속가능성이 화두가 되고 있는 가운데, 과학기술정보통신부는 ‘탄소중립 기술혁신 추진전략-10대 핵심기술 개발방향’에서 2030년까지 데이터센터 전력소모량을 20% 절감하겠다고 밝힌 바 있다. 이러한 목표에 발맞춰, 집적도를 획기적으로 개선한 대용량 데이터 스토리지를 활용하는 것은 원활하고 지속적인 AI 모델 학습, 혁신 촉진 및 비즈니스 성공을 위해 필수적이다. 엔터프라이즈 데이터센터의 경우 제한된 공간, 전력, 예산에 맞춰 확장할 수 있는 지속 가능한 방법을 찾아야 한다. 하드 드라이브의 집적도 혁신은 점점 더 커져가는 클라우드 생태계와 AI 시대에 대응하는 해답이자, 동일한 공간에 더 많은 엑사바이트를 저장하면서도 자원 사용은 줄이도록 인프라를 확장할 수 있는 방법이다. 이는 글로벌 데이터 영역에서 경쟁력을 유지하고 글로벌 디지털 경제의 선두주자로서 입지를 강화하는 데 매우 중요하다.
추천기사
