chmod 권한 숫자(644·755·777) 더는 검색하지 마세요 - 리눅스 파일 권한표 총정리

 

리눅스에서 파일 권한 644, 755, 777이 정확히 무슨 뜻인지 매번 헷갈려서 검색하게 됩니다. 이 글은 chmod 숫자 권한의 원리부터 자주 쓰는 조합, 상황별 추천 권한, setuid·setgid·sticky bit 같은 특수 권한까지 표로 정리한 개발자·서버 관리자용 레퍼런스입니다.

 

 

"chmod 755였나 644였나... 또 검색하네."
"안 되면 그냥 777 주면 되던데?"
"그러다 보안 점검에서 한 소리 들어요."

 

 

파일 권한은 별거 아닌 것 같지만, 사실 서버 보안의 가장 첫 단추입니다. 웬만한 해킹 시나리오가 잘못 열어둔 파일 권한에서 시작하니까요. 그런데 정작 현장에서는 "안 되면 일단 777" 하고 넘어가는 경우가 많죠. 저도 신입 때 그랬습니다. 그래서 chmod 숫자가 어떻게 만들어지는지, 어떤 상황에 뭘 줘야 하는지를 한 번에 정리해두려고 합니다.

숫자 권한이 헷갈리는 분, 배포할 때마다 권한 때문에 고생하는 분, "이 파일엔 몇을 줘야 하지" 싶을 때 즐겨찾기를 열어 바로 베껴 쓸 표가 필요한 분께 맞춰 썼습니다.

📋 목차

1. 리눅스 파일 권한, 누구에게 줄지부터 정합니다 (소유자·그룹·기타)
2. chmod 권한 숫자 계산법 - 그냥 더하기입니다
3. chmod 755·644·777 자주 쓰는 권한표
4. 디렉터리 권한과 파일 권한, x의 의미가 다릅니다
5. 특수 권한(setuid·setgid·sticky bit) - 네 자리가 나오는 이유
6. 상황별 추천 권한 - 웹 파일·SSH 키·로그
7. chmod 명령어 사용법 - 숫자 방식과 문자 방식
8. 파일 권한 보안 - 해킹은 보통 권한에서 시작합니다
9. 자주 묻는 질문(FAQ)

1. 리눅스 파일 권한, 누구에게 줄지부터 정합니다 (소유자·그룹·기타)

리눅스 권한은 읽기(r)·쓰기(w)·실행(x) 세 가지를 누구에게 줄지 정하는 겁니다. 그 "누구"가 세 부류로 나뉘는데, 이게 단순해 보여도 막상 실무에서 자주 발목을 잡습니다.

먼저 권한 한 줄이 어떻게 끊어 읽히는지 보겠습니다. ls -l에서 보이는 -rwxr-xr-x는 사실 이렇게 네 토막으로 나뉩니다.

-

종류

rwx

소유자

r-x

그룹

r-x

기타

맨 앞 한 글자는 파일 종류(-는 파일, d는 디렉터리)이고, 나머지 9칸을 셋씩 끊으면 차례대로 소유자·그룹·기타의 권한이 됩니다. 그 "누구"가 정확히 누구냐가 가장 헷갈리는 부분인데, 정리하면 이렇습니다.

소유자 (user, u)

파일을 가진 단 하나의 계정. 보통 만든 사람이고, chown으로 바꿉니다.

그룹 (group, g)

파일에 지정된 그룹 하나. 그 그룹에 속한 계정들이 여기 묶입니다.

기타 (other, o)

소유자도, 그 그룹 소속도 아닌 나머지 전부입니다.

여기서 가장 많이 오해하는 게 있습니다. 이 셋은 "순서대로 권한이 쌓이는" 게 아니라, 내가 누구냐에 따라 딱 한 묶음만 적용된다는 점입니다. 내가 그 파일의 소유자라면 소유자 권한만 적용되고, 그룹이나 기타 권한은 나에게 아무 영향을 주지 않습니다.

그래서 가끔 황당한 상황이 생깁니다. 소유자 권한은 읽기가 막혀 있는데 그룹엔 읽기가 열려 있는 파일을 보면, "나도 그 그룹 멤버인데 왜 못 읽지?" 싶죠. 하지만 내가 소유자인 이상 소유자 권한(여기선 차단)이 먼저 걸려서 못 읽습니다. 권한은 "더 열린 쪽"이 아니라 "내 신분에 해당하는 쪽"을 따른다는 겁니다. 이거 하나만 잡아도 권한 디버깅이 한결 수월해집니다.

그런데 "왜 하필 소유자·그룹·기타 세 단계일까?" 하고 들여다보면 시대적 배경이 있습니다. 이 권한 모델은 한 대의 서버에 여러 사람이 각자 계정을 받아 같이 쓰던 시절에 만들어졌습니다. 1970년대 유닉스가 그랬고, 한국에서도 2000년대 초반까지는 대학 전산실이나 회사 공용 서버 한 대에 교수·학생·조교, 또는 팀원 여럿이 동시에 로그인해서 작업하는 게 흔했죠.

그 환경에서 세 단계는 정말 잘 맞아떨어졌습니다.

 

 

예를 들어 공용 서버에서 제가 짠 코드 파일이 있다고 해봅시다.

저(소유자)는 읽고 쓰고,

같은 연구실 사람들(그룹)은 읽기만 하게 열어두고,

옆 연구실 학생(기타)은 아예 못 보게 막고 싶을 때

→ 권한을 640으로 주면 한 서버 안에서 이게 깔끔하게 정리됐습니다.

컴퓨터 한 대를 수십 명이 나눠 쓰는데

서로의 파일이 뒤엉키지 않으려면 이런 구분이 꼭 필요했던 거죠.

 

 

지금은 이 그림이 많이 바뀌었습니다. 컨테이너(Docker)와 클라우드가 보편화되면서, 서버 한 대에 사람 여러 명이 로그인해 부대끼는 구조는 상당히 사라졌습니다. 컨테이너 하나가 사실상 하나의 역할만 맡고, 사람이 그 안에 직접 들어가 사는 일이 드무니까요. 그래서 "여러 명의 실제 사용자를 그룹으로 묶는다"는 원래 쓸모는 예전만큼 와닿지 않습니다.

다만 개념이 없어진 게 아니라 의미가 옮겨갔습니다. 요즘 그룹은 사람보다 프로세스·서비스 계정을 묶는 데 더 많이 쓰입니다. 모양은 1970년대 그대로인데, 그 안을 채우는 주인공이 사람에서 프로세스로 바뀐 셈이죠. 그래서 지금도 모든 리눅스 파일에 이 세 칸이 박혀 있고, 모르면 권한 디버깅에서 막힙니다.

 

 

💡 그룹은 지금도 협업할 때 빛납니다

웹 서버가 www-data 사용자로 돌아갈 때,

개발자 계정을 www-data 그룹에 넣어두면 소유자를 건드리지 않고도

그룹 권한만으로 같은 파일을 함께 다룰 수 있습니다.

"한 명(또는 한 프로세스)이 소유하되,

정해진 팀만 같이 만지게" 하고 싶을 때 쓰는 게 그룹입니다.

 

 

실제로 ls -l을 찍으면 이렇게 나옵니다.

 

 

-rw-r--r-- 1 user_name developers 2048 Jun 23 10:00 config.yml

 

 

여기서 세 번째 칸 user_name 가 소유자, 네 번째 칸 developers가 그룹입니다. 맨 앞 -rw-r--r--에서 첫 글자는 파일 종류(-는 파일, d는 디렉터리)이고, 나머지 9칸을 셋으로 끊으면 rw-(소유자) / r--(그룹) / r--(기타)가 됩니다. 즉 소유자 user_name 는 읽기쓰기, developers 그룹은 읽기, 그 외 전부도 읽기인 파일이죠. 이 구조만 눈에 들어오면 나머지는 전부 응용입니다.

2. chmod 권한 숫자 계산법 - 그냥 더하기입니다

각 권한에는 숫자가 붙어 있습니다. 읽기(r)는 4, 쓰기(w)는 2, 실행(x)은 1. 이걸 더하면 한 자리 숫자가 나옵니다. rwx면 4+2+1=7, rw-면 4+2=6, r-x면 4+1=5인 식이죠.

이렇게 나온 한 자리 숫자를 소유자 / 그룹 / 기타 순으로 세 개 늘어놓은 게 755, 644 같은 권한입니다. 755라면 소유자 7(rwx), 그룹 5(r-x), 기타 5(r-x)인 거고요. 원리만 알면 표 없이도 계산되지만, 바쁠 땐 그냥 표 보는 게 빠릅니다.

숫자	권한	의미
7	rwx	읽기+쓰기+실행
6	rw-	읽기+쓰기
5	r-x	읽기+실행
4	r--	읽기만
3	-wx	쓰기+실행
2	-w-	쓰기만
1	--x	실행만
0	---	권한 없음

3. chmod 755·644·777 자주 쓰는 권한표

이 글의 핵심입니다. 실무에서 마주치는 권한은 사실 몇 개로 정해져 있습니다. 아래 표만 즐겨찾기 해두셔도 검색할 일의 대부분이 사라집니다.

반응형

숫자	표기	누가 뭘 할 수 있나	주로 쓰는 곳
755	rwxr-xr-x	소유자 전부, 나머지 읽기+실행	디렉터리, 실행 스크립트, 웹 폴더
644	rw-r--r--	소유자 읽기쓰기, 나머지 읽기	일반 파일, HTML·이미지 등 웹 파일
700	rwx------	소유자만 전부, 나머지 차단	개인 전용 디렉터리
600	rw-------	소유자만 읽기쓰기	SSH 개인키, 민감한 설정 파일
750	rwxr-x---	소유자 전부, 그룹 읽기+실행, 기타 차단	협업 디렉터리
640	rw-r-----	소유자 읽기쓰기, 그룹 읽기, 기타 차단	설정·로그 파일
444	r--r--r--	모두 읽기만	수정 막을 읽기 전용 파일
777	rwxrwxrwx	모두 전부	임시 테스트 외 비권장

 

📌 외우려 하지 마세요

실무의 90%는 755(디렉터리·실행)와 644(파일)면 끝납니다.

나머지는 필요할 때 표에서 찾아 쓰면 됩니다.

즐겨찾기 해두고 베껴 쓰는 게 이기는 길입니다.

 

4. 디렉터리 권한과 파일 권한, x의 의미가 다릅니다

같은 실행 비트(x)라도 파일과 디렉터리에서 뜻이 다릅니다. 이걸 모르면 "디렉터리에 644 줬는데 왜 못 들어가지?" 하고 한참 헤맵니다.

- 파일에서 x: 그 파일을 프로그램으로 실행할 수 있다
- 디렉터리에서 x: 그 디렉터리 안으로 들어가(접근할) 수 있다

그래서 디렉터리는 읽기만으로는 부족하고 실행 비트까지 줘서 755나 750을 씁니다. 파일은 실행할 필요가 없으면 644로 충분하고요. 웹 서버에서 폴더는 755, 안에 든 파일은 644 — 이 조합이 거의 기본값처럼 굳어진 이유가 여기 있습니다.

5. 특수 권한(setuid·setgid·sticky bit) - 네 자리가 나오는 이유

가끔 4755, 1777처럼 네 자리 권한을 봅니다. 앞에 붙은 한 자리가 특수 권한입니다.

- setuid (4): 실행할 때 파일 소유자의 권한으로 동작합니다. 대표가 /usr/bin/passwd인데, 비밀번호를 바꾸려면 root만 건드릴 수 있는 파일을 손대야 해서 일반 사용자가 실행해도 root 권한으로 돌아갑니다.
- setgid (2): 실행 시 그룹 권한으로 동작합니다. 디렉터리에 걸면 그 안에 새로 만든 파일이 디렉터리의 그룹을 물려받아서, 여러 명이 같이 쓰는 폴더에서 편합니다.
- sticky bit (1): 디렉터리에 걸면 파일을 만든 사람(과 root)만 자기 파일을 지울 수 있습니다. 모두가 쓰는 /tmp가 1777인 이유죠.

 

💡 setuid는 양날의 검

편한 만큼 위험합니다. 잘못 걸린 setuid 파일 하나가 권한 상승 공격의 통로가 되기도 합니다.

find / -perm -4000으로 시스템에 어떤 setuid 파일이 있는지 가끔 점검해두면 마음이 편합니다.

 

6. 상황별 추천 권한 - 웹 파일·SSH 키·로그

"이건 몇을 줘야 하지" 싶을 때 바로 보는 표입니다.

대상	추천	이유
웹 디렉터리	755	서버 프로세스가 접근해야 함
웹 파일(HTML·CSS·JS·이미지)	644	읽기만 되면 충분, 실행 불필요
실행 스크립트(.sh)	755 / 700	실행 비트 필요, 노출 줄이려면 700
설정 파일(.env, DB 정보)	600 / 640	노출되면 큰일 나는 파일
SSH 개인키	600	그 외엔 아예 접속 거부됨
로그 파일	640 / 644	프로세스가 쓰고, 필요 시 읽기
업로드 파일 저장 폴더	644(실행 비트 제거)	절대 실행되면 안 됨

여기서 한 가지 꼭 강조하고 싶은 게 있습니다. 사용자가 올리는 업로드 파일은 가능하면 앱 서버가 직접 들고 있지 말고, 실행이 안 되는 별도 파일 스토리지(S3 같은 오브젝트 스토리지)에 올려두고 다운로드만 내주는 구조를 권합니다. 업로드 폴더가 웹 루트 안에 있고 실행 권한까지 살아 있으면, 공격자가 악성 스크립트를 올린 뒤 그 주소로 직접 접속해 실행시키는 고전적인 웹쉘 공격이 그대로 통합니다. 파일은 파일 서버에, 앱은 앱 서버에 — 이렇게 역할만 분리해둬도 막을 수 있는 사고가 의외로 많습니다.

7. chmod 명령어 사용법 - 숫자 방식과 문자 방식

숫자 방식이 익숙하지만, 권한 일부만 손볼 때는 문자 방식이 더 편합니다.

- 대상: u(소유자) / g(그룹) / o(기타) / a(전체)
- 연산: +(추가) / -(제거) / =(지정)

예를 들면 이렇습니다.

- chmod 755 deploy.sh — 숫자로 한 번에 지정
- chmod u+x deploy.sh — 소유자에게 실행 권한만 추가
- chmod o-r secret.conf — 기타 사용자의 읽기 권한만 제거
- chmod -R 755 /var/www/html — 하위 전체에 재귀 적용

 

 

📌 -R(재귀)은 강력한 만큼 위험합니다

경로를 한 번 잘못 짚으면 하위 전체 권한이 한 방에 바뀝니다.

특히 /나 홈 디렉터리에 chmod -R 777 같은 걸 날리면,

복구하느라 밤새는 지름길입니다.

재귀 적용 전엔 경로를 두 번 확인하세요.

 

8. 파일 권한 보안 - 해킹은 보통 권한에서 시작합니다

앞에서도 말씀드렸지만, 권한 설정은 보안의 기본 중의 기본입니다. 현장에서 자주 보는 실수와 원칙을 정리해봅니다.

- 777 남발: "안 되니까 일단 777" — 가장 흔하고 가장 위험합니다. 사실 권한 문제는 다른 데(소유자, 상위 디렉터리, 실행 사용자)에 있는 경우가 대부분인데, 엉뚱하게 보안 구멍만 뚫고 넘어가는 거죠.
- SSH 개인키는 600: 키 파일 권한이 너무 열려 있으면 OpenSSH가 아예 접속을 거부합니다. 접속하려는데 키 권한이 열려 있다는 경고가 뜬다면 600으로 맞추면 됩니다.
- 웹 프로세스 권한은 최소로: 웹 서버가 돌아가는 사용자(www-data, nginx 등)에게는 꼭 필요한 디렉터리에, 꼭 필요한 권한만 줍니다. 이 사용자가 손댈 수 있는 범위가 곧 사고 났을 때의 피해 범위가 됩니다.
- 자동 배포(git) 권한 주의: CI/CD나 git pull로 자동 배포하는 경우, 배포 계정과 웹 실행 계정의 권한 경계를 분명히 해두는 게 좋습니다. 배포하면서 권한이 통째로 풀리거나, 배포 계정이 필요 이상으로 강한 권한을 쥐는 구성은 위험합니다.
- 로그 파일 권한: 프레임워크가 웹 사용자 권한으로 로그를 파일에 쌓는 경우가 많습니다. 로그 디렉터리 권한을 잘못 주면 로그가 안 쌓이거나(권한 부족), 반대로 아무나 읽을 수 있게 됩니다(과한 권한). 크롤러나 봇이 오류를 잔뜩 유발할 때 그 로그가 어디에 어떤 권한으로 쌓이는지도 한 번 점검해두면, 디스크가 꽉 차거나 민감 정보가 로그로 새는 사고를 줄일 수 있습니다.

 

 

💡 결국 원칙은 하나

"필요한 사람에게, 필요한 만큼만."

최소 권한 원칙(least privilege)이라고 부르는데,

권한을 줄 때 "이걸 풀면 누가 뭘 할 수 있게 되지?"를

한 번만 생각해도 사고의 절반은 막힙니다.

 

9. 자주 묻는 질문(FAQ)

리눅스 파일 권한 확인은 어떻게 하나요?

가장 간단한 건 ls -l 파일명입니다. -rw-r--r-- 형태로 소유자·그룹·기타 권한이 한 줄에 나옵니다. 더 자세히 보려면 stat 파일명을 쓰면 됩니다. 권한이 (0644/-rw-r--r--)처럼 숫자와 문자 표기로 같이 표시돼서, 숫자가 헷갈릴 때 확인용으로 좋습니다.

권한 644와 755 중 뭘 써야 하나요?

일반 파일은 644, 디렉터리와 실행 스크립트는 755가 기본입니다. 파일에 실행 권한이 필요 없다면 644로 충분합니다.

chmod 777은 왜 위험한가요?

누구나 읽고, 쓰고, 실행할 수 있다는 뜻이라 보안상 거의 항상 과합니다. 안 될 때는 권한 숫자보다 소유자(chown)나 상위 디렉터리 권한, 실행 사용자를 먼저 의심하는 게 맞습니다.

SSH 키 권한은 왜 600이어야 하나요?

개인키가 본인 외 다른 사용자에게 노출되면 OpenSSH가 보안상 접속을 거부합니다. 600(소유자만 읽기쓰기)으로 맞춰야 정상적으로 접속됩니다.

chmod -R는 안전한가요?

경로만 정확하면 안전하지만, 경로를 잘못 지정하면 하위 전체 권한이 한 번에 바뀝니다. 시스템 디렉터리나 홈 전체에 재귀 적용하는 건 특히 조심해야 합니다.

setuid는 언제 쓰나요?

일반 사용자가 더 높은 권한이 필요한 작업을 해야 할 때(예: 비밀번호 변경) 제한적으로 씁니다. 직접 설정할 일은 드물고, 보안상 함부로 늘리지 않는 게 좋습니다.

마무리

권한 숫자는 결국 4·2·1 더하기와 소유자·그룹·기타 세 묶음, 이 두 가지만 잡으면 끝납니다. 그런데 막상 바쁠 땐 그 계산조차 귀찮죠. 그래서 이 글은 외우라고 쓴 게 아니라, 필요할 때 열어서 표만 보고 가시라고 정리해뒀습니다. 그리고 권한은 단순히 "되게 만드는" 설정이 아니라 "사고를 막는" 첫 줄이라는 점만 기억해두시면, 적어도 777 갈겨놓고 나중에 후회하는 일은 줄어들 겁니다.

📚 함께 보면 좋은 글

SSL 인증서 유효기간 단축 - 1년에서 47일로, 무료 SSL 인증서 대응법

우분투(Ubuntu)는 왜 운영체제의 표준이 되었나? 이름 속에 숨겨진 인문학적 성공 비결

리눅스 계보도 정복하기: 유닉스에서 시작된 오픈소스 언어의 거대한 역사

웹개발자 MBTI 직무 추천 — 프론트엔드·백엔드·DBA 성향 궁합

Apache Nginx Tomcat 차이 완벽 정리 - 웹서버 30년 변천사로 이해하기