날짜:
업데이트실패
dism
KB설치
SSU
Windows업데이트
- 공유 링크 만들기
- X
- 이메일
- 기타 앱
-->
기본 콘텐츠로 건너뛰기이 글의 목적은 Windows 11에서 장치 암호화와 BitLocker를 함께 쓰는 과정에서 발생하는 체감 성능 저하를 원인별로 분해하고, “하나의 방식으로 정리”하여 성능과 안정성을 함께 회복하도록 돕는 것이다.
Windows 11의 “장치 암호화(Device encryption)”는 사용자 입장에서는 간단 토글처럼 보이지만, 내부적으로는 BitLocker 기반의 드라이브 암호화를 자동으로 켜는 방식으로 동작하는 경우가 많다.
문제는 여기서 “혼용”이 실제로는 두 겹으로 동시에 암호화된다는 뜻이 아니라, 같은 BitLocker 엔진이 서로 다른 경로(설정 앱의 장치 암호화 토글, 제어판/정책/MDM의 BitLocker 설정)에서 상충하는 방식으로 제어되는 상황을 뜻하는 경우가 대부분이다.
예를 들어 초기 설정에서 장치 암호화가 자동으로 켜진 뒤, 관리자가 BitLocker를 다시 켜면서 암호화 방식(전체/사용된 공간), 보호기 구성, 알고리즘 강도, 하드웨어 기반 암호화 사용 여부 같은 조건이 달라지면 “변환 작업이 재개”되거나 “정책 충돌로 반복 시도”가 발생할 수 있다.
이때 디스크 I/O가 장시간 증가하고, 부팅/로그온 지연, 탐색기 응답 저하, 배터리 소모 증가, SSD 벤치마크 저하 같은 체감 문제가 나타나기 쉽다.
부팅 직후 디스크 사용률이 100%에 가깝게 유지되다.
파일 복사, 압축 해제, 대용량 설치에서 평소 대비 시간이 크게 늘다.
작업 관리자의 “시스템” 또는 “BitLocker Drive Encryption Service” 관련 부하가 지속되다.
노트북에서 배터리 소모가 증가하고 발열이 커지다.
아래 중 어디에 해당하는지 먼저 판단하면 해결 속도가 빨라지다.
| 구분 | 주요 징후 | 핵심 원인 | 우선 조치 |
|---|---|---|---|
| 암호화 진행 중 | Conversion Status가 “Encryption in Progress”로 보이다 | 초기 암호화/재암호화가 실제로 수행 중이다 | 진행 완료 유도 또는 일시중지/재개를 설계하다 |
| 정책/경로 혼선 | 설정 앱과 제어판 표기가 다르다 | 장치 암호화 토글과 BitLocker 설정이 상충하다 | 하나의 관리 경로로 통일하다 |
| 알고리즘/강도 영향 | 256bit 강도, 전체 암호화 적용이 확인되다 | 보안 강도 선택이 성능에 영향을 주다 | 요구 수준에 맞게 방식 선택을 정리하다 |
| 드라이버/펌웨어 영향 | 업데이트 이후 갑자기 느려지다 | 스토리지 드라이버, 펌웨어, TPM/BIOS 변화가 연계되다 | 업데이트와 암호화 상태를 함께 점검하다 |
Windows 설정에서 “개인 정보 및 보안” 또는 “프라이버시 및 보안” 영역의 “장치 암호화” 항목을 확인하다.
여기에서 켜짐으로 표시되면, OS 드라이브가 자동 암호화 흐름에 들어가 있거나 이미 암호화되어 있을 가능성이 크다.
제어판의 BitLocker 드라이브 암호화(또는 “BitLocker 관리”)에서 OS 드라이브와 데이터 드라이브 각각의 보호 상태를 확인하다.
여기에서 “BitLocker 켜기/끄기”, “보호 일시 중단”, “복구 키 백업” 같은 항목이 보이다.
가장 확실한 확인 방법은 manage-bde 명령으로 상태를 읽는 것이다.
:: 관리자 권한 명령 프롬프트 또는 PowerShell에서 실행하다 manage-bde -status :: 특정 드라이브만 확인하다 manage-bde -status C: manage-bde -status D: 출력에서 아래 항목을 중심으로 읽다.
| 출력 항목 | 의미 | 성능과의 관련성 |
|---|---|---|
| Conversion Status | 암호화/복호화 진행 상태이다 | 진행 중이면 I/O 부하가 발생하기 쉽다 |
| Percentage Encrypted | 암호화 진행률이다 | 낮을수록 아직 작업이 남아있다 |
| Encryption Method | XTS-AES 128/256 등 알고리즘 정보이다 | 256 선택은 128 대비 부하가 늘 수 있다 |
| Protection Status | 보호 활성/비활성 상태이다 | 보호 일시중단이 성능을 “직접” 올리지는 않지만 문제분리에 유용하다 |
| Key Protectors | TPM, PIN, 복구키 등 보호기 구성이다 | 부팅 흐름/복구 화면 반복 이슈 분석에 필요하다 |
개인 사용자라면 설정 앱의 장치 암호화 중심으로 단순 운용하는 쪽이 관리 부담이 적다.
업무용 또는 정책 준수가 필요한 환경이라면 BitLocker를 정책(GPO/MDM) 기준으로 운영하는 편이 일관성이 좋다.
혼용 문제의 핵심 해결은 “장치 암호화 토글과 BitLocker 정책/설정이 동시에 드라이브를 흔들지 않게” 만드는 것이다.
복구키를 백업하다.
노트북이라면 전원 어댑터를 연결하다.
중요 데이터는 외장 저장소 또는 백업으로 이중화하다.
:: 복구 화면 대비로, 현재 상태를 텍스트로 저장하다 manage-bde -status > "%USERPROFILE%\Desktop\bitlocker_status.txt" Conversion Status가 진행 중이라면, 체감 성능 저하의 상당 부분이 “진행 작업 자체”에서 발생하다.
이 경우 선택지는 세 가지이다.
첫째, 가능한 한 빠르게 완료시키다.
둘째, 업무 시간에는 일시 중단하고 야간에 재개하다.
셋째, 암호화 자체를 중단하고 복호화하여 원복하다.
:: 암호화 작업을 일시 중단하다 manage-bde -pause C: :: 다시 재개하다 manage-bde -resume C: :: 암호화를 끄고 복호화를 시작하다 manage-bde -off C: 대표 패턴은 “장치 암호화가 켜진 상태에서 BitLocker를 다시 구성”하거나, 반대로 “BitLocker를 끈 뒤 장치 암호화가 다시 켜지는” 형태이다.
이때는 관리 경로를 하나로 고정해야 한다.
회사 정책이나 보안 기준으로 BitLocker를 유지해야 한다면, 장치 암호화 토글을 끄는 방향으로 정리하다.
설정 앱에서 장치 암호화를 끄고, 필요 시 복호화를 완료한 뒤, 제어판 또는 정책 기준으로 BitLocker를 다시 켜다.
재구성 시 “사용된 공간만 암호화”와 “전체 암호화” 선택이 가능한데, 초기 성능 부담과 완료 시간은 사용된 공간만 암호화가 유리한 편이다.
개인용이며 별도의 정책이 없다면 장치 암호화 토글만으로 관리하는 편이 단순하다.
제어판에서 BitLocker를 끄거나, 불필요한 추가 설정(PIN 강제 등)을 제거하여 충돌 요인을 줄이다.
핵심은 “한쪽에서 켜고 다른 쪽에서 또 켜는” 상황을 끝내는 것이다.
Encryption Method가 XTS-AES 256으로 고정되어 있고, 해당 강도가 조직 요구사항이 아니라면 128을 고려할 수 있다.
다만 암호화 방법 변경은 보통 “이미 암호화된 드라이브”에는 즉시 적용되지 않고, 재암호화가 필요할 수 있어 운영 리스크가 발생하다.
따라서 정책 변경은 신규 설치 또는 재암호화 계획이 있는 유지보수 창에 맞춰 수행하는 편이 안전하다.
일부 환경에서는 SSD의 하드웨어 기반 암호화 사용 여부, 스토리지 드라이버, 펌웨어 조합에 따라 성능과 안정성이 달라지다.
업무 환경에서는 예측 가능성을 위해 소프트웨어 기반 암호화를 강제하는 정책을 적용하기도 하다.
이 설정은 로컬 그룹 정책 편집기에서 BitLocker 드라이브 암호화의 “하드웨어 기반 암호화 사용” 항목으로 관리하는 것이 일반적이다.
Windows 11 Home에서는 로컬 그룹 정책 편집기가 기본 제공되지 않는 경우가 많으므로, 이 경로로 제어하기 어렵다는 점을 전제로 판단해야 한다.
조치 후에는 “체감”만으로 결론을 내지 말고 최소한의 재현 가능한 확인 절차를 두는 것이 좋다.
manage-bde -status C: Conversion Status가 완료 상태로 보이고 Percentage Encrypted가 100%로 고정되는지 확인하다.
작업 관리자에서 디스크 사용률이 부팅 후 정상 범위로 내려오는지 확인하다.
대용량 파일 복사, 압축 해제, 개발 빌드 캐시 생성 같은 “I/O 민감 작업”을 동일 조건에서 비교하다.
| 점검 항목 | 권장 기준 | 재발 방지 효과 |
|---|---|---|
| 관리 경로 통일 | 장치 암호화 또는 BitLocker 중 하나로 통일하다 | 상충 설정으로 인한 재암호화/반복 시도를 예방하다 |
| 복구키 보관 | 계정 또는 조직 저장소에 백업하다 | 업데이트/펌웨어 변경 후 복구 화면 대응이 가능하다 |
| 업데이트 후 점검 | 대형 업데이트 후 manage-bde 상태를 확인하다 | 예상치 못한 보호/복구 동작을 조기에 발견하다 |
| 암호화 방식 변경 관리 | 업무 시간 외 유지보수 창에 수행하다 | 진행 중 I/O 부하로 인한 업무 장애를 줄이다 |
일반적으로 암호화를 끄면 암호화로 인한 오버헤드는 줄어들 수 있다.
하지만 데이터 보호 요구사항이 있는 환경에서는 선택지가 아닐 수 있다.
또한 현재 느림의 주 원인이 “암호화 진행 중”이라면, 끄는 과정 자체가 복호화로 이어져 당분간 I/O 부하가 유지될 수 있다.
manage-bde -pause로 일시 중단하고, 업무 종료 후 manage-bde -resume으로 재개하는 방식이 실무에서 자주 쓰이다.
다만 노트북 절전/전원 정책, 업데이트 재부팅이 끼어들면 계획이 틀어질 수 있으므로, 전원 연결과 재부팅 통제가 가능한 시간에 수행하는 편이 안정적이다.
TPM 상태 변화, 펌웨어 설정 변화, 정책 변경, 보호기 변경이 있으면 복구 화면이 나타날 수 있다.
작업 전 복구키를 확보했다면 복구키 입력 후 정상 부팅이 가능하다.
반복된다면 보호기 구성이 계속 변하고 있는지, 장치 암호화 토글과 BitLocker 정책이 동시에 개입하는지부터 다시 점검해야 하다.
Home에서도 장치 암호화가 BitLocker 기반으로 동작하는 흐름이 있을 수 있어 명령이 일부 동작하는 경우가 있다.
다만 정책 편집기 기반의 세밀한 제어는 제한될 수 있으므로, “통일된 한 경로로 운영”이라는 원칙을 더 강하게 적용하는 편이 안전하다.