내 PC의 주인은 누구인가

PC는 오랫동안 사용자가 직접 통제하는 기기였다.

운영체제를 설치하고, 로컬 계정을 만들고, 파일을 자신의 저장장치에 보관한다.
인터넷은 필요할 때 연결했고, 클라우드는 필요하다면 추가로 사용하는 서비스였다.

적어도 과거에는 PC가 먼저 존재하고, 온라인 서비스가 그 위에 올라가는 구조에 가까웠다.

그런데 최근 Windows를 사용하다 보면 이 관계가 조금씩 반대로 움직이고 있다는 느낌을 받는다.

Microsoft 계정은 Windows의 기본적인 사용 경험에서 점점 더 큰 비중을 차지하고 있고, OneDrive는 문서와 바탕 화면 같은 주요 사용자 폴더를 클라우드와 연결한다. Windows Backup 역시 Microsoft 계정을 중심으로 동작하며, Windows Update는 운영체제를 공급자가 정한 지원 상태로 지속적으로 유지하도록 설계되어 있다.

각각의 기능만 따로 놓고 보면 이유가 있다.

계정 연동은 편리하다. 클라우드는 기기 고장에 대비할 수 있다. 자동 업데이트는 보안을 향상시킨다.

문제는 기능의 존재 자체가 아니다.

그 기능을 원하지 않는 사용자가 얼마나 쉽게 거부할 수 있는가. 그리고 이미 선택한 것을 얼마나 쉽게 철회할 수 있는가.

계정 하나를 추가했는데, 왜 계정 하나를 지우는 것은 이렇게 어려운가

이런 생각을 하게 된 직접적인 계기는 회사 PC에서 겪었던 Microsoft 계정 문제였다.

Windows 자체는 로컬 관리자 계정으로 사용하고 있었다.

동료가 Excel을 사용하기 위해 개인 Microsoft 계정으로 잠시 로그인했고, 사용이 끝난 이후 Excel, Microsoft Store, OneDrive에서 모두 로그아웃했다. Microsoft 웹사이트의 기기 목록에서도 해당 PC를 제거했다.

일반적인 사용자라면 여기까지 했다면 해당 계정이 PC에서 제거됐다고 생각할 것이다.

하지만 Windows 설정에는 개인 Microsoft 계정이 계속 표시되고 있었다.

더 이상했던 것은 계정이 분명 존재하는데도 제거 또는 로그아웃 버튼이 없었다는 점이다. 계정 관리를 선택하면 Windows 내부에서 연결을 해제하는 것이 아니라 Microsoft 웹사이트가 열릴 뿐이었다.

내부 상태를 확인해보니 사용자가 하나의 Microsoft 계정이라고 인식하는 것이 실제 Windows 내부에서는 하나의 상태가 아니었다.

Windows 로컬 사용자와 별개로 Workplace Join, WAM(Web Account Manager), Credential Manager, IdentityCRL, TokenBroker, OneAuth, IdentityCache 등 여러 인증 계층이 존재하고 있었다.

Microsoft의 WPJCleanUp.cmd를 실행해 Workplace Join을 제거해도 개인 Microsoft Account의 WAM 상태는 남아 있었다.

Credential Manager에서 Microsoft Account Credential을 삭제하는 데 성공해도 WamDefaultSet : YES는 그대로 유지됐다.

결국 AAD BrokerPlugin과 CloudExperienceHost의 TokenBroker Accounts를 정리하고, OneAuth·IdentityCache·TokenBroker 등의 사용자 인증 캐시를 초기화한 뒤 재부팅하고 나서야 Windows 설정에서 해당 계정이 사라졌다.

여기서 이상한 비대칭이 생긴다.

사용자는 Microsoft 계정 하나를 로그인했을 뿐이다.

그런데 그 계정을 완전히 제거하려면 운영체제 내부의 인증 구조를 상당 부분 이해해야 했다.

로그인은 몇 번의 클릭으로 끝나지만, 완전한 로그아웃은 WAM과 TokenBroker까지 알아야 할 수도 있다.

계정이 사용자를 위한 수단이라면, 계정을 연결하는 것만큼 연결을 끊는 과정도 명확하고 쉬워야 하지 않을까.

이 문제를 실제로 추적하면서 확인한 Windows 내부 인증 구조와 제거 과정은 아래 글에 별도로 정리해두었다.

Windows 11 MS계정 로그아웃 이슈

개인 Microsoft 계정이 로그아웃 후에도 Windows에 남는 원인과 강제 로그아웃 방법

Sonny_Blogsonny

소유권과 통제권은 같은 말이 아니다

Microsoft의 소비자용 서비스 계약에서는 사용자가 서비스에 저장하거나 생성한 콘텐츠에 대해 Microsoft가 소유권을 주장하지 않는다고 명시한다.

콘텐츠의 소유권과 책임은 사용자에게 있다는 것이다. Microsoft는 동시에 자신이 사용자의 콘텐츠를 소유하거나 보증하지 않으며, 사용자 콘텐츠에 대한 법적 책임도 제한하고 있다.

표면적으로 보면 명확하다.

내 파일은 내 것이다.

하지만 조금 다른 질문을 하면 이야기가 복잡해진다.

그 파일을 실제로 어떻게 다룰지 결정하는 권리는 누구에게 있는가.

어떤 계정과 연결되는지,

어디에 저장되는지,

어떤 인증 정보가 남는지,

어떤 서비스와 동기화되는지,

그리고 그 연결을 완전히 끊을 수 있는지는 운영체제와 플랫폼의 설계에 크게 의존한다.

법적인 소유권이 사용자에게 있다고 해도 실제 데이터 관리 구조에 대한 통제력이 플랫폼에 집중되어 있다면, 소유권과 통제권 사이에는 분명 차이가 생긴다.

로컬 계정은 왜 점점 예외적인 경로가 되는가

Windows 설치 과정도 비슷한 방향으로 움직이고 있다.

Microsoft는 Windows 11 Insider 빌드에서 bypassnro.cmd를 제거하면서 보안과 사용자 경험 향상을 이유로 들었고, 모든 사용자가 인터넷 연결과 Microsoft 계정이 있는 상태로 설치 과정을 끝내도록 하는 변경이라고 직접 설명했다.

이후 다른 Insider 빌드에서는 OOBE에서 로컬 계정을 만드는 데 사용되던 알려진 메커니즘도 제거한다고 밝혔다.

Microsoft의 설명은 이러한 방법이 중요한 설정 화면을 우회할 수 있기 때문이며, 사용자는 인터넷과 Microsoft 계정을 이용해 OOBE를 마쳐야 장치가 제대로 설정된다는 것이었다.

물론 이 내용은 해당 Insider 빌드에서의 정책이다.

이를 두고 모든 Windows 환경에서 로컬 계정이 기술적으로 완전히 사라졌다고 말할 수는 없다.

하지만 Microsoft가 어떤 방향을 정상적인 기본 경로로 보고 있는지는 꽤 분명하다.

Microsoft 계정은 기본 경로가 되고,

로컬 계정은 점점 별도의 방법을 알아야 하는 경로가 된다.

Microsoft 계정 자체가 문제라는 이야기는 아니다.

문제는 로컬 계정을 원하는 사용자의 선택이 왜 계속 어려워져야 하느냐는 것이다.

OneDrive는 선택인가, 운영체제의 일부인가

OneDrive 역시 같은 질문을 만든다.

Desktop, Documents, Pictures 같은 Windows의 주요 사용자 폴더를 OneDrive에 연결하면 분명 장점이 있다.

PC가 고장 나더라도 정상적으로 동기화된 파일은 다른 장치에서 다시 받을 수 있고, 여러 장치에서도 동일한 파일을 사용할 수 있다.

Microsoft는 조직 환경에서 Known Folder Move 정책을 제공한다.

사용자가 Documents, Pictures, Desktop을 OneDrive로 옮기도록 안내할 수 있고, 사용자가 안내를 닫아도 이동이 끝나거나 오류가 발생할 때까지 Activity Center에 reminder를 계속 표시할 수 있다.

관리자는 사용자 개입 없이 폴더를 OneDrive로 이동할 수도 있고, 사용자가 다시 로컬 PC로 돌리는 것을 금지할 수도 있다.

물론 이것은 조직 관리자가 적용하는 정책이다.

일반 개인용 Windows에서 Microsoft가 똑같은 정책을 임의로 강제한다는 뜻은 아니다.

그럼에도 Windows와 OneDrive가 점점 깊게 결합되는 방향을 보면 한 가지 질문은 남는다.

사용자가 클라우드를 선택하는 것과, 운영체제가 클라우드 사용을 정상적인 기본 상태로 취급하는 것은 같은 것인가.

백업 권장 안내 자체가 사용자에게는 장애처럼 보였다

OneDrive와 관련해 현장에서 여러 차례 겪은 또 다른 문제는 백업을 권장하는 안내 자체가 사용자에게 PC 장애처럼 받아들여졌다는 점이었다.

OneDrive가 바탕 화면이나 문서, 사진 등을 백업하도록 권장하는 화면이 갑자기 나타나는 경우가 있었다.

컴퓨터에 익숙한 사용자라면 내용을 읽고 백업을 설정하거나, 원하지 않는다면 창을 닫고 넘어갈 수 있다.

하지만 회사의 모든 사용자가 Windows의 계정 구조나 OneDrive가 무엇인지 이해하고 있는 것은 아니다.

실제로 이런 안내 화면이 나타난 뒤

“컴퓨터가 이상해졌어요.”

“바탕화면이 안 나와요.”

“갑자기 이상한 화면이 떠서 아무것도 못 하겠어요.”

와 같은 문의를 받고 직접 현장에 확인하러 간 경우가 여러 차례 있었다.

막상 가보면 Windows가 고장 난 것도 아니고 PC가 멈춘 것도 아니었다.

OneDrive가 백업 설정을 권장하는 화면을 표시하고 있었을 뿐이었다.

하지만 컴퓨터를 잘 모르는 사용자 입장에서는 충분히 장애처럼 느껴질 수 있다.

매일 PC를 켜면 익숙한 바탕 화면이 나타났는데, 어느 날 갑자기 처음 보는 화면이 그 앞을 가리고 있고 Microsoft 계정이나 백업과 관련된 선택을 요구한다면 그것이 새로운 기능의 안내인지, 오류 메시지인지 구분하기 어렵다.

특히 업무용 PC에서는 사용자가 운영체제의 새로운 기능을 탐색하기 위해 PC를 켜는 것이 아니다.

자신이 사용해야 할 업무 프로그램을 실행하기 위해 PC를 켠다.

그 과정 앞에 사용자가 요청하지 않은 선택 화면이 나타났다면, IT에 익숙하지 않은 사람에게는 그 순간부터 업무가 막힌 것이다.

OneDrive 백업 자체가 잘못된 기능이라는 뜻은 아니다.

오히려 제대로 사용하면 상당히 유용하다.

하지만 기능을 제공하는 것과, 사용자가 그 기능을 이해할 수 있는 방식으로 제공하는 것은 다른 문제라고 생각한다.

사용자가 원하지 않는다면 쉽게 거절할 수 있어야 하고,

나중에 다시 설정할 수 있다는 사실도 명확해야 하며,

거절했다고 해서 같은 선택이 계속 업무 흐름 앞에 나타나지 않는 편이 좋다.

실제 현장에서는 OneDrive 자체의 기술적 장애가 아니라 OneDrive를 사용하도록 권장하는 UI만으로도 헬프데스크 요청과 현장 지원이 발생했다.

이 또한 시스템을 설계하는 입장에서는 잘 보이지 않지만, 운영하는 입장에서는 분명한 비용이다.

클라우드를 권하지만 데이터 보존의 최종 책임은 다시 사용자에게 있다

이 부분은 개인적으로 가장 아이러니하게 느껴진다.

Microsoft는 OneDrive를 사용자 데이터 보호 수단으로 적극적으로 제공한다.

하지만 Microsoft 서비스 계약에서는 사용자가 자신의 콘텐츠에 대한 책임을 지는 구조가 명확하다.

계정이 해지되면 Microsoft는 계정과 연결된 데이터나 콘텐츠를 삭제하거나 연결을 해제할 수 있고, 이후 Microsoft가 해당 데이터를 검색하지 못할 수 있으므로 사용자가 정기적인 백업 계획을 세워야 한다고 직접 명시한다.

이를 두고 Microsoft가 데이터를 보호하지 않는다고 말하는 것은 정확하지 않다.

OneDrive에는 서버 측 복원력, 휴지통, 버전 기록 등 여러 보호 장치가 존재한다.

하지만 중요한 차이가 있다.

높은 데이터 내구성을 제공하는 것과 사용자의 모든 데이터가 반드시 보존된다고 보증하는 것은 다른 문제다.

결국 사용자 입장에서는 묘한 구조가 된다.

Windows는 클라우드 사용을 적극적으로 권장한다.

그러나 정말 중요한 데이터라면 사용자가 다시 별도의 독립 백업을 준비해야 한다.

그렇다면 OneDrive는 무엇인가.

주 저장소인가.

동기화 서비스인가.

백업인가.

실제 일반 사용자가 이 차이를 얼마나 명확하게 인식하고 있을까.

동기화는 백업과 같지 않다

OneDrive의 중요한 기능 중 하나는 동기화다.

한 장치의 상태를 클라우드와 다른 장치에 반영한다.

이는 매우 편리하지만 전통적인 의미의 독립된 백업과는 성격이 다르다.

특히 Files On-Demand가 활성화되어 있다면 이 차이는 더욱 커진다.

Microsoft 설명에 따르면 온라인 전용 파일은 파일 탐색기에 표시되면서도 실제 파일 내용은 로컬 저장 공간에 내려와 있지 않을 수 있다.

파일을 열면 장치에 내려받아 로컬에서 사용할 수 있게 되고, 인터넷 없이도 항상 사용하려면 항상 이 장치에 유지 상태로 만들어야 한다.

녹색 체크 아이콘도 상태에 따라 의미가 다르며, Always keep on this device로 지정된 파일만 항상 오프라인 사용이 보장되는 상태다.

정상적인 환경에서는 상당히 유용한 기능이다.

대량의 클라우드 파일을 탐색기에서 보면서도 SSD 공간을 절약할 수 있기 때문이다.

문제는 장애가 발생했을 때다.

실제 데이터 복구에서는 확인해야 할 것이 오히려 늘었다

실제 PC 장애를 처리하면서 OneDrive 때문에 데이터 복구가 예상보다 복잡해진 사례가 있었다.

Windows가 정상적으로 부팅되는 상황이 아니라 디스크를 분리해 오프라인 상태에서 데이터를 복구해야 하는 경우였다.

이때 과거 파일 탐색기에서 보였던 폴더와 파일 구조와 실제 디스크에 존재하는 데이터가 반드시 일치하지 않았다.

온라인 전용이었던 파일은 이름과 경로는 존재했던 것처럼 보여도 실제 데이터가 완전히 로컬에 내려와 있지 않을 수 있다.

그래서 복구 시에는 단순히

“파일 이름이 보인다.”

“폴더가 남아 있다.”

라는 사실만으로 데이터를 확보했다고 판단하기 어려웠다.

해당 파일이 실제 로컬에 내려와 있었는지,

온라인 전용이었는지,

마지막 동기화가 정상적으로 끝났는지,

클라우드에는 어느 시점의 데이터까지 올라갔는지까지 확인해야 했다.

순수한 로컬 저장 환경이었다면 복구 대상과 확인 범위를 우선 로컬 저장장치에 집중할 수 있었다.

OneDrive가 개입된 환경에서는 복구해야 할 상태가 두 개가 된다.

로컬 디스크 상태와 클라우드 상태다.

그리고 두 상태는 반드시 같지 않다.

같은 Microsoft 계정으로 로그인한다고 모든 데이터가 살아나는 것도 아니었다

이 부분도 실제 현장에서 쉽게 오해하는 지점이었다.

사용자는 Microsoft 계정과 OneDrive를 사용했다면 새 PC에서 같은 계정으로 로그인하는 것만으로 이전 환경이 거의 그대로 돌아올 것이라고 생각하기 쉽다.

하지만 계정 로그인은 결국 해당 계정으로 다시 인증했다는 의미다.

과거 PC의 모든 파일이 서버에 존재한다는 뜻은 아니다.

해당 파일이 OneDrive 동기화 대상이었는지,

마지막 변경 사항이 서버까지 전송됐는지,

로컬에만 존재하던 파일은 없었는지,

어떤 파일이 온라인 전용이었는지에 따라 실제 복구 결과는 달라진다.

내가 직접 처리했던 복구 사례에서도 동일한 Microsoft 계정에 로그인한다고 해서 모든 데이터가 온전하게 복원되는 형태는 아니었다.

결국 여기서 하나를 분명히 구분해야 했다.

계정은 데이터가 아니다.

그리고 동기화 역시 완전한 복구 시점을 자동으로 만들어주는 것은 아니다.

OneDrive는 복구 수단 하나를 추가해준다.

하지만 동시에 복구 과정에서 확인해야 할 상태 역시 하나 더 추가한다.

정상 업무 중에도 OneDrive가 새로운 장애 지점이 되었다

문제는 장애 이후 복구에만 있지 않았다.

정상적으로 업무 중인 PC에서도 OneDrive가 기존 프로그램의 파일 처리 과정과 맞물리면서 실제 장애가 발생한 사례가 있었다.

사내 프로그램에서 데이터를 조회하거나 출력한 뒤 Excel 파일을 생성하고, 생성한 결과 파일을 즉시 Excel로 열어주는 기능이 있었다.

정상적인 환경이라면 사용자가 버튼을 누른 직후 Excel이 실행되어야 했다.

그런데 OneDrive 연결 이후 일부 PC에서 이 과정이 정상적으로 이어지지 않았다.

사내 프로그램은 작업을 수행했고 네트워크 자체에도 특별한 문제가 없었지만, 결과 Excel 파일이 바로 열리지 않았다.

확인해보니 사내 프로그램은 사용자 내 문서(Documents) 아래의 특정 경로에 임시 파일을 생성한 뒤 결과 파일을 처리하는 구조였다.

그리고 OneDrive 역시 해당 Documents 영역을 동기화 대상으로 관리하고 있었다.

프로그램이 임시 파일을 생성하고 이를 후속 처리하는 과정에서 OneDrive의 파일 상태 처리 또는 동기화가 함께 이루어지고 있었으며, 이 과정과 관련된 것으로 의심되는 파일 접근 지연 현상이 나타났다.

정확히 어떤 파일 핸들이 어느 시점에 충돌했는지까지 모든 사례에서 디버깅한 것은 아니기 때문에 일반적인 OneDrive 버그라고 단정할 수는 없다.

그러나 현장에서 나타난 패턴은 상당히 일관적이었다.

파일은 있었는데 바로 열리지 않았다

사용자에게 보이는 증상은 단순했다.

사내 프로그램에서 버튼을 누른다.

원래라면 바로 Excel이 열린다.

그런데 열리지 않는다.

흥미로운 점은 파일이 완전히 생성되지 않은 것도 아니었다는 것이다.

한참 기다리고 나서야 열리기도 했고,

사용자가 직접 내 문서 안에 있는 임시 파일 생성 폴더를 탐색기로 열어 접근한 뒤에야 파일이 열리는 경우도 있었다.

즉 프로그램이 파일을 만들지 못한 것이 아니라,

프로그램이 파일을 생성한 직후 사용해야 하는 시점에서 정상적으로 접근하지 못하는 것처럼 보이는 상태가 발생한 것이다.

사용자 입장에서는 이것을 OneDrive 문제라고 생각할 이유가 거의 없다.

바로 직전에 사용한 것은 사내 프로그램이고,

열리지 않는 것은 Excel 파일이다.

따라서 사용자들은 대부분

“사내 프로그램에서 Excel 파일이 안 열립니다.”

라는 형태로 장애를 접수했다.

OneDrive 연결 이후 내가 담당한 환경에서 이 유형으로 접수된 요청은 12곳 중 8건이었다.

‘이 PC에 항상 유지’를 설정해도 동일했다

처음에는 Files On-Demand 때문이라고 의심했다.

그래서 문제가 발생하는 파일과 폴더에 항상 이 장치에 유지, 즉 로컬에 파일을 내려받아 보관하는 설정도 적용해봤다.

탐색기에는 실제로 녹색 체크 표시가 나타났다.

Microsoft 문서상으로도 이 상태는 해당 파일이 장치에 다운로드되어 있고 오프라인에서도 사용할 수 있는 상태를 의미한다.

그런데도 문제는 사라지지 않았다.

파일을 로컬에 유지하도록 했음에도 사내 프로그램이 생성한 결과 파일이 즉시 열리지 않는 현상은 동일하게 나타났다.

즉 내가 처리한 해당 환경에서는 단순히

“온라인 전용 파일이라서 바로 열리지 않았다.”

라고 설명할 수 있는 문제는 아니었다.

폴더 동기화를 꺼도 증상이 계속됐다

그다음에는 문제가 되는 Documents 영역의 OneDrive 동기화를 해제했다.

이 정도라면 프로그램의 파일 처리 과정에서 OneDrive의 영향을 제거할 수 있을 것이라고 생각했다.

하지만 해당 환경에서는 동기화 대상 폴더를 해제한 뒤에도 동일한 증상이 계속 발생했다.

사용자에게 보이는 폴더 동기화는 꺼져 있었지만 OneDrive 클라이언트 자체는 여전히 동작하고 있었고, 프로그램의 Excel 파일 처리 문제도 사라지지 않았다.

결국 원인 분리를 위해 OneDrive 클라이언트를 PC에서 완전히 제거했다.

그제서야 사내 프로그램이 파일을 생성하고 Excel로 즉시 여는 기존 동작이 정상으로 돌아왔다.

따라서 내가 처리한 환경에서는

OneDrive 연결 전 정상 → 연결 이후 반복 발생 → 항상 이 장치에 유지 후에도 발생 → 폴더 동기화 해제 후에도 발생 → OneDrive 클라이언트 제거 후 정상화

라는 흐름이 확인됐다.

직접적인 내부 원인을 모두 추적했다고 말할 수는 없지만, 운영 관점에서는 OneDrive 클라이언트와 해당 프로그램의 파일 처리 과정 사이의 연관성을 의심하기에 충분한 결과였다.

문제 해결 과정 자체가 또 다른 불편을 만들었다

더 큰 문제는 장애를 해결하기 위해 동기화 설정을 변경하는 과정에서도 새로운 불편이 발생했다는 점이다.

OneDrive 폴더 동기화를 해제하거나 다시 구성하면 기존 클라우드 파일과 로컬 상태를 다시 맞추는 과정이 필요했다.

그 결과 사용자 PC에서 파일을 다시 내려받는 작업이 진행됐다.

문제는 당시 업무 환경의 인터넷 회선이었다.

전체 인터넷 연결은 가능했지만 사용자별 QoS가 적용되어 있어 한 명이 사용할 수 있는 대역폭이 충분히 빠른 환경은 아니었다.

이 상황에서 OneDrive는 파일을 올리고,

설정을 변경하면 다시 내려받고,

다시 동기화 상태를 맞추는 작업을 반복했다.

사용자 입장에서는 업무와 직접 관계없는 대량의 업로드와 다운로드가 백그라운드에서 계속 발생하는 셈이었다.

특히 많은 파일을 다시 내려받는 동안 네트워크 사용량이 증가했고, 같은 환경을 사용하는 동료들 사이에서도 인터넷이 느려졌다는 불편이 나왔다.

결국 원래 목적은 데이터를 편리하게 동기화하는 것이었는데,

문제를 해결하는 과정에서는 오히려 클라우드와 로컬 사이에서 같은 데이터를 반복해서 업로드하고 다운로드하면서 제한된 네트워크 자원을 소비하는 상황이 생겼다.

정상 상태만 보면 보이지 않는 비용

OneDrive가 정상적으로 동작할 때는 이런 부분을 거의 의식하지 않는다.

사용자가 파일을 만들면 자동으로 올라가고,

다른 PC에서는 다시 내려온다.

클라우드에 데이터가 있으니 안심할 수 있다.

하지만 장애 상황에서는 그 뒤에 숨어 있던 구조가 드러난다.

로컬 파일인지 온라인 전용 파일인지 확인해야 한다.

동기화가 완료됐는지 확인해야 한다.

파일 상태 아이콘을 확인해야 한다.

폴더 리디렉션 여부를 확인해야 한다.

OneDrive 클라이언트 자체가 파일 처리에 영향을 주는지도 확인해야 한다.

설정을 바꾸고 나면 다시 데이터를 내려받아야 할 수도 있다.

그리고 네트워크의 대역폭까지 함께 고려해야 한다.

기존에는

사내 프로그램 → 파일 생성 → Excel 실행

정도였던 문제 분석 구조가,

클라우드 동기화를 사용하면서는

사내 프로그램 → 임시 파일 → 로컬 파일 상태 → OneDrive 클라이언트 → 동기화 상태 → 클라우드 상태 → 다시 로컬 상태 → Excel

까지 확장될 수 있다.

정상일 때는 전혀 보이지 않던 계층이다.

하지만 장애가 발생하면 확인해야 할 지점과 실패할 수 있는 지점이 동시에 늘어난다.

사용자는 당연히 사내 프로그램 문제라고 생각했다

이 점은 IT 운영 관점에서도 상당히 중요했다.

OneDrive가 원인 후보라는 사실을 모르는 사용자는 자연스럽게 바로 앞에서 사용한 프로그램을 의심한다.

Excel 파일이 안 열린다면 Excel을 의심하거나,

Excel을 호출한 사내 프로그램을 의심한다.

따라서 장애 접수 역시 사내 프로그램 문제로 들어온다.

전산 담당자는 프로그램을 확인한다.

서버를 확인한다.

네트워크를 확인한다.

Office 설치 상태를 확인한다.

파일 권한을 확인한다.

그리고 마지막 단계에 가서야 파일과 프로그램 사이에 새로 추가된 동기화 계층을 의심하게 된다.

클라우드 서비스 하나를 추가했을 뿐인데, 실제 장애 분석 범위는 훨씬 넓어진 셈이다.

12곳 중 8건이라는 접수 비율보다 개인적으로 더 크게 느낀 부분은 이것이었다.

사용자에게는 보이지 않는 시스템이 장애 원인 후보로 하나 더 추가됐다는 점이다.

운영체제 자체의 변경도 사용자가 완전히 결정하기 어려워졌다

계정과 데이터뿐 아니라 Windows Update에서도 비슷한 방향을 볼 수 있다.

Microsoft가 Windows 업데이트를 자동화한 이유는 충분히 이해할 수 있다.

인터넷에 연결된 취약한 PC는 그 PC 한 대만의 문제가 아니다. 랜섬웨어나 웜, 봇넷과 같은 보안 위협은 패치되지 않은 시스템을 통해 다른 사용자에게까지 피해를 줄 수 있다.

따라서 보안 업데이트를 자동으로 제공하는 것 자체에는 충분한 이유가 있다.

다만 현재 일반 Windows 사용자가 할 수 있는 것은 업데이트를 완전히 거부하는 것보다는 일정 기간 미루는 것에 가깝다.

업데이트를 일시 중지할 수는 있지만 그 기간에는 제한이 있고, 기간이 끝나면 Windows는 다시 업데이트를 검사하고 다운로드·설치한다.

결국 사용자가 결정할 수 있는 것은 점점

“업데이트를 적용할 것인가.”

보다는

“지금 적용할 것인가, 조금 뒤에 적용할 것인가.”

에 가까워진다.

물론 업데이트 이후 문제가 발생했을 때 이전 버전이나 빌드로 되돌리기 기능도 제공된다.

하지만 이것 역시 사용자가 특정 버전을 장기간 선택해 유지할 수 있도록 하는 기능과는 거리가 있다.

업그레이드 이후 일정 기간 동안은 이전 Windows 환경으로 돌아갈 수 있지만, 되돌리기가 가능한 기간 자체가 제한되어 있다.

더구나 내가 실제로 관리했던 환경에서는 이전 빌드로 되돌린 이후에도 이미 다음 업데이트가 다운로드되어 있거나 설치 대기 상태로 남아 있어, 다시 ‘업데이트 후 종료’ 또는 ‘업데이트 후 다시 시작’ 메뉴가 활성화되는 경우가 있었다.

즉 되돌리기에 성공했다고 해서

“이 버전이 내 환경에서 안정적이니 앞으로도 계속 사용하겠다.”

라는 선택이 보장되는 것은 아니었다.

오히려 업데이트 이후 문제가 생겼을 때 잠시 이전 환경으로 돌아가 호환성 문제를 확인하고 대응할 시간을 확보하는 임시적인 복구 수단에 가까웠다.

결국 시간이 지나면 다시 업데이트 문제를 마주하게 된다.

시간이 지나면, 어떻게든 원점이다.

운영체제의 지원 정책이 하드웨어의 수명까지 결정하기도 한다

업데이트 문제는 현재 설치된 Windows의 버전만으로 끝나지 않는다.

Windows 11로 넘어오면서는 TPM 2.0, Secure Boot, 지원 CPU 목록과 같은 하드웨어 요구사항까지 운영체제 지원 여부를 결정하는 중요한 기준이 됐다.

Microsoft는 현재도 Windows 11의 최소 요구사항으로 TPM 2.0을 명시하고 있으며, TPM 2.0 미만인 장치는 Windows 11 요구사항을 충족하지 않는다고 안내한다. Microsoft는 이를 Windows Hello나 BitLocker 같은 보안 기능의 기반으로 설명하고 있다. 마이크로소프트 지원

보안 강화를 위한 취지 자체는 이해할 수 있다.

문제는 현장에서 PC의 실제 사용 가능 여부와 운영체제의 지원 가능 여부가 반드시 일치하지 않는다는 것이다.

CPU 성능도 충분하고,

메모리도 충분하며,

SSD까지 장착해 일반적인 업무에는 별다른 문제가 없는 PC인데도,

TPM 2.0이나 지원 CPU 조건을 충족하지 못한다는 이유로 Windows 11의 공식적인 업그레이드 대상에서 제외될 수 있다. 마이크로소프트 지원

즉 하드웨어가 성능적으로 수명을 다한 것이 아니라,

운영체제의 지원 정책이 먼저 그 PC의 실질적인 수명을 결정하는 상황이 생긴다.

Windows 10의 일반 지원이 종료된 이후 Microsoft는 Windows 11로 이동할 것을 권장하고 있다. 동시에 Windows 11 최소 요구사항을 충족하지 않는 장치에 대해서는 Windows 11 설치를 권장하지 않으며, 이러한 장치는 Microsoft 지원 대상이 아니고 업데이트 역시 보장되지 않는다고 안내한다. 마이크로소프트 지원

사용자 입장에서는 선택지가 묘해진다.

기존 Windows의 지원은 끝났으니 최신 Windows로 이동하라고 한다.

하지만 아직 충분히 사용할 수 있는 PC가 Windows 11의 하드웨어 요구사항을 충족하지 못하면 공식적으로는 업그레이드 대상이 아니다.

결국 기기를 교체하거나,

지원되지 않는 방법으로 Windows 11을 설치하거나,

지원이 종료된 Windows를 유지하거나,

별도의 격리 환경을 마련해야 한다.

어느 쪽이든 비용과 관리 부담은 사용자나 기업에게 돌아온다.

지원되지 않는 PC에 대한 안내도 한동안 혼란을 만들었다

이 과정에서는 Microsoft의 안내가 사용자 입장에서 다소 혼란스럽게 보인 사례도 있었다.

Windows 11 출시 이후 Microsoft는 TPM 2.0을 포함한 최소 하드웨어 요구사항을 계속 유지해왔다.

그런데 최소 요구사항을 충족하지 않는 PC에 Windows 11을 설치했을 때의 주의사항과 복구 방법을 설명하는 Microsoft 지원 문서가 존재하면서, 한동안 이를 두고 “Microsoft가 구형 PC의 Windows 11 설치를 사실상 허용하는 방향으로 입장을 완화한 것 아니냐”는 해석도 나왔다.

Microsoft는 이후 해당 지원 문서를 명확히 수정하면서 이 해석에 선을 그었다.

2024년 12월 12일 갱신된 공식 안내에서는 Windows 11의 최소 시스템 요구사항은 변경되지 않았으며, 요구사항을 충족하지 않는 장치에 Windows 11을 설치하는 것은 여전히 권장하지 않는다고 명시했다.

또 이런 장치는 Microsoft의 지원을 받을 수 없으며 업데이트도 보장되지 않고, 요구사항을 충족하지 않는 PC에 Windows 11을 설치했다면 Windows 10으로 되돌릴 것을 권장한다고 설명했다. 마이크로소프트 지원

엄밀히 말하면 Microsoft가 TPM 정책을 공식적으로 없앴다가 다시 부활시킨 것은 아니다.

하지만 사용자 입장에서는 지원되지 않는 설치 방법을 설명하는 공식 문서가 존재하고, 이를 두고 정책이 완화됐다는 해석이 나온 뒤 다시 최소 요구사항은 변하지 않았다고 명확히 선을 긋는 과정 자체가 혼란스럽게 느껴질 수밖에 없다.

더 아이러니한 것은 실제 운영 환경이다.

내가 관리하는 환경에서는 TPM 요구사항을 우회해 Windows 11을 설치한 일부 구형 PC도 사용하고 있지만, 지금까지 TPM 미지원 자체가 원인이 되어 별도의 장애가 접수된 사례는 없었다.

물론 이것이 TPM 2.0 요구사항이 불필요하다는 의미는 아니다. Microsoft가 TPM을 보안 기준으로 요구하는 기술적 이유와, 특정 환경에서 당장 장애 없이 사용할 수 있다는 사실은 서로 다른 문제다.

다만 현장에서 정상적으로 사용되고 있는 PC를 보면서도 정책상으로는 지원되지 않는 장치라고 판단해야 한다는 점에서, 기술적으로 사용할 수 있는 상태와 공식적으로 지원되는 상태 사이의 간극을 체감하게 된다.

더구나 Windows 10 지원 종료 이후에는 Windows 11로의 이동을 권장하면서도, 요구사항을 충족하지 못하는 장치에는 Windows 11을 설치하지 말라는 안내가 동시에 존재한다. 마이크로소프트 지원

정책 하나하나에는 이유가 있겠지만,

사용자 입장에서는 결국 이런 질문이 남는다.

아직 업무에는 충분한 PC인데,
운영체제가 요구하는 보안 조건을 만족하지 못한다는 이유만으로 하드웨어까지 교체해야 하는가.

기업 환경에서는 이 비용이 PC 한 대의 가격으로 끝나지도 않는다.

1.장비 교체,

2.사용자 데이터 이전,

3.사내 프로그램 재설치,

4.드라이버와 주변기기 검증,

5.사용자 환경 재구성까지 따라온다.

운영체제의 보안 정책 하나가 결국 하드웨어와 업무 시스템 전체의 교체 주기에 영향을 주는 셈이다.

보안 패치라는 목적만 본다면 Microsoft가 최신 환경을 유지하려는 방향 자체는 이해할 수 있다.

하지만 실제 업무 환경에서는 최신이라는 것이 항상 가장 안정적인 상태와 같은 뜻은 아니다.

오래된 사내 프로그램이 있을 수 있다.

특정 드라이버나 하드웨어에 의존하는 장비가 있을 수 있다.

방송, 산업, 연구, 의료처럼 이미 검증된 환경을 쉽게 변경하기 어려운 시스템도 존재한다.

이런 환경에서 운영체제 업데이트는 단순히 UI가 조금 달라지는 문제가 아니다.

특정 프로그램이 실행되지 않거나,

드라이버 호환성이 깨지거나,

오랫동안 정상적으로 사용하던 업무 시스템 자체를 사용할 수 없게 되는 문제로 이어질 수 있다.

결국 현장에서 중요한 것은 단순히 최신 버전인가 아닌가가 아니다.

업데이트 이후에도 기존 업무 환경이 정상적으로 유지되는가,

장비와 드라이버가 정상적으로 동작하는가,

레거시 프로그램을 계속 사용할 수 있는가를 함께 봐야 한다.

최신화를 위해 다시 구형 Windows를 유지해야 하는 역설

실제로 나 역시 이러한 레거시 프로그램을 유지하기 위해 별도의 Windows 가상환경을 구성하고, VMware ESXi와 Guacamole을 이용해 필요한 구형 프로그램만 별도의 VM Pool에서 사용할 수 있도록 환경을 구성한 적이 있다.

레거시 프로그램을 위한 가상 PC Pool 구성기

Guacamole + VMware ESXi로 Windows VM Pool 구축하기

Sonny_Blogsonny

이렇게 하면 최신 Windows 환경과 레거시 프로그램을 어느 정도 분리할 수 있다.

하지만 생각해보면 이것 역시 상당히 아이러니하다.

보안을 위해 운영체제를 최신화했는데, 그 결과 기존 업무 프로그램을 사용하기 위해 오래된 운영체제를 별도의 가상환경에 다시 유지해야 하는 상황이 생길 수 있기 때문이다.

가상화 자체가 보안 취약점이라는 의미는 아니다.

오히려 제대로 격리한다면 레거시 시스템을 물리 PC에 그대로 유지하는 것보다 관리하기 좋은 방법이 될 수 있다.

하지만 구형 운영체제와 프로그램을 계속 유지해야 하고, 이를 위한 가상화 서버와 네트워크 정책, 원격 접속 게이트웨이, 접근제어까지 추가된다면 관리해야 할 공격면과 보안 지점 역시 함께 늘어난다.

결국 하나의 호환성 문제를 해결하기 위해

별도의 레거시 OS, 가상화 환경, 네트워크 격리, 원격 접속 체계라는 또 다른 시스템

을 만들어야 하는 상황이 생길 수 있다.

보안을 위해 요구되는 최신화가 역설적으로 레거시 환경을 별도로 유지하게 만들고,

그 환경을 안전하게 사용하기 위해 다시 추가적인 보안 대책을 마련해야 하는 셈이다.

그래서 기업이나 특수 업무 환경에서는 단순히

“최신 버전이니 더 안전하다.”

라는 논리만으로 운영체제 업데이트를 판단하기 어렵다.

업데이트를 미룰 수 있고, 문제가 생기면 일정 기간 이전 환경으로 돌아갈 수도 있다.

하지만 그것은 결국 업데이트 시점을 조절하거나 문제 해결 시간을 확보하는 장치이지, 사용자가 자신의 환경에 가장 적합한 운영체제 버전을 장기간 선택할 수 있다는 의미는 아니다.

실제로 중요한 것은 최신 버전인지가 아니라,

현재 사용하는 프로그램과 장비가 정상적으로 동작하면서도 필요한 보안 수준을 유지할 수 있는가이기 때문이다.

각각 따로 보면 합리적이지만, 하나의 방향으로 모이면 다른 문제가 된다

Microsoft 계정을 권장하는 데에는 이유가 있다.

OneDrive를 통해 데이터를 보호하려는 데에도 이유가 있다.

Windows Update를 자동화하는 데에도 이유가 있다.

각 정책을 따로 보면 충분히 합리적으로 설명할 수 있다.

문제는 이것들이 계속 같은 방향으로 쌓일 때다.

계정은 온라인 계정으로 향한다.

데이터는 클라우드에 연결된다.

운영체제는 지속적인 온라인 업데이트를 전제로 한다.

인증 상태 역시 여러 온라인 서비스와 연결된다.

복구에서도 로컬 디스크만 확인해서는 끝나지 않는다.

클라우드 상태를 함께 확인해야 한다.

정상 업무 중의 파일 처리에도 동기화 상태라는 변수가 추가된다.

백업 권장 화면 하나만으로도 컴퓨터에 익숙하지 않은 사용자에게는 장애처럼 받아들여질 수 있다.

설정을 변경하면 다시 대량의 데이터를 내려받아야 할 수도 있고, 제한된 네트워크 환경에서는 그것 자체가 또 다른 업무 부담이 된다.

결국 PC는 점점 자체적으로 완결된 컴퓨터라기보다는 온라인 계정을 중심으로 여러 서비스에 연결된 단말기에 가까워진다.

데이터의 소유권보다 중요한 것은 철회할 수 있는가이다

그래서 나는 데이터 소유권에서 가장 중요한 것이 약관에

“이 데이터의 소유권은 사용자에게 있습니다.”

라고 적혀 있는 것만은 아니라고 생각한다.

사용자에게 실질적인 소유권과 통제권이 있다면, 한번 내린 선택을 다시 되돌릴 수도 있어야 한다.

1. Microsoft 계정을 연결했다면 사용자가 원할 때 명확한 절차를 통해 완전히 제거할 수 있어야 한다.
2. OneDrive를 사용했다면 다시 완전한 로컬 저장 환경으로 돌아가는 과정도 어렵지 않아야 한다.
3. 클라우드에 있는 파일은 필요할 경우 자신의 저장장치에 완전한 사본으로 가져올 수 있어야 한다.
4. 클라우드를 사용하지 않기로 했다면 그 선택 역시 운영체제에서 지속적으로 존중되어야 한다.
5. 운영체제 업데이트가 필요한 경우에도 업무 환경과 프로그램의 호환성을 충분히 검증할 시간을 확보할 수 있어야 한다.
6. 운영체제 최신화로 인해 기존 프로그램의 호환성이 깨진다면, 그에 대한 대안 역시 운영체제 차원에서 함께 제공할 필요가 있다.
7. 특히 오래된 업무 프로그램을 위해 호스트 운영체제와 분리된 독립적인 호환·샌드박스 환경을 제공할 수 있는 체계가 있었으면 한다.

개인적으로는 이 부분이 특히 아쉽다.

Windows는 WSL을 통해 Linux 실행 환경까지 Windows 안에 상당히 자연스럽게 통합했다.

그렇다면 다른 운영체제의 실행 환경을 지원하는 것만큼, 과거 Windows용 프로그램을 안전하게 계속 사용할 수 있는 호환 환경에도 조금 더 많은 관심을 기울일 수 있지 않았을까 싶다.

물론 WSL과 구형 Windows 호환 환경은 기술적으로 같은 문제는 아니다.

내가 말하고 싶은 것은 WSL 자체를 레거시 프로그램 실행에 사용하자는 것이 아니라, 그와 비슷한 수준으로 운영체제에 통합된 독립 실행 환경을 구형 Windows 프로그램에도 제공할 수 없었겠느냐는 것이다.

보안을 이유로 최신 Windows 사용을 사실상 요구하면서, 그 과정에서 호환성을 잃은 업무 프로그램은 사용자가 별도의 VM을 만들고 네트워크를 격리하고 원격 접속 환경까지 구축해 유지해야 한다면 결국 최신화에 따른 비용과 복잡성의 상당 부분을 사용자와 기업이 떠안게 된다.

새로운 환경으로 이동할 자유가 있다면
기존 환경을 안전하게 유지할 방법도 있어야 한다.

클라우드로 이동할 자유가 있다면 로컬로 돌아올 자유도 있어야 한다.

계정을 연결할 자유가 있다면 완전히 끊을 자유도 있어야 한다.

철회하기 어려운 선택은 완전한 선택이라고 보기 어렵다.

Microsoft의 입장이 전혀 이해되지 않는 것은 아니다

그렇다고 Microsoft의 입장이 전혀 이해되지 않는 것은 아니다.

Windows는 전 세계적으로 엄청난 수의 사용자가 사용하는 운영체제다.

오랫동안 업데이트되지 않은 PC가 인터넷에 남아 있는 것은 보안상 위험하다.

Microsoft 계정 하나로 설정과 서비스를 연결해두면 일반 사용자가 새 PC로 옮겨갈 때 편리하다.

OneDrive에 정상적으로 동기화된 파일이 있다면 SSD가 완전히 고장 나더라도 데이터를 다시 받을 수 있다.

Files On-Demand도 정상적인 네트워크 환경에서는 저장공간을 상당히 효율적으로 사용할 수 있는 기능이다.

Microsoft 입장에서는 사용자 실수와 장치 고장에 강한 환경을 만들기 위해 계정, 클라우드, 백업, 업데이트를 하나의 경험으로 연결하려는 것이라고 이해할 수 있다.

그 취지 자체를 부정하고 싶지는 않다.

다만 모든 PC가 항상 정상적인 온라인 상태일 것만 고려하는 것 같아 심히 아쉽다

내가 가장 아쉽게 느끼는 부분은 다른 데 있다.

Windows의 기본 정책이 점점 모든 PC가 항상 정상적인 인터넷 환경에 있고, 계정 인증이 정상이며, 클라우드 동기화 역시 아무 문제 없이 이루어지는 상태를 기본으로 전제하는 것처럼 보인다는 점이다.

실제 현장은 그렇게 단순하지 않다.

Windows가 부팅되지 않는 PC도 있다.

디스크를 분리해 오프라인으로 데이터를 복구해야 하는 상황도 있다.

인터넷에 연결할 수 없는 장비도 있다.

보안 정책이나 내부망 구조 때문에 외부 클라우드를 자유롭게 사용할 수 없는 PC도 있다.

특정 프로그램이나 장비 때문에 Windows 버전을 쉽게 변경할 수 없는 환경도 있다.

OneDrive의 온라인 전용 파일 때문에 오프라인 복구에서 온전한 파일 데이터가 존재하지 않는 경우도 있었다.

동일한 Microsoft 계정으로 다시 로그인해도 모든 데이터가 기대했던 형태로 돌아오지 않는 경우도 있었다.

정상적으로 업무 중인 PC에서도 OneDrive 연결 이후 프로그램이 사용하는 임시 파일과 결과 파일의 처리 과정에서 문제가 발생했다.

항상 이 장치에 유지로 설정해 녹색 체크 표시까지 확인했지만 증상은 동일했다.

관련 폴더의 동기화를 중지해도 현상은 계속됐다.

결국 OneDrive 클라이언트를 완전히 제거한 이후에야 사내 프로그램의 기존 동작이 정상으로 돌아왔다.

이 유형으로 접수된 요청은 12곳 중 8건이었다.

사용자 대부분은 OneDrive를 의심하지 않았다.

당연히 사내 프로그램이 고장 났다고 생각했다.

그뿐 아니라 OneDrive 백업 권장 화면이 갑자기 나타나 기존 바탕 화면을 바로 볼 수 없다는 이유만으로도

“PC가 고장 난 것 같다.”

는 문의를 받고 현장으로 확인하러 간 경우가 여러 차례 있었다.

기술적으로는 장애가 아니었다.

하지만 사용자가 업무를 진행하지 못한다고 느끼는 순간, 운영 현장에서는 그것 역시 지원이 필요한 사건이 된다.

문제를 해결하기 위해 동기화 설정을 변경하고 파일을 다시 내려받는 과정에서는 또 다른 문제가 생겼다.

당시 환경은 사용자별 QoS가 적용돼 있어 한 사람이 사용할 수 있는 인터넷 속도도 빠르지 않았다.

그 상황에서 이미 올라간 파일을 다시 내려받고, 상태를 다시 맞추고, 경우에 따라 업로드와 다운로드가 반복되면서 네트워크 사용량이 늘었다.

파일을 다시 내려받는 동안 같은 환경을 사용하는 동료들이 느려진 인터넷 때문에 불편을 호소하기도 했다.

정상적인 인터넷과 충분한 대역폭이 있다면 눈에 잘 띄지 않았을 문제다.

하지만 제한된 환경에서는 클라우드 동기화 그 자체가 또 하나의 운영 부담이 되었다.

이런 문제를 직접 겪다 보면 클라우드 중심 설계가 항상 복구와 안정성을 단순하게 만들어주는 것은 아니라는 사실을 체감하게 된다.

정상 상태에서는 분명 편리하다.

그러나 장애가 발생하면 확인해야 할 시스템의 상태와 의존 관계도 함께 늘어난다.

시스템의 가치는 정상적인 상황에서 얼마나 편리한지만으로 결정되는 것은 아니라고 생각한다.

장애가 발생했을 때 사용자가 얼마나 통제할 수 있는가 역시 시스템 설계의 중요한 일부다.

Microsoft가 보안과 데이터 보호, 사용자 편의를 위해 지금과 같은 방향을 선택하는 이유 자체는 이해할 수 있다.

다만 모든 PC가 항상 온라인이고, 충분한 네트워크 대역폭이 있으며, 계정 인증과 클라우드 서비스가 언제나 정상적으로 동작할 것이라는 상황을 중심으로 Windows의 기본 정책을 계속 밀어붙이는 모습은 심히 아쉽다.

PC는 서비스가 정상일 때만 사용하는 장치가 아니다.

인터넷이 끊기고, 대역폭이 부족하고, 계정 인증이 실패하고, 운영체제가 손상되고, 클라우드 동기화가 꼬인 순간에도 사용자는 자신의 계정과 데이터, 그리고 장치를 통제할 수 있어야 한다.

그것이 내가 생각하는 ‘내 PC의 주인이 사용자여야 한다’는 말의 의미다.