- jq 문법 그대로 Markdown을 질의·필터·변환하는 Rust CLI ‘mq’가 등장 — LLM 워크플로우 가공에 특히 강하다
- Linear가 밀리초 만에 반응하는 비결은 서버가 아니라 브라우저 안 IndexedDB와 로컬 우선 동기화 엔진이다
- V8도 Node도 없이 TypeScript를 LLVM 네이티브 바이너리로 직접 컴파일하는 ‘Perry’가 화제다
숫자가 먼저 눈에 띈다. Linear는 빌드 파이프라인을 다시 짜며 전송 코드를 50% 줄였고, 메모리 사용량은 70~80%까지 떨어뜨렸다. Perry는 런타임 계층을 통째로 걷어내 수 MB짜리 바이너리와 1초 미만 콜드 스타트를 노린다. mq는 jq가 JSON에서 하던 일을 Markdown으로 옮겨 한 줄 명령으로 문서를 가공한다. 오늘 GeekNews 인기글에서 고른 세 가지는 공통적으로 ‘더 적게, 더 빠르게, 더 가깝게’라는 엔지니어링 본능을 향하고 있다.
Markdown을 jq처럼 다룬다, CLI 도구 ‘mq’
JSON엔 jq, 이제 Markdown엔 mq
mq는 jq와 유사한 문법으로 Markdown 문서를 질의·필터링·변환하는 CLI 도구다. JSON 세계에서 jq가 맡던 역할을 그대로 Markdown으로 옮겨, 문서를 구조화된 데이터처럼 슬라이스하고 필터링하고 매핑하며 배치 처리할 수 있다. Rust로 구현됐고 MIT 라이선스로 공개됐다.
입출력 포맷이 넓다. 입력은 markdown, mdx, html, csv, json, toml, xml, yaml을, 출력은 table·grep·json 등을 지원하며 파일 확장자나 -I 플래그로 자동 파싱한다. 셀렉터도 직관적이다. 헤딩은 .h(1..3), 특정 언어 코드 블록은 .code(“rust”), 링크 URL은 .link.url로 추출하고, section::section(“Installation”)처럼 제목 기준 섹션 단위 추출도 된다. mq conv를 쓰면 Excel·Word·PDF를 Markdown으로 변환한 뒤 Unix 파이프로 이어 붙여 처리할 수 있다.
개발 편의 기능도 갖췄다. REPL, LSP, VSCode 확장, 디버거(mq-dbg)를 제공하고, 설치 없이 브라우저에서 돌려보는 Playground와 WebAssembly 빌드(mq-web)도 있다. Elixir, Python, Ruby, Java, Go 바인딩까지 제공돼 파이프라인에 끼워 넣기 쉽다.
Tech Insight — 진짜 의미는 LLM 시대의 가공 도구라는 점이다. LLM이 Markdown을 기본 입출력 형식으로 쓰면서 프롬프트와 응답을 잘라내고 합치고 분류하는 작업이 잦아졌다. jq를 아는 개발자라면 학습 곡선이 거의 없이, 문서 관리와 콘텐츠 분석을 셸 스크립트 한 줄로 자동화할 수 있다.
Linear는 왜 이렇게 빠른가
서버가 아니라 브라우저 안에 데이터베이스가 있다
이슈 관리 도구 Linear의 체감 속도 비결을 분석한 글이 화제다. 핵심은 UI가 읽는 실제 데이터베이스가 서버가 아니라 브라우저의 IndexedDB에 있다는 점이다. 변경은 로컬에 먼저 적용된 뒤 서버로 비동기 전송되고, 서버는 WebSocket으로 다른 클라이언트에 델타만 브로드캐스트한다. 사용자는 자신의 변경을 보려고 네트워크를 기다리지 않으므로 스피너가 사라진다.
렌더링도 정밀하다. IndexedDB 데이터를 MobX 객체 풀로 수화하고, 모든 모델 속성을 개별 observable로 두기 때문에 한 필드 변경은 그 필드를 읽는 컴포넌트만 다시 그린다. 이슈 50개가 바뀌어도 목록 전체가 아니라 50개 셀만 리렌더링된다. 부팅도 IndexedDB에서 바로 수화하므로 이슈 1만 개 워크스페이스가 100개짜리와 거의 같은 속도로 뜬다.
첫 로드 최적화 수치가 인상적이다. 빌드 파이프라인을 Parcel, Rollup, Vite, Rolldown 순서로 다시 쓰면서 전송 코드 50% 감소, 압축 후 크기 30% 감소, 콜드 캐시 로드 10~30% 개선, Safari에서 active-issues 뷰 첫 페인트 59% 단축, 메모리 70~80% 절감을 얻었다. 최적화 뒤에도 21MB의 minified JS를 수백 개 라우트 청크로 쪼개고, modulepreload와 서비스 워커로 약 1,200개 asset을 백그라운드 프리캐시해 로그인 화면에 머무는 몇 초 사이 앱 전체를 캐시에 넣는다. 결과적으로 오프라인에서도 이슈 읽기·생성·편집이 동작한다.
Tech Insight — 대부분의 앱은 Linear처럼 자체 동기화 엔진을 만들 필요가 없다. 글쓴이도 TanStack Query나 SWR의 낙관적 업데이트만으로 상당히 근접한 체감을 낼 수 있다고 본다. 속도는 단일 기술이 아니라 로컬 데이터베이스, 낙관적 쓰기, 세밀한 observable 세 축이 맞물린 시스템 전체의 속성이다. 한편 Hacker News에서는 “실제로 매일 쓰면 검색이 느리고 둔탁하다”는 반론도 적지 않아, 아키텍처 이상으로 수년간의 디테일 관리가 관건임을 보여준다.
TypeScript를 런타임 없이 네이티브로, ‘Perry’
V8도 Node도 걷어낸 Native-First 컴파일러
지금까지 TypeScript는 JavaScript로 트랜스파일한 뒤 V8이나 JavaScriptCore 같은 무거운 JIT 런타임(Node.js, Bun, Deno) 위에서 돌리는 방식이 당연했다. Perry는 이 런타임 모델을 통째로 걷어내고 TypeScript 코드를 독립 실행형 네이티브 바이너리로 직접 컴파일하는 것을 목표로 하는 Rust 기반 Native-First 컴파일러다.
동작은 이렇다. SWC로 TS 코드를 파싱하고 LLVM 인프라를 통해 타겟 플랫폼의 머신 코드로 직접 빌드한다. V8 엔진도 Electron도 JVM도 없는 런타임 제로 구조다. 하나의 TypeScript 코드베이스로 macOS, iOS, Android, Linux, Windows 바이너리를 만들고, AssemblyScript 같은 ‘TS 비슷한 별도 언어’가 아니라 strict mode 기반의 온전한 TypeScript 생태계를 지향한다. 바이너리는 수 MB 수준, 콜드 스타트는 1초 미만에 가깝고, SwiftUI·GTK4·WinUI 같은 네이티브 GUI 결합은 물론 자체 React 렌더러로 JSX 작성도 된다.
한계도 분명하다. 객체에 런타임으로 필드를 주입하거나 프로토타입을 변형하는 동적 JS 스타일은 정적 컴파일 특성상 지원하지 않고, 결정론적인 TS 서브셋 위에서 동작한다. Node.js 내장 모듈은 hyper·rustls·tokio 등 Rust 생태계로 에뮬레이션 중이며 Fastify 일부 컴파일에는 성공했지만, Express처럼 동적 임포트가 얽힌 라이브러리와의 100% 호환은 아직 알파 단계 과제다. 사용법 자체는 perry compile src/main.ts -o myapp 한 줄로 극도로 단순하다.
Tech Insight — 웹에 갇혀 있던 TypeScript를 시스템 프로그래밍과 초경량 네이티브 앱 영역으로 끌어내려는 흐름의 한 갈래다. tsc의 Go 포팅, Bun의 단일 실행 파일에 이어 ‘네이티브 TS’ 실험이 늘고 있다. 아직 알파라 프로덕션에 바로 쓰긴 이르지만, 콜드 스타트와 배포 크기가 중요한 CLI·엣지·데스크톱 영역에서 TypeScript의 선택지가 넓어진다는 신호로 지켜볼 만하다.
관련 글
- mdq – 마크다운을 위한 jq
- sq – 데이터베이스 및 기타 기능을 위한 jq 대체제
- Linear가 나를 로컬-퍼스트 rabbit hole로 이끌었음
- SyncKit – 실시간 협업 앱을 위한 타입세이프 동기화 엔진
- Spinel – Ruby AOT 네이티브 컴파일러
출처
- mq – jq 스타일 Markdown 쿼리 언어 (mqlang.org)
- Linear는 어떻게 이렇게 빠른가? 기술적 분석 (performance.dev)
- Perry – TypeScript 네이티브 컴파일러 (github.com/PerryTS)
- GeekNews 오늘의 인기글 (news.hada.io)
AI Biz Insider · Tech Digest · aibizinsider.com
댓글 남기기