이 글에서는 EC2 서버에서 로그가 기록되지 않는 주요 원인을 운영 관점에서 체계적으로 정리하고, 빠르게 점검할 수 있는 방법까지 함께 설명한다.

1. 애플리케이션 레벨 문제

가장 먼저 확인해야 할 것은 애플리케이션 자체의 로그 설정이다.

주요 원인

• 로그 레벨이 ERROR 이상으로 변경됨 (INFO 로그 미출력)
• 로그 파일 경로 변경 또는 잘못된 설정
• 로깅 라이브러리 오류 (logback, log4j 등)

점검 방법

• 설정 파일 확인 (logback.xml, application.yml)
• 최근 배포 이력 확인 (CI/CD 영향)
• 프로세스 재시작 여부 확인

특히 배포 이후 로그가 안 남는다면 코드/설정 변경 가능성이 가장 높다.

2. 디스크 용량 부족 (가장 흔한 원인)

EC2 운영에서 가장 흔한 케이스는 디스크가 꽉 차면서 로그 파일이 더 이상 기록되지 않는 상황이다.

주요 원인

• 로그 파일 누적 (log rotation 미설정)
• 임시 파일 증가 (/tmp, /var 등)
• 대용량 dump 파일 생성

점검 명령어

df -h
du -sh /var/log/*

해결 방법

• logrotate 설정 적용
• 오래된 로그 삭제
• 디스크 확장 (EBS 볼륨 증설)

디스크 100% 상태에서는 로그뿐 아니라 서비스 자체가 멈출 수 있다.

3. 권한(Permission) 문제

로그 파일은 정상적으로 생성되지만, 쓰기 권한이 없어서 기록이 실패하는 경우도 많다.

주요 원인

• 로그 디렉토리 권한 변경
• 실행 유저 변경 (ex: root → appuser)
• 컨테이너 환경에서 volume 권한 mismatch

점검 방법

ls -al /var/log/myapp

해결 방법

chown -R appuser:appuser /var/log/myapp
chmod 755 /var/log/myapp

4. 로그 로테이션(logrotate) 설정 오류

로그 관리 자동화를 위해 사용하는 logrotate 설정이 잘못된 경우 로그가 생성되지 않을 수 있다.

주요 원인

• logrotate 후 파일이 삭제되었지만 애플리케이션이 reopen하지 않음
• 잘못된 rotate 주기 설정
• copytruncate 옵션 누락

점검 방법

cat /etc/logrotate.d/myapp

특히 Java 애플리케이션은 로그 파일 핸들을 유지하기 때문에 설정 오류 시 로그가 멈춘 것처럼 보일 수 있다.

5. CloudWatch Agent 또는 로그 수집 에이전트 문제

EC2에서 로그를 Amazon CloudWatch로 전송하는 경우, 수집 에이전트 문제로 로그가 안 보일 수 있다.

주요 원인

• CloudWatch Agent 중지
• IAM Role 권한 문제
• 로그 경로 mismatch

점검 방법

systemctl status amazon-cloudwatch-agent

해결 방법

systemctl restart amazon-cloudwatch-agent

로컬에는 로그가 남지만 CloudWatch에 안 보이면 에이전트 문제 가능성 높음

6. 프로세스/서비스 비정상 상태

애플리케이션이 정상적으로 실행되지 않으면 로그도 생성되지 않는다.

주요 원인

• 프로세스 다운 (OOM, crash)
• 시스템 리소스 부족 (CPU, Memory)
• 커널 OOM Killer 작동

점검 방법

ps -ef | grep myapp
dmesg | grep -i kill

로그가 “갑자기 끊겼다”면 프로세스 종료 시점 확인이 중요하다.

7. 파일 디스크립터(File Descriptor) 한계 초과

리눅스 시스템에서 파일 오픈 수 제한을 초과하면 로그 파일도 생성되지 않는다.

주요 원인

• ulimit 설정 부족
• 대량 트래픽 환경에서 FD 고갈

점검 방법

ulimit -n
lsof | wc -l

해결 방법

ulimit -n 65535

8. 네트워크 파일 시스템(NFS/EFS) 이슈

로그를 EFS/NFS에 저장하는 경우, 네트워크 문제로 인해 로그 기록이 실패할 수 있다.

주요 원인

• 마운트 끊김
• 네트워크 지연
• 파일 시스템 lock

9. 빠른 장애 대응 체크리스트

운영 환경에서 즉시 확인해야 할 순서:

1. df -h → 디스크 상태 확인
2. ps -ef → 프로세스 상태 확인
3. 로그 파일 존재 여부 확인
4. CloudWatch Agent 상태 확인
5. 최근 배포 여부 확인
6. 권한 및 logrotate 설정 확인

이 순서대로 보면 대부분 5~10분 내 원인 파악 가능

결론

EC2 서버에서 로그가 갑자기 안 남는 문제는 단일 원인보다는 여러 계층(애플리케이션, OS, 인프라)의 복합 문제로 발생하는 경우가 많다.

특히 운영 환경에서는 로그 자체가 장애 분석의 핵심 데이터이기 때문에,

• 로그 로테이션
• 모니터링
• 디스크 관리
  를 사전에 설계하는 것이 중요하다.

결국 로그가 멈췄다는 것은 단순한 문제가 아니라 장애 대응 능력이 사라진 상태를 의미한다.

따라서 운영자는 항상 “로그가 정상적으로 남고 있는가”를 기본 헬스체크 지표로 관리해야 한다.

게시물 EC2 서버에서 로그가 갑자기 안 남는 원인 총정리 (운영자가 꼭 알아야 할 체크리스트)이 탑클스 - Top Click Spot에 처음 등장했습니다.

AWS EC2 인스턴스를 운영하다 보면 특별한 변경 작업이 없었는데도 서버가 갑자기 느려지는 상황을 겪게 된다. 웹 페이지 로딩이 지연되거나, API 응답 시간이 늘어나고, 내부 작업 처리 속도가 떨어지는 현상은 많은 운영자가 공통적으로 경험하는 문제다. 하지만 이런 현상의 대부분은 무작위로 발생하는 것이 아니라, 반복적으로 나타나는 원인이 존재한다. 원인을 구조적으로 이해하면 문제를 빠르게 파악하고 재발을 줄일 수 있다.

CPU 사용률 급증과 일시적 병목

EC2 인스턴스가 느려지는 가장 흔한 원인 중 하나는 CPU 사용률 급증이다. 트래픽이 갑자기 증가하거나, 특정 배치 작업이 동시에 실행되면 CPU가 순간적으로 포화 상태에 도달할 수 있다. CPU 사용률이 높아지면 요청 처리 대기 시간이 늘어나고, 서비스 응답이 지연된다.

특히 저사양 인스턴스에서는 작은 부하에도 CPU 병목이 쉽게 발생한다. CPU 사용률이 평소보다 장시간 높게 유지된다면 인스턴스 성능 자체가 현재 서비스 요구를 따라가지 못하고 있을 가능성이 크다.

메모리 부족으로 인한 성능 저하

메모리 부족 역시 EC2 인스턴스 성능 저하의 대표적인 원인이다. 메모리가 부족해지면 서버는 디스크를 대신 사용해 데이터를 처리하게 되는데, 이 과정에서 응답 속도가 급격히 느려진다. 심한 경우 일부 프로세스가 강제로 종료되거나 서비스가 비정상적으로 동작할 수 있다.

메모리 사용량은 갑자기 폭증하는 경우도 많다. 로그 누적, 캐시 증가, 특정 애플리케이션의 메모리 누수 등은 점진적으로 성능을 떨어뜨리는 주요 원인이다.

디스크 I/O 병목 현상

EC2 인스턴스에서 디스크 성능 문제는 체감 성능에 큰 영향을 준다. 디스크 읽기와 쓰기 작업이 많아지면 서버 전반의 처리 속도가 느려질 수 있다. 로그 파일 기록이 급격히 늘어나거나, 대용량 파일 처리 작업이 동시에 실행될 때 이런 문제가 자주 발생한다.

특히 스토리지 성능이 낮은 환경에서는 디스크 I/O 병목이 CPU와 메모리 문제처럼 보일 수 있어 원인 파악이 어려워진다.

네트워크 트래픽 증가와 대기 시간

AWS EC2 인스턴스는 네트워크를 통해 대부분의 작업을 수행한다. 외부 트래픽이 갑자기 늘어나거나, 내부 시스템과의 통신량이 증가하면 네트워크 대기 시간이 늘어날 수 있다. 이 경우 서버 자체 리소스는 여유가 있어도 전체 서비스는 느려진 것처럼 보인다.

네트워크 지연은 로그만 봐서는 파악하기 어려운 경우가 많기 때문에, 체감 성능 저하의 원인으로 자주 오해된다.

인스턴스 타입 선택의 한계

EC2 인스턴스 타입이 서비스 특성과 맞지 않는 경우에도 성능 저하가 발생한다. 처음에는 문제가 없던 인스턴스라도 서비스가 성장하면서 처리량이 증가하면 기존 사양으로는 감당하기 어려워진다. CPU 중심 작업, 메모리 중심 작업, 디스크 작업 비중에 따라 적합한 인스턴스 타입은 다르다.

인스턴스 타입이 현재 서비스 부하와 맞지 않으면 점진적인 성능 저하가 발생한다.

백그라운드 작업과 예약 작업의 영향

EC2 인스턴스에서 실행되는 백그라운드 작업이나 예약 작업도 성능 저하의 원인이 된다. 정기 백업, 로그 정리, 데이터 처리 작업이 사용자 요청 처리와 동시에 실행되면 리소스 경쟁이 발생한다. 이로 인해 평소보다 서버가 느려진 것처럼 느껴질 수 있다.

이러한 작업은 눈에 잘 띄지 않기 때문에 원인을 놓치기 쉽다.

스토리지 용량 부족에 따른 성능 문제

디스크 용량이 부족해지면 EC2 인스턴스는 정상적인 파일 처리와 로그 기록이 어려워진다. 이로 인해 서비스 응답이 느려지거나 오류가 발생할 수 있다. 디스크 용량 부족은 성능 저하뿐 아니라 장애로 이어질 수 있는 위험 요소다.

특히 로그와 임시 파일이 누적되는 환경에서는 디스크 사용량을 주기적으로 점검하지 않으면 갑작스러운 성능 저하를 겪게 된다.

운영체제와 애플리케이션 누적 문제

EC2 인스턴스를 장기간 재부팅 없이 운영하다 보면 운영체제나 애플리케이션 내부 상태로 인해 성능이 저하되는 경우도 있다. 프로세스가 비정상적으로 증가하거나, 리소스가 제대로 반환되지 않는 상황이 누적되면 서버가 점점 느려질 수 있다.

이 경우 단순한 재부팅으로 일시적으로 문제가 해결되기도 하지만, 근본 원인을 파악하지 않으면 동일한 문제가 반복된다.

모니터링 부재로 인한 대응 지연

서버가 느려졌을 때 가장 큰 문제는 원인을 즉시 파악하지 못하는 것이다. CPU, 메모리, 디스크, 네트워크 상태를 지속적으로 확인하지 않으면 문제는 감으로 판단할 수밖에 없다. 이로 인해 대응이 늦어지고, 성능 저하가 장기화된다.

EC2 인스턴스 성능 문제의 상당수는 모니터링 부재로 인해 키워진다.

AWS EC2 인스턴스 성능 저하 원인 정리

AWS EC2 인스턴스가 갑자기 느려지는 원인은 대부분 CPU, 메모리, 디스크, 네트워크 같은 기본 리소스와 관련되어 있다. 인스턴스 타입 선택, 백그라운드 작업, 스토리지 관리, 운영 습관까지 함께 영향을 미친다. 중요한 것은 문제가 발생했을 때 즉각적인 재부팅이나 임시 조치에 의존하기보다, 원인을 구조적으로 이해하고 재발을 방지하는 것이다.

EC2 인스턴스 성능 저하의 원인을 체계적으로 이해하면, 서버 운영 안정성과 서비스 품질을 동시에 개선할 수 있다. 서버가 느려졌을 때 당황하기보다, 이 기본 원인들부터 차분히 점검하는 것이 가장 효과적인 대응 방법이다.

게시물 AWS EC2 인스턴스가 갑자기 느려지는 가장 흔한 원인들이 탑클스 - Top Click Spot에 처음 등장했습니다.