Windows는 왜 지금의 모습이 되었나: 개발자가 보는 역대 Windows의 진화
· 小村 豪 · Windows, Windows 애플리케이션 개발, 호환성, OS 역사, Win32, .NET, 보안
1. 들어가며
Windows의 역사라고 하면, 겉모습의 변화로 이야기되는 경우가 많습니다.
시작 메뉴가 등장했다. Aero가 도입되었다. 시작 화면이 되었다. 작업 표시줄의 위치가 바뀌었다. 모서리가 둥글어졌다.
물론, 그것도 Windows의 역사입니다.
하지만 Windows 앱 개발자 입장에서 보면, 정말로 큰 변화는 화면 디자인만이 아닙니다. 오히려 중요한 것은 이런 변화들입니다.
- OS의 안정성
- 메모리 보호
- 권한 관리
- 드라이버 모델
- 32비트 / 64비트 대응
- COM, ActiveX, Win32 API와의 호환성
- .NET Framework와 .NET
- UAC
- Windows Update
- 보안 기능
- 스토어 앱과 데스크톱 앱의 공존
- WSL
- TPM, Secure Boot
- 고DPI, 멀티 디스플레이
- 하이브리드 CPU와 절전 제어
Windows는 단순히 겉모습을 바꾸며 진화해 온 OS가 아니라, 오래된 앱을 최대한 계속 돌리면서, 안정성, 보안, 성능, 하드웨어 대응을 조금씩 끌어올려 온 OS입니다. 이 점이 Windows의 재미이자, 동시에 번거로움이기도 합니다.
이 글에서는 역대 Windows를 단순한 연표가 아니라, Windows 앱 개발자가 보는 변화로서 되짚어 봅니다.
2. Windows의 역사는, 두 흐름이 합류하는 역사이기도 하다
Windows의 역사를 이해할 때, 먼저 짚어 두어야 할 것은 Windows에는 크게 두 가지 흐름이 있었다는 점입니다.
가정용 PC를 위해 확산된, Windows 95 / 98 / Me의 흐름. 기업・업무용을 염두에 두고 성장한, Windows NT / 2000의 흐름.
이 두 가지가, Windows XP에서 크게 합류합니다.
flowchart LR DOS["MS-DOS / Windows 3.x"] --> W95["Windows 95 / 98 / Me\n가정용 PC・편의성・주변기기"] NT["Windows NT / 2000\n업무용・안정성・권한 관리"] --> XP["Windows XP\n가정용과 업무용의 통합"] W95 --> XP XP --> VISTA["Windows Vista / 7\nUAC・WDDM・보안 강화"] VISTA --> W8["Windows 8 / 8.1\n터치・스토어・클라우드"] W8 --> W10["Windows 10\n지속적 업데이트・WSL・호환성과 현대화"] W10 --> W11["Windows 11\n보안 기준・현대 하드웨어"]
이 흐름을 모르면, Windows의 지금 모습이 조금 이해하기 어려워집니다.
왜 오래된 API가 남아 있는가. 왜 관리자 권한 문제가 있는가. 왜 32비트 앱이 아직도 동작하는가. 왜 Program Files에 직접 쓰면 문제가 되는가. 왜 드라이버나 주변기기에서 고생하는 일이 있는가.
이런 것들은 단순한 설계 실수라기보다, Windows가 오랜 시간에 걸쳐 현실의 PC 이용을 짊어져 온 결과이기도 합니다.
3. Windows 95 / 98: 가정용 PC를 일반화한 시대
Windows 95는, 오늘날 Windows의 사용성을 결정지은 OS입니다.
시작 메뉴. 작업 표시줄. 최소화, 최대화, 닫기 버튼. Plug and Play. 네트워크 기능. 인터넷으로의 입구.
지금은 당연한 조작이, 이 시기에 상당히 형태를 갖췄습니다.
개발자 시점에서 보면, Windows 95 / 98 시대는 PC가 「일부 전문가가 쓰는 기계」에서 「가정이나 직장에서 평범하게 쓰는 도구」로 바뀌어 가던 시대입니다.
앱을 설치한다. 프린터를 연결한다. 모뎀으로 인터넷에 연결한다. CD-ROM에서 소프트웨어를 설치한다. 디지털카메라나 USB 기기를 다룬다.
이런 이용이 한꺼번에 확산되었습니다.
Windows 98에서는, 인터넷, USB, DVD, 멀티미디어, 가정 내 네트워크 같은 요소가 더욱 강화됩니다.
다만, 이 시대의 Windows에는 DOS에서 유래한 불안정함도 남아 있었습니다.
어떤 앱이 OS 전체를 끌어들인다. 드라이버가 부실하면 블루스크린이 뜬다. DLL 버전이 다르면 다른 앱이 망가진다. 재시작하면 고쳐진다는 알 수 없는 경험 법칙이 통용된다.
이 시대를 아는 사람에게, Windows는 편리한 동시에 조금 무서운 존재였습니다.
4. Windows Me: 가정용 DOS 계열 Windows의 마지막 몸부림
Windows Me는, 평가하기 어려운 OS입니다.
일반적으로는 「불안정했던 Windows」로 이야기되는 경향이 있습니다. 실제로 좋은 기억이 적은 사람도 많을 것입니다.
하지만 Windows Me에도 새로운 시도가 있었습니다.
System Restore. System File Protection. AutoUpdate. 디지털 미디어 기능. 홈 네트워크.
즉, 지금의 Windows에서는 당연해진 「망가지면 되돌린다」「중요 파일을 지킨다」「업데이트를 자동화한다」는 방향성은, 이미 보이고 있었습니다.
다만, 토대로서는 가정용 DOS 계열 Windows의 마지막 단계입니다.
기능적으로는 현대적인 것을 넣으려 하고 있다. 하지만, OS의 기초 체력은 아직 충분하지 않다.
그 격차가, Windows Me의 어려움이었다고 생각합니다.
개발자 시점에서는, Windows Me는 「새로운 경험을 얹으려면, OS의 토대 자체를 바꿀 필요가 있다」고 가르쳐 주는 존재입니다.
그리고 그 답이, NT 계열로의 통합이었습니다.
5. Windows NT / 2000: 업무용 Windows의 토대
가정용 Windows와는 별개로, Windows NT 계열의 흐름이 있었습니다.
NT 계열은, 처음부터 업무 이용을 강하게 염두에 둔 Windows입니다.
안정성. 메모리 보호. 권한 관리. 서비스. 네트워크. 기업 내 관리.
이 흐름의 중요한 도달점이, Windows 2000입니다.
Windows 2000은, Windows 95 / 98에서 길러진 편의성을 받아들이면서, NT 계열의 안정성과 관리성을 전면에 내세운 OS였습니다.
개발자에게 중요한 것은, 이 시점부터 Windows가 「멈춰도 어쩔 수 없는 가정용 OS」가 아니라, 「업무를 지탱하는 플랫폼」으로서의 성격을 강화해 갔다는 점입니다.
Windows 서비스로 상주한다. 이벤트 로그에 기록한다. 사용자 권한을 고려한다. 네트워크 도메인으로 관리된다. 공유 폴더나 프린터와 연동한다.
그런, 지금의 업무용 앱 개발에서는 당연한 전제가, NT 계열 Windows의 맥락에서 자라났습니다.
6. Windows XP: 가정용과 업무용의 통합
Windows XP는, Windows의 역사에서도 특히 중요한 OS입니다. 이유는 단순히 인기가 있었기 때문이 아니라, 가정용 Windows의 흐름과, 업무용 Windows NT 계열의 흐름이, 실용적인 형태로 통합되었기 때문입니다.
Windows XP에 의해, 가정용 PC에서도 NT 계열의 안정성을 전제로 삼을 수 있게 되었습니다. 이것은 매우 큰 변화입니다.
그 전까지의 가정용 Windows에서는, 앱이나 드라이버의 불안정함이 OS 전체를 쉽게 불안정하게 만들었습니다. XP 이후로는, 적어도 기반으로서는 더 안정된 NT 계열을 전제로 삼을 수 있습니다.
한편으로, XP는 매우 오랫동안 사용되었습니다. 이것은 좋은 일이기도 하고, 어려운 일이기도 합니다. 오랫동안 사용됨으로써, 기업 시스템, 사내 도구, ActiveX, COM 컴포넌트, 오래된 주변기기, 업무 전용 소프트웨어가 대량으로 XP 시대의 전제를 안게 되었습니다.
즉 XP는, 현대 Windows의 원형인 동시에, 지금까지 이어지는 레거시 자산의 출발점 중 하나이기도 합니다.
Windows 앱 개발자에게, XP의 교훈은 이것으로 요약됩니다.
OS가 오래 사용되면, 앱의 전제도 오래 남는다.
이것은, 호환성 문제이기도 하고, 업무 연속성 문제이기도 합니다.
7. Windows Vista: 실패로 취급되기 쉽지만, 중요한 전환점
Windows Vista는, 평가가 나빴던 OS로 이야기되는 경우가 있습니다.
무겁다. 경고가 많다. 드라이버가 안 맞는다. 앱이 안 돌아간다. XP가 더 좋았다.
당시의 사용자 경험으로서는, 그런 평가에도 나름의 이유가 있습니다.
하지만 Windows 앱 개발자 입장에서 보면, Vista는 중요한 전환점입니다.
특히 큰 것은, 다음과 같은 부분입니다.
- UAC
- WDDM
- Aero / Desktop Window Manager
- 새로운 드라이버 모델
- 보안 강화
- 64비트 환경의 확산
- Program Files나 Windows 폴더에 대한 쓰기 제한
- 애플리케이션 매니페스트
Vista는, Windows에 「안전하게 쓰기 위한 불편함」을 들여왔습니다.
그전까지의 Windows에서는, 관리자 권한으로 동작하는 것이 당연시되고 있었습니다. 앱도, 설정 파일을 실행 파일과 같은 폴더에 쓴다. 레지스트리의 시스템 영역에 가볍게 쓴다. 설치 프로그램도 앱 본체도 관리자 권한을 전제로 한다.
그런 설계가 드물지 않았습니다.
Vista 이후로는, 그것이 통하기 어려워집니다.
앱은, 어디에 설정을 써야 하는가. 사용자별 데이터는 AppData에 두는가. 전체 사용자 공통 데이터는 ProgramData에 두는가. 관리자 권한이 필요한 처리를, 어디서, 어떻게 사용자에게 설명하는가.
이런 것을 생각하지 않으면, Windows 앱으로서 제대로 동작하지 않게 되어 갔습니다.
Vista는, 사용자 입장에서는 번거로웠을지도 모릅니다. 하지만 긴 안목으로 보면, Windows가 현대적인 보안 모델로 나아가기 위해 필요한 계단이었습니다.
8. Windows 7: Vista의 토대를 실용적으로 만든 OS
Windows 7은, 완성도가 매우 높은 Windows로 기억되고 있습니다.
Vista에서 도입된 큰 변화를, 더 가볍고, 더 사용하기 쉽고, 더 안정된 형태로 정리한 OS입니다.
업무용 Windows로서도 인기가 높았고, Windows 앱 개발 현장에서도 오랫동안 기준 환경으로 취급되었습니다.
Windows 7의 중요한 점은, 「큰 사상 변경」보다 「실용상의 완성도」입니다.
Vista에서 도입된 UAC나 WDDM 등의 방향성은 유지하면서, 사용자 경험이 개선되었습니다.
개발자에게는, Windows 7의 확산으로 인해, Vista 이후의 설계를 전제로 한 앱 개발이 현실적이 되어 갑니다.
예를 들어, 이런 사고방식입니다.
- 표준 사용자로 동작하는 것을 전제로 한다
- 관리자 권한이 필요한 처리는 설치 프로그램이나 별도 프로세스로 분리한다
- 설정 파일의 저장 위치를 적절히 나눈다
- 고DPI나 멀티 디스플레이를 조금씩 의식한다
- 32비트 앱을 64비트 Windows 위에서 돌리는 것을 전제로 한다
- 드라이버나 주변기기의 호환성을 확인한다
Windows 7은, Windows 앱 개발에서 「XP 시대의 작법」에서 「Vista 이후의 작법」으로 옮겨 가기 위한, 현실적인 다리 역할을 했다고 할 수 있습니다.
9. Windows 8 / 8.1: 터치 시대로의 급선회
Windows 8은, 꽤 대담한 OS였습니다.
시작 화면. 라이브 타일. Windows Store. 터치 조작. 차임(Charms). 클라우드 연동.
PC뿐만 아니라, 태블릿도 강하게 염두에 둔 Windows입니다.
방향성으로서는, 결코 틀리지 않았다고 생각합니다.
스마트폰과 태블릿이 급속히 확산되면서, PC에도 터치와 스토어 앱의 사고방식을 받아들일 필요가 있었습니다.
다만, 기존 데스크톱 사용자에게는 변화가 급했습니다.
시작 메뉴가 사라진 것처럼 보인다. 화면 전체가 전환된다. 마우스와 키보드 중심의 업무용 PC에서는, 조작의 맥락이 너무 많이 바뀐다.
그 결과, Windows 8은 평가가 나뉘는 OS가 되었습니다.
개발자 시점에서 보면, Windows 8은 「Windows에는 여러 앱 모델이 공존한다」는 현실을 강화한 OS입니다.
기존의 Win32 데스크톱 앱. .NET Framework 앱. WPF 앱. 스토어 앱. WinRT. 터치를 전제로 한 UI.
같은 Windows 위에, 여러 작법이 나란히 존재하게 되었습니다.
이것은 혼란스러움이기도 합니다. 하지만 동시에, Windows다움이기도 합니다.
새로운 것을 들여온다. 하지만, 오래된 것을 바로 버리지는 않는다.
이런 자세는, Windows 10 이후에도 계속 이어집니다.
10. Windows 10: 서비스로서의 Windows
Windows 10의 큰 특징은, Windows가 「몇 년마다 새로 사는 OS」에서 「계속해서 업데이트되는 OS」로 바뀐 것입니다.
Windows as a Service. 기능 업데이트. 누적 업데이트. Windows Defender의 강화. Microsoft Edge. WSL. 가상화 관련 기능. 클라우드와의 연동.
Windows 10에서는, Windows 그 자체가 항상 업데이트된다는 전제가 되었습니다.
이것은 사용자에게도, 개발자에게도 큰 변화입니다.
예전에는, Windows XP, Windows 7처럼, 특정 OS 버전을 오랫동안 기준으로 삼을 수 있었습니다. 하지만 Windows 10 이후로는, 같은 Windows 10이라도 버전이 다릅니다.
1507, 1511, 1607, 1703, 1709, 1809, 1903, 2004, 21H2, 22H2.
세세한 차이를 모두 의식할 필요는 없지만, 개발자는 「Windows는 계속 업데이트된다」는 전제를 가질 필요가 생겼습니다.
이것은, 테스트에 대한 사고방식에도 영향을 미칩니다.
- Windows Update 이후에 문제가 생기지 않는가
- 보안 기능 강화로 설치 프로그램이 멈추지 않는가
- 백신 소프트웨어와 충돌하지 않는가
- .NET Framework나 런타임 상태에 너무 의존하고 있지 않은가
- 기존 주변기기나 드라이버가 최신 Windows에서도 동작하는가
- WSL이나 가상화 기능과의 공존에 문제가 없는가
Windows 10은, 호환성을 유지하면서 현대화한다는, 매우 Windows다운 난제에 도전한 OS였습니다.
11. Windows 11: 보안 기준과 현대 하드웨어의 시대
Windows 11에서는, 겉모습도 바뀌었습니다.
가운데로 정렬된 작업 표시줄. 둥근 느낌의 UI. 새로운 시작 메뉴. Snap Layouts. 새로운 Microsoft Store.
하지만, 개발자 시점에서 보면 더욱 중요한 것은 보안 기준과 하드웨어 전제의 변화입니다.
Windows 11에서는, TPM 2.0, UEFI, Secure Boot, DirectX 12 지원 GPU, WDDM 2.0 드라이버 등, 시스템 요구 사항이 올라갔습니다.
이것은 단순한 배제가 아니라, OS의 보안 기능, 신뢰성, 업데이트 가능성, 현대적인 하드웨어 기능을 전제로 삼기 위한 판단입니다.
물론, 오래된 PC나 오래된 주변기기를 쓰고 있는 현장에게는 고민스러운 이야기입니다. 하지만, Windows가 앞으로도 안전한 업무 기반으로 남으려면, 어딘가에서 전제를 끌어올릴 필요가 있습니다.
개발자에게 Windows 11은, 이런 시대를 보여 줍니다.
- 보안 기능을 전제로 한다
- 고DPI, 멀티 화면, 터치, 펜, 음성 입력 등을 전제로 한다
- GPU나 디스플레이 드라이버의 세대 차이를 의식한다
- P코어/E코어 같은 하이브리드 CPU를 의식한다
- 절전 설정이나 백그라운드 실행의 영향을 고려한다
- 클라우드 계정이나 관리 정책과의 관계를 고려한다
Windows 앱의 성능이나 안정성은, 이제 코드만으로는 결정되지 않습니다.
OS 버전, 업데이트 상태, 보안 설정, 전원 설정, CPU 구성, 드라이버, 권한, 주변기기. 이들을 포함해서, 실행 환경으로 봐야 합니다.
12. 개발자 시점에서 보는 Windows의 진화
역대 Windows를, 개발자 시점에서 대략 정리하면 이 표와 같습니다.
| 시대 | 대표적인 Windows | OS로서의 변화 | 개발자에게 미친 영향 |
|---|---|---|---|
| 가정용 PC의 확산 | Windows 95 / 98 | 시작 메뉴, 작업 표시줄, Plug and Play, 인터넷 대응 | 설치 프로그램, DLL, 주변기기, 네트워크 대응이 중요해짐 |
| 가정용 DOS 계열의 막바지 | Windows Me | System Restore, AutoUpdate, 디지털 미디어 | 새 기능을 얹으려면 OS의 기초 체력이 필요하다는 것이 보였음 |
| 업무용 기반 | Windows NT / 2000 | 안정성, 권한 관리, 서비스, 네트워크 관리 | 업무용 앱, 상주 처리, 이벤트 로그, 권한 설계가 중요해짐 |
| 통합의 성공 | Windows XP | 가정용과 업무용의 통합, NT 계열의 일반화 | XP를 전제로 한 업무 자산이 대량으로 생겨남 |
| 보안 전환 | Windows Vista | UAC, WDDM, 드라이버 모델, 64비트 | 관리자 권한을 전제로 한 설계가 통하기 어려워짐 |
| 실용화 | Windows 7 | Vista의 개선, 안정성, 업무 이용에서의 확산 | Vista 이후의 작법이 실무에 정착함 |
| 터치와 스토어 | Windows 8 / 8.1 | 시작 화면, 스토어 앱, 클라우드 연동 | Win32와 새로운 앱 모델의 공존이 과제가 됨 |
| 지속적 업데이트 | Windows 10 | Windows as a Service, Defender 강화, WSL | OS 업데이트를 전제로 한 테스트가 필요해짐 |
| 현대 하드웨어 | Windows 11 | TPM, Secure Boot, UI 개편, 현대 CPU/GPU | 보안, 전원, CPU, 드라이버까지 포함한 설계가 필요해짐 |
이 표에서 보이는 것은, Windows가 단순히 「새로워진」 것이 아니라는 점입니다. 오래된 호환성을 안은 채로, 새로운 안전성과 새로운 하드웨어에 대응해 왔습니다.
그렇기 때문에, Windows 앱 개발에서는 최신 API만 봐서는 부족합니다.
오래된 COM 컴포넌트가 남아 있을 수도 있다. ActiveX를 사용한 업무 흐름이 남아 있을 수도 있다. 32비트 DLL이 필요할 수도 있다. 프린터 드라이버나 USB 기기가 오래되었을 수도 있다. 관리자 권한 없이 사용해야 할 수도 있다. Windows Update로 동작이 바뀔 수도 있다.
그것이 Windows입니다.
번거롭습니다.
하지만, 그 번거로움은, Windows가 현실의 업무를 오랫동안 짊어져 온 증거이기도 합니다.
13. Windows 앱 개발에서, 역사를 알고 있으면 도움이 되는 것
Windows의 역사를 알고 있으면, 실무에서의 시각이 달라집니다.
예를 들어, 앱이 실행되지 않을 때.
단순히 「버그입니다」라고는 단정할 수 없습니다.
32비트 / 64비트 문제일 수도 있다. 필요한 .NET Framework가 없는 것일 수도 있다. VC++ 런타임이 없는 것일 수도 있다. COM 등록이 깨진 것일 수도 있다. UAC로 쓰기가 실패하고 있는 것일 수도 있다. 백신 소프트웨어에 막히고 있는 것일 수도 있다. 오래된 프린터 드라이버가 영향을 주고 있는 것일 수도 있다. 고DPI로 화면이 깨지고 있는 것일 수도 있다. Windows Update 이후의 동작 차이일 수도 있다. 절전 설정으로 성능이 나오지 않는 것일 수도 있다.
Windows 앱 개발에서는, 앱 단독만 보는 것이 아니라 환경 전체를 볼 필요가 있습니다.
이것은 번거롭습니다. 하지만, 그만큼, 현장에서 동작하는 소프트웨어를 만드는 가치가 있습니다.
14. 실무에서 봐야 할 체크리스트
기존 Windows 앱의 개편이나 신규 개발에서는, 최소한 다음과 같은 관점을 가지고 있으면 안심할 수 있습니다.
- 대상 OS는 Windows 10인가, Windows 11인가
- Windows 10인 경우, 지원이나 ESU, LTSC의 취급은 어떻게 되어 있는가
- 32비트 앱인가, 64비트 앱인가
- 32비트 DLL이나 COM 컴포넌트에 의존하고 있지 않은가
- 관리자 권한 없이 일반 조작을 할 수 있는가
- Program Files에 설정을 쓰고 있지 않은가
- 사용자별 데이터는 AppData, 공통 데이터는 ProgramData로 나누어져 있는가
- UAC 상승이 필요한 처리를 분리하고 있는가
- 설치 프로그램, 업데이트 처리, 제거 처리가 안전한가
- .NET Framework, .NET, VC++ 런타임 등의 의존 관계가 명확한가
- 고DPI, 멀티 디스플레이, 원격 데스크톱에서 화면이 깨지지 않는가
- 프린터, USB 기기, 시리얼 통신, 카메라 등 주변기기와 호환성이 있는가
- Windows Update 이후에도 동작을 확인할 수 있는 체계가 있는가
- Windows Defender나 타사 보안 소프트웨어와의 호환성을 확인하고 있는가
- 절전 설정이나 CPU 구성의 차이로 성능이 바뀔 수 있음을 상정하고 있는가
- 오류 시에 로그를 남기고, 현장에서 상황을 회수할 수 있는가
이 체크리스트는 단순한 개발 기법이 아니라, Windows가 쌓아 온 역사 그 자체입니다.
15. Windows는 오래된 것이 아니라, 쌓여 있는 것이다
Windows는, 흔히 「오래되었다」는 말을 듣습니다. 확실히 오래된 부분은 있습니다.
Win32 API도 있습니다. COM도 있습니다. 레지스트리도 있습니다. DLL 문제도 있습니다. 오래된 컨트롤도 있습니다. 호환성을 위해 남아 있는 동작도 있습니다.
하지만, 그것을 단순히 오래되었다고 잘라내기만 해서는, Windows의 본질이 보이지 않습니다. Windows는, 오래된 것을 안은 채로, 새로운 것을 쌓아 올려 온 OS입니다. 정돈된 정원이라기보다, 계속 증축을 이어 온 거대한 도시에 가깝다고 하는 것이 딱 맞습니다.
새 건물이 있다. 오래된 골목도 있다. 지하에는 옛날 배관이 지나가고 있다. 편리한 고속도로도 있다. 공장도 병원도 학교도 관공서도, 그 도시 안에서 움직이고 있다.
개발자는, 그 도시 안에서 앱을 만듭니다.
그러니까, 최신 길만 알아서는 부족합니다. 오래된 길이 왜 남아 있는지도, 조금은 알아 둘 필요가 있습니다.
16. 정리
Windows의 역사는, 겉모습의 역사만이 아닙니다. 호환성을 유지하면서, 안정성, 보안, 성능, 하드웨어 대응을 어떻게 끌어올려 왔는가의 역사입니다.
Windows 95 / 98은, PC를 가정과 직장으로 넓혔습니다. Windows NT / 2000은, 업무용 OS로서의 안정성과 관리성을 키웠습니다. Windows XP는, 그 두 가지를 통합했습니다. Windows Vista는, 보안과 드라이버 모델의 큰 전환점이 되었습니다. Windows 7은, 그 전환을 실용적으로 만들었습니다. Windows 8은, 터치와 스토어라는 새로운 방향으로 발을 내디뎠습니다. Windows 10은, 계속해서 업데이트되는 Windows를 정착시켰습니다. Windows 11은, 보안 기준과 현대 하드웨어에 대한 대응을 더욱 진행하고 있습니다.
Windows는, 깨끗하게 정리된 이상향이 아닙니다. 현실의 업무, 오래된 자산, 주변기기, 보안 요구, 새로운 하드웨어를 동시에 안은 채 계속 움직여 온, 거대하고 복잡한 플랫폼입니다.
그렇기 때문에, Windows 앱 개발에서는 「지금의 Windows만」을 보는 것이 아니라, 과거로부터 이어져 온 설계 사상과 호환성의 역사를 이해하는 것이 중요합니다.
오래된 자산을 함부로 버리지 않는다. 하지만, 새로운 안전성과 실행 환경에도 대응한다.
그 균형 위에, 지금의 Windows가 있습니다. 그리고, 그 위에서 확실하게 동작하는 소프트웨어를 만드는 데에는, 지금도 큰 가치가 있습니다.
참고 자료
- Die Geschichte von Windows - Microsoft News Center
- Microsoft Windows 98 Second Edition Released to Manufacturing
- Microsoft Windows Millennium Edition Released to Manufacturing
- Microsoft Announces Immediate Availability Of Windows Millennium Edition
- Windows 2000 Offers Significant Value for Small Businesses
- User Account Control and remote restrictions - Microsoft Learn
- WDDM Overview - Microsoft Learn
- Windows 8 Arrives - Microsoft Source
- Windows as a Service 개요 - Microsoft Learn
- Windows 10 Home and Pro - Microsoft Lifecycle
- Windows 11 available on October 5 - Windows Experience Blog
- Windows 11 System Requirements - Microsoft Support
- Windows 11 release information - Microsoft Learn
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
Windows 위장 토큰을 올바르게 다루기 - 스레드 단위 권한 대여와 안전한 복원 방법
Windows의 위장 토큰에 대해 액세스 토큰, 기본 토큰, 스레드 토큰, 위장 레벨, RevertToSelf, .NET의 WindowsIdentity.RunImpersonated까지, 실무에서 안전하게 다루기 위한 사고방식을 정리합니다.
WinForms/WPF 앱에 Entra ID 인증 넣기 ── MSAL.NET과 WAM 브로커 실무 구성
WinForms/WPF 데스크톱 앱에 Entra ID(구 Azure AD) 인증을 도입하는 절차를 실무 관점에서 정리합니다. 퍼블릭 클라이언트의 개념, ROPC 폐지 현황, 앱 등록, MSAL.NET의 AcquireTokenSilent 패턴, W...
Windows의 세션 분리를 어떻게 이해할까 ── Session 0・RDP・다중 사용자 동시 실행
Windows 앱 개발자가 혼란스러워하기 쉬운 '세션' 개념을 정리합니다. 서비스가 UI를 표시할 수 없는 Session 0 분리의 이유, RDP 접속 시 세션의 동작, 명명된 개체의 세션 분리, 공유 PC・RDS 환경에서 흔히 발생하는 설계 실...
Windows 앱의 중복 실행 방지 ── 네임드 Mutex와 재실행 시 창 활성화
업무용 Windows 앱의 정석 요건인 「같은 앱을 두 번 실행시키지 않는다」를 네임드 Mutex로 구현하는 방법을 정리합니다. Global\ 과 Local\ 네임스페이스의 차이로 인한 RDP 환경의 함정, 소유 스레드 제약과 AbandonedM...
C#에서 Win32 API를 안전하게 호출하기 — P/Invoke 실무 가이드(DllImport / LibraryImport / CsWin32)
C#에서 P/Invoke로 Win32 API나 네이티브 DLL을 호출할 때의 실무 포인트를 정리합니다. DllImport와 LibraryImport의 차이, CsWin32를 이용한 시그니처 자동 생성, 문자열 마샬링의 함정, SafeHandle을...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.
자주 묻는 질문
이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.
- Windows XP는 왜 Windows 역사에서 중요한가요?
- 가정용 Windows(95/98/Me)의 흐름과, 업무용 Windows NT/2000의 흐름이 XP에서 실용적인 형태로 통합되었기 때문입니다. 이로써 가정용 PC에서도 NT 계열의 안정성을 전제로 삼을 수 있게 되었습니다. 한편 XP는 매우 오랫동안 사용되었기 때문에, 기업 시스템, ActiveX, COM 컴포넌트, 오래된 주변기기 등이 XP 시대의 전제를 대량으로 안고 있게 되었고, 지금까지 이어지는 레거시 자산의 출발점 중 하나가 되기도 했습니다.
- Windows Vista는 실패작이었나요?
- 당시 사용자 경험으로는 「무겁다」「경고가 많다」「드라이버가 안 맞는다」라는 악평에 나름의 이유가 있었지만, 개발자 시점에서는 중요한 전환점입니다. UAC, WDDM, 새로운 드라이버 모델, 64비트 환경의 확산, Program Files에 대한 쓰기 제한 등이 도입되어, 관리자 권한을 전제로 한 앱의 설계가 통하기 어려워졌습니다. Windows가 현대적인 보안 모델로 나아가기 위해 필요했던 계단이었다고 할 수 있습니다.
- Windows 10에서 개발자에게 무엇이 바뀌었나요?
- Windows가 「몇 년마다 새로 사는 OS」에서 「계속해서 업데이트되는 OS」(Windows as a Service)로 바뀐 것이 가장 큰 변화입니다. 같은 Windows 10이라도 1507부터 22H2까지 버전이 다르기 때문에, 특정 OS 버전을 오랫동안 기준으로 삼는 사고방식이 통하지 않게 되었습니다. Windows Update 이후에 문제가 생기지 않는지, 보안 기능 강화로 설치 프로그램이 멈추지 않는지 등, OS가 계속 업데이트된다는 전제로 테스트할 필요가 생겼습니다.
- Windows 11의 시스템 요구 사항은 왜 올라갔나요?
- Windows 11에서는 TPM 2.0, UEFI, Secure Boot, DirectX 12 지원 GPU, WDDM 2.0 드라이버 등이 요구 사항이 되었습니다. 이것은 단순히 오래된 PC를 배제하려는 것이 아니라, OS의 보안 기능, 신뢰성, 업데이트 가능성, 현대적인 하드웨어 기능을 전제로 삼기 위한 판단입니다. Windows가 앞으로도 안전한 업무 기반으로 남기 위해서는, 어딘가에서 전제를 끌어올릴 필요가 있었다는 뜻입니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크