직접 Win32 API, 이상한 모양의 창, 그리고 그것들이 대부분 사라진 이유

요즘 Windows 데스크톱 앱은 React, Electron, Tauri 같은 웹 래퍼 위주로 굳어졌고, 메모리와 성능 면에서 비대해졌다고 비판한다. 반면 예전 Win32 시절에는 창 자체를 직접 제어하면서 더 개성 있는 UI를 만들 수 있었다.

핵심은 Win32 메시지 루프다. GetMessage → TranslateMessage → DispatchMessage로 이어지는 흐름 안에서 WM_CREATE, WM_PAINT, WM_SIZE, WM_DESTROY 같은 메시지를 처리하며 앱의 동작을 구성한다.

이 구조 위에서 이상한 모양의 창도 만들 수 있다.

• 타원형 창: CreateEllipticRgn으로 영역을 만들고 SetWindowRgn으로 창의 실제 영역을 바꾼다.
• 드래그 처리: 제목 표시줄이 없으면 WM_LBUTTONDOWN에서 WM_NCLBUTTONDOWN과 HTCAPTION을 보내 직접 끌 수 있게 만든다.
• 비트맵 기반 창: shape.bmp를 읽어 투명색(예: RGB(255, 0, 255))이 아닌 픽셀을 모두 작은 영역으로 합쳐 창 모양을 만든다.
• 레이어드 창: WS_EX_LAYERED와 UpdateLayeredWindow를 써서 32-bit 알파 이미지를 올리고, 프레임마다 다른 픽셀을 그려 애니메이션 마스코트처럼 동작하게 한다.

이 방식은 단순한 원형이나 사각형을 넘어서, 개가 뛰어다니는 마스코트나 장난감 같은 창을 만들 수 있게 해준다. 창은 더 이상 고정된 직사각형이 아니라, 그 순간의 픽셀 자체가 된다.

다만 대가도 분명하다. 프레임을 버리는 순간부터 드래그, 리사이즈, 닫기, 히트 테스트, 키보드 처리, DPI 대응, 다시 그리기까지 전부 직접 책임져야 한다. 그래서 이런 창은 만들기는 쉽지만, 제대로 다듬는 데는 비용이 크다.

결국 이 글은 Win32가 아직도 이런 표현을 막지 않는다는 점을 보여준다. 대부분의 경우 일반적인 직사각형 창이 맞지만, 창의 형태 자체를 디자인 요소로 삼을 수 있다는 사실을 다시 떠올리게 한다.