itsdev의 IT Blog

WithBuddy 연재 6편. L1(Caffeine) + L2(Redis) 하이브리드 캐시를 적용해 캐시 히트 경로의 p95를 1,643ms에서 263ms까지 줄였다. 이번 글에서는 왜 Redis 단독 구성이 아니라 2단 캐시를 선택했는지, 캐시에서 발생할 수 있는 장애를 어떻게 방어했는지, 그리고 “6.2배 빨라졌다”는 결과를 어디까지 신뢰할 수 있는지 함께 정리한다. 이 글에서 다루는 내용Redis 단독 대신 Caffeine + Redis 2단 캐시를 선택한 이유Cache Stampede, Penetration, 연쇄 장애와 이를 막기 위한 방어 장치캐시 히트 경로 p95를 약 84% 단축한 측정 결과“6.2배 개선”이라는 수치를 해석할 때 반드시 함께 봐야 할 검증의 한계 Redis만으로는 부족했던..

WithBuddy 연재를 시작한다. 첫 편은 아키텍처 다이어그램이 아니라, 그 다이어그램이 왜 그 모양이 될 수밖에 없었는지에 대한 이야기다.발표 자료에는 "의도적으로 설계된 Modular Monolith"라고 적혀 있었다. 틀린 말은 아니지만, 정확한 말도 아니다. 실제로는 예산이 없어서 시작된 구조였다. 그리고 나는 그 사실을 숨기는 것보다 그대로 쓰는 편이 더 설득력 있다고 생각한다.50만 원을 어디에 쓸 것인가팀 자체 예산은 0원이었다. 빌더스리그에서 지원되는 50만 원이 우리가 쓸 수 있는 전부였다.이 돈을 어디에 쓸지가 첫 번째 의사결정이었다. 팀원 전체가 Claude, ChatGPT 같은 AI 개발 도구를 구독하면 생산성이 확실히 올라간다. 하지만 인프라에 돈이 나가기 시작하면 그만큼 구독 ..

백엔드 프로젝트에서 소스 코드는 Git으로 관리한다. 하지만 데이터베이스 구조 변경 이력은 제대로 관리되지 않는 경우가 많다.초기에는 개발자가 직접 SQL을 실행하거나, 로컬 환경에서 ddl-auto=update에 의존해도 큰 문제가 없어 보인다. 그러나 프로젝트 규모가 커지고 협업 인원이 늘어나면 다음과 같은 문제가 반복적으로 발생한다.개발자마다 DB 스키마 상태가 다르고, 운영 서버 SQL 반영이 누락되며, 컬럼 추가 순서가 충돌한다. 배포 후 DDL 실행 오류, 운영 DB와 로컬 DB 구조 불일치, 그리고 롤백 불가능 상태까지. 한 번쯤은 겪어봤을 풍경이다.이러한 문제를 해결하기 위해 사용하는 대표적인 도구가 Flyway다.이 글에서는 Spring Boot 환경에서 Flyway를 어떻게 적용하고, ..

오늘은 JPA에서 데이터를 조회할 때 사용하는 List, Page, Slice의 차이점과 성능 최적화 방법에 대해 공부한 내용을 정리해본다. 특히 대용량 데이터 환경에서 왜 성능 문제가 발생하는지, 그리고 어떻게 해결할 수 있는지 알아봤다.List로 조회하기가장 기본적인 방법은 List로 데이터를 가져오는 것이다.List users = userRepository.findByStatus("ACTIVE");List의 특징조회 쿼리 하나만 실행된다조건에 맞는 모든 데이터를 한 번에 가져온다페이징 처리가 없다List의 문제점데이터가 많아지면 모든 데이터를 메모리에 올리기 때문에 OutOfMemoryError가 발생할 수 있다. 따라서 데이터 양이 확실히 적을 때만 사용해야 한다는 것을 배웠다.Page로 조회하기..

자바 백엔드 개발 생태계에서 Spring Data JPA는 생산성을 높여주는 강력한 도구이지만, 객체지향 모델과 관계형 데이터베이스(RDB) 사이의 '패러다임 불일치'를 정확히 이해하지 못하면 치명적인 런타임 오류를 야기한다. 최근 많은 주니어 개발자들이 채용 공고나 커뮤니티 시스템을 구축하며 겪는 대표적인 오류인 InvalidDataAccessApiUsageException을 중심으로, 왜 우리가 ERD와 엔티티를 완벽하게 동기화해야 하는지 객관적으로 고찰해본다.1. 현상의 발견: 왜 내 코드는 런타임에 무너지는가?Spring Boot 3.x 환경에서 JPA를 이용해 다대다 연관관계를 처리할 때 가장 흔히 발생하는 문제는 "존재하지 않는 속성에 대한 참조"이다. 개발 환경에서는 애플리케이션이 정상적으로..