기억과 기록 기억과 기록

분산 환경에서 @Scheduled 작업을 운영할 때가장 먼저 부딪히는 문제 중 하나는 동일 작업의 중복 실행이다. 애플리케이션이 여러 인스턴스로 실행되는 환경에서는 같은 스케줄이 각 노드에서 동시에 수행될 수 있고,이때 배치 중복 실행이나 데이터 정합성 문제가 발생할 수 있다. 이 문제를 해결하기 위해 많이 사용하는 라이브러리 중 하나다 ShedLock이다.ShedLock은 스케줄러 자체를 대체하는 도구가 아니라,동일한 작업이 동시에 실행되지 않도록 외부 저장소(DB, Redis 등)에 lock을 기록해 제어하는 라이브러리이다.같은 이름의 lock이 이미 잡혀 있으면 다른 노드는 기다리지 않고 해당 실행을 건너뛴다. 그런데 이번에 Spring Boot 3.x + ShedLock 2.1.0 조합으로 일부 ..

Spring Batch를 처음 적용하면 BATCH_* 테이블이 먼저 눈에 들어온다. 처음에는 이런 생각이 들 수 있다.배치는 그냥 Job만 실행하면 되는 것 아닌가?왜 별도의 메타데이터 테이블까지 필요할까? Spring Batch는 단순히 메서드를 한 번 호출하는 도구가 아니다.실행 이력, 재시작 가능 여부, Step별 처리 현황, 실행 중 상태값까지 함께 관리하는 배치 프레임워크다. 이때 이런 정보를 저장하는 중심 저장소가 JobRepository이며,공식 문서도 JobRepository를JobExecution, StepExecution 같은 persisted domain object의 CRUD를 담당하는 핵심 구성요소로 설명한다. 즉, BATCH_* 테이블은 단순 로그 테이블이 아니라,Spring B..

스케줄러를 통해 Job은 실행되었고,Reader / Processor / Writer 로그도 정상적으로 찍혔다. 그런데 정작 DB의 Spring Batch 메타 테이블에는 실행 이력이 남지 않았다. Spring Batch 공식 문서에 따르면,메타데이터 테이블은 JobInstance, JobExecution, StepExecution, JobParameters 같은 배치 도메인 객체와 매핑되며,이를 저장하는 주체는 JobRepository 라고 명시되어 있다. 즉, 이 테이블에 값이 안 들어간다면,단순히 "실행이 안 됐다"라기 보다 어떤 JobRepository를 쓰고 있는지를먼저 의심해야 한다.원인 : Spring Batch 6의 기본 배치 인프라 변경핵심 원인은 Spring Batch 6의 기본 동작 ..

시작은 단순했다. Controller의 반환 타입은 String이어도 되고, Integer, DTO여도 된다.Spring은 이를 자동으로 JSON으로 직렬화하고, 기본적으로 200 OK와 함께 내려준다. 그런데 우리는 습관처럼 이렇게 작성한다.return new ResponseEntity.ok(data); 처음에는 그냥 그러려니 했다. 그런데 문득 이런 생각이 들었다.굳이 한 번 더 감싸는 이유가 뭘까?그냥 객체를 반환하면 안 되는 걸까?한 번 정리해보자.ResponseEntity는 무엇인가?ResponseEntity는 Spring에서 제공하는 HTTP 응답을 표현하는 객체다. 조금 더 정확히 말하면,HTTP Response 전체(상태 코드 + 헤더 + 바디)를 담는 컨테이너다. 구조적으로 보면 다음 세..

Spring Boot 4가 나왔다는 소식을 듣고 토이프로젝트에 Spring Boot 4를 도입해보기로 했다.4로 마이그레이션을 진행하면서 예상치 못한 문제를 하나 마주쳤다..! Cannot resolve symbol 'DataJpaTest' 기존에는 아무 문제 없이 사용하던 @DataJpaTest가 Spring Boot 4로 올리자마자 IDE에서 인식되지 않았다. 처음에는 JPA 설정 문제나 버전 충돌을 의심했지만,결론부터 말하면 Spring Boot 4의 테스트 스타터 구조 변경이 원인이었다.분명 예전엔 됐는데, 왜 지금은 안 될까?Spring Boot 3.x까지는 테스트 의존성을 보통 이렇게 가져왔다.testImplementation "org.springframework.boot:spring-boo..

✅ 왜 API 문서화가 필요한가?백엔드와 프론트엔드가 분리된 개발 환경에서 API 문서화는 필수다.백엔드 - 프론트엔드 협업 : 정확한 API 스펙 공유로 개발 효율성 증대커뮤니케이션 비용 절감 : "이 API 어떻게 호출하나요?" 질문 감소병렬 개발 가능 : API 스펙 확정 후 각자 개발 진행 📋 API 문서화 방법들1. 수동 문서 작성 - Notion, Confluence 등에 직접 작성 - 단점 : 코드 변경 시 문서 동기화 누락, 유지보수 어려움 2. Postman Collection - 장점 : 테스트와 문서화 동시 해결 - 단점 : 개발자 중심, 비개발자가 보기 어려움 3. Spring REST Docs - 장점 : 테스트 기반으로 정확성 보장, 운영 코드에 어노테이션 불필요 - 단점 :..

Java Switch Expression 완벽 가이드왜 만들어졌을까?기존 switch문은 여러 가지 문제점을 가지고 있었다. 기존 Switch문의 문제점// 기존 방식의 문제점들String dayType;switch (day) { case MONDAY: case TUESDAY: case WEDNESDAY: case THURSDAY: case FRIDAY: dayType = "평일"; break; // break를 빼먹으면 fall-through 발생! case SATURDAY: case SUNDAY: dayType = "주말"; break; default: dayType = "알 수 없음"; ..

Record의 등장 배경Java 14에서 프리뷰 기능으로 처음 도입되었고, Java 16에서 정식 기능으로 추가된 Record는 불변 데이터를 다루는 클래스를 더 간결하게 작성할 수 있도록 만들어졌다.기존에는 단순한 데이터 홀더 클래스를 만들기 위해서도 많은 보일러플레이트 코드가 필요했었다. 필드 선언, 생성자, getter, equals(), hashCode(), toString() 메서드를 모두 작성해야했다. 이는 코드 가동성을 떨어뜨리고 실수할 가능성을 높였다. * 보일러플레이트 코드?보일러플레이트(Boilerplate) 코드는 반복적으로 작성해야 하는 정형화된 코드.실제 비즈니 로직과는 관계없지만, 언어나 프레임워크의 요구사항을 충족시키기 위해 반드시 작성해야 하는 코드. 기존에는 단순한 데이터 ..