돌미나리

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

리눅스 시스템에는 이러한 작업을 예약하고 자동으로 실행해 주는 **크론(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. 결론: 자동화로 서버 관리의 자유를 찾으세요

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

서버를 운영하다 보면 원인 모를 에러로 서비스가 중단되는 상황을 맞이하게 됩니다. 이때 당황하지 않고 가장 먼저 확인해야 할 것이 바로 **로그(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)**을 획기적으로 줄여줍니다.

서버를 운영하다 보면 갑자기 웹사이트 응답이 느려지거나, 특정 프로세스가 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을 켜서 리소스 흐름을 체크해 보세요.

리눅스 서버를 운영하는 관리자나 개발자라면 누구나 한 번쯤 '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%를 넘을 때 알람을 받도록 설정하는 것이 가장 바람직합니다.

리눅스 서버(Ubuntu)를 처음 생성하고 공인 IP를 할당받으면, 그 순간부터 전 세계의 수많은 봇(Bot)들이 여러분의 서버에 접속하기 위해 무차별 대입 공격(Brute-force)을 시도합니다. 특히 기본 설정인 22번 포트와 root 계정은 해커들의 주요 타겟이 됩니다.

오늘은 내 소중한 서버를 안전하게 보호하기 위한 가장 기초적이면서도 필수적인 보안 설정 두 가지, SSH 포트 변경과 Root 로그인 차단 방법을 상세히 알아보겠습니다.

1. 왜 기본 설정을 변경해야 하는가?

서버 운영에 있어 '보안의 기본'은 공격자가 예측하기 어렵게 만드는 것입니다.

• SSH 기본 포트(22번): 누구나 알고 있는 포트입니다. 공격자들은 자동화된 스크립트로 22번 포트가 열려 있는지 확인하고 접속을 시도합니다. 포트 번호만 바꿔도 자동화 공격의 90% 이상을 차단할 수 있습니다.
• Root 계정: 리눅스에서 모든 권한을 가진 절대적인 계정입니다. ID가 'root'라는 것을 이미 알고 있기 때문에, 비밀번호만 알아내면 서버의 모든 제어권을 뺏기게 됩니다.

따라서 별도의 관리자 계정을 생성하고, root 접속은 원천 차단하는 것이 서버 보안의 시작입니다.

2. 작업 전 주의사항 (필독)

설정을 변경하다가 실수하면 **본인조차 서버에 접속하지 못하는 상황(Lock-out)**이 발생할 수 있습니다. 작업을 시작하기 전에 아래 사항을 반드시 확인하세요.

1. 관리자 권한을 가진 일반 사용자 계정이 미리 생성되어 있어야 합니다.
2. 사용 중인 클라우드(AWS, GCP, Azure 등)의 방화벽(Security Group) 설정에서 변경할 포트 번호를 미리 허용(Inbound)해 두어야 합니다.

3. SSH 설정 파일 수정하기

모든 SSH 관련 설정은 /etc/ssh/sshd_config 파일에서 관리합니다. 안전을 위해 원본 파일을 백업하고 수정을 시작해 보겠습니다.

3.1 설정 파일 백업 및 열기

# 설정 파일 백업
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# 설정 파일 편집 (nano 또는 vim 사용)
sudo nano /etc/ssh/sshd_config

3.2 SSH 포트 번호 변경

파일 상단 근처에 #Port 22라는 문구를 찾으세요. 주석(#)을 제거하고 원하는 포트 번호로 수정합니다.

• 추천 범위: 1024 ~ 65535 사이의 사용하지 않는 번호 (예: 2026, 8822 등)

# 수정 전
#Port 22

# 수정 후
Port 2026

3.3 Root 로그인 차단 설정

파일을 아래로 내리다 보면 PermitRootLogin 항목이 보입니다. 이를 no로 변경하여 외부에서 root 계정으로 직접 접속하는 것을 막습니다.

# 수정 전
#PermitRootLogin prohibit-password (또는 yes)

# 수정 후
PermitRootLogin no

4. 변경 사항 적용 및 테스트

설정을 마쳤다면 파일을 저장하고(Nano 기준: Ctrl+O -> Enter -> Ctrl+X), SSH 서비스를 재시작해야 적용됩니다.

4.1 서비스 재시작

sudo systemctl restart ssh

4.2 방화벽 설정 (UFW 기준)

서버 자체 방화벽인 UFW를 사용 중이라면 새 포트를 허용해 주어야 합니다.

# 새 포트 허용 (예: 2026)
sudo ufw allow 2026/tcp

# 기존 22번 포트 차단 (선택 사항)
sudo ufw delete allow 22/tcp

# 방화벽 상태 확인
sudo ufw status

5. 접속 테스트 (매우 중요!)

현재 접속되어 있는 터미널 창을 절대 끄지 마세요. 설정이 잘못되었을 경우를 대비해 현재 세션을 유지한 상태에서, 새로운 터미널 창을 열어 접속을 시도합니다.

# 새로운 터미널에서 접속 시도
ssh -p [변경한포트번호] [사용자계정]@[서버IP주소]

# 예시
ssh -p 2026 yumina@1.23.456.78

정상적으로 접속이 된다면 모든 설정이 성공적으로 완료된 것입니다. 이제 root 계정으로의 직접 접속은 차단되었으며, 지정한 포트를 통해서만 서버에 접근할 수 있습니다.

6. 결론 및 요약

서버 보안은 거창한 솔루션을 도입하는 것보다, 이처럼 기본적인 설정을 꼼꼼히 챙기는 것에서 시작됩니다.

오늘 배운 내용 요약:

1. SSH 포트 변경: 자동화된 봇 공격으로부터 서버를 은닉합니다.
2. PermitRootLogin no: 서버의 심장인 root 계정을 외부 노출로부터 보호합니다.
3. 방화벽 설정: 서버 내부와 클라우드 외부 방화벽 모두에서 새 포트를 열어주어야 합니다.

가장 단순하지만 가장 강력한 이 두 가지 설정을 통해 더욱 안전한 서버 운영 환경을 구축하시기 바랍니다.