개발이군고구마

[리눅스 심화 ②] 패킷은 어떻게 흐르는가: 소켓부터 컨테이너 네트워크까지

김구황 — Sun, 12 Jul 2026 21:00:37 +0900

0. 들어가며: 네트워크도 결국 파일과 프로세스다

이 시리즈의 관통 주제는 "고급 개념은 리눅스 기초의 조합"임. 네트워크도 예외가 아님.

소켓은 결국 파일 디스크립터(FD)임 → [기초편]의 "모든 것은 파일이다"와 연결됨.
컨테이너 네트워크는 NET namespace + iptables의 조합임 → [프로세스편]과 연결됨.

과거 스테이징 환경 디버깅에서 정리했던 OSI 계층(L3/L4/L7), 포워드 프록시, SNAT 개념이 이 글에서 하나의 그림으로 합쳐짐. 아래 순서로 진행함.

1. 패킷의 여정: 애플리케이션에서 NIC까지

애플리케이션이 데이터를 보낼 때, 그 데이터는 곧바로 랜선으로 나가지 않음. 커널의 여러 계층을 통과하며 각 계층이 헤더(주소표)를 하나씩 덧붙이는 과정을 거침. 이를 캡슐화(encapsulation)라 함.

수신은 정확히 이 반대 순서로, 각 계층이 헤더를 하나씩 벗겨내며(역캡슐화) 최종적으로 애플리케이션에 데이터를 전달함.

1.1 OSI 계층과 실무 개념의 매핑

과거에 정리했던 OSI 계층을 실무에서 마주치는 장비·개념과 연결하면 아래와 같음. "이 문제는 몇 계층 문제인가"를 판단하는 것이 네트워크 트러블슈팅의 첫걸음임.

계층	이름	다루는 주소	대표 장비·개념
L7	애플리케이션	URL, HTTP 헤더	프록시(nginx), API Gateway, WAF
L4	전송	포트 번호	L4 로드밸런서, TCP/UDP, 방화벽
L3	네트워크	IP 주소	라우터, NAT, iptables
L2	데이터링크	MAC 주소	스위치, ARP

SNAT vs 프록시의 근본 차이가 여기서 명확해짐. SNAT는 L3(IP 헤더)만 바꿔치기하는 것이라 애플리케이션은 눈치채지 못함. 반면 프록시는 L7에서 연결을 한 번 끊고 대신 맺어주는 것이라 연결 자체가 두 개로 나뉨. 같은 "중계"처럼 보여도 동작 계층이 완전히 다름. 이 차이가 스테이징 프록시 디버깅에서 헷갈렸던 핵심이었음.

2. 소켓과 포트: 프로세스가 네트워크에 연결되는 접점

2.1 소켓은 파일 디스크립터다

[기초편]에서 "모든 것은 파일"이라 했음. 네트워크 통신도 예외가 아님. 프로세스가 네트워크로 통신할 때, 커널은 소켓(socket)이라는 특수 파일을 열어주고, 그 소켓에 접근하는 파일 디스크립터(FD)를 프로세스에 발급함.

즉 프로세스 입장에서 네트워크 통신은 "어떤 FD에 데이터를 읽고 쓰는 것"일 뿐임. 디스크 파일에 쓰는 것과 문법상 동일함. 이것이 리눅스 네트워크의 출발점임.

2.2 포트: 하나의 IP 안에서 프로세스를 구분하는 번호

IP 주소는 "어느 서버인가"를 식별함(L3). 하지만 서버 하나에는 웹 서버, DB, SSH 등 여러 프로세스가 동시에 통신함. 이들을 구분하는 것이 포트(port)임(L4).

IP:Port 조합이 통신의 최종 종착지를 결정함. (예: 10.0.1.5:8080)
하나의 연결은 출발지 IP:Port ↔ 도착지 IP:Port의 4가지 값 조합으로 유일하게 식별됨.

[프로세스편]에서 "컨테이너마다 80 포트를 각자 쓸 수 있다"고 한 것이 이제 명확해짐. 각 컨테이너가 독립된 NET namespace를 가져 자기만의 IP:Port 공간을 갖기 때문임.

3. ss로 TCP 상태 읽기: LISTEN, ESTABLISHED, TIME_WAIT

소켓의 상태를 읽는 도구가 ss임(구형 netstat의 후계). TCP 연결이 지금 어떤 상태인지를 보여줌.

3.1 자주 쓰는 ss 명령어

ss -tnlp    # TCP, 숫자표시, LISTEN 중인 것, 프로세스명 → "무슨 포트가 열려있나"
ss -tnp     # 현재 맺어진 연결 확인 → "누가 나에게 붙어있나"
ss -s       # 전체 소켓 통계 요약
ss state time-wait   # 특정 상태만 필터링

3.2 TCP 연결의 생성과 종료

TCP 상태를 이해하려면 연결의 시작(3-way handshake)과 끝(4-way termination)을 알아야 함.

3.3 실무에서 반드시 구분해야 할 두 상태

상태	의미	많이 쌓이면?
`LISTEN`	연결을 기다리는 서버 소켓	정상 (서비스가 떠 있다는 뜻)
`ESTABLISHED`	현재 데이터를 주고받는 연결	정상 (동시 접속 수 지표)
`TIME_WAIT`	연결을 먼저 끊은 쪽이 잔여 패킷 처리를 위해 잠시 대기	단기 연결이 폭증하는 신호
`CLOSE_WAIT`	상대는 끊었는데 내 애플리케이션이 소켓을 안 닫음	애플리케이션 버그

이 두 가지는 반드시 구분해야 함. 원인 주체가 정반대이기 때문임.

TIME_WAIT 폭증: 대개 정상 동작의 부작용임. 짧은 연결을 대량으로 맺고 끊을 때(예: 커넥션 풀 없이 매 요청마다 새 연결) 발생함. 커널 파라미터 튜닝이나 커넥션 재사용(keep-alive, 커넥션 풀)로 완화함.
CLOSE_WAIT 폭증: 거의 항상 애플리케이션 버그임. 상대방이 FIN을 보냈는데 내 코드가 소켓을 close()하지 않아 생김. 방치하면 FD가 고갈되어 "Too many open files" 에러로 이어짐. 코드에서 소켓·커넥션을 제대로 닫는지 점검해야 함.

[기초편]에서 lsof로 프로세스가 연 FD를 봤던 것을 기억할 것. CLOSE_WAIT이 쌓이는 건 결국 FD 누수임. "Too many open files"와 CLOSE_WAIT은 같은 문제의 다른 얼굴임.

4. iptables와 NAT: 컨테이너가 외부와 통신하는 원리

4.1 iptables란

iptables는 리눅스 커널의 방화벽·패킷 처리 프레임워크임. 패킷이 커널을 통과하는 지점마다 규칙(rule)을 걸어 허용/차단/변조함. 크게 두 가지 용도로 씀.

filter 테이블: 패킷을 허용하거나 막음(방화벽). INPUT, OUTPUT, FORWARD 체인.
nat 테이블: 패킷의 IP·포트를 바꿔치기함(주소 변환). PREROUTING, POSTROUTING 체인.

4.2 NAT: 주소를 바꿔치기하는 L3 기술

NAT(Network Address Translation)는 패킷의 IP 주소를 변환하는 기술임. 방향에 따라 두 종류로 나뉨.

종류	변환 대상	용도	방향
SNAT (Source NAT)	출발지 IP를 바꿈	내부 사설 IP → 공인 IP (밖으로 나갈 때)	아웃바운드
DNAT (Destination NAT)	도착지 IP를 바꿈	공인 IP:Port → 내부 서버 (안으로 들어올 때)	인바운드

SNAT는 프록시가 아님(재확인). SNAT는 L3에서 IP 헤더의 출발지 주소만 갈아끼울 뿐, 연결 자체는 끊지 않고 그대로 통과시킴. 그래서 애플리케이션은 자신의 IP가 바뀐 줄 모름. 이것이 프록시(L7에서 연결을 새로 맺음)와의 결정적 차이임. docker run -p 8080:80이 바로 DNAT 규칙을 iptables에 추가하는 동작임.

5. DNS 조회 흐름: 이름이 IP로 바뀌는 과정

애플리케이션은 api.example.com 같은 이름으로 통신하지만, 실제 패킷은 IP 주소가 있어야 나감(L3). 이 이름→IP 변환이 DNS 조회(resolution)임.

5.1 조회 순서

리눅스는 정해진 순서로 이름을 찾음. 이 순서를 모르면 "코드는 맞는데 왜 특정 서버에서만 접속이 안 되는가" 같은 문제를 못 풂.

5.2 핵심 설정 파일

파일	역할
`/etc/hosts`	이름-IP를 직접 매핑(정적). DNS보다 먼저 조회됨
`/etc/resolv.conf`	질의할 DNS 서버(nameserver) 목록
`/etc/nsswitch.conf`	조회 순서(files → dns)를 정의

실무 활용: 테스트 시 특정 도메인을 강제로 특정 IP로 보내려면 /etc/hosts에 한 줄 추가하면 됨(DNS보다 우선하므로). 반대로 "hosts엔 없는데 조회가 이상하다"면 /etc/resolv.conf의 DNS 서버가 잘못됐거나 응답이 느린 것임. Docker 컨테이너는 보통 /etc/resolv.conf가 내장 DNS(127.0.0.11)를 가리켜 서비스명으로 컨테이너 간 통신이 됨.

6. 종합: 컨테이너 네트워크는 어떻게 완성되는가

이제 모든 조각을 합침. [프로세스편]에서 "컨테이너 = namespace + cgroup + 파일시스템"이라 했음. 그 중 네트워크 격리(NET namespace)가 실제로 어떻게 외부 통신까지 이어지는지를, 이 글의 개념들로 완성함.

컨테이너가 외부와 통신하려면 세 가지 부품이 조합됨.

NET namespace — 컨테이너에 독립된 네트워크 스택(자기만의 IP, 포트, 라우팅 테이블)을 줌.
veth pair (가상 랜선) — 한쪽 끝은 컨테이너 안에, 다른 쪽 끝은 호스트에 꽂히는 가상의 랜선 한 쌍. 격리된 namespace를 호스트와 연결함.
bridge (가상 스위치) + iptables NAT — 호스트의 가상 스위치(docker0)가 컨테이너들을 묶고, SNAT(아웃바운드)·DNAT(포트 포워딩)로 외부와 연결함.

흐름 정리: 컨테이너 A가 외부로 요청을 보내면 → veth를 타고 docker0 브리지에 도달 → iptables가 SNAT로 출발지를 호스트 IP로 바꿈 → NIC를 통해 외부로 나감. 외부에서 컨테이너로 들어올 땐 반대로 DNAT로 도착지를 컨테이너 IP로 바꿈. 이 모든 게 앞에서 다룬 namespace·veth·NAT의 조합임.

한 줄 정리: 컨테이너 네트워크는 마법이 아니라 "격리된 NET namespace를 veth로 호스트에 잇고, iptables NAT로 외부와 연결한 것"임.

7. 실무 트러블슈팅 체크리스트

증상	확인 명령어	원인·해석
서비스 접속 안 됨	`ss -tnlp \| grep <포트>`	프로세스가 해당 포트를 `LISTEN` 중인지 확인
"Too many open files"	`ss -tnp state close-wait`	`CLOSE_WAIT` 누수 — 앱이 소켓을 안 닫음
순간적 커넥션 폭증	`ss -s` / `ss state time-wait`	`TIME_WAIT` 확인 — 커넥션 풀·keep-alive 검토
특정 도메인만 접속 실패	`cat /etc/resolv.conf`, `nslookup <도메인>`	DNS 조회 실패 또는 `/etc/hosts` 오설정
컨테이너에서 외부 통신 불가	`iptables -t nat -L -n`	SNAT(MASQUERADE) 규칙 존재 여부 확인
방화벽 차단 의심	`iptables -L -n`	filter 테이블의 INPUT/FORWARD 규칙 확인
어느 계층 문제인지 모름	`ping`(L3) → `telnet IP 포트`(L4) → `curl`(L7)	계층을 순서대로 좁혀가며 원인 격리

마지막 행이 핵심임. 문제를 만나면 낮은 계층부터 올라가며 원인을 좁힘. ping으로 L3(IP 도달) 확인 → telnet/nc로 L4(포트 열림) 확인 → curl로 L7(HTTP 응답) 확인. 어느 단계에서 막히는지가 곧 문제의 계층임.

[리눅스 심화 ①] 프로세스는 어떻게 태어나고, 격리되고, 컨테이너가 되는가

김구황 — Sun, 12 Jul 2026 20:54:03 +0900

0. 들어가며: 왜 프로세스를 더 깊이 봐야 하는가

앞 글에서 프로세스를 "부모가 자식을 낳는 나무 구조"로 이해함. 이 글은 그 나무의 뿌리(생성 원리)와 울타리(격리·제한)를 파고듦.

인프라 엔지니어에게 프로세스 심화가 중요한 이유는 명확함. Docker, Kubernetes 같은 컨테이너 기술이 새로운 마법이 아니라, 사실은 리눅스 프로세스의 두 가지 기능(namespace + cgroup)을 조합한 것이기 때문임. 이 원리를 알면 "컨테이너가 왜 격리되는가", "메모리 제한이 어떻게 걸리는가", "OOM Killer는 왜 뜨는가"가 전부 하나로 설명됨.

1. 프로세스는 어떻게 태어나는가: fork()와 exec()

1.1 리눅스에는 "그냥 실행"이 없다

가장 먼저 깨야 할 오해임. 리눅스에서 새 프로그램을 실행할 때, 무(無)에서 프로세스가 뿅 하고 생기지 않음. 반드시 기존 프로세스가 자신을 복제한 뒤, 그 복제본을 다른 프로그램으로 덮어쓰는 2단계를 거침. 이 두 단계가 fork()와 exec()임.

1.2 fork(): 자기 자신을 복제함

fork()는 현재 프로세스를 통째로 복제해서 자식 프로세스를 만드는 시스템 콜임.

부모의 메모리, 열린 파일(FD 테이블 포함!), 환경 변수를 그대로 물려받음.
복제 직후 부모와 자식은 거의 동일하지만, PID는 서로 다름.
fork()의 반환값으로 부모와 자식이 자신을 구분함: 부모는 자식의 PID를, 자식은 0을 받음.

앞 글에서 "자식은 부모의 FD 0/1/2를 물려받는다"고 했던 것이 바로 이 fork() 때문임. 그래서 셸에서 실행한 명령어가 별도 설정 없이도 화면(터미널)에 출력됨.

성능 팁 — Copy-on-Write(COW): 복제할 때 메모리 전체를 실제로 복사하면 무거움. 그래서 리눅스는 처음엔 부모·자식이 같은 물리 메모리를 공유하다가, 둘 중 하나가 값을 쓰려는 순간에만 그 부분을 복사함. 이 덕분에 fork()가 가벼움.

1.3 exec(): 자신을 다른 프로그램으로 덮어씀

exec()는 현재 프로세스의 메모리 내용을 새 프로그램으로 완전히 교체하는 시스템 콜임. 새 프로세스를 만드는 게 아니라, PID는 그대로 유지한 채 알맹이만 갈아치우는 것이 핵심임.

1.4 fork + exec: 셸이 명령어를 실행하는 방식

우리가 셸에서 ls를 치면 내부적으로 이런 일이 일어남.

이 fork → exec → wait 3박자가 리눅스에서 프로그램이 실행되는 근본 원리임. systemd가 서비스를 띄우는 것도, Docker가 컨테이너 프로세스를 띄우는 것도 결국 이 패턴의 변형임.

2. 프로세스의 생애주기: 상태와 좀비의 정체

프로세스는 태어나서 죽을 때까지 여러 상태(state)를 오감. ps aux의 STAT 열이나 top에서 이 상태를 볼 수 있음.

2.1 프로세스의 5가지 핵심 상태

상태	기호	의미	특징
Running	`R`	실행 중 또는 실행 대기(runnable)	CPU를 쓰고 있거나 곧 쓸 예정
Sleeping	`S`	대기(interruptible)	이벤트(입력, 응답)를 기다리는 정상 상태
Uninterruptible	`D`	대기(uninterruptible)	주로 디스크 I/O 중. kill -9로도 안 죽음
Stopped	`T`	정지	`Ctrl+Z`(SIGSTOP)로 멈춘 상태
Zombie	`Z`	좀비	죽었지만 아직 수거 안 된 상태 (아래 상세)

⚠️ D 상태(Uninterruptible Sleep) 는 실무에서 중요함. 이 상태의 프로세스는 커널 레벨에서 I/O를 기다리는 중이라 kill -9(SIGKILL)로도 죽지 않음. D 상태 프로세스가 쌓이면 대개 스토리지(디스크·NFS) 장애의 신호임. 프로세스를 억지로 죽이려 하기보다 I/O 병목의 원인을 찾아야 함.

2.2 좀비 프로세스(Zombie): 오해와 진실

좀비는 이름과 달리 위험하게 날뛰는 프로세스가 아님. 정반대로, 이미 죽어서 아무 일도 안 하는 프로세스임.

동작 원리는 이러함.

자식 프로세스가 종료됨 → 실행은 끝났지만, 자신의 종료 코드(exit code)를 부모가 읽어갈 때까지 프로세스 테이블에 흔적을 남김.
부모가 wait()를 호출해 그 종료 코드를 수거하면 → 흔적이 완전히 사라짐(정상).
그런데 부모가 wait()를 호출하지 않으면 → 자식은 종료 코드를 든 채 Z 상태로 계속 남음. 이것이 좀비임.

좀비 자체는 메모리·CPU를 쓰지 않음. 다만 프로세스 테이블의 한 칸(PID 슬롯)을 계속 점유함. 좀비가 대량으로 쌓이면 PID가 고갈되어 새 프로세스를 못 만드는 상황이 올 수 있음.

핵심: 좀비가 많이 보이면 그건 부모 프로세스(애플리케이션)가 자식을 제대로 수거하지 않는 버그의 증상임. 좀비를 직접 죽일 순 없음(이미 죽었으므로). 대신 부모 프로세스를 고치거나 재시작해야 함.

2.3 고아 프로세스(Orphan)와 systemd의 입양

반대 상황도 있음. 자식보다 부모가 먼저 죽는 경우임. 이때 부모를 잃은 자식을 고아 프로세스라 함.

리눅스는 고아를 방치하지 않음. 부모 잃은 프로세스는 자동으로 PID 1(systemd)에게 입양(re-parenting)됨. 그리고 systemd가 이 입양한 자식들이 죽을 때 wait()로 종료 코드를 수거해줌. 이 "입양 후 수거" 역할을 reaping이라 부름.

앞 글에서 systemd를 "PID 1, 모든 프로세스의 최상위 조상"이라 했던 것이 여기서 실질적 의미를 가짐. systemd는 단순 서비스 관리자가 아니라, 고아를 입양해 좀비가 시스템에 쌓이지 않게 하는 청소부 역할도 함. (Docker 컨테이너에서 init 프로세스를 넣어주는 이유도 이 reaping 때문임.)

3. 프로세스의 메모리 구조와 우선순위

3.1 프로세스 메모리 레이아웃 (간단히)

프로세스 하나가 차지하는 메모리는 용도별로 구획이 나뉘어 있음. 트러블슈팅 시 "메모리 누수가 어디서 나는가"를 판단하는 기초가 됨.

영역	저장 대상	특징
Text (Code)	실행할 기계어 코드	읽기 전용
Data / BSS	전역 변수, static 변수	프로그램 시작 시 크기 확정
Heap	`malloc` 등 동적 할당 메모리	위로 자람. 메모리 누수의 주범
Stack	함수 호출·지역 변수	아래로 자람. 너무 깊으면 stack overflow

3.2 우선순위: nice 값

CPU가 부족할 때 어떤 프로세스를 먼저 실행할지는 우선순위로 결정됨. 사용자가 조정할 수 있는 값이 nice 값(-20 ~ 19)임.

값이 낮을수록 우선순위 높음(-20이 최고 우선순위).
"nice(친절하다)"는 이름은 "양보한다"는 의미임. nice 값이 높을수록 다른 프로세스에게 CPU를 양보함.

nice -n 10 ./batch.sh     # 낮은 우선순위로 배치 작업 실행 (양보)
renice -n -5 -p 1234      # 실행 중인 프로세스(1234)의 우선순위를 높임

대용량 배치 작업을 nice로 낮은 우선순위로 돌리면, 실시간 서비스 응답에 주는 영향을 줄일 수 있음. 트래픽 많은 커머스 환경에서 유용한 기법임.

4. namespace: 프로세스가 "볼 수 있는 세계"를 격리함

여기서부터가 컨테이너의 뿌리임. 핵심 질문은 이것임.

"한 서버에서 도는 프로세스인데, 어떻게 서로를 못 보게 만들 수 있는가?"

답이 namespace(네임스페이스)임. namespace는 프로세스가 볼 수 있는 시스템 자원의 범위를 격리하는 커널 기능임. 한마디로 "시야 차단막"임.

4.1 namespace의 종류

리눅스는 자원 종류별로 여러 namespace를 제공함. 프로세스마다 각 자원에 대해 "어느 namespace에 속하는지"가 정해짐.

namespace	격리하는 대상	격리 효과
PID	프로세스 ID	컨테이너 안에서는 자기 프로세스가 PID 1로 보임
NET	네트워크	독립된 IP, 포트, 네트워크 인터페이스를 가짐
MNT	마운트(파일시스템)	자기만의 파일시스템 루트(`/`)를 봄
UTS	호스트명	독립된 hostname을 가질 수 있음
IPC	프로세스 간 통신	공유 메모리·세마포어를 격리
USER	사용자/그룹 ID	컨테이너 안의 root ≠ 호스트의 root

4.2 이게 왜 강력한가

PID namespace 덕분에 컨테이너 안의 프로세스는 자기가 PID 1(그 세계의 systemd 자리)이라고 믿음. 호스트에서 보면 그냥 PID 30521 같은 평범한 프로세스지만, 격리된 시야 안에서는 독립된 하나의 시스템처럼 동작함.

NET namespace 덕분에 컨테이너마다 80 포트를 각자 독립적으로 쓸 수 있음. 호스트에서는 하나뿐인 80 포트를, 컨테이너 A도 80, 컨테이너 B도 80으로 쓸 수 있는 이유가 이것임.

4.3 실무에서 namespace 들여다보기

lsns                        # 현재 시스템의 namespace 목록
ls -l /proc/<PID>/ns/       # 특정 프로세스가 속한 namespace들
nsenter -t <PID> -n ip addr # 특정 프로세스의 network namespace 안으로 들어가 명령 실행

5. cgroup: 프로세스가 "쓸 수 있는 자원의 양"을 제한함

namespace가 시야(무엇을 볼 수 있는가)를 격리한다면, cgroup은 자원(얼마나 쓸 수 있는가)을 제한함. 이 둘의 역할 구분이 컨테이너 이해의 핵심임.

5.1 cgroup이란

cgroup(Control Group)은 프로세스 그룹이 사용하는 자원(CPU, 메모리, 디스크 I/O 등)을 측정하고 제한하는 커널 기능임. "이 프로세스 그룹은 메모리 512MB, CPU 0.5코어까지만 써라"를 강제할 수 있음.

제한 대상	예시
CPU	"CPU 사용량을 최대 50%로 제한"
Memory	"메모리를 512MB까지만 허용"
I/O	"디스크 읽기/쓰기 대역폭 제한"
PIDs	"이 그룹은 최대 100개 프로세스까지만"

5.2 OOM Killer와의 연결

cgroup의 메모리 제한은 OOM(Out Of Memory) Killer와 직결됨. 프로세스가 자신에게 할당된 메모리 한도를 넘어서려 하면, 커널은 OOM Killer를 발동해 그 프로세스를 강제 종료함.

컨테이너가 갑자기 죽으면서 로그에 OOMKilled가 찍히는 상황이 바로 이것임. 애플리케이션이 cgroup으로 설정된 메모리 한도를 초과했다는 뜻임. JVM 힙 설정(-Xmx)을 컨테이너 메모리 제한보다 작게 잡아야 하는 이유도 여기 있음. JVM이 힙 외에 메타스페이스·스레드 스택도 쓰기 때문에, -Xmx를 cgroup 한도에 딱 맞추면 초과되어 OOMKilled 당함.

5.3 실무에서 cgroup·OOM 확인하기

systemd-cgtop                        # cgroup별 CPU·메모리 사용량 실시간 확인
cat /sys/fs/cgroup/memory.max        # (cgroup v2) 메모리 한도 확인
dmesg | grep -i "killed process"     # OOM Killer가 죽인 프로세스 기록 확인
journalctl -k | grep -i oom          # 커널 로그에서 OOM 이벤트 조회

6. 결론: 컨테이너는 마법이 아니라 프로세스다

이제 앞의 모든 조각이 하나로 맞춰짐. Docker 컨테이너는 새로운 종류의 무언가가 아니라, 그냥 리눅스 프로세스임. 다만 아래 세 가지 기능으로 포장된 프로세스임.

graph LR
    A["일반 프로세스"] --> B["+ namespace<br/>(시야 격리)"]
    B --> C["+ cgroup<br/>(자원 제한)"]
    C --> D["+ 이미지 파일시스템<br/>(격리된 루트)"]
    D --> E["= 컨테이너"]

컨테이너의 특징	실제로는 무엇인가
격리된 것처럼 보임	namespace로 시야를 차단한 프로세스
자원이 제한됨	cgroup으로 CPU·메모리를 묶은 프로세스
독립된 파일시스템을 가짐	이미지 레이어(union filesystem)로 만든 격리된 루트(`/`)
컨테이너 안 root	USER namespace로 매핑된, 호스트에서는 일반 사용자

한 줄 정리: namespace(무엇을 볼 수 있는가) + cgroup(얼마나 쓸 수 있는가) + 파일시스템(어디에 쓸 수 있는가) = 컨테이너.

VM(가상머신)이 하드웨어 위에 별도 OS를 통째로 올리는 무거운 방식이라면, 컨테이너는 호스트 커널을 공유하면서 프로세스만 격리하는 가벼운 방식임. 그래서 빠르고 가벼움. 이 차이의 근원이 바로 "컨테이너는 결국 프로세스"라는 사실임.

7. 실무 트러블슈팅 체크리스트

이 글의 개념들이 실제 운영에서 어떻게 쓰이는지 정리함.

증상	확인 명령어	원인
좀비(`Z`)가 쌓임	`ps aux \| grep defunct`	부모 프로세스가 자식을 수거 안 함 (앱 버그)
프로세스가 `kill -9`로도 안 죽음	`ps -eo pid,stat,cmd \| grep ' D'`	`D` 상태 — 스토리지 I/O 장애 의심
컨테이너가 갑자기 종료됨	`dmesg \| grep -i oom`	cgroup 메모리 한도 초과 (OOMKilled)
특정 서비스가 CPU 독점	`systemd-cgtop`	cgroup CPU 제한 미설정
컨테이너 네트워크 문제	`nsenter -t <PID> -n ip addr`	NET namespace 내부 상태 확인 필요

리눅스 운영체제

김구황 — Sun, 12 Jul 2026 20:30:44 +0900

0. 들어가며

catalina.out이 왜 무한히 커지는지, 2>&1이 무슨 뜻인지, systemd가 왜 필요한지

— 이 질문들의 답은 전부 "프로세스(Process)"와 "파일 디스크립터(File Descriptor)"라는 단 두 개의 뿌리 개념에서 나옴.

1. 리눅스의 근본 철학: "모든 것은 파일이다"

리눅스를 이해하는 첫 번째 열쇠는 "Everything is a file" 이라는 설계 철학임.

여기서 말하는 "파일"은 우리가 아는 텍스트 문서만이 아님. 리눅스는 아래의 모든 것을 파일이라는 동일한 인터페이스로 다룸.

종류	예시	설명
일반 파일	`/etc/hosts`	실제 데이터를 담은 파일
디렉터리	`/home`	다른 파일들의 목록을 담은 특수 파일
장치 파일	`/dev/sda`, `/dev/null`	디스크, 키보드 같은 하드웨어를 파일처럼 표현
소켓 · 파이프	`/var/run/*.sock`	프로세스 간 통신 통로
프로세스 정보	`/proc/1234/`	실행 중인 프로세스의 상태를 파일로 표현

핵심 함의: 리눅스에서는 디스크에 쓰든, 화면에 출력하든, 네트워크로 보내든 — 프로그램 입장에서는 전부 "파일에 읽고 쓰는" 동일한 동작임. 이 통일성이 다음에 나올 파일 디스크립터를 이해하는 전제가 됨.

2. 파일 디스크립터(File Descriptor): 0, 1, 2의 정체

JVM(자바 프로그램)을 실행하는 순간의 OS 내부 모습

프로세스 메모리 할당: OS가 JVM을 위한 메모리 공간을 만들고 프로세스 ID(PID)를 부여
FD 테이블 생성: 이때 이 JVM 전용의 FD 테이블(배열)도 커널 공간에 함께 생성
기본 티켓(0, 1, 2) 발급: OS는 묻지도 따지지도 않고 이 테이블의 앞자리 3개를 채워줌.
- 0번(표준 입력) ➔ 시스템의 키보드 입력 스트림과 연결
- 1번(표준 출력) ➔ 시스템의 모니터 콘솔 출력 스트림과 연결
- 2번(표준 에러) ➔ 시스템의 모니터 콘솔 에러 스트림과 연결

2.1 파일 디스크립터란

프로세스가 파일을 열면, 운영체제(커널)는 그 파일에 접근할 수 있는 정수 번호표(티켓)를 발급함. 이 번호가 바로 파일 디스크립터(FD)임. 프로세스는 파일의 실제 경로를 매번 들고 다니지 않고, 이 번호만으로 "3번 파일에 써줘"라고 커널에 요청함. 각 프로세스는 자신만의 FD 테이블을 가짐.

FD 테이블은 프로세스가 커널에게 일을 시키기 위한 '주문서 ID 목록'
"내가 가진 0번에 있는 거 읽어줘", "내가 가진 3번에 이거 적어줘"처럼 프로세스가 주도적으로 자기 테이블의 번호를 커널에 던지며 요청
커널은 요청을 받으면 그 요청을 보낸 프로세스가 누구인지 확인(PID)하고, 그 프로세스의 FD 테이블을 열어서 해당 번호에 연결된 진짜 물리 장치(키보드/모니터/디스크)에 명령을 전달합니다.

[JVM 프로세스]                              [운영체제 커널]
     │                                           │
     │ 1. "recipe.txt 파일 좀 열어줘"            │
     └──────────────────────────────────────────>│
                                                 │ 2. 하드디스크에서 파일 위치 탐색 및 권한 체크
                                                 │ 3. JVM의 FD 테이블에서 비어있는 가장 작은
                                                 │    번호(예: 3번)에 파일 정보 연결
     <───────────────────────────────────────────┤
     │ 4. "너의 3번 티켓에 등록해뒀어. 3 받아라."   │
     │                                           │
     │                                           │
     │ 5. "방금 받은 3번 파일에 '설탕 2스푼' 써줘" │
     └──────────────────────────────────────────>│
                                                 │ 6. JVM의 FD 테이블 3번 확인 ➔ recipe.txt 매핑
                                                 │ 7. 실제 하드디스크의 해당 구역에 데이터 기록
     <───────────────────────────────────────────┤
     │ 8. "기록 완료" 응답                        │

2.2 0, 1, 2는 예약된 자리

리눅스는 프로세스가 시작될 때 FD 0, 1, 2를 자동으로 미리 열어둠. 이것이 그토록 자주 보이는 0, 1, 2의 정체임.

FD	이름	표준 명칭	기본 연결 대상	용도
`0`	표준 입력	stdin	키보드	프로그램이 입력을 받는 통로
`1`	표준 출력	stdout	화면(터미널) 모니터 콘솔	정상 결과를 내보내는 통로
`2`	표준 에러	stderr	화면(터미널) 에러 콘솔	에러 메시지를 내보내는 통로

2.3 왜 stdout과 stderr를 나눴는가

가장 자주 나오는 질문임. 화면에 찍히는 건 똑같아 보이는데 왜 굳이 통로를 두 개로 나눴을까?

정상 결과와 에러를 따로 처리할 수 있게 하려고 나눔. 예를 들어 아래처럼 활용함.

정상 결과(1)만 파일로 저장하고, 에러(2)는 화면에 그대로 보여주고 싶을 때
반대로 에러(2)만 별도 로그 파일로 모으고 싶을 때
스크립트에서 "성공 결과"와 "실패 원인"을 다른 시스템으로 보내야 할 때

이 분리 덕분에 다음 장의 리다이렉션이 강력해짐.

3. 표준 스트림과 리다이렉션: catalina.out의 비밀

리다이렉션(Redirection)은 FD가 가리키는 대상을 바꿔치기하는 것임. 기본적으로 화면을 가리키는 1, 2를 파일 쪽으로 돌려버리는 동작임.

3.1 기본 리다이렉션 기호

기호	의미	비고
`> file`	stdout(1)을 file로 (덮어쓰기)	`1>`의 축약형
`>> file`	stdout(1)을 file로 (이어쓰기)	기존 내용 보존
`2> file`	stderr(2)를 file로	에러만 저장
`< file`	stdin(0)을 file에서 읽기	입력 리다이렉션
`2>&1`	stderr(2)를 현재 stdout(1)이 가리키는 곳으로	아래에서 상세 설명
`&> file`	stdout·stderr를 동시에 file로	bash 확장 문법

3.2 `2>&1`을 정확히 읽는 법

가장 헷갈리는 부분임. 2>&1은 "2번을, 현재 1번이 가리키는 곳과 같은 곳으로 보내라"는 뜻임. 여기서 &1은 "숫자 1인 파일"이 아니라 "FD 1"을 의미하는 표기임. (&가 없으면 1이라는 이름의 파일로 인식됨.)

순서가 결정적으로 중요함. 리다이렉션은 왼쪽에서 오른쪽으로 순차 적용되기 때문임.

# (O) 올바른 경우: 1을 먼저 file로 보내고, 그다음 2를 "1이 가리키는 곳(=file)"으로 보냄
command > file 2>&1
# 결과: stdout, stderr 모두 file로 저장됨

# (X) 흔한 실수: 2를 먼저 "1이 가리키는 곳(=화면)"으로 보내고, 그다음 1만 file로 바꿈
command 2>&1 > file
# 결과: stderr는 여전히 화면으로, stdout만 file로 감

3.3 `/dev/null`: 출력 버리기

/dev/null은 무엇을 써도 즉시 사라지는 특수 장치 파일(블랙홀)임. 불필요한 출력을 버릴 때 사용함.

command > /dev/null 2>&1   # 정상·에러 출력 모두 버림 (조용히 실행)

3.4 이제 catalina.out을 해석함

Tomcat을 실행하면 catalina.out이라는 파일이 생기고, 운영이 길어질수록 이 파일이 수 GB까지 무한히 커져서 디스크를 채우는 문제를 겪게 됨. 그 원인이 위 개념으로 완벽히 설명됨.

Tomcat의 실행 스크립트(catalina.sh)는 내부적으로 애플리케이션의 stdout(1)과 stderr(2)를 전부 catalina.out으로 리다이렉션함. 구조적으로 아래와 같음.

# catalina.sh 내부의 동작을 단순화한 형태
java org.apache.catalina.startup.Bootstrap start >> "$CATALINA_OUT" 2>&1 &

여기서 발생하는 핵심 문제:

catalina.out은 애플리케이션의 모든 stdout/stderr가 이어쓰기(>>)로 쌓이는 파일임. System.out.println, 스택 트레이스, 서드파티 라이브러리 출력이 전부 여기로 감.
그런데 catalina.out은 Tomcat이 자동으로 로테이션(잘라내기)하지 않음. Log4j/Logback으로 설정한 애플리케이션 로그는 날짜별로 잘리지만, catalina.out은 그 관리 대상 밖임.
결과적으로 파일이 무한정 커지다가 디스크를 가득 채움 → 서버 장애로 이어짐.

이는 예전에 겪은 Vector의 nohup.out 누적으로 인한 디스크 풀 장애와 정확히 같은 메커니즘임.
"stdout/stderr가 로테이션되지 않는 단일 파일로 무한히 쌓임" — 이것이 문제의 본질임.
해결책은 8장의 logrotate에서 다룸.

4. 프로세스(Process): 실행 중인 프로그램의 실체

FD가 파일 쪽 뿌리라면, 프로세스는 실행 쪽 뿌리임.

4.1 프로세스의 정의

프로세스 = 메모리에 올라가 실행 중인 프로그램의 인스턴스임. 디스크에 있는 java 실행 파일은 "프로그램"이고, 그것을 실행해서 메모리에 올라간 상태가 "프로세스"임.

모든 프로세스는 아래 정보를 가짐.

PID (Process ID): 프로세스 고유 번호
PPID (Parent PID): 자신을 실행시킨 부모 프로세스의 번호
FD 테이블: 앞서 본 0/1/2를 포함한, 이 프로세스가 연 파일 목록
소유자(UID): 어떤 사용자 권한으로 실행 중인지

4.2 프로세스는 나무처럼 이어짐 (부모-자식)

리눅스의 모든 프로세스는 부모가 자식을 낳는 트리 구조임. 최상위 조상은 부팅 시 커널이 만드는 PID 1임. (요즘 배포판에서는 이 PID 1이 바로 systemd임 — 7장 연결점.)

이 부모-자식 관계가 다음 장의 nohup, &, 그리고 시그널(signal)을 이해하는 열쇠임.

4.3 프로세스 확인 명령어

ps aux              # 전체 프로세스 목록 (소유자, CPU, 메모리 포함)
ps -ef              # 부모-자식(PPID) 관계 확인에 유용
top / htop          # 실시간 리소스 사용량 모니터링
pstree              # 프로세스 트리 구조를 시각적으로 표시
lsof -p <PID>       # 특정 프로세스가 연 파일(FD) 목록 확인

lsof -p <PID>로 catalina.out처럼 이미 삭제됐지만 프로세스가 아직 붙잡고 있어 디스크가 안 비는(deleted 표시) 파일을 찾아낼 수 있음. 디스크 풀 트러블슈팅의 필수 도구임.

4.4 시그널(Signal): 프로세스에게 보내는 신호

프로세스를 제어할 때 커널을 통해 시그널을 보냄. kill 명령어는 "죽이는 것"이 아니라 "시그널을 전달하는 것"임.

시그널	번호	의미	특징
`SIGTERM`	15	정상 종료 요청	프로세스가 뒷정리 후 종료 (기본값)
`SIGKILL`	9	강제 종료	무시 불가, 뒷정리 없이 즉시 죽음 (최후의 수단)
`SIGHUP`	1	터미널 연결 끊김	다음 장의 핵심
`SIGINT`	2	인터럽트	`Ctrl + C`가 보내는 시그널

kill <PID>        # 기본 SIGTERM (정상 종료) — 먼저 시도할 것
kill -9 <PID>     # SIGKILL (강제 종료) — 정말 안 죽을 때만

⚠️ 운영에서 무조건 kill -9부터 쓰는 습관은 위험함. SIGKILL은 프로세스가 진행 중이던 트랜잭션이나 파일 쓰기를 마무리할 기회를 주지 않아 데이터 손상을 유발할 수 있음. SIGTERM → 안 되면 SIGKILL 순서를 지킬 것.

5. 데몬과 백그라운드 실행: nohup, &, 그리고 그 한계

5.1 데몬(Daemon)이란

데몬 = 사용자와 직접 상호작용하지 않고 백그라운드에서 계속 도는 서비스 프로세스임. 웹 서버(nginx), DB, sshd 등이 데몬임. 관례적으로 이름 끝에 d가 붙음(systemd, sshd, httpd).

5.2 `&`와 nohup: 초보가 서비스를 띄우는 방식

터미널에서 프로그램을 백그라운드로 띄우는 가장 원시적인 방법임.

./start.sh &            # & : 백그라운드로 실행 (터미널을 다시 쓸 수 있음)
nohup ./start.sh &      # nohup : 터미널이 끊겨도 계속 실행되게 함

여기서 4.4의 SIGHUP이 등장함. 터미널(SSH 세션)을 닫으면, 그 세션에 속한 자식 프로세스들에게 SIGHUP(연결 끊김) 시그널이 전달되어 함께 죽음. nohup은 이 SIGHUP을 무시(no hang up)하도록 만들어서 세션이 끊겨도 프로세스가 살아남게 함.

5.3 nohup.out은 왜 생기는가 (그리고 왜 위험한가)

nohup으로 실행하면, 터미널(화면)로 향하던 stdout/stderr가 갈 곳을 잃음. 그래서 nohup은 출력을 nohup.out이라는 파일로 자동 리다이렉션함. 즉 아래와 사실상 동일함.

nohup ./start.sh > nohup.out 2>&1 &

이제 문제가 보임. nohup.out도 catalina.out과 똑같이 로테이션되지 않는 단일 파일에 무한히 쌓이는 구조임. 이것이 예전에 겪은 Vector 프로세스의 nohup.out 누적 → 디스크 풀 장애의 근본 원인임.

5.4 nohup/& 방식의 근본적 한계

nohup & 방식은 급할 때 임시로 쓰기엔 편하지만, 운영 서비스를 이 방식으로 띄우면 안 됨. 이유는 다음과 같음.

자동 재시작 안 됨: 프로세스가 죽으면 그대로 끝임. 누군가 수동으로 다시 띄워야 함.
부팅 시 자동 실행 안 됨: 서버가 재부팅되면 서비스가 안 올라옴.
로그 관리 안 됨: nohup.out이 무한히 커짐.
상태 관리 불가: 표준화된 시작/중지/상태 확인 방법이 없음.

이 모든 한계를 해결하기 위해 등장한 것이 바로 systemd임.

6. systemd: 현대 리눅스의 서비스 관리자

6.1 systemd의 위치

systemd는 부팅 직후 커널이 가장 먼저 실행하는 PID 1 프로세스이며, 시스템의 모든 서비스를 관리하는 최상위 관리자임. 앞서 본 nohup &의 모든 한계(재시작, 부팅 실행, 로그, 상태 관리)를 표준화된 방식으로 해결함.

6.2 유닛 파일(Unit File): 서비스의 설계도

systemd는 각 서비스를 유닛 파일(.service)로 정의함. 이 파일 하나에 "어떻게 실행하고, 죽으면 어떻게 할지"를 전부 선언함. nohup &을 여러 줄로 흩어놓던 것을 하나의 명세로 대체하는 개념임.

# /etc/systemd/system/myapp.service
[Unit]
Description=My Application
After=network.target          # 네트워크가 준비된 후 실행

[Service]
User=appuser                  # 실행할 사용자 (권한 관리)
ExecStart=/opt/app/start.sh   # 실행 명령
Restart=on-failure            # 비정상 종료 시 자동 재시작 ★
RestartSec=5                  # 5초 후 재시작
StandardOutput=journal        # stdout을 journald로 (★ nohup.out 문제 해결)
StandardError=journal         # stderr을 journald로

[Install]
WantedBy=multi-user.target    # 부팅 시 자동 시작 대상에 포함

여기서 StandardOutput=journal이 중요함. nohup.out/catalina.out처럼 파일로 무한히 쌓는 대신, systemd의 로깅 시스템(journald)이 출력을 받아 자동으로 용량 관리해줌.

6.3 systemctl: 서비스 제어 명령어

systemctl start myapp        # 시작
systemctl stop myapp         # 중지 (내부적으로 SIGTERM 전달)
systemctl restart myapp      # 재시작
systemctl status myapp       # 현재 상태·최근 로그 확인 (가장 자주 씀)
systemctl enable myapp       # 부팅 시 자동 시작 등록
systemctl daemon-reload      # 유닛 파일 수정 후 반드시 실행 (설정 재적용)

6.4 journalctl: systemd의 로그 조회

systemd로 띄운 서비스의 로그는 journalctl로 조회함. catalina.out을 tail로 뒤지던 것을 대체하는, 훨씬 강력한 방식임.

journalctl -u myapp             # 특정 서비스의 로그 전체
journalctl -u myapp -f          # 실시간 로그 추적 (tail -f 와 유사)
journalctl -u myapp --since "1 hour ago"   # 시간 필터
journalctl -u myapp -p err      # 에러 레벨만 필터

정리: nohup ./app & → catalina.out을 tail -f로 보던 방식에서, systemctl start app → journalctl -u app -f로 보는 방식으로 넘어가는 것이 주니어에서 인프라 엔지니어로 가는 핵심 전환점임.

7. 로그와 디스크: 왜 서버가 꽉 차는가 (logrotate)

3장·5장에서 본 catalina.out/nohup.out 무한 증식 문제의 정석 해결책이 logrotate임.

7.1 logrotate란

logrotate = 로그 파일을 주기적으로 잘라내고(rotate), 오래된 것은 압축·삭제하는 도구임. 대부분의 리눅스에 기본 설치되어 있고, 매일 cron으로 자동 실행됨.

"로테이션"의 동작은 다음과 같음.

graph LR
    A["app.log (현재)"] -->|"매일 자정"| B["app.log.1"]
    B --> C["app.log.2.gz (압축)"]
    C --> D["app.log.3.gz"]
    D --> E["30일 지나면 삭제"]

7.2 catalina.out을 위한 설정 예시

# /etc/logrotate.d/tomcat
/opt/tomcat/logs/catalina.out {
    daily                 # 매일 로테이션
    rotate 14             # 14개(14일치)까지 보관
    compress              # 오래된 로그는 gzip 압축
    missingok             # 파일 없어도 에러 안 냄
    notifempty            # 비어 있으면 로테이션 안 함
    copytruncate          # ★ 아래 설명 참조
}

7.3 `copytruncate`가 중요한 이유

catalina.out처럼 프로세스가 파일을 계속 붙잡고 쓰고 있는 경우 특별한 주의가 필요함.

일반적인 로테이션은 파일 이름을 바꿈(mv). 그런데 4장에서 봤듯 프로세스는 파일 이름이 아니라 FD(번호표)로 파일을 붙잡고 있음. 이름을 바꿔도 프로세스는 여전히 같은 FD로 옛 파일에 계속 씀 → 새 catalina.out은 안 생기고 디스크는 계속 참.

copytruncate는 이를 우회함. 원본을 복사한 뒤, 원본 파일의 내용만 0으로 비움(truncate). 프로세스가 붙잡은 FD는 그대로 유지되므로, 프로세스는 눈치채지 못하고 비워진 파일에 계속 씀. 이것이 재시작 없이 catalina.out을 안전하게 관리하는 핵심 옵션임.

더 나은 해결책: 애초에 catalina.out에 stdout/stderr를 몰아넣지 않고, 애플리케이션 로그를 Logback/Log4j2로 파일 롤링 정책과 함께 설정하는 것임. catalina.out은 최소한의 부트 로그만 남게 하고, 나머지는 로깅 프레임워크가 관리하도록 분리하는 것이 정석임.

8. 권한과 소유권: 운영의 기본 안전장치

인프라 운영에서 "Permission denied"는 매일 마주치는 문제임. 권한 모델을 정확히 알아야 함.

8.1 소유권과 권한 3분할

모든 파일은 소유자(User) / 그룹(Group) / 그 외(Others) 세 주체에 대해 각각 읽기(r) / 쓰기(w) / 실행(x) 권한을 가짐.

-rwxr-xr--   1  appuser  devops  4096  Jul 12 10:00  start.sh
 │└┬┘└┬┘└┬┘     └──┬──┘  └─┬─┘
 │ │  │  │        소유자   그룹
 │ │  │  └─ others: r--  (읽기만)
 │ │  └──── group:   r-x  (읽기·실행)
 │ └─────── user:    rwx  (읽기·쓰기·실행)
 └───────── 파일 타입 (- 일반파일, d 디렉터리, l 링크)

8.2 숫자(8진수) 표기

권한은 r=4, w=2, x=1의 합으로 숫자화함.

숫자	권한	의미
`7`	`rwx`	읽기+쓰기+실행 (4+2+1)
`6`	`rw-`	읽기+쓰기 (4+2)
`5`	`r-x`	읽기+실행 (4+1)
`755`	`rwxr-xr-x`	소유자 전체, 그룹·기타는 읽기·실행 (실행 파일 표준)
`644`	`rw-r--r--`	소유자 읽기·쓰기, 나머지 읽기만 (설정·문서 표준)

chmod 755 start.sh        # 권한 변경
chown appuser:devops file # 소유자·그룹 변경

⚠️ 운영에서 chmod 777(모두에게 전체 권한)을 남발하는 것은 심각한 보안 위험임. "권한 문제 같으니 일단 777" 습관은 반드시 버려야 함. 필요한 최소 권한만 부여하는 것이 원칙(최소 권한 원칙)임.

9. 셸과 환경: 명령어가 실행되는 맥락

9.1 셸(Shell)이란

셸은 사용자의 명령을 받아 커널에 전달하는 해석기임. bash, zsh 등이 있음. 우리가 터미널에 치는 모든 명령어는 셸이 해석해서 프로세스로 실행함.

9.2 환경 변수(Environment Variable)

프로세스가 실행될 때 참조하는 설정값들임. 4장에서 본 것처럼 자식 프로세스는 부모의 환경 변수를 물려받음.

echo $PATH              # 명령어를 찾는 디렉터리 목록
echo $JAVA_HOME         # 자바 설치 경로
export APP_ENV=prod     # 환경 변수 설정 (자식 프로세스에 상속됨)
env                     # 현재 모든 환경 변수 출력

PATH는 특히 중요함. java라고만 쳐도 실행되는 이유는 셸이 $PATH에 나열된 디렉터리들을 순서대로 뒤져 java 실행 파일을 찾기 때문임. "command not found"는 대부분 PATH 문제임.

9.3 파이프(`|`)와 명령어 조합

파이프는 한 명령어의 stdout(1)을 다음 명령어의 stdin(0)으로 연결하는 것임. 2장의 FD 개념이 여기서도 그대로 쓰임.

# tomcat 프로세스의 PID만 뽑아내는 조합
ps -ef | grep tomcat | grep -v grep | awk '{print $2}'

9.4 실무에서 자주 쓰는 필수 명령어

목적	명령어
디스크 사용량 확인	`df -h` (파티션별), `du -sh *` (디렉터리별)
큰 파일 찾기	`find / -type f -size +1G`
메모리 확인	`free -h`
포트·연결 확인	`ss -tnlp` (구 `netstat`)
로그 실시간 추적	`tail -f app.log`
텍스트 검색	`grep -r "keyword" /path`
네트워크 응답 확인	`curl -I https://...`

EC2 리눅스 OS 서버 데이터 저장 구조

김구황 — Sun, 12 Jul 2026 20:15:12 +0900

EC2 리눅스 OS 마이그레이션 작업 진행 중 발생한 의문점 정리. "EBS 스냅샷 생성 후 EBS·ENI를 신규 OS의 EC2로 옮긴다"는 방식이 회의에서 언급되었으나, 정작 서버 내부에 쌓이는 로그·설정·데이터가 물리적으로 어디에 저장되고 있는지에 대한 개념 혼재 상태 발견.

1. RAM vs EBS vs EFS — 역할 구분

가장 먼저 명확히 할 부분은 "로그나 설정이 RAM에 저장된다"는 흔한 오해. RAM은 프로세스 실행 중 사용하는 휘발성 작업 공간이며, 재부팅 시 전체 소멸 대상. 반면 재부팅 후에도 남아있어야 하는 모든 데이터는 디스크, 즉 EBS에 저장.

구분	저장 위치	휘발성	공유 가능 여부	대표 데이터
메모리	RAM	휘발성 (재부팅 시 소멸)	불가	실행 중 프로세스, 캐시
인스턴스 전용 디스크	EBS	영속 (단, 인스턴스 종료 정책에 종속)	원칙적으로 단일 인스턴스 전용	OS, 설정, crontab, 개별 서버 로그, `/home`
네트워크 공유 스토리지	EFS	영속 (인스턴스 생명주기와 무관)	다수 인스턴스 동시 마운트 가능	여러 서버가 공유하는 데이터 (예: wlog)

EBS가 "인스턴스 하나에만 붙는 디스크"라는 성격을 갖는 반면, EFS는 NFS 기반이라 애초에 "공유"를 전제로 설계된 서비스라는 점이 핵심 차이.

2. 리눅스 디렉토리별 저장 데이터

리눅스 표준(FHS, Filesystem Hierarchy Standard)에 따른 디렉토리별 용도는 아래와 같음.

디렉토리	표준 용도
`/root`	root 계정 전용 홈. 개인 설정·작업 파일
`/home/{user}`	일반 유저 홈. dotfile, SSH key, 개인 작업 공간
`/etc`	시스템 및 애플리케이션 설정 파일
`/var`	계속 변화하는 데이터 — `/var/log`(로그), `/var/spool`(큐/스풀), `/var/run` 등
`/opt`	서드파티/자체 패키징 애플리케이션 설치 위치 (원칙상 Spring Boot 배포 경로에 해당)
`/usr`	배포판이 관리하는 시스템 전역 프로그램·라이브러리
`/tmp`	임시 파일. 재부팅 시 소멸 가능

참고로 crontab은 실제로는 /var/spool/cron/crontabs/{user} (Debian 계열) 혹은 /var/spool/cron/{user} (RHEL 계열)에 저장. crontab -e로 편집하는 구조이며, 홈 디렉토리에 crontab 관련 파일이 존재한다면 crontab -l > backup.txt 형태의 수동 백업 사본일 가능성 높음.

회사 자체 컨벤션 디렉토리

/cont 같은 디렉토리는 FHS 표준이 아닌 조직 자체 관례. 한국 엔터프라이즈 환경, 특히 WAS 기반 레거시 시스템에서는 /app, /was, /data1, /cont 처럼 자체 네이밍으로 배포 경로를 구성하는 경우 다수. 표준은 아니지만 조직의 오래된 관례이며, Jenkins 파이프라인·배포 스크립트가 이미 해당 경로를 기준으로 구성되어 유지되는 구조.

3. 데이터 3분류 — 설정 / 순수 데이터 / CI 산출물

서버에 존재하는 모든 파일이 같은 성격을 갖는 것은 아님. 마이그레이션 관점에서는 아래 3가지로 구분 필요.

분류	판단 기준	예시	마이그레이션 시 처리
설정 (Config)	언제든 플레이북 재실행으로 동일하게 재생성 가능 (idempotent)	패키지 설치, 유저/그룹, cron 엔트리, 설정파일 템플릿, `fstab` 엔트리, 디렉토리 권한	Ansible이 새 인스턴스에 선언·적용
CI 산출물 (Artifact)	빌드 파이프라인이 매번 새로 생성	Spring Boot 배포 zip/jar, war	별도 이전 불필요 — Jenkins 재배포로 해결. 단 롤백용 과거 버전 이력은 순수 데이터로 취급
순수 데이터 (Data)	서버가 살아온 이력이 있어야만 존재. 재생성 불가능	실제 로그 파일 내용, DB 데이터, 업로드된 문서/이미지, 축적된 캐시	EBS 볼륨 detach/attach로 물리 이전

crontab이 Ansible에 아직 관리되지 않는 상태라면, 이는 "관례상 제외"가 아니라 수동으로 추가된 뒤 IaC에 반영되지 못한 기술 부채일 가능성 높음. 마이그레이션은 이런 누락분을 코드화할 좋은 계기.

4. OS 마이그레이션 워크플로우

EBS·ENI를 detach 후 새 OS의 EC2에 재연결하는 방식의 실제 순서는 아래와 같음. 핵심은 Ansible이 먼저 "빈 그릇"(마운트 포인트, fstab, 설정)을 준비한 뒤, EBS가 그 그릇에 "내용물"을 채우는 구조라는 점.

주황색 단계: AWS 인프라 레이어 작업 (콘솔·CLI·Terraform)
파란색 단계: Ansible 레이어 작업
회색 단계: 검증 단계

EBS·ENI attach/detach는 AWS API 레벨 작업으로, Ansible이 다루는 "OS 내부 설정"과는 레이어가 다름. amazon.aws.ec2_vol 모듈로 Ansible이 직접 처리하는 것도 가능하나, 컷오버 시점의 민감한 작업이라 별도 스텝(수동 또는 Terraform/CLI)으로 분리하는 경우 다수.

ENI 이전 시점은 EBS와 반드시 같을 필요 없음. Ansible이 SSH로 프로비저닝하는 동안은 임시 IP·보안그룹 사용, 최종 컷오버 직전 ENI를 옮겨 기존 프라이빗 IP·보안그룹 그대로 유지하는 방식 일반적. EFS는 네트워크 마운트 방식이라 인스턴스에 종속되지 않으므로, 신규 인스턴스에서 마운트 설정만 다시 하면 기존 공유 데이터 그대로 접근 가능.

5. Auto Scaling 환경에서의 EBS·EFS

단일 서버(pet) 마이그레이션과 달리, Auto Scaling Group(ASG) 환경은 인스턴스를 "언제든 대체 가능한 자원(cattle)"으로 취급. 이 전제에서 EBS의 동작 방식이 완전히 달라짐.

스케일아웃: Launch Template의 AMI 기준으로 신규 EBS 매번 새로 생성. 기존 볼륨 재사용 없음. Ansible(또는 user-data/cloud-init)이 부팅 시점에 재프로비저닝.
스케일인: 인스턴스 종료 시 DeleteOnTermination 옵션에 따라 EBS도 함께 삭제 (root 볼륨은 기본값 true인 경우 다수). 로컬에만 있던 로그·캐시는 이 시점에 유실.

항목	ASG 환경	단일 서버(pet) 환경
EBS 취급	휘발성 스크래치 공간으로 간주	보존 대상 (detach/attach로 이전)
영속 데이터 위치	EFS, S3, 관리형 DB	EBS 자체
로그 처리	실시간으로 중앙 저장소(ELK, CloudWatch Logs 등)로 전송	로컬 보존 후 필요 시 이전
인스턴스 정체성	대체 가능 (cattle)	고유 정체성 유지 (pet)

결론적으로 여러 서버가 공유해야 하거나 인스턴스 생명주기와 무관하게 남아야 하는 데이터는 EFS·S3·DB 같은 외부 스토리지 사용 원칙. EBS는 인스턴스의 "몸", EFS는 인스턴스가 죽어도 남는 "기억"에 해당.

6. 전체 정리표

디렉토리/데이터	성격	저장 위치	관리 주체	마이그레이션 시
OS, 패키지, `/etc` 설정	설정	EBS (root)	Ansible (선언)	새 인스턴스에서 재생성
crontab	설정 (단, 미관리 시 기술 부채)	EBS (root, `/var/spool/cron`)	Ansible (권장)	Ansible로 흡수 또는 수동 확인
`/home` 내 dotfile, SSH key	설정	EBS (root)	Ansible	새 인스턴스에서 재생성
`/home` 내 개인 작업 스크립트·캐시	순수 데이터	EBS (root 또는 데이터 볼륨)	없음 (비관리 영역)	필요 시에만 수동 이전
`/var/log`, 애플리케이션 로그	순수 데이터	EBS (데이터 볼륨)	없음	EBS 물리 이전 대상
`/cont` 내 최신 배포 zip/jar	CI 산출물	EBS (데이터 볼륨)	Jenkins	이전 불필요, 재배포로 해결
`/cont` 내 과거 릴리즈 이력	순수 데이터	EBS (데이터 볼륨)	없음	롤백 필요 시 EBS 물리 이전
wlog 등 서버 간 공유 데이터	순수 데이터 (공유형)	EFS	없음	재마운트만 하면 접근 가능
실행 중 프로세스, 캐시	휘발성	RAM	없음	이전 대상 아님

프록시·NAT·네트워크 계층 기초 정리

김구황 — Fri, 3 Jul 2026 22:10:11 +0900

1. 문제 상황

운영 환경: 상담 솔루션을 도메인(예: sangdam.com)으로 호출 → 정상 동작.
STG 환경: 설정값에 도메인 대신 솔루션 서버의 IP(예: 13.x)가 박혀 있음. 이 IP로 직접 접속 시 상담 화면이 안 뜸.
STG는 테스트용 WiFi를 거치며, 이 WiFi에는 프록시가 걸려 있음. 문제의 출발점

"패킷이 어디를 어떻게 지나서 왜 막혔는지"

2. 개념 1 : 네트워크는 "봉투 여러 겹"

패킷

패킷은 레이어. 각각의 장비가 장비별로 다른 정보들을 파악

인터넷으로 오가는 데이터 한 덩어리로 실제 내용물을 여러 겹 봉투로 싼 형태.
안쪽일수록 실제 내용, 바깥쪽일수록 배달용 정보.

계층이름	담는 정보	편지	장비
L7	HTTP	실제 요청 내용 (GET, 주소, 본문)	어플리케이션
L4	TCP	포트 번호 (:8888, :17777)	OS 커널
L3	IP	출발지·도착지 IP 주소	라우터 / OS 커널
L2	이더넷	MAC 주소	스위치 / NIC

바깥 봉투일수록 아래 계층(L2), 안쪽 알맹이일수록 위 계층(L7)
장비마다 봉투를 어디까지 뜯어보는지가 다름.

3. 개념 2 : 서버 안에서 벌어지는 일 (NIC·커널·앱)

받을 때(해체, 아래→위)

NIC가 L2 프레임을 받아 "이 MAC이 내 것인가?" 확인 → 맞으면 L2 봉투를 벗기고 L3로 올림.
→ 커널 IP가 "이 도착지 IP가 내 것인가?" 확인 → 맞으면 L3 벗기고 L4로.
→ 커널 TCP가 포트를 보고 "이 포트(:17777)를 듣고 있는 프로세스가 누구지?" → 해당 소켓으로 L4를 벗긴 바이트 스트림을 전달.
→ 그 바이트를 최종적으로 받는 건 그 포트를 listen 중인 애플리케이션 프로세스. 여기서 앱이 바이트를 HTTP 문법으로 파싱해 GET·URL·헤더를 읽는다(L7).

보낼 때(포장, 위→아래):

앱이 HTTP 텍스트를 만든다(L7)
→ OS 커널의 TCP가 앞에 포트 헤더를 붙인다(L4)
→ IP가 출발지/도착지 IP 헤더를 붙인다(L3)
→ NIC/드라이버가 MAC 프레임으로 감싼다(L2)
→ 전기·전파 신호로 나간다.

[개념정리]

NIC (네트워크 카드/랜카드)
- NIC = Network Interface Card, 랜카드/네트워크 카드
- 기계를 네트워크에 물리적으로 연결하는 하드웨어 하는 일은 두 방향 변환.
- 밖에서 오는 전기·광·전파 신호 ↔ 0/1 비트, 그리고 비트 ↔ L2 프레임. 즉 서버로 들어오는 모든 패킷이 통과하는 물리적 정문이고, 봉투를 벗기는 첫 단계
커널 (L2 → L3 → L4)
- 운영체제의 핵심부.
- 네트워크 카드·CPU·메모리 같은 하드웨어를 직접 다루고, 모든 프로그램이 공통으로 쓰는 기능(네트워크 송수신, 파일 읽기)을 대신 처리하는 부분
- "내 MAC인가 → 내 IP인가 → 어느 포트의 소켓인가"를 차례로 확인하며 겉봉투를 벗김. 모든 프로그램이 공통으로 쓰는 부분.
애플리케이션 (L7)
- 우리가 실행하는 개별 프로그램. 상담 서비스 프로세스, 웹서버, 브라우저 등. HTTP 내용(L7)을 실제로 이해하고 처리하는 주체.
- 커널이 넘겨준 알맹이 바이트를 HTTP로 해석해 GET /chat 같은 내용을 읽음.

4. 개념 3 : NAT와 프록시

NAT (주소 바꿔치기)

집·회사의 여러 기기가 인터넷에 나갈 때 공인 IP 하나를 공유하게 만드는 기술.

밖으로 나가는 패킷의 출발지 사설 IP를 공인 IP로 바꿔치기하는 것이 SNAT.
이 작업은 사설망과 인터넷의 경계에 있는 라우터/게이트웨이(집 공유기, 회사 방화벽, 클라우드의 NAT Gateway 등)가 진행함

[참고 개념]

라우터
- " 네트워크 장비 " but 내부에 CPU, 메모리, 운영체제(OS)를 갖춘 일종의 소형 컴퓨터(네트워크장비).
- '경로 설정'에 초점. 데이터 패킷 포워딩 및 라우팅 (OSI 3계층 작동)
게이트웨이
- '다른 네트워크로 나아가는 관문'과 '프로토콜 번역'에 초점
- 프로토콜 변환 및 다른 네트워크로의 통로 제공 (OSI 5계층 이상 작동)

프록시 (심부름꾼)

내가 목적지에 직접 가지 않고, 대신 심부름꾼(프록시)에게 "이 주소로 대신 다녀와줘"라고 맡기는 방식.

프록시는 요청을 받아 자기 이름으로 목적지에 다시 접속함.
그래서 목적지 서버가 보는 접속자는 나(원래 단말)가 아니라 프록시임.
WiFi 프록시 설정 = "인터넷 요청을 목적지로 직접 보내지 말고 프록시로 보내라"고 단말에 알려주는 것임.

5. 개념 4 : HTTP vs HTTPS — 프록시가 내용을 보느냐

HTTP:
- 요청 문장(GET http://13.x:17777/...)이 프록시에 그대로 보임.
- 프록시가 내용을 읽고 주소 형식을 고쳐 서버로 전달함.
HTTPS:
- 단말이 프록시에 "터널만 뚫어줘(CONNECT 13.x:17777)"라고 요청함.
- 프록시는 통로만 열고, 이후 내용은 암호화됨. 프록시는 목적지만 알고 내용은 못 봄.

이 차이 때문에 "IP로만 접속"할 때 HTTPS면 인증서가 도메인 기준이라 IP와 안 맞아 실패하는 경우도 생김.

6. 문제 상황 : 패킷의 여정

① 테스터가 요청 생성 목적지를 프록시:8888로 지정.

진짜 목적지인 서버(13.x:17777)는 IP 칸이 아니라 요청 내용(L7) 안에 문자열(7번)로 들어감.
출발지 IP·포트는 단말이 정하는 게 아니라 OS가 자동으로 채움
- 출발지 IP: 그 단말이 그 네트워크에서 가진 주소(10.0.0.5). 나중에 게이트웨이가 SNAT로 32.x로 바꿈.
- 출발지 포트(임의 포트): OS가 매 연결마다 안 쓰는 번호 하나를 자동으로 뽑는다(보통 49152~65535, ephemeral port). 목적지 포트(8888)는 고정이지만 출발지 포트는 자동인 이유는, 응답이 돌아왔을 때 "이 응답이 내 어느 연결/탭 것인지"를 이 번호로 구분하기 때문

② 게이트웨이가 SNAT 밖으로 내보내며 출발지를 10.0.0.5 → 32.x로 바꿈.

이 시점 패킷: 출발지 32.x → 도착지 42.x(프록시), 도착 포트 :8888.
L4 도착지가 42.x로 바뀌는 건 아님.
- IP(42.x)는 L3, 포트(8888)는 L4임
- L4 칸엔 포트만 들어가고 IP는 안 들어감. 둘을 합쳐서 하나의 목적지 42.x:8888이 되는 것

③ 프록시가 대신 접속 프록시가 요청 내용을 읽어 목적지 13.x:17777을 뽑아냄.

그리고 프록시의 공인 IP (52.x)으로 서버에 새 연결을 만듦.
이 시점 패킷: 출발지 52.x → 도착지 13.x, 도착 포트 :17777.

④ 서버가 수신 서버 입장에서 접속 출처는 52.x (프록시의 공인 IP)

7. 왜 진짜 목적지가 "내용" 안에 들어가나

프록시를 쓰면

패킷의 목적지 칸에는 항상 프록시가 적히며,
진짜 목적지(13.x:17777)는 IP 칸이 아니라 HTTP 요청 문장 안에 들어감.
프록시는 이 문장을 직접 읽어서 목적지를 알아냄.

GET http://13.x:17777/chat HTTP/1.1

프록시(어플리케이션) 가 그 연결의 종단(끝점) 이기 때문에 봉투를 L7까지 다 뜯어 HTTP 문장으로 해석
반대로 중간의 라우터는 L3(IP)까지만, 방화벽은 L4(IP+포트)까지만 봄.
그래서 이들은 요청 안의 URL을 알 수 없음. 연결의 끝점인 애플리케이션(프록시·서버)만 L7을 읽음.

9. 원인과 해결

서버가 보는 접속 출처 = 프록시 42.x. (테스터도 32.x도 아님.)
따라서 서버 방화벽(보안그룹)에 42.x의 17777 포트 허용이 필요함. 이걸 열지 않으면 접속이 막힘.
추가 점검 항목:
- 프록시가 17777 같은 비표준 포트로의 연결을 허용하는지(프록시 자체가 막으면 서버 방화벽과 무관하게 실패함).
- HTTPS라면 서버 인증서가 도메인 기준이라 IP 직접 접속 시 검증 실패로 화면이 안 뜨는지.
확정 방법: 서버 접속 로그에서 실제 출처가 42.x로 찍히는지 먼저 확인. 안 찍히면 프록시 단계에서 막힌 것이므로 방화벽이 아니라 프록시를 점검해야 함.

카프카 컨슈밍 규칙

김구황 — Thu, 2 Jul 2026 07:15:49 +0900

1. 왜 특정 STG 에서만 데이터를 처리하는가.

그룹 개수: 그룹 ID를 stage 단위로 잡는다면(group.id = stg1-group, stg2-group...) 그룹은 4개. 각 그룹 안에 그 stage의 API 서버 4대가 멤버

각 서버는 애초에 자기한테 할당된 파티션의 메시지만 받게 됨

2. Offset의 의미

offset은 "파티션 안에서 메시지 하나하나에 매겨진 순번"

"커밋된 위치"와 "실제로 처리를 끝낸 위치"가 어긋날 때 생기는 문제

1) 커밋이 처리(DB) 보다 앞서 있으면 → 유실 (건너뜀)

컨슈머가 offset 51~100번 메시지를 poll해서 메모리에 가져옴
auto-commit 타이머가 돌아서 "100까지 다 처리했다"고 카프카에 먼저 커밋해버림
근데 실제로는 51~60번 정도까지만 DB 반영(가격 처리)하다가 서버가 죽음
재시작하면 카프카는 "너 100까지 커밋했잖아" 하고 101번부터 줘버림
61~100번 사이 가격 변경 이벤트는 영원히 그 컨슈머 인생에서 다시 안 보임 → 데이터 유실

2) 처리(DB) 가 커밋보다 앞서 있으면 → 중복 (다시 처리) — 리밸런싱/재시작 시 흔한 케이스

컨슈머 A가 51~60번 메시지를 이미 DB에 반영(가격 UPDATE)
아직 auto-commit 주기가 안 돌아서 커밋은 50에 머물러 있는 상태
리밸런싱(배포, 재시작, 스케일 조정 등)이 발생하면, 파티션이 컨슈머 B로 넘어감
B는 카프카에 기록된 "커밋된 offset 50"부터 다시 읽음
51~60번은 이미 DB에 반영된 이벤트를 한 번 더 처리하게 되는데, 이때 DB가 "어? 이미 처리된 상태인데?" 하면서 에러

Jenkins 구조와 원리 정리

김구황 — Wed, 1 Jul 2026 23:40:05 +0900

1. Jenkins가 하는 일

한 줄로 요약하면: "특정 조건(버튼 클릭, 코드 push 등)이 되면, 미리 정해둔 작업(빌드/테스트/배포)을 순서대로 실행해주는 자동화 서버".

Controller (Jenkins 서버 본체): UI 제공, Job 설정 저장, 실행 스케줄링을 담당하는 Java 프로세스
Job (=Project): "무엇을 어떻게 실행할지"에 대한 정의 단위. 화면에서 하나씩 만드는 그 대상
Build: Job을 한 번 실행한 결과물. Job이 "레시피"라면 Build는 "그 레시피로 만든 요리 한 접시" (빌드로그)

2. Jenkins 서버 구조 — JENKINS_HOME

Jenkins(war 파일 or 패키지)를 설치하고 실행하면, Java 프로세스 하나가 뜨면서 기본적으로 JENKINS_HOME 디렉토리(보통 /var/lib/jenkins 또는 지정 경로)를 생성/사용. Jenkins의 모든 상태(Job 설정, 빌드 이력, 플러그인)가 여기 저장됨.

경로 내용	생성	시점
jobs/<job명>/config.xml	Job 설정 원본	Job 화면에서 Save 누를 때
jobs/<job명>/builds/<번호>/	빌드 로그, 결과	빌드 실행 완료 후
workspace/<job명>/	실제 소스코드 (Git clone 결과)	빌드 실행할 때마다 갱신
plugins/	설치된 플러그인	플러그인 설치 시

jobs/ 밑에 있는 것과 workspace/ 밑에 있는 것은 성격이 다름.

jobs/config.xml → 설정 (Git URL, credential, 파라미터 등). Jenkins가 원본을 직접 소유
workspace/ → 결과물 (Git 리포지토리를 그대로 받아온 사본). 매 빌드마다 새로 갱신되므로 "원본"이 아님

참고 : https://sweetjhpotato.tistory.com/556 빌드실행 완료 후에 빌드 로그와 서버 실행 로그는 다름

3. Job 실행 흐름 — 저장 시점과 실행 시점은 다르다

Job 생성 (1회성): 웹 화면에서 설정 입력 → Save 클릭 → config.xml 즉시 저장. 아직 빌드는 한 번도 안 돌아간 상태
Build 버튼 클릭 (매번 반복): config.xml을 읽어서 이 Job이 뭘 해야 하는지 파악
Git clone/pull: 설정에 지정된 리포지토리를 workspace/로 받아옴
Jenkinsfile 파싱 & 실행: workspace 안의 Jenkinsfile을 읽어서 그 안의 stage들을 순서대로 실행
로그 기록: 실행 결과와 콘솔 출력을 builds/<번호>/에 저장

즉 ①은 한 번, ②~⑤는 빌드할 때마다 처음부터 반복되는 구조. 매 빌드가 "새로 클론 → 새로 실행"에 가까움.

4. Pipeline 정의 방식 — 화면에 스크립트가 보이는 것과 안 보이는 것의 차이

Job 설정 화면에 파라미터 + node, stage 코드가 그대로 입력되어 있는 경우
Job 설정 화면엔 Git URL, credential, 브랜치, 실행 파일 경로만 있고 실제 코드는 안 보이는 경우

방식 1. Pipeline script (Directly)

스크립트 원문을 Job 설정 화면에 직접 작성
config.xml 안에 스크립트 텍스트가 그대로 저장됨
Git 리포지토리와 무관, 원본 소유자는 Jenkins 자신
화면에서 스크립트를 고치면 = 코드를 고치는 것과 동일함

방식 2. Pipeline script from SCM

Job 설정 화면엔 "어디서 가져올지"에 대한 정보(Git URL, credential, branch, script path)만 지정
실제 stage 로직은 리포지토리 안의 Jenkinsfile에 있음
빌드할 때마다 그 리포지토리를 clone해서 Jenkinsfile을 읽어 실행
원본 소유자는 Git 리포지토리. Jenkins는 실행기 역할만 함
화면을 고쳐도 stage 로직에는 영향 없음 (애초에 화면에 로직 자체가 없음). 반대로 리포지토리의 Jenkinsfile을 고치면 다음 빌드부터 바로 반영됨

예외 하나: Jenkinsfile에 parameters { ... }를 정의해두면, 빌드 1회 후 Job 설정 화면에 "Build with Parameters" 입력 폼이 자동으로 생김. 코드 → 화면으로 반영되는 유일한 케이스. 다만 화면에서 그 파라미터 기본값을 바꿔도 다음 빌드 때 Jenkinsfile 쪽 정의로 다시 덮어써짐.

5. Jenkinsfile이란

Pipeline 정의를 담는 텍스트 파일. Groovy 문법 기반 DSL로 작성.

// Scripted Pipeline — 자유도 높음, 코드처럼 작성
node {
    stage('Build') {
        sh 'mvn clean package'
    }
    stage('Deploy') {
        sh './deploy.sh'
    }
}

// Declarative Pipeline — 구조 정형화, 최근 표준
pipeline {
    agent any
    stages {
        stage('Build') {
            steps { sh 'mvn clean package' }
        }
        stage('Deploy') {
            steps { sh './deploy.sh' }
        }
    }
}

파일명은 관례일 뿐 강제 아님. Job 설정에서 Script Path를 다르게 지정하면 다른 이름도 가능. 보통 리포지토리 루트에 Jenkinsfile이라는 이름으로 둠.

6. 실습 순서 — Job 하나 만들어서 실행까지

Jenkins 접속 → 새로운 Item → Freestyle project 또는 Pipeline 선택
Pipeline 선택 시 "Definition" 항목에서 방식 결정
- Pipeline script → 화면에 직접 Groovy 코드 작성
- Pipeline script from SCM → Git URL, credential, branch, Script Path 입력
Save
"지금 빌드" 클릭
콘솔 출력(Console Output)에서 실행 로그 확인. 어느 stage에서 뭘 했는지 순서대로 나옴

7. 도커 위에서 Jenkins를 띄우면

Controller를 Docker 컨테이너로 운영하면 얻는 것.

환경을 Dockerfile로 코드화 → 서버 교체/장애 복구 시 재현 쉬움
호스트 OS와 격리 → Java 버전, 의존성 충돌 없음
이미지 태그 변경만으로 업그레이드/롤백
JENKINS_HOME을 volume으로 분리하면 컨테이너를 갈아끼워도 데이터 보존

주의할 점.

Volume 마운트 안 하면 컨테이너 삭제 시 Job 설정/빌드 이력 전부 소실
컨테이너 안에서 Docker 빌드까지 하려면(docker.sock 마운트) 호스트 Docker 데몬 제어권을 넘기는 셈이라 보안 검토 필요
리소스 제한 안 걸면 빌드 폭주 시 호스트 전체에 영향

서버 디스크가 100% — 로그 파이프라인

김구황 — Sat, 27 Jun 2026 07:51:51 +0900

Jenkins 빌드 배포가 먹통이 되어 서버에 들어가보니 /engine 디렉토리 용량이 100%.

실제 발생한 이슈를 바탕으로, ELK 스택과 Jenkins가 함께 올라가 있는 서버에서 로그가 어떻게 흐르는지, 각 도구의 역할이 뭔지 분석.

1. stdout과 stderr — 로그는 어디서 시작되는가

로그의 출발점 : 어떤 프로그램이 실행되면, 운영체제는 그 프로세스에 기본적으로 세 가지 통로(파일 디스크립터)를 오픈

프로세스가 실행되면 OS가 stdin/stdout/stderr 세 통로를 자동으로 열어주고, 실행 방법에 따라 stdout/stderr의 목적지가 달라진다

모든 프로세스는 태어날 때부터 세 개의 통로를 가지고 있고, 우리가 System.out.println()을 쓰든 Python의 print()를 쓰든 결국 그건 다 stdout으로 나오는 거다. 하지만, 어플리케이션이 로그를 "어떤 파일에 쓴다"고 설정했을 때는, 그 라이브러리(log4j, logback 등)가 내부적으로 파일 디스크립터를 직접 파일로 연결한 것이다. stdout/stderr를 거치지 않는다.

핵심 개념 stdout → 정상적인 출력. 로그 라이브러리에서 INFO, DEBUG 레벨이 여기로 나오는 경우가 많음
stderr → 오류 출력. ERROR, 예외 스택 트레이스가 주로 여기로
그리고 이 둘의 목적지는 실행 방법(터미널, nohup, systemd)에 따라 완전히 달라짐

2. 핵심 개념 4가지 — nohup / systemd / logrotate / journald

이 네 가지는 서로 비교 대상이 아니다. 각각 다른 문제를 해결하는 도구다.

실행 방식과 로그 관리 방식의 짝꿍 관계

nohup

SSH 접속이 끊기면 그 세션에서 실행된 프로세스도 같이 죽어버린다. nohup은 이걸 막기 위한 단순한 명령어다. 터미널 세션과 프로세스를 분리하는 것이 전부고, 로그 관리 기능은 없다. stdout/stderr를 nohup.out에 쏟아내는 것도 그냥 기본 동작이다.

systemd

Linux의 init 시스템이다. 서버가 부팅될 때 가장 먼저 뜨는 프로세스(PID 1)로, 이후 모든 서비스를 관리한다. 부팅 시 자동 시작, 프로세스가 죽으면 자동 재시작, 의존성 관리가 가능하고, stdout/stderr를 자동으로 journald에 넘긴다. nohup과 비교했을 때 관리 기능이 훨씬 많다.

journald

systemd가 관리하는 서비스들의 로그를 받아서 저장하는 로그 수집기다. /var/log/journal/에 바이너리 형태로 저장하고, 용량과 기간 설정으로 자동 로테이션해준다. systemd로 실행된 서비스는 별도 설정 없이 자동으로 여기로 로그가 들어간다.

logrotate

파일 기반 로그를 주기적으로 잘라주는 도구다. nohup.out처럼 파일에 무한정 쌓이는 로그를 날짜별로 분리하고, 오래된 건 압축하거나 삭제한다. cron으로 주기적으로 실행된다.

nohup + logrotate를 같이 쓸 때 주의할 점 nohup으로 실행 중인 프로세스는 nohup.out 파일 디스크립터를 계속 물고 있다. 그냥 파일을 삭제하거나 교체하면 프로세스는 이미 없어진 파일에 계속 쓰려고 한다. copytruncate 옵션이 이걸 해결해준다. 내용을 복사해두고 원본을 비워버려서(truncate) 프로세스 재시작 없이 동작한다.

3. 이슈 상황 — 서버 구성과 문제

테스트 스테이지 솔루션 서버 한 대에 아래 프로그램들이 다 함께 올라가 있었다.

서버 구성 Jenkins / Vector / Elasticsearch / Kibana — 단일 서버에 공존
PC 앱, MO 앱, 관리자 앱, 파트너사 앱 × 4개 stage = 총 16개 앱 인스턴스가 로그를 이 서버로 전송

/engine 디렉토리 용량이 100%에 도달하면서 Jenkins 빌드가 실패하기 시작했다. 원인을 추적해보니 두 곳에서 로그가 관리 없이 무한정 쌓이고 있었다.

Jenkins 서버 로그(jenkins.log) — 로테이션 없이 append
Vector 프로세스 로그(nohup.out) — nohup 방식으로 실행 중, 무한 증가

4. ELK 로그 파이프라인 전체 흐름

앱 로그 데이터 흐름과 Vector 자체 서버 로그는 완전히 별개의 채널이다.

전체 로그 파이프라인 — 상단은 앱 로그 데이터 흐름, 하단은 Vector 자체 서버 로그 처리 방식 비교

핵심: nohup.out을 지워도 앱 로그는 사라지지 않는다

Vector가 Kafka에서 읽어온 앱 로그 데이터는 Vector 프로세스의 메모리(RAM) 안에서 처리돼서 Elasticsearch로 전송된다. nohup.out은 이 흐름과 전혀 무관하다. nohup.out에는 Vector 프로세스 자신의 상태 메시지(INFO: 연결됨, ERROR: 전송 실패 등)만 담겨 있다.

Vector 프로세스 안에는 두 채널이 완전히 분리되어 있다

결론 nohup.out 삭제 = 앱 로그 데이터 흐름에 영향 없음.
nohup.out에는 Vector 자신의 상태 로그만 있을 뿐, Elasticsearch로 가는 데이터와 무관하다.

5. Jenkins 로그 구조 — systemd인데 왜 파일에 쌓이나

Jenkins는 systemd로 실행되고 있었다. 그런데 로그는 journald가 아니라 jenkins.log 파일에 쌓이고 있었다. 일반적인 상식으로는 이해가 안 가는 상황이다.

이유는 JVM 때문이다. Jenkins는 JVM 위에서 동작하고, 내부적으로 java.util.logging 프레임워크가 stdout으로 내보내기 전에 로그를 가로채서 파일에 직접 써버린다. systemd 입장에서는 Jenkins가 거의 아무것도 stdout에 출력하지 않는 프로세스처럼 보인다. 그래서 journald에는 Jenkins 서버 로그가 거의 들어오지 않는다.

Jenkins는 JVM이 systemd를 우회해 파일에 직접 쓴다 — 그래서 systemd로 실행해도 journald에 로그가 안 쌓인다

/etc/default/jenkins 또는 /etc/sysconfig/jenkins 파일을 보면 이런 설정이 있다.

# Jenkins 서버 로그 경로 설정
JENKINS_LOG=/var/log/jenkins/jenkins.log

JVM이 이 경로를 읽어서 직접 파일에 쓰는 구조다. Vector(단순 프로세스)와 Jenkins(JVM 앱)가 같은 systemd 위에 있어도 로그 목적지가 달라지는 이유가 여기 있다.

항목	일반 프로세스 (Vector 등)	Jenkins (JVM)
stdout/stderr 처리	systemd → journald 자동 수집	JVM이 직접 파일에 write (우회)
서버 로그 위치	journald `journalctl -u vector -f`	/var/log/jenkins/jenkins.log
로그 관리 방법	journald.conf 설정	logrotate 별도 설정
빌드 로그 관리	해당 없음	config.xml 보존 기간/개수 설정

6. 실제 조치 순서

긴급 조치 — Vector 중지 후 nohup.out 삭제

용량 확보가 급선무였다. Vector를 종료하고 수십 GB까지 불어난 nohup.out을 삭제했다. 앱 로그 데이터 파이프라인과 무관한 파일이라 삭제해도 데이터 손실이 없다.

임시 처치 — /dev/null 리다이렉션

재시작 시 서버 로그를 아예 버리도록 했다.

nohup /bin/vector -C config > /dev/null 2>&1 &

빠르게 공간을 확보할 수 있지만, Vector 내부 에러를 아예 볼 수 없어진다는 단점이 있어서 어디까지나 임시 처치다.

근본 해결 — systemd 서비스로 전환

/etc/systemd/system/vector.service 파일을 작성한다.

[Unit]
Description=Vector log pipeline
After=network.target

[Service]
ExecStart=/bin/vector -C /etc/vector/config
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable vector   # 부팅 시 자동 시작
systemctl start vector

이제 Vector의 서버 로그는 journald가 자동으로 수집하고 관리한다.

journald 용량 설정

# /etc/systemd/journald.conf
SystemMaxUse=500M
MaxRetentionSec=30day

systemctl restart systemd-journald

Jenkins 빌드 로그 보존 정책 설정

Jenkins 관리 → 각 Job 설정 → 오래된 빌드 삭제 → 보존 일수(30일), 최대 빌드 수(100) 설정. config.xml을 직접 수정하는 방법도 있다.

Elasticsearch ILM 정책 확인

앱 로그가 ES에 쌓이는 것도 결국 디스크를 먹는다. Index Lifecycle Management(ILM) 정책이 없으면 이것도 결국 터진다. 오래된 인덱스 자동 삭제 정책을 반드시 확인해야 한다.

7. nohup + logrotate도 유효한 선택이다

systemd 전환이 표준 권장 방식이지만, 기존 실행 스크립트를 건드리기 어렵거나 환경 제약이 있다면 nohup 방식을 유지하면서 logrotate로 관리하는 것도 완전히 유효한 선택이다.

# /etc/logrotate.d/vector
/engine/.../nohup.out {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate   # 실행 중인 프로세스 재시작 없이 동작하는 핵심 옵션
}

방식	장점	단점
nohup + logrotate	기존 방식 유지, 설정 간단	재부팅 자동시작 없음, 프로세스 죽어도 재시작 없음
systemd + journald	자동 재시작, 부팅 자동시작, 로그 자동 관리	서비스 파일 작성 필요, 기존 스크립트 수정

- 젠킨스 실행/빌드 로그

로그

김구황 — Sun, 7 Jun 2026 16:34:19 +0900

요약

catalina.out은 Tomcat 프로세스의 콘솔 출력이 모이는 파일에 가까운 로그. 애플리케이션 로그가 콘솔로 출력되고 있다면 해당 로그도 catalina.out에 쌓일 수 있음. 하지만 Vector가 catalina.out을 수집하지 않는다면 Kibana에서는 이 로그를 확인할 수 없음.

반면 Kibana에서 조회되는 로그는 Vector가 읽고 Kafka를 거쳐 Elasticsearch에 저장된 로그. 서버에 존재하는 모든 로그가 자동으로 Kibana에 보이는 구조가 아님.

logrotate는 일반 로그 파일을 주기적으로 나누고 압축하고 삭제하는 도구. systemd는 서비스를 실행하고 stdout/stderr의 처리 방식을 관리하는 도구. systemd를 사용한다고 해서 모든 로그 파일의 rotate가 자동으로 해결되는 것은 아님.

운영 환경에서 로그를 설계할 때 확인해야 할 핵심 질문은 세 가지.

애플리케이션 로그는 어디에 저장되는가
stdout/stderr는 어디로 흘러가는가
수집기는 어떤 파일을 읽고 있는가

이 세 가지가 맞지 않으면 Kibana에서는 조용하지만 서버 디스크만 가득 차는 상황 발생 가능.

로그 파이프라인을 구성할 때는 단순히 “Kibana에서 보이는가”만 볼 것이 아니라, 서버 안에서 실제로 어떤 로그 파일이 생성되고 증가하는지까지 함께 확인하는 관점 필요.

1. 서버 로그는 하나가 아니라 여러 갈래의 흐름

서버에서 “로그”라고 부르는 것은 하나의 파일이나 하나의 시스템을 의미하지 않음. 실제로는 로그를 남기는 주체, 로그가 저장되는 위치, 로그를 수집하는 도구, 로그를 조회하는 화면이 모두 분리된 구조.

대표적인 흐름은 다음과 같은 형태.

애플리케이션 코드
  ↓
Logback
  ↓
로그 파일 또는 콘솔 출력
  ↓
Vector
  ↓
Kafka
  ↓
Elasticsearch
  ↓
Kibana

애플리케이션에서 다음과 같은 코드를 작성했다고 가정.

logger.info("주문 생성 완료");

이 로그가 실제로 어디에 남는지는 Logback 설정에 따라 달라짐.

파일로 저장
→ /logs/mobile/application.log

콘솔로 출력
→ stdout 또는 stderr

Tomcat 실행 환경에서 콘솔 출력 저장
→ catalina.out

Vector 수집 대상 파일
→ Kafka, Elasticsearch, Kibana로 전달

즉, 애플리케이션에서 로그를 남겼다고 해서 모든 로그가 Kibana에 보이는 구조는 아님. Kibana에 보이는 로그는 수집기가 읽어서 Elasticsearch까지 전달한 로그뿐.

2. catalina.out의 정체

catalina.out은 Tomcat 환경에서 자주 등장하는 로그 파일. 일반적으로 Tomcat 프로세스의 표준 출력과 표준 에러가 모이는 파일에 가까운 개념.

쉽게 말하면 다음과 같은 출력이 catalina.out에 쌓일 수 있음.

System.out.println()
System.err.println()
콘솔로 출력되는 애플리케이션 로그
Tomcat 실행 중 발생한 에러
예외 스택트레이스

Tomcat을 실행하면 내부적으로 여러 로그 파일이 생성될 수 있음.

파일의미

catalina.out	Tomcat 프로세스의 콘솔 출력 저장 파일
catalina.YYYY-MM-DD.log	Tomcat 자체 동작 로그
localhost.YYYY-MM-DD.log	웹 애플리케이션 컨텍스트 관련 로그
localhost_access_log.YYYY-MM-DD.txt	HTTP 요청 접근 로그

이 중 디스크 증가 문제에서 자주 원인이 되는 파일은 catalina.out.

중요한 점은 catalina.out이 Logback의 RollingFileAppender가 관리하는 애플리케이션 로그 파일이 아닐 수 있다는 점. 애플리케이션 로그가 콘솔로 출력되고, Tomcat이 그 콘솔 출력을 catalina.out에 저장하는 구조일 수 있음.

예를 들면 이런 흐름.

애플리케이션 로그 발생
  ↓
Logback ConsoleAppender
  ↓
stdout / stderr
  ↓
Tomcat 실행 스크립트
  ↓
catalina.out

반대로 Logback이 파일에 직접 쓰는 경우는 다음과 같은 흐름.

애플리케이션 로그 발생
  ↓
Logback RollingFileAppender
  ↓
/var/log/mobile/application.log

두 로그는 비슷한 내용을 담을 수 있지만 관리 주체와 저장 위치가 다른 별개의 로그.

3. Kibana 수집 로그의 의미

Kibana는 로그를 직접 수집하는 도구가 아님. Elasticsearch에 저장된 데이터를 검색하고 시각화하는 화면.

즉, Kibana에서 로그를 보기 위해서는 먼저 로그가 Elasticsearch에 들어가 있어야 함. 그 앞단에는 보통 Vector, Filebeat, Logstash 같은 수집기가 존재.

이번 구조를 기준으로 보면 다음과 같은 흐름.

서버 로그 파일
  ↓
Vector
  ↓
Kafka
  ↓
Elasticsearch
  ↓
Kibana

각 구성요소의 역할은 다음과 같음.

구성요소역할

Logback	애플리케이션 로그의 출력 위치와 형식 결정
Vector	서버의 로그 파일을 읽고 다음 단계로 전달
Kafka	로그 이벤트를 안정적으로 전달하기 위한 메시지 스트림
Elasticsearch	로그를 검색 가능한 형태로 저장
Kibana	Elasticsearch에 저장된 로그 조회 및 시각화

따라서 “Kibana 수집 로그”라는 표현은 정확히는 다음과 같은 의미.

Vector가 읽은 로그
Kafka를 거쳐 Elasticsearch에 저장된 로그
Kibana에서 조회 가능한 로그

반대로 서버에 존재하지만 Vector가 읽지 않는 파일은 Kibana에 보이지 않음.

예를 들어 Vector 설정이 다음 파일만 읽는 상태라고 가정.

/logs/mobile/application.log
/logs/mobile/error.log

그런데 catalina.out의 위치가 다음과 같다면.

/usr/local/tomcat/logs/catalina.out

결과는 다음과 같은 구조.

application.log
→ Vector 수집
→ Kafka
→ Elasticsearch
→ Kibana에서 조회 가능

catalina.out
→ Vector 수집 대상 아님
→ Elasticsearch 미저장
→ Kibana에서 조회 불가
→ 서버 디스크에는 계속 누적

이런 구조 때문에 Kibana에서는 문제가 보이지 않는데 서버 저장소는 계속 증가하는 상황 발생 가능.

4. 이번 문제의 구조

이번 저장소 증가 문제는 다음과 같은 구조로 이해 가능.

모바일 서버에서 로그 급증
  ↓
서버 저장소 사용량 증가
  ↓
확인 결과 catalina.out 파일 증가
  ↓
해당 파일은 Vector 수집 대상이 아님
  ↓
Kibana에서는 관련 로그 조회 불가
  ↓
서버 디스크에만 로그 누적

즉, 핵심은 “Kibana에 보이는 로그”와 “서버에 실제로 쌓이는 로그”가 서로 다를 수 있다는 점.

애플리케이션에서 예외가 반복적으로 발생하고, 그 예외가 콘솔로 출력되고 있었다면 다음과 같은 흐름 가능.

Exception 발생
  ↓
콘솔 출력
  ↓
Tomcat stdout / stderr
  ↓
catalina.out 증가
  ↓
Vector 수집 대상 아님
  ↓
Kibana에서 확인 불가
  ↓
서버 저장소 증가

운영 환경에서 로그를 확인할 때는 Kibana만 보는 것으로 충분하지 않음. 실제 서버에서 어떤 파일이 증가하고 있는지 별도 확인 필요.

5. /dev/null의 의미

로그 문제를 처리하는 과정에서 자주 등장하는 표현 중 하나가 /dev/null.

/dev/null은 리눅스에서 데이터를 버리는 특수 파일. 여기에 출력되는 내용은 저장되지 않고 사라짐.

예를 들어 다음 명령.

some-command > /dev/null 2>&1

의미는 다음과 같음.

> /dev/null
→ 표준 출력(stdout)을 버림

2>&1
→ 표준 에러(stderr)를 표준 출력과 같은 곳으로 보냄

결과
→ stdout과 stderr 모두 버림

systemd 서비스에서는 비슷한 설정을 다음과 같이 적용 가능.

[Service]
StandardOutput=null
StandardError=null

이 설정은 서비스의 표준 출력과 표준 에러를 저장하지 않고 버리는 방식.

다만 /dev/null 처리는 신중하게 접근 필요. 디스크 증가를 막을 수는 있지만, 해당 로그는 복구 불가능한 형태로 사라짐. 필요한 로그가 Logback 파일 로그나 Kibana 수집 로그로 안정적으로 남고 있다는 전제 필요.

6. .gz 로그 파일의 의미

로그 디렉터리에서 자주 보이는 .gz 파일은 gzip으로 압축된 로그 파일.

예시.

application.log
application.2026-06-01.log.gz
application.2026-06-02.log.gz
application.2026-06-03.log.gz

이 파일들은 보통 과거 로그를 압축한 결과물. 생성 주체는 크게 두 가지 가능성.

logrotate가 압축한 로그
Logback RollingFileAppender가 압축한 로그

Logback 설정에서 다음과 같은 패턴을 사용하면 과거 로그가 .gz 형태로 보관 가능.

<fileNamePattern>/logs/mobile/app.%d{yyyy-MM-dd}.log.gz</fileNamePattern>
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>

의미는 다음과 같음.

날짜별 로그 파일 생성
지난 로그를 gzip으로 압축
30일치 보관
전체 보관 용량 3GB 제한

.gz 파일 삭제는 이미 압축되어 보관 중인 과거 로그를 제거하여 디스크 공간을 확보하는 조치. 다만 장애 분석이나 추적에 필요한 로그일 수 있으므로 삭제 전 보관 정책 확인 필요.

7. logrotate의 역할

logrotate는 리눅스에서 로그 파일을 자동으로 관리하는 도구.

로그 파일은 그냥 두면 계속 커짐.

application.log

그래서 일정 주기나 크기 기준으로 파일을 나누고, 오래된 파일을 압축하거나 삭제하는 관리 필요.

application.log
application.log.1
application.log.2.gz
application.log.3.gz

logrotate의 핵심 역할은 다음과 같음.

rotate
→ 현재 로그 파일을 과거 로그 파일로 넘김

compress
→ 오래된 로그 파일 압축

remove
→ 보관 기간이 지난 로그 삭제

postrotate
→ rotate 이후 서비스에 신호 전달

예시 설정.

/var/log/tomcat/catalina.out {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

각 옵션의 의미.

daily
→ 매일 rotate

rotate 7
→ 7개 파일만 보관

compress
→ 지난 로그 압축

missingok
→ 파일이 없어도 오류 처리하지 않음

notifempty
→ 빈 파일은 rotate하지 않음

copytruncate
→ 기존 파일을 복사한 뒤 원본 파일 크기를 0으로 비움

catalina.out처럼 프로세스가 계속 열고 있는 로그 파일은 단순히 파일명을 바꾸는 방식만으로는 충분하지 않을 수 있음. 애플리케이션이 여전히 기존 파일을 바라보고 있을 수 있기 때문. 이런 경우 copytruncate 같은 방식이 사용되기도 함.

단, copytruncate는 복사와 비우기 사이의 짧은 순간에 일부 로그 유실 가능성 존재.

8. systemd의 역할

systemd는 리눅스에서 서비스를 실행하고 관리하는 시스템 관리자.

서버가 켜질 때 서비스를 자동 실행하고, 서비스가 죽었을 때 재시작하며, 어떤 사용자 권한으로 실행할지, 표준 출력과 표준 에러를 어디로 보낼지 등을 관리.

예시.

[Unit]
Description=Mobile API Server

[Service]
User=mobile
WorkingDirectory=/opt/mobile
ExecStart=/usr/bin/java -jar mobile.jar
Restart=always
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

여기서 중요한 설정은 다음 부분.

StandardOutput=journal
StandardError=journal

서비스의 표준 출력과 표준 에러를 systemd journal로 보내는 설정. 이 경우 로그는 journalctl 명령으로 확인 가능.

journalctl -u mobile.service
journalctl -u mobile.service -f

systemd를 사용하면 catalina.out 같은 파일에 stdout/stderr가 쌓이지 않도록 구성 가능. 하지만 이것이 모든 로그 파일에 대해 logrotate가 필요 없다는 의미는 아님.

9. systemd를 쓰면 logrotate가 필요 없을까

항상 그렇지는 않음.

systemd와 logrotate는 역할이 다름.

systemd
→ 서비스를 실행하고 stdout/stderr 처리 방식을 결정

logrotate
→ 일반 파일로 쌓이는 로그를 주기적으로 정리

상황별로 보면 다음과 같음.

로그 저장 방식관리 방식

stdout/stderr → journald	journald 보관 정책 확인
stdout/stderr → /dev/null	저장되는 로그 없음
stdout/stderr → 일반 파일	logrotate 필요 가능성 높음
Logback → RollingFileAppender	Logback rolling 정책 필요
Logback → 단순 FileAppender	logrotate 또는 rolling 설정 필요
Tomcat → catalina.out	logrotate 필요 가능성 높음

즉, systemd로 서비스를 구성하더라도 애플리케이션이 Logback으로 파일에 직접 쓰고 있다면 해당 파일에 대한 rolling 정책 필요. Tomcat이 catalina.out에 계속 출력하고 있다면 해당 파일 역시 별도 관리 필요.

정확한 표현은 다음에 가까움.

systemd로 stdout/stderr를 journald에 보내면 catalina.out 관리 부담은 줄어들 수 있음
하지만 애플리케이션 로그 파일까지 자동으로 rotate되는 것은 아님

10. catalina.out이 위험해지는 이유

catalina.out은 운영 환경에서 디스크 증가 문제의 원인이 되기 쉬운 파일.

주요 이유는 다음과 같음.

stdout과 stderr가 한 파일에 모임
애플리케이션 콘솔 로그가 함께 쌓일 수 있음
반복 에러 발생 시 스택트레이스가 빠르게 누적됨
Logback의 maxHistory, totalSizeCap 관리 대상이 아닐 수 있음
Vector 수집 대상이 아니면 Kibana에서 확인 불가

특히 Logback 설정에 ConsoleAppender와 FileAppender가 함께 있으면 같은 로그가 두 경로로 남을 수 있음.

<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>

이 경우 흐름은 다음과 같음.

CONSOLE
→ stdout/stderr
→ catalina.out

FILE
→ application.log
→ Vector
→ Kafka
→ Elasticsearch
→ Kibana

결과적으로 Kibana에는 application.log 기준 로그만 보이고, catalina.out은 별도로 서버 디스크에서 증가하는 상황 가능.

11. 운영 환경에서 확인할 항목

로그로 인한 디스크 증가가 발생했을 때 확인할 항목.

디스크 사용량 확인

df -h

어느 파티션이 가득 찼는지 확인.

큰 로그 디렉터리 확인

du -sh /var/log/* 2>/dev/null | sort -h
du -sh /usr/local/tomcat/logs/* 2>/dev/null | sort -h
du -sh /opt/*/logs/* 2>/dev/null | sort -h

어떤 디렉터리가 커지고 있는지 확인.

Tomcat 로그 확인

ls -lh /usr/local/tomcat/logs/
tail -n 100 /usr/local/tomcat/logs/catalina.out

catalina.out 크기와 반복 로그 확인.

systemd 서비스 설정 확인

systemctl cat mobile.service

서비스의 실행 방식과 stdout/stderr 처리 방식 확인.

journald 로그 확인

journalctl -u mobile.service -n 100
journalctl -u mobile.service -f

systemd journal로 들어가는 로그 확인.

Logback 설정 확인

grep -R "ConsoleAppender\|RollingFileAppender\|fileNamePattern\|maxHistory\|totalSizeCap" .

콘솔 출력 여부, 파일 로그 여부, rolling 정책 확인.

Tomcat의 catalina.out 설정 확인

grep -R "catalina.out\|CATALINA_OUT" /usr/local/tomcat/bin /etc/systemd/system 2>/dev/null

catalina.out 생성 방식 확인.

삭제된 파일 점유 여부 확인

lsof | grep deleted

로그 파일을 삭제했는데도 디스크 사용량이 줄지 않는 경우 존재. 프로세스가 삭제된 파일을 계속 열고 있으면 공간이 바로 반환되지 않을 수 있음. 이 경우 프로세스 재시작 또는 정상적인 로그 파일 해제 필요.

급한 디스크 확보가 필요한 경우 파일 자체 삭제보다 파일 내용만 비우는 방식 사용 가능.

: > /usr/local/tomcat/logs/catalina.out

파일 핸들을 유지한 채 내용만 비우는 방식. 단, 운영 환경에서는 사전 정책과 영향도 확인 필요.

JDBC 트랜잭션의 원리

김구황 — Sun, 17 May 2026 20:00:13 +0900

Backend Deep Dive

Spring + JDBC 트랜잭션의 원리
이중 실행 방지까지

ThreadLocal, Connection Pool, @Transactional의 동작 원리를 한 번에 이해하는 가이드 — 주니어 개발자를 위한 실전 해설

Spring Framework JDBC / Connection Pool ThreadLocal JDK 21 Virtual Thread

왜 이 문제를 만났는가 — 이중 실행의 위험
JDBC가 Connection을 관리하는 방법 — ThreadLocal
스레드 풀과 Connection 반납 원리
@Transactional 어노테이션의 실제 동작
DB Lock과 트랜잭션 전파 — 첫 번째 시도와 그 한계
JDK 21 Virtual Thread로 문제 해결하기
실전 설계 — CountDownLatch + UPSERT + SELECT FOR UPDATE
공통 백엔드 개발자가 꼭 알아야 할 원리 정리

1왜 이 문제를 만났는가 — 이중 실행의 위험

백엔드 개발을 하다 보면 반드시 마주치는 상황이 있습니다. 하나의 API 요청 안에서 여러 업무(비즈니스 로직)가 순서대로 실행되어야 할 때, 그리고 그 중 하나가 동시에 중복 실행되면 안 되는 경우입니다.

실제 문제 상황

클라이언트(앱/브라우저)는 타임아웃이 발생해 요청을 취소했지만, 서버는 그 사실을 모른 채 계속 작동합니다. 이 틈에 같은 요청이 다시 들어오면 데이터가 중복으로 처리될 수 있습니다.

문제가 되는 구조

class OrderService {

    @Transactional
    void processOrder(Long orderId) {

        task1_validateOrder(orderId);   // 업무1: DB 조회

        task2_deductInventory(orderId); // 업무2: 재고 차감 (느림, 중복 불가!)
        // ↑ 클라이언트가 여기서 timeout → 재요청 발생
        // ↑ 서버는 모르고 계속 실행 중...

        task3_createShipment(orderId);  // 업무3: 배송 생성
    }
}

업무2는 두 가지 조건이 충돌합니다. 처리 시간이 길어서 클라이언트가 타임아웃을 일으키기 쉽고, 동시에 같은 데이터에 대해 두 번 실행되면 재고가 두 배로 차감되는 치명적 버그가 발생합니다.

2JDBC가 Connection을 관리하는 방법 — ThreadLocal

트랜잭션을 이해하려면 먼저 JDBC가 DB 커넥션을 어떻게 저장하고 관리하는지를 알아야 합니다. 핵심 개념은 바로 ThreadLocal입니다 — 스레드마다 별도의 변수 공간을 제공하는 것입니다.

Spring의 TransactionSynchronizationManager

Spring이 실제로 커넥션을 관리할 때 사용하는 클래스가 바로 TransactionSynchronizationManager입니다. 내부적으로 ThreadLocal로 구현되어 있습니다.

Spring 내부 구현 (간략화)

public abstract class TransactionSynchronizationManager {

    // 핵심: ThreadLocal로 Connection을 스레드에 묶는다
    private static final ThreadLocal<Map<Object, Object>> resources =
        new NamedThreadLocal("Transactional resources");

    // 트랜잭션 시작 시 Connection을 현재 스레드에 바인딩
    public static void bindResource(Object key, Object value) {
        Map<Object, Object> map = resources.get();
        if (map == null) { map = new HashMap<>(); resources.set(map); }
        map.put(key, value); // DataSource → Connection 매핑
    }

    // 같은 스레드에서 Connection 조회 → 항상 같은 Connection 반환
    public static Object getResource(Object key) {
        Map<Object, Object> map = resources.get();
        return (map != null ? map.get(key) : null);
    }
}

핵심 원리

같은 스레드 안에서 실행되는 모든 메서드가 동일한 Connection을 공유할 수 있는 이유가 바로 ThreadLocal입니다. 업무1(), 업무2(), 업무3()이 모두 같은 트랜잭션에 묶이는 것이 이 원리 덕분입니다.

REQUIRES_NEW 사용 시 Connection이 중첩되는 구조

3스레드 풀과 Connection 반납 원리

스레드를 매 요청마다 새로 만들면 CPU와 메모리 비용이 큽니다. 그래서 서버는 스레드 풀(Thread Pool)을 미리 만들어 두고 재사용합니다. Tomcat은 기본적으로 200개의 스레드를 유지합니다.

왜 Thread.join()을 쓸 수 없는가

처음에는 "업무2()를 별도 스레드로 분리하고, thread.join()으로 기다리면 되지 않나?"라고 생각할 수 있습니다. 하지만 이 방법에는 치명적인 문제가 있습니다.

❌ 안 되는 이유

Thread.join()은 현재 스레드를 블로킹(blocking)합니다. 스레드 풀에서 빌려온 Thread-1이 join()으로 멈추면, 그 스레드는 다른 HTTP 요청을 처리하지 못합니다.

Thread-1이 잡고 있는 Connection-1도 함께 블로킹됩니다. 풀의 스레드와 커넥션이 모두 대기 상태가 되어 서버 전체가 마비될 수 있습니다.

✅ 올바른 접근

스레드 풀 스레드를 블로킹하지 않는 방법이 필요합니다. JDK 21의 Virtual Thread가 이 문제를 우아하게 해결합니다.

Virtual Thread는 블로킹되더라도 OS 스레드를 점유하지 않아서 수천 개가 동시에 실행되어도 풀 고갈이 없습니다.

4@Transactional 어노테이션의 실제 동작

@Transactional은 많은 개발자가 "그냥 트랜잭션 묶어주는 거"로만 알고 있습니다. 하지만 실제로는 AOP Proxy를 통해 동작하며, 이 원리를 모르면 예상치 못한 버그를 만납니다.

Spring이 Proxy 객체 생성

Spring 컨텍스트가 시작될 때, @Transactional이 붙은 빈을 감싸는 CGLIB Proxy를 생성합니다. 실제로 주입받는 것은 원본 객체가 아닌 이 Proxy입니다.

Proxy가 메서드 호출 가로채기

메서드가 호출되면 Proxy가 먼저 받아서 TransactionInterceptor를 실행합니다. 여기서 DataSource로부터 Connection을 가져와 ThreadLocal에 바인딩합니다.

실제 메서드 실행 — 같은 Connection 재사용

원본 메서드가 실행됩니다. 내부에서 Repository를 통해 DB에 접근할 때, JDBC는 ThreadLocal에서 아까 바인딩한 Connection을 꺼내어 사용합니다 — 모두 같은 트랜잭션에 속합니다.

예외 없으면 커밋, 예외 있으면 롤백 후 반납

메서드가 정상 종료되면 connection.commit()을 호출하고, RuntimeException이 발생하면 connection.rollback()을 호출합니다. 이후 Connection을 Pool에 반납합니다.

@Transactional이 실제로 하는 일 (의사코드)

// Spring이 생성하는 Proxy 클래스 (개념적 표현)
class OrderService$$SpringCGLIB extends OrderService {

    void processOrder(Long orderId) {
        Connection conn = dataSource.getConnection(); // Pool에서 획득
        conn.setAutoCommit(false);
        TransactionSynchronizationManager.bindResource(dataSource, conn);
        try {
            super.processOrder(orderId); // 실제 비즈니스 로직
            conn.commit();
        } catch (RuntimeException e) {
            conn.rollback(); throw e;
        } finally {
            TransactionSynchronizationManager.unbindResource(dataSource);
            conn.close(); // 실제로는 Pool에 반납
        }
    }
}

⚠️

@Transactional이 동작하지 않는 경우

같은 클래스 내부 호출은 Proxy를 거치지 않습니다! this.업무2()처럼 자기 자신을 직접 호출하면 Proxy가 끼어들지 못해 트랜잭션이 적용되지 않습니다. 반드시 다른 Bean을 통해 호출하거나, AopContext.currentProxy()를 활용해야 합니다.

트랜잭션 전파(Propagation) 옵션

옵션	동작	언제 쓰나
`REQUIRED` (기본)	트랜잭션이 있으면 합류, 없으면 새로 생성	일반적인 상황 대부분
`REQUIRES_NEW`	항상 새 트랜잭션 생성, 기존 일시 중지	외부 TX 실패와 무관하게 커밋이 필요할 때 (감사 로그 등)
`NESTED`	중첩 트랜잭션 (Savepoint 활용)	부분 롤백이 필요할 때
`NOT_SUPPORTED`	트랜잭션 없이 실행	성능을 위해 TX 없이 조회할 때
`NEVER`	트랜잭션 있으면 예외 발생	절대 TX 안에서 실행되면 안 되는 작업

5DB Lock과 트랜잭션 전파 — 첫 번째 시도와 그 한계

이중 실행을 막기 위해 가장 먼저 떠오르는 방법은 DB Lock입니다. 업무2()를 실행하기 전에 Lock을 걸고, 같은 Lock을 획득하려는 두 번째 요청은 실패시키는 것입니다.

첫 번째 시도: REQUIRES_NEW + SELECT FOR UPDATE

@Service
class OrderService {
    @Transactional // 외부 트랜잭션 (Connection-1)
    public void processOrder(Long orderId) {
        task1_validateOrder(orderId);
        inventoryService.deductWithLock(orderId); // 별도 Bean 호출 → Proxy 통과 ✅
        task3_createShipment(orderId);
    }
}

@Service
class InventoryService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    // 새로운 트랜잭션 (Connection-2) 생성 — Thread-1이 이제 2개 커넥션 보유!
    public void deductWithLock(Long orderId) {
        Inventory inv = inventoryRepo.findByOrderIdForUpdate(orderId); // SELECT FOR UPDATE
        if (inv == null) throw new DuplicateExecutionException("이미 처리 중");
        inventoryRepo.save(inv);
    } // REQUIRES_NEW 커밋 → Lock 해제
}

HikariCP 데드락 방지 설정

REQUIRES_NEW를 사용한다면 최악의 경우 스레드당 2개의 Connection이 필요합니다. Pool 사이즈를 넉넉히 잡지 않으면 Connection 대기 타임아웃이 발생합니다.

⚙️

Heartbeat 방식의 문제

분산 Lock(Redis SETNX)을 쓰면 TTL을 설정할 수 있지만, "얼마나 긴 TTL을?"이라는 새로운 문제가 생깁니다. TTL이 짧으면 정상 처리 중에 Lock이 해제되고, TTL이 길면 서버 장애 시 Lock이 오래 남습니다. Heartbeat를 구현하면 복잡도가 폭발합니다. Redisson 같은 라이브러리가 이를 내부적으로 처리해 줍니다.

6JDK 21 Virtual Thread로 문제 해결하기

앞서 살펴본 모든 문제의 근원은 하나입니다: Thread-1이 업무2를 처리하는 동안 Connection-1을 잡고 있어야 한다는 것입니다. JDK 21의 Virtual Thread를 사용하면 이 문제를 우아하게 풀 수 있습니다.

Virtual Thread로 문제 해결하는 원리

핵심 아이디어는: 업무2를 Virtual Thread에서 실행시키는 것입니다. Virtual Thread는 자신만의 ThreadLocal을 가지므로, 새로운 Connection이 자동으로 할당됩니다.

Virtual Thread를 활용한 개선된 구현

@Service
class OrderService {

    @Transactional
    public void processOrder(Long orderId) {

        task1_validateOrder(orderId); // Thread-1, Connection-1 사용

        // ✅ Virtual Thread를 생성하여 업무2 실행
        // 새 ThreadLocal → 새 Connection → 독립 트랜잭션 (REQUIRES_NEW 불필요)
        Thread vt = Thread.ofVirtual()
            .name("vt-deduct-" + orderId)
            .start(() -> inventoryService.deductInventory(orderId));

        try {
            vt.join(); // VT 종료 대기
            // ✅ VT가 블로킹될 때 캐리어 OS Thread를 반납 → Tomcat 풀 고갈 없음
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("업무2 처리 중단", e);
        }

        task3_createShipment(orderId); // Thread-1, Connection-1 계속 사용
    }
}

@Service
class InventoryService {

    @Transactional // REQUIRES_NEW 불필요 — VT는 새 ThreadLocal = 새 Connection
    public void deductInventory(Long orderId) {
        // DB 유니크 제약으로 중복 방지 (멱등성 보장)
        boolean inserted = inventoryRepo.insertDeductionIfNotExists(orderId);
        if (!inserted) throw new DuplicateDeductionException("이미 처리된 주문");

        Inventory inv = inventoryRepo.findByOrderId(orderId);
        inv.deduct();
        inventoryRepo.save(inv);
    }
}

⚠️

Virtual Thread 사용 시 주의: ThreadLocal 데이터 공유 불가

Virtual Thread는 새로운 ThreadLocal 공간을 가지므로, 부모 스레드의 인증 정보(SecurityContext), 요청 컨텍스트 등이 전달되지 않습니다. 필요한 데이터는 명시적으로 전달하거나, ScopedValue(JDK 21+)를 활용하세요.

7실전 설계 — CountDownLatch + UPSERT + SELECT FOR UPDATE

앞서 살펴본 Virtual Thread 기반 해결책에서 한 단계 더 나아간 설계입니다. 핵심 아이디어는 Thread-2를 Lock 전담 스레드로만 쓰는 것입니다. 업무2() 실행은 Thread-1이 직접 하고, Thread-2는 Lock 행만 붙잡고 있다가 신호를 받으면 트랜잭션을 커밋해서 Lock을 자동 해제합니다.

왜 Thread-2가 업무2()를 실행하면 안 되나?

Thread-2가 업무2()까지 처리하면 업무2가 오래 걸릴수록 Thread-1이 계속 대기해야 합니다. Thread-1 입장에서는 Lock을 잡는 시간 (짧음) 만 기다리면 충분합니다. 업무2 실행은 Thread-1이 직접 해야 지연이 없습니다.

Lock의 생명주기가 task2 블록과 정확히 일치하는 원리

LockGuardOptions — 이중 실행 감지 시 동작 옵션

Lock 획득 실패(이중 실행 감지) 시 Thread-1이 어떻게 반응할지를 호출 전에 옵션으로 주입합니다.

LockGuardOptions

public class LockGuardOptions {

    public enum OnDuplicate {
        SKIP,  // 조용히 넘어감 (멱등 처리)
        FAIL   // n초 대기 후 예외 발생
    }

    private final OnDuplicate onDuplicate;
    private final long failWaitMillis; // FAIL 시 대기 시간 (ms)

    public static LockGuardOptions skip() {
        return new LockGuardOptions(OnDuplicate.SKIP, 0);
    }

    public static LockGuardOptions failAfter(long millis) {
        return new LockGuardOptions(OnDuplicate.FAIL, millis);
    }
}

전체 구현 — processOrder()

@Transactional
public void processOrder(Long orderId, LockGuardOptions opts) {

    task1_validateOrder(orderId); // Connection-1 사용

    // ── Latch 준비 ──────────────────────────────────────────
    CountDownLatch thread1Latch = new CountDownLatch(1); // T2 → T1 신호
    CountDownLatch thread2Latch = new CountDownLatch(1); // T1 → T2 신호
    AtomicReference<Exception> lockError = new AtomicReference<>();

    // ── Thread-2: Lock 전담 Virtual Thread ──────────────────
    Thread.ofVirtual().name("lock-guard-" + orderId).start(() -> {
        try {
            // A. UPSERT → 행 생성 or 갱신
            lockRepo.upsertLock(orderId);

            // B. SELECT FOR UPDATE WAIT {n}
            // 다른 세션이 같은 행 잡고 있으면 ORA-30006 발생 → 이중 실행 감지
            lockRepo.selectForUpdateWait(orderId);

            // C. Lock 확보 완료 → Thread-1 깨움
            thread1Latch.countDown();

            // D. Thread-1이 task2() 완료할 때까지 대기 (timeout 없음 — 업무 최우선)
            // 이 동안 Connection-2의 트랜잭션이 열려있어 Lock이 유지됨
            thread2Latch.await();

        } catch (Exception e) {
            lockError.set(e);
            thread1Latch.countDown(); // 에러여도 Thread-1 블로킹 해제
        }
        // E. 메서드 return → @Transactional Proxy가 commit()
        // → SELECT FOR UPDATE Lock 자동 해제 (DELETE 불필요)
    });

    // ── Thread-1: Lock 확보 대기 ────────────────────────────
    thread1Latch.await();

    // ── 이중 실행 감지 처리 ──────────────────────────────────
    Exception err = lockError.get();
    if (err != null) {
        thread2Latch.countDown(); // Thread-2 정리
        if (opts.getOnDuplicate() == OnDuplicate.SKIP) {
            return; // 조용히 넘어감
        }
        Thread.sleep(opts.getFailWaitMillis()); // n ms 대기 후 예외
        throw new DuplicateExecutionException("이미 처리 중인 요청입니다", err);
    }

    // ── task2 보호 구간 ──────────────────────────────────────
    // try/finally가 핵심: 성공/예외/롤백/인터럽트 무관하게 Thread-2를 반드시 깨움
    try {
        task2_deductInventory(orderId); // Thread-1이 직접 실행 (Connection-1)
    } finally {
        thread2Latch.countDown(); // ✅ Thread-2 깨움 → 커밋 → Lock 자동 해제
    }

    task3_createShipment(orderId); // Lock과 무관, Connection-1 계속 사용
}

try/finally가 보장하는 것

task2 정상 완료 → countDown() → Thread-2 커밋 → Lock 해제
task2 예외 발생 → countDown() → Thread-2 커밋 → Lock 해제 → @Transactional 롤백
HTTP timeout 인터럽트 → countDown() → Thread-2 커밋 → Lock 해제 → Thread-1 롤백
JVM 크래시 → Java finally도 실행 불가, 그러나 Oracle 세션 자체가 끊겨 Lock 자동 해제

SELECT FOR UPDATE WAIT {n} 의 역할

Oracle SQL — Lock 획득 쿼리

-- UPSERT: 행이 없으면 INSERT, 있으면 touched_at 갱신
MERGE INTO execution_lock el
USING (SELECT :orderId AS order_id FROM dual) src
ON (el.order_id = src.order_id)
WHEN NOT MATCHED THEN
    INSERT (order_id, created_at) VALUES (:orderId, SYSDATE)
WHEN MATCHED THEN
    UPDATE SET el.touched_at = SYSDATE;

-- SELECT FOR UPDATE WAIT {n}
-- 다른 세션이 같은 행을 잡고 있으면 n초 대기 후 ORA-30006 발생
-- n = 이중 실행을 얼마나 빨리 감지할지 결정하는 값 (보통 0~3초)
SELECT order_id FROM execution_lock
WHERE order_id = :orderId
FOR UPDATE WAIT 3;

⚠️

WAIT {n} 값 설정 기준

너무 짧으면 (WAIT 0 = NOWAIT) — 정상적인 첫 번째 요청이 아직 Lock을 잡기 전에 두 번째 요청이 도달해서 false positive 발생 가능
너무 길면 — 이중 실행 감지까지 오래 걸려 Connection-2를 오래 점유
권장 — 업무2()의 시작까지 걸리는 시간보다 약간 길게 설정 (보통 1~3초)

Oracle의 세션 종료 시 동작 — 주의사항

Thread-1이 비정상 종료될 때 Oracle이 자동 롤백을 해주는지 궁금할 수 있습니다. 결론은 "상황에 따라 다르며, 의존하면 위험합니다."

종료 방식	Oracle 동작	안전 여부
HTTP timeout → Thread 인터럽트	Java finally가 실행되어 명시적 롤백 + countDown()	✅ 안전 (finally 보장)
DBA가 세션 KILL	Oracle이 해당 세션 트랜잭션 자동 롤백	✅ 안전
Connection Pool removeAbandoned	Oracle에서 close()가 커밋으로 처리될 수 있음	❌ 위험 — 설정 주의
JVM 크래시	Oracle 세션 끊김으로 자동 롤백	✅ 안전 (Oracle 보장)

HikariCP removeAbandoned 주의

Thread-2가 thread2Latch.await()로 오래 블로킹되면 HikariCP가 Connection-2를 "유기된 커넥션"으로 판단할 수 있습니다. 이때 강제 close()가 호출되면 Oracle에서는 롤백 대신 커밋이 될 수 있습니다. keepaliveTime과 maxLifetime을 업무2의 예상 최대 실행 시간보다 충분히 길게 설정하세요.

8공통 백엔드 개발자가 꼭 알아야 할 원리 정리

① 스레드와 상태 격리 원리

개념	핵심 이해	실제 적용
`ThreadLocal`	스레드 로컬 변수 — 스레드마다 별도 공간	Spring 트랜잭션, MDC 로깅, SecurityContext 저장
스레드 풀 재사용	스레드가 재사용될 때 ThreadLocal이 남아있을 수 있음	`finally` 블록에서 반드시 ThreadLocal 초기화
스레드 경계	트랜잭션은 스레드 경계를 넘지 않음	비동기(@Async) 사용 시 트랜잭션 전파 안 됨을 이해

② 트랜잭션 설계 원칙

원칙	내용
트랜잭션은 짧게	트랜잭션이 긴 시간 열려있으면 Lock이 길게 유지되고 Connection을 점유합니다. HTTP 호출, 외부 API 등은 트랜잭션 밖으로 빼세요.
경계를 명확히	어디서 트랜잭션이 시작되고 끝나는지 항상 추적하세요. @Transactional이 붙었다고 항상 새 트랜잭션인 건 아닙니다 (REQUIRED 전파).
읽기와 쓰기 분리	조회 전용은 `@Transactional(readOnly = true)`로 최적화하세요. 불필요한 쓰기 Lock을 피하고 성능이 향상됩니다.
멱등성 설계	재시도가 발생해도 같은 결과가 나오도록 설계하세요. UPSERT, 유니크 제약 조건, 처리 상태 플래그를 활용하세요.

③ Connection Pool 설계

HikariCP 핵심 설정

# application.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 10       # 권장: (CPU코어×2) + 디스크수
      connection-timeout: 30000   # 30초 초과 시 예외
      minimum-idle: 5
      max-lifetime: 1800000      # 30분 (DB wait_timeout보다 짧게)
      connection-test-query: SELECT 1

HikariCP 공식 권장 공식

connections = (CPU 코어 수 × 2) + 디스크 수 — 예: 4코어 서버 + SSD 1개 → 최적 Pool 사이즈 = 9. 너무 많은 Connection이 오히려 Lock 경합과 컨텍스트 스위칭 비용으로 성능을 저하시킵니다.

④ 동시성 제어 전략 비교

방법	장점	단점	적합한 상황
낙관적 락 `@Version`	Lock 없이 충돌 감지, 읽기 성능 우수	충돌 시 재시도 로직 필요	충돌 빈도가 낮을 때
비관적 락 SELECT FOR UPDATE	강력한 일관성 보장	Lock 대기로 처리량 저하, 데드락 위험	충돌이 자주 발생할 때
분산 Lock Redis/Zookeeper	다중 서버 환경에서 동작	인프라 추가, TTL/Heartbeat 관리	여러 서버가 공유 자원에 접근
DB 유니크 제약	단순하고 강력, DB가 보장	삽입-삭제 패턴에만 적용 가능	중복 처리 방지 (멱등성)

⑤ 다음으로 공부할 토픽

트랜잭션 격리 수준

READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE — Phantom Read, Dirty Read의 차이

️

SAGA 패턴

마이크로서비스에서 분산 트랜잭션을 대체하는 패턴. Choreography vs Orchestration 방식

Outbox 패턴

DB 저장과 메시지 발행의 원자성 보장. 이중 쓰기 문제 해결

Project Loom 심화

Carrier Thread, Pinning, ScopedValue, StructuredConcurrency

MVCC

PostgreSQL/MySQL의 다중 버전 동시성 제어. Snapshot Isolation 내부 동작

⚡

R2DBC / Reactive

논블로킹 DB 접근. Virtual Thread와의 차이점과 각각의 장단점 비교

핵심 5줄 요약

1. ThreadLocal이 같은 스레드 내 Connection을 공유하게 한다.
2. @Transactional은 AOP Proxy가 Connection 획득-커밋/롤백-반납을 대신한다.
3. 스레드 풀 스레드는 블로킹되면 안 된다 — Thread.join()은 OS 스레드를 잡는다.
4. Virtual Thread는 새로운 ThreadLocal = 새 Connection = 독립 트랜잭션이다.
5. 트랜잭션 설계는 "어느 Connection이, 언제, 어떤 Lock을 잡는가"를 항상 추적해야 한다.

개발이군고구마

[리눅스 심화 ②] 패킷은 어떻게 흐르는가: 소켓부터 컨테이너 네트워크까지

0. 들어가며: 네트워크도 결국 파일과 프로세스다

1. 패킷의 여정: 애플리케이션에서 NIC까지

1.1 OSI 계층과 실무 개념의 매핑

2. 소켓과 포트: 프로세스가 네트워크에 연결되는 접점

2.1 소켓은 파일 디스크립터다

2.2 포트: 하나의 IP 안에서 프로세스를 구분하는 번호

3. ss로 TCP 상태 읽기: LISTEN, ESTABLISHED, TIME_WAIT

3.1 자주 쓰는 ss 명령어

3.2 TCP 연결의 생성과 종료

3.3 실무에서 반드시 구분해야 할 두 상태

4. iptables와 NAT: 컨테이너가 외부와 통신하는 원리

4.1 iptables란

4.2 NAT: 주소를 바꿔치기하는 L3 기술

5. DNS 조회 흐름: 이름이 IP로 바뀌는 과정

5.1 조회 순서

5.2 핵심 설정 파일

6. 종합: 컨테이너 네트워크는 어떻게 완성되는가

7. 실무 트러블슈팅 체크리스트

[리눅스 심화 ①] 프로세스는 어떻게 태어나고, 격리되고, 컨테이너가 되는가

0. 들어가며: 왜 프로세스를 더 깊이 봐야 하는가

1. 프로세스는 어떻게 태어나는가: fork()와 exec()

1.1 리눅스에는 "그냥 실행"이 없다

1.2 fork(): 자기 자신을 복제함

1.3 exec(): 자신을 다른 프로그램으로 덮어씀

1.4 fork + exec: 셸이 명령어를 실행하는 방식

2. 프로세스의 생애주기: 상태와 좀비의 정체

2.1 프로세스의 5가지 핵심 상태

2.2 좀비 프로세스(Zombie): 오해와 진실

2.3 고아 프로세스(Orphan)와 systemd의 입양

3. 프로세스의 메모리 구조와 우선순위

3.1 프로세스 메모리 레이아웃 (간단히)

3.2 우선순위: nice 값

4. namespace: 프로세스가 "볼 수 있는 세계"를 격리함

4.1 namespace의 종류

4.2 이게 왜 강력한가

4.3 실무에서 namespace 들여다보기

5. cgroup: 프로세스가 "쓸 수 있는 자원의 양"을 제한함

5.1 cgroup이란

5.2 OOM Killer와의 연결

5.3 실무에서 cgroup·OOM 확인하기

6. 결론: 컨테이너는 마법이 아니라 프로세스다

7. 실무 트러블슈팅 체크리스트

리눅스 운영체제

1. 리눅스의 근본 철학: "모든 것은 파일이다"

2. 파일 디스크립터(File Descriptor): 0, 1, 2의 정체

2.1 파일 디스크립터란

2.2 0, 1, 2는 예약된 자리

2.3 왜 stdout과 stderr를 나눴는가

3. 표준 스트림과 리다이렉션: catalina.out의 비밀

3.1 기본 리다이렉션 기호

3.2 2>&1을 정확히 읽는 법

3.3 /dev/null: 출력 버리기

3.4 이제 catalina.out을 해석함

4. 프로세스(Process): 실행 중인 프로그램의 실체

4.1 프로세스의 정의

4.2 프로세스는 나무처럼 이어짐 (부모-자식)

4.3 프로세스 확인 명령어

4.4 시그널(Signal): 프로세스에게 보내는 신호

5. 데몬과 백그라운드 실행: nohup, &, 그리고 그 한계

5.1 데몬(Daemon)이란

5.2 &와 nohup: 초보가 서비스를 띄우는 방식

5.3 nohup.out은 왜 생기는가 (그리고 왜 위험한가)

5.4 nohup/& 방식의 근본적 한계

6. systemd: 현대 리눅스의 서비스 관리자

6.1 systemd의 위치

6.2 유닛 파일(Unit File): 서비스의 설계도

6.3 systemctl: 서비스 제어 명령어

6.4 journalctl: systemd의 로그 조회

7. 로그와 디스크: 왜 서버가 꽉 차는가 (logrotate)

7.1 logrotate란

7.2 catalina.out을 위한 설정 예시

7.3 copytruncate가 중요한 이유

8. 권한과 소유권: 운영의 기본 안전장치

8.1 소유권과 권한 3분할

8.2 숫자(8진수) 표기

9. 셸과 환경: 명령어가 실행되는 맥락

9.1 셸(Shell)이란

9.2 환경 변수(Environment Variable)

3.2 `2>&1`을 정확히 읽는 법

3.3 `/dev/null`: 출력 버리기

5.2 `&`와 nohup: 초보가 서비스를 띄우는 방식

7.3 `copytruncate`가 중요한 이유

9.3 파이프(`|`)와 명령어 조합