푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1705편 · 1 / 171 페이지)
-
자율형 에이전트란 무엇인가 — 감지·판단·실행·보고 루프와 실제 사용사례
“이번 주 매출이 평소보다 낮아요. 원인 분석 리포트를 만들어 둘까요?”
-
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)다.
-
DB 커넥션 풀 × 스레드 풀 — 줄은 어디에 서는가 (리틀의 법칙으로 보는 Tomcat·HikariCP·가상 스레드)
검증 범위. 기본값·동작 설명은 전부 1차 문서에서 확인했다 — HikariCP README·위키, Apache Tomcat 10.1 HTTP Connector 문서, Spring Boot 공식 프로퍼티 부록, OpenJDK JEP 444/491, PostgreSQL 공식 문서. 본문의 처리량 계산(예: “500 tx/s”)은 설명용 가정값을 공식에 넣은 산술이지 측정값이 아니다. 내 환경에서 부하 테스트로 재현한 수치는 이 글에 없다.