리눅스 파일 권한 완벽 가이드: chmod 755, 644, 777

리눅스 파일 권한은 시스템의 모든 파일과 폴더를 누가 읽고, 쓰고, 실행할 수 있는지 결정합니다. 각 항목에는 세 부류의 사용자(소유자, 그룹, 그 외 모두)가 있고, 각 부류마다 읽기(r), 쓰기(w), 실행(x)이라는 세 개의 권한 비트가 주어집니다. 파일 하나당 아홉 개의 비트인 셈입니다. chmod가 이 비트를 설정하며, 어디서나 볼 수 있는 축약 표기가 바로 8진수입니다. 각 부류의 rwx가 0부터 7까지의 한 자리 숫자로 압축됩니다(읽기 4 + 쓰기 2 + 실행 1).

실제로 입력하게 될 거의 모든 경우를 세 가지 모드가 감당합니다:

• 755 (rwxr-xr-x) — 디렉터리와 스크립트용입니다. 소유자는 변경할 수 있고, 나머지 모두는 읽고 실행할 수 있습니다.
• 644 (rw-r--r--) — 일반 파일용입니다. 소유자는 쓰고, 나머지 모두는 읽습니다.
• 777 (rwxrwxrwx) — 모두에게 전체 접근을 허용합니다. 거의 항상 잘못된 선택이며, 해결책이 아니라 보안 구멍입니다.

무료 chmod 계산기에서 원하는 조합을 켜고 끄면 8진수, rwx 문자열, 정확한 명령어가 함께 갱신되는 모습을 볼 수 있습니다. 이 가이드의 나머지 부분에서는 이 숫자들이 어떻게 작동하고 각각 어디에 쓰이는지 설명합니다.

30초 만에 보는 리눅스 파일 권한

8진수	기호 표기	대표적 용도
400	r--------	SSH 개인 키, 읽기 전용
600	rw-------	비공개 파일, SSH 키, .env
644	rw-r--r--	웹 페이지, 설정, 대부분의 파일
700	rwx------	비공개 디렉터리(~/.ssh)
755	rwxr-xr-x	스크립트, 바이너리, 웹 디렉터리
775	rwxrwxr-x	그룹 공유 디렉터리
777	rwxrwxrwx	모두에게 모든 권한 — 피할 것
1777	rwxrwxrwt	/tmp 같은 공유 임시 디렉터리

경험칙은 이렇습니다. 파일은 644, 디렉터리는 755로 두고, 거기서부터 더 조이는 것입니다. 모드는 구체적으로 무언가가 깨질 때만 완화하고, 미리 앞당겨 풀어 주지 마십시오.

권한 모델: 소유자, 그룹, 기타 사용자

세 부류가 하나의 파일을 공유합니다. 소유자(보통 그 파일을 만든 사람), 하나의 그룹, 그리고 기타 사용자, 즉 소유자도 그룹 구성원도 아닌 모든 계정입니다. 각 부류는 저마다 독립적으로 읽기, 쓰기, 실행 권한을 갖습니다:

• 읽기(r) — 파일의 내용을 보거나 디렉터리의 항목 목록을 조회합니다.
• 쓰기(w) — 파일을 변경하거나 디렉터리 안의 항목을 추가하고 삭제합니다.
• 실행(x) — 파일을 프로그램으로 실행하거나 디렉터리 안으로 들어갑니다(cd).

사람들이 자주 걸려 넘어지는 반전은 이렇습니다. 디렉터리에서는 이 비트들의 의미가 달라집니다. r는 이름 목록을 볼 수 있게 하고, w는 안쪽 항목을 생성하고 삭제할 수 있게 하며, x는 하위 파일에 닿아 cd로 들어갈 수 있도록 통과를 허용합니다. 디렉터리에 x 없이 r만 갖고 있으면 ls는 실행되지만, 막상 들어가려는 순간 “Permission denied”가 나옵니다. 디렉터리가 644가 아니라 755인 이유가 바로 이것입니다.

ls -l 한 줄 읽기

ls -l을 실행하면 모든 항목이 열 글자짜리 블록으로 시작합니다:

$ ls -l
-rw-r--r--  1 jack staff  1400 Jul 17 10:00 index.html
drwxr-xr-x  5 jack staff   160 Jul 17 10:00 assets

왼쪽에서 오른쪽으로 읽습니다. 첫 글자는 파일 유형이며 권한이 아닙니다. -는 일반 파일, d는 디렉터리, l은 심볼릭 링크, c 또는 b는 장치, p는 명명된 파이프, s는 소켓입니다. 그다음 아홉 글자는 소유자, 그룹, 기타 사용자에 해당하는 세 묶음의 rwx입니다. 따라서 -rw-r--r--는 소유자가 읽고 쓰지만(rw-) 그룹과 기타 사용자는 읽기만 하는(r-- r--) 일반 파일이며, 이는 644입니다. drwxr-xr-x는 755인 디렉터리입니다.

일부 시스템은 아홉 비트 뒤에 표식을 덧붙입니다. 끝에 붙은 .은 SELinux 컨텍스트를 나타내고, +는 기본 비트 너머로 규칙을 더하는 ACL이 있다는 뜻이며, macOS에서 @는 확장 속성을 표시합니다. 이들 중 어느 것도 8진수를 바꾸지 않습니다. 표식은 무시하고 아홉 글자만 읽으십시오.

8진수 표기: 755가 rwxr-xr-x가 되는 원리

8진수 파일 권한이 작동하는 이유는 각 권한이 2의 거듭제곱이기 때문입니다:

• 읽기 = 4
• 쓰기 = 2
• 실행 = 1

한 부류가 가진 비트를 더하면 그 자릿수가 나옵니다. rwx는 4 + 2 + 1 = 7입니다. r-x는 4 + 1 = 5입니다. r--는 4입니다. 그래서 rwxr-xr-x는 셋씩 묶어 읽으면 7 5 5가 됩니다. rw-r--r--도 똑같이 하면 4 + 2, 4, 4 → 644가 나옵니다. 이게 요령의 전부입니다. 8진수 권한은 세 번의 독립된 덧셈일 뿐입니다.

권한 자릿수 0–7 한눈에 보기

자릿수	2진수	권한
0	000	권한 없음
1	001	실행만
2	010	쓰기만
3	011	쓰기 + 실행
4	100	읽기만
5	101	읽기 + 실행
6	110	읽기 + 쓰기
7	111	읽기 + 쓰기 + 실행

8진수는 그저 밑이 8인 진법이므로, 각 자릿수는 다음 부류로 넘치지 않고 세 비트를 담습니다. 자릿값 산술이 가물가물하다면 진법 변환기가 각 권한 자릿수와 똑같은 방식으로 8진수가 2진수에 대응되는 모습을 보여 줍니다.

chmod 755 vs 644 vs 777: 실제로 입력하게 될 모드

755, 644, 777을 나란히 놓고 비교하면 이렇습니다:

8진수	기호 표기	소유자	그룹	기타 사용자	대표적 용도	위험도
644	rw-r--r--	읽기/쓰기	읽기	읽기	일반 파일	안전한 기본값
755	rwxr-xr-x	전체	읽기/실행	읽기/실행	디렉터리, 스크립트	안전한 기본값
600	rw-------	읽기/쓰기	—	—	비공개 파일, 키	매우 안전
700	rwx------	전체	—	—	비공개 디렉터리	매우 안전
775	rwxrwxr-x	전체	전체	읽기/실행	그룹 공유 디렉터리	그룹이 쓸 수 있음
777	rwxrwxrwx	전체	전체	전체	(피할 것)	전체 쓰기 가능

755와 644의 차이는 비트 하나, 바로 실행입니다. 디렉터리, 스크립트, 바이너리는 들어가거나 실행하려면 x가 필요하므로 755로 자리 잡습니다. HTML 페이지, 이미지, 설정 파일 같은 일반 파일은 실행 가능일 이유가 없으므로 644에 머뭅니다. 이 둘을 헷갈리는 것이 일상적인 권한 오류 대부분의 원인입니다.

777이 위험한 이유. 이 모드는 침해된 서비스 계정이나 탈취된 웹 프로세스를 포함해 그 기기의 모든 계정에 쓰기 권한을 넘겨줍니다. 전체 쓰기 가능한 문서 루트는 사이트 변조나 악성 코드 주입으로 가는 교과서적인 경로입니다. 거기에 닿을 수 있는 누구든 당신의 코드를 덮어쓸 수 있기 때문입니다. 포럼 글에서 무언가를 “작동하게 하려고” chmod 777하라고 한다면, 진짜 문제는 거의 항상 소유권이며 이는 아래에서 다룹니다.

1777이라는 예외. /tmp는 의도적으로 전체 쓰기 가능이지만 안전장치가 있습니다. 1777 모드는 스티키 비트를 더하는데, 이는 누구나 파일을 생성할 수 있게 하면서도 자기 소유가 아닌 파일은 삭제하거나 이름을 바꾸지 못하도록 막습니다. 공유 임시 디렉터리가 1777에서는 안전하지만 맨 777에서는 결코 안전하지 않은 이유가 이것입니다. chmod 계산기에 777을 입력하면 위험 패널이 즉시 이를 표시하고, 1777은 표준 공유 디렉터리 패턴으로 인식됩니다.

숫자 방식 vs 기호 방식

chmod는 같은 비트를 두 가지 방식으로 받습니다.

숫자(절대) 방식은 완성된 결과를 그대로 지정합니다. chmod 755 file은 이전에 무엇이 있었든 아홉 비트 전부를 rwxr-xr-x로 설정합니다. 검증된 상태를 강제하는 스크립트나 배포에서 원하는 방식입니다.

기호(상대) 방식은 변경 사항을 서술합니다. chmod u+x file은 비트 하나만 바꾸고(소유자에게 실행 권한 추가) 나머지는 그대로 둡니다. chmod u=rwx,go=rx file은 부류 전체를 명시적으로 설정합니다. 기호 방식은 모드 전체를 다시 적는 것이 과한, 일회성 조정에 적합합니다.

# 숫자 방식: 모드 전체를 덮어씀
$ chmod 644 report.txt

# 기호 방식: 지정한 부분만 변경
$ chmod u+x deploy.sh        # 소유자에게 실행 권한 추가
$ chmod go-w shared.conf     # 그룹과 기타 사용자에서 쓰기 권한 제거
$ chmod u=rw,go=r notes.md   # 각 클래스를 명시적으로 설정 → 644

기호 방식의 함정 하나. 부류를 지정하지 않은 chmod +x는 umask에 의해 걸러집니다. 흔한 umask 022에서는 chmod +x script.sh가 모두에게 실행 권한을 더하므로 chmod a+x와 같습니다. 077처럼 더 엄격한 umask에서는 소유자에게만 영향을 줍니다. 확실한 결과를 원한다면 부류를 지정하십시오. 소유자만이면 u+x, 모두면 a+x입니다.

특수 권한: setuid, setgid, 스티키 비트

아홉 개의 표준 비트 너머로, 맨 앞에 오는 네 번째 8진수 자릿수가 세 가지 특수 모드, 즉 setuid, setgid, 스티키 비트를 담습니다:

• setuid = 4000 — 프로그램이 호출자가 아니라 파일 소유자의 권한으로 실행됩니다. root가 소유한 passwd가 일반 사용자로 하여금 root 소유의 비밀번호 데이터베이스를 갱신할 수 있게 하는 원리가 이것입니다.
• setgid = 2000 — 그룹에 대해 같은 개념입니다. 디렉터리에서는 새 파일이 그 디렉터리의 그룹을 상속하게도 하여, 공유 프로젝트의 그룹 소유권을 일관되게 유지합니다.
• 스티키 비트 = 1000 — 공유 디렉터리에서 삭제를 제한하여 사용자가 자기 파일만 지울 수 있게 합니다. 1777인 /tmp가 대표적인 예입니다.

$ chmod 4755 /usr/local/bin/mytool   # setuid
$ chmod 2775 /srv/shared             # 공유 디렉터리에 setgid
$ chmod 1777 /tmp                     # 스티키 비트
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 59976 Jul 17 10:00 /usr/bin/passwd

s/S와 t/T 대소문자 규칙

ls -l에서 특수 비트는 실행 슬롯을 다시 사용하며, 대소문자가 실행 권한도 켜져 있는지를 알려 줍니다. 소문자 s(setuid/setgid)나 t(스티키)는 특수 비트와 실행이 모두 켜진 정상적인 경우를 뜻합니다. 대문자 S나 T는 특수 비트는 설정됐지만 실행은 아님을 뜻하며, 실행 불가능한 파일에 붙은 특수 비트는 쓸모 있는 일을 전혀 하지 않으므로 대개 실수입니다.

rwsr-xr-x(4755, 실행이 있는 setuid, 올바름)와 rwSr--r--(4644, 실행이 없는 setuid, 의심스러움)를 비교해 보십시오. 대문자 S나 T가 보일 때마다 누군가 실수로 실행 비트를 떨어뜨린 것은 아닌지 확인하십시오.

아무도 언급하지 않는 GNU 디렉터리 함정

거의 모든 튜토리얼이 틀리게 다루는 플랫폼 차이가 하나 있습니다. **리눅스(GNU coreutils)**에서는 숫자 방식의 chmod 755 dir이 그 디렉터리에 이미 있던 setuid나 setgid 비트를 지우지 않습니다. 그대로 보존합니다. 디렉터리가 이미 2755(setgid)인데 깨끗한 상태를 기대하며 chmod 755를 실행하면 setgid 비트는 남고, 그 디렉터리는 실제로 여전히 2755입니다.

실제로 지우려면 명시적으로 지정하십시오:

$ chmod 00755 dir      # 다섯 자리 형식은 특수 자릿수를 0으로 만듦
$ chmod =755 dir       # =는 나열되지 않은 모든 비트를 지움
$ chmod u-s,g-s dir    # 이름으로 setuid와 setgid 제거

BSD와 macOS는 정반대입니다. 숫자 방식의 chmod 755가 기본적으로 특수 비트를 지웁니다. 그래서 chmod -R 755로 권한을 “초기화”하는 배포 스크립트는 Mac 노트북에서와 리눅스 서버에서 다르게 동작합니다. 이 보존 동작은 GNU coreutils 매뉴얼에 문서화되어 있습니다. 헷갈릴 때는 다섯 자리 형식이나 u-s,g-s 형식을 사용하여 어디서나 결과가 동일하도록 하십시오.

umask: 새로 생성된 파일이 얻는 권한

모든 파일을 손으로 일일이 chmod하는 일은 드뭅니다. 대부분은 생성 시점에 모드를 얻고, 그것을 umask가 결정합니다. umask는 꺼 버릴 비트의 집합입니다. 새 파일은 기준값 666에서, 새 디렉터리는 777에서 시작하며, umask가 비트를 가려 냅니다:

effective mode = base & ~umask

파일이 777이 아니라 666에서 시작하는 것은 갓 만든 파일이 기본적으로 실행 가능일 이유가 없기 때문입니다. 그 비트는 chmod +x로 의도적으로 더합니다.

umask	새 파일	새 디렉터리	의미
022	644	755	기본값 — 기타 사용자는 읽기만, 쓰기는 불가
077	600	700	소유자에게만 비공개
002	664	775	그룹 협업

기본값 022를 손으로 계산해 봅시다. 666 & ~022 = 666 & 755 = 644이고, 777 & ~022 = 755입니다. 현재 값은 umask로 확인하고, 그룹이나 전체가 읽을 수 있으면 안 되는 기기에서는 이를테면 umask 077로 세션 기본값을 설정하십시오.

chmod vs chown: 권한 vs 소유권

chmod과 chown은 서로 다른 질문에 답합니다. chmod은 소유자, 그룹, 기타 사용자가 무엇을 할 수 있는지, 즉 권한 비트를 바꿉니다. chown은 소유자와 그룹이 실제로 누구인지를 바꿉니다. 777에 손을 뻗는 경우는 흔히 권한 문제의 탈을 쓴 소유권 문제입니다.

전형적인 사례는 이렇습니다. www-data로 실행되는 웹 서버가 자신의 업로드 디렉터리에 쓰지 못합니다. chmod 777은 전 세계에 쓰기를 허용해 오류를 사라지게 하지만, 뒤에 구멍을 남깁니다. 올바른 해결책은 그것이 필요한 프로세스에 소유권을 넘기는 것입니다:

# 잘못된 방법: 시스템의 모든 계정에 디렉터리를 개방함
$ sudo chmod -R 777 /var/www/uploads

# 올바른 방법: 웹 사용자에게 소유권을 주고 모드는 엄격하게 유지
$ sudo chown -R www-data:www-data /var/www/uploads
$ sudo find /var/www/uploads -type d -exec chmod 755 {} +
$ sudo find /var/www/uploads -type f -exec chmod 644 {} +

무언가가 예상과 달리 읽히지 않을 때의 진단 순서는 이렇습니다. 먼저 ls -l을 실행해 누가 소유하는지를 보고, 두 번째로 모드를 해독한 다음, 해결책이 chown인지, chmod인지, 아니면 사용자를 그룹에 추가하는 것인지 결정하십시오.

재귀 권한을 제대로 다루기

무차별적인 chmod -R 755 .은 모든 일반 파일을 실행 가능으로 표시하는데, 잘해야 잡음이고 잘못하면 조용한 위험입니다. 대신 유형별로 재귀하십시오:

$ find . -type d -exec chmod 755 {} +   # 디렉터리 → 755
$ find . -type f -exec chmod 644 {} +   # 파일 → 644

GNU chmod은 **대문자 X**로 한 줄짜리 지름길을 제공합니다. 이는 디렉터리와, 이미 실행 비트를 가진 파일에만 실행 권한을 더합니다:

$ chmod -R u+rwX,go+rX .

chmod 계산기는 선택한 어떤 모드에 대해서도 디렉터리 전용과 파일 전용 find 명령어를 생성하므로, 맨 -R에 손을 뻗는 대신 올바르게 나뉜 명령을 복사할 수 있습니다.

리눅스 파일 권한 모범 사례

• 작동하는 최소한의 권한만 부여하십시오. 가장 조인 모드에서 시작해 깨지는 부분만 엽니다. 여분의 쓰기 비트 하나하나가 공격 표면입니다.
• 755 디렉터리 안의 644 파일을 기본으로 삼으십시오. 이 조합은 거의 모든 웹 루트와 저장소 체크아웃에 맞습니다. 일반 파일은 실행이 필요한 경우가 드물지만, 디렉터리는 항상 필요합니다.
• 서버가 닿을 수 있는 어떤 것에도 777을 남겨 두지 마십시오. 여러 계정이 써야 한다면 모드를 전 세계에 여는 대신 775나 2775(setgid는 그룹 소유권을 일관되게 유지함)로 공유 그룹을 사용하십시오.
• SSH 개인 키는 600으로, 최종 상태가 되면 400으로 유지하십시오. OpenSSH는 그룹이나 전체가 읽을 수 있는 개인 키를 아예 거부합니다. 정확한 키 파일 요구 사항은 OpenSSH 매뉴얼을 참고하십시오. 공개 키와 authorized_keys는 644로 두어도 괜찮습니다.
• 파일 모드를 다른 통제 수단과 겹쳐 쓰십시오. 권한은 토대입니다. 폴더에 로그인이 필요할 때는 htpasswd 생성기의 기본 인증과 함께 쓰고, 파일 모드는 웹 보안 핵심 가이드에서 다루는 전체 그림의 한 조각으로 여기십시오.

자주 묻는 질문

drwxr-xr-x 맨 앞의 d나 l은 무슨 뜻인가요?

ls -l 한 줄의 첫 글자는 권한이 아니라 파일 유형입니다. d는 디렉터리, l은 심볼릭 링크, -는 일반 파일, c나 b는 장치, p는 명명된 파이프, s는 소켓을 표시합니다. 실제 읽기, 쓰기, 실행 비트를 담는 것은 그 뒤의 아홉 글자뿐입니다.

권한에서 소문자 s와 대문자 S의 차이는 무엇인가요?

소문자 s와 대문자 S는 둘 다 setuid 또는 setgid 비트가 설정됐음을 뜻합니다. 소문자 s는 실행도 함께 설정된, 정상적으로 작동하는 경우입니다. 대문자 S는 특수 비트는 켜졌지만 실행은 꺼진(4644가 그 예) 상태로, 특수 비트는 실행 없이는 의미가 없으므로 거의 항상 잘못된 설정입니다.

umask란 무엇이며 기본 권한을 어떻게 결정하나요?

umask는 파일이 생성될 때 꺼지는 권한 비트의 집합입니다. 새 파일은 기준값 666에서, 디렉터리는 777에서 시작하고, 그다음 effective = base & ~umask가 가려진 비트를 제거합니다. 기본값 022는 644 파일과 755 디렉터리를 만듭니다. 자신의 값을 보려면 umask를, 더 비공개인 기본값을 원하면 umask 077을 실행하십시오.

644나 755 대신 400이나 700은 언제 써야 하나요?

파일이나 디렉터리를 완전히 비공개로 유지해야 할 때 400이나 700을 사용하십시오. 400(r--------)은 읽기 전용 비공개 파일로, 두 번 다시 편집하지 않을 최종 SSH 개인 키에 이상적입니다. 700(rwx------)은 ~/.ssh나 ~/.gnupg처럼 소유자만 들어갈 수 있는 디렉터리입니다. 644나 755와 달리, 이들은 다른 누구에게도 아무것도 부여하지 않습니다.

디렉터리 목록은 볼 수 있는데 왜 cd로 들어갈 수는 없나요?

디렉터리 권한은 목록 조회와 통과를 나눕니다. r 비트는 이름 목록을 볼 수 있게 하고, x 비트는 들어갈 수 있게 합니다. x 없이 r만 있는 디렉터리(644 디렉터리)는 ls로 이름은 보여 주지만 cd와 안쪽 파일에 대한 모든 접근은 막습니다. 들어갈 수 있게 하려면 실행 권한을 더하십시오(755로 설정).

파일 권한은 macOS에서도 리눅스와 똑같이 작동하나요?

둘 다 POSIX를 따르므로 핵심적인 rwx와 8진수 모델은 양쪽에서 동일하지만, 세부 사항은 다릅니다. BSD와 macOS는 숫자 방식의 chmod에서 기본적으로 디렉터리의 setuid/setgid를 지우는 반면, 리눅스는 이를 보존합니다. 모드를 읽는 방법도 다릅니다. 리눅스에서는 stat -c '%a' file, macOS에서는 stat -f '%Lp' file이며, macOS는 ACL과 파일 플래그를 추가로 둡니다.

명령줄 없이도 파일 권한을 바꿀 수 있나요?

터미널 없이도 권한을 계산하고 해독할 수 있습니다. 무료 chmod 계산기에서는 권한 행렬을 체크하거나, 8진수 값을 입력하거나, ls -l 한 줄을 붙여넣으면 정확한 chmod 명령어를 되돌려 복사해 줍니다. 다만 실제 파일에 적용하려면 여전히 서버에서 그 명령어를 실행하거나, 권한 필드를 노출하는 GUI 또는 FTP 클라이언트가 필요합니다.