Tachyon 프로젝트가 "커널을 거치지 않는 56ns 크로스언어 IPC"를 내세우며 설계 문서를 공개했다.1 핵심은 단순히 빠른 IPC 하나가 아니라, 프로세스 간 통신에서 시스템 콜과 커널 중재를 최대한 밀어내고, 공유 메모리와 사용자 공간 동기화로 지연을 극단적으로 줄이겠다는 접근이다.
왜 지금 이게 중요할까. 요즘 병목은 네트워크보다 "같은 머신 안에서 서로 다른 런타임이 얼마나 빨리 말할 수 있느냐"로 옮겨가는 경우가 많다. Python 서비스와 Rust 엔진, JVM 기반 분석기처럼 언어가 섞인 시스템이 흔해졌기 때문이다. 이때 IPC 비용은 생각보다 크고, 같은 데이터를 한 프로세스 안에서 처리할 때보다 두세 자릿수 비싸질 수 있다.2
56ns의 본질은 "IPC를 메시징이 아니라 메모리 문제로 본다"는 점이다
일반적인 IPC는 파이프, 유닉스 도메인 소켓, 메시지 큐, RPC처럼 커널이 중간에서 복사·스케줄링·권한 중재를 맡는 구조가 많다.2 이런 방식은 안전하고 범용적이지만, 아주 짧은 메시지를 매우 자주 주고받는 상황에서는 커널 진입 자체가 비용이 된다. 커널과 사용자 공간이 분리되어 있는 이유는 보호와 자원 관리에 있지만, 그 경계는 곧 지연의 원인이기도 하다.34
Tachyon이 강조하는 56ns는 이 경계를 가능한 한 덜 넘는 설계의 결과로 읽는 게 맞다.1 즉 "메시지를 보낸다"기보다, 서로 다른 프로세스가 같은 메모리 구조를 안전하게 바라보게 만들고 최소한의 신호만 교환하는 쪽에 가깝다. 이런 발상은 새롭지 않다. IPC에서 shared memory가 가장 빠른 축에 속한다는 점은 오래전부터 알려져 있었다.25 새로운 점은 이를 크로스언어 환경에서 일관된 런타임 인터페이스로 밀어붙였다는 데 있다.
실무적으로는 이것이 중요하다. 초저지연 시스템에서 병목은 네트워크가 아니라 직렬화, 복사, 락 경합, 캐시 라인 충돌인 경우가 많다. IPC를 "운영체제 기능 호출"이 아니라 "캐시 친화적인 메모리 프로토콜"로 재설계하면 숫자가 급격히 달라질 수 있다.
하지만 "커널 우회"는 무료 점심이 아니다
여기서 가장 큰 오해는 "커널을 안 거치면 무조건 낫다"는 생각이다. 아니다. 커널은 느리게 만들려고 있는 게 아니라, 격리·권한·공정한 스케줄링·장애 격리를 제공하려고 있다.3 그 기능을 덜 쓰겠다는 말은, 일부 책임을 애플리케이션과 런타임이 떠안겠다는 뜻이기도 하다.
대표적인 부담은 세 가지다.
첫째, 동기화가 어려워진다. 공유 메모리는 빠르지만, 잘못 쓰면 busy loop, stale notification, 순서 보장 실패 같은 문제가 생긴다. Xen vchan 기반 IPC를 직접 구현한 사례에서도 이벤트 처리 방식 하나 때문에 100% CPU 루프가 생겼고, 동적 도메인 ID와 권한 관리가 별도 문제로 드러났다.6
둘째, 언어 경계를 넘는 메모리 모델이 까다롭다. "크로스언어 IPC"는 단순히 C ABI만 맞춘다고 끝나지 않는다. 각 언어의 소유권, GC, 정렬, 원자성 규칙이 다르기 때문이다. 성능 수치가 좋더라도 데이터 레이아웃 제약이 커지면 범용 시스템에선 도입 장벽이 높아진다. 이 부분은 공개 문서로 확인 가능한 범위와 실제 운영 난이도를 구분해 봐야 한다.1
셋째, 수치는 환경 의존적이다. 락프리 링 버퍼 같은 구조는 캐시 배치, 코어 핀ning, C-state, 하이퍼스레딩, 인터럽트 설정에 크게 흔들린다.7 56ns가 인상적인 수치인 것은 맞지만, 그것이 모든 서버와 워크로드에서 재현된다는 뜻은 아니다. 여기서 확인된 사실은 "특정 설계와 조건에서 매우 낮은 지연이 가능하다"는 것이고, "일반적인 IPC의 새 표준"이라고 단정하긴 이르다.
도입 판단 기준은 "평균 처리량"보다 "지연 예산"이다
이런 기술이 맞는 곳은 분명하다. 고빈도 거래, 실시간 추론 파이프라인, 멀티프로세스 게임 엔진, 언어별 마이크로컴포넌트를 한 머신에 붙여 쓰는 시스템처럼, 로컬 IPC가 전체 지연 예산의 큰 비중을 차지하는 경우다.
반대로 웹 백엔드의 일반적인 서비스 간 호출, 장애 격리와 관측성이 더 중요한 업무 시스템이라면 유닉스 소켓이나 gRPC, 혹은 단순 shared memory + 표준 동기화 정도가 더 현실적일 수 있다.2 커널 우회형 IPC는 대개 성능을 위해 디버깅 편의성과 범용성을 일부 포기한다.
그래서 판단 기준은 간단하다. "빠른가?"보다 먼저 "내 병목이 정말 커널 경계인가?"를 물어야 한다. 직렬화가 더 큰 문제인지, GC stop-the-world가 더 큰 문제인지, 스케줄링 지터가 더 큰 문제인지부터 확인해야 한다. 그 다음에야 56ns 같은 숫자가 의미를 가진다.
결국 이번 이야기는 초저지연 IPC 기술 자체보다, 소프트웨어 경계가 다시 얇아지고 있다는 신호로 보는 편이 정확하다. 같은 머신 안에서 여러 언어를 섞어 쓰면서도 단일 프로세스에 가까운 통신 비용을 원한다면 지금부터 관심을 가질 만하다. 다만 그 대가가 무엇인지--메모리 규약, 운영 복잡성, 재현 가능한 벤치마크 조건--까지 함께 볼 수 있을 때만 좋은 선택이 된다.
참고
1Bypassing the kernel for 56ns cross-language IPC
2Inter-process communication - Wikipedia
3Kernel (operating system) - Wikipedia
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.