ZeroOS: 검증 가능한 컴퓨팅 시대를 위한 “레이어 제로”

Key Takeaways

• 현재 20개 이상의 zkVM 프로젝트들이 각각 프로그래밍 언어 툴체인을 개별적으로 포크하고 수정해야 하는 "버전 헬(Version Hell)"에 시달리고 있다. 현재의 구조는 새 버전이 나올 때마다 수정을 반복해야 하고, 보안 패치도 모든 포크에 일일이 적용해야 하므로 막대한 자원 낭비와 보안 위험을 내재하고 있다.

• 레이어제로 랩스와 스탠포드 대학교 연구진은 이에 대한 해결책으로 ZeroOS를 제안한다. ZeroOS는 각 언어의 내부를 수정하는 대신, 모든 언어가 공통으로 사용하는 시스템 콜 인터페이스 층위를 수정하는 접근법을 제안한다. 이는 zkVM을 이용하는 개발자들이 수정되지 않은 표준 툴체인을 그대로 사용할 수 있도록 해 버전 관리 부담을 제거한다.

• 모든 zkVM 프로젝트가 동일한 ZeroOS 코드를 공유하게 되면, 한 번의 보안 감사나 성능 개선이 생태계 전체에 즉시 전파되는 효과를 얻을 수 있으며, 개별 프로젝트들은 툴체인 유지보수 대신 자신만의 핵심 기술 개발에 집중할 수 있게 될 것으로 기대된다.

1. 배경 - 영지식 가상머신과 툴체인 유지보수의 지옥

2025년은 영지식 가상머신(zkVM) 프로젝트들이 실질적인 성과를 내기 시작한 해였다. 써싱트(Succinct), 바운드리스(Boundless) 등 주요 프로젝트들이 성공적으로 메인넷을 출시한 것을 시작으로, 이제는 스무 개 이상의 팀이 이 분야에서 경쟁하고 있다. (출처: Ethproofs)

하지만 이러한 발전 속에서도 아직 영지식 가상머신 생태계에는 커다란 구조적 비효율이 남아 있다. 바로 "버전 헬"이라 불리는 툴체인 유지보수의 지옥이다.

간단한 예시로 버전 헬이 발생하는 상황을 그려보자.

어떤 zkVM 프로젝트가 있다고 가정해 보자. 이 프로젝트는 개발자들이 Rust라는 프로그래밍 언어로 작성한 프로그램을 자신들의 플랫폼에서 실행할 수 있도록 지원하고 싶어한다. 언뜻 생각하면 바로 Rust 컴파일러를 가져다 쓰면 될 것 같은, 단순한 작업으로 보인다. 그러나 현실은 그렇게 간단하지 않아서, zkVM이라는 특수한 실행 환경에 맞게 Rust의 핵심 부품들을 일일이 수정해야만 한다. 마치 외국에서 수입한 가전제품의 전원 플러그를 국내 콘센트에 맞게 개조해야 하는 것과 비슷한데, 문제는 이 "개조"가 단순한 어댑터 연결이 아니라 내부 회로 자체를 뜯어고치는 수준의 작업이라는 점이다.

그렇기에 프로젝트 팀은 특정 Rust 버전(예를 들어, 버전 1.69)의 내부 코드를 복사해서 자신들만의 수정본을 만들게 된다. 여기까지는 괜찮아 보이지만, 시간이 흐르면서 진짜 문제가 시작된다. Rust는 계속 발전해서 새 버전이 나오고, 새로운 기능과 보안 수정이 추가된다. 고객들은 당연히 이 새로운 기능들을 사용하고 싶어하므로, 프로젝트는 각각의 새 버전에 대해서도 같은 수정 작업을 반복해야 한다. 여기에 또 다른 프로그래밍 언어도 지원해야 한다면, 그 언어의 여러 버전에 대해서도 동일한 작업을 해야 한다.

언어별로, 버전별로 뻗어나가는 수정본들이 기하급수적으로 늘어나고, 각각을 별도로 관리해야 하는 부담이 눈덩이처럼 커진다. 설상가상으로, 원본 언어에 심각한 보안 취약점이 발견되어 긴급 수정이 배포되면, 프로젝트 팀은 자신들이 관리하는 모든 포크 버전에 이 수정을 일일이 적용해야 한다. 이 작업이 완료되기 전까지 사용자들은 알려진 취약점에 노출된 상태로 남게 되는데, 생태계 내 거의 모든 zkVM 프로젝트가 각자 이런 상황에 처해 있으니 업계 전체로 보면 큰 자원 낭비이자 심각한 보안 위험이라고 할 수 있다.

Source: LayerZero

이러한 문제를 근본적인 수준에서 해소하기 위해 레이어제로와 스탠포드 대학교의 연구진이 협력, 2025년 12월 12일 오늘 ZeroOS를 제안했다. 각 프로그래밍 언어의 내부를 일일이 고치는 대신, 모든 언어가 공통으로 의존하는 더 깊은 곳, 즉 운영체제와 프로그램이 대화하는 창구에서 단 한 번만 수정해 그 위의 모든 언어와 모든 zkVM 플랫폼이 자동으로 혜택을 받을 수 있도록 하자는 것이다.

2. 검증 가능한 어플리케이션의 이상과 현실

ZeroOS가 왜 필요한지 더 깊이 이해하려면, 먼저 zkVM이라는 기술이 어떤 가능성을 열어주는지 살펴볼 필요가 있다.

우리가 일상에서 컴퓨터를 사용할 때, 대부분의 경우 "이 프로그램이 제대로 동작했는지"를 믿음에 의존해서 받아들인다. 은행 앱이 송금을 처리했다고 화면에 표시하면 우리는 그것을 믿는 것처럼 말이다. 이런 신뢰는 해당 프로그램을 만든 회사의 평판, 정부의 규제, 또는 단순히 "지금까지 문제없이 작동해왔으니까"라는 경험에 기반한다. 대부분의 상황에서 이 정도의 신뢰로 충분하지만, 때로는 더 강력한 보장이 필요한 경우가 있다.

영지식 증명(Zero-Knowledge Proof)은 바로 이런 상황을 위해 존재하는데, 이 기술을 사용하면 어떤 계산이 올바르게 수행되었음을 수학적으로 증명할 수 있다. 비유를 들어 설명하자면, 당신이 복잡한 수학 문제의 답을 알고 있다고 주장한다고 하자. 전통적인 방법은 풀이 과정을 처음부터 끝까지 보여주는 것인데, 이 과정에서 당신의 풀이 비법이 모두 노출된다. 반면 영지식 증명을 사용하면, 풀이 과정은 비밀로 유지하면서도 "이 사람은 확실히 답을 알고 있다"는 사실만을 상대방이 100% 확신할 수 있도록 증명하는 것이 가능해진다.

zkVM은 이러한 기술을 일반적인 컴퓨터 프로그램에 적용한 것으로, 어떤 프로그램이 주어진 입력에 대해 올바르게 실행되었음을 수학적으로 증명하는 가상의 컴퓨터라고 생각하면 쉽다. zkVM을 통해서는 프로그램을 만든 회사나 프로그램이 출력하는 결과의 무결성이 수학적으로 검증될 수 있다.

그런데 여기서 이상과 현실 사이의 간극이 등장한다. zkVM은 흔히 "일반 컴퓨터에서 돌아가는 프로그램이라면 zkVM을 통해 뭐든 증명할 수 있다"고 알려져 있지만, 이는 실제 구현 수준에서는 그렇게 간단하지 않다. 현대의 프로그램들은 실행을 위해 운영체제라는 뒷단의 조력자와 끊임없이 소통하며 동작하기 때문이다.

예를 들어 프로그램이 "메모리가 필요해" 또는 "파일을 저장해줘"라고 요청하면, 운영체제가 뒤에서 복잡한 작업을 처리해 준다. 그러나 zkVM은 본질적으로 운영체제가 없는 텅 빈 환경에 가깝기 때문에, 일반 프로그램을 그대로 가져오면 이런 요청들이 처리되지 않아 프로그램이 동작하지 않거나 중간에 멈춰버린다.

지금까지의 해결책은 각 프로그래밍 언어의 내부를 뜯어고쳐서, 운영체제에 도움을 요청하는 부분을 zkVM 환경에서 직접 처리하는 코드로 대체하는 것이었는데, 이는 앞서 언급한 버전 헬이라는 문제를 낳아왔다.

3. 문제를 푸는 지점을 바꾸다

ZeroOS의 핵심은 컴퓨터 소프트웨어가 층층이 쌓인 구조로 되어 있다는 사실에서 출발한다.

컴퓨터에서 프로그램이 실행되는 과정을 건물에 비유하면 이해하기 쉬운데, 맨 위층에는 우리가 직접 사용하는 어플리케이션이 있고, 그 아래층에는 프로그래밍 언어가 제공하는 기본 도구들이 있으며, 더 아래에는 모든 언어가 공통으로 사용하는 기초 도구들이 있고, 맨 아래층에는 운영체제가 자리 잡고 있다. 위층은 항상 아래층에서 제공하는 서비스에 의존하는 구조이다.

기존의 접근법은 각 프로그래밍 언어의 기본 도구들이 있는 층, 즉 위에서 두 번째 층에서 수정을 가하는 방식이었다. 이러한 접근법의 문제는 각 언어가 완전히 독자적인 설계와 구현을 가지고 있어서 수정 작업을 처음부터 새로 해야 한다는 점이었는데, 마치 건물의 각 사무실마다 별도의 배관 공사를 해야 하는 듯한 불편을 초래했다.

ZeroOS는 한 층 더 내려가서, 모든 언어가 공통으로 사용하는 기초 도구 층과 운영체제 사이의 경계에서 작업한다. 이 경계를 기술적으로는 "시스템 콜(syscall)" 인터페이스라고 부르는데, 쉽게 말해 프로그램이 운영체제에 무언가를 요청할 때 사용하는 표준화된 창구이다. Rust로 작성된 프로그램이든 C로 작성된 프로그램이든, 메모리가 필요하면 결국 이 창구를 통해 운영체제에 요청하게 된다. ZeroOS는 바로 이 창구에서 요청을 받아 처리하는 역할을 한다.

이 접근법의 장점은 매우 직관적이다. 앞서 언급한 배관에 대한 비유로 설명하자면, 각 사무실의 배관을 일일이 고치는 대신 건물 전체의 중앙 배관 시스템을 한 번만 설치하는 것과 같다. 중앙 시스템이 제대로 작동하면 모든 사무실이 자동으로 혜택을 받게 되는데, 게다가 이 중앙 시스템의 인터페이스는 수십 년간 안정적으로 동작해왔으며, 거의 변하지 않았다는 장점도 있다. 논문에서 인용하는 사례를 보면, 2001년에 운영체제의 메모리 관리 기능이 확장되었을 때도 기존 인터페이스와의 호환성이 완벽하게 유지되었는데, 이는 이 층위의 인터페이스가 얼마나 안정적인지를 보여주는 증거이다.

결과적으로 ZeroOS를 사용하면 수정되지 않은 표준 프로그래밍 도구들을 그대로 사용할 수 있게 된다. 새 버전이 나오면 그냥 쓰면 되고, 보안 패치가 나오면 즉시 적용된다. 버전 헬이 사라지는 것이다.

4. 필요한 부품만 골라 조립하는 운영체제

ZeroOS는 기술적으로 "라이브러리 운영체제"라는 범주에 속하는데, 이것이 무엇인지 이해하면 ZeroOS의 설계 철학이 더 명확해진다.

우리가 일반적으로 사용하는 윈도우나 맥, 리눅스 같은 운영체제는 모든 가능한 상황에 대비해서 수많은 기능을 탑재하고 있다. 네트워크 통신, 파일 관리, 화면 출력, 키보드 입력, 여러 프로그램의 동시 실행 등 상상할 수 있는 거의 모든 기능이 포함되어 있는데, 이런 방식은 범용 컴퓨터에서는 합리적이지만 zkVM 환경에서는 심각한 낭비를 초래한다.

그 이유를 이해하려면 zkVM의 독특한 비용 구조를 알아야 한다. zkVM에서 프로그램을 실행하면, 프로그램이 수행한 모든 동작이 빠짐없이 기록된다. 이 기록을 바탕으로 "이 프로그램이 올바르게 실행되었다"는 수학적 증명이 만들어지는데, 핵심은 기록이 길어질수록 증명을 만드는 데 더 많은 시간과 비용이 든다는 점이다. 따라서 zkVM 환경에서는 불필요한 동작 하나하나가 실제 금전적 비용으로 이어진다.

만약 프로그램이 순수하게 숫자 계산만 수행하고 네트워크 통신은 전혀 사용하지 않는다면, 네트워크 관련 기능이 프로그램에 포함될 이유가 없다. 사용하지 않더라도 일단 포함되어 있으면 초기화 과정에서 불필요한 동작이 기록되고, 이것이 증명 비용 증가로 이어질 수 있기 때문이다.

ZeroOS의 라이브러리 운영체제 설계는 이 문제를 모듈러하게 해결한다. 운영체제 기능을 마치 레고 블록처럼 개별 부품으로 분리해 두고, 프로그램을 만들 때 필요한 부품만 골라서 조립할 수 있게 한 것이다. 네트워크가 필요 없으면 네트워크 부품을 빼고, 복잡한 메모리 관리가 필요 없으면 단순한 버전의 메모리 관리 부품을 선택하는 식이다. 논문은 이를 "필요한 만큼만 지불하는(Pay-for-what-you-use)" 모델이라고 부른다.

이 모델의 장점은 효율성만이 아니다. 보안 측면에서도 큰 이점이 있는데, 프로그램에 포함된 코드가 적을수록 버그나 보안 취약점이 숨어 있을 곳도 적어지기 때문이다. 프로그램 개발자 입장에서는 자신이 실제로 사용하는 부품만 신뢰하면 되고, 사용하지 않는 부품에 심각한 문제가 있더라도 자신의 프로그램에는 영향이 없다는 확신을 가질 수 있다.

구체적인 수치로 이 차이를 느껴보면, 일반 운영체제에서 프로그램 실행의 기본 단위를 관리하는 데이터 구조는 300개가 넘는 정보 항목을 포함하고 있는데, 여러 사용자가 동시에 여러 프로그램을 실행하는 복잡한 환경을 관리하기 위해 필요한 것들이다. 반면 ZeroOS에서 같은 역할을 하는 데이터 구조는 단 세 개의 정보 항목만 가지고 있다. 하나의 프로그램만 실행되는 zkVM 환경에서는 나머지가 모두 불필요하기 때문인데, 이런 극단적인 단순화가 가능한 것이 ZeroOS 설계의 핵심이다.

5. 하나의 수정이 모두에게 전파되도록

ZeroOS가 가져올 가장 중요한 변화는 기술적 진보 보다는 생태계 전체의 역학 변화에 있다고 생각된다.

소프트웨어의 보안을 검증하는 작업, 즉 보안 감사는 매우 비용이 많이 드는 작업이다. 숙련된 보안 전문가가 코드를 한 줄 한 줄 검토하면서 취약점을 찾아내야 하는데, 포크된 툴체인 모델에서는 각 zkVM 프로젝트가 자신들이 수정한 코드에 대해 별도로 이 작업을 수행해야 한다. A 프로젝트가 자신들의 수정본을 감사받아도 그 결과가 B 프로젝트에는 적용되지 않는데, 수정 내용이 서로 다르기 때문이다. 업계 전체로 보면 비슷한 코드에 대해 스무 번 이상의 중복 감사가 이루어지는 셈이다.

ZeroOS 모델에서는 상황이 완전히 달라지는데, 모든 zkVM 프로젝트가 동일한 ZeroOS 코드를 공유하기 때문이다. 한 번의 감사 결과가 모든 프로젝트에 적용되고, 한 곳에서 발견된 취약점의 수정이 모든 곳에 동시에 전파된다. 논문의 표현을 빌리면, 보안의 수준이 더 이상 개별 팀이 감사에 얼마나 투자할 수 있는지에 의해 결정되지 않고, 생태계 전체가 공동으로 투자하는 자원에 의해 결정되는 것이다.

성능 개선도 마찬가지 논리가 적용된다. 누군가 ZeroOS의 메모리 관리 효율을 10% 개선하는 방법을 발견하면, 그 혜택이 ZeroOS를 사용하는 모든 zkVM과 그 위에서 동작하는 모든 프로그램에 즉시 전파된다. 스무 개 이상의 프로젝트와 그 위에서 개발되는 수많은 애플리케이션의 개발자들이 잠재적으로 이 공유된 코드에 기여할 수 있으므로, 분산되어 있던 개선 노력이 하나의 코드베이스에 집중되는 효과도 있다.

새로운 zkVM 프로젝트가 이 생태계에 합류하는 것도 훨씬 쉬워지는데, 플랫폼별로 다르게 구현해야 하는 코드가 단 하나의 함수로 최소화되어 있기 때문이다. 이 함수만 자신들의 플랫폼에 맞게 구현하면 나머지 ZeroOS의 모든 기능을 그대로 사용할 수 있으므로, 새 프로젝트는 버전 관리라는 소모적인 작업 대신 자신들만의 차별화된 기술에 집중할 수 있다.

6. 앞으로를 바라보며

새로운 기술 분야가 등장하면 초기에는 모든 것을 처음부터 만드는 시기가 있다. 경쟁이 치열하고 표준이 없으니 각자의 방식으로 같은 문제를 해결하게 되는데, 그러나 기술이 성숙해지면 어느 순간 공통 기반이 등장한다. 모든 웹사이트가 자체적으로 네트워크 통신 코드를 작성하던 시대가 지나고 공유 라이브러리가 등장한 것처럼, zkVM 생태계도 그런 전환점에 와 있는 것으로 보인다.

ZeroOS가 제안하는 것은 공유된 토대 위에서의 경쟁이다. 각 zkVM 프로젝트는 자신만의 증명 기술, 자신만의 최적화 방법, 자신만의 사용자 경험으로 차별화를 추구할 수 있지만, 프로그래밍 언어와의 호환성이라는 기본적인 문제는 함께 해결한다. zkVM 개발팀은 툴체인 유지보수의 굴레에서 벗어나 핵심 기술에 집중할 수 있게 되고, 어플리케이션 개발자는 익숙한 도구와 라이브러리를 그대로 사용할 수 있게 되며, 최종 사용자는 더 안전하고 신뢰할 수 있는 프로그램을 만나게 될 것이다.

수학적 증명으로 신뢰를 대체하는 검증 가능한 컴퓨팅의 시대가 다가오고 있다. 그 시대의 운영체제가 어떤 모습이어야 하는지에 대해, ZeroOS는 하나의 설득력 있는 답을 제시하고 있다.