- 서버 배포와 프로세스 격리 문제의 역사를 추적하며, FreeBSD jails가 현대 컨테이너 개념을 업계보다 10년 앞서 구현했음을 조명하는 글
- 2000년 FreeBSD 4.0에 도입된 jails는
chroot를 확장해 파일시스템·네트워크·프로세스의 완전한 격리를 커널 네이티브 기능으로 제공 - Linux는 2008년 LXC, 2013년 Docker를 통해 컨테이너에 도달했지만, 그 과정에서 namespace·cgroups·OCI 등 복잡한 추상화 계층이 누적
- Docker가 잘 해결한 것은 애플리케이션 패키징과 배포(shipping) 문제이며, jails는 격리는 뛰어나지만 네이티브 배포 표준이 부재한 점이 약점
- 후속편에서 jails 기반 인프라 구축, ZFS 스냅샷, Ansible 프로비저닝 등 실제 운용 방법을 다룰 예정
초기 서버 배포의 문제
- 수십 년 전 서버에 무언가를 배포하는 표준적 방법은 Total Commander, FileZilla, FAR Manager 등으로 FTP를 통해 수동으로 파일을 복사하는 것이었으며, 고급 사용자는
scp나rsync를 사용했지만 본질은 동일 - 혼자 작업하는 프로젝트에서는 실수가 큰 문제가 아니었지만, 수십 개의 클라이언트 프로젝트를 관리할 때는 치명적
- 일반적인 백엔드 구성에서 여러 웹사이트가 동일한 Apache 웹 서버 인스턴스를 공유하며 같은 생명주기를 가졌고, Apache가 다운되면 모두 다운
- 트래픽 급증 시 한 사이트가 모든 리소스를 소비하면 같은 서버의 다른 사이트들이 조용히 질식하는 문제 발생
- 시스템 관리자들은 셸 스크립트로 자동화를 시도했지만, 버전 관리나 롤백을 위한 표준적인 방법이 존재하지 않았으며, 프로젝트 폴더명에 증분 번호나 타임스탬프를 붙이는 관례를 사용
해결해야 할 두 가지 핵심 문제
- 배포(Deployment): 안정적 전달, 휴먼 에러 방지, 버전 관리와 롤백 구현, 모든 비즈니스 케이스를 커버하는 범용 솔루션 필요
- 프로세스 격리(Process Isolation): 앱과 시스템 간 상호 보호, 한 앱의 요구사항이 다른 앱을 몰래 깨뜨리는 상황 방지, 의존성 충돌 해결 필요
- 배포 문제 해결 시도는 현대의 CI/CD 파이프라인, 패키징 표준, 버전 관리 시스템으로 진화했지만, 격리 문제의 역사는 상대적으로 덜 알려져 있음
chroot에서 가상 머신까지
- 1979년 Bell UNIX가 도입한
chroot는 프로세스에 파일시스템의 격리된 뷰를 제공해 서브트리 밖에 접근하지 못하게 하는 원시적이지만 유용한 아이디어- 한계: 파일시스템만 격리하며, 네트워크·다른 프로세스·시스템 리소스에는 여전히 간섭 가능하고 탈출도 가능
- 최초의 본격적인 엔터프라이즈 해답은 가상 머신(VM) 으로, VMware가 1990년대 후반에 주류화
- 각 애플리케이션에 완전히 격리된 OS 환경을 제공했지만, 모든 VM이 완전한 OS를 포함해 상당한 오버헤드와 분 단위 시작 시간이라는 비용 문제 존재
FreeBSD Jails의 탄생
- 2000년, Windows Server도 Linux도 아닌 FreeBSD에서 조용한 혁명 발생
- FreeBSD는 Linux와 근본적으로 다른 방식으로, Linux가 커널만 제공하고 GNU 유저랜드·패키지 생태계·배포판별 선택이 조합되는 반면, FreeBSD는 커널·유저랜드·기본 도구·라이브러리를 하나의 완전한 OS로 함께 개발·버전 관리·테스트
- 이 일관된 기반 위에 구축된 솔루션이 jails로, Poul-Henning Kamp과 Robert Watson이 발표하고 FreeBSD 4.0(2000년 3월)에 네이티브 커널 기능으로 탑재
- 각 jail은 자체 파일시스템 뷰, 네트워크 스택, 프로세스 공간을 가지며 호스트 시스템은 보이지 않음
- 호스트 커널을 공유하므로 거의 제로에 가까운 오버헤드와 거의 즉각적인 시작 시간 실현
- FreeBSD는 현재 컨테이너라 부르는 것의 실용적 구현을 업계보다 10년 앞서 프로덕션에서 달성
격리 기술의 타임라인
- 격리 문제의 실제 진화 경로: 격리 없는 공유 서버 → 무겁지만 격리된 가상 머신 → 경량이면서 격리된 컨테이너
- FreeBSD는 2000년에 세 번째 단계에 도달, Linux는 2008년 LXC로 도달, Docker는 2013년에 등장
- Docker가 혁명적이라 찬사받을 때 FreeBSD jails는 이미 13년간 성숙하고 실전 검증된 상태
Linux가 승리한 이유
- 기술적 우월성이 생태계 전쟁에서 승리하지 못함
- Linux는 빠른 의사결정, GPL 라이선스의 바이럴 효과, Red Hat과 IBM의 강력한 엔터프라이즈 지원으로 승리
- 이후 Google, Facebook, Amazon이 대규모 데이터센터를 위한 도구를 개발하며 전체 업계 방향을 설정
- Linux는 "상용 라이선스를 못 사는 사람들의 무료 OS"에서 "서버용 유일한 선택지" 로 변모
Linux 컨테이너 생태계의 복잡성
- Linux 엔지니어들은 격리와 배포 문제를 해결하기 위해 namespace, cgroups, seccomp 등 커널 프리미티브를 구축한 뒤, 그 위에 LXC(2008) → OCI/runc(2015) → Docker/Podman(2013/2018) → Docker Hub 등 복잡한 추상화 계층을 쌓음
- 결과적으로 클라우드 기반, 벤더 종속적 인프라를 위한 과도하게 엔지니어링된 누수 추상화(leaky abstractions)의 덩어리가 형성
- 오늘날 애플리케이션을 대규모 시스템에서 운영하려면 Docker로 컨테이너화하고 Kubernetes로 오케스트레이션하는 것이 암묵적 기본값으로 자리잡았으며, 여러 옵션 중 하나가 아닌 당연한 선택으로 제시
Docker의 기여와 Jails의 약점
- Docker가 잘 해결한 것은 shipping 문제: 애플리케이션을 모든 의존성과 함께 패키징하고, 레지스트리를 통해 배포하며, 어떤 머신에서든 동일하게 실행하는 범용 표준 제공
- OCI 이미지 포맷이 실질적인 업계 표준으로 자리잡음
- Jails는 격리 문제를 훌륭하게 해결하지만 shipping에 대한 네이티브 솔루션이 부재하며, 이것이 Docker 생태계에 비해 jails 생태계가 미성숙하게 느껴지는 주요 원인
- 커뮤니티도 이 격차를 인식하고 있으며, 일부 도구(cbsd, bastille, pot, appjail 등)가 현대 컨테이너 생태계를 모방하려 시도 중이고, FreeBSD 네이티브 프리미티브를 활용하는 다른 접근법도 존재
후속편 예고
- 다음 파트에서 FreeBSD 기반 인프라의 간결함과 우아함, jails의 기초부터 작동 방식, jail 관리자를 통한 보일러플레이트 감소, Ansible을 이용한 프로비저닝과 배포, ZFS 스냅샷의 강력함, 그리고 이 모든 것을 결합해 Hypha를 위한 견고하고 확장 가능한 인프라를 구축하는 방법을 다룰 예정