[리눅스 기초] 로그 관리, 리눅스 부트 프로세스, 소프트웨어 패키지

Chapter 08. 로그 관리

1. rsyslogd

rsyslogd는 리눅스 시스템에서 발생하는 로그를 기록하고 관리하는 프로세스입니다.
syslog를 기반으로 로그를 처리하며, 로그의 종류와 우선순위를 기준으로 원하는 로그를 분류하고 /var/log 아래의 파일에 저장할 수 있습니다.

특히 로그 전송 시 암호화 옵션을 사용할 수 있어 보안을 강화할 수 있고, 로그 처리 및 저장 성능이 우수하다는 특징이 있습니다.

rsyslogd의 설정은 /etc/rsyslog.conf를 기반으로 이루어집니다.

 

2. Selector와 Action

rsyslog의 로그 처리 규칙은 크게 Selector와 Action으로 나눌 수 있습니다.

 

Selector

Selector는 어떤 로그를 선택할 것인지를 결정합니다.

Selector는 다시 다음 두 가지 기준으로 구성됩니다.

• Facility: 로그의 종류
• Priority: 로그의 심각도

즉, 로그의 종류와 심각도를 기준으로 원하는 로그만 골라낼 수 있습니다.

로그를 기능별로 분리하면 문제 발생 시 원하는 로그를 빠르게 찾을 수 있고, 중요한 로그를 별도로 관리하여 더 오래 보관할 수도 있습니다.

 

Priority

Priority는 로그의 심각도를 나타냅니다.

특정 우선순위를 지정하면 일반적으로 그보다 높은 우선순위의 로그도 함께 포함됩니다.

반대로 특정 우선순위만 정확하게 지정하거나 특정 우선순위를 제외하는 방식도 사용할 수 있습니다.

 

Action

Action은 Selector가 선택한 로그를 어떻게 처리하고 어디에 저장할지를 결정합니다.

정리하면 다음과 같습니다.

Selector = 어떤 로그를 선택할 것인가?
Action = 선택한 로그를 어떻게 처리할 것인가?

예를 들어 특정 로그는 /var/log/messages, 인증 관련 로그는 /var/log/secure처럼 목적에 따라 서로 다른 파일에 저장할 수 있습니다.

 

3. systemd-journald

systemd-journald는 systemd의 일부로 동작하는 로그 관리 데몬입니다.

시스템이 부팅을 시작할 때부터 발생하는 이벤트를 수집하고, 이를 구조화된 바이너리 형태의 저널로 저장합니다.

구조화된 형태로 저장되기 때문에 로그의 메타데이터를 활용할 수 있고, 인덱싱을 통해 원하는 로그를 빠르게 검색할 수 있다는 장점이 있습니다.

다만 저널은 일반적인 텍스트 파일이 아니기 때문에 cat, tail과 같은 명령으로 직접 확인하는 것이 아니라 journalctl을 사용하여 조회합니다.

대표적인 조회 방식은 다음과 같은 목적을 가집니다.

• 최근 로그 확인
• 로그 실시간 확인
• 특정 systemd 서비스의 로그만 확인

 

4. journald 로그의 영구 저장

기본적으로 journald의 로그는 /run/log/journal에 저장됩니다.

/run은 메모리 기반 파일시스템이기 때문에 시스템이 재부팅되면 기존 로그가 사라질 수 있습니다.

따라서 로그를 재부팅 이후에도 유지하려면 저널을 /var/log/journal에 저장하도록 설정하여 영구 로그 저장을 사용할 수 있습니다.

 

5. 로그 관리 핵심 흐름

리눅스의 로그 관리는 크게 다음 구조로 이해할 수 있습니다.

시스템 이벤트 발생 → systemd-journald가 수집 → 필요에 따라 rsyslogd가 처리 → /var/log 등에 저장

여기서 journald는 구조화된 바이너리 로그를 관리하고, rsyslogd는 로그를 분류하고 지정된 파일이나 다른 대상으로 전달하는 역할을 담당합니다.

 

Chapter 09. 리눅스 부트 프로세스

1. 부팅 과정을 알아야 하는 이유

리눅스 시스템에서 부팅 문제가 발생했을 때는 부팅 과정의 어느 단계에서 문제가 발생했는지 파악하는 것이 중요합니다.

부팅은 한 번에 이루어지는 것이 아니라 여러 단계를 거쳐 진행되므로 각 단계의 역할을 이해해야 문제를 진단할 수 있습니다.

특히 다음 개념들이 부팅 과정을 이해하는 데 중요합니다.

• BIOS / UEFI
• POST
• Boot Loader
• GRUB2
• Kernel
• init / systemd
• Runlevel / Target
• UUID

원문에서는 특히 init 기반 부팅과 systemd 기반 부팅의 차이를 중요하게 다룹니다.

 

2. 전체적인 부팅 흐름

기본적인 부팅 과정은 다음과 같이 이해할 수 있습니다.

전원 공급 → 펌웨어(BIOS/UEFI) → POST → 부트 로더 → 커널 → 초기화 프로세스 → 시스템 초기화 → 로그인

각 단계에서 시스템의 제어권이 다음 단계로 넘어가는 구조입니다.

 

3. BIOS/UEFI와 POST

시스템에 전원이 공급되면 가장 먼저 시스템 펌웨어가 동작합니다.

펌웨어는 하드웨어의 상태를 확인하며, 이 과정이 POST(Power-On Self Test)입니다.

하드웨어에 문제가 없다면 부팅 가능한 장치를 찾고 부트 로더를 실행합니다.

BIOS 방식에서는 부팅 디스크의 특정 영역에서 부트 로더를 찾고, UEFI 방식에서는 EFI 시스템 파티션을 활용합니다.

 

4. Boot Loader와 GRUB2

부트 로더는 운영체제를 실제로 시작하기 위한 역할을 담당합니다.

리눅스에서는 일반적으로 GRUB2가 부트 로더로 사용됩니다.

GRUB2는 부팅 가능한 커널을 찾아 부팅 메뉴에 표시하고, 선택된 커널을 메모리에 적재한 뒤 시스템의 제어권을 커널로 전달합니다.

즉,

Boot Loader의 핵심 역할 = 부팅할 커널을 선택하고 메모리에 적재한 후 커널에게 제어권을 넘기는 것

입니다.

 

5. Kernel

커널은 운영체제의 핵심으로, 시스템을 실행하기 위한 기본적인 기능을 제공합니다.

부팅 과정에서는 커널이 메모리에 적재된 이후 시스템 초기화 과정이 진행됩니다.

초기 부팅 단계에서는 루트 파일시스템이 임시로 /sysroot에 마운트되는 과정이 등장합니다.

 

6. init과 systemd의 차이

과거 리눅스에서는 init이 시스템의 초기화 프로세스로 사용되었습니다.

init은 PID 1을 할당받아 시스템 초기화, 프로세스 실행, 서비스 관리 등을 담당합니다.

반면 현재의 리눅스에서는 대부분 systemd가 PID 1로 실행됩니다.

가장 중요한 차이는 다음과 같습니다.

구분initsystemd

PID 1	init	systemd
시스템 상태 관리	Runlevel	Target
서비스 실행	순차적 중심	의존성 기반 병렬 실행
부팅 속도	상대적으로 느림	병렬 처리로 개선
서비스 관리	제한적	통합적인 관리

즉, init은 런레벨을 중심으로 시스템을 초기화하고, systemd는 Target과 Unit의 의존성을 중심으로 시스템을 초기화합니다.

 

7. systemd 기반 부팅 과정

systemd 기반 시스템에서는 펌웨어와 부트 로더 단계까지는 기존 방식과 유사하지만, 이후의 초기화 과정에서 차이가 발생합니다.

 

① 펌웨어 및 부트 로더

BIOS 또는 UEFI가 POST를 수행하고 부트 로더를 실행합니다.

 

② 커널 및 initramfs

커널이 실행되고 systemd가 PID 1로 시작합니다.

systemd는 단순히 서비스를 순서대로 실행하는 것이 아니라 서비스 간 의존성을 분석하여 가능한 작업을 병렬로 실행합니다.

 

③ Target 실행

systemd는 기본 Target을 활성화하고, 해당 Target과 연결된 의존성 관계의 Unit들을 활성화합니다.

Target은 계층적인 구조를 가지며, 필요한 하위 Target과 Unit이 먼저 활성화되어야 합니다.

따라서 systemd의 부팅 순서는 단순히 위에서 아래로 모든 작업을 하나씩 실행하는 방식이 아니라 의존성 관계에 따라 필요한 작업을 실행하는 구조입니다.

 

8. 주요 Target

Target은 특정한 시스템 상태에 도달하기 위해 필요한 여러 Unit을 묶어 관리하는 역할을 합니다.

즉,

Target = 특정 시스템 상태를 만들기 위해 필요한 Unit들의 그룹

이라고 이해할 수 있습니다.

 

local-fs.target

로컬 파일시스템을 마운트하는 것이 주요 목적입니다.

/etc/fstab 등에 정의된 파일시스템을 마운트하며, 시스템에서 사용할 로컬 파일시스템을 준비합니다.

 

sysinit.target

시스템 초기화를 담당합니다.

대표적으로 다음과 같은 초기화 작업이 포함됩니다.

• 스왑 활성화
• 임시 파일 정리
• 커널 모듈 로딩

basic.target

시스템을 사용하기 위한 기본적인 리소스를 활성화합니다.

소켓, 타이머, 경로, 슬라이스 등의 기본 리소스가 이 단계와 관련됩니다.

 

default.target

default.target은 실제로 모든 작업을 수행하는 Target이라기보다 시스템이 최종적으로 도달할 기본 Target을 가리키는 심볼릭 링크입니다.

일반적으로 다음 중 하나를 가리킵니다.

• multi-user.target
• graphical.target

따라서 시스템이 부팅을 완료했을 때 어떤 환경으로 진입할지를 결정하는 역할을 합니다.

multi-user.target

CLI 기반의 다중 사용자 환경입니다.

서버 환경에서 주로 사용되며, 그래픽 환경 없이 여러 사용자가 시스템을 사용할 수 있는 상태를 제공합니다.

graphical.target

multi-user.target의 기능에 그래픽 사용자 인터페이스(GUI)를 추가한 환경입니다.

단, graphical.target 자체만으로 GUI가 만들어지는 것은 아니며 GUI 관련 패키지가 설치되어 있어야 합니다.

 

9. Runlevel과 Target의 관계

systemd는 기존 init의 Runlevel 개념을 Target으로 대체했습니다.

기존 Runlevel과 Target은 호환성을 위해 서로 매핑되어 있습니다.

대표적으로 다음과 같이 연결됩니다.

기존 Runlevelsystemd Target

0	poweroff.target
1	rescue.target
2	multi-user.target
3	multi-user.target
4	multi-user.target
5	graphical.target
6	reboot.target

즉, 기존에는 시스템 상태를 Runlevel로 구분했다면 systemd에서는 Target을 통해 시스템 상태를 관리합니다.

 

10. 복구 관련 주요 Target

emergency.target

시스템이 정상적으로 부팅할 수 없는 매우 긴급한 상황에서 사용하는 최소한의 환경입니다.

가장 제한적인 상태로 시스템을 시작하여 문제를 확인하고 수정하는 데 사용합니다.

루트 파일시스템이 읽기 전용으로 마운트되는 것이 특징입니다.

 

rescue.target

문제 해결을 위한 복구 모드입니다.

emergency.target보다 더 많은 시스템 기능을 사용할 수 있으며, 로컬 파일시스템을 마운트하고 필요한 파일을 수정할 수 있습니다.

네트워크나 일반적인 다중 사용자 환경까지 제공하는 것은 아닙니다.

 

poweroff.target

시스템을 정상적으로 종료하기 위한 Target입니다.

종료 과정에서는 데이터 손상을 방지하기 위해 파일시스템과 프로세스를 적절하게 정리한 뒤 시스템을 종료합니다.

 

reboot.target

시스템을 종료한 후 다시 시작하기 위한 Target입니다.

poweroff.target과 유사한 종료 과정을 거치지만 최종적으로 시스템을 재부팅한다는 차이가 있습니다.

 

Chapter 10. 소프트웨어 패키지

1. 소프트웨어 패키지란?

초기의 리눅스에서는 프로그램을 설치하기 위해 소스 코드를 직접 다운로드하고 컴파일해야 하는 경우가 많았습니다.

이러한 복잡한 설치 과정을 해결하기 위해 소프트웨어 패키지가 등장했습니다.

패키지는 특정 프로그램을 실행하고 관리하는 데 필요한 구성 요소를 하나로 묶은 배포 단위입니다.

일반적으로 다음과 같은 요소가 포함될 수 있습니다.

• 실행 파일
• 라이브러리
• 설정 파일
• 문서
• 기타 프로그램 실행에 필요한 구성 요소

즉,

패키지 = 프로그램 실행에 필요한 여러 구성 요소를 하나로 묶어 배포하는 단위

라고 이해하면 됩니다.

 

2. RPM과 DNF

Red Hat 계열 리눅스에서는 대표적으로 RPM과 DNF를 사용합니다.

둘은 모두 패키지 관리와 관련되어 있지만 역할과 수준에 차이가 있습니다.

 

RPM

RPM은 개별 패키지 파일을 직접 다루는 저수준 패키지 관리 도구입니다.

주로 패키지의 정보를 조회하거나 개별 패키지를 관리할 때 사용합니다.

RPM의 중요한 특징은 의존성을 자동으로 해결하지 않는다는 것입니다.

따라서 RPM은 개별 패키지를 직접 확인하고 관리하는 데 적합합니다.

 

DNF

DNF는 RPM 기반의 고수준 패키지 관리 도구입니다.

RPM과 달리 저장소를 기반으로 패키지를 관리하고, 패키지 설치에 필요한 의존성을 자동으로 해결합니다.

따라서 실제 시스템에서 패키지를 설치하거나 업데이트하는 경우 DNF를 사용하는 것이 일반적입니다.

 

3. 패키지 의존성

하나의 프로그램은 혼자서 동작하지 않고 다른 라이브러리나 패키지를 필요로 할 수 있습니다.

이때 프로그램이 동작하기 위해 필요한 다른 패키지나 라이브러리를 의존성(Dependency)이라고 합니다.

RPM은 개별 패키지를 직접 다루기 때문에 의존성을 직접 관리해야 하지만, DNF는 저장소 정보를 이용해 필요한 의존성을 자동으로 찾아 설치할 수 있습니다.

따라서 패키지 관리에서는 의존성 관리가 중요한 차이점입니다.

 

4. DNF Repository

DNF는 Repository(저장소)를 기반으로 패키지를 관리합니다.

Repository는 패키지들을 저장해놓은 서버라고 생각할 수 있습니다.

앱스토어에서 필요한 프로그램을 검색하고 설치하는 것과 비슷한 개념으로 이해할 수 있습니다.

DNF는 Repository에 접근하여 다음과 같은 작업을 수행합니다.

• 패키지 정보 조회
• 패키지 다운로드
• 패키지 설치
• 패키지 업데이트
• 패키지 제거

Repository 설정은 일반적으로 /etc/yum.repos.d 디렉터리의 .repo 파일을 통해 관리합니다.

 

5. Repository 설정의 주요 요소

Repository 설정에는 다음과 같은 요소가 등장합니다.

 

baseurl

패키지가 실제로 존재하는 저장소의 주소입니다.

 

mirrorlist

여러 미러 서버 중 적절한 서버를 선택할 수 있도록 정보를 제공합니다.

미러 서버를 사용하면 사용자와 가까운 서버를 선택하여 패키지 다운로드 효율을 높일 수 있습니다.

 

enabled

해당 저장소를 사용할지 여부를 결정합니다.

 

gpgcheck

패키지의 GPG 서명을 확인하여 패키지의 위변조 여부 등을 검증하는 데 사용됩니다.

 

gpgkey

패키지 서명 검증에 사용할 GPG 키를 지정합니다.

즉, Repository 설정은 어디에서 패키지를 가져올 것인지뿐 아니라 패키지의 신뢰성을 어떻게 확인할 것인지까지 포함합니다.

 

6. 폐쇄망과 로컬 Repository

인터넷에 연결할 수 없는 폐쇄망 환경에서는 외부 Repository에 직접 접근할 수 없습니다.

이 경우 로컬 Repository를 구성하여 내부에서 패키지를 제공할 수 있습니다.

기본적인 개념은 다음과 같습니다.

인터넷이 가능한 환경에서 패키지와 의존성 확보 → 내부 저장 공간에 저장 → Repository 메타데이터 생성 → 폐쇄망에서 로컬 Repository를 사용

여기서 중요한 점은 RPM 파일만 모아놓는다고 Repository가 되는 것은 아니라는 것입니다.

DNF가 패키지를 정상적으로 검색하고 관리하려면 Repository에 대한 메타데이터가 필요합니다.

이때 createrepo_c와 같은 도구를 이용하여 Repository 메타데이터를 생성합니다.

결국 폐쇄망에서도 외부 인터넷 저장소 대신 내부의 로컬 Repository를 DNF가 바라보도록 구성하여 패키지를 설치할 수 있습니다.