[SpringBatch] 과거 Job Parameter가 계속 따라오는 이유

주기적으로 실행되는 배치 잡의 시작 로그에, 한참 전에 딱 한 번 쓰였던 파일명이 매 실행마다 찍히고 있었습니다.스케줄러는 그 값을 넘기지 않았고, 누가 수동으로 넣은 것도 아니었습니다.그런데도 그 값이 계속 되살아나면서 메타테이블에 새 행으로 쌓이고 있었습니다.단순 확인용을 위해 로그에 찍힌 것이었지만 처음에 보았을 때는 실행한 적없는 파일이 로그에 찍혀서 매우 놀랐었습니다..(정말)원인은 모든 잡에 공통 설정을 붙여주는 코드 몇 줄이었습니다.이번 글에서는 왜 이런 일이 생길 수 있는지 정리해보겠습니다. 1️⃣ 스프링 배치란?스프링 배치는 대량 데이터를 일괄로 처리하는 작업을 만들기 위한 프레임워크입니다.웹 API 는 사용자가 요청할 때 실행되지만, 배치는 내가 정한 시점에 내가 실행시킵니다..

• format_list_bulleted SpringBatch
• · 2026. 9. 13.

[프로젝트] 태권도 관장님께 드린 작은 선물

태권도를 다니고 있습니다.단 취득이 목적이었지만 재활을 곁들인..저에게 만큼은 재활치료사 같았던 관장님께 작은 선물을 드리기로 했습니다. 제가 다니는 태권도장은 개관한지 얼마 안 된 성인 태권도장입니다.때문에 출결시스템을 수기로 진행하고 있었습니다.매일 어느시간대에 누가 오는지를 매일 카톡으로 여쭤보시고, "오늘 몇시부에 참석하겠습니다"라는 카톡을 보내야했기 때문에 번거로움이 있습니다. 심지어 실제로 왔는지 여부는 당일날 수업을 진행하시는 도중 수기로 체크를 하셨습니다. 이런 점이 불편하실 것 같아서 불편하진 않으신지를 여쭤봤는데아니나다를까..너무 불편하지만, 출결시스템 이용료를 아직 낼 수 없다고 하셨습니다. 자동화에 미친 개발자는 언젠가..언젠가.. 만들어드리면 좋겠다..라는 생각을 하고 그렇게 ..

• format_list_bulleted 프로젝트
• · 2026. 8. 29.

[JAVA] 21보다는 25를 써야하는 이유

서버의 아웃바운드 공인 IP 를 조회해서 캐싱해두는 간단한 컴포넌트가 있었습니다.캐시가 만료되면 외부 엔드포인트를 호출해서 IP 를 다시 받아오고, TTL 만큼 다시 캐싱하는 구조입니다.이때 캐시가 만료된 순간 여러 스레드가 동시에 들어와서 외부 호출을 중복으로 날리는 것을 막기 위해 synchronized 블록으로 한 스레드만 갱신하도록 막아두었습니다.흔히 쓰는 single-flight 패턴입니다. 문제는 이 애플리케이션이 가상 스레드(Virtual Thread) 위에서 돌고 있었고, JDK 버전이 21 이었다는 점입니다.synchronized 블록 안에 블로킹 HTTP I/O 가 들어 있었기 때문에, 이 코드는 JDK 21 에서 캐리어 스레드를 pinning 하는 코드였습니다. 이번 포스팅에서는 왜 ..

• format_list_bulleted JAVA
• · 2026. 8. 15.

[DB & SQL] 바꾼적 없는 컬럼을 조회할 수 없었던 이유

특정 테이블의 컬럼 몇 개에 대해 ALTER TABLE 을 수행했습니다.기본값을 설정하고 타입을 UNSIGNED 로 변경하는 간단한 작업이었습니다.그런데 ALTER를 수행한 후에 수정한 컬럼들과는 전혀 상관없는 다른 컬럼들을 조회하는 SELECT SUM(...) 쿼리에서 아래 예외가 발생했습니다.rootCause: SQLException: Table definition has changed, please retry transaction"테이블 정의가 변경되었다" 라는 이유로 실패했습니다.이번 글에서는 왜 수정하지도 않은 컬럼을 조회하는데 메타데이터 변경 에러의 영향을 받았는지,그 원인을 MySQL 내부 동작과 함께 정리해보겠습니다. 1️⃣ ALTER TABLE 은 어떤 작업인지SQL 명령은 ..

• format_list_bulleted DB & SQL
• · 2026. 8. 1.

[SpringBoot] 방금 INSERT 한 데이터가 조회되지 않았던 이유

데이터를 저장한 직후 후처리 작업을 수행하는 로직이 있었습니다.저장은 정상적으로 완료되었고 예외도 발생하지 않았지만, 후처리 과정에서 방금 저장한 데이터를 다시 조회하면 결과가 조회되지 않는 현상이 발생했습니다. 조회 조건도 정상이었고 조회SQL에도 문제가 없었습니다.실행 순서를 따라가 보니 원인은 트랜잭션 전파 옵션으로 사용한 REQUIRES_NEW 에 있었습니다. 이번 글에서는 REQUIRES_NEW 가 부모 트랜잭션의 데이터를 조회하지 못했던 이유와afterCommit 으로 어떻게 해결했는지 정리해보겠습니다. 1️⃣ 트랜잭션 전파(Propagation)란스프링에서 트랜잭션이 걸린 메서드 안에서 또 다른 트랜잭션 메서드를 호출하면,기존 트랜잭션에 참여할지, 새로운 트랜잭션을 시작할지를 결..

• format_list_bulleted SpringBoot
• · 2026. 7. 13.

[DB & SQL] 30초 걸리던 조회 API, 한 줄 바꿔서 응답시간 1초로

특정 그룹별 현황을 페이지네이션으로 조회하는 API가 있었습니다.초기에는 문제 없이 동작했지만 데이터가 누적되자 응답 시간이 증가하기 시작했습니다. 결국에는 한 번 호출하는데 20~30초가 소요되는 수준까지 늘어났습니다.조회는 한 페이지당 20개씩밖에 보여주지 않는데도 많이.. 걸렸습니다.실행 계획을 확인해보니 EXISTS를 사용한 서브쿼리가 DEPENDENT SUBQUERY로 동작하고 있었고,이것이 성능 저하의 원인이었습니다. 이번 글에서는 EXISTS와 DEPENDENT SUBQUERY가 어떤 관계인지, 그리고 어떻게 개선했는지 정리해보려고 합니다. 1️⃣ 어쩌다 30초까지 늘어났는가문제의 쿼리는 단순화하면 아래와 비슷한 형태였습니다.SELECT COUNT(*)FROM AWHERE EXI..

• format_list_bulleted DB & SQL
• · 2026. 5. 31.