안드로이드 시스템의 심장부: Fastboot와 AOSP의 동작 원리 ~ Dev.

안드로이드 스마트폰은 우리 일상의 필수품이 되었지만, 그 화려한 사용자 인터페이스와 편리한 앱 생태계 아래에는 복잡하고 정교한 시스템 아키텍처가 숨 쉬고 있습니다. 대부분의 사용자는 제조사가 제공하는 운영체제(OS)의 틀 안에서 기기를 사용하지만, 개발자, 보안 연구원, 그리고 순수한 기술적 호기심을 가진 파워 유저들은 종종 그 경계를 넘어서고자 합니다. 바로 이 지점에서 'Fastboot'와 'AOSP(Android Open Source Project)'라는 두 가지 핵심 개념이 등장합니다. 이들은 단순히 기기를 '커스터마이징'하는 도구를 넘어, 안드로이드의 가장 깊은 수준에서 시스템을 이해하고 제어할 수 있게 해주는 열쇠와도 같습니다.

이 글은 Fastboot를 이용해 AOSP 이미지를 플래시하는 단순한 절차를 나열하는 것을 목표로 하지 않습니다. 대신, 우리는 한 걸음 더 깊이 들어가 안드로이드 기기가 어떻게 부팅되는지, 부트로더는 어떤 역할을 하는지, Fastboot 프로토콜이 어떤 원리로 동작하는지, 그리고 순수한 AOSP 이미지가 무엇을 의미하며 어떤 구조를 가지고 있는지 근본적인 원리를 탐구할 것입니다. 이 과정을 통해 독자들은 단순한 명령어의 나열이 아닌, 각 단계가 시스템에 어떤 영향을 미치는지에 대한 명확한 이해를 얻게 될 것입니다. 이는 시스템을 수정하는 과정에서 발생할 수 있는 잠재적 위험을 최소화하고, 예기치 않은 문제에 직면했을 때 스스로 해결할 수 있는 능력을 배양하는 데 결정적인 역할을 할 것입니다.

1부: 근본적인 이해 - 부트로더와 안드로이드 아키텍처

1.1. 전원 버튼 너머: 안드로이드 부팅 시퀀스

우리가 스마트폰의 전원 버튼을 누를 때, 화면에 로고가 나타나고 잠금 화면이 뜨기까지의 과정은 마법처럼 보일 수 있습니다. 하지만 내부적으로는 여러 단계의 정교한 부팅 시퀀스가 순차적으로 실행됩니다. 이 과정을 이해하는 것은 Fastboot가 왜 필요한지를 이해하는 첫걸음입니다.

Primary Bootloader (PBL): 전원이 인가되면, 기기의 System-on-Chip (SoC)에 내장된 읽기 전용 메모리(ROM)에 있는 코드가 가장 먼저 실행됩니다. 이 코드는 매우 원시적인 수준의 하드웨어 초기화를 수행하고, 신뢰할 수 있는 다음 단계의 부트로더를 찾아 메모리로 로드한 후 실행 제어권을 넘깁니다.
Secondary Bootloader (SBL): 일반적으로 '부트로더'라고 부르는 것이 바로 이 부분입니다. SBL은 RAM과 같은 주요 하드웨어를 초기화하고, 보안 검사를 수행합니다. 여기서 사용자의 입력(예: 볼륨 버튼 누르기)을 감지하여 일반 부팅, 리커버리 모드, 또는 Fastboot 모드로 진입할지를 결정합니다.
리눅스 커널 (Linux Kernel): 부트로더는 저장소(eMMC 또는 UFS)의 'boot' 파티션에서 커널 이미지를 메모리로 로드합니다. 안드로이드 커널은 리눅스 커널을 기반으로 하며, 프로세스 관리, 메모리 관리, 하드웨어 드라이버 등 시스템의 핵심 기능을 담당합니다.
init 프로세스: 커널이 부팅되면 가장 먼저 'init'이라는 사용자 공간 프로세스를 실행합니다. init은 안드로이드 시스템의 첫 번째이자 모든 다른 프로세스의 조상입니다. 다양한 스크립트(.rc 파일)를 읽어 시스템 파티션을 마운트하고, 핵심 시스템 서비스(데몬)들을 시작하며, 안드로이드 런타임(ART)을 준비시킵니다.
자이고트 (Zygote)와 시스템 서버: init은 '자이고트'라는 특별한 프로세스를 시작합니다. 자이고트는 핵심 시스템 라이브러리와 클래스를 미리 로드하여 새로운 앱 프로세스가 매우 빠르게 시작될 수 있도록 하는 '앱 프로세스의 부모' 역할을 합니다. 이후 자이고트는 '시스템 서버'를 포크(fork)하여 전화, 네트워크, 배터리 관리 등 안드로이드 프레임워크의 핵심 서비스를 실행시킵니다.
홈 화면 (Launcher): 모든 시스템 서비스가 준비되면, 시스템 서버는 홈 화면 앱(런처)을 시작하고, 마침내 사용자가 기기와 상호작용할 수 있는 상태가 됩니다.

이 복잡한 과정에서 Fastboot는 2단계, 즉 SBL(부트로더) 레벨에서 동작합니다. 이는 운영체제가 완전히 로드되기 전, 시스템의 가장 근본적인 부분에 접근할 수 있다는 것을 의미합니다. ADB(Android Debug Bridge)가 이미 부팅된 안드로이드 시스템 위에서 동작하는 반면, Fastboot는 시스템이 부팅되지 않거나 손상된 상태에서도 기기를 제어할 수 있는 강력한 권한을 가집니다.

1.2. 시스템의 문지기: 부트로더의 역할과 잠금 해제

부트로더는 단순히 커널을 로드하는 역할을 넘어, 시스템의 무결성과 보안을 책임지는 중요한 문지기입니다. 제조사는 신뢰할 수 없는 소프트웨어가 기기에서 실행되는 것을 방지하기 위해 부트로더를 '잠금(Locked)' 상태로 출고합니다.

잠긴 부트로더 (Locked Bootloader): 잠긴 상태에서는 제조사의 디지털 서명이 있는 공식 펌웨어만 부팅을 허용합니다. 즉, boot, recovery, system 등의 파티션에 수정이 가해지거나 서명이 일치하지 않으면 부트로더는 부팅 프로세스를 중단시켜 기기를 보호합니다. 이것이 바로 '보안 부팅(Secure Boot)'의 핵심 원리입니다.
잠금 해제된 부트로더 (Unlocked Bootloader): 부트로더 잠금을 해제하면 이러한 서명 검증 과정이 비활성화됩니다. 이를 통해 사용자는 AOSP 기반의 커스텀 ROM, 커스텀 리커버리(TWRP 등), 수정된 커널 등 비공식 소프트웨어를 기기에 플래시하고 부팅할 수 있게 됩니다. 시스템 파티션에 대한 완전한 쓰기 권한을 얻는 셈입니다.

부트로더 잠금 해제는 강력한 자유를 부여하지만, 그에 따르는 책임도 명확합니다.

데이터 완전 삭제: 보안상의 이유로, 부트로더 잠금 해제 과정은 기기의 모든 사용자 데이터(사진, 앱, 설정 등)를 완전히 삭제합니다. 이는 기기를 분실했을 때 잠금 해제를 통해 데이터에 접근하는 것을 방지하기 위한 조치입니다.
보안 위험 증가: 서명 검증이 비활성화되므로, 악성 소프트웨어가 포함된 이미지를 플래시할 경우 시스템이 치명적인 위험에 노출될 수 있습니다. 또한, 일부 금융 앱이나 DRM 콘텐츠를 사용하는 앱은 부트로더가 잠금 해제된 기기에서 실행을 거부할 수 있습니다.
보증 무효: 대부분의 제조사는 부트로더 잠금 해제를 사용자가 시스템을 임의로 변경한 것으로 간주하여 하드웨어 보증을 무효화합니다.

따라서 Fastboot를 사용하여 시스템을 수정하기 위한 첫 번째이자 가장 중요한 관문은 바로 이 부트로더의 잠금을 해제하는 것입니다.

2부: Fastboot 프로토콜과 명령어 심층 분석

2.1. Fastboot의 작동 원리: 도구와 프로토콜

Fastboot는 두 가지 의미를 가집니다. 하나는 PC에서 실행하는 커맨드라인 '도구(tool)'이고, 다른 하나는 PC와 기기의 부트로더 간에 통신하는 '프로토콜(protocol)'입니다. 이 프로토콜은 USB를 통해 간단한 텍스트 기반의 명령과 바이너리 데이터를 주고받는 방식으로 동작합니다.

사용자가 PC에서 `fastboot flash system system.img`와 같은 명령어를 입력하면, 다음과 같은 과정이 일어납니다.

명령어 전송: `fastboot` 도구는 "flash:system"이라는 텍스트 명령어를 USB를 통해 기기의 부트로더로 전송합니다.
데이터 크기 협상: 부트로더는 이 명령을 받고, 뒤이어 전송될 데이터(system.img)의 크기를 PC에 요청합니다. PC는 이미지 파일의 크기를 담은 "DATA<16진수 크기>" 형태의 응답을 보냅니다.
데이터 전송: 부트로더가 "OKAY"로 응답하면, PC는 `system.img` 파일의 내용을 청크(chunk) 단위로 나누어 USB를 통해 전송하기 시작합니다. 부트로더는 이 데이터 청크들을 받아 임시 버퍼에 저장합니다.
플래싱(쓰기) 작업: 모든 데이터가 성공적으로 전송되면, 부트로더는 PC에 최종 "OKAY" 신호를 보낸 후, 버퍼에 저장된 데이터를 실제 'system' 파티션(eMMC 또는 UFS 메모리)에 기록합니다. 이 과정이 완료되면 최종 성공 또는 실패 상태를 PC로 다시 알려줍니다.

이처럼 Fastboot는 비교적 단순하지만 효율적인 프로토콜을 사용하여, 운영체제의 도움 없이도 PC가 기기의 저장소 파티션을 직접 읽고 쓸 수 있도록 해줍니다.

2.2. 환경 설정: 모든 작업의 시작

Fastboot를 사용하기 위해서는 먼저 PC에 개발 환경을 구축해야 합니다. 이는 구글에서 공식적으로 배포하는 'Android SDK Platform-Tools'를 다운로드하는 것부터 시작됩니다.

다운로드: 공식 안드로이드 개발자 웹사이트에서 자신의 운영체제(Windows, macOS, Linux)에 맞는 최신 버전의 Platform-Tools를 다운로드합니다.
압축 해제: 다운로드한 zip 파일의 압축을 사용자가 접근하기 쉬운 경로(예: `C:\platform-tools` 또는 `~/platform-tools`)에 해제합니다. 내부에는 `fastboot`, `adb` 등의 실행 파일이 포함되어 있습니다.
PATH 환경 변수 설정: 매번 `C:\platform-tools\fastboot`처럼 전체 경로를 입력하는 불편을 없애기 위해, 이 폴더의 경로를 시스템의 PATH 환경 변수에 추가하는 것이 좋습니다. 이렇게 하면 어떤 폴더에서든 터미널이나 명령 프롬프트를 열고 `fastboot` 명령어를 바로 실행할 수 있습니다.
- Windows: '시스템 속성' > '고급' > '환경 변수'에서 'Path' 변수를 편집하여 `C:\platform-tools` 경로를 추가합니다.
- macOS/Linux: `~/.zshrc`, `~/.bash_profile`, 또는 `~/.bashrc` 파일에 `export PATH=$PATH:~/platform-tools` 라인을 추가하고 터미널을 다시 시작합니다.
드라이버 설치 (Windows 전용): Windows 사용자는 기기가 Fastboot 모드일 때 PC가 이를 인식할 수 있도록 적절한 USB 드라이버를 설치해야 합니다. 보통 구글에서 제공하는 'Google USB Driver'나 기기 제조사에서 제공하는 공식 드라이버를 설치하면 됩니다. 장치 관리자에서 기기가 'Android Bootloader Interface'로 정상적으로 인식되는지 확인해야 합니다. macOS와 Linux는 일반적으로 별도의 드라이버 설치가 필요 없습니다.

2.3. 핵심 Fastboot 명령어 상세 해설

Fastboot는 다양한 명령어를 제공하며, 각 명령어는 시스템의 특정 부분을 제어하는 역할을 합니다.

fastboot devices

가장 기본적인 명령어로, PC에 Fastboot 모드로 연결된 기기의 목록을 표시합니다. 기기의 고유 시리얼 번호와 'fastboot'라는 상태가 함께 출력되어야 합니다. 만약 아무것도 출력되지 않거나 '< waiting for any device >' 메시지만 표시된다면, USB 케이블 연결, 드라이버 설치, 또는 기기가 Fastboot 모드로 정상 진입했는지를 확인해야 합니다.

fastboot reboot [bootloader|recovery|fastboot]

기기를 재부팅하는 명령어입니다. 아무런 인자 없이 사용하면(`fastboot reboot`) 일반 안드로이드 시스템으로 재부팅합니다.

fastboot reboot bootloader: 다시 부트로더(Fastboot 모드)로 재부팅합니다. 여러 작업을 연속으로 해야 할 때 유용합니다.
fastboot reboot recovery: 리커버리 모드로 재부팅합니다.
fastboot reboot fastboot: 'Fastbootd'라는 특수한 모드로 진입합니다. 이는 동적 파티션을 사용하는 최신 기기에서 논리 파티션(예: system, vendor, product)을 플래시할 때 사용되는 사용자 공간의 Fastboot 모드입니다.

fastboot flashing unlock

기기의 부트로더 잠금을 해제하는 명령어입니다. 구형 기기에서는 `fastboot oem unlock` 명령어를 사용하기도 했습니다. 이 명령을 실행하면 기기 화면에 경고 메시지와 함께 잠금 해제를 확인하는 프롬프트가 나타납니다. 볼륨 버튼으로 선택하고 전원 버튼으로 확인하면 잠금 해제가 진행되며, 이 과정에서 모든 데이터가 삭제됩니다.

fastboot flashing lock

잠금 해제된 부트로더를 다시 잠그는 명령어입니다. 주의: 이 명령어는 반드시 기기가 100% 순정 상태일 때만 사용해야 합니다. 커스텀 ROM이나 수정된 파티션이 있는 상태에서 부트로더를 잠그면, 부트로더가 서명되지 않은 시스템 파티션을 발견하고 부팅을 거부하여 기기가 부팅 불능 상태('벽돌')가 될 수 있습니다.

fastboot flash <partition_name> <filename.img>

Fastboot의 핵심 기능으로, 특정 파티션에 이미지 파일을 플래시(쓰기)합니다.

fastboot flash boot boot.img: 커널과 램디스크가 포함된 부트 이미지를 'boot' 파티션에 플래시합니다.
fastboot flash recovery recovery.img: 리커버리 이미지를 'recovery' 파티션에 플래시합니다.
fastboot flash system system.img: 안드로이드 프레임워크와 시스템 앱이 포함된 시스템 이미지를 'system' 파티션에 플래시합니다. 이 파일은 용량이 매우 클 수 있습니다.

fastboot getvar <variable>

부트로더가 가지고 있는 다양한 정보를 조회하는 매우 유용한 명령어입니다.

fastboot getvar all: 부트로더가 제공하는 모든 변수와 그 값을 한 번에 보여줍니다.
fastboot getvar product: 기기의 제품명을 확인합니다. 올바른 AOSP 이미지를 다운로드했는지 교차 확인하는 데 필수적입니다.
fastboot getvar version-bootloader: 부트로더의 버전을 확인합니다.
fastboot getvar serialno: 기기의 시리얼 번호를 확인합니다.
fastboot getvar current-slot: A/B 파티션 시스템을 사용하는 기기에서 현재 활성화된 슬롯('a' 또는 'b')을 확인합니다.

fastboot boot <kernel.img>

이미지를 파티션에 영구적으로 플래시하지 않고, 메모리에 로드하여 일회성으로 부팅시키는 명령어입니다. 커스텀 리커버리(예: TWRP)를 설치하기 전에 정상적으로 동작하는지 테스트하거나, 커스텀 커널을 테스트할 때 매우 유용합니다. 기기를 재부팅하면 원래의 커널/리커버리로 돌아갑니다.

fastboot -w

사용자 데이터와 캐시를 지우는(wipe) 명령어입니다. 내부적으로는 `fastboot erase userdata`와 `fastboot erase cache` 명령을 순차적으로 실행하는 것과 같습니다. 새로운 ROM을 클린 설치(clean install)할 때, 이전 시스템의 찌꺼기 데이터로 인한 충돌을 방지하기 위해 반드시 실행해야 하는 중요한 단계입니다.

fastboot set_active <slot>

A/B 파티션 시스템을 사용하는 기기에서 부팅할 슬롯을 수동으로 변경하는 명령어입니다. 예를 들어, `fastboot set_active b`는 다음 부팅 시 'b' 슬롯으로 부팅하도록 설정합니다. 이는 OTA(Over-the-Air) 업데이트가 실패했을 때 이전 슬롯으로 돌아가 시스템을 복구하는 등 고급 시나리오에서 사용됩니다.

3부: AOSP 이미지의 구조와 의미

3.1. AOSP란 무엇인가? 순수 안드로이드의 본질

AOSP(Android Open Source Project)는 구글이 주도하여 개발하고 공개하는 안드로이드 운영체제의 오픈소스 코드베이스를 의미합니다. 우리가 사용하는 삼성, LG, 샤오미 등의 스마트폰에 설치된 안드로이드는 모두 이 AOSP를 기반으로 합니다. 하지만 제조사들은 AOSP 위에 자신들만의 사용자 인터페이스(One UI, MIUI 등), 추가 기능, 그리고 독점 드라이버를 추가하여 자사 기기에 최적화된 OS를 만듭니다.

반면, 구글이 픽셀 기기용으로 배포하는 '공장 이미지(Factory Image)'나 순수 AOSP 소스 코드를 직접 빌드하여 얻은 이미지는 이러한 제조사의 추가 수정이 전혀 없는, 말 그대로 '순정' 안드로이드입니다. AOSP 이미지를 플래시한다는 것은 기기를 구글이 의도한 가장 기본적인 안드로이드 상태로 되돌리는 것을 의미합니다.

여기서 중요한 점은 AOSP 자체에는 구글 플레이 스토어, Gmail, 구글 지도 등 구글의 독점적인 앱과 서비스(GMS, Google Mobile Services)가 포함되어 있지 않다는 것입니다. AOSP는 운영체제의 뼈대일 뿐이며, GMS는 구글과의 라이선스 계약을 통해 제조사들이 추가하는 별도의 패키지입니다.

3.2. AOSP 공장 이미지 파일 해부

구글 개발자 사이트에서 특정 기기용 공장 이미지를 다운로드하여 압축을 풀면, 여러 개의 `.img` 파일과 스크립트 파일이 나타납니다. 각 파일은 안드로이드 시스템의 특정 파티션에 해당하며, 이들의 조합으로 하나의 완전한 운영체제가 구성됩니다.

bootloader-<device>-<version>.img: 기기의 부트로더 이미지입니다. 일반적으로 가장 먼저 플래시하며, 새로운 안드로이드 버전에 필요한 부트로더 기능이 포함되어 있을 수 있습니다.
radio-<device>-<version>.img: 통신 모뎀 펌웨어입니다. 셀룰러 네트워크(LTE, 5G), Wi-Fi, 블루투스, GPS 등 무선 통신 기능을 제어하는 소프트웨어가 들어 있습니다. 베이스밴드(baseband) 펌웨어라고도 불립니다.
boot.img: 앞서 설명한 것처럼 리눅스 커널과 램디스크(ramdisk)를 포함하는 부트 이미지입니다. 램디스크는 시스템의 나머지 부분을 마운트하고 init 프로세스를 시작하는 데 필요한 최소한의 파일과 스크립트를 담고 있습니다.
system.img: 안드로이드 운영체제의 핵심부입니다. `/system` 파티션에 해당하며, 안드로이드 프레임워크, 시스템 라이브러리, 그리고 계산기, 시계와 같은 기본적인 시스템 앱들이 포함되어 있습니다.
vendor.img: 기기의 하드웨어를 제어하기 위한 제조사별 독점 파일(바이너리, 드라이버, HAL 구현체)이 들어있는 파티션입니다. SoC(칩셋) 제조사(퀄컴, 미디어텍 등)와 기기 제조사가 제공하는 소프트웨어로, AOSP가 하드웨어와 통신할 수 있도록 하는 다리 역할을 합니다.
product.img / system_ext.img: 최신 안드로이드 버전에서는 시스템 파티션이 더 세분화되었습니다. `product.img`는 특정 제품 모델에만 적용되는 앱이나 설정을, `system_ext.img`는 AOSP와 긴밀하게 연관된 시스템 확장 기능을 담습니다.
vbmeta.img: 안드로이드 검증 부팅(Android Verified Boot, AVB) 2.0에서 사용되는 메타데이터입니다. 이 파일에는 `boot`, `system` 등 다른 파티션 이미지의 암호화 해시값이 포함되어 있어, 부트로더가 각 파티션이 변조되지 않았는지 검증하는 데 사용됩니다. 보안에 매우 중요한 역할을 합니다.
dtbo.img: Device Tree Blob Overlay의 약자로, 런타임에 커널이 하드웨어 구성을 동적으로 로드할 수 있도록 하는 데이터를 담고 있습니다. 이는 동일한 커널 이미지를 여러 하드웨어 변형에 사용할 수 있게 해줍니다.
flash-all.sh (Linux/macOS) / flash-all.bat (Windows): 이 모든 이미지 파일들을 올바른 순서와 명령어로 자동으로 플래시해주는 편리한 셸 스크립트입니다. 초보자들은 이 스크립트를 사용하는 것이 안전하며, 스크립트 내용을 열어보면 어떤 `fastboot` 명령어가 실행되는지 학습할 수도 있습니다.

4부: 실전! AOSP 이미지 플래시 단계별 절차

이론적인 배경을 모두 이해했다면, 이제 실제 기기에 AOSP 이미지를 플래시할 준비가 되었습니다. 모든 과정은 신중하게 진행해야 하며, 단 하나의 실수도 기기에 문제를 일으킬 수 있음을 명심해야 합니다.

단계 0: 철저한 사전 준비

데이터 백업: 가장 중요한 단계입니다. 부트로더 잠금 해제와 `-w` 옵션으로 인해 기기의 모든 데이터가 영구적으로 삭제됩니다. 사진, 연락처, 문서 등 중요한 모든 것을 PC나 클라우드에 백업해야 합니다.
배터리 충전: 플래싱 도중에 전원이 꺼지면 기기가 심각한 손상을 입을 수 있습니다. 최소 80% 이상 배터리를 충전하는 것이 안전합니다.
정확한 공장 이미지 다운로드: 자신의 기기 모델명과 빌드 번호에 정확히 일치하는 공장 이미지를 다운로드해야 합니다. 예를 들어 'Pixel 7 Pro (cheetah)'용 이미지를 'Pixel 7 (panther)'에 플래시하면 안 됩니다. `fastboot getvar product` 명령어로 기기의 제품명을 다시 한번 확인하세요.
개발자 옵션 및 USB 디버깅 활성화:
- '설정' > '휴대전화 정보'로 이동하여 '빌드 번호' 항목을 7번 연속으로 탭하여 개발자 옵션을 활성화합니다.
- '설정' > '시스템' > '개발자 옵션'으로 이동합니다.
- 'OEM 잠금 해제' 옵션을 활성화합니다. (부트로더 잠금 해제를 허용하는 설정)
- 'USB 디버깅' 옵션을 활성화합니다.

단계 1: 부트로더 진입 및 잠금 해제

PC와 기기를 고품질의 USB 케이블로 연결합니다.
터미널(또는 명령 프롬프트)을 열고 `adb reboot bootloader` 명령어를 입력하여 기기를 Fastboot 모드로 재부팅합니다. 또는, 기기의 전원을 끈 상태에서 특정 키 조합(일반적으로 '전원 버튼 + 볼륨 다운 버튼')을 길게 눌러 수동으로 진입할 수도 있습니다.
Fastboot 모드에 진입하면, `fastboot devices` 명령어를 입력하여 PC가 기기를 제대로 인식하는지 확인합니다.
`fastboot flashing unlock` 명령어를 실행하여 부트로더 잠금 해제를 시작합니다. 기기 화면의 지시에 따라 잠금 해제를 완료합니다. 이 과정 후 기기는 초기화되고 다시 부트로더로 재부팅될 수 있습니다.

단계 2: AOSP 이미지 플래시

이제 본격적으로 이미지를 플래시할 차례입니다. 두 가지 방법이 있습니다.

방법 A: 자동 스크립트 사용 (권장)

다운로드한 AOSP 공장 이미지 압축 파일의 내용물을 모두 Platform-Tools 폴더에 함께 두거나, 압축 해제한 폴더에서 터미널을 엽니다.
Windows 사용자는 `flash-all.bat` 파일을 더블클릭하거나 터미널에서 실행합니다.
macOS/Linux 사용자는 터미널에서 `sh flash-all.sh` 명령어를 실행합니다.
스크립트가 자동으로 부트로더, 라디오 펌웨어를 업데이트하고, 모든 시스템 이미지를 플래시한 후, 데이터를 초기화하고 기기를 재부팅합니다. 모든 과정이 자동으로 진행되므로 완료될 때까지 기다리기만 하면 됩니다.

방법 B: 수동 플래시 (고급 사용자용)

각 파티션을 직접 제어하고 싶거나 스크립트가 제대로 동작하지 않을 때 사용하는 방법입니다. 플래시 순서가 매우 중요합니다.


# 1. 부트로더 업데이트
fastboot flash bootloader <bootloader_image_name>.img
fastboot reboot-bootloader

# 2. 라디오 펌웨어 업데이트
fastboot flash radio <radio_image_name>.img
fastboot reboot-bootloader

# 3. 핵심 시스템 이미지 플래시
# -w 옵션을 제거하면 사용자 데이터가 유지되지만, 충돌의 원인이 될 수 있습니다.
# update 명령어는 zip 파일 내의 모든 이미지를 순서대로 플래시합니다.
fastboot -w update image-<device>-<version>.zip

위의 `update` 명령어는 가장 간단한 수동 방식입니다. 만약 각 이미지를 하나씩 플래시하고 싶다면, `flash-all.sh` 스크립트의 내용을 참고하여 `fastboot flash boot boot.img`, `fastboot flash system system.img` 등의 명령어를 순서대로 실행해야 합니다.

단계 3: 첫 부팅 및 마무리

플래싱이 완료되고 `fastboot reboot` 명령어가 실행되면 기기가 재부팅됩니다. 새로운 시스템을 처음으로 부팅하는 데에는 평소보다 훨씬 긴 시간(5~15분)이 소요될 수 있습니다. 이는 모든 앱을 최적화하고 초기 설정을 구성하는 과정 때문이니 인내심을 갖고 기다려야 합니다. 부팅 로고 화면에서 멈춘 것처럼 보이더라도 강제로 전원을 끄지 마세요.

부팅이 성공적으로 완료되면, 익숙한 안드로이드 초기 설정 화면이 나타납니다. 언어, Wi-Fi 등을 설정하고 나면 순수한 AOSP 환경을 경험할 수 있습니다.

5부: 문제 해결 및 고급 주제

5.1. 흔히 발생하는 문제와 해결책

"< waiting for any device >": Fastboot가 기기를 찾지 못하는 상태입니다.
- 해결책 1: USB 케이블 및 포트 확인. 다른 케이블이나 다른 USB 포트(특히 메인보드 직결 포트)를 사용해보세요.
- 해결책 2 (Windows): 장치 관리자에서 드라이버가 올바르게 설치되었는지 확인하고, 문제가 있다면 재설치하세요.
- 해결책 3 (Linux): `udev` 규칙이 설정되지 않았을 수 있습니다. `sudo fastboot devices`로 시도해보거나, 안드로이드 개발용 `udev` 규칙을 설정하세요.
"FAILED (remote: '...partition not found')": Fastboot가 지정된 파티션을 찾지 못하는 오류입니다.
- 해결책: 이미지 파일이 현재 기기와 호환되지 않거나, 파티션 레이아웃이 다른 구형/신형 펌웨어용일 가능성이 높습니다. 기기 모델에 정확히 맞는 공장 이미지를 다운로드했는지 다시 확인하세요.
"FAILED (remote: '...flashing is not allowed in locked state')": 부트로더가 잠겨 있는 상태에서 플래시를 시도할 때 발생합니다.
- 해결책: `fastboot flashing unlock` 명령어로 부트로더 잠금을 먼저 해제해야 합니다.
무한 부팅 (Bootloop): 기기가 부팅 로고 화면을 계속 반복하며 시스템으로 진입하지 못하는 상태입니다.
- 해결책 1: 잘못된 이미지를 플래시했거나 데이터 초기화(`-w`)를 하지 않아 발생할 수 있습니다. 다시 Fastboot 모드로 진입하여 `fastboot -w`를 실행하거나, 올바른 이미지로 전체 플래싱 과정을 다시 진행해보세요.
- 해결책 2: 리커버리 모드로 진입하여 '공장 초기화(Factory Reset)'를 시도해볼 수 있습니다.

5.2. 보안: 검증 부팅(AVB)과 부트로더 재잠금

AOSP를 설치한 후, 보안에 민감하다면 부트로더를 다시 잠그는 것을 고려할 수 있습니다. 그러나 이는 매우 신중하게 접근해야 합니다.

검증 부팅(AVB): 앞서 설명했듯, 최신 안드로이드는 부팅 과정에서 `boot`, `system` 등 모든 중요 파티션의 무결성을 `vbmeta` 파티션의 서명을 통해 검증합니다. 부트로더가 잠겨 있으면, 이 검증에 실패할 경우 부팅이 중단됩니다.
부트로더 재잠금(`fastboot flashing lock`): 오직 100% 순정 공장 이미지가 설치된 상태에서만 부트로더를 다시 잠가야 합니다. 만약 루팅을 했거나, 커스텀 커널을 설치했거나, 시스템 파티션의 일부라도 수정된 상태에서 부트로더를 잠그면, AVB 검증에 실패하여 기기가 부팅되지 않는 '하드 브릭(hard brick)' 상태가 될 위험이 매우 큽니다. 이 경우 서비스 센터의 도움이 필요할 수 있습니다.

결론: 권한과 책임

Fastboot와 AOSP는 안드로이드의 닫힌 문을 열고, 그 내부를 깊숙이 탐험할 수 있게 해주는 강력한 도구입니다. 이를 통해 사용자는 제조사가 제공하는 환경을 넘어 자신이 원하는 대로 시스템을 재구성하고, 최신 안드로이드 버전을 먼저 경험하며, 시스템의 동작 원리를 직접 체험할 수 있습니다. 하지만 이 강력한 권한에는 시스템을 손상시킬 수 있는 위험과 모든 결과에 대한 책임이 뒤따릅니다.

이 글에서 다룬 부팅 시퀀스, 부트로더의 역할, Fastboot 명령어의 의미, AOSP 이미지의 구조에 대한 깊이 있는 이해는 단순한 '따라하기' 식의 작업을 넘어, 각 단계가 시스템에 미치는 영향을 예측하고 잠재적인 문제를 해결하는 데 필수적인 지식입니다. 이제 여러분은 안드로이드 시스템의 더 깊은 레이어와 소통할 준비가 되었습니다. 신중하게, 그리고 호기심을 잃지 않고 탐험을 계속해나가시길 바랍니다.

Wednesday, February 28, 2024

안드로이드 시스템의 심장부: Fastboot와 AOSP의 동작 원리