asciinema CLI 3.0, Rust로 재작성되어 라이브 스트리밍 및 파일 포맷 업그레이드 제공

(blog.asciinema.org)

10P by GN⁺ 1일전 | ★ favorite | 댓글 2개

터미널 녹화 도구 asciinema CLI 3.0이 Rust로 전면 재작성되어, 파일 포맷 업그레이드 및 터미널 라이브 스트리밍 기능이 추가됨
Rust 채택으로 정적 바이너리 제공과 빠른 시작 시간, AVT 통합으로 동시성·시스템 호출 처리가 쉬워지고 신규 기능 구현 기반 확보
새 asciicast v3 포맷은 이벤트 인터벌(델타) 기반 타이밍, term 하위 메타데이터 구조화, "x" 종료 이벤트, # 라인 주석을 도입해 편집성과 표현력을 높임
라이브 터미널 스트리밍은 로컬 내장 서버와 원격 릴레이(자체 호스팅/공식 서버) 두 모드로 제공되며, 네트워크 상황에 따라 적응형 버퍼링으로 부드러운 뷰잉 경험을 제공
기본 철학을 Local-first로 재정비하여 rec는 파일명을 필수로 받고 업로드를 분리(upload <파일>), 자체 서버 선택 프롬프트로 셀프 호스팅 친화성과 의도치 않은 데이터 유출 방지 강화

3.0 출시: Rust로 재작성된 asciinema CLI와 주요 개선점

asciinema CLI 3.0이 공식적으로 출시
이번 버전에서는 전체 코드가 Rust로 재작성됨과 동시에 레코딩 파일 포맷이 업그레이드
터미널 세션 라이브 스트리밍 등 다양한 기능들이 추가/개선됨

Rust 재작성과 전반적 개선

CLI를 Rust로 전면 재작성하여 개발자 경험과 유지보수성을 높였으며, 정적 바이너리 배포로 설치 경로 단순화, 시작 속도 향상, 기능 확장성 확보
- 시스템 호출과 동시성 처리가 Python 대비 용이하다는 저자의 경험을 바탕으로 선택했으며, asciinema virtual terminal(AVT) 를 CLI에 통합해 신규 기능 구현이 가능해졌음
결과적으로 성능·배포·아키텍처 측면에서 향후 기능 추가의 토대를 마련함

asciicast v3 파일 포맷

asciicast v3 파일 포맷으로 진화하며, 기존 v2에서 드러난 여러 단점을 보완함
v2의 절대 타임스탬프를 간격(인터벌/델타) 기반 타이밍으로 교체하여 이벤트 삽입·삭제 시 후속 타임스탬프 일괄 조정 문제를 해소
헤더를 재구성하여 터미널 관련 메타데이터를 term 키 아래로 그룹화하고, 세션 종료 상태 저장을 위한 "x"(exit) 이벤트를 지원
파일 내 라인 주석(#) 을 허용해 가독성과 관리 용이성 향상
예시 스니펫 제공으로 구조와 이벤트 스트림 구성을 직관적으로 제시함
신규 포맷은 asciinema server, asciinema player 에서 이미 지원됨

라이브 터미널 스트리밍

로컬 모드: 내장 HTTP 서버로 동일 네트워크에서 시청 가능한 스트림 제공, 데이터가 시청자 브라우저로만 전달되는 프라이버시 우선 모드
- CLI에 최신 asciinema player가 번들되어 즉시 재생 가능하며, 방화벽 포트 개방이 필요할 수 있음
원격 모드: asciinema server(공식 또는 자가 호스팅)를 릴레이로 사용해 공유 가능한 URL로 스트림을 배포
- 두 모드를 동시에 사용할 수 있어 상황에 맞는 배포 구성이 가능
플레이어는 실시간 네트워크 지연 측정 기반의 적응형 버퍼링으로 낮은 지연과 버퍼 언더런 방지를 균형화
서버는 스트림 자동 녹화를 지원하며, 현재 asciinema.org 운영 서버는 녹화 비활성·동시 1개 스트림 제한 정책을 운용 중
- 셀프 호스팅 시 기본적으로 녹화 활성·동시 스트림 제한 없음

Local-first로의 회귀

과거 asciinema rec는 업로드 동작이 기본 경로에 포함되어 무의식적 공개·정보 누출 위험이 있었음
- 2.4에서 업로드 전 선택 프롬프트를 도입해 전환을 준비했으며, 3.0에서 파일명 필수·rec의 업로드 기능 제거·upload <파일> 명시적 명령으로 분리함
기본 철학을 로컬 우선으로 명확히 하여, 사용자가 의도를 갖고 공개/공유를 결정하도록 흐름을 재설계함
- 로컬 전용 사용이 완전 지원되며, 필요 시에만 명시적으로 퍼블리시함

셀프 호스팅 친화성 강화

upload/stream/auth를 처음 사용할 때 서버 URL 선택 프롬프트를 표시, 기본값을 asciinema.org로 제시하되 사용자 의도에 따른 인스턴스 선택을 저장함
- 기존에도 설정 파일/환경 변수로 지정 가능했으나, 대화형 환경(신규 VM·Dev 컨테이너 등) 에서 수월한 지정이 가능해짐
이는 셀프 호스팅 사용성을 높이는 동시에, 원치 않는 외부 업로드 방지라는 추가 안전장치 역할을 수행함

배포와 이용 안내

각 배포판 패키지 리포지터리 반영까지는 시간이 소요될 수 있음
그 사이 GNU/Linux·macOS용 사전 빌드 바이너리를 GitHub 릴리스에서 내려받아 사용하거나, 소스에서 빌드 가능함
릴리스 노트와 상세 변경 이력은 GitHub의 release notes 및 CHANGELOG 문서에서 확인 가능함

▲

xguru 1일전 [-]

3.0이 예전에 나오지 않았나? 해서 검색해보니 2021년에 Player를 Rust로 재작성하면서 4배 작고 50배 빨라질꺼라고 예고했던 글이었네요

Asciinema - 터미널 화면을 녹화하고 공유
Asciinema 3.0 - 4배 작고, 50배 빠르게

답변달기

▲

GN⁺ 1일전 [-]

Hacker News 의견

Asciinema는 정말 멋진 도구임, 나는 TerminalTextEffects 데모를 모두 캡처할 때 사용함, Asciinema GIF Generator(AGG)가 asciicast 파일을 고품질 터미널 GIF로 변환해줌, 그래서 TerminalTextEffects 저장소나 문서에 데모를 쉽게 올릴 수 있음
raw 파일 출력이나 termsvg 류의 방법은 stdout에 엄청난 데이터가 출력되기 때문에 TTE에 맞지 않음
AGG 문서와 TerminalTextEffects 저장소 링크를 참고하면 좋음
- 서버 motd나 스타트업 메시지를 매번 랜덤한 TTE로 꾸며서 넘길 때마다 즐거움을 느끼는 중임
  내가 만든 예시는 여기에서 볼 수 있음
- 이 프롬프트 효과는 진짜 아름다움, 쓸 데가 있든 없든 그냥 계속 만들었으면 좋겠음, 넋을 잃게 보는 중임
  TTE는 오래 전 Compiz 윈도우 매니저에서 처음 리눅스를 쓰게 만든 그 환상적인효과가 터미널에서 구현된 느낌임
  TTE를 tmux나 vim에 스크린 세이버처럼 간헐적으로 적용하는 방법이 궁금함, 파이프로 연결해야 하는지, alias로 쓰는 게 나은지 등 고민이 있음
  보통 어떻게 쓰고, 제작할 때는 어떤 용도였고 지금은 어떻게 활용하고 있는지 궁금함
  계속해서 발전시켜주었으면 하는 바람임
- t-rec도 굉장히 유용한 툴임, 원하는 윈도우를 녹화해서 비디오나 gif로 만들 수 있음
  완전히 같진 않지만, 단순히 터미널 gif를 빨리 공유하려면 t-rec가 더 쉬운 경우도 있음
- 15MB짜리 GIF 파일은 도저히 감당이 안 됨
  탐색도 불가능하고, 텍스트 선택도 불가, 15배의 대역폭 낭비까지 감수해야 함
  부드럽게 압축되고, 탐색 쉽고, 접근성 높은 텍스트를 가장 끔찍한 형식의 비디오로 옮기는 건 너무 아쉬움
  최소한 raw asciinema 파일이나 웹뷰어로의 링크도 같이 주면 좋겠음, 그러면 짧은 시간에 불러오고, 멈춤/탐색/복사-붙여넣기까지 다 가능함
  루프만 빠르게 도는 GIF는 만든 사람 외엔 의도가 거의 전달되지 않음
asciinema.org 사이트가 너무 인기가 많아 현재 트래픽 폭주 현상임, btop 스트림이 연결된 서버의 CPU 점유율이 무려 95%임
해당 스트림 예시는 여기에서 볼 수 있음
그래도 BEAM 위에 올린 Elixir/Phoenix 서버는 많은 요청과 CPU 사용에도 무난하게 서비스 중임 — 이것이 바로 BEAM의 힘임
현 시점에서 2GB RAM짜리 VM 2대만으로도 버티지만, 조만간 확장할 필요를 느낌
- 모든 인프라가 클라우드로 쏠리는 시대에 이렇게 유명한 서비스가 단 두 대의 2GB VM에서 안정적으로 돌아가는 모습이 놀라움
  요즘 중급 노트북의 램보다도 적은 자원임에도 원활함
- 인프라를 바로 확장한 결과, 다시 안정적이고 반응도 좋아진 상태임
- 현재 btop 스트림이 심하게 끊기고 CPU 점유율도 0% ~ 100% 사이에서 계속 급변함
  혹시 서비스가 계속 크래시 후 재시작 중인지 궁금증이 있음
- BEAM이여 영원하라!
- 팁을 주자면 btop의 새로고침 주기를 줄이는 게 좋을 것 같음, 100ms로 돌리면 btop이 CPU를 많이 쓰게 됨
Asciinema 클라이언트가 Python → Golang → Python → Rust로 계속 바뀜
변천사 문서와 관련 블로그도 참고 가능함
- 이런 프로젝트는 어떤 언어로 구현해도 딱히 상관 없을 것 같음, 모든 언어가 비슷한 성능을 내기 때문임
  코드베이스가 작다보니 어떤 언어로 옮겨도 기능적 영향이 미미해서, 개발자가 동기부여되는 언어로 계속 재작성해도 무방하다고 생각함
- 흥미로운 점임
  Go의 문제점 대부분은 코드를 쓰기도 전에 미리 파악할 수 있어야 한다고 생각함, 단순 조사만 했어도 packaging 이슈 같은 것들은 2016년에 정당한 불만이었으나 Go 모듈로 이후 해결됨
  그 후에는 ClojureScript, Elixir, Rust로 계속 재작성하는 건 기술 트렌드 쫓기라는 느낌을 지울 수 없음
  이런 잦은 언어 교체는 엔지니어링 신뢰도를 떨어뜨림
Asciinema에 애정을 갖고 있으며, 작은 기여와 기부를 통해 프로젝트를 후원함
기부 안내와 리눅스 시스템 문제 해결에 Asciinema가 어떻게 보일지 (사드서버스 리플레이)도 한 번 확인해보길 추천함
Asciinema는 내가 사용해 본 도구·제품 중에서 단연 최고임
CLI로 인증/업로드하는 플레이가 깔끔하고 직관적이라, 여러 번 단계를 거쳐야 해도 절대 불편함이 없음
다른 CLI에서도 비슷한 설계가 있긴 하지만 Asciinema는 방해받는 느낌이 전혀 없었음
정말 멋진 성과임을 축하함
다만 asciinema가 SVG나 GIF로 바로 저장하는 기능이 내장되면 좋겠다는 바람임
별도의 변환 앱 없이도 마크다운 파일에 삽입할 수 있게 되니까 사용성이 더욱 좋아질 것임
Asciinema의 열렬한 팬으로서 이번 작업이 정말 멋지다고 생각함
라이브 스트리밍 기능 관련해서는, 내가 공동 창업자인 s2.dev의 스트림 위에 비슷한 것을 해킹해서 올린 적이 있는데, 이런 구조라면 중간 릴레이 없이도 가능할 것 같음
개인적으로 btop을 실시간으로 보여주는 게 멋졌음
라이브 스트리밍 구조 참고는 이 문서가 도움될 것임
터미널 실시간 스트리밍 기능이 도입된 만큼, 누군가 ASCII 아트 vtuber 아바타를 터미널 위에 오버레이로 얹어주면 재밌을 것 같음
- Max Headroom v0.2를 떠올리게 하는 아이디어임
내가 가장 좋아하는 elixir 프로젝트인 asciinema가 이제 Rust로도 재작성됨
이 발전이 정말 마음에 듦
혹시 명령어에서 시크릿, 키 같은 민감 정보를 자동 정제/감시하는 기능도 추가했는지 궁금함, 요즘은 가벼운 LLM도 많으니 이전보다 더 쉬워졌을 것 같음
- CLI는 Rust로 재작성되었지만 서버는 여전히 Elixir/Phoenix 임, 이 부분은 민감 정보 필터링 같은 기능에 딱 맞는 구조임
- 예전엔 Python으로 먼저 만들어지지 않았었는지 궁금함
- 명령어에서 시크릿/키 자동 필터링 기능 문의는 혹시 농담이 아닌지 의문임
트위치 스트리머들이 보통 두 대의 컴퓨터로 방송을 하는 이유는 하나는 방송 화면을 보여주는 용, 다른 하나는 OBS와 HDMI 캡처를 돌리기 위함임
Asciinema의 새로운 라이브 스트리밍 기능을 활용한다면, 콘솔(terminal)에서만 작업하는 개발자라면 HDMI 캡처기 없이도 dev 머신의 터미널 화면을 OBS 머신으로 바로 스트리밍할 수 있을 것 같음
아주 소수의 프로그래밍 스트리머에게는 Asciinema 3가 진정한 대안이 될 수 있을 것임
- Asciinema 스트리밍이라면 성능에 영향이 거의 없어서 이런 듀얼 장비 구성은 필요 없음
  2PC 세팅이 태동된 건 x264 인코딩의 CPU 부하 때문이었으나, 요즘은 GPU로 인코딩(Nvidia NVENC)하면 부담이 거의 없어짐
  OBS x264는 오프라인 녹화용(유튜브 영상 등)이 아니면 필요 없어짐
- 트위치 스트리머들이 2PC를 쓰는 이유는 GPU를 많이 쓰는 게임 방송 시 리소스 충돌을 막기 위함임
  또, 게임 도중 드라이버 크래시가 스트림에 영향을 미치는 걸 방지함
- 이런 방송 장비 세팅은 대부분 영상 인코딩 부하 분산 용도여서, 콘솔에서만 작업하는 프로그래밍 스트리머라면 굳이 필요 없다고 생각함

답변달기