파일시스템을 '지웠더니' 47배 빨라졌다: microsandbox의 OCI 이미지 최적화 이야기

빨리하려면 줄이지 말고, 아예 없애라

성능 최적화 글을 읽다 보면 "이걸 줄였더니 N배 빨라졌다" 같은 이야기가 흔하잖아요. 그런데 microsandbox 팀이 쓴 이 글의 제목은 좀 충격적이에요. "파일시스템을 삭제했더니 47배 빨라졌다". 어떻게 파일시스템을 통째로 없애고 컨테이너가 돌아가지? 싶은데, 읽어보면 꽤 영리한 접근이에요.

microsandbox는 코드 실행용 마이크로 가상머신을 만드는 프로젝트예요. AI 에이전트가 코드를 안전하게 실행할 수 있는 격리 환경을 빠르게 띄워주는 게 목표죠. 이런 시스템에서 컨테이너 시작 속도는 사용자 경험을 좌우하는 가장 중요한 지표예요. 사용자가 "코드 돌려줘"라고 했는데 컨테이너 부팅에 5초씩 걸리면 답답하잖아요.

OCI 이미지가 뭔지부터

잠깐 배경 설명을 좀 해야 해요. OCI(Open Container Initiative) 이미지는 컨테이너 표준 포맷이에요. Docker 이미지가 사실상 이 표준을 따라요. 이게 뭐냐면, 컨테이너가 실행될 때 필요한 파일들(운영체제 라이브러리, 애플리케이션 코드, 의존성 등)을 레이어(layer) 단위로 쌓아놓은 압축 파일 모음이에요.

예를 들어 Python 컨테이너 이미지라면, 1번 레이어에 Ubuntu 베이스, 2번 레이어에 Python 인터프리터, 3번 레이어에 pip 패키지들… 이런 식으로 쌓여있어요. 컨테이너를 시작하려면 이 레이어들을 다운받아서 풀고, 합쳐서 하나의 파일시스템처럼 보이게 만들어야 해요. 이걸 보통 overlay 파일시스템으로 처리해요.

기존 방식의 문제

microsandbox 팀이 부딪힌 병목은 바로 이 풀기 단계였어요. tar로 압축된 레이어를 디스크에 풀고, overlay로 합치고, 그걸 마이크로VM에 마운트하는 일련의 과정이 시간을 잡아먹었거든요. 작은 이미지면 괜찮은데, 큰 이미지일수록 시간이 누적적으로 늘어났어요.

또 디스크 I/O가 많이 발생하니까 동시에 여러 샌드박스를 띄울 때 디스크가 병목이 되기도 했어요. SSD가 빨라봤자 수천 개 파일을 한꺼번에 푸는 작업은 부담스럽거든요.

그래서 어떻게 "파일시스템을 없앴는가"

핵심 아이디어는 이거예요. "굳이 진짜 파일시스템을 만들 필요가 있을까?" 컨테이너 안에서 실행되는 프로세스는 파일을 읽을 때 시스템 콜(예: open, read)을 호출해요. 그러면 커널이 파일시스템을 통해 디스크에서 데이터를 가져다주죠. 그런데 이 데이터가 꼭 실제 디스크에 풀려있어야 할 이유는 없거든요.

microsandbox는 OCI 이미지의 tar 레이어를 그대로 메모리에 매핑해두고, 가상의 파일시스템 인터페이스를 통해 직접 읽도록 만들었어요. 비유하자면, 책을 다 복사해서 책상에 펴놓는 대신, 원본 책에 책갈피만 잘 꽂아두고 필요할 때 그 페이지를 펴서 읽는 거예요. 복사하는 시간이 통째로 사라지니까 시작이 빨라지는 거죠.

구체적으로는 FUSE(Filesystem in Userspace) 비슷한 메커니즘을 활용했어요. 컨테이너가 "/usr/bin/python 읽고 싶어"라고 하면, 시스템이 "그 파일은 레이어 3의 offset 12345에 있어"라고 즉시 응답하는 식이에요. 실제 디스크에 풀어두지 않고도 정상적으로 동작하는 거죠.

47배라는 숫자의 의미

물론 47배는 특정 시나리오에서의 수치예요. 모든 워크로드에서 그렇게 빨라지진 않아요. 하지만 컨테이너 부팅 시간이 수 초에서 수십~수백 밀리초로 줄어든다는 건, AI 에이전트 같은 응용에서 결정적인 차이예요.

사용자가 ChatGPT 코드 인터프리터 같은 기능을 쓸 때, 실제로는 백엔드에서 매번 컨테이너를 띄워서 코드를 돌려요. 이때 부팅이 500ms냐 50ms냐는 사용자 경험에 직격탄이거든요. 또 동시 사용자가 많아질수록 서버 비용도 달라져요. 빠른 부팅은 같은 하드웨어에서 더 많은 트래픽을 처리할 수 있다는 뜻이니까요.

비슷한 시도들

이런 "OCI 이미지를 효율적으로 다루자"는 흐름은 microsandbox만의 것이 아니에요. AWS의 Firecracker는 마이크로VM 자체를 빠르게 띄우는 방향으로 가고, gVisor는 사용자 공간 커널로 격리를 효율화해요. 이미지 측면에서는 eStargz나 Nydus 같은 lazy-pulling 포맷이 "필요한 파일만 즉시 가져오기"를 시도해왔어요.

microsandbox의 접근은 이 중에서도 "풀지 않고 그대로 쓴다"는 점에서 더 급진적인 편이에요. 호환성 문제가 좀 있겠지만, 특정 워크로드에 최적화하면 큰 이득을 보는 트레이드오프죠.

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

컨테이너 인프라를 다루는 분들에겐 영감을 주는 사례예요. "이 단계가 정말 필요한가?"를 다시 묻는 사고방식 자체가 중요하거든요. 우리가 당연하다고 여기는 "이미지를 풀고 마운트한다"는 절차도, 목적을 다시 보면 생략할 수 있는 거였어요.

AI 에이전트나 서버리스 함수, CI/CD 파이프라인처럼 컨테이너를 자주 띄웠다 내리는 환경이라면 이런 최적화의 가치가 커요. 반대로 한 번 띄우고 오래 쓰는 마이크로서비스에선 큰 의미가 없을 수도 있고요. 자기 워크로드의 특성을 알고 도구를 고르는 게 핵심이에요.

마무리

빠르게 만드는 가장 좋은 방법은 일을 적게 하는 게 아니라, 일을 아예 안 하는 거예요. microsandbox는 그 단순한 원칙을 컨테이너 부팅에 적용했고, 47배라는 결과를 얻었어요.

여러분이 다루는 시스템에서 "당연하다고 여겨서 손대지 않은 단계"가 있나요? 만약 있다면, 그게 정말 필요한지 한 번 다시 봐도 좋을 것 같아요.