AI 코드 에디터, 메모리 최대 2배 차이

AI 코딩 에디터는 기능 경쟁이 치열하지만, 정작 매일 체감하는 것은 창이 뜨는 속도와 램을 얼마나 먹느냐다. VS 코드(VS Code)를 포크한 에디터 하이퍼레인(Hyperlane) 팀이 8월 19일 자체 측정 결과를 공개했다. 같은 조건에서 재본 결과, 시작 시간은 최대 4.85배, 상주 메모리는 2배 이상 벌어졌다.

무슨 일인가

하이퍼레인 팀은 최근 몇 번의 릴리스에서 시작 시간과 메모리를 줄이는 작업을 해왔고, 자기 위치를 확인하려고 비교 벤치마크를 만들었다고 밝혔다. 측정 대상은 자사 에디터와 VS 코드 본체, 그리고 역시 VS 코드를 포크한 커서(Cursor)·안티그래비티(Antigravity)다. 여기에 네이티브로 만들어진 제드(Zed)를 규모 비교용으로 넣었다.

주목할 점은 이 측정이 '자기 제품을, 자기가 만든 벤치마크로, 자기 기계에서' 잰 결과라는 사실을 팀 스스로 먼저 밝혔다는 것이다. 그래서 벤치마크 코드를 오픈소스로 공개했고, 글에 나온 모든 숫자는 누구나 자기 하드웨어에서 다시 만들어낼 수 있는 단일 보고서 파일에서 나온다고 설명했다. 측정 환경은 애플 M5 맥스 128GB 램·맥오에스 26.5.2이며, 버전은 하이퍼레인 v2026.08.7, VS 코드 1.133.0, 커서 3.9.16, 안티그래비티 1.107.0이다.

핵심 짚어보기

시작 시간은 프로세스가 뜬 순간부터 편집 화면이 준비됐다고 보고할 때까지를, VS 코드에 원래 들어 있는 계측 기능을 손대지 않고 그대로 써서 쟀다. 워밍업 두 번을 버리고 열 번을 측정했으며 실행마다 프로필을 새로 만들었다. 중앙값은 하이퍼레인 496.5밀리초, VS 코드 693밀리초(1.40배), 안티그래비티 1,617밀리초(3.26배), 커서 2,407밀리초(4.85배)로 나왔다. 표준편차는 대부분 4~7밀리초로 좁았지만 커서만 2,152~3,403밀리초로 실행마다 크게 흔들렸다.

메모리 측정은 조건이 더 현실적이다. 2,500개 모듈·2,605개 파일짜리 타입스크립트 저장소를 규칙적으로 생성한 뒤 각 에디터로 열고, 3분 동안 5초마다 프로세스 전체를 훑었다. 안정 구간 기준으로 하이퍼레인 2,095MB(최대 2,240MB, 프로세스 9개), VS 코드 2,779MB(최대 3,232MB, 13개), 안티그래비티 3,339MB(최대 3,785MB, 18개), 커서 4,496MB(최대 5,040MB, 25개)였다. 유휴 상태 CPU 점유는 VS 코드 0.3%, 하이퍼레인 1.8%, 커서 5.2%인데 안티그래비티만 33.4%로 크게 튀었다.

안티그래비티의 유휴 CPU 33.4%와 커서의 4.5GB 상주 메모리는, 램 16GB 노트북 한 대로 일하는 사람에게는 그 자체로 예산 문제다.

1인기업 실전 적용 포인트

• 램 16GB 기기 한 대로 일한다면 에디터 하나가 4.5GB를 붙잡는 순간 브라우저·도커·영상 렌더가 동시에 못 돈다. 커서나 안티그래비티를 계속 쓰더라도, 무거운 렌더를 걸 때는 에디터를 닫는 습관만으로 2~3GB를 회수할 수 있다.
• 자동화 스크립트를 백그라운드로 돌리는 환경이라면 유휴 CPU가 특히 중요하다. 3분 내내 코어 하나를 붙잡는 수준이면 배터리·발열·동시 실행 여력이 한꺼번에 깎인다.
• 벤치마크가 오픈소스라는 점을 활용하자. 남의 M5 맥스 숫자보다 내 노트북에서 직접 돌린 숫자가 도구 교체 판단에 훨씬 낫다.
• 시작 시간 0.2초 차이는 하루 종일 켜두는 사람에겐 의미가 없다. 교체 판단은 시작 속도가 아니라 상주 메모리와 유휴 CPU로 하는 편이 합리적이다.

전망과 주의점

이 숫자를 순위표로 받아들이는 건 위험하다. 제작사 자체 측정이고, 절대값은 기계마다 달라지며 느린 하드웨어에서는 모든 수치가 커진다. 팀 설명에 따르면 VS 코드 계열 네 종은 약 17MB 규모의 같은 편집 화면 코드를 같은 시작 경로로 돌리기 때문에, 차이는 각 포크가 그 위에 얹은 것에서 나온다. 하이퍼레인은 자사 기능을 시작 경로 밖으로 빼고 캐싱을 넣는 작업으로 앞섰다고 밝혔다.

더 중요한 한계는 측정 범위다. 이번 벤치마크는 속도와 메모리만 봤을 뿐, AI 코드 완성 품질이나 에이전트 실행 능력은 다루지 않았다. 커서와 안티그래비티가 무거운 이유 중 상당 부분이 바로 그 AI 기능이라는 점을 감안하면, 가벼움 하나로 선택을 뒤집기보다 내 작업에서 실제로 쓰는 기능값과 저울질하는 편이 맞다.

출처: 하이퍼레인 블로그 (https://hyperlaneide.com/blog/hyperlane-vs-code-cursor-antigravity-zed-benchmark)