단색 배경 사용 시 Windows 7 로그온 화면이 30초 머물던 이유

 (devblogs.microsoft.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Windows 7과 Windows Server 2008 R2에서 단색 바탕화면을 쓰면 로그온 중 Welcome 화면이 최대 30초 동안 남을 수 있었고, 원인은 준비 완료 신호 누락이었음
  • 로그온 시스템은 작업 표시줄, 시스템 서비스 구성요소, 바탕화면 창, 배경화면 표시 등이 모두 준비 완료를 보고하거나 30초가 지나야 Welcome 화면을 전환함
  • 배경화면 코드가 비트맵 배경이 있을 때만 Report(WallpaperReady)를 호출해, 비트맵이 없는 단색 배경에서는 대기 조건이 끝까지 채워짐
  • “Hide desktop icons” 그룹 정책도 같은 패턴으로 Report(DesktopIconsReady) 호출이 조건문 안에 묶이면 아이콘 준비 보고가 빠질 수 있음
  • 실제 로그온이 항상 30초 늘어난 것은 아니며, 원래 5초나 25초에 끝났을 준비 과정과 무관하게 Welcome 화면이 타임아웃 30초까지 유지된 현상임

단색 배경에서 Welcome 화면이 오래 남은 이유

  • 로그온 인증이 끝나면 Windows는 사용자의 데스크톱 환경을 구성함
    • 작업 표시줄 생성
    • 여러 시스템 서비스 담당 구성요소 로드와 초기화
    • 바탕화면 창 생성과 아이콘 표시
    • 바탕화면 배경 창에서 배경화면을 로드하고 화면에 그림
  • 로그온 시스템은 각 구성요소가 준비됐다고 보고할 때까지 기다림
    • 모든 구성요소가 준비 완료를 보고하면 Welcome 화면에서 전환함
    • 또는 30초가 지나면 Welcome 화면에서 전환함
  • 단색 배경 문제는 배경화면 준비 보고가 비트맵 로딩 코드 내부에 있었기 때문에 발생함
    • 비트맵 배경이 정의되어 있으면 파일을 찾고, 메모리에 로드하고, 화면에 그린 뒤 Report(WallpaperReady)를 호출함
    • 단색 배경처럼 비트맵이 없으면 해당 코드 경로가 실행되지 않아 WallpaperReady 보고가 발생하지 않음
    • 로그온 시스템은 오지 않을 보고를 기다리다가 30초 제한에 도달함

그룹 정책에서도 반복된 준비 신호 누락

  • 관련 지원 문서에는 “Hide desktop icons” 그룹 정책을 켠 경우에도 30초 지연을 겪을 수 있다고 나와 있음
  • 그룹 정책은 기존 코드 위에 나중에 덧붙는 경우가 많아, “정책이 허용하면 실행” 같은 조건문으로 감싸지기 쉬움
    • 원래 바탕화면 아이콘 초기화 코드는 바탕화면 폴더에 바인딩하고, 아이콘을 열거하고, 화면에 추가한 뒤 Report(DesktopIconsReady)를 호출함
    • 그룹 정책 지원을 추가하면서 이 전체 블록이 정책 조건문 안으로 들어가면, 아이콘 숨김 정책이 활성화된 경우 준비 완료 보고도 실행되지 않음
  • 이 현상은 로그온 작업 자체가 추가로 30초 걸린다는 뜻이 아님
    • 시스템 성능에 따라 원래 모든 준비 보고가 끝나는 시간이 5초일 수도 있고 25초일 수도 있음
    • 문제가 있는 경우 Welcome 화면은 실제 준비 시간과 무관하게 30초 타임아웃까지 유지됨
  • 문서 타임스탬프 기준으로 이 문제는 Windows 7이 2009년 7월 출시된 뒤 몇 달 후인 2009년 11월 수정됨
  • 비트맵 배경을 피하던 이유로는 과거 4MB 또는 8MB 메모리 환경에서 배경화면만으로 약 0.75MB를 쓰는 것이 부담스러웠다는 점이 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 단색 배경을 선호하는 입장에서, 이렇게 단순한 취향이 자주 이상한 토끼굴로 이어지는 게 늘 놀라움
    최신 macOS에서는 사용자 지정 단색 배경을 설정하려 하면 눈부신 흰 화면만 뜸: https://discussions.apple.com/thread/256029958?sortBy=rank
    GNOME은 단색 배경 설정 UI를 모두 없앴지만, 여러 설정 키를 수동으로 바꾸면 기술적으로는 아직 가능하고, 그 키들도 버전마다 무작위로 바뀌는 듯함: https://www.tc3.dev/posts/2021-09-04-gnome-3-solid-color-bac...
    결국 소수 사용자를 위해 반쯤 남겨둔 기능처럼 보이고, 제대로 지원하거나 깔끔하게 제거하는 쪽이 나음. RGB 값을 그냥 넣고 싶지만, 지금 상태라면 불안정한 배경색 로직보다 잘 관리되는 하나의 배경화면 시스템이 더 낫다고 봄

    • KDE에서 확인해 보니, 배경화면 설정에서 wallpaper type: plain color를 고르면 색상 선택기로 지정할 수 있음
      적용할 화면도 보여주고, 모든 화면에 한 번에 적용하는 불리언 옵션도 있음
    • 마지막으로 Android Galaxy 폰을 썼을 때, 완전한 검은색 배경을 쓰려면 Galaxy Store 같은 곳에서 검은 이미지를 다운로드해야 했음
      현대 폰 디스플레이에서 전력 면에서도 합리적이고 보기에도 괜찮은데, 기본 옵션이나 설정의 한 번 탭 스위치여야 할 일이 불신, 검색, 체념을 거치는 잡일이 됐음
    • GNOME에서 단색 배경 UI를 없애고 설정 키 수동 변경만 남긴 건 정말 GNOME다운 경험의 정점임
    • 최근 macOS에서도 단색을 설정해 놨는데 몇 번이나 기본 숲 사진으로 되돌아갔음
      예전 OS X에서는 20년 넘게 잘 되던 기능이라, System Preferences 재작성과 관련이 있어 보임
    • 나도 단색을 선호하지만, 바꾸는 의미가 별로 없다고 느꼈음
      데스크톱 바로가기가 세대를 거치며 남용된 탓에 바탕화면을 보여주는 건 화면 공간 낭비가 됐고, 조심해도 결국 어수선한 황무지가 됨. Windows에서는 특히 그렇고, 그냥 데스크톱을 아무 용도로도 쓰지 않고 여러 모니터에 창을 항상 띄워두는 쪽으로 익숙해졌음

  • 지난 25년간 Windows 세계를 피하다가 최근 몇 년 기업 환경으로 돌아와 보니, Microsoft 도구에서 이런 패턴을 계속 봄
    보안 문제로 Teams는 로드되지 않는데 알림에는 메시지 전체 내용이 뜨거나, Word 클라우드 버전에서 몇 단어를 입력하거나 문서 전체를 붙여넣은 뒤에야 보안 검사가 따라와 민감도 레이블 설정을 요구함
    Microsoft의 웹 앱 소프트웨어 아키텍처가 매우 나쁘다는 신호로 보이고, 데스크톱 앱도 예외는 아닌 듯함

    • Microsoft만의 문제는 아님. 예전 Google Photos도 앱에 사진 접근 권한이 없는데, 내 사진으로 만든 AI 생성 앨범 미리보기 알림을 보냈던 게 기억남
      이후 권한 요청이 따라와서 거부하면 미리보기가 사라졌음
    • Microsoft 제품은 항상 80% 완성이라고 농담하곤 함
      뻔한 사용 사례에서는 아주 잘 작동하지만, 커버하지 않은 경계 사례를 만나면 곧바로 이상한 문제에 부딪힘. 개발자들이 실력이 약하다는 평판은 없으니 기업 문화나 작업 방식 때문일 수 있고, 거대한 사용자 기반에서는 80%가 사업적으로 최적일 수도 있음. 그래도 외부 개발자 입장에서는 가능하면 Microsoft 제품을 피하게 됨
    • 가장 짜증나는 건 Windows 머신이 깊은 절전 능력을 잃었다는 점임
      5년 전에는 완벽히 잠들던 노트북들이 이제는 CPU, 팬, 하드디스크가 계속 도는 24시간 좀비가 됐음
      글에서 말한 것과 비슷한 멍청한 변경이 멀쩡하던 기능을 망가뜨렸고, 10년 된 노트북이 잠든 중에도 AI를 돌려 엿들은 내용 기반 광고를 제안하게 만드는 최신 헛구상에 방해될까 봐 아무도 고치지 않는다고 확신함

  • 이건 그 무렵 시작됐을 법한 관행과 연결됨: 스플래시 화면을 일정 시간만 보여준 뒤, 소프트웨어가 완전히 시작되기 전에 사용자 환경을 먼저 보여주는 방식
    운영체제와 앱 모두 “앱이 너무 오래 걸린다”는 인식을 피하려고 그랬던 것으로 의심됐음. 이제는 사용하기 전에 소프트웨어가 정말 로드됐는지 추측해야 함

    • 기업 정보 시스템 환경에서는 보안·모니터링 시스템 여러 개가 메모리를 스캔하고 차단하며 클라우드에 세세하게 로그를 남길 때까지 기다려야 함
      그다음에야 하부 소프트웨어가 전부 로드되기를 멍하니 기다리는 응답 없는 UI 스레드를 보게 됨
    • 이 30초 제한 시간의 의도는 명확해 보임
      로딩 화면에 영원히 갇혀 다른 OS로 부팅해 고쳐야 하는 상황보다는, 반쯤 망가졌더라도 어쨌든 쓸 수 있는 데스크톱이 낫다는 판단임
    • “소프트웨어가 완전히 시작되기 전에 사용자 환경을 보여주는” 방식은 오늘날 웹 앱으로 옮겨갔음
      뭔가를 하면 UI는 로딩/진행 휠을 보여주지만 실제로는 끝없이 걸리고, 웹페이지 시작 시에는 빈 화면에 자리표시자 막대나 흐릿한 색상 이미지가 뜸. 이게 이른바 반응형 설계라니
    • 이런 경우에는 30초 뒤 “로드된 것으로 간주”하는 제한 시간이 없으면, 버그에 걸린 사용자는 로딩 화면에 영원히 갇힘
      때로는 시스템이 실제로 로드됐다고 낙관적으로 처리하는 편이 사용자에게 더 나음

  • 기본 설정을 거의 모든 곳에서 쓰는 법을 배웠음
    사용자 지정을 유지보수하는 건 너무 번거로워서 그냥 신경 쓰지 않는 게 가장 쉽다. 예외는 어딘가의 신비한 파일에 동기화된 VS Code 설정 약 50줄인데, 아마 GitHub 서버에 있겠지만 내가 볼 수 있는 곳에는 없음

    • 의존하는 도구가 emacs, vim, lf, mpv, fish, foot 등 몇 개뿐이라 시간을 들여 설정한 뒤, Git 저장소에 넣어 어디서나 동기화함
      개인 컴퓨터에서는 stow를 쓰고, 원격 머신에서는 복사-붙여넣기함. 이 도구들이 워낙 안정적이라 Debian stable로 옮겨도 괜찮다는 점이 좋음
    • 사용자 지정 유지보수가 정말 그렇게 번거로운가? 대부분은 원하는 대로 설정하고 나면 문자 그대로 몇 년 동안 그냥 둠
      몇 년 전 Sublime Text 백업을 바로 복원해도 내 사용자 설정은 여전히 작동함
    • 재현 가능하고 자기완결적인 설정은 버그 제보에서도 대부분 같은 이점을 줌
      정기 알림처럼 말하자면, nix는 실제로 좋음
      “버그가 있는데, nixos-rebuild build-vm --flake "github:user/repo#test-vm" && ./result/bin/run-*-vm로 재현 VM을 받을 수 있음”이라고 할 수 있음. 그 VM을 만드는 코드도 보안 악몽 같은 바이너리 덩어리가 아니라 누구나 읽을 수 있는 평범한 nix 표현식이고, 새 머신 적용도 단일 명령으로 끝남
    • 나쁜 기본값을 쓰는 것도 번거롭고, 사용자 지정을 유지보수하는 것보다 훨씬 더 자주 겪게 됨
    • “기본값은 아마 너보다 그 소프트웨어를 더 잘 아는 사람들이 넣어둔 것”이라고 말하던 교수가 있었음
      기본값이 무엇을 하는지 이해하고 있다면, 세상의 모든 옵션을 건드리는 편이 더 번거로울 때가 많음

  • “위안 음식”이라는 표현이 웃김. AIX에서 Linux로 넘어온 뒤로도 여전히 motif window manager에 steelblue4 데스크톱, wheat xterm 배경을 씀
    1989년 대학 시절 처음 접한 기본값이었고, 그 이후 나아진 게 없다고 느낀다. GNOME, KDE 같은 건 속이 메스꺼움

    • 이 글에서의 “위안 음식”은 아무리 크고 고급스러운 팀이라도 모두 정말 멍청한 변경을 프로덕션에 내보낸다는 깨달음임
      범위가 조금 과하게 넓어진 덧댄 if() 래퍼는 고전적인 사례임
    • bb4win에 대한 향수가 있음. 대학 때 알게 됐고, Linux를 처음 접하는 계기였음
      향수는 강력한 약임
    • 4K 모니터를 쓰고 싶어지면 어떻게 할지 궁금함
      비꼬는 게 아니라, motif에서 HiDPI가 실제로 동작하는지 진심으로 궁금함

  • 아주 오래전 Windows를 취미로 쓰던 시절, 특정 Windows 레지스트리 키 값을 편집해 explorer.exe를 cmd.exe로 바꿨음
    그러면 Windows가 explorer.exe를 실행해 배경화면·아이콘이 있는 데스크톱을 띄우지 않았고, UNIX 창 관리자처럼 단색 배경 위에 각 창이 Microsoft cmd.exe 셸로 뜨는 환경이 됐음. 고전적인 Windows 검은 상자에 파란 제목 표시줄과 얇은 회색 테두리가 있는 형태였고, 명령 프롬프트에서 C:\windows\system32의 taskmgr.exe 같은 앱을 실행할 수 있었음
    내게는 explorer.exe를 쓸 때보다 훨씬 빠르고 견고하게 느껴졌고 확실히 가벼웠음. 나중에 Arthur Whitney 글의 사진에서 Windows 데스크톱에 열린 창이 cmd.exe 하나뿐인 장면을 봤는데, 뭔가를 암시하려는 건 아니지만 늘 기억에 남음
    최근 Microsoft 문서에서도 이걸 봤음: https://learn.microsoft.com/en-us/windows/configuration/shel...

    • Windows Server에는 이런 모드가 있거나 있었음
      IoT나 임베디드용 저가/무료 Windows에도 explorer 없이 cmd 전용으로 동작하는 버전이 있었던 것으로 기억함

  • 이런 건 내가 시스템적 버그 또는 “타입 버그”라고 부르는 범주에 들어감
    로그인 컴포넌트에 토큰을 넘기고, 토큰의 소멸자가 자동으로 프로세스 완료를 표시하게 만들었다면 이 버그는 거의 작성 불가능했을 것임
    대신 런타임에서 “컴포넌트들이 이걸 기억해야 함”으로 만들었기 때문에 코드 구조 자체가 버그를 허용함
    몇 년 전 Facebook에도 비슷한 버그가 있었는데, 알림 개수는 알림이 있다고 표시하지만 클릭하면 아무것도 없었음. 개수 갱신 경로와 목록 삽입 경로가 달라서 어긋났고, 둘을 같은 시스템 부분이 관리하도록 바꾸자 해당 버그가 영구히 사라졌음

    • Reddit에서도 잘못된 알림 아이콘이 늘 생김
      항상 나쁜 캐싱 때문이라고 생각해 왔음

  • 약간 메타지만, Raymond Chen 글을 알리는 “Why did happen with” 식 제목을 기대하게 됐음
    항상 흥미로움

    • The Old New Thing은 Windows 기묘함의 훌륭한 모음임
      어릴 때부터 갖고 있던 Windows 관련 컴퓨팅 미신을 유일하게 풀어준 블로그임

  • 해당 코드는 내가 좋아하는 Kubernetes 버그를 많이 떠올리게 함
    if (request.authenticationData) { ok := validate(etc); if (!ok) { return authenticationFailure; } }
    같은 밈이 수십 년을 가로질러 이어진 셈임

    • 이건 “검증하지 말고 파싱하라”는 원칙의 좋은 예임
      어떤 권한이 필요한 모든 함수가 그 권한을 인자로 받게 만들면, 예를 들어 void doFoo(PermissionToDoFoo permission, ...){...}처럼 작성하고, 호출은 인증 데이터에서 권한을 얻는 경로를 통해서만 가능하게 할 수 있음
      그러면 권한 없이 Foo를 수행하는 잘못된 상태를 표현하는 것 자체가 불가능해짐
    • 그 버그는 어디서 읽을 수 있음? 버그가 정확히 뭐였는지도 궁금함
      authenticationData가 없으면 기본적으로 인증된 것으로 처리됐다는 건가?
    • 소프트웨어를 만드는 방식은 수십 년 동안 변하지 않았음

  • 주제와 조금 벗어나지만, 로그인 화면에서 자동으로 새로고침되는 Windows Spotlight 배경화면을 정말 좋아했음
    그래서 그걸 데스크톱 배경화면으로 동기화하는 스크립트도 썼음. 그런데 내 Windows 10에서는 이유 없이 멈춰서, 대신 Bing Image of the Day를 다운로드하는 스크립트를 작성했음: https://blog.est.im/2025/stdout-03

    • Windows 11에서는 Spotlight를 데스크톱 배경화면으로 설정할 수 있음
    • 이를 위한 공식 Bing Wallpaper App(https://www.bing.com/apps/wallpaper)이 있지만, 기본 브라우저를 Edge로 바꾸려는 성가신 요소와 다크 패턴이 온갖 방식으로 들어 있음
    • KDE Plasma에서는 내장 기능임
답변달기