1990년 워드는 1MB로 돌았습니다. 2026년 날씨 앱은 1GB를 씁니다

작업 관리자를 켰다가 화가 난 적 있으신가요. 아무것도 안 했는데 램 사용량이 12GB를 넘어가고, 목록을 훑어보니 날씨 앱이 수백 MB를 먹고 앉아 있는 그 장면 말입니다. 이 불만은 몇 년째 반복되는 클리셰였는데요. 2026년에는 조금 다르게 읽힙니다. 램값이 진짜로 올랐거든요.

미리 밝혀두자면, 이번 주제는 최근 30일 내 커뮤니티 데이터가 거의 잡히지 않았습니다. 리서치에서 확인된 신규 스레드는 0건입니다. 그래서 특정 벤치마크 수치를 확정해 전하는 대신, 오래된 논쟁이 왜 하필 지금 다시 아픈지를 짚어보려 합니다.

숫자로 보면 황당한 비교

1990년 MS 워드 1.1은 플로피 디스크 몇 장에 담겼습니다. 실행에 필요한 램은 1MB 남짓이었고요. 문서 편집, 서식, 인쇄, 맞춤법 검사까지 다 들어 있었습니다.

36년이 지난 지금, 화면에 기온 숫자 하나와 구름 아이콘을 띄우는 앱이 그보다 1000배 많은 메모리를 씁니다. 기능이 1000배 늘었냐고 물으면 대답이 궁색해집니다. 늘어난 건 애니메이션 배경과 광고 슬롯, 뉴스 피드, 그리고 그걸 다 굴리는 브라우저 엔진입니다.

물론 공정하게 짚을 부분도 있습니다. 요즘 앱은 4K 해상도를 다루고, 유니코드 전체를 지원하고, HTTPS로 통신하고, 백그라운드에서 위치를 갱신합니다. 1990년 워드는 그중 어느 것도 하지 않았습니다. 하지만 이 차이가 세 자릿수 배수를 정당화하지는 못합니다.

범인은 대체로 웹뷰입니다

요즘 데스크톱 앱은 상당수가 알고 보면 브라우저입니다. Electron이든 WebView2든, 안에서 돌아가는 건 크로미움 엔진이죠. 앱 하나를 켠다는 건 사실상 탭 하나짜리 크롬을 하나 더 띄우는 일입니다.

왜 이렇게 만들까요. 개발사 입장에선 계산이 명확합니다. HTML과 자바스크립트를 아는 개발자는 넘쳐나고, 코드 한 벌로 윈도우와 맥과 웹을 동시에 커버할 수 있습니다. 네이티브로 각 플랫폼마다 따로 만들면 인건비가 세 배로 뜁니다.

게으름이 아니라 계산입니다. 문제는 그 절약분이 개발사 장부에 남고, 비용은 사용자 램에 청구된다는 점입니다. 경제학에서 말하는 전형적인 외부효과입니다. 비용을 만든 쪽과 부담하는 쪽이 다릅니다.

그동안은 그럭저럭 넘어갔습니다

지난 20년간 이 외부효과가 크게 문제되지 않은 이유가 있습니다. 램이 계속 싸졌거든요.

2000년대 초 512MB가 사치였다면, 2010년대엔 8GB가 기본이 됐고, 2020년대엔 16GB가 표준이 됐습니다. 소프트웨어가 뚱뚱해지는 속도보다 하드웨어가 싸지는 속도가 빨랐습니다. 그래서 개발자는 “요즘 램 싸잖아요"라는 말로 논쟁을 종료할 수 있었습니다.

이 말에는 앤디와 빌의 법칙이라는 오래된 농담까지 붙어 있습니다. 앤디 그로브가 준 것을 빌 게이츠가 가져간다. 인텔이 성능을 올려놓으면 마이크로소프트가 그만큼 소프트웨어를 무겁게 만든다는 뜻입니다.

그런데 2026년, 전제가 깨졌습니다

AI 붐이 메모리 시장을 뒤집어놨습니다. 데이터센터가 HBM과 고용량 D램을 빨아들이면서, 일반 소비자용 램 가격이 몇 년째 내리기는커녕 오르고 있습니다. 노트북 제조사가 기본 사양 올리기를 망설이는 이유도 여기 있습니다.

전제가 바뀌면 결론도 바뀝니다. “램은 계속 싸진다"를 깔고 짠 설계 판단이 이제 유효기간을 넘겼습니다. 8GB 노트북을 쓰는 사람에게 날씨 앱 하나가 500MB를 요구하는 건, 램이 반값이던 시절과는 전혀 다른 무게의 요구입니다.

여기에 로컬 AI까지 얹힙니다. 온디바이스 모델을 돌리려면 수 GB의 메모리가 통으로 필요합니다. 시스템 램을 두고 경쟁하는 상대가 하나 더 늘어난 셈이죠. 브라우저 엔진 여섯 개가 백그라운드에서 놀고 있으면 그 경쟁이 제법 빡빡해집니다.

그래도 반론은 있습니다

이 논쟁에서 개발자 쪽 반박도 들어볼 만합니다.

일단 작업 관리자 숫자를 곧이곧대로 믿으면 안 됩니다. 요즘 OS는 남는 램을 캐시로 적극 씁니다. 다른 앱이 메모리를 달라고 하면 상당 부분은 도로 회수됩니다. 1GB를 점유한다고 해서 1GB를 버리는 건 아닙니다.

사용자가 지갑으로 투표한 결과이기도 합니다. 가볍고 기능 적은 앱과 무겁고 예쁜 앱을 놓고 시장은 대체로 후자를 골라왔습니다.

네이티브로 다시 짜자는 말도 대개 남의 인건비로 하는 소리입니다. 그 앱을 실제로 유지보수하는 팀에게는 현실적인 선택지가 아닐 수 있고요.

다만 이 반박이 “그래서 개선이 불가능하다"는 뜻은 아닙니다. 같은 웹 기술 스택으로도 메모리 사용량을 절반으로 줄인 사례는 계속 나옵니다. 하려면 할 수 있는데 우선순위에서 밀린 것에 가깝습니다.

진짜 질문은 청구서입니다

소프트웨어 비만 논쟁이 20년째 결론이 안 나는 이유는 이게 기술 문제가 아니라 비용 배분 문제라서입니다.

개발사는 개발 시간을 아낍니다. 사용자는 램을 냅니다. 시장에 이 거래를 조정할 가격 신호가 없습니다. 앱스토어 어디에도 “이 앱은 메모리 400MB를 사용합니다"라는 라벨은 붙어 있지 않습니다. 정보가 없으니 선택도 없습니다.

OS 차원에서 앱별 메모리 등급을 표시하고, 기본 앱부터 그 기준을 지킨다면 이야기가 달라질 수 있습니다. 전자제품 에너지 효율 등급이 그랬듯이요. 물론 그 기준을 만들 주체가 기본 날씨 앱을 만드는 회사와 같다는 게 이 문제의 묘미입니다.

램이 계속 싸지던 시대는 일단 멈췄습니다. 미뤄둔 청구서가 돌아오는 중인데, 받아 들 준비가 된 쪽은 아직 안 보입니다. 여러분 작업 관리자에서 제일 억울한 항목은 뭔가요.