푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1706편 · 1 / 171 페이지)
-
데일리 AI·Kubernetes·프리랜서 브리핑 — 2026-11-11
기준 시각: 2026-11-11 08:30 KST. “최신”은 11-10~11-11 날짜 항목만 셉니다. 라벨: [사실] 1차·공식 출처 / [보도] 언론 보도(1차 미확인) / [벤더 주장] 벤더 자체 수치 / [추론] 필자 해석 / [미확인] 검증하지 못함. 11-10 브리핑과 겹치는 항목(Fable·Mythos 5.2 출시, 11-09 KEV 4건, SSHole, KubeRay 기증 발표, MCP 12-15 사양 계획 등)은 새 진전이 있을 때만 다룹니다.
-
자율형 에이전트란 무엇인가 — 감지·판단·실행·보고 루프와 실제 사용사례
“이번 주 매출이 평소보다 낮아요. 원인 분석 리포트를 만들어 둘까요?”
-
Redis 캐시와 멀티스레딩 — 서버·클라이언트·애플리케이션, 세 층에서 '동시에'가 뜻하는 것이 다르다
검증 범위. Redis 서버 동작은 redis.io 공식 문서와
redis.conf원문, 클라이언트 동작은 Lettuce 공식 레퍼런스, Spring 동작은 Spring Framework·Spring Data Redis 공식 레퍼런스와 GitHub 소스(2.7.x / 3.3.x / 3.4.x / 3.5.x / main 브랜치)를 직접 열어 확인했다. 성능 수치는 인용하지 않는다(공식 문서가 직접 쓴 대략치 두 개만 출처와 함께 인용). “~일 것이다”로 표시한 부분은 내 추론이다. -
Spring Batch 아키텍처 — 메타데이터가 재시작을 만들고, 확장 모델 여섯 개는 '병목이 어디냐'로 고른다 (Spring Batch 6 기준)
검증 범위. 개념·동작·버전별 변화는 전부 Spring Batch 공식 레퍼런스(Domain Language, Scaling and Parallel Processing, What’s new in Spring Batch 6)에서 확인했다. 성능 수치는 공식 문서가 직접 쓴 한 문장(“수백 MB 파일 읽고 쓰기는 일반 하드웨어로 1분 안쪽”)만 인용하고, 그 외 수치는 쓰지 않는다. “~일 것이다”로 표시한 부분은 문서에서 끌어낸 내 추론이다.
-
WebSocket·Spring Boot·STOMP — 채팅 구조로 보는 STOMP의 사용사례
WebSocket을 붙이면 곧바로 이런 질문들이 따라옵니다. “이 메시지는 어느 방 거지?”, “누가 이 방을 구독하고 있지?”, “서버가 두 대가 되면?”, “인증은 어디서 하지?” STOMP는 이 질문들에 미리 정해진 답을 주는 하위 프로토콜입니다. 이 글은 개념을 순서대로 짚고, 채팅 서비스를 만든다고 가정해 STOMP의 각 기능이 어디에 쓰이는지 살펴봅니다.
-
Spring Cloud Stream × Kafka — 함수 하나를 토픽에 묶는 추상화, 그리고 그 대가
이 글은 MSA · EDA · CDC · CQRS 비교 → 멱등성과 멱등키에 이은 세 번째 글이다. 앞의 두 글이 “이벤트로 서비스를 잇는다면 무엇을 지켜야 하나”를 다뤘다면, 이번엔 스프링 진영에서 그걸 코드로 옮길 때 가장 먼저 만나는 프레임워크 — Spring Cloud Stream(이하 SCS)과 그 Kafka 바인더를 1차 문서 기준으로 정리한다.
-
Spring Batch 성능 튜닝부터 실전 전략까지 — 김남윤 강의 자료 정리
김남윤(cheese10yun) 님의 「Spring Batch : 성능 튜닝부터 실전 전략까지」 강의 자료(344쪽)를 읽고 정리한 글입니다. 강의 자료 원본 PDF는 여기에서 받을 수 있습니다 (16.6MB, 344쪽). 자료의 저작권은 저자 김남윤 님에게 있습니다. 저자의 글은 블로그에, 실습 코드는 GitHub 저장소 spring-batch5에 공개되어 있습니다.
-
QueryDSL 사용사례와 성능 최적화 — 동적 쿼리부터 No-Offset·count 분리까지, 100만 건 실측
QueryDSL은 JPQL(과 SQL, MongoDB 등)을 문자열 대신 자바 코드로, 컴파일 타임 타입 체크를 받으며 조립하게 해 주는 라이브러리입니다. 이 글은 두 가지를 다룹니다. 하나는 어디에 쓰면 이득인가(사용사례), 다른 하나는 QueryDSL로 쓴 쿼리를 어떻게 빠르게 만드나(성능)입니다. 성능 쪽은 주장만 하지 않고 직접 100만 건을 넣어 쟀습니다.
-
JPA·JPQL 사용사례와 성능 최적화 — Hibernate 7.2 에서 JDBC 왕복 횟수를 직접 세 봤다
JPA 성능 글은 대개 “N+1 은 fetch join 으로 푼다” 같은 처방 목록이다. 처방은 맞다. 하지만 몇 번이 몇 번으로 줄어드는지, 어떤 처방이 어디서 깨지는지는 직접 돌려보지 않으면 감으로 남는다.
-
멱등성과 멱등키 — "한 번만 일어나게"를 어디서, 어떻게 보장할까
앞 글(MSA · EDA · CDC · CQRS 비교)의 4장에서 “Outbox 릴레이는 같은 메시지를 두 번 보낼 수 있으므로 소비자는 멱등해야 한다“고 한 줄로 넘어갔다. 이 글은 그 한 줄을 펼친다. 분산 시스템에서 “정확히 한 번”은 네트워크가 주는 것이 아니라 수신 쪽이 만들어 내는 것이다. 그 도구가 멱등성이고, HTTP 경계에서는 그 손잡이가 멱등키(Idempotency-Key)다.