# Microsoft 새 Outlook, Classic 버전에선 즉시 하는 작업에 10초나 걸림 > Clean Markdown view of GeekNews topic #30628. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30628](https://news.hada.io/topic?id=30628) - GeekNews Markdown: [https://news.hada.io/topic/30628.md](https://news.hada.io/topic/30628.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-19T09:42:34+09:00 - Updated: 2026-06-19T09:42:34+09:00 - Original source: [windowslatest.com](https://www.windowslatest.com/2026/06/15/microsofts-new-outlook-takes-10-seconds-to-do-what-outlook-classic-does-instantly-on-windows/) - Points: 1 - Comments: 1 ## Topic Body - Windows 11의 **새 Outlook**은 메일 알림을 클릭해도 해당 메일로 바로 이동하지 못해, Outlook Classic이 즉시 처리하는 흐름에서 약 **10초 지연**이 발생함 - 지연의 핵심은 **WebView2 기반 구조**로, 알림 클릭 뒤 앱 실행, 받은편지함 로드, 인증, 메일 스레드 표시, 렌더링 과정을 거쳐야 함 - 리소스 사용도 차이가 커서 새 Outlook은 유휴 상태에서도 10개 프로세스와 **490~636MB RAM**을 쓰는 반면, Outlook Classic은 단일 프로세스와 117~148MB RAM 수준임 - Microsoft는 기능 보강을 이어가고 기업 강제 전환 기한도 **2027년 3월**로 늦췄지만, 알림 지연은 기능 부족보다 웹 앱 구조의 제약에 가까움 - 알림에서 바로 메일을 열어야 하는 업무 흐름이라면 현재는 **Outlook Classic**이 더 안정적인 선택이며, Classic Outlook은 2029년 4월까지 지원됨 --- ### Windows 11 알림에서 드러난 새 Outlook의 지연 - Windows 11에는 두 가지 Outlook이 함께 존재함 - **Outlook Classic**: 오래된 Win32 데스크톱 앱으로 파워 유저가 많이 쓰는 버전 - **새 Outlook**: Microsoft가 Windows 이메일의 미래로 밀고 있는 WebView2 기반 앱 - 새 이메일이 도착하면 Windows 11 오른쪽 아래에 알림 배너가 나타나며, 배너나 알림 센터 항목을 클릭하면 해당 이메일로 바로 이동해야 함 - Outlook Classic은 알림 클릭 후 해당 이메일을 거의 즉시 엶 - 새 Outlook은 앱을 열고 전체 받은편지함을 로드한 뒤, 알림이 가리킨 특정 이메일이 화면에 나타나기까지 약 **10초**가 걸림 - Start 메뉴에서 새 Outlook을 직접 열고 새 이메일을 찾아 클릭하면 약 5초 안에 끝낼 수 있어, 알림을 통한 직접 이동보다 수동 경로가 더 빠름 ### WebView2 구조가 만드는 처리 경로 - 새 Outlook은 Microsoft Edge의 **WebView2 런타임** 위에서 동작하며 Chromium 기반 렌더링 엔진을 사용함 - 알림 클릭 같은 단순한 상호작용도 브라우저와 비슷한 흐름을 통과함 - 웹 계층 초기화 또는 재개 - 인증 - 관련 메일 스레드 로드 - 웹 엔진을 통한 렌더링 - Microsoft는 WebView2 앱의 성능 문제를 진단하기 위한 **Delayed Message Timing** API를 테스트했지만, Outlook 알림 클릭 과정에서 이 API 사용은 확인되지 않음 - 작업 관리자 기준 새 Outlook은 10개 별도 프로세스로 실행됨 - WebView2 Manager - 여러 WebView2 Utility 프로세스 - WebView2 GPU Process - WebView2 Service Worker 등 - 같은 작업에서 Outlook Classic은 단일의 더 작은 프로세스로 동작함 ### 메모리와 CPU 사용량 차이 - 새 Outlook은 유휴 상태에서 **490MB~636MB RAM**을 사용함 - 세션별 수치는 메일함 크기에 따라 달라짐 - Outlook Classic은 같은 조건에서 약 **117MB~148MB RAM**을 사용함 - 메모리 사용량만 보면 새 Outlook이 Outlook Classic보다 대략 4배 수준임 - CPU 사용률도 차이가 남 - 새 Outlook: 유휴 상태 약 **4%** - Outlook Classic: 유휴 상태 **1% 미만** - 이 수치는 두 앱을 동시에 열어둔 상태에서 작업 관리자로 측정한 값임 ### Microsoft의 전환 추진과 업데이트 - Microsoft는 기존 UWP **Mail and Calendar** 앱을 새 Outlook으로 대체하는 방향을 밀어붙였고, 2024년 말 Mail and Calendar 앱은 공식 종료됨 - 기업 대상 전환도 진행 중이지만, 강제 옵트아웃 기한은 원래 2026년 4월에서 **2027년 3월**로 연기됨 - 새 Outlook은 출시 이후 일부 기능 격차를 줄여 왔음 - [2026년 3월 업데이트](https://www.windowslatest.com/2026/03/27/new-outlooks-march-2026-update-improves-folder-search-and-shared-mailboxes-as-it-catches-up-with-outlook-classic/): 폴더 검색 옵션 개선, 공유 메일함 접근 개선 - [2026년 5월 업데이트](https://www.windowslatest.com/2026/05/10/new-outlook-and-outlook-classic-features-in-may-2026-include-copilot-insights-teammates-calendars-automapped-calendars/): automapped calendar 지원으로 Classic에서 새 Outlook으로 옮겨도 공유 캘린더가 유지됨 - [2026년 6월 확인된 업데이트](https://www.windowslatest.com/2026/06/13/ditch-outlook-classic-microsoft-confirms-major-new-outlook-update-with-5-features-all-accounts-view-mail-merge-pst-and-more/): 2026년 8월 all-accounts inbox view, mail merge 개선, .PST 지원 확대 - 2026년 7월 예정된 .PST 가져오기 업데이트는 로컬 아카이브 파일의 캘린더 항목과 연락처를 가져올 수 있게 함 - Microsoft는 2026년 6월 초 새 Outlook 전환 이유로 15개 생산성 기능을 제시했으며, 오프라인 접근, Copilot 통합, 빠른 검색, 개선된 캘린더 제어가 포함됨 ### 현재 선택지와 남은 제약 - 새 Outlook은 Start 메뉴에서 빠르게 열리는 부분과 여러 기능에서 개선이 있었지만, 알림 처리 경험은 아직 Outlook Classic 수준에 못 미침 - 알림 클릭 후 바로 메일을 여는 흐름에서는 **WebView2 아키텍처**가 만든 추가 단계가 체감 지연으로 이어짐 - Microsoft는 Windows 네이티브 앱을 위해 **WinUI**에 더 집중하고 있으며, 네이티브 Outlook 가능성도 언급됨 - Windows 11 알림 센터에 Windows 10과 비슷한 캘린더 agenda view를 되돌리는 기능도 예정되어 있고, 이 기능 역시 WebView2 기반이 될 예정임 - 빠른 알림 처리가 업무 흐름에서 중요하다면 Outlook Classic이 더 신뢰할 수 있는 선택이며, Classic Outlook은 **2029년 4월**까지 지원됨 ## Comments ### Comment 59915 - Author: neo - Created: 2026-06-19T09:42:35+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48584207) - 2019년까지 약 20년 동안 Windows를 주 운영체제로 썼고 Linux 서버에는 SSH로 자주 들어갔지만, 데스크톱으로 살 곳은 아니라고 느꼈음 2019년에 PC를 새로 맞추며 Linux 환경에 익숙해지려고 Ubuntu 데스크톱과 Windows **듀얼 부팅**을 구성했는데, 드라이버나 주변기기 설정 때문에 삽질할 거라 예상한 것과 달리 며칠간 설정 몇 개만 검색하면 됐고 나머지는 잘 동작함 몇 주 뒤 Windows 파티션으로 돌아갈 일이 한 번도 없었다는 걸 깨닫고, 한 달 후 Windows SSD를 포맷해 Linux 저장공간으로 붙였음 Linux 전환이 귀찮을까 봐 망설였다면 선택권이 있을 때 한 번 시도해볼 만함. 적어도 2019년부터는 충분히 다듬어져 있었고, New Outlook 사례처럼 Microsoft는 대다수 사용자가 떠나지 못한다고 보고 **사용자 경험**을 개선할 유인이 줄어든 듯함 - 벌써 20년이 됐다는 걸 깨달음. 2006년쯤 Windows Vista가 피할 수 없다고 보고 Linux로 옮겼던 기억이 희미하게 남아 있음 이것저것 만지는 데 관심 없고 일과 여가에 쓸 **실용적인 컴퓨터**만 필요함. Linux도 완벽하진 않지만 Windows나 macOS를 써야 할 때 던져주는 잡다한 것들의 양은 거의 우스울 정도임 - “적어도 2019년부터는 다듬어져 있었다”는 말은 2019년에도 Linux 쪽에서 이미 하던 말임. 항상 “지난 몇 년간 많이 좋아졌다”는 식인데, 그 말이 틀렸다는 뜻은 아님 이제는 Linux 데스크톱이 얼마나 개선됐는지보다 **Microsoft가 얼마나 망쳤는지**가 시장 점유율을 좌우한다고 봄 - 동의함. 레거시 소프트웨어 때문에 Windows가 필요할 때도 있지만, **99%의 사용 사례**에서는 Linux가 잘 동작하고 더 빠르며 사생활도 더 존중함 - 거의 같은 경험임. 4년째 만족스럽게 Ubuntu를 쓰고 있음. 가끔 사소한 문제는 있지만 빠른 검색이나 AI로 해결 가능하고, 여기 있는 우리는 어쨌든 해커들이기도 함 - 이런 성공담에서 제일 마음에 드는 대목은 Nautilus가 Windows에서 예전부터 되던 기능, 예를 들면 **RDP 세션 3단계 안에서 텍스트와 파일을 복사·붙여넣기** 같은 걸 못 따라 한다는 점임 컴퓨터를 가끔 Google Docs나 여는 SSH 터미널처럼 쓰는 사람은 문제를 못 느끼겠지만, 매일 실제로 일하는 입장에서는 문제가 됨 - Outlook이 WebView2 기반이라 모든 웹 앱처럼 느리다는 식으로 말하지만, Fastmail도 웹 기반 메일 클라이언트를 제공하고 **Outlook Classic**만큼 빠르거나 더 빠름 New Outlook이 그냥 나쁨. 로딩 순서가 잘못됐고, 모든 창에서 전부 렌더링하며, 불필요한 데이터까지 불러와서 짜증남 - New Outlook을 실제 웹 브라우저에서 outlook.office.com으로 실행하면 무거운 데스크톱 클라이언트보다 훨씬 빠름 덤으로 Linux에서도 잘 돌아감. 예전 Outlook 대비 빠진 기능이 좀 있는 건 이해하지만, 기본적인 회사 메일 처리에는 충분히 잘 맞음 이제 직장에서 Windows를 쓸 이유가 0개가 됐으니, 이번만큼은 Microsoft가 일을 잘했다고 진심으로 응원하게 됨 - Fastmail 클라이언트는 일단 떠 있으면 좋지만, 잘 만든 **네이티브 앱**만큼 좋지는 않음 초기 실행이 훨씬 느리고, iOS/iPadOS 앱도 같은 웹 앱으로 기억하는데 버그가 꽤 많아서 웹뷰가 멈추거나 닫고 다시 열기 전까지 로딩 애니메이션에서 넘어가지 않을 때가 있음 - 어떻게든 배운 교훈을 잃어버린 듯함. 예전에는 전체를 표시하는 데 오래 걸린다는 걸 알면, 렌더링되는 대로 가능한 부분부터 보여줬음 예를 들어 긴 보고서라면 200쪽 전체가 끝날 때까지 기다리지 않고, 각 페이지가 렌더링될 때마다 표시 가능하게 만들었음. **빠르게 느껴지는 것**이 실제로 빠른 것만큼 중요할 때가 많았음 - Gmail에는 한때 저대역폭·고성능 웹메일 인터페이스가 있었고, 사실상 초기 UI였음 **번개처럼 빠르고** 메모리도 거의 쓰지 않았으며 메일이 거의 즉시 열렸음. 지속됐을 때는 좋았음 - 웹 기술을 쓰겠다는 결정과 성능 또는 사용성에 신경 쓰지 않겠다는 결정은 이론상 별개지만, 실제로는 자주 같이 내려짐 스타일 없는 텍스트를 버튼으로 쓰는 식의 결과까지 나옴 - “구형” Outlook의 시작 화면에도 이유가 있었음. SSD가 보편화되기 전에는 실행에 시간이 걸렸기 때문임 예전 Windows는 HDD에서도 쓸 만했고, SSD가 나오자 모든 게 즉시 열리며 충격적으로 빨라졌음. 그런데 요즘은 AHCI 지연 비용도 없는 **20Gbps 이상 SSD**가 있어도 이메일 하나 여는 데 충분하지 않음 그만큼 기준이 바닥까지 떨어졌음 - Windows만의 문제가 아니라 Microsoft 전체의 문제임 Outlook에서 답장을 누르면 답장 창이 열리기도 전에 첫 문장의 절반을 입력할 수 있음. M4 Pro에서도 그럼 거의 매번 Outlook이 백그라운드에서 뭔가 끝내기 전에 입력한 문장의 절반이 날아가서 첫 문장을 다시 써야 함. 같은 기기의 다른 메일 클라이언트에서는 이런 일이 없음 8자 키보드 버퍼를 쓰던 1982년도 아닌데, 사람이 컴퓨터의 입력 처리보다 빠르게 타이핑할 수 있어서는 안 됨 - 왜 이런 **엔시티피케이션**이 벌어지는지 모르겠음 Outlook 일정 이벤트를 복제하려 했는데, Teams 링크가 들어간 회의를 불규칙한 새 시간에 반복해서 필요로 해서 반복 일정으로 만들 수 없는 상황이었음 Outlook 네이티브는 그걸 못 해서 Teams로 이벤트를 복제해야 했고, 아마 Teams가 새 회의 ID를 필요로 하기 때문일 텐데 왜 Outlook 네이티브가 그걸 못 하는지 이해가 안 됨. 아마 웹 기반이라서겠지만 사용자 필요가 아니라 변화 자체와 돈을 위해 바꾸는 게 안타까움 - 더 쉽고 빠른 소프트웨어 개발 프레임워크가 **쓰레기 소프트웨어**를 출시하는 비용을 낮췄음 소프트웨어 품질을 어떻게 측정할지는 아무도 잘 모르지만, 애자일 개발은 소프트웨어 산출량 측정을 아주 쉽게 만들고 회사들은 그걸 우선시함 AI 기반 개발이 개발자를 더 효율적으로 만들어도 실제 제품이 좋아지지 않는 이유도 여기에 있음. 쓰레기를 더 빨리 찍어내는 데 쓰일 뿐임 - 새 직장에서 Windows 11을 쓰기 시작했는데, 업무용 시스템에서 **notepad.exe**가 열리는 데 3~4초가 걸림. 마지막 탭을 닫고 다시 열어도 마찬가지임 심지어 AI 글쓰기용 인앱 구매까지 들어 있음 - Windows 자체도 매우 느리지만, 그 위에 CrowdStrike 같은 **기업 보안 도구**와 느리고 버그 많은 사내 DNS까지 얹으면 쓸 수 없을 지경이 됨 이제 제시간에 뭔가 하려면 WSL을 통하는 수밖에 없음 - 안타까움. 여기에 형제 댓글들이 말한 기업 보안 스택, 즉 EDR/XDR, 앱 제어, 방화벽, 생산성 감시 도구 같은 것들이 문제를 더 키움 두 번째로는 PC 대량 구매 때 데스크톱 사용자 경험을 지킬 사람이 보통 없고, 그날그날 전략은 가장 싼 화장지를 고르는 식임 CFO 분석에서 매력적으로 보인 저가 PC에, 애초에 제한된 성능의 50%를 빨아먹는 보안 소프트웨어까지 올라가 있음 - Microsoft가 왜 이렇게 되는지 끝목표를 이해하기 어려움. 모든 걸 얼마나 대충 만들 수 있어야 회사 전체가 그냥 방해물처럼 변하는지 보는 듯함 - 메모장을 **Notepad2e**로 바꾸는 사람들도 있다고 읽었음. 개인적으로는 텍스트 편집기로 vim을 씀 [https://github.com/ProgerXP/Notepad2e]() - 많은 기업이 어떤 도구를 통해 앱 실행 **허용 목록**을 켜고 있음. Microsoft도 하나 제공하는 것 같고 CrowdStrike 등도 있음 지연은 백엔드 애플리케이션이나 때로는 웹 서버 호출까지 끼어들기 때문일 가능성이 큼. 여기에 파일을 열기 전마다 실시간 검사까지 더해짐 - Microsoft의 품질이 어떻게 이렇게 낮은지 정말 궁금함. 기술 부채, 마감, 관료주의 때문일까 이 회사는 **도그푸딩**이라는 용어를 만들고 모든 버그가 잡힐 때까지 Exchange를 전 직원에게 쓰게 했던 회사임 직장에서 차세대 웹 메일 앱을 만들고 있는데 사용자 경험의 경계 사례는 많아도 핵심 UI 성능은 로켓 과학이 아님 버그를 줄이고 마지막 성능을 개선하며 Outlook 지원을 추가하기 위해 플레이 테스트 도움을 찾고 있음 [https://housecat.com/]() 이 메일 앱은 “변형 가능”해서 inbox zero에 도달하도록 맞춤 워크플로와 UI 위젯을 만들 수 있다는 점이 유인임 - 예전 Exchange였던 조직에서 일하고 있음. 내 의견은 개인 의견임 품질 문제에는 단일 원인이 없음. 수십 년에 걸친 **수천 개의 작은 결정과 문제**가 서로 복합적으로 쌓였고, 플랫폼이 처리하는 기능 복잡도·범위·영향력·엄청난 규모와 트래픽이 곱해진 결과임 엔지니어링 문화가 고객의 하위 호환성을 매우 중시하는데, 좋은 이유가 있지만 플랫폼과 의사결정 전반에 좋은 방식과 나쁜 방식으로 스며듦 그래서 내부적으로 크게 개선할 수 있는 명확한 플랫폼 전환에는 투자가 잘 안 되거나 비용이 너무 크다고 판단됨 그래도 여전히 일하기 좋은 곳이고, 내 일이 수십억 명의 업무 생활에 조금이나마 직접 기여한다는 점은 자랑스럽지만, 내부·외부 고객 모두의 플랫폼 사용 경험을 개선하려면 갈 길이 멂 - 클릭했다가 “자체 AI 에이전트를 가진 이메일 앱”이라는 문구를 보고 닫았음. 또 하나의 **AI를 억지로 끼워 넣은 것**처럼 보였음 Outlook도 이미 이런 걸 제공하지만 형편없음. 맥락이 핵심인데 그 맥락은 여러 곳에 묻혀 있고, 접근 권한이 있어도 제대로 못 해냄 - 어느 순간 품질 관리를 포기한 듯함. 이유는 모르겠지만 Microsoft는 이미 몇 년 전부터 내리막이었음 AI 잡동사니가 늘고 Microsoft가 “microslop”처럼 변하면서 이 흐름이 더 증폭됐을 뿐임 - Microsoft는 늘 성능에 부주의했음. 일화가 두 개 있음 오래전 Microsoft에서 일하던 친구에게 어떤 Microsoft 패키지가 너무 느리다고 불평했더니, 무심하게 “Intel 주식을 사. 사람들이 PC를 업그레이드해야 할 거야”라고 답했음 또 하나는 약 15년 전 지역 모임에서 Yahoo에서 일하던 오랜 친구와 나눈 대화임. Yahoo와 Microsoft의 검색 계약이 실제로 어떻게 동작했는지 설명해줬는데, Microsoft 엔지니어들에게 문제를 제기해도 반응이 없었다고 함 유럽 사용자가 search.yahoo.de에서 검색하면 EU 데이터센터의 Yahoo 서버로 요청이 가고, 계약상 그 요청이 Virginia의 Microsoft 서버로 전달됨. 그런데 EU 요청이므로 그 Microsoft 서버가 다시 EU의 Microsoft 서버에 요청하고, 결과는 EU Microsoft 서버에서 Virginia Microsoft 서버로, 다시 EU Yahoo 서버로 돌아감 결국 검색 요청 하나에 **대서양 왕복 4번**이 발생했고, 지연은 약 1500ms였다고 함. Yahoo 내부 목표는 300ms 이하였는데, 이 지연 폭증을 Microsoft 쪽에 말해도 그냥 어깨를 으쓱했다는 얘기였음 - 검색을 Virginia로 보낸 건 **감시 목적**이었음. 그건 분명히 알아야 함 - Mac용 “Legacy Outlook” 최신 버전에 큰 버그가 생겼음. “legacy Outlook for Mac에서 이메일에 답장하거나 전달할 때 원문이 본문에 포함되지 않음”이라는 버그임 [https://support.microsoft.com/en-us/topic/replying-to-or-for...]() 그래서 결국 New Outlook이라는 쓰레기를 쓰도록 강요받게 됐고, 실제로 쓰레기임. 개처럼 느리고 모든 동작에 1초씩 걸림 왜 버튼을 전부 재배치하고 글꼴을 바꾸는지 모르겠음. 그냥 예전 인터페이스를 1:1로 복사하면 안 되는 걸까 이 새 버전을 2주 넘게 써야 한다면 다른 클라이언트로 바꿀 생각임. 어쩌면 사람들을 전환시키려고 일부러 이런 치명적 버그를 넣는 건지도 모름 - 정말 믿기 힘들 정도로 짜증남. “지원”에서 제안한 해결책이 “이 버그를 넣기 전 버전으로 다운그레이드할 수 있다”처럼 보일 때는 더 그렇음 새 쓰레기로 갈아타볼 생각도 없고, 그냥 **메일 클라이언트**를 통째로 바꿀 예정임 - 계산기가 열리는 데 체감 가능한 초 단위 시간이 걸린 게 Windows 10에서 마지막 한계였음 집에서는 몇 년째 **Linux만** 쓰고 있고, 그 선택이 옳았다는 걸 상기시켜주는 기사 제목이 비교적 꾸준히 나오고 있음 - 2019년부터 집에서는 Linux만 쓰고 있음. 다만 일은 Windows에서 해야 하는데, Windows가 형편없고 업데이트할 때마다 더 나빠진다는 걸 매일 떠올리게 됨 WSL만이 그나마 견딜 수 있게 해줌. 집 컴퓨터 앞에 앉을 수 있을 때 길게 편안한 숨을 내쉬는 느낌임 - 다행히 여전히 클래식 계산기로 되돌릴 수 있음: [https://win7games.com/#calc]() - 고맙게도 그 문제는 나아졌지만, 계산기 인스턴스가 이유 없이 여러 개 뜨는 이상한 버그는 아직 남아 있음 - 2023년쯤 전환했는데, Windows를 떠난 결정을 의심하게 만든 기사 제목이나 일화나 댓글이나 조짐은 단 하나도 못 봤음 Linux에서 아무 이유 없이 뭔가 안 되는 최악의 날조차 Windows보다 나음 - 매일 아침 업무 메일을 확인하려고 Outlook을 실행함. 어떤 때는 열리고 어떤 때는 아무것도 안 보이며, 화면에도 로딩 대화상자도 없이 마치 실행하지 않은 것처럼 있다가 **5분 뒤**에 열림 Windows와 Mac 모두에서 발생함 UI를 렌더링하기 전에 업데이트 확인을 하는 듯하고, 업데이트가 있으면 UI를 보여주기 전에 다운로드와 적용을 끝내야 하는 것 같음. 앱을 열려는 사용자 입장에서는 고장 나서 로딩이 안 되는 것처럼 보임 메일에 접근하려는데 앱이 열리지 않고 업데이트부터 하기로 결정하면 5분을 기다려야 해서 엄청난 고통임. 거부 옵션을 주거나 백그라운드에서 투명하게 처리한 뒤 준비되면 재시작하라고 묻는 방식이어야 함 Office에서 파일을 저장하려고 해도 비슷하게 답답함. 로컬 저장 대신 **OneDrive**에 저장하게 만들려는 어두운 사용자 경험이 들어가 있음 - Microsoft는 매우 빠르게 도는 네이티브 앱을 만들 직원이 충분한데도 여전히 웹 이식성 논리에 끌려가고 있음. 다들 알다시피 그 주장은 지금도 대체로 사실이 아니며, 깔끔하게 처리하기 어려운 **비결정적 지연과 오류**를 온갖 방식으로 끌어들임 솔직히 개발자가 10명 넘게 붙은 거의 모든 앱에서 비슷함. 의존성 증가와 일관된 설계 부재가 서서히 죽이는 구조임 그래도 다른 사람이 말했듯 Fastmail처럼 브라우저에서 괜찮게 동작하는 것도 있으니 가능은 함 - 네이티브 소프트웨어를 잘 만드는 건 굉장히 어려움 지원해야 할 플랫폼만 해도 최소 Windows, Mac, iPhone, Android 네 가지임. 프론트엔드만 해도 최소 **서로 다른 엔지니어 4명**이 필요함 여기에 여러 백엔드 엔지니어가 필요하고, 공유할 수는 있지만 항상 그런 것도 아님. Android의 특이한 런타임 요구사항은 충분히 맞춤형이라 데이터베이스가 C++로 작성됐다고 해서 Windows 백엔드와 같은 C++ 데이터베이스라는 뜻은 아님 마지막으로 디자이너들은 각 네이티브 플랫폼의 고유한 요소를 공통 디자인 언어로 합쳐 모든 플랫폼에서 같은 비전을 가지려 함. 그러면 엔지니어는 4개 플랫폼에서 동일하게 동작하는 UI를 만들게 되고, 결국 사실상 맞춤형 “브라우저”를 만드는 셈이 됨 - 네이티브 앱을 만들어도 망칠 것임 - 플랫폼이 문제가 아님. 유능한 엔지니어링 팀이라면 **단일 스레드 jQuery 웹 앱**으로도 이것보다 훨씬 잘 만들 수 있음