평면이냐 분할이냐: 메모리 구조의 진짜 쟁점은 '재귀성'이다

메모리를 하나의 거대한 연속 공간으로 다룰 것인가(flat), 아니면 하드웨어가 구획을 알고 있게 할 것인가(segmented). 이 오래된 논쟁은 x86의 진화 궤적을 되짚어 보면 한쪽으로 기운 것처럼 보인다. 스티븐(humprog.org)의 블로그 글은 x86 세그멘테이션의 역사를 다시 살피면서, 286 이래 이 아키텍처의 상징이었던 세밀한 메모리 보호가 점차 약해져 왔다고 지적한다. 64비트로 넘어오면서, 그리고 그 이전에 빠른 시스템 콜 기능이 도입되면서 정교한 세그먼트 기능이 부분적으로 무력화됐다는 것이다. 필자는 그 배경으로 유닉스를 지목한다. 유닉스가 PDP-11 혹은 그 이전 PDP-7에서 물려받은 평면 주소 공간 선호가 업계를 지배하면서, '아무도' 64비트 세그멘테이션을 원하지 않게 됐다는 설명이다.

그런데 필자는 웹어셈블리(WebAssembly) 진영에서 '분할 메모리가 돌아오고 있다'는 농담을 즐겨 한다고 말한다. 웹어셈블리의 프로그래밍 모델이 평면성이 절대적이지 않았던 OS/2 같은 비(非)유닉스 계열 운영체제를 연상시킨다는 것이다. 이 관찰은 단순한 향수가 아니다. 비평면 구조는 안전성과 보안 측면에서 여전히 핵심적인 쟁점이기 때문이다.

하드웨어가 구획을 알아야 하는가

글은 FreeBSD 커뮤니티에서 잘 알려진 Poul-Henning Kamp의 논지를 인용한다. 그는 평면 메모리 모델을 '어떤 속도에서도 안전하지 않다(unsafe at any speed)'고 표현하며 CHERI를 그에 대한 반작용으로 규정했다. 핵심 관찰은 간단하다. 어떤 소프트웨어든 평면 메모리 위에서 가장 먼저 하는 일은 그 공간에 어떤 세분화 구조를 부과하는 것이라는 점이다. 그렇다면 하드웨어가 이 구획을 알아야 하는가? CHERI는 '그렇다'고 답하고, 이전의 대다수 하드웨어는 '아니다'라고 답해 왔다. 물론 세그멘테이션이라는 예외를 두긴 했지만 말이다.

필자의 진짜 통찰은 이 '예/아니오' 프레임 자체가 잘못됐다는 데 있다. 세분화는 재귀적 현상이라는 것이다. 평면 메모리에 한 번 구조를 부과하고 나면, 우리는 그 안에서 또다시 구획을 나눈다. 아레나나 메모리 풀을 떠올려도 좋고, 구조체 안의 필드, 다시 그 안의 구조체를 떠올려도 좋다. 프로그래머의 머릿속 추상은 결코 평면이었던 적이 없다. 문제는 평면이냐 아니냐가 아니라, 프로그래머가 실천하는 근본적으로 재귀적인 세분화를, 재귀적이지 않은 하드웨어와 어떻게 맞물리게 하느냐다. 하드웨어는 개념상 유한 상태 기계이고, 그 공학적 관행은 고정된 구조와 한정된 깊이를 선호한다. 초(超)CISC CPU가 마이크로코드로 약간의 반복을 제공할 수는 있어도 거기까지가 한계다.

깊이를 잘라내는 순진한 해법의 함정

이 간극을 메우는 순진한 방법은 깊이를 고정하는 것이다. 하드웨어가 N단계까지, 대개 N=1까지만 알고 나머지는 소프트웨어에 맡기는 방식이다. 하지만 필자는 이를 '하드웨어가 손을 씻는' 태도라고 비판한다. 이 방식은 불균일성을 보장하고, N이 커질수록 하드웨어가 더해줄 수 있는 가치를 잃게 만든다. CHERI는 이렇게 하지 않는다. 재귀적 분해의 유연성을 유지하되 재귀 단계는 여전히 소프트웨어가 처리한다. 경계(bounds)는 임의로 좁게 만들 수 있지만, 그 좁힘은 소프트웨어가 수행하고 명시적으로 전달한다. 그래서 특정 시점에 무엇을 주소 지정할 수 있는가는 하드웨어의 상태가 아니라, 현재 실행 중인 코드의 손이 닿는 범위로 흘러 들어온 것들, 즉 도달 가능한 케이퍼빌리티의 전이적 폐포(transitive closure)라는 소프트웨어적 창발로 결정된다.

다만 CHERI는 이 유연성을 역설적으로 하나의 제약으로 사들인다. 주소 지정은 경계가 단조적으로 좁아지는, 끊기지 않은 케이퍼빌리티 파생 연산의 사슬 위에서만 허용된다. 필자는 이 거래에 늘 불편함을 느낀다고 고백한다. 소프트웨어는 소프트웨어이기에, 어떤 프로그램은 단조적이지 않은 기묘한 주소 계산으로 제 갈 길을 가려 하기 때문이다. 수십 년간 프로그램들이 세분화된 주소 공간을 자기 방식대로 순회해 온 유산은, 더 완고한 새 하드웨어와 마찰을 일으킬 수밖에 없다. 이 마찰을 넘어서는 것은 결국 개발 노력의 문제지만, 그 비용이 업계 전반에 '성공적으로' 외부화되어 표준이 되려면 CHERI 혹은 유사한 무언가가 하드웨어 보편성을 획득해야 한다. 필자의 표현대로 이는 판돈이 큰 게임이다.

liballocs가 택한 다른 길

필자 자신의 프로젝트인 liballocs는 보안에서 한 발 물러서 있기에 주소가 어떻게 파생돼야 하는지 규칙을 강제하는 일에서 자유롭다고 말한다. 대신 실제 소프트웨어가 평면 주소 공간을 재귀적으로 세분화하며 만들어낸 구조가 무엇이든, 그것을 규범적으로 통제하기보다 서술적으로 포착하는 데 집중한다. 그 핵심에는 재귀적 추상이 있다. 할당(allocation)은 다른 할당 안에 중첩되어 트리를 이룬다. 여기에는 'N단계 컷오프'도, 하드웨어와 소프트웨어의 경계도 없다. 이것은 근본적으로 소프트웨어이며, 구현이 제각각 이질적이더라도 가능한 한 균일한 반영적(reflective) 추상으로 구조를 끝까지 포착하려 한다. 이 '동질적 인터페이스, 이질적 구현'이라는 발상은 흔히 객체지향과 연결되지, 하드웨어와는 좀처럼 엮이지 않는다.

글은 또 다른 객체지향적 대비로 마무리된다. 고전적 언어 VM 방식은 하드웨어와 정반대로 손을 놓는다. 모든 것을 거의 최대한으로 잘게 쪼개 작은 객체들과, 그 사이를 잇는 방대한 포인터 관계로 표현한다. 프로그래머 머릿속에 있을 더 굵은 단위의 구조는 머릿속에만 머물고, 시스템은 그것을 중심으로 저장소를 구조화해 주지 않는다. 그 결과 이런 시스템은 공간적 지역성마저 포기한다. 바이트나 워드를 더 큰 단위로 묶는 하드웨어의 휴리스틱을 활용하지 못하는 것이며, 이것이 오랫동안 이런 접근이 성능에서 불리했던 이유다. 한국 개발자에게 이 논의가 주는 실무적 함의는 분명하다. 메모리 안전성을 논할 때 '평면이냐 세그먼트냐'라는 이분법은 실제 프로그램의 중첩된 구조를 담아내지 못하며, 웹어셈블리든 CHERI든 차세대 실행 모델을 평가할 때는 재귀적 세분화를 시스템이 얼마나 균일하게 지원하는지를 기준으로 봐야 한다는 점이다.