2025년 9월 17일·7분
컨테이너와 클라우드 OS에 깔린 켄 톰프슨의 UNIX 원칙
켄 톰프슨의 UNIX 원칙—작은 도구, 파이프, 파일 인터페이스, 명확한 경계—이 어떻게 컨테이너, 리눅스, 클라우드 인프라를 형성했는지 살펴봅니다.
켄 톰프슨의 UNIX 원칙—작은 도구, 파이프, 파일 인터페이스, 명확한 경계—이 어떻게 컨테이너, 리눅스, 클라우드 인프라를 형성했는지 살펴봅니다.
켄 톰프슨은 "영원한 운영체제"를 만들려 한 게 아니었습니다. 데니스 리치와 벨 연구소의 다른 이들과 함께 그는 개발자가 이해하고 개선하며 기계 간에 옮길 수 있는 작고 사용하기 쉬운 시스템을 만들려 했습니다. UNIX는 실용적인 목표에 의해 형성되었습니다: 핵심을 단순하게 유지하고, 도구들이 잘 함께 동작하게 하며, 사용자를 한 컴퓨터 모델에 묶어두지 않는 것.
놀라운 점은 초기 선택들이 현대 컴퓨팅에 얼마나 잘 맞아떨어지는지입니다. 터미널이 웹 대시보드로 바뀌고 단일 서버가 가상 머신의 무리로 바뀌었지만 같은 질문들이 반복해서 등장합니다:
구체적인 UNIX 기능은 진화(혹은 대체)했지만 설계 원칙은 유용함을 유지했습니다. 왜냐하면 이들은 시스템을 어떻게 구축할지 설명하기 때문입니다:
이런 아이디어는 리눅스와 POSIX 호환성부터 프로세스 격리, 네임스페이스, 파일시스템 트릭에 의존하는 컨테이너 런타임까지 어디에나 나타납니다.
우리는 톰프슨 시대의 UNIX 개념과 오늘날 당신이 다루는 것들을 연결할 것입니다:
이 글은 실용적인 안내입니다: 전문 용어는 최소화하고 구체적 예시에 집중하며 ‘왜 작동하는가’에 초점을 둡니다. 컨테이너와 클라우드 OS 동작에 대한 빠른 멘탈 모델이 필요하면 적절한 자리입니다.
준비되면 /blog/how-unix-ideas-show-up-in-containers 로 바로 넘어가도 됩니다.
UNIX는 거대한 플랫폼 전략으로 시작하지 않았습니다. 그것은 켄 톰프슨(데니스 리치와 벨 연구소의 다른 핵심 기여자들과 함께)이 만든 작고 동작하는 시스템으로 시작했으며, 명확성, 단순성, 실제 작업 완료를 우선시했습니다.
초창기에는 운영체제가 특정 컴퓨터 모델에 강하게 묶여 있는 경우가 많았습니다. 하드웨어를 바꾸면 사실상 OS(및 소프트웨어)도 바꿔야 했습니다.
이식 가능한 OS는 실용적인 의미였습니다: 같은 운영체제 개념과 많은 코드가 훨씬 적은 재작성으로 다른 기계에서 동작할 수 있다는 것. UNIX를 C로 표현함으로써 팀은 특정 CPU에 대한 의존도를 줄였고 다른 이들이 UNIX를 채택하고 수정하는 것을 현실적으로 만들었습니다.
사람들이 “UNIX”라 말할 때 원래 벨 연구소 버전, 상업적 변형, 혹은 리눅스나 BSD 같은 현대적 UNIX 유사 시스템을 뜻할 수 있습니다. 공통점은 단일 브랜드가 아니라 공유된 설계 선택과 인터페이스 집합입니다.
그래서 POSIX가 중요합니다: 많은 UNIX 동작(명령, 시스템 호출, 관례)을 규격화해 서로 다른 UNIX 및 UNIX 유사 시스템 전반에서 소프트웨어가 호환되도록 돕습니다.
UNIX는 속임수처럼 단순한 규칙을 대중화했습니다: 한 가지 일을 잘하는 프로그램을 만들고 그것들을 결합하기 쉽게 만들라. 켄 톰프슨과 초기 UNIX 팀은 거대한 올인원 애플리케이션을 목표로 하지 않았습니다. 대신 명확한 동작을 가진 작은 유틸리티를 목표로 했고, 그것들을 쌓아 실제 문제를 해결할 수 있게 했습니다.
한 가지 일을 잘하는 도구는 움직이는 부품이 적어 이해하기 쉽습니다. 테스트하기도 쉽습니다: 알려진 입력을 넣고 출력만 확인하면 되니 전체 환경을 세팅할 필요가 거의 없습니다. 요구사항이 바뀌면 모든 것을 고치는 대신 한 조각만 바꿀 수 있습니다.
이 접근법은 또한 “대체 가능성”을 장려합니다. 유틸리티가 느리거나 기능이 부족하면 동일한 기본 입출력 기대치를 유지하는 한 더 나은 것으로 교체하거나 새로 작성할 수 있습니다.
UNIX 도구를 LEGO 블록처럼 생각해보세요. 각 블록은 단순합니다. 힘은 이들이 어떻게 연결되는지에서 나옵니다.
텍스트 처리의 고전적인 예에서는 데이터를 단계별로 변환합니다:
cat access.log | grep " 500 " | sort | uniq -c | sort -nr | head
명령을 외우지 않더라도 아이디어는 명확합니다: 데이터를 시작으로 필터링하고 요약해 상위를 보여줍니다.
마이크로서비스는 "네트워크상의 UNIX 도구"가 아니며 그 비교를 억지로 하면 오해를 낳습니다. 하지만 근본적인 직관은 친숙합니다: 구성 요소는 집중되어 있고 경계는 명확하며 더 큰 시스템은 독립적으로 진화할 수 있는 작은 부품으로 조립합니다.
UNIX는 프로그램이 예측 가능한 방식으로 한 장소에서 입력을 읽고 다른 장소에 출력을 쓰게 해야 한다는 단순한 관례에서 많은 힘을 얻었습니다. 이 관례는 작은 도구들을 다시 작성하지 않고도 더 큰 "시스템"으로 결합할 수 있게 했습니다.
파이프는 한 명령의 출력을 다음 명령의 입력으로 직접 연결합니다. 메모를 전달하듯 한 도구가 텍스트를 생산하고 다음 도구가 이를 소비합니다.
UNIX 도구는 일반적으로 세 가지 표준 채널을 사용합니다:
이 채널들이 일관되기 때문에 프로그램들이 서로에 대해 아무것도 모른 채 ‘배선’될 수 있습니다.
파이프는 도구를 작고 집중되게 만듭니다. 프로그램이 stdin을 받아 stdout을 내보낼 수 있다면 대화형 사용, 배치 작업, 예약 작업, 스크립트 등 다양한 맥락에서 재사용할 수 있습니다. 이것이 UNIX 계열 시스템이 스크립트 친화적인 이유입니다: 자동화는 종종 "이 조각들을 연결하라"는 것뿐입니다.
이 조합성은 초기 UNIX에서 오늘날의 클라우드 워크플로를 조립하는 방식까지 직선적으로 이어집니다.
UNIX는 대담한 단순화를 했습니다: 다양한 자원을 파일처럼 취급하라. 디스크 파일과 키보드가 같기 때문이 아니라, 이들에게 공유된 인터페이스(open, read, write, close)를 제공하면 시스템을 이해하고 자동화하기 쉬워지기 때문입니다.
/dev/ 아래에 나타날 수 있습니다. /dev/urandom에서 읽는 것은 파일처럼 느껴지지만 실제로는 바이트를 생성하는 장치 드라이버입니다.자원들이 하나의 인터페이스를 공유하면 지렛대를 얻게 됩니다: 적은 수의 도구가 많은 맥락에서 작동할 수 있습니다. 만약 "출력은 바이트"이고 "입력은 바이트"라면 간단한 유틸리티들이 특수한 장치, 네트워크, 커널에 대한 지식 없이도 수없이 조합될 수 있습니다.
이것은 또한 안정성을 장려합니다. 팀은 읽기/쓰기 스트림, 파일 경로, 권한 같은 소수의 원시 개념을 기반으로 스크립트와 운영 습관을 만들고, 기반 기술이 바뀔 때마다 그들이 매번 바뀌지 않을 것이라고 신뢰할 수 있습니다.
현대 클라우드 운영도 이 아이디어에 의존합니다. 컨테이너 로그는 흔히 tail하고 포워딩하는 스트림으로 취급됩니다. 리눅스의 /proc는 프로세스와 시스템 텔레메트리를 파일로 노출하므로 모니터링 에이전트는 CPU, 메모리, 프로세스 통계를 일반 텍스트처럼 ‘읽을’ 수 있습니다. 그 파일형 인터페이스가 대규모에서도 관찰 가능성과 자동화를 접근하기 쉽게 만듭니다.
UNIX의 권한 모델은 겉보기엔 작습니다: 모든 파일(그리고 파일처럼 동작하는 여러 시스템 자원)은 소유자, 그룹, 그리고 세 관객—사용자(user), 그룹(group), 다른 사용자(others)—에 대한 권한 집합을 가집니다. 읽기/쓰기/실행 비트로 UNIX는 누가 무엇을 할 수 있는지에 대한 공통 언어를 만들었습니다.
-rwxr-x--- 같은 것을 본 적이 있다면 모델 전체를 한 줄에서 본 것입니다:
이 구조는 추론하기 쉽고 감사하기 쉬워 확장에 유리합니다. 또한 팀을 한 가지 깨끗한 습관으로 유도합니다: 작동시키기 위해 ‘모든 것을 개방’하지 마라.
최소 권한은 사람, 프로세스, 서비스에 그 일이 수행되는 데 정말 필요한 권한만 주고 더는 주지 않는다는 뜻입니다. 실제로 이는 자주 다음을 의미합니다:
클라우드 플랫폼과 컨테이너 런타임은 다른 도구를 사용해 같은 생각을 반영합니다:
UNIX 권한은 가치가 있지만 완전한 보안 전략은 아닙니다. 권한만으로 모든 데이터 유출을 막거나 취약한 코드를 이용한 침해를 막을 수 없으며 네트워크 제어와 비밀(secret) 관리를 대체하지 않습니다. 이것을 기반으로 생각하세요: 필요하고 이해하기 쉬우며 효과적이지만 그 자체로 충분하지는 않습니다.
UNIX는 프로세스—무언가의 실행 인스턴스—를 핵심 구성 요소로 취급합니다. 그 말은 추상적으로 들릴 수 있지만, 신뢰성, 멀티태스킹, 그리고 현대 서버(및 컨테이너)가 머신을 어떻게 공유하는지를 형성하는 방식에서 그 중요성이 드러납니다.
프로그램은 레시피 카드와 같습니다: 무엇을 할지 설명합니다.
프로세스는 그 레시피로 실제 요리하는 요리사와 같습니다: 현재 단계, 재료, 사용하는 스토브, 타이머가 있습니다. 같은 레시피로 여러 요리사가 동시에 요리할 수 있습니다—각 요리사는 같은 프로그램에서 시작했더라도 고유한 상태를 가진 별개의 프로세스입니다.
UNIX 시스템은 각 프로세스가 자체 실행 ‘버블’을 가지도록 설계되었습니다: 자체 메모리, 열린 파일의 자체 뷰, 건드릴 수 있는 것에 대한 명확한 경계.
이 격리는 실패를 국한시킵니다. 하나의 프로세스가 크래시해도 보통 다른 것들을 끌어내리진 않습니다. 이것이 하나의 머신에서 많은 서비스를 실행할 수 있는 큰 이유입니다: 웹 서버, 데이터베이스, 백그라운드 스케줄러, 로그 전송기—각각 별개의 프로세스로서 독립적으로 시작, 중지, 재시작, 모니터링될 수 있습니다.
공유 시스템에서는 격리가 안전한 자원 공유도 지원합니다: 운영체제가 CPU 시간이나 메모리 같은 한계치를 강제해 한 프로세스가 머신을 잠식하지 못하게 할 수 있습니다.
UNIX는 또한 시스템(또는 당신)이 프로세스에게 알릴 수 있는 시그널을 제공합니다. 이것은 어깨를 톡톡 두드리는 것과 같습니다:
작업 제어는 대화형 사용에서 이 개념을 확장합니다: 작업을 일시 중지하고, 포그라운드로 재개하거나 백그라운드로 돌려보낼 수 있습니다. 요점은 단순한 편의성이 아니라 프로세스가 생명 주기 단위로 관리되도록 설계되었다는 것입니다.
프로세스를 만들고 격리하고 제어하기가 쉬워지면 하나의 머신에서 많은 워크로드를 안전하게 실행하는 것이 보통이 됩니다. 이 사고 모델—감독, 재시작, 제약 가능한 작은 단위—은 현대 서비스 관리자와 컨테이너 런타임의 직접적인 조상입니다.
UNIX가 승리한 이유는 모든 기능을 가장 먼저 가졌기 때문이 아닙니다. 오랫동안 몇 가지 인터페이스를 지루하게 유지했기 때문입니다. 개발자가 같은 시스템 호출, 같은 커맨드 동작, 같은 파일 관례를 수년간 신뢰할 수 있을 때 도구들은 축적되고 재작성되지 않습니다.
인터페이스는 프로그램과 주변 시스템 간의 약속입니다: “X를 요청하면 Y를 받을 것이다.” UNIX는 핵심 약속들(프로세스, 파일 디스크립터, 파이프, 권한)을 안정적으로 유지해 새로운 아이디어가 기존 소프트웨어를 깨뜨리지 않고 위에 성장할 수 있게 했습니다.
사람들은 종종 “API 호환성”을 말하지만 두 계층이 있습니다:
안정적인 ABI는 에코시스템이 오래 가는 큰 이유입니다: 이미 빌드된 소프트웨어를 보호합니다.
POSIX는 공통된 "UNIX 유사" 유저스페이스(시스템 호출, 유틸리티, 셸 동작, 관례)를 포착한 표준 노력입니다. 모든 시스템을 동일하게 만들진 않지만 리눅스, BSD, 기타 UNIX 유래 시스템 전반에서 동일한 소프트웨어를 빌드하고 사용할 수 있는 큰 겹침을 만듭니다.
컨테이너 이미지는 조용히 안정적인 UNIX 유사 동작에 의존합니다. 많은 이미지는 다음을 가정합니다:
컨테이너가 포터블하게 느껴지는 이유는 "모든 것을 포함해서"가 아니라 널리 공유되는 안정적인 계약 위에 놓이기 때문입니다. 그 계약은 UNIX의 가장 오래가는 기여 중 하나입니다.
컨테이너는 현대적으로 보이지만 멘탈 모델은 매우 UNIX적입니다: 실행 중인 프로그램을 파일, 권한, 자원 한계가 설정된 프로세스처럼 취급합니다.
컨테이너는 "가벼운 VM"이 아닙니다. 애플리케이션과 라이브러리, 설정을 패키징한 뒤 프로세스들이 격리되어 마치 혼자인 것처럼 동작하도록 만드는 것입니다. 큰 차이점은 컨테이너가 호스트 커널을 공유한다는 점이고, VM은 자체 커널을 실행합니다.
많은 컨테이너 기능은 UNIX 아이디어의 직접적 확장입니다:
두 커널 메커니즘이 대부분의 무거운 작업을 처리합니다:
컨테이너는 커널을 공유하기 때문에 격리가 절대적이지 않습니다. 커널 취약점은 모든 컨테이너에 영향을 줄 수 있고, 잘못된 구성(루트로 실행, 과도한 권한, 민감한 호스트 경로 마운트)은 경계에 구멍을 낼 수 있습니다. "탈출" 위험은 현실적이지만 보통은 신중한 기본값, 최소 권한, 좋은 운영 위생으로 완화됩니다.
UNIX는 간단한 습관을 대중화했습니다: 한 가지 일을 하는 작은 도구를 만들고 명확한 인터페이스로 연결하며 환경이 배선을 처리하게 하라. 클라우드 네이티브 시스템은 표면적으로는 다르게 보이지만 같은 생각이 분산 작업에 놀랍도록 잘 맞습니다: 서비스는 집중되고, 통합 지점은 명시적이며, 운영은 예측 가능하게 유지됩니다.
클러스터에서 "작은 도구"는 종종 "작은 컨테이너"를 의미합니다. 모든 것을 하려는 커다란 이미지 하나를 배포하는 대신 팀은 책임을 좁게 제한한 컨테이너로 역할을 나눕니다.
몇 가지 공통 예시는 고전적 UNIX 조합을 닮았습니다:
각 부분은 포트, 파일, HTTP 엔드포인트, stdout/stderr 같은 명확한 인터페이스를 가집니다.
파이프가 프로그램을 연결했다면 현대 플랫폼은 텔레메트리 스트림을 연결합니다. 로그, 메트릭, 트레이스는 에이전트, 수집기, 백엔드로 흐르며 파이프라인과 유사합니다:
application → node/sidecar agent → collector → storage/alerts.
파이프와 같은 장점: 필터링, 샘플링, 보강 같은 단계를 삽입·교체·제거할 수 있고 생산자를 다시 쓰지 않아도 됩니다.
조합 가능한 빌딩 블록은 배포를 반복 가능하게 만듭니다: "이걸 어떻게 실행하는가"라는 논리는 누군가의 기억에 있는 대신 선언적 매니페스트와 자동화에 담깁니다. 표준 인터페이스는 작은 단위로 변경하고 진단을 추가하며 정책을 일관되게 강제할 수 있게 합니다.
UNIX 원칙이 계속 재등장하는 한 이유는 팀이 실제로 일하는 방식과 일치하기 때문입니다: 작은 단계로 반복하고 인터페이스를 안정적으로 유지하며 놀라움이 생기면 롤백합니다.
웹 서비스나 내부 도구를 오늘날 구축한다면 Koder.ai 같은 플랫폼은 그 사고방식을 마찰 없이 적용하게 하는 일종의 의견이 담긴 도구라고 볼 수 있습니다: 채팅으로 시스템을 설명하고 작은 컴포넌트를 반복하며 경계를 명확히 유지합니다(프론트엔드는 React, 백엔드는 Go와 PostgreSQL, 모바일은 Flutter 등). 플래닝 모드, 스냅샷과 롤백, 소스 코드 내보내기 같은 기능은 UNIX가 권장한 운영 습관—안전하게 변경하고 결과를 관찰하며 시스템을 설명 가능하게 유지—을 지원합니다.
UNIX 아이디어는 커널 개발자 전용이 아닙니다. 이들은 일상 엔지니어링을 더 침착하게 만들 실용적 습관입니다: 놀라움 줄이기, 실패 명확화, 재작성 없이 시스템이 진화하게 하기.
작은 인터페이스는 이해, 문서화, 테스트, 교체가 쉽습니다. 서비스 엔드포인트, CLI 플래그 집합, 내부 라이브러리를 설계할 때:
UNIX 도구는 투명한 경향이 있습니다: 무엇을 하는지 보고 생성물을 검사할 수 있어야 합니다. 서비스와 파이프라인에도 같은 기준을 적용하세요:
컨테이너화된 서비스를 구축 중이라면 /blog/containers-basics 의 기본을 다시 살펴보세요.
자동화는 위험을 줄여야지 증폭시키면 안 됩니다. 작업에 필요한 최소 권한을 사용하세요:
권한과 그 중요성에 대한 실용적 복습은 /blog/linux-permissions-explained 를 보세요.
새로운 의존성(프레임워크, 워크플로 엔진, 플랫폼 기능)을 채택하기 전에 세 가지를 물어보세요:
어느 하나라도 "아니오"라면 단순히 도구를 사는 것이 아니라 잠김(lock-in)과 숨겨진 복잡성을 사는 것입니다.
UNIX는 두 가지 반대되는 신화를 끌어당기는데 둘 다 요점을 놓칩니다.
UNIX는 설치하는 제품이 아니라 인터페이스에 대한 아이디어 집합입니다. 세부 사항은 진화했습니다(리눅스, POSIX, systemd, 컨테이너 등) 하지만 UNIX를 유용하게 만든 습관들은 여전히 사람들이 이해하고 디버그하며 확장해야 하는 곳이면 어디에나 나타납니다. 컨테이너 로그가 표준 출력으로 가고, 도구가 파이프로 입력을 받으며, 권한이 피해 반경을 제한할 때 당신은 같은 멘탈 모델을 사용하고 있는 것입니다.
작은 도구의 조합성은 팀을 ‘영리하지만 명확하지 않은’ 시스템을 만들도록 유혹할 수 있습니다. 조합은 강력한 도구이며 강한 관례와 신중한 경계와 함께일 때 최선입니다.
과도한 분할(fragmentation)이 흔합니다: “작을수록 좋다”는 이유로 수십 개의 마이크로서비스나 아주 작은 스크립트로 쪼갠 뒤 조정, 버전 관리, 교차 서비스 디버깅 비용을 치르는 경우. 셸 스크립트 스프롤(sprawl)도 문제입니다: 빠른 글루 코드가 테스트, 오류 처리, 관측성, 소유권 없이 프로덕션 필수로 변합니다. 결과는 단순함이 아니라 암묵적 의존성의 취약한 거미줄입니다.
클라우드 플랫폼은 UNIX의 강점(표준 인터페이스, 격리, 자동화)을 증폭시키지만 추상화를 쌓아 올립니다: 컨테이너 런타임, 오케스트레이터, 서비스 메시, 관리형 DB, IAM 레이어. 각 레이어는 지역적으로 노력을 줄이는 반면 전역적으로 "어디서 실패했나?"의 불확실성을 키웁니다. 신뢰성 작업은 코드 작성에서 경계, 기본값, 실패 모드를 이해하는 일로 이동합니다.
켄 톰프슨의 UNIX 원칙은 단순한 인터페이스, 조합 가능한 빌딩 블록, 최소 권한으로 시스템을 편하게 변경하고 운영하기 쉽게 하는 편향을 제공합니다. 신중하게 적용하면 현대 인프라를 운영하기 쉽고 안전하게 변경할 수 있게 합니다. 교조적으로 적용하면 불필요한 분산과 디버깅하기 어려운 복잡성을 초래합니다. 목표는 1970년대 UNIX를 그대로 모방하는 것이 아니라 압박 속에서도 시스템이 설명 가능하도록 유지하는 것입니다.
켄 톰프슨과 벨 연구소 팀은 이해하기 쉽고, 수정 가능하며 시스템을 목표로 설계했습니다: 작은 핵심, 단순한 관례, 그리고 재조합 가능한 도구들. 이런 선택은 자동화, 격리, 대규모 시스템 유지관리 같은 현대적 요구에 그대로 연결됩니다.
UNIX를 C로 다시 작성한 것은 특정 CPU나 하드웨어 모델에 대한 의존도를 줄였습니다. 이는 OS와 그 위에서 동작하는 소프트웨어를 다른 기계로 옮기는 것을 현실적으로 만들었고, 이후 UNIX 계열 시스템과 POSIX 같은 표준에 영향을 주었습니다.
POSIX는 시스템 호출, 유틸리티, 셸 관습 같은 UNIX 유사 동작의 공통 집합을 규정합니다. 모든 시스템을 동일하게 만들진 않지만, 다양한 UNIX·UNIX 계열 시스템에서 소프트웨어를 더 적은 문제로 빌드하고 실행할 수 있는 큰 호환 영역을 만듭니다.
작고 조합 가능한 도구는 이해·테스트·교체가 쉽습니다. 각 도구에 입력/출력 계약이 명확하면 도구를 직접 바꿀 필요 없이 조합으로 더 큰 문제를 해결할 수 있습니다.
파이프(|)는 한 프로그램의 stdout을 다음 프로그램의 stdin으로 연결해 변환 파이프라인을 만듭니다. stderr를 분리해두면 정상 출력은 자동화 처리하고 오류는 따로 보이거나 리다이렉트할 수 있어 자동화에 유리합니다.
UNIX는 open, read, write, close 같은 통일된 인터페이스를 파일뿐 아니라 여러 자원에 적용합니다. 그래서 동일한 도구와 습관이 널리 활용됩니다.
일반적인 예: /dev의 장치 파일, /proc 같은 텔레메트리 파일들.
소유자/그룹/다른 사용자 모델과 읽기/쓰기/실행 비트는 권한을 이해하고 감사하기 쉽게 만듭니다. 최소 권한 원칙은 필요한 것만 부여하는 운영 습관입니다.
실용적 조치 예:
프로그램은 정적 코드이고, 프로세스는 그 코드를 실행하는 동작 인스턴스입니다. UNIX의 프로세스 격리는 신뢰성 면에서 중요합니다. 실패가 한 프로세스에 갇히는 경향이 있어서 다른 프로세스에 영향을 덜 줍니다. 또한 시그널과 종료 코드를 통해 프로세스를 제어하고 감독하는 모델은 현대 서비스 관리의 기반입니다.
안정적인 인터페이스는 장기적인 계약입니다(시스템 호출, 스트림, 파일 설명자, 시그널 등). 이런 계약이 오래 유지되면 도구들이 재작성되지 않고 축적됩니다.
컨테이너는 호스트의 예측 가능한 UNIX 유사 동작에 의존하므로 안정적 ABI/API가 중요합니다.
컨테이너는 ‘프로세스 격리 + 패키징’으로 보는 것이 적절합니다. VM처럼 별도 커널을 돌리는 것이 아니라 호스트 커널을 공유합니다.
핵심 커널 메커니즘:
공유 커널이기 때문에 완전한 격리는 아니며, 루트로 실행하거나 민감한 호스트 경로를 마운트하는 등 잘못된 구성은 경계를 약화시킵니다.