WSL2와 듀얼 부팅 중 뭐가 더 안전한가요?

WSL2가 압도적으로 안전합니다. 기존 파티션이나 부트로더를 전혀 건드리지 않고 윈도우 안의 애플리케이션처럼 설치·제거되기 때문입니다. 반면 듀얼 부팅은 EFI 시스템 파티션과 부트 매니저를 건드리므로 절차를 따르지 않으면 윈도우 부팅 자체가 실패할 수 있습니다. GPU 연산이나 실시간 하드웨어 제어처럼 WSL2로 안 되는 작업이 아니라면 WSL2부터 시작하는 것이 맞습니다.

듀얼 부팅을 해도 정말 기존 윈도우에 전혀 영향이 없나요?

설치 방식에 따라 다릅니다. 우분투 전용 물리 SSD를 따로 쓰거나 설치 중 윈도우 디스크를 물리적으로 분리하면 사실상 영향이 없습니다. 반면 같은 디스크의 빈 공간에 파티션을 나눠 설치하면 EFI 시스템 파티션을 공유하고 부트 매니저에 우분투 항목이 추가되므로, 절차를 잘못 따르면 윈도우 부팅에 영향을 줄 수 있는 여지가 생깁니다. 안전도는 "별도 디스크 > 외장 SSD > 같은 디스크 파티션 분할" 순입니다.

WSL2로는 어떤 작업을 못 하나요?

커널 모듈을 직접 빌드하고 로드해야 하는 작업(커스텀 드라이버 개발), 실시간성이 중요한 하드웨어 제어(로봇 제어 보드, 산업용 통신), USB 장치 중 일부(특정 시리얼-USB 브리지, 일부 카메라)의 저수준 접근, systemd 서비스를 다수 운용하는 환경 등은 WSL2에서 제약이 있거나 추가 설정이 까다롭습니다. 이런 경우 듀얼 부팅이나 네이티브 리눅스 머신이 더 안정적입니다.

우분투 설치 전에 반드시 확인해야 할 하드웨어는 무엇인가요?

CPU 가상화 지원 여부(VT-x/AMD-V, WSL2 필수), UEFI 모드와 Secure Boot 상태, 디스크 파티션 방식(GPT), 그리고 NVIDIA GPU가 있다면 Secure Boot와의 충돌 가능성입니다. 특히 일부 노트북은 BIOS에서 인텔 RST(RAID) 모드가 기본으로 켜져 있어 우분투 설치 프로그램이 NVMe SSD를 아예 인식하지 못하는 경우가 있으므로 미리 확인해야 합니다.

듀얼 부팅에서 우분투를 나중에 지우고 윈도우만 남기려면 어떻게 하나요?

순서가 중요합니다. 먼저 윈도우의 디스크 관리에서 우분투가 쓰던 파티션을 삭제하고 그 공간을 기존 볼륨에 병합한 뒤, EFI 부트 메뉴에서 우분투 부트 항목을 제거해야 합니다. 반대 순서로 하면 부팅 항목은 남아 있는데 실제 파티션이 없어 부팅 메뉴에서 오류가 나는 상태가 될 수 있습니다. bcdedit이나 efibootmgr로 항목을 정리하는 방법은 본문에서 다룹니다.

WSL2와 듀얼 부팅 중 무엇을 고를까: 윈도우를 건드리지 않고 우분투 설치하기와 하드웨어 사양 점검

작성 0xmote · 2026년 9월 24일 · 23분 읽기 · 수정 2026년 9월 24일 중급 가이드

이 글의 핵심

윈도우에서 개발하다가 우분투 환경이 필요해진 개발자를 위해 WSL2와 듀얼 부팅을 GPU·USB 장치·성능·안정성 기준으로 비교하고, 기존 윈도우 파티션을 건드리지 않는 안전한 설치 방법과 실제 개발에 필요한 하드웨어 사양, 설치 전 체크리스트, 자주 겪는 부팅 문제 해결법까지 실전 관점에서 정리합니다.

들어가며

윈도우에서 주로 개발하던 사람이 어느 시점부터 우분투 환경을 필요로 하게 되는 경우는 생각보다 흔합니다. 배포 대상 서버가 리눅스라서 로컬에서 같은 환경을 재현하고 싶거나, ROS2처럼 리눅스 우선으로 설계된 도구를 써야 하거나, 팀의 CI 파이프라인이 우분투 컨테이너 기반이라 로컬 디버깅도 같은 조건에서 하고 싶은 경우입니다. 이때 가장 먼저 부딪히는 질문은 “WSL2로 충분한가, 아니면 진짜 우분투를 따로 설치해야 하는가”입니다.

이 질문에 대한 답은 “둘 다 써봐야 안다”가 아니라 실제로는 몇 가지 명확한 기준으로 갈립니다. GPU 연산을 하는지, USB로 붙는 하드웨어를 다루는지, 커널 모듈을 직접 만지는지에 따라 답이 거의 정해집니다. 이 글은 그 판단 기준을 먼저 정리하고, 듀얼 부팅을 선택했을 때 기존 윈도우 환경에 손상을 주지 않는 구체적인 설치 절차와, 설치 전에 확인해야 할 하드웨어 사양을 다룹니다. 대상 배포판은 Ubuntu 24.04 LTS, 윈도우 쪽은 Windows 11을 기준으로 합니다.

이 글은 우분투 데스크톱 조작법 자체(클립보드, 단축키, 터미널 습관)는 다루지 않습니다. 그 내용은 윈도우 개발자를 위한 우분투 데스크톱 적응 가이드에서 별도로 정리했고, 설치가 끝난 뒤의 실전 명령어와 개발 환경 세팅은 우분투 서버 명령어 가이드와 씽크패드 우분투 개발 환경 가이드를 참고하시기 바랍니다. 이 글은 그 이전 단계, 즉 “어떤 방식으로 설치할지 결정하고 실제로 안전하게 설치하는 것”에만 집중합니다.

1. WSL2 vs 듀얼 부팅 vs 그 외: 무엇을 기준으로 고를까

가장 많이 하는 실수는 “듀얼 부팅이 더 진짜 리눅스니까 더 낫다”는 식으로 접근하는 것입니다. 실제로는 정반대인 경우가 많습니다. WSL2는 리눅스 커널을 경량 VM 위에서 그대로 돌리는 방식이라, 대부분의 개발 작업(웹 백엔드, 컨테이너 빌드, 스크립트, 대부분의 CLI 툴체인)에서는 네이티브 우분투와 체감 차이가 거의 없습니다. 반면 듀얼 부팅은 설치와 유지보수 비용이 훨씬 크고, 부팅 전환마다 컨텍스트 스위칭 비용(재부팅, 열려 있던 윈도우 앱 종료)이 발생합니다.

판단 기준표

기준	WSL2	듀얼 부팅
GPU 연산(CUDA, PyTorch/TensorFlow 학습)	지원됨. 윈도우 NVIDIA 드라이버가 WSL2에 GPU를 노출(WSL2용 별도 리눅스 드라이버 설치 불필요)	네이티브 지원, 가장 안정적
GUI 애플리케이션	WSLg로 지원되지만 일부 3D 가속·특수 윈도우 매니저 기능은 제약	완전 지원
USB/시리얼 장치(아두이노, 로봇 컨트롤러 등)	usbipd-win으로 개별 장치를 USB/IP 방식으로 연결 가능하지만 설정이 번거롭고 일부 장치는 호환 문제 발생	네이티브로 즉시 인식
실시간성이 필요한 하드웨어 제어(ROS2 + 실물 로봇 등)	VM 위에서 도는 구조라 지연/타이밍이 불안정할 수 있음	권장. 실제 하드웨어 타이밍 요구가 있는 작업은 듀얼 부팅이 안전
커널 모듈 빌드/로드	WSL2 커널은 마이크로소프트가 관리하며 커스텀 모듈 로드가 까다로움	자유롭게 가능
파일시스템 성능	WSL2 내부 ext4는 빠르지만, 윈도우 쪽 `/mnt/c`를 통한 접근은 9P 프로토콜 오버헤드로 느림	네이티브 ext4, 오버헤드 없음
메모리/CPU 제한	`.wslconfig`로 상한을 걸 수 있고 기본값은 호스트 메모리의 절반 정도를 동적으로 사용	OS 전체 자원을 그대로 사용
Docker	Docker Desktop(WSL2 백엔드) 또는 WSL2 안에 네이티브 docker 설치, 둘 다 가능	네이티브 docker, 오버헤드 최소
전환 비용	윈도우 창 하나처럼 즉시 실행/종료	재부팅 필요(보통 30초~1분)
설치·삭제 안전성	앱 제거 수준으로 완전 원복 가능	파티션/부트로더 작업 필요, 절차 실수 시 위험

표에서 가장 자주 오해되는 항목이 GPU입니다. WSL2는 별도의 리눅스용 NVIDIA 드라이버를 설치하는 게 아니라, 윈도우에 설치된 드라이버가 WSL2 안의 CUDA 런타임에 GPU를 그대로 노출하는 구조입니다. 그래서 nvidia-smi를 WSL2 안에서 실행하면 윈도우 쪽 드라이버 버전이 그대로 보입니다. 딥러닝 실험이나 CUDA 개발이 목적이라면 대부분 WSL2만으로 충분하고, 듀얼 부팅으로 넘어갈 이유가 크지 않습니다.

반대로 USB 장치는 WSL2의 약점입니다. WSL2는 원래 USB 장치에 직접 접근할 방법이 없었는데, 마이크로소프트가 usbipd-win이라는 프로젝트를 통해 USB/IP 프로토콜로 개별 장치를 WSL2 안에 “붙여넣는” 방식을 지원합니다. 다만 이 방식은 장치를 attach할 때마다 관리자 권한의 PowerShell 명령이 필요하고, 일부 장치(특히 벤더 고유 프로토콜을 쓰는 산업용 장비)는 USB/IP 계층을 거치면서 타이밍이 어긋나거나 아예 인식되지 않는 경우가 있습니다. ROS2로 실제 로봇 하드웨어를 다루는 작업이라면 이런 불안정성이 개발 생산성을 크게 깎아먹기 때문에, 저는 하드웨어가 얽힌 프로젝트는 처음부터 듀얼 부팅이나 별도의 리눅스 머신으로 시작하는 쪽을 권합니다.

flowchart TD
    A["우분투가 필요한 이유는?"] --> B{"GPU/CUDA 연산 위주인가?"}
    B -->|"예"| C["WSL2로 충분 (윈도우 드라이버 그대로 사용)"]
    B -->|"아니오"| D{"USB/시리얼 하드웨어를 직접 제어하는가?"}
    D -->|"예, 실시간성 중요"| E["듀얼 부팅 권장"]
    D -->|"아니오 또는 가끔"| F{"커널 모듈을 직접 빌드/로드하는가?"}
    F -->|"예"| E
    F -->|"아니오"| G["WSL2로 시작, 필요해지면 듀얼 부팅 검토"]

이 결정 트리에서 중요한 것은 “듀얼 부팅이 더 우월하다”는 결론이 아니라, 대부분의 웹/백엔드/일반 서버 개발자는 왼쪽 경로(WSL2)로 충분히 끝난다는 점입니다. 실제로 팀 내에서 “우분투가 필요하다”고 말하는 사람 대부분은 정확히는 “bash, apt, systemd, 리눅스 전용 CLI 도구가 필요하다”는 뜻이고, 이건 WSL2가 정확히 제공하는 것입니다. VM(VirtualBox/VMware)이나 외장 SSD 부팅은 이 표의 중간 지점에 있는데, VM은 GPU 패스스루가 까다롭고 USB 문제도 WSL2와 비슷하게 남아있어 특별한 이유가 없다면 WSL2 대비 이점이 적습니다. 외장 SSD 부팅은 뒤에서 별도로 다룹니다.

2. 윈도우에 영향 없이 우분투를 쓰는 방법 (안전한 순서대로)

“기존 윈도우에 영향 없이”라는 요구는 방식에 따라 안전도가 크게 다릅니다. 안전한 순서대로 정리하면 다음과 같습니다.

1) WSL2 — 사실상 위험 없음. 파티션도, 부트로더도 건드리지 않습니다. wsl --uninstall이나 배포판 개별 제거로 완전히 원복됩니다. 대부분의 경우 이것이 정답입니다.

2) 우분투 전용 물리 SSD 추가 — 매우 안전. 노트북에 M.2 슬롯이 비어있거나 데스크톱에 SATA/NVMe 슬롯이 여유가 있다면, 물리적으로 별도의 디스크에 우분투를 설치하는 것이 듀얼 부팅 중 가장 안전한 방법입니다. 설치 중 파티션 선택 화면에서 반드시 우분투용 디스크만 대상으로 지정하고, 가능하다면 설치 시작 전에 윈도우가 설치된 디스크를 BIOS에서 일시적으로 비활성화하거나 물리적으로 분리해두면 설치 프로그램이 실수로 윈도우 디스크를 건드릴 여지 자체가 사라집니다. 설치가 끝난 뒤에는 F12(제조사마다 다름, Boot Menu 키)로 매번 부팅할 디스크를 고르거나, UEFI 펌웨어 설정에서 기본 부팅 순서를 조정합니다. 이 방식은 EFI 시스템 파티션도 디스크별로 따로 생기기 때문에 윈도우의 부트 매니저를 전혀 수정하지 않습니다.

3) 외장 USB SSD 설치 — 안전하지만 성능 트레이드오프. USB 3.x 이상의 외장 SSD(USB 스틱이 아니라 SSD)에 우분투를 설치하면 내장 디스크를 전혀 건드리지 않고, 필요할 때만 꽂아서 부팅할 수 있습니다. 다만 USB 인터페이스를 거치므로 내장 NVMe 대비 디스크 I/O 성능이 떨어지고, 일부 노트북은 외장 부팅을 지원하려면 UEFI 설정에서 “External Device Boot”류 옵션을 켜야 합니다. Docker 빌드나 컴파일이 잦은 작업에는 체감 속도 차이가 있을 수 있습니다.

4) 같은 디스크에 파티션을 나눠 듀얼 부팅 — 가장 흔하지만 위험도가 가장 높음. 우분투 설치 프로그램의 “Ubuntu를 Windows Boot Manager와 함께 설치” 옵션을 쓰면 기존 윈도우 파티션 뒤의 빈 공간에 우분투용 파티션을 만들고, 기존 EFI 시스템 파티션을 그대로 재사용합니다. 즉 윈도우 부트 매니저가 들어있는 파티션에 우분투의 GRUB 부트로더 파일도 같이 설치되는 구조입니다. 이 자체는 정상적인 절차이고 수백만 명이 이렇게 씁니다만, 설치 도중 파티션을 잘못 지정하거나(윈도우 파티션을 실수로 포맷) 디스크 공간을 정확히 확보하지 않으면 복구가 훨씬 번거롭습니다. 이 방식을 쓴다면 반드시 3번 항목의 사전 체크리스트를 전부 따르는 것을 권합니다.

정리하면, “정말로 윈도우에 손도 대고 싶지 않다”는 요구에는 WSL2나 별도 물리 디스크가 정답이고, “굳이 같은 디스크를 나눠 써야 한다”면 그만큼 사전 준비(백업, BitLocker 키, Fast Startup 해제)가 필수적으로 따라와야 합니다.

3. 설치 전 하드웨어 권장 사양

공식 최소 사양

Canonical이 공개하는 Ubuntu Desktop의 공식 최소 사양은 대략 2GHz 듀얼코어 64비트 CPU, 4GB RAM, 25GB 이상의 저장 공간입니다. 다만 이 수치는 “부팅해서 데스크톱이 뜨는” 수준의 최소 기준이지, 실제 개발 환경으로 쓰기에는 턱없이 부족합니다. 공식 최소 사양을 그대로 믿고 저사양 장비에 설치했다가 IDE 하나 켜는 데도 버벅거리는 경우를 자주 봅니다.

실전 개발 환경 권장 사양

RAM: 최소 16GB. VS Code나 JetBrains IDE, 브라우저 여러 탭, Docker 컨테이너 몇 개를 동시에 띄우면 8GB는 스왑이 발생하기 시작합니다. 특히 WSL2는 기본적으로 호스트 RAM의 절반까지 동적으로 점유하므로, 윈도우와 우분투를 동시에 무겁게 쓰는 경우 32GB를 권장합니다.
저장장치: NVMe SSD 필수. SATA SSD도 동작은 하지만 컴파일이 잦은 작업(C++ 빌드, Docker 이미지 빌드)에서 체감 차이가 큽니다. 개발용으로 우분투에 할당할 공간은 최소 100GB 이상을 권장합니다 — OS, 언어별 툴체인, Docker 이미지, 프로젝트 소스가 누적되면 50GB는 금방 찹니다.
CPU: 코어 수보다 가상화 지원 여부가 더 중요합니다(아래 참고). 컴파일이 잦다면 코어 수가 많을수록 유리하지만, 최근 4코어 이상 CPU라면 대부분 문제없습니다.

WSL2를 쓰려면 반드시 필요한 것: CPU 가상화 지원

WSL2는 실제로는 경량화된 Hyper-V VM 위에서 리눅스 커널을 돌리는 구조이기 때문에, CPU의 하드웨어 가상화 기능(인텔 VT-x 또는 AMD-V)이 BIOS/UEFI에서 켜져 있어야 합니다. 최신 CPU는 대부분 기본 활성화되어 있지만, 일부 기업용 노트북은 보안 정책상 BIOS에서 기본으로 꺼두는 경우가 있습니다. 윈도우 작업 관리자의 성능 탭에서 “가상화: 사용” 여부를 바로 확인할 수 있고, 꺼져 있다면 BIOS/UEFI 설정에서 켜야 합니다.

UEFI, GPT, Secure Boot 확인

듀얼 부팅을 하려면 디스크가 GPT(GUID Partition Table) 방식이어야 하고 UEFI 모드로 부팅되고 있어야 합니다. 오래된 MBR/레거시 BIOS 방식 디스크에서는 우분투 설치 프로그램이 파티션을 제대로 다루지 못하거나 부트로더가 꼬일 수 있습니다. 윈도우에서 msinfo32를 실행하면 “BIOS 모드” 항목에서 UEFI/레거시 여부와 보안 부팅(Secure Boot) 상태를 바로 확인할 수 있고, 디스크 관리(diskmgmt.msc)나 PowerShell의 Get-Disk로 파티션 스타일(GPT/MBR)을 확인할 수 있습니다.

# 파티션 스타일(GPT/MBR) 확인
Get-Disk | Select-Object Number, FriendlyName, PartitionStyle

# BitLocker 상태 확인 (다음 섹션에서 다시 다룹니다)
manage-bde -status C:

흔히 걸리는 하드웨어 호환 문제

NVIDIA GPU + Secure Boot: NVIDIA의 독점 드라이버는 서명되지 않은 커널 모듈이기 때문에 Secure Boot가 켜진 상태에서 설치하면 MOK(Machine Owner Key) 등록 과정을 거쳐야 합니다. 재부팅 시 파란 화면의 MOK 관리 화면에서 직접 키를 승인해야 하는데, 이 단계를 모르고 건너뛰면 로그인 후 화면이 검게 나오는 증상으로 이어집니다.
인텔 RST/VMD(RAID) 모드: 일부 최신 노트북은 NVMe SSD를 BIOS에서 RAID(RST/VMD) 모드로 기본 설정해둡니다. 이 상태에서는 우분투 설치 프로그램이 디스크를 아예 인식하지 못합니다. AHCI로 전환하면 해결되지만, 이미 윈도우가 RST 모드로 설치되어 있었다면 AHCI로 바꾸는 순간 윈도우가 INACCESSIBLE_BOOT_DEVICE 블루스크린을 내며 부팅에 실패할 수 있습니다. 전환 전에 윈도우에서 안전 모드 재부팅을 이용해 스토리지 컨트롤러 드라이버를 먼저 전환해두는 절차가 필요하므로, 이 항목은 설치 당일이 아니라 며칠 전에 미리 처리해두는 것을 권합니다.
Wi-Fi 칩셋: 인텔 계열 Wi-Fi는 커널에 드라이버가 기본 내장되어 있어 대체로 문제가 없지만, 일부 리얼텍/브로드컴 칩셋은 설치 직후 Wi-Fi가 잡히지 않거나 별도 드라이버 설치가 필요한 경우가 있습니다. 설치 USB와 별개로 유선 이더넷을 준비해두면 이런 상황에서도 드라이버를 내려받을 수 있습니다.
지문 인식기: 대부분의 노트북 지문 리더는 리눅스에서 기본 지원되지 않습니다. 로그인 방식을 지문에 의존하고 있었다면 비밀번호 로그인으로 전환할 준비가 필요합니다.
하이브리드 그래픽(인텔 내장 + NVIDIA 외장): 최근 NVIDIA Optimus 구성은 nvidia-prime으로 대체로 잘 지원되지만, 설치 직후 기본값은 내장 그래픽을 쓰도록 되어 있는 경우가 많아 외장 GPU 성능이 필요한 작업(CUDA, 3D 렌더링)에서는 별도 전환 설정이 필요합니다.

4. 설치 전 체크리스트 (왜 필요한지 포함)

이 단계를 건너뛰고 바로 설치를 진행했다가 낭패를 보는 경우를 자주 봅니다. 각 항목이 왜 필요한지까지 이해하고 진행하는 것을 권합니다.

1) 중요 데이터 백업. 이후 단계(볼륨 축소, 파티션 생성)는 모두 정상적인 절차를 따르면 안전하지만, 정전이나 디스크 오류처럼 통제 불가능한 변수는 항상 존재합니다. 특히 파티션 작업 중에는 절대 노트북 전원을 뽑거나 배터리가 방전되게 두면 안 됩니다.

2) BitLocker 복구 키 저장. 윈도우 11 Pro/Enterprise에서는 BitLocker가 기본 활성화되어 있는 경우가 많고, Home 에디션에서도 “장치 암호화”라는 이름으로 유사한 기능이 켜져 있을 수 있습니다. UEFI 설정 변경(Secure Boot 토글, 부팅 순서 변경)은 BitLocker가 “부팅 환경이 변조되었을 수 있다”고 판단하는 트리거가 되어, 다음 부팅 때 복구 키 48자리를 입력하라는 화면이 뜰 수 있습니다. 이 키를 모르면 디스크에 있는 모든 데이터에 접근할 수 없게 되므로, 작업 전에 반드시 manage-bde -status C:로 활성화 여부를 확인하고, 마이크로소프트 계정에 연결되어 있다면 aka.ms/myrecoverykey에서 키를 미리 확인해 별도로 적어두어야 합니다.

저는 이 문제를 실제로 겪었습니다. Secure Boot를 잠깐 껐다가 다시 켜는 것뿐이라고 가볍게 생각하고 진행했는데, 다음 부팅에서 파란 화면 가득 “BitLocker 복구”라는 문구와 함께 48자리 키를 요구하는 화면이 떴습니다. 다행히 마이크로소프트 계정에 키가 자동 백업되어 있어 복구는 됐지만, 계정에 로그인할 다른 기기가 없었다면 그 자리에서 발이 묶였을 상황이었습니다. 이후로는 BIOS/UEFI 설정을 하나라도 바꾸기 전에는 반드시 복구 키부터 확인하는 습관이 생겼습니다.

3) 빠른 시작(Fast Startup) 끄기. 윈도우의 빠른 시작은 완전한 종료 대신 커널 세션을 하이버네이션 파일에 저장해 다음 부팅을 빠르게 만드는 기능입니다. 이 상태에서는 NTFS 파티션이 “잠긴” 상태로 남아있어, 우분투에서 같은 파티션에 쓰기 접근을 시도하면 거부되거나 최악의 경우 파일 시스템이 손상될 수 있습니다. 설정 > 전원 옵션 > 전원 단추 작동 설정에서 빠른 시작을 꺼야 합니다.

4) 디스크 관리에서 볼륨 축소. diskmgmt.msc를 열어 C: 드라이브를 우클릭하고 “볼륨 축소”를 실행해 우분투가 쓸 공간을 확보합니다. 이때 요청한 만큼 줄어들지 않고 예상보다 훨씬 작은 값까지만 줄어드는 경우가 흔한데, 이는 페이지 파일, 하이버네이션 파일, 시스템 복원 지점처럼 디스크 중간에 박혀 있어 이동할 수 없는 파일들이 축소 가능한 범위를 제한하기 때문입니다. 이럴 때는 디스크 조각 모음을 먼저 실행하거나, 페이지 파일 크기를 일시적으로 줄이고 재부팅한 뒤 다시 시도하면 더 많은 공간을 확보할 수 있습니다.

5) 설치 USB 준비 및 ISO 검증. Rufus(윈도우)나 balenaEtcher로 USB를 만들 때 반드시 파티션 스킴을 GPT, 대상 시스템을 UEFI로 지정해야 합니다(레거시 BIOS로 만들면 UEFI 시스템에서 부팅이 안 되거나 Secure Boot와 충돌합니다). 또한 다운로드한 ISO 파일은 반드시 SHA256 체크섬을 공식 사이트 값과 대조해 검증하는 것을 권합니다. 손상된 ISO로 설치를 진행하면 설치 도중 알 수 없는 오류로 실패하거나, 더 나쁘게는 설치 후반부까지 진행되다가 실패해 시간을 낭비하게 됩니다.

# 다운로드한 ISO의 SHA256 체크섬 계산 (리눅스/맥)
sha256sum ubuntu-24.04-desktop-amd64.iso

# 윈도우 PowerShell
Get-FileHash .\ubuntu-24.04-desktop-amd64.iso -Algorithm SHA256

5. 듀얼 부팅 설치 단계별 가이드

여기서는 같은 디스크에 파티션을 나눠 설치하는 가장 흔한 시나리오를 기준으로 설명합니다. 앞서 설명한 별도 물리 디스크 방식이라면 파티션 단계가 훨씬 단순해집니다(우분투용 디스크 전체를 그대로 쓰면 됩니다).

1) 부팅 메뉴로 USB 부팅. 노트북 제조사별 부팅 메뉴 키(대개 F12, F2, Esc, Del 중 하나)를 눌러 USB를 선택해 부팅합니다. UEFI 항목과 레거시 항목이 둘 다 보인다면 반드시 “UEFI: [USB 이름]“을 선택해야 합니다.

2) 파티션 방식 선택. 설치 프로그램에서 “Ubuntu를 Windows Boot Manager와 함께 설치”를 선택하면 슬라이더로 공간을 나눠주는 자동 방식이고, “기타(수동 파티션 설정)“를 선택하면 직접 파티션을 구성할 수 있습니다. 자동 방식이 대부분의 경우 충분히 안전하지만, 스왑 파티션 대신 스왑 파일을 쓰고 싶거나 홈 디렉터리를 별도 파티션으로 분리하고 싶다면 수동 설정을 씁니다. 수동 설정 시 기존 EFI 시스템 파티션(보통 100~500MB, fat32, 마운트 지점 /boot/efi)은 삭제하지 말고 그대로 재사용해야 합니다. 새로 만들면 윈도우 부트 항목이 있는 기존 EFI 파티션과 별개로 두 개의 EFI 파티션이 생겨 부팅 순서가 꼬일 수 있습니다.

3) 루트 파티션 구성. 루트(/)는 ext4로 확보한 공간 대부분을 할당하고, 스왑은 최근 Ubuntu 설치 프로그램 기본값대로 파일 방식(스왑 파티션이 아니라 /swapfile)으로 두는 것이 관리하기 편합니다. 스왑 크기는 하이버네이션을 쓰지 않는다면 RAM의 절반 정도, 하이버네이션이 필요하다면 RAM과 같거나 그 이상으로 잡습니다.

4) Secure Boot 관련 옵션. 설치 중 “서드파티 소프트웨어 설치” 체크박스를 켜면 그래픽/Wi-Fi용 독점 드라이버가 함께 설치되는데, 이 드라이버들은 서명이 없으므로 Secure Boot가 켜져 있으면 설치 마지막에 MOK 암호를 설정하라는 화면이 뜹니다. 재부팅 후 파란 화면에서 “Enroll MOK”를 선택하고 설정한 암호를 입력해야 드라이버가 실제로 로드됩니다. 이 화면을 놓치고 그냥 Enter를 눌러 넘어가면 드라이버가 로드되지 않아 이후 NVIDIA 드라이버가 동작하지 않는 원인이 됩니다.

5) 설치 완료 후 GRUB 확인. 정상적으로 설치되면 재부팅 시 GRUB 메뉴가 나타나 우분투와 윈도우를 선택할 수 있습니다. 기본 부팅 항목이나 대기 시간을 조정하려면 /etc/default/grub을 수정합니다.

sudo nano /etc/default/grub

# GRUB_DEFAULT=0 은 메뉴의 첫 번째 항목(보통 우분투)을 기본값으로 부팅
GRUB_DEFAULT=0
# 메뉴 대기 시간(초). 윈도우를 더 자주 쓴다면 늘려서 실수로 우분투가 뜨는 걸 방지
GRUB_TIMEOUT=5
# 최근 GRUB 버전은 os-prober가 기본 비활성화된 경우가 있어, 윈도우 항목이
# 메뉴에 안 보이면 이 값을 false로 명시해 켜야 합니다
GRUB_DISABLE_OS_PROBER=false

# 설정 반영
sudo update-grub

update-grub을 실행하면 os-prober가 디스크를 스캔해 윈도우 부트로더를 찾아 GRUB 메뉴에 자동으로 추가해줍니다. 이 항목이 안 보인다면 GRUB_DISABLE_OS_PROBER 설정을 먼저 의심하는 것이 맞습니다.

6) 시간 차이 문제 해결. 윈도우는 하드웨어 시계(RTC)를 로컬 타임존 기준으로 쓰고, 리눅스는 전통적으로 UTC 기준으로 씁니다. 이 때문에 듀얼 부팅 환경에서는 OS를 바꿀 때마다 시스템 시간이 몇 시간씩 틀어지는 현상이 발생합니다. 해결 방법은 두 가지입니다. 우분투 쪽에서 RTC를 로컬 시간으로 맞추거나, 윈도우 쪽에서 RTC를 UTC로 맞추는 것입니다.

# 우분투에서 RTC를 로컬 타임으로 설정 (윈도우와 맞추는 쪽)
timedatectl set-local-rtc 1 --adjust-system-clock

저는 이 방법보다 윈도우 레지스트리를 수정해 UTC를 쓰도록 맞추는 쪽을 더 권장합니다. timedatectl set-local-rtc 1은 편리하지만 systemd 공식 문서에서도 로컬 RTC는 서머타임 전환이나 다중 OS 환경에서 시간 계산이 꼬일 수 있다고 명시하고 있어, 리눅스 쪽을 표준(UTC)에서 벗어나게 만드는 임시방편에 가깝습니다. 반대로 윈도우 레지스트리를 고치면 윈도우도 표준을 따르게 되므로 장기적으로 더 깔끔합니다.

# 관리자 권한 PowerShell/레지스트리 편집기에서
# HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
# RealTimeIsUniversal (DWORD) 값을 1로 설정

7) 윈도우 파티션(NTFS) 접근. 우분투에서 파일 관리자나 터미널로 윈도우 데이터 파티션에 바로 접근할 수 있습니다. NTFS 드라이버(ntfs-3g)가 기본 포함되어 있어 별도 설치 없이 읽기/쓰기가 가능하지만, C: 드라이브가 빠른 시작이나 하이버네이션으로 잠겨 있으면(4장 참고) 읽기 전용으로만 마운트되니 참고하시기 바랍니다.

8) 나중에 우분투를 제거하고 윈도우만 남기기. 순서를 반드시 지켜야 합니다. 먼저 윈도우 디스크 관리에서 우분투가 쓰던 파티션들(루트, 스왑)을 삭제하고 그 공간을 인접한 윈도우 볼륨에 병합합니다. 그다음 부팅 순서에서 우분투 GRUB 항목을 제거해야 합니다. 파티션만 지우고 부트 항목을 그대로 두면, 다음 부팅 때 GRUB이 이미 사라진 파티션을 찾다가 오류 화면에서 멈추는 상태가 될 수 있습니다.

# 윈도우 부팅 관리자에서 부팅 항목 목록 확인
bcdedit /enum firmware

# ubuntu 항목의 GUID를 확인한 뒤 제거
bcdedit /delete {해당-GUID} /f

또는 우분투가 아직 부팅 가능한 상태라면 우분투 안에서 efibootmgr로 정리할 수도 있습니다.

# 현재 등록된 EFI 부팅 항목 목록
sudo efibootmgr -v

# 특정 항목(Boot0003 등) 제거
sudo efibootmgr -b 0003 -B

6. WSL2 빠른 설정 (비교용)

듀얼 부팅과 대비해서 WSL2가 얼마나 간단한지 보여드리겠습니다. 관리자 권한 PowerShell에서 명령 한 줄이면 끝납니다.

# 기본 배포판으로 설치 (커널, WSL2, Ubuntu를 한 번에)
wsl --install

# 특정 버전을 명시하고 싶다면
wsl --install -d Ubuntu-24.04

메모리나 CPU 사용량을 제한하고 싶다면 사용자 홈 디렉터리에 .wslconfig 파일을 만들어 조정합니다.

# C:\Users\<사용자명>\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=4GB
# 최근 WSL2는 mirrored 네트워킹 모드를 지원해 localhost 공유가 더 자연스러워짐
networkingMode=mirrored

기본 네트워킹 모드는 NAT 방식이라 WSL2 안의 서비스를 윈도우 쪽 localhost로 접근하려면 포트 포워딩이 자동으로 되긴 하지만 종종 예외가 생깁니다. networkingMode=mirrored로 바꾸면 윈도우와 WSL2가 같은 네트워크 인터페이스를 공유하는 것처럼 동작해 이런 문제가 크게 줄어듭니다.

작업 속도 측면에서 가장 중요한 습관은 프로젝트 코드를 윈도우 드라이브(/mnt/c/...)가 아니라 WSL2 리눅스 파일시스템 안(~/projects 등)에 두는 것입니다. /mnt/c 경유 접근은 9P 프로토콜을 거치는 구조라 파일이 많은 프로젝트(특히 node_modules처럼 파일 수가 많은 경우)에서 체감될 정도로 느립니다. VS Code를 쓴다면 Remote-WSL 확장으로 WSL2 안의 파일시스템에 직접 연결해 편집하는 것이 성능과 줄바꿈 문자(CRLF/LF) 문제 모두를 피하는 방법입니다.

7. 자주 겪는 문제와 해결

GRUB 메뉴가 안 뜨고 바로 윈도우로 부팅된다. 윈도우 업데이트가 부팅 순서를 자기 자신(Windows Boot Manager)으로 되돌리는 경우가 흔합니다. UEFI 설정에서 부팅 순서를 확인해 우분투(보통 “ubuntu” 항목)를 최상단으로 올리거나, 윈도우 안에서 bcdedit으로 직접 부트 매니저 경로를 GRUB으로 지정할 수 있습니다.

# 관리자 권한 PowerShell
bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi

BitLocker 복구 화면이 뜬다. 4장에서 설명한 대로 UEFI 설정 변경이 트리거입니다. 복구 키를 입력해 일단 부팅하고, 이후 BitLocker를 일시 중단(manage-bde -protectors -disable C:)한 뒤 필요한 UEFI 설정을 마무리하면 반복적으로 이 화면을 보는 것을 피할 수 있습니다.

NVIDIA 드라이버 설치 후 검은 화면. MOK 등록을 건너뛰었거나 Secure Boot와 드라이버 서명 문제일 가능성이 높습니다. 임시로 GRUB 부팅 메뉴에서 e 키를 눌러 커널 파라미터 줄 끝에 nomodeset을 추가하고 부팅하면 기본 디스플레이 드라이버로 진입할 수 있고, 이후 MOK를 다시 등록하거나 드라이버를 재설치해 근본 원인을 해결합니다.

설치 프로그램이 디스크를 못 찾는다. 3장에서 설명한 인텔 RST/VMD(RAID) 모드가 원인인 경우가 대부분입니다. BIOS에서 스토리지 컨트롤러 모드를 확인하고, 이미 윈도우가 설치된 상태라면 안전 모드 재부팅으로 AHCI 드라이버를 먼저 준비한 뒤 전환해야 합니다.

마치며

WSL2와 듀얼 부팅은 경쟁 관계가 아니라 서로 다른 문제를 푸는 도구입니다. 대부분의 백엔드/웹 개발, 컨테이너 작업, 일반적인 CLI 도구 사용은 WSL2로 충분하고 위험도도 거의 없습니다. GPU 연산조차 윈도우 드라이버를 그대로 활용할 수 있어 딥러닝 작업도 WSL2로 시작하는 것이 합리적입니다. 반면 실시간 하드웨어 제어, USB 장치를 깊게 다루는 작업, 커널 모듈 개발처럼 VM 계층이 방해가 되는 작업이라면 듀얼 부팅이 필요하고, 이 경우에도 별도 물리 디스크를 쓰면 기존 윈도우 환경에 실질적인 위험 없이 안전하게 시작할 수 있습니다. 같은 디스크를 나눠 쓰는 방식을 선택했다면 BitLocker 키 확인과 Fast Startup 해제만큼은 절대 생략하지 않는 것을 권합니다.