하나의 주소 공간에서 여러 실행 파일을 돌린다 — Threadprocs가 제안하는 제로카피 IPC

프로세스 격리의 대가, 복사 비용

운영체제를 공부하면 가장 먼저 배우는 개념 중 하나가 프로세스 격리(process isolation)다. 각 프로세스는 자신만의 가상 주소 공간을 갖고, 다른 프로세스의 메모리에 직접 접근할 수 없다. 이 덕분에 하나의 프로그램이 죽어도 다른 프로그램에 영향을 주지 않는, 안정적인 멀티태스킹이 가능하다. 하지만 이 격리에는 숨겨진 비용이 있다. 프로세스끼리 데이터를 주고받으려면 반드시 IPC(Inter-Process Communication)를 거쳐야 하고, 대부분의 IPC 메커니즘은 데이터를 복사하는 과정을 수반한다.

파이프(pipe), 소켓(socket), 메시지 큐 같은 전통적인 IPC 방식에서는 보내는 쪽이 커널 버퍼에 데이터를 쓰고, 받는 쪽이 다시 자신의 버퍼로 복사해 온다. 작은 메시지라면 문제없지만, 대용량 데이터를 빈번하게 교환하는 시스템에서는 이 복사 오버헤드가 성능의 병목이 된다. 공유 메모리(shared memory)를 사용하면 복사를 줄일 수 있지만, 여기에도 한계가 있다. 공유 메모리 안의 포인터는 각 프로세스에서 다른 주소로 매핑될 수 있기 때문에, 복잡한 데이터 구조(트리, 그래프, 링크드 리스트 등)를 공유하려면 오프셋 기반으로 변환하거나 직렬화(serialization)를 거쳐야 한다.

바로 이 문제를 정면으로 공략하는 실험적인 프로젝트가 등장했다. Threadprocs는 여러 독립적인 실행 파일을 하나의 주소 공간에서 스레드처럼 실행함으로써, 프로세스 간 제로카피(zero-copy) 포인터 전달을 가능하게 하는 Linux용 시스템 프로그래밍 프로젝트다.

Threadprocs의 핵심 아이디어

Threadprocs의 발상은 의외로 단순하다. "프로세스를 분리하면 복사가 필요하고, 스레드는 같은 주소 공간을 쓰니 복사가 필요 없다. 그렇다면 독립적인 프로그램을 스레드처럼 실행하면 어떨까?" 이것이 핵심이다.

구체적으로, Threadprocs는 여러 개의 ELF 실행 파일을 하나의 프로세스 주소 공간에 로드한다. 각 실행 파일은 자신만의 독립적인 코드와 데이터를 갖지만, 메모리 주소 공간은 공유한다. 이렇게 하면 프로그램 A가 힙에 할당한 복잡한 데이터 구조의 포인터를 프로그램 B에게 그대로 넘길 수 있다. 포인터가 가리키는 메모리 주소가 양쪽에서 동일하기 때문에, 직렬화도 복사도 필요 없다.

이것이 가능한 이유는 Linux의 clone() 시스템 콜의 유연성 덕분이다. clone()은 새로운 실행 흐름을 만들 때 어떤 자원을 부모와 공유할지 세밀하게 제어할 수 있다. 일반적으로 fork()는 주소 공간을 복제하고, pthread_create()는 주소 공간을 완전히 공유하는데, Threadprocs는 이 중간 지점을 활용한다. 주소 공간은 공유하되, 각 "threadproc"은 독립적인 실행 바이너리의 코드를 수행하는 것이다.

기존 접근법과의 비교

이런 "주소 공간 공유" 아이디어가 완전히 새로운 것은 아니다. 역사적으로 몇 가지 유사한 시도가 있었다.

LRPC(Lightweight Remote Procedure Call)는 1990년대에 연구된 개념으로, 프로세스 간 호출의 오버헤드를 줄이기 위해 공유 메모리 영역을 적극 활용했다. L4 마이크로커널 계열에서도 IPC 최적화를 위해 주소 공간 공유 기법을 연구했다. 보다 최근에는 io_uring이 커널-유저 공간 간의 제로카피 통신을 가능하게 하면서 비슷한 철학을 보여주고 있다.

그러나 Threadprocs가 독특한 지점은, 기존 ELF 바이너리를 거의 수정 없이 같은 주소 공간에 로드할 수 있다는 점이다. 특별한 라이브러리를 링크하거나 소스 코드를 수정할 필요 없이, 이미 컴파일된 실행 파일을 대상으로 할 수 있다는 것이 설계 목표다. 물론 이 과정에서 심볼 충돌, 전역 변수 관리, 시그널 핸들링 등 수많은 기술적 난관이 존재하며, 프로젝트 자체도 이를 실험적(experimental)이라고 명시하고 있다.

공유 메모리(shm)와 비교하면 차이가 더 명확해진다. 전통적인 공유 메모리에서는 포인터를 직접 전달할 수 없다. 프로세스 A에서 주소 0x7fff1234에 있는 데이터가 프로세스 B에서는 0x7fff5678에 매핑될 수 있기 때문이다. 그래서 공유 메모리 안의 데이터 구조는 보통 오프셋 기반으로 설계하거나, Flatbuffers/Cap'n Proto 같은 제로카피 직렬화 포맷을 사용한다. Threadprocs에서는 이런 변환 자체가 불필요하다.

보안과 안정성 트레이드오프

당연히 이런 접근법에는 큰 트레이드오프가 따른다. 프로세스 격리를 포기한다는 것은 곧 보안 경계(security boundary)를 없앤다는 뜻이다. 같은 주소 공간에 있는 프로그램은 서로의 메모리를 읽고 쓸 수 있으므로, 하나의 프로그램에 취약점이 있으면 같은 공간의 다른 프로그램까지 위험해진다. 또한 한 프로그램의 메모리 버그(버퍼 오버플로우, use-after-free 등)가 다른 프로그램의 메모리를 오염시킬 수 있어 디버깅도 훨씬 어려워진다.

이런 이유로 Threadprocs는 범용적인 프로세스 관리 대체재가 아니라, 신뢰할 수 있는 컴포넌트들 간의 고성능 통신이 필요한 특수한 시나리오를 위한 도구라고 봐야 한다. 예를 들어 게임 엔진의 내부 모듈 간 통신, 고빈도 거래(HFT) 시스템에서의 컴포넌트 간 데이터 교환, 또는 임베디드 시스템에서의 리소스 최적화 같은 경우가 적합한 사용처일 수 있다.

이 프로젝트는 Rust로 작성되어 있으며, Rust의 메모리 안전성 보장이 주소 공간 공유의 위험성을 어느 정도 완화해줄 수 있다. unsafe 블록 사용이 불가피하겠지만, 적어도 Rust의 타입 시스템과 소유권 모델이 잘못된 포인터 전달을 컴파일 타임에 잡아줄 수 있는 부분이 있다.

한국 개발자에게 주는 시사점

이 프로젝트를 당장 프로덕션에 쓸 수 있느냐고 묻는다면, 솔직히 아직 아니다. 실험적인 단계이고, 안정성이 검증되지 않았다. 하지만 이 프로젝트가 건드리는 문제 영역 — IPC 오버헤드, 제로카피 데이터 전달, 프로세스 격리와 성능의 트레이드오프 — 은 시스템 프로그래밍에서 끊임없이 등장하는 근본적인 주제다.

특히 다음과 같은 상황에서 일하는 개발자라면 이 프로젝트의 접근법을 눈여겨볼 만하다. 마이크로서비스 간 gRPC/REST 호출의 직렬화/역직렬화 오버헤드가 병목인 경우, 대용량 데이터 파이프라인에서 프로세스 간 데이터 전달 비용이 큰 경우, 또는 게임 서버나 실시간 시스템에서 레이턴시를 극한까지 줄여야 하는 경우가 그렇다.

직접 코드를 살펴보고 싶다면 GitHub 저장소에서 ELF 로더 구현과 clone() 시스템 콜 활용 부분을 중점적으로 보는 것을 추천한다. Linux 시스템 프로그래밍의 저수준 메커니즘을 이해하는 데 훌륭한 학습 자료가 될 것이다.

마무리

프로세스 격리는 운영체제의 핵심 원칙이지만, 모든 원칙에는 예외가 필요한 순간이 있다. Threadprocs는 "격리를 의도적으로 포기하면 무엇을 얻을 수 있는가"를 실험하는 대담한 프로젝트다. 여러분이 설계하는 시스템에서 프로세스 간 통신이 병목이 된 경험이 있는가? 그때 어떤 방식으로 해결했는지 경험을 공유해주면 좋겠다.