BitLocker 실무 가이드 ── 복구 키 관리로 시작하는 드라이브 암호화

“PC를 초기화했더니 다음 부팅에서 처음 보는 파란 화면이 나오고 48자리 키를 요구받았다”, “BIOS를 업데이트했을 뿐인데 복구 키 입력 화면이 떴다. 그런 키는 받은 적이 없다”, “새 PC 설정을 보니 ‘디바이스 암호화’가 멋대로 켜져 있다. 업무 앱이 느려질 것 같으니 꺼버려도 되는가” ── 최근 1년 사이 고객으로부터 이런 종류의 상담이 눈에 띄게 늘었습니다.

배경은 분명합니다. Windows 11 버전 24H2 이후, 클린 설치한 PC에서는 ‘디바이스 암호화’(BitLocker의 자동 활성화)가 기본으로 동작하게 되었기 때문입니다. 하드웨어 요구 사항도 완화되어 대상이 되는 PC가 크게 늘었습니다. 즉 BitLocker는 이제 ‘대기업이 의식적으로 도입하는 것’이 아니라 ‘중소기업의 PC에도 조용히 들어오는 것’으로 바뀌었습니다. 이때 유일한 생명줄이 되는 것이 복구 키이며, 이것이 누구의 관리도 받지 않은 채 암호화만 진행되는 상태가 가장 위험합니다.

이 글에서는 중소기업의 정보시스템 담당자·경영자와, 업무 앱이나 장치 PC를 맡고 있는 개발자를 대상으로 BitLocker를 ‘끄는 것’이 아니라 ‘제대로 활용하는 것’으로 정리합니다. 에디션별 차이, TPM과 키의 관계라는 최소한의 원리, 복구 키 저장 위치 판단표, 조직에서의 활성화와 운영, 사고 대응, 그리고 폐기와의 관계까지, 2026년 8월 시점의 Microsoft Learn 등 1차 정보를 바탕으로 해설합니다.

1. 먼저 결론

• BitLocker는 드라이브 전체를 암호화하는 Windows의 기능으로, 분실·도난·부적절한 폐기로 인한 데이터 유출을 막습니다. 디스크를 빼내 다른 PC에 연결하는 공격에 대해서도, 암호화되어 있으면 데이터를 읽을 수 없습니다.¹
• 전체 기능의 BitLocker를 활성화할 수 있는 것은 Pro/Enterprise/Pro Education/Education입니다. 그 간이판인 ‘디바이스 암호화’는 Home을 포함한 모든 에디션에서 이용할 수 있습니다.¹
• Windows 11 24H2 이후 자동 디바이스 암호화의 요구 사항이 완화되었습니다. HSTI/Modern Standby 요구 사항과 ‘허용되지 않은 DMA 인터페이스가 없을 것’이라는 요구 사항이 철폐되어, 클린 설치 후 OOBE(초기 설정) 완료 시점에 TPM+UEFI Secure Boot를 충족하는 많은 PC에서 암호화가 기본으로 초기화됩니다.²
• 암호화의 ‘시작’과 보호의 ‘활성화’는 별개입니다. Microsoft 계정·Entra ID·(복구 정책이 구성된) AD DS 중 어느 하나로 복구 키 백업이 성공할 때까지 보호는 활성화(암)되지 않습니다. 어디에도 백업되지 않는 로컬 계정만 사용하는 PC는 암호화되어 있어도 보호되지 않는 상태로 남습니다.¹²
• 복구 키(48자리 복구 암호)의 저장 위치는 Entra ID / AD DS / Microsoft 계정 / 인쇄·파일의 4가지 중 하나입니다. Entra ID 참가라면 Entra ID로, AD 도메인 참가라면 AD DS로, 둘 다 아니라면 관리자의 Microsoft 계정으로 저장되는 것이 기본 흐름입니다.¹³
• 복구 키가 요구되는 것은 이상 상황일 때만이 아닙니다. 펌웨어 업데이트, Secure Boot 설정 변경, TPM 초기화, 메인보드 교체, 드라이브 교체 등 부팅 환경의 변화는 모두 트리거가 될 수 있습니다. 계획된 작업 전에는 보호의 일시 중지(서스펜드)가 정석입니다.³
• 기본 암호화 방식은 XTS-AES 128비트입니다. 방식을 나중에 바꾸려면 복호화 후 재암호화가 필요하므로, 처음에 확실히 정해 두는 것이 유리합니다. 새 드라이브라면 ‘사용한 공간만 암호화’로 초기 암호화 시간을 크게 단축할 수 있습니다.⁴⁵
• 복구 키를 요구받았는데 제시하지 못하는 PC의 데이터는 포기할 수밖에 없습니다. Microsoft 지원팀도 분실한 키는 꺼낼 수 없습니다. 그렇기 때문에 이 글의 주제는 ‘암호화를 할지 말지’가 아니라 ‘복구 키를 어디에 저장하고 누가 꺼낼 수 있게 할 것인가’입니다.⁶

2. BitLocker와 디바이스 암호화의 차이 ── 에디션별로 무엇을 사용할 수 있는가

먼저 용어를 정리하겠습니다. ‘BitLocker’와 ‘디바이스 암호화’는 같은 암호화 기술의 두 얼굴입니다.

• BitLocker(전체 기능): 드라이브 단위로 활성화하며, TPM+PIN·시작 키 등의 인증 방식, 그룹 정책/Intune을 통한 제어, manage-bde.exe나 PowerShell을 통한 관리까지 포함하는 관리자용 모습.
• 디바이스 암호화(Device Encryption): 요구 사항을 충족하는 PC에서 BitLocker를 자동으로 활성화하는 구조. 설정 앱에 ‘디바이스 암호화’ 스위치가 나타나며, OS 드라이브와 내장 고정 드라이브만 암호화합니다(외장/USB 드라이브는 대상 외).¹

에디션별 대응은 다음과 같습니다.¹

Windows 11 24H2에서 무엇이 바뀌었는가

자동 디바이스 암호화는 이전부터 있었지만, 대상은 ‘Modern Standby 또는 HSTI 준수’, ‘외부에서 DMA로 접근 가능한 포트가 없음’ 같은 조건을 충족하는, 비교적 신형인 모바일 PC가 중심이었습니다. Windows 11 버전 24H2에서 이 두 요구 사항이 철폐되어, 남은 주요 조건은 ‘TPM(1.2 또는 2.0) 탑재’, ‘UEFI Secure Boot 활성화’ 등으로 좁혀졌습니다. OEM이 허용되지 않은 DMA 버스를 레지스트리(AllowedBuses)에 등록하는 운용도 필요 없어졌으며, 이 키 자체가 24H2 이후로는 무시됩니다. 다만 이 요구 사항 완화는 Windows IoT 에디션에는 적용되지 않습니다.²

그 결과 클린 설치(초기화·재설정 포함) 후 OOBE를 완료하면 아주 평범한 데스크톱 PC에서도 암호화가 기본으로 초기화되게 되었습니다. 여기서 중요한 것이 ‘초기화’와 ‘보호의 활성화’의 구분입니다.

• OOBE 완료 시점에는 드라이브가 클리어 키(보호 없는 임시 키)로 암호화된 상태입니다. 탐색기에는 경고 아이콘이 표시됩니다.¹
• Microsoft 계정·Entra ID 계정으로 로그인하거나, 도메인 참가 PC라면 (복구 정책이 구성된) AD DS로의 백업이 성공하면 TPM 보호기가 생성되어 클리어 키가 제거됩니다. 이 시점에서 비로소 보호가 활성화됩니다.¹²
• 로컬 계정만으로 사용하는 PC는 암호화되어 있어도 보호되지 않는 상태 그대로입니다.¹

이 흐름을 그림으로 나타내면 다음과 같습니다.

flowchart TB
    A["클린 설치·초기화<br/>Windows 11 24H2 이후"] --> B{"TPM+UEFI Secure Boot 등<br/>요구 사항을 충족하는가"}
    B -- "충족하지 않음" --> Z["암호화되지 않음"]
    B -- "충족함" --> C["OOBE 완료 시 암호화 초기화<br/>클리어 키=보호 없는 임시 키"]
    C --> D{"복구 키의<br/>백업 위치는?"}
    D -- "Microsoft 계정 / Entra ID /<br/>AD DS, 복구 정책 구성 완료" --> E["복구 키 백업 성공"]
    E --> F["TPM 보호기 생성·클리어 키 제거<br/>=보호가 활성화됨"]
    D -- "로컬 계정만 사용<br/>백업 위치가 없음" --> G["암호화된 채로 보호는 비활성<br/>경고 아이콘이 표시됨"]

‘어느새 암호화되어 있었다’의 정체는 바로 이 구조입니다. Windows 10 지원 종료 대응으로 Windows 11 PC로의 교체를 진행하는 조직은(Windows 10 지원 종료 판단), 새 PC가 처음부터 이 상태로 도착한다는 것을 전제로 복구 키 관리를 키팅 절차에 포함시킬 필요가 있습니다.

자신의 PC가 대응하는지는 시스템 정보(msinfo32.exe)를 관리자 권한으로 열어 ‘디바이스 암호화 지원’ 행에서 확인할 수 있습니다. ‘전제 조건을 충족합니다’로 표시되면 대상입니다.¹

3. 최소한의 원리 ── TPM과 키의 관계

BitLocker의 키를 지키고 있는 것은 TPM(Trusted Platform Module)입니다. TPM은 OS가 오프라인인 동안 디바이스가 변조되지 않았음을 확인하는 역할을 맡으며, 부팅 시 검증을 통과했을 때만 암호화 키를 사용할 수 있게 합니다. 그렇기 때문에 정규 Windows가 정상적으로 부팅되면 사용자는 아무것도 입력하지 않고 사용할 수 있고, 디스크만 빼냈을 경우에는 읽을 수 없다는 양립이 가능합니다.¹ TPM 자체의 원리(키를 밖으로 내보내지 않는 구조, PCR, 측정 부팅)는 ‘Windows TPM이란 무엇인가‘에서 그림으로 설명하고 있습니다.

부팅할 때마다 일어나는 일을 그림으로 나타내면 다음과 같습니다.

flowchart TB
    ON["전원 켜기"] --> M["TPM이 부팅 환경을 측정<br/>펌웨어·부팅 구성 등"]
    M --> Q{"측정 결과가<br/>평소와 같은가"}
    Q -- "같음" --> UN["TPM이 암호화 키를 해제"]
    UN --> BOOT["정상 부팅<br/>사용자는 아무것도 입력하지 않음"]
    Q -- "다름" --> REC["복구 모드<br/>48자리 복구 키를 요구"]
    REC --> K1["복구 키를 입력하면 부팅"]
    REC --> K2["입력하지 못하면<br/>데이터를 꺼낼 수 없음"]

TPM 외에도 부팅 시 PIN 입력이나 시작 키(USB 메모리 안의 키 파일) 삽입을 필수로 하는 다중 요소 구성도 선택할 수 있습니다. TPM이 없는 PC에서도 시작 키 방식으로 OS 드라이브를 암호화할 수 있지만, 암호 방식은 잠금 메커니즘이 없어 무차별 대입 공격에 취약하기 때문에 기본적으로 비활성화되어 있습니다.¹

복구 키가 요구되는 것은 어떤 때인가

TPM은 ‘부팅 환경이 평소와 같은가’를 보고 있으므로, 환경이 바뀌면 정당한 소유자라도 복구 모드로 진입합니다. Microsoft가 제시하는 대표적인 트리거는 다음과 같습니다.³

• BIOS/UEFI 펌웨어 업데이트 등, 초기 부팅 구성 요소의 업데이트
• TPM을 끄거나 비활성화·초기화했거나, TPM 자체 테스트 실패
• TPM 검증 프로필이 사용하는 PCR(플랫폼 구성 레지스터)의 변경 ── Secure Boot 설정 변경이 여기에 해당합니다
• 메인보드 교체(새 TPM으로의 교체)
• BitLocker로 보호된 드라이브를 다른 PC로 옮긴 경우
• 도킹 스테이션의 탈부착, NTFS 파티션 테이블 변경, 부팅 관리자 변경, PXE 부팅
• PIN을 반복해서 잘못 입력한 경우, TPM 1.2 기종에서 부팅 장치 순서를 변경한 경우

즉 ‘BIOS 업데이트로 복구 키를 요구받았다’는 것은 고장도 공격도 아니라 설계대로의 동작입니다. 계획된 작업(펌웨어 업데이트나 하드웨어 교체) 전에는 보호를 일시 중지(서스펜드)하는 것이 정석이며, 일시 중지해도 드라이브는 암호화된 상태를 유지하고, 작업 후에는 복구 키 입력 없이 재개할 수 있습니다. 기본적으로 재부팅하면 보호가 자동으로 재개됩니다(재부팅 횟수 지정도 가능).³

# 펌웨어 업데이트 전에 일시 중지. 기본적으로 1회 재부팅으로 보호가 자동 재개되기
# 때문에, 여러 번 재부팅하는 업데이트에서는 두 번째 이후의 재부팅이 복구 화면에서
# 멈출 수 있다.
# -RebootCount 0으로 자동 재개를 멈추고, 작업 완료 후의 재개를 절차에 포함시킨다
Suspend-BitLocker -MountPoint C: -RebootCount 0
# 작업 후 반드시 재개한다(-RebootCount 0에서는 자동 재개되지 않으므로 이 실행이 필수)
Resume-BitLocker -MountPoint C:

참고로 용어에 대해 말씀드립니다. 기술 문서에서는 48자리 숫자를 ‘복구 암호’, USB 메모리에 저장하는 .bek 파일을 ‘복구 키’로 구분합니다만³, 일반 사용자용 화면과 이 글에서는 널리 쓰이는 명칭에 맞춰 48자리 숫자를 ‘복구 키’라고 부릅니다.

4. 복구 키 저장 위치 판단표 ── 네 가지 선택지 중 무엇을 고를까

이 글의 핵심입니다. 복구 키의 저장 위치는 사실상 네 가지 선택지이며, PC의 로그인 방식으로 거의 자동으로 정해집니다. 먼저 판단표를 제시합니다.

하이브리드 참가(AD와 Entra ID 양쪽) 디바이스에서는 복구 암호가 양쪽 모두에 백업됩니다.⁴

조직 차원에서 짚어야 할 포인트는 세 가지입니다.

1. ‘조직의 저장 위치’를 하나로 정한다. Entra ID 참가가 진행되고 있다면 Entra ID, 온프레미스 AD라면 AD DS입니다. 담당자 개인의 Microsoft 계정에 회사 PC의 복구 키가 들어 있는 상태는 퇴직·이동으로 즉시 무너집니다.
2. AD DS는 ‘자동으로 저장된다’고 단정하지 않는다. AD DS로의 백업에는 정책 구성(뒤에서 설명)이 전제입니다. 또한 Active Directory는 복구 암호의 이력을 계속 보관하며, 오래된 키는 컴퓨터 개체를 삭제하지 않는 한 자동으로는 사라지지 않습니다.³
3. 파일 저장을 선택한다면 저장 위치를 엄격히 관리한다. 복구 키 파일은 해당 PC 자신이 아닌 다른 위치(네트워크 폴더 등)에 저장해야 합니다.⁵ 복구 키를 가진 사람은 드라이브의 모든 데이터에 접근할 수 있으므로, 보호 대상 PC와 분리해 보관하고 접근을 통제하는 것이 필수입니다.³

지금 내 PC가 어떤 상태인지 확인하기

관리자 권한 터미널에서 다음 중 하나를 실행합니다.⁵

# PowerShell: 암호화 상태와 보호기 종류 확인
Get-BitLockerVolume C: | Format-List
# 복구 암호(48자리)와 그 ID 확인
(Get-BitLockerVolume -MountPoint C).KeyProtector

:: 명령 프롬프트: 상태 확인
manage-bde -status
:: 보호기(TPM, 복구 암호 등) 목록과 48자리 값
manage-bde -protectors -get C:

manage-bde -protectors -get C: 의 출력에서 ‘숫자 암호’(Numerical Password)로 표시되는 것이 48자리 복구 키이며, 함께 표시되는 ID의 앞 8자리가 복구 화면에서 ‘어느 키인지’를 대조하는 단서가 됩니다.⁶

이미 암호화된 PC의 복구 암호를 나중에 Entra ID나 AD DS로 백업할 수도 있습니다.⁵

# 복구 암호의 ID를 확인한 뒤 실행
# Entra ID로 백업
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"
# AD DS로 백업
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"

:: manage-bde를 사용하는 경우
manage-bde -protectors -aadbackup C: -id {ID}
manage-bde -protectors -adbackup C: -id {ID}

‘모든 PC의 복구 키가 조직의 저장 위치에 들어 있는가’에 대한 전수 조사는, IPA의 중소기업 대상 가이드라인이 말하는 정보 보안 기본 대책과 마찬가지로 한 번 하고 끝나는 것이 아니라 대장 운영에 올려야 하는 종류의 작업입니다(‘중소기업 보안 대책, 무엇부터 시작할까’).

5. 조직에서의 활성화와 운영 ── 정책·명령·암호화 방식

5.1. 정책으로 ‘복구 키 없는 활성화’를 금지한다

BitLocker 설정은 그룹 정책(GPO)과 MDM(Intune 등의 BitLocker CSP) 양쪽에서 구성할 수 있습니다.⁴ 복구 키 관리 관점에서 가장 중요한 정책은 ‘BitLocker로 보호된 운영체제 드라이브의 복구 방법 선택‘입니다. 여기서 다음을 구성합니다.⁴³

• AD DS에 복구 정보 저장(복구 암호만, 또는 키 패키지까지 포함)
• ‘복구 정보가 AD DS에 저장될 때까지 BitLocker를 사용하지 않음’ 활성화 ── 백업이 성공하지 않는 한 암호화를 시작시키지 않는, 사고 방지의 핵심입니다. 이 구성에서는 복구 암호가 자동 생성됩니다

Entra ID 참가 디바이스를 Intune으로 관리하는 경우도 사고방식은 같아서, 복구 키 백업을 필수로 만든 다음 암호화를 활성화합니다. Entra ID상의 복구 키는 Entra 관리 센터·Intune 관리 센터·PowerShell·Microsoft Graph에서 가져올 수 있으며, 헬프데스크에 위임할 수도 있습니다.³

5.2. 암호화 방식 ── 기본값은 XTS-AES 128

암호화 방식을 구성하지 않으면 BitLocker는 기본적으로 XTS-AES 128비트를 사용합니다. 디바이스 암호화도 기본값은 XTS-AES 128입니다. 정책 ‘드라이브 암호화 방법 및 암호 강도 선택’에서 XTS-AES 256 등으로 변경할 수 있지만, Microsoft의 권장 사항은 모든 드라이브에 XTS-AES를 사용하되, 키 길이는 디바이스의 성능(과 업계의 규제 요구 사항)에 따라 128/256 중에서 선택하라는 것입니다.⁴¹

주의할 점은 이미 암호화된 드라이브의 방식은 나중에 바꿀 수 없다는 것입니다. 방식이나 키 길이를 바꾸려면 일단 복호화한 뒤 다시 암호화해야 합니다.¹ ‘규제 요구 사항상 256비트가 필요하다’ 같은 사정이 있다면 배포 첫 단계에서 확실히 정해 두십시오.

5.3. 사용한 공간만 암호화 vs 드라이브 전체

활성화 시 하나 더 선택하는 것이 암호화 범위입니다. Microsoft의 구분 기준은 명확합니다.⁵

• 사용한 공간만 암호화: 데이터를 저장한 적 없는 새 드라이브용. 초기 암호화가 빠름
• 드라이브 전체 암호화: 이미 사용해 온 드라이브 ── 데이터를 저장한 적이 있어 삭제된 파일이 남아 있을 수 있는 드라이브용

이유는 삭제된 파일의 영역이 파일 시스템상 ‘빈 공간’으로 보이기 때문에, ‘사용한 공간만’으로는 암호화되지 않아 덮어써지기 전까지는 포렌식 도구로 복구될 수 있기 때문입니다.⁵ 키팅 직후의 새 PC라면 ‘사용한 공간만’으로 문제없고, 오래 사용해 온 PC에 나중에 적용한다면 전체 암호화, 라고 기억해 두면 실무에서는 충분합니다.

5.4. PowerShell을 통한 활성화

스크립트 배포의 기본형은 다음과 같습니다.⁵

# 1. 먼저 복구 암호(48자리) 보호기를 추가한다(이 시점에서는 암호화가 시작되지 않는다).
#    재시도 등으로 복구 암호가 여러 개 남아 있어도, 이번에 추가한 것 하나만
#    특정할 수 있도록 추가 전후의 ID 차이로 선택한다
$before = (Get-BitLockerVolume -MountPoint C).KeyProtector.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
$rpId = (Get-BitLockerVolume -MountPoint C).KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $before } |
    Select-Object -ExpandProperty KeyProtectorId

# 2. 추가한 복구 암호를 조직의 저장 위치로 백업한다. 여기서 실패하면
#    암호화로 진행해서는 안 되므로, -ErrorAction Stop으로 오류 시 처리를 중단한다
#    (Entra 관리 센터/AD에서 키가 보이는지 확인하는 것까지가 이 절차다)
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop
# AD DS라면: Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop

# 3. 백업이 성공한 뒤에 암호화를 시작한다. 3a와 3b는 상호 배타적 ──
#    둘 중 하나만 실행한다(방식·범위도 여기서 확실히 정한다)

# 3a. 표준 구성: TPM만(무인 재부팅이 필요한 단말은 이쪽)
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

# 3b. TPM+PIN 구성(고정 배치되는 고보안 단말용). 3a 대신 실행한다.
#     PIN은 단말마다 다른 값을 그 자리에서 입력한다. 스크립트에 평문으로 넣으면
#     모든 단말이 같은 PIN이 되는 데다 스크립트 자체가 유출 지점이 된다
$Pin = Read-Host -AsSecureString -Prompt "이 단말의 PIN"
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $Pin -TPMandPinProtector

‘복구 암호를 맡긴 뒤에 암호화를 시작한다’는 이 순서가 중요합니다. 반대로 Enable-BitLocker -TpmProtector부터 시작하면 처리가 도중에 멈춘 시점에 복구 수단의 사본이 없는 채로 TPM 보호만 적용된 PC가 남아, 다음 펌웨어 업데이트나 하드웨어 변경에서 데이터째로 잃을 수 있습니다. 위의 순서라면 도중에 멈춰도 암호화는 아직 시작되지 않았으므로 다시 하기만 하면 됩니다. 조직 배포에서는 5.1의 ‘복구 정보가 저장될 때까지 BitLocker를 사용하지 않음’ 정책을 먼저 적용해 두면, 이런 어중간한 상태를 정책 쪽에서도 막을 수 있습니다. ‘백업 성공 확인보다 먼저 암호화를 시작하지 않는다’가 조직 배포의 철칙입니다.

6. 사고 대응 ── ‘복구 키를 요구받았다’, ‘찾을 수 없다’는 상황

6.1. 복구 화면이 뜨면 먼저 키 ID의 앞 8자리

파란 복구 화면에는 복구 키 ID가 표시됩니다. 사본이 여러 개 있는 경우에도 ID의 앞 8자리를 대조하면 올바른 키를 특정할 수 있습니다.⁶ 찾을 곳은 4장의 표와 같으며, 순서대로 확인합니다.

1. 조직의 저장 위치(Entra ID 관리 센터/Intune, 또는 AD DS) ── 관리자·헬프데스크 경유
2. 사용자 본인의 계정 ── 직장 계정이라면 aka.ms/aadrecoverykey, 개인 Microsoft 계정이라면 aka.ms/myrecoverykey⁶
3. 활성화 시의 사본 ── 인쇄한 종이, USB 메모리 안의 파일, 저장한 텍스트 파일⁶

flowchart TB
    REC["파란 복구 화면<br/>복구 키 ID가 표시됨"] --> ID["키 ID의 앞 8자리를 적어 둔다"]
    ID --> ORG["1. 조직의 저장 위치<br/>Entra ID 관리 센터·Intune / AD DS"]
    ORG -- "ID가 일치하는 키 있음" --> INPUT["48자리를 입력해 부팅"]
    ORG -- "찾을 수 없음" --> SELF["2. 사용자 본인의 계정<br/>aka.ms/aadrecoverykey / aka.ms/myrecoverykey"]
    SELF -- "일치하는 키 있음" --> INPUT
    SELF -- "찾을 수 없음" --> PAPER["3. 활성화 시의 사본<br/>인쇄한 종이·USB 메모리·파일"]
    PAPER -- "일치하는 키 있음" --> INPUT
    PAPER -- "찾을 수 없음" --> LOST["초기화 외에는 방법 없음, 전체 데이터 소실<br/>Microsoft도 꺼낼 수 없음"]
    INPUT --> AFTER["원인을 확인하고, 사용한 복구 키는<br/>무효화 후 재발급 - 6.3절"]

아울러 ‘왜 복구 모드에 진입했는지’에 대한 원인 확인을 습관화하십시오. 전날 BIOS를 업데이트했다, Secure Boot 설정을 건드렸다 같은 짚이는 데가 있다면 설계대로의 동작입니다. 짚이는 데가 없는데도 반복해서 발생한다면, 하드웨어 이상이나 물리적 접근에 의한 변조 가능성까지 포함해 조사해 볼 가치가 있습니다.³

6.2. 아무리 해도 찾을 수 없는 경우

냉정한 이야기지만, 복구 키를 찾을 수 없다면 그 암호화된 드라이브의 데이터를 꺼낼 방법은 없습니다. 조직에서 관리하는 PC라면 IT 부서 확인이 마지막 보루이며, 그마저도 안 된다면 디바이스 초기화(전체 데이터 소실)밖에 방법이 없습니다. Microsoft 지원팀은 분실한 복구 키를 제공하거나 다시 만들 수 없습니다.⁶

이를 ‘암호화 때문에 데이터가 사라졌다’고 받아들이는 것은 인과가 거꾸로입니다. 복구 키 관리를 체계화하지 않았던 것이 원인이며, 같은 관리 미비는 도난 시에는 정보 유출로 드러났을 것입니다.

6.3. 사용한 복구 키는 일회용으로 취급한다 ── 수리·분실·퇴직 시의 운영

• 수리를 맡길 때: 수리 업체에 복구 키를 건넸다면(또는 건넸을 가능성이 있다면), 돌아온 뒤에 먼저 새 복구 암호를 추가해 Entra ID / AD DS로의 백업 성공을 확인하고, 그런 다음 건넸던 복구 암호를 삭제합니다. 먼저 삭제하면 추가나 백업이 실패한 시점에 그 드라이브는 복구 수단이 없는 상태가 되므로 순서가 중요합니다. Microsoft도 사용 후의 복구 암호 무효화를 권장하고 있으며, 추가→백업→삭제의 일련의 과정은 명령으로 완결됩니다.⁵ Entra ID 참가 디바이스에서는 사용된 복구 암호를 자동으로 교체(로테이션)하는 정책도 있습니다. 기본값은 Entra ID 참가 디바이스에서 활성화되어 있지만, 복구 정보 백업을 필수로 하는 정책(5.1)이 구성되어 있을 때만 작동합니다. 자동 교체를 믿기 전에, 이 전제 구성과 실제로 키가 바뀌는지를 확인하십시오.⁴
• PC를 분실했을 때: 보호가 활성화되어 있었는지(TPM 보호기 생성 완료·클리어 키 제거 완료) 4장의 명령 출력 기록이나 관리 도구로 확인하고, 암호화되어 있었다면 ‘디스크상의 데이터는 읽을 수 없다’고 설명할 수 있는 상태가 됩니다. 이것이 평상시에 전수 조사를 해 두어야 하는 가장 큰 이유입니다.
• 퇴직·PC 반납 시: 반납된 PC의 복구 키가 퇴직자 개인의 Microsoft 계정에만 있는 상태를 만들지 않는 것이 우선입니다. 조직의 저장 위치로의 집약(4장)이 되어 있다면, 반납 시 작업은 재키팅과 복구 암호 재발급만으로 끝납니다.

예를 들어 수리 사례를 흐름으로 나타내면 다음과 같습니다.

flowchart LR
    S["수리에 맡긴다<br/>복구 키를 건넸을 가능성"] --> B["PC가 돌아온다"]
    B --> N["새 복구 암호를 추가한다"]
    N --> BK["Entra ID / AD DS로의<br/>백업 성공을 확인한다"]
    BK --> D["건넨 복구 암호를<br/>무효화·삭제한다"]
    D --> OK["대장을 업데이트하고 완료한다"]

7. 폐기와의 관계 ── 암호화된 디스크는 폐기가 쉬워진다

BitLocker의 효능은 사용 중일 때만 있는 것이 아닙니다. 드라이브가 처음부터 암호화되어 있으면, 폐기 시 디스크에 남는 것은 암호문뿐입니다. BitLocker는 애초에 분실·도난뿐 아니라 ‘부적절하게 폐기된 디바이스’로부터의 데이터 유출을 막는 기능으로 설계되어 있으며, 보호된 디바이스를 폐기·재활용할 때 데이터를 읽을 수 없게 만드는 것도 목적에 포함됩니다.¹

다만 암호화되어 있다고 해서 폐기 시의 삭제 절차(초기화·전용 삭제 도구·물리적 파괴)를 생략해도 되는 것은 아닙니다. 암호화는 ‘삭제 전·삭제 불가능할 때 디스크에서 평문이 읽힐 위험을 낮추는’ 보험이지, 검증 가능한 삭제를 대체하는 것이 아니기 때문입니다. 그 위에, 암호화를 운용하는 조직에는 고유한 작업이 하나 더 추가됩니다 ── 복구 키 사본(종이·파일·AD나 Entra ID상의 등록)의 정리입니다. 디스크를 삭제하더라도 사본으로 남은 복구 키가 있다면 대장상의 폐기는 완료되지 않은 것입니다. 오래된 키의 삭제까지 포함해 폐기 절차의 일부로 삼으십시오.

다만 PC 폐기에는 암호화 이외의 논점 ── 계정과 라이선스 해제, 자산 대장, 증적 ── 도 있습니다. 전체 절차는 ‘Windows PC를 폐기하기 전에 해둘 것‘에 체크리스트로 정리되어 있으므로, 암호화를 전제로 한 폐기 흐름 정비에는 그쪽도 함께 활용하십시오.

8. 업무 앱 개발자의 관점 ── 성능·장치 PC·클론 배포

마지막으로 업무 앱이나 장치 제어 PC를 맡는 입장에서의 주의점입니다.

• 성능 영향은 ‘먼저 기본값인 128비트로 실측’이 기본입니다. Microsoft 스스로 키 길이의 선택 기준을 ‘디바이스의 성능에 따라’라고 하며, 성능이 높은 드라이브·CPU라면 256비트, 그렇지 않다면 128비트로 제시하고 있습니다.⁴ 뒤집어 말하면, 현대의 PC에서 기본값인 XTS-AES 128이 업무 앱의 체감 성능을 좌우하는 경우는 드물며, 당사에서도 파일 I/O가 특별히 무거운 앱을 제외하면 문제가 된 경험은 거의 없습니다. 의심스럽다면 실제 운영에 준하는 데이터양으로 암호화 전후의 I/O를 실측한 뒤 판단해야 하며, 감으로 ‘느려질 것 같으니 끈다’는 것은 본말이 전도된 판단입니다.
• 암호화는 앱 입장에서 투명합니다. BitLocker는 볼륨 전체 암호화이며 파일 API의 동작은 바뀌지 않습니다. 반대로 말하면, 실행 중인 머신상에서 앱이 다루는 비밀 정보(연결 문자열·API 키)는 BitLocker로 지킬 수 없습니다. 로그온된 머신에서는 드라이브가 복호화된 상태로 보이기 때문입니다. 이때는 DPAPI 등이 나설 차례입니다(‘Windows 앱의 비밀 정보는 어디에 저장해야 할까’).
• 장치 PC·키오스크 PC는 ‘무인 재부팅이 가능한가’로 구성을 정합니다. TPM만 사용하는 구성이라면 전원 차단에서의 복구도 무인으로 이루어지지만, TPM+PIN이나 시작 키는 부팅할 때마다 사람 손이 필요해 무인 운전 장치에는 맞지 않습니다. 한편 TPM만 사용하는 구성은 3장의 트리거(펌웨어 업데이트 등)로 복구 화면에 멈춰 있게 될 위험을 안고 있으므로, 현장에서 떨어진 곳(잠금 보관+대장)에 복구 키를 두고, 장치의 유지보수 절차서에 ‘작업 전 Suspend-BitLocker’를 명기하는 것이 운영의 핵심이 됩니다. 무인 단말을 잠그는 방법 전반은 ‘키오스크 모드로 업무 단말을 잠그기‘에서 다루고 있습니다. 또한 24H2의 자동 디바이스 암호화 요구 사항 완화는 Windows IoT 에디션에는 적용되지 않지만², 이것이 ‘IoT라면 자동 암호화가 일어나지 않는다’는 의미는 아닙니다. 완화 이전부터의 요구 사항(HSTI/Modern Standby 등)을 충족하는 기종에서는 종전대로 자동 암호화가 일어날 수 있으므로, 장치 PC에서도 manage-bde -status를 이용한 상태 확인을 키팅 절차에 넣어 두는 것이 확실합니다.
• 클론 배포에서는 ‘암호화한 뒤 이미지화’를 하지 않습니다. 복구 암호는 생성한 디바이스에 고유한 것입니다.³ 보호가 활성화된 상태의 마스터 이미지를 복제하는 구성은 취하지 않고, 배포 후 PC별로 활성화(또는 OOBE에서의 자동 암호화)→복구 키 백업이라는 순서로 진행합니다. 키팅을 스크립트화하고 있다면(‘winget + PowerShell로 PC 키팅을 자동화하기’), 5.4절의 활성화와 백업 확인을 마지막 공정에 추가하기만 하면 됩니다.

9. 정리

• Windows 11 24H2 이후의 클린 설치에서는 TPM+UEFI Secure Boot를 충족하는 PC에서 디바이스 암호화가 기본으로 초기화됩니다. HSTI/Modern Standby와 DMA 요구 사항은 철폐되어, 대상이 평범한 데스크톱 PC까지 확대되었습니다.
• ‘멋대로 암호화되었다’에 대한 올바른 대응은 비활성화가 아니라 복구 키의 소재 확인입니다. 끄면 분실·도난·폐기 시의 보호를 잃으며, 한 번 끄면 자동으로는 다시 활성화되지 않습니다.
• 복구 키의 저장 위치는 Entra ID / AD DS / Microsoft 계정 / 인쇄·파일의 4가지 중 하나이며, 로그인 방식으로 거의 정해집니다. 조직의 저장 위치를 하나 정하고, 모든 PC가 그곳에 저장되어 있는지 전수 조사하십시오.
• 확인은 manage-bde -protectors -get C: 또는 (Get-BitLockerVolume -MountPoint C).KeyProtector, 뒤늦은 백업은 BackupToAAD-BitLockerKeyProtector / Backup-BitLockerKeyProtector로 완결됩니다.
• 복구 키는 펌웨어 업데이트·Secure Boot 설정 변경·하드웨어 교체 등으로 정당한 소유자에게도 요구됩니다. 계획된 작업 전의 Suspend-BitLocker를 절차서에 넣어 두십시오.
• 기본 방식은 XTS-AES 128이며, 나중에 바꾸려면 복호화→재암호화가 필요합니다. 새 드라이브라면 사용한 공간만 암호화로 충분합니다.
• 사용한 복구 키는 무효화하고 재발급한다, 퇴직자의 계정에 키를 남기지 않는다, 폐기 시에는 키의 사본까지 폐기한다 ── 복구 키는 ‘발급하면 끝’이 아니라 생애 주기로 관리하는 것입니다.
• 암호화는 폐기 시의 보험도 되지만, 삭제 절차(초기화·삭제 도구·물리적 파괴)를 대체하지는 않습니다. BitLocker를 끄는 것이 아니라 복구 키 관리와 함께 제대로 활용하는 것이 중소기업에게 현실적인 해법입니다.

관련 글

• Windows의 TPM이란 무엇인가 ── 그림으로 이해하는 ‘키를 밖으로 내보내지 않는 금고’와 측정 부팅
• Windows PC를 폐기하기 전에 해둘 것 ── 데이터 삭제·계정 해제·백업 실무 체크리스트
• Windows 10 지원 종료 이후의 현실적 해법 ── ESU·LTSC·교체 판단표
• 중소기업의 보안 대책, 무엇부터 시작할까 ── IPA 「중소기업의 정보보안 대책 가이드라인」제4.0판 활용법
• 키오스크 모드로 업무 단말을 지키다 ── Assigned Access・Shell Launcher 선택법과 운영 설계
• winget + PowerShell로 PC 키팅을 자동화하기 ── 절차서를 실행 가능하게 만들기
• Windows 앱에서 설정 파일에 기밀 정보를 평문으로 저장하지 않기 위한 베스트 프랙티스

관련 상담 영역

합동회사 코무라소프트에서는 업무 앱·장치 PC를 포함한 Windows 환경의 암호화 운영 설계(복구 키 저장 위치 설계, 키팅에의 통합, 장치 PC에서의 BitLocker 구성)와, 암호화 환경에서의 업무 앱 성능 검증·문제 조사 상담을 다루고 있습니다. ‘장치 PC를 암호화해도 괜찮은가’를 확인하는 것부터 시작하셔도 괜찮습니다.

• 기술 상담·설계 리뷰
• Windows 앱 개발
• 결함 조사·원인 분석
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

어느새 '디바이스 암호화'가 활성화되어 있었습니다. 비활성화해도 될까요?

비활성화는 권장하지 않습니다. Windows 11 버전 24H2 이후의 클린 설치에서는 TPM과 Secure Boot 등의 조건을 충족하는 PC에서 디바이스 암호화가 기본으로 초기화되기 때문에 '멋대로 켜진' 것처럼 보입니다. 이는 분실·도난 시 데이터를 지키는 구조로, 끄면 보호를 잃는 데다 한 번 끄면 자동으로는 다시 활성화되지 않습니다. 해야 할 일은 비활성화가 아니라 manage-bde -protectors -get C: 등으로 복구 키를 확인하고, Microsoft 계정·Entra ID·AD 등 조직에서 정한 곳에 저장되어 있는 상태로 만드는 것입니다.

BitLocker 복구 키는 어디에 있나요?

저장 위치는 PC의 로그인 방식에 따라 정해집니다. 개인 Microsoft 계정으로 설정한 PC라면 https://aka.ms/myrecoverykey 에 같은 계정으로 로그인하면 목록을 확인할 수 있습니다. 회사의 Entra ID(직장 계정) 참가 PC는 https://aka.ms/aadrecoverykey 의 'BitLocker 키 표시'에서 확인할 수 있습니다. 온프레미스 AD 도메인 참가 PC는 정책이 구성되어 있다면 컴퓨터 개체 하위에서 관리자가 꺼낼 수 있습니다. 그 밖에 인쇄한 종이나 USB 메모리·파일 사본으로 보관되어 있을 수도 있습니다. 복구 화면의 복구 키 ID 앞 8자리를 대조하면 올바른 키를 특정할 수 있습니다.

Windows 11 Home PC에서도 BitLocker를 사용할 수 있나요?

에디션마다 사용할 수 있는 기능이 다릅니다. PIN 추가나 정책 관리를 포함한 전체 기능의 BitLocker를 활성화할 수 있는 것은 Pro/Enterprise/Education 계열이며, Home에서는 사용할 수 없습니다. 반면 간이판인 디바이스 암호화는 Home을 포함한 모든 에디션에서 이용할 수 있으며, TPM과 UEFI Secure Boot 등의 요구 사항을 충족하면 자동으로 활성화됩니다. 다만 보호를 활성화하려면 관리자 권한의 Microsoft 계정으로 로그인해야 하며, 로컬 계정만으로는 보호되지 않습니다. 회사 PC로 관리한다면 Pro를 전제로 Entra ID나 AD에서 복구 키를 중앙 관리하는 구성을 권장합니다.

BIOS(UEFI 펌웨어)를 업데이트했더니 복구 키를 요구받았습니다. 왜 그런가요?

BitLocker는 TPM을 사용해 부팅 환경이 변조되지 않았는지 검증하고 있으며, 펌웨어 업데이트·Secure Boot 설정 변경·TPM 초기화·메인보드 교체 등으로 부팅 시 측정값이 바뀌면 '평소와 다른 환경'으로 판단해 복구 모드로 진입합니다. 이는 고장이 아니라 설계대로의 동작입니다. 계획된 업데이트 작업 전에는 Suspend-BitLocker(또는 manage-bde -protectors -disable C:)로 보호를 일시 중지한 뒤 진행하면 복구 키 입력 없이 작업할 수 있습니다. 일시 중지 중에도 드라이브는 암호화된 상태를 유지하며, 기본적으로 다음 재부팅 시 보호가 자동으로 재개됩니다.

복구 키를 찾을 수 없는 경우, 데이터를 꺼낼 수 있나요?

올바른 복구 키(48자리 복구 암호)나 다른 해제 수단이 없는 한, 암호화된 드라이브의 데이터를 꺼낼 방법은 없습니다. Microsoft 지원팀도 분실한 복구 키를 재발급하거나 꺼낼 수 없다고 명확히 밝히고 있습니다. 조직에서 관리하는 PC라면 먼저 IT 부서에 확인하고, 개인 PC라면 Microsoft 계정의 복구 키 페이지, 인쇄한 사본, USB 메모리 안의 .bek/.txt 파일을 찾아보십시오. 그래도 찾을 수 없다면 PC 초기화(재설치)밖에 방법이 없으며, 데이터는 사라집니다. 그렇기 때문에 암호화를 끌지 말지를 논의하기 전에, 모든 PC의 복구 키가 조직의 관리 아래 있는지를 먼저 확인해야 합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.