언스테이블 빌드, IDE Rune 오픈소스 공개

그 선택의 대가는 숫자로 남아 있어요. 발표문에 따르면 Go로 쓴 Rune의 터미널은 처음에 의사 터미널 처리량에서 Alacritty와 Ghostty와 Kitty보다 100배에 가까울 만큼 느렸어요. 세 프로그램은 각각 러스트와 Zig와 C로 쓰였어요. 회사는 cgo 로 수동 메모리 관리 언어에 내려가지 않고 이 격차를 좁혔다고 밝혔어요.

방법은 네 가지였어요. 더 나은 알고리즘, 고루틴 사이의 일 분배 개선, Go 런타임 부담을 줄이기 위한 고루틴 깨우기 조절, 그리고 렌더링에 쓰던 게임 엔진에서 물려받은 초당 프레임 중심 모델을 사건 중심 모델로 바꾼 것이에요. 엔지니어 눈으로 보면 마지막 항목이 가장 크고, 화면을 일정한 주기로 계속 다시 그리는 대신 입력이 올 때만 움직이게 해서 지연을 줄인 거예요.

측정은 Alacritty 쪽이 만든 vtebench 로 했어요. 회사는 구할 수 있는 가장 빠른 노트북인 램 128GB짜리 애플 M4 맥스 맥북과, 아직도 개발에 쓰는 가장 느린 노트북인 2016년형 맥북에서 같은 시험을 돌렸어요. 느린 쪽은 저전력 모바일 인텔 코어 m3-6Y30 CPU 에 리눅스를 올린 기계예요. 첫 번째 그래프에는 iTerm2 까지 들어갔는데, 몇몇 스크롤 작업에서 나머지보다 10배에서 100배까지 느려 로그 눈금을 써야 모든 터미널이 한 그림에 들어갔어요.

회사가 스스로 그은 선도 같은 자리에 있어요. 발표문은 "이것들은 언어 벤치마크가 아니고, Go 가 러스트나 Zig 만큼 빠르다는 것을 보여 주지도 않습니다" 라고 적었어요. 대신 프로파일링과 공들인 엔지니어링으로 100배에 가까운 격차를 닫아 이 작업들에서 겨룰 만하게 만들었고, 처음 Go 를 고른 이유인 단순함과 반복 속도를 포기하지 않았다는 게 회사가 내세우는 값이에요.

왜 지금이냐는 질문에도 답이 달려 있어요. 회사는 오래전부터 열고 싶었지만 적절한 단계를 기다렸다고 했어요. 프로젝트 초기에는 작은 팀이 공개된 자리에서는 내기 어려운 밀도로 근본 설계 질문을 통과할 수 있고, IDE 는 표면적이 워낙 넓어 초기 구현 선택 하나가 실수로 API 가 되거나 호환성 약속이 되거나 구조적 제약이 되기 쉽다는 이유예요. "우리가 아직 자기 탐색 중일 때 오픈소스로 열고 싶지는 않았습니다" 라고 발표문은 적었어요.

이제 무게중심이 분명해졌다며 회사가 꼽은 항목은 여섯 개예요. 터미널이 환경의 1급 구성요소고, 콘솔은 패키지 설치와 모델 설정과 확장 및 프로세스 관리와 디버거 구동을 맡는 지속형 REPL 이에요. 명령 프롬프트 하나가 에디터 조작과 창 관리, 언어 도구, 에이전트 작업 흐름을 같은 퍼지 검색 면에서 다루고, 명령은 직접 치거나 확장이 더하거나 별칭으로 엮거나 단축키에 묶을 수 있어요. 에디터 핵심은 작게 남기고 확장은 명시적인 gRPC API 로 통신해서 Go 가 아닌 언어로도 확장을 쓸 수 있어요.

여섯 번째는 네트워크예요. Rune 인스턴스 하나하나가 사설 개발 P2P 네트워크의 노드가 되고, rune:// 라는 새 스킴으로 어디서든 자기 개발 기계의 작업 공간을 열 수 있어요. NAT 통과가 되는 범위 안에서라는 단서가 함께 붙어 있어요.

기여자 이야기가 이 발표에서 가장 낯선 대목이에요. 회사는 최근 몇 년 사이 오픈소스 진영에서 벌어진 일을 개탄스럽다고 적었어요. 공개된 자리에서 프로젝트를 키우고 사용자와 기여자의 도움을 받은 다음, 프로젝트가 값어치를 갖게 되자 라이선스를 바꾼 회사들 이야기예요. 광범위한 기여자 라이선스 계약이 그 일을 쉽게 만든다고도 지적했는데, 기여자에게 저작권을 넘기게 하거나 회사에만 재라이선스 권리를 주기 때문이에요.

Rune 은 반대로 가겠다고 했어요. GPLv3 를 유지하고 기여자는 자기 작업의 저작권을 그대로 가지며 나머지 코드와 같은 조건으로 기여해요. 언스테이블 빌드는 공동체의 작업을 나중에 독점으로 돌릴 특별한 권리를 갖지 않는다고 발표문은 못 박았어요. 그 위에 기여자가 Rune 이 만들어 내는 수입을 나눠 가질 계약상의 권리를 주겠다는 약속이 얹혔어요.

구조는 크레딧이에요. 채택된 작업이 기여 크레딧을 얻고, 적격 서비스 수입의 정해진 비율이 기여자 풀을 채우고, 그 기간에 살아 있는 크레딧 비율대로 나뉘어요. 계산은 공개적으로 감사할 수 있는 장부에 남는데 대상 수입과 허용 공제, 기여 보상, 활성 크레딧, 전체 분모, 각 배분이 모두 적혀요. 기여자가 닫힌 문 뒤에서 나온 숫자를 믿는 대신 직접 재계산할 수 있게 하겠다는 설계예요.

빠진 것도 회사가 먼저 적었어요. 풀의 비율, 어떤 서비스가 대상인지, 크레딧이 얼마나 오래 살아 있는지, 언제 지급하는지는 아직 정하는 중이에요. 참여는 선택이고 프로그램에 들어가지 않아도 GPLv3 와 DCO 절차로 기여할 수 있으며, 참여한다고 해서 직원이나 지분 보유자나 회사 구성원이 되는 건 아니라고 밝혔어요. 발표문은 "회사가 기여자에게서 특별한 권리를 얻으면서 경제적 이득은 전부 자기가 가져가서는 안 됩니다" 라는 원칙만은 이미 정해졌다고 적었어요.

앞으로 할 일 목록은 언어 지원이에요. 지금 1급으로 지원하는 언어는 Go 와 파이썬 둘이고, 러스트와 Zig 는 베타라 main 가지에서 소스로 빌드해야 써요. 회사는 표준 LSP 메서드를 넘어 rust-analyzer 기능을 rust 명령으로 꺼내 쓰고 rustup 을 콘솔에서 다뤄 환경을 벗어나지 않고 툴체인을 관리하는 것을 1급 지원의 예로 들었어요. 파이썬 확장 자체가 Go 로 쓰였다는 점도 같이 적혀 있어요.

메탈이 확인한 발표문 전문은 13분 분량으로 표시돼 있고 글쓴이 자리에는 ernestrc 라는 이름이 붙어 있어요. 메탈은 오픈AI 코덱스 CLI 가 터미널에서 도는 오픈소스 코딩 에이전트라고 보도한 바 있는데, Rune 은 터미널 옆에 에이전트를 두는 대신 에이전트 작업 흐름을 에디터의 명령 면 안으로 끌어들였어요. 발표문이 자동 프로그래밍의 등장으로 이 문제가 그 어느 때보다 중요해졌다고 적은 이유가 거기에 있어요.

오픈소스 프로젝트의 소유 구조가 흔들리는 장면은 올해 내내 이어졌어요. 메탈은 DuckLabs 가 오픈소스 DuckDB 의 지배 구조를 지키는 조건으로 AWS 에 합류했다고 보도한 바 있어요. 코드를 여는 것과 그 코드로 버는 돈을 나누는 것은 다른 문제고, Rune 은 뒤쪽에 계약서를 붙이겠다고 먼저 말한 쪽이에요.

남은 검증은 숫자예요. 풀 비율과 지급 일정이 적히기 전까지 이 약속의 크기는 알 수 없고, 장부가 실제로 열려야 재계산도 가능해져요. 코드는 열렸고 장부는 아직 열리지 않았어요.