리눅스 커널 구조: 스케줄러·메모리·VFS·부팅·장애 진단

리눅스 커널 구조: 애플리케이션이 CPU·메모리·디스크·네트워크를 안전하게 공유하도록 만드는 운영체제의 핵심 계층입니다. 프로세스는 커널 함수를 직접 호출하지 않고 시스템 콜 ABI를 통해 서비스를 요청하며, 커널은 권한과 자원 상태를 검사한 뒤 하드웨어 작업을 수행합니다.

이 글은 모놀리식 커널이라는 분류만 나열하지 않습니다. 실제 서버에서 관측할 수 있는 명령을 따라 스케줄링, 가상 메모리, VFS, 부팅, 모듈, 패닉의 연결 관계를 확인하고, 근거 없는 sysctl 권장값을 적용하지 않는 진단 원칙까지 설명합니다.

리눅스 커널 구조 한눈에 보기

리눅스는 성능이 중요한 스케줄러, 메모리 관리자, VFS, 네트워크 스택과 대부분의 드라이버를 커널 주소 공간에서 실행하는 모놀리식 커널입니다. 다만 기능을 런타임에 추가·제거하는 로드 가능한 커널 모듈을 지원합니다. 사용자 공간과 커널 공간은 CPU 권한 수준과 페이지 테이블 보호로 구분됩니다.

현재 커널과 실행 환경 확인

uname -a
cat /etc/os-release
cat /proc/cmdline
systemd-detect-virt
cat /proc/sys/kernel/tainted

마지막 값이 0이 아니면 독점 모듈 로드, 강제 모듈 제거, 하드웨어 오류 등으로 커널이 tainted 상태일 수 있습니다. 숫자 자체만 보고 결론 내리지 말고 공식 taint 비트 설명과 커널 로그를 함께 확인합니다.

리눅스 커널 구조: 핵심 서브시스템

리눅스 커널 구조: 시스템 콜 경계

애플리케이션은 보통 libc 래퍼를 사용하지만 libc는 필수 경로가 아닙니다. 아키텍처별 시스템 콜 명령과 호출 규약을 직접 사용할 수도 있습니다. 커널은 시스템 콜 번호, 인자, 권한을 검사하고 내부 구현으로 전달합니다. 따라서 ‘glibc가 시스템 콜을 처리한다’가 아니라 ‘glibc가 흔히 편리한 래퍼를 제공한다’가 정확한 표현입니다.

strace로 파일 열기 경로 확인

strace -f -e trace=openat,read,write,close cat /etc/hostname

# 요약 통계만 확인
strace -c cat /etc/hostname

최신 glibc 환경에서는 파일 열기가 open() 대신 openat() 계열로 보일 수 있습니다. 사용자 함수 이름과 실제 시스템 콜 이름이 항상 일치한다고 가정하면 안 됩니다.

리눅스 커널 구조: CFS와 EEVDF 스케줄러

Linux의 일반 태스크 스케줄링은 선점형입니다. CFS를 ‘비선점 스케줄러’라고 설명하는 것은 잘못입니다. 또한 커널 6.6부터 일반 스케줄링 로직은 CFS의 가상 실행 시간 모델에서 EEVDF로 전환되기 시작했습니다. 배포판 백포트가 있을 수 있으므로 이름만으로 동작을 단정하지 말고 실제 커널 버전과 공급자 문서를 봅니다.

uname -r
ps -eo pid,tid,psr,cls,pri,ni,stat,comm --sort=-pri | head -n 20
chrt -p $$
cat /proc/$$/sched | head -n 30

리눅스 커널 구조: 가상 메모리와 페이지 캐시

프로세스가 보는 가상 주소는 MMU와 페이지 테이블을 통해 물리 메모리 또는 파일에 매핑됩니다. 익명 메모리, 파일 매핑, 페이지 캐시, slab, reclaim, swap은 서로 영향을 줍니다. free의 free 열만 보고 메모리 부족을 판단하지 말고 available, swap, page fault, reclaim, PSI를 함께 봅니다.

free -h
grep -E 'MemAvailable|Cached|Swap|Slab|SReclaimable' /proc/meminfo
vmstat 1 10
cat /proc/pressure/memory
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -n 20

프로세스 주소 공간 확인

PID=1234
pmap -x "$PID" | tail -n 20
cat "/proc/$PID/status" | grep -E 'VmRSS|VmSwap|Threads'
cat "/proc/$PID/smaps_rollup

VmRSS는 공유 페이지를 포함하므로 프로세스별 값을 단순 합산하면 실제 물리 메모리보다 크게 보일 수 있습니다. 공유 비용을 나눠 보는 PSS가 필요하면 smaps_rollup을 사용합니다.

리눅스 커널 구조: VFS와 파일 I/O

VFS는 ext4, XFS, Btrfs, NFS 같은 구현 위에 공통 인터페이스를 제공합니다. pathname은 dentry cache를 거쳐 inode로 해석되고, 열린 파일은 프로세스의 파일 디스크립터 테이블에서 커널의 file 객체를 참조합니다. 삭제된 파일을 프로세스가 계속 열고 있으면 경로는 사라져도 블록이 해제되지 않는 이유도 이 참조 관계에 있습니다.

cat /proc/filesystems
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
stat /var/log/messages
sudo lsof +L1
cat /proc/sys/fs/file-nr

디스크 공간 오류는 블록, inode, 열린 삭제 파일을 구분해 조사해야 합니다. 자세한 순서는 No space left on device 진단 가이드를 참고하십시오.

리눅스 커널 구조: 부팅과 initramfs

일반적인 UEFI 시스템은 펌웨어, 부트로더, 커널과 initramfs, 실제 루트 파일시스템, PID 1 순으로 부팅합니다. initramfs는 보통 압축된 cpio 아카이브로 전달되어 초기 사용자 공간을 제공하며, 스토리지·암호화·LVM·RAID에 필요한 모듈과 도구를 준비한 뒤 실제 루트로 전환합니다.

1. 펌웨어가 부트 항목을 선택하고 부트로더 또는 EFI stub을 실행합니다.
2. 커널이 CPU·메모리·인터럽트·초기 드라이버를 설정합니다.
3. initramfs의 초기 사용자 공간이 실제 루트 장치를 준비합니다.
4. switch_root 이후 실제 루트의 PID 1이 서비스와 로그인 환경을 올립니다.

cat /proc/cmdline
systemd-analyze time
systemd-analyze critical-chain
journalctl -b -k -p warning

# RHEL/Rocky 계열에서 현재 initramfs 내용 확인
lsinitrd "/boot/initramfs-$(uname -r).img" | less

커널 모듈과 드라이버 진단

모듈은 커널 내부에서 높은 권한으로 실행되므로 사용자 프로그램과 실패 영향이 다릅니다. 장치가 보이지 않을 때는 무작정 모듈을 제거하거나 다시 넣기보다 장치, 바인딩된 드라이버, 모듈 서명, 커널 로그 순서로 확인합니다.

lspci -nnk
lsmod | head
modinfo <module_name>
journalctl -k -b | grep -Ei 'firmware|module|driver|taint|error'
cat /proc/sys/kernel/tainted

modprobe -r는 사용 중인 스토리지·네트워크 드라이버를 분리할 수 있습니다. 운영 환경에서는 의존성과 영향 범위를 확인하고 유지보수 창 및 콘솔 접속을 확보하기 전에는 실행하지 않습니다.

리눅스 커널 구조: 커널 패닉 진단

Kernel Oops는 커널 오류를 기록한 뒤 실행을 이어 갈 수도 있지만 시스템 신뢰성은 이미 손상됐을 수 있습니다. Kernel Panic은 커널이 정상 실행을 지속할 수 없다고 판단한 상태이며, 설정에 따라 정지하거나 일정 시간 뒤 재부팅하거나 kdump용 캡처 커널로 전환할 수 있습니다. 항상 ‘보호를 위한 셧다운’이라고 단정하면 안 됩니다.

journalctl -k -b -1 -p warning..alert
last -x | head -n 20
sudo kdumpctl status
sysctl kernel.panic kernel.panic_on_oops
ls -lh /var/crash

패닉 조사 순서

• 최근 커널·드라이버·펌웨어·하드웨어 변경 시점을 확인합니다.
• 콘솔 또는 원격 관리 장치의 전체 패닉 화면과 최초 오류를 보존합니다.
• kdump가 준비돼 있었다면 vmcore와 동일 빌드의 디버그 심볼을 확보합니다.
• 이전 커널 부팅으로 재현 여부를 나눠 회귀와 하드웨어 문제를 구분합니다.
• 운영 서버에서 의도적인 패닉 트리거를 실행하지 않습니다.

sysctl은 측정·가설·롤백 순서로

sysctl에는 모든 웹 서버에 통하는 만능 추천값이 없습니다. 커널 버전, 메모리, 연결 패턴, 애플리케이션 큐, 컨테이너 제한에 따라 병목이 달라집니다. 특히 tcp_tw_reuse, 포트 범위, backlog, swappiness를 근거 없이 한꺼번에 바꾸면 장애 원인만 흐려집니다.

# 1. 변경 전 값과 관련 지표 저장
sysctl vm.swappiness net.core.somaxconn net.ipv4.ip_local_port_range
ss -s
vmstat 1 10

# 2. 적용 파일의 문법과 전체 병합 결과 점검
sudo sysctl --system

# 3. 실제 실행 중인 값을 다시 확인
sysctl vm.swappiness net.core.somaxconn net.ipv4.ip_local_port_range

리눅스 커널 구조: 10분 진단 순서

# 1. 버전·부팅·taint
uname -r
uptime
cat /proc/sys/kernel/tainted

# 2. CPU·메모리·I/O 압력
vmstat 1 10
cat /proc/pressure/{cpu,memory,io}

# 3. 최근 커널 경고와 실패 단위
journalctl -k -b -p warning..alert
systemctl --failed

# 4. 파일시스템과 열린 삭제 파일
df -hT
df -i
sudo lsof +L1

진단은 ‘튜닝값을 먼저 바꾸는 작업’이 아닙니다. 시간축을 맞추고 어떤 자원이 포화됐는지, 커널 경고가 먼저인지 애플리케이션 오류가 먼저인지 확인한 다음 재현 가능한 가설을 세웁니다.

자주 틀리는 설명 교정

공식 문서와 다음 학습

• Linux EEVDF 스케줄러 문서
• Linux 메모리 관리 문서
• Linux VFS 개요
• Linux /proc/sys/kernel 문서
• Linux kdump 문서
• Python 사용자 공간 격리 가이드

정리

리눅스 커널 구조를 이해한다는 것은 용어를 외우는 것이 아니라 사용자 공간의 증상을 시스템 콜, 스케줄러, 메모리, VFS, 드라이버와 연결하는 능력입니다. 먼저 현재 버전과 로그를 보존하고, 관측 지표로 병목 계층을 좁힌 뒤, 변경은 한 번에 하나씩 롤백 계획과 함께 검증하십시오.