내가 직접 설계하고 지켜온 앱이 이렇게 바뀌어버려서 조금 씁쓸한 마음임
예전의 네이티브 앱은 완벽하진 않았지만, 생산성 도구로서 환경을 존중하려는 느낌이 있었음
결론적으로 대기업에게 네이티브 데스크톱 앱은 현실적으로 불가능하다고 봄. 이유는 조율 비용 때문임
여러 플랫폼에서 동시에 기능을 출시하려면 복잡도가 기하급수적으로 늘어남. 느긋한 개발 속도라면 가능하겠지만, 빠른 실험과 반복을 원한다면 결국 웹 코드 한 번 쓰는 게 낫다는 결론에 다다름
요즘은 Microsoft조차 이런 방식으로 개발하고 있음. 아이러니하게도 작은 회사일수록 네이티브 앱을 더 잘 유지할 수 있음
이 말이 이해가 안 됨. 나와 동료 둘이서 wxWidgets로 오디오 신호 처리용 크로스플랫폼 GUI를 만들었는데, macOS와 Windows에서 잘 돌아갔음
대기업이 텍스트 버블과 이모지를 네이티브로 못 그린다는 건 납득이 안 됨. 예전 MSN Messenger도 그 정도는 했었음
문제의 핵심은 인력 수가 아니라 조율 비용임
워터폴 방식에서는 괜찮지만, 요즘의 ‘Agile’식 개발에서는 완전 혼돈임
Android나 iOS는 네이티브 경험이 중요하니 감수할 만하지만, Windows는 API가 계속 바뀌고 네이티브 감각도 거의 사라졌음
차라리 Telegram처럼 Qt로 만들었으면 나았을 것 같음
예전에 Facebook과 Messenger의 Windows 버전을 만들었는데, 웹 대비 사용률이 1%도 안 돼서 경영진이 실패로 간주했음
혹시 Windows에서 DB 키의 비밀 저장소 위치를 알려줄 수 있는지 궁금함. DB가 곧 막히기 전에 내보내고 싶음
요즘 앱들은 사용자보다 개발자 중심으로 최적화되어 있음
처음엔 장인정신으로 만든 네이티브 앱이 인기를 얻지만, 회사가 커지면 실험과 텔레메트리, 빠른 반복이 우선이 됨
독점적 지위 덕분에 품질은 중요하지 않게 되고, 결국 Electron 덩치 앱이 되어도 아무도 어쩌지 못함
교체 이유는 명확함. 웹 버전에서 새 기능을 빠르게 내보내는데, 네이티브 클라이언트는 그걸 따라잡기 어려웠음
그래서 결국 웹 래퍼로 전환한 것임
요즘 ‘네이티브 Windows 앱’이란 개념 자체가 모호하고, 성능이나 오프라인 대응도 웹으로 충분히 구현 가능함
다만 GPU 프로세스가 400MB까지 커지는 건 좀 웃김. 그래도 Meta 같은 대기업이니까 가능한 일이라 생각함
이제는 Windows조차 네이티브 느낌이 거의 사라진 듯함
사실 예전 네이티브 클라이언트가 기능적으로 더 앞서 있었음. 영상 통화 같은 기능도 있었음
Meta가 웹 클라이언트를 주력으로 삼으면서, 비모바일 플랫폼은 전부 웹으로 통합한 듯함
나는 항상 ‘모든 걸 웹으로 하자’는 개발자들과 싸우고 있음
“Firefox가 지원 안 해. Chrome 안 써.”가 내 최종 무기였는데, 요즘은 Safari 핑계도 써야 함. React 때문임
예전엔 128MB RAM과 단일 코어 CPU로도 음성·영상 통화가 가능했는데, 지금은 효율이 퇴보한 것 같음
사실 이건 Jevons 역설의 사례임. 효율이 높아질수록 자원 소비가 늘어남
JS와 웹의 성능 향상은 결국 더 많은 광고와 코드 배포로 이어졌음 Jevons paradox 위키
물론 예전엔 해상도와 비트레이트가 낮고 암호화도 없었지만, 그래도 지금보다 효율적이었던 건 사실임
나도 32MB RAM의 ThinkPad로 모든 걸 잘 했던 기억이 있음
WhatsApp이 웹 래퍼 → 네이티브 → 다시 웹으로 돌아간 건 흥미로운 순환임
네이티브 유지 비용이 크다고 하지만, 이렇게 몇 년마다 리라이트하는 게 더 낭비 아닌가 싶음
내부 정치 싸움의 결과일 수도 있음. 잘못된 기술 결정을 내린 사람이 승진했을 뿐임
웹 개발자들은 대부분 시간을 의존성 업데이트나 프레임워크 싸움(특히 React 욕)으로 보냄
아무도 “앱을 다시 쓰지 말자”고 해서 승진한 적은 없음
Windows의 네이티브 프레임워크가 너무 엉망이라 Microsoft조차 안 씀.
버그와 누락된 기능이 많고, Chrome은 이런 문제를 겪지 않음
결국 승진 인센티브 문제임. 잘 돌아가는 앱을 유지한다고 보상받지 못함
나는 자주 여행을 다니는데, 여러 휴대폰에서 WhatsApp을 동시에 쓸 수 있으면 좋겠음
여행용 폰을 초기화할 때마다 백업·복원이 번거로움
지금은 최대 4~5대까지 설치 가능함. 메인 기기 외에도 클라이언트들이 독립적으로 메시지를 주고받을 수 있음
나는 WhatsApp을 안 쓰지만, Telegram은 여러 기기에서 완벽히 동기화됨. 요즘은 다들 Telegram을 씀
초기화한 폰에는 어떤 앱을 설치하는지 궁금함
Meta의 AI 코딩 에이전트가 네이티브 앱 하나 제대로 못 유지한 건가 하는 생각이 듦
하지만 AI로 만든 네이티브 앱이라도 크게 다르진 않았을 것 같음
이런 웹 기반 전환 추세는 앞으로도 계속될 것 같음
Microsoft의 New Outlook도 사실상 웹 클라이언트를 EXE로 감싼 형태임
덕분에 COM Add-in, VBA, MAPI, .PST 지원 같은 핵심 기능이 사라졌음
이런 흐름이 결국 문명 붕괴의 신호일지도 모름
관련 글: Collapse of Civilization
New Outlook에서 검색 기능이 제대로 작동하지 않음. 자기 자신에게 보낸 메일도 몇 개만 나옴
우리 조직에서도 모두 옛 Outlook이 훨씬 낫다고 불평함
Flutter가 좋은 절충안이 될 수 있었을 것 같음
크로스플랫폼 데스크톱 앱을 효율적으로 만들고, 리소스도 훨씬 덜 쓸 수 있었을 것임
실제로는 메모리를 많이 쓰는 게 아니라 V8이 예약만 하는 것일 수도 있음
Windows에서 256MB 단위로 예약하기 때문에, 여러 프로세스가 있으면 1GB까지 잡히는 것처럼 보임
작업 관리자에서 보이는 건 실제 사용량이 아니라 Chromium의 예약 메모리임
WhatsApp의 잘못이라기보단 Chromium의 구조적 문제임
그래도 그런 플랫폼을 선택한 건 책임이 있음
메모리를 먹는 걸 알면서도 Electron을 택한 건 결국 그들의 결정임
예전 iOS WhatsApp이나 2018년 Windows 버전과 비교해도 기능 차이는 거의 없을 텐데, 굳이 새로 만들 이유가 있었는지 의문임
Hacker News 의견
내가 직접 설계하고 지켜온 앱이 이렇게 바뀌어버려서 조금 씁쓸한 마음임
예전의 네이티브 앱은 완벽하진 않았지만, 생산성 도구로서 환경을 존중하려는 느낌이 있었음
결론적으로 대기업에게 네이티브 데스크톱 앱은 현실적으로 불가능하다고 봄. 이유는 조율 비용 때문임
여러 플랫폼에서 동시에 기능을 출시하려면 복잡도가 기하급수적으로 늘어남. 느긋한 개발 속도라면 가능하겠지만, 빠른 실험과 반복을 원한다면 결국 웹 코드 한 번 쓰는 게 낫다는 결론에 다다름
요즘은 Microsoft조차 이런 방식으로 개발하고 있음. 아이러니하게도 작은 회사일수록 네이티브 앱을 더 잘 유지할 수 있음
대기업이 텍스트 버블과 이모지를 네이티브로 못 그린다는 건 납득이 안 됨. 예전 MSN Messenger도 그 정도는 했었음
워터폴 방식에서는 괜찮지만, 요즘의 ‘Agile’식 개발에서는 완전 혼돈임
Android나 iOS는 네이티브 경험이 중요하니 감수할 만하지만, Windows는 API가 계속 바뀌고 네이티브 감각도 거의 사라졌음
차라리 Telegram처럼 Qt로 만들었으면 나았을 것 같음
처음엔 장인정신으로 만든 네이티브 앱이 인기를 얻지만, 회사가 커지면 실험과 텔레메트리, 빠른 반복이 우선이 됨
독점적 지위 덕분에 품질은 중요하지 않게 되고, 결국 Electron 덩치 앱이 되어도 아무도 어쩌지 못함
교체 이유는 명확함. 웹 버전에서 새 기능을 빠르게 내보내는데, 네이티브 클라이언트는 그걸 따라잡기 어려웠음
그래서 결국 웹 래퍼로 전환한 것임
요즘 ‘네이티브 Windows 앱’이란 개념 자체가 모호하고, 성능이나 오프라인 대응도 웹으로 충분히 구현 가능함
다만 GPU 프로세스가 400MB까지 커지는 건 좀 웃김. 그래도 Meta 같은 대기업이니까 가능한 일이라 생각함
Meta가 웹 클라이언트를 주력으로 삼으면서, 비모바일 플랫폼은 전부 웹으로 통합한 듯함
“Firefox가 지원 안 해. Chrome 안 써.”가 내 최종 무기였는데, 요즘은 Safari 핑계도 써야 함. React 때문임
관련 글: Making News Feed Nearly 50% Faster on iOS
경영진 입장에서는 여러 플랫폼에 같은 기능을 개발하는 게 낭비로 보이니까 숫자 중심 개발로 흐름
성능이나 메모리 사용은 고려되지 않고, “웹앱도 충분히 빠르다”는 인식이 퍼져 있음
나는 WhatsApp의 옛 네이티브 Windows 앱이 정말 끔찍했다고 생각함
자주 입력이 멈추거나 악센트 문자가 깨져서 재시작해야 했음. 새 Electron 앱은 무겁지만 적어도 제대로 작동함
Microsoft WebView2 공식 페이지
예전엔 128MB RAM과 단일 코어 CPU로도 음성·영상 통화가 가능했는데, 지금은 효율이 퇴보한 것 같음
JS와 웹의 성능 향상은 결국 더 많은 광고와 코드 배포로 이어졌음
Jevons paradox 위키
WhatsApp이 웹 래퍼 → 네이티브 → 다시 웹으로 돌아간 건 흥미로운 순환임
네이티브 유지 비용이 크다고 하지만, 이렇게 몇 년마다 리라이트하는 게 더 낭비 아닌가 싶음
버그와 누락된 기능이 많고, Chrome은 이런 문제를 겪지 않음
나는 자주 여행을 다니는데, 여러 휴대폰에서 WhatsApp을 동시에 쓸 수 있으면 좋겠음
여행용 폰을 초기화할 때마다 백업·복원이 번거로움
Meta의 AI 코딩 에이전트가 네이티브 앱 하나 제대로 못 유지한 건가 하는 생각이 듦
이런 웹 기반 전환 추세는 앞으로도 계속될 것 같음
Microsoft의 New Outlook도 사실상 웹 클라이언트를 EXE로 감싼 형태임
덕분에 COM Add-in, VBA, MAPI, .PST 지원 같은 핵심 기능이 사라졌음
이런 흐름이 결국 문명 붕괴의 신호일지도 모름
관련 글: Collapse of Civilization
Flutter가 좋은 절충안이 될 수 있었을 것 같음
크로스플랫폼 데스크톱 앱을 효율적으로 만들고, 리소스도 훨씬 덜 쓸 수 있었을 것임
실제로는 메모리를 많이 쓰는 게 아니라 V8이 예약만 하는 것일 수도 있음
Windows에서 256MB 단위로 예약하기 때문에, 여러 프로세스가 있으면 1GB까지 잡히는 것처럼 보임
작업 관리자에서 보이는 건 실제 사용량이 아니라 Chromium의 예약 메모리임
WhatsApp의 잘못이라기보단 Chromium의 구조적 문제임
메모리를 먹는 걸 알면서도 Electron을 택한 건 결국 그들의 결정임
예전 iOS WhatsApp이나 2018년 Windows 버전과 비교해도 기능 차이는 거의 없을 텐데, 굳이 새로 만들 이유가 있었는지 의문임