열어만 두면 CPU를 쓰지 않게 만든 방법

에디터는 노트북에서 가장 오래 열려 있는 앱이에요. 하지만 실제로 글을 쓰는 시간은 길지 않아요. 대부분은 다른 일을 하는 동안 조용히 떠 있죠.

그래서 mote는 한 가지 원칙을 세웠어요.

문서가 바뀌지 않고 애니메이션도 없다면, 아무 일도 하지 않는다.

예약된 프레임도, 반복 타이머도, 주기적인 확인도 없어요. 최적화가 아니라 모든 기능보다 먼저 지켜야 하는 설계 원칙이에요.

아무 일도 없다면, 프레임도 0

CPU 사용률만으로는 앱이 조용한지 알기 어려워요. 측정할 때마다 값이 흔들리고, 반올림하면 쉽게 0이 되기 때문이에요.

그래서 mote는 프레임 수를 먼저 봐요. 창을 띄운 뒤 10초 동안 문서에 변화가 없다면, 그린 프레임은 정확히 0이어야 해요. 앱 안에서 직접 세고, 하나라도 그리면 코드가 합쳐지지 않아요.

프레임이 0이어도 안심할 수는 없어요. 보이지 않는 곳에서 스레드가 계속 깨어날 수 있으니까요. 프로세스의 모든 스레드가 초당 몇 번 깨어나는지도 함께 기록해요. 아직 기준을 쌓는 중이라 이 수치만으로 개발을 막지는 않아요.

예외는 캐럿 깜빡임뿐이에요. 반복 타이머를 쓰지 않고, 한 번 깜빡인 뒤 다음 동작을 다시 예약해요. 창이 포커스를 잃으면 바로 멈춰요. 캐럿까지 포함한 유휴 CPU 예산은 0.3%예요.

유휴 성능만 따로 보지는 않아요. 그리기를 미루면 프레임 수는 쉽게 0이 되지만, 입력한 글자가 늦게 나타날 수 있어요. 그래서 키 입력 지연, 시작 속도, 메모리를 한 번에 검사해요. 기준을 하나라도 넘으면 코드가 합쳐지지 않아요.

코드에서 한 번, 실제 기기에서 한 번

원칙은 시간이 지나면 흐려져요. 그래서 두 번 확인해요.

먼저 코드를 검사해요. 반복 타이머, 끝나지 않는 틱, 잠들었다 깨기를 반복하는 폴링, 파일 전체를 불필요하게 다시 읽는 코드를 자동으로 찾아요. 발견되면 CI가 거기서 멈춰요. 꼭 필요한 예외라면, 왜 작업이 끝나는지 코드 바로 위에 적어야 해요.

그다음 실제 기기에서 재요. 이때 네 가지 조건을 지켜요.

GPU가 있는 실제 화면에서 측정해요. 포인터는 창 밖에 둬요. 실제 세션 버스를 사용하고, 프레임은 그려지는 순간 바로 세요.

이 조건들은 실패를 겪으며 생겼어요. 포인터가 창 위에 있다는 이유만으로 유휴 프레임이 150개 생긴 적이 있었어요. 격리된 세션에서는 툴킷이 응답을 기다리느라 시작이 몇 초씩 늦어졌고요. 늦게 보고되는 프레임 카운터를 썼을 때는 시작 화면의 프레임이 유휴 구간에 섞이기도 했어요.

메모리도 절대값으로 판단하지 않아요. 툴킷과 그래픽 드라이버가 차지하는 메모리는 환경에 따라 수십 MB씩 달라지거든요.

대신 빈 문서를 기준으로 삼아요. 빈 문서보다 문서를 열었을 때 얼마나 더 쓰는지만 봐요. 최근 측정에서 빈 문서는 116MB, 100KB 문서는 120MB를 썼어요. mote가 추가로 쓴 메모리는 4MB로, 예산 8MB 안이에요.

처음부터 이렇게 잰 건 아니에요. 메모리 예산을 넘긴 줄 알았는데, 알고 보니 앱이 아니라 실행 환경의 기본 메모리가 늘어난 적이 있었어요. 그날부터 절대값 대신 ‘우리 기능이 더한 만큼’을 재기 시작했어요.

개발할 때는 살아 있는 타이머 수도 화면에 보여줘요. 0이 아니라면 커밋하기 전에 바로 알 수 있어요.

자동 저장도 이 원칙을 따라요. 문서가 바뀌었을 때만 타이머를 한 번 걸고, 저장이 끝나면 없애요. 주기적으로 깨어나 “바뀐 게 있나?” 확인하지 않아요.

경쟁자를 이기기 위한 숫자는 아니에요

처음에는 유휴 성능을 Typora보다 나은 점으로 소개하고 싶었어요. 하지만 직접 재보니 그렇지 않았어요.

같은 기기와 같은 조건에서 Typora의 유휴 CPU 사용률은 0.1%였어요. mote와 사실상 같았죠. 차이가 확인된 앱은 Obsidian 0.8%, MarkText 0.6%였어요.

잘못 적은 적도 있어요. 한동안 문서에는 “Typora는 열어두면 CPU를 쓴다”라고 적혀 있었어요. 근거로 쓴 34.6%는 Typora가 아니라 apostrophe의 측정값이었어요. 다시 확인한 뒤 문장을 바로 고쳤어요.

유휴 프레임 0은 경쟁자를 향한 주장이 아니에요. mote가 스스로 지키는 규율이에요. 반복해서 돌아가는 작업이 없다면, 앱이 지금 무엇을 하는지 언제든 설명할 수 있으니까요.

이 원칙 때문에 포기한 것도 있어요

편한 방법을 쓸 수 없을 때가 많아요.

파일이 바깥에서 바뀌었는지 주기적으로 확인하는 대신, 운영체제의 변경 알림을 받아야 해요. 수식을 웹뷰에 맡기는 대신 레이아웃 엔진을 직접 만들었어요. 애니메이션도 계속 돌게 만들 수 없어요. 모든 움직임에는 시작과 끝이 있고, 끝나면 완전히 멈춰야 해요.

배터리가 몇 시간 더 간다고 말하지는 않을게요. 측정하지 않은 숫자니까요. 우리가 확인한 건 프레임 수와 CPU 사용률, 스레드가 깨어난 횟수까지예요.

아무 일도 없을 때 아무것도 하지 않는 것.

mote에서는 기능이 아니라, 모든 기능이 통과해야 하는 원칙이에요.