ls 명령어 기본 옵션으로 파일 목록 문제를 확인하는 실무 순서

서버에 파일을 올렸는데 목록에 보이지 않거나, 분명 수정한 파일이 있는데 서비스에는 반영되지 않는 상황이라면 먼저 파일이 정말 없는지부터 확인해야 합니다. 이 글은 ls 명령어 기본 옵션을 이용해 현재 위치, 숨김 파일, 권한, 수정 시간, 파일 크기를 순서대로 확인하고, 파일 누락처럼 보이는 문제의 원인을 분리하는 방법을 정리한 문서입니다.

이 글에서 해결할 문제

ls는 단순히 파일 목록을 보는 명령어로 보이지만, 실제 서버 운영에서는 문제 원인을 좁히는 첫 번째 확인 도구가 됩니다. 특히 Debian/Ubuntu 기반 VPS에서 SSH로 접속해 WordPress, Node.js, Nginx 관련 파일을 확인하다 보면 다음과 같은 상황이 자주 생깁니다.

• 업로드한 파일이 보이지 않는다.
• .env, .htaccess 같은 숨김 파일이 목록에 나오지 않는다.
• 파일은 있는데 웹 서버나 앱이 읽지 못한다.
• 수정했다고 생각한 파일과 실제 서비스가 읽는 파일이 다르다.
• 로그 파일이 너무 커졌는지 확인하고 싶다.

처음에는 파일이 삭제됐거나 배포가 실패했다고 생각하기 쉽지만, 실제로는 현재 경로가 다르거나, 숨김 파일이라 보이지 않거나, 사용자 권한이 맞지 않는 경우가 많습니다. 그래서 바로 파일을 다시 만들거나 권한을 바꾸기보다 pwd, ls, ls -la 순서로 현재 상태를 먼저 확인하는 편이 안전합니다.

먼저 확인할 핵심 요약

확인 목적	명령어	판단 기준
현재 위치 확인	pwd	내가 의도한 디렉터리에서 작업 중인지 확인
기본 파일 목록 확인	ls	파일명과 폴더명이 보이는지 확인
숨김 파일 포함 확인	ls -a	점(.)으로 시작하는 설정 파일 존재 여부 확인
권한, 소유자, 수정 시간 확인	ls -l	웹 서버 계정 또는 실행 사용자가 접근 가능한지 확인
읽기 쉬운 파일 크기 확인	ls -lh	로그나 업로드 파일 크기를 KB, MB 단위로 확인
숨김 파일과 상세 정보를 함께 확인	ls -la	실무 점검에서 가장 자주 쓰는 조합

실제 서버 운영 중 헷갈리기 쉬운 지점

서버에서 파일이 보이지 않을 때 가장 흔한 오해는 목록에 안 보이면 파일이 없다고 판단하는 것입니다. 하지만 ls 결과는 현재 사용자, 현재 경로, 표시 옵션에 따라 달라집니다.

1. 현재 디렉터리가 다르면 결과도 다릅니다

SSH로 접속한 뒤 바로 ls를 실행하면 보통 사용자의 홈 디렉터리에서 목록을 봅니다. 그런데 실제 웹 파일은 /var/www/html 또는 프로젝트별 디렉터리에 있을 수 있습니다.

pwd
ls

/home/ubuntu
app-backup  memo.txt

위 결과만 보고 웹 파일이 없다고 판단하면 안 됩니다. 먼저 실제 서비스 경로를 확인해야 합니다. Ubuntu에서 Nginx 기본 웹 루트는 환경에 따라 다르지만, 간단한 서버에서는 /var/www/html인 경우가 많습니다.

ls /var/www/html

index.html  index.nginx-debian.html

2. 숨김 파일은 기본 ls에 나오지 않습니다

.env, .gitignore, .htaccess처럼 점으로 시작하는 파일은 기본 ls 출력에 표시되지 않습니다. Node.js 앱이나 WordPress 관련 작업에서 설정 파일이 빠졌다고 생각했는데, 실제로는 숨김 파일이라 못 본 경우가 있습니다.

ls
ls -a

app.js  package.json
.  ..  .env  .gitignore  app.js  package.json

.는 현재 디렉터리, ..는 상위 디렉터리입니다. ls -a를 실행했을 때 이 두 항목이 보이는 것은 숨김 항목까지 표시되고 있다는 뜻입니다.

3. 파일은 있어도 읽을 권한이 없을 수 있습니다

서버 운영에서는 파일 존재 여부와 접근 가능 여부를 구분해야 합니다. 파일은 분명히 있지만 현재 사용자 또는 웹 서버 실행 사용자가 읽지 못하면 서비스에서는 오류처럼 보일 수 있습니다. 이럴 때 바로 권한을 크게 풀기보다 먼저 현재 상태를 확인해야 합니다.

whoami
id
ls -l /var/www/html

ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),27(sudo)
total 8
-rw-r--r-- 1 root root     615 Jan 10 09:20 index.html
drwxr-xr-x 2 www-data www-data 4096 Jan 10 09:22 uploads

위 출력에서는 파일 소유자와 그룹이 함께 보입니다. Ubuntu의 Nginx나 PHP-FPM 환경에서는 www-data 계정이 관련될 수 있지만, 배포판이나 설정에 따라 실행 사용자는 달라질 수 있습니다. 따라서 권한 문제를 의심할 때는 ls -l 출력과 실제 서비스 실행 사용자를 함께 봐야 합니다.

처음 의심하기 쉬운 원인과 실제 원인의 차이

처음 생각하기 쉬운 원인	실제 원인일 수 있는 것	먼저 볼 명령어
파일이 삭제됐다	다른 디렉터리에서 보고 있다	pwd, ls /경로
배포가 실패했다	숨김 파일이라 기본 목록에 안 보인다	ls -a
앱 코드가 잘못됐다	파일 권한 또는 소유자가 맞지 않는다	ls -l, whoami, id
로그가 안 쌓인다	로그 디렉터리에 쓸 권한이 없거나 경로가 다르다	ls -ld logs, ls -lh logs
수정 사항이 반영되지 않았다	수정한 파일과 서비스가 읽는 파일 경로가 다르다	pwd, ls -l, 설정 파일의 경로 확인

리눅스를 오래 다루다 보면 명령어 자체보다 현재 사용자, 경로, 파일 권한이 원인인 경우가 많습니다. 특히 Permission denied를 보고 명령어가 틀렸다고 생각하기 쉽지만, 실제로는 현재 계정 권한이나 파일 소유자가 맞지 않는 경우가 많습니다.

ls 명령어 기본 옵션을 문제 해결에 쓰는 방법

1. ls: 파일 존재 여부를 빠르게 확인

가장 기본 형태입니다. 현재 디렉터리에 있는 일반 파일과 디렉터리 이름을 보여줍니다.

ls

app.js  logs  node_modules  package.json

이 단계에서는 파일명만 확인할 수 있습니다. 파일인지 디렉터리인지, 소유자가 누구인지, 언제 수정됐는지는 알기 어렵습니다. 목록이 예상과 다르면 바로 다음 단계로 넘어가야 합니다.

2. ls -l: 권한, 소유자, 수정 시간 확인

-l 옵션은 실무에서 가장 자주 쓰입니다. 파일은 있는데 서비스가 읽지 못하거나, 최근 수정한 파일이 맞는지 확인할 때 유용합니다.

ls -l

total 16
-rw-r--r-- 1 ubuntu   ubuntu   1204 Jan 10 09:20 app.js
drwxr-xr-x 2 www-data www-data 4096 Jan 10 09:25 logs
-rw-r--r-- 1 ubuntu   ubuntu    842 Jan 10 09:18 package.json

앞부분의 -rw-r--r--, drwxr-xr-x는 권한을 나타냅니다. 첫 글자가 d이면 디렉터리, -이면 일반 파일입니다. 그 뒤에는 소유자 권한, 그룹 권한, 기타 사용자 권한이 이어집니다.

3. ls -a: 숨김 파일 확인

환경 변수 파일이나 설정 파일을 확인할 때 필요합니다.

ls -a

.  ..  .env  .gitignore  app.js  package.json

특히 Node.js 앱에서 .env가 없으면 포트, DB 접속 정보, API 키를 읽지 못해 앱 실행이 실패할 수 있습니다. 다만 .env 파일에는 민감한 값이 들어갈 수 있으므로 화면 공유나 로그 저장 시 내용이 노출되지 않도록 주의해야 합니다.

4. ls -lh: 파일 크기를 읽기 쉽게 확인

-h는 -l과 함께 사용해야 의미가 있습니다. 바이트 단위 숫자 대신 KB, MB, GB처럼 사람이 읽기 쉬운 단위로 보여줍니다.

ls -lh /var/log/nginx

total 2.9M
-rw-r----- 1 www-data adm 2.1M Jan 10 10:12 access.log
-rw-r----- 1 www-data adm 812K Jan 10 10:12 error.log

로그 파일이 갑자기 커졌는지 가볍게 확인할 때 좋습니다. 다만 디렉터리 전체 사용량을 정확히 보려면 ls보다 du가 더 적합합니다.

du -sh /var/log/nginx

2.9M    /var/log/nginx

du는 디스크 사용량을 확인하는 명령어입니다. 삭제나 변경을 수행하지는 않지만, 운영 서버에서 큰 디렉터리를 대상으로 실행하면 환경에 따라 시간이 걸릴 수 있습니다.

5. ls -ld: 디렉터리 자체의 권한 확인

ls -l 디렉터리명은 디렉터리 안의 목록을 보여줍니다. 디렉터리 자체의 권한을 보고 싶다면 -d를 함께 써야 합니다.

ls -l logs
ls -ld logs

total 4
-rw-r--r-- 1 ubuntu ubuntu 1200 Jan 10 10:15 app.log
drwxr-xr-x 2 www-data www-data 4096 Jan 10 10:15 logs

업로드 폴더나 로그 폴더 문제를 볼 때는 디렉터리 안의 파일뿐 아니라 디렉터리 자체 권한도 확인해야 합니다.

실제로 자주 막히는 상황

상황 1. 파일이 없다고 나오지만 경로 오타인 경우

ls /var/www/htm

ls: cannot access '/var/www/htm': No such file or directory

이 메시지는 해당 경로가 없다는 뜻입니다. 파일이 삭제됐다는 의미로 바로 해석하면 안 됩니다. 상위 디렉터리부터 확인하면 오타를 빨리 찾을 수 있습니다.

ls /var/www
ls /var/www/html

html
index.html  index.nginx-debian.html

상황 2. 권한 때문에 목록을 열지 못하는 경우

ls /root

ls: cannot open directory '/root': Permission denied

이 경우는 파일이 없다는 뜻이 아니라 현재 사용자가 해당 디렉터리를 열 권한이 없다는 뜻입니다. 무리하게 권한을 바꾸기보다 먼저 현재 사용자를 확인해야 합니다.

whoami
id

ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),27(sudo)

/root는 root 계정의 홈 디렉터리입니다. 일반 운영 작업에서 굳이 열 필요가 없는 경우가 많습니다. 필요한 작업이라면 서버 정책에 맞게 sudo 권한 사용 여부를 판단해야 하지만, 단순 확인을 위해 권한을 넓히는 방식은 피하는 것이 좋습니다.

상황 3. Nginx 403처럼 보이지만 실제로는 파일 위치나 권한 문제인 경우

웹서버가 살아 있는데 403 Forbidden이 뜰 때는 서버가 죽었다기보다 index 파일 위치, Nginx의 root 경로, 파일 권한이 맞지 않는 경우가 있습니다. 설정을 수정하기 전에 실제 파일 위치를 먼저 확인합니다.

ls -la /var/www/html
ls -ld /var/www/html

total 12
drwxr-xr-x 2 www-data www-data 4096 Jan 10 09:30 .
drwxr-xr-x 3 root     root     4096 Jan 10 09:10 ..
-rw-r--r-- 1 www-data www-data  615 Jan 10 09:30 index.html

이 결과만으로 Nginx 설정이 맞다고 단정할 수는 없지만, 최소한 해당 경로에 index 파일이 있는지와 웹 서버 계정이 접근할 수 있는 형태인지 1차 판단할 수 있습니다. Nginx 설정 변경은 서비스에 영향을 줄 수 있으므로, 변경 전에는 현재 설정과 파일 상태를 먼저 확인하는 순서가 안전합니다.

원인 분리 순서

파일 목록 문제가 생겼을 때는 아래 순서로 확인하면 원인을 좁히기 쉽습니다.

1. pwd로 현재 위치를 확인합니다.
2. ls로 기본 목록을 확인합니다.
3. ls -la로 숨김 파일과 상세 정보를 함께 봅니다.
4. ls -ld 디렉터리명으로 디렉터리 자체 권한을 확인합니다.
5. whoami, id로 현재 사용자를 확인합니다.
6. 서비스가 읽는 실제 경로와 지금 보고 있는 경로가 같은지 확인합니다.
7. 필요하면 로그 디렉터리의 파일 크기와 수정 시간을 확인합니다.

이 순서는 서버에 영향을 주지 않는 확인 명령어 위주입니다. 권한 변경, 파일 삭제, 서비스 재시작 같은 작업은 원인을 충분히 좁힌 뒤에 진행하는 편이 좋습니다.

잘못된 예시와 수정 예시

잘못된 예시: 현재 위치를 확인하지 않고 파일이 없다고 판단

ls
cat package.json

memo.txt  backup
cat: package.json: No such file or directory

이 상태에서 바로 파일을 다시 업로드하거나 새로 만들면 중복 파일이 생길 수 있습니다. 먼저 현재 경로를 확인해야 합니다.

수정 예시: 경로를 확인한 뒤 실제 프로젝트 폴더에서 다시 확인

pwd
ls /var/www
cd /var/www/myapp
pwd
ls -la

/home/ubuntu
html  myapp
/var/www/myapp
total 28
drwxr-xr-x  4 ubuntu ubuntu 4096 Jan 10 10:20 .
drwxr-xr-x  4 root   root   4096 Jan 10 09:10 ..
-rw-r--r--  1 ubuntu ubuntu  124 Jan 10 10:18 .env
-rw-r--r--  1 ubuntu ubuntu 1204 Jan 10 10:19 app.js
-rw-r--r--  1 ubuntu ubuntu  842 Jan 10 10:19 package.json
drwxr-xr-x  2 ubuntu ubuntu 4096 Jan 10 10:20 logs

수정이라고 해서 항상 파일 권한을 바꾸거나 서비스를 재시작해야 하는 것은 아닙니다. 실제로는 올바른 경로에서 다시 확인하는 것만으로 문제가 정리되는 경우가 많습니다.

수정 후 확인 방법

경로를 바로잡았거나 파일을 다시 배치했다면, 다음 순서로 확인합니다.

pwd
ls -la
ls -lh
ls -ld .

확인할 기준은 다음과 같습니다.

• 현재 위치가 의도한 프로젝트 또는 웹 루트 경로인지 확인합니다.
• 필요한 숨김 파일이 보이는지 확인합니다.
• 최근 수정한 파일의 시간이 예상과 맞는지 확인합니다.
• 파일 크기가 0바이트로 비정상적으로 비어 있지 않은지 확인합니다.
• 디렉터리 자체 권한이 너무 제한되어 있지 않은지 확인합니다.

서비스 오류와 연결된 문제라면 파일 목록만 보지 말고 관련 로그도 함께 확인하는 편이 좋습니다. 예를 들어 Nginx를 사용하는 Ubuntu 서버에서는 다음처럼 최근 로그를 볼 수 있습니다.

sudo tail -n 50 /var/log/nginx/error.log

sudo는 현재 사용자에게 권한이 있을 때만 사용해야 하며, 로그에는 요청 경로, 내부 파일 경로, 권한 오류가 남을 수 있습니다. 로그 확인은 원인 파악에 도움이 되지만, 민감한 경로나 IP가 포함될 수 있으므로 공유할 때는 필요한 부분만 남기는 것이 좋습니다.

재발 방지 체크리스트

• 파일이 안 보이면 먼저 pwd로 현재 위치를 확인합니다.
• 설정 파일을 찾을 때는 기본 ls가 아니라 ls -la를 사용합니다.
• 권한 문제를 의심하면 chmod부터 실행하지 말고 ls -l, whoami, id부터 확인합니다.
• 업로드 폴더나 로그 폴더는 ls -ld 폴더명으로 디렉터리 자체 권한도 확인합니다.
• 파일 크기 확인은 ls -lh, 디렉터리 전체 사용량 확인은 du -sh처럼 목적에 맞게 구분합니다.
• 서비스가 읽는 경로와 사람이 접속해 확인하는 경로가 같은지 확인합니다.
• Docker, PM2, Nginx 같은 환경에서는 호스트 경로와 실행 환경 내부 경로가 다를 수 있음을 염두에 둡니다.
• 권한을 넓히는 방식으로 임시 해결하지 말고, 필요한 최소 권한과 소유자를 확인한 뒤 변경 여부를 판단합니다.

FAQ

Q1. ls를 실행했는데 아무것도 안 나오면 폴더가 비어 있는 건가요?

항상 그렇지는 않습니다. 일반 파일이 없을 수도 있지만, 숨김 파일만 있을 수도 있습니다. 먼저 ls -la를 실행해 점으로 시작하는 파일이 있는지 확인해 보세요. 그래도 목록이 없다면 현재 경로가 맞는지도 pwd로 확인하는 것이 좋습니다.

Q2. Permission denied가 나오면 어떻게 해야 하나요?

파일이 없는 것이 아니라 현재 사용자에게 접근 권한이 없다는 뜻일 수 있습니다. 먼저 whoami, id, ls -l로 현재 사용자와 파일 소유자, 권한을 확인하세요. 권한 변경은 서비스 동작과 보안에 영향을 줄 수 있으므로, 원인을 확인하기 전에 무작정 권한을 넓히는 방식은 피하는 것이 좋습니다.

Q3. ls -l과 ls -lh는 무엇이 다른가요?

ls -l은 권한, 소유자, 크기, 수정 시간을 자세히 보여줍니다. ls -lh는 여기에 사람이 읽기 쉬운 크기 표시를 더한 형태입니다. 예를 들어 바이트 숫자 대신 860K, 2.1M처럼 표시되어 로그 파일이나 업로드 파일 크기를 확인할 때 편합니다.