개발 노트

Java 23

창욱씨 — Wed, 6 May 2026 18:34:48 +0900

1. Markdown Documentation Comments (JEP 467) - 정식 출시

Javadoc 주석을 HTML 태그 없이 Markdown 문법으로 작성할 수 있습니다. /// 으로 시작하는 새로운 주석 스타일을 사용합니다.

// ❌ 기존 HTML 방식
/**
 * <h2>두 수를 더합니다.</h2>
 * <p>두 정수를 받아 합계를 반환합니다.</p>
 * <ul>
 *   <li>{@code a} - 첫 번째 정수</li>
 *   <li>{@code b} - 두 번째 정수</li>
 * </ul>
 * @return 두 수의 합
 */
public int add(int a, int b) {
    return a + b;
}

// ✅ Java 23 Markdown 방식
/// ## 두 수를 더합니다.
///
/// 두 정수를 받아 합계를 반환합니다.
///
/// - `a` - 첫 번째 정수
/// - `b` - 두 번째 정수
///
/// @return 두 수의 합
public int add(int a, int b) {
    return a + b;
}

2. Primitive Types in Patterns (JEP 455 - Preview)

기존 패턴 매칭(instanceof, switch)은 참조 타입만 지원했지만, Java 23부터 int, double 등 primitive 타입도 패턴 매칭에 사용할 수 있습니다.

// ✅ instanceof에서 primitive 타입 패턴 매칭
Object obj = 42;

// 기존 방식
if (obj instanceof Integer i && i > 10) {
    System.out.println("10보다 큰 정수: " + i);
}

// Java 23 - primitive 직접 사용
if (obj instanceof int i && i > 10) {
    System.out.println("10보다 큰 int: " + i);
}

// ✅ switch에서 primitive 타입 패턴 매칭
double value = 3.14;

String result = switch (value) {
    case double d when d < 0   -> "음수";
    case double d when d == 0  -> "영";
    case double d when d < 1   -> "0과 1 사이";
    default                    -> "1 이상";
};
System.out.println(result); // 출력: 1 이상

// ✅ 숫자 범위에 따른 분기 처리
int score = 85;

String grade = switch (score) {
    case int s when s >= 90 -> "A";
    case int s when s >= 80 -> "B";
    case int s when s >= 70 -> "C";
    default                 -> "F";
};
System.out.println(grade); // 출력: B

3. Stream Gatherers (JEP 473 - 2nd Preview)

커스텀 중간 스트림 연산을 직접 정의할 수 있습니다. 기존의 고정된 filter, map 등의 연산 외에 원하는 중간 처리 로직을 자유롭게 만들 수 있습니다.

import java.util.stream.Gatherers;

// ✅ 내장 Gatherer - 고정 크기 윈도우
Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.windowFixed(2))
    .forEach(System.out::println);
// 출력: [1, 2], [3, 4], [5]

// ✅ 내장 Gatherer - 슬라이딩 윈도우
Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.windowSliding(3))
    .forEach(System.out::println);
// 출력: [1, 2, 3], [2, 3, 4], [3, 4, 5]

// ✅ 내장 Gatherer - 누적 집계 (scan)
Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.scan(() -> 0, Integer::sum))
    .forEach(System.out::println);
// 출력: 1, 3, 6, 10, 15

// ✅ 커스텀 Gatherer - 중복 제거 후 처음 N개만 추출
Gatherer<Integer, ?, Integer> distinctLimit = Gatherer.ofSequential(
    () -> new HashSet<Integer>(),
    (seen, element, downstream) -> {
        if (seen.add(element)) {          // 중복이 아닌 경우만
            return downstream.push(element); // 다음 단계로 전달
        }
        return true;
    }
);

Stream.of(1, 2, 2, 3, 1, 4, 3, 5)
    .gather(distinctLimit)
    .forEach(System.out::println);
// 출력: 1, 2, 3, 4, 5

4. Implicitly Declared Classes & Instance Main Methods (JEP 477 - 3rd Preview)

Java 입문자의 진입장벽을 낮추기 위해 클래스 선언과 복잡한 main 메서드 시그니처를 생략할 수 있습니다.

// ❌ 기존 방식
public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

// ✅ Java 23 방식 - 클래스, static, args 모두 생략 가능
void main() {
    System.out.println("Hello, World!");
}

// ✅ 간단한 계산기 예제
void main() {
    int a = 10, b = 20;
    System.out.println("합계: " + (a + b));       // 합계: 30
    System.out.println("곱셈: " + (a * b));       // 곱셈: 200
    System.out.println("평균: " + (a + b) / 2.0); // 평균: 15.0
}

5. Structured Concurrency (JEP 480 - 3rd Preview)

여러 비동기 작업의 생명주기를 하나의 블록에서 구조적으로 관리합니다. 작업 실패 시 자동으로 나머지 작업을 취소하고 리소스를 정리합니다.

// ✅ ShutdownOnFailure - 하나라도 실패하면 나머지 모두 취소
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Future<String> user  = scope.fork(() -> fetchUser());   // 병렬 실행
    Future<String> order = scope.fork(() -> fetchOrder());  // 병렬 실행

    scope.join();           // 두 작업 모두 완료될 때까지 대기
    scope.throwIfFailed();  // 실패한 작업이 있으면 예외 전파

    return new Result(user.resultNow(), order.resultNow());
}
// try 블록을 벗어나면 모든 하위 스레드 자동 정리

// ✅ ShutdownOnSuccess - 가장 먼저 성공한 결과 사용 (경쟁 실행)
try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
    scope.fork(() -> fetchFromServerA()); // 서버 A에서 조회
    scope.fork(() -> fetchFromServerB()); // 서버 B에서 조회 (더 빠른 쪽 사용)

    scope.join();
    return scope.result(); // 먼저 성공한 결과 반환, 나머지는 자동 취소
}

6. Scoped Values (JEP 481 - 3rd Preview)

ThreadLocal의 문제점(메모리 누수, 변경 가능성)을 해결하는 불변 데이터 공유 메커니즘입니다. 특정 스코프 내에서만 유효한 값을 안전하게 전달합니다.

// ✅ ScopedValue 선언
static final ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();
static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance();

// 요청 처리 진입점
void handleRequest(User user, String requestId) {
    // 스코프 내에서만 값 바인딩 (여러 값 동시 바인딩 가능)
    ScopedValue.where(CURRENT_USER, user)
               .where(REQUEST_ID, requestId)
               .run(() -> {
                   authenticate(); // CURRENT_USER 접근 가능
                   logRequest();   // REQUEST_ID 접근 가능
                   processData();  // 둘 다 접근 가능
               });
    // 블록을 벗어나면 자동 해제 - 메모리 누수 없음
}

void authenticate() {
    User user = CURRENT_USER.get();
    System.out.println("인증 확인: " + user.name());
}

void logRequest() {
    String id = REQUEST_ID.get();
    System.out.println("요청 ID 로깅: " + id);
}

항목	`ThreadLocal`	`ScopedValue`
값 변경	✅ 가능	❌ 불변
유효 범위	스레드 전체 생존 기간	명시적 블록 내부
메모리 누수 위험	⚠️ 있음	✅ 없음
Virtual Thread 성능	❌ 비효율	✅ 최적화

7. ️ Flexible Constructor Bodies (JEP 482 - 2nd Preview)

기존에는 생성자에서 super() 또는 this() 호출이 반드시 첫 번째 줄에 있어야 했습니다. Java 23부터는 super() 호출 이전에도 인스턴스 필드에 영향을 주지 않는 코드를 작성할 수 있습니다.

class Animal {
    String name;
    Animal(String name) {
        this.name = name;
    }
}

class Dog extends Animal {

    // ❌ 기존 방식 - super() 전에 유효성 검사 불가
    Dog(String name) {
        super(name); // 반드시 첫 줄이어야 함
        if (name == null || name.isBlank()) { // super() 이후에만 검사 가능
            throw new IllegalArgumentException("이름은 비어있을 수 없습니다.");
        }
    }

    // ✅ Java 23 방식 - super() 호출 전에 유효성 검사 가능
    Dog(String name) {
        // super() 전에 검증 로직 작성 가능
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("이름은 비어있을 수 없습니다.");
        }
        super(name); // 검증 후 부모 생성자 호출
    }
}

// ✅ 데이터 전처리 후 super() 호출
class Circle extends Shape {
    Circle(double radius) {
        // super() 전에 값 가공 가능
        double normalized = Math.abs(radius); // 음수 반지름 보정
        super(normalized);
    }
}

Kubernetes HPA

창욱씨 — Sun, 3 May 2026 20:10:57 +0900

1. HPA란?

Pod 수를 자동으로 조절하는 Kubernetes 리소스
직접 스케일링을 수행하지 않고, 메트릭을 모니터링 후 Deployment의 replicas 수를 업데이트하는 명령만 내림
실제 Pod 생성/삭제는 Deployment → ReplicaSet → Scheduler → kubelet이 담당

2. 스케일링 방향

Scale Up (증가) / Scale Down (감소) 모두 담당
단, 제약 안에서만 동작

제약 종류	설명
수량 제약	`minReplicas` ~ `maxReplicas` 범위를 절대 벗어날 수 없음
속도 제약	Scale Up은 즉시, Scale Down은 기본 5분 안정화 윈도우 적용

3. 구성 요소 및 단위

[클러스터] - 전체 Kubernetes 환경
    ├── kube-controller-manager (클러스터에 1개)
    │     └── HPA Controller    (클러스터에 1개, 모든 HPA 관리)
    │
    ├── Metrics Server          (클러스터에 1개, 메트릭 집계 및 API 제공)
    │
    ├── [Node 1]                (실제 서버, 클러스터에 여러 개)
    │     ├── kubelet           (Node마다 1개, Pod 메트릭 수집)
    │     ├── Pod A
    │     └── Pod B
    │
    └── [Node 2]
          ├── kubelet
          └── Pod C

컴포넌트	단위	역할
HPA Controller	클러스터에 1개	메트릭 모니터링 + replicas 결정
Metrics Server	클러스터에 1개	kubelet 데이터 집계 + API 제공
kubelet	Node마다 1개	해당 Node의 모든 Pod 메트릭 수집

4. 전체 흐름

kubelet (각 Node)
  → 메트릭 수집
Metrics Server
  → kubelet으로부터 집계
HPA Controller
  → Metrics Server에 질의 → replicas 수 계산
Deployment Controller → ReplicaSet Controller → Scheduler → kubelet
  → 실제 Pod 생성/삭제

Kubernetes Ingress

창욱씨 — Sat, 25 Apr 2026 16:56:25 +0900

1. Ingress란?

클러스터 외부 HTTP/HTTPS 트래픽을 내부 Service로 라우팅하는 쿠버네티스 리소스

도메인/경로 기반 라우팅 지원 (L7)
TLS/HTTPS 종료 처리
단독 사용 불가 → 반드시 Ingress Controller 필요 (nginx, traefik 등)

2. Service vs Ingress

항목	Service	Ingress
한 줄 정의	Pod을 위한 로드밸런서	Service를 위한 로드밸런서
레이어	L4 (TCP/UDP)	L7 (HTTP/HTTPS)
라우팅 기준	랜덤/라운드로빈	도메인, URL 경로
독립 실행	✅	❌ (Service 필요)

3. 전체 구조 (2단계 로드밸런싱)

외부 사용자
    │
    ▼
[ Ingress ]          ← L7 로드밸런서 (어느 Service로?)
    │
    ├──→ [ Service A ]  ← L4 로드밸런서 (어느 Pod으로?)
    │      ├→ [Pod]
    │      └→ [Pod]
    │
    └──→ [ Service B ]  ← L4 로드밸런서 (어느 Pod으로?)
           ├→ [Pod]
           └→ [Pod]

4. 2단계 구조의 이점

이점	설명
관심사의 분리	Ingress는 라우팅만, Service는 Pod 관리만
Pod IP 변동 대응	Pod 재시작 시 IP가 바뀌어도 Service IP는 고정
재사용성	같은 Service를 여러 Ingress에서 참조 가능

5. Ingress → Pod 직접 연결은?

기술적으로는 가능 (일부 Controller에서 비표준 지원)
하지만 권장하지 않음

문제	설명
Pod IP 변동	재시작 시 IP 바뀌어 연결 끊김
헬스체크 부재	죽은 Pod으로 트래픽 전달 가능
스케일링 어려움	Pod 추가/삭제 시 실시간 감지 어려움

Java에서 데이터 없음을 표현하는 방법

창욱씨 — Sat, 18 Apr 2026 17:14:01 +0900

"Java에서 '데이터/값 없음'을 어떻게 표현할 것인가?"

상황별로 최적의 선택이 다릅니다. 다음 영역을 단계별로 살펴봅니다:

null의 본질
   ↓
클래스 필드 (primitive vs wrapper)
   ↓
Optional (어디에 쓸까)
   ↓
메서드 반환
   ↓
Enum 탐색 (다양한 패턴)
   ↓
컬렉션 / 배열 / 예외 처리

1️⃣ null의 본질

null = 참조할 객체 자체가 없음 (참조 타입 전용)
"참조 없음" ≠ "빈 데이터"
- null → 주소 자체가 없음
- "", [] → 객체는 있는데 내용이 비어있음
null 참조 사용 시 → NullPointerException 발생

2️⃣ 클래스 필드 설계 원칙

기본 원칙

primitive 우선, 단 "값 없음"이 의미를 가질 땐 wrapper + null

의사결정

상황	선택
값이 항상 존재	`int`, `long`, `boolean` (primitive) ✅
값이 없을 수 있음	`Integer`, `Long` (wrapper) + null ✅
0, -1을 sentinel로	❌ 안티패턴
`Optional` 필드	❌ 안티패턴

예시

class User {
    private Long id;           // ✅ wrapper (저장 전 null)
    private String name;       // ✅ 참조 타입 (null 가능)
    private int loginCount;    // ✅ primitive (0이 자연스러움)
    private Integer age;       // ✅ wrapper (미입력 = null)
}

왜 sentinel(0, -1)은 안 되나?

"0 = 없음"은 암묵적 약속 → 실수 유발
JPA/Hibernate가 wrapper 권장
JSON 직렬화 시 모호함
미래에 0이 유효 값이 될 수 있음

3️⃣ Optional은 어디에 쓰나?

✅ 사용 권장

메서드 반환 타입 (오직 여기에만!)

❌ 사용 금지

필드 (직렬화 문제, 메모리 오버헤드, null 역설)
매개변수
컬렉션 원소

4️⃣ 메서드 반환 - null vs Optional

원칙

필드:        wrapper + null ✅,  Optional ❌
메서드 반환: Optional ✅,        null ⚠️

Optional 제대로 쓰기

❌ .get(), .isPresent() 남용 = 안티패턴 (null 체크와 다를 게 없음)

✅ 선언적 메서드 활용:

// 기본값
opt.orElse(defaultValue);
opt.orElseGet(() -> compute());

// 예외
opt.orElseThrow(() -> new MyException());

// 동작
opt.ifPresent(this::handle);
opt.ifPresentOrElse(this::handle, this::onEmpty);

// 변환
opt.map(User::getName).filter(...).orElse("unknown");

사고방식 전환

❌ "Optional에서 값을 꺼내자(unwrap)"

✅ "Optional 안에서 작업을 처리하자"

5️⃣ Enum 탐색 패턴 (정확한 구분)

5가지 패턴 비교

패턴 1: UNKNOWN 반환 (가장 흔함) ⭐

"못 찾으면 UNKNOWN을 기본값으로 반환"

public enum Status {
    ACTIVE, INACTIVE, PENDING, UNKNOWN;

    public static Status fromCode(String code) {
        return Arrays.stream(values())
            .filter(s -> s.name().equals(code))
            .findFirst()
            .orElse(UNKNOWN);
    }
}

// 호출자가 직접 분기
Status s = Status.fromCode(code);
if (s == Status.UNKNOWN) {
    log.warn("알 수 없는 상태");
    return;
}
switch (s) {
    case ACTIVE -> doActive();
    case INACTIVE -> doInactive();
}

→ 간단, 명확, 동작 많아도 enum이 비대해지지 않음.

패턴 2: Null Object Pattern (동작 단순할 때)

"UNKNOWN이 무해한 동작을 직접 가짐"

public enum Status {
    ACTIVE   { @Override public void process() { /* 처리 */ } },
    INACTIVE { @Override public void process() { /* 비활성 */ } },
    UNKNOWN  { @Override public void process() { /* 아무것도 안 함 */ } };

    public abstract void process();
}

// 호출자가 분기 없음
Status.fromCode(code).process();

→ 분기 제거되고 우아하지만, 동작이 많으면 enum 폭발 .

패턴 3: Strategy Pattern (동작 복잡할 때)

"enum은 식별자만, 동작은 별도 클래스로 분리"

public enum OrderStatus {
    CREATED, PAID, SHIPPED, DELIVERED, CANCELLED, UNKNOWN;
}

public interface OrderStatusHandler {
    void handle(Order order);
}

@Component
public class OrderStatusHandlerFactory {
    private final Map<OrderStatus, OrderStatusHandler> handlers = Map.of(
        OrderStatus.CREATED, new CreatedHandler(),
        OrderStatus.PAID, new PaidHandler(),
        OrderStatus.UNKNOWN, new NoOpHandler()  // ← 핸들러 레벨 Null Object
    );

    public OrderStatusHandler get(OrderStatus status) {
        return handlers.getOrDefault(status, new NoOpHandler());
    }
}

// 사용
factory.get(order.getStatus()).handle(order);

→ enum 깔끔, 동작 분리, 확장 용이.

패턴 4: Optional 반환 (호출자 결정)

public static Optional<Status> fromCode(String code) {
    return Arrays.stream(values())
        .filter(s -> s.name().equals(code))
        .findFirst();
}

// 호출자가 상황에 따라 처리
Status.fromCode(code)
    .ifPresentOrElse(this::process, () -> log.warn("없음"));

→ 호출자에게 유연성 제공.

패턴 5: 예외 던지기 (엄격한 도메인)

public static Status fromCode(String code) {
    return Arrays.stream(values())
        .filter(s -> s.name().equals(code))
        .findFirst()
        .orElseThrow(() -> 
            new IllegalArgumentException("알 수 없는 상태: " + code));
}

→ 결제, 주문 등 절대 잘못되면 안 되는 도메인.

의사결정 가이드

"못 찾은 enum을 어떻게 처리할까?"
    │
    ▼
동작이 단순하고 추상화 가능한가?
    │
    ├─ YES → Null Object Pattern
    │       (UNKNOWN이 무해한 동작 가짐)
    │
    └─ NO  → 동작이 많거나 복잡함
              │
              ▼
         어디에서 처리할까?
              │
              ├─ 알 수 없는 상태로 진행 OK
              │   → UNKNOWN 반환 + 호출자 분기 ⭐ (가장 흔함)
              │
              ├─ 동작을 깔끔히 분리하고 싶음
              │   → Strategy Pattern
              │
              ├─ 호출자에게 결정 위임
              │   → Optional 반환
              │
              └─ 절대 있으면 안 됨
                  → 예외 던지기 (Fail Fast)

Enum 패턴 비교표

방식	복잡도	호출자 부담	적합한 상황
UNKNOWN 반환	⭐ 낮음	분기 필요	동작 다양, 일반적 ⭐
Null Object Pattern	⭐⭐ 중간	분기 없음	동작 단순, 통일 가능
Strategy Pattern	⭐⭐⭐ 높음	없음	동작 많고 복잡
Optional 반환	⭐ 낮음	처리 필요	호출자가 결정
예외 던지기	⭐ 낮음	catch 필요	엄격한 도메인

실전 권장 순서

기본: UNKNOWN 반환 (또는 Optional 반환)
동작이 명확하고 단순하면: Null Object Pattern으로 발전
동작이 복잡해지면: Strategy Pattern으로 분리
있으면 안 되는 상황: 예외 던지기

6️⃣ 컬렉션 (List, Set, Map)

절대 금지: null 컬렉션 반환

// ❌ 최악의 안티패턴
public List<User> findUsers() {
    if (noResult) return null;
    return users;
}

List<User> users = findUsers();
for (User u : users) { ... }  //   NPE!

✅ 빈 컬렉션 반환

public List<User> findUsers() {
    if (noResult) return Collections.emptyList();  // 또는 List.of()
    return users;
}

findUsers().forEach(this::process);  // 결과 없어도 안전 ✅

빈 컬렉션 만드는 방법

// 불변 빈 컬렉션 (메모리 효율적)
List.of();                       // Java 9+
Collections.emptyList();
Collections.emptySet();
Collections.emptyMap();

// 가변 빈 컬렉션
new ArrayList<>();
new HashMap<>();

Map - 키가 없을 때

// ❌ 옛날 스타일
Object value = map.get(key);
if (value == null) {
    value = defaultValue;
}

// ✅ Java 8+
map.getOrDefault(key, defaultValue);
map.computeIfAbsent(key, k -> createNewValue());
map.putIfAbsent(key, defaultValue);

Map.get()의 함정 ⚠️

// 두 가지 의미가 섞임
map.get(key);
//   1. 키가 없음 → null
//   2. 키는 있는데 값이 null → null
// 구분하려면 containsKey() 사용

컬렉션 황금 규칙:
"값 없음 = null이 아니라, 값 없음 = 빈 컬렉션"

7️⃣ 배열 (Array)

null 배열 vs 빈 배열

// ❌ null 배열
public int[] getNumbers() {
    return null;
}

// ✅ 빈 배열
public int[] getNumbers() {
    return new int[0];
}

// 또는 상수로 메모리 절약
private static final int[] EMPTY_INT_ARRAY = new int[0];

컬렉션 → 배열 변환

List<String> list = getStrings();

// ✅ 안전한 패턴 (Java 11+)
String[] arr = list.toArray(String[]::new);

// 빈 리스트면 빈 배열 반환 (null 아님) ✅

배열 황금 규칙:
"컬렉션과 동일 - null 배열보다 빈 배열을!"

8️⃣ 예외 처리 (Exception)

null 반환 vs 예외 던지기

상황	선택
정상 흐름의 "없음" (조회 실패 등)	`Optional` / null
비정상 상태 (잘못된 입력, 시스템 오류)	예외 던지기
호출자가 항상 값을 기대	예외 또는 default
있을 수도 있고 없을 수도 있음	`Optional`

핵심 원칙: Fail Fast

// ❌ null로 조용히 실패
public User getUser(Long id) {
    if (id == null) return null;
    return repository.findById(id).orElse(null);
}
// 호출자: 어디서 null이 됐는지 모름 → 디버깅 지옥  

// ✅ 즉시 예외로 명확히 실패
public User getUser(Long id) {
    Objects.requireNonNull(id, "id는 null일 수 없습니다");
    return repository.findById(id)
        .orElseThrow(() -> new UserNotFoundException(id));
}

입력 검증 (Guard Clauses)

public void process(User user, List<Order> orders) {
    Objects.requireNonNull(user, "user는 null일 수 없습니다");
    Objects.requireNonNull(orders, "orders는 null일 수 없습니다");

    if (orders.isEmpty()) {
        throw new IllegalArgumentException("orders는 비어있을 수 없습니다");
    }

    // 본 로직 - 여기서부터 null/empty 걱정 없음
}

Checked vs Unchecked

// ✅ Unchecked - 프로그래머 실수
throw new IllegalArgumentException("잘못된 입력");
throw new IllegalStateException("잘못된 상태");

// ✅ Checked - 외부 요인 (호출자가 처리해야 함)
throw new IOException("파일 읽기 실패");

// ✅ 도메인 예외는 Unchecked로
public User findUser(Long id) {
    throw new UserNotFoundException(id);  // RuntimeException 상속
}

Optional + 예외의 우아한 조합

public class UserService {
    // 호출자가 결정
    public Optional<User> findUser(Long id) {
        return repository.findById(id);
    }

    // 반드시 있어야 함
    public User getUser(Long id) {
        return findUser(id)
            .orElseThrow(() -> new UserNotFoundException(id));
    }
}

"예상 가능한 없음 → Optional, 비정상 상태 → 예외 (Fail Fast)"

️ 전체 통합 가이드

위치 / 상황	권장 방식	비권장
필드 - 항상 값 존재	primitive (`int`, `long`)	-
필드 - 값 없을 수 있음	wrapper + null (`Integer`)	sentinel (0, -1), Optional
메서드 반환 - 결과 없을 수 있음	`Optional<T>`	null
Enum 탐색 - 단순 기본값	UNKNOWN 반환 ⭐	null
Enum 탐색 - 동작 단순	Null Object Pattern	-
Enum 탐색 - 동작 복잡	Strategy Pattern	-
Enum 탐색 - 호출자 결정	Optional 반환	-
Enum 탐색 - 잘못된 입력	예외 던지기	UNKNOWN
컬렉션 반환	빈 컬렉션 (`List.of()`)	null
Map 조회	`getOrDefault`, `computeIfAbsent`	null 체크
배열 반환	빈 배열 (`new int[0]`)	null
메서드 입력 검증	`Objects.requireNonNull`	조용한 null
예상 가능한 "없음"	`Optional`	예외
비정상 상태	예외 (Fail Fast)	null 반환

핵심 원칙 8가지

null은 "참조할 대상 없음"이지, "빈 데이터"가 아니다.
필드 설계: primitive 우선, "없음"이 필요하면 wrapper + null. sentinel은 안티패턴.
Optional은 메서드 반환 전용. 필드/매개변수에 쓰지 말 것.
Optional은 .get() 쓰라고 만든 게 아니다. orElse, map, ifPresent로 처리.
Enum 탐색은 상황별로 5가지 패턴: UNKNOWN 반환 / Null Object / Strategy / Optional / 예외.
"UNKNOWN 반환"과 "Null Object Pattern"은 다른 개념. 동작 추상화 가능 여부에 따라 선택.
컬렉션과 배열은 절대 null 반환 금지 → 항상 빈 컬렉션/빈 배열.
예외는 비정상 상태에서 빠르게 던져라 (Fail Fast) → 조용한 null 반환은 디버깅 지옥.

영역별 사고방식 정리

데이터 표현 영역

필드        → wrapper + null (sentinel ❌)
컬렉션      → 빈 컬렉션 (null ❌)
배열        → 빈 배열 (null ❌)

메서드 시그니처 영역

반환값      → Optional ⭐
매개변수    → 오버로딩, Builder 패턴
입력 검증   → Objects.requireNonNull (Fail Fast)

Enum 탐색 영역

단순 기본값         → UNKNOWN 반환 ⭐
동작 통일 가능      → Null Object Pattern
동작 복잡           → Strategy Pattern
호출자 결정         → Optional 반환
엄격한 도메인       → 예외 던지기

️ 안전 장치 영역

정상 흐름의 없음    → Optional
비정상 상태         → 예외 (Fail Fast)
외부 경계           → 즉시 검증
무음 실패 방지      → 예외 무시 금지

Kubernetes Service

창욱씨 — Wed, 1 Apr 2026 22:33:48 +0900

Kubernetes Service 정리

1. Service란?

Pod는 동적으로 생성/삭제되어 IP가 계속 바뀜
Service는 Pod들에게 안정적인 고정 IP / DNS를 제공하는 리소스
Pod 집합에 대한 추상화된 네트워크 접근 방법

2. Service의 주요 역할

역할	설명
고정 엔드포인트	Pod가 바뀌어도 Service IP/DNS는 유지
로드밸런싱	여러 Pod에 트래픽 자동 분산 (Round Robin)
서비스 디스커버리	DNS 이름으로 Pod 접근 가능
헬스체크 연동	죽은 Pod는 자동으로 트래픽 대상에서 제외

3. Service의 종류

타입	접근 범위	주요 사용 사례
`ClusterIP`	클러스터 내부	마이크로서비스 내부 통신
`NodePort`	노드 IP + 포트	개발/테스트 외부 접근
`LoadBalancer`	외부 인터넷	클라우드 운영 환경
`ExternalName`	외부 DNS	외부 서비스 참조

4. Service는 "Pod를 위한 로드밸런서"?

✅ 맞습니다 — 여러 Pod에 트래픽을 분산시키는 로드밸런서 역할
➕ 그 이상 — 고정 엔드포인트 제공, 서비스 디스커버리, 헬스체크 연동까지

5. Service IP는 VIP?

✅ VIP와 유사한 역할 — 고정된 단일 진입점 제공, 뒤의 Pod가 바뀌어도 동일 IP로 접근
실무에서도 Service IP를 VIP라고 부르기도 함
단, 구현 방식이 전용 LB 장비가 아닌 각 노드의 iptables / IPVS 규칙으로 동작

n8n

창욱씨 — Tue, 24 Mar 2026 11:30:31 +0900

n8n이란

n8n(nodemation)은 Node.js 기반의 오픈소스 워크플로우 자동화 엔진입니다. 다양한 서비스(SaaS), 데이터베이스, API를 시각적인 '노드(Node)' 형태로 연결하여 비즈니스 로직을 자동화합니다. Zapier와 같은 서비스와 유사하지만, 사용자가 자신의 서버에 직접 설치(Self-hosting)하여 운영할 수 있는 'Fair-code' 라이선스 모델을 채택하고 있어 데이터 주권 확보에 최적화되어 있습니다.

n8n의 특징

자가 호스팅 (Self-hosting): 온프레미스(On-premise)나 개인 클라우드(Docker 등)에 직접 설치하여 외부 서버로의 데이터 유출을 원천 차단합니다.
노드 기반 시각적 설계: 복잡한 프로그래밍 코드를 작성하는 대신, 직관적인 UI에서 노드를 드래그 앤 드롭하고 선으로 연결하여 로직을 설계합니다.
강력한 확장성 (Low-code): 기본 노드로 부족한 로직은 JavaScript를 직접 작성하여 확장할 수 있으며, API가 있는 모든 서비스와 연동 가능합니다.
JSON 기반 데이터 흐름: 모든 노드 간 데이터 교환은 표준 JSON 배열 형식을 따르므로 개발자가 데이터를 가공하고 참조하기 매우 용이합니다.

n8n의 장점 및 단점

✅ 장점

비용 효율성: 실행 횟수(Task)당 과금이 없어 대규모 트래픽 처리 시 비용 부담이 거의 없습니다.
보안 및 프라이버시: 민감한 비즈니스 데이터를 내부망 내에서만 처리할 수 있습니다.
로직의 자유도: 무한 루프, 조건부 분기, 데이터 병합 등 프로그래밍 수준의 복잡한 설계가 가능합니다.

❌ 단점

인프라 관리 부담: 서버 구축, DB 튜닝, 보안 업데이트, 백업 등을 사용자가 직접 관리해야 합니다.
초기 학습 곡선: JSON 구조 및 자바스크립트에 대한 기초 지식이 없으면 고급 기능을 활용하기 어렵습니다.

n8n의 워크플로우

n8n의 워크플로우는 트리거(Trigger) → 로직/액션 노드 → 데이터 출력의 순서로 실행됩니다.

비동기 병렬 처리: 기본적으로 여러 요청이 동시에 인입될 경우 각 작업을 **병렬(Parallel)**로 즉시 실행합니다.
Wait 노드의 특수 동작: 워크플로우 중간에 대기가 발생하면 현재 상태를 직렬화(Serialization)하여 DB에 저장한 뒤 메모리를 해제합니다. 이후 정해진 시간에 DB에서 상태를 복원(Hydration)하여 작업을 재개하므로 서버 재시작 시에도 데이터가 보호됩니다.

n8n 노드 종류

Trigger Nodes: 워크플로우의 시작점 (Webhook, Cron/Schedule, 이메일 수신 등)
Regular Nodes: 실제 작업을 수행 (Google Sheets 기록, Slack 메시지 전송, DB 쿼리 등)
Logic Nodes: 흐름을 제어 (IF 조건문, Switch 분기, Wait 대기, Merge 병합)
Code Node: JavaScript를 사용하여 데이터를 커스텀 가공하는 노드

n8n 데이터 저장 및 처리 구조

성능과 안정성을 위해 n8n은 데이터를 물리적으로 분리하여 관리합니다.

구분	저장 위치	역할 및 특성
활성 실행 데이터	RAM (메모리)	실시간 연산 데이터. 재시작 시 휘발됨(In-flight data).
영속성 데이터	DB (Disk)	설계도(JSON), Credentials, 실행 이력, Wait 상태 정보.
바이너리 데이터	Disk / S3	이미지, PDF 등 대용량 파일 저장.

* 운영 환경에서는 PostgreSQL을 권장하며, 기존 인프라에 따라 MySQL 연동도 가능합니다. Docker 배포 시 /home/node/.n8n 볼륨 마운트는 필수적입니다.

Kubernetes Deployment

창욱씨 — Thu, 5 Mar 2026 12:13:02 +0900

1. Deployment란?

Deployment는 Kubernetes에서 애플리케이션의 선언적 업데이트를 관리하는 리소스입니다.

"이 앱을 이런 설정으로, 이 개수만큼 항상 실행되도록 유지해줘!" 라고 Kubernetes에게 선언하는 것

2. 리소스 계층 구조

Deployment
    └── ReplicaSet
            └── Pod
                    └── Container

3. 각 리소스 역할

리소스	비유	역할
Deployment	건축 설계도	Pod의 설계도 관리 (이미지, 리소스, 버전, 배포 전략)
ReplicaSet	건설 현장 감독	실제 Pod 생성 / 제거 / 유지 / 재시작
Pod	실제 건물	컨테이너가 실행되는 최소 단위
Container	건물 내부	실제 애플리케이션 프로세스

4. Deployment가 관리하는 것

어떤 이미지를 사용할지 (image: my-app:1.0.0)
리소스 제한 (CPU, Memory requests/limits)
환경변수, ConfigMap, Secret 연결
버전 히스토리 (롤백용 이전 ReplicaSet 보존)
배포 전략 (RollingUpdate, Recreate 등)

5. ReplicaSet이 관리하는 것

✅ 지정된 수의 Pod 항상 유지
➕ Pod 부족 시 생성
➖ Pod 초과 시 제거
Pod 장애 시 재생성

6. 스케일링 관리

스케일링의 목표 수치를 선언하는 것은 Deployment (또는 HPA), 실제로 Pod 수를 맞추는 것은 ReplicaSet입니다.

수동 스케일링

사용자 → Deployment (replicas 선언) → ReplicaSet (Pod 수 실현) → Pod

자동 스케일링 (HPA)

CPU/메모리 임계값 초과
        ↓
       HPA (자동 감지)
        ↓
   Deployment (replicas 자동 조절)
        ↓
   ReplicaSet (Pod 수 실현)
        ↓
   Pod Pod Pod Pod Pod

7. 버전 관리 & 롤백 원리

Deployment는 새 버전 배포 시 이전 ReplicaSet을 삭제하지 않고 보존합니다.
이 덕분에 빠른 롤백이 가능합니다.

배포 시

[현재] Deployment (image: v2)
         ├── ReplicaSet-A (v1) → Pod 0개  ← 보존됨
         └── ReplicaSet-B (v2) → Pod 3개  ← 현재 운영 중

롤백 시

[롤백] Deployment (image: v1으로 복구)
         ├── ReplicaSet-A (v1) → Pod 3개  ← 복구됨
         └── ReplicaSet-B (v2) → Pod 0개  ← 축소됨

8. ReplicaSet 데이터 저장 방식

ReplicaSet을 포함한 모든 Kubernetes 리소스는 etcd에 저장됩니다.

etcd란?

항목	설명
종류	분산 Key-Value 데이터베이스
저장 방식	디스크에 영구 저장 (재시작해도 유지)
저장 내용	모든 K8s 리소스 상태 (Deployment, ReplicaSet, Pod 등)
특징	고가용성, 분산 저장, Watch 기능 (변경 감지)

저장 흐름

kubectl apply -f deployment.yaml
        ↓
   API Server
        ↓
  etcd (분산 Key-Value DB) ← 여기에 영구 저장!
        ↓
  Controller Manager
  (etcd 상태를 보고 ReplicaSet, Pod 생성/관리)

9. ReplicaSet 보관 주기 관리

이전 ReplicaSet의 보존 개수는 revisionHistoryLimit 으로 설정합니다. (기본값: 10)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  revisionHistoryLimit: 3  # 이전 ReplicaSet 보존 개수
  selector:
    matchLabels:
      app: my-app
  template:
    ...

동작 방식 (revisionHistoryLimit: 3)

배포 v1 → ReplicaSet-A 생성
배포 v2 → ReplicaSet-B 생성  (A 보존)
배포 v3 → ReplicaSet-C 생성  (A, B 보존)
배포 v4 → ReplicaSet-D 생성  (B, C 보존, A 삭제! ← 3개 초과)
배포 v5 → ReplicaSet-E 생성  (C, D 보존, B 삭제! ← 3개 초과)

⚠️ revisionHistoryLimit: 0 으로 설정하면 이전 ReplicaSet을 전혀 보존하지 않아 롤백이 불가능해집니다!

10. 전체 핵심 요약

항목	내용
Deployment	Pod 설계도 (이미지, 리소스, 버전, 배포 전략 관리)
ReplicaSet	Pod 실제 생성/제거/유지 담당
스케일링 선언	Deployment 또는 HPA
스케일링 실현	ReplicaSet
롤백 가능 이유	이전 ReplicaSet을 etcd에 보존하기 때문
데이터 저장소	etcd (디스크 영구 저장)
보관 주기 설정	`revisionHistoryLimit` (기본값: 10)

Java 22

창욱씨 — Sun, 28 Dec 2025 21:47:27 +0900

1. Unnamed Variables & Patterns (JEP 456) - 정식 기능

언더스코어(_)를 사용하여 사용하지 않는 변수나 패턴을 표시할 수 있습니다.

// 사용하지 않는 변수
try {
    // ... 
} catch (Exception _) {  // 예외 변수를 사용하지 않음
    System.out.println("에러 발생");
}

// 람다에서 사용하지 않는 파라미터
list. forEach((_, value) -> System.out.println(value));

// 패턴 매칭에서
if (obj instanceof Point(int x, _)) {  // y 값은 필요 없음
    System.out.println("x = " + x);
}

2. Statements Before super() (JEP 447) - 프리뷰

생성자에서 super() 호출 전에 문장을 실행할 수 있습니다.

public class Child extends Parent {
    public Child(int value) {
        // super() 전에 검증 가능! 
        if (value < 0) {
            throw new IllegalArgumentException("음수 불가");
        }
        super(value);
    }
}

3. String Templates (JEP 459) - 두 번째 프리뷰

문자열 템플릿을 통한 안전한 문자열 보간 기능

String name = "홍길동";
int age = 25;
String message = STR."이름:  \{name}, 나이:  \{age}";

4. Stream Gatherers (JEP 461) - 프리뷰

Stream API에 커스텀 중간 연산을 추가할 수 있습니다.

// 고정 크기 윈도우로 그룹화
List<List<Integer>> windows = Stream.of(1, 2, 3, 4, 5)
    .gather(Gatherers.windowFixed(2))
    .toList();
// 결과: [[1, 2], [3, 4], [5]]

5. Structured Concurrency (JEP 462) - 두 번째 프리뷰

구조화된 동시성으로 멀티스레드 프로그래밍 단순화

try (var scope = new StructuredTaskScope. ShutdownOnFailure()) {
    Future<String> user = scope.fork(() -> fetchUser());
    Future<Integer> order = scope.fork(() -> fetchOrder());

    scope.join();
    scope.throwIfFailed();

    return new Response(user.resultNow(), order.resultNow());
}

6. Scoped Values (JEP 464) - 두 번째 프리뷰

ThreadLocal의 대안으로 불변 데이터 공유

final static ScopedValue<User> CURRENT_USER = ScopedValue.newInstance();

ScopedValue.where(CURRENT_USER, user)
    .run(() -> processRequest());

Docker Compose

창욱씨 — Sun, 21 Dec 2025 21:59:44 +0900

Docker Compose 가이드

Docker Compose는 여러 개의 Docker 컨테이너를 정의하고 실행하기 위한 도구입니다. YAML 파일을 사용하여 애플리케이션의 서비스, 네트워크, 볼륨 등을 구성할 수 있습니다.

주요 특징

1. 다중 컨테이너 관리

하나의 명령어로 여러 컨테이너를 동시에 시작/중지할 수 있습니다
복잡한 애플리케이션 스택을 쉽게 관리할 수 있습니다

2. 선언적 구성

docker-compose.yml 파일에 인프라를 코드로 정의합니다
버전 관리가 가능하고 재현 가능한 환경을 만들 수 있습니다

기본 구조 예시

version: '3.8'

services:
  # 웹 애플리케이션 서비스
  web:
    build: ./app
    ports: 
      - "3000:3000"
    environment: 
      - DATABASE_URL=postgres://db:5432/myapp
    depends_on:
      - db
    volumes:
      - ./app:/usr/src/app

  # 데이터베이스 서비스
  db:
    image: postgres: 15
    environment: 
      - POSTGRES_DB=myapp
      - POSTGRES_PASSWORD=secret
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

⌨️ 주요 명령어

명령어	설명
`docker compose up`	서비스 시작 (컨테이너 생성 및 실행)
`docker compose up -d`	백그라운드에서 서비스 시작
`docker compose down`	서비스 중지 및 컨테이너 삭제
`docker compose build`	서비스 이미지 빌드
`docker compose logs`	서비스 로그 확인
`docker compose ps`	실행 중인 컨테이너 목록
`docker compose exec <서비스> <명령>`	실행 중인 컨테이너에서 명령 실행

⚙️ 주요 설정 옵션

services (서비스 정의)

옵션	설명
`image`	사용할 Docker 이미지
`build`	Dockerfile 경로 (이미지를 직접 빌드할 때)
`ports`	포트 매핑 (호스트: 컨테이너)
`volumes`	볼륨 마운트
`environment`	환경 변수
`depends_on`	서비스 의존성 정의
`restart`	재시작 정책 (always, on-failure 등)

volumes (볼륨 정의)

데이터 영속성을 위한 볼륨 정의

networks (네트워크 정의)

컨테이너 간 통신을 위한 네트워크 구성

사용 예시

# 서비스 시작 (빌드 포함)
docker compose up --build

# 백그라운드 실행
docker compose up -d

# 특정 서비스만 시작
docker compose up web

# 서비스 중지 및 볼륨까지 삭제
docker compose down -v

# 서비스 스케일링 (web 서비스를 3개로)
docker compose up -d --scale web=3

✅ 장점

개발 환경 표준화: 팀원 모두 동일한 환경에서 개발 가능
빠른 환경 구축: 한 번의 명령으로 전체 스택 실행
마이크로서비스 관리: 여러 서비스를 효율적으로 관리
CI/CD 통합: 테스트 및 배포 파이프라인에 쉽게 통합

Docker Compose 주의사항 및 단점

⚠️ 주의사항

1. 프로덕션 환경에서의 제한

Docker Compose는 단일 호스트에서만 작동합니다
대규모 프로덕션 환경에서는 Kubernetes, Docker Swarm 등 오케스트레이션 도구를 권장합니다
고가용성(HA), 자동 복구, 로드 밸런싱 기능이 제한적입니다

2. depends_on의 한계

services:
  web:
    depends_on: 
      - db  # db 컨테이너가 "시작"되면 web 시작

depends_on은 컨테이너 시작 순서만 보장합니다
서비스가 실제로 준비(ready) 되었는지는 확인하지 않습니다
해결책: healthcheck + condition 사용

services:
  web: 
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres: 15
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

3. 환경 변수 보안

# ❌ 안전하지 않음 - 비밀번호 노출
environment:
  - DB_PASSWORD=mysecretpassword

# ✅ 권장 - . env 파일 또는 secrets 사용
env_file:
  - .env

docker-compose.yml에 민감한 정보를 직접 작성하지 마세요
.env 파일은 반드시 .gitignore에 추가하세요

4. 볼륨 데이터 삭제 주의

# ⚠️ 주의! 볼륨까지 모두 삭제됨
docker compose down -v

# 안전하게 중지만 (볼륨 유지)
docker compose down

5. 네트워크 충돌

여러 프로젝트에서 같은 포트를 사용하면 충돌 발생
프로젝트별로 다른 포트를 지정하거나 네트워크 분리 필요

단점

1. 확장성 제한

항목	Docker Compose	Kubernetes
다중 호스트	❌	✅
자동 스케일링	❌	✅
자동 복구	❌	✅
롤링 업데이트	제한적	✅

2. 모니터링 기능 부재

내장된 모니터링, 로깅 시스템이 없습니다
별도 도구 필요 (Prometheus, Grafana, ELK Stack 등)

3. 서비스 디스커버리 제한

기본적인 DNS 기반 서비스 디스커버리만 제공
복잡한 마이크로서비스 환경에서는 부족할 수 있음

4. 리소스 관리의 한계

# 리소스 제한 설정 가능하지만... 
services:
  web: 
    deploy:
      resources: 
        limits:
          cpus:  '0.5'
          memory: 512M

deploy 섹션은 Swarm 모드에서만 완전히 동작
일반 Compose에서는 --compatibility 플래그 필요

5. 버전 호환성 문제

Docker Engine 버전에 따라 지원되는 Compose 파일 버전이 다름
팀원 간 Docker 버전 차이로 문제 발생 가능

6. 디버깅의 어려움

여러 컨테이너 간 문제 추적이 복잡할 수 있음
로그가 분산되어 있어 통합 확인이 어려움

✅ 권장 사용 환경

환경	적합성	비고
로컬 개발	⭐⭐⭐⭐⭐	최적
테스트/CI	⭐⭐⭐⭐⭐	최적
스테이징	⭐⭐⭐⭐	적합
소규모 프로덕션	⭐⭐⭐	가능
대규모 프로덕션	⭐⭐	비권장 (K8s 추천)

Best Practices

# docker-compose.yml 모범 사례
version:  '3.8'

services:
  web: 
    image: myapp:${APP_VERSION:-latest}  # 버전 태그 사용
    restart: unless-stopped              # 재시작 정책
    logging:                             # 로깅 설정
      driver: "json-file"
      options: 
        max-size: "10m"
        max-file: "3"
    healthcheck:                          # 헬스체크 설정
      test:  ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

참고 자료

요약: Docker Compose는 개발 및 테스트 환경에서는 훌륭한 도구이지만, 대규모 프로덕션 환경에서는 Kubernetes 같은 오케스트레이션 도구를 고려하세요!

Next.js 하이드레이션

창욱씨 — Sun, 26 Oct 2025 23:14:14 +0900

하이드레이션이란 서버에서 HTML을 먼저 보내줘 사용자가 화면을 빠르게 볼 수 있게 한 다음, 클라이언트에서 해당 HTML에 JavaScript코드를 결합하여 상호작용이 가능한 동적인 웹페이지로 만드는 과정입니다.

하이드레이션의 주요 역할 및 필요성

Next.js는 기본적으로 SSR이나 SSG 방식으로 HTML을 미리 생성하여 클라이언트에 전달할 수 있습니다.

HTML을 미리 생성과 하이드레이션의 이점

초기 로딩 속도 향상 및 SEO 최적화: 서버에서 완성된 HTML을 받기 때문에 사용자는 빈 화면이 아닌 내용이 채워진 페이지를 빠르게 볼 수 있으며, 검색 엔진 최적화에도 유리합니다.
React 기능 활성화: 서버에서 내려준 HTML은 단순히 구조만 있는 정적인 상태입니다. 하이드레이션 과정을 통해 클라이언트의 React가 페이지를 인수하여 이벤트 리스너를 DOM 요소에 부착하고 상태를 관리할 수 있게 됩니다.

하이드레이션 과정

서버 렌더링: Next.js가 HTML과 최소한의 JavaScript 번들을 생성하여 클라이언트에 전송합니다.
클라이언트 렌더링: 브라우저는 HTML을 받아 화면에 보여줍니다.
하이드레이션: JavaScript가 로드된 후, ReactDOM.hydrate() 메서드 등을 통해 HTML 구조에 React 컴포넌트의 로직을 일치시키고 연결합니다.
완료