효율적인 소프트웨어 개발에서 길을 잃어버린 것일까?

• 약 30MB Word 문서를 브라우저에서 편집하려다 입력 지연을 겪으며, 최신 웹 앱의 성능 비용이 체감되는 사례가 됨
• 문서는 대부분 텍스트이고 일부 이미지와 표만 포함됐지만, Google Docs 또는 Chrome 환경에서는 원활히 처리되지 않았음
• 유료 Microsoft Office 대신 설치한 LibreOffice에서는 같은 문서가 훨씬 빠르게 동작해, 웹 앱과 네이티브 앱의 차이가 두드러짐
• 최신 웹 애플리케이션이 더 많은 메모리와 CPU를 요구하면서, 하드웨어 고사양화가 리소스 집약적 웹 앱과 맞물려 있다는 문제의식으로 이어짐
• PWA와 브라우저 기반 UI가 확산되는 상황에서도, 실제 사용성에는 네이티브 렌더링과 효율적인 소프트웨어 설계가 여전히 중요함

---

30MB 문서에서 드러난 웹 앱 성능 문제

• Google 계정과 클라우드 자동 동기화를 활용할 수 있어 Google Docs가 먼저 선택됨
• 문서를 Google Docs에 올린 뒤 입력해 보니, 글자가 화면에 나타나기까지 몇 초가 걸림
• 파일 크기는 약 30MB였고, 일부 이미지와 간단한 표가 있었지만 대부분은 텍스트였음
• Chrome 또는 Google Docs가 이 문서를 제대로 처리하지 못한 것으로 판단함
• Microsoft Office는 유료라 제외됐고, 대신 설치한 LibreOffice에서는 같은 문서가 매우 빠르게 동작함

효율성에 대한 더 큰 질문

• 최신 도구·프레임워크·언어가 성능 면에서 소프트웨어를 더 무겁게 만들고 있는지 돌아보게 함
• 리소스 집약적인 웹 애플리케이션을 감당하려고 하드웨어 사양이 높아졌고, 순수 네이티브 앱만 있었다면 이런 요구가 줄었을 수 있다고 봄
• 모바일 기기에 16GB RAM이 필요한 상황을 예로 들며, 소프트웨어의 자원 사용 증가를 문제 삼음
• 웹이 단순한 UI 렌더링 엔진 래퍼에 머무르기보다 네이티브 렌더링 수준의 효율성을 갖춰야 한다고 봄
• 1966년 Apollo 컴퓨터는 2KB RAM으로 달 착륙을 가능하게 했지만, 2024년 브라우저에서는 약 30MB 문서 작업도 어렵다는 대비가 최적화의 필요성을 강조함

[GN⁺]

Hacker News 의견들

• 네이티브 앱을 만들고 싶어도 Apple과 Microsoft가 계속 막는 느낌임. 개발자 계정, 바이너리 서명 인증서, 별 이유 없는 매출 30% 수수료까지 감수해야 하고, 특히 Microsoft 쪽 API는 혼란스럽게 변했음
  그래서 더 단순하고 저렴한 웹을 선택하게 됨

  • macOS에서 Apple Developer Program은 바이너리 서명이나 Mac App Store 배포를 원할 때만 필요함. Microsoft도 Microsoft Store에 올리거나, 회사 규모가 특정 기준을 넘는 상태에서 Visual Studio를 쓸 때만 비용이 듦
    서명 안 된 앱도 Windows와 macOS에서 실행은 가능하지만 경고가 더 많이 뜸. 30% 수수료도 Mac App Store나 Microsoft Store를 쓸 때만 해당하고, Microsoft Store는 게임이 아니고 자체 결제를 쓰면 수수료를 안 받는 것으로 보임
  • C/C++ 개발을 오래 하다가 JavaScript 웹 개발로 옮긴 이유 중 하나가 이것임. iPhone 앱을 Apple App Store에 올리는 과정은 지옥 같았고, 웹 앱은 라이선스·승인·설치 프로그램이 필요 없음
  • 단도직입적으로 말하면 Microsoft에 대해서는 개발자 계정 생성, 바이너리 서명, 매출 30% 공유가 필수가 아님. Microsoft API도 엉망이라고 보진 않고, Win32, .NET, UWP 같은 선택지가 있으며 꽤 잘 동작하고 유연함
    Apple은 잘 모르지만 Mac 앱은 개발자 계정 없이도 만들 수 있을 가능성이 높고, iPhone은 개발자 계정이 필요함. 예전에 본 가격은 연 $99였고, 앱을 진지하게 만들 생각이면 큰돈은 아님
  • 웹에서 카드 결제를 직접 붙이면 Stripe에 2.9% + 30¢ 를 내야 함. 10달러를 받아야 거래 수수료가 6% 수준까지 내려가니 가격 하한과 과금 모델 제약이 생김
    차지백과 환불 처리도 비용이 들고 고객지원에 시간을 쓰거나 사람을 고용해야 함. 연 매출 100만 달러 미만이면 Apple 수수료는 15%라서, 저가 앱이나 부가가치 앱이라면 직접 결제 처리보다 Apple이 더 나은 거래일 수 있음
  • macOS, Windows, Linux용 네이티브 앱을 만들 때 이런 걸 할 필요가 없었고 그냥 Qt를 씀

• 이 글이 265단어짜리 글 하나에 10.88MB를 내려주는 Medium에 올라왔다는 점이 아이러니함

  • Medium 입장에서는 광고가 진짜 콘텐츠임. 글은 광고라는 진짜 콘텐츠를 브라우저까지 실어 나르는 매개체이고, 광고 전달에는 많은 복잡성이 필요함
  • Firefox about:process로 보니 로딩이 끝난 지 10분 뒤에도 이 글이 메모리 239MB와 CPU 0.06~0.2%를 쓰고 있었고, CPU 시간의 45%는 Google reCAPTCHA에서 쓰이는 듯함
    Mozilla나 Google 같은 곳이 도메인별 CPU·메모리·에너지 사용 통계를 모아, 성능에 신경 안 쓰는 개발자들을 공개적으로 부끄럽게 만들었으면 좋겠음
  • 브라우저는 웬만한 운영체제보다 커졌고, 생태계도 닫힌 느낌임. WASM은 아직 제약이 많고, 웹 개발에서 실질적으로 가능한 선택지는 JS/HTML/CSS뿐임
    웹은 다시 2005년처럼 느껴짐. 다만 이번에는 팝업이 페이지 안에 박혀 있음
  • 이런 경우 Gemini 브라우저로 gemini://gemi.dev/bin/waffle.cgi를 열고 URL을 붙여넣음. Gemini 네트워크를 안 쓰는 사람은 URL에서 medium.com을 scribe.rip으로 바꾸면 됨
  • 텍스트 모드 브라우저에서는 괜찮음

• 길을 잃은 건 맞고, 이유는 간단함. 그렇게 할 수 있었기 때문임. 저항이 가장 적은 길이었고, 그래서 그 길을 택했음
  소프트웨어는 수십 년 동안 하드웨어 발전에 무임승차해 왔고, 특히 웹과 데스크톱 앱에서 그랬음. 무어의 법칙은 축복이자 저주였고, 오늘날 쓰는 소프트웨어는 그 무임승차가 한창일 때 기술을 익힌 사람들이 만든 것임

  • 컴퓨터로 하는 일은 매년 거의 같은데 소프트웨어는 점점 무거워지는 게 미칠 것 같음. 2010년만 해도 데스크톱 환경이 뜬 Linux 배포판은 시작 직후 RAM 100MB, 최적화판은 60MB 정도였음
    지금은 8GB 미만 컴퓨터는 못 쓰고, 8GB도 간신히 쓸 만함. 새 소프트웨어는 Electron을 쓰며 최소 1GB RAM을 먹고, 브라우저를 포함해 모든 것이 터무니없이 많은 메모리를 씀
    Windows는 더 이해가 안 됨. 어머니 컴퓨터를 도와줄 때마다 최근 i5와 8GB RAM PC인데도 너무 느리고, 부팅과 프로그램 실행, 업데이트가 오래 걸림. 1분 넘게 부팅하는 컴퓨터라면 창밖으로 던지고 싶을 정도임
  • 맞는 말임. 소프트웨어의 어려운 문제 중 상당수는 해결된 게 아니라 우회됐다고 봄. 컨테이너가 딱 그런 예임
    여러 언어·환경의 애플리케이션 배포를 해결한 게 아니라 컨테이너 엔진으로 피해 간 것임. 사용자가 원하면 컴파일러와 도구를 설치하는 빌드 스크립트도 줄 수 있지만 제대로 테스트하기 어려우니 결국 컨테이너를 씀
    Redbean과 Cosmopolitan libc가 이 문제를 “해결”하는 데 가장 가까워 보였음. 사용자가 앱을 쉽고 안정적으로 배포하길 원하면 컨테이너가 경쟁상 유리하고, 그러면 곧바로 디스크 100MB 이상과 컨테이너 엔진이 따라옴
  • “할 수 있으니까”라는 논리로 AI 살상 봇 군집까지 가면 Slaughterbots가 됨
    국가나 기업 간 경쟁을 기술 개발의 핵심 원리로 삼는 한, 기후 변화, 생태계 파괴, 살상 AI 같은 전 지구적 위기를 통제하기 어려움. 최고 수준의 조직 원리로 협업과 협력이 필요하고, 경쟁은 지구 전체에 거대한 부정적 외부효과를 만든다
  • 동의하지 않음. 원인은 프레임워크와 운영체제의 보안 기능, 예컨대 원격 측정 같은 것과 그 라이브러리들임
    Lazarus, 즉 Free Pascal로 작성된 프로그램은 Windows 11 같은 최신 Windows에서도 매우 빠르게 돌아감. 데스크톱에서 특정 목적에 맞게 작성된 소프트웨어를 유지하는 것이 속도와 안정성에는 가장 좋음
    소프트웨어의 모든 현대화, 하드웨어와 프레임워크 모두는 기존 기능 전체에 부과되는 세금처럼 작용함
  • “저항이 가장 적은 길”이라는 표현이 좋음. 그 길 위에 이력서 주도 개발이 엄청나게 뿌려진 느낌임
    복잡성이 완전히 잘못된 곳에 쌓였음

• 이런 불평은 반복되지만, 사실상 아무도 진심으로 원하지 않는 상태임
  개발자는 완전히 통합되고 연결된 범용 컴퓨팅 플랫폼인 웹을 좋아하고, 사용자는 충분히 괜찮기만 하면 성능을 크게 신경 쓰지 않는 듯함. 결국 소프트웨어는 사용자를 너무 짜증나게 하지 않을 정도까지 나빠져도 허용됨
  경영진도 충분히 좋은 소프트웨어가 이미 개발됐다면 더 좋은 소프트웨어를 만드는 데 관심이 없음. 누군가가 급격한 이탈이 필요하다고 판단하지 않는 한 아무것도 바뀌지 않고, 어느 관점에서도 변화의 유인이 거의 없음

  • 사람들은 성능과 다운로드 크기에 대해 분명 불평하지만, 보통 부작용을 말하는 방식으로 표현함. 노트북이 왜 뜨거운지, iPhone이 왜 “화면 멈춤”이 생기는지 묻는 식임
    신호가 약한 휴대폰에서 큰 앱을 내려받거나, 인터넷이 불안정한 지역에서 살거나, 저소득층·개발도상국에서 오래된 기기를 쓰는 사람들은 크고 느린 앱 때문에 좌절함. 성능과 앱 크기를 신경 안 쓴다고 느낀다면, 잘못된 사람에게 잘못된 질문을 하고 있을 수 있음
  • 소프트웨어 비대화는 새 현상이 아님. 적어도 1990년대 중반부터 불평이 있었고, 더 오래된 사람은 1980년대나 1970년대까지 거슬러 올라간다고 할 것임
    시간이 지나면 불평하는 사람만 특이해지고, 나머지는 업그레이드하거나 비대함을 감수하거나 오래된 소프트웨어를 계속 씀
    다만 그 비대함이 주는 이익도 봐야 함. Google Docs가 Word 복제품에 불과했다면 많이 쓰이지 않았겠지만, 무료, 여러 기기 접근, 원활한 협업 때문에 쓰는 사람이 있음
    또 비대함처럼 보이는 것 중 일부는 실제로 편의성 향상임. 어떤 크기에서도 예쁘게 보이는 비례 글꼴, Unicode 글꼴, 메모리보다 큰 문서 처리, 작업 문서와 자료 간 전환, 메모리 보호 같은 기능은 자원을 많이 쓰지만 삶의 질을 높임
  • 정말 그런가 싶음. 웹 개발자는 그럴 수 있지만 직접 웹 개발은 거의 해본 적 없음. 웹 인터페이스는 선택이고, 구독 매출을 원하고 일회성 판매를 피하려는 상업적 필요가 큰 동인으로 보임
    현대의 클라우드 기반 또는 반쯤 온라인인 세계는 사용자 관점에서 꽤 부자연스럽고, 수익화 필요가 없는 OpenOffice 같은 경우는 데스크톱 애플리케이션으로 남을 수 있음
  • 성공했던 스타트업 중 하나는 5MB 번들을 내려받고 데이터를 미리 읽는 단일 페이지 앱이었고, 시작에 거의 10초가 걸렸음
    아무도 그걸 불평하지 않았고, 앱 일부의 성능이 형편없어도 고객 불만은 드물었음. 로딩이 60초쯤 돼야 불평이 나오기 시작함
    그래도 그 소프트웨어는 일주일 걸리던 일을 몇 분으로 줄여주는 매우 가치 있는 문제를 해결했기 때문에 고객들은 극찬했음. 경쟁이 치열해지며 개선은 필요했지만, 대부분은 정말 신경 쓰지 않았고 항상 우선순위 최하위였음
  • 이 차이를 가장 크게 느끼는 곳은 이 함정에 빠지지 않은 소프트웨어를 쓸 때임. MYOB EXO/CRM이나 SAP ERP 같은 시스템은 수십 년 된 코드베이스를 아주 느리게 바꿔 왔고, 사실상 2000년대 기술이라 여전히 쓰기 불편하지만 그게 큰 장점이 됨
    작업 관리자를 열어 보면 현재 데이터베이스가 상당 부분 올라와 있는데도 RAM 20~30MB만 쓰는 걸 보는 재미가 있음. VLC와 Blender도 비슷한 예임

• 대부분이 개발자 탓을 하는 게 흥미롭지만, 현실적으로는 전부 비즈니스 결정임
  클라우드로 가는 건 기업이 구독의 안정적 수익을 좋아해서이고, 기업 고객은 IT 팀을 고용하지 않아도 되며 책임이 외부로 넘어가므로 높은 가동률을 요구할 수 있음. 성능은 최종 사용자에게 “괜찮은 정도”면 됨
  온프레미스 소프트웨어 업그레이드를 거부하는 고객은 긴 유지보수 주기와 끝없는 패치를 낳았고, 웹으로 한 번 개발하는 방식은 플랫폼별로 따로 개발자와 테스터를 두는 것보다 사업적으로 유리함. 개발자 전문성만으로는 이 근본적 힘을 바꿀 수 없음

  • 일정 시간이 지나면 그 소프트웨어는 고객에게 그냥 잘 동작함. Photoshop이 좋은 예임
    화려한 최신 기능은 못 쓰겠지만, Win7 기계에서 CS4는 추가 비용 없이 여전히 쓸 수 있음
  • 클라우드 위에서도 효율적인 웹 앱을 만들 수 있음. 결국 서버일 뿐임
    문제는 개발자들이 사용자가 살 수 없는 성능의 기계에서 개발하고, 성능과 효율적인 코드에 신경 쓰지 않는 데 있음
  • 많은 개발자도 같은 결정을 내릴 것 같음. 같은 소프트웨어의 플랫폼별 버전을 따로 유지하는 건 고통스럽고, 서버를 다루는 일은 개발 시간을 빼앗음

• 90년대 초 MS Word는 플로피 몇 장에 들어갔고, 주 실행 파일은 2MB였던 것으로 기억함. 전체 RAM 2MB인 16MHz 386에서도 잘 돌아갔음
  지금 하는 일 대부분을 그때도 했고, 문법 검사기 정도만 없었음. 이제는 GB 단위로 재고, 1000배 커졌는데 무엇을 얻었는지 모르겠음. 길을 잃었을 뿐 아니라 목적지도 모르게 됨

  • 얻은 건 기능과 그래픽임
    예를 들어 Linux의 dict.words만 해도 4.8MB이고, Arial Unicode는 20MB 정도 되는 글꼴임. 작업 중인 앱 아이콘 하나가 400KB이고, 충돌 처리용 Google Crashpad 핸들러도 몇 MB임
    4K 트루컬러 화면은 640x480 16색 화면보다 138배 큼
  • 몇 년 전 만우절 장난으로 PXE 네트워크 부팅 서버에 DOS/Windows 3.11 디스크 이미지를 올렸음. 동작하는 Word 6 for Windows가 포함됐고, gzip 압축 이미지가 12MB 안에 들어갔음
    그 시절 PC는 UEFI 없이도 부팅 가능했고, 제대로 설정하면 Windows 3.11도 거의 즉시 켜졌으며 Word도 바로 열렸음
    지금 Word에는 아주 작은 기능들과 몇몇 큰 기능이 꽤 추가됐지만, Microsoft가 신경만 쓴다면 메모리 사용량을 10분의 1로 줄일 수 있다고 확신함. 다만 유인이 없음. 컴퓨터는 빠르고 메모리는 많고, 플로피에 의존하지 않으니 비용만 더 들 뿐임
    소프트웨어 비대화가 환경에 무시 못 할 영향을 줄 수도 있다고 생각하지만, 충분히 강한 불만이나 EU의 반-소프트웨어-비대화 법 같은 게 나오지 않는 한 바뀌지 않을 것임
    최근 GitHub에서 MS Word for Windows 1.0 소스도 봤음. 원래 공개는 Computer History Museum에 있고 https://computerhistory.org/blog/microsoft-word-for-windows-...에서 볼 수 있음. 순수 C였고 큰 부분은 어셈블리였지만, 코드는 지금의 C/C++ 표준이나 패턴, 언어 기능과 비교할 수 없을 정도로 지저분했음
  • 예전에 폐기하러 들어온 오래된 PowerBook Duo에서 추억 때문에 Word 5.1을 켜 봤음
    소프트웨어는 기체와 같아서, 주어진 공간을 채우도록 팽창한다는 표현을 본 적 있음
    라이브 배포판에서도 비슷함. 예전에는 CD-R에 맞추려고 700MB였는데, 이제는 2GB USB에 들어가는 걸 찾기 어려워졌음. 그래도 “minimal”이 힘을 얻는 건 반가움
  • 회사에서 기계학습 코드를 돌리는 Docker 파일이 6GiB임. 모델 파일은 포함되지도 않음
    Nvidia, 대체 뭘 받게 하는 건가 싶음. 절대 쓰지 않을 생성 코드 조합 수천 개를 내려받는 건가
  • Word 6에 있던 기능이 사실상 지금 최신 Word에서도 쓰는 기능임
    다만 추가된 비대한 기능들 사이에서 원하는 걸 찾느라 더 오래 걸림

• 미니멀한 소프트웨어는 존재하지만 사람들이 잘 선택하지 않음. 의존성을 보수적으로 고르는 데 꽤 시간을 쓰고, 그러면 가볍고 성능 좋은 스택으로 이어짐
  요즘은 Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2], Mako Server[3] 같은 도구를 선호함. 훌륭하고 가볍고 안정적이며 효율적인 소프트웨어를 무료로 쓸 수 있지만, 흔한 길에서 조금 벗어나야 함. Stack Overflow에서 자주 들을 만한 것들은 아님
  프론트엔드에 대해서는 약간 갈등이 있음. 네이티브 앱과 웹 페이지를 선호하지만 Tiddlywiki를 매일 쓰고, 웹 앱의 자리가 있다고 봄. 다만 6MB Tiddlywiki 파일 탭이 RAM 155MB를 쓰고, 많이 커스터마이즈한 Emacs 세션은 88MB만 쓰니 글쓴이의 문제의식에는 동의함
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua는 내가 아는 프로그래밍 도구 중 가장 과소평가됐음. Lua 숙련은 프로그래밍 실력을 끌어올리는 최고의 방법 중 하나임
    물론 잘못 쓸 수도 있지만, 대부분의 다른 언어와 비교해 Lua 프로그램이 얼마나 작고 효율적일 수 있는지는 거의 충격적임

• 문제는 대략 이런 식이라고 봄. 회사 임원이 경쟁력을 위해 개발자에게 최고급 하드웨어가 필요하다고 판단하고, 개발자는 회사가 준 128GB RAM 고성능 노트북에서 웹 앱을 만듦
  그리고 아버지가 쓰는 2010년산 가족 PC 같은 환경에서는 테스트하지 않거나, 많은 부분이 망가지고 못 쓸 정도라는 걸 알아차릴 만큼 자주·철저히 테스트하지 않음

  • 네트워크 연결도 마찬가지임. 사무실에서 Wifi 7과 대칭형 기가비트 광인터넷으로 앱을 쓰는 사람과, 아파트 단지의 형편없는 와이파이 라우터와 소비자용 인터넷 회선으로 쓰는 사람의 경험은 다를 수밖에 없음
  • 이건 쉽게 고칠 수 있음. 개발할 때 개발자 도구를 모바일과 제한된 연결 상태로 설정함
    그러면 모바일 우선 반응형, 제한된 화면 공간, 나쁜 연결에서의 잠재 문제를 1급 관심사로 다루게 됨
    보통은 제품 책임자에게 문제를 알리면 그냥 넘겨버림. 그래서 세 번째 항목은 “2010년산 가족 PC에서도 테스트하지만, 더 중요한 이해관계자에게는 관심사가 아니다”로 고칠 수 있음
  • 지금 하는 일의 일부가 구형 하드웨어나 낮은 성능의 하드웨어, 여전히 쓰이는 오래된 브라우저, 특히 모바일 환경에서 테스트하는 것임
  • 빗나간 추측은 아님. 다만 글 자체가 상상 속 문제를 다룬 것이었음
  • 관련해서 Google Android 엔지니어들이 Android 폰을 직접 쓰며 테스트하는지 궁금함. 대부분 Apple 사용자일 것 같음

• 최근 오래된 페이지를 순수 HTML과 백엔드 생성 방식에서 React로 옮겼더니, 항목 천 개쯤 있는 드롭다운 하나가 열리는 데 몇 초가 걸렸음. 예전에는 전체 페이지가 100ms 정도면 열렸음
  처음에는 첫 100개만 보여주고 사용자가 세 글자를 입력해야 렌더링하자는 제안이 나왔음. 요즘 현실이 그렇긴 함
  물론 실제로는 형편없는 React 코드를 고쳐서 즉시 렌더링되게 만들었음

  • 맞음. 흔한 일임. 첫 화면 표시 시간 같은 성능 글이 많아지는 동안, React는 이런 식의 완전히 새로운 문제 범주를 만들어 냈음
  • Turbo 같은 서버 측 렌더링 프레임워크를 쓰면 됨. 요즘 사람들이 원하는 클라이언트 측 프레임워크를 많이 써 봤지만, 데이터가 많으면 전부 느렸고 Turbo만 예외였음
  • 수천 개 옵션이 있는 선택 상자는 사용자 경험이 형편없어 보임
    새 프레임워크가 문제를 너무 뚜렷하게 드러내서 누군가 실제로 고칠 명분을 만들 수 있다면, 오히려 그 프레임워크를 쓸 이유가 더 생김

• “idiomatic Ruby”나 “섣부른 최적화는 모든 악의 근원” 같은 글을 띄우고, “성능보다 개발 시간이 중요하다”고 말하니 이렇게 됨
  예전에는 더 적은 시간에 더 좋은 코드를 쓰는 개발자들이 있었음

  • 동의하지 않음. 오늘날에는 효율적인 코드를 쓰는 데 도움이 되는 자료가 과거보다 훨씬 많음
    예전 코드 중에는 지금이라면 만들어지지 않았을 끔찍한 코드도 많이 봤음