# Direct Win32 API, 이상한 모양의 윈도우, 그리고 그것들이 대부분 사라진 이유 > Clean Markdown view of GeekNews topic #28586. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28586](https://news.hada.io/topic?id=28586) - GeekNews Markdown: [https://news.hada.io/topic/28586.md](https://news.hada.io/topic/28586.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-16T11:34:19+09:00 - Updated: 2026-04-16T11:34:19+09:00 - Original source: [warped3.substack.com](https://warped3.substack.com/p/direct-win32-api-weird-shaped-windows) - Points: 7 - Comments: 1 ## Topic Body - 현대 Windows 앱은 **웹 기반 프레임워크 의존**으로 인해 느리고 무거워졌으며, 과거 Win32 시절의 **운영체제 수준 제어권**이 사라짐 - Win32 API는 **메시지 루프와 HRGN 객체**를 통해 창의 형태를 자유롭게 정의할 수 있었고, **비표준 창 디자인**이 흔했음 - 비트맵과 **레이어드 윈도우 기술**을 이용하면 투명도와 애니메이션을 가진 **자유로운 형태의 창**을 구현할 수 있었음 - 그러나 커스텀 창은 **기본 기능을 모두 수동 구현해야 하는 복잡성**과 사용자들의 **단순성 선호 변화**로 인해 점차 사라짐 - 그럼에도 Win32는 여전히 **창 제어와 실험의 자유**를 제공하며, **창의적 데스크톱 소프트웨어 제작 가능성**을 유지함 --- ### 현대 Windows 앱의 단조로움과 Win32의 잃어버린 자유 - 최근 Windows 데스크톱 앱은 대부분 **React, Electron, Tauri** 같은 브라우저 래퍼 위에서 동작하며, 느리고 메모리를 과도하게 사용하는 **복잡한 웹 기반 구조**로 변함 - 단순한 메모장조차 50MB의 메모리를 차지하지만, **순수 Win32 C로 작성된 동일 기능 앱은 1.8MB**에 불과함 - 최신 하드웨어에서도 Windows 11 부팅 시 메모리 사용률이 77%에 달함 - 과거 Win32 API로 직접 프로그래밍하던 시절에는 **운영체제 수준의 완전한 제어권**을 가질 수 있었음 - 당시에는 사각형 창에 갇히지 않고, **비표준 형태의 창**을 자유롭게 만들 수 있었음 - Windows XP 시대에는 **Windows Media Player**를 비롯해 다양한 앱이 독특한 외형을 가졌음 ### 과거의 ‘이상한 모양’ 윈도우들 - 한때 Windows 앱은 **정체성과 개성**을 표현하기 위해 다양한 형태로 제작되었음 - 미디어 플레이어는 하드웨어처럼 보였고, 데스크톱 마스코트가 화면을 돌아다녔으며, 유틸리티 패널은 **계기판, 장난감, 외계 콘솔**처럼 디자인됨 - 창의 형태는 사각형일 필요가 없었고, **UI의 목적은 사용성보다 개성**에 가까웠음 - 오늘날 이런 형태가 사라진 이유는 **프로그래머가 더 이상 창 자체를 제어하지 않기 때문**임 - 대부분의 현대 UI 프레임워크는 운영체제를 감추고, 개발자는 제한된 사각형 영역 안에서만 작업함 ### Win32 메시지 기반 구조와 창 제어 - Win32 프로그래밍의 핵심은 **이벤트 메시지 루프**에 있음 - `GetMessage`, `TranslateMessage`, `DispatchMessage`로 구성된 루프가 모든 동작의 기반 - “WM_CREATE”, “WM_PAINT”, “WM_SIZE”, “WM_DESTROY” 등 메시지를 처리하며 창의 동작을 정의함 - **HRGN(Region Object)** 을 사용하면 창의 모양을 자유롭게 변경 가능 - `SetWindowRgn`으로 창에 영역을 지정하면, 그 영역만 실제 창으로 인식됨 - 예시 코드에서는 `CreateEllipticRgn`으로 타원형 창을 만들고, **제목 표시줄이 없는 상태에서 직접 드래그 기능을 구현**함 - “WM_LBUTTONDOWN” 시 “WM_NCLBUTTONDOWN”을 “HTCAPTION”으로 보내 **창 이동을 흉내냄** - 이처럼 **모양을 만드는 것은 쉽지만**, 기본 프레임이 제공하던 기능을 직접 구현해야 하는 점이 핵심 과제임 ### 비트맵 기반 창과 레이어드 윈도우 - “drivenbyimage/main.c” 예제는 **비트맵 데이터로 창의 형태를 정의**함 - “shape.bmp”를 로드해 **투명색(마젠타)** 을 제외한 픽셀을 창 영역으로 설정 - 비트맵은 동시에 **화면에 그려질 이미지이자 창의 실제 형태**로 작동 - 과거 스킨형 앱들이 이런 방식으로 **강아지, 우주선, 라디오, 캐릭터 얼굴** 등 다양한 형태를 구현함 - 하지만 비트맵 기반 영역은 **경계가 단단하고 반투명 표현이 불가능**함 - 부드러운 가장자리나 애니메이션을 위해서는 **레이어드 윈도우(WS_EX_LAYERED)** 가 필요함 - “Animated/” 예제에서는 **투명 알파 채널을 가진 32비트 이미지**를 `UpdateLayeredWindow`로 업로드 - **GDI+** 로 메모리 비트맵에 스프라이트 시트를 그려 프레임을 전환하고, 이를 데스크톱에 표시 - 창의 형태가 고정된 것이 아니라, **현재 픽셀 상태 자체가 창의 모양**이 됨 - 이 방식은 **부드러운 투명도, 프레임별 형태 변화, 자연스러운 애니메이션**을 지원 ### 커스텀 창의 어려움과 문화적 변화 - Win32 API로 커스텀 창을 만들면 **모든 세부 동작을 직접 처리해야 함** - 드래그, 리사이즈, 닫기, 키보드 입력, DPI 대응 등 **기본 창이 자동으로 처리하던 기능을 수동 구현**해야 함 - 프로토타입은 쉽지만, 완성도 높은 제품으로 다듬는 데는 **큰 비용과 노력**이 필요함 - 사용자들은 이런 시각적 실험보다 **안정성과 단순함**을 선호하게 되었음 - 비표준 창은 종종 **광고 프로그램, 툴바, 불필요한 유틸리티**와 연관되어 부정적 인식이 생김 - 결과적으로 “이상한 모양의 창”은 **진지한 소프트웨어보다는 장난스러운 요소**로 여겨지게 됨 ### Win32의 여전한 가능성과 의미 - 그럼에도 Win32는 여전히 **직접 제어와 실험의 자유**를 제공함 - 메시지, 핸들, 그리기 API만으로도 **운영체제 수준의 창 제어**가 가능 - 대부분의 경우 사각형 창이 합리적이지만, **그 형태가 선택일 뿐 강제는 아님**을 상기시킴 - 예제 코드는 GitHub 저장소 [WierdApps](https://github.com/IvRogoz/WierdApps)에 공개되어 있음 - 타원형 창, 비트맵 기반 창, 애니메이션 마스코트 등 세 가지 샘플 포함 - Win32가 여전히 **창의적이고 실험적인 데스크톱 소프트웨어 제작**을 가능하게 함 ## Comments ### Comment 55567 - Author: neo - Created: 2026-04-16T11:34:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47776667) - 이상한 모양의 윈도우는 다시 돌아오지 않았으면 함 단지 만들 수 있다고 해서 만들어야 하는 건 아님 요즘 **React, Electron, Tauri** 같은 브라우저 래퍼로 만든 앱들이 전부 비슷하게 보이는 건, OS의 GUI 프레임워크를 쓰지 않기 때문임 앱이 제각각의 **비표준 위젯**이나 색상, 형태를 쓰면 접근성과 사용성이 망가짐 아이러니하게도 요즘 ‘정체성’을 강조하는 앱들은 대부분 하드웨어 제조사들이 끼워 넣은 **드라이버용 제어판** 같은 것들이고, 그게 가장 형편없는 블로트웨어임 - Electron은 오히려 반대 문제를 만듦. 모든 앱이 제각각 다르게 보여서 **플랫폼 가이드라인**을 따르지 않음 - 접근성은 법적 요구사항도 있는 중요한 부분임. 최신 **크로스플랫폼 GUI 프레임워크**들은 시각장애인을 위한 스크린리더나 HiDPI 지원을 잘 처리함 - 그래도 나는 그런 **특이한 창 형태**가 멋있다고 생각함. 누군가 다시 시도한다면 환영임 - Vista 시절 **WPF와 XAML**로 만든 비표준 UI들을 많이 봤는데, 창 크기 조정이나 모니터 이동 시 스케일링이 엉망이 되어 결국 불편함만 남았음 - 내 생각은 정반대임. 예전처럼 컴퓨터를 **재미있고 멋지게** 만들고 싶음. 지금은 전부 서류철 같음. 인생의 재미있는 부분은 원래 선택적인 것임 - 나는 **Win32**를 좋아하지만, 예전의 이상한 스킨 문화가 지금의 “브랜딩 = 정체성” 사고방식의 전조였다고 봄 그게 결국 **Electron과 반쯤 완성된 위젯 라이브러리**의 난립으로 이어졌음 Blender나 Ardour 같은 특수 앱이 아니라면, 개성 있는 GUI는 우선순위가 아님 - Electron 앱은 전부 똑같이 생겼음. 반면 Winamp 같은 **Win32 스킨**은 최소한 개성이 있었음 지금의 OS들은 개인용이 아니라 기업용임. **Win3.1~XP 시절**이 진짜 개인용 컴퓨팅의 시대였음 - 일반 업무용 앱이라면 네이티브 컨트롤을 쓰는 게 맞지만, **iPad나 스마트기기**처럼 전체 화면을 커스텀 UI로 쓰는 경우엔 멋지고 잘 작동함 - 요즘의 **React 기반 앱들**은 OS와도, 서로 간에도 일관성이 없음 6개월마다 UI가 바뀌는데 UX는 개선되지 않음. 접근성(a11y)은 완전히 잊혀진 상태임 - 예전엔 소프트웨어를 소수 인원이 만들고 오랫동안 안정적으로 유지했음 지금은 빠른 반복과 대규모 팀 중심으로 바뀌었고, **플랫 디자인**이 이런 환경에 맞는 결과물임 **Skeuomorphic 디자인**은 자산을 계속 새로 만들어야 해서 비용이 큼 결국 **속도와 규모**가 우선인 시대가 되었음. 마치 손으로 조각한 가구 대신 **평면 조립 가구**가 대세가 된 것처럼 - 사실 Win32 API에서도 모든 걸 직접 구현할 필요는 없음. 기본 메시지 처리를 **위임(delegate)** 하면 됨 - Skeuomorphic 디자인은 현실 모방이 과해서 **시각적으로 복잡하고 지저분**했음. 방향은 좋았지만 구현이 힘듦 - 결국 **비용 절감**이 이유임. 더 나은 사용성을 포기하고, 자동차의 버튼을 **대형 터치스크린**으로 바꾼 것과 같음 - **HiDPI** 시대가 되면서 예전처럼 픽셀 단위로 UI를 그리기 어려워졌음 예전 Win95~XP 시절엔 **프론트 버퍼에 직접 그려서** 빠르고 메모리도 적게 썼지만, 지금은 각 창마다 백업 버퍼를 유지하느라 RAM을 더 씀 - “The point was usually not usability. It was identity.”라는 문장을 보고 **LLM이 쓴 글** 같다는 생각이 들었음 - 나도 같은 느낌을 받았음. 그래도 글쓴이가 뭔가 말하고 싶었던 건 느껴졌음 - 모든 문장이 **LLM이 생성한 것처럼** 보였음 - 예전에 Windows 앱을 개발했는데, **Win32 인터페이스**는 90% 정도만 제어 가능했음 색상 테마를 바꾸려다 **MessageBox를 직접 재구현**해야 했던 기억이 있음 - 예전엔 **Win32 Hook**으로 MessageBox를 수정할 수 있었음. HCBT_CREATEWND로 HWND를 얻어 **서브클래싱**하면 됨 - 더 깊이 들어가면 **User32.dll** 대신 Win32U.dll을 후킹해야 하는 경우도 있음 - 그걸 직접 다시 만드는 건 고통스러움. **Qt**로 하면 좀 나을까 궁금함 - 순수 Win32 C로 만든 **Notepad**는 1.8MB밖에 안 쓰는데, 요즘 메모장은 50MB나 씀 - 최소한의 “Hello World” 프로그램도 500KB는 필요함. 시스템 라이브러리들이 기본으로 메모리를 차지함 - 최신 **Windows 11 Notepad**는 탭, 스타일 텍스트, AI 기능까지 포함돼서 기본 32MB를 씀 심지어 **GNU Emacs**가 더 적은 메모리를 씀 반면 텍스트 모드의 **EDIT.EXE**는 520KB밖에 안 써서 훨씬 효율적임 - 예전에 Mac용 **Disco**라는 CD 굽기 앱이 있었는데, 디스크를 굽는 동안 창 위로 **연기가 피어오르는 애니메이션**이 나왔음 Steve Jobs가 무대에서 직접 보여주며 좋아했음 - 기사에서 **데스크톱 마스코트** 이야기도 나와서 반가웠음 최근에 [Godot으로 만든 데스크톱 펫 영상](https://youtu.be/x8BO9C6YtlE)을 봤는데, 크로스플랫폼으로 작동함 약간 손이 많이 가긴 하지만, Win32 수준의 복잡함은 아님. **데스크톱 펫 애호가**에게는 좋은 선택임