Linux

UNIX와 MINIX의 영향

Linux의 개발은 UNIX와 이를 교육용으로 다시 구현한 MINIX의 영향을 받았다. 리누스 토르발스는 1990년 헬싱키 대학교에서 UNIX를 접한 뒤 운영체제와 Intel 80386 프로세서의 보호 모드, 메모리 관리와 다중 작업 기능에 관심을 갖게 되었다. 당시 대학과 기업에서 사용되는 상용 UNIX 시스템은 개인이 자신의 컴퓨터에 설치하고 내부를 자유롭게 수정하기에는 가격과 접근성 면에서 제약이 컸다.

토르발스는 앤드루 타넨바움이 운영체제 교육을 위해 개발한 MINIX를 자신의 80386 기반 개인용 컴퓨터에 설치했다. MINIX는 소스 코드와 함께 제공되어 운영체제 구조를 연구할 수 있었지만, 교육 목적의 단순한 설계를 중시했으며 당시 버전은 80386의 기능을 충분히 활용하지 않았다. 토르발스는 MINIX를 개발 환경과 참고 대상으로 사용했지만, MINIX의 소스 코드를 Linux에 복사하지 않고 새로운 커널을 독립적으로 작성했다.

Linux는 MINIX와 비슷한 UNIX식 사용자 인터페이스와 초기 파일 시스템 배치를 사용했다. 이는 기존 UNIX용 프로그램을 쉽게 이식하고 MINIX를 이용해 개발과 설치를 시작하기 위한 실용적인 선택이었다. 그러나 Linux는 MINIX의 마이크로커널 구조를 따르지 않고 프로세스 관리, 메모리 관리, 파일 시스템과 장치 드라이버를 하나의 커널 주소 공간에 배치하는 모놀리식 커널로 발전했다.

토르발스는 UNIX 프로그램과 호환되는 환경을 만들기 위해 POSIX 인터페이스도 참고했다. 1991년 7월에는 comp.os.minix 뉴스그룹에 POSIX 표준의 기계 판독 가능한 문서를 구할 수 있는지 질문했으며, 표준 문서를 충분히 확보하지 못한 부분은 대학에서 사용할 수 있던 UNIX 문서와 MINIX 관련 자료를 참고해 시스템 호출을 구현했다.^[5]

Linux가 UNIX와 비슷하다는 것은 UNIX의 원본 소스 코드를 계승했다는 뜻이 아니다. Linux는 UNIX 프로그램이 기대하는 동작과 인터페이스를 새로운 코드로 구현한 유닉스 계열 커널이며, MINIX는 그 개발을 시작하고 초기 프로그램을 준비하기 위한 발판이었다.

터미널 프로그램에서 커널로

토르발스가 처음부터 완전한 운영체제를 만들 계획을 세운 것은 아니었다. 그는 1991년 초 자신의 80386 컴퓨터에서 헬싱키 대학교의 UNIX 시스템에 접속하고 뉴스그룹을 읽기 위한 터미널 프로그램을 작성하기 시작했다.

이 프로그램은 기존 운영체제 위에서 실행되는 일반 응용 프로그램이 아니라 컴퓨터를 부팅한 뒤 하드웨어를 직접 제어했다. 토르발스는 80386의 보호 모드와 작업 전환 기능을 익히기 위해 두 프로세스가 번갈아 화면에 문자를 출력하는 프로그램을 만들었고, 여기에 키보드와 직렬 통신 처리를 추가했다. 대학 컴퓨터와 통신한 내용을 저장하기 위해 디스크 드라이버와 파일 시스템 기능도 구현했다.

프로그램에 프로세스 전환과 인터럽트 처리, 터미널 입력, 디스크 접근과 파일 시스템이 차례로 추가되면서 단순한 터미널 프로그램은 운영체제 커널에 가까운 형태가 되었다. 토르발스는 이후 이 환경에서 UNIX 프로그램을 실행할 수 있도록 시스템 호출을 구현하기 시작했다. 그는 훗날 자신이 어느 시점에 이미 커널에 필요한 상당수 기능을 만들었다는 사실을 깨달았다고 설명했다.^[6]

초기 개발은 MINIX 위에서 이루어졌다. 토르발스는 MINIX에서 GCC를 사용해 Linux 커널을 컴파일하고, 만들어진 커널 이미지를 플로피 디스크에 기록한 다음 컴퓨터를 다시 부팅해 시험했다. Linux가 멈추거나 오류가 발생하면 다시 MINIX로 부팅해 소스를 수정하고 같은 과정을 반복했다.

따라서 초기 Linux는 커널만으로 완전히 독립된 개발 환경을 제공하지 못했다. 커널을 빌드하고 디스크를 준비하려면 MINIX와 MINIX에서 실행되는 GCC가 필요했다. Linux는 먼저 다른 운영체제의 도움을 받아 만들어지고 부팅된 뒤, 점차 자체적으로 프로그램을 실행하고 자신을 다시 컴파일할 수 있는 환경으로 발전했다.

GNU 프로그램을 실행하는 운영체제 환경

Linux 커널만으로는 사용자가 명령을 입력하거나 프로그램을 컴파일하고 파일을 관리할 수 없었다. 토르발스는 커널을 실제로 시험하기 위해 이미 자유 소프트웨어로 개발되어 있던 GNU 프로그램을 Linux에 이식했다.

초기에 이식된 핵심 프로그램은 Bash와 GCC였다. Bash는 사용자가 명령을 입력하고 프로그램을 실행할 수 있는 셸을 제공했으며, GCC는 C 소스 코드를 실행 파일로 컴파일했다. 이어 GNU Make, GNU Sed, 파일 관리 도구와 압축 프로그램 등도 Linux에서 실행되었다.

1991년 8월 토르발스는 Linux에서 Bash 1.08과 GCC 1.40을 실행하는 데 성공했다고 밝혔다. 이는 커널 자체가 운영체제 전체는 아니더라도, 기존 사용자 공간 프로그램과 결합하여 실제 작업이 가능한 UNIX식 환경을 구성할 수 있다는 것을 보여주었다.^[7]

초기 실행 파일은 MINIX에서 교차 준비되었다. Linux용 Bash와 GCC 바이너리, 루트 파일 시스템을 MINIX에서 디스크에 배치한 뒤 Linux를 부팅하면 커널이 이를 실행했다. 이 단계에서 Linux는 부팅과 프로세스 실행을 담당하고, 사용자에게 보이는 명령줄 환경과 개발 도구는 GNU 프로그램이 담당했다.

Linux 0.02는 Bash와 GCC, GNU Make, GNU Sed 등의 프로그램을 실행할 수 있었지만, 커널을 컴파일하고 설치하려면 여전히 MINIX가 필요했다. 토르발스는 당시 Linux를 MINIX가 없는 사용자를 위한 독립 시스템이 아니라, 운영체제와 80386에 관심이 있는 개발자를 위한 커널이라고 설명했다.^[8]

커널과 라이브러리, 컴파일러가 발전하면서 Linux 위에서 Linux 커널 자체를 컴파일할 수 있게 되었다. 개발 환경이 MINIX에 의존하지 않게 되면서 Linux는 자신의 소스를 자신의 실행 환경에서 빌드하는 자체 호스팅 시스템이 되었다. 이 과정은 Linux가 단순한 부팅 가능한 커널에서 독립된 운영체제 기반으로 전환되는 중요한 단계였다.

Linux가 GNU 도구와 결합한 것은 새로운 사용자 공간 전체를 처음부터 개발할 필요를 없앴다. GNU 프로젝트에는 이미 셸과 컴파일러, 링커, 바이너리 도구, 파일 관리 프로그램과 여러 UNIX 호환 유틸리티가 존재했지만, 당시 GNU가 개발하던 GNU Hurd 커널은 완성되지 않은 상태였다. 반대로 Linux에는 작동하는 커널이 있었지만 완전한 사용자 공간이 없었다. 두 구성 요소가 결합하면서 비교적 짧은 기간 안에 자유롭게 사용할 수 있는 완전한 UNIX식 운영체제 환경이 형성되었다.

공개와 공동 개발의 시작

1991년 8월 25일 토르발스는 comp.os.minix 뉴스그룹에 자신이 386 및 486 AT 호환 컴퓨터용 자유 운영체제를 만들고 있다고 알렸다. 그는 이를 취미 프로젝트라고 설명하면서 MINIX 사용자들이 좋아하거나 불편하게 생각하는 기능에 대한 의견을 요청했다.

이 글은 완성된 제품의 발표라기보다 개발 중인 시스템에 참여자를 모으는 글에 가까웠다. 토르발스는 시스템이 MINIX와 비슷한 면이 있지만 MINIX 코드는 포함하지 않았고, 80386 하드웨어에 강하게 의존하며 자신이 보유한 AT 하드 디스크만 지원한다고 설명했다.^[9]

Linux 0.01 소스는 1991년 9월 핀란드의 FUNET 서버에 공개되었다. 이 버전은 일반 사용자가 바로 설치해 사용할 수 있는 완성된 시스템이 아니었으며, 별도의 실행 환경과 도구가 필요한 개발용 소스에 가까웠다. FTP 서버를 관리하던 아리 렘케는 토르발스가 생각했던 Freax 대신 서버 디렉터리 이름으로 Linux를 사용했고, 이 이름이 프로젝트의 정식 명칭으로 자리 잡았다.

1991년 10월 공개된 Linux 0.02는 Bash와 GCC 등의 프로그램을 실행할 수 있었다. 토르발스는 전체 커널 소스를 제공하고 다른 개발자들이 코드를 살펴보거나 자신에게 필요한 기능을 수정해 보도록 요청했다. 당시 Linux는 규모가 작아 개인 개발자가 전체 구조를 이해하고 직접 기능을 추가하기에 비교적 적합했다.

인터넷을 통해 소스가 공개되자 여러 개발자가 각자 보유한 하드웨어에서 Linux를 시험하고 오류 보고와 수정 코드를 보냈다. 토르발스 혼자서는 접할 수 없던 디스크 제어기와 그래픽 카드, 네트워크 장치에 대한 지원이 외부 기여를 통해 추가되었다. 새로운 파일 시스템과 네트워크 기능, 메모리 관리 개선도 서로 다른 개발자가 맡기 시작했다.

Linux의 공개 개발 방식은 개발자가 먼저 완전한 설계를 확정하고 구현을 배포하는 방식과 달랐다. 실행 가능한 초기 버전을 빠르게 공개하고, 실제 사용자가 시험한 결과와 패치를 지속해서 통합했다. 토르발스는 모든 코드를 직접 작성하는 역할에서 점차 변경 사항을 검토하고 공식 버전에 포함할 코드를 결정하는 유지관리자 역할로 이동했다.

라이선스 변경과 확산

초기 Linux에는 소스의 사용과 재배포를 허용하지만 금전적인 대가를 받고 배포하는 것을 제한하는 토르발스의 자체 라이선스가 적용되었다. 이 조건은 소프트웨어를 복사해 판매하거나 유료 지원과 함께 제공하려는 배포자와 기업의 활동을 제한할 수 있었다.

토르발스는 Linux 0.12를 발표하면서 상업적 배포 금지 조건을 제거하고 GNU의 카피레프트 조건과 호환되도록 라이선스를 변경하겠다고 밝혔다. 변경된 조건은 1992년 2월부터 적용되었으며 Linux는 이후 GNU GPL 버전 2로 배포되었다.^[10]

GPL은 누구나 Linux를 사용하고 수정하며 복사본을 판매할 수 있게 했다. 대신 수정한 커널을 배포할 때는 해당 소스 코드와 동일한 자유를 수령인에게 제공해야 했다. 이 구조는 Linux를 특정 기업이 독점적인 제품으로 전환하는 것을 막으면서도, 배포판과 설치 매체, 기술 지원과 하드웨어를 판매하는 사업을 가능하게 했다.

라이선스 변경은 Linux와 GNU 사용자 공간을 법적·기술적으로 함께 배포하기 쉽게 만들었다. 대학과 개인 개발자는 비용 없이 시스템을 내려받아 연구할 수 있었고, 기업은 Linux를 제품에 포함하거나 고객에게 판매하면서 필요한 기능을 직접 개발할 수 있었다. 개발 결과가 다시 공개되면서 다른 사용자와 기업도 이를 활용할 수 있었다.

Linux 0.12 무렵에는 가상 메모리와 작업 제어 등이 추가되고 설치 가능한 디스크 이미지도 제공되기 시작했다. Linux를 시험하려는 사용자의 수가 늘었으며, 단일 FTP 서버에 올라온 커널과 여러 도구를 직접 찾아 조합하는 방식은 점차 한계를 드러냈다.

초기 배포판의 등장

초기 Linux 사용자는 커널 이미지와 Bash, GCC, C 라이브러리, 파일 도구와 설치 프로그램을 서로 다른 FTP 위치에서 내려받아 직접 조합해야 했다. 각 프로그램이 요구하는 라이브러리 버전도 맞춰야 했으며, 하드 디스크 파티션을 준비하고 부팅 디스크와 루트 디스크를 만드는 과정도 대부분 수동으로 수행했다.

이 문제를 해결하기 위해 커널과 사용자 공간 프로그램, 라이브러리와 설치 절차를 하나의 묶음으로 제공하는 Linux 배포판이 등장했다. 배포판은 새로운 운영체제 커널을 만드는 것이 아니라 Linux 커널을 선택하고, 그 위에서 사용할 프로그램과 설정, 설치·업데이트 방식을 함께 관리했다.

Linux 초기에는 부팅 디스크와 루트 파일 시스템을 모은 여러 비공식 패키지가 존재했기 때문에 무엇을 최초의 배포판으로 볼 것인지는 기준에 따라 달라진다. 단순히 Linux 실행 파일과 도구를 묶은 초기 모음까지 포함할 수도 있지만, 다른 운영체제 없이 설치 절차를 통해 독립된 Linux 시스템을 구성할 수 있었던 최초의 배포판으로는 일반적으로 MCC Interim Linux가 언급된다.

MCC Interim Linux는 영국 맨체스터 컴퓨팅 센터의 오언 르 블랑이 만들었으며 1992년 2월 처음 공개되었다. 르 블랑은 Linux 0.11을 설치하면서 작동하는 파티션 도구와 필요한 프로그램을 여러 곳에서 따로 구해야 했던 불편을 겪었다. 그는 간단하고 더 완전한 설치 절차, 백업과 복구 기능을 제공하려는 목적으로 커널과 여러 유틸리티를 플로피 디스크 세트로 묶었다.^[11]

MCC Interim Linux는 설치를 어느 정도 자동화했지만 포함된 소프트웨어의 범위는 제한적이었다. 같은 해 등장한 SLS는 X Window System과 네트워크 프로그램, 개발 도구를 포함한 더 큰 시스템을 제공하면서 널리 사용되었다. SLS는 사용자가 Linux를 직접 조립하지 않고도 비교적 완전한 UNIX식 환경을 설치할 수 있게 했으며, 이후 여러 배포판에 직접적인 영향을 주었다.

SLS의 설치 방식과 품질 관리에 불만을 가졌던 패트릭 볼커딩은 이를 수정한 시스템을 만들었고, 사용자들의 요청에 따라 1993년 7월 Slackware 1.0으로 공개했다.^[12] Slackware는 비교적 단순한 구성과 UNIX에 가까운 관리 방식을 유지하면서 장기간 개발되는 배포판이 되었다.

1992년 말에는 Yggdrasil Linux/GNU/X가 등장했다. Yggdrasil은 CD-ROM을 주요 배포 매체로 사용하고 CD에서 직접 시스템을 실행할 수 있는 환경을 제공한 초기 상용 배포판이었다. 당시 인터넷 연결이 느리거나 제공되지 않는 사용자에게 CD-ROM은 대량의 소프트웨어를 전달하는 효과적인 수단이었다.

1993년 8월 이언 머독은 Debian 프로젝트를 시작했다. Debian은 한 개인이나 기업이 완성된 배포판을 공개하는 방식에서 더 나아가, 배포판 자체를 공개적인 공동 개발 프로젝트로 만들고자 했다. 패키지를 세분화하고 의존 관계와 업그레이드를 체계적으로 관리하며, 누구나 개발 과정에 참여할 수 있는 운영 구조를 형성했다.^[13]

이 시기부터 Linux 사용자는 커널을 직접 조립하기보다 목적과 운영 방식이 다른 배포판을 선택하기 시작했다. 배포판은 설치와 패키지 관리, 보안 수정, 문서와 사용자 지원을 담당했고, Linux 커널 개발자는 하드웨어와 운영체제의 핵심 기능에 집중할 수 있게 되었다.

Linux 1.0과 대중적 인지도 확대

Linux는 초기부터 Usenet과 FTP를 통해 알려졌지만, 처음에는 운영체제 개발자와 대학 사용자, UNIX에 익숙한 기술자들이 주로 사용했다. 설치가 복잡하고 지원되는 하드웨어가 제한적이었기 때문에 일반 개인용 컴퓨터 사용자가 쉽게 접근할 수 있는 시스템은 아니었다.

배포판이 설치 절차와 프로그램 구성을 정리하면서 Linux를 시험할 수 있는 사용자의 범위가 넓어졌다. 대학과 연구 기관에서는 값비싼 UNIX 워크스테이션 대신 일반 386 및 486 컴퓨터에서 UNIX 개발 환경과 네트워크 서비스를 사용할 수 있다는 점이 주목받았다. 학생과 개발자는 운영체제의 전체 소스를 읽고 수정할 수 있었으며, 인터넷을 통해 수정 사항을 바로 공유할 수 있었다.

Linux 관련 뉴스그룹과 메일링 리스트, FTP 미러가 늘어나면서 개발 과정도 빨라졌다. 사용자가 증가할수록 더 많은 하드웨어에서 시험이 이루어졌고, 새로운 장치 드라이버와 파일 시스템, 네트워크 기능이 추가되었다. 개선된 기능은 다시 배포판을 통해 더 많은 사용자에게 전달되는 순환 구조가 형성되었다.

1994년 3월 14일 Linux 1.0이 공개되었다.^[14] 1.0은 Linux가 실험적인 개인 프로젝트를 넘어 안정적인 버전 번호를 부여할 수 있는 단계에 이르렀음을 상징했다. TCP/IP 네트워크와 여러 파일 시스템, 가상 메모리와 UNIX식 프로세스 환경을 제공하면서 인터넷 서버와 개발 시스템으로 실제 사용될 수 있었다.

Linux 1.0 전후로 Linux 전문 서적과 잡지, 사용자 모임과 상용 배포판이 등장했다. 인터넷을 통해 무료로 받을 수 있다는 점뿐 아니라 CD-ROM과 서적에 포함된 설치 매체를 구입할 수 있게 되면서 네트워크 접근이 제한된 사용자에게도 보급되었다.

Linux는 특정 제조사의 컴퓨터에 묶이지 않고 범용 PC에서 실행되었으며, 기존 UNIX 개발자가 익숙한 셸과 컴파일러, 네트워크 프로그램을 사용할 수 있었다. 이식과 수정이 자유로웠기 때문에 대학 연구실, 인터넷 서비스 제공자와 소규모 기업이 웹 서버와 전자우편, DNS, 파일 서버 등의 용도로 채택하기 시작했다.

상용 배포판과 지원 산업

Linux가 실제 업무에 사용되기 시작하면서 설치 매체만 제공하는 것을 넘어 검증된 패키지와 업데이트, 문서, 기술 지원을 판매하는 기업이 등장했다. Red Hat, SUSE와 같은 회사는 자유롭게 배포되는 소프트웨어를 기반으로 배포판을 만들고 기업 고객에게 장기적인 유지보수와 지원 서비스를 제공했다.

이 사업 모델에서 고객은 소프트웨어를 실행할 권리 자체보다 안정적으로 구성된 배포판과 보안 업데이트, 문제 해결과 인증에 비용을 지불했다. 소스 코드가 공개되어 있어도 대규모 조직에서는 어떤 버전을 사용할지 결정하고, 수정 사항을 검증하며, 장애에 책임 있게 대응할 공급자가 필요했다.

배포판 기업은 커널과 사용자 공간 프로젝트에 개발자를 고용해 기능을 직접 개선했다. 기업 고객이 요구하는 대용량 메모리와 다중 프로세서, 저장 장치, 네트워크 성능, 보안과 관리 기능을 Linux에 추가하고 이를 상위 프로젝트에 제출했다. 특정 기업 내부에만 수정본을 유지하는 것보다 공식 커널에 기능을 포함시키는 편이 이후 버전과의 호환성을 유지하고 장기적인 관리 비용을 줄이는 데 유리했다.

하드웨어 제조사도 Linux용 드라이버와 플랫폼 지원을 확대했다. 운영체제가 자사의 서버와 프로세서, 저장 장치에서 안정적으로 실행되면 새로운 고객을 확보할 수 있었고, 하나의 공통 커널을 지원함으로써 서로 다른 UNIX 계열 운영체제를 각각 개발하거나 이식하는 부담을 줄일 수 있었다.

기업의 채택과 기여

1990년대 후반 Linux는 인터넷 서버 시장에서 존재감을 확대했다. 저렴한 x86 서버 여러 대를 연결해 서비스를 구성할 수 있었고, UNIX용 서버 프로그램을 비교적 쉽게 이식할 수 있었다. 웹 서버와 데이터베이스, 네트워크 서비스처럼 그래픽 데스크톱에 의존하지 않는 작업은 Linux가 먼저 경쟁력을 확보한 분야였다.

기업이 개인이 시작한 Linux를 채택한 이유는 개발자의 배경보다 시스템이 제공하는 기술적·경제적 조건에 있었다. Linux는 특정 하드웨어 업체의 독점 운영체제와 달리 여러 제조사의 장비로 이식할 수 있었고, 소스 코드에 접근해 필요한 기능과 오류를 직접 수정할 수 있었다. 기존 UNIX 개발자의 지식과 소프트웨어를 활용하기도 쉬웠다.

기업 입장에서 Linux는 단순히 무료인 운영체제가 아니었다. 소프트웨어 라이선스 비용을 줄이면서도 하드웨어와 지원 업체를 선택할 수 있었고, 특정 공급자의 제품에 장기간 종속되는 상황을 완화했다. 여러 기업이 동일한 커널 개발 비용을 공동으로 부담하고 각자 하드웨어, 미들웨어, 데이터베이스와 기술 지원을 판매할 수도 있었다.

1998년과 1999년에는 Intel이 Red Hat에 투자하고 IBM, Hewlett-Packard, Silicon Graphics와 여러 하드웨어 업체가 Linux 지원 계획을 발표했다. 1999년 IBM은 Red Hat과 협력하여 Linux를 자사의 서버와 워크스테이션에서 지원하겠다고 발표했다. 당시 기업 도입의 주요 장애물 가운데 하나는 문제가 발생했을 때 책임지고 지원할 공급자가 부족하다는 점이었으며, IBM과 기존 서버 업체의 참여는 Linux에 상업적 신뢰성을 부여했다.^[15]

IBM은 이후 Linux를 x86 서버뿐 아니라 Power 시스템과 S/390 메인프레임으로 이식하고, 2001년 Linux 개발과 마케팅에 10억 달러를 투입했다. IBM은 Linux 자체의 라이선스를 판매하기보다 Linux가 실행되는 서버와 미들웨어, 데이터베이스, 컨설팅과 기술 지원을 판매할 수 있었다. Linux를 공통 플랫폼으로 지원하면 자사의 여러 하드웨어 제품군에서 같은 소프트웨어 생태계를 제공할 수도 있었다.^[16]

기업의 참여는 Linux를 폐쇄적인 상용 운영체제로 전환하지 않았다. GPL에 따라 배포되는 커널 수정 사항은 소스 코드와 함께 제공되어야 했고, 공식 커널에 들어가려면 공개 검토와 유지관리자 승인을 거쳐야 했다. 기업 개발자와 개인 개발자는 같은 개발 절차를 사용했으며, 기여의 채택 여부는 소속보다 코드의 품질과 유지 가능성, 기존 구조와의 적합성에 따라 결정되었다.

기업은 Linux의 개발 비용을 공동으로 분담하면서도 각자의 사업에 필요한 기능을 확보했다. 커널 공동체는 기업이 제공한 전임 개발자와 시험 장비, 문서, 행사와 인프라의 지원을 얻었다. 이 관계를 통해 Linux는 자원봉사 중심 프로젝트에서 개인 개발자와 대학, 배포판 업체, 반도체 및 서버 제조사, 클라우드 기업이 함께 개발하는 산업 기반 프로젝트로 성장했다.

서버에서 다양한 플랫폼으로

Linux의 기업 도입은 먼저 서버와 네트워크 장비에서 확대되었다. 서버에서는 그래픽 사용자 인터페이스보다 안정성, 네트워크 성능, 원격 관리와 자동화가 중요했고, Linux는 기존 UNIX 운영 방식과 자유 소프트웨어 서버 프로그램을 활용할 수 있었다.

Linux는 범용 PC 서버 외에도 메인프레임과 슈퍼컴퓨터, 라우터와 임베디드 장치로 이식되었다. 소스가 공개되어 있었기 때문에 새로운 프로세서 아키텍처와 장치에 맞춰 커널을 수정할 수 있었고, 필요한 기능만 선택해 작은 시스템을 구성하는 것도 가능했다.

2000년대에는 대규모 인터넷 기업이 수많은 범용 서버를 운영하기 위한 기반으로 Linux를 채택했다. 이들 기업은 자체 데이터 센터의 성능과 확장성을 개선하기 위해 스케줄러, 파일 시스템, 네트워크와 가상화 기능을 개발하고 커널에 기여했다.

Android는 Linux 커널을 스마트폰 운영체제의 기반으로 사용하면서 Linux를 대량의 소비자 기기에 보급했다. Android는 전통적인 GNU/Linux 배포판과 다른 사용자 공간과 응용 프로그램 환경을 사용하지만, 프로세스와 메모리, 장치 드라이버와 보안을 관리하는 핵심에는 Linux 커널을 사용한다.

클라우드 컴퓨팅과 컨테이너가 확산된 뒤에는 Linux의 네임스페이스와 cgroups, 가상 네트워크와 파일 시스템 기능이 대규모 서비스 운영의 기반이 되었다. Linux는 하나의 개인용 컴퓨터를 위한 취미 커널에서 출발했지만, 공개된 소스와 재배포 가능한 라이선스, 배포판과 기업의 공동 개발을 통해 다양한 컴퓨팅 환경에서 공유되는 핵심 시스템 소프트웨어로 발전했다.

Linux라는 이름의 유래

리누스 토르발스는 개발 초기 프로젝트의 이름으로 Freax를 사용하려 했다. 이 이름은 자유를 뜻하는 free, 기이하거나 열성적인 사람을 뜻하는 freak, 그리고 UNIX 계열 시스템에서 자주 사용되던 x를 결합한 것이었다. 그는 자신의 이름을 붙인 Linux라는 이름도 생각했지만, 지나치게 자기중심적으로 보일 수 있다고 여겨 처음에는 사용하지 않았다.

1991년 토르발스가 커널 소스를 핀란드의 FUNET FTP 서버에 공개하려 하자, 서버 관리자였던 아리 렘케가 업로드 디렉터리를 만들었다. 렘케는 Freax라는 이름을 마음에 들어 하지 않았으며, 토르발스와 별도로 협의하지 않고 디렉터리 이름을 linux로 지정했다. 공개된 소스가 이 이름으로 내려받아지고 알려지면서 Linux가 프로젝트의 이름으로 정착했고, 토르발스도 이를 받아들였다.^[17]

Linux라는 이름은 토르발스의 이름 Linus와 UNIX를 결합한 표현으로 받아들여진다. 엄밀히 말하면 이 이름이 처음 가리킨 대상은 토르발스가 개발한 커널이었다. 그러나 Linux 커널을 사용해 구성한 완전한 운영체제와 배포판이 널리 보급되면서, Linux는 커널뿐 아니라 그 위에 구축된 운영체제 전체를 가리키는 이름으로도 사용되기 시작했다.

커널과 운영체제

좁은 의미의 Linux는 Linux 커널을 뜻한다. 커널은 프로세스와 메모리, 파일 시스템, 네트워크, 장치 드라이버와 하드웨어 자원을 관리하며, 사용자 공간 프로그램이 하드웨어를 사용할 수 있도록 시스템 호출 인터페이스를 제공한다.

커널만으로는 사용자가 직접 명령을 입력하거나 파일을 복사하고 프로그램을 컴파일하는 일반적인 운영체제 환경을 구성할 수 없다. 실제로 사용할 수 있는 시스템을 만들려면 다음과 같은 사용자 공간 구성 요소가 필요하다.

• 프로그램이 커널 기능을 사용할 수 있게 하는 C 표준 라이브러리
• 명령을 입력하고 프로그램을 실행하는 셸
• 파일과 프로세스, 사용자와 네트워크를 관리하는 기본 도구
• 프로그램을 컴파일하고 연결하는 컴파일러와 링커
• 시스템을 부팅하고 서비스를 시작하는 초기화 시스템
• 소프트웨어를 설치하고 업데이트하는 패키지 관리 체계
• 필요에 따라 그래픽 시스템과 데스크톱 환경, 응용 프로그램

이러한 구성 요소와 Linux 커널을 결합해 설치 가능한 형태로 제공하는 시스템이 Linux 배포판이다. 따라서 Debian, Fedora와 Alpine Linux는 동일한 Linux 커널 계열을 사용하지만 사용자 공간 도구와 라이브러리, 패키지 형식, 초기화 시스템과 관리 정책은 서로 다를 수 있다.

Linux라는 말이 어떤 문맥에서 사용되었는지는 문장에 따라 구분된다. 커널 개발이나 시스템 호출, 드라이버와 커널 버전을 이야기할 때는 Linux가 커널을 가리키는 경우가 많다. 반면 “Linux를 설치한다”, “Linux 서버를 운영한다”, “Linux용 프로그램”과 같은 표현에서는 Linux 커널을 기반으로 구성된 운영체제 환경 전체를 뜻하는 경우가 일반적이다.

초기 Linux와 GNU 도구

토르발스가 Linux를 개발하던 1991년에는 커널 이외의 UNIX식 사용자 공간 프로그램을 모두 새로 작성할 수도 있었다. 그러나 셸과 컴파일러, 링커, 라이브러리, 파일 관리 프로그램과 개발 도구를 처음부터 함께 개발하려면 커널 개발보다 훨씬 넓은 범위의 작업이 필요했다.

당시 GNU 프로젝트는 자유롭게 사용할 수 있는 UNIX 호환 운영체제를 만드는 것을 목표로 여러 구성 요소를 이미 개발해 놓은 상태였다. GCC, GNU Binutils, Bash, GNU Make와 여러 명령줄 도구가 존재했으며, 이들은 다른 UNIX 계열 운영체제에서도 실행할 수 있도록 만들어졌다. 반면 GNU가 자체 커널로 개발하던 GNU Hurd는 일반적인 운영체제로 사용할 수 있는 단계에 이르지 못했다.

Linux는 반대 상황에 있었다. 작동하는 커널은 있었지만 그 위에서 사용할 완전한 사용자 공간이 없었다. 토르발스는 GCC를 이용해 커널을 컴파일했고, Bash와 GCC를 Linux에서 실행할 수 있도록 이식하면서 시스템을 시험했다. GNU 도구를 활용함으로써 셸과 컴파일러를 비롯한 기반 프로그램을 새로 작성하지 않고도 Linux 위에 실제 개발 환경을 구성할 수 있었다.

초기 Linux 개발에서 GNU 소프트웨어가 사용된 것은 단순한 편의 이상의 의미가 있었다. Linux가 자신을 컴파일하고 일반 UNIX 프로그램을 실행하는 독립된 시스템으로 성장하려면 컴파일러와 링커, 셸과 라이브러리가 필요했고, 당시 자유롭게 사용하고 수정할 수 있으면서 충분히 완성된 도구 집합으로 GNU 소프트웨어가 가장 현실적인 선택이었다.

다만 Linux가 기술적으로 GNU에만 의존하도록 설계된 것은 아니다. Linux 커널은 특정 셸이나 C 라이브러리, 명령줄 도구 집합을 요구하지 않으며, 커널의 시스템 호출 인터페이스를 사용할 수 있다면 서로 다른 사용자 공간을 구성할 수 있다.

GNU/Linux라는 명칭

자유 소프트웨어 재단과 리처드 스톨먼은 Linux 커널과 GNU 사용자 공간을 결합한 시스템을 GNU/Linux라고 부를 것을 주장한다. 이 관점에서 Linux는 완전한 운영체제가 아니라 GNU 시스템에 추가된 커널이며, 일반적인 배포판에서 사용되는 셸과 C 라이브러리, 컴파일러와 기본 명령어 중 상당수가 GNU 프로젝트에서 만들어졌다는 점이 강조된다.

GNU 프로젝트는 1984년부터 완전한 자유 UNIX 호환 운영체제를 개발했고, Linux가 등장하기 전까지 커널을 제외한 주요 구성 요소의 상당 부분을 완성했다고 설명한다. 이후 Linux 커널이 GNU 구성 요소와 결합하면서 실제로 사용할 수 있는 자유 운영체제가 완성되었으므로, 전체 시스템의 기원과 GNU 프로젝트의 역할을 나타내기 위해 GNU/Linux라는 이름을 사용해야 한다는 주장이다.^[18]

GNU 프로젝트는 명칭을 단순한 기여자 표기의 문제로만 보지 않는다. 운영체제 전체를 Linux라고 부르면 GNU 프로젝트가 먼저 추진한 자유 소프트웨어 운영체제의 역사와 철학이 가려지고, Linux 커널과 전체 운영체제를 구별하기 어려워진다고 본다. 이에 따라 GNU 사용자 공간을 중심으로 구성된 배포판은 GNU/Linux로 부르고, Linux라는 명칭은 커널에 한정할 것을 권장한다.^[19]

Debian은 이러한 구분을 공식 명칭에 반영하여 Linux 커널을 사용하는 배포판을 Debian GNU/Linux라고 부른다. Debian은 과거 GNU Hurd나 FreeBSD 커널을 사용하는 변형도 개발했으므로, GNU/Linux라는 표현은 GNU 사용자 공간과 Linux 커널의 조합을 구체적으로 나타내는 이름으로도 사용된다.

토르발스의 입장

토르발스는 GNU 프로젝트와 GNU 도구가 Linux의 개발과 초기 확산에 중요한 역할을 했다는 점을 인정했다. 특히 GCC가 없었다면 자신이 Linux를 개발하기 훨씬 어려웠을 것이며, GNU 소프트웨어가 Linux와 자유 소프트웨어 생태계에 큰 기여를 했다는 취지로 여러 차례 언급했다.

그러나 그는 Linux를 사용하는 모든 시스템을 일반적으로 GNU/Linux라고 부르는 주장에는 동의하지 않았다. 다큐멘터리 《Revolution OS》에서 토르발스는 GNU 프로젝트가 자체적으로 Linux 배포판을 만들고 그것을 GNU/Linux라고 부르는 것은 정당하지만, Linux 기반 시스템 전체를 일괄적으로 GNU/Linux라고 부르는 것은 적절하지 않다는 입장을 밝혔다.^[20]

토르발스의 관점에서 배포판은 Linux 커널뿐 아니라 GNU 프로젝트, X Window System, 데스크톱 환경과 수많은 독립 프로젝트의 소프트웨어를 결합한 결과물이다. GNU가 중요한 부분을 차지하더라도 전체 시스템을 구성하는 모든 프로젝트를 이름에 열거할 수 없으며, 배포판을 만든 주체가 Debian Linux나 Red Hat Linux처럼 자신의 배포판 이름을 정할 수 있다는 것이다.

그는 Linux라는 이름을 반드시 커널에만 한정하지도 않았다. 커널은 운영체제에서 독립적으로 존재하는 일반 응용 프로그램과 달리, 하드웨어와 사용자 공간 사이의 핵심 실행 환경을 구성한다. 이에 따라 Linux를 커널의 이름으로 사용하면서 동시에 Linux 커널을 중심으로 구축된 운영체제 계열을 가리키는 일반 명칭으로 사용하는 관행을 받아들였다.

양측의 차이는 GNU의 기여 여부보다 어떤 범위를 하나의 운영체제로 보고 무엇을 명칭에 반영할 것인가에 가깝다. GNU/Linux라는 이름은 GNU 사용자 공간과 Linux 커널의 조합을 분명하게 표현하고 GNU 프로젝트의 역사적 역할을 강조한다. Linux라는 이름은 커널을 중심으로 형성된 더 넓은 운영체제 계열과 생태계를 포괄하며, 실제 사용과 산업에서 널리 정착한 명칭이다.

GNU를 사용하는 Linux 시스템

전통적인 범용 Linux 배포판 다수는 GNU 프로젝트의 구성 요소를 핵심 사용자 공간으로 사용한다. 대표적인 구성은 다음과 같다.

• C 표준 라이브러리로 glibc
• 컴파일러로 GCC
• 링커와 바이너리 도구로 GNU Binutils
• 셸로 Bash
• 기본 명령어로 GNU Coreutils
• 빌드 도구로 GNU Make

이러한 조합을 중심으로 구성된 Debian, Ubuntu, Fedora와 여러 배포판은 기술적으로 GNU/Linux라고 부를 수 있다. 다만 이들 시스템에도 systemd, OpenSSH, X.Org, Wayland, KDE Plasma, GNOME, Firefox와 같이 GNU 프로젝트에 속하지 않는 수많은 구성 요소가 포함된다.

따라서 GNU/Linux라는 표현도 배포판의 모든 구성 요소를 나열하는 이름은 아니다. Linux 커널과 GNU 사용자 공간이라는 두 역사적 기반의 결합을 강조하는 명칭으로 이해할 수 있다.

GNU 없이 구성된 Linux 시스템

Linux 커널은 GNU 사용자 공간 없이도 완전한 운영체제의 기반으로 사용할 수 있다. C 라이브러리와 셸, 기본 명령어, 컴파일러와 링커를 다른 구현으로 대체하면 GNU 구성 요소에 의존하지 않는 Linux 시스템을 구성할 수 있다.

Alpine Linux는 glibc 대신 musl C 라이브러리를 사용하고, GNU Coreutils의 여러 명령어 대신 BusyBox를 중심으로 기본 사용자 공간을 구성한다. Alpine은 경량성과 단순성, 보안을 주요 목표로 하며 컨테이너와 서버, 임베디드 환경에서 널리 사용된다.^[21]

BusyBox는 셸과 파일 관리, 프로세스, 네트워크 관련 명령어를 하나의 실행 파일에 모아 제공한다. 완전한 운영체제 자체는 아니지만 Linux 커널과 C 라이브러리, 부팅 구성 요소를 함께 사용하면 GNU Coreutils와 Bash 없이도 작동하는 작은 Linux 시스템을 만들 수 있다.^[22]

Chimera Linux는 GNU 사용자 공간을 사용하지 않는 범용 배포판을 명시적인 목표로 개발되었다. C 라이브러리로 musl을 사용하고, 기본 사용자 공간에는 FreeBSD 계열 도구를 사용하며, 시스템 컴파일러와 링커는 GCC와 GNU Binutils 대신 LLVM, Clang과 LLD로 구성한다. Chimera는 GNU 명령어, GNU C 라이브러리와 GNU 도구 모음을 기본 시스템에서 사용하지 않으므로 스스로를 GNU/Linux가 아닌 Linux 기반 운영체제로 설명한다.^[23]

Android도 Linux 커널을 사용하지만 전통적인 GNU/Linux 사용자 공간과는 다른 구조를 가진다. Android는 glibc 대신 자체 C 라이브러리인 Bionic을 사용하고, 응용 프로그램 환경과 시스템 서비스도 Android Runtime과 Android 프레임워크를 중심으로 구성한다.^[24] 기본 명령줄 도구 역시 GNU Coreutils 중심의 데스크톱·서버 배포판과 다르다.

라우터와 텔레비전, 저장 장치, 산업 장비 같은 임베디드 시스템에서도 Linux 커널과 BusyBox, musl 또는 다른 소형 C 라이브러리를 결합한 구성이 사용된다. 이러한 시스템은 GNU 프로그램을 일부 포함할 수도 있지만, GNU 사용자 공간을 운영체제 구성의 필수 조건으로 삼지 않는다.

명칭의 적용 범위

Linux와 GNU/Linux는 모든 상황에서 완전히 같은 범위를 가리키는 표현은 아니다.

Linux는 다음 대상을 가리킬 수 있다.

• 리누스 토르발스가 시작한 Linux 커널
• Linux 커널을 사용하는 운영체제 계열
• 개별 Linux 배포판
• Linux를 중심으로 형성된 개발·소프트웨어 생태계

GNU/Linux는 일반적으로 다음 대상을 가리킨다.

• Linux 커널과 GNU 사용자 공간을 결합한 운영체제
• GNU 도구와 glibc를 핵심 구성 요소로 사용하는 Linux 배포판
• GNU 프로젝트의 역사적·철학적 기여를 강조해 부르는 Linux 시스템

모든 GNU/Linux 시스템은 Linux 커널을 사용하지만, 모든 Linux 기반 운영체제가 GNU/Linux인 것은 아니다. Alpine Linux처럼 일부 GNU 프로그램을 사용할 수 있으나 기본 사용자 공간을 musl과 BusyBox로 구성한 배포판이 있고, Chimera Linux와 Android처럼 GNU와 구별되는 사용자 공간을 명확히 구축한 시스템도 존재한다.

실제 사용에서는 Linux라는 명칭이 커널과 운영체제 계열 모두를 가리키는 일반적인 표현으로 정착했다. GNU/Linux는 GNU 구성 요소를 중심으로 한 시스템의 구조와 역사를 보다 명확하게 나타내려는 경우 사용된다. 어느 표현을 선택하느냐에 따라 커널, 사용자 공간 또는 전체 배포판 가운데 무엇을 가리키는지 문맥에서 구체적으로 밝히는 것이 중요하다.

Linux 기반 운영체제는 하나의 단일 프로그램이 아니라 Linux 커널과 사용자 공간의 여러 구성 요소를 결합해 만들어진다. 커널은 하드웨어와 프로세스, 메모리와 장치를 관리하고, 그 위에서는 시스템 라이브러리와 초기화 시스템, 셸, 관리 도구, 그래픽 환경과 응용 프로그램이 실행된다.

각 구성 요소의 선택은 배포판과 사용 목적에 따라 달라진다. 같은 Linux 커널을 사용하더라도 glibc 대신 musl을 사용하거나, systemd 대신 다른 초기화 시스템을 선택하고, 그래픽 환경을 포함하지 않는 서버 시스템을 구성할 수 있다. 따라서 Linux 시스템에는 모든 배포판이 반드시 공유하는 하나의 완전한 사용자 공간 구성이 존재하지 않는다.

펌웨어와 부트로더

컴퓨터의 전원이 켜지면 먼저 펌웨어가 실행되어 프로세서와 메모리, 저장 장치와 기본 하드웨어를 초기화한다. 개인용 컴퓨터에서는 주로 UEFI 또는 과거의 BIOS가 이 역할을 담당한다.

펌웨어는 부팅 가능한 장치에서 부트로더를 실행한다. 부트로더는 사용할 Linux 커널 이미지와 초기 사용자 공간 이미지를 메모리에 올리고, 커널에 명령줄 매개변수와 하드웨어 정보를 전달한다. 여러 운영체제나 여러 커널 버전이 설치된 시스템에서는 사용자가 부팅 대상을 선택할 수 있도록 메뉴를 제공하기도 한다.

Linux 시스템에서 사용되는 부트로더에는 다음과 같은 것들이 있다.

• GNU GRUB
• systemd-boot
• U-Boot
• SYSLINUX
• 직접 Linux 커널을 실행하는 UEFI 구성

부트로더는 Linux 자체의 필수 고정 구성 요소가 아니다. 플랫폼에 따라 펌웨어가 커널을 직접 실행할 수도 있으며, 임베디드 장치에서는 U-Boot와 같은 전용 부트로더가 사용된다. 중요한 역할은 커널이 실행될 수 있는 상태를 준비하고 필요한 부팅 정보를 전달하는 것이다.^[25]

Linux 커널

부트로더가 제어권을 넘기면 Linux 커널이 실행된다. 커널은 프로세서와 메모리 관리 기능을 초기화하고, 사용 가능한 장치를 감지하며, 필요한 드라이버와 파일 시스템을 준비한다.

커널은 사용자 프로그램과 하드웨어 사이에서 다음과 같은 핵심 기능을 제공한다.

• 프로세스와 스레드 실행
• 가상 메모리 관리
• 파일과 저장 장치 접근
• 장치 드라이버
• 네트워크 통신
• 사용자와 권한 검사
• 프로세스 간 통신
• 자원 격리와 제한

커널은 일반 사용자가 직접 조작하는 운영 환경 전체가 아니다. 부팅을 계속하려면 루트 파일 시스템을 연결하고 사용자 공간에서 첫 번째 프로세스를 실행해야 한다. 커널의 내부 구조와 개발 방식, 시스템 호출과 드라이버에 관한 자세한 내용은 Linux 커널에서 다룬다.

초기 사용자 공간

Linux 시스템은 실제 루트 파일 시스템을 바로 사용할 수 없는 경우가 많다. 루트 파일 시스템이 암호화되어 있거나 논리 볼륨, 소프트웨어 RAID, 네트워크 저장소 또는 커널에 내장되지 않은 드라이버를 필요로 할 수 있기 때문이다.

이를 해결하기 위해 부트로더는 커널과 함께 initramfs 또는 과거 방식의 initrd를 메모리에 올릴 수 있다. 이 이미지는 임시 루트 파일 시스템으로 사용되며, 실제 루트 파일 시스템을 찾고 연결하는 데 필요한 최소한의 프로그램과 드라이버를 포함한다.^[26]

초기 사용자 공간에서는 배포판과 시스템 구성에 따라 다음 작업이 이루어질 수 있다.

• 필요한 커널 모듈 적재
• 저장 장치와 파일 시스템 감지
• 암호화된 장치의 잠금 해제
• 소프트웨어 RAID와 논리 볼륨 활성화
• 네트워크 기반 루트 파일 시스템 준비
• 실제 루트 파일 시스템 검사와 마운트
• 제어권을 실제 사용자 공간의 init 프로그램으로 이전

initramfs는 일반적으로 압축된 cpio 형식의 파일 묶음으로 제공된다. 커널은 이를 메모리에 풀어 초기 루트 파일 시스템으로 사용한 뒤, 준비가 완료되면 실제 루트 파일 시스템으로 전환한다.

모든 Linux 시스템이 복잡한 initramfs를 필요로 하는 것은 아니다. 커널에 필요한 드라이버가 내장되어 있고 단순한 로컬 저장 장치에서 루트 파일 시스템을 직접 마운트할 수 있다면 초기 사용자 공간을 생략하거나 매우 작게 구성할 수 있다.

루트 파일 시스템

루트 파일 시스템은 /를 시작점으로 하는 시스템의 기본 디렉터리 계층이다. 커널과 초기 사용자 공간이 실제 루트 파일 시스템을 연결하면 사용자 공간 프로그램과 설정 파일, 라이브러리와 시스템 데이터에 접근할 수 있게 된다.

전통적인 Linux 배포판은 FHS의 영향을 받은 디렉터리 구조를 사용한다. FHS는 UNIX 계열 시스템에서 프로그램과 설정, 가변 데이터와 사용자 파일을 일관된 위치에 배치하기 위한 지침을 제공한다.^[27]

주요 디렉터리는 일반적으로 다음 역할을 가진다.

/usr에는 일반적으로 실행 파일과 라이브러리, 아키텍처 독립 데이터가 저장된다. FHS는 /usr를 공유할 수 있는 읽기 전용 데이터의 주요 계층으로 정의하며, 호스트마다 달라지거나 실행 중 계속 변경되는 데이터는 다른 위치에 저장하도록 구분한다.^[28]

실제 배포판은 FHS를 완전히 동일하게 구현하지 않을 수 있다. 일부 배포판은 /bin, /sbin, /lib를 /usr 아래의 대응 디렉터리로 통합하고 심볼릭 링크로 유지한다. 읽기 전용 루트 파일 시스템이나 원자적 업데이트를 사용하는 시스템에서는 전통적인 디렉터리의 쓰기 가능 여부와 배치 방식도 달라질 수 있다.

init 시스템

커널이 루트 파일 시스템을 준비하면 사용자 공간의 첫 번째 프로세스를 실행한다. 이 프로세스는 일반적으로 프로세스 식별자 PID 1을 가지며, 시스템의 나머지 사용자 공간을 시작하고 관리하는 init 역할을 수행한다.

init 시스템은 다음과 같은 작업을 담당한다.

• 필수 파일 시스템 마운트
• 장치와 런타임 디렉터리 준비
• 시스템 서비스 시작
• 서비스 간 실행 순서와 의존 관계 관리
• 로그인 환경 시작
• 종료와 재부팅 처리
• 종료된 자식 프로세스 정리

현대의 많은 배포판은 systemd를 init 시스템과 서비스 관리자로 사용한다. systemd는 PID 1로 실행되면 파일 시스템, 장치, 소켓과 서비스를 단위로 관리하고, 부팅에 필요한 구성 요소를 의존 관계에 따라 시작한다.^[29]

Linux에서 systemd 사용이 필수인 것은 아니다. 배포판과 시스템 목적에 따라 다음과 같은 다른 init 체계를 사용할 수 있다.

• SysV init
• OpenRC
• runit
• s6
• BusyBox init
• 자체 제작한 단순 init 프로그램

작은 임베디드 시스템에서는 하나의 프로그램이 PID 1로 실행되어 필요한 응용 프로그램만 시작할 수 있다. 반대로 데스크톱과 서버 배포판에서는 장치 관리, 사용자 세션, 네트워크, 로그와 수많은 백그라운드 서비스를 init 시스템과 연동한다.

시스템 서비스

init 시스템은 운영체제의 기능을 제공하는 여러 백그라운드 프로그램을 시작한다. 이러한 프로그램은 일반적으로 서비스 또는 데몬이라고 한다.

서비스의 예에는 다음과 같은 것이 있다.

• 네트워크 설정과 연결 관리
• 시스템 로그 수집
• 시간 동기화
• 원격 접속
• 장치 관리
• 작업 예약
• 전원 관리
• 프린터와 오디오 관리
• 웹 서버와 데이터베이스
• 그래픽 로그인 화면

서버 시스템에서는 웹 서버, 데이터베이스와 원격 관리 서비스가 중심이 될 수 있으며, 데스크톱 시스템에서는 디스플레이 관리자, 오디오 서버, 블루투스와 네트워크 관리 서비스가 추가된다. 임베디드 시스템은 제품의 기능에 필요한 소수의 서비스만 실행할 수 있다.

서비스는 배포판이 제공하는 기본 설정과 관리 정책의 영향을 받는다. 같은 프로그램이라도 어느 사용자 권한으로 실행되는지, 어떤 디렉터리에 데이터를 저장하는지, 언제 시작되는지와 다른 서비스에 대한 의존 관계는 배포판마다 달라질 수 있다.

시스템 라이브러리

사용자 공간 프로그램은 일반적으로 커널 시스템 호출을 직접 실행하기보다 시스템 라이브러리가 제공하는 함수를 사용한다. 시스템 라이브러리는 프로그램이 파일과 메모리, 프로세스, 네트워크와 스레드를 다룰 수 있는 표준 인터페이스를 제공하고 필요한 경우 이를 Linux 시스템 호출로 변환한다.

Linux 배포판에서 사용되는 대표적인 C 표준 라이브러리는 다음과 같다.

• glibc
• musl
• uClibc-ng
• Android의 Bionic

glibc는 많은 범용 배포판에서 사용되며, C와 C 호환 언어로 작성된 프로그램에 시스템 API와 런타임 기능을 제공한다. 프로그램이 입출력과 프로세스 생성 등의 기능을 요청하면 라이브러리 함수가 필요한 Linux 시스템 호출을 수행할 수 있다.^[30]

모든 커널 기능에 반드시 라이브러리 래퍼가 존재하는 것은 아니며 프로그램이 시스템 호출을 직접 사용할 수도 있다. 그러나 라이브러리를 통하면 아키텍처별 호출 방식과 호환성 차이를 감추고 POSIX 또는 C 표준에 가까운 인터페이스를 사용할 수 있다.

시스템에는 C 라이브러리 외에도 암호화, 압축, 그래픽, 오디오, 국제화와 프로그래밍 언어 런타임을 위한 공유 라이브러리가 설치될 수 있다. 동적으로 연결된 프로그램은 실행 시 필요한 공유 라이브러리를 로더를 통해 메모리에 불러온다.

셸과 명령줄 도구

셸은 사용자의 명령을 해석하고 프로그램을 실행하는 사용자 공간 프로그램이다. 셸은 커널의 일부가 아니며, 한 시스템에 여러 종류를 함께 설치할 수 있다.

대표적인 셸에는 다음과 같은 것들이 있다.

• Bash
• Dash
• Zsh
• Fish
• KornShell
• BusyBox ash

셸은 명령 실행뿐 아니라 입출력 재지정, 파이프, 환경 변수, 작업 제어와 스크립트 실행 기능을 제공한다. 시스템 관리와 자동화에서는 여러 프로그램을 조합하는 셸 스크립트가 널리 사용된다.

ls, cp, mv, grep, sed, mount와 같은 기본 명령도 커널에 포함되지 않는다. GNU Coreutils, util-linux, BusyBox, Toybox와 같은 사용자 공간 프로젝트가 이러한 프로그램을 제공한다.

사용자가 터미널에서 입력한 명령은 대체로 다음 흐름으로 처리된다.

1. 터미널이 입력을 셸에 전달한다.
2. 셸이 명령과 인수를 해석한다.
3. 셸이 실행 파일을 찾고 새 프로세스를 시작한다.
4. 프로그램이 라이브러리와 시스템 호출을 통해 커널 기능을 요청한다.
5. 결과가 터미널이나 파일, 다른 프로그램으로 전달된다.

이 구조 때문에 같은 Linux 커널에서도 셸과 명령줄 도구를 전혀 다르게 구성할 수 있다. 범용 배포판은 여러 도구를 개별 프로그램으로 제공하는 경우가 많고, 작은 시스템은 BusyBox 하나로 많은 명령을 제공한다.

장치와 동적 장치 관리

Linux에서는 많은 장치가 /dev 아래의 특수 파일을 통해 사용자 공간에 나타난다. 프로그램은 일반 파일과 유사한 방식으로 장치 파일을 열고 읽거나 쓰면서 드라이버가 제공하는 기능을 사용한다.

현대적인 범용 배포판에서는 커널이 장치를 발견하거나 상태 변화를 알리면 사용자 공간의 장치 관리자가 이를 처리한다. 장치 관리자는 필요한 장치 노드를 만들고 권한을 설정하며, 장치 정보에 따라 추가 프로그램이나 서비스를 시작할 수 있다.

systemd를 사용하는 배포판에서는 이러한 기능을 systemd-udevd가 담당하는 경우가 많다. 다른 시스템에서는 독립적인 udev 구현이나 mdev와 같은 더 작은 장치 관리자를 사용할 수 있다.

/sys에 마운트되는 sysfs는 장치와 드라이버, 커널 객체의 계층을 사용자 공간에 보여준다. /proc에 마운트되는 procfs는 프로세스와 시스템 상태, 일부 커널 설정을 파일과 유사한 인터페이스로 제공한다. 두 파일 시스템은 디스크에 저장된 일반 파일 시스템이 아니라 커널이 실행 중 동적으로 제공하는 가상 파일 시스템이다.

사용자와 로그인 환경

Linux 시스템은 사용자와 그룹을 통해 프로세스와 파일의 소유권을 구분한다. 각 프로세스는 사용자 식별자와 그룹 식별자를 가지며, 커널은 이를 바탕으로 파일과 장치, 네트워크 기능에 대한 접근을 검사한다.

사용자는 로컬 콘솔, 그래픽 로그인 화면, SSH와 같은 원격 접속 서비스를 통해 로그인할 수 있다. 로그인 과정에서는 일반적으로 다음 정보가 준비된다.

• 사용자 식별자와 그룹
• 홈 디렉터리
• 기본 셸
• 환경 변수
• 자원 제한
• 사용자별 세션과 서비스
• 인증 및 접근 정책

사용자 계정 정보는 전통적으로 /etc/passwd, /etc/group과 관련 파일에 저장된다. 네트워크 환경에서는 LDAP, Kerberos와 다른 중앙 인증 시스템을 사용할 수도 있다.

인증 방식은 PAM을 통해 구성되는 경우가 많다. PAM은 프로그램이 비밀번호, 보안 키, 생체 인증과 중앙 인증 서비스를 공통된 방식으로 사용할 수 있도록 모듈화된 인증 인터페이스를 제공한다.

패키지와 배포판 구성

커널과 사용자 공간 프로그램을 선택하고 하나의 설치 가능한 시스템으로 조합하는 역할은 주로 Linux 배포판이 담당한다. 배포판은 단순히 프로그램을 모으는 데 그치지 않고 각 구성 요소가 함께 동작하도록 빌드 옵션과 디렉터리 구조, 기본 설정과 의존 관계를 관리한다.

배포판은 일반적으로 다음 요소를 제공한다.

• Linux 커널 또는 커널 패키지
• 시스템 라이브러리
• init 시스템과 기본 서비스
• 셸과 관리 도구
• 패키지 관리자와 소프트웨어 저장소
• 보안 업데이트
• 설치 프로그램
• 기본 설정과 정책
• 문서와 지원 체계

패키지 관리자는 프로그램과 라이브러리를 패키지 단위로 설치하고, 필요한 의존성을 함께 해결한다. 배포판에 따라 dpkg와 APT, RPM과 DNF, pacman, APK, XBPS와 같은 서로 다른 체계가 사용된다.

패키지 관리 체계는 Linux 커널의 기능이 아니다. 같은 커널을 사용하는 시스템이라도 패키지를 설치하는 방식과 저장소 구조, 업데이트 정책은 배포판이 결정한다. 컨테이너 이미지나 임베디드 장치처럼 실행 중 패키지를 추가하지 않고 전체 시스템 이미지를 교체하는 방식도 사용할 수 있다.

그래픽 환경

그래픽 환경은 Linux 시스템의 선택적 구성 요소다. 서버와 임베디드 시스템은 그래픽 스택 없이 명령줄과 네트워크 서비스만으로 동작할 수 있다.

데스크톱 Linux 시스템의 그래픽 환경은 일반적으로 여러 계층으로 구성된다.

• 커널의 그래픽 장치 드라이버
• Mesa 등의 사용자 공간 그래픽 라이브러리
• Wayland 컴포지터 또는 X11 서버
• 창 관리자 또는 컴포지터
• 데스크톱 환경
• 그래픽 툴킷
• 응용 프로그램

Wayland 환경에서는 컴포지터가 화면 합성과 창 배치, 입력 처리를 함께 담당하는 경우가 많다. X11 환경에서는 X 서버가 입력과 화면 출력을 중개하고 별도의 창 관리자가 창의 위치와 장식을 관리한다.

대표적인 데스크톱 환경에는 KDE Plasma, GNOME, Xfce, Cinnamon과 LXQt가 있다. 데스크톱 환경은 패널과 파일 관리자, 설정 도구, 알림과 기본 응용 프로그램을 통합하지만 Linux의 필수 구성 요소는 아니다.

응용 프로그램과 실행 환경

사용자가 직접 사용하는 웹 브라우저, 편집기, 게임, 서버와 개발 도구는 사용자 공간의 응용 프로그램이다. 응용 프로그램은 시스템 라이브러리와 런타임을 이용하고, 최종적으로 시스템 호출을 통해 커널의 기능을 사용한다.

Linux에서는 다음과 같은 형태로 프로그램을 실행할 수 있다.

• 네이티브 ELF 실행 파일
• 셸과 Python 등의 인터프리터 스크립트
• Java Virtual Machine과 같은 가상 머신 프로그램
• Flatpak, Snap과 AppImage 형식
• 컨테이너 내부 프로그램
• Wine을 통한 일부 Windows 프로그램

응용 프로그램의 실행 환경은 배포판의 라이브러리 버전과 파일 시스템, 권한 정책에 영향을 받는다. 배포판 패키지는 해당 시스템과 통합되도록 빌드되는 반면, 범용 패키지와 컨테이너는 필요한 라이브러리 일부를 함께 제공해 배포판 사이의 차이를 줄인다.

구성 요소의 교체 가능성

Linux 시스템의 중요한 특징은 사용자 공간의 구성 요소가 하나의 고정된 조합으로 묶여 있지 않다는 점이다. 배포판이나 시스템 제작자는 사용 목적에 따라 거의 모든 계층을 선택할 수 있다.

예를 들어 다음과 같은 구성이 가능하다.

• glibc 대신 musl 사용
• systemd 대신 OpenRC 또는 runit 사용
• GNU Coreutils 대신 BusyBox 사용
• Bash 대신 Dash 또는 Zsh 사용
• GRUB 대신 systemd-boot 또는 U-Boot 사용
• 데스크톱 환경 없이 서버 서비스만 실행
• 패키지 관리자 없이 읽기 전용 시스템 이미지 사용

구성 요소를 교체하더라도 Linux 커널의 사용자 공간 인터페이스와 프로그램이 요구하는 라이브러리·파일 구조가 호환되면 시스템을 구성할 수 있다. 반대로 같은 Linux 커널을 사용하더라도 사용자 공간과 관리 방식이 크게 다르면 사용 경험과 운영 방식도 서로 달라진다.

따라서 Linux 기반 운영체제는 단일한 제품이라기보다 Linux 커널을 공통 기반으로 여러 독립 프로젝트와 배포판 구성 요소를 조합하는 운영체제 계열로 이해할 수 있다.

Linux 기반 운영체제의 핵심에는 Linux 커널이 있다. Linux 커널은 사용자 공간 프로그램과 하드웨어 사이에서 실행되며, 프로세서 시간과 메모리, 저장 장치, 네트워크와 주변 장치를 관리한다.

Linux 커널은 주요 운영체제 기능이 하나의 커널 주소 공간에서 함께 실행되는 모놀리식 커널 구조를 사용한다. 프로세스 관리와 메모리 관리, 파일 시스템, 네트워크와 장치 드라이버가 서로 분리된 일반 사용자 프로세스로 실행되는 것이 아니라 커널 내부의 하위 시스템으로 동작한다.

다만 모든 기능이 하나의 고정된 실행 파일에만 포함되는 것은 아니다. 장치 드라이버와 파일 시스템, 네트워크 기능의 일부는 커널을 빌드할 때 내장하거나 적재 가능 커널 모듈로 만들 수 있다. 모듈은 필요한 시점에 실행 중인 커널에 적재할 수 있으므로, 모놀리식 구조를 유지하면서도 시스템 목적과 하드웨어에 따라 기능을 선택적으로 구성할 수 있다.^[31]

사용자 공간과 커널 공간

Linux는 실행 환경을 크게 사용자 공간과 커널 공간으로 구분한다. 일반 응용 프로그램과 셸, 시스템 서비스는 사용자 공간에서 실행되며, 커널 내부 데이터와 하드웨어에 임의로 직접 접근할 수 없다.

사용자 공간 프로그램은 파일을 열거나 메모리를 할당하고, 프로세스를 만들거나 네트워크 통신을 수행할 때 시스템 호출을 통해 커널에 작업을 요청한다. 커널은 요청의 유효성과 권한을 검사하고 필요한 하위 시스템을 호출한 뒤 결과를 사용자 공간에 반환한다. Linux는 시스템 호출 외에도 ioctl, Netlink, /proc, /sys와 장치 파일 등 여러 사용자 공간 인터페이스를 제공한다.^[32]

이 경계는 응용 프로그램의 오류가 커널 전체에 직접 영향을 주는 것을 줄이고, 사용자와 프로세스별 접근 권한을 적용하는 기반이 된다. 반면 커널과 커널 모듈의 오류는 높은 권한으로 실행되기 때문에 시스템 전체의 정지나 데이터 손상으로 이어질 수 있다.

프로세스와 실행 관리

커널은 실행 중인 프로그램을 프로세스와 스레드 단위로 관리한다. 각 실행 단위에는 메모리 공간과 열린 파일, 사용자 권한, 실행 상태와 같은 정보가 연결된다.

스케줄러는 실행 가능한 작업 가운데 어떤 작업을 어느 프로세서에서 실행할지 결정한다. 일반적인 대화형 프로그램과 서버 작업뿐 아니라 실시간 작업, 우선순위와 프로세서 선호도 등을 함께 처리한다.

프로세스 생성과 종료, 신호 전달, 대기, 스레드와 자원 공유도 커널이 제공하는 실행 모델을 통해 이루어진다. 네임스페이스는 프로세스가 보는 프로세스 식별자와 파일 시스템, 네트워크 등의 범위를 분리하고, cgroups는 프로세스 집합의 CPU와 메모리, 입출력 자원 사용을 분류하고 제한한다. cgroup v2는 프로세스를 계층적으로 구성하고 그 계층에 따라 자원을 분배하는 기능을 제공한다.^[33]

메모리 관리

메모리 관리 하위 시스템은 각 프로세스에 독립적인 가상 주소 공간을 제공하고, 가상 주소를 실제 메모리 페이지와 연결한다. 이를 통해 여러 프로그램이 같은 시스템에서 실행되면서도 서로의 메모리에 직접 접근하지 않도록 격리할 수 있다.

커널은 다음과 같은 메모리 관련 기능을 관리한다.

• 물리 메모리 페이지 할당과 회수
• 프로세스별 가상 주소 공간
• 실행 파일과 공유 라이브러리 매핑
• 파일을 메모리처럼 사용하는 메모리 매핑
• 페이지 캐시
• 공유 메모리
• 스왑
• 메모리 부족 상황 처리

사용자 프로그램이 요청한 메모리가 항상 즉시 물리 메모리에 할당되는 것은 아니다. 커널은 페이지 폴트가 발생할 때 필요한 페이지를 준비하거나 파일에서 읽어 들일 수 있으며, 사용 빈도가 낮은 데이터를 스왑 장치로 이동할 수도 있다.

가상 파일 시스템

Linux 커널의 가상 파일 시스템은 서로 다른 파일 시스템을 공통된 파일 인터페이스로 연결한다. 사용자 프로그램은 실제 저장 장치가 ext4, XFS, Btrfs, NFS 또는 다른 파일 시스템인지와 관계없이 open, read, write, stat과 같은 공통 연산을 사용할 수 있다.

가상 파일 시스템은 사용자 공간에 파일 시스템 인터페이스를 제공하는 동시에, 커널 내부에서 여러 파일 시스템 구현이 함께 존재할 수 있도록 추상화 계층을 제공한다.^[34]

Linux에서는 일반 저장 파일 외에도 장치와 프로세스, 커널 상태가 파일과 유사한 형태로 노출된다. /dev의 장치 파일, /proc의 프로세스와 시스템 정보, /sys의 장치 및 커널 객체 인터페이스가 이에 해당한다.

장치 드라이버

장치 드라이버는 커널이 하드웨어 장치와 통신할 수 있도록 한다. 저장 장치와 네트워크 인터페이스, 그래픽 장치, 입력 장치, USB 장치와 각종 버스 제어기가 드라이버를 통해 커널 하위 시스템에 연결된다.

드라이버는 커널에 내장하거나 모듈로 제공할 수 있다. 새로운 장치가 발견되면 커널의 장치 모델이 장치와 적절한 드라이버를 연결하며, 사용자 공간의 장치 관리 프로그램이 필요한 모듈 적재와 장치 파일 생성, 권한 설정을 보조할 수 있다.

Linux의 폭넓은 하드웨어 지원은 하나의 중앙 개발팀만으로 구성되지 않는다. 커널 공동체와 반도체 제조사, 장치 제조사, 배포판과 시스템 기업이 각 하드웨어 계열의 드라이버와 공통 기반을 함께 유지한다.

네트워크

Linux의 네트워크 스택은 응용 프로그램의 소켓 인터페이스와 네트워크 프로토콜, 라우팅, 패킷 필터링과 네트워크 장치 드라이버를 연결한다.

사용자 프로그램은 일반적으로 소켓을 만들어 TCP, UDP와 다른 통신 방식을 사용한다. 커널은 데이터를 프로토콜에 맞게 처리하고 라우팅 결정을 수행한 뒤 네트워크 장치 드라이버를 통해 송수신한다.

네트워크 하위 시스템에는 다음과 같은 기능이 포함된다.

• IPv4와 IPv6
• TCP와 UDP
• 로컬 UNIX 도메인 소켓
• 라우팅과 포워딩
• 네트워크 인터페이스 관리
• 방화벽과 패킷 필터링
• 가상 네트워크 장치
• 브리지와 터널
• 네트워크 네임스페이스
• 트래픽 제어

이 기능들은 서버와 라우터뿐 아니라 컨테이너, 가상 머신과 클라우드 네트워크를 구성하는 기반으로 사용된다.

보안과 접근 제어

Linux 커널은 사용자와 그룹, 파일 권한과 프로세스 자격 정보를 바탕으로 자원 접근을 통제한다. 전통적인 UNIX 권한 모델 외에도 권한을 세분화하는 Linux capabilities, 시스템 호출을 제한하는 seccomp, 보안 정책을 적용하는 Linux Security Modules 등의 기능을 제공한다.

Linux Security Modules 구조를 통해 SELinux, AppArmor, Smack와 같은 보안 모듈이 커널의 주요 자원 접근 지점에 추가 정책을 적용할 수 있다. 네임스페이스와 cgroups도 프로세스가 볼 수 있는 시스템 범위와 사용할 수 있는 자원을 제한하여 격리 환경을 구성하는 데 사용된다.

커널은 사용자 공간 메모리와 커널 메모리를 구분하고, 사용자 공간 데이터에 접근할 때 별도의 검사와 복사 절차를 사용한다. 지원되는 하드웨어에서는 커널이 사용자 공간 메모리를 임의로 실행하거나 예상하지 않은 방식으로 접근하지 못하도록 하는 보호 기능도 활용한다.^[35]

커널 모듈과 구성

Linux 커널은 빌드 시 수많은 기능을 선택하거나 제외할 수 있다. 프로세서 아키텍처와 장치 드라이버, 파일 시스템, 네트워크 프로토콜과 보안 기능은 Kconfig 설정을 통해 구성된다.

선택된 기능은 다음 형태 가운데 하나로 빌드할 수 있다.

• 커널 이미지에 직접 포함
• 적재 가능한 커널 모듈로 빌드
• 시스템에서 제외

커널 이미지에 포함된 기능은 부팅 초기부터 사용할 수 있다. 모듈로 빌드된 기능은 필요할 때 적재할 수 있으며 일반적으로 .ko 파일로 제공된다. 커널은 모듈이 요구하는 심볼과 버전 정보를 확인하고, 호환되지 않는 모듈의 적재를 거부할 수 있다.^[36]

배포판은 다양한 하드웨어에서 사용할 수 있도록 비교적 많은 기능을 모듈로 제공하는 경우가 많다. 임베디드 시스템은 필요한 기능만 커널에 포함하고 나머지를 제거하여 크기와 부팅 시간, 공격 표면을 줄일 수 있다.

하위 시스템의 결합

Linux 커널의 각 하위 시스템은 독립된 프로그램처럼 완전히 분리되어 있지 않다. 프로세스가 파일을 읽는 간단한 작업에도 시스템 호출 처리, 파일 디스크립터, 가상 파일 시스템, 페이지 캐시, 메모리 관리와 저장 장치 드라이버가 함께 관여할 수 있다.

이처럼 주요 기능이 같은 커널 공간에서 직접 협력하기 때문에 하위 시스템 사이의 호출과 데이터 전달이 효율적으로 이루어진다. 동시에 한 하위 시스템의 오류가 다른 부분과 시스템 전체에 영향을 줄 가능성도 있으므로, 커널 개발에서는 동시성 제어와 메모리 안전성, 인터페이스 안정성이 중요하게 다뤄진다.

Linux 커널의 세부적인 소스 구조와 스케줄러, 메모리 관리자, 시스템 호출, 동기화, 드라이버 모델과 개발 절차는 Linux 커널에서 다룬다.

Linux는 서버와 데이터 센터, 클라우드, 통신 장비, 산업 설비와 기업용 응용 프로그램의 기반으로 널리 사용된다. 산업 환경에서 Linux를 운영한다는 것은 개별 서버에 로그인하여 명령을 실행하는 것만을 뜻하지 않는다. 조직이 사용하는 배포판과 버전을 정하고, 수백 대에서 수십만 대에 이르는 시스템의 설정과 패키지, 보안 정책, 장애 대응과 수명 주기를 일관되게 관리하는 전체 활동을 포함한다.

개인이나 소규모 환경에서는 관리자가 각 시스템을 직접 구성할 수 있지만, 상업 환경에서는 동일한 작업을 반복 가능한 절차로 만들고 변경 기록과 책임 범위를 남기는 것이 중요하다. 이에 따라 Linux 운영은 일반적으로 다음 영역을 함께 다룬다.

• 운영체제와 하드웨어의 표준화
• 자동 설치와 구성 관리
• 계정과 접근 권한 통제
• 패키지와 보안 업데이트
• 로그, 지표와 추적 정보 수집
• 백업과 재해 복구
• 장애 대응과 서비스 연속성
• 규제와 보안 기준 준수
• 장기 지원과 버전 전환
• 공급업체 및 오픈 소스 공동체와의 협력

기업용 배포판

Linux 커널과 대부분의 사용자 공간 소프트웨어는 누구나 내려받아 사용할 수 있지만, 기업은 운영 환경에 직접 커뮤니티 배포판을 조합하기보다 장기 지원과 품질 보증을 제공하는 기업용 배포판을 선택하기도 한다.

대표적인 기업용 Linux 배포판에는 다음과 같은 것들이 있다.

• Red Hat Enterprise Linux
• SUSE Linux Enterprise Server
• Ubuntu LTS와 Ubuntu Pro
• Oracle Linux
• 상용 지원이 제공되는 각종 파생 배포판

기업용 배포판은 오픈 소스 소프트웨어를 독점적인 운영체제로 바꾸는 것이 아니라, 특정 시점의 커널과 라이브러리, 사용자 공간 프로그램을 함께 검증하고 일정 기간 안정적으로 유지하는 제품을 제공한다.

새로운 상위 버전이 공개된 뒤에도 기업용 배포판은 기존 버전에 보안 수정과 중요한 오류 수정을 역이식한다. 이 방식은 응용 프로그램과 관리 절차에 영향을 줄 수 있는 큰 기능 변경을 줄이면서 보안 문제를 해결할 수 있게 한다.

Red Hat은 RHEL의 각 주요 버전을 여러 지원 단계로 나누어 관리하고, 단계에 따라 기능 개선과 하드웨어 지원, 보안 및 오류 수정의 제공 범위를 달리한다.^[37] SUSE 역시 제품별 수명 주기를 공개하며 일부 제품에는 연장 지원을 포함해 장기간 유지보수를 제공한다.^[38]

기업이 구입하는 것은 Linux를 실행할 수 있는 권리만이 아니다. 구독이나 지원 계약에는 일반적으로 다음 요소가 포함된다.

• 검증된 패키지와 설치 이미지
• 보안 권고와 수정 패키지
• 장기간 유지되는 안정 버전
• 기술 문서와 지식 기반
• 장애 분석과 기술 지원
• 특정 하드웨어 및 소프트웨어 인증
• 관리·보안 도구 사용 권한
• 연장 유지보수와 버전 이전 지원

소스가 공개되어 있어도 대규모 조직은 모든 오류를 직접 분석하고 패치를 작성하기 어렵다. 지원 계약은 문제가 발생했을 때 분석과 수정에 참여할 공급자, 명확한 지원 범위와 대응 절차를 확보하는 수단이 된다.

플랫폼 표준화

기업은 조직 안에서 허용할 Linux 환경을 일정한 기준으로 제한하는 경우가 많다. 여러 배포판과 버전을 자유롭게 혼용하면 응용 프로그램 호환성, 보안 패치, 기술 지원과 관리자 교육이 복잡해지기 때문이다.

표준 플랫폼은 보통 다음 요소를 정한다.

• 승인된 배포판과 주요 버전
• 사용 가능한 커널과 패키지 저장소
• 지원 대상 하드웨어와 가상 머신 유형
• 파일 시스템과 디스크 배치
• 네트워크와 이름 해석 설정
• 인증과 접근 제어 방식
• 로깅과 감시 도구
• 백업과 보존 정책
• 보안 강화 기준
• 개발·시험·운영 환경의 차이

조직은 이러한 기준을 바탕으로 공통 설치 이미지 또는 기본 시스템 이미지를 만든다. 클라우드 환경에서는 가상 머신 이미지가 사용되고, 물리 서버에서는 자동 설치 파일과 네트워크 부팅, 임베디드 장치에서는 읽기 전용 펌웨어 이미지가 사용될 수 있다.

기본 이미지는 모든 응용 프로그램을 미리 포함하기보다 운영에 필요한 최소 구성과 보안 설정, 관리 에이전트만 제공하는 경우가 많다. 실제 서비스는 이후 자동화 도구나 컨테이너를 통해 배포된다.

표준화는 모든 서버를 영구적으로 동일하게 유지한다는 의미는 아니다. 데이터베이스와 웹 서버, 연산 노드와 네트워크 장비는 서로 다른 구성이 필요할 수 있다. 대신 시스템을 역할별로 분류하고 같은 역할에 속한 장비가 동일한 정책과 배포 절차를 따르도록 한다.

자동 설치와 프로비저닝

대규모 환경에서는 운영체제를 사람이 직접 반복 설치하지 않는다. 서버가 준비되면 자동으로 디스크를 구성하고 Linux를 설치하거나, 미리 만들어진 시스템 이미지를 복제하여 실행한다.

자동 프로비저닝에는 다음과 같은 방식이 사용된다.

• PXE와 네트워크 부팅
• Kickstart와 AutoYaST 같은 자동 설치 정의
• 클라우드 가상 머신 이미지
• cloud-init를 이용한 초기 구성
• 이미지 빌드 파이프라인
• 베어메탈 프로비저닝 시스템
• 컨테이너와 가상 머신 템플릿

프로비저닝 과정에서는 호스트 이름과 네트워크 주소, 저장 장치, 관리자 인증 정보, 패키지 저장소와 감시 시스템 연결 등이 자동으로 설정된다. 설치가 끝난 시스템은 자산 관리 데이터베이스나 서비스 검색 시스템에 등록될 수 있다.

자동화된 설치 정의는 코드와 함께 버전 관리되기도 한다. 이를 통해 누가 어떤 설정을 변경했는지 추적하고, 시험 환경에서 검증한 구성을 운영 환경에 동일하게 적용할 수 있다.

구성 관리

운영 중인 Linux 시스템의 설정은 시간이 지나면서 달라질 수 있다. 관리자가 직접 파일을 수정하거나 패키지를 추가하고, 장애 대응 과정에서 임시 변경을 남기면 처음 의도한 표준 구성과 실제 상태 사이에 차이가 생긴다. 이를 구성 편차라고 한다.

구성 관리 도구는 시스템이 유지해야 할 상태를 선언하고 여러 장비에 반복 적용한다. 대표적인 도구에는 Ansible, Puppet, Chef와 Salt가 있다.

구성 관리 대상에는 다음과 같은 것이 포함된다.

• 설치할 패키지와 제거할 패키지
• 서비스의 실행 여부
• 설정 파일의 내용과 권한
• 사용자와 그룹
• SSH와 인증 정책
• 방화벽 규칙
• 저장 장치 마운트
• 로그 전송 설정
• 응용 프로그램 배포
• 예약 작업과 시스템 제한

구성 관리 서버가 중앙에서 각 시스템에 명령을 전달할 수도 있고, 각 노드의 에이전트가 중앙 정책을 주기적으로 받아 적용할 수도 있다. 에이전트를 설치하지 않고 SSH와 기존 시스템 도구를 이용하는 방식도 사용된다.

자동화 정의는 동일한 작업을 여러 번 실행해도 결과가 불필요하게 달라지지 않도록 작성하는 것이 일반적이다. 이를 통해 신규 서버를 기존 서버와 같은 상태로 만들고, 잘못 변경된 설정을 감지하거나 원래 상태로 되돌릴 수 있다.

계정과 접근 관리

Linux는 root 계정과 일반 사용자, 그룹과 파일 권한을 이용한 전통적인 UNIX 접근 제어 모델을 제공한다. 산업 환경에서는 이를 중앙 인증과 역할 기반 관리, 감사 체계와 결합한다.

관리자는 일상 작업을 root 계정으로 직접 수행하기보다 개인별 계정으로 로그인한 뒤 sudo와 같은 도구를 통해 승인된 관리 명령만 높은 권한으로 실행하는 경우가 많다. 이 방식은 작업을 수행한 사람과 시간을 기록하고 사용자별 권한을 구분하기 쉽다.

대규모 조직에서는 계정 정보를 각 서버에 따로 만들지 않고 LDAP, Kerberos, Active Directory와 같은 중앙 디렉터리 및 인증 시스템과 연동한다. 사용자가 조직을 떠나거나 역할이 바뀌면 중앙 계정과 권한을 변경하여 여러 Linux 시스템에 반영할 수 있다.

산업 환경의 접근 관리에는 다음 요소가 사용될 수 있다.

• 개인별 관리자 계정
• SSH 공개 키 또는 인증서
• 다중 인증
• sudo 정책
• 중앙 사용자 디렉터리
• 짧은 수명의 접근 자격 증명
• 특권 접근 관리 시스템
• 명령과 세션 기록
• 서비스 계정과 사람 계정의 분리

서비스도 가능하면 root 권한 전체를 사용하지 않고 별도의 사용자로 실행한다. Linux capabilities와 접근 통제 정책을 이용해 필요한 권한만 부여할 수도 있다.

패치와 취약점 관리

상업 환경에서 업데이트는 새 기능을 얻기 위한 작업뿐 아니라 취약점과 오류를 통제하는 운영 절차다. 조직은 사용 중인 운영체제와 패키지 목록을 파악하고, 공개된 취약점이 자사 시스템에 영향을 주는지 평가한 뒤 수정 패키지를 배포한다.

보안 업데이트는 일반적으로 다음 과정을 거친다.

1. 취약점과 공급업체 권고를 수집한다.
2. 영향을 받는 배포판과 패키지 버전을 식별한다.
3. 위험도와 외부 노출 여부를 평가한다.
4. 시험 환경에 업데이트를 적용한다.
5. 응용 프로그램과 시스템 기능을 검증한다.
6. 유지보수 창에 운영 환경으로 배포한다.
7. 실패한 시스템과 재부팅 필요 여부를 확인한다.
8. 적용 결과를 감사 기록으로 남긴다.

모든 서버를 동시에 업데이트하면 공통 오류가 전체 서비스에 영향을 줄 수 있다. 이에 따라 일부 시험 서버와 비핵심 시스템에 먼저 적용한 뒤 범위를 점진적으로 확대하는 방식이 사용된다. 장애가 발견되면 패키지를 되돌리거나 이전 시스템 이미지로 복구할 수 있도록 준비한다.

커널과 핵심 라이브러리 업데이트는 재부팅이나 프로세스 재시작을 요구할 수 있다. 중단 시간을 줄이기 위해 트래픽을 다른 노드로 이동한 뒤 한 대씩 재부팅하는 순차 작업이 사용된다.

일부 배포판은 제한된 범위의 커널 취약점을 실행 중인 시스템에 적용하는 라이브 패치 기능을 제공한다. Ubuntu의 Livepatch는 중요한 커널 취약점에 대한 수정을 실행 중인 커널에 적용하여 즉각적인 재부팅 필요성을 줄이도록 설계되었다.^[39] 라이브 패치는 모든 커널 변경을 대체하지 않으므로 정기적인 전체 업데이트와 재부팅 계획은 별도로 유지된다.

수명 주기 관리

기업용 시스템은 설치 당시의 안정성뿐 아니라 언제까지 보안 수정과 기술 지원을 받을 수 있는지가 중요하다. 조직은 배포판의 수명 주기를 기준으로 도입, 유지, 업그레이드와 폐기 시점을 계획한다.

일반적인 수명 주기 관리는 다음 단계로 이루어진다.

• 도입할 배포판과 버전 평가
• 응용 프로그램 및 하드웨어 인증
• 표준 이미지와 운영 절차 개발
• 운영 배포
• 정기 패치와 소규모 업데이트
• 다음 주요 버전 시험
• 단계적 마이그레이션
• 기존 버전 폐기와 데이터 정리

오래된 시스템은 응용 프로그램 호환성과 규제 때문에 즉시 업그레이드하기 어려울 수 있다. 기업용 배포판은 이러한 환경을 위해 제한된 보안 수정과 기술 지원을 추가로 제공하는 연장 지원 상품을 운영하기도 한다.

그러나 연장 지원은 버전 이전을 영구적으로 대신하는 수단이라기보다 마이그레이션 시간을 확보하기 위한 수단으로 사용된다. 새로운 하드웨어와 응용 프로그램은 오래된 배포판을 지원하지 않을 수 있고, 새 보안 기능과 개발 도구도 최신 버전에 집중되기 때문이다.

운영 조직은 서비스마다 사용 중인 배포판과 버전, 지원 종료일, 담당 조직과 이전 계획을 자산 정보로 관리한다. 지원 종료 직전에 모든 시스템을 한꺼번에 교체하지 않도록 여러 해에 걸쳐 버전 전환을 분산하기도 한다.

감시와 관측 가능성

Linux 시스템의 운영 상태는 로그, 지표와 실행 추적 정보를 통해 관찰된다. 개별 서버의 화면을 직접 확인하는 대신 여러 시스템의 정보를 중앙 수집 시스템으로 전송하고, 이상 상태가 감지되면 경고를 발생시킨다.

주요 감시 대상에는 다음과 같은 것이 있다.

• CPU 사용률과 부하
• 메모리와 스왑 사용량
• 디스크 용량과 입출력 지연
• 네트워크 오류와 처리량
• 프로세스와 서비스 상태
• 시스템 및 응용 프로그램 로그
• 파일 시스템과 저장 장치 오류
• 인증 실패와 보안 사건
• 응용 프로그램 응답 시간
• 사용자 요청의 성공률

Linux는 /proc, /sys, 시스템 로그, 성능 카운터와 여러 커널 인터페이스를 통해 운영 정보를 제공한다. 수집 에이전트는 이 정보를 중앙 시계열 데이터베이스나 로그 시스템으로 전송할 수 있다.

감시는 시스템 자원만 확인하는 것으로 끝나지 않는다. 서버가 실행 중이어도 실제 고객 요청이 실패할 수 있으므로, 응용 프로그램 수준의 성공률과 지연 시간, 처리량을 함께 측정한다.

경고는 단순한 임계값뿐 아니라 일정 시간 동안 지속된 이상, 여러 신호의 조합과 서비스 수준 목표를 기준으로 발생할 수 있다. 지나치게 많은 경고는 운영자가 중요한 문제를 놓치게 하므로, 실제 조치가 필요한 조건을 중심으로 경고 정책을 조정한다.

로그와 감사

Linux 시스템과 응용 프로그램은 부팅, 서비스 시작과 종료, 인증, 오류와 보안 사건을 로그로 기록한다. systemd를 사용하는 환경에서는 journald가 시스템 로그를 수집할 수 있으며, rsyslog와 syslog-ng 같은 구현도 사용된다.

산업 환경에서는 로그를 각 서버에만 저장하지 않고 중앙 로그 시스템으로 전송하는 경우가 많다. 중앙화된 로그는 서버가 손상되거나 삭제되더라도 기록을 보존하고, 여러 시스템에서 발생한 사건을 시간 순서로 연결하여 분석할 수 있게 한다.

감사 기록은 다음과 같은 정보를 대상으로 할 수 있다.

• 관리자 로그인과 권한 상승
• 사용자 및 그룹 변경
• 중요 설정 파일 수정
• 패키지 설치와 제거
• 서비스 시작과 중지
• 보안 정책 변경
• 중요 파일 접근
• 네트워크 및 인증 사건

보안과 규제 요구가 있는 조직은 로그의 보존 기간, 접근 권한, 암호화와 위변조 방지 방식을 별도로 정한다. 모든 명령을 무제한 기록하기보다 보호할 자산과 조사에 필요한 사건을 기준으로 감사 범위를 설계한다.

고가용성과 장애 대응

상업 서비스에서는 한 대의 Linux 서버가 중단되더라도 전체 서비스가 계속 제공되도록 여러 시스템을 함께 구성한다. 고가용성은 운영체제 자체의 단일 기능이 아니라 응용 프로그램, 네트워크, 저장 장치와 운영 절차를 결합하여 구현한다.

일반적으로 다음 방식이 사용된다.

• 여러 서버 사이의 부하 분산
• 활성·대기 또는 다중 활성 구성
• 데이터 복제
• 장애 감지와 자동 전환
• 가상 머신 및 컨테이너 재시작
• 서로 다른 데이터 센터 또는 가용 영역 배치
• 서비스 상태 검사
• 예비 용량 확보

클러스터 관리 소프트웨어는 노드와 서비스의 상태를 확인하고 장애가 발생한 자원을 다른 노드에서 시작할 수 있다. 데이터베이스와 저장 시스템은 자체 복제 및 합의 기능을 제공하기도 한다.

자동 복구가 항상 안전한 것은 아니다. 네트워크 단절로 두 노드가 동시에 자신을 정상 노드로 판단하면 같은 데이터에 충돌하는 쓰기를 수행할 수 있다. 이를 막기 위해 정족수, fencing과 저장 장치 접근 차단 같은 기능이 사용된다.

장애 대응 절차에는 기술적인 복구뿐 아니라 담당자 호출, 사용자 공지, 원인 분석과 후속 조치가 포함된다. 복구가 끝난 뒤에는 장애의 직접 원인과 이를 확대시킨 조건을 분석하고 감시, 자동화와 시스템 구조를 개선한다.

백업과 재해 복구

고가용성은 서비스 중단을 줄이지만 데이터 삭제와 손상, 잘못된 배포와 보안 침해를 해결하는 백업을 대신하지 않는다. 복제된 시스템은 잘못된 데이터도 여러 노드에 빠르게 복제할 수 있기 때문이다.

Linux 환경의 백업 대상에는 다음이 포함될 수 있다.

• 데이터베이스와 사용자 데이터
• 응용 프로그램 설정
• 암호화 키와 인증서
• 배포 및 자동화 정의
• 시스템 이미지
• 감사와 운영 기록

백업 정책은 어느 시점까지 데이터를 복구해야 하는지를 나타내는 복구 시점 목표와, 장애 후 얼마 안에 서비스를 되살려야 하는지를 나타내는 복구 시간 목표에 따라 설계된다.

백업은 원본 시스템과 다른 저장 장치나 지역에 보관하고, 일부 복사본을 운영 계정으로부터 격리할 수 있다. 백업 파일이 존재하는지만 확인하지 않고 실제 복원 시험을 정기적으로 수행해야 복구 절차와 데이터의 유효성을 확인할 수 있다.

재해 복구 계획은 데이터 센터 전체의 장애, 클라우드 지역 중단, 랜섬웨어와 운영자 실수 등을 가정할 수 있다. 조직은 대체 환경에서 Linux 시스템과 응용 프로그램을 다시 생성하고 데이터와 네트워크 구성을 복원하는 절차를 문서화하고 시험한다.

보안 강화와 규정 준수

산업 환경에서 Linux의 기본 설치 상태는 조직의 보안 요구를 모두 충족하지 않을 수 있다. 운영 조직은 필요한 서비스만 활성화하고, 파일과 계정 권한, 네트워크와 커널 설정을 기준에 맞게 조정한다.

보안 강화에는 다음 작업이 포함될 수 있다.

• 사용하지 않는 패키지와 서비스 제거
• 원격 root 로그인 제한
• 강한 인증과 다중 인증 적용
• 방화벽과 네트워크 접근 제한
• SELinux 또는 AppArmor 정책 적용
• 감사 기능 활성화
• 암호화와 키 관리
• 커널 및 시스템 보안 매개변수 조정
• 변경 및 취약점 검사
• 부팅과 소프트웨어 무결성 검증

금융, 의료, 공공과 국방 분야에서는 조직별 정책 외에도 법률과 산업 표준, 정부 보안 기준을 충족해야 할 수 있다. 기업용 Linux 제품과 관리 서비스는 CIS 기준, FIPS 검증 암호 모듈과 DISA STIG 같은 보안 기준을 지원 대상으로 제공하기도 한다. Ubuntu Pro는 장기 보안 유지와 함께 FIPS, CIS 및 DISA STIG 관련 기능을 기업 서비스로 제공한다.^[40]

준수 여부는 설정을 한 번 적용하는 것으로 끝나지 않는다. 운영 중 변경과 새 취약점으로 상태가 달라질 수 있으므로 시스템을 주기적으로 검사하고 기준에서 벗어난 항목을 보고하거나 자동 수정한다.

가상화와 클라우드 운영

상업 환경의 Linux는 물리 서버에 직접 설치되기도 하지만, 가상 머신과 퍼블릭 클라우드 인스턴스, 컨테이너 호스트로 실행되는 경우가 많다.

가상화 환경에서는 운영체제 설치보다 템플릿 또는 이미지 복제를 통해 시스템을 생성한다. 서버는 장기간 수동 관리되는 고유한 장비가 아니라 필요할 때 자동으로 생성되고 제거되는 자원으로 다뤄질 수 있다.

클라우드 운영에서는 다음 요소가 Linux 관리와 결합한다.

• 이미지와 인스턴스 유형
• 가상 네트워크와 방화벽 정책
• 블록 및 객체 저장소
• 자동 확장
• 부하 분산
• 역할 기반 클라우드 권한
• 메타데이터와 임시 자격 증명
• 인프라스트럭처 애즈 코드
• 사용량과 비용 관리

클라우드 사업자는 배포판 업체와 협력하여 지원 계약이 포함된 Linux 이미지를 제공할 수 있다. 사용자는 구독 비용을 클라우드 사용료와 함께 지불하거나 기존 기업 계약을 클라우드 인스턴스에 연결할 수 있다.

클라우드가 관리 책임을 모두 없애는 것은 아니다. 사업자가 물리 하드웨어와 일부 기반 서비스를 관리하더라도, 사용자는 가상 머신 안의 패키지와 계정, 응용 프로그램, 데이터와 접근 정책을 계속 관리해야 한다.

컨테이너 호스트

Linux는 네임스페이스와 cgroups를 기반으로 컨테이너 실행 환경을 제공한다. 산업 환경에서는 호스트 운영체제를 비교적 작고 일관되게 유지하고 응용 프로그램과 의존 라이브러리를 컨테이너 이미지로 배포할 수 있다.

컨테이너 운영에서도 Linux 호스트의 관리는 필요하다. 호스트 커널은 모든 컨테이너가 공유하므로 커널 취약점과 자원 고갈, 장치 접근과 격리 설정이 전체 노드에 영향을 줄 수 있다.

컨테이너 호스트 운영은 다음 요소를 포함한다.

• 호스트 커널과 런타임 업데이트
• 컨테이너 이미지 출처와 서명 검증
• 이미지 취약점 검사
• CPU와 메모리 제한
• 네트워크 정책
• 비밀 정보와 인증서 관리
• 로그와 지표 수집
• 노드 교체와 배출
• 저장 장치와 영구 데이터 관리

Kubernetes 같은 오케스트레이션 시스템은 컨테이너의 배치와 재시작, 서비스 검색과 확장을 자동화한다. 이 경우 관리자는 각 컨테이너에 직접 접속하기보다 선언된 배포 상태와 클러스터 전체의 정책을 관리한다.

변경 관리와 배포

운영 Linux 시스템의 변경은 장애와 보안 사고의 주요 원인이 될 수 있다. 기업은 패키지, 설정과 응용 프로그램 변경을 요청·검토·시험·배포·복구할 수 있는 절차로 관리한다.

변경은 보통 개발, 시험, 준비와 운영 환경을 차례로 거친다. 동일한 자동화 코드와 패키지 또는 이미지를 환경별 설정만 달리하여 배포함으로써 시험한 결과와 운영 결과의 차이를 줄인다.

배포 방식에는 다음과 같은 선택이 있다.

• 모든 노드의 순차 업데이트
• 일부 노드에 먼저 적용하는 카나리 배포
• 기존 환경과 새 환경을 병렬 운영하는 블루·그린 배포
• 시스템 이미지 전체 교체
• 컨테이너 이미지 롤링 업데이트
• 기능 플래그를 이용한 단계적 활성화

변경 전에는 복구 방법과 서비스 영향, 감시 기준을 정한다. 배포 후 오류율이나 지연 시간이 기준을 넘으면 자동 또는 수동으로 이전 버전으로 되돌릴 수 있다.

운영체제 자체도 변경 불가능한 이미지처럼 관리할 수 있다. 새 패키지를 실행 중인 서버에 계속 추가하기보다 새로운 이미지로 서버를 교체하면 노드 간 구성 편차를 줄일 수 있다.

기술 지원과 책임 분담

Linux는 여러 프로젝트와 기업이 함께 구성하므로 장애가 발생했을 때 어느 구성 요소가 원인인지 즉시 드러나지 않을 수 있다. 커널, 하드웨어, 가상화 계층, 라이브러리, 데이터베이스와 응용 프로그램 가운데 어느 부분이 문제인지 분석해야 한다.

기업 지원 계약은 이러한 문제를 접수하고 재현하며 관련 프로젝트 또는 하드웨어 업체와 협력하는 단일 창구를 제공할 수 있다. 공급업체는 지원 대상 패키지와 구성, 하드웨어 인증 범위를 정하고 그 범위 안에서 오류 수정과 우회 방법을 제공한다.

조직 내부에서도 책임을 다음과 같이 나눌 수 있다.

• 플랫폼 팀은 Linux 이미지와 공통 서비스를 관리한다.
• 네트워크 및 저장 팀은 기반 인프라를 관리한다.
• 보안 팀은 접근, 취약점과 준수 정책을 관리한다.
• 응용 프로그램 팀은 서비스 코드와 데이터의 운영을 담당한다.
• 사이트 신뢰성 엔지니어링 조직은 자동화, 관측과 장애 대응을 담당한다.
• 오픈 소스 프로그램 조직은 사용 라이선스와 외부 기여 정책을 관리한다.

역할을 엄격하게 분리하는 방식 외에 하나의 제품 팀이 개발과 운영을 함께 담당하고 공통 플랫폼 팀이 기반 기능을 제공하는 구조도 사용된다.

오픈 소스 프로젝트에 대한 기여

기업은 Linux와 관련 오픈 소스 소프트웨어를 단순히 소비하는 데 그치지 않고 개발자를 고용해 기능과 수정 사항을 상위 프로젝트에 제출하기도 한다.

기업이 자체 수정 사항을 내부에만 유지하면 새 커널이나 배포판 버전이 나올 때마다 변경 사항을 다시 적용해야 한다. 수정이 공식 프로젝트에 포함되면 다른 개발자의 검토와 시험을 받을 수 있고, 장기적인 유지 부담을 공동체와 나눌 수 있다.

기여 대상에는 다음과 같은 것이 포함된다.

• 새로운 하드웨어 드라이버
• 서버와 네트워크 성능 개선
• 파일 시스템과 저장 기능
• 가상화 및 컨테이너 기능
• 보안 수정
• 오류 보고와 시험
• 문서와 개발 인프라
• 장기 유지관리 인력과 재정 지원

Linux Foundation은 기업과 개발자가 공동으로 오픈 소스 프로젝트를 운영할 수 있는 중립적인 협업 기반을 제공하며, 기업이 의존하는 오픈 소스 프로젝트에 참여하고 관리하기 위한 전략과 조직 구조를 안내한다.^[41]

기업의 기여는 자선 활동에만 해당하지 않는다. 자사 제품에 필요한 기능을 공식 코드에 포함하고, 공동 유지보수를 통해 개발 비용을 분담하며, 프로젝트의 기술 방향과 품질에 참여하는 사업적 활동이기도 하다.

관리 도구와 중앙 통제

규모가 큰 조직은 개별 Linux 서버를 각각 관리하기보다 중앙 플랫폼에서 자산과 패치, 정책과 상태를 관리한다.

중앙 관리 시스템은 다음 기능을 제공할 수 있다.

• 등록된 시스템과 버전 목록
• 패키지와 취약점 현황
• 업데이트 일괄 배포
• 설정 및 준수 검사
• 원격 작업 실행
• 저장소와 콘텐츠 복제
• 구독 및 지원 상태
• 보고서와 감사 기록
• 인터넷이 차단된 환경의 오프라인 관리

Canonical의 Landscape는 Ubuntu 시스템 집합을 대상으로 보안 패치, 감사, 접근과 준수 작업을 자동화하며, 네트워크가 분리된 환경에서도 운영할 수 있도록 제공된다.^[42] Red Hat과 SUSE도 자사 기업용 배포판을 위한 시스템 관리 및 콘텐츠 관리 제품을 제공한다.

중앙 도구가 모든 환경을 완전히 통합하지는 않는다. 여러 배포판과 클라우드, 네트워크 장비를 함께 운영하는 조직은 배포판별 관리 도구와 범용 자동화·감시 시스템을 조합할 수 있다.

산업 환경에서의 Linux 운영

Linux가 산업 환경에서 채택되는 이유는 라이선스 비용만으로 설명되지 않는다. Linux는 여러 하드웨어와 가상화·클라우드 환경에서 사용할 수 있고, 소스 코드와 공개 인터페이스를 바탕으로 자동화와 제품 요구에 맞게 수정할 수 있다.

기업은 커널과 공통 사용자 공간을 직접 처음부터 개발하는 대신 여러 조직이 공동으로 유지하는 기반을 사용한다. 그 위에서 데이터베이스, 미들웨어, 클라우드 서비스, 네트워크 장비, 산업용 제품과 기술 지원을 제공한다.

상업적 Linux 운영은 자유롭게 수정할 수 있다는 특성과 통제된 운영 절차를 결합한다. 시스템의 소스와 구성 요소는 공개되어 있을 수 있지만 실제 운영 환경은 승인된 버전, 검증된 패키지, 자동화된 변경과 책임 있는 지원 체계 아래 관리된다.

이에 따라 산업 환경의 Linux는 단순히 무료로 설치하는 운영체제가 아니라, 장기간 유지되는 플랫폼과 공급망, 운영 도구, 기술 인력과 공동 개발 생태계를 포함하는 기반 시스템으로 사용된다.

Linux의 보안은 커널이 제공하는 프로세스 격리와 접근 제어 기능, 배포판의 패키지 관리와 보안 업데이트, 응용 프로그램의 구성, 운영 조직의 관리 절차가 결합되어 형성된다. Linux 커널의 소스 코드가 공개되어 있다는 사실만으로 시스템이 자동으로 안전해지거나 취약해지는 것은 아니다. 공개된 코드는 여러 개발자와 보안 연구자가 검토하고 시험할 수 있게 하지만, 방대한 코드 규모와 다양한 하드웨어 지원, 높은 권한으로 실행되는 커널의 특성 때문에 지속적으로 오류와 취약점이 발견된다.

Linux 기반 시스템의 보안 범위에는 Linux 커널뿐 아니라 부트로더, 시스템 라이브러리, 셸, 네트워크 서비스, 패키지 저장소와 설치되는 응용 프로그램이 포함된다. 따라서 흔히 “Linux 취약점”이라고 불리는 사건도 실제로는 커널 자체의 오류, 사용자 공간 프로그램의 취약점, 배포판 설정 문제 또는 소프트웨어 공급망 공격 가운데 하나일 수 있다.

기본 보안 모델

Linux는 UNIX에서 발전한 사용자와 그룹, 프로세스와 파일 소유권 모델을 사용한다. 각 프로세스는 사용자 식별자와 그룹 식별자, 여러 보안 자격 정보를 가지며, 커널은 파일과 장치, 프로세스와 네트워크 기능에 접근할 때 이를 검사한다.

전통적으로 모든 관리 권한을 가진 사용자는 root로 표현된다. 일반 사용자는 제한된 권한으로 프로그램을 실행하고, 필요한 관리 작업만 sudo와 같은 도구를 통해 높은 권한으로 수행할 수 있다.

파일에는 소유자와 그룹, 그 밖의 사용자에 대한 읽기·쓰기·실행 권한이 설정된다. 접근 제어 목록을 사용하면 특정 사용자와 그룹에 더 세밀한 권한을 부여할 수 있다. 이 모델은 기본적인 격리를 제공하지만, root 권한을 획득한 공격자나 권한 검사의 오류를 막기에는 충분하지 않을 수 있다.

Linux는 root의 권한을 여러 단위로 나누는 capabilities를 제공한다. 프로그램은 전체 관리자 권한을 갖지 않고도 네트워크 설정, 사용자 식별자 변경 또는 특정 시스템 작업에 필요한 권한만 받을 수 있다. 다만 CAP_SYS_ADMIN처럼 매우 넓은 범위의 권한은 사실상 여러 관리자 기능을 포함하므로 최소한으로 부여해야 한다.

강제적 접근 통제

Linux는 전통적인 파일 권한 외에 LSM 구조를 제공한다. LSM은 파일과 프로세스, 소켓과 자격 정보에 대한 주요 보안 검사를 커널 내부에 연결할 수 있도록 하는 공통 구조다.^[43]

LSM을 사용하는 대표적인 보안 체계에는 다음과 같은 것들이 있다.

• SELinux
• AppArmor
• Smack
• TOMOYO
• Landlock
• Integrity Policy Enforcement

SELinux는 사용자와 프로세스, 파일 등의 보안 레이블을 바탕으로 세밀한 강제적 접근 통제 정책을 적용한다. AppArmor는 프로그램별 프로필을 이용해 접근할 수 있는 파일과 기능을 제한한다. 이러한 정책은 응용 프로그램이 공격당하더라도 시스템 전체에 접근할 수 있는 범위를 줄이는 데 사용된다.

Landlock은 일반 사용자 프로세스가 스스로 파일 시스템 접근 범위를 제한할 수 있게 한다. 응용 프로그램은 높은 관리자 권한 없이도 자신과 자식 프로세스가 접근할 수 있는 파일 영역을 축소할 수 있다.^[44]

강제적 접근 통제는 프로그램의 취약점을 제거하지는 않는다. 대신 취약점이 악용되었을 때 공격자가 읽거나 변경할 수 있는 데이터와 실행할 수 있는 작업을 제한해 피해 범위를 줄인다.

프로세스 격리와 공격 표면 축소

Linux는 프로그램이 사용할 수 있는 커널 기능과 시스템 자원의 범위를 줄이기 위한 여러 기능을 제공한다.

seccomp는 프로세스가 호출할 수 있는 시스템 호출을 제한한다. 웹 브라우저의 샌드박스, 컨테이너 런타임과 네트워크 서비스는 정상 동작에 필요하지 않은 시스템 호출을 차단하여 커널 공격 표면을 줄일 수 있다.

네임스페이스는 프로세스 식별자, 마운트 지점, 네트워크 인터페이스, 사용자와 호스트 이름처럼 프로세스가 보는 시스템 자원을 분리한다. cgroups는 프로세스가 사용할 수 있는 CPU와 메모리, 입출력 자원을 제한한다. 두 기능은 컨테이너 격리의 기반이지만, 같은 호스트의 컨테이너가 하나의 Linux 커널을 공유하므로 커널 취약점이 존재하면 격리 경계를 넘어설 가능성이 있다.

Linux 커널의 자체 보호 문서는 seccomp를 사용해 프로세스가 접근할 수 있는 커널 진입점을 줄이고, 커널 모듈 적재 제한이나 서명된 모듈을 사용해 높은 권한을 획득한 공격자가 커널 코드를 추가하기 어렵게 만드는 방식을 설명한다.^[45]

서비스는 가능한 한 별도 사용자로 실행하고, 읽기 전용 파일 시스템과 제한된 디렉터리, capabilities와 시스템 호출 필터를 조합할 수 있다. systemd와 컨테이너 런타임은 이러한 커널 기능을 서비스별 격리 설정으로 제공하기도 한다.

커널 취약점의 특성

Linux 커널은 높은 권한으로 실행되고 모든 프로세스와 장치의 요청을 처리하기 때문에, 커널 취약점은 일반 응용 프로그램의 오류보다 큰 영향을 줄 수 있다. 공격자가 취약점을 악용하면 일반 사용자 권한에서 root 권한으로 상승하거나, 컨테이너와 가상화 경계를 벗어나거나, 시스템을 중단시키고 정보를 노출할 수 있다.

취약점은 다음과 같은 영역에서 발생할 수 있다.

• 메모리 해제 후 사용과 이중 해제
• 버퍼 범위 초과 접근
• 정수 오버플로와 잘못된 길이 검사
• 경쟁 상태
• 참조 횟수와 객체 수명 관리 오류
• 사용자 공간 포인터 검사 오류
• 파일과 디렉터리 권한 검사 누락
• 네트워크 패킷 및 파일 시스템 입력 검증 오류
• 장치 드라이버와 ioctl 처리 오류
• eBPF 검증기의 상태 추적 오류
• CPU 추측 실행과 캐시를 이용한 정보 노출

Linux 커널의 많은 부분은 C로 작성되어 있다. C는 하드웨어와 메모리를 직접 제어하기에 적합하지만, 배열 범위와 객체 수명을 자동으로 검사하지 않으므로 메모리 안전성 오류가 발생할 수 있다.

커널 개발자들은 일부 하위 시스템에서 Rust를 사용할 수 있도록 기반을 추가했다. Rust 사용이 기존 C 코드를 즉시 대체하는 것은 아니지만, 새 코드에서 해제 후 사용과 잘못된 포인터 접근 같은 일부 메모리 안전성 오류를 컴파일 단계에서 줄이려는 방향 가운데 하나다.

Dirty COW

2016년에 공개된 Dirty COW는 Linux 커널의 copy-on-write 처리 과정에 존재한 경쟁 상태 취약점이다. 읽기 전용으로 매핑된 파일에 대해 두 작업이 동시에 일어나는 과정에서 권한 검사를 우회해 파일 내용을 변경할 수 있었다.

공격자는 이 취약점을 이용해 자신에게 쓰기 권한이 없는 실행 파일이나 시스템 파일을 수정하고, 로컬 사용자 권한에서 root 권한으로 상승할 수 있었다. 취약점에는 CVE-2016-5195가 부여되었다.^[46]

Dirty COW는 오랫동안 커널에 존재했지만 실제 악용 가능성이 확인된 뒤 주요 배포판과 장치 제조사가 수정된 커널을 배포했다. 이 사건은 취약점 수정이 상위 Linux 커널에 포함되는 것만으로 모든 사용자가 즉시 보호되는 것은 아니라는 점을 보여주었다. 배포판과 서버 관리자는 수정된 패키지를 제공하고 설치해야 하며, Android와 임베디드 장치 제조사도 각 제품의 커널에 수정 사항을 적용해야 했다.

Dirty Pipe

2022년에 공개된 Dirty Pipe는 Linux 커널 파이프 구현의 초기화되지 않은 플래그로 인해 페이지 캐시에 있는 파일 데이터를 덮어쓸 수 있었던 취약점이다. 읽기 권한은 있지만 쓰기 권한이 없는 파일에도 영향을 줄 수 있었으며, 조건이 맞으면 시스템 파일을 변경해 권한을 상승시킬 수 있었다.

이 취약점은 Linux 5.8 이후 일부 버전에 영향을 주었으며 CVE-2022-0847이 부여되었다.^[47]

Dirty Pipe는 문제를 일으킨 코드의 플래그를 올바르게 초기화하도록 수정되었고, 수정 사항이 지원되는 안정 커널과 배포판 패키지에 반영되었다. 관리자는 배포판이 제공하는 수정된 커널로 업데이트하고 시스템을 재부팅해야 했다.

Dirty COW와 Dirty Pipe는 서로 다른 구현 오류였지만, 일반 사용자가 커널의 파일 및 메모리 관리 오류를 이용해 높은 권한을 얻을 수 있다는 공통점이 있었다. 이후에도 특정 취약점 하나에 대한 수정뿐 아니라 메모리 초기화 강화, 객체 수명 검사와 테스트 확대 같은 일반적인 방어가 계속 추가되었다.

하드웨어 취약점

Linux는 커널 코드의 오류뿐 아니라 프로세서 자체의 보안 취약점에도 대응해야 한다. Spectre와 Meltdown을 비롯한 추측 실행 취약점은 CPU의 실행 최적화와 캐시 동작을 이용해 다른 프로세스나 커널의 정보를 추론할 수 있게 했다.

이러한 문제는 Linux만의 취약점이 아니지만, 커널은 사용자 공간과 커널 주소 공간의 분리, 분기 예측 제어, 캐시와 실행 상태 정리 같은 완화책을 구현해야 했다. 일부 완화책은 프로세서 종류와 시스템 사용 목적에 따라 성능에 영향을 줄 수 있다.

Linux 커널은 알려진 CPU 취약점별 영향 범위와 완화 기능, 부팅 및 실행 중 설정 방법을 별도의 문서로 관리한다.^[48]

배포판은 커널 업데이트와 함께 CPU 마이크로코드 업데이트를 제공할 수 있다. 운영자는 커널 로그와 /sys 인터페이스, 배포판의 검사 도구를 이용해 시스템에 적용된 완화 상태를 확인한다.

커널 자체 보호

Linux의 보안 개선은 발견된 취약점을 하나씩 수정하는 것에 그치지 않는다. 커널 개발에서는 취약점이 발생하기 어렵게 만들거나, 오류가 존재하더라도 공격자가 이를 실제 권한 상승으로 연결하기 어렵게 만드는 방어 기능을 추가한다.

대표적인 방어 방식에는 다음이 포함된다.

• 실행할 필요가 없는 메모리를 실행 불가능하게 설정
• 쓰기 가능한 커널 메모리와 실행 가능한 커널 메모리 분리
• 커널 코드와 데이터의 주소 무작위화
• 스택 보호와 제어 흐름 보호
• 사용자 공간 메모리 접근 제한
• 객체와 힙 메모리 초기화
• 커널 스택과 민감 정보 정리
• 참조 횟수 오버플로 방지
• 읽기 전용 커널 데이터 보호
• 커널 모듈 서명과 적재 제한
• 커널 명령줄 및 디버깅 인터페이스 제한

커널 자체 보호의 목표는 개별 취약점의 완전한 방지를 보장하는 것이 아니라, 반복되는 오류 유형을 제거하고 공격에 필요한 조건을 늘리며 취약점 악용의 성공률을 낮추는 데 있다.^[49]

배포판은 이러한 기능 가운데 일부를 커널 빌드 설정과 기본 보안 정책으로 활성화한다. 성능과 호환성, 디버깅 가능성에 영향을 주는 기능도 있으므로 모든 배포판과 장치가 동일한 구성을 사용하지는 않는다.

코드 검토와 자동 검사

Linux 커널 변경은 하위 시스템 메일링 리스트와 유지관리자를 통해 공개적으로 검토된다. 제출된 패치는 기능의 정확성뿐 아니라 기존 인터페이스와의 호환성, 동시성, 메모리 관리와 보안 영향을 함께 검토받을 수 있다.

정적 분석 도구와 컴파일러 경고, KASAN, UBSAN, KMSAN, lockdep와 같은 실행 중 검사 기능도 개발과 시험에 사용된다. 이러한 기능은 잘못된 메모리 접근, 초기화되지 않은 값 사용, 정의되지 않은 동작과 잠금 오류를 발견하는 데 도움을 준다.

퍼징은 자동으로 많은 시스템 호출과 입력 조합을 생성해 커널을 비정상 상태로 만드는 오류를 찾는다. Google의 syzkaller와 syzbot은 발견한 충돌을 자동으로 재현하고 관련 개발자에게 보고하며, Linux 커널에서 여러 취약점과 일반 오류를 발견하는 데 사용되어 왔다.^[50]

퍼징과 자동 검사가 모든 논리 오류와 권한 문제를 찾을 수 있는 것은 아니다. 코드 검토와 수동 보안 연구, 실제 운영 환경의 오류 보고가 함께 사용된다.

취약점 보고와 수정

Linux 커널에는 공개 전에 보안 문제를 검토하고 수정할 수 있는 보안 연락 체계가 있다. 즉각적인 위험을 가진 취약점은 비공개 보안 목록으로 보고할 수 있으며, 보안 담당자와 해당 하위 시스템 유지관리자가 문제를 확인하고 수정 사항을 준비한다.^[51]

수정된 코드는 상위 커널에 반영되고, 적용 조건을 충족하면 지원되는 안정 커널 계열에도 역이식된다. 배포판은 이를 자사가 제공하는 커널에 적용하고 보안 권고와 업데이트 패키지를 공개한다.

Linux 커널 프로젝트는 지원되는 커널의 수정 커밋을 분석해 CVE를 배정하는 자체 CVE 번호 기관으로 운영된다. 커널 취약점의 CVE 정보와 수정 커밋은 공개 목록을 통해 발표된다.^[52]

커널 개발에서는 보안 오류를 일반 오류와 완전히 분리하기 어려운 경우가 많다. 단순한 충돌이나 경계 검사 오류도 공격자가 통제할 수 있는 입력 경로에 존재하면 보안 취약점이 될 수 있다. 따라서 운영 환경에서는 CVE로 명시된 패치만 선택적으로 설치하기보다 배포판이 제공하는 안정 커널 업데이트를 지속적으로 적용하는 방식이 권장된다.

배포판의 보안 업데이트

Linux 커널의 수정이 공개되어도 실제 시스템이 자동으로 보호되는 것은 아니다. 배포판은 수정 사항을 자사의 커널과 패키지 버전에 적용하고, 빌드와 시험을 거쳐 저장소에 배포한다.

배포판의 보안 팀은 다음과 같은 작업을 수행한다.

• 영향을 받는 버전과 기본 설정 확인
• 상위 프로젝트의 수정 사항 검토
• 기존 제품 버전으로 수정 역이식
• 업데이트 패키지 빌드와 시험
• 보안 권고와 영향도 발표
• 취약한 패키지 철회
• 장기 지원 버전 유지
• 고객과 하위 배포판에 정보 전달

기업용 배포판은 응용 프로그램 호환성을 유지하기 위해 프로그램의 전체 버전을 올리는 대신 필요한 보안 수정만 기존 버전에 적용하기도 한다. 이 때문에 패키지 버전 문자열이 상위 프로젝트의 취약 버전과 비슷해 보여도 배포판 패치가 이미 적용되어 있을 수 있다.

커널 업데이트를 완전히 적용하려면 일반적으로 재부팅하여 새 커널을 실행해야 한다. 일부 환경에서는 라이브 패치를 이용해 제한된 커널 수정 사항을 실행 중에 적용하지만, 모든 변경을 재부팅 없이 처리할 수 있는 것은 아니다.

소프트웨어 공급망

Linux 시스템은 커널과 배포판이 직접 작성한 코드만으로 구성되지 않는다. 수많은 독립 오픈 소스 프로젝트의 라이브러리와 빌드 도구, 압축 프로그램과 네트워크 서비스를 패키지로 포함한다.

공격자는 공개된 프로그램의 취약점을 찾는 대신 프로젝트 관리자 계정이나 빌드 시스템, 배포 파일과 패키지 저장소를 공격할 수 있다. 정상적인 개발자가 배포한 것처럼 보이는 파일에 악성 코드를 넣으면 여러 배포판과 제품으로 확산될 가능성이 있다.

이를 줄이기 위해 다음과 같은 방식이 사용된다.

• 소스 코드와 패키지의 디지털 서명
• 저장소 메타데이터 검증
• 여러 관리자의 코드 검토
• 빌드 환경 격리
• 재현 가능한 빌드
• 의존성 및 소프트웨어 자재 명세 관리
• 유지관리자 계정의 다중 인증
• 릴리스 파일과 소스 저장소의 비교
• 패키지 출처와 변경 이력 추적

공급망 보안은 개별 프로그램의 코드 안전성뿐 아니라 누가 소스를 변경하고 빌드하며 서명할 수 있는지를 관리하는 문제다.

XZ Utils 백도어 사건

2024년 3월 XZ Utils의 5.6.0과 5.6.1 릴리스에서 정교하게 숨겨진 악성 코드가 발견되었다. 이 사건에는 CVE-2024-3094가 부여되었다.

악성 구성 요소의 일부는 일반 소스 저장소에 그대로 나타나지 않고 배포용 tarball과 빌드 과정에 숨겨져 있었다. 특정 Linux 빌드 환경에서 liblzma에 악성 코드를 삽입하고, 일부 배포판에서 systemd를 통해 이 라이브러리와 연결된 OpenSSH 서버의 인증 처리에 영향을 주도록 설계되어 있었다.^[53]

PostgreSQL 개발자인 안드레스 프로인트는 Debian 시험 환경에서 SSH 접속 과정의 비정상적인 CPU 사용과 지연, 분석 도구의 오류를 조사하다가 문제를 발견했다. 그는 2024년 3월 29일 oss-security 메일링 리스트에 분석 결과를 공개했다.

XZ Utils는 Linux 커널 구성 요소가 아니며 여러 운영체제에서 사용할 수 있는 압축 도구와 라이브러리다. 따라서 이 사건을 Linux 커널에 백도어가 포함된 사건으로 보는 것은 정확하지 않다. 다만 공격 코드가 일부 Linux 배포판의 빌드 구성과 OpenSSH 실행 경로를 대상으로 했고, Linux 배포판의 핵심 라이브러리 공급망을 이용하려 했다는 점에서 Linux 생태계의 주요 보안 사건으로 평가된다.

영향을 받은 버전은 주로 Fedora Rawhide, Fedora Linux 40의 시험 단계와 Debian·openSUSE 등의 개발 또는 시험 저장소에 유입되었다. 널리 사용되는 안정 기업용 배포판에는 해당 버전이 일반 배포되기 전에 발견되었다. Red Hat과 여러 배포판은 영향을 받은 패키지를 철회하고 이전의 안전한 XZ 버전으로 되돌리도록 안내했다.^[54][55]

이 사건은 장기간에 걸쳐 프로젝트의 유지관리 신뢰를 얻은 인물이 릴리스와 빌드 체계에 악성 코드를 삽입한 공급망 공격이었다. 공개 소스 코드만 검토하는 것으로 충분하지 않으며, 실제 배포된 tarball과 빌드 결과, 유지관리자 권한과 프로젝트 운영 구조도 검증해야 한다는 점을 드러냈다.

XZ Utils 사건을 포함한 주요 침해 시도와 커널·배포판 취약점의 구체적인 경과는 Linux 보안 취약점 사건에서 다룬다.

보안과 공개 개발

Linux의 공개 개발 방식은 누구나 코드를 분석할 수 있으므로 취약점 발견과 수정에 유리할 수 있다. 보안 연구자와 기업, 대학과 배포판 개발자는 같은 코드를 분석하고 패치를 제안할 수 있으며, 수정 과정과 코드 변경 기록도 공개된다.

그러나 코드가 공개되어 있다는 사실이 모든 부분을 충분한 인원이 검토하고 있다는 뜻은 아니다. 일부 하위 시스템과 사용자 공간 프로젝트는 소수의 유지관리자에게 의존하며, 오래된 드라이버와 복잡한 경계 조건은 오랫동안 검토되지 않을 수 있다. 공격자 역시 공개된 소스를 분석해 취약점을 찾을 수 있다.

따라서 Linux 보안은 공개 여부 하나보다 다음 조건에 영향을 받는다.

• 프로젝트의 유지관리 인력
• 코드 검토와 시험의 범위
• 취약점 보고 체계
• 수정 사항의 안정 버전 반영 속도
• 배포판과 장치 제조사의 업데이트 제공
• 운영자의 패치 적용 속도
• 서비스와 계정의 실제 구성
• 소프트웨어 공급망의 신뢰성

소스가 공개된 Linux는 여러 조직이 취약점을 찾고 공동으로 수정할 수 있는 기반을 제공하지만, 실제 시스템의 안전성은 그 수정이 제품과 운영 환경에 전달되는 전체 과정에 달려 있다.

시스템 강화

Linux는 범용 운영체제이므로 기본 구성만으로 모든 위협 모델에 최적화되어 있지는 않다. 인터넷 서버, 데스크톱, 스마트폰, 컨테이너 호스트와 산업 제어 장치는 서로 다른 기능과 보안 정책을 요구한다.

실제 시스템에서는 사용 목적에 따라 다음과 같은 강화 작업이 적용된다.

• 필요하지 않은 서비스와 패키지 제거
• 원격 root 로그인 제한
• SSH 키와 다중 인증 사용
• 방화벽과 네트워크 접근 제한
• SELinux 또는 AppArmor 활성화
• 서비스별 사용자와 최소 권한 적용
• seccomp와 네임스페이스를 이용한 격리
• 커널 모듈 적재 제한
• Secure Boot와 서명된 커널·모듈 사용
• 파일 및 실행 코드의 무결성 검사
• 로그 중앙 수집과 감사
• 정기적인 패키지와 커널 업데이트
• 백업과 침해 대응 계획 수립

보안 기능을 활성화하는 것만으로 충분하지 않으며 정책이 실제 서비스의 동작과 맞게 설정되어야 한다. 지나치게 넓은 허용 규칙이나 사용되지 않는 강제적 접근 통제 정책은 형식적으로 활성화되어 있어도 실질적인 보호를 제공하지 못할 수 있다.

보안의 범위

Linux는 서버와 데스크톱, 스마트폰, 클라우드와 임베디드 시스템에 사용되므로 하나의 보안 수준으로 평가하기 어렵다. 최신 배포판을 정기적으로 업데이트하고 최소 권한과 격리 기능을 적용한 서버와, 지원이 종료된 커널을 수정 없이 사용하는 네트워크 장비는 같은 Linux 커널 계열을 사용하더라도 보안 상태가 크게 다르다.

Linux 커널의 보안은 다음 요소 가운데 하나이며 서로 분리될 수 없다.

• 하드웨어와 펌웨어
• 부팅 과정과 커널
• 사용자 공간 라이브러리와 서비스
• 배포판의 패키지 공급망
• 응용 프로그램
• 인증과 접근 제어
• 네트워크 구성
• 운영과 업데이트 정책
• 사용자와 관리자의 행동

따라서 Linux의 보안은 “취약점이 없는 운영체제”라는 특성보다, 취약점을 발견하고 공개하며 수정한 뒤 다양한 배포판과 장치에 전달하는 지속적인 과정으로 이해할 수 있다.

Linux는 물리 서버와 개인용 컴퓨터에서 직접 실행될 뿐 아니라, 가상 머신의 호스트와 게스트 운영체제, 컨테이너의 공통 커널과 클라우드 컴퓨팅 노드로 널리 사용된다. Linux가 제공하는 하드웨어 지원과 프로세스 관리, 네트워크, 네임스페이스와 자원 제어 기능은 현대 가상화와 컨테이너 환경의 주요 기반이 되었다.

가상화는 하나의 물리적 컴퓨터가 여러 개의 독립된 컴퓨터처럼 동작하도록 CPU와 메모리, 저장 장치와 주변 장치를 추상화하는 기술이다. 각 가상 머신은 일반적으로 자체 커널과 운영체제를 실행한다.

컨테이너는 하나의 호스트 커널을 공유하면서 프로세스가 보는 파일 시스템과 네트워크, 프로세스 목록과 사용자 환경을 분리하는 운영체제 수준의 가상화 기술이다. 가상 머신처럼 완전한 하드웨어를 각각 제공하지 않으므로 더 적은 자원으로 많은 격리 환경을 빠르게 실행할 수 있다.

두 기술은 모두 하나의 물리 시스템에서 여러 작업을 분리하고 자원을 효율적으로 사용하기 위해 만들어졌지만, 격리하는 계층과 실행 방식이 다르다.

가상화가 필요해진 배경

초기의 컴퓨터와 서버는 가격이 높았으며, 하나의 시스템을 한 작업이나 조직이 독점적으로 사용하는 것은 자원 낭비로 이어질 수 있었다. 중앙 처리 장치와 메모리의 용량이 커져도 개별 응용 프로그램이 항상 전체 자원을 사용하는 것은 아니었다.

여러 사용자가 하나의 컴퓨터를 공동으로 사용하는 시분할 시스템이 등장했지만, 같은 운영체제 안의 프로세스만 분리하는 방식으로는 서로 다른 운영체제나 완전히 독립된 관리 환경을 제공하기 어려웠다. 시스템 소프트웨어를 시험하다가 커널이 중단되면 같은 컴퓨터의 다른 작업에도 영향을 줄 수 있었다.

가상화는 하나의 물리적 컴퓨터를 여러 논리적 컴퓨터로 나누어 다음 문제를 해결하려 했다.

• 여러 조직과 사용자가 한 시스템을 독립적으로 사용
• 서로 다른 운영체제와 버전을 동시에 실행
• 개발과 시험 환경을 실제 운영 환경에서 분리
• 장애와 잘못된 설정의 영향 범위 제한
• 사용률이 낮은 여러 서버를 하나의 물리 서버로 통합
• 오래된 운영체제와 응용 프로그램 유지
• 가상 머신 단위의 복제, 이동과 복구
• 하드웨어를 직접 구입하기 전 필요한 서버를 빠르게 준비

가상화는 Linux보다 오래된 기술이다. 메인프레임에서는 1960년대부터 가상 머신 개념이 발전했으며, 하나의 대형 컴퓨터를 여러 독립 시스템으로 나누어 사용하는 데 활용되었다. 이후 x86 서버가 기업 환경에 대량으로 배치되면서 서버 통합과 개발 환경 격리를 위한 가상화가 다시 중요해졌다.

1990년대와 2000년대 초반의 데이터 센터에서는 서비스마다 별도의 물리 서버를 배치하는 경우가 많았다. 응용 프로그램 충돌과 장애를 피하기에는 단순했지만, 각 서버의 평균 자원 사용률이 낮고 장비 구입과 전력, 냉각과 공간 비용이 증가했다. 가상 머신을 사용하면 하나의 대형 서버에 여러 서비스를 서로 다른 운영체제 환경으로 배치할 수 있었다.

가상 머신과 하이퍼바이저

가상 머신은 CPU와 메모리, 저장 장치, 네트워크 인터페이스와 펌웨어를 가진 독립된 컴퓨터처럼 보이는 실행 환경이다. 게스트 운영체제는 자신이 물리 하드웨어에서 실행된다고 인식하거나, 가상화 환경에 맞춘 인터페이스를 사용한다.

여러 가상 머신을 생성하고 실행하며 자원을 분배하는 소프트웨어를 하이퍼바이저라고 한다. 하이퍼바이저는 가상 머신이 실제 CPU에서 실행되는 시간을 배정하고, 게스트 메모리를 호스트 메모리와 연결하며, 가상 저장 장치와 네트워크 장치를 제공한다.

하이퍼바이저는 실행 위치에 따라 흔히 두 종류로 구분된다.

유형 1 하이퍼바이저는 물리 하드웨어 위에서 직접 실행되며, 가상 머신을 주요 실행 단위로 관리한다. Xen과 여러 상용 서버 가상화 제품이 여기에 포함된다.

유형 2 하이퍼바이저는 일반 운영체제 위의 응용 프로그램처럼 실행된다. 데스크톱에서 다른 운영체제를 시험하거나 개발 환경을 만들 때 사용되는 가상화 프로그램이 대표적이다.

이 구분은 실제 구현에서 항상 명확하지 않다. KVM은 Linux 커널에 가상화 기능을 추가하고, 일반 Linux 사용자 공간의 QEMU와 관리 도구를 이용한다. 전체 시스템은 하드웨어 위에서 직접 가상 머신을 실행하는 서버 하이퍼바이저로 사용되지만, 동시에 일반 Linux 운영체제의 장치 드라이버와 스케줄러를 활용한다.

완전 가상화와 반가상화

초기의 x86 프로세서는 기존 운영체제를 효율적으로 가상화하기 어려운 명령과 실행 특성을 가지고 있었다. 하이퍼바이저는 게스트가 실행하는 특권 명령을 감지해 대신 처리하거나, 실행 코드를 동적으로 변환해야 했다.

완전 가상화에서는 게스트 운영체제를 수정하지 않고 실행할 수 있도록 물리 컴퓨터와 유사한 환경을 제공한다. 게스트는 일반 하드웨어용 운영체제 이미지를 그대로 사용할 수 있지만, 특권 명령과 장치 접근을 중개하는 과정에서 추가 비용이 발생할 수 있다.

반가상화에서는 게스트 운영체제가 자신이 가상화 환경에서 실행된다는 사실을 알고, 하드웨어를 직접 조작하는 대신 하이퍼바이저 호출과 가상화 전용 장치를 사용한다. 이를 통해 소프트웨어만으로 처리하기 어려웠던 일부 x86 가상화 비용을 줄일 수 있었다.

Xen은 케임브리지 대학교의 XenoServer 연구에서 발전한 하이퍼바이저로, 초기에는 수정된 게스트 운영체제를 사용하는 반가상화를 주요 방식으로 활용했다. Xen은 작은 유형 1 하이퍼바이저 위에서 여러 운영체제를 실행하며, 일반적으로 Linux가 dom0라는 관리 영역에서 장치와 가상 머신 관리를 담당한다.^[56]

이후 Intel VT-x와 AMD-V 같은 하드웨어 가상화 확장이 보급되면서 수정하지 않은 운영체제도 효율적으로 실행할 수 있게 되었다. CPU는 게스트와 하이퍼바이저의 실행 상태를 전환하고 특권 작업을 안전하게 중개하는 기능을 제공했다.

현대 가상 머신은 하드웨어 가상화를 사용하면서도 저장 장치와 네트워크 입출력에는 Virtio와 같은 반가상화 장치를 함께 사용하는 경우가 많다. CPU와 메모리는 하드웨어 가상화로 실행하고, 입출력은 게스트가 가상화 전용 드라이버를 사용해 성능을 높이는 방식이다.

QEMU

QEMU는 여러 프로세서와 컴퓨터 시스템을 구현하는 오픈 소스 에뮬레이터이자 가상화 프로그램이다. QEMU는 CPU와 메모리, 칩셋, 저장 장치, 네트워크 카드와 주변 장치를 포함한 전체 컴퓨터 모델을 제공할 수 있다.^[57]

QEMU는 호스트와 다른 프로세서 아키텍처를 소프트웨어로 에뮬레이션할 수 있다. 예를 들어 x86 컴퓨터에서 ARM이나 RISC-V 시스템을 실행하거나, 실제 하드웨어가 없는 상태에서 펌웨어와 운영체제를 개발하고 시험할 수 있다.

전체 CPU 명령을 소프트웨어로 변환하는 에뮬레이션은 유연하지만 실제 하드웨어에서 직접 실행하는 것보다 느릴 수 있다. 호스트와 게스트의 프로세서 아키텍처가 같고 하드웨어 가상화가 지원되면 QEMU는 KVM과 결합하여 게스트 코드를 실제 CPU에서 직접 실행할 수 있다.

Linux 가상화 환경에서 QEMU는 보통 다음 역할을 담당한다.

• 가상 머신 프로세스 생성
• 가상 펌웨어와 하드웨어 모델 제공
• 디스크 이미지와 가상 저장 장치 관리
• 가상 네트워크 장치 제공
• 그래픽·콘솔과 원격 접속 제공
• 가상 머신 상태 저장과 복원
• 실행 중인 가상 머신 이동
• KVM 인터페이스를 통한 CPU 실행

따라서 KVM이 커널 안에서 CPU와 메모리 가상화의 기반을 제공한다면, QEMU는 사용자 공간에서 실제 가상 컴퓨터를 구성하는 역할을 맡는다.

KVM

KVM은 Linux 커널이 하드웨어 가상화 기능을 이용해 가상 머신을 실행할 수 있도록 하는 가상화 하위 시스템이다. KVM은 2006년 공개되었으며 Linux 2.6.20에 포함되어 2007년 2월 정식 커널과 함께 배포되었다.^[58]

KVM은 Intel VT-x와 AMD-V를 비롯한 프로세서의 가상화 확장을 사용한다. KVM 모듈이 적재되면 Linux는 가상 CPU를 만들고 게스트 메모리를 관리하며, 사용자 공간 프로그램이 /dev/kvm 인터페이스를 통해 가상 머신을 제어할 수 있게 한다.

각 KVM 가상 머신은 Linux에서 일반 프로세스의 형태로 나타나며, 가상 CPU는 스레드로 실행된다. 이에 따라 Linux의 스케줄러와 메모리 관리자, NUMA 정책, cgroups와 보안 기능을 가상 머신 관리에도 사용할 수 있다.

KVM은 일반적으로 QEMU와 결합한다. KVM은 게스트 CPU 실행을 가속하고, QEMU는 가상 장치와 디스크, 네트워크, 펌웨어와 관리 기능을 제공한다. libvirt와 같은 관리 계층은 QEMU·KVM 가상 머신의 생성과 저장소, 네트워크와 수명 주기를 공통된 인터페이스로 관리한다.

KVM이 Linux 커널에 포함되면서 배포판과 서버 제조사, 클라우드 사업자는 별도의 폐쇄형 커널 계층을 추가하지 않고 Linux 자체를 가상화 호스트로 사용할 수 있게 되었다. 기존 Linux 장치 드라이버와 하드웨어 지원, 보안 업데이트 체계를 그대로 활용할 수 있다는 점도 확산에 영향을 주었다.

가상화의 활용

Linux 기반 가상화는 다음과 같은 분야에서 사용된다.

• 서버 통합
• 퍼블릭 및 사설 클라우드
• 개발·시험 환경
• 데스크톱 가상화
• 오래된 시스템과 응용 프로그램 보존
• 악성 코드와 보안 분석
• 커널 및 운영체제 개발
• 네트워크 기능 가상화
• 임베디드와 자동차 시스템
• 여러 고객을 위한 호스팅 서비스

클라우드 사업자는 물리 서버의 자원을 여러 가상 머신으로 나누어 고객에게 제공한다. 고객은 실제 하드웨어를 구입하지 않고 필요한 CPU와 메모리, 저장 장치 크기를 선택해 가상 서버를 생성할 수 있다.

가상 머신은 각각 독립된 커널을 실행하므로 서로 다른 Linux 배포판뿐 아니라 Windows와 BSD 등의 운영체제를 같은 호스트에서 실행할 수 있다. 커널 수준에서 분리되기 때문에 일반적인 컨테이너보다 강한 격리 경계로 사용되기도 한다.

반면 각 가상 머신은 자체 커널과 시스템 서비스를 포함하므로 메모리와 저장 공간을 더 많이 사용하고 부팅에도 상대적으로 긴 시간이 필요하다. 대량의 동일한 응용 프로그램을 빠르게 시작하려는 환경에서는 컨테이너가 더 효율적일 수 있다.

운영체제 수준 가상화의 필요성

모든 작업에 서로 다른 운영체제 커널이 필요한 것은 아니다. 웹 서버와 데이터베이스, 응용 프로그램처럼 같은 Linux 커널에서 실행할 수 있는 작업을 분리하기 위해 매번 완전한 가상 머신을 만드는 것은 추가적인 메모리와 저장 공간을 요구한다.

인터넷 호스팅 서비스에서는 하나의 서버에서 여러 고객에게 각각 독립적인 Linux 환경을 제공할 필요가 있었다. 각 고객은 자신의 프로세스와 파일, 네트워크 주소와 사용자 계정을 관리해야 했지만, 모든 고객에게 별도의 커널을 실행하는 가상 머신을 제공하면 같은 하드웨어에서 운영할 수 있는 환경의 수가 줄어들었다.

운영체제 수준 가상화는 하나의 커널을 공유하면서 사용자 공간만 여러 개로 분리하는 방식으로 이 문제를 해결했다. 이를 통해 다음과 같은 이점을 얻을 수 있었다.

• 가상 환경의 빠른 생성과 시작
• 낮은 메모리와 저장 공간 사용
• 하나의 호스트에서 더 많은 환경 실행
• 동일한 Linux 기반 서비스의 분리
• 개발과 실행 환경의 일관성
• 응용 프로그램과 의존성의 묶음 배포
• 프로세스별 자원 사용량 제한
• 서비스 장애와 설정 충돌의 범위 축소

초기의 운영체제 수준 격리는 현대적인 컨테이너와 동일한 형태는 아니었다. 파일 시스템 경로를 제한하는 기능과 프로세스 자원 제어, 네트워크와 사용자 격리 기능이 서로 다른 시기에 개발된 뒤 하나의 컨테이너 실행 환경으로 결합되었다.

chroot와 초기 격리

UNIX의 chroot 기능은 프로세스가 인식하는 루트 디렉터리를 다른 디렉터리로 변경한다. 이를 이용하면 프로그램이 특정 디렉터리 계층 바깥의 파일을 일반적인 경로로 접근하지 못하게 할 수 있다.

chroot는 빌드 환경과 복구 시스템, FTP 서비스와 시험 환경을 분리하는 데 사용되었다. 그러나 프로세스 목록과 네트워크, 사용자 식별자와 커널은 호스트와 그대로 공유하며, 높은 권한을 가진 프로세스에 대한 완전한 보안 경계로 설계되지 않았다.

현대적인 Linux 컨테이너는 파일 시스템 경로만 변경하지 않고 여러 종류의 네임스페이스와 자원 제어, capabilities와 보안 정책을 함께 사용한다. 따라서 chroot는 컨테이너의 역사적 전신 가운데 하나로 볼 수 있지만 그 자체가 완전한 컨테이너는 아니다.

OpenVZ와 가상 사설 서버

1990년대 말부터 Linux 커널을 수정하여 하나의 서버에서 여러 격리된 Linux 사용자 공간을 실행하려는 프로젝트가 개발되었다. Virtuozzo와 그 오픈 소스 기반인 OpenVZ는 이러한 운영체제 수준 가상화의 주요 초기 구현이었다.

OpenVZ의 개발은 1999년 무렵 Linux 2.2 커널을 기반으로 시작되었으며, 2005년 핵심 기술이 GNU GPL로 공개되었다.^[59]

OpenVZ는 각 환경에 독립된 파일 시스템과 프로세스, 네트워크 설정과 사용자 환경을 제공했다. 모든 가상 환경은 호스트의 Linux 커널을 공유했으며, CPU와 메모리 등의 자원을 환경별로 제한할 수 있었다.

이 방식은 웹 호스팅 사업자가 하나의 물리 서버를 여러 가상 사설 서버로 나누어 판매하는 데 적합했다. 완전한 가상 머신보다 적은 자원을 사용하면서 각 고객에게 root 권한을 가진 독립적인 Linux 사용자 공간을 제공할 수 있었기 때문이다.

초기의 OpenVZ는 공식 Linux 커널에 포함되지 않은 별도 커널 패치를 사용했다. 이후 Linux 본류에 네임스페이스와 cgroups 기능이 발전하면서 별도 패치 없이 컨테이너를 구성하는 LXC와 다른 실행 환경이 등장했다.

Linux 네임스페이스

Linux 네임스페이스는 시스템 전체에서 공유되던 자원을 프로세스 집합별로 다르게 보이게 하는 커널 기능이다. 네임스페이스 안의 프로세스는 해당 자원의 독립된 인스턴스를 가진 것처럼 동작한다.^[60]

Linux는 다음과 같은 네임스페이스를 제공한다.

PID 네임스페이스 안에서는 컨테이너의 첫 프로세스가 PID 1로 보일 수 있지만, 호스트에서는 다른 PID를 가진 일반 프로세스로 보인다. 네트워크 네임스페이스에는 독립적인 네트워크 인터페이스와 라우팅 테이블, 방화벽 규칙을 구성할 수 있다.

사용자 네임스페이스는 컨테이너 안의 사용자 식별자를 호스트의 다른 식별자로 연결할 수 있다. 컨테이너 안에서 root로 보이는 프로세스가 호스트에서는 일반 사용자 권한으로 실행되도록 구성할 수 있어 비특권 컨테이너의 기반이 된다.

네임스페이스는 프로세스가 무엇을 볼 수 있는지를 분리하지만, 사용할 수 있는 자원의 양을 자동으로 제한하지는 않는다. 컨테이너가 호스트의 모든 메모리나 CPU 시간을 소비하지 못하게 하려면 cgroups와 함께 사용해야 한다.

cgroups

cgroups는 프로세스를 계층적인 그룹으로 묶고 CPU와 메모리, 입출력과 프로세스 수 등의 자원을 분배하고 제한하며 측정하는 Linux 커널 기능이다.

cgroups가 필요한 이유는 프로세스의 보기 환경만 격리해도 자원 경쟁은 계속 발생하기 때문이다. 하나의 컨테이너가 메모리를 모두 사용하거나 지나치게 많은 프로세스를 만들면 같은 호스트의 다른 서비스와 운영체제 전체에 영향을 줄 수 있다.

cgroups는 다음과 같은 기능을 제공한다.

• CPU 사용 비중과 실행 위치 제어
• 메모리 사용량 제한과 통계
• 블록 장치 입출력 제어
• 생성 가능한 프로세스 수 제한
• 프로세스 집합의 일시 정지
• 자원 사용량 측정과 계정 처리
• 프로세스 그룹별 우선순위 설정

cgroup v1에서는 자원 제어기마다 서로 다른 계층을 구성할 수 있었다. 이 방식은 유연했지만 여러 관리 도구가 서로 다른 계층을 만들면서 복잡성과 일관성 문제가 생겼다.

cgroup v2는 모든 프로세스와 자원 제어기를 하나의 통합된 계층으로 관리하는 구조를 제공한다. 각 프로세스는 한 cgroup에 속하며, 부모와 자식 그룹 관계에 따라 자원을 분배하고 위임할 수 있다.^[61]

cgroups는 컨테이너뿐 아니라 systemd 서비스 관리, 사용자 세션, 고성능 컴퓨팅 작업과 가상 머신 자원 제한에도 사용된다.

LXC

LXC는 Linux 커널의 네임스페이스와 cgroups, capabilities와 보안 기능을 이용해 컨테이너를 생성하고 관리하는 사용자 공간 도구와 라이브러리다. LXC는 2008년부터 개발되었으며, 별도의 커널 패치 대신 Linux 본류의 격리 기능을 조합한 초기 범용 컨테이너 실행 환경 가운데 하나가 되었다.^[62]

LXC는 하나의 응용 프로그램만 실행하는 환경뿐 아니라 init 시스템과 여러 서비스를 갖춘 완전한 Linux 사용자 공간을 실행할 수 있다. 이러한 형태를 시스템 컨테이너라고 한다.

시스템 컨테이너는 가상 머신과 비슷한 관리 경험을 제공하지만 호스트와 같은 Linux 커널을 공유한다. 컨테이너 안에는 다른 배포판의 사용자 공간을 넣을 수 있으나, 호스트와 다른 운영체제 커널을 실행할 수는 없다.

LXC는 다음 기능을 결합한다.

• 네임스페이스 생성
• cgroup 자원 제어
• 루트 파일 시스템 준비
• 네트워크 인터페이스 연결
• 사용자 및 그룹 식별자 매핑
• capabilities 제한
• AppArmor와 seccomp 정책
• 컨테이너 시작과 종료
• 콘솔과 파일 시스템 관리

LXC에서 발전한 관리 계층과 관련 프로젝트는 장기간 실행되는 시스템 컨테이너를 가상 머신과 유사하게 운영하는 데 사용된다. Incus는 시스템 컨테이너와 가상 머신을 공통된 방식으로 관리하며, 컨테이너에는 Linux 네임스페이스와 cgroups를 사용한다.^[63]

응용 프로그램 컨테이너

초기의 컨테이너는 여러 서비스와 init 시스템을 포함한 작은 가상 서버와 비슷하게 사용되었다. 이후 하나의 응용 프로그램과 그 의존성을 묶어 배포하는 응용 프로그램 컨테이너 방식이 널리 확산되었다.

응용 프로그램 컨테이너는 운영체제 전체를 장기간 관리하기보다 특정 프로그램을 실행하는 데 필요한 파일과 라이브러리, 설정을 이미지에 포함한다. 실행 중인 컨테이너의 상태를 직접 수정하기보다 새 이미지를 빌드하여 컨테이너를 교체하는 방식이 주로 사용된다.

이 방식은 개발 환경에서는 정상 작동한 프로그램이 시험과 운영 환경에서는 라이브러리 버전이나 설정 차이로 실패하는 문제를 줄이려 했다. 응용 프로그램과 의존성을 같은 이미지로 배포하면 인프라가 달라져도 비교적 일관된 실행 환경을 만들 수 있다.

응용 프로그램 컨테이너는 다음 요구에서 발전했다.

• 개발·시험·운영 환경의 차이 축소
• 응용 프로그램별 의존성 충돌 방지
• 빠르고 반복 가능한 배포
• 서비스별 독립적인 업데이트와 복구
• 대규모 서버에서 높은 배치 밀도 확보
• 자동 확장과 일시적인 작업 실행
• 마이크로서비스 단위의 배포
• 이미지 기반 소프트웨어 공급망

Docker

Docker는 2013년 공개되어 Linux 컨테이너를 개발자와 운영자가 쉽게 만들고 배포할 수 있도록 한 플랫폼이다. Docker 자체가 네임스페이스나 cgroups를 처음 개발한 것은 아니지만, 기존 Linux 커널 기능을 이미지 형식과 빌드 도구, 레지스트리, 네트워크와 명령줄 인터페이스로 통합했다.^[64]

초기의 Docker는 LXC를 실행 기반으로 사용했으며, 이후 자체 라이브러리인 libcontainer를 개발했다. libcontainer는 이후 Open Container Initiative의 저수준 런타임인 runc로 발전했다.

Docker가 확산된 이유에는 다음 요소가 있었다.

• 텍스트 파일로 이미지 빌드 절차 정의
• 계층형 이미지와 캐시
• 이미지의 이름과 버전 관리
• 공개 및 사설 이미지 저장소
• 일관된 컨테이너 실행 명령
• 네트워크와 볼륨 관리
• 개발 컴퓨터와 서버 사이의 동일한 실행 방식
• 응용 프로그램과 의존성의 묶음 배포

Docker는 컨테이너를 작은 가상 머신으로 관리하기보다, 응용 프로그램을 빌드하고 전달하는 표준 단위로 다루는 방식을 대중화했다. 컨테이너가 종료되면 내부 상태를 영구적으로 보존하기보다 이미지를 바탕으로 새 컨테이너를 생성하고, 필요한 데이터는 외부 볼륨이나 데이터베이스에 저장하는 방식이 널리 사용되었다.

컨테이너 이미지와 런타임

컨테이너 이미지는 응용 프로그램 코드와 실행에 필요한 라이브러리, 도구와 기본 파일 시스템을 묶은 읽기 중심의 파일 집합이다. 이미지는 일반적으로 여러 계층으로 구성되며, 공통된 기반 계층을 여러 이미지가 공유할 수 있다.

이미지 자체는 실행 중인 프로세스가 아니다. 컨테이너 런타임은 이미지를 파일 시스템으로 준비하고, 네임스페이스와 cgroups, 보안 정책을 설정한 뒤 이미지 안의 프로그램을 실행한다.

현대 Linux 컨테이너 환경에는 역할이 다른 여러 구성 요소가 사용된다.

• runc는 OCI 실행 명세에 따라 하나의 컨테이너 프로세스를 생성하는 저수준 런타임이다.
• containerd는 이미지 전송과 저장, 컨테이너 수명 주기와 runc 실행을 관리한다.
• CRI-O는 Kubernetes의 컨테이너 런타임 인터페이스에 맞춰 OCI 컨테이너를 실행한다.
• Podman은 데몬 없이 컨테이너와 Pod를 관리하는 사용자 도구를 제공한다.
• Docker Engine은 이미지 빌드와 네트워크, 볼륨과 컨테이너 관리를 통합한다.

Docker는 2015년 컨테이너 이미지와 런타임 기술을 Open Container Initiative에 제공했으며, 이를 바탕으로 OCI 이미지 명세와 런타임 명세가 발전했다. 표준화는 특정 도구로 만든 이미지를 여러 호환 런타임에서 실행할 수 있는 기반을 제공했다.^[65]

컨테이너 오케스트레이션

컨테이너 한두 개는 개별 명령으로 실행할 수 있지만, 여러 서버에 수천 개의 컨테이너를 배치하려면 별도의 관리 계층이 필요하다. 서버 장애나 트래픽 증가에 따라 컨테이너를 다시 배치하고, 네트워크 주소와 저장 장치, 비밀 정보와 업데이트를 관리해야 하기 때문이다.

컨테이너 오케스트레이션 시스템은 다음 기능을 제공한다.

• 컨테이너 배치
• 필요한 복제본 수 유지
• 장애 발생 시 재시작과 재배치
• 서비스 검색과 부하 분산
• 점진적 업데이트와 되돌리기
• 자동 확장
• 저장 장치 연결
• 설정과 비밀 정보 관리
• 자원 요청과 제한
• 노드 상태 관리

Kubernetes는 이러한 기능을 제공하는 대표적인 오케스트레이션 시스템이다. 사용자는 개별 컨테이너를 어느 서버에서 실행할지 직접 지정하기보다 원하는 응용 프로그램 상태를 선언하고, 제어 계층이 실제 클러스터를 그 상태에 맞게 유지하도록 한다.

Kubernetes 자체는 컨테이너 격리를 구현하지 않는다. 각 Linux 노드의 컨테이너 런타임과 Linux 커널이 실제 프로세스와 자원 격리를 수행하며, Kubernetes는 여러 노드와 컨테이너의 배치와 수명 주기를 조정한다.

가상 머신과 컨테이너의 차이

가상 머신과 컨테이너는 격리 계층이 다르다.

가상 머신은 자체 커널을 가지므로 게스트 커널이 손상되어도 일반적으로 호스트 커널과 직접 분리된다. 컨테이너는 호스트 커널을 공유하므로 커널 취약점이 격리 경계에 영향을 줄 수 있다.

반대로 컨테이너는 별도의 커널을 부팅하지 않으므로 빠르게 생성할 수 있고, 같은 메모리와 저장 장치에서 더 많은 실행 환경을 구성할 수 있다.

가상 머신과 컨테이너의 결합

실제 클라우드와 데이터 센터에서는 가상 머신과 컨테이너를 함께 사용하는 경우가 많다. 물리 서버 위에 여러 가상 머신을 만들고, 각 가상 머신 안에서 여러 컨테이너를 실행하는 방식이다.

가상 머신은 고객과 조직, 보안 영역을 비교적 강하게 분리하고, 컨테이너는 각 가상 머신 안에서 응용 프로그램을 빠르게 배포하고 높은 밀도로 실행한다.

결합 방식은 다음과 같은 장점을 제공한다.

• 고객 또는 조직별 가상 머신 격리
• 응용 프로그램별 컨테이너 배포
• 서로 다른 커널과 배포판 요구 분리
• 가상 머신 단위의 네트워크와 보안 정책
• 컨테이너 단위의 빠른 확장과 교체
• 물리 하드웨어와 응용 프로그램 관리 책임 분리

공용 클라우드의 관리형 Kubernetes 서비스도 각 노드를 가상 머신으로 제공하고, 그 위에서 Linux 컨테이너를 실행하는 형태가 일반적이다.

일부 실행 환경은 가상 머신 수준의 격리와 컨테이너 수준의 시작 속도 및 관리 방식을 결합하려 한다. 경량 가상 머신 안에서 컨테이너를 실행하거나, 각 컨테이너 또는 Pod에 작은 전용 커널을 제공하는 방식이 이에 해당한다.

격리와 보안

컨테이너는 단순히 프로세스 이름을 분리하는 기능이 아니다. 실제 격리는 여러 Linux 보안 기능을 조합하여 구성된다.

• 네임스페이스로 자원 보기 분리
• cgroups로 자원 사용 제한
• capabilities로 root 권한 분할
• seccomp로 시스템 호출 제한
• SELinux와 AppArmor로 접근 제어
• 읽기 전용 파일 시스템
• 사용자 네임스페이스를 이용한 UID 매핑
• 장치 접근 제한
• 네트워크 정책과 방화벽
• 서명된 이미지와 공급망 검증

컨테이너 안에서 root로 실행되는 프로세스가 호스트에서도 같은 권한을 갖는 구성은 위험을 높일 수 있다. 사용자 네임스페이스와 rootless 컨테이너를 사용하면 컨테이너 내부의 root를 호스트의 일반 사용자에 연결할 수 있다.

cgroups 제한이 없으면 컨테이너가 호스트의 CPU와 메모리를 과도하게 사용해 다른 서비스에 영향을 줄 수 있다. LXC 보안 문서도 기본 cgroup 제한이 없는 환경에서는 컨테이너가 메모리와 프로세스, 네트워크 자원을 고갈시킬 수 있음을 지적한다.^[66]

컨테이너 격리는 가상 머신과 동일하지 않으며, 신뢰할 수 없는 작업을 실행할 때는 위협 모델에 따라 가상 머신이나 별도의 물리 시스템, 추가 샌드박스를 함께 사용할 수 있다.

Linux에서의 의미

Linux는 가상화와 컨테이너 기술을 모두 제공함으로써 물리 하드웨어와 응용 프로그램 사이의 여러 계층에서 실행 환경을 구성할 수 있게 했다.

KVM과 Xen은 하나의 서버에서 서로 다른 운영체제와 커널을 실행하는 기반을 제공했다. QEMU는 가상 하드웨어와 다른 프로세서 아키텍처를 구현했으며, libvirt와 여러 클라우드 플랫폼은 이러한 가상 머신을 대규모로 관리했다.

네임스페이스와 cgroups는 하나의 Linux 커널에서 여러 사용자 공간을 격리하고 자원을 제어하는 기반이 되었다. LXC와 OpenVZ는 독립적인 Linux 시스템 환경을 제공했고, Docker와 OCI 생태계는 응용 프로그램과 의존성을 이미지로 묶어 배포하는 방식을 확산시켰다.

가상화는 서버를 하드웨어에서 분리했고, 컨테이너는 응용 프로그램을 개별 운영체제 설치 환경에서 분리했다. 두 기술은 서버 통합과 클라우드 컴퓨팅, 자동 배포와 대규모 서비스 운영을 가능하게 한 Linux 생태계의 핵심 기반으로 사용된다.

Linux는 운영체제와 서버 프로그램, 데스크톱 응용 프로그램, 임베디드 소프트웨어와 커널을 개발하는 환경으로 널리 사용된다. 개발에 필요한 컴파일러와 링커, 셸과 편집기, 빌드 자동화 도구, 디버거와 성능 분석기가 배포판의 패키지 저장소를 통해 제공되며, 대부분을 명령줄에서 조합하거나 통합 개발 환경 안에서 사용할 수 있다.

Linux 개발 환경에는 하나의 공식적인 도구 집합이 존재하지 않는다. 같은 C 또는 C++ 프로젝트도 GCC와 Clang 가운데 하나를 선택하고, Make나 Ninja를 직접 사용하거나 CMake, Meson, Autotools와 같은 상위 빌드 체계를 사용할 수 있다. 편집기도 Vim과 Emacs 같은 터미널 편집기부터 KDevelop, GNOME Builder, Qt Creator와 여러 상용 개발 환경까지 선택할 수 있다.

이러한 선택 가능성은 Linux 개발 문화의 특징이지만, 프로젝트마다 서로 다른 도구와 설정을 요구하는 원인이 되기도 한다. 배포판은 일반적으로 개발에 필요한 프로그램을 개별 패키지나 개발 도구 묶음으로 제공하며, 프로젝트는 빌드 문서와 자동화 파일을 통해 필요한 환경을 정의한다.

셸과 기본 명령줄 환경

Linux 개발은 전통적으로 셸과 명령줄 도구를 중심으로 이루어졌다. 셸은 프로그램을 실행하는 기능뿐 아니라 파일과 디렉터리 조작, 입출력 연결, 환경 변수 설정과 여러 도구의 자동화를 담당한다.

개발 환경에서 널리 사용되는 셸에는 다음과 같은 것들이 있다.

• Bash
• Zsh
• Fish
• Dash
• KornShell
• Nushell

Bash는 많은 Linux 배포판에서 대화형 셸 또는 스크립트 실행 환경으로 사용된다. Zsh는 확장된 자동 완성과 프롬프트 사용자화 기능으로 사용되며, Fish는 기본 설정만으로도 구문 강조와 제안을 제공하는 대화형 사용성을 강조한다. Dash는 기능을 줄이고 빠르게 실행되는 POSIX 계열 셸로 시스템 스크립트에 사용될 수 있다.

셸에서는 다음과 같은 기본 프로그램을 조합한다.

• find와 fd를 이용한 파일 검색
• grep, ripgrep과 awk를 이용한 텍스트 검색과 처리
• sed를 이용한 텍스트 변환
• sort, uniq, cut과 xargs를 이용한 데이터 가공
• curl과 wget을 이용한 네트워크 자료 전송
• tar, gzip, xz와 zstd를 이용한 압축과 보관
• diff, patch와 cmp를 이용한 변경 비교
• jq와 yq를 이용한 JSON 및 YAML 처리
• tmux와 GNU Screen을 이용한 터미널 세션 관리

이러한 프로그램은 각각 작은 작업에 집중하며, 파이프를 통해 한 프로그램의 출력을 다른 프로그램의 입력으로 전달할 수 있다. 개발자는 파일 검색 결과를 필터링하고 변환하거나, 빌드 로그에서 오류만 추출하는 작업을 별도의 대형 프로그램 없이 명령 조합으로 수행할 수 있다.

컴파일러

Linux에서 네이티브 프로그램을 개발할 때 대표적으로 사용되는 컴파일러 체인은 GCC와 LLVM·Clang이다.

GCC는 C와 C++, Objective-C, Fortran, Ada와 여러 언어를 지원하며 GNU 사용자 공간과 Linux 커널, 수많은 오픈 소스 프로젝트를 빌드하는 데 사용되어 왔다. gcc와 g++는 각각 C와 C++ 컴파일 명령으로 널리 사용되지만, 실제 빌드 과정에서는 전처리기와 어셈블러, 링커를 포함한 여러 프로그램을 호출한다.

Clang은 LLVM 프로젝트의 C 계열 언어 프런트엔드다. 진단 메시지와 도구 통합, 정적 분석 기능을 제공하며 GCC와 상당 부분 호환되는 명령줄 인터페이스를 사용한다. Linux 커널도 지원되는 구성에서 GCC와 Clang으로 빌드할 수 있다.

컴파일러는 일반적으로 다음 작업을 수행한다.

• 소스 코드 전처리
• 구문과 타입 검사
• 중간 표현 생성
• 코드 최적화
• 대상 프로세서용 기계어 생성
• 디버깅 및 진단 정보 생성
• 보안 강화 옵션 적용
• 링크 단계 호출

Linux에서는 실행 중인 호스트와 다른 플랫폼의 프로그램을 만드는 크로스 컴파일도 널리 사용된다. x86-64 시스템에서 ARM64나 RISC-V, 임베디드 프로세서용 실행 파일과 커널을 빌드할 수 있으며, 컴파일러 이름에 대상 아키텍처와 ABI가 포함되는 경우가 많다.

C와 C++ 외에도 Rust의 rustc, Go의 go, Java의 javac, Free Pascal과 여러 언어 구현을 배포판 패키지 또는 언어별 도구 체인을 통해 설치할 수 있다. Python, Ruby, Perl과 셸 스크립트처럼 일반적으로 별도의 네이티브 컴파일 과정을 요구하지 않는 언어도 Linux 개발과 자동화에 널리 사용된다.

어셈블러와 링커

컴파일러가 생성한 어셈블리 코드와 오브젝트 파일은 어셈블러와 링커를 통해 실행 파일 또는 라이브러리로 만들어진다.

GNU Binutils는 다음과 같은 주요 도구를 제공한다.

• as — 어셈블러
• ld — 링커
• ar — 정적 라이브러리 보관 도구
• nm — 오브젝트의 심볼 표시
• objdump — 오브젝트와 실행 파일 분석
• objcopy — 오브젝트 형식과 섹션 변환
• readelf — ELF 구조 표시
• strip — 불필요한 심볼과 디버깅 정보 제거
• addr2line — 주소를 소스 위치로 변환

LLVM 생태계에는 LLD 링커와 llvm-ar, llvm-objdump, llvm-readelf 등의 대응 도구가 있다. 프로젝트는 GNU 도구와 LLVM 도구를 함께 사용하거나, 컴파일러와 링커를 독립적으로 조합할 수 있다.

Linux의 네이티브 실행 파일과 공유 라이브러리는 주로 ELF 형식을 사용한다. readelf, objdump, nm 같은 도구는 실행 파일의 헤더와 섹션, 심볼과 동적 라이브러리 의존성을 분석할 때 사용된다.

Make와 빌드 자동화

소규모 프로그램은 컴파일러 명령 하나로 만들 수 있지만, 여러 소스 파일과 라이브러리, 생성 코드를 포함한 프로젝트에서는 파일 간 의존 관계와 빌드 순서를 관리해야 한다.

Make는 목표 파일과 의존 파일, 이를 생성하는 명령을 Makefile에 정의한다. 변경된 소스와 그 영향을 받는 결과물만 다시 빌드할 수 있으며, Linux와 UNIX 계열 프로젝트에서 오랫동안 사용되어 왔다.

Makefile에는 다음과 같은 내용이 포함될 수 있다.

• 소스 파일을 오브젝트 파일로 컴파일하는 규칙
• 오브젝트 파일을 실행 파일이나 라이브러리로 연결하는 규칙
• 생성 코드와 리소스 처리
• 설치와 제거
• 시험 실행
• 문서 생성
• 정리 작업
• 플랫폼별 옵션

GNU Make 외에도 BSD Make와 여러 구현이 존재한다. 각 구현은 기본 규칙과 확장 문법에서 차이가 있으므로 프로젝트가 요구하는 Make 구현을 확인해야 할 수 있다.

Ninja는 사람이 직접 복잡한 빌드 파일을 작성하기보다 CMake와 Meson 같은 상위 도구가 생성한 빌드 계획을 빠르게 실행하도록 설계된 빌드 도구다. 작은 시작 비용과 병렬 빌드에 중점을 두며 대규모 프로젝트에서 사용된다.

Autotools

GNU Autotools는 서로 다른 UNIX 계열 운영체제와 컴파일러 환경에서 소프트웨어를 빌드할 수 있도록 구성 스크립트와 Makefile을 생성하는 전통적인 도구 집합이다.

주요 구성 요소는 다음과 같다.

• Autoconf
• Automake
• Libtool
• M4
• pkg-config와 함께 사용되는 구성 검사

Autoconf는 시스템의 함수와 헤더, 라이브러리와 컴파일러 특성을 검사하는 configure 스크립트를 생성한다. 사용자는 소스 디렉터리에서 ./configure, make, make install 순서로 프로그램을 빌드하는 방식에 익숙할 수 있다.

Autotools는 오래된 UNIX 환경까지 폭넓게 지원하고 많은 프로젝트에 축적된 검사를 제공한다. 반면 생성 파일과 매크로 계층이 복잡하고 오류를 추적하기 어렵다는 평가도 있어, 새 프로젝트에서는 CMake나 Meson을 선택하기도 한다.

CMake

CMake는 플랫폼과 컴파일러에 독립적인 프로젝트 정의를 읽고 Makefile, Ninja 파일 또는 통합 개발 환경용 프로젝트 같은 네이티브 빌드 시스템을 생성한다. CMake 자체가 모든 컴파일 작업을 직접 수행하기보다 선택된 생성기에 맞는 빌드 규칙을 만든다.^[67]

CMake 프로젝트는 일반적으로 CMakeLists.txt 파일에 다음 정보를 정의한다.

• 프로젝트와 사용 언어
• 실행 파일과 라이브러리
• 소스 파일과 헤더 경로
• 컴파일 옵션과 매크로
• 외부 라이브러리 탐색
• 설치 규칙
• 시험
• 패키지 생성

CMake는 하나의 소스 트리에서 여러 빌드 디렉터리를 분리할 수 있다. 같은 프로젝트를 디버그와 릴리스 설정, GCC와 Clang, 정적 및 공유 라이브러리 구성으로 각각 빌드할 수 있다.

크로스 컴파일에서는 toolchain 파일에 대상 운영체제와 컴파일러, sysroot와 검색 경로를 정의한다. C와 C++의 크로스 플랫폼 프로젝트에서 널리 사용되지만, 프로젝트가 복잡해질수록 변수와 전역 설정, 모듈 탐색 방식이 이해하기 어려워질 수 있다.

Meson

Meson은 빠른 빌드와 읽기 쉬운 프로젝트 정의를 목표로 하는 빌드 시스템이다. 자체 선언형 문법을 사용하며 일반적으로 Ninja를 실제 빌드 실행기로 사용한다.^[68]

Meson 프로젝트는 meson.build 파일에서 실행 파일과 라이브러리, 의존성을 정의한다. 외부 라이브러리를 dependency()로 탐색하고, 테스트와 설치 규칙, 빌드 옵션을 함께 구성할 수 있다.

Meson은 C와 C++, Objective-C, Fortran, D, Rust 등 여러 언어를 지원하며 Linux 데스크톱과 시스템 소프트웨어 프로젝트에서도 사용된다. 별도의 빌드 디렉터리를 기본으로 사용하고, 구성과 실제 빌드 단계를 분리한다.

Meson은 비교적 간결한 문법과 빠른 Ninja 빌드를 제공하지만, Autotools나 CMake로 이미 구축된 대형 프로젝트를 이전하려면 빌드 체계를 다시 작성해야 할 수 있다.

그 밖의 빌드 도구

Linux 생태계에는 프로젝트의 언어와 규모, 재현성 요구에 따라 다양한 빌드 도구가 사용된다.

• Bazel은 대규모 다중 언어 저장소와 재현 가능한 빌드, 원격 캐시와 분산 실행을 목표로 한다.
• Buck 계열 도구는 대규모 코드베이스의 증분 빌드를 관리한다.
• SCons는 Python 스크립트로 빌드 정의를 작성한다.
• xmake는 Lua 기반의 프로젝트 정의와 패키지 통합을 제공한다.
• Premake는 Lua 정의에서 여러 빌드 시스템 프로젝트를 생성한다.
• Ccache는 동일한 컴파일 입력의 결과를 저장해 반복 빌드 시간을 줄인다.
• distcc는 C와 C++ 컴파일 작업을 여러 컴퓨터에 분산한다.
• Icecream은 네트워크의 여러 빌드 노드에 컴파일 작업을 배분한다.

언어별 빌드 및 패키지 도구도 개발 환경의 일부다.

• Cargo — Rust
• Go 도구 체인과 Go modules
• Maven과 Gradle — Java 및 JVM 언어
• pip, Poetry, uv와 setuptools — Python
• npm, Yarn과 pnpm — JavaScript
• Bundler — Ruby
• Cabal과 Stack — Haskell

이 도구들은 컴파일뿐 아니라 의존성 다운로드와 버전 결정, 테스트, 문서 생성과 패키지 배포를 함께 담당할 수 있다.

소스 코드 관리

Git은 Linux 커널 개발을 위해 리누스 토르발스가 처음 개발한 분산 버전 관리 시스템이며, Linux와 오픈 소스 개발에서 널리 사용된다.

Git 저장소에는 각 개발자가 전체 변경 이력과 브랜치를 로컬에 보유할 수 있다. 네트워크 연결 없이 커밋과 비교, 브랜치 작업을 수행한 뒤 다른 저장소와 변경을 교환할 수 있다.

Linux 개발에서 사용되는 Git 관련 도구와 서비스에는 다음과 같은 것들이 있다.

• Git 명령줄 도구
• GitHub
• GitLab
• Codeberg
• Gerrit
• cgit와 Gitweb
• 이메일 패치와 git send-email
• Patchwork
• SourceHut

Linux 커널 개발은 일반적인 웹 기반 pull request만으로 이루어지지 않고 메일링 리스트에 패치를 보내고 검토하는 방식을 중심으로 유지된다. git format-patch는 커밋을 이메일 패치 형태로 만들고, git send-email은 이를 개발 목록에 전송한다.

Git 위에는 Tig, Lazygit과 GitUI 같은 터미널 인터페이스와 여러 그래픽 클라이언트가 존재한다. 일부 개발자는 명령줄만 사용하고, 다른 개발자는 IDE의 Git 통합과 코드 호스팅 서비스의 병합 요청을 이용한다.

편집기

Linux에서는 단순 텍스트 편집기부터 확장 가능한 프로그래밍 환경까지 다양한 편집기를 사용할 수 있다.

Vim과 Neovim은 터미널에서 실행할 수 있는 모달 편집기다. 키보드 중심의 편집과 매크로, 플러그인과 언어 서버 연동을 제공한다. 원격 서버와 최소 설치 환경에서도 사용할 수 있어 시스템 관리와 개발에 널리 쓰인다.

Emacs는 텍스트 편집기를 중심으로 Lisp 확장을 통해 코드 탐색, 디버깅, 버전 관리, 셸, 이메일과 문서 작성 환경을 구성할 수 있다. Vim과 Emacs의 선택은 오랫동안 개발자 문화의 농담과 논쟁 소재가 되기도 했다.

Linux 데스크톱에는 다음과 같은 편집기도 사용된다.

• Kate
• GNOME Text Editor
• Gedit
• Geany
• Sublime Text
• Zed
• Helix
• Lapce
• 여러 Electron 기반 코드 편집기

Kate는 KDE의 고급 텍스트 편집기로 프로젝트와 터미널, 언어 서버와 플러그인 기능을 제공한다. Geany는 비교적 가벼운 편집기와 기본적인 IDE 기능을 결합한다.

편집기는 언어 서버 프로토콜을 통해 자동 완성과 정의 이동, 오류 진단과 이름 변경을 지원할 수 있다. clangd, rust-analyzer, gopls, Pyright와 여러 언어 서버를 편집기와 독립적으로 사용할 수 있으므로, 터미널 편집기도 대형 IDE와 유사한 코드 분석 기능을 갖출 수 있다.

통합 개발 환경

Linux에서는 범용 또는 특정 데스크톱과 언어에 맞춘 통합 개발 환경을 사용할 수 있다.

KDevelop은 KDE에서 개발하는 IDE로 C와 C++, Python, QML과 여러 언어를 지원하며, CMake 문서와 Qt 문서, 매뉴얼 페이지를 편집기 안에서 확인할 수 있다. 플러그인을 통해 Clang-Tidy와 Heaptrack 등의 도구를 연결할 수 있다.^[69]

GNOME Builder는 GNOME 응용 프로그램 개발에 맞춘 IDE다. GTK와 GLib, Flatpak, Meson과 GNOME 개발 도구를 통합하고, GNOME 플랫폼용 응용 프로그램을 만들고 시험하는 환경을 제공한다.^[70]

Qt Creator는 Qt 응용 프로그램과 C++ 개발을 중심으로 하는 IDE다. CMake와 qmake, QML 편집, 디버거와 UI 설계 도구를 통합한다.

그 밖에도 다음과 같은 환경이 Linux에서 사용된다.

• CLion
• Eclipse
• IntelliJ IDEA
• Android Studio
• NetBeans
• Code::Blocks
• GNAT Studio
• Eric
• Spyder
• RStudio
• JetBrains의 언어별 IDE
• 웹 브라우저 기반 개발 환경

IDE는 편집과 빌드, 디버깅과 버전 관리를 하나의 화면에 통합하지만, 내부적으로 GCC와 Clang, GDB, CMake와 Git 같은 독립 도구를 호출하는 경우가 많다. 이에 따라 동일한 프로젝트를 IDE와 명령줄에서 함께 다룰 수 있다.

데스크톱 응용 프로그램 개발

Linux 데스크톱 응용 프로그램은 특정한 단일 그래픽 툴킷에 묶이지 않는다. 서로 다른 데스크톱 환경과 툴킷, 언어 바인딩을 선택할 수 있다.

GTK는 GNOME과 여러 데스크톱 응용 프로그램에서 사용되는 그래픽 툴킷이다. C API를 중심으로 하며 Rust, Python, Vala와 여러 언어 바인딩을 제공한다. GNOME 응용 프로그램은 GLib, GObject, GIO와 GNOME 플랫폼 라이브러리를 함께 사용할 수 있다.

Qt는 C++ 기반의 크로스 플랫폼 응용 프로그램 프레임워크다. 위젯 기반 UI와 QML·Qt Quick, 네트워크, 멀티미디어와 여러 시스템 기능을 제공하며 KDE Plasma와 KDE 응용 프로그램의 기반으로 사용된다.

그 밖에도 다음과 같은 그래픽 기술이 사용된다.

• SDL
• GLFW
• Dear ImGui
• wxWidgets
• FLTK
• EFL
• Tk
• Electron
• Tauri
• Avalonia
• JavaFX

Wayland와 X11 환경의 차이, 데스크톱 포털, 파일 선택기와 알림, 테마와 접근성도 데스크톱 응용 프로그램 개발에서 고려된다. Flatpak으로 배포되는 응용 프로그램은 샌드박스 밖의 파일과 장치, 데스크톱 기능에 접근할 때 포털 인터페이스를 사용할 수 있다.

디버거

GDB는 Linux에서 널리 사용되는 네이티브 디버거다. 실행 중인 프로그램을 중단하고 소스 코드와 어셈블리 명령을 따라가며 변수와 메모리, 레지스터와 호출 스택을 조사할 수 있다.

GDB는 다음과 같은 작업에 사용된다.

• 중단점과 감시점 설정
• 한 줄 또는 한 명령씩 실행
• 함수 호출 스택 확인
• 변수와 메모리 표시 및 변경
• 스레드 전환
• 코어 덤프 분석
• 원격 대상 디버깅
• 실행 중인 프로세스 연결

LLVM 생태계에는 LLDB가 있다. LLDB는 Clang과 LLVM의 타입 및 디버깅 정보를 활용하며 C와 C++, Objective-C와 Swift 등의 디버깅에 사용된다.

터미널 사용자 인터페이스인 GDB TUI, GDB Dashboard와 GEF, pwndbg 같은 확장은 레지스터와 어셈블리, 메모리 지도를 보기 쉽게 표시한다. IDE는 GDB 또는 LLDB를 백엔드로 사용하면서 그래픽 중단점과 변수 창을 제공할 수 있다.

시스템 호출과 라이브러리 추적

프로그램이 파일이나 네트워크, 프로세스 기능을 어떻게 사용하는지 확인할 때는 소스 디버거 외의 추적 도구가 사용된다.

strace는 프로그램이 실행하는 Linux 시스템 호출과 그 결과를 기록한다. 프로그램이 찾지 못하는 파일, 권한 거부, 네트워크 연결 실패와 프로세스 생성 과정을 조사할 때 유용하다.

ltrace는 프로그램이 호출하는 동적 라이브러리 함수를 추적할 수 있다. ldd는 실행 파일이 요구하는 공유 라이브러리를 표시하고, 동적 로더의 진단 옵션은 라이브러리 검색과 심볼 바인딩 과정을 분석하는 데 사용된다.

fuser와 lsof는 파일이나 포트, 장치를 사용 중인 프로세스를 찾는다. ss는 네트워크 소켓 상태를 확인하고, ip는 인터페이스와 주소, 라우팅을 관리하거나 조사한다.

이러한 도구는 프로그램을 다시 컴파일하지 않고도 실행 중인 동작을 관찰할 수 있어, 개발 환경뿐 아니라 실제 서버의 장애 분석에도 사용된다.

메모리와 정의되지 않은 동작 검사

C와 C++ 프로그램은 잘못된 포인터 사용과 메모리 누수, 배열 범위 초과 같은 오류가 발생할 수 있다. Linux에서는 실행 중 프로그램의 메모리 동작을 검사하는 여러 도구를 사용할 수 있다.

Valgrind의 Memcheck는 프로그램을 가상 실행 환경에서 실행하여 초기화되지 않은 메모리 사용과 잘못된 읽기·쓰기, 메모리 누수 등을 찾는다. 상세한 정보를 제공하지만 프로그램 실행 속도가 크게 느려질 수 있다.

컴파일러 Sanitizer는 검사 코드를 프로그램에 삽입한다.

• AddressSanitizer — 잘못된 메모리 접근과 객체 수명 오류
• UndefinedBehaviorSanitizer — 정의되지 않은 동작
• ThreadSanitizer — 데이터 경쟁
• MemorySanitizer — 초기화되지 않은 메모리 사용
• LeakSanitizer — 메모리 누수

Sanitizer는 시험과 지속적 통합에서 사용되며, 일반 릴리스 빌드와 별도의 검사 구성을 만드는 경우가 많다.

Electric Fence, Dr. Memory와 여러 할당자 디버깅 기능도 사용할 수 있다. glibc와 jemalloc, mimalloc 같은 메모리 할당자는 통계와 진단 옵션을 제공할 수 있다.

성능 분석

Linux는 CPU와 메모리, 디스크와 네트워크 성능을 분석하는 다양한 도구를 제공한다.

perf는 Linux 커널의 성능 이벤트 하위 시스템을 사용하는 분석 도구다. 하드웨어 성능 카운터와 커널 이벤트, 함수 호출 스택을 수집하여 CPU 시간이 사용된 위치를 분석할 수 있다.

perf stat은 명령 실행 중 명령 수와 캐시 실패, 분기 예측 등의 통계를 수집하고, perf record와 perf report는 샘플링 프로파일을 기록하고 표시한다.

그 밖의 도구에는 다음과 같은 것들이 있다.

• time — 명령 실행 시간과 자원 사용량
• top, htop, btop — 프로세스와 시스템 자원
• vmstat — 프로세스, 메모리와 입출력 통계
• iostat — 블록 장치 성능
• pidstat — 프로세스별 CPU와 입출력
• sar — 시스템 활동 기록
• iftop, nethogs — 네트워크 사용량
• iotop — 프로세스별 저장 장치 입출력
• FlameGraph — 호출 스택 표본 시각화
• Heaptrack — 힙 할당 추적
• Hotspot — perf 자료의 그래픽 분석
• Callgrind와 KCachegrind — 호출 관계와 비용 분석
• Tracy — 실시간 프레임 및 영역 프로파일링
• sysprof — GNOME 계열 시스템 프로파일러

성능 분석은 프로그램 내부의 계산뿐 아니라 시스템 호출과 스케줄링, 페이지 폴트, 캐시, 네트워크와 저장 장치 대기 시간을 함께 고려해야 한다.

ftrace와 eBPF

ftrace는 Linux 커널 내부 함수와 이벤트를 추적하는 기반이다. 커널 함수 호출과 스케줄러 이벤트, 인터럽트와 지연 시간을 기록할 수 있으며 /sys/kernel/tracing 인터페이스와 여러 상위 도구를 통해 사용된다.

eBPF는 검증된 프로그램을 커널의 여러 지점에서 실행하여 네트워크 처리, 시스템 호출, 추적과 보안 정책에 활용할 수 있게 한다.

eBPF 기반 개발 및 관측 도구에는 다음과 같은 것들이 있다.

• BCC
• bpftrace
• libbpf
• bpftool
• Cilium
• 여러 성능 및 보안 관측 플랫폼

bpftrace는 추적 지점과 kprobe, uprobe 등에 짧은 스크립트를 연결해 커널과 사용자 프로그램의 동작을 분석한다. libbpf와 CO-RE는 eBPF 프로그램을 작성하고 여러 커널 구성에서 실행하는 기반을 제공한다.

eBPF는 강력하지만 커널 버전과 권한, 검증기 규칙과 보안 정책의 영향을 받는다. 일반 응용 프로그램 개발자가 항상 직접 사용할 필요는 없으며, 성능 분석과 네트워크, 보안 도구의 내부 구현으로 사용되기도 한다.

정적 분석과 코드 품질

프로그램을 실행하지 않고 소스 코드와 중간 표현을 분석하는 도구도 Linux 개발 환경의 일부다.

• Clang-Tidy
• Clang Static Analyzer
• GCC의 정적 분석 기능
• Cppcheck
• Coverity
• CodeQL
• Semgrep
• Infer
• Sparse
• Smatch
• Coccinelle

Sparse는 Linux 커널 코드의 주소 공간 표시와 타입 사용을 검사하는 데 사용된다. Coccinelle은 의미적 패치 언어를 이용해 C 코드의 반복 패턴을 찾고 변환할 수 있으며, 커널 API 변경과 오류 패턴 탐지에 사용된다.

코드 형식 도구에는 clang-format, astyle, uncrustify, rustfmt, Black과 Prettier 등이 있다. 프로젝트는 CI에서 형식과 정적 분석 결과를 검사해 코드 스타일과 기본 품질 기준을 유지할 수 있다.

시험과 지속적 통합

Linux 프로젝트는 언어별 시험 프레임워크와 셸 스크립트, 가상 머신과 컨테이너를 조합해 자동 시험 환경을 구성한다.

C와 C++에서는 다음과 같은 시험 도구가 사용된다.

• CTest
• GoogleTest
• Catch2
• Boost.Test
• Criterion
• CMocka
• Unity

커널과 시스템 소프트웨어는 별도의 가상 머신에서 부팅 시험을 수행하거나 QEMU를 사용해 여러 아키텍처와 구성을 시험할 수 있다. KUnit은 Linux 커널 내부 단위 시험을 지원하며, kselftest는 사용자 공간에서 커널 기능을 검증하는 시험 집합을 제공한다.

지속적 통합 환경에는 다음과 같은 서비스와 도구가 사용된다.

• GitHub Actions
• GitLab CI/CD
• Jenkins
• Buildbot
• Cirrus CI
• Zuul
• Woodpecker CI
• 자체 빌드 팜

CI는 소스가 변경될 때 빌드와 시험, 정적 분석과 패키지 생성을 자동으로 수행한다. 여러 배포판과 컴파일러, 프로세서 아키텍처를 행렬 형태로 시험할 수도 있다.

커널과 모듈 개발

Linux 커널 개발은 일반 사용자 공간 프로그램과 다른 빌드 및 실행 환경을 요구한다. 커널은 자체 Kbuild 체계를 사용하며, Kconfig를 통해 빌드할 기능과 드라이버를 선택한다.

커널 개발 환경에는 일반적으로 다음 도구가 사용된다.

• GCC 또는 Clang
• GNU Make
• Binutils 또는 LLVM 도구
• Git
• bc, flex와 bison
• pahole
• cpio
• QEMU
• GDB
• Sparse
• Coccinelle
• objtool
• perf와 ftrace
• KUnit과 kselftest
• syzkaller

외부 커널 모듈은 설치된 커널의 빌드 디렉터리와 Kbuild 인터페이스를 사용해 .ko 파일로 빌드한다. 모듈은 실행 중 적재할 수 있지만, 현재 실행 중인 커널의 구성과 심볼, ABI와 일치해야 한다.

모듈 개발 중 오류는 시스템 전체를 중단시킬 수 있으므로 가상 머신이나 별도의 시험 장비를 사용하는 경우가 많다. QEMU와 KVM을 이용하면 커널 이미지를 빠르게 부팅하고, 중단된 가상 머신을 다시 생성하거나 GDB를 연결할 수 있다.

커널 패치는 코딩 스타일 검사와 빌드, 정적 분석, 여러 자동 시험을 거친다. 세부적인 커널 개발 과정은 Linux 커널에서 다룬다.

임베디드 개발

Linux는 라우터와 자동차, 산업 장비, 텔레비전과 소형 컴퓨터에도 사용되므로 크로스 컴파일과 시스템 이미지 생성 도구가 중요하다.

Buildroot는 Linux 커널과 부트로더, C 라이브러리와 사용자 공간 패키지를 선택해 작은 임베디드 시스템 이미지를 생성한다.

Yocto Project는 레시피와 계층을 이용해 제품별 Linux 배포판과 SDK, 패키지와 이미지를 빌드한다. 여러 하드웨어 제품과 장기간 유지되는 제품 계열에서 재현 가능한 빌드 구성을 관리하는 데 사용된다.

그 밖에도 OpenEmbedded, PTXdist와 OpenWrt 빌드 시스템이 사용된다. 개발자는 U-Boot와 커널, 장치 트리와 루트 파일 시스템을 함께 빌드하고, JTAG와 직렬 콘솔, 네트워크 부팅을 통해 장치를 시험할 수 있다.

QEMU는 실제 보드가 준비되지 않았거나 자동 시험이 필요한 경우 일부 하드웨어를 에뮬레이션한다. 실제 장치에서는 GDB 원격 디버깅과 gdbserver, OpenOCD와 제조사별 디버거를 사용할 수 있다.

패키징

Linux 응용 프로그램은 소스 코드만 제공할 수도 있지만, 사용자가 배포판의 패키지 관리자를 통해 설치할 수 있도록 패키지로 만들어지기도 한다.

주요 패키지 형식과 도구에는 다음이 있다.

• Debian 패키지와 dpkg-buildpackage, debhelper
• RPM과 rpmbuild
• Arch Linux의 PKGBUILD와 makepkg
• Alpine Linux의 APKBUILD와 abuild
• Gentoo의 ebuild
• Nix 표현식
• GNU Guix 패키지 정의

배포판 패키지는 프로그램을 해당 배포판의 파일 구조와 라이브러리, 보안 및 업데이트 체계에 통합한다. 소스에서 직접 설치하는 것과 달리 패키지 관리자가 설치 파일과 의존성, 업그레이드와 제거를 추적할 수 있다.

배포판과 독립적인 형식으로는 Flatpak, Snap과 AppImage가 사용된다. Flatpak은 런타임과 샌드박스, 포털을 이용해 데스크톱 응용 프로그램을 여러 배포판에 제공한다. AppImage는 응용 프로그램과 필요한 파일을 하나의 실행 가능한 이미지로 묶는 방식을 사용한다.

재현 가능한 개발 환경

Linux 배포판의 패키지는 시스템 전체에 설치되는 경우가 많으므로, 서로 다른 프로젝트가 요구하는 라이브러리와 컴파일러 버전이 충돌할 수 있다. 개발 환경을 격리하고 재현하기 위한 도구가 이를 보완한다.

컨테이너를 이용하면 프로젝트에 필요한 배포판과 패키지를 이미지로 정의할 수 있다. Dockerfile이나 Containerfile은 개발 및 빌드 환경의 설치 절차를 기록하고, CI와 개발 컴퓨터에서 같은 이미지를 사용할 수 있게 한다.

Distrobox와 Toolbox는 Podman 또는 다른 컨테이너 기술 위에서 호스트 데스크톱과 긴밀하게 연결된 개발용 배포판 환경을 제공한다. 사용자는 현재 배포판을 변경하지 않고 다른 배포판의 컴파일러와 패키지를 사용할 수 있다.

Nix와 GNU Guix는 패키지와 개발 환경을 선언적으로 구성한다. 동일한 정의에서 특정 컴파일러와 라이브러리 버전을 다시 준비하고, 여러 버전을 함께 설치할 수 있다.

direnv는 디렉터리에 들어갈 때 프로젝트별 환경 변수를 적용하고 나갈 때 해제한다. Python의 가상 환경, Rust toolchain 관리자, SDKMAN과 언어별 버전 관리자도 프로젝트별 언어 환경을 분리한다.

문서와 매뉴얼

Linux 개발 환경에서는 프로그램의 사용법과 시스템 인터페이스가 로컬 문서로 제공되는 경우가 많다.

man은 명령과 시스템 호출, 라이브러리 함수와 설정 파일의 매뉴얼 페이지를 표시한다. Linux man-pages 프로젝트는 커널과 C 라이브러리의 여러 사용자 공간 인터페이스를 문서화한다.

GNU 프로그램은 Info 형식의 자세한 매뉴얼을 제공하기도 한다. info 명령으로 계층형 문서를 읽을 수 있으며, 웹에서도 같은 매뉴얼을 제공하는 경우가 많다.

apropos와 man -k는 설명에서 관련 매뉴얼을 검색한다. Devhelp는 GNOME과 GTK 계열 API 문서를 검색하고 표시하며, Qt Assistant와 IDE의 문서 통합은 Qt API를 탐색한다.

Doxygen, Sphinx, MkDocs, rustdoc, Javadoc와 여러 문서 생성기는 소스 코드와 문서 파일에서 API 및 프로젝트 문서를 만든다.

터미널과 개발자 사용자화

Linux 개발자는 터미널을 단순한 명령 입력 창이 아니라 장시간 사용하는 작업 환경으로 구성하기도 한다.

터미널 에뮬레이터에는 다음과 같은 것들이 있다.

• Konsole
• GNOME Console과 GNOME Terminal
• Kitty
• Alacritty
• WezTerm
• Foot
• Tilix
• Terminator
• XTerm

개발자는 글꼴과 색상, 투명도와 배경, 탭과 분할 화면을 설정한다. Nerd Fonts와 아이콘 글꼴은 프롬프트와 파일 목록에 기호를 표시하는 데 사용된다.

프롬프트 도구와 프레임워크에는 다음과 같은 것들이 있다.

• Starship
• Powerlevel10k
• Oh My Zsh
• Prezto
• Oh My Posh
• Bash-it

프롬프트에는 현재 디렉터리와 Git 브랜치, 변경 상태, 실행 중인 언어 환경과 이전 명령의 결과가 표시될 수 있다. 지나치게 많은 정보를 표시하면 셸 시작과 디렉터리 이동이 느려질 수 있어 필요한 항목만 선택하기도 한다.

데스크톱 꾸미기와 dotfiles

Linux 데스크톱은 창 관리자와 패널, 테마와 단축키를 폭넓게 변경할 수 있다. 일부 개발자는 개발 도구 자체만큼 작업 환경의 배치와 외형을 세밀하게 관리한다.

KDE Plasma와 GNOME 같은 완전한 데스크톱 환경을 사용할 수도 있고, i3, Sway, Hyprland, Awesome과 dwm 같은 타일링 창 관리자를 사용할 수도 있다.

타일링 환경에서는 창을 키보드로 배치하고 작업 공간마다 터미널과 편집기, 브라우저를 정해진 위치에 놓을 수 있다. Waybar, Polybar, Rofi, Wofi와 여러 알림 데몬을 조합해 독자적인 데스크톱 환경을 만들기도 한다.

셸과 편집기, 터미널, Git과 창 관리자의 설정 파일을 모은 저장소를 흔히 dotfiles라고 한다. 사용자는 Git 저장소와 심볼릭 링크 관리 도구, GNU Stow, chezmoi 또는 yadm을 이용해 여러 컴퓨터에 같은 설정을 배포한다.

이러한 사용자화는 개발에 필수적이지 않지만, Linux 환경을 자신의 작업 흐름에 맞게 조정할 수 있다는 점을 보여준다. 설정에 지나치게 많은 시간이 들어가는 현상 자체도 Linux 데스크톱 문화에서 농담의 소재가 된다.

시스템 정보와 화면 장식

Linux 사용자는 터미널을 열었을 때 배포판 로고와 하드웨어, 커널과 데스크톱 환경 정보를 표시하는 프로그램을 사용하기도 한다.

Fastfetch는 운영체제와 커널, CPU와 GPU, 메모리, 데스크톱과 터미널 정보를 로고와 함께 표시하는 도구다. Neofetch와 유사한 용도를 가지며 성능과 기능 확장을 목표로 개발되었다.^[71]

Screenfetch, Pfetch와 Onefetch 같은 도구도 존재한다. Onefetch는 시스템 대신 Git 저장소의 언어 구성과 커밋, 라이선스 등의 정보를 표시한다.

이러한 프로그램은 개발 과정에 필수적인 정보를 제공한다기보다 시스템 상태를 빠르게 확인하거나 화면 캡처에 자신의 환경을 보여주는 데 사용된다. 로고와 색상, 사용자 지정 그림을 넣어 데스크톱과 터미널 디자인의 일부로 활용하기도 한다.

장난감 명령과 개발자 문화

Linux와 UNIX 계열에는 실용적인 목적이 거의 없거나, 기존 명령의 출력을 재미있게 꾸미기 위해 만들어진 프로그램도 많다. 이러한 도구는 시스템 개발에 필수적이지 않지만, 작은 프로그램을 자유롭게 조합하는 명령줄 문화와 개발자들의 유머를 보여준다.

cowsay는 입력한 문장을 말풍선 안에 넣고 ASCII 소나 다른 동물이 말하는 형태로 출력한다. 기본 소뿐 아니라 펭귄과 용, 유령과 여러 그림을 선택할 수 있으며, 다른 명령의 출력을 파이프로 전달하는 데 사용된다.

fortune은 짧은 문장과 농담, 격언을 임의로 출력한다. fortune | cowsay처럼 결합하면 소가 무작위 문장을 말하게 할 수 있다.

lolcat은 입력 텍스트에 무지개색을 입혀 출력한다. 빌드 결과나 배너를 보기 좋게 만들 수도 있지만, 오류 메시지의 색상 의미를 망가뜨릴 수 있으므로 실제 자동화 로그에는 적합하지 않을 수 있다.

cmatrix는 터미널에 영화 《매트릭스》를 연상시키는 문자가 흘러내리는 화면을 표시한다. 시스템을 분석하거나 개발하는 기능은 없지만 터미널 화면 장식과 시연에 사용된다.

그 밖에도 다음과 같은 도구가 있다.

• sl — ls를 잘못 입력하면 기차가 지나가는 프로그램
• nyancat — 터미널에서 Nyan Cat 애니메이션 표시
• asciiquarium — ASCII 수족관
• pipes.sh — 터미널에 움직이는 파이프 무늬 표시
• hollywood — 여러 가짜 시스템 분석 화면을 분할해 영화 속 해킹 장면처럼 표시
• boxes — 텍스트 둘레에 ASCII 상자 생성
• figlet과 toilet — 큰 ASCII 문자 생성
• ponysay — 조랑말 캐릭터가 문장을 말하도록 표시
• cbonsai — 터미널에서 분재 나무 성장
• genact — 무언가 중요한 작업을 수행하는 것처럼 보이는 가짜 활동 출력
• oneko — 화면에서 고양이가 마우스 포인터를 따라다니도록 표시
• XScreenSaver의 여러 화면 보호기

이 프로그램들은 패키지 저장소를 통해 실제로 설치할 수 있는 경우가 많다. 일부는 프로그래밍 연습이나 작은 오픈 소스 프로젝트로 시작했고, 이후 여러 구현과 변형이 만들어졌다.

고양이를 활용한 도구도 많다. cat은 본래 파일 내용을 연결하여 출력하는 실용적인 UNIX 명령이지만 이름 때문에 고양이 그림과 결합한 농담이 생겼다. bat은 cat과 유사한 파일 출력에 구문 강조와 Git 변경 표시를 더하고, nyancat은 오직 움직이는 고양이 그림을 보여준다. oneko는 데스크톱 위에서 고양이가 포인터를 추적한다.

이러한 도구는 Linux가 업무용 서버 운영체제일 뿐 아니라 사용자가 직접 작은 프로그램을 만들고 서로 공유하는 개인 컴퓨팅 환경이라는 면을 보여준다.

현대적인 명령줄 대체 도구

일부 프로그램은 전통적인 UNIX 명령을 완전히 없애기보다, 대화형 사용과 시각적 출력을 개선한 대체 도구로 개발되었다.

• bat — 구문 강조와 Git 통합을 제공하는 파일 출력
• eza — 파일 종류와 Git 상태, 트리 출력을 지원하는 디렉터리 목록
• fd — 간단한 기본값을 가진 파일 검색
• ripgrep — 빠른 재귀 텍스트 검색
• dust — 디렉터리별 디스크 사용량 시각화
• duf — 파일 시스템 사용량을 표 형태로 표시
• procs — 프로세스 목록을 읽기 쉽게 표시
• bottom — 시스템 자원 모니터
• delta — Git diff와 일반 diff를 구문 강조하여 표시
• fzf — 범용 퍼지 선택기
• zoxide — 사용 기록을 이용한 디렉터리 이동
• tldr — 자주 사용하는 명령 예제를 짧게 제공

이 도구들은 스크립트 호환성을 위해 기존 명령을 그대로 대체하기보다 대화형 셸에서 별도 이름으로 사용하는 경우가 많다. 전통적인 POSIX 도구는 거의 모든 UNIX 환경에서 사용할 수 있지만, 현대적인 도구는 더 풍부한 출력과 편리한 기본값을 제공하는 대신 추가 설치가 필요하다.

개발 환경의 선택

Linux 개발에 필요한 최소 도구는 개발 대상에 따라 달라진다. C 프로그램이라면 편집기와 컴파일러, 링커와 빌드 도구가 기본이 되고, Python 스크립트라면 인터프리터와 가상 환경 도구만으로 시작할 수 있다. 커널 개발에는 전용 빌드 의존성과 가상 머신, 추적 및 정적 분석 도구가 추가된다.

대규모 프로젝트에서는 다음과 같은 조합이 일반적이다.

• Git으로 소스와 변경 이력 관리
• GCC 또는 Clang으로 컴파일
• CMake나 Meson으로 빌드 정의
• Ninja 또는 Make로 실제 빌드 실행
• GDB와 Sanitizer로 오류 분석
• perf와 eBPF 도구로 성능 분석
• CI에서 여러 배포판과 컴파일러 시험
• 패키지 또는 컨테이너 이미지로 결과 배포

개인 개발자는 편집기와 셸 프롬프트, 터미널과 데스크톱을 자유롭게 구성할 수 있다. 최소한의 콘솔 환경에서 Vim과 Make만 사용할 수도 있고, 그래픽 IDE와 컨테이너 기반 개발 환경, 여러 자동화 도구를 결합할 수도 있다.

Linux 개발 환경의 특징은 모든 기능이 하나의 제품 안에 고정되어 있다는 데 있지 않다. 오래된 UNIX 명령과 현대적인 언어 서버, 대형 IDE와 작은 셸 도구, 산업용 성능 분석기와 고양이가 화면을 뛰어다니는 장난감 프로그램까지 같은 시스템에서 선택적으로 조합할 수 있다는 데 있다.

Linux 기반 운영체제의 중심이 되는 Linux 커널은 하나의 기업이나 고정된 개발 조직이 독점적으로 만드는 제품이 아니다. 개인 개발자와 대학, 반도체·하드웨어 제조사, Linux 배포판 업체, 클라우드 사업자와 여러 산업 분야의 기업이 공동으로 개발한다.

개발자는 자신이 필요로 하는 장치 드라이버와 파일 시스템, 프로세서 지원, 네트워크 기능과 오류 수정을 제안할 수 있다. 다만 제안된 코드가 곧바로 공식 Linux 커널에 포함되는 것은 아니다. 각 변경은 관련 하위 시스템의 공개적인 검토 절차와 유지관리자 저장소를 거쳐 최종 메인라인에 통합된다.

Linux 커널 개발은 중앙에서 모든 개발자에게 작업을 배정하는 방식보다, 하위 시스템별 개발 공동체와 유지관리자가 각 영역을 책임지는 분산형 구조에 가깝다. 최종 릴리스는 하나의 메인라인 저장소에서 만들어지지만, 실제 개발과 검토는 여러 메일링 리스트와 Git 저장소에서 병렬로 진행된다.

커널 내부 구현과 소스 디렉터리, 빌드 방법과 프로그래밍 인터페이스에 관한 자세한 내용은 Linux 커널에서 다룬다.

개발 주체

Linux 커널 개발에는 서로 다른 배경과 목적을 가진 개발자가 참여한다.

• 개인 개발자와 자원봉사자
• 대학과 연구 기관
• Linux 배포판 개발자
• 반도체와 프로세서 제조사
• 서버·저장 장치·네트워크 장비 제조사
• 스마트폰과 임베디드 장치 제조사
• 클라우드와 데이터 센터 사업자
• 자동차와 산업 시스템 기업
• 보안 연구자
• 컨설팅 및 커널 개발 전문 기업

초기 Linux는 리누스 토르발스 개인이 중심이 되어 개발했지만, 지원하는 하드웨어와 기능이 늘면서 한 사람이 전체 코드를 직접 검토하고 관리할 수 없는 규모로 성장했다. 이에 따라 파일 시스템과 네트워크, 프로세서 아키텍처, 장치 드라이버 등 각 영역을 담당하는 유지관리자 구조가 형성되었다.

기업 개발자는 자사 제품에서 필요한 기능을 구현하거나 성능과 안정성 문제를 해결하기 위해 커널 개발에 참여한다. 반도체 제조사는 새로운 프로세서와 전원 관리 기능을 지원하고, 장치 제조사는 드라이버를 개발하며, 클라우드 기업은 가상화와 네트워크, 자원 관리와 대규모 시스템 성능을 개선할 수 있다.

기업이 작성한 코드도 공식 커널에 포함되려면 일반적으로 공개 검토와 유지관리자의 승인을 거쳐야 한다. 기업 내부에만 별도 수정본을 유지할 수도 있지만, 공식 커널에 통합하면 새 버전이 나올 때마다 같은 변경을 다시 적용해야 하는 부담을 줄이고 다른 개발자의 검토와 공동 유지보수를 받을 수 있다.

Linux 커널 프로젝트에 참여하는 개발자는 고용 관계와 관계없이 동일한 패치 형식과 검토 절차를 사용한다. 다만 장기간 개발에 참여하는 전임 개발자가 많은 코드를 작성하고 유지할 수 있으므로, 실제 기여량에서는 커널 개발자를 고용한 기업이 큰 비중을 차지할 수 있다.

리누스 토르발스의 역할

리누스 토르발스는 Linux 커널 프로젝트를 시작한 개발자이자 메인라인 커널의 최종 통합을 담당하는 수석 유지관리자다.

토르발스는 현재 커널의 모든 패치를 직접 처음부터 검토하지 않는다. 대부분의 변경은 먼저 관련 하위 시스템의 개발자와 유지관리자가 검토하고, 여러 단계의 저장소를 거쳐 정리된 Git 변경 묶음으로 전달된다.

토르발스는 최상위 유지관리자들이 보낸 pull 요청을 검토하고 메인라인 저장소에 병합한다. 이 단계에서는 다음과 같은 요소가 고려된다.

• 변경이 충분한 하위 시스템 검토를 거쳤는가
• 병합 시점이 현재 릴리스 주기에 적절한가
• 다른 하위 시스템과 충돌하지 않는가
• 기존 사용자 공간과의 호환성을 훼손하지 않는가
• 변경 규모와 위험에 맞는 시험이 이루어졌는가
• 회귀나 설계상 문제가 보고되지 않았는가
• 제출자와 유지관리자 사이에 변경 이력이 명확한가

Linux 커널 개발은 넓게 분산되어 있지만 마지막 메인라인 병합은 중앙화되어 있다. 공식 문서는 100명이 넘는 유지관리자가 각자의 저장소에서 변경을 관리하며, 마지막 단계에서 메인라인 저장소로 병합된다고 설명한다. 이 작업은 일반적으로 토르발스가 수행하지만, 2018년 Linux 4.19 개발 당시에는 그레그 크로아하트먼이 임시로 최종 통합을 맡은 사례도 있다.^[72]

토르발스가 모든 안정·장기지원 버전을 직접 유지하는 것은 아니다. 메인라인 이후의 안정 계열은 별도의 안정 커널 유지관리자들이 담당한다.

하위 시스템

Linux 커널은 하나의 소스 트리로 배포되지만 개발 과정에서는 여러 하위 시스템으로 나뉜다.

대표적인 영역에는 다음과 같은 것들이 있다.

• 프로세서 아키텍처
• 프로세스 스케줄러
• 메모리 관리
• 가상 파일 시스템
• 개별 파일 시스템
• 블록 장치와 저장 장치
• 네트워크 스택
• 그래픽과 DRM
• USB와 PCI
• 입력 장치
• 사운드
• 보안
• 가상화
• eBPF
• 전원 관리
• 플랫폼과 장치 드라이버
• 문서와 개발 도구

각 하위 시스템은 자체 메일링 리스트와 유지관리자, Git 저장소와 패치 처리 규칙을 가질 수 있다. 규모가 큰 하위 시스템은 다시 여러 하위 영역과 드라이버별 유지관리자로 나뉜다.

예를 들어 특정 네트워크 장치 드라이버의 변경은 먼저 해당 드라이버 또는 네트워크 영역의 유지관리자에게 전달된다. 검토와 시험을 통과한 패치는 네트워크 하위 시스템 저장소에 들어가고, 이후 메인라인 병합을 위한 pull 요청에 포함될 수 있다.

이 계층은 토르발스가 모든 세부 하드웨어와 기능의 전문가가 될 필요 없이, 해당 영역의 경험을 가진 개발자가 먼저 품질과 설계를 검토할 수 있게 한다.

유지관리자

유지관리자는 특정 파일이나 드라이버, 하위 시스템 또는 릴리스 계열의 개발과 변경 통합을 책임지는 개발자다.

유지관리자는 단순히 기존 코드를 보존하는 역할만 하지 않는다. 일반적으로 다음과 같은 일을 수행한다.

• 새 패치 검토
• 설계와 인터페이스에 대한 의견 제시
• 오류 보고와 회귀 확인
• 수정 버전 재제출 요청
• 관련 개발자와 검토자 연결
• 패치가 적용되는 순서와 의존 관계 관리
• 하위 시스템 Git 저장소 운영
• 다음 메인라인 릴리스에 보낼 변경 정리
• 장기적인 코드 품질과 호환성 관리
• 관리가 중단된 코드의 후임 유지관리자 탐색

유지관리자가 모든 코드를 직접 작성할 필요는 없다. 해당 영역의 변경을 이해하고 적절한 검토자를 찾으며, 어떤 변경을 공식 저장소에 받아들일지 판단하는 역할이 중요하다.

커널 소스의 MAINTAINERS 파일에는 각 영역의 유지관리자와 검토자, 메일링 리스트, 관련 파일 경로와 Git 저장소가 기록된다. 개발자는 scripts/get_maintainer.pl을 사용해 수정한 파일과 커밋 이력을 바탕으로 패치를 보낼 대상과 목록을 찾을 수 있다.

유지관리자는 프로젝트의 중앙 조직이 임명하는 고정된 직급이라기보다, 해당 영역에 지속적으로 기여하고 검토와 관리 책임을 맡으면서 형성되는 역할이다. 기존 유지관리자가 새로운 공동 유지관리자를 추가하거나 책임을 넘길 수 있으며, 관리되지 않는 영역에는 새로운 개발자가 유지관리자로 나설 수 있다.

하위 시스템마다 개발 속도와 위험, 사용자층과 기술 구조가 다르기 때문에 세부 절차도 달라질 수 있다. 커널 문서는 일반 개발 절차와 별도로 네트워크, SoC와 여러 유지관리자 트리의 추가 규칙을 제공한다.^[73]

패치 작성과 제출

Linux 커널의 변경은 일반적으로 패치 단위로 제출된다. 패치는 코드 차이뿐 아니라 변경 이유와 문제 상황, 해결 방식, 시험 결과와 관련 정보를 포함한다.

패치 설명은 단순히 무엇을 바꾸었는지만 적기보다 다음 내용을 밝히는 것이 권장된다.

• 기존 코드에서 발생한 문제
• 그 문제가 실제로 미치는 영향
• 선택한 해결 방식
• 다른 해결 방법과의 차이
• 사용자 공간 호환성에 미치는 영향
• 시험한 환경과 결과
• 관련 오류 보고와 커밋
• 안정 커널에 적용할 필요가 있는지 여부

하나의 큰 기능은 검토 가능한 여러 패치로 나누어 패치 시리즈로 제출할 수 있다. 각 패치는 가능한 한 독립적인 목적을 가져야 하며, 이전 패치가 적용된 상태에서 순서대로 빌드되고 동작할 수 있도록 구성하는 것이 일반적이다.

커널 프로젝트는 Git을 사용하지만, 대부분의 하위 시스템에서는 웹사이트의 pull request보다 이메일을 통한 패치 제출과 검토가 중심이다. 개발자는 git format-patch로 커밋을 이메일 패치로 만들고 git send-email로 유지관리자와 관련 공개 메일링 리스트에 보낼 수 있다.

패치에는 작성자 서명을 나타내는 Signed-off-by 줄이 포함된다. 이는 개발자가 해당 기여물을 제출할 권리가 있으며 개발자 기원 증명서의 조건에 동의한다는 표시다.

Signed-off-by는 코드가 충분히 검토되었다는 의미와는 다르다. 검토 과정에서는 다음과 같은 별도 태그가 추가될 수 있다.

• Reviewed-by — 검토자가 코드를 검토하고 동의함
• Acked-by — 해당 변경에 동의함
• Tested-by — 특정 환경에서 시험함
• Reported-by — 문제를 처음 보고한 사람
• Suggested-by — 해결 방향을 제안한 사람
• Fixes — 문제가 시작된 이전 커밋
• Cc: stable — 안정 커널 적용 검토 요청

이러한 태그는 변경이 어떤 검토와 시험을 거쳤는지 추적하는 데 사용된다.

공개 검토

제출된 패치는 관련 개발자와 유지관리자가 공개 메일링 리스트에서 검토한다. 검토자는 코드 스타일만이 아니라 설계와 동시성, 메모리 수명, 오류 처리, 성능, 보안과 사용자 공간 호환성을 확인할 수 있다.

검토 과정에서 문제가 발견되면 개발자는 의견을 반영한 새 버전을 제출한다. 패치 제목에 v2, v3와 같은 버전이 표시될 수 있으며, 이전 버전에서 무엇을 바꾸었는지도 함께 설명한다.

패치가 제출되었다고 해서 반드시 답변이나 채택이 보장되는 것은 아니다. 관련 유지관리자가 바쁘거나 패치의 대상과 제출 방식이 잘못되었을 수 있으며, 변경의 필요성과 설계에 대한 합의가 부족할 수도 있다.

대규모 기능은 코드를 완성한 뒤 처음 공개하기보다 설계 단계부터 관련 공동체와 논의하는 경우가 많다. 초기 제안은 RFC 형태로 제출하여 구현 방향과 인터페이스에 대한 의견을 받을 수 있다.

공개 검토는 코드의 오류를 찾는 과정인 동시에 장기적으로 유지할 수 있는 설계를 결정하는 과정이다. 커널에 포함된 인터페이스는 여러 배포판과 장치, 응용 프로그램이 의존할 수 있으므로, 당장의 기능 구현보다 이후 호환성과 유지 비용이 중요하게 다뤄진다.

유지관리자 저장소와 병합 경로

검토를 통과한 패치는 관련 유지관리자의 Git 저장소에 적용된다. 다만 모든 패치가 한 단계만 거쳐 토르발스에게 전달되는 것은 아니다.

규모가 큰 영역에서는 다음과 같은 경로가 형성될 수 있다.

1. 드라이버 또는 세부 영역 유지관리자가 패치를 받는다.
2. 패치가 세부 유지관리자 저장소에서 시험된다.
3. 상위 하위 시스템 유지관리자가 변경을 가져온다.
4. 하위 시스템 통합 저장소에서 다른 변경과 함께 시험한다.
5. 병합 창에 최상위 유지관리자가 토르발스에게 pull 요청을 보낸다.
6. 토르발스가 변경을 메인라인 저장소에 병합한다.

각 단계에서 패치의 원래 작성자와 검토자, 적용한 유지관리자의 서명과 Git 이력이 유지된다. 이를 통해 코드가 어떤 경로로 공식 커널에 들어왔는지 추적할 수 있다.

하위 시스템 저장소에는 개발 중인 기능을 위한 브랜치와 현재 릴리스의 긴급 수정 브랜치가 따로 존재할 수 있다. 새 기능은 다음 병합 창을 기다리는 반면, 심각한 회귀 수정은 현재 릴리스 후보 기간에 전달될 수 있다.

linux-next

여러 유지관리자가 서로 독립적으로 개발하면 각 저장소에서는 정상적으로 빌드되던 변경이 메인라인에 함께 병합될 때 충돌하거나 오류를 일으킬 수 있다.

linux-next는 다음 메인라인 병합 창에 들어갈 가능성이 높은 여러 하위 시스템 저장소를 미리 통합하는 시험용 커널 트리다. 유지관리자는 자신의 변경을 linux-next에 포함시켜 다른 하위 시스템과의 충돌과 빌드 오류, 통합 문제를 병합 창 이전에 발견할 수 있다.

linux-next는 다음 정식 Linux 릴리스가 아니며 안정적인 운영 환경을 위한 커널도 아니다. 향후 병합 후보를 조기에 결합하여 시험하는 개발용 통합 지점이다.

자동 빌드와 부팅 시험 시스템은 linux-next와 여러 유지관리자 트리를 다양한 아키텍처와 구성으로 시험한다. 발견된 문제는 해당 패치를 작성하거나 관리하는 개발자에게 보고된다.

메인라인 릴리스 주기

Linux 커널의 메인라인 개발은 대체로 시간 기반의 반복 주기를 따른다. 새로운 메인라인 버전은 현재 일반적으로 약 9~10주마다 공개된다.^[74]

한 릴리스 주기는 크게 병합 창과 릴리스 후보 기간으로 나뉜다.

새 메인라인 버전이 공개되면 약 2주 동안 다음 버전을 위한 병합 창이 열린다. 이 기간에 각 하위 시스템 유지관리자는 이전 개발 주기 동안 검토하고 시험한 기능과 큰 변경을 토르발스에게 보낸다.

병합 창에는 일반적으로 다음과 같은 변경이 들어간다.

• 새로운 장치와 프로세서 지원
• 새 파일 시스템 및 네트워크 기능
• 주요 하위 시스템 개선
• 내부 API와 구조 변경
• 많은 파일에 영향을 주는 정리 작업
• 다음 버전의 전체 기능 기반

병합 창이 끝나면 토르발스는 첫 번째 릴리스 후보인 -rc1을 공개한다. 이후에는 새로운 대형 기능보다 오류와 회귀 수정에 집중한다.

보통 매주 새로운 릴리스 후보가 공개된다.

• -rc1
• -rc2
• -rc3
• …
• 정식 버전

대부분의 개발 주기는 약 7개 또는 8개의 릴리스 후보를 거친다. 문제가 많거나 추가 시험이 필요한 경우 더 많은 릴리스 후보가 나올 수 있다.

릴리스 후보 기간에 심각한 문제가 발견되면 변경을 수정하거나 메인라인에서 되돌릴 수 있다. 정식 버전은 알려진 모든 오류가 사라졌다는 선언이라기보다, 새 기능 병합을 마치고 다음 안정화·개발 단계로 넘어갈 수 있다고 판단한 시점의 메인라인 상태다.

병합 창

병합 창은 새로운 아이디어를 처음 제출하는 2주가 아니다. 큰 기능은 병합 창이 열리기 오래전부터 관련 메일링 리스트에서 개발과 검토를 거쳐야 한다.

유지관리자는 충분히 검토되지 않았거나 linux-next에서 시험되지 않은 대형 변경을 병합 창에 갑자기 제출하지 않는 것이 일반적이다. 병합 창은 이미 준비된 하위 시스템 변경을 메인라인에 통합하는 기간에 가깝다.

병합 창 이후에도 모든 변경이 금지되는 것은 아니다. 현재 버전에서 발견된 오류와 회귀, 문서 수정과 위험이 작은 수정은 릴리스 후보 기간에 계속 들어갈 수 있다. 다만 릴리스가 가까워질수록 허용되는 변경의 범위와 위험은 줄어든다.

이 구조는 개발 속도를 지나치게 늦추지 않으면서도 기능 통합과 안정화 시점을 구분한다. 개발자는 다음 버전을 위한 기능을 하위 시스템 저장소에서 계속 준비할 수 있고, 메인라인은 현재 버전의 오류 수정에 집중할 수 있다.

회귀

Linux 커널 개발에서 회귀는 이전 버전에서 정상 작동하던 기능이 새 변경 이후 작동하지 않게 되는 현상을 뜻한다.

회귀에는 다음과 같은 사례가 포함될 수 있다.

• 기존 하드웨어가 부팅되지 않음
• 장치 드라이버가 작동하지 않음
• 성능이나 전력 소비가 크게 악화됨
• 응용 프로그램이 사용하는 인터페이스가 달라짐
• 파일이나 네트워크 동작이 변경됨
• 시스템 중단과 데이터 손상이 발생함

Linux 커널은 기존 사용자 공간 프로그램을 깨뜨리지 않는 것을 중요한 원칙으로 삼는다. 따라서 설계상 더 깔끔한 변경이라도 기존 프로그램과 운영 환경에 실제 문제를 일으키면 수정하거나 되돌릴 수 있다.

회귀가 보고되면 관련 변경을 찾고 수정하는 작업이 현재 릴리스의 새 기능보다 우선될 수 있다. 원인을 즉시 해결하기 어려우면 문제를 일으킨 커밋을 되돌리고 이후 개발 주기에 다시 설계할 수도 있다.

정식 메인라인 버전

릴리스 후보 기간이 끝나면 토르발스는 6.x 형태의 새 메인라인 버전을 공개한다. 이 버전은 해당 개발 주기의 기능과 수정 사항을 포함한 기준점이 된다.

메인라인 버전 번호의 첫 번째 숫자가 바뀌는 것은 반드시 근본적인 기술 단절이나 호환성 파괴를 의미하지 않는다. Linux 3.0과 4.0, 5.0과 6.0으로의 변경은 버전 번호가 지나치게 커지는 것을 피하기 위한 관리상의 선택에 가까웠다.

새 메인라인 버전이 나오면 다음 버전의 병합 창이 바로 시작된다. 동시에 방금 공개된 버전은 안정 커널 유지관리자에게 넘어가 6.x.1, 6.x.2와 같은 안정 업데이트를 받을 수 있다.

안정 커널

메인라인 버전이 공개된 뒤 발견되는 오류를 수정하기 위해 안정 커널 계열이 유지된다.

안정 커널에는 일반적으로 새로운 기능을 추가하지 않고, 이미 메인라인에 들어간 명확한 오류 수정 가운데 기존 안정 버전에도 필요한 변경을 역이식한다.

안정 커널에 들어갈 수정은 다음과 같은 조건을 요구한다.

• 실제 문제를 수정할 것
• 수정 범위가 작고 명확할 것
• 이미 메인라인에서 받아들여졌을 것
• 사용자에게 영향을 미치는 오류를 고칠 것
• 기존 기능과 인터페이스를 불필요하게 바꾸지 않을 것
• 해당 안정 버전에 실제로 적용 가능한 문제일 것

안정 커널 업데이트는 필요에 따라 공개되며 보통 일주일에 한 번 정도 나올 수 있다. 새 메인라인 버전이 공개되면 직전 일반 안정 계열은 몇 차례의 수정 릴리스 뒤 유지가 종료되는 경우가 많다.^[75]

안정 커널 패치는 공개 검토 기간을 거친다. 안정 유지관리자는 후보 패치 묶음을 발표하고 개발자와 시험자가 문제를 확인할 시간을 제공한 뒤 정식 업데이트를 공개한다.

안정 커널의 수정은 메인라인에 먼저 들어가는 것이 원칙이다. 안정 계열에만 수정하고 메인라인에는 반영하지 않으면 이후 버전에서 같은 오류가 다시 나타날 수 있기 때문이다.^[76]

장기지원 커널

일부 메인라인 버전은 일반 안정 계열보다 오랫동안 유지되는 장기지원 커널로 선정된다. 장기지원 커널은 흔히 LTS 커널이라고 부른다.

장기지원 계열에도 새로운 대형 기능을 계속 추가하는 것이 아니라, 메인라인에서 확인된 중요한 오류와 보안 수정, 필요한 하드웨어 관련 수정을 선별해 역이식한다.

모든 메인라인 버전이 장기지원 버전이 되는 것은 아니다. 특정 릴리스가 장기지원 계열로 선정되는 것은 해당 버전을 유지할 필요와 이를 담당할 유지관리자의 시간과 자원이 있는지에 따라 결정된다. 예정된 미래 버전이 반드시 장기지원 버전이 된다는 고정 규칙은 없다.^[77]

장기지원 커널은 다음과 같은 환경에서 사용될 수 있다.

• 기업용 Linux 배포판
• Android와 스마트폰
• 임베디드와 산업 장비
• 자동차 시스템
• 장기간 운영되는 서버
• 인증과 검증에 오랜 시간이 필요한 제품

장기지원 커널의 공식 유지 기간과 실제 제품 지원 기간은 같지 않을 수 있다. 배포판과 장치 제조사는 공식 장기지원 계열을 기반으로 자체 패치를 추가하고, 상위 커널의 공식 종료 이후에도 별도의 유지보수를 계속할 수 있다.

반대로 장기지원이라는 이름이 모든 드라이버와 기능을 제품 수명 동안 자동으로 지원한다는 뜻은 아니다. 실제 보안과 안정성은 유지관리자, 배포판과 제조사가 필요한 수정 사항을 지속해서 적용하고 제품에 전달하는 과정에 달려 있다.

활성 메인라인·안정·장기지원 계열과 담당 유지관리자, 예상 지원 종료 시점은 kernel.org의 릴리스 목록에서 관리된다.^[78]

안정·장기지원 유지관리자

안정 및 장기지원 커널은 메인라인과 별도의 유지관리자가 담당한다. 이들은 메인라인에서 수정된 패치를 검토하고 각 안정 계열에 적용 가능한지 판단한다.

유지관리자는 같은 오류가 여러 커널 계열에 존재하면 각 버전의 코드 구조에 맞춰 패치를 역이식할 수 있다. 최신 메인라인에 적용된 수정이 오래된 커널에 그대로 적용되지 않으면 추가 조정이 필요하다.

안정 유지관리자는 다음 작업을 수행한다.

• 메인라인 수정 가운데 안정 계열 후보 선별
• Cc: stable 태그와 자동화된 후보 수집 검토
• 이전 커널 코드에 맞춘 역이식
• 빌드와 자동 시험
• 안정 후보 공개와 검토 요청
• 문제 있는 패치 제외 또는 수정
• 안정 업데이트와 변경 기록 발표
• 지원 종료 시점 결정

오래된 계열을 계속 유지할수록 최신 메인라인과 코드 차이가 커지고 패치 역이식이 어려워질 수 있다. 장기지원은 단순히 버전 번호를 보존하는 작업이 아니라 지속적인 검토와 시험, 실제 사용자와 기업의 지원이 필요한 개발 활동이다.

배포판 커널

Debian, Fedora, Ubuntu, Red Hat Enterprise Linux와 SUSE Linux Enterprise 같은 배포판은 kernel.org의 메인라인 커널을 그대로 제공하기보다 자체 정책에 맞춘 배포판 커널을 만든다.

배포판은 특정 메인라인 또는 장기지원 버전을 기반으로 다음 변경을 추가할 수 있다.

• 보안 및 오류 수정 역이식
• 하드웨어 지원 추가
• 배포판 기능과 설치 환경 통합
• 보안 강화 설정
• 특정 기업용 기능
• 성능과 전원 관리 수정
• 패키징과 모듈 서명
• 배포판이 지원하는 커널 ABI 관리

기업용 배포판은 사용자 공간과 제3자 커널 모듈의 호환성을 유지하기 위해 특정 커널 ABI를 장기간 안정적으로 제공할 수 있다. 상위 Linux 커널은 내부 모듈 ABI의 영구적 안정성을 보장하지 않으므로, 이러한 호환 정책은 배포판이 별도로 관리한다.

배포판의 커널 버전 문자열만 보고 포함된 기능과 보안 수정 수준을 정확히 판단하기 어려울 수 있다. 배포판은 전체 버전을 올리지 않고 필요한 패치를 기존 버전에 역이식하기 때문이다.

따라서 실제 시스템의 커널 지원과 보안 상태는 kernel.org 버전뿐 아니라 배포판의 패키지 변경 기록과 보안 권고, 지원 수명 주기를 함께 확인해야 한다.

시험과 자동화

Linux 커널은 수많은 하드웨어와 프로세서 아키텍처, 빌드 설정을 지원하므로 한 개발자나 유지관리자가 모든 조합을 직접 시험할 수 없다.

커널 개발에는 다음과 같은 시험 방식이 사용된다.

• 여러 아키텍처와 설정의 자동 빌드
• 실제 장치와 가상 머신 부팅 시험
• 커널 자체 시험
• 하위 시스템별 시험 모음
• 정적 분석
• Sanitizer와 메모리 검사
• 퍼징
• 성능과 전력 회귀 시험
• linux-next 통합 시험
• 배포판과 기업의 제품 시험

공개된 자동 시험 서비스와 기업 내부 시험 팜은 새 패치와 유지관리자 저장소를 지속적으로 빌드하고 실행한다. 실패가 발생하면 관련 개발자와 메일링 리스트에 보고할 수 있다.

KUnit은 커널 내부 단위 시험을 제공하며, kselftest는 사용자 공간에서 커널 기능과 인터페이스를 시험한다. syzkaller는 시스템 호출 조합을 자동으로 생성하여 커널 충돌과 보안 문제를 찾는다.

자동 시험이 성공했다고 해서 모든 하드웨어와 사용 사례가 검증되는 것은 아니다. Linux가 지원하는 장치와 구성의 수가 매우 많기 때문에 실제 사용자와 배포판, 제조사의 시험과 오류 보고도 릴리스 품질에 중요한 역할을 한다.

버그와 회귀 보고

사용자와 개발자는 커널 문제를 발견하면 영향을 받는 하위 시스템과 유지관리자를 찾아 보고할 수 있다. 많은 커널 문제는 중앙 버그 추적기 하나보다 해당 유지관리자와 공개 메일링 리스트에 직접 전달된다.^[79]

유용한 오류 보고에는 다음 정보가 포함될 수 있다.

• 문제가 발생한 정확한 커널 버전
• 마지막으로 정상 작동한 버전
• 하드웨어와 시스템 구성
• 커널 설정
• 재현 절차
• 커널 로그와 오류 메시지
• 회귀를 일으킨 커밋의 이분 탐색 결과
• 적용한 외부 패치와 배포판 정보
• 문제를 재현하는 최소 프로그램

Git의 bisect 기능을 사용하면 정상 버전과 문제 버전 사이의 커밋을 반복 시험하여 오류가 처음 나타난 변경을 찾을 수 있다. 원인 커밋이 확인되면 해당 작성자와 유지관리자가 문제를 이해하고 수정하기 쉬워진다.

보안 취약점은 일반 오류와 다른 비공개 보고 절차를 사용할 수 있다. 영향을 받는 하위 시스템 유지관리자와 커널 보안 팀이 공개 전에 수정과 배포 준비를 조정할 수 있다.

기여 방법

Linux 커널 기여는 대형 기능이나 새로운 드라이버 작성에만 한정되지 않는다. 처음 참여하는 개발자도 다음과 같은 방식으로 기여할 수 있다.

• 재현 가능한 오류 보고
• 회귀가 시작된 커밋 탐색
• 문서 오류 수정
• 컴파일러 경고 해결
• 정적 분석과 퍼징 결과 수정
• 기존 드라이버의 작은 오류 수정
• 시험 코드 작성
• 오래된 코드와 주석 정리
• 다른 개발자의 패치 시험
• 코드 검토
• 새로운 하드웨어 지원
• 번역이 아닌 기술 문서와 예제 개선

개발자는 먼저 관심 있는 하위 시스템의 메일링 리스트와 최근 패치를 살펴보고, MAINTAINERS 파일과 해당 영역의 개발 지침을 확인할 수 있다.

패치를 만들기 전에는 최신 메인라인 또는 관련 유지관리자 트리에서 문제가 여전히 존재하는지 확인해야 한다. 오래된 배포판 커널에서만 발생하는 문제는 이미 상위 커널에서 수정되었을 수 있으며, 배포판에 역이식을 요청하는 편이 적절할 수 있다.

Linux 커널 개발 문서는 기술적인 코딩 방법뿐 아니라 패치 작성, 이메일 전송, 검토 대응과 공동체의 작업 방식을 설명한다.^[80]

코드 소유와 라이선스

Linux 커널에 코드를 기여한다고 해서 저작권을 토르발스나 Linux Foundation에 일괄 양도하는 것은 아니다. 일반적으로 각 기여자 또는 그 고용주가 자신이 작성한 코드의 저작권을 보유하며, 해당 코드를 커널의 라이선스 조건에 따라 배포하도록 허용한다.

Linux 커널은 주로 GPL-2.0-only 조건으로 배포되며, 파일과 구성 요소에 따라 SPDX 라이선스 식별자가 표시된다.

여러 개발자와 기업이 각자 저작권을 가진 코드를 하나의 프로젝트에 기여하므로, 특정 조직이 커널 전체를 단독으로 소유하거나 임의로 폐쇄형 라이선스로 전환하기 어렵다.

기여자는 Developer Certificate of Origin 절차를 통해 자신이 코드를 제출할 권리가 있음을 확인한다. 기업 개발자는 고용주의 오픈 소스 기여 정책과 승인을 따를 수도 있다.

개발 기반과 Linux Foundation

Linux 커널의 기술적 개발과 패치 채택은 토르발스와 유지관리자, 개발 공동체가 담당한다. Linux Foundation이 커널 패치를 직접 지시하거나 모든 유지관리자를 고용하는 것은 아니다.

Linux Foundation은 다음과 같은 개발 기반을 지원한다.

• 토르발스와 일부 주요 개발자의 활동 지원
• kernel.org와 관련 인프라
• 개발자 행사와 협업
• 교육과 인증
• 기업과 공동체의 중립적 협력 기반
• 오픈 소스 프로젝트의 법률·운영 지원

기업은 Linux Foundation 회원으로 참여하거나 개발자를 직접 고용하고, 시험 장비와 개발 인프라, 행사와 프로젝트에 자금을 제공할 수 있다.

재정과 조직 기반을 지원하는 기관이 존재하더라도 어떤 패치가 메인라인에 들어가는지는 일반적으로 공개된 기술 검토와 유지관리자 계층을 통해 결정된다.

분산 개발과 중앙 통합

Linux 커널 개발은 완전히 중앙집중적이지도, 완전히 분산되어 있지도 않다.

개발과 검토는 하위 시스템과 기업, 개인 개발자의 저장소와 메일링 리스트에 넓게 분산된다. 각 유지관리자는 자신의 전문 영역에서 상당한 판단 권한을 가지며, 여러 저장소가 동시에 다음 릴리스를 준비한다.

반면 공식 메인라인의 최종 통합과 버전 공개는 토르발스의 저장소를 중심으로 이루어진다. 안정·장기지원 릴리스도 지정된 유지관리자와 공식 저장소를 중심으로 관리된다.

이 구조는 한 사람이 전체 세부 코드를 직접 관리하지 않으면서도, 공식 Linux 커널이 서로 호환되지 않는 여러 갈래로 무제한 분리되는 것을 줄인다. 하위 시스템의 전문성과 분산된 개발 능력을 활용하면서 최종 릴리스에는 공통된 기준점과 책임 경로를 제공한다.

Linux 커널은 누구나 복제하고 수정하여 별도의 버전을 만들 수 있다. 그러나 배포판과 하드웨어 제조사, 응용 프로그램 개발자가 함께 사용할 공통 기반은 메인라인과 안정·장기지원 계열을 중심으로 형성된다.

이에 따라 Linux 커널 개발은 공개된 소스 코드만으로 이루어지는 것이 아니라, 유지관리자 사이의 신뢰와 검토 기록, 정기적인 릴리스와 안정화, 수많은 사용자와 기업의 시험을 결합한 지속적인 공동 개발 과정으로 운영된다.

Linux는 원본 UNIX 소스 코드에서 직접 분기한 운영체제가 아니다. 리누스 토르발스와 이후의 개발자들이 UNIX의 인터페이스와 동작 방식을 참고하여 독립적으로 구현한 유닉스 계열 운영체제다.

유닉스 계열이라는 분류는 반드시 원본 UNIX와 코드 계보를 공유하거나 공식 UNIX 인증을 받았다는 뜻은 아니다. 계층형 파일 시스템과 다중 사용자·다중 작업 모델, 프로세스와 파일 디스크립터, 셸과 작은 명령줄 도구의 조합, UNIX 계열 시스템 호출과 프로그래밍 인터페이스를 따른다는 구조적·문화적 관계를 나타낸다.

Linux의 호환성은 하나의 단일 표준만으로 결정되지 않는다. 소스 코드 수준에서는 POSIX와 ISO C, 명령줄과 파일 배치에서는 POSIX와 FHS, Linux 배포판 사이의 실행 파일 호환성에는 LSB, 커널과 사용자 공간 사이에는 Linux 고유의 사용자 공간 ABI가 영향을 준다.

UNIX와 유닉스 계열

UNIX라는 명칭에는 역사적인 운영체제 계보와 기술 표준, 상표라는 서로 다른 의미가 함께 존재한다.

역사적인 의미의 UNIX는 1969년부터 Bell Labs에서 개발된 운영체제와 여기에서 파생된 System V, BSD와 여러 상용 계열을 가리킨다. Linux는 이 소스 계보에서 직접 파생되지 않았으며, UNIX 소스 코드를 복제하여 만들어진 시스템도 아니다.

기술적인 의미에서는 UNIX가 형성한 프로세스와 파일 모델, 셸, 시스템 호출과 프로그래밍 관습을 따르는 운영체제를 넓게 유닉스 계열이라고 부른다. Linux는 이 의미에서 유닉스 계열로 분류된다.

한편 대문자로 표기되는 UNIX는 The Open Group이 관리하는 등록 상표다. 특정 제품이 UNIX 상표를 사용하려면 The Open Group의 Single UNIX Specification에 대한 적합성 시험과 인증을 받아야 한다. 단순히 POSIX 인터페이스를 상당 부분 구현하거나 UNIX와 비슷하게 작동하는 것만으로 공식 UNIX 제품이 되는 것은 아니다.^[81]

Linux 커널과 일반적인 Linux 배포판은 전체 생태계를 대표하는 하나의 제품으로 UNIX 인증을 받지 않는다. Linux는 여러 독립 배포판과 사용자 공간 조합으로 구성되므로, “Linux 전체”를 하나의 고정된 제품으로 시험하기도 어렵다.

다만 Linux 커널이나 GNU 사용자 공간을 사용한다는 사실 자체가 UNIX 인증을 막는 것은 아니다. 특정 제조사가 구성과 버전을 고정한 운영체제 제품을 만들고 Single UNIX Specification의 요구 사항을 충족한 뒤 인증을 받는다면 UNIX 상표를 사용할 수 있다. 따라서 “Linux는 UNIX가 아니다”라는 말은 주로 Linux 전체가 원본 UNIX 계보 또는 하나의 공식 인증 제품이 아니라는 뜻이지, Linux 기반 제품이 기술적으로 인증될 가능성까지 부정하는 표현은 아니다.

POSIX

POSIX는 운영체제와 응용 프로그램 사이의 표준 인터페이스를 정의하여 프로그램을 서로 다른 UNIX 및 유닉스 계열 시스템으로 이식하기 쉽게 만들기 위한 표준이다.

POSIX는 다음과 같은 영역을 정의한다.

• 프로세스 생성과 실행
• 파일과 디렉터리 조작
• 파일 디스크립터와 입출력
• 신호
• 사용자와 그룹
• 시간과 타이머
• 스레드와 동기화
• 소켓과 여러 시스템 인터페이스
• 셸 언어
• awk, sed, grep, make와 같은 기본 유틸리티
• 환경 변수와 로케일
• 프로그램 빌드와 실행에 필요한 기본 환경

현재 POSIX의 주요 판은 POSIX.1-2024이며, 동시에 IEEE Std 1003.1-2024와 The Open Group Base Specifications Issue 8로 발행되었다. 이 규격은 운영체제 API뿐 아니라 셸과 공통 유틸리티를 포함하는 표준 실행 환경을 정의한다.^[82][83]

POSIX는 특정 커널 구현 방식을 규정하지 않는다. 모놀리식 커널과 마이크로커널, 서로 다른 파일 시스템과 스케줄러를 사용하더라도 응용 프로그램에 표준 인터페이스와 동작을 제공하면 POSIX 호환 환경을 만들 수 있다.

Linux 커널은 POSIX에 필요한 많은 시스템 호출과 실행 의미를 제공하며, glibc와 musl 같은 C 라이브러리와 셸, Coreutils 등의 사용자 공간 프로그램이 표준 API와 명령을 완성한다. 따라서 POSIX 호환성은 Linux 커널 하나만의 속성이 아니라 커널과 C 라이브러리, 셸과 명령줄 도구를 포함한 전체 사용자 공간의 속성이다.

glibc는 ISO C 인터페이스와 POSIX, BSD, System V와 GNU 확장을 함께 제공한다. 프로그램은 기능 검사 매크로와 컴파일 옵션을 사용하여 POSIX에 정의된 기능만 노출하거나 Linux·GNU 확장 기능을 사용할 수 있다.^[84]

POSIX 호환성과 Linux 확장

Linux에서 POSIX 프로그램을 실행할 수 있다고 해서 Linux의 모든 기능이 POSIX 표준에 포함되는 것은 아니다. Linux는 POSIX가 정의하지 않는 여러 고유 인터페이스와 확장을 제공한다.

대표적인 Linux 고유 기능에는 다음이 포함된다.

• epoll
• inotify
• signalfd와 eventfd
• futex
• 네임스페이스
• cgroups
• eBPF
• seccomp
• io_uring
• Netlink
• Linux capabilities
• 각종 Linux 전용 시스템 호출과 ioctl

이러한 기능을 직접 사용하는 프로그램은 Linux에서 높은 성능이나 고유 기능을 활용할 수 있지만, 다른 UNIX 계열 운영체제로 이식하려면 해당 코드를 변경하거나 호환 계층을 마련해야 한다.

이식성을 중시하는 프로그램은 공통 기능에 POSIX 인터페이스를 사용하고, 운영체제별 고성능 기능은 별도의 구현으로 분리하는 경우가 많다. 예를 들어 이벤트 처리 추상화 계층에서 Linux에서는 epoll, BSD와 macOS에서는 kqueue를 사용할 수 있다.

반대로 Linux가 POSIX의 모든 선택 기능과 세부 동작을 모든 구성에서 완벽하게 제공한다고 단정할 수도 없다. 배포판이 선택한 C 라이브러리와 셸, 설치된 유틸리티와 기능 설정에 따라 사용할 수 있는 표준 기능이 달라질 수 있다.

Single UNIX Specification

Single UNIX Specification은 The Open Group이 관리하는 UNIX 운영체제 표준이다. 핵심 규격은 POSIX와 공동으로 개발되며, UNIX 인증 제품이 제공해야 하는 인터페이스와 환경을 정의한다.

POSIX와 Single UNIX Specification은 상당한 내용을 공유하지만 목적이 완전히 같지는 않다. POSIX는 응용 프로그램의 이식성을 위한 표준 인터페이스를 정의하고, Single UNIX Specification은 인증 가능한 UNIX 시스템의 요구 사항을 구성한다.

The Open Group은 Single UNIX Specification을 충족하고 인증 절차를 통과한 제품만 UNIX 상표를 사용할 수 있다고 규정한다.^[85]

Linux가 POSIX와 UNIX 인터페이스를 광범위하게 구현해도, 일반적인 Linux 배포판을 자동으로 UNIX라고 부르지 않는 이유가 여기에 있다. UNIX 상표는 구현의 유사성을 설명하는 일반 명칭이 아니라 특정 제품과 버전에 부여되는 인증 표지다.

실제 소프트웨어 개발에서는 UNIX 인증 여부보다 POSIX 및 일반적인 UNIX 인터페이스 지원이 더 직접적인 영향을 주는 경우가 많다. Linux, BSD와 macOS에서 함께 실행되는 프로그램은 공통된 POSIX API와 빌드 도구를 기반으로 작성될 수 있다.

Linux Standard Base

Linux 배포판은 같은 커널을 사용하더라도 C 라이브러리와 파일 배치, 패키지 형식, 기본 셸과 포함된 라이브러리가 다를 수 있다. 이 차이는 한 배포판에서 빌드한 실행 파일이 다른 배포판에서 그대로 실행되지 않는 문제를 만들었다.

LSB는 여러 Linux 배포판에 공통된 실행 환경을 정의하여 응용 프로그램의 이식성과 바이너리 호환성을 높이기 위해 개발되었다.

LSB는 다음과 같은 내용을 다뤘다.

• 공통 시스템 라이브러리와 함수
• 실행 파일과 동적 링커 인터페이스
• 프로세서 아키텍처별 ABI
• 기본 명령과 셸 환경
• 프로그램 설치 스크립트 환경
• 파일 시스템 배치
• 그래픽과 데스크톱 라이브러리
• 언어 런타임과 인쇄·이미징 인터페이스

POSIX가 주로 소스 코드 수준의 이식성을 목표로 한다면, LSB는 특정 프로세서 아키텍처에서 컴파일된 Linux 응용 프로그램이 여러 호환 배포판에서 실행될 수 있도록 바이너리 인터페이스까지 정의하려 했다.

LSB는 Linux 배포판을 하나로 통합하려는 규격이 아니었다. 각 배포판이 서로 다른 패키지 관리자와 관리 정책, 추가 기능을 유지하면서도 상용 응용 프로그램이 의존할 수 있는 공통 기반을 제공하는 것이 목적이었다.

LSB 5.0은 2015년 공개되었으며, Linux Foundation의 규격 보관소에서 제공된다. LSB 5.0은 이전의 ISO/IEC 23360에 해당했던 LSB 3.1을 발전시킨 규격이지만, Linux Foundation판 LSB 5.0 문서 자체는 ISO 표준판으로 간주하지 않는다고 명시한다.^[86]

ISO/IEC 23360

LSB는 국제 표준으로도 채택되었다. ISO/IEC 23360 계열은 Linux Standard Base를 바탕으로 Linux 시스템의 공통 응용 프로그램 인터페이스와 실행 환경을 규정한다.

ISO/IEC 23360은 공통 규격과 프로세서 아키텍처별 규격을 분리한다. 공통 부분은 여러 Linux 구현에서 동일하게 제공할 인터페이스를 정의하고, 아키텍처별 부분은 호출 규약과 데이터 형식, 실행 파일 구조처럼 프로세서에 따라 달라지는 바이너리 인터페이스를 정의한다.

2006년에 발행된 ISO/IEC 23360 계열은 LSB 3.1에 대응했다. 이 판은 이후 철회되었으며, LSB 5 계열을 반영하도록 다시 구성된 2021년판 ISO/IEC 23360 문서들이 발행되었다.^[87]

2021년판은 다음과 같이 여러 부분으로 세분화되어 있다.

• ISO/IEC 23360-1-1 — 공통 정의
• ISO/IEC 23360-1-2 — 공통 Core 규격
• ISO/IEC 23360-1-3 — 공통 Desktop 규격
• ISO/IEC 23360-1-4 — 언어 규격
• ISO/IEC 23360-1-5 — 이미징 규격
• ISO/IEC TS 23360-1-6 — 그래픽과 GTK 3 규격
• ISO/IEC 23360-2-2 등 — 각 프로세서 아키텍처의 Core 규격

예를 들어 ISO/IEC 23360-2-2:2021은 x86-32 아키텍처를 위한 Core 인터페이스를 정의하고, ISO/IEC 23360-8-2:2021은 S390X 아키텍처의 Core 규격을 제공한다.^[88][89]

ISO/IEC 23360은 Linux 커널의 내부 설계나 모든 배포판의 관리 방식을 규정하지 않는다. 컴파일된 응용 프로그램과 설치 스크립트가 의존할 수 있는 공통 시스템 환경을 정의하는 표준이다.

ISO는 POSIX와 LSB 사이에 충돌하거나 다르게 규정된 영역을 분석하기 위해 ISO/IEC TR 24715:2006도 발행했다. 이 기술 보고서는 ISO/IEC 9945의 POSIX 규격과 ISO/IEC 23360의 LSB 규격 사이의 차이를 정리한다.^[90]

이는 Linux가 POSIX를 그대로 복제한 환경이 아니라, POSIX 기반 위에 별도의 ABI와 라이브러리, Linux 전용 인터페이스를 가진 플랫폼이라는 점을 보여준다.

LSB의 영향과 한계

LSB는 Linux가 상용 UNIX와 서버 시장에서 경쟁하기 시작하던 시기에 중요한 역할을 했다. 독립 소프트웨어 공급업체는 배포판마다 별도 실행 파일을 만들고 시험하는 비용을 줄일 수 있었고, 배포판은 공통 라이브러리와 파일 배치를 참고할 수 있었다.

LSB는 다음과 같은 영향을 남겼다.

• Linux 배포판 사이의 공통 ABI에 대한 요구 정립
• 상용 응용 프로그램을 위한 인증 대상 정의
• 아키텍처별 ELF와 호출 규약 문서화
• POSIX와 Linux 고유 인터페이스의 관계 정리
• FHS와 연계한 파일 시스템 배치 통일
• 배포판과 응용 프로그램 공급업체 사이의 시험 체계 제공
• Linux 인터페이스의 ISO 국제 표준화

그러나 Linux 생태계가 발전하면서 LSB의 실제 적용에는 한계도 나타났다. 데스크톱과 그래픽 라이브러리는 빠르게 변했고, 모든 배포판이 동일한 라이브러리 버전과 패키지를 장기간 제공하기 어려웠다. 배포판은 LSB가 규정하지 않는 새로운 기술을 채택했고, 일부 LSB 인터페이스는 실제 개발 환경의 변화를 충분히 따라가지 못했다.

현대의 Linux 응용 프로그램 배포에서는 LSB 하나에 의존하기보다 다음과 같은 방식도 사용된다.

• 배포판별 네이티브 패키지 제공
• 오래된 glibc 환경에서 빌드하여 호환 범위 확대
• 필요한 라이브러리를 프로그램과 함께 배포
• Flatpak과 Snap 같은 공통 런타임 사용
• AppImage로 파일 묶음 제공
• 컨테이너 이미지로 사용자 공간 전체 고정
• 소스 코드와 자동 빌드 절차 제공

따라서 LSB와 ISO/IEC 23360은 Linux 호환성의 역사적·기술적 기준으로 중요하지만, 현재 존재하는 모든 배포판과 응용 프로그램 배포 방식을 완전히 통일하는 규격은 아니다.

Filesystem Hierarchy Standard

FHS는 UNIX 계열 운영체제에서 파일과 디렉터리를 배치하는 공통 기준을 제공한다.

FHS는 다음과 같은 디렉터리의 용도를 정의한다.

• /bin
• /boot
• /dev
• /etc
• /home
• /lib
• /media
• /mnt
• /opt
• /run
• /sbin
• /srv
• /tmp
• /usr
• /var

FHS의 목적은 배포판과 응용 프로그램, 시스템 관리 도구와 문서가 파일 위치에 대해 공통된 가정을 할 수 있도록 하는 것이다. FHS 3.0은 2015년 공개되었으며 UNIX 계열 시스템에서 응용 프로그램과 관리 도구, 개발 도구와 스크립트의 상호운용성을 지원하는 파일 배치 규칙을 제공한다.^[91]

FHS는 처음부터 모든 UNIX 계열 운영체제에 적용되는 이름으로 시작한 것은 아니다. 1993년 Linux의 디렉터리 구조를 정리하려는 FSSTND 작업에서 출발했고, 다른 UNIX 계열 시스템까지 범위가 넓어지면서 FHS로 이름이 변경되었다.^[92]

실제 Linux 배포판은 FHS를 완전히 동일하게 따르지 않을 수 있다. /bin, /sbin과 /lib를 /usr 아래로 통합하는 usr merge, 읽기 전용 시스템 이미지와 원자적 업데이트 같은 새로운 배포 방식은 전통적인 디렉터리 구성을 변화시켰다.

FHS의 영향은 특정 경로가 절대로 바뀌지 않는다는 데 있지 않다. 서로 다른 배포판과 소프트웨어가 파일 위치를 논의할 수 있는 공통 기준을 만들었다는 데 있다.

C와 언어 표준

Linux 사용자 공간의 많은 프로그램은 C (프로그래밍 언어)로 작성되며, ISO C 표준과 POSIX API를 함께 사용한다.

ISO C는 언어 문법과 표준 라이브러리를 정의하지만 프로세스 생성, 디렉터리 탐색, 소켓과 사용자 계정 같은 운영체제 기능은 대부분 정의하지 않는다. POSIX는 C 언어를 중심으로 이러한 운영체제 인터페이스를 확장한다.

Linux 프로그램의 일반적인 표준 관계는 다음과 같이 구분할 수 있다.

• ISO C — 언어와 기본 C 라이브러리
• POSIX — 프로세스, 파일, 스레드, 셸과 UNIX식 운영체제 API
• Linux UAPI — Linux에만 존재하는 시스템 호출과 기능
• LSB·ISO/IEC 23360 — Linux 배포판의 공통 바이너리 실행 환경
• 프로세서 ABI — 호출 규약과 데이터 배치, 실행 파일 형식

C++와 Rust, Go, Java와 같은 언어도 Linux에서 사용되지만, 최종적으로는 언어 런타임과 표준 라이브러리가 POSIX 또는 Linux 사용자 공간 인터페이스를 호출한다.

Linux 사용자 공간 ABI

Linux 커널과 응용 프로그램 사이의 실제 호환성에서 중요한 기준은 사용자 공간 ABI다. 여기에는 시스템 호출 번호와 인수, ioctl, Netlink 메시지, /proc와 /sys 인터페이스, 장치별 사용자 공간 API 등이 포함된다.

Linux 커널은 기존 사용자 공간을 깨뜨리지 않는 것을 매우 중요한 원칙으로 삼는다. 커널 문서는 안정된 사용자 공간 인터페이스에 대해 호환성을 유지하며, 시스템 호출과 같은 대부분의 인터페이스는 사라지지 않고 계속 제공될 것으로 기대된다고 설명한다.^[93]

이 원칙 덕분에 오래된 Linux 실행 파일이 새로운 커널에서 계속 실행되는 경우가 많다. 새로운 커널은 기존 시스템 호출과 동작을 유지하면서 새 기능을 추가한다.

커널 헤더도 일반적으로 이전 버전과의 호환성을 고려한다. 오래된 커널 헤더를 사용하는 C 라이브러리에 맞춰 빌드한 프로그램은 새로운 커널에서 실행될 수 있지만, 새로운 헤더와 기능을 요구하는 프로그램은 오래된 커널에서 실행되지 않을 수 있다.^[94]

다만 모든 /proc, /sys, 디버깅 인터페이스와 시험 단계의 API가 동일한 안정성 수준을 갖는 것은 아니다. 커널 문서는 사용자 공간 ABI를 안정, 시험, 폐기 예정과 제거됨 등의 범주로 나누어 문서화한다.

커널 내부 ABI

사용자 공간 ABI의 강한 호환성과 달리, Linux 커널 내부 API와 커널 모듈 ABI는 일반적으로 메인라인 전체에 걸쳐 안정적으로 고정되지 않는다.

장치 드라이버와 파일 시스템이 사용하는 내부 함수와 자료 구조는 커널 개발 과정에서 변경될 수 있다. 오래된 내부 인터페이스를 영구히 유지하면 잘못된 설계와 중복 코드를 제거하기 어렵고, 커널 전체의 개선을 방해할 수 있기 때문이다.

공식 커널 트리에 포함된 드라이버는 내부 API가 바뀔 때 같은 변경 안에서 함께 수정된다. 반면 외부에서 별도로 배포되는 커널 모듈은 새 커널 버전마다 소스를 수정하거나 다시 빌드해야 할 수 있다.

일부 기업용 배포판은 자사 제품 수명 동안 제3자 모듈을 지원하기 위해 제한된 커널 ABI를 별도로 안정화한다. 이는 메인라인 Linux 전체가 보장하는 표준이 아니라 해당 배포판이 제공하는 제품 호환성 정책이다.

Linux 커널 문서는 사용자 공간 시스템 호출 ABI는 장기간 안정적으로 유지되지만, 커널 내부 드라이버 인터페이스를 고정하는 것은 개발 속도와 코드 품질을 저해한다고 설명한다.^[95]

프로세서 아키텍처와 바이너리 호환성

Linux 실행 파일의 호환성은 운영체제 인터페이스뿐 아니라 프로세서 아키텍처와 ABI에 영향을 받는다.

프로세서 ABI는 다음 요소를 정의한다.

• 정수와 포인터의 크기
• 자료형의 메모리 정렬
• 함수 인수와 반환값 전달 방식
• 사용해야 하는 레지스터
• 스택 배치
• 시스템 호출 규약
• 오브젝트 및 실행 파일 형식
• 동적 링커와 공유 라이브러리 규칙

x86-64용 실행 파일은 ARM64 Linux에서 직접 실행되지 않는다. 두 시스템이 같은 Linux 커널 계열과 POSIX API를 제공해도 CPU 명령어와 바이너리 형식의 세부 규약이 다르기 때문이다.

Linux는 주로 ELF를 실행 파일과 공유 라이브러리 형식으로 사용한다. ELF 자체만으로 전체 호환성이 보장되지는 않으며, 해당 아키텍처 ABI와 C 라이브러리, 동적 링커와 필요한 라이브러리 버전이 맞아야 한다.

LSB와 ISO/IEC 23360이 공통 부분과 아키텍처별 부분을 분리한 것도 이러한 차이 때문이다.

라이브러리와 배포판 호환성

같은 CPU 아키텍처와 Linux 커널을 사용해도 실행 파일이 모든 배포판에서 항상 동작하는 것은 아니다.

프로그램은 다음 요소에 의존할 수 있다.

• glibc 또는 musl과 같은 C 라이브러리
• C++ 표준 라이브러리와 심볼 버전
• 동적 링커의 경로
• 공유 라이브러리의 이름과 버전
• 파일과 설정의 위치
• 그래픽 및 데스크톱 라이브러리
• 배포판이 적용한 패치
• 커널의 최소 버전과 기능
• CPU 명령어 집합 수준

glibc를 사용해 빌드한 프로그램은 musl 기반 배포판에서 그대로 실행되지 않을 수 있다. 최신 glibc의 새 심볼을 요구하는 실행 파일은 오래된 배포판에서 실패할 수 있지만, 오래된 glibc를 대상으로 빌드한 프로그램은 새로운 배포판에서 실행될 가능성이 상대적으로 높다.

배포판 패키지는 이러한 차이를 해결하기 위해 해당 배포판에서 다시 빌드되고 의존성 정보와 함께 제공된다. 소프트웨어 공급자가 하나의 범용 실행 파일을 제공하려면 지원할 최소 라이브러리와 커널 버전을 정하고, 호환되는 환경에서 빌드·시험해야 한다.

명령줄 호환성

Linux 셸 환경은 UNIX 및 POSIX 명령과 유사하지만, 실제 명령 구현은 서로 다른 확장을 제공할 수 있다.

GNU Coreutils와 GNU sed, GNU grep은 POSIX 기능에 더해 긴 옵션과 추가 출력 형식, 확장 정규 표현식과 Linux 환경에 맞춘 기능을 제공한다. BSD 계열 도구와 BusyBox 구현은 같은 명령 이름을 사용해도 옵션과 세부 동작이 다를 수 있다.

POSIX 셸 스크립트는 /bin/sh와 표준 유틸리티만 사용하도록 작성하면 여러 UNIX 계열 환경으로 이식하기 쉽다. 반대로 Bash 배열과 프로세스 치환, GNU 전용 명령 옵션을 사용하면 실행 가능한 환경이 제한된다.

Linux 안에서도 /bin/sh가 Bash, Dash, BusyBox ash 또는 다른 셸을 가리킬 수 있다. 따라서 특정 셸 기능을 요구하는 스크립트는 적절한 인터프리터를 명시해야 한다.

소스 호환성과 바이너리 호환성

호환성은 어느 단계의 호환성을 의미하는지 구분해야 한다.

소스 호환성은 같은 소스 코드를 다른 시스템에서 다시 컴파일하여 실행할 수 있는 능력이다. POSIX와 ISO C는 주로 이러한 이식성을 지원한다.

바이너리 호환성은 이미 컴파일된 실행 파일을 다시 빌드하지 않고 다른 시스템에서 실행할 수 있는 능력이다. 프로세서 ABI와 C 라이브러리, 동적 링커와 LSB 같은 규격이 영향을 준다.

동작 호환성은 프로그램이 실행되는 데 그치지 않고 파일 권한과 신호, 스레드, 네트워크와 명령줄 도구가 예상한 의미로 작동하는지를 뜻한다.

관리 호환성은 패키지 설치와 서비스 관리, 네트워크 설정과 시스템 구성 방식이 비슷한지를 뜻한다. 이 영역은 POSIX나 커널 ABI보다 배포판 정책의 영향을 크게 받는다.

두 Linux 배포판이 POSIX 소스 호환성을 제공하더라도 패키지 관리자와 서비스 설정은 완전히 다를 수 있다. 반대로 컨테이너를 사용하면 사용자 공간 전체를 함께 배포하여 배포판 사이의 바이너리·관리 차이를 일부 우회할 수 있다.

사실상의 표준

Linux 생태계에서는 공식적인 국제 표준 외에도 널리 채택되어 사실상 표준 역할을 하는 인터페이스가 존재한다.

예를 들면 다음과 같다.

• ELF 실행 파일 형식
• glibc의 GNU 및 Linux 확장
• systemd의 서비스 단위와 관련 인터페이스
• freedesktop.org의 데스크톱 규격
• XDG Base Directory Specification
• D-Bus
• Wayland 프로토콜
• OCI 이미지와 런타임 규격
• Devicetree 바인딩
• Virtio
• UEFI와 ACPI의 Linux 지원
• 배포판별 패키지 메타데이터

이들 가운데 일부는 Linux Foundation, freedesktop.org, OASIS 또는 다른 표준화 단체가 관리하며, 일부는 주요 구현체가 널리 채택되면서 사실상의 기준이 되었다.

Linux는 공개 구현을 통해 새로운 인터페이스가 실제 시스템에 빠르게 적용되고 검증되는 환경을 제공했다. 컨테이너와 클라우드, 하드웨어 초기화, 그래픽과 장치 관리 분야에서는 Linux에서 널리 사용된 인터페이스가 다른 시스템과 산업 규격에도 영향을 주었다.

표준에 대한 Linux의 영향

Linux는 기존 UNIX와 POSIX 표준을 구현한 운영체제로 시작했지만, 확산 이후에는 새로운 시스템 인터페이스와 산업 규격의 형성에도 영향을 주었다.

Linux의 영향은 다음과 같은 형태로 나타난다.

• 여러 프로세서 아키텍처에서 공통된 운영체제 기반 제공
• LSB를 통한 Linux 전용 국제 표준 형성
• FHS를 통한 디렉터리 배치의 공통 기준 확립
• ELF와 System V ABI의 광범위한 실사용
• cgroups와 네임스페이스를 이용한 컨테이너 모델 확산
• Virtio를 통한 가상 장치 인터페이스 보급
• Devicetree를 이용한 임베디드 하드웨어 기술 방식 확대
• Linux 시스템 호출과 ABI를 대상으로 하는 호환 계층 등장
• Linux 중심의 OCI와 클라우드 네이티브 규격 발전
• 오픈 소스 참조 구현을 통한 표준의 실제 검증

Linux ABI를 구현하여 기존 Linux 응용 프로그램을 실행하려는 다른 운영체제와 호환 계층도 개발되고 있다. 이는 POSIX 호환성만으로는 Linux용 응용 프로그램 생태계를 완전히 대체할 수 없으며, Linux 고유 시스템 호출과 동작이 하나의 중요한 플랫폼 규격으로 자리 잡았음을 보여준다.

표준화의 한계

Linux의 표준화는 배포판과 소프트웨어를 완전히 동일하게 만들지 않는다.

POSIX는 공통 기능을 정의하지만 Linux의 최신 기능 전체를 포함하지 않는다. LSB는 바이너리 호환성을 목표로 했지만 빠르게 변화하는 데스크톱과 라이브러리 생태계를 모두 따라가기 어려웠다. FHS는 공통 디렉터리 기준을 제공하지만 새로운 이미지 기반 시스템과 /usr 통합은 기존 배치를 변화시키고 있다.

Linux 커널은 안정적인 사용자 공간 ABI를 유지하지만, 배포판마다 다음 요소가 다를 수 있다.

• 패키지 형식과 저장소
• C 라이브러리
• init 시스템
• 기본 셸과 명령 구현
• 파일 시스템 배치
• 보안 정책
• 그래픽 환경
• 지원하는 커널 구성
• 업데이트와 장기 지원 정책

표준은 이러한 차이를 제거하기보다 프로그램과 시스템이 의존할 수 있는 공통된 최소 기반을 제공한다.

Linux의 호환성은 국제 표준, 공개된 사용자 공간 ABI, 배포판 정책과 실제 구현 관행이 함께 유지한다. Linux가 UNIX 계열로 분류되는 이유도 특정 하나의 인증이나 코드 계보 때문이 아니라, UNIX에서 발전한 인터페이스와 프로그래밍 모델을 따르면서 이를 독립적으로 확장하고 사실상의 새로운 플랫폼 표준으로 발전시켰기 때문이다.

Linux는 범용 서버와 클라우드부터 스마트폰, 슈퍼컴퓨터, 네트워크 장비, 자동차와 소형 임베디드 장치까지 다양한 컴퓨팅 환경에서 사용된다. 하나의 고정된 제품이 아니라 커널과 사용자 공간, 배포판 구성을 목적에 맞게 선택할 수 있기 때문에 규모와 형태가 다른 시스템에 적용할 수 있다.

Linux가 널리 사용되는 분야는 모두 같은 구성을 사용하지 않는다. 데이터 센터에서는 범용 배포판과 가상화 기능이 중심이 되고, 스마트폰에서는 Android 사용자 공간이 결합되며, 임베디드 장치에서는 필요한 기능만 남긴 작은 시스템 이미지가 사용된다.

서버와 인터넷 서비스

Linux는 웹 서버와 데이터베이스, 파일 서버, 전자우편, DNS와 각종 네트워크 서비스의 기반으로 사용된다. 원격 관리와 자동화가 쉽고, 상용 및 오픈 소스 서버 소프트웨어를 폭넓게 실행할 수 있으며, 그래픽 환경을 제외한 최소 구성으로도 운영할 수 있기 때문이다.

서버 환경에서는 다음과 같은 용도로 사용된다.

• 웹과 응용 프로그램 서버
• 데이터베이스
• 파일과 저장 장치 서비스
• 전자우편과 DNS
• 인증과 디렉터리 서비스
• 게임 서버
• 미디어 처리와 스트리밍
• 사내 업무 시스템
• 대규모 검색과 데이터 처리

기업은 자체 데이터 센터에서 Linux를 직접 운영하거나, 상용 지원이 제공되는 배포판을 사용한다. 같은 Linux 기반이라도 안정성과 장기 지원을 중시하는 기업용 배포판, 빠른 기능 도입을 중시하는 배포판과 작은 컨테이너용 배포판이 서로 다른 역할을 맡는다.

클라우드 컴퓨팅

Linux는 가상 머신과 컨테이너, 클라우드 관리 시스템의 주요 실행 환경이다. KVM을 이용한 가상화, 네임스페이스와 cgroups를 이용한 컨테이너, 가상 네트워크와 자동화 도구가 Linux를 중심으로 발전했다.

클라우드에서는 다음 계층에 Linux가 사용될 수 있다.

• 물리 서버의 호스트 운영체제
• 고객에게 제공되는 가상 머신
• 컨테이너 호스트
• Kubernetes 노드
• 스토리지와 네트워크 장비
• 클라우드 제어 서비스
• 서버리스 실행 환경의 기반

Linux는 일반 x86-64 서버뿐 아니라 ARM64와 여러 프로세서 아키텍처에서 실행되므로, 클라우드 사업자가 목적과 비용에 따라 서로 다른 하드웨어를 제공하는 데도 적합하다. Linux 커널은 현재 여러 32비트 및 64비트 프로세서 아키텍처를 지원한다.^[96]

슈퍼컴퓨터와 고성능 컴퓨팅

Linux는 과학 계산과 기상 예측, 물리 시뮬레이션, 인공지능 학습과 대규모 공학 계산을 수행하는 슈퍼컴퓨터에서 사용된다.

고성능 컴퓨팅 시스템은 수천 개 이상의 연산 노드와 가속기, 고속 네트워크와 병렬 저장 장치를 결합한다. Linux는 소스 코드를 수정할 수 있고 프로세서와 네트워크, 스케줄러와 파일 시스템을 시스템 구조에 맞게 조정할 수 있어 이러한 환경에 적합하다.

슈퍼컴퓨터용 Linux는 일반 데스크톱 배포판과 같은 형태로 사용되지 않을 수 있다. 제조사와 연구 기관은 Linux를 기반으로 다음 요소를 통합한다.

• 대규모 병렬 작업 스케줄러
• MPI와 병렬 통신 환경
• GPU와 연산 가속기
• 고속 인터커넥트
• 병렬 파일 시스템
• 노드 자동 설치와 관리
• 장애 감시와 전력 관리

TOP500은 세계 주요 슈퍼컴퓨터의 운영체제 계열 통계를 제공하며, Linux 계열은 현대 고성능 컴퓨팅에서 지배적인 기반으로 자리 잡았다.^[97]

스마트폰과 모바일 장치

Android는 Linux 커널을 기반으로 한다. Android는 전통적인 GNU/Linux 배포판과 다른 Bionic C 라이브러리, Android Runtime과 응용 프로그램 프레임워크를 사용하지만, 프로세스와 메모리, 장치와 네트워크를 관리하는 핵심에는 Linux 커널이 있다.

Android 커널은 업스트림 Linux 장기지원 커널을 기반으로 Android에 필요한 변경과 장치 지원을 통합한다.^[98]

Linux는 스마트폰에서 다음 기능을 담당한다.

• 응용 프로그램 프로세스 관리
• 메모리와 전원 관리
• 디스플레이와 입력 장치
• 카메라와 오디오
• 이동통신과 무선 네트워크
• 저장 장치와 파일 시스템
• 보안과 응용 프로그램 격리
• 제조사별 하드웨어 드라이버

Android의 보급으로 Linux 커널은 일반 사용자가 Linux 배포판을 직접 설치하지 않더라도 대량의 소비자 기기에서 사용되는 기반 소프트웨어가 되었다.

임베디드 시스템과 가전제품

Linux는 라우터와 텔레비전, 셋톱박스, 저장 장치, 카메라, 산업 제어기와 각종 스마트 기기에 사용된다.

임베디드 시스템에서는 제품에 필요한 기능만 선택해 커널과 사용자 공간을 작게 구성할 수 있다. 제조사는 Linux의 장치 드라이버와 네트워크 기능을 활용하면서 자체 응용 프로그램과 사용자 인터페이스를 추가한다.

대표적인 활용 대상에는 다음이 포함된다.

• 공유기와 무선 액세스 포인트
• 스마트 텔레비전과 미디어 장치
• NAS와 저장 장치
• 보안 카메라
• 로봇과 드론
• 공장 자동화 장비
• 의료·측정 장치
• 디지털 사이니지
• 단일 보드 컴퓨터
• IoT 게이트웨이

Buildroot와 Yocto Project 같은 도구는 부트로더와 Linux 커널, 라이브러리와 응용 프로그램을 결합해 제품별 시스템 이미지를 만드는 데 사용된다.

Linux는 실시간 운영체제 자체와 완전히 같은 특성을 갖지는 않지만, PREEMPT_RT와 우선순위 스케줄링을 이용해 지연 시간을 줄인 구성이 산업·오디오·제어 환경에서 사용되기도 한다. 매우 엄격한 실시간성과 작은 자원 사용이 필요한 부분에는 별도의 실시간 운영체제를 함께 사용할 수 있다.

네트워크와 통신 장비

Linux는 라우터와 방화벽, 부하 분산 장치, VPN 게이트웨이와 통신 기반 장비에 사용된다. 다양한 네트워크 프로토콜과 패킷 처리, 라우팅, 브리지와 가상 네트워크 기능을 커널에서 제공하기 때문이다.

네트워크 분야에서는 다음과 같은 용도로 사용된다.

• 인터넷 라우터와 게이트웨이
• 방화벽과 침입 방지 장비
• VPN 서버
• 무선 네트워크 장비
• 통신사 기반 시설
• 소프트웨어 정의 네트워크
• 네트워크 기능 가상화
• 가상 스위치와 컨테이너 네트워크
• 트래픽 분석과 감시

네트워크 장비 제조사는 일반 Linux 배포판을 그대로 사용하기보다 제품에 필요한 관리 인터페이스와 드라이버, 패킷 처리 기능을 결합한 전용 시스템을 구성할 수 있다.

eBPF와 XDP는 Linux 커널 안에서 네트워크 패킷을 관찰하거나 빠르게 처리하는 데 사용된다. 이 기술은 클라우드 네트워크와 보안, 부하 분산과 관측 도구에도 활용된다.

자동차와 운송 시스템

Linux는 차량용 인포테인먼트와 계기판, 텔레매틱스, 차량 연결 서비스와 소프트웨어 정의 자동차 플랫폼에 사용된다.

Automotive Grade Linux는 자동차 제조사와 부품·기술 기업이 공동으로 차량용 오픈 소스 소프트웨어 기반을 개발하는 프로젝트다. 차량용 사용자 인터페이스와 연결 기능, 가상화와 클라우드 연동을 위한 공통 기반을 제공한다.^[99]

차량에서는 안전 중요도가 서로 다른 기능을 분리해야 하므로 Linux가 모든 제어 기능을 단독으로 담당하지는 않는다. 인포테인먼트와 연결 서비스에는 Linux를 사용하고, 제동과 조향처럼 엄격한 실시간성과 기능 안전이 필요한 영역에는 실시간 운영체제나 별도의 안전 플랫폼을 함께 사용할 수 있다.

가상화 기술을 이용해 한 차량용 컴퓨터에서 Linux와 실시간 운영체제를 분리하여 실행하는 구조도 개발되고 있다.

산업과 엣지 컴퓨팅

Linux는 공장과 발전 설비, 통신 기지국, 매장과 물류 시스템처럼 데이터가 발생하는 현장에 배치되는 엣지 장치의 기반으로 사용된다.

엣지 시스템은 중앙 클라우드에 모든 데이터를 보내지 않고 현장에서 다음 작업을 수행할 수 있다.

• 센서 데이터 수집
• 영상과 음성 분석
• 장비 제어와 상태 감시
• 데이터 필터링과 변환
• 인공지능 추론
• 클라우드와의 동기화
• 네트워크 장애 시 독립 동작

Linux는 작은 ARM 장치부터 GPU가 탑재된 산업용 서버까지 같은 계열의 개발·관리 도구를 사용할 수 있다는 장점이 있다. 컨테이너를 이용하면 클라우드에서 개발한 서비스를 현장 장치에 배포하는 방식도 사용할 수 있다.

데스크톱과 개인용 컴퓨터

Linux는 개인용 컴퓨터와 워크스테이션의 데스크톱 운영체제로도 사용된다. KDE Plasma와 GNOME, Xfce와 여러 데스크톱 환경을 선택할 수 있으며 웹 브라우저, 문서 작성, 그래픽, 미디어와 개발 도구를 실행할 수 있다.

데스크톱 Linux는 다음과 같은 사용자에게 주로 선택된다.

• 소프트웨어 개발자
• 시스템과 네트워크 관리자
• 자유 소프트웨어 사용자
• 운영체제를 직접 구성하려는 사용자
• 과학·공학 워크스테이션 사용자
• 오래된 컴퓨터에 가벼운 시스템이 필요한 사용자
• 보안과 개인 정보 보호를 중시하는 사용자

일반 소비자용 데스크톱 시장에서는 Windows와 macOS보다 사용 비중이 작으며, 일부 상용 응용 프로그램과 게임, 특정 하드웨어의 제조사 지원이 부족할 수 있다. 반면 개발 도구와 서버 환경, 패키지 관리와 사용자화 측면에서는 강점을 가진다.

게임 분야에서는 Steam과 Proton, Vulkan과 그래픽 드라이버의 발전으로 Linux에서 실행 가능한 게임이 늘었다. Linux 기반 휴대용 게임 기기와 전용 게임 시스템도 등장했다.

소프트웨어 개발

Linux는 서버와 임베디드, 운영체제와 오픈 소스 소프트웨어를 개발하는 작업 환경으로 사용된다. 컴파일러와 빌드 도구, 디버거와 성능 분석기, 컨테이너와 가상 머신을 한 시스템에서 사용할 수 있다.

특히 다음 분야의 개발과 밀접하다.

• 웹과 클라우드 서비스
• C와 C++ 시스템 소프트웨어
• Linux 커널과 장치 드라이버
• 임베디드 Linux
• 컨테이너와 Kubernetes
• 네트워크 소프트웨어
• 과학 계산과 인공지능
• 크로스 플랫폼 응용 프로그램

개발자는 개인용 Linux 데스크톱을 사용할 수도 있고, 다른 운영체제에서 원격 Linux 서버나 가상 머신, 컨테이너에 접속해 개발할 수도 있다.

교육과 연구

Linux는 소스 코드와 개발 도구를 공개적으로 이용할 수 있어 컴퓨터 과학과 운영체제, 네트워크와 보안 교육에 사용된다.

학생과 연구자는 다음과 같은 작업을 수행할 수 있다.

• 운영체제 시스템 호출과 프로세스 실험
• 커널과 드라이버 코드 분석
• 컴파일러와 프로그래밍 언어 연구
• 네트워크 프로토콜 실험
• 분산 시스템 구성
• 보안 취약점과 방어 기법 분석
• 병렬 계산과 인공지능 연구
• 새로운 파일 시스템과 스케줄러 개발

가상 머신과 컨테이너를 이용하면 실제 장비를 손상시키지 않고 여러 Linux 환경을 만들고 초기화할 수 있다. 저가의 단일 보드 컴퓨터도 운영체제와 하드웨어 제어 교육에 사용된다.

전용 시스템

Linux는 사용자에게 일반적인 운영체제로 보이지 않는 전용 제품에도 포함된다. 자동판매기와 키오스크, 항공기 오락 장치, 방송 장비와 각종 검사·측정 시스템이 Linux를 내부 기반으로 사용할 수 있다.

이러한 제품에서는 일반적인 데스크톱이나 셸을 노출하지 않고, 전원을 켜면 특정 응용 프로그램만 실행한다. 운영체제는 장치 제어와 네트워크, 업데이트와 오류 복구를 담당하지만 사용자는 Linux를 직접 인식하지 못할 수 있다.

Linux는 처음에는 32비트 x86 개인용 컴퓨터용으로 개발되었지만, 현재는 여러 프로세서 아키텍처와 장치 유형을 지원한다.^[100] 이러한 이식성과 구성 가능성 때문에 Linux는 하나의 특정 시장에 한정된 운영체제가 아니라, 범용 서버에서 소비자 기기와 산업 시스템까지 공통 기반으로 사용되는 운영체제 계열로 발전했다.

Linux는 Linux 커널 하나만으로 이루어진 단일 제품이 아니라, 커널 개발 공동체와 배포판, GNU를 비롯한 사용자 공간 프로젝트, 하드웨어 제조사, 클라우드 사업자, 응용 프로그램 개발자와 사용자 집단이 결합한 생태계다.

Linux 생태계에는 전체를 지휘하는 하나의 중앙 조직이 존재하지 않는다. 커널은 자체 유지관리자 체계를 통해 개발되고, 배포판은 각자의 조직과 정책에 따라 커널과 사용자 공간을 조합하며, 데스크톱 환경과 컴파일러, 시스템 라이브러리와 응용 프로그램은 각각 독립적인 프로젝트가 관리한다.

Linux Foundation은 이러한 생태계를 지원하는 주요 비영리 단체지만 Linux 전체의 소유자나 기술적 지휘 기관은 아니다. Linux라는 명칭과 커널 개발, 배포판과 사용자 공간 프로젝트는 서로 다른 주체와 거버넌스 아래 운영된다.

분산된 생태계

Linux 기반 운영체제의 구성 요소는 여러 독립 프로젝트에서 개발된다.

대표적인 구성 주체는 다음과 같다.

• Linux 커널 개발 공동체
• GNU 프로젝트
• Debian, Fedora와 Arch Linux 등의 배포판 공동체
• Red Hat, Canonical과 SUSE 등의 배포판 기업
• GNOME과 KDE 등의 데스크톱 프로젝트
• systemd, OpenRC와 여러 시스템 구성 프로젝트
• glibc와 musl 등의 C 라이브러리 프로젝트
• GCC와 LLVM 등의 컴파일러 프로젝트
• X.Org와 Wayland 관련 그래픽 프로젝트
• Docker, containerd와 Kubernetes 등의 컨테이너·클라우드 프로젝트
• 하드웨어와 반도체 제조사
• 응용 프로그램과 오픈 소스 개발자

각 프로젝트는 자체 저장소와 릴리스 일정, 유지관리자와 기여 규칙을 가진다. Linux 커널에 코드가 포함되었다고 해서 관련 사용자 공간 프로그램까지 같은 조직이 관리하는 것은 아니며, 한 프로젝트의 결정이 전체 Linux 생태계에 자동으로 적용되지도 않는다.

이 구조는 하나의 조직이 Linux 전체를 통제하지 못하게 하지만, 구성 요소 사이의 변경을 조정하기 어렵게 만들기도 한다. 배포판은 여러 프로젝트에서 발표된 버전을 선택하고 패치와 설정을 적용하여 실제 사용 가능한 시스템으로 통합한다.

Linux 커널의 거버넌스

Linux 커널은 법인 이사회가 기술 기능을 표결하여 결정하는 방식으로 개발되지 않는다. 각 하위 시스템의 개발자와 유지관리자가 공개 메일링 리스트에서 패치를 검토하고, 검토된 변경을 여러 Git 저장소를 거쳐 메인라인으로 전달한다.

커널 소스는 네트워크와 메모리 관리, 파일 시스템, 프로세서 아키텍처, 그래픽과 장치 드라이버 같은 하위 시스템으로 나뉜다. 대부분의 하위 시스템에는 해당 코드 영역의 전반적인 책임을 맡는 유지관리자가 있으며, 이들은 패치를 받아들여 메인라인에 보낼지 판단하는 관문 역할을 한다.^[101]

커널 프로젝트에는 100명이 넘는 유지관리자가 각자의 저장소를 운영한다. 개발과 검토는 여러 저장소에 분산되어 있지만, 최종 단계에서는 변경이 메인라인 저장소로 통합된다. 이 작업은 일반적으로 리누스 토르발스가 담당한다.^[102]

토르발스는 Linux 커널의 창시자이자 최상위 유지관리자지만 모든 코드를 직접 작성하거나 모든 패치를 처음부터 검토하지 않는다. 하위 시스템 유지관리자가 전문 영역의 변경을 검토하고 정리한 뒤 토르발스에게 pull 요청을 보낸다.

이러한 구조에서는 공식적인 직급보다 기술적 기여와 지속적인 유지보수, 다른 개발자에게 얻은 신뢰가 중요하다. 개발자가 특정 영역에 오랫동안 기여하고 패치를 검토하며 책임을 맡으면 공동 유지관리자나 유지관리자로 참여할 수 있다.

기술적 의사 결정

Linux 커널의 변경은 일반적으로 다수결 투표보다 패치와 기술적 논의를 통해 결정된다. 개발자는 실제 코드를 제출하고, 관련 개발자와 유지관리자는 설계와 성능, 보안, 호환성과 장기 유지 가능성을 검토한다.

의견이 충돌할 때는 다음 요소가 판단에 영향을 준다.

• 실제로 해결하려는 문제가 분명한가
• 기존 사용자 공간과의 호환성을 유지하는가
• 다른 하위 시스템에 미치는 영향은 무엇인가
• 충분한 시험과 사용 사례가 있는가
• 코드를 장기적으로 유지할 개발자가 있는가
• 더 단순하거나 일반적인 해결 방식이 있는가
• 변경으로 얻는 효과가 복잡성과 위험을 정당화하는가

최종적으로 특정 하위 시스템에서는 담당 유지관리자가 패치 수용 여부를 판단하며, 메인라인 통합 단계에서는 토르발스가 pull 요청을 받아들이거나 거부할 수 있다.

유지관리자의 판단이 절대적이거나 영구적인 것은 아니다. 결정에 동의하지 않는 개발자는 기술적 근거와 수정된 패치를 다시 제시할 수 있고, 관련 공동체에서 대안을 논의할 수 있다. 자유 소프트웨어 라이선스에 따라 소스를 분기해 별도 커널을 만들 수도 있지만, 공식 메인라인과의 차이를 계속 유지해야 하는 비용이 발생한다.

배포판의 역할

Linux 커널 공동체가 커널을 개발하더라도 사용자가 설치하는 전체 운영체제를 직접 구성하지는 않는다. Linux 배포판은 커널과 사용자 공간 프로그램, 패키지 관리자, 설치 프로그램과 보안 정책을 조합한다.

배포판은 다음과 같은 결정을 내린다.

• 사용할 커널 버전과 패치
• C 라이브러리와 기본 명령줄 도구
• init 시스템과 서비스 구성
• 패키지 형식과 저장소
• 그래픽 환경과 기본 응용 프로그램
• 보안 설정
• 지원할 프로세서와 하드웨어
• 업데이트 주기
• 지원 종료 시점
• 자유 및 비자유 소프트웨어 포함 정책

Debian과 Arch Linux처럼 공동체 중심으로 운영되는 배포판이 있고, Red Hat Enterprise Linux와 Ubuntu, SUSE Linux Enterprise처럼 기업이 제품과 기술 지원을 제공하는 배포판도 있다. Fedora처럼 기업 지원을 받으면서 공개 공동체가 개발에 참여하는 형태도 존재한다.

배포판은 상위 프로젝트의 코드를 그대로 전달하기도 하지만, 자체 오류 수정과 통합 패치를 적용할 수도 있다. 장기적으로 유지하기 어려운 수정은 가능하면 상위 프로젝트에 제출하여 공식 코드에 포함시키는 것이 일반적으로 유리하다.

Linux Foundation

Linux Foundation은 Linux와 여러 오픈 소스 기술의 개발 및 산업 협력을 지원하는 비영리 단체다. 현재는 Linux뿐 아니라 클라우드, 컨테이너, 네트워크, 자동차, 보안, 인공지능과 오픈 표준을 포함한 다수의 프로젝트를 지원한다.

Linux Foundation은 스스로를 개발자와 조직이 오픈 기술 프로젝트와 생태계를 개발하고 관리하며 확장할 수 있도록 돕는 중립적인 협력 기반으로 설명한다.^[103]

Linux와 직접 관련된 주요 지원 활동에는 다음과 같은 것들이 있다.

• 주요 개발자의 활동과 고용 지원
• kernel.org 기반 시설 지원
• 개발자 행사와 기술 회의 운영
• 법률과 상표 관련 지원
• 기업과 개발 공동체의 협력 공간 제공
• 교육과 기술 인증
• 오픈 소스 보안과 공급망 사업
• 프로젝트 운영과 재정 관리 도구 제공
• 표준화와 산업 도입 지원

kernel.org를 운영하는 Linux Kernel Organization은 Linux Foundation의 관리 아래 있으며, 재단은 기반 시설의 운영에 필요한 기술적·재정적·인력 지원을 제공한다.^[104]

Linux Foundation이 커널 소스를 소유하거나 모든 패치를 승인하는 것은 아니다. 재단은 개발 기반과 행정·법률·재정 지원을 제공하지만, 커널의 기술적 결정은 토르발스와 하위 시스템 유지관리자, 개발 공동체의 절차를 통해 이루어진다.

Linux Foundation의 형성

Linux Foundation은 Linux 산업을 지원하던 Open Source Development Labs와 Free Standards Group이 2007년 합병하면서 현재의 이름과 조직으로 출범했다.

Open Source Development Labs는 기업과 개발자가 Linux를 서버와 산업 시스템에 적용할 수 있도록 개발 기반과 시험, 주요 개발자 지원을 제공했다. 리누스 토르발스도 이 조직의 지원 아래 커널 개발을 수행했다.

Free Standards Group은 Linux Standard Base와 관련 표준화를 추진하며 Linux 배포판 사이의 호환성과 상용 소프트웨어 이식성을 높이려 했다.

두 조직의 합병은 커널 개발 지원과 산업 표준화, 기업 협력을 하나의 비영리 기반 안에 결합했다. 이후 Linux Foundation은 Linux 중심 단체에서 여러 오픈 소스 프로젝트를 지원하는 대규모 우산 조직으로 확대되었다.

기업 회원과 재정적 참여

Linux Foundation은 개인 기부만으로 운영되지 않으며, 여러 기술·통신·반도체·자동차·금융 기업이 회원으로 참여하고 재정과 인력을 제공한다.

2026년 Linux Foundation이 발표한 최고 등급 회원에는 Google을 비롯하여 Ericsson, Fujitsu, Hitachi, Huawei, Intel, Meta, Microsoft, NEC, Oracle, Qualcomm, IBM·Red Hat과 Samsung 등이 포함되어 있다.^[105]

재단 회원은 다음과 같은 방식으로 생태계에 참여할 수 있다.

• 재정 지원
• 재단 이사회와 사업별 운영위원회 참여
• 개발자 고용
• 행사와 기반 시설 후원
• 특정 오픈 소스 프로젝트 참여
• 공동 표준과 산업 규격 개발
• 보안과 교육 사업 지원
• 자사 기술의 오픈 소스 공개

Linux Foundation의 회원이라는 사실이 해당 기업이 Linux 커널에 특정 양의 코드를 기여했다는 뜻은 아니다. 반대로 재단 회원이 아닌 기업이나 개인도 커널 패치를 제출하고 유지관리자가 될 수 있다.

재단의 회원 등급과 이사회 구성은 재정·조직적 거버넌스에 관한 것이며, Linux 커널의 패치 채택 권한과는 구분된다. 기업이 높은 회원 등급을 보유하더라도 기술적으로 부적절한 커널 변경을 메인라인에 포함시킬 권리는 얻지 않는다.

기업의 커널 기여

Linux 커널은 개인 자원봉사자뿐 아니라 기업에 고용된 개발자들의 기여를 통해 발전한다. 공식 커널 개발 문서는 하나의 개발 주기에 1,000명 이상의 개발자와 100개 이상의 기업 또는 무소속 개발자가 참여할 수 있다고 설명한다.^[106]

역사적으로 커널 개발에 많은 개발자를 참여시킨 기업에는 다음과 같은 곳들이 있다.

• Intel
• Red Hat
• IBM
• Google
• Samsung
• SUSE
• AMD
• Oracle
• Qualcomm
• Renesas
• Microsoft
• Meta
• NVIDIA
• 여러 반도체와 장치 제조사

기업별 기여량과 순위는 조사 기간과 커널 버전에 따라 달라지므로 고정된 순위로 볼 수 없다. 또한 커밋 수가 적더라도 복잡한 하위 시스템을 유지하거나 보안 수정과 시험 기반을 제공하는 기업이 있을 수 있다.

기업은 다음과 같은 사업적 필요 때문에 커널에 기여한다.

• 새로운 프로세서와 장치 지원
• 서버와 데이터 센터 성능 개선
• 클라우드와 가상화 기능
• Android와 소비자 기기 지원
• 자동차와 산업 장비
• 파일 시스템과 저장 장치
• 네트워크와 통신 장비
• 보안과 관측 기능
• 전력 관리
• 자사 제품의 장기 유지비용 절감

공식 커널에 기능을 포함하면 여러 배포판에서 자사 하드웨어와 서비스를 지원하기 쉬워진다. 내부 패치를 장기간 따로 유지하는 대신 다른 개발자와 비용을 분담하고, 상위 커널의 변경에 맞춰 공동으로 코드를 관리할 수 있다.

개인 개발자와 공동체

기업 참여가 크더라도 Linux 커널이 기업 연합만의 프로젝트인 것은 아니다. 특정 기업에 속하지 않은 개발자, 학생과 연구자, 독립 컨설턴트도 패치와 검토, 문서와 시험에 참여한다.

기여는 새로운 기능 개발에만 한정되지 않는다.

• 오류 보고
• 회귀 원인 탐색
• 패치 시험
• 코드 검토
• 문서 개선
• 정적 분석과 퍼징
• 보안 취약점 수정
• 오래된 드라이버 유지
• 개발 도구와 기반 시설 관리

커널 개발에서는 코드 작성자뿐 아니라 패치를 검토하고 장기간 책임지는 유지관리자의 역할이 중요하다. 기업이 작성한 코드라도 이후 유지할 주체가 없거나 다른 시스템에 미치는 영향이 충분히 검토되지 않으면 받아들여지기 어렵다.

메일링 리스트와 공개 Git 저장소를 중심으로 한 개발 방식은 소속과 지역이 다른 개발자가 같은 절차로 참여할 수 있게 한다. 반면 이메일 패치 문화와 방대한 기술 지식, 공개적인 검토 방식은 처음 참여하는 개발자에게 높은 진입 장벽이 될 수 있다.

기여와 영향력의 관계

Linux 커널에서 영향력은 재단 회원 등급이나 기업 규모만으로 결정되지 않는다. 특정 영역의 코드를 지속적으로 작성하고 검토하며 오류에 대응한 개발자는 해당 하위 시스템에서 높은 신뢰와 판단 권한을 얻을 수 있다.

기업은 개발자를 고용하여 장기간 참여하게 함으로써 기술적 영향력을 형성할 수 있다. 그러나 이는 패치를 강제로 채택시키는 권한이 아니라, 설계 논의에 참여하고 실제 구현과 유지보수를 책임질 능력을 확보하는 방식이다.

커널 코드에 포함된 기능은 특정 기업의 제품만이 아니라 전체 사용자에게 영향을 미칠 수 있다. 유지관리자는 한 기업의 요구와 커널 전체의 장기적인 구조가 충돌하지 않는지 검토한다.

기업의 요구가 지나치게 특수하면 범용 인터페이스로 다시 설계하거나, 공식 커널 밖의 별도 모듈과 패치로 유지해야 할 수 있다. 반대로 여러 사용자와 기업이 공통으로 필요로 하는 기능은 공식 하위 시스템으로 발전할 가능성이 높다.

상표와 소유권

Linux라는 이름의 상표는 리누스 토르발스가 보유하며, Linux Mark Institute가 사용 허가와 관련 업무를 수행한다. 이는 Linux Foundation이 Linux라는 명칭을 소유한다는 뜻이 아니다.

Linux 커널 코드의 저작권도 하나의 조직에 집중되어 있지 않다. 각 개발자와 기업은 자신이 작성한 코드의 저작권을 보유하며, Linux 커널의 라이선스 조건에 따라 이를 배포한다.

다수의 저작권자가 존재하므로 Linux 커널 전체를 한 기업이 인수하거나 임의로 폐쇄형 라이선스로 변경하기 어렵다. 커널의 라이선스 변경처럼 전체 코드에 영향을 주는 결정에는 수많은 권리자의 동의 문제가 발생한다.

Linux Foundation은 상표와 법률, 오픈 소스 라이선스 관련 지원을 제공할 수 있지만, 커널 전체의 단일 저작권자는 아니다.

행동 규범

Linux 커널 공동체는 기술적 검토 과정에서 개발자가 따라야 할 행동 규범을 채택하고 있다. 이 규범은 기여자의 배경과 관계없이 괴롭힘 없는 환경을 제공하고, 의견 충돌을 사람에 대한 공격이 아니라 기술적 문제에 집중하도록 요구한다.^[107]

커널 개발은 오랫동안 매우 직접적이고 거친 의사소통으로 알려져 있었다. 프로젝트 규모와 참여자의 다양성이 커지면서 기술적 비판과 개인적 공격을 구분하고, 공동체 내부 문제를 처리하기 위한 절차가 필요해졌다.

행동 규범이 기술적 판단을 대체하는 것은 아니다. 패치는 여전히 코드의 품질과 필요성, 호환성과 유지 가능성을 기준으로 검토되지만, 그 과정에서 참여자를 모욕하거나 배제하지 않도록 하는 공동체 기준을 제공한다.

GNU와의 관계

GNU 프로젝트는 Linux 커널 개발 조직이나 Linux Foundation 산하 프로젝트가 아니다. GNU와 Linux는 독립적으로 시작되고 별도의 공동체와 거버넌스를 가진 프로젝트다.

GNU는 자유로운 UNIX 호환 운영체제를 만들기 위해 GCC와 Bash, GNU Binutils, GNU Make, GNU Coreutils와 glibc 등 여러 사용자 공간 구성 요소를 개발했다. Linux가 등장했을 때 이러한 도구들은 Linux 위에 완전한 개발·사용 환경을 구성하는 데 중요한 역할을 했다.

GNU 프로젝트는 GNU 사용자 공간과 Linux 커널을 결합한 시스템을 GNU/Linux라고 부른다. GNU 측은 Linux가 커널이며, 널리 사용되는 전체 시스템의 상당 부분이 GNU 프로젝트에서 만들어졌다는 점을 강조한다.^[108]

그러나 Linux 커널 자체는 GNU 프로젝트가 관리하지 않으며, Linux Foundation도 GNU 프로젝트를 지휘하지 않는다. GCC와 glibc 같은 GNU 구성 요소의 기술적 결정은 해당 GNU 프로젝트 유지관리자와 자유 소프트웨어 재단의 별도 체계 아래 이루어진다.

또한 모든 Linux 기반 시스템이 GNU 사용자 공간을 사용하는 것은 아니다. Android는 Bionic과 Android 고유 사용자 공간을 사용하며, Alpine Linux는 musl과 BusyBox를 중심으로 구성된다. 따라서 GNU는 Linux 역사와 다수 배포판에서 중요한 관계를 가지지만 Linux 생태계 전체의 필수적 관리 주체는 아니다.

자유 소프트웨어와 오픈 소스

Linux 생태계에는 자유 소프트웨어와 오픈 소스라는 서로 겹치지만 강조점이 다른 관점이 공존한다.

GNU와 자유 소프트웨어 재단은 사용자가 프로그램을 실행하고 연구하며 수정하고 공유할 자유를 중심 가치로 강조한다. Linux Foundation과 많은 기업은 공개 협업과 공동 개발, 산업 혁신과 경제적 효율을 중심으로 오픈 소스를 설명하는 경우가 많다.

Linux 커널의 GPL 라이선스는 코드의 사용과 수정, 재배포를 허용하면서 배포되는 파생 커널 코드에 같은 자유를 유지하도록 요구한다. 이 법적 기반 위에서 개인의 자유 소프트웨어 활동과 기업의 상업적 개발이 동시에 이루어진다.

두 관점은 같은 소프트웨어와 개발 절차를 지지하면서도 목적과 언어에서 차이를 보일 수 있다. Linux 생태계에는 GNU의 자유 소프트웨어 철학을 따르는 배포판과, 실용적인 오픈 소스 개발과 상업 지원을 중심으로 운영되는 조직이 함께 존재한다.

관련 재단과 프로젝트

Linux 생태계는 Linux Foundation 하나로만 구성되지 않는다. 여러 비영리 단체와 재단이 관련 소프트웨어를 관리한다.

• Free Software Foundation — GNU와 자유 소프트웨어 운동
• Software Freedom Conservancy — 여러 자유·오픈 소스 프로젝트 지원
• GNOME Foundation — GNOME 생태계
• KDE e.V. — KDE 공동체의 법률·재정 지원
• Apache Software Foundation — 서버와 데이터 처리 프로젝트
• Eclipse Foundation — 개발 도구와 산업 프로젝트
• Cloud Native Computing Foundation — Kubernetes와 클라우드 네이티브 생태계
• Open Source Initiative — 오픈 소스 정의와 라이선스
• Debian Project — Debian 배포판 공동체
• X.Org Foundation — 그래픽 관련 프로젝트 지원

Cloud Native Computing Foundation과 같은 단체는 Linux Foundation 아래에 있지만 자체 기술 감독 조직과 운영 구조를 가진다. 모든 재단 산하 프로젝트가 Linux 커널의 거버넌스를 따르는 것은 아니다.

생태계의 조정

분산된 Linux 생태계는 공식 명령 체계 대신 개발자 회의와 메일링 리스트, 공개 표준과 배포판 통합 과정을 통해 조정된다.

Linux Plumbers Conference와 Linux Kernel Maintainers Summit 같은 행사는 서로 다른 하위 시스템 개발자가 공통 문제와 향후 인터페이스를 논의하는 자리다. 배포판과 데스크톱 프로젝트도 자체 개발자 회의와 릴리스 계획을 운영한다.

freedesktop.org의 규격과 D-Bus, 데스크톱 포털과 XDG 규격은 서로 다른 Linux 데스크톱과 응용 프로그램 사이의 공통 인터페이스를 제공한다. OCI와 Kubernetes 관련 규격은 컨테이너 도구와 클라우드 사업자 사이의 호환성을 높인다.

조정이 실패하면 서로 다른 init 시스템이나 패키지 형식, 그래픽 환경과 API가 경쟁할 수 있다. 이는 중복 개발과 호환성 문제를 만들지만, 하나의 기술이 생태계 전체에 강제로 고정되는 것을 막고 여러 접근 방식이 경쟁하게 하는 측면도 있다.

거버넌스의 특징

Linux의 거버넌스는 다음과 같은 특징을 가진다.

• 커널과 사용자 공간 프로젝트의 관리 주체가 분리되어 있다.
• 기술 결정은 실제 코드와 공개 검토를 중심으로 이루어진다.
• 하위 시스템별 유지관리자에게 책임이 분산된다.
• 메인라인 커널의 최종 통합은 중앙화되어 있다.
• 개인과 기업이 같은 공개 절차로 기여할 수 있다.
• 기업은 개발자 고용과 재정 지원을 통해 참여한다.
• 재단의 회원 자격과 기술적 패치 채택 권한은 구분된다.
• 소스와 저작권이 여러 기여자에게 분산되어 있다.
• 배포판은 독립적으로 구성 요소와 정책을 선택한다.
• 프로젝트를 분기할 자유가 있지만 유지 비용이 따른다.

이 구조는 Linux가 개인 프로젝트에서 세계적인 산업 기반으로 성장하면서도 특정 기업의 단일 제품으로 편입되지 않게 한 요인이다.

동시에 중요한 하위 시스템이 소수의 유지관리자에게 의존하거나, 기업의 필요와 공동체의 장기적인 방향이 충돌하고, 여러 프로젝트 사이에서 변경을 조정해야 하는 문제가 계속 발생한다. Linux의 거버넌스는 완성된 고정 제도라기보다 기술 규모와 참여 주체의 변화에 맞춰 지속적으로 조정되는 공개 협력 구조다.

Linux는 기존 운영체제의 소스 코드를 직접 이어받아 만들어진 것이 아니라, UNIX의 구조와 프로그래밍 인터페이스를 참고하여 독립적으로 개발된 운영체제 커널이다. Linux 커널 문서도 Linux를 UNIX와 유사한 기능을 제공하도록 처음부터 새로 작성된 구현이며, POSIX와 Single UNIX Specification에 대한 호환성을 지향한다고 설명한다.^[109]

이 때문에 Linux는 UNIX와 직접적인 소스 계보를 공유하지 않지만 일반적으로 유닉스 계열 운영체제로 분류된다. 프로세스와 파일 디스크립터, 계층형 파일 시스템, 셸과 명령줄 도구, 사용자와 권한 모델 등 많은 기본 개념을 UNIX 환경과 공유한다.

Linux는 이후 서버와 데스크톱, 스마트폰과 임베디드 분야로 확산되면서 다른 운영체제와 경쟁하는 한편, 가상화와 호환 계층, 공통 표준을 통해 서로의 응용 프로그램과 개발 환경을 연결하는 역할도 하게 되었다.

UNIX

Linux는 UNIX의 영향을 강하게 받았지만 역사적인 UNIX 소스 계보에 포함되지는 않는다. System V와 BSD처럼 원본 UNIX에서 직접 분기된 운영체제와 달리, Linux는 공개된 인터페이스와 문서, MINIX와 기존 UNIX 시스템의 사용 경험을 바탕으로 독립적으로 구현되었다.

두 계열은 다음과 같은 개념을 공유한다.

• 프로세스와 신호
• 파일 디스크립터
• 모든 자원을 파일과 유사한 인터페이스로 다루는 방식
• 사용자와 그룹, 파일 권한
• 셸과 파이프
• 계층형 파일 시스템
• 장치 파일
• C 언어 기반의 시스템 프로그래밍
• POSIX 계열 API

Linux는 UNIX의 설계 전통을 따르면서도 epoll과 cgroups, 네임스페이스, eBPF와 io_uring 같은 고유 인터페이스를 발전시켰다. 이러한 기능은 기존 UNIX 표준에는 포함되지 않으며 Linux 플랫폼의 독자적인 특성을 형성한다.

UNIX는 The Open Group이 관리하는 등록 상표이므로, 공식 UNIX 제품이라는 명칭은 인증을 받은 특정 운영체제와 버전에만 사용할 수 있다. 일반적인 Linux 배포판은 하나의 고정 제품으로 UNIX 인증을 받지 않으므로 기술적으로는 UNIX가 아니라 유닉스 계열로 표현된다.

BSD

BSD 계열과 Linux는 UNIX식 인터페이스와 오픈 소스 개발 방식을 공유하지만 서로 다른 계보와 라이선스, 개발 구조를 가진다.

FreeBSD와 OpenBSD, NetBSD는 원본 BSD UNIX에서 이어진 코드를 바탕으로 발전했다. Linux는 UNIX와 BSD의 동작 방식을 참고했지만 커널 코드는 별도로 작성되었다.

두 계열의 주요 차이는 다음과 같다.

• Linux는 일반적으로 커널과 사용자 공간이 서로 다른 프로젝트에서 개발된다.
• BSD 프로젝트는 커널과 기본 사용자 공간을 하나의 운영체제 소스 트리로 함께 관리하는 경우가 많다.
• Linux 커널은 GPL 계열 라이선스를 사용한다.
• BSD 계열은 수정된 코드를 공개하지 않고 제품에 포함할 수도 있는 허용적 BSD 라이선스를 주로 사용한다.
• Linux는 여러 독립 배포판이 존재한다.
• BSD에서는 FreeBSD와 OpenBSD, NetBSD 자체가 각각 완성된 운영체제 프로젝트다.

Linux와 BSD는 같은 POSIX 및 UNIX 인터페이스를 구현하므로 많은 오픈 소스 프로그램을 소스 수준에서 서로 이식할 수 있다. 다만 시스템 호출과 네트워크 관리, 장치 인터페이스와 명령 옵션이 달라 수정이 필요할 수 있다.

서로의 기술이 교류되기도 한다. Linux는 BSD에서 발전한 네트워크 코드와 도구, 라이선스가 허용하는 여러 구성 요소를 사용해 왔으며, BSD 운영체제도 Linux에서 널리 쓰인 소프트웨어와 파일 시스템, 드라이버와 사용자 공간 도구를 도입할 수 있다.

FreeBSD는 Linux 실행 파일을 실행하기 위한 선택적 바이너리 호환 계층인 Linuxulator를 제공한다. 이 계층은 Linux ELF 실행 파일과 시스템 호출을 FreeBSD 환경에 연결하여 일부 수정되지 않은 Linux 프로그램을 실행할 수 있게 한다.^[110]

Linux와 BSD는 서버와 네트워크 장비, 저장 시스템과 임베디드 환경에서 경쟁해 왔다. Linux는 하드웨어와 기업 지원, 배포판과 클라우드 생태계에서 더 넓은 범위를 형성했으며, BSD는 통합된 기본 시스템과 허용적 라이선스, 특정 네트워크·스토리지 분야에서 독자적인 위치를 유지한다.

macOS와 Darwin

macOS는 Apple이 개발하는 데스크톱 운영체제이며, Linux 커널이 아니라 XNU 커널과 Darwin 기반을 사용한다.

Darwin은 Mach 계열 기술과 BSD 구성 요소를 결합한 운영체제 기반이다. 따라서 macOS는 Linux와 달리 역사적인 UNIX 및 BSD 기술과 직접적인 코드 관계를 가진다. Apple은 Darwin과 여러 관련 구성 요소의 소스 코드를 공개하고 있다.^[111]

macOS와 Linux는 POSIX 및 UNIX 계열 프로그래밍 환경을 공유하므로 다음 도구와 프로그램을 양쪽에서 사용할 수 있다.

• 셸과 터미널 프로그램
• C와 C++ 컴파일러
• Git
• Python과 여러 프로그래밍 언어
• POSIX 시스템 API
• UNIX 계열 서버 프로그램
• 다수의 오픈 소스 명령줄 도구

그러나 두 시스템은 커널과 그래픽 환경, 장치 드라이버, 패키지 관리와 응용 프로그램 API가 다르다. Linux 응용 프로그램을 macOS에서 그대로 실행할 수 있는 것은 아니며, 소스 코드를 다시 빌드하거나 운영체제별 코드를 수정해야 할 수 있다.

macOS는 Aqua와 Cocoa, Metal과 Apple 전용 프레임워크를 사용한다. Linux 데스크톱은 GTK와 Qt, Wayland 또는 X11을 중심으로 구성되므로 그래픽 응용 프로그램의 직접적인 바이너리 호환성은 없다.

Apple은 일부 macOS 버전을 UNIX 규격에 맞춘 인증 제품으로 제공해 왔다. 이는 Linux와 macOS가 모두 유닉스 계열이라는 사실과 별개로, macOS의 특정 제품 구성이 공식 UNIX 인증을 받았다는 차이를 만든다.

Linux와 macOS는 개발자용 데스크톱과 UNIX 서버 개발 환경에서 경쟁하지만, 실제 개발에서는 macOS에서 Linux 서버와 컨테이너를 원격으로 사용하거나 가상 머신에서 Linux를 실행하는 방식으로 함께 사용되기도 한다.

Windows

Windows는 Linux와 다른 계보와 시스템 구조, 프로그래밍 인터페이스를 가진 운영체제다. Windows NT 계열은 UNIX가 아니라 Microsoft의 독자적인 커널과 Win32 API, NT 객체 모델을 중심으로 발전했다.

Linux와 Windows는 오랫동안 개인용 컴퓨터와 서버 시장에서 경쟁해 왔다.

Windows는 다음 영역에서 강점을 가져왔다.

• 일반 소비자용 개인용 컴퓨터
• 상용 데스크톱 응용 프로그램
• 기업용 Active Directory 환경
• DirectX 기반 게임
• 제조사가 제공하는 하드웨어 지원
• Microsoft 개발 도구와 업무 소프트웨어

Linux는 다음 영역에서 강한 위치를 형성했다.

• 웹과 인터넷 서버
• 클라우드와 컨테이너
• 슈퍼컴퓨터
• 네트워크 장비
• 임베디드 시스템
• 오픈 소스 개발 환경
• 운영체제 사용자화와 자동화

두 시스템의 실행 파일과 시스템 API는 기본적으로 호환되지 않는다. Windows 프로그램은 PE 형식과 Win32·NT API를 사용하고, Linux 프로그램은 주로 ELF와 Linux 시스템 호출, POSIX 계열 API를 사용한다.

그러나 네트워크 표준과 프로그래밍 언어, 파일 형식과 크로스 플랫폼 프레임워크를 통해 같은 응용 프로그램과 서비스를 두 시스템에서 제공할 수 있다. Java와 .NET, Qt, Electron과 웹 기술은 운영체제 차이를 추상화하는 데 사용된다.

Microsoft는 Azure와 서버·개발 도구 사업이 확대되면서 Linux를 경쟁 운영체제일 뿐 아니라 핵심 지원 플랫폼으로 다루게 되었다. Windows와 Linux를 함께 사용하는 개발과 운영 환경도 보편화되었다.

Windows Subsystem for Linux

WSL은 Windows 안에서 Linux 배포판과 명령줄 프로그램을 실행할 수 있도록 하는 기능이다.

초기의 WSL 1은 Linux 시스템 호출을 Windows 커널의 기능으로 변환하는 호환 계층을 사용했다. Linux 커널을 직접 실행하지 않고 Linux ELF 프로그램이 요청한 시스템 호출을 Windows NT 환경에서 처리했다.

WSL 2는 경량 가상 머신 안에서 실제 Linux 커널을 실행하는 방식으로 변경되었다. 이를 통해 기존보다 높은 시스템 호출 호환성과 컨테이너, 파일 시스템과 네트워크 기능을 제공한다.

Microsoft는 WSL을 별도의 전통적인 가상 머신이나 이중 부팅 없이 Windows에서 Linux 환경과 도구를 사용할 수 있도록 설계된 기능으로 설명한다.^[112]

WSL에서는 Ubuntu와 Debian, openSUSE와 여러 Linux 배포판의 사용자 공간을 설치할 수 있다. 개발자는 Windows용 편집기와 브라우저, 업무 프로그램을 사용하면서 Linux 셸과 컴파일러, 패키지 관리자와 컨테이너 도구를 함께 사용할 수 있다.

WSL은 Windows를 Linux로 바꾸는 기능은 아니다. Windows가 호스트 운영체제로 유지되며, Linux 환경은 Windows 파일과 네트워크, 그래픽 및 개발 도구와 통합된다.

WSL의 확산은 Linux 개발 환경이 Linux 데스크톱 사용자에게만 한정되지 않게 했다. Windows 개발자도 로컬에서 Linux 서버와 유사한 환경을 사용하고, Linux용 소프트웨어를 빌드하고 시험할 수 있게 되었다.

Wine과 Windows 응용 프로그램

Wine은 Linux와 BSD, macOS 같은 POSIX 계열 운영체제에서 Windows 응용 프로그램을 실행하기 위한 호환 계층이다.

Wine은 완전한 Windows 운영체제를 가상 머신으로 실행하는 방식이 아니다. Windows 프로그램이 호출하는 Win32와 관련 API를 자체 구현하고, 이를 호스트 운영체제의 그래픽과 파일, 네트워크 기능으로 연결한다. Wine이라는 이름은 “Wine Is Not an Emulator”라는 재귀 약어에서 유래했다.^[113]

Wine은 다음과 같은 구성 요소를 제공한다.

• Windows 실행 파일 로더
• Win32와 여러 Windows DLL 구현
• Windows 레지스트리와 유사한 설정
• Direct3D와 그래픽 API 변환
• Windows 파일 경로와 UNIX 파일 시스템 연결
• 오디오와 입력 장치 통합

모든 Windows 프로그램이 완벽하게 동작하는 것은 아니다. 특정 드라이버와 커널 구성 요소, 디지털 권리 관리, 안티치트와 최신 Windows 내부 동작에 의존하는 프로그램은 실행되지 않거나 제한될 수 있다.

Valve의 Proton은 Wine을 기반으로 게임 실행에 필요한 DirectX 변환과 패치, 실행 환경을 통합한다. 이를 통해 많은 Windows용 게임이 Linux 기반 Steam 환경에서 실행될 수 있게 되었다.

Wine은 Linux와 Windows 사이의 관계가 단순한 경쟁에 그치지 않고, 응용 프로그램 생태계를 호환 계층으로 연결할 수 있음을 보여준다.

Android

Android는 Linux 커널을 사용하는 운영체제지만 일반적인 데스크톱·서버 Linux 배포판과는 다른 사용자 공간과 응용 프로그램 플랫폼을 가진다.

Android는 다음 요소를 사용한다.

• Linux 커널
• Bionic C 라이브러리
• Android Runtime
• Binder 기반 프로세스 간 통신
• Android 응용 프로그램 프레임워크
• APK와 Android 패키지 체계
• Android 전용 그래픽과 미디어 구성

Android Open Source Project는 커널을 장치 하드웨어와 통신하는 운영체제의 중심 구성 요소로 설명하며, 하드웨어 독립 부분과 제조사별 모듈을 분리하는 구조를 사용한다.^[114]

Android의 Linux 커널은 메인라인 및 장기지원 Linux 커널을 기반으로 하지만 Android에 필요한 기능과 장치 지원을 추가한다. Android common kernel 개발에서는 Linux 메인라인의 변경을 지속적으로 병합하고 Android 기능을 관리한다.^[115]

Android는 GNU Coreutils와 glibc, 일반적인 Linux 데스크톱 환경을 사용하지 않는다. 따라서 Linux 커널을 기반으로 하지만 전통적인 GNU/Linux 배포판으로 분류하지 않는 경우가 많다.

일반 Linux 응용 프로그램은 Android에서 그대로 실행되지 않으며, Android 응용 프로그램도 일반 Linux 데스크톱에서 직접 실행되지 않는다. 다만 두 환경은 같은 커널 계열과 여러 오픈 소스 라이브러리를 공유하고, 컨테이너와 호환 계층을 이용한 상호 실행 기술이 개발되어 있다.

Android의 보급은 Linux 커널을 세계에서 가장 널리 사용되는 소비자 장치 기반 가운데 하나로 만들었다.

ChromeOS

ChromeOS와 그 오픈 소스 기반인 ChromiumOS도 Linux 커널을 사용하는 운영체제다.

ChromiumOS는 초기에는 특정 Ubuntu 기반 커널을 사용했으나 이후 업스트림 Linux 메인라인을 직접 추적하고, 필요한 기능과 안정성 변경을 적용하는 방향으로 발전했다.^[116]

ChromeOS는 웹 브라우저와 클라우드 서비스를 중심으로 설계되었으며, 일반적인 Linux 데스크톱 배포판과 다른 부팅·보안·업데이트와 사용자 인터페이스 구조를 가진다.

ChromeOS는 Linux 기반이지만 사용자가 전통적인 Linux 시스템을 직접 관리하지 않도록 설계되었다. 시스템 파티션과 업데이트, 응용 프로그램 실행 환경이 Google의 관리 체계에 맞춰 구성된다.

Crostini 기능은 가상 머신과 컨테이너를 이용하여 ChromeOS 안에서 별도의 Linux 개발 환경을 제공한다. ChromeOS는 임의의 Linux 프로그램을 호스트 시스템에 직접 실행시키는 대신, 가상 머신 안의 Linux 컨테이너에 격리하여 실행한다.^[117]

이에 따라 ChromeOS는 Linux 커널을 내부 기반으로 사용하면서도, 별도의 Linux 사용자 환경을 다시 가상화하여 제공하는 계층적 구조를 가진다.

임베디드 및 전용 운영체제

Linux는 여러 전용 운영체제와 제품 플랫폼의 커널로 사용된다.

스마트 텔레비전과 라우터, 자동차 인포테인먼트, 네트워크 장비와 산업 시스템은 Linux 커널 위에 제품별 사용자 공간과 그래픽 환경, 관리 인터페이스를 구성할 수 있다.

이러한 시스템은 일반적인 Linux 배포판과 같은 패키지 관리자나 셸을 사용자에게 제공하지 않을 수 있다. 운영체제는 특정 응용 프로그램만 실행하고, 업데이트는 전체 시스템 이미지 교체 방식으로 이루어질 수 있다.

Linux 기반 전용 운영체제에는 다음과 같은 계열이 있다.

• Android와 파생 모바일 운영체제
• ChromeOS와 ChromiumOS
• 스마트 텔레비전 플랫폼
• 라우터와 네트워크 장비용 배포판
• 자동차용 Linux 플랫폼
• 게임기와 휴대용 게임 장치의 Linux 기반 시스템
• NAS와 저장 장치 운영체제
• 산업·로봇용 Linux 이미지

이들은 같은 Linux 커널을 사용하더라도 사용자 공간과 응용 프로그램 API, 관리 방식이 다르므로 서로 직접 호환되지 않을 수 있다.

실시간 운영체제

Linux는 범용 운영체제이지만 스케줄링과 선점 지연을 줄여 실시간 요구에 대응할 수 있다.

PREEMPT_RT와 실시간 스케줄링 정책을 사용하는 Linux는 산업 제어와 오디오, 통신과 일부 자동차 시스템에서 사용된다. 그러나 모든 Linux 구성이 엄격한 시간 제한을 보장하는 것은 아니다.

실시간 운영체제는 일반적으로 특정 작업이 정해진 시간 안에 완료된다는 예측 가능성을 우선한다. FreeRTOS와 QNX, VxWorks와 여러 소형 RTOS는 제한된 기능과 자원 환경에서 엄격한 실시간 제어를 제공한다.

복잡한 제품에서는 Linux와 실시간 운영체제를 함께 사용할 수 있다.

• Linux는 그래픽과 네트워크, 파일과 응용 프로그램을 처리한다.
• 실시간 운영체제는 모터와 센서, 안전 중요 제어를 담당한다.
• 하이퍼바이저가 두 운영체제를 같은 하드웨어에서 분리한다.
• 별도 프로세서나 마이크로컨트롤러가 실시간 작업을 수행한다.

이 관계에서 Linux는 RTOS를 완전히 대체하기보다, 풍부한 사용자 공간과 연결 기능을 담당하며 실시간 운영체제를 보완한다.

가상 머신의 게스트와 호스트

Linux는 다른 운영체제와 가상화 계층을 통해 함께 실행될 수 있다.

Linux는 KVM과 Xen, Hyper-V와 VMware 등의 가상화 환경에서 게스트 운영체제로 실행된다. 반대로 KVM과 QEMU를 사용하는 Linux는 Windows와 BSD, 다른 Linux 배포판을 실행하는 호스트가 될 수 있다.

가상화는 다음과 같은 관계를 가능하게 한다.

• Linux 호스트에서 Windows 서버 실행
• Windows 호스트에서 Linux 가상 머신 실행
• macOS에서 Linux 개발 환경 실행
• Linux 클라우드 호스트에서 여러 고객 운영체제 실행
• 한 장치에서 Linux와 실시간 운영체제 분리
• 오래된 운영체제를 새 하드웨어에서 유지

Virtio와 Hyper-V의 합성 장치처럼 가상화 전용 인터페이스는 운영체제 사이의 입출력 효율을 높인다. Linux 커널에는 여러 하이퍼바이저의 게스트·호스트 지원 코드가 포함되어 있다.

다른 운영체제에 대한 영향

Linux는 UNIX의 영향을 받아 시작했지만 성장 이후에는 다른 운영체제의 구조와 산업 생태계에도 영향을 주었다.

주요 영향에는 다음이 포함된다.

• 공개 저장소와 분산 버전 관리에 기반한 대규모 개발
• 운영체제 구성 요소의 오픈 소스 공개 확대
• Linux 호환 개발 환경과 시스템 호출 계층 등장
• 컨테이너와 cgroups·네임스페이스 모델 확산
• 클라우드 운영체제 설계의 중심 플랫폼 형성
• 오픈 소스 드라이버와 하드웨어 지원 확대
• 패키지 저장소와 자동 업데이트 방식의 대중화
• 개발자 중심의 셸·명령줄 환경 재평가

Windows가 WSL을 통해 Linux 개발 환경을 직접 제공하고, BSD가 Linux 바이너리 호환 계층을 유지하며, ChromeOS가 Linux 개발 컨테이너를 제공하는 현상은 Linux 응용 프로그램과 도구 생태계가 독립적인 호환 대상으로 자리 잡았음을 보여준다.

경쟁과 상호운용

Linux와 다른 운영체제의 관계는 어느 하나가 다른 것을 완전히 대체하는 단순한 경쟁으로 설명하기 어렵다.

개인용 컴퓨터에서는 Linux와 Windows, macOS가 서로 다른 응용 프로그램과 사용자 경험을 제공하며 경쟁한다. 서버와 클라우드에서는 Linux가 강한 위치를 차지하지만 Windows Server와 UNIX 계열 제품도 특정 기업 환경과 응용 프로그램에서 사용된다.

스마트폰에서는 Android가 Linux 커널을 사용하지만 Apple의 iOS와 별도의 플랫폼 경쟁을 한다. 차량과 산업 시스템에서는 Linux와 여러 실시간 운영체제가 서로 역할을 분담한다.

개발 환경에서는 한 컴퓨터에서 여러 운영체제를 동시에 사용하기도 한다.

• Windows에서 WSL로 Linux 도구 사용
• Linux에서 Wine으로 Windows 응용 프로그램 실행
• macOS에서 Linux 컨테이너와 가상 머신 사용
• FreeBSD에서 Linux 바이너리 실행
• Linux 호스트에서 Windows와 BSD 가상 머신 운영
• 공통 POSIX 소스 코드를 여러 운영체제에서 빌드

따라서 Linux는 다른 운영체제와 경쟁하면서도 POSIX와 네트워크 표준, 가상화와 호환 계층을 통해 연결된다. Linux의 확산은 하나의 운영체제가 모든 환경을 통일한 결과라기보다, 여러 운영체제가 서로 다른 역할을 유지하면서 Linux 인터페이스와 개발 도구를 공통 기반으로 받아들인 과정에 가깝다.

Linux는 개인 개발자의 실험적인 UNIX 호환 커널에서 출발했지만, 이후 서버와 클라우드, 스마트폰, 슈퍼컴퓨터, 임베디드 장치와 산업 시스템을 연결하는 공통 기반으로 발전했다. 그 영향은 Linux를 직접 사용하는 장치의 수에만 있지 않다. 오픈 소스 공동 개발, 하드웨어 지원 방식, 소프트웨어 배포와 클라우드 운영의 구조에도 변화를 일으켰다.

오픈 소스 개발의 산업화

Linux 이전에도 자유 소프트웨어와 공개 소스 프로젝트는 존재했지만, Linux는 세계 여러 지역의 개인과 기업이 하나의 대규모 핵심 시스템을 공개적으로 공동 개발할 수 있음을 보여준 대표적인 사례가 되었다.

Linux 커널의 변경은 공개 메일링 리스트와 Git 저장소에서 검토되며, 개인 개발자와 경쟁 관계에 있는 기업들이 동일한 코드 기반에 기여한다. 반도체 제조사와 클라우드 사업자, 배포판 업체와 장치 제조사는 각자 필요한 기능을 개발하면서 공통 커널의 유지비용을 분담한다.

이 방식은 기업이 오픈 소스를 단순히 무료 소프트웨어로 사용하는 수준을 넘어, 개발자를 고용하고 상위 프로젝트에 직접 기여하며 기술 방향에 참여하는 사업 모델을 확산시켰다.

Linux를 중심으로 형성된 공동 개발 방식은 다음과 같은 분야에도 영향을 주었다.

• 프로그래밍 언어와 컴파일러
• 데이터베이스
• 웹 서버
• 컨테이너와 클라우드
• 인공지능과 데이터 처리
• 네트워크 운영체제
• 자동차와 임베디드 플랫폼
• 산업 표준과 공개 참조 구현

Linux의 성공은 기업이 독점적으로 개발하던 기반 소프트웨어도 여러 조직이 공개적으로 공동 개발할 수 있다는 인식을 넓혔다.

Git과 분산 개발

Linux 커널 개발 과정에서 기존 버전 관리 도구를 둘러싼 문제가 발생하자 리누스 토르발스는 2005년 Git을 개발했다. Git은 거대한 커널 소스와 수많은 분기, 빠른 병합과 분산된 개발자 저장소를 처리하기 위해 설계되었다.

Git은 이후 Linux 커널을 넘어 소프트웨어 개발의 대표적인 분산 버전 관리 시스템으로 확산되었다. GitHub와 GitLab, Codeberg와 여러 코드 호스팅 서비스도 Git 저장소와 브랜치, 코드 검토를 중심으로 발전했다.

이에 따라 Linux는 운영체제 기술뿐 아니라 현대 소프트웨어 협업 방식에도 직접적인 영향을 남겼다. 개발자가 중앙 서버에 항상 연결되지 않아도 전체 저장소를 복제하고 독립적으로 커밋과 브랜치를 관리한 뒤 변경을 교환하는 방식이 널리 보급되었다.

서버와 인터넷 기반

Linux는 웹 서버와 데이터베이스, 네트워크 서비스와 대규모 인터넷 플랫폼의 주요 실행 기반이 되었다. 공개된 소스와 자동화 가능한 관리 환경, 다양한 서버 하드웨어 지원은 인터넷 서비스 사업자가 자체 요구에 맞게 시스템을 구성할 수 있도록 했다.

Linux 기반 서버 환경에서는 특정 제조사의 운영체제와 하드웨어를 하나의 묶음으로 구입하지 않고, 여러 제조사의 하드웨어와 오픈 소스 소프트웨어, 상용 지원을 선택적으로 결합할 수 있었다.

이 과정에서 다음과 같은 운영 방식이 확산되었다.

• 원격 명령줄 관리
• 패키지 저장소를 통한 중앙 배포
• 설정과 시스템 구축 자동화
• 서비스별 최소 운영체제 구성
• 여러 서버를 하나의 집합으로 관리
• 공개 프로토콜과 오픈 소스 서버 소프트웨어 활용
• 시스템을 코드와 이미지로 재현하는 방식

현대의 인터넷 서비스는 Linux 자체만으로 구성되는 것은 아니지만, Linux는 웹 서버와 데이터베이스, 언어 런타임과 분산 시스템이 실행되는 공통 기반으로 자리 잡았다.

클라우드 컴퓨팅

Linux는 현대 클라우드 컴퓨팅의 호스트와 게스트 운영체제, 컨테이너 커널과 네트워크 기반으로 사용되었다.

KVM은 Linux를 하이퍼바이저로 사용할 수 있게 했으며, 네임스페이스와 cgroups는 컨테이너 격리와 자원 관리의 기반이 되었다. 이러한 기능 위에서 OpenStack과 Docker, Kubernetes와 여러 클라우드 플랫폼이 발전했다.

클라우드 환경에서 Linux가 널리 사용되면서 운영체제는 한 대의 물리 서버에 장기간 설치해 수동으로 관리하는 제품에서, 필요할 때 자동 생성하고 교체하는 가상 머신 이미지와 컨테이너 호스트로도 다뤄지게 되었다.

Linux의 영향으로 확산된 운영 방식에는 다음이 포함된다.

• 인프라스트럭처 애즈 코드
• 이미지 기반 서버 배포
• 가상 머신과 컨테이너의 자동 생성
• 불변에 가까운 시스템 구성
• 분산 서비스와 자동 확장
• 소프트웨어 정의 네트워크
• 대규모 관측과 자동 복구

Linux는 클라우드 사업자가 서로 다른 프로세서와 저장 장치, 네트워크 기술을 공통된 운영체제 환경 아래 제공하는 기반이 되었다.

컨테이너 생태계

Linux의 네임스페이스와 cgroups는 하나의 커널 위에서 여러 사용자 공간을 분리하는 컨테이너 기술의 핵심이 되었다.

운영체제 수준 가상화는 OpenVZ와 LXC 같은 시스템 컨테이너에서 발전했고, Docker는 응용 프로그램과 의존성을 이미지로 묶어 배포하는 방식을 대중화했다. 이후 OCI 규격과 containerd, CRI-O와 Kubernetes를 중심으로 여러 도구가 상호 운용되는 생태계가 형성되었다.

컨테이너는 다음과 같은 소프트웨어 개발 방식에 영향을 주었다.

• 개발과 운영 환경의 차이 축소
• 응용 프로그램별 의존성 분리
• 이미지 단위의 배포와 되돌리기
• 마이크로서비스 구조
• 지속적 통합과 지속적 배포
• 서버 자원의 고밀도 사용
• 클라우드 사이의 응용 프로그램 이전

컨테이너가 모든 가상화와 배포 문제를 해결한 것은 아니지만, Linux 커널 기능이 응용 프로그램의 전달 단위를 바꾼 대표적인 사례가 되었다.

슈퍼컴퓨터와 과학 계산

Linux는 슈퍼컴퓨터와 고성능 컴퓨팅에서 지배적인 운영체제 기반으로 자리 잡았다. TOP500의 운영체제 계열 통계에서 Linux는 현대 슈퍼컴퓨터의 사실상 공통 기반으로 나타난다.^[118]

연구 기관과 제조사는 Linux의 소스를 수정하여 대규모 프로세서와 가속기, 고속 네트워크와 병렬 파일 시스템에 맞게 조정할 수 있었다. 특정 제조사의 전용 UNIX에 의존하기보다 공통 Linux 기반 위에서 하드웨어별 최적화를 적용하는 방식이 확대되었다.

Linux의 확산은 슈퍼컴퓨터에서도 일반 서버와 비슷한 개발 도구와 언어, 오픈 소스 라이브러리를 사용할 수 있게 했다. 연구용 프로그램을 소규모 Linux 워크스테이션에서 개발한 뒤 대형 계산 시스템으로 이전하는 흐름도 형성되었다.

모바일 컴퓨팅

Android가 Linux 커널을 채택하면서 Linux는 서버와 개발자용 컴퓨터를 넘어 대규모 소비자 모바일 기기의 기반이 되었다.

Android는 일반적인 GNU/Linux 배포판과 다른 사용자 공간과 응용 프로그램 체계를 사용하지만, 프로세스와 메모리, 장치와 보안을 관리하는 기반에는 Linux 커널이 있다. Android의 커널은 업스트림 장기지원 Linux 커널을 바탕으로 Android 관련 변경을 결합한다.^[119]

이로 인해 Linux 커널은 스마트폰과 태블릿, 텔레비전과 자동차용 Android 시스템, 여러 소비자 장치에 사용되었다. 일반 사용자가 Linux라는 이름을 직접 인식하지 않더라도 Linux 커널을 사용하는 환경과 접하게 되었다.

Android의 확산은 Linux가 전통적인 데스크톱 환경을 사용하지 않아도 독자적인 응용 프로그램 플랫폼의 커널로 활용될 수 있음을 보여주었다.

임베디드와 하드웨어 생태계

Linux는 처음에는 x86 개인용 컴퓨터를 대상으로 시작했지만, 이후 ARM과 ARM64, RISC-V, MIPS, PowerPC와 여러 프로세서 아키텍처로 이식되었다. Linux 커널 문서는 현재 다양한 범용·서버·임베디드 프로세서 아키텍처를 구분하여 관리한다.^[120]

제조사는 새로운 프로세서와 장치를 Linux에서 지원하기 위해 드라이버와 플랫폼 코드를 상위 커널에 기여할 수 있다. 공식 커널에 지원 코드가 포함되면 여러 배포판과 제품에서 같은 하드웨어를 사용할 수 있으므로, Linux 지원 여부가 하드웨어 시장성과 개발 편의성에 영향을 주기도 한다.

Linux의 장치 드라이버와 네트워크, 파일 시스템과 전원 관리 기능은 라우터와 텔레비전, 저장 장치, 산업 설비와 자동차 시스템을 처음부터 새로 개발하지 않고 구성할 수 있는 기반을 제공했다.

그 결과 Linux는 범용 운영체제이면서 동시에 제품별 전용 운영체제를 만드는 재료로 사용되었다.

운영체제 경쟁 구조

Linux는 서버와 워크스테이션 시장에서 상용 UNIX의 위치를 크게 대체했다. 과거에는 하드웨어 제조사마다 자체 UNIX 계열 운영체제를 제공했지만, Linux가 여러 아키텍처와 서버에서 동작하면서 하드웨어와 운영체제의 결합이 약해졌다.

기업은 특정 제조사의 UNIX 대신 여러 업체가 지원하는 Linux 배포판을 선택할 수 있게 되었고, 하드웨어 제조사도 자체 범용 운영체제를 독자적으로 유지하기보다 Linux 지원에 투자할 수 있었다.

Linux는 Windows와 macOS에도 영향을 주었다. Microsoft는 WSL과 Azure를 통해 Linux를 핵심 개발·클라우드 플랫폼으로 지원하게 되었고, 다른 UNIX 계열 운영체제는 Linux 바이너리 또는 개발 환경과의 호환성을 제공하기도 했다.

Linux의 영향은 모든 운영체제를 Linux로 대체한 것이 아니라, 다른 운영체제와 플랫폼이 Linux 응용 프로그램과 도구, 컨테이너와 서버 환경을 중요한 호환 대상으로 다루게 했다는 데 있다.

자유로운 수정과 제품 개발

Linux 커널은 GPL-2.0-only 조건으로 배포되며, 커널 전체에 적용되는 라이선스와 시스템 호출 예외가 공식 소스에 명시되어 있다.^[121]

기업과 개인은 커널을 연구하고 수정하여 자체 서버와 장치, 운영체제 제품에 사용할 수 있다. 배포하는 파생 커널 코드에는 라이선스 의무가 적용되지만, Linux 위에서 실행되는 일반 사용자 공간 응용 프로그램이 자동으로 GPL이 되는 것은 아니다.

이 구조는 자유 소프트웨어와 상용 제품이 같은 커널 생태계 안에서 공존할 수 있게 했다. 기업은 Linux를 이용해 하드웨어와 클라우드, 지원 서비스와 독점 응용 프로그램을 판매하면서도 공통 커널의 개선을 공개적으로 공유할 수 있다.

개발자 문화

Linux는 운영체제를 사용하는 것과 개발하는 것의 경계를 낮추었다. 사용자는 커널과 시스템 도구의 소스를 읽고, 배포판을 수정하거나 자신의 시스템을 직접 구성할 수 있다.

이 환경에서는 다음과 같은 문화가 발전했다.

• 소스에서 프로그램 빌드
• 패치와 포크를 통한 기능 변경
• 명령줄과 작은 도구의 조합
• 설정 파일과 자동화 스크립트 공유
• 배포판과 데스크톱 환경의 선택
• 오류 보고와 상위 프로젝트 기여
• 개인 서버와 자가 호스팅
• 사용자 환경을 세밀하게 꾸미는 문화

Linux는 전문적인 서버 운영체제인 동시에 운영체제 내부 구조를 배우고 직접 변경할 수 있는 교육·실험 환경으로도 기능했다.

영향의 범위

Linux의 영향은 특정 사용자 인터페이스나 하나의 배포판의 성공으로 설명되지 않는다. Linux 커널을 공통 기반으로 서로 다른 운영체제와 제품, 서비스가 만들어졌다는 데 핵심이 있다.

Linux는 다음과 같은 변화를 함께 이끌었다.

• 공개 공동 개발의 산업적 확산
• 범용 서버 운영체제의 상품 구조 변화
• 클라우드와 컨테이너 기반의 확산
• 여러 프로세서 아키텍처의 공통 소프트웨어 기반 형성
• 스마트폰과 임베디드 제품의 Linux 커널 채택
• 오픈 소스 개발 도구와 협업 방식의 대중화
• 하드웨어 제조사의 상위 프로젝트 기여 확대
• Linux ABI와 실행 환경의 사실상 플랫폼화

Linux는 UNIX의 영향을 받아 개발되었지만, 이후에는 UNIX 계열 운영체제의 개념을 서버와 모바일, 클라우드와 임베디드 전반으로 확장하고 새로운 운영체제 기술의 기준을 만드는 데 영향을 주었다.

Linux의 특성은 사용 목적과 배포판, 하드웨어와 운영 방식에 따라 장점 또는 한계가 될 수 있다. 서버와 임베디드 환경에서 강점이 되는 자유로운 구성 가능성은 일반 소비자에게 복잡성으로 느껴질 수 있으며, 빠른 개발과 다양한 선택지는 호환성 차이를 만들기도 한다.

장점

공개된 소스와 수정 가능성

Linux 커널의 소스 코드는 공개되어 있으며 누구나 연구하고 수정할 수 있다. 조직은 필요한 장치와 기능을 추가하고, 성능과 보안 정책을 제품 목적에 맞게 조정할 수 있다.

소스 접근은 특정 공급자가 지원을 중단했을 때 다른 개발자나 기업이 유지보수를 이어갈 가능성을 제공한다. 또한 보안 연구자와 배포판, 하드웨어 업체가 같은 코드를 검토하고 수정할 수 있다.

GPL은 배포되는 커널 파생 코드가 다시 공개되는 기반을 제공하여, 여러 기업이 공통 개선 사항을 공유하도록 한다.

폭넓은 구성 가능성

Linux는 소형 임베디드 장치부터 대규모 서버와 슈퍼컴퓨터까지 목적에 따라 기능을 선택할 수 있다.

시스템 제작자는 다음 요소를 변경할 수 있다.

• 커널 기능과 드라이버
• C 라이브러리
• init 시스템
• 셸과 기본 명령
• 파일 시스템
• 그래픽 환경
• 패키지 관리 체계
• 보안 정책
• 업데이트 방식

데스크톱이 필요하지 않은 서버에서는 그래픽 구성 요소를 제거하고, 임베디드 장치에서는 필요한 드라이버와 프로그램만 포함할 수 있다.

다양한 하드웨어 지원

Linux는 여러 프로세서 아키텍처와 장치 종류를 지원한다. 범용 PC와 서버뿐 아니라 스마트폰, 라우터와 자동차, 산업 장치와 단일 보드 컴퓨터에서 사용할 수 있다.^[122]

하드웨어 제조사가 드라이버를 공식 커널에 기여하면 여러 배포판이 같은 지원 코드를 공유할 수 있다. 오래된 하드웨어와 특수 장치도 공동체 개발자를 통해 지원되는 경우가 있다.

서버와 자동화 환경

Linux는 셸과 원격 접속, 텍스트 기반 설정과 패키지 관리 도구를 제공하여 서버를 자동화하기 쉽다.

시스템은 설치와 설정, 업데이트와 감시를 코드로 정의할 수 있으며, 그래픽 환경 없이도 완전히 운영할 수 있다. 컨테이너와 가상 머신, 구성 관리와 클라우드 도구의 폭넓은 지원도 대규모 운영에 적합하다.

안정적인 사용자 공간 인터페이스

Linux 커널은 기존 사용자 공간 프로그램을 깨뜨리지 않는 것을 중요한 원칙으로 다룬다. 시스템 호출을 비롯한 다수의 사용자 공간 인터페이스는 장기간 호환성을 유지하도록 관리된다.^[123]

이러한 정책은 오래된 프로그램이 새로운 커널에서도 실행될 가능성을 높이며, 커널이 내부 구현을 개선하면서도 사용자 공간의 호환성을 유지할 수 있게 한다.

개발 도구와 소프트웨어 생태계

Linux에서는 GCC와 LLVM, Git, GDB와 여러 언어 런타임, 빌드·분석 도구를 자유롭게 사용할 수 있다. 서버와 클라우드 프로그램은 실제 운영 환경과 유사한 Linux 시스템에서 직접 개발하고 시험할 수 있다.

대부분의 오픈 소스 서버 소프트웨어는 Linux를 주요 지원 플랫폼으로 제공하며, 배포판 저장소를 통해 개발 라이브러리와 도구를 설치할 수 있다.

배포판과 지원 방식의 선택

사용자는 공동체 배포판과 기업용 장기지원 배포판, 작은 컨테이너용 배포판과 데스크톱 배포판 가운데 목적에 맞는 구성을 선택할 수 있다.

무료 공동체 지원을 사용할 수도 있고, Red Hat과 Canonical, SUSE와 여러 공급자의 기술 지원과 인증, 장기 유지보수 계약을 구입할 수도 있다.

하나의 공급자에만 의존하지 않고 다른 배포판이나 지원 기업으로 이전할 수 있다는 점도 장점이다.

보안 기능

Linux는 사용자와 권한, capabilities와 LSM, SELinux와 AppArmor, seccomp, 네임스페이스와 cgroups, 커널 모듈 서명과 여러 자체 보호 기능을 제공한다.

시스템 목적에 따라 필요하지 않은 패키지와 서비스를 제거하고 강제적 접근 통제와 샌드박스를 적용할 수 있다. 공개 개발과 여러 배포판의 보안 팀은 취약점 발견과 수정에 함께 참여한다.

다만 보안 기능이 존재한다는 사실만으로 실제 시스템이 안전해지는 것은 아니며, 올바른 설정과 지속적인 업데이트가 필요하다.

비용과 사업 모델

Linux는 커널 사용에 장치별 라이선스 비용을 요구하지 않으므로 대규모 서버와 제품에 적용할 수 있다. 조직은 소프트웨어 사용권보다 기술 지원과 관리 도구, 인증과 운영 서비스에 비용을 지불할 수 있다.

무료라는 특성만으로 전체 운영 비용이 낮아지는 것은 아니지만, 소스 접근과 공급자 선택 가능성은 라이선스와 제품 전략에 유연성을 제공한다.

한계

배포판과 환경의 분산

Linux에는 수많은 배포판과 데스크톱 환경, 패키지 형식과 시스템 구성 방식이 존재한다.

이 다양성은 선택권을 제공하지만 소프트웨어 공급자에게는 다음과 같은 부담을 준다.

• 서로 다른 패키지 형식
• 라이브러리 버전 차이
• glibc와 musl의 차이
• 파일과 설정 위치 차이
• 데스크톱 환경과 테마 차이
• 배포판별 시험과 지원
• 서로 다른 업데이트 주기

LSB와 FHS, freedesktop.org 규격이 공통 기반을 제공하지만 모든 배포판과 응용 프로그램을 완전히 통일하지는 않는다. freedesktop.org의 규격도 여러 자유 소프트웨어 데스크톱 사이의 상호운용성과 공통 기반 기술을 높이는 것을 목적으로 한다.^[124]

상용 데스크톱 소프트웨어 부족

일부 전문 상용 응용 프로그램은 Linux 버전을 제공하지 않거나 Windows와 macOS 버전보다 기능과 지원이 제한될 수 있다.

특히 특정 산업용 설계 도구와 미디어 제작 소프트웨어, 기업 내부 프로그램과 주변 장치 관리 프로그램은 Linux를 공식 지원하지 않을 수 있다. Wine과 가상 머신으로 일부 프로그램을 실행할 수 있지만 완전한 호환성을 보장하지 않는다.

웹 응용 프로그램과 크로스 플랫폼 개발 도구의 증가로 차이가 줄어든 분야도 있지만, 응용 프로그램 지원은 데스크톱 Linux 채택의 지속적인 제약이다.

하드웨어 제조사 지원의 차이

Linux 커널은 폭넓은 하드웨어를 지원하지만 모든 제조사가 Linux 드라이버와 관리 프로그램을 제공하는 것은 아니다.

새 노트북과 주변 장치, 전문 오디오·영상 장비와 특정 GPU 기능은 Windows에서 먼저 지원되거나 독점 드라이버에 의존할 수 있다. 공개 문서가 없는 하드웨어는 공동체가 역공학으로 드라이버를 개발해야 할 수 있다.

반대로 오래된 장치는 최신 Windows보다 Linux에서 더 오래 지원될 수 있으므로 하드웨어 지원의 장단점은 장치마다 다르다.

사용자 경험의 일관성 부족

Linux 데스크톱은 KDE Plasma와 GNOME, Xfce와 여러 창 관리자를 선택할 수 있지만, 응용 프로그램마다 GTK와 Qt, 다른 포털과 테마 방식을 사용하여 외형과 동작이 달라질 수 있다.

배포판과 데스크톱 환경에 따라 설정 위치와 업데이트 도구, 기본 프로그램과 문제 해결 절차가 달라질 수 있어 일반 사용자용 지원 문서를 통일하기 어렵다.

높은 사용자화 가능성은 숙련 사용자에게 장점이지만, 설정 없이 일관된 경험을 원하는 사용자에게는 복잡성으로 작용할 수 있다.

높은 학습 비용

현대적인 데스크톱 배포판은 설치 후 바로 사용할 수 있지만, 시스템의 고급 관리와 문제 해결에는 셸과 파일 권한, 서비스, 패키지와 로그에 대한 지식이 필요할 수 있다.

인터넷에 존재하는 해결 방법은 배포판과 버전에 따라 맞지 않을 수 있으며, 오래된 명령이나 위험한 권한 변경을 그대로 따라 하면 시스템 상태를 악화시킬 수 있다.

Linux를 세밀하게 구성할 수 있다는 특성은 사용자가 더 많은 선택과 책임을 맡아야 한다는 뜻이기도 하다.

빠른 변화와 호환성 문제

Linux 커널은 사용자 공간 ABI를 안정적으로 유지하려 하지만 커널 내부 API와 모듈 인터페이스는 고정되지 않는다. 공식 문서는 커널 내부 드라이버 API와 바이너리 인터페이스를 영구히 안정화하지 않는다고 설명한다.^[125]

공식 커널 트리 안의 드라이버는 내부 변경과 함께 수정되지만, 외부 독점 모듈은 새 커널에서 빌드되지 않거나 작동하지 않을 수 있다. 배포판은 자체 커널 ABI를 유지하여 이를 완화하기도 하지만 이는 메인라인 전체의 보장이 아니다.

사용자 공간에서도 빠르게 변하는 그래픽과 오디오, 데스크톱 기술로 인해 오래된 응용 프로그램과의 호환 문제가 발생할 수 있다.

여러 지원 주체

Linux 시스템의 문제는 커널과 배포판, 하드웨어 드라이버, 데스크톱 환경과 응용 프로그램 가운데 어느 부분에서 발생했는지 구분하기 어려울 수 있다.

한 기업이 전체 시스템을 단독으로 제공하는 제품과 달리, 각 구성 요소의 지원 창구가 나뉠 수 있다. 공동체 배포판에서는 사용자가 버그를 적절한 상위 프로젝트에 직접 보고해야 할 수도 있다.

기업용 배포판과 하드웨어 인증, 기술 지원 계약은 단일 지원 창구를 제공하지만 추가 비용과 지원 구성 제한이 따른다.

장기 유지보수

Linux를 제품에 포함하는 것 자체는 어렵지 않지만, 장기간 안전하게 유지하려면 커널과 사용자 공간, 부트로더와 응용 프로그램의 보안 업데이트를 계속 제공해야 한다.

일부 저가형 소비자 장치와 임베디드 제품은 판매 이후 업데이트가 중단되어 오래된 커널과 취약한 사용자 공간을 계속 사용할 수 있다. 소스가 공개되어 있다는 사실이 제조사가 실제 장치용 업데이트를 제공한다는 뜻은 아니다.

제품별 수정이 상위 커널과 크게 달라지면 새 보안 패치를 역이식하기 어려워질 수 있다.

실시간성과 안전 인증

Linux는 PREEMPT_RT와 실시간 스케줄링 기능을 제공하지만, 매우 작은 마이크로컨트롤러와 엄격한 시간 보장이 필요한 시스템에서는 전용 실시간 운영체제보다 복잡하고 무거울 수 있다.

자동차와 항공, 의료와 산업 제어처럼 기능 안전 인증이 필요한 분야에서는 범용 Linux 전체를 안전 중요 기능에 사용하는 데 추가적인 검증과 제한이 필요하다.

이러한 시스템은 Linux가 그래픽과 네트워크, 사용자 응용 프로그램을 담당하고 별도의 실시간·안전 운영체제가 핵심 제어를 맡도록 구성할 수 있다.

자원 사용량

Linux는 작게 구성할 수 있지만 일반 데스크톱 배포판과 완전한 그래픽 환경, 여러 백그라운드 서비스는 상당한 메모리와 저장 공간을 사용할 수 있다.

작은 임베디드 장치에서는 Linux 커널과 메모리 관리 장치, 사용자 공간을 실행하기 위한 하드웨어가 지나치게 클 수 있다. 단순한 센서와 제어 장치는 마이크로컨트롤러용 RTOS나 펌웨어만으로 더 효율적으로 구현될 수 있다.

자유와 책임

Linux는 사용자가 시스템을 폭넓게 수정할 수 있게 하지만, 잘못된 커널과 패키지, 권한과 부팅 설정을 적용할 가능성도 함께 제공한다.

공식 저장소 밖의 패키지와 스크립트, 커널 모듈을 설치하면 보안과 안정성이 저하될 수 있다. 여러 선택지 가운데 안전하고 유지 가능한 구성을 판단하는 책임이 사용자와 운영 조직에 있다.

평가

Linux의 가장 큰 강점은 공개된 개발과 폭넓은 이식성, 구성 가능성, 안정적인 사용자 공간 인터페이스와 거대한 산업 생태계에 있다. 이 특성은 서버와 클라우드, 임베디드와 슈퍼컴퓨터처럼 시스템을 목적에 맞게 조정해야 하는 분야에서 특히 유리하다.

반면 분산된 배포판과 사용자 공간, 상용 데스크톱 프로그램과 제조사 지원의 차이, 높은 선택 복잡성과 장기 유지관리 부담은 한계로 작용한다.

Linux가 적합한지는 무료인지 여부만으로 판단할 수 없다. 필요한 응용 프로그램과 하드웨어, 보안과 실시간 요구, 운영 인력과 지원 기간을 함께 고려해야 한다.

• Linux 커널
• Linux 배포판
• 유닉스 계열 운영체제
• UNIX
• GNU
• GNU/Linux
• 자유 소프트웨어
• 오픈 소스
• Linux Foundation
• Linux Standard Base
• POSIX
• Filesystem Hierarchy Standard
• 시스템 소프트웨어
• 운영체제
• 커널
• 모놀리식 커널
• 시스템 호출
• 파일 시스템
• 셸
• 패키지 관리자
• 서버
• 클라우드 컴퓨팅
• 가상화
• 컨테이너
• KVM
• Docker
• Kubernetes
• 임베디드 Linux
• Android
• ChromeOS
• 실시간 운영체제
• Linux 보안 취약점 사건
• Linux 커널 모듈
• Linux 네임스페이스
• cgroups
• Git