Linux 서버를 운영하다 보면 커널 로그에서 “Oops” 라는 메시지를 발견하는 경우가 있습니다.

Oops는 Kernel Panic처럼 치명적인 오류처럼 보이지만 실제 의미는 조금 다릅니다.

Kernel Oops는 커널 내부에서 오류가 발생했지만 즉시 시스템 전체를 중단하지는 않는 상태를 의미합니다.

즉, 커널이 오류를 감지하고 해당 정보를 출력한 뒤 가능한 범위 내에서 시스템을 계속 동작시키려는 것입니다.

이번 글에서는 Linux Kernel Oops의 개념과 발생 원인, 로그 구조, Call Trace 해석 방법, Kernel Panic과의 차이점, 실무 분석 절차까지 자세히 알아보겠습니다.

Linux Kernel Oops란?

Kernel Oops는 커널에서 예기치 않은 오류가 발생했음을 알리는 진단 메시지입니다.

전체 흐름은 다음과 같습니다.

Kernel

↓

Unexpected Error

↓

Oops Message

↓

Call Trace

↓

System Continue

가능한 경우 시스템은 계속 동작하지만 일부 기능은 정상적으로 동작하지 않을 수도 있습니다.

왜 Oops가 발생할까?

대표적인 원인은 다음과 같습니다.

NULL Pointer 접근
잘못된 메모리 참조
Driver 오류
잘못된 Kernel Module
Stack Overflow
Buffer Overflow
잘못된 Page Access
Race Condition

대부분 커널 코드의 버그로 인해 발생합니다.

Oops 발생 과정

Oops는 일반적으로 다음 순서로 발생합니다.

Kernel Function

↓

Fault

↓

Exception

↓

Oops Handler

↓

Call Trace

↓

Kernel Continue

커널은 오류 정보를 최대한 기록한 후 실행을 이어가려고 시도합니다.

대표적인 Oops 메시지

예시

BUG: unable to handle kernel NULL pointer dereference

Oops: 0000 [#1]

CPU: 3

RIP: driver_open+0x45

Call Trace:

driver_init()

device_probe()

...

Oops 메시지에는 문제를 분석하는 데 필요한 정보가 포함되어 있습니다.

Oops 메시지 구성

일반적으로 다음과 같은 정보가 출력됩니다.

BUG

Oops 번호

CPU 번호

PID

프로세스 이름

RIP

Register

Stack

Call Trace

Module 정보

이 정보를 통해 오류의 원인을 추적할 수 있습니다.

BUG 메시지

가장 먼저 확인해야 하는 부분입니다.

예시

BUG:

unable to handle kernel paging request

또는

BUG:

NULL pointer dereference

오류 종류를 빠르게 파악할 수 있습니다.

CPU 정보

예시

CPU: 5

멀티코어 환경에서는 어떤 CPU에서 문제가 발생했는지 알려줍니다.

PID와 Process

예시

PID: 1842

Comm: nginx

오류 당시 어떤 프로세스가 실행 중이었는지 확인할 수 있습니다.

단, 프로세스 자체가 원인이라는 의미는 아닙니다.

RIP(Register Instruction Pointer)

예시

RIP:

driver_open+0x58

현재 실행 중인 함수와 Offset을 의미합니다.

디버깅 시 매우 중요한 정보입니다.

Register 정보

예시

RAX

RBX

RCX

RDX

CPU 레지스터 값을 출력합니다.

NULL Pointer나 잘못된 주소 접근 여부를 확인할 수 있습니다.

Stack Trace

Stack 정보는 함수 호출 순서를 보여줍니다.

main()

↓

driver_probe()

↓

net_open()

↓

Oops

Call Trace와 함께 분석하면 원인을 빠르게 찾을 수 있습니다.

Call Trace 분석

예시

Call Trace:

driver_open

device_add

bus_probe

do_initcalls

가장 아래쪽 함수부터 호출이 시작되어 위쪽으로 실행됩니다.

오류 직전의 함수들을 중심으로 분석하는 것이 일반적입니다.

Module 정보

예시

Modules linked in:

e1000e

xfs

nf_tables

로드된 Kernel Module 목록입니다.

특정 모듈에서 문제가 발생했는지 확인할 수 있습니다.

Oops와 Kernel Panic 비교

항목	Kernel Oops	Kernel Panic
시스템 실행	대부분 계속 실행	중단 또는 재부팅
심각도	높음	매우 높음
로그 출력	O	O
Call Trace	O	O
복구 가능성	있음	거의 없음

Oops는 즉시 시스템을 종료하지 않는다는 점이 가장 큰 차이입니다.

Oops 발생 후 해야 할 일

다음 절차를 권장합니다.

dmesg 확인
journalctl 확인
Call Trace 분석
Driver 확인
Module 확인
최근 Kernel 변경 사항 확인
동일 문제 재현

재현이 가능하면 원인 분석이 훨씬 쉬워집니다.

dmesg 확인

dmesg

최근 로그

dmesg | tail -100

Oops 메시지가 그대로 기록됩니다.

journalctl 확인

현재 부팅

journalctl -k

이전 부팅

journalctl -k -b -1

systemd 환경에서는 매우 자주 사용됩니다.

addr2line 활용

함수 위치 확인

addr2line -e vmlinux 주소

Offset을 실제 소스 코드 위치로 변환할 수 있습니다.

gdb 분석

Kernel Image 분석

gdb vmlinux

Breakpoint 설정과 변수 확인이 가능합니다.

crash 분석

Oops 이후 vmcore가 존재하면

crash vmlinux vmcore

메모리 상태와 Stack을 상세히 분석할 수 있습니다.

실무에서 자주 사용하는 명령어

Kernel 로그 확인

dmesg

Kernel Journal 확인

journalctl -k

최근 로그

dmesg | tail -100

Kernel Image 분석

gdb vmlinux

주소 확인

addr2line -e vmlinux 주소

Crash 분석

crash vmlinux vmcore

실무 사례

예를 들어 네트워크 드라이버를 업데이트한 후 간헐적으로 Oops 메시지가 발생한다고 가정해 보겠습니다.

운영팀은 다음과 같은 절차로 문제를 분석합니다.

dmesg에서 Oops 로그 확인
Call Trace를 통해 오류 함수 확인
addr2line으로 Offset을 실제 소스 코드 위치에 매핑
최근 변경된 드라이버 코드와 비교
테스트 환경에서 동일한 요청을 반복하여 문제 재현
수정 후 다시 빌드 및 검증
운영 서버에 패치 적용

이처럼 Oops는 단순한 오류 메시지가 아니라 커널 버그를 추적하는 핵심 단서가 됩니다.

자주 묻는 질문

Kernel Oops가 발생하면 반드시 재부팅해야 하나요?

반드시 그렇지는 않습니다. 일부 Oops는 시스템이 계속 동작할 수 있지만, 커널 상태가 불안정해질 수 있으므로 원인을 분석하고 가능한 한 빠르게 점검하는 것이 좋습니다.

Oops와 Kernel Panic은 어떤 관계인가요?

Oops는 커널이 오류를 기록하고 가능한 범위에서 계속 실행하려는 상태입니다. 하지만 심각한 오류가 연속적으로 발생하거나 복구가 불가능한 상황이라면 Kernel Panic으로 이어질 수 있습니다.

Oops 메시지에서 가장 중요한 정보는 무엇인가요?

BUG 메시지, RIP(Instruction Pointer), Call Trace, 그리고 관련 Kernel Module 정보가 가장 중요한 분석 대상입니다. 이 정보를 통해 오류가 발생한 함수와 원인을 추적할 수 있습니다.

마무리

Linux Kernel Oops는 커널 내부 오류를 알리는 중요한 진단 메시지입니다. 시스템이 즉시 중단되지는 않더라도 잠재적인 안정성 문제를 의미하므로 반드시 원인을 분석해야 합니다. dmesg, journalctl, Call Trace, addr2line, gdb, crash 등의 도구를 적절히 활용하면 오류 발생 위치와 원인을 효과적으로 추적할 수 있으며, Kernel Panic으로 이어지기 전에 문제를 해결하는 데 큰 도움이 됩니다.

Linux Kernel Oops란? Oops 메시지 분석부터 Call Trace 해석과 Kernel Panic 차이까지 완벽 이해