Hacker News 2026.06.19 36

메일 하나 여는 데 10초? 새 아웃룩이 느려진 진짜 이유

클릭 한 번에 10초, 새 아웃룩에 무슨 일이?

회사에서 윈도우 쓰시는 분들이라면 요즘 마이크로소프트가 “이제 새 아웃룩(New Outlook)으로 갈아타세요” 하고 계속 권하는 걸 보셨을 거예요. 그런데 막상 바꿔보면 좀 답답하거든요. 기존 아웃룩 클래식(Outlook Classic)에서는 메일을 클릭하면 곧바로 열리고 폴더도 바로바로 넘어갔는데, 새 아웃룩에서는 똑같은 동작에 길게는 10초씩 걸린다는 이야기가 나오고 있어요. 메일 클라이언트처럼 하루에도 수십 번 만지는 도구가 이렇게 굼뜨면 체감이 정말 크죠.

왜 이렇게 느려진 걸까

이게 뭐냐면, 새 아웃룩은 사실 우리가 알던 그 ‘프로그램’이 아니에요. 속을 들여다보면 웹 브라우저로 여는 Outlook 웹 버전을 데스크톱 앱처럼 껍데기만 씌운 거거든요. 마이크로소프트가 자기네 브라우저 엔진(Edge WebView2)을 안에 넣어두고, 그 위에서 웹페이지를 띄우는 방식이에요.

반면 클래식 아웃룩은 윈도우용으로 직접 만든 네이티브(native) 앱이에요. 네이티브라는 건 운영체제가 제공하는 기능을 직접 갖다 쓴다는 뜻인데, 메일 목록이나 버튼 같은 화면 요소를 OS가 가장 빠른 방식으로 그려주고, 데이터도 내 컴퓨터에 미리 저장(캐싱)해둬서 클릭하면 즉시 보여줄 수 있어요.

웹 기반 앱은 사정이 달라요. 화면을 브라우저 엔진이 한 단계 거쳐서 그리고, 많은 데이터를 그때그때 서버에서 받아와야 하거든요. 네트워크가 느리거나 서버 응답이 늦으면 그 시간만큼 사용자가 멍하니 기다리게 되는 거죠. ‘메일 하나 여는 데 10초’의 정체가 바로 이거예요.

사실 이건 아웃룩만의 문제가 아니에요

요즘 데스크톱 앱들이 점점 웹 기술로 만들어지는 흐름이 있어요. 슬랙, 디스코드, VS Code, 팀즈 같은 앱들이 다 Electron(일렉트론)이라는, 웹 기술로 데스크톱 앱을 만드는 도구로 제작됐거든요. 개발사 입장에서는 코드 한 벌로 윈도우·맥·리눅스를 다 커버할 수 있으니 엄청 매력적이에요. 인력과 시간을 크게 아낄 수 있으니까요.

하지만 공짜는 없죠. 브라우저 엔진을 통째로 끼고 다니니 메모리도 많이 먹고, 네이티브만큼 빠릿빠릿하지 못해요. 그래서 요즘은 Tauri(타우리)처럼 OS에 이미 깔린 웹뷰를 활용해 더 가볍게 만드는 대안도 주목받고 있어요. 결국 ‘개발 편의성 대 사용자 체감 성능’이라는 오래된 줄다리기인 셈이에요.

한국 개발자에게 주는 시사점

우리가 사내 도구나 자체 앱을 만들 때도 똑같은 고민을 하게 돼요. 빠르게 출시하려고 웹뷰로 감싸면 개발은 편하지만, 사용자가 매일 수십 번 누르는 핵심 동작이 1~2초씩 밀리면 그 답답함이 쌓여서 결국 ‘이 앱 별로다’라는 인상으로 돌아오거든요. 특히 하루 종일 쓰는 도구일수록 체감 속도가 곧 제품의 평가가 돼요.

교훈은 명확해요. 크로스플랫폼이 무조건 정답은 아니라는 것, 그리고 자주 쓰는 동작만큼은 캐싱이나 로컬 처리로 즉시 반응하게 설계해야 한다는 거예요. 모든 화면을 다 빠르게 만들 수 없다면, 적어도 사용 빈도가 높은 길목만큼은 네이티브 수준으로 다듬어 두는 게 현명한 선택이죠.