푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 821편 · 1 / 83 페이지)
-
[Briefing] 2026-09-16 르무엘 클러스터 상태 점검 리포트
1. 개요 (Summary)
-
2026년 9월 16일 기술 브리핑: AI-First Kubernetes와 Spring Boot 4.1의 시대
매일 오전 최신 기술 동향을 정리해 드립니다. 오늘은 AI 인프라의 표준이 된 Kubernetes와 Java 생태계의 거대한 전환점인 Spring Boot 4.1 소식을 중심으로 전해드립니다.
-
러너 업그레이드가 고쳐 온 것들 — 깃랩과 깃헙은 반대편에서 출발해 같은 답에 도착했다
CI 러너는 조용히 바뀐다. 파이프라인 YAML 은 3년 전 그대로인데, 그 밑에서 도는 러너는 세 번쯤 구조가 갈렸다. 이 글은 깃랩 러너와 깃헙 액션 러너가 각자의 업그레이드에서 무엇을 고쳐 왔는지를 1차 출처만으로 맞대어 본 것이다.
-
AWS·GCP·네이버클라우드에서 Redis 가 기여할 수 있는 자리
“Redis 를 쓰면 뭐가 좋아지는가” 는 클라우드가 정하지 않는다 — 워크로드가 정한다. 그러나 어떤 관리형으로, 어떤 엔진 이름으로, 어떤 운영 모델로 쓰게 되는가는 클라우드마다 꽤 다르고, 2024년 라이선스 사변 이후로는 더 달라졌다. 이 글은 ① Redis 가 기여하는 자리 자체를 먼저 고정하고, ② 세 클라우드(AWS·GCP·네이버클라우드)의 관리형 지형을 공식 문서 기준으로 얹은 뒤, ③ 선택 기준을 정리한다.
-
프로파일은 늘리고 산출물은 늘리지 않는다 — 스프링 프로파일과 빌드 결과물의 분리 운영
“환경이 늘었으니 프로파일을 늘린다” 까지는 대부분 같은 답을 낸다. 문제는 그다음이다 — 프로파일이 늘면 빌드 산출물도 같이 늘어나는가?
-
Oracle·MySQL·MSSQL 셋을 이고 사는 MyBatis, JPA+QueryDSL 로 갈아탈 것인가 — 기회비용 계산서
Oracle·MySQL·MSSQL 세 벤더를 동시에 지원하는 시스템을 MyBatis 로 운영 중이고, JPA + QueryDSL 로 옮길지 고민한다고 하자. 이 결정은 흔한 “MyBatis vs JPA” 논쟁과 결이 다르다 — 멀티 DB 라는 조건이 저울 양쪽의 추를 전부 바꿔 놓기 때문이다. 순서대로: 지금 구조의 실체 → 양쪽의 장단 → 감춰진 비용 → 기회비용 계산 프레임 → 권고.
-
Lombok @Data 와 record 정밀분석 — 둘은 같은 문제를 푸는 두 해법이 아니다
“record 가 나왔으니 Lombok 은 끝났다” 는 말을 자주 듣는다. 이 문장의 문제는 결론이 아니라 전제다. 두 기능이 같은 문제를 푼다고 가정하는데, record 를 설계한 문서가 그 가정을 직접 부정한다. JEP 395 의 Non-Goals 절이다.1
-
OpenJDK 공식 — JEP 395: Records (Status: Closed / Delivered, Release 16). Non-Goals, Description, Rules for record classes 절. ↩
-
-
스프링부트 4 백엔드에서 React vs Vue — 프레임워크 비교가 아니라 '경계 설계' 비교다
React 와 Vue 자체의 비교(변경 감지 모델, JSX vs SFC, 생태계)는 이틀 전 글에서 다뤘다. 오늘의 질문은 다르다 — 백엔드가 스프링부트 4 로 정해져 있을 때, 그 옆자리에 React 를 앉히느냐 Vue 를 앉히느냐는 무엇으로 갈리는가.
-
스프링 6 + Vue 2, 어디로 어떤 순서로 — 탈출 로드맵 (3/3)
-
지원 시계로 읽는 스프링 6 + Vue 2 리스크 장부 (2/3)
1편에서 스프링 6 + Vue 2 조합의 장점을 봤다. 이번엔 반대편 장부다. 이 조합의 리스크는 추상적인 “낡았다” 가 아니라 날짜가 박힌 지원 종료의 누적이고, 날짜는 전부 공식 문서에 있다.