리눅스 서버에서 장애가 나면 로그 파일을 확인해야 할 때가 많습니다.
그런데 로그 파일이 생각보다 큰 경우가 있습니다.
수십 MB 정도면 그나마 괜찮지만, 운영 서버에서는 몇백 MB, 많으면 GB 단위 로그도 볼 수 있습니다.
이런 로그 파일을 무심코 vi로 열거나 cat으로 출력하면 터미널이 멈춘 것처럼 느껴지거나, 필요한 내용을 찾기 어려워질 수 있습니다.
저도 처음에는 로그 파일을 보면 습관처럼 vi 로그파일을 입력하곤 했습니다.
그런데 운영 서버에서는 큰 로그 파일을 편집기로 여는 것보다, 먼저 less로 읽는 편이 훨씬 안전하고 편했습니다.
이번 글에서는 리눅스 서버에서 큰 로그 파일을 확인할 때 less 명령어를 어떻게 쓰면 좋은지 정리해보겠습니다.
큰 로그 파일을 vi로 바로 열면 불편한 이유
vi는 파일을 편집할 때 사용하는 도구입니다.
물론 로그 파일도 열 수는 있습니다.
vi service.log하지만 큰 로그 파일을 확인하는 용도로는 불편할 때가 많습니다.
운영 서버에서는 이런 문제가 생길 수 있습니다.
파일이 너무 커서 여는 데 오래 걸림
실수로 편집 모드에 들어갈 수 있음
저장하지 않아도 불안함
필요한 줄을 찾기 전에 화면이 복잡해짐
로그 확인이 아니라 파일 편집 작업처럼 되어버림로그는 대부분 수정하는 파일이 아니라 확인하는 파일입니다.
그래서 큰 로그 파일은 먼저 읽기 전용처럼 볼 수 있는 less를 쓰는 편이 좋습니다.
less 기본 사용법
기본 사용법은 간단합니다.
less /app/logs/service.log또는 OS 로그를 본다면:
less /var/log/messagesUbuntu 계열에서는 아래처럼 볼 수도 있습니다.
less /var/log/syslogless는 파일 내용을 한 번에 터미널에 다 쏟아내지 않고, 화면 단위로 넘겨보는 방식입니다.
그래서 큰 로그 파일을 볼 때 cat보다 훨씬 편합니다.
less에서 꼭 알아야 할 키
처음에는 많은 기능을 외울 필요 없습니다.
아래 키만 알아도 로그 확인에는 충분합니다.
Space : 다음 화면으로 이동
b : 이전 화면으로 이동
↓ : 한 줄 아래로 이동
↑ : 한 줄 위로 이동
G : 파일 맨 아래로 이동
g : 파일 맨 위로 이동
/검색어 : 검색
n : 다음 검색 결과
N : 이전 검색 결과
q : 종료가장 중요한 건 q입니다.
처음 less를 쓰면 “어떻게 나가지?” 하고 당황할 수 있습니다.
종료는 그냥 q를 누르면 됩니다.
최근 로그부터 보고 싶을 때
로그 파일은 보통 아래쪽에 최신 로그가 쌓입니다.
그래서 큰 로그를 열었을 때 맨 아래부터 보고 싶을 때가 많습니다.
less로 파일을 연 뒤:
G를 누르면 파일 맨 아래로 이동합니다.
예를 들어:
less /app/logs/service.log파일이 열리면 G를 눌러 최신 로그 쪽으로 이동합니다.
맨 위로 다시 가고 싶으면:
g를 누르면 됩니다.
장애가 방금 발생했다면 보통 파일 맨 아래 근처를 먼저 보는 경우가 많습니다.
에러 검색하기
큰 로그 파일에서 직접 눈으로 에러를 찾는 건 힘듭니다.
이럴 때는 less 안에서 검색하면 됩니다.
예를 들어 ERROR를 찾고 싶으면:
/ERROR를 입력합니다.
그 다음 검색 결과로 이동하려면:
n이전 검색 결과로 돌아가려면:
N을 누릅니다.
대문자, 소문자 차이 때문에 검색이 안 될 수도 있습니다.
그럴 때는 로그에서 자주 쓰는 여러 키워드를 상황에 맞게 검색하면 됩니다.
/ERROR
/Exception
/timeout
/fail
/denied실무에서는 ERROR 한 단어만 찾기보다, 장애 상황에 맞는 키워드를 바꿔가며 보는 게 좋았습니다.
less로 보고, grep으로 좁혀보기
less는 큰 로그 파일을 이동하면서 보기 좋고, grep은 특정 키워드를 빠르게 찾기 좋습니다.
예를 들어 에러만 먼저 보고 싶다면:
grep -i "error" /app/logs/service.log최근 로그 중에서만 보고 싶다면:
tail -n 500 /app/logs/service.log | grep -i "error"그런데 에러 전후 흐름까지 보고 싶다면 less로 직접 열어서 검색하는 편이 더 나을 때도 있습니다.
정리하면 이렇게 보면 됩니다.
큰 로그를 위아래로 보면서 확인
→ less
특정 키워드만 빠르게 찾기
→ grep
최근 로그만 먼저 확인
→ tail -n
새 로그가 찍히는지 실시간 확인
→ tail -f명령어를 하나만 고집하기보다 상황에 따라 나누는 게 좋습니다.
less + tail을 같이 쓰는 흐름
장애 상황에서는 보통 이렇게 봅니다.
먼저 최근 로그를 확인합니다.
tail -n 100 /app/logs/service.log최근 로그에서 에러가 보이는데 앞뒤 흐름을 더 보고 싶다면 less로 엽니다.
less /app/logs/service.log그리고 /ERROR로 검색합니다.
/ERROR새 로그가 계속 찍히는지 봐야 한다면 tail -f로 이어갑니다.
tail -n 100 -f /app/logs/service.log이렇게 보면 됩니다.
최근 확인 → 큰 로그 탐색 → 실시간 확인이 흐름이 익숙해지면 로그 확인이 훨씬 덜 복잡해집니다.
less에서 실수하기 쉬운 부분
less는 비교적 안전한 편이지만, 처음 사용할 때 헷갈리는 부분이 있습니다.
종료는 q
검색은 /검색어
다음 검색 결과는 n
이전 검색 결과는 N
맨 아래는 G
맨 위는 g특히 G와 g가 헷갈릴 수 있습니다.
G : 아래로, 최신 로그 쪽
g : 위로, 오래된 로그 쪽대부분의 로그는 아래쪽이 최신이므로, 장애가 방금 났다면 G를 많이 씁니다.
파일 크기 먼저 확인하기
로그 파일을 열기 전에 크기를 먼저 보는 습관도 좋습니다.
ls -lh /app/logs/service.log예시입니다.
-rw-r--r-- 1 app app 1.5G May 22 10:20 service.log1.5GB 로그 파일이라면 vi로 바로 여는 건 피하는 편이 좋습니다.
이럴 때는 먼저:
tail -n 100 /app/logs/service.log또는:
less /app/logs/service.log처럼 확인하는 게 낫습니다.
운영 서버에서는 “일단 열어보자”보다 “파일 크기를 보고 알맞은 명령어를 고르자”가 더 안전합니다.
운영 서버에서 주의할 점
로그 확인은 단순 조회 작업처럼 보이지만, 운영 서버에서는 조심해야 할 부분이 있습니다.
로그 파일을 편집하지 않기
실제 로그 원문을 외부에 그대로 공유하지 않기
토큰, 계정명, IP, 내부 도메인 등 민감 정보 확인하기
큰 로그 파일을 무리하게 열지 않기
로그 삭제는 원인 확인 후 판단하기특히 로그에는 내부 IP, 사용자 정보, 토큰, 요청 URL 등이 들어갈 수 있습니다.
블로그나 외부 보고 자료에 실제 로그를 그대로 올리는 건 피해야 합니다.
예시는 항상 가짜 경로와 가짜 로그로 정리하는 게 좋습니다.
장애 상황에서 less 확인 순서
초보 운영자 기준으로는 아래 순서가 무난합니다.
1. 로그 파일 위치 확인
2. 파일 크기 확인
3. tail -n으로 최근 로그 먼저 확인
4. 큰 로그를 봐야 하면 less로 열기
5. G로 최신 로그 위치 이동
6. /ERROR 같은 키워드 검색
7. 필요하면 grep 또는 tail -f로 추가 확인명령어로 정리하면 아래처럼 볼 수 있습니다.
ls -lh /app/logs/service.logtail -n 100 /app/logs/service.logless /app/logs/service.logG
/ERROR
n
q이 정도만 알아도 큰 로그 파일 확인은 훨씬 편해집니다.
실무 보고 예시
큰 로그 파일을 확인한 뒤에는 이렇게 정리할 수 있습니다.
애플리케이션 로그 파일 용량이 커서 less 명령어로 확인했습니다.
최근 로그 기준 ERROR 발생 시각을 확인했으며, 관련 키워드로 앞뒤 흐름을 추가 확인 중입니다.에러 검색까지 했다면 이렇게 쓸 수 있습니다.
less에서 ERROR 키워드 기준으로 로그를 확인했습니다.
동일 에러가 특정 시간대부터 반복되는 것으로 보여, 해당 시점의 요청 및 서비스 상태를 추가 확인하겠습니다.로그가 너무 큰 경우는 이렇게 정리할 수 있습니다.
로그 파일 용량이 커서 전체 출력은 진행하지 않고, tail -n 및 less로 필요한 구간만 확인했습니다.
민감 정보가 포함될 수 있어 외부 공유 시 로그 내용은 마스킹 후 전달하겠습니다.이렇게 쓰면 단순히 “로그 봤습니다”보다 훨씬 운영자답게 정리됩니다.
정리
리눅스 서버에서 큰 로그 파일을 확인할 때는 무작정 vi나 cat으로 열지 않는 것이 좋습니다.
큰 로그 파일을 안전하게 확인할 때는:
less 로그파일최근 로그만 먼저 볼 때는:
tail -n 100 로그파일실시간으로 새 로그를 볼 때는:
tail -f 로그파일less에서 자주 쓰는 키는 아래 정도만 기억하면 됩니다.
G : 맨 아래로 이동
g : 맨 위로 이동
/검색어 : 검색
n : 다음 검색 결과
N : 이전 검색 결과
q : 종료초보 운영자라면 이 문장만 기억해도 좋습니다.
큰 로그 파일은 vi로 바로 열지 말고, less로 안전하게 확인한다.로그 확인도 결국 확인 → 판단 → 조치 순서가 중요합니다.
4. 관련 글 연결 문구
큰 로그 파일을 보기 전에 최근 로그부터 빠르게 확인하면 원인 방향을 잡기 쉽습니다.
아래 글도 함께 보면 좋습니다.
- 리눅스 서버 로그 확인할 때 전체 열지 말고 tail -n으로 최근만 보는 법
- 리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법
- 리눅스 서버 로그 볼 때 cat부터 치지 말고 tail과 less로 확인하는 법
- 리눅스 서버 재기동 전 바로 확인해야 할 기본 체크리스트
5. 다음 글 예고 문구
다음 글에서는 로그에서 에러를 빠르게 찾을 때 자주 쓰는 grep 명령어를 정리해 보겠습니다.
'리눅스' 카테고리의 다른 글
| 리눅스 서버 로그에서 에러 한 줄만 보지 말고 grep -C로 앞뒤 흐름 확인하는 법 (0) | 2026.05.28 |
|---|---|
| 리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법 (0) | 2026.05.26 |
| 리눅스 서버 로그 확인할 때 전체 열지 말고 tail -n으로 최근만 보는 법 (0) | 2026.05.25 |
| 리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법 (0) | 2026.05.24 |
| 리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법 (0) | 2026.05.21 |