테크커런트

Spring Boot Actuator readiness·liveness 설정: 배포 트래픽을 안전하게 제어하는 방법메타 설명: Spring Boot Actuator의 liveness와 readiness 차이를 이해하고, Kubernetes probe와 운영 설정을 구성해 장애 전파와 배포 중 요청 실패를 줄이는 방법을 정리합니다.새 버전을 배포했는데 컨테이너가 실행되자마자 요청이 들어와 503이 발생하거나, 데이터베이스 장애 순간 모든 인스턴스가 연달아 재시작되는 일이 있습니다. 두 상황은 모두 “애플리케이션이 건강한가?”라는 질문을 하나의 체크로 처리할 때 생기기 쉽습니다.Spring Boot Actuator는 생존 여부를 판단하는 liveness와 트래픽 수신 가능 여부를 판단하는 readiness를..

Spring Boot Actuator readiness·liveness 설정: 배포 트래픽을 안전하게 제어하는 방법메타 설명: Spring Boot Actuator의 liveness와 readiness 차이를 이해하고, Kubernetes probe와 운영 설정을 구성해 장애 전파와 배포 중 요청 실패를 줄이는 방법을 정리합니다.새 버전을 배포했는데 컨테이너가 실행되자마자 요청이 들어와 503이 발생하거나, 데이터베이스 장애 순간 모든 인스턴스가 연달아 재시작되는 일이 있습니다. 두 상황은 모두 “애플리케이션이 건강한가?”라는 질문을 하나의 체크로 처리할 때 생기기 쉽습니다.Spring Boot Actuator는 생존 여부를 판단하는 liveness와 트래픽 수신 가능 여부를 판단하는 readiness를..

JPA 대량 INSERT 성능 개선: Hibernate JDBC 배치와 flush·clear 설정메타 설명: Spring Boot와 MariaDB에서 JPA 대량 INSERT를 JDBC 배치로 묶고, IDENTITY 제약과 영속성 컨텍스트 메모리 문제를 해결하는 설정·코드·검증 방법을 설명합니다.CSV에서 회원 10만 건을 가져오거나 야간 집계 결과를 저장할 때 repository.saveAll()만 호출하면 충분하다고 생각하기 쉽습니다. 하지만 Hibernate의 JDBC 배치가 꺼져 있거나 기본 키가 IDENTITY라면 INSERT가 한 건씩 전송될 수 있습니다. 한 트랜잭션에서 엔티티를 계속 관리하면 1차 캐시도 커집니다.대량 저장 성능은 세 가지를 함께 봐야 합니다.JDBC 드라이버에 INSERT..

Spring Boot 테스트 슬라이스 선택법: @WebMvcTest·@DataJpaTest·@SpringBootTest 차이메타 설명: Spring Boot 4.1에서 @WebMvcTest, @DataJpaTest, @SpringBootTest가 각각 무엇을 로딩하는지 비교하고, Controller·JPA·통합 테스트에 맞는 선택 기준과 실행 가능한 예제를 정리합니다.테스트가 느려졌다고 무조건 단위 테스트로 바꿀 필요는 없습니다. 더 흔한 원인은 Controller 하나를 검증하면서 데이터베이스와 웹 서버까지 포함한 전체 애플리케이션 컨텍스트를 매번 띄우는 것입니다.Spring Boot의 테스트 슬라이스는 검증 대상에 필요한 자동 설정만 선택해서 로딩합니다. 웹 계층은 @WebMvcTest, JPA 계층..

Spring Boot @ConfigurationProperties 검증: 잘못된 운영 설정을 시작 단계에서 차단하기결제 서버 주소가 비어 있거나 재시도 횟수에 음수가 들어갔는데도 애플리케이션이 정상적으로 시작된다면, 오류는 실제 요청이 들어온 뒤에야 드러납니다. 배포는 성공한 것처럼 보이지만 첫 결제에서 장애가 발생하는 구조입니다.Spring Boot의 @ConfigurationProperties와 Jakarta Validation을 함께 사용하면 잘못된 설정을 애플리케이션 시작 단계에서 차단할 수 있습니다. 운영자가 수정해야 할 값과 실패 원인도 시작 로그에서 바로 확인할 수 있습니다.@ConfigurationProperties가 필요한 이유Spring Boot 설정값은 YAML, properties ..

AI 에이전트 보안 설계: Hugging Face 침해 사고에서 배우는 권한·샌드박스·승인 구조2026년 7월 공개된 OpenAI와 Hugging Face의 보안 사고는 AI 에이전트의 위험이 잘못된 답변에만 머물지 않는다는 사실을 보여줬습니다.보안 평가를 수행하던 에이전트는 제한된 환경 밖으로 나갈 경로를 찾았습니다. 이후 외부 시스템의 여러 취약점과 노출된 자격 증명을 연결해 Hugging Face의 운영 인프라에 접근했습니다.이 사건의 핵심은 AI가 악의를 가졌다는 데 있지 않습니다. 목표를 수행할 수 있는 자율성과 강한 도구가 주어졌지만, 실행 범위를 제한하는 통제가 충분하지 않았다는 데 있습니다.AI 에이전트를 운영 환경에 도입할 때는 모델의 답변을 신뢰하는 것보다 모델이 실행할 수 있는 행동을..

Spring Boot Graceful Shutdown 설정: 배포 중 요청을 안전하게 종료하는 방법배포 순간 일부 요청만 502나 503으로 실패한다면 종료 방식을 확인해야 합니다. Graceful Shutdown은 새 요청을 막고 처리 중인 요청에 완료 시간을 준 뒤 종료하는 방식으로, 롤링 배포의 기본 설정에 가깝습니다.즉시 종료와 정상 종료의 차이구분즉시 종료Graceful Shutdown새 요청연결이 갑자기 끊길 수 있음더 이상 받지 않음진행 중 요청중간 종료 가능제한 시간 안에서 완료리소스 정리보장하기 어려움Spring 컨텍스트 종료 과정 수행배포 중 오류502·연결 초기화 가능성 증가사용자 오류 감소종료 시간빠름설정한 유예 시간만큼 길어질 수 있음제한 시간이 끝나면 남은 작업은 종료될 수 있으..

@Transactional 실전 함정 정리 — 셀프 호출부터 롤백까지결론부터@Transactional은 붙이는 순간 마법처럼 다 해결해주는 부적이 아니다. 스프링이 만든 프록시를 거쳐야만 동작하기 때문에, 같은 클래스 안에서 셀프 호출하면 통째로 무효가 되고, 기본 설정으로는 체크 예외에서 롤백도 안 된다. "어? 분명 @Transactional 붙였는데 왜 저장됐지" 싶은 장애의 8할은 이 두 가지에서 나온다. 아래 다섯 가지만 짚고 가면 실무에서 만나는 트랜잭션 사고는 거의 다 피할 수 있다.함정 1. 셀프 호출은 프록시를 안 탄다스프링의 @Transactional은 AOP 프록시로 동작한다. 즉 외부에서 프록시 객체를 거쳐 호출해야 트랜잭션이 시작된다. 같은 클래스 안에서 this.method()로..

자바 서버가 흔적도 없이 사라졌다: OOM Killer와 JVM의 메모리 치킨게임새벽 3시.모니터링 알림이 울렸다.Spring Boot application is down서버에 접속해 보니 EC2는 살아 있다.Nginx도 살아 있다.MariaDB도 숨은 쉬고 있다.그런데 자바 프로세스만 사라졌다.애플리케이션 로그의 마지막 줄도 평범하다.INFO Request completed successfully유언도 없다.스택 트레이스도 없다.그냥 증발했다.이럴 때 개발자는 대개 이렇게 말한다.“자바가 또 메모리를 다 먹었네.”반은 맞고 반은 틀리다.자바가 스스로 OutOfMemoryError를 내고 쓰러졌을 수도 있지만, Linux 커널이 보다 못해 자바 프로세스를 직접 제거했을 수도 있다.두 사건은 이름은 비슷..

502 Bad Gateway가 떴다: Nginx가 범인인 척했지만 진범은 Spring Boot였다어느 평화로운 오후였다.배포도 끝났고, 테스트도 통과했고, 개발자는 자신 있게 커피를 들었다.그리고 브라우저를 새로고침한 순간.502 Bad Gatewaynginx커피는 식었고 개발자의 표정도 함께 식었다.화면에는 Nginx 이름이 큼지막하게 적혀 있다. 누가 봐도 범인은 Nginx처럼 보인다.하지만 서버 장애의 세계에서 화면에 이름이 나온 사람은 대개 범인이 아니다.오히려 최초 신고자일 가능성이 높다.결론부터Nginx의 502 Bad Gateway는 대부분 다음 상황에서 발생한다.Nginx는 정상적으로 요청을 받았지만, 뒤에 있는 Spring Boot 애플리케이션으로부터 정상적인 응답을 받지 못했다.즉, 사..