17강 / 20강

로그 — 서버가 남긴 일기

무슨 일이 있었는지는 항상 기록에 남아 있습니다

"사이트가 안 돼요!" 라는 연락을 받았습니다. 무엇부터 해야 할까요?

초보자는 서버를 재부팅합니다. 관리자는 로그를 읽습니다.

리눅스 서버는 모든 일을 기록으로 남깁니다. 누가 접속했는지, 어떤 요청이 왔는지, 무엇이 실패했는지. 읽는 법만 알면 대부분의 문제는 5분 안에 원인이 나옵니다.

고등학생서버가 남긴 일기

서버에 문제가 생기면 가장 먼저 볼 곳입니다.

무슨 일이 있었는지는 항상 기록에 남아 있다

로그가 답하는 것

물음	로그에서
언제부터 이상한가	시각
무엇이 실패했나	오류 메시지
누가 했나	IP · 사용자
왜 죽었나	종료 직전 줄

"언제부터" 를 아는 것이 절반이다

왜 시각이 중요한가

그 시각에 무엇을 바꿨는지 를 대조할 수 있으니까요.

발견	추론
오후 3시부터 오류	3시에 배포했나?
매일 새벽 3시	cron 이 뭘 하나? (19강)
부하가 높을 때만	자원 문제 (18강)

패턴이 보이면 원인이 좁혀진다

주요 로그 위치

경로	담는 것
`/var/log/syslog`	시스템 전반
`/var/log/auth.log`	로그인 · sudo
`/var/log/nginx/`	웹 접속 · 오류
`journalctl -u 서비스`	systemd 서비스

4강의 /var 는 "변하는 것" — 로그가 여기 있는 이유

서버의 일기장들이 모여 있는 곳

bash 내 가상 Ubuntu 서버에서 실행

sudo ls -lh /var/log/

/var/log/syslog시스템 전반온갖 것이 다 들어옴

/var/log/auth.log로그인·sudo 기록보안 점검의 출발점

/var/log/nginx/access.log누가 뭘 요청했나모든 방문 기록

/var/log/nginx/error.lognginx 오류502 의 진짜 이유

journalctl -u 서비스서비스별 로그systemd 가 모아 둔 것

고등학생로그는 대부분 root 만 읽을 수 있습니다

note 의 이 설명이 7강과 이어집니다.

로그에는 민감한 정보가 들어 있다

무엇이 들어 있나

정보	왜 민감한가
IP 주소	누가 접속했나
로그인 실패	어떤 계정이 존재하는지 드러난다
URL · 파라미터	토큰이 섞일 수 있다 ⚠
내부 경로 · 버전	공격에 단서

로그가 새면 공격 지도를 주는 셈이다

그래서 조심할 것

규칙	이유
비밀번호를 로그에 안 남긴다	평문으로 남는다
토큰은 가린다	일부만 표시
로그 파일 권한 640	7강

"디버깅용" 으로 남긴 로그가 유출 사고가 되는 일이 흔하다

adm 그룹

사람마다 root 를 주지 않고 adm 그룹에 넣으면 로그를 읽을 수 있습니다.

방법	권한
root 를 준다	전부 ⚠
adm 그룹	로그만 ✔

7강의 최소 권한 원칙 — 필요한 만큼만

비유 — 병원 기록

진료 기록은 아무나 못 봅니다. 그런데 의료진은 봐야 하죠.

"전부 아니면 아무것도" 가 아니라 역할별로 나눈다

세 가지 읽기 방법

① tail — 가장 최근 것부터 (거의 항상 이걸로 시작합니다)

bash 내 가상 Ubuntu 서버에서 실행

sudo tail -5 /var/log/syslog

② grep — 찾는 것만 골라서

bash 내 가상 Ubuntu 서버에서 실행

sudo grep ERROR /var/log/shop/app.log

③ journalctl — 서비스별로 모아서 (systemd 의 선물)

bash 내 가상 Ubuntu 서버에서 실행

journalctl -u shop -n 10

고등학생tail -f 는 실시간 감시

note 가 말하는 대로 10강이 여기서 무기가 됩니다.

tail -f — 새 줄이 쌓이면 바로 보여 준다

언제 쓰나

상황	쓰는 법
배포 직후	오류가 나는지 지켜본다
재현되는 버그	보면서 동작시킨다
공격 의심	접속을 실시간으로

"방금 무슨 일이 일어났나" 를 즉시 본다

파이프와 함께

tail -f app.log | grep -i error
tail -f app.log | grep --line-buffered ERROR

--line-buffered 가 없으면 모아서 나온다 — 실시간이 안 된다

grep 은 기본적으로 출력을 모아서 내보냅니다. 파일에 쓸 땐 효율적이지만 실시간 감시에는 방해예요.

여러 파일을 한 번에

tail -f /var/log/nginx/*.log

파일 이름이 구분선으로 표시된다

systemd 서비스는 journalctl

명령	하는 일
`journalctl -u 앱 -f`	실시간
`journalctl -u 앱 -n 100`	최근 100줄
`journalctl -u 앱 --since "1 hour ago"`	시간 범위
`journalctl -p err`	오류 이상만

--since 가 실전에서 가장 유용하다 — 사고 시각 근처만

비유 — CCTV

방식	비유
`tail -f`	실시간 화면을 본다
`--since`	녹화본을 돌려 본다

사고는 대개 지나간 뒤에 안다 — 그래서 기록이 중요하다

🎮 로그 분석 실습실

진짜 문제를 드립니다. 파이프를 조립해서 답을 찾아보세요. 10강에서 배운 것이 여기서 무기가 됩니다.

실전 · 세 가지 질문에 답해 봅시다

쇼핑몰 관리자에게 아침마다 필요한 정보입니다.

① 어제 방문이 몇 건이었나

bash 내 가상 Ubuntu 서버에서 실행

sudo cat /var/log/nginx/access.log | wc -l

② 없는 페이지를 찾은 요청은? — 오타인가, 공격인가

bash 내 가상 Ubuntu 서버에서 실행

sudo grep " 404 " /var/log/nginx/access.log

③ 가장 많이 들어온 IP 세 개

bash 내 가상 Ubuntu 서버에서 실행

sudo cat /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -3

1등이 45.148.10.72 입니다. 그런데 이 IP가 요청한 주소를 보면 /admin.php, /wp-login.php, /.env. 우리 쇼핑몰에는 있지도 않은 주소들이죠.

워드프레스나 PHP 사이트의 흔한 취약점을 무작정 찔러 보는 자동 스캐너입니다. 전 세계 서버가 매일 겪는 일이에요. 20강에서 이 IP를 막아 봅니다.

웹으로도 찔러 보고, SSH 로도 찔러 봤습니다

bash 내 가상 Ubuntu 서버에서 실행

sudo grep "45.148.10.72" /var/log/nginx/access.log
sudo grep "Failed password" /var/log/auth.log | wc -l

500 오류의 진짜 원인 찾기

접속 기록에 500 이 하나 보였습니다. 서버 잘못이라는 뜻이에요. 어디가 잘못됐는지는 앱의 로그에 있습니다.

nginx 는 '500이 났다'만 알고, 앱 로그가 '왜'를 압니다

bash 내 가상 Ubuntu 서버에서 실행

sudo grep " 500 " /var/log/nginx/access.log
sudo grep ERROR /var/log/shop/app.log

sqlite3.OperationalError: no such table: review

범인을 찾았습니다. review 라는 표가 데이터베이스에 없는데 app.py 41번째 줄이 그 표를 읽으려 했어요. 로그 한 줄이 코드 한 줄을 정확히 가리킵니다.

고등학생로그도 디스크를 잡아먹습니다

note 의 이 경고가 18강의 1위 장애와 이어집니다.

로그는 계속 쌓인다 — 관리하지 않으면 디스크를 채운다

얼마나 쌓이나

초당 요청	하루 로그
10	약 200MB
100	약 2GB
1,000	약 20GB

한 달이면 수백 GB — 디스크가 찬다

디스크가 차면 벌어지는 일

영향	설명
앱이 못 쓴다	파일 저장 실패
DB 가 멈춘다	쓰기 불가
로그도 못 쓴다	원인을 기록도 못 한다 ⚠

가장 얄궂다 — 문제를 진단할 로그가 안 남는다

해결 — logrotate

리눅스에는 자동 회전 도구가 있습니다.

동작	설명
일정 크기·기간마다	파일을 새로 시작
옛 파일	압축한다
정해진 개수를 넘으면	지운다

압축하면 텍스트는 10분의 1 이 된다 — 큰 절약

journald 도 제한을 겁니다

journalctl --disk-usage              # 얼마나 쓰나
journalctl --vacuum-size=500M        # 500MB 로 줄인다

기본값이 디스크의 10% — 큰 디스크면 수십 GB

비유 — 일기장

매일 일기를 쓰는데 한 권도 안 버리면? 방이 일기장으로 찹니다.

방식	결과
전부 보관	공간이 찬다
최근 것만 · 옛것은 압축	필요한 것은 남는다 ✔

기록은 보존 기간을 정해야 유지된다

🤔 확인 문제

사이트가 안 된다는 연락을 받았을 때 가장 먼저 할 일은?

해설 재부팅은 원인을 지워 버립니다. 게다가 원인이 그대로면 곧 다시 죽어요. systemctl status → journalctl -u → error.log 순서로 읽는 것이 정석입니다.

🤔 확인 문제

nginx 접속 기록에 500 이 보일 때 원인을 찾으려면 어디를 봐야 하나?

해설 nginx 는 앱이 준 상태 코드를 그대로 적을 뿐입니다. 왜 500이 났는지는 앱만 알아요. 그래서 journalctl -u shop 이나 앱 로그에서 Traceback 을 찾습니다.

🤔 확인 문제

tail -f 가 특별히 유용한 상황은?