A-3: 권한과 소유권

안녕하세요, 홍순구입니다. 지난 시간에 우리는 직접 파일을 만들고, 들여다보고, 옮기고, 안전하게 지우고, 찾아서 압축까지 해봤어요. 이제 리눅스 위에서 제법 손을 놀릴 줄 알게 됐습니다.

그런데 그 과정에서 자꾸 눈에 밟히던 게 하나 있었죠. ls -l을 칠 때마다 줄 맨 앞에 따라다니던 -rw-r--r-- 같은 10글자예요. 압축을 풀 때도 그 정보가 같이 살아난다고 했고요. 그때마다 "이건 권한이라는 건데, 읽는 법은 다음 시간에 배운다"고 미뤄뒀습니다. 오늘이 바로 그 다음 시간이에요. 드디어 이 10글자의 정체를 밝힙니다.

왜 권한이라는 게 있을까요? 리눅스는 처음부터 여러 사람이 컴퓨터 한 대를 나눠 쓰는 환경으로 태어났어요. 회사 서버 한 대에 여러 개발자가 각자 자기 계정으로 들어와 일하는 거죠. 그러면 "이 파일은 내 것, 저 설정은 관리자만"처럼 누가 무엇을 건드릴 수 있는지 칼같이 나눠야 합니다. 그 약속이 바로 권한이에요.

이게 왜 실전에서 중요하냐면 — 서버를 다루다 보면 누구나 한 번쯤 빨간 글씨로 Permission denied(권한 거부)를 만나거든요. 신입 때 이걸 만나면 당황해서 일단 sudo(관리자 권한)부터 붙이고 보는 경우가 많아요. 그런데 그 10글자를 읽을 줄 알면 "아, 이건 내 파일이니까 chmod로 풀면 되네" 또는 "이건 시스템 파일이라 정말 관리자 권한이 필요하구나"를 바로 구분할 수 있습니다. 무작정 sudo를 남발하다 사고 내는 일을 막아주는 거예요.

오늘 우리가 걸어갈 길을 한눈에 그려둘게요.

  [나는 누구인가]  whoami·id·groups   →   [권한 10글자 읽기]  ls -l
       │
       ▼
  [권한 바꾸기]  chmod  (u+x · 755)   →   [주인 바꾸기]  chown·chgrp
       │
       ▼
  [관리자 권한]  sudo   →   [기본 권한]  umask   →   [링크]  ln · ln -s

조금 낯선 단어가 많아 보여도 걱정 마세요. 하나씩 "왜 필요한지"부터 풀어가며 천천히 갈 테니 편하게 따라오면 됩니다.

💡 오늘 수업의 핵심 — "권한 10글자를 읽고, chmod로 바꿔, Permission denied를 스스로 푼다"

내가 누구이고 어떤 그룹에 속하는지 확인하고, ls -l 줄 맨 앞 10글자를 읽어 누가 무엇을 할 수 있는지 파악하고, chmod로 권한을 바꾸고, chown으로 주인을 바꾸고, sudo가 왜 필요하고 왜 위험한지 이해하고, umask와 링크(ln)까지 — 여기까지가 오늘의 목표입니다.

🎯 학습 목표

• 멀티유저 리눅스에서 내 정체(whoami·id·groups)를 확인하고, ls -l의 권한 10글자를 owner/group/others × rwx로 읽어낸다
• chmod로 권한을 바꾸고(기호 모드 u+x·8진수 모드 755), chown/chgrp로 소유자·그룹을 바꾼다
• sudo가 왜 필요하고 왜 위험한지 이해해 Permission denied를 무작정 sudo로 때우지 않고 스스로 풀며, umask와 하드/심볼릭 링크(ln)까지 다룬다

Step 1: "여럿이 한 서버를 나눠 쓴다 — 나는 누구인가"

권한 이야기를 하려면, 먼저 "누가 있는가"부터 알아야 해요. 권한이란 결국 "누가 무엇을 할 수 있는가"의 문제니까요.

내 노트북은 보통 나 혼자 씁니다. 그런데 회사의 리눅스 서버는 달라요. 여러 개발자가 각자 자기 계정으로 같은 서버에 들어와 일합니다. 비유하자면 여러 사람이 함께 쓰는 공유 사무실 같은 거예요. 각자 자기 사물함이 있고, 공용 회의실은 함부로 못 바꾸죠.

   리눅스 서버 한 대 = 여러 사람이 함께 쓰는 공유 사무실

     root              ← 관리자(슈퍼유저). 모든 문을 여는 마스터키를 가진 단 한 명
      ├─ alice         ← 개인 사물함 /home/alice (자기 것만 손댈 수 있음)
      ├─ bob           ← 개인 사물함 /home/bob
      └─ www-data      ← 웹 서버가 쓰는 전용 계정 (사람이 아니라 서비스용)

     공용 공간(/etc·/var 등)은 보통 root 만 고칠 수 있다

여기서 가장 중요한 이름이 root예요. root는 이 서버의 관리자 계정, 흔히 슈퍼유저(superuser)라고 부릅니다. 모든 파일을 읽고 쓰고 지울 수 있는, 말 그대로 마스터키를 가진 계정이에요. 그래서 강력한 만큼 위험합니다 — root로 명령 하나 잘못 치면 서버 전체가 날아갈 수도 있거든요. 그래서 평소엔 root로 직접 일하지 않고, 우리 같은 일반 계정(alice)으로 일하다가 꼭 필요할 때만 잠깐 관리자 권한을 빌려 씁니다. 그 "잠깐 빌리는" 명령이 오늘 뒤에서 배울 sudo예요.

그리고 www-data 같은 계정도 보이죠? 사람만 계정을 갖는 게 아니에요. 웹 서버 같은 프로그램도 자기 전용 계정으로 돌아갑니다. "이 서비스는 딱 이만큼만 할 수 있게" 권한을 가둬두기 위해서예요.

자, 그럼 지금 서버에 들어와 있는 나는 누구인지부터 확인해볼게요. 세 가지 명령을 써봅니다.

whoami

alice

whoami는 말 그대로 "who am I", 지금 내가 누구로 로그인해 있는지 계정 이름을 알려줘요. 서버 여러 대를 옮겨 다니다 보면 "지금 내가 어느 계정이지?" 헷갈릴 때가 많은데, 그때 한 번 쳐보는 명령입니다.

이름만으론 부족해요. 내가 어떤 그룹에 속하는지도 알아야 권한을 이해할 수 있거든요.

id

uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),100(users)

조금 복잡해 보이지만 천천히 읽으면 됩니다. uid는 사용자 번호(user id), gid는 기본 그룹 번호(group id)예요. 리눅스는 속으로는 이름이 아니라 숫자로 사람을 구분합니다. 그리고 뒤의 groups=...가 중요해요 — 내가 속한 모든 그룹의 목록이에요. 여기 sudo라는 그룹이 보이죠? alice가 sudo 그룹에 속해 있다는 건 "이 사람은 관리자 권한을 빌릴 자격이 있다"는 뜻이에요. 이게 뒤에서 sudo 명령을 쓸 수 있는 근거가 됩니다.

그룹만 따로 보고 싶으면 더 간단한 명령도 있어요.

groups

alice sudo users

왜 그룹이 중요할까요? 권한은 세 부류로 나뉘거든요 — 소유자(나) / 그룹 / 그 외 모두. 예를 들어 개발팀 폴더를 만들고 "개발팀 그룹에 속한 사람만 읽게" 설정하면, 일일이 사람을 지정하지 않고 그룹 하나로 여러 명을 한 번에 다룰 수 있어요. 공유 사무실에서 "마케팅팀 출입증을 가진 사람만 이 방에 들어올 수 있음" 같은 거죠.

현업 서버에선 새 팀원이 들어오면 그 사람 계정을 적절한 그룹에 넣어주는 것부터 시작해요. 그래야 팀 공용 폴더에 접근할 수 있거든요. 그래서 id로 "이 사람이 어느 그룹에 속하나"를 확인하는 게 권한 문제를 풀 때 첫걸음입니다.

💡 한 줄 정리

리눅스는 여러 사람이 나눠 쓰는 멀티유저 환경이라 권한을 소유자/그룹/그 외로 나눈다. whoami로 내 이름을, id/groups로 내가 속한 그룹을 확인한다. 관리자 계정은 root(슈퍼유저)다.

Step 2: "줄 맨 앞 10글자의 정체 — 권한 비트 읽기"

드디어 그 10글자를 해부할 시간이에요. 지난 시간 내내 ls -l을 칠 때마다 따라다니던 -rw-r--r-- 말이에요.

먼저 연습할 파일을 준비해볼게요. 지난 시간에 만든 연습장으로 가서, 간단한 스크립트 파일 하나와 메모 파일 하나를 만들어둡니다. (스크립트 내용이 뭔지는 지금 몰라도 돼요. A-11에서 본격적으로 배웁니다.)

cd ~/practice
echo '#!/bin/bash' > backup.sh
echo 'echo "백업 시작"' >> backup.sh
touch notes.txt
ls -l

-rw-r--r-- 1 alice alice  35 Jun 16 10:30 backup.sh
-rw-r--r-- 1 alice alice   0 Jun 16 10:30 notes.txt

자, 줄 맨 앞의 -rw-r--r--를 보세요. 이 10글자가 오늘의 주인공입니다. 이 한 덩어리가 "누가 이 파일을 읽고, 쓰고, 실행할 수 있는가"를 전부 말해줘요. 어떻게 읽는지 그림으로 쪼개볼게요.

      -  rwx  r-x  r-x      (예시로 -rwxr-xr-x 를 펼침)
      ┃   ┃    ┃    ┗━━  others : 그 외 모두에게 허용된 권한
      ┃   ┃    ┗━━━━━━━  group  : 같은 그룹 구성원에게 허용된 권한
      ┃   ┗━━━━━━━━━━━━  owner  : 파일 주인에게 허용된 권한
      ┗━━━━━━━━━━━━━━━━  파일 종류 : - 일반파일 · d 디렉토리 · l 링크

10글자는 사실 1글자 + 3글자 묶음 세 개로 되어 있어요.

• 맨 앞 1글자: 파일의 종류예요. -면 일반 파일, d면 디렉토리(directory), l이면 링크(link, 오늘 Step 8에서 배워요). 지난 시간에 ls -l을 쳤을 때 폴더는 d로 시작했던 거 기억나죠?
• 나머지 9글자: 3글자씩 세 묶음이에요. 순서대로 owner(소유자) → group(그룹) → others(그 외 모두).

그리고 각 묶음의 세 글자는 언제나 같은 순서로 와요.

      각 칸의 세 글자는 언제나  r → w → x  순서

        r (read)    : 읽기   — 내용을 보거나 복사할 수 있다
        w (write)   : 쓰기   — 내용을 고치거나 지울 수 있다
        x (execute) : 실행   — 프로그램·스크립트로 실행할 수 있다
                               (디렉토리에선 "그 안으로 들어갈 수 있다")
        - (대시)     : 그 권한이 꺼져 있다

이제 우리 파일 -rw-r--r--를 다시 읽어볼까요?

• 맨 앞 - → 일반 파일
• rw- (owner) → 주인은 읽기·쓰기 가능, 실행은 불가
• r-- (group) → 그룹은 읽기만
• r-- (others) → 그 외 모두도 읽기만

그러니까 "이 파일은 주인만 고칠 수 있고, 나머지는 읽기만 할 수 있다"는 뜻이에요. 일반 텍스트 파일의 가장 흔한 권한이 바로 이거예요.

한 가지 짚을 게 있어요. x(실행)가 디렉토리에 붙으면 의미가 살짝 달라져요. 파일에서 x는 "이 파일을 프로그램으로 실행할 수 있다"인데, 디렉토리에서 x는 "그 폴더 안으로 들어갈(cd 할) 수 있다"예요. 그래서 폴더 권한엔 x가 거의 항상 붙어 있습니다. x가 없으면 폴더가 보여도 안으로 못 들어가거든요.

ls -l 출력에서 권한 바로 다음에 이름이 두 번 나오는 것도 기억해두세요 — alice alice. 앞은 소유자, 뒤는 그룹 이름이에요. 이게 "누구의 owner 권한이고 누구의 group 권한인지"를 알려줍니다. Step 5에서 이 이름을 바꾸는 법(chown)을 배워요.

현업에서 Permission denied를 만나면 가장 먼저 하는 게 바로 이거예요. ls -l로 그 파일의 10글자를 읽고, "내가 owner인가? 그럼 owner 칸에 필요한 권한이 켜져 있나?"를 확인하는 거죠. 여기서 답이 거의 다 나옵니다.

💡 한 줄 정리

ls -l 맨 앞 10글자 = 파일종류 1글자 + (owner·group·others) × (r·w·x). 켜진 권한은 글자, 꺼진 권한은 -. 디렉토리의 x는 "들어갈 수 있다"는 뜻이다.

Step 3: "방금 만든 스크립트에 실행권한 — chmod 기호 모드"

지난 시간 예고에서 "방금 만든 스크립트에 실행권한을 주려면?" 같은 상황을 다룬다고 했죠. 바로 지금이에요.

Step 2에서 만든 backup.sh를 다시 볼게요. 이건 사실 스크립트(자동 실행되는 명령 묶음)인데, 권한이 -rw-r--r--라 실행 권한(x)이 하나도 없어요. 이 상태로 실행하려고 하면 리눅스가 거부합니다.

./backup.sh

bash: ./backup.sh: Permission denied

또 그 빨간 메시지죠? 이번엔 당황하지 않아요. ls -l backup.sh로 10글자를 읽어보면 rw-r--r--, 어디에도 x가 없어요. "아, 실행 권한이 꺼져 있어서 막혔구나"가 바로 보입니다. 그럼 켜주면 되겠죠. 권한을 바꾸는 명령이 chmod예요. change mode의 줄임말이에요.

chmod엔 두 가지 방식이 있는데, 오늘은 더 직관적인 기호 모드부터 배웁니다. 기호 모드는 "누구에게 + 어떤 권한을 - 켜고 끈다"를 글자로 그대로 쓰는 방식이에요.

chmod u+x backup.sh
ls -l backup.sh

-rwxr--r-- 1 alice alice 35 Jun 16 10:30 backup.sh

owner 칸이 rw-에서 rwx로 바뀌었죠? u+x를 글자 그대로 읽으면 "user(소유자)에게 +(추가) execute(실행) 권한"이에요. 이제 실행이 됩니다.

./backup.sh

백업 시작

방금 우리가 만든 스크립트가 진짜로 실행됐어요. (이 #!/bin/bash로 시작하는 스크립트를 본격적으로 짜는 건 A-11에서 다뤄요. 오늘은 "실행 권한을 줘야 돌아간다"는 것만 손에 익히면 됩니다.)

기호 모드의 문법을 정리해볼게요. 세 부분을 조합하는 거예요.

      chmod   [누구에게]  [+ 또는 -]  [어떤 권한]   파일명

      누구에게        켜고 끄기        어떤 권한
        u  소유자        +  추가          r  읽기
        g  그룹          -  제거          w  쓰기
        o  그 외         =  이것만 설정    x  실행
        a  전체(ugo)

몇 가지 더 써볼게요.

chmod g+w notes.txt      # 그룹에게 쓰기 권한 추가
chmod o-r notes.txt      # 그 외 사람의 읽기 권한 제거
chmod a+r notes.txt      # 모두에게 읽기 권한 추가
chmod u+x,g+x backup.sh  # 소유자와 그룹에 실행 권한 한 번에

+는 더하고, -는 빼고, =는 "딱 이것만"으로 덮어써요. 예를 들어 chmod u=rw notes.txt는 "소유자 권한을 읽기·쓰기로 딱 맞춰라"라서, 원래 있던 실행 권한이 있었다면 그건 꺼집니다.

현업에서 스크립트를 새로 짜서 서버에 올리면 거의 항상 chmod +x 스크립트.sh부터 쳐요. 안 그러면 방금처럼 Permission denied로 안 돌아가거든요. 그래서 이 명령이 손에 제일 먼저 익는 권한 명령 중 하나예요. (chmod +x처럼 누구를 생략하면 기본적으로 전체에 적용돼요.)

💡 한 줄 정리

chmod로 권한을 바꾼다. 기호 모드는 chmod u+x 파일처럼 "누구에게(u·g·o·a) + 켜고 끄기(+·-·=) + 권한(r·w·x)"을 글자로 쓴다. 스크립트는 chmod +x 해야 실행된다.

Step 4: "권한을 숫자로 — chmod 8진수 모드"

기호 모드(u+x)는 직관적이라 한두 개 바꿀 때 편해요. 그런데 권한 전체를 한 번에 딱 정하고 싶을 때는 더 빠른 방식이 있어요. 바로 숫자(8진수) 모드예요. 현업 서버 설정이나 스크립트에서는 이 숫자 방식을 훨씬 많이 봅니다. chmod 755, chmod 644 같은 거요. 처음 보면 암호 같지만, 원리를 알면 5초면 읽혀요.

비밀은 이거예요. r·w·x 각각에 숫자를 매긴 거예요.

        r = 4        w = 2        x = 1        (없으면 0)

왜 하필 4·2·1일까요? 이 셋을 더하면 어떤 조합이든 겹치지 않고 딱 하나의 숫자가 나오기 때문이에요. 한 칸(세 글자)을 숫자 하나로 압축할 수 있는 거죠.

        r w x    r w x    r w x
        4 2 1    4 2 1    4 2 1     ← 각 칸을 4·2·1 의 합으로
        ━━━━━    ━━━━━    ━━━━━
          7        5        5       →  chmod 755
        4+2+1    4+0+1    4+0+1
         rwx      r-x      r-x
        owner    group    others

그러니까 755는 한 자리씩 끊어 읽으면 돼요. 첫 숫자는 owner, 둘째는 group, 셋째는 others.

• 7 = 4+2+1 = rwx (다 됨)
• 5 = 4+0+1 = r-x (읽기·실행, 쓰기 없음)
• 5 = 4+0+1 = r-x

자주 쓰는 조합 몇 개만 외워두면 거의 다 커버돼요.

        숫자    권한        흔히 쓰는 곳
        ────────────────────────────────────────────
        755   rwxr-xr-x   디렉토리, 실행 스크립트 (남들은 읽고 실행만)
        644   rw-r--r--   일반 파일 (주인만 수정, 남들은 읽기만)
        700   rwx------   나만 쓰는 개인 폴더 (남들은 접근 불가)
        600   rw-------   비밀 파일 (나만 읽고 쓰기 — SSH 키 등)

직접 써볼게요. Step 3에서 실행 권한을 준 backup.sh를 표준적인 755로 맞추고, notes.txt는 644로 맞춰봅니다.

chmod 755 backup.sh
chmod 644 notes.txt
ls -l

-rwxr-xr-x 1 alice alice 35 Jun 16 10:30 backup.sh
-rw-r--r-- 1 alice alice  0 Jun 16 10:30 notes.txt

backup.sh가 rwxr-xr-x(755)로, notes.txt가 rw-r--r--(644)로 깔끔하게 맞춰졌죠? 기호 모드로 하나씩 켜고 끄는 것보다, 권한 전체를 한 번에 정할 땐 숫자가 훨씬 빨라요.

그럼 기호 모드와 숫자 모드, 언제 뭘 쓰냐고요?

• 기호 모드(u+x): 지금 권한은 그대로 두고 딱 하나만 바꿀 때. "실행 권한만 추가" 같은 거요.
• 숫자 모드(755): 권한 전체를 처음부터 한 번에 정할 때. 기존 권한을 신경 쓸 필요 없이 통째로 덮어써요.

⚠️ 한 가지 주의. 숫자 모드는 항상 세 칸 전체를 덮어쓴다는 걸 기억하세요. chmod 644를 치면 "owner=rw, group=r, others=r"로 전부 다시 정해지는 거예요. 기호 모드처럼 "있던 거에 살짝 더하기"가 아니라, 통째로 새로 칠하는 거라 더 강력하고 그만큼 실수도 조심해야 합니다.

💡 한 줄 정리

권한을 숫자로도 쓴다. r=4·w=2·x=1을 칸별로 더해 세 자리(owner·group·others). 755=rwxr-xr-x, 644=rw-r--r--. 하나만 바꿀 땐 기호 모드, 전체를 한 번에 정할 땐 숫자 모드.

Step 5: "이 파일은 누구 것인가 — chown·chgrp"

지금까지는 "owner·group·others가 각각 뭘 할 수 있나"(권한)를 바꿨어요. 이번엔 한 발 더 나가서 "그 owner와 group이 누구인가"(소유권) 자체를 바꿔봅니다.

ls -l에서 권한 다음에 이름이 두 번 나왔던 거 기억하죠? 그게 소유자와 그룹이에요.

      -rw-r--r--  1  alice  alice  1024  Jun 16 11:00  report.txt
                     └─┬─┘  └─┬─┘
                       │      └──  그룹(group)
                       └─────────  소유자(owner)

이 report.txt는 소유자도 alice, 그룹도 alice예요. 그런데 상황을 상상해볼게요. 서버에서 어떤 파일을 bob에게 넘겨줘야 한다거나, 개발팀이 함께 쓰는 폴더라 그룹을 devteam으로 바꿔야 한다거나. 이럴 때 소유권을 바꾸는 명령이 chown(change owner)과 chgrp(change group)예요.

sudo chown bob report.txt

chown bob report.txt는 "이 파일의 주인을 bob으로 바꿔라"예요. 그룹까지 한 번에 바꾸려면 소유자:그룹 형태로 콜론(:)을 써요.

sudo chown bob:devteam report.txt
ls -l report.txt

-rw-r--r-- 1 bob devteam 1024 Jun 16 11:00 report.txt

소유자가 bob, 그룹이 devteam으로 바뀌었죠? 그룹만 바꾸고 싶으면 chgrp를 쓰거나, chown :devteam처럼 콜론 뒤만 적으면 돼요.

sudo chgrp devteam report.txt    # 그룹만 devteam 으로
sudo chown :devteam report.txt   # 위와 같은 효과 (소유자는 그대로)

그런데 눈치채셨나요? 위 명령들 앞에 전부 sudo가 붙어 있어요. 왜일까요? 생각해보면 당연해요 — 내가 내 파일을 아무에게나 "이제 네 거야" 하고 마음대로 넘길 수 있으면, 권한 체계가 무너지잖아요. 남의 파일을 가로채거나, 책임을 떠넘기는 장난도 가능해지고요. 그래서 소유권을 바꾸는 건 보통 관리자(root)만 할 수 있어요. 일반 사용자는 자기 파일이라도 주인을 남에게 넘기지 못합니다.

그러니까 chown/chgrp는 거의 항상 sudo와 함께 다녀요. 자연스럽게 다음 질문이 떠오르죠 — "그 sudo가 대체 뭔데?" 바로 다음 Step에서 제대로 파봅니다.

현업에선 배포 자동화나 서버 세팅 중에 chown을 자주 만나요. 예를 들어 웹 서버가 쓰는 폴더는 소유권을 www-data로 맞춰줘야 그 서버 프로세스가 파일을 읽고 쓸 수 있거든요. "분명 파일은 있는데 웹 서버가 못 읽는다" 싶을 때, 십중팔구 소유권이나 권한 문제예요.

💡 한 줄 정리

권한은 "owner/group이 뭘 할 수 있나", 소유권은 "그 owner/group이 누구인가". chown 사람 또는 chown 사람:그룹으로 소유자를, chgrp 그룹으로 그룹을 바꾼다. 소유권 변경은 보통 sudo가 필요하다.

Step 6: "Permission denied를 만났을 때 — sudo, 왜 필요하고 왜 위험한가"

지난 시간에 약속했죠. 서버를 다루다 누구나 만나는 그 빨간 메시지 Permission denied를, 무작정 sudo로 때우지 않고 스스로 푸는 법을 배운다고요. 이번 Step이 그 핵심이에요.

먼저 sudo가 뭔지부터. 앞에서 계속 나왔지만 정리하면, sudo는 "이 명령 하나만 잠깐 관리자(root) 권한으로 실행해줘"라는 뜻이에요. superuser do의 줄임말이에요. 평소엔 일반 계정(alice)으로 안전하게 일하다가, 시스템을 손봐야 하는 순간에만 마스터키를 잠깐 빌리는 거죠.

실제로 만나볼게요. 시스템 설정 파일 중엔 일반 사용자가 못 읽는 것도 있어요.

cat /etc/sudoers

cat: /etc/sudoers: Permission denied

또 그 메시지예요. 그런데 이번엔 우리가 배운 대로 차분히 진단해봅니다. 무작정 sudo부터 붙이지 말고요.

   Permission denied 를 만나면 — 무작정 sudo 전에 한 호흡

     1) ls -l 로 그 파일의 10글자와 소유자를 본다
            │
            ▼
     2) "내가 owner 인가?"
            ├─ 예 →  내 파일이다. chmod 로 내가 직접 풀 수 있다
            │         (예: 실행 권한이 없어 막힘 → chmod +x)
            │
            └─ 아니오 →  시스템·남의 파일이다
                          │
                          ▼
                  3) "정말 관리자 권한이 필요한 일인가?"
                          ├─ 예 →  sudo 를 붙인다 (시스템 설정 등)
                          └─ 아니오 →  굳이 건드릴 필요가 있나 다시 생각

/etc/sudoers를 ls -l로 보면 소유자가 root예요. 내 파일이 아니죠. 그리고 이건 시스템의 핵심 설정 파일이라 관리자만 읽게 막아둔 거예요. 그러니 이건 정말로 관리자 권한이 필요한 경우예요. 이럴 때 sudo를 씁니다.

sudo cat /etc/sudoers

[sudo] password for alice:

여기서 비밀번호를 물어봐요. 한 가지 짚을 게 있어요 — 이건 root의 비밀번호가 아니라 여러분(alice) 자신의 비밀번호예요. "너 정말 alice 맞아? 관리자 권한 빌려줄 자격(sudo 그룹) 있는 사람 맞지?"를 확인하는 거예요. Step 1에서 id를 쳤을 때 sudo 그룹이 보였던 게 바로 이 자격이었어요. 비밀번호를 맞게 넣으면 명령이 실행되고, 한동안은 다시 안 물어봐요(잠깐 기억해둬요).

자, 이제 중요한 이야기. sudo는 강력한 만큼 위험해요. root 권한으로 도는 명령은 안전장치가 없거든요. 일반 계정이면 "어 그건 권한이 없는데?" 하고 막아주던 일도, sudo를 붙이면 그냥 실행돼버려요. 그래서 명령을 잘못 쳤을 때 피해가 훨씬 커요.

겁주려는 게 아니에요. 솔직하게 알려드리는 거예요. 그리고 안심도 함께 드릴게요 — 위험을 피하는 건 어렵지 않아요. 습관 두 가지면 됩니다.

• sudo를 붙이기 전에 한 호흡 쉰다. "이거 정말 관리자 권한이 필요한 일인가?"를 한 번 묻는 거예요. 위 진단 그림처럼요. 내 파일 문제면 chmod로 풀면 되지 sudo가 필요 없어요.
• sudo rm -rf 같은 위험한 조합은 두 번 확인하고 친다. 지난 시간에 배운 rm의 위험을 기억하죠? 거기에 sudo가 붙으면 시스템 파일까지 지울 수 있어 더 위험해요. 치기 전에 경로를 눈으로 한 번 더 읽습니다.

마지막으로, 권한 문제를 sudo로 푸는 것 못지않게 흔한 나쁜 습관 하나 — chmod 777 남발이에요. 777은 "owner·group·others 모두에게 rwx 전부"예요. Permission denied가 나면 일단 chmod 777로 다 열어버리는 사람이 많은데, 이건 "문이 안 열리니까 아예 떼어버리는" 거예요. 그 파일을 아무나 읽고 고치고 실행할 수 있게 되니까요. 서버에선 이게 그대로 보안 구멍이 됩니다. 진짜 해법은 "꼭 필요한 사람에게 꼭 필요한 권한만" 주는 거예요. 777이 떠오르면, 대신 "누가 이 파일을 써야 하지? 그럼 그 사람에게만 권한을 주려면?"을 먼저 생각해보세요.

💡 한 줄 정리

sudo는 명령 하나만 잠깐 관리자 권한으로 실행한다(내 비밀번호로 자격 확인). Permission denied는 무작정 sudo 말고, ls -l로 소유자·권한부터 진단한다. 내 파일이면 chmod로 풀고, sudo·chmod 777 남발은 보안 사고로 이어진다.

Step 7: "새 파일은 왜 644로 태어날까 — umask"

여기서 작은 궁금증 하나 풀고 가요. 우리가 touch로 새 파일을 만들 때마다, 따로 권한을 정하지 않았는데도 항상 rw-r--r--(644)로 생겼어요. 폴더를 mkdir로 만들면 항상 rwxr-xr-x(755)였고요. 누가 정해준 걸까요?

이 "새로 만드는 파일·폴더의 기본 권한"을 정하는 게 umask예요. 그냥 쳐보면 지금 값이 나와요.

umask

0022

0022라는 숫자가 나오죠. 이게 어떻게 644를 만드는지가 살짝 거꾸로라 헷갈릴 수 있는데, 천천히 보면 간단해요. umask는 권한을 더하는 게 아니라 "깎아내는" 마스크예요. 이름의 뜻도 "user mask(가리개)"거든요.

리눅스는 새 파일·폴더를 만들 때 출발점이 정해져 있어요.

        새 파일의 출발점   :  666  (rw-rw-rw-)   — 파일은 실행권을 기본으로 안 줌
        새 폴더의 출발점   :  777  (rwxrwxrwx)   — 폴더는 들어가야 하니 x 포함

        여기서 umask 값을 "빼면" 실제 권한이 된다

그러니까 umask가 022면 이렇게 계산돼요.

        파일 :  666 - 022 = 644   →  rw-r--r--   (우리가 본 그 644!)
        폴더 :  777 - 022 = 755   →  rwxr-xr-x   (우리가 본 그 755!)

022를 빼면 group과 others에서 w(쓰기, 값 2)가 깎여나가는 거예요. 그래서 "주인은 읽고 쓰고, 남들은 읽기만"이라는 안전한 기본값이 나오는 거죠. 새 파일이 처음부터 아무나 고칠 수 있게 태어나면 위험하니까, 리눅스가 umask로 미리 쓰기 권한을 막아두는 거예요.

대부분은 이 기본값을 건드릴 일이 없어요. 다만 "이 세션에서 만드는 파일은 더 꽁꽁 닫아두고 싶다" 같은 특별한 경우엔 값을 바꿀 수 있어요.

umask 077
touch secret.txt
ls -l secret.txt

-rw------- 1 alice alice 0 Jun 16 11:20 secret.txt

077이면 group과 others의 권한 비트가 전부 꺼져서 600(rw-------), 즉 "나만 읽고 쓸 수 있는" 파일이 만들어진 거예요. 비밀 파일을 다룰 때 쓰는 설정이죠.

⚠️ 이렇게 umask로 바꾼 값은 지금 이 터미널 세션에만 적용돼요. 터미널을 닫으면 원래대로 돌아가요. 영구적으로 바꾸려면 설정 파일(.bashrc)에 적어둬야 하는데, 그건 A-11에서 환경설정을 배울 때 다뤄요. 오늘은 "새 파일의 기본 권한은 umask가 정한다"는 원리만 알면 충분합니다.

💡 한 줄 정리

umask는 새로 만드는 파일·폴더의 기본 권한을 정한다. 권한을 더하는 게 아니라 출발점(파일 666·폴더 777)에서 깎아내는 마스크다. 흔한 022는 남들의 쓰기를 깎아 파일 644·폴더 755를 만든다.

Step 8: "같은 파일을 가리키는 두 길 — 하드 링크 vs 심볼릭 링크"

오늘의 마지막 주제는 링크(link)예요. "같은 파일을 여러 이름으로 가리키는" 방법인데, 권한·소유권과 같은 묶음에서 배우는 이유가 있어요. 둘 다 "파일이라는 실체를 어떻게 가리키고 다루는가"에 대한 이야기거든요.

먼저 윈도우의 "바로 가기(shortcut)"를 떠올려보세요. 바탕화면 아이콘은 진짜 프로그램이 아니라 "저쪽에 있는 진짜를 가리키는 화살표"잖아요. 리눅스에도 비슷한 게 있는데, 두 종류예요. 그리고 그 둘이 동작하는 방식이 꽤 달라서, 구분해두면 나중에 헷갈리지 않아요.

이걸 이해하려면 작은 개념 하나가 필요해요. 리눅스에서 파일의 진짜 실체는 inode(아이노드)라는 곳에 저장돼요. inode는 "실제 데이터가 디스크 어디에 있는지, 권한은 뭔지" 같은 파일의 본체 정보예요. 그리고 우리가 쓰는 파일 이름은 사실 그 inode를 가리키는 꼬리표일 뿐이에요. 이 구분이 두 링크의 차이를 가르는 핵심이에요.

직접 만들어볼게요. 원본 파일 하나를 만들고, 두 종류의 링크를 걸어봅니다.

echo "원본 내용입니다" > original.txt
ln original.txt hardlink.txt       # 하드 링크
ln -s original.txt softlink.txt    # 심볼릭 링크 (-s)
ls -l

-rw-r--r-- 2 alice alice  25 Jun 16 11:30 hardlink.txt
-rw-r--r-- 2 alice alice  25 Jun 16 11:30 original.txt
lrwxrwxrwx 1 alice alice  12 Jun 16 11:30 softlink.txt -> original.txt

출력에서 두 가지가 눈에 띄죠?

• original.txt와 hardlink.txt는 권한 다음 숫자가 2예요 (보통은 1이었죠). 이 숫자가 "이 inode를 가리키는 이름이 몇 개인가"예요. 하드 링크를 걸었더니 2가 됐어요.
• softlink.txt는 맨 앞이 l(링크)로 시작하고, 뒤에 -> original.txt라고 어디를 가리키는지 적혀 있어요.

이 둘의 차이를 그림으로 볼게요.

  하드 링크 — 두 이름이 같은 실체(inode)를 직접 가리킨다
       original.txt ─┐
                     ├─→  [inode]  →  실제 데이터 "원본 내용입니다"
       hardlink.txt ─┘
       → 원본을 지워도 hardlink.txt 로 데이터가 그대로 살아있다
         (이름표 하나 뗐을 뿐, 실체는 남아있으니까)

  심볼릭 링크 — 이름이 "다른 경로"를 적어둔 쪽지일 뿐
       softlink.txt  →  "original.txt 로 가보세요"  →  [inode]  →  데이터
       → 원본을 지우면 softlink.txt 는 갈 곳을 잃어 깨진 링크가 된다
         (쪽지에 적힌 주소로 갔는데 아무것도 없는 셈)

핵심 차이는 "원본을 지웠을 때"예요. 직접 확인해볼게요.

rm original.txt
cat hardlink.txt

원본 내용입니다

원본을 지웠는데도 hardlink.txt로 내용이 멀쩡히 나와요. 하드 링크는 inode를 직접 가리키니까, 원본이라는 이름표 하나를 뗐을 뿐 실체는 그대로거든요. 반면 심볼릭 링크는요?

cat softlink.txt

cat: softlink.txt: No such file or directory

softlink.txt는 "original.txt로 가보세요"라는 쪽지인데, 정작 original.txt가 사라졌으니 갈 곳을 잃은 거예요. 이런 걸 깨진 링크(broken link)라고 해요.

그럼 실무에선 뭘 더 많이 쓸까요? 압도적으로 심볼릭 링크예요. 하드 링크는 제약이 많거든요 — 디렉토리엔 못 걸고, 다른 디스크(파일시스템)를 넘나들 수도 없어요. 심볼릭 링크는 그냥 "경로를 적은 쪽지"라 폴더든 다른 디스크든 자유롭게 가리킬 수 있어요.

심볼릭 링크가 빛나는 대표적인 현업 상황이 있어요. 서버에 프로그램을 버전별로 깔아두고, "현재 사용 중인 버전"을 가리키는 링크 하나를 두는 거예요.

ln -s /app/releases/v2.3 /app/current

이렇게 해두면 모두가 /app/current만 보고 일해요. 새 버전 v2.4를 배포할 땐 이 링크가 가리키는 곳만 v2.4로 바꾸면 끝이에요. 실제 폴더를 옮기거나 복사할 필요 없이, 쪽지에 적힌 주소만 고쳐 쓰는 거죠. 배포를 깔끔하고 빠르게 만들어주는 기법이라 정말 자주 봅니다.

💡 한 줄 정리

링크는 한 파일을 여러 이름으로 가리킨다. 하드 링크(ln)는 inode를 직접 가리켜 원본을 지워도 살아남고, 심볼릭 링크(ln -s)는 경로를 적은 쪽지라 원본이 사라지면 깨진다. 실무는 자유로운 심볼릭 링크를 압도적으로 많이 쓴다.

마무리

오늘 정말 큰 산을 하나 넘었어요. 지난 시간까지 자꾸 눈에 밟히던 그 -rw-r--r-- 10글자, 이제 척 보면 "주인은 읽고 쓰고, 남들은 읽기만"이라고 읽히죠? 그리고 chmod로 직접 바꾸고, Permission denied를 만나도 당황하지 않고 진단할 수 있게 됐습니다. 권한은 처음엔 다들 헷갈려하는 주제인데, 오늘 여기까지 따라왔으면 정말 잘하신 거예요. 핵심을 세 가지로 정리할게요.

오늘 배운 핵심 세 가지

💡 하나 — ls -l 맨 앞 10글자는 "파일종류 1 + (owner·group·others)×(rwx)"다. 리눅스는 여러 사람이 나눠 쓰는 멀티유저 환경이라, 누가 무엇을 할 수 있는지를 이 10글자로 칼같이 나눈다. whoami·id로 내 정체부터 확인한다.

💡 둘 — chmod로 권한을 바꾼다. 하나만 바꿀 땐 기호 모드(u+x), 전체를 한 번에 정할 땐 숫자 모드(755=rwxr-xr-x, 644=rw-r--r--). 소유권 자체는 chown/chgrp로 바꾸고, 이건 보통 sudo가 필요하다.

💡 셋 — Permission denied는 무작정 sudo·chmod 777로 때우지 않는다. ls -l로 소유자·권한을 먼저 진단하고, 내 파일이면 chmod로 풀고, 정말 필요할 때만 sudo를 쓴다. umask는 새 파일의 기본 권한을, 링크(ln -s)는 한 파일을 가리키는 또 다른 길을 다룬다.

다음 시간 예고

오늘 ls -l로 권한을 읽으면서, 파일이 많아지면 출력도 주르륵 길어진다는 걸 느꼈을 거예요. 그러다 보면 자연스럽게 욕심이 생겨요 — "이 긴 출력에서 내가 원하는 줄만 쏙 뽑아볼 순 없을까?", "이 결과를 화면 말고 파일로 저장해두고 싶은데?"

다음 시간(A-4)엔 바로 그걸 해요. 한 명령의 출력을 다음 명령으로 흘려보내는 파이프(|), 결과를 파일로 보내는 리다이렉션(>), 그리고 수천 줄에서 원하는 줄만 뽑아내는 grep을 배웁니다. "작은 도구 하나가 한 가지를 잘하고, 그것들을 컨베이어 벨트처럼 잇는다"는 유닉스 철학의 진짜 핵심으로 들어가는 거예요. 로그가 수천 줄인데 에러 난 줄만 눈으로 스크롤하며 찾던 신입을, 한 줄 명령으로 구원하는 시간이 됩니다. 그럼 다음 시간에 만나요.

과제

오늘 과제는 모두 여러분 자신의 리눅스 환경(WSL2·맥 터미널·VM)에서 직접 손으로 쳐보는 실습이에요. 권한은 눈으로 읽기만 해선 손에 안 익어요. 한 단계 칠 때마다 ls -l로 10글자가 어떻게 바뀌는지 직접 확인하며 천천히 따라오세요.

[기초] 권한 10글자 읽고 바꾸기

연습장을 차려서 권한을 직접 읽고 바꿔보세요.

• ~/practice 폴더에서 touch memo.txt로 파일을 하나 만들고, ls -l memo.txt로 권한 10글자를 확인한다
• 그 10글자를 직접 손으로 적고, "맨 앞 1글자는 무엇이고, owner·group·others 칸은 각각 무슨 권한인지" 한국어로 풀어 적는다
• chmod g+w memo.txt로 그룹에 쓰기 권한을 추가한 뒤, ls -l로 어느 글자가 바뀌었는지 확인한다
• echo '#!/bin/bash' > hello.sh로 스크립트 파일을 만들고, 실행 권한이 없어 ./hello.sh가 Permission denied로 막히는 걸 확인한 뒤, chmod u+x로 풀어서 실행되게 만든다

[응용] 기호 모드와 숫자 모드 오가기

같은 권한을 기호 모드와 숫자 모드 두 가지로 만들어보며 둘을 연결하세요.

• touch report.txt로 파일을 만들고, chmod 600 report.txt로 "나만 읽고 쓰기"로 바꾼 뒤 ls -l로 rw-------이 맞는지 확인한다
• 이번엔 같은 파일을 기호 모드만 써서 rw-r--r--(644)로 만들어본다 (chmod g+r,o+r 또는 chmod a+r 등을 고민해서)
• mkdir shared로 폴더를 만들고 ls -ld shared로 폴더의 기본 권한을 확인한 뒤, 그 숫자가 왜 755인지 umask 값과 연결해 한 줄로 설명한다
• 755·644·700·600이 각각 rwx 표기로 무엇인지, 그리고 어떤 파일에 쓰면 좋을지 표로 정리한다

[심화] Permission denied 스스로 진단하기 (서버 상황 상상)

현업 상황을 상상해봅시다. "서버에 들어갔더니 어떤 파일이 Permission denied로 안 열린다. 무작정 sudo를 붙이기 전에, 왜 막혔는지부터 진단하고 싶다." 그 진단 흐름을 직접 재현해보세요.

• 시스템 파일 하나(/etc/shadow 또는 /etc/sudoers)를 그냥 cat으로 열어보고 Permission denied를 만난다
• ls -l로 그 파일의 소유자와 권한 10글자를 확인하고, "내가 owner인가? 이게 막힌 진짜 이유가 무엇인가"를 한국어로 적는다
• 진단 결과 "정말 관리자 권한이 필요한 시스템 파일"이라고 판단되면, sudo를 붙여 열어본다 (이때 물어보는 비밀번호가 누구의 것인지도 적어본다)
• 반대로, 내 연습장에서 일부러 chmod 000 locked.txt로 모든 권한을 꺼버린 파일을 만든 뒤, 이건 sudo 없이 chmod만으로 어떻게 다시 열 수 있는지 보인다 (왜 이 경우엔 sudo가 필요 없는지도 함께)
• 마지막으로, "chmod 777로 다 열어버리는 게 왜 나쁜 해법인지" 두 문장으로 정리한다

생각해볼 주제

1. 왜 권한은 소유자·그룹·그 외 "세 부류"로만 나눌까

리눅스 권한은 딱 세 부류 — owner, group, others — 로만 나뉩니다. "alice는 읽기, bob은 쓰기, carol은 실행"처럼 사람마다 따로 정하면 더 세밀할 텐데, 왜 굳이 셋으로 단순하게 묶었을까요? 단순함이 주는 이점(빠른 판단·적은 저장 공간·예측 가능성)과, 그 단순함 때문에 포기한 것(사람별 세밀한 제어)을 저울질해보세요. 그리고 진짜로 사람별 세밀한 권한이 필요한 현업 상황(예: 특정 파일을 딱 두 사람만 쓰게 하고 싶을 때)에서는 어떤 보완책이 있을지도 상상해보세요. (힌트: ACL이라는 키워드를 찾아보면 흥미로운 확장이 보일 거예요.)

2. chmod 777은 왜 "해결"이 아니라 "포기"인가

Permission denied를 만났을 때 chmod 777로 다 열어버리면 일단 문제는 사라집니다. 그런데 왜 현업에서는 이걸 나쁜 습관으로 볼까요? "문이 안 열리니 문을 떼어버린다"는 비유를 실마리로, 777이 멀티유저 서버에서 만드는 위험을 구체적으로 그려보세요. 누가 그 파일을 망칠 수 있게 되는지, 그게 웹 서버처럼 외부에 노출된 환경이라면 어떤 사고로 이어질 수 있는지요. 그리고 "꼭 필요한 사람에게 꼭 필요한 권한만"이라는 원칙(최소 권한 원칙)이 왜 보안의 기본인지 자기 말로 정리해보세요.

3. 심볼릭 링크는 "깨질 수 있는데도" 왜 실무의 기본일까

하드 링크는 원본을 지워도 멀쩡한데, 심볼릭 링크는 원본이 사라지면 깨집니다. 안정성만 보면 하드 링크가 나아 보이는데, 현업에서는 심볼릭 링크를 압도적으로 많이 씁니다. 이 역설을 풀어보세요. 심볼릭 링크가 주는 자유(폴더·다른 디스크·아직 없는 경로까지 가리킴)와 명확함(->로 정체가 드러남)이, "깨질 수 있음"이라는 약점을 어떻게 압도하는지요. 그리고 "원본이 사라지면 링크가 눈에 띄게 깨진다"는 것이, 오히려 문제를 숨기지 않고 드러내는 장점이 될 수 있다는 관점도 함께 생각해보세요.