Java Eco

검색이 10초 넘게 늘어지자 스레드 풀을 키웠다. 64개로 늘리자 컨테이너가 죽었고, 24개로 줄이자 검색이 세 건만 겹쳐도 작업이 거절됐다. 원인은 풀의 크기가 아니라, 결과를 기다리는 오케스트레이터와 그 결과를 만드는 크롤 작업이 한 풀을 나눠 쓰는 구조였다. 둘을 갈라 크롤 작업을 가상 스레드로 옮기고, 검색 경로의 분산 락까지 걷어 낸 하루의 기록이다. 원인을 적어 두고도 첫 커밋은 크기를 바꾸는 것이었던 이유까지 담았다.

같은 JDK 버전, 같은 jar 인데 AWS Lambda 에서만 JVM 이 죽었다. 원인은 Lambda 의 Java 21 런타임이 JIT 를 C1 하나로 묶어 둘 때만 켜지는 최적화에 숨어 있던 OpenJDK 결함, JDK-8386708 이었다. AI 코딩 에이전트와 함께 이 크래시를 쫓은 기록이고, 답을 손에 쥐고도 엉뚱한 가설로 실험을 6만 번 돌린 헛걸음까지 담았다.

원제 : 이것이 Spring AI다 (개정판) 저자 : 신용권 출판 : 한빛미디어, 2026 "한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다." 지난달에 LangChain 기반으로 AI 에이전트를 만드는 책을 읽었다. 체인 구성, RAG, 메모리, MCP, 종합 프로젝트까지 한 호흡으로 따라가면서 에이전트가 대강 어떤 구조로 돌아가는지 감을 잡을 수 있었다. 그런데 그 책은 Python이었다. 나는 Java 개발자다. 실무에서 Spring Boot와 Spring Framework를 매일 쓰고 있고, 솔직

스프링의 @Transactional 애노테이션 하나면 트랜잭션을 쉽게 다룰 수 있다고 생각했는데, 실무에서 쓰다 보니 생각보다 고려할 게 많았다. 프록시가 어떻게 동작하는지, 전파 규칙은 어떻게 설정해야 하는지, JPA와는 어떻게 맞물리는지 등등... 그래서 트랜잭션의 기본 개념부터 스프링이 내부적으로 어떻게 처리하는지까지, 실무에서 마주쳤던 내용들을 정리해봤다. 트랜잭션은 데이터베이스에서 데이터의 일관성과 원자성(Atomicity) 을 보장하기 위한 최소 작업 단위다. 스프링은 이 트랜잭션 개념을 추상화해서, 개발자가 데이터베이스

파일 업로드 다운로드를 개발하다 보면 내가 개발하고 있는 어플리케이션이 파일이 저장되는 종착지가 아닐때가 있다. 예를들어 하나의 백엔드 어플리케이션이 모든 도메인을 처리하고 있고 그중에 파일 관련된 핸들링도 포함되어있다면 그 백엔드가 파일 시스템 어딘가에 저장하거나 S3 스토리지로 보낸다. 그런데 마이크로서비스가 보편화된 시대에서 파일이 여러 서비스를 거쳐야 파일 핸들링을 하는 서비스에 도달하는 경우가 있을 수 있다. 그 역할을 클라우드 플랫폼에 포함된 API 게이트웨이가 아니라 Spring Framework로 만들어진 WAS가 해

Java 클래스의 생성자는 제네릭 클래스인 Constructor 의 인스턴스로 나타낸다 이 객체는 클래스 생성자의 모든 정보를 포함하고 있다. 파라미터의 수 파라미터의 타입 클래스에는 여러개의 생성자가 있을 수 있다. Class.getDeclaredConstructos() : 클래스의 모든 생성자를 반환한다. public이거나 아니거나 상관없이 모두 반환한다. Class.getConstructors() : Public 생성자만 반환한다. 특정 생성자 매개변수 유형을 알고 있는 경우 파라미터의 타입을 나타내는 타입 목록을 전달할 수

JVM 기능 런타임 동안 클래스와 객체 정보를 추출할 수 있음 Reflection API로 접근 가능 JDK에 포함된 클래스 집합 소스 코드를 수정하지 않고 새로운 프로그램 순서를 만들 수 있음. 실행하고 있는 클래스와 객체에 동적으로 코드 삽입. 실제로 사용하는 곳 로깅 프레임워크 ORM Spring Framework JUnit Jackson @Autowired @Configuration @Bean bean을 정의하고 의존성을 주입하는 과정이 reflection을 통해 이뤄짐. Reflection을 사용해 클래스를 확인하고 필드를