돌미나리

서버를 운영하다 보면 "지금 CPU 점유율이 얼마지?", "어제 밤에 트래픽이 얼마나 몰렸을까?"와 같은 질문에 답해야 할 때가 많습니다. 매번 터미널에 접속해 htop을 입력하는 것은 번거로울 뿐만 아니라 과거의 데이터를 추적하기도 어렵습니다.

오늘은 오픈소스 모니터링의 표준이라 불리는 Prometheus(프로메테우스)와 시각화 도구인 Grafana(그라파나)를 연동하여, 누구나 한눈에 이해할 수 있는 멋진 서버 대시보드를 만드는 방법을 알아보겠습니다.

1. 모니터링 시스템의 두 주인공

1.1 Prometheus (데이터 수집기)

서버의 메트릭(Metric, 수치 데이터)을 수집하고 저장하는 역할을 합니다. "서버의 현재 CPU는 20%다"라는 정보를 일정 시간마다 가져와서 자신의 데이터베이스에 쌓아둡니다.

1.2 Grafana (데이터 시각화)

Prometheus가 수집한 딱딱한 숫자 데이터를 가져와 예쁜 그래프, 게이지, 차트로 그려주는 도구입니다. 커스터마이징이 매우 자유로워 나만의 관제 센터를 만들 수 있습니다.

2. 데이터의 원천: Node Exporter 설치

Prometheus가 서버의 하드웨어 정보를 읽어가려면, 서버 안에 정보를 내보내 주는 Node Exporter라는 작은 프로그램이 떠 있어야 합니다.

1. Node Exporter 설치:
2. Bash

    

   sudo apt update
   sudo apt install prometheus-node-exporter -y
   

3. 이제 9100번 포트를 통해 서버의 실시간 상태가 텍스트 형태로 출력되기 시작합니다.

3. Prometheus 및 Grafana 구축 (Docker 활용)

설치 과정을 단순화하기 위해 Docker Compose를 사용하는 것이 가장 효율적입니다.

3.1 docker-compose.yml 설정 예시

version: '3.8'
services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

4. Grafana에서 대시보드 구성하기

설치가 완료되었다면 http://서버IP:3000으로 접속합니다. (기본 계정: admin / admin)

4.1 데이터 소스 연결

• Configuration > Data Sources에서 Prometheus를 선택합니다.
• URL에 http://prometheus:9090을 입력하고 저장합니다.

4.2 대시보드 템플릿 가져오기 (꿀팁)

처음부터 그래프를 하나씩 그리는 것은 매우 어렵습니다. Grafana 커뮤니티에는 이미 잘 만들어진 템플릿이 많습니다.

1. Create > Import로 이동합니다.
2. 유명한 Linux 모니터링 템플릿 번호인 1860을 입력하고 로드합니다.
3. 순식간에 CPU 사용량, 메모리, 디스크 I/O, 네트워크 트래픽이 포함된 전문가용 대시보드가 완성됩니다!

5. 모니터링 시스템 도입의 효과

• 장애 선제 대응: 트래픽 증가 추이를 보고 서버 증설 시점을 미리 파악할 수 있습니다.
• 원인 분석: 장애가 발생했던 시점의 그래프를 되돌려 보며 무엇이 문제였는지 명확히 짚어낼 수 있습니다.
• 보고 및 공유: 복잡한 로그 대신 시각화된 그래프를 통해 팀원이나 클라이언트에게 시스템 상태를 직관적으로 설명할 수 있습니다.

6. 결론: 데이터 기반의 서버 운영

"측정할 수 없으면 관리할 수 없다"는 경영학의 격언은 서버 운영에도 그대로 적용됩니다. Prometheus와 Grafana는 여러분의 서버를 투명하게 들여다볼 수 있는 강력한 돋보기가 되어줄 것입니다.

공들여 만든 웹 서비스가 출시 당일, 예상보다 많은 사용자가 몰려 서버가 다운된다면 그보다 아찔한 상황은 없을 것입니다. 서버가 한 번에 얼마나 많은 요청을 처리할 수 있는지, 어느 정도의 동시 접속자 수에서 속도가 느려지는지 미리 파악하는 과정이 바로 **부하 테스트(Load Testing)**입니다.

오늘은 별도의 복잡한 설치 없이 Node.js 환경에서 간편하게 사용할 수 있는 부하 테스트 도구인 Artillery를 활용하여 내 서버의 체력을 측정하는 방법을 알아보겠습니다.

1. 부하 테스트(Load Testing)는 왜 필요한가?

부하 테스트는 단순히 서버를 괴롭히는 것이 아니라, 시스템의 **병목 지점(Bottleneck)**을 찾아내기 위해 수행합니다.

• 최대 수용 인원 파악: 현재 서버 사양(EC2 인스턴스 등)에서 동시 접속자 몇 명까지 안정적인지 확인합니다.
• 리소스 부족 지점 발견: CPU가 먼저 차오르는지, 메모리가 부족한지, 혹은 DB 연결 개수가 모자란지 파악합니다.
• Auto Scaling 기준 수립: 서버가 자동으로 늘어나야 하는 기준(CPU 70% 등)을 정하는 근거가 됩니다.

2. Artillery 설치 및 첫 테스트 시작

Artillery는 YAML 파일로 테스트 시나리오를 작성할 수 있어 매우 직관적입니다.

2.1 설치하기

npm을 통해 전역으로 설치하거나 npx로 바로 실행할 수 있습니다.

npm install -g artillery

2.2 간단한 명령어로 테스트하기

가장 기본적인 테스트는 명령어 한 줄로 가능합니다. 아래는 10명의 가상 사용자가 1초에 1번씩 총 100번의 요청을 보내는 예시입니다.

artillery quick --count 10 -n 100 https://your-api-domain.com

3. 시나리오 기반의 정밀 테스트 (YAML 설정)

실제 서비스와 유사한 환경을 만들기 위해 script.yml 파일을 작성하여 테스트를 수행하는 것이 좋습니다.

config:
  target: "https://api.example.com"
  phases:
    - duration: 60      # 60초 동안 테스트 진행
      arrivalRate: 5    # 초당 5명의 가상 사용자 투입 (평상시 트래픽)
    - duration: 120
      arrivalRate: 5
      rampTo: 50        # 2분 동안 초당 접속자를 50명까지 점진적으로 증가 (피크 타임)
  
scenarios:
  - name: "메인 페이지 접속 및 상품 상세 조회"
    flow:
      - get:
          url: "/"
      - think: 1        # 1초 대기 (사용자 행동 모의)
      - get:
          url: "/products/1"

3.3 테스트 실행 및 리포트 생성

artillery run -o report.json script.yml
# 결과를 HTML 리포트로 변환
artillery report report.json

4. 테스트 결과 해석하기 (지표 읽는 법)

테스트가 끝나면 터미널이나 HTML 리포트에 여러 수치가 나타납니다. 무엇을 중요하게 봐야 할까요?

• Scenarios created/completed: 생성된 가상 사용자가 요청을 모두 마치고 성공적으로 종료되었는지 확인합니다.
• RPS (Requests Per Second): 초당 처리량입니다. 서버가 초당 몇 개의 요청을 소화하는지 보여줍니다.
• Latency (p95, p99): 응답 속도입니다. p95가 500ms라면 전체 사용자 중 95%가 0.5초 이내에 응답을 받았음을 의미합니다. 이 수치가 급격히 올라가면 서버가 힘겨워하고 있다는 신호입니다.
• HTTP 2xx vs 5xx: 500번대 에러가 발생하기 시작하는 시점이 바로 내 서버의 한계치입니다.

5. 결론: 부하 테스트는 '신뢰'를 만드는 과정입니다

부하 테스트를 마쳤다면, 이제 "우리 서버는 동시 접속자 500명까지는 응답 속도 0.3초를 유지할 수 있습니다"라고 자신 있게 말할 수 있습니다. 수치화된 데이터는 인프라 증설이나 코드 최적화의 명확한 기준이 됩니다.

웹 서비스를 개발하다 보면, 새로운 기능을 배포하기 전에 실제 서버와 동일한 환경에서 미리 테스트해 볼 공간이 필요합니다. 이때 기존 도메인을 활용하여 dev나 test 같은 머리말을 붙인 서브도메인을 생성하면 비용 추가 없이 독립적인 환경을 구축할 수 있습니다.

오늘은 Route 53과 Nginx를 활용하여 하나의 도메인으로 여러 개의 서비스를 스마트하게 관리하는 방법을 알아보겠습니다.

1. 서브도메인이란 무엇인가?

서브도메인은 루트 도메인(Root Domain, 예: example.com)의 왼쪽에 마침표로 구분하여 추가하는 이름입니다.

• 운영 서버 (Production): www.example.com 또는 example.com
• 개발 서버 (Development): dev.example.com
• API 서버 (API): api.example.com

이들은 각각 서로 다른 IP 주소(다른 EC2 인스턴스)를 가리키거나, 한 서버 내에서 서로 다른 포트로 연결될 수 있습니다.

2. AWS Route 53에서 서브도메인 레코드 추가하기

가장 먼저 해야 할 일은 DNS 설정에서 서브도메인이 어디로 가야 할지 이정표를 세워주는 것입니다.

1. Route 53 호스팅 영역으로 이동합니다.
2. [레코드 생성] 버튼을 클릭합니다.
3. 레코드 이름: dev (원하는 서브도메인 이름)를 입력합니다.
4. 레코드 유형: A - IPv4 주소를 선택합니다.
5. 값: 개발용으로 사용할 서버의 IP 주소를 입력합니다.

이제 dev.your-domain.com을 입력하면 해당 IP의 서버로 접속 신호가 전달됩니다.

3. Nginx 서버 블록(Virtual Host) 설정

서버에 신호가 도착했다면, Nginx가 "이건 dev로 들어온 요청이니 이 폴더를 보여줘!"라고 판단할 수 있게 설정해야 합니다.

3.1 운영 서버와 개발 서버 설정 분리

/etc/nginx/sites-available/ 디렉토리에 각각의 설정 파일을 만듭니다.

운영 서버 설정 (my-app-prod):

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

    location / {
        proxy_pass http://localhost:3000; # 운영 포트
    }
}

개발 서버 설정 (my-app-dev):

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

    location / {
        proxy_pass http://localhost:4000; # 개발용 포트 또는 다른 폴더
    }
}

이렇게 server_name을 기반으로 요청을 분기하면 하나의 서버(Nginx) 안에서도 여러 서비스를 완벽히 분리하여 운영할 수 있습니다.

4. 서브도메인 활용의 장점

1. 비용 절감: 도메인을 추가로 구매할 필요가 없습니다.
2. 독립적인 테스트: 운영 중인 서비스에 영향을 주지 않고 새로운 기능을 마음껏 테스트할 수 있습니다.
3. 브랜드 통일성: 서비스의 성격에 따라 주소를 나누더라도 메인 도메인의 브랜드 가치를 유지할 수 있습니다.
4. SSL 통합 관리: Wildcard SSL 인증서(*.example.com)를 사용하면 모든 서브도메인에 한 번에 HTTPS를 적용할 수 있어 관리가 편리합니다.

5. 실무 꿀팁: 개발 서버 보안 강화

개발 서버(dev.)는 외부인에게 노출되어서는 안 되는 공간입니다. 서브도메인을 만들었다면 반드시 아래 설정을 추가하세요.

• IP 제한: 사내 IP나 본인의 IP에서만 접속할 수 있도록 Nginx 설정에서 allow 기능을 사용하세요.
• 검색 엔진 차단: 구글 봇이 개발 서버의 내용을 수집하지 않도록 robots.txt에 Disallow: / 설정을 추가하세요.
• 기본 인증: ID/PW를 입력해야 접속할 수 있는 HTTP Basic Auth를 걸어두는 것도 좋은 방법입니다.

6. 결론: 체계적인 배포 프로세스의 완성

서브도메인을 활용한 환경 분리는 단순한 기술을 넘어 배포의 안전성을 책임지는 중요한 전략입니다. 이제 dev 서버에서 충분히 테스트하고 확신이 섰을 때 www 서버로 코드를 옮기는 안전한 개발 문화를 시작해 보세요.

서버를 운영하다 보면 매일 특정 시간에 데이터베이스를 백업하거나, 매주 월요일마다 임시 파일을 정리해야 하는 상황이 생깁니다. 이런 반복적인 작업을 사람이 일일이 수동으로 하는 것은 비효율적일 뿐만 아니라 실수할 위험도 큽니다.

리눅스 시스템에는 이러한 작업을 예약하고 자동으로 실행해 주는 **크론(Cron)**이라는 강력한 도구가 있습니다. 오늘은 크론의 설정 파일인 **크론탭(Crontab)**의 문법부터 실전 활용 사례까지 상세히 알아보겠습니다.

1. 크론탭(Crontab)이란 무엇인가?

**크론(Cron)**은 리눅스용 시간 기반 잡 스케줄러입니다. 그리고 **크론탭(Crontab)**은 크론 작업(Cron Job)을 설정하는 테이블(Table) 형태의 파일을 말합니다.

사용자가 크론탭에 특정 시간과 실행할 명령어를 등록해 두면, 시스템은 백그라운드에서 대기하다가 정해진 시간에 맞춰 해당 명령을 자동으로 수행합니다.

2. 크론탭 기본 명령어

터미널에서 크론탭을 관리하기 위한 기본 명령어 3가지는 다음과 같습니다.

• crontab -e: 크론탭 설정을 편집합니다. (가장 많이 사용)
• crontab -l: 현재 예약된 크론 작업 목록을 출력합니다.
• crontab -r: 예약된 모든 크론 작업을 삭제합니다. (주의해서 사용)

3. 크론탭 주기 설정 문법 (별 5개의 의미)

크론탭 설정은 한 줄에 5개의 시간 단위와 실행할 명령어를 공백으로 구분하여 작성합니다.

* * * * * [실행할 명령어]
┬  ┬  ┬  ┬  ┬
│  │  │  │  └─ 요일 (0-6, 0:일요일)
│  │  │  └─ 월 (1-12)
│  │  └─ 일 (1-31)
│  └─ 시 (0-23)
└─ 분 (0-59)

3.1 실전 설정 예시

• 매분 실행: * * * * * /path/to/script.sh
• 매일 새벽 3시에 실행: 0 3 * * * /path/to/backup.sh
• 매주 월요일 오전 9시에 실행: 0 9 * * 1 /path/to/report.sh
• 10분마다 실행: */10 * * * * /path/to/check.sh
• 평일(월~금) 오후 6시에 실행: 0 18 * * 1-5 /path/to/work.sh

4. 크론탭 작성 시 주의사항 (트러블슈팅)

초보자들이 크론탭을 설정하고 가장 당황하는 순간은 "명령어가 제대로 실행되지 않을 때"입니다. 이를 방지하기 위한 팁입니다.

4.1 절대 경로 사용

크론은 일반적인 터미널 환경과 환경 변수(PATH)가 다릅니다. 따라서 python이나 node 같은 명령어를 쓸 때도 반드시 절대 경로를 사용해야 합니다.

• 잘못된 예: python3 script.py
• 올바른 예: /usr/bin/python3 /home/user/script.py

4.2 실행 로그 남기기

크론은 백그라운드에서 돌아가기 때문에 성공 여부를 알기 어렵습니다. 리다이렉션을 사용해 로그를 남기는 습관을 들이세요.

0 3 * * * /home/user/backup.sh >> /home/user/logs/cron.log 2>&1

4.3 권한 확인

실행하려는 스크립트 파일(.sh 등)에 실행 권한(chmod +x)이 있는지 확인해야 합니다.

5. 실전 활용 사례: DB 자동 백업 및 로그 정리

서버 관리자가 가장 흔히 사용하는 자동화 조합입니다.

# 매일 밤 12시에 DB 백업 스크립트 실행
0 0 * * * /home/user/scripts/db_backup.sh

# 매주 일요일 새벽 4시에 7일 지난 임시 파일 삭제
0 4 * * 0 find /tmp -mtime +7 -delete

6. 결론: 자동화로 서버 관리의 자유를 찾으세요

크론탭은 한 번 제대로 설정해 두면 서버가 돌아가는 동안 묵묵히 제 역할을 수행하는 든든한 조수입니다. 반복 업무를 자동화함으로써 여러분은 더 중요한 개발 업무에 집중할 수 있는 시간을 벌게 됩니다.

웹 서비스가 성장하여 방문자가 급증하면, 아무리 고성능인 단일 서버라도 물리적인 한계에 부딪히게 됩니다. 서버가 느려지거나 다운되는 것을 방지하기 위해 가장 먼저 고려해야 할 기술이 바로 **로드 밸런싱(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을 켜서 리소스 흐름을 체크해 보세요.