운영체제 신입 트러블슈팅 면접

Segmentation Fault는 프로세스가 허용되지 않은 메모리 영역에 접근하려 할 때 발생하는 에러입니다. 주요 원인으로는 초기화되지 않은 포인터를 사용하거나, 이미 해제된 메모리에 접근하거나, 배열의 범위를 벗어난 인덱스에 접근하는 경우가 있습니다. 또한 NULL 포인터를 역참조하거나, 읽기 전용 메모리 영역에 쓰기를 시도할 때도 발생합니다. 이는 운영체제의 메모리 보호 기능이 작동하여 잘못된 메모리 접근을 차단하는 것입니다. 디버깅 도구나 코어 덤프 분석을 통해 문제가 발생한 코드 위치를 파악할 수 있습니다.

D 상태는 Uninterruptible Sleep 상태로, 프로세스가 I/O 작업 완료를 기다리며 인터럽트나 시그널로도 깨울 수 없는 상태입니다. 주로 디스크 I/O, NFS 마운트 응답 대기, 하드웨어 장치 응답 대기 등에서 발생합니다. 이 상태가 지속되면 디스크 장애, 네트워크 스토리지 연결 문제, 커널 버그 등을 의심해야 합니다. 해결 방법으로는 먼저 dmesg나 /var/log/messages를 확인하여 I/O 에러를 찾고, iostat이나 iotop으로 디스크 상태를 점검합니다. NFS 문제라면 마운트를 해제하거나 서버 재부팅이 필요할 수 있으며, 하드웨어 문제라면 디스크 교체를 고려해야 합니다.

Out of Memory 에러는 물리 메모리가 충분해도 여러 이유로 발생할 수 있습니다. 첫째, 프로세스별 메모리 제한(ulimit)이 설정되어 있어 특정 프로세스가 더 이상 메모리를 할당받지 못할 수 있습니다. 둘째, 32비트 시스템에서는 프로세스당 주소 공간이 제한되어 있습니다. 셋째, 메모리 파편화로 인해 연속된 큰 메모리 블록을 할당하지 못할 수 있습니다. 진단 방법으로는 ulimit -a로 제한값을 확인하고, /var/log/messages에서 OOM Killer 로그를 확인하며, cat /proc/meminfo로 메모리 상세 정보를 분석합니다. 또한 특정 프로세스의 메모리 사용량은 /proc/[pid]/status에서 확인할 수 있습니다.

top 명령어에서 먼저 상단의 CPU 사용률 라인을 확인하여 us(user), sy(system), wa(I/O wait) 값을 파악해야 합니다. us가 높으면 애플리케이션 로직 문제, sy가 높으면 시스템 콜이나 커널 작업 과다, wa가 높으면 디스크 I/O 대기 문제입니다. 프로세스 목록에서 %CPU 컬럼을 확인하여 어떤 프로세스가 CPU를 많이 사용하는지 식별합니다. 특정 프로세스가 원인이라면 해당 프로세스의 로그나 스택 트레이스를 확인하고, 무한 루프나 비효율적인 알고리즘이 있는지 점검합니다. 여러 프로세스가 동시에 높다면 시스템 전체 부하를 줄이거나 스케일 아웃을 고려해야 합니다.

이는 전형적인 Race Condition(경쟁 상태) 문제로, 여러 스레드가 공유 데이터에 동시에 접근하여 읽기/쓰기 순서가 보장되지 않을 때 발생합니다. 비결정적으로 나타나는 이유는 스레드 스케줄링 타이밍에 따라 실행 순서가 매번 달라지기 때문입니다. 디버깅 방법으로는 Thread Sanitizer 같은 도구를 사용하거나, 로그에 타임스탬프와 스레드 ID를 기록하여 실행 순서를 추적합니다. 해결 방안으로는 뮤텍스나 세마포어 같은 동기화 기법을 사용하여 임계 구역을 보호하거나, 원자적 연산을 사용하거나, 스레드 안전한 자료구조를 활용합니다. 근본적으로는 공유 상태를 최소화하는 설계가 중요합니다.