돌미나리

서버를 운영하다 보면 원인 모를 에러로 서비스가 중단되는 상황을 맞이하게 됩니다. 이때 당황하지 않고 가장 먼저 확인해야 할 것이 바로 **로그(Log)**입니다. 하지만 로그를 단순히 쌓아두기만 하면, 어느덧 수십 GB로 커진 로그 파일이 디스크 용량을 점유하여 오히려 서버를 멈추게 하는 원인이 되기도 합니다.

오늘은 리눅스 서버에서 에러 로그를 스마트하게 확인하는 방법과, 로그 파일을 효율적으로 관리해 주는 logrotate 설정법을 상세히 알아보겠습니다.

1. 실시간으로 에러 로그 추적하기: tail 명령어

문제가 발생한 순간, 실시간으로 어떤 메시지가 찍히는지 확인하는 것이 급선무입니다. 이때 가장 유용한 명령어가 tail -f입니다.

1.1 Nginx 에러 로그 확인 예시

sudo tail -f /var/log/nginx/error.log

• -f (follow): 파일의 끝부분을 실시간으로 계속 보여줍니다. 브라우저에서 새로고침을 할 때마다 찍히는 에러를 즉각 확인할 수 있습니다.

1.2 특정 키워드로 필터링하기 (grep)

로그 양이 너무 많을 때는 grep을 조합하여 필요한 정보만 골라냅니다.

sudo tail -f /var/log/nginx/error.log | grep "Critical"

2. 로그 관리의 핵심: logrotate란?

로그는 매일 생성되지만, 모든 과거 로그를 하나의 파일에 보관하는 것은 비효율적입니다. logrotate는 리눅스 시스템 도구로, 로그 파일을 주기적으로 분할(Rotation), 압축(Compression), 삭제(Removal)하여 디스크 공간을 확보해 줍니다.

2.1 logrotate 작동 원리

1. 로그 분할: error.log를 error.log.1로 이름을 바꾸고 새 파일을 만듭니다.
2. 압축: error.log.1을 error.log.2.gz 형태로 압축하여 용량을 줄입니다.
3. 순환: 설정된 개수(예: 7개)가 넘어가면 가장 오래된 로그를 자동으로 삭제합니다.

3. logrotate 실전 설정 가이드

대부분의 주요 서비스(Nginx, MySQL 등)는 설치 시 logrotate 설정이 자동으로 생성됩니다. 하지만 본인이 만든 애플리케이션 로그를 관리하려면 직접 설정 파일을 만들어야 합니다.

3.1 설정 파일 생성

/etc/logrotate.d/ 디렉토리에 서비스 이름으로 파일을 생성합니다.

sudo nano /etc/logrotate.d/my-app

3.2 설정 내용 예시

/var/www/my-app/logs/*.log {
    daily                   # 매일 실행
    missingok               # 로그 파일이 없어도 에러 내지 않음
    rotate 14               # 최대 14일치 로그 보관
    compress                # 이전 로그 압축(.gz)
    delaycompress           # 현재 분할된 파일은 다음 주기에 압축
    notifempty              # 로그가 비어있으면 로테이트 하지 않음
    create 0640 www-data adm # 새 로그 파일 권한 설정
    sharedscripts
    postrotate
        # 로그 분할 후 서비스 재시작 명령 (필요 시)
        /usr/bin/systemctl reload nginx > /dev/null 2>&1
    endscript
}

4. 설정 테스트 및 강제 실행

설정이 올바른지 확인하고 싶다면 아래 명령어로 테스트해 볼 수 있습니다.

# 설정 파일 문법 체크 (드라이 런)
sudo logrotate -d /etc/logrotate.d/my-app

# 조건에 상관없이 즉시 로테이트 실행
sudo logrotate -f /etc/logrotate.d/my-app

5. 결론: 로그는 읽기 위해 존재한다

로그 관리는 단순히 디스크 용량을 아끼는 기술이 아닙니다. 깨끗하게 정리된 로그는 장애 발생 시 **평균 복구 시간(MTTR)**을 획기적으로 줄여줍니다.

웹 서비스가 성장하여 방문자가 급증하면, 아무리 고성능인 단일 서버라도 물리적인 한계에 부딪히게 됩니다. 서버가 느려지거나 다운되는 것을 방지하기 위해 가장 먼저 고려해야 할 기술이 바로 **로드 밸런싱(Load Balancing)**입니다.

오늘은 오픈소스 웹 서버인 Nginx를 활용하여 여러 대의 서버로 부하를 분산하고, 서비스의 가용성을 극대화하는 방법을 상세히 알아보겠습니다.

1. 로드 밸런싱(Load Balancing)이란?

로드 밸런싱은 말 그대로 '부하(Load)'를 여러 대의 서버에 '균형 있게(Balancing)' 나누는 기술입니다. 사용자의 요청이 집중될 때, 앞단에 위치한 로드 밸런서가 뒤에 대기 중인 여러 대의 애플리케이션 서버로 요청을 배분합니다.

1.1 로드 밸런싱의 주요 목적

• 고가용성(High Availability): 특정 서버에 장애가 발생해도 다른 서버가 요청을 처리하여 중단 없는 서비스를 제공합니다.
• 확장성(Scalability): 트래픽 증가 시 서버 대수만 늘리면 되므로 유연한 대응이 가능합니다.
• 성능 최적화: 서버 한 대에 가해지는 부담을 줄여 응답 속도를 향상시킵니다.

2. Nginx 로드 밸런싱 핵심 설정법

Nginx에서는 upstream 블록을 사용하여 로드 밸런싱 그룹을 정의합니다.

2.1 기본 설정 예시 (Round Robin)

가장 기본적인 방식으로, 서버들에 순차적으로 요청을 배분합니다.

http {
    # 백엔드 서버 그룹 정의
    upstream my_backend_servers {
        server 10.0.0.1:3000;
        server 10.0.0.2:3000;
        server 10.0.0.3:3000;
    }

    server {
        listen 80;
        server_name your-domain.com;

        location / {
            # 위에서 정의한 upstream 그룹으로 요청 전달
            proxy_pass http://my_backend_servers;
            
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

2.2 주요 부하 분산 알고리즘

서비스의 성격에 따라 적절한 알고리즘을 선택할 수 있습니다.

• Round Robin (기본값): 순서대로 균등 배분.
• Least Connections (least_conn): 현재 연결 수가 가장 적은 서버로 요청을 보냅니다. 작업 시간이 긴 요청이 많을 때 유리합니다.
• IP Hash (ip_hash): 사용자의 IP를 해싱하여 항상 동일한 서버로 연결합니다. 세션 유지가 필요한 서비스에 적합합니다.
• Weight (가중치): 성능이 더 좋은 서버에 더 많은 요청을 보내도록 설정합니다. (server 10.0.0.1:3000 weight=3;)

3. 장애 감지와 복구 (Health Check)

Nginx 로드 밸런서의 강력한 기능 중 하나는 백엔드 서버의 상태를 체크하는 것입니다.

upstream my_backend_servers {
    # 3번 실패하면 30초 동안 해당 서버를 제외함
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
}

이 설정을 통해 특정 서버가 다운되었을 때 사용자가 에러 페이지를 보는 대신, 정상 작동하는 다른 서버의 응답을 받을 수 있도록 자동 제어가 가능합니다.

4. 실무 도입 시 고려사항: 세션 동기화

로드 밸런싱을 도입할 때 가장 주의해야 할 점은 세션(Session) 관리입니다. 사용자가 A 서버에서 로그인했는데, 다음 클릭 시 B 서버로 연결되면 로그인이 풀리는 현상이 발생합니다.

이를 해결하기 위해 다음과 같은 방법을 사용합니다.

1. Sticky Session: ip_hash를 사용하여 사용자를 특정 서버에 고정시킵니다.
2. External Session Store: 세션 정보를 서버 메모리가 아닌 외부 저장소(예: Redis)에 저장하여 모든 서버가 공유하게 합니다. (권장 방식)

5. 결론: 더 큰 서비스를 향한 도약

Nginx 로드 밸런싱 설정은 단순한 서버 운영을 넘어 '시스템 아키텍처'를 설계하는 첫걸음입니다. 초기 비용 없이 소프트웨어 설정만으로 대규모 트래픽에 대응할 수 있다는 점은 큰 매력입니다.

서버를 운영하다 보면 갑자기 웹사이트 응답이 느려지거나, 특정 프로세스가 CPU를 100% 점유하여 시스템이 멈추는 상황을 겪게 됩니다. 이때 가장 먼저 해야 할 일은 "지금 내 서버에서 무슨 일이 벌어지고 있는가?"를 파악하는 것입니다.

오늘은 리눅스 서버 모니터링의 핵심 도구인 top과 그 상위 호환 버전인 htop을 활용하여 시스템 부하의 원인을 진단하는 방법을 상세히 알아보겠습니다.

1. 리눅스 기본 모니터링: top 명령어

top은 모든 리눅스 배포판에 기본으로 내장된 실시간 프로세스 모니터링 도구입니다.

1.1 top 실행 및 화면 읽기

터미널에 top을 입력하면 상단에 시스템 전체 요약 정보가 나타납니다.

• load average: 최근 1분, 5분, 15분 동안의 평균 작업 대기 수입니다. 코어 수보다 높다면 서버가 과부하 상태임을 의미합니다.
• %CPU(s): us(사용자), sy(시스템), id(유휴) 등의 상태를 보여줍니다. id값이 낮을수록 서버가 바쁘게 돌아가고 있다는 뜻입니다.
• KiB Mem: 전체 메모리 사용량과 여유 공간을 보여줍니다.

1.2 유용한 단축키

• P: CPU 사용량이 높은 순으로 정렬
• M: 메모리 사용량이 높은 순으로 정렬
• k: 특정 프로세스 종료 (PID 입력 필요)
• q: 프로그램 종료

2. 시각화된 강력한 도구: htop

top이 텍스트 위주라 가독성이 떨어진다면, **htop**은 컬러풀한 그래프와 직관적인 인터페이스를 제공하는 상위 호환 도구입니다.

2.1 htop 설치하기

대부분의 서버에는 기본 설치되어 있지 않으므로 별도로 설치해야 합니다.

sudo apt update
sudo apt install htop -y

2.2 htop의 장점

• 직관적인 바(Bar) 그래프: 각 CPU 코어별 점유율과 메모리 사용량을 시각적으로 보여줍니다.
• 마우스 지원: 터미널 환경에서도 마우스 클릭으로 프로세스를 선택하고 정렬할 수 있습니다.
• 트리 보기 (F5): 프로세스 간의 부모-자식 관계를 한눈에 파악하여 어떤 서비스가 리소스를 잡아먹는지 쉽게 알 수 있습니다.

3. 서버 부하의 3대 원인 진단법

상태 창을 열었을 때, 무엇을 중점적으로 봐야 할까요?

3.1 CPU 사용량이 너무 높을 때 (High CPU)

특정 프로세스가 연산 처리를 과도하게 하고 있는 경우입니다. 보통 무한 루프에 빠진 스크립트나 복잡한 계산 작업이 원인입니다. htop에서 %CPU 열을 확인하여 해당 프로세스를 최적화하거나 종료해야 합니다.

3.2 메모리 스왑 발생 (High Memory & Swap)

물리 메모리(RAM)가 부족하여 디스크의 일부를 메모리처럼 사용하는 '스왑(Swap)' 현상이 발생하면 서버 속도가 급격히 저하됩니다. htop 상단의 Swp 게이지가 차오르고 있다면 메모리 증설이나 캐시 정리(예: Redis 데이터 정리)가 필요합니다.

3.3 I/O Wait (Wait 상태)

CPU 점유율은 낮은데 서버가 느리다면 디스크 읽기/쓰기 속도가 병목 현상을 일으키는 것입니다. top의 %wa 수치가 높다면 데이터베이스 쿼리 최적화나 디스크 성능 점검이 우선입니다.

4. 실무 꿀팁: 특정 사용자 프로세스만 보기

서버에 여러 사용자가 접속해 있다면, 내 계정이 실행한 프로세스만 필터링해서 보는 것이 효율적입니다.

# htop 실행 후 'u'를 누르거나 아래 명령어로 실행
htop -u [사용자이름]

# 예시
htop -u yumina

5. 결론: 상시 모니터링의 중요성

서버 장애는 예고 없이 찾아오지만, top과 htop을 활용하는 습관을 들이면 사고를 미연에 방지할 수 있습니다. 서버가 평소보다 조금이라도 무겁게 느껴진다면 바로 htop을 켜서 리소스 흐름을 체크해 보세요.

웹 서비스의 사용자가 늘어남에 따라 데이터베이스(DB)에 가해지는 부하도 기하급수적으로 증가합니다. 매번 똑같은 데이터를 조회하기 위해 무거운 디스크 기반 DB(MySQL, PostgreSQL 등)를 거치는 것은 비효율적입니다.

오늘은 메모리 기반의 데이터 저장소인 **Redis(Remote Dictionary Server)**를 도입하여 시스템의 응답 속도를 혁신적으로 개선하고, DB의 부담을 덜어주는 캐시 서버 구축 방법을 알아보겠습니다.

1. Redis란 무엇이며 왜 필요한가?

Redis는 '인메모리(In-memory)' 데이터 구조 저장소입니다. 데이터를 디스크가 아닌 RAM에 저장하기 때문에 읽기/쓰기 속도가 압도적으로 빠릅니다.

1.1 캐싱 전략: Look-Aside 패턴

가장 많이 사용되는 방식은 클라이언트가 데이터를 요청할 때, 먼저 Redis(캐시)에 데이터가 있는지 확인하는 것입니다.

1. Cache Hit: Redis에 데이터가 있다면 즉시 반환 (매우 빠름)
2. Cache Miss: Redis에 없다면 DB에서 조회 후 Redis에 저장하고 반환

이 과정을 통해 반복적인 DB 쿼리를 줄여 전체적인 서비스 성능을 최적화할 수 있습니다.

2. Ubuntu에서 Redis 설치 및 초기 설정

이제 실습을 통해 서버에 Redis를 설치해 보겠습니다.

2.1 패키지 설치

sudo apt update
sudo apt install redis-server -y

2.2 설정 파일 최적화

Redis의 동작 방식을 제어하기 위해 설정 파일을 수정합니다.

sudo nano /etc/redis/redis.conf

• 메모리 제한 설정: 서버의 전체 메모리를 다 쓰지 않도록 제한을 둡니다.(LRU 정책은 메모리가 가득 찼을 때 가장 오래 사용되지 않은 데이터를 삭제하여 공간을 확보합니다.)
• Plaintext

   

  maxmemory 256mb
  maxmemory-policy allkeys-lru
  

2.3 서비스 재시작 및 확인

sudo systemctl restart redis-server
sudo systemctl status redis-server

3. Redis CLI를 이용한 데이터 조작 기초

설치가 완료되었다면 redis-cli를 통해 간단한 명령어를 연습해 볼 수 있습니다. Redis는 Key-Value 쌍으로 데이터를 저장합니다.

• 데이터 저장: set user:1 "Yumina"
• 데이터 조회: get user:1
• 만료 시간 설정(중요): setex session:key 3600 "data" (3600초 뒤에 자동으로 데이터가 삭제되도록 설정하여 메모리를 효율적으로 관리합니다.)

4. 실무 도입 시 주의사항 (Best Practice)

Redis는 강력하지만, 잘못 사용하면 데이터 유실이나 메모리 부족 문제가 발생할 수 있습니다.

1. 휘발성 데이터 위주로 저장: Redis는 메모리 기반이므로 서버가 꺼지면 데이터가 사라질 수 있습니다. 사라져도 다시 DB에서 불러올 수 있는 '캐시' 용도로 사용하는 것이 가장 안전합니다.
2. 보안 설정: Redis의 기본 포트(6379)는 외부 공격에 취약할 수 있습니다. 반드시 redis.conf에서 비밀번호(requirepass)를 설정하고, 방화벽을 통해 허용된 IP만 접속 가능하게 제한하세요.
3. 적절한 만료 시간(TTL): 모든 데이터에 적절한 유효 기간을 설정하여 메모리 파편화를 방지해야 합니다.

5. 결론: 빠르고 견고한 서버를 위한 선택

Redis 도입은 현대 백엔드 아키텍처에서 선택이 아닌 필수 과정 중 하나입니다. 단순한 캐시 서버를 넘어 세션 관리, 실시간 랭킹 시스템, 메시지 큐 등 활용도가 무궁무진합니다.

웹사이트를 운영하면서 주소창 옆에 있는 '자물쇠 아이콘'은 이제 선택이 아닌 필수입니다. HTTPS가 적용되지 않은 사이트는 구글 검색 순위에서 밀려날 뿐만 아니라, 사용자들에게 '안전하지 않음' 경고를 표시하여 신뢰도를 떨어뜨리기 때문입니다.

오늘은 Let's Encrypt를 사용하여 무료로 SSL 인증서를 발급받고, 90일마다 돌아오는 갱신 과정을 Certbot을 이용해 완전히 자동화하는 방법을 상세히 알아보겠습니다.

1. Let's Encrypt와 Certbot이란?

Let's Encrypt는 누구나 무료로 SSL/TLS 인증서를 발급받을 수 있도록 지원하는 비영리 인증 기관(CA)입니다. 그리고 Certbot은 이 Let's Encrypt 인증서를 자동으로 발급, 설치, 갱신해 주는 오픈소스 소프트웨어 도구입니다.

1.1 왜 자동 갱신이 필요한가?

Let's Encrypt 인증서의 유효 기간은 90일로 매우 짧습니다. 이는 보안성을 높이기 위함이지만, 관리자가 매번 수동으로 갱신하기에는 번거롭고 실수로 만료될 위험이 큽니다. 따라서 자동화 설정을 통해 신경 쓰지 않아도 인증서가 유지되도록 하는 것이 핵심입니다.

2. 사전 준비 사항

작업을 시작하기 전에 아래 두 가지 조건이 충족되어야 합니다.

1. 도메인 보유: IP 주소가 아닌 실제 도메인(example.com)이 서버의 공인 IP와 연결되어 있어야 합니다.
2. 웹 서버 설치: Nginx 또는 Apache가 서버에 설치되어 동작 중이어야 합니다.

3. Certbot 설치 및 인증서 발급 (Nginx 기준)

Ubuntu 서버 환경에서 Nginx를 위한 Certbot 설정을 진행해 보겠습니다.

3.1 Certbot 설치

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

3.2 인증서 발급 및 자동 설정

아래 명령어를 입력하면 Certbot이 Nginx 설정 파일을 자동으로 분석하여 SSL 설정을 추가해 줍니다.

sudo certbot --nginx -d your-domain.com -d www.your-domain.com

• 이메일 입력: 만료 알림을 받을 이메일 주소를 입력합니다.
• 약관 동의: A를 눌러 동의합니다.
• HTTPS 리다이렉트: 기존 HTTP 접속을 자동으로 HTTPS로 넘길지 묻는 질문에는 2 (Redirect)를 선택하는 것을 권장합니다.

4. SSL 자동 갱신 설정 및 검증

Certbot은 설치 시 자동으로 시스템 스케줄러(cron 또는 systemd timer)에 갱신 스크립트를 등록합니다. 하지만 실제로 잘 작동하는지 확인하는 과정이 필요합니다.

4.1 드라이 런(Dry Run) 테스트

실제로 갱신을 수행하지 않고, 절차상 문제가 없는지 가상으로 테스트합니다.

sudo certbot renew --dry-run

결과 메시지에 **"Congratulations, all simulated renewals succeeded"**라는 문구가 보인다면 자동 갱신 설정에 문제가 없는 것입니다.

4.2 스케줄러 확인

인증서 갱신 작업이 등록되어 있는지 확인하려면 아래 명령어를 입력하세요.

systemctl list-timers | grep certbot

5. SSL 보안 등급 확인하기 (전문성 강화)

인증서 설치가 완료되었다면, 내 사이트의 보안 설정이 얼마나 견고한지 테스트해 볼 수 있습니다. SSL Labs 사이트에 접속하여 본인의 도메인을 입력하면 보안 등급(A~F)을 확인할 수 있습니다.

Nginx에서 최신 암호화 프로토콜(TLS 1.2, 1.3)만 사용하도록 설정하면 손쉽게 A 등급을 획득할 수 있으며, 이는 구글 SEO 점수에도 긍정적인 영향을 미칩니다.

6. 결론: 안전한 웹 서비스의 완성

무료 인증서라고 해서 유료 인증서보다 보안성이 떨어지는 것은 아닙니다. Let's Encrypt와 Certbot을 조합하면 비용 부담 없이 완벽한 HTTPS 환경을 구축할 수 있습니다.

요약하자면:

1. Certbot으로 간편하게 인증서를 발급받으세요.
2. --dry-run 테스트를 통해 자동 갱신 설정을 꼭 검증하세요.
3. 보안 등급을 체크하여 최적의 서버 설정을 유지하세요.

리눅스 서버를 운영하는 관리자나 개발자라면 누구나 한 번쯤 'Disk Full' 메시지와 함께 서버가 먹통이 되는 아찔한 경험을 하게 됩니다. 로그 파일이 감당할 수 없을 정도로 커졌거나, 나도 모르는 사이에 임시 파일이 쌓여 소중한 디스크 자원을 잠식하기 때문입니다.

오늘은 서버 용량 부족 문제를 해결하기 위해, 어떤 디렉토리가 용량을 많이 차지하고 있는지 범인을 찾아내는 핵심 명령어와 효율적인 관리 팁을 정리해 보겠습니다.

1. 전체 디스크 사용량 확인: df 명령어

가장 먼저 해야 할 일은 서버 전체의 디스크 상태를 파악하는 것입니다. 이때 사용하는 명령어가 df (disk free)입니다.

1.1 df -h 활용하기

단순히 df만 입력하면 바이트 단위로 출력되어 읽기 어렵습니다. -h (human-readable) 옵션을 추가하여 GB, MB 단위로 확인하세요.

df -h

• Filesystem: 파티션 이름
• Size: 전체 용량
• Used: 사용 중인 용량
• Avail: 남은 용량
• Use%: 사용률 (이 수치가 90%를 넘었다면 즉시 조치가 필요합니다.)

2. 특정 디렉토리 용량 확인: du 명령어

어떤 파티션이 가득 찼는지 확인했다면, 이제 구체적으로 어떤 폴더가 범인인지 찾아야 합니다. 이때 du (disk usage) 명령어를 사용합니다.

2.1 하위 디렉토리별 용량 요약 (du -sh)

현재 디렉토리의 전체 합계 용량만 보고 싶을 때 사용합니다.

du -sh .

2.2 깊이 조절하여 확인하기 (--max-depth)

루트(/) 디렉토리부터 하위 1단계 폴더들의 용량을 한눈에 보고 싶을 때 유용합니다.

sudo du -h --max-depth=1 / | sort -hr

• sort -hr: 용량이 큰 순서대로 정렬하여 출력합니다. 이 명령어를 통해 /var/log나 /tmp 중 어디가 문제인지 바로 파악할 수 있습니다.

3. 리눅스 서버의 용량 도둑, 주요 타겟 3곳

디스크 용량을 많이 잡아먹는 대표적인 디렉토리는 보통 정해져 있습니다.

3.1 /var/log (시스템 및 서비스 로그)

애플리케이션의 디버그 로그가 무한정 쌓이거나, syslog가 거대해지는 경우가 많습니다.

• 해결책: logrotate 설정을 통해 오래된 로그는 압축하거나 삭제하도록 설정하세요.

3.2 /tmp (임시 파일)

시스템이나 프로그램이 실행 중에 생성한 임시 파일들이 삭제되지 않고 남는 경우입니다.

• 해결책: 재부팅 시 자동으로 삭제되거나, 주기적으로 오래된 파일을 정리하는 스크립트를 실행하세요.

3.3 Docker 관련 데이터 (/var/lib/docker)

도커를 사용 중이라면 사용하지 않는 이미지, 컨테이너, 볼륨이 상당한 용량을 차지합니다.

• 해결책: 아래 명령어로 쓰지 않는 자원을 일괄 정리하세요.

docker system prune -a --volumes

4. 실무 꿀팁: 큰 파일 한 번에 찾기 (find)

디렉토리 단위가 아니라, 특정 크기(예: 500MB) 이상의 '대용량 파일'만 골라내고 싶을 때 find 명령어가 제격입니다.

sudo find / -type f -size +500M -exec ls -lh {} \;

이 명령어는 전체 파일 시스템에서 500MB가 넘는 파일들의 목록과 상세 정보를 출력해 줍니다.

5. 결론: 예방이 최선의책입니다

디스크 용량 문제는 서비스 중단으로 이어지는 치명적인 사고입니다. 사고가 터진 후 대응하는 것도 중요하지만, 모니터링 시스템(Prometheus, Grafana 등)을 구축하여 사용률이 80%를 넘을 때 알람을 받도록 설정하는 것이 가장 바람직합니다.