[Linux 초보 탈출] 리눅스 파일 시스템에 대해 알아 봅시다.

본 포스트는 Fedora Linux를 기준으로 작성되었습니다. 

이번 포스트에서는 리눅스 파일 시스템에 대해 알아보겠습니다. 

리눅스의 파일 시스템 전체를 이해한다는 것은 굉장히 방대한 지식체계입니다. 이것을 블로그 글 한 두 개로 다 설명할 수는 없겠지요. 본 포스트에서는 WIndows나 macOS를 사용하다가 Linux로 입문하는 분들이 WIndows 나 macOS와는 파일 시스템에서 어떤 차이가 있고, 리눅스를 사용하기 위해 파일 시스템과 관련하여 기본적으로 알고 있어야 하는 중요한 몇 가지를 살펴보도록 하겠습니다.   

- - - - -

파일 시스템(File System 혹은 Filesystem)이란 컴퓨터의 저장장치에 데이터를 저장하고 관리하는 체계를 의미하는데,  데이터 관리 체계라 함은 굉장히 광의적인 표현으로 기본적으로는 데이터를 물리적 저장장치에 기록하거나 읽어오는 방법,  기록 형식 및 규칙, 데이터의 무결성 유지 방안과  함께, 저장된 정보들을 체계적으로 분류하고 권한을 통제하는 일련의 규칙을 포괄하는 것이라고 볼 수 있습니다.  

우리가 흔히들 "파일 시스템"이라는 말을 사용할 때는 두 가지 측면의 의미가 있는데, 일상에서 "이거 NTFS로 포맷해줘, 아니야 FAT으로 포맷해야 해~" 이런 말을 사용할 때, NTFS 나 FAT...  macOS라면 APFS, HFS+ 등등을 흔히들 파일 시스템이라고 지칭합니다. 반면, Windows 파일 시스템, macOS 파일 시스템, Linux 파일 시스템이라고 표현할 때는  저-수준(Low Level) 기술 규칙과 고-수준(High Level) 기술 규칙을 포괄하는 의미가 됩니다.   

FAT, NTFS, APFS, ext4 등등의 파일 시스템은 저-수준 기술규칙을 지칭하는 것으로 데이터를 어떠한 방법으로 물리저장장치에 기록하고 읽어오는지, 데이터 무결성을 어떻게 유지할지, 효율성과 성능을 위해 특별히 어떠한 기능을 지원할지에 대한 것입니다.  사용자 입장에서는 이러한 것들을 직접적으로 알 필요가 없습니다. 내가 저장한 데이터가 SSD나 하드디스크에 어떠한 형식으로 어디에 어떻게 기록되고 관리되는지 알 이유는 없습니다.

고-수준 기술 규칙이라 함은 저-수준 기술 규칙이 무엇이던 상관 없이 사용자에게 데이터들이 어떻게 조직하고 어떻게 보여줄지, 어떻게 읽고, 쓰고, 실행할지 등에 대한 논리적인 규칙을 의미합니다. Unix-Like 운영체제들은 FHS(Filesystem Hierachy Standard)라는 규칙을 따르며 어떠한 저-수준 파일 시스템을 사용하든 동일하게 적용됩니다.  

Linux를 사용하는 유저들은 바로 이 FHS가 무엇인지를 알아야 합니다. 왜냐하면 사용자가 Linux를 사용하려면 Linux 파일 시스템 규칙에 따라 데이터를 저장하고 참조하며 관리해야 하기 때문입니다.  이 부분은 특히 WIndows만 사용해 오던 유저들이 Linux를 사용하게 되면, 생소한 파일시스템 때문에 사용 초기 어렵게 느껴지는 부분이기도 합니다.  

macOS와의 차이점은 살펴보지 않나요? 라고 궁금해하실 수 있는데, macOS의 kernel인 Darwin은 Unix를 기반으로 만들어진 것입니다. Darwin은 Unix 표준인 POSIX(Portable Operationg System Interface)를 준수합니다. 이 표준을 준수한다는 것은 Unix의 동작방식을 따르고 있다는 것을 의미합니다. 구체적으로 Darwin은 BSD와 Mach micro-kernel을 차용한 결과물입니다.  BSD(Berkeley Software Distribution)는 미국 버클리 대학에서 개발한 운영체제이고, Mach는 카네기 멜론 대학에서 개발한 Kernel이지요.  이러한 이유로 macOS의 파일 시스템은 저-수준 파일 시스템은 Linux와 다르지만, 고-수준 측면에서는 Unix나 Linux와 완전히 동일하지는 않지만 대체적으로 동일합니다. 반면, WIndows는 Unix-Like 운영체제와는 완전히 다른 파일시스템 체계로 만들어진 운영체제입니다.

 

Everything is a File

Everything is a file... "모든 것은 파일이다." 이것은 Unix-Like 운영체제(이하 Linux)의 핵심 철학 중 하니입니다. Linux에서는 모든 것은 파일로 취급됩니다. 우리가 다루는 이미지 데이터, Text 데이터, 오디오 데이터는 물론, 키보드, 마우스, 모니터, SSD, RAM, CPU 등의 물리적인 장치들 또한 Linux에서는 모두 file 일 뿐입니다.  당연히 파일들을 담고 있는 디렉터리도 특별한 정보를 담고 있는 파일일 뿐입니다. 그래서 일반 파일을 관리하는 것과 똑같은 방식으로 디렉터리를 관리하게 됩니다. 이것은 뒤에서 좀 더 자세히 알아보도록 하겠습니다. 

반면, WIndows에서는 이미지 데이터, Text 데이터.. 등등이 파일이고, 키보드, 마우스, 모니터 등은 장치들입니다. WIndows에서는 키보드, 마우스 등의 장치를 사용자가 직접 수정하거나 읽어보거나 기록하거나 할 수 없습니다. 굳이 장치에 접근하고자 한다면 Registry라는 장치 데이터베이스에 접근하거나 장치 드라이버를 제어하는 API를 이용해야만 합니다. 우리가 사용하는 word 파일이나 jpg 파일처럼 장치를 취급할 수 없습니다.  Windows에서의 폴더는 File이 아니라 Container입니다.  리눅스에서는 파일을 다루는 open(), read(), write() 같은 표준 시스템 Call로 FIle과 동일하게 Directiory를 취급할 수 있지만, Windows에서는 파일을 취급하는 API와 폴더를 취급하는 API가 각각 따로 존재합니다. 

이러한 이유로 Linux의 파일 시스템은 통일성과 유연성이 좋습니다.  

 

루트 파일 시스템

흔히들 Linux 파일 시스템을 루트(Root) 파일 시스템이라고 부르곤 히는데, 이것은 Linux의 파일 시스템이 단일 계층적 트리 구조( Single hierarchical tree structure)이기 때문입니다. 

root는 Linux 파일 시스템에서 최상위 계층을 의미합니다. root를 제외한 모든 파일과 디렉터리, 장치들은 root 디렉터리의 아래(하위)에 존재하게 됩니다. 

** Windows나 macOS 에서는에서는 파일들이 위치한 곳을 지칭하여 폴더(folder)라고 표현하지만, Linux에서는 디렉터리(Directory)라고 표현합니다. 

/ 은 root 디렉터리를 의미하며, /home 은 root 디렉터리 하위의 home 디렉터리를 뜻합니다(home이 디렉터리인 경우). /home/elsa라는 표현은 root 디렉터리 밑에 home 디렉터리 그리고 그 밑에 elsa 디렉터리라는 의미가 되겠죠(elsa가 디렉터리인 경우), 이 경우 home은 elsa의 상위 디렉터리 혹은 부모 디렉터리(Parent Directory)라고 하고 home 입장에서 elsa는 하위 디렉터리 또는 자식 디렉터리(Child Directory)가 됩니다. 

반면, Windows의 경우는 디스크 또는 파티션마다 각각의 root가 독립적으로 존재하는 다중 계층적 트리 구조(multiple hierarchical tree structure)입니다.  Windows에서는 파티션 또는 디스크마다 C:, D: E: 등 각 드라이브 문자가 개별젹이고 독립적인 root가 되고, 그 이하에 계층적 폴더 구조로 구성됩니다. 

그렇다면, Linux의 단일 계층적 트리 구조와 Windows의 다중 계층적 트리 구조의 장/단점은 무엇일까?

WIndows의 다중 계층 구조는 직관적이라는 장점이 있습니다. C:는 운영체제, D:는 사용자 데이터, E:는 게임, F: 멀티미디어 보관소.. 등등.. 그리고, 파티션 관리도 쉽습니다. 특정 디스크나 파티션이 구분되어 있기 때문에 해당 디스크/파티션을 제각기 개별적으로 취급할 수 있습니다.  

반면, Linux와 같은 단일 계층 트리 구조의 장점은 통일성에 있습니다. 직관성보다는 논리성을 강조합니다. 디스크가 3개가 연결될 때 각 디스크는  사용자가 지정한 Directory에 mount 즉 연동됩니다.  파티션이던 디스크던 정해진 이름은 없습니다. 유저 마음입니다. 디스크도 파티션도 그저 파일일 뿐이기 때문입니다. 파일에 정해진 이름이란 있을 수 없습니다.   따라서 직관성은 떨어집니다. 디스크를 마운트 한 유저 당사자는 특정 디렉터리가 디스크의 Mount point라는 것을 알지만, 옆 동료나 다른 사람이 볼 때 어떤 게 일반 디렉터리이고 어떤 게 연결된 외장 SSD인지 특별히 확인하지 않는 이상 알 수가 없습니다.  직관성은 떨어지지만 파일로 root의 하위에 가지를 하나 덧붙이는 것일 뿐입니다. 통일성이 유지됩니다.  그리고 유연합니다. 어느 하위 디렉터리이든 원하는 곳에 디스크를 붙일 수 있습니다.  Windows라면 C 드라이브는 C 드라이브일 뿐 D 드라이브 밑에 붙일 수 없습니다. 직관성은 좋지만, 유연성은 떨어집니다. 

 

권한(permission)

파일 시스템에는 권한(permission)이라는 중요한 개념이 있습니다. 이건 Windows를 포함한 모든 운영체제가 갖고 있는 개념으로 보안과 안정성을 담보하는 핵심 요소입니다. 

Linux는 3가지 권한 범주와  3가지 권한이 있습니다. 

3가지 권한 범위는 소유자(Owner), 그룹(Groups), 기타(Others)로 구분되는데, 소유자 권한이란 말 그대로 임의의 파일에 대한 사용자 소유권을 의미합니다. 그룹 권한은 여러 명의 사용자들을 하나의 그룹으로 묶어 부여하는 권한이고, 기타권한이란 소유자나 그룹에 속하지 않는 나머지 사용자의 권한을 의미합니다. 

3가지 권한이란 읽기(read) 권한, 쓰기(write) 권한, 그리고 실행(execute) 권한을 말합니다. 

읽기 권한이란 파일의 내용을 읽을 수 있는 권한이고, 쓰기 권한이란 파일의 내용을 수정하거나 생성 및 삭제할 수 있는 권한을 의미하며, 실행권한이란 파일을 실행하거나 디렉터리로 들어갈 수 있는 권한을 의미합니다. 

Linux의 모든 것은 파일이라는 것을 다시 한번 상기하면서... 그래서 모든 파일들은 3가지 범주와 3가지 권한에 대한 정보를 갖고 있으며, 사용자는 이를 확인할 수 있습니다. 

이러한 파일속성에 관한 정보를 메타데이터(metadata)라고 부릅니다.  메타데이터의 의미는 "데이터의 데이터"라는 뜻인데, meta는 그리스어에서 유래한 접두사로 "~에 관한"이라는 의미이고, meta와 data를 띄어 쓰지 않고 하나의 단어로 사용합니다. 

/home 디렉터리에서 ls 명령을 내리면, 위와 스샷처럼 해당 디렉터리의 파일 목록(서브 디렉터리도 파일이죠)을 확인할 수 있는데, 특별히 l(소문자 L)을 주면 metadata 정보를 확인할 수 있습니다. 

elsa라는 디렉터리 파일을 보면, 앞에 drwxrwx---@ elsa 이렇게 표시되어 있는 것을 볼 수 있습니다. 

d는 해당 파일이 directory라는 의미입니다. 일반 파일이라면 . 으로 표시됩니다. rwx는 각각 Read(읽기), Write(쓰기), eXecute(실행)의 의미입니다.  3개씩 권한을 표시하는 것인데 3묶음으로 되어 있으니, 첫 번째 묶음은 소유권(Owner), 두 번째 묶음은 그룹(Groups), 그리고 세 번째는 기타(Owners) 권한을 표시합니다. 

그리니까, drwxrwx--- 는 d rwx rwx --- 로 구분될 수 있고, 소유권이나 Groups의 구성원은 모두 읽고, 쓰고, 실행(디렉터리의 경우 진입)할 수 있지만, Others(소유권자도 아니고 같은 그룹에 속한 사람도 아닌 사람)은 --- 즉, 읽을 수도, 쓸 수도, 실행할 수도 없다는 것을 알 수 있습니다. 

@는 기본 속성이 이 외에 확장속성(Extended metadata)이 설정되어 있다는 표시입니다. 이것은 어떠한 종류의 저-수준 파일 시스템을 사용하고 있느냐에 따라 달라집니다. 확장속성에는 보안 콘텍스트, 코멘트, 제작자 정보 등이 포함되어 있을 수 있으며, getfattr이라는 명령으로 확인할 수 있습니다. 물론 "확장속성 정보를 담을 수 있다는 의미"이지 모든 파일에 확장 속성 정보가 있다는 의미는 아닙니다.

그러니까 위의 스샷을 보자면.. 나는 elsa로 로그인을 했기 때문에 elsa라는 디렉터리에는 진입을 할 수 있지만, link 디렉터리는 진입을 할 수 없다는 것을 알 수 있습니다. 왜냐하면 elsa는 link가 아니기 때문이며, link 입장에서 elsa는 others 권한이기 때문입니다. 

 

기본 디렉토리(Essential Directories)

자 그럼, 이제 Linux의 기본 directory에 대해 좀 설펴 봐야겠습니다. 다른 포스트에서도 잠깐 언급한 바가 있지만 Linux는 몇 개의 배포판들이 존재합니다.  Red Hat 계열, Debian(데비안) 계열, Arch(아치) 계열이 그것인데요, 많이 사용하는 Linux Mint나 Ubuntu는 모두 Debian 계열입니다. Ubuntu는 Debian을 기반으로 만든 것이며, Linux Mint는 Ubuntu를 기반으로 만든 배포판입니다. Fedora는 Red Hat 계열이죠. 배포판은 다르지만 모두 HFS를 따르기 때문에 기본 디렉터리 구조는 동일하다고 볼 수 있습니다 만, 약간의 미묘한 차이가 있습니다. 

root 디렉터리에서 ls 명령을 내리면, root 디렉터리의 하위 디렉터리들을 확인할 수 있습니다. 위의 스샷에서 Volumes는 본인이 만든 디렉터리이니 제외입니다. 

/boot 디렉터리는 부팅(booting)에 필요한 파일들이 위치하는 곳으로 Kernel Image와 boot loader 설정파일등이 이곳에 위치합니다. 

/dev 는 device(장치)의 약자로 키보드, 마우스, 다스크, 모니터 등 컴퓨터와 연결된 입출력(I/O) 장치 파일들이 위치한 디렉터리입니다. 

/etc 는 시스템 전체의 설정 파일들이 위치한 디렉터리입니다. 사용자 계정 정보, 네트워크, 시스템 서비스 등등의 설정파일들이 이곳에 있습니다. 

/proc 은 process(프로세스)의 약자로 실행 중인 프로세스와 시스템 정보를 담고 있는 가상 파일 시스템으로 실제 파일이 물리적인 디스크에 저장된 것이 아니라 메모리에 Kernel 이 생성한 정보들입니다.  이곳에는 시스템 메모리, CPU, 네트워크 상태 등 다양한 시스템 정보들이 포함되어 있습니다. 따라서, 파일들의 크기가 0으로 보이기도 하지만, 파일을 읽어보면 정보가 표시됩니다. (kernel 이 생성한 실시간 정보)

/sys 는 system의 약자로 시스템 하드웨어 정보를 담고 있는 가상 파일 시스템입니다. /proc 과 마찬가지로 메모리에 존재하며 하드웨어를 제어하는 데 사용됩니다. 

/run 은 runtime의 약자로, 시스템이 부팅된 후에 실행되는 프로그램들이 임시로 데이터를 저장하는 데 사용되는 공간입니다. 과거에는 /var/run 이렇게 /var 밑에 위치했었지만 지금은 독립적으로 존재합니다. 

/bin 은 binary이 약자로 모든 사용자들이 공통으로 사용할 수 있는 기본 실행파일들이 위치하는 곳입니다. 

/sbin 은 system binary의 약자이며, 시스템관리자인 root 만 사용할 수 있는 시스템 관리 프로그램들이 위치한 곳입니다. 

/var 은 variable의 약자로 시스템이 부팅되고 운영되는 과정에서 자주 변하는 파일들이 저장되는 곳으로, log, mail, 데이터 베이스 등이 이곳에 저장됩니다. 

/tmp 는 temporary의 약자로 임시 파일들이 저장되는 공간입니다. 해당 디렉터리의 내용들은 시스템이 종료되거나 재 부팅이 되면 자동으로 모두 삭제됩니다. 

/usr 는 user로 착각하는 사람들이 많은데, Unix System Resources의 약자로 운영체제에 필요한 대부분의 프로그램과 라이브러리들이 설치되는 곳으로 /bin 또는 /sbin 보다 훨씬 많은 프로그램들이 있는 곳입니다. 최근 Linux 배포판들은 /bin, /sbin, /lib, /lib64 등을 별도로 두지 않고, /usr/bin, /usr/sbin, /usr/lib, /usr/lib64 등을 Symbolic Link로 구성합니다.  초기 Linux 시스템에서는 / 만 mount가 되고, /usr 는 나중에 mount 되는 환경이었기 때문에 부팅에 필요한 도구들을 /bin /sbin에 별도로 구성했습니다. 하지만,  현재는 시스템들이 빵빵하기 때문에 굳이 이렇게 구분하지 않습니다. 다만, 과거로부터 사용해 오던 유저들에게 익숙한 운영환경을 제공할 목적과 빠르게 접근할 수 있도록 Symbolic Link를 해 놓고 있습니다.  이것을 "usr-merge를 적용" 했다고 합니다.   debian 계열에서는 usr-merge 하지 않고, 과거 전통적인 기본 디렉터리 구성을 하고 있어 차이가 있었지만, 최신 배포버전에서는 usr-merge를 적용하는 것으로 알고 있습니다. 

/media 는 USB 드라이브나 CD-ROM 같은 이동식 미디어가 자동으로 마운트딜 때 사용하는 디렉터리입니다.

/mnt 는 관리자(root)가 수동으로 파일 시스템을 임시적으로 마운트 할 때 사용하기 위한 디렉터리입니다. 

/opt 는 optional의 약자로 별도의 추가 소프트웨어를 설치하기 위한 곳입니다 

/root 는 시스템 관리자인 root 계정의 홈 디렉터리입니다. 일반 사용자의 홈 디렉터리인 /home과 구분하고 있습니다. 

/srv 는 서버에 대한 서비스 관련 데이터가 저장되는 곳으로 웹 서버의 데이터들이 이곳에 저장됩니다. 

/home 은 일반 사용자 계정의 홈 디렉터리로 사용자의 홈 디렉터리는 /home의 하위에 계정(id)과 동일한 이름으로 생성됩니다. 

 

절대경로, 상대경로

다음으로 절대경로(Absolute Path)와 상대경로(Relative Path)에 대해 알아봅니다. 

절대경로, 상대경로는 Windows를 포함하여 거의 모든 대부분의 운영체제들이 지원하는 개념입니다.  Linux와 Windows의 두드러진 차이점 중 하나는 경로를 구분하는 경로구분자(path separator)가 다르다는 건데, Windows의 경우에는 \(백 슬레쉬) 인 반면, Linux는 /(슬레쉬)를 사용합니다. 그리고 Root가 Windows는 C: D: 같은 Drive 이름을 포함한 C:\ 또는 D:\ 인 반면, Linux는 경로구분자와 동일한 / 를 사용합니다.   

리눅스가 경로구분자를 / 로 사용한데에는 이유가 있습니다. 초기 Unix를 개발하던 개발자들은 당연히 모두 프로그래머들이었고, C언어를 사용했는데, C언어에서는 escape 문자로 \를 사용합니다. 예를 들자면 \n (new line) 혹은 \t (tab) 등등.. 그래서 경로를 \로 사용하게 되면, 경로와 espace를 식별할 수가 없게 됩니다. 그래서 경로구분자를 /로 사용하게 된 것입니다.  참고로 윈도우에서는 \ 를 경로구분자로 사용하기 때문에 C 언어를 사용할 때 동일한 문제에 봉착하게 되는데, Windows에서는 escape와 경로 구분자를 식별하기 위해 \\ 를 사용했습니다. c:\\new_folder 이렇게 말이죠. 

그럼, Windows 개발자들은 \ 이 escpae 문자와 혼용시 문제가 된다는 것을 몰랐을까?
Windows는 MS-DOS를 계승한 것이고, MS-DOS는 Microsoft사가 Seatle Computer Products라는 회사에서 개발한 QDOS를 사 와서 업그레이드한 것입니다. QDOS는 CP/M 이라는 운영체제를 기반으로 했는데, 이 CP/M의 파일시스템이 경로구분을 \으로 사용했었기에, 이것이 자연스럽게 MS-DOS에서도 그대로 사용되었고, Windows에서도 그대로 사용하게 됩니다.  흔히들 MS-DOS는 빌 게이츠가 개발한 것으로 알고 계신 분들이 간혹 있는데, MS는 원래 BASIC 이라는 프로그래밍 언어를 개발 및 판매하던 회사였습니다. IBM이 1980년대 개인용 PC에서 사용할 운영체제를 물색하고 있었고, 당시 표준은 CP/M 이였지만 둘 간에 협상이 불발되면서 운영체제 공급을 마이크로소프트에 의뢰하게 되었지요. 이예 MS는 QDOS의 라이선스를 구매, 수정/보완하여 MS-DOS로 명명 IBM에 공급하게 됩니다. 물론 나중에 QDOS의 소유권을 아예 사 버리죠. MS-DOS이 대부분은 어셈블리어로 개발되었습니다. 

절대경로란 최상위 지점(Root)로 부터 시작하여 현재의 위치에 이르는 모든 경로를 모두 표현하는 것을 말합니다.  흔히들 전체경로(full-path)라고도 부릅니다. 

Windows 에서는 C:\Users\elsa\Documents\test.doc 이런 식이고 Linux 라면 /home/elsa/Documents/test.doc 이런 식입니다. 

상대경로란 현재 디렉터리(폴더) 혹은 특정 기준점을 기준으로 표현한 경로를 말합니다. 

예를들어 절대경로가 /home/elsa/documents/pdf 이고, elsa 가 현재 디렉터리라면,  

documents 이 표현 자체가 현재 디렉터리를 기준으로한 하위 디렉터리를 의미하는 상대경로입니다.  document/pdf  이것도 상대경로입니다.  document/pdf/example.pdf  이것도 상대경로 표현입니다. 공통점은 현재 디렉터리가 기준이라는 점입니다. 

현재 또는 상위 디렉터리를 의미하는 특별한 형태가 있는데, . 은 현재 디렉터리를 .. 는 상위 디렉터리를 의미합니다. 

따라서, documents 는 ./documents 와 같고,  ../link 는  절대경로 /home/link 와 같은 의미가 됩니다.

Linux에서 흔히 사용하는 디렉터리 관련 표현 중에 ~(tilde:틸드) 가 있는데요.. 이건 상대경로가 아닌 별칭(Alias) 혹은 단축(Abbreviation) 라고 합니다.  의미론적으로는 분명 "현재 사용자의 home 디렉터리"라는 상대경로를 의미하지만,  ~ 은 Unix-like 운영체제의 표준요소가 아닌 Bash나 zsh 와 같은 shell 이 제공하는 편의 기능이기 때문입니다.  내부적으로 ~ 은 shell 에서 절대경로로 치환하게 됩니다. 

따라서, shell과 직접적인 관련이 없는 순수 Linux 관련 기능에서는 ~를 이용한 경로표현을 허용하지 않는 경우도 있습니다. 

 

파일 확장자

확장자는 파일이 어떤 종류의 파일인지를 식별하는 것으로 extension 이라고 부릅니다. windows에서는 이 확장자가 매우 절대적인 의미를 갖습니다.  확장자에 따라 Icon 도 바뀌고, 연결되어 열 수 있는 프로그램도 결정이 되기 때문입니다. 

반면, Linux에서는 확장자라는 개념은 없습니다.  사용자가 파일의 종류를 직관적으로 식별하기 위해  또는 통념적인 파일네임 표현식에 따라 .zip .jpg 이렇게 붙이는 것이지, 이것이 windows의 그것처럼 동작하거나 인식되지 않습니다. 

그럼 Linux에서는 파일의 종류를 어떻게 식별할까?
Linux에서는 파일들이 포함하고 있는 medata, Magic Number나 Shebang(쉬뱅), MIME-Type 등으로 식별을 합니다.

우선 실행 파일이나 데이터 파일이냐 하는 것은 파일의 metada에 해당 파일이 실행권한이 설정되어 있는지의 여부로 판단합니다. 실제 실행파일인지 데이터파일인지의 여부와 무관하게 실행권한이 있다면 실행할 수 있는 파일이고, 없다면 실행할 수 없습니다.

파일이 스크립트(script) 파일이고, Shebang이 명시되어 있다면, 해당 파일이 shell script 인지, python 코드인지를 식별할 수 있게 됩니다. 

일반적인 데이터 파일들, 그러니까.. 음악 파일, 이미지 파일, 동영상 파일 등은 파일의 내용을 보고 파일 type을 구분합니다.  Linux에서는 Magic Number라는 것이 있는데, 이는 특정 파일 형식이 시작 부분 혹은 특정 위치에 고정적으로 나타나는 고유한 바이트 시퀀스 혹은 특정값을 의미합니다. Linux는 이 magic number 데이터베이스를 갖고 있기 때문에, 해당 파일의 내용을 보고 해당파일이 어떤 파일인지를 식별합니다.  이 데이터베이스는 /usr/share/misc 디렉터리에 존재합니다. 

 

아래 스샷을 보면, test1 이라는 디렉터리에 flac(오디오), mkv(동영상), jpg(이미지), test2(디렉터리) 이렇게 4개의 파일이 있는 것을 알 수 있습니다. 

file 이라는 명령은 해당 파일의 Magic Number를 식별하여 어떤 파일인지를 알려주는 명령입니다. 

JPEG 아미지 파일은 16진수 값으로 FF D8 FF E0 으로 시작하고, PDF 파일의 경우 ASCII 문자열로 %PDF로 시작합니다.  그리고 Zip 압축 파일의 경우 ASCII로 PK 로 시작을 합니다. 

결론적으로 Linux에서는 사용자가 임의로 붙이는 .확장자 형식은 아무런 의미가 없습니다. 그저 이름의 일부일 뿐입니다. 사용자가 그냥 식별하기 위해서 이름을 그렇게 만든 것 이상의 의미는 없습니다. 

리눅스에서는 또 MIME(Multipurpose Internet Mail Extenstions) Type이라는 것을 사용합니다.  이것은 원래 인터넷 환경에서 파일의 종류를 식별할 목적으로 사용되는데 xdg-open 과 같은 도구가 파일을 열 때 MIME 기준으로 해당 파일을 열 프로그램을 선택하게 됩니다.  MIME type 은 다양한 운영체제에서 사용하는 것이기 때문에 파일명의 .txt 와 같은 표현을 조금은 고려합니다. 하지만 이는 Magic Number 분석으로 식별이 되지 않을 경우에 보조적으로 분석하는 것이지 본질적인 분석 요소가 아니며, 여전히 이름의 일부일 뿐이지 확장자는 아닙니다. 

또, 일부 응용프로그램 단계에서 .확장자 처럼 파일이름 형식을 요구하는 경우가 있습니다. 

가장 대표적인 것이 프로그래밍 언어 컴파일러 들로 예를 들어 C 언어 컴파일러의 경우 .c 를 c코드로 .h 파일을 헤더파일로 처리합니다. 프로그래밍 언어들 마다 제각기 자신들이 정한 네이밍 규칙이 있지요. 웹서버의 경우에도 .html 파일을 HTML 문서로 인식하고 .php 파일을 PHP 스크립트로 인식하여 처리합니다.  다만 이 경우에도 이들을 확장자로 인식한다기보단 파일명의 접미사(suffux)로 인식하는 것일 뿐입니다. 

Linux에서는 실행파일이든 문서파일이던 이름과 type 간에 논리적인 연결성이 없습니다. 아무리 jpg 이미지 파일을 test.pdf 라고 하거나 test.mp3라고 바꿔도 Linux에서는 그저 jpg 이미지 파일로 식별합니다. 디렉터리 이름에 .mp3를 넣어도 디렉터리는 디렉터리일 뿐입니다.  

반면, Windows에서는 확장자가 갖는 의미가 절대적입니다.  jpg 파일의 확장자를 .zip으로 바꾸면 이를 압축파일로 인식합니다.  대신, 장점이라면 매우 직관적이라는 점을 들 수 있습니다. 실제로 파일의 내용을 들여다보지 않고도 해당파일이 어떤 파일인지를 식별할 수 있고 적절한 프로그램으로 열 수 있도록 연결할 수 있습니다. 

macOS의 경우에는 Unix-like 운영체제로 근본적으로는 Linux와 동일하게 파일명을 식별하지만, 사용자 편의성, 다른 운영체제와의 차별화를 위해 WIndows와 같은 확장자 개념을 사용하고 있습니다.  그 증거는 Finder에서 확장자를 숨기거나 볼 수 있는 옵션이 있다는 점을 들 수 있습니다.  

 

링크(Link)

자 이제 마지막 주제입니다.  Link란 둘을 연결한다는 의미인데요, 파일시스템과 관련이 있으므로 파일과 파일을 연결한다는 의미가 될 겁니다. Linux에는 Soft Link와 Hard Link 이렇게 두 가지가 있습니다. Soft Link는 Symbolic Link 라고도 부릅니다. 

Soft Link는 파일이나 디렉터리를 가르키는 포인터(Pointer) 또는 바로가기(Shortcut)을 의미하는데, 이는 Windows나 macOS에서도 있는 개념입니다. 실제 데이터를 갖고 있는 것이 아니라, 단순희 원본파일(혹은 디렉터리)의 위치를 가리키는 파일을 뜻합니다.

Linux의 파일들은 모두 inode라는 정보를 갖고 있는데, 이는 실제 저장장치에 저장된 데이터의 위치 정보 입니다. Soft Link는 독립적인 파일로 고유한 inode를 갖고 있어 별개의 파일로 인식됩니다. 

Hard Link는 Soft Link처럼 자신이 데이터를 갖고 있는 것이 아니라 원본 파일을 가르키고 있다는 점에서는 동일하지만, 자신의 inode를 갖고 있는 것이 아니라 원본 파일의 inode를 똑같이 갖게 됩니다.  따라서, 운영체제 입장에서는 Hard Link 파일과 원본 파일은 사실상 동일한 파일로 간주합니다. Hard Link로 접근을 하던, 원본 파일로 접근을 하던 사용되는 실제 데이터는 동일한 것입니다. 

Hard Link가 Soft Link와 다른 또 다른 특징은, 일반 파일은 Hard Link를 만들 수 있지만 디렉터리는 Hard Link로 만들 수 없다는 점입니다. /home/elsa 라는 디렉터리를 /home/elsa/test 라는 Hard Link로 만들게 되면, 디렉터리의 기본 개념이 무너지기 때문입니다. (이것을 "순환 참조 문제"라고 합니다.)

세 번째 차이점은 Hard Link는 동일한 저-수준 파일 시스템 혹은 동일한 파티션 내에서만 만들 수 있는데, Hard Link는 원본 파일의 inode를 공유하기 때문입니다. 이게 무슨 말이냐면, 서로 다른 저장장치 혹은 서로 다른 파티션은 물리적으로 별개의 장치로 인식하기 때문에 "다른 공간 동일 위치"가 존재하게 됩니다. 따라서 한 저장장치의 inode를 다른 장치에서 Hard Link로 지정할 수 있게 허용하게 되면, Hard Link 의 inode가 동일한 파티션 혹은 동일한 저장장치 내의 저장 위치인지 다른 저장장치 혹은 파티션의 저장위치인지를 판단할 수 없게 됩니다. 따라서 Hard Link는 동일한 파티션 내에서만 생성할 수 있도록 제한한 것입니다. 

네 번째 차이점은 Soft Link는 원본 파일이 삭제되면 Soft Link가 더 이상 유효한 원본을 가르킬 수 없는 상태 즉, Danggling Link(끊어진 링크)가 되는 반면, Hard Link는 원본 파일이 삭제되더라도 원본 파일을 계속 가리킬 수 있습니다. 즉, 원본파일이 삭제되더라도 Hard Link에 inode가 남아 있기 때문에 실제로는 원본 데이터가 삭제된 것은 아닌 셈이 됩니다. 

Soft Link의 가장 흔한 용도는 Shortcut(바로가기) 입니다. 원본 파일이 매우 복잡한 디렉터리에 포함되어 있을 때, 해당 원본 파일을 Symbolic Link로 만들면 매우 직관적으로 쉽게 원하는 곳에서 접근할 수 있습니다. 

Hard Link는 잘 사용되지는 않자만 특정 디렉터리 내의 원본파일이 매우 중요해서 실수로 디렉터리가 삭제될 경우라도 파일이 삭제되지 않게 할 목적으로 사용됩니다. copy와 같이 물리적으로 원본데이터를 다른 곳에 똑같은 내용으로 저장하는 것이 아니기 때문에, 물리적은 저장공간을 부가적으로 소모하지 않으면서도 원본파일을 보호할 수 있게 됩니다. 물론, 부가적으로 Soft Link와 같은 shortcut 효과를 같이 얻을 수 있습니다. 

Hard Link 사용 시의 단점이라면, 저장다용량 대비 사용된 용량을 계산할 때 혼란이 야기될 수 있다는 점입니다. 원본과 Hard Link 사이에는 "원본"과 "사본" 같은 개념이 없습니다. 둘 다 원본인 셈입니다. 정확한 저장공간 사용용량을 계산하기 위해서는 원본과 사본 중 어느 한쪽만 계산에 넣어야 합니다. 둘 다 동일한 크기를 표시하기 때문입니다.  그러니까 둘 다 계산에 포함하면 실제보다 더 많은 용량을 사용한 것처럼 잘못 계산될 것이고, 둘 다 계산에 넣지 않으면 실제보다 더 작은 용량을 사용한 것처럼 잘못 계산될 것입니다. 문제는 원본과 사본 개념이 없기 때문에 이를 적절히 식별할 방법이 없다는 것입니다. 

Link는 ln 명령으로 생성할 수 있으며, Link 또한 파일이므로 다른 파일과 동일하게 rm 혹은 rmdir로 제거할 수 있습니다. ln -s 옵션을 사용하면 Soft Link를 생성하는 것이고, 그냥 ln 으로 Link를 만들면 Hard Link를 만드는 것입니다. 

 위의 스샷은 temp333 이라는 디렉터리에 포함된 3개의 파일을 ls -l 명령으로 확인한 것입니다. 

원본파일은 test.txt 이고, symbolic-link 라는 파일은 test.txt의 Soft Link임을 알 수 있습니다. hard-link 파일은 text.txt의 Hard Link 인데, Soft Link 처럼 원본 파일이 무엇인지를 알려주지 않습니다. test.txt가 제거되더라고 물리적인 저장장치에서 데이터가 제거되는 것이 아니기 때문에 원본 파일이 뭔지 Hard Link 파일이 뭔지 알 필요가 없습니다. 다만, 왼쪽에 권한정보 -rw-r--r--. 2 elsa elsa .. 이렇게 된 것을 보면, symbolic-link 파일은 1 이자만, test.txt와 hard-link 파일은 2로 되어 있는 것을 확인할 수 있습니다.  inode가 2개라는 의미로 원본파일에 대해 1개의 Hard Link 파일이 추가적으로 존재한다는 것을 알 수 있습니다.  또 한 가지 확인할 수 있는 것은 hard-link 파일도 3.1KB 크기이고, test.txt도 물론 3.1KB로 표시된다는 것입니다.  앞서 언급한 것처럼 사용자가 확인할 수 있는 디렉터리 크기나 파일의 사용용량은 정확하지 않을 수 있습니다. 

 

- - - - - 

글을 쓰다보니, 예상대로 꽤 길어 졌습니다. 

우리가 Windows나 macOS를 처음 접했을 때, 해당 운영체제를 어떻게 사용할 수 있었는지를 돌이켜 보면, 대부분은 그냥 이것저것 사용하면서 경험적으로 사용법을 익히게 되지요, 하지만, 좀 더 효과적이고 깊이있게 사용하기위해서는 어느 순간에는 결국 기술적이고 학문적인 영역으로 들어가야 합니다.

Linux는 Windows나 macOS 만큼 불특정 사용자층을 배려한 OS가 아니기 때문에, WIndows나 macOS를 사용하던 분들이 Linux를 사용하고자 할 때, 꽤나 진입장벽이 높다고 느끼게 되고, 그래서 Linux는 사용하기 어렵다는 인식이 많은 것 같습니다.  

열정을 갖고 Linux를 사용하고자 도전하는 분들에게 조금이나마 도움이 될 수 있었으면 합니다. ^^