SPACE LOGBOOK

OCEAN LOGBOOK

Linux .. 파일의 소유권 개념

2026.09.01

Linux .. 파일의 소유권 개념

2026.09.01

서버를 만지다 보면 반드시 한 번은 마주치는 “Permission denied”. 그 뒤에 숨어있는 리눅스의 소유권 개념을 처음부터 끝까지 풀어본다.

왜 파일에 “소유자”가 있는가

윈도우즈로 PC를 쓸 때는 “이 파일은 누구 것인가”를 신경 쓸 일이 거의 없다. 내가 관리자니까 내 컴퓨터 안의 파일은 그냥 다 내 것이고, 다 열리고, 다 고쳐진다. 그런데 서버용 운영체제인 리눅스로 넘어오면 갑자기 chown, chmod, Permission denied 같은 낯선 단어들이 쏟아진다.

이건 리눅스가 태생부터 “한 컴퓨터를 여러 사람이 동시에 쓴다”는 전제로 설계됐기 때문이다. 대학 전산실 메인프레임 시절부터 이어진 사고방식이다. 지금은 서버 하나를 혼자 운영하더라도, 그 서버 안에는 사람 계정만 있는 게 아니라 웹서버 프로그램, 데이터베이스, 메일 시스템 같은 여러 프로세스가 저마다 자기 이름의 계정을 갖고 동시에 돌아간다. 이 여러 “입주자”들이 같은 파일 시스템을 공유하다 보니, “이 파일은 누가 만들었고 누가 손댈 수 있는가”를 파일 하나하나에 꼬리표로 박아둘 수밖에 없었던 것이다.

소유권의 3단 구조: 소유자 / 그룹 / 기타

리눅스는 파일 하나마다 접근 권한을 세 부류로 나눠서 관리한다.

  • 소유자(user/owner) — 그 파일을 만들었거나 할당받은 계정 딱 1명
  • 그룹(group) — 여러 계정을 하나로 묶어놓은 단위. 소유자가 어느 그룹에 속해있는지가 여기 연결된다
  • 기타(other) — 위 둘에 해당하지 않는 나머지 전부

그리고 이 세 부류마다 각각 읽기(r) · 쓰기(w) · 실행(x) 권한을 따로따로 줄 수 있다. ls -l로 파일 목록을 볼 때 나오는 다음과 같은 문자열이 바로 이 구조다.

– rwx r-x r-x 1  your-user  http  4096  page.php
타입 소유자 그룹 기타

맨 앞 10글자 중 첫 글자(-는 일반 파일, d는 디렉토리)를 빼면 나머지 9글자가 3글자씩 끊어서 소유자·그룹·기타 순으로 rwx를 나타낸다. 권한이 없는 자리는 -로 표시된다.

숫자로 줄여 쓰기 (755, 644, 777…)

rwx 각각에 숫자를 매겨서(r=4, w=2, x=1) 합산하면 세 자리 숫자 하나로 압축해서 표현할 수 있다. 서버 작업하다 보면 텍스트 표기보다 이 숫자 표기를 훨씬 자주 보게 된다.

권한의미숫자
rwx읽기+쓰기+실행 모두4+2+1 = 7
rw-읽기+쓰기만4+2 = 6
r-x읽기+실행만4+1 = 5
r–읽기만4

그래서 755는 “소유자는 다 되고(7=rwx), 그룹과 기타는 읽기·실행만 되고 쓰기는 안 됨(5=r-x)”이라는 뜻이다. 644는 “소유자만 쓸 수 있고 나머지는 읽기만”이라는 뜻이고, 777은 “누구나 다 됨” — 즉 아무 제약이 없는 상태다.

여기서 중요한 포인트 하나: 그룹에 속해 있다고 해서 자동으로 쓰기가 되는 게 아니다. 폴더가 755라면, 설령 내 계정이 그 폴더의 그룹 멤버여도 그룹 권한 자체가 r-x(읽기·실행만)이기 때문에 쓰기는 여전히 막혀 있다. “그룹에 속해있는데 왜 안 되지?”라는 의문은 대개 이 지점에서 생긴다.

서버 안의 “입주자”들: root, http, 그리고 나

Permission denied 메시지에 등장하는 계정 이름들이 각각 뭘 의미하는지 정리하면 이렇다.

root — 전지전능 계정

모든 권한 체크를 무시하고 뭐든 할 수 있는 최상위 계정이다. 윈도우즈의 “관리자”보다 훨씬 강력해서, 이 계정으로 직접 로그인하는 건 보통 막아두고 필요할 때만 잠깐 권한을 빌리는 방식을 쓴다. 그게 바로 sudo다.

sudo — 계정이 아니라 명령어

sudo는 계정 이름이 아니다. “이 한 줄만 root 권한으로 대신 실행해줘”라는 요청 명령어다. 앞에 비밀번호를 물어보는 건 root로 승격하기 전에 본인 확인을 하는 절차다. 서버 관리자가 특정 계정에 sudo 권한을 아예 안 준 경우에는 비밀번호를 넣어도 “not in sudoers” 같은 에러가 뜨며 막힌다.

http (또는 www-data, nginx, apache) — 웹서버 프로그램의 신분증

이건 사람이 로그인하는 계정이 아니라, Apache·Nginx·PHP-FPM 같은 웹서버 프로그램이 실제로 동작할 때 사용하는 전용 계정이다. 워드프레스가 관리자 화면에서 이미지 업로드를 처리하거나, 플러그인을 자동 업데이트하거나, 캐시 파일을 생성할 때 — 그 작업을 실제로 실행하는 주체는 사람이 아니라 이 웹서버 프로세스이고, 그렇게 만들어진 파일은 자동으로 이 계정 소유가 된다.

사람 계정 (예: SSH 로그인용 개인 계정)

SSH로 터미널을 붙여서 직접 명령을 치는 용도의 개인 계정이다. scp로 파일을 올리거나 에디터로 직접 코드를 고칠 때는 이 계정 권한이 적용된다.

같은 서버, 심지어 같은 워드프레스 사이트 안에서도 폴더마다 소유자가 제각각 섞여 있는 이유가 여기 있다. 그 파일을 누가/어떤 경로로 만들었는가에 따라 소유자가 갈린다.

· SSH로 직접 올리거나(scp) 만든 파일 → 사람 계정 소유
· 워드프레스 관리자 화면에서 업로드/설치/자동 업데이트한 파일 → 웹서버(http) 프로세스 소유

실제 사례: 테마 폴더에 배포가 막혔을 때

실제로 겪었던 상황을 예로 들면 이렇다. 어떤 워드프레스 테마 폴더는 통째로 http:http 소유에 755로 되어 있었다. SSH로 접속한 개인 계정은 http 그룹에 속해 있긴 했지만, 그룹 권한이 r-x(읽기·실행만)라서 쓰기가 전부 막혔다. scp로 파일을 올리는 것도, 백업 파일을 새로 만드는 것도 다 Permission denied였다.

반면 다른 테마 폴더는 예전에 개인 계정 소유로 바꾸고 777까지 열어둔 적이 있어서 문제없이 되고 있었다. 하지만 777은 “기타(other)” 계정까지 전부 쓰기를 허용하는 것이므로, 서버에 다른 취약한 프로세스나 침입 경로가 있다면 그 폴더를 마음대로 조작당할 수 있는 위험한 설정이다. “예전에 이렇게 해서 됐다”가 “안전한 방법이었다”를 뜻하지는 않는다.

절충안: 소유자는 사람 계정, 그룹은 http, 권한은 775

이 상황에서 실제로 적용한 해법은 다음 두 줄이었다.

sudo chown -R your-user:http /경로/테마폴더
sudo chmod -R 775 /경로/테마폴더

이 조합이 왜 균형점인지 뜯어보면:

  • 소유자를 사람 계정으로 — sudo 없이도 바로 scp 업로드나 직접 파일 편집이 가능해진다
  • 그룹은 여전히 http로 — 워드프레스 관리자 화면의 “테마 파일 편집기” 저장, 자동 업데이트처럼 웹서버 프로세스가 파일을 쓰는 기능도 그대로 살아있다
  • 777이 아니라 775 — 기타(other) 계정은 여전히 쓰기 불가. 완전 개방이 아니라서 이전보다 보안이 후퇴하지 않는다

만약 소유자만 사람 계정으로 바꾸고 그룹을 신경 쓰지 않은 채 755로 끝냈다면, 이번엔 반대로 워드프레스 관리자 화면 쪽 기능(테마 편집기 저장, 자동 업데이트)이 깨질 수 있었다. 사람과 웹서버 프로세스, 이 두 “입주자”가 같은 폴더를 각자의 방식으로 건드려야 하는 상황이라, 소유자와 그룹을 각각 다른 주체에게 나눠주는 게 핵심이었다.

777을 피해야 하는 이유
777은 소유자·그룹뿐 아니라 “기타”까지 전부 rwx를 허용하는 설정이다. 서버 안의 아무 프로세스, 심지어 잠재적인 침입자까지 그 폴더를 마음대로 읽고 쓰고 실행할 수 있게 문을 열어두는 셈이다. 당장 편하다고 이 방식을 습관적으로 쓰면, 문제가 생겼을 때 피해 범위가 훨씬 커진다.

소유권·권한을 직접 바꾸는 명령어: chown, chgrp, chmod

지금까지는 “권한이 왜 이렇게 걸려있는가”를 봤다면, 이제 그걸 직접 바꾸는 명령어 세 가지를 정리해본다. 모두 파일 소유권 구조(소유자·그룹·rwx)를 그대로 조작하는 도구들이라, 앞서 설명한 개념과 그대로 대응된다.

chown — 소유자 바꾸기 (change owner)

파일/폴더의 소유자를 바꾼다. 소유자:그룹 형태로 둘을 한 번에 바꿀 수도 있다.

# 소유자만 변경
sudo chown your-user 파일명

# 소유자와 그룹을 동시에 변경
sudo chown your-user:http 파일명

# -R 옵션: 폴더 안의 모든 하위 파일까지 재귀적으로 적용
sudo chown -R your-user:http /경로/테마폴더

chgrp — 그룹만 바꾸기 (change group)

소유자는 그대로 두고 그룹만 바꾸고 싶을 때 쓴다. chown 소유자:그룹으로도 같은 결과를 낼 수 있지만, 그룹만 건드릴 게 확실할 때는 이 쪽이 더 명확하다.

sudo chgrp -R http /경로/테마폴더

chmod — 권한(rwx) 바꾸기 (change mode)

소유자/그룹/기타 각각에게 읽기·쓰기·실행을 얼마나 허용할지를 바꾼다. 숫자 표기(755, 775, 644…)를 그대로 인자로 넘긴다.

# 폴더 전체를 775로 (소유자·그룹은 rwx, 기타는 r-x)
sudo chmod -R 775 /경로/테마폴더

# 폴더와 파일을 다르게 주고 싶을 때 (더 정교한 방식)
sudo find /경로/테마폴더 -type d -exec chmod 775 {} \;
sudo find /경로/테마폴더 -type f -exec chmod 664 {} \;
셋 다 기본적으로 소유자 본인이나 root만 실행할 수 있다. 그래서 앞에 sudo가 거의 항상 붙는다 — “이 파일의 소유권/권한 자체를 바꾸는 일”은 그만큼 민감한 작업이라, 시스템이 함부로 아무나 못 하게 막아둔 것이다.

명령어에 자주 붙는 -R 옵션 (재귀적 적용)

위 예시들에 공통으로 붙어있는 -R은 재귀적(Recursive)이라는 뜻이다. “이 폴더 자체뿐 아니라, 그 안의 모든 하위 폴더와 파일까지 전부 다 똑같이 적용해달라”는 옵션이다.

# -R 없이: 테마폴더라는 껍데기 하나만 소유자 변경, 안의 파일들은 그대로
sudo chown your-user:http /경로/테마폴더

# -R 포함: 하위 파일·폴더까지 전부 재귀적으로 변경
sudo chown -R your-user:http /경로/테마폴더

워드프레스 테마 폴더처럼 안에 파일이 수십~수백 개 들어있는 경우, -R 없이는 폴더 껍데기만 바뀌고 속은 예전 소유자로 그대로 남아있게 된다. 그래서 chown·chgrp·chmod를 폴더 단위로 쓸 때는 거의 항상 -R을 같이 쓴다.

참고로 같은 “재귀”라는 의미인데도 명령어마다 대소문자가 다르다 — chown/chgrp/chmod는 대문자 -R, rm -r(폴더 삭제)·cp -r(폴더 복사)은 소문자 -r을 쓴다. 각 명령어가 서로 별개로 만들어지다 보니 관례가 통일되지 않은 것뿐이라, 헷갈리면 명령어 --help나 man 명령어로 확인하는 게 가장 확실하다.

흔한 함정: “그룹에 속해있는데 왜 안 될까”

실제로 자주 헷갈리는 부분이 있다. 어떤 계정을 http 그룹의 멤버로 추가해뒀는데도 여전히 쓰기가 막히는 경우다. 이건 그룹 멤버십과 그 폴더가 그룹에게 실제로 허용한 권한이 서로 다른 문제이기 때문이다.

비유하면 이렇다 — 사원증(그룹 멤버십)은 있어도, 건물 출입문(폴더)에 “직원은 들어올 수만 있고(읽기) 물건은 두고 갈 수 없음(쓰기 불가)”이라는 규칙이 붙어 있으면 사원증만으로는 쓰기가 안 되는 것과 같다. 폴더 권한이 755라면 그룹 자리가 r-x(쓰기 없음)이기 때문에, 그 그룹의 멤버라도 쓰기는 막혀 있다.

이럴 때 필요한 건 두 단계다.

  1. 그룹 자격 확인/부여 — 이 계정이 해당 그룹(예: http)에 속해 있는가 (chgrp는 파일 쪽 그룹을, 계정을 그룹에 넣는 건 별도 사용자 관리 화면/명령에서 처리)
  2. 그룹 권한 자체를 쓰기 가능하게 조정 — chmod로 그룹 자리를 r-x에서 rwx로(예: 755 → 775) 바꿔야 실제로 쓰기가 열린다

이 둘 중 하나만 되어 있으면 여전히 Permission denied가 난다. 자격(멤버십)과 권한(그 자격에 실제로 뭘 허용했는지)은 항상 같이 확인해야 하는 두 축이다.

참고 (Synology 같은 NAS 환경)
시놀로지 DSM처럼 유닉스 rwx 권한 위에 별도의 Windows식 ACL(공유 폴더 권한)을 한 겹 더 얹는 시스템도 있다. 이런 환경에서는 터미널에서 chmod로 권한을 바꿔도, DSM 제어판의 공유 폴더 권한 설정이 그 위에서 다시 덮어쓸 수 있다. rwx만 고쳤는데도 여전히 막힌다면, NAS 관리 화면 쪽 권한 설정도 함께 확인해야 한다.

정리

리눅스에서 “소유자”란 결국 이 서버 안에 사람 계정과 여러 프로그램 계정이 동시에 살고 있고, 파일 하나하나마다 그중 누가 만들었고 누가 건드릴 수 있는지를 명시해둔 꼬리표다. 윈도우즈 개인 PC에서는 “나 혼자 관리자”라 이 구분이 보이지 않을 뿐, 여러 주체가 파일을 공유하는 서버 환경에서는 필연적으로 드러나는 구조다.

권한 문제를 만났을 때 확인할 것은 결국 세 가지다.

  1. 이 파일의 소유자는 누구인가
  2. 이 파일의 그룹은 무엇이고, 나는 그 그룹에 속해 있는가
  3. 소유자/그룹/기타 각각에 읽기·쓰기·실행 중 무엇이 허용되어 있는가

이 세 질문에 답이 나오면, “왜 어떤 폴더는 되고 어떤 폴더는 안 되는지”가 더 이상 미스터리가 아니게 된다.

댓글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 기록은 여기까지지만,
생각은 아직 이동 중이다