서버에서 애플리케이션이 멈췄을 때, strace가 필요한 순간

strace는 애플리케이션이 리눅스 커널에 보낸 요청과 그 결과를 그대로 보여주는 추적 도구입니다. 파일을 열었는지, 소켓 연결을 시도했는지, 권한 때문에 거절됐는지, 어떤 호출에서 기다리고 있는지를 애플리케이션 로그보다 한 단계 아래에서 확인합니다.

제가 strace를 꺼내는 순간은 대체로 비슷합니다. 프로세스는 살아 있고 CPU도 튀지 않는데 응답이 없거나, 로그에는 failed 한 줄만 남았거나, 컨테이너 안에서는 파일이 있다고 믿었는데 실제 프로세스는 다른 경로를 보고 있을 때입니다. 이런 문제는 프레임워크 로그만 붙잡고 있으면 오래 돌아갑니다. 커널 입장에서 보면 대개 ENOENT, EACCES, ECONNREFUSED, ETIMEDOUT, futex 대기 같은 단서로 쪼개집니다.

다만 strace는 만능 관찰기가 아닙니다. 시스템 콜 경계는 잘 보여주지만, 애플리케이션 내부 변수나 비즈니스 로직의 분기까지 알려주지는 않습니다. 그래서 저는 장애 대응 때 순서를 이렇게 잡습니다. 먼저 애플리케이션 로그와 메트릭으로 증상을 좁히고, 파일·권한·네트워크·프로세스 대기처럼 운영체제 경계가 의심될 때 strace를 붙입니다. 이 순서를 지키면 출력의 바다에서 헤매는 시간이 확 줄어듭니다.

strace는 사용자 공간(User Space)의 애플리케이션과 커널(Kernel) 사이에서 오가는 시스템 콜 흐름을 추적합니다. 그래서 “내 코드가 뭘 하려고 했는가”보다 “커널에 실제로 어떤 요청이 도착했는가”를 확인하는 데 강합니다.

strace 개념: 시스템 콜을 로그처럼 읽는 법

리눅스 애플리케이션은 파일, 네트워크, 프로세스, 시간, 메모리 같은 자원을 직접 만지지 않습니다. openat(), read(), write(), connect(), statx(), clone(), execve(), futex() 같은 시스템 콜을 통해 커널에 요청합니다. strace는 그 요청의 인자와 반환값을 보여줍니다.

출력 한 줄은 보통 아래처럼 읽습니다.

openat(AT_FDCWD, "/etc/myapp/config.yml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

왼쪽은 호출 이름과 인자, 오른쪽은 반환값입니다. = -1은 실패, ENOENT는 파일이 없다는 뜻입니다. 이 한 줄만으로도 “설정 로딩 실패”가 코드 문제인지, 배포 경로 문제인지, 마운트 문제인지 조사 방향이 달라집니다.

실전 구현: 기본 명령어보다 필터링이 먼저입니다

설치는 간단합니다. 운영 서버에 새 패키지를 설치해야 한다면 변경 절차를 따라야 하지만, 대부분의 배포판에서는 표준 패키지로 제공합니다.

# Debian/Ubuntu 계열
sudo apt update
sudo apt install -y strace

# RHEL/CentOS/Fedora 계열
sudo dnf install -y strace

# 설치 확인
strace -V

가장 단순한 실행은 명령 앞에 strace를 붙이는 방식입니다.

strace ls /tmp

하지만 실무에서는 이렇게 전체를 보는 일이 많지 않습니다. 출력이 너무 많고, 동적 라이브러리 로딩이나 로케일 파일 접근처럼 지금 문제와 무관한 줄이 섞입니다. 처음부터 범위를 좁히는 편이 낫습니다.

# 파일 관련 시스템 콜만 추적
strace -e trace=file ls /etc/nginx

# 네트워크 관련 시스템 콜만 추적
strace -e trace=network curl -I https://example.com

# 프로세스 실행 흐름 확인
strace -e trace=process bash -lc 'echo hello'

# 시간 정보와 각 호출 소요 시간 표시
strace -tt -T -e trace=file ls /etc

# 실패한 시스템 콜만 보고 싶을 때
strace -e trace=file -e status=failed ls /does-not-exist

-e trace=file은 파일 관련 호출 그룹만 표시합니다. -e trace=network는 소켓과 연결 흐름을 좁혀 보여줍니다. -tt는 시각을 마이크로초 단위까지 자세히 표시하고, -T는 각 시스템 콜에 걸린 시간을 꺾쇠괄호로 붙입니다. -e status=failed는 실패한 호출만 추려서 볼 때 유용합니다. strace 버전이나 배포판에 따라 지원 옵션이 다를 수 있으니, 현장 서버에서는 strace -h로 한 번 확인하는 습관이 좋습니다.

운영 환경에서는 전체 추적보다 trace=file, trace=network, status=failed처럼 질문을 좁히는 방식이 훨씬 빠릅니다.

이미 실행 중인 프로세스에 붙어서 Linux 디버깅하기

실제 장애에서는 새 명령을 실행하는 것보다 이미 떠 있는 프로세스를 봐야 할 때가 많습니다. 이때는 -p로 PID에 붙습니다.

# PID 확인
pgrep -af 'nginx|gunicorn|java|node'

# 실행 중인 프로세스에 연결
sudo strace -p 12345

# 자식 프로세스까지 따라가며 파일에 저장
sudo strace -f -tt -T -s 256 -o /tmp/app.strace.log -p 12345

# PID별로 로그 파일을 나누고 싶을 때
sudo strace -ff -tt -T -s 256 -o /tmp/app.strace -p 12345

-f는 fork, clone, vfork로 생기는 자식 프로세스까지 추적합니다. 웹 서버, 워커, 큐 컨슈머, CGI 계열처럼 실행 흐름이 자식 프로세스로 넘어가는 구조에서는 거의 필수입니다. -ff는 PID별로 로그를 분리합니다. 한 파일에 모든 프로세스 로그가 섞이면 시간순으로 따라가기는 쉽지만, 특정 워커만 분석할 때는 분리 로그가 더 편합니다.

-s 256은 문자열 출력 길이를 늘립니다. 기본 출력 길이로는 긴 파일 경로나 HTTP 헤더 일부가 잘려서 원인을 놓칠 수 있습니다. 분석용이면 -s 256 또는 -s 1024 정도로 늘리고, 민감정보가 섞일 수 있는 환경에서는 저장 위치와 공유 범위를 조심해야 합니다. strace 로그에는 파일 경로, 환경 변수 일부, 소켓 주소, 토큰처럼 보안상 민감한 값이 드러날 수 있습니다.

운영 서버에 붙일 때는 짧게, 좁게, 파일로 남기는 쪽을 권합니다. strace는 ptrace 기반으로 대상 프로세스를 관찰하므로 오버헤드가 생길 수 있습니다. 특히 초당 시스템 콜이 많은 프로세스에 전체 추적을 오래 걸면 지연이 커질 수 있습니다. 수치를 단정할 수는 없지만, 장애 중인 서비스에 무심코 전체 추적을 오래 붙이는 건 피하는 편이 안전합니다.

재현 가능한 시나리오 1: 설정 파일을 못 찾는 애플리케이션 분석

먼저 가장 흔한 파일 경로 문제를 작게 재현해보겠습니다. 일부러 없는 설정 파일을 열고, strace에서 실제 접근 경로와 에러 코드를 확인합니다.

# app.py
from pathlib import Path

config_path = Path("/etc/myapp/config.yml")
print(config_path.read_text())

python3 app.py

# 파일 관련 시스템 콜만 추적
strace -e trace=file -s 256 python3 app.py

출력에서 이런 줄을 찾습니다.

openat(AT_FDCWD, "/etc/myapp/config.yml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

• openat: 파일을 열려고 했습니다.
• "/etc/myapp/config.yml": 애플리케이션이 실제로 접근한 경로입니다.
• O_RDONLY: 읽기 전용으로 열려고 했습니다.
• -1 ENOENT: 호출이 실패했고, 커널은 파일이 없다고 답했습니다.

여기서 중요한 건 “설정 파일이 없다”가 아니라 “해당 프로세스의 파일 시스템 네임스페이스에서 그 경로가 없다”입니다. 호스트에는 파일이 있어도 컨테이너 안에는 없을 수 있고, systemd 서비스의 WorkingDirectory가 달라 상대 경로가 다르게 해석될 수 있습니다. Kubernetes라면 ConfigMap/Secret 마운트 경로와 컨테이너 이미지를 같이 봐야 합니다.

EACCES라면 방향이 바뀝니다. 파일 존재 여부보다 소유자, 그룹, 모드, 디렉터리 실행 권한, SELinux/AppArmor 정책을 봐야 합니다. 디렉터리 중간 경로에 실행 권한이 없어도 파일 접근은 실패합니다.

# 파일과 상위 디렉터리 권한을 함께 확인
namei -l /etc/myapp/config.yml

# systemd 서비스의 작업 디렉터리와 실행 사용자 확인
systemctl cat myapp.service
systemctl show myapp.service -p User -p Group -p WorkingDirectory

재현 가능한 시나리오 2: 연결 거부와 타임아웃을 구분하기

네트워크 장애에서 strace가 빛나는 지점은 connect()의 반환값입니다. “안 붙는다”는 말은 너무 넓습니다. 대상이 즉시 거부하는지, 네트워크 경로에서 시간이 빠지는지, DNS 이전 단계인지에 따라 담당 영역이 달라집니다.

# 로컬에서 열려 있지 않은 포트에 연결 시도
strace -tt -T -e trace=network curl -v --connect-timeout 3 http://127.0.0.1:9/

# DNS 해석까지 포함해 파일/네트워크 흐름을 함께 확인
strace -tt -T -e trace=file,network -s 256 curl -v --connect-timeout 3 https://example.com/

ECONNREFUSED는 대상 호스트까지 도달했지만 해당 포트가 거부했다는 쪽에 가깝습니다. 서비스가 안 떠 있거나, 다른 포트에 떠 있거나, 로컬 방화벽이 즉시 거부하는 식입니다. 반대로 ETIMEDOUT은 응답이 돌아오지 않는 흐름이라 라우팅, 보안 그룹, 방화벽 드롭, 네트워크 ACL을 의심합니다. 둘을 구분하지 않고 “네트워크 문제”라고 뭉개면 담당자도, 조사 순서도 흐려집니다.

strace 옵션 비교: 장애 유형별 조합을 외우는 편이 낫습니다

옵션을 백과사전처럼 외울 필요는 없습니다. 장애 유형별로 손에 익는 조합을 만들어두면 됩니다. 저는 아래 표를 기준으로 시작하고, 필요할 때만 넓힙니다.

옵션 선택의 핵심은 “무엇이 궁금한가”입니다. 파일이 궁금하면 trace=file, 네트워크면 trace=network, 자식 프로세스가 의심되면 -f, 흐름 공유가 필요하면 -o부터 붙이면 됩니다.

주의사항과 트러블슈팅: 실제 현장에서 자주 밟는 함정

권한 문제: Operation not permitted

다른 사용자의 프로세스에 붙을 때 Operation not permitted가 나올 수 있습니다. 우선 root 권한으로 실행합니다.

sudo strace -p 12345

그래도 막힌다면 ptrace 제한이나 컨테이너 보안 정책을 봐야 합니다. Ubuntu 계열에서는 /proc/sys/kernel/yama/ptrace_scope가 관련될 수 있습니다.

cat /proc/sys/kernel/yama/ptrace_scope

이 값을 낮추면 붙을 수 있는 범위가 넓어질 수 있지만, 보안 정책을 약하게 만드는 결정입니다. 운영 서버에서 임의로 바꾸기보다 승인된 디버그 절차, 동일 사용자 실행, 재현 환경, 디버그 컨테이너를 먼저 검토하는 편이 맞습니다.

로그가 너무 많아서 못 읽겠는 문제

전체 추적을 파일로 남기면 몇 초 만에도 읽기 어려운 양이 될 수 있습니다. 먼저 실패 호출만 보거나, 파일과 네트워크처럼 관심 범위를 좁힙니다.

# 파일 문제만 본다
sudo strace -f -e trace=file -e status=failed -s 256 -o /tmp/file.failed.log -p 12345

# 네트워크 문제만 본다
sudo strace -f -tt -T -e trace=network -s 256 -o /tmp/network.log -p 12345

# 요약 통계만 본다
strace -c curl -I https://example.com

futex가 많이 보이면 무조건 문제일까?

futex는 멀티스레드 애플리케이션에서 흔합니다. 많이 보인다는 사실만으로 장애라고 판단하면 안 됩니다. 중요한 건 맥락입니다. 요청 처리가 멈춘 상태에서 특정 스레드가 계속 futex 대기에 머물고, CPU 사용률은 낮고, 처리량이 떨어졌다면 락 경합이나 데드락 가능성을 봅니다. 이때 strace만으로 결론을 내리지 말고 스레드 단위 관찰을 같이 해야 합니다.

# 스레드별 CPU/상태 확인
top -H -p 12345

# 프로세스의 스레드 목록 확인
ps -L -p 12345 -o pid,tid,stat,comm

# Java라면 스레드 덤프와 함께 비교
jstack 12345 > /tmp/jstack.12345.txt

컨테이너에서는 strace가 안 붙는 경우

컨테이너 안에서 strace를 쓰려면 패키지가 없거나, ptrace 권한이 막혀 있거나, seccomp 프로파일 때문에 제한될 수 있습니다. 운영 정책이 허용한다면 디버그 컨테이너나 임시 권한 부여를 사용합니다.

# Docker에서 재현 환경을 만들 때의 예시
# 운영에 그대로 적용하기 전에 보안 정책을 반드시 확인하세요.
docker run --rm -it --cap-add SYS_PTRACE --security-opt seccomp=unconfined ubuntu:latest bash

Kubernetes에서는 노드 접근, ephemeral container, 보안 컨텍스트, 배포 조직의 운영 기준을 같이 봐야 합니다. 여기서 중요한 판단은 “운영 파드에 도구를 설치할지”가 아니라 “동일 증상을 낮은 위험으로 관찰할 방법이 있는지”입니다.

검증과 결과 해석: 에러 코드, 반복, 대기 시간을 분리해서 봅니다

strace 로그를 받을 때 저는 세 갈래로 읽습니다. 첫째, 실패 코드를 봅니다. 둘째, 같은 호출이 반복되는지 봅니다. 셋째, -T 기준으로 특정 호출이 오래 걸리는지 봅니다.

1. 실패 코드: ENOENT, EACCES, EPERM, ECONNREFUSED, ETIMEDOUT, EROFS 같은 반환값을 우선 확인합니다.
2. 반복 패턴: 같은 경로, 같은 포트, 같은 FD에 대한 호출이 짧은 간격으로 반복되는지 봅니다.
3. 대기 지점: -T 출력에서 connect, read, poll, epoll_wait, futex 뒤에 시간이 길게 붙는지 봅니다.

파일 문제는 openat()의 경로와 반환값이 거의 출발점입니다. ENOENT면 경로, 마운트, 작업 디렉터리, 배포 산출물을 봅니다. EACCES면 권한, 상위 디렉터리 실행 권한, SELinux/AppArmor, 컨테이너 사용자 UID를 봅니다. EROFS가 보이면 읽기 전용 파일 시스템이나 컨테이너 마운트 옵션 쪽입니다.

네트워크 문제는 connect() 반환값으로 먼저 나눕니다. ECONNREFUSED는 상대가 거부한 상황에 가깝고, ETIMEDOUT은 응답이 돌아오지 않는 상황에 가깝습니다. DNS 문제는 connect() 이전의 /etc/resolv.conf, /etc/hosts, NSS 관련 파일 접근 흐름에서 힌트가 나올 수 있습니다.

# strace 로그에서 자주 보는 실패만 빠르게 훑기
grep -E 'ENOENT|EACCES|EPERM|ECONNREFUSED|ETIMEDOUT|EROFS' /tmp/app.strace.log | head -100

# 특정 설정 파일 접근 여부 확인
grep '/etc/myapp/config.yml' /tmp/app.strace.log

# 오래 걸린 호출 후보를 눈으로 보기 쉽게 추리기
grep -E '<[0-9]+\.[0-9]+>' /tmp/app.strace.log | head -50

해석은 감이 아니라 분류입니다. 에러 코드로 범주를 나누고, 반복 패턴으로 재현성을 보고, 대기 시간으로 병목 후보를 좁히면 strace 로그가 훨씬 덜 거칠게 느껴집니다.

언제 strace를 쓰고, 언제 다른 도구를 먼저 써야 할까

strace는 강력하지만 모든 문제의 첫 번째 도구는 아닙니다. 시스템 콜 경계의 증거가 필요할 때 가장 좋고, 애플리케이션 내부 상태나 장기 성능 분석이 필요할 때는 다른 도구가 더 맞습니다.

n

제가 쓰는 기준은 단순합니다. “커널에 무엇을 요청했는지”가 질문이면 strace가 맞습니다. “코드 내부에서 왜 그 요청을 했는지”가 질문이면 로그, 디버거, 프로파일러, 스레드 덤프가 필요합니다.

자주 묻는 질문

strace를 운영 서버에서 써도 괜찮나요?

가능은 하지만 짧게 쓰는 쪽을 권합니다. -e trace=...로 범위를 줄이고, -o로 파일에 저장하고, 필요한 순간에만 붙이세요. 초당 시스템 콜이 많은 프로세스에 전체 추적을 오래 거는 방식은 피하는 편이 안전합니다.

애플리케이션 로그와 strace 중 무엇을 먼저 봐야 하나요?

대부분은 애플리케이션 로그가 먼저입니다. 로그에서 파일, 권한, 네트워크, 외부 프로세스 실행, 대기 상태가 의심될 때 strace로 내려가면 좋습니다. 처음부터 strace를 보면 단서보다 소음이 많을 수 있습니다.

컨테이너에서도 쓸 수 있나요?

쓸 수 있습니다. 다만 컨테이너 이미지에 strace가 없을 수 있고, SYS_PTRACE capability, seccomp, AppArmor, Kubernetes 보안 정책에 막힐 수 있습니다. 운영 파드에 직접 설치하기보다 디버그 컨테이너나 재현 환경을 먼저 고려하세요.

strace 로그에 민감정보가 남나요?

남을 수 있습니다. 파일 경로, 실행 인자, 소켓 주소, 일부 문자열 버퍼가 출력될 수 있습니다. -s 값을 크게 잡을수록 더 많은 문자열이 보입니다. 공유 전에는 토큰, 인증 헤더, 고객 데이터가 섞였는지 확인해야 합니다.

마무리: 장애 유형별로 이렇게 꺼내면 됩니다

strace는 “리눅스에서 애플리케이션이 실제로 무엇을 요청했는가”를 확인하는 도구입니다. 로그가 애매할 때, 커널의 반환값을 보면 문제가 갑자기 작아지는 순간이 있습니다.

파일 경로나 권한이 의심되면 strace -e trace=file -s 256로 시작하세요. 네트워크 연결 문제가 의심되면 strace -tt -T -e trace=network로 connect() 반환값을 보세요. 실행 중인 서비스가 멈춘 듯 보이면 sudo strace -f -tt -T -s 256 -o /tmp/app.strace.log -p PID 조합이 출발점으로 좋습니다. 자식 프로세스가 많으면 -ff로 PID별 로그를 분리하세요.

반대로 CPU 병목, 메모리 누수, 애플리케이션 내부 락 원인까지 strace 하나로 끝내려 하면 돌아갑니다. 그때는 perf, lsof, ss, 스레드 덤프, 언어별 프로파일러와 함께 봐야 합니다. 실무에서 중요한 건 도구 이름이 아니라 관찰 순서입니다. strace는 그 순서에서 “운영체제는 뭐라고 답했나”를 확인하는 가장 직접적인 렌즈입니다.

strace는 로그가 말해주지 않는 커널 레벨의 단서를 보여주는 실무형 디버깅 도구입니다. 짧게 붙이고, 질문을 좁히고, 반환값으로 다음 조사를 결정하세요.