터미널 에뮬레이터를 새로 만들려는 개발자가 가장 먼저 부딪히는 벽은 화면 렌더링이 아니라 그 아래에 깔린 코어다. VT 이스케이프 시퀀스를 해석하는 상태 기계, 문자 격자(grid)와 스크롤백 버퍼, 선택과 검색, 그리고 Sixel·Kitty·iTerm2 같은 이미지 프로토콜까지. 이 부분은 수년에 걸쳐 다듬어야 제대로 동작하는 영역이지만, 대개 특정 앱의 렌더러나 설정과 뒤엉켜 있어 다른 프로젝트가 재사용하기 어렵다. Rust로 작성된 터미널 Rio가 0.5 버전에서 내놓은 답은 이 코어를 앱에서 완전히 떼어내 독립적으로 임베드할 수 있는 두 개의 계층으로 나눈 것이다. 순수 Rust 크레이트인 rio-vt와 이를 감싼 C ABI인 librio다.
코어를 앱에서 떼어내다
핵심 발상은 단순하다. 터미널 기능이 필요한 대부분의 프로젝트는 완성된 터미널 앱 전체가 아니라 그 엔진만 원한다. rio-vt는 아무 기능 플래그 없이 빌드하면 렌더러도, GPU 의존성도, 폰트 셰이핑 라이브러리도 끌어오지 않는다. 말 그대로 터미널 엔진 그 자체만 남는다. 동작 방식도 실제 터미널이 하는 그대로다. 바이트를 밀어 넣고 격자 상태를 다시 꺼내 읽는다. PTY도, 렌더러도, 별도 스레드도 필요 없는 단순한 루프다. rio-vt는 아무것도 직접 그리지 않기 때문에, 꺼낸 격자를 어떤 렌더러와 짝지을지 혹은 아예 렌더링하지 않을지는 전적으로 사용하는 쪽이 결정한다.
이미지 프로토콜 처리 방식이 이 설계 철학을 잘 보여준다. Sixel, Kitty, iTerm2 방식의 이미지 전송은 코어가 디코딩한 뒤 이벤트 형태로 프런트엔드에 넘긴다. 프런트엔드는 다른 모든 상태를 기록하듯 이미지 전송도 동일한 방식으로 기록하면 된다. 헤드리스 환경, 즉 화면이 전혀 없는 상태에서도 Kitty 그래픽 프로토콜 전송을 그대로 포착할 수 있다는 점은 이 엔진이 렌더링과 얼마나 깔끔하게 분리돼 있는지를 드러낸다.
librio와 더티 로우(dirty-row) 방식
librio는 이 엔진을 작은 C ABI로 감싼 계층이다. 엔진을 만들고, 내부적으로 PTY를 띄우는 서피스(surface)를 생성하고, 거기에 데이터를 쓴 다음, 어떤 행이 바뀌었고 각 셀이 무엇을 담고 있는지 알려주는 렌더 상태를 꺼내는 구조다. 네이티브 Swift나 C로 만든 프런트엔드가 소비하는 표면이 바로 이것이며, 셀 단위로 정확히 대응된다. 여기서 핵심은 '바뀐 행만 알려주는' 더티 로우 렌더 상태다. 소비하는 쪽은 터미널이 변경됐다고 표시한 셀만 다시 그리면 되고, 이스케이프 시퀀스를 단 하나도 직접 구현할 필요가 없다. 이 방식 덕분에 GPU 없이 CPU만으로 렌더링하는 것이 현실적인 선택지가 된다.
크로스 플랫폼 지원도 C ABI의 이점을 그대로 살린다. 동일한 ABI가 macOS, 리눅스, 윈도우에서 빌드되고 실행되며, 각 플랫폼의 PTY(윈도우에서는 ConPTY)를 통해 실제 셸을 띄운다. 주목할 대목은 이것이 실험적 프로젝트가 아니라는 점이다. rio-vt는 이미 Lovable 같은 기업의 프로덕션 환경에서 실제 터미널 워크로드를 처리하는 데 쓰이고 있다. 코어를 별도 크레이트로 분리한 것도 단순한 정리 차원이 아니라, 다른 제품들이 Rio가 쓰는 것과 같은 엔진 위에서 무언가를 만들 수 있게 하려는 의도였다.
벤치마크는 참고하되 직접 돌려보라
성능 수치를 두고 개발자는 스스로 여러 조건을 붙였다. 벤치마크는 까다롭고, 이 측정 도구가 다루지 않는 영역에서는 rio-vt가 부진할 것이 분명하다는 것이다. 측정에 쓴 워크로드는 모든 코드 경로를 훑는 인위적 구성이 아니라 사용자들이 실제로 가져온 프로덕션 사례에 기반한다. 공개된 rio-vt-benchmark는 doy의 vt100 파서, alacritty_terminal과 rio-vt를 같은 워크로드로 비교한다. 바이트 스트림을 화면으로 파싱하고, 채워진 화면을 다시 직렬화하고, 크기를 조정하는 작업을 80x24 고정 크기에서 수행한다. 수치는 애플 실리콘 맥에서 측정한 Criterion 중앙값이다.
결과는 일방적 승리가 아니다. rio-vt는 대부분의 입력 형태에서 파싱이 더 빠르고, 특히 평범한 아스키 글자(ascii_plain)나 전체 화면 재출력(alt_screen_redraw)에서 격차가 크다. 화면 직렬화는 여러 배 빠르고, 줄바꿈된 라인을 리플로우하면서도 크기 조정은 두 경쟁자보다 훨씬 빠르다. 참고로 vt100은 리플로우를 하지 않아 화면을 줄일 때 내용이 잘리고, alacritty는 리플로우는 하지만 이 항목에서 두 자릿수 배 느리다. 반대로 vt100은 SGR 스타일이 자주 바뀌는 sgr_churn에서 앞서는데, rio-vt의 셀별 스타일 인터닝(interning)이 단순한 방식보다 비용이 크기 때문이다. 유니코드 넓은 글자(unicode_wide)는 alacritty가 가져간다. 엔진마다 트레이드오프가 다르며, 벤치마크를 공개한 이유가 바로 이 지점에 있다. 개발자 자신도 스크롤백이 8천~1만 줄을 넘어가는 큰 규모나 리사이즈에서는 libghostty가 rio-vt를 앞설 것으로 예상한다고 밝혔다.
한국 실무자에게 주는 의미
국내에서도 웹 IDE, 클라우드 개발 환경, AI 코딩 도구 안에 터미널을 심으려는 시도가 늘고 있다. 이런 상황에서 rio-vt와 librio는 검증된 VT 코어를 처음부터 다시 짜지 않아도 되는 선택지를 제공한다. 특히 C ABI를 통해 네이티브 macOS 앱이든 윈도우 앱이든 같은 엔진을 붙일 수 있고, 더티 로우 방식 덕분에 무거운 GPU 스택 없이 CPU 렌더링만으로도 실용적인 성능을 낼 수 있다는 점은 리소스 제약이 있는 데스크톱·임베디드 환경에서 특히 매력적이다. 다만 벤치마크가 프로덕션 사례에 특화돼 있고 대용량 스크롤백 등 일부 영역은 아직 측정되지 않았다는 한계는 분명히 인지해야 한다. 도입을 검토한다면 공개된 벤치마크를 자신의 워크로드로 직접 돌려 보고, 스타일 변경 빈도나 유니코드 처리 같은 실제 사용 패턴에 맞는지 확인하는 편이 안전하다. 어떤 엔진이 우월한가보다, 내 워크로드에서 어느 트레이드오프가 유리한가를 따지는 것이 이 도구를 제대로 쓰는 방법이다.