며칠 전, 고장 난 노트북과 여덟 개의 운영체제(Windows와 Linux)가 공존하는 멀티부팅 환경에서 KDE neon 인스턴스를 복구한 이야기를 다룬 적이 있습니다. 당시 여러 배포판이 부팅되지 않은 원인은, 존재하지 않는 파티션을 마운트하도록 설정되어 있었기 때문이었습니다. 새로운 리눅스 시스템들이 단순한 숫자 대신 사람이 읽을 수 없는 의미 없는 UUID 문자열로 장치를 표시하는 최적화되지 않은 방식을 사용하기 때문에 발생한 문제였죠.
이번에는 Windows 10 인스턴스도 손볼 차례입니다. 여기서의 문제도 비슷했습니다. Windows 10이 부팅을 시작하다가 'PC 진단 중', '자동 복구' 메시지를 보여주더니, 예상대로 자동 복구는 실패하고 말았습니다. 지난 글에서 Windows 10 파티션이 건강하고 모든 데이터가 그대로 있다는 것을 확인했기 때문에 초기화 같은 극단적인 조치는 피하고 싶었습니다. 이 번거로운 문제를 어떻게 우아하게 해결했는지 소개하겠습니다.
문제 상세 분석
창백한 파란색의 Windows 10 복구 콘솔 화면에는 다음과 같은 메시지가 떠 있었습니다.
자동 복구로 PC를 복구할 수 없습니다.
'고급 옵션'을 눌러 다른 복구 옵션을 시도하거나 '시스템 종료'를 눌러 PC를 끄십시오.
로그 파일: C:\Recovery\WindowsRE\Winre.wim\System32\Logfiles\Srt\SrtTrail.txt
기술적으로 접근하는 사람답게, 가장 좋은 방법은 고급 옵션으로 들어가 명령 프롬프트를 실행한 뒤 로그 파일로 이동해 내용을 확인하는 것이라 판단했습니다. 그런데 이 파일이 존재하지 않았습니다. 이 부분은 곧 살펴보겠습니다.
이 시점에서 최근에 진행했던 시스템 이미지 복구 테스트가 문제의 원인일 수 있다고 생각했습니다. 그래서 Windows 10 부트로더를 수정해야 할지도 모른다고 짐작했습니다. 사실 리눅스 부트로더로 부팅 순서를 제어하고 있어서 의심스러웠지만, 명확한 원인부터 제거하기 위해 간단한 부트로더 수정을 시도해 보기로 했습니다.
bootrec.exe /rebuildbcd
bootrec.exe /fixmbr
bootrec.exe /fixboot
그런데 바로 문제에 부딪혔습니다. Windows 10 USB 드라이브에서 이 명령을 실행하면 아무것도 찾지 못했습니다. 역시 여기에도 이유가 있는데, 곧 설명드리겠습니다. 반면 복구 콘솔에서 실행하면 하나는 찾았지만, C:\ 드라이브가 아닌 D:\ 드라이브를 참조했고, 실제로 항목을 추가하려고 하면 작업을 완료할 수 없다는 오류가 발생했습니다.
지정된 경로를 찾을 수 없습니다.
마지막 명령은 다음과 같은 오류를 냈습니다.
액세스가 거부되었습니다.
로그 파일이 C:\ 아래에 있어야 하는데 없었고, bootrec.exe가 D:\ 아래에서 운영체제를 찾았다는 사실로 미루어, 드라이브 문자가 올바르게 할당되지 않았을 가능성이 크다고 판단했습니다. 이를 수정해야 했죠. 그럼 해결책으로 넘어가겠습니다.
해결 방법 1: 드라이브 문자 정비
cmd에서 diskpart 도구를 실행했습니다. 평소 Windows에서 사용하는 디스크 관리 도구는 GUI 기반이지만, 여기서는 명령줄 방식을 사용해야 합니다. 어떻게 해야 할지 모르겠다면 '?'를 입력해 다양한 옵션과 플래그를 확인할 수 있습니다. 먼저 볼륨 문자를 확인해 보겠습니다.
diskpart
list volumes
제 경우에는 C:\ 드라이브가 잘못 할당되어 있는 것을 발견했습니다. 그래서 이를 변경했습니다. 만약 C: 문자가 이미 사용 중이라면 두 단계가 필요합니다. 먼저 해당 드라이브를 비어 있는 다른 문자로 할당한 후, 올바른 드라이브에 C:를 지정하는 것입니다. 예를 들면 다음과 같습니다(실제 숫자는 시스템 구성에 따라 다르므로 무시하세요).
select volume 2
assign letter=(C가 아닌 다른 문자):
select volume 5
assign letter=C:
다시 bootrec.exe를 실행했고, 진전이 있었지만 여전히 시스템은 부팅되지 않았습니다.
해결 방법 2: EFI 부팅 이미지 재구축
이 시점에서 문제는 부트로더가 아니라고 확신했습니다. 이제 부팅 프로세스의 다음 단계로 넘어갈 차례입니다. 바로 EFI 파티션에 위치한 부팅 이미지입니다. 어떤 이유로든 이 파일이 손상되었고 재구축이 필요했던 것입니다.
복구 콘솔로 부팅한 뒤 diskpart 작업을 다시 수행했습니다. 이번에는 두 단계가 필요했습니다. 첫째, 올바른 볼륨이 C:\에 매핑되도록 하는 것. 둘째, EFI 파티션을 대상으로 작업하고 있는지 확인하는 것입니다. 드라이브 문자에 특히 주의하세요. 실수가 걱정된다면 해당 볼륨을 선택해 새 문자를 할당한 후 부팅 이미지 재구축을 진행하면 됩니다. 문자가 이미 올바르다면 이 단계는 생략해도 됩니다.
diskpart
list volumes
# C:에 해당하는 파티션 선택
select volume X
assign letter=C:
# EFI 파티션 선택(FAT32, 부팅 플래그가 있으며 흔히 숨겨져 있음)
select volume Y
assign letter=F:
exit
EFI에는 F 문자를 사용했습니다. 원하는 문자를 자유롭게 선택하면 됩니다. 이제 부팅 이미지 복구 단계입니다.
bcdboot.exe C:\Windows /s F: /f UEFI
여기서 무슨 일이 일어나는 걸까요? bcdboot는 다음과 같은 방식으로 동작합니다.
- 소스 - C:\Windows의 BCD 파일을 사용해 시스템 파티션을 초기화합니다.
- /s - 시스템(EFI) 파티션의 드라이브 문자를 지정합니다.
- /f - 펌웨어 유형을 지정합니다.
/s와 /f는 모두 선택 사항입니다. 자세한 내용은 Microsoft의 기술 참조 문서를 확인하세요.
이 단계가 완료된 후 재부팅하자 Windows 10이 정상적으로 실행되었고, 모든 데이터가 그대로 유지되었습니다. 다른 리눅스 배포판들도 모두 정상 작동했고, GRUB2는 손대지 않았으며, 데이터 손실도 전혀 없었습니다.
결론
이 과정은 꽤 답답했지만 동시에 즐겁기도 했습니다. 깊은 기술적 영역에서는 Windows가 Linux와 상당히 비슷하게 동작합니다. 그리고 시스템 부팅 오류에 관해서는 마찬가지로 모호하고 유연하지 못합니다. 왜 자동 복구가 제가 한 작업을 스스로 처리하지 못했는지 의문입니다. 제가 거친 단계들에는 특별하거나 마법적인 것이 전혀 없었습니다. 또한 로그에 쉽게 접근할 수 없다는 점도 아쉽습니다. 첫 오류 화면에서 바로 로그를 읽을 수 있게 해주면 안 될까요?
또 하나의 문제는, 시스템이 기대하는 상태와 실제 사이에 불일치가 있을 때(예: 드라이브 문자), 불필요한 다른 문제들이 우후죽순 나타나 주의를 산만하게 한다는 점입니다. 해결책 자체는 어렵지 않지만, 엉뚱한 것들을 추적하느라 시간을 낭비하게 됩니다. 요즘 소프트웨어라는 게 그렇죠. 멀티부팅 환경에서 Windows 10 시작에 문제가 있을 때 무엇을 할 수 있는지 조금이나마 명확히 설명되었기를 바랍니다. 데이터가 온전하다면 간단한 것부터 시작해 부팅 순서를 따라 한 단계씩 진행하세요. 철학적으로는 Linux와 같습니다. 미래가 밝지 않으니, 모든 것이 추상적인 악몽이 되기 전에 남아 있는 기술적 자유를 즐기시길 바랍니다.
그럼, 즐거운 컴퓨팅 되세요!