[IT-비교] ls 컨테이너 환경 비교를 통한 격리 원리 파악 – 호스트와 컨테이너의 파일 목록이 다른 이유

분명히 파일이 있는데 왜 안 보일까요? 파일 목록 조회의 미스터리

서버에 접속해서 분명히 파일이 있는 것을 확인했는데, 막상 컨테이너 안으로 들어가 ls를 입력하니 아무것도 보이지 않아 당황했던 경험이 있으신가요? 혹은 호스트 시스템에서는 권한이 충분해 보이는데, 컨테이너 환경으로 들어가는 순간 파일 목록이 깨지거나 접근할 수 없다는 메시지가 뜨기도 해요. 이런 상황은 단순한 버그가 아니라 리눅스 컨테이너 기술의 핵심 원리인 격리(Isolation)와 밀접하게 연관되어 있어요.

현업에서 인프라를 운영하다 보면 ls 컨테이너 환경 비교 작업은 필수적이에요. 단순히 파일이 있다, 없다를 넘어, 지금 내가 보고 있는 이 시야가 전체 시스템의 어디까지를 포함하는지 정확히 알아야 장애를 빠르게 해결할 수 있기 때문이에요. 만약 이 차이를 명확히 모른다면, 잘못된 파일 경로를 수정하거나 존재하지 않는 파일을 찾는 데 아까운 시간을 허비하게 돼요.

이 글은 컨테이너 기반 인프라를 관리하는 엔지니어를 위해 작성되었어요. 호스트와 컨테이너라는 두 세계가 어떻게 파일을 다르게 바라보는지, 그리고 그 경계가 어디서 발생하는지를 심도 있게 다뤄요. 이 글을 끝까지 읽고 나면, 어떤 환경에서든 당황하지 않고 파일 시스템의 구조를 파악할 수 있는 통찰력을 얻게 될 거예요.

오늘 우리는 다음과 같은 내용을 구체적으로 살펴볼 거예요.

• 네임스페이스가 만드는 파일 시스템의 가시성 경계
• 레이어 구조(OverlayFS)로 인한 파일 목록의 차이
• 사용자 권한 매핑에 따른 접근 제한 문제
• 호스트, 컨테이너, 사이드카 환경별 실행 시나리오 비교

환경 차이를 이해하기 위한 사전 지식과 체크리스트

본격적으로 ls 명령어의 결과 차이를 분석하기 전에, 우리가 발을 딛고 있는 두 환경의 설계 철학부터 이해해야 해요. 호스트는 시스템의 전체 권한을 가진 ‘관리자’의 영역이라면, 컨테이너는 격리된 상자 안에서 특정 작업만 수행하는 ‘손님’의 영역이라고 생각하면 쉬워요.

파일 목록이 다르게 보이는 근본적인 이유는 리눅스 커널의 네임스페이스(Namespace) 기술 때문이에요. 네임스페이스는 프로세스별로 시스템 자원을 분리하여, 특정 프로세스가 시스템의 다른 부분을 보지 못하도록 차단하는 역할을 해요. 이 기술 덕분에 컨테이너는 자신이 마치 독립된 컴퓨터인 것처럼 착각하며 살아가게 되는 것이죠.

또한, 파일 시스템을 구성하는 방식에서도 큰 차이가 있어요. 호스트는 물리적인 디스크나 네트워크 스토리지가 직접 연결된 구조를 가지지만, 컨테이너는 여러 개의 이미지 레이어가 겹쳐진 복합적인 구조를 가져요. 이 구조적 차이를 미리 인지하고 있어야 나중에 파일이 보이지 않는 문제를 만났을 때 어떤 부분을 먼저 점검할지 판단할 수 있어요.

환경별 주요 특성 비교

작업을 시작하기 전에 여러분의 환경이 어떤 상태인지 다음 리스트를 통해 체크해 보세요. 이 질문들에 답할 수 있다면 이미 문제 해결의 절반은 성공한 것이나 다름없어요.

• 현재 접속한 세션이 네임스페이스 격리가 적용된 상태인가요?
• 조회하려는 디렉토리가 볼륨 마운트(Volume Mount)를 통해 연결된 영역인가요?
• 파일의 소유자(Owner)와 권한(Permission)이 호스트의 UID와 일치하나요?
• 사용 중인 컨테이너 엔진이 OverlayFS를 사용하고 있나요?

왜 결과가 다를까? 파일 목록 격리의 4가지 핵심 메커니즘

이제 본격적으로 ls 명령어를 실행했을 때 왜 호스트와 컨테이너에서 서로 다른 결과가 나오는지, 그 내부를 낱낱이 파헤쳐 볼게요. 단순히 “격리되어 있어서”라는 추상적인 답변 대신, 실제 리눅스 커널이 어떻게 동작하는지 단계별로 알아봐요.

STEP 1. 마운트 네임스페이스와 시야의 한계

리눅스에는 마운트 네임스페이스(Mount Namespace)라는 개념이 있어요. 이것은 특정 프로세스가 어떤 디렉토리를 보고, 어떤 파일 시스템을 마운트할지를 결정하는 울타리 역할을 해요. 호스트에서 ls /를 치면 시스템 전체의 루트 디렉토리가 보이지만, 컨테이너 안에서 ls /를 치면 컨테이너 이미지에 포함된 아주 제한된 루트 디렉토리만 보여요.

컨테이너가 실행될 때, 도커(Docker)나 쿠버네티스(Kubernetes) 같은 런타임은 해당 컨테이너만을 위한 새로운 마운트 네임스페이스를 생성해요. 그리고 그 안에 컨테이너의 루트 파일 시스템을 마운트하죠. 따라서 컨테이너 내부의 프로세스는 호스트의 /etc나 /var를 절대로 볼 수 없어요. 만약 호스트의 특정 폴더를 보고 싶다면, 반드시 볼륨 마운트(Volume Mount)를 통해 그 영역을 컨테이너의 네임스페이스 안으로 끌어들여야만 해요.

STEP 2. 레이어드 파일 시스템(OverlayFS)의 마법과 함정

컨테이너의 파일 시스템은 우리가 흔히 보는 단일 디렉토리 구조가 아니에요. 대부분의 현대적인 컨테이너는 OverlayFS를 사용해요. 이는 여러 개의 읽기 전용(Read-only) 레이어를 하나로 겹쳐서, 마치 하나의 파일 시스템처럼 보이게 만드는 기술이에요.

이미지 레이어는 아래에서 위로 쌓이며, 각 레이어는 변경 사항을 저장하는 방식이 달라요. ls -l을 실행했을 때 파일의 생성 날짜나 속성이 이상하게 느껴진다면, 그것은 당신이 보고 있는 파일이 하위 레이어에서 올라온 것인지, 아니면 현재 컨테이너 레이어(Upper Layer)에서 새롭게 생성된 것인지에 따른 차이일 수 있어요. 파일을 수정하면 원본 레이어를 건드리는 것이 아니라, 가장 위에 있는 쓰기 가능한 레이어에 복사본을 만들어 수정하는 Copy-on-Write(CoW) 방식이 작동해요. 이 과정에서 파일 목록의 구성이 실제 물리적 디스크 구조와는 완전히 다르게 보일 수 있어요.

STEP 3. 사용자 네임스페이스와 UID/GID 불일치

파일 목록을 볼 때 파일 이름만큼 중요한 것이 바로 소유자 정보예요. 호스트에서 ls -l을 했을 때 root 소유로 보이는 파일이, 컨테이너 내부에서는 숫자로만 표시되거나 전혀 다른 사용자로 보일 때가 있어요. 이것은 사용자 네임스페이스(User Namespace) 때문이에요.

컨테이너의 보안을 위해, 컨테이너 내부의 root(UID 0)가 실제 호스트의 root와 동일한 권한을 갖지 않도록 매핑을 해두는 경우가 많아요. 예를 들어, 컨테이너 안의 UID 1000번 사용자가 실제 호스트에서는 UID 100001번 사용자로 매핑될 수 있어요. 이 상태에서 호스트의 파일을 컨테이너에 마운트하면, 컨테이너 내부의 ls 결과에는 파일 소유자가 숫자로만 출력되거나, 권한 부족으로 파일 목록 조차 불가능한 상황이 발생하게 돼요.