allluck777

[멋사 클라우드 5기] Day 37 & 38 - Linux (3)

allluck777 — Wed, 25 Mar 2026 09:07:28 +0900

Chapter 18. 환경변수 & 셸 설정

환경변수

환경변수(Environment Variable)는 운영체제가 프로세스에게 전달하는 이름=값 형태의 설정 정보이다. 프로세스는 환경변수를 통해 자신이 실행되는 환경에 대한 정보를 얻는다.

환경변수는 리눅스뿐만 아니라 모든 운영체제에 존재하는 개념이며, 애플리케이션 설정을 코드와 분리하는 핵심 메커니즘이다.

셸 변수 vs 환경변수

이 둘은 자주 혼동되지만 범위가 다르다:

셸 변수: 현재 셸 안에서만 유효하다. 자식 프로세스에 전달되지 않는다.
환경변수: export로 내보내면 자식 프로세스에도 상속된다.

# 셸 변수 (현재 셸에서만 유효)
MY_VAR="hello"
echo $MY_VAR           # hello
bash -c 'echo $MY_VAR' # (빈 출력 — 자식 셸에 전달되지 않음)

# 환경변수 (자식 프로세스에도 전달)
export MY_VAR="hello"
echo $MY_VAR           # hello
bash -c 'echo $MY_VAR' # hello (자식 셸에서도 접근 가능)

환경변수 확인 및 설정

# 모든 환경변수 출력
env
printenv

# 특정 환경변수 확인
echo $HOME
echo $PATH
echo $USER
printenv HOME

# 현재 셸의 모든 변수 (환경변수 + 셸 변수 + 함수)
set

설정 및 해제

# 환경변수 설정 (현재 셸 + 자식 프로세스)
export DB_HOST="localhost"
export DB_PORT=5432

# 한 줄로 설정과 export 동시에
export APP_ENV="production"

# 변수 해제 (삭제)
unset DB_HOST

# 특정 명령어에만 일시적으로 환경변수 설정 ★
DB_HOST=remotedb APP_ENV=staging ./myapp
# myapp은 DB_HOST=remotedb로 실행되지만, 현재 셸에는 영향 없음

주요 시스템 환경변수

변수	설명	예시
`HOME`	현재 사용자의 홈 디렉터리	`/home/devops`
`USER`	현재 사용자 이름	`devops`
`SHELL`	현재 사용자의 기본 셸	`/bin/bash`
`PATH`	실행 파일 검색 경로	`/usr/local/bin:/usr/bin:/bin`
`PWD`	현재 작업 디렉터리	`/home/devops/projects`
`LANG`	시스템 로캘(언어) 설정	`en_US.UTF-8`
`TERM`	터미널 종류	`xterm-256color`
`EDITOR`	기본 텍스트 편집기	`vim`
`HOSTNAME`	호스트명	`web-server-01`
`UID`	현재 사용자 ID	`1000`

`PATH` — 가장 중요한 환경변수

PATH는 셸이 명령어를 찾을 때 검색하는 디렉터리 목록이다.
:으로 구분된 디렉터리 경로의 나열이며, 왼쪽부터 순서대로 검색한다.

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# ls를 실행하면 셸이 다음 순서로 검색:
# 1. /usr/local/sbin/ls → 없음
# 2. /usr/local/bin/ls → 없음
# 3. /usr/sbin/ls → 없음
# 4. /usr/bin/ls → 있음! → 실행

PATH에 경로 추가

# PATH 끝에 추가 (기존 PATH 뒤에)
export PATH="$PATH:/opt/myapp/bin"

# PATH 앞에 추가 (우선순위 높게)
export PATH="/opt/myapp/bin:$PATH"

앞에 추가 vs 뒤에 추가:

앞에 추가하면 시스템 기본 명령어보다 우선 실행된다
뒤에 추가하면 시스템 기본 명령어를 그대로 사용하되, 새 경로는 보조로 사용된다
보안상 일반적으로 뒤에 추가하는 것이 안전하다

"command not found" 문제 해결

# 1. 명령어가 어디에 있는지 확인
which python3
type python3

# 2. 명령어가 설치되어 있는지 확인
find / -name "python3" -type f 2>/dev/null

# 3. 찾은 경로가 PATH에 있는지 확인
echo $PATH | tr ':' '\n' | grep "/usr/local/bin"

# 4. 없으면 PATH에 추가
export PATH="$PATH:/found/path"

히스토리 관리

bash는 실행한 명령어를 ~/.bash_history 파일에 저장한다.

# 히스토리 확인
history
history 20          # 최근 20개

# 히스토리에서 검색
history | grep "docker"

# 이전 명령어 재실행
!!                  # 직전 명령어 재실행
!123                # 히스토리 번호 123 재실행
!docker             # "docker"로 시작하는 가장 최근 명령어 재실행

# 역방향 검색 (가장 유용!) ★★★
# Ctrl + R → 검색어 입력 → 매치되면 Enter로 실행
# Ctrl + R을 반복 누르면 이전 매치로 이동

보안: 히스토리에 민감한 정보 남기지 않기

# 방법 1: 명령어 앞에 공백을 넣으면 히스토리에 기록되지 않음 (HISTCONTROL=ignorespace 필요)
 export DB_PASSWORD="secret123"     # 맨 앞에 공백

# 방법 2: 환경변수 파일에서 읽기
source /etc/myapp/env              # 파일에서 로드

# 방법 3: 현재 세션의 히스토리 삭제
history -c && history -w

Chapter 19. 사용자 & 그룹 관리

리눅스의 사용자 체계

사용자는 크게 세 가지로 분류된다

종류	UID 범위	설명
root	0	시스템 최고 관리자. 모든 권한을 가진다.
시스템 사용자	1~999	서비스(데몬)를 실행하기 위한 계정. 직접 로그인하지 않는다. nginx, mysql, www-data 등.
일반 사용자	1000~	사람이 로그인하여 사용하는 계정.

UID(User ID) 범위는 배포판마다 약간 다를 수 있지만, 1000부터 일반 사용자가 시작되는 것은 대부분 공통이다.

사용자 정보가 저장되는 파일

/etc/passwd — 사용자 계정 정보

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
devops:x:1000:1000:DevOps User:/home/devops:/bin/bash
nginx:x:33:33:nginx,,,:/nonexistent:/usr/sbin/nologin

devops : x : 1000 : 1000 : DevOps User : /home/devops : /bin/bash
  │      │    │      │         │              │             │
  │      │    │      │         │              │             └─ 로그인 셸
  │      │    │      │         │              └─ 홈 디렉터리
  │      │    │      │         └─ 코멘트 (이름, 설명)
  │      │    │      └─ GID (기본 그룹 ID)
  │      │    └─ UID (사용자 ID)
  │      └─ 비밀번호 (x = /etc/shadow에 저장)
  └─ 사용자명

/etc/shadow — 비밀번호 해시 (root만 읽기 가능)

$ sudo cat /etc/shadow
devops:$6$rounds=656000$salt...$hash...:19400:0:99999:7:::

필드	의미
1	사용자명
2	비밀번호 해시 (`!` 또는 `*`면 로그인 불가)
3	마지막 비밀번호 변경일 (1970-01-01부터의 일수)
4	최소 변경 간격 (일)
5	최대 유효 기간 (일)
6	만료 경고 기간 (일)
7	비활성화 기간 (일)
8	계정 만료일

/etc/group — 그룹 정보

$ cat /etc/group
devteam:x:1001:devops,deploy,alice
docker:x:999:devops

devteam : x : 1001 : devops,deploy,alice
   │      │    │          │
   │      │    │          └─ 그룹 멤버 목록
   │      │    └─ GID (그룹 ID)
   │      └─ 그룹 비밀번호 (거의 사용하지 않음)
   └─ 그룹명

사용자 관리 명령어

`useradd` — 사용자 생성

# 기본 사용자 생성
sudo useradd devops

# 실무에서 사용하는 전형적인 옵션 조합 ★
sudo useradd -m -s /bin/bash -c "DevOps Engineer" devops
#  -m : 홈 디렉터리 자동 생성 (/home/devops)
#  -s : 로그인 셸 지정
#  -c : 코멘트 (사용자 설명)

# 비밀번호 설정
sudo passwd devops

# 특정 UID/GID 지정
sudo useradd -m -u 1500 -g devteam -s /bin/bash deploy

# 시스템 사용자 생성 (서비스용, 로그인 불가)
sudo useradd -r -s /usr/sbin/nologin -d /nonexistent myservice
#  -r : 시스템 사용자 (UID < 1000)
#  -s /usr/sbin/nologin : 로그인 차단
#  -d /nonexistent : 홈 디렉터리 없음

# 사용자 생성 + sudo 그룹에 추가 (Ubuntu)
sudo useradd -m -s /bin/bash -G sudo newadmin
sudo passwd newadmin

useradd vs adduser:

useradd: 저수준 명령어. 옵션을 직접 지정해야 한다.
adduser: Debian/Ubuntu에서 제공하는 대화형 래퍼 스크립트. 비밀번호 설정, 홈 디렉터리 생성 등을 자동으로 처리한다.

`usermod` — 사용자 수정

# 사용자를 추가 그룹에 추가 ★★★
sudo usermod -aG docker devops
#  -a : append (기존 그룹 유지하면서 추가)
#  -G : 보조 그룹 지정

# ⚠️ -a를 빼먹으면 기존 보조 그룹이 모두 제거된다!
sudo usermod -G docker devops    # 위험: docker만 남고 나머지 그룹 제거

# 로그인 셸 변경
sudo usermod -s /bin/zsh devops

# 사용자명 변경
sudo usermod -l newname oldname

# 홈 디렉터리 변경 (기존 파일도 이동)
sudo usermod -d /new/home -m devops

# 계정 잠금 / 해제
sudo usermod -L devops    # Lock (비밀번호 앞에 ! 추가)
sudo usermod -U devops    # Unlock

그룹 관리

모든 사용자는 기본 그룹(primary group)과 0개 이상의 보조 그룹(supplementary groups)을 가진다.

기본 그룹: 사용자가 파일을 생성할 때 적용되는 그룹. /etc/passwd의 GID 필드.
보조 그룹: 추가적인 권한을 부여하기 위한 그룹. /etc/group에 멤버로 등록.

# 현재 사용자의 그룹 정보 확인
id
# uid=1000(devops) gid=1000(devops) groups=1000(devops),27(sudo),999(docker)

# 특정 사용자의 그룹 확인
id deploy
groups deploy

그룹 관리 명령어

# 그룹 생성
sudo groupadd devteam
sudo groupadd -g 2000 devteam    # GID 지정

# 그룹에 사용자 추가 ★
sudo usermod -aG devteam devops
sudo usermod -aG devteam alice
sudo usermod -aG devteam deploy

# 그룹에서 사용자 제거
sudo gpasswd -d alice devteam

# 그룹 삭제
sudo groupdel devteam

# 그룹명 변경
sudo groupmod -n newname oldname

그룹 변경 즉시 적용

usermod -aG로 그룹을 추가해도 현재 세션에는 즉시 반영되지 않는다. 로그아웃/로그인을 해야 적용된다.

# 그룹 추가 후 확인
sudo usermod -aG docker devops
groups     # 아직 docker가 안 보일 수 있음

# 방법 1: 로그아웃 후 재로그인 (가장 확실)
# 방법 2: newgrp으로 임시 적용
newgrp docker
groups     # 이제 docker가 보임

그룹 활용

Docker 그룹

Docker를 sudo 없이 사용하려면 사용자를 docker 그룹에 추가해야 한다.

sudo usermod -aG docker devops
# 로그아웃 후 재로그인
docker ps    # sudo 없이 실행 가능

sudo 그룹

# Ubuntu: sudo 그룹에 추가
sudo usermod -aG sudo newadmin

# RHEL/Fedora: wheel 그룹에 추가
sudo usermod -aG wheel newadmin

서비스 전용 사용자 생성

애플리케이션은 전용 사용자로 실행하는 것이 보안 best practice이다.
root로 실행하면 취약점 발생 시 시스템 전체가 위험해진다.

# 서비스 전용 사용자 생성
sudo useradd -r -s /usr/sbin/nologin -d /opt/myapp -c "MyApp service" myapp

# 애플리케이션 디렉터리 소유자 설정
sudo chown -R myapp:myapp /opt/myapp

# systemd 서비스에서 해당 사용자로 실행
# [Service]
# User=myapp
# Group=myapp

사용자 전환

`su` — Switch User

# root로 전환 (root 비밀번호 필요)
su -

# 특정 사용자로 전환
su - deploy
# deploy 사용자의 비밀번호 입력

# 현재 환경 유지하면서 전환 (- 없이)
su deploy
# 환경변수, 작업 디렉터리가 변경되지 않음

# 명령어 하나만 다른 사용자로 실행
su - deploy -c "whoami"

su - vs su (하이픈의 차이):

su - (또는 su -l, su --login): 대상 사용자의 로그인 셸을 완전히 재현한다. 환경변수, HOME, PATH 등이 대상 사용자의 것으로 설정된다.
su (하이픈 없이): 사용자만 전환하고, 현재 환경을 유지한다. PATH가 원래 사용자의 것이라서 혼란이 생길 수 있다.

su -를 사용하는 것이 권장된다.

`sudo su -` vs `sudo -i`

# 둘 다 root 셸로 전환 (sudo 비밀번호 사용)
sudo su -
sudo -i

# 차이점은 미미하지만, sudo -i가 더 직접적이고 감사 로그에 더 잘 남는다

사용자 정보 확인 명령어

# 현재 사용자 확인
whoami
# devops

# 현재 로그인한 모든 사용자
who
# devops   pts/0    2025-03-23 10:00 (192.168.1.100)
# deploy   pts/1    2025-03-23 11:30 (192.168.1.101)

# 더 자세한 정보
w
# USER     TTY      FROM             LOGIN@   IDLE   WHAT
# devops   pts/0    192.168.1.100    10:00    0.00s  vim config.yaml
# deploy   pts/1    192.168.1.101    11:30    2:15   bash

# 사용자/그룹 ID 정보
id
id deploy

# 마지막 로그인 기록
last | head -20
last devops

# 마지막 로그인 실패 기록
sudo lastb | head -20

시나리오

새 팀원 온보딩

#!/bin/bash
USERNAME=$1
FULLNAME=$2

# 사용자 생성
sudo useradd -m -s /bin/bash -c "$FULLNAME" $USERNAME

# 임시 비밀번호 설정 + 다음 로그인 시 변경 강제
echo "${USERNAME}:TempPass123!" | sudo chpasswd
sudo chage -d 0 $USERNAME

# 필요한 그룹에 추가
sudo usermod -aG sudo $USERNAME
sudo usermod -aG docker $USERNAME
sudo usermod -aG devteam $USERNAME

# SSH 키 디렉터리 설정
sudo mkdir -p /home/$USERNAME/.ssh
sudo chmod 700 /home/$USERNAME/.ssh
sudo chown -R $USERNAME:$USERNAME /home/$USERNAME/.ssh

echo "User $USERNAME created successfully"

퇴사자 계정 처리

#!/bin/bash
USERNAME=$1

# 1. 계정 잠금
sudo usermod -L $USERNAME

# 2. 실행 중인 프로세스 종료
sudo pkill -u $USERNAME

# 3. crontab 제거
sudo crontab -r -u $USERNAME

# 4. 홈 디렉터리 백업
sudo tar -czf /backup/departed/${USERNAME}-$(date +%Y%m%d).tar.gz /home/$USERNAME

# 5. (확인 후) 계정 삭제
# sudo userdel -r $USERNAME

echo "Account $USERNAME has been locked and backed up"

Chapter 20. 패키지 관리

패키지 관리

패키지(Package)란 소프트웨어를 설치하기 위해 필요한 파일들(바이너리, 라이브러리, 설정 파일, 문서 등)을 하나로 묶은 것이다. 패키지 매니저는 이 패키지를 설치, 업데이트, 삭제하는 도구이다.

패키지 매니저가 없다면 소프트웨어를 설치할 때마다 소스 코드를 다운로드하고, 의존성 라이브러리를 직접 찾아 설치하고, 컴파일해야 한다. 패키지 매니저가 이 모든 과정을 자동화한다.

패키지 매니저의 역할

의존성 자동 해결: A 패키지가 B 라이브러리를 필요로 하면 B를 자동 설치
버전 관리: 패키지의 설치, 업그레이드, 다운그레이드
저장소 관리: 어디서 패키지를 다운로드할지
무결성 검증: 패키지의 서명을 확인하여 변조 방지

배포판별 패키지 시스템

배포판 계열	패키지 형식	저수준 도구	고수준 도구
Debian/Ubuntu	`.deb`	`dpkg`	`apt`
RHEL/Fedora	`.rpm`	`rpm`	`dnf` (이전: `yum`)
Alpine	`.apk`	—	`apk`

저수준 vs 고수준

저수준(dpkg, rpm): 개별 패키지 파일을 직접 처리. 의존성을 자동 해결하지 않는다.
고수준(apt, dnf): 저장소에서 패키지를 검색하고, 의존성을 자동으로 해결한다. 실무에서는 거의 항상 고수준 도구를 사용한다.

APT — Debian/Ubuntu 패키지 관리

패키지 목록 업데이트

# 저장소에서 최신 패키지 목록을 가져온다 (설치는 아님)
sudo apt update

apt update는 무엇을 하는가: /etc/apt/sources.list에 정의된 저장소 서버에 접속하여 "어떤 패키지가 어떤 버전으로 이용 가능한지" 목록을 다운로드한다. 패키지를 설치/업그레이드하기 전에 반드시 먼저 실행해야 한다.

패키지 설치/삭제/업그레이드

# 패키지 설치
sudo apt install nginx
sudo apt install nginx curl vim     # 여러 패키지 동시

# 확인 없이 설치 (-y)
sudo apt install -y nginx

# 패키지 삭제 (설정 파일은 유지)
sudo apt remove nginx

# 패키지 + 설정 파일까지 완전 삭제
sudo apt purge nginx

# 패키지 재설치
sudo apt reinstall nginx

# 모든 패키지 업그레이드
sudo apt update && sudo apt upgrade -y

# 의존성 변경이 필요한 업그레이드까지 포함 (커널 등)
sudo apt full-upgrade

# 불필요한 의존성 패키지 자동 제거
sudo apt autoremove

패키지 검색 및 정보 확인

# 패키지 검색
apt search nginx
apt search "web server"

# 패키지 상세 정보
apt show nginx

# 설치된 패키지 목록
apt list --installed
apt list --installed | grep nginx

# 업그레이드 가능한 패키지 목록
apt list --upgradable

# 패키지가 설치한 파일 목록
dpkg -L nginx

# 특정 파일이 어느 패키지에 포함되어 있는지
dpkg -S /usr/sbin/nginx
# nginx-core: /usr/sbin/nginx

패키지 버전 고정 (Version Pinning)

자동 업그레이드로 인해 호환성이 깨지는 것을 방지하려면 특정 패키지의 버전을 고정할 수 있다.

APT (Debian/Ubuntu)

# 패키지 버전 고정 (hold)
sudo apt-mark hold nginx

# 고정 해제
sudo apt-mark unhold nginx

# 고정된 패키지 목록 확인
apt-mark showhold

# 특정 버전 설치
sudo apt install nginx=1.18.0-0ubuntu1

핵심 원칙

항상 고수준 도구(apt, dnf)를 우선 사용한다
apt install 전에 반드시 apt update를 먼저 실행한다
프로덕션 서버에서는 버전 고정을 고려한다
자동 보안 업데이트를 활성화한다
소스 설치는 최후의 수단으로만 사용한다

Chapter 21. 네트워킹

IP 주소

IP 주소는 네트워크에서 장치를 식별하는 주소이다.

IPv4: 192.168.1.100 — 32비트, 약 43억 개. 현재 주류.
IPv6: 2001:db8::1 — 128비트, 사실상 무한. 점진적 전환 중.
루프백(Loopback): 127.0.0.1 (localhost) — 자기 자신을 가리키는 특수 주소.
사설 IP: 내부 네트워크에서만 사용. 인터넷에서 직접 접근 불가.
- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
공인 IP: 인터넷에서 직접 접근 가능한 주소.

포트 (Port)

IP 주소가 건물 주소라면, 포트는 방 번호이다. 하나의 IP에서 여러 서비스를 구분하는 번호(0~65535)이다.

포트	서비스
22	SSH
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
8080	대체 HTTP (개발용)
27017	MongoDB

Well-known 포트 (0~1023): 시스템/표준 서비스용. 바인딩에 root 권한 필요.
등록된 포트 (1024~49151): 일반 애플리케이션용.
동적 포트 (49152~65535): 임시 연결에 자동 할당.

DNS (Domain Name System)

사람이 읽기 쉬운 도메인 이름(google.com)을 IP 주소(142.250.196.110)로 변환하는 시스템이다.

브라우저: "google.com에 접속하고 싶어"
    ↓ DNS 쿼리
DNS 서버: "google.com은 142.250.196.110이야"
    ↓
브라우저: 142.250.196.110에 연결

# DNS 설정 파일
cat /etc/resolv.conf
# nameserver 8.8.8.8
# nameserver 8.8.4.4

# 로컬 호스트 이름 매핑 (DNS보다 우선)
cat /etc/hosts
# 127.0.0.1   localhost
# 192.168.1.10 db-server
# 192.168.1.20 cache-server

TCP vs UDP

특성	TCP	UDP
연결 방식	연결 지향 (3-way handshake)	비연결
신뢰성	데이터 전달 보장, 순서 보장	보장 없음
속도	상대적으로 느림	빠름
용도	HTTP, SSH, DB 연결	DNS, 스트리밍, 게임

CIDR 표기법

192.168.1.0/24와 같은 표기를 CIDR(Classless Inter-Domain Routing)이라 한다. /24는 네트워크 부분의 비트 수이다.

192.168.1.0/24
→ 네트워크: 192.168.1.0
→ 호스트 범위: 192.168.1.1 ~ 192.168.1.254
→ 사용 가능 IP: 254개

10.0.0.0/16
→ 호스트 범위: 10.0.0.1 ~ 10.0.255.254
→ 사용 가능 IP: 65,534개

/32 → 단일 IP (호스트 1개)
/0  → 모든 IP

네트워크 인터페이스 확인

`ip` — 현대적 네트워크 도구

ifconfig는 더 이상 권장되지 않으며(deprecated), ip 명령어가 표준이다.

# 모든 인터페이스와 IP 주소 확인 ★★★
ip addr show
ip a          # 축약

# 특정 인터페이스만
ip addr show eth0

# 인터페이스 활성화/비활성화
sudo ip link set eth0 up
sudo ip link set eth0 down

# IP 주소 추가/삭제
sudo ip addr add 192.168.1.100/24 dev eth0
sudo ip addr del 192.168.1.100/24 dev eth0

# 라우팅 테이블 확인 ★
ip route show
ip r
# default via 10.0.0.1 dev eth0     ← 기본 게이트웨이
# 10.0.0.0/24 dev eth0 proto kernel  ← 로컬 네트워크

연결 진단 명령어

`ping` — 기본 연결 확인

# 호스트 연결 확인
ping google.com
ping 8.8.8.8

# 횟수 지정 (-c)
ping -c 4 google.com

# 타임아웃 지정 (-W: 초)
ping -c 1 -W 3 10.0.0.1

ping이 실패하면: 네트워크 자체가 끊어졌거나, 방화벽이 ICMP를 차단하고 있거나, DNS가 동작하지 않는 경우이다.

`curl` — HTTP 요청 테스트

웹 서비스의 응답을 확인하는 데 가장 많이 사용한다.

# 기본 GET 요청
curl http://localhost:8080

# 응답 헤더 포함 (-i)
curl -i http://localhost:8080

# 상태 코드만 확인 (-o /dev/null -s -w)
curl -o /dev/null -s -w "%{http_code}\n" http://localhost:8080
# 200

# 상세 연결 과정 확인 (-v: verbose) ★
curl -v https://example.com

# POST 요청
curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' http://localhost:8080/api

# 연결 타임아웃 설정
curl --connect-timeout 5 --max-time 10 http://example.com

# SSL 인증서 무시 (개발용)
curl -k https://self-signed.example.com

`dig` / `nslookup` — DNS 조회

# DNS 조회
dig google.com
dig google.com +short       # IP만 간결하게
# 142.250.196.110

# 특정 DNS 서버로 조회
dig @8.8.8.8 google.com

# 역방향 DNS (IP → 도메인)
dig -x 8.8.8.8

# 레코드 타입 지정
dig google.com MX           # 메일 서버
dig google.com NS           # 네임 서버
dig google.com CNAME        # 별칭
dig google.com TXT          # TXT 레코드

# nslookup (간단한 조회)
nslookup google.com
nslookup google.com 8.8.8.8

`traceroute` / `tracepath` — 경로 추적

패킷이 목적지까지 어떤 경로를 거치는지 추적한다.

# 경로 추적
traceroute google.com

# tracepath (traceroute 대안, 별도 설치 불필요한 경우 많음)
tracepath google.com

포트 & 연결 확인

`ss` — 소켓 통계

netstat의 현대적 대체 도구이다. 열린 포트, 연결 상태를 확인한다.

# 리스닝 중인 TCP 포트 확인 ★★★
ss -tlnp
#  -t: TCP
#  -l: LISTEN 상태만
#  -n: 포트 번호를 숫자로 표시 (이름 변환 안 함)
#  -p: 프로세스 정보 표시

# State    Recv-Q Send-Q  Local Address:Port  Peer Address:Port  Process
# LISTEN   0      511     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=2345))
# LISTEN   0      128     0.0.0.0:22          0.0.0.0:*          users:(("sshd",pid=1234))

# UDP 포트 확인
ss -ulnp

# 모든 TCP 연결 (LISTEN + ESTABLISHED + ...)
ss -tanp

# ESTABLISHED 연결만
ss -tanp state established

# 특정 포트로 필터링
ss -tlnp | grep :80
ss -tlnp sport = :443

`netstat` — 전통적 네트워크 통계

ss와 유사하지만, 일부 환경에서는 여전히 netstat이 기본 설치되어 있다.

# 설치 (없는 경우)
sudo apt install net-tools

# 리스닝 중인 TCP 포트
netstat -tlnp

# 모든 연결
netstat -tanp

파일 전송

`wget` — 파일 다운로드

# 파일 다운로드
wget https://example.com/file.tar.gz

# 다른 이름으로 저장
wget -O output.tar.gz https://example.com/file.tar.gz

# 백그라운드 다운로드
wget -b https://example.com/large-file.iso

# 재시도 횟수
wget --tries=3 https://example.com/file.tar.gz

# 이어받기 (중단된 다운로드 재개)
wget -c https://example.com/large-file.iso

`curl` vs `wget`

기능	curl	wget
파일 다운로드	`curl -O url`	`wget url`
API 호출	✓ (기본 용도)	✗
HTTP 메서드 지원	GET, POST, PUT, DELETE...	GET만
재귀적 다운로드	✗	✓ (`wget -r`)
이어받기	`curl -C -`	`wget -c`

일반적으로: API 테스트는 curl, 파일 다운로드는 wget.

네트워크 트러블슈팅 체계

"서비스에 접속이 안 된다"는 보고가 왔을 때의 체계적 진단 순서:

# 1. 네트워크 인터페이스 확인 — IP가 할당되어 있는가?
ip addr show

# 2. 기본 게이트웨이 확인
ip route show

# 3. 외부 연결 확인 — 인터넷에 나갈 수 있는가?
ping -c 2 8.8.8.8

# 4. DNS 확인 — 도메인이 해석되는가?
dig example.com +short
# 실패하면: /etc/resolv.conf 확인, DNS 서버 변경

# 5. 특정 호스트+포트 연결 확인
curl -v http://target-host:8080
# 또는
ss -tlnp | grep :8080    # (대상 서버에서) 서비스가 리스닝 중인가?

# 6. 방화벽 확인
sudo ufw status           # 또는 firewall-cmd --list-all
# 클라우드: 보안 그룹 규칙 확인

# 7. 서비스 상태 확인
systemctl status nginx
journalctl -u nginx -n 20

요약

명령어	용도	가장 많이 쓰는 형태
`ip addr`	IP/인터페이스 확인	`ip a`
`ip route`	라우팅 테이블	`ip r`
`ping`	기본 연결 확인	`ping -c 4 host`
`curl`	HTTP 요청/API 테스트	`curl -v`, `curl -s -o /dev/null -w "%{http_code}"`
`dig`	DNS 조회	`dig domain +short`
`ss`	포트/연결 확인	`ss -tlnp`
`traceroute`	경로 추적
`wget`	파일 다운로드	`wget -O file url`

Chapter 22. SSH & 원격 접속

SSH

SSH(Secure Shell)는 네트워크를 통해 다른 컴퓨터에 안전하게 접속하기 위한 프로토콜이다. 모든 통신이 암호화되므로, 비밀번호나 명령어가 네트워크에서 평문으로 노출되지 않는다.

SSH 이전에는 telnet, rsh 같은 프로토콜을 사용했는데, 이들은 데이터를 암호화하지 않아서 도청에 취약했다. SSH는 이 문제를 완전히 해결했으며, 현재 서버 원격 접속의 사실상 유일한 표준이다.

SSH의 용도

원격 서버에 로그인하여 명령어 실행
서버 간 파일 전송 (scp, sftp, rsync)
포트 포워딩 (터널링)
Git 원격 저장소 접근
자동화 스크립트에서 원격 명령어 실행

SSH의 동작 방식

SSH 연결은 두 단계로 이루어진다:

① 서버 인증: 클라이언트가 "이 서버가 진짜 내가 접속하려는 서버인가"를 확인한다. 서버의 공개 키(host key)를 이전에 저장해둔 것(~/.ssh/known_hosts)과 비교한다.

② 사용자 인증: 서버가 "이 사용자가 접속 권한이 있는가"를 확인한다. 비밀번호 또는 키 기반 인증을 사용한다.

키 기반 인증 (Key-Based Authentication)

비밀번호 인증의 문제점:

무차별 대입 공격에 취약
여러 서버에 비밀번호를 기억하기 어려움
자동화 스크립트에 비밀번호를 하드코딩하면 보안 위험

키 기반 인증은:

수학적으로 매우 강력한 보안 (2048/4096비트 RSA, Ed25519)
비밀번호 없이 자동화 가능
AWS, GCP, Azure 등 클라우드 서비스의 기본 인증 방식

공개 키 / 개인 키

SSH 키는 한 쌍(pair)으로 생성된다:

개인 키(Private Key): 자신만 가지고 있는 비밀 키. 절대 공유하면 안 된다. ~/.ssh/id_rsa 또는 ~/.ssh/id_ed25519
공개 키(Public Key): 서버에 등록하는 키. 공유해도 안전하다. ~/.ssh/id_rsa.pub 또는 ~/.ssh/id_ed25519.pub

인증 흐름:
1. 사용자가 서버에 접속 시도
2. 서버가 랜덤 챌린지를 보냄
3. 클라이언트가 개인 키로 챌린지에 서명하여 응답
4. 서버가 등록된 공개 키로 서명을 검증
5. 검증 성공 → 접속 허용

비유하자면: 공개 키는 자물쇠, 개인 키는 열쇠이다. 자물쇠(공개 키)는 서버에 설치하고, 열쇠(개인 키)는 자기만 가지고 다닌다.

SSH 키 생성

# Ed25519 키 생성 (현재 추천되는 알고리즘) ★★★
ssh-keygen -t ed25519 -C "devops@example.com"
# -t: 알고리즘 타입
# -C: 코멘트 (보통 이메일, 식별용)

# 실행하면 다음을 물어본다:
# 1. 키 저장 경로 (기본: ~/.ssh/id_ed25519) → Enter
# 2. 패스프레이즈(비밀번호) → 보안을 위해 설정 권장, 자동화 시 빈 값

# RSA 키 생성 (레거시 시스템 호환 필요 시)
ssh-keygen -t rsa -b 4096 -C "devops@example.com"
# -b 4096: 키 길이 (최소 2048, 4096 권장)

# 결과:
# ~/.ssh/id_ed25519       ← 개인 키 (절대 유출 금지)
# ~/.ssh/id_ed25519.pub   ← 공개 키 (서버에 등록)

서버에 공개 키 등록

# 방법 1: ssh-copy-id (가장 간편) ★
ssh-copy-id user@remote-server
# 비밀번호를 한 번 입력하면 공개 키가 서버의 ~/.ssh/authorized_keys에 추가된다

# 방법 2: 수동 등록
cat ~/.ssh/id_ed25519.pub | ssh user@remote-server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# 방법 3: 클라우드 (AWS EC2)
# 인스턴스 생성 시 키 페어를 지정하면 자동으로 등록된다
# 또는 EC2 Instance Connect, Session Manager 사용

키 파일 권한 (필수!)

SSH는 키 파일의 권한이 너무 열려있으면 접속을 거부한다.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/id_ed25519         # 개인 키
chmod 644 ~/.ssh/id_ed25519.pub     # 공개 키
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/config

SSH 접속

# 기본 접속
ssh user@hostname
ssh user@192.168.1.100

# 포트 지정 (기본: 22)
ssh -p 2222 user@hostname

# 특정 키 파일 지정
ssh -i ~/.ssh/my-key.pem ubuntu@ec2-xx-xx-xx-xx.compute-1.amazonaws.com

# 원격 서버에서 명령어 하나만 실행하고 종료
ssh user@server "uptime"
ssh user@server "df -h && free -h"

첫 접속 시 fingerprint 확인

처음 접속하는 서버에는 다음 메시지가 뜬다:

The authenticity of host 'server (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

yes를 입력하면 서버의 공개 키가 ~/.ssh/known_hosts에 저장된다. 이후 접속 시에는 이 키를 비교하여 서버 위조(중간자 공격)를 방지한다.

SSH 설정 파일 (`~/.ssh/config`)

여러 서버에 접속할 때 매번 긴 명령어를 입력하는 대신, 설정 파일에 별칭을 등록할 수 있다.

# ~/.ssh/config
Host web-prod
    HostName 10.0.1.100
    User deploy
    Port 22
    IdentityFile ~/.ssh/prod-key.pem

Host web-staging
    HostName 10.0.2.100
    User deploy
    IdentityFile ~/.ssh/staging-key.pem

Host db-prod
    HostName 10.0.1.200
    User admin
    IdentityFile ~/.ssh/prod-key.pem

# 패턴 매칭 — 모든 호스트에 적용
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    AddKeysToAgent yes

# 설정 후에는 별칭으로 간단히 접속
ssh web-prod       # ssh -i ~/.ssh/prod-key.pem deploy@10.0.1.100 과 동일
ssh web-staging
ssh db-prod

파일 전송

`scp` — 파일 복사

Secure Copy의 약자이다. SSH를 통해 파일을 복사한다.

# 로컬 → 원격
scp file.txt user@server:/home/user/

# 원격 → 로컬
scp user@server:/var/log/app.log ./

# 디렉터리 복사 (-r)
scp -r ./project/ user@server:/opt/

# 특정 포트
scp -P 2222 file.txt user@server:/tmp/

# SSH 설정 파일의 별칭 사용
scp file.txt web-prod:/opt/deploy/

Chapter 23. 셸 스크립트 기초

셸 스크립트

셸 스크립트(Shell Script)는 셸 명령어들을 파일에 순서대로 작성하여 자동으로 실행되게 하는 프로그램이다. 지금까지 배운 모든 명령어(grep, awk, find, systemctl 등)를 조합하여 복잡한 작업을 자동화할 수 있다.

셸 스크립트는 다음과 같은 곳에 사용된다:

서버 초기 설정 자동화
배포(deploy) 스크립트
백업 스크립트
모니터링 / 헬스체크
CI/CD 파이프라인의 빌드/테스트 단계
크론 작업

첫 번째 스크립트

#!/bin/bash
# 첫 번째 셸 스크립트

echo "Hello, DevOps!"
echo "Current user: $(whoami)"
echo "Date: $(date)"
echo "Hostname: $(hostname)"

# 실행 권한 부여
chmod +x hello.sh

# 실행
./hello.sh

Shebang (`#!`)

스크립트 첫 줄의 #!/bin/bash를 Shebang(셔뱅)이라고 한다. 이 스크립트를 어떤 인터프리터로 실행할지 지정한다.

#!/bin/bash         # bash로 실행
#!/bin/sh           # POSIX sh로 실행 (더 이식성이 높음)
#!/usr/bin/env bash # PATH에서 bash를 찾아 실행 (이식성 좋음)
#!/usr/bin/python3  # Python 스크립트도 가능

#!/bin/bash vs #!/bin/sh: bash는 sh의 상위 호환이지만, bash 전용 기능(배열, [[ ]] 등)은 sh에서 동작하지 않는다. 이식성이 중요하면 #!/bin/sh, bash 기능이 필요하면 #!/bin/bash를 사용한다.

변수

변수 선언과 사용

#!/bin/bash

# 변수 선언 (= 양옆에 공백 금지!)
NAME="DevOps"
PORT=8080
LOG_DIR="/var/log/myapp"

# 변수 사용 ($변수명 또는 ${변수명})
echo "Hello, $NAME"
echo "Server running on port ${PORT}"

# 중괄호가 필요한 경우 — 변수명 뒤에 문자가 붙을 때
FILE="${NAME}_config.yaml"    # DevOps_config.yaml
# $NAME_config로 쓰면 NAME_config라는 변수를 찾게 된다

특수 변수

변수	의미
`$0`	스크립트 이름
`$1`, `$2`...	1번째, 2번째... 인자(argument)
`$#`	인자의 개수
`$@`	모든 인자 (개별 문자열로)
`$*`	모든 인자 (하나의 문자열로)
`$?`	직전 명령어의 종료 코드 ★
`$$`	현재 스크립트의 PID
`$!`	마지막 백그라운드 프로세스의 PID

#!/bin/bash
echo "Script: $0"
echo "First arg: $1"
echo "Second arg: $2"
echo "Total args: $#"
echo "All args: $@"

./script.sh hello world
# Script: ./script.sh
# First arg: hello
# Second arg: world
# Total args: 2
# All args: hello world

종료 코드 (Exit Code)

모든 명령어는 종료 시 종료 코드(exit code)를 반환한다. 0은 성공, 0이 아닌 값은 실패이다.

# 종료 코드 확인
ls /etc/passwd
echo $?    # 0 (성공)

ls /nonexistent
echo $?    # 2 (실패 — 파일 없음)

# 스크립트에서 종료 코드 지정
exit 0     # 성공
exit 1     # 실패

명령어 치환 (Command Substitution)

명령어의 출력 결과를 변수에 저장한다.

# $( ) 형태 (추천)
CURRENT_DATE=$(date +%Y%m%d)
FILE_COUNT=$(find /var/log -name "*.log" | wc -l)
MY_IP=$(hostname -I | awk '{print $1}')

# 백틱 형태 (레거시, 중첩 시 불편)
CURRENT_DATE=`date +%Y%m%d`

echo "Date: $CURRENT_DATE"
echo "Log files: $FILE_COUNT"
echo "IP: $MY_IP"

조건문

`if` 문

#!/bin/bash

if [ condition ]; then
    # 조건이 참일 때
elif [ condition2 ]; then
    # 조건2가 참일 때
else
    # 모두 거짓일 때
fi

조건 표현식

파일 테스트:

표현식	의미
`-f file`	파일이 존재하고 일반 파일인가
`-d dir`	디렉터리가 존재하는가
`-e path`	경로가 존재하는가 (파일/디렉터리 무관)
`-r file`	읽기 가능한가
`-w file`	쓰기 가능한가
`-x file`	실행 가능한가
`-s file`	파일이 비어있지 않은가 (크기 > 0)

문자열 비교:

표현식	의미
`"$a" = "$b"`	같은가
`"$a" != "$b"`	다른가
`-z "$a"`	빈 문자열인가 (zero length)
`-n "$a"`	비어있지 않은가 (non-zero length)

숫자 비교:

표현식	의미
`$a -eq $b`	같은가 (equal)
`$a -ne $b`	다른가 (not equal)
`$a -gt $b`	큰가 (greater than)
`$a -lt $b`	작은가 (less than)
`$a -ge $b`	크거나 같은가
`$a -le $b`	작거나 같은가

예시

#!/bin/bash

# 파일 존재 확인
CONFIG="/etc/myapp/config.yaml"
if [ -f "$CONFIG" ]; then
    echo "Config found: $CONFIG"
else
    echo "ERROR: Config not found!"
    exit 1
fi

# 인자 확인
if [ $# -eq 0 ]; then
    echo "Usage: $0 <environment>"
    echo "  environments: dev, staging, prod"
    exit 1
fi

# 종료 코드로 성공/실패 판단
if systemctl is-active --quiet nginx; then
    echo "Nginx is running"
else
    echo "Nginx is NOT running"
    sudo systemctl start nginx
fi

# 디스크 사용률 체크
USAGE=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -gt 90 ]; then
    echo "WARNING: Disk usage is ${USAGE}%"
fi

`[[ ]]` vs `[ ]`

[[ ]]는 bash 전용 확장이며, [ ]보다 강력하다:

# [[ ]]의 장점:
# 1. 패턴 매칭
[[ "$string" == *.log ]]

# 2. 정규표현식
[[ "$string" =~ ^[0-9]+$ ]]

# 3. && / || 사용 가능
[[ -f "$file" && -r "$file" ]]

# [ ]에서는 -a / -o를 사용해야 한다 (비추천)
[ -f "$file" -a -r "$file" ]

추천: bash 스크립트(#!/bin/bash)에서는 [[ ]]를 사용한다.

반복문

`for` 문

# 리스트 순회
for server in web-01 web-02 web-03; do
    echo "Checking $server..."
    ssh "$server" "uptime"
done

# 범위 (Brace Expansion)
for i in {1..10}; do
    echo "Iteration $i"
done

# C 스타일
for ((i=0; i<5; i++)); do
    echo "Count: $i"
done

# 명령어 결과 순회
for file in /var/log/*.log; do
    echo "$(wc -l < "$file") lines in $file"
done

# 파일의 각 줄 처리
while IFS= read -r line; do
    echo "Processing: $line"
done < servers.txt

`while` 문

# 기본 while
count=0
while [ $count -lt 5 ]; do
    echo "Count: $count"
    ((count++))
done

# 서비스가 시작될 때까지 대기 ★
echo "Waiting for service to start..."
while ! curl -s http://localhost:8080/health > /dev/null 2>&1; do
    echo "  Not ready yet, retrying in 3s..."
    sleep 3
done
echo "Service is up!"

# 파일 읽기 (줄 단위)
while IFS= read -r line; do
    echo "$line"
done < /etc/hosts

`until` 문

while의 반대 — 조건이 참이 될 때까지 반복한다.

until systemctl is-active --quiet nginx; do
    echo "Nginx not running, starting..."
    sudo systemctl start nginx
    sleep 2
done
echo "Nginx is running"

함수

#!/bin/bash

# 함수 정의
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

check_service() {
    local service_name=$1    # local: 함수 내 지역 변수
    if systemctl is-active --quiet "$service_name"; then
        log "$service_name is running"
        return 0
    else
        log "ERROR: $service_name is not running"
        return 1
    fi
}

# 함수 호출
log "Starting health check"
check_service nginx
check_service postgresql

# 반환값 활용
if check_service redis; then
    log "Redis OK"
else
    log "Redis FAILED — attempting restart"
    sudo systemctl restart redis
fi

local 키워드: 함수 내에서 선언한 변수가 함수 밖에 영향을 주지 않게 한다. 사용하지 않으면 전역 변수가 되어 예기치 않은 버그가 발생할 수 있다.

에러 처리

`set` 옵션 — 안전한 스크립트의 시작

#!/bin/bash
set -euo pipefail

옵션	효과
`set -e`	명령어가 실패(종료 코드 ≠ 0)하면 스크립트 즉시 종료 ★
`set -u`	정의되지 않은 변수 사용 시 에러로 종료 ★
`set -o pipefail`	파이프라인에서 중간 명령어가 실패해도 감지

# set -e 없이: 에러가 발생해도 다음 줄이 실행된다 (위험!)
rm -rf /opt/myapp/
cp -r /tmp/deploy/* /opt/myapp/   # rm이 실패해도 실행됨

# set -e 있으면: rm이 실패하면 스크립트가 즉시 멈춘다 (안전!)

`trap` — 종료 시 정리 작업

#!/bin/bash
set -euo pipefail

# 스크립트 종료 시 (정상/비정상 모두) 실행할 정리 코드
cleanup() {
    echo "Cleaning up temporary files..."
    rm -rf "$TEMP_DIR"
}
trap cleanup EXIT

TEMP_DIR=$(mktemp -d)
echo "Working in $TEMP_DIR"

# 작업 수행 (에러 발생해도 cleanup이 자동 호출된다)
cp important_file.txt "$TEMP_DIR/"
# ... 추가 작업 ...

스크립트 예시

배포 스크립트

#!/bin/bash
set -euo pipefail

# --- 설정 ---
APP_NAME="myapp"
DEPLOY_DIR="/opt/${APP_NAME}"
RELEASE_DIR="${DEPLOY_DIR}/releases"
CURRENT_LINK="${DEPLOY_DIR}/current"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
NEW_RELEASE="${RELEASE_DIR}/${TIMESTAMP}"

log() { echo "[$(date '+%H:%M:%S')] $1"; }

# --- 인자 확인 ---
ARTIFACT=${1:?"Usage: $0 <artifact-path>"}
[ -f "$ARTIFACT" ] || { log "ERROR: $ARTIFACT not found"; exit 1; }

# --- 배포 ---
log "Starting deployment..."

mkdir -p "$NEW_RELEASE"
tar -xzf "$ARTIFACT" -C "$NEW_RELEASE"

log "Switching symlink..."
ln -sfn "$NEW_RELEASE" "$CURRENT_LINK"

log "Restarting service..."
sudo systemctl restart "$APP_NAME"

# 이전 릴리스 정리 (최근 5개만 유지)
ls -dt ${RELEASE_DIR}/*/ | tail -n +6 | xargs rm -rf

log "Deployment completed: $TIMESTAMP"

서버 헬스체크

#!/bin/bash
set -euo pipefail

ALERT_EMAIL="ops@example.com"
CHECKS_FAILED=0

check() {
    local name=$1
    local cmd=$2
    if eval "$cmd" > /dev/null 2>&1; then
        echo "  ✓ $name"
    else
        echo "  ✗ $name FAILED"
        ((CHECKS_FAILED++))
    fi
}

echo "=== Health Check: $(hostname) ==="
echo "Time: $(date)"
echo ""

# 서비스 체크
echo "[Services]"
check "Nginx" "systemctl is-active --quiet nginx"
check "PostgreSQL" "systemctl is-active --quiet postgresql"
check "Redis" "systemctl is-active --quiet redis"

# 리소스 체크
echo "[Resources]"
DISK=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
MEM=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
check "Disk < 90%" "[ $DISK -lt 90 ]"
check "Memory < 90%" "[ $MEM -lt 90 ]"

# 결과
echo ""
if [ $CHECKS_FAILED -gt 0 ]; then
    echo "RESULT: $CHECKS_FAILED check(s) FAILED"
    exit 1
else
    echo "RESULT: All checks passed"
    exit 0
fi

셸 스크립트 작성 모범 사례

항상 set -euo pipefail로 시작한다
변수는 항상 따옴표로 감싼다: "$VAR" (공백이 포함된 값 보호)
Shebang을 명시한다: #!/bin/bash
함수로 구조화한다: 재사용 가능하고 읽기 쉽다
에러 메시지는 stderr로: echo "ERROR" >&2
임시 파일은 mktemp으로 생성하고, trap으로 정리한다
하드코딩 대신 변수/인자를 사용한다
주석을 충분히 작성한다
복잡한 로직은 Python 등 다른 언어를 고려한다

[멋사 클라우드 5기] Day 35 & 36 - Linux (2)

allluck777 — Wed, 25 Mar 2026 09:06:47 +0900

Chapter 10. 텍스트 정렬, 집계 & 비교

grep, sed, awk

grep, sed, awk 는 단독으로도 유용하지만, 파이프(|)로 연결하여 데이터 분석 파이프라인을 구성할 때 더 많은 작업을 할 수 있다.

# 로그에서 IP별 접속 횟수 상위 10개
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

`sort` — 텍스트 정렬

sort는 입력을 줄 단위로 정렬한다. 기본은 알파벳(사전) 순서이다.

# 알파벳순 정렬
sort names.txt

# 역순 정렬 (-r: reverse)
sort -r names.txt

# 숫자순 정렬 (-n: numeric) ★
sort -n numbers.txt
# 숫자 정렬 없이 하면: 1, 10, 100, 2, 20 (문자열 비교)
# -n을 붙이면: 1, 2, 10, 20, 100 (숫자 비교)

# 사람이 읽기 쉬운 크기 단위로 정렬 (-h: human-numeric)
du -sh */ | sort -rh
# 2.1G, 500M, 128K 순서로 정렬

특정 필드 기준 정렬

# 특정 필드 기준으로 정렬 (-k: key, -t: delimiter)
# /etc/passwd를 UID(3번째 필드) 기준으로 숫자 정렬
sort -t: -k3 -n /etc/passwd

# CSV에서 3번째 열 기준 숫자 역순 정렬
sort -t',' -k3 -rn data.csv

# 여러 키로 정렬 (1차: 2번째 필드, 2차: 3번째 필드 숫자)
sort -t',' -k2,2 -k3,3n data.csv

유용한 옵션

# 중복 줄 제거하면서 정렬 (-u: unique)
sort -u names.txt

# 대소문자 무시 정렬 (-f: fold case)
sort -f mixed_case.txt

# 결과를 원본 파일에 덮어쓰기 (-o)
sort -n numbers.txt -o numbers.txt
# 주의: sort file > file 은 안된다 (파일이 비어버림). -o를 사용해야 안전

`uniq` — 중복 처리

uniq는 인접한 중복 줄을 처리한다. 핵심 주의사항: uniq는 연속된 중복만 감지하므로, 반드시 sort와 함께 사용해야 한다.

# 잘못된 사용 — 비연속 중복은 제거되지 않음
echo -e "a\nb\na" | uniq
# a
# b
# a    ← 여전히 남아있음

# 올바른 사용 — sort로 먼저 정렬
echo -e "a\nb\na" | sort | uniq
# a
# b

주요 옵션

# 중복 제거 (기본 동작)
sort data.txt | uniq

# 중복 횟수와 함께 출력 (-c: count) ★★★
sort data.txt | uniq -c
#       3 apple
#       1 banana
#       5 cherry

# 중복된 줄만 출력 (-d: duplicated)
sort data.txt | uniq -d

# 중복되지 않은 줄만 출력 (-u: unique)
sort data.txt | uniq -u

# 대소문자 무시 (-i)
sort data.txt | uniq -ci

핵심 패턴: `sort | uniq -c | sort -rn`

# 패턴 분해:
# sort         → 동일한 값을 인접하게 모음
# uniq -c      → 중복 횟수를 센다
# sort -rn     → 횟수 기준 내림차순 정렬

# 실무 예시: Nginx 로그에서 가장 많이 접속한 IP
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

# 실무 예시: 가장 많이 발생한 에러 메시지
grep "ERROR" app.log | awk -F'ERROR' '{print $2}' | sort | uniq -c | sort -rn | head -10

# 실무 예시: HTTP 상태 코드 분포
awk '{print $9}' access.log | sort | uniq -c | sort -rn
#   45231 200
#    3214 304
#     567 404
#      23 500

`wc` — 텍스트 통계

Word Count의 약자이다.

# 파이프와 조합 — 결과의 줄 수 세기
grep "ERROR" app.log | wc -l          # 에러 발생 횟수
ps aux | wc -l                         # 실행 중인 프로세스 수
find /tmp -type f | wc -l             # /tmp의 파일 수
docker ps | wc -l                      # 실행 중인 컨테이너 수 (+1 헤더)

# 여러 파일의 줄 수 비교
wc -l /var/log/*.log

`cut` — 필드 추출

`cut` vs `awk` — 언제 무엇을 쓰는가

상황	추천	이유
단순히 N번째 필드 추출	`cut`	더 간결하고 빠르다
구분자가 여러 공백일 때	`awk`	`cut`은 연속 공백을 하나로 처리하지 못한다
조건부 필드 추출	`awk`	조건 처리 기능이 있다
필드 계산이 필요할 때	`awk`	프로그래밍 기능

# cut: 구분자가 명확한 경우 (CSV, /etc/passwd 등)
cut -d: -f1,3 /etc/passwd

# awk: 공백으로 구분된 출력 (ps, df 등)
ps aux | awk '{print $1, $11}'      # 사용자, 명령어
df -h | awk 'NR>1 {print $5, $6}'  # 사용률, 마운트포인트

`tr` — 문자 변환 (보충)

# Windows 줄바꿈(\r\n)을 Unix 줄바꿈(\n)으로 변환
tr -d '\r' < windows_file.txt > unix_file.txt

# 여러 구분자를 통일
echo "a;b,c:d" | tr ';,:' '\t\t\t'
# a    b    c    d

# 알파벳 외 문자 모두 제거
echo "Hello, World! 123" | tr -cd 'a-zA-Z\n'
# HelloWorld

# 연속된 빈 줄을 하나로 압축
cat messy.txt | tr -s '\n'

`diff` — 파일 비교

두 파일의 차이점을 줄 단위로 비교하여 보여준다. 설정 파일 변경 전후 비교, 코드 리뷰, 패치 생성 등에 사용한다.

# 기본 비교
diff file1.txt file2.txt
# 3c3         ← 3번째 줄이 변경(changed)됨
# < old line  ← file1의 내용
# ---
# > new line  ← file2의 내용

# Unified 형식 (-u) ★★★ — 가장 읽기 쉬움 (git diff와 동일한 형식)
diff -u file1.txt file2.txt
# --- file1.txt
# +++ file2.txt
# @@ -1,5 +1,5 @@
#  unchanged line
# -deleted line
# +added line
#  unchanged line

Chapter 11. 파이프 & 리다이렉션

파이프와 리다이렉션은 UNIX 철학의 핵심인 "작은 도구를 조합하여 복잡한 작업을 수행한다"를 실현하는 메커니즘이다.

리다이렉션 (Redirection)

리다이렉션은 표준 스트림의 방향을 바꾸는 것이다. 기본적으로 stdout은 화면에 출력되고 stdin은 키보드에서 입력받지만, 이를 파일이나 다른 스트림으로 변경할 수 있다.

출력 리다이렉션 (`>`, `>>`)

# stdout을 파일로 저장 (덮어쓰기)
echo "Hello" > output.txt

# stdout을 파일에 추가 (append)
echo "World" >> output.txt

# 명령어 결과를 파일로 저장
ls -la /var/log > file_list.txt
df -h > disk_status.txt
ps aux > process_list.txt

> vs >> — 중요한 차이:

> : 파일이 이미 존재하면 내용을 완전히 덮어쓴다. 파일이 없으면 새로 생성한다.
>> : 파일이 이미 존재하면 기존 내용 뒤에 추가한다. 파일이 없으면 새로 생성한다.

# 파일 비우기 (truncate)
> /var/log/large_app.log    # 파일 내용을 0바이트로 만듦 (파일은 유지)
# 이것은 rm 후 재생성보다 안전하다. 파일을 열고 있는 프로세스에 영향이 적다.

에러 리다이렉션 (`2>`, `2>>`)

stderr(파일 디스크립터 2)를 별도로 제어할 수 있다.

# 에러만 파일로 저장
find / -name "*.conf" 2> errors.txt

# 에러를 버리기 (화면에 표시하지 않기) ★★★
find / -name "*.conf" 2>/dev/null

# 에러를 별도 파일에 추가
command 2>> error_log.txt

2.3 stdout과 stderr를 동시에 제어

# stdout은 파일로, stderr는 다른 파일로
command > output.txt 2> errors.txt

# stdout과 stderr를 같은 파일로 ★★★
command > all_output.txt 2>&1
# 해석: stdout(1)을 all_output.txt로 → stderr(2)를 stdout(1)이 가리키는 곳으로

# 위와 동일한 축약 문법 (bash 4.0+)
command &> all_output.txt

# stdout과 stderr를 모두 버리기 ★★★
command > /dev/null 2>&1
# 또는
command &> /dev/null

2>&1의 의미:

2> : stderr(fd 2)의 방향을 바꾼다
&1 : fd 1(stdout)이 현재 가리키고 있는 곳으로 보낸다
따라서 > file 2>&1은 "stdout을 file로 보내고, stderr도 같은 곳(file)으로 보내라"는 뜻이다

⚠️ 순서가 중요하다:

> file 2>&1 → ✓ 올바름 (stdout이 먼저 file로 향하고, stderr가 따라감)

2>&1 > file → ✗ 의도와 다름 (stderr가 원래 stdout=화면으로 향하고, stdout만 file로 감)

입력 리다이렉션 (`<`)

# 파일을 stdin으로 전달
sort < unsorted.txt

# 실무에서는 파이프가 더 흔하지만, 일부 명령어에서 사용
mysql -u root -p database < schema.sql    # SQL 파일 실행
wc -l < data.txt                           # 파일명 없이 줄 수만 출력

Here Document (`<<`)

여러 줄의 텍스트를 stdin으로 전달한다. 스크립트에서 파일을 생성하거나, 대화형 명령어에 입력을 전달할 때 사용한다.

# 파일 생성
cat << EOF > /etc/myapp/config.yaml
server:
  host: 0.0.0.0
  port: 8080
database:
  host: ${DB_HOST}
  port: 5432
EOF

# 변수 확장을 막으려면 구분자를 따옴표로 감싼다
cat << 'EOF' > script_template.sh
echo "Current user: $USER"
echo "Home: $HOME"
EOF
# 위 경우 $USER, $HOME이 확장되지 않고 그대로 기록된다

파이프 (Pipe, `|`)

파이프(|)는 앞 명령어의 stdout을 뒤 명령어의 stdin으로 연결한다.

명령어A  |  명령어B  |  명령어C
stdout ──→ stdin   stdout ──→ stdin   stdout → 화면

# 기본 예시
cat /etc/passwd | grep "bash" | wc -l
# 1) cat이 파일 내용을 stdout으로 출력
# 2) grep이 stdin에서 "bash" 포함 줄을 필터링
# 3) wc -l이 stdin에서 줄 수를 센다

파이프는 stdout만 전달한다

파이프는 stdout만 전달한다. stderr는 파이프를 통과하지 않고 화면에 그대로 출력된다.

# stderr는 파이프를 통과하지 않는다
find / -name "*.conf" | grep nginx
# Permission denied 에러 메시지(stderr)는 여전히 화면에 출력된다

# stderr도 파이프로 전달하려면
find / -name "*.conf" 2>&1 | grep nginx
# stderr를 stdout으로 합친 후 파이프 전달

자주 쓰는 파이프 패턴

# 1. 로그 분석: 에러 추출 → 빈도 분석
grep "ERROR" app.log | awk '{print $4}' | sort | uniq -c | sort -rn

# 2. 프로세스 찾기
ps aux | grep nginx | grep -v grep

# 3. 디스크 사용량 정렬
du -sh /var/*/ 2>/dev/null | sort -rh | head -10

# 4. 파일 내용을 클립보드에 복사 (xclip 설치 필요)
cat config.yaml | xclip -selection clipboard

# 5. JSON 응답 정리 (jq 설치 필요)
curl -s https://api.example.com/data | jq '.items[] | .name'

# 6. 실시간 로그 필터링
tail -f /var/log/syslog | grep --line-buffered "error"

`tee` — 출력을 파일과 화면 동시에

tee는 stdin을 받아서 파일과 stdout 양쪽에 동시 출력하는 명령어이다. 이름은 T자 모양 배관(pipe fitting)에서 유래했다.

           ┌──→ 파일
stdin ──→ tee
           └──→ stdout (다음 파이프 또는 화면)

# 화면에 출력하면서 파일에도 저장
ls -la | tee file_list.txt

# 파일에 추가(append)하면서 화면에도 출력
echo "new entry" | tee -a log.txt

# 여러 파일에 동시 저장
echo "config" | tee file1.txt file2.txt file3.txt

# sudo와 함께 사용 — 권한이 필요한 파일에 쓰기 ★
echo "new line" | sudo tee -a /etc/hosts
# 주의: sudo echo "..." > /etc/hosts는 동작하지 않는다
# > 리다이렉션은 셸이 처리하므로 sudo의 권한이 적용되지 않기 때문이다

프로세스 치환 (Process Substitution)

프로세스 치환은 명령어의 출력을 임시 파일처럼 다른 명령어에 전달하는 기법이다.
<(command) 형태로 사용한다.

# 두 명령어의 출력을 diff로 비교
diff <(ls dir1/) <(ls dir2/)

# 두 서버의 설정 파일 비교
diff <(ssh server1 cat /etc/nginx/nginx.conf) \
     <(ssh server2 cat /etc/nginx/nginx.conf)

# 정렬된 두 결과를 comm으로 비교
comm -12 <(sort file1.txt) <(sort file2.txt)

diff나 comm 같은 명령어는 파일을 인자로 받는다. 파이프로는 하나의 stdin만 전달할 수 있으므로, 두 명령어의 출력을 동시에 전달할 수 없다. 프로세스 치환은 명령어의 출력을 임시 파일 디스크립터로 만들어 이 문제를 해결한다.

`xargs` vs 파이프

파이프는 데이터를 stdin 스트림으로 전달하지만, 일부 명령어는 stdin이 아닌 인자(argument)로 데이터를 받는다. 이때 xargs가 필요하다.

# rm은 stdin으로 파일명을 받지 않는다
find /tmp -name "*.tmp" | rm       # ✗ 동작하지 않음
find /tmp -name "*.tmp" | xargs rm # ✓ xargs가 stdin을 인자로 변환

Chapter 12. vim 편집기

서버에 SSH로 접속했을 때, GUI 에디터는 없다. 사용할 수 있는 텍스트 편집기는 vi(또는 개선판인 vim)와 nano 정도이다. vim은 거의 모든 리눅스 시스템에 기본 설치되어 있으며, git commit, crontab -e, visudo 등 많은 시스템 도구가 기본 편집기로 vim을 호출한다.

vi와 vim의 관계

vi: 1976년에 만들어진 원조 편집기이다. Bill Joy가 개발했다.
vim: Vi IMproved의 약자이다. vi를 기반으로 구문 강조, 다중 되돌리기, 플러그인 등 수많은 기능을 추가한 개선판이다.

대부분의 최신 리눅스 배포판에서 vi를 실행하면 실제로는 vim이 실행된다.

# vim 설치 확인
vim --version | head -1

# 없으면 설치
sudo apt install vim       # Debian/Ubuntu
sudo dnf install vim       # RHEL/Fedora

vim의 모드

vim이 다른 편집기와 다른 점은 모드(mode) 개념이다.

                     i, a, o
         ┌──────── Normal ─────────┐
         │          Mode           │
         │    (명령어 입력 모드)       │
    Esc  │                         │  Esc
         │   :     ──→ Command     │
         │            Mode         │
         │         (저장,종료 등)     │
         │                         │
         └────────→ Insert ────────┘
                    Mode
              (텍스트 입력 모드)

모드	용도	진입 방법	빠져나가는 방법
Normal	커서 이동, 복사, 삭제, 검색 등 명령	vim 시작 시 기본	—
Insert	실제 텍스트 입력	`i`, `a`, `o` 등	`Esc`
Command	저장, 종료, 치환 등 Ex 명령어	Normal에서 `:`	`Enter` 또는 `Esc`
Visual	텍스트 선택 (블록 복사/삭제)	Normal에서 `v`	`Esc`

현재 어떤 모드인지 모르겠으면 Esc를 누른다. Esc는 항상 Normal 모드로 돌아간다.

파일 열기

vim filename.txt           # 파일 열기 (없으면 새로 생성)
vim +10 filename.txt       # 10번째 줄에서 열기
vim +/error filename.txt   # "error"가 처음 나오는 줄에서 열기
vim -R filename.txt        # 읽기 전용으로 열기

저장 & 종료 (Command 모드)

Normal 모드에서 :를 누르면 Command 모드로 진입한다.

명령	동작
`:w`	저장 (Write)
`:q`	종료 (Quit)
`:wq`	저장 후 종료 ★
`:q!`	저장하지 않고 강제 종료 ★
`:wq!`	강제 저장 후 종료 (읽기 전용 파일도)
`ZZ`	`:wq`와 동일 (Normal 모드에서 바로 사용)
`:w newfile.txt`	다른 이름으로 저장

vim을 빠져나올 수 없다면?: Esc를 누른 후 :q!를 입력하면 무조건 나갈 수 있다.

Insert 모드 진입

Normal 모드에서 다음 키를 누르면 Insert 모드로 전환된다:

키	동작
`i`	커서 앞에서 입력 시작 (가장 많이 사용)
`a`	커서 뒤에서 입력 시작
`I`	줄의 맨 앞에서 입력 시작
`A`	줄의 맨 뒤에서 입력 시작
`o`	현재 줄 아래에 새 줄 추가 후 입력
`O`	현재 줄 위에 새 줄 추가 후 입력

Normal 모드 — 커서 이동

기본 이동

키	이동
`h` / `l`	좌 / 우 (한 글자)
`j` / `k`	아래 / 위 (한 줄)
`w`	다음 단어의 시작으로
`b`	이전 단어의 시작으로
`e`	현재 단어의 끝으로
`0`	줄의 맨 처음
`$`	줄의 맨 끝
`^`	줄의 첫 번째 비공백 문자

큰 이동

키	이동
`gg`	파일의 맨 처음
`G`	파일의 맨 끝
`10G` 또는 `:10`	10번째 줄로 이동
`Ctrl + f`	한 페이지 아래 (forward)
`Ctrl + b`	한 페이지 위 (backward)
`Ctrl + d`	반 페이지 아래
`Ctrl + u`	반 페이지 위
`H`	화면 맨 위 (High)
`M`	화면 중간 (Middle)
`L`	화면 맨 아래 (Low)

Normal 모드 — 편집 명령

삭제

명령	동작
`x`	커서 위치의 한 글자 삭제
`dd`	현재 줄 전체 삭제 ★
`3dd`	현재 줄부터 3줄 삭제
`dw`	커서부터 단어 끝까지 삭제
`d$` 또는 `D`	커서부터 줄 끝까지 삭제
`d0`	커서부터 줄 처음까지 삭제
`dG`	커서부터 파일 끝까지 삭제
`dgg`	커서부터 파일 처음까지 삭제

복사 & 붙여넣기

vim에서 복사는 yank라고 부른다.

명령	동작
`yy`	현재 줄 복사 ★
`3yy`	현재 줄부터 3줄 복사
`yw`	단어 복사
`p`	커서 아래/뒤에 붙여넣기 ★
`P`	커서 위/앞에 붙여넣기

되돌리기 & 다시 실행

명령	동작
`u`	되돌리기 (Undo) ★
`Ctrl + r`	다시 실행 (Redo)
`.`	마지막 명령 반복

검색 & 치환

검색

/pattern    → 아래 방향으로 검색
?pattern    → 위 방향으로 검색
n           → 다음 검색 결과로 이동
N           → 이전 검색 결과로 이동
*           → 커서 위의 단어를 아래 방향으로 검색
#           → 커서 위의 단어를 위 방향으로 검색

치환 (Command 모드)

sed와 거의 동일한 문법이다.

# 현재 줄에서 치환 (첫 번째만)
:s/old/new/

# 현재 줄에서 모든 매치 치환
:s/old/new/g

# 파일 전체에서 치환 ★★★
:%s/old/new/g

# 파일 전체에서 치환 (확인하면서)
:%s/old/new/gc
# 각 매치마다 y(yes), n(no), a(all), q(quit)를 선택

# 특정 범위에서 치환 (10~20번째 줄)
:10,20s/old/new/g

# 대소문자 무시 치환
:%s/old/new/gi

`~/.vimrc` — 영구 설정

vim을 열 때마다 설정을 반복하고 싶지 않다면 ~/.vimrc 파일에 설정을 저장한다.

# 실무에 적합한 최소 .vimrc
cat << 'EOF' > ~/.vimrc
set number              " 줄 번호 표시
syntax on               " 구문 강조
set hlsearch            " 검색 하이라이트
set incsearch           " 입력하면서 검색
set tabstop=4           " 탭 너비
set shiftwidth=4        " 자동 들여쓰기 너비
set expandtab           " 탭을 공백으로
set autoindent          " 자동 들여쓰기
set showmatch           " 괄호 매치 표시
set ruler               " 커서 위치 표시
set encoding=utf-8      " UTF-8 인코딩
EOF

요약

상황	키
텍스트 입력하고 싶다	`i` → 입력 → `Esc`
새 줄 추가하고 싶다	`o` → 입력 → `Esc`
저장하고 종료	`Esc` → `:wq` → Enter
저장 안 하고 종료	`Esc` → `:q!` → Enter
줄 삭제	`dd`
되돌리기	`u`
검색	`/keyword` → `n`(다음)
전체 치환	`:%s/old/new/g`
줄 번호 표시	`:set number`
모르겠으면	`Esc` 연타

Chapter 13. 프로세스 관리

프로그램 vs 프로세스

프로그램(Program)은 디스크에 저장된 실행 파일이다. /usr/bin/nginx, /usr/bin/python3 같은 바이너리 파일이 프로그램이다. 프로그램은 정적(static)이다 — 그냥 파일일 뿐이다.

프로세스(Process)는 프로그램이 메모리에 로드되어 실행 중인 인스턴스이다. 하나의 프로그램에서 여러 프로세스가 생성될 수 있다. 예를 들어 터미널 3개를 열면 bash 프로세스가 3개 존재한다.

프로세스는 다음을 가진다:

PID (Process ID): 프로세스의 고유 식별 번호
PPID (Parent PID): 자신을 생성한 부모 프로세스의 PID
UID/GID: 프로세스를 실행한 사용자/그룹
메모리 공간: 코드, 데이터, 스택, 힙
파일 디스크립터: 열린 파일, 소켓, 파이프 등
환경변수: 프로세스에 전달된 설정값

PID 1 — init/systemd

리눅스 부팅 시 커널이 가장 먼저 실행하는 프로세스가 PID 1이다.
최신 배포판에서는 systemd가 PID 1이다.
모든 다른 프로세스는 PID 1의 자식(또는 자손)이다.

# PID 1 확인
ps -p 1 -o comm=
# systemd

# 프로세스 트리 확인
pstree -p | head -20
# systemd(1)─┬─sshd(1234)───sshd(5678)───bash(5679)
#            ├─nginx(2345)─┬─nginx(2346)
#            │             └─nginx(2347)
#            └─dockerd(3456)

프로세스의 생성 — fork와 exec

리눅스에서 새 프로세스는 fork-exec 메커니즘으로 생성된다:

fork(): 현재 프로세스(부모)의 복사본을 만든다 → 자식 프로세스 생성
exec(): 자식 프로세스의 메모리를 새로운 프로그램으로 교체한다

셸에서 명령어를 실행하면 이 과정이 일어난다:

bash(PID 100)  →  fork()  →  bash(PID 200, 복사본)  →  exec("ls")  →  ls(PID 200)
    (부모)                       (자식)                                  (프로그램 교체)

좀비 프로세스와 고아 프로세스

좀비 프로세스(Zombie): 실행이 끝났지만 부모가 아직 종료 상태를 회수하지 않은 프로세스이다. ps에서 상태가 Z로 표시된다. 소량은 정상이지만, 대량 발생하면 PID가 고갈될 수 있다.

고아 프로세스(Orphan): 부모 프로세스가 먼저 종료된 자식 프로세스이다. PID 1(systemd)이 자동으로 입양(adopt)하여 관리한다.

# 좀비 프로세스 찾기
ps aux | awk '$8 == "Z" {print}'

프로세스 확인 명령어

`ps` — 프로세스 상태 스냅샷

ps는 실행 중인 프로세스의 현재 상태를 한 번 캡처하여 보여준다.

# 모든 프로세스 상세 정보 ★★★
ps aux
# USER       PID %CPU %MEM    VSZ   RSS TTY  STAT START   TIME COMMAND
# root         1  0.0  0.3 169484 12340 ?    Ss   Mar20   0:05 /usr/lib/systemd/systemd
# nginx     2345  0.1  0.5  45678 20480 ?    S    Mar20   1:23 nginx: worker process

# 특정 프로세스 검색 ★★★
ps aux | grep nginx
ps aux | grep -v grep | grep nginx    # grep 자체 제외

# 프로세스 트리 형태로 보기
ps auxf

# 특정 필드만 출력 (-o: format)
ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%mem | head -15

# 특정 사용자의 프로세스
ps -u nginx

# 특정 PID의 상세 정보
ps -p 1234 -f

ps aux 출력 필드

필드	설명
USER	프로세스 소유자
PID	프로세스 ID
%CPU	CPU 사용률
%MEM	메모리 사용률
VSZ	가상 메모리 크기 (KB)
RSS	실제 사용 중인 물리 메모리 (KB) — Resident Set Size
TTY	연결된 터미널 (`?`면 터미널 없음 = 데몬)
STAT	프로세스 상태
START	시작 시간
TIME	CPU 사용 누적 시간
COMMAND	실행 명령어

STAT(프로세스 상태) 코드:

코드	의미
`R`	Running — 실행 중 또는 실행 대기
`S`	Sleeping — 이벤트 대기 중 (대부분의 프로세스)
`D`	Uninterruptible Sleep — I/O 대기 (디스크 등)
`T`	Stopped — 중지됨 (Ctrl+Z 등)
`Z`	Zombie — 종료되었지만 부모가 회수하지 않음

`pgrep` — 프로세스 이름으로 PID 찾기

# 프로세스 이름으로 PID 검색
pgrep nginx
# 2345
# 2346

# 상세 정보와 함께
pgrep -a nginx
# 2345 nginx: master process /usr/sbin/nginx
# 2346 nginx: worker process

# 특정 사용자의 프로세스만
pgrep -u www-data

프로세스 종료 — 시그널(Signal)

시그널이란

시그널은 프로세스에 보내는 비동기적 알림(notification)이다. "이 일을 해라", "종료해라", "멈춰라" 같은 메시지를 프로세스에 전달하는 메커니즘이다.

주요 시그널

번호	이름	기본 동작	설명
1	`SIGHUP`	종료	터미널 연결이 끊어질 때. 데몬에서는 설정 다시 읽기용으로 사용
2	`SIGINT`	종료	`Ctrl + C`에 해당. 사용자가 인터럽트 요청
9	`SIGKILL`	강제 종료	프로세스가 무시/가로챌 수 없다. 최후의 수단
15	`SIGTERM`	종료	정상 종료 요청 (기본 시그널). 프로세스가 정리 작업 후 종료 가능
18	`SIGCONT`	재개	중지된 프로세스를 재개
19	`SIGSTOP`	중지	프로세스 일시 중지. 무시/가로챌 수 없다
20	`SIGTSTP`	중지	`Ctrl + Z`에 해당

SIGTERM vs SIGKILL

SIGTERM (15): "깔끔하게 종료해주세요"라는 요청이다. 프로세스는 이 시그널을 받으면 열린 파일을 닫고, 임시 파일을 정리하고, 연결을 해제한 뒤 종료할 수 있다. 항상 먼저 시도해야 한다.
SIGKILL (9): "지금 즉시 죽어라"라는 명령이다. 커널이 프로세스를 즉시 종료시킨다. 프로세스는 어떤 정리 작업도 할 수 없다. 데이터 손실, 파일 손상, 잠금 미해제 등의 문제가 발생할 수 있다.

`kill` — 시그널 보내기

kill이라는 이름이지만, 실제로는 시그널을 보내는 명령어이다.

# SIGTERM 보내기 (기본, 정상 종료 요청) ★
kill 1234
kill -15 1234
kill -SIGTERM 1234
# 세 가지 모두 동일

# SIGKILL 보내기 (강제 종료, 최후의 수단)
kill -9 1234
kill -SIGKILL 1234

# 설정 다시 읽기 (SIGHUP) — 데몬을 재시작하지 않고 설정 반영
kill -1 $(pgrep nginx)
kill -HUP $(pgrep nginx)

# 여러 프로세스에 시그널 보내기
kill 1234 1235 1236

`pkill` / `killall` — 이름으로 종료

# 프로세스 이름으로 종료
pkill nginx
pkill -9 nginx          # 강제 종료

# 특정 사용자의 프로세스만 종료
pkill -u testuser

# killall: 정확한 이름으로 종료
killall nginx
killall -9 hung_process

올바른 프로세스 종료 순서

# 1단계: SIGTERM으로 정상 종료 요청
kill 1234

# 2단계: 잠시 대기 (프로세스가 정리할 시간을 준다)
sleep 5

# 3단계: 아직 살아있는지 확인
ps -p 1234

# 4단계: 여전히 살아있으면 SIGKILL
kill -9 1234

포그라운드 & 백그라운드

포그라운드(Foreground): 터미널을 점유하고 있는 프로세스이다. 명령어를 실행하면 기본적으로 포그라운드에서 실행된다. 프로세스가 끝나거나 중지할 때까지 터미널에 다른 명령어를 입력할 수 없다.

백그라운드(Background): 터미널을 점유하지 않고 실행되는 프로세스이다. 명령어 끝에 &를 붙이면 백그라운드로 실행된다.

# 백그라운드로 실행
./long_running_task.sh &
# [1] 12345    ← 작업 번호 1, PID 12345

# 포그라운드 프로세스를 백그라운드로 전환
# Ctrl + Z  (SIGTSTP → 일시 중지)
# bg        (백그라운드에서 재개)

# 백그라운드 프로세스를 포그라운드로 전환
fg
fg %1     # 작업 번호 지정

# 백그라운드 작업 목록 확인
jobs
# [1]+  Running    ./long_task.sh &
# [2]-  Stopped    vim file.txt

`nohup` — 터미널 종료 후에도 실행 유지

터미널(SSH 세션)을 닫으면 해당 터미널에서 실행한 프로세스는 SIGHUP을 받아 종료된다. nohup은 SIGHUP을 무시하여 터미널을 닫아도 프로세스가 계속 실행되게 한다.

# nohup + 백그라운드 실행
nohup ./long_running_task.sh &
# 출력은 nohup.out 파일에 저장된다

# 출력을 특정 파일로 지정
nohup ./task.sh > /var/log/task.log 2>&1 &

`lsof` — 열린 파일 확인

List Open Files의 약자이다. lsof는 파일뿐만 아니라 네트워크 소켓, 파이프, 디바이스 등 프로세스가 열고 있는 모든 것을 보여준다.

# 특정 프로세스가 열고 있는 파일
lsof -p 1234

# 특정 파일을 사용 중인 프로세스
lsof /var/log/syslog

# 삭제되었지만 아직 열려있는 파일 (디스크 공간 미해제 원인)
lsof +L1

# 특정 포트를 사용 중인 프로세스 ★★★
lsof -i :80
lsof -i :8080

# 특정 사용자가 열고 있는 파일
lsof -u nginx

# 특정 디렉터리의 파일을 사용 중인 프로세스
lsof +D /var/log/

요약

명령어	용도	핵심
`ps aux`	프로세스 목록	가장 기본적인 확인
`pgrep`	이름으로 PID 검색	`pgrep -a` (상세)
`pstree`	프로세스 트리	부모-자식 관계 파악
`kill`	시그널 보내기	`-15`(정상) → `-9`(강제) 순서
`pkill`	이름으로 종료	`pkill -u user`
`jobs` / `fg` / `bg`	작업 제어	포그라운드/백그라운드 전환
`nohup`	터미널 독립 실행	SSH 끊어져도 생존
`lsof`	열린 파일/포트 확인	`lsof -i :PORT`

Chapter 14. 시스템 모니터링

장애가 발생하면 "지금 서버에서 무슨 일이 일어나고 있는가"를 빠르게 파악해야 한다.
모니터링은 크게 네 가지 리소스를 추적한다:

리소스	핵심 질문	주요 도구
CPU	어떤 프로세스가 CPU를 많이 쓰는가?	`top`, `htop`, `mpstat`
메모리	메모리가 부족한가? 스왑이 발생하는가?	`free`, `top`, `vmstat`
디스크	I/O 병목이 있는가? 용량이 부족한가?	`iostat`, `df`, `iotop`
네트워크	트래픽이 과도한가? 연결 문제가 있는가?	`ss`, `netstat`, `iftop`

`top` — 실시간 시스템 모니터링

top은 리눅스의 작업 관리자(Task Manager)에 해당한다. CPU, 메모리 사용량과 프로세스 목록을 실시간으로 보여준다.

출력 해석

top - 14:30:00 up 15 days,  3:22,  2 users,  load average: 0.52, 0.38, 0.41
Tasks: 215 total,   1 running, 213 sleeping,   0 stopped,   1 zombie
%Cpu(s):  5.2 us,  1.8 sy,  0.0 ni, 92.1 id,  0.3 wa,  0.0 hi,  0.6 si,  0.0 st
MiB Mem :   7812.5 total,   1245.3 free,   3210.8 used,   3356.4 buff/cache
MiB Swap:   2048.0 total,   1792.0 free,    256.0 used.   4230.1 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2345 nginx     20   0  456780  98760  12340 S   3.2  1.2   5:23.45 nginx
 3456 mysql     20   0 1234560 567890  45678 S   2.1  7.1  12:34.56 mysqld

헤더 영역 상세 해석:

Load Average (0.52, 0.38, 0.41):

1분, 5분, 15분 평균 시스템 부하이다
CPU 코어 수와 비교해야 의미가 있다. 4코어 시스템에서 load 4.0이면 100% 활용, 8.0이면 과부하
load average가 코어 수를 초과하면 프로세스가 CPU를 기다리는 대기열(queue)이 존재한다는 뜻이다

# CPU 코어 수 확인
nproc
# 또는
grep -c processor /proc/cpuinfo

`htop` — 향상된 대화형 모니터링

top의 개선판이다. 색상, 그래프, 마우스 지원 등 사용성이 훨씬 좋다.

htop의 장점:

CPU, 메모리 사용률을 그래프 바로 시각화
화살표 키와 마우스로 탐색 가능
프로세스를 직접 선택하여 시그널 전송 가능 (F9)
트리 보기 (F5)
필터링 (F4) / 검색 (F3)
설정 커스터마이징 (F2)

`uptime` — 시스템 가동 시간 & 부하

$ uptime
 14:30:00 up 15 days,  3:22,  2 users,  load average: 0.52, 0.38, 0.41

간결하게 load average를 확인할 때 자주 사용한다.

`iostat` — 디스크 I/O 모니터링

# 설치 (sysstat 패키지)
sudo apt install sysstat

# 확장 통계, 2초 간격
$ iostat -x 2
Device     r/s     w/s   rkB/s   wkB/s  await  %util
sda       12.50   45.30  200.00  1024.00  2.50  15.20
nvme0n1    5.20   10.10  320.00   512.00  0.30   3.40

장애 대응 체크리스트

서버에 문제가 발생했을 때 순서대로 확인하는 체계적 접근법

# 1. 전체 상황 파악 (30초 안에)
uptime              # load average 확인
free -h             # 메모리 상태
df -h               # 디스크 용량
top -bn1 | head -20 # CPU/프로세스 상위

# 2. CPU 문제 의심 시
top                 # CPU 점유율 높은 프로세스 확인 (P키)
mpstat -P ALL 1     # CPU 코어별 사용률

# 3. 메모리 문제 의심 시
free -h             # available 확인
vmstat 1 5          # si/so (스왑 활동) 확인
ps aux --sort=-%mem | head -10   # 메모리 점유 상위 프로세스
dmesg -T | grep -i oom          # OOM killer 동작 여부

# 4. 디스크 문제 의심 시
df -h               # 용량 확인
df -i               # inode 확인
iostat -x 1 5       # I/O 활용률 확인
iotop                # 프로세스별 I/O (별도 설치)

# 5. 네트워크 문제 의심 시
ss -tlnp            # 리슨 중인 포트
ping 8.8.8.8        # 외부 연결 확인
curl -v http://localhost  # 웹 서비스 응답 확인

Chapter 15. 서비스 관리 & systemd 심화

systemd

init 시스템의 역할

리눅스가 부팅되면 커널은 PID 1 프로세스를 실행한다.
이 PID 1 프로세스가 init 시스템이며, 이후 모든 서비스(데몬)를 시작하고 관리하는 역할을 한다.

systemd의 특징

병렬 부팅: 서비스들을 동시에 시작하여 부팅 속도가 빠르다
의존성 관리: 서비스 간 의존 관계를 선언적으로 정의한다
소켓 기반 활성화: 소켓 요청이 들어올 때 서비스를 자동 시작한다
cgroup 통합: 프로세스 그룹을 추적하여 자식 프로세스까지 관리한다
저널(journal): 통합 로그 시스템(journald)을 내장한다
타이머: cron을 대체할 수 있는 스케줄링 기능을 제공한다

데몬(Daemon)

데몬(Daemon)은 백그라운드에서 실행되는 프로세스로, 사용자와 직접 상호작용하지 않는다.
웹 서버(nginx), 데이터베이스(mysql), SSH 서버(sshd) 등이 데몬이다.
관례적으로 이름 끝에 d를 붙인다 (sshd, httpd, dockerd 등).

`systemctl` — 서비스 관리의 핵심 명령어

systemctl은 systemd를 제어하는 통합 명령어이다.

서비스 상태 확인

# 서비스 상태 확인 ★★★
systemctl status nginx
# ● nginx.service - A high performance web server and a reverse proxy server
#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
#      Active: active (running) since Mon 2025-03-20 10:00:00 KST; 3 days ago
#    Main PID: 2345 (nginx)
#       Tasks: 5 (limit: 4915)
#      Memory: 12.3M
#      CGroup: /system.slice/nginx.service
#              ├─2345 nginx: master process /usr/sbin/nginx
#              ├─2346 nginx: worker process
#              └─2347 nginx: worker process
#
# Mar 20 10:00:00 web-server systemd[1]: Starting A high performance web server...
# Mar 20 10:00:00 web-server systemd[1]: Started A high performance web server...

# 간단히 활성 여부만 확인
systemctl is-active nginx
# active

# 부팅 시 자동 시작 설정 여부
systemctl is-enabled nginx
# enabled

필드	의미
Loaded	unit 파일 경로, enabled/disabled 여부
Active	현재 상태 — active(running), inactive(dead), failed
Main PID	메인 프로세스의 PID
Tasks	서비스가 사용 중인 스레드/프로세스 수
Memory	서비스가 사용 중인 메모리
CGroup	서비스에 속한 프로세스 트리

서비스 시작/중지/재시작

# 시작
sudo systemctl start nginx

# 중지
sudo systemctl stop nginx

# 재시작 (stop + start)
sudo systemctl restart nginx

# 설정만 다시 읽기 (중단 없이) ★
sudo systemctl reload nginx
# 모든 서비스가 reload를 지원하지는 않는다

# reload를 시도하고, 안 되면 restart
sudo systemctl reload-or-restart nginx

restart vs reload

restart: 프로세스를 완전히 종료 후 다시 시작한다. 순간적으로 서비스가 중단된다.
reload: 프로세스를 종료하지 않고 설정 파일만 다시 읽는다. 서비스 중단이 없다. Nginx, Apache, HAProxy 등이 지원한다.

부팅 시 자동 시작 설정

# 부팅 시 자동 시작 활성화
sudo systemctl enable nginx

# 활성화 + 즉시 시작을 한 번에
sudo systemctl enable --now nginx

# 부팅 시 자동 시작 비활성화
sudo systemctl disable nginx

서비스 목록 조회

# 모든 활성 서비스 목록
systemctl list-units --type=service

# 실행 중인 서비스만
systemctl list-units --type=service --state=running

# 실패한 서비스 확인 ★★★
systemctl --failed

# 모든 서비스 (enabled/disabled 포함)
systemctl list-unit-files --type=service

`journalctl` — 로그 조회

systemd는 journald라는 통합 로그 시스템을 내장한다. journalctl은 이 저널 로그를 조회하는 명령어이다.

# 전체 로그 (페이저로 열림)
journalctl

# 특정 서비스의 로그 ★★★
journalctl -u nginx
journalctl -u nginx --since "1 hour ago"

# 최근 N줄만 보기
journalctl -u nginx -n 50

# 실시간 로그 추적 (tail -f와 동일) ★★★
journalctl -u nginx -f

# 이번 부팅 이후 로그만
journalctl -b

# 시간 범위 지정
journalctl --since "2025-03-23 14:00" --until "2025-03-23 15:00"

# 특정 우선순위 이상만 (에러 이상)
journalctl -p err
# 우선순위: emerg(0), alert(1), crit(2), err(3), warning(4), notice(5), info(6), debug(7)

# 커널 메시지만 (dmesg와 유사)
journalctl -k

# 디스크 사용량 확인
journalctl --disk-usage

# 오래된 로그 정리
sudo journalctl --vacuum-time=7d     # 7일 이전 삭제
sudo journalctl --vacuum-size=500M   # 500MB 이하로 유지

Unit 파일 — systemd의 설정 단위

Unit이란

systemd가 관리하는 모든 리소스를 Unit이라고 한다.
서비스뿐만 아니라 마운트, 타이머, 소켓 등도 Unit이다.

Unit 타입	확장자	설명
Service	`.service`	데몬 프로세스
Timer	`.timer`	스케줄링 (cron 대안)
Socket	`.socket`	소켓 기반 활성화
Mount	`.mount`	파일시스템 마운트
Target	`.target`	Unit들의 그룹 (부팅 레벨과 유사)
Path	`.path`	파일시스템 경로 감시

Service Unit 파일 구조

# 기존 서비스의 unit 파일 확인
systemctl cat nginx.service
systemctl cat cron.service

[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

[Unit] 섹션 — 서비스의 메타데이터와 의존성

[Service] 섹션 — 서비스 실행 방식

[Install] 섹션 — enable/disable 시 동작

요약

명령어	용도	가장 많이 쓰는 형태
`systemctl status`	서비스 상태 확인	`systemctl status nginx`
`systemctl start/stop`	서비스 시작/중지
`systemctl restart`	서비스 재시작
`systemctl reload`	설정만 다시 읽기	서비스 중단 없음
`systemctl enable --now`	자동 시작 + 즉시 시작
`systemctl --failed`	실패한 서비스 확인	장애 대응 시 필수
`systemctl daemon-reload`	unit 파일 변경 반영	unit 수정 후 필수
`systemctl edit`	서비스 설정 오버라이드
`journalctl -u X -f`	실시간 서비스 로그

Chapter 16. 로그 관리

로그가 왜 중요한가

로그는 시스템과 애플리케이션이 "무슨 일이 일어났는지"를 기록한 텍스트이다.

애플리케이션이 죽었다 → 로그에서 에러 메시지 확인
보안 침해가 의심된다 → 인증 로그에서 비정상 접근 확인
성능이 저하되었다 → 로그에서 느린 쿼리, 타임아웃 패턴 확인
배포 후 문제가 생겼다 → 배포 시점 전후 로그 비교

리눅스 로그 체계

두 가지 로그 시스템

현대 리눅스에는 두 가지 로그 시스템이 공존한다:

① rsyslog (전통적 방식)

텍스트 파일로 /var/log/에 저장
오래된 표준이지만 여전히 널리 사용
cat, grep, tail 등으로 직접 읽을 수 있다

② journald (systemd 방식)

바이너리 형식으로 저장 (직접 읽을 수 없음)
journalctl 명령어로 조회
구조화된 메타데이터(서비스명, PID, 우선순위 등) 포함
systemd 서비스의 stdout/stderr를 자동 수집

대부분의 배포판에서 두 시스템이 동시에 동작한다.
journald가 수집한 로그를 rsyslog가 전달받아 /var/log/에 텍스트 파일로 저장하는 구조이다.

# 로그 디렉터리 구조 확인
ls -la /var/log/

로그 로테이션 (logrotate)

로그 파일은 시간이 지나면 계속 커진다. 방치하면 디스크를 가득 채운다. logrotate는 로그 파일을 주기적으로 회전(rotate)시켜 관리하는 도구이다.

access.log      ← 현재 기록 중
access.log.1    ← 어제 (로테이션 됨)
access.log.2.gz ← 그저께 (압축됨)
access.log.3.gz ← 3일 전
...
access.log.7.gz ← 7일 전 (이후 삭제)

logrotate 테스트 및 수동 실행

# 설정 문법 검증 (실제로 실행하지 않음)
sudo logrotate -d /etc/logrotate.d/nginx

# 강제 수동 실행
sudo logrotate -f /etc/logrotate.d/nginx

# 전체 logrotate 수동 실행
sudo logrotate -f /etc/logrotate.conf

Chapter 17. 스케줄링

특정 시간 또는 주기적으로 명령어나 스크립트를 자동 실행하는 것이다.

매일 새벽 3시 데이터베이스 백업
매 5분마다 서비스 헬스체크
매월 1일 리포트 생성

리눅스에서는 cron(전통적)과 systemd timer(현대적), 두 가지 방식으로 스케줄링할 수 있다.

cron — 전통적 작업 스케줄러

cron은 유닉스 시대부터 사용되어 온 작업 스케줄러 데몬이다. 백그라운드에서 항상 실행되며, 설정된 시간이 되면 명령어를 자동 실행한다. 설정 파일을 crontab(cron table)이라고 한다.

crontab 시간 형식

┌───────── 분 (0-59)
│ ┌─────── 시 (0-23)
│ │ ┌───── 일 (1-31)
│ │ │ ┌─── 월 (1-12)
│ │ │ │ ┌─ 요일 (0-7, 0과 7은 일요일)
│ │ │ │ │
* * * * * command

문자	의미	예시
`*`	모든 값	`* * * * *` → 매분
`,`	여러 값	`1,15 * * * *` → 1분, 15분
`-`	범위	`1-5 * * * *` → 1~5분
`/`	간격	`/5 * * *` → 5분마다

자주 쓰는 스케줄 예시

# 매분 실행
* * * * * /path/to/script.sh

# 매시 정각
0 * * * * /path/to/script.sh

# 매일 새벽 3시
0 3 * * * /path/to/script.sh

# 매일 새벽 3시 30분
30 3 * * * /path/to/script.sh

# 5분마다
*/5 * * * * /path/to/script.sh

# 매주 일요일 자정
0 0 * * 0 /path/to/script.sh

# 매월 1일 새벽 2시
0 2 1 * * /path/to/script.sh

# 평일(월~금) 오전 9시
0 9 * * 1-5 /path/to/script.sh

# 매시 0분, 30분 (30분마다)
0,30 * * * * /path/to/script.sh

crontab 관리

# 현재 사용자의 crontab 편집 ★★★
crontab -e

# 현재 사용자의 crontab 보기
crontab -l

# 현재 사용자의 crontab 전체 삭제 (주의!)
crontab -r

# 특정 사용자의 crontab 편집 (root만 가능)
sudo crontab -u deploy -e

# 특정 사용자의 crontab 보기
sudo crontab -u deploy -l

crontab 작성 시 주의사항

① 환경변수가 다르다

cron은 사용자의 로그인 셸과 다른 환경에서 실행된다. PATH, HOME 등이 최소한으로 설정되어 있다. 그래서 crontab에서는 절대 경로를 사용해야 한다.

# ✗ 잘못된 예 — PATH에 /usr/local/bin이 없을 수 있음
* * * * * python3 script.py

# ✓ 올바른 예 — 절대 경로 사용
* * * * * /usr/bin/python3 /home/devops/script.py

# 또는 crontab 상단에 PATH를 직접 설정
PATH=/usr/local/bin:/usr/bin:/bin
* * * * * python3 /home/devops/script.py

② 출력을 반드시 처리하기

cron 작업의 stdout/stderr는 기본적으로 사용자에게 메일로 전송된다. 메일 시스템이 없으면 에러가 쌓인다.

# 출력을 로그 파일로 저장
0 3 * * * /opt/backup.sh >> /var/log/backup.log 2>&1

# 출력을 아예 버리기
0 3 * * * /opt/backup.sh > /dev/null 2>&1

# 에러만 로그로 남기기
0 3 * * * /opt/backup.sh > /dev/null 2>> /var/log/backup-error.log

③ 중복 실행 방지

작업이 오래 걸려서 다음 실행 시점에도 아직 실행 중이면 중복 실행된다. flock으로 방지할 수 있다.

# flock을 사용한 중복 실행 방지
*/5 * * * * flock -n /tmp/myjob.lock /opt/slow_task.sh
# -n: 이미 잠겨있으면 즉시 종료 (대기하지 않음)

systemd timer — 현대적 스케줄러

왜 systemd timer를 쓰는가

기능	cron	systemd timer
의존성 관리	없음	다른 서비스에 의존 가능
로그	직접 리다이렉션 필요	journalctl로 통합
실행 기록	별도 관리 필요	`systemctl list-timers`로 확인
놓친 실행 처리	서버 꺼져있으면 놓침	`Persistent=true`로 보장
초 단위 스케줄링	불가 (분 단위)	가능
리소스 제한	불가	MemoryMax, CPUQuota 등 가능

timer 구조

systemd timer는 두 개의 unit 파일로 구성된다:

.timer — 언제 실행할지 (스케줄)
.service — 무엇을 실행할지 (작업 내용)

OnCalendar 시간 형식

# 형식: 요일 년-월-일 시:분:초

OnCalendar=*-*-* 03:00:00           # 매일 3시
OnCalendar=Mon *-*-* 09:00:00       # 매주 월요일 9시
OnCalendar=*-*-01 02:00:00          # 매월 1일 2시
OnCalendar=*-01-01 00:00:00         # 매년 1월 1일
OnCalendar=*-*-* *:*:00             # 매분
OnCalendar=*-*-* *:00/30:00         # 30분마다
OnCalendar=hourly                    # 매시간
OnCalendar=daily                     # 매일 자정
OnCalendar=weekly                    # 매주 월요일 자정

# 시간 표현식 검증
systemd-analyze calendar "*-*-* 03:00:00"
# Original form: *-*-* 03:00:00
# Next elapse: Tue 2025-03-24 03:00:00 KST

`at` — 일회성 예약 실행

특정 시간에 한 번만 실행할 작업을 예약한다. cron은 반복 실행, at은 일회성이다.

# 설치 (없는 경우)
sudo apt install at

# 10분 후에 실행
at now + 10 minutes
> /opt/scripts/deploy.sh
> [Ctrl+D]

# 특정 시간에 실행
at 3:00 AM
> /opt/scripts/maintenance.sh
> [Ctrl+D]

# 내일 오후 5시에 실행
at 5:00 PM tomorrow
> echo "Reminder" | mail -s "Task due" admin@example.com
> [Ctrl+D]

# 예약된 작업 목록
atq

# 예약 취소
atrm <작업번호>

[멋사 클라우드 5기] Day 33 & 34 - Linux (1)

allluck777 — Wed, 25 Mar 2026 09:05:50 +0900

Chapter 01. 리눅스 개요

리눅스란 무엇인가

리눅스(Linux)는 오픈소스 운영체제(Operating System)이다. 정확히 말하면, 리눅스는 커널(Kernel)의 이름이다. 커널이란 하드웨어와 소프트웨어 사이에서 중재자 역할을 하는 운영체제의 핵심 구성 요소이다. "리눅스"라고 부르는 것은 이 리눅스 커널 위에 다양한 시스템 유틸리티, 라이브러리, 셸(Shell), 패키지 매니저 등을 결합한 리눅스 배포판(Distribution)을 의미한다.

운영체제의 구조

┌─────────────────────────────────────┐
│          사용자 애플리케이션             │  ← 웹 브라우저, 에디터, Docker 등
├─────────────────────────────────────┤
│              셸 (Shell)              │  ← bash, zsh 등 명령어 해석기
├─────────────────────────────────────┤
│         시스템 유틸리티 / 라이브러리       │  ← GNU 도구들 (ls, cp, grep 등)
├─────────────────────────────────────┤
│         커널 (Kernel) — Linux        │  ← 프로세스, 메모리, 파일시스템, 네트워크 관리
├─────────────────────────────────────┤
│            하드웨어 (Hardware)        │  ← CPU, RAM, 디스크, NIC 등
└─────────────────────────────────────┘

하드웨어(Hardware)
CPU, 메모리(RAM), 디스크(SSD/HDD), 네트워크 인터페이스 카드(NIC) 등 물리적 장치이다. 운영체제 없이는 이 하드웨어를 직접 제어하기 어렵다.

커널(Kernel)
운영체제의 심장이다. 커널이 수행하는 핵심 기능은 다음과 같다:

프로세스 관리: 어떤 프로그램이 CPU를 얼마나 사용할지 결정한다 (스케줄링)
메모리 관리: 각 프로그램에 메모리를 할당하고, 부족하면 스왑(swap) 영역을 활용한다
파일시스템 관리: 디스크에 데이터를 읽고 쓰는 방식을 제어한다
디바이스 드라이버: 하드웨어 장치와 통신하기 위한 인터페이스를 제공한다
네트워크 스택: TCP/IP 통신을 처리한다

시스템 유틸리티 / 라이브러리
커널 위에서 동작하는 기본 도구들이다. 파일을 복사하는 cp, 텍스트를 검색하는 grep, C 라이브러리인 glibc 등이 여기에 해당한다. 이 도구들의 상당수는 GNU 프로젝트에서 만들었기 때문에, 리눅스의 정식 명칭은 "GNU/Linux"이다.

셸(Shell)
사용자가 키보드로 입력한 명령어를 해석하여 커널에 전달하는 프로그램이다. 대표적으로 bash(Bourne Again Shell), zsh, sh 등이 있다. 셸은 단순한 명령어 해석기를 넘어서, 변수, 조건문, 반복문 등을 지원한다.

사용자 애플리케이션
최종 사용자가 직접 사용하는 프로그램이다. 웹 서버(Nginx, Apache), 컨테이너 런타임(Docker), 데이터베이스(MySQL, PostgreSQL) 등이 이 계층에서 동작한다.

왜 서버 환경에서 리눅스가 지배적인가

전 세계 서버의 약 96% 이상이 리눅스를 운영체제로 사용한다.

무료 & 오픈소스
라이선스 비용이 없다. 수천 대의 서버를 운영해도 OS 라이선스 비용은 0원이다.

안정성 & 보안
리눅스는 수십 년간 서버 환경에서 검증되었다. 커널과 주요 구성 요소들이 오픈소스이므로 전 세계 개발자들이 보안 취약점을 빠르게 발견하고 수정한다.

경량성
GUI 없이 CLI(Command Line Interface)만으로 운영할 수 있어 시스템 리소스를 효율적으로 사용한다. 이는 클라우드 환경에서 비용 절감과 직결된다.

자동화 친화적
모든 작업을 CLI와 스크립트로 수행할 수 있다. 이것이 DevOps의 핵심인 Infrastructure as Code(IaC), CI/CD 파이프라인, 설정 관리(Configuration Management)**를 가능하게 한다.

커널 (Kernel)

운영체제의 핵심이다. 하드웨어를 직접 제어하며, 애플리케이션이 하드웨어 리소스를 사용할 수 있도록 시스템 콜(System Call)이라는 인터페이스를 제공한다.

시스템 콜(System Call)이란, 사용자 공간(User Space)의 프로그램이 커널 공간(Kernel Space)의 기능을 요청하는 메커니즘이다. 예를 들어 파일을 열 때(open()), 프로세스를 생성할 때(fork()), 네트워크 데이터를 보낼 때(send()) 모두 시스템 콜을 통해 커널에 요청한다.

┌──────────────────────────────┐
│       User Space (사용자 공간)  │  ← 애플리케이션, 셸, 유틸리티
│                              │
│    open(), read(), write()   │  ← 시스템 콜 호출
├──────────────────────────────┤
│      Kernel Space (커널 공간)  │  ← 프로세스 스케줄러, 메모리 관리자
│                              │     파일시스템 드라이버, 네트워크 스택
│      하드웨어 제어 코드           │
└──────────────────────────────┘

셸 (Shell)

사용자와 커널 사이의 인터페이스이다. 사용자가 명령어를 입력하면 셸이 이를 해석하여 커널에 전달한다.

주요 셸 종류:

셸	설명
`sh` (Bourne Shell)	가장 오래된 셸이다. POSIX 표준의 기반이다.
`bash` (Bourne Again Shell)	sh의 개선판이다. 대부분의 리눅스 배포판에서 기본 셸로 사용된다.
`zsh` (Z Shell)	bash의 기능을 확장한 셸이다. macOS의 기본 셸이다.
`dash`	Debian 계열에서 `/bin/sh`로 사용하는 경량 셸이다. 스크립트 실행 속도가 빠르다.
`fish`	사용자 친화적인 셸이다. 자동완성 기능이 강력하다.

현재 사용 중인 셸 확인:

# 현재 셸 확인
echo $SHELL

# 사용 가능한 셸 목록 확인
cat /etc/shells

터미널 (Terminal)

터미널, 콘솔, 셸 — 이 세 가지 용어는 자주 혼용되지만 엄밀히 다르다:

터미널(Terminal): 셸에 접근하기 위한 입출력 장치 또는 프로그램이다. 물리적 터미널에서 유래했으며, 현재는 소프트웨어 터미널 에뮬레이터(iTerm2, Windows Terminal, GNOME Terminal 등)를 의미한다.
콘솔(Console): 시스템에 직접 연결된 물리적 터미널이다. 서버실에서 모니터와 키보드로 직접 접속하는 것이 콘솔 접속이다.
셸(Shell): 터미널 안에서 실행되는 명령어 해석기 프로그램이다.

즉, 터미널은 창(window)이고, 셸은 그 창 안에서 동작하는 프로그램이다.

프롬프트 (Prompt) 읽는 법

터미널에 접속하면 다음과 같은 프롬프트가 표시된다:

username@hostname:~$

부분	의미
`username`	현재 로그인한 사용자 이름
`@`	구분자
`hostname`	현재 시스템의 호스트 이름
`:`	구분자
`~`	현재 위치한 디렉터리 (`~`는 홈)
`$`	일반 사용자를 의미한다. `#`이면 root(관리자) 사용자이다.

명령어 기본 구조

command [options] [arguments]

command: 실행할 명령어 (예: ls, cd, grep)
options: 명령어의 동작을 변경하는 플래그 (예: l, -all, v)
arguments: 명령어가 처리할 대상 (예: 파일명, 디렉터리명)

# 예시
ls -la /var/log
#  │  │    └── argument (대상 디렉터리)
#  │  └── options (-l: 자세히, -a: 숨김파일 포함)
#  └── command (파일 목록 출력)

옵션의 두 가지 형태

# 짧은 옵션 (하이픈 하나 + 알파벳 한 글자)
ls -l
ls -a
ls -la        # 짧은 옵션은 합칠 수 있다

# 긴 옵션 (하이픈 두 개 + 단어)
ls --long
ls --all

도움말 확인하는 방법

# 1. --help 옵션 (간략한 도움말)
ls --help

# 2. man 명령어 (상세한 매뉴얼)
man ls
# q를 누르면 종료, /키워드로 검색, n으로 다음 검색 결과 이동

# 3. tldr (커뮤니티 기반 간결한 예시 — 별도 설치 필요)
tldr ls

# 4. type 명령어 (명령어의 종류 확인)
type ls      # ls is aliased to 'ls --color=auto'
type cd      # cd is a shell builtin
type grep    # grep is /usr/bin/grep

Chapter 02. 디렉터리 구조 & 탐색

리눅스 디렉터리 구조 개요

루트 디렉터리 (/)

리눅스의 모든 디렉터리는 루트 디렉터리(/) 에서 시작한다. Windows가 C:\, D:\ 등 드라이브 문자로 구분하는 것과 달리, 리눅스는 하나의 트리(tree) 구조로 모든 파일시스템을 통합한다. 외장 디스크를 연결하든, 네트워크 드라이브를 마운트하든, 모두 이 단일 트리 아래에 위치한다.

/                     ← 루트 디렉터리 (모든 것의 시작점)
├── bin/              ← 기본 명령어
├── boot/             ← 부팅에 필요한 파일
├── dev/              ← 디바이스 파일
├── etc/              ← 시스템 설정 파일
├── home/             ← 일반 사용자 홈 디렉터리
├── lib/              ← 공유 라이브러리
├── media/            ← 이동식 미디어 마운트 포인트
├── mnt/              ← 임시 마운트 포인트
├── opt/              ← 서드파티 소프트웨어
├── proc/             ← 프로세스 정보 (가상 파일시스템)
├── root/             ← root 사용자의 홈 디렉터리
├── run/              ← 런타임 데이터
├── sbin/             ← 시스템 관리 명령어
├── srv/              ← 서비스 데이터
├── sys/              ← 커널/하드웨어 정보 (가상 파일시스템)
├── tmp/              ← 임시 파일
├── usr/              ← 사용자 프로그램 및 데이터
└── var/              ← 가변 데이터 (로그, 캐시 등)

주요 디렉터리 상세 설명

`/bin` — 필수 사용자 명령어

모든 사용자가 사용할 수 있는 필수 명령어 바이너리(실행 파일)가 위치한다.

ls /bin/
# ls, cp, mv, rm, cat, echo, grep, mkdir, chmod, chown, ps, mount ...

참고: 최신 배포판(Ubuntu 20.04+, Fedora 등)에서는 /bin이 /usr/bin의 심볼릭 링크인 경우가 많다. 이를 UsrMerge라고 하며, /bin, /sbin, /lib을 각각 /usr/bin, /usr/sbin, /usr/lib으로 통합하는 추세이다.

`/sbin` — 시스템 관리 명령어

시스템 관리에 필요한 명령어가 위치한다. 주로 root 사용자가 사용하는 명령어들이다.

ls /sbin/
# fdisk, mkfs, iptables, reboot, shutdown, ifconfig, route ...

/bin과 /sbin의 차이는 대상 사용자이다. /bin은 모든 사용자용, /sbin은 관리자용이다.

`/etc` — 시스템 설정 파일

시스템 전체에 적용되는 설정 파일(configuration files)이 위치한다.

# 주요 설정 파일들
/etc/hostname          # 시스템 호스트명
/etc/hosts             # 호스트명-IP 매핑 (로컬 DNS 역할)
/etc/resolv.conf       # DNS 서버 설정
/etc/fstab             # 파일시스템 마운트 정보 (부팅 시 자동 마운트)
/etc/passwd            # 사용자 계정 정보
/etc/shadow            # 사용자 비밀번호 (해시)
/etc/group             # 그룹 정보
/etc/sudoers           # sudo 권한 설정
/etc/ssh/sshd_config   # SSH 서버 설정
/etc/nginx/            # Nginx 웹 서버 설정 (설치 시)
/etc/systemd/          # systemd 서비스 설정
/etc/crontab           # 시스템 크론 작업
/etc/environment       # 시스템 전역 환경변수
/etc/apt/              # APT 패키지 매니저 설정 (Debian 계열)
/etc/yum.repos.d/      # YUM/DNF 저장소 설정 (Red Hat 계열)

서버 설정을 변경할 때는 거의 항상 /etc 아래의 파일을 편집하게 된다. 설정 파일을 수정하기 전에 반드시 백업하는 습관을 들여야 한다.

# 설정 파일 수정 전 백업
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)

`/home` — 일반 사용자 홈 디렉터리

각 일반 사용자의 개인 공간이다. 사용자 devops가 있다면 /home/devops가 해당 사용자의 홈 디렉터리이다.

/home/
├── devops/           # devops 사용자의 홈
│   ├── .bashrc       # bash 셸 설정 (숨김 파일)
│   ├── .ssh/         # SSH 키 저장소
│   ├── .profile      # 로그인 시 실행되는 스크립트
│   └── projects/     # 사용자가 만든 디렉터리
└── deploy/           # deploy 사용자의 홈

숨김 파일: 리눅스에서 파일명이 .(점)으로 시작하면 숨김 파일이다. ls로는 보이지 않고, ls -a를 사용해야 보인다. 사용자 설정 파일들은 대부분 숨김 파일이다.

~ (틸드): 현재 사용자의 홈 디렉터리를 나타내는 축약어이다.

# 다음 두 명령어는 동일하다 (현재 사용자가 devops인 경우)
cd /home/devops
cd ~

# 다른 사용자의 홈 디렉터리
cd ~deploy    # /home/deploy로 이동

`/var` — 가변 데이터

시스템이 운영되면서 크기가 변하는(variable) 데이터가 저장된다. 로그, 캐시, 메일, 스풀 등이 여기에 위치한다.

/var/
├── log/              # 시스템 및 애플리케이션 로그 ★★★
│   ├── syslog        # 시스템 로그 (Debian 계열)
│   ├── messages      # 시스템 로그 (Red Hat 계열)
│   ├── auth.log      # 인증 로그 (로그인, sudo 등)
│   ├── kern.log      # 커널 로그
│   ├── nginx/        # Nginx 로그
│   └── journal/      # systemd 저널 로그
├── cache/            # 애플리케이션 캐시
│   └── apt/          # APT 패키지 캐시
├── lib/              # 가변 상태 데이터
│   ├── docker/       # Docker 데이터 (이미지, 컨테이너, 볼륨)
│   └── mysql/        # MySQL 데이터
├── tmp/              # 재부팅 시에도 유지되는 임시 파일
├── spool/            # 처리 대기 중인 데이터 (메일, 프린트)
└── run/              # 실행 중인 프로세스의 런타임 데이터

/var/log는 트러블슈팅의 시작점이다. 문제가 발생하면 가장 먼저 확인하는 곳이다. /var가 위치한 파티션이 꽉 차면 시스템 전체에 문제가 생길 수 있으므로, 디스크 용량 모니터링에서 /var는 특별히 주의해야 한다.

`/proc` — 프로세스 정보 (가상 파일시스템)

/proc는 실제 디스크에 존재하는 디렉터리가 아니다. 커널이 메모리 상에서 동적으로 생성하는 가상 파일시스템이다. 현재 실행 중인 프로세스 정보와 시스템 상태를 파일 형태로 제공한다.

/proc/
├── 1/                # PID 1 (init/systemd) 프로세스 정보
│   ├── cmdline       # 프로세스 실행 명령어
│   ├── status        # 프로세스 상태 (메모리 사용량 등)
│   ├── fd/           # 열린 파일 디스크립터 목록
│   └── environ       # 프로세스 환경변수
├── cpuinfo           # CPU 정보
├── meminfo           # 메모리 정보
├── diskstats         # 디스크 I/O 통계
├── net/              # 네트워크 관련 정보
│   ├── tcp           # TCP 연결 정보
│   └── dev           # 네트워크 인터페이스 통계
├── loadavg           # 시스템 부하 평균
├── uptime            # 시스템 가동 시간
└── version           # 커널 버전 정보

# 활용 예시
cat /proc/cpuinfo       # CPU 정보 확인
cat /proc/meminfo       # 메모리 상세 정보
cat /proc/loadavg       # 시스템 부하 (load average)
cat /proc/version       # 커널 버전
cat /proc/1/cmdline     # PID 1 프로세스의 실행 명령어
ls -la /proc/self/fd    # 현재 프로세스의 열린 파일 목록

왜 중요한가: 모니터링 도구(Prometheus node_exporter, Datadog agent 등)가 시스템 메트릭을 수집할 때 바로 이 /proc 파일시스템에서 데이터를 읽는다. top, htop, free 같은 명령어도 내부적으로 /proc를 읽어서 정보를 표시한다.

`/sys` — 커널/하드웨어 정보 (가상 파일시스템)

/proc와 유사한 가상 파일시스템이지만, /sys는 커널 오브젝트와 하드웨어 장치에 대한 정보를 체계적으로 제공한다. /proc가 프로세스 중심이라면, /sys는 하드웨어/디바이스 중심이다.

# 네트워크 인터페이스 정보
ls /sys/class/net/
# eth0  lo

# 블록 디바이스(디스크) 정보
ls /sys/block/
# sda  nvme0n1

`/dev` — 디바이스 파일

하드웨어 장치를 파일로 표현한 것이다.

/dev/
├── sda               # 첫 번째 SCSI/SATA 디스크
├── sda1              # 첫 번째 디스크의 첫 번째 파티션
├── nvme0n1           # 첫 번째 NVMe SSD
├── nvme0n1p1         # NVMe SSD의 첫 번째 파티션
├── tty0              # 가상 콘솔
├── null              # 블랙홀 — 쓴 데이터는 사라진다
├── zero              # 무한히 0(null byte)을 출력한다
├── random            # 랜덤 데이터를 생성한다
└── urandom           # 비차단 랜덤 데이터 생성

특수 장치 파일의 활용:

# 출력을 버리고 싶을 때
command > /dev/null 2>&1

# 파일을 0으로 채워서 보안 삭제
dd if=/dev/zero of=file_to_wipe bs=1M count=100

# 랜덤 비밀번호 생성
cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 32

`/tmp` — 임시 파일

임시 파일을 저장하는 디렉터리이다. 재부팅하면 삭제될 수 있다 (배포판에 따라 다름).
모든 사용자가 읽고 쓸 수 있다.

# 임시 파일 생성
mktemp    # /tmp/tmp.XXXXXXXXXX 형식의 고유한 파일 생성

보안 주의: /tmp는 모든 사용자가 접근 가능하므로, 민감한 데이터를 저장하면 안 된다. Sticky Bit가 설정되어 있어서 다른 사용자의 파일은 삭제할 수 없지만, 읽기는 가능할 수 있다.

`/usr` — 사용자 프로그램 및 데이터

"Unix System Resources"의 약자이다 (User가 아니다). 시스템에 설치된 프로그램, 라이브러리, 문서 등이 위치한다.

/usr/
├── bin/              # 사용자 명령어 (대부분의 명령어가 여기에)
├── sbin/             # 시스템 관리 명령어
├── lib/              # 라이브러리
├── local/            # 로컬에서 직접 컴파일하여 설치한 소프트웨어
│   ├── bin/
│   ├── lib/
│   └── etc/
├── share/            # 아키텍처 독립적 데이터 (매뉴얼, 문서 등)
│   └── man/          # man 페이지
└── include/          # C/C++ 헤더 파일

경로 (Path)

절대 경로 (Absolute Path)

루트 디렉터리(/)부터 시작하는 전체 경로이다. 어디서든 동일한 위치를 가리킨다.

/home/devops/projects/myapp/config.yaml
/var/log/nginx/access.log
/etc/ssh/sshd_config

상대 경로 (Relative Path)

현재 위치(CWD, Current Working Directory)를 기준으로 하는 경로이다. /로 시작하지 않는다.

# 현재 /home/devops에 있다고 가정
cd projects/myapp      # /home/devops/projects/myapp로 이동
cat config.yaml        # /home/devops/projects/myapp/config.yaml

# 현재 위치에 따라 가리키는 곳이 달라진다

특수 경로 표기

표기	의미	예시
`.`	현재 디렉터리	`./script.sh` (현재 디렉터리의 스크립트 실행)
`..`	상위(부모) 디렉터리	`cd ..` (한 단계 위로 이동)
`~`	현재 사용자의 홈 디렉터리	`cd ~` → `/home/username`
`~user`	특정 사용자의 홈 디렉터리	`cd ~deploy` → `/home/deploy`
`-`	이전 디렉터리	`cd -` (직전에 있던 디렉터리로 이동)

디렉터리 탐색 명령어

`pwd` — 현재 위치 확인

Print Working Directory의 약자이다. 현재 작업 중인 디렉터리의 절대 경로를 출력한다.

$ pwd
/home/devops/projects

# 심볼릭 링크를 따르지 않고 실제 물리 경로를 표시
$ pwd -P
/data/projects    # 실제 경로 (심볼릭 링크가 아닌)

팁: 셸 스크립트에서 현재 스크립트의 위치를 기준으로 작업할 때 자주 사용한다.

# 스크립트 파일이 위치한 디렉터리로 이동
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
cd "$SCRIPT_DIR"

`cd` — 디렉터리 이동

Change Directory의 약자이다. 디렉터리를 이동하는 가장 기본적인 명령어이다.

# 기본 사용법
cd /var/log              # 절대 경로로 이동
cd nginx                 # 상대 경로로 이동 (현재 위치 기준)
cd ..                    # 상위 디렉터리로 이동
cd ../..                 # 두 단계 상위로 이동
cd ~                     # 홈 디렉터리로 이동
cd                       # 인자 없이 — 홈 디렉터리로 이동 (cd ~와 동일)
cd -                     # 이전 디렉터리로 이동 (토글)

`ls` — 디렉터리 내용 나열

List의 약자이다. 디렉터리의 내용물(파일, 하위 디렉터리)을 나열한다. 가장 자주 사용하는 명령어 중 하나이다.

ls                       # 현재 디렉터리의 내용
ls /var/log              # 특정 디렉터리의 내용
ls file.txt              # 특정 파일 정보
ls *.log                 # 와일드카드 — .log로 끝나는 파일만

주요 옵션

ls -l                    # 긴 형식 (자세한 정보)
ls -a                    # 숨김 파일(.으로 시작) 포함
ls -la                   # -l과 -a 조합 (가장 많이 사용하는 조합)
ls -lh                   # 파일 크기를 사람이 읽기 쉬운 형태로 (K, M, G)

`ls -l` 출력 상세 해석

$ ls -la /var/log/
total 12345
drwxrwxr-x  12 root   syslog  4096 Mar 23 10:30 .
drwxr-xr-x  14 root   root    4096 Jan 15 08:00 ..
-rw-r-----   1 syslog adm    98234 Mar 23 10:30 syslog
-rw-r-----   1 syslog adm   234567 Mar 22 23:59 syslog.1
drwxr-xr-x   2 root   root    4096 Mar 20 00:00 nginx
lrwxrwxrwx   1 root   root      39 Jan 15 08:00 mail.log -> /var/log/mail/current

각 필드의 의미를 분해하면:

-rw-r-----   1   syslog   adm   98234   Mar 23 10:30   syslog
│├─┤├─┤├─┤   │     │       │      │         │             │
│ │  │  │    │     │       │      │         │             └─ 파일명
│ │  │  │    │     │       │      │         └─ 최종 수정 시간
│ │  │  │    │     │       │      └─ 파일 크기 (byte)
│ │  │  │    │     │       └─ 소유 그룹
│ │  │  │    │     └─ 소유자
│ │  │  │    └─ 하드 링크 수
│ │  │  └─ 기타(other) 사용자 권한 (---)
│ │  └─ 그룹(group) 권한 (r--)
│ └─ 소유자(owner) 권한 (rw-)
└─ 파일 타입

파일 타입 문자:

문자	의미
`-`	일반 파일
`d`	디렉터리
`l`	심볼릭 링크
`c`	문자 디바이스 (터미널 등)
`b`	블록 디바이스 (디스크 등)
`s`	소켓
`p`	Named pipe (FIFO)

`tree` — 트리 구조로 표시

디렉터리 구조를 시각적인 트리 형태로 보여준다. 기본 설치가 아닌 경우가 많으므로 설치가 필요할 수 있다.

# 설치 (없는 경우)
sudo apt install tree       # Debian/Ubuntu

# 기본 사용법
tree                        # 현재 디렉터리의 트리 구조
tree /etc/nginx             # 특정 디렉터리의 트리 구조
tree -L 2                   # 깊이 2단계까지만 표시 ★
tree -d                     # 디렉터리만 표시
tree -a                     # 숨김 파일 포함
tree -h                     # 파일 크기 표시 (사람이 읽기 쉬운 형태)
tree -P "*.conf"            # 특정 패턴 파일만 표시
tree -I "node_modules|.git" # 특정 디렉터리 제외
tree --dirsfirst            # 디렉터리를 먼저 표시

`find` — 파일/디렉터리 검색

파일시스템에서 파일이나 디렉터리를 다양한 조건으로 검색하는 강력한 명령어이다.

find [검색 시작 경로] [검색 조건] [동작]

이름으로 검색

# 파일명으로 검색 (대소문자 구분)
find /etc -name "nginx.conf"

# 파일명으로 검색 (대소문자 무시)
find /etc -iname "*.CONF"

# 와일드카드 사용
find /var/log -name "*.log"
find / -name "docker-compose*.yml"

타입으로 검색

# 파일만 검색
find /home -type f -name "*.sh"

# 디렉터리만 검색
find /var -type d -name "log"

# 심볼릭 링크만 검색
find /etc -type l

크기로 검색

# 100MB 이상인 파일 검색
find / -type f -size +100M

# 1KB 미만인 파일 검색
find /tmp -type f -size -1k

# 정확히 0byte (빈 파일)
find /var/log -type f -empty

# 빈 디렉터리
find /home -type d -empty

시간으로 검색

# 최근 7일 이내에 수정된 파일
find /var/log -type f -mtime -7

# 30일 이상 된(수정되지 않은) 파일
find /tmp -type f -mtime +30

# 최근 60분 이내에 수정된 파일
find /var/log -type f -mmin -60

# 최근 1일 이내에 접근된 파일
find /home -type f -atime -1

시간 옵션:

옵션	의미	단위
`-mtime`	내용이 수정(modify)된 시간	일(day)
`-atime`	접근(access)된 시간	일(day)
`-ctime`	메타데이터가 변경(change)된 시간	일(day)
`-mmin`	내용이 수정된 시간	분(minute)
`-amin`	접근된 시간	분(minute)
`-cmin`	메타데이터가 변경된 시간	분(minute)

권한/소유자로 검색

# 권한이 777인 파일 (보안 위험 — 누구나 읽기/쓰기/실행 가능)
find / -type f -perm 777

# 소유자가 없는 파일 (사용자가 삭제된 경우)
find / -type f -nouser

# 특정 사용자 소유 파일
find /home -type f -user devops

# 특정 그룹 소유 파일
find /var -type f -group www-data

검색 결과에 동작 수행 (`exec`)

find의 가장 강력한 기능은 검색 결과에 대해 명령어를 실행할 수 있다는 것이다.

# 검색된 파일의 상세 정보 출력
find /var/log -name "*.log" -exec ls -lh {} \;

# 30일 이상 된 로그 파일 삭제
find /var/log -name "*.log" -mtime +30 -exec rm -f {} \;

# 검색된 파일의 권한을 644로 변경
find /var/www -type f -exec chmod 644 {} \;

# 검색된 디렉터리의 권한을 755로 변경
find /var/www -type d -exec chmod 755 {} \;

exec 문법 설명:
{} : 검색된 각 파일/디렉터리의 경로가 들어가는 자리이다
\; : exec 명령어의 끝을 표시한다 (세미콜론을 이스케이프)
+ : \; 대신 사용하면 검색 결과를 한 번에 전달하여 성능이 향상된다

# \; → 파일마다 명령어를 한 번씩 실행 (느림)
find /var/log -name "*.log" -exec ls -l {} \;

# + → 파일을 모아서 명령어를 한 번에 실행 (빠름)
find /var/log -name "*.log" -exec ls -l {} +

조건 조합

# AND (기본 동작 — 조건을 나열하면 AND)
find /var/log -name "*.log" -size +10M

# OR (-o 옵션)
find /etc -name "*.conf" -o -name "*.cfg"

# NOT (! 또는 -not)
find /home -type f ! -name "*.tmp"

# 복합 조건: /var/log에서 7일 이상 되고 100MB 이상인 .log 파일
find /var/log -type f -name "*.log" -mtime +7 -size +100M

실무 활용 시나리오

# 1. 디스크 정리 — 큰 파일 찾기
find / -type f -size +500M 2>/dev/null | head -20

# 2. 보안 점검 — 권한이 너무 열려있는 파일 찾기
find / -type f -perm -o+w 2>/dev/null

# 3. 최근 변경된 설정 파일 확인 (트러블슈팅)
find /etc -type f -mmin -30

# 4. 특정 확장자 파일 일괄 삭제
find /tmp -type f -name "*.tmp" -mtime +7 -delete

# 5. SUID 비트 설정된 파일 찾기 (보안 감사)
find / -type f -perm -4000 2>/dev/null

`which`, `whereis`, `type` — 명령어 위치 찾기

# which: 실행 파일의 경로 (PATH에서 검색)
$ which python3
/usr/bin/python3

$ which nginx
/usr/sbin/nginx

# whereis: 바이너리, 소스, man 페이지 위치
$ whereis nginx
nginx: /usr/sbin/nginx /etc/nginx /usr/share/nginx /usr/share/man/man8/nginx.8.gz

# type: 명령어의 종류 (alias, builtin, file 등)
$ type cd
cd is a shell builtin

$ type ls
ls is aliased to 'ls --color=auto'

$ type python3
python3 is /usr/bin/python3

which와 type의 차이:

which는 PATH 환경변수에서 실행 파일의 경로만 찾는다
type은 셸 빌트인(built-in) 명령어, 앨리어스(alias), 함수까지 구분하여 알려준다

파일시스템과 마운트 개념

파일시스템 (Filesystem)이란

파일시스템은 디스크에 데이터를 저장하고 조직하는 방식이다.
도서관에서 책을 분류하고 찾는 시스템에 비유할 수 있다.

마운트 (Mount)란

마운트는 파일시스템을 디렉터리 트리의 특정 위치에 연결하는 것이다. 리눅스에서는 디스크를 연결하면 자동으로 접근할 수 있는 것이 아니라, 반드시 특정 디렉터리에 마운트해야 한다.

물리 디스크 /dev/sdb1  ──mount──→  /data  (디렉터리 트리에 연결)

마운트 이후에는 /data 경로를 통해 해당 디스크에 접근할 수 있다.

# 현재 마운트된 파일시스템 확인
mount | column -t
df -hT

# 수동 마운트
sudo mount /dev/sdb1 /mnt/data

# 언마운트
sudo umount /mnt/data

inode와 파일시스템 내부 구조

inode란

inode(Index Node)는 파일시스템에서 파일의 메타데이터(metadata)를 저장하는 데이터 구조이다. 모든 파일과 디렉터리는 하나의 inode를 가진다.

inode에 저장되는 정보:

파일 타입 (일반 파일, 디렉터리, 심볼릭 링크 등)
권한 (permissions)
소유자 (UID)와 그룹 (GID)
파일 크기
타임스탬프 (생성, 수정, 접근 시간)
하드 링크 수
데이터 블록의 위치 (포인터)

중요: inode에는 파일 이름이 저장되지 않는다. 파일 이름은 디렉터리 엔트리에 저장된다. 디렉터리란 본질적으로 "파일명 ↔ inode 번호"의 매핑 테이블이다.

# 파일의 inode 번호 확인
ls -i /etc/hostname
# 131074 /etc/hostname

# 상세 inode 정보 확인
stat /etc/hostname
#   File: /etc/hostname
#   Size: 12          Blocks: 8          IO Block: 4096   regular file
# Device: 801h/2049d  Inode: 131074      Links: 1
# Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
# Access: 2025-03-23 10:00:00.000000000 +0900
# Modify: 2025-01-15 08:00:00.000000000 +0900
# Change: 2025-01-15 08:00:00.000000000 +0900

Chapter 03. 파일 & 디렉터리 관리

파일과 디렉터리의 기본 개념

리눅스에서 파일은 바이트(byte)의 연속된 스트림이다. Windows와 달리 리눅스는 파일 확장자에 의존하지 않는다. .txt, .log, .conf 같은 확장자는 사람이 파일의 용도를 구분하기 위한 관례(convention)일 뿐이며, 시스템이 파일의 종류를 결정하는 기준은 아니다.

파일명 규칙

리눅스 파일명은 Windows보다 자유도가 높지만, 알아두어야 할 규칙이 있다:

대소문자를 구분한다: File.txt와 file.txt는 다른 파일이다
최대 255자까지 가능하다 (ext4 기준)
거의 모든 문자를 사용할 수 있다: 사용할 수 없는 문자는 /(경로 구분자)와 NULL(문자열 종결자)뿐이다
.으로 시작하면 숨김 파일이다: .bashrc, .ssh/, .gitignore 등
공백과 특수문자는 피하는 것이 좋다: 셸 스크립트에서 문제를 일으킬 수 있다

# 공백이 포함된 파일명 다루기 (반드시 따옴표 사용)
ls "my file.txt"
rm "my file.txt"

# 하이픈(-)으로 시작하는 파일명 다루기 (옵션으로 인식되는 문제)
rm -- -filename       # -- 이후는 옵션이 아님을 표시
rm ./-filename        # 상대 경로로 지정

타임스탬프 (Timestamps)

리눅스의 모든 파일은 세 가지 타임스탬프를 가진다:

타임스탬프	약자	설명	변경되는 시점
Modify time (mtime)	m	파일 내용이 마지막으로 변경된 시간	파일에 데이터를 쓸 때
Access time (atime)	a	파일이 마지막으로 읽힌 시간	파일을 읽을 때 (cat, less 등)
Change time (ctime)	c	파일의 메타데이터가 마지막으로 변경된 시간	권한, 소유자, 이름 변경 시

# stat 명령어로 세 가지 타임스탬프 확인
$ stat config.yaml
  File: config.yaml
  Size: 1234        Blocks: 8          IO Block: 4096   regular file
Access: 2025-03-23 14:30:00.000000000 +0900
Modify: 2025-03-20 09:15:00.000000000 +0900
Change: 2025-03-20 09:15:00.000000000 +0900
 Birth: 2025-03-01 10:00:00.000000000 +0900

참고: 생성 시간(Birth/Creation time)은 전통적인 UNIX에는 없었으나, ext4와 최신 커널에서는 지원한다. stat 명령어의 Birth 필드에서 확인할 수 있다.

noatime 마운트 옵션: 서버 환경에서는 /etc/fstab에 noatime 옵션을 설정하여 atime 업데이트를 비활성화하는 경우가 많다. 파일을 읽을 때마다 디스크에 쓰기(atime 업데이트)가 발생하면 성능 저하의 원인이 되기 때문이다.

디렉터리 생성 — `mkdir`

기본 사용법

Make Directory의 약자이다. 새 디렉터리를 생성한다.

# 단일 디렉터리 생성
mkdir projects

# 여러 디렉터리 한 번에 생성
mkdir dir1 dir2 dir3

# 중첩 디렉터리 한 번에 생성 (-p 옵션) ★★★
mkdir -p projects/backend/src/main
# -p 없이 하면 상위 디렉터리가 없으면 에러 발생
# mkdir: cannot create directory 'projects/backend/src/main': No such file or directory

Brace Expansion을 활용한 구조 생성

셸의 Brace Expansion({}) 기능을 활용하면 복잡한 디렉터리 구조를 한 줄로 생성할 수 있다.

# 프로젝트 기본 구조 한 번에 생성
mkdir -p myapp/{src,test,docs,config,scripts}

# 더 복잡한 구조
mkdir -p myapp/{src/{main,lib},test/{unit,integration},deploy/{dev,staging,prod}}

# 결과 확인
$ tree myapp/
myapp/
├── deploy
│   ├── dev
│   ├── prod
│   └── staging
├── src
│   ├── lib
│   └── main
└── test
    ├── integration
    └── unit

파일 생성

`touch` — 빈 파일 생성 / 타임스탬프 변경

touch의 원래 목적은 파일의 타임스탬프를 변경하는 것이다. 하지만 대상 파일이 존재하지 않으면 빈 파일을 생성하기 때문에, 빈 파일 생성 용도로도 자주 사용한다.

# 빈 파일 생성
touch newfile.txt

# 여러 파일 한 번에 생성
touch file1.txt file2.txt file3.txt

# Brace Expansion 활용
touch log-{01..12}.txt
# log-01.txt log-02.txt ... log-12.txt 생성

리다이렉션으로 파일 생성

# 빈 파일 생성 (touch과 동일한 효과)
> newfile.txt

# 내용이 있는 파일 생성
echo "Hello, World!" > hello.txt

# 여러 줄 파일 생성 (Here Document)
cat << EOF > config.yaml
server:
  host: 0.0.0.0
  port: 8080
database:
  host: localhost
  port: 5432
EOF

Here Document (<< EOF): EOF(End Of File)는 구분자이며, 임의의 문자열을 사용할 수 있다. 여기서부터 같은 구분자가 나올 때까지의 내용이 입력으로 전달된다. 설정 파일을 스크립트로 생성할 때 매우 유용하다.

복사 — `cp`

Copy의 약자이다. 파일이나 디렉터리를 복사한다.

# 파일 복사
cp source.txt destination.txt

# 파일을 다른 디렉터리로 복사
cp config.yaml /tmp/

# 파일을 다른 디렉터리로 복사하면서 이름 변경
cp config.yaml /tmp/config.yaml.bak

활용 패턴

# 1. 설정 파일 백업 (날짜 포함) ★★★
cp -p /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d_%H%M%S)

# 2. 디렉터리 전체 백업 (메타데이터 보존)
cp -a /var/www/html/ /backup/www-$(date +%Y%m%d)/

# 3. 여러 파일을 디렉터리로 복사
cp file1.txt file2.txt file3.txt /destination/

# 4. 와일드카드로 특정 파일만 복사
cp /var/log/*.log /backup/logs/

# 5. 빈 디렉터리 구조만 복사 (find + mkdir 조합)
cd /source && find . -type d -exec mkdir -p /dest/{} \;

`cp`의 동작 원리

cp는 원본 파일의 데이터를 읽어서 새로운 inode를 가진 새 파일을 생성한다. 즉, 원본과 복사본은 완전히 독립적인 파일이다. 한쪽을 수정해도 다른 쪽에 영향이 없다.

이동 / 이름 변경 — `mv`

Move의 약자이다. 파일이나 디렉터리를 이동하거나 이름을 변경한다. 리눅스에는 별도의 "rename" 명령어가 기본 제공되지 않으며, mv가 이름 변경 기능을 겸한다.

# 파일 이름 변경
mv old_name.txt new_name.txt

# 파일을 다른 디렉터리로 이동
mv report.pdf /home/devops/documents/

# 이동하면서 이름 변경
mv config.yaml /etc/myapp/application.yaml

# 디렉터리 이름 변경 (디렉터리도 동일하게 동작)
mv old_dir/ new_dir/

# 디렉터리를 다른 위치로 이동
mv projects/ /opt/

삭제 — `rm`, `rmdir`

`rm` — 파일/디렉터리 삭제

Remove의 약자이다. 파일이나 디렉터리를 삭제한다.

⚠️ 경고: 리눅스에는 휴지통(Recycle Bin)이 없다. rm으로 삭제한 파일은 복구가 매우 어렵다. 특히 rm -rf는 확인 없이 재귀적으로 모든 것을 삭제하므로 극도로 주의해야 한다.

# 파일 삭제
rm file.txt

# 여러 파일 삭제
rm file1.txt file2.txt file3.txt

# 와일드카드로 삭제
rm *.tmp
rm *.log

`rmdir` — 빈 디렉터리만 삭제

rmdir은 비어있는 디렉터리만 삭제할 수 있다. 내용물이 있으면 에러가 발생한다.

# 빈 디렉터리 삭제
rmdir empty_dir/

# 에러 발생 — 디렉터리가 비어있지 않음
rmdir non_empty_dir/
# rmdir: failed to remove 'non_empty_dir/': Directory not empty

# -p : 빈 상위 디렉터리까지 함께 삭제
rmdir -p a/b/c/     # c, b, a 순서로 삭제 (모두 비어있어야 함)

안전한 삭제 습관

# 1. 삭제 전에 항상 먼저 ls로 확인
ls /var/log/*.log.1          # 삭제 대상 확인
rm /var/log/*.log.1          # 확인 후 삭제

# 2. rm -rf를 사용할 때는 경로를 절대 변수에 넣지 말 것
# 위험한 패턴 — 변수가 비어있으면 / 를 삭제하게 된다
rm -rf ${DIR}/               # DIR이 빈 문자열이면 rm -rf / 실행 ☠️

# 안전한 패턴
rm -rf "${DIR:?Variable is not set}/"   # 변수가 비어있으면 에러 발생

# 3. 삭제 대신 이동으로 대체 (안전한 삭제 패턴)
mv old_files/ /tmp/trash/    # 나중에 확인 후 /tmp는 재부팅 시 자동 삭제

# 4. interactive 옵션 활용
alias rm='rm -i'             # 별칭 설정 (모든 rm에 확인 절차 추가)

# 5. 중요한 작업 전에 pwd 확인
pwd                          # 현재 위치가 맞는지 확인
rm -rf build/                # 그 후에 삭제

`wc` — 파일 통계

Word Count의 약자이다. 파일의 줄 수, 단어 수, 바이트 수를 출력한다.

$ wc /etc/passwd
  42   68  2156  /etc/passwd
#  │    │    │
#  │    │    └─ 바이트 수
#  │    └─ 단어 수
#  └─ 줄 수

# 줄 수만 출력 (-l: lines) ★ 가장 자주 사용
wc -l /var/log/syslog
# 15234 /var/log/syslog

# 단어 수만 출력 (-w: words)
wc -w document.txt

# 바이트 수만 출력 (-c: bytes)
wc -c data.bin

# 문자 수만 출력 (-m: characters, 멀티바이트 문자 지원)
wc -m korean_text.txt

# 여러 파일의 줄 수 확인
wc -l /var/log/*.log
#   1234 /var/log/auth.log
#   5678 /var/log/syslog
#    234 /var/log/kern.log
#   7146 total

# 파이프와 조합 — 프로세스 수 세기
ps aux | wc -l

와일드카드 (Globbing)

셸에서 파일명 패턴을 매칭하는 특수 문자를 와일드카드(wildcard) 또는 글로빙(globbing)이라고 한다. find의 정규표현식과는 다른 개념이다. 와일드카드는 셸이 명령어를 실행하기 전에 파일명으로 확장(expand)한다.

기본 와일드카드

패턴	의미	예시
`*`	0개 이상의 임의의 문자	`*.log` → error.log, access.log
`?`	정확히 1개의 임의의 문자	`file?.txt` → file1.txt, fileA.txt
`[abc]`	괄호 안의 문자 중 하나	`file[123].txt` → file1.txt, file2.txt
`[a-z]`	범위 내의 문자 중 하나	`file[a-c].txt` → filea.txt, fileb.txt
`[!abc]` 또는 `[^abc]`	괄호 안의 문자가 아닌 것	`file[!0-9].txt` → filea.txt

확장 글로빙 (bash)

bash에서는 extglob 옵션으로 더 강력한 패턴 매칭을 사용할 수 있다.

# extglob 활성화 (보통 기본 활성화)
shopt -s extglob

# ?(pattern)  : 패턴이 0번 또는 1번
# *(pattern)  : 패턴이 0번 이상
# +(pattern)  : 패턴이 1번 이상
# @(pattern)  : 패턴이 정확히 1번
# !(pattern)  : 패턴에 매치되지 않는 것

# .log와 .tmp를 제외한 모든 파일
ls !(*.log|*.tmp)

# .conf 또는 .yaml 파일만
ls *.@(conf|yaml)

Brace Expansion (`{}`)

와일드카드와는 다른 메커니즘이지만, 파일 관리에서 매우 유용하다. 글로빙은 존재하는 파일을 매칭하지만, Brace Expansion은 문자열을 생성한다.

# 문자열 목록 생성
echo {apple,banana,cherry}
# apple banana cherry

# 범위 생성
echo {1..10}
# 1 2 3 4 5 6 7 8 9 10

echo {a..z}
# a b c d e f g h i j k l m n o p q r s t u v w x y z

echo {01..12}
# 01 02 03 04 05 06 07 08 09 10 11 12

# 증가값 지정
echo {0..100..10}
# 0 10 20 30 40 50 60 70 80 90 100

# 실무 활용
# 1. 파일 백업
cp config.yaml{,.bak}           # config.yaml → config.yaml.bak으로 복사
# 확장: cp config.yaml config.yaml.bak

# 2. 여러 디렉터리 생성
mkdir -p project/{src,test,docs,build}

# 3. 확장자 변경 (rename 효과)
mv report.{txt,md}              # report.txt → report.md
# 확장: mv report.txt report.md

복수 파일/디렉터리 일괄 처리

`xargs` — 표준 입력을 명령어 인자로 변환

xargs는 파이프를 통해 전달된 표준 입력(stdin)을 명령어의 인자(argument)로 변환한다. find와 함께 사용하면 매우 강력하다.

# find 결과를 xargs로 전달
find /tmp -name "*.tmp" -mtime +7 | xargs rm -f

# 파일명에 공백이 있을 때 안전하게 처리 ★★★
find /tmp -name "*.tmp" -print0 | xargs -0 rm -f
# -print0: null 문자로 구분
# -0: null 문자를 구분자로 인식

# 한 번에 처리할 인자 수 제한
find . -name "*.log" | xargs -n 5 ls -l
# 5개씩 묶어서 ls -l 실행

# 자리 표시자(placeholder) 사용 (-I)
find . -name "*.conf" | xargs -I {} cp {} /backup/{}.bak

# 병렬 처리 (-P: 동시 실행할 프로세스 수)
find . -name "*.png" | xargs -P 4 -I {} convert {} -resize 50% resized_{}

`find` + `exec` vs `xargs` 비교

# find -exec: 파일 하나씩 명령어 실행
find . -name "*.log" -exec gzip {} \;

# find -exec +: 가능한 많은 파일을 한 번에 전달
find . -name "*.log" -exec gzip {} +

# xargs: find의 출력을 파이프로 받아서 전달
find . -name "*.log" | xargs gzip

일반적으로 xargs가 -exec \;보다 빠르다. -exec +와 xargs는 성능이 비슷하다. 파일명에 특수문자(공백, 개행)가 있을 수 있다면 find -print0 | xargs -0 조합을 사용하는 것이 가장 안전하다.

핵심 원칙 정리

삭제 전에 반드시 ls로 확인한다
설정 파일 수정 전에 반드시 백업한다 (cp -p file file.bak.$(date +%Y%m%d))
rm -rf에 변수를 사용할 때는 변수가 비어있지 않은지 검증한다
파일명에 공백이 있을 수 있으면 find -print0 | xargs -0 조합을 사용한다
같은 파티션의 mv는 즉시, 다른 파티션의 mv는 시간이 걸린다는 점을 기억한다
rm은 unlink이다 — 프로세스가 파일을 잡고 있으면 공간이 해제되지 않는다

Chapter 04. 파일 내용 확인 & 검색

파일 내용을 확인하는 방법

리눅스에서 파일 내용을 확인하는 명령어는 여러 가지가 있다.

상황	적합한 명령어
짧은 파일 전체 보기	`cat`
긴 파일을 페이지 단위로 읽기	`less`
파일의 앞/뒤 일부만 보기	`head`, `tail`
실시간 로그 모니터링	`tail -f`
파일 간 차이 빠르게 비교	`diff`

`cat` — 파일 전체 출력

Concatenate의 약자이다. 원래 목적은 여러 파일을 연결(concatenate)하여 출력하는 것이지만, 단일 파일의 내용을 확인하는 용도로 가장 흔히 사용한다.

# 파일 내용 출력
cat /etc/hostname

# 줄 번호와 함께 출력
cat -n /etc/passwd

# 빈 줄을 제외하고 줄 번호 표시
cat -b /etc/ssh/sshd_config

# 여러 파일 연결하여 출력
cat header.txt body.txt footer.txt

# 여러 파일을 하나로 합치기
cat part1.log part2.log part3.log > combined.log

언제 쓰고, 언제 쓰지 말아야 하는가:

수십 줄 이하의 짧은 파일 → cat 적합
수백~수천 줄 이상의 파일 → cat은 부적합 (터미널이 스크롤로 넘쳐버린다). less를 사용한다.

`tac` — 역순 출력

cat의 철자를 뒤집은 이름 그대로, 파일의 마지막 줄부터 거꾸로 출력한다.

# 최신 로그가 아래에 쌓이는 파일을 역순으로 보기
tac /var/log/auth.log | head -20

`less` — 페이지 단위 탐색

less는 파일 내용을 페이지 단위로 스크롤하며 읽을 수 있는 뷰어(pager)이다. more라는 오래된 명령어의 개선판이며, 이름은 "less is more"라는 말장난에서 유래했다.

less /var/log/syslog
less +G /var/log/syslog    # 파일 끝부터 열기

`less` 내부 조작 키

less는 열린 상태에서 다양한 키로 탐색할 수 있다. 외울 필요 없이, 자주 쓰는 것만 알면 된다:

키	동작
`Space` / `f`	한 페이지 아래로
`b`	한 페이지 위로
`j` / `k`	한 줄 아래 / 위로
`G`	파일 끝으로 이동
`g`	파일 처음으로 이동
`/키워드`	아래 방향으로 검색
`?키워드`	위 방향으로 검색
`n`	다음 검색 결과
`N`	이전 검색 결과
`q`	종료
`&패턴`	패턴이 포함된 줄만 표시 (필터)

실무 팁: less의 / 검색은 로그 파일에서 특정 에러 메시지를 찾을 때 매우 유용하다. &ERROR를 입력하면 "ERROR"가 포함된 줄만 필터링하여 볼 수 있다.

`more`와의 차이

more는 앞으로만 스크롤할 수 있고, less는 앞뒤로 자유롭게 이동할 수 있다. 사실상 less만 사용한다고 보면 된다.

`head`와 `tail` — 파일의 앞/뒤 확인

`head` — 파일 앞부분

# 기본: 처음 10줄 출력
head /etc/passwd

# 줄 수 지정
head -n 20 /var/log/syslog
head -20 /var/log/syslog       # 동일 (축약형)

# 바이트 수 지정
head -c 100 binary_file        # 처음 100바이트

`tail` — 파일 뒷부분

# 기본: 마지막 10줄 출력
tail /var/log/syslog

# 줄 수 지정
tail -n 50 /var/log/syslog
tail -50 /var/log/syslog       # 동일

# 특정 줄부터 끝까지 (+N: N번째 줄부터)
tail -n +100 /etc/passwd       # 100번째 줄부터 끝까지

`tail -f` — 실시간 로그 모니터링 ★★★

tail -f는 가장 자주 사용하는 명령어 조합 중 하나이다. 파일에 새로운 내용이 추가되면 실시간으로 화면에 표시한다.

# 실시간 로그 모니터링
tail -f /var/log/syslog

# 여러 파일 동시 모니터링
tail -f /var/log/nginx/access.log /var/log/nginx/error.log

# 특정 키워드만 필터링하며 모니터링
tail -f /var/log/syslog | grep --line-buffered "error"

f vs F의 차이:

옵션	동작
`-f`	파일 디스크립터를 추적한다. 파일이 삭제되고 재생성되면 추적이 끊긴다.
`-F`	파일 이름을 추적한다. 로그 로테이션으로 파일이 교체되어도 계속 추적한다.

실무에서는 로그 로테이션(logrotate)이 적용된 환경이 대부분이므로, tail -F를 사용하는 것이 더 안전하다.

# 로그 로테이션 환경에서 안전한 모니터링
tail -F /var/log/nginx/access.log

파일 내용 가공 출력

`cut` — 필드/컬럼 추출

cut은 텍스트에서 특정 필드(열)만 잘라내는 명령어이다. CSV나 구분자 기반 파일을 다룰 때 유용하다.

# /etc/passwd에서 사용자명(1번째 필드)만 추출
# /etc/passwd는 : 으로 필드가 구분된다
cut -d ':' -f 1 /etc/passwd

# 1번, 3번 필드 (사용자명, UID)
cut -d ':' -f 1,3 /etc/passwd

# 1~4번 필드 (범위)
cut -d ':' -f 1-4 /etc/passwd

# CSV 파일에서 2번째 컬럼 추출
cut -d ',' -f 2 data.csv

# 문자 위치 기준으로 추출 (고정 폭 데이터)
cut -c 1-10 fixed_width.txt    # 1~10번째 문자

주요 옵션:

d : 구분자(delimiter) 지정 (기본값: TAB)
f : 추출할 필드 번호
c : 추출할 문자 위치

`tr` — 문자 변환/삭제

Translate의 약자이다. 문자를 다른 문자로 치환하거나 삭제한다. 주의할 점은, tr은 파일을 직접 읽지 못하고 반드시 표준 입력(stdin)으로 데이터를 받아야 한다.

# 소문자 → 대문자 변환
echo "hello world" | tr 'a-z' 'A-Z'
# HELLO WORLD

# 공백을 줄바꿈으로 변환 (단어를 한 줄에 하나씩)
echo "one two three" | tr ' ' '\n'

# 특정 문자 삭제 (-d)
echo "Hello, World! 123" | tr -d '0-9'
# Hello, World!

# 연속된 중복 문자를 하나로 압축 (-s: squeeze)
echo "hello     world" | tr -s ' '
# hello world

# 실무: 로그에서 탭을 쉼표로 변환 (TSV → CSV)
cat data.tsv | tr '\t' ',' > data.csv

`nl` — 줄 번호 추가

# 줄 번호를 붙여서 출력 (빈 줄 제외)
nl /etc/ssh/sshd_config

# 빈 줄에도 번호 부여
nl -ba /etc/ssh/sshd_config

표준 스트림 (Standard Streams)

리눅스의 모든 프로세스는 실행될 때 3개의 기본 스트림을 자동으로 부여받는다:

┌─────────────────────────────────────────────────┐
│                  프로세스                         │
│                                                 │
│  stdin (fd 0)  ──→  [처리]  ──→  stdout (fd 1)   │
│                            ──→  stderr (fd 2)   │
└─────────────────────────────────────────────────┘

스트림	파일 디스크립터(fd)	설명	기본 연결
stdin (표준 입력)	0	프로세스가 데이터를 읽어오는 통로	키보드
stdout (표준 출력)	1	프로세스가 정상 결과를 내보내는 통로	터미널 화면
stderr (표준 에러)	2	프로세스가 에러 메시지를 내보내는 통로	터미널 화면

파일 디스크립터(File Descriptor, fd)란 커널이 열린 파일(스트림 포함)을 관리하기 위해 부여하는 정수 번호이다. 0, 1, 2는 예약된 번호이고, 이후 열리는 파일은 3, 4, 5... 순서로 번호가 부여된다.

왜 stdout과 stderr가 분리되어 있는가:

정상 출력과 에러 메시지를 독립적으로 처리할 수 있기 때문이다.

# 정상 출력은 파일에 저장하고, 에러만 화면에 표시
find / -name "*.conf" > result.txt 2>&1
# 1(stdout) → result.txt
# 2(stderr) → 화면에 표시 (권한 없는 디렉터리 접근 에러 등)

# 에러 메시지만 파일에 저장
find / -name "*.conf" 2> errors.txt

# 에러를 아예 무시
find / -name "*.conf" 2>/dev/null

`grep` — 패턴으로 텍스트 검색

grep은 Global Regular Expression Print의 약자이다. 파일에서 특정 패턴(문자열)이 포함된 줄을 검색하여 출력한다. 가장 많이 사용되는 명령어 중 하나이며, 로그 분석과 트러블슈팅의 핵심 도구이다.

기본 사용법

# 파일에서 문자열 검색
grep "error" /var/log/syslog

# 대소문자 무시 (-i)
grep -i "error" /var/log/syslog

# 줄 번호 함께 표시 (-n)
grep -n "error" /var/log/syslog

# 매치된 줄 수만 출력 (-c)
grep -c "error" /var/log/syslog

# 패턴이 포함되지 않은 줄만 출력 (-v: invert)
grep -v "^#" /etc/ssh/sshd_config     # 주석(#) 제외

# 디렉터리 내 모든 파일에서 재귀 검색 (-r)
grep -r "database_url" /etc/myapp/

# 매치된 파일명만 출력 (-l)
grep -rl "TODO" ./src/

주변 줄 함께 보기 (Context)

에러 로그를 검색할 때, 에러가 발생한 줄만 보면 맥락을 파악하기 어렵다. 주변 줄을 함께 보면 원인을 파악하기 쉽다.

# 매치된 줄 + 아래 3줄 (-A: After)
grep -A 3 "Exception" /var/log/app.log

# 매치된 줄 + 위 3줄 (-B: Before)
grep -B 3 "Exception" /var/log/app.log

# 매치된 줄 + 위아래 3줄 (-C: Context)
grep -C 3 "Exception" /var/log/app.log

자주 쓰는 패턴

# 설정 파일에서 주석과 빈 줄 제거하고 실제 설정만 보기
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

# 로그에서 특정 시간대의 에러 검색
grep "2025-03-23 14:" /var/log/syslog | grep -i "error"

# 특정 IP의 접속 로그 검색
grep "192.168.1.100" /var/log/nginx/access.log

# 프로세스 목록에서 특정 프로세스 찾기
ps aux | grep nginx | grep -v grep

요약

명령어	용도	핵심 포인트
`cat`	짧은 파일 전체 출력, 파일 연결	긴 파일에는 부적합
`less`	긴 파일 페이지 탐색	`/`로 검색, `&`로 필터
`head`	파일 앞부분 확인	`-n N`으로 줄 수 지정
`tail`	파일 뒷부분 확인	`-F`로 실시간 모니터링
`cut`	필드/컬럼 추출	`-d`(구분자) + `-f`(필드)
`tr`	문자 변환/삭제	stdin으로만 입력 받음
`grep`	패턴 검색	`-i`, `-r`, `-v`, `-C` 가 핵심
`strings`	바이너리에서 텍스트 추출	파일 정체 파악에 유용

Chapter 05. 링크 (심볼릭 링크, 하드 링크)

리눅스에서 링크(Link)란 하나의 파일에 대해 여러 이름(경로)을 부여하는 메커니즘이다. Windows의 "바로가기"와 유사하지만, 동작 방식이 근본적으로 다르다.

파일의 실제 데이터와 메타데이터는 inode에 저장된다
파일 이름은 inode에 저장되지 않는다
디렉터리란 "파일명 → inode 번호"의 매핑 테이블이다

디렉터리 엔트리 (매핑 테이블)
┌──────────────────────────────┐
│  파일명         → inode 번호    │
│  config.yaml   → 131074      │
│  readme.md     → 131075      │
│  deploy.sh     → 131076      │
└──────────────────────────────┘

inode 테이블
┌──────────────────────────────────────────┐
│  inode 131074: 권한, 소유자, 크기, 데이터 위치  │
│  inode 131075: 권한, 소유자, 크기, 데이터 위치  │
│  inode 131076: 권한, 소유자, 크기, 데이터 위치  │
└──────────────────────────────────────────┘

링크란 이 매핑 관계를 추가로 만드는 것이다.

하드 링크 (Hard Link)

하드 링크는 동일한 inode를 가리키는 새로운 디렉터리 엔트리를 만드는 것이다. 원본과 하드 링크는 완전히 동등한 관계이며, 어느 쪽이 "원본"이고 어느 쪽이 "링크"인지 구분할 수 없다.

원본 생성 후:
  "config.yaml"  ──→  inode 131074  ──→  [디스크의 실제 데이터]
                       (Links: 1)

하드 링크 생성 후:
  "config.yaml"  ──→  inode 131074  ──→  [디스크의 실제 데이터]
  "config.bak"   ──→  inode 131074  ──→  (같은 데이터를 가리킴)
                       (Links: 2)

두 파일명이 동일한 inode(동일한 데이터)를 가리킨다
어느 쪽을 수정해도 양쪽 모두 반영된다 (같은 데이터이므로)
한쪽을 삭제해도 다른 쪽은 영향 없다 (inode의 링크 카운트가 0이 되어야 데이터가 삭제된다)
디스크 공간을 추가로 차지하지 않는다 (데이터 복제가 아니므로)

생성 및 확인

# 하드 링크 생성
ln original.txt hardlink.txt

# inode 번호 확인 — 동일한 번호를 가진다
ls -li original.txt hardlink.txt
# 131074 -rw-r--r-- 2 devops devops 1234 Mar 23 10:00 hardlink.txt
# 131074 -rw-r--r-- 2 devops devops 1234 Mar 23 10:00 original.txt
#   │                 │
#   └ 같은 inode      └ Links: 2 (하드 링크 수)

# 한쪽 수정 → 양쪽 반영 확인
echo "new content" >> original.txt
cat hardlink.txt    # "new content"가 보인다

# 한쪽 삭제 → 다른 쪽은 살아있다
rm original.txt
cat hardlink.txt    # 여전히 정상 접근 가능
ls -li hardlink.txt
# 131074 -rw-r--r-- 1 devops devops ...    ← Links가 2→1로 줄어듦

제약사항

제약	이유
디렉터리에는 하드 링크를 만들 수 없다	순환 참조(circular reference)가 발생하면 파일시스템이 무한 루프에 빠질 수 있다
다른 파일시스템(파티션)을 넘어서 만들 수 없다	inode 번호는 파일시스템 내에서만 유일하다. 다른 파일시스템의 inode와는 연결할 수 없다

심볼릭 링크 (Symbolic Link / Symlink)

심볼릭 링크는 다른 파일의 경로(문자열)를 저장하는 별도의 파일이다. 하드 링크와 달리 자체 inode를 가지며, 그 안에 "원본 파일의 경로"를 텍스트로 저장한다.

심볼릭 링크 생성 후:
  "config.yaml"       ──→  inode 131074  ──→  [실제 데이터]
  "config-link.yaml"  ──→  inode 131099  ──→  "/home/devops/config.yaml" (경로 문자열)
                             (타입: symlink)

Windows의 "바로가기"와 가장 유사한 개념이다. 다만 리눅스의 심볼릭 링크는 OS 수준에서 투명하게 동작하므로, 대부분의 프로그램이 심볼릭 링크를 원본 파일처럼 취급한다.

생성 및 확인

# 심볼릭 링크 생성 (-s 옵션)
ln -s /etc/nginx/nginx.conf ~/nginx-config

# 확인
ls -la ~/nginx-config
# lrwxrwxrwx 1 devops devops 21 Mar 23 10:00 nginx-config -> /etc/nginx/nginx.conf
# │                            │                              │
# └ 타입: l (심볼릭 링크)        └ 링크 파일 자체의 크기           └ 가리키는 원본 경로
#                                (경로 문자열의 길이)

# 심볼릭 링크를 통해 원본 파일 읽기
cat ~/nginx-config    # /etc/nginx/nginx.conf의 내용이 출력된다

# 디렉터리에도 심볼릭 링크 생성 가능
ln -s /var/log/nginx ~/logs
ls ~/logs/            # /var/log/nginx/의 내용이 보인다

# 다른 파일시스템(파티션)을 넘어서도 생성 가능
ln -s /mnt/external/data ~/external-data

끊어진 심볼릭 링크 (Dangling Symlink)

심볼릭 링크의 가장 큰 약점은 원본이 삭제되면 링크가 끊어진다는 것이다. 끊어진 심볼릭 링크를 dangling symlink이라고 한다.

# 원본 생성 → 심볼릭 링크 생성 → 원본 삭제
touch /tmp/original.txt
ln -s /tmp/original.txt ~/my-link
rm /tmp/original.txt

# 끊어진 링크 — 접근하면 에러
cat ~/my-link
# cat: /home/devops/my-link: No such file or directory

# ls에서 끊어진 링크는 빨간색으로 표시된다 (색상 지원 터미널)
ls -la ~/my-link
# lrwxrwxrwx 1 devops devops 17 Mar 23 10:00 my-link -> /tmp/original.txt (빨간색)

# 끊어진 심볼릭 링크 찾기
find /home -type l ! -exec test -e {} \; -print

실무에서의 심볼릭 링크 활용

Nginx 사이트 활성화/비활성화

Nginx의 가상 호스트 관리는 심볼릭 링크의 대표적 활용 사례이다.

# 사이트 설정은 sites-available에 저장
/etc/nginx/sites-available/mysite.conf    # 설정 파일 (원본)

# 활성화: sites-enabled에 심볼릭 링크 생성
sudo ln -s /etc/nginx/sites-available/mysite.conf /etc/nginx/sites-enabled/

# 비활성화: 심볼릭 링크만 삭제 (원본은 보존)
sudo rm /etc/nginx/sites-enabled/mysite.conf

장점: 설정 파일 자체를 삭제하지 않고도 사이트를 활성화/비활성화할 수 있다.

무중단 배포 (Zero-Downtime Deployment)

# 디렉터리 구조
/opt/myapp/
├── releases/
│   ├── v1.0.0/          # 이전 버전
│   ├── v1.1.0/          # 이전 버전
│   └── v1.2.0/          # 새 버전
└── current -> releases/v1.1.0   # 현재 운영 중인 버전 (심볼릭 링크)

# 배포: 심볼릭 링크만 교체 (거의 즉시 완료)
ln -sfn /opt/myapp/releases/v1.2.0 /opt/myapp/current
#  -s: 심볼릭 링크
#  -f: 기존 링크 덮어쓰기
#  -n: 대상이 디렉터리여도 링크 자체를 교체 (안으로 들어가지 않음)

# 롤백: 이전 버전으로 링크만 되돌리기 (즉시 완료)
ln -sfn /opt/myapp/releases/v1.1.0 /opt/myapp/current

웹 서버의 DocumentRoot가 /opt/myapp/current를 가리키고 있다면, 심볼릭 링크 교체만으로 배포와 롤백이 거의 즉시 이루어진다.

요약

개념	핵심 내용
하드 링크	동일한 inode를 공유, 원본 삭제해도 데이터 유지, 같은 파티션만 가능
심볼릭 링크	별도 inode, 경로 문자열 저장, 파티션/디렉터리 제약 없음, 원본 삭제 시 끊어짐
실무 기본 선택	심볼릭 링크 (99%의 경우)
핵심 활용	Nginx sites-enabled, 무중단 배포, 바이너리 버전 관리
생성 명령어	`ln` (하드), `ln -s` (심볼릭), `ln -sfn` (덮어쓰기)
주의사항	심볼릭 링크 디렉터리 삭제 시 `/` 붙이지 않기

Chapter 06. 압축 & 아카이브

아카이브와 압축의 차이

아카이브

여러 파일과 디렉터리를 하나의 파일로 묶는 것이다. 파일의 크기를 줄이지는 않는다. 마치 여러 서류를 하나의 봉투에 넣는 것과 같다.

압축

데이터의 크기를 줄이는 것이다. 반복되는 패턴을 효율적으로 인코딩하여 파일 크기를 감소시킨다.

[파일A] [파일B] [파일C]
         │
    아카이브 (tar)
         ↓
  [파일A+B+C.tar]        ← 크기는 거의 동일 (묶기만 함)
         │
      압축 (gzip)
         ↓
  [파일A+B+C.tar.gz]     ← 크기가 줄어듦

`tar` — 아카이브 도구

Tape Archive의 약자이다. 원래 자기 테이프에 백업하기 위해 만들어졌지만, 현재는 파일 묶기/풀기의 표준 도구이다.

tar의 옵션은 동작(무엇을 할 것인가)과 수식(어떻게 할 것인가)으로 나뉜다:

동작 옵션	설명
`-c`	Create — 새 아카이브 생성
`-x`	Extract — 아카이브 풀기
`-t`	lisT — 아카이브 내용 목록 보기

수식 옵션	설명
`-f`	File — 아카이브 파일명 지정 (거의 항상 사용)
`-v`	Verbose — 처리 과정 출력
`-z`	gzip으로 압축/해제 (`.tar.gz`, `.tgz`)
`-j`	bzip2로 압축/해제 (`.tar.bz2`)
`-J`	xz로 압축/해제 (`.tar.xz`)
`-C`	지정한 디렉터리에서 작업

아카이브 생성

# 기본 아카이브 생성 (압축 없이 묶기만)
tar -cvf archive.tar file1.txt file2.txt dir1/
#  -c: 생성
#  -v: 과정 출력
#  -f: 파일명 지정

# gzip 압축 아카이브 (가장 흔히 사용) ★★★
tar -czvf archive.tar.gz /var/log/nginx/

# bzip2 압축 아카이브 (더 높은 압축률, 더 느림)
tar -cjvf archive.tar.bz2 /var/log/nginx/

# xz 압축 아카이브 (가장 높은 압축률, 가장 느림)
tar -cJvf archive.tar.xz /var/log/nginx/

# 특정 파일/디렉터리 제외
tar -czvf backup.tar.gz --exclude='*.log' --exclude='.git' /opt/myapp/
tar -czvf backup.tar.gz --exclude-vcs /opt/myapp/   # VCS 디렉터리 전체 제외

아카이브 풀기

# gzip 압축 아카이브 풀기
tar -xzvf archive.tar.gz

# 특정 디렉터리에 풀기 (-C 옵션)
tar -xzvf archive.tar.gz -C /opt/restore/

# 아카이브 내용 목록 보기 (풀지 않고 확인)
tar -tzvf archive.tar.gz

# 아카이브에서 특정 파일만 추출
tar -xzvf archive.tar.gz path/to/specific/file.txt

실무 패턴

# 서버 설정 백업 (날짜 포함)
tar -czvf /backup/etc-backup-$(date +%Y%m%d).tar.gz /etc/

# 애플리케이션 배포 패키지 생성 (불필요한 파일 제외)
tar -czvf release-v1.2.0.tar.gz \
  --exclude='node_modules' \
  --exclude='.env' \
  --exclude='*.log' \
  ./myapp/

# 원격 서버로 직접 전송 (로컬에 파일을 만들지 않고)
tar -czf - /opt/myapp/ | ssh user@remote "tar -xzf - -C /opt/"
# '-'는 stdout/stdin을 의미한다

압축 도구 비교

도구	확장자	압축률	속도	특징
gzip	`.gz`	보통	빠름	가장 범용적, 사실상 표준
bzip2	`.bz2`	높음	느림	gzip보다 높은 압축률
xz	`.xz`	매우 높음	매우 느림	배포판 패키지에서 자주 사용
zstd	`.zst`	높음	매우 빠름	최신, 압축률과 속도 모두 우수
lz4	`.lz4`	낮음	극히 빠름	실시간 압축에 적합

선택 기준:

일반적인 백업/전송: gzip (호환성 최고)
대용량 로그 아카이브: xz 또는 zstd (높은 압축률)
빠른 처리가 중요한 경우: zstd 또는 lz4

`gzip` / `gunzip`

# 파일 압축 (원본 파일이 .gz로 대체된다)
gzip access.log
# access.log → access.log.gz (원본 사라짐)

# 원본 유지하면서 압축
gzip -k access.log
# access.log 유지, access.log.gz 생성

# 해제
gunzip access.log.gz
# 또는
gzip -d access.log.gz

# 압축률 조절 (1=빠름/낮은압축, 9=느림/높은압축, 기본=6)
gzip -9 large_file.log    # 최대 압축

# 압축 파일의 내용을 해제하지 않고 보기
zcat access.log.gz        # cat처럼 출력
zless access.log.gz       # less처럼 페이지 단위
zgrep "error" access.log.gz  # grep처럼 검색

`xz` / `unxz`

# 압축
xz large_file.log

# 원본 유지하면서 압축
xz -k large_file.log

# 해제
unxz large_file.log.xz

# 멀티스레드 압축 (속도 개선) ★
xz -T 0 large_file.log    # 사용 가능한 모든 코어 활용

# 압축 파일 내용 보기
xzcat large_file.log.xz

`zip` / `unzip`

zip은 Windows 환경과의 호환성을 위해 사용한다. 리눅스 자체적으로는 tar.gz가 표준이지만, Windows 사용자에게 파일을 전달하거나 받을 때 zip을 사용하게 된다.

# 설치 (없는 경우)
sudo apt install zip unzip

# 압축 (파일/디렉터리)
zip -r archive.zip mydir/
zip archive.zip file1.txt file2.txt

# 해제
unzip archive.zip
unzip archive.zip -d /opt/extract/    # 특정 디렉터리에 풀기

# 내용 목록 보기
unzip -l archive.zip

# 특정 파일만 추출
unzip archive.zip path/to/file.txt

# 비밀번호 설정 압축
zip -e -r secret.zip sensitive_data/

압축 알고리즘의 원리

무손실 압축(Lossless Compression)은 데이터에서 반복되는 패턴을 찾아서 더 짧은 표현으로 대체한다. 해제하면 원본과 100% 동일한 데이터가 복원된다.

예시 — AAAAABBBCC라는 10바이트 데이터:

압축 후: 5A3B2C (6바이트) — "A가 5번, B가 3번, C가 2번"
이를 Run-Length Encoding (RLE)이라고 한다

실제 gzip, bzip2, xz 등은 이보다 훨씬 정교한 알고리즘을 사용하지만, 핵심 원리는 동일하다 — 반복과 패턴을 효율적으로 인코딩하는 것이다.

요약

도구	역할	핵심 사용법
`tar`	아카이브(묶기/풀기)	`-czf`(생성), `-xzf`(풀기), `-tzf`(목록)
`gzip`	범용 압축	`gzip file`, `zcat`, `zgrep`
`xz`	고압축	`xz -T0 file` (멀티스레드)
`zip/unzip`	Windows 호환	`zip -r`, `unzip -l`

상황	추천
리눅스 서버 간 백업/전송	`tar.gz`
장기 아카이브 (공간 절약)	`tar.xz`
Windows 사용자에게 전달	`zip`
압축된 로그 검색	`zgrep`, `zcat`, `zless`
서버 간 실시간 전송	`tar -czf -

Chapter 07. 권한 & 소유자 관리

리눅스는 태생적으로 멀티유저(multi-user) 시스템이다. 여러 사용자가 동시에 접속하여 작업하기 때문에, "누가 어떤 파일을 읽고, 쓰고, 실행할 수 있는가"를 제어하는 것이 필수이다.

권한 문제는 매우 빈번하게 발생할 수 있다

배포 스크립트가 실행 권한이 없어서 실패
애플리케이션이 로그 파일에 쓰기 권한이 없어서 에러
설정 파일이 누구나 읽을 수 있어서 보안 위험 (DB 비밀번호 노출 등)
Docker 컨테이너 내부의 파일 소유자 문제

권한의 구조

세 가지 주체 (Who)

리눅스는 파일에 접근하는 주체를 세 그룹으로 나눈다:

주체	약자	설명
Owner (소유자)	`u` (user)	파일을 소유한 사용자. 보통 파일을 생성한 사람이다.
Group (그룹)	`g`	파일에 지정된 그룹에 속한 사용자들.
Others (기타)	`o`	소유자도 아니고 그룹에도 속하지 않는 나머지 모든 사용자.

세 가지 권한

권한	문자	숫자	파일에 대한 의미	디렉터리에 대한 의미
Read	`r`	4	파일 내용을 읽을 수 있다	디렉터리 내 파일 목록을 볼 수 있다 (`ls`)
Write	`w`	2	파일 내용을 수정할 수 있다	디렉터리 내 파일을 생성/삭제할 수 있다
Execute	`x`	1	파일을 실행할 수 있다	디렉터리에 진입할 수 있다 (`cd`)

디렉터리의 x(실행) 권한은 직관적이지 않으므로 주의가 필요하다:

r 없이 x만 있으면: 디렉터리 안의 파일 목록은 볼 수 없지만, 파일명을 정확히 알면 접근할 수 있다
x 없이 r만 있으면: 파일 목록은 볼 수 있지만, 실제로 파일에 접근하거나 cd로 진입할 수 없다
w는 x와 함께 있어야 의미가 있다: 디렉터리에 진입(x)할 수 있어야 파일을 생성/삭제(w)할 수 있다

권한 표기법

ls -l 출력에서 권한은 9자리 문자로 표시된다:

-rwxr-xr--
│├─┤├─┤├─┤
│ │  │  └── Others: r-- (읽기만)
│ │  └── Group: r-x (읽기+실행)
│ └── Owner: rwx (읽기+쓰기+실행)
└── 파일 타입 (- = 일반 파일)

8진수(Octal) 표기법

각 권한을 숫자로 표현하며, 세 자리 숫자로 소유자/그룹/기타의 권한을 나타낸다.

r=4, w=2, x=1 → 합산하여 표현

rwx = 4+2+1 = 7
r-x = 4+0+1 = 5
r-- = 4+0+0 = 4
--- = 0+0+0 = 0

자주 사용하는 권한 조합:

8진수	문자 표기	의미	용도
`755`	rwxr-xr-x	소유자 전체, 나머지 읽기+실행	실행 파일, 디렉터리
`644`	rw-r--r--	소유자 읽기+쓰기, 나머지 읽기	일반 파일, 설정 파일
`700`	rwx------	소유자만 전체 권한	개인 디렉터리, SSH 키 디렉터리
`600`	rw-------	소유자만 읽기+쓰기	SSH 개인 키, 민감한 설정
`777`	rwxrwxrwx	모두에게 전체 권한	보안 위험 — 거의 사용하지 않는다
`400`	r--------	소유자만 읽기	AWS 키 파일 등

`chmod` — 권한 변경

Change Mode의 약자이다.

8진수 방식

# 파일 권한을 644로 설정
chmod 644 config.yaml

# 스크립트에 실행 권한 부여
chmod 755 deploy.sh

# SSH 개인 키 — 소유자만 읽기 (AWS에서 필수)
chmod 400 my-key.pem

# 디렉터리와 내용물에 재귀적으로 적용
chmod -R 755 /var/www/html/

심볼릭 방식

누구(u/g/o/a)에게 무엇(r/w/x)을 어떻게(+/-/=) 할 것인지를 문자로 표현한다.

기호	의미
`u`	owner(소유자)
`g`	group(그룹)
`o`	others(기타)
`a`	all(전체) — u+g+o
`+`	권한 추가
`-`	권한 제거
`=`	권한을 정확히 설정 (기존 권한 대체)

# 소유자에게 실행 권한 추가
chmod u+x script.sh

# 그룹과 기타에서 쓰기 권한 제거
chmod go-w sensitive.conf

# 기타 사용자의 모든 권한 제거
chmod o= secret.env

# 모든 사용자에게 읽기 권한 부여
chmod a+r public.html

# 실행 권한만 추가 (기존 권한 유지)
chmod +x deploy.sh

`chown` — 소유자/그룹 변경

Change Owner의 약자이다. 파일의 소유자와 소유 그룹을 변경한다. root 권한(sudo)이 필요하다.

# 소유자 변경
sudo chown nginx /var/www/html/index.html

# 소유자 + 그룹 동시 변경
sudo chown nginx:www-data /var/www/html/index.html

# 그룹만 변경 (: 앞을 비움)
sudo chown :www-data /var/www/html/index.html

# 재귀적으로 변경 (디렉터리 전체)
sudo chown -R nginx:www-data /var/www/html/

# 심볼릭 링크 자체의 소유자 변경 (기본은 대상 파일 변경)
sudo chown -h devops symlink_file

`chgrp` — 그룹만 변경

# chown :group과 동일한 효과
sudo chgrp www-data /var/www/html/
sudo chgrp -R docker /opt/containers/

특수 권한

기본 rwx 외에 세 가지 특수 권한이 있다.

SUID (Set User ID) — 4000

실행 파일에 SUID가 설정되면, 해당 파일을 누가 실행하든 파일 소유자의 권한으로 실행된다.

# 대표적인 SUID 파일
ls -la /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd
#    ^
#    s = SUID가 설정되어 있다는 표시

어떤 상황에 필요할까?
passwd 명령어는 /etc/shadow 파일을 수정해야 한다. 이 파일은 root만 쓸 수 있다. 하지만 일반 사용자도 자신의 비밀번호를 변경할 수 있어야 한다. SUID를 통해 일반 사용자가 passwd를 실행하면 root 권한으로 동작하여 /etc/shadow를 수정할 수 있게 된다.

# SUID 설정
chmod u+s executable
chmod 4755 executable

# 보안 감사 — SUID 파일 찾기 (비정상적인 SUID 파일은 보안 위험)
find / -type f -perm -4000 2>/dev/null

SGID (Set Group ID) — 2000

파일에 설정: 실행 시 파일 소유 그룹의 권한으로 실행된다.

디렉터리에 설정: 해당 디렉터리 안에서 생성되는 새 파일의 그룹이 디렉터리의 그룹을 상속한다. 팀 공유 디렉터리에서 매우 유용하다.

# 팀 공유 디렉터리 설정
sudo mkdir /shared/project
sudo chown :devteam /shared/project
sudo chmod 2775 /shared/project
#          ^
#          2 = SGID

# 이후 이 디렉터리에서 생성되는 모든 파일은 자동으로 devteam 그룹 소유

Sticky Bit — 1000

디렉터리에 설정하면, 해당 디렉터리 안의 파일을 파일의 소유자와 root만 삭제할 수 있다. 다른 사용자의 파일을 삭제할 수 없게 보호한다.

# /tmp의 권한을 확인해보면 Sticky Bit가 설정되어 있다
ls -ld /tmp
# drwxrwxrwt 15 root root 4096 ... /tmp
#          ^
#          t = Sticky Bit

/tmp는 모든 사용자가 읽고 쓸 수 있는(rwxrwxrwx) 디렉터리이다. Sticky Bit가 없으면 사용자 A가 사용자 B의 임시 파일을 삭제할 수 있어 위험하다. Sticky Bit 덕분에 자기 파일만 삭제할 수 있다.

# Sticky Bit 설정
chmod +t /shared/tmp
chmod 1777 /shared/tmp

특수 권한 정리

특수 권한	숫자	대상	효과
SUID	4000	파일	실행 시 소유자 권한으로 동작
SGID	2000	디렉터리	새 파일이 디렉터리의 그룹을 상속
Sticky Bit	1000	디렉터리	소유자만 자기 파일 삭제 가능

umask — 기본 권한 설정

umask는 새로 생성되는 파일과 디렉터리의 기본 권한을 결정하는 마스크 값이다.

리눅스에서 파일/디렉터리 생성 시 기본 최대 권한:

파일: 666 (rw-rw-rw-) — 보안상 실행 권한은 기본 부여하지 않는다
디렉터리: 777 (rwxrwxrwx)

여기서 umask 값을 빼면 실제 생성되는 파일의 권한이 된다:

파일 기본 권한   = 666 - umask
디렉터리 기본 권한 = 777 - umask

# 현재 umask 확인
$ umask
0022

# umask가 0022일 때:
# 파일:      666 - 022 = 644 (rw-r--r--)
# 디렉터리:   777 - 022 = 755 (rwxr-xr-x)

# umask 변경
umask 0077
# 파일:      666 - 077 = 600 (rw-------)
# 디렉터리:   777 - 077 = 700 (rwx------)
# → 소유자만 접근 가능하게 된다

보안이 중요한 환경에서는 umask를 0027 또는 0077로 설정하여 기타 사용자의 접근을 기본적으로 차단한다. umask 설정은 ~/.bashrc나 /etc/profile에 넣어 영구 적용할 수 있다.

참고: umask는 엄밀히는 단순 뺄셈이 아닌 비트 마스크(NOT AND) 연산이다. 대부분의 경우 뺄셈과 결과가 같지만, 이론적으로는 최대권한 AND (NOT umask)가 정확한 계산이다.

`sudo` — 관리자 권한 실행

sudo는 Superuser Do의 약자이다. 일반 사용자가 임시로 root 권한을 빌려서 명령어를 실행할 수 있게 한다. root 계정으로 직접 로그인하는 것보다 안전하다.

왜 root 직접 로그인 대신 sudo를 사용하는가:

감사 로그: 누가, 언제, 어떤 명령어를 실행했는지 기록된다 (/var/log/auth.log)
최소 권한 원칙: 필요한 순간에만 일시적으로 권한을 상승시킨다
실수 방지: 항상 root로 작업하면 한 번의 실수가 시스템 전체에 영향을 미친다

# root 권한으로 명령어 실행
sudo systemctl restart nginx

# root 셸로 전환
sudo -i       # root의 로그인 환경으로 전환
sudo su -     # 위와 유사

# 다른 사용자로 명령어 실행
sudo -u nginx cat /etc/nginx/nginx.conf

# 직전 명령어를 sudo로 재실행 ★
sudo !!
# 예: apt update → 권한 에러 → sudo !!로 재실행

요약

명령어	용도	핵심
`chmod`	권한 변경	`755`(8진수), `u+x`(심볼릭)
`chown`	소유자/그룹 변경	`-R`(재귀), root 권한 필요
`umask`	기본 권한 마스크	`0022`(기본), `0077`(보안 강화)
`sudo`	관리자 권한 실행	`visudo`로 설정, `!!`로 재실행

Chapter 08. 디스크 & 용량 관리

디스크 관리가 중요한 이유

클라우드/서버 환경에서 "디스크 용량 부족"은 가장 빈번하게 발생하는 장애 원인 중 하나이다. 디스크가 꽉 차면 다음과 같은 문제가 발생한다:

로그를 더 이상 기록할 수 없어서 애플리케이션이 비정상 종료
데이터베이스가 쓰기를 멈추거나 손상
시스템 자체가 부팅 불가 상태에 빠짐
배포(deploy)가 실패

디스크 구조 기본 개념

물리 디스크 → 파티션 → 파일시스템

물리 디스크 (/dev/sda 또는 /dev/nvme0n1)
  ├── 파티션 1 (/dev/sda1) → 파일시스템(ext4) → / (루트)에 마운트
  ├── 파티션 2 (/dev/sda2) → 파일시스템(ext4) → /home에 마운트
  └── 파티션 3 (/dev/sda3) → 스왑(swap)

파티션(Partition): 하나의 물리 디스크를 논리적으로 나눈 영역이다. 각 파티션은 독립적으로 포맷하고 마운트할 수 있다.

파일시스템(Filesystem): 파티션 위에 생성되는 데이터 저장 구조이다. 포맷(format)이란 파티션에 파일시스템을 생성하는 작업이다.

마운트(Mount): 파일시스템을 디렉터리 트리의 특정 위치에 연결하는 것이다.

디스크 용량 확인

`df` — 파일시스템 단위 용량 확인

Disk Free의 약자이다. 마운트된 파일시스템별 전체/사용/남은 용량을 표시한다.

# 기본 사용 (사람이 읽기 쉬운 형태) ★★★
df -h
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda1        50G   32G   16G  67% /
# /dev/sda2       100G   45G   50G  48% /home
# tmpfs            3.9G  1.2M  3.9G   1% /run

# 파일시스템 타입도 함께 표시
df -hT
# Filesystem      Type  Size  Used Avail Use% Mounted on
# /dev/sda1       ext4   50G   32G   16G  67% /

# 특정 경로가 어느 파일시스템에 속하는지 확인
df -h /var/log/
# → /var/log/가 위치한 파일시스템의 용량 정보

# inode 사용량 확인 ★ (파일 수 관련 문제 진단)
df -i
# Filesystem      Inodes  IUsed   IFree IUse% Mounted on
# /dev/sda1     3276800 234567 3042233    8% /

df는 파일시스템 단위로 보여준다. "어느 파티션이 꽉 찼는가"를 파악하는 첫 번째 단계이다.

`du` — 디렉터리/파일 단위 용량 확인

Disk Usage의 약자이다. df로 어느 파티션이 문제인지 파악했다면, du로 어떤 디렉터리가 공간을 많이 차지하는지 추적한다.

# 현재 디렉터리의 총 용량
du -sh .

# 하위 디렉터리별 용량 (1단계)
du -h --max-depth=1 /var/

# 용량 순 정렬 (큰 것부터) ★★★
du -sh /var/*/ 2>/dev/null | sort -rh | head -10

# 특정 디렉터리의 총 용량
du -sh /var/log/ /var/cache/ /var/lib/

# 파일 단위까지 표시
du -ah /var/log/ | sort -rh | head -20

`lsblk` — 블록 디바이스 목록

시스템에 연결된 디스크와 파티션의 트리 구조를 보여준다.

$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    0   50G  0 disk
├─sda1        8:1    0   49G  0 part /
└─sda2        8:2    0    1G  0 part [SWAP]
nvme0n1     259:0    0  100G  0 disk
└─nvme0n1p1 259:1    0  100G  0 part /data

# 파일시스템 정보 포함
lsblk -f
# NAME    FSTYPE LABEL UUID                                 MOUNTPOINT
# sda1    ext4         a1b2c3d4-...                         /

디스크 용량 문제 해결

"디스크가 꽉 찼다" — 체계적인 진단 절차

# Step 1: 어느 파일시스템이 꽉 찼는지 확인
df -h
# Use%가 90% 이상인 파일시스템을 찾는다

# Step 2: 해당 파일시스템에서 큰 디렉터리 찾기
du -h --max-depth=1 / 2>/dev/null | sort -rh | head -10
# /var가 크다면 → /var 안에서 다시 추적

# Step 3: 범인 디렉터리 좁히기
du -h --max-depth=1 /var/ | sort -rh | head -10
# /var/log가 크다면 → /var/log 안에서 다시 추적

# Step 4: 큰 파일 직접 찾기
find / -type f -size +100M 2>/dev/null | xargs ls -lhS

# Step 5: 삭제되었지만 공간을 차지하는 파일 확인
lsof +L1 2>/dev/null

inode 고갈 문제

디스크 공간은 남아있는데 "No space left on device" 에러가 발생하면 inode 고갈을 의심해야 한다. 작은 파일이 수백만 개 생성된 경우에 발생한다.

# inode 사용량 확인
df -i

# 어느 디렉터리에 파일이 많은지 찾기
find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10
# 각 디렉터리의 파일 수를 세어서 정렬

Chapter 09. 텍스트 검색 & 치환

리눅스에서는 거의 모든 것이 텍스트이다.
설정 파일, 로그, 명령어 출력, /proc 파일시스템 — 전부 텍스트 스트림이다.

텍스트 처리의 3대 도구

도구	역할	핵심 용도
`grep`	검색 (Search)	패턴이 포함된 줄을 찾는다
`sed`	치환 (Replace)	텍스트를 변환/치환한다
`awk`	추출/가공 (Extract)	필드 단위로 데이터를 추출/계산한다

정규표현식 (Regular Expression)

grep, sed, awk 모두 정규표현식(regex)을 사용한다.

메타문자	의미	예시	매치 대상
`.`	임의의 한 문자	`h.t`	hat, hot, hit
`^`	줄의 시작	`^Error`	Error로 시작하는 줄
`$`	줄의 끝	`\.log$`	.log로 끝나는 줄
`*`	앞 문자가 0회 이상	`ab*c`	ac, abc, abbc
`+`	앞 문자가 1회 이상 (ERE)	`ab+c`	abc, abbc (ac는 안됨)
`?`	앞 문자가 0회 또는 1회 (ERE)	`colou?r`	color, colour
`[]`	문자 클래스 (하나)	`[aeiou]`	모음 한 글자
`[^]`	부정 문자 클래스	`[^0-9]`	숫자가 아닌 문자
`	`	OR (ERE)	`cat
`()`	그룹핑 (ERE)	`(ab)+`	ab, abab, ababab
`\b`	단어 경계	`\berror\b`	"error" 단어만 (errors 제외)

BRE vs ERE

BRE (Basic Regular Expression): grep, sed의 기본 모드. +, ?, |, () 사용 시 앞에 \를 붙여야 한다.
ERE (Extended Regular Expression): grep -E (또는 egrep), sed -E, awk의 기본 모드. \ 없이 바로 사용 가능하다.

# BRE (grep 기본)
grep "error\|fail" logfile        # \| 필요

# ERE (grep -E) — 더 깔끔하다
grep -E "error|fail" logfile      # | 그대로 사용

특별한 이유가 없으면 항상 grep -E를 사용하는 것이 편하다.

자주 쓰는 패턴 모음

# IP 주소 패턴
[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+

# 날짜 패턴 (YYYY-MM-DD)
[0-9]{4}-[0-9]{2}-[0-9]{2}

# 이메일 패턴 (간략)
[a-zA-Z0-9.]+@[a-zA-Z0-9.]+

# 빈 줄
^$

# 주석 줄 (# 또는 //)
^#|^//

# 숫자만
^[0-9]+$

`grep` — 텍스트 검색

정규표현식 검색

# ERE 모드로 여러 패턴 동시 검색
grep -E "error|warning|critical" /var/log/syslog

# IP 주소 추출
grep -Eo "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" /var/log/auth.log

# 특정 날짜의 로그만 추출
grep "^2025-03-23" /var/log/app.log

# 특정 패턴 사이의 줄 (시작 패턴 ~ 끝 패턴)
grep -A 100 "BEGIN CERTIFICATE" cert.pem | grep -B 100 "END CERTIFICATE"

`o` 옵션 — 매치된 부분만 출력

# 줄 전체가 아닌, 매치된 부분만 출력
grep -oE "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" access.log

# 로그에서 HTTP 상태 코드만 추출
grep -oE "HTTP/[0-9.]+ [0-9]{3}" access.log

`grep` 조합 패턴

# 여러 조건을 AND로 결합 (grep 파이프 체인)
grep "2025-03-23" app.log | grep "ERROR" | grep "database"
# → 3월 23일 + ERROR + database 포함하는 줄

# 특정 패턴 제외 (NOT)
grep "error" app.log | grep -v "timeout"
# → error를 포함하지만 timeout은 포함하지 않는 줄

# 전후 맥락과 함께 보기
grep -C 5 "OOM" /var/log/syslog
# → Out Of Memory 전후 5줄씩

`sed` — 스트림 편집기

Stream Editor의 약자이다.
텍스트를 줄 단위로 읽어서 변환하는 도구이다. 가장 많이 사용하는 기능은 치환이다.

치환

# 기본 치환: 각 줄에서 첫 번째 매치만 변환
sed 's/old/new/' file.txt

# 모든 매치 변환 (g = global) ★★★
sed 's/old/new/g' file.txt

# 대소문자 무시 (i 플래그)
sed 's/error/ERROR/gi' file.txt

# 특정 줄만 치환
sed '3s/old/new/' file.txt        # 3번째 줄만
sed '1,5s/old/new/g' file.txt     # 1~5번째 줄만

원본 파일 직접 수정 (`i`)

기본적으로 sed는 결과를 stdout으로 출력하며, 원본 파일은 변경하지 않는다. -i 옵션을 사용하면 원본 파일을 직접 수정한다.

# 원본 파일을 직접 수정 ★★★
sed -i 's/old/new/g' config.yaml

# 백업을 만들면서 수정 (안전한 방법)
sed -i.bak 's/old/new/g' config.yaml
# config.yaml → 수정됨
# config.yaml.bak → 원본 백업

# macOS에서는 -i 뒤에 빈 문자열을 반드시 지정해야 한다
sed -i '' 's/old/new/g' config.yaml    # macOS

활용 예시

# 1. 설정 파일의 특정 값 변경
sed -i 's/^port=.*/port=8080/' app.conf
# port= 으로 시작하는 줄의 값을 8080으로 변경

# 2. 여러 파일에서 일괄 치환
find /etc/myapp -name "*.conf" -exec sed -i 's/old-server/new-server/g' {} +

# 3. 파일에서 특정 범위 추출
sed -n '10,20p' file.txt    # 10~20번째 줄만 출력 (-n + p)

# 4. 환경별 설정 파일 생성
sed 's/{{DB_HOST}}/prod-db.example.com/g; s/{{DB_PORT}}/5432/g' template.conf > prod.conf

`awk` — 필드 기반 텍스트 처리

awk는 텍스트를 필드(열) 단위로 분리하여 처리하는 프로그래밍 언어이다. 이름은 개발자 세 명(Aho, Weinberger, Kernighan)의 이니셜에서 유래했다.

기본 동작 원리

awk는 입력을 줄(record) 단위로 읽고, 각 줄을 필드(field)로 분리한 뒤 처리한다.

입력: "devops  1234  /bin/bash"

$0 = "devops  1234  /bin/bash"    (줄 전체)
$1 = "devops"                     (1번째 필드)
$2 = "1234"                       (2번째 필드)
$3 = "/bin/bash"                  (3번째 필드)
NF = 3                            (필드 수)
NR = (현재 줄 번호)

기본 필드 구분자는 공백/탭이다. -F 옵션으로 변경할 수 있다.

# 특정 필드만 출력
awk '{print $1}' /etc/passwd           # 첫 번째 필드 (구분자: 공백)
awk -F: '{print $1}' /etc/passwd       # 구분자를 :으로 지정 → 사용자명

# 여러 필드 출력
awk -F: '{print $1, $3}' /etc/passwd   # 사용자명, UID
awk -F: '{print $1 ":" $3}' /etc/passwd  # 사용자명:UID (포맷 지정)

조건부 처리

awk는 패턴 { 동작 } 형식으로 조건부 처리를 할 수 있다.

# 특정 조건에 맞는 줄만 처리
awk -F: '$3 >= 1000 {print $1, $3}' /etc/passwd
# UID가 1000 이상인 사용자만 출력 (일반 사용자)

# 특정 문자열이 포함된 줄
awk '/error/ {print}' /var/log/syslog
# grep "error"와 동일하지만, awk는 필드 추출까지 가능

# 특정 필드가 조건을 만족하는 줄
awk '$9 == 500 {print $7}' access.log
# HTTP 상태 코드(9번째 필드)가 500인 줄에서 URL(7번째 필드)만 추출

계산과 집계

awk의 가장 강력한 기능은 데이터 집계이다.

# 합계 계산
awk '{sum += $1} END {print sum}' numbers.txt

# 평균 계산
awk '{sum += $1; count++} END {print sum/count}' numbers.txt

# 최대값
awk 'BEGIN {max=0} $1 > max {max=$1} END {print max}' numbers.txt

BEGIN과 END 블록:

BEGIN { ... }: 입력을 처리하기 전에 한 번 실행된다 (초기화)
END { ... }: 모든 입력을 처리한 후에 한 번 실행된다 (결과 출력)

실무 활용 예시

# 1. Nginx 액세스 로그에서 IP별 요청 수 집계
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# 2. 디스크 사용률이 80% 이상인 파티션 알림
df -h | awk 'NR>1 && +$5 >= 80 {print "WARNING:", $6, "is", $5, "full"}'

# 3. 프로세스별 메모리 사용량 합계
ps aux | awk 'NR>1 {mem[$11] += $6} END {for (p in mem) print mem[p]/1024 "MB", p}' | sort -rn | head -10

# 4. CSV에서 특정 열의 합계
awk -F',' '{sum += $3} END {printf "Total: %.2f\n", sum}' sales.csv

# 5. 로그에서 시간대별 에러 수 집계
grep "ERROR" app.log | awk '{print substr($1,1,13)}' | sort | uniq -c
# 시간(hour) 단위로 에러 발생 빈도 확인

[멋사 클라우드 5기] Day 31 & 32 - OSI 7 Layers

allluck777 — Mon, 16 Mar 2026 23:23:25 +0900

OSI 7 Layers

네트워크 문제가 발생했을 때 "인터넷이 안 돼요"라는 말만으로는 원인을 파악할 수 없다.
DNS가 안 되는 건지, 방화벽이 막는 건지, 물리 케이블이 빠진 건지.
문제의 위치를 특정하려면 네트워크가 어떤 단계로 동작하는지 이해해야 한다.

OSI(Open Systems Interconnection) 모델은 네트워크 통신을 7개의 계층으로 분리한 참조 모델이다.
1984년 ISO(International Organization for Standardization)가 제정했다.
실제 인터넷은 TCP/IP 4계층 모델로 동작하지만, OSI 7계층은 문제를 진단하고 설명하는 공통 언어로서 표준이다.

Layer 1 — Physical (물리 계층)

물리 계층은 0과 1의 비트(bit)를 실제 전기 신호, 광 신호, 무선 전파로 변환하여 전송하는 계층이다.

이 계층은 "데이터"가 뭔지 모른다. 단지 비트 스트림을 물리적 매체를 통해 보내고 받을 뿐이다.

구성 요소

전송 매체:

UTP 케이블(Cat5e, Cat6, Cat6a): 구리선으로 전기 신호를 전달한다. 사무실 LAN에 가장 많이 쓰인다.
광섬유(Fiber Optic): 빛으로 데이터를 전달. 장거리, 고속 통신에 사용한다. 데이터센터 간 연결의 핵심이다.
무선(Wi-Fi, 5G): 전파로 데이터를 전달한다.

장비:

리피터(Repeater): 약해진 신호를 증폭한다.
허브(Hub): 들어온 신호를 연결된 모든 포트로 복사하여 내보낸다. 현재는 거의 사용하지 않는다.

데이터 단위

비트(Bit) — 0 또는 1. 물리 계층이 다루는 최소 단위이다.

Layer 2 — Data Link (데이터링크 계층)

데이터링크 계층은 같은 네트워크(LAN) 안에서 장치 간 통신을 담당한다. 물리 계층의 비트 스트림을 의미 있는 프레임(Frame) 단위로 구성하고, MAC 주소를 사용하여 특정 장치를 식별한다.

MAC 주소

MAC(Media Access Control) 주소는 네트워크 인터페이스 카드(NIC)에 부여된 고유한 48비트 하드웨어 주소이다.

예: 00:1A:2B:3C:4D:5E

앞 24비트(00:1A:2B) = OUI (제조사 식별자, IEEE가 할당)
뒤 24비트(3C:4D:5E) = 제조사가 부여한 고유 번호

MAC 주소는 로컬 네트워크 내에서만 유효하다. 라우터를 넘어가면 MAC 주소는 바뀐다(라우터가 자신의 MAC으로 교체한다).

ARP (Address Resolution Protocol)

IP 주소는 알지만 MAC 주소를 모를 때 ARP를 사용한다.

1. PC-A가 "192.168.1.10의 MAC 주소가 뭐야?" 라고 브로드캐스트(FF:FF:FF:FF:FF:FF)를 보낸다.
2. 해당 IP를 가진 PC-B가 "내 MAC은 00:1A:2B:3C:4D:5E야" 라고 유니캐스트로 응답한다.
3. PC-A는 이 매핑을 ARP 테이블에 캐시한다.

장비

스위치(Switch):

MAC 주소 테이블(CAM 테이블)을 학습하여, 프레임을 해당 포트로만 전달한다.
허브와 달리 불필요한 트래픽을 줄인다.

브리지(Bridge):

두 개의 네트워크 세그먼트를 연결한다.
현재는 스위치에 기능이 통합되어 거의 쓰이지 않는다.

Layer 3 — Network (네트워크 계층)

네트워크 계층은 서로 다른 네트워크 간의 통신을 담당한다. L2가 "같은 방 안에서 누구에게 전달할까"를 결정한다면, L3는 "어느 방(네트워크)으로 보낼까"를 결정한다.

핵심 기능 두 가지: 논리적 주소 지정(IP 주소)과 라우팅(최적 경로 선택).

IP 주소

IPv4:

192.168.1.100 (32비트, 약 43억 개)

네트워크 부분 + 호스트 부분으로 나뉜다.
서브넷 마스크가 경계를 결정한다.

예: 192.168.1.100/24
- /24 = 서브넷 마스크 255.255.255.0
- 네트워크: 192.168.1.0
- 호스트 범위: 192.168.1.1 ~ 192.168.1.254
- 브로드캐스트: 192.168.1.255
- 사용 가능 호스트: 254개 (2^8 - 2)

IPv6:

2001:0db8:85a3:0000:0000:8a2e:0370:7334 (128비트)
축약: 2001:db8:85a3::8a2e:370:7334

사실상 무한한 주소 공간을 제공한다.

서브넷팅 (Subnetting)

큰 네트워크를 작은 단위로 나누는 것.

VPC CIDR: 10.0.0.0/16 (65,536개 IP)

이것을 서브넷으로 나눈다:
├── 10.0.1.0/24  → Public Subnet AZ-a  (256개 IP)
├── 10.0.2.0/24  → Public Subnet AZ-b  (256개 IP)
├── 10.0.10.0/24 → Private Subnet AZ-a (256개 IP)
├── 10.0.20.0/24 → Private Subnet AZ-b (256개 IP)
└── 나머지        → 향후 확장용

CIDR(Classless Inter-Domain Routing) 계산:

/24 = 256 IP (호스트 254개)
/25 = 128 IP (호스트 126개)
/26 = 64 IP  (호스트 62개)
/27 = 32 IP  (호스트 30개)
/28 = 16 IP  (호스트 14개)

공식: 사용 가능 호스트 = 2^(32 - 서브넷 비트 수) - 2
AWS에서는 서브넷당 5개 IP를 추가로 예약한다(네트워크, 라우터, DNS, 예약, 브로드캐스트).

라우팅

패킷이 목적지까지 도달하는 최적 경로를 선택하는 과정이다.
라우터는 패킷의 목적지 IP를 라우팅 테이블과 대조하여 가장 구체적인(longest prefix match) 경로로 전달한다.

NAT (Network Address Translation)

사설 IP를 공인 IP로 변환하는 기술이다.

내부 서버(10.0.1.50) → NAT Gateway → 인터넷(52.78.100.200으로 변환)

- SNAT(Source NAT): 출발지 IP 변환. 사설 → 공인. AWS NAT Gateway가 이 역할이다.
- DNAT(Destination NAT): 목적지 IP 변환. 공인 → 사설. 포트 포워딩이 대표적이다.

패킷 구조

┌──────────┬──────────┬─────┬──────────┬──────────┬─────────┐
│ Version  │ IHL      │ TTL │ Protocol │ Src IP   │ Dst IP  │
│ (4/6)    │ 헤더길이   │     │ TCP=6    │          │         │
│          │          │     │ UDP=17   │          │         │
└──────────┴──────────┴─────┴──────────┴──────────┴─────────┘

- TTL(Time To Live): 라우터를 지날 때마다 1씩 감소. 0이 되면 패킷 폐기. 무한 루프 방지 장치이다.
- Protocol: 상위 계층 프로토콜 식별 (6=TCP, 17=UDP, 1=ICMP)

Layer 4 — Transport (전송 계층)

전송 계층은 종단 간(End-to-End) 데이터 전송의 신뢰성과 흐름을 제어한다. "어떻게 안전하게 보낼까"와 "어떤 애플리케이션에 전달할까"를 담당한다.

핵심 개념: 포트 번호로 애플리케이션을 식별하고, TCP 또는 UDP 프로토콜로 전송 방식을 결정한다.

포트 번호

하나의 IP에서 여러 서비스를 구분하는 논리적 식별자이다. 0~65535 범위를 가진다.

Well-Known Ports (0-1023): 시스템 서비스용
  22   = SSH
  53   = DNS
  80   = HTTP
  443  = HTTPS
  3306 = MySQL
  5432 = PostgreSQL
  6379 = Redis

Registered Ports (1024-49151): 등록된 애플리케이션
  3000 = 개발 서버 (관례)
  8080 = 대체 HTTP (관례)
  8443 = 대체 HTTPS (관례)
  27017 = MongoDB

Dynamic/Ephemeral Ports (49152-65535): 클라이언트가 임시로 사용
  브라우저가 웹서버에 접속할 때, 출발지 포트로 이 범위의 임의 번호를 사용한다.

소켓(Socket) = IP 주소 + 포트 번호 + 프로토콜. 네트워크 통신의 종단점이다.

192.168.1.100:443/TCP → 하나의 소켓

TCP (Transmission Control Protocol)

연결 지향(Connection-Oriented), 신뢰성 있는 전송 프로토콜이다.

3-Way Handshake (연결 수립):

Client                    Server
  │                         │
  │──── SYN (seq=100) ─────→│   1. "연결하고 싶다" (SYN 플래그)
  │                         │
  │←── SYN-ACK (seq=300,    │   2. "좋다, 나도 준비됐다" (SYN+ACK)
  │     ack=101) ───────────│
  │                         │
  │──── ACK (ack=301) ─────→│   3. "확인, 시작하자" (ACK)
  │                         │
  │     연결 수립 완료 (ESTABLISHED)

이 과정이 완료되어야 데이터를 주고받을 수 있다. 모든 HTTP, SSH, DB 연결이 이 핸드셰이크로 시작한다.

4-Way Handshake (연결 종료):

Client                    Server
  │──── FIN ───────────────→│   1. "보낼 데이터 다 보냈다"
  │←──── ACK ───────────────│   2. "알겠다"
  │←──── FIN ───────────────│   3. "나도 다 보냈다"
  │──── ACK ───────────────→│   4. "알겠다. 연결 종료"

TCP의 신뢰성 보장 메커니즘:

시퀀스 번호(Sequence Number): 모든 바이트에 번호를 매긴다. 수신 측은 이를 통해 데이터를 올바른 순서로 재조립한다.
확인 응답(ACK): 수신한 데이터에 대해 확인 메시지를 보낸다. ACK가 안 오면 재전송한다.
흐름 제어(Flow Control): 수신 측의 처리 능력에 맞춰 전송 속도를 조절한다. Window Size로 제어한다.
혼잡 제어(Congestion Control): 네트워크 혼잡 시 전송 속도를 줄인다. Slow Start, Congestion Avoidance 등의 알고리즘을 사용한다.
체크섬(Checksum): 데이터 무결성을 검증한다.

UDP (User Datagram Protocol)

비연결(Connectionless), 신뢰성 없는 전송 프로토콜이다.

Client                   Server
  │                        │
  │──── 데이터 ─────────────→│   핸드셰이크 없이 바로 전송
  │──── 데이터 ─────────────→│   도착 확인도 하지 않음
  │──── 데이터 ─────────────→│   순서 보장도 하지 않음

UDP를 쓰는 이유:

빠르다. 핸드셰이크 오버헤드가 없다.
실시간성이 중요한 서비스에 적합하다.

UDP 사용 사례:

DNS 조회 (53번 포트): 작은 요청/응답이므로 TCP 오버헤드가 불필요하다.
실시간 스트리밍, VoIP: 약간의 패킷 손실보다 지연이 더 치명적이다.
게임 서버: 실시간 상태 업데이트에 UDP가 적합하다.
DHCP: IP 할당 과정에서 사용한다.

TCP vs UDP 비교

특성            TCP                    UDP
──────────────────────────────────────────────────
연결 방식       연결 지향 (3-way)       비연결
신뢰성         보장 (ACK, 재전송)       미보장
순서 보장       보장                    미보장
속도           상대적으로 느림          빠름
헤더 크기       20~60 바이트            8 바이트
사용 사례       웹, 이메일, 파일전송     DNS, 스트리밍, 게임

Layer 5 — Session (세션 계층)

세션 계층은 통신 세션의 수립, 유지, 종료를 관리한다. 두 장치 간의 대화(dialog)를 제어하고, 데이터 교환의 동기화 지점을 설정한다.

현대 네트워크에서 L5는 독립된 계층으로 명확히 구분되기 어렵다. 대부분의 세션 관리 기능은 L4(TCP)나 L7(HTTP) 안에 녹아 있다.

세션의 의미

웹 브라우저로 쇼핑몰에 로그인한 상황을 생각해 보자:

1. 세션 수립: 로그인 성공 → 서버가 세션 ID 발급
2. 세션 유지: 페이지를 이동해도 로그인 상태 유지
3. 세션 종료: 로그아웃 또는 타임아웃 → 세션 파기

세션 계층의 역할

대화 제어(Dialog Control):
- 전이중(Full-Duplex): 양방향 동시 통신 (전화 통화)
- 반이중(Half-Duplex): 한 번에 한쪽만 통신 (무전기)
동기화(Synchronization):
- 대용량 파일 전송 시 체크포인트를 설정한다.
- 전송 중 끊기면 처음부터가 아니라 마지막 체크포인트부터 재개한다.
세션 복구(Recovery):
- 연결이 끊겼을 때 세션을 복원한다.

Layer 6 — Presentation (표현 계층)

표현 계층은 데이터의 형식(포맷) 변환, 암호화/복호화, 압축/해제를 담당한다. 애플리케이션이 이해할 수 있는 형태로 데이터를 변환하는 "번역가" 역할이다.

L5와 마찬가지로 현대 네트워크에서는 독립 계층으로 존재하기보다 L7에 통합된 경우가 많다. 하지만 TLS/SSL이 이 계층의 대표적 기능이다.

세 가지 핵심 기능

1. 데이터 변환 (Translation):

- 문자 인코딩: UTF-8, ASCII, ISO-8859-1 간 변환
- 데이터 직렬화: JSON, XML, Protocol Buffers, YAML
- 이미지 포맷: JPEG, PNG, WebP
- 영상 코덱: H.264, H.265, VP9

예: 한국어가 포함된 JSON을 UTF-8로 인코딩하여 전송하고,
    수신 측에서 디코딩한다.

2. 암호화/복호화 (Encryption/Decryption):

TLS(Transport Layer Security) — 이전 이름: SSL

TLS 핸드셰이크 과정 (TLS 1.3 기준):

Client                           Server
  │                                │
  │── ClientHello ────────────────→│  지원하는 암호 스위트, TLS 버전 전달
  │   (+ 키 공유)                    │
  │                                │
  │←── ServerHello ────────────────│  선택한 암호 스위트, 서버 인증서 전달
  │    (+ 키 공유, 인증서)            │
  │                                │
  │   [양측이 공유 비밀키 계산]          │
  │                                │
  │←→ 암호화된 데이터 통신 ←→───────────│  대칭키로 암호화된 통신 시작

인증서 체인:

Root CA (DigiCert, Let's Encrypt 등)
  └── Intermediate CA
        └── 서버 인증서 (example.com)

브라우저/OS에 Root CA가 내장되어 있다.
서버 인증서 → Intermediate CA → Root CA 순으로 검증한다.
하나라도 검증 실패 시 "이 사이트는 안전하지 않습니다" 경고가 뜬다.

3. 압축/해제 (Compression/Decompression):

- gzip, brotli: HTTP 응답 압축
- 이미지 손실/무손실 압축
- 데이터 전송량을 줄여 속도를 높인다.

Layer 7 — Application (응용 계층)

응용 계층은 사용자와 가장 가까운 계층으로, 네트워크 서비스를 직접 제공한다. 웹 브라우저, 이메일 클라이언트, API 등 사용자가 실제로 사용하는 애플리케이션 프로토콜이 이 계층에서 동작한다.

주요 프로토콜

HTTP/HTTPS (포트 80/443):

웹 통신의 기본. 요청-응답 모델이다.

요청:
GET /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Accept: application/json

응답:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 234

{"users": [...]}

DNS (포트 53):

도메인 이름을 IP 주소로 변환하는 프로토콜이다.

www.example.com → ?

1. 브라우저 캐시 확인
2. OS 캐시 확인 (/etc/hosts 포함)
3. Local DNS 서버(리졸버)에 질의
4. Root DNS → .com TLD DNS → example.com 권한 DNS
5. IP 주소 반환: 93.184.216.34

레코드 타입:
  A      = 도메인 → IPv4
  AAAA   = 도메인 → IPv6
  CNAME  = 도메인 → 다른 도메인 (별칭)
  MX     = 메일 서버
  NS     = 네임서버
  TXT    = 텍스트 (SPF, DKIM, 도메인 검증 등)

SSH (포트 22):

# 원격 서버 접속
ssh -i key.pem ubuntu@10.0.1.50

# 포트 포워딩 (로컬 → 원격)
ssh -L 3306:rds-endpoint:3306 bastion-host
# 로컬 3306 포트로 접속하면 bastion을 통해 RDS에 연결된다.

# 포트 포워딩 (원격 → 로컬)
ssh -R 8080:localhost:3000 remote-server

기타 주요 프로토콜:

SMTP(25)/IMAP(143)/POP3(110): 이메일
FTP(21)/SFTP(22): 파일 전송

OSI 모델 vs TCP/IP 모델

실제 인터넷은 TCP/IP 4계층 모델로 동작한다.

OSI 7 계층                TCP/IP 4 계층          주요 프로토콜
───────────────────────────────────────────────────────────
L7 Application  ┐
L6 Presentation ├───→  Application Layer      HTTP, DNS, SSH,
L5 Session      ┘                             TLS, SMTP, FTP

L4 Transport    ────→  Transport Layer        TCP, UDP

L3 Network      ────→  Internet Layer         IP, ICMP, ARP

L2 Data Link    ┐
L1 Physical     ┘───→  Network Access Layer   Ethernet, Wi-Fi

[멋사 클라우드 5기] Day 29 & 30 - 게시판 구현을 통해 확인한 Spring Data JPA

allluck777 — Thu, 12 Mar 2026 16:10:46 +0900

findById vs getReferenceById 차이

메서드	사용하는 곳	대상
`findById`	`getPost()`, `getPostWithComments()`	Post 조회
`getReferenceById`	`registerPost()`, `updatePost()`)	User, Post

findById — 즉시 SELECT 실행

// PostService.java:29-33
@Transactional
public PostDto getPost(Long pid) {
    return postRepository.findById(pid)           // ← 이 시점에 SELECT 실행
                         .map(PostDto::from)
                         .orElseThrow(() -> new NoSuchElementException("해당 게시글 존재 x"));
}

findById(pid)가 호출되는 그 즉시 DB에 SELECT 쿼리를 날린다.

-- findById(pid) 호출 시 즉시 실행
SELECT p1_0.pid, p1_0.category_type, p1_0.content, p1_0.created_by,
       p1_0.created_date, p1_0.modified_by, p1_0.modified_date, p1_0.title,
       u1_0.uid, u1_0.created_by, u1_0.created_date, u1_0.email,
       u1_0.modified_by, u1_0.modified_date, u1_0.password, u1_0.role_type, u1_0.username
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid
WHERE p1_0.pid = ?

Optional<Post>를 반환한다.
DB에 해당 row가 없으면 Optional.empty()가 온다.
결과: 실제 데이터가 채워진 진짜 Post 엔티티 객체를 반환한다.

getReferenceById — SELECT 없이 프록시 반환

// PostService.java:51
User user = userRepository.getReferenceById(postDto.getUserDto().getUid());
// ↑ 이 시점에서 SELECT 실행 안 함! 프록시 객체만 반환

// PostService.java:60
Post post = postRepository.getReferenceById(pid);
// ↑ 역시 SELECT 실행 안 함! 프록시 객체만 반환

getReferenceById()는 호출 시점에 DB에 쿼리를 보내지 않는다.
대신 Hibernate가 만든 프록시(Proxy) 객체를 반환한다.

프록시 객체란?

실제 User 객체:
┌──────────────────────┐
│ uid = "user1"        │  ← 모든 필드에 실제 값이 들어있음
│ username = "홍길동"   │
│ email = "a@b.com"    │
│ password = "1234"    │
└──────────────────────┘

프록시 User 객체:
┌──────────────────────┐
│ uid = "user1"        │  ← ID만 가지고 있음 (파라미터로 넘긴 값)
│ username = ???       │  ← 나머지 필드는 비어있음
│ email = ???          │
│ password = ???       │
└──────────────────────┘
   ↓ username에 접근하면?
   그제서야 SELECT 쿼리 실행!

프록시는 실제 엔티티 클래스를 상속한 가짜 객체다.
ID 값만 가지고 있고, 나머지 필드는 비어있다.
프록시의 ID가 아닌 다른 필드(예: user.getUsername())에 접근하면, 그 시점에 SELECT가 실행된다.
DB에 해당 row가 없으면 EntityNotFoundException이 발생한다 (Optional이 아님).

언제 어떤 것을 쓸까?

상황	적절한 메서드	이유
조회한 데이터를 화면에 보여줘야 할 때	`findById`	실제 데이터가 필요하므로 즉시 SELECT
FK 설정만 필요할 때 (INSERT/UPDATE 시 연관 엔티티)	`getReferenceById`	ID만 있으면 되므로 SELECT 불필요
존재 여부를 확인해야 할 때	`findById`	프록시는 존재 여부를 즉시 알 수 없음

(1) registerPost

// User의 실제 데이터가 필요 없다.
// Post 테이블의 uid 컬럼에 FK만 넣으면 된다.
// → getReferenceById가 적절하다.
User user = userRepository.getReferenceById(postDto.getUserDto().getUid());
Post post = postDto.toEntity(user);  // Post의 user 필드에 프록시를 세팅
postRepository.save(post);           // INSERT 시 프록시의 uid만 사용

(2) getPost

// Post의 모든 필드를 화면에 보여줘야 한다.
// → findById가 적절하다.
return postRepository.findById(pid)
                     .map(PostDto::from)  // Post의 모든 필드 + User의 모든 필드에 접근

Lazy Loading vs Eager Loading

JPA의 기본 fetch 전략

어노테이션	기본값	이유
`@ManyToOne`	EAGER	"Many" 쪽에서 "One"을 조회 → 항상 1건이므로 부담 적음
`@OneToMany`	LAZY	"One" 쪽에서 "Many"를 조회 → 수백~수천 건일 수 있어 위험
`@OneToOne`	EAGER	1건이므로 부담 적음
`@ManyToMany`	LAZY	대량 데이터 가능

Post & PostComment Entity의 fetch 전략

// Post.java:46-48
@ManyToOne(cascade = CascadeType.PERSIST)   // ← fetch 속성 생략 = 기본값 EAGER
@JoinColumn(name = "uid")
private User user;

Post → User: EAGER (fetch 속성을 지정하지 않았으므로 @ManyToOne의 기본값인 EAGER 적용)

// Post.java:43-44
@OneToMany(mappedBy = "post", cascade = CascadeType.ALL)   // ← 기본값 LAZY
private final Set<PostComment> postComments = new LinkedHashSet<>();

Post → PostComment: LAZY (@OneToMany의 기본값)

// PostComment.java:25-27
@ManyToOne(optional = false)   // ← 기본값 EAGER
@JoinColumn(name = "pid", referencedColumnName = "pid")
private Post post;

// PostComment.java:29-31
@ManyToOne(optional = false)   // ← 기본값 EAGER
@JoinColumn(name = "uid", referencedColumnName = "uid")
private User user;

PostComment → Post: EAGER
PostComment → User: EAGER

요약

Post 조회 시:
  ├── User (EAGER)         → Post SELECT할 때 LEFT JOIN으로 함께 가져옴
  └── PostComment (LAZY)   → postComments에 접근하기 전까지 SELECT 안 함
                               접근하면 그때 SELECT 실행

PostComment 조회 시 (이론상):
  ├── Post (EAGER)         → PostComment를 findById()로 직접 조회하면 LEFT JOIN (이론상!)
  └── User (EAGER)         → PostComment를 findById()로 직접 조회하면 LEFT JOIN

프로젝트에서의 실제 동작:
사실 PostComment를 findById()로 직접 조회하는 코드는 없다.
PostComment가 로딩되는 경우는 두 가지뿐이다:

post.getPostComments() — Lazy 로딩 시
→ Post는 이미 영속성 컨텍스트에 존재하므로 Post JOIN 없음. User만 LEFT JOIN.

deleteByIdAndPost_IdAndUser_Uid() — 댓글 삭제 시
→ Post, User JOIN이 보이지만 EAGER 로딩이 아니라 WHERE 조건 검색용 JOIN.

따라서 이 프로젝트에서 PostComment → Post EAGER LEFT JOIN은 실제로 발생하지 않는다.

Lazy 로딩이 실제 발생하는 시점

⚠️ 참고로 getPost 메서드는
상세페이지(GET /posts/{pid})에서
수정페이지(GET /posts/{pid}/form)로 넘어갈 때 호출된다. (수정 폼에서는 댓글이 필요 없다)

하지만 영속성 컨텍스트가 공유되지는 않는다.

HTTP 요청마다 영속성 컨텍스트가 새로 만들어지기 때문이다.

[1번째 요청] GET /posts/1 (상세페이지)

→ @Transactional 시작 → 영속성 컨텍스트 생성

→ getPostWithComments(1) → SELECT Post, SELECT PostComment

→ @Transactional 종료 → 영속성 컨텍스트 소멸 ← 여기서 전부 사라짐

[2번째 요청] GET /posts/1/form (수정 폼)

→ @Transactional 시작 → 새 영속성 컨텍스트 생성 (1번 요청과 무관)

→ getPost(1) → SELECT Post JOIN User ← DB에 다시 쿼리

→ @Transactional 종료 → 영속성 컨텍스트 소멸

영속성 컨텍스트는 하나의 트랜잭션(= 하나의 HTTP 요청) 안에서만 살아있다.

브라우저에서 페이지를 이동하면 완전히 새로운 요청이므로, 이전에 조회했던

Post/User 캐시는 이미 없다.

getPost()

// PostService.java:30

postRepository.findById(pid)
// → SELECT post LEFT JOIN user 실행 (User는 EAGER이므로 JOIN)
// → PostComment는 LAZY이므로 아직 로딩 안 됨

.map(PostDto::from)
// → PostDto.from() 내부에서 post.getUser() 호출 (이미 JOIN으로 로드됨, 추가 쿼리 없음)
// → PostComment에는 접근하지 않으므로 PostComment SELECT 없음

getPostWithComments()

// PostService.java:37

postRepository.findById(pid)
// → SELECT post LEFT JOIN user 실행

// PostService.java:38
.map(PostWithCommentsDto::from)
// → PostWithCommentsDto.from() 내부:

// PostWithCommentsDto.java:42
post.getPostComments().stream()   // ← 이 순간! Lazy 로딩 발동!
// → SELECT post_comment LEFT JOIN user WHERE pid = ? 실행
// → PostComment들이 이 시점에 DB에서 로딩됨

핵심: post.getPostComments()를 호출하는 그 순간에 PostComment를 조회하는 SELECT가 실행된다. getPost()에서는 PostComment에 접근하지 않으므로 이 쿼리가 실행되지 않는다.

실행되는 SQL 추적

getPost() — 게시글 단건 조회

실제 코드

// PostService.java:28-33
@Transactional
public PostDto getPost(Long pid) {
    return postRepository.findById(pid)
                         .map(PostDto::from)
                         .orElseThrow(() -> new NoSuchElementException("해당 게시글 존재 x"));
}

실행되는 SQL

-- [1] findById(pid) → Post + User를 LEFT JOIN으로 한 번에 조회
SELECT p1_0.pid, p1_0.category_type, p1_0.content, p1_0.created_by, ...
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid
WHERE p1_0.pid = ?

총 1개의 쿼리가 실행된다.

findById()는 즉시 SELECT를 실행한다.
Post.user가 @ManyToOne (기본 EAGER)이므로, Hibernate가 LEFT JOIN으로 User를 함께 가져온다.
Post.postComments는 @OneToMany (기본 LAZY)이고, PostDto::from에서 postComments에 접근하지 않으므로 PostComment 쿼리는 실행되지 않는다.

getPostWithComments() — 게시글 + 댓글 조회

실제 코드

// PostService.java
@Transactional
public PostWithCommentsDto getPostWithComments(Long pid) {
    return postRepository.findById(pid)
                         .map(PostWithCommentsDto::from)
                         .orElseThrow(() -> new NoSuchElementException("해당 게시글 존재 x"));
}

// PostWithCommentsDto.java
public static PostWithCommentsDto from(Post post) {
    return new PostWithCommentsDto(
        post.getId(),
        post.getTitle(),
        post.getContent(),
        post.getCategoryType(),
        post.getPostComments().stream()          // ← Lazy 로딩 발동 지점
                              .map(PostCommentDto::from)
                              .collect(Collectors.toCollection(LinkedHashSet::new)),
        UserDto.from(post.getUser()),            // ← 이미 EAGER로 로드됨
        post.getCreatedDate(),
        post.getCreatedBy(),
        post.getModifiedDate(),
        post.getModifiedBy()
    );
}

실행되는 SQL

-- [1] findById(pid) → Post + User 조회 (EAGER JOIN)
SELECT p1_0.pid, p1_0.category_type, p1_0.content, p1_0.created_by, ...
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid
WHERE p1_0.pid = ?

-- [2] post.getPostComments() 접근 → Lazy 로딩으로 PostComment + User 조회
SELECT pc1_0.pid, pc1_0.id, pc1_0.content, pc1_0.created_by, ...
FROM post_comment pc1_0
LEFT JOIN user u1_0 ON u1_0.uid = pc1_0.uid
WHERE pc1_0.pid = ?

총 2개의 쿼리가 실행된다.

1번 쿼리: findById()에 의해 Post + User(EAGER) 조회.
2번 쿼리: PostWithCommentsDto.from() 안에서 post.getPostComments()를 호출하는 순간, Lazy 로딩이 발동하여 해당 Post의 PostComment들을 조회한다. PostComment → User도 @ManyToOne(EAGER)이므로 LEFT JOIN으로 함께 가져온다.

registerPost() — 게시글 등록

실제 코드

// PostService.java:42-55
@Transactional
public void registerPost(PostDto postDto) {
    User user = userRepository.getReferenceById(postDto.getUserDto().getUid());
    // ↑ SELECT 실행 안 함. uid만 가진 프록시 반환.

    Post post = postDto.toEntity(user);
    // ↑ Post 객체 생성. user 필드에 프록시가 들어감.

    postRepository.save(post);
    // ↑ INSERT 실행. 프록시의 uid만 FK 값으로 사용.
}

실행되는 SQL

-- [1] postRepository.save(post) → INSERT (getReferenceById는 쿼리 없음)
INSERT INTO post (category_type, content, created_by, created_date,
                  modified_by, modified_date, title, uid)
VALUES (?, ?, ?, ?, ?, ?, ?, ?)

총 1개의 쿼리가 실행된다.

getReferenceById()는 프록시를 반환할 뿐, SELECT를 실행하지 않는다.
save()가 호출되면 Hibernate는 Post가 새 엔티티임을 감지하고(@GeneratedValue(strategy = IDENTITY) + id가 null) INSERT를 실행한다.
INSERT 시 uid 컬럼에는 프록시가 가진 ID 값("user1" 등)만 필요하므로, User의 다른 필드를 조회할 필요가 없다.
이것이 getReferenceById의 장점이다. FK 설정을 위해 불필요한 SELECT를 하지 않는다.

updatePost() — 게시글 수정 (Dirty Checking)

실제 코드

// PostService.java:57-66
@Transactional
public void updatePost(Long pid, PostDto postDto) {
    Post post = postRepository.getReferenceById(pid);
    // ↑ 프록시 반환 (SELECT 아직 안 함)

    post.updateTitleAndContentAndCategoryType(
        postDto.getTitle(),
        postDto.getContent(),
        postDto.getCategoryType()
    );
    // ↑ 프록시의 필드에 접근 → 이 시점에 SELECT 실행
    // ↑ 그 후 title, content, categoryType 값을 변경
    // ↑ save() 호출 없음! @Transactional 종료 시 dirty checking으로 UPDATE 실행
}

// Post.java:63-67
public void updateTitleAndContentAndCategoryType(String title, String content, CategoryType categoryType) {
    this.title = title;        // ← setter로 값 변경
    this.content = content;
    this.categoryType = categoryType;
}

실행되는 SQL

-- [1] post.updateTitleAndContent...() 호출 시 → 프록시 초기화를 위한 SELECT
SELECT p1_0.pid, p1_0.category_type, p1_0.content, p1_0.created_by, ...
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid
WHERE p1_0.pid = ?

-- [2] @Transactional 종료 시 → dirty checking에 의한 UPDATE
UPDATE post
SET category_type = ?, content = ?, created_date = ?,
    modified_by = ?, modified_date = ?, title = ?, uid = ?
WHERE pid = ?

총 2개의 쿼리가 실행된다.

getReferenceById(pid)는 프록시만 반환한다. (SELECT 없음)
post.updateTitleAndContentAndCategoryType()이 호출되면, 프록시의 실제 필드에 접근하게 되므로 프록시가 초기화된다. 이때 SELECT가 실행된다.
SELECT로 가져온 원본 데이터(스냅샷)를 영속성 컨텍스트가 보관한다.
setter로 title, content, categoryType이 변경된다.
@Transactional 메서드가 끝나면 트랜잭션이 커밋된다.
커밋 직전, Hibernate가 현재 엔티티 상태와 스냅샷(원본)을 비교한다 → Dirty Checking
변경된 필드가 발견되면 UPDATE SQL을 자동으로 실행한다.
save()를 호출하지 않아도 UPDATE가 실행되는 이유가 바로 이것이다.

deletePost() — 게시글 삭제

실제 코드

// PostService.java:68-74
@Transactional
public void deletePost(long pid, String uid) {
    System.out.println("DELETE POST");
    postRepository.deleteByIdAndUser_Uid(pid, uid);
    // ↑ Spring Data JPA가 메서드 이름을 파싱하여 쿼리 생성
}

실행되는 SQL

-- [1] 삭제 대상 Post 조회 (pid + uid 조건)
SELECT p1_0.pid, p1_0.category_type, p1_0.content, p1_0.created_by, ...
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid
WHERE p1_0.pid = ? AND u1_0.uid = ?

-- [2] Post의 User를 로딩 (EAGER이므로)
SELECT u1_0.uid, u1_0.created_by, u1_0.created_date, u1_0.email, ...
FROM user u1_0
WHERE u1_0.uid = ?

-- [3] CascadeType.ALL에 의해 연관된 PostComment 로딩
SELECT pc1_0.pid, pc1_0.id, pc1_0.content, pc1_0.created_by, ...
FROM post_comment pc1_0
LEFT JOIN user u1_0 ON u1_0.uid = pc1_0.uid
WHERE pc1_0.pid = ?

-- [4] Post 삭제 (댓글이 있었다면 댓글 먼저 삭제 후 Post 삭제)
DELETE FROM post WHERE pid = ?

총 3~4개의 쿼리가 실행된다.

Spring Data JPA의 deleteByXxx() 메서드는 내부적으로 먼저 SELECT로 엔티티를 조회한 뒤, EntityManager.remove()로 삭제한다. (바로 DELETE를 날리지 않는다!)
Post의 postComments에 CascadeType.ALL이 걸려있으므로, Post를 삭제하기 전에 연관된 PostComment도 함께 삭제해야 한다.
이를 위해 Hibernate는 PostComment도 미리 SELECT한다.
댓글이 있으면 댓글 DELETE → Post DELETE 순서로 실행된다.

JOIN이 발생하는지 vs 추가 SELECT가 발생하는지

조회 방식	User 로딩 방식	이유
`findById(pid)`	LEFT JOIN (한 방 쿼리)	EntityManager.find() 사용 → Hibernate가 EAGER 관계를 JOIN으로 최적화
`findAll()`	별도 SELECT (추가 쿼리)	JPQL 기반 → Hibernate가 EAGER이더라도 별도 SELECT로 처리
`findByTitleContains()`	별도 SELECT (추가 쿼리)	Spring Data JPA 쿼리 메서드 → JPQL 기반
`findByUser_UidContains()`	LEFT JOIN(조건) + 별도 SELECT(로딩)	WHERE 절을 위해 JOIN은 하지만, User 데이터 로딩은 별도 SELECT

실제 로그로 확인

findById(1) — JOIN 발생:

-- 한 번의 쿼리로 Post + User를 함께 가져온다
SELECT p1_0.pid, ..., u1_0.uid, u1_0.username, ...
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid    -- ← JOIN!
WHERE p1_0.pid = ?

findAll() (목록 조회) — 별도 SELECT 발생:

-- 1번째 쿼리: Post만 가져온다 (User JOIN 없음!)
SELECT p1_0.pid, ..., p1_0.uid
FROM post p1_0
LIMIT ?, ?

-- 2번째 쿼리: 각 Post의 User를 개별적으로 가져온다
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid = ?
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid = ?
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid = ?
-- ... Post 개수만큼 반복 (같은 uid면 영속성 컨텍스트 캐시로 생략)

참고로 각 Post의 User를 개별적으로 가져오는 쿼리는 findAll() 뒤에 이어지는 map(PostDto::from) 때문에 발생하는 것이 아니다.
Post가 User를 참조로 갖고 있고 이는 ManyToOne 관계이기 때문에 EAGER가 적용되어 findAll() 후 User를 가져온다.

왜 이런 차이가 생기는가?

findById()
  → EntityManager.find() 호출
  → Hibernate가 직접 SQL을 생성
  → EAGER 관계를 LEFT JOIN으로 최적화함

findAll(), findByXxx()
  → JPQL 실행 ("SELECT p FROM Post p" 등)
  → JPQL은 엔티티 기준이라 JOIN을 자동 추가하지 않음
  → Post만 SELECT한 뒤, EAGER 관계의 User를 별도 SELECT로 로딩
  → 이것이 N+1 문제의 원인!

해결 방법

방법	설명	적용 예시
Fetch Join (JPQL)	JPQL에 JOIN FETCH 추가	`@Query("SELECT p FROM Post p JOIN FETCH p.user")`
@EntityGraph	메서드에 어노테이션 추가	`@EntityGraph(attributePaths = {"user"})`
@BatchSize	N+1의 N을 줄임 (IN절로 묶음)	`@BatchSize(size = 100)` on User

N+1 문제에 대해 고민해보자

N+1 문제란?

1번의 쿼리로 N개의 데이터를 가져온 뒤,
각 데이터의 연관 엔티티를 가져오기 위해 N번의 추가 쿼리가 실행되는 것.
총 1 + N번의 쿼리가 실행된다.

N+1이 발생하는 시나리오

발생 위치: getPosts(), getPostsWithPage(), getPostsWithSearch()

// PostService.java:76-82
@Transactional
public List<PostDto> getPosts() {
    return postRepository.findAll().stream()   // ← Post Select 1번 + User Select N번
                         .map(PostDto::from)
                         .toList();
}

실제 SQL 로그

Post 쿼리: Post 10개 가져옴
User 쿼리: 10개 중 3개 게시글은 동일한 작성자. 총 8번의 User 쿼리 발생.

-- [1번째 쿼리] Post 목록 조회
SELECT p1_0.pid, p1_0.category_type, p1_0.content, ..., p1_0.uid
FROM post p1_0
LIMIT ?, ?

-- [2번째] 1번 Post의 User 조회
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid = ?    -- uid = 'user1'

-- [3번째] 2번 Post의 User 조회
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid = ?    -- uid = 'user2'

-- [4번째] 3번 Post의 User 조회
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid = ?    -- uid = 'user3'

-- ... uid가 같은 경우 영속성 컨텍스트 캐시로 생략되지만,
-- 서로 다른 uid가 있으면 그만큼 추가 쿼리 발생!

-- [마지막] count 쿼리 (페이징 시)
SELECT count(p1_0.pid) FROM post p1_0

해결 방법 ① — Fetch Join (JPQL)

// PostRepository.java에 추가
@Query("SELECT p FROM Post p JOIN FETCH p.user")
List<Post> findAllWithUser();

@Query("SELECT p FROM Post p JOIN FETCH p.user")
Page<Post> findAllWithUser(Pageable pageable);

실행되는 SQL:

-- 1번의 쿼리로 Post + User를 함께 가져온다
SELECT p1_0.pid, ..., u1_0.uid, u1_0.username, ...
FROM post p1_0
INNER JOIN user u1_0 ON u1_0.uid = p1_0.uid

해결 방법 ② — @EntityGraph

// PostRepository.java에 추가
@EntityGraph(attributePaths = {"user"})
@Override
List<Post> findAll();

@EntityGraph(attributePaths = {"user"})
Page<Post> findByTitleContains(String searchValue, Pageable pageable);

실행되는 SQL:

-- findAll()이지만 LEFT JOIN이 추가된다
SELECT p1_0.pid, ..., u1_0.uid, u1_0.username, ...
FROM post p1_0
LEFT JOIN user u1_0 ON u1_0.uid = p1_0.uid

해결 방법 ③ — @BatchSize

// User.java에 추가
@BatchSize(size = 100)    // ← 클래스 레벨에 추가
@Entity
public class User extends AuditingFields {
    // ...
}

실행되는 SQL:

-- Post 조회
SELECT p1_0.pid, ..., p1_0.uid FROM post p1_0

-- User를 한 번에 IN절로 묶어서 조회 (N번 → 1번으로 줄어듦)
SELECT u1_0.uid, ... FROM user u1_0 WHERE u1_0.uid IN (?, ?, ?, ?, ?, ?, ?, ?)

방법 비교

방법	장점	단점
Fetch Join	가장 확실, 1번의 쿼리	페이징과 함께 쓰면 메모리에서 페이징(경고 발생)
@EntityGraph	기존 메서드에 어노테이션만 추가	복잡한 조건에서는 한계
@BatchSize	기존 코드 변경 최소	완전한 1번은 아님(배치 수에 따라 나뉨)

[멋사 클라우드 5기] Day 28 - JWT 그런데 Redis를 곁들인

allluck777 — Tue, 10 Mar 2026 02:07:58 +0900

최근 Spring Security, JWT, Redis를 학습하며 보안에 대해 조금 더 고민해 볼 수 있었다.

기술 하나하나만 보면 단순해 보이는데, 이들을 조합해서 쓰면 구조는 복잡해지는 한편

훨씬 다양한 문제들을 해결할 수 있게 되는 점이 흥미롭다.
그럼에도 불구하고, 보안에 있어 완벽한 기술이란 없다고 한다.
다만, 최선의 트레이드오프를 결정하기 위해서
어떤 보안 위협을 최우선으로 방어할 것인지,
그리고 프로젝트의 복잡도와 아키텍처 사이에서
어느정도의 타협점을 찾을 것인지 고민하는 것이 중요한 문제라고 느껴졌다.
어제 정리한 내용들과 겹치는 부분이 있지만, 헷갈리던 점을 명확히 짚고 넘어가기 위해 다시 정리했다.

세션 기반 인증의 구조와 한계

세션 기반 인증이란?

HTTP는 Stateless(무상태) 프로토콜이다. 각 요청은 독립적이며, 서버는 이전 요청을 기억하지 않는다.

Stateless란? 서버가 클라이언트의 이전 상태를 기억하지 않는다는 의미다.

그런데 로그인은 "나 이전에 인증했어"라는 상태를 유지해야 한다.
이 간극을 메우기 위해 세션(Session)이 활용된다.

1. 사용자가 id/pw로 로그인 요청
2. 서버가 인증 후 세션 생성 → 서버 메모리에 저장
   { sessionId: "abc123", userId: 42, role: "USER" }
3. 클라이언트에게 sessionId만 쿠키로 전달
4. 이후 요청마다 쿠키에 sessionId 포함
5. 서버는 sessionId로 메모리 조회 → "아, userId 42구나"

단순하고 직관적이다. 지금도 많은 서비스에서 잘 쓰이고 있다.

서버가 한 대일 땐 문제없다

[클라이언트] ──→ [Server 1 (세션 메모리 보유)] ──→ 정상 응답

클라이언트는 항상 같은 서버와 통신하고, 서버 메모리에 세션이 있으니 문제없다.

서버가 여러 대가 되는 순간 문제가 생긴다

서비스가 성장하면 트래픽을 감당하기 위해 Scale-out을 한다.

Scale-out이란? 서버 1대의 성능을 높이는 대신(Scale-up), 서버를 여러 대 추가해 부하를 분산하는 방식이다.
앞단에 로드밸런서(Load Balancer)가 요청을 각 서버에 나눠준다.

[클라이언트]
     │
     ▼
[Load Balancer]
   ┌──┴──┐
   ▼     ▼
[S1]   [S2]   ← 세션이 S1 메모리에만 있음

시나리오:
1. 사용자가 S1으로 로그인 → 세션이 S1 메모리에 저장
2. 다음 요청을 로드밸런서가 S2로 라우팅
3. S2는 그 세션을 모름 → 로그인 풀림

서버가 늘어날수록 이 문제는 심각해진다.

해결하기 위한 시도들

① Sticky Session (고정 세션)

같은 사용자는 항상 같은 서버로 보내는 방식이다.

문제: 특정 서버에 부하가 몰릴 수 있다.
     그 서버가 죽으면 해당 사용자들은 전부 로그인이 풀린다.

② Session Replication (세션 복제)

모든 서버에 세션 데이터를 복제해서 동기화하는 방식이다.

문제: 서버가 늘어날수록 복제 비용이 기하급수적으로 증가한다.
      서버 10대면 모든 세션 변경사항을 10곳에 동기화해야 한다.

두 방식 모두 타당하나 완전한 해결책이 아니다. 그래서 나온 아이디어가 이것이다.

"서버가 상태를 아예 들고 있지 않으면 어떨까?"

이 아이디어에서 JWT가 등장한다.

JWT와 Refresh Token 패턴

왜 Stateless가 가능한가?

세션은 서버 메모리에서 "이 사람이 누구인지" 조회했다. JWT는 토큰 자체에 그 정보가 담겨있다.

세션 방식: 서버가 sessionId → 메모리 조회 → userId 확인
JWT  방식: 서버가 토큰의 서명만 검증 → 토큰 안의 userId 바로 사용

서버가 아무것도 저장하지 않아도 되니, 어느 서버로 요청이 가든 상관없다.

[클라이언트]
     │
     ▼
[Load Balancer]
   ┌──┴──┐
   ▼     ▼
[S1]   [S2]   ← 둘 다 토큰 서명만 검증하면 됨. 저장소 불필요.

Scale-out 문제가 깔끔하게 해결된다.

Access Token 만료 시간 딜레마

그런데 JWT는 한 번 발급하면 만료 시간이 될 때까지 항상 유효하다. 서버가 "이 토큰 무효화해줘"를 할 수 없다.
서버에서 저장해서 관리하지 않기 때문이다. 그래서 만료 시간 설정에 딜레마가 생긴다.

짧게 (예: 5분) → 탈취당해도 곧 만료. 보안적으로는 좋음. 하지만 5분마다 재로그인 필요 → UX 최악
길게 (예: 7일) → 편리함. 하지만 탈취당하면 7일 동안 무방비

Refresh Token를 곁들여 보자

이 딜레마를 해결하기 위해 두 종류의 토큰을 함께 쓰는 패턴이 고안됐다.

토큰	역할	만료 시간
Access Token	API 요청 시 인증에 사용	짧게 (5~30분)
Refresh Token	Access Token 재발급용	길게 (7~30일)

로그인 → Access Token (15분) + Refresh Token (7일) 발급

... 15분 후 Access Token 만료 ...

클라이언트가 Refresh Token 제출 → 서버가 검증 → 새 Access Token 발급

사용자는 재로그인 없이 계속 서비스를 이용하고, Access Token은 항상 짧게 유지된다.

⚠️ 그런데 Refresh Token도 탈취당하면 마찬가지 아닌가?

맞다. Refresh Token도 탈취당하면 문제가 생긴다. 게다가 만료 시간이 더 길다.

더 근본적인 문제가 있다. JWT 특성상 서버는 이 Refresh Token을 무효화할 방법이 없다.

공격자가 Refresh Token 탈취
→ 서버는 이 사실을 알 방법도, 막을 방법도 없음
→ 7일 동안 계속 새 Access Token 발급 가능
→ 사실상 영구 접근

여기서 Redis가 등장한다.

Redis까지 곁들여 보자

Redis란?

Redis(Remote Dictionary Server)는 데이터를 메모리(RAM)에 저장하는 인메모리 데이터 저장소다.

일반 DB(MySQL 등)는 디스크에 저장해 영구적이지만 상대적으로 느리다.

Redis는 메모리에 저장해 매우 빠르고 (1ms 이하), TTL 자동 만료 기능을 갖는다.

Key-Value 구조로 저장한다.

"refresh:allluck"           →  "eyJhbGc...BBB"
"blacklist:eyJhbGc...AAA"   →  "logout"

TTL (Time To Live) — Redis의 핵심 기능

저장할 때 만료 시간을 설정하면, 그 시간이 지나면 Redis가 자동으로 삭제한다.

// 7일 후 자동 삭제
redisTemplate.opsForValue().set("refresh:allluck", token, 7, TimeUnit.DAYS);

이 기능이 JWT와 결합했을 때 강력해진다.

Redis가 없으면 왜 Refresh Token 관리가 안 되는가?

Redis 없이 Refresh Token을 쓰면 서버는 어떤 Refresh Token을 발급했는지 알 방법이 없다.

클라이언트: "이 Refresh Token으로 새 Access Token 주세요"
서버:       "...서명은 유효한데, 내가 실제로 발급한 건지, 이미 무효화된 건지 알 방법이 없네"

비교할 정답지가 없다.

Redis가 생기면 서버가 "통제권"을 갖는다

Redis에 Refresh Token을 저장하는 순간, 서버는 정답지를 갖게 된다.

Redis: { "refresh:allluck" → "eyJhbGc...BBB" }

이제 가능해지는 것들:

클라이언트가 보낸 토큰과 Redis 값 비교 → 불일치 시 거부
비밀번호 변경, 계정 정지 시 Redis에서 삭제 → 즉시 무효화
탈취 의심 시 삭제 → 이후 재발급 요청 전부 차단

Access Token과 Refresh Token의 저장위치에 대해 고민해보자

브라우저에서 토큰을 저장할 수 있는 곳은 크게 세 곳이다.

저장 위치	특징	탈취 위협
localStorage	새로고침/탭 종료 후에도 영구 유지	XSS 공격으로 탈취 가능
~~Cookie (일반)~~	JS에서 접근 가능	XSS 공격으로 탈취 가능
메모리 (JS 변수)	페이지 새로고침 시 사라짐	JS로 접근 불가, XSS에 안전
HttpOnly Cookie	JS에서 접근 불가, 브라우저가 자동으로 요청에 포함	XSS로 탈취 불가

XSS(Cross-Site Scripting)란? 공격자가 웹페이지에 악성 JS 코드를 심어서, 그 페이지를 방문한 사용자의 브라우저에서 코드가 실행되게 하는 공격이다. localStorage나 일반 쿠키에 저장된 값은 JS로 읽을 수 있어서 그대로 탈취된다.

Access Token을 메모리(JS 변수)에 저장하면 JS 코드가 접근할 수 없으니 XSS 공격으로 훔쳐갈 수가 없다.

하지만 새로고침하면 사라지잖아?!

바로 재발급을 받아서 사용할 수 있다

1. 사용자가 새로고침
2. 메모리의 Access Token 사라짐
3. 앱이 초기화되면서 "Access Token 없네, 로그인 상태 확인 필요"
4. HttpOnly Cookie에 담긴 Refresh Token으로 /reissue 요청 자동 발송
   ← 사용자는 이 과정을 모름. 보통 100ms 이내
5. 새 Access Token 발급 → 메모리에 저장
6. 사용자 입장에선 그냥 새로고침 후 정상 이용

Refresh Token을 HttpOnly Cookie에 저장하는 이유

HttpOnly는 쿠키에 붙일 수 있는 속성 중 하나다.

HttpOnly 속성이 붙은 쿠키는 JS에서 아예 읽을 수 없다.

브라우저가 요청 시 자동으로 포함시켜 줄 뿐이다.

// 이런 코드로 접근 시도해도
document.cookie  // HttpOnly 쿠키는 여기에 안 나온다

즉, XSS 공격자가 JS를 심어도 Refresh Token을 읽어갈 수 없다.

전체 저장 전략의 의도

Access Token  → 메모리 저장
  이유: 수명이 짧아서 새로고침 시 재발급해도 부담 없음
        JS 접근 불가 → XSS 안전

Refresh Token → HttpOnly Cookie 저장
  이유: 수명이 길어서 영구 보관 필요
        HttpOnly → JS 접근 불가 → XSS 안전
        새로고침 시에도 유지되어 자동 재발급에 활용

둘 다 JS에서 읽을 수 없게 설계한 것이다.

Access Token은 메모리로,

Refresh Token은 HttpOnly Cookie로,

각자의 방식으로 XSS를 막는다.

그런데 한 가지 아쉬운 점이 있다.

Access Token과 Refresh Token 둘을 비교한다면 보안적으로 더 중요한 대상은 Refresh Token이다. 유효기간이 길기 때문이다. 탈취당하면 만료전까지 계속해서 사용될 우려가 있다. 하지만 Access Token이 만약 메모리에서 관리된다면, 사용자의 페이지 이탈 또는 새로고침 등의 이유로 쉽게 소실될 수 있다. 이때 소실된 Access Token에 대하여 새로 발급받기 위해 Refresh Token을 담은 https 요청을 보내게된다. 재발급 요청이 빈번해진다는 것은 Refresh Token이 네트워크를 타는 빈도도 증가하는 것이다. 아주 미세하게지만 Refresh Token의 탈취 기회가 증가되는게 아닐까?

사실 이 부분도 어떻게 보면 트레이드오프라고 볼 수 있다.
Access Token을 메모리에서 관리하는 대신 localStorage에 저장한다고 가정해보자. 새로고침해도 유지가 되므로 재발급 빈도는 낮을 것이다. 하지만 JS로 읽힐 수 있다는 문제로 인해 XSS 공격에 노출되기 쉽다.

Access Token을 HttpOnly Cookie로 관리한다고 가정해보자. 또 다른 문제가 생긴다. 브라우저는 쿠키를 자동으로 요청에 포함시키기 때문에 CSRF 공격에 취약해진다.

즉, Access Token을 메모리에서 관리함으로써 발생할 수 있는 (희박한) 네트워크 노출 위협은 LocalStorage 또는 Cookie로 관리할 때 발생할 수 있는 XSS 위협, CSRF 위협보다는 훨씬 감수할만한 것이다.

시나리오로 확인하기

id:allluck / pw:1234 로 로그인하고, API 요청 후, 로그아웃하는 시나리오

일반 API 요청 (Access Token 유효)

GET /api/mypage + Authorization: Bearer eyJhbGc...AAA

서버:
1. 서명 검증 → 유효
2. 만료 시간 확인 → 유효
3. 블랙리스트 확인: Redis에 "blacklist:eyJhbGc...AAA" 없음
4. 정상 응답 ✅

Redis 상태 변화 없음.

Access Token 만료 → 재발급

POST /reissue + Refresh Token eyJhbGc...BBB

서버:
1. Refresh Token 서명 검증 → 유효
2. 토큰에서 userId 추출 → "allluck"
3. Redis 조회: GET "refresh:allluck" → "eyJhbGc...BBB"
4. 클라이언트 값 == Redis 값 → 일치 ✅
5. 새 Access Token 발급: eyJhbGc...CCC

Redis 상태 변화 없음. Refresh Token은 그대로 유지.

로그아웃

POST /logout + Authorization: Bearer eyJhbGc...CCC

서버:
1. Access Token 남은 만료 시간 계산 → 720초
2. Access Token 블랙리스트 등록
3. Refresh Token 삭제

Redis 변화:

# 블랙리스트 추가
SET "blacklist:eyJhbGc...CCC"  →  "logout"  (TTL: 720초)

# Refresh Token 삭제
DEL "refresh:allluck"

로그아웃 후 공격 시도

탈취한 Access Token으로 API 요청:

서버:
1. 서명 검증 → 유효 (서명은 멀쩡함)
2. 만료 확인 → 아직 유효 (720초 남음)
3. 블랙리스트 확인: "blacklist:eyJhbGc...CCC" 존재 → 거부 ❌
→ 401 Unauthorized

탈취한 Refresh Token으로 재발급 시도:

서버:
1. 서명 검증 → 유효
2. userId 추출 → "allluck"
3. Redis 조회: "refresh:allluck" → null (삭제됨) → 거부 ❌
→ 401 Unauthorized

그런데, 이건 Stateless로 보기힘들지 않을까?

Redis에 상태를 저장하는 순간, 완전한 Stateless는 아니다.

정확히 구분하면 이렇다.

순수 JWT          → 완전한 Stateless  (하지만 로그아웃 무효화 불가)
JWT + Redis       → 부분적 Stateless  (보안 확보, 대신 상태 일부 존재)
순수 Session      → 완전한 Stateful

제대로된 로그아웃을 구현하기 위해서는 어느정도의 트레이드오프를 인정하고,
JWT + Redis 구조로 만들어야 한다.

완벽한 Stateless 보다 실제로 안전한 인증이 더 중요하기 때문이다.

그럼 세션의 Scale-out 문제가 다시 생기는 건가?

Redis를 쓰면 서버에 상태가 생기는 거니까 세션과 같은 문제가 발생하는게 않을까?

조금 다르다. 세션과 Redis의 구조는 다르기 때문이다.

세션 문제의 본질

세션은 각 서버의 메모리에 저장된다.

사용자가 S1으로 로그인 → 세션이 S1 메모리에 저장
로드밸런서가 다음 요청을 S2로 라우팅
→ S2에는 그 세션이 없음 → 인증 실패

서버가 늘어날수록 데이터가 흩어진다.

Redis는 외부 공유 저장소다

Redis는 서버 안에 있지 않다. 모든 서버가 바라보는 독립적인 외부 저장소다.

Server 1 ─┐
Server 2 ─┼──→ Redis (중앙 저장소)
Server 3 ─┘

어느 서버로 요청이 가든, 모두 같은 Redis를 조회한다.

사용자가 S1으로 로그인 → Refresh Token이 Redis에 저장
로드밸런서가 다음 요청을 S3으로 라우팅
→ S3도 같은 Redis를 조회 → 정상 동작 ✅

Redis 자체의 고가용성

그럼 Redis가 단일 장애점(Single Point of Failure)이 되지 않냐는 의문이 생긴다.

Redis 자체도 Scale-out이 가능하다.

Redis Sentinel: 마스터-슬레이브 구조로 고가용성 확보. 마스터가 죽으면 슬레이브가 자동으로 마스터 승격
Redis Cluster: 데이터를 여러 노드에 분산 저장

애플리케이션 서버와 Redis를 독립적으로 각각 확장할 수 있다.

그럼 애초에 세션 + Redis면 됐던 거 아닌가?

맞다. 그리고 실제로 그렇게도 한다.

Spring Session + Redis라는 이름으로 이미 널리 쓰이는 구조라고 한다.

세션 ID만 쿠키로 클라이언트에 전달
세션 데이터는 Redis에 저장
→ 어느 서버로 요청이 가도 Redis에서 꺼내면 됨
→ Scale-out 문제 해결

그러면 JWT는 왜 쓰는거야...?

JWT가 세션의 "유일한 해결책"인 것은 아니다. JWT만의 진짜 장점이 따로 있다.

① MSA 환경에서의 독립적 인증

마이크로서비스 환경에서 서비스가 수십 개라면, 각 서비스마다 Redis 연결을 붙이는 게 부담이다. JWT는 서명 검증만으로 Redis 연결없이 독립적으로 인증이 가능하다.

Session + Redis 방식:
서비스 A → Redis 조회 → 인증
서비스 B → Redis 조회 → 인증
서비스 C → Redis 조회 → 인증  ← 모든 서비스가 Redis에 의존

JWT 방식 (이상적):
서비스 A → 서명 검증만 → 인증  ← Redis 불필요
서비스 B → 서명 검증만 → 인증
서비스 C → 서명 검증만 → 인증

② 모바일 / 서드파티 환경

세션은 쿠키 기반이라 브라우저에 최적화되어 있다. 모바일 앱이나 외부 API 클라이언트에서는 JWT가 훨씬 다루기 편하다.

③ 단순한 서비스라면 Session + Redis가 오히려 나을 수 있다

모놀리식 웹 서비스라면 JWT의 복잡한 토큰 관리, 블랙리스트 처리 없이 세션 만료시키면 끝이다.

트레이드오프를 알고 선택하자

각 방식의 특성을 비교하면 이렇다.

항목	Session	Session + Redis	순수 JWT	JWT + Redis
Scale-out	❌ 취약	✅	✅	✅
로그아웃 무효화	✅	✅	❌	✅
강제 로그아웃	✅	✅	❌	✅
MSA 환경	❌	△	✅	△
모바일/서드파티	❌	❌	✅	✅
인프라 복잡도	낮음	중간	낮음	중간
완전한 Stateless	❌	❌	✅	❌

어떤 기술이 더 좋다는 건 없다. 서비스의 규모, 구조, 클라이언트 환경에 따라 선택이 달라진다.

[멋사 클라우드 5기] Day 26, 27 - Spring Security & JWT

allluck777 — Mon, 9 Mar 2026 01:15:57 +0900

1. 인증과 인가

개념	의미	비유
인증 (Authentication)	"너는 누구인가?"를 확인하는 과정	건물 출입 시 신분증을 보여주는 것
인가 (Authorization)	"너는 이것을 할 수 있는가?"를 확인하는 과정	신분증 확인 후 특정 층에 들어갈 권한이 있는지 확인하는 것

예를 들어, 사용자가 로그인하면 인증이 완료된 것이고,
로그인한 사용자가 관리자 페이지에 접근하려 할 때 관리자 권한이 있는지 확인하는 것이 인가이다.

2. 세션 방식의 한계와 JWT의 등장

세션(Session) 방식이란

JWT가 등장하기 전, 대부분의 웹 서버는 세션(Session) 방식으로 사용자를 관리했다.

세션 방식 동작 흐름:

1. 사용자가 로그인 → 서버가 세션 생성 → 서버 메모리에 저장
2. 서버가 클라이언트에게 Session ID(세션 식별자) 발급 (보통 쿠키에 저장)
3. 클라이언트가 요청할 때마다 Session ID를 보냄
4. 서버가 메모리에서 해당 Session ID를 찾아 사용자 확인

세션 방식의 문제점

서버 메모리 부담: 동시 접속자 수가 많을수록 메모리 사용량 급증
수평 확장(Scale-out) 어려움: 서버 A에서 발급한 세션을 서버 B는 모른다

사용자 ---> [서버 A] (세션 있음) ✅
사용자 ---> [서버 B] (세션 없음) ❌ → 다시 로그인 요구

Scale-out(수평 확장)이란? 서버 한 대의 성능을 올리는 대신, 동일한 서버를 여러 대 추가하여 부하를 분산하는 방식이다.
현대의 클라우드 환경에서 매우 일반적이다.

MSA 환경에서 복잡성 증가: 마이크로서비스마다 세션을 따로 관리하거나 공유 스토리지(Redis 등)가 필요하다

MSA(Microservices Architecture)란? 하나의 큰 애플리케이션을 여러 개의 작은 독립적인 서비스로 나누는 설계 방식이다.
예를 들어 쇼핑몰을 '상품 서비스', '주문 서비스', '결제 서비스'로 분리하는 것이다.

이러한 한계를 극복하기 위해 서버가 상태를 저장하지 않아도 되는 인증 방식이 필요했고, 그 해답이 바로 JWT이다.

3. JWT란 무엇인가

JWT(JSON Web Token)는 당사자 간에 정보를 JSON 형태로 안전하게 전달하기 위한 개방형 표준(RFC 7519)이다.

RFC(Request for Comments)란? 인터넷 기술의 표준 문서 시리즈다. RFC 7519는 JWT의 공식 명세(spec)다.

핵심 특징:

자기완결적(Self-contained): 토큰 자체에 사용자 정보가 담겨 있다.
서버가 DB나 메모리를 조회하지 않아도 토큰만으로 사용자를 검증할 수 있다.
서명(Signature) 포함: 토큰이 위조되지 않았음을 수학적으로 검증할 수 있다.
URL-safe: 토큰이 URL에 포함되어도 깨지지 않는 문자로만 구성된다.

4. JWT의 구조

JWT는 3개의 파트로 구성되며, 각 파트를 점(.)으로 구분한다.

xxxxx.yyyyy.zzzzz
  │      │      │
Header Payload Signature

실제 JWT 예시:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6Iuq5jOuhneyekCIsInJvbGUiOiJVU0VSIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwMDM2MDB9
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

4-1. Header (헤더)

헤더는 토큰의 타입과 서명 알고리즘 정보를 담는다.

{
  "alg": "HS256",
  "typ": "JWT"
}

필드	의미
alg	서명에 사용된 알고리즘 (예: HS256, RS256)
typ	토큰 타입 (항상 "JWT")

이 JSON을 Base64Url 인코딩하면 헤더 파트가 된다.

Base64Url 인코딩이란? 바이너리 데이터나 텍스트를 URL에서 안전하게 사용할 수 있는 64개의 문자(A-Z, a-z, 0-9, -, _)로 변환하는 방식이다. 암호화가 아니라 단순 인코딩이므로, 누구나 디코딩해서 원본 내용을 볼 수 있다.

4-2. Payload (페이로드)

페이로드는 실제로 전달하려는 데이터(클레임) 를 담는다.

클레임(Claim)이란? "주장"이라는 뜻으로, JWT 안에 담긴 키-값 쌍의 정보를 의미한다.
"이 사용자의 ID는 123이다", "이 사용자의 역할은 ADMIN이다" 같은 주장(정보)들이다.

클레임은 3가지 종류로 나뉜다:

① 등록된 클레임 (Registered Claims) - 표준으로 정의된 예약어

클레임	전체 이름	의미
iss	Issuer	토큰 발급자 (예: "my-app")
sub	Subject	토큰 주체 (보통 사용자 ID)
aud	Audience	토큰 수신자 (예: "mobile-app")
exp	Expiration Time	만료 시각 (Unix 타임스탬프)
nbf	Not Before	이 시각 이전에는 토큰 사용 불가
iat	Issued At	발급 시각
jti	JWT ID	토큰 고유 식별자

Unix 타임스탬프란? 1970년 1월 1일 00:00:00 UTC부터 현재까지 경과한 초(second) 의 수다.
예를 들어 1700000000은 2023년 11월 14일을 나타낸다.

② 공개 클레임 (Public Claims) - 충돌 방지를 위해 URI 형식 권장

{
  "https://myapp.com/roles": ["ADMIN", "USER"]
}

③ 비공개 클레임 (Private Claims) - 당사자 간 합의한 커스텀 정보

{
  "userId": "user123",
  "name": "홍길동",
  "role": "USER"
}

전체 Payload 예시:

{
  "sub": "user123",
  "name": "홍길동",
  "role": "USER",
  "iat": 1700000000,
  "exp": 1700003600
}

⚠️ 중요: Payload도 Base64Url로 인코딩될 뿐, 암호화되지 않는다.
누구나 디코딩해서 내용을 볼 수 있으므로, 비밀번호나 카드번호 같은 민감한 정보를 넣으면 절대 안 된다.

4-3. Signature (서명)

서명은 토큰이 위조되지 않았음을 검증하는 핵심 파트다.

서명 생성 공식 (HS256 기준):

Signature = HMAC-SHA256(
  Base64Url(Header) + "." + Base64Url(Payload),
  서버의_비밀키(Secret Key)
)

HMAC(Hash-based Message Authentication Code)이란?
비밀키와 해시 함수를 조합하여 메시지의 무결성(변조 여부)을 검증하는 알고리즘이다.
비밀키를 모르면 같은 서명을 만들 수 없다.

SHA-256이란? SHA(Secure Hash Algorithm)의 256비트 버전이다.
어떤 데이터도 항상 256비트(32바이트)의 고정된 해시값으로 변환한다.
원본 데이터가 1비트라도 바뀌면 해시값이 완전히 달라진다.

서명의 역할:

공격자가 Payload를 수정하려 시도:
  원본:  {"role": "USER"}   → Signature: abc123
  조작:  {"role": "ADMIN"}  → 새 Signature: xyz789  ← 기존 서명과 다름!

서버가 수신 시 서명을 재계산 → 토큰의 서명과 불일치 → 토큰 거부 ✅

5. JWT의 동작 원리

전체 흐름

클라이언트                          서버
    │                                │
    │  1. POST /login                │
    │  { id: "user", pw: "1234" }    │
    │ ─────────────────────────────> │
    │                                │ 2. DB에서 사용자 검증
    │                                │ 3. JWT 생성
    │  4. 200 OK                     │
    │  { token: "eyJ..." }           │
    │ <───────────────────────────── │
    │                                │
    │  5. GET /api/profile           │
    │  Authorization: Bearer eyJ...  │
    │ ─────────────────────────────> │
    │                                │ 6. JWT 서명 검증
    │                                │ 7. Payload에서 사용자 정보 추출
    │  8. 200 OK { ... }             │
    │ <───────────────────────────── │

Bearer 토큰이란? HTTP 인증 스킴(scheme) 중 하나로, "이 토큰을 소지한 자(Bearer)에게 접근을 허용한다"는 의미다.
보통 Authorization: Bearer <token> 헤더 형식으로 전달한다.

서버의 JWT 검증 과정

수신한 JWT: header.payload.signature

1. header와 payload를 추출
2. 서버의 비밀키로 signature를 재계산
3. 재계산한 signature == 수신한 signature ? → 위조 없음 ✅
4. exp(만료 시각) 확인 → 현재 시각보다 이전이면 만료 ❌
5. 검증 성공 → Payload에서 사용자 정보 사용

6. JWT의 종류: JWS vs JWE

JWT는 사용 목적에 따라 두 가지 형태로 구분된다.

구분	이름	특징
JWS	JSON Web Signature	서명만 포함 → 내용은 누구나 읽을 수 있음
JWE	JSON Web Encryption	내용까지 암호화 → 키 없이는 내용 불가독

일반적으로 "JWT"라고 부르는 것은 대부분 JWS다.

7. Spring Security란 무엇인가

왜 Spring Security를 사용하는가

앞에서 JWT라는 인증 기술을 살펴보았다.
그런데 실제 Spring 기반 애플리케이션에서 인증/인가를 구현하려면, JWT를 검증하는 로직만 있으면 되는 것이 아니다.
보안은 생각보다 고려할 것이 매우 많다.

직접 구현할 경우 신경 써야 하는 것들:

비밀번호 암호화 및 안전한 저장
세션 관리 및 세션 고정 공격(Session Fixation) 방지
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조) 방지
CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유) 설정
Remember-Me 기능
OAuth2 / JWT 기반 인증
권한별 접근 제어
보안 관련 HTTP 헤더 설정

이 모든 것을 직접 구현하면 코드가 복잡해지고, 보안 취약점이 발생할 가능성이 높다. Spring Security는 Spring 기반 애플리케이션의 인증과 인가를 담당하는 보안 프레임워크로, 이러한 보안 기능들을 검증된 방식으로 제공한다. 덕분에 개발자는 비즈니스 로직에 집중할 수 있다.

8. 핵심 아키텍처: 두 컨테이너와 필터 체인

Spring Security의 동작 원리를 이해하려면 전체 구조를 먼저 파악해야 한다.
그런데 그 전에, Spring Security가 왜 이런 구조를 가지게 되었는지를 이해하기 위해 "컨테이너"라는 개념부터 짚고 넘어가자.

8.1 컨테이너(Container)란

컨테이너는 "객체의 생명주기를 대신 관리해주는 환경"이라고 이해하면 된다.

우리가 직접 new로 객체를 만들고, 필요 없으면 버리는 대신,
컨테이너가 "이 객체를 언제 만들고, 언제 초기화하고, 언제 제거할지"를 알아서 관리해주는 것이다.

Java 웹 애플리케이션에는 이런 컨테이너가 두 개 공존한다.

8.2 서블릿 컨테이너 (Servlet Container)

Spring Boot로 프로젝트를 실행하면 내장 Tomcat이 자동으로 뜨는데, 이 Tomcat이 바로 서블릿 컨테이너이다.

서블릿 컨테이너가 관리하는 것들은 다음과 같다.

Servlet — HTTP 요청을 받아서 처리하는 객체. Spring MVC의 DispatcherServlet도 결국 하나의 Servlet이다.
Filter — Servlet에 요청이 도달하기 전에 가로채는 객체.
Listener — 특정 이벤트(서버 시작, 세션 생성 등)를 감지하는 객체.

핵심은, 서블릿 컨테이너는 Java EE(Jakarta EE) 표준 스펙에 따라 동작한다는 것이다.
Tomcat은 Spring이 뭔지 모른다. 그냥 "Servlet 스펙에 맞는 객체"만 관리한다.

┌─── 서블릿 컨테이너 (Tomcat) ───────────────────┐
│                                            │
│  Filter A → Filter B → DispatcherServlet   │
│                                            │
│  "나는 Servlet, Filter, Listener만 안다.      │
│   Spring Bean? 그게 뭔데?"                   │
│                                            │
└────────────────────────────────────────────┘

8.3 스프링 컨테이너 (Spring Container)

ApplicationContext라고도 부른다.
@Component, @Service, @Repository, @Bean 등으로 등록하는 모든 객체(Bean)를 생성하고 관리하는 주체이다.

┌─── 스프링 컨테이너 (ApplicationContext) ───────┐
│                                            │
│  @Service UserService                      │
│  @Repository UserRepository                │
│  @Component JwtTokenProvider               │
│  @Bean SecurityFilterChain                 │
│  @Bean PasswordEncoder                     │
│                                            │
│  "나는 Spring Bean을 관리한다.                 │
│   Servlet Filter? 그건 내 관할이 아닌데?"       │
│                                            │
└────────────────────────────────────────────┘

Spring Security의 모든 보안 로직(SecurityFilterChain, AuthenticationManager, 각종 Provider 등)은 Spring Bean이다.
즉, 스프링 컨테이너 안에 산다.

8.4 두 컨테이너의 충돌: 문제 상황

이제 문제가 보인다.

HTTP 요청이 들어오면

   서블릿 컨테이너가 먼저 처리한다
   (Filter들이 순서대로 실행됨)
         │
         ▼
   그 다음에 DispatcherServlet에 도달한다
   (여기서부터 Spring 세계)
         │
         ▼
   Controller → Service → Repository

Filter는 서블릿 컨테이너가 관리하는 것이고,
Spring Security의 보안 로직은 스프링 컨테이너가 관리하는 Bean이다.

그런데 Spring Security는 Filter 단계에서 보안 처리를 하고 싶다.
Controller에 도달하기 전에 인증/인가를 해야 하니까.
하지만 서블릿 컨테이너는 Spring Bean을 모른다.

8.5 해결: DelegatingFilterProxy

이 문제를 해결하기 위해 DelegatingFilterProxy가 존재한다.
이 녀석은 서블릿 필터이면서 Spring Bean에게 실제 작업을 위임(delegate)하는 다리 역할을 한다.

┌─── 서블릿 컨테이너 ────────────────────────────────────────────┐
│                                                            │
│  Filter A                                                  │
│     │                                                      │
│  DelegatingFilterProxy  ──── "나는 서블릿 필터인데,             │
│     │                         실제 일은 Spring Bean에게       │
│     │                         시킬게"                        │
│     │                                                      │
│     │    ┌─── 스프링 컨테이너 ─────────────────────────┐       │
│     └───▶│  FilterChainProxy (Spring Bean)         │       │
│          │    ├── SecurityFilter 1                 │       │
│          │    ├── SecurityFilter 2                 │       │
│          │    ├── SecurityFilter 3                 │       │
│          │    └── ...                              │       │
│          └─────────────────────────────────────────┘       │
│     │                                                      │
│  Filter C                                                  │
│     │                                                      │
│  DispatcherServlet                                         │
└────────────────────────────────────────────────────────────┘

DelegatingFilterProxy는 서블릿 컨테이너 입장에서는 평범한 Filter이다. 그래서 서블릿 컨테이너가 관리할 수 있다.

하지만 이 녀석은 자기가 직접 보안 처리를 하지 않는다.
대신 스프링 컨테이너에서 FilterChainProxy라는 Bean을 찾아서, 요청 처리를 위임(delegate)한다.
이름 그대로 "위임하는 필터 프록시"인 것이다.

이렇게 하면 서블릿 컨테이너의 Filter 자리에 끼어들면서도, 실제 보안 로직은 Spring이 관리하는 Bean들이 수행할 수 있게 된다.

8.6 FilterChainProxy와 SecurityFilterChain

FilterChainProxy는 Spring Security의 핵심 엔진이다.
이 안에 하나 이상의 SecurityFilterChain이 등록되어 있다.

SecurityFilterChain은 "이 URL 패턴에 대해서는 이 필터들을 적용하라"는 규칙의 묶음이다.

FilterChainProxy
├── SecurityFilterChain ("/api/**")
│   ├── CorsFilter
│   ├── CsrfFilter (비활성)
│   ├── JwtAuthenticationFilter
│   └── AuthorizationFilter
│
└── SecurityFilterChain ("/**")
    ├── CorsFilter
    ├── CsrfFilter
    ├── UsernamePasswordAuthenticationFilter
    ├── SessionManagementFilter
    └── AuthorizationFilter

위 예시를 보면, /api/** 경로와 그 외 경로에 서로 다른 보안 정책을 적용할 수 있다.
API 요청에는 JWT 기반 인증을, 웹 페이지 요청에는 세션 기반 인증을 적용하는 식이다.

8.7 두 컨테이너 정리

	서블릿 컨테이너	스프링 컨테이너
대표 예시	Tomcat, Jetty	ApplicationContext
관리 대상	Servlet, Filter, Listener	@Component, @Bean 등 모든 Spring Bean
기반 스펙	Java EE / Jakarta EE	Spring Framework
요청 처리 순서	먼저 (Filter 단계)	나중에 (Controller 단계)

두 컨테이너는 별개의 세계이고, DelegatingFilterProxy가 두 세계를 연결하는 다리 역할을 한다.
Spring Security의 모든 필터가 Controller보다 먼저 실행될 수 있는 이유가 바로 이 구조 덕분이다.

8.8 전체 아키텍처 다이어그램

[클라이언트 요청]
       │
       ▼
┌─────────────────────────┐
│   Servlet Filter Chain  │  ← 서블릿 컨테이너(Tomcat 등)가 관리
│   ┌───────────────────┐ │
│   │ DelegatingFilter  │ │  ← Spring Security의 진입점
│   │ Proxy             │ │
│   └───────┬───────────┘ │
│           │             │
│   ┌───────▼───────────┐ │
│   │ FilterChainProxy  │ │  ← 실제 Security 필터들을 관리
│   │ ┌───────────────┐ │ │
│   │ │ Security      │ │ │
│   │ │ Filter Chain  │ │ │  ← 여러 보안 필터가 순서대로 실행
│   │ │ (15개 이상)     │ │ │
│   │ └───────────────┘ │ │
│   └───────────────────┘ │
└─────────────────────────┘
       │
       ▼
  [DispatcherServlet → Controller]

9. Security Filter Chain의 주요 필터들

SecurityFilterChain 안에는 약 15개 이상의 필터가 정해진 순서대로 실행된다.

주요 필터 실행 순서

요청(Request) 들어옴
    │
    ▼
[SecurityContextPersistenceFilter]
    │  → 이전 요청에서 저장된 SecurityContext를 복원한다
    ▼
[CorsFilter]
    │  → CORS 정책을 확인한다
    ▼
[CsrfFilter]
    │  → CSRF 토큰을 검증한다
    ▼
[LogoutFilter]
    │  → 로그아웃 요청이면 로그아웃 처리를 한다
    ▼
[UsernamePasswordAuthenticationFilter]
    │  → 로그인 요청이면 아이디/비밀번호로 인증을 시도한다
    ▼
[DefaultLoginPageGeneratingFilter]
    │  → 커스텀 로그인 페이지가 없으면 기본 로그인 페이지를 생성한다
    ▼
[BasicAuthenticationFilter]
    │  → HTTP Basic 인증 헤더가 있으면 처리한다
    ▼
[SessionManagementFilter]
    │  → 세션 관련 처리를 한다 (세션 고정 공격 방지 등)
    ▼
[ExceptionTranslationFilter]
    │  → 보안 예외를 적절한 HTTP 응답으로 변환한다
    ▼
[AuthorizationFilter]
    │  → 최종적으로 해당 리소스에 접근할 권한이 있는지 확인한다
    ▼
  Controller에 도달

각 필터는 자기가 처리할 요청이 아니면 아무것도 하지 않고 다음 필터로 넘긴다.
예를 들어, UsernamePasswordAuthenticationFilter는 POST /login 요청일 때만 동작하고, 그 외의 요청은 그냥 통과시킨다.

10. 인증(Authentication) 동작 원리

인증은 Spring Security에서 가장 중요한 부분이다.
사용자가 로그인할 때 내부에서 어떤 일이 벌어지는지 단계별로 살펴보자.

10.1 인증 처리 흐름

[사용자: POST /login (username, password)]
           │
           ▼
┌──────────────────────────────────────┐
│ UsernamePasswordAuthenticationFilter │
│   → UsernamePasswordAuthentication   │
│     Token 생성 (미인증 상태)             │
└──────────────┬───────────────────────┘
               │
               ▼
┌──────────────────────────┐
│    AuthenticationManager │  ← 인증 작업을 총괄하는 관리자
│    (ProviderManager)     │
└──────────────┬───────────┘
               │ 적절한 Provider에게 위임
               ▼
┌──────────────────────────┐
│  AuthenticationProvider  │  ← 실제 인증 로직 수행
│  (DaoAuthentication      │
│   Provider)              │
│                          │
│  1. UserDetailsService   │  ← DB에서 사용자 정보 조회
│     .loadUserByUsername()│
│  2. PasswordEncoder      │  ← 비밀번호 일치 여부 확인
│     .matches()           │
└──────────────┬───────────┘
               │
          인증 성공 시
               │
               ▼
┌───────────────────────────┐
│ SecurityContextHolder     │
│  └── SecurityContext      │
│       └── Authentication  │  ← 인증된 사용자 정보 저장
│            ├── Principal  │     (이후 어디서든 꺼내 쓸 수 있음)
│            ├── Credentials│
│            └── Authorities│
└───────────────────────────┘

10.2 각 구성 요소 상세 설명

Authentication 객체

Authentication은 인증 정보를 담는 객체이다. 크게 세 가지 정보를 가지고 있다.

속성	설명
Principal	인증된 사용자 자체를 나타낸다. 보통 UserDetails 객체가 들어간다
Credentials	비밀번호 등 인증에 사용된 자격 증명이다. 인증 후에는 보안을 위해 비워진다
Authorities	사용자에게 부여된 권한 목록이다. ROLE_USER, ROLE_ADMIN 등이 들어간다

이 객체는 인증 전에는 "사용자가 인증을 요청한 정보"를, 인증 후에는 "인증이 완료된 사용자의 정보"를 담는다.

AuthenticationManager

AuthenticationManager는 인터페이스이며, 기본 구현체는 ProviderManager이다. 이 녀석의 역할은 단순하다.
자신이 가지고 있는 여러 AuthenticationProvider 중 해당 인증 요청을 처리할 수 있는 Provider를 찾아서 인증 작업을 위임하는 것이다.

왜 직접 인증하지 않고 Provider에게 위임할까? 인증 방식이 여러 가지일 수 있기 때문이다. 아이디/비밀번호 인증, OAuth2 인증, JWT 인증 등 각기 다른 방식을 각각의 Provider가 처리하도록 분리한 것이다.

AuthenticationProvider

AuthenticationProvider는 실제로 인증 로직을 수행하는 컴포넌트이다.
가장 일반적으로 사용되는 구현체는 DaoAuthenticationProvider이다.

DaoAuthenticationProvider는 내부적으로 두 가지를 사용한다.

1) UserDetailsService — 사용자 정보를 어디서 가져올지를 정의한다.

public interface UserDetailsService {
    UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}

이 인터페이스를 구현하여 DB, LDAP, 메모리 등 원하는 곳에서 사용자 정보를 가져올 수 있다.
가장 흔한 패턴은 DB에서 사용자를 조회하는 것이다.

2) PasswordEncoder — 비밀번호를 안전하게 비교한다.

사용자가 입력한 비밀번호(평문)와 DB에 저장된 비밀번호(암호화된 형태)를 비교한다. Spring Security는 기본적으로 BCryptPasswordEncoder를 권장한다.

SecurityContextHolder

인증에 성공하면 Authentication 객체가 SecurityContext에 저장되고,
이 SecurityContext는 SecurityContextHolder가 관리한다.

SecurityContextHolder는 기본적으로 ThreadLocal 전략을 사용한다. ThreadLocal이란 각 쓰레드(Thread)마다 독립적인 저장 공간을 제공하는 기술이다. 웹 요청은 각각 별도의 쓰레드에서 처리되므로, 요청 A의 인증 정보와 요청 B의 인증 정보가 섞이지 않는다.

// 현재 인증된 사용자 정보를 꺼내는 방법
SecurityContext context = SecurityContextHolder.getContext();
Authentication authentication = context.getAuthentication();
String username = authentication.getName();
Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();

이 코드는 Controller, Service 등 어디에서든 현재 요청의 인증된 사용자 정보에 접근할 수 있게 해준다.

11. 인가(Authorization) 동작 원리

인증이 완료된 후, 사용자가 특정 리소스에 접근할 수 있는 권한이 있는지 확인하는 과정이 인가이다.

11.1 권한의 종류

Spring Security에서 권한은 GrantedAuthority 인터페이스로 표현된다. 보통 문자열 형태이며, 두 가지 관례가 있다.

유형	형식	예시	용도
Role	ROLE_ 접두사 필수	ROLE_USER, ROLE_ADMIN	역할 기반의 넓은 권한 구분
Authority	접두사 없음	READ_ARTICLE, DELETE_USER	세밀한 기능 단위 권한 구분

ROLE_ 접두사는 Spring Security가 내부적으로 Role을 구분하기 위한 관례이다. hasRole("ADMIN")이라고 작성하면, 내부적으로 ROLE_ADMIN을 가지고 있는지 확인한다.

11.2 인가 처리 방식

Spring Security는 두 가지 수준에서 인가를 수행할 수 있다.

1) URL 기반 인가 (HTTP Request Level)

SecurityFilterChain 설정에서 URL 패턴별로 접근 권한을 지정한다. AuthorizationFilter가 이를 처리한다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
        // /api/admin/** 경로는 ADMIN 역할만 접근 가능
        .requestMatchers("/api/admin/**").hasRole("ADMIN")
        // /api/user/** 경로는 USER 또는 ADMIN 역할이 접근 가능
        .requestMatchers("/api/user/**").hasAnyRole("USER", "ADMIN")
        // /api/public/** 경로는 누구나 접근 가능 (인증 불필요)
        .requestMatchers("/api/public/**").permitAll()
        // 그 외 모든 요청은 인증 필요
        .anyRequest().authenticated()
    );
    return http.build();
}

2) 메서드 기반 인가 (Method Level)

컨트롤러나 서비스의 메서드에 어노테이션을 붙여서 권한을 체크한다.

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long userId) {
    // ADMIN 역할이 있는 사용자만 이 메서드를 호출할 수 있다
}

@PreAuthorize("hasRole('USER') and #userId == authentication.principal.id")
public UserProfile getProfile(Long userId) {
    // USER 역할이면서, 자기 자신의 프로필만 조회할 수 있다
}

@PreAuthorize는 메서드 실행 전에 권한을 확인하고, @PostAuthorize는 메서드 실행 후에 결과를 보고 권한을 확인한다. 메서드 레벨 보안을 사용하려면 @EnableMethodSecurity 어노테이션을 설정 클래스에 추가해야 한다.

12. Spring Security + JWT 통합 구현

이제 이론을 바탕으로, Spring Security 위에서 JWT 기반 인증을 구현하는 방법을 살펴보자. 최근 프로젝트에서는 서버 렌더링 대신 프론트엔드(React, Vue 등) + 백엔드 API 구조가 일반적이고, 이 경우 세션 대신 JWT를 사용하는 것이 보편적이다.

12.1 세션 vs JWT 비교

항목	세션 기반	JWT 기반
상태 저장 위치	서버 메모리	클라이언트 (토큰 자체)
Stateless 여부	Stateful	Stateless
확장성	서버 간 세션 공유 필요	서버 간 공유 불필요
보안 취약점	세션 하이재킹	토큰 탈취
주 사용 환경	서버 렌더링 웹	SPA + REST API, 모바일

12.2 JWT 인증 흐름 (Spring Security 관점)

[로그인 요청]
POST /api/auth/login { username, password }
         │
         ▼
   서버: 인증 성공 → JWT 토큰 생성 → 클라이언트에 반환
         │
         ▼
[이후 모든 API 요청]
GET /api/user/profile
Header: Authorization: Bearer eyJhbGciOiJI...
         │
         ▼
   서버: JWT 검증 → SecurityContext에 인증 정보 설정 → 요청 처리

12.3 JWT 인증 필터

이 필터는 매 요청마다 실행되며, 요청 헤더에 JWT가 있으면 검증하고 SecurityContext에 인증 정보를 설정한다.
Spring Security의 필터 체인에 끼워넣는 커스텀 필터이다.

OncePerRequestFilter란? 하나의 HTTP 요청에 대해 딱 한 번만 실행되는 것을 보장하는 필터 기반 클래스이다.
일반 Filter는 포워딩(forward) 등으로 같은 요청 내에서 여러 번 실행될 수 있지만, OncePerRequestFilter는 이를 방지한다.

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtTokenProvider;
    private final UserDetailsService userDetailsService;

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                     HttpServletResponse response,
                                     FilterChain filterChain)
            throws ServletException, IOException {

        // 1. 요청 헤더에서 토큰 추출
        String token = resolveToken(request);

        // 2. 토큰이 존재하고 유효하면
        if (token != null && jwtTokenProvider.validateToken(token)) {

            // 3. 토큰에서 사용자 이름 추출
            String username = jwtTokenProvider.getUsername(token);

            // 4. DB에서 사용자 정보 조회
            UserDetails userDetails =
                userDetailsService.loadUserByUsername(username);

            // 5. 인증 객체 생성 (이미 토큰으로 인증되었으므로 credentials는 null)
            UsernamePasswordAuthenticationToken authentication =
                new UsernamePasswordAuthenticationToken(
                    userDetails,
                    null,
                    userDetails.getAuthorities()
                );

            // 6. SecurityContext에 인증 정보 저장
            SecurityContextHolder.getContext()
                .setAuthentication(authentication);
        }

        // 7. 다음 필터로 요청 전달
        filterChain.doFilter(request, response);
    }

    /**
     * Authorization 헤더에서 "Bearer " 접두사를 제거하고 토큰만 추출한다.
     */
    private String resolveToken(HttpServletRequest request) {
        String bearerToken = request.getHeader("Authorization");
        if (bearerToken != null && bearerToken.startsWith("Bearer ")) {
            return bearerToken.substring(7);
        }
        return null;
    }
}

12.4 JWT용 SecurityConfig

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class JwtSecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        http
            // REST API이므로 CSRF 비활성화
            .csrf(csrf -> csrf.disable())

            // 세션을 사용하지 않음 (JWT는 stateless)
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            )

            // URL별 접근 권한
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/auth/**").permitAll()
                .anyRequest().authenticated()
            )

            // JWT 필터를 UsernamePasswordAuthenticationFilter 앞에 추가
            // 이렇게 하면 JWT 필터가 먼저 실행되어 토큰 기반 인증을 처리한다
            .addFilterBefore(jwtAuthenticationFilter,
                UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }
}

핵심은 .addFilterBefore() 메서드이다.
이 메서드로 우리가 만든 JWT 필터를 Spring Security 필터 체인의 원하는 위치에 삽입할 수 있다.
여기서는 UsernamePasswordAuthenticationFilter 앞에 넣었으므로, 폼 로그인 필터보다 먼저 JWT 인증을 시도하게 된다.

13. Access Token & Refresh Token 전략

실무에서는 토큰을 두 종류로 나눠 사용한다.

토큰 종류	유효 기간	역할
Access Token	짧게 (15분 ~ 1시간)	API 호출 시 인증에 사용
Refresh Token	길게 (7일 ~ 30일)	만료된 Access Token 재발급에 사용

왜 두 종류를 쓰는가?

Access Token만 사용하면:
- 유효 기간이 짧으면 → 사용자가 자주 로그인해야 함
- 유효 기간이 길면 → 토큰 탈취 시 오랫동안 악용 가능
Refresh Token을 도입하면:
- Access Token은 짧은 수명 → 탈취되어도 피해 최소화
- Refresh Token으로 새 Access Token 자동 발급 → 사용자 편의성 유지

Access Token 만료 시 재발급 흐름:

클라이언트                        서버
    │  GET /api/data              │
    │  Authorization: Bearer [만료된 AT] 
    │ ────────────────────────>   │
    │  401 Unauthorized           │
    │ <────────────────────────   │
    │                             │
    │  POST /api/token/refresh    │
    │  { refreshToken: "eyJ..." } │
    │ ────────────────────────>   │
    │                             │ Refresh Token 검증
    │  200 OK                     │
    │  { accessToken: "eyJ..." }  │
    │ <────────────────────────   │
    │                             │
    │  GET /api/data              │
    │  Authorization: Bearer [새 AT] 
    │ ────────────────────────>   │

14. CORS와 CSRF 이해하기

14.1 CORS (Cross-Origin Resource Sharing)

CORS는 다른 출처(Origin)의 리소스에 접근하는 것을 제어하는 브라우저의 보안 정책이다.

"출처(Origin)"란 프로토콜 + 도메인 + 포트의 조합이다.

https://example.com:443    ← 이것이 하나의 출처
http://example.com:80      ← 프로토콜이 다르므로 다른 출처
https://api.example.com    ← 도메인이 다르므로 다른 출처
https://example.com:8080   ← 포트가 다르므로 다른 출처

프론트엔드가 http://localhost:3000에서 실행되고, 백엔드 API가 http://localhost:8080에서 실행되면,
포트가 다르므로 다른 출처이다. 브라우저는 기본적으로 다른 출처로의 요청을 차단한다.

Spring Security에서 CORS 설정:

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .cors(cors -> cors.configurationSource(corsConfigurationSource()))
        // ... 나머지 설정
    ;
    return http.build();
}

@Bean
public CorsConfigurationSource corsConfigurationSource() {
    CorsConfiguration config = new CorsConfiguration();

    config.setAllowedOrigins(List.of("http://localhost:3000"));
    config.setAllowedMethods(List.of("GET", "POST", "PUT", "DELETE"));
    config.setAllowedHeaders(List.of("*"));
    config.setAllowCredentials(true);

    UrlBasedCorsConfigurationSource source =
        new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", config);

    return source;
}

14.2 CSRF (Cross-Site Request Forgery)

CSRF는 사용자가 의도하지 않은 요청을 악의적인 사이트가 대신 보내는 공격이다.

예시 시나리오:

사용자가 은행 사이트에 로그인한 상태이다 (세션 쿠키가 브라우저에 존재).
사용자가 악의적인 사이트를 방문한다.
악의적인 사이트에 숨겨진 코드가 은행 사이트로 송금 요청을 보낸다.
브라우저가 자동으로 세션 쿠키를 포함시키므로, 은행 서버는 정상적인 요청으로 인식한다.

Spring Security는 기본적으로 CSRF 방어가 활성화되어 있다. CSRF 토큰이라는 임의의 값을 발행하고, 모든 상태 변경 요청(POST, PUT, DELETE 등)에 이 토큰을 포함하도록 요구한다. 악의적인 사이트는 이 토큰을 알 수 없으므로 공격이 차단된다.

언제 CSRF를 비활성화해도 되는가?

REST API가 세션 쿠키 대신 JWT를 사용하고, 클라이언트가 매 요청마다 Authorization 헤더에 토큰을 직접 넣는 경우에는 CSRF 공격이 성립하지 않는다. 브라우저가 자동으로 토큰을 보내지 않기 때문이다. 따라서 이 경우 .csrf(csrf -> csrf.disable())로 비활성화해도 안전하다.

15. 예외 처리

Spring Security에서 발생하는 보안 예외는 크게 두 가지이다.

예외	발생 상황	HTTP 상태 코드
AuthenticationException	인증 실패 (로그인 실패, 토큰 만료 등)	401 Unauthorized
AccessDeniedException	인가 실패 (권한 부족)	403 Forbidden

ExceptionTranslationFilter가 이 예외들을 잡아서 적절한 응답으로 변환한다.

핵심 요약

JWT = Header.Payload.Signature
       (Base64Url 인코딩)

✅ 서명으로 위조 방지
✅ 서버가 상태를 저장하지 않음 (Stateless)
✅ 확장성 뛰어남 (Scale-out, MSA)

⚠️ Payload는 암호화되지 않으므로 민감정보 금지
⚠️ 만료 전 강제 무효화 어려움 → Refresh Token + 블랙리스트로 보완
⚠️ 비밀키는 절대 외부 노출 금지

Spring Security에서의 핵심 흐름:

요청 → DelegatingFilterProxy → FilterChainProxy
     → SecurityFilterChain (JWT 필터 포함)
     → JWT 검증 → SecurityContext에 인증 정보 저장
     → Controller에 도달

요청이 들어오면 필터 체인을 순서대로 통과한다.
JWT 인증 필터에서 토큰을 검증하고 사용자가 누구인지 확인한다.
인가 필터에서 이 사용자가 이 리소스에 접근할 수 있는지 확인한다.
모든 검증을 통과하면 Controller에 요청이 도달한다.

[멋사 클라우드 5기] Day 25 - Spring Data JPA (3)

allluck777 — Thu, 5 Mar 2026 23:18:38 +0900

Fetch Type

연관관계를 설정할 때 반드시 확인해야하는 부분이다.

즉시 로딩 (Eager Loading)

연관된 엔티티를 즉시 함께 조회 한다. FetchType.EAGER 로 설정한다.

@ManyToOne(fetch = FetchType.EAGER) // 기본값
private Customer customer;

-- Order를 조회할 때 Customer도 JOIN해서 함께 가져옴
SELECT o.*, c.*
FROM orders o
LEFT JOIN customer c ON o.customer_id = c.id
WHERE o.id = 1

문제: 지금 당장 Customer 정보가 필요 없어도 항상 JOIN 쿼리가 실행된다.
연관된 엔티티가 많을수록 불필요한 데이터를 많이 가져와 성능이 저하된다. 특히 N+1 문제가 발생하기 쉽다.

지연 로딩 (Lazy Loading)

연관된 엔티티를 실제로 사용할 때 조회한다. FetchType.LAZY 로 설정한다.

@ManyToOne(fetch = FetchType.LAZY)  // 권장
private Customer customer;

Order order = orderRepository.findById(1L).get();
// 이 시점: order만 조회, customer는 아직 조회 안 함

String customerName = order.getCustomer().getName();
// 이 시점: getName()이 호출되는 순간 Customer SELECT SQL 실행

Hibernate는 지연 로딩을 구현하기 위해 프록시(Proxy)객체를 사용한다. order.getCustomer() 가 반환하는 것은 실제 Customer 객체가 아니라, 실제 조회를 미루는 가짜 프록시 객체다. 실제 데이터에 접근하는 순간 DB에서 조회한다.

기본 fetch 전략

어노테이션	기본 fetch 전략	권장 설정
@ManyToOne	EAGER	LAZY로 변경 권장
@OneToOne	EAGER	LAZY로 변경 권장
@OneToMany	LAZY	LAZY 유지
@ManyToMany	LAZY	LAZY 유지

실무 원칙: 모든 연관관계는 LAZY 로딩으로 설정 하고, 필요한 경우에만 페치 조인(FETCH JOIN)으로 한 번에 가져오는 것이 성능 최적화의 기본이다.

N+1 문제

LAZY 로딩 덕분에 불필요한 데이터를 미리 안 가져오는 건 좋은데,
막상 연관 데이터가 필요한 순간 쿼리가 폭발적으로 늘어나는 부작용이 생긴다.

상황

Customer (1) ──── Order (N) ──── Product (1)

DB에 아래 데이터가 있다고 가정하자.

[customer]             [orders]
┌────┬──────────┐      ┌────┬─────────────┬────────────┐
│ id │ name     │      │ id │ customer_id │ product_id │
├────┼──────────┤      ├────┼─────────────┼────────────┤
│  1 │ 홍길동     │      │  1 │      1      │     1      │
│  2 │ 김철수     │      │  2 │      1      │     2      │
│  3 │ 이영희     │      │  3 │      2      │     1      │
└────┴──────────┘      │  4 │      3      │     3      │
                       └────┴─────────────┴────────────┘

N+1이 터지는 코드

// OrderService.java
@Transactional(readOnly = true)
public void printAllOrders() {
    List<Order> orders = orderRepository.findAll();
    // ① 이 시점: SELECT * FROM orders → 쿼리 1번

    for (Order order : orders) {
        System.out.println(order.getCustomer().getName());
        // ② 이 시점: SELECT * FROM customer WHERE id = ?
        //    → order마다 1번씩, 총 4번 추가 실행
    }
}

실제로 실행되는 SQL을 보면 이렇다.

-- ① findAll() 실행 시
SELECT * FROM orders;

-- ② 루프를 돌며 각 order의 customer를 LAZY 로딩
SELECT * FROM customer WHERE id = 1;
SELECT * FROM customer WHERE id = 1;  -- 이미 조회했는데 또 나감 (1차 캐시 덕분에 실제론 생략되지만)
SELECT * FROM customer WHERE id = 2;
SELECT * FROM customer WHERE id = 3;
-- 총 1 + 3 = 4번 (고객이 중복되지 않을 경우 기준)
-- 최악의 경우 1 + N번

왜 문제인가? Order가 1,000개라면 SQL이 1,001번 실행된다.
각 SQL은 DB 커넥션을 열고 닫는 네트워크 비용을 수반하기 때문에, 성능이 급격히 저하된다.

개발자들이 이 문제를 풀려고 시도하면서 세 가지 접근법이 등장했는데, 각각 해결 방식이 다르고, 장단점도 다르다.

해결책 1️⃣ Fetch Join

핵심 아이디어

"처음 조회할 때, 연관된 엔티티를 JOIN으로 한 번에 다 가져오자"

SQL의 JOIN과 개념은 같다.
차이점은 JPA에서 LAZY로 설정된 연관관계도 강제로 즉시 함께 로딩한다는 것이다.

사용법

JPQL에서 JOIN FETCH 키워드를 사용한다.

// OrderRepository.java
public interface OrderRepository extends JpaRepository<Order, Long> {

    // 일반 JPQL — LAZY 설정이므로 customer는 나중에 따로 조회됨
    @Query("SELECT o FROM Order o")
    List<Order> findAll();

    // Fetch Join JPQL — customer를 즉시 함께 조회
    @Query("SELECT o FROM Order o JOIN FETCH o.customer")
    List<Order> findAllWithCustomer();

    // 여러 연관관계를 한 번에 Fetch Join
    @Query("SELECT o FROM Order o JOIN FETCH o.customer JOIN FETCH o.product")
    List<Order> findAllWithCustomerAndProduct();
}

실제로 실행되는 SQL

-- findAllWithCustomer() 실행 시 → 쿼리 딱 1번
SELECT o.*, c.*
FROM orders o
INNER JOIN customer c ON o.customer_id = c.id;

Order와 Customer를 한 번의 SQL로 한 번에 가져온다. 루프를 돌며 추가 SQL이 실행되지 않는다.

// 이제 N+1이 발생하지 않음
@Transactional(readOnly = true)
public void printAllOrders() {
    List<Order> orders = orderRepository.findAllWithCustomer();
    // ① 이 시점: 위의 JOIN SQL 1번 실행, customer까지 모두 로딩 완료

    for (Order order : orders) {
        System.out.println(order.getCustomer().getName());
        // ② 추가 SQL 없음! 이미 다 메모리에 있다
    }
}

Fetch Join의 한계

편리하지만 단점도 있다. 반드시 알아야 한다.

단점 1: 컬렉션(1:N) Fetch Join + 페이징은 함께 쓸 수 없다

OneToMany 관계(컬렉션)를 Fetch Join하면서 동시에 페이징(LIMIT, OFFSET)을 사용하면
Hibernate가 경고를 띄우고 모든 데이터를 메모리에 올린 후 페이징을 처리한다.

// ❌ 위험한 코드 — 데이터가 많으면 OOM(Out of Memory) 발생 가능
@Query("SELECT c FROM Customer c JOIN FETCH c.orders")
Page<Customer> findAllWithOrders(Pageable pageable);
// → Hibernate 경고: "HHH90003004: firstResult/maxResults specified with collection fetch"
// → 전체 데이터를 메모리에 올린 후 Java에서 페이징 처리 → 매우 위험

왜 이런 일이 생기냐면, JOIN FETCH 로 1:N 관계를 조인하면 결과 행(row)이 뻥튀기되기 때문이다.

[orders JOIN customer 결과]
┌──────────┬──────────┐
│ order_id │ customer │
├──────────┼──────────┤
│    1     │  홍길동    │ ← customer 홍길동이
│    2     │  홍길동    │ ← 두 번 등장 (order 2개)
│    3     │  김철수    │
└──────────┴──────────┘

DB 입장에서는 행이 3개지만, Java 입장에서 Customer는 2명이다.
DB 레벨에서 LIMIT 1 을 하면 Customer 1명이 아니라 row 1개만 자르기 때문에, 결과가 뒤틀린다.
그래서 Hibernate는 메모리에 전부 올린 다음 Java에서 직접 자른다.

해결책: 컬렉션(1:N) Fetch Join과 페이징은 함께 쓰지 말 것. 이 상황에서는 BatchSize 를 사용하는 것이 정답이다.

단점 2: 두 개 이상의 컬렉션을 동시에 Fetch Join할 수 없다

// ❌ 불가능 — MultipleBagFetchException 발생
@Query("SELECT c FROM Customer c JOIN FETCH c.orders JOIN FETCH c.reviews")
List<Customer> findAllWithOrdersAndReviews();

List 타입 컬렉션을 두 개 이상 동시에 Fetch Join하면 Hibernate가 예외를 던진다. (Set으로 바꾸면 가능하지만 카테시안 곱(Cartesian Product) 문제가 생긴다.)

단점 3: JPQL을 직접 작성해야 한다

항상 @Query 에 JPQL을 직접 써야 하기 때문에, 쿼리 메서드처럼 선언적으로 사용할 수 없다. 코드가 다소 복잡해진다.

언제 쓰면 좋을까?

단일 연관관계(N:1, 1:1) 를 함께 조회할 때 → 가장 깔끔하고 효율적
페이징이 필요 없는 컬렉션 조회
성능이 중요한 핵심 쿼리에서 명시적으로 제어하고 싶을 때

해결책 2️⃣ EntityGraph

핵심 아이디어

"Fetch Join이랑 결과는 같은데, JPQL 없이 어노테이션으로 선언하고 싶다"

EntityGraph는 Fetch Join과 동일하게 JOIN을 통해 연관 엔티티를 함께 로딩한다.
차이는 JPQL 대신 어노테이션으로 설정한다는 것이다.
내부적으로 Hibernate는 EntityGraph를 보고 Fetch Join SQL을 생성한다.

방법 1: @EntityGraph 어노테이션 — 즉석에서 선언

// OrderRepository.java
public interface OrderRepository extends JpaRepository<Order, Long> {

    // attributePaths에 함께 로딩할 연관관계 필드명을 적는다
    @EntityGraph(attributePaths = {"customer"})
    List<Order> findAll();

    // 여러 개도 가능
    @EntityGraph(attributePaths = {"customer", "product"})
    List<Order> findAllBy();

    // 기존 쿼리 메서드에도 그냥 붙일 수 있다
    @EntityGraph(attributePaths = {"customer"})
    List<Order> findByCustomerId(Long customerId);
}

실제로 실행되는 SQL

-- findAll() with @EntityGraph 실행 시 → Fetch Join과 동일한 SQL
SELECT o.*, c.*
FROM orders o
LEFT OUTER JOIN customer c ON o.customer_id = c.id;

Fetch Join vs EntityGraph SQL 차이

Fetch Join: INNER JOIN (기본)

EntityGraph: LEFT OUTER JOIN (기본)

LEFT OUTER JOIN이기 때문에 연관 엔티티가 null인 경우에도 Order가 조회된다.

방법 2: @NamedEntityGraph — Entity 클래스에 미리 정의

자주 재사용하는 그래프 패턴을 엔티티 클래스에 이름을 붙여 정의해두는 방법이다.

// Order.java
@Entity
@Table(name = "orders")
@NamedEntityGraph(
    name = "Order.withCustomerAndProduct",       // 그래프에 이름 부여
    attributeNodes = {
        @NamedAttributeNode("customer"),
        @NamedAttributeNode("product")
    }
)
public class Order {
    // ... 필드들
}

// OrderRepository.java
public interface OrderRepository extends JpaRepository<Order, Long> {

    // 이름으로 참조해서 사용
    @EntityGraph("Order.withCustomerAndProduct")
    List<Order> findAll();

    @EntityGraph("Order.withCustomerAndProduct")
    Optional<Order> findById(Long id);
}

EntityGraph의 한계

EntityGraph도 내부적으로 JOIN을 사용하기 때문에 Fetch Join과 동일한 한계 를 공유한다.

컬렉션(1:N) + 페이징 조합 시 메모리 페이징 문제 발생
두 개 이상 컬렉션 동시 로딩 시 문제 발생

추가적으로 EntityGraph만의 단점이 있다.

JPQL과 함께 쓰면 충돌이 생기기 쉽다. @Query 에 이미 JOIN이 있는데 EntityGraph도 붙이면 예상치 못한 SQL이 생성될 수 있다.
Fetch Join보다 동작이 덜 명시적이라 디버깅이 어려울 수 있다.

Fetch Join과의 선택 기준

상황	권장
쿼리 재사용이 많고, 선언적으로 관리하고 싶다	EntityGraph
복잡한 조건의 JPQL과 함께 사용한다	Fetch Join
성능 튜닝이 중요하고 SQL을 직접 제어하고 싶다	Fetch Join
Spring Data JPA의 쿼리 메서드에 간단히 붙이고 싶다	EntityGraph

언제 쓰면 좋을까?

기존 쿼리 메서드에 빠르게 Fetch 전략을 추가하고 싶을 때
자주 재사용되는 로딩 패턴을 @NamedEntityGraph 로 이름 붙여 관리할 때
JPQL 없이 선언형으로 연관관계 로딩을 제어하고 싶을 때

해결책 3️⃣ BatchSize

핵심 아이디어

"한 방에 JOIN으로 가져오는 게 아니라, 여러 ID를 묶어서 IN 쿼리로 한 번에 처리하자"

Fetch Join과 EntityGraph는 JOIN 으로 N+1을 해결했다. BatchSize는 완전히 다른 방식이다.

LAZY 로딩은 유지하되, 연관 엔티티를 하나씩 가져오는 대신, 여러 개의 ID를 모아서 WHERE id IN (...) 쿼리로 한 번에 가져온다.

작동 방식 — 단계별로 이해하기

batchSize = 100 으로 설정했다고 가정하자.

기존 N+1 방식:
① SELECT * FROM orders                    → order 300개 조회
② SELECT * FROM customer WHERE id = 1    → 1번
③ SELECT * FROM customer WHERE id = 2    → 1번
④ SELECT * FROM customer WHERE id = 3    → 1번
... (총 300번 추가)
→ 합계: 301번의 SQL

BatchSize = 100 방식:
① SELECT * FROM orders                              → order 300개 조회
② SELECT * FROM customer WHERE id IN (1,2,...,100)  → 100개씩 묶어서
③ SELECT * FROM customer WHERE id IN (101,...,200)  → 1번
④ SELECT * FROM customer WHERE id IN (201,...,300)  → 1번
→ 합계: 4번의 SQL (1 + 300/100 = 4번)

N+1이 N+1 → 1 + (N / BatchSize) 로 줄어든다.

방법 1: 전역 설정 (application.yml)

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100  # 전체 프로젝트에 적용

이 설정 하나만 추가하면 모든 LAZY 로딩 연관관계에 자동으로 BatchSize가 적용된다. 가장 간단하고 실무에서 많이 쓰는 방법이다.

방법 2: 특정 필드에만 @BatchSize 어노테이션

// Customer.java
@Entity
public class Customer {

    @OneToMany(mappedBy = "customer")
    @BatchSize(size = 100)  // 이 컬렉션에만 적용
    private List<Order> orders = new ArrayList<>();
}

// Order.java
@Entity
public class Order {

    @ManyToOne(fetch = FetchType.LAZY)
    @BatchSize(size = 50)   // 이 연관관계에만 적용
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

BatchSize가 유용한 상황 — 페이징과의 조합

BatchSize의 가장 큰 장점은 컬렉션(1:N) 조회 + 페이징을 동시에 해결한다는 것이다.

Fetch Join은 컬렉션 + 페이징을 함께 쓰면 메모리 페이징 문제가 생겼다. BatchSize는 이 문제가 없다.

// ✅ BatchSize + 페이징 — 완벽하게 동작
@Transactional(readOnly = true)
public Page<Customer> getCustomersWithOrders(Pageable pageable) {

    // ① 먼저 Customer를 페이징으로 조회 (SQL 1번)
    Page<Customer> customers = customerRepository.findAll(pageable);
    // → SELECT * FROM customer LIMIT 10 OFFSET 0

    // ② customers의 orders에 접근하는 순간 BatchSize IN 쿼리 실행
    customers.getContent().forEach(c -> c.getOrders().size());
    // → SELECT * FROM orders WHERE customer_id IN (1, 2, 3, ..., 10)
    // → 페이징된 10명의 orders를 한 번에 가져옴

    return customers;
}

-- 실행되는 SQL (총 2번)

-- ① 페이징 Customer 조회
SELECT * FROM customer LIMIT 10 OFFSET 0;

-- ② BatchSize IN 쿼리로 10명의 orders 한 번에 조회
SELECT * FROM orders WHERE customer_id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

페이징도 정확하고, SQL도 2번뿐이다.

BatchSize 크기는 어떻게?

일반적으로 100 ~ 1000 사이를 권장한다.

너무 작으면 (예: 10):
  IN 쿼리가 자주 나가서 성능 개선 효과가 줄어든다

너무 크면 (예: 10000):
  IN 절에 들어가는 ID가 너무 많아 DB 쿼리 자체가 무거워진다
  일부 DB는 IN 절 개수 제한이 있다 (Oracle: 1000개)

실무 기본값: 100

Oracle 사용 시 주의: Oracle은 IN 절에 최대 1000개까지만 허용한다.
default_batch_fetch_size = 1000 이 Oracle에서의 사실상 최대값이다.

BatchSize의 한계

JOIN이 아닌 별도의 SELECT 쿼리를 추가로 실행한다. 즉, SQL이 완전히 1번이 되진 않는다.
연관 엔티티 데이터가 정말 많을 때는 IN 쿼리 자체가 무거워질 수 있다.
Fetch Join처럼 "이 쿼리에서는 반드시 함께 가져와야 한다" 는 확신이 없을 때, 예상치 못한 시점에 IN 쿼리가 실행될 수 있다.

언제 쓰면 좋을까?

컬렉션(1:N) 관계 + 페이징이 함께 필요한 상황 → BatchSize가 사실상 유일한 해결책
전역 설정으로 프로젝트 전체의 LAZY 로딩 성능을 간단히 끌어올리고 싶을 때
Fetch Join의 컬렉션 2개 이상 동시 로딩 제한을 우회하고 싶을 때

Fetch 방식 비교

핵심 차이 한눈에 보기

Fetch	Join	EntityGraph	BatchSize
해결 방식	JOIN으로 한 번에	JOIN으로 한 번에	IN 쿼리로 묶어서
SQL 실행 횟수	1번	1번	1 + N/size 번
설정 방식	JPQL @Query	어노테이션	yml 또는 어노테이션
컬렉션 + 페이징	❌ 위험	❌ 위험	✅ 안전
컬렉션 2개 동시	❌ 불가	❌ 불가	✅ 가능
코드 복잡도	중간 (JPQL 작성)	낮음 (어노테이션)	매우 낮음 (전역 설정)
SQL 제어력	높음	중간	낮음

OSIV

OSIV는 Open Session In View의 줄임말이다.
Hibernate에서는 Session, JPA에서는 EntityManager라고 부르지만 같은 개념이다.
쉽게 말하면 "영속성 컨텍스트를 언제까지 열어둘 것인가"에 대한 설정이다.

배경 — 트랜잭션이 끝나면 무슨 일이 생기나

기본적으로 영속성 컨텍스트는 트랜잭션과 생명주기를 같이 한다고 했다.

트랜잭션 시작 → 영속성 컨텍스트 생성
트랜잭션 종료 → 영속성 컨텍스트 종료 → 엔티티가 준영속 상태

그런데 일반적인 Spring MVC 요청 흐름을 보면 이렇다.

HTTP 요청
    ↓
Controller
    ↓
Service  ← @Transactional, 여기서 트랜잭션 시작/종료
    ↓
Controller  ← 트랜잭션 이미 끝남
    ↓
View / Response 변환  ← 트랜잭션 이미 끝남
    ↓
HTTP 응답

Service에서 트랜잭션이 끝나면 영속성 컨텍스트도 닫힌다.
그 이후 Controller나 View에서 엔티티의 LAZY 로딩을 시도하면 어떻게 될까?

// Service
@Transactional
public Order getOrder(Long id) {
    return orderRepository.findById(id).get();
    // 트랜잭션 종료 → 영속성 컨텍스트 닫힘
}

// Controller
public ResponseEntity<?> getOrder(Long id) {
    Order order = orderService.getOrder(id);
    order.getCustomer().getName(); // ❌ LazyInitializationException 발생!
    // 영속성 컨텍스트가 이미 닫혀있어서 LAZY 로딩 불가
}

이 문제를 해결하려고 등장한 것이 OSIV다.

OSIV On — 영속성 컨텍스트를 요청 끝까지 열어두기

OSIV를 켜면 영속성 컨텍스트의 생명주기가 트랜잭션이 아닌 HTTP 요청 전체로 늘어난다.

OSIV ON

HTTP 요청 → [영속성 컨텍스트 시작]
    ↓
Controller
    ↓
Service (@Transactional 시작/종료)
    ↓
Controller  ← 영속성 컨텍스트 살아있음
    ↓
View  ← 영속성 컨텍스트 살아있음 → LAZY 로딩 가능
    ↓
HTTP 응답 → [영속성 컨텍스트 종료]

// Controller에서 LAZY 로딩 가능
Order order = orderService.getOrder(id);
order.getCustomer().getName(); // ✅ 영속성 컨텍스트 살아있으니 동작함

Spring Boot의 OSIV 기본값은 true, 즉 켜져 있다.

OSIV On의 문제점

편하지만 치명적인 단점이 있다.

DB 커넥션을 너무 오래 점유한다.

OSIV ON일 때 DB 커넥션 점유 시간

HTTP 요청 들어옴  → DB 커넥션 획득
    ↓
Service 로직 (DB 작업)
    ↓
Controller 로직 (DB 작업 없음)
    ↓
JSON 직렬화 (DB 작업 없음)
    ↓
HTTP 응답 나감  → DB 커넥션 반환

DB 작업이 없는 구간에도 커넥션을 잡고 있다. 트래픽이 많아지면 커넥션 풀이 고갈되고 장애로 이어질 수 있다.

OSIV Off

# application.yml
spring:
  jpa:
    open-in-view: false

OSIV OFF

HTTP 요청
    ↓
Controller
    ↓
Service (@Transactional 시작)
    → DB 커넥션 획득
    → 로직 실행
    → 트랜잭션 종료 → 영속성 컨텍스트 종료
    → DB 커넥션 반환  ← 여기서 바로 반환
    ↓
Controller  ← 영속성 컨텍스트 없음
    ↓
HTTP 응답

DB 커넥션을 실제로 필요한 순간에만 점유한다. 훨씬 효율적이다.

OSIV Off의 문제점

트랜잭션 밖, 즉 Service를 벗어나면 LAZY 로딩이 불가능하다.

// ❌ OSIV Off 상태에서 Controller에서 LAZY 로딩 시도
Order order = orderService.getOrder(id);
order.getCustomer().getName(); // LazyInitializationException 발생!

이 문제를 해결하는 방법이 두 가지다.

방법 1 — Service 안에서 미리 다 로딩하고 나오기

@Transactional
public Order getOrder(Long id) {
    Order order = orderRepository.findById(id).get();
    order.getCustomer().getName(); // 트랜잭션 안에서 미리 LAZY 로딩 강제
    return order;
}

방법 2 — DTO로 변환해서 반환하기 (권장)

@Transactional
public OrderResponse getOrder(Long id) {
    Order order = orderRepository.findById(id).get();
    return new OrderResponse(order); // 트랜잭션 안에서 DTO로 변환
    // DTO는 순수 Java 객체라 영속성 컨텍스트와 무관
}

DTO로 변환하면 영속성 컨텍스트가 닫혀도 아무 문제가 없다.
OSIV를 끄면 DTO 분리가 사실상 강제된다고 볼 수 있다.

결론

	OSIV On	OSIV Off
영속성 컨텍스트	요청 끝까지 유지	트랜잭션 안에서만 유지
LAZY 로딩	어디서든 가능	트랜잭션 안에서만 가능
DB 커넥션	요청 내내 점유	필요한 순간만 점유
실무 권장	❌ 트래픽 많으면 위험	✅ 권장
주의사항	없음	Controller에서 LAZY 로딩 불가

실무에서는 OSIV를 끄고, Service 안에서 DTO로 변환해서 반환하는 패턴을 권장한다.

[멋사 클라우드 5기] Day 24 - Spring Data JPA (2)

allluck777 — Wed, 4 Mar 2026 23:34:52 +0900

1. 연관관계 매핑이란?

현실 세계에서 고객(Customer) 과 상품(Product) 은 서로 관계가 있다.

한 고객은 여러 상품을 주문할 수 있다.
한 상품은 여러 고객에게 주문될 수 있다.

이 관계를 Java 객체로 표현하면 참조(Reference)가 되고, DB로 표현하면 외래 키(Foreign Key)가 된다.

연관관계 매핑은 이 두 세계를 JPA 어노테이션으로 연결하는 작업이다.

[Java 세계]                    [DB 세계]
Customer → Product    ↔    customer_id FK
                            product_id FK

2. 연관관계의 종류

연관관계는 4가지로 나뉜다.

종류	어노테이션	예시
다대일 (N:1)	@ManyToOne	여러 주문 → 한 고객
일대다 (1:N)	@OneToMany	한 고객 → 여러 주문
일대일 (1:1)	@OneToOne	고객 → 고객 상세정보
다대다 (N:M)	@ManyToMany	여러 고객 ↔ 여러 상품

Customer와 Product의 관계는 다대다(N:M) 다.

한 고객이 여러 상품을 살 수 있고, 한 상품이 여러 고객에게 팔릴 수 있으니까.

3. 핵심 개념 먼저 잡기

방향 (Direction)

연관관계에는 단방향(Unidirectional)과 양방향(Bidirectional)이 있다.

// 단방향: Customer가 Product를 알지만, Product는 Customer를 모른다
class Customer {
    List<Product> products; // Customer → Product (일방통행)
}

class Product {
    // Customer에 대한 참조 없음
}

// 양방향: 서로가 서로를 안다
class Customer {
    List<Product> products; // Customer → Product
}

class Product {
    List<Customer> customers; // Product → Customer
}

DB 테이블은 외래 키 하나로 양쪽 조인이 가능하다.
하지만 Java 객체는 참조가 없으면 반대 방향으로 탐색이 불가능하다.
양방향은 사실 단방향 2개를 연결한 것이라고 이해하면 된다.

연관관계의 주인 (Owner)

양방향 관계에서는 반드시 "누가 외래 키를 관리할 것인가"를 정해야 한다.
이것이 연관관계의 주인(Owner) 이다.

규칙:

주인 쪽: 외래 키를 직접 관리한다. mappedBy 속성을 쓰지 않는다.
비주인 쪽: 읽기 전용이다. mappedBy = "상대 클래스의 필드명" 을 반드시 붙여야 한다.

// 주인: Order (orders 테이블에 customer_id FK가 있음)
@ManyToOne
@JoinColumn(name = "customer_id")  // 주인 → @JoinColumn 사용
private Customer customer;

// 비주인: Customer (mappedBy로 주인이 누구인지 알려줌)
@OneToMany(mappedBy = "customer")  // 비주인 → mappedBy 사용
private List<Order> orders;

흔한 실수: 비주인 쪽에만 값을 세팅하면 DB에 반영이 안 된다. 주인 쪽에 값을 세팅해야 한다.

@JoinColumn

@JoinColumn 은 외래 키 컬럼의 이름을 지정하는 어노테이션이다.

@JoinColumn(name = "customer_id")
// → DB에서 외래 키 컬럼 이름이 "customer_id"가 됨

4. 일대다 / 다대일

다대다로 넘어가기 전에, 이해를 돕기 위해 1:N 관계를 먼저 살펴보자.

"한 Customer가 여러 Order(주문)를 가진다" 는 1:N 관계다.

Customer (1) ──────── Order (N)
            1개의 고객이 여러 주문을 가짐

@Entity
public class Customer {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    // 1:N 관계 — Customer가 비주인 (mappedBy 사용)
    @OneToMany(mappedBy = "customer")
    private List<Order> orders = new ArrayList<>();
}

@Entity
public class Order {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    // N:1 관계 — Order가 주인 (@JoinColumn으로 FK 관리)
    @ManyToOne
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

이 관계에서 DB 테이블은 아래처럼 된다.

[customer 테이블]          [orders 테이블]
┌────┬────────┐           ┌────┬─────────────┐
│ id │ name   │           │ id │ customer_id │  ← FK
├────┼────────┤           ├────┼─────────────┤
│  1 │ 홍길동   │           │  1 │      1      │
│  2 │ 김철수   │           │  2 │      1      │
└────┴────────┘           │  3 │      2      │
                          └────┴─────────────┘

외래 키(customer_id)는 N 쪽(orders 테이블)에 존재한다.

원칙: 외래 키는 항상 "N 쪽" 테이블에 존재한다.
따라서 연관관계의 주인도 보통 N 쪽(더 구체적인 쪽)이 된다.

5. 다대다 (N:M) — @ManyToMany의 문제

이제 본론이다. Customer와 Product의 관계는 다대다(N:M)다.

Customer (N) ──────── Product (M)

DB에서 N:M은 직접 표현이 불가능하다

관계형 DB는 N:M을 직접 표현할 수 없다.
반드시 중간 테이블(Junction Table / 연결 테이블) 이 필요하다.

[customer 테이블]    [customer_product 테이블]    [product 테이블]
┌────┬────────┐      ┌─────────────┬────────────┐  ┌────┬──────────┐
│ id │ name   │      │ customer_id │ product_id │  │ id │ name     │
├────┼────────┤      ├─────────────┼────────────┤  ├────┼──────────┤
│  1 │ 홍길동   │      │      1      │     1      │  │  1 │ 노트북    │
│  2 │ 김철수   │      │      1      │     2      │  │  2 │ 마우스    │
└────┴────────┘      │      2      │     1      │  └────┴──────────┘
                     └─────────────┴────────────┘

@ManyToMany로 간단히 표현하면?

JPA는 @ManyToMany 어노테이션으로 N:M 관계를 쉽게 표현할 수 있게 해준다.

@Entity
public class Customer {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    @ManyToMany
    @JoinTable(
        name = "customer_product",             // 중간 테이블 이름
        joinColumns = @JoinColumn(name = "customer_id"),         // 이 엔티티의 FK
        inverseJoinColumns = @JoinColumn(name = "product_id")   // 반대 엔티티의 FK
    )
    private List<Product> products = new ArrayList<>();
}

@Entity
public class Product {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private int price;

    @ManyToMany(mappedBy = "products") // 비주인
    private List<Customer> customers = new ArrayList<>();
}

코드가 간결하고 깔끔해 보인다.
하지만 실무에서는 @ManyToMany를 사용하지 않는다. 왜일까?

@ManyToMany의 치명적인 문제점

문제 1: 중간 테이블에 컬럼을 추가할 수 없다

실제 서비스에서 "주문 내역"에는 주문 날짜, 수량, 가격 등 추가 정보가 필요하다.
하지만 @ManyToMany 가 자동 생성한 중간 테이블에는 외래 키 두 개 외에 컬럼을 추가할 방법이 없다.

[실제로 필요한 테이블]
┌─────────────┬────────────┬──────────────┬──────┬────────┐
│ customer_id │ product_id │ ordered_at   │ qty  │ price  │  ← 이런 컬럼들이 필요!
├─────────────┼────────────┼──────────────┼──────┼────────┤
│      1      │     1      │  2024-01-15  │  2   │ 1200000│
└─────────────┴────────────┴──────────────┴──────┴────────┘

[@ManyToMany가 만드는 테이블]
┌─────────────┬────────────┐
│ customer_id │ product_id │  ← FK 두 개만 존재, 추가 컬럼 불가
└─────────────┴────────────┘

문제 2: 예상치 못한 쿼리가 발생한다

@ManyToMany 는 내부적으로 복잡한 조인 쿼리와 중간 테이블 관련 SQL을 발생시키는데, 개발자가 이를 예측하고 제어하기 어렵다.
이는 성능 문제로 이어지기 쉽다.

6. 올바른 다대다 해결책 — 중간 테이블을 Entity로 승격

실무에서는 @ManyToMany 대신, 중간 테이블을 직접 Entity 클래스로 만드는 방법 을 사용한다.

Customer ↔ Product 사이에 Order (주문) 엔티티를 만드는 것이다.

Customer (1) ──── Order (N:M의 중간) ──── Product (1)
              N                       N

이렇게 하면 Customer와 Order 는 1:N, Product와 Order 도 1:N 관계가 된다.
N:M이 두 개의 1:N으로 분해된다.

전체 구조 설계

[customer]        [orders]                                              [product]
┌────┬──────┐  ┌────┬─────────────┬────────────┬────────────┬──────┐  ┌────┬────────┬────────┐
│ id │ name │  │ id │ customer_id │ product_id │ ordered_at │ qty  │  │ id │ name   │ price  │
└────┴──────┘  └────┴─────────────┴────────────┴────────────┴──────┘  └────┴────────┴────────┘
     1 ──────────────── N                                N ──────────────────── 1

[멋사 클라우드 5기] Day 23 - Spring Data JPA (1)

allluck777 — Tue, 3 Mar 2026 11:42:35 +0900

1. 왜 JPA가 필요한가? — 패러다임 불일치 문제

객체 지향 vs 관계형 데이터베이스

Java는 객체 지향 언어다.
개발자는 현실 세계를 객체(Object) 로 모델링하고, 객체 간의 관계를 참조(Reference) 로 표현한다.

반면, 우리가 데이터를 저장하는 공간인 RDBMS는
데이터를 테이블과 외래 키(Foreign Key) 로 표현한다.

이 두 세계는 근본적으로 사고방식이 다르다.
이것을 패러다임 불일치(Paradigm Mismatch) 라고 한다.

패러다임 불일치의 구체적인 예시

문제 1: 상속(Inheritance)

Java에서는 클래스 간 상속이 자연스럽다.

// Java: 상속 관계
class Vehicle {
    Long id;
    String name;
}

class Car extends Vehicle {
    int doorCount;
}

하지만 RDBMS에는 상속이라는 개념이 없다.
Vehicle과 Car를 테이블로 표현하려면 다양한 전략이 필요하고, 이를 수동으로 처리하는 건 매우 번거롭다.

문제 2: 연관관계(Association)

Java에서 객체 간 관계는 참조 로 표현된다.

// Java: 참조로 관계 표현
class Order {
    Member member; // Member 객체를 직접 참조
}

RDBMS에서는 외래 키(FK) 로 관계를 표현한다.

-- SQL: FK로 관계 표현
CREATE TABLE orders (
    id BIGINT,
    member_id BIGINT  -- Member의 PK를 저장
);

Java 객체는 order.getMember() 처럼 객체를 직접 꺼내오지만, SQL은 JOIN 을 통해 데이터를 합쳐야 한다.
이 간극을 개발자가 직접 메워야 한다.

문제 3: 동일성(Identity)

Java에서 같은 객체인지 비교할 때는 == 또는 equals() 를 쓴다.

Member m1 = memberDAO.findById(1L);
Member m2 = memberDAO.findById(1L);

m1 == m2; // false! 서로 다른 인스턴스

같은 회원(id=1)을 두 번 조회해도, 매번 새로운 객체가 반환되어 == 비교 시 false 가 나온다.
데이터베이스 입장에서 같은 행(row)이지만, Java 입장에서는 다른 객체다.

패러다임 불일치를 직접 해결하면?

JPA 없이 JDBC만으로 위 문제들을 해결하려면, 개발자가 직접 SQL을 작성하고,
ResultSet에서 데이터를 꺼내 객체에 매핑하는 지루하고 반복적인 코드 를 수없이 작성해야 한다.

// JPA 없이 직접 작성해야 하는 코드 예시
public Member findById(Long id) {
    String sql = "SELECT * FROM member WHERE id = ?";
    PreparedStatement ps = connection.prepareStatement(sql);
    ps.setLong(1, id);
    ResultSet rs = ps.executeQuery();
    
    Member member = new Member();
    member.setId(rs.getLong("id"));
    member.setName(rs.getString("name"));
    member.setEmail(rs.getString("email"));
    // ... 필드가 많아질수록 코드가 늘어남
    return member;
}

이런 코드를 모든 테이블, 모든 CRUD 작업에 대해 작성해야한다...
ORM 은 바로 이 문제를 해결하기 위해 등장했다.

2. ORM이란 무엇인가?

ORM(Object-Relational Mapping) 은 객체 세계와 관계형 데이터베이스 세계를 자동으로 연결해주는 기술이다.

ORM 프레임워크를 사용하면 개발자는 SQL을 직접 작성하지 않아도 된다.
대신 Java 객체를 조작 하면 ORM이 알아서 적절한 SQL을 생성하고 실행한다.

개발자 → Java 객체 조작 → ORM → SQL 자동 생성 → RDBMS

ORM의 핵심 아이디어는 "Java 클래스와 DB 테이블을 연결(매핑)하자" 는 것이다.

Member 클래스  ↔  MEMBER 테이블
id 필드        ↔  ID 컬럼
name 필드      ↔  NAME 컬럼

3. JPA란 무엇인가?

JPA = Java ORM의 표준 명세

JPA(Java Persistence API, 혹은 Jakarta Persistence API)는
Java 진영에서 ORM 기술을 사용하기 위한 표준 인터페이스(Interface) 모음 이다.

핵심 포인트: JPA는 구현체(Implementation)가 아니라 명세(Specification) 다.

마치 JDBC가 데이터베이스 연결을 위한 표준 인터페이스이고, 실제 구현은 MySQL Driver, PostgreSQL Driver 등이 담당하는 것처럼,
JPA는 ORM의 표준 인터페이스이고, 실제 구현은 Hibernate, EclipseLink, OpenJPA 등이 담당한다.

JPA (인터페이스/명세)
    ├── Hibernate (가장 많이 쓰이는 구현체)
    ├── EclipseLink
    └── OpenJPA

JPA를 사용한다는 것은 JPA가 정의한 인터페이스를 통해 ORM 기능을 사용한다는 뜻이다.
구현체를 Hibernate에서 다른 것으로 바꿔도 코드가 크게 변하지 않는 이유가 바로 이 덕분이다.

JPA의 핵심 역할

JPA는 크게 세 가지 역할을 한다.

CRUD SQL 자동 생성 — persist(), find(), remove() 등의 메서드로 SQL을 자동 생성한다.
결과를 자동으로 객체에 매핑 — SQL 실행 결과를 Java 객체로 자동 변환한다.
패러다임 불일치 해결 — 상속, 연관관계, 객체 그래프 탐색 등을 처리한다.

4. 전체 구조 이해하기

아래 그림이 나타내는 구조를 층별로 이해해보자.

┌──────────────────────────────────────┐
│        Spring Boot Application       │
└──────────────┬───────────────────────┘
               │ ↕
┌──────────────▼───────────────────────┐
│   ┌──────────────────────────────┐   │
│   │      Spring Data JPA         │   │  ← 편의 레이어 (Repository 자동 구현)
│   └──────────────────────────────┘   │
│   ┌──────────────────────────────┐   │
│   │    Java Persistence API      │   │  ← ORM 표준 명세 (인터페이스)
│   └──────────────────────────────┘   │
│   ┌──────────────────────────────┐   │
│   │         Hibernate            │   │  ← JPA 구현체 (실제 ORM 동작)
│   └──────────────────────────────┘   │
│   ┌──────────────────────────────┐   │
│   │           JDBC               │   │  ← DB와의 저수준 통신 담당
│   └──────────────────────────────┘   │
└──────────────┬───────────────────────┘
               │ ↕
        ┌──────▼──────┐
        │    RDBMS    │
        └─────────────┘

JDBC (Java Database Connectivity)

JDBC 는 Java 프로그램이 데이터베이스와 통신하기 위한 가장 기본적인 API다.
SQL 작성, Connection 열기, PreparedStatement 실행, ResultSet에서 데이터 꺼내기와 같은 모든 저수준 작업을 담당한다.

모든 Java ORM은 내부적으로 JDBC를 사용한다.
JPA, Hibernate 모두 최종적으로는 JDBC를 통해 DB와 통신한다.

Hibernate

Hibernate 는 JPA 명세를 실제로 구현한 ORM 프레임워크다.
JPA가 정의한 인터페이스의 실제 로직을 담고 있으며,
SQL 자동 생성, 캐싱, 영속성 컨텍스트 관리 등의 핵심 기능을 제공한다.

Java Persistence API (JPA)

Hibernate 같은 구현체들이 공통적으로 따르는 표준 인터페이스 집합 이다.
EntityManager, @Entity, @Table 등이 JPA가 정의한 표준 요소들이다.

Spring Data JPA

JPA를 더 편리하게 사용할 수 있도록 Spring 팀이 추가로 감싼 편의 레이어 다.
Repository 인터페이스만 정의하면 기본 CRUD를 자동으로 구현해주는 등, 반복 코드를 크게 줄여준다.

5. Hibernate란?

Hibernate는 현재 사실상 Java ORM의 표준 구현체로 자리 잡은 오픈소스 프레임워크다.
JPA 명세의 거의 모든 기능을 구현하며, 추가적인 고급 기능도 제공한다.

Spring Boot에서 spring-boot-starter-data-jpa 의존성을 추가하면, 기본적으로 Hibernate가 JPA 구현체로 자동 설정된다.

Hibernate의 핵심 기능

기능	설명
자동 SQL 생성	객체 조작에 따라 INSERT/UPDATE/DELETE/SELECT SQL을 자동 생성
영속성 컨텍스트	객체의 상태를 관리하는 1차 캐시 영역
지연 로딩 (Lazy Loading)	연관된 객체를 실제로 사용할 때까지 DB 조회를 미룸
HQL / JPQL	객체 지향적인 쿼리 언어 지원
캐싱 (2차 캐시)	성능 향상을 위한 캐시 기능

6. Spring Data JPA란 무엇인가?

JPA만 사용할 때의 불편함

JPA를 직접 사용하면 EntityManager 를 주입받아 매번 비슷한 CRUD 코드를 작성해야 한다.

// JPA EntityManager를 직접 사용하는 경우
@Repository
public class MemberRepository {
    
    @PersistenceContext
    private EntityManager em;
    
    public void save(Member member) {
        em.persist(member);
    }
    
    public Member findById(Long id) {
        return em.find(Member.class, id);
    }
    
    public List<Member> findAll() {
        return em.createQuery("SELECT m FROM Member m", Member.class).getResultList();
    }
    
    public void delete(Member member) {
        em.remove(member);
    }
}

save, findById, findAll, delete 같은 기본 CRUD는 모든 엔티티에 반복적으로 등장한다.
Member 뿐만 아니라 Order, Product, Review 등 엔티티마다 동일한 코드를 작성해야 한다면 매우 비효율적이다.

Spring Data JPA의 해결책

Spring Data JPA 는 이 반복을 제거한다.
개발자가 인터페이스만 선언 하면, Spring이 런타임에 자동으로 구현체를 만들어준다.

// Spring Data JPA 사용 — 이게 전부다!
public interface MemberRepository extends JpaRepository<Member, Long> {
    // 기본 CRUD는 자동으로 제공됨
    // 필요한 쿼리만 메서드 이름으로 선언하면 됨
    List<Member> findByName(String name);
    Optional<Member> findByEmail(String email);
}

JpaRepository<Member, Long> 을 상속받는 것만으로
save(), findById(), findAll(), delete() 등 수십 개의 메서드가 자동으로 생긴다.

메서드 이름으로 쿼리 생성 (Query Method)

Spring Data JPA의 강력한 기능 중 하나는 메서드 이름만으로 쿼리를 자동 생성 해주는 것이다.

// 메서드 이름 → 자동 생성되는 SQL
findByName(String name)
// → SELECT * FROM member WHERE name = ?

findByAgeGreaterThan(int age)
// → SELECT * FROM member WHERE age > ?

findByNameAndEmail(String name, String email)
// → SELECT * FROM member WHERE name = ? AND email = ?

findByNameContaining(String keyword)
// → SELECT * FROM member WHERE name LIKE '%keyword%'

7. Entity란 무엇인가?

Entity의 정의

Entity(엔티티) 는 데이터베이스 테이블과 매핑되는 Java 클래스다.
JPA는 Entity 클래스를 보고 어떤 테이블에 어떤 컬럼으로 저장할지 파악한다.

import jakarta.persistence.*;

@Entity                          // 이 클래스가 JPA Entity임을 선언
@Table(name = "member")          // 매핑할 테이블 이름 (생략하면 클래스 이름 사용)
public class Member {
    
    @Id                          // 기본 키(PK) 필드임을 선언
    @GeneratedValue(strategy = GenerationType.IDENTITY)  // PK 자동 생성 전략
    private Long id;
    
    @Column(name = "member_name", nullable = false, length = 50)
    private String name;         // DB 컬럼과 매핑
    
    @Column(unique = true)
    private String email;
    
    protected Member() {}        // JPA는 기본 생성자가 반드시 필요 (public 또는 protected)
    
    public Member(String name, String email) {
        this.name = name;
        this.email = email;
    }
    
    // Getter/Setter...
}

주요 JPA 어노테이션

annotation	역할
@Entity	이 클래스가 JPA 관리 대상 엔티티임을 선언
@Table	매핑할 DB 테이블 지정
@Id	기본 키(Primary Key) 필드 지정
@GeneratedValue	PK 자동 생성 전략 설정
@Column	컬럼 세부 설정 (이름, null 허용 여부, 길이 등)
@ManyToOne, @OneToMany	연관관계 매핑
@Transient	이 필드는 DB에 저장하지 않음

@GeneratedValue 전략

PK를 자동으로 생성할 때 4가지 전략이 있다.

전략	설명	주로 사용하는 DB
IDENTITY	DB가 PK 자동 증가	MySQL, MariaDB
SEQUENCE	DB 시퀀스 사용	Oracle, PostgreSQL
TABLE	별도 키 생성 테이블 사용	모든 DB (잘 안 씀)
AUTO	DB에 따라 자동 선택	기본값

8. 영속성 컨텍스트 (Persistence Context)

JPA를 이해하는 데 있어 가장 중요한 핵심이다.
영속성 컨텍스트는 JPA의 1차 캐시, 쓰기 지연, 변경 감지를 위해 필수적이기 때문이다.

영속성 컨텍스트란?

영속성 컨텍스트(Persistence Context) 는 엔티티를 영구 저장하는 환경이다.
쉽게 말하면 JPA가 관리하는 엔티티들을 담아두는 메모리 공간이다.

️ 영속성 컨텍스트 = JPA가 관리하는 엔티티 저장소 (메모리 위)

이 컨텍스트는 EntityManager 를 통해 접근한다.
하나의 EntityManager는 하나의 영속성 컨텍스트를 가진다.

EntityManager ↔ Persistence Context ↔ DB

EntityManager

EntityManager 는 영속성 컨텍스트를 통해 엔티티를 관리하는 JPA의 핵심 인터페이스다.
CRUD 작업, 트랜잭션, 쿼리 실행 등의 작업을 담당한다.

Spring Data JPA를 쓰면 EntityManager를 직접 다룰 일은 거의 없지만, 내부적으로는 항상 EntityManager가 동작한다.

트랜잭션과 영속성 컨텍스트

Spring에서 영속성 컨텍스트의 생명주기는 기본적으로 트랜잭션(Transaction)과 함께한다.

트랜잭션 시작 → 영속성 컨텍스트 생성
트랜잭션 커밋(commit) → DB에 반영 + 영속성 컨텍스트 종료
트랜잭션 롤백(rollback) → 변경 취소 + 영속성 컨텍스트 종료

트랜잭션(Transaction) 이란? 데이터베이스의 작업 단위다. "모두 성공하거나, 하나라도 실패하면 전부 취소"하는 원자성(Atomicity)을 보장한다. @Transactional 어노테이션으로 선언한다.

9. Entity의 생명주기 (Life Cycle)

엔티티는 영속성 컨텍스트와의 관계에 따라 4가지 상태를 가진다.

        new Member()
             │
             ▼
     ┌─────────────────┐
     │  비영속 상태       │  ← JPA가 모르는 상태 (일반 Java 객체)
     │  (New/Transient)│
     └───────┬─────────┘
             │ em.persist(member)
             ▼
     ┌───────────────┐
     │   영속 상태     │  ← JPA가 관리하는 상태 (영속성 컨텍스트에 저장됨)
     │  (Managed)    │◄──────────────────────────┐
     └─────────┬─────┘                           │
               │                           em.merge(member)
    em.detach()│                                 │
    em.clear() │                                 │
               ▼                                 │
     ┌───────────────┐                           │
     │  준영속 상태     │  ← 한때 영속이었지만 분리됨     │
     │  (Detached)   │ ──────────────────────────┘
     └─────────┬─────┘
               │
    em.remove()│
               ▼
     ┌───────────────┐
     │   삭제 상태     │  ← DB에서 삭제 예정
     │  (Removed)    │
     └───────────────┘

각 상태 설명

1. 비영속 (New / Transient)

엔티티 객체를 방금 new 로 생성한 상태다.
JPA와 전혀 관계가 없다. 일반 Java 객체와 동일하다.

Member member = new Member("홍길동", "hong@email.com");
// 이 시점의 member는 비영속 상태
// JPA는 이 객체의 존재를 모른다

2. 영속 (Managed)

엔티티가 영속성 컨텍스트에 저장된 상태다.
JPA가 이 객체를 추적하고 관리 한다.
em.persist() 를 호출하거나, em.find() 로 DB에서 조회한 엔티티는 영속 상태가 된다.

em.persist(member); // 영속 상태로 전환
// 또는
Member found = em.find(Member.class, 1L); // DB에서 조회 → 영속 상태

중요: em.persist() 를 호출한다고 즉시 DB에 INSERT SQL이 실행되는 게 아니다.
영속성 컨텍스트에 등록될 뿐이며, 실제 SQL은 트랜잭션 커밋 시점에 실행된다. (→ 쓰기 지연 참고)

3. 준영속 (Detached)

영속성 컨텍스트에서 분리된 상태다. 한때 영속 상태였지만, JPA의 관리에서 벗어난 상태다.
변경 감지, 지연 로딩 등의 JPA 기능이 동작하지 않는다.

em.detach(member); // 특정 엔티티만 분리
em.clear();        // 영속성 컨텍스트 전체 초기화
em.close();        // EntityManager 종료

트랜잭션이 끝난 후, Controller나 View 계층에서 엔티티를 사용할 때 이 상태가 된다.

4. 삭제 (Removed)

엔티티를 삭제 요청한 상태다. 트랜잭션 커밋 시점에 DELETE SQL이 실행된다.

em.remove(member); // 삭제 상태로 전환

10. 1차 캐시 (First-Level Cache)

1차 캐시란?

영속성 컨텍스트 내부에는 Map 형태의 저장소가 있다. 이것이 바로 1차 캐시 다.
Key는 엔티티의 @Id 값(PK), Value는 엔티티 객체다.

영속성 컨텍스트 (1차 캐시)
┌─────────────────────────────────┐
│  Key (PK)  │  Value (Entity)    │
├────────────┼────────────────────┤
│  1L        │  Member{id=1, ...} │
│  2L        │  Member{id=2, ...} │
└─────────────────────────────────┘

1차 캐시의 동작

em.find() 로 엔티티를 조회할 때, JPA는 먼저 1차 캐시를 확인 한다.

// 1차 캐시 동작 예시
Member m1 = em.find(Member.class, 1L); // DB 조회 → 1차 캐시에 저장
Member m2 = em.find(Member.class, 1L); // 1차 캐시에서 반환 (DB 조회 없음!)

m1 == m2; // true! 같은 인스턴스

첫 번째 find(): 1차 캐시에 없음 → DB에 SELECT SQL 실행 → 결과를 1차 캐시에 저장 → 반환

두 번째 find(): 1차 캐시에 있음 → DB 조회 없이 캐시에서 바로 반환

1차 캐시의 장점

불필요한 DB 조회 감소 — 동일한 트랜잭션 내에서 같은 엔티티를 여러 번 조회해도 SQL은 한 번만 실행된다.
동일성 보장 — 같은 PK로 조회한 엔티티는 항상 같은 인스턴스다 (== 비교 가능).

1차 캐시의 범위

1차 캐시는 트랜잭션 단위로 존재 한다. 트랜잭션이 끝나면 영속성 컨텍스트가 종료되고 1차 캐시도 사라진다.
애플리케이션 전체에서 공유되는 캐시가 아님을 주의해야 한다.

2차 캐시(Second-Level Cache) 란? Hibernate는 여러 트랜잭션에 걸쳐 공유되는 2차 캐시도 지원한다.
애플리케이션 레벨에서 공유되는 캐시로, 별도 설정이 필요하다. (예: EhCache, Redis 연동)

11. 쓰기 지연 (Write-Behind)

쓰기 지연이란?

영속성 컨텍스트는 내부에 쓰기 지연 SQL 저장소(ActionQueue) 를 가지고 있다.
엔티티를 persist() 하거나 변경해도, SQL이 즉시 DB로 전송되지 않는다.
대신, SQL을 이 저장소에 모아두었다가 트랜잭션 커밋 직전에 한꺼번에 DB로 전송 한다.

이 동작을 쓰기 지연(Transactional Write-Behind) 이라고 한다.

쓰기 지연의 동작 과정

@Transactional
public void saveMembersExample() {
    Member m1 = new Member("홍길동", "hong@email.com");
    Member m2 = new Member("김철수", "kim@email.com");
    
    em.persist(m1); // SQL 저장소에 INSERT 쌓기 (DB 전송 X)
    em.persist(m2); // SQL 저장소에 INSERT 쌓기 (DB 전송 X)
    
    // 이 시점까지 DB에는 아무 변화가 없음
    
} // 메서드 종료 → 트랜잭션 커밋 → flush() 실행 → SQL 일괄 전송 → DB 반영

1. em.persist(m1) 호출
   → 영속성 컨텍스트에 m1 저장
   → SQL 저장소: [INSERT INTO member VALUES (m1)]
   → DB: 변화 없음

2. em.persist(m2) 호출
   → 영속성 컨텍스트에 m2 저장
   → SQL 저장소: [INSERT INTO member VALUES (m1), INSERT INTO member VALUES (m2)]
   → DB: 변화 없음

3. 트랜잭션 커밋
   → flush() 실행: 저장소의 SQL 일괄 DB 전송
   → DB: m1, m2 저장 완료

flush()란?

flush() 는 영속성 컨텍스트의 변경 내용을 DB에 동기화하는 작업이다. 트랜잭션 커밋 시 자동으로 호출된다.

flush()를 한다고 트랜잭션이 커밋되는 건 아니다. DB에 SQL을 전송할 뿐이며, 커밋은 별개다.

쓰기 지연의 장점

성능 최적화: 여러 SQL을 하나의 배치(Batch)로 전송할 수 있다.
DB와의 통신 횟수 감소: 10번 persist해도 DB 요청은 한 번.
불필요한 DB 부하 제거: 취소될 수 있는 작업을 미리 DB에 보내지 않아도 된다.

12. 변경 감지 (Dirty Checking)

변경 감지란?

JPA의 가장 마법 같은 기능 중 하나다.
영속 상태의 엔티티를 수정하기만 해도, 트랜잭션 커밋 시점에 JPA가 자동으로 UPDATE SQL을 실행 한다.
개발자가 직접 save() 나 update() 를 호출할 필요가 없다.

@Transactional
public void updateMember(Long id) {
    Member member = em.find(Member.class, id); // 영속 상태로 조회
    
    member.setName("새이름"); // 그냥 setter 호출만 해도...
    
    // em.persist(member); // 이 코드가 없어도!
    // em.update(member);  // 이런 메서드도 없음!
    
} // 트랜잭션 커밋 → JPA가 자동으로 UPDATE SQL 실행

변경 감지의 동작 원리

JPA는 어떻게 변경을 감지할까? 바로 스냅샷(Snapshot) 을 활용한다.

영속화 시점: 엔티티가 영속성 컨텍스트에 들어올 때, JPA는 해당 엔티티의 초기 상태를 복사해 스냅샷으로 저장 한다.
커밋 시점: flush()가 호출될 때, JPA는 현재 엔티티 상태와 스냅샷을 비교한다.
차이 발생 시: 변경된 필드가 있으면 UPDATE SQL을 자동으로 생성해 실행한다.

영속성 컨텍스트
┌────────────────────────────────────────────┐
│ 1차 캐시                                     │
│  Member{id=1, name="홍길동", email="hong@"}  │ ← 현재 상태
│                                            │
│ 스냅샷                                       │
│  Member{id=1, name="홍길동", email="hong@"}  │ ← 최초 상태 (복사본)
└────────────────────────────────────────────┘

member.setName("김길동") 호출 후:

┌────────────────────────────────────────────┐
│ 1차 캐시                                     │
│  Member{id=1, name="김길동", email="hong@"}  │ ← 현재 상태 (변경됨)
│                                            │
│ 스냅샷                                       │
│  Member{id=1, name="홍길동", email="hong@"}  │ ← 최초 상태 (그대로)
└────────────────────────────────────────────┘
      ↓ flush() 시 비교
UPDATE member SET name='김길동' WHERE id=1

변경 감지 주의사항

변경 감지는 영속 상태의 엔티티에만 동작 한다. 트랜잭션 밖에서 엔티티를 수정하거나,
준영속(Detached) 상태의 엔티티를 수정해도 UPDATE SQL은 실행되지 않는다.

// ❌ 변경 감지 동작 안 함 (트랜잭션 없음)
Member member = memberRepository.findById(1L).get();
member.setName("새이름"); // 준영속 상태 → DB 반영 안 됨

// ✅ 변경 감지 동작 (트랜잭션 있음)
@Transactional
public void update(Long id) {
    Member member = memberRepository.findById(id).get(); // 영속 상태
    member.setName("새이름"); // → 커밋 시 UPDATE 자동 실행
}

13. Spring Data JPA 실전 사용법

의존성 추가

<!-- Maven -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
</dependency>

// Gradle
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
runtimeOnly 'com.mysql:mysql-connector-j'

application.yml 설정

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb
    username: root
    password: password
    driver-class-name: com.mysql.cj.jdbc.Driver

  jpa:
    hibernate:
      ddl-auto: update       # 애플리케이션 시작 시 테이블 자동 생성/수정
    show-sql: true            # 실행되는 SQL 로그 출력
    properties:
      hibernate:
        format_sql: true      # SQL 로그를 보기 좋게 포맷

ddl-auto 옵션 설명

create: 시작 시 테이블 삭제 후 재생성 (데이터 유실 위험)

update: 변경된 스키마만 반영 (기존 데이터 보존)

validate: 스키마 검증만 (변경 없음)

none: 아무것도 안 함

운영 환경에서는 반드시 validate 또는 none 사용 권장

전체 예시 코드

// 1. Entity 정의
@Entity
@Table(name = "member")
@Getter @Setter
@NoArgsConstructor
public class Member {
    
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    @Column(nullable = false)
    private String name;
    
    @Column(unique = true, nullable = false)
    private String email;
    
    public Member(String name, String email) {
        this.name = name;
        this.email = email;
    }
}

// 2. Repository 정의
public interface MemberRepository extends JpaRepository<Member, Long> {
    Optional<Member> findByEmail(String email);
    List<Member> findByNameContaining(String keyword);
    
    // JPQL 직접 작성도 가능
    @Query("SELECT m FROM Member m WHERE m.name = :name AND m.email = :email")
    Optional<Member> findByNameAndEmail(@Param("name") String name, 
                                        @Param("email") String email);
}

// 3. Service 계층 — 트랜잭션 관리
@Service
@RequiredArgsConstructor
public class MemberService {
    
    private final MemberRepository memberRepository;
    
    @Transactional
    public Member createMember(String name, String email) {
        Member member = new Member(name, email);
        return memberRepository.save(member); // persist → 영속화
    }
    
    @Transactional(readOnly = true)  // 읽기 전용 트랜잭션 (성능 최적화)
    public Member getMember(Long id) {
        return memberRepository.findById(id)
                .orElseThrow(() -> new RuntimeException("회원을 찾을 수 없습니다."));
    }
    
    @Transactional
    public void updateMemberName(Long id, String newName) {
        Member member = memberRepository.findById(id)
                .orElseThrow(() -> new RuntimeException("회원을 찾을 수 없습니다."));
        member.setName(newName); // 변경 감지 → 자동 UPDATE
        // save() 호출 불필요!
    }
    
    @Transactional
    public void deleteMember(Long id) {
        memberRepository.deleteById(id);
    }
}

JPQL이란?

JPQL(Java Persistence Query Language) 은 JPA에서 사용하는 객체 지향 쿼리 언어다.
SQL과 비슷하지만, 테이블과 컬럼이 아닌 엔티티 클래스와 필드명을 사용 한다.

-- SQL (테이블/컬럼 대상)
SELECT * FROM member WHERE name = 'hong'

-- JPQL (엔티티/필드 대상)
SELECT m FROM Member m WHERE m.name = 'hong'

14. 정리 및 흐름 요약

전체 흐름 한 눈에 보기

[Spring Boot Application]
        │
        │ Repository 메서드 호출
        ▼
[Spring Data JPA]
  JpaRepository 구현체 자동 생성
        │
        │ EntityManager 호출
        ▼
[JPA / Hibernate]
  영속성 컨텍스트 관리
  ┌─────────────────────────────┐
  │ 1차 캐시                      │
  │ 쓰기 지연 SQL 저장소            │
  │ 스냅샷 (변경 감지용)             │
  └─────────────────────────────┘
        │
        │ 트랜잭션 커밋 → flush()
        ▼
[JDBC]
  SQL 실행 (커넥션 풀 관리)
        │
        ▼
[RDBMS]
  실제 데이터 저장

allluck777

[멋사 클라우드 5기] Day 37 & 38 - Linux (3)

Chapter 18. 환경변수 & 셸 설정

환경변수

셸 변수 vs 환경변수

환경변수 확인 및 설정

설정 및 해제

주요 시스템 환경변수

PATH — 가장 중요한 환경변수

PATH에 경로 추가

"command not found" 문제 해결

히스토리 관리

보안: 히스토리에 민감한 정보 남기지 않기

Chapter 19. 사용자 & 그룹 관리

리눅스의 사용자 체계

사용자 정보가 저장되는 파일

사용자 관리 명령어

useradd — 사용자 생성

usermod — 사용자 수정

그룹 관리

그룹 관리 명령어

그룹 변경 즉시 적용

그룹 활용

Docker 그룹

sudo 그룹

서비스 전용 사용자 생성

사용자 전환

su — Switch User

sudo su - vs sudo -i

사용자 정보 확인 명령어

시나리오

새 팀원 온보딩

퇴사자 계정 처리

Chapter 20. 패키지 관리

패키지 관리

패키지 매니저의 역할

배포판별 패키지 시스템

APT — Debian/Ubuntu 패키지 관리

패키지 목록 업데이트

패키지 설치/삭제/업그레이드

패키지 검색 및 정보 확인

패키지 버전 고정 (Version Pinning)

APT (Debian/Ubuntu)

핵심 원칙

Chapter 21. 네트워킹

IP 주소

포트 (Port)

DNS (Domain Name System)

TCP vs UDP

CIDR 표기법

네트워크 인터페이스 확인

ip — 현대적 네트워크 도구

연결 진단 명령어

ping — 기본 연결 확인

curl — HTTP 요청 테스트

dig / nslookup — DNS 조회

traceroute / tracepath — 경로 추적

포트 & 연결 확인

ss — 소켓 통계

netstat — 전통적 네트워크 통계

파일 전송

wget — 파일 다운로드

curl vs wget

네트워크 트러블슈팅 체계

요약

Chapter 22. SSH & 원격 접속

SSH

SSH의 용도

SSH의 동작 방식

키 기반 인증 (Key-Based Authentication)

공개 키 / 개인 키

SSH 키 생성

서버에 공개 키 등록

키 파일 권한 (필수!)

SSH 접속

첫 접속 시 fingerprint 확인

SSH 설정 파일 (~/.ssh/config)

파일 전송

scp — 파일 복사

Chapter 23. 셸 스크립트 기초

`PATH` — 가장 중요한 환경변수

`useradd` — 사용자 생성

`usermod` — 사용자 수정

`su` — Switch User

`sudo su -` vs `sudo -i`

`ip` — 현대적 네트워크 도구

`ping` — 기본 연결 확인

`curl` — HTTP 요청 테스트

`dig` / `nslookup` — DNS 조회

`traceroute` / `tracepath` — 경로 추적

`ss` — 소켓 통계

`netstat` — 전통적 네트워크 통계

`wget` — 파일 다운로드

`curl` vs `wget`

SSH 설정 파일 (`~/.ssh/config`)

`scp` — 파일 복사

Shebang (`#!`)

`if` 문

`[[ ]]` vs `[ ]`

`for` 문

`while` 문

`until` 문

`set` 옵션 — 안전한 스크립트의 시작

`trap` — 종료 시 정리 작업

`sort` — 텍스트 정렬

`uniq` — 중복 처리

핵심 패턴: `sort | uniq -c | sort -rn`

`wc` — 텍스트 통계

`cut` — 필드 추출

`cut` vs `awk` — 언제 무엇을 쓰는가

`tr` — 문자 변환 (보충)

`diff` — 파일 비교

출력 리다이렉션 (`>`, `>>`)

에러 리다이렉션 (`2>`, `2>>`)

입력 리다이렉션 (`<`)

Here Document (`<<`)

파이프 (Pipe, `|`)

`tee` — 출력을 파일과 화면 동시에

`xargs` vs 파이프

`~/.vimrc` — 영구 설정