흔한 로그 위치
- /var/log 아래 시스템·서비스 로그
- 애플리케이션 지정 경로 (설정 파일에 명시)
- 컨테이너는 표준 출력 (docker logs)
- 실행 디렉터리의 logs 폴더
이 파트에서 다루는 내용
로그가 쌓이는 곳실시간으로 보기시간으로 좁히기요청 흐름 좇기
01
로그는 장애 대응의 1차 증거입니다
AI에게 에러를 붙여넣던 습관을, 로그를 직접 읽는 능력으로 대체하는 것이 이 파트의 목표입니다. 로그는 무슨 일이 있었는지 시간 순서로 기록한 유일한 증거입니다.
먼저 로그가 어디에 쌓이는지 알아야 합니다. 위치를 모르면 시작할 수 없습니다.
위치를 모를 때
find 로 최근 수정된 .log 파일을 찾거나, 애플리케이션 설정에서 로그 경로를 grep 으로 찾습니다. 도구가 여기서도 이어집니다.
컨테이너 로그
컨테이너는 로그를 파일이 아니라 표준 출력으로 내보내는 것이 기본입니다. docker logs 로 확인하며, Docker 코스에서 다룬 방식과 이어집니다.
find /var/log -name "*.log" -mtime -1최근 하루 안에 쓰인 로그 파일 찾기ls -lt /var/log/*.log최근에 수정된 순으로 로그 목록 확인grep -ri "log" app.conf | grep -i path설정에서 로그 경로 찾기02
실시간으로 따라 보며 재현합니다
문제를 재현할 수 있다면, 로그를 실시간으로 보면서 그 순간 무엇이 찍히는지 확인하는 것이 가장 빠릅니다.
재현하며 관찰
tail -f 를 켜 두고 문제 동작을 다시 해 봅니다. 그 순간 찍히는 로그가 원인에 가장 가깝습니다. 오류만 보려면 grep 을 파이프로 붙입니다.
less +F 의 장점
tail -f 는 흘러가기만 하지만, less +F 는 Ctrl+C 로 멈춰 위로 스크롤해 앞을 확인하고 다시 F 로 실시간에 복귀할 수 있습니다.
재현이 안 될 때
간헐적이거나 이미 지난 장애는 실시간으로 못 봅니다. 이때는 시간을 기준으로 과거 로그를 좁혀 들어갑니다.
tail -f app.log새로 쌓이는 로그를 실시간으로 따라 보기tail -f app.log | grep -i error실시간 로그에서 오류만 걸러 보기tail -n 200 app.log최근 200줄만 빠르게 확인less +F app.log실시간 보기와 스크롤 탐색을 오가며 확인03
장애 시각을 알면 로그를 크게 좁힐 수 있습니다
수십만 줄 로그를 처음부터 읽을 수는 없습니다. 장애가 난 대략적인 시각을 알면, 그 구간만 잘라내 집중할 수 있습니다.
트랙 A에서 배운 grep 과 정규표현식이 여기서 힘을 발휘합니다. 로그의 시각 형식을 패턴으로 잡아 구간을 뽑습니다.
먼저 형식 확인
head 나 tail 로 로그 한 줄을 보고 시각이 어떤 형식인지 확인합니다. 형식을 알아야 패턴을 정확히 만들 수 있습니다.
첫 오류가 중요
오류가 연쇄로 터질 때는 마지막이 아니라 첫 번째 오류가 원인인 경우가 많습니다. 시간순으로 가장 이른 오류부터 봅니다.
시각이 어긋날 때
서버와 로그의 시간대(UTC·KST)가 다를 수 있습니다. 장애 시각을 잘못 잡으면 엉뚱한 구간을 뒤집니다. 로그의 시간대를 먼저 확인합니다.
시간으로 구간 좁히기bash
# 특정 시각(14:30~14:35) 구간만 뽑기
grep -E "2026-07-24 14:3[0-5]:" app.log
# 그 구간의 오류만 보기
grep -E "2026-07-24 14:3[0-5]:" app.log | grep -i error
# 오류 발생 지점 앞뒤 맥락 함께 (트랙 A -A -B)
grep -n -A 10 -B 3 "OutOfMemory" app.log
# 여러 날 로그에서 특정 날짜만
grep "2026-07-24" app.log | grep -i "exception"시각 형식은 로그마다 다릅니다. 먼저 head 로 한 줄을 보고 형식을 확인한 뒤 패턴을 만듭니다. 이것이 정규표현식을 실무에서 쓰는 대표적인 장면입니다.
04
요청 식별자로 한 요청의 흐름을 좇습니다
여러 요청이 뒤섞인 로그에서 문제가 된 한 요청만 따라가려면 식별자가 필요합니다. API 코스와 Spring Boot 코스에서 다룬 추적 아이디가 여기서 쓰입니다.
요청마다 고유 아이디가 로그에 남으면, 그 아이디로 grep 해서 한 요청이 거쳐 간 전 과정을 순서대로 모을 수 있습니다.
로그 레벨 이해
- ERROR: 처리 못 한 오류. 가장 먼저 봄
- WARN: 문제 소지. 원인 단서가 되기도 함
- INFO: 정상 흐름. 맥락 파악용
- DEBUG: 상세. 평소엔 노이즈, 추적 시엔 유용
추적 아이디가 없다면
아이디가 없으면 시각과 사용자 정보, 요청 경로를 조합해 좁힙니다. 그래서 개발 단계에서 추적 아이디를 남기는 것이 중요합니다. Spring Boot Part 6과 이어집니다.
여러 서버에 걸칠 때
요청이 여러 서버를 거치면 각 서버 로그를 따로 봐야 합니다. 같은 추적 아이디로 각 서버에서 grep 해 흐름을 잇습니다. 규모가 커지면 로그 수집 시스템이 필요합니다.
grep "b3f1c2a4" app.log특정 추적 아이디의 모든 로그 모으기grep "b3f1c2a4" app.log | sort시간순으로 정렬해 흐름 확인grep -h "b3f1c2a4" app*.log | sort여러 로그 파일에 걸친 흐름 합치기정리
로그 읽기는 순서가 있습니다. 로그 위치를 찾고, 재현되면 실시간으로 보고, 아니면 장애 시각으로 구간을 좁히고, 추적 아이디로 한 요청을 좇습니다. AI에게 물어보던 일을 이 순서로 스스로 하는 것이 목표입니다.
체크