메뉴 막대를 없애고 모바일 우선 설계로 대체한 날이 원망스러움. 데스크톱 UI는 Windows 95 무렵에 완성됐고, 이후 버전이 나올 때마다 나빠졌다고 봄. C에서 Windows API를 직접 쓰는 대신 비네이티브 프레임워크와 라이브러리에 점점 더 의존하게 된 것도 아쉬움.
Android에는 언제든 메뉴를 열 수 있는 전용 메뉴 키가 있었지만, Apple의 화면 중심 설계를 따라가느라 없애버렸음.
그것도 불편하지만, 정말 거슬리는 건 앱마다 제각각인 UI임. 웹 개발자들이 Electron 같은 도구로 웹을 감싸서 ‘앱’으로 내놓기 시작한 시기와 정확히 겹침.
Windows 98부터 썼지만, 정점은 Vista / 7이었다고 봄. 초보자에게 충분히 친절하면서도 고급 제어 기능을 희생하지 않았고, 자주 쓰는 기능에 집중할 수 있도록 배치만 개선했음.
Windows 95는 통제된 환경에서 진지하게 사용자 테스트를 진행한 마지막 버전임. NeXT에서 많은 것을 참고한 점도 도움이 됐음.
1998~2002년 무렵 인터페이스 설계를 바라보고 접근하는 방식이 근본적으로 바뀌었음. 1997년 Windows 그룹웨어 회사에서 여름 디자인 인턴으로 경력을 시작했는데, 플랫폼 지침을 준수하고 실제 사용자가 제품을 쓰는 모습을 촬영하며 설계를 검증하는 데 자부심을 갖던 회사였음. 작은 UI 부서에도 산업 디자이너와 인지과학자가 함께 일했음.
5년 뒤 만난 UI 디자이너들은 모두 Photoshop으로 번쩍이는 웹사이트 시안을 그리는 그래픽 디자이너였음. Web 2.0과 함께 과학에 기반한 UI 설계의 전통은 사라지고 감각 위주의 설계가 자리 잡았음. Apple도 예외가 아니었고, 1997년 복귀한 Steve Jobs가 선호한 금속 질감의 QuickTime Player 같은 사용자에게 불친절한 스큐어모피즘도 큰 영향을 끼쳤다고 봄.
데스크톱 GUI는 1990년 NeXTStep에서 완성됐다고 봄. 보기 좋은 그림과 색상을 제외하면 1984년 Smalltalk를 꼽을 수도 있음.
GUI 배치만 다르게 해서 데스크톱·모바일 코드베이스를 통합하는 것도 가능하며, 280 North의 Objective-J/Cappuccino가 이를 입증했음. 이제는 우리가 대체 무엇을 하고 있는지 모르겠음.
최근 Windows 3.1용으로 출시된 1990년대 어린이 CD-ROM 게임을 되살렸음. https://github.com/matthewbloch/orlys-draw-a-story-fixes.
완성된 패치 DLL에는 그동안 무엇이 망가졌는지가 고스란히 담겼음. Windows 11에서도 실행은 됐지만, 핵심은 DirectDraw 이전의 8비트 그래픽 동작이 깨졌다는 점임. 256색 화면에서 팔레트 인덱스를 한 번만 해석하는 반면, 게임은 페이드 효과 등을 위해 팔레트를 바꿀 수 있어야 했음. 그 결과 화면 대부분이 검게 나오고 움직이는 부분만 정상적으로 보였음.
결국 모든 그리기 호출을 가로채 당시 그래픽카드처럼 동작하는 가상 GDI를 구현하는 것이 수정 작업의 대부분을 차지했음. 32비트 디스크 공간 검사에서 오버플로가 발생했고, 해제 후 사용으로 인한 충돌과 CPU가 2개인 환경에서는 테스트하지 않았을 법한 스레드 경쟁 조건도 있었음.
Microsoft의 하위 호환성은 거의 완성돼 있었고, 이후 몇 차례 Windows 버전에서도 Orly를 계속 실행할 수 있었을 듯함. 다만 개발자도 어느 정도 맞춰줘야 하며, 에뮬레이션 계층은 아님.
이런 일에 감탄한다는 사실이 흥미로움. 34년 전 책은 지금도 아무 문제 없이 펼칠 수 있고, 책장에 있는 1896년 책도 에뮬레이터 없이 읽을 수 있음. 너무 도발하려는 건 아니지만, 소프트웨어에서 하위 호환성이 없는 상황에 우리가 얼마나 익숙해졌는지 놀라울 정도임.
몇 주 전 95세 할머니를 찾아갔다가 아직도 옛날 FreeCell을 즐기시는 걸 봤음. 특히 지금은 구하기 어려운 FreeCell Pro였음. https://cards.fandom.com/wiki/FreeCell_Pro.
덕분에 주말 프로젝트를 시작했음. 원작에서 카드 뒷면을 바꾸고 여러 테마의 덱으로 플레이할 수 있는 점이 좋아서, 바이브 코딩으로 좀 더 현대적인 게임을 만들었음. 만들다 보니 로그라이트 모드까지 추가하게 됐음. ‘로그라이트 FreeCell’이 어떻게 들릴지는 알지만, 광고 없이 웹에서 무료로 즐길 수 있음. https://freecellworlds.com/.
버그인지 내가 규칙을 모르는 건지 모르겠음. 가끔 J, 10, 9, 8, 7처럼 길게 이어진 카드 묶음을 Q 위에 놓을 수 없는데 왜 그런가?
Visual Studio에는 아직도 1990년대 초반 모습의 Spy++ 실행 파일이 포함돼 있나?
2026년에도 새 Windows 앱을 Win32 API로 만드는 게 합리적일까? Mac의 QuickLook과 비슷한 간단한 이미지 뷰어를 Win32로 만들었는데 반응성이 매우 좋았음. React보다 코드 가독성은 떨어지지만, UI 상태 머신이 충분히 단순하다면 좋은 선택이라고 봄.
여전히 여러 용도에 괜찮음. AI 덕분에 네이티브 Win32 앱 개발이 아주 쉬워졌음. 예전에는 기반 코드를 작성하는 일이 고역이라 래퍼를 쓰곤 했는데, 이제는 직접 구현해도 됨. 결과물은 성능이 좋고 바이너리가 작으며 즉시 실행되는, Windows 앱다운 앱임.
집에서는 얼마 전 Linux로 옮겨 활용도가 줄었지만 WINE에서도 잘 돌아감. 업무용 작은 유틸리티는 여전히 이 방식으로 만들고 있음.
적절한 절충점은 WPF, 더 정확히는 그 자유·오픈소스 버전 격인 AvaloniaUI라고 봄. 크로스 플랫폼을 지원할 만큼 고수준이고 코드가 과도하게 장황하지 않으면서 자원도 비교적 적게 사용함. 다만 극단적인 최소화를 추구한다면 여전히 Win32가 앞섬.
Win32 API는 훌륭하고 반응성이 좋으며, ATL/WTL과 MFC도 적은 비용으로 유용한 추상화를 제공함. 가장 불편한 점은 DPI 인식이나 테마 적용 컨트롤 등 많은 부분을 수동으로 처리해야 한다는 것임.
기억하기로 이모지 같은 현대적인 텍스트 기능도 GDI로는 지원되지 않아 DirectWrite가 필요함. 그럼에도 이 오래된 API가 여전히 얼마나 유용한지 놀라움.
지금도 C#의 WinForms가 가장 좋다고 봄.
이름이 Raymond Chen이 아니라면 적어도 ATL/MFC는 쓰는 편이 좋을 듯함. 신규 개발은 멈췄지만 지원은 계속됨. 나는 언제든 Qt를 고르겠고, 최소한으로 가고 싶다면 wxWidgets를 쓰겠음.