Technical Architect

Java - 02. types

dongka — Fri, 10 Jul 2026 17:39:07 +0900

`==`가 `true`이기도 하고 `false`이기도 한 이유 — Java 타입 시스템의 두 세계

다음 코드를 보자.

// Java 25
Integer a = 127;
Integer b = 127;
System.out.println(a == b);   // (1)

Integer c = 200;
Integer d = 200;
System.out.println(c == d);   // (2)

(1)은 true, (2)는 false다. 같은 == 연산자인데, 값이 127일 때와 200일 때 결과가 다르다. 이게 말이 되는가?

이 미스터리를 풀려면 한 가지를 알아야 한다 — Java에는 데이터를 저장하는 두 가지 방식이 있다는 것. 이 두 방식의 차이가 ==의 동작을 결정하고, null의 의미를 결정하고, 성능과 메모리 사용량까지 결정한다. 이 글은 이 두 세계를 하나씩 풀어가며, 처음의 미스터리를 해결한다.

두 가지 저장 방식 — "값"과 "주소"

Java의 모든 변수는 값을 직접 들고 있거나, 값이 있는 곳의 주소를 들고 있다. 이게 전부다. 이 두 가지를 Java는 각각 primitive 타입과 reference 타입이라 부른다.

쉽게 비유하자면:

primitive는 지갑에 현금을 넣는 것이다. int x = 5000이면 지갑에 5000원이 직접 들어있다. 돈을 확인하려면 지갑을 열면 된다.
reference는 지갑에 체크카드를 넣는 것이다. String name = "Alice"는 지갑에 카드가 있고, 카드는 계좌(객체)를 가리킨다. 잔액을 확인하려면 카드를 읽어서 계좌에 가봐야 한다.

이 차이가 왜 중요한가? ==로 두 변수를 비교할 때:

현금(primitive)끼리 비교하면 → 금액이 같은지 본다. 5000원과 5000원은 같다.
카드(reference)끼리 비교하면 → 같은 계좌를 가리키는지 본다. 다른 두 카드가 같은 잔액을 가져도, 다른 카드면 false다.

이것이 ==가 혼란스러운 이유다. primitive에서는 "값이 같은가?"를 묻지만, reference에서는 "같은 객체인가?"를 묻는다.

primitive — 현금처럼 값 자체를 저장하는 8가지

Java는 8개의 primitive 타입을 정의한다. (JLS §4.1)

타입	크기	범위	언제 쓰나
`int`	32-bit	약 ±21억	정수의 기본. 웬만하면 이걸 쓴다
`long`	64-bit	약 ±920경	큰 숫자. `L` 붙임: `10000000000L`
`double`	64-bit	소수	실수의 기본
`boolean`	—	`true`/`false`	조건. 크기 명세 없음
`char`	16-bit	0~65535	글자 하나. 부호 없는 정수이기도 함
`byte`	8-bit	-128~127	이진 데이터 (파일, 네트워크)
`short`	16-bit	±3만	거의 안 씀
`float`	32-bit	소수	거의 안 씀. `double` 쓰자

primitive 변수는 메모리에 값 자체를 저장한다. int x = 42라고 하면, 그 메모리 칸에는 42라는 숫자가 직접 들어간다. "42를 가리키는 주소"가 아니라 42 자체다.

정수에 끝이 있다 — 오버플로우

int의 최대값은 2,147,483,647(약 21억)이다. 이걸 넘으면 어떻게 될까?

int max = 2147483647;
System.out.println(max + 1);   // -2147483648

예외가 안 난다. 조용히 음수가 된다. 자동차 주행거리계가 999,999에서 0으로 돌아가는 것과 같다 — 한 바퀴 돌아서 최소값으로 간다.

이게 왜 위험한가? 은행에서 잔액이 21억에서 1원이 입금됐는데 -21억이 되는 상황을 상상해 보자. 금액 계산에는 Math.addExact()를 쓰면 — 초과 시 ArithmeticException을 던져서 즉시 알려준다.

`0.1 + 0.2`는 `0.3`이 아니다

System.out.println(0.1 + 0.2 == 0.3);   // false
System.out.println(0.1 + 0.2);         // 0.30000000000000004

이건 Java의 버그가 아니다. 컴퓨터가 0.1을 이진수로 표현할 때 정확히 맞아떨어지지 않기 때문이다. 10진수로 1/3을 정확히 표현할 수 없는 것과 같은 이치다.

돈 계산에는 double을 쓰지 마라. BigDecimal을 쓴다:

// Java 25
import java.math.BigDecimal;

BigDecimal a = new BigDecimal("0.1");   // String으로!
BigDecimal b = new BigDecimal("0.2");
System.out.println(a.add(b));           // 0.3 (정확)

new BigDecimal("0.1")에서 문자열을 쓰는 이유: new BigDecimal(0.1)은 이미 부정확한 double 값을 받아들이기 때문이다. 0.1이라고 써도 0.1000000000000000055...로 해석된다.

reference — 카드처럼 주소를 저장하는 세계

String, ArrayList, 우리가 만든 클래스 — 이들은 모두 reference 타입이다. 변수가 객체 자체가 아니라 객체의 주소를 들고 있다.

flowchart LR
    subgraph stack["변수 공간 (Stack)"]
        X["int x = 42<br/>(값이 직접 있음)"]
        S["String s<br/>(주소만 있음)"]
    end
    subgraph heap["객체 공간 (Heap)"]
        O["String 객체<br/>값: &quot;Hello&quot;"]
    end
    S -->|"이쪽에 있음"| O

int x = 42는 x 칸에 42가 있다. String s = "Hello"는 s 칸에 "Hello"가 있는 게 아니라 — "Hello 객체는 heap의 이 주소에 있어"라는 안내판이 있다. 실제 "Hello"는 heap이라는 별도 영역에 있다.

`==`가 다시 문제된다

이제 ==가 왜 위험한지 보인다:

String s1 = new String("hello");
String s2 = new String("hello");
System.out.println(s1 == s2);        // false — 다른 객체(다른 주소)
System.out.println(s1.equals(s2));   // true — 내용은 같음

s1과 s2는 둘 다 "hello"라는 같은 내용을 가진 객체를 가리킨다. 하지만 서로 다른 객체다. ==는 주소를 비교하므로 false. .equals()는 내용을 비교하므로 true.

규칙이 하나 있다: reference 타입을 비교할 때는 항상 .equals()를 쓴다. ==는 primitive에만.

미스터리 해결 — Integer 캐싱

이제 처음의 퍼즐로 돌아가자.

Integer a = 127;   // Integer는 reference 타입 (wrapper)
Integer b = 127;
System.out.println(a == b);   // true (?!)

Integer c = 200;
Integer d = 200;
System.out.println(c == d);   // false

Integer는 int의 wrapper 클래스다. int는 primitive(값)이고, Integer는 reference(객체)다. Java 5부터 Integer a = 127이라고 쓰면 컴파일러가 자동으로 Integer.valueOf(127)로 변환한다(오토박싱).

이 valueOf 메서드가 바로 범인이다. (Integer.valueOf API) 내부 코드를 보면:

// Integer.valueOf의 내부 동작 (단순화)
private static final Integer[] cache = new Integer[256];

public static Integer valueOf(int i) {
    if (i >= -128 && i <= 127) {
        return cache[i + 128];   // 미리 만들어둔 객체 재사용
    }
    return new Integer(i);        // 범위 밖 → 새 객체 매번 생성
}

즉, -128에서 127 사이의 숫자는 미리 객체를 만들어두고 재사용한다. 127을 요청하면 항상 같은 객체를 돌려준다. 그래서 a == b가 true — 둘이 같은 객체를 가리키니까.

하지만 200은 캐시 범위 밖이다. valueOf(200)을 부를 때마다 새로운 객체를 만든다. c와 d는 다른 객체 → ==가 false.

비유: 편의점에서 "물"을 사면, 진열대에 미리 채워둔 물(캐시)을 준다 — 두 사람이 물을 사면 같은 진열대에서 줘서 "같은 물"이다(127). 하지만 "한정판 음료"(200)는 주문할 때마다 새로 만들어 주니까, 두 개는 "다른 병"이다.

왜 하필 -128~127인가? 이 범위의 숫자가 프로그래밍에서 가장 빈번하게 쓰이기 때문이다 (루프 인덱스, 작은 카운터 등). 자주 쓰는 객체를 미리 만들어두어 성능을 높이려는 설계다. (JLS §5.1.7)

실전에서 왜 문제인가

이 캐싱은 테스트에서는 통과하고 프로덕션에서 터진다. 테스트할 때는 ID가 1, 2, 3 같은 작은 값이니까 ==가 우연히 true. 프로덕션에서 ID가 9,999가 되면 갑자기 false. "테스트에서 됐는데요?"라는 말이 나오는 순간이다.

해결책은 단순하다: wrapper 타입(Integer, Long, Double)을 비교할 때는 항상 .equals(). 규칙은 하나다.

실전 시나리오 — ID 비교 버그

// 실제 발생할 수 있는 버그 패턴
class UserService {
    private Map<Long, User> cache = new HashMap<>();

    public boolean isCached(Long userId) {
        // 개발 중: userId가 1, 2, 3 → 캐시 범위 → == 로 우연히 동작
        // 프로덕션: userId가 98765 → 캐시 범위 밖 → == 실패
        return userId == getLastAccessedId();   // 버그!
    }

    public boolean isCachedSafe(Long userId) {
        return userId.equals(getLastAccessedId());   // 정확
    }
}

이 패턴이 위험한 이유는 — 개발 환경에서 ID가 작은 값일 때는 "잘 되는데?"라고 넘어가기 때문이다. 코드 리뷰에서도 ==와 .equals()의 차이를 놓치기 쉽다.

오토박싱의 숨은 비용

Long sum = 0L;   // Long (wrapper) — primitive long이 아님!
for (int i = 0; i < 1000000; i++) {
    sum += i;    // 매번: 객체 열기(언박싱) → 더하기 → 새 객체 만들기(박싱)
}

Long은 long이 아니다. Long은 객체이므로, sum += i를 할 때마다 (1) 객체에서 long 값 꺼내기, (2) 더하기, (3) 결과로 새 Long 객체 생성이 일어난다. 100만 번의 루프에서 100만 개의 쓰레기 객체가 만들어진다 — GC가 청소하느라 CPU를 낭비한다.

해결: long sum = 0L; (primitive). 단 한 글자 차이지만 성능은 수십 배 다르다.

형변환 — 큰 그릇에서 작은 그릇으로

Java에서 타입을 바꾸는 것을 형변환(casting)이라 한다. (JLS §5)

작은 것 → 큰 것 (widening): 데이터 손실이 없으니 컴파일러가 알아서 해준다.

int i = 42;
long l = i;       // OK: int(32비트)를 long(64비트)에 넣기 — 남는 공간이 충분

큰 것 → 작은 것 (narrowing): 데이터가 잘릴 수 있으니 "정말 할 거야?"라고 명시해야 한다.

double d = 3.99;
int i = (int) d;   // (int) 캐스트: 소수점 버림 → i = 3

비유하자면: 1L 주전자의 물을 2L 주전자에 붓는 건 문제없다(widening). 2L 주전자의 물을 1L 주전자에 붓는 건 넘친다(narrowing) — "알고 있다"고 (int)로 명시해야 컴파일러가 허락한다.

참조 타입의 캐스트 — 안전하게

Object obj = "Hello";
// Integer num = (Integer) obj;   // ClassCastException! "Hello"는 Integer가 아니다

// Java 16+ 안전한 방법
if (obj instanceof String s) {   // 타입 확인 + 변수 바인딩 동시에
    System.out.println(s.length());
}

(JEP-394) instanceof String s는 "obj가 String이면 s에 넣어라" — 확인과 캐스트를 한 번에 한다.

`var` — 타입을 생략하면 컴파일러가 추론한다

Java 10부터 var 키워드로 타입을 생략할 수 있다. (JEP-286)

var name = "Alice";           // String으로 추론
var count = 42;               // int로 추론
var users = List.of("A","B"); // List<String>으로 추론

오해하지 마라: var은 JavaScript의 var과 다르다. 동적 타입이 아니다. 컴파일 타임에 타입이 고정된다. var name = "Alice"는 String name = "Alice"와 바이트코드가 동일하다. var은 단지 타입을 적기 귀찮을 때 쓰는 단축키일 뿐이다.

주의: 타입이 명확하지 않으면 var이 독이 된다.

var result = process(data);   // result의 타입이 뭔지 코드만 보고 모름
var x = 0;                    // int인데, long이 의도였다면?

초기화식의 타입이 한눈에 보이면 var을 쓰고, 메서드 반환값처럼 "뭔지 알아내야 하는" 경우는 명시적 타입을 쓴다.

초기화되지 않은 변수 — Java의 안전망

Java는 "초기화 안 된 변수"를 사용하지 못하게 막는다.

void method() {
    int x;
    // System.out.println(x);  // 컴파일 에러: x를 초기화 안 했음
    x = 42;
    System.out.println(x);      // OK
}

C/C++에서는 초기화 안 된 변수에 "쓰레기값"이 들어있어서 버그의 온상이었다. Java는 컴파일 타임에 이것을 막는다 — 안전망이다.

다만 필드(클래스의 멤버 변수)는 자동으로 기본값(0, false, null)으로 초기화된다. 지역 변수는 자동 초기화가 안 되므로 명시적으로 초기화해야 한다.

분류	기본값
숫자 (`int`, `long`, `double` 등)	`0`
`boolean`	`false`
`char`	`'\u0000'` (null 문자)
reference (`String`, `List` 등)	`null`

reference 타입의 기본값이 null이라는 것이 함정이다. 필드로 private List<Order> orders;를 선언하고 초기화하지 않으면, orders는 null이다. 이 상태에서 orders.add(...)를 부르면 NullPointerException. "선언만 하고 안 넣었으면 빈 리스트여야 하는 거 아닌가?"라고 생각할 수 있지만 — Java는 null과 빈 컬렉션을 구분한다. private List<Order> orders = new ArrayList<>();로 명시적 초기화가 필요하다.

요약 — 이 글의 결론

Java에는 두 세계가 있다. primitive는 값 자체를, reference는 객체의 주소를 저장한다. ==는 primitive에서는 "값이 같나?"를, reference에서는 "같은 객체인가?"를 묻는다.
wrapper 비교에는 항상 .equals()를 쓴다. Integer ==가 127에서는 true, 200에서는 false인 이유는 캐싱 때문이다. 이 버그는 작은 숫자로 테스트하면 잡히지 않는다.
정수에는 끝이 있다. 21억을 넘으면 조용히 음수가 된다. 금액 계산에는 Math.addExact()로 방어한다.
0.1 + 0.2 != 0.3이다. 돈 계산에는 BigDecimal(String)을 쓴다.
var은 동적 타입이 아니다. 컴파일 타임에 타입이 고정되는 단축키다. 타입이 명확할 때만 쓴다.

생각해 볼 문제

Double a = 0.0 / 0.0;의 값은 무엇인가? a == a의 결과는? (NaN은 자기 자신과도 같지 않다.)
char c = 65; System.out.println(c);의 출력은? (힌트: char는 부호 없는 정수이기도 하다.)
Long sum = 0L 루프와 long sum = 0L 루프의 실행 시간을 비교해 보자. 얼마나 차이가 나는가?
var list = new ArrayList<>();에서 list의 원소 타입은 무엇으로 추론되는가?
-XX:AutoBoxCacheMax=1000으로 캐싱 범위를 늘리면 Integer a = 500; Integer b = 500; a == b의 결과는?

참고

JLS §4 - Types, Values, and Variables - 접근 2026-07-10
JLS §5 - Conversions and Contexts - 접근 2026-07-10
Integer.valueOf API (Java 25) - 접근 2026-07-10
JEP-286: Local-Variable Type Inference - 접근 2026-07-10
JEP-394: Pattern Matching for instanceof - 접근 2026-07-10

Java - 01. intro

dongka — Fri, 10 Jul 2026 17:31:20 +0900

`java Hello.java`가 숨기고 있는 것 — JVM, 바이트코드, 그리고 "한 번 쓰면 어디서나"의 진짜 의미

Java 11부터 java Hello.java 한 줄로 프로그램을 바로 실행할 수 있게 됐다. (JEP-330) 파일을 저장하고 java 명령 하나면 끝난다. 이 명령이 내부적으로 무엇을 하는지 모른 채 써도 프로그램은 잘 돌아간다.

문제는 여기서 시작된다. "Java는 컴파일 언어인가 인터프리터 언어인가?"라는 질문에 답하지 못하는 것은, 단계를 건너뛰었기 때문이다. javac가 .java 파일을 무엇으로 바꾸는지, JVM이 그 결과물을 어떻게 실행하는지, "Write Once Run Anywhere"가 마케팅 구호가 아니라 정밀한 기술적 설계임을 이해하지 못하면 — GC 튜닝, 클래스 로딩 에러, 버전 호환성 문제가 발생했을 때 원인을 추적할 수 없다.

이 글은 java Hello.java가 숨기는 두 단계 — 소스 코드에서 바이트코드, 바이트코드에서 기계어 — 를 직접 들여다본다. JDK와 JVM이 정확히 무엇이고, Java 11에서 "JRE"를 다운로드할 수 없는 이유는 무엇이며, .class 파일에 담긴 바이트코드가 어떻게 Linux, macOS, Windows에서 같은 의미로 실행되는지를 다룬다.

JDK, JRE, JVM — 세 개를 구분해야 하는 이유

Java를 처음 설치할 때 마주치는 혼란: JDK, JRE, JVM 중 무엇을 설치해야 하는가? Java 11 이전 튜토리얼은 "JRE만 필요하면 JRE를 설치하고, 개발하려면 JDK를 설치하라"고 안내한다. 이 안내는 Java 11부터 틀렸다.

flowchart TD
    JDK["JDK (Java Development Kit)<br/>javac, java, jshell, jlink 등<br/>+ JRE 포함 (Java 10까지)"]
    JDK --> JRE["JRE (Java Runtime Environment)<br/>JVM + core library<br/>별도 다운로드: Java 10까지만"]
    JRE --> JVM["JVM (Java Virtual Machine)<br/>바이트코드 → 기계어 실행<br/>spec, 구현은 다양"]

Oracle은 Java 11부터 JRE를 별도로 제공하지 않는다. (Oracle Java 11 릴리스 노트) JDK가 유일한 배포판이다. "실행만 하려면 JRE"라는 구분이 사라진 것 — 더 이상 "개발 도구 없이 실행 환경만" 제공하는 패키지를 다운로드할 수 없다.

대신 Java 9에서 도입된 jlink로 필요한 모듈만 포함한 사용자 정의 런타임 이미지를 생성할 수 있다. (JEP-282) JRE 대신 더 정밀한 방식 — 애플리케이션이 사용하는 모듈만 추려서 경량 런타임을 만든다.

각각이 무엇인가

구성	포함하는 것	역할
JVM	실행 엔진(인터프리터 + JIT 컴파일러), GC, 클래스 로더	바이트코드를 읽고 기계어로 실행. 사양(spec)은 있고 구현은 다양(HotSpot, OpenJ9, GraalVM)
JRE	JVM + core library(`java.base`, `java.util` 등)	Java 프로그램 실행 환경. Java 10까지 별도 배포, Java 11부터 JDK에 통합
JDK	JRE + 개발 도구(`javac`, `jshell`, `jdb`, `jlink`, `jar` 등)	개발·컴파일·디버깅. Java 11부터 유일한 배포판

JVM은 소프트웨어가 아니라 명세다. (JVM Specification) 이 명세를 구현한 것이 HotSpot(OpenJDK/Oracle JDK 기본), Eclipse OpenJ9(IBM 계열), GraalVM(Oracle, AOT 컴파일 지원) 등이다. "JVM"이라는 말이 HotSpot을 지칭하는 경우가 많지만, 엄밀히는 구현이 아니라 명세다.

컴파일 — `.java`에서 `.class`로

Java 소스 코드가 실행되려면 두 단계를 거친다. 첫 번째는 javac가 .java 파일을 .class 파일(바이트코드)로 컴파일하는 것이다.

flowchart LR
    SRC["Hello.java<br/>(소스 코드)"] -->|javac| CLS["Hello.class<br/>(바이트코드)"]
    CLS -->|java| JVM["JVM<br/>(인터프리터 + JIT)"]
    JVM -->|실행| OUT["콘솔 출력"]

전통적인 방식으로 컴파일과 실행을 분리해 보자:

// Java 25 — Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, Java 25");
    }
}

# 1단계: 컴파일 (.java -> .class)
javac Hello.java

# 2단계: 실행 (.class를 JVM에 로드)
java Hello

Hello, Java 25

javac Hello.java를 실행하면 Hello.class 파일이 생성된다. 이 파일은 소스 코드가 아니다 — 바이트코드(bytecode)라는 중간 표현이다. .class 파일을 텍스트 편집기로 열면 읽을 수 없지만, javap로 역어셈블하면 내용을 볼 수 있다:

# Hello.class의 바이트코드 역어셈블
javap -c Hello

Compiled from "Hello.java"
public class Hello {
  public Hello();
    Code:
       0: aload_0
       1: invokespecial #1  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: getstatic     #7  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #13 // String Hello, Java 25
       5: invokevirtual #15 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
}

getstatic, ldc, invokevirtual — 이것들이 JVM이 이해하는 명령어(바이트코드 opcode)다. (JVM Spec §6.5 - Opcode 정의) 각 opcode는 1바이트로 표현되며, JVM이 실행할 수 있는 기본 단위다.

javap는 JDK에 포함된 도구다. 별도 설치 불필요. javap -c는 바이트코드, javap -v는 상수 풀(constant pool)까지 포함한 전체 덤프, javap -p는 private 멤버까지 표시.

`--release` 플래그 — 컴파일 타임과 런타임 버전 불일치 함정

Java 9부터 javac --release N 플래그가 도입됐다. 구버전용 -source/-target 조합을 대체하며, 더 안전한 크로스 컴파일을 보장한다.

# Java 25 컴파일러로 Java 17 호환 바이트코드 생성
javac --release 17 Hello.java

# 구 방식 (Java 8 시절) — 위험: 컴파일은 되지만 런타임에 NoSuchMethodError 가능
javac -source 17 -target 17 Hello.java

-source/-target은 바이트코드 버전만 지정할 뿐, 컴파일러가 참조하는 API는 현재 JDK(Java 25)의 API다. Java 25에서 추가된 메서드를 쓰고 -target 17로 컴파일하면, 바이트코드는 Java 17 호환이지만 Java 17 런타임에서 NoSuchMethodError가 발생한다. --release 17은 컴파일러가 Java 17의 API만 참조하므로 이 문제를 원천 차단한다.

바이트코드가 존재하는 이유 — 플랫폼 독립성

C/C++는 소스 코드를 각 OS의 기계어로 직접 컴파일한다. Linux에서 컴파일한 바이너리는 Windows에서 실행되지 않는다. Java는 다른 길을 택했다 — 모든 플랫폼에서 동일한 바이트코드를 생성하고, 각 플랫폼의 JVM이 바이트코드를 해당 기계어로 번역한다.

단계	C/C++	Java
컴파일 대상	OS별 기계어(x86-64, ARM 등)	플랫폼 독립 바이트코드
실행	OS가 기계어 직접 실행	JVM이 바이트코드를 기계어로 번역(인터프리터 + JIT) 후 실행
결과물 이식성	컴파일 환경에 종속	`.class` 파일은 어느 OS의 JVM에서든 실행

"Write Once Run Anywhere(WORA)"는 마케팅 구호가 아니다 — 바이트코드라는 중간 단계를 두어 컴파일 결과물(.class)이 OS에 종속되지 않는다는 정확한 기술적 설계를 가리키는 말이다. 물론 JVM 자체는 OS별로 다르다(Linux용 JVM, Windows용 JVM). 하지만 같은 Hello.class를 어느 JVM에서든 실행할 수 있다.

이 설계의 대가: 직접 기계어로 컴파일하는 C/C++에 비해 실행 시 추가 번역 단계(JVM)가 필요하다. 이 대가를 줄이기 위해 JIT 컴파일러가 존재한다(아래).

JVM이 바이트코드를 실행하는 방식 — 인터프리터와 JIT의 이중 구조

JVM이 .class 파일의 바이트코드를 읽어 실행하는 과정은 단순한 인터프리터가 아니다. 두 가지 실행 방식을 상황에 따라 혼합한다.

flowchart TD
    LOAD["1. 클래스 로딩<br/>ClassLoader가 .class 로드"] --> VERIFY["2. 바이트코드 검증<br/>Verifier가 타입 안전성 확인"]
    VERIFY --> INTERP["3. 인터프리터 실행<br/>(초기: 모든 코드를 한 줄씩 해석)"]
    INTERP -->|"자주 실행되는 코드 감지<br/>(hot spot)"| JIT["4. JIT 컴파일<br/>HotSpot → 네이티브 기계어"]
    JIT --> NATIVE["5. 네이티브 코드 실행<br/>(이후 해당 코드는 기계어로 직행)"]

인터프리터는 바이트코드를 한 줄씩 읽어 기계어로 번역하며 실행한다. 장점은 즉시 실행(컴파일 대기 없음), 단점은 같은 코드를 반복 번역한다는 것 — 루프가 10,000번 돌면 같은 바이트코드를 10,000번 해석한다.

JIT(Just-In-Time) 컴파일러는 이 비효율을 해결한다. JVM이 실행 중에 "hot spot" — 자주 실행되는 코드 — 를 감지하면, 그 코드를 네이티브 기계어로 한 번에 컴파일한다. 이후 같은 코드를 만나면 인터프리터를 건너뛰고 컴파일된 기계어를 직접 실행한다.

HotSpot JVM(OpenJDK/Oracle JDK의 기본 구현)이라는 이름 자체가 이 메커니즘에서 왔다 — "hot spot"을 찾아 JIT 컴파일하는 JVM. (HotSpot VM 문서)

C1과 C2 — 두 단계 JIT 컴파일러

HotSpot JVM은 두 개의 JIT 컴파일러를 가진다:

JIT 컴파일러	목표	특징
C1 (Client)	빠른 컴파일	적은 최적화, 빠른 시작. 짧은 실행 애플리케이션에 적합
C2 (Server)	극한 최적화	aggressive 인라이닝, 루프 언롤링, escape analysis. 긴 실행 서버 애플리케이션에 적합

Java 8부터 Tiered Compilation이 기본으로 활성화돼 — 처음엔 C1으로 빠르게 컴파일하고, 코드가 충분히 hot 해지면 C2로 다시 컴파일한다. 두 컴파일러의 장점을 모두 취하는 방식이다.

java -version 출력에서 "mixed mode"는 인터프리터 + JIT 혼합을 의미한다. java -Xint -version은 인터프리터 전용(JIT 끔), java -Xcomp -version은 JIT 우선 모드. 성능 차이를 직접 체감할 수 있다.

GC — JVM이 메모리를 회수하는 방식

Java의 핵심 설계 결정 중 하나: 개발자가 메모리를 직접 해제하지 않는다. C/C++의 malloc/free, new/delete에 대응하는 명시적 해제가 Java에는 없다. 대신 Garbage Collector(GC) 가 더 이상 참조되지 않는 객체를 자동으로 회수한다.

이것이 가능한 이유는 JVM이 모든 객체 참조를 추적하고 있기 때문이다 — GC root(스택 변수, static 필드 등)에서 도달할 수 없는 객체는 쓰레기로 판단한다. Java 25에서 기본 GC는 G1 GC이며, ZGC(JEP-439, 세대별 ZGC)와 Shenandoah도 선택 가능하다. GC에 대한 자세한 내용은 24-jvm-gc.md에서 다룬다.

OpenJDK vs Oracle JDK — 어떤 것을 쓸 것인가

"JDK를 설치하라"고 했는데, 어떤 JDK인가? Java 생태계에는 여러 JDK 배포판(distribution)이 있다:

배포판	제공	라이선스	특징
OpenJDK	커뮤니티(Oracle 주도)	GPL v2	Java의 참조 구현. 소스 코드의 단일 출처
Oracle JDK	Oracle	Oracle No-Fee Terms (교육/개발 무료, 프로덕션은 유료 조건)	OpenJDK 기반. 상업 지원 포함
Eclipse Temurin(Adoptium)	Eclipse 재단	GPL v2	OpenJDK 빌드. 커뮤니티 표준 배포판
Amazon Corretto	AWS	GPL v2	OpenJDK 빌드. AWS 환경 최적화
Azul Zulu	Azul	GPL v2 / 상업	OpenJDK 빌드. Zing(상업 GC) 옵션

Java 11부터 Oracle JDK와 OpenJDK는 본질적으로 같은 코드베이스다. (Oracle 발표) Oracle JDK는 상업 지원과 일부 WebStart 등 부가 기능을 더할 뿐, 코어는 동일하다. 프로덕션에서는 OpenJDK 기반 배포판(Temurin, Corretto 등)을 쓰는 것이 일반적이다.

Java 25 LTS — 왜 LTS인가, 무엇이 달라졌나

Java는 6개월마다 새 버전을 릴리스한다. 그중 LTS(Long-Term Support) 버전은 장기 지원(최소 8년 보안 패치)이 보장된다. 비-LTS 버전은 다음 버전 나올 때까지만 지원된다(6개월).

버전	연도	LTS	핵심 변화
Java 8	2014	LTS(종료 연장됨)	Lambda, Stream, Optional
Java 11	2018	LTS	`var`, HttpClient, JEP-330(단일 파일 실행)
Java 17	2021	LTS	Sealed classes, Pattern Matching(switch), record 정식
Java 21	2023	LTS	Virtual Threads(JEP-444), Sequenced Collections, Pattern Matching for switch 정식
Java 25	2025-09	LTS	Compact Object Headers(JEP-519), Scoped Values(JEP-506 finalized), AOT Method Profiling(JEP-515), Module Import Declarations(JEP-511), Flexible Constructor Bodies(JEP-513), Generational Shenandoah(JEP-521)

이 학습서의 기준은 Java 25 LTS다. Spring Framework 7.0 / Spring Boot 4.0의 최소 요구 버전이 Java 17이며, 권장 LTS는 Java 25다. Java 21은 "이전 LTS"로, Java 8/11은 "역사적 환경"으로 다룬다.

실습 — Java 25에서 프로그램 실행하기

사전: Java 25 설치 확인(java -version). 설치되지 않았다면 Adoptium(Temurin)에서 다운로드.

방식 1 — 단일 파일 직접 실행 (Java 11+, JEP-330)

// Java 25 — Hello.java
public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, Java 25");
        System.out.println("JVM: " + System.getProperty("java.vm.name"));
        System.out.println("Java version: " + System.getProperty("java.version"));
    }
}

# 컴파일 없이 직접 실행 (JEP-330, Java 11+)
java Hello.java

Hello, Java 25
JVM: OpenJDK 64-Bit Server VM
Java version: 25

확인할 것: java Hello.java는 내부적으로 (1) 소스를 임시 바이트코드로 컴파일하고 (2) 메모리에 로드하여 실행한다. .class 파일을 디스크에 생성하지 않는다.

[Java 11+] JEP-330으로 도입된 single-file source-code 실행은 학습·프로토타이핑 용도다. 다중 파일 프로젝트는 여전히 javac로 컴파일하거나 빌드 도구(Maven, Gradle)를 써야 한다.

방식 2 — 전통적 컴파일 + 실행

# 1단계: 컴파일 (.class 파일 생성)
javac Hello.java

# .class 파일 확인
ls Hello.class

Hello.class

확인할 것: javac가 .class 파일을 생성한다. 이 파일은 OS에 독립적인 바이트코드다.

# 2단계: 바이트코드 역어셈블로 내부 확인
javap -c Hello

Compiled from "Hello.java"
public class Hello {
  public static void main(java.lang.String[]);
    Code:
       0: getstatic     #7  // Field java/lang/System.out
       3: ldc           #13 // String Hello, Java 25
       5: invokevirtual #15 // Method println
       8: return
}

확인할 것: javap -c가 보여주는 것이 바이트코드다. getstatic, ldc, invokevirtual은 JVM이 실행하는 명령어다.

방식 3 — JShell (Java 9+ REPL)

# Java 25 — 대화형 실험
jshell

|  Welcome to JShell -- Version 25
|  For an introduction type: /help intro

jshell> var name = "Java 25";
name ==> "Java 25"

jshell> System.out.println("Hello, " + name);
Hello, Java 25

jshell> /exit
|  Goodbye

확인할 것: JShell로 컴파일 없이 Java 코드를 즉시 실험할 수 있다. API 동작 확인, 문법 테스트에 유용.

왜 이 구조인가 — Java 설계의 트레이드오프

지금까지의 모든 것이 세 가지 설계 결정으로 요약된다.

왜 바이트코드 중간 단계를 두었나? 직접 기계어로 컴파일하면 이식성을 포기해야 한다. 바이트코드 + JVM 구조는 "컴파일 한 번, 어디서든 실행"을 가능하게 한다. 대가: 실행 시 번역 오버헤드(JIT로 완화).
왜 인터프리터와 JIT를 혼합했나? 인터프리터만 쓰면 느리고, JIT만 쓰면 시작 지연이 길다(모든 코드를 미리 컴파일). 실행 초반은 인터프리터로 빠르게 시작하고, hot spot이 감지되면 JIT로 최적화 — 두 방식의 장점을 취한다.
왜 GC를 언어에 내장했나? 개발자가 메모리 해제를 직접 관리(C/C++ 방식)하면 use-after-free, double-free, memory leak이 빈번한다. GC는 이 클래스의 버그를 원천 제거한다. 대가: GC 실행 시 일시 정지(stop-the-world)와 메모리 오버헤드.

이 세 가지는 독립이 아니다. 바이트코드이기 때문에 JIT가 같은 코드를 반복 최적화할 수 있고, GC가 있기 때문에 객체 참조 추적이 JVM 수준에서 가능하며, 이식성이 확보되기 때문에 같은 GC 알고리즘이 다양한 OS에서 동일하게 동작한다. 하나를 빼면 나머지의 근거가 흔들린다.

요약 — 이 글의 결론

JRE는 Java 11부터 별도 배포되지 않는다. JDK가 유일한 배포판이며, 경량 런타임이 필요하면 jlink로 맞춤형 이미지를 생성한다.
javac가 만드는 .class 파일은 기계어가 아니라 바이트코드다. 이 바이트코드는 OS에 독립적이며, 각 OS의 JVM이 실행 시 기계어로 번역한다. WORA는 이 중간 단계에서 나온다.
JVM은 인터프리터와 JIT 컴파일러를 상황에 따라 혼합한다. 실행 초반은 인터프리터로 빠르게 시작하고, hot spot은 JIT(C1 → C2)로 최적화한다. "Java가 느리다"는 평가는 JIT가 웜업되기 전의 상태를 가리키는 경우가 많다.
OpenJDK와 Oracle JDK는 본질적으로 같은 코드베이스다. 프로덕션에서는 OpenJDK 기반 배포판(Temurin, Corretto)이 일반적이다.
Java 25 LTS는 현재 엔터프라이즈 표준이다. Compact Object Headers, Scoped Values(finalized), AOT Method Profiling, Flexible Constructor Bodies가 정식으로 들어왔다. 이 학습서 전체의 기준 버전이다.

생각해 볼 문제

java -Xint Hello(인터프리터 전용)와 java Hello(혼합 모드)의 실행 시간을 비교해 보자. 어느 정도 차이가 나는가? JIT의 효과를 체감할 수 있는가?
javap -v Hello.class를 실행해 상수 풀(constant pool)을 확인해 보자. #7, #13, #15가 각각 무엇을 가리키는가?
C/C++ 프로그램과 Java 프로그램을 각각 Linux에서 컴파일한 뒤, 그 결과물을 macOS에서 실행하려고 하면 어떤 일이 벌어지는가? 둘의 차이는 어디서 오는가?
jlink --module-path $JAVA_HOME/jmods --add-modules java.base --output myjre로 생성한 런타임 이미지의 크기를 확인해 보자. 전체 JDK와 얼마나 차이가 나는가?
Java 25에서 java Hello.java를 실행할 때, .class 파일이 생성되지 않는다면, JVM은 바이트코드를 어디에 보관하는가? (힌트: JEP-330의 구현 방식)
SecurityManager가 Java 17에서 deprecated 되고 Java 25에서 여전히 존재한다. 이것이 의미하는 바는 무엇이며, Java의 보안 모델이 어떻게 변화하고 있는가?

참고

JVM Specification (Java 25) - 접근 2026-07-10
Java Language Specification (Java 25) - 접근 2026-07-10
Java 25 API Documentation - 접근 2026-07-10
JEP-330: Launch Single-File Source-Code Programs - 접근 2026-07-10
JEP-282: jlink: The Java Linker - 접근 2026-07-10
JEP-444: Virtual Threads - 접근 2026-07-10
JEP-439: Generational ZGC - 접근 2026-07-10
OpenJDK - 접근 2026-07-10
Oracle JDK and OpenJDK announcement - 접근 2026-07-10

Kafka - 13. mirror maker 2

dongka — Fri, 10 Jul 2026 09:40:59 +0900

MirrorMaker 2 — 클러스터 경계를 넘는 복제, 그리고 offset 동기화의 함정

서울 리전의 Kafka 클러스터가 장애 났다. DR 사이트(도쿄)에 복제해둔 토픽 데이터는 살아 있다. 하지만 장애 복구팀이 가장 먼저 듣는 질문은 이것이다: "consumer offset은요?" 데이터는 복제됐지만, consumer 그룹이 어디까지 읽었는지는 복제되지 않았다. 수천 개의 partition에 대해 consumer가 마지막으로 읽은 위치를 모른다 — 백로그를 처음부터 다시 처리하거나, 하루 전 체크포인트로 수동 복구해야 한다.

이것이 MirrorMaker 1 시절의 현실이었다. MirrorMaker 2(MM2)는 이 문제를 근본적으로 다시 설계했다 — 데이터만 복제하는 것이 아니라, consumer offset, 토픽 설정, ACL까지 함께 옮기는 Connect 기반 복제 프레임워크로. 이 글은 MM2가 무엇인지부터 시작해, 구성 방법, 멀티 리전 offset 동기화의 작동 원리와 함정, 그리고 프로덕션 운영에서 반드시 알아야 할 것들을 다룬다.

이 글은 Kafka의 클러스터 내 복제(intra-cluster replication, ISR/HW)가 아닌 클러스터 간 복제(inter-cluster replication)를 다룬다. 클러스터 내 복제는 06-replication.md 참조.

MM2란 — Connect 위에 구축된 크로스 클러스터 복제 프레임워크

MM2는 서로 다른 Kafka 클러스터 간에 토픽 데이터, 토픽 설정, consumer 그룹 offset, ACL을 복제하는 도구다. (geo-replication.md) 핵심은 Kafka Connect 프레임워크 위에 구축됐다는 점 — Connect의 task 분산, 장애 복구, 내부 topic 기반 상태 저장을 그대로 상속받는다. (10-connect.md 참조)

MM2는 세 가지 커넥터로 구성된다:

flowchart TD
    subgraph MM2["MirrorMaker 2 (Connect 기반)"]
        SC["MirrorSourceConnector<br/>토픽 데이터 + 설정 + ACL 복제"]
        CC["MirrorCheckpointConnector<br/>consumer offset 체크포인트 + 변환"]
        HC["MirrorHeartbeatConnector<br/>연결 상태 모니터링"]
    end
    SRC["source cluster<br/>(예: us-west)"] --> SC
    SRC --> CC
    SRC --> HC
    SC --> TGT["target cluster<br/>(예: us-east)"]
    CC --> TGT
    HC --> TGT

커넥터	역할	기본 활성화
MirrorSourceConnector	source topic의 record를 target으로 복제. 토픽 설정·ACL도 동기화	예
MirrorCheckpointConnector	source consumer 그룹의 offset을 target 기준으로 변환해 checkpoint topic에 기록. `sync.group.offsets.enabled=true` 시 target의 `__consumer_offsets`에 직접 기록	예 (단, offset 동기화는 기본 비활성화)
MirrorHeartbeatConnector	target cluster에 heartbeat을 주기적으로 발행하여 연결 상태를 추적 가능하게 함	예

MirrorMaker 1은 단순한 "source consumer + target producer" 조합이었다. offset 동기화, ACL 복제, 자동 토픽 감지, 루프 방지 기능이 없었다. MM2는 KIP-382(Kafka 2.4)에서 도입됐다. (KIP-382)

복제 흐름(replication flow) — 방향성이 있는 데이터 이동

MM2의 핵심 단위는 replication flow다. {source}->{target} 형식으로 정의하며, 방향성이 있다 — 양방향 복제가 필요하면 두 flow를 각각 활성화해야 한다. (geo-replication.md)

flowchart LR
    subgraph patterns["복제 토폴로지 패턴"]
        A1["Active/Passive<br/>A->B"] 
        A2["Active/Active<br/>A->B, B->A"]
        A3["Aggregation<br/>A->K, B->K, C->K"]
        A4["Fan-out<br/>K->A, K->B, K->C"]
    end

가장 많이 쓰이는 두 패턴:

Active/Passive (A->B): primary에서 secondary로 단방향 복제. DR(disaster recovery) 용도. 장애 시 secondary로 전환(failover).
Active/Active (A->B, B->A): 양방향 복제. 두 리전 모두 생산·소비. 지연 허용 오차가 큰 워크로드.

Active/Active에서 복제 "루프"(A→B로 복제된 데이터가 다시 B→A로 복제되는 현상)는 같은 MM2 설정 파일에 두 flow를 정의하면 자동으로 방지된다. MM2가 복제된 토픽(이름에 source alias가 붙은)을 식별해 되복제하지 않기 때문. (geo-replication.md)

복제된 토픽의 이름 규칙 — DefaultReplicationPolicy

MM2는 source topic을 target으로 복제할 때 이름 앞에 source cluster alias를 붙인다. 기본 DefaultReplicationPolicy에 따른 규칙: {source_alias}.{topic_name} (DefaultReplicationPolicy.java)

us-west (source)       us-east (target)
================       =================
foo-topic         -->  us-west.foo-topic
bar-topic         -->  us-west.bar-topic

이 이름 변형이 왜 필요한가 — 같은 토픽 이름을 가진 데이터가 출처가 섞이는 것을 막기 위해. Active/Active에서 foo 토픽이 양쪽에 있다면, us-west의 foo는 us-east에 us-west.foo로, us-east의 foo는 us-west에 us-east.foo로 복제된다. 루프 없이 출처가 추적 가능하다.

구분자(separator)는 기본 .이지만 변경 가능:

# 커스텀 구분자
replication.policy.separator = _
# 결과: us-west_foo-topic

완전히 다른 이름 규칙이 필요하면 replication.policy.class로 커스텀 ReplicationPolicy 구현체를 지정할 수 있다. (IdentityReplicationPolicy를 쓰면 이름 변형을 하지 않지만, Active/Active에서는 루프 위험이 있으므로 주의.)

이름 규칙이 consumer에게 영향을 준다 — target에서 소비하려면 원래 foo-topic이 아니라 us-west.foo-topic을 구독해야 한다. 이는 장애 전환(failover) 시 consumer 설정 변경이 필요하다는 의미이기도 하다.

MM2 구성 — 설정 파일 한 개로 모든 것을

MM2는 단일 설정 파일(connect-mirror-maker.properties)로 모든 복제를 정의한다. 이 파일에 cluster 정의, 복제 flow, Connect/producer/consumer 설정이 모두 들어간다.

전체 구성 예시 — Active/Passive

# Kafka 4.3, KRaft
# cluster alias 정의
clusters = primary, secondary

# 각 cluster 연결 정보
primary.bootstrap.servers = broker1-primary:9092,broker2-primary:9092
secondary.bootstrap.servers = broker1-secondary:9092,broker2-secondary:9092

# 복제 flow 활성화 (primary -> secondary 단방향)
primary->secondary.enabled = true
secondary->primary.enabled = false

# 복제할 토픽 (정규식)
primary->secondary.topics = .*

# 내부 topic 복제 팩터 (프로덕션: 3 이상 권장)
replication.factor = 3
checkpoints.topic.replication.factor = 3
heartbeats.topic.replication.factor = 3
offset-syncs.topic.replication.factor = 3

# Connect 내부 topic 복제 팩터
offset.storage.replication.factor = 3
status.storage.replication.factor = 3
config.storage.replication.factor = 3

# consumer 그룹 offset 동기화 활성화 (DR 핵심 설정)
sync.group.offsets.enabled = true
sync.group.offsets.interval.seconds = 60
emit.checkpoints.enabled = true
emit.checkpoints.interval.seconds = 60

# 복제에서 제외할 토픽 (내부 topic 제외)
topics.exclude = .*[\-\.]internal, .*\.replica, __.*

(connect-mirror-maker.properties 예시) (MirrorConnectorConfig.java)

설정 문법의 계층 구조

MM2 설정은 전역 기본값 → flow별 오버라이드 계층을 가진다:

# 전역 기본값 (모든 flow에 적용)
topics = .*
groups = .*

# flow별 오버라이드
primary->secondary.topics = foo.*, bar.*
primary->secondary.groups = important-.*

또한 Connect, producer, consumer 설정을 cluster별로 커스터마이징할 수 있다:

# source cluster consumer 설정
primary.consumer.isolation.level = read_committed

# target cluster producer 설정
secondary.producer.compression.type = gzip
secondary.producer.buffer.memory = 32768

실행

# Kafka 4.3, KRaft 단일 노드 환경
# 전체 flow 실행
bin/connect-mirror-maker.sh config/connect-mirror-maker.properties

# 특정 target만 (consume from remote, produce to local)
bin/connect-mirror-maker.sh config/connect-mirror-maker.properties --clusters secondary

--clusters 옵션은 특정 target cluster에 가까운 위치에서만 실행할 때 사용. producer가 원격 cluster로 보낼 때 발생하는 지연(producer lag)을 줄이는 공식 권장 사항이다. (geo-replication.md)

멀티 리전 offset 동기화 — 이 글의 핵심

DR 시나리오에서 가장 중요한 질문으로 돌아가자: 장애 전환 후 consumer가 어디서부터 읽어야 하는가? MM2는 이 문제를 offset 변환(translation)으로 푼다.

offset이 왜 다른가 — 복제 과정에서 발생하는 offset 불일치

source에서 offset 100인 record가 target으로 복제되면, target에서의 offset이 100이라는 보장이 없다. 이유:

source와 target의 파티션 수가 다를 수 있다 (MM2는 partition 수를 동기화하려 하지만, 기존 토픽이 이미 있는 경우는 다를 수 있음).
source에서 retention으로 일부 record가 삭제됐을 수 있다.
복제 중 일부 record가 누락됐거나 재시도로 인해 순서가 다를 수 있다.

따라서 source offset 100이 target에서는 offset 97일 수도 있고 103일 수도 있다. 이 매핑을 저장하고 변환하는 것이 offset 동기화의 본질이다.

MM2의 offset 동기화 메커니즘

MM2는 offset 동기화를 두 단계로 수행한다:

flowchart TD
    subgraph 1단계["1단계: offset 매핑 기록"]
        S1["MirrorSourceConnector<br/>record 복제"] --> OST["offset-syncs topic<br/>source offset → target offset 매핑"]
    end
    subgraph 2단계["2단계: checkpoint 발행 + offset 동기화"]
        CC["MirrorCheckpointConnector<br/>source consumer 그룹 offset 읽기"] --> OST
        OST --> TR["offset 변환<br/>source offset → target offset"]
        TR --> CKPT["checkpoints topic<br/>(target에 저장)"]
        TR -->|"sync.group.offsets.enabled=true"| TCO["target __consumer_offsets<br/>(직접 기록)"]
    end

1단계 — offset-syncs topic: MirrorSourceConnector가 record를 복제할 때마다, source offset과 target offset의 매핑을 mm2-offset-syncs.{target}.internal topic에 기록한다. (MirrorConnectorConfig.java) 이 topic은 기본적으로 source cluster에 저장된다 (offset-syncs.topic.location = source). (MirrorConnectorConfig.java)

2단계 — checkpoint + group offset 동기화: MirrorCheckpointConnector가 source cluster에서 consumer 그룹의 현재 offset을 읽고, offset-syncs topic의 매핑을 이용해 target 기준 offset으로 변환한 뒤:

checkpoints topic({target}.checkpoints.internal)에 변환된 offset을 기록한다 — "source 그룹 X가 source offset 100까지 읽었고, 이는 target offset 97에 해당한다."
sync.group.offsets.enabled = true인 경우, 변환된 offset을 target cluster의 __consumer_offsets topic에 직접 기록한다. 이렇게 되면 target cluster로 consumer를 전환했을 때, source에서 읽던 위치부터 자연스럽게 이어서 읽을 수 있다.

(MirrorCheckpointConfig.java)에 따르면, sync.group.offsets.enabled의 기본값은 false다. 의도하지 않은 offset 덮어쓰기를 막기 위해保守的に 기본값이 설정된 것이다. DR 목적이라면 반드시 true로 설정해야 한다.

offset 동기화의 치명적인 전제 조건

sync.group.offsets.enabled = true가 동작하려면 "target cluster에 해당 consumer 그룹의 활성 consumer가 없어야 한다" — (MirrorCheckpointConfig.java)의 문서에 명시된 전제 조건이다.

이 조건이 왜 중요한가:

target에 활성 consumer가 있으면, MM2가 덮어쓰는 offset과 consumer가 자체적으로 관리하는 offset이 충돌한다.
Active/Passive DR에서는 정상적으로 동작 — 평소 target에 consumer가 없으므로 MM2가 offset을 안전하게 동기화한다.
Active/Active에서는 제약이 된다 — 양쪽에 consumer가 있으므로 offset 동기화가 제대로 동작하지 않는다.

이 제약 때문에 Active/Active에서는 offset 동기화 대신 checkpoints topic을 직접 조회하여 애플리케이션 수준에서 offset을 복구하는 패턴이 필요하다. MirrorClient API(kafka-clients의 org.apache.kafka.connect.mirror.MirrorClient)를 통해 checkpoint를 조회할 수 있다.

offset lag 허용 임계값 — `offset.lag.max`

source offset을 target offset으로 변환할 때, 변환 데이터가 없는 offset(매핑이 아직 기록되지 않은 최신 영역)는 어떻게 처리되는가. offset.lag.max(기본값: 100) 설정이 이를 제어한다 — 매핑이 없는 offset 차이가 이 값 이하면 가장 가까운 매핑을 사용하고, 초과하면 checkpoint를 생략한다. (MirrorConnectorConfig.java)

너무 낮으면 복제 지연 시 checkpoint가 누락되고, 너무 높으면 정확도가 떨어진다. 처리량이 높은 토픽은 기본값(100)으로 충분하지만, 낮은 처리량 토픽은 조정이 필요할 수 있다.

Active/Active 구성 — 멀티 리전 양방향 복제

Active/Active는 두 리전 모두에서 읽기·쓰기를 수행하면서 데이터를 상호 복제한다.

# Kafka 4.3, KRaft
clusters = us-west, us-east

us-west.bootstrap.servers = broker1-west:9092,broker2-west:9092
us-east.bootstrap.servers = broker1-east:9092,broker2-east:9092

# 양방향 flow
us-west->us-east.enabled = true
us-east->us-west.enabled = true

# 모든 토픽 복제
topics = .*
topics.exclude = .*[\-\.]internal, .*\.replica, __.*

# 내부 topic 복제 팩터
replication.factor = 3
checkpoints.topic.replication.factor = 3
heartbeats.topic.replication.factor = 3
offset-syncs.topic.replication.factor = 3

# checkpoint 발행 (양쪽 consumer 모니터링)
emit.checkpoints.enabled = true
emit.checkpoints.interval.seconds = 60

# offset 동기화는 Active/Active에서는 제약이 있음 (위 참조)
sync.group.offsets.enabled = true
sync.group.offsets.interval.seconds = 60

Active/Active에서 루프 방지를 위해 topics.exclude를 별도로 설정할 필요는 없다 — 같은 설정 파일에 두 flow를 정의하면 MM2가 자동으로 us-west.*, us-east.* 패턴의 토픽(이미 복제된 토픽)을 되복제하지 않는다. (geo-replication.md)

Active/Active의 consumer 관점

양방향 복제 환경에서 consumer가 foo 토픽을 구독하면, 같은 cluster의 원본 foo와 반대쪽에서 복제된 us-east.foo(또는 us-west.foo) 모두를 구독해야 양쪽 데이터를 모두 받는다. 이를 위해 MM2는 consumer가 하나의 "논리적 토픽"으로 통합 구독할 수 있게 지원하지 않으므로 — 애플리케이션이 두 토픽을 모두 구독하거나, upstream에서 통합 토픽으로 다시 쓰는 별도 계층이 필요하다.

이 한계는 MM2 설계의 트레이드오프다: 단순성(이름 규칙 기반 출처 추적)을 택하는 대신 consumer 복잡성을 감수한다. 대안으로 Kafka 3.9+에서 도입된 Cluster Linking(Confluent 확장, ASF core 아님)이 이 문제를 다르게 접근하지만, 이 글의 범위를 벗어난다.

프로덕션 운영 고려사항

consume from remote, produce to local

공식 문서가 명시하는 최우선 권장 사항이다. (geo-replication.md)

First DC              Second DC
==========            =================
primary ------------- MM2 ---------> secondary
(remote / source)     (local / target)

Kafka producer는 consumer보다 불안정한 네트워크에 취약하다 (ack 대기, 재시도, 타임아웃). 따라서 MM2 프로세스를 target cluster와 같은 위치에 배치하고 --clusters 옵션으로 로컬 target만 지정하는 것이 지연 최소화의 핵심이다.

# secondary DC에서 실행 — primary(원격)에서 읽고 secondary(로컬)로 쓰기
bin/connect-mirror-maker.sh mm2.properties --clusters secondary

tasks.max 설정

MM2는 Connect 기반이므로, tasks.max로 병렬 task 수를 조절한다. 기본값은 1이며, 프로덕션에서는 최소 2 이상을 권장한다 — topic-partition 수와 하드웨어 리소스에 따라 증가. (geo-replication.md)

# 각 MM2 프로세스의 최대 task 수
tasks.max = 5

내부 topic 관리

MM2는 여러 내부 topic을 생성한다. (connect-mirror-maker.properties)

topic	위치	목적	복제 팩터 설정
`heartbeats`	target	connector↔cluster 연결 상태	`heartbeats.topic.replication.factor`
`{target}.checkpoints.internal`	source (기본)	변환된 offset checkpoint	`checkpoints.topic.replication.factor`
`mm2-offset-syncs.{target}.internal`	source (기본)	source→target offset 매핑	`offset-syncs.topic.replication.factor`
Connect 내부 topic (`-configs`, `-offsets`, `*-status`)	target	Connect 프레임워크 상태	`*.storage.replication.factor`

프로덕션에서는 모든 내부 topic의 복제 팩터를 3 이상으로 설정해야 한다. 기본 예제 파일에서는 1로 설정되어 있으나, 이는 개발/테스트용이다.

설정 일관성 — 치명적인 함정

여러 MM2 프로세스가 같은 target cluster를 향해 복제할 때, 설정이 다르면 마지막에 실행된 프로세스의 설정으로 덮어쓰기된다. (geo-replication.md)

# process 1
A->B.enabled = true
A->B.topics = foo

# process 2 (같은 target B를 향함)
A->B.enabled = true
A->B.topics = bar
# 결과: foo 또는 bar 중 하나만 복제됨 (leader에 따라 결정)

→ 모든 MM2 프로세스가 동일한 설정 파일을 사용해야 한다. 조직 수준에서 단일 설정 파일을 관리하고 자동화 도구(Ansible, Kubernetes ConfigMap 등)로 배포하는 것이 안전하다.

exactly-once 지원 (Kafka 3.5+)

dedicated MM2 cluster에 대해 exactly-once semantic이 지원된다 (Kafka 3.5.0부터). (geo-replication.md)

# target cluster에 exactly-once 쓰기
secondary.exactly.once.source.support = enabled

# MM2 노드 간 내부 통신 활성화 (필수)
dedicated.mode.enable.internal.rest = true
listeners = http://localhost:8080

# source consumer에서 aborted transaction 필터링
primary.consumer.isolation.level = read_committed

기존 MM2 cluster를 exactly-once로 전환하려면 2단계 업그레이드가 필요하다: 먼저 exactly.once.source.support = preparing으로 전체 노드 재시작, 이후 enabled로 재재시작. (geo-replication.md)

모니터링 — replication-latency가 핵심 메트릭

MM2는 kafka.connect.mirror 메트릭 그룹으로 JMX 메트릭을 발행한다. (geo-replication.md)

# MirrorSourceConnector 메트릭
record-count              # 복제된 record 수
record-rate               # records/sec
replication-latency-ms    # source → target 전파 지연 (핵심)
byte-rate                 # bytes/sec

# MirrorCheckpointConnector 메트릭
checkpoint-latency-ms     # consumer offset 복제 지연

replication-latency-ms는 source에서 record가 쓰인 시각과 target에 복제된 시각의 차이이다. DR 시나리오에서 이 값이 크면, 장애 전환 시 최근 데이터가 유실될 수 있음을 의미한다. Prometheus + Grafana로 replication-latency-ms와 checkpoint-latency-ms를 대시보드에 반드시 포함해야 한다.

console-consumer 테스트 시 주의

기본적으로 MM2는 console-consumer-.*, connect-.*, __.* 패턴의 consumer 그룹을 복제에서 제외한다 (groups.exclude 기본값). 테스트로 console consumer를 실행한 그룹의 offset이 동기화되지 않는다면 이 설정이 원인이다. (geo-replication.md)

테스트 시에는 임시로 제외 목록을 수정:

# 테스트용 — console-consumer 그룹도 동기화
groups.exclude = connect-.*, __.*

테스트 완료 후 반드시 원래대로 복구.

DR 장애 전환(failover) 실제 시나리오

Active/Passive DR에서 장애 전환은 다음 순서로 수행한다:

flowchart TD
    A["1. primary 장애 감지"] --> B["2. consumer를 secondary로 전환<br/>(target 토픽명 사용: primary.foo)"]
    B --> C["3. 동기화된 offset으로 이어서 소비<br/>(sync.group.offsets=true였으므로 자동)"]
    C --> D["4. producer를 secondary로 전환"]
    D --> E["5. primary 복구 후<br/>역방향 flow로 데이터 역동기화"]

전환 시 consumer가 구독하는 토픽 이름이 바뀐다 — foo → primary.foo (DefaultReplicationPolicy). 이를 자동화하려면 consumer 설정에서 토픽 이름을 환경 변수로 관리하고, failover 시 이 값을 교체하는 메커니즘이 필요하다.

장애 복구(failback) 후 primary와 secondary 간 데이터 일관성을 맞추려면, 복구된 primary로 역방향 복제 flow를 임시 활성화해야 한다. 단, 이미 소비된 offset 이후의 데이터만 복제되도록 주의.

MM2 vs 클러스터 내 복제 — 혼동하면 안 되는 것

항목	클러스터 내 복제 (ISR/HW)	클러스터 간 복제 (MM2)
목적	단일 클러스터 내 broker 간 데이터 안전성	서로 다른 클러스터/리전 간 데이터 복제
단위	partition replica	topic (데이터 + 설정 + offset + ACL)
지연	밀리초 (동기/비동기 복제)	네트워크 RTT + 복제 파이프라인 지연
offset 보존	같은 cluster이므로 동일	변환 필요 (source ≠ target offset)
장애 조치	자동 (리더 선출)	수동 또는 반자동 (consumer/producer 전환 필요)

요약 — 이 글의 결론

MM2는 Connect 기반 크로스 클러스터 복제 프레임워크다. 데이터뿐 아니라 토픽 설정, ACL, consumer offset까지 복제한다 — 이것이 MirrorMaker 1과의 근본적 차이.
복제된 토픽 이름에는 source alias가 붙는다 (us-west.foo). 이 규칙이 루프 방지와 출처 추적을 가능하게 하지만, consumer는 target에서 다른 이름으로 구독해야 한다.
offset 동기화는 sync.group.offsets.enabled = true로 명시적 활성화해야 한다 (기본값 false). 핵심 전제: target에 활성 consumer가 없어야 동작한다 — Active/Passive DR에는 적합, Active/Active에는 제약.
consume from remote, produce to local — MM2 프로세스는 target 근처에 배치한다. producer가 consumer보다 네트워크 지연에 취약하기 때문.
설정 일관성이 치명적이다 — 같은 target을 향하는 모든 MM2 프로세스는 동일한 설정 파일을 써야 한다. 다르면 리더 선출에 따라 일부 복제가 조용히 사라진다.
DR 장애 전환은 자동이 아니다 — 토픽 이름 변경, consumer/producer 재연결, offset 검증을 포함한 런북(runbook)이 있어야 한다.

생각해 볼 문제

Active/Active 환경에서 consumer가 source의 foo와 복제된 us-east.foo를 모두 구독하고 있다. 같은 record를 두 번 처리하지 않으려면 애플리케이션 수준에서 어떤 설계가 필요할까?
sync.group.offsets.enabled = true인데 DR 전환 후 consumer가 offset 0부터 다시 읽는다면, 어떤 원인을 의심해야 할까?
세 개의 리전(west, east, north)이 있고 각 리전에 두 개의 클러스터가 있다. XDCR(Cross Data Center Replication)을 포함한 전체 복제 토폴로지에서 --clusters 옵션 없이 실행하면 어떤 문제가 발생할까?
MM2의 exactly-once가 활성화된 환경에서 source cluster의 producer가 transaction을 abort했다. target에서 이 abort된 데이터가 어떻게 처리되는가?
offset-syncs.topic.location을 source에서 target으로 변경하면 어떤 장단점이 있을까?

참고

ASF 공식 문서 - Geo-Replication (Cross-Cluster Data Mirroring) - 접근 2026-07-10
MirrorMaker Configs - 접근 2026-07-10
MirrorConnectorConfig.java - 접근 2026-07-10
MirrorCheckpointConfig.java - 접근 2026-07-10
DefaultReplicationPolicy.java - 접근 2026-07-10
connect-mirror-maker.properties 예시 - 접근 2026-07-10
KIP-382: MirrorMaker 2.0 - 접근 2026-07-10

Kafka - 12. operations

dongka — Thu, 9 Jul 2026 17:48:05 +0900

운영과 보안 — 클러스터 건강 유지와 "누가 뭘 할 수 있는가" 통제

Kafka를 기본 설정으로 두면 통신이 평문(PLAINTEXT)이고, 아무나 topic에 쓸 수 있다. 개발/테스트에만 허용되는 상태다. 프로덕션에선 (1) 클러스터가 건강한지 감시하고, (2) 누가 접속하고 무엇을 할 수 있는지 통제해야 한다.

이 글은 Kafka 운영의 두 축과, 실제로 보안을 어떻게 적용하는지(SASL_SSL/SCRAM 설정, 인증서, ACL)까지 다룬다. 읽고 나면 broker와 client에 보안을 설정할 수 있다.

운영의 두 축

클러스터 건강 — broker가 살아있고, 복제가 따라잡고, 리더가 정상인가.
보안 — 인증(누가), 인가(뭘 할 수 있는가), 암호화(통신 노출 여부).

클러스터 건강 — KRaft와 복제 감시

Kafka 4.x는 KRaft로 메타데이터를 관리한다(장 01·06). 운영자가 봐야 할 것:

URP(under-replicated partitions) — ISR < 복제본 수. 복제가 안 따라잡아 장애 내성 저하. 핵심 경보(장 06).
ISR shrink/expand 빈도 — 잦으면 broker 불건강(GC·디스크·네트워크).
controller 활성 상태 — active controller는 1개여야 정상.
request latency — broker 응답 지연.

JMX(보통 포트 9999)로 메트릭 수집(Prometheus/JMX exporter). URP/ISR 모니터링 없이는 장애 감지 불가.

보안 3계층 — 암호화·인증·인가를 분리하는 이유

계층	담당	수단
암호화(encryption)	통신 내용 보호	SSL/TLS
인증(authentication)	접속 주체 확인	SASL(PLAIN/SCRAM/GSSAPI/OAUTHBEARER) 또는 mTLS
인가(authorization)	권한 제어	ACL(`kafka-acls.sh`)

왜 3계층을 분리하는가 — 심층 방어(defense in depth). 한 계층이 뚫려도 다른 층이 방어.

SASL 메커니즘 — PLAIN은 평문이다

메커니즘	비고
PLAIN	자격증명 평문 전송 → 반드시 SSL과 함께(`SASL_SSL`)
SCRAM-SHA-256/512	자격증명이 broker에 저장(해시). SSL 없이도 상대적 안전
GSSAPI(Kerberos)	기업 환경, 복잡
OAUTHBEARER	JWT/OAuth 연동

자주 틀리는 함정: "SASL만 켜면 안전하다" — SASL/PLAIN은 평문 → SSL 없이면 도청 취약. 반드시 SASL_SSL.

보안 프로토콜 조합

`security.protocol`	암호화	인증	용도
`PLAINTEXT`	X	X	개발 전용
`SSL`	O	mTLS(선택)	TLS 암호화
`SASL_PLAINTEXT`	X	SASL	인증만 (평문)
`SASL_SSL`	O	SASL	프로덕션 표준

SASL_SSL/SCRAM 적용 방법 — 단계별 가이드

이제 실제로 보안을 어떻게 켜는지 단계별로 보자. SCRAM-SHA-256 + SSL 조합을 예로.

1단계: SCRAM 자격증명 생성 (broker에 사용자 추가)

# Kafka 4.3 — broker에 SCRAM 사용자 'alice' 추가
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --add-config 'SCRAM-SHA-256=[password=alice-secret]' \
  --entity-type users --entity-name alice

# 확인
bin/kafka-configs.sh --bootstrap-server localhost:9092 \
  --describe --entity-type users --entity-name alice

이 자격증명은 KRaft 메타데이터에 저장된다(구 ZK와 다름).

2단계: broker 설정 (server.properties)

# 리스너 설정
listeners=SASL_SSL://:9092
advertised.listeners=SASL_SSL://broker1.example.com:9092

# SASL 메커니즘
sasl.enabled.mechanisms=SCRAM-SHA-256
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256

# 인가(Authorizer) 활성화
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer

# ACL 없을 때 기본 거부
allow.everyone.if.no.acl.found=false

# super.users (모든 권한)
super.users=User:admin

# SSL 설정
ssl.keystore.location=/etc/kafka/keystore.jks
ssl.keystore.password=changeit
ssl.key.password=changeit
ssl.truststore.location=/etc/kafka/truststore.jks
ssl.truststore.password=changeit

3단계: SSL 인증서 준비 (keytool)

# 1. 키스토어 생성 (broker 인증서)
keytool -keystore /etc/kafka/keystore.jks -alias broker1 -validity 365 \
  -genkey -keyalg RSA -dname "CN=broker1.example.com" \
  -storepass changeit -keypass changeit

# 2. CA 인증서로 서명 (실제 환경)
# (자체 서명 인증서는 학습용; 프로덕션은 정식 CA 사용)

# 3. 트러스트스토어 생성 (client가 broker 인증서 검증용)
keytool -keystore /etc/kafka/truststore.jks -alias CARoot -import \
  -file ca-cert -storepass changeit -noprompt

4단계: client 설정 (producer/consumer)

# 보안 프로토콜
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256

# JAAS (자격증명)
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="alice" \
  password="alice-secret";

# SSL (broker 인증서 검증)
ssl.truststore.location=/etc/kafka/client-truststore.jks
ssl.truststore.password=changeit

또는 JAAS 파일 방식 (kafka_client_jaas.conf):

KafkaClient {
  org.apache.kafka.common.security.scram.ScramLoginModule required
  username="alice"
  password="alice-secret";
};

5단계: ACL 부여

# alice에게 my-topic 쓰기 권한
bin/kafka-acls.sh --bootstrap-server localhost:9092 \
  --add --allow-principal User:alice \
  --operation WRITE --operation READ \
  --topic my-topic

# alice에게 consumer group 'my-group' 권한
bin/kafka-acls.sh --bootstrap-server localhost:9092 \
  --add --allow-principal User:alice \
  --operation READ \
  --group my-group

# ACL 확인
bin/kafka-acls.sh --bootstrap-server localhost:9092 --list

6단계: 보안 적용 후 producer/consumer 실행

# 보안 설정이 담긴 client properties 파일로 실행
bin/kafka-console-producer.sh --topic my-topic \
  --producer.config /etc/kafka/client.properties \
  --bootstrap-server broker1.example.com:9092

bin/kafka-console-consumer.sh --topic my-topic \
  --consumer.config /etc/kafka/client.properties \
  --bootstrap-server broker1.example.com:9092

보안 설정은 broker 재기동이 필요하다. 학습 환경에서는 무거울 수 있으니, PLAINTEXT 환경에서 동작을 먼저 확인한 뒤 보안을 적용하라.

ACL — 리소스와 작업

ACL은 리소스별로 "누가( principal) 무슨 작업(operation)을 할 수 있는가"를 정의한다:

리소스 종류	작업 예
`topic`	READ, WRITE, CREATE, DELETE, ALTER, DESCRIBE
`group`	READ, DESCRIBE
`cluster`	CLUSTER_ACTION, DESCRIBE
`transactionalId`	WRITE, DESCRIBE

# User:bob에게 orders topic 읽기 + my-group group 읽기
bin/kafka-acls.sh --add \
  --allow-principal User:bob \
  --operation READ --topic orders \
  --operation READ --group my-group \
  --bootstrap-server localhost:9092

# prefix 매칭 (모든 'logs-' topic에 쓰기)
bin/kafka-acls.sh --add \
  --allow-principal User:logger \
  --operation WRITE --topic logs- --resource-pattern-type prefixed \
  --bootstrap-server localhost:9092

JMX 모니터링 설정

broker의 JMX 메트릭을 노출하려면:

# broker 기동 시 JMX 포트 지정
export JMX_PORT=9999
bin/kafka-server-start.sh config/server.properties

핵심 지표:
| 지표 | 의미 |
|------|------|
| kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions | URP 수 (0이 정상) |
| kafka.server:type=ReplicaManager,name=IsrShrinksPerSec | ISR 축소 빈도 |
| kafka.network:type=RequestMetrics,name=TotalTimeMs | 요청 지연 |
| kafka.controller:type=KafkaController,name=ActiveControllerCount | 활성 controller (1이 정상) |

Prometheus + JMX Exporter로 수집·Grafana로 시각화하는 게 운영 표준.

KRaft 운영 — broker 추가/제거

broker 추가: 새 broker 기동 + partition 복제 이동(kafka-reassign-partitions.sh).
controller 추가/제거: quorum 재구성(KIP-853 동적 quorum, controller.quorum.bootstrap.servers).

# partition reassignment (broker 추가 후 부하 분산)
bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --topics-to-move-json-file topics.json \
  --broker-list "0,1,2" --generate
# → 생성된 계획으로 --execute

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"SASL만 켜면 안전하다"	PLAIN은 평문 자격증명 → `SASL_SSL` 필수
"보안은 나중에 붙인다"	재기동·호환성 비용. 설계 단계부터 권장
"ACL 없으면 다 허용이다"	`allow.everyone.if.no.acl.found` 설정에 따라 다름
"JMX는 옵션"	URP/ISR/지연 모니터링 없이는 장애 감지 불가
"KRaft는 ZK와 운영 명령이 같다"	`controller.quorum.bootstrap.servers`(KIP-853)가 최신
"mTLS는 클라이언트만"	broker 간 통신에도 권장

더 깊이

동적 broker 구성: kafka-configs.sh --entity-type brokers로 재기동 없이 설정 변경.
partition reassignment throttle: --throttle로 대량 복제 시 운영 트래픽 보호.
mTLS(상호 TLS): 클라이언트가 X.509 인증서 제시 → broker truststore로 검증. broker 간 통신 권장.
OAUTHBEARER: JWT/OAuth 토큰 기반 인증(KIP-255). 클라우드 환경에서 유용.

요약 — 이 글의 결론

운영 2축: 클러스터 건강(KRaft/복제) + 보안 3계층.
건강 감시: JMX(포트 9999)로 URP·ISR·controller·지연. URP가 핵심 경보.
보안 3계층: 암호화(SSL), 인증(SASL/mTLS), 인가(ACL).
SASL_SSL/SCRAM 적용: (1) SCRAM 자격증명 생성 → (2) broker 설정(listeners/SASL/SSL/ACL) → (3) SSL 인증서(keytool) → (4) client 설정(JAAS+truststore) → (5) ACL 부여 → (6) 보안 적용 후 실행.
ACL: kafka-acls.sh. 리소스(topic/group/cluster) × 작업(READ/WRITE/...). 기본 거부 권장.
KRaft 운영: controller.quorum.bootstrap.servers(KIP-853 동적). broker 추가 시 reassignment.

생각해 볼 문제

보안 3계층이 각각 해결하는 위협을 말하라.
SASL/PLAIN을 SSL 없이 쓰면 왜 위험한가? SCRAM이 상대적으로 안전한 이유는?
SCRAM 자격증명을 broker에 추가하는 명령을 써 보라.
SASL_SSL을 적용하기 위한 broker 설정 항목 5가지를 말하라.
ACL로 "User:alice가 orders topic에 쓰기·읽기" 권한을 부여하는 명령은?
URP가 운영 경보의 핵심인 이유는? JMX로 뭘 봐야 하는가?

참고

Security Overview - 접근 2026-07-09
Security Model - 접근 2026-07-09
Authentication using SASL - 접근 2026-07-09
SSL encryption - 접근 2026-07-09
Authorization and ACLs - 접근 2026-07-09
Operations — KRaft - 접근 2026-07-09

Kafka - 11. kafka streams

dongka — Thu, 9 Jul 2026 17:47:22 +0900

Kafka Streams — topic의 데이터를 가공(집계·조인·창)하는 라이브러리

orders topic에 주문 이벤트가 계속 쌓인다. "5분 단위로 주문 금액을 합산하고 싶다" — 직접 consumer + window 로직 + 상태 저장을 짜면, 장애 시 상태 복구·재처리가 지옥이다. Kafka Streams는 집계·조인·창(windowing) + 상태 저장(state store) + 장애 복구(changelog)를 프레임워크가 알아서 처리한다.

이 글은 Streams가 뭔지부터 시작해, 실제로 앱을 어떻게 만들고 실행하는지(Maven 설정, topology 코드, 실행)까지 다룬다. 읽고 나면 간단한 스트림 처리 앱을 만들 수 있다.

Streams란 — 앱에 내장되는 스트림 처리 라이브러리

Kafka Streams는 별도 처리 클러스터가 아니라, 애플리케이션에 내장되는 클라이언트 라이브러리다. Spark/Flink처럼 별도 클러스터를 세울 필요 없이, 당신의 앱 프로세스 안에서 동작한다.

왜 라이브러리인 게 강점인가:

배포 단순 — 그냥 앱(JAR)을 띄우면 됨. 별도 클러스터 운영 오버헤드 없음.
확장 — 인스턴스를 더 띄우면 consumer group처럼 partition 재분배로 부하 분산(장 05).
장애 복구 — 인스턴스가 죽으면 다른 인스턴스가 partition + state를 인계.

Connect(장 10)가 "데이터를 옮기는" 거라면, Streams는 "데이터를 가공하는" 도구다.

stream-table duality — 같은 데이터의 두 모습

Streams의 핵심 통찰: "stream과 table은 같은 것의 두 모습"이다.

stream = 이벤트의 흐름(예: 주문이 발생하는 기록).
table = key별 최신 상태(예: 각 사용자의 현재 주문 합계).

거래 내역을 시간순으로 적은 장부(stream)에서, 각 계좌별 마지막 잔액만 모으면 잔액장(table)이 된다. 반대로 잔액장의 변경 이력을 펼치면 다시 거래 내역(stream)이 된다.

Streams는 이를 두 타입으로 모델링한다:

KStream — record 스트림. 각 이벤트가 독립.
KTable — key→값의 최신 상태 테이블. 같은 key 갱신은 이전값 대체.
GlobalKTable — 모든 인스턴스가 전체 복제. partition 무관 조인(참조 데이터용).

Streams 앱 만들기 — Maven 설정부터

의존성 (pom.xml)

<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-streams</artifactId>
    <version>4.3.0</version>
</dependency>
<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-clients</artifactId>
    <version>4.3.0</version>
</dependency>
<!-- JSON serde (예시) -->
<dependency>
    <groupId>org.apache.kafka</groupId>
    <artifactId>kafka-streams-test-utils</artifactId>
    <version>4.3.0</version>
    <scope>test</scope>
</dependency>

앱 설정 (Properties)

Properties props = new Properties();
props.put(StreamsConfig.APPLICATION_ID_CONFIG, "order-aggregation-app");
props.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(StreamsConfig.DEFAULT_KEY_SERDE_CLASS_CONFIG, Serdes.String().getClass());
props.put(StreamsConfig.DEFAULT_VALUE_SERDE_CLASS_CONFIG, Serdes.String().getClass());
// EOS 켜기 (선택)
props.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, "exactly_once_v2");

application.id — Streams 앱 식별자. changelog topic 이름의 prefix가 됨. 같은 id의 인스턴스들이 consumer group 형성.
PROCESSING_GUARANTEE — at_least_once(기본) 또는 exactly_once_v2(EOS, 장 08).

topology 코드 — "처리 흐름" 정의

topology는 데이터 처리 흐름의 DAG(유향 비순환 그래프)다. DSL API로 선언적으로 정의한다.

예 1: 사용자별 주문 금액 합산

// 1. 입력 topic → KStream
KStream<String, String> orders = builder.stream("orders");

// 2. key별 그룹화 + 금액 합산 → KTable
KTable<String, Long> userTotals = orders
    .groupByKey()
    .aggregate(
        () -> 0L,                          // 초기값
        (key, order, total) -> total + parseAmount(order),  // 집계 로직
        Materialized.as("user-totals-store")  // state store 이름
    );

// 3. 결과를 topic으로 내보내기
userTotals.toStream().to("user-totals", Produced.with(Serdes.String(), Serdes.Long()));

이 코드가 하는 일:

orders topic의 메시지를 key(사용자 ID)별로 그룹화.
금액을 누적 합산(state store에 저장).
결과를 user-totals topic으로 내보냄.
상태 저장(aggregate)이므로 changelog topic이 자동 생성되어 장애 복구 지원.

예 2: 필터링 (무상태)

KStream<String, String> orders = builder.stream("orders");
KStream<String, String> bigOrders = orders.filter((key, value) -> parseAmount(value) > 1000);
bigOrders.to("big-orders");

무상태 연산(filter/map)은 state store나 changelog가 필요 없다 — 빠르고 단순.

예 3: 시간 창 집계 (windowing)

KTable<Windowed<String>, Long> hourlyTotals = orders
    .groupByKey()
    .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofHours(1)))
    .count();

1시간 창으로 key별 개수 집계. event time 기준.

topology 시작

Topology topology = builder.build();
KafkaStreams streams = new KafkaStreams(topology, props);
streams.start();

// 종료 훅
Runtime.getRuntime().addShutdownHook(new Thread(streams::close));

상태 저장 처리가 장애 후에도 정확히 복구되는 원리 — changelog

상태 저장 처리(집계 등)는 "별도 DB가 필요하다"고 생각하기 쉽다. Streams는 state store를 로컬(RocksDB)에 두고, 그 백업을 Kafka 내부 topic(changelog)에 영속한다.

flowchart LR
    IN[orders topic] --> S["KStream"]
    S --> AGG["aggregate<br/>(state store: RocksDB)"]
    AGG --> CH["changelog topic<br/>(백업/복구)"]
    AGG --> OUT[user-totals topic]

집계 상태는 로컬 state store(RocksDB)에 유지.
store의 모든 갱신은 changelog topic에 기록.
장애 시 changelog에서 state store 재구축 → 별도 DB 없이 내결함 상태 처리.
state store는 partition 단위로 분산 → 확장성.

changelog topic 확인

Streams 앱 기동 후 자동 생성되는 내부 topic:

bin/kafka-topics.sh --list --bootstrap-server localhost:9092
# order-aggregation-app-user-totals-store-changelog 같은 topic 생성 확인

이 topic이 state store의 복구 원천이다 — 삭제/retention 변경 금지(상태 손상).

DSL vs Processor API

API	수준	특징
DSL	고수준	`map`/`filter`/`aggregate`/`join`/`windowedBy`. 선언적. 대부분 이걸로 충분.
Processor API	저수준	커스텀 processor + state store 직접 제어. 최대 유연성.

초보자는 DSL로 시작하라 — 대부분의 집계·필터·조인이 DSL 한 줄로 된다.

Kafka 4.3 실습 — 직접 확인하기

사전: KRaft 단일 노드 기동. Streams는 Java 라이브러리 → Maven 프로젝트 필요.

앱 빌드·실행

# 1. Maven 프로젝트 빌드
mvn clean package

# 2. 앱 실행
java -jar target/my-streams-app.jar

# 3. 다른 터미널에서 입력 topic에 메시지 produce
bin/kafka-console-producer.sh --topic orders --bootstrap-server localhost:9092
# userA:{"amount": 5000}
# userA:{"amount": 3000}
# userB:{"amount": 7000}

# 4. 출력 topic 확인
bin/kafka-console-consumer.sh --topic user-totals --from-beginning --bootstrap-server localhost:9092
# userA: 8000
# userB: 7000

changelog topic 관찰

bin/kafka-topics.sh --list --bootstrap-server localhost:9092
# order-aggregation-app-user-totals-store-changelog 생성 확인

확인할 것: 상태 저장 연산을 쓰면 changelog topic이 자동 생성.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"Streams는 별도 클러스터다"	라이브러리. 앱에 내장
"KStream과 KTable은 같다"	다르다. stream=이벤트 흐름, table=최신 상태
"상태 저장 처리엔 외부 DB가 필요"	로컬 state store(RocksDB) + changelog로 자체 해결
"Connect와 Streams는 같은 역할"	다르다. Connect=데이터 이동, Streams=데이터 가공
"EOS는 자동이다"	`processing.guarantee=exactly_once_v2` 설정 시. 기본은 at-least-once
"windowing은 processing time 기준"	event time 기준 권장 (지연 이벤트 처리)
"changelog topic은 삭제해도 된다"	금지. 상태 손상

더 깊이

interactive queries: state store를 앱이 직접 조회(별도 DB 동기화 없이 "현재 key X의 값" 반환). 단, partition 분산이라 다른 인스턴스의 key 조회엔 RPC 필요.
GlobalKTable vs KTable 조인: KTable-KStream join은 같은 key + 같은 partition 전제(co-partitioning). GlobalKTable은 partition 무관(참조 데이터용).
rebalance와 static membership: Streams 앱 재시작 시 rebalance 비용. group.instance.id(장 05)로 최소화.
EOS: processing.guarantee=exactly_once_v2로 consume-process-produce 자동 원자화(장 08).

요약 — 이 글의 결론

Kafka Streams = 클라이언트 라이브러리(별도 클러스터 아님). 앱에 내장.
stream-table duality: stream = 이벤트 흐름, table = key별 최신 상태.
KStream(이벤트) / KTable(상태) / GlobalKTable(전체 복제).
Maven 의존성 + Properties 설정(application.id 핵심) + DSL topology로 앱 구성.
state store(RocksDB) + changelog topic = 내결함 상태 처리. 별도 DB 불필요.
DSL(고수준) / Processor API(저수준).
EOS: processing.guarantee=exactly_once_v2.
Connect ≠ Streams: 이동 vs 가공.

생각해 볼 문제

Streams가 "라이브러리"라는 것이 운영상 어떤 의미인가?
stream-table duality를 KStream/KTable로 설명하라.
Maven 프로젝트에서 Streams 앱을 빌드하려면 어떤 의존성이 필요한가?
application.id가 changelog topic 이름에 어떤 영향을 주는가?
state store가 장애 후 정확히 복구되는 원리(changelog)는?
Connect와 Streams의 역할 차이는? 둘을 같이 쓰는 시나리오를 상상해 보라.

참고

Streams — Core Concepts - 접근 2026-07-09
Streams Developer Guide - 접근 2026-07-09
Streams config (EOS, application.id) - 접근 2026-07-09
Streams code examples - 접근 2026-07-09
KIP-447(exactly_once_v2)

Kafka - 10. kafka connect

dongka — Thu, 9 Jul 2026 17:46:33 +0900

Kafka Connect — 코드 없이 DB·파일과 Kafka 사이 데이터를 옮기다

"DB의 주문 데이터를 Kafka로 옮기고 싶다." producer 코드를 직접 짤 수도 있지만 — 재시작 시 어디까지 읽었는지, 병렬로 어떻게 나눌지, 장애 시 복구를 다 손봐야 한다. Kafka Connect는 이 공통 작업을 프레임워크가 대신 처리한다. 커넥터 설정 하나로 데이터 파이프라인이 완성된다.

이 글은 Connect가 뭔지부터 시작해, 실제로 어떻게 구성하고 실행하는지(설정 파일, connector JSON, REST API 관리)까지 다룬다. 읽고 나면 "파일→Kafka→파일" 파이프라인을 직접 구성할 수 있다.

Connect란 — 커넥터 기반 데이터 파이프라인 프레임워크

Connect는 데이터를 Kafka와 외부 시스템(DB·파일·S3) 사이로 옮기는 프레임워크다. 핵심 개념:

connector — "어디서→어디로, 무엇을"의 정의. 두 종류:
- source connector: 외부 시스템 → Kafka (DB 변경을 topic으로).
- sink connector: Kafka → 외부 시스템 (topic 데이터를 ES·S3로).
task — connector가 작업을 병렬 단위로 쪼갠 것. worker들이 나눠 실행.
worker — Connect 프로세스.

flowchart LR
    DB[(Postgres DB)] -->|source connector| K[Kafka topic]
    K -->|sink connector| ES[(Elasticsearch)]
    K -->|sink connector| S3[(S3)]
    subgraph CW[Connect worker]
        C[connector] -->|작업 분할| T1[task 1]
        C --> T2[task 2]
    end

Connect는 Apache Kafka core 배포판에 포함된다(bin/connect-*). 별도 설치 불필요. 단, Schema Registry는 Confluent 확장이라 별도(장 09).

standalone vs distributed — 어느 모드를 쓸까

모드	용도	상태 저장	특징
standalone	개발/테스트	로컬 파일	단일 프로세스. 단일 장애점.
distributed	프로덕션	내부 topic	여러 worker가 task 공유. 장애 시 자동 재배치. REST API 관리.

프로덕션은 무조건 distributed — standalone은 단일 장애점이라 장애 시 데이터 이동이 멈춘다.

Connect 구성 방법 — 설정 파일부터 시작

Connect를 실행하려면 worker 설정 + connector 설정 두 가지가 필요하다.

worker 설정 (standalone)

config/connect-standalone.properties — Connect 프로세스 자체의 설정:

# Kafka 클러스터 연결
bootstrap.servers=localhost:9092

# 데이터 직렬화 포맷 (converter)
key.converter=org.apache.kafka.connect.json.JsonConverter
value.converter=org.apache.kafka.connect.json.JsonConverter
key.converter.schemas.enable=false
value.converter.schemas.enable=false

# offset/config/status 저장 위치 (standalone은 파일)
offset.storage.file.filename=/tmp/connect.offsets

# REST API 포트 (distributed에서 필수, standalone은 선택)
rest.port=8083

# 커넥터 플러그인 경로 (JAR 배치 위치)
plugin.path=/usr/local/share/kafka/plugins

key.converter/value.converter가 핵심 — Connect가 Kafka에 쓸 때 바이트로 변환하는 포맷. JSON 또는 Avro(+Schema Registry). 잘못된 converter는 consumer가 못 읽는 바이트를 만든다.

worker 설정 (distributed)

config/connect-distributed.properties — 차이점은 상태를 Kafka 내부 topic에 저장:

bootstrap.servers=localhost:9092
key.converter=org.apache.kafka.connect.json.JsonConverter
value.converter=org.apache.kafka.connect.json.JsonConverter

# 상태 저장용 내부 topic (distributed 모드 필수)
group.id=connect-cluster
offset.storage.topic=connect-offsets
config.storage.topic=connect-configs
status.storage.topic=connect-status

# 내부 topic 설정 (compact 권장 - 최신 설정만 유지)
offset.storage.replication.factor=3
config.storage.replication.factor=3
status.storage.replication.factor=3

rest.port=8083
plugin.path=/usr/local/share/kafka/plugins

connect-offsets/connect-configs/connect-status는 삭제·retention 변경 금지. Connect가 상태를 의존한다.

distributed 모드 기동

# Kafka 4.3, KRaft 단일 노드 기동 후
bin/connect-distributed.sh config/connect-distributed.properties
# 여러 터미널에서 같은 설정으로 추가 기동 → 자동 클러스터 형성

connector 구성 — 어떻게 데이터 파이프라인을 정의하나

방식 1: properties 파일 (standalone)

config/connect-file-source.properties:

name=file-source
connector.class=org.apache.kafka.connect.file.FileStreamSourceConnector
tasks.max=1
file=/tmp/test.txt
topic=connect-test

방식 2: REST API + JSON (distributed, 권장)

distributed 모드에선 REST API(포트 8083)로 connector를 관리한다:

connector 생성:

curl -X POST -H "Content-Type: application/json" \
  --data '{
    "name": "file-source-demo",
    "config": {
      "connector.class": "org.apache.kafka.connect.file.FileStreamSourceConnector",
      "tasks.max": "1",
      "file": "/tmp/test.txt",
      "topic": "connect-test"
    }
  }' \
  http://localhost:8083/connectors

JDBC source connector 예 (DB → Kafka):

curl -X POST -H "Content-Type: application/json" \
  --data '{
    "name": "postgres-orders-source",
    "config": {
      "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
      "connection.url": "jdbc:postgresql://localhost:5432/mydb",
      "connection.user": "postgres",
      "connection.password": "secret",
      "table.whitelist": "orders",
      "mode": "incrementing",
      "incrementing.column.name": "id",
      "topic.prefix": "postgres-",
      "tasks.max": "1"
    }
  }' \
  http://localhost:8083/connectors

이 설정으로 Postgres orders 테이블의 새 행이 postgres-orders topic으로 자동 들어간다.

REST API — connector 생명주기 관리

distributed 모드의 REST API(포트 8083)로 모든 관리를 한다:

작업	명령
목록	`GET /connectors`
상세	`GET /connectors/{name}`
상태	`GET /connectors/{name}/status`
생성	`POST /connectors` (JSON body)
설정 변경	`PUT /connectors/{name}/config` (JSON body)
일시정지	`PUT /connectors/{name}/pause`
재개	`PUT /connectors/{name}/resume`
재시작	`POST /connectors/{name}/restart`
task 재시작	`POST /connectors/{name}/tasks/{taskId}/restart`
삭제	`DELETE /connectors/{name}`
플러그인 목록	`GET /connector-plugins`

상태 확인 예

curl http://localhost:8083/connectors/file-source-demo/status

{"name":"file-source-demo","connector":{"state":"RUNNING","worker_id":"localhost:8083"},
 "tasks":[{"state":"RUNNING","worker_id":"localhost:8083"}]}

확인할 것: RUNNING/FAILED/PAUSED. FAILED 시 trace 필드로 원인 확인.

일시정지·재개

# 일시정지 (데이터 이동 중단, connector는 유지)
curl -X PUT http://localhost:8083/connectors/file-source-demo/pause
# 재개
curl -X PUT http://localhost:8083/connectors/file-source-demo/resume

플러그인 확인

curl http://localhost:8083/connector-plugins | jq '.[].class'

plugin.path에 배치한 커넥터 JAR들이 보여야 한다.

커넥터 설치 — 플러그인 관리

Connect는 plugin.path에 있는 JAR을 자동으로 인식한다:

# 커넥터 JAR을 plugin.path에 배치
cp my-connector.jar /usr/local/share/kafka/plugins/
# Connect 재기동 (또는 분산 모드면 자동 감지)

Confluent Hub로 커넥터 설치:

confluent-hub install confluentinc/kafka-connect-jdbc:latest
# → plugin.path에 자동 설치

대표 커넥터:

Debezium (CDC: MySQL/Postgres 변경 감지)
JDBC Source/Sink (DB ↔ Kafka)
Elasticsearch Sink (Kafka → ES)
S3 Sink (Kafka → S3)
FileStream (파일 ↔ Kafka, 학습용)

converter와 SMT — 메시지 변환

converter

Connect는 내부적으로 SourceRecord/SinkRecord 모델을 쓴다. Kafka에 쓸 땐 converter가 바이트로 변환:

JsonConverter — JSON 직렬화 (디버깅 쉬움).
AvroConverter — Avro + Schema Registry 연동 (장 09).
잘못된 converter는 consumer가 못 읽는 바이트를 만든다 — "Unknown magic byte!" 에러의 원인.

SMT (Single Message Transform)

메시지 하나씩 변환(필드명 변경·타입 변환·timestamp 추가):

"transforms": "RenameField",
"transforms.RenameField.type": "org.apache.kafka.connect.transforms.ReplaceField$Value",
"transforms.RenameField.renames": "[\"old_name:new_name\"]"

복잡 집계·조인은 불가 → 그건 Kafka Streams(장 11).

실습 — FileStream 파이프라인 구성하기

standalone으로 파일→Kafka→파일

# 1. 입력 파일 준비
echo "hello connect" > /tmp/test.txt

# 2. Connect 기동 (file-source + file-sink 동시)
bin/connect-standalone.sh config/connect-standalone.properties \
  config/connect-file-source.properties \
  config/connect-file-sink.properties

# 3. test.txt에 줄 추가 → connect-test topic → 출력 파일에 나타남
echo "second line" >> /tmp/test.txt
cat /tmp/test.sink.txt  # 출력 확인

distributed로 REST API로 connector 관리

# 1. Connect distributed 기동
bin/connect-distributed.sh config/connect-distributed.properties

# 2. REST로 connector 생성 (위 JSON 예 참조)

# 3. 상태 확인
curl http://localhost:8083/connectors

# 4. 파일에 데이터 추가하고 topic/출력 파일 확인

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"Connect는 Kafka core가 아니다"	core 포함. Schema Registry만 별도
"standalone으로 프로덕션 해도 된다"	단일 장애점. 프로덕션은 distributed
"converter는 아무거나 해도 된다"	source/consumer 호환 포맷이어야
"SMT로 복잡 집계를 한다"	SMT는 메시지 단위 경량 변환만. 집계는 Streams
"task 수는 많을수록 좋다"	source/sink 대역폭·파티션 수에 bound
"내부 topic은 삭제해도 된다"	`connect-offsets`/`configs`/`status` 삭제 금지

더 깊이

DLQ (Dead Letter Queue): 처리 실패 메시지를 별도 topic(errors.deadletterqueue.topic.name)으로 보내 분석.
exactly-once Connect: source 커넥터는 at-least-once가 기본. sink는 멱등 쓰기 권장.
커넥터 개발: Connector + Task 인터페이스 구현으로 커스텀 커넥터 작성 가능.

요약 — 이 글의 결론

Kafka Connect = 코드 없는 데이터 이동 프레임워크(Kafka core 포함).
source(외부→Kafka) / sink(Kafka→외부). connector가 작업을 task로 분할.
worker 설정: standalone(개발, 파일에 상태) / distributed(프로덕션, 내부 topic에 상태, REST 8083).
connector 구성: properties 파일(standalone) 또는 REST API + JSON(distributed).
REST API CRUD: 생성·상태·일시정지·재개·재시작·삭제.
converter: wire format 결정. SMT는 메시지 단위 변환.
플러그인: plugin.path에 JAR 배치 또는 Confluent Hub 설치.
Connect(데이터 이동) ≠ Streams(데이터 가공).

생각해 볼 문제

source 커넥터와 sink 커넥터의 차이를 설명하라.
standalone과 distributed의 차이. 프로덕션은 왜 distributed인가?
REST API로 connector를 생성하는 JSON을 직접 작성해 보라.
converter를 잘못 설정하면 어떤 일이 벌어지는가?
SMT가 할 수 있는 것과 할 수 없는 것은? 안 되는 건 무엇으로 푸는가?
distributed 모드의 내부 topic(connect-offsets 등)이 왜 중요한가?

참고

Kafka Connect — User Guide - 접근 2026-07-09
Connector Development Guide - 접근 2026-07-09
Quickstart — FileStream 파이프라인 - 접근 2026-07-09

Kafka - 09. schema registry

dongka — Thu, 9 Jul 2026 17:45:46 +0900

Schema Registry — 메시지 구조를 안전하게 바꾸는 방법

producer가 {"id":1,"name":"alice"}를 보내고 consumer가 읽는다. 그런데 producer가 필드를 추가했다 — {"id":1,"name":"alice","email":"..."}. 옛 consumer는 이걸 못 읽고 크래시난다. Kafka는 value를 바이트로만 저장하고 구조(schema)를 모른다. producer와 consumer가 각자 해석하다가 구조가 어긋나면 깨진다. 이걸 푸는 게 Schema Registry다.

이 글은 Schema Registry가 뭔지부터 시작해, 실제로 어떻게 설정하고 사용하는지(Schema Registry 기동, Avro schema 정의, producer/consumer serde 설정, 호환성 검사)까지 다룬다.

중요 전제: Schema Registry는 Confluent 확장이며 Apache Kafka core가 아니다. 별도 설치가 필요하다.

Kafka가 스키마를 모른다는 것 — 왜 문제인가

Kafka는 value를 바이트로만 저장한다. 그래서:

스키마(필드명·타입)는 producer/consumer 코드에만 존재.
스키마 변경(필드 추가/삭제)이 양쪽에 동시 적용되지 않으면 consumer 크래시.
"스키마 안 바꾸면 되지" → 현실에선 불가능(요구사항 변화). 안전하게 바꾸는 규칙이 필요.

Schema Registry란 — 스키마를 별도로 두고 진화 규칙을 강제

Schema Registry는 스키마를 저장·버전 관리·호환성 검사하는 외부 서비스다(기본 포트 8081). 메시지를 보낼 때:

producer가 스키마를 Registry에 등록.
Registry가 호환성을 검사 → 통과하면 schema ID 발급.
메시지엔 schema ID만 붙여 보냄(0x00 + ID + payload).
consumer가 ID로 Registry에서 스키마를 조회해 역직렬화.

이렇게 하면 "새 스키마가 옛 consumer를 깨뜨리는지"를 등록 시점에 검사해서, 불호환 스키마 등록 자체를 거부한다. 단순 문서화가 아니라 운영 가드레일이다.

Avro — 스키마와 데이터를 분리하는 포맷

Avro의 핵심은 스키마와 데이터 분리다. 데이터 자체엔 필드명이 안 들어감(스키마로 해석) → 크기 작음. 진화 규칙(필드 default 등)을 지원한다.

Schema Registry 설정 — 어떻게 기동하나

Schema Registry는 Confluent 확장이라 Kafka core 배포판에 없다. Docker로 기동하는 게 가장 쉽다:

Docker로 Schema Registry 기동

# Kafka(KRaft)가 이미 localhost:9092에서 기동 중이라 가정

# Schema Registry 컨테이너 기동
docker run -d --name schema-registry \
  -p 8081:8081 \
  -e SCHEMA_REGISTRY_HOST_NAME=localhost \
  -e SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS=PLAINTEXT://host.docker.internal:9092 \
  -e SCHEMA_REGISTRY_LISTENERS=http://0.0.0.0:8081 \
  confluentinc/cp-schema-registry:latest

또는 Confluent Platform 전체를 Docker Compose로:

# docker-compose.yml (발췌)
services:
  schema-registry:
    image: confluentinc/cp-schema-registry:latest
    ports:
      - "8081:8081"
    environment:
      SCHEMA_REGISTRY_HOST_NAME: schema-registry
      SCHEMA_REGISTRY_KAFKASTORE_BOOTSTRAP_SERVERS: "kafka:9092"
      SCHEMA_REGISTRY_LISTENERS: "http://0.0.0.0:8081"
    depends_on:
      - kafka

기동 확인:

curl http://localhost:8081/subjects
# [] (빈 배열 — 아직 등록된 스키마 없음)

Avro 스키마 정의 — 메시지 구조를 JSON으로

Avro 스키마는 JSON으로 정의한다. User 레코드 예:

{
  "type": "record",
  "name": "User",
  "namespace": "com.example",
  "fields": [
    {"name": "id", "type": "int"},
    {"name": "name", "type": "string"},
    {"name": "email", "type": "string", "default": ""}
  ]
}

type: record — Avro 레코드(구조체).
fields — 필드 배열. 각 필드는 이름·타입·(선택)default.
default: "" — 이 필드가 없는 옛 데이터를 읽을 때 기본값 사용 → 호환성의 핵심.

스키마 등록과 호환성 검사

스키마 등록

# v1 등록
curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  --data '{"schema": "{\"type\":\"record\",\"name\":\"User\",\"fields\":[{\"name\":\"id\",\"type\":\"int\"},{\"name\":\"name\",\"type\":\"string\"}]}"}' \
  http://localhost:8081/subjects/users-value/versions
# → {"id": 1}  (schema ID 발급)

호환성 위반 시나리오

v1: {id: int, name: string} (email 없음).
v2 시도: {id: int, name: string, email: string}(default 없음) → BACKWARD 위반 → Registry가 거부(409 Conflict).
v2': {id: int, name: string, email: string, default: ""} → default로 BACKWARD 호환 → 등록 성공(새 ID 발급).

이 "등록 시점 검사"가 단순 문서화가 아니라 운영 가드레일인 이유다.

호환성 모드

모드	의미	전제
BACKWARD	새 스키마가 옛 데이터를 읽을 수 있음	흔한 기본. consumer 먼저 업그레이드
FORWARD	옛 consumer가 새 데이터를 읽을 수 있음	producer 먼저 업그레이드
FULL	backward + forward	가장 안전
NONE	검사 없음	위험

subject 명명 전략

TopicNameStrategy(기본): <topic>-key / <topic>-value. 한 topic = 한 스키마 타입.
RecordNameStrategy: Avro record 이름 기준. 한 topic에 여러 타입 허용(이벤트 소싱에 유리).

producer/consumer Avro serde 설정

Schema Registry를 쓰려면 producer와 consumer가 Avro serde를 써야 한다.

producer 설정 (Java)

# Avro 직렬화 + Schema Registry
value.serializer=io.confluent.kafka.serializers.KafkaAvroSerializer
schema.registry.url=http://localhost:8081

# (선택) 등록 시 호환성 확인 안 함(개발용)
auto.register.schemas=true

producer가 send()할 때 Avro 객체를 직렬화하며 자동으로 Schema Registry에 스키마를 등록/조회한다. 메시지엔 0x00(magic byte) + schema ID(4바이트) + Avro payload가 붙는다.

consumer 설정 (Java)

value.deserializer=io.confluent.kafka.serializers.KafkaAvroDeserializer
schema.registry.url=http://localhost:8081
specific.avro.reader=true  # GenericRecord 대신 생성된 클래스 사용

Maven 의존성

<dependency>
    <groupId>io.confluent</groupId>
    <artifactId>kafka-avro-serializer</artifactId>
    <version>7.7.0</version>
</dependency>
<dependency>
    <groupId>org.apache.avro</groupId>
    <artifactId>avro</artifactId>
    <version>1.11.0</version>
</dependency>

serde 불일치 주의: Schema Registry serializer로 쓰고 plain deserializer로 읽으면(또는 역) "Unknown magic byte!" 에러. 양쪽 모두 Avro serde + 같은 Schema Registry여야 한다.

전체 워크플로우 — schema에서 consume까지

스키마 정의: Avro JSON으로 User 레코드 작성(default 필드 포함).
Schema Registry 기동: Docker로 localhost:8081에 기동.
스키마 등록: curl POST /subjects/users-value/versions → schema ID 발급.
producer 설정: KafkaAvroSerializer + schema.registry.url.
produce: producer가 Avro 객체를 보내면 자동 직렬화 + ID 부여.
consumer 설정: KafkaAvroDeserializer + 같은 Registry.
consume: consumer가 ID로 스키마 조회 → 역직렬화 → Avro 객체 획득.
스키마 진화: v2에 default 필드 추가 → BACKWARD 호환 확인 → 등록.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"Schema Registry는 Kafka core의 일부"	Confluent 확장. ASF 배포판에 없음
"Avro는 압축 포맷"	아님. 스키마 기반 직렬화 포맷
"스키마 바꾸면 무조건 깨진다"	호환성 모드 + 진화 규칙 지키면 안전
"magic byte는 장식"	wire format 식별자. plain serde와 섞으면 "Unknown magic byte!"
"Schema Registry 없이 Avro 써도 된다"	가능은 하나 schema ID/호환성 검사 불가 → 진화 관리가 수동

더 깊이

Confluent wire format: 0x00 + schema ID(4B) + payload. 모든 메시지에 붙음.
_TRANSITIVE 모드: 직전 버전뿐 아니라 모든 과거 버전과 호환.
Avro 진화 규칙: 필드 추가→default 필수, 타입 widening(int→long)만, 필드명 변경은 비호환(alias로 일부 완화).
비-Confluent 대안: Apicurio Registry, AWS Glue Schema Registry.

요약 — 이 글의 결론

Kafka = value를 바이트로만 저장. 스키마 모름 → 진화 문제.
Schema Registry(Confluent 확장, 비 core): 스키마 저장·버전·호환성 강제(등록 시점 검사).
설정: Docker로 기동(포트 8081), Kafka broker에 연결.
Avro: 스키마-데이터 분리(JSON 스키마 정의). 크기 작음. 진화 규칙(default).
producer/consumer: KafkaAvroSerializer/Deserializer + schema.registry.url.
호환성: BACKWARD(흔한 기본)/FORWARD/FULL/NONE. 필드 추가 시 default 필수.
운영 표준: BACKWARD + consumer 먼저 배포 + default 필수.

생각해 볼 문제

Kafka가 value를 바이트로만 본다는 것이 왜 스키마 문제를 만드는가?
Schema Registry를 Docker로 기동하는 방법을 설명하라.
Avro 스키마에서 필드 추가 시 default가 필요한 이유는?
producer/consumer에 Avro serde를 설정하려면 어떤 프로퍼티가 필요한가?
"Unknown magic byte!" 에러가 발생하는 원인과 해결책은?
Schema Registry가 ASF core가 아닌 것이 왜 중요한가? 대안은?

참고

Conduktor — Schema registry - 접근 2026-07-09
Confluent Schema Registry docs - 접근 2026-07-09
Confluent — Avro serializer 설정 - 접근 2026-07-09
Avro spec(avro.apache.org), Protobuf, JSON Schema

Kafka - 08. delivery semantics

dongka — Thu, 9 Jul 2026 17:45:06 +0900

"Kafka는 exactly-once인가요" — 질문이 틀렸다

"Kafka는 exactly-once를 보장하나요?" — Kafka를 배우면 누구나 받는 질문이다. 답은 "무엇의 exactly-once인지에 따라 다르다"다. 단일 partition 쓰기(idempotent)는 exactly-once다. consume-process-produce 패턴(EOS)도 exactly-once다. 하지만 시스템 외부(DB)까지는 아니다. 이 질문이 틀린 이유는 "exactly-once"를 메시지 자체의 마법 같은 속성으로 생각하기 때문이다. 실제로는 "출력 메시지와 consumer offset을 한 트랜잭션으로 묶어 원자 commit"하는 설계 패턴의 결과다.

이 글은 Kafka의 세 가지 전달 보장 — at-most-once, at-least-once(기본), exactly-once — 의 정의, 달성 방법, 그리고 정확한 경계를 다룬다. 중복을 그냥 두면 결제가 두 번 일어나고, 손실을 그냥 두면 주문이 사라진다. 전달 보장의 경계를 정확히 아는 것이 신뢰성 설계의 출발점이다.

세 가지 전달 보장 — 중복과 손실의 트레이드오프

택배에 비유하면 감이 온다:

at-most-once: 문 앞에 두고 간다(비가 와도 책임 안 짐). 잃을 수 있지만 중복은 안 된다.
at-least-once: 수령증 받을 때까지 다시 온다. 같은 소포가 두 번 올 수 있다(중복).
exactly-once: 수령증(출력 메시지)과 배송 완료 등록(offset commit)을 한 장부에 동시에 적는다. 둘 중 하나만 일어나는 일은 없다.

보장	어떻게	Kafka 구현	비용
at-most-once	확인 안 함, 재시도 안 함	`acks=0`	최저
at-least-once	확인하고, 실패 시 재시도(중복 가능)	`acks=all` + 재시도, Kafka 기본	낮음
exactly-once	중복 제거 + 원자 쓰기	idempotent producer + transactions + read_committed	높음

Kafka의 전달 보장은 버전을 거치며 발전했다 (design.md — Message Delivery Semantics):

0.11 이전: producer는 at-least-once(네트워크 에러 시 재전송 → 중복 가능).
0.11.0.0부터: idempotent delivery(PID + sequence로 중복 제거) → 단일 partition exactly-once. transactions → 여러 partition 원자 쓰기.

전달 보장 발전사 — 타임라인으로 보는 진화

이 발전을 시간순으로 보면 각 단계가 "이전의 어떤 갭을 메웠는지" 보인다:

flowchart LR
    A["0.11 이전<br/>at-least-once만<br/>(중복 가능)"] --> B["0.11 (2017)<br/>idempotent producer<br/>(단일 partition 중복 제거)"]
    B --> C["0.11<br/>transactions<br/>(여러 partition 원자)"]
    C --> D["2.5+<br/>exactly_once_v2 (KIP-447)<br/>(consume-process-produce EOS)"]
    D --> E["3.0+<br/>idempotence 기본 true"]
    E --> F["4.x<br/>KRaft + EOS 안정화"]

단계	해결한 갭	남은 한계
at-least-once	(기준선)	중복
idempotent producer	단일 partition 중복	여러 partition은 미지원
transactions	여러 partition 원자	consumer offset과 결합은 별도
EOS v2	consume-process-produce 원자	외부 시스템은 미지원, 성능 비용

이 타임라인이 "Kafka는 exactly-once인가"라는 질문이 왜 범위를 정해야 하는지 보여준다 — "exactly-once"가 버전마다 의미하는 바가 달랐고, 각 단계가 좁은 범위의 정확성을 추가해왔다. 4.x의 EOS도 "같은 클러스터 내 consume-process-produce"에 한정된다.

exactly-once의 정확한 범위 — 오해 주의

"exactly-once"가 어디까지 보장인지를 정확히 해야 한다:

단일 partition 쓰기: idempotent producer로 exactly-once(장 03). 4.x에선 기본 동작.
consume-process-produce(consumer가 읽고 처리하고 다른 topic에 쓰는 패턴): EOS(Exactly-Once Semantics). 출력 메시지 + 입력 offset을 같은 트랜잭션으로 묶어 commit.
시스템 외부(DB 등): Kafka만으로는 보장 못 함. 외부 시스템도 트랜잭션 참여 또는 멱등 처리 필요.

"Kafka는 exactly-once인가"가 틀린 질문인 이유 — 범위를 안 정하고 묻기 때문. 단일 partition 쓰기는 이미 exactly-once(4.x 기본), consume-process-produce는 EOS로 가능, DB 쓰기는 불가.

EOS — consume-process-produce에서 exactly-once가 어떻게 나오나

여기서 핵심 질문: consume-process-produce에서 "출력과 offset을 한 트랜잭션으로"가 왜 exactly-once를 만드는가?

exactly-once는 메시지 자체의 마법 같은 속성이 아니다. "출력 메시지가 commit됐으면 입력 offset도 commit됐고, 입력 offset이 commit됐으면 출력도 commit됐다"는 원자성에서 나온다. 둘 중 하나만 일어나는 상태를 원천 차단한다.

EOS의 세 기둥

consumer partition 배타 소유: 한 consumer group 내 partition은 한 consumer만(장 05). 같은 입력을 두 consumer가 동시에 처리하는 일 없음.
producer 트랜잭션: 출력 record 생산 + consumer offsets 갱신을 하나의 트랜잭션으로 원자 commit.
consumer마다 producer 1개: rebalance 시 소유권 이전을 정확히 처리.

consume-process-produce 흐름

sequenceDiagram
    participant C as consumer (read_committed)
    participant T as transaction
    participant O as output topic
    participant OS as __consumer_offsets
    C->>C: poll() → records
    C->>T: beginTransaction()
    C->>O: send(출력 메시지들)
    C->>OS: sendOffsetsToTransaction(offsets, groupMetadata)
    C->>T: commitTransaction()  // 출력과 offset이 원자적으로 commit
    Note over O,OS: 둘 다 commit 되거나 둘 다 abort — 중간 상태 없음

코드 패턴 (ExactlyOnceMessageProcessor.java):

producer.initTransactions();          // 좀비 차단
consumer.subscribe(...);
while (running) {
    records = consumer.poll(...);
    producer.beginTransaction();
    for (record : records) producer.send(transform(record));
    producer.sendOffsetsToTransaction(offsets, consumer.groupMetadata());
    producer.commitTransaction();      // 원자 commit
}

좀비 차단 — transactional.id가 왜 필요한가

producer가 크래시 났는데 사실은 살아있어서(좀비) 같은 데이터를 다시 쓰면 중복이 생긴다. 이걸 막는 것이 transactional.id다:

initTransactions() 시 broker가 이 transactional.id의 epoch를 올린다.
이전 epoch(좀비)의 producer가 쓰려 하면 ProducerFencedException → 좀비 격리.
이것이 "재시작해도 안전"을 보장하는 핵심.

transactional.id는 안정적이고 고유해야 한다 — 재시작해도 같은 값이 유지되어야 좀비 차단이 작동한다. 아무 값이나 쓰면 안 된다.

isolation.level=read_committed — abort된 트랜잭션을 안 보게

EOS consumer는 isolation.level=read_committed를 써야 한다:

consumer가 commit된 트랜잭션만 읽는다. abort된 것은 보이지 않는다.
EOS에서 offset은 트랜잭션으로 commit되므로 enable.auto.commit=false 필수(자동 commit이 트랜잭션을 우회하면 안 됨).

read_committed는 성능에 영향이 있다 — abort 처리·LISO(last stable offset) 추적으로 지연이 생긴다. 필요한 곳에만 쓴다.

LSO(last stable offset) — read_committed가 멈추는 지점

read_committed consumer는 LSO(last stable offset)까지만 읽을 수 있다. LSO는 "아직 진행 중이거나 abort 안 된 가장 오래된 트랜잭션의 시작점" 전까지다. 즉, 한 트랜잭션이 진행 중이면 그 이후의 commit된 메시지도 consumer는 LSO 때문에 못 본다(잠시 대기).

왜 이렇게까지 하는가 — abort될 수 있는 트랜잭션의 데이터를 consumer에게 보였다가 나중에 "사실 취소"할 수 없기 때문. LSO는 "이 지점까지는 모든 트랜잭션이 결정났다(또는 abort 처리됐다)"는 안전 경계다. 장기 실행 트랜잭션이 LSO를 멈추게 하므로(지연 유발), transaction.timeout.ms로 트랜잭션 시간 상한을 둬야 한다 — 안 두면 하나의 느린 트랜잭션이 전체 consumer 지연을 만든다.

EOS 실패 모드 — 트랜잭션 중간에 크래시 나면?

EOS의 진짜 가치는 실패 상황에서 정확성을 유지하는 데 있다. consumer가 트랜잭션 중간에 크래시 나는 시나리오를 보자:

flowchart TD
    A["beginTransaction"] --> B["send(출력들)"]
    B --> C["sendOffsetsToTransaction"]
    C --> D{"commitTransaction 도달?"}
    D -->|O 크래시 전| E["트랜잭션 미완료 → abort 타임아웃 → 출력 안 보임(read_committed)"]
    D -->|O commit 직후 크래시| F["commit 성공 → 출력+offset 영속 → 재시작 시 다음부터"]
    E --> G["재시작: offset 안 넘어감 → 입력 재처리(at-least-once) → EOS 보장"]

핵심: 트랜잭션이 commit되지 않고 끝나면(크래시·타임아웃) broker가 그 트랜잭션을 abort로 처리 → 출력 메시지는 read_committed consumer에게 안 보인다 → 마치 처음부터 없었던 것처럼. consumer offset도 commit 안 됐으므로, 재시작 시 같은 입력을 다시 처리한다(at-least-once 재시도). 결국 "모두 일어나거나 아무것도 안 일어나거나"가 보장된다.

transaction.timeout.ms — 좀비·지연 방지

트랜잭션에 시간 상한(transaction.timeout.ms, 기본 60초)을 둔다:

producer가 이 시간 내에 commit/abort 안 하면 broker가 강제 abort → 장기 미완료 트랜잭션이 LSO를 멈추게 하는 걸 방지.
좀비 producer도 같은 원리로 차단 — transactional.id의 epoch가 올라가면 옛 epoch의 트랜잭션은 abort.

좀비 차단 worked example — zombie fencing이 어떻게 동작하는가

좀비 시나리오를 구체적으로 보자. producer P1(transactional.id=order-processor-1)이 트랜잭션 도중 네트워크 분단으로 "죽은 줄 알았는데 살아있다(좀비)". 한편 같은 transactional.id를 가진 P1'가 재시작됐다:

P1'가 initTransactions() 호출 → broker가 order-processor-1의 epoch를 5→6으로 올림.
좀비 P1(epoch=5)이 늦게 commit 시도 → broker가 ProducerFencedException 발생 → P1 격리.
P1'(epoch=6)만 정상 동작 → 같은 데이터 두 번 쓰는 일 차단.

이게 transactional.id가 "안정적이고 고유"해야 하는 이유다 — 같은 논리 역할(예: order-processor-1)의 재시작은 같은 id를 써야 좀비가 잡힌다. 반대로 서로 다른 역할이 같은 id를 쓰면 서로를 fence해버리는 사고가 난다. 운영에선 id 할당 체계를 명확히 설계해야 한다.

at-least-once vs exactly-once — 비용 비교

"왜 모든 곳에 EOS를 안 쓰나" — 비용 때문이다. 두 보장의 실사용 비교:

항목	at-least-once (`acks=all`+재시도)	EOS (transactional + read_committed)
처리량	높음	낮음(트랜잭션 오버헤드 10 ~ 20%+ 추정, 환경 의존)
지연	낮음	높음(LSO 대기·commit 비용)
구현 복잡도	낮음(재시도만)	높음(transactional API·좀비 처리)
중복 가능성	있음(애플리케이션 멱등 설계로 완화)	없음(단일 클러스터 내)
적합	로그·메트릭·멱등 처리 가능한 곳	결제·주문·정확성 필수

그래서 "무조건 EOS"가 정답이 아니다. 애플리케이션이 멱등 처리(DB upsert 등)로 at-least-once 중복을 흡수할 수 있으면, at-least-once가 훨씬 싸다. EOS는 정말 "정확히 한 번"이 요구되는 좁은 영역(결제·원장)에 쓴다.

전달 보장 결정 트리 — 어느 보장을 택할까

실제 설계에서 "우리는 뭘 써야 하나"를 결정하는 흐름:

flowchart TD
    Q1{데이터 손실 허용?} -->|O| AMO["at-most-once (acks=0)"]
    Q1 -->|X| Q2{"중복 처리가 안전한가?<br/>(멱등/DB upsert 가능?)"}
    Q2 -->|O| ALO["at-least-once (acks=all+재시도)<br/>+ 애플리케이션 멱등"]
    Q2 -->|X| Q3{"consume-process-produce 패턴?<br/>같은 Kafka 클러스터 내?"}
    Q3 -->|O| EOS["EOS (transactional + read_committed)"]
    Q3 -->|X 외부 DB/HTTP| OUTBOX["at-least-once + outbox/멱등 키 패턴<br/>(Kafka만으로는 한계)"]

이 트리가 보여주는 핵심: exactly-once는 항상 정답이 아니다. 손실을 감내하면 at-most-once(로그), 중복을 애플리케이션이 흡수하면 at-least-once, consume-process-produce면 EOS, 외부 시스템이면 outbox 패턴. 각기 비용·복잡도가 다르다.

외부 시스템까지 exactly-once — outbox 패턴

Kafka 트랜잭션은 같은 클러스터 내만 보장한다. "메시지 처리 후 DB에 쓰기"처럼 외부 DB까지 정확히 한 번이 필요하면, Kafka 트랜잭션이 DB를 묶을 수 없으므로 별도 패턴이 필요하다.

대표적 해법 — transactional outbox:

비즈니스 로직이 DB에 "보낼 메시지"를 outbox 테이블에 같은 DB 트랜잭션으로 쓴다(비즈니스 데이터 + outbox가 원자).
별도 프로세스(또는 Debezium CDC)가 outbox 테이블을 읽어 Kafka로 produce.
produce 성공하면 outbox 행을 삭제/마킹.

이렇게 하면 "DB 쓰기 + Kafka produce"가 (outbox를 매개로) 원자가 된다. 핵심은 DB 트랜잭션과 Kafka 트랜잭션을 직접 묶지 않고, outbox라는 중간 매개로 우회하는 것. 반대 방향(Kafka → DB)은 consumer가 DB에 멱등 쓰기(중복 키 허용)로 at-least-once 중복을 흡수한다.

이 패턴이 Kafka "exactly-once"의 경계를 보여준다 — 클러스터 내는 EOS, 외부는 설계 패턴으로 보완해야 한다.

Kafka Streams가 EOS를 "자동"으로 만드는 것

EOS를 직접 구현하려면 transactional API(initTransactions/beginTransaction/sendOffsetsToTransaction/commitTransaction)를 다뤄야 한다. 복잡하고 실수하기 쉽다. Kafka Streams는 이걸 프레임워크가 자동 처리한다 — processing.guarantee=exactly_once_v2 한 줄이면:

내부적으로 transactional producer + read_committed consumer + offset 원자 commit을 자동 구성.
rebalance 시 트랜잭션 정리도 자동.
개발자는 topology 로직만 짠다.

이게 Streams가 EOS를 쓰는 애플리케이션에서 인기인 핵심 이유다 — 직접 트랜잭션 API를 다루는 복잡도를 프레임워크가 흡수한다. 단, exactly_once (v1, KIP-98)은 폐지됐고 exactly_once_v2 (KIP-447, 2.5+)를 써야 한다 — 구형 자료 주의.

전달 보장 관련 자주 묻는 추가 질문

질문	답
"read_committed가 처리량을 얼마나 깎나"	LSO 대기·abort 처리로 지연. 정량값은 환경 의존(미검증), 보통 수 ~ 10%+
"EOS 없이 consume-process-produce 정확성?"	at-least-once만 → 중복 발생. 애플리케이션 멱등으로 보완하거나 EOS 써야
"transactional.id를 바꾸면?"	다른 producer로 인식 → 좀비 차단 안 됨. 재시작은 같은 id 유지 필수
"EOS consumer와 일반 consumer 혼합?"	read_committed consumer만 abort 제외. 일반(read_uncommitted)은 abort된 것도 봄
"외부 DB 쓰기까지 EOS?"	불가(outbox 패턴 등 별도 설계). Kafka 클러스터 내 한정

Kafka 4.3 실습 — 직접 확인하기

사전: KRaft 단일 노드. EOS는 트랜잭션 API 코드가 필요 → console 도구로 완전 재현은 어렵다(미검증: console 한계).

transaction 상태 관찰

# Kafka 4.3 — 트랜잭션 내부 topic 확인(구조적)
bin/kafka-topics.sh --list --bootstrap-server localhost:9092
# __transaction_state 가 보임 (트랜잭션 상태 저장, compact 정책)

확인할 것: __transaction_state 내부 topic 존재(트랜잭션 로그). EOS 앱 기동 후 이 topic에 상태가 쓰인다.

완전한 EOS 검증(출력+offset 원자성)은 두 터미널에 producer/consumer + ExactlyOnceMessageProcessor 예제를 실행해야 한다. 본 노트에선 개념·내부 topic 확인으로 한계 명시. idempotence 효과(중복 제거) 시각화도 broker 재시작·네트워크 에러 시뮬레이션이 필요해 console 도구로는 어렵다.

EOS 검증 — 무엇을 어떻게 확인하는가

EOS가 진짜 동작하는지 검증하려면 고의 장애 주입이 필요하다. 절차(개념):

환경: ExactlyOnceMessageProcessor 예제 기동(input topic → 처리 → output topic, transactional.id 설정).
정상 처리 확인: input에 메시지 → output에 정확히 한 번 나타나는지 카운트.
장애 주입: 처리 중간에 consumer 프로세스 kill(트랜잭션 도중 크래시 시뮬레이션).
재시작 후 확인: 같은 transactional.id로 재기동. output에 중복 없이 이어지는지(abort된 미완료 트랜잭션의 출력이 안 보이는지).
__transaction_state 관찰: 트랜잭션 상태가 (Begin→PrepareCommit→Complete)로 전이하는지(구조적 확인).
read_committed vs read_uncommitted 대비: read_uncommitted consumer는 abort된 것도 보는지, read_committed는 안 보는지 교차 확인.

이 절차가 "출력+offset 원자 commit"이 실제로 중복·손실을 막는지 눈으로 확인하는 방법이다. 단, 단일 노드 + console 도구로는 3 ~ 4번(장애 주입·재시작)이 어려워 애플리케이션 코드가 필수다.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"Kafka는 항상 exactly-once다"	기본은 at-least-once. exactly-once는 idempotence/transactions 명시 적용 시
"exactly-once는 메시지 속성이다"	아님. 출력+offset 원자 commit이라는 설계 패턴의 결과
"exactly-once가 DB 쓰기까지 보장한다"	Kafka 내부 한정. 외부 DB는 별도 트랜잭션/멱등 필요
"idempotent producer = exactly-once"	단일 partition에 한정. 여러 partition/offset은 transactions 필요
"transactional.id는 아무 값이나 된다"	안정적이고 고유해야. 좀비 차단의 기준
"read_committed는 성능에 무관하다"	abort 처리·LISO 지연 있음. 필요 시만
"exactly_once와 exactly_once_v2는 같다"	구형(KIP-98)은 폐지, v2(KIP-447) 사용. 구형 자료 주의
"transaction.timeout.ms는 안 설정해도 된다"	장기 트랜잭션이 LSO를 멈춰 전체 consumer 지연 유발. 반드시 상한 설정
"EOS를 쓰면 외부 DB도 자동 exactly-once"	아니다. 클러스터 내 한정. 외부는 outbox/멱등 패턴 별도 필요
"idempotent producer는 4.x에서도 켜야 한다"	4.x 기본 true. 별도 지정 불필요(단, 구형 자료는 false 기준)

더 깊이

Kafka Streams의 EOS: Streams는 consume-process-produce를 프레임워크 수준에서 자동화한다. processing.guarantee=exactly_once_v2(KIP-447, 2.5+)로 EOS 활성화 — 내부적으로 transactional producer + read_committed consumer + offset 원자 commit을 자동 처리. 개발자가 직접 트랜잭션 API를 다루지 않아도 EOS 달성 → Streams가 인기인 이유 중 하나.
exactly-once의 경계: 같은 Kafka 클러스터 내는 EOS 보장 가능. 다른 클러스터(MirrorMaker 등)는 source offset과 target 메시지를 한 트랜잭션으로 못 묶어 at-least-once가 한계(2.x 이후 일부 EOS 지원, 미검증). 외부 DB/HTTP는 Kafka 트랜잭션 밖 → 멱등 키·outbox 패턴 등 별도 설계.

요약 — 이 글의 결론

기본 = at-least-once(중복 가능). 0.11부터 exactly-once 옵션.
idempotent producer(4.x 기본) = 단일 partition exactly-once(PID+sequence 중복 제거).
transactions = 여러 partition 원자 쓰기 + consumer offsets과 결합.
EOS(consume-process-produce) = 출력 메시지 + 입력 offset을 한 트랜잭션으로 원자 commit. "exactly-once는 메시지 속성이 아니라 이 원자성의 결과".
좀비 차단 = transactional.id의 epoch 증가 → ProducerFencedException.
isolation.level=read_committed = commit된 트랜잭션만 consumer가 읽음(EOS 필수, 단 LSO 지연 비용).
Streams EOS = processing.guarantee=exactly_once_v2. 프레임워크가 자동 처리(트랜잭션 API 복잡도 흡수).
발전사: at-least-once(0.11 이전) → idempotent(0.11) → transactions(0.11) → EOS v2(2.5+) → 기본 true(3.0+). 각 단계가 좁은 범위 정확성 추가.
경계: Kafka 클러스터 내만. 외부 DB/HTTP는 멱등 설계 필요. "Kafka가 exactly-once인가"는 범위를 정하고 물어야.
LSO(last stable offset): read_committed consumer가 읽을 수 있는 안전 경계. 진행 중 트랜잭션이 LSO를 멈추게 함 → transaction.timeout.ms로 상한 필수.
transaction.timeout.ms: 트랜잭션 시간 상한(기본 60초). 초과 시 강제 abort → LSO 정체·좀비 방지.
outbox 패턴: 외부 DB까지 exactly-once가 필요할 때 Kafka 트랜잭션 대신 outbox 테이블로 DB+produce를 원자화.
결정 트리: 손실 허용→at-most-once, 중복 흡수 가능→at-least-once, consume-process-produce→EOS, 외부→outbox.

생각해 볼 문제

at-most-once, at-least-once, exactly-once의 차이를 중복/손실 관점에서 설명하라.
idempotent producer가 "exactly-once"인 정확한 범위는? 왜 "단일 partition" 한정인가?
consume-process-produce에서 "출력과 offset을 한 트랜잭션으로"가 왜 exactly-once를 만드는가?
transactional.id가 좀비(zombie)를 차단하는 원리를 설명하라. 왜 안정적이어야 하나?
read_committed consumer가 abort된 트랜잭션을 안 보는 것이 왜 중요한가? 비용은?
Kafka만으로 외부 DB 쓰기까지 exactly-once로 만들 수 없는 이유는? 어떤 패턴으로 보완하는가?
Kafka Streams가 EOS를 "자동"으로 달성한다는 것이 왜 강력한가?
LSO(last stable offset)가 무엇이고, 왜 진행 중 트랜잭션이 consumer 지연을 만드는가?
transactional.id를 재시작마다 바꾸면 어떤 일이 벌어지는가?
외부 DB 쓰기까지 exactly-once가 필요할 때 outbox 패턴이 어떻게 동작하는가?
at-least-once + 애플리케이션 멱등 vs EOS — 비용 관점에서 언제 어느 쪽을 택하는가?
전달 보장 발전사에서 idempotent producer와 transactions가 각각 어떤 갭을 메웠는가?
EOS 검증에서 "고의 장애 주입 후 output에 중복 없는지 확인"이 핵심인 이유는?

참고

Design — Message Delivery Semantics / Using Transactions - 접근 2026-07-09
ExactlyOnceMessageProcessor.java - 접근 2026-07-09
TransactionalClientDemo.java - 접근 2026-07-09
KIP-98(transactions), KIP-447(exactly_once_v2), KIP-833(KRaft)
ProducerConfig.java (transaction.timeout.ms 등) - 접근 2026-07-09

Kafka - 07. log retention

dongka — Thu, 9 Jul 2026 17:44:05 +0900

retention과 compaction — 메시지가 언제, 어떻게 사라지는가

Kafka는 메시지를 읽어도 지우지 않는다(장 01·02). 그럼 디스크는 계속 찰 수밖에 없나? 아니다 — topic마다 "언제, 무엇을 지울지" 정책(retention/compaction)을 둬서 오래된 데이터를 정리한다. 이 글은 그 두 가지 규칙과 실제 설정 방법을 다룬다.

주의할 점부터: "compaction"은 압축(zip)이 아니다. 같은 key의 옛 메시지를 버리는 것이다. 이 용어 혼동이 운영 착오를 자주 만든다.

메시지는 영원히 남지 않는다 — 왜 retention이 필요한가

Kafka topic은 로그라 메시지가 계속 쌓인다. 하지만 디스크는 유한하다. 그래서 topic마다 정리 정책을 둔다. 두 가지:

delete — 오래된 것을 시간이나 크기 기준으로 버린다.
compact — 같은 key의 옛 값을 버리고 최신값만 남긴다.

이 둘은 "언제 지울지"의 차이가 아니라 "무엇을 지울지"의 차이다.

segment — 로그를 이루는 파일 단위

partition 하나는 여러 segment로 구성된다 (log.md). 각 segment는 세 파일로 이루어진다:

파일	역할
`.log`	실제 메시지 데이터(순차 append)
`.index`	offset → 파일 내 바이트 위치 매핑(빠른 임의 접근)
`.timeindex`	timestamp → offset 매핑(시간 기반 조회·retention)

segment는 log.segment.bytes(기본 1 GiB)에 도달하거나 log.segment.ms(시간)가 지나면 새 segment로 넘어간다(rolling). active segment(마지막, 쓰기 진행 중)는 삭제 대상이 아니다 — rolling되어 읽기 전용이 된 segment만 삭제 후보.

segment가 왜 중요한가

"consumer가 offset 5000을 읽고 싶다"고 할 때, partition 전체를 처음부터 훑으면 느리다. .index 파일이 offset 5000이 어느 바이트 위치에 있는지 알려주어 O(1)에 찾는다. retention도 segment 단위로 일어나서 — 파일 중간을 수정할 필요 없이 segment 전체를 삭제(append-only 유지).

delete 정책 — 오래된 segment를 통째로 버린다

cleanup.policy=delete(기본)는 오래된 segment를 통째로 버린다. 두 기준:

시간 기반: segment 내 가장 큰 timestamp가 retention.ms(기본 7일 = 604800000ms)를 넘으면 그 segment 삭제.
크기 기반: partition 크기가 retention.bytes(기본 -1 = 비활성) 한계를 넘으면 가장 오래된 segment부터 삭제.

둘 다 켜면 어떤 쪽이든 임계에 닿으면 삭제(먼저 닿는 쪽).

retention 설정 예

topic 생성 시 retention을 1시간으로 설정:

# Kafka 4.3
bin/kafka-topics.sh --create --topic short-lived \
  --partitions 3 --replication-factor 1 \
  --config retention.ms=3600000 \
  --bootstrap-server localhost:9092

topic별로 동적 변경:

bin/kafka-configs.sh --alter --topic short-lived \
  --add-config retention.ms=7200000,retention.bytes=1073741824 \
  --bootstrap-server localhost:9092

현재 설정 확인:

bin/kafka-configs.sh --describe --topic short-lived --bootstrap-server localhost:9092

retention 시나리오 — 시간순 타임라인

시각 0:    partition 생성, segment-0 활성화
시각 1h:   segment-0이 1GiB 도달 → segment-1로 rolling
시각 7d:   segment-0의 max timestamp가 7일(retention.ms) 초과 → segment-0 삭제
시각 8d:   segment-1 삭제...

이 흐름이 "7일 보관, segment 단위 삭제"가 실제로 어떻게 일어나는지 보여준다.

compact 정책 — 같은 key의 최신값만 남긴다

cleanup.policy=compact는 key 기반이다. 같은 key의 메시지가 여러 개 있으면 가장 최근 것만 남기고 옛 것은 버린다 (design.md — Log Compaction).

예: topic에 user1의 프로필이 v1, v2, v3로 업데이트되며 들어온다. compaction 후엔 user1의 v3만 남는다. 과거(v1, v2)는 버려진다. 이게 "사용자 최신 상태만 유지"가 필요한 topic에 유용한 이유다.

compaction ≠ 압축

"compaction = 압축(zip)"이라고 생각하면 안 된다. 압축은 용량을 줄이지만 데이터는 그대로고, compaction은 옛 데이터 자체를 버린다. 용량은 줄지만 원리가 다르다.

tombstone — "이 key를 삭제하라" 표식

value가 null인 메시지를 tombstone이라 한다. compaction에서 "이 key를 더 이상 유지하지 마라"는 삭제 표식. 일정 기간 후 tombstone 자체도 제거된다.

tombstone 사용 예:

# user1을 삭제하려면 value=null로 produce
bin/kafka-console-producer.sh --topic user-profiles \
  --property "parse.key=true" --property "key.separator=:" \
  --bootstrap-server localhost:9092
# 입력: user1:  (value 없음 = null = tombstone)

dirty ratio — compaction 트리거

min.cleanable.dirty.ratio(기본 0.5) — 한 segment에서 옛 key 값이 일정 비율(dirty) 이상 쌓여야 compact 대상이 됨. 너무 낮으면 빈번 compact(CPU 비용), 너무 높으면 용량 비효율.

key가 없으면 compact는 무의미

key가 null인 메시지는 compact 대상이 아니다 → delete와 혼합(compact,delete) 운영이 권장된다.

delete vs compact — 무엇을 지울 것인가

정책	무엇이 남나	전형 용도	설정
`delete`	기간 내 전체 이력	이벤트 로그, 원시 데이터	`cleanup.policy=delete`, `retention.ms=604800000`
`compact`	각 key 최신값	상태 스냅샷, config, 사용자 프로필	`cleanup.policy=compact`, `min.cleanable.dirty.ratio=0.5`
`compact,delete`	key 최신 + 기간 제한	상태 + tombstone 정리	`cleanup.policy=compact,delete`

Kafka 4.3 실습 — 직접 확인하기

사전: KRaft 단일 노드.

retention 관찰

# Kafka 4.3 — 짧은 retention으로 topic 생성 (1분)
bin/kafka-topics.sh --create --topic ret-demo \
  --partitions 1 --replication-factor 1 \
  --config retention.ms=60000 \
  --bootstrap-server localhost:9092

# 메시지 produce 후 1분 대기 → describe로 segment 확인
bin/kafka-topics.sh --describe --topic ret-demo --bootstrap-server localhost:9092

compaction (key 기반)

# cleanup.policy=compact 로 topic 생성
bin/kafka-topics.sh --create --topic comp-demo \
  --partitions 1 --replication-factor 1 \
  --config cleanup.policy=compact \
  --bootstrap-server localhost:9092

# 같은 key에 여러 값 produce
bin/kafka-console-producer.sh --topic comp-demo \
  --property "parse.key=true" --property "key.separator=:" \
  --bootstrap-server localhost:9092
# user1:v1 / user1:v2 / user1:v3 입력

확인할 것: compact 실행 후 user1의 최신값(v3)만 남는지(즉시 관찰은 어려움 — dirty ratio·시간 조건 충족 시 실행).

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"compaction = 압축(zip)"	아님. key별 옛값 제거
"retention은 시간 OR 크기 중 하나만"	둘 다 켜면 먼저 닿는 쪽 삭제
"key 없이 produce해도 compact된다"	key 없으면 compact 의미 없음
"메시지 단위로 삭제된다"	segment 단위로 통째 삭제
"active segment도 retention 대상"	아님. rolling 후 후보
"tombstone은 영구 남는다"	일정 기간 후 제거됨

더 깊이

__consumer_offsets는 왜 compact인가: consumer offset은 (group,topic,partition)을 key로 저장. 같은 key의 옛 offset은 필요 없음 → compact로 최신만 유지(장 04).
tiered storage (3.x+): 로컬 디스크 외 원격(S3)에 오래된 segment 보관 → 비용 절감.
log.segment.ms: 시간 기반 segment rolling. 기본값은 7일(미검증). 짧게 두면 segment 수가 많아져 파일 핸들 증가.

요약 — 이 글의 결론

segment: partition을 이루는 파일 단위(.log + .index + .timeindex). active segment만 쓰기.
delete: 시간(retention.ms, 기본 7일) 또는 크기(retention.bytes) — 먼저 도달한 쪽. segment 통째 삭제.
compact: key별 최신값만 유지. tombstone(null)으로 key 삭제. key 없으면 무의미. (압축 아님!)
compact,delete: 상태 유지 + 기간 제한 결합.
설정: topic별로 동적 변경(kafka-configs.sh --alter --add-config).
delete vs compact는 "무엇을" 지울지의 차이 — 시간/크기(delete) vs key별 옛값(compact).

생각해 볼 문제

delete와 compact의 차이를 "무엇을 지우는가" 관점에서 설명하라.
retention 시간과 크기를 둘 다 켜면 어떻게 동작하는가?
segment를 통째로 삭제하는 이유(append-only)를 설명하라.
compaction에서 tombstone(value=null)의 역할은? 어떻게 쓰는가?
key 없이 produce하는데 cleanup.policy=compact인 topic에서 무슨 일이 벌어지는가?
__consumer_offsets가 compact 정책을 쓰는 이유는?
retention.ms를 topic별로 동적 변경하는 명령은?

참고

Implementation — log.md (segments, deletes) - 접근 2026-07-09
Design — Log Compaction - 접근 2026-07-09
Topic configs - 접근 2026-07-09

Kafka - 06. replication

dongka — Thu, 9 Jul 2026 17:26:32 +0900

broker가 죽어도 데이터가 안 사라지는 이유 — 복제와 ISR

broker 한 대에 모든 데이터를 두면 그 broker가 죽는 순간 전부 날아간다. 그래서 Kafka는 partition을 복제(replication)한다. 하지만 "복제했다"로 끝이 아니다 — 얼마나 복제해야 안전한지, 복제가 안 끝난 메시지는 consumer에게 보여야 하는지, 리더가 죽으면 누가 이어받는지를 정의해야 한다. Kafka의 답은 ISR(In-Sync Replicas)이라는 동적 쿼럼과 HW(high watermark)라는 commit 경계다.

이 글은 Kafka의 내결함성 모델 — f+1개 복제본이 f개 장애까지, 이미 commit된 메시지는 잃지 않는다는 보장 — 을 다룬다. replication.factor=1로 두다가 broker 한 대에 모든 데이터가 날아가는 사고를 막으려면 이 메커니즘을 이해해야 한다.

partition은 복제된 로그다

Kafka partition은 복제된 로그(replicated log)다 (design.md — Replication). 핵심 구조:

leader가 쓰기 순서를 결정하고, follower는 leader에서 fetch해 복사한다.
leader는 ISR(In-Sync Replicas) 집합을 유지한다. ISR 조건을 잃으면(liveness 세션 상실 또는 replica.lag.time.max.ms 초과 지연) ISR에서 제거된다.
commit = ISR의 모든 복제본이 해당 메시지를 받음. ISR 집합은 클러스터 메타데이터에 영속 → ISR 어느 것이든 leader 후보.

복제는 동기 push가 아니다. follower가 leader에서 pull(fetch) 한다 — consumer와 같은 방식. 그래서 leader가 follower를 밀어주지 않는다.

신뢰성 공식

_f+1 복제본으로 f 장애까지, *_이미 commit된 메시지는 잃지 않는다.***

복제본 수	감내 장애 수	비고
1 (단일)	0	broker 장애 = 데이터 손실
2	0 (또는 1, 가용성 한계)	권장 안 함
3	1	프로덕션 표준
5	2	고신뢰

ISR — "충분히 따라잡은" 복제본 집합

ISR은 leader를 포함해 "충분히 따라잡은" 복제본의 동적 집합이다. "충분히"의 기준은 두 가지:

liveness 세션이 살아있고,
leader와의 지연이 replica.lag.time.max.ms 이내.

follower가 이 기준을 어기면 ISR에서 제거되고, 다시 따라잡으면 복귀한다. ISR은 고정이 아니라 계속 변한다 — 그래서 "동적 쿼름"이다.

ISR이 왜 leader 후보 집합인가 — ISR에 있다는 건 "최신 데이터를 갖고 있다"는 보증이므로, ISR 안의 복제본이 leader가 되면 commit된 데이터를 잃지 않는다.

HW와 LEO — commit 경계와 로그 끝

여기서 두 offset이 등장한다:

LEO(log end offset): 각 복제본 로그의 끝 offset. leader와 follower 각자 자기 LEO를 갖는다.
HW(high watermark): 모든 ISR이 받은 마지막 offset. = min(모든 ISR의 LEO).

flowchart LR
    L["leader LEO=10"] --> HW["HW = min(ISR LEO들)"]
    F1["follower1 LEO=10"] --> HW
    F2["follower2 LEO=8"] --> HW
    HW --> C["HW=8: consumer에게 노출되는 commit 경계"]

HW가 consumer 노출 경계다: consumer는 HW 이하의 offset만 읽을 수 있다. 왜 — leader 장애로 사라질 수 있는 미commit 메시지를 consumer가 못 보게 하려고. HW 너머(HW < offset ≤ LEO)의 메시지는 leader엔 있지만 아직 모든 ISR에 복제 안 된, "아직 commit 아닌" 메시지다.

HW가 "commit"을 정의한다는 게 핵심이다. Kafka에선 "commit = ISR 전원 수신"이고, 그 경계가 HW다.

acks=all + min.insync.replicas — 신뢰성 강제

acks=all은 "ISR 모두"를 기다린다. 하지만 ISR이 1개만 남아도 그 1개만 확인하면 성공 → 사실상 신뢰성 없음. 그래서 min.insync.replicas(예: 2)를 설정하면, ISR 수가 이 미만이면 쓰기를 거부(NotEnoughReplicas)한다.

설정	ISR=3	ISR=2(min.insync=2)	ISR=1
`acks=all` 쓰기	성공(전원 확인)	성공(최소 충족)	거부(NotEnoughReplicas)
1 broker 장애 감내	O	O(replication.factor=3)	X
가용성	높음	균형	낮음(쓰기 막힘)

전형적 프로덕션: replication.factor=3, min.insync.replicas=2, acks=all. → 1 broker 장애까지 쓰기 가능 + commit 데이터 안전.

leader 선출 — 리더가 죽으면 누가 이어받는가

리더가 장애 감지되면, controller(KRaft)가 새 leader를 선출한다. 기본 규칙: ISR 안의 follower만 leader 후보.

flowchart TD
    L["leader 장애 감지"] --> S1{"ISR에 살아있는 복제본?"}
    S1 -->|"있음"| EL1["ISR에서 선출 (데이터 손실 없음)"]
    S1 -->|"없음"| S2{"ELR(4.0) 활성 또는 unclean 허용?"}
    S2 -->|"ELR 활성"| EL2["ELR/마지막 leader 중 선출 (HW까지 보존)"]
    S2 -->|"unclean 허용"| EL3["ISR 밖 선출 (데이터 손실 가능)"]
    S2 -->|"불가"| W["쓰기 중단 — 가용성 포기, 신뢰성 선택"]

ELR(Eligible Leader Replicas) — Kafka 4.0의 가용성 개선

1차 출처: eligible-leader-replicas.md

Kafka 4.0 도입, 4.1부터 신규 클러스터 기본 활성화.
ISR이 min.insync.replicas 미만이라 HW가 멈춰 있을 때, ISR이 아닌 복제본도(조건 충족 시) leader가 될 수 있게 허용.
"엄격 min ISR" 규칙이 HW 전진을 막는 문제(가용성 손실)를 해소.
controller 선출 우선순위: ISR > unfenced ELR > 마지막으로 알려진 unfenced leader.

unclean leader election — 신뢰성 vs 가용성의 극단

unclean.leader.election.enable=true면 ISR이 전멸해도 ISR 밖 복제본이 leader가 된다(가용성 회복). 단, HW 이후의 commit 데이터 손실이 가능하다. unclean=false면 ISR 회복까지 쓰기 중단(신뢰성 우선). 4.x에선 기본 false(데이터 손실 방지) 경향 — 미검증: 정확 기본값은 broker 설정 실측.

follower는 어떻게 복제하는가

follower는 leader에게 fetch 요청을 보내 새 메시지를 당겨온다(pull). 사실상 consumer와 같은 방식. follower가 충분히 최신이면 ISR 유지, 뒤처지면(replica.lag.time.max.ms 초과) ISR에서 제외.

이 "비동기 pull 복제"가 중요한 함의를 갖는다 — leader가 follower의 보제 완료를 동기적으로 기다리는 게 아니라, follower가 알아서 따라온다. 그래서 acks=all의 "all"은 "현재 ISR 전원이 fetch 완료"를 의미하지, "모든 복제본이 무조건"을 의미하진 않는다(뒤처진 복제본은 ISR에서 빠져서 all 대상이 아님).

leader epoch — leader가 바뀌어도 로그가 발산하지 않는 장치

leader가 바뀔 때마다 한 가지 위험이 있다 — 옛 leader가 잠깐 살아나서(네트워크 분단) 자기 로그에 쓰다가 새 leader와 다른 내용이 생기는 "로그 발산(log divergence)"이다. Kafka는 leader epoch로 이를 막는다.

leader epoch는 단조증가 정수로, leader가 바뀔 때마다 1씩 올라간다. 각 로그 세그먼트는 (epoch, start-offset) 쌍을 메타데이터로 갖는다. 새 leader가 선출되면:

자기 epoch를 올린다.
follower가 fetch할 때 자기가 본 마지막 epoch를 함께 보낸다.
leader는 epoch 불일치를 감지하면 follower 로그의 잘못된(옛 leader가 쓴) 꼬리를 잘라내고(truncate) 자기 로그로 다시 맞춘다.

이게 KIP-101(Stop replicating after leader epoch)의 핵심이다. epoch가 없던 시절엔 HW 기준으로만 잘라내다가 모호한 경우가 있었는데, epoch로 "이 시점 이후는 옛 leader의 것이니 버려라"가 명확해졌다. replication 정확성의 근간이다.

복제 worked example — broker 장애 시 무슨 일이 일어나는가

추상 설명만으론 감이 안 온다. 3 broker(b1,b2,b3), partition p0(replication.factor=3, leader=b1, ISR={b1,b2,b3}, HW=100)에서 b1이 장애났다고 하자. 단계별로:

장애 감지: coordinator가 b1의 heartbeat 단절을 감지(session.timeout 또는 KRaft liveness). controller가 개입.
ISR 재계산: b1이 ISR에서 제외 → ISR={b2,b3}.
새 leader 선출: ISR 안의 b2(또는 b3)가 새 leader. epoch 증가.
HW 유지: HW는 min(b2.LEO, b3.LEO). b1이 빠졌지만 둘 다 HW=100까지 복제했으므로 HW=100 유지 → commit된 메시지(≤100) 손실 없음.
쓰기 가용성: min.insync.replicas=2, ISR=2 → 쓰기 계속 가능.
b1 복구: b1이 돌아오면 자기 epoch가 옛이라는 걸 new leader에게 fetch하며 알게 되고, 옛 leader 시절 쓴(잘못된) 꼬리를 truncate한 뒤 새 leader에서 따라잡음 → ISR에 복귀.

이 시나리오가 f+1=3 복제본이 f=1 장애를 견디는 것을 구체적으로 보여준다. 핵심은 "commit(HW=100) 이하 데이터는 손실 없다"는 보장이 ISR·HW·leader epoch의 조합으로 실제로 지켜진다는 점이다.

동시 장애 2대면 어떻게 되나

b1, b2가 동시에 장애 → ISR={b3} 하나만. min.insync.replicas=2이면 ISR(1) < min(2) → 쓰기 거부(NotEnoughReplicas). 읽기는 HW=100까지 가능. b1이나 b2가 복구해 ISR≥2가 되어야 쓰기 재개. 이게 신뢰성이 가용성을 이긴 순간이다. unclean 허용 시 b3가 단독 leader가 되어 쓰기를 허용하되, HW 너머 b3만 가진 미commit 데이터가 손실될 수 있다.

ISR 라이프사이클 — flap과 복구

ISR은 고정이 아니라 계속 변한다. follower가 느려졌다 빨라졌다(flapping) 하는 실제 운영 시나리오를 보자:

follower b3가 GC·디스크 지연으로 replica.lag.time.max.ms 초과 → ISR에서 제거(shrink). 이 순간 partition은 URP가 된다.
b3가 따라잡아(leader의 HW까지 fetch 완료) → ISR에 복귀(expand).
이 shrink/expand가 잦으면 broker 불건강(GC·디스크·네트워크) 신호. JMX ISRShrinkRate/ISRExpandRate로 잡는다(장 12).

ISR 변동이 잦은 partition은 안정적이지 않다 — min.insync.replicas에 자주 걸려 쓰기가 거부될 수 있고, 리더 선출 빈도가 올라간다. 운영에선 ISR 안정성 자체가 건강 지표다.

produce → commit 수명주기 — HW가 어떻게 전진하는가

복제가 정상 동작할 때 HW가 어떻게 자라는지 추적하면, "commit"이 동적으로 만들어지는 과정이 보인다. partition p0(leader=b1, ISR={b1,b2,b3}, 현재 HW=100)에서 producer가 batch를 보낸다고 하자:

sequenceDiagram
    participant P as producer
    participant L as leader b1
    participant F2 as follower b2
    participant F3 as follower b3
    P->>L: send batch[101..110] (acks=all)
    L->>L: append (LEO=110)
    F2->>L: fetch → b2도 101..110 수신 (b2.LEO=110)
    F3->>L: fetch → b3도 101..110 수신 (b3.LEO=110)
    Note over L: 모든 ISR의 LEO=110 → HW=110으로 전진
    L-->>P: ack (HW 반영, commit 완료)

핵심: HW는 leader가 모든 ISR의 fetch를 확인한 뒤에야 전진한다. producer의 acks=all 대기는 곧 "이 HW 전진이 끝날 때까지 기다린다"는 뜻이다. follower가 하나라도 느리면 그 follower의 LEO가 HW를 낮추므로, HW 전진이 늦어지고 producer ack도 늦어진다 → 처리량 저하로 이어진다. 그래서 ISR 안정성이 성능에도 직결된다.

복제 관련 주요 설정 — 튜닝 축

복제 동작을 다루는 핵심 설정(1차 출처: topic-configs/broker-configs):

설정	기본값	의미
`replica.lag.time.max.ms`	30000(30초)	follower가 이 시간 내에 leader를 따라잡지 못하면 ISR 제거
`min.insync.replicas`	1(권장 2)	`acks=all` 쓰기 허용 최소 ISR 수
`replica.fetch.max.bytes`	1MB	follower fetch 한 번당 최대 바이트
`num.replica.fetchers`	1	broker당 follower fetch 스레드 수(증가시 복제 병렬성↑)
`unclean.leader.election.enable`	false(권장)	ISR 전멸 시 ISR 밖 leader 허용 여부

num.replica.fetchers를 늘리면 follower가 여러 스레드로 leader에서 당겨오므로, partition 수가 많고 복제가 따라잡지 못할 때 효과가 있다. 반대로 replica.lag.time.max.ms를 너무 크게 두면 느린 follower가 ISR에 오래 남아 처리량을 끌어내린다. 복제 튜닝은 ISR 안정성과 처리량의 균형을 잡는 일이다.

복제 throttle — 대규모 복구 시 디스크 보호

broker 장애 복구나 partition reassignment로 대량 복제가 몰리면, 네트워크·디스크가 포화돼 운영 트래픽까지 느려진다. kafka-reassign-partitions.sh --throttle <bps>로 복제 대역폭을 제한해 운영 영향을 막는다(장 12). 복구 속도와 운영 안정성의 균형 — "최대한 빨리 복구"가 항상 정답은 아니다.

복제 모델 비교 — 왜 Kafka는 ISR 동적 쿼럼을 택했나

Kafka의 ISR 모델이 유일한 복제 방식은 아니다. 다른 접근과 비교하면 Kafka의 선택이 왜 이런지 보인다.

접근	작동	Kafka ISR과의 차이
동기 전 복제(모든 쓰기마다 전원 동기 대기)	쓰기마다 N 복제본 모두 확인	Kafka도 `acks=all`이 유사하지만, ISR(동적)만 대기. ISR 밖 느린 복제본은 기다리지 않음 → 가용성 유지
정적 과반수 쿼럼(Raft/Paxos)	고정 N개 중 과반수	Kafka는 ISR이 동적(느린 복제본 자동 제외). ELR(4.0)이 ISR 부재 시 HW 범위 쿼럼 확대로 가용성 회복
chain replication	leader→follower1→follower2 선형 전파	Kafka는 leader가 모든 follower에게서 pull(팬아웃). chain보다 병렬 fetch로 빠름
비동기 복제(ack 안 기다림)	fire-and-forget	`acks=0`과 같음. 가장 빠르나 신뢰성 없음

Kafka의 설계 철학: 신뢰성(acks=all + ISR)과 가용성(ISR 동적 + ELR)의 균형. 모든 복제본을 강제 동기 대기하면 느린 하나가 전체를 끌어내리고(가용성 손실), 반대로 비동기만 쓰면 장애 시 데이터 유실이다. Kafka는 "충분히 따라잡은 복제본(ISR)만 commit에 참여시키고, 뒤처진 건 제외해 처리량을 지킨다"는 중간 노선을 택했다. ELR은 이 균형을 가용성 쪽으로 더 밀어준 4.0의 개선이다.

복제 관련 자주 묻는 추가 질문

질문	답
"ISR이 1개면 commit이 의미 있나"	사실상 없음. leader만 확인하면 commit되므로 leader 장애 시 미commit 손실. 그래서 `min.insync.replicas≥2` 필수
"follower가 전부 느리면 producer는?"	HW가 전진 안 해 `acks=all` 대기만 길어짐 → 타임아웃/처리량 저하. ISR 설정·broker 용량 점검 신호
"read도 leader만?"	기본 yes(follower는 복제만). follower read는 별도 설정이 있으나 일반적이진 않음 — 순서/일관성 복잡도
"복제본 수를 나중에 바꿀 수 있나"	가능(reassignment). 늘리는 건 온라인, 줄이는 건 즉시. 데이터 이동 동반

under-replicated partition (URP) — 운영 핵심 경보

ISR < 복제본 전체 수인 partition을 URP라 한다. 즉 일부 복제본이 따라잡지 못해 장애 내성이 떨어진 상태. 운영 핵심 경보 지표 — URP가 지속되면 복제 지연·broker 불건강 신호. 모니터링에서 URP 수를 잡는 게 Kafka 운영의 기본이다(장 12).

Kafka 4.3 실습 — 직접 확인하기

사전: 다중 broker 필요(3 broker KRaft). 단일 노드(replication.factor=1)에선 ISR/복제가 의미 없음.

복제 상태 확인

# Kafka 4.3, KRaft 다중 broker
bin/kafka-topics.sh --describe --topic rep-demo --bootstrap-server localhost:9092

Topic: rep-demo  Partition: 0  Leader: 1  Replicas: 1,2,3  Isr: 1,2,3
Topic: rep-demo  Partition: 1  Leader: 2  Replicas: 2,3,1  Isr: 1,2,3

확인할 것: Leader(partition별), Replicas(전체 복제본), Isr(동기화된 복제본). Isr이 Replicas와 같으면 정상, 일부 빠지면 URP.

broker 장애 시나리오 (개념)

한 broker 프로세스를 종료하고 --describe로 Leader/Isr 변화 관찰:

종료된 broker가 leader였던 partition → ISR 내 다른 broker가 leader 선출.
종료된 broker가 ISR에서 제거됨.
min.insync.replicas=2, 복제본 3 → 1대 종료 후에도 쓰기 유지.

단일 노드 환경에선 복제 실습 불가. 다중 broker 구성 필요(또는 Docker compose 3 broker).

broker 장애 시뮬레이션 — 단계별 관찰 가이드

다중 broker(3대) 환경에서 복제 동작을 직접 보는 절차:

준비: partition 3, replication.factor=3, min.insync.replicas=2 topic 생성. 메시지 produce.
정상 상태 캡처: kafka-topics.sh --describe로 Leader/Replicas/Isr가 모두 같은지(URP 아님) 확인.
leader broker 종료: leader였던 broker 프로세스 kill.
즉시 describe: Leader가 ISR 안 다른 broker로 바뀌었는지, Isr에서 종료된 broker가 빠졌는지 확인. epoch 증가는 메타데이터로 직접 보긴 어려우나 리더 변경으로 간접 확인.
쓰기 계속: producer로 메시지 보내 — min.insync=2, ISR=2이므로 쓰기 성공하는지.
종료 broker 복구: broker 재기동. ISR에 복귀하는지(Isr에 다시 나타남) 확인.
데이터 무결성: --describe의 Isr == Replicas 복귀 + consumer로 누락·중복 없는지 최종 확인.

이 절차가 f+1 보장을 눈으로 확인하는 가장 확실한 방법이다. 핵심은 "leader 장애 → ISR 안 이관 → commit 데이터 무손실 → 복구 시 ISR 복귀" 흐름 전체를 한 번에 보는 것.

복제 건강 운영 체크리스트

복제를 프로덕션에서 운영할 때 매일 확인해야 할 것들:

URP 수 = 0(또는 일시적 스파이크만). 지속 URP는 복제 지연.
ISR shrink/expand 빈도 낮음. 잦으면 broker 불건강(GC·디스크·네트워크).
min.insync.replicas ≤ ISR 유지. ISR 하락 시 쓰기 거부 사전 경보.
replication.factor=3 (프로덕션). 1~2는 데이터 유실 위험.
acks=all 기본. acks=1은 미복제 손실 위험.
복제 throttle 적용(reassignment/복구 시 운영 트래픽 보호).
leader 분산 고른 broker에. 한 broker에 leader 몰리면 핫스팟.

이 체크리스트는 장 12(운영·JMX 지표)와 직결된다.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"acks=all이면 무조건 안전"	ISR이 1개 남으면 사실상 신뢰성 없음. `min.insync.replicas`와 세트
"복제는 동기 push다"	follower가 leader에서 pull(fetch). 비동기
"replication.factor=2면 1대 장애 감내"	가용성 한계. 권장 최소 3
"leader 죽으면 데이터 손실"	ISR 안 follower가 이어받으면 commit된 메시지 손실 없음. 손실 위험은 unclean 선출 시
"ELR은 ISR을 무시한다"	아님. ISR 우선, ISR 부재 시 HW 범위 내에서 안전하게 선출 확대
"min.insync.replicas 높을수록 좋다"	너무 높으면 ISR 하락 시 쓰기 전면 거부(가용성 손실)
"HW와 LEO는 같다"	HW = min(ISR LEO), LEO = 각 복제본 끝. consumer는 HW까지만 읽음

더 깊이

unclean leader election 상세: unclean.leader.election.enable=true면 ISR 전멸 시 ISR 밖 복제본이 leader(가용성 회복, 단 HW 이후 commit 데이터 손실 가능). false면 ISR 회복까지 쓰기 중단(신뢰성 우선).
ELR이 "엄격 min ISR" 문제를 푸는 방식: 기존은 ISR < min.insync.replicas → HW 멈춤 → 쓰기 거부 → 가용성 손실. ELR은 ISR이 아닌 복제본도 HW 범위 내에서 leader 후보에 추가 → HW를 전진시켜 가용성 회복, 동시에 이미 commit된 데이터(HW 이하)는 보존. 신뢰성-가용성 균형의 4.0 해법.

요약 — 이 글의 결론

partition = 복제된 로그. leader 결정 순서, follower가 pull로 복제.
ISR = 충분히 따라잡은 복제본 집합(동적). leader 후보는 ISR.
commit = ISR 전원 수신. HW = ISR 모두의 LEO 최소 = consumer 노출 경계. consumer는 HW까지만 읽음.
f+1 복제본 → f 장애까지 commit 메시지 보존.
min.insync.replicas + acks=all = 신뢰성 강제. ISR 미달 시 쓰기 거부. 프로덕션 표준: replication.factor=3, min.insync.replicas=2, acks=all.
ELR(4.0, 4.1 기본): ISR 부재 시 HW 범위 내 복제본까지 leader 후보 확대(가용성 회복).
leader epoch: leader 교체 시 로그 발산 방지(truncate 옛 leader 꼬리). replication 정확성 근간.
produce→commit: HW는 모든 ISR의 fetch 확인 후 전진. acks=all은 이 HW 전진을 기다림.
URP(under-replicated partition) = 핵심 운영 경보. ISR shrink/expand 빈도도 건강 지표.
설계 철학: ISR 동적 쿼럼으로 신뢰성(acks=all+ISR)과 가용성(ISR 제외+ELR) 균형.
복제 설정: replica.lag.time.max.ms·num.replica.fetchers·min.insync.replicas로 ISR 안정성·처리량 튜닝.

생각해 볼 문제

f+1 복제본이 f 장애까지 commit 메시지를 잃지 않는 이유를 ISR 관점에서 설명하라.
HW와 LEO의 차이. consumer가 HW까지만 읽는 이유는?
acks=all + min.insync.replicas=2 + replication.factor=3 설정에서 1 broker 장애 시 쓰기는?
follower가 ISR에서 제외되는 조건 두 가지를 말하라.
ELR(4.0)이 해결한 "엄격 min ISR"의 문제는?
복제가 동기 push가 아니라 비동기 pull인 것이 acks=all의 의미에 어떤 영향을 주는가?
URP가 운영 경보의 핵심인 이유는? ISR shrink/expand 빈도는 무엇을 시사하는가?
leader epoch가 없다면 leader 교체 시 어떤 문제가 생기는가?
동기 전 복제(모든 복제본 강제 대기) 대신 Kafka가 ISR 동적 쿼럼을 택한 이유는?
broker 장애 시뮬레이션에서 "leader 이관 → 쓰기 유지 → ISR 복귀" 흐름이 f+1 보장을 어떻게 보여주는가?

참고

Design — Replication / Replicated Logs - 접근 2026-07-09 (ISR, HW, commit 정의, f+1)
Eligible Leader Replicas (4.0) - 접근 2026-07-09
Basic Operations — replication - 접근 2026-07-09
KIP-392(ELR 계열), KIP-101(leader epoch로 복제 정확성), unclean leader election 관련 설정
broker-configs.md(replica.lag.time.max.ms, num.replica.fetchers 등 복제 튜닝) - 접근 2026-07-09

Kafka - 05. consumer group

dongka — Thu, 9 Jul 2026 17:24:46 +0900

consumer group — topic을 여러 consumer가 나눠 읽는 팀

orders topic에 주문이 초당 수만 건 쏟아진다. consumer 하나로는 다 못 읽는다. consumer를 여럿 띄워 병렬로 읽고 싶다 — 하지만 같은 메시지를 두 consumer가 동시에 읽으면 중복이 생긴다. 이걸 해결하는 게 consumer group이다. 여러 consumer가 topic의 partition을 서로 겹치지 않게 나눠 읽는 팀이다.

이 글은 consumer group이 뭔지, 어떻게 partition을 나누는지, consumer가 들락날락할 때 일어나는 rebalance와 그 비용, 그리고 실제로 어떻게 구성하고 관리하는지까지 다룬다.

consumer group이란 — partition을 나눠 읽는 consumer 팀

consumer group은 같은 group 이름을 가진 consumer들의 모임이다. 핵심 규칙은 한 줄이다:

한 consumer group 안에서, partition 1개는 정확히 한 consumer가 담당한다.

구성	무슨 일
partition 4개 + consumer 2명	각 consumer가 2 partition씩
partition 4개 + consumer 4명	각 consumer가 1 partition씩 (최대 병렬)
partition 4개 + consumer 6명	4개만 일하고 2개는 놀음(idle)

왜 "1 partition = 1 consumer"인가 — 같은 partition을 두 consumer가 동시에 읽으면 순서가 꼬이고 offset commit이 충돌한다. 그래서 한 partition은 한 consumer만 단독 소유. 병렬성의 상한 = partition 수다(장 02).

consumer group은 어떻게 쓰이나 — worked scenario

orders topic(partition 6개)을 consumer 3개로 확장:

flowchart TB
    T["orders topic<br/>(partition 0 ~ 5)"] --> A["consumer A<br/>(p0, p1)"]
    T --> B["consumer B<br/>(p2, p3)"]
    T --> C["consumer C<br/>(p4, p5)"]
    subgraph GP["group: order-processors"]
        A
        B
        C
    end

consumer 3개를 같은 group(order-processors)으로 띄운다.
Kafka가 partition을 나눠 줌 — A: p0,p1 / B: p2,p3 / C: p4,p5.
각 consumer가 자기 partition만 읽어 처리 → 3배 병렬, 중복 없음.

다른 group은 독립적: order-processors group과 analytics group은 서로 간섭 없이 같은 orders topic을 전부 각자 읽는다. group마다 자기 offset을 따로 관리한다.

consumer group 설정 — 어떻게 구성하나

consumer 설정 (Java)

# group 식별자 (핵심 — 같은 group.id = 같은 팀)
group.id=order-processors

# broker 연결
bootstrap.servers=localhost:9092

# 역직렬화
key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
value.deserializer=org.apache.kafka.common.serialization.StringDeserializer

# auto-commit (신뢰성 필요시 false, 장 04)
enable.auto.commit=false

# partition 할당 전략
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

# rebalance 관련 (차세대 프로토콜 사용시 일부 무시)
session.timeout.ms=45000
heartbeat.interval.ms=3000
max.poll.interval.ms=300000

partition 할당 전략

전략	특징
RangeAssignor	topic별로 partition을 범위로 나눔 (오랜 기본)
RoundRobinAssignor	round-robin으로 순환 분배
StickyAssignor	재할당 시 기존 할당 최대한 유지 (이동 최소화)
CooperativeStickyAssignor	sticky + 증분 교환 (KIP-429, 권장)

차세대 rebalance 프로토콜(4.0 GA) 활성 시 partition.assignment.strategy는 사용 불가. 프로토콜이 자체 관리.

rebalance — consumer가 들락날락하면 partition을 다시 나눈다

consumer group의 구성원이 바뀌면 partition을 재분배한다(rebalance):

consumer 합류(새 consumer 띄움) 또는 이탈(크래시·종료).
구독 topic/partition 변경.

rebalance의 비용 — stop-the-world

구형(eager) 프로토콜에선 rebalance 시작 시 모든 consumer가 partition을 내려놓고 전체를 다시 나눈다 — 끝날 때까지 아무도 소비 못함. consumer가 많을수록 멈춤이 길어진다. "consumer를 함부로 재시작하면 안 된다"는 이유.

cooperative rebalance — 변경분만 교체

Kafka 4.0에선 차세대 rebalance 프로토콜이 GA됐다 (consumer-rebalance-protocol.md):

유지 가능한 partition은 그대로, 변경이 필요한 partition만 교체.
나머지 consumer는 계속 소비 → 멈춤 최소화.
활성화: group.protocol=consumer.

차세대 프로토콜 활성 시 heartbeat.interval.ms, session.timeout.ms, partition.assignment.strategy 사용 불가.

ConsumerRebalanceListener — 상태 정리 핵심 훅

partition이 할당/해제될 때 콜백을 받아 상태를 정리한다:

consumer.subscribe(Arrays.asList("orders"), new ConsumerRebalanceListener() {
    @Override
    public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
        // partition을 잃기 전에 처리 중인 offset을 commit (유실 방지)
        consumer.commitSync();
        // state store 정리 등
    }

    @Override
    public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
        // 새 partition 할당 시 초기화 (예: offset seek, 캐시 갱신)
    }
});

이 훅이 rebalance 중 데이터 유실/중복을 막는 핵심이다. 멱등 처리와 함께 써야 at-least-once를 지킨다.

Kafka 4.3 실습 — 직접 확인하기

사전: KRaft 단일 노드, grp-demo topic(--partitions 4), 메시지 다수 사전 produce.

group 상태와 할당 확인

# Kafka 4.3, KRaft 단일 노드
bin/kafka-consumer-groups.sh --describe --group g-state --state --bootstrap-server localhost:9092

COORDINATOR (ID)     ASSIGNMENT-STRATEGY   STATE     #MEMBERS
localhost:9092 (0)   range                 Stable    4

확인할 것: STATE(Stable/PreparingRebalance/CompletingRebalance), 멤버 수.

partition 할당 분포

bin/kafka-consumer-groups.sh --describe --group g-state --members --verbose --bootstrap-server localhost:9092

다중 consumer 병렬 실습

터미널 3개를 열어 같은 group으로 consumer를 각각 띄운다:

# 터미널 1
bin/kafka-console-consumer.sh --topic grp-demo --group demo-group --bootstrap-server localhost:9092
# 터미널 2 (같은 group)
bin/kafka-console-consumer.sh --topic grp-demo --group demo-group --bootstrap-server localhost:9092
# 터미널 3 (같은 group)
bin/kafka-console-consumer.sh --topic grp-demo --group demo-group --bootstrap-server localhost:9092

메시지를 produce하면 3개 consumer가 partition을 나눠 각자 다른 메시지를 받는다. 한 consumer를 종료(Ctrl+C)하면 → rebalance → 남은 consumer가 그 partition을 이어받는다.

차세대 rebalance 프로토콜 활성화

# consumer 설정에 추가
group.protocol=consumer

이 설정으로 4.0 차세대 프로토콜 활성 → rebalance 멈춤 최소화.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"consumer를 늘리면 무조건 빨라진다"	partition 수가 상한. 초과분은 idle
"다른 consumer group은 메시지를 나눠 갖는다"	각 그룹이 독립적으로 전체 소비
"rebalance는 순식간이라 무시해도 된다"	구형에선 stop-the-world. 빈번 재시작은 처리량 저하
"partition.assignment.strategy는 항상 설정해야"	차세대 프로토콜 활성 시 사용 불가

더 깊이

static membership(KIP-345): group.instance.id로 고정 identity. 재시작 시 rebalance 최소화 → 상태 저장 앱에 유리.
assignment 전략 선택: CooperativeStickyAssignor(권장)가 가장 적은 이동으로 rebalance.
rebalance 리스너와 at-least-once: onPartitionsRevoked에서 commit하지 않으면, partition 이관 시 미처리 메시지가 중복/유실.

요약 — 이 글의 결론

consumer group = 같은 group 이름의 consumer 모임. partition을 겹치지 않게 나눠 읽음.
핵심 규칙: partition 1개 = consumer 1명. 병렬성 상한 = partition 수.
group 간 독립: 각 group이 전체 topic을 따로 소비(자기 offset 관리).
설정: group.id가 팀 식별자. partition.assignment.strategy로 할당 알고리즘 선택.
rebalance: 멤버십 변화 시 재분배. 구형=stop-the-world, 차세대(4.0 GA, group.protocol=consumer)=변경분만 교체.
ConsumerRebalanceListener: onPartitionsRevoked에서 commit+정리 → rebalance 중 유실/중복 방지.

생각해 볼 문제

consumer group이 "partition을 겹치지 않게 나눠 읽는 팀"이라는 것이 왜 필요한가?
partition 6개에 consumer 4개. 각 consumer는 몇 partition? 8개로 늘리면?
주문 처리 group과 분석 group이 같은 topic을 읽을 때 서로 간섭이 없는 이유는?
rebalance가 일어나는 상황 세 가지. 구형에서 왜 "stop-the-world"가 문제인가?
차세대 rebalance 프로토콜(4.0)을 활성화하는 설정은?
ConsumerRebalanceListener의 onPartitionsRevoked에서 해야 할 일은?
CooperativeStickyAssignor가 기본 RangeAssignor보다 나은 점은?

참고

KafkaConsumer.java (consumer group, rebalance) - 접근 2026-07-09
Consumer Rebalance Protocol (4.0 GA) - 접근 2026-07-09
Consumer configs - 접근 2026-07-09
KIP-429(cooperative rebalance), KIP-345(static membership), KIP-848(차세대 rebalance protocol)

Kafka - 04. consumer

dongka — Thu, 9 Jul 2026 17:23:56 +0900

consumer — topic에서 메시지를 읽는 주체

orders topic에 주문 이벤트가 쌓인다. 이제 그 메시지를 읽어 처리해야 한다 — 주문 처리 서비스가 읽어가고, 분석 서비스가 따로 읽는다. 이 "topic에서 메시지를 읽는 주체"가 consumer다.

이 글은 consumer가 뭔지부터 시작해, 실제 설정과 코드, auto-commit의 위험, LAG 모니터링까지 다룬다.

consumer란 — topic에서 메시지를 읽는 클라이언트

consumer도 producer처럼 앱에 내장되는 클라이언트 라이브러리다.

Java consumer 기본 코드

// 1. 설정
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("group.id", "order-processors");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("enable.auto.commit", "false");  // 수동 commit (신뢰성)

// 2. consumer 생성 + 구독
Consumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("orders"));

// 3. poll loop
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
    for (ConsumerRecord<String, String> record : records) {
        processOrder(record.value());  // 비즈니스 처리
    }
    consumer.commitSync();  // 처리 후 commit (at-least-once)
}

consumer는 어떻게 쓰이나 — worked scenario

주문 처리 서비스: orders topic을 구독 → poll()로 새 주문 batch 당겨옴 → 각 주문 처리(재고·결제·배송) → offset commit.

flowchart LR
    T[orders topic] -->|poll| C[consumer]
    C -->|처리| B[(재고·결제)]
    C -->|commit| OS["__consumer_offsets"]

consumer는 pull이다 — broker가 밀어넣지 않는다

"producer가 쓰면 consumer에게 push된다"가 아니다. consumer가 능동적으로 poll()로 당겨온다. broker는 요청 없이 안 보낸다. 왜 pull — consumer가 자기 속도 제어(backpressure), replay(과거부터 다시) 자연스러움.

offset — 읽기 커서, 영속 저장

consumer는 "어디까지 읽었나"를 offset으로 기억:

__consumer_offsets 내부 topic에 영구 저장(메모리 아님).
compacted → 같은 key의 최신 offset만 유지.
consumer 장애 후 재시작해도 이어서 읽음.

auto-commit의 위험 — 메시지가 조용히 사라진다

기본값 enable.auto.commit=true는 poll 직후(처리 전)에 offset을 넘길 수 있다. 처리 중 크래시 → 재시작 시 이미 commit된 offset부터 → 그 메시지들 영영 유실.

sequenceDiagram
    participant C as consumer (auto-commit)
    participant B as broker
    C->>B: poll() → batch[m1,m2,m3]
    Note over C: auto-commit: offset=m4 (처리 전!)
    C->>C: m1 처리 중 크래시
    Note over C: 재시작 → 다음 poll은 m4부터
    Note over C: m1,m2,m3 유실

해법: enable.auto.commit=false + 처리 후 수동 commit → at-least-once. 단, 재시도 시 중복 가능 → 처리 로직은 멱등(같은 입력 여러 번 처리해도 같은 결과)이어야 함.

consumer.properties — 전체 설정 예제

신뢰성 우선 (수동 commit)

bootstrap.servers=localhost:9092
group.id=order-processors

key.deserializer=org.apache.kafka.common.serialization.StringDeserializer
value.deserializer=org.apache.kafka.common.serialization.StringDeserializer

# 수동 commit (신뢰성)
enable.auto.commit=false

# poll loop 건강
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=3000

# offset reset (committed 없을 때)
auto.offset.reset=earliest

처리량 튜닝

fetch.min.bytes=1048576    # 1MB까지 모아서 fetch
max.poll.records=1000

kafka-consumer-groups.sh — group 관리 명령

# group 목록
bin/kafka-consumer-groups.sh --list --bootstrap-server localhost:9092

# group 상세 (offset, LAG)
bin/kafka-consumer-groups.sh --describe --group order-processors --bootstrap-server localhost:9092

GROUP             TOPIC       PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
order-processors  orders      0          150             155             5
order-processors  orders      1          200             200             0

LAG — consumer가 못 따라가는 정도

LAG = LOG-END-OFFSET − CURRENT-OFFSET. LAG이 크고 자라면 consumer가 처리량 못 감당 → consumer 추가(≤ partition 수) 또는 처리 경량화.

offset reset

# group의 offset을 처음으로 reset
bin/kafka-consumer-groups.sh --reset-offsets --group order-processors \
  --topic orders --to-earliest --execute --bootstrap-server localhost:9092

# 특정 offset으로 reset
bin/kafka-consumer-groups.sh --reset-offsets --group order-processors \
  --topic orders:0 --to-offset 100 --execute --bootstrap-server localhost:9092

Kafka 4.3 실습 — 직접 확인하기

읽기 + offset 확인

# Kafka 4.3 — 신규 group, 처음부터
bin/kafka-console-consumer.sh --topic cons-demo --group g1 \
  --from-beginning --bootstrap-server localhost:9092

# 같은 group으로 재실행 → committed offset부터 (출력 없음, 이미 끝)
bin/kafka-console-consumer.sh --topic cons-demo --group g1 \
  --bootstrap-server localhost:9092

확인할 것: 같은 group이면 committed offset 이어받음(--from-beginning 무시됨).

LAG 확인

bin/kafka-consumer-groups.sh --describe --group g1 --bootstrap-server localhost:9092

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"consumer는 broker가 push"	pull(poll) 기반
"auto-commit이 안전하다"	반대. 처리 전 commit → 유실 위험
"offset은 메모리에만"	`__consumer_offsets`에 영구 저장
"--from-beginning이 항상 처음부터"	committed offset 있으면 무시됨
"처리가 느려도 괜찮다"	`max.poll.interval.ms` 초과 → 그룹 퇴출

더 깊이

position vs committed offset: position(메모리, 다음 읽을 offset) vs committed(영구). 차이가 중복의 원인.
partition별 개별 commit: commitSync(offsets)로 처리 완료한 partition만 부분 commit.
auto.offset.reset: committed 없을 때만 동작(earliest/latest/none).

요약 — 이 글의 결론

consumer = 앱 내장 클라이언트. poll()로 topic에서 읽어 처리. pull 기반.
offset = 읽기 커서. __consumer_offsets에 영구 저장.
auto-commit 위험: 처리 전 commit → 유실. enable.auto.commit=false + 수동 commit → at-least-once.
at-least-once → 중복 가능 → 처리 로직은 멱등 필수.
consumer.properties: group.id, enable.auto.commit=false, poll loop 설정.
LAG = LOG-END-OFFSET − CURRENT-OFFSET. consumer 지연 지표.
consumer-groups.sh: list, describe(LAG 확인), reset-offsets.

생각해 볼 문제

consumer가 "pull"인 것이 왜 설계상 유리한가?
offset이 영구 저장된다는 것이 왜 중요한가?
auto-commit이 메시지 유실을 일으키는 과정을 설명하라.
수동 commit으로 at-least-once를 달성하면 왜 중복이 생기는가?
consumer.properties에서 신뢰성을 위한 핵심 설정 3가지는?
LAG이 자라면 어떤 조치를 취할 수 있는가?
kafka-consumer-groups.sh로 LAG을 확인하는 명령은?

참고

KafkaConsumer.java (poll loop) - 접근 2026-07-09
Implementation — distribution.md (offset tracking) - 접근 2026-07-09
Consumer configs - 접근 2026-07-09

Kafka - 03. producer

dongka — Thu, 9 Jul 2026 16:35:39 +0900

producer — 메시지를 topic에 보내는 주체

쇼핑몰 주문 API가 주문 이벤트를 orders topic에 넣는다(장 02). 이때 "메시지를 topic에 보내는 주체"가 producer다. 애플리케이션에 내장되는 클라이언트로, producer.send(...) 한 줄로 메시지를 쏜다.

이 글은 producer가 뭔지부터 시작해, 실제 설정과 코드로 어떻게 쓰는지, acks·idempotent producer로 신뢰성을 어떻게 확보하는지까지 다룬다.

producer란 — topic에 메시지를 보내는 클라이언트

producer는 앱에 내장되는 클라이언트 라이브러리다. 별도 서버가 아니라, 주문 API·배치 잡·로그 수집기 같은 앱 프로세스 안에서 동작한다.

Java producer 기본 코드

// 1. 설정
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "all");
props.put("enable.idempotence", "true");

// 2. producer 생성
Producer<String, String> producer = new KafkaProducer<>(props);

// 3. 메시지 전송
producer.send(new ProducerRecord<>("orders", "order-123", "주문 데이터"));

// 4. 종료
producer.close();

producer는 어떻게 쓰이나 — worked scenario

사용자가 "결제" 버튼을 누르면: 주문 API가 DB에 저장 → producer로 orders topic에 이벤트 전송 → 주문 처리·분석·알림 서비스가 각자 소비(장 02 시나리오).

flowchart LR
    U[결제 클릭] --> API[주문 API]
    API -->|1. DB 저장| DB[(주문 DB)]
    API -->|2. producer.send| P[producer]
    P -->|메시지| T[orders topic]
    T --> C1[주문 처리]
    T --> C2[분석]

send는 비동기다 — 즉시 반환, 뒤에서 전송

send()는 비동기. 즉시 Future를 반환하고, 실제 전송은 배경 스레드(sender)가 처리. 애플리케이션이 broker 응답을 기다리며 멈추지 않도록 한다.

flowchart LR
    A["send(record)"] --> ACC["accumulator<br/>(batch 모음)"]
    ACC --> SND["sender 스레드<br/>(배경 전송)"]
    SND --> L["broker"]

send 콜백으로 성공/실패 확인

producer.send(new ProducerRecord<>("orders", "order-123", "data"), (metadata, exception) -> {
    if (exception == null) {
        System.out.println("전송 성공: " + metadata.partition() + "/" + metadata.offset());
    } else {
        System.err.println("전송 실패: " + exception.getMessage());
    }
});

batch — 왜 모아서 보내는가

메시지를 하나씩 보내지 않고 여러 개를 batch로 모아 보낸다. linger.ms(대기)나 batch.size(크기)에 도달하면 전송. 네트워크 왕복 비용을 줄인다.

batch는 압축과 짝 — batch로 뭉쳐야 압축 효율이 올라간다. linger.ms=0 + 압축은 무의미(메시지 1개씩이라 압축 안 걸림).

acks — "얼마나 확실히 썼다고 볼 것인가"

`acks`	의미	신뢰성	언제
`0`	확인 안 기다림	가장 낮음	손실 감내 로그
`1`	리더까지만 확인	중간	성능 우선
`all`(`-1`)	리더 + ISR 전원 확인	가장 높음	신뢰성 필수

acks=all은 min.insync.replicas(예: 2)와 세트여야 의미 — ISR이 1개면 사실상 신뢰성 없음. 프로덕션 표준: replication.factor=3, min.insync.replicas=2, acks=all(장 06).

idempotent producer — 재시도해도 중복이 안 생기는 비밀

재시도를 켜면 같은 메시지가 두 번 쓰일 수 있다. idempotent producer는 broker가 중복을 걸러낸다:

enable.idempotence=true → broker가 PID 발급 → 각 메시지에 sequence number → 중복 검출.

4.x 기본값은 true. 구형 자료(false 기본)와 혼동 주의.

idempotent 모드는 acks=all, retries>0, max.in.flight<=5를 자동 강제.

producer.properties — 전체 설정 예제

신뢰성 우선 (프로덕션 권장)

# 연결
bootstrap.servers=localhost:9092

# 직렬화
key.serializer=org.apache.kafka.common.serialization.StringSerializer
value.serializer=org.apache.kafka.common.serialization.StringSerializer

# 신뢰성
acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5

# 배치/처리량
linger.ms=10
batch.size=16384
compression.type=zstd

# 재시도 상한 (총)
delivery.timeout.ms=120000
request.timeout.ms=30000

처리량 우선 (로그 수집)

acks=1
linger.ms=50
batch.size=131072
compression.type=zstd

→ 지연 수십 ms 희생, 처리량·네트워크 효율 최대.

지연 최소 (실시간 이벤트)

acks=1
linger.ms=0
compression.type=none

→ 처리량 희생, end-to-end 지연 최소.

Kafka 4.3 실습 — 직접 확인하기

console-producer

# Kafka 4.3, KRaft 단일 노드
bin/kafka-console-producer.sh --topic prod-demo --bootstrap-server localhost:9092
>Hello
>World

확인할 것: 각 줄이 topic에 메시지로 들어감. 다른 터미널에서 consumer로 읽어 확인.

key와 함께 produce

bin/kafka-console-producer.sh --topic prod-demo \
  --property "parse.key=true" --property "key.separator=:" \
  --bootstrap-server localhost:9092
# userA:evt1 / userA:evt2 / userB:evt3

확인할 것: 같은 key는 같은 partition으로 감(장 02).

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"producer는 별도 서버다"	앱에 내장되는 클라이언트
"send() 반환됐으면 broker에 도달했다"	비동기. accumulator에 있을 수 있음
"acks=1이면 안전하다"	리더 장애 시 미복제 손실 위험
"재시도하면 무조건 중복"	idempotent(4.x 기본)는 broker가 제거
"linger.ms=0이 항상 빠르다"	지연은 최소지만 처리량은 낮음
"4.x도 idempotence=false 기본"	아니다. 4.x는 기본 true
"압축은 producer만 손해"	broker가 압축된 채 저장·전송

더 깊이

max.in.flight와 순서: 1보다 크면 재시도 시 순서 뒤바뀔 수 있음. idempotent 모드는 5 이하로 제한해 순서 보존.
delivery.timeout.ms: 총 재시도 상한(기본 2분). 시간 기반 모델(무한 retries 아님).
transactional producer: transactional.id로 여러 partition 원자 쓰기 → EOS(장 08).
JMX metrics: record-send-rate, retry-rate(높으면 불안정), batch-size-avg.

요약 — 이 글의 결론

producer = 앱 내장 클라이언트. send()로 topic에 메시지.
비동기 send: accumulator→sender 배경 전송. 콜백으로 성공/실패 확인.
batch: linger.ms/batch.size로 모아 효율↑. 압축과 세트.
acks: 0/1/all. all은 min.insync.replicas와 세트.
idempotent producer(4.x 기본): PID+sequence로 중복 제거 + 순서 보존.
설정 프로필: 신뢰성 우선(acks=all+idempotent) / 처리량 우선(linger 큼) / 지연 최소(linger=0).

생각해 볼 문제

producer가 "앱 안의 클라이언트"라는 것이 운영상 어떤 의미인가?
send()가 비동기인 것을 어떻게 확인하는가? (콜백)
acks=0/1/all의 차이를 복제 관점에서 설명하라.
idempotent producer가 중복을 어떻게 제거하는가? 4.x 기본값은?
신뢰성 우선 producer.properties를 작성해 보라.
linger.ms=0 + compression이 무의미한 이유는?

참고

Producer configs (producer-configs.txt) - 접근 2026-07-09
ProducerConfig.java (idempotence/delivery.timeout) - 접근 2026-07-09
KIP-98(idempotent producer/transactions), KIP-588(zombie fencing)

Kafka - 02. topic and partition

dongka — Thu, 9 Jul 2026 15:40:07 +0900

topic과 partition — 메시지를 어디에, 어떻게 쌓을 것인가

쇼핑몰에서 주문이 들어온다. 이 주문 데이터를 어디에 쌓을까? Kafka에선 topic이라는 곳에 넣는다. "주문" topic, "클릭 로그" topic, "결제" topic처럼 용도별로 topic을 나눠 메시지를 분류한다. 그런데 주문이 초당 수만 건씩 쏟아지면 topic 하나로는 감당이 안 된다 — 그래서 topic을 여러 조각으로 쪼개는데, 그 조각이 partition이다.

이 글은 Kafka를 처음 접하는 사람이 topic과 partition을 "확" 이해하도록, 기초부터 차근차근 쌓아 올린다. topic이 뭔지, 어떻게 쓰이는지부터 시작해 partition이 왜 필요한지, key가 뭔 역할을 하는지, 그리고 "partition 수를 나중에 바꾸면 생기는 일"까지. 어려운 구현 디테일(murmur2 해시 등)은 마지막 심화로 미뤘다.

topic이란 — 메시지를 담는 이름 붙인 상자

topic은 가장 단순하게 말하면 "메시지를 담는, 이름 붙인 상자(또는 카테고리)"다. 데이터베이스의 테이블이나 파일시스템의 폴더와 비슷하다 — 용도별로 나눠 놓는 구분선.

비유	topic에 대응
우체국의 수신처란(주문/청구/문의)	topic 이름(orders / clicks / payments)
회사의 사서함 번호	topic 이름 — 메시지가 여기로 배달됨
데이터베이스의 테이블	topic — 한 종류의 데이터를 담는 그릇

topic의 구체 예

실제 서비스에선 이렇게 topic을 나눈다:

orders — 주문 이벤트 (주문 생성, 취소, 상태 변경)
user-clicks — 사용자 클릭 로그 (UX 분석용)
payments — 결제 요청/완료
shipping-events — 배송 상태
__consumer_offsets — (내부용) consumer가 어디까지 읽었나

topic 이름은 용도를 드러내게 짓는 게 관례다. t1, test 같은 이름은 운영에서 혼란을 만든다.

topic의 핵심 성질 (장 01 복습)

topic은 로그(log)다 — 메시지가 들어온 순서대로 계속 append되고, consumer가 읽어도 지워지지 않는다(retention 정책이 닿기 전까지). 그래서 여러 consumer가 같은 topic을 각자 따로 읽을 수 있고, 나중에 다시 읽을(replay) 수도 있다. 이게 일반 "큐"(소비하면 사라짐)와 topic의 결정적 차이다.

topic은 어떻게 쓰이나 — worked scenario

추상 정의만으론 감이 안 온다. 쇼핑몰의 orders topic이 실제로 어떻게 쓰이는지 보자.

flowchart LR
    P1[주문 API 서버] -->|주문 이벤트 produce| T["orders topic"]
    P2[모바일 앱] -->|주문 이벤트 produce| T
    T -->|consume| C1[주문 처리 서비스<br/>재고 차감·결제]
    T -->|consume| C2[분석 파이프라인<br/>일별 매출 집계]
    T -->|consume| C3[알림 서비스<br/>주문 확인 이메일]

이 시나리오가 topic의 가치를 보여준다:

여러 곳에서 쓴다(multi-producer): 주문 API 서버와 모바일 앱이 모두 orders topic에 주문 이벤트를 쓴다. 어디서 왔든 같은 topic에 쌓인다.
여러 곳에서 읽는다(multi-consumer): 주문 처리 서비스(재고 차감), 분석 파이프라인(매출 집계), 알림 서비스(이메일)가 각자 독립적으로 같은 orders topic을 읽는다. 한 consumer가 느려져도 다른 consumer는 영향 안 받는다.
나중에 다시 읽을 수 있다(replay): 분석에서 버그를 발견하면, 지난주 주문 데이터를 orders topic에서 다시 읽어 재처리할 수 있다(메시지가 남아있으므로).

이게 topic을 단순 "메시지 큐"가 아니라 이벤트의 영속 저장소로 쓰는 방식이다. 서비스들이 topic을 사이에 두고 느슨하게 연결되는 구조(이벤트 기반 아키텍처)의 기반이 된다.

topic을 만들 때: bin/kafka-topics.sh --create --topic orders --partitions 3 --replication-factor 1 --bootstrap-server localhost:9092. 여기서 --partitions 3이 바로 다음에 볼 partition이다.

topic 하나로 충분한가 — 왜 partition이 필요한가

주문이 초당 10건이면 topic 하나(partition 1개)로 충분하다. 하지만 주문이 초당 수만 건으로 늘면? topic을 하나의 줄(로그)로만 처리하면:

쓰기가 한 곳에 몰림 — 한 broker만 바쁘고, 다른 broker는 한가함.
읽기도 한 줄 — consumer를 여럿 띄워도 한 줄을 순서대로 읽어야 하니 병렬 처리가 안 됨.

해법: topic을 여러 조각(partition)으로 쪼개 각 조각을 다른 broker에 두고, consumer도 각 조각을 나눠 읽는다. 이게 partition의 탄생 동기다. "topic은 논리적 분류, partition은 물리적 분할"이라고 한 줄로 요약할 수 있다.

partition이란 — topic을 쪼갠 물리적 조각

partition은 topic을 물리적으로 나눈 조각이다. topic orders에 partition 3개를 두면:

partition 0, partition 1, partition 2 — 각각 독립된 append-only 로그.
메시지는 (key 유무에 따라) 어느 partition으로 갈지 정해져 들어간다.
각 partition은 (복제본 제외) 단일 broker에 저장되어 부하가 분산된다.

flowchart TB
    T["topic: orders<br/>(논리적 분류)"] --> P0["partition 0<br/>(물리적 로그)"]
    T --> P1["partition 1"]
    T --> P2["partition 2"]
    P0 --> B0["broker 0"]
    P1 --> B1["broker 1"]
    P2 --> B2["broker 2"]

partition은 세 가지의 최소 단위다

partition은 Kafka에서 세 가지 의미의 최소 단위를 동시에 뜻한다:

데이터 분할 단위 — 각 partition은 단일 broker에 저장. topic 전체 데이터가 partition 수만큼 분산.
병렬성 단위 — consumer group 내에서 partition 1개당 최대 consumer 1개가 병렬 소비. 즉 partition 수 = consumer 병렬성의 상한.
순서 보장 단위 — partition 내에서만 쓴 순서대로 읽힌다. topic 전체 순서 보장은 없다.

(basic-kafka-operations.md): partition 수가 "데이터를 몇 개 로그로 샤딩할지"와 "consumer 최대 병렬성"을 결정한다.

이 셋이 한 몸이라는 게 핵심이다. 병렬성을 늘리려 partition을 늘리면 순서 보장 범위가 쪼개진다 — partition 수 선택은 병렬성 vs 순서 보장 범위의 트레이드오프다.

key가 partition을 고정한다 — 같은 key는 같은 partition으로

producer가 메시지에 key를 주면, 같은 key는 항상 같은 partition으로 간다. 왜 필요한가 — 같은 사용자의 주문이 여러 partition에 흩어지면 순서가 꼬인다. "사용자 A의 주문"이 항상 같은 partition에 있어야 그 사용자 이벤트를 순서대로 처리할 수 있다.

구체 예:

key = "userA"인 메시지 → 항상 partition 1로 감(예). "userA"의 모든 주문이 partition 1에 순서대로 쌓임.
key = "userB" → 항상 partition 0으로 감(예).
key 없음(null) → sticky: 한 batch를 같은 partition에 몰아넣어 효율을 높임. key 기반 순서가 필요 없는 로그에 적합.

어떻게 partition이 정해지나 — key를 해시해서 partition 수로 나눈다(자세한 공식은 심화 절에서). 핵심은 같은 key → 항상 같은 partition이라는 보장이다.

partition이 정해지는 방식을 모르면 "key를 줬는데 왜 어떤 사용자는 빨리 처리되고 어떤 사용자는 늦지?" 같은 현상의 원인(partition 쏠림)을 못 찾는다.

partition 수를 늘리면 같은 key가 다른 partition으로 간다

이제 위에서 쌓은 기초가 필요한 부분이다. topic을 만들 때 partition 3개로 잡았다. 처리량이 부족해 5로 늘리기로 했다. "빈 공간이 두 개 더 생기겠지"라고 생각한다면 — 위험하다.

partition을 늘리는 순간, 기존에 특정 partition에 가던 key가 다른 partition으로 갈 수 있다. key가 "userA"라 partition 1에 가던 메시지가, partition이 5개가 되면 partition 3으로 갈 수 있다. 같은 key의 메시지가 partition 경계에서 순서가 끊기는 것이다.

flowchart LR
    A["partition 3개<br/>key 'userA' → partition 1"] -->|alter --partitions 5| B["partition 5개"]
    B --> C["key 'userA' → partition 3<br/>(매핑 변화)"]
    C --> D["key 기반 순서 보장 파손<br/>(기존 메시지는 옮겨지지 않음)"]

왜? partition 결정이 hash(key) % partition수라서, partition수가 바뀌면 결과가 달라지기 때문이다. 공식 문서가 명시하는 부작용 (basic-kafka-operations.md):

key 분포 변화: Kafka Streams 등 key 기반 상태를 쓰는 앱의 순서·상태 가정이 깨짐.
consumer 데이터 누락 위험: auto.offset.reset=latest인 consumer가 새 partition을 인지 못하는 찰나에 메시지를 놓칠 수 있음.
메타데이터 전파 지연: 클러스터 전체에 새 partition 정보가 퍼지는 데 시간차.

주의: partition을 늘려도 기존 메시지는 옮겨지지 않는다. userA의 과거 메시지는 partition 1에 그대로 있고, 새 메시지는 partition 3으로 간다.

절대 금지: 내부 topic(__consumer_offsets, __transaction_state, __cluster_metadata)의 partition을 수동으로 늘리면 시스템 장애. 이들은 Kafka가 스스로 관리한다.

partition은 왜 줄일 수 없는가

"그럼 모자라면 늘리고, 너무 많으면 줄이면 되겠지?" — 줄일 수 없다. Kafka는 partition 감소를 지원하지 않는다. 이유:

메시지는 이미 특정 partition에 영속됐다. 합치려면 offset을 다시 매겨야 하는데, 이미 commit된 consumer offset과 어긋난다.
두 partition의 메시지 사이엔 정의된 전체 순서가 없었으므로(그게 partition의 전제), 합쳐서 시간순으로 다시 엮는 게 불가능하다.
ISR 복제본들도 같은 재구성을 동시에 해야 한다.

그래서 줄이려면 새 topic을 만들고 데이터를 이주(migrate)하는 수밖에 없다. 설계 단계에서 넉넉히 잡되, key 매핑 깨짐을 감수할 수 없다면 partition 수를 사실상 고정으로 설계해야 한다.

partition 수는 어떻게 정하나

공식 문서는 절대 권장값을 명시하지 않는다. 다음 기준으로 산정한다:

기준	관계
처리량	partition ↑ → 병렬 쓰기/읽기 ↑ (broker 한계까지)
consumer 병렬성	consumer 수 ≤ partition 수 (초과분은 idle)
broker 부하	partition ↑ → 파일 수·메모리 ↑
장애 복구	partition ↑ → 복구 시간 ↑
순서 보장	partition ↑ → key 순서 보장 범위 세분화

사이징 예(수치는 가정): 초당 100MB 목표, partition당 ~ 10MB 측정 → 최소 10 partition. consumer 병렬성 상한 10. 확장 여유 1.5 ~ 2배 → 15 ~ 20으로 시작. (partition당 처리량은 실측 필수 — 공식 문서는 절대 수치를 안 준다.)

"많을수록 좋다"가 아니다 — partition당 파일 핸들·메모리가 들고, broker 장애 시 복구가 느려진다.

Kafka 4.3 실습 — 직접 확인하기

사전: KRaft 단일 노드 기동.

topic 만들고 메시지 넣기

# Kafka 4.3, KRaft 단일 노드
bin/kafka-topics.sh --create --topic part-demo --partitions 3 --replication-factor 1 --bootstrap-server localhost:9092
# key:value 형태로 produce (key가 partition 결정)
bin/kafka-console-producer.sh --topic part-demo --property "parse.key=true" --property "key.separator=:" --bootstrap-server localhost:9092
# 입력 예:
# userA:evt1
# userA:evt2
# userB:evt3

확인할 것: 같은 key(userA)는 항상 같은 partition에 기록되는가.

bin/kafka-console-consumer.sh --topic part-demo --property "print.key=true" --property "print.partition=true" --from-beginning --bootstrap-server localhost:9092

partition: 1, key: userA, value: evt1
partition: 1, key: userA, value: evt2
partition: 2, key: userB, value: evt3

실제 partition 번호는 해시 결과에 따라 달라진다. 핵심은 같은 key → 같은 partition.

partition 추가와 key 매핑 변화 관찰

bin/kafka-topics.sh --alter --topic part-demo --partitions 5 --bootstrap-server localhost:9092
bin/kafka-console-producer.sh --topic part-demo --property "parse.key=true" --property "key.separator=:" --bootstrap-server localhost:9092
# userA:evt4  (새로 입력)
bin/kafka-console-consumer.sh --topic part-demo --property "print.key=true" --property "print.partition=true" --from-beginning --bootstrap-server localhost:9092

확인할 것: userA의 evt1/evt2는 partition 1에 있었지만, evt4는 partition이 바뀔 수 있다 → 같은 key의 순서가 partition 경계에서 끊긴다.

describe로 partition 상태 보기

bin/kafka-topics.sh --describe --topic part-demo --bootstrap-server localhost:9092

PartitionCount / ReplicationFactor: topic 전체 설정.
Leader / Replicas / Isr: 각 partition의 복제 상태(단일 노드에선 모두 같음; 복제는 장 06).

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"topic은 메시지 큐라서 소비하면 사라진다"	아니다. topic은 로그. 소비해도 retention 전엔 남음(장 01)
"partition 많을수록 항상 빠르다"	broker당 파일 핸들·메모리 한계. 과도하면 장애 복구 지연
"partition을 줄일 수 있다"	불가. 늘리기만. 줄이려면 새 topic으로 이주
"key 순서는 영원히 보장된다"	partition 수가 변하지 않는 한 보장. partition 증가 순간 깨짐
"partition 수 = consumer 수로 맞추면 된다"	consumer 병렬성 상한일 뿐. 처리량·broker 부하도 함께 고려
"topic 생성 후 기본값(partition 1)으로 둬도 된다"	프로덕션에선 거의 항상 부족. 명시적 `--partitions` 필수
"partition 늘리면 기존 메시지도 옮겨진다"	아니다. 과거는 그대로, 새 메시지만 새 매핑 → key 순서 끊김

더 깊이 — partition은 어떻게 정해지나 (murmur2)

위에서 "key를 해시해서 partition 수로 나눈다"고만 했다. 정확한 공식이 궁금한 사람을 위해:

key != null: toPositive(murmur2(key)) % numPartitions. 같은 key는 항상 같은 partition(결정적).
BuiltInPartitioner.java를 보면 murmur2 해시를 쓰고, 그걸 partition 수로 나눈다(모듈로).

왜 consistent hash가 아닌가 — partition 확장에 취약한 이유

Kafka 파티셔너가 consistent hash를 쓴다고 생각하는 경우가 많다. 아니다. consistent hash라면 partition 수가 변해도 대부분 key-매핑이 유지되지만, 모듈로 방식은 partition 수가 변하면 거의 모든 key의 매핑이 바뀐다. 바로 이것이 위 "partition 늘리면 key 매핑이 깨진다"의 원인이다.

murmur2는 비암호학적 해시다 — 속도가 빠르고 분산이 고른 것이 목적이지, 보안이 아니다. toPositive는 murmur2의 signed(음수 가능) 결과를 양수로 바꾸는 래퍼(음수 해시에 모듈로를 쓰면 partition 번호가 음수가 되므로).

key 기반 상태(changelog, state store)를 쓰는 Kafka Streams 앱은 "key X는 항상 partition P에 있다"를 전제로 동작한다. partition 수가 변하면 이 전제가 깨져 상태 재구성이 일어난다.

요약 — 이 글의 결론

topic = 메시지를 담는 이름 붙은 상자(카테고리). 용도별로 나눔(orders, clicks...). 로그라 소비해도 남고, 여러 consumer가 따로 읽고, replay 가능.
topic 사용: multi-producer(여러 곳에서 씀) + multi-consumer(여러 서비스가 따로 읽음). 이벤트 기반 아키텍처의 기반.
partition = topic을 물리적으로 쪼갠 조각. topic 하나의 부하를 여러 broker로 분산.
partition 세 의미: 데이터 분할 + 병렬성(=consumer 병렬성 상한) + 순서 보장(partition 내만).
key → 같은 partition: 같은 key는 항상 같은 partition. 같은 사용자 이벤트 순서 처리에 필수.
partition은 늘리기만 가능(줄이기 불가). 늘리면 key 매핑이 깨져 순서 가정 파손.
내부 topic partition 변경 절대 금지 → 시스템 장애.
partition 수 산정은 처리량·컨슈머 병렬성·broker 부하·복구의 균형. "많을수록 좋다"가 아니다.

생각해 볼 문제

topic을 "메시지 큐"가 아니라 "로그"로 부르는 것이 어떤 차이를 만드는가? (소비 후 삭제 vs 남음)
쇼핑몰에서 orders topic 하나를 주문 처리·분석·알림 서비스가 따로 읽는 것이 가능한 이유는?
topic 하나(partition 1개)로 초당 수만 건을 처리하기 어려운 이유는? partition이 어떻게 해결하는가?
partition 6개인 topic에 consumer 4개인 그룹이 있다. 각 consumer는 몇 partition을 소유하는가? consumer를 8개로 늘리면?
partition을 3→5로 늘리면 같은 key의 메시지 순서가 왜 끊기는가?
partition을 줄일 수 없는 이유는? 줄여야 한다면 어떻게 해야 하는가?
key 없이 produce하는데 cleanup.policy=compact인 topic에서 무슨 일이 벌어지는가?

참고

Basic Operations — Adding/Modifying topics - 접근 2026-07-09 (partition 증가 부작용, 내부 topic 금지)
Topic configurations - 접근 2026-07-09
Introduction — Partitioning - 접근 2026-07-09
BuiltInPartitioner (murmur2) - 접근 2026-07-09

Kafka - 01. architecture

dongka — Thu, 9 Jul 2026 14:52:15 +0900

Kafka는 큐가 아니다 — 영속적 분산 로그가 만든 모든 차이

Kafka를 처음 배우는 사람 대부분은 "메시지 큐"라는 설명을 듣고 RabbitMQ처럼 생각한다. 그래서 "소비했는데 왜 데이터가 남지?", "왜 메시지 순서가 섞이지?" 같은 오해에 빠진다. 이 오해의 뿌리는 단 하나다 — Kafka는 소비하면 사라지는 큐가 아니라, 영속적이고 파티션 내 순서가 보장되는 분산 로그다. 이 하나의 차이가 Kafka의 모든 설계(복제, 컨슈머 그룹, retention, 전달 의미론)를 설명한다.

이 글은 그 핵심 추상 — partition = append-only log — 을 중심으로 Kafka가 무엇인지, 왜 그렇게 설계됐는지, 그리고 왜 "빠르다"는 평가가 마법이 아니라 설계의 결과인지를 다룬다. retention·복제·rebalance·exactly-once가 암기 과목이 되지 않으려면, 이 로그 모델을 먼저 정확히 잡아야 한다.

Kafka는 영속적 분산 로그다

정확히 말해, Kafka의 partition 하나는 끝에만 줄을 적는 장부(append-only ledger)다. 이미 적힌 줄은 번호(offset)가 매겨지고 고정된다. 읽는 사람(consumer)은 자기가 마지막으로 읽은 줄 번호를 기억해 두고, 다음 번호부터 다시 읽는다. 여러 사람이 같은 장부의 같은 번호를 여러 번 읽을 수 있다 — 장부는 읽었다고 지워지지 않는다.

flowchart LR
    P[producer] -->|write| T["topic<br/>(multi-producer, multi-consumer)"]
    T --> PART["partition 0<br/>partition 1<br/>partition 2<br/>(각각 append-only log)"]
    PART -->|read| C1[consumer A]
    PART -->|read| C2[consumer B]

ASF 공식 문서가 강조하는 핵심 사실들: (introduction.md)

topic은 multi-producer, multi-consumer다. 여러 클라이언트가 같은 topic에 동시에 쓰고 읽는다.
소비해도 삭제되지 않는다. 전통 메시징과 달리 메시지는 consumer가 읽었다고 사라지지 않는다. 대신 topic별 retention(시간/크기) 정책으로만 삭제된다. → 같은 데이터를 여러 consumer 그룹이 독립적으로, 그리고 나중에 다시(replay) 읽을 수 있는 이유.
같은 key의 메시지는 같은 partition에, partition 내에서는 쓴 순서대로 읽힌다. (전체 topic 순서 보장은 아니다.)
데이터 크기에 관계없이 성능이 일정하다 — O(1) disk seek per read, 순차 I/O 덕분. 이것이 장기 보관을 가능하게 한다.

record — 데이터 단위의 구조

Kafka의 데이터 단위는 record(event/message)다. 1차 출처 message-format.md에 따른 구조:

필드	설명	비고
`key`	파티셔닝 키(선택). 같은 key → 같은 partition	`null` 가능 → sticky partitioning
`value`	실제 페이로드	바이트 배열. 형식 자유(JSON, Avro 등)
`timestamp`	메시지 시각	`CreateTime`(producer 지정) 또는 `LogAppendTime`(broker 지정). topic 설정 `message.timestamp.type`
`headers`	키-값 메타데이터	KIP-82, Kafka 0.11(v2 포맷)에 추가

key가 없으면(null) producer는 sticky partitioning을 쓴다 — 한 batch의 메시지를 같은 partition으로 몰아 넣어 효율을 높인다. key가 있으면 murmur2(key) % numPartitions로 partition이 결정된다(자세한 건 02장).

큐가 아니라 로그라는 게, 구체적으로 뭐가 다른가

"Kafka는 큐가 아니다"라는 말이 추상적이다. 전통 메시징(RabbitMQ 같은 AMQP 브로커)과 비교하면 차이가 선명해진다.

항목	전통 메시징(큐)	Kafka(로그)
소비 후	즉시 삭제	남아있음(retention이 지나야 삭제)
같은 메시지 재소비	불가(지워졌으므로)	가능(offset만 다시 돌리면 replay)
여러 소비자가 같은 데이터	큐는 경쟁 소비(한 메시지=한 소비자)	consumer group마다 독립적으로 전부 읽기 가능
순서 보장 단위	큐 전체(보통)	partition 내만
처리량 한계	메모리/인덱스 한계, 삭제 비용	디스크 순차 I/O → 대량 장기 보관에 유리

핵심 차이는 "소비 = 삭제" 모델이냐 "소비 = 읽기 커서 이동" 모델이냐다. RabbitMQ에서 consumer가 메시지를 ack 하면 그 메시지는 사라진다. Kafka에서 consumer가 메시지를 읽으면 broker는 아무것도 하지 않는다 — consumer가 자기 offset을 어디까지 읽었나 기억할 뿐이다. 그래서 같은 topic을 이벤트 소싱용으로도, 분석용으로도, 나중에 재처리용으로도 동시에 읽을 수 있다. 이 "읽기가 파괴적이지 않다"는 성질이 Kafka를 단순 메시지 브로커가 아니라 이벤트 스트리밍 플랫폼으로 만든다.

왜 로그인가 — Kafka가 빠른 진짜 이유

"Kafka가 빠르다"는 평가는 마법이 아니라 세 가지 설계 결정의 결과다: 순차 디스크 I/O + 일괄(batch) + zero-copy.

순차 디스크 I/O가 무작위 메모리 접근보다 빠를 수 있다

직관과 달리, 동일한 디스크에서 순차 쓰기는 무작위 읽기보다 훨씬 빠르다. Kafka는 이를 극단까지 밀어붙인다 — 모든 쓰기는 로그 끝에 append, 읽기도 offset 기준 순차 탐색. (design.md)

순차 vs 무작위 디스크 접근: 같은 디스크에서 순차가 수십~수백 배 빠르다. 7200rpm HDD 기준 순차 읽기 ~100 MB/s, 무작위 읽기는 수백 KB/s 수준. SSD는 격차가 좁지만 여전히 순차가 유리하다. (수치는 미검증, design.md의 상대적 통찰에 근거)

데이터 크기가 커져도 읽기 비용이 일정한 이유(O(1) per read)가 바로 이것이다 — offset으로 위치를 계산해 순차로 읽기 때문에, 1TB든 1GB든 읽기 단가가 같다. retention 비용이 "디스크 용량만 있으면 무한 보관 가능"이 되는 이유이기도 하다.

batch + 압축의 종단간 전달

producer는 메시지 여러 개를 한 묶음(batch)으로 모은다 — linger.ms/batch.size까지 모아 한 번에 전송해 네트워크 왕복을 최소화한다. 여기에 batch compression이 더해진다:

producer가 batch를 압축해서 broker로 보낸다.
broker는 검증을 위해 잠깐 해제하지만, 디스크엔 압축된 채 저장하고 consumer에게도 압축된 채 전송한다.
네트워크 비용이 종단간 절감된다.

zero-copy — 커널 페이지 캐시에서 소켓으로 곧장

보통 파일을 읽어 네트워크로 보내려면: 디스크 → 커널 페이지 캐시 → 사용자 공간(응용 메모리) → 커널 소켓 버퍼 → 네트워크 카드. 사용자 공간을 거치는 복사가 두 번 든다. Kafka는 sendfile(zero-copy) 로 이 복사를 건너뛴다 — 데이터가 커널 페이지 캐시에서 소켓으로 곧장 간다.

flowchart LR
    subgraph 일반["일반 전송(복사 4단계)"]
        D1[디스크] --> PC1[페이지 캐시] --> US1[사용자 공간] --> SK1[소켓 버퍼] --> N1[NIC]
    end
    subgraph ZC["Kafka zero-copy (sendfile)"]
        D2[디스크] --> PC2[페이지 캐시] --> SK2[소켓 버퍼] --> N2[NIC]
    end

게다가 Kafka는 디스크 파일을 커널 페이지 캐시에 올려두고 그대로 소비한다 — 별도의 응용 캐시를 두지 않는다. 그래서 남는 메모리가 곧 읽기 캐시가 된다. "Kafka는 메모리를 적게 쓰면서도 빠르다"는 평가의 진짜 이유.

절대 처리량(예: "초당 수백만 건")은 하드웨어·메시지 크기에 따라 폭넓게 변동한다. 공식 design 문서는 상대적 통찰(순차 » 무작위, batch/zero-copy의 효과)만 제시한다. 구체 수치는 Confluent 벤치마크(2차 출처) 참조 시 출처 명시 필수.

partition — 병렬성과 순서의 트레이드오프

단일 로그는 단순하지만 병렬성이 없다. Kafka는 topic을 partition으로 쪼개 이 문제를 푼다. 각 partition이 독립된 병렬 단위가 되어 쓰기도 분산되고 consumer도 분산된다. 대신 전체 순서는 포기하고 partition 내 순서만 보장한다는 트레이드오프를 치른다.

partition 내: 쓴 순서대로 읽힌다(단일 로그의 순서 보장).
partition 간: 순서 보장 없음.
전체 topic 순서가 꼭 필요하면 partition=1로 둬야 한다 — 병렬성을 포기하는代价로.

partition 수는 어떻게 정하나

이게 자주 묻는 질문이고, 정답은 "상황에 따라"다. trade-off를 보자:

partition을 늘리면	대가
병렬성↑(consumer 동시 처리↑)	broker가 관리할 partition 파일·리더 수↑(파일 핸들·메모리)
처리량↑	rebalance 비용↑(partition이 많을수록 재분배가 느림)
	리더 선출·복제 부하↑

공식 문서는 단일 정답을 주지 않는다 — 목표 처리량·컨슈머 수·클러스터 규모로 산정한다. (구체 권장값은 없으니 "미겕안" 표식 없이 단정하지 말 것.) 일반적으로 "당장 필요한 것보다 약간 여유"로 시작하고, 모니터링하면 늘린다. partition 수를 줄이는 것은 지원되지 않는다는 것도 기억하라 — 늘리기만 가능하다(02장 상세).

produce 경로 — 메시지가 broker에 도달하기까지

producer가 send(record)를 부르면 메시지가 즉시 broker로 가는 게 아니다. accumulator에 쌓였다가 batch로 묶여 간다.

sequenceDiagram
    participant P as producer
    participant ACC as accumulator(batch)
    participant L as partition leader broker
    participant F as ISR follower brokers
    P->>ACC: send(record) — 직렬화+파티셔닝 후 batch 적재
    ACC->>L: batch 전송(압축)
    L->>L: 로그 끝에 append
    L->>F: 복제(팔로워 fetch)
    F-->>L: ACK (HW 갱신)
    L-->>P: ack (acks 설정에 따라)

단계	일어나는 일	비고
파티셔닝	`key` 있으면 `toPositive(murmur2(key)) % numPartitions`로 partition 결정. `key` 없으면 sticky	BuiltInPartitioner.java. murmur2, consistent hash 아님
batch 적재	`linger.ms`/`batch.size`까지 모아 한 번에 전송	네트워크 왕복 최소화
leader append	partition 리더 broker가 로그 끝에 기록	순차 I/O
복제	ISR 팔로워들이 리더에서 fetch해 복제	장 06 상세
ack	`acks` 설정(0/1/all)에 따라 producer에게 확인	장 03/08 상세

acks — "얼마나 확실히 썼다고 볼 것인가"

producer가 메시지를 보낸 뒤 broker에게 확인(ack)을 기다리는 강도를 acks가 결정한다. 이 한 설정이 성능과 신뢰성의 균형을 잡는다.

`acks`	의미	잃을 수 있는 것	대표 용도
`0`	broker 응답 안 기다림(fire and forget)	broker가 받기도 전에 네트워크에서 사라지면 유실	로그·메트릭 등 손실 감내 가능한 고처리량
`1`	리더만 확인(리더 장애 직전에 받고 복제 전이면 유실 가능)	리더 장애 시 미복제 메시지 유실	성능과 신뢰성 절충
`all`(`-1`)	ISR 전원 확인(복제까지 끝나야 성공)	ISR 전원 장애가 아니면 유실 없음	신뢰성 최우선(금융·주문)

acks=all이 "가장 안전"이지만 단독으론 부족하다 — ISR이 1개만 남으면 그 1개만 확인하면 성공이므로 사실상 신뢰성이 없다. 그래서 min.insync.replicas(예: 2)와 세트로 써야 ISR 미달 시 쓰기를 거부하게 만든다. 이 조합(replication.factor=3, min.insync.replicas=2, acks=all)이 프로덕션 표준이다(장 06·08 상세).

idempotent producer(enable.idempotence=true)는 acks=all을 자동 강제한다 — 재시도 중 중복을 막으려면 복제 완료가 보장돼야 하므로. 이 설정 관계는 장 08(exactly-once)의 핵심이다.

consume 경로 — consumer가 데이터를 당기는 방식

여기서 자주 틀린다. "producer가 쓰면 consumer에게 push된다"가 아니다. consumer가 능동적으로 poll()로 당겨온다. broker는 consumer가 요청하지 않으면 아무것도 보내지 않는다.

sequenceDiagram
    participant C as consumer
    participant L as partition leader broker
    participant OS as __consumer_offsets
    C->>C: poll() 호출
    C->>L: Fetch 요청(이전 offset부터)
    L-->>C: batch 반환(압축 해제)
    C->>C: 애플리케이션 처리
    C->>OS: offset commit(자동/수동)

consumer는 poll loop로 당긴다. 한 번에 여러 메시지 batch가 반환된다.
offset은 __consumer_offsets 내부 topic에 저장된다(0.9부터 ZooKeeper에서 이관). 장 04 상세.
같은 offset을 여러 번 읽을 수 있다(replay). consumer가 자기 offset만 기억하면 된다.

왜 pull인가

broker가 consumer에게 push하는 대신 consumer가 당기게 한 이유는 세 가지다 (design.md: Push vs. pull):

consumer가 자기 속도를 스스로 제어 → 압도당하지 않는다(backpressure가 자연스럽다).
broker가 consumer 상태를 추적할 부담이 줄어든다.
replay(과거 offset부터 다시 읽기)가 자연스럽다 — push 모델에선 불가능하거나 어렵다.

offset — consumer의 읽기 커서, 그리고 로그가 사라지는 조건

offset은 partition 내 각 메시지의 단조증가 번호다. consumer는 "어디까지 읽었나"를 offset으로 기억하고, 다음 poll부터 그 다음 offset을 요청한다. 두 가지를 짚고 넘어가야 한다.

offset commit — consumer가 읽은 위치를 영속화하는 행위. 자동(enable.auto.commit=true, poll 주기마다)과 수동(애플리케이션이 처리 완료 후 명시 commit)이 있다. 자동이 편하지만 함정이 있다 — "읽고 commit 했는데 처리가 실패하면 그 메시지는 영영 사라진다(최소 한 번 at-least-once 위반 방향)". 신뢰성이 중요하면 수동 commit이 필요하다(장 04·08).

retention — 로그가 사라지는 조건. consumer가 읽든 안 읽든 상관없이, 메시지는 retention 정책이 도달하면 삭제된다:

retention.ms(시간, 기본 168시간=7일) 또는 retention.bytes(크기) 중 먼저 도달한 쪽이 삭제를 발동시킨다.
둘 다 설정하면 OR가 아니라 "먼저 닿은 쪽"이다 — 이걸 단일 조건으로 오해하면 보관 기간 추정이 틀린다.

retention은 장 07에서, 정확한 전달(수동 commit·exactly-once)은 장 08에서 다룬다. 여기선 "소비해도 지워지지 않되, retention이 닿으면 지워진다"는 두 축만 기억하라.

왜 이렇게 설계됐나 — 네 가지 핵심 설계 결정

지금까지의 모든 것이 네 가지 질문에 대한 답으로 요약된다.

왜 로그인가? 로그는 append·순차읽기에 최적화된 가장 단순한 자료구조다. 복제·재생산(replay)·순서 보장이 모두 자연스럽다.
왜 partition인가? 단일 로그는 병렬성이 없다. partition으로 쪼개면 각 partition이 독립된 병렬 단위가 된다(쓰기도 분산, consumer도 분산). 대신 전체 순서를 포기하고 partition 내 순서만 보장한다는 트레이드오프.
왜 consumer group인가? 한 partition을 여러 consumer가 동시에 읽으면 순서가 꼬인다. 그래서 한 consumer group 내에서 각 partition은 정확히 한 consumer가 소유한다. consumer가 늘어나면 partition이 재분배(rebalance). 장 05 상세.
왜 pull인가? consumer가 속도를 스스로 제어하고, broker 부담을 줄이고, replay를 자연스럽게.

이 네 가지는 독립이 아니라 서로를 강화한다. 로그이기 때문에 partition으로 쪼개도 순서가 partition 내에 보존되고, partition이 병렬 단위이기 때문에 consumer group이 partition을 소유하는 모델이 말이 되며, pull이기 때문에 consumer group마다 자기 offset·속도로 독립 읽기가 가능하다. 하나를 빼면 전체가 흔들린다 — 그래서 Kafka를 "빠른 큐"로만 보면 이 네 기둥의 시너지를 놓친다.

ZK는 사라졌다 — KRaft 시대

Kafka 4.0(2025-03)부터 ZooKeeper 모드가 완전히 제거되고 KRaft만 남았다. 메타데이터(어떤 topic, 어느 partition의 리더가 누구, ISR은 누구)를 더 이상 외부 코디네이터(ZK)에 맡기지 않고, broker들 사이에서 Raft 합의로 스스로 관리한다.

왜 ZK를 버렸나 — 메타데이터 병목

ZK 시절 Kafka는 두 시스템을 운영해야 했다: 메시지를 다루는 broker와 메타데이터를 다루는 ZK 앙상블. 이중 운영은 그 자체로 부담이었지만, 진짜 문제는 확장성이었다. partition 수가 늘어날수록 broker가 ZK에 갱신·구독해야 할 메타데이터가 선형으로 늘어났고, 수만 partition 규모에서 controller(ZK와 통신하는 특별 broker)가 병목이 됐다. controller 장애 시 메타데이터를 새 controller가 다시 로드하는 데 수분이 걸리는 일도 있었다.

KRaft는 이 메타데이터 자체를 Kafka의 로그 구조에 담아 Raft로 복제한다. 그래서 메타데이터 갱신이 단일 Raft 로그로 선형화(linearizable)되고, controller 장애 시에도 다른 controller가 즉시 이어받는다(수분이 아니라 수초). "Kafka로 Kafka의 메타데이터를 관리한다"는 자기참조적 설계다.

역할 분리: 각 서버는 process.roles로 broker, controller, 또는 broker,controller(combined) 중 하나. 단일 노드 학습은 combined.
controller quorum: controller들이 Raft로 활성 컨트롤러를 선출. 과반수(quorum)가 살아있으면 메타데이터 일관성 유지.
이득: 외부 의존성(ZK) 제거, 메타데이터 갱신 선형화, 대규모 클러스터(partition 수만 개)에서 확장 용이, controller 장애 복구 시간 단축.

단일 노드 vs 프로덕션 토폴로지

이 글(와 이 서브프로젝트 전체)의 실습은 combined 모드 단일 노드다 — 한 프로세스가 broker와 controller 역할을 모두 한다. 학습엔 충분하지만 내결함성은 없다(그 프로세스가 죽으면 클러스터 끝). 프로덕션 표준 토폴로지는:

broker replication.factor=3(장 06) — 1 broker 장애까지 데이터 손실 없이 감내.
controller 3개(quorum) — 1개 장애까지 감내(과반수 2 유지).
역할은 분리(controller-only 노드 + broker-only 노드)하거나 combined하거나, 규모에 따라 선택.

단일 노드 환경에선 복제·ISR·leader 선출이 의미 없다. 복제 실습은 최소 3 broker 환경이 필요하다(장 06·gotchas.md).

ZK 시절(3.x 이하)은 역사적 배경으로만. 4.x 자료가 아니면 --zookeeper·zookeeper.connect·config/kraft/ 같은 명령/설정이 등장하는데, 이것들은 4.x에서 동작하지 않는다. (장 12 운영·gotchas.md 참조)

core 위에 생태계가 올라간다 — 범위 정리

지금까지 본 broker·topic·partition·producer·consumer가 Apache Kafka core(ASF 산하)다. 이 로그 모델 위에 몇 가지가 더 올라간다:

Kafka Connect(ASF core): source/sink 커넥터로 DB·파일 ↔ Kafka 이동. 장 10.
Kafka Streams(ASF core): topic 간 스트림 처리 라이브러리(topology·state store). 장 11.
Schema Registry(Confluent 제공, ASF core 아님): Avro/JSON/Protobuf 스키마를 저장·호환성 검사. 장 09. core에 포함되지 않으므로 별도 설치·별도 문서.

이 서브프로젝트는 core를 중심으로 하되 생태계는 "어떤 문제를 푸는가·core와 어디서 만나는가"로 다룬다. core 사실과 Confluent 확장 사실을 섞지 않는 게 핵심 규칙이다.

Kafka 4.3 실습 — 직접 확인하기

사전: KRaft 단일 노드 기동(harness/commands.md 또는 kafka-verify 스킬). 단일 노드라 복제 동작은 일부만 관찰된다.

topic이 "삭제되지 않는 로그"임 확인

# Kafka 4.3, KRaft 단일 노드
bin/kafka-topics.sh --create --topic arch-demo --partitions 3 --replication-factor 1 --bootstrap-server localhost:9092
bin/kafka-console-producer.sh --topic arch-demo --bootstrap-server localhost:9092
# (콘솔에 메시지 몇 줄 입력 후 Ctrl-D)

확인할 것: producer가 종료돼도 메시지가 broker에 남아 있다(로그 모델).

bin/kafka-console-consumer.sh --topic arch-demo --from-beginning --bootstrap-server localhost:9092
# 같은 메시지를 처음부터 다시 읽을 수 있다(replay)

partition 분산과 offset 확인

bin/kafka-topics.sh --describe --topic arch-demo --bootstrap-server localhost:9092

확인할 것: Partition: 0/1/2, 각 partition의 Leader, Replicas, Isr.

Topic: arch-demo  PartitionCount: 3  ReplicationFactor: 1
  Topic: arch-demo  Partition: 0  Leader: 1  Replicas: 1  Isr: 1
  Topic: arch-demo  Partition: 1  Leader: 1  Replicas: 1  Isr: 1
  Topic: arch-demo  Partition: 2  Leader: 1  Replicas: 1  Isr: 1

key 없이 produce하면 sticky로 한 partition에 몰릴 수 있어 위 describe만으로는 분산이 안 보일 수 있다. key를 주고 produce하면 murmur2(key) % 3로 고정 partition이 결정되는지 교차 확인하라.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"Kafka는 큐라서 소비하면 사라진다"	로그다. 소비해도 retention이 지나기 전엔 남는다. 그래서 replay·여러 consumer 그룹 독립 읽기 가능
"Kafka는 전체 순서를 보장한다"	partition 내 순서만. 여러 partition 섞으면 순서 보장 없음. 전체 순서 필요하면 partition=1(병렬성 포기)
"Kafka는 실시간 push다"	pull 기반. consumer가 `poll()`로 당긴다. broker가 밀어넣지 않는다
"key만 주면 순서 보장 + 병렬 처리 둘 다"	같은 key는 같은 partition → 순서 보장. 하지만 key 종류가 적으면 partition이 쏠려 병렬성이 떨어짐(cardinality 트레이드오프)
"partition은 줄일 수 있다"	줄일 수 없다. 늘리기만 가능(02장)
"Kafka가 빠른 건 메모리 DB라서"	아니다. 디스크 기반 로그 + 순차 I/O + zero-copy + batch 덕분
"ZK 기반 자료 그대로 써도 된다"	4.x에선 `--zookeeper` 동작 안 함. 무조건 `--bootstrap-server`

요약 — 이 글의 결론

Kafka = 분산 커밋 로그. 소비해도 retention 전엔 남는다(재생산·다중 소비 가능). 이게 "큐가 아닌 로그"라는 한 문장이 모든 설계를 설명한다.
partition = append-only log + 순서 보장 단위 + 병렬 단위. 전체 순서 포기, partition 내 순서 보장. partition은 늘릴 수만 있고 줄일 수 없다.
record = key + value + timestamp + headers(0.11+). 같은 key → murmur2(key) % numPartitions(consistent hash 아님).
producer 쓰기: batch → leader append → ISR 복제 → ack(acks). 압축은 종단간.
consumer 읽기: pull(poll()) → offset 기반 → __consumer_offsets에 commit. replay 가능.
빠른 이유: 순차 I/O + batch 압축 + zero-copy(sendfile). 마법 아님 — 페이지 캐시를 읽기 캐시로 쓴다.
KRaft: ZK 제거(4.0), broker들이 Raft로 메타데이터 자체 관리. ZK 시절 명령/설정은 4.x에서 동작 안 함.
설계의 네 기둥: 로그(단순+순차) · partition(병렬, 순서 트레이드오프) · consumer group(한 partition=한 consumer) · pull(속도 제어+replay).

생각해 볼 문제

Kafka가 "큐가 아니라 로그"라는 말의 의미를, retention 관점에서 설명하라.
같은 key의 메시지가 어떻게 같은 partition에 도달하는지, 파티셔너 알고리즘(murmur2)을 포함해 설명하라.
consumer가 broker에 데이터를 "요청"한다는 것이 왜 설계상 유리한가(pull vs push)?
partition을 늘리면 얻는 것과 잃는 것을 각각 말하라. 왜 줄일 수 없는가?
Kafka가 디스크 기반인데 빠른 이유를 세 가지 설계 결정으로 설명하라.
zero-copy(sendfile)가 없었다면 consumer 읽기 경로에서 구체적으로 어떤 비용이 추가되는가?
KRaft가 ZooKeeper를 대체한 핵심 이유 하나를 말하라.

참고

Introduction — Main Concepts - 접근 2026-07-09
Design — Motivation & Persistence - 접근 2026-07-09 (순차 I/O, zero-copy, push vs pull, batch compression)
Record message format - 접근 2026-07-09
BuiltInPartitioner.java (murmur2) - 접근 2026-07-09
KRaft — operations/kraft.md - 접근 2026-07-09
KIP-833(KRaft production ready), KIP-853(동적 controller quorum), KIP-82(record headers)

Linux - 11. services

dongka — Thu, 9 Jul 2026 14:36:19 +0900

메일은 한 번에 가지 않는다 — 인터넷 서비스의 역할 분담

메일을 보냈다. 바로 도착할까? 아니다. 메일은 송신자 → 송신 서버(MTA) → 수신 서버(MTA) → 메일함(MDA) → 수신자(MUA) 의 다단계 흐름을 거친다. 어디쯤 걸려 지연되는지 알려면 이 흐름을 알아야 한다. 단일 "메일 서버"라는 말이 감추는 것이 바로 이 분업이다.

서버의 주된 용도가 바로 이 서비스들이다 — 웹, 이름 해석(DNS), 메일, 파일 공유, 데이터베이스. 각각 고유한 프로토콜·포트·패키지·설정 파일을 갖는다. 이 글은 그 매핑과, 서비스가 "설치했는데 외부 접속이 안 될 때"의 3단계 진단을 다룬다.

서비스는 역할별 부서다 — 포트가 내선 번호다

서버는 하나의 회사, 각 서비스는 부서이자 안내 데스크다. 각 부서에 고유 내선(포트)이 있다.

flowchart TB
    CLIENT[클라이언트] --> WEB[웹: 80/443<br/>httpd / nginx]
    CLIENT --> DNS[DNS: 53<br/>BIND named]
    CLIENT --> MAIL[메일: 25/465/993<br/>Postfix + Dovecot]
    CLIENT --> FILE[파일공유: 445/2049/21<br/>Samba / NFS / vsftpd]
    CLIENT --> DB[DB: 3306/5432<br/>MariaDB / PostgreSQL]

서비스	프로토콜	포트	Rocky 10 패키지
웹	HTTP/HTTPS	80 / 443	httpd, nginx 1.26
DNS	DNS(UDP/TCP)	53	bind(named)
메일 송신	SMTP	25, 465(SMTPS), 587	postfix(기본 MTA)
메일 수신	IMAP/POP3	143/993, 110/995	dovecot
파일(윈도 공유)	SMB/CIFS	445, 139	samba
파일(유닉스 공유)	NFS	2049	nfs-utils
파일(FTP)	FTP	21(제어), 20(데이터)	vsftpd
DB	MySQL 프로토콜	3306	MariaDB 10.11 / MySQL 8.4
DB	PostgreSQL	5432	PostgreSQL 16.8

부서 비유는 "역할별 부서 + 고유 내선(포트)"만 잡는다. 서비스는 동시 다수 연결을 처리하고(멀티스레드/이벤트), 메일은 여러 서버를 거친다는 점에서 비유를 넘어선다.

웹 서버 — httpd(Apache) / nginx

HTTP 요청을 받아 정적/동적 콘텐츠를 제공한다.

httpd(Apache): 전통 모듈 구조(prefork/worker/event MPM). .htaccess, 가상호스트.
nginx: 이벤트 기반, 고동시성에 강, 리버스 프록시/로드밸런서로도 사용.

sudo dnf install -y httpd       # 또는 nginx
sudo systemctl enable --now httpd
sudo firewall-cmd --permanent --add-service={http,https}
sudo firewall-cmd --reload

패키지	주 설정	가상호스트	문서루트
httpd	`/etc/httpd/conf/httpd.conf`, `/etc/httpd/conf.d/*.conf`	`/etc/httpd/conf.d/vhost.conf`	`/var/www/html`
nginx	`/etc/nginx/nginx.conf`, `/etc/nginx/conf.d/*.conf`	`/etc/nginx/conf.d/vhost.conf`	`/usr/share/nginx/html`

비표준 포트/디렉토리를 쓰면 SELinux가 차단한다 — semanage로 컨텍스트/포트 허용 추가(10장).

DNS — BIND(named)

도메인 이름 ↔ IP 변환. 영역(zone) 단위로 관리한다.

데몬: named. 포트 53(UDP/TCP).
마스터(Primary)/슬레이브(Secondary) 영역 복제.

DNS 레코드 종류:

레코드	의미
A	도메인 → IPv4
AAAA	도메인 → IPv6
MX	메일 교환 서버
CNAME	별칭(다른 이름으로 리디렉션)
NS	네임서버
TXT	임의 텍스트(SPF, DKIM 등)
SOA	영역 시작·관리 정보

sudo dnf install -y bind bind-utils
sudo systemctl enable --now named

/etc/named.conf — 주 설정(옵션, zone 선언, ACL).
/var/named/ — zone 파일(example.com.zone).

메일 — 왜 한 번에 안 가는가 (다단계 흐름)

도입부의 질문으로 돌아가자. 메일은 한 번에 가지 않는다.

flowchart LR
    S[송신자 MUA] -->|SMTP| MTA1[MTA - Postfix<br/>송신 서버]
    MTA1 -->|SMTP| MTA2[MTA - 수신 서버]
    MTA2 -->|LDA| MDA[MDA - Dovecot<br/>메일함 저장]
    R[수신자 MUA] -->|IMAP/POP3| MDA

MTA(Mail Transfer Agent): 서버 간 메일 송수신. SMTP. Rocky 10 기본 = postfix(sendmail은 사실상 사장).
MDA(Mail Delivery Agent): 메일함에 저장. Dovecot이 겸함.
MUA(Mail User Agent): 사용자 클라이언트(Thunderbird). IMAP/POP3로 Dovecot에 접속.

이 분업 덕에 송신 서버와 수신 서버가 다를 수 있고, 수신자는 나중에 메일함에서 읽을 수 있다. "메일이 지연된다"면 이 흐름의 어느 단계(MTA↔MTA 전송? MDA 저장? MUA 조회?)인지를 봐야 한다.

SMTP 포트의 분담도 이 분업을 반영한다: 25번은 서버 간(MTA↔MTA), 587/465는 사용자 제출(MUA→MTA, 인증). 25번을 사용자 송신용으로 쓰지 않는다.

sudo dnf install -y postfix dovecot
sudo systemctl enable --now postfix

/etc/postfix/main.cf — Postfix 주 설정(myhostname, mydomain, myorigin, inet_interfaces).
/etc/dovecot/dovecot.conf — Dovecot 주 설정.

파일 공유 — Samba / NFS / vsftpd

서비스	용도	클라이언트
Samba(SMB/CIFS)	윈도우와 공유	Windows 탐색기, smbclient
NFS	유닉스/리눅스 간 공유	`mount -t nfs`
vsftpd(FTP)	범용 파일 전송(레거시)	ftp 클라이언트

Samba: /etc/samba/smb.conf.
NFS: /etc/exports(내보낼 디렉토리). exportfs -rav로 적용.
vsftpd: /etc/vsftpd/vsftpd.conf.

NFSv3와 NFSv4는 다르다. NFSv4는 단일 포트(2049)로 방화벽이 쉽지만, v3는 동적 다수 포트를 쓴다. Rocky 10은 v4가 기본. FTP는 평문 비밀번호 문제로 레거시 — 신규는 SFTP/SCP를 권장한다.

NFS 마운트(클라이언트):

sudo mount -t nfs server:/shared /mnt

데이터베이스 — MariaDB / PostgreSQL

구조화 데이터 저장·질의. LAMP/LEMP 스택의 핵심이다.

MariaDB: MySQL 포크. Rocky 10 기본 DB(10.11). MySQL 8.4도 선택 가능.
PostgreSQL: 객체-관계형 DB. Rocky 10 = 16.8.

MariaDB에 mysql 명령으로 접속하는 건 이상해 보이지만 자연스럽다 — MariaDB가 MySQL의 포크라 클라이언트 호환성을 유지하기 때문. 명령은 mysql이지만 실제는 MariaDB다.

# MariaDB
sudo dnf install -y mariadb-server
sudo systemctl enable --now mariadb
sudo mysql_secure_installation      # 초기 보안 설정

# PostgreSQL
sudo dnf install -y postgresql-server
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장. 서비스 시작 전 항상 SELinux/firewalld를 고려하라.

# 패키지 버전 확인
dnf info nginx | grep Version          # 1.26.x
dnf info mariadb-server | grep Version # 10.11
dnf info postgresql-server | grep Version  # 16.8

# 서비스 운영 공통
sudo dnf install -y <pkg>
sudo systemctl enable --now <svc>   # 부팅 자동 + 즉시 시작
sudo systemctl status <svc>
sudo systemctl reload <svc>         # 끊김 없이 재적용(httpd/nginx/postfix)
sudo journalctl -u <svc> -f         # 실시간 로그

# 웹 서버 기동 확인
curl -I http://localhost            # HTTP/1.1 200
ss -tlnp | grep -E ':80|:443'       # 리스닝 확인

# 방화벽에 서비스 개방
sudo firewall-cmd --permanent --add-service={http,https,dns,smtp,imap}
sudo firewall-cmd --reload
firewall-cmd --list-services

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"MariaDB와 MySQL은 다른 DB"	MariaDB가 MySQL 포크. `mysql` 명령으로 접속하지만 실제는 MariaDB
"메일 25번이 사용자용"	25는 서버 간(MTA↔MTA). 587/465가 사용자 제출(MUA→MTA, 인증)
"FTP가 파일 공유 표준"	레거시. 평문 비번 문제. 신규는 SFTP/SCP 권장
"NFSv3와 NFSv4는 같다"	NFSv4는 단일 포트(2049)로 방화벽 쉬움. v3는 동적 다수 포트. Rocky 10은 v4 기본
"서비스 설정 파일 위치는 다 비슷"	아니다. 각기 다름(표 참조). 반드시 매핑 숙지
"서비스 안 되면 패키지만 재설치"	9할은 SELinux/firewalld. 설정 파일·포트·컨텍스트 확인 먼저
"포트만 열면 외부 접속된다"	서비스가 `0.0.0.0`에 바인딩돼야(`127.0.0.1`이면 로컬만)
"DB 데이터는 어디든 둬도 된다"	SELinux가 기본 경로(`/var/lib/mysql`, `/var/lib/pgsql`) 외엔 차단. `semanage fcontext`로 허용

더 깊이

가상화·컨테이너: KVM/libvirt(네이티브 하이퍼바이저, VM 실행), Podman 5(Docker 호환, daemonless/rootless, systemd quadlet 통합).
인증 서비스: LDAP(중앙 계정 디렉토리), Kerberos(티켓 기반 강력 인증), SSSD(로컬과 IdM/AD/LDAP 연결).
NTP/chrony: 시간 동기화. Rocky 10 기본 = chrony. 인증서(Kerberos), 로그 정렬, 분산 시스템에 필수. chronyc sources로 상태 확인.

요약 — 이 글의 결론

서비스별 포트: 80/443(웹), 53(DNS), 25/465/587(SMTP), 143/993(IMAP), 445(SMB), 2049(NFS), 21(FTP), 3306(MariaDB), 5432(PostgreSQL).
웹: httpd(/etc/httpd/), nginx(/etc/nginx/). Rocky 10 nginx 1.26.
DNS: bind(named), /etc/named.conf. 레코드: A/AAAA/MX/CNAME/NS/TXT/SOA.
메일: postfix(MTA) + dovecot(MDA/IMAP). /etc/postfix/main.cf. 한 번에 안 간다 — MUA→MTA→MTA→MDA→MUA 다단계. 25=서버 간, 587/465=사용자 제출.
파일: Samba(SMB/윈도), NFS(유닉스, v4 기본), vsftpd(FTP/레거시).
DB: MariaDB 10.11(Rocky 10 기본, MySQL 포크), PostgreSQL 16.8.
서비스 안 될 때 3단계: (1) 서비스 상태 (2) firewalld 포트 (3) SELinux 컨텍스트.

생각해 볼 문제

웹/DNS/메일(SMTP)/파일(SMB)/DB(PostgreSQL)의 기본 포트를 말하라.
httpd와 nginx의 핵심 설정 파일 경로와 기본 문서루트를 비교하라.
DNS 레코드 A, MX, CNAME, NS의 의미를 말하라.
MTA, MDA, MUA의 역할과 메일 흐름을 설명하라. 메일이 "한 번에 안 가는" 이유는?
SMTP 25와 587/465의 용도 차이는?
Samba와 NFS의 주요 차이. 각각 어떤 환경에 어울리는가?
MariaDB와 MySQL의 관계는? 왜 mysql 명령으로 접속하는가?
서비스가 설치됐는데 외부 접속이 안 될 때 확인 3단계는?

참고

Rocky Linux 10 Release Notes — Notable packages - 접근 2026-07-09 (nginx 1.26, MariaDB 10.11, PostgreSQL 16.8)
RHEL 10 문서 - 접근 2026-07-09
man page: man httpd, man nginx, man named, man postfix, man smb.conf, man exports(5), man mysqld

Linux - 10. security

dongka — Thu, 9 Jul 2026 14:35:38 +0900

설정은 다 맞는데 403이 난다 — 9할은 SELinux다

httpd 설정을 다 맞췄다. 파일도 /var/www/html에 넣었다. 그런데 브라우저에서 403 Forbidden. Apache 설정만 뒤지다 한참을 헤맨다 — 그런데 진짜 원인은 SELinux인 경우가 압도적으로 많다. 파일을 cp/mv로 옮기면 보안 레이블(컨텍스트)이 잘못되어 SELinux가 접근을 막는 것이다.

리눅스 보안은 다층 방어(defense in depth)다. 전통 권한(DAC) 위에 강제 접근 제어(SELinux), 네트워크 검문(firewalld), 인증(PAM)이 올려져 있고, 각 층이 독립적으로 통과돼야 접근이 허용된다. 이 장을 모르면 "설정 다 맞는데 왜 안 되지?"의 원인을 못 찾고, 방화벽·인증 정책도 못 짠다. 이 글은 그 다층 구조를 다룬다.

접근 제어의 두 층 — DAC와 MAC, 둘 다 통과해야 한다

보안 층	건물 비유	리눅스
DAC(권한 rwx)	출입증 소유자가 자기 사무실 출입 권한 부여	전통 UNIX 퍼미션(05장)
MAC(SELinux)	건물 보안 정책이 출입증과 무관하게 추가 검문	SELinux
firewalld	건물 정문 검문대(외부인 통제)	네트워크 패킷 필터
PAM	신분증 확인 절차(로그인·sudo)	인증 프레임워크

모델	설명	예
DAC(임의)	소유자가 권한 결정	전통 UNIX 퍼미션
MAC(강제)	정책이 접근 강제. 소유자 권한 무관	SELinux, AppArmor

핵심: DAC가 허용해도 MAC(SELinux)이 거부하면 접근 불가. 둘 다 통과해야 동작한다. 이것이 "서비스 안 될 때 SELinux를 의심해야 하는 이유"다. 권한(chmod)만 보고 "다 됐는데"라고 착각하기 쉽기 때문이다.

SELinux — 모든 것에 레이블을 붙인다

NSA가 기여한 MAC 구현이다. 모든 프로세스와 파일에 레이블(컨텍스트)을 붙이고, 정책이 허용한 관계만 접근을 허용한다. "웹 서버 프로세스가 웹 콘텐츠 디렉토리만 읽게" 같은 세밀한 통제가 가능하다.

모드	동작	용도
enforcing	정책 위반 차단 + 로그	운영 기본(Rocky 10 기본)
permissive	위반 허용 + 로그만(감사/디버그)	문제 원인 파악
disabled	완전 비활성	권장 안 함(재부팅 필요, 보안 약화)

정책은 RHEL 10에서 targeted(기본, 주요 서비스만 confinement)이 표준이다.

SELinux 컨텍스트(레이블)

user:role:type:mls
예: unconfined_u:object_r:httpd_sys_content_t:s0
     │           │        │                  │
     │           │        │                  └ MLS 레벨
     │           │        └ 타입(가장 중요, 정책 매칭 단위)
     │           └ 롤
     └ 사용자

type(_t 접미사)가 정책 적용의 핵심이다. httpd_t 프로세스는 httpd_sys_content_t 파일만 읽도록 허용된다. 파일을 cp/mv로 /var/www/html에 넣으면 이 type 레이블이 잘못되고, SELinux가 차단한다 — 도입부의 403 사태.

firewalld — 네트워크 검문대

동적 방화벽 관리 데몬. RHEL 10 백엔드는 nftables(iptables는 unmaintained, 단계적 제거).

flowchart LR
    NIC[네트워크 인터페이스] --> ZONE[Zone<br/>trusted/public/dmz...]
    ZONE --> RULE[규칙: 서비스/포트/소스]
    RULE --> BACKEND[nftables 백엔드]
    BACKEND --> KERNEL[커널 패킷 필터]

Zone: 신뢰 수준별 규칙 묶음. 인터페이스를 zone에 할당. public(기본), trusted(모두 허용), block, dmz, home, work.
Service: 미리 정의된 포트/프로토콜 묶음(http, ssh, dns).
Runtime vs Permanent: 기본은 임시(재시작 시 사라짐). --permanent로 영구화한 뒤 --reload.

PAM과 sudo — 인증과 권한 위임

PAM(Pluggable Authentication Modules)

인증을 모듈화한 프레임워크. 로그인·sudo·ssh 등이 PAM을 통해 인증한다.

flowchart LR
    APP[응용: login, sshd, sudo] --> PAM[PAM 라이브러리]
    PAM --> CONF[/etc/pam.d/<service>/]
    CONF --> MOD[모듈: pam_unix, pam_sss, ...]
    MOD --> BACKEND[로컬/LDAP/Kerberos/IdM]

설정: /etc/pam.d/<서비스>.
관리 도구: authselect(RHEL 10). PAM/NSS 설정을 프로필 단위로 관리. 직접 /etc/pam.d 편집 금지(authselect가 덮어씀).
백엔드 통합: SSSD → IdM/AD/LDAP.

sudo — 권한 위임

일반 사용자가 root 권한 명령을 제한적으로 실행한다.

설정: /etc/sudoers와 /etc/sudoers.d/*. 반드시 visudo로 편집(문법 검증).
일반 사용자를 wheel 그룹에 넣으면 sudo 사용 가능(RHEL 기본).

/etc/sudoers를 일반 에디터로 고치다 문법을 틀리면 모든 sudo가 막힌다 — root조차 못 된다. 그래서 visudo가 저장 시 문법을 검증한다.

시스템 전체 암호화 정책(Crypto Policies)

RHEL은 TLS/SSH/IPsec/DNSSEC/Kerberos 허용 알고리즘을 전역 정책으로 통일 관리한다: DEFAULT(운영 기본, 현대 알고리즘), LEGACY(구형 호환), FUTURE(더 강력), FIPS(FIPS 140 준수).

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

# SELinux — 서비스 안 될 때 가장 먼저
getenforce                       # 현재 모드
sestatus                         # 상세(모드, 정책)
sudo setenforce 0                # Permissive(임시)
sudo setenforce 1                # Enforcing

ls -Z /var/www/html/index.html   # 파일 컨텍스트
ps -eZ | grep httpd              # 프로세스 컨텍스트

# AVC 거부 로그(서비스 안 될 때)
sudo ausearch -m AVC -ts recent
sudo journalctl -t setroubleshoot

unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

SELinux 문제 해결 흐름:

sudo ausearch -m AVC -ts recent | tail          # 1. 거부 로그에서 AVC 확인
sudo restorecon -Rv /var/www/html               # 2. 컨텍스트 복구(잘못된 레이블 교정)
# 비표준 경로/포트는 semanage로 레이블 추가
sudo semanage fcontext -a -t httpd_sys_content_t "/custom/web(/.*)?"
sudo restorecon -Rv /custom/web
# 반복 거부는 정책 모듈 자동 생성
sudo grep "...denied" /var/log/audit/audit.log | audit2allow -M mypol
sudo semodule -i mypol.pp

# firewalld
sudo systemctl status firewalld
firewall-cmd --get-default-zone
firewall-cmd --list-all                 # 현재 zone 전체

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload              # 영구 → 런타임 반영

sudo firewall-cmd --permanent --change-interface=enp0s3 --zone=public

public (active)
  services: cockpit dhcpv6-client ssh
  ports: 8080/tcp

# PAM / authselect
authselect current                    # 현재 프로필
cat /etc/pam.d/system-auth            # authselect 관리(직접 편집 금지)
sudo authselect select sssd --update  # 프로필 변경

# sudo
sudo -l                               # 내가 실행 가능한 명령
sudo visudo                           # 설정 편집(반드시 visudo)
echo "alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx" | sudo tee /etc/sudoers.d/alice

# 암호화 정책
update-crypto-policies --show         # DEFAULT
sudo update-crypto-policies --set FUTURE

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"설정 맞는데 안 되면 Apache 설정을 뒤진다"	9할 SELinux. permissive로 전환 후 AVC 로그 먼저
"SELinux 귀찮으니 disabled로"	금지. 보안 무력화 + 재부팅 시 레이블 재작성(매우 느림). 차라리 permissive
"`firewall-cmd --add-service=http` 영구다"	아니다. `--permanent` 없으면 재시작 시 사라짐
"`/etc/pam.d/system-auth` 직접 고친다"	authselect가 다음 업데이트에 덮어씀. authselect로
"`/etc/sudoers`를 에디터로 고친다"	문법 틀리면 모든 sudo 막힘(root 못 됨). 반드시 `visudo`
"SELinux는 무작위로 차단"	아니다. 컨텍스트 매칭 안 되면. `restorecon`으로 교정
"firewalld 임시 규칙도 부팅 후 유지"	사라짐. 운영은 `--permanent` + `--reload`
"포트 열면 서비스 접속된다"	SELinux가 비표준 포트 차단 가능. `semanage port`로 허용 추가 필요

더 깊이

SELinux boolean: 세밀한 토글 스위치. setsebool -P httpd_can_network_connect on(웹 서버가 네트워크 연결 허용). getsebool -a로 전체 확인.
auditd와 침입 탐지: auditd는 시스템 호출·파일 접근을 상세 로깅한다(/var/log/audit/audit.log). ausearch/aureport로 분석. 침해 사후 조사의 핵심.
IdM(Identity Management): RHEL의 중앙 인증(LDAP+Kerberos+DNS+CA 통합). Active Directory와 신뢰 관계 구성 가능.

요약 — 이 글의 결론

DAC(소유자 결정) + MAC(정책 강제, SELinux). 둘 다 통과해야 접근 — 이게 "권한 줬는데 왜 안 되지?"의 답.
SELinux: 레이블(컨텍스트 user:role:type:mls) 기반. type(_t)이 핵심. 모드는 enforcing(기본)/permissive/disabled(금지). "설정 맞는데 403"은 9할 컨텍스트 문제 → restorecon.
firewalld: zone(public/trusted/dmz) + service. 백엔드 nftables(Rocky 10). --permanent + --reload로 영구화.
PAM: /etc/pam.d/. authselect로 관리(직접 편집 금지).
sudo: visudo만. wheel 그룹이 기본 sudo 권한. 에디터로 고치면 문법 틀렸을 때 전체 마비.
Crypto policies: DEFAULT/LEGACY/FUTURE/FIPS.
서비스 안 될 때 3단계: (1) 서비스 상태 (2) firewalld 포트 (3) SELinux 컨텍스트.

생각해 볼 문제

DAC와 MAC의 차이. 둘 다 통과해야 하는 이유는?
SELinux의 enforcing/permissive/disabled 차이. 왜 disabled를 피하는가?
SELinux 컨텍스트에서 가장 중요한 필드는? 왜?
"httpd 설정 다 맞는데 403"일 때 가장 먼저 확인할 것은?
firewalld의 runtime과 permanent 차이. 운영에선 어떻게?
/etc/pam.d/system-auth를 직접 고치면 안 되는 이유는?
/etc/sudoers를 일반 에디터로 고치면 위험한 이유는? 안전한 도구는?
Rocky 10의 firewalld 백엔드는?

참고

Using SELinux — RHEL 10 - 접근 2026-07-09
Configuring firewalls — RHEL 10 - 접근 2026-07-09
Configuring authentication — RHEL 10 - 접근 2026-07-09
man page: man selinux(8), man sestatus, man firewall-cmd, man authselect, man sudoers, man pam(8)

Linux - 09. network

dongka — Thu, 9 Jul 2026 14:33:59 +0900

DNS를 바꾸려고 resolv.conf를 고쳤다가 사라졌다 — 네트워크 관리

DNS 서버를 바꾸려고 /etc/resolv.conf를 직접 편집했다. 잘 되는 듯했는데 재부팅하니 원래대로 돌아갔다. 왜? Rocky 10에선 NetworkManager가 /etc/resolv.conf를 자동 관리한다. 직접 편집하면 덮어쓴다. DNS 변경은 nmcli로 해야 한다.

이런 함정이 네트워크 관리엔 많다. 서버의 대부분은 네트워크로 통신하고, IP 설정·포트 점검·DNS 오류·라우팅 문제는 운영 일상이다. 이 글은 컴퓨터가 서로 통신하는 세 가지 기반 — 서로를 식별할 주소(IP), 데이터를 전달할 경로(라우팅), 이름을 주소로 바꿀 DNS — 과, Rocky 10이 이걸 NetworkManager로 관리하는 방식을 다룬다.

우편 시스템으로 보는 네트워크 — 주소·포트·이름

네트워크 통신은 우편 시스템과 정확히 대응된다(오래된 표준 비유):

	네트워크	우편
호스트 식별	IP 주소	우편번호 + 집 주소
서비스 구분	포트 번호	건물 내 호수(한 건물에 여러 수신자)
패킷 전달	라우팅	우체부 경로(목적지까지 거쳐가는 우체국들)
이름→주소	DNS	전화번호부
우체부 규칙	TCP/UDP	등기(TCP, 확실) / 엽서(UDP, 빠름)

우편 비유는 "주소-경로-이름해석" 구조만 잡는다. 패킷은 여러 홉을 거치며 분할/재조립되고, 포트는 동시 다수 연결이 가능하다는 점에서 비유를 넘어선다.

IP 주소와 CIDR

IPv4: 32비트, 4옥텟(192.168.1.10). 약 43억 개.
CIDR 표기: 192.168.1.10/24 = 앞 24비트가 네트워크(255.255.255.0).
- /24 → 호스트 254개(네트워크·브로드캐스트 주소 제외, 256이 아님). /30 → 2개(링크용). /16 → 65,534개.

대역	용도
`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`	사설(인터넷 직접 불가, NAT 필요)
`127.0.0.0/8`	루프백(loopback, `localhost`)
`169.254.0.0/16`	링크 로컬(DHCP 실패 시 자동)

TCP vs UDP

항목	TCP	UDP
연결	연결 지향(3-way handshake)	비연결
신뢰성	보장(재전송, 순서)	보장 없음
속도	느림	빠름
용도	웹(HTTP), 메일(SMTP), SSH	DNS, DHCP, 스트리밍, VoIP

포트는 16비트(0~65535). 잘 알려진 포트(<1024)는 root 권한이 필요하다. 22(SSH), 25(SMTP), 53(DNS), 80, 443(HTTPS).

TCP/IP 계층 — 4개로 압축

flowchart TB
    L4[4. 응용 Application<br/>HTTP, SSH, DNS, SMTP] --> L3[3. 전송 Transport<br/>TCP, UDP]
    L3 --> L2[2. 인터넷 Internet<br/>IP, ICMP]
    L2 --> L1[1. 링크 Link<br/>이더넷, Wi-Fi]

OSI 7계층을 실용적으로 4개로 압축. 각 계층은 하위 계층을 이용한다.

라우팅과 DNS — 경로와 이름 해석

라우팅

패킷이 목적지까지 가는 경로 결정. 커널은 라우팅 테이블에서 가장 길게 매칭되는(longest prefix match) 엔트리를 선택한다.

게이트웨이(next hop): 다음 라우터.
기본 라우트(default, 0.0.0.0/0): 매칭 엔트리가 없을 때 쓰는 탈출구.

DNS와 이름 해석

호스트 이름 → IP 변환. 해석 순서는 /etc/nsswitch.conf의 hosts: 줄이 결정한다(보통 files dns).

/etc/hosts: 정적 로컬 매핑(가장 먼저).
/etc/resolv.conf: DNS 서버 목록 — 그런데 Rocky 10에선 NetworkManager가 자동 관리.

핑은 되는데 DNS가 안 된다면? 핑은 IP 연결만 확인한다. DNS는 53번 포트로 따로 동작하니 dig로 확인해야 한다.

NetworkManager — Rocky 10의 네트워크 데몬

단일 데몬이 유선/무선/VPN/브리지/본딩을 통합 관리한다. 설정은 연결 프로필(key file) 단위.

flowchart LR
    NM[NetworkManager 데몬] --> CLI[nmcli / nmtui]
    NM --> PROF[연결 프로필<br/>/etc/NetworkManager/system-connections/]
    NM --> KERNEL[커널 네트워크 스택<br/>ip 명령으로 확인]

설정 파일: /etc/NetworkManager/system-connections/<name>.nmconnection(key-file).
구 /etc/sysconfig/network-scripts/ifcfg-*는 더 이상 권장 아니다(RHEL 9부터 단계적 제거).
인터페이스 명명: eth0 구식 → enp0s3(버스 기반 예측 가능 이름)이 현대 기본. en=이더넷, p0s3=버스 위치.

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

# 인터페이스·주소 (ip - 저수준)
ip addr show              # 모든 인터페이스 + 주소 (ip a)
ip -4 addr show           # IPv4만
ip link show              # 링크 상태(up/down)
ip route show             # 라우팅 테이블 (ip r)
ip route show default     # 기본 게이트웨이
ip neigh show             # ARP/이웃 테이블

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.50/24 brd 192.168.1.255 scope global enp0s3

default via 192.168.1.1 dev enp0s3 proto static metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.50

# NetworkManager (nmcli) — 권장 설정
nmcli general status               # NM 상태
nmcli device status                # 장치 목록
nmcli connection show              # 모든 연결 프로필

# 정적 IP 설정
sudo nmcli connection modify "enp0s3" \
    ipv4.method manual \
    ipv4.addresses 192.168.1.50/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns "8.8.8.8 1.1.1.1"
sudo nmcli connection up "enp0s3"  # 활성화

# DHCP 복귀
sudo nmcli connection modify "enp0s3" ipv4.method auto

# 소켓/포트 (ss - netstat 대체)
ss -tlnp                # TCP 리스닝 + 프로세스
ss -ulnp                # UDP 리스닝
ss -tunap               # TCP+UDP 모든 소켓 + 프로세스
ss -t state established # established만
ss -s                   # 요약

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

netstat는 deprecated. ss를 써라.

# 진단 도구
ping -c 4 8.8.8.8                   # 연결성/지연
ping -c 4 example.com               # DNS+연결 동시 확인
tracepath example.com               # 경로 추적(traceroute 대체)
dig example.com                     # DNS 상세
dig +short example.com              # IP만
dig @8.8.8.8 example.com            # 특정 DNS 서버
getent hosts example.com            # nsswitch 전체 조회
curl -I https://example.com         # HTTP 헤더만
curl -v https://example.com         # 상세

# 로컬 이름 해석
cat /etc/hosts                      # 정적 매핑
cat /etc/nsswitch.conf | grep hosts # 해석 순서
cat /etc/resolv.conf                # DNS 서버(NM 관리, 직접 편집 금지)

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"`/etc/resolv.conf` 직접 고치면 된다"	Rocky 10에선 NM이 덮어씀. nmcli로
"`netstat`를 쓴다"	deprecated. `ss` 사용
"인터페이스는 `eth0`"	현대는 `enp0s3`, `ens33`(예측 가능 이름). e=이더넷, w=무선
"서비스가 `127.0.0.1`에만 묶어도 외부 접속된다"	아니다. `0.0.0.0`(모든 IF)이나 특정 IP로 바인딩해야
"`/24`면 호스트 256개"	254개(네트워크·브로드캐스트 주소 제외)
"핑 되면 DNS도 된다"	핑은 IP 연결만. DNS는 53번 따로. `dig`로 확인
"DNS는 캐시된다"	리눅스는 보통 시스템 DNS 캐시가 없음(nscd/systemd-resolved 안 쓰면). 매번 쿼리
"CIDR `/30`은 쓸모 없다"	링크용 2개 호스트(라우터 간). 실제로 자주 씀

더 깊이

IPv6: IPv4 고갈 대안. 128비트(2001:db8::1). /64가 표준 서브넷. SLAAC(자동 설정) 또는 DHCPv6. Rocky 10은 기본 듀얼스택(IPv4+IPv6).
본딩·브리지: 본딩은 여러 NIC를 하나의 논리 인터페이스로(이중화/대역폭, mode 1 active-backup·mode 4 LACP). 브리지는 L2 스위치 역할(가상화/컨테이너가 호스트 LAN에 직접 참여).
방화벽과 nftables: Rocky 10의 firewalld 백엔드는 nftables. 패킷 필터링 규칙은 nmcli가 아니라 firewall-cmd로(10장 참조).

요약 — 이 글의 결론

IP/CIDR: /24 = 255.255.255.0 = 호스트 254개(256 아님). 사설대역(10/172.16/192.168)은 NAT 없이 인터넷 불가.
TCP(신뢰, 연결, 3-way handshake) vs UDP(빠름, 비연결).
포트: 잘 알려진 <1024(root 필요). 22/25/53/80/443.
라우팅: longest prefix match. 기본 라우트(0.0.0.0/0)가 탈출구.
DNS 해석 순서: /etc/hosts → DNS(/etc/nsswitch.conf hosts: 줄).
NetworkManager(nmcli): Rocky 10 중심. /etc/resolv.conf를 자동 관리하니 직접 편집 금지. 인터페이스 이름은 enp0s3(예측 가능), 구 eth0 아님.
ss > netstat(deprecated). 바인딩: 127.0.0.1(로컬만) vs 0.0.0.0(모든 IF, 외부 접속 가능).

생각해 볼 문제

IP 주소·포트·라우팅·DNS를 우편 시스템에 비유해 설명하라.
TCP와 UDP의 차이. 어떤 서비스가 각각 어울리는가?
/24 서브넷에서 사용 가능한 호스트 수는? 왜 256이 아닌가?
사설 IP 대역 3가지를 말하고, 왜 인터넷에 직접 못 나가는가?
Rocky 10에서 DNS 서버를 바꾸려면 어떻게 하는가? 왜 /etc/resolv.conf 직접 편집이 위험한가?
ss -tlnp 출력에서 127.0.0.1:80과 0.0.0.0:80의 차이는?
핑은 되는데 DNS가 안 될 때 의심할 곳은?
enp0s3라는 인터페이스 이름의 의미는?

참고

Configuring an Ethernet connection — RHEL 10 - 접근 2026-07-09
NetworkManager — Rocky Linux 10 - 접근 2026-07-09
man page: man nmcli, man ip(8), man ss(8), man dig, man resolv.conf(5), man nsswitch.conf(5)

Linux - 08. package

dongka — Thu, 9 Jul 2026 14:30:34 +0900

`rpm -i`로 설치하면 왜 의존성 에러가 나는가 — RPM과 dnf의 역할 분담

nginx를 설치하려고 rpm -i nginx.rpm을 쳤더니 의존성 에러로 실패한다. 왜? RPM은 의존성을 풀어주지 않는다. 단순 설치만 한다. 의존성 해결은 dnf의 일이다. 그래서 로컬 .rpm 파일도 dnf install ./pkg.rpm으로 설치해야 dnf가 의존성까지 처리한다.

이 글은 Rocky 10이 패키지를 어떻게 관리하는지 다룬다 — RPM(포장 형식 + 저수준 도구)과 dnf(앱스토어 관리자)의 역할 분담, 그리고 Rocky 10의 두 가지 큰 변화: dnf5 전환과 modularity 폐지. 이 변화를 모르면 구형 자료의 명령이 Rocky 10에서 동작하지 않는다.

RPM과 dnf는 역할이 다르다

	역할	비유
RPM	단일 `.rpm` 패키지 파일 + 저수준 설치 도구	포장된 상자(내용물 + 설명서 + 조립법)
dnf5	저장소 관리 + 의존성 자동 해결 + 설치/업데이트	앱스토어 관리자(검색·배달·세트물 해결)

RPM은 패키지 형식(.rpm)이자 저수준 도구다. dnf는 그 위에서 저장소 관리와 의존성 자동 해결을 한다. 의존성 지옥(openssl, pcre... 각각 컴파일하던 시절)에서 벗어나게 한 것이 dnf의 핵심 가치다.

NEVRA — 패키지 식별자

nginx-1.26.3-1.el10.x86_64.rpm
  │     │     │  │     │
  │     │     │  │     └ 아키텍처(x86_64, aarch64, noarch)
  │     │     │  └ 배포 태그(el10 = Enterprise Linux 10)
  │     │     └ 릴리스(같은 버전의 빌드 회차)
  │     └ 버전(업스트림)
  └ 이름

noarch는 아키텍처 무관(스크립트/문서). RPM 파일 내부는 헤더(메타데이터) + 페이로드(cpio 압축) + 서명(GPG)으로 이루어진다.

트랜잭션 스크립트

패키지는 설치/제거 시점에 스크립트를 실행한다:
| 스크립트 | 실행 시점 |
|----------|-----------|
| %pre / %post | 설치 전 / 후 |
| %preun / %postun | 제거 전 / 후 |

Rocky 10의 큰 변화 — dnf5와 modularity 폐지

Rocky 10은 dnf4(구)에서 dnf5로 전환했다.

flowchart LR
    D[dnf5 명령] --> LIB[libdnf5<br/>C++ 라이브러리]
    LIB --> REPO[저장소 메타데이터]
    LIB --> RPM[RPM DB<br/>/var/lib/rpm]

항목	dnf4(구)	dnf5(Rocky 10)
구현	Python + libdnf(C++)	libdnf5(전체 C++ 재작성)
Python 의존	필수	제거(컨테이너에 유리)
속도	보통	더 빠름
modularity(`dnf module`)	지원	폐지
filelists metadata	기본 다운로드	기본 생략(필요 시 자동/수동)
사용자 캐시	`~/.cache/dnf`	`~/.cache/libdnf5`

modularity 폐지 — 구형 자료가 동작하지 않는 이유

Rocky 8/9에선 특정 버전을 설치하려고 dnf module enable nginx:1.14 && dnf module install nginx:1.14를 썼다. Rocky 10에선 이 명령이 안 통한다. modularity가 폐지됐기 때문이다. 대신 버전을 직접 지정한다.

작업	구 방식(Rocky 8/9)	새 방식(Rocky 10)
특정 버전 설치	`dnf module enable nginx:1.14 && dnf module install nginx:1.14`	`dnf install nginx-1.26.3`
버전 목록	`dnf module list nginx`	`dnf repoquery nginx`

구버전(Rocky 8/9)에서는 구 방식이 정상 동작한다. 버전에 따라 명령이 다르니, 자료의 Rocky 버전을 반드시 확인하라. nginx-1.26.3(하이픈)과 nginx:1.26(콜론, module 방식)은 다르다 — Rocky 10은 하이픈 방식만 된다.

dnf4와 dnf5는 같은 RPM DB(/var/lib/rpm)를 공유하지만, 트랜잭션 히스토리 DB는 다르다. dnf5로 깐 패키지를 dnf4로 보면 "user installed"로 보이고 그 반대도 마찬가지. Rocky 10은 dnf5가 기본이라 혼용할 일은 거의 없다.

저장소와 GPG 검증 — 변조를 막는다

패키지와 메타데이터를 제공하는 원격/로컬 소스가 저장소(repository)다.

설정: /etc/yum.repos.d/*.repo.
기본 저장소(Rocky 10): BaseOS, AppStream, Extras.
메타데이터: repodata/(primary, filelists, updateinfo).

.repo 파일 예시:

[example-base]
name=Example Base
baseurl=https://example.com/linux/10/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-example

저장소/패키지의 GPG 서명으로 변조 여부를 확인한다. gpgcheck=1이면 서명 안 된 패키지 설치를 거부한다. 저장소 추가 시 공개 키를 먼저 등록: rpm --import <keyfile>. gpgcheck를 끄면 편하지만 위험하다 — 변조된 패키지가 설치될 수 있다.

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

dnf --version    # dnf5 버전 출력

# 패키지 조회
dnf list installed              # 설치된 패키지
dnf info nginx                  # 패키지 상세
dnf search "web server"         # 이름/요약 검색
dnf provides /usr/bin/curl      # 파일이 어느 패키지인지
dnf repoquery nginx             # 저장소의 모든 버전(modularity 대체)

sudo dnf install -y nginx             # -y 자동 yes
sudo dnf install -y nginx-1.26.3      # 특정 버전(새 방식)
sudo dnf remove nginx
sudo dnf update                       # 전체 업데이트(= upgrade)
sudo dnf check-update                 # 업데이트 가능 목록만
sudo dnf downgrade nginx

# 저장소 관리
dnf repolist                         # 활성 저장소
dnf repolist all                     # 전체
sudo dnf config-manager --add-repo https://example.com/repo.repo
sudo dnf config-manager --disable example-base
sudo dnf clean all                   # 캐시 삭제

# 히스토리 — 롤백
dnf history list                     # 트랜잭션 목록
dnf history info 5                   # 5번 상세
sudo dnf history undo 5              # 5번 취소(롤백)
sudo dnf history rollback 3          # 3번 이후 모두 취소

dnf5는 서브명령이 필수: dnf history만 치면 안 되고 dnf history list.

# 저수준 rpm (dnf로 안 될 때)
rpm -qa | grep nginx                 # 설치된 패키지 검색
rpm -qi nginx                        # 패키지 정보
rpm -ql nginx                        # 설치한 파일 목록
rpm -qf /usr/bin/curl                # 파일 소속 패키지
rpm -Va nginx                        # 검증(변조/무결성)
sudo rpm -ivh pkg.rpm                # 설치(로컬, 의존성 안 풀림)

dnf group list
sudo dnf group install "Server with GUI"

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"`rpm -i`로 설치하면 된다"	의존성 안 풀림. `dnf install ./pkg.rpm` 사용
"Rocky 10에선 `dnf module`이 된다"	안 됨(폐지). `dnf install pkg-ver`로
"filelists는 항상 받아진다"	Rocky 10은 기본 생략. 필요 시 자동/`optional_metadata_types=filelists`
"`dnf update`와 `dnf upgrade`는 다르다"	현대 dnf에선 동일(upgrade가 alias)
"`-y`는 항상 좋다"	운영에선 의존성 변경 먼저 확인 권장. 자동 스크립트만 `-y`
"EPEL은 기본 저장소다"	아니다. 서드파티. 필요 시 별도 설치(`dnf install epel-release`)
"gpgcheck 끄면 편하다"	위험. 변조 패키지 설치 가능. 공식 외엔 더 엄격히
"dnf5 히스토리에 과거가 다 보인다"	dnf4→5 전환 시 과거 히스토리 마이그레이션 안 됨

더 깊이

EPEL(Extra Packages for Enterprise Linux): Fedora 커뮤니티가 RHEL/Rocky용으로 제공하는 추가 패키지 저장소. RHEL 기본에 없는 도구(htop, nginx 최신 등) 설치에 유용. dnf install epel-release로 활성화. 단, 공식 지원 아님(운영 환경 주의).
dnf5 명령 변경: dnf shell → dnf5 do, dnf updateinfo → dnf5 advisory summary, dnf mark install → dnf5 mark user 등 서브명령이 바뀌었다. 자동화 스크립트 작성 시 dnf5 문서 확인.
RPM 직접 빌드: rpmbuild + .spec 파일로 커스텀 패키지를 생성. 소스 + 패치 + 설치 스크립트 + 메타데이터를 묶어 배포. 고급 주제.

요약 — 이 글의 결론

RPM = 패키지 형식(.rpm) + 저수준 도구. 의존성을 안 푼다 — 그래서 rpm -i는 실패하고 dnf install ./pkg.rpm을 써야 한다.
dnf5(Rocky 10) = libdnf5(C++ 재작성), Python 의존 제거, 더 빠름.
NEVRA: Name-Version-Release.Architecture.
modularity 폐지: dnf module이 안 통한다. dnf install pkg-ver로 버전 지정(하이픈). 구버전(8/9)은 콜론 module 방식.
filelists 기본 생략(필요 시 자동/optional_metadata_types=filelists).
저장소: /etc/yum.repos.d/*.repo. GPG 서명(gpgcheck=1)으로 변조 방지 — 끄면 위험.
rollback: dnf history undo N / dnf history rollback N.
dnf update = upgrade(동일).

생각해 볼 문제

RPM과 dnf의 역할 분담을 설명하라. 왜 rpm -i로 설치하면 안 되는가?
NEVRA의 각 자리가 의미하는 바를 풀어 설명하라.
dnf5가 dnf4보다 나은 점 3가지는?
Rocky 10에서 특정 버전 패키지를 설치하는 명령은? 구버전(8/9) 방식과 비교하라.
filelists metadata가 기본 생략된 이유와, 필요할 때 어떻게 하는가?
/usr/bin/curl이 어느 패키지 소속인지 확인하는 두 명령은?
설치를 롤백하려면 어떤 명령을 쓰는가? gpgcheck를 끄면 왜 위험한가?

참고

Rocky Linux 10 Release Notes — DNF/Modularity - 접근 2026-07-09
RHEL 10 Considerations — Software management - 접근 2026-07-09
Changes between DNF and DNF5 - 접근 2026-07-09
Migrating from DNF to DNF5 - 접근 2026-07-09
man page: man dnf5, man rpm, man dnf5.conf

Linux - 07. shell script

dongka — Thu, 9 Jul 2026 14:29:50 +0900

`ls *.txt`에서 별을 처리하는 건 ls가 아니다 — 셸과 확장

ls *.txt를 친다. ls가 *.txt를 처리할까? 아니다. 셸이 먼저 *.txt를 a.txt b.txt c.txt로 펼쳐서(확장) ls에 넘긴다. ls는 이미 펼쳐진 파일 이름만 받는다. 이 사실을 모르면 셸 스크립트의 이상한 동작 원인을 평생 못 찾는다.

셸은 단순한 명령 실행기가 아니다. 명령을 해석하고, 변수·glob·산술을 치환(확장)하며, 파이프·리다이렉션·제어문까지 처리하는 인터프리터다. cron, systemd unit, 배포 스크립트, 설정 자동화 — 리눅스 관리의 상당수가 셸 기반이다. 이 글은 셸이 명령을 어떻게 해석하는지, 그리고 그 해석을 스크립트로 어떻게 묶는지를 다룬다.

셸은 명령 번역사다

flowchart LR
    U[사용자/스크립트] --> SH[셸 - bash]
    SH --> K[커널 시스템 콜]
    K --> HW[하드웨어]

사용자(또는 스크립트)가 명령을 치면 → 셸이 해석 → 커널 시스템 콜 → 실행.

bash(Bourne Again Shell): GNU 프로젝트, 대부분 리눅스의 기본 로그인 셸. Bourne shell(sh) 호환 + 확장.
Rocky 10의 /bin/sh는 bash를 가리킨다(RHEL 전통). 단, sh로 호출하면 POSIX 제한 모드로 동작한다.

셸이 명령을 실행하기 전 거치는 확장 — 따옴표가 핵심

셸은 명령을 실행하기 전 여러 확장(expansion)을 거친다. 이 순서를 모르면 이상한 동작의 원인을 못 찾는다:

브레이스 확장: a{b,c} → ab ac
틸드 확장: ~ → 홈 디렉토리
변수/명령/산술 확장: $VAR, $(cmd), $((1+2))
워드 분리(IFS 기준)
경로명 확장(glob): *, ?, [abc]
리다이렉션/파이프 적용
최종 명령 실행

파일 이름에 공백이 있을 때 재앙이 일어나는 이유

초보자가 자주 겪는 재앙: rm $file을 쳤는데 파일 이름에 공백이 있었다. 셸이 워드 분리를 해버려 my file.txt가 my와 file.txt 두 인자로 쪼개지고, 각각을 지우려다 사고가 난다. 항상 "$file"(큰따옴표)로 감싸야 한다.

" "(큰따옴표): 변수 확장 O, glob X.
' '(작은따옴표): 모든 확장 X(문자 그대로).
따옴표 없음: glob·워드 분리 다 됨(위험).

변수 — 환경변수만 자식에게 간다

종류	범위	선언	예
셸 변수	현재 셸만	`VAR=value`	`NAME=rocky`
환경변수	자식 프로세스에 상속	`export VAR=value`	`export PATH=...`

자식 프로세스는 환경변수만 물려받는다. 스크립트 안에서 설정한 셸 변수는 호출한 셸에 영향을 주지 않는다. 부모 셸에 적용하려면 source로 실행해야 한다.

주요 환경변수:

변수	의미
`PATH`	명령 검색 디렉토리 목록(`:` 구분)
`HOME`	현재 사용자 홈
`USER` / `LOGNAME`	사용자명
`SHELL`	로그인 셸 경로
`PWD`	현재 작업 디렉토리
`LANG` / `LC_*`	로케일

PATH와 명령 검색

명령을 치면 셸은 PATH의 각 디렉토리를 순서대로 찾는다. 없으면 "command not found". 현재 디렉토리(.)는 보통 PATH에 없다(보안상 — 공격자가 현재 디렉토리에 가짜 ls를 두면 실행될 수 있으므로). 그래서 ./script.sh로 명시한다. 명령 위치는 which cmd나 type cmd로 확인. 한 번 찾은 경로는 hash 캐시에 기억되니, 새 위치로 옮긴 명령이 안 될 땐 hash -r.

입출력 리다이렉션·파이프

파일 디스크립터: 0=stdin, 1=stdout, 2=stderr.

표현	효과
`cmd > file`	표준출력을 file로(덮어쓰기)
`cmd >> file`	표준출력을 file에 추가
`cmd < file`	file에서 표준입력 읽기
`cmd 2> file`	표준에러를 file로
`cmd 2>&1`	표준에러를 표준출력으로 합침
`cmd &> file`	표준출력+에러 모두 file로(bash)
`cmd > /dev/null 2>&1`	모두 폐기

파이프 cmd1 | cmd2: cmd1의 표준출력을 cmd2의 표준입력으로 연결. ls | grep txt | wc -l. tee는 화면과 파일에 동시 출력(cmd | tee out.log).

메타문자·연산자

기호	의미
`*` / `?` / `[abc]`	glob(0개 이상 / 1개 / 문자집합)
`{a,b,c}`	브레이스 확장
`~`	홈
`;`	명령 순차 실행(앞 결과 무관)
`&&`	앞 명령 성공 시 다음(단락 평가)
`\|\|`	앞 명령 실패 시 다음
`$(cmd)`	명령 치환(`cmd` 대신 권장)
`$((expr))`	산술 확장
`#`	주석

스크립트 문법 — 제어 흐름 묶기

shebang과 실행

#!/bin/bash
# 더 이식성 높게: #!/usr/bin/env bash

실행 권한을 주고 ./script.sh, 또는 bash script.sh(실행 권한 불필요). shebang이 없으면 현재 셸로 해석되어 동작이 달라질 수 있으니 항상 명시하라.

변수·인자

#!/bin/bash
greeting="Hello"          # 할당 (= 양옆 공백 없음!)
name=$1                    # 첫 번째 인자
count=$#                   # 인자 개수
all="$@"                   # 모든 인자(따옴표 시 각각 보존)
exit_code=$?               # 직전 명령 종료 코드 (0=성공)
echo "$greeting, $name"    # 큰따옴표 권장

조건문 — `[ ]` vs `[[ ]]`

if grep -q "root" /etc/passwd; then
    echo "root 존재"
elif [ ... ]; then
    echo "다른 경우"
else
    echo "나머지"
fi

[[ $a == *.txt ]]           # 패턴 매칭([[ ]]만)
[ -f /etc/hosts ]           # 파일 존재
[ -z "$var" ]               # 빈 문자열
[ $num -gt 5 ]              # 정수 비교(-eq -ne -lt -le -gt -ge)

현대 bash에선 [[ ]]를 권장한다 — 단어 분리가 안 되고, 패턴/정규식을 지원하고, 더 안전하다.

반복문·case

for f in *.txt; do echo "$f"; done
for ((i=0; i<5; i++)); do echo "$i"; done
while [ "$count" -lt 10 ]; do count=$((count+1)); done
while IFS= read -r line; do echo "$line"; done < input.txt

case "$1" in
    start)   systemctl start nginx ;;
    stop)    systemctl stop nginx ;;
    *)       echo "usage: $0 {start|stop}"; exit 1 ;;
esac

함수

greet() {
    local name="$1"          # local: 함수 내 한정
    echo "Hi, $name"
    return 0                 # 종료 코드만(0~255)
}
msg=$(greet "world")         # 출력을 변수로 회수

return은 종료 코드만 반환한다. 데이터를 돌려받으려면 echo + 명령 치환($(...)).

안전 모드 — 모든 스크립트에 권장

set -e             # 오류 시 즉시 종료
set -u             # 미정의 변수 사용 시 오류
set -o pipefail    # 파이프 어느 단계 실패 시 전체 실패
# 한 줄: set -Eeuo pipefail

단, set -e는 if/while 조건문 안의 실패나 파이프 마지막 단계만 검사한다. 파이프 전체를 잡으려면 set -o pipefail로 보완.

Rocky 10에서 직접 확인하기

미검증(출처 인용). 표준 bash라 Ubuntu/WSL에서도 대부분 동일.

echo "$SHELL"             # /bin/bash
echo "$BASH_VERSION"      # 5.x
ps -p $$ -o comm=         # 현재 셸
cat /etc/shells           # 사용 가능 셸 목록

env | sort | head
echo "$PATH"
which systemctl
export PATH="$PATH:/opt/myapp/bin"   # 현재 세션 임시 추가

실용 스크립트 예(백업):

#!/bin/bash
set -Eeuo pipefail

src="${1:?usage: $0 <src> <dest>}"
dest="${2:?usage: $0 <src> <dest>}"
ts=$(date +%Y%m%d-%H%M%S)

if [[ ! -d "$src" ]]; then
    echo "error: $src not a directory" >&2
    exit 1
fi

tar -czf "${dest}/backup-${ts}.tar.gz" -C "$src" .
echo "backup done: ${dest}/backup-${ts}.tar.gz"

# ~/.bashrc 에 추가해 별칭·함수 영구화
alias ll='ls -lh'
mkcd() { mkdir -p "$1" && cd "$1"; }
source ~/.bashrc            # 적용

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"`VAR = value`"	오류. `VAR=value`(공백 없음)만 정상
"`rm $file` 안전하다"	파일명에 공백 있으면 재앙. 항상 `"$file"`
"`[ $a > $b ]` 정수 비교"	리다이렉션으로 해석(위험). `-gt`/`-lt` 또는 `(( a > b ))`
"`$?`는 마지막 결과"	직전 명령 코드. 사이에 다른 명령 끼면 덮어씀
"`&&`는 항상 다음 실행"	단락 평가. 앞 실패 시 다음 안 됨. 정리 무조건 필요하면 trap
"스크립트 안 `export`가 부모 셸에 영향"	아니다. 자식에만. 부모에 적용은 `source`
"shebang 없어도 된다"	현재 셸로 해석될 수 있어 동작 다를 수 있음. 항상 shebang 명시
"`set -e`는 모든 실패를 잡는다"	`if`/`while` 조건문 안 실패나 파이프 마지막 단계만 검사. `set -o pipefail`로 보완

더 깊이

프로세스 치환: <(cmd)는 명령 출력을 임시 파일처럼 쓰게 한다 — diff <(ls dir1) <(ls dir2). 임시 파일 없이 두 명령 출력을 비교.
배열·연관배열: arr=(a b c), declare -A m; m[name]="alice" (bash 4+).
trap으로 정리: trap 'cleanup' EXIT로 스크립트 종료 시(정상/오류/시그널) 항상 정리 함수를 실행. 임시 파일 제거·잠금 해제에 필수.

요약 — 이 글의 결론

셸(bash) = 명령 해석기 + 스크립트 언어. /bin/sh는 bash(RHEL).
확장 순서: 브레이스 → 틸드 → 변수/명령/산술 → 워드분리 → glob → 리다이렉션 → 실행. ls *.txt에서 별을 펼치는 건 셸이다.
따옴표: " "(변수 O, glob X), ' '(모두 X). 파일명엔 항상 "..." — 공백 재앙을 막는다.
환경변수(export)만 자식 상속. 셸 변수는 현재 셸만. PATH엔 .이 없다(보안).
리다이렉션: >(덮어쓰기), >>(추가), 2>&1(에러를 출력으로), &>(모두).
[[ ]] > [ ]: 더 안전, 패턴 매칭 지원.
안전 모드: set -Eeuo pipefail. 단 set -e는 pipefail로 보완해야 파이프 실패를 잡는다.
변수 할당: VAR=value(공백 없음). $?는 직전 종료 코드.

생각해 볼 문제

ls *.txt를 칠 때 *를 처리하는 주체는 누구인가?
'...'와 "..."의 차이는? 파일 이름에 공백이 있을 때 왜 "..."를 써야 하는가?
셸 변수와 환경변수의 차이. 자식 프로세스는 무엇을 상속받는가?
현재 디렉토리가 PATH에 없는 이유(보안)는?
cmd > /dev/null 2>&1의 의미를 풀어 설명하라.
&&와 ;의 차이는?
[ ]와 [[ ]]의 차이. 현대 bash에서 어느 것을 권장하는가?
스크립트에 set -e가 있을 때의 효과와 한계는?

참고

Bash Reference Manual — GNU - 접근 2026-07-09
Advanced Bash-Scripting Guide - 접근 2026-07-09
man page: man bash, man test, man hier, man printf(1)
POSIX Shell: pubs.opengroup.org

Linux - 06. io device

dongka — Thu, 9 Jul 2026 14:27:09 +0900

SSD, 키보드, 네트워크 카드를 같은 방식으로 다룬다 — 장치 추상화와 LVM

서버에 디스크를 하나 더 꽂았다. 이제 공간이 모자라니 LVM으로 볼륨을 늘리고 싶다. 그런데 스크립트가 /dev/sda1을 찾는데 실제는 /dev/nvme0n1p1이라 실패한다 — 왜 이름이 다르지? 또 모든 드라이버를 커널에 넣지 않고도 필요할 때만 쓸 수 있는데, 어떻게?

이 글은 리눅스가 수십~수백 종의 하드웨어를 일관되게 다루는 방식(장치 파일 추상화)과, 고정된 물리 디스크를 유연하게 쪼개고 합치는 방식(LVM)을 다룬다. 서버 운영 일상 — 디스크 추가, LVM 확장, 드라이버 적재 — 의 기반을 잡는다.

하드웨어도 파일이다 — 장치 파일과 major/minor

리눅스는 "모든 것은 파일" 원칙에 따라 하드웨어를 /dev 아래 파일로 노출한다. 그래서 디스크는 cat으로, 키보드는 read로 접근할 수 있다(물론 권한이 있어야). 각 장치는 major:minor 번호로 식별된다:

major: 장치 종류/드라이버(예: 8 = SCSI/SATA 디스크)
minor: 같은 드라이버 내 개별 장치(예: 0 = 첫 디스크, 1 = 첫 파티션)

ls -l /dev/sda1
# brw-rw---- 1 root disk 8, 1 ...   ← 'b'=블록, major=8, minor=1

블록 장치 vs 문자 장치

구분	블록 장치(`b`)	문자 장치(`c`)
접근	랜덤 접근(임의 블록)	순차 스트림
단위	블록(512B/4KiB)	바이트
예	디스크(`/dev/sda`, NVMe), 램디스크	직렬 포트(`/dev/tty`), `/dev/null`, `/dev/random`

자주 쓰는 `/dev` 노드

노드	용도
`/dev/null`	읽으면 EOF, 쓰면 버림(출력 폐기)
`/dev/zero`	읽으면 0x00 무한 제공
`/dev/random`	엔트로피 기반 난수
`/dev/urandom`	의사난수(블록 안 됨, 빠름)
`/dev/sda`, `/dev/nvme0n1`	디스크 전체
`/dev/sda1`, `/dev/nvme0n1p1`	디스크 파티션
`/dev/mapper/rl-root`	LVM 논리 볼륨

LVM — 레고 블록으로 조립하는 유연한 디스크

물리 디스크는 고정되어 있다. 디스크 2개(각 1TB)를 합쳐 2TB 하나처럼 못 쓰면 공간이 비효율적이고, 공간이 모자랄 때 파티션을 옮기지 않고는 확장할 수도 없다. LVM(Logical Volume Manager)이 이를 푼다.

	LVM	레고 블록
기본 단위	PV(물리 디스크)	레고 베이스판
모으기	VG(볼륨 그룹)	베이스판 여러 개 연결 → 큰 작업판
잘라 쓰기	LV(논리 볼륨)	작업판에서 원하는 크기로 조립

레고 비유는 "작은 것을 모아 크고 유연하게"만 잡는다. LVM은 PE(Physical Extent, 보통 4 MiB) 단위의 논리 매핑이고, LV는 데이터를 유지하며 확장된다(축소는 위험).

flowchart LR
    PV1[PV<br/>/dev/sda] --> VG[VG<br/>volgroup]
    PV2[PV<br/>/dev/sdb] --> VG
    VG --> LV1[LV<br/>root]
    VG --> LV2[LV<br/>swap]
    VG --> LV3[LV<br/>data]

PV(Physical Volume): LVM용으로 초기화한 디스크/파티션(pvcreate).
VG(Volume Group): PV들의 풀. 여러 PV를 묶어 하나의 가상 디스크처럼(vgcreate).
LV(Logical Volume): VG에서 잘라낸 논리 볼륨. 파일 시스템을 올리는 단위(lvcreate).
PE/LE: PV의 최소 할당 단위 = LV의 최소 단위. 보통 4 MiB.

LVM이 주는 것: 여러 물리 디스크를 하나의 거대 볼륨으로, 온라인 크기 조정(fs 언마운트 불필요), 스냅샷·thin provisioning·mirroring.

RHEL 9+/Rocky 10의 LVM은 devices file(/etc/lvm/devices/system.devices)로 사용 디스크를 추적한다. lvmdevices로 관리. 기존 filter 방식보다 명시적이다.

Rocky 10 기본 설치 구조:

sda
├─sda1 → /boot (파티션)
└─sda2 → rl VG
         ├─rl-root LV (17G) → /
         └─rl-swap LV (2G)  → [SWAP]

파티션 — MBR vs GPT, 그리고 NVMe 이름의 비밀

항목	MBR(MSDOS)	GPT(GUID)
최대 디스크	2 TiB	사실상 무제한
최대 파티션	4개 주(확장 시 더)	128개(기본)
부팅	BIOS/Legacy	UEFI
권장	구 시스템	현대(Rocky 10 기본)

디스크가 2 TiB 이상이거나 UEFI면 GPT가 필수다.

NVMe vs SATA 이름 — 자주 걸리는 함정

초보자는 디스크 파티션을 무조건 /dev/sda1로 생각한다. 하지만 NVMe는 /dev/nvme0n1(컨트롤러0 네임스페이스1), 파티션은 /dev/nvme0n1p1(p가 붙는다). SATA/SCSI는 /dev/sda1. 이 차이를 모르면 스크립트가 NVMe 시스템에서 실패한다.

커널 모듈 — 런타임에 드라이버를 끼웠다 뺐다

모든 드라이버를 커널에 넣으면 커널이 비대해지고 메모리가 낭비된다. 해법은 필요할 때만 로드하는 것이다. 커널 기능/드라이버는 런타임에 동적 적재 가능한 코드(.ko)로, /lib/modules/<커널버전>/에 있다. 재부팅 없이 기능을 추가·제거할 수 있어 메모리를 절약한다.

insmod vs modprobe — 왜 modprobe를 써야 하나

초보자가 자주 insmod를 쓴다. modprobe가 낫다. insmod는 의존성을 무시한다 — 단일 파일을 강제 로드하며, 의존 모듈이 빠지면 실패. 반면 modprobe는 의존 모듈까지 자동으로 처리한다(depmod가 만든 modules.dep 기반). 항상 modprobe를 써라.

udev — 장치를 자동으로 인식한다

systemd-udevd가 장치 이벤트(핫플러그)를 감지해 /dev 노드를 자동 생성하고 이름을 붙인다. 디스크를 꽂으면 자동으로 /dev/sdb가 생기고, 영구 이름도 만든다: /dev/disk/by-uuid/, /dev/disk/by-id/.

fstab/GRUB에 UUID를 쓰는 이유: /dev/sdb는 부팅마다 바뀔 수 있다. UUID나 by-id는 고정되어 마운트 실패를 막는다. lsblk는 sysfs + udev DB를 읽어 정보를 표시한다.

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

lsblk                    # 트리 형태
lsblk -f                 # 파일시스템/UUID 포함
blkid                    # UUID/타입/라벨
findmnt                  # 마운트 트리

NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda             8:0    0   20G  0 disk
├─sda1          8:1    0    1G  0 part /boot
└─sda2          8:2    0   19G  0 part
  ├─rl-root   253:0    0   17G  0 lvm  /
  └─rl-swap   253:1    0    2G  0 lvm  [SWAP]

# Rocky 10 — 파티션 관리
sudo fdisk -l                    # 전체 디스크/파티션
sudo parted /dev/sdb print       # GPT/MBR 무관 범용
sudo fdisk /dev/sdb              # 파티션 생성(대화형)

# Rocky 10 — LVM 확장(자주 쓰는 절차)
sudo pvcreate /dev/sdb                 # 1. 새 디스크를 PV로
sudo vgextend rl /dev/sdb              # 2. 기존 VG에 추가
sudo lvextend -L +10G /dev/rl/root     # 3. LV 확장(+10G)
sudo xfs_growfs /                      # 4. 파일 시스템까지 확장(XFS)
# sudo resize2fs /dev/rl/root          #    (ext4)
pvs && vgs && lvs                      # 상태 확인

# Rocky 10 — 커널 모듈
lsmod                            # 적재된 모듈
modinfo xfs                      # 모듈 정보
sudo modprobe zram num_devices=1 # 모듈 로드(의존성 자동)
sudo modprobe -r zram            # 제거
ls /lib/modules/$(uname -r)/     # 모듈 디렉토리

# Rocky 10 — 영구 식별자: fstab에 안전하게 쓰려면
ls -l /dev/disk/by-uuid/ | grep sda1
ls -l /dev/disk/by-id/
sudo udevadm monitor             # 실시간 장치 이벤트

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"NVMe 파티션은 `/dev/nvme0n11`"	`/dev/nvme0n1p1`(p 붙음). SATA는 `/dev/sda1`
"`insmod`와 `modprobe`는 같다"	`insmod`는 의존성 무시. 항상 `modprobe`
"LVM 축소는 확장처럼 쉽다"	데이터 손실 위험. fs 먼저 축소 후 LV 축소. XFS는 축소 자체 불가
"파티션 생성하면 바로 쓴다"	아니다. 위에 파일 시스템 생성(`mkfs.xfs`) 별도, 마운트도 별도
"`/dev/sdb`는 항상 같은 디스크"	부팅마다 바뀔 수 있음. fstab엔 UUID/by-id 사용
"LVM은 예전 기술이다"	현대 RHEL/Rocky 기본. thin pool, 스냅샷, vdo 등 계속 진화
"커널 모듈은 재부팅해야 로드된다"	`modprobe`로 런타임 로드 가능. `/etc/modules-load.d/`로 영구화

더 깊이

LVM thin provisioning: 일반 LV는 할당 즉시 공간을 예약하지만, thin pool은 실제 쓰는 만큼만 할당한다(over-provisioning 가능). 가상화·컨테이너 환경에 유리. 단, over-provision 시 풀 고갈에 주의.
device mapper: LVM은 커널 device mapper(DM) 계층 위에 구현된다. DM은 블록 장치를 매핑·재조합하는 범용 계층(LVM, multipath, dm-crypt가 모두 DM 사용). dmsetup으로 저수준 확인.
VDO(Virtual Data Optimizer): 중복 제거·압축으로 디스크 공간을 절약. 백업 스토리지에 유리.

요약 — 이 글의 결론

장치 파일: 하드웨어를 /dev 아래 파일로. major:minor 번호로 식별. 블록(랜덤, 디스크) vs 문자(스트림, 터미널/null).
LVM: PV → VG → LV. 레고 블록처럼 모으고 자른다. 온라인 확장 가능(축소는 위험). Rocky 10은 devices file로 디스크 추적.
파티션: MBR(2 TiB 한계, BIOS) vs GPT(대용량, UEFI, Rocky 10 기본).
NVMe 명명 함정: /dev/nvme0n1, 파티션은 nvme0n1p1(p 붙음). SATA는 /dev/sda1. 스크립트가 여기서 자주 실패.
커널 모듈: 런타임 적재. modprobe(의존성 자동) > insmod.
udev: 핫플러그 자동 인식, /dev 노드 생성. 영구 이름(by-uuid/by-id) 제공 — fstab엔 /dev/sdX 말고 UUID를 써라(부팅마다 이름이 바뀔 수 있으니).

생각해 볼 문제

블록 장치와 문자 장치의 차이와 각각 예를 말하라.
/dev/null, /dev/zero, /dev/random의 용도를 말하라.
LVM에서 PV, VG, LV의 관계를 그려보라. 왜 LVM이 일반 파티션보다 유연한가?
NVMe 디스크의 첫 파티션 장치 이름은? SATA와 왜 다른가?
MBR과 GPT의 주요 차이. 언제 GPT가 필수인가?
insmod 대신 modprobe를 써야 하는 이유는?
/dev/sdb 대신 fstab에 UUID를 써야 하는 이유는?
LVM LV를 축소할 때 주의할 점은? XFS는 왜 축소 불능인가?

참고

Linux allocated devices — Kernel docs - 접근 2026-07-09 (장치 major/minor)
lvm(8) manual - 접근 2026-07-09 (PV/VG/LV)
lvmdevices(8) — man7 - 접근 2026-07-09
man page: man lsblk, man blkid, man fdisk, man parted, man lvcreate, man modprobe, man udev(7)

Linux - 05. filesystem

dongka — Thu, 9 Jul 2026 14:25:45 +0900

inode에는 파일 이름이 없다 — 파일 시스템이 감추는 것

"Permission denied"가 떴다. 파일 권한을 고쳤는데도 안 된다. 왜? 종종 진짜 원인은 파일이 아니라 부모 디렉토리에 있다. 또 디스크에 공간이 남았는데 파일이 안 만들어진다 — 이번엔 inode가 다 떨어졌기 때문이다. 이런 일들은 파일 시스템이 실제로 어떻게 돌아가는지를 모르면 진단할 수 없다.

리눅스는 "모든 것은 파일"이라고 한다. 그런데 디스크는 그냥 0과 1의 블록 덩어리다. 이 블록들을 어떻게 "이름 있는 파일"로 조직하고, 누가 접근할지 통제하는가 — 이 글이 푸는 질문이다.

"모든 것은 파일" — VFS 추상화

리눅스는 디스크 파일, 하드웨어 장치, 프로세스 정보, 네트워크 소켓까지 모두 파일로 다룬다. 그래서 같은 도구(cat, ls, grep)로 모든 것을 조작할 수 있다. 이 통일을 가능하게 하는 커널 계층이 VFS(Virtual File System)다.

flowchart TB
    APP[응용 프로그램<br/>open/read/write] --> VFS[VFS 계층<br/>공통 인터페이스]
    VFS --> XFS[XFS 드라이버]
    VFS --> EXT[ext4 드라이버]
    VFS --> PROC[procfs/proc]
    VFS --> SYS[sysfs/sys]
    VFS --> DEV[devtmpfs/dev]

VFS는 각 파일 시스템(XFS/ext4/proc/sysfs 등)의 차이를 감추고 동일한 시스템 콜을 제공한다. 덕분에 cat/ls가 XFS든 procfs든 같은 방식으로 동작하고, /proc/meminfo를 cat으로 읽는 것이 가능하다.

inode에는 이름이 없다 — 도서관 카드 카탈로그

많은 초보자가 "inode에 파일 이름이 들어있겠지"라고 생각한다. 틀렸다. inode에는 파일 이름이 없다. 이름은 디렉토리가 보관한다(이름 → inode 번호 매핑 표).

	파일 시스템	도서관
파일 이름	"report.pdf"	책 제목
inode	메타데이터 + 데이터 블록 포인터	카드 카탈로그(위치·저자·페이지 수)
데이터 블록	실제 파일 내용	실제 책
디렉토리	이름 → inode 매핑 표	색인함(제목 → 카드 위치)

도서관 비유는 "이름은 카드에 없고 색인함에 있다"는 관계만 잡는다. 파일 시스템은 같은 inode에 이름 여러 개(하드 링크)가 가능하고, 디스크는 블록 단위 비연속 할당이라는 점에서 비유를 넘어선다.

이름이 inode가 아니라 디렉토리에 있다는 설계 덕분에:

같은 inode에 여러 이름(하드 링크)을 가질 수 있다.
파일 이름 바꾸기(mv)는 데이터 복사 없이 디렉토리 항목만 변경 → 즉시 완료.

구조를 보자:

flowchart LR
    BS[Boot Sector] --> SB[Superblock<br/>전체 메타정보]
    SB --> IT[Inode Table<br/>파일 메타데이터]
    IT --> DB[Data Blocks<br/>실제 파일 내용]

Superblock: 파일 시스템 전체 정보(크기, 타입, 마운트 상태). 손상 시 복구 대상.
inode: 파일 1개당 1개. 권한·소유자·크기·타임스탬프 + 데이터 블록 포인터.
Data block: 실제 파일 데이터.

inode 고갈의 함정: 디스크 여유 공간이 있어도 inode가 다 떨어지면 파일 생성이 안 된다(df -i로 확인). 작은 파일 수십만 개(메일 큐 등)가 있는 시스템에서 발생한다. "공간은 있는데 파일이 안 만들어진다"의 원인.

XFS vs ext4 — Rocky 10의 기본은 XFS

항목	XFS(RHEL 10 기본)	ext4
개발	SGI, 1990년대 초	리눅스 전통(ext2/3 진화)
확장	성장만 가능(grow), 축소 불가	성장/축소(축소는 오프라인) 모두
inode	동적 할당, 64-bit(2^32 한계 없음)	고정, 2^32 한계
대용량/IOPS	대형 파일·고동시성에 강	단일 스레드/소규모에 적합
특수 기능	reflink(COW 복사), xattr, project quota	익숙함, 단순
생성/복구	`mkfs.xfs` / `xfs_repair`	`mkfs.ext4` / `e2fsck`

특별한 이유 없으면 XFS(RHEL 기본)를 써라. 현대 서버는 대용량·고동시성이고, XFS는 대형 파일(수백 MB 이상)·수천 IOPS 환경에서 ext4보다 일관되게 우수하다. 또 reflink(COW 복사)로 스냅샷·백업이 효율적이다. 단, 축소 불가는 단점 — 줄이려면 백업→재생성해야 한다.

FHS — 디렉토리 계층 표준

리눅스 디렉토리 구조는 FHS(Filesystem Hierarchy Standard)로 표준화되어 있다. 핵심 디렉토리:

경로	용도
`/`	최상위 루트
`/bin`, `/sbin`	기본 명령. RHEL 8+부터 `/usr/bin`, `/usr/sbin`으로 심볼릭 통합
`/boot`	커널·initramfs·GRUB 부트 파일
`/etc`	시스템 설정 파일(editable text configuration)
`/usr`	UNIX System Resources — 사용자 명령·라이브러리·문서
`/var`	가변 데이터 — 로그, 스풀, 메일
`/home`, `/root`	일반 사용자 홈 / root 홈
`/tmp`	임시 파일(부팅 시 초기화 가능)
`/dev`	장치 파일(블록/문자 장치)
`/proc`	가상 fs — 커널/프로세스 정보(`/proc/<pid>/`, `/proc/meminfo`)
`/sys`	가상 fs — 하드웨어/커널 모듈 정보(sysfs)
`/mnt`, `/media`	임시 마운트 / 이동식 미디어
`/run`	런타임 데이터(부팅마다 초기화, 과거 `/var/run`)

권한 — 9비트가 누가 뭘 할 수 있는지를 결정한다

각 파일/디렉토리는 3개 주체 × 3개 권한 = 9비트(+특수 3비트)로 통제된다.

주체	기호	권한	파일	디렉토리
소유자	`u`	`r`(4)	내용 읽기	`ls`(목록 조회)
그룹	`g`	`w`(2)	내용 수정	파일 생성/삭제
그 외	`o`	`x`(1)	실행	진입(`cd`)

8진수: rwx = 4+2+1 = 7. 예: 755 = rwxr-xr-x.

디렉토리 x권한의 비밀

초보자가 자주 틀리는 부분: "디렉토리에 x가 있으면 실행? 이상하다." — 디렉토리에서 x는 '진입'(cd) 권한이다. 디렉토리에 r만 있고 x가 없으면 ls는 되지만 cd/내부 파일 접근이 안 된다. r은 목록 보기, x는 들어가기.

특수 비트

비트	기호	8진수 자리	효과
setuid	`s`(user 자리)	첫 자리 4	실행 시 소유자 권한으로 동작(예: `/usr/bin/passwd`)
setgid	`s`(group 자리)	첫 자리 2	파일: 그룹 권한으로 실행. 디렉토리: 새 파일이 디렉토리 그룹 상속
sticky	`t`(others 자리)	첫 자리 1	공유 디렉토리에서 본인 소유 파일만 삭제(`/tmp`가 대표)

4자리 8진수: 4755 = setuid + rwxr-xr-x. 1777 = sticky + rwxrwxrwt(= /tmp).

파일 삭제 권한의 함정 — 도입부의 수수께끼 풀기

파일을 지우려면 파일 자체의 w 비트가 아니라 부모 디렉토리의 w 비트가 필요하다. 읽기 전용 파일(-r--r--r--)도 부모 디렉토리에 w가 있으면 지울 수 있다. "Permission denied"의 진짜 원인이 파일이 아니라 디렉토리인 이유다. /tmp는 sticky 비트 덕분에 남의 파일을 못 지운다.

마운트, fstab, 링크

파일 시스템을 디렉토리 트리에 연결하는 게 마운트다. /etc/fstab에 자동 마운트를 정의한다:

# 장치              마운트포인트  타입  옵션        dump fsck
/dev/mapper/rl-root /             xfs   defaults    0    0
UUID=...           /boot         xfs   defaults    0    0
/dev/mapper/rl-swap none         swap  defaults    0    0

컬럼 6개: 장치 / 마운트포인트 / 타입 / 옵션 / dump / fsck 순서. 부팅 시 자동 마운트되며, 변경 후엔 sudo mount -a로 검증한다.

하드 링크 vs 심볼릭 링크

항목	하드 링크	심볼릭 링크
명령	`ln 원본 링크`	`ln -s 원본 링크`
본질	같은 inode를 가리키는 또 하나의 이름	원본 경로를 담은 별개의 파일
inode	원본과 동일	다름(자체 inode)
원본 삭제	데이터 유지(링크 남음)	깨진 링크(dangling)
디렉토리	불가	가능
다른 fs	불가	가능

"inode에 이름이 없다"를 떠올려라. 하드 링크는 같은 inode에 이름을 하나 더 추가하는 것이다. 그래서 원본을 "지워도" inode 참조가 남아있으면 데이터는 살아있다. 단, 하드 링크는 백업이 아니다 — 같은 inode를 가리킬 뿐, 복사가 아니다.

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

df -hT            # -h 인간판독, -T 타입
df -i             # inode 사용량(공간 있는데 안 만들어지면 확인)
du -sh /var/log   # 특정 디렉토리 합계

Filesystem              Type   Size  Used Avail Use% Mounted on
/dev/mapper/rl-root     xfs     17G  4.5G   13G  27% /

# Rocky 10 — inode 직접 확인: 이름은 inode에 없다
ls -i /etc/hosts            # inode 번호
stat /etc/hosts             # 메타데이터 전체

  File: /etc/hosts
  Inode: 1234567     Links: 1
  Access: (0644/-rw-r--r--)  Uid: (0/root)  Gid: (0/root)

확인할 것: stat 출력에 파일 이름은 없다. inode는 번호로만 존재한다.

# Rocky 10 — 권한 관리
chmod 755 script.sh          # 8진수
chmod u+x,g-w file.txt       # 기호
chmod -R 644 /var/www        # 재귀
sudo chown user:group file   # 소유권 변경
sudo chmod 4755 /usr/bin/myapp    # setuid
sudo chmod 1777 /shared           # sticky (=/tmp처럼)
umask                            # 신규 파일 기본 권한 마스크(보통 022)

# Rocky 10 — 마운트 관리
findmnt                       # 트리 형태
sudo mount /dev/sdb1 /mnt     # 수동 마운트
sudo mount -a                 # fstab 수정 후 문법 검증

# Rocky 10 — 하드 vs 심볼릭 체험
ln /etc/file /root/hardlink       # 하드(같은 inode)
ln -s /etc/file /root/softlink    # 심볼릭(다른 inode)
ls -li /root/                     # inode 확인(-i)

# Rocky 10 — setuid 파일 점검(보안)
find / -perm -4000 -type f 2>/dev/null   # setuid 파일(정기 점검 권장)
find /var -name "*.log" -mtime -1        # 1일 이내 .log
find /home -size +100M                    # 100MB 초과

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"디렉토리에 `x`는 의미 없다"	진입(`cd`) 권한. `r`만 있고 `x` 없으면 내부 접근 불가
"파일 지우려면 파일 `w` 필요"	부모 디렉토리 `w` 필요. 파일 자체는 읽기전용이어도 디렉토리 `w` 있으면 지움
"inode에 파일 이름이 있다"	없다. 이름은 디렉토리가 보관. 그래서 하드링크 가능
"`mv`는 데이터를 복사한다"	같은 파일 시스템 내에선 inode 그대로, 디렉토리 항목만 변경 → 즉시
"XFS는 ext4보다 무조건 좋다"	대용량/고동시성에 강하지만 축소 불가, 메타데이터 CPU 더 씀
"inode 고갈은 안 일어난다"	작은 파일 수백만 개(메일 큐) 시스템에선 발생. `df -i` 확인
"`/bin`과 `/usr/bin`은 다르다"	RHEL 8+부턴 `/bin` → `/usr/bin` 심볼릭. 사실상 같음
"하드 링크는 백업이다"	같은 inode 가리킬 뿐. 복사 아님. rsync/reflink이 진짜 복사

더 깊이

setuid의 보안 위험: setuid 파일은 권한 승격 통로다. /usr/bin/passwd(일반 사용자가 root 권한으로 /etc/shadow 변경)가 정당한 사례지만, setuid가 걸린 의심스러운 바이너리는 침해 통로. find / -perm -4000로 정기 점검하라.
reflink(XFS COW 복사): cp --reflink=always는 데이터 복사 없이 같은 블록을 참조(COW). 스냅샷·백업이 거의 즉시. Stratis 같은 스냅샷 기반 백업 솔루션의 기반.
atime/noatime: 파일 접근 시간(atime) 기록이 매 읽기마다 디스크 쓰기를 유발. 성능 중요 서버에선 noatime으로 끈다. RHEL 최근 기본은 relatime(필요 시만 갱신).

요약 — 이 글의 결론

VFS: 모든 파일 시스템을 통일 인터페이스로 추상화. "모든 것은 파일"의 기반.
inode: 파일 1개당 1개. 메타데이터 + 데이터 블록 포인터. 이름은 inode에 없다(디렉토리가 보관) — 이 설계가 하드 링크·빠른 mv를 가능하게 한다.
XFS(RHEL 10 기본): 대용량/고동시성 강, reflink. 축소 불가.
권한 9비트: rwx × (user/group/other). 디렉토리 x = 진입. 파일 삭제는 부모 디렉토리 w가 결정 — 이게 도입부 "Permission denied"의 진짜 원인.
특수 비트: setuid(4), setgid(2), sticky(1). /tmp = sticky(1777)라 남의 파일 삭제가 안 된다.
inode 고갈: 공간이 있어도 파일 생성 불가. df -i로 확인.

생각해 볼 문제

inode에 파일 이름이 있는가? 없다면 이름은 어디에 있고, 그 설계의 이점은?
디스크 공간이 있는데 파일 생성이 안 될 때 무엇을 확인하는가?
디렉토리에 r만 있고 x 없을 때 일어나는 일은?
읽기전용 파일(-r--r--r--)을 지울 수 있는가? 조건은?
setuid, setgid, sticky 비트의 8진수 값과 효과를 말하라. /tmp는 왜 남의 파일 삭제가 안 되는가?
하드 링크와 심볼릭 링크의 차이. 원본 삭제 시 각각 어떻게 되나?
VFS가 없다면 cat /proc/meminfo가 안 되는 이유는?

참고

Managing file systems — RHEL 10 - 접근 2026-07-09 (XFS/ext4 비교)
Getting started with XFS — RHEL 10 - 접근 2026-07-09
Rocky Linux 10 Admin Guide - File System - 접근 2026-07-09
man page: man hier(FHS), man chmod, man stat, man find, man inode(7), man fstab

Linux - 04. memory

dongka — Thu, 9 Jul 2026 14:22:18 +0900

각 프로세스는 수십 TB 메모리를 독점한다고 착각한다 — 가상 메모리의 속임

서버에서 free를 치면 "free가 거의 없다"고 나온다. 메모리 부족인가, 패닉할 일인가? 보통 아니다. 또 누군가 malloc(1GB)를 호출하면 즉시 1GB RAM이 사라질까? 그것도 아니다. 두 사실 모두 리눅스 메모리 관리가 만들어내는 환상의 결과다.

이 글은 그 환상을 다룬다 — 각 프로세스가 "자기만의 거대한 주소 공간"을 독점하는 듯 보이게 만드는 가상 메모리, RAM이 부족할 때 디스크까지 끌어쓰는 swap, 그리고 모조리 고갈됐을 때 시스템을 살리기 위해 프로세스를 죽이는 OOM killer까지. 이 셋을 모르면 free/vmstat 숫자를 읽을 수 없고, "서버가 느린데 CPU는 한가하다" 같은 메모리 병목을 진단하지 못한다.

가상 메모리 — 각자 자기만의 주소 세계

각 프로세스는 물리 RAM과 무관한 고유의 가상 주소 공간을 본다. x86_64에서 약 256 TiB(4-level) 또는 128 PiB(5-level). 물리 RAM은 8GB여도, 프로세스는 자기가 256 TB를 쓸 수 있다고 믿는다.

flowchart LR
    V["가상 주소<br/>프로세스 관점"] --> MMU["MMU + TLB"]
    MMU --> PT["페이지 테이블<br/>(커널 관리)"]
    PT --> P["물리 페이지 프레임"]

왜 이 속임수를 쓸까. 세 가지 문제를 한꺼번에 푼다:

격리/보안 — 프로세스 A의 "주소 100"과 프로세스 B의 "주소 100"은 물리적으로 다른 곳. 서로 침범 불가.
RAM보다 큰 공간 — demand paging(필요할 때만 할당)으로 실제 RAM을 넘는 주소 공간을 다룬다.
효율적 공유 — 같은 물리 페이지를 여러 프로세스가 공유(COW, 공유 라이브러리).

호텔 방 번호와 비슷하다: 각 층에 101호가 있지만 물리적 위치는 다르다. 단, 가상 메모리는 페이지가 디스크(swap)로도 갈 수 있고 여러 프로세스가 같은 물리 페이지를 공유할 수 있다는 점에서 호텔 비유를 넘어선다.

페이지, 페이지 테이블, TLB — 변환의 비용

메모리를 다루는 최소 단위는 페이지(x86_64 기본 4 KiB)다. 가상 주소 → 물리 주소 변환 정보는 페이지 테이블(계층 구조: PGD → P4D → PUD → PMD → PTE)에 있고, 이 변환을 캐시하는 하드웨어가 TLB(CPU MMU 내)다.

왜 TLB가 중요한가. 수치로 보자.

	지연	비고
L1 캐시 접근	~0.5 ns
TLB 히트	~1 ns	변환 캐시에서 즉시
메인 메모리 접근	~100 ns
TLB 미스 → 페이지 워크	~60-100 ns	페이지 테이블을 RAM에서 탐색

TLB 미스는 매 접근마다 메모리 탐색을 강제한다. 최악의 경우 CPU가 99% 시간을 주소 변환에 낭비할 수도 있다. 그래서 huge page(2 MiB/1 GiB)로 TLB 커버리지를 넓힌다 — 4 KiB 페이지 64개 엔트리는 256 KiB를 커버하지만, 2 MiB huge page 64개는 128 MiB를 커버. 대형 메모리 작업(DB)에 필수다.

malloc은 약속일 뿐이다 — demand paging

프로그램이 malloc(1GB)로 1GB를 요청하면, 즉시 1GB RAM이 할당될까? 아니다. malloc은 "이 주소 구간을 쓸 수 있다"는 약속만 할 뿐, 실제 물리 페이지는 그 주소에 처음 접근하는 순간에야 할당된다. 이걸 demand paging(요구 시 할당)이라 한다. 1GB를 malloc하고 1MB만 쓰면, 실제 RAM은 1MB만 점유한다. "오버 커밋"의 원리다.

접근 순간 페이지가 없으면 → 페이지 폴트 예외 → 커널이 그제야 물리 페이지를 확보하고 매핑 → 프로세스는 모르고 계속 실행.

flowchart TD
    A[프로세스 메모리 접근] --> B{TLB hit?}
    B -->|예| RUN[실행]
    B -->|아니오| C[페이지 워크]
    C --> D{PTE 존재?}
    D -->|예| RUN
    D -->|아니오| FAULT[페이지 폴트]
    FAULT --> T{유형}
    T -->|minor| M[zero/COW 페이지 할당<br/>디스크 I/O 없음]
    T -->|major| MA[디스크 읽기<br/>파일/swap-in]

폴트 유형	의미	비용
minor	COW, lazy alloc, 최초 zero 페이지	낮음(메모리만)
major	파일 mmap 미스 또는 swap-in → 디스크 I/O	높음(~~150μs~~10ms)
SIGSEGV	매핑 자체가 없거나 권한 위반	프로세스 종료

COW(Copy-On-Write) — fork가 빠른 이유

fork() 시 부모의 모든 페이지를 복사하면 느리다. 리눅스는 PTE를 읽기 전용으로 공유한다. 어느 한쪽이 쓰기하면 그때 minor 폴트로 그 페이지만 복사. fork 비용을 극적으로 낮춘다(03장 참조).

"free가 적은 건 정상이다" — 페이지 캐시

초보자가 free를 보고 "free가 거의 없다, 메모리 부족!"이라 패닉하는 게 가장 흔한 실수다. 틀렸다. 리눅스는 남는 RAM을 자동으로 디스크 캐시(페이지 캐시)로 쓴다. 빈 RAM은 낭비라는 철학 때문이다.

파일 읽기/쓰기는 페이지 캐시를 거친다(direct I/O가 아니면).
RAM 여유가 많으면 캐시가 커진다 → 다음 읽기가 빨라진다.
메모리 압력이 오면 커널이 캐시를 회수해 프로세스에 준다.

그래서 판단은 free 컬럼이 아니라 available 컬럼으로 해야 한다. free -h의 buff/cache가 바로 이 영역. available이 충분하면 free가 낮아도 정상이다.

RAM이 모자랄 때 — swap과 zram

RAM이 꽉 찼다. 새 할당 요청이 오면? (1) 캐시 회수 (2) 그래도 모자라면 — 사용 빈도 낮은(cold) 페이지를 디스크로 쫓아낸다. 이게 swap이다.

swap 파티션 또는 swap 파일.
vm.swappiness(0~200, 기본 60): 커널이 anonymous 페이지(프로세스 힙/스택)를 swap할 적극성. 높을수록 swap 선호.

zram은 RAM 일부를 압축하여 swap 장치로 사용하는 블록 장치(/dev/zramN)다. 디스크 I/O 없이 RAM 내에서 압축/해제 → 일반 swap보다 훨씬 빠르다. 메모리가 작은 시스템(라즈베리파이, 임베디드)에서 특히 효과적. Rocky 10 서버 설치 시 기본은 swap 파티션이며, zram은 별도 설정(zram-generator)으로 추가한다.

왜 swap이 느린가 — 수치로

	지연	비고
메모리 접근	~100 ns
zram swap-in	~수 μs	RAM 내 압축 해제
SSD swap-in	~150 μs	디스크 읽기(메모리의 1500배)
HDD swap-in	~10 ms	디스크 탐색(메모리의 10만 배)

swap이 잦으면 시스템이 이 수치 차이만큼 느려진다. 특히 HDD 서버에서 스와핑 폭주(thrashing)는 치명적이다. 잦은 스와핑은 RAM 증설 신호다.

swap을 0으로 두면? 고갈 시 즉시 OOM kill이 발생한다. 안정성을 위해 일정 swap을 권장한다. swappiness=0도 "안 하려 할 뿐"이지 절대 금지가 아니다 — 극한엔 여전히 swap한다.

최후의 방어 — OOM killer

swap까지 썼는데도 메모리가 완전 고갈되면, 시스템 전체가 멈추기 직전이 된다. 이때 시스템 보존을 위해 프로세스를 강제 종료하는 커널의 최후 방어가 OOM(Out-Of-Memory) killer다.

flowchart LR
    LOW[메모리 고갈] --> RECL[페이지 회수<br/>캐시/swap]
    RECL -->|부족| OOM[OOM killer 호출]
    OOM --> SCORE[각 프로세스 oom_score 계산]
    SCORE --> KILL[최고 점수 프로세스에 SIGKILL]

oom_score ≈ RSS + 0.5 × swap 사용량에 가중치.
/proc/<pid>/oom_score_adj(-1000 ~ 1000)로 점수 조정: -1000은 OOM kill 대상에서 사실상 제외(systemd가 journald/dbus에 적용), 1000은 최우선 kill 대상.

OOM은 무작위가 아니다. RSS가 큰(메모리 많이 쓰는) 프로세스가 희생된다. DB처럼 큰 메모리 프로세스가 잡히기 쉬우므로 oom_score_adj=-1000으로 보호하는 게 정상이다.

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

# Rocky 10 — 진짜 부족한가
free -h

판단: free가 낮아도 available이 충분하면 정상(캐시가 차지한 것). 진짜 부족 신호는 available 낮음 + 지속적 swap I/O.

               total   used   free   shared  buff/cache  available
Mem:            3.8Gi   1.2Gi  512Mi  120Mi   2.1Gi       2.2Gi
Swap:           2.0Gi   0.0Gi  2.0Gi

vmstat 1 5

읽는 법: si(swap-in)/so(swap-out)가 계속 0보다 크면 스와핑 발생 → 메모리 부족 신호.

cat /proc/meminfo | head -20
# MemTotal/MemFree/MemAvailable/Cached/SwapTotal/SwapFree

# Rocky 10 — swap 관리
swapon --show
sudo swapoff /dev/sdXN
cat /proc/sys/vm/swappiness       # 보통 60
sudo sysctl vm.swappiness=10      # 임시 변경
# 영구: /etc/sysctl.d/99-swappiness.conf

# Rocky 10 — zram 설정(옵션)
sudo modprobe zram num_devices=1
sudo zramctl /dev/zram0 --algorithm zstd --size 2G
sudo mkswap /dev/zram0
sudo swapon -p 100 /dev/zram0   # 우선순위 높게(디스크 swap보다 먼저)
zramctl

# Rocky 10 — OOM 점수: 누가 희생될까
for p in $(pgrep -f postgres); do
  echo "$p: $(cat /proc/$p/oom_score)"
done
# 중요 프로세스 보호 (예: PID 1234)
echo -1000 | sudo tee /proc/1234/oom_score_adj
# OOM 이력
journalctl -k | grep -i "out of memory"

cat /sys/kernel/mm/transparent_hugepage/enabled   # [always] madvise never
grep Huge /proc/meminfo

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"free가 적으면 메모리 부족"	틀림. `buff/cache`가 차지한 것. `available`로 판단
"swap은 쓰면 안 좋다, 0으로 두자"	swap 0이면 고갈 시 즉시 OOM kill. 안정성 위해 일정 swap 권장
"OOM은 무작위로 잡는다"	아니다. RSS 큰 프로세스 우선. DB가 희생되기 쉬움
"swappiness=0이면 swap 안 한다"	"안 하려 할 뿐"이지 절대 금지 아님. 극한엔 여전히 swap
"`malloc(1GB)`하면 1GB 즉시 할당"	아니다. demand paging. 실제 접근 전까지 물리 페이지 안 줌
"fork는 느리다(전체 복사)"	COW로 사실상 거의 안 복사. 매우 빠름
"페이지 캐시는 낭비다"	아니다. 빈 RAM이 낭비. 캐시가 있어야 다음 읽기가 빠름

더 깊이

overcommit 정책: vm.overcommit_memory — 0(휴리스틱 기본), 1(항상 승인), 2(엄격, CommitLimit 초과 시 실패). overcommit=1이면 malloc은 성공하지만 접근 시 OOM 발생 가능. 메모리 집약 서버는 2(엄격) 고려.
NUMA: 다소켓 서버는 CPU 소켓마다 가까운/먼 메모리가 있다. numactl로 바인딩. 단일 소켓 시스템은 무관.

요약 — 이 글의 결론

가상 메모리: 각 프로세스는 자기만의 거대 주소 공간(수십 TB)을 본다. 물리 RAM과 무관. 격리·보호·공유의 기반.
페이지(4 KiB) + 페이지 테이블 + TLB. TLB 미스는 비싸므로 huge page로 커버리지를 넓힌다.
demand paging: 접근할 때 물리 페이지 할당. malloc은 약속일 뿐이다.
페이지 폴트: minor(메모리만), major(디스크 I/O), SIGSEGV(권한/매핑 없음).
COW: fork 시 페이지 공유, 쓰기 시 복사 → fork가 빠르다.
페이지 캐시: 남는 RAM은 디스크 캐시. 판단은 available(free 아님). "free 적은 건 정상".
swap: RAM 부족 시 디스크로. zram은 RAM 내 압축 swap(더 빠름). swappiness로 조절.
OOM killer: 고갈 시 RSS 큰 프로세스를 SIGKILL. oom_score_adj=-1000으로 보호.
체감: 메모리 100ns vs SSD 150μs(1500배) vs HDD 10ms(10만 배). swap이 잦으면 이 차이만큼 느려진다.

생각해 볼 문제

가상 메모리가 없다면 어떤 3가지 문제가 생기는가?
malloc(1GB) 직후와 그 1GB에 실제로 접근한 후의 물리 메모리 점유량 차이는? 왜?
free에서 free가 낮은데 시스템이 정상인 이유는? 무엇을 봐야 하는가?
COW가 fork 비용을 어떻게 낮추는가?
swap이 잦으면 왜 시스템이 느려지는가? (수치로)
OOM killer가 RSS 큰 프로세스를 우선 잡는 이유는? 중요 프로세스는 어떻게 보호하는가?

참고

Memory Management Concepts — Linux Kernel docs - 접근 2026-07-09
Page Tables — Linux Kernel docs - 접근 2026-07-09
zram — Linux Kernel docs - 접근 2026-07-09
Latency Numbers — Google SRE - 접근 2026-07-09
man page: man free, man vmstat, man swapon, man proc(5), man mmap(2)

Linux - 03. process

dongka — Thu, 9 Jul 2026 14:17:51 +0900

수백 개 프로그램이 코어 몇 개를 나눠 쓰는 법 — 프로세스와 스케줄러

컴퓨터를 켜면 웹 브라우저, 셸, SSH 서버, 시스템 모니터까지 수십 ~ 수백 개 프로그램이 "동시에" 돌아간다. 하지만 CPU 코어는 보통 4 ~ 16개뿐이다. 어떻게 가능할까?

정답은 CPU를 매우 빠르게 번갈아 쓰기 때문이다. 1초에 수천 번 문맥(context)을 바꿔가며 각 프로그램에 조금씩 CPU를 나눠준다. 사람 눈엔 "동시에" 보이지만, 실은 빠른 교대 실행일 뿐이다. 이 교대를 가능하게 하는 두 추상 — 프로세스(독립된 메모리 방을 가진 실행 단위)와 스케줄러(수백 개 중 지금 누구를 CPU에 올릴지 고르는 커널의 판관) — 가 이 글의 주제다.

이 둘을 모르면 "프로세스가 응답 없다", "좀비가 쌓인다", "CPU를 하나만 잡아먹는다" 같은 문제를 진단할 수 없다.

프로세스와 스레드 — 격리의 단위가 갈린다

	프로세스	스레드
비유	독립된 단독 주택 — 자기 마당·부엌·창고	쉐어하우스의 방 — 거실·부엌·창고는 공유, 방만 내 것
메모리	자기만의 가상 주소 공간(남이 못 건드림)	같은 프로세스의 주소 공간을 서로 공유
안전	하나가 죽어도 다른 건 안전	한 스레드가 공유 메모리를 망치면 형제도 사고
만들기 비용	큼(주소 공간 복사)	작음(스택만 추가)

이 비유는 "메모리 격리"만 잡는다. 스레드의 진짜 핵심 — 스케줄링 단위가 커널의 task라는 것 — 은 비유 너머에 있다.

정확한 사실을 보자. 리눅스 커널은 프로세스와 스레드를 모두 같은 task_struct 구조체로 다룬다. 차이는 주소 공간을 공유하느냐뿐이다.

프로세스: 자기 task_struct + 자기 mm_struct(주소 공간)
스레드: 자기 task_struct + 형제의 mm_struct를 공유

사용자 입장에선 프로세스/스레드 구분. 커널 입장에선 둘 다 "task"다. 그래서 리눅스에서 스레드를 "lightweight process"라 부르기도 한다.

생성 비용의 체감: fork()로 프로세스를 만드는 건 ~ 수백 μs(주소 공간 복사, 실제론 COW로 지연), pthread_create()로 스레드를 만드는 건 ~ 수십 μs(스택만). 스레드가 한 자릿수 빠르다. 그래서 수천~

수만 동시 처리(웹 서버)에선 스레드나 이벤트 방식을 쓴다. 단, 격리·안전이 필요하면 프로세스가 낫다 — 상황에 따라. (수치는 규모의 직관용이지 정확값은 시스템마다 다름.)

새 프로그램은 fork와 exec, 두 단계로만 띄운다

여기서 많이 틀린다. "bash가 ls를 실행한다 = bash가 ls 코드를 직접 부른다"라고 생각하기 쉽다. 아니다. 실제로는:

bash가 자기 복사본을 하나 더 만들고(fork)
그 복사본이 자기 자신을 ls로 덮어쓴다(exec)
ls가 끝나면 복사본은 사라진다(exit)
bash가 그 종료 코드를 회수한다(wait)

원래의 bash는 그대로 살아있다. 이것이 리눅스에서 새 프로그램을 띄우는 유일한 방법이다.

sequenceDiagram
    participant B as bash (PID 100)
    participant K as 커널
    participant L as ls (PID 101)
    B->>K: fork()
    K-->>B: 새 PID 101 생성 (bash 복사본)
    K-->>L: PID 101 = bash 복제, 아직 bash 코드 실행 중
    L->>K: exec("ls")
    K-->>L: PID 101의 메모리를 ls로 덮어씀 (PID는 그대로 101)
    L->>L: ls 코드 실행, 결과 출력
    L->>K: exit(0)
    K-->>B: SIGCHLD + 종료코드 대기
    B->>K: wait()
    K-->>B: 종료코드 0 회수 → PID 101 소멸

단계	시스템 콜	무슨 일	PID 변화
복제	`fork()`	부모의 거의 완전한 복사본 생성(COW)	새 PID
교체	`exec()`	현재 프로세스의 코드/메모리를 새 프로그램으로 교체	PID 그대로(중요)
종료	`exit()`	프로세스 종료, 종료코드를 커널에 저장	—
회수	`wait()`	부모가 자식의 종료코드 회수	사라짐

왜 fork와 exec을 분리했는가

이 분리는 Unix의 천재적 설계다. 두 단계 사이에 부모는 자식의 환경(파일 기술자, 환경변수, 권한)을 자유롭게 조작할 수 있다. 셸의 리다이렉션(> file), 파이프(|), 백그라운드(&)가 전부 이 "사이"에서 일어난다. 단일 호출이었다면 이 유연성이 불가능했다.

좀비(Z) — 회수되지 않은 종료자

자식이 exit() 했는데 부모가 wait()을 안 하면? 자식은 종료했지만 사라지지 못한 상태로 남는다. 이게 좀비다.

흔한 오해: "좀비는 시스템을 위협하는 괴물" — 보통 아니다. 좀비는 메모리를 거의 안 쓴다(커널에 종료코드 한 줄만 보관). 진짜 문제는 PID를 소모한다는 것. PID 한계(보통 32768~약 400만 개)에 도달하면 새 프로세스를 못 만든다.

좀비 해법: 좀비를 직접 죽일 수 없다(SIGKILL도 안 통함). 부모가 wait()하게 하거나, 부모를 죽여서 init(systemd, PID 1)이 회수하게 해야 한다.

프로세스 상태 다섯 가지 — ps 출력이 말하는 것

flowchart LR
    R((R<br/>실행/실행대기)) -->|이벤트 대기| S((S<br/>수면))
    S -->|이벤트 도착| R
    R -->|시그널/트레이스| T((T<br/>정지))
    T -->|SIGCONT| R
    R -->|exit| Z((Z<br/>좀비))
    Z -->|부모 wait| X((소멸))
    S -.디스크 I/O 대기.-> D((D<br/>불가중 수면))
    D -.I/O 완료.-> R

기호	이름	한 줄	시그널로 빠져나올 수 있나
R	running/runnable	CPU에서 돌고 있거나 돌 차례를 기다리는 중	—
S	interruptible sleep	이벤트(타이머, I/O 완료) 기다리는 수면	O(대부분 시그널)
D	uninterruptible sleep	디스크 I/O 등 강제 수면	X(SIGKILL도 안 통함)
T	stopped	시그널(Ctrl+Z)이나 디버거로 멈춤	O(SIGCONT)
Z	zombie	종료했지만 부모가 아직 회수 안 함	X(직접 처리 불가)

D 상태의 함정

D 상태 프로세스가 있으면 root도 kill -9로 못 죽인다. D는 커널이 디스크(또는 NFS) 응답을 기다리는 동안 프로세스를 "절대 깨우지 마" 모드로 놓은 것이다. 보통 디스크가 느리면 잠깐 D → 해결이지만, NFS 서버가 죽었는데 마운트가 안 풀리면 D가 무한 지속 → 서버 재부팅 외엔 답이 없다. D가 오래 지속되면 저장소 문제를 의심하라.

시그널 — 비동기 알림과 "왜 SIGTERM을 먼저 써야 하나"

시그널은 커널이나 다른 프로세스가 프로세스에 던지는 작은 비동기 알림이다. 프로세스는 받으면 하던 일을 멈추고 정해진 동작을 수행한다.

시그널	번호	보통 어떻게 쓰나	무시 가능?
SIGTERM	15	"정리하고 종료해라"(`kill`의 기본)	O
SIGINT	2	"중단해라"(Ctrl+C)	O
SIGHUP	1	"설정 다시 읽어라"(데몬 관례)	O
SIGKILL	9	"당장 죽어라"(강제, 최후 수단)	X(무조건 죽음)
SIGSTOP	19	"멈춰라"(Ctrl+Z와 유사)	X(무조건 멈춤)
SIGCONT	18	"다시 돌아가라"	—
SIGCHLD	17	"자식이 죽었어"(부모에게)	O(보통 무시)

위험한 습관: "프로세스가 응답 없으면 kill -9부터" — SIGKILL(9)은 프로세스에게 정리 기회를 안 준다. 열어둔 파일이 flush 안 되어 데이터가 깨지거나, 잠금(lock)이 안 풀려 다른 프로세스가 멈출 수 있다.

올바른 순서: kill 1234(SIGTERM) → 30초 대기 → 그래도 안 죽으면 kill -9 1234. 정리할 기회를 먼저 줘라.

절대 무시 불가능한 시그널은 SIGKILL(9)과 SIGSTOP(19)뿐. 그래서 프로세스가 미친 듯이 돌 때 최후의 수단으로 쓴다. 단, D 상태 프로세스에는 SIGKILL도 대기 행렬에 들어갈 뿐 즉시 효과가 없다.

nice — 우선순위인데 왜 반대일까

모든 프로세스가 같은 우선권이면 급한 것과 안 급한 것을 구분 못 한다. 누구를 조금 더 자주 CPU에 올릴 것인가? 여기서 nice가 우선순위를 조절한다.

여기서 꼭 기억할 것: nice 값은 "작을수록 우선"이다. 일반적 직관(클수록 좋다)과 반대다.

nice	의미
-20	최우선(root만 설정 가능)
0	기본
+19	최하위

일반 사용자는 nice를 높이기만 가능(우선순위 낮추기만). 자기 프로세스를 더 우선시하려면 root 권한이 필요하다. 범위는 -20 ~ +19.

왜 반대일까? "nice"라는 이름 자체가 "다른 사람에게 양보(nice)한다"에서 왔다. nice 값이 높다 = 남에게 더 양보한다 = 내 우선순위가 낮아진다. 어원을 알면 헷갈리지 않는다.

커널은 누구에게 CPU를 줄까 — EEVDF가 CFS 자리를 빼앗은 이유

수백 개 프로세스가 코어 몇 개를 두고 줄을 선다. "공평"이란 대체 무엇일까. 2004년부터 커널은 CFS로 답했다 — "가장 오래 기다린 순"을 고른다. 그런데 2023년(kernel 6.6) 그 자리를 EEVDF가 빼앗았다. Rocky 10(커널 6.12)은 EEVDF를 쓴다. 왜 바뀌었을까.

EEVDF — 짧게 끝나는 일을 먼저

EEVDF의 핵심은 한 줄로 간다: 공평함은 유지하되, "짧게 끝나는 일(응답이 중요한 일)"을 더 빨리 처리한다. CFS는 "누가 더 기다렸나"만 봤다면, EEVDF는 "누가 더 기다렸나 + 이 작업이 얼마나 짧나"를 함께 본다. 짧게 끝날 작업의 deadline이 더 빠르게 잡히고, 그게 먼저 실행된다.

작동은 세 단계(굳이 외우지 않아도 된다):

각 작업의 lag(자기 몫 대비 덜/더 받은 정도) 계산
lag ≥ 0인 작업(eligible, 자기 차례 됨)만 후보
후보 중 deadline이 가장 빠른 작업 선택

EEVDF는 비유로 가르치기 어렵다(은행 줄·급한 사람 같은 비유는 정반대 직관을 심는다). 수치와 작동으로 이해하라.

실용적 의미: 데스크탑/대화형 작업(마우스 클릭, 오디오, 터미널 응답)이 더 빠르게 반응한다. 일반 서버 워크로드는 체감이 어렵다.

역사 박스 — CFS는 어떻게 작동했고, 왜 시대에 뒤처졌나

CFS(Completely Fair Scheduler)의 목표는 단순했다: "모든 프로세스에게 CPU를 공평하게 나눠준다." 각 프로세스마다 가상 시계(vruntime)를 하나씩 들려준다. CPU를 쓴 만큼 이 시계가 앞으로 간다. 스케줄러는 시계가 가장 뒤처진 프로세스를 다음으로 실행한다. 그러면 자연스럽게 모두의 시계가 비슷하게 맞춰진다 → 공평.

프로세스 A: vruntime = 100   ← 가장 작음, 다음 차례
프로세스 B: vruntime = 250
프로세스 C: vruntime = 300

nice가 낮으면(-20) 시계가 느리게 감 → 더 자주 차례가 옴 → 우선
nice가 높으면(+19) 시계가 빠르게 감 → 덜 차례가 옴 → 양보

CFS는 rbtree(레드블랙트리)로 vruntime 순 정렬 → 가장 작은 것을 O(1)에 선택했다. 매우 효율적이었다.

그런데 데스크탑·대화형 워크로드의 요구가 변했다. "공평"만으로는 터미널 입력 한 번에 반응이 느릴 수 있었다. EEVDF는 공평성(vruntime/lag)은 계승하되, 짧은 작업 우선(deadline)을 더해 대화형 반응을 끌어올렸다. 한 줄 요약: CFS = "가장 오래 기다린 순", EEVDF = "차례가 된 것 중 가장 짧게 끝날 순".

체감 수치 — 왜 이 복잡함이 필요한가

이 모든 복잡함(프로세스 분리, 스케줄러, 컨텍스트 스위치)이 왜 필요한지 수치로 체감하자.

연산	대략 지연	비고
CPU 레지스터 연산	~1 ns
L1 캐시 접근	~0.5 ns
메인 메모리 접근	~100 ns	L1의 약 200배
컨텍스트 스위치	~3-5 μs (3000-5000 ns)	캐시를 어느 정도 무효화
SSD 4KB 읽기	~150 μs	메모리의 1500배
디스크 탐색	~10 ms (10,000,000 ns)	메모리의 10만 배

출처: Jeff Dean/Peter Norvig "Latency Numbers Every Programmer Should Know" — 규모의 직관용이지 정확값은 시스템마다 다름. 접근 2026-07-09.

의미: 컨텍스트 스위치 한 번 = 메모리 접근 수십 번 비용. 그래서 같은 주소 공간을 공유해 캐시를 유지하는 스레드가 프로세스 스위치보다 싸다. 디스크 I/O는 메모리의 10만 배 — 그래서 디스크 접근을 최소화하려고 페이지 캐시와 스와핑이 존재한다(04장).

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 실행 권장.

# Rocky 10
ps -ef --forest | head

확인할 것: PID 1이 systemd이고, 모든 프로세스가 systemd의 자손이라는 사실. fork의 연쇄가 보인다.

UID   PID  PPID  ... CMD
root    1     0  ... /usr/lib/systemd/systemd --system
root    2     0  ... [kthreadd]
...

ps -eo pid,ppid,stat,nice,comm --sort=-stat | head -15

확인할 것: STAT의 첫 글자(R/S/D/T/Z)가 상태, 두 번째 글자(s=세션 리더, +=포그라운드)는 부가 정보.

# Rocky 10
bash -c 'echo "내 PID: $$"; exec echo "exec 후 같은 PID: $$"'

확인할 것: 두 PID가 같다. "exec은 PID를 바꾸지 않는다"를 눈으로 확인.

# Rocky 10 (권장 순서)
kill 1234           # SIGTERM - 정리 기회 부여
# 30초 대기 후에도 살아있으면
kill -9 1234        # SIGKILL - 강제

# Rocky 10
nice -n 10 ./heavy_job &     # 낮은 우선순위로 백그라운드
sudo renice -n -5 -p 1234    # 실행 중인 프로세스 우선순위 높이기(root)

ps aux | awk '$8 ~ /^Z/'

좀비가 보이면 부모를 찾아라: ps -o ppid= -p <좀비PID>. 부모를 재시작하거나 죽여야 회수된다.

uname -r   # 6.6+ = EEVDF, 4.x = CFS

Rocky 10(6.12)은 EEVDF. 구형 자료의 "CFS" 설명은 역사적 배경으로 읽어라.

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"nice가 높으면 더 우선이다"	반대. 낮을수록(-20 방향) 우선
"프로세스가 안 죽으면 kill -9부터"	위험. SIGTERM(15) 먼저, 정리 기회 줄 것
"좀비는 위험한 괴물"	보통 아님. 메모리 거의 안 씀. PID 소모가 유일한 문제
"좀비를 kill -9로 없앤다"	불가능. 부모를 wait하게 하거나 부모를 죽여야
"D 상태는 kill -9로 해결"	안 됨. 디스크/NFS 문제 해결이 근본
"bash가 ls를 직접 부른다"	아니다. bash가 fork하고 그 자식이 exec으로 ls가 됨
"스레드는 프로세스보다 무조건 좋다"	상황에 따라. 격리·안전이 필요하면 프로세스가 나음
"모든 CPU 코어를 100% 쓰면 빠르다"	컨텍스트 스위치 비용이 크면 병렬이 역효과
"Rocky 10도 CFS를 쓴다"	아니다. EEVDF(kernel 6.6+). CFS는 구버전(4.x) 이야기

요약 — 이 글의 결론

프로세스 = 실행 중인 프로그램 + 독립된 메모리 공간. 스레드 = 같은 주소 공간을 공유하는 실행 흐름. 커널은 둘 다 task_struct로 본다.
새 프로그램 실행 = fork(복제) + exec(교체, PID 유지) + exit + wait. 이 분리 덕에 리다이렉션·파이프가 가능하다.
상태 5종: R/S/D/T/Z. D(디스크 대기)와 Z(회수 안 된 종료자)는 시그널로 직접 해결 불가 — 근본 원인을 봐야 한다.
시그널: SIGKILL(9), SIGSTOP(19)만 무시 불가. 나머지는 처리 가능. "응답 없다"고 해서 바로 -9 금지, TERM 먼저.
nice: -20~19, 낮을수록 우선. 일반 사용자는 높이기만(양보만) 가능.
스케줄러: Rocky 10은 EEVDF — 공평함은 유지하되 짧게 끝나는 일(대화형)을 우선. CFS(vruntime 공평)는 구버전 이야기이자 EEVDF가 계승한 전신.

생각해 볼 문제

bash가 ls를 실행할 때 일어나는 일을 fork/exec/exit/wait로 설명하라.
PID 100의 프로세스가 exec()하면 PID는 어떻게 되는가? 왜?
SIGTERM과 SIGKILL의 차이, 그리고 "왜 TERM을 먼저 써야 하는가"를 설명하라.
nice 값 -20, 0, +19 중 가장 우선인 것은? 왜 반대인가?
좀비 프로세스를 직접 kill할 수 있는가? 없다면 어떻게 해결하는가?
D 상태 프로세스에 SIGKILL을 보내면 어떻게 되는가?
CFS가 "공평"을 달성한 방식(vruntime)과 EEVDF가 거기에 더한 것을 비교하라.

참고

EEVDF Scheduler — Linux Kernel docs - 접근 2026-07-09
An EEVDF CPU scheduler for Linux — LWN - 접근 2026-07-09 (CFS→EEVDF 전환 배경)
CFS Documentation — Linux Kernel docs - 접근 2026-07-09 (역사적 전신)
Latency Numbers — Google SRE - 접근 2026-07-09
man page: man ps, man kill, man signal(7), man nice, man fork(2), man execve(2)

Linux - 02. boot systemd

dongka — Thu, 9 Jul 2026 14:08:52 +0900

전원 ON부터 로그인까지 30초 — 그 사이에 무슨 일이 일어나는가

서버 전원을 켰다. 30초~1분 뒤 SSH 로그인 프롬프트가 뜬다. 그 사이 30초 동안 무슨 일이 벌어지는가? 대부분 "부팅되겠지" 하고 넘긴다. 하지만 서비스가 부팅 후 자동으로 안 올라오거나, 부팅이 응급 모드(emergency)에 빠져 멈추거나, 부팅이 너무 느릴 때 — 이 연쇄를 모르면 어디서 막혔는지조차 진단할 수 없다.

이 글은 전원 ON부터 로그인 프롬프트까지의 연쇄를 따라간다. 핵심 인물은 systemd, PID 1 — 모든 서비스의 출발점이다.

부팅은 여섯 단계 연쇄다

flowchart LR
    P1["1. 펌웨어<br/>BIOS/UEFI + POST"] --> P2["2. 부트로더<br/>GRUB2 2.12"]
    P2 --> P3["3. 커널 로드<br/>vmlinuz + initramfs"]
    P3 --> P4["4. systemd<br/>PID 1"]
    P4 --> P5["5. target 도달<br/>default.target"]
    P5 --> P6["6. 로그인 프롬프트<br/>getty / 디스플레이 매니저"]

비유하자면 아침에 건물을 여는 절차와 비슷하다 — 경비원 출근(펌웨어) → 안내데스크가 관리실 열쇠 전달(GRUB2) → 임시 관리실 개방(initramfs) → 건물 관리자 출근(systemd) → 층별 전원 병렬 점등(target) → 로비 개방(로그인). 단, 건물은 순차적이지만 systemd는 병렬로 서비스를 올린다(의존성만 충족하면 동시).

각 단계를 좇아보자.

1. 펌웨어(BIOS/UEFI)

POST(Power-On Self-Test) 로 하드웨어를 점검한다(CPU·RAM·저장소가 살아있나). 그리고 부트 디바이스를 찾아 부트로더를 메모리에 올린다. UEFI 시스템이면 ESP(EFI System Partition)의 grubx64.efi를 실행한다.

2. GRUB2(부트로더)

Rocky 10은 GRUB2 2.12. 디스크에서 커널 이미지(vmlinuz-<버전>)와 initramfs를 메모리에 적재하고, 커널 명령줄 매개변수(root=, crashkernel=, rd.lvm.lv= 등)를 전달한다.

부트 엔트리는 과거의 거대한 grub.cfg 스크립트가 아니라 BLS(Boot Loader Specification) 방식 — 커널마다 독립된 .conf 스니펫으로 모듈화되어 있다:

title Rocky Linux (6.12.0-xxx.el10.x86_64)
version 6.12.0-xxx.el10.x86_64
linux /vmlinuz-6.12.0-xxx.el10.x86_64
initrd /initramfs-6.12.0-xxx.el10.x86_64.img
options root=/dev/mapper/rl-root ro crashkernel=2G-64G:256M rd.lvm.lv=rl/root

BLS가 왜 생겼나: 구 GRUB은 /boot/grub2/grub.cfg 하나에 모든 엔트리가 스크립트로 들어가 커널 업데이트마다 재생성이 필요했고 오류가 잦았다. BLS는 커널별 독립 스니펫으로 모듈화해 이 문제를 풀었다. grubby가 관리한다.

3. 커널 + initramfs

커널이 메모리에서 initramfs(압축 CPIO 아카이브)를 tmpfs로 풀어 임시 루트를 만들고, 제어를 systemd로 넘긴다. 왜 굳이 임시 루트를 거치는지는 바로 다음 절에서.

4-6. systemd(PID 1) → target → 로그인

커널이 시작하는 첫 사용자 공간 프로세스가 systemd다. systemd가 target(동기화 체크포인트)을 차례로 도달하며 서비스를 올리고, 마침내 로그인 서비스(getty/sshd/GDM)가 뜬다.

flowchart TD
    SYS["systemd 시작"] --> SYSINIT["sysinit.target<br/>(체크포인트)"]
    SYSINIT --> BASIC["basic.target<br/>(체크포인트)"]
    BASIC --> DEFAULT["default.target<br/>(multi-user 또는 graphical)"]
    DEFAULT --> LOGIN["로그인 서비스<br/>getty/sshd/GDM"]

sysinit.target, basic.target은 체크포인트다. 여기서 실패하면 emergency.target(응급 모드)로 빠진다.

커널은 왜 곧바로 루트를 마운트하지 못할까 — initramfs의 이유

여기서 의문이 든다: 커널이 임시 루트(initramfs)를 거치지 않고 곧바로 진짜 루트(/)를 마운트하면 안 되나? 귀찮게 왜 임시 루트를 거치는가?

핵심 사실: 커널은 만능이 아니다. 루트 파티션이 LVM이면, RAID면, 디스크 암호화면, NVMe/iSCSI 특수 드라이버가 필요하면 — 커널이 혼자서 마운트할 수 없다. 필요한 드라이버와 도구가 있어야 한다. 그 도구를 담은 임시 환경이 initramfs다.

흐름:

커널이 initramfs를 tmpfs로 풀어 임시 루트 구성.
initramfs가 LVM/RAID/암호화/특수 드라이버 초기화.
진짜 루트 장치가 준비되면 /sysroot에 마운트 → switch_root로 전환.
제어를 systemd로 넘김.

구 용어 initrd와 initramfs가 혼용되지만 기술적 구분이 있다: initrd = 블록 장치 기반 ramdisk(구식), initramfs = tmpfs 기반 CPIO(현대). 현대 리눅스는 모두 initramfs. LVM/RAID/암호화 루트면 initramfs 없이는 부팅 자체가 불가능하다.

systemd가 모든 것을 총괄한다 — PID 1

systemd는 RHEL/Rocky 7부터 기본 init 시스템이며, PID 1으로 모든 서비스를 관리한다. 핵심 설계 네 가지:

병렬 서비스 시작 — 의존성만 충족하면 동시에 올린다 → 부팅 속도 향상.
cgroup 기반 자원 관리 — 서비스별 CPU/메모리를 통제. Rocky 10은 cgroup v2 강제.
socket/D-bus activation — 요청이 올 때까지 서비스를 안 띄운다 → 메모리 절약. 첫 연결이 오면 그제야 서비스를 시작하고, 서비스가 죽어도 소켓이 요청을 큐에 담아둬 재시작 시 이어받는다.
통합 로그(journald) — 커널·서비스·syslog 로그를 구조화해 한곳에 수집.

Rocky 10(systemd 257)의 변화: cgroup v1을 폐기하고 항상 v2를 쓴다. System V(init.d) 서비스 스크립트는 deprecated(향후 제거 → 네이티브 unit 파일 권장). 기본 설정 파일 위치가 /etc/systemd/에서 /usr/lib/systemd/로 이동했다(/etc/나 드롭인으로 오버라이드).

cgroup v2 강제의 함정: 구 모니터링 도구·컨테이너 런타임이 cgroup v1 경로(/sys/fs/cgroup/memory/...)를 쓰면 동작하지 않는다. v2 통일 경로(/sys/fs/cgroup/)를 써야 한다.

unit과 target — systemd가 세상을 보는 단위

systemd가 관리하는 모든 것은 unit이다. 접미사로 종류가 갈린다.

unit 종류	접미사	용도
service	`.service`	데몬/서비스 (예: `sshd.service`)
target	`.target`	동기화 지점/상태 (예: `multi-user.target`)
socket	`.socket`	소켓 activation
timer	`.timer`	cron 대체 스케줄러
mount	`.mount`	파일시스템 마운트
device	`.device`	커널 장치
slice	`.slice`	cgroup 계층 그룹

unit 파일 우선순위(높은 순): /etc/systemd/system/(관리자 수정, 최우선) > /run/systemd/system/(런타임) > /usr/lib/systemd/system/(패키지 기본, Rocky 10부터 여기가 기본).

target — runlevel의 현대적 대체

과거 runlevel은 숫자였다(0~6). systemd는 이름 있는 target으로 대체했다.

target	구 runlevel	의미
`poweroff.target`	0	종료
`rescue.target`	1, s, single	단일 사용자(구조)
`multi-user.target`	3	텍스트 다중 사용자(서버 표준)
`graphical.target`	5	GUI 다중 사용자
`reboot.target`	6	재부팅
`emergency.target`	—	최소 응급(루트만, 거의 아무것도 마운트 안 함)

service unit 파일 구조

# /usr/lib/systemd/system/sshd.service (예시 형태)
[Unit]
Description=OpenSSH server daemon
After=network.target auditd.service       # 의존 순서

[Service]
Type=notify                                # 시작 완료 신호 방식
ExecStart=/usr/sbin/sshd -D $OPTIONS       # 시작 명령
ExecReload=/bin/kill -HUP $MAINPID         # 재로드 명령
Restart=on-failure

[Install]
WantedBy=multi-user.target                 # enable 시 어느 target에 걸지

Type이 서비스 시작을 어떻게 판정하느냐를 결정한다: simple(기본, 즉시 시작으로 간주), forking(fork 후 부모가 종료되면 시작 완료), notify(sd_notify로 준비 신호 받아야 시작 완료), oneshot(일회성).

부팅 시간은 어디서 걸리나 — systemd-analyze

systemd-analyze는 부팅 시간을 세 단계로 쪼개 보여준다.

단계	대략 시간	의미
kernel	1-5초	커널 자체 초기화
initrd	2-10초	initramfs에서 루트 마운트(LVM/암호화면 더 김)
userspace	5-30초	systemd가 서비스 올리는 시간

Startup finished in 3.1s (kernel) + 5.5s (initrd) + 12.8s (userspace) = 21.4s
graphical.target reached after 12.5s in userspace

userspace가 길면 systemd-analyze blame으로 어떤 서비스가 느린지 찾아라. 보통 NetworkManager(네트워크 대기)나 초기화가 무거운 DB가 병목이다. 부팅 최적화의 첫 단추는 "어디서 걸리나"를 아는 것이다.

Rocky 10에서 직접 확인하기

미검증(출처 인용). Rocky 10 VM에서 직접 실행 권장.

# Rocky 10 — UEFI인가 BIOS인가
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS/Legacy"

# Rocky 10 — 어느 커널로 부팅하나 (BLS 엔트리)
ls /boot/loader/entries/
cat /boot/loader/entries/$(ls /boot/loader/entries/ | head -1)

systemctl --version

확인할 것: Rocky 10은 systemd 257.

systemd 257 (257.x)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP ...

# Rocky 10 — 서비스 운영
systemctl status sshd              # 현재 상태
sudo systemctl start sshd          # 즉시 시작
sudo systemctl enable sshd         # 부팅 시 자동 시작 등록
systemctl is-enabled sshd          # 자동 시작 여부

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
     Active: active (running) since ...
   Main PID: 1234 (sshd)

# Rocky 10 — target 관리
systemctl get-default              # 현재 기본 target (보통 multi-user.target)
sudo systemctl set-default graphical.target   # 기본 변경
sudo systemctl isolate rescue.target          # 즉시 전환(로그아웃 발생)

# Rocky 10 — 부팅 로그 분석 (어디서 느리거나 막혔나)
journalctl -b                      # 현재 부팅 전체 로그
systemd-analyze                    # 부팅 시간 요약
systemd-analyze blame | head       # 서비스별 시작 시간(느린 순)
systemd-analyze critical-chain     # 병목 서비스
journalctl -u sshd                 # 특정 서비스 로그
journalctl -p err -b               # 이번 부팅 에러만

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"`enable`하면 지금 시작된다"	아니다. enable은 부팅 시 자동 시작 등록만. 즉시 시작은 `start`
"`start`하면 부팅 후에도 자동이다"	아니다. start는 즉시 시작만. 재부팅 후엔 자동 아님
"unit 파일을 고치면 바로 적용된다"	아니다. `systemctl daemon-reload`로 systemd가 다시 읽게 해야
"구 `/etc/sysconfig/network-scripts/`를 써야 한다"	Rocky 10은 NetworkManager(nmcli) 중심
"`service sshd restart`는 안 된다"	된다(호환 래퍼). 단 System V 스크립트 자체는 deprecated
"모든 서비스가 순차 시작한다"	아니다. systemd는 병렬 시작(의존성만 충족하면 동시)
"initramfs는 안 쓰는 게 빠르다"	LVM/RAID/암호화 루트면 initramfs 없이 부팅 불가
"Rocky 10도 cgroup v1을 쓴다"	아니다. systemd 257이 cgroup v2 강제. v1 경로는 동작 안 함

요약 — 이 글의 결론

부팅 6단계: 펌웨어(POST) → GRUB2 → 커널+initramfs → systemd(PID 1) → target → 로그인.
initramfs = 임시 루트. 커널이 혼자 마운트 못 하는 루트(LVM/RAID/암호화) 환경을 제공. 없으면 부팅 불가.
systemd = PID 1. 병렬 시작 + cgroup 자원 관리 + socket activation + journald 통합 로그.
unit/target: systemd의 관리 단위(unit)와 동기화 지점(target=runlevel 대체, multi-user=3, graphical=5).
enable vs start: enable=부팅 자동 등록, start=즉시 시작. 보통 둘 다 필요. unit 수정 후엔 반드시 daemon-reload.
Rocky 10 특이: systemd 257, cgroup v2 강제(v1 폐기), System V deprecated, BLS 부트 엔트리, 설정 기본 위치 /usr/lib/systemd/.
부팅 병목은 systemd-analyze blame으로 잡는다 — userspace가 길면 서비스 탓.

생각해 볼 문제

전원 ON부터 systemd가 시작되기까지의 단계를 순서대로 말하라.
왜 커널이 곧바로 루트 파티션을 마운트하지 않고 initramfs를 거치는가?
systemd의 PID는 왜 1인가? (03장의 fork 연쇄와 연결해 생각해 보라)
enable과 start의 차이. 두 단계 모두 필요한 이유는?
unit 파일을 수정한 뒤 반드시 해야 하는 명령은? 안 하면 어떻게 되는가?
부팅이 느릴 때 어느 명령으로 병목 서비스를 찾는가?

참고

Rocky Linux 10 Admin Guide - System Startup - 접근 2026-07-09 (부팅 흐름 1차)
RHEL 10 Release Notes - systemd 257 - 접근 2026-07-09
RHEL 10 - Configuring kernel command-line parameters - 접근 2026-07-09 (grubby/BLS)
man page: man systemctl, man systemd.unit, man systemd.target, man journalctl, man bootup(7)

Linux - 01. overview

dongka — Wed, 8 Jul 2026 16:57:12 +0900

"리눅스"라 부르는 것의 반은 리눅스가 아니다

RHEL(Red Hat Enterprise Linux)은 연 수백만 원짜리 유료 구독이다. 그런데 Rocky Linux는 RHEL과 거의 똑같이 생겼으면서 무료다. 같은 소스에서 나왔는데 한쪽만 돈을 받는다. 처음 보면 모순처럼 보인다.

이 모순은 "리눅스"라는 단어가 숨기고 있는 것을 한 겹 벗기면 사라진다. 이 글은 그 한 겹을 다룬다 — 정확히 "리눅스"가 가리키는 것이 무엇인지, 그리고 왜 같은 코드에서 유료와 무료가 동시에 나올 수 있는지.

"리눅스"는 사실 커널이다

정확히 말해 "리눅스(Linux)"는 커널 그 자체를 가리킨다. 우리가 "리눅스 OS"라 부르는 것은 사실 커널 하나가 아니라, 커널 + 사용자 공간 도구 + 패키지 관리자를 한 묶음으로 포장한 배포판(distribution)이다.

리눅스 커널 단독으로는 부팅조차 안 된다. 셸도, 명령어도, 라이브러리도 없기 때문이다. 그래서 커널만으로는 쓸 수 없고, GNU 도구(bash, coreutils, gcc)와 결합해야 비로소 운영체제가 된다. FSF가 "GNU/Linux"라 부르자고 고집하는 이유가 여기에 있다.

	커널	배포판
비유	자동차의 엔진	완성된 자동차 모델(세단, SUV, 트럭)
단독으로	의미 없음 — 엔진만으론 못 굴러	바로 운전 가능
같은 것으로 다양화	같은 엔진 → 여러 차종	같은 커널 → Rocky, Ubuntu, RHEL…

이 비유는 "핵심 부품 vs 완성품" 관계만 잡는다. 자동차는 물리적 1대라 복제 불가지만 배포판은 무한 복제되고, 자동차 엔진 교체는 매우 어렵지만 커널은 비교적 독립적으로 교체·업그레이드된다. 정확한 구조는 아래에서.

이 구분을 못 하면 뒷글의 어휘가 전부 흔들린다. "리눅스에서 dnf가 안 돼요"라는 말은 정확히는 "RHEL 계열 배포판에서"라는 뜻이지, 커널 수준의 이야기가 아니다.

커널 하나인데 왜 배포판은 수백 개일까

"리눅스" 커널은 사실상 하나다. 그런데 Rocky, Ubuntu, Debian, Arch… 배포판은 수백 개다. 같은 엔진으로 만든 여러 자동차 모델이라 생각하면 된다.

많은 사람이 "배포판 = 패키지 관리자"로 요약하지만, 그건 표면이다. 진짜 차이는 세 가지에서 온다: 패키지 관리 방식, 릴리스 철학, 누구를 위한 배포판인가.

flowchart TD
    ROOT[독립 루트] --> RH[Red Hat 계열<br/>RPM / dnf]
    ROOT --> DEB[Debian 계열<br/>.deb / apt]
    ROOT --> ARCH[Arch 계열<br/>pacman, 롤링]
    ROOT --> SUSE[SUSE 계열<br/>RPM / zypper]

    RH --> FED[Fedora — 상류, 최신]
    FED --> RHEL[RHEL — 상용, 장기지원]
    RHEL --> CST[CentOS Stream — 개발 브랜치]
    RHEL --> RL[Rocky Linux]
    RHEL --> AL[AlmaLinux]

    DEB --> DEB1[Debian — 안정 중심]
    DEB1 --> UB[Ubuntu]

가문	패키지 관리자	패키지 형식	대표
Red Hat	`dnf`	`.rpm`	RHEL, Rocky, Alma, Fedora
Debian	`apt`/`dpkg`	`.deb`	Debian, Ubuntu, Mint
Arch	`pacman`	—	Arch, Manjaro
SUSE	`zypper`	`.rpm`	openSUSE, SLES

패키지 관리자는 표면이다 — 릴리스 철학이 진짜 갈린다

같은 RPM을 써도 Fedora와 RHEL은 완전히 다른 동물이다. 차이는 얼마나 자주, 얼마나 오래 갱신하느냐에 있다.

전략	갱신 속도	지원 기간	무엇을 포기하는가
롤링(Arch, Tumbleweed)	계속 최신	없음(계속 굴리면 영원)	안정성. 한 번 업데이트가 시스템을 깰 수 있음
포인트 릴리스(Debian, Ubuntu)	6개월~2년 주기	LTS 5년	최신 기능. 검증된 버전에 머무름
엔터프라이즈(RHEL, Rocky)	보수적, 큰 점프만	10년	최신성. 안정·패치 SLA가 우선

여기서 "안정"이란 "안 죽는다"가 아니라 "API가 안 바뀐다"다. RHEL/Rocky는 10년 동안 같은 커널·라이브러리 주버전을 유지하며, 보안 패치만 역이식(backport)해 넣는다. 그래서 5년 전에 짠 서비스가 업그레이드 없이 계속 돈다. 대가는 — 커널은 6.12 쓰면서도 사용자 공간 도구는 구버전에 머무를 수 있다는 모순(이건 Rocky 10의 함정이기도 하다, 08장).

상류에서 하류로 — 코드는 어디서 흐르는가

Red Hat 계열은 단방향 파이프라인이다. 위쪽에서 실험하고, 아래로 갈수록 굳어진다.

flowchart LR
    UP["상류(upstream)<br/>커널·프로젝트 원본"] --> FED["Fedora<br/>실험장, 최신"]
    FED --> CST["CentOS Stream<br/>RHEL의 다음 버전 양산"]
    CST --> RHEL["RHEL<br/>안정화, 상용"]
    RHEL --> RL["Rocky / Alma<br/>RHEL 재구축(무료)"]

Fedora가 새 기능을 시험한다(커널·systemd·GNOME 최신).
CentOS Stream이 RHEL의 다음 마일스톤을 굴리며(RHEL의 상류 겸 개발 브랜치).
RHEL이 그 중 검증된 것을 10년 지원 상용으로 얼린다.
Rocky/Alma가 그 얼려진 RHEL을 소스에서 그대로 다시 묶는다.

→ 같은 코드가 흐르되, 어느 단계에서 끊어 가져오느냐가 배포판의 정체성이다. 이 흐름을 모르면 "Rocky가 RHEL보다 빠르냐 느리냐" 같은 질문에 헷갈린다(답: 같다. 같은 RHEL 소스에서 나왔으니).

왜 이 저장소는 Rocky 10인가

학습엔 안정성도 필요하지만, 너무 구버전이면 안 된다. Ubuntu LTS는 편하지만 커널·도구가 RHEL 계열과 달라 실무(특히 국내 서버 시장의 RHEL 환경)와 괴리된다. 반대로 Arch는 너무 날카롭다. Rocky는 RHEL과 바이너리 호환이면서 무료 — 엔터프라이즈 급 안정성을 공짜로 쓸 수 있는 유일한 선택지다. 그래서 이 저장소 전체의 실습 기준이다.

왜 RHEL은 유료이고 Rocky는 무료인가 — GPL의 역설 풀기

이제 처음의 모순으로 돌아가자. 답은 리눅스 커널의 라이선스인 GPL에 있다.

핵심 오해 하나: "리눅스는 무료"라고들 한다. 틀렸다. 리눅스는 무료(free of charge)가 아니라 자유(freedom)다. GPL은 비용이 아니라 소스코드 공개 의무를 다룬다.

GPL은 판매를 금지하지 않는다. 팔아도 된다.
대신 수정·재배포할 때 소스코드를 공개해야 한다(copyleft).
그 공개된 소스로 누구나 똑같이 재구축할 수 있다.

RHEL은 GPL을 지키면서도 돈을 받는다. 돈을 받는 것은 코드가 아니라 지원·인증·안정성 보증·패치 SLA 때문이다. 그리고 RHEL이 공개한 GPL 소스를 그대로 받아 RHEL과 바이너리 호환되게 다시 묶은 무료 배포판이 Rocky Linux, AlmaLinux다.

모순이 아니라 GPL이 설계한 대로 작동하는 것이다. "자유"는 "공짜"를 뜻하지 않는다.

항목	내용
현재 커널 라이선스	GPL-2.0-only
핵심	copyleft — 2차 저작물도 동일 라이선스로 공개 의무
허용	자유 복제·수정·재배포·상업 이용(판매 가능)
의무	수정·재배포 시 소스코드 공개

copyleft가 실제로 강제하는 것과 아닌 것

"copyleft가 전염된다(viral)"는 표현이 자주 나오지만, 오해를 낳는다. GPL이 강제하는 것은 정확히 "배포(distribution)할 때"뿐이다.

강제한다: GPL 코드를 가져다 수정한 뒤 남에게 배포하면, 그 수정본의 소스도 GPL로 공개.
강제하지 않는다: 회사 안에서만 쓰고 밖으로 내보내지 않으면? 공개 의무 없음. GPL 코드를 고쳐서 사내 서버에만 굴려도 소스를 공개할 필요가 없다.
강제하지 않는다: GPL 코드와 별도 프로세스로 통신(예: 명령행으로 GPL 도구를 호출)하는 자기 코드는 GPL에 물들지 않는다.

즉 GPL은 "전염"이 아니라 "배포 조건"이다. 이 선을 알아야 "회사에서 GPL 쓰면 소스 다 공개해야 하나?" 같은 공포가 사라진다.

왜 커널은 영원히 GPL-2.0-only인가

게다가 Torvalds 본인이 "GPLv2로 충분하다"며 이전에 부정적이다. 그래서 커널은 GPLv2에 영원히 고정되고, 새 라이선스 논쟁이 나와도 "GPL-2.0-only" 표기는 변하지 않는다. 이것은 결함이 아니라, 커널이 거대한 협업 결과물이기에 치르는 비용이다.

syscall 예외 — 왜 독점 프로그램이 리눅스에서 돌아는가

GPL은 2차물에 같은 라이선스를 강제한다. 그렇다면 리눅스에서 돌아가는 모든 상용 프로그램(Oracle DB, 게임, 독점 드라이버)도 소스를 공개해야 하는 게 아닌가? 그렇지 않다. 커널은 syscall 경계를 예외로 둔다 — 시스템 콜로 커널을 이용하는 응용은 GPL 강제 대상이 아니다(커널 소스 COPYING 파일에 명시).

응용과 커널은 "한 프로그램"이 아니라 "정의된 인터페이스(syscall ABI)로 대화하는 별개의 프로그램"으로 본다. 응용은 GPL 영향을 받지 않고, 커널 자체만 GPL로 보호되는 구조다. 이 예외가 없었다면 상용 생태계가 리눅스를 외렸을 것이다. 리눅스 생태계가 폭발적으로 성장한 핵심 설계 결정 중 하나다.

30년이 한 줄로 — 잠깐의 역사

이 모든 것의 시작은 1991년이다. 핵심 날짜만 짚는다.

flowchart LR
    A["1983<br/>GNU 프로젝트<br/>Stallman"] --> B["1991-08-25<br/>Torvalds 발표<br/>comp.os.minix"]
    B --> C["1992<br/>GPLv2 도입"]
    C --> D["1994-03-14<br/>1.0 정식"]
    D --> F["현재<br/>GPL-2.0-only"]

1991-08-25: Linus Torvalds(21세, 헬싱키대)가 comp.os.minix에 "취미 프로젝트"라며 올린 글. 리눅스의 공식 생일이다.
1992: 처음엔 상업적 사용을 금지하는 자체 라이선스였다가 GPLv2로 바꿨다. Torvalds는 훗날 이를 "내 인생 최고의 결정"이라 불렀다. 이 결정이 없었다면 RHEL/Rocky 이야기도 없었다.
1994-03-14: 1.0 정식 릴리스(약 17만 줄). 오늘날 커널은 수천만 줄, 전 세계 수천 명이 하루에도 수백 커밋을 넣는다.

왜 1991년에 리눅스가 나왔는가. 당시 상용 유닉스(Sun Solaris, HP-UX, IBM AIX)는 하드웨어 회사마다 비싸게 팔아 학생이나 소규모 연구자는 엄두를 못 냈다. 마침 GNU 프로젝트(Stallman, 1983)가 셸·컴파일러·명령어는 다 만들어놓고 커널(Hurd)만 못 만들고 있었다. Torvalds가 만든 커널이 그 빈자리를 채웠다. "GNU 도구 + 리눅스 커널"이 자연스럽게 결합해 오늘날의 리눅스 OS가 됐다. 이 역사가 "왜 배포판이 커널+도구 묶음인가"의 답이다.

취미 프로젝트가 어떻게 상용 유닉스를 이겼는가

1991년 "취미 프로젝트"가 2020년대에 슈퍼컴퓨터 TOP500의 100%, 안드로이드폰 전체, 클라우드 인프라 대부분을 지배하게 된 과정은 한 사람의 천재로 설명되지 않는다. 핵심은 개발 모델에 있다.

리눅스 커널은 계층적 메인테이너(hierarchical maintainer) 구조로 굴러간다. Torvalds가 최종 병합권을 쥐고, 그 아래 서브시스템별 중간 메인테이너(lieutenant)들이 각 영역(파일시스템·네트워크·스케줄러 등)의 품질을 검수해 Torvalds에게 올린다. 한 명이 전부 읽는 게 아니라, 신뢰의 계단을 통해 수천 명의 기여를 걸러 올린다.

여기에 "충분한 눈이 있으면 모든 버그는 얕다"(Linus's law) — Eric Raymond가 명명한 통찰이 작동한다. 소스가 공개되어 누구나 볼 수 있으면, 버그가 전 세계 수만 명의 눈에 빠르게 노출되어 잡힌다. 닫힌 상용 유닉스가 수십 년 못 잡은 버그를 리눅스는 몇 주 만에 잡는 일이 흔해졌다.

이 두 개 — 계층적 검수 + 열린 시야 — 가 "혼자 만든 커널"을 "인류가 함께 만드는 인프라"로 바꿨다. 1.0(1994, 약 17만 줄)이 오늘날 커널 6.x(수천만 줄, 전 세계 수천 명 기여, 하루 수백 커밋)이 될 수 있었던 이유다. 단일 기업이 이 규모를 따라잡는 건 불가능해졌고, 그게 곧 상용 유닉스의 패배 본질이다.

CentOS는 어디로 갔나 — Rocky가 그 자리를 이었다

Rocky가 왜 존재하는지 이해하려면 CentOS 이야기를 짚고 넘어가야 한다. 과거 구 CentOS는 RHEL의 무료 바이너리 클론이었다. 2021년 Red Hat이 CentOS를 종료시키고 CentOS Stream(RHEL의 상류 개발 브랜치)으로 방향을 바꿨다. 그 빈자리 — "무료 RHEL 호환 배포판" — 를 메운 것이 Rocky Linux와 AlmaLinux다.

Fedora: Red Hat 후원 커뮤니티 상류. 최신 기능 선별. RHEL의 실험장(proving ground).
RHEL: Fedora에서 파생된 상용 엔터프라이즈 OS. 약 10년 장기 지원.
CentOS Stream: RHEL의 상류·개발 브랜치. (구 CentOS와 다르다.)
Rocky Linux: 2021년 Gregory Kurtzer(CentOS 공동 창립자)가 시작한 RHEL 바이너리 호환 무료 재구축. 이름은 고인이 된 공동 창립자 Rocky McGaugh에게서. 이 저장소의 실습 환경이다.

2023년, Red Hat이 소스를 막았다 — Rocky는 어떻게 살아남았나

여기까지 읽으면 한 가지 의문이 든다. "Rocky가 RHEL 소스를 그대로 받아 재구축한다고 했는데, Red Hat이 그 소스를 안 주면?" 그 일이 실제로 일어났다.

2023년 6월, Red Hat은 RHEL 소스 코드의 공개 재배포를 중단했다. 더 이상 누구나 ftp에서 SRPM(source RPM)을 받아갈 수 없게 했다. RHEL 소스는 (1) 유료 고객에게만 Red Hat Customer Portal로, (2) 일반에는 CentOS Stream 경로로만 제공한다고 발표했다.

표면적 이유는 "무료 재구축 배포판이 Red Hat의 상업 모델을 무임승차한다"는 불만이었다. 하지만 GPL의 관점에서 보면 미묘하다 — GPL은 소스 공개를 의무로 하지만, 누구에게나 공개하라고는 명시하지 않는다. "배포 대상(고객)에게는 소스를 줘야 한다"는 게 GPL의 요지다. Red Hat은 고객에게는 소스를 주되, 재배포를 사실상 막는(고객 계약상) 방식으로 copyleft의 글자를 지키면서 의도는 희석했다. 커뮤니티는 이를 "GPL 정신 위반"과 "GPL 글자 준수" 사이의 회색지대로 받아들였다.

Rocky와 AlmaLinux는 죽지 않았다. 그들은 방식을 바꿨다 — CentOS Stream의 소스(공개됨)를 뼈대로 삼고, Red Hat이 공개하는 패치와 공개 채널의 소스를 조합해 RHEL과 바이너리 호환을 유지한다. 완전히 동일한 경로는 아니지만, 실사용에 문제없는 호환성을 유지하고 있다(2026년 현재 Rocky 10이 정상 출시된 것이 증거).

이 사건이 시사하는 것: "무료" RHEL 재구축은 Red Hat의 자비가 아니라 GPL이라는 계약 위에 서 있다. 계약의 글자를 지키면서 의도를 비틀 수는 있어도, 완전히 없앨 수는 없다. 리눅스 생태계의 자유는 도덕이 아니라 라이선스라는 법적 구조로 보장된다.

Rocky 10에서 직접 확인하기

# Rocky 10
cat /etc/redhat-release

확인할 것: "Red Quartz"라는 코드명과 버전 10.x. Rocky가 Red Hat 계열임을 시스템이 스스로 선언한다.

Rocky Linux release 10.x (Red Quartz)

uname -r

확인할 것: 6.12.x. 이 커널 버전으로 EEVDF 스케줄러 사용 여부를 판별한다(03장).

6.12.0-xxx.el10.x86_64

cat /etc/os-release

확인할 것: ID_LIKE="rhel centos fedora" 줄. Rocky가 RHEL 계열임을 스스로 선언하며, 패키지 호환성 판단에 쓰인다.

NAME="Rocky Linux"
VERSION="10.x (Red Quartz)"
ID="rocky"
ID_LIKE="rhel centos fedora"

흔히 묻는 것, 흔히 틀리는 것

오해	정정
"리눅스 = 운영체제"	리눅스는 커널이다. OS가 되려면 배포판(커널+GNU 도구+패키지관리자)이 필요
"리눅스는 무료니까 RHEL이 유료인 건 모순"	GPL은 자유(freedom)지 무료(free)가 아님. RHEL은 GPL 소스를 공개하면서 유료 판매 정상
"CentOS = Rocky"	구 CentOS는 종료. CentOS Stream은 RHEL 상류(개발). Rocky/Alma가 구 CentOS 자리 계승
"GPL은 무조건 무료 배포 강제"	아니다. 팔아도 됨. 단 소스 공개 의무
"GPL 코드를 쓰면 내 코드도 무조건 공개해야"	배포할 때만. 사내에서만 쓰고 밖으로 안 내보내면 공개 의무 없음
"GPL은 전염성(viral)이다"	"전염"이 아니라 "배포 조건". syscall 경계 밖 응용은 GPL에 물들지 않음
"배포판이 다르면 완전히 다른 OS"	아니다. 커널은 같고 패키지 관리자·철학만 다름. 개념은 공통
"Rocky가 RHEL을 복사한 불법"	아니다. GPL이 허용하는 정상적 재구축. 2023년 소스 제한 이후엔 경로만 바뀜

요약 — 이 글의 결론

"리눅스"는 커널이다. 단독 부팅 불가. 우리가 쓰는 건 커널+GNU 도구+패키지관리자 묶음인 배포판.
배포판은 커널 하나로 수백 개. 진짜 차이는 패키지 관리자가 아니라 릴리스 철학(롤링 vs 포인트 vs 엔터프라이즈)과 상류-하류 코드 흐름. Rocky 10은 Red Hat 계열(RPM/dnf, 10년 지원).
GPL은 자유지 무료가 아니다. 판매 가능, 단 소스 공개 의무(배포 시만). 이게 RHEL(유료)과 Rocky(무료)가 같은 소스에서 공존하는 이유.
커널은 GPL-2.0에 영원히 고정 — 수만 기여자 동의 없이 GPLv3로 못 옮김. 그래서 "GPL-2.0-only".
syscall 예외 덕에 독점 응용도 리눅스에서 동작 — 커널만 GPL 보호, 응용은 자유. 생태계 폭발의 핵심 설계.
Rocky는 구 CentOS의 빈자리를 메운 RHEL 바이너리 호환 무료 재구축. 2023년 Red Hat의 소스 공개 제한에도 CentOS Stream 경로로 살아남았다 — 리눅스의 자유는 도덕이 아니라 GPL이라는 계약 위에 있다.
리눅스가 이긴 이유는 천재 한 명이 아니라 계층적 메인테이너 구조 + "충분한 눈"의 개방 모델이 만들어낸 협업 규모.

생각해 볼 문제

누군가 "리눅스는 공짜 운영체제"라고 말한다. 한 문장으로 정정하면?
같은 RHEL 소스에서 RHEL(유료)과 Rocky(무료)가 나온다. RHEL 구독자가 돈을 내는 것은 정확히 무엇일까?
syscall 예외가 없었다면 리눅스 생태계에 구체적으로 어떤 일이 벌어졌을까?
회사에서 GPL 라이브러리를 고쳐 쓰려 한다. "소스 공개 안 하려면?" 조건을 세 가지 말하라.
배포판이 100개인데 "리눅스를 배운다"는 말은 무엇을 배운다는 뜻일까 — 커널을, 배포판을, 둘 다를?
Red Hat이 2023년 RHEL 소스 공개를 막았는데 Rocky가 살아남은 것은, GPL이 결국 "글자"를 지킨 것인가 "정신"을 지킨 것인가?

참고

History of Linux - Wikipedia - 접근 2026-07-09 (역사/날짜 교차검증)
Linux kernel version history - Wikipedia - 접근 2026-07-09
Comparison of Linux distributions - Wikipedia - 접근 2026-07-09
Rocky Linux Release Notes - 접근 2026-07-09 (Rocky 10 사양)
커널 라이선스·syscall 예외: 커널 소스 COPYING 파일, 또는 man 7 copyright
copyleft·GPL 해석: GPLv2 원문(gnu.org), FSF FAQ - 접근 2026-07-09
2023 RHEL 소스 정책 변경: Red Hat 공식 발표(2023-06-21, "Furthering the evolution of CentOS Stream"), Rocky Linux/AlmaLinux 공식 응답문 - 접근 2026-07-09
Linus's law·개발 모델: Eric S. Raymond, The Cathedral and the Bazaar(1997)

Technical Architect

Java - 02. types

==가 true이기도 하고 false이기도 한 이유 — Java 타입 시스템의 두 세계

두 가지 저장 방식 — "값"과 "주소"

primitive — 현금처럼 값 자체를 저장하는 8가지

정수에 끝이 있다 — 오버플로우

0.1 + 0.2는 0.3이 아니다

reference — 카드처럼 주소를 저장하는 세계

==가 다시 문제된다

미스터리 해결 — Integer 캐싱

실전에서 왜 문제인가

실전 시나리오 — ID 비교 버그

오토박싱의 숨은 비용

형변환 — 큰 그릇에서 작은 그릇으로

참조 타입의 캐스트 — 안전하게

var — 타입을 생략하면 컴파일러가 추론한다

초기화되지 않은 변수 — Java의 안전망

요약 — 이 글의 결론

생각해 볼 문제

참고

Java - 01. intro

java Hello.java가 숨기고 있는 것 — JVM, 바이트코드, 그리고 "한 번 쓰면 어디서나"의 진짜 의미

JDK, JRE, JVM — 세 개를 구분해야 하는 이유

각각이 무엇인가

컴파일 — .java에서 .class로

--release 플래그 — 컴파일 타임과 런타임 버전 불일치 함정

바이트코드가 존재하는 이유 — 플랫폼 독립성

JVM이 바이트코드를 실행하는 방식 — 인터프리터와 JIT의 이중 구조

C1과 C2 — 두 단계 JIT 컴파일러

GC — JVM이 메모리를 회수하는 방식

OpenJDK vs Oracle JDK — 어떤 것을 쓸 것인가

Java 25 LTS — 왜 LTS인가, 무엇이 달라졌나

실습 — Java 25에서 프로그램 실행하기

방식 1 — 단일 파일 직접 실행 (Java 11+, JEP-330)

방식 2 — 전통적 컴파일 + 실행

방식 3 — JShell (Java 9+ REPL)

왜 이 구조인가 — Java 설계의 트레이드오프

요약 — 이 글의 결론

생각해 볼 문제

참고

Kafka - 13. mirror maker 2

MirrorMaker 2 — 클러스터 경계를 넘는 복제, 그리고 offset 동기화의 함정

MM2란 — Connect 위에 구축된 크로스 클러스터 복제 프레임워크

복제 흐름(replication flow) — 방향성이 있는 데이터 이동

복제된 토픽의 이름 규칙 — DefaultReplicationPolicy

MM2 구성 — 설정 파일 한 개로 모든 것을

전체 구성 예시 — Active/Passive

설정 문법의 계층 구조

실행

멀티 리전 offset 동기화 — 이 글의 핵심

offset이 왜 다른가 — 복제 과정에서 발생하는 offset 불일치

MM2의 offset 동기화 메커니즘

offset 동기화의 치명적인 전제 조건

offset lag 허용 임계값 — offset.lag.max

Active/Active 구성 — 멀티 리전 양방향 복제

Active/Active의 consumer 관점

프로덕션 운영 고려사항

consume from remote, produce to local

tasks.max 설정

내부 topic 관리

설정 일관성 — 치명적인 함정

exactly-once 지원 (Kafka 3.5+)

모니터링 — replication-latency가 핵심 메트릭

console-consumer 테스트 시 주의

DR 장애 전환(failover) 실제 시나리오

MM2 vs 클러스터 내 복제 — 혼동하면 안 되는 것

요약 — 이 글의 결론

생각해 볼 문제

참고

Kafka - 12. operations

운영과 보안 — 클러스터 건강 유지와 "누가 뭘 할 수 있는가" 통제

운영의 두 축

클러스터 건강 — KRaft와 복제 감시

보안 3계층 — 암호화·인증·인가를 분리하는 이유

SASL 메커니즘 — PLAIN은 평문이다

보안 프로토콜 조합

SASL_SSL/SCRAM 적용 방법 — 단계별 가이드

1단계: SCRAM 자격증명 생성 (broker에 사용자 추가)

2단계: broker 설정 (server.properties)

3단계: SSL 인증서 준비 (keytool)

`==`가 `true`이기도 하고 `false`이기도 한 이유 — Java 타입 시스템의 두 세계

`0.1 + 0.2`는 `0.3`이 아니다

`==`가 다시 문제된다

`var` — 타입을 생략하면 컴파일러가 추론한다

`java Hello.java`가 숨기고 있는 것 — JVM, 바이트코드, 그리고 "한 번 쓰면 어디서나"의 진짜 의미

컴파일 — `.java`에서 `.class`로

`--release` 플래그 — 컴파일 타임과 런타임 버전 불일치 함정

offset lag 허용 임계값 — `offset.lag.max`