가볍다는 말 대신 숫자를 공개하는 이유

마크다운 에디터는 흔히 이렇게 소개돼요.

빠르다. 가볍다. 부드럽다.

하지만 숫자에 조건이 빠지면 형용사와 다르지 않아요. 유휴 CPU를 언제, 얼마나 오래 쟀는지. 시작 시간을 어디서부터 어디까지 계산했는지. 조건이 다른 숫자는 비교할 수 없기 때문이에요.

그래서 mote가 공개하는 성능 지표를 8개로 정했어요. 각 지표에는 측정 방법과 조건, 제외 대상, 비교 규칙, 주의할 점, 예산을 기록했어요. 측정 스크립트도 하나씩 연결했고요.

문서와 결과, 코드는 모두 같은 이름을 써요. 숫자가 어디서 나왔는지 바로 추적할 수 있게요.

숫자에는 조건이 따라야 해요

mote는 네 가지 원칙을 지켜요.

모든 측정값에 값과 단위, 통계, 표본 수, 원표본을 함께 저장해요. 단위가 빠진 결과는 검사 단계에서 거부해요.

재지 않은 값은 적지 않아요. 측정할 수 없다면 이유와 함께 비워 둬요. 추정값으로 채우지 않아요.

비교는 같은 머신과 같은 세션에서만 해요. 다른 날, 다른 기기에서 나온 숫자는 나란히 놓지 않아요.

측정 조건도 숫자와 함께 공개해요. 특히 주사율과 CPU 거버너는 항상 적어요. 이 조건이 다르면 지연 시간과 시작 시간을 제대로 비교할 수 없어요.

측정법을 새로 만들지는 않았어요.

키 입력부터 화면이 바뀔 때까지의 지연은 Pavel Fatin의 Typometer가 쓴 방식 그대로예요. 앱 밖에서 키를 입력하고, 픽셀이 바뀔 때까지 확인해요. 시작 시간은 VS Code처럼 단계별로 나누고 콜드 스타트와 웜 스타트를 구분했어요.

지연은 프레임워크 안이 아니라 끝에서 끝까지 재야 한다는 원칙은 Dan Luu의 글에서 가져왔어요.

직접 같은 조건에서 비교했어요

경쟁 앱의 성능은 다른 곳의 숫자를 인용하지 않았어요. 직접 같은 노트북에서 측정했어요.

100KB짜리 같은 문서를 열고, 같은 스크립트로 앱마다 7번씩 실행했어요. 모두 인라인 편집 화면을 사용했고 포인터 위치도 같게 맞췄어요.

프로세스 전체의 메모리 사용량은 이랬어요.

• mote: 78MB
• Typora: 453MB
• Obsidian: 361MB
• MarkText: 416MB

타이핑할 때 CPU 사용량은 한 코어 기준으로 10.9%, 103%, 152%, 136%였어요. 프로세스 수는 각각 1개, 8개, 7개, 6개였고요.

mote의 메모리 사용량은 4.6배에서 5.8배 적었어요. 타이핑할 때 쓰는 CPU는 9.4배에서 14배 적었고요.

메모리는 RSS가 아니라 PSS로 계산했어요. RSS는 여러 프로세스가 공유하는 메모리를 중복해서 셀 수 있어요. PSS는 공유 메모리를 프로세스 수에 따라 나눠 계산해요. 시스템 모니터에서 보는 방식과도 같아요.

불리한 숫자도 그대로 남겼어요

앱을 열어 두기만 했을 때 CPU 사용량은 mote 0.0%, Typora 0.1%, Obsidian 0.8%, MarkText 0.6%였어요.

Typora도 유휴 상태에서는 CPU를 거의 쓰지 않았어요. 따라서 “열어 두면 아무것도 하지 않는다”는 점을 Typora보다 나은 점으로 내세울 수는 없어요.

웹 셸은 3.6%를 사용해 Typora보다 오히려 나빴어요.

앱 내부의 반복 타이머를 없애는 일은 여전히 중요해요. 하지만 지켜야 할 원칙과 경쟁 우위는 다른 문제예요.

유휴 프레임은 경쟁 앱과 비교하지 않았어요. mote의 목표는 10초 동안 0프레임이지만, 다른 앱에는 같은 방식으로 확인할 프레임 카운터가 없어요.

그래서 경쟁 앱의 칸은 비워 뒀어요. 빈칸은 0이 아니에요.

비교할 수 없다면 비교하지 않아요

파일을 열었다가 수정 없이 저장했을 때 원본이 그대로 유지되는지도 확인해요.

mote는 CommonMark 예제 652개를 검사해요. 저장소의 모든 문서도 열고 다시 저장한 뒤, 바이트 단위로 같은지 확인하고요. 하나라도 달라지면 성능 문제가 아니라 데이터 손실 버그로 봐요.

경쟁 앱의 결과는 적지 않았어요. 저장 과정을 같은 조건으로 자동화하기 어려웠기 때문이에요.

측정 전에는 머신 상태도 확인해요. 컴파일이 실행 중이면 측정을 시작하지 않아요. 브라우저는 실제로 CPU를 많이 쓰고 있을 때만 막아요. 부하 평균과 CPU 유휴율, 판단 기준, 측정 당시의 값은 모두 결과에 남겨요.

이 규칙은 실패를 겪고 나서 생겼어요.

CPU를 많이 쓰는 브라우저를 켜 둔 채 시작 시간을 쟀더니 성능이 나빠진 것처럼 보였어요. 이전 커밋과 현재 커밋을 같은 부하에서 번갈아 측정해 보니, 코드 회귀가 아니라 머신 부하가 원인이었어요.

그 뒤로 시작 시간은 절대값 하나만 보고 판단하지 않아요.

예산을 넘으면 머지할 수 없어요

성능 예산은 문서에만 적힌 목표가 아니에요. 빌드를 통과하려면 지켜야 하는 기준이에요.

기준은 hard와 report로 나눠요.

hard는 결정 문서로 숫자가 정해진 항목이에요. 하나라도 기준을 넘으면 검사가 실패해요. 별도의 예외 승인도 없어요.

report는 아직 근거가 부족하거나 플랫폼의 한계에 영향을 많이 받는 항목이에요. 값은 기록하지만 빌드를 막지는 않아요.

근거가 부족한 숫자로 빌드를 막으면 사람들은 측정 자체를 피하게 돼요. 그래서 확실한 기준만 관문으로 사용해요.

측정 스크립트와 원본 CSV, 결과 JSON은 저장소에 함께 보관해요. 같은 조건에서 같은 스크립트를 실행하면 표를 다시 만들 수 있어요. 측정 도구와 테스트 문서를 공개 벤치마크 저장소로 내놓는 일도 준비하고 있어요.

좋은 숫자만 고르는 건 공개가 아니에요.

무엇을 어떻게 쟀는지, 어떤 조건이었는지, 무엇은 재지 못했는지까지 함께 보여 주는 것. mote가 숫자를 공개하는 방식이에요.