오늘 아침 노트북 전원을 켰는데 익숙해지고 싶지 않은 파란 화면이 또 나타났다. BitLocker 복구키를 입력하라는 화면이었다.
처음 한두 번은 복구키를 입력하고 Windows에 들어가는 것으로 넘겼다. 그런데 최근에는 노트북을 켤 때마다 비슷한 일이 반복됐다. 매번 48자리 숫자를 확인하고 입력하는 것도 번거로웠지만, 그보다 더 신경 쓰였던 것은 왜 정상적으로 사용하던 노트북에서 BitLocker 복구 화면이 계속 나타나는지 알 수 없다는 점이었다.
이번에는 그냥 넘어가지 않기로 했다. Windows에 정상 진입한 뒤 BitLocker 상태부터 하나씩 확인해 봤다. 결론부터 적으면 보호기를 한 번 일시 중지했다가 다시 활성화한 뒤 재부팅과 완전 종료 후 전원 켜기까지는 BitLocker 복구 화면 없이 정상 부팅되고 있다.
BitLocker 보호기를 일시 중지한 뒤 다시 활성화했고, 이후 일반 재부팅과 완전 종료 후 콜드부팅까지 정상적으로 확인했다. 다만 하루 이상 장기간 사용하면서 재발하지 않는 것까지 확인한 것은 아니다. 따라서 이 글에서는 아직 “완전히 해결됐다”라고 단정하지 않는다.

노트북 부팅 때 BitLocker 복구키 화면이 반복됐다
BitLocker 화면 자체를 처음 본 것은 아니었다. 문제는 최근 들어 노트북을 켤 때 비슷한 상황이 반복된다는 것이었다. 복구키가 있으니 Windows에 들어가는 것은 가능했지만 매번 같은 절차를 반복하는 것은 정상적인 상태로 보이지 않았다.
인터넷에서 흔히 보이는 해결방법만 보고 바로 BIOS 설정을 바꾸거나 TPM을 초기화하고 싶지는 않았다. BitLocker가 드라이브 암호화와 연결된 보안 기능인 만큼 잘못 건드렸다가 오히려 Windows에 진입하지 못하는 상황이 생길 수 있다는 점이 먼저 마음에 걸렸다.
이번 작업에서 가장 먼저 중요하다고 느낀 부분이다. BitLocker 복구키를 확실하게 확보하기 전에는 TPM 초기화, BIOS/UEFI 설정 변경, Secure Boot 설정 변경, BitLocker 해제 같은 작업을 함부로 진행하지 않는 편이 안전하다. PC와 설정 상태에 따라 예상하지 못한 복구키 입력이 다시 필요해질 수 있기 때문이다.
특히 화면 캡처를 블로그나 커뮤니티에 올릴 때는 48자리 BitLocker 복구키와 복구키 ID를 반드시 가려야 한다. 복구키 자체는 다른 사람에게 공개할 정보가 아니다.
1. BitLocker 상태부터 확인했다
Windows에 정상 진입한 뒤 관리자 권한으로 명령 프롬프트를 실행했다. 첫 번째로 궁금했던 것은 C드라이브가 실제로 어떤 상태인지였다.
이 명령은 C드라이브의 BitLocker 암호화 상태와 보호 상태 등을 확인하는 용도다. 결과를 보니 C드라이브는 BitLocker로 100% 암호화되어 있었고 보호 상태도 활성화되어 있었다.
즉 BitLocker 자체가 꺼져 있어서 생긴 문제는 아니었다. 암호화는 정상적으로 적용되어 있고, 부팅 과정에서 어떤 이유로 복구 모드가 호출되는 쪽에 더 가까워 보였다.

2. BitLocker 복구키와 키 보호기를 먼저 확인했다
다음으로 확인한 것은 C드라이브에 어떤 키 보호기가 등록되어 있는지였다. 무엇보다 이후 작업을 진행하기 전에 48자리 BitLocker 복구키를 확실하게 확보하는 것이 먼저라고 판단했다.
확인 결과 TPM과 숫자 암호 보호기가 등록되어 있었다. 숫자 암호 항목에서는 48자리 BitLocker 복구키도 확인할 수 있었다. 이 복구키는 바로 별도로 보관했다.
여기에서 한 가지 더 알게 됐다. 그동안 Microsoft 계정에 복구키가 당연히 백업되어 있을 것이라고 생각했는데, 실제로 확인해 보니 Microsoft 계정에 복구키를 미리 백업해 둔 상태가 아니었다.
만약 Windows에 들어갈 수 없는 상황에서 복구키까지 찾지 못했다면 훨씬 난감했을 것이다. 이번 문제를 해결하는 것과 별개로 복구키를 어디에 보관하고 있는지를 평소 확인해 두는 것이 중요하다는 사실을 제대로 느꼈다.
- 48자리 BitLocker 복구키는 공개하지 않는다.
- 복구키 ID도 블로그 화면에서는 가린다.
- PC 이름, 이메일 주소 등 개인 식별정보가 함께 보이는지도 확인한다.
- 원본 화면을 그대로 올리기보다 필요한 부분만 잘라서 사용하는 편이 안전하다.
3. TPM 문제가 있는지 확인했다
BitLocker가 부팅 과정에서 TPM과 연결되어 동작한다는 점 때문에 다음으로 TPM 상태를 확인했다. TPM이 꺼져 있거나 준비되지 않은 상태라면 원인을 찾는 방향도 달라질 수 있다고 생각했다.
확인 결과 TpmPresent, TpmReady, TpmEnabled, TpmActivated 등이 모두 True로 나타났다. 적어도 현재 Windows에서 확인한 TPM 상태만 놓고 보면 TPM 자체가 꺼져 있거나 준비되지 않은 상황은 아니었다.

4. Secure Boot도 True였다
TPM 상태가 정상이어서 Secure Boot도 확인해 봤다.
결과는 True였다. Secure Boot도 현재 활성화되어 있다는 뜻이었다.
여기까지 확인하니 처음 생각했던 단순한 시나리오와는 조금 달랐다. TPM이 꺼져 있는 것도 아니고 Secure Boot가 비활성화된 것도 아니었다.

5. 그렇다면 BitLocker 반복 원인은 무엇이었을까
여기서부터는 확인된 사실과 추정을 구분할 필요가 있었다. 이번 점검으로 확인한 것은 TPM과 Secure Boot가 현재 활성화되어 있다는 사실이다. 그렇다고 해서 왜 최근 부팅 때마다 BitLocker 복구키 화면이 나타났는지 정확한 원인까지 확인된 것은 아니다.
다만 BitLocker는 TPM을 이용해 부팅 환경의 무결성을 확인하고, 예상하지 못한 부팅 환경 변화가 감지되면 복구 모드로 들어갈 수 있다. 그래서 현재 상태를 보면서 TPM이나 Secure Boot가 단순히 꺼진 문제라기보다 부팅 과정에서 TPM이 기억하고 있는 측정 상태와 어떤 변화가 생겼던 것은 아닐까 하는 쪽으로 생각이 옮겨갔다.
- BitLocker 암호화: 정상 적용
- BitLocker 보호: 활성화 상태
- TPM: 주요 상태값 True
- Secure Boot: True
- 따라서 단순한 TPM OFF 또는 Secure Boot OFF 문제라고 보기는 어려웠다.
정확한 원인을 확정할 만큼 이벤트 로그나 펌웨어 변경 이력까지 분석한 것은 아니기 때문에 “Secure Boot 때문에 발생했다”거나 “TPM 오류가 원인이었다”고 단정하지는 않는다. 이번에는 먼저 BitLocker 보호 상태를 다시 정상적인 부팅 환경과 맞춰보는 쪽으로 접근했다.
6. 내가 시도한 BitLocker 해결방법, 보호기를 일시 중지했다
복구키를 확보했고 TPM과 Secure Boot 상태도 확인했기 때문에 다음 단계로 BitLocker 보호기를 한 번 일시 중지해 보기로 했다.
이 명령은 C드라이브의 BitLocker 암호화를 풀어버리는 작업이 아니다. 드라이브에 저장된 데이터를 복호화하는 것이 아니라 BitLocker 보호기를 일시 중지하는 작업이다.
명령을 실행한 뒤 Windows 메뉴에서 ‘다시 시작’을 선택했다. 조금 긴장한 채 부팅 화면을 지켜봤는데 이번에는 파란 BitLocker 복구키 화면이 나타나지 않았다. Windows가 바로 정상 부팅됐다.
7. 정상 부팅 후 BitLocker 보호기를 다시 활성화했다
한 번 정상 부팅됐다고 해서 보호를 중지한 상태로 계속 사용할 생각은 없었다. Windows에 들어온 뒤 BitLocker 보호기를 다시 활성화했다.
활성화한 뒤에는 처음 사용했던 명령으로 다시 상태를 확인했다.
BitLocker 보호가 다시 정상적으로 활성화된 것을 확인했다. 그 상태에서 다시 한 번 재부팅했다. 이번에도 BitLocker 복구키 화면은 나타나지 않았다.
8. 재부팅만 정상인 것은 아닐까, 완전 종료 후 다시 켜봤다
여기에서 한 번 더 확인하고 싶었다. Windows의 ‘다시 시작’과 노트북 전원을 완전히 끈 뒤 다시 켜는 과정은 체감상 다르기 때문이다. 최근 문제도 주로 아침에 노트북 전원을 처음 켰을 때 나타났다.
그래서 Windows를 완전히 종료했다. 전원이 꺼진 것을 확인하고 다시 전원 버튼을 눌렀다.
부팅 화면을 기다렸는데 이번에도 BitLocker 복구 화면은 나오지 않았다. 완전 종료 후 다시 전원을 켠 콜드부팅까지 정상적으로 통과했다.
적어도 오늘 진행한 테스트 범위에서는 보호기 일시 중지 → 재부팅 → 보호기 재활성화 → 재부팅 → 완전 종료 후 부팅까지 모두 정상이다.
BitLocker 반복 문제를 겪으며 가장 중요했던 순서
이번에는 처음부터 BIOS로 들어가 설정을 바꾸거나 TPM을 초기화하지 않았다. 돌아보면 그 순서가 가장 중요했다.
- Windows에 진입할 수 있을 때 BitLocker 상태부터 확인
- 48자리 복구키를 먼저 확보
- TPM 상태 확인
- Secure Boot 활성화 여부 확인
- 확인된 결과를 보고 원인 범위를 좁히기
- BitLocker 보호기를 일시 중지하고 재부팅
- 보호기를 다시 활성화
- 재부팅과 완전 종료 후 부팅을 각각 확인
특히 인터넷에서 해결방법을 찾다 보면 TPM 초기화나 BIOS 설정 변경부터 시도하고 싶어질 수 있다. 하지만 BitLocker 복구키도 확보하지 않은 상태에서 보안 관련 설정부터 바꾸는 것은 이번에는 선택하지 않았다. 먼저 현재 상태를 확인하고 되돌아올 수 있는 수단부터 확보하는 것이 맞다고 판단했다.
그래서 BitLocker 반복 문제는 해결됐을까
현재 상태만 보면 상당히 긍정적이다. 보호기를 다시 활성화한 상태에서도 재부팅이 정상적으로 됐고, Windows를 완전히 종료했다가 전원을 다시 켠 뒤에도 복구키 화면 없이 부팅됐다.
하지만 아직 완전히 해결됐다고 적지는 않으려고 한다. 최근 문제가 노트북을 처음 켤 때 반복해서 나타났기 때문에 오늘 몇 차례 정상 부팅됐다는 것만으로 장기간 재발하지 않는다고 판단하기는 이르다.
TPM과 Secure Boot는 정상 활성화 상태였고, BitLocker 보호기를 일시 중지한 뒤 정상 부팅시키고 다시 활성화했다. 그 뒤 일반 재부팅과 완전 종료 후 부팅까지 정상적으로 확인했다. 다만 장기간 재발 여부는 아직 확인 중이다.
내일 아침이 중요한 시험이 될 것 같다. 평소처럼 노트북을 완전히 꺼둔 상태에서 첫 부팅을 해보고 BitLocker 복구키 화면이 다시 나타나는지 확인해 볼 예정이다.
다음 날 아침 첫 부팅 결과까지 확인한 뒤 이 글에 최종 결과를 업데이트할 생각이다. 며칠 더 사용한 뒤 같은 현상이 다시 발생한다면 그때는 Windows 이벤트 로그와 BIOS/UEFI 업데이트 이력까지 범위를 넓혀 원인을 다시 찾아볼 예정이다.
이번에 남은 것은 특별한 명령어 하나보다 순서였다. 문제가 생겼다고 바로 설정부터 바꾸는 것이 아니라 현재 상태를 먼저 확인하고, 복구할 수 있는 키를 확보한 뒤 하나씩 범위를 좁혀가는 편이 마음도 덜 급해졌다. BitLocker처럼 데이터와 직접 연결된 보안 기능은 해결 속도보다 되돌아올 방법을 먼저 확보하는 것이 중요했다.
이 글은 제 노트북에서 직접 확인하고 진행한 과정을 기록한 것입니다. PC 제조사, BIOS/UEFI 구성, Windows 버전, BitLocker 설정 방식에 따라 원인과 해결방법은 달라질 수 있습니다.
따라 하시기 전에는 중요한 데이터를 먼저 백업하고 48자리 BitLocker 복구키를 반드시 확보하시기 바랍니다. 복구키를 확보하지 않은 상태에서 TPM을 초기화하거나 BIOS/UEFI 및 Secure Boot 설정을 변경하는 작업은 특히 신중하게 진행하시기 바랍니다. 회사나 기관에서 관리하는 PC라면 개인적으로 설정을 변경하기보다 먼저 IT 관리자에게 확인하시는 것이 좋습니다.
'퇴직 후 삶' 카테고리의 다른 글
| 농업인과 농업경영체는 다르다|귀농 전에 알아둘 등록 조건과 실제 달라지는 것 (0) | 2026.08.26 |
|---|---|
| 사찰음식은 왜 오신채를 사용하지 않을까? 오신채 5가지와 사찰음식의 의미 (0) | 2026.08.07 |
| 퇴직 후 작심삼일을 줄이는 방법|90일 동안 꾸준함을 확인하는 실천법 (1) | 2026.08.06 |
| “봉사활동도 구직이라고?” 실업급여 적자 논쟁에서 퇴직자가 확인할 것 (0) | 2026.08.05 |
| 퇴직 후 건강보험료 공단에 직접 물어봤다|임의계속가입보다 지역가입자가 저렴했던 이유 (0) | 2026.08.04 |