63 MB: 브라우저가 아닌 Mac 코드 편집기가 쓰는 메모리

편집기는 절대 종료하지 않는 앱입니다. 브라우저와 메일 클라이언트와 화상 회의 뒤에서 하루 종일 켜진 채, 아직 끝맺지 못한 문장을 붙들고 있습니다. 얼마를 쓰든 그 비용은 하루 내내 발생하고, 하필 당신이 무언가를 컴파일하려던 바로 그 기계 위에서 발생합니다.

그래서 추측하는 대신 MeatPad 을 직접 측정했습니다. 다른 모든 것이 그대로 돌아가는 평범한 작업용 Mac에서 말이죠.

숫자

세 가지 상황, 한 대의 기계, 하루 오후:

MeatPad 0.10.2 · macOS 26.5.2 · Apple silicon

노트 창만 열어 둔 채 19시간 경과        63 MB    최고 83 MB
2,721개 파일 프로젝트, 탭 6개         108 MB    최고 131 MB
6.3 MB 텍스트 파일 한 개             1500 MB    아래 솔직한 절 참고

VS Code 1.130.0, 같은 폴더, 같은 파일 6개
                                      710 MB    프로세스 8개 합계

중요한 것은 가운데 줄입니다. 그것이 실제 작업 상태이기 때문입니다. 진짜 저장소를 열고 파일 트리, 탭 여섯 개, 구문 강조, 프로젝트 전체 검색, 자동 완성이 모두 살아 있는 상태입니다. 108 MB에서 안정되고 그대로 유지됩니다. 131 MB의 최고치는 프로젝트를 처음 훑으며 자동 완성용 식별자 색인을 만드는 과정이고, 그 메모리는 곧바로 반납됩니다.

VS Code 줄은 대조를 위한 것이지 판정이 아닙니다. 사용자 데이터 디렉터리를 새로 만들고 확장 프로그램은 하나도 설치하지 않은 채, 같은 폴더와 같은 파일 여섯 개를 열고 실행 1분 뒤에 측정했습니다. VS Code는 MeatPad보다 훨씬 많은 일을 하고, 그 차이의 상당 부분은 많은 사람이 당연히 원하는 확장 생태계입니다. 이 비교는 바닥값에 대한 것이지 승패에 대한 것이 아닙니다.

직접 확인하되, 잘못된 숫자를 조심하세요

이 문제에서 Mac의 두 도구는 서로 다른 말을 하고, 옳은 쪽은 하나뿐입니다. MeatPad가 63 MB라고 알리던 바로 그 순간, ps 는 같은 프로세스에 대해 147 MB라고 했습니다:

$ ps -o rss= -p $(pgrep -x MeatPad)
  150304

$ footprint -p $(pgrep -x MeatPad)
    phys_footprint: 63 MB
    phys_footprint_peak: 83 MB

레지던트 세트 크기는 프로세스에 매핑된 모든 페이지를 셉니다. AppKit, SwiftUI, CoreText를 비롯한 시스템의 공유 읽기 전용 copy-on-write 페이지까지 포함해서요. 그 페이지들은 Mac 전체에서 한 번만 상주하며 누구에게도 청구되지 않습니다. 물리적 풋프린트는 그 프로세스가 실제로 책임지는 부분만 세고, 활성 상태 보기의 메모리 열에 나오는 숫자도 이것입니다. 누군가 네이티브 Mac 앱의 메모리 수치를 말한다면, 둘 중 어느 쪽을 측정했는지 물어보세요.

이유 하나: 프로세스 안에 브라우저가 없다

MeatPad는 네이티브 앱입니다. Swift, AppKit, SwiftUI로 작성했고 자체 프레임워크 패키지를 포함해 소스 92개 파일, 약 1만 5천 5백 줄입니다. Chromium도, JavaScript 런타임도, Node 프로세스도, 플러그인 호스트도, 번들 안에 넣은 UI 툴킷 사본도 없습니다.

첫 100메가바이트의 비밀은 사실상 이것이 전부입니다. 웹 스택 위에 만든 편집기는 출근할 때 브라우저를 데리고 가야 하고, 브라우저는 자기 주장이 뚜렷한 운영체제입니다. 자체 레이아웃 엔진, 자체 가비지 컬렉터, 창마다 하나씩의 프로세스, 모든 것의 자체 사본. 당신의 코드를 한 글자 그리기도 전에 이미 그 값을 다 치른 상태입니다. 네이티브 앱은 레이아웃 엔진과 텍스트 엔진과 툴킷을 기계에서 빌려 씁니다. Finder를 위해 이미 올라와 있던 것들이죠.

이유 둘: 편집기는 눈에 보이는 줄만 배치한다

편집기가 조용히 어긋나는 지점이 텍스트 배치입니다. 스크롤 막대의 높이를 맞추겠다고 긴 문서의 모든 줄을 정확한 글꼴과 너비로 측정하는 일은, 아직 아무것도 보여 주지 않은 상태에서 하기에는 지나치게 큰 작업입니다.

MeatPad는 TextKit 2 위의 STTextView로 그립니다. Apple의 현행 텍스트 스택이고, 보이는 영역을 기준으로 동작합니다. 화면에 있는 조각과 그 조금 너머만 배치하고, 벗어나면 다시 잊습니다. 파일을 연다는 것은 읽어서 한 화면을 그리는 일입니다. 나머지 문서의 비용은 그곳까지 스크롤할 때로 미뤄지고, 멀어지면 반납됩니다.

이유 셋: 노트는 메모리 속 데이터베이스가 아니라 디스크 위의 파일

모든 노트는 평범한 텍스트 파일이고, 그 옆에 작은 JSON 파일이 하나 있을 뿐입니다. 앱은 작업 공간을 메모리에 올려놓고 그 안에서 살지 않습니다. 실제로 열어 둔 문서만 자기 텍스트를 들고 있고, 창을 닫으면 돌려줍니다.

같은 감각이 프로젝트 기능 전반에 흐릅니다:

• 파일 트리는 먼저 한 단계만 얕게 읽어 창을 즉시 그리고, 준비가 되면 전체 트리로 바꿔 넣습니다.
• 프로젝트 전체 검색은 검색하는 순간에 디스크에서 파일을 병렬로 읽습니다. 검색과 검색 사이에 메모리에 남아 있는 영구 색인은 없습니다. 디스크는 빠르고, 당신의 프로젝트는 그렇게 크지 않으니까요.
• 자동 완성 색인은 파일 내용 대신 파일별 식별자 빈도를 저장하고, 4메가바이트가 넘는 파일은 건너뜁니다.
• 구문 강조는 tree-sitter입니다. C로 작성된 작은 파서로, 열린 문서마다 구문 트리 하나를 두고, 입력할 때마다 다시 만드는 대신 증분으로 갱신합니다.

이유 넷: 비싼 지능은 다른 프로세스에 산다

편집기의 지능은 정말로 비쌉니다. 언어 서버는 프로젝트 전체의 의미 모델을 들고 있고, 큰 Rust나 Swift 코드베이스에서는 그 모델이 편집기가 텍스트로 하는 모든 일을 압도합니다.

MeatPad는 그 일을 직접 떠안지 않습니다. 이미 당신의 기계에 설치된 서버, 즉 SourceKit-LSP, rust-analyzer, Pyright와 Language Server Protocol로 대화합니다. 각각은 자기 프로세스에서 돌고, 프로젝트를 열면 시작되고 닫으면 사라집니다. 의미 모델의 비용은 그 서버에 청구되고, 활성 상태 보기에 서버 자신의 이름으로 표시되며, 프로젝트를 닫는 순간 회수됩니다. 편집기가 들고 있는 것은 메시지이지 모델이 아닙니다. 설치된 서버가 없으면 자동 완성은 열린 프로젝트의 식별자로 대체되고 나머지는 그대로 동작합니다.

위의 숫자들이 편리한 숫자가 아니라 정직한 숫자인 이유도 여기에 있습니다. 기능을 빼서 다른 프로세스로 밀어내 숨겼기 때문에 낮은 것이 아닙니다. 메모리를 많이 필요로 하는 부분이 자기 메모리를 가질 수 있게 되어 있어서 낮은 것입니다.

이 설계가 물어뜯는 지점

그 표의 세 번째 줄은 오타가 아닙니다. 6.3 MB짜리 텍스트 파일 하나, 약 12만 9천 줄을 열면 MeatPad는 1기가바이트를 넘기고 코어 하나를 붙잡습니다.

원인은 텍스트 엔진이 아닙니다. 그쪽은 광고한 그대로 동작합니다. 원인은 상태 표시줄입니다. 상태 표시줄은 문서의 줄 수, 단어 수, 글자 수를 보여 주는데, 인터페이스가 배치될 때마다 텍스트 전체를 훑어 세 가지를 모두 다시 계산합니다. 노트나 소스 파일이라면 몇 킬로바이트를 훑는 일이라 아무도 눈치채지 못합니다. 12만 9천 줄에서는 배치할 때마다 6메가바이트의 텍스트를 통째로 훑게 되고, 인터페이스는 아주 자주 다시 배치됩니다.

고치는 일은 작습니다. 그릴 때마다가 아니라 텍스트가 바뀔 때 한 번만 세면 되고, 이미 대기열에 올라가 있습니다. 이를 빼놓지 않고 여기에 적는 이유는, 좋은 측정치만 나열하는 메모리 글은 광고이기 때문입니다. 편집기가 실제로 열게 되는 일상적인 파일은 앞의 두 줄 안에 들어갑니다. 아주 큰 단일 파일은 아직 남은 영역이고, 그것을 고치는 일은 우리 몫입니다.

이 일이 오후 한나절을 들일 가치가 있는 이유

팔리는 Mac 대부분은 메모리가 16 GB이고, 1기가바이트를 남겨 두고 사는 사람은 거의 없습니다. 브라우저에는 탭이 서른 개, 디자인 도구는 열려 있고, 무언가는 컴파일 중입니다. 편집기가 붙들고 있는 메모리는 컴파일러가 쓸 수 없는 메모리이고, 그것이 바닥나면 macOS는 압축과 스왑을 시작합니다. 사용자에게는 모든 것이 한꺼번에 조금씩 나빠지는 느낌으로 다가옵니다.

시스템 프레임워크를 빌려 쓰고, 보이는 것만 배치하고, 문서를 파일 그대로 두고, 언어 서버를 각자의 프로세스에서 돌리는 네이티브 앱은 아무도 특별히 최적화하지 않아도 63 MB 언저리에 도착합니다. 영웅적인 엔지니어링 이야기가 아닙니다. 브라우저부터 만들지 않은 데서 나온 평범한 결과입니다.