Effectiveness

효용성 — 정리가 정말 빨라지게 하나?

메모리 정리 도구는 대부분 "얼마나 회수했는지"만 보여주고 그래서 빨라졌는지는 말하지 않는다. 그래서 직접 쟀다. 이 페이지는 그 결과다 — 우리 도구에 불리한 결과까지 그대로 적는다.

📊 원본 데이터·실험 설계·스크립트: docs/21 효용성 실측 · 재현 스크립트 scripts/measure/

---

결론부터

질문	답
정리하면 메모리가 실제로 늘어나나?	그렇다. 워킹셋 3.9GB가 실제로 걷혔다
그 효과가 유지되나?	아니다. 절반이 14초 만에, 4분이면 96%가 되돌아온다
평상시 주기적으로 돌리면 빨라지나?	아니다. 앱 기동 +4.3%, 파일 읽기 +12.6% 느려졌다
메모리가 빠듯할 때 미리 정리해두면?	차이 없다. 4GB 할당 소요 1,032ms → 1,020ms (오차 범위)

한 줄로: 이 도구의 가치는 "주기적 정리"가 아니라 관찰(목록·Top 5·종료)과 사용자가 판단하는 온디맨드 1회 정리에 있다. 그래서 주기 정리는 기본이 꺼져 있다.

---

왜 되돌아오나 — 걷어낸 건 "안 쓰는 메모리"가 아니었다

정리 후 5분간 5초마다 재보면 이렇게 된다.

경과	실사용 워킹셋(Active)	회복률
정리 직전	10,976 MB	—
정리 직후	7,256 MB	0%
14초	≈9,100 MB	50%
61초	10,127 MB	77%
273초	10,812 MB	96%

프로세스 하나만 따라가 보면 더 분명하다.

VS Code 워킹셋	정리 전	정리 직후	5분 뒤
	666.7 MB	39.6 MB	716.8 MB

VS Code가 쓰는 메모리가 줄어든 게 아니다. 쓰고 있던 페이지를 뺏겼다가, 필요하니까 전부 다시 읽어들인 것이다. 정리는 메모리 수요를 줄이지 못한다 — 같은 페이지를 다시 읽는 작업을 추가할 뿐이다.

---

되찾는 데 드는 값

1,200MB를 쥔 프로세스가 트림당한 뒤 그 메모리를 다시 만지는 시간을 쟀다.

상태	재접근 시간
정상	43 ms
트림 직후	414 ms (약 10배)
그다음 회차	28 ms (정상 복귀)

페이지 하나를 되찾는 건 마이크로초 단위로 싸다. 그런데 1.2GB는 30만 페이지라 합계가 0.4초가 된다. "안전하다"와 "공짜다"는 다르다.

다행히 하드 폴트는 0~1건 — 디스크는 건드리지 않았다. 페이지는 RAM 안(대기·수정 목록)에 그대로 남아 있어서, 되돌림이 전부 메모리 내 이동으로 끝났다. 60초를 방치한 뒤에도 같았다. 영역 ①(워킹셋 트림)이 안전한 기본값이라는 근거다.

---

주기적 정리를 켜면 (60초마다 · 각 10분 측정)

	정리 안 함	60초마다 정리
앱 기동 (중앙값)	316.1 ms	329.6 ms — 4.3% 느림
파일 읽기 (중앙값)	26.1 ms	29.4 ms — 12.6% 느림
벤치마크 중 하드 폴트	26건	620건 (24배)
여유 메모리(Available) 평균	6,801 MB	7,489 MB (+688MB)
정리에 쓴 CPU	0	6.1초

여유 메모리 숫자는 688MB 올라간다. 그리고 실제로 하는 일은 전부 조금씩 느려진다. 개선된 성능 지표는 하나도 없었다.

---

영역 ③을 켜면 안 되는 이유 (실측)

정리 영역 ③(전체 대기 퍼지)은 기본이 꺼져 있다. 왜 그런지 숫자로 보면:

조건	같은 파일 196.8MB 읽기	디스크에서 다시 읽은 양
정상	60.5 ms	0.1 MB
기본 정리(① ②) 직후	64.3 ms	1.7 MB
③ 켠 정리 직후	265.4 ms (4.4배)	452.8 MB

게다가 ③을 켠 쪽이 회수량은 오히려 가장 적었다(+215MB). 캐시를 버려 숫자만 키우고 체감은 깎는 전형적인 경우다. 켜지 마시라.

---

"회수 MB" 표시를 곧이곧대로 믿지 마시라

알림에 뜨는 숫자는 정리 후 Available − 정리 전 Available이다. 그런데 같은 정리 1회에서:

알림에 표시된 값	실제로 걷힌 워킹셋
+679 MB	−3,870 MB

차액 3,195MB는 수정(Modified) 목록으로 갔는데, 이건 Available에 포함되지 않아 표시에 잡히지 않는다. 표시값은 실제 일어난 일의 1/5에도 못 미친다. 반대로 영역 ③처럼 캐시를 버리는 동작은 표시값을 부풀리면서 체감은 떨어뜨린다. 즉 이 숫자는 "얼마나 빨라졌나"의 지표가 아니다.

---

그래서 어떻게 쓰면 되나

상황	권장
평상시	그냥 두시라. 주기 정리는 기본 꺼짐 — 켜지 않는 걸 권한다
무거운 작업을 막 끝냈을 때	트레이에서 [지금 정리] 1회. 판단은 사용자가
메모리를 누가 먹는지 궁금할 때	목록 창·Top 5 팝업 — 이게 이 도구의 본체다
특정 앱이 폭주할 때	목록에서 선택 종료 / 개별 회수
자동 정리	기본값(임계 90% + Windows 저메모리 이벤트) 유지 — 필요할 때만 움직인다

💡 효용이 중립인 기능이라도 비용이 0에 가까우면 해롭지 않다. 이 도구는 상주 시 1.30MB, 실행 파일 0.64MB다. 그게 이 설계의 방어선이다.

---

측정 조건과 한계

시험대 — RAM 16,085MB · 커밋 26,032MB(물리 RAM을 10GB 초과) · 여유 페이지 2.5MB · 페이지 파일이 기계식 HDD에 있음 · Windows 11 26200. 하드 폴트가 비싼 환경이라 정리에 유리한 조건인데도 이득이 나오지 않았다.

한계 — 솔직히 적는다.

1. 단일 PC · 90분 세션. 다른 구성(32GB, NVMe 페이지파일, RAM 8GB 기기)에서는 다를 수 있다.
2. 진짜 스래싱 구간은 검증하지 못했다. 측정 중 여유 메모리는 4.6~7.7GB 범위였다. 여유가 수백 MB로 떨어져 실제로 버벅이는 상황에서는 결론이 달라질 여지가 있다. (다만 그 구간에서는 Windows가 스스로 트림한다.)
3. 합성 워크로드 — 앱 기동·파일 읽기·대용량 할당. 게임 프레임 타임 같은 체감과 정확히 같지는 않다.

측정을 직접 돌려보고 싶다면 scripts/measure/의 스크립트를 그대로 실행하면 된다. 각 스크립트는 시작할 때 상주 셸을 멈추고 CSV를 남긴다.