▲

macOS Tahoe에서 창 크기 조정 문제, 여전히 이어지는 이야기

 (noheger.at)
1P by GN⁺ 11시간전 | ★ favorite | 댓글 1개
  • macOS 26.3의 창 크기 조정 버그 수정 여부를 검증하기 위해 테스트 애플리케이션을 제작
  • 픽셀 단위 스캔을 통해 창 모서리 주변의 클릭 반응 영역을 분석, 색상별로 반응 상태를 시각화
  • 수정된 RC 버전에서는 모서리 반경을 따르는 곡선형 영역으로 변경되어 개선된 모습 확인
  • 그러나 수직·수평 전용 조정 영역 두께가 7픽셀에서 6픽셀로 감소, 조작 정확도가 낮아짐
  • 최종 릴리스에서는 수정이 완전히 제거되어 이전 사각형 영역으로 복귀, 릴리스 노트에서도 “Resolved Issue”가 “Known Issue”로 변경됨

macOS 26.3 RC 버전의 변경 사항

  • macOS 26.3 RC 릴리스 노트에는 이전 블로그에서 제기된 창 크기 조정 문제 해결이 명시됨
    • 이에 따라 테스트 애플리케이션을 제작해 실제 변경 사항을 검증
  • 테스트 앱은 창의 오른쪽 하단 모서리 주변을 픽셀 단위로 스캔하며, 마우스 클릭 반응을 색상으로 표시
    • 빨강: 클릭 반응 있음
    • 초록: 크기 조정 가능
    • 노랑: 수직 또는 수평만 조정 가능
    • 파랑: 마우스 이벤트 없음
  • 결과적으로 창 크기 조정 영역이 사각형 대신 모서리 곡선을 따르는 형태로 변경되어 시각적 일관성이 향상됨
  • 그러나 노란색 영역의 두께가 3픽셀에서 2픽셀로 줄어, 전체 두께가 7픽셀에서 6픽셀로 감소
    • 이는 약 14% 감소로, 사용자가 조정 영역을 놓칠 확률이 높아짐

macOS 26.3 최종 릴리스의 회귀

  • 최종 버전에서 동일한 테스트를 다시 수행한 결과, RC 버전의 수정이 완전히 제거됨
    • 창 크기 조정 영역이 다시 기존의 사각형 형태로 복귀
  • Apple의 릴리스 노트에서도 해당 문제의 상태가 “Resolved Issue”에서 “Known Issue”로 변경
    • 즉, 문제 해결이 철회되고 여전히 인식된 버그로 남아 있음
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • 처음 Linux의 윈도우 매니저(WM) 를 접했을 때부터, 창 이동과 크기 조절은 각각 super+lmb/rmb 조합이 가장 효율적이라고 믿음
    더 이상 픽셀 단위로 헤더나 모서리를 맞출 필요가 없다는 점이 최고임
    관련 논의는 Reddit 스레드에서도 볼 수 있음

    • 예전에 Sawfish 윈도우 매니저를 썼는데, 유지보수가 중단되기 전까지는 정말 좋았음
      그중에서도 어떤 창이든 자유롭게 크기 조절할 수 있었던 점이 가장 그리움
      세로 모니터를 쓰다 보면, 고정 크기의 모달 창들이 불필요하게 스크롤바를 달고 있는 게 아쉬움
    • Linux에서는 닫기/최소화/최대화 단축키까지 익히면, 아예 창 테두리와 타이틀바를 제거할 수도 있음
      화면 공간을 완전히 확보할 수 있는 셈임
    • macOS에서는 Control+Command 조합으로 창 드래그를 활성화할 수 있음
      defaults write -g NSWindowShouldDragOnGesture -bool true 명령으로 설정 가능하며, 세 손가락 드래그와 함께 쓰면 경계선에서의 리사이즈 문제는 거의 없음
    • Linux를 처음 썼을 때부터 이 기능을 보고, 왜 다른 OS들은 이걸 그대로 복사하지 않았는지 의문이었음
    • 최근 업무용으로 새 Mac을 쓰게 되었는데, Hyprland에서 넘어오니 적응이 쉽지 않았음
      Aerospace와 Karabiner-Elements로 대부분의 워크플로우를 복제했지만, 여전히 super+우클릭으로 리사이즈하는 기능이 그리움
      그래도 ctrl+cmd+좌클릭으로 창 이동이 되는 건 꽤 괜찮음

  • 화면은 점점 커지는데, UI 요소는 오히려 작아지고 클릭하기 어려워지는 느낌임
    예전 Macintosh 640x480 시절에는 창 컨트롤이 명확하고 누르기 쉬웠음
    관련 회고는 이 블로그 글에서도 볼 수 있음

    • 예전 EGA 620x200 시절부터 창 조작 영역의 픽셀 크기는 거의 변하지 않은 듯함
      지금은 ppi가 200 이상인 디스플레이도 많은데, 여전히 같은 픽셀 단위로 유지되는 건 비효율적임
      차라리 타일링 윈도우 매니저로 돌아가서 키 하나로 크기 조절을 없애는 게 나을지도 모름
    • 1994년 System 7 시절부터 Mac을 써왔는데, Snow Leopard(10.6) 때가 안정성과 속도 모두 최고였다고 느낌
      특히 블랙북 시절의 터치패드와 키보드 품질이 뛰어났고, 멀티모니터 지원도 훌륭했음
      만약 구형 MacOS의 디자인 철학이 현대 하드웨어와 결합된다면 어떤 결과가 나올지 궁금함
    • 4K 모니터를 쓰는 UX 디자이너들이 실제로는 2K 해상도로 낮춰서 작업하는 걸 보면, “큰 화면인데 작게 보이는” 문제는 진짜임

  • 픽셀 두께가 7에서 6으로 줄어들면 14% 줄어드는 셈이지만, 실제로 클릭 실패 확률이 정확히 14% 증가하는 건 아님
    사용자의 클릭은 균등 분포가 아니라 중앙에 치우쳐 있기 때문임

    • 하지만 분포를 모르는 이상, 오히려 실패 확률이 더 높을 수도 있음
    • 반대로, 클릭 이벤트가 창 관리자에 의해 가로채이지 않고 애플리케이션으로 전달될 확률은 높아질 수도 있음
    • 나도 같은 생각을 했지만, 너무 꼬치꼬치한 사람처럼 보일까봐 말하지 않았음

  • 최근 Apple의 업데이트는 macOS, iOS, iPadOS 전반에서 버그를 더 많이 도입하는 느낌임
    내부에 사용자 이익보다 조직 논리에 우선하는 그룹이 있는 듯함

    1. 외부 모니터 연결 시 디스플레이 재배치가 매번 필요함
    2. AirDrop이 이유 없이 작동 중단됨
    3. 기기간 복사-붙여넣기가 불안정함
    4. PDF 스크롤 시 Preview 앱이 크래시됨
      이런 문제들이 새로 생긴 걸 보면, Apple의 내부 품질 관리가 심각하게 흔들리고 있음
    • Ethernet 케이블을 꽂은 상태에서 Wi-Fi를 켜면 macOS가 완전히 크래시 후 재부팅됨
      경고 메시지도 없이 그냥 다운됨
    • Microsoft처럼 Apple도 내부적으로 AI 사용을 강제하는지 궁금함

  • 이번 변경사항은 RC 버전에서 수정됐다가 최종 릴리스에서 되돌려졌음
    뭔가 회귀나 부작용이 있었던 듯한데, 정확히 어떤 문제가 있었는지 궁금함

    • 일부 NSWindow 스타일이 깨졌다는 보고가 있었음 (Apple Developer 포럼)
    • 기술적인 이유일 수도 있음
      예를 들어 두 창의 모서리가 겹칠 때, 단순히 bounding box로 처리하던 걸 실제 그래픽 마스크로 계산해야 하는 상황이 생겼을 수 있음
      혹은 단순한 버그나 크래시였을 수도 있음
    • 어쩌면 Apple이 둥근 모서리 디자인을 없애려는 계획이 있어서 되돌린 걸 수도 있음
    • 아마도 공개 테스트에서 사용자 반응이 좋지 않아 보류했을 가능성이 높음
    • 이런 단순한 수정조차 Apple 내부에서 배포하기 어려운 걸 보면, 조직 구조의 복잡성이 느껴짐
      오히려 왜 이 버그가 그렇게 빨리 처리됐는지가 더 흥미로움

  • UI의 히트 테스트(hit testing) 는 수십 년 전부터 해결된 문제인데, 여전히 논쟁이 있다는 게 놀라움
    둥근 모서리조차 기술적으로 어렵지 않은데, 내부에서 디자이너와 개발자 간의 갈등이 있었던 게 아닐까 추측함

    • Mobile Safari의 터치 히트 테스트는 특히 끔찍함
      컨트롤 근처를 터치하면 엉뚱한 요소가 반응하는 경우가 많음
      CSS에서 탭 영역(tap zone) 을 제어할 수 있으면 좋겠지만, 지금은 HTML 요소를 추가하거나 onclick 핸들러를 억지로 넣어야 함
      iOS 26 Safari에서는 탭 이벤트를 가로채는 새로운 문제도 생김

  • 몇 달 동안 이유 없이 창 크기 조절이 안 되는 버그가 있었는데, 원인은 두 모니터에 걸친 창이었음
    창이 두 화면에 몇 픽셀이라도 걸치면 리사이즈가 불가능해짐

    • macOS의 외부 모니터 관리는 정말 혼란스러움
      창 위치가 유지되거나, 엉뚱한 화면으로 이동하거나, 심지어 보이지 않는 영역에 생기기도 함
      Apple이 창을 타일이나 전체화면으로만 쓰게 유도하는 이유를 알 것 같음
      Windows나 Linux보다도 더 불안정함
    • 설정 어딘가에서 이 기능을 끌 수 있는데, 막상 꺼보니 오히려 그 상태가 더 편했음
    • super+화살표로 창을 모니터 경계에 정확히 맞추는 단축키를 쓰면 이런 문제를 피할 수 있음
      이제는 마우스로 직접 드래그할 일이 거의 없음

  • 완벽하진 않지만 BetterTouchTool로 세 손가락 더블탭으로 리사이즈 모드를 토글할 수 있음
    Yabai를 쓰면 SIP를 완전히 끄지 않아도 되고, HYPER 키로 창 이동도 가능함
    커서 움직임으로 창을 조정하고, 키를 놓으면 즉시 멈춤

  • Mac에서 창 리사이즈 앱을 여러 개 써봤지만, Windows PowerToys의 FancyZones만큼 좋은 건 없었음
    복잡한 단축키나 핫코너는 원하지 않음
    내가 원하는 건 두 가지임

    1. 사전 정의된 영역
    2. 두 창의 공유된 경계선 리사이즈
      구독 없이 이런 기능을 제공하는 앱이 있으면 좋겠음
    • 유료이긴 하지만 Rectangle Pro가 가장 근접한 솔루션임
      하지만 나는 직접 Hammerspoon을 설치해 Lua로 스크립트를 작성함
      두 개의 1440p 모니터에 맞춘 커스텀 설정이라 코드가 단순하고 수정도 쉬움
      Hammerspoon 공식 사이트와 내 스크립트 예시를 참고할 수 있음
    • Swish는 여러 창을 동시에 리사이즈할 수 있고, BentoBox는 FancyZones에서 영감을 받음
      Lasso는 그리드 기반 레이아웃을 제공하며, MacsyZones는 오픈소스 형태로 유사 기능을 제공함
      Swish, BentoBox, Lasso, MacsyZones
    • PowerToys는 좋지만 1.17GB 용량을 차지하는 건 너무 과함

  • 기본 Gnome이 더 낫다고 느껴질 정도면 상황이 심각함

    • 최근 KDE Plasma로 옮겼는데, 다시 각진 창 모서리를 쓸 수 있어서 만족함
    • Fedora의 Gnome 구현을 좋아함
      Mac으로 돌아가면 왜 Spotlight와 Mission Control이 따로 존재하는지 이해가 안 됨
    • Windows나 Gnome의 창 스냅 기능이 그리움
      Win 키로 앱 전체 보기, 반쪽 화면 정렬, 전체화면이 아닌 최대화 등은 macOS보다 훨씬 직관적임
답변달기