바이트코드 VM은 생각보다 우리 가까이에 있어요

VM이라고 하면 뭐가 떠오르세요?

"바이트코드 VM"이라고 하면 보통 자바의 JVM이나 파이썬의 CPython 인터프리터를 떠올리실 거예요. 큰 언어 런타임의 거대한 기계 같은 이미지죠. 그런데 dubroy.com에 올라온 이 글은 "바이트코드 VM이 우리가 매일 쓰는, 언어와 전혀 상관없어 보이는 도구들 안에 숨어 있다" 는 이야기를 풀어냅니다. 읽다 보면 "아, 이것도 VM이었어?" 싶은 사례가 꽤 많아요.

먼저 바이트코드 VM이 뭔지 잠깐 정리할게요. 이게 뭐냐면, 소스 코드를 한 번에 기계어로 컴파일하는 대신, 중간 단계인 "바이트코드"라는 작은 명령어 집합으로 변환한 다음, 그 명령어를 한 줄씩 실행해주는 가상의 실행기예요. 예를 들어 "스택에 1을 올려라", "스택 위 두 값을 더해라" 같은 단순한 명령어 수십 개를 정의해두고, 프로그램을 그 명령어들의 나열로 바꿔서 돌리는 거죠. 인터프리터보다는 빠르고, 네이티브 컴파일보다는 이식성과 유연성이 좋다는 게 장점입니다.

이런 데에도 VM이 있다고요?

글에서 소개하는 첫 사례가 정규표현식 엔진이에요. 우리가 ^[a-z]+\d{2}$ 같은 패턴을 짜면, 엔진은 이걸 일종의 바이트코드로 컴파일합니다. "문자 클래스 매칭", "분기", "백트래킹 지점 기록" 같은 명령어들로요. 그리고 입력 문자열을 받으면 이 명령어들을 작은 VM이 실행해서 매칭 여부를 판단해요. Go의 regexp, Rust의 regex 크레이트, 펄과 PCRE 모두 내부적으로 이런 VM 구조를 갖고 있습니다. 1968년 켄 톰슨이 NFA 시뮬레이션을 "가상 머신"으로 구현한 게 출발점인데, 지금도 그 아키텍처가 살아 있어요.

두 번째 사례는 데이터베이스 쿼리 엔진입니다. SQLite가 대표적이에요. 우리가 SELECT 문을 던지면 SQLite는 이걸 파싱한 다음 자체 바이트코드로 컴파일해요. OpenRead, Rewind, Column, ResultRow 같은 명령어들로 이루어진 프로그램이 만들어지고, SQLite의 내부 VM이 이걸 실행하면서 행을 하나씩 토해냅니다. EXPLAIN 키워드를 붙여서 실제로 어떤 바이트코드가 나오는지 볼 수도 있어요. 이렇게 한 번 더 중간 단계를 두는 이유는, 쿼리 플래너의 결과를 명령어 시퀀스로 표현해두면 실행 시점에 인덱스나 통계 정보에 따라 유연하게 최적화할 수 있기 때문이에요.

세 번째 사례는 eBPF입니다. 리눅스 커널 안에서 동작하는 작은 가상 머신인데, 사용자가 작성한 코드를 커널 공간에서 안전하게 실행시키기 위한 장치예요. 네트워크 패킷 필터링, 시스템 콜 추적, 성능 모니터링 도구들이 모두 eBPF를 씁니다. 일반 코드를 그대로 커널에 넣으면 시스템을 박살낼 수 있으니, eBPF VM은 검증기(verifier)를 거친 바이트코드만 실행해요. 무한 루프나 메모리 침범이 없다는 걸 정적으로 증명한 코드만 통과시킵니다.

네 번째는 폰트 렌더링이에요. 의외죠? TrueType 폰트는 글자의 윤곽선뿐 아니라 작은 크기에서 글자가 흐릿하게 보이지 않도록 "힌팅(hinting)" 명령어들을 함께 담고 있어요. 이 힌팅 언어 자체가 스택 기반 바이트코드 VM이에요. FreeType 같은 폰트 렌더러는 이 VM을 구동해서 픽셀 그리드에 맞춰 글자 형태를 미세 조정합니다. 여러분이 보고 있는 화면의 한글 글자 하나하나가 작은 VM의 실행 결과인 셈이에요.

왜 사람들은 자꾸 VM을 만들까

공통점이 보이시나요? "외부에서 받은 코드를 안전하고 유연하게 실행하고 싶을 때" VM이 등장해요. 정규식은 사용자가 던진 패턴, SQL은 사용자가 던진 쿼리, eBPF는 사용자가 작성한 커널 확장, 폰트 힌팅은 폰트 디자이너가 작성한 명령어들이죠. 이런 "외부 입력 코드"를 네이티브로 컴파일하려면 보안 위협이 너무 크고, 단순 인터프리터로 돌리려면 너무 느립니다. 바이트코드 VM은 그 중간 지점에 있는 절묘한 해답이에요.

또 하나 흥미로운 건 "하드웨어와의 거리"입니다. 진짜 CPU는 너무 복잡하고 플랫폼마다 다르거든요. x86에서 만든 바이트코드가 ARM에서도 똑같이 동작하려면, 그 사이에 추상화 계층이 필요해요. VM이 그 역할을 합니다. WebAssembly가 요즘 떠오르는 것도 같은 맥락이에요. 브라우저, 서버, 엣지, 임베디드까지 한 바이트코드로 굴리고 싶다는 욕구가 만들어낸 결과물이죠.

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

이 글이 주는 가장 큰 교훈은 "VM은 거창한 게 아니라 실무에서 자주 쓰는 도구" 라는 점이에요. 직접 작은 DSL(도메인 특화 언어)을 만들 일이 생겼을 때, 인터프리터로 처리할지 바이트코드 VM으로 처리할지 고민하게 되거든요. 룰 엔진, 게임의 스킬 효과 시스템, 워크플로우 자동화 도구, 광고 타게팅 표현식, 사용자 정의 알람 조건. 이런 데서 작은 VM을 짜본 경험이 있으면 시스템 설계의 폭이 확 넓어집니다.

그리고 SQLite의 EXPLAIN이나 정규식 라이브러리의 디버그 모드를 한 번씩 열어보세요. 평소 그냥 쓰던 도구가 어떻게 동작하는지 들여다보면, 성능 문제를 만났을 때 "왜 이 쿼리가 느리지?"를 훨씬 빠르게 판단할 수 있어요. 추상화 한 꺼풀 아래를 본다는 건 시니어로 성장하는 가장 확실한 방법 중 하나라고 생각해요.

마무리

바이트코드 VM은 언어 런타임만의 것이 아니라, 코드와 데이터 사이의 경계를 안전하게 다루기 위한 보편적 도구입니다. 여러분이 평소 쓰는 라이브러리 중에 "알고 보니 안에 VM이 들어 있었다"는 사례가 또 뭐가 있을까요? 그리고 직접 작은 VM을 짜본다면 어떤 문제를 풀고 싶으신가요?