리눅스 find 명령어로 파일 찾는 방법: 경로·권한·대소문자까지 확인하는 순서

서버에서 설정 파일을 수정했는데 반영되지 않거나, 로그 파일이 있다고 들었는데 경로를 찾지 못하는 상황을 해결하는 글입니다. 단순히 find 문법만 외우는 것이 아니라, 현재 위치와 권한, 파일명 대소문자, 서비스가 실제로 참조하는 경로를 순서대로 확인해 파일이 정말 어디에 있는지 좁혀가는 방법을 다룹니다.

이 글에서 해결할 문제

리눅스 서버를 운영하다 보면 파일이 없는 것처럼 보이지만 실제로는 다른 경로에 있거나, 권한 때문에 보이지 않거나, 파일명이 조금 달라 검색되지 않는 경우가 많습니다. 특히 Debian/Ubuntu 기반 VPS에서 Nginx, Node.js, PM2, WordPress 같은 서비스를 운영할 때 이런 일이 자주 생깁니다.

이 글에서는 다음 상황을 기준으로 설명합니다.

• 설정 파일 위치를 모르겠을 때
• 로그 파일이 생성되는 위치를 찾고 싶을 때
• 파일명이 정확히 기억나지 않을 때
• 권한 문제와 파일 부재를 구분해야 할 때
• 검색 범위를 너무 넓게 잡아 서버에 부담을 주고 싶지 않을 때

먼저 확인할 핵심 요약

파일을 찾기 전에 아래 순서로 확인하면 불필요한 전체 검색을 줄일 수 있습니다.

1. pwd로 현재 작업 위치를 확인합니다.
2. ls -la로 현재 디렉터리에 파일이 있는지 먼저 봅니다.
3. 파일인지 디렉터리인지 구분해 -type f 또는 -type d를 붙입니다.
4. 대소문자가 의심되면 -name 대신 -iname을 사용합니다.
5. 권한 오류가 나오면 파일이 없다고 단정하지 말고 현재 사용자와 접근 권한을 확인합니다.
6. 운영 서버에서는 / 전체보다 /etc, /var/www, /var/log, /opt처럼 후보 경로부터 검색합니다.

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

처음에는 파일이 삭제된 문제처럼 보였지만 실제로는 검색 위치가 틀린 경우가 많습니다. 예를 들어 Nginx 설정 파일을 찾을 때 Ubuntu 계열에서는 보통 /etc/nginx/ 아래를 먼저 보지만, Apache 설정은 CentOS 계열과 Debian/Ubuntu 계열의 기본 경로가 다를 수 있습니다.

또 하나 자주 놓치는 부분은 현재 사용자 권한입니다. 서버 작업 중 Permission denied가 나오면 명령어가 틀렸다고 생각하기 쉽지만, 실제로는 현재 계정이 해당 디렉터리를 읽을 권한이 없는 경우가 많습니다. 이럴 때는 바로 권한을 바꾸기보다 whoami, id, ls -ld로 현재 상태를 먼저 확인하는 편이 안전합니다.

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

겉으로 보이는 상황	처음 의심하기 쉬운 원인	실제로 자주 나오는 원인	먼저 확인할 명령어
파일 검색 결과가 없음	파일이 삭제됨	대소문자나 확장자가 다름	find /var/www -iname '*config*'
설정을 바꿨는데 반영 안 됨	서비스 오류	다른 설정 파일을 수정함	find /etc -type f -name 'nginx.conf'
로그 파일을 못 찾음	로그가 생성되지 않음	서비스별 로그 경로가 다름	find /var/log -type f -mtime -1
Permission denied가 출력됨	find 명령어 문제	현재 사용자 권한 부족	whoami, ls -ld 경로

실제로 자주 막히는 상황

1. 현재 디렉터리 기준으로만 찾고 있었다

find .에서 점은 현재 디렉터리를 뜻합니다. SSH로 접속한 뒤 어디에 있는지 확인하지 않고 검색하면, 예상과 다른 하위 경로만 뒤지는 일이 생깁니다.

pwd
ls -la

현재 경로가 확인되면 그 아래에서 검색합니다.

find . -type f -name 'app.log'

2. 파일명이 정확하지 않았다

리눅스에서는 일반적으로 파일명 대소문자를 구분합니다. app.log와 App.log는 다른 이름입니다.

find /var/www -type f -name 'app.log'

위 명령으로 결과가 없다면 대소문자를 무시하고 다시 확인합니다.

find /var/www -type f -iname 'app.log'

3. 권한 때문에 내부를 읽지 못했다

루트 경로부터 검색하면 접근 권한이 없는 디렉터리에서 오류가 섞여 나올 수 있습니다.

find / -name 'secure.conf'
find: '/root': Permission denied
find: '/var/lib/private': Permission denied

이 출력은 파일이 없다는 뜻이 아닙니다. 현재 사용자로 해당 디렉터리를 읽지 못한다는 뜻일 수 있습니다. 먼저 현재 사용자를 확인합니다.

whoami
id

그리고 의심되는 디렉터리의 권한을 확인합니다.

ls -ld /root
ls -ld /var/lib/private

관리 권한이 필요한 서버라면 sudo로 다시 검색할 수 있지만, 운영 서버에서 전체 경로를 무작정 검색하면 시간이 오래 걸릴 수 있습니다. 가능한 한 검색 범위를 먼저 좁히는 것이 좋습니다.

find 명령어 기본 사용법

가장 기본 형태는 검색을 시작할 경로와 조건을 함께 쓰는 방식입니다.

find 검색시작경로 조건

현재 디렉터리 아래에서 특정 파일명을 찾으려면 다음처럼 실행합니다.

find . -type f -name 'app.log'

예상 출력은 다음과 같습니다.

./logs/app.log

-type f는 일반 파일만 찾겠다는 뜻입니다. 디렉터리까지 섞이면 결과가 헷갈릴 수 있으므로, 서버 운영 중에는 파일과 디렉터리를 구분해서 찾는 습관이 좋습니다.

원인 분리: 어디서부터 찾을지 정하는 기준

검색 범위를 정할 때는 파일의 성격을 기준으로 시작 경로를 정하면 빠릅니다.

찾는 대상	먼저 볼 경로	예시 명령어
Nginx 설정 파일	/etc/nginx	find /etc/nginx -type f -name '*.conf'
웹 프로젝트 파일	/var/www, /opt	find /var/www -type f -iname '*config*'
최근 로그 파일	/var/log	find /var/log -type f -mtime -1
사용자 홈 파일	/home/사용자명	find /home/ubuntu -type f -name '.env'
임시 파일	/tmp	find /tmp -type f -mtime -1

Debian/Ubuntu 서버라면 웹 관련 파일은 /etc/nginx, /var/www, /var/log를 먼저 보는 경우가 많습니다. 다만 직접 설치한 서비스나 Docker, PM2, nvm 환경에서는 경로가 달라질 수 있습니다.

잘못된 예시

1. 서버 전체를 바로 검색하는 경우

find / -name 'config.json'

이 명령은 틀린 명령은 아니지만, 디스크가 크거나 파일이 많은 서버에서는 오래 걸릴 수 있습니다. 권한 오류도 많이 섞여 결과를 보기 어려울 수 있습니다. 운영 중인 서버에서는 먼저 후보 경로를 좁히는 것이 좋습니다.

2. 파일과 디렉터리를 구분하지 않는 경우

find /var/www -name 'logs'

이렇게 실행하면 파일명과 디렉터리명이 함께 검색될 수 있습니다. 로그 디렉터리를 찾는 목적이라면 다음처럼 구분합니다.

find /var/www -type d -name 'logs'

3. 대소문자를 고려하지 않는 경우

find /var/www -type f -name 'app.log'

실제 파일명이 App.Log라면 위 명령은 결과가 없을 수 있습니다. 이름이 정확하지 않다면 -iname을 사용합니다.

find /var/www -type f -iname 'app.log'

수정 예시: 목적별로 find 명령어 바꾸기

설정 파일 찾기

Nginx 설정 파일처럼 위치가 어느 정도 예상되는 파일은 /etc 아래부터 찾습니다.

find /etc -type f -name 'nginx.conf'
find /etc/nginx -type f -name '*.conf'

설정 파일을 찾은 뒤 바로 수정하기보다, 먼저 내용을 확인합니다.

less /etc/nginx/nginx.conf

Nginx 설정을 변경해야 하는 상황이라면 수정 후 바로 재시작하지 말고 문법 검사를 먼저 해야 합니다.

sudo nginx -t

문법 검사가 통과한 경우에만 반영합니다. 운영 서버에서는 서비스 반영이 접속에 영향을 줄 수 있으므로 작업 시간을 고려하는 것이 좋습니다.

sudo systemctl reload nginx

최근 수정된 로그 파일 찾기

오류가 발생한 직후라면 최근 변경된 로그 파일을 기준으로 찾는 것이 빠릅니다.

find /var/log -type f -mtime -1

-mtime -1은 최근 1일 이내 수정된 파일을 찾습니다. 더 짧은 시간 단위가 필요하면 -mmin을 사용할 수 있습니다.

find /var/log -type f -mmin -60

위 명령은 최근 60분 이내 수정된 로그 파일을 찾습니다.

확장자로 찾기

프로젝트 안에서 특정 확장자 파일만 찾고 싶다면 와일드카드를 사용합니다.

find /var/www -type f -name '*.php'
find /var/www -type f -name '*.js'
find /var/www -type f -name '*.log'

와일드카드 패턴은 쉘이 먼저 해석하지 않도록 작은따옴표로 감싸는 편이 안전합니다.

이름 일부만 기억날 때

파일명 전체가 기억나지 않으면 앞뒤에 *를 붙여 일부 문자열로 찾습니다.

find /var/www -type f -iname '*config*'
find /var/www -type f -iname '*backup*'
find /var/www -type f -iname '*error*'

서비스가 실제로 쓰는 경로도 함께 확인하기

파일을 찾았다고 해서 그 파일이 서비스에서 실제로 사용 중인 파일이라고 단정하면 안 됩니다. 서버 운영에서는 설정 파일이 여러 개 남아 있거나, 예전 배포 디렉터리가 그대로 남아 있는 경우가 있습니다.

Nginx라면 서비스 상태와 설정 파일 위치를 함께 확인합니다.

systemctl status nginx

로그 확인이 필요하다면 다음 명령으로 최근 로그를 볼 수 있습니다.

journalctl -u nginx --no-pager -n 50

Node.js 앱을 PM2로 운영한다면 파일을 찾는 것과 별개로 현재 실행 중인 앱 목록과 로그를 봐야 원인을 좁히기 쉽습니다.

pm2 list
pm2 logs --lines 50

처음에는 파일 위치 문제처럼 보였지만, 실제로는 서비스가 다른 작업 디렉터리에서 실행 중이거나 다른 설정 파일을 참조하는 경우가 있습니다. 그래서 파일 검색 후에는 서비스 상태와 로그를 함께 확인하는 편이 좋습니다.

수정 후 확인 방법

파일을 찾고 설정이나 내용을 확인했다면, 실제로 기대한 파일이 맞는지 다시 검증합니다.

1. 파일 경로가 예상한 서비스 경로와 일치하는지 확인합니다.
2. 파일 소유자와 권한을 확인합니다.
3. 최근 수정 시간이 맞는지 확인합니다.
4. 서비스 로그에서 해당 파일을 읽는 흔적이나 오류를 확인합니다.

기본 확인 명령어는 다음과 같습니다.

ls -l /etc/nginx/nginx.conf
stat /etc/nginx/nginx.conf

웹 서버 설정처럼 서비스에 영향을 주는 파일이라면, 변경 전에 현재 파일을 확인하고 변경 후 문법 검사나 로그 확인까지 진행해야 합니다.

sudo nginx -t
systemctl status nginx
journalctl -u nginx --no-pager -n 50

systemctl이나 journalctl 출력은 배포판과 설치 방식에 따라 다를 수 있습니다. Debian/Ubuntu에서는 보통 위 명령을 사용할 수 있지만, 컨테이너 환경이나 직접 빌드한 서비스에서는 로그 위치가 다를 수 있습니다.

Permission denied가 많을 때 처리 방법

전체 검색 중 권한 오류가 너무 많이 나오면 표준 오류를 숨겨 결과만 볼 수 있습니다.

find / -type f -name 'php.ini' 2>/dev/null

다만 이 방법은 권한 오류를 화면에서 숨길 뿐, 접근 권한이 생기는 것은 아닙니다. 운영 서버에서는 오류를 숨기기 전에 검색 범위를 줄이는 것이 우선입니다.

find /etc -type f -name 'php.ini' 2>/dev/null
find /usr -type f -name 'php.ini' 2>/dev/null

정말 관리자 권한이 필요한 경로라면 sudo를 사용할 수 있습니다.

sudo find /etc -type f -name 'php.ini'

sudo는 권한이 필요한 작업이므로, 공유 서버나 운영 서버에서는 자신이 관리해야 하는 범위인지 확인한 뒤 사용해야 합니다.

CentOS와 Debian/Ubuntu에서 달라질 수 있는 부분

find 명령어 자체는 대부분의 리눅스 배포판에서 비슷하게 동작합니다. 차이는 주로 파일이 놓이는 기본 경로에서 생깁니다.

항목	Debian/Ubuntu에서 자주 보는 위치	CentOS 계열에서 자주 보는 위치
Nginx 설정	/etc/nginx/	/etc/nginx/
Apache 설정	/etc/apache2/	/etc/httpd/
웹 루트	/var/www/	/var/www/ 또는 환경별 경로
시스템 로그	/var/log/	/var/log/

따라서 같은 명령어라도 시작 경로를 어디로 잡느냐에 따라 속도와 결과가 달라집니다.

재발 방지 체크리스트

1. 작업 전 pwd로 현재 위치를 확인한다.
2. 파일명 대소문자가 애매하면 -iname으로 검색한다.
3. 파일만 찾을 때는 -type f, 디렉터리만 찾을 때는 -type d를 붙인다.
4. 운영 서버에서는 find /보다 후보 경로를 먼저 정한다.
5. Permission denied를 파일 없음으로 해석하지 않는다.
6. 설정 파일을 찾은 뒤에는 서비스가 실제로 그 파일을 참조하는지 확인한다.
7. Nginx 설정 변경 전후에는 nginx -t와 로그를 확인한다.
8. 자주 찾는 프로젝트 경로와 로그 경로는 문서나 배포 메모에 남긴다.

FAQ

Q1. find 명령어 결과가 없으면 파일이 삭제된 건가요?

그렇게 단정하면 안 됩니다. 검색 시작 경로가 틀렸거나, 대소문자가 다르거나, 현재 사용자에게 디렉터리 읽기 권한이 없을 수 있습니다. 먼저 pwd, ls -la, find 경로 -iname '이름' 순서로 확인해 보세요.

Q2. 서버 전체에서 찾으려면 항상 find / 를 쓰면 되나요?

가능은 하지만 운영 서버에서는 권장되는 첫 번째 방법은 아닙니다. 파일이 많은 서버에서는 오래 걸릴 수 있고 권한 오류도 많이 나옵니다. 설정 파일은 /etc, 웹 파일은 /var/www, 로그는 /var/log처럼 후보 경로를 먼저 좁히는 편이 안전합니다.

Q3. Permission denied가 나오면 sudo find를 쓰면 되나요?

관리 권한이 필요한 경로라면 sudo find가 필요할 수 있습니다. 다만 먼저 현재 사용자와 경로 권한을 확인하는 것이 좋습니다. whoami, id, ls -ld 경로로 상태를 본 뒤, 자신이 관리해야 하는 서버와 경로인지 확인하고 사용하세요.