Stitchhhh

복합 인덱스 설계의 오해와 실체: 선택도가 아니라 연산자가 기준이다

인덱스를 만들 때 "선택도(Selectivity)가 높고 데이터가 잘 분산된 칼럼을 앞에 두라"는 조언이 많지만, 이는 데이터베이스 내부 동작 원리를 고려하지 않은 오해에 가깝습니다. 복합 인덱스 칼럼 순서를 결정하는 진짜 기준을 정리합니다.1. 모든 조건이 등호(=)일 때: 순서는 상관없다두 칼럼을 모두 등호 조건으로 조회하는 경우, 칼럼 순서가 바뀌어도 성능 차이는 없습니다.SELECT * FROM employees WHERE employee_id = 123 AND subsidiary_id = 20;이유: B-Tree 인덱스는 왼쪽 칼럼부터 순서대로 다단 정렬됩니다. 두 조건 모두 명확한 값(=)을 지정했다면, 어느 칼럼이 앞에 오든 목적지 데이터로 향하는 탐색 경로와 비용은 동일합니다.진짜 기준: ..

최근 비동기 처리를 구현하면서 코루틴의 내부 동작과 활용법을 깊이 있게 검토해 보았습니다. 단순히 API를 사용하는 수준을 넘어, 코루틴의 작동 원리와 최신 Java 21 가상 스레드(Virtual Thread)와의 차이점, 그리고 실무적인 예외 처리 전략을 중심으로 학습한 내용을 정리해 보았습니다.1. 동시성 메커니즘의 비교 (Thread vs Coroutine vs Virtual Thread)효율적인 동시성 제어를 위해서는 각 메커니즘이 자원을 어떻게 관리하는지 파악하는 것이 우선이라고 생각합니다. 관리 주체와 비용에 따른 차이를 다음과 같이 정리했습니다.구분스레드 (Platform)가상 스레드 (Java 21)코루틴 (Kotlin)관리 주체OS 커널JVM (Project Loom)Kotlin 런타임..

Java 21에서 정식 도입된 가상 스레드(Virtual Thread)는 기존 플랫폼 스레드 모델의 자원 한계를 극복하기 위한 새로운 동시성 모델입니다. 본 포스팅에서는 가상 스레드의 설계 배경, 동작 원리, 그리고 실무 적용 시 반드시 알아야 할 핵심 개념을 정리해 보겠습니다.1. 가상 스레드의 설계 배경자바 애플리케이션의 성능은 오랫동안 운영체제(OS)의 스레드를 직접 사용하는 플랫폼 스레드(Platform Thread)에 종속되어 왔습니다. 하지만 플랫폼 스레드는 다음과 같은 물리적 제약이 존재합니다.메모리 점유: 스레드 하나당 약 1~2MB의 스택 메모리를 점유하므로 수천 개 이상의 스레드를 운용하기 어렵습니다.I/O 대기 손실: DB 조회나 외부 API 호출 시, 응답이 올 때까지 스레드는 자원..

백엔드 개발을 하다 보면 서비스 레이어의 처리 결과를 컨트롤러에 어떻게 전달할지 고민하게 됩니다. 데이터가 없으면 null을 보낼지, 아니면 Exception을 던져야 할지 모호한 경우가 많죠. 이럴 때 Sealed Interface를 활용하면 응답의 상태를 명확하게 강제할 수 있고, 코드의 안정성도 획기적으로 높아집니다.1. Sealed Interface 응답 구조 설계성공, 데이터 없음, 에러 상황을 하나의 인터페이스로 묶어 관리하는 방식입니다. 여기서 핵심은 상황에 따라 class와 object를 적절히 섞어 쓰는 것입니다.sealed interface AnalyticsResult { // 성공: 결과 데이터라는 '본문'이 있으므로 data class data class Success(v..

Spring에서 캐시를 사용할 때 @Cacheable 어노테이션 한 줄로 마법처럼 동작하는 배경에는 CacheManager와 Cache라는 두 핵심 인터페이스의 철저한 역할 분담이 있습니다. 이 둘의 관계를 이해하면 커스텀 캐싱 전략을 훨씬 유연하게 설계할 수 있습니다.1. CacheManager: 캐시를 찍어내는 "공장이자 관리소"CacheManager는 캐시 추상화의 최상위 진입점입니다. 애플리케이션 내의 모든 캐시 인스턴스를 생성하고 관리하는 역할을 합니다.주요 역할:캐시 생성 및 조회: "users", "products" 등 이름에 맞는 Cache 객체를 생성하거나 찾아줍니다.설정의 중심: 데이터 유효 기간(TTL), 최대 크기, 직렬화 방식 등 '어떻게(How)' 저장할지를 결정합니다.라이프사이..

1. 개요Spring Cache 추상화의 가장 큰 장점은 비즈니스 로직에 캐시 코드를 섞지 않고, 어노테이션(Annotation) 만으로 선언적인 캐싱을 적용할 수 있다는 점입니다. 본 보고서는 Spring Cache의 핵심 어노테이션인 @Cacheable, @CachePut, @CacheEvict 등의 기능과 속성을 상세히 분석하고, Kotlin 환경(Data Class, Coroutines)에서의 구체적인 사용 패턴을 제시합니다.2. 핵심 어노테이션 상세 분석2.1 @Cacheable: 조회 및 저장의 자동화가장 빈번하게 사용되는 어노테이션으로, 캐시 룩어사이드(Look-aside) 전략을 수행합니다. 데이터가 캐시에 있으면 반환하고, 없으면 메서드를 실행 후 결과를 캐시에 저장합니다.2.1.1 기본..

MGET (Multi-Get)이란?MGET은 Redis와 같은 키-값(Key-Value) 저장소에서 여러 개의 키(Key)에 해당하는 값(Value)들을 단 한 번의 명령으로 가져오는 기능입니다.비효율적인 방법 (GET 반복): 필요한 물건 목록(우유, 계란, 빵)을 보고, 우유를 가지러 갔다가 계산하고, 다시 계란을 가지러 갔다가 계산하고, 또 빵을 가지러 가는 방식입니다. 물건 하나마다 계산대(네트워크)를 거치므로 매우 비효율적입니다.효율적인 방법 (MGET): 필요한 물건 목록(우유, 계란, 빵)을 장바구니에 한 번에 다 담아서 계산대에 딱 한 번만 가는 방식입니다. 이것이 바로 MGET의 원리입니다.MGET의 동작 원리와 과정MGET은 N+1 문제를 해결하기 위해 "N번의 요청을 1번의 요청으로"..

최근 기술 블로그 RSS를 스크래핑하고 AI로 내용을 요약하는 'Morning Commit' 프로젝트의 파이프라인을 개선했습니다. 구현 과정에서 마주친 성능 병목 지점과 이를 Kotlin Coroutines로 해결한 과정을 정리했습니다.1. 문제 상황: 순차 처리의 한계기존 방식은 RSS 피드에서 추출한 포스트들을 하나씩 순서대로 처리했습니다.프로세스: HTML 스크래핑 → AI 요약(LLM API 호출) → 데이터 가공 및 저장소요 시간: 포스트 당 평균 약 10초포스트 하나당 10초는 짧아 보일 수 있지만, 배치 작업의 특성상 누적 시간은 무시할 수 없습니다. 한 번에 처리해야 할 포스트가 30개만 되어도 5분이 소요되며, 연동하는 블로그 소스가 늘어날수록 전체 작업 완료 시간은 선형적으로 증가하는 ..

Spring Boot와 Redis를 연동하여 캐싱을 구현하다 보면, 특히 Kotlin 환경에서 페이징된 데이터(Page)를 캐싱할 때 두 가지 큰 장벽에 부딪히게 됩니다.InvalidDefinitionException: PageImpl은 기본 생성자가 없어 Jackson이 역직렬화를 못 함.ClassCastException: 캐시에서 꺼낸 데이터가 DTO가 아닌 LinkedHashMap으로 변환됨.이 글에서는 이 문제의 원인을 파헤치고, 커스텀 Serializer를 이용한 근본적인 해결법과 Wrapper 클래스를 이용한 간편한 해결법 두 가지를 소개합니다.문제의 원인1. PageImpl의 구조적 문제Spring Data의 PageImpl 클래스는 Jackson이 데이터를 복원할 때 필요한 기본 생성자(N..

1. 서론: "API 스펙을 직접 구현해야 하나?"'Morning Commit' 프로젝트의 핵심 기능은 기술 블로그 게시글을 AI가 분석하여 요약, 핵심 인사이트, 난이도 등을 추출하는 것입니다. 초기에는 이 기능을 구현하기 위해 가장 익숙한 방식인 REST API 직접 호출을 선택했습니다.하지만 개발을 진행할수록 비즈니스 로직보다 OpenAI의 API 스펙을 관리하는 데 더 많은 시간을 쏟고 있다는 것을 깨달았습니다.2. 태동기: 직접 통신의 시대 (OpenFeign & ObjectMapper)초기 아키텍처는 OpenFeign을 사용하여 OpenAI 엔드포인트와 통신했습니다.2-1. 직면한 문제점 (Pain Points)DTO 관리의 부담 (Boilerplate Hell)OpenAI의 요청/응답 규격을..