안드로이드 커널 커스터마이징

📋 목차

• 🔎 커널 구조와 동작 개요
• 🧰 빌드 환경과 소스 구성
• 🌳 디바이스 트리·defconfig·드라이버
• ⚡ 스케줄러·전력·써멀 튜닝
• 🧠 메모리/ZRAM/Binder 최적화
• 🛡 보안·SELinux·테스트/배포
• ❓ FAQ

안드로이드 커널 커스터마이징은 기기 체감 성능, 전력 효율, 발열 안정성, 보안을 한 번에 바꾸는 핵심 작업이에요. 메인라인 리눅스와 AOSP(Android Common Kernel), 벤더 포크가 맞물려 동작하니, 레이어별 역할을 이해하는 게 첫걸음이에요.

 

작업 범위는 defconfig 조정, 스케줄러/CPUfreq/IO 스택 튜닝, ZRAM·LMKD 메모리 정책, SELinux 정책, 드라이버 패치, DT(Device Tree) 수정까지 넓게 펼쳐져요. 내가 생각했을 때 가장 중요한 건 ‘측정→가설→검증’ 루프를 짧게 돌리는 태도예요.

🔎 커널 구조와 동작 개요

안드로이드 커널은 리눅스 커널 기반이에요. AOSP는 Android Common Kernel(ACK)을 제공하고, 칩셋 벤더는 SoC별 패치(스케줄러 트윅, 드라이버, 보안)를 얹어 기기 커널로 납품해요. 여기에 OEM이 전력/열 정책과 기능을 덧입혀 출하돼요.

 

핵심 경로는 태스크 스케줄링(CFS/EAS), CPUFreq/CPUIdle, Thermal, Memory Reclaim(LMKD/psi), Block IO, Binder IPC, 보안(SELinux/LSM) 등이에요. 사용자 앱 체감은 이 경로들의 지연과 변동성에 크게 좌우돼요.

 

🧭 구성 계층 요약

계층	예	역할
Mainline	v6.x	기본 커널 기능
ACK	android12-…	Android 전용 패치
Vendor	Qualcomm/Exynos	SoC 드라이버/최적화
OEM	Device Kernel	제품 정책·튜닝

 

🧰 빌드 환경과 소스 구성

일반적으로 Clang/LLVM 툴체인과 binutils를 사용해요. AOSP prebuilt 도구를 쓰면 호환성이 좋아요. Kbuild/Kconfig로 설정을 관리하고, out 디렉터리로 분리 빌드를 구성하면 실수가 줄어요.

 

🛠 필수 요소 체크

항목	권장	팁
툴체인	Clang/LLVM	커널 릴리즈 노트 호환 확인
설정	defconfig	fragment로 관리
아카이브	git submodule	ACK/Vendor 분리

 

🌳 디바이스 트리·defconfig·드라이버

DT는 하드웨어 자원(CPU 클러스터, 레귤레이터, 클럭, GPIO, 센서)을 기술하고 커널이 이를 참조해 드라이버를 초기화해요. defconfig는 커널 기능을 켜고 끄는 스위치라서, 불필요 기능을 줄이면 부팅 시간·메모리 발자국이 좋아져요.

 

🧩 DT/Config 포인트

영역	예	효과
cpufreq	opp-table	전력/성능 커브 지정
thermal	cooling-device	온도별 스로틀 정책
io sched	blk-mq 옵션	지연/변동성 제어

 

⚡ 스케줄러·전력·써멀 튜닝

CFS/EAS 기반 태스크 스케줄링을 조정해요. big.LITTLE/tri-cluster 환경에서 task placement가 핵심이에요. CPUfreq governor(schedutil), input boost, hint 기반 부스트를 조화롭게 써야 프레임 타이밍이 안정돼요.

 

🏁 튜닝 비교

항목	옵션	장점	주의
governor	schedutil	부하 반응 빠름	센서 잡음 필터
부스트	input/UF hints	UI 지연 감소	배터리 영향
써멀	정책 곡선	열 안정성	성능 저하

 

🧠 메모리/ZRAM/Binder 최적화

LMKD는 PSI 기반 메모리 압력을 감지해 백그라운드 프로세스를 정리해요. ZRAM은 DRAM 일부를 압축 스왑으로 활용해 멀티태스킹 안정성을 높여요. Binder IPC 경로의 버퍼 크기·우선순위도 UI 체감에 직접적이에요.

 

🧪 메모리 옵션 비교

옵션	선택	효과
ZRAM 알고리즘	lz4 / zstd	지연 vs 압축률
swappiness	40~80	스왑 민감도
lowmemorykiller	adj 조정	앱 유지/종료 균형

 

🛡 보안·SELinux·테스트/배포

SELinux는 Enforcing 유지가 기본이에요. denials를 퍼미시브로 풀기보다 정책 최소 보완이 안전해요. 커널 모듈 서명, kptr_restrict, usercopy 보호, lockdown 등 하드닝 스위치를 점검해요.

 

🔐 품질/배포 체크

영역	도구	목표
안정성	kselftest, CTS/VTS	호환·회귀 방지
성능	perf/ftrace/systrace	핫패스 지연 분석
배포	OTA/fastboot	안전 롤백

 

❓ FAQ

Q1. ACK와 메인라인의 차이는 뭐예요?

A1. ACK는 안드로이드 기능·보안·테스트가 추가된 공통 커널이고, 메인라인은 범용 리눅스예요.

 

Q2. 커널 빌드에 Clang만 써야 하나요?

A2. 요즘 트리 대부분이 Clang 기준으로 검증돼요. 호환성 측면에서 Clang을 권장해요.

 

Q3. defconfig는 어떻게 관리하죠?

A3. 베이스 defconfig에 fragment를 쌓아 기기·시장별 차이를 모듈화하면 편해요.

 

Q4. EAS가 항상 CFS보다 낫나요?

A4. 워크로드와 클러스터 토폴로지에 따라 달라요. 프레임 변동성 기준으로 검증해요.

 

Q5. input boost는 배터리를 많이 쓰나요?

A5. 지속 시간·목표 클럭을 낮추면 체감과 전력 균형을 잡을 수 있어요.

 

Q6. 써멀 정책은 어디서 조정하나요?

A6. DT의 cooling-device 곡선과 userspace 정책 데몬에서 다뤄요.

 

Q7. ZRAM 크기는 어느 정도가 좋아요?

A7. RAM의 25~50%를 시작점으로 두고, zstd/lz4를 비교해 지연·압축률을 맞춰요.

 

Q8. LMKD 민감도를 올리면 빨라지나요?

A8. 재시작이 늘어 역효과가 날 수 있어요. PSI 목표 지표로 균형을 잡아요.

 

Q9. Binder 버퍼 사이즈를 키우면 좋아요?

A9. 왕복 횟수는 줄지만 메모리 파편화가 늘 수 있어 벤치로 검증이 필요해요.

 

Q10. IO 스케줄러는 무엇을 쓰나요?

A10. blk-mq 기반으로 CFQ 계열 대신 mq-deadline/none 조합이 흔해요.

 

Q11. 파일시스템은 F2FS가 좋아요?

A11. 플래시 특화라 쓰기 효율이 좋고, 안드로이드에서 널리 사용돼요.

 

Q12. 프레임 드랍 디버깅은 뭘 보나요?

A12. systrace/perf/ftrace로 런큐 지연, 빈번한 스로틀, IO 스파이크를 봐요.

 

Q13. 커널 로그가 성능에 영향 주나요?

A13. 과도한 printk는 지연을 만들 수 있어 레벨을 관리해야 해요.

 

Q14. HZ 값은 어떻게 정해요?

A14. 타이머 해상도·오버헤드 균형을 보고 벤더 기본을 따르는 게 안전해요.

 

Q15. 페이지 캐시 조정은 의미 있나요?

A15. readahead, dirty ratios 조정이 미디어 워크로드에 도움 될 때가 있어요.

 

Q16. memfd/ashmem은 왜 쓰나요?

A16. 무명 공유 메모리로 프로세스 간 버퍼 공유에 효율적이에요.

 

Q17. 커널 모듈은 서명해야 하나요?

A17. 서명 적용이 보안상 바람직해요. 정책에 따라 미서명 로드가 차단돼요.

 

Q18. SELinux를 Permissive로 두면 편한데요?

A18. 보안 리스크가 크고 인증에 문제돼요. 필요한 룰만 최소로 추가해요.

 

Q19. 커널 업그레이드 이점은?

A19. 보안 패치, 스케줄러 개선, 드라이버 안정화가 누적돼 품질이 올라가요.

 

Q20. 메모리 누수는 어떻게 찾나요?

A20. kmemleak, slabinfo, tracepoints로 장기 관찰이 좋아요.

 

Q21. 배터리 세이버에서 왜 느려지죠?

A21. CPU/GPU/메모리 클럭과 IO 스케줄이 절약 프로파일로 바뀌기 때문이에요.

 

Q22. 프리페처 파라미터는 만지나요?

A22. 과도하면 캐시 오염이 늘 수 있어 워크로드별 신중히 조정해요.

 

Q23. IO 큐 깊이는 어느 정도가 좋아요?

A23. 지연 분산과 스루풋 균형을 벤치로 찾아요. 너무 깊으면 변동성이 커져요.

 

Q24. 커널 디버그 옵션은 꺼야 하나요?

A24. 개발기에서는 켜고, 릴리스에서는 오버헤드를 줄이기 위해 최소화해요.

 

Q25. 메모리 압축은 CPU를 많이 먹지 않나요?

A25. lz4는 가볍고, zstd는 압축률이 좋아요. 기기 성향에 맞춰 선택해요.

 

Q26. OTA 배포 시 벽돌 방지는?

A26. A/B 파티션, 롤백 보호, 서명 검증으로 안전하게 설계해요.

 

Q27. CTS/VTS 불통 원인은?

A27. 보안 정책 완화, 인터페이스 호환성 깨짐, 시간 소스 변경 등이 흔해요.

 

Q28. 전력 프로파일 평가는 어떻게?

A28. Power monitor와 프레임 타이밍을 동시에 기록해 상관분석해요.

 

Q29. 오픈소스 라이선스 주의점은?

A29. GPLv2 의무 준수(소스 공개), 서드파티 코드 라이선스 호환성 확인이 필수예요.

 

Q30. 커널 커스터마이징 시작 팁은?

A30. 실측 → 작은 변경 → 회귀 테스트 루프를 짧게, 변경점은 fragment와 패치로 추적해요.

 

⚖️ 주의사항 및 면책조항

본 HTML 문서는 2025년 기준 공개 기술 자료와 업계 일반 관행을 근거로 작성된 정보 제공용 콘텐츠예요. 여기서 다루는 설정, 파라미터, 정책, 예시는 이해를 돕기 위한 범용 설명이며, 특정 기기·펌웨어·지역 규격에 대한 정확한 적합성이나 결과를 보장하지 않아요.

커널 커스터마이징, 부트로더 언락, 비공식 바이너리 플래싱, SELinux 정책 변경, 디버그 옵션 수정, 전력/열 정책 조정 등은 기기 보증 무효, 데이터 손실, 보안 취약점 유발, 규격 불일치, 서비스 제약(예: 금융·DRM 앱 차단) 등의 리스크를 수반해요. 모든 행위는 사용자 본인의 전적인 판단과 책임 하에 진행되어야 하며, 이 문서는 그 어떠한 법적·기술적 결과에 대해서도 책임을 지지 않아요.

이 문서는 법률·보안·투자·제조 공정에 관한 공식 자문이 아니며, 규제·표준·보안 공지·제조사 매뉴얼·AOSP/ACK 문서·칩셋 벤더 가이드 등 1차 자료 확인이 항상 우선이에요. 기업·개발·배포 환경에서는 내부 보안팀·품질팀·법무팀의 사전 검토를 거쳐야 하고, GPLv2 등 오픈소스 라이선스 의무(소스 공개·저작권 고지 유지)를 준수해야 해요.

표기된 상표·로고·제품명은 각 소유자 자산이며 식별 목적으로만 언급돼요. 본 자료의 무단 복제·변형·상업적 전용은 제한될 수 있고, 인용 시 출처 표기를 권장해요. 관할·분쟁과 관련된 사항은 이용자 거주지의 강행 규정과 공서양속에 따르며, 구체 사안은 변호사·공학 감정인 등 공인 전문가의 개별 자문을 통해 판단해야 해요.