▲

FreeBSD로의 회귀: 파트 1

 (hypha.pub)
3P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • 서버 배포와 프로세스 격리 문제의 역사를 추적하며, 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를 위한 견고하고 확장 가능한 인프라를 구축하는 방법을 다룰 예정
▲
GN⁺ 16시간전  [-]
Hacker News 의견들

  • 기술적 우월성만으로는 에코시스템 전쟁에서 이길 수 없었음
    90년대 중반 리눅스는 빠른 의사결정, GPL 라이선스의 확산성, Red Hat과 IBM의 기업 지원 덕분에 성장했음
    나는 1994년에 리눅스를 설치했는데, FreeBSD 커뮤니티에서는 내 $3,500짜리 PC가 “별로”라며 무시당했음
    IDE 인터페이스에 버그가 있었지만 리눅스는 며칠 만에 우회책을 냈고, BSD 쪽은 SCSI 장비를 사라고만 했음
    당시 대학생이던 나는 돈이 없었고, 결국 리눅스가 현실적인 선택이었음
    나중에 FreeBSD를 다시 써봤지만, 이미 리눅스가 내가 필요한 건 다 해주고 있었음
    관련 버그는 CMD640 위키 문서에 정리되어 있음

    • 나도 FreeBSD 팬이지만, 리눅스와 기능적 수렴이 많이 이루어졌다고 느낌
      그래도 FreeBSD는 시스템의 일관성이 더 높고, 사운드나 이벤트 API 같은 핵심 구성요소가 안정적으로 유지된다는 점이 마음에 듦
      최신 하드웨어 드라이버 지원은 여전히 리눅스가 낫지만, FreeBSD가 너무 “리눅스화”되지 않기를 바람
    • 요즘 BSD를 쓰는 사람들은 대부분 익숙해서 쓰거나, 그냥 반골 기질로 쓰는 경우가 많음
      사실 현대의 *nix라면 어느 쪽이든 거의 다 할 수 있음. 이제는 성능보다 성향과 익숙함의 문제임
    • 리눅스는 초기에 상업적 관심을 받으면서 하드웨어 지원이 폭발적으로 좋아졌음
      반면 BSD는 AT&T와의 소송 때문에 기업들이 꺼렸고, 그 사이 리눅스가 시장을 장악했음
      지금도 FreeBSD를 옹호하는 글이 나오지만, 90년대에 굳어진 흐름을 깨긴 어려움
    • BSD 진영이 내 PC를 비웃었다는 얘기에 웃음이 나옴
      그래도 하드웨어 지원은 지금도 개선될 여지가 많다고 생각함
    • 1992~1994년 사이 BSD는 소송 위협을 받는 동안 리눅스가 성장했음

  • 글이 흥미로웠음
    리눅스의 namespaces, cgroups, seccomp 같은 커널 프리미티브가 결국 복잡한 추상화 생태계를 만들었다는 평에는 동의하지 않음
    리눅스가 성공했기 때문에 복잡해진 것이지, 실패한 설계 때문은 아님
    만약 BSD가 주류였다면 똑같이 “과공학적” 생태계가 생겼을 것임

    • FreeBSD는 해커 문화보다 엔지니어링 중심 사고방식이 강함
      컨테이너는 결국 가벼운 VM에 불과하므로, 차라리 진짜 VM을 쓰는 게 낫다고 생각함
    • BSD 유틸리티와 GNU 유틸리티를 비교하면 스타일 차이가 확실함
      Docker가 인기 있는 이유는 재사용성과 생태계이지, 보안 격리 때문은 아니었음

  • FreeBSD의 jail은 단순하고 우아하지만, 리눅스의 OCI 컨테이너는 훨씬 사용하기 쉬움
    컨테이너는 커널의 독립된 기능이 아니라 여러 네임스페이스와 마운트, 프로세스 격리를 조합한 환상임
    리눅스의 설계는 의도된 것이며, cgroups와 seccomp는 컨테이너 외에도 systemd나 flatpak 등에서 폭넓게 쓰임

    • FreeBSD는 여전히 네트워킹 장비나 스토리지 컨트롤러 같은 분야에서 강점이 있음
      “가축 vs 애완동물” 철학을 VM과 오케스트레이션 레벨에서 적용할 수 있음
    • 리눅스 컨테이너는 생성과 실행 속도가 FreeBSD jail보다 훨씬 빠름
      jails가 더 낫다는 말은 현실적으로 와닿지 않음

  • Docker가 승리한 이유는 기술적 격리가 아니라 생태계였음
    Dockerfile, public registry, compose 같은 도구 덕분에 30초 만에 실행 가능한 환경을 만들 수 있었음
    FreeBSD jail은 기술적으로 훌륭했지만, 진입 장벽이 높았음
    최근에는 컨테이너 스택의 복잡성 때문에 단순한 jail이나 VM으로 돌아가려는 움직임도 보임

    • FreeBSD는 시장 점유율이 0.1% 수준이라 “이길” 수 없었음
      하지만 경쟁이 아니라 각자 역할이 다를 뿐임
    • Docker의 클라이언트/서버 구조 덕분에 Docker Desktop 같은 통합 환경이 가능했음
      FreeBSD에는 이런 개념이 없고, 이미지 시스템도 부족함
    • 나는 Docker Compose나 Swarm만 써도 충분히 단순하다고 느낌
      FreeBSD가 Docker처럼 UX와 생태계에 투자했다면 사용자층이 몇 배는 늘었을 것임
    • 원문에서도 “에코시스템”이라는 단어를 여러 번 강조하고 있음

  • 2005년쯤 회사 전체를 FreeBSD 위에 올려 운영했었음
    하지만 시간이 지나면서 리눅스가 개인과 업무 모두를 장악했음
    이제는 Docker도 충분히 괜찮고, 다시 돌아갈 논리적 이유가 없음

    • 2000년대 초 FreeBSD 4는 네트워크와 스토리지 성능이 탁월했음
      그러나 멀티코어 CPU 시대에 대응이 늦어 리눅스와 윈도우에 밀렸음
      지금은 성능이 회복됐지만, 드라이버 부족과 개발자 수의 한계로 여전히 불리함
      나는 GPU나 CUDA가 필요한 곳엔 리눅스를, 안정적인 서버엔 FreeBSD를 씀
    • 나도 비슷한 입장임. 리눅스의 투자 규모가 워낙 커서 단점이 묻힘
      FreeBSD의 UX가 더 일관적이지만, 현실적으로 리눅스가 “행복한 경로”가 되어버림
    • 사토시가 왜 윈도우를 썼는지는 여전히 의문임

  • FreeBSD를 소개하는 글은 언제나 반가움

  • FreeBSD가 2000년에 jail을 도입했지만, 리눅스에는 이미 OpenVZ와 VServer 같은 유사 기술이 있었음

    • Virtuozzo는 비공개라 확산이 늦었고, Linux-VServer는 웹호스팅에만 초점을 맞춰 주류가 되지 못했음
      결국 2000년대 후반 LXC가 등장하면서 “FreeBSD가 앞서 있었다”는 인식이 생김

  • 컨테이너와 VM의 격리 구현 방식을 기술적으로 설명한 글이 있는지 궁금함
    단순히 “같은 커널이라 약하다”는 수준이 아니라, 실제 구현 세부를 알고 싶음

  • 최근 systemd-oomd 같은 기능 때문에 FreeBSD로 돌아가고 싶다는 생각이 듦
    예전에는 터미널에서 여러 프로세스를 띄워두고 로그를 남기며 개발했는데,
    이제는 systemd가 cgroup 단위로 프로세스를 통째로 죽이는 바람에 작업이 사라짐
    이런 비호환적 시스템 변경은 개발 흐름을 깨뜨리고, 프로세스 격리를 위해 매번 systemd-run이나 Docker를 써야 하는 상황이 답답함

  • 리눅스 성공의 핵심은 GPL의 전염성과 네트워크 효과였음
    사용자들이 리눅스를 표준으로 인식하면서, 하드웨어 제조사들도 자연스럽게 리눅스용 드라이버를 내놓게 되었음
    커널의 유연함 덕분에 오픈소스 드라이버 생태계가 폭발적으로 성장했음

답변달기