Advanced Beginner

전략적 설계

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 16 Feb 2026 00:00:00 +0000

대상 독자: DDD의 큰 그림을 이해하고 싶은 아키텍트 및 시니어 개발자 선수 지식: Quick Start를 읽었거나 DDD 기본 개념에 대한 이해 소요 시간: 약 30분 핵심 질문: “시스템을 어떻게 나누고, 각 부분이 어떻게 협력해야 하는가?”

요약
전략적 설계의 4가지 핵심 개념: Subdomain(비즈니스 영역 분류) → Ubiquitous Language(공통 언어 정의) → Bounded Context(모델 경계 설정) → Context Mapping(경계 간 협력 방식 정의)

복잡한 도메인을 어떻게 나누고 통합할지 결정하는 고수준 설계가 바로 전략적 설계입니다. 이는 DDD의 출발점이자 전체 시스템 아키텍처를 결정하는 핵심 활동입니다.

Implicit/Given 디버깅

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

컴파일러가 암시적 값을 찾지 못할 때 원인을 진단하고 해결하는 방법을 안내합니다.

소요 시간: 약 10-15분

TL;DR

Scala 2: -Xlog-implicits 플래그로 검색 과정 확인

Scala 3: 컴파일러 메시지가 더 명확하며, import 제안도 제공

공통: 스코프에 암시적 값이 있는지, 타입이 정확히 일치하는지 확인

이 가이드가 해결하는 문제#

다음과 같은 컴파일 에러가 발생할 때 이 가이드를 사용하세요:

Scala 2

could not find implicit value for parameter ord: Ordering[MyClass]

또는

ambiguous implicit values

Scala 3

No given instance of type Ordering[MyClass] was found

또는

OutOfMemoryError 해결하기

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

예상 소요 시간: 약 15분

TL;DR

Driver OOM: collect() 결과 크기 줄이기, spark.driver.memory 증가

Executor OOM: 파티션 수 증가 (repartition), spark.executor.memory 증가

진단 우선: Spark UI에서 어디서 OOM이 발생하는지 먼저 확인

문제 정의#

Spark 애플리케이션 실행 중 다음과 같은 오류가 발생합니다:

java.lang.OutOfMemoryError: Java heap space

또는:

Container killed by YARN for exceeding memory limits

이 가이드에서는 OOM 오류의 원인을 진단하고 해결하는 방법을 단계별로 설명합니다.

전제 조건#

항목	요구 사항	확인 방법
Spark 버전	2.4 이상 (3.x 권장)	`spark-submit --version`
Java 버전	8, 11, 또는 17	`java -version`
Spark UI	접근 가능	브라우저에서 `http://localhost:4040` 열기
권한	Spark 설정 변경 가능	spark-submit 실행 권한 확인

지원 환경: Linux, macOS, Windows (WSL2 권장)

Pod 트러블슈팅

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

목표: Pod가 정상적으로 시작되지 않거나 비정상 종료될 때 원인을 파악하고 해결합니다 예상 시간: 30분

이 가이드의 범위
다루는 내용: Pod 시작 실패, CrashLoopBackOff, ImagePullBackOff, Readiness 실패

다루지 않는 내용: 네트워크 연결 문제(네트워크 트러블슈팅 참조), 리소스 부족으로 인한 성능 저하(리소스 최적화 참조)

시작하기 전에#

다음 조건을 확인하세요.

1. kubectl 설치 및 버전 확인#

kubectl version --client

성공 시 출력:

Client Version: v1.28.0

버전 호환성
kubectl 버전은 클러스터 버전과 ±1 마이너 버전 이내여야 합니다. 예: 클러스터 1.27 → kubectl 1.26~1.28 사용 가능

2. 클러스터 접근 확인#

kubectl cluster-info

성공 시 출력:

느린 쿼리 최적화

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

검색 응답 시간이 느릴 때 원인을 진단하고 개선하는 방법을 안내합니다.

소요 시간: 약 15-30분

이 가이드의 범위
다루는 내용: 쿼리 수준의 성능 최적화, Profile API 분석, 캐시 활용

다루지 않는 내용: 클러스터 수준 튜닝(노드 추가, 하드웨어 업그레이드)은 성능 튜닝을 참조하세요.

TL;DR

Profile API로 쿼리 실행 계획 분석

불필요한 필드 제거: _source 필터링, stored fields 활용

쿼리 유형 최적화: match 대신 term, 와일드카드 앞자리 피하기

캐시 활용: filter context 사용, request cache 활성화

시작하기 전에#

다음 조건을 확인하세요:

Latency (지연시간)

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 응급실 대기 시간#

Latency를 응급실 대기 시간에 비유하면 이해하기 쉽습니다:

응급실 비유	Latency 개념	의미
평균 대기 시간	평균 응답시간	전체 환자 평균 (왜곡 가능)
절반 환자 대기 시간	P50 (중앙값)	일반적인 경험
대부분 환자 대기 시간	P95	거의 모든 환자 경험
최악 대기 시간	P99	SLA 기준, 1%의 경험
응급 vs 일반 환자	성공/실패 분리	요청 유형별 분석
대기 시간 목표	SLA/SLO	허용 가능한 한계
대기 시간 급증 알림	알림 규칙	지연 발생 시 감지

이처럼 응급실 대기 시간에서 평균보다 “최악의 대기 시간"이 중요하듯, 서비스에서도 P99가 사용자 경험을 좌우합니다.

계층형 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 아키텍처 패턴을 처음 배우는 개발자 선수 지식: 기본적인 Spring Boot MVC 패턴 이해 소요 시간: 약 15분

가장 기본적이고 널리 사용되는 아키텍처 패턴입니다. 처음 아키텍처를 배운다면 여기서 시작하세요. 계층형 아키텍처는 소프트웨어를 수평으로 나누어 각 계층이 명확한 역할을 가지도록 구성합니다. 각 계층은 위에서 아래로만 호출할 수 있다는 단순하지만 강력한 규칙을 따릅니다.

한 줄 요약#

코드를 4개 층으로 나누고, 위에서 아래로만 호출한다는 원칙을 기본으로 합니다. 이렇게 하면 각 층이 자신의 책임에 집중할 수 있고, 코드의 구조를 이해하기 쉬워집니다.

관측성 3요소

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 의사의 진단 과정#

관측성 3요소를 의사의 환자 진단 과정에 비유하면 이해하기 쉽습니다:

의사의 진단 비유	관측성 3요소	역할
체온, 혈압, 맥박 측정	Metrics	수치로 상태 파악
문진과 증상 기록	Logs	상세한 이벤트 기록
CT/X-ray 촬영	Traces	문제 위치 시각화
38.5도, 혈압 120/80	측정값	정량적 데이터
“3일 전부터 시작, 식후 악화”	로그 메시지	맥락 정보
충수돌기 부위 염증 확인	Span	문제 구간 식별
진료 기록부	데이터 저장소	Prometheus, Loki, Jaeger
종합 진단	통합 분석	3요소 상호 연결

이처럼 의사가 환자를 진단할 때 여러 방법을 조합하듯, 시스템 관측도 3요소를 함께 사용해야 정확한 분석이 가능합니다.

기본 문법

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 환자 기록 검색#

PromQL 기본 문법을 병원 EMR 검색 시스템에 비유하면 이해하기 쉽습니다:

EMR 검색 비유	PromQL 문법	역할
전체 환자 기록	메트릭명	모든 시계열 조회
현재 상태 조회	Instant Vector	특정 시점 데이터
기간별 기록 조회	Range Vector	시간 범위 데이터
진료과 필터	레이블 매칭 (=)	정확히 일치 필터
제외 검색	레이블 매칭 (!=)	특정 값 제외
패턴 검색	정규식 (=~)	유연한 필터링
이전 기록 조회	offset	과거 시점 데이터
기준 비교 (정상 범위)	비교 연산자	임계값 비교

이처럼 EMR에서 조건을 조합하여 환자 기록을 검색하듯, PromQL로 메트릭을 필터링하고 조회합니다.

기본 문법

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 건축 자재 선택#

Scala의 기본 문법을 건축 자재 선택에 비유하면 이해하기 쉽습니다:

건축 비유	Scala 개념	역할
콘크리트 (영구 고정)	val (불변)	한 번 정하면 변경 불가
이동식 파티션	var (가변)	필요시 재배치 가능
조립식 자재	lazy val	필요할 때 조립
건물 설계도	타입 시스템	구조적 안전성 보장
자동 측량	타입 추론	컴파일러가 치수 계산
모듈형 템플릿	문자열 보간	재사용 가능한 형식
건축 표준	타입 계층	일관된 호환성 규칙

이처럼 좋은 건물이 적절한 자재 선택에서 시작하듯, 좋은 Scala 코드는 올바른 변수 선언과 타입 활용에서 시작합니다.

아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 단지 운영 본부#

Kubernetes 아키텍처를 아파트 단지 운영 본부에 비유하면 이해하기 쉽습니다:

아파트 단지 비유	Kubernetes	역할
관리사무소	Control Plane	단지 전체 운영 결정 및 지휘
관리소장	API Server	모든 요청의 창구, 인증/인가 담당
입주민 대장	etcd	모든 세대 정보 기록 및 보관
입주 배정 담당자	Scheduler	새 입주자를 어느 동에 배치할지 결정
시설 관리팀	Controller Manager	세대 수 유지, 시설 상태 점검
각 동 건물	Worker Node	실제 세대가 있는 공간
동 관리인	Kubelet	해당 동의 세대 관리, 상태 보고
동 안내 데스크	Kube-proxy	방문자를 올바른 세대로 안내
이삿짐 업체	Container Runtime	실제 이사(컨테이너 실행) 담당

이처럼 Control Plane은 “관리사무소에서 단지 전체를 운영"하고, Worker Node는 “각 동에서 실제 입주민을 수용"합니다.

아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Spark는 Driver(조율자) + Executor(작업자) + Cluster Manager(리소스 관리)로 구성

모든 Transformation은 DAG로 표현되고, Action 호출 시 Job → Stage → Task로 분할되어 실행

메모리는 Execution(연산)과 Storage(캐시)가 동적으로 공유하는 Unified Memory 모델 사용

Java/Spring 개발자에게 SparkSession은 Spring Container, Executor는 Thread Pool Worker와 유사

대상 독자: Java/Spring 기반 백엔드 개발 경험이 있는 개발자

선수 지식:

Java 기본 문법 및 JVM 메모리 구조 이해
멀티스레딩 기초 개념 (Thread, ExecutorService)
분산 시스템의 기본 개념 (선택 사항)

소요 시간: 약 25-30분

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

DDD 용어 사전#

Domain-Driven Design의 핵심 용어를 정리합니다. 상세 설명은 개념 이해 섹션을 참고하세요.

TL;DR

전략적 설계: Bounded Context, Context Mapping, Ubiquitous Language로 도메인 경계와 언어 정의

전술적 설계: Entity, Value Object, Aggregate, Repository, Domain Event로 도메인 모델 구현

아키텍처 패턴: Layered, Hexagonal, CQRS, Event Sourcing으로 시스템 구조화

전략적 설계 (Strategic Design)#

📖 자세한 내용: 전략적 설계

Bounded Context (경계된 컨텍스트)#

정의: 특정 도메인 모델이 적용되고 일관성을 유지하는 명시적 경계

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Index/Document/Field: RDB의 Table/Row/Column에 대응

Shard/Replica: 데이터 분산과 복제의 기본 단위

Analyzer/Tokenizer: 텍스트를 검색 가능한 토큰으로 분해

Query/Filter Context: 점수 계산 여부에 따른 검색 방식 구분

알파벳순으로 정렬, 각 용어에서 관련 개념 문서로 링크

빠른 이동: A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | Z

Elasticsearch 핵심 용어를 빠르게 찾아볼 수 있습니다. 상세 설명은 개념 이해 섹션을 참고하세요.

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Kafka 관련 주요 용어를 정리합니다. 각 용어의 상세한 설명은 개념 이해 섹션을 참고하세요. 용어들은 알파벳 순서로 정렬되어 있으며, 관련 용어들은 상호 참조로 연결되어 있습니다.

TL;DR

핵심 구성요소: Topic(논리적 채널), Partition(병렬 처리 단위), Broker(서버), Producer(발행자), Consumer(수신자)

신뢰성: ACK(전송 확인), ISR(동기화 복제본), Replication Factor(복제 수)

Consumer 관리: Consumer Group(병렬 처리), Offset(위치), Commit(저장), Rebalancing(재분배)

Spring Kafka: KafkaTemplate(Producer), @KafkaListener(Consumer)

메타데이터 관리: KRaft(신규 권장), Zookeeper(레거시)

A#

ACK (Acknowledgment)

Producer가 메시지 전송 성공을 확인받는 방식입니다. acks=0은 확인 없이 전송하여 처리량이 가장 높지만 메시지 유실 가능성이 있습니다. acks=1은 Leader만 확인하는 중간 수준의 설정입니다. acks=all은 ISR(In-Sync Replicas) 전체가 확인해야 하므로 가장 안전하지만 지연 시간이 증가합니다. 프로덕션 환경에서는 데이터 중요도에 따라 적절한 값을 선택해야 합니다. 자세한 내용은 심화 개념 문서의 acks 섹션을 참고하세요.

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Kubernetes 학습과 운영에 필요한 핵심 용어를 정리합니다.

A-C#

Access Modes#

PersistentVolume의 접근 방식입니다. RWO(ReadWriteOnce: 단일 노드 읽기/쓰기), ROX(ReadOnlyMany: 여러 노드 읽기), RWX(ReadWriteMany: 여러 노드 읽기/쓰기)가 있습니다.

API Server (kube-apiserver)#

Kubernetes의 프론트엔드입니다. 모든 kubectl 명령, 대시보드, CI/CD 도구가 API Server를 통해 클러스터와 통신합니다. 인증, 권한 검사, 요청 검증을 수행하고 etcd와 통신합니다.

Cluster#

여러 노드(머신)로 구성된 Kubernetes 환경 전체를 의미합니다. 하나의 Control Plane과 여러 Worker Node로 구성됩니다.

ClusterIP#

Service의 기본 유형입니다. 클러스터 내부에서만 접근 가능한 가상 IP를 할당받습니다. 마이크로서비스 간 내부 통신에 사용됩니다.

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

빠른 이동: A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | R | S | T | U | V | W | Z

A#

Alerting Rules#

Prometheus에서 조건 기반 알림을 정의하는 규칙. 조건 만족 시 Alertmanager로 알림 전송.

Alertmanager#

Prometheus의 알림을 수신하여 그룹화, 억제, 라우팅하는 컴포넌트.

Annotation#

알림 규칙에서 알림 메시지, 설명, 런북 URL 등을 정의하는 메타데이터.

B#

Bucket#

Histogram에서 값의 분포를 측정하는 구간. le (less than or equal) 라벨로 구분. 예: le="0.5"는 0.5초 이하.

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Scala 핵심 용어를 알파벳 순으로 정리합니다. 상세 설명은 개념 이해 섹션을 참고하세요. 각 용어는 정의와 함께 관련 문서 링크를 제공합니다.

TL;DR - 핵심 용어 5선

Case Class: 불변 데이터 클래스, equals/copy 자동 생성

Option[A]: null 대체, Some(값) 또는 None

Pattern Matching: 구조 분석 및 데이터 추출 (match 표현식)

Trait: 구현 포함 가능한 인터페이스, 믹스인 상속 지원

given/using (Scala 3): 암시적 값/매개변수의 새로운 문법

A#

ADT (Algebraic Data Type): 대수적 데이터 타입. sealed trait과 Case Class로 정의되는 합 타입과 곱 타입의 조합. Scala 3에서는 enum으로 더 간단히 정의 가능. → 패턴 매칭과 함께 사용
Applicative: 독립적인 효과를 결합하는 타입 클래스. pure와 ap 연산을 제공. Functor보다 강력하고 Monad보다 약함. → 함수형 패턴
apply 메서드: 객체를 함수처럼 호출할 수 있게 하는 특별한 메서드. obj(args)는 obj.apply(args)로 해석됨. Companion Object에서 팩토리 메서드로 자주 사용.
Abstract Class (추상 클래스): 인스턴스화할 수 없으며 하위 클래스에서 구현해야 하는 추상 멤버를 정의하는 클래스. Trait와 달리 생성자 매개변수를 가질 수 있음. → 클래스와 객체
Await: Future의 결과를 동기적으로 기다리는 함수. Await.result(future, duration) 형태로 사용. 테스트에서만 사용하고 프로덕션에서는 피해야 함. → 동시성

C#

Cats Effect: 순수 함수형 비동기 프로그래밍을 지원하는 라이브러리. IO 타입으로 참조 투명성을 보장하며, Future보다 더 강력한 효과 시스템 제공. → 함수형 패턴
Case Class: 불변 데이터를 위한 특별한 클래스. equals, hashCode, copy, unapply 등이 자동 생성됨. Pattern Matching과 함께 사용. → Case Classes 상세
Companion Object: 클래스와 같은 이름을 가진 싱글톤 객체. 클래스의 private 멤버에 접근 가능. apply 메서드로 팩토리 패턴 구현. → 클래스와 객체
Context Bound: def f[A: Ordering]처럼 타입 클래스 인스턴스 존재를 요구하는 문법. → 암시적 변환
Currying (커링): 여러 인자를 받는 함수를 단일 인자 함수의 체인으로 변환하는 기법. Higher-Order Function과 함께 사용. → 함수와 메서드

A-C 핵심 포인트

ADT: sealed trait + case class로 타입 안전한 데이터 모델링

Case Class: 불변 데이터에 최적, 패턴 매칭과 함께 사용

Companion Object: 팩토리 메서드(apply)와 유틸리티 함수 배치

E#

Either[L, R]: 두 가지 타입 중 하나의 값을 담는 타입. 보통 Left는 실패, Right는 성공. Option과 유사하나 실패 사유를 담을 수 있음. flatMap으로 체이닝 가능.
Extension Method: 기존 타입에 새 메서드를 추가하는 기법. Scala 3에서는 extension 키워드 사용. Type Class 구현에 활용. → Scala 3 기능 비교
Enum (Scala 3): Scala 3에서 열거형을 정의하는 키워드. 단순 열거형부터 ADT 스타일까지 지원. Scala 2에서는 sealed trait + case object 조합으로 구현. → 클래스와 객체
ExecutionContext: Future 실행을 위한 스레드 풀을 제공하는 컨텍스트. → 동시성

F#

fold: 초기값과 함께 컬렉션의 모든 요소를 하나의 값으로 축소하는 연산. foldLeft는 왼쪽에서 오른쪽으로, foldRight는 오른쪽에서 왼쪽으로 축소. → 컬렉션
Function Composition (함수 합성): 작은 함수들을 결합하여 더 큰 함수를 만드는 기법. andThen은 왼쪽에서 오른쪽으로, compose는 오른쪽에서 왼쪽으로 연결. → 함수형 패턴
flatMap: 컨테이너 내의 값을 변환하고 결과를 평탄화하는 연산. Monad의 핵심 연산. For Comprehension으로 우아하게 표현 가능.
For Comprehension: flatMap, map, withFilter의 조합을 우아하게 표현하는 문법적 설탕. Option, Future, Either 등에 사용. → For Comprehension 상세
Functor: map 연산을 가진 타입 클래스. 컨테이너 내의 값을 변환. Applicative와 Monad의 기반. → 함수형 패턴
Future[T]: 아직 완료되지 않은 비동기 계산을 나타내는 타입. ExecutionContext 필요. For Comprehension으로 순차 실행 가능. → 동시성

G#

Given (Scala 3): 타입 클래스 인스턴스를 정의하는 키워드. Scala 2의 implicit val을 대체. → Scala 2 vs 3 비교

H#

Higher-Order Function: 함수를 인자로 받거나 함수를 반환하는 함수. map, filter, fold 등. → 고차 함수 상세
Higher-Kinded Type: 타입 생성자를 인자로 받는 타입. F[_] 형태. Functor, Monad 정의에 필수. → 고급 타입 시스템

I#

Immutable (불변): 생성 후 상태를 변경할 수 없는 것. Scala는 불변성을 권장. Case Class, val, 불변 컬렉션 사용.
Implicit (Scala 2): 암시적 값, 매개변수, 변환을 정의하는 키워드. Scala 3에서는 given/using으로 대체. → 암시적 변환 상세
inline (Scala 3): 컴파일 타임에 코드를 인라인하여 런타임 오버헤드를 제거하는 키워드. inline def, inline val, inline if 등으로 사용. → 매크로와 메타프로그래밍
Intersection Type (&): 여러 타입을 모두 만족하는 타입. A & B. Union Type과 반대. → 고급 타입 시스템

E-I 핵심 포인트

Either/Option: null 대신 사용, 에러 처리의 함수형 방식

flatMap: Monad의 핵심, for comprehension으로 우아하게 표현

given/using (Scala 3): implicit을 대체하는 명확한 문법

L#

Lazy val: 처음 접근할 때까지 초기화가 지연되는 값. 비용이 큰 초기화에 유용. → 기초 문법
Linearization (선형화): 다중 트레이트 상속 시 메서드 호출 순서를 결정하는 알고리즘. 오른쪽에서 왼쪽으로 트레이트가 적용됨. → 클래스와 객체
List: 불변 연결 리스트. 앞에서 추가/삭제가 O(1)로 빠르지만 인덱스 접근은 O(n). :: 연산자로 요소 추가, ::: 또는 ++로 리스트 연결. → 컬렉션
Lower Bound (하한 경계): 타입 매개변수가 특정 타입의 상위 타입이어야 함을 지정. A >: B 형태. 공변 타입에서 메서드 매개변수를 다룰 때 사용. → 제네릭

M#

Macro (매크로): 컴파일 타임에 코드를 생성하는 기능. Scala 3에서는 ${ } 스플라이스와 '{ } 인용, scala.quoted API 사용. 보일러플레이트 코드 생성에 유용. → 매크로와 메타프로그래밍
Match Type (Scala 3): 타입 수준에서 패턴 매칭을 수행하는 기능. 입력 타입에 따라 다른 결과 타입을 계산. 재귀적 Match Types로 복잡한 타입 변환 가능. → 고급 타입 시스템
Mixin: 여러 Trait를 조합하여 클래스를 구성하는 방식. with 키워드로 트레이트를 믹스인. 코드 재사용과 관심사 분리에 유용. → 클래스와 객체
Match Expression: 값의 패턴에 따라 분기하는 표현식. switch의 강력한 버전. Case Class와 Sealed 트레이트에 최적화. → 패턴 매칭 상세
Monad: flatMap과 pure 연산을 가진 타입 클래스. 순차적 효과 조합. Option, Either, Future 등이 Monad. → 함수형 패턴

O#

Object: 싱글톤 인스턴스를 정의하는 키워드. Companion Object 참고. → 클래스와 객체
Opaque Type (Scala 3): 외부에서는 다른 타입으로 보이지만 내부에서는 기반 타입과 동일한 타입. 런타임 오버헤드 없는 타입 안전성. → Scala 3 기능 비교
Option[A]: 값이 있거나(Some) 없음(None)을 나타내는 타입. null 대체. flatMap과 For Comprehension으로 안전하게 처리. → 기초 문법

L-O 핵심 포인트

lazy val: 비용이 큰 초기화를 첫 사용 시점까지 지연

Monad: flatMap + pure, 순차적 효과 조합의 핵심 추상화

Option: null 대신 Some/None으로 타입 안전한 처리

P#

Partial Function: 일부 입력에 대해서만 정의된 함수. Pattern Matching의 케이스와 같은 형태. collect 메서드에 활용. → 함수와 메서드
Pattern Matching: 값의 구조를 분석하고 데이터를 추출하는 기법. Case Class, Sealed 트레이트와 함께 사용. → 패턴 매칭 상세
Promise[T]: Future를 직접 완료할 수 있게 해주는 타입. 콜백 기반 API 래핑에 사용. → 동시성
Pure Function (순수 함수): 동일한 입력에 대해 항상 동일한 출력을 반환하고 부수 효과가 없는 함수. 참조 투명성 보장. 함수형 프로그래밍의 핵심. → 함수형 패턴

R#

Range: 숫자 범위를 나타내는 특수 시퀀스. 1 to 10, 1 until 10, 1 to 10 by 2 형태로 생성. 메모리에 모든 요소를 저장하지 않고 필요 시 계산. → 컬렉션
reduce: 컬렉션의 요소들을 하나의 값으로 축소하는 연산. fold와 달리 초기값 없이 첫 요소부터 시작. 빈 컬렉션에 사용 시 예외 발생. → 컬렉션
Referential Transparency: 표현식을 그 결과값으로 대체해도 프로그램 의미가 변하지 않는 속성. 순수 함수의 핵심 특성. Immutable 데이터와 관련. → 함수형 패턴

S#

Sealed: 같은 파일에서만 상속 가능하게 제한하는 수식어. Pattern Matching 완전성 검사에 사용. ADT 정의에 필수. → 패턴 매칭
Set: 중복이 없는 불변 컬렉션. 요소 포함 여부를 빠르게 확인 가능. union, intersect, diff 등 집합 연산 지원. → 컬렉션
Side Effect (부수 효과): 함수가 값을 반환하는 것 외에 외부 상태를 변경하거나 관찰 가능한 동작을 수행하는 것. 콘솔 출력, 파일 I/O, 전역 변수 변경 등. 함수형 프로그래밍에서는 최소화 권장. → 함수형 패턴
Singleton Object: Object 키워드로 정의된 유일한 인스턴스. Companion Object 참고.
String Interpolation (문자열 보간): 문자열 내에 변수나 표현식을 삽입하는 기능. s"Hello, $name", f"$pi%.2f", raw"\d+" 형태. → 기초 문법
summon (Scala 3): 주어진 타입의 암시적 인스턴스를 가져오는 함수. implicit implicitly를 대체. → 타입 클래스

T#

Tail Recursion: 함수의 마지막 연산이 자기 자신 호출인 재귀. 스택 오버플로우 없이 최적화 가능. @tailrec 어노테이션으로 검증. → 함수와 메서드
Trait: Java의 인터페이스와 유사하지만 구현을 포함할 수 있는 타입. 믹스인 상속 지원. Sealed와 함께 ADT 구성. → 클래스와 객체
Try[T]: 예외를 던질 수 있는 계산의 결과를 담는 타입. Success 또는 Failure. Either, Option과 유사한 에러 처리 패턴. → 기초 문법
Type Class: 기존 타입에 기능을 추가하는 패턴. Ad-hoc 다형성 구현. Functor, Monad 등이 대표적. → 타입 클래스 상세
Type Inference: 컴파일러가 타입을 자동으로 추론하는 기능. Scala의 강력한 타입 추론으로 보일러플레이트 감소. → 기초 문법
Type Lambda (Scala 3): 타입 생성자를 타입 매개변수로 전달할 수 있게 하는 기능. [X] =>> F[X] 형태. 고차 타입을 다룰 때 타입 매개변수 부분 적용에 유용. → 고급 타입 시스템
transparent inline (Scala 3): 반환 타입을 더 정밀하게 추론하는 inline. 각 호출 지점에서 정확한 타입이 추론됨. 타입별 최적화에 사용. → 매크로와 메타프로그래밍

P-T 핵심 포인트

Pattern Matching: match 표현식으로 데이터 구조 분해 및 분기

Sealed: 상속을 같은 파일로 제한, 패턴 매칭 완전성 검사

Type Class: 기존 타입에 기능 추가, Ad-hoc 다형성 구현

U#

Union Type (|): 여러 타입 중 하나를 나타내는 타입. Int | String. Intersection Type과 반대. Scala 3 전용. → 고급 타입 시스템
unapply: 패턴 매칭에서 객체를 분해하여 필드를 추출하는 메서드. Case Class에서 자동 생성. 커스텀 추출자(Extractor) 정의에 사용. → 패턴 매칭
Upper Bound (상한 경계): 타입 매개변수가 특정 타입의 하위 타입이어야 함을 지정. A <: B 형태. 타입 매개변수가 특정 메서드를 가짐을 보장. → 제네릭
Using (Scala 3): 암시적 매개변수를 선언하는 키워드. Implicit을 대체. Given과 짝을 이룸. → Scala 2 vs 3 비교

V#

Vector: 랜덤 접근이 빠른 불변 시퀀스. 32진 트리 구조로 대부분의 연산이 사실상 상수 시간. List보다 인덱스 접근이 필요한 경우에 적합. → 컬렉션
val: Immutable 값을 선언하는 키워드. var와 비교. Scala에서 기본 선택.
var: 가변 변수를 선언하는 키워드. val보다 권장되지 않음. → 기초 문법
Variance (변성): 타입 매개변수의 서브타이핑 관계. 공변(+A), 반공변(-A), 무공변. 컬렉션 설계에 중요. → 변성 상세

Y#

yield: For Comprehension에서 값을 생성하는 키워드. map 호출로 변환됨. → For Comprehension 상세

U-Y 핵심 포인트

Union Type (|): Scala 3 전용, Either 대신 간결한 타입 표현

val/var: val(불변) 우선, var(가변)는 최소화

Variance: 공변(+A), 반공변(-A)으로 타입 관계 정의

Z#

ZIO: 효과 시스템과 의존성 주입을 통합한 라이브러리. ZIO[R, E, A] 타입으로 환경, 에러, 결과를 명시. Cats Effect와 함께 Future의 대안으로 사용. → 함수형 패턴

다음 단계#

개념 이해 - Scala 핵심 개념
실습 예제 - 코드로 배우기
Spark 통합 - 빅데이터 처리
참고 자료 - 도서, 강좌, 커뮤니티
FAQ - 자주 묻는 질문

용어 사전

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Spark에서 사용되는 주요 용어와 개념을 정리합니다. 각 용어에서 관련 문서로 이동할 수 있습니다.

TL;DR

핵심 추상화: SparkSession(진입점) → Application → Job → Stage → Task

데이터 구조: RDD(저수준) < DataFrame(스키마, Row) < Dataset(타입 안전)

실행 모델: Transformation(지연 평가) + Action(실제 실행) = DAG 기반 실행

성능 핵심: Partition(분할 단위), Shuffle(데이터 재분배), Cache/Persist(재사용)

최적화 도구: Catalyst Optimizer(쿼리 최적화), Tungsten(실행 엔진), AQE(런타임 최적화)

핵심 개념#

Action

RDD/DataFrame의 실제 계산을 트리거하고 결과를 반환하는 연산. count(), collect(), show(), write() 등이 있다. → Transformation과 Action

핵심 구성요소

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Cluster: 여러 노드를 묶어 고가용성과 분산 처리를 제공하는 서버 그룹

Node: 클러스터를 구성하는 단일 Elasticsearch 서버 (Master, Data, Coordinating 역할)

Index: 문서들의 논리적 모음 (RDB의 테이블과 유사)

Document: JSON 형태의 데이터 단위 (RDB의 Row와 유사)

Shard: 인덱스를 수평 분할한 조각 (Primary/Replica로 구성)

대상 독자: Elasticsearch를 처음 접하는 개발자 선수 지식: JSON 기본 문법, REST API 개념

소요 시간: 약 25-30분

Elasticsearch의 핵심 구성요소인 Cluster, Node, Index, Document, Shard의 역할과 관계를 이해합니다.

핵심 구성요소

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Producer: 메시지를 발행하고 Partition을 선택하여 Broker로 전송

Consumer: Consumer Group 단위로 Partition에서 메시지를 읽고 Offset 관리

Broker: 메시지를 저장하고 복제하며 Leader/Follower 구조로 고가용성 제공

Topic: 메시지를 논리적으로 분류하는 채널

Partition: Topic을 물리적으로 분할하여 병렬 처리 가능하게 하는 단위

대상 독자: Kafka를 처음 접하는 개발자 또는 분산 메시지 시스템의 기본 개념을 학습하려는 분

선수 지식: 기본적인 네트워크 통신 개념, REST API 사용 경험, Spring Boot 기초

소요 시간: 약 25-30분

Kafka는 다섯 가지 핵심 구성요소로 이루어져 있습니다. Producer는 메시지를 발행하고, Consumer는 메시지를 소비하며, Broker는 메시지를 저장하고 전달합니다. Topic은 메시지를 논리적으로 분류하는 채널이고, Partition은 Topic을 물리적으로 분할하여 병렬 처리를 가능하게 합니다. 이 다섯 가지 구성요소가 어떻게 상호작용하는지 이해하면 Kafka 기반 시스템을 설계하고 운영하는 데 필요한 기초를 갖추게 됩니다.

높은 지연시간 진단

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

대상 상황: P99 응답시간이 SLA(500ms)를 초과 목표: 병목 구간을 찾아 해결 소요 시간: 15~30분 (문제 복잡도에 따라 상이) 성공 기준: P99 응답시간이 SLA 임계값(500ms) 이하로 복구됨

문제 상황#

Alert: HighP99Latency
Service: order-service
P99: 2.5s (Threshold: 500ms)
Duration: 10 minutes

진단 워크플로우#

graph TD
 A["1. 범위 파악<br>어떤 서비스? 언제부터?"]
 B["2. 구간 분석<br>어디서 느린가?"]
 C["3. 리소스 점검<br>CPU/메모리/DB?"]
 D["4. 근본 원인<br>코드? 쿼리? 외부?"]
 E["5. 해결"]

 A --> B --> C --> D --> E

Step 1: 범위 파악#

영향 범위 확인#

# 어떤 서비스가 느린가?
topk(5,
 histogram_quantile(0.99,
 sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
 )
)

# 언제부터 느려졌나?
histogram_quantile(0.99,
 sum by (le) (rate(http_request_duration_seconds_bucket{service="order-service"}[5m]))
)
# → Time range: Last 1 hour

특정 엔드포인트 확인#

# 엔드포인트별 P99
histogram_quantile(0.99,
 sum by (uri, le) (rate(http_request_duration_seconds_bucket{service="order-service"}[5m]))
)

결과: /orders POST 엔드포인트가 느림

환경 구성

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

소요 시간: 15분 선수 지식: Docker, Docker Compose 기본 이 문서를 읽으면: 로컬에 완전한 Observability 스택을 구축할 수 있습니다

전체 아키텍처#

graph TB
 APP["Spring Boot App"] --> |"metrics"| PROM["Prometheus"]
 APP --> |"logs"| LOKI["Loki"]
 APP --> |"traces"| TEMPO["Tempo"]

 PROM --> GF["Grafana"]
 LOKI --> GF
 TEMPO --> GF

 PROM --> AM["Alertmanager"]

Step 1: 디렉토리 구조 생성#

mkdir -p observability-stack/{prometheus/rules,grafana/{provisioning/datasources,provisioning/dashboards,dashboards},loki,promtail}
cd observability-stack

Step 2: Docker Compose 작성#

# docker-compose.yml
services:
 # 메트릭 수집
 prometheus:
 image: prom/prometheus:v2.50.0
 container_name: prometheus
 ports:
 - "9090:9090"
 volumes:
 - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
 - ./prometheus/rules:/etc/prometheus/rules
 - prometheus-data:/prometheus
 command:
 - '--config.file=/etc/prometheus/prometheus.yml'
 - '--storage.tsdb.path=/prometheus'
 - '--web.enable-lifecycle'
 - '--web.enable-remote-write-receiver'

 # 알림 관리
 alertmanager:
 image: prom/alertmanager:v0.26.0
 container_name: alertmanager
 ports:
 - "9093:9093"
 volumes:
 - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml

 # 시각화
 grafana:
 image: grafana/grafana:10.3.0
 container_name: grafana
 ports:
 - "3000:3000"
 environment:
 - GF_SECURITY_ADMIN_PASSWORD=admin
 - GF_AUTH_ANONYMOUS_ENABLED=true
 - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
 volumes:
 - ./grafana/provisioning:/etc/grafana/provisioning
 - ./grafana/dashboards:/var/lib/grafana/dashboards
 - grafana-data:/var/lib/grafana

 # 로그 수집
 loki:
 image: grafana/loki:2.9.0
 container_name: loki
 ports:
 - "3100:3100"
 volumes:
 - ./loki/loki.yml:/etc/loki/local-config.yaml
 - loki-data:/loki
 command: -config.file=/etc/loki/local-config.yaml

 # 로그 에이전트
 promtail:
 image: grafana/promtail:2.9.0
 container_name: promtail
 volumes:
 - ./promtail/promtail.yml:/etc/promtail/config.yml
 - /var/log:/var/log:ro
 - /var/lib/docker/containers:/var/lib/docker/containers:ro
 command: -config.file=/etc/promtail/config.yml

 # 분산 추적
 tempo:
 image: grafana/tempo:2.3.0
 container_name: tempo
 ports:
 - "4317:4317" # OTLP gRPC
 - "4318:4318" # OTLP HTTP
 - "3200:3200" # Tempo API
 volumes:
 - ./tempo/tempo.yml:/etc/tempo/config.yaml
 - tempo-data:/var/tempo
 command: -config.file=/etc/tempo/config.yaml

volumes:
 prometheus-data:
 grafana-data:
 loki-data:
 tempo-data:

Step 3: Prometheus 설정#

# prometheus/prometheus.yml
global:
 scrape_interval: 15s
 evaluation_interval: 15s

alerting:
 alertmanagers:
 - static_configs:
 - targets:
 - alertmanager:9093

rule_files:
 - /etc/prometheus/rules/*.yml

scrape_configs:
 - job_name: 'prometheus'
 static_configs:
 - targets: ['localhost:9090']

 - job_name: 'spring-app'
 metrics_path: '/actuator/prometheus'
 static_configs:
 - targets: ['host.docker.internal:8080']

Step 4: Loki 설정#

# loki/loki.yml
auth_enabled: false

server:
 http_listen_port: 3100

common:
 path_prefix: /loki
 storage:
 filesystem:
 chunks_directory: /loki/chunks
 rules_directory: /loki/rules
 replication_factor: 1
 ring:
 instance_addr: 127.0.0.1
 kvstore:
 store: inmemory

schema_config:
 configs:
 - from: 2020-10-24
 store: boltdb-shipper
 object_store: filesystem
 schema: v11
 index:
 prefix: index_
 period: 24h

limits_config:
 retention_period: 168h

Step 5: Promtail 설정#

# promtail/promtail.yml
server:
 http_listen_port: 9080

positions:
 filename: /tmp/positions.yaml

clients:
 - url: http://loki:3100/loki/api/v1/push

scrape_configs:
 - job_name: containers
 static_configs:
 - targets:
 - localhost
 labels:
 job: containerlogs
 __path__: /var/lib/docker/containers/*/*log

 pipeline_stages:
 - json:
 expressions:
 output: log
 stream: stream
 attrs:
 - json:
 expressions:
 tag:
 source: attrs
 - regex:
 expression: (?P<container_name>(?:[^|]*[^|]))
 source: tag
 - labels:
 container_name:
 stream:

Step 6: Tempo 설정#

# tempo/tempo.yml
server:
 http_listen_port: 3200

distributor:
 receivers:
 otlp:
 protocols:
 grpc:
 endpoint: 0.0.0.0:4317
 http:
 endpoint: 0.0.0.0:4318

storage:
 trace:
 backend: local
 local:
 path: /var/tempo/traces
 wal:
 path: /var/tempo/wal

metrics_generator:
 registry:
 external_labels:
 source: tempo
 storage:
 path: /var/tempo/generator/wal
 remote_write:
 - url: http://prometheus:9090/api/v1/write
 send_exemplars: true

Step 7: Grafana 데이터소스 설정#

# grafana/provisioning/datasources/datasources.yml
apiVersion: 1
datasources:
 - name: Prometheus
 type: prometheus
 access: proxy
 url: http://prometheus:9090
 isDefault: true

 - name: Loki
 type: loki
 access: proxy
 url: http://loki:3100

 - name: Tempo
 type: tempo
 access: proxy
 url: http://tempo:3200
 jsonData:
 tracesToLogsV2:
 datasourceUid: loki
 filterByTraceID: true
 tracesToMetrics:
 datasourceUid: prometheus
 serviceMap:
 datasourceUid: prometheus

Step 8: Alertmanager 설정#

mkdir -p alertmanager

# alertmanager/alertmanager.yml
global:
 resolve_timeout: 5m

route:
 receiver: 'default'
 group_by: ['alertname', 'job']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 4h

receivers:
 - name: 'default'
 webhook_configs:
 - url: 'http://localhost:5001/'
 send_resolved: true

Step 9: 스택 실행#

docker compose up -d

예상 출력:

환경 설정

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

대상 독자: 로컬에서 Kubernetes를 실습하고 싶은 개발자 선수 지식: Docker 기본 이 문서를 읽으면: Minikube 또는 Kind로 로컬 Kubernetes 환경을 구성할 수 있습니다

TL;DR

Minikube: 단일 노드, 초보자에게 권장, 다양한 애드온 지원

Kind: 다중 노드 가능, CI/CD에 적합, 빠른 클러스터 생성

Docker Desktop: macOS/Windows에서 가장 간단한 설정

로컬 Kubernetes 옵션 비교#

도구	장점	단점	적합한 경우
Minikube	애드온 풍부, 문서 많음	단일 노드만	학습, 개발
Kind	빠름, 다중 노드, CI 친화	애드온 적음	CI/CD, 테스트
Docker Desktop	설치 쉬움	리소스 많이 사용	빠른 시작
k3d	경량, 빠름	프로덕션과 차이	빠른 테스트

Minikube 설치#

설치#

macOS

# Homebrew로 설치
brew install minikube

# 버전 확인
minikube version

Linux

# 바이너리 다운로드
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

# 설치
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# 버전 확인
minikube version

Windows

# Chocolatey로 설치
choco install minikube

# 또는 수동 설치
# https://minikube.sigs.k8s.io/docs/start/

클러스터 시작#

# 기본 설정으로 시작
minikube start

# 리소스 지정
minikube start --cpus=4 --memory=8192

# 특정 Kubernetes 버전 사용
minikube start --kubernetes-version=v1.29.0

# 드라이버 지정
minikube start --driver=docker

사용 가능한 드라이버는 다음과 같습니다.

Aggregate 경계 정하기

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

해결하는 문제: Aggregate를 너무 크게 만들어 성능 이슈가 발생하거나, 너무 작게 만들어 일관성이 깨지는 상황 소요 시간: 약 30분 전제 조건: Aggregate 심화 문서를 읽었다고 가정

성공 기준
이 가이드를 완료하면 다음을 할 수 있습니다:

불변식을 식별하여 Aggregate 경계를 결정

4가지 판단 질문으로 Entity 포함 여부를 결정

경계가 잘못되었을 때의 신호를 인식

1. 핵심 불변식 식별하기#

불변식(Invariant)은 항상 참이어야 하는 비즈니스 규칙입니다. Aggregate 경계를 정하는 가장 중요한 기준입니다.

1.1 비즈니스 규칙 나열하기#

대상 도메인의 비즈니스 규칙을 모두 나열하라:

Consumer Lag 진단 및 해결

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Consumer Lag가 발생했을 때 원인을 진단하고 해결하는 방법을 단계별로 안내합니다.

TL;DR

Consumer Lag: Consumer가 읽지 못한 메시지 수 (Producer 속도 > Consumer 처리 속도)

진단: kafka-consumer-groups.sh로 Lag 확인, 모니터링 도구로 추이 분석

해결: Consumer 수 증가, 처리 로직 최적화, Partition 수 조정, 배치 설정 튜닝

Consumer Lag란?#

Consumer Lag는 Producer가 발행한 메시지 중 Consumer가 아직 읽지 못한 메시지의 수입니다. Lag가 지속적으로 증가하면 메시지 처리 지연이 발생하고, 최악의 경우 메시지가 보관 기간을 초과하여 삭제될 수 있습니다.

프로젝트 설정

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

프로젝트 설정#

TL;DR

DDD 계층형 아키텍처(Domain, Application, Infrastructure, Interfaces)로 패키지 구성

Spring Boot 3.2.x + Spring Kafka + JPA 기반 의존성 설정

AggregateRoot, DomainEvent, Entity 기반 클래스 구현

Docker Compose로 Kafka + PostgreSQL 개발 환경 구축

대상 독자 및 선수 지식#

항목	요구 수준
대상 독자	DDD 패턴을 Spring Boot에 적용하려는 백엔드 개발자
Java	Java 17+ 문법, Record, Stream API
Spring Boot	Spring Boot 기본 구조, DI, @Service, @Repository
Gradle	Kotlin DSL 기본 문법
Docker	docker-compose up/down 실행 경험

DDD 예제 프로젝트의 구조와 의존성을 설정합니다.

환경 구성

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Spring Boot에서 Kafka를 사용하기 위한 환경 설정 레퍼런스입니다.

TL;DR

Kafka 실행: Docker Compose로 KRaft 모드 Kafka 3.6.1 실행

의존성: spring-kafka, spring-boot-starter-web 추가

기본 설정: bootstrap-servers, Serializer/Deserializer, group-id 설정

프로덕션: acks: all, enable.idempotence: true로 안정성 확보

대상 독자 및 선수 지식#

항목	설명
대상 독자	Spring Boot 프로젝트에서 Kafka 환경을 구성하려는 개발자
선수 지식	Docker 기본 사용법, Gradle 또는 Maven 빌드 도구, Spring Boot 설정 파일(application.yml)
필수 도구	Docker Desktop 또는 Docker Engine, JDK 17+, IDE (IntelliJ IDEA 권장)
예상 소요 시간	약 15분

Quick Start를 완료했다면 이미 기본 환경을 구성한 것입니다. 이 문서는 설정 상세 내용과 프로덕션 환경 구성을 위한 참조 문서입니다.

환경 설정

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Docker Compose로 Elasticsearch 8.11 + Kibana 환경을 빠르게 구성합니다

Spring Boot 3.2 + Spring Data Elasticsearch로 연동 설정을 완료합니다

Nori 분석기를 설치하여 한글 검색을 준비합니다

전체 소요 시간: 약 15분

버전 정보

Elasticsearch / Kibana: 8.11.0

Spring Boot: 3.2.0

Spring Data Elasticsearch: 5.2.x (Spring Boot 3.2에 포함)

Java: 17+

Docker로 Elasticsearch + Kibana를 구성하고, Spring Boot 프로젝트를 설정합니다.

Docker 환경 구성#

docker-compose.yml#

docker/elasticsearch/docker-compose.yml 파일:

version: '3.8'

services:
 elasticsearch:
 image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
 container_name: elasticsearch
 environment:
 - discovery.type=single-node
 - xpack.security.enabled=false
 - xpack.security.enrollment.enabled=false
 - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
 ports:
 - "9200:9200"
 - "9300:9300"
 volumes:
 - elasticsearch-data:/usr/share/elasticsearch/data
 healthcheck:
 test: ["CMD-SHELL", "curl -s http://localhost:9200/_cluster/health | grep -q '\"status\":\"green\"\\|\"status\":\"yellow\"'"]
 interval: 10s
 timeout: 10s
 retries: 10
 networks:
 - elastic

 kibana:
 image: docker.elastic.co/kibana/kibana:8.11.0
 container_name: kibana
 environment:
 - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
 ports:
 - "5601:5601"
 depends_on:
 elasticsearch:
 condition: service_healthy
 networks:
 - elastic

volumes:
 elasticsearch-data:
 driver: local

networks:
 elastic:
 driver: bridge

설정 설명#

설정	값	설명
`discovery.type`	single-node	단일 노드 모드 (개발용)
`xpack.security.enabled`	false	보안 비활성화 (개발용)
`ES_JAVA_OPTS`	-Xms512m -Xmx512m	JVM 힙 메모리 (최소=최대)
`9200`	HTTP API 포트	REST API 통신용
`9300`	Transport 포트	노드 간 통신용

프로덕션 환경에서는 반드시 보안을 활성화하고, 적절한 메모리를 할당하세요.

환경 설정

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Coursier로 JDK, sbt, Scala CLI를 한 번에 설치

sbt는 Scala의 표준 빌드 도구로 컴파일, 테스트, 의존성 관리 담당

IntelliJ IDEA 또는 VS Code + Metals로 IDE 설정

프로젝트 구조: build.sbt (설정) + src/main/scala/ (소스) + src/test/scala/ (테스트)

대상 독자: Scala 프로그래밍을 처음 시작하는 개발자

선수 지식:

기본적인 터미널/명령줄 사용법
Java 또는 다른 JVM 언어 경험 (권장)
IDE 사용 경험

Scala 개발 환경을 설정하는 방법을 상세히 설명합니다. Scala 프로그래밍을 시작하려면 JDK, sbt(Scala Build Tool), 그리고 IDE가 필요합니다. 이 문서에서는 각 도구의 설치 방법과 설정 과정을 단계별로 안내합니다.

환경 설정

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Gradle 의존성: spark-core_2.13:3.5.1, spark-sql_2.13:3.5.1

로깅 충돌 방지: exclude group: 'org.slf4j' 필수

SparkSession: getOrCreate()로 싱글톤 관리

Windows: winutils 설정 필요

대상 독자 및 선수 지식#

구분	내용
대상 독자	Java/Spring Boot 프로젝트에 Spark를 도입하려는 개발자
선수 지식	Java 17, Gradle 기본, Spring Boot 경험 (선택)
학습 목표	로컬 환경에서 Spark 애플리케이션을 실행할 수 있다
예상 소요 시간	약 15분

Java/Spring Boot 프로젝트에서 Spark를 사용하기 위한 환경을 구성합니다.

순수 Java 프로젝트#

가장 간단한 구성입니다.

전술적 설계

d8lzz1gpw@mozmail.com (kimbenji) — Tue, 17 Feb 2026 00:00:00 +0000

대상 독자: DDD 빌딩 블록을 코드로 구현하고 싶은 백엔드 개발자 선수 지식: 전략적 설계를 읽었거나 Bounded Context 개념에 대한 이해 소요 시간: 약 40분 핵심 질문: “도메인 모델을 어떤 패턴으로 구현해야 하는가?”

요약
전술적 설계 빌딩 블록: Entity(식별자로 구분) + Value Object(값으로 구분) → Aggregate(일관성 경계) + Repository(영속화) + Domain Service(도메인 로직) + Domain Event(이벤트 통신)

도메인 모델을 구체적으로 구현하기 위한 패턴들이 바로 전술적 설계입니다. 전략적 설계가 “큰 그림"을 그리는 것이라면, 전술적 설계는 “구체적인 구현 방법"을 제시합니다.

Bounded Context 식별하기

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

해결하는 문제: 시스템을 어떻게 나눠야 할지 모르거나, Context 경계를 잘못 정해서 팀 간 의존성이 높아진 상황 소요 시간: 약 25분 전제 조건: 전략적 설계 문서를 읽었다고 가정

성공 기준
이 가이드를 완료하면 다음을 할 수 있습니다:

3가지 신호로 Context 경계를 식별

도메인 전문가 인터뷰로 경계 검증

잘못된 경계의 증상을 인식하고 수정

1. Context 경계가 필요한 신호 감지하기#

다음 3가지 신호를 확인하여 Bounded Context 분리가 필요한지 판단하세요.

1.1 신호 1: 같은 용어, 다른 의미#

도메인 전문가와 대화할 때 “그 X 말고 다른 X요"라는 말이 나오면 Context 분리 신호입니다. 이 신호를 포착하세요.

Future 에러 처리

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

비동기 코드에서 예외를 안전하게 처리하고 디버깅하는 방법을 안내합니다.

소요 시간: 약 15-20분

TL;DR

recover/recoverWith: 특정 예외를 처리하고 대체값 반환

transform: 성공/실패 모두 변환

onComplete: 부수 효과 (로깅 등)에만 사용

절대 하지 말 것: Await.result로 예외를 동기적으로 던지기

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

Future에서 발생한 예외가 조용히 사라지는 경우
비동기 코드의 에러를 어떻게 처리해야 할지 모를 때
recover, recoverWith, transform 중 어떤 것을 사용해야 할지 결정이 필요할 때

증상#

import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global

val future = Future {
 throw new RuntimeException("Something went wrong")
}
// 프로그램은 정상 종료되지만, 예외는 어디로 갔을까?

이 가이드가 다루지 않는 것#

Future의 기본 개념: 동시성 개념 문서를 참조하세요
Cats Effect IO / ZIO의 에러 처리: 해당 라이브러리 문서를 참조하세요
액터 시스템(Akka)의 에러 처리: Akka 문서를 참조하세요

시작하기 전에#

다음 환경이 준비되어 있는지 확인하세요:

데이터 스큐 해결하기

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

예상 소요 시간: 약 20분

TL;DR

진단: Spark UI Stages 탭에서 Task Duration Min/Max 비교 (10배 이상 차이 = 스큐)

AQE 활성화: spark.sql.adaptive.skewJoin.enabled=true (Spark 3.0+)

수동 해결: Salting 기법으로 핫 키 분산

문제 정의#

Spark 작업이 대부분 빠르게 완료되지만 일부 Task만 오래 걸리는 현상이 발생합니다:

Stage 3: 199/200 tasks completed... (마지막 1개가 수십 분째 실행 중)

이는 데이터 스큐(Data Skew) - 특정 키에 데이터가 집중되어 해당 파티션만 과부하 상태가 됩니다.

전제 조건#

항목	요구 사항	확인 방법
Spark 버전	2.4+ (AQE는 3.0+)	`spark-submit --version`
Spark UI	접근 가능	브라우저에서 `http://localhost:4040` 열기
데이터	조인/그룹화에 사용되는 키 컬럼 존재	스키마에서 키 컬럼 확인

지원 환경: Linux, macOS, Windows (WSL2 권장)

리소스 최적화

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

목표: 적절한 CPU/메모리 설정을 찾아 리소스 효율성을 높입니다 예상 시간: 45분

이 가이드의 범위
다루는 내용: 리소스 사용량 측정, requests/limits 적정값 산정, 스로틀링/OOM 해결

다루지 않는 내용: 자동 스케일링(스케일링 참조), Pod 시작 문제(Pod 트러블슈팅 참조)

시작하기 전에#

다음 조건을 확인하세요.

1. kubectl 설치 및 버전 확인#

kubectl version --client

성공 시 출력:

Client Version: v1.28.0

2. Metrics Server 설치 확인#

kubectl top nodes

성공 시 출력:

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
node-1 250m 12% 1024Mi 50%

오류가 발생하면 Metrics Server를 설치하세요.

메모리 문제 해결

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

OutOfMemoryError나 GC 문제가 발생할 때 원인을 진단하고 해결하는 방법을 안내합니다.

소요 시간: 약 20-40분 (GC 로그 분석 시 추가 10분)

이 가이드의 범위
다루는 내용: 힙 메모리 설정, Circuit Breaker, Field Data 최적화, GC 튜닝

다루지 않는 내용: 노드 추가, 하드웨어 업그레이드는 클러스터 관리를 참조하세요.

TL;DR

힙 메모리: 전체 메모리의 50% 이하, 최대 31GB

Circuit Breaker: 메모리 과사용 방지 설정 확인

필드 데이터: text 필드 집계 피하기, doc_values 활용

GC 튜닝: G1GC 사용, 로그 분석으로 문제 파악

시작하기 전에#

다음 조건을 확인하세요:

Pod

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 한 세대#

Pod를 아파트 한 세대에 비유하면 이해하기 쉽습니다:

아파트 세대 비유	Kubernetes Pod	역할
아파트 한 세대	Pod	최소 거주/배포 단위
세대 내 거주자들	Containers	함께 살며 자원 공유
세대 현관문	Pod IP	외부에서 접근하는 주소
거실/주방 공유	Network 공유	같은 Pod 내 localhost 통신
공용 창고	Volume	거주자들이 함께 사용하는 저장 공간
각자 방	Container 격리	개별 파일시스템, 프로세스
이사 시 함께 이동	공동 생명주기	Pod 삭제 시 모든 컨테이너 종료
원룸 vs 투룸	단일/멀티 컨테이너	대부분 원룸(1 컨테이너) 권장

이처럼 Pod는 “한 세대에 여러 사람이 함께 살면서 주방과 거실을 공유"하는 것과 같습니다.

RDD 기초

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

RDD(Resilient Distributed Dataset)는 분산 불변 데이터 컬렉션으로 Spark의 기본 데이터 추상화

Transformation(지연 평가)과 Action(즉시 실행)으로 데이터 처리

Lineage를 통해 장애 발생 시 자동 복구 가능

현재는 DataFrame/Dataset을 권장하지만, 저수준 제어가 필요할 때 RDD 사용

대상 독자: Java/Spring 개발자, Spark 기본 개념을 학습하려는 초급자

선수 지식:

Java 컬렉션 API (List, Map 등)
람다 표현식 및 함수형 프로그래밍 기초
아키텍처 문서 이해

소요 시간: 약 25-30분

RDD는 Spark의 가장 기본적인 데이터 추상화입니다. DataFrame과 Dataset의 기반이 되는 저수준 API로, Spark의 동작 원리를 이해하는 데 필수적입니다.

Traffic (트래픽)

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 병원 외래 환자 수#

Traffic을 병원 외래 환자 방문량에 비유하면 이해하기 쉽습니다:

병원 외래 비유	Traffic 개념	의미
시간당 방문 환자 수	RPS (초당 요청)	현재 서비스 부하
일일 진료 건수	일일 처리량	기간별 총 처리량
동시 진료 환자 수	동시 연결	현재 처리 중인 요청
평소 대비 방문 증가	트래픽 스파이크	비정상적 부하 감지
방문 환자 급감	트래픽 급락	장애 또는 문제 신호
진료과별 환자 수	엔드포인트별 트래픽	세부 분석
병원 수용 능력	용량 계획	최대 처리 가능량

이처럼 병원이 환자 방문 패턴을 분석하여 의료진을 배치하듯, 트래픽 분석으로 시스템 용량을 계획합니다.

데이터 모델링

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Mapping: 문서 구조를 정의하는 스키마 (RDB의 테이블 정의와 유사)

text: 풀텍스트 검색용, Analyzer로 토큰화됨

keyword: 정확한 값 매칭, 정렬/집계용

Analyzer: 텍스트를 검색 가능한 토큰으로 변환 (한글은 Nori 사용)

비정규화: JOIN 없으므로 관련 데이터를 한 문서에 포함

대상 독자: Elasticsearch 검색 기능을 사용하려는 개발자 선수 지식: 핵심 구성요소, JSON 기본 문법

소요 시간: 약 25-30분

전체 비유: 도서관의 도서 분류 시스템#

데이터 모델링을 도서관의 도서 분류 체계에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
도서 분류 규칙 (DDC, KDC)	Mapping	책을 어떻게 분류하고 정리할지 정의
책 내용으로 검색	text 타입	“인공지능"을 검색하면 관련 내용 포함 도서 반환
청구기호로 정확히 찾기	keyword 타입	“005.133-P99” 정확히 일치하는 책 찾기
색인 담당 사서	Analyzer	책 내용을 읽고 핵심 키워드 추출하여 색인 카드 작성
한 책에 관련 정보 모두 기록	비정규화	저자, 출판사, 분류 정보를 한 카드에 기재
Object (저자 정보)	단순 중첩	저자명, 생년 등 관련 정보 묶음
Nested (시리즈 정보)	관계 유지	1권-2024년, 2권-2025년 각각 독립적 관계 유지

이처럼 Mapping은 도서관에서 “어떤 기준으로 책을 분류하고 색인할 것인가"를 정하는 것과 같습니다.

메시지 흐름

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Producer가 메시지를 직렬화하고 Partitioner가 대상 Partition을 결정

Key가 있으면 같은 Key는 같은 Partition으로 전송되어 순서 보장

Broker는 메시지를 Partition에 저장하고 ISR에 복제 후 ACK 반환

Consumer는 Pull 방식으로 메시지를 가져와 처리 후 Offset 커밋

At-Most-Once, At-Least-Once, Exactly-Once 세 가지 전달 보장 수준 제공

대상 독자: Kafka의 기본 구성요소를 이해한 개발자, 메시지 전달 과정의 상세 동작을 학습하려는 분

선수 지식: 핵심 구성요소의 Producer, Consumer, Broker, Topic, Partition 개념

소요 시간: 약 20분

메트릭 기초

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 병원 의료 장비#

메트릭 타입을 병원의 의료 장비에 비유하면 이해하기 쉽습니다:

병원 장비 비유	메트릭 타입	역할
체온계	Gauge	현재 값 측정 (오르내림 가능)
만보기	Counter	누적 카운트 (증가만 가능)
혈압 분포 차트	Histogram	값의 분포 측정
체온 37.2도	Gauge 값	현재 상태
오늘 총 5000보	Counter 값	누적 합계
환자 80%가 혈압 120 이하	Percentile	분포의 백분위
일일 환자 수 변화	rate()	시간당 변화율
환자 평균 대기시간	avg()	집계 연산

이처럼 체온계는 “현재 온도"를, 만보기는 “누적 걸음수"를 측정하듯, 메트릭 타입은 데이터의 본질에 맞게 선택해야 합니다.

제어 구조

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 교통 시스템#

Scala의 제어 구조를 교통 시스템에 비유하면 이해하기 쉽습니다:

교통 시스템 비유	Scala 개념	역할
교차로 (갈림길 선택)	if 표현식	조건에 따라 경로 선택
순환버스 (정해진 경로 순회)	for 표현식	컬렉션 순회 및 변환
환승 연계 (A→B→C 연결)	for comprehension	다중 컬렉션 조합
정류장 안내 (목적지별 분류)	match 표현식	값/타입에 따른 분기
무한 루프선 (조건 만족까지)	while 루프	가변 상태 기반 반복
티켓 발권 (입력→출력)	표현식	모든 것이 값을 반환

이처럼 교통 시스템이 승객을 목적지로 안내하듯, 제어 구조는 데이터를 원하는 결과로 흐르게 합니다.

집계 연산자

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 병원 통계 분석#

PromQL 집계 연산자를 병원 통계 분석에 비유하면 이해하기 쉽습니다:

병원 통계 비유	집계 연산자	역할
전체 환자 수 합계	sum	모든 값 더하기
평균 진료 시간	avg	평균값 계산
병동별 환자 수	count	개수 세기
최고/최저 혈압	max/min	극값 찾기
진료 건수 상위 5개 과	topk	상위 N개 추출
진료과별 통계	by	그룹별 집계
개인정보 제외 통계	without	특정 라벨 제외 집계
환자 연령 분포	quantile	분위수 계산

이처럼 병원에서 진료과별, 병동별로 통계를 집계하듯, PromQL 집계 연산자로 메트릭을 요약합니다.

헥사고날 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 테스트 용이성과 외부 의존성 교체를 고려하는 개발자 선수 지식: 계층형 아키텍처의 한계 이해 소요 시간: 약 20분

Ports and Adapters 패턴이라고도 불립니다. 애플리케이션의 핵심을 외부 세계로부터 완전히 격리시키는 아키텍처입니다. 헥사고날 아키텍처의 핵심 아이디어는 비즈니스 로직을 중심에 두고, 외부와의 모든 상호작용을 Port와 Adapter를 통해 처리한다는 것입니다. 이렇게 하면 외부 기술이 바뀌어도 핵심 비즈니스 로직은 영향을 받지 않습니다.

한 줄 요약#

애플리케이션은 육각형 안에 있고, 외부와의 모든 연결은 Port와 Adapter로 처리합니다. 이를 통해 비즈니스 로직과 기술적 세부사항을 완벽하게 분리할 수 있습니다.

FAQ

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

일반#

Q: Monitoring과 Observability의 차이는?#

Monitoring: 사전에 정의한 지표를 감시 (“이 값이 임계치를 넘었는가?”)

Observability: 시스템 내부 상태를 외부에서 파악할 수 있는 능력 (“왜 이 문제가 발생했는가?”)

Monitoring은 Observability의 일부입니다. Observability는 예상치 못한 문제도 분석할 수 있는 능력을 포함합니다.

Q: 3요소(Metrics, Logs, Traces) 중 뭘 먼저 도입해야 하나?#

권장 순서:

Metrics - 시스템 상태 파악, 알림 설정
Logs - 에러 원인 분석
Traces - 분산 시스템 흐름 분석

단일 서비스라면 Metrics + Logs로 충분할 수 있습니다. 마이크로서비스라면 Traces가 필수입니다.

Spring Boot 메트릭

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

소요 시간: 20분 선수 지식: Spring Boot, 환경 구성 이 문서를 읽으면: Spring Boot 애플리케이션에 Observability를 적용할 수 있습니다

Step 1/8: 의존성 추가 (2분)#

// build.gradle.kts
dependencies {
 // Actuator + Prometheus
 implementation("org.springframework.boot:spring-boot-starter-actuator")
 implementation("io.micrometer:micrometer-registry-prometheus")

 // Tracing
 implementation("io.micrometer:micrometer-tracing-bridge-otel")
 implementation("io.opentelemetry:opentelemetry-exporter-otlp")

 // Logging (Loki)
 implementation("com.github.loki4j:loki-logback-appender:1.4.2")
}

Step 2/8: application.yml 설정 (3분)#

spring:
 application:
 name: order-service

management:
 endpoints:
 web:
 exposure:
 include: health,info,prometheus,metrics
 endpoint:
 health:
 show-details: always
 metrics:
 tags:
 application: ${spring.application.name}
 distribution:
 percentiles-histogram:
 http.server.requests: true
 slo:
 http.server.requests: 50ms, 100ms, 200ms, 500ms, 1s
 tracing:
 sampling:
 probability: 1.0
 otlp:
 tracing:
 endpoint: http://localhost:4318/v1/traces

logging:
 pattern:
 level: "%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]"

Step 3/8: Loki 로그 설정 (3분)#

<!-- src/main/resources/logback-spring.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <include resource="org/springframework/boot/logging/logback/defaults.xml"/>

 <springProperty scope="context" name="appName" source="spring.application.name"/>

 <!-- Console Appender -->
 <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
 <encoder>
 <pattern>%d{ISO8601} %5p [${appName},%X{traceId:-},%X{spanId:-}] --- [%t] %-40.40logger{39} : %m%n</pattern>
 </encoder>
 </appender>

 <!-- Loki Appender -->
 <appender name="LOKI" class="com.github.loki4j.logback.Loki4jAppender">
 <http>
 <url>http://localhost:3100/loki/api/v1/push</url>
 </http>
 <format>
 <label>
 <pattern>app=${appName},host=${HOSTNAME},level=%level</pattern>
 </label>
 <message>
 <pattern>{"timestamp":"%d{ISO8601}","level":"%level","logger":"%logger","message":"%msg","traceId":"%X{traceId:-}","spanId":"%X{spanId:-}"}</pattern>
 </message>
 </format>
 </appender>

 <root level="INFO">
 <appender-ref ref="CONSOLE"/>
 <appender-ref ref="LOKI"/>
 </root>
</configuration>

중간 확인 (Step 1~3 완료)#

build.gradle.kts에 의존성 추가됨
application.yml에 management 설정 완료
logback-spring.xml 파일 생성됨
./gradlew bootRun 실행 후 http://localhost:8080/actuator/prometheus 접속 시 메트릭 표시

Step 4/8: 커스텀 메트릭 추가 (5분)#

@RestController
@RequiredArgsConstructor
@RequestMapping("/orders")
public class OrderController {
 private final MeterRegistry meterRegistry;
 private final OrderService orderService;

 // Counter: 주문 수
 private Counter orderCounter(String status) {
 return Counter.builder("orders_total")
 .tag("status", status)
 .description("Total number of orders")
 .register(meterRegistry);
 }

 // Gauge: 처리 중인 주문
 private final AtomicInteger ordersInProgress = new AtomicInteger(0);

 @PostConstruct
 void registerGauge() {
 Gauge.builder("orders_in_progress", ordersInProgress, AtomicInteger::get)
 .description("Orders currently being processed")
 .register(meterRegistry);
 }

 @PostMapping
 public ResponseEntity<Order> createOrder(@RequestBody OrderRequest request) {
 ordersInProgress.incrementAndGet();
 try {
 // Timer로 처리 시간 측정
 return Timer.builder("order_processing_duration_seconds")
 .tag("type", request.getType())
 .publishPercentileHistogram()
 .register(meterRegistry)
 .record(() -> {
 Order order = orderService.create(request);
 orderCounter("success").increment();
 return ResponseEntity.ok(order);
 });
 } catch (Exception e) {
 orderCounter("failed").increment();
 throw e;
 } finally {
 ordersInProgress.decrementAndGet();
 }
 }
}

Step 5/8: 수동 트레이싱 (3분)#

@Service
@RequiredArgsConstructor
@Slf4j
public class OrderService {
 private final Tracer tracer;
 private final PaymentClient paymentClient;
 private final InventoryClient inventoryClient;

 public Order create(OrderRequest request) {
 // 현재 Span에 태그 추가
 Span currentSpan = tracer.currentSpan();
 if (currentSpan != null) {
 currentSpan.tag("order.type", request.getType());
 currentSpan.tag("order.items", String.valueOf(request.getItems().size()));
 }

 // 새 Span 생성
 Span inventorySpan = tracer.nextSpan().name("checkInventory").start();
 try (Tracer.SpanInScope ws = tracer.withSpan(inventorySpan)) {
 inventoryClient.check(request.getItems());
 inventorySpan.event("Inventory checked");
 } finally {
 inventorySpan.end();
 }

 // 결제 처리
 Span paymentSpan = tracer.nextSpan().name("processPayment").start();
 try (Tracer.SpanInScope ws = tracer.withSpan(paymentSpan)) {
 paymentClient.process(request.getPayment());
 paymentSpan.event("Payment processed");
 } finally {
 paymentSpan.end();
 }

 log.info("Order created: {}", request.getId());
 return new Order(request);
 }
}

중간 확인 (Step 4~5 완료)#

OrderController에 Counter, Gauge, Timer 메트릭 추가됨
OrderService에 수동 Span 생성 코드 추가됨
컴파일 오류 없이 빌드 성공: ./gradlew build

Step 6/8: 메트릭 확인 (2분)#

Prometheus 엔드포인트#

curl http://localhost:8080/actuator/prometheus

예상 출력:

메트릭 카디널리티 최적화

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

대상 상황: Prometheus 메모리/스토리지 급증, 쿼리 느림 목표: 불필요한 시계열을 줄여 비용 최적화 소요 시간: 30분~1시간 (분석 및 수정 복잡도에 따라 상이) 성공 기준: 시계열 수가 목표치 이하로 감소하고 메모리 사용량이 안정화됨

문제 상황#

Alert: PrometheusHighCardinality
Active Series: 2,500,000 (Threshold: 1,000,000)
Memory Usage: 32GB

카디널리티란?#

카디널리티 = 고유한 시계열 수

http_requests_total{method="GET", status="200", path="/api/users"} # 1개
http_requests_total{method="GET", status="200", path="/api/users/123"} # 또 1개!
http_requests_total{method="GET", status="200", path="/api/users/456"} # 또 1개!

문제: path에 user_id가 들어가면 사용자 수만큼 시계열 생성

FAQ

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Kubernetes 학습과 운영에서 자주 묻는 질문과 답변을 정리합니다.

시작하기 전에#

Q: Kubernetes를 배우기 전에 알아야 할 것은?#

A: 다음 지식이 있으면 학습이 수월합니다:

필수: Docker 기본 (이미지 빌드, 컨테이너 실행)
필수: Linux 기본 명령어 (cd, ls, cat, grep)
권장: YAML 문법, 네트워크 기초 (IP, 포트, DNS)

Q: 로컬에서 Kubernetes를 어떻게 실습하나요?#

A: 세 가지 방법이 있습니다:

도구	특징	권장 대상
Minikube	가장 쉬움, 문서 많음	초보자
Kind	빠른 시작, 다중 노드	CI/CD
Docker Desktop	설치 간편	macOS/Windows

초보자라면 Minikube로 시작하세요: minikube start

기본 예제

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

대상 독자: Kubernetes 핵심 리소스를 실습하고 싶은 개발자 선수 지식: Pod, Deployment, Service 개념 이 문서를 읽으면: Pod, Deployment, Service, ConfigMap을 직접 생성하고 관리할 수 있습니다

TL;DR

Nginx Deployment를 생성하고 Service로 노출합니다

ConfigMap으로 설정을 주입합니다

롤링 업데이트와 롤백을 실습합니다

사전 준비#

다음이 필요합니다:

로컬 Kubernetes 클러스터 (Minikube 또는 Kind)
kubectl

# 클러스터 상태 확인
kubectl cluster-info

실습 1: Deployment와 Service#

Deployment 생성#

웹 서버를 배포합니다.

# nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx
 labels:
 app: nginx
spec:
 replicas: 3
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx:1.25
 ports:
 - containerPort: 80
 resources:
 requests:
 memory: "64Mi"
 cpu: "100m"
 limits:
 memory: "128Mi"
 cpu: "200m"

# Deployment 생성
kubectl apply -f nginx-deployment.yaml

# 상태 확인
kubectl get deployment nginx
kubectl get pods -l app=nginx

예상 출력:

FAQ

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

ES vs RDB: 풀텍스트 검색/로그 분석은 ES, 트랜잭션/JOIN은 RDB

text vs keyword: text는 검색용(분석됨), keyword는 필터/정렬용(분석 안 됨)

성능 문제: Filter Context 사용, 필요한 필드만 반환, search_after 페이지네이션

한글 검색: Nori 분석기 설치 필수

흔한 에러: 대부분 디스크 부족, 메모리 부족, 타입 불일치가 원인

자주 묻는 질문과 답변을 정리했습니다.

기본 개념#

Elasticsearch vs RDB, 언제 무엇을 써야 하나요?#

상황	권장
풀텍스트 검색	Elasticsearch
트랜잭션 무결성 필요	RDB
복잡한 JOIN	RDB
실시간 집계/분석	Elasticsearch
일반 CRUD	RDB
대용량 로그 저장	Elasticsearch

일반적인 패턴: RDB를 메인 저장소로, Elasticsearch를 검색용 보조 저장소로 사용.

FAQ

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

자주 묻는 질문과 흔히 발생하는 문제의 해결 방법을 제공합니다.

TL;DR

Java 버전: Spark 3.5는 Java 8, 11, 17 지원 (21은 미지원)

DataFrame vs RDD: DataFrame 권장 (자동 최적화, 간결한 API)

흔한 오류: OutOfMemoryError(메모리 증가), NotSerializableException(직렬화 가능 객체만 사용)

성능 튜닝: 셔플 최소화, 적절한 파티션 수(코어 x 2~4), 브로드캐스트 조인 활용

디버깅: Spark UI의 Stages 탭에서 Task 분포와 스큐 확인

일반 질문#

Spark는 어떤 Java 버전을 지원하나요?

Spark 3.5는 Java 8, 11, 17을 지원합니다. Java 21은 아직 공식 지원되지 않습니다.

Producer 성능 최적화

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Producer의 처리량을 높이고 지연 시간을 줄이는 방법을 단계별로 안내합니다.

TL;DR

처리량 우선: batch.size 증가, linger.ms 설정, 압축 활성화

지연 우선: linger.ms=0, acks=1, 작은 배치 크기

안정성 우선: acks=all, enable.idempotence=true, 재시도 설정

트레이드오프: 처리량 ↔ 지연 시간 ↔ 안정성은 상충 관계

성능 최적화의 세 가지 축#

Producer 성능 최적화는 세 가지 요소의 균형을 맞추는 작업입니다:

flowchart TB
 T[처리량<br>Throughput] <--> L[지연 시간<br>Latency]
 L <--> D[안정성<br>Durability]
 D <--> T

요소	설명	최적화 방향
처리량	초당 전송 메시지 수	배치 크기 증가, 압축 활성화
지연 시간	메시지 전송~확인까지 시간	배치 대기 시간 감소
안정성	메시지 유실 방지	acks=all, 복제 대기

1단계: 현재 성능 측정하기#

최적화 전에 현재 성능을 측정하세요. 기준선 없이는 개선 효과를 알 수 없습니다.

Scala 2 vs Scala 3 버전 비교

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Scala 2와 Scala 3의 주요 차이점을 한눈에 정리합니다. Scala 3는 2020년에 출시되어 더 간결한 문법, 강력한 타입 시스템, 개선된 암시적 기능을 제공합니다.

TL;DR

새 프로젝트: Scala 3 권장 (더 간결한 문법, 개선된 타입 시스템)

Spark 사용: Scala 2.12/2.13 유지 (Spark가 아직 Scala 3 미지원)

핵심 변경: implicit → given/using, 들여쓰기 기반 문법, enum 추가

호환성: Scala 3에서 Scala 2.13 라이브러리 사용 가능

마이그레이션: -source:3.0-migration 옵션으로 점진적 전환

새로운 기능 (Scala 3)#

Scala 3에서 추가된 주요 기능들을 카테고리별로 살펴봅니다.

Spring Kafka로 Producer/Consumer 구현하기

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

이 문서에서는 Spring Kafka를 사용하여 메시지를 송수신하는 방법을 단계별로 실습합니다.

TL;DR

Producer: KafkaTemplate으로 동기/비동기 메시지 전송, Key 사용으로 Partition 지정

Consumer: @KafkaListener로 메시지 수신, 배치 처리 및 패턴 구독 지원

수동 커밋: Acknowledgment로 처리 완료 후 명시적 커밋

에러 처리: @RetryableTopic으로 재시도 및 Dead Letter Topic 설정

시작하기 전에#

항목	요구사항
대상 독자	Spring Boot 애플리케이션에서 Kafka를 사용하려는 백엔드 개발자
선수 지식	Java 기본 문법, Spring Boot 기초, Kafka 기본 개념
사전 완료	Quick Start 예제 완료, 환경 구성 설정 완료
예상 소요 시간	약 30분

환경별 주의사항
Windows 사용자: 명령어에서 ./gradlew 대신 gradlew.bat을 사용하세요.

기본 예제

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Spring Data Elasticsearch로 Document CRUD 및 기본 검색을 구현합니다

Repository 패턴으로 간단한 쿼리, ElasticsearchOperations로 복합 쿼리를 처리합니다

필드 타입은 용도에 맞게 선택: Text(검색용), Keyword(필터용), Integer(범위 검색)

전체 소요 시간: 약 20분

Spring Data Elasticsearch를 사용하여 Document CRUD와 기본 검색을 구현합니다.

프로젝트 구조#

src/main/java/com/example/
├── ElasticsearchApplication.java
├── config/
│ └── ElasticsearchConfig.java
├── domain/
│ └── Product.java
├── repository/
│ └── ProductRepository.java
├── service/
│ └── ProductService.java
└── controller/
 └── ProductController.java

도메인 클래스#

Product.java#

package com.example.domain;

import org.springframework.data.annotation.Id;
import org.springframework.data.elasticsearch.annotations.Document;
import org.springframework.data.elasticsearch.annotations.Field;
import org.springframework.data.elasticsearch.annotations.FieldType;
import org.springframework.data.elasticsearch.annotations.Setting;

@Document(indexName = "products")
@Setting(settingPath = "elasticsearch/settings.json") // 선택사항
public class Product {

 @Id
 private String id;

 @Field(type = FieldType.Text, analyzer = "standard")
 private String name;

 @Field(type = FieldType.Keyword)
 private String category;

 @Field(type = FieldType.Integer)
 private Integer price;

 @Field(type = FieldType.Text)
 private String description;

 @Field(type = FieldType.Boolean)
 private Boolean inStock;

 // 기본 생성자
 public Product() {}

 // 전체 필드 생성자
 public Product(String id, String name, String category,
 Integer price, String description, Boolean inStock) {
 this.id = id;
 this.name = name;
 this.category = category;
 this.price = price;
 this.description = description;
 this.inStock = inStock;
 }

 // Getter/Setter
 public String getId() { return id; }
 public void setId(String id) { this.id = id; }

 public String getName() { return name; }
 public void setName(String name) { this.name = name; }

 public String getCategory() { return category; }
 public void setCategory(String category) { this.category = category; }

 public Integer getPrice() { return price; }
 public void setPrice(Integer price) { this.price = price; }

 public String getDescription() { return description; }
 public void setDescription(String description) { this.description = description; }

 public Boolean getInStock() { return inStock; }
 public void setInStock(Boolean inStock) { this.inStock = inStock; }
}

어노테이션 설명#

어노테이션	설명
`@Document`	Elasticsearch 인덱스 매핑
`@Id`	문서 고유 ID 필드
`@Field`	필드 타입 및 분석기 설정
`@Setting`	인덱스 설정 파일 경로

왜 이렇게 설계했나?#

필드 타입 선택 이유:

기본 예제

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

케이스 클래스로 불변 데이터 모델링, 자동 생성되는 equals, copy 활용

Option으로 null 안전성, Either로 상세한 에러 처리

패턴 매칭으로 타입에 따른 분기 처리

컬렉션 API (map, filter, groupBy)로 선언적 데이터 처리

타입 클래스로 확장 가능한 기능 구현

대상 독자: Scala 환경 설정을 마친 개발자, 실제 코드로 Scala를 학습하려는 분

선수 지식:

Scala 개발 환경 설정 완료 (환경 설정 참조)
객체지향 프로그래밍 기본 개념
함수형 프로그래밍 기초 (권장)

Scala의 핵심 개념을 활용한 종합 예제입니다. 이 문서에서는 케이스 클래스, 패턴 매칭, 컬렉션 처리, Option, Either, 타입 클래스 등 실무에서 자주 사용하는 기능들을 예제 코드와 함께 설명합니다.

기본 예제

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

CSV, JSON, Parquet, JDBC 등 다양한 데이터 소스 읽기/쓰기

DataFrame API로 필터, 변환, 집계, 조인 수행

SQL 쿼리와 DataFrame API 혼용 가능

실무 예제: NYC 택시 데이터, Kaggle 데이터셋 분석

대상 독자 및 선수 지식#

구분	내용
대상 독자	Spark DataFrame API를 처음 사용하는 Java 개발자
선수 지식	Java 기본 문법, SQL 기초, 환경 설정 완료
학습 목표	데이터 로딩, 변환, 집계, 조인, 저장을 수행할 수 있다
예상 소요 시간	약 30분

Spark의 핵심 기능을 활용하는 예제 코드입니다.

주문 도메인

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

주문 도메인 구현#

TL;DR

Order: Aggregate Root. 주문의 일관성 경계를 관리

OrderLine: 내부 Entity. Order를 통해서만 생성/변경 가능

Money, ShippingAddress, OrderId: Value Object. 불변이며 값으로 비교

불변식: 주문 항목 1개 이상, 최대 금액 1억원, 수량 1~999

도메인 이벤트: OrderCreatedEvent, OrderConfirmedEvent 등 상태 변경 시 발행

대상 독자 및 선수 지식#

항목	요구 수준
대상 독자	DDD 전술적 패턴을 코드로 구현하려는 개발자
DDD 기초	Aggregate, Entity, Value Object, Domain Event 개념 이해
Java	Record, Optional, Stream API 사용 경험
선수 문서	프로젝트 설정 완료

DDD 패턴을 적용하여 주문 도메인을 구현합니다.

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

참고 자료#

DDD 학습을 위한 도서, 아티클, 발표 자료를 정리합니다.

TL;DR

필독서: Blue Book(원전), Red Book(구현), DDD Distilled(입문)

학습 순서: 입문 → 기본 → 심화 → 실전 순으로 점진적 학습

한국어 자료: DDD START(최범균), 우아한객체지향(조영호) 추천

실습: 기존 프로젝트 리팩터링 또는 EventStorming으로 시작

필독서#

Domain-Driven Design (Blue Book)#

저자: Eric Evans
원서: Domain-Driven Design: Tackling Complexity in the Heart of Software (2003)
한국어판: 도메인 주도 설계

DDD의 원전입니다. 전략적/전술적 설계 패턴의 원리와 철학을 담고 있습니다.

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Kafka 학습을 위한 추가 자료들을 정리했습니다. 공식 문서부터 서적, 온라인 강의, 커뮤니티, 도구까지 체계적으로 학습할 수 있는 자료들을 모았습니다.

TL;DR

공식 문서: Apache Kafka, Spring Kafka, Confluent 문서 필수

입문 서적: “Kafka: The Definitive Guide”, “Kafka in Action” 추천

온라인 강의: Confluent Developer(무료), Udemy, 인프런

커뮤니티: Stack Overflow, Confluent Forum, OKKY

도구: Kafka UI(관리), Prometheus+Grafana(모니터링)

공식 문서#

Apache Kafka

Apache Kafka 공식 문서는 가장 정확하고 최신 정보를 제공합니다. Apache Kafka Documentation은 Kafka의 전체 아키텍처, 설정, API를 다루는 공식 문서입니다. Kafka Quickstart는 처음 시작하는 사람을 위한 공식 Quick Start 가이드로, 설치부터 기본 메시지 송수신까지 안내합니다. Kafka APIs는 Producer API, Consumer API, Streams API, Admin API 등 각 API의 상세 레퍼런스를 제공합니다. Kafka Configuration은 Broker, Producer, Consumer, Topic 등 모든 설정 옵션의 전체 목록과 설명을 포함합니다.

매핑 마이그레이션

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

다운타임 없이 인덱스 매핑(필드 타입, 분석기 등)을 변경하는 방법을 안내합니다.

소요 시간: 약 20-40분 (데이터 크기에 따라 추가 소요)

이 가이드의 범위
다루는 내용: Reindex API를 활용한 무중단 매핑 변경, Alias 전환 전략, 검증 방법

다루지 않는 내용: 대규모 인덱스 재구축은 인덱스 재구축을, 클러스터 수준 변경은 클러스터 확장을 참조하세요.

TL;DR

Alias 기반 운영: 애플리케이션은 Alias를 통해 인덱스에 접근

새 인덱스 생성: 변경된 매핑으로 새 인덱스를 만들고 Reindex

Alias 전환: 검증 완료 후 Alias를 새 인덱스로 전환

롤백 가능: 이전 인덱스를 삭제하지 않으면 즉시 롤백 가능

시작하기 전에#

다음 조건을 확인하세요:

타입 에러 디버깅

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

복잡한 타입 에러 메시지를 해독하고 해결하는 방법을 안내합니다.

소요 시간: 약 15-20분

TL;DR

Type Mismatch: 기대 타입과 실제 타입을 비교하여 어디서 불일치가 발생했는지 확인

Bounds 위반: 타입 파라미터의 상한/하한 제약 조건 확인

Variance 문제: 공변/반공변 위치에 올바른 타입이 있는지 확인

splain 플러그인: 복잡한 타입 에러를 읽기 쉬운 형태로 변환

이 가이드가 해결하는 문제#

다음과 같은 컴파일 에러가 발생할 때 이 가이드를 사용하세요:

type mismatch;
 found : List[String]
 required: List[Int]

type arguments [Dog] do not conform to method process's
type parameter bounds [A <: Animal with Serializable]

covariant type A occurs in contravariant position in type A => Unit

이 가이드가 다루지 않는 것#

타입 시스템의 기초 개념: 타입 시스템 개념 문서를 참조하세요
암시적 값 관련 에러: Implicit/Given 디버깅을 참조하세요
매크로/리플렉션 관련 에러: 해당 라이브러리 문서를 참조하세요

시작하기 전에#

다음 환경이 준비되어 있는지 확인하세요:

Value Object 설계하기

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

해결하는 문제: 모든 것을 Entity로 만들어 복잡도가 높아지거나, Primitive Obsession으로 타입 안정성이 낮은 상황 소요 시간: 약 20분 전제 조건: 전술적 설계 문서를 읽었다고 가정

성공 기준
이 가이드를 완료하면 다음을 할 수 있습니다:

3가지 질문으로 Entity와 Value Object 구분

Java Record를 활용한 Value Object 구현

Primitive Obsession을 Value Object로 리팩토링

1. Entity vs Value Object 구분하기#

1.1 3가지 판단 질문#

다음 질문을 순서대로 적용하세요:

질문 1: “이것은 고유한 식별자가 필요한가?”

네트워크 트러블슈팅

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

목표: Service나 Ingress가 연결되지 않을 때 원인을 파악하고 해결합니다 예상 시간: 30분

이 가이드의 범위
다루는 내용: Service 연결 문제, DNS 문제, Ingress 라우팅 문제

다루지 않는 내용: Pod 시작 문제(Pod 트러블슈팅 참조), 외부 네트워크 방화벽 설정

시작하기 전에#

다음 조건을 확인하세요.

1. kubectl 설치 및 클러스터 접근 확인#

kubectl cluster-info

성공 시 출력:

Kubernetes control plane is running at https://xxx.xxx.xxx.xxx
CoreDNS is running at https://xxx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

2. Pod 상태 확인#

연결하려는 대상 Pod가 Running 상태인지 확인하세요.

메시지 손실 방지 가이드

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

Kafka에서 메시지 손실을 방지하고 안정적인 메시징을 보장하는 방법을 단계별로 안내합니다.

소요 시간: 약 30분 (설정 적용 기준)

TL;DR

Producer 측: acks=all, enable.idempotence=true, 적절한 재시도 설정

Broker 측: min.insync.replicas=2, unclean.leader.election.enable=false

Consumer 측: 수동 커밋, 처리 후 커밋, 재시도 메커니즘 구현

End-to-End: 메시지 추적 ID 활용, 모니터링 및 알림 설정

시작하기 전에#

이 가이드를 따라하기 위해 다음 환경이 필요합니다.

필수 요구사항#

항목	최소 버전	확인 명령어
Apache Kafka	2.8+	`kafka-topics.sh --version`
Java	17+	`java -version`
Spring Boot	3.0+	`./gradlew dependencies \| grep spring-boot`
Spring Kafka	3.0+	`./gradlew dependencies \| grep spring-kafka`

환경 확인#

Kafka 클러스터에 접근 가능한지 확인하세요:

셔플 최적화하기

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

예상 소요 시간: 약 20분

TL;DR

셔플 확인: df.explain()에서 Exchange 노드 = 셔플 발생

불필요한 셔플 제거: 같은 그룹에서 여러 집계 한 번에 수행

브로드캐스트 조인: 작은 테이블(수십 MB)은 broadcast() 사용

셔플 파티션 수: spark.sql.shuffle.partitions 조정 (기본 200)

문제 정의#

다음과 같은 증상이 나타나면 셔플 최적화가 필요합니다:

증상	확인 위치
Stage 간 전환이 10초 이상 걸림	Spark UI → Jobs 탭
Shuffle Read/Write가 수십 GB 이상	Spark UI → Stages 탭
네트워크 I/O로 인한 타임아웃	애플리케이션 로그
`explain()`에서 `Exchange` 노드 다수	실행 계획 출력

셔플은 Spark에서 가장 비용이 큰 연산입니다. 아래 연산은 셔플을 발생시킵니다:

알림 피로도 관리

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

대상 상황: 하루에 수십~~수백 건의 알림이 발생하여 중요한 알림을 놓침 목표: 실질적으로 대응이 필요한 알림만 수신 소요 시간: 1~~2시간 (알림 규칙 분석 및 수정) 성공 기준: 일일 알림 수가 대응 가능한 수준(예: 10건 이하)으로 감소

시작하기 전에#

필요 환경#

구성요소	버전	확인 방법
Prometheus	2.40+	`prometheus --version`
Alertmanager	0.25+	`alertmanager --version`
amtool	0.25+	`amtool --version`

필요 권한#

Prometheus 설정 파일(prometheus.yml) 수정 권한
Alertmanager 설정 파일(alertmanager.yml) 수정 권한
Prometheus/Alertmanager 재시작 권한

환경 확인#

# Prometheus 상태 확인
curl -s http://localhost:9090/-/healthy && echo "Prometheus OK"

# Alertmanager 상태 확인
curl -s http://localhost:9093/-/healthy && echo "Alertmanager OK"

# amtool 설정 확인
amtool config show --alertmanager.url=http://localhost:9093

문제 상황#

# 어제 발생한 알림 요약
Critical: 15건 (HighCPU 8건, HighMemory 7건)
Warning: 87건 (SlowResponse 45건, HighLatency 32건, PodRestart 10건)
총: 102건

# 실제 장애: 1건
# 놓친 알림: 1건 (HighCPU 알림에 묻힘)

알림 피로도(Alert Fatigue)가 발생하면:

Aggregate 심화

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: Aggregate 기본 개념을 알고 있으며 설계 심화 학습이 필요한 개발자 선수 지식: 전술적 설계의 Entity, Value Object 개념 소요 시간: 약 25분 핵심 질문: “Aggregate 경계를 어떻게 정하고, 크기는 어느 정도가 적당한가?”

요약
Aggregate 설계 핵심: 불변식 기반 경계 설정 → 작게 유지 → ID로 참조 → 결과적 일관성 활용

Aggregate 심화#

Aggregate의 설계 원칙, 트랜잭션 경계, 실전 패턴을 깊이 있게 다룹니다.

비유: 가족과 이웃
Aggregate를 이해하는 가장 쉬운 비유는 가족 단위입니다.

Consumer Group & Offset

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Consumer Group은 동일 목적의 Consumer들을 묶어 병렬 처리하는 논리적 그룹

핵심 규칙: 하나의 Partition은 Group 내에서 하나의 Consumer만 읽을 수 있음

Offset은 Partition 내 메시지 위치 번호로, __consumer_offsets 토픽에 저장

자동 커밋은 간편하지만 데이터 유실 위험, 수동 커밋은 정확한 제어 가능

Consumer 장애 시 리밸런싱으로 Partition이 자동 재분배됨

대상 독자: Kafka Consumer를 개발하거나 운영하는 개발자, 병렬 처리와 상태 관리를 학습하려는 분

선수 지식: 메시지 흐름의 Topic과 Partition 개념, Replication의 Leader/Follower 개념

소요 시간: 약 25-30분

DataFrame과 Dataset

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

DataFrame은 스키마가 있는 분산 테이블, Dataset은 타입 안전한 분산 컬렉션

Java에서 DataFrame = Dataset<Row>, 타입 Dataset = Dataset<T>

Catalyst Optimizer를 통한 자동 최적화로 RDD보다 성능 우수

SQL 스타일 작업은 DataFrame, 복잡한 비즈니스 로직은 Dataset 권장

대상 독자: Java/Spring 개발자, Spark 데이터 처리를 시작하는 중급자

선수 지식:

Java Generics 및 함수형 인터페이스 (Function, Consumer 등)
SQL 기본 문법 (SELECT, WHERE, GROUP BY)
RDD 기초 문서 이해 권장

소요 시간: 약 25-30분

Deployment

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 입주민 관리 시스템#

Deployment를 아파트 입주민 관리 시스템에 비유하면 이해하기 쉽습니다:

아파트 관리 비유	Kubernetes Deployment	역할
입주민 관리 시스템	Deployment	세대(Pod) 배치와 업데이트 총괄
“항상 3세대 유지” 규칙	replicas: 3	원하는 세대 수 선언
세대 목록 관리대장	ReplicaSet	실제 세대 수 유지 담당
순차적 이사	Rolling Update	한 세대씩 새 버전으로 교체
이전 주소로 복귀	Rollback	문제 시 이전 상태로 되돌리기
공실 발생 시 자동 입주	자동 복구	Pod 장애 시 자동 재생성
입주 규격 템플릿	Pod Template	생성할 세대의 표준 사양
과거 입주 기록 보관	revisionHistory	롤백용 이전 버전 유지

이처럼 Deployment는 “관리사무소가 항상 일정 수의 세대를 유지하고, 리모델링 시 순차적으로 진행"하는 것과 같습니다.

Errors (에러)

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 응급실 분류 체계#

Errors를 응급실 환자 분류(Triage) 시스템에 비유하면 이해하기 쉽습니다:

응급실 분류 비유	Errors 개념	의미
진료 실패율	에러율	전체 중 실패 비율
환자 분류 (중증/경증)	에러 분류	5xx vs 4xx, 심각도 구분
감기 환자 (경미)	404 Not Found	흔하고 대부분 정상
예방 조치 (거부)	429 Rate Limit	의도적 보호 기제
응급 환자 (심각)	500 에러	즉각 조치 필요
중환자실 만석	503 에러	용량 문제
월간 응급 예산	에러 버짓	허용 가능한 에러량
진료 성공률 목표	SLO	목표 가용성

이처럼 응급실에서 환자를 분류하듯, 에러도 유형별로 분류하여 적절한 대응 우선순위를 정합니다.

Prometheus 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 정기 건강검진 시스템#

Prometheus 아키텍처를 병원의 정기 건강검진 시스템에 비유하면 이해하기 쉽습니다:

건강검진 비유	Prometheus 구성요소	역할
정기 건강검진 일정	Pull 모델	정해진 주기로 상태 확인
건강검진 센터	Prometheus Server	데이터 수집/저장
환자 명부 (자동 갱신)	서비스 디스커버리	모니터링 대상 자동 발견
검진 결과 DB	TSDB (시계열 DB)	시간별 데이터 저장
직원 건강검진 (회사 방문)	Scrape	타겟에서 메트릭 수집
외래 환자 접수	Pushgateway	짧은 작업의 메트릭 저장
이상 수치 알림	Alertmanager	문제 발생 시 알림
검진 결과 분류/정리	Relabeling	라벨 변환 및 필터링

이처럼 정기 건강검진에서 의사가 환자를 찾아가듯, Prometheus는 타겟을 주기적으로 방문하여 상태를 확인합니다.

Query DSL

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Query Context: 관련성 점수(score)를 계산하는 풀텍스트 검색

Filter Context: 점수 없이 조건만 확인, 캐싱되어 빠름

match/match_phrase: 풀텍스트 검색에 사용 (text 필드)

term/terms/range: 정확한 값 검색에 사용 (keyword 필드)

bool: must/should/must_not/filter로 쿼리 조합

대상 독자: Elasticsearch 기본 개념을 이해한 개발자 선수 지식: 핵심 구성요소, JSON 기본 문법

소요 시간: 약 25-30분

전체 비유: 도서관에서 책 찾기#

Query DSL을 도서관에서 책을 찾는 방법에 비유하면 이해하기 쉽습니다:

도서관 비유	Query DSL	역할
“인공지능 관련 책 찾아주세요”	Query Context (match)	내용 관련성으로 추천, 관련도 순 정렬
“005.133 분류 책만 보여주세요”	Filter Context (term)	조건 일치 여부만 확인, 빠름
“머신러닝 입문” 내용 검색	match	단어 포함 여부로 검색 (순서 무관)
“머신러닝 입문” 정확히	match_phrase	정확한 문구 순서로 검색
청구기호 “005.133” 정확히	term	값이 정확히 일치하는 것만
2020~2024년 출판 도서	range	범위 내 값 검색
컴퓨터 분야 AND 2024년 출판	bool (must)	모든 조건 만족
프로그래밍 OR 데이터분석	bool (should)	하나 이상 만족
번역서 제외	bool (must_not)	해당 조건 제외

이처럼 Query DSL은 도서관 사서에게 “어떤 조건으로 책을 찾아달라"고 요청하는 것과 같습니다.

rate와 increase

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 누적 진료 기록 분석#

rate와 increase를 누적 진료 기록 분석에 비유하면 이해하기 쉽습니다:

진료 기록 비유	PromQL 함수	역할
총 누적 진료 건수	Counter 원시값	서버 시작 후 누적 (의미 제한적)
시간당 진료 건수	rate()	초당 평균 증가율 (핵심)
오늘 하루 진료 건수	increase()	기간 내 총 증가량
방금 전 진료 속도	irate()	마지막 구간 순간 증가율
야간 진료 재시작	Counter 리셋	자동으로 처리됨
대시보드 현황판	rate 활용	실시간 모니터링
월간 리포트	increase 활용	기간별 합계

이처럼 누적 진료 기록에서 “시간당 진료 건수"를 계산하듯, rate()로 Counter를 변화율로 변환합니다.

클린 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 엄격한 의존성 관리가 필요한 대규모 프로젝트 개발자 선수 지식: 헥사고날 아키텍처의 Port/Adapter 개념 소요 시간: 약 25분

클린 아키텍처 (Clean Architecture)#

Uncle Bob(Robert C. Martin)이 2012년에 제안한 아키텍처입니다. 의존성 규칙을 엄격하게 지키는 것이 핵심입니다.

클린 아키텍처가 등장한 배경에는 소프트웨어 개발의 고질적인 문제가 있습니다. 비즈니스 로직이 프레임워크나 데이터베이스에 강하게 결합되면, 기술 스택을 변경하거나 테스트를 작성하는 것이 매우 어려워집니다. 예를 들어, JPA 어노테이션이 도메인 객체에 직접 붙어 있으면, 해당 도메인 로직을 테스트하려면 반드시 데이터베이스 연결이 필요하게 됩니다. 클린 아키텍처는 이런 문제를 해결하기 위해 비즈니스 규칙을 기술적 세부사항으로부터 완전히 격리하는 것을 목표로 합니다.

함수와 메서드

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 요리사와 레시피#

Scala의 함수와 메서드를 요리사와 레시피에 비유하면 이해하기 쉽습니다:

요리 비유	Scala 개념	역할
레시피 (조리법)	메서드 (def)	클래스에 소속된 동작 정의
레시피 카드 (전달 가능)	함수 값 (val)	저장/전달 가능한 동작
재료 손질법 전달	일급 함수	함수를 인자로 전달
소스 베이스 만들기	커링	기본 설정 후 변형
부분 조리 (반조리)	부분 적용	일부 재료만 먼저 적용
재료 → 요리 변환	함수 타입	입력 → 출력 관계
같은 과정 반복	재귀	자기 자신 호출

이처럼 요리사가 레시피를 조합하여 새로운 요리를 만들듯, Scala에서는 함수를 조합하여 복잡한 로직을 구성합니다.

Kafka 모니터링

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

소요 시간: 20분 선수 지식: Kafka 기초, 환경 구성 이 문서를 읽으면: Kafka 클러스터와 Consumer Lag을 모니터링할 수 있습니다

Kafka 모니터링 핵심 지표#

카테고리	지표	의미
Consumer	Lag	처리 지연 (가장 중요)
Broker	Under-replicated Partitions	복제 문제
Producer	Record Error Rate	전송 실패율
Broker	Disk Usage	저장 공간

Step 1: Kafka + JMX Exporter 설정#

# docker-compose.yml에 추가
services:
 kafka:
 image: confluentinc/cp-kafka:7.5.0
 container_name: kafka
 ports:
 - "9092:9092"
 - "9101:9101" # JMX
 environment:
 KAFKA_NODE_ID: 1
 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
 KAFKA_PROCESS_ROLES: broker,controller
 KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:29093
 KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:29093
 KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
 CLUSTER_ID: MkU3OEVBNTcwNTJENDM2Qk
 KAFKA_JMX_PORT: 9101
 KAFKA_JMX_HOSTNAME: localhost
 KAFKA_OPTS: -javaagent:/opt/jmx-exporter/jmx_prometheus_javaagent.jar=7071:/opt/jmx-exporter/kafka.yml
 volumes:
 - ./jmx-exporter:/opt/jmx-exporter

 kafka-exporter:
 image: danielqsj/kafka-exporter:latest
 container_name: kafka-exporter
 ports:
 - "9308:9308"
 command:
 - --kafka.server=kafka:9092
 - --topic.filter=.*
 - --group.filter=.*

Step 2: JMX Exporter 설정#

mkdir -p jmx-exporter
curl -L https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.19.0/jmx_prometheus_javaagent-0.19.0.jar -o jmx-exporter/jmx_prometheus_javaagent.jar

# jmx-exporter/kafka.yml
lowercaseOutputName: true
rules:
 # Broker 메트릭
 - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
 name: kafka_server_$1_$2
 type: GAUGE
 labels:
 clientId: "$3"
 topic: "$4"
 partition: "$5"

 - pattern: kafka.server<type=(.+), name=(.+)><>Value
 name: kafka_server_$1_$2
 type: GAUGE

 # Under-replicated Partitions
 - pattern: kafka.server<type=ReplicaManager, name=UnderReplicatedPartitions><>Value
 name: kafka_server_replicamanager_underreplicatedpartitions
 type: GAUGE

 # Messages In Per Sec
 - pattern: kafka.server<type=BrokerTopicMetrics, name=MessagesInPerSec, topic=(.+)><>OneMinuteRate
 name: kafka_server_brokertopicmetrics_messagesin_total
 type: GAUGE
 labels:
 topic: "$1"

 # Bytes In Per Sec
 - pattern: kafka.server<type=BrokerTopicMetrics, name=BytesInPerSec, topic=(.+)><>OneMinuteRate
 name: kafka_server_brokertopicmetrics_bytesin_total
 type: GAUGE
 labels:
 topic: "$1"

Step 3: Prometheus 설정 추가#

# prometheus/prometheus.yml에 추가
scrape_configs:
 - job_name: 'kafka'
 static_configs:
 - targets: ['kafka:7071']

 - job_name: 'kafka-exporter'
 static_configs:
 - targets: ['kafka-exporter:9308']

Step 4: 핵심 PromQL 쿼리#

Consumer Lag#

# 컨슈머 그룹별 Lag
sum by (consumergroup, topic) (kafka_consumergroup_lag)

# Lag이 10000 이상인 그룹
sum by (consumergroup, topic) (kafka_consumergroup_lag) > 10000

# Lag 추이
sum(kafka_consumergroup_lag) by (consumergroup)

Broker 상태#

# Under-replicated Partitions
kafka_server_replicamanager_underreplicatedpartitions

# ISR (In-Sync Replicas) 축소
kafka_server_replicamanager_isrshrinks_total

트래픽#

# 토픽별 초당 메시지 수
sum by (topic) (rate(kafka_server_brokertopicmetrics_messagesin_total[5m]))

# 토픽별 초당 바이트
sum by (topic) (rate(kafka_server_brokertopicmetrics_bytesin_total[5m]))

Step 5: 알림 규칙#

# prometheus/rules/kafka-alerts.yml
groups:
 - name: kafka
 rules:
 - alert: KafkaConsumerLagHigh
 expr: sum by (consumergroup, topic) (kafka_consumergroup_lag) > 10000
 for: 10m
 labels:
 severity: warning
 annotations:
 summary: "High consumer lag: {{ $labels.consumergroup }}"
 description: "Lag is {{ $value }} on topic {{ $labels.topic }}"

 - alert: KafkaUnderReplicatedPartitions
 expr: kafka_server_replicamanager_underreplicatedpartitions > 0
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "Kafka under-replicated partitions"
 description: "{{ $value }} partitions are under-replicated"

 - alert: KafkaBrokerDown
 expr: count(kafka_server_kafkaserver_brokerstate) < 3
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "Kafka broker down"

Step 6: Recording Rules#

# prometheus/rules/kafka-recording.yml
groups:
 - name: kafka_recording
 rules:
 - record: topic:kafka_messages:rate5m
 expr: sum by (topic) (rate(kafka_server_brokertopicmetrics_messagesin_total[5m]))

 - record: consumergroup:kafka_lag:sum
 expr: sum by (consumergroup) (kafka_consumergroup_lag)

 - record: :kafka_underreplicated:sum
 expr: sum(kafka_server_replicamanager_underreplicatedpartitions)

Step 7: Grafana 대시보드#

Row 1: Overview#

패널	쿼리	타입
Total Lag	`sum(kafka_consumergroup_lag)`	Stat
Messages/sec	`sum(rate(kafka_server_brokertopicmetrics_messagesin_total[5m]))`	Stat
Under-replicated	`sum(kafka_server_replicamanager_underreplicatedpartitions)`	Stat

Row 2: Consumer Lag#

# Time Series: Lag 추이
sum by (consumergroup) (kafka_consumergroup_lag)

# Table: 상세
sum by (consumergroup, topic, partition) (kafka_consumergroup_lag)

Row 3: Traffic#

# 토픽별 메시지/초
sum by (topic) (rate(kafka_server_brokertopicmetrics_messagesin_total[5m]))

Spring Kafka 메트릭#

# application.yml
management:
 metrics:
 enable:
 kafka: true

# Producer 메트릭
kafka_producer_record_send_total
kafka_producer_record_error_total

# Consumer 메트릭
kafka_consumer_records_consumed_total
kafka_consumer_fetch_manager_records_lag

확인 체크리스트#

kafka-exporter 메트릭 노출 확인
Consumer Lag 쿼리 동작 확인
Grafana 대시보드 구성
알림 규칙 테스트

다음 단계#

추천 순서	문서	배우는 것
1	풀스택 예제	통합 예제
2	서비스 유형별 적용	Kafka 황금 신호

알림 후 액션 가이드

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

알림을 받은 후 어떻게 대응해야 하는지 상황별 가이드입니다.

알림 → 액션 워크플로우#

graph LR
 A["알림 수신"] --> B["상황 파악"]
 B --> C["영향도 평가"]
 C --> D["즉시 조치"]
 D --> E["근본 원인 분석"]
 E --> F["영구 해결"]
 F --> G["사후 검토"]

상황별 대응#

1. 서비스 다운 (TargetDown)#

알림

alert: TargetDown
expr: up == 0

즉시 조치

# 1. 서비스 상태 확인
kubectl get pods -l app=order-service
docker ps -f name=order-service

# 2. 로그 확인
kubectl logs -l app=order-service --tail=100
docker logs order-service --tail=100

# 3. 재시작 시도
kubectl rollout restart deployment/order-service
docker restart order-service

근본 원인 분석

Spring Boot 배포

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

대상 독자: Spring Boot 애플리케이션을 Kubernetes에 배포하고 싶은 백엔드 개발자 선수 지식: Deployment, Service, ConfigMap, Docker 이 문서를 읽으면: Spring Boot 앱을 컨테이너화하고 Kubernetes에 배포할 수 있습니다

TL;DR

Dockerfile 작성 → 이미지 빌드 → Kubernetes 배포

ConfigMap/Secret으로 환경별 설정 분리

Actuator 엔드포인트로 헬스 체크 구성

전체 흐름#

flowchart LR
 A[Spring Boot App] --> B[Dockerfile]
 B --> C[Docker Build]
 C --> D[이미지 Push]
 D --> E[K8s Deployment]
 E --> F[Service]
 F --> G[Ingress]

1. Spring Boot 애플리케이션 준비#

예제 애플리케이션 구조#

my-app/
├── src/main/
│ ├── java/com/example/
│ │ └── MyAppApplication.java
│ └── resources/
│ └── application.yml
├── Dockerfile
├── build.gradle.kts
└── kubernetes/
 ├── deployment.yaml
 ├── service.yaml
 ├── configmap.yaml
 └── secret.yaml

application.yml#

spring:
 application:
 name: my-app
 datasource:
 url: ${DATABASE_URL:jdbc:postgresql://localhost:5432/mydb}
 username: ${DATABASE_USERNAME:postgres}
 password: ${DATABASE_PASSWORD:postgres}

server:
 port: 8080

management:
 endpoints:
 web:
 exposure:
 include: health,info,prometheus
 endpoint:
 health:
 probes:
 enabled: true
 health:
 livenessState:
 enabled: true
 readinessState:
 enabled: true

간단한 컨트롤러#

@RestController
public class HelloController {

 @GetMapping("/")
 public String hello() {
 return "Hello from Kubernetes!";
 }

 @GetMapping("/hostname")
 public String hostname() {
 try {
 return "Pod: " + InetAddress.getLocalHost().getHostName();
 } catch (UnknownHostException e) {
 return "Unknown";
 }
 }
}

2. Docker 이미지 빌드#

Dockerfile (멀티스테이지 빌드)#

# 빌드 스테이지
FROM eclipse-temurin:17-jdk AS build
WORKDIR /app
COPY gradle gradle
COPY build.gradle.kts settings.gradle.kts gradlew ./
COPY src src
RUN ./gradlew bootJar --no-daemon

# 실행 스테이지
FROM eclipse-temurin:17-jre
WORKDIR /app

# 보안: non-root 사용자
RUN addgroup --system appgroup && adduser --system appuser --ingroup appgroup
USER appuser

COPY --from=build /app/build/libs/*.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

이미지 빌드#

# Docker 이미지 빌드
docker build -t my-app:1.0 .

# 로컬 테스트
docker run -p 8080:8080 my-app:1.0

# Minikube 환경에서 로컬 이미지 사용
eval $(minikube docker-env)
docker build -t my-app:1.0 .

# Kind 환경에서 로컬 이미지 사용
kind load docker-image my-app:1.0

3. Kubernetes 리소스 작성#

ConfigMap (환경 설정)#

# kubernetes/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: my-app-config
data:
 SPRING_PROFILES_ACTIVE: "kubernetes"
 DATABASE_URL: "jdbc:postgresql://postgres-service:5432/mydb"
 JAVA_OPTS: "-Xms256m -Xmx512m"

Secret (민감 정보)#

# Secret 생성 (명령어)
kubectl create secret generic my-app-secret \
 --from-literal=DATABASE_USERNAME=myuser \
 --from-literal=DATABASE_PASSWORD=mypassword

또는 YAML로:

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Sun, 11 Jan 2026 00:00:00 +0000

Kubernetes 학습과 운영에 도움이 되는 공식 문서와 추가 학습 자료를 정리합니다.

학습 단계별 추천 자료#

어디서부터 시작해야 할지 모르겠다면 아래 로드맵을 참고하세요.

flowchart TD
 START[시작] --> L1[1단계: 입문]
 L1 --> L2[2단계: 기초]
 L2 --> L3[3단계: 심화]
 L3 --> L4[4단계: 전문가]

 L1 -.->|추천| R1[Kubernetes Basics 튜토리얼]
 L2 -.->|추천| R2[kubectl Cheat Sheet + 이 가이드]
 L3 -.->|추천| R3[Kubernetes in Action 도서]
 L4 -.->|추천| R4[CKA/CKAD 자격증]

단계	목표	추천 자료	예상 기간
1. 입문	첫 배포 성공	Kubernetes Basics, Play with K8s	1주
2. 기초	핵심 개념 이해	이 가이드, kubectl Cheat Sheet	2-4주
3. 심화	운영 역량 확보	Kubernetes in Action, Prometheus	1-3개월
4. 전문가	자격증/아키텍처	CKA/CKAD, Kubernetes Patterns	3-6개월

공식 문서#

Kubernetes 공식#

자료	설명	링크
Kubernetes Documentation	공식 문서 (한글 지원)	kubernetes.io/docs
Kubernetes Blog	새로운 기능, 릴리스 소식	kubernetes.io/blog
Kubernetes GitHub	소스 코드, 이슈	github.com/kubernetes

kubectl 참조#

자료	설명	링크
kubectl Cheat Sheet	자주 쓰는 명령어 모음	kubectl cheatsheet
kubectl Reference	전체 명령어 참조	kubectl reference

API 참조#

자료	설명	링크
API Reference	Kubernetes API 문서	API Reference

학습 자료#

인터랙티브 튜토리얼#

자료	설명	링크
Kubernetes Basics	공식 인터랙티브 튜토리얼	Learn Kubernetes Basics
Katacoda (Killercoda)	브라우저 기반 실습 환경	killercoda.com
Play with Kubernetes	무료 온라인 실습 환경	labs.play-with-k8s.com

도서#

도서	저자	특징
Kubernetes in Action	Marko Lukša	실무 중심, 상세한 설명
Kubernetes Patterns	Bilgin Ibryam	디자인 패턴 중심
Cloud Native DevOps with Kubernetes	John Arundel	DevOps 관점

자격증#

자격증	대상	설명
CKA	관리자	Kubernetes 클러스터 관리 능력 검증
CKAD	개발자	Kubernetes 애플리케이션 개발 능력 검증
CKS	보안 전문가	Kubernetes 보안 능력 검증

도구#

로컬 개발#

도구	설명	링크
Minikube	로컬 Kubernetes 클러스터	minikube.sigs.k8s.io
Kind	Docker 기반 로컬 클러스터	kind.sigs.k8s.io
k3d	경량 Kubernetes (k3s)	k3d.io

패키지 관리#

도구	설명	링크
Helm	Kubernetes 패키지 관리자	helm.sh
Kustomize	설정 커스터마이징	kustomize.io

모니터링#

도구	설명	링크
Prometheus	메트릭 수집	prometheus.io
Grafana	시각화 대시보드	grafana.com
Lens	Kubernetes IDE	k8slens.dev

CLI 도구#

도구	설명	링크
kubectx/kubens	컨텍스트/네임스페이스 전환	github.com/ahmetb/kubectx
k9s	터미널 UI	k9scli.io
stern	멀티 Pod 로그	github.com/stern/stern

관리형 Kubernetes#

서비스	클라우드	링크
Amazon EKS	AWS	aws.amazon.com/eks
Google GKE	GCP	cloud.google.com/kubernetes-engine
Azure AKS	Azure	azure.microsoft.com/services/kubernetes-service

커뮤니티#

채널	설명	링크
Kubernetes Slack	공식 커뮤니티	slack.kubernetes.io
CNCF	Cloud Native 재단	cncf.io
Stack Overflow	Q&A	stackoverflow.com/questions/tagged/kubernetes

버전 및 릴리스#

자료	설명	링크
Release Notes	버전별 변경사항	kubernetes.io/releases
Deprecation Policy	지원 중단 정책	Deprecation Policy
Version Skew Policy	버전 호환성	Version Skew

FAQ

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Scala에 대해 자주 묻는 질문과 답변입니다. 질문을 카테고리별로 분류하여 빠르게 원하는 정보를 찾을 수 있도록 했습니다.

TL;DR

버전 선택: 새 프로젝트는 Scala 3, Spark 사용 시 Scala 2.12/2.13

val vs var: 항상 val(불변) 우선 사용

null 대신 Option: Option, Some, None으로 안전한 null 처리

IDE: IntelliJ IDEA + Scala 플러그인 (가장 완성도 높음)

성능: Java와 동등, 컬렉션 체이닝과 람다 사용 시 주의

일반#

Scala 학습과 관련된 일반적인 질문들입니다.

Scala를 배워야 할까요?

Scala 2 vs Scala 3 비교

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

문법 간소화: Scala 3는 들여쓰기 기반 구문, then 키워드 도입

enum 지원: sealed trait + case object 대신 네이티브 enum 사용

암시적 재설계: implicit → given/using/extension으로 역할 분리

새 타입 기능: Union Type (|), Opaque Type 추가

하위 호환: Scala 3는 대부분의 Scala 2 문법 지원, 점진적 마이그레이션 가능

대상 독자: Scala 2 경험자 또는 두 버전 모두 이해하고 싶은 개발자

선수 지식:

Scala 기본 문법 이해
함수형 프로그래밍 기초 개념
(선택) Scala 2 코드베이스 경험

동일한 로직을 Scala 2와 Scala 3로 구현하여 차이점을 비교합니다. 두 버전 간의 문법 변화를 이해하면 코드를 마이그레이션하거나 양쪽 버전 모두에서 작업할 때 도움이 됩니다. 이 문서에서는 주요 변경 사항들을 실제 코드 예제로 보여줍니다.

상품 검색 시스템

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

완전한 예제 프로젝트
이 문서의 코드를 바로 실행해보고 싶다면, 완전한 Spring Boot 프로젝트를 사용하세요:

📁 examples/elasticsearch/product-search/

docker-compose로 Elasticsearch(Nori 포함) 즉시 실행 가능

샘플 데이터 자동 초기화

TL;DR

Nori 분석기로 한글 형태소 분석을 적용하여 “삼성전자” → “삼성”, “전자” 검색을 구현합니다

Edge N-gram으로 자동완성 기능을 구현합니다

Bool Query + Aggregation으로 필터링과 패싯(facet)을 제공합니다

하이라이팅으로 검색어를 강조 표시합니다

전체 소요 시간: 약 30분

한글 형태소 분석, 자동완성, 필터링을 포함한 실제 서비스 수준의 상품 검색 시스템을 구현합니다.

애플리케이션 계층

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

애플리케이션 계층 구현#

TL;DR

OrderService: Use Case 조율. 도메인 로직 호출, 트랜잭션 관리, 이벤트 발행

Command 객체: CreateOrderCommand 등 요청을 불변 객체로 캡슐화

DTO: OrderResponse 등 응답을 도메인과 분리하여 표현

JPA Repository: Domain Repository 인터페이스의 구현체. Mapper로 Entity 변환

이벤트 핸들러: @TransactionalEventListener로 커밋 후 Kafka 발행

대상 독자 및 선수 지식#

항목	요구 수준
대상 독자	Application Service와 Infrastructure 계층 구현을 배우려는 개발자
Spring	@Service, @Transactional, @Repository 애노테이션 사용 경험
JPA	Entity, @Embedded, CascadeType 이해
선수 문서	프로젝트 설정, 주문 도메인 완료

Use Case를 조율하는 Application Service와 인프라 계층을 구현합니다.

자주 묻는 질문

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

DDD 자주 묻는 질문 (FAQ)#

DDD를 적용할 때 자주 받는 질문과 답변입니다.

TL;DR

DDD는 아키텍처가 아닌 방법론이며, 복잡한 비즈니스 로직이 있을 때 가치가 있습니다

Entity는 ID로, Value Object는 속성 값으로 동등성을 판단합니다

Aggregate는 “진정한 불변식을 보호하는 최소 단위"로 설계합니다

유비쿼터스 언어가 DDD 적용 시 가장 중요한 요소입니다

레거시 시스템에도 ACL(Anti-Corruption Layer)을 통해 점진적으로 적용 가능합니다

기본 개념#

Q: DDD는 아키텍처인가요?#

A: 아닙니다. DDD는 복잡한 도메인을 다루는 방법론입니다.

DDD가 아닌 것:
- 아키텍처 패턴 (Clean, Hexagonal 등과 같이 쓰일 뿐)
- 기술 스택
- 프레임워크

DDD인 것:
- 도메인 중심 사고방식
- 전략적/전술적 패턴 모음
- 비즈니스와 기술의 협업 방법

Q: DDD는 모든 프로젝트에 필요한가요?#

A: 아닙니다. 복잡한 비즈니스 로직이 있을 때 가치가 있습니다.

주문 시스템

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

실무에 가까운 이벤트 기반 주문 시스템을 구현합니다. 이 예제에서는 주문 생성부터 배송 완료까지의 전체 흐름을 Kafka 이벤트로 처리하며, Message Key를 활용한 순서 보장과 여러 Consumer Group을 활용한 확장 패턴을 학습합니다.

TL;DR

이벤트 기반 아키텍처: REST API 요청을 Kafka 이벤트로 변환하여 비동기 처리

Message Key: orderId를 Key로 사용하여 같은 주문 이벤트의 순서 보장

상태 머신: CREATED -> PAID -> SHIPPED -> DELIVERED 순서로 상태 전이

확장 패턴: 여러 Consumer Group이 동일 Topic 독립적으로 구독

대상 독자 및 선수 지식#

항목	설명
대상 독자	이벤트 기반 시스템을 구축하려는 백엔드 개발자
선수 지식	Spring Boot 기초, Kafka 기본 개념, 기본 예제 완료
필수 환경	Docker로 Kafka 실행 중, JDK 17+, Gradle
예상 소요 시간	약 45분

이 페이지의 모든 코드 예제에서는 다음 import가 공통으로 사용됩니다. Spring Kafka의 KafkaTemplate과 @KafkaListener를 중심으로 구현하며, Jackson ObjectMapper를 통해 JSON 직렬화를 처리합니다.

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

공식 문서: Elastic 공식 가이드, Spring Data Elasticsearch 문서

한글 자료: 우아한형제들, 카카오, 네이버 D2 기술 블로그의 실무 사례

클라우드 서비스: Elastic Cloud(공식), Amazon OpenSearch(AWS 통합), Self-Managed(완전 통제)

학습 경로: 공식 무료 교육 → 한글 블로그 → Elastic 인증

공식 문서, 추천 도서, 커뮤니티 리소스 링크입니다.

공식 문서#

Elasticsearch#

Kibana#

Spring Data Elasticsearch#

온라인 강의#

무료#

Elastic 공식 교육 - 기초 과정 무료
YouTube: Elastic 공식 채널

유료#

Elastic 인증 과정
Udemy, Coursera 등의 Elasticsearch 강의

커뮤니티#

포럼 & Q&A#

Elastic Discuss - 공식 포럼
Stack Overflow elasticsearch 태그

한국 커뮤니티#

한글 학습 자료#

블로그 & 아티클#

주제	링크	특징
ES 기초	우아한형제들 기술블로그	실무 적용 사례
검색 최적화	카카오 기술블로그	대규모 검색 경험
로그 분석	네이버 D2	ELK 스택 운영
인프라	당근마켓 기술블로그	스타트업 ES 도입기

국내 도서#

도서	특징
엘라스틱서치 실무 가이드	한글, 실무 중심
기초부터 다지는 ElasticSearch	입문자 친화적

팁: 영문 공식 문서와 한글 블로그를 병행하면 이해가 빠릅니다.

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Apache Spark 학습을 위한 공식 문서와 추가 자료를 안내합니다.

TL;DR

공식 문서: spark.apache.org/docs/latest - 가장 정확한 최신 정보

Java API: Javadoc - Dataset, SparkSession, functions 클래스 참조

학습 추천: Databricks Academy(공식), Baeldung(Java 개발자용)

입문서 추천: “Learning Spark, 2nd Edition”, “Spark: The Definitive Guide”

커뮤니티: Stack Overflow apache-spark 태그, GitHub Issues

공식 문서#

Apache Spark 공식 사이트

Spark 공식 사이트 — 다운로드, 뉴스, 릴리즈 정보
Spark 3.5 문서 — 현재 안정 버전 문서
Spark 최신 문서 — 최신 버전 문서

프로그래밍 가이드

sbt 의존성 충돌 해결

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

라이브러리 버전 충돌을 진단하고 해결하는 방법을 안내합니다.

소요 시간: 약 15-20분

TL;DR

증상: 컴파일은 성공하지만 런타임에 NoSuchMethodError, ClassNotFoundException 발생

진단: sbt dependencyTree로 충돌 라이브러리 확인

해결: exclude, dependencyOverrides, force() 활용

예방: eviction 경고를 무시하지 말 것

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

컴파일은 성공하지만 런타임에 NoSuchMethodError가 발생하는 경우
ClassNotFoundException이 발생하지만 라이브러리가 분명히 있는 경우
sbt 빌드 시 eviction 경고가 출력되는 경우
여러 라이브러리가 같은 의존성의 다른 버전을 요구하는 경우

증상#

# 컴파일은 성공하지만 실행 시 에러
$ sbt run
java.lang.NoSuchMethodError: 'void com.google.common.collect.ImmutableMap.forEach()'

# 또는 클래스를 찾지 못함
$ sbt run
java.lang.ClassNotFoundException: org.apache.commons.lang3.StringUtils

이 가이드가 다루지 않는 것#

sbt 기본 사용법: sbt 공식 문서를 참조하세요
Maven/Gradle 의존성 관리: 해당 빌드 도구 문서를 참조하세요
Scala 바이너리 호환성: Scala 버전 간 호환성 문제는 별도 주제입니다

시작하기 전에#

다음 환경이 준비되어 있는지 확인하세요:

StatefulSet 실습

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

대상 독자: 상태를 유지해야 하는 애플리케이션을 Kubernetes에 배포하고 싶은 개발자 선수 지식: Deployment, Service, PersistentVolume 개념 이 문서를 읽으면: StatefulSet으로 MySQL을 배포하고 데이터 영속성을 검증할 수 있습니다

TL;DR

StatefulSet으로 MySQL을 배포합니다

Headless Service로 개별 Pod에 접근합니다

PersistentVolumeClaim 템플릿으로 데이터를 영속화합니다

스케일 업/다운 시 데이터 보존을 확인합니다

전체 흐름#

flowchart LR
 A[Headless Service] --> B[StatefulSet]
 B --> C[mysql-0]
 B --> D[mysql-1]
 B --> E[mysql-2]
 C --> F[PVC-0]
 D --> G[PVC-1]
 E --> H[PVC-2]

사전 준비#

다음이 필요합니다:

인덱스 재구축

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

대용량 인덱스를 효율적으로 재구축하는 방법을 안내합니다.

소요 시간: 약 30-60분 (데이터 크기에 따라 수 시간 소요 가능)

이 가이드의 범위
다루는 내용: _reindex API, Snapshot/Restore, Logstash 비교, 대용량 처리 전략, 성능 최적화

다루지 않는 내용: 단순 매핑 변경은 매핑 마이그레이션을, 클러스터 확장은 클러스터 확장을 참조하세요.

TL;DR

_reindex API: 가장 간단, 같은 클러스터 내 재구축에 적합

Snapshot/Restore: 클러스터 간 이동, 대용량 데이터에 적합

Logstash: 변환이 복잡하거나 외부 소스와 연동할 때 적합

성능 최적화: refresh_interval: -1, replica 0, sliced scroll 활용

시작하기 전에#

다음 조건을 확인하세요:

DDD 토론: 긍정파 vs 부정파

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

DDD 토론: 긍정파 vs 부정파#

두 시니어 개발자가 Domain-Driven Design(DDD)에 대해 토론합니다.

이 문서에 대하여
이 문서는 DDD에 대한 서로 다른 관점을 가진 두 시니어 개발자의 토론을 기록한 것입니다. 정답을 제시하기보다는 다양한 관점을 통해 DDD에 대한 균형 잡힌 시각을 갖도록 돕는 것이 목적입니다.

참여자:

긍정파 (Pro-DDD): DDD를 지지하는 시니어 개발자
부정파 (Anti-DDD): DDD에 회의적인 시니어 개발자

일시: 2026-01-17

토론 시작#

부정파 오프닝#

솔직히 말씀드리면, 저는 DDD를 찬양하는 분들을 볼 때마다 걱정이 앞섭니다. 이론은 참 좋죠. ‘비즈니스 로직을 중심으로 설계한다’, ‘도메인 전문가와 언어를 통일한다’—누가 반대하겠습니까?

도메인 이벤트 설계하기

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

해결하는 문제: Aggregate 간 강한 결합으로 트랜잭션이 복잡해지거나, 변경 전파가 어려운 상황 소요 시간: 약 25분 전제 조건: Aggregate 심화 문서를 읽었다고 가정

성공 기준
이 가이드를 완료하면 다음을 할 수 있습니다:

도메인 이벤트가 필요한 상황 식별

이벤트 명명 규칙과 페이로드 설계

Spring의 이벤트 발행/구독 패턴 구현

1. 도메인 이벤트가 필요한 상황 식별하기#

1.1 이벤트가 필요한 3가지 신호#

다음 3가지 신호를 확인하여 도메인 이벤트가 필요한지 판단하세요.

신호 1: “~하면 ~해야 한다” 패턴

로그 수집 및 분석

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

목표: 효과적으로 로그를 수집하고 분석하여 문제를 진단합니다 예상 시간: 25분

이 가이드의 범위
다루는 내용: kubectl logs 활용, 멀티 컨테이너 로그, 로그 필터링, stern 도구

다루지 않는 내용: 중앙 로깅 시스템(ELK, Loki) 설정, 장기 로그 보관

시작하기 전에#

다음 조건을 확인하세요.

1. kubectl 설치 및 클러스터 접근 확인#

kubectl cluster-info

성공 시 출력:

Kubernetes control plane is running at https://xxx.xxx.xxx.xxx

2. 로그 접근 권한 확인#

kubectl auth can-i get pods/log

성공 시 출력:

토픽 설계 및 파티션 결정 가이드

d8lzz1gpw@mozmail.com (kimbenji) — Fri, 16 Jan 2026 00:00:00 +0000

새로운 Kafka 토픽을 생성할 때 적절한 파티션 수, 복제 팩터, 보관 정책을 결정하는 방법을 안내합니다.

소요 시간: 약 15분

TL;DR

파티션 수: 예상 처리량 / Consumer당 처리량, 최소 6개 권장

복제 팩터: 프로덕션은 3, 개발은 1

보관 기간: 비즈니스 요구사항 + 재처리 여유 시간

네이밍: {domain}.{entity}.{event-type} 패턴 사용

시작하기 전에#

필수 요구사항#

항목	요구사항	확인 명령어
Kafka CLI	설치 및 PATH 등록	`kafka-topics.sh --version`
Broker 접근	관리자 권한	`kafka-acls.sh --list`
클러스터 정보	Broker 수 파악	`kafka-broker-api-versions.sh`

환경 확인#

토픽 생성 권한과 클러스터 상태를 확인하세요:

Aggregate 실전 패턴

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: Aggregate 기본 개념을 익히고 실전 패턴을 학습하려는 개발자 선수 지식: Aggregate 심화에서 핵심 개념 이해 소요 시간: 약 30분 핵심 질문: “Aggregate 구현 시 어떤 패턴을 적용해야 하는가?”

요약
실전 패턴: Factory Method(생성) + Domain Event 발행 + Optimistic Locking(동시성) + Soft Delete(삭제)

Aggregate 실전 패턴#

Aggregate 설계를 위한 구현 패턴과 의사결정 가이드입니다.

왜 Aggregate에 패턴이 필요한가?#

Aggregate는 단순히 객체를 묶는 것이 아닙니다. 일관성, 동시성, 생명주기라는 세 가지 책임을 져야 합니다. 이 책임을 효과적으로 수행하기 위해 검증된 패턴들이 존재합니다.

Consumer 심화 운영

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

session.timeout.ms는 장애 감지, max.poll.interval.ms는 처리 시간 제한 설정

Cooperative Sticky Assignor로 리밸런싱 영향 최소화 (Kafka 2.4+)

Static Group Membership으로 재시작 시 리밸런싱 방지 가능

Consumer Lag이 가장 중요한 모니터링 지표, 추세 관찰이 핵심

kafka-consumer-groups.sh로 Offset 수동 리셋 가능 (Consumer 중지 필요)

대상 독자: Kafka Consumer를 프로덕션에서 운영하는 개발자 및 운영자

선수 지식: Consumer Group & Offset의 기본 개념, Replication의 ISR과 Leader 개념

소요 시간: 약 25-30분

리밸런싱 최적화, Consumer Lag 모니터링, 트러블슈팅을 다룹니다. 이 문서는 Kafka 3.6.x 기준으로 작성되었으며, Spring Boot 3.2.x와 Spring Kafka 3.1.x, Micrometer 1.12.x, Java 17 환경에서 코드 예제가 검증되었습니다.

histogram_quantile

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 진료 대기시간 분포 분석#

histogram_quantile을 진료 대기시간 분포 분석에 비유하면 이해하기 쉽습니다:

대기시간 분석 비유	histogram_quantile	역할
평균 대기시간	평균 (avg)	극단값에 왜곡됨
절반 환자 대기시간	P50 (중앙값)	일반적 경험
대부분 환자 대기시간	P95	95% 환자 경험
최악 대기시간	P99	SLA 기준
대기시간 구간 (0-10분, 10-30분)	Histogram 버킷	분포 저장 구조
구간 간 추정	선형 보간	버킷 사이 값 추정
세밀한 구간 설정	버킷 설계	정확도 향상

이처럼 “평균 대기시간 10분"보다 “95% 환자가 30분 이내"가 더 정확한 정보인 것처럼, 백분위가 실제 경험을 반영합니다.

Replication

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Replication Factor(RF)는 Partition 복제본 수, 프로덕션에서 RF=3 권장

Leader가 읽기/쓰기 처리, Follower는 복제만 담당하다가 장애 시 승격

ISR(In-Sync Replicas)은 Leader와 동기화된 복제본 집합

min.insync.replicas=2 + acks=all 조합으로 데이터 안전성 확보

KRaft 모드(Kafka 3.3+)로 Zookeeper 없이 클러스터 운영 가능

대상 독자: Kafka 클러스터를 운영하거나 고가용성 시스템을 설계하는 개발자 및 운영자

선수 지식: 핵심 구성요소의 Broker, Partition 개념

소요 시간: 약 15분

데이터 복제는 Kafka의 고가용성과 내결함성의 핵심입니다. 이를 은행 금고 시스템에 비유하면 이해하기 쉽습니다:

Saturation (포화도)

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 병원 수용 능력#

Saturation을 **병원의 수용 능력(병상/장비/인력)**에 비유하면 이해하기 쉽습니다:

병원 수용력 비유	Saturation 개념	역할
병상 점유율	리소스 사용률	현재 자원 사용 상태
의사 업무 포화	CPU 포화도	처리 능력 한계
수술실 대기열	요청 대기열	처리 대기 중인 작업
의약품 재고	메모리 사용량	가용 자원 현황
창고 공간	디스크 사용률	저장 공간 여유
응급실 만석 경고	임계값 알림	한계 도달 전 경고
병원 확장 계획	용량 계획	자원 증설 계획
여유 병상 확보	헤드룸 (20%)	버퍼 공간 유지

이처럼 병원이 병상 점유율을 모니터링하여 응급 상황에 대비하듯, 시스템도 리소스 포화도를 감시합니다.

Service

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 인터폰/안내 시스템#

Service를 아파트 인터폰 시스템에 비유하면 이해하기 쉽습니다:

아파트 인터폰 비유	Kubernetes Service	역할
동 현관 인터폰	Service	고정된 접근점으로 세대 연결
인터폰 번호 (101동)	ClusterIP	변하지 않는 내부 주소
세대 호수 변경되어도 인터폰 동일	Pod IP 변경 무관	Service IP는 고정
같은 세대 여러 명에게 연결	Load Balancing	여러 Pod에 트래픽 분산
내부 인터폰	ClusterIP	단지 내부에서만 통화 가능
외부 전화 연결	NodePort	외부에서 특정 포트로 연결
대표 전화번호	LoadBalancer	외부 고정 IP로 연결
입주민 명부	Endpoints	Service가 관리하는 Pod IP 목록
“101동 김철수네”	DNS	이름으로 Service 접근

이처럼 Service는 “세대 번호가 바뀌어도 인터폰 번호는 그대로여서 항상 연결 가능"한 것과 같습니다.

Spark SQL

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Spark SQL은 SQL 문법으로 DataFrame을 쿼리할 수 있는 모듈

Catalyst Optimizer가 4단계(Analysis → Optimization → Planning → CodeGen)로 쿼리 최적화

AQE(Adaptive Query Execution)로 런타임 최적화 (Spark 3.0+)

DataFrame API와 SQL은 동일한 실행 엔진 사용, 성능 차이 없음

대상 독자: SQL에 익숙한 데이터 엔지니어 및 분석가

선수 지식:

표준 SQL 문법 (SELECT, JOIN, GROUP BY, Window 함수)
DataFrame과 Dataset 기본 이해

소요 시간: 약 25-30분

Spark SQL은 구조화된 데이터 처리를 위한 Spark 모듈입니다. SQL 쿼리와 DataFrame API를 모두 지원하며, 동일한 실행 엔진(Catalyst Optimizer)을 사용합니다.

검색 관련성

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

선수 개념
이 문서를 읽기 전에 다음 개념을 먼저 이해하세요:

Query DSL - match, bool 쿼리 기본

데이터 모델링 - Analyzer 동작 원리

소요 시간: 약 25-30분

전체 비유: 도서관 사서의 책 추천#

검색 관련성을 도서관 사서가 책을 추천하는 방식에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
추천 우선순위 점수	Score	얼마나 관련 있는지 수치화
“이 책에서 해당 주제를 많이 다뤄요”	TF (Term Frequency)	검색어가 문서에 많이 등장할수록 점수 상승
“이 주제를 다루는 책이 드물어요”	IDF (Inverse Doc Frequency)	희귀한 단어일수록 점수 상승
“제목에서 바로 찾았어요”	Field Length	짧은 필드에서 일치하면 점수 상승
“제목 일치는 가산점”	필드 부스팅	중요 필드에 가중치 부여 (name^3)
“신간이라 추천해요”	Decay Function	시간/거리에 따라 점수 조정
“베스트셀러는 우선 추천”	Function Score	인기도, 평점 등 비즈니스 로직 반영
“절판 도서는 후순위”	Negative Boosting	특정 조건의 점수 감소

이처럼 Score는 사서가 “이 책이 당신 질문에 가장 적합합니다"라고 판단하는 기준과 같습니다.

어니언 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: DDD와 잘 어울리는 아키텍처를 찾는 개발자 선수 지식: 헥사고날 아키텍처와 의존성 역전 원칙 소요 시간: 약 20분

어니언 아키텍처 (Onion Architecture)#

Jeffrey Palermo가 2008년에 제안한 아키텍처입니다. 도메인 모델을 가장 중심에 두고, 양파처럼 겹겹이 감싸는 구조입니다.

어니언 아키텍처는 전통적인 계층형 아키텍처의 한계에서 출발합니다. 계층형 아키텍처에서는 상위 계층이 하위 계층에 의존하므로, 데이터베이스 계층의 변경이 서비스 계층에 연쇄적인 영향을 미칩니다. 반면 어니언 아키텍처에서는 도메인 모델이 어떤 것에도 의존하지 않고, 인프라스트럭처가 도메인에 의존하는 방향으로 설계합니다. 이를 통해 도메인 로직은 데이터베이스, 프레임워크, 외부 서비스의 변화와 무관하게 순수한 비즈니스 규칙만을 표현할 수 있습니다. DDD(Domain-Driven Design)와 특히 잘 어울리는 이유도 여기에 있습니다.

클래스와 객체

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 회사 조직도#

Scala의 클래스, 객체, 트레이트를 회사 조직도에 비유하면 이해하기 쉽습니다:

회사 조직 비유	Scala 개념	역할
직원 (여러 명 가능)	class	인스턴스를 여러 개 생성 가능
CEO (한 명만)	object (싱글톤)	프로그램에서 단 하나만 존재
비서실 (직원 보조)	컴패니언 객체	클래스의 정적 멤버 역할
역할/자격증 (조합 가능)	trait	여러 개 믹스인 가능
부서 템플릿	abstract class	상속받아 구체화
직급 체계	상속	extends로 확장
공개/비공개 정보	접근 제어자	private, protected

이처럼 회사에서 다양한 역할이 조합되어 조직을 구성하듯, Scala에서는 클래스, 객체, 트레이트가 조합되어 프로그램을 구성합니다.

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

공식 문서#

Prometheus#

자료	링크	설명
Prometheus 공식 문서	https://prometheus.io/docs/	설정, PromQL, 운영 가이드
PromQL 참조	https://prometheus.io/docs/prometheus/latest/querying/basics/	쿼리 언어 상세
Alerting Rules	https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/	알림 규칙 작성

Grafana#

자료	링크	설명
Grafana 공식 문서	https://grafana.com/docs/grafana/latest/	대시보드, 패널 설정
Loki 문서	https://grafana.com/docs/loki/latest/	로그 수집/쿼리
Tempo 문서	https://grafana.com/docs/tempo/latest/	분산 추적

OpenTelemetry#

자료	링크	설명
OpenTelemetry 공식	https://opentelemetry.io/docs/	개념, SDK, Collector
Java 계측	https://opentelemetry.io/docs/languages/java/	Java 자동/수동 계측
Semantic Conventions	https://opentelemetry.io/docs/concepts/semantic-conventions/	표준화된 속성 이름

도서#

필수#

도서	저자	내용
Site Reliability Engineering	Google SRE Team	SRE 원칙, 황금 신호, SLO
Observability Engineering	Charity Majors, Liz Fong-Jones	현대적 관측성 개념
The SRE Workbook	Google SRE Team	SRE 실전 적용

권장#

도서	저자	내용
Prometheus: Up & Running	Brian Brazil	Prometheus 상세 가이드
Distributed Tracing in Practice	Austin Parker 외	분산 추적 심화
Database Reliability Engineering	Laine Campbell, Charity Majors	DB 관측성

블로그 & 아티클#

Prometheus/Grafana#

Prometheus Best Practices - 공식 권장사항
Grafana Blog - 새 기능, 사례 연구
Robust Perception Blog - Brian Brazil의 Prometheus 팁

SRE/Observability#

Google SRE Books (무료) - 전체 내용 무료 공개
Honeycomb Blog - 관측성 심화
Charity Majors’ Blog - 관측성 리더의 인사이트

영상#

컨퍼런스#

영상	링크	내용
PromCon	https://www.youtube.com/@PrometheusIo	Prometheus 컨퍼런스
GrafanaCon	https://www.youtube.com/@Grafana	Grafana 컨퍼런스
KubeCon	https://www.youtube.com/@caborgg	Kubernetes, 관측성 세션

튜토리얼#

Prometheus Tutorial for Beginners - TechWorld with Nana
Grafana Tutorials - Grafana 공식

온라인 코스#

코스	플랫폼	설명
Prometheus & Grafana	Udemy	실습 중심
Site Reliability Engineering	Coursera	Google의 SRE 코스
Observability with OpenTelemetry	Linux Foundation	OTel 입문

커뮤니티#

Slack#

Prometheus Users
Grafana Community
CNCF Slack - #prometheus, #opentelemetry

GitHub#

프로젝트	링크
Prometheus	https://github.com/prometheus/prometheus
Grafana	https://github.com/grafana/grafana
Loki	https://github.com/grafana/loki
Tempo	https://github.com/grafana/tempo
OpenTelemetry	https://github.com/open-telemetry

대시보드 & 규칙#

Grafana 대시보드#

ID	이름	용도
1860	Node Exporter Full	서버 모니터링
3662	Prometheus Stats	Prometheus 자체 모니터링
4701	JVM Micrometer	Spring Boot JVM
7362	MySQL Overview	MySQL 모니터링
7587	PostgreSQL	PostgreSQL 모니터링
11074	Kafka Exporter	Kafka 모니터링

https://grafana.com/grafana/dashboards/ 에서 검색 가능

풀스택 Observability

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 12 Jan 2026 00:00:00 +0000

소요 시간: 30분 선수 지식: Spring Boot 메트릭 이 문서를 읽으면: 3요소(Metrics, Logs, Traces)를 연결하여 문제를 추적할 수 있습니다

목표#

“에러율 급증” → “로그에서 trace_id 확인” → “트레이스로 근본 원인 파악”

graph LR
 A["1. Metrics<br>에러율 5% 감지"]
 B["2. Logs<br>trace_id 확인"]
 C["3. Traces<br>병목 구간 발견"]
 D["4. 해결<br>DB 쿼리 최적화"]

 A --> B --> C --> D

시나리오: 주문 서비스 장애 분석#

시스템 구성#

graph LR
 USER["User"] --> GW["API Gateway"]
 GW --> ORDER["Order Service"]
 ORDER --> PAYMENT["Payment Service"]
 ORDER --> INVENTORY["Inventory Service"]
 PAYMENT --> DB["Payment DB"]

Step 1: 장애 감지 (Metrics)#

Grafana Alert 발동#

Alert: HighErrorRate
Service: order-service
Error Rate: 5.2%
Threshold: 1%

대시보드 확인#

# 에러율 급증 확인
sum(rate(http_server_requests_seconds_count{application="order-service",status=~"5.."}[5m]))
/ sum(rate(http_server_requests_seconds_count{application="order-service"}[5m]))

# 어떤 엔드포인트?
sum by (uri) (rate(http_server_requests_seconds_count{application="order-service",status=~"5.."}[5m]))

결과: /orders POST 엔드포인트에서 에러 발생

Event Sourcing 실습

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Event Sourcing: 상태 대신 이벤트를 저장. 이벤트 재생으로 상태 복원

Event Store: 이벤트 영속화 저장소. 버전 기반 낙관적 동시성 제어

Event-Sourced Aggregate: apply/when 패턴으로 이벤트 적용 및 상태 변경

Snapshot: 성능 최적화를 위해 주기적으로 상태 스냅샷 저장

시점 복원: 특정 버전까지의 이벤트만 재생하여 과거 상태 조회 가능

대상 독자 및 선수 지식#

항목	요구 수준
대상 독자	Event Sourcing 패턴을 실제로 구현해보려는 개발자
DDD	Aggregate, Domain Event 개념 이해
Java	Switch Expression, Pattern Matching 문법
선수 문서	주문 도메인, 애플리케이션 계층 완료

Event Sourcing 패턴을 실제 주문 도메인에 구현합니다. 상태 대신 이벤트를 저장하고, 이벤트를 재생하여 상태를 복원합니다.

Spark 연동

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Scala는 Spark의 네이티브 언어: 최신 기능 가장 먼저 지원, 가장 간결한 API

DataFrame: SQL 스타일 데이터 처리, $"column" 문법으로 컬럼 참조

Dataset[T]: Case Class로 타입 안전한 데이터 처리, 컴파일 타임 오류 검출

성능 최적화: 브로드캐스트 조인, 캐싱, Predicate Pushdown 활용

주의: Spark 3.5는 Scala 2.12/2.13만 지원 (Scala 3 미지원)

대상 독자: 대규모 데이터 처리를 배우려는 Scala 개발자, Spark 입문자

선수 지식:

Scala 기본 문법 및 함수형 프로그래밍 개념
sbt 빌드 도구 사용법
SQL 기초 (권장)

Scala로 Apache Spark를 활용하는 방법을 배웁니다. Scala는 Spark의 네이티브 언어로, 가장 풍부한 API를 제공합니다. Spark 자체가 Scala로 작성되었기 때문에 새로운 기능이 가장 먼저 Scala API에 추가되며, 타입 안전성과 함수형 프로그래밍의 장점을 최대한 활용할 수 있습니다.

로그 분석 시스템

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

완전한 예제 프로젝트
이 문서의 코드를 바로 실행해보고 싶다면, 완전한 Spring Boot 프로젝트를 사용하세요:

📁 examples/elasticsearch/log-analysis/

docker-compose로 Elasticsearch + Kibana 즉시 실행 가능

샘플 로그 생성 API 포함

TL;DR

Logback Appender로 애플리케이션 로그를 Elasticsearch에 직접 전송합니다

MDC로 요청 ID, 사용자 ID를 로그에 자동 포함하여 추적성을 확보합니다

**집계(Aggregation)**로 에러율, 응답시간 백분위수 등을 분석합니다

ILM으로 로그 수명주기(Hot→Warm→Cold→Delete)를 자동 관리합니다

전체 소요 시간: 약 40분

Elasticsearch를 사용하여 애플리케이션 로그를 수집, 저장, 분석하는 시스템을 구현합니다.

버전 정보

Elasticsearch: 8.11.x

Spring Boot: 3.2.x

Logback: Spring Boot 기본 포함

구현 목표#

flowchart LR
 A[Spring Boot App] -->|Logback| B[Elasticsearch]
 B --> C[Kibana Dashboard]
 B --> D[알림/모니터링]

로그 수집: 애플리케이션 로그를 Elasticsearch에 직접 저장
실시간 검색: 에러 로그, 특정 사용자 요청 추적
대시보드: 에러율, 응답시간 분포 시각화
알림: 에러 급증 시 알림

1. 인덱스 설계#

로그 인덱스 매핑#

PUT /_index_template/logs
{
 "index_patterns": ["logs-*"],
 "template": {
 "settings": {
 "number_of_shards": 2,
 "number_of_replicas": 1,
 "refresh_interval": "5s"
 },
 "mappings": {
 "properties": {
 "@timestamp": {
 "type": "date"
 },
 "level": {
 "type": "keyword"
 },
 "logger": {
 "type": "keyword"
 },
 "thread": {
 "type": "keyword"
 },
 "message": {
 "type": "text",
 "fields": {
 "keyword": {
 "type": "keyword",
 "ignore_above": 256
 }
 }
 },
 "exception": {
 "type": "text"
 },
 "stack_trace": {
 "type": "text",
 "index": false
 },
 "application": {
 "type": "keyword"
 },
 "environment": {
 "type": "keyword"
 },
 "host": {
 "type": "keyword"
 },
 "request_id": {
 "type": "keyword"
 },
 "user_id": {
 "type": "keyword"
 },
 "duration_ms": {
 "type": "long"
 },
 "http_method": {
 "type": "keyword"
 },
 "http_path": {
 "type": "keyword"
 },
 "http_status": {
 "type": "integer"
 }
 }
 }
 }
}

일별 인덱스 패턴#

logs-2024.01.15
logs-2024.01.16
logs-2024.01.17

장점: 오래된 로그 삭제가 쉬움 (인덱스 단위 삭제)

마이크로서비스 연동

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

마이크로서비스 환경에서 Kafka를 활용한 이벤트 기반 통신을 구현합니다.

TL;DR

이벤트 체이닝: 주문 -> 결제 -> 배송 -> 알림 순서로 이벤트 전파

Correlation ID: 분산 추적을 위한 상관 ID 전파

Saga 패턴: 보상 트랜잭션으로 분산 트랜잭션 처리

멱등성: 중복 메시지 안전하게 처리

대상 독자 및 선수 지식#

항목	설명
대상 독자	마이크로서비스 아키텍처에서 이벤트 기반 통신을 구축하려는 개발자
선수 지식	Kafka 기본, Spring Boot, 주문 시스템 예제 이해
필수 환경	Docker, JDK 17+, 여러 서비스를 실행할 수 있는 환경
예상 소요 시간	약 60분

시나리오: 주문 처리 시스템#

이 예제에서는 주문 서비스, 결제 서비스, 배송 서비스, 알림 서비스가 Kafka를 통해 이벤트를 주고받습니다. 주문 서비스가 주문을 생성하면 orders Topic에 이벤트를 발행합니다. 결제 서비스가 이를 수신하여 결제를 처리하고 payments Topic에 결과를 발행합니다. 배송 서비스는 결제 완료 이벤트를 수신하여 배송을 생성합니다. 알림 서비스는 모든 Topic을 구독하여 고객에게 알림을 발송합니다.

모니터링 설정

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

Spark UI: 실시간 작업 상태, 실행 계획, 메모리 사용량 확인 (:4040)

History Server: 종료된 애플리케이션 로그 분석 (:18080)

Prometheus + Grafana: 메트릭 수집 및 시각화, 알림 설정

커스텀 메트릭: 비즈니스 KPI (처리량, 실패율, 처리 시간) 추적

대상 독자 및 선수 지식#

구분	내용
대상 독자	Spark 애플리케이션을 운영하는 DevOps/데이터 엔지니어
선수 지식	Spark 기본 동작, 기본 예제 완료, Prometheus/Grafana 경험 (선택)
학습 목표	Spark 애플리케이션의 상태를 모니터링하고 문제를 진단할 수 있다
예상 소요 시간	약 35분

프로덕션 환경에서 Spark 애플리케이션을 안정적으로 운영하기 위한 모니터링 설정 가이드입니다.

자주 묻는 질문

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Kafka를 사용하면서 자주 받는 질문과 답변을 정리했습니다. 기본 개념부터 설정, 에러 처리, 성능 튜닝, 운영, Spring Kafka까지 주제별로 구성했습니다.

TL;DR

기본 개념: Kafka는 메시지 큐가 아닌 분산 이벤트 스트리밍 플랫폼, Partition 단위 순서 보장

설정: acks=all로 안정성 확보, auto.offset.reset=earliest 권장, 수동 커밋으로 메시지 유실 방지

에러 처리: @RetryableTopic으로 재시도 후 Dead Letter Topic으로 이동

성능: Producer는 배치/압축, Consumer는 인스턴스 수 증가 및 fetch 설정 조정

운영: replication.factor=3, min.insync.replicas=2 권장

Spring Kafka: KafkaTemplate과 @KafkaListener로 간편하게 구현

기본 개념#

Q: Kafka는 메시지 큐인가요?

참고 자료

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

Scala 학습에 도움이 되는 참고 자료를 정리합니다. 공식 문서부터 서적, 온라인 강의, 커뮤니티까지 다양한 리소스를 카테고리별로 분류했습니다.

TL;DR - 핵심 추천

공식 문서: Scala 3 Book - 단계별 학습서

입문서: “Scala for the Impatient” - 빠른 학습에 최적

함수형 심화: “Scala with Cats” (무료 온라인) - 타입 클래스 마스터

온라인 실습: Scastie - 브라우저에서 즉시 실행

커뮤니티: Scala Discord - 실시간 질의응답

공식 문서#

Scala 공식 사이트와 문서는 가장 정확하고 최신의 정보를 제공합니다.

RBAC 설정 실습

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

대상 독자: Kubernetes 클러스터의 접근 제어를 설정하고 싶은 개발자/운영자 선수 지식: Namespace, Pod, Deployment 개념 이 문서를 읽으면: Role, RoleBinding, ServiceAccount를 활용한 네임스페이스별 접근 제어를 구성할 수 있습니다

TL;DR

개발팀용 제한된 권한 Role을 만듭니다

ServiceAccount를 생성하고 Role에 바인딩합니다

kubectl auth can-i로 권한을 테스트합니다

네임스페이스별로 접근 권한을 분리합니다

RBAC 구조#

flowchart TD
 SA[ServiceAccount] -->|바인딩| RB[RoleBinding]
 R[Role] -->|참조| RB
 RB -->|권한 부여| NS[Namespace 리소스]

 SA2[ServiceAccount] -->|바인딩| CRB[ClusterRoleBinding]
 CR[ClusterRole] -->|참조| CRB
 CRB -->|권한 부여| CL[클러스터 전체 리소스]

리소스	범위	설명
Role	Namespace	특정 Namespace 내 리소스 권한
ClusterRole	Cluster	클러스터 전체 리소스 권한
RoleBinding	Namespace	Role/ClusterRole을 주체에 바인딩
ClusterRoleBinding	Cluster	ClusterRole을 주체에 바인딩

사전 준비#

다음이 필요합니다:

성능 프로파일링

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Scala 애플리케이션의 성능 병목을 찾고 최적화하는 방법을 안내합니다.

소요 시간: 약 20-25분

TL;DR

CPU 프로파일링: JFR(Java Flight Recorder)로 핫스팟 식별

메모리 분석: 힙 덤프를 VisualVM 또는 MAT로 분석

컬렉션 선택: 용도에 맞는 컬렉션을 사용하면 성능이 크게 달라짐

최적화 기법: @specialized, @tailrec, 박싱 회피

이 가이드가 해결하는 문제#

다음 상황에서 이 가이드를 사용하세요:

애플리케이션의 응답 시간이 갑자기 느려진 경우
메모리 사용량이 지속적으로 증가하는 경우 (메모리 누수 의심)
어떤 컬렉션을 사용해야 할지 성능 관점에서 결정이 필요한 경우
GC 일시 정지가 빈번하게 발생하는 경우

이 가이드가 다루지 않는 것#

JVM 튜닝 (GC 옵션 등): JVM 공식 문서를 참조하세요
분산 시스템 성능 최적화: 별도 주제입니다
Cats Effect / ZIO의 성능 최적화: 해당 라이브러리 문서를 참조하세요

시작하기 전에#

다음 환경이 준비되어 있는지 확인하세요:

클러스터 확장

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

Elasticsearch 클러스터를 안전하게 확장하는 방법을 안내합니다.

소요 시간: 약 30-60분 (노드 추가 및 샤드 재배치 시간 별도)

이 가이드의 범위
다루는 내용: 데이터 노드 추가, 역할별 노드 분리, Hot-Warm-Cold 아키텍처, 확장 후 검증

다루지 않는 내용: 쿼리 수준 성능 최적화는 느린 쿼리 최적화를, 메모리 문제는 메모리 문제 해결을 참조하세요.

TL;DR

수평 확장: 데이터 노드를 추가하고 샤드를 재배치

역할 분리: master, data, coordinating, ingest 노드를 분리하여 안정성 확보

Hot-Warm-Cold: 데이터 사용 빈도에 따라 노드 계층을 구분하여 비용 최적화

확장 후 검증: 클러스터 상태, 샤드 분포, 성능 지표를 반드시 확인

시작하기 전에#

다음 조건을 확인하세요:

ConfigMap과 Secret

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 게시판과 우편함#

ConfigMap과 Secret을 아파트 게시판과 우편함에 비유하면 이해하기 쉽습니다:

아파트 비유	Kubernetes	역할
로비 게시판	ConfigMap	모든 입주민이 볼 수 있는 공지사항
개인 우편함 (비밀번호)	Secret	민감한 정보 보관
게시판 내용	data (평문)	일반 설정 값
우편함 내용	data (Base64)	인코딩된 민감 정보
게시판 읽고 메모	환경 변수 주입	설정을 Pod에 전달
게시판 사진 찍어가기	볼륨 마운트	파일로 설정 전달
게시판 내용 변경	ConfigMap 업데이트	설정 변경 (재시작 필요할 수도)
DB 접속 정보	Secret	비밀번호, API 키 등
Wi-Fi 비밀번호 공유	ConfigMap	공개해도 되는 설정

이처럼 ConfigMap은 “게시판에 붙여 모두가 보는 공지"이고, Secret은 “개인 우편함에 넣어 본인만 확인하는 정보"입니다.

CQRS

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 복잡한 조회 요구사항이나 성능 최적화가 필요한 시스템을 설계하는 개발자 선수 지식: 이벤트 기반 아키텍처 또는 이벤트 기반 아키텍처 기본 개념 소요 시간: 약 35분 핵심 질문: “언제 읽기와 쓰기 모델을 분리해야 하는가?”

요약
CQRS 핵심: Command(상태 변경, 도메인 모델 사용) ↔ Query(조회, 최적화된 읽기 모델 사용) 분리로 각각의 요구사항에 맞게 최적화

비유: 도서관
CQRS를 도서관 운영에 비유할 수 있습니다:

기존 방식(단일 모델): 도서 관리자가 책 대출/반납도 처리하고, 도서 검색 요청도 처리합니다. 대출이 밀리면 검색도 느려지고, 검색이 많으면 대출도 느려집니다.

CQRS 방식: 대출 담당자(Command)와 검색 사서(Query)를 분리합니다. 대출 담당자는 책의 상태를 변경하고, 검색 사서는 최적화된 색인(인덱스)을 활용하여 빠르게 응답합니다.

핵심: 대출(쓰기)과 검색(읽기)의 요구사항이 다르므로 각각에 최적화된 방식으로 처리합니다. 대출은 정합성이 중요하고, 검색은 속도가 중요합니다.

Recording Rules

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 정기 통계 보고서#

Recording Rules를 병원의 정기 통계 보고서에 비유하면 이해하기 쉽습니다:

정기 보고서 비유	Recording Rules	역할
매일 계산하는 월간 통계	사전 계산	복잡한 쿼리 미리 계산
정기 보고서 템플릿	규칙 정의	반복 계산 자동화
보고서 저장	새 메트릭 생성	결과를 메트릭으로 저장
일간→주간→월간 요약	계층적 집계	단계별 요약
부서별 통계	by 그룹화	그룹별 사전 계산
경영진 대시보드	대시보드 최적화	빠른 조회 지원
표준 보고서 명명규칙	네이밍 컨벤션	일관된 메트릭 이름

이처럼 병원에서 복잡한 통계를 매일 미리 계산해두듯, Recording Rules로 자주 쓰는 쿼리를 사전 계산합니다.

Transformation과 Action

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Transformation은 지연 평가(Lazy)되어 DAG에 추가만 됨

Action 호출 시 전체 DAG가 실행되어 Job 생성

Narrow(셔플 없음) vs Wide(셔플 발생) Transformation 구분이 성능 핵심

같은 DataFrame을 여러 번 사용하면 매번 재계산 → 캐싱 필요

대상 독자: Spark 연산의 실행 시점을 이해하고자 하는 개발자

선수 지식:

아키텍처 문서의 Job, Stage, Task 개념
Java Stream API의 지연 평가 개념

소요 시간: 약 25-30분

Spark의 모든 연산은 Transformation과 Action 두 가지로 분류됩니다. 이 구분을 이해하는 것이 Spark 프로그래밍의 핵심입니다.

서비스 유형별 적용

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 병원 부서별 핵심 지표#

서비스 유형별 황금 신호를 병원 부서별 핵심 지표에 비유하면 이해하기 쉽습니다:

병원 부서	서비스 유형	핵심 지표
외래 진료실	웹 API	진료 대기시간 (Latency), 진료 오류율 (Errors)
검사실 (혈액검사)	Kafka	검체 처리량 (Traffic), 대기 검체 수 (Lag)
데이터베이스 (EMR)	데이터베이스	조회 속도 (Latency), 연결 포화도 (Saturation)
약국	캐시 (Redis)	조제 시간 (Latency), 재고 현황 (Saturation)
야간 정산	배치 작업	정산 오류율 (Errors), 처리 완료율 (Traffic)
로비 안내 데스크	로드 밸런서	안내 건수 (Traffic), 연결 오류 (Errors)

이처럼 병원의 각 부서가 서로 다른 핵심 지표를 모니터링하듯, 서비스 유형에 따라 우선 모니터링할 황금 신호가 다릅니다.

심화 개념

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

acks=0(빠름/유실 가능), acks=1(Leader만 확인), acks=all(ISR 전체 확인, 권장)

acks=all + min.insync.replicas=2 조합으로 데이터 안전성 확보

Message Key로 같은 Partition에 전송하여 순서 보장, Partition 수 변경 주의

Retention: 시간 기반 삭제(기본 7일), 용량 기반 삭제, Log Compaction

Idempotent Producer(Kafka 3.0+ 기본)로 네트워크 오류 시 중복 방지

대상 독자: Kafka의 심화 개념을 이해하고 프로덕션 설정을 최적화하려는 개발자

선수 지식: 메시지 흐름의 Topic, Partition, Broker 개념, Replication의 ISR, Leader, Follower 개념

소요 시간: 약 25-30분

집계

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

선수 개념
이 문서를 읽기 전에 다음 개념을 먼저 이해하세요:

Query DSL - 기본 쿼리 구조

데이터 모델링 - keyword vs text 타입

소요 시간: 약 25-30분

전체 비유: 도서관 통계 분석#

Aggregation을 도서관의 장서 통계 분석에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
“분야별로 몇 권씩 있나요?”	Bucket (terms)	값별로 그룹화
“가격대별 도서 수는?”	Bucket (range)	범위별로 그룹화
“월별 대출 추이는?”	Bucket (date_histogram)	시간별로 그룹화
“평균 도서 가격은?”	Metric (avg)	숫자 통계 계산
“분야별 평균 가격은?”	중첩 집계	그룹 내 통계
“월별 대출 증감률은?”	Pipeline	집계 결과 재가공
“전체 장서 대비 검색 결과 비율?”	Global	필터 무시한 전체 통계

이처럼 Aggregation은 사서에게 “장서 현황 보고서를 만들어 주세요"라고 요청하는 것과 같습니다.

케이스 클래스

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 공식 서류 양식#

케이스 클래스를 공식 서류 양식에 비유하면 이해하기 쉽습니다:

서류 양식 비유	Scala 개념	역할
양식 칸 (이름, 주민번호)	필드 (val)	자동으로 읽기 전용
양식 복사 (일부 수정)	copy 메서드	일부 필드만 변경한 복사본
동일 양식 비교	equals/hashCode	내용으로 동등성 비교
양식 번호 부여	apply	new 없이 생성
양식에서 정보 추출	unapply	패턴 매칭으로 분해
양식 인쇄	toString	읽기 좋은 문자열 표현
양식 종류 (신청서/계약서)	sealed + ADT	닫힌 타입 계층

이처럼 공식 서류가 불변하고 복사/비교/추출이 용이하듯, 케이스 클래스는 불변 데이터 모델링에 최적화되어 있습니다.

Spring Boot 통합

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

SparkSession Bean: @Configuration으로 싱글톤 관리, @PreDestroy로 정리

프로파일 분리: local, production, test 환경별 Spark 설정

비동기 배치: @Async + CompletableFuture로 대용량 처리

REST API: DataFrame 결과를 JSON 응답으로 변환

대상 독자 및 선수 지식#

구분	내용
대상 독자	Spring Boot 애플리케이션에 Spark를 통합하려는 백엔드 개발자
선수 지식	Spring Boot 기초, 환경 설정 완료, Spark DataFrame API
학습 목표	Spring Boot에서 Spark를 활용한 데이터 분석 API를 구현할 수 있다
예상 소요 시간	약 40분

Java/Spring 개발자를 위한 Spark와 Spring Boot 통합 패턴입니다.

실무 프로젝트

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

REST API 서버: http4s + Circe + Cats Effect로 함수형 웹 서버 구축

데이터 파이프라인: FS2로 메모리 효율적인 스트림 처리

CLI 도구: scopt로 타입 안전한 명령줄 파서 구현

에러 처리: Cats Validated로 여러 검증 오류 동시 수집

모든 예제는 불변성, 참조 투명성, 타입 안전성을 강조하는 함수형 스타일

대상 독자: Scala로 실제 서비스를 구축하려는 개발자

선수 지식:

Scala 기본 문법 및 함수형 프로그래밍 개념
sbt 빌드 도구 사용법
REST API 및 HTTP 기본 개념 (프로젝트 1)
(선택) Cats Effect/IO 모나드 기초 지식

Scala로 실제 서비스를 구축하는 예제입니다. REST API 서버와 데이터 파이프라인을 구현합니다. 이 예제들은 Scala의 함수형 프로그래밍 특성을 활용하여 타입 안전하고 유지보수하기 쉬운 코드를 작성하는 방법을 보여줍니다.

CronJob 실습

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

대상 독자: Kubernetes에서 주기적 작업을 스케줄링하고 싶은 개발자 선수 지식: Pod, Job 개념 이 문서를 읽으면: CronJob으로 주기적 백업 작업을 만들고, 실행 이력과 동시 실행 정책을 관리할 수 있습니다

TL;DR

CronJob으로 주기적 데이터 백업을 자동화합니다

successfulJobsHistoryLimit로 실행 이력을 관리합니다

concurrencyPolicy로 동시 실행을 제어합니다

실패 시 알림을 설정합니다

CronJob 동작 흐름#

flowchart TD
 CRON[CronJob Controller] -->|스케줄에 따라| JOB[Job 생성]
 JOB --> POD[Pod 실행]
 POD -->|성공| SUCCESS[완료 기록]
 POD -->|실패| RETRY{재시도?}
 RETRY -->|backoffLimit 이내| POD
 RETRY -->|초과| FAIL[실패 기록]

 SUCCESS --> HIST[이력 관리<br>successfulJobsHistoryLimit]
 FAIL --> HIST2[이력 관리<br>failedJobsHistoryLimit]

사전 준비#

다음이 필요합니다:

도메인 모델 패턴

d8lzz1gpw@mozmail.com (kimbenji) — Tue, 17 Feb 2026 00:00:00 +0000

대상 독자: 전술적 설계 빌딩 블록을 이해한 백엔드 개발자 선수 지식: Entity, Value Object, Repository, Domain Service 개념 이해 소요 시간: 약 25-30분 핵심 질문: “핵심 빌딩 블록만으로 표현하기 어려운 도메인 로직을 어떻게 구조화하는가?”

요약
핵심 빌딩 블록(Entity, Value Object, Repository, Domain Service, Factory)은 도메인 모델의 뼈대입니다. 이 문서에서 다루는 패턴들은 그 뼈대 위에 비즈니스 규칙을 체계적으로 표현하는 도구입니다: Specification(조건 검사) + Policy(계산/결정) + Module(코드 조직) + Builder(복잡한 생성) + Null Object(null 안전성)

전술적 설계의 핵심 빌딩 블록만으로도 도메인 모델을 구현할 수 있습니다. 하지만 실제 비즈니스는 더 복잡한 요구사항을 가집니다. “이 주문은 확정 가능한가?“라는 조건 검사, “VIP 고객에게는 몇 % 할인을 적용하는가?“라는 정책 결정, 그리고 여러 모듈에 걸친 코드 조직까지 — 이런 문제를 깔끔하게 해결하는 보조 패턴들을 알아보겠습니다.

Alerting Rules

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 환자 모니터 경보 시스템#

Alerting Rules를 중환자실 환자 모니터 경보 시스템에 비유하면 이해하기 쉽습니다:

환자 모니터 비유	Alerting Rules	역할
맥박 비정상 조건	expr (조건)	알림 발동 조건 정의
5분간 지속 시 알림	for (지속 시간)	일시적 변동 무시
긴급/주의 분류	severity 라벨	심각도 구분
담당 의료진 호출	알림 라우팅	적절한 담당자에게 전달
알림 상세 정보	annotations	문제 설명, 조치 가이드
경보 피로 방지	적절한 임계값	의미 있는 알림만
연쇄 경보 억제	inhibition	중복 알림 방지
대응 매뉴얼 링크	runbook_url	문제 해결 가이드

이처럼 환자 모니터가 이상 징후를 감지하여 의료진에게 알리듯, Alerting Rules로 시스템 문제를 감지합니다.

Volume과 스토리지

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 수납공간과 창고#

Volume과 스토리지를 아파트 수납공간에 비유하면 이해하기 쉽습니다:

아파트 수납 비유	Kubernetes	역할
세대 내 붙박이장	emptyDir	Pod와 함께 생성/삭제되는 임시 공간
단지 공용 창고	PersistentVolume (PV)	이사해도 유지되는 외부 저장소
창고 사용 신청서	PersistentVolumeClaim (PVC)	필요한 용량과 조건 요청
창고 자동 배정 시스템	StorageClass	요청 시 자동으로 창고 할당
세대 간 물건 공유	Volume Mount	컨테이너 간 데이터 공유
개인만 사용	ReadWriteOnce (RWO)	단일 노드에서만 읽기/쓰기
여러 세대가 읽기만	ReadOnlyMany (ROX)	여러 노드에서 읽기 전용
여러 세대가 함께 사용	ReadWriteMany (RWX)	여러 노드에서 읽기/쓰기
퇴거 시 창고 처리	Reclaim Policy	Retain(유지), Delete(삭제)

이처럼 emptyDir은 “이사하면 사라지는 붙박이장"이고, PV/PVC는 “이사해도 물건이 남아있는 별도 창고"입니다.

이벤트 기반 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 도메인 모델링과 트랜잭션 개념을 이해한 개발자 선수 지식: 어니언 아키텍처 또는 Aggregate 경계 개념에 대한 이해 소요 시간: 약 30분 핵심 질문: “도메인 이벤트를 언제, 왜 사용해야 하는가?”

이벤트 기반 아키텍처 (Event-Driven Architecture)#

비유: 회사 공지 시스템
도메인 이벤트를 회사 공지 시스템에 비유할 수 있습니다:

이벤트 발행: 인사팀에서 “신입 사원 입사” 공지를 보냅니다. 인사팀은 누가 이 공지를 볼지 모르고, 알 필요도 없습니다.

이벤트 구독: IT팀은 공지를 보고 계정을 생성하고, 총무팀은 명함을 주문하며, 교육팀은 신입 교육 일정을 잡습니다. 각 부서가 독립적으로 행동합니다.

느슨한 결합: 인사팀이 IT팀의 존재를 모르더라도 시스템은 작동합니다. 나중에 “환영 선물 담당 팀"이 추가되어도 인사팀은 수정할 필요가 없습니다.

핵심: 발행자는 “무슨 일이 일어났다"만 알리고, 구독자들이 각자 필요한 일을 합니다.

인덱싱 전략

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

선수 개념
이 문서를 읽기 전에 다음 개념을 먼저 이해하세요:

핵심 구성요소 - Shard, Segment 개념

데이터 모델링 - Mapping, Analyzer 기본

소요 시간: 약 25-30분

전체 비유: 도서관의 신간 입고 프로세스#

인덱싱 전략을 도서관의 신간 입고 프로세스에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
한 권씩 등록	단건 인덱싱	느리지만 즉시 확인 가능
박스 단위 대량 입고	Bulk 인덱싱	훨씬 빠름 (10배 이상)
입고 후 서가 배치	Refresh	검색 가능하게 만듦 (기본 1초)
영구 장서 등록	Flush	디스크에 영구 저장
입고 일지	Translog	장애 시 복구용 기록
신간 분류 규칙 템플릿	Index Template	새 인덱스 자동 설정
오래된 책 → 창고 → 폐기	ILM (Index Lifecycle)	Hot → Warm → Cold → Delete
구판 → 신판 교체	Reindex	데이터 마이그레이션
도서 별칭 (시리즈명)	Alias	인덱스 별명으로 무중단 교체

이처럼 인덱싱 전략은 “도서관에 새 책을 효율적으로 입고하고 관리"하는 프로세스와 같습니다.

트랜잭션과 Exactly-Once

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

At-Most-Once: 유실 가능/중복 없음, At-Least-Once: 유실 없음/중복 가능

Exactly-Once: Idempotent Producer + Transactional API + read_committed 필요

Idempotent Producer는 Kafka 3.0+에서 기본 활성화, 단일 Partition 중복 방지

Kafka 트랜잭션은 여러 Partition에 원자적 쓰기 보장

DB + Kafka 원자적 처리가 필요하면 Outbox 패턴 사용

대상 독자: 메시지 전달 보장이 중요한 시스템을 개발하는 개발자

선수 지식: 심화 개념의 acks, Idempotent Producer 개념

소요 시간: 약 25-30분

메시지 전달 보장 수준과 Kafka 트랜잭션을 이해합니다. 이 문서는 Kafka 3.6.x 기준으로 작성되었으며, Spring Boot 3.2.x와 Spring Kafka 3.1.x, Java 17 환경에서 코드 예제가 검증되었습니다.

파티셔닝과 셔플

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

파티션은 데이터의 논리적 분할 단위, 각 파티션이 하나의 Task로 처리

셔플은 파티션 간 데이터 재분배로 Spark에서 가장 비용이 높은 연산

권장 파티션 크기: 100~~200MB, 파티션 수 = 코어 수 x 2~~4

AQE(Spark 3.0+)가 런타임에 파티션 수 자동 조정

대상 독자: Spark 성능 튜닝을 시작하는 데이터 엔지니어

선수 지식:

아키텍처 문서의 Stage, Task 개념
Transformation과 Action의 Wide/Narrow 구분

소요 시간: 약 25-30분

파티셔닝은 Spark 성능의 핵심입니다. 데이터가 어떻게 분산되는지 이해하고 최적화하는 것이 대규모 데이터 처리의 관건입니다.

패턴 매칭

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 우편 분류 센터#

패턴 매칭을 우편 분류 센터에 비유하면 이해하기 쉽습니다:

우편 분류 비유	Scala 개념	역할
우편번호로 분류	리터럴 패턴	정확한 값 매칭
크기/무게로 분류	타입 패턴	런타임 타입 검사
내용물 확인	케이스 클래스 패턴	구조 분해
조건부 특송	가드 (if)	추가 조건 검사
수취인 정보 추출	변수 바인딩	값 추출
기타 분류함	와일드카드 (_)	기본값 처리
스티커 부착 + 분류	@ 바인딩	전체+부분 동시 접근
분류 규칙 정의	추출자 (unapply)	커스텀 패턴

이처럼 우편물을 다양한 기준으로 분류하고 정보를 추출하듯, 패턴 매칭은 값을 분석하고 분기합니다.

Delta Lake 통합

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

ACID 트랜잭션: 동시 쓰기 시에도 데이터 일관성 보장

시간 여행: 과거 버전 조회/복원으로 데이터 복구 가능

스키마 진화: mergeSchema 옵션으로 컬럼 추가 안전하게 처리

최적화: OPTIMIZE(파일 병합), Z-ORDER(쿼리 최적화), VACUUM(정리)

대상 독자 및 선수 지식#

구분	내용
대상 독자	데이터 레이크 아키텍처를 개선하려는 데이터 엔지니어
선수 지식	Spark DataFrame API, Parquet 포맷 이해, 기본 예제 완료
학습 목표	Delta Lake로 신뢰성 있는 데이터 레이크를 구축할 수 있다
예상 소요 시간	약 50분

Delta Lake를 활용하여 데이터 레이크에 ACID 트랜잭션, 스키마 관리, 시간 여행 기능을 추가합니다.

ETL 파이프라인

d8lzz1gpw@mozmail.com (kimbenji) — Sat, 10 Jan 2026 00:00:00 +0000

TL;DR

템플릿 메서드 패턴: Extract → Transform → Validate → Load 표준화

데이터 정제 유틸리티: 중복 제거, NULL 처리, 이상치 필터링

증분 ETL: 워터마크 기반 변경 데이터만 처리

재시도 로직: 실패 시 자동 재시도 및 날짜 범위 처리

대상 독자 및 선수 지식#

구분	내용
대상 독자	Spark로 데이터 파이프라인을 구축하려는 데이터 엔지니어
선수 지식	기본 예제 완료, Java/Spark DataFrame API
학습 목표	재사용 가능한 ETL 파이프라인을 설계하고 구현할 수 있다
예상 소요 시간	약 45분

프로덕션 환경에서 사용 가능한 완전한 ETL(Extract-Transform-Load) 파이프라인 예제입니다.

Producer 튜닝

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

batch.size와 linger.ms로 배치 효율 조절 (OR 조건으로 동작)

linger.ms=5만으로도 처리량이 약 2.7배 증가 가능

compression.type: snappy(일반), lz4(고성능), zstd(고압축) 권장

Idempotent Producer(Kafka 3.0+ 기본)로 중복 방지 및 순서 보장

buffer.memory 부족 시 BufferExhaustedException 발생

대상 독자: Producer 성능을 최적화하려는 개발자, 대용량 메시지 처리가 필요한 운영자

선수 지식: 심화 개념의 acks, Idempotent Producer, 메시지 흐름의 Topic, Partition 개념

소요 시간: 약 25-30분

Producer 성능을 최적화하는 핵심 설정들을 이해합니다. 이 문서는 Kafka 3.6.x 기준으로 작성되었으며, Spring Boot 3.2.x와 Spring Kafka 3.1.x, Java 17 환경에서 코드 예제가 검증되었습니다.

네트워킹

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 단지 출입 시스템#

Kubernetes 네트워킹을 아파트 단지 출입 시스템에 비유하면 이해하기 쉽습니다:

아파트 출입 비유	Kubernetes	역할
세대 간 방문	Pod-to-Pod 통신	같은 단지 내 자유로운 왕래
각 세대 고유 호수	Pod IP	고유한 네트워크 주소
동 현관 인터폰	Service	안정적인 접근점 제공
단지 정문/경비실	Ingress	외부 방문자 안내 및 통제
방문자 명부	Ingress Rules	도메인/경로별 라우팅 규칙
외부 전화 연결	NodePort	외부에서 특정 포트로 접근
대표 전화번호	LoadBalancer	외부 고정 IP 제공
출입 통제 규칙	NetworkPolicy	특정 세대 간 왕래 제한
VIP 전용 출입구	TLS Termination	HTTPS 암호화 처리

이처럼 Ingress는 “단지 정문에서 방문자를 확인하고 올바른 동/호수로 안내"하는 것과 같습니다.

캐싱과 영속성

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

cache() = persist(MEMORY_ONLY), 여러 Action에서 재사용할 데이터 캐싱

Storage Level: MEMORY_ONLY(빠름), MEMORY_AND_DISK(안정), *_SER(메모리 절약)

캐시는 첫 Action 시 저장되고, unpersist()로 해제

체크포인트는 Lineage를 끊어 장애 복구와 긴 계보 문제 해결

대상 독자: 반복 연산 최적화가 필요한 데이터 엔지니어

선수 지식:

Transformation과 Action 지연 평가 이해
JVM 메모리 구조 기초

소요 시간: 약 25-30분

Spark의 인메모리 컴퓨팅 능력을 활용하여 중간 결과를 캐시하고 재사용하는 방법을 알아봅니다.

비유로 이해하는 캐싱#

개념	비유	핵심 아이디어
cache()	자주 쓰는 재료 냉장고 보관	매번 장 보러 가는 대신 냉장고에서 바로 꺼내 사용
persist()	보관 위치 선택	냉장고(메모리) vs 창고(디스크) vs 진공포장(직렬화)
MEMORY_ONLY	냉장 보관	빠르게 꺼내 쓰지만 공간 많이 차지
MEMORY_AND_DISK	냉장고 + 창고	냉장고 가득 차면 창고로 이동
직렬화 (_SER)	진공 포장	부피는 줄지만 사용 시 포장 해체 시간 필요
checkpoint	요리 중간 상태 사진 촬영	실수해도 사진 시점부터 다시 시작 가능
unpersist()	냉장고 정리	안 쓰는 재료 치워서 공간 확보

핵심 원리: 캐싱은 “계산 시간"과 “저장 공간"을 교환하는 것입니다. 자주 사용하는 데이터는 저장해두고, 한 번만 쓰는 데이터는 매번 계산하는 게 효율적입니다.

컬렉션

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 도서관 시스템#

Scala 컬렉션을 도서관에 비유하면 이해하기 쉽습니다:

도서관 비유	Scala 개념	특성
서가의 책 순서	Seq (시퀀스)	순서가 있는 컬렉션
책장별 책 나열	List (연결 리스트)	앞에서 빠른 추가/제거
도서 번호 색인	Vector (인덱스 시퀀스)	랜덤 접근 최적화
등록된 회원 명단	Set (집합)	중복 없는 고유 요소
도서 목록 카탈로그	Map (맵)	ISBN → 도서 정보 매핑
보존 서고 (원본 보관)	불변 컬렉션	원본 변경 없이 새 복사본 생성
열람실 책상 (임시 작업)	가변 컬렉션	성능상 필요시에만 사용

도서관에서 책의 순서, 검색 방법, 보관 정책이 중요하듯이, 컬렉션에서도 데이터의 구조와 접근 방식이 프로그램 설계의 핵심입니다.

클러스터 관리

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 도서관 체인 본사 운영#

클러스터 관리를 도서관 체인의 본사 운영에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
체인 본사 (정책 결정)	Master Node	클러스터 상태 관리, 인덱스 생성/삭제 결정
각 지점 창고	Data Node	실제 도서(데이터) 저장 및 대출(검색) 처리
안내 데스크	Coordinating Node	고객 요청을 적절한 지점으로 라우팅
본사 회의 정족수 (3인)	Master 선출	과반수로 의사 결정 (3대 권장)
Green 상태	모든 지점 정상	모든 도서 대출 가능
Yellow 상태	복본 부족	대출은 가능, 일부 백업 없음
Red 상태	일부 도서 접근 불가	즉시 복구 필요
지점 폐점 절차	노드 제거	도서를 다른 지점으로 이관 후 폐점

이처럼 클러스터 관리는 “전국 도서관 체인의 본사에서 모든 지점을 관리"하는 것과 같습니다.

테스트 전략

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: DDD 기반 프로젝트에서 테스트 전략을 수립하려는 개발자 선수 지식: 전술적 설계 빌딩 블록, 기본적인 JUnit/Mockito 사용법 소요 시간: 약 25분 핵심 질문: “DDD 아키텍처에서 테스트를 어떻게 구성해야 하는가?”

요약
테스트 전략 핵심: 단위 테스트(도메인 모델 중심, 가장 많이) → 통합 테스트(Repository, 외부 연동) → E2E 테스트(핵심 시나리오만)

도메인 주도 설계를 적용한 시스템은 일반적인 CRUD 애플리케이션과는 다른 테스트 전략이 필요합니다. 비즈니스 로직이 도메인 모델에 집중되어 있기 때문에, 테스트 역시 도메인 계층을 중심으로 설계해야 합니다. 이 문서에서는 DDD 아키텍처에 적합한 테스트 전략과 구체적인 구현 방법을 살펴봅니다.

Consumer 튜닝

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

fetch.min.bytes/fetch.max.wait.ms로 배치 효율과 지연시간 균형 조절

max.poll.records와 max.poll.interval.ms가 리밸런싱 방지의 핵심

session.timeout.ms는 heartbeat.interval.ms의 3배 이상 권장

처리량 최적화: fetch.min.size 증가, max.poll.records 증가

지연시간 최적화: fetch.min.size 감소, fetch.max.wait 감소

대상 독자: Consumer 성능을 최적화하려는 개발자, 운영 안정성을 높이려는 운영자

선수 지식: Consumer Group & Offset의 Consumer 동작 원리

소요 시간: 약 20분

Consumer 성능 최적화와 안정적인 운영을 위한 설정을 이해합니다.

전체 비유: 택배 수거 및 배송#

Consumer 튜닝을 택배 기사의 물품 수거에 비유하면 이해하기 쉽습니다:

Structured Streaming

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Structured Streaming은 스트림을 무한히 추가되는 테이블로 처리

배치와 동일한 DataFrame API 사용 (readStream/writeStream만 변경)

Output Mode: append(새 행), complete(전체), update(변경분)

Watermark로 늦게 도착하는 데이터(late data) 처리

대상 독자: 실시간 데이터 처리가 필요한 데이터 엔지니어

선수 지식:

DataFrame과 Dataset API
Kafka 기본 개념 (선택 사항)
이벤트 시간 vs 처리 시간 개념

소요 시간: 약 25-30분

Structured Streaming은 Spark의 스트림 처리 엔진입니다. 배치 처리와 동일한 DataFrame/Dataset API를 사용하여 실시간 데이터를 처리합니다.

고차 함수

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 식품 가공 공장#

고차 함수를 식품 가공 공장의 생산 라인에 비유하면 이해하기 쉽습니다:

공장 비유	Scala 개념	역할
재료 선별기	`filter`	조건에 맞는 요소만 통과
가공 기계	`map`	각 요소를 변환
포장 → 개봉 기계	`flatMap`	변환 후 평탄화
최종 계량기	`fold`/`reduce`	모든 요소를 하나로 축약
분류 컨베이어	`partition`/`groupBy`	조건에 따라 분류
기계 연결	함수 합성 (`andThen`)	여러 변환을 연결
기계 설정	커링	일부 파라미터 미리 고정
기계 조작법 전달	함수를 인자로	“어떻게” 처리할지 지정

공장에서 기계(함수)를 조립하여 생산 라인(파이프라인)을 구성하듯이, 고차 함수는 작은 함수들을 조합하여 복잡한 데이터 처리를 수행합니다. 핵심은 “무엇을” 처리할지와 “어떻게” 처리할지를 분리하는 것입니다.

리소스 관리

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 전기/수도 배정#

리소스 관리를 아파트 전기/수도 배정에 비유하면 이해하기 쉽습니다:

아파트 공과금 비유	Kubernetes	역할
기본 전기 용량	requests	최소 보장 리소스
최대 전기 용량	limits	사용 가능한 최대치
전기 초과 시 차단기	CPU 스로틀링	한계 초과 시 성능 저하
수도 초과 시 단수	OOMKilled	메모리 초과 시 강제 종료
프리미엄 세대	Guaranteed QoS	가장 마지막에 퇴거 요청
일반 세대	Burstable QoS	중간 우선순위
관리비 미납 세대	BestEffort QoS	가장 먼저 퇴거 요청
단지 전체 전기 한도	ResourceQuota	네임스페이스 총량 제한
세대별 기본 배정량	LimitRange	기본 리소스 설정

이처럼 requests는 “항상 보장받는 기본 전기량"이고, limits는 “절대 넘을 수 없는 최대 사용량"입니다.

성능 튜닝

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 도서관 운영 효율화#

성능 튜닝을 도서관 운영 효율화에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
적정 서가 수 결정	샤드 수 설계	너무 많으면 관리 오버헤드 증가
불필요한 색인 카드 제거	불필요한 필드 제외	저장/검색 비용 절감
인기 도서 앞자리 배치	Filter 캐시	자주 조회되는 조건 캐싱
통계 보고서 캐싱	Request 캐시	집계 결과 재사용
“소설, 컴퓨터"만 반환	_source 필터링	필요한 필드만 반환
끝없는 목록 대신 “다음 페이지”	search_after	깊은 페이지네이션 최적화
“*가 들어간 책” 요청 회피	Wildcard 쿼리 피하기	전체 스캔 방지
느린 대출 요청 분석	Slow Log	병목 쿼리 식별

이처럼 성능 튜닝은 “도서관 운영을 최적화하여 대출 대기 시간을 줄이는 것"과 같습니다.

안티패턴과 함정

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: DDD를 적용하고 있거나 도입을 고려 중인 개발자 선수 지식: Quick Start와 전술적 설계 기본 개념 소요 시간: 약 20분 핵심 질문: “DDD 적용 시 흔히 저지르는 실수는 무엇이고, 어떻게 피할 수 있는가?”

주의
이 문서에서 소개하는 안티패턴은 실제 프로젝트에서 자주 발생합니다. 자신의 코드베이스에 해당 증상이 있는지 확인해보세요.

안티패턴을 이해하는 비유#

비유: 건축과 안티패턴
DDD 안티패턴을 건축 설계 실수에 비유할 수 있습니다:

안티패턴 건축 비유 결과

Big Ball of Mud 칸막이 없는 원룸 부엌 냄새가 침실까지, 손님이 오면 모든 공간 정리 필요

Anemic Domain Model 벽만 있고 가구 없는 집 살기 위해 매번 외부에서 가구를 빌려와야 함

God Aggregate 모든 방이 연결된 미로 한 방 고치려면 모든 방에 영향

Primitive Obsession 문 없이 커튼만 있는 방 누구나 들어올 수 있어 보안 취약

중요: 안티패턴이라고 해서 항상 나쁜 것은 아닙니다. 빠른 프로토타입, 단순한 CRUD 앱, 1인 프로젝트에서는 “과도한 설계"가 오히려 해가 됩니다. 이 문서의 해결책은 복잡한 비즈니스 도메인에 적합합니다.

MLlib

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

MLlib은 DataFrame 기반 분산 머신러닝 라이브러리 (spark.ml 패키지)

Pipeline으로 전처리 → 학습 → 예측 단계를 연결

Transformer(변환), Estimator(학습), Evaluator(평가) 패턴

CrossValidator/TrainValidationSplit로 하이퍼파라미터 튜닝

대상 독자: 대규모 데이터에서 머신러닝을 수행하려는 ML 엔지니어

선수 지식:

DataFrame과 Dataset API
머신러닝 기본 개념 (분류, 회귀, 클러스터링)
특성 공학(Feature Engineering) 기초

소요 시간: 약 25-30분

MLlib은 Spark의 분산 머신러닝 라이브러리입니다. 대규모 데이터셋에서 머신러닝 모델을 학습하고 예측할 수 있습니다.

비유로 이해하는 MLlib#

개념	비유	핵심 아이디어
Transformer	재료 손질사	원재료(데이터)를 조리 가능한 형태로 변환. 학습 없이 규칙대로 처리
Estimator	요리사	레시피(알고리즘)로 연습(학습)하여 실력(모델)을 갖춤
Model	숙련된 요리사	학습 완료된 상태. 새 재료가 와도 바로 요리(예측) 가능
Pipeline	조리 라인	재료 손질 → 양념 → 조리 → 플레이팅을 하나로 연결
Evaluator	음식 평론가	완성된 요리(모델)의 품질(정확도)을 평가
CrossValidator	맛 테스트 반복	여러 번 맛보고 가장 좋은 레시피(하이퍼파라미터) 선택
Feature Vector	표준화된 재료 목록	모든 재료를 동일한 형식(벡터)으로 정리

핵심 원리: MLlib은 “전처리 → 학습 → 예측 → 평가"의 반복 가능한 파이프라인을 구축하여, 대규모 데이터에서도 일관된 ML 워크플로우를 제공합니다.

고가용성

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 도서관의 재난 대비 시스템#

고가용성을 도서관 체인의 재난 대비 시스템에 비유하면 이해하기 쉽습니다:

도서관 비유	Elasticsearch	역할
인기 도서 복본 비치	Replica Shard	데이터 복제로 장애 대비 + 대출 분산
장서 목록 사진 백업	Snapshot	특정 시점 데이터 백업
백업 사진 정기 촬영	SLM (Snapshot Lifecycle)	자동 백업 정책
타 지역 도서관에 복본 보관	CCR (Cross-Cluster Replication)	원격 클러스터로 실시간 복제
화재 시 백업 지점 운영	Active-Passive DR	장애 시 대체 클러스터 활성화
지점 폐쇄 → 타 지점 자동 대출	자동 Failover	노드 장애 시 Replica 승격
서울/부산 양방향 운영	Active-Active	각 리전에서 독립 운영

이처럼 고가용성은 “지진이나 화재에도 도서관 서비스를 중단 없이 제공"하는 재난 대비 시스템과 같습니다.

스케일링

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 세대 수 조절#

스케일링을 아파트 세대 수 조절에 비유하면 이해하기 쉽습니다:

아파트 관리 비유	Kubernetes	역할
입주 수요에 따라 세대 수 조절	스케일링	트래픽에 따른 Pod 수 조정
세대 수 늘리기	Horizontal Scaling (HPA)	Pod 개수 증가
세대 크기 늘리기	Vertical Scaling (VPA)	Pod 리소스 증가
입주율 50% 초과 시 증축	averageUtilization	스케일링 기준 메트릭
최소 3세대 유지	minReplicas	최소 Pod 수
최대 10세대까지	maxReplicas	최대 Pod 수
증축은 빠르게, 감축은 천천히	scaleUp/scaleDown 정책	급격한 변화 방지
전기 사용량 측정기	Metrics Server	리소스 사용량 모니터링
성수기 자동 증축	자동 스케일링	부하에 따른 자동 조절

이처럼 HPA는 “입주 수요가 늘면 세대 수를 늘리고, 줄면 다시 줄이는” 자동 관리 시스템입니다.

에러 처리 심화

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

에러 유형: 역직렬화 에러(건너뛰기), 일시적 에러(재시도), 영구적 에러(DLT)

@RetryableTopic으로 선언적 재시도 및 DLT 처리 (Spring Kafka 2.7+)

DefaultErrorHandler + DeadLetterPublishingRecoverer로 DLT 발행

역직렬화 에러는 ErrorHandlingDeserializer로 처리

DLT 메시지 도착 시 알림 설정으로 빠른 대응 필요

대상 독자: Consumer 에러 처리 전략을 구현하려는 개발자

선수 지식: Consumer Group & Offset의 Consumer 동작 원리, Spring Kafka 기초

소요 시간: 약 25-30분

Kafka Consumer의 에러 처리 전략과 Dead Letter Topic 패턴을 이해합니다.

전체 비유: 우편물 처리#

Consumer 에러 처리를 우편물 배달에 비유하면 이해하기 쉽습니다:

제네릭

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 만능 수납함#

제네릭을 만능 수납함 시스템에 비유하면 이해하기 쉽습니다:

수납함 비유	Scala 개념	역할
규격화된 수납함	제네릭 클래스 `Box[A]`	어떤 타입이든 담을 수 있는 컨테이너
“책 전용” 라벨	타입 매개변수 `A`	담을 내용물의 타입 지정
“도서류 이하만” 규칙	상한 경계 `A <: Book`	허용 타입 범위 제한
“인쇄물 이상만” 규칙	하한 경계 `A >: Paper`	최소 타입 요구사항
“무게 측정 가능” 조건	컨텍스트 경계 `A : Weighable`	특정 기능 보유 요구
빈 수납함	`None`, `List.empty[A]`	명시적 타입 필요

수납함에 라벨을 붙여 어떤 물건을 담을 수 있는지 명시하듯이, 제네릭은 컴파일 시점에 타입을 검사하여 잘못된 타입의 데이터가 들어가는 것을 방지합니다.

For Comprehension

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 조립 라인#

For comprehension을 공장 조립 라인에 비유하면 이해하기 쉽습니다:

조립 라인 비유	Scala 개념	역할
부품 공급 컨베이어	생성자 (`<-`)	데이터 소스에서 값 추출
품질 검사 스테이션	가드 (`if`)	조건에 맞는 값만 통과
조립 작업대	값 정의 (`=`)	중간 계산 결과 저장
완제품 출하	`yield`	최종 결과 생성
여러 라인 합류	다중 생성자	여러 소스의 조합
불량품 → 라인 정지	None/Left	실패 시 즉시 중단

조립 라인에서 부품이 순차적으로 가공되듯이, for comprehension에서는 각 단계가 이전 단계의 결과에 의존합니다. 불량품(None/Left)이 발견되면 전체 라인이 멈추는 것이 핵심입니다.

Vector Search (kNN)

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Vector Search: 의미(Semantic) 기반 검색으로 키워드가 달라도 유사한 내용 검색 가능

dense_vector: 벡터를 저장하는 필드 타입, similarity로 유사도 계산 방식 지정

kNN 쿼리: k개의 가장 가까운 이웃 문서를 찾는 검색 방식

하이브리드 검색: kNN + 키워드 검색을 결합하여 최상의 결과 제공

임베딩 모델: 텍스트/이미지를 벡터로 변환 (한글은 다국어 모델 권장)

대상 독자: 시맨틱 검색이나 추천 시스템을 구현하려는 개발자 선수 지식: 핵심 구성요소, Query DSL, 기본적인 ML 개념

소요 시간: 약 25-30분

모니터링 기초

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Consumer Lag이 가장 중요한 메트릭, 증가 추세 시 즉시 조치 필요

Broker 핵심 메트릭: UnderReplicatedPartitions, ActiveControllerCount, OfflinePartitionsCount

Producer 메트릭: record-send-rate, record-error-rate, request-latency-avg

Prometheus + Grafana로 시각화 및 알림 설정 권장

Lag 급증 시: Consumer 상태 → 처리 속도 → 리밸런싱 → 스케일 아웃 순서로 확인

대상 독자: Kafka 클러스터를 운영하고 모니터링하려는 운영자 및 개발자

선수 지식: Consumer Group & Offset의 Offset과 Lag 개념

소요 시간: 약 25-30분

Kafka 클러스터와 애플리케이션의 핵심 메트릭을 이해합니다.

성능 튜닝

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

튜닝 순서: 코드 최적화 → 데이터 구조 → 리소스 설정 → 세부 설정

핵심 전략: 셔플 최소화, 조기 필터링, Broadcast Join, 캐싱

Executor 권장: 코어당 5GB, 4~5코어가 최적

AQE + Kryo 직렬화 + 적절한 파티션 수가 기본 설정

대상 독자: 프로덕션 Spark 워크로드를 최적화하는 시니어 엔지니어

선수 지식:

파티셔닝과 셔플 이해
캐싱과 영속성 이해
Spark UI 기본 사용법

소요 시간: 약 25-30분

Spark 애플리케이션의 성능을 최적화하는 전략과 구체적인 설정 방법을 알아봅니다.

헬스 체크

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 아파트 안전 점검#

헬스 체크를 아파트 안전 점검에 비유하면 이해하기 쉽습니다:

아파트 점검 비유	Kubernetes	역할
정기 안전 점검	Health Check	애플리케이션 상태 확인
“살아 계신가요?” 확인	Liveness Probe	컨테이너 생존 확인
“손님 받을 준비 됐나요?”	Readiness Probe	트래픽 수신 준비 확인
“이사 완료됐나요?”	Startup Probe	시작 완료 여부 확인
응답 없으면 119 호출	Liveness 실패 → 재시작	컨테이너 재시작
바쁘면 손님 안 받음	Readiness 실패 → 트래픽 제외	Service에서 제외
이사 중이면 기다림	Startup 진행 중	다른 Probe 비활성화
초인종 눌러서 확인	HTTP Probe	HTTP 엔드포인트 체크
전화해서 확인	TCP Probe	포트 연결 체크
가스 점검 (직접 확인)	Exec Probe	명령어 실행 체크

이처럼 Probe는 “관리인이 주기적으로 세대를 방문하여 상태를 확인"하는 것과 같습니다.

Namespace

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 아파트 단지의 동 구분#

Namespace를 아파트 단지의 동 구분에 비유하면 이해하기 쉽습니다:

아파트 단지 비유	Kubernetes Namespace	역할
101동, 102동 구분	Namespace	리소스를 논리적으로 분리
동별 관리비 예산	ResourceQuota	네임스페이스별 리소스 총량 제한
세대당 전기/수도 한도	LimitRange	개별 Pod/컨테이너 리소스 기본값
관리사무소 전용 구역	kube-system	시스템 구성요소 전용 공간
공용 게시판 구역	kube-public	모든 사용자 접근 가능 공간
동별 출입 카드	RBAC + Namespace	접근 권한 분리

이처럼 Namespace는 “하나의 아파트 단지에서 동별로 관리 영역을 나누는 것"과 같습니다.

Implicit / Given

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 개인 비서#

암시적 기능을 개인 비서 시스템에 비유하면 이해하기 쉽습니다:

비서 비유	Scala 개념	역할
비서가 자동으로 자료 준비	`given`/`implicit val`	필요한 값을 자동 제공
“비서에게 부탁해”	`using`/`implicit` 매개변수	암시적으로 값 요청
비서의 스킬 확장	`extension` 메서드	기존 타입에 기능 추가
비서 유형별 전문 서비스	타입 클래스	타입별 맞춤 동작
비서 찾기 순서	암시적 범위	현재 스코프 → 컴패니언
비서 고용	`import ... given`	암시적 인스턴스 도입

비서가 당신이 말하지 않아도 필요한 것을 준비하듯이, 암시적 기능은 컴파일러가 필요한 값을 자동으로 찾아서 전달합니다. 핵심은 **명확한 규칙(타입)**에 따라 적절한 값을 선택하는 것입니다.

로그 수집

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 병원 의무 기록 관리#

로그 수집을 병원의 의무 기록 관리 시스템에 비유하면 이해하기 쉽습니다:

병원 의무 기록 비유	로그 수집	역할
각 병동의 진료 기록	분산된 서버 로그	개별 위치의 기록
중앙 의무 기록실	로그 수집 시스템 (Loki/ELK)	통합 저장소
환자명으로 검색	키워드 검색	특정 이벤트 찾기
진료 기록 양식	구조화 로그 (JSON)	표준화된 형식
진료일지, 처방전, 검사결과	로그 레벨 (INFO, ERROR)	기록 유형 분류
오래된 기록 창고 이관	로그 보관 정책	Hot → Warm → Cold
환자 차트 번호	trace_id	관련 기록 연결
카드 검색 시스템 (색인)	Elasticsearch 인덱싱	빠른 전문 검색
라벨 기반 분류	Loki 라벨 인덱싱	경량 검색

이처럼 병원이 환자 기록을 중앙에서 관리하듯, 로그 수집 시스템은 분산된 로그를 한 곳에서 검색할 수 있게 합니다.

배포와 클러스터 관리

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

클러스터 매니저: Local(개발), Standalone(소규모), YARN(Hadoop), K8s(클라우드)

배포 모드: Client(디버깅), Cluster(프로덕션)

동적 할당으로 워크로드에 따라 Executor 자동 조절

Fat JAR로 의존성 포함하여 spark-submit 실행

대상 독자: Spark 클러스터를 운영하는 DevOps/플랫폼 엔지니어

선수 지식:

아키텍처 문서의 Driver/Executor 개념
Docker/Kubernetes 기초 (K8s 배포 시)
Hadoop YARN 기초 (YARN 배포 시)

소요 시간: 약 25-30분

Spark 애플리케이션을 다양한 클러스터 환경에 배포하고 관리하는 방법을 알아봅니다.

비유로 이해하는 배포#

개념	비유	핵심 아이디어
Local 모드	1인 식당 운영	주방장(Driver)이 혼자 요리(Executor 역할)도 함. 빠른 테스트용
Standalone	소규모 자체 주방	직접 관리하는 주방. 간단하지만 확장에 한계
YARN	대형 호텔 총괄 주방	호텔(Hadoop) 전체 리소스를 관리하는 주방장이 따로 있음
Kubernetes	푸드코트 공유 주방	컨테이너 단위로 공간 임대. 유연하게 확장/축소 가능
Client 모드	주방장이 손님 옆에서 조리	바로 피드백 가능하지만, 손님(클라이언트)이 떠나면 요리 중단
Cluster 모드	주방장이 백주방에서 조리	손님이 떠나도 요리 계속. 완성되면 전달
동적 할당	바쁠 때만 알바생 추가	주문량(워크로드)에 따라 인력 자동 조절

핵심 원리: 배포 환경 선택은 “기존 인프라”, “확장 요구”, “운영 복잡도"의 균형점을 찾는 것입니다.

보안

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Kafka 보안 3계층: SSL/TLS(암호화) → SASL(인증) → ACL(권한)

SSL/TLS로 전송 중 데이터 암호화, 양방향 TLS로 클라이언트 인증

SASL 메커니즘: SCRAM-SHA-256 권장 (프로덕션), PLAIN은 SSL과 함께만 사용

ACL로 Principal별 Topic/Group 접근 권한 세분화

allow.everyone.if.no.acl.found=false 설정으로 기본 거부 정책 적용

대상 독자: Kafka 클러스터 보안을 구성하려는 운영자 및 보안 담당자

선수 지식: 핵심 구성요소의 Broker, Producer, Consumer 개념, 기본적인 보안 개념(암호화, 인증, 인가)

소요 시간: 약 25-30분

프로덕션 환경에서 Kafka를 안전하게 운영하기 위한 암호화, 인증, 권한 관리를 이해합니다.

한글 검색 최적화

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

선수 개념
이 문서를 읽기 전에 다음 개념을 먼저 이해하세요:

데이터 모델링 - Analyzer, text vs keyword 타입

Query DSL - match, multi_match 쿼리

소요 시간: 약 25-30분

전체 비유: 외국인을 위한 한글 도서 검색#

한글 검색 최적화를 외국인 사서가 한글 도서를 색인하는 상황에 비유하면 이해하기 쉽습니다:

한글 검색 비유	Elasticsearch	역할
영어 사서: “삼성전자가"를 통째로 기록	Standard Analyzer	조사 분리 못함
한국어 사서: “삼성전자+가"로 분리	Nori Analyzer	형태소 분석으로 조사 분리
“삼성전자” → “삼성 + 전자”	decompound_mode: mixed	복합명사 분해
신조어/브랜드명 등록	사용자 사전	특수 단어 인식
“갤럭” 입력 시 “갤럭시” 추천	자동완성 (Edge N-gram)	접두어 매칭
“ㄱㄹㅅ"로 “갤럭시” 찾기	초성 검색	자음 추출 후 매칭
“노트북 = 랩탑” 등록	동의어 처리	유사어 확장 검색

이처럼 한글 검색은 “한글의 특성을 이해하는 전문 사서를 배치"하는 것과 같습니다.

StatefulSet

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 지정석이 있는 식당#

StatefulSet을 지정석이 있는 식당에 비유하면 이해하기 쉽습니다:

식당 비유	Kubernetes StatefulSet	역할
지정석 번호 (1번, 2번, 3번)	Pod 이름 (app-0, app-1, app-2)	안정적이고 고유한 식별자
손님 전용 사물함	PersistentVolumeClaim	Pod마다 전용 영구 스토리지
순서대로 착석/퇴석	순차적 생성/삭제	0번부터 생성, 역순으로 삭제
예약 명패	안정적 네트워크 ID	Pod 재시작 후에도 같은 호스트명 유지
자유석 식당	Deployment	아무 자리나 앉고, 바뀔 수 있음

이처럼 StatefulSet은 “지정석과 전용 사물함이 있어서 항상 같은 자리, 같은 물건을 사용하는 것"과 같습니다.

Spark Connect

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Spark Connect는 gRPC 기반 클라이언트-서버 분리 아키텍처 (Spark 3.4+)

경량 클라이언트(~10MB)로 원격 Spark 클러스터 접근

SparkSession.builder().remote("sc://host:port") 로 연결

DataFrame API 완전 지원, RDD API/Streaming은 제한적

대상 독자: 마이크로서비스 환경에서 Spark를 사용하려는 개발자

선수 지식:

아키텍처 문서의 Driver/Executor 개념
gRPC 기본 개념 (선택 사항)
DataFrame과 Dataset API

소요 시간: 약 25-30분

Spark Connect는 Spark 3.4에서 도입된 새로운 클라이언트-서버 아키텍처입니다. 씬 클라이언트(Thin Client)로 원격 Spark 클러스터에 연결할 수 있습니다.

비유로 이해하는 Spark Connect#

개념	비유	핵심 아이디어
기존 방식	자가용 직접 운전	내 차(Driver)에 모든 장비 실어서 직접 운전. 차가 고장나면 여행 중단
Spark Connect	택시 호출	스마트폰(Thin Client)으로 택시(서버) 호출. 기사(Driver)가 목적지까지 데려다줌
gRPC	무전기 통신	표준화된 통신 규약으로 어떤 택시든 같은 방식으로 호출
Thin Client	가벼운 스마트폰 앱	목적지만 입력하면 됨. 내비게이션은 택시 기사가 알아서
서버 업그레이드	택시 회사 차량 교체	앱 업데이트 없이 새 차량(Spark 버전) 이용 가능

핵심 원리: Spark Connect는 “무거운 연산 로직"을 클라이언트에서 서버로 분리합니다. 클라이언트는 “무엇을 원하는지"만 전달하고, 서버가 “어떻게 할지"를 결정합니다.

분산 추적

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 택배 추적 시스템#

분산 추적을 택배 배송 추적에 비유하면 이해하기 쉽습니다:

택배 추적 비유	분산 추적	역할
운송장 번호	Trace ID	전체 요청의 고유 식별자
배송 구간별 스캔	Span	개별 작업 단위 기록
“물류센터 → 허브”	Parent-Child Span	구간 간 연결 관계
각 구간 소요 시간	Duration	작업 처리 시간
배송 상태 “집하/배송중/완료”	Status	성공/실패 상태
물류 센터 간 운송장 전달	Context Propagation	서비스 간 추적 정보 전달
지연 구간 표시	Latency 분석	병목 구간 식별
배송 사고 이력	Error Span	실패 지점 추적

이처럼 택배를 추적하듯, 분산 추적은 “요청이 어떤 서비스를 거쳐 어디서 지연됐는지"를 추적합니다.

생태계

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

TL;DR

Kafka Connect: 외부 시스템과 Kafka 간 데이터 이동, 코딩 없이 설정으로 파이프라인 구축

Schema Registry: 메시지 스키마 중앙 관리, 호환성 검증으로 런타임 오류 방지

Kafka Streams: 실시간 스트림 처리 라이브러리, 별도 클러스터 불필요

Debezium: CDC(Change Data Capture)로 DB 변경사항을 Kafka로 스트리밍

스키마 호환성: BACKWARD(기본), FORWARD, FULL, NONE 정책 지원

대상 독자: Kafka 생태계를 활용한 데이터 파이프라인을 구축하려는 개발자 및 데이터 엔지니어

선수 지식: 핵심 구성요소의 Topic, Producer, Consumer 개념, 메시지 흐름의 전체 데이터 흐름

타입 클래스

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 만능 어댑터 시스템#

타입 클래스를 전자기기 어댑터 시스템에 비유하면 이해하기 쉽습니다:

어댑터 비유	Scala 개념	역할
어댑터 규격 (USB-C 등)	타입 클래스 (`trait Show[A]`)	기능의 인터페이스 정의
특정 기기용 어댑터	인스턴스 (`given Show[Int]`)	특정 타입에 대한 구현
어댑터 사용 포트	API (`def show[A: Show]`)	타입 클래스를 사용하는 메서드
어댑터 연결	`extension` 메서드	타입에 메서드 추가
기기 본체 변경 불필요	기존 타입 수정 없음	외부에서 기능 추가
여러 어댑터 선택	여러 인스턴스 정의	상황별 다른 동작

기기 본체를 분해하지 않고 어댑터만 연결하면 새 기능을 사용할 수 있듯이, 타입 클래스는 기존 타입을 수정하지 않고 새로운 기능을 추가합니다. 핵심은 “어떤 기능이 필요한지"와 “어떻게 구현할지"를 분리하는 것입니다.

RBAC

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 건물 출입 카드 시스템#

RBAC을 건물 출입 카드 시스템에 비유하면 이해하기 쉽습니다:

건물 출입 비유	Kubernetes RBAC	역할
출입 권한 세트 (3층 서버실 접근 가능)	Role	특정 Namespace 내 허용 작업 정의
전 건물 마스터 권한	ClusterRole	클러스터 전체 허용 작업 정의
사원증에 권한 부여	RoleBinding	사용자에게 Role 할당
전 지점 출입 권한 부여	ClusterRoleBinding	사용자에게 ClusterRole 할당
사원증	ServiceAccount	Pod가 사용하는 인증 주체
“꼭 필요한 구역만 출입” 원칙	최소 권한 원칙	필요한 권한만 부여

이처럼 RBAC은 “누가 어디에서 무엇을 할 수 있는지"를 체계적으로 관리하는 것과 같습니다.

OpenTelemetry

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 국제 의료 기록 표준#

OpenTelemetry를 **국제 의료 기록 표준(HL7/FHIR)**에 비유하면 이해하기 쉽습니다:

의료 표준 비유	OpenTelemetry	역할
병원마다 다른 차트 양식	벤더별 SDK	호환 안 되는 형식들
국제 의료 기록 표준	OpenTelemetry 표준	통일된 데이터 형식
표준 진료 기록 양식	Semantic Conventions	공통 속성 이름 규약
병원 내 기록 시스템	OTel SDK	데이터 수집
기록 전송 센터	OTel Collector	수집/변환/전송
다양한 EMR 시스템	다양한 백엔드	Jaeger, Prometheus 등
병원 이전해도 기록 호환	벤더 중립성	백엔드 변경 용이
자동 기록 시스템	Auto-instrumentation	코드 변경 없이 계측

이처럼 국제 표준이 있으면 어느 병원에서도 환자 기록을 읽을 수 있듯, OpenTelemetry는 어떤 백엔드로도 데이터를 보낼 수 있습니다.

공변성 / 반공변성

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 물류 창고 시스템#

변성을 물류 창고 시스템에 비유하면 이해하기 쉽습니다:

물류 비유	Scala 개념	역할
출고 전용 창고	공변 (`+A`)	생산자 - 값을 꺼내기만 함
입고 전용 창고	반공변 (`-A`)	소비자 - 값을 넣기만 함
입출고 창고	무공변 (`A`)	양방향 - 넣고 꺼내기 모두
개 사육장 → 동물원	`List[Dog] <: List[Animal]`	더 넓은 곳으로 이동 가능
동물 핸들러 → 개 핸들러	`Handler[Animal] <: Handler[Dog]`	더 일반적인 것이 더 유용

물류에서 출고 전용 창고는 큰 카테고리로 물건을 보낼 수 있고, 입고 전용 창고는 작은 카테고리의 물건도 받을 수 있습니다. 변성은 이런 물류 흐름의 타입 안전한 규칙입니다.

Job과 CronJob

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 아르바이트와 정기 청소#

Job과 CronJob을 아르바이트와 정기 청소에 비유하면 이해하기 쉽습니다:

비유	Kubernetes	역할
일회성 아르바이트	Job	한 번 실행하고 끝나는 작업
정기 청소 스케줄	CronJob	주기적으로 반복 실행되는 작업
아르바이트생 3명 고용	completions: 3	성공 완료해야 할 횟수
동시에 2명 투입	parallelism: 2	동시에 실행할 Pod 수
최대 재시도 횟수	backoffLimit	실패 시 재시도 상한
작업 마감 시한	activeDeadlineSeconds	전체 작업 제한 시간

이처럼 Job은 “정해진 일을 완료하면 끝나는 작업"이고, CronJob은 “정해진 시간에 반복 실행되는 예약 작업"입니다.

고급 타입 시스템

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 건축 설계 시스템#

고급 타입 시스템을 건축 설계 규칙에 비유하면 이해하기 쉽습니다:

건축 설계 비유	Scala 개념	역할
“거실 또는 침실”	Union Type (`A \| B`)	여러 타입 중 하나
“내진 설계 + 방음 설계”	Intersection (`A & B`)	여러 조건 동시 충족
“비공개 내부 설계도”	Opaque Type	외부에 구현 숨김
“조건부 자재 선택”	Match Type	타입 레벨 조건 분기
“자재 변환 규칙”	Type Lambda	타입 생성자 매핑
“방 크기에 따른 자재”	Dependent Type	값에 따른 타입 결정

건축에서 설계 규칙이 안전한 건물을 보장하듯이, 고급 타입 시스템은 컴파일 타임에 더 정밀한 제약을 표현하여 런타임 오류를 사전에 방지합니다.

대시보드 설계

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 중환자실 모니터링 대시보드#

대시보드 설계를 중환자실(ICU) 모니터링 시스템에 비유하면 이해하기 쉽습니다:

중환자실 모니터 비유	대시보드 설계	역할
병실 전체 현황판	Overview 대시보드	전체 상태 한눈에 파악
개별 환자 모니터	Service 대시보드	서비스별 상세 상태
상세 검사 결과지	Detail 대시보드	문제 원인 심층 분석
정상 범위 녹색등	색상 규칙	시각적 상태 표시
5초 내 이상 감지	5초 규칙	빠른 문제 파악
활력징후 (맥박, 혈압)	핵심 지표 (황금 신호)	우선 모니터링 항목
알람 임계값 설정	Threshold 설정	경고/위험 수준 정의
병실 간호사 호출	알림 연결	문제 시 담당자 호출

이처럼 중환자실에서 환자 상태를 한눈에 파악하듯, 대시보드는 시스템 상태를 즉시 이해할 수 있게 합니다.

NetworkPolicy

d8lzz1gpw@mozmail.com (kimbenji) — Mon, 23 Mar 2026 00:00:00 +0000

전체 비유: 아파트 단지 방화벽#

NetworkPolicy를 아파트 단지의 출입 통제 시스템에 비유하면 이해하기 쉽습니다:

아파트 단지 비유	Kubernetes NetworkPolicy	역할
동별 출입 통제 규칙	NetworkPolicy	Pod 간 트래픽 허용/차단 정의
“101동 주민만 출입 허용”	podSelector	정책 적용 대상 Pod 선택
“배달원은 로비까지만”	Ingress 규칙	들어오는 트래픽 제어
“택배 발송은 경비실 경유”	Egress 규칙	나가는 트래픽 제어
경비 시스템 (CCTV, 카드키)	CNI 플러그인	정책을 실제로 적용하는 네트워크 엔진
규칙 없으면 자유 출입	기본 Allow All	NetworkPolicy 미설정 시 모든 트래픽 허용

이처럼 NetworkPolicy는 “어떤 Pod가 어떤 Pod와 통신할 수 있는지"를 제어하는 방화벽 규칙과 같습니다.

매크로와 메타프로그래밍

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 3D 프린터 공장#

메타프로그래밍을 3D 프린터가 있는 공장에 비유하면 이해하기 쉽습니다:

3D 프린터 비유	Scala 개념	역할
도면 임베딩	`inline`	코드를 호출 지점에 직접 삽입
조건부 부품 선택	`inline if/match`	컴파일 타임 조건 분기
설계 검증 시스템	`error`, `constValue`	컴파일 타임 검증
3D 프린터 (부품 생성)	매크로 (`${ }`)	컴파일 타임 코드 생성
설계도 원본	인용 (`'{ }`)	런타임 코드 표현
프린터 명령어	`Expr[T]`	타입 안전한 코드 조각

3D 프린터가 설계도(인용)를 받아 실제 부품(코드)을 출력하듯이, 매크로는 컴파일 타임에 코드를 분석하고 새로운 코드를 생성합니다. 핵심은 런타임 전에 모든 준비를 마치는 것입니다.

동시성

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 레스토랑 주방#

Scala 동시성을 레스토랑 주방에 비유하면 이해하기 쉽습니다:

레스토랑 비유	Scala 개념	역할
주문서	Future	비동기 계산의 결과를 나타내는 약속
주방장들	ExecutionContext	작업을 실행하는 스레드 풀
요리 단계 연결	flatMap/map	순차적 비동기 작업 연결
여러 요리 동시 조리	병렬 Future	독립적 작업의 동시 실행
요리 완료 알림벨	Promise	외부에서 결과를 설정
첫 번째 완성 요리	firstCompletedOf	가장 먼저 완료되는 작업
모든 요리 완성 대기	sequence	모든 Future 완료 대기

레스토랑에서 여러 주방장이 동시에 요리하듯이, Future를 사용하면 여러 작업을 동시에 처리할 수 있습니다. 중요한 것은 작업 간의 의존성을 파악하여 순차/병렬 실행을 올바르게 선택하는 것입니다.

함수형 프로그래밍 패턴

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

전체 비유: 레고 블록 조립#

함수형 프로그래밍 패턴을 레고 블록 조립에 비유하면 이해하기 쉽습니다:

레고 비유	Scala 개념	역할
블록의 표준 연결부	타입 시그니처	조합 가능성 보장
같은 블록 → 같은 결과	참조 투명성	예측 가능한 동작
원본 블록 보존	불변성	부수 효과 없음
블록 색 변환기	Functor (map)	내용물만 변환, 구조 유지
블록 연결기	Monad (flatMap)	순차적 조립 연결
“비어 있음” 표시 블록	Option	값의 유무 표현
“오류 라벨” 블록	Either	성공/실패 정보 포함
블록 조립 설명서	for comprehension	조립 순서 기술

레고를 조립할 때 표준 연결부가 있어야 어떤 블록이든 연결할 수 있듯이, 함수형 프로그래밍에서는 Functor, Monad 같은 추상화가 다양한 타입을 일관되게 조합할 수 있게 해줍니다.

도서	저자	특징
Elasticsearch in Action (2nd Ed)	Madhusudhan Konda	실전 예제 중심
Learning Elastic Stack 8.0	Pranav Shukla	ELK 스택 전체 학습

도서	저자	특징
Elasticsearch: The Definitive Guide	Clinton Gormley	원리 이해 (구버전이지만 개념 학습에 유용)
Relevant Search	Doug Turnbull	검색 관련성 최적화

안티패턴	건축 비유	결과
Big Ball of Mud	칸막이 없는 원룸	부엌 냄새가 침실까지, 손님이 오면 모든 공간 정리 필요
Anemic Domain Model	벽만 있고 가구 없는 집	살기 위해 매번 외부에서 가구를 빌려와야 함
God Aggregate	모든 방이 연결된 미로	한 방 고치려면 모든 방에 영향
Primitive Obsession	문 없이 커튼만 있는 방	누구나 들어올 수 있어 보안 취약