Stitchhhh

[Java 21] 가상 스레드(Virtual Threads): 원리와 실무 적용 지침

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의 요청/응답 규격을..

이번 포스트에는 예약 게시글 업로드를 구현하면서 새로 배웠던 내용을 다시 한번 정리해보겠습니다. 예약 게시글 업로드를 구현하기 위해 ThreadPoolTaskScheduler, RabbitMQ를 사용하였고, 각 기술의 특징에 대해서 설명해보겠습니다. ThreadPoolTaskScheduler먼저 ThreadPoolTaskScheduler입니다. ThreadPoolTaskScheduler는 Spring Framework에서 제공하는 스케줄링용 스레드 풀 기반의 TaskScheduler 구현체입니다. ThreadPoolTaskScheduler를 사용하기 위해 Bean으로 등록을 해주었습니다.@Configurationpublic class SchedulerConfig { @Bean public Th..

컴퓨터의 구조와 성능 향상컴퓨터의 기본 구성하드웨어의 구성컴퓨터는 CPU, 메인메모리, 입력장치, 출력장치, 주변장치로 구성됩니다. 컴퓨터로 하는 작업은 대부분 CPU와 메인메모리의 협업으로 이루어지기 때문에 필수장치로 분류되고 그 외는 주변장치로 분류됩니다.. 메인메모리는 휘발성이기 때문에 영구히 보관하기 위하여 하드디스크나 USB 메모리를 사용합니다. 그래서 메인메모리를 제1저장장치라 부르고 하드디스크나 USB 메모리가 같은 메모리를 제2저장장치 또는 보조저장장치라고 부릅니다. CPU와 메인메모리CPU는 명령어를 해석하여 실행하는 장치로 메인메모리는 작업에 필요한 프로그램과 데이터를 저장하는 장소로, 바이트 단위로 분할되어 있으며 분할 공간마다 주소로 구분합니다. 입출력장치입력장치는 외부의 데이터를 ..