Zustand의 persist 미들웨어에서 사용하는 Hydration(하이드레이션)은쉽게 말해 스토리지(localStorage 등)에 저장된 데이터를 메모리(Zustand 스토어)로 다시 불러와 합치는 과정을 의미한다. `_hasHydrated`가 왜 필요한가요?Zustand `persist`는 앱이 실행되자마자 스토리지에서 데이터를 읽어오지만, 이 과정은 찰나의 시간(비동기적 특성)이 걸린다.이 때 다음과 같은 문제가 발생할 수 있다.데이터 불일치 : 새로고침 직후, Zustand 스토어는 잠시 동안 초기값(session: null)을 가진다. 하지만 실제 Local Storage에는 로그인 정보가 들어있다.깜빡임 현상(Flicker) : 사용자 정보가 복원되지 않았는데 AutoGuard가 먼저 작동하..

RAG(Retrieval-Augmented Generation)검색(Retrieval)과 생성(Generation)을 결합한 AI 아키텍처LLM이 답변을 생성하기 전에 외부의 신뢰할 수 있는 데이터베이스나 문서 저장소에서 관련 정보를 먼저 검색한 뒤, 그 정보를 바탕으로 문장을 생성하는 방식RAG 아키텍처 구성 요소Dense Retriever (예: DPR)사용자가 질문을 하면, 관련 있는 문서나 정보를 찾음단순히 단어가 똑같은 것이 아니라 뜻이 비슷한 문장이나 내용을 파악해 골라옴Document Store (예: Vector 데이터베이스)찾을 문서들이 저장되어있는 데이터베이스다양한 정보가 저장되어 있고, Retriever가 적절한 문서를 뽑아오는 구조흔히 FAISS, Pinecone, Weaviate ..

@Configuration`@Bean` 메서드를 통해 스프링 빈을 직접 등록할 때 사용다른 설정을 조합/활성화(`@Import`, `@Enable`...)하는 용도에도 쓰인다.@ConfigurationProperties"외부 설정값(application.yml/properties)을 이 객체 필드에 바인딩하겠다"는 것을 선언하는 것과 같다.설정을 필드에 매핑해 주입받는 설정 값 홀더(POJO)를 만들 때 사용한다.자동으로 빈으로 지정되는 것은 아니며, 빈으로의 등록이 필요하다.`@EnableConfigurationProperties``@ConfigurationPropertiesScan``@Component`즉, @Configuration는 스프링 빈들을 만드는/등록하는 클래스로 만들어준다.@Configu..

개요현재 인턴 중인 곳에서 기존 1차 개발이 되어있던 프로젝트를 보수하고, 새로운 기능을 추가하여 정식 배포를 준비 중에 있다.그 중 QA 결과로 PDF 프리뷰를 제공하는 페이지에 진입 시 해당 PDF가 자동 다운로드 되는 현상이 발견되어 해결을 요청 받았다.확인해본 결과 문제 상황은 다음과 같았다.상세 페이지에서 html `` 태그로 pdf 프리뷰 제공 중일부 pdf를 대상으로 프리뷰가 성공적으로 렌더링 되지 않고, 자동 다운로드 되는 문제 발생원인 분석현재 프리뷰를 제공 대상인 pdf는 사용자가 서비스 내에서 업로드한 pdf로, CDN에서 제공하는 url을 사용하여 가져온다.프리뷰에 성공하는 pdf와 실패하는 pdf의 CDN url로 curl 명령어을 통해 응답 헤더를 확인해보았다.curl 명령어를 ..

☑️ 문제 정의 : 비동기처럼 보이는 동기 처리현재 우리 시스템의 알림 전송은 SQS 기반 Outbox 패턴을 따르고 있다.알림이 필요한 이벤트가 발생하면 다음과 같은 흐름으로 메시지가 처리된다.알림 정보를 Notification 테이블(사용자 조회용)과 Outbox 테이블(메시지 발행용)에 저장저장된 메시지를 SQS에 발행SQS 소비자가 메시지를 받아 실제 사용자에게 알림 전송알림 전송은 구조적으로 비동기처럼 보이지만, SQS로 메시지를 발행하는 로직만은 동기적으로 동작하고 있었다.이로 인해 대규모 알림 발송 시 병목이 발생할 수밖에 없는 구조였다.▶︎ 단계별 병목 지점 정리병목이 예상되는 지점은 다음과 같다.알림 데이터를 DB에 저장할 때메시지를 SQS로 발행할 때알림을 사용자에게 전송할 때단계처리 ..

서론기존에는 Spring의 `ApplicationEventPublisher`와 Redis의 Pub/Sub 구조를 활용해 알림 기능을 구현하고 있었다.이 구조는 내부 서버간 이벤트 전파와 브라우저 클라이언트로의 SSE 알림 전송에 효과적이었지만, 알림 수가 많아질수록 처리에 병목이 생길 수 있으며 실패시 재처리가 어렵다는 문제가 있었다.이러한 한계를 해결하고자 AWS SQS를 도입하여 알림 시스템을 재구성하게 되었다. 이 글에서 구조 설계, 고민했던 부분들과 해결 방안을 중심으로 알림 시스템 전환 과정을 정리하고자 한다.SQS를 도입하게 된 이유기존에는 웨이팅 호출 시 해당 웨이팅의 사용자에게 알림을 보내는 기능만 있었지만, 이후 쿠폰 이벤트가 시작되면 해당 가게를 찜한 사용자 전체에게 알림을 발송해야 하..

AWS SQS란?Simple Queue Service로, AWS에서 서비스하는 메시지 큐이다.메시지 큐를 왜 사용할까?하나의 API 요청에 동시에 수행되는 후처리 작업들이 많은 경우 ⇒ 응답 지연 최소화 및 시스템 간 결합도 감소 가능문제 상황응답 지연 문제 : API 내부에서 동기로 처리한다면 응답 대기 시간이 증가함 → UX 저하장애 전파 위험 : 외부 API 호출이 포함되는 경우, 서비스 하나에 장애가 나도 전체 기능 장애로 이어질 가능성이 높음해결한 API는 관련 작업만 처리하고, 동반되어야 하는 각 작업을 메시지로 만들어 큐에 넣음각각의 작업을 담당하는 Consumer가 큐에서 메시지를 비동기적으로 소비하여 처리함효과고객의 응답 대기 시간 감소후처리 시스템에 장애가 나도 메인 작업 자체는 정상 ..

최근 실시간 알림 기능을 구현하면서 공부했던 실시간 데이터 전송에 대표적인 기술들을 정리해본다.1. Polling주기적으로 서버에 요청을 보내 업데이트를 확인하는 방식클라이언트에서 서버로 계속해서 request를 전송한다.서버는 반복되는 request에 응답하면서, 전달할 이벤트가 있는 경우 전달한다.▶︎ 장점구현이 간단하다. (기본 HTTP만 지원되면 구현 가능)▶︎ 단점불필요한 요청이 많아지므로 서버 부하가 증가한다.새 이벤트가 발생하자마자 확인할 수는 없어 지연(Latency)이 존재한다.다수 클라이언트가 있을 경우 네트워크 오버헤드가 증가한다.매우매우 간단하게 실시간 (비슷한) 서비스를 구현해볼 수 있는 방식 2. Long Polling클라이언트가 서버에 요청을 보내고, 서버는 새로운 데이터가 있..