푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 914편 · 11 / 92 페이지)
-
스프링부트 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 조합의 장점을 봤다. 이번엔 반대편 장부다. 이 조합의 리스크는 추상적인 “낡았다” 가 아니라 날짜가 박힌 지원 종료의 누적이고, 날짜는 전부 공식 문서에 있다.
-
스프링 6 + Vue 2 — 이 조합이 아직 굴러가는 이유 (1/3)
-
pom.xml 경로·DB 설정과 Liquibase 조합에서 유의할 점 — 경로가 체인지셋의 '이름'이다
Maven 프로젝트에 Liquibase 를 붙이는 방법은 두 갈래다 —
liquibase-maven-plugin으로 빌드/배포 단계에서 돌리거나, Spring Boot 라면 앱 기동 시 자동 실행에 맡기거나. 문제는 두 경로를 같이 쓰는 순간부터다. 같은 체인지로그인데 한쪽에서는 이미 실행된 걸로, 다른 쪽에서는 처음 보는 걸로 인식되는 사고가 난다. 원인은 늘 같다. 경로 문자열이 체인지셋 신원(identity)의 일부이기 때문이다. -
인텔리제이 디버거와 Liquibase, 부트 없이 — 순수 스프링에서는 루프의 축이 바뀐다
앞 글에서 인텔리제이 디버거와 Liquibase 조합의 루프 비용을 다뤘는데, 그 글은 스프링부트를 전제했다 —
spring.liquibase.*프로퍼티, 스타터가 붙여 주는 자동 실행. 이번 글은 같은 주제를 부트가 없는 순수 스프링 프레임워크에서 다시 푼다. -
Hibernate 와 HikariCP — 커넥션을 언제 빌리고 언제 돌려주는지가 성능의 절반이다
스프링 부트에서 JPA 를 쓰면 Hibernate 와 HikariCP 는 자동으로 한 몸이 된다 — 부트는 HikariCP 가 클래스패스에 있으면 무조건 그걸 선택한다. 그래서 대부분 둘의 경계를 의식할 일이 없다. 그런데 성능 문제(풀 고갈, 불필요한 왕복, 커넥션을 오래 무는 트랜잭션)는 거의 전부 이 경계에서 생긴다. 핵심 질문은 하나다: Hibernate 는 Hikari 풀에서 커넥션을 언제 빌리고, 언제 돌려주는가.
-
Chrome 일반모드·시크릿모드·iPhone Private Browsing 차이
Chrome 일반모드·시크릿모드·Private Browsing 차이
-
스프링 6에서 스프링부트 4로 — 공식 문서로 그리는 마이그레이션 지도
스프링부트 4.0 은 2025년 11월 20일 GA 됐다(공식 발표). 스프링 프레임워크 6 위의 부트 3.x 에서 넘어가려는 팀이 이제 꽤 될 시점이라, 공식 마이그레이션 가이드와 릴리스 노트를 축으로 무엇이 언제 터지는지 순서대로 지도를 그려 본다.
-
USB 동글 하나 더 꽂았을 뿐인데 — 노드가 20시간 죽었다
오늘 아침 6시 59분 48초, 우리 집 K3s 클러스터의 컨트롤플레인 노드 하나가 네트워크에서 완전히 사라졌다. 원인은 해킹도 정전도 아니었다. 가동 중인 노드에 USB 무선 동글을 하나 더 꽂은 것. 그 순간 기존 동글의 드라이버가 행에 걸렸고, 노드는 저녁 7시 44분 재부팅될 때까지 20시간 45분 동안 불통이었다.