[IT-비교] cd 컨테이너 환경 비교: 디렉터리 이동 결과가 다른 이유 – 호스트와 컨테이너의 환경 격차 분석

분명히 같은 명령인데 왜 결과가 다를까요?

서버 운영 중에 컨테이너 내부로 접속해서 cd /etc 명령어를 입력해 본 경험이 있으신가요? 호스트 머신에서 똑같이 입력했을 때와는 전혀 다른 파일 목록이 눈앞에 펼쳐져 당황스러웠던 적이 있을 거예요. 분명히 똑같은 리눅스 환경이고 똑같은 디렉터리 경로를 입력했는데, 왜 내가 찾던 설정 파일은 보이지 않는 걸까요?

이런 혼란은 단순히 명령어를 잘못 입력해서 생기는 문제가 아니에요. 우리가 매일 다루는 컨테이너 환경과 호스트 환경 사이에는 눈에 보이지 않는 거대한 벽이 존재하기 때문이에요. 이 벽을 이해하지 못하면 디버깅 과정에서 엉뚱한 경로를 헤매거나, 운영 중인 서비스의 설정 파일을 잘못 수정하는 치명적인 실수를 저지를 수도 있어요.

단순히 디렉터리를 이동하는 기능을 넘어, 리눅스 커널이 어떻게 프로세스를 격리하고 우리에게 독립된 파일 시스템 뷰를 제공하는지 아는 것은 인프라 엔지니어에게 매우 중요한 역량이에요. 이번 글에서는 cd 컨테이너 환경 비교를 통해 왜 이런 차이가 발생하는지 그 근본적인 원인을 파헤쳐 볼게요.

이 글을 읽고 나면 다음과 같은 내용들을 확실히 정리할 수 있어요.

• 호스트와 컨테이너의 디렉터리 구조가 왜 다른지 결정하는 핵심 기술
• 네임스페이스와 루트 파일 시스템의 관계
• 실무에서 빈번하게 발생하는 권한(Permission) 불일치 문제
• 상황별(호스트, 컨테이너, 사이드카) 올바른 디렉터리 접근 방법

디렉터리 이동의 차이를 이해하기 위한 사전 지식

본격적으로 환경 차이를 비교하기 전에, 우리가 어떤 개념들을 머릿속에 담고 있어야 하는지 먼저 살펴볼게요. 단순히 cd 명령어의 문법을 아는 것만으로는 부족해요. 컨테이너라는 특수한 환경이 리눅스 커널의 기능을 어떻게 활용해서 우리를 속이고(?) 있는지 이해해야 하거든요.

반드시 알아야 할 3가지 핵심 개념

가장 먼저 이해해야 할 것은 리눅스 네임스페이스(Namespace)예요. 네임스페이스는 커널이 프로세스들에게 각자 독립된 자원을 보고 있다고 믿게 만드는 마법 같은 기술이에요. 예를 들어, ‘마운트 네임스페이스’는 특정 프로세스가 어떤 디렉터리를 루트(Root)로 볼 것인지를 결정해요. 그래서 컨테이너 안에서 cd /를 실행하면 호스트의 최상위 디렉터리가 아니라, 컨테이너 이미지에 포함된 별도의 최상위 디렉터리로 이동하게 되는 거예요.

두 번째는 루트 파일 시스템(Root Filesystem)이에요. 컨테이너는 실행될 때 특정 디렉터리를 자신의 뿌리로 삼도록 설정되는데, 이를 chroot(Change Root) 개념과 유사하게 활용해요. 이 때문에 호스트의 `/var/log`와 컨테이너의 `/var/log`는 이름만 같을 뿐, 물리적으로는 완전히 다른 저장 공간을 가리키고 있어요.

세 번째는 사용자 및 그룹 ID(UID/GID) 매핑이에요. 디렉터리 이동 자체는 성공하더라도, 그 안에 있는 파일을 읽거나 쓰려고 할 때 ‘Permission denied’ 오류가 난다면 이건 권한 문제예요. 호스트의 사용자 ID와 컨테이너 내부의 사용자 ID가 서로 다르게 매핑되어 있기 때문에 발생하는 현상이죠.

환경별 특징 비교표

호스트와 컨테이너 환경의 차이를 한눈에 파악할 수 있도록 정리해 보았어요. 이 표를 기준으로 앞으로 전개될 내용을 이해하시면 훨씬 수월할 거예요.

환경 격차를 만드는 5가지 핵심 단계별 분석

이제 본격적으로 왜 cd 명령어 하나에 결과가 천차만별로 달라지는지, 그 내부 메커니즘을 단계별로 뜯어볼게요. 엔지니어로서 이 흐름을 이해하면 컨테이너 디버깅 능력이 비약적으로 상승할 거예요.

STEP 1. 마운트 네임스페이스를 통한 시야의 격리

리눅스 커널의 가장 강력한 기능 중 하나인 마운트 네임스페이스(Mount Namespace)는 프로세스가 바라보는 파일 시스템의 지도를 완전히 다르게 그려줘요. 컨테이너가 생성될 때, 커널은 해당 컨테이너만을 위한 새로운 마운트 네임스페이스를 할당해요.

이 상태에서 컨테이너 내부의 프로세스가 cd /etc를 실행하면, 커널은 ‘이 프로세스의 지도는 이 컨테이너 전용 지도야’라고 판단해요. 그래서 호스트의 `/etc`에 있는 네트워크 설정이나 사용자 정보가 아닌, 컨테이너 이미지 안에 포함된 별도의 `/etc` 디렉터리로 안내하는 거죠. 즉, 보는 범위의 경계가 네임스페이스에 의해 결정된다고 이해하면 쉬워요.

STEP 2. 루트 파일 시스템(Rootfs)과 chroot의 원리

컨테이너는 실행될 때 호스트의 특정 디렉터리나 압축 해제된 이미지 폴더를 자신의 최상위 디렉터리(/)로 선언해요. 이를 위해 커널은 chroot(change root)와 유사한 원리를 사용하여 프로세스의 루트 위치를 고정해 버려요.

예를 들어, 호스트의 `/home/user/my-container/rootfs`라는 폴더가 컨테이너의 루트라고 가정해 볼게요. 컨테이너 안에서 어떤 사용자가 cd /를 입력하든, 실제로는 호스트의 `/home/user/my-container/rootfs`로 이동하게 돼요. 이 지점에서 호스트의 실제 루트인 `/`와 컨테이너의 루트인 `/`는 이름만 같을 뿐, 논리적으로 완전히 단절된 세계가 되는 거예요. 이 단절 덕분에 컨테이너 내부의 프로세스가 실수로 호스트의 시스템 파일을 건드리는 사고를 막을 수 있는 것이죠.

STEP 3. 마운트 포인트와 볼륨 공유의 메커니즘

그런데 가끔은 컨테이너 안에서 호스트의 특정 디렉터리가 보이는 경우가 있어요. 바로 볼륨 마운트(Volume Mount)를 사용했을 때예요. 이때의 디렉터리 이동은 더욱 복잡한 양상을 보여요.

호스트의 `/data/logs`를 컨테이너의 `/var/log`로 마운트했다면, 컨테이너 내부에서 cd /var/log를 했을 때 우리는 호스트의 로그 파일을 볼 수 있어요. 하지만 여기서 주의할 점은, 컨테이너 내부의 `/var/log`는 더 이상 컨테이너 이미지 고유의 디렉터리가 아니라 호스트와 연결된 ‘통로’ 역할을 한다는 거예요. 이 통로를 통해 이동할 때는 호스트의 파일 시스템 일부가 컨테이너의 네임스페이스 안으로 침범해 들어오는 형태가 됩니다. 이것이 바로 컨테이너와 호스트가 데이터를 주고받는 핵심적인 방식이에요.

STEP 4. UID/GID 불일치로 인한 접근 거부 현상

디렉터리 이동은 성공했는데, 막상 ls -l을 쳤을 때 권한 오류가 나거나 파일 소유자가 숫자로만 표시되는 경우가 있죠? 이는 사용자 식별자(UID) 불일치 때문이에요.

호스트에서는 사용자 ‘alice’가 UID 1000을 사용하고 있다고 가정해 볼게요. 그런데 컨테이너 내부의 이미지에는 ‘appuser’라는 사용자가 있고, 이 사용자의 UID는 2000으로 설정되어 있을 수 있어요. 만약 호스트의 디렉터리를 컨테이너로 마운트했는데, 그 디렉터리의 권한이 UID 1000에게만 있다면? 컨테이너 내부의 UID 2000을 가진 프로세스는 cd를 통해 해당 폴더에 들어갈 수는 있어도, 정작 내부 파일을 읽으려고 하면 ‘Permission denied’를 마주하게 돼요.

STEP 5. 실행 환경별 디렉터리 접근 시나리오 비교

실무에서 엔지니어가 마주하는 세 가지 주요 시나리오를 통해 정리해 볼게요.

• 호스트 직접 접속: 서버의 모든 파일 시스템에 접근 가능해요. 시스템 설정 변경(sysctl 등)이나 커널 모듈 로드가 가능한 ‘진짜’ 권한을 가져요.
• 컨테이너 내부 접속 (docker exec): 격리된 네임스페이스 안에서만 움직여요. 컨테이너 이미지에 포함된 파일들만 보이며, 마운트되지 않은 호스트 경로는 절대 볼 수 없어요.
• 사이드카(Sidecar) 컨테이너: 하나의 포드(Pod) 내에서 다른 컨테이너와 볼륨을 공유해요. 같은 포드 내의 다른 컨테이너가 사용하는 경로를 공유하여 디버깅이나 로그 수집에 활용할 수 있지만, 여전히 각자의 네임스페이스를 가지고 있다는 점을 잊으면 안 돼요.

이처럼 리눅스 컨테이너 환경 비교를 통해 살펴본 디렉터리 이동은 단순히 위치를 바꾸는 행위가 아니라, 현재 내가 어떤 네임스페이스와 권한 체계 아래에 있는지를 확인하는 과정이에요.

자주 하는 실수와 해결법 및 FAQ

실무에서 디렉터리 이동과 관련해 엔지니어들이 가장 빈번하게 저지르는 실수들을 모아봤어요. 비슷한 상황을 겪고 있다면 이 부분을 집중적으로 확인해 보세요.

자주 하는 실수와 해결법

❌ 실수: 컨테이너 내부에서 cd /home/user/data를 입력했는데 경로를 찾을 수 없다고 나와요.
왜 발생하는가: 호스트의 경로를 그대로 입력했기 때문이에요. 컨테이너 내부에는 호스트와 동일한 디렉터리 구조가 존재하지 않아요.
✅ 해결법: 컨테이너 내부의 경로를 확인하거나, 호스트의 디렉터리가 컨테이너의 어느 경로로 마운트되었는지 docker inspect 명령어로 먼저 확인하세요.

❌ 실수: 볼륨 마운트를 했는데 컨테이너 안에서 파일이 보이지 않아요.
왜 발생하는가: 마운트 명령 시 소스(Host)와 타겟(Container) 경로의 순서를 바뀌었거나, 마운트 포인트가 컨테이너 내 기존 디렉터리를 덮어버렸을 수 있어요.
✅ 해결법: -v [호스트경로]:[컨테이너경로] 형식을 정확히 지켰는지 다시 검토하세요.

❌ 실수: cd는 되는데 ls를 하면 권한 오류가 떠요.
왜 발생하는가: 디렉터리에 대한 실행(x) 권한은 있지만, 읽기(r) 권한이 없기 때문이에요. 보통 UID 불일치 문제입니다.
✅ 해결법: 호스트 디렉터리의 소유 권한을 컨테이너 실행 계정의 UID와 일치시키거나, chmod를 통해 적절한 읽기 권한을 부여하세요.

❌ 실수: 컨테이너 내부에서 cd ..을 계속해서 호스트의 루트까지 가려고 해요.
왜 발생하는가: 네임스페이스의 경계를 이해하지 못했기 때문이에요.
✅ 해결법: 컨테이너는 독립된 세계임을 인정해야 해요. 호스트 파일이 필요하다면 반드시 볼륨 마운트를 이용해야 합니다.

❌ 실수: 쉘 스크립트를 작성했는데 호스트에서는 잘 돌아가고 컨테이너에서는 경로 오류가 나요.
왜 발생하는가: 스크립트 내에 하드코딩된 절대 경로가 호스트 기준이기 때문이에요.
✅ 해결법: 환경 변수를 활용하거나, 컨테이너 환경에 맞는 상대 경로를 사용하도록 스크립트를 유연하게 작성하세요.

자주 묻는 질문

Q. 컨테이너 안에서 호스트의 모든 파일을 볼 수 있는 방법은 없나요?
네, 보안상 원칙적으로는 불가능해요. 다만, 호스트의 특정 디렉터리를 컨테이너로 마운트해주면 해당 영역만 볼 수 있어요. 전체를 다 보여주는 것은 컨테이너의 격리 원칙을 깨뜨리는 매우 위험한 행위예요.

Q. cd /를 쳤을 때 왜 호스트랑 다른 파일들이 나오나요?
앞서 설명한 마운트 네임스페이스 때문이에요. 컨테이너는 자신만의 루트 파일 시스템을 가지고 있어서, 호스트의 루트와는 완전히 분리된 별도의 세계를 보고 있는 거예요.

Q. 컨테이너 내부의 사용자를 호스트 사용자처럼 바꾸려면 어떻게 하나요?
컨테이너를 실행할 때 --user $(id -u):$(id -g) 옵션을 사용해 보세요. 이렇게 하면 현재 호스트 사용자의 UID와 GID를 컨테이너 프로세스에 그대로 적용할 수 있어요.

Q. 마운트된 디렉터리에서 권한 문제가 계속 발생하면 가장 먼저 뭘 확인해야 하죠?
ls -ln 명령어를 사용해 보세요. 숫자로 된 UID와 GID를 직접 확인하면 호스트와 컨테이너의 계정이 얼마나 다른지 즉시 알 수 있어요.

Q. 사이드카 컨테이너도 일반 컨테이너와 똑같이 격리되어 있나요?
네, 기본적으로는 격리되어 있어요. 하지만 동일한 포드(Pod) 내에 있다면 볼륨을 공유하도록 설정되어 있어 특정 경로를 통해 서로의 데이터를 볼 수 있는 구조예요.

실무 환경별 디렉터리 관리 가이드

오늘 우리는 cd 컨테이너 환경 비교를 통해 리눅스 커널의 네임스페이스와 파일 시스템 격리 원리를 깊이 있게 살펴보았어요. 단순히 명령어를 치는 것을 넘어, 내가 지금 어떤 환경의 지도를 보고 있는지 파악하는 것이 장애를 줄이는 지름길이에요.

이제 여러분은 컨테이너 내부에서 길을 잃어도 당황하지 않고, 왜 그런 현상이 발생하는지 논리적으로 추론할 수 있는 능력을 갖추게 되었어요. 지금 바로 운영 중인 컨테이너에 접속해서 ls -ln 명령어로 현재 경로의 소유자 ID를 확인해 보는 건 어떨까요?

오늘 할 일: 현재 사용 중인 컨테이너의 마운트된 볼륨 경로와 호스트의 실제 경로를 매칭해 보세요.
이번 주 할 일: UID/GID 불일치 문제를 해결하기 위한 --user 옵션 활용법을 실습해 보세요.
실행 직전 할 일: 중요한 설정 파일을 수정하기 전, 반드시 호스트와 컨테이너의 경로가 일치하는지 다시 한번 확인하세요.

컨테이너와 호스트에서 같은 명령을 실행해 차이를 직접 눈으로 비교해 보며 감각을 익히는 것이 가장 좋은 학습법이에요. 더 깊이 있는 리눅스 운영 지식이 필요하다면 아래의 글도 함께 읽어보시길 권해요.

관련 글: 리눅스 파일관리 명령어 모음 가이드