RSS Feed of jiu's blog

Bash Script: 운영 자동화 실습

Thu, 16 Apr 2026 00:00:00 GMT

운영 자동화 실습

서비스 헬스체크 + 최근 journal 저장

서비스가 내려가 있으면 최근 부팅 기준 로그를 바로 파일로 저장한다.

#!/bin/bash
set -u

SERVICE="${1:-sshd}"
OUT_DIR="/var/tmp/service-check"
TS=$(date +"%Y%m%d-%H%M%S")

mkdir -p "$OUT_DIR"

if systemctl is-active --quiet "${SERVICE}.service"; then
    echo "[OK] ${SERVICE}.service is active"
    exit 0
else
    echo "[FAIL] ${SERVICE}.service is not active"

    LOG_FILE="${OUT_DIR}/${SERVICE}-${TS}.log"

    journalctl -u "${SERVICE}.service" -b --no-pager > "$LOG_FILE"

    echo "[INFO] recent boot log saved to: $LOG_FILE"
    exit 1
fi

안전하게 스크립트 작성하기

1. 테스트 환경에서 먼저 실행하기

운영 서버에서 바로 실행하기보다, 테스트용 디렉터리나 샘플 파일로 먼저 동작을 검증하는 것이 좋다.

예를 들어 로그 정리 스크립트라면 실제 /var/log 대신
직접 만든 ./test-logs 디렉터리에서 먼저 실행해볼 수 있다.

2. 절대 경로 사용하기

스크립트는 실행 위치에 따라 상대 경로가 달라질 수 있다.
그래서 중요한 작업일수록 절대 경로를 쓰는 편이 더 안전하다.

예를 들어:

LOG_FILE="/var/log/app.log"

3. 삭제 명령(`rm`) 주의하기

삭제 명령은 가장 조심해야 한다.
특히 변수와 함께 사용할 때는 값이 비어 있거나 예상과 다르면 위험해질 수 있다.

예를 들어 아래 같은 명령은 항상 신중해야 한다.

rm -rf "$TARGET_DIR"

삭제 작업을 넣기 전에는 먼저 echo, ls, find 등으로
정말 원하는 대상이 맞는지 확인하는 단계를 거치는 것이 좋다.

4. root 권한 스크립트 주의하기

sudo나 root 권한으로 실행되는 스크립트는 영향 범위가 훨씬 크다.
파일 삭제, 계정 변경, 패키지 설치 같은 작업은 시스템 전체에 영향을 줄 수 있다.

초기 학습 단계에서는
가능하면 root 권한이 필요 없는 작업부터 연습하는 것이 안전하다.

Bash Script: 조건문, 반복문, 함수

Wed, 15 Apr 2026 00:00:00 GMT

이 글에서는 Bash 스크립트의 다음 내용들을 다룬다.

조건문

기본 구조

if 조건1 ; then
    명령1
elif 조건2 ; then
    명령2
else
	명령3
fi

조건 자리에는 다음 두 가지가 올 수 있다.

[ ... ], [[ ... ]] 같은 비교식/검사식
일반 명령어 또는 파이프라인
종료 코드가 0이면 참, 아니면 거짓

비교식/검사식

비교식/검사식을 을 사용할 때는 다음 두 가지를 주의해야 한다.

앞뒤 공백이 꼭 필요하다.
문자열 변수는 큰따옴표로 감싸는 것이 안전하다.

운영 스크립트에서 자주 사용하는 조건식은 크게 아래 세 가지다.

1. 파일 존재 여부

파일이나 디렉터리가 실제로 있는지 검사할 때 사용한다.

if [ -f backup.log ]; then
    echo "file exists"
fi

if [ -d /var/log ]; then
    echo "log directory exists"
fi

자주 쓰는 파일 관련 테스트:

-f : 일반 파일이 존재하는가
-d : 디렉터리가 존재하는가
-e : 파일 또는 디렉터리가 존재하는가

2. 문자열 비교

문자열 값이 같은지, 비어 있는지 등을 검사할 때 사용한다.

if [ "$env" = "prod" ]; then
    echo "production mode"
fi

if [ -z "$name" ]; then
    echo "name is empty"
fi

자주 쓰는 문자열 테스트:

= : 문자열이 같은가
!= : 문자열이 다른가
-z : 문자열 길이가 0인가
-n : 문자열 길이가 0이 아닌가

3. 숫자 비교

숫자는 문자열 비교와 다른 연산자를 사용한다.

count=10

if [ "$count" -gt 5 ]; then
    echo "count is greater than 5"
fi

if [ "$port" -eq 8080 ]; then
    echo "default port"
fi

자주 쓰는 숫자 비교 연산자:

-eq : 같다
-ne : 다르다
-gt : 크다
-ge : 크거나 같다
-lt : 작다
-le : 작거나 같다

반복문

`for`

for item in 값1 값2 값3
do
    실행할 명령
done

예: 파일 목록 순회

for file in app.log db.log auth.log
do
    echo "checking $file"
done

예: 현재 디렉터리의 .log 파일 순회

for file in *.log
do
    echo "processing $file"
done

`while`

while [ 조건식 ]
do
    실행할 명령
done

예시

count=1

while [ "$count" -le 5 ]
do
    echo "$count"
    count=$((count + 1))
done

운영에서 자주 쓰이는 반복문 예시

여러 파일 처리

for file in *.log
do
    grep "ERROR" "$file"
done

각 로그 파일에서 ERROR를 검색한다.

여러 프로세스 이름 검사

for proc in nginx sshd cron
do
    ps -ef | grep "[${proc:0:1}]${proc:1}"
done

여러 서비스 상태를 한 번에 점검할 수 있다.

여러 로그에 대한 반복 작업

for file in /var/log/*.log
do
    echo "===== $file ====="
    grep "failed" "$file"
done

로그 파일이 여러 개일 때 같은 필터를 반복 적용하는 데 유용하다.

함수

기본 구조

함수 정의

hello() {
    echo "hello"
}

호출

hello

함수 이름만 쓰면 된다.

예시

정의:

check_file() {
    if [ -f "$1" ]; then
        echo "$1 exists"
    else
        echo "$1 missing"
    fi
}

$1 : 전달한 첫 번째 인자

호출:

check_file "/etc/passwd"
check_file "nofile.txt"

반복되는 작업을 함수로 분리하기

같은 로직이 두 번 이상 나오기 시작하면 함수로 분리하는 것이 좋다.

예를 들어 여러 파일의 존재 여부를 검사한다고 할 때, 아래처럼 함수로 분리하는 것이 좋다.

check_file() {
    if [ -f "$1" ]; then
        echo "[OK] $1 exists"
    else
        echo "[FAIL] $1 missing"
    fi
}

check_file "/etc/passwd"
check_file "/etc/hosts"
check_file "./config.env"

명령어 치환

Bash Script에서는 명령어 실행 결과를 변수에 넣고,
그 값을 이후 조건문이나 반복문에서 활용하는 경우가 많다.
이때 사용하는 문법이 명령어 치환(command substitution) 이다.

명령어의 실행 결과를 변수에 저장할 때는 $(...)를 사용한다.

name=$(whoami)  
today=$(date)  
count=$(grep -c "ERROR" app.log)

예시

count=$(grep -c "ERROR" app.log)

grep -c "ERROR" app.log를 실행한 뒤,
그 출력 결과를 count 변수에 저장한다.

운영 자동화에서 자주 쓰이는 요소

변수화

고정값을 직접 코드에 반복해서 쓰기보다 변수로 분리하는 것이 좋다.

LOG_DIR="/var/log"
KEYWORD="ERROR"

이렇게 하면 나중에 경로나 검색어를 바꾸기 쉽다.

grep "$KEYWORD" "$LOG_DIR/app.log"

특히 다음은 변수화하는 경우가 많다.

경로
파일명
포트 번호
환경 이름
반복 대상 목록

조건 검사 후 실행

무조건 실행하기보다, 조건을 확인하고 실행해야 예상치 못한 실패를 줄일 수 있다.

if [ -f "$LOG_DIR/app.log" ]; then
    grep "$KEYWORD" "$LOG_DIR/app.log"
else
    echo "log file not found"
fi

파일이 있을 때만 읽기
디렉터리가 있을 때만 이동
인자가 주어졌을 때만 특정 작업 수행
이전 명령이 성공했을 때만 다음 단계 진행

실패 시 종료

가장 단순한 방식은 exit 1이다. 아래처럼 필수 파일이 없을 때 바로 종료시킬 수 있다.

if [ ! -f config.env ]; then
    echo "config.env not found"
    exit 1
fi

명령 직후 종료 코드를 검사할 수도 있다.

cp source.txt backup.txt

if [ $? -ne 0 ]; then
    echo "copy failed"
    exit 1
fi

로그 남기기

자동화 스크립트는 나중에 무엇이 실행됐는지 추적할 수 있어야 한다.
그래서 중요한 단계마다 메시지를 남기는 경우가 많다.

echo "[INFO] backup started"
echo "[INFO] checking log files"
echo "[ERROR] config file missing"

파일에 저장할 수도 있다.

echo "[INFO] backup started" >> backup.log

실행 결과 확인

스크립트는 실행만 하는 것이 아니라, 실행 결과를 확인하고 필요하면 다음 동작을 정해야 한다.

예를 들어 로그 검색 결과 개수를 세고 판단할 수 있다.

count=$(grep -c "ERROR" app.log)

if [ "$count" -gt 0 ]; then
    echo "errors found: $count"
else
    echo "no errors"
fi

서비스가 실행 중인지 검사할 수도 있다.

ps -ef | grep '[n]ginx' > /dev/null

if [ $? -eq 0 ]; then
    echo "nginx is running"
else
    echo "nginx is not running"
fi

Bash Script: 표준입출력과 리다이렉션, 파이프

Wed, 15 Apr 2026 00:00:00 GMT

Bash Script에는 하나의 명령만 쓰는 것이 아니라
한 명령의 출력을 파일로 보내거나, 다른 명령의 입력으로 넘기거나, 에러만 따로 저장하는 식으로
입력과 출력의 흐름을 조합하며 사용한다.

이 글에서는 Bash의 표준 입출력과 명령어 연결에 대해 정리한다.

표준 입출력

명령어는 실행될 때 입력을 받고, 결과를 출력한다.
리눅스는 이 입출력 경로를 기본적으로 세 가지로 나눠 관리한다.

표준 입력(stdin)

표준 입력은 명령어가 입력을 받는 기본 통로다.
보통은 키보드 입력이 표준 입력으로 연결된다.

표준 출력(stdout)

표준 출력은 명령어가 정상적인 실행 결과를 내보내는 기본 통로다.

대부분의 명령어 결과는 기본적으로 터미널 화면에 출력되는데,
이때 화면에 보이는 일반 결과가 바로 표준 출력이다.

표준 에러(stderr)

표준 에러는 오류 메시지를 출력하는 별도의 통로다.
에러 메시지도 화면에 보이기 때문에 stdout과 같아 보일 수 있지만, 내부적으로는 다른 경로이다.

예를 들어 존재하지 않는 파일을 읽으려고 하면:

$ cat notexist.txt
cat: notexist.txt: No such file or directory

이 에러 메시지는 일반 출력이 아니라 stderr로 전달된다.

이렇게 stdout과 stderr가 분리되어 있기 때문에,
정상 결과는 파일로 저장하고 에러는 따로 남기는 식의 처리가 가능하다.

파일 디스크립터

리눅스는 표준 입출력을 숫자로도 구분한다.
이 숫자를 파일 디스크립터(file descriptor) 라고 한다.

기본 표준 입출력은 다음과 같이 정해져 있다.

0: 표준 입력 (stdin)
1: 표준 출력 (stdout)
2: 표준 에러 (stderr)

아래 두 표현은 같은 의미다.

ls > out.txt
ls 1> out.txt

에러만 따로 저장하려면 2>를 사용할 수 있다.

ls 2> error.txt

리다이렉션

리다이렉션은 명령어의 입력 또는 출력을 기본 경로가 아닌 다른 곳으로 보내는 것이다.

화면으로 나가던 출력을 파일로 보내거나
키보드로 받던 입력을 파일에서 받도록 바꾸는 방식이다.

출력 리다이렉션

출력 리다이렉션은 주로 표준 출력(stdout)이나 표준 에러(stderr)를 파일로 보내기 위해 사용한다.

`>`

>는 출력을 파일로 덮어써서 저장한다.

echo "hello" > output.txt

이 명령은 hello를 output.txt에 저장한다.
이미 파일이 있다면 기존 내용은 사라지고 새로 덮어써진다.

`>>`

>>는 출력을 파일 끝에 이어서 추가한다.

echo "hello" >> output.txt  
echo "world" >> output.txt

결과:

hello  
world

로그를 계속 누적해서 저장할 때 자주 사용한다.

입력 리다이렉션

입력 리다이렉션은 표준 입력(stdin)을 파일이나 다른 입력원으로 바꾸는 것이다.

`<`

<는 파일 내용을 명령어의 입력으로 전달한다.

wc -l < input.txt

이 명령은 input.txt의 내용을 표준 입력으로 받아 줄 수를 센다.

here document

here document는 여러 줄 입력을 직접 스크립트 안에서 표준 입력으로 전달하는 방식이다.

cat <<EOF  
hello  
world  
EOF

출력:

hello  
world

이 방식으로 임시로 Script를 만들어서 실행할 수 있다.

화면에 출력을 표시하는 대신 > 연산자를 사용하여 파일로 리디렉션할 수 도 있다.
아래처럼 하면 여러 줄 내용을 파일로 한 번에 저장할 수 있다.
환경변수, 변수 참조도 가능하다.

cat << EOF > file.txt
The current working directory is: $PWD
You are logged in as: $(whoami)
EOF

파이프

파이프(|)는 한 명령의 표준 출력을 다음 명령의 표준 입력으로 넘기는 연산자다.
파일을 중간에 만들지 않고도 명령어 결과를 바로 다음 명령어가 받아 처리할 수 있게 해준다.

리눅스 명령어는 대부분 텍스트를 입력받고 텍스트를 출력하기 때문에,
파이프를 이용하여 서로 다른 명령어들을 쉽게 연결할 수 있다.

ls | wc -l

이 명령은 다음 흐름으로 동작한다.

ls가 현재 디렉터리 목록을 출력한다.
그 출력이 화면으로 가지 않고
wc -l의 표준 입력으로 전달된다.
wc -l은 줄 수를 세어 결과를 출력한다.

파이프는 여러 개를 이어서 쓸 수도 있다.

ps -ef | grep nginx | wc -l

ps -ef : 전체 프로세스 목록 출력
grep nginx : 그중 nginx가 포함된 줄만 추림
wc -l : 최종 개수 계산

자주 사용하는 명령 연결 패턴

연결에 자주 쓰이는 명령어

ps : 프로세스 목록 확인
grep : 특정 문자열 검색
awk : 열 단위 추출, 간단한 가공
sort : 정렬
uniq : 중복 제거 또는 중복 개수 확인
wc : 줄 수, 단어 수, 문자 수 계산

로그 검색

로그에서 특정 에러만 찾고 싶다면 다음처럼 쓸 수 있다.

grep "ERROR" app.log

빈도도 셀 수 있다.

grep "ERROR" app.log | wc -l

자주 등장한 메시지를 보고 싶다면:

grep "ERROR" app.log | sort | uniq -c | sort -nr

grep : ERROR 포함 줄 추출
sort : 같은 줄끼리 모이도록 정렬
uniq -c : 중복 횟수 집계
sort -nr : 많은 순서대로 정렬

![[Pasted image 20260416171718.png]]

프로세스 필터링

특정 프로세스가 실행 중인지 확인할 때 자주 쓴다.

ps -ef | grep nginx

다만 이 방식은 grep nginx 자체도 결과에 포함되기 때문에, 아래 방식을 사용한다.

ps -ef | grep '[n]ginx'
ps -ef | grep nginx | grep -v grep

프로세스 개수만 확인하려면:

ps -ef | grep '[n]ginx' | wc -l

파일 내용 가공

파일에서 특정 열만 뽑거나 정리할 수 있다.

예를 들어 /etc/passwd에서 사용자 이름만 보고 싶다면:

awk -F: '{print $1}' /etc/passwd

중복 없이 정렬된 목록:

awk -F: '{print $1}' /etc/passwd | sort | uniq

로그에서 특정 필드만 뽑아 개수를 세는 식의 패턴도 자주 나온다.

awk '{print $1}' access.log | sort | uniq -c | sort -nr

표준 에러 분리

stderr와 stdout 분리가 필요한 이유

명령 실행 결과와 에러 메시지가 한 파일에 섞이면 실패 원인을 정확히 추적하기 어려워진다.

예를 들어 배치 작업이 실패했을 때, 정상 처리 로그와 에러 메시지가 뒤섞여 있으면
어디서 문제가 발생했는지 찾는 데 시간이 더 걸린다.

그래서 stdout과 stderr를 분리하면 다음이 쉬워진다.

정상 처리 결과 확인
에러 원인 추적
실패 시점 파악
자동화 스크립트에서 후속 처리 분기

에러 출력 분리하기

에러 메시지만 따로 파일로 저장하려면 2>를 사용한다.

ls existing.txt nofile.txt 2> error.txt

이 경우 존재하지 않는 파일에 대한 에러 메시지는 error.txt에 저장된다.

정상 출력은 별도로 처리하지 않았기 때문에 화면으로 나간다.

표준 출력과 표준 에러를 각각 분리하기

stdout과 stderr를 각각 다른 파일로 보낼 수도 있다.

ls > output.txt 2> error.txt

output.txt : 정상 출력 저장
error.txt : 에러 메시지 저장

이 방식은 정상 결과와 오류 메시지를 완전히 분리해서 보고 싶을 때 유용하다.

표준 출력과 표준 에러를 같은 파일에 저장하기

stdout과 stderr를 같은 파일에 함께 저장할 수도 있다.

ls > all.log 2>&1

> all.log : stdout을 all.log로 보냄
2>&1 : stderr도 stdout이 향하는 곳과 동일하게 보냄

정상 출력과 에러 메시지를 모두 all.log 하나에 저장한다.

Bash에서는 아래처럼 더 짧게 쓸 수도 있다.

ls &> all.log

출력 없이 실행만 하기

스크립트나 명령을 실행하되 출력은 모두 버리고 싶을 때는 /dev/null을 사용한다.

./script.sh > /dev/null 2>&1

/dev/null : 필요 없는 출력을 버리는 특수 파일
> /dev/null : 표준 출력을 버림
2>&1 : 표준 에러도 같은 곳으로 보냄

주로 다음 상황에서 사용한다.

출력이 너무 많지만 성공/실패만 확인하면 될 때
cron 같은 비대화형 실행에서 불필요한 출력을 줄이고 싶을 때
조용히 실행하고 종료 코드만 확인하고 싶을 때

stderr만 따로 남기기

정상 출력은 버리고, 에러만 보고 싶을 수도 있다.

ls > /dev/null 2> error.txt

표준 출력은 버림
표준 에러만 error.txt에 저장

정상 결과는 필요 없고 실패한 이유만 확인하고 싶을 때 유용하다.

예를 들어 배치 작업, 점검 스크립트, 파일 검사 스크립트에서는
정상 출력은 무시하고 에러만 따로 수집하는 식으로 활용할 수 있다.

Bash Script: 기본 문법과 실행 구조

Tue, 14 Apr 2026 00:00:00 GMT

리눅스에서 반복 작업을 자동화하거나 여러 명령을 순서대로 실행하려면 쉘 스크립트를 작성하게 된다.

특히 운영 환경에서는 명령을 한 번 실행하는 것을 넘어,
일관된 절차를 코드로 남기고 재사용 가능한 형태로 만드는 것이 중요하다.

이 글에서는 Bash 스크립트를 처음 다룰 때 필요한 기본 개념을 다음 흐름으로 정리한다.

Shell과 Bash

Shell

Shell은 사용자가 입력한 명령을 해석해 운영체제에 전달하는 명령어 인터페이스다.

사용자는 터미널에서 명령을 입력하고,
Shell은 그 명령을 해석한 뒤 적절한 프로그램을 실행한다.

이름 그대로 커널을 감싸는 껍데기 역할을 한다고 해서 Shell이라고 부른다.

Shell의 종류

Bourne Shell (sh)
C Shell (csh)
Z Shell (zsh)
Bourne Again Shell (bash)

헷갈리기 쉬운 용어

Shell: 명령을 해석하고 실행하는 프로그램

Terminal: Shell을 사용할 수 있게 해주는 화면 환경

Console: 시스템과 직접 연결된 입력/출력 환경을 가리키는 전통적 표현

Prompt: 명령 입력을 기다리는 표시 ($, # 등)

Bash

Bash는 여러 Shell 중 하나이며, 정식 이름은 Bourne Again Shell이다.

리눅스 환경에서 가장 널리 사용되는 Shell 중 하나이며,
Bourne Shell(sh)을 계승하면서 스크립트 작성과 사용자 편의 기능을 강화한 Shell이라고 볼 수 있다.

Bash는 단순히 명령을 실행하는 것뿐 아니라 다음 기능도 제공한다.

변수 사용
조건문, 반복문
명령 치환
스크립트 파일 실행
환경 변수 관리

이러한 기능 덕분에 Bash는
단순 명령 입력 도구를 넘어 자동화와 운영 작업을 작성하는 실행 환경으로도 사용된다.

Bash Script

Bash Script는 Bash가 읽고 실행할 명령들을 모아 둔 텍스트 파일이다.

즉, 사용자가 터미널에 직접 입력할 명령들을 파일로 저장해 반복 실행할 수 있게 만든 형태라고 볼 수 있다.

주로 다음과 같은 목적에 사용한다.

반복 작업 자동화
운영 절차 표준화
여러 명령의 순차 실행
환경 설정 및 배포 보조 작업

주요 특징은 다음과 같다.

텍스트 파일 형태로 작성한다
별도 컴파일 없이 쉘이 읽어서 실행한다
변수, 조건문, 반복문을 사용할 수 있다
운영 자동화와 반복 작업 처리에 적합하다

예를 들어 여러 명령을 매번 직접 입력하는 대신, 아래처럼 하나의 .sh 파일에 정리해둘 수 있다.
이렇게 하면 동일한 작업을 반복할 때 사람이 직접 명령을 다시 입력하지 않아도 된다.

#!/bin/bash
echo "start"
date
echo "done"

Bash Script의 기본 구조와 실행

기본 구조

기본적인 Bash 스크립트는 아래처럼 시작한다.

#!/bin/bash

echo "Hello, Bash"

Shebang

스크립트의 첫 줄에 자주 보이는 아래 구문을 Shebang이라고 한다.

#!/bin/bash

이 줄은 운영체제에게 “이 파일은 /bin/bash로 실행하라”는 의미를 전달한다.
즉, Shebang은 스크립트 파일 자체를 실행할 때 어떤 해석기를 사용할지 명시하는 역할이다.

예를 들어 Python 스크립트라면 이렇게 쓸 수 있다.

#!/usr/bin/env python3

Bash 스크립트에서는 보통 다음 둘 중 하나를 자주 사용한다.

#!/bin/bash

#!/usr/bin/env bash

실행 방식

Bash 스크립트는 대표적으로 두 방식으로 실행한다.

1. `bash script.sh`

이 방식은 Bash 프로그램이 script.sh 파일을 읽어서 실행하는 형태다.

실행 권한이 없어도 동작 가능
Shebang이 없어도 Bash로 실행 가능

2. `./script.sh`

이 방식은 파일 자체를 실행하는 형태다.

실행 권한이 있어야 함 chmod +x ./script.sh
Shebang이 있어야 어떤 인터프리터로 실행할지 명확함

실행 예시

실행 권한이 없는 상태에서, bash script.sh 방식으로 실행하면 성공하지만,
./script.sh 방식으로 실행하면 실패한다.
스크립트파일에 실행권한을 추가한 뒤에는 ./script.sh 방식으로도 실행에 성공했다.

Bash Script의 실행 흐름

명령어 실행과 순차 처리

Bash 스크립트는 명령을 위에서 아래로 순서대로 실행한다.

한 줄에 명령 하나를 쓰면 그대로 실행된다.

echo "start"

여러 줄로 작성하면 순서대로 처리된다.

echo "step 1"
date
echo "step 2"

한 줄에 세미콜론 ;으로 이어서 쓸 수도 있다.

echo "step 1"; date; echo "step 2"

종료 코드 (Exit Code)

Shell에서 모든 명령은 실행이 끝난 뒤 종료 코드(exit code) 를 남긴다.
이 값은 명령의 성공 여부를 판단하는 기준이 된다.

종료코드 값의 의미

0 → 성공
0이 아닌 값 → 실패 또는 예외 상황

`$?`로 결과 확인하기

$? 를 통해 직전에 실행한 명령의 종료 코드를 확인할 수 있다.

운영 스크립트에서는 이 종료 코드를 바탕으로 다음 동작을 계속할지, 에러 처리할지를 판단하게 된다.

예시

성공한 명령어 ls 의 종료 코드는 0
실패한 명령어 cat의 종료 코드는 1

변수와 문자열

Bash에서는 값을 변수에 저장해서 재사용할 수 있다.

일반 변수

일반 변수는 현재 쉘 안에서만 사용하는 값이다.

name="jiu"
echo "$name"

일반 변수를 정의할 때, = 양옆에 공백이 없어야 한다.

name="jiu"   # 정상
name = "jiu" # 오류

변수를 사용할 때는 앞에 $를 붙인다.

echo "$name"

예시

= 양 옆에 공백이 있는 경우, 변수 저장이 되지 않는다.

문자열

Bash Script에서 문자열은 작은따옴표와 큰따옴표로 표현할 수 있다.

작은따옴표 `' '`

문자열을 있는 그대로 취급한다.

name="jiu"
echo '$name'

출력

$name

큰따옴표 `" "`

변수나 일부 특수 문자가 해석된다.

name="jiu"
echo "$name"

출력

jiu

변수 참조

변수 앞에 $를 붙여 값을 꺼낸다.

name="jiu"  
echo "$name"

중괄호를 써서 경계를 명확히 할 수도 있다.

echo "${name}"

중괄호는 변수명과 다른 문자열이 붙을 때 특히 유용하다.

file="log"  
echo "${file}.txt"

문자열과 변수 참조 예시

작은따옴표로 감싼 문자열은 있는 그대로 저장된다.
큰따옴표로 감싼 문자열은 변수 해석이 적용된다.
중괄호를 써서 변수 경계를 명확히 할 수 있다.

환경변수와 export

환경 변수

환경 변수는 현재 쉘 + 현재 쉘이 실행하는 자식 프로세스에도 전달되는 변수다.

export name="jiu"

위처럼 환경변수를 설정하면 이후 실행되는 프로그램도 name 값을 참조할 수 있다.

환경 변수는 단순한 저장값이 아니라 실행 환경의 일부라고 볼 수 있다.
그래서 자식에게 상속되는 문맥에 포함되는 것이다.

export의 의미

export는 변수를 환경 변수로 내보내는 명령이다.

name="jiu"
export name

# 한 줄로 쓸 수도 있다.
export name="jiu"

예시

export를 실행하지 않으면 현재 쉘이 생성한 자식 bash 프로세스에서 $name을 인식하지 못한다.
export를 실행하면 현재 쉘이 생성한 자식 bash 프로세스에서 $name을 인식한다.

export의 유효기간

export한 변수는 현재 쉘과 그 자식 프로세스에서 유효하지만,
현재 세션이 끝나면 사라진다.

즉, 아래 경우에는 더 이상 유지되지 않는다.

터미널 세션 종료
해당 쉘 종료
새로 로그인한 다른 쉘 시작
시스템 재부팅 후 새 세션 시작

환경변수 영구적으로 유지하기

특정 환경변수를 영구적으로 유지하려면
매번 새 쉘이 시작될 때 다시 설정되도록 Shell 초기화 파일에 적어야 한다.

보통 아래 파일 중 하나에 export 문을 넣는다.

~/.bashrc
~/.bash_profile
~/.profile

실제로 ~/.bashrc 파일을 보면, PATH 환경변수를 지정하는 export 문이 기본으로 써있다.

자주 보는 환경 변수: `PATH`, `HOME`, `USER`

운영체제는 여러 기본 환경 변수를 제공한다.

`PATH`

명령어를 찾을 디렉터리 목록이다. 예를 들어 ls라고만 입력해도 실행되는 이유는
Shell이 알아서 PATH에 등록된 디렉터리들에서 ls 실행 파일을 찾기 때문이다.

echo "$PATH"

`HOME`

현재 사용자의 홈 디렉터리다. /home/user 같은 값이 들어 있다.

echo "$HOME"

`USER`

현재 사용자 이름이다. 스크립트 안에서 실행 계정을 확인할 때 자주 사용한다.

echo "$USER"

예시

명령행 인자

명령행 인자: `$0`, `$1`, `$2`, `$#`, `$@`

스크립트를 실행할 때 뒤에 값을 붙이면 그 값들을 스크립트 안에서 참조할 수 있다.
이를 통해 스크립트를 입력에 따라 다르게 동작하게 할 수 있다.

아래처럼 스크립트 실행 시 인자를 넘겨준다.

bash hello.sh apple banana

스크립트 내부에서는 다음처럼 접근한다.

$0 : 스크립트 이름
$1 : 첫 번째 인자
$2 : 두 번째 인자
$# : 인자 개수
$@ : 전체 인자 목록

예시

hello.sh

#!/bin/bash

echo "script: $0"
echo "first: $1"
echo "second: $2"
echo "third: $3"
echo "count: $#"
echo "all: $@"

리눅스 자원 제어: cgroup

Wed, 01 Apr 2026 00:00:00 GMT

멀티 유저, 멀티 프로세스 운영 환경에서는
각 서비스가 얼마나 CPU와 메모리를 사용할 수 있는지,
그리고 하나의 서비스 문제가 다른 서비스까지 번지지 않도록 어떻게 통제할 것인지가 중요하다.

따라서 프로세스를 실행 대상뿐만 아니라, 자원 관리의 대상으로도 다뤄야 한다.

이 글에서는 Red Hat 리눅스가 자원 통제를 어떻게 수행하는지, 다음 순서로 정리한다.

cgroup: 자원 관리의 핵심

cgroup이란?

cgroup은 Control Group의 약자로,

여러 프로세스를 하나의 그룹으로 묶고
그룹 단위로 자원을 제한하고 추적하는
리눅스 커널 기능이다.

예를 들어 다음과 같은 정책을 적용할 수 있다.

이 서비스는 메모리를 512MB까지만 사용
이 서비스는 CPU를 일정 비율까지만 사용
이 서비스는 생성 가능한 프로세스 수를 제한
이 서비스의 디스크 I/O를 제한

리눅스는 cgroup이라는 커널 기능을 통해 프로세스 그룹 단위로 자원을 제어한다.

cgroup이 제공하는 기능

cgroup은 크게 네 가지 기능을 제공한다.

1. 자원 제한 (Limit)

각 그룹에 사용할 수 있는 자원 한도를 설정할 수 있다.

CPU 사용량 제한
메모리 사용량 제한
디스크 I/O 제한
프로세스 수 제한

2. 자원 격리 (Isolation)

하나의 서비스가 문제를 일으켜도 다른 서비스까지 영향을 주지 않도록 분리할 수 있다.

3. 우선순위 제어 (Priority)

특정 서비스에 더 많은 CPU 비중을 주거나, 덜 중요한 작업의 우선순위를 낮출 수 있다.

4. 사용량 추적 (Accounting)

그룹 단위로 CPU, 메모리, I/O 사용량을 추적할 수 있다.

systemd: cgroup의 관리 주체

systemd와 cgroup의 관계

현대 리눅스에서 서비스 관리는 systemd가 담당한다.

systemd는 다음과 같은 운영 기능을 제공한다.

서비스 시작과 종료
상태 관리
자동 재시작
의존성 관리
로그 연계
자원 제어

이 가운데 자원 제어를 실제로 가능하게 해주는 기반이 바로 cgroup이다.

서비스별 cgroup 생성과 적용

systemd는 서비스를 실행할 때,

해당 서비스 전용 cgroup 을 만들고
관련 프로세스를 모두 그 안에 넣는다.
그 다음 필요한 자원 정책을 그 cgroup에 적용한다.

정리하면 내부 동작은 다음과 같다.

1. 서비스 실행
2. 해당 서비스용 cgroup 생성
3. 관련 프로세스를 그 cgroup에 배치
4. 자원 정책 적용

systemctl status로 cgroup 확인하기

systemctl status를 보면 다음과 같은 항목이 보인다.

CGroup: /system.slice/sshd.service

이 의미는 다음과 같다.

sshd.service에 속한 프로세스들이
/system.slice/sshd.service라는 cgroup 아래 묶여 있고
그 단위로 자원 관리가 이루어진다는 뜻이다

RHEL에서 보는 cgroup 구조

cgroup 버전

RHEL에서는 cgroup 버전에 따라 구조가 다르다.

cgroup v1에서는 리소스별로 CPU, 메모리, I/O 등이 각각 별도의 계층으로 나뉘어,
CPU용 트리와 메모리용 트리가 따로 존재했다.

반면 cgroup v2는 모든 자원을 하나의 트리에서 통합 관리한다.

이 구조는 다음 장점이 있다.

구조가 단순함
systemd와의 통합이 쉬움
자원 관리 방식이 일관됨

RHEL 9 이상에서는 cgroup v2 구조가 기본이다.

cgroup 기본 경로

/sys/fs/cgroup/

cgroup v2의 기본 경로는 위와 같다.
이 아래에서 systemd가 관리하는 서비스와 자원 구조를 확인할 수 있다.

systemd가 관리하는 cgroup 단위

cgroup 기본 경로 아래에는 systemd가 만든 단위들이 계층적으로 나타난다.
주요 단위는 다음과 같다.

1. slice

slice는 systemd가 만든 상위 논리 그룹이다.
자원 분배의 큰 틀을 나누는 단위라고 볼 수 있다.
예를 들어 system.slice 아래에 있다는 것은 해당 unit이 시스템 서비스 영역에 속한다는 뜻이다.

2. service

service는 실제 서비스 단위이다.
보통 systemd의 service unit과 1:1로 대응한다.
예: sshd.service, nginx.service

3. scope

scope는 서비스 외부에서 시작된 프로세스를 systemd 관리 범위 안에 포함시킬 때 사용하는 단위다.

정리하면 다음과 같다.

slice: 상위 그룹

service: 실제 서비스 단위

scope: 외부 프로세스 관리 단위

cgroup controller 파일

실제 자원 제한과 사용량 확인은 controller 파일을 통해 이루어진다.

cgroup 디렉터리 안에는 자원 제한과 상태 확인에 사용하는 controller 파일들이 있다.
이 파일들이 실제 자원 제어 인터페이스 역할을 한다.

대표적인 controller는 다음과 같다.

controller	역할
`cpu`	CPU 사용량 제어
`memory`	메모리 제한 및 사용량 확인
`io`	디스크 I/O 제어
`pids`	프로세스 수 제한

예를 들어 다음 경로를 보자.

/sys/fs/cgroup/system.slice/sshd.service/

이 안에는 다음과 같은 파일이 있을 수 있다.

cpu.max
memory.max
memory.current
pids.max

이 파일들의 의미는 다음과 같다.

*.max : 어디까지 허용할 것인가
*.current : 지금 얼마나 쓰고 있는가

실제로 출력해보면 아래처럼 값이 나타난다.

자원 제어의 동작 방식

systemd 설정이 cgroup으로 반영되는 방식

운영자는 보통 cgroup 파일을 직접 수정하기보다, systemd 설정을 통해 자원 정책을 적용한다.

예를 들어 unit file에 다음과 같이 설정할 수 있다.

[Service]
CPUQuota=20%
MemoryMax=512M

이 설정은 내부적으로 cgroup 관련 값으로 반영된다.

예를 들어 다음과 같은 controller 파일과 연결된다.

cpu.max
memory.max

운영자가 unit file을 통해 자원 정책을 설정하면
systemd가 controller 파일에 매핑하여 구현한다.

실행 중 자원 정책 변경

cgroup 기반 자원 정책은 실행 중에도 변경할 수 있다. 다음 두가지 방식으로 자원 정책을 변경할 수 있다.

1. systemd 방식

systemctl set-property nginx.service CPUQuota=30%

이 명령은 서비스 재시작 없이 자원 정책을 즉시 적용한다.

2. low-level

echo "30000 100000" > cpu.max

이처럼 group 파일을 직접 수정할 수도 있다.
다만 실제 운영에서는 직접 파일을 수정하기보다, systemd를 통해 관리하는 것이 더 안전하고 일관적이다.

정리

리눅스에서 자원 관리는 프로세스 그룹 단위로 이루어진다.
cgroup은 프로세스를 그룹 단위로 묶어 자원을 제어하는 커널 기능이다.
systemd는 서비스를 실행할 때 해당 서비스용 cgroup을 만들고 자원 정책을 적용한다.
cgroup 디렉터리의 controller 파일들을 통해 실제 제한과 사용량 확인이 이루어진다.
운영자가 unit file을 통해 자원 정책을 설정하면 systemd가 controller 파일에 매핑하여 구현한다.

리눅스 작업 스케줄링: cron, at

Wed, 01 Apr 2026 00:00:00 GMT

서버 운영을 하다 보면 반드시 정해진 시점에 실행해야 하는 작업이 생긴다.
예를 들어 백업, 로그 정리, 임시 파일 삭제, 리포트 생성, 배치 실행 같은 작업은
사람이 매번 수동으로 처리하기 어렵다.

그래서 운영에서는 작업을 자동으로 예약하고 실행하는 도구가 필요하다.

이 글에서는 리눅스 작업 스케줄링에 대해 다음 흐름으로 정리한다.

cron: 주기 작업 스케줄러

1. 개념

cron은 리눅스에서 가장 대표적인 주기적 작업 스케줄러다.
정해진 시간이나 주기에 따라 작업을 반복 실행할 때 사용한다.

예를 들어 다음과 같은 작업이 cron의 대상이 된다.

매일 새벽 백업 실행
일정 주기 로그 정리
캐시 / 임시 파일 삭제
주기적 배치 작업 실행

즉 cron은 반복되는 운영 작업을 자동화하는 기본 도구라고 볼 수 있다.

2. 동작 구조

구성 요소

작업 정의: crontab
실행 주체: crond
서비스 관리: systemd

실행 흐름

사용자는 crontab에 실행 규칙을 등록한다.
실제 실행은 백그라운드 데몬인 crond가 수행한다.
데몬은 systemd가 서비스 단위로 관리한다.

3. 운영 시 주의사항

cron은 조용히 실패(silent failure) 할 수 있다.

대표적인 원인은 다음과 같다.

환경 변수 미설정 (PATH)
권한 문제
스크립트 내부 에러
표준 출력 / 에러 출력이 별도로 수집되지 않음

예를 들어 터미널에서는 잘 실행되던 스크립트가, cron에서는 실패하는 경우가 자주 있다.
이는 cron이 로그인 셸과 다른 환경에서 실행되기 때문이다.

그래서 운영 환경에서는 단순히 작업을 등록하는 것보다, 실패를 확인할 수 있게 만드는 것이 더 중요하다.

따라서 실무에서는 반드시 다음을 고려해야 한다.

로그 파일로 출력 리다이렉션
에러 출력 포함 (2>&1)
모니터링 연계

4. crontab 기본 명령어

# 현재 등록된 작업 확인
crontab -l

# 작업 편집
crontab -e

5. crontab 포맷

cron은 다음 5개의 시간 필드로 실행 시점을 지정한다.

* * * * * command
│ │ │ │ │
│ │ │ │ └ 요일 (0-7, 일요일=0 또는 7)
│ │ │ └ 월 (1-12)
│ │ └ 일 (1-31)
│ └ 시 (0-23)
└ 분 (0-59)

6. crontab 사용 예시

0 3 * * * /opt/myapp/backup.sh >> /var/log/myapp-backup.log 2>&1

이 설정은 다음 의미를 가진다.

매일 새벽 3시 실행
표준 출력 + 에러 로그를 파일에 기록

실행뿐 아니라 실패 여부를 나중에 추적할 수 있도록 로그까지 함께 남기는 형태다.

at: 단발성 작업 스케줄러

1. 개념

at은 한 번만 실행되는 작업 을 예약할 때 사용한다.

예를 들어 점검 종료 후 새벽 2시에 스크립트를 한 번 실행하거나,
일정 시각에 일회성 후처리 작업을 예약할 때 사용할 수 있다.

2. at 사용 예시

at 02:00
> /opt/myapp/run-once-job.sh
> Ctrl+D

위 예시는 지정한 시각에 스크립트를 한 번 실행하도록 예약하는 방식이다.

명령 입력을 마친 뒤 Ctrl + D를 누르면 작업이 등록된다.

3. at 주요 명령어

# 예약 목록 확인
atq

# 작업 삭제
atrm <job_id>

4. 동작 구조

구성 요소

작업 등록: at
실행 주체: atd
서비스 관리: systemd

실행 흐름

사용자는 at 명령으로 실행 규칙을 등록한다.
실제 실행은 백그라운드 데몬인 atd가 수행한다.
데몬은 systemd가 서비스 단위로 관리한다.

*구조는 cron과 비슷하지만, 반복 실행이 아니라 1회 실행이라는 점이 다르다.

systemd 환경의 작업 스케줄링

지금까지의 내용을 systemd 관점에서 정리하면,
리눅스 작업 스케줄링 구조는 다음처럼 볼 수 있다.

구성 요소	역할	systemd 관계
cron	반복 작업 스케줄링	`crond.service`로 관리
at	단발성 작업 스케줄링	`atd.service`로 관리
systemd	스케줄러 데몬의 실행·상태 관리	상위 관리 주체

사용자는 cron, at으로 언제 작업을 실행할지 정의하고,
systemd는 그 규칙을 수행하는 데몬의 실행과 상태를 관리한다.

(참고) 대안: systemd timer

systemd 환경에서는 cron 대신 systemd timer를 사용하는 방식도 존재한다.

보통 .service와 .timer를 조합해서 사용하며,
systemd 체계 안에서 더 일관되게 관리할 수 있다는 장점이 있다.

주요 특징

.service + .timer 조합
journal과 연계된 로그 확인
의존성 및 실행 순서 관리 가능

하지만 다음의 이유로 실무에서는 여전히 cron이 많이 사용된다.

기존 시스템과의 호환성
단순 작업에 대한 직관성
빠르게 등록하고 확인하기 쉬운 사용성

정리

cron은 반복 작업 스케줄링 도구
at은 1회성 작업 스케줄링 도구
crond, atd는 각각 systemd가 관리하는 서비스
운영에서는 작업 등록 자체보다 실패를 확인할 수 있는 로그와 실행 결과 관리가 더 중요하다

리눅스 프로세스: 구조부터 제어까지

Wed, 01 Apr 2026 00:00:00 GMT

리눅스에서 실행되는 모든 프로그램은 프로세스 단위로 관리된다.

프로세스는 PID, 부모-자식 관계, 실행 상태, 자원 사용 정보등을 가지며,
운영체제는 이를 기준으로 프로그램의 실행을 추적하고 제어한다.

이 글에서는 리눅스 프로세스가 어떤 구조로 동작하고 관리되는지 다음 순서로 정리한다.

프로세스의 시작: PID 1

리눅스에서 사용자 공간의 모든 프로세스는
부팅 직후 커널이 실행한 첫 번째 프로세스에서 출발한다.
이 첫 프로세스가 바로 PID 1 이다.

커널은 사용자 프로그램을 하나씩 직접 실행하지 않는다.
대신 사용자 공간의 시작점이 되는 프로세스 하나를 먼저 실행하고,
이후의 서비스와 세션 관리는 그 프로세스가 맡는다.

커널은 직접 모든 사용자 프로그램을 실행하지 않고,
사용자 공간의 시작점이 되는 PID 1 을 먼저 실행한다.

부팅 이후 실행 흐름

부팅 직후 실행 흐름은 다음과 같다.

펌웨어(BIOS/UEFI) 가 하드웨어를 초기화
부트로더(GRUB 등) 가 리눅스 커널을 메모리에 적재
커널(kernel) 이 메모리, CPU, 장치 드라이버, 파일시스템 등을 초기화
커널이 사용자 공간의 첫 프로세스인 PID 1 을 실행
PID 1 이 이후 서비스와 세션을 시작

즉, 사용자 공간은 커널이 실행한 PID 1 에서부터 시작된다.

PID 1의 역할

PID 1은 이후 사용자 공간 전체의 기준점이 된다.

모든 사용자 공간 프로세스의 최상위 부모
서비스 시작 및 관리
orphan 프로세스 수용

init과 systemd

이러한 PID 1 역할을 전통적으로는 init 이 맡았고, 현대 리눅스에서는 대부분 systemd 가 맡는다.
둘 다 사용자 공간의 첫 프로세스라는 점은 같지만, 시스템을 관리하는 방식에는 차이가 있다.

왜 init에서 systemd로 넘어갔을까?

전통적인 init은 현대 시스템을 운영하기에는 몇 가지 한계가 있었다.

서비스들을 순차적으로 실행해서 부팅이 느릴 수 있음
서비스 간 의존성 관리가 어려움
로그, 타이머, 소켓 같은 운영 기능이 분리되어 있음

반면 systemd는 이런 한계를 보완하면서, 현대 리눅스 운영 환경에 맞는 기능을 함께 제공한다.

의존성 기반 실행
병렬 부팅
서비스/로그/타이머의 통합 관리

init은 서비스를 순서대로 띄우는 시작점에 가까웠다면

systemd는 서비스들을 관계 기반으로 관리하는 운영 체계에 가깝다.

프로세스의 구조: 계층적 트리

PID 1 이후에 만들어지는 프로세스들은
서로 독립적으로 존재하는 것이 아니라, 부모-자식 관계를 가지는 트리 구조를 이룬다.

그래서 프로세스를 이해할 때는
무엇이 실행 중인지만 보는 것이 아니라, 누가 누구를 생성했는가까지 함께 봐야 한다.

이 구조를 이해하면 다음과 같은 점에서 도움이 된다.

어떤 프로세스가 누가 만든 것인지를 통해 동작 흐름을 이해할 수 있다
장애 분석 시 원인을 추적하기 쉽다
종료나 재시작 시 영향 범위를 판단할 수 있다

트리 구조의 특징

프로세스 트리는 몇 가지 기본 특징을 가진다.

모든 프로세스는 고유한 PID 를 가진다
대부분의 프로세스는 자신을 만든 부모의 PPID(Parent PID) 를 가진다
새로운 프로세스는 기존 프로세스가 생성한다
사용자 공간 프로세스 트리의 최상위 기준점은 PID 1(systemd) 이다

프로세스의 상속

자식 프로세스는 부모가 가진 실행 문맥 일부를 이어받은 상태에서 시작한다.

대표적으로 다음과 같은 것들이 상속된다.

환경 변수
현재 작업 디렉터리
파일 디스크립터
사용자 및 권한 정보
일부 리소스 제한값

이런 상속 구조 덕분에, 셸에서 환경 변수를 export 한 뒤 명령어를 실행하면
그 명령어가 실행된 프로세스도 같은 환경을 사용할 수 있다.

orphan과 zombie 프로세스

프로세스 트리에는 일반적인 부모-자식 관계만 있는 것이 아니라,
운영 중 자주 언급되는 예외적인 상태도 있다.

orphan process

부모 프로세스가 먼저 종료되어 고아가 된 자식 프로세스
자식 프로세스는 보통 PID 1(systemd)가 수용한다
부모가 종료되었다고 해서 자식이 즉시 함께 종료되지는 않는다

zombie process

자식 프로세스는 이미 종료되었지만, 부모가 종료 상태를 아직 회수하지 않아
프로세스 테이블에 남아 있는 상태
실제로 실행 중인 것은 아니며, 부모가 wait() 계열 호출로 상태를 회수하면 정리된다

orphan은 살아 있는 자식이 부모를 잃은 상태이고,
zombie는 이미 종료된 자식의 상태 정보가 아직 회수되지 않은 상태다.

프로세스의 생성과 실행

프로세스 트리는 기존 프로세스가 새로운 프로세스를 만들면서 형성된다.

리눅스에서는 이 과정을 보통 fork() 와 exec()로 설명한다.

fork(): 새 프로세스를 만든다
exec(): 현재 프로세스를 다른 프로그램으로 바꾼다

리눅스에서 프로그램 실행은
프로세스 생성(fork) 과 프로그램 교체(exec) 가 이어지는 구조로 이해할 수 있다.

fork(): 프로세스 생성

fork() 는 현재 프로세스를 복제하여 자식 프로세스를 만든다.

pid = fork();

fork() 가 호출되면, 부모와 자식은 거의 동일한 실행 문맥을 가진 상태에서 각각 실행을 이어간다.

반환값은 다음과 같다.

부모 프로세스: 자식의 PID 반환
자식 프로세스: 0 반환
실패 시: -1

부모와 자식은 같은 코드에서 시작하지만, 반환값이 다르기 때문에 이후 서로 다른 동작으로 분기할 수 있다.

exec(): 프로그램 교체

exec() 계열 함수는 현재 프로세스의 메모리 공간을 새 프로그램으로 덮어쓴다.

exec("/bin/ls", ...);

exec() 는 새 프로세스를 만들지 않고, 이미 존재하는 프로세스를 다른 프로그램으로 교체한다.

따라서 다음의 특징이 있다.

기존 PID 유지
기존 프로세스 자리에 새 프로그램이 올라감
성공하면 원래 코드로 돌아오지 않음

왜 fork() 와 exec() 를 나눴을까

두 과정이 분리되어 있어서 프로세스를 실행하기 전에 필요한 준비를 먼저 할 수 있다.

예를 들면 자식 프로세스에서 exec() 전에 다음과 같은 작업이 가능하다.

표준 입력/출력 리다이렉션
파일 디스크립터 정리
환경 변수 설정
권한 변경

즉 실행 환경을 먼저 준비한 뒤 원하는 프로그램으로 교체할 수 있기 때문에
fork() 와 exec() 가 나뉘어 있다.

Shell에서 명령어가 실행되는 흐름

터미널에서 ls 를 입력하면 개념적으로 다음과 같이 동작한다.
(실제 구현에서는 clone이나 posix_spawn 같은 최적화가 사용될 수 있다.)

bash → fork → exec(ls)

bash 가 자식 프로세스를 하나 만든다
자식 프로세스가 exec() 를 호출해 ls 프로그램으로 바뀐다
부모 셸은 자식이 끝날 때까지 기다리거나, 상황에 따라 백그라운드로 넘긴다

프로세스 관찰 및 제어

이제 실행 중인 프로세스를 어떻게 확인하고, 상태를 바꾸고, 자원 사용을 조정할 것인지 알아보자.

리눅스에서 프로세스 제어는 크게 세 가지로 나뉜다.

조회: ps, top
상태 변경: kill
자원 사용 제어(우선순위): nice, renice

ps: 현재 프로세스 조회

*ps: process status의 약자

현재 시점의 프로세스 상태를 정적인 스냅샷으로 보여준다.

자주 쓰는 옵션

a: 다른 사용자 프로세스도 포함
u: 사용자 중심 포맷
x: 터미널 없는 프로세스도 포함
e: 환경 변수까지 함께 표시
f: 부모-자식 관계를 포함한 full format 표시

자주 쓰는 형태

# 가장 많이 쓰이는 형태
ps aux

# 시스템 전체 프로세스를 계층/관계 중심으로 보기 좋다.
ps -ef

# 특정 PID만 조회
ps -p <PID>

# 프로세스 트리 형태로 보기  
ps -ef --forest

top: 실시간 프로세스 모니터링

시스템의 CPU, 메모리, 로드 평균, 프로세스 상태를 실시간으로 갱신해서 보여준다.

확인하는 것

CPU 사용률
메모리 사용량
load average
어떤 프로세스가 자원을 많이 먹는지
프로세스 상태 (R, S, D, Z 등)

자주 쓰는 형태

# 특정 PID만 집중 모니터링
top -p <PID>

# 특정 사용자의 프로세스만 보기
top -u <user_name>

# 갱신 주기 지정
top -d <second>

# 전체 커맨드라인 표시
top -c

실행 중 자주 쓰는 키

P: CPU 사용량 기준 정렬
M: 메모리 사용량 기준 정렬
k: 프로세스 종료 신호 보내기
r: nice 값 변경
1: CPU 코어별 보기
q: 종료

kill: 프로세스에 제어 시그널 전달

프로세스를 종료하는 명령어가 아니라, 프로세스에 시그널을 보내는 명령어다.
종료뿐 아니라 재로드, 일시 정지, 재개 같은 제어에도 사용할 수 있다.

자주 쓰는 형태

# 기본 종료 요청 - SIGTERM(15)
kill <PID>

# SIGTERM 명시
kill -TERM <PID>

# 재시작 없이 설정 재로드 용도로 자주 사용
kill -HUP <PID>

# 시그널 목록 확인
kill -l

자주 쓰는 시그널

시그널	의미	용도
`SIGTERM (15)`	정상 종료 요청	가장 먼저 시도
`SIGKILL (9)`	강제 종료	최후 수단
`SIGINT (2)`	인터럽트	Ctrl+C 유사
`SIGHUP (1)`	hangup/reload	설정 재적용 용도
`SIGSTOP`	일시 정지	즉시 멈춤
`SIGCONT`	재개	중단 후 다시 실행

운영 주의사항

무조건 kill -9 부터 쓰지 않는다
먼저 SIGTERM 으로 정상 종료를 시도한다
종료가 안 될 때만 SIGKILL 고려한다.
서비스라면 kill 보다 systemctl stop/restart 가 우선이다

nice / renice: CPU 우선순위 조정

리눅스 스케줄러는 모든 프로세스에 동일하게 CPU를 주지 않는다.
각 프로세스는 우선순위를 가지며, 사용자는 nice 값을 통해 이를 조정할 수 있다.

기본 규칙

값 범위: -20 ~ 19
숫자가 낮을수록 우선순위 높음
숫자가 높을수록 우선순위 낮음

nice: 새 프로세스를 특정 우선순위로 시작

nice -n 10 python app.py

renice: 이미 실행 중인 프로세스의 우선순위 변경

renice -n 5 -p 1234

nice와 renice는 프로세스를 종료하지 않고도
CPU 경쟁에서의 상대적 우선순위를 조정할 수 있게 해준다.

정리

모든 프로세스는 PID 1에서 시작된다
프로세스는 트리 구조로 연결된다
실행은 fork → exec으로 이루어진다
운영자는 이를 조회(ps/top)하고 제어(kill/nice) 한다

리눅스 서비스 관리: systemd, systemctl, unit file

Wed, 01 Apr 2026 00:00:00 GMT

리눅스 운영 환경에서는 단순히 프로세스가 실행 중인가만 보는 것으로는 충분하지 않다.
실제로 운영에서는 서비스가 정상적으로 관리되고 있는가를 기준으로 시스템을 바라보게 된다.

예를 들어 어떤 프로그램이 죽었을 때,
단순 프로세스라면 종료된 것으로 끝나지만 서비스로 관리되고 있다면 자동으로 다시 시작될 수 있다.
또 부팅 시 자동 실행, 권한 분리, 환경 변수 주입, 로그 확인까지 모두 서비스 단위에서 관리된다.

이 글에서는 리눅스 서비스 운영의 핵심 개념을 다음 순서로 정리한다.

서비스: 리눅스 운영의 중심

리눅스 운영은 프로세스가 아니라 서비스 단위로 제어한다.

프로세스와 서비스는 무엇이 다를까

리눅스를 처음 배울 때는 보통 프로세스의 개념과 관리 방법을 먼저 배운다.
운영 관점에서는 여기서 한 단계 더 나아가 서비스라는 관리 단위를 이해해야 한다.

프로세스 vs 서비스

구분	프로세스 (Process)	서비스 (Service)
정의	실행 중인 프로그램	운영 단위
생명주기	죽으면 끝	재시작 가능
관리 방식	`kill`, `ps`	`systemctl`
운영 관점	개별 실행 단위	정책 기반 관리 단위

프로세스는 실행 상태이고,
서비스는 운영 정책을 포함한 단위이다.

모든 서비스는 하나 이상의 프로세스를 포함한다.
모든 프로세스가 서비스는 아니다.

서비스

따라서 서비스는 단순히 프로그램을 띄우는 개념이 아니다.

보통 아래와 같은 운영 요소를 함께 포함한다.

자동 재시작
로그 관리
부팅 시 자동 실행
실행 계정 및 권한 설정
환경 변수 주입

즉, 서비스는 리눅스에서
프로세스를 더 안정적이고 일관되게 운영하기 위해 사용하는 관리 단위라고 볼 수 있다.

systemd: 리눅스 서비스 관리의 중심

systemd는 현대 리눅스 배포판에서 서비스 관리를 담당하는 표준 시스템이다.

systemd의 역할

systemd는 시스템 전반의 실행 흐름을 관리하는 중심 역할을 맡는다.

주요 역할은 다음과 같다.

PID 1, 시스템에서 가장 먼저 시작되는 프로세스
다른 프로세스들의 부모 프로세스
서비스 실행 및 상태 관리
부팅 과정 제어
로그 관리 (journalctl)

특히 PID 1이라는 점이 중요하다.
리눅스에서 시스템이 부팅되면 가장 먼저 시작되는 프로세스가 systemd 이고,
이후 여러 서비스와 데몬이 이 흐름 아래에서 관리된다.

실제로 pstree 명령어를 쳐보면, 대부분의 프로세스의 부모 프로세스가 systemd 인것을 확인할 수 있다.

systemd의 특징

Red Hat 계열에서 도입되었고, 현재는 Ubuntu를 포함한 대부분의 주요 리눅스 배포판에서 사용된다.
운영 중인 서비스의 상태를 판단할 때 사실상 기준점 역할을 한다.

운영 환경에서는 systemd를 기준으로 이 서비스가 살아있는지를 확인한다.

systemctl: 서비스 제어 인터페이스

systemctl은 systemd를 제어하기 위한 CLI 도구이다.

주요 명령어

# 상태 확인
systemctl status <service>

# 시작 / 중지
systemctl start <service>
systemctl stop <service>

# 재시작
systemctl restart <service>

# 부팅 시 자동 실행
systemctl enable <service>
systemctl disable <service>

systemctl status로 서비스 상태 확인하기

이 출력에서 특히 중요하게 봐야 하는 항목은 세 가지다.

1. Active

현재 서비스 상태를 보여준다.
서비스가 죽었는지, 살아 있는지를 가장 먼저 판단하는 기준이다.

active (running): 정상 실행 중
failed: 실패 상태
inactive: 실행 중이 아님

2. Main PID

실제로 이 서비스를 대표해서 실행 중인 프로세스의 PID다.
운영 중 프로세스 트리나 리소스 사용량을 볼 때 연결점이 된다.

3. 최근 로그

systemctl status 하단에는 최근 로그 몇 줄이 같이 붙는 경우가 많다.
이 부분이 장애 원인을 빠르게 추정하는 데 매우 유용하다.

systemctl status를 통해 현재 상태 + 실패 힌트를 함께 확인할 수 있다.

Unit File: 서비스 운영 정책 문서

Unit File은 서비스가 어떤 운영 정책 아래 움직이는지를 판단할 수 있는 문서이다.

Unit

systemd를 이해하려면 Unit 개념도 알아야 한다.

Unit은 systemd가 관리하는 시스템 구성 요소를 의미한다.
서비스뿐 아니라 마운트 지점, 소켓, 타겟 등도 모두 Unit으로 표현된다.

즉, systemd는 서비스만 관리하는 것이 아니라,
시스템 자원과 동작 단위를 유닛(Unit) 이라는 공통 개념으로 관리한다.

systemctl list-units 명령어를 통해 모든 유닛들을 조회할 수 있다. 그중 서비스 유닛만을 출력해봤다.

Unit File: 서비스의 실행 정의

“everything is a file” 이라는 리눅스의 철학처럼,
systemd의 서비스 운영 정책도 파일 형태로 정의된다.
그 파일이 바로 Unit File이다.

실무에서는 아예 새 unit file을 처음부터 만드는 일보다,
기존 서비스의 unit file을 읽고 해석하거나 일부 수정하는 일이 더 자주 생긴다.

따라서 unit file을 통해 이 서비스가 어떤 운영 정책 아래 움직이는지를 판단할 수 있어야 한다.

Unit의 종류

유닛 유형	확장자	설명
service	`.service`	시스템 서비스, 보통 데몬
device	`.device`	커널이 인식한 디바이스
mount	`.mount`	파일 시스템 마운트 지점
path	`.path`	파일 또는 디렉터리 경로 감시
socket	`.socket`	프로세스 간 통신에 사용하는 소켓
snapshot	`.snapshot`	저장된 시스템 상태
target	`.target`	여러 unit을 묶는 논리적 그룹

Unit File의 위치

Unit file은 보통 다음 디렉토리들에서 관리된다.

디렉토리	설명
`/usr/lib/systemd/system/`	패키지 설치 시 함께 제공되는 기본 unit file
`/run/systemd/system/`	런타임에 생성되는 임시 unit file
`/etc/systemd/system/`	운영자가 override 하거나 enable 설정에 의해 반영되는 영역. 우선순위가 가장 높다

운영 관점에서는 /etc/systemd/system/이 특히 중요하다.
기본 설정 위에 운영자 의도가 덮어씌워지는 위치이기 때문이다.

Unit File 구조 읽기

unit file은 보통 세 개의 블록으로 나뉜다.

[Unit]
Description=My Service
After=network.target

[Service]
ExecStart=/usr/bin/my-app
WorkingDirectory=/app
User=appuser
Environment=ENV=prod
Restart=always

[Install]
WantedBy=multi-user.target

각 블록의 역할은 다음과 같다.

[Unit]

서비스의 메타 정보와 의존성을 정의한다.

[Service]

가장 중요한 블록으로, 실제로 어떻게 실행할 것인가가 정의된다.
핵심 항목
- ExecStart: 실제 실행 명령
- WorkingDirectory: 실행 위치
- User / Group: 실행 계정
- Environment / EnvironmentFile: 환경 변수 주입
- Restart: 재시작 정책
운영자가 이 블록에서 반드시 파악해야 하는 것은 보통 다음 세 가지다.
- 어떤 명령으로 실행되는가
- 어떤 계정으로 실행되는가
- 죽었을 때 어떤 정책으로 다시 뜨는가

[Install]

이 서비스가 enable 되었을 때 어느 target에 연결될지를 정의한다.
쉽게 말해 부팅 시 자동 시작 설정과 연결되는 영역이다.

Unit File 확인 방법

1. 서비스의 unit file 보기

systemctl cat <service>

2. 로드된 unit 위치 확인하기

systemctl status <service>

출력 중 Loaded 항목을 보면 어느 파일이 현재 로드되었는지 알 수 있다.

예를 들어, 아래 결과는 현재 sshd.service가 어느 위치에서 로드되었는지 보여준다.

Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)

실제 예시로 보는 Unit File

ExecStart=/usr/sbin/sshd -D $OPTIONS
→ 실제로 어떤 명령으로 SSH 데몬이 실행되는지 알 수 있다.
EnvironmentFile=-/etc/sysconfig/sshd
→ 별도 환경 파일을 통해 옵션이 주입될 수 있음을 알 수 있다.
Restart=on-failure
→ 실패 시 자동 재시작 정책이 걸려 있음을 알 수 있다.

Unit File 수정 후 꼭 해야 하는 작업

unit file을 수정한 뒤에는 아래 명령이 필요하다.

systemctl daemon-reload
systemctl restart <service>

이유는 다음과 같다.

systemd는 unit file을 읽어 내부적으로 로드해 둔다.
따라서 파일만 수정하고 끝내면 변경 내용이 바로 반영되지 않을 수 있다.

따라서 아래 두 단계가 함께 가는 경우가 많다.

daemon-reload: 설정 다시 읽기
restart: 실제 서비스 재기동

왜 kill 했는데 프로세스가 다시 뜰까?

운영하다 보면 프로세스를 죽였는데 다시 살아나는 상황을 자주 겪는다.

이 글을 통해 리눅스 운영의 중심이 프로세스가 아니라 서비스라는 점을 이해했다면,
그 원인도 자연스럽게 파악할 수 있을 것이다.

해당 프로세스가 systemd에 의해 서비스로 관리되고 있어서,
프로세스를 종료해도 서비스 정책에 따라 다시 실행된 것이다.

그래서 실무에서는 장애가 났다고 해서 바로 kill하는 것이 아니라,
먼저 어떤 서비스가 이 프로세스를 관리하고 있는지 확인한 뒤 systemd를 통해 조치한다.

보통은 아래와 같은 흐름으로 대응한다.

1. status 확인
2. 로그 확인
3. restart로 복구 시도

리눅스 운영에서는 프로세스 하나가 아니라,
프로세스를 관리하는 서비스 단위로 시스템을 이해하는 것이 중요하다!

Amazon Athena

Mon, 23 Mar 2026 00:00:00 GMT

한줄요약

S3 데이터에 쿼리하는 서버리스 서비스

What is it?

표준 SQL을 사용해서 Amazon S3에 있는 데이터를 쉽게 분석할 수 있는 대화형 쿼리 서비스
서버리스 서비스로, 관리할 인프라가 없고 실행한 쿼리에 대해서 비용 지불.
자동으로 확장되며, 쿼리를 병렬 실행하여 빠르게 결과를 반환
S3 데이터를 in-place 조회하므로, 별도 적재 없이 ad hoc 쿼리에 적합
AWS Glue Data Catalog, 외부 Hive metastore, federated query와 연계해 메타데이터를 관리할 수 있음

When use it?

S3에 저장된 정형/반정형/비정형 데이터 분석 (CSV, JSON, Parquet 등)
S3 데이터에 대해 간단한 ad hoc SQL 쿼리를 빠르게 실행하고 싶을 때
인프라나 클러스터를 직접 구축/운영하고 싶지 않을 때
로그 분석, 리포팅, 탐색적 주문처럼 주문형 조회가 필요할 때
S3 Inventory, AWS Cost and Usage Report, 각종 AWS 서비스 로그를 SQL로 조회하고 싶을 때

Key points for SAA

S3에 있는 데이터를 최소 변경, 최소 운영으로 SQL 조회 → Athena
S3 + SQL + 서버리스 + ad hoc 쿼리 + 운영 오버헤드 최소화 → Athena
이미 데이터가 S3에 저장되어 있다면 Athena를 가장 먼저 떠올리기
보통 Glue Data Catalog와 함께 출제됨

참고자료

https://docs.aws.amazon.com/athena/latest/ug/what-is.html https://docs.aws.amazon.com/athena/latest/ug/when-should-i-use-ate.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-inventory-athena-query.html

Amazon S3 Transfer Acceleration

Mon, 23 Mar 2026 00:00:00 GMT

한줄요약

전 세계 클라이언트가 먼 S3 버킷에 대용량 데이터를 빠르게 업로드하도록 돕는 S3 기능

What is it?

전 세계 어디서든 멀리 떨어진 중앙 S3 버킷으로 더 빠르게 업로드할 수 있게 해주는 S3 버킷 기능
사용자는 가까운 CloudFront 엣지 로케이션에 먼저 업로드하고, 이후 AWS 글로벌 백본 네트워크를 통해 대상 S3 버킷으로 전달됨
장거리 인터넷 구간의 비효율을 줄여 업로드 성능을 개선함

When use it?

여러 국가·대륙의 사용자 또는 지사에서 하나의 S3 버킷으로 데이터를 빠르게 모아야 할 때
GB~TB 규모의 대용량 데이터를 장거리로 업로드할 때
공용 인터넷만으로는 장거리 전송 속도와 안정성이 떨어질 수 있을 때
운영 복잡도 증가 없이 S3 업로드 성능을 개선하고 싶을 때

Key points for SAA

글로벌 업로드 가속이 필요하면 가장 먼저 떠올릴 것
단일 S3 버킷으로 직접 업로드하는 구조에 적합
별도 서버나 복잡한 중계 아키텍처 없이 사용 가능
멀티파트 업로드와 함께 쓰면 대용량 파일 업로드에 더 유리함

참고자료

https://docs.aws.amazon.com/AmazonS3/latest/userguide/transfer-acceleration.html

리눅스 가상머신 SSH로 접속하기

Sat, 21 Mar 2026 00:00:00 GMT

RHEL 10을 Minimal Install로 설치한 뒤 CLI 환경에서 실습을 시작했는데,
터미널 스크롤이 되지 않아 이전 출력 내용을 확인하기가 불편했다.

그래서 VM 안에 SSH 서버를 설치하고, macOS의 iTerm으로 접속해서 작업하는 방식으로 환경을 바꿨다.

이번 글에서는 그 설정 과정을 순서대로 정리한다.

1. 일반 사용자 생성

SSH 접속을 위한 사용자를 생성한다.

sudo useradd -m <user_name>
sudo passwd <user_name>
sudo usermod -aG wheel <user_name>

각 명령어의 의미는 다음과 같다.

useradd -m <user_name> : <user_name> 사용자를 생성하고 홈 디렉터리도 함께 만든다.
passwd <user_name> : <user_name> 사용자의 비밀번호를 설정한다.
usermod -aG wheel <user_name> : <user_name> 사용자를 wheel 그룹에 추가한다.

wheel 그룹

RHEL 계열에서는 보통 wheel 그룹 사용자에게 sudo 권한을 부여하므로, 이후 <user_name> 계정으로 로그인하더라도 필요할 때 관리자 권한 명령을 실행할 수 있다.

2. SSH 서버 설치 및 실행

VM 내부에 SSH 서버를 설치하고 바로 실행한다.

sudo dnf install -y openssh-server
sudo systemctl enable --now sshd
sudo systemctl status sshd

dnf install -y openssh-server : SSH 서버 패키지 설치
systemctl enable --now sshd : 부팅 시 자동 시작 + 지금 바로 실행
systemctl status sshd : 서비스 상태 확인

sshd가 active (running) 상태로 보이면 정상적으로 실행된 것이다.

3. 방화벽 상태 확인

sudo systemctl status firewalld
sudo firewall-cmd --permanent --add-service=ssh

ssh 서비스가 이미 허용되어 있어서 already enabled가 출력되었다.

4. VM IP 주소 확인

SSH로 접속하려면 VM의 IP 주소가 필요하다. 아래 명령어로 현재 IP를 확인한다.

ip addr

출력 결과에서 네트워크 인터페이스에 붙은 inet 주소를 확인하면 된다.
이 IP가 나중에 iTerm에서 접속할 때 사용할 주소이다.

5. iTerm에서 SSH 접속

이제 macOS에서 iTerm을 열고 아래처럼 접속한다.

ssh <user_name>@<vm_ip>

처음 접속할 때는 fingerprint 확인 메시지가 뜰 수 있는데, yes를 입력하면 된다.
이후 비밀번호를 입력하면 VM의 RHEL 환경에 SSH로 접속된다.

접속 성공!

이후 접속 방법

UTM에서 VM 실행
VM이 부팅될 때까지 기다리기
- 로그인 화면이나 셸 프롬프트가 뜰 때까지 기다린다.
- sudo systemctl enable --now sshd를 실행해두었다면, 부팅 시 sshd도 자동으로 함께 시작된다.
UTM 콘솔에서 상태 확인
```
systemctl status sshd  
ip addr
```
- sshd가 active (running) 인지 확인
- 현재 VM IP가 무엇인지 확인
iTerm에서 접속
```
ssh <user_name>@<vm_ip>
```

명령어 정리

VM 내부에서 실행한 명령어

sudo useradd -m <user_name>
sudo passwd <user_name>
sudo usermod -aG wheel <user_name>

sudo dnf install -y openssh-server
sudo systemctl enable --now sshd
sudo systemctl status sshd

sudo systemctl status firewalld
sudo firewall-cmd --permanent --add-service=ssh

ip addr

iTerm에서 실행한 명령어

ssh <user_name>@<vm_ip>

Red Hat Enterprise Linux 10.0 Minimal 설치하기

Fri, 20 Mar 2026 00:00:00 GMT

엔터프라이즈 환경의 리눅스를 실습해보고 싶어서, UTM을 이용해 RHEL 10 가상머신을 설치했다.

이번 글에서는 아래 순서로 설치 과정을 정리한다.

0. 설치 환경

MacBook pro M5 (10 코어, 24GB 메모리, 512GB 스토리지)
UTM
RHEL 10 (rhel-10.0-aarch64-dvd.iso)

1. 환경 세팅

1) UTM 설치

먼저 UTM 다운로드 페이지에서 UTM을 설치한다.

UTM은 macOS에서 다른 운영체제를 손쉽게 설치하고 실행할 수 있도록 도와주는 가상머신 도구이다.

2) RHEL 이미지 다운로드

RHEL 이미지는 Red Hat Developers에 가입한 뒤 공식 다운로드 페이지에서 받을 수 있다.

아래 이미지를 다운받았다.

rhel-10.0-aarch64-dvd.iso

M 시리즈 맥에서는 aarch64 이미지를 선택해야 한다.

3) UTM에서 VM 생성

UTM을 실행한 뒤 아래 순서대로 가상머신을 만든다.

Create a New Virtual Machine → Virtualize → Linux

옵션은 다음과 같이 설정했다.

Memory

4096 MiB
Enable display output 체크
Enable hardware OpenGL acceleration 체크 해제

Linux

Use Apple Virtualization 체크 해제
Boot from ISO image 선택
Boot ISO Image에 다운로드한 rhel-10.0-aarch64-dvd.iso 선택

Storage

64 GiB

Shared Directory

Share is read only 체크 해제

Summary

Save

가볍게 실습할 목적이라 4GB 메모리, 64GB 스토리지로 설정했다.

기본적인 VM 생성이 끝났다.

2. RHEL 설치 및 초기 설정

설치 과정은 잘 정리된 블로그를 참고하여 진행했다.

1) 설치 시작

부팅 후 설치 메뉴가 뜨면 다음 항목으로 들어간다.

Install Red Hat Enterprise Linux 10.0

2) Software Selection

Minimal Install 선택

필요한 것만 직접 추가하면서 환경을 구성해보기 위해 Minimal Install을 선택했다.

3) Installation Destination

Storage Configuration에서 Custom 선택

파티션 구성을 직접 확인해보기 위해 Custom으로 진행했다.

4) Manual Partitioning

New mount points will use the following partitioning scheme
→ Standard Partition 선택
Click here to create them automatically 클릭
기본값 그대로 두고 Done

5) Network & Host Name

Configure 클릭
General 탭
- Connect automatically with priority 값은 -999 유지
- 자동 연결 체크 유지
IPv4 Settings
- DHCP 유지

별도로 고정 IP를 지정해야 하는 환경이 아니라면 기본 DHCP 설정으로 충분하다.

6) Root Account

Enable root account 체크
root 비밀번호 지정

학습용 환경이라 root 계정을 바로 활성화해두었다. 실제 운영 환경이라면 root 직접 사용보다 일반 사용자 + sudo 방식이 더 권장된다.

7) 설치 완료 및 재부팅

설치 완료 후 Reboot System 선택

설치에는 약 1분 정도 소요되었다.

8) 설치 성공!

위처럼 터미널 창이 나오면 설치가 제대로 된 것이다. 로그인을 진행하면 된다.

2*. 트러블슈팅

1) display output is not active

처음에는 display output 설정이 잘못된 줄 알고 UTM 설정을 여러 번 수정했다.
그런데 실제로는 오류가 아니라, 몇 초 기다리면 정상적으로 설치 화면이 나타났다.

display output is not active 문구가 보이면 기다리면 된다!

2) 재부팅 후 다시 설치 화면이 뜨는 문제

설치가 끝난 뒤 재부팅했는데, 다시 RHEL 설치 화면으로 들어가는 문제가 있었다.

이 문제의 원인은 UTM이 계속 ISO 파일로 부팅하고 있기 때문이다.

UTM에서는 설치용 ISO가 removable drive처럼 연결된 상태로 남아 있다.
따라서 설치가 끝난 뒤에도 VM이 가상 디스크가 아니라 설치용 ISO를 다시 먼저 읽어서, installer 화면으로 돌아가게 된다.

해결 방법

사이드바에서 해당 VM 우클릭
Edit → Drives → USB Drive
Path에 연결된 ISO 경로를 Clear
Save

3. 구독 등록

RHEL은 패키지 설치와 업데이트를 위해 Red Hat 계정 구독 등록이 필요하다.

터미널에서 아래 명령어를 실행해서 계정 정보를 입력하면 된다.

subscription-manager register

RHEL 10.0 환경에서는 위 명령어만으로 별도 추가 설정 없이 등록이 완료되었다.

이후에는 아래 명령어로 시스템 정보와 구독 상태를 확인하고, 패키지를 업데이트했다.

# 시스템 정보 확인
cat /etc/redhat-release

# 구독 상태 확인
subscription-manager status

# 패키지 메타데이터 갱신 및 업데이트
dnf check-update  
sudo dnf update -y

RSS Feed of jiu's blog

Bash Script: 운영 자동화 실습

운영 자동화 실습

서비스 헬스체크 + 최근 journal 저장

안전하게 스크립트 작성하기

1. 테스트 환경에서 먼저 실행하기

2. 절대 경로 사용하기

3. 삭제 명령(rm) 주의하기

4. root 권한 스크립트 주의하기

Bash Script: 조건문, 반복문, 함수

조건문

기본 구조

비교식/검사식

1. 파일 존재 여부

2. 문자열 비교

3. 숫자 비교

반복문

for

while

운영에서 자주 쓰이는 반복문 예시

여러 파일 처리

여러 프로세스 이름 검사

여러 로그에 대한 반복 작업

함수

기본 구조

예시

반복되는 작업을 함수로 분리하기

명령어 치환

운영 자동화에서 자주 쓰이는 요소

변수화

조건 검사 후 실행

실패 시 종료

로그 남기기

실행 결과 확인

Bash Script: 표준입출력과 리다이렉션, 파이프

표준 입출력

표준 입력(stdin)

표준 출력(stdout)

표준 에러(stderr)

파일 디스크립터

리다이렉션

출력 리다이렉션

>

>>

입력 리다이렉션

<

here document

파이프

자주 사용하는 명령 연결 패턴

연결에 자주 쓰이는 명령어

로그 검색

프로세스 필터링

파일 내용 가공

표준 에러 분리

stderr와 stdout 분리가 필요한 이유

에러 출력 분리하기

표준 출력과 표준 에러를 각각 분리하기

표준 출력과 표준 에러를 같은 파일에 저장하기

출력 없이 실행만 하기

stderr만 따로 남기기

Bash Script: 기본 문법과 실행 구조

Shell과 Bash

Shell

헷갈리기 쉬운 용어

Bash

Bash Script

Bash Script의 기본 구조와 실행

기본 구조

Shebang

실행 방식

1. bash script.sh

2. ./script.sh

실행 예시

Bash Script의 실행 흐름

명령어 실행과 순차 처리

종료 코드 (Exit Code)

$?로 결과 확인하기

예시

변수와 문자열

일반 변수

3. 삭제 명령(`rm`) 주의하기

`for`

`while`

`>`

`>>`

`<`

1. `bash script.sh`

2. `./script.sh`

`$?`로 결과 확인하기

작은따옴표 `' '`

큰따옴표 `" "`

자주 보는 환경 변수: `PATH`, `HOME`, `USER`

`PATH`

`HOME`

`USER`

명령행 인자: `$0`, `$1`, `$2`, `$#`, `$@`