RAG 2편에서 청킹과 임베딩을, 3편에서 벡터 DB와 인덱스를 살펴봤습니다. 그런데 dense 벡터 검색만으로는 검색 품질에 한계가 있습니다. 임베딩은 의미가 비슷한 문장을 잘 찾지만, “제3조” 같은 정확한 조항 번호나 고유명사, 제품명 매칭에는 오히려 약합니다. 이번 글에서는 dense 검색과 키워드 검색을 결합하는 Hybrid Search, 두...

RAG 2편에서 문서를 청크로 나누고 임베딩으로 벡터화하는 인덱싱 설계를 살펴봤습니다. 이렇게 만들어진 수백만 개의 벡터에서 질의와 가까운 것을 빠르게 찾으려면 저장소와 인덱스가 필요합니다. 이번 글에서는 벡터 검색의 핵심 문제와 측정 축, 대표 인덱스인 HNSW와 IVF의 동작 원리, 그리고 pgvector와 Qdrant를 선택 기준 관점에서 살펴봅...

RAG 1편에서 RAG 파이프라인의 큰 그림을 살펴봤습니다. 이번 글에서는 그중에서도 검색 품질을 가장 크게 좌우하는 인덱싱 단계, 즉 문서를 어떻게 쪼개고(chunking), 어떤 임베딩으로 벡터화하며, 청킹 과정에서 잃어버리는 맥락을 어떻게 되살리는지(Contextual Retrieval)를 다룹니다. RAG는 “검색이 틀리면 생성도 틀린다”는 구...

사내 정책 문서를 찾는 상황을 떠올려 봅니다. “출장 규정에서 숙박비 한도가 얼마였지”, “보안 정책상 외부 저장소 사용이 허용되는가” 같은 질문의 답은 대부분 어딘가의 문서에 이미 존재합니다. 하지만 문서는 PDF, Confluence 위키, 사내 위키 등 여러 곳에 흩어져 있고, 일반 LLM에게 물으면 그 문서를 본 적이 없으니 그럴듯하지만 틀린 ...

이 커리큘럼은 하나의 질문에서 시작했습니다. “Spring Boot 메이저 업그레이드(새 JDK/G1GC 동반) 이후, Old gen이 예전보다 높게 유지되고 컨테이너 메모리가 빠듯해 보인다. 메모리 누수일까?” 마지막 글에서는 Series 1~4에서 쌓은 조각(요청 처리, JVM 메모리, GC, 동시성, 데이터 계층)을 모아 이 질문을 끝까지 진단합...

Series 1에서 “요청이 흐르는 길”을 위에서 아래로 따라왔고, 3편에서 “스레드 스택은 힙이 아니라 native 메모리”라고 했습니다. 이번 편에서는 그때 흘려보낸 stack과 heap이 각각 무엇이고 어떻게 다른지를 프로세스 메모리 레이아웃 관점에서 정리합니다. Series 2는 한 계층 더 내려가 JVM과 메모리를 다룹니다. 그 첫걸음으로,...

앞 편에서 “컨테이너 메모리 = Heap + Non-heap + 여유”라는 걸 봤습니다. 그런데 -Xmx(Heap)를 누가 정할까요? 명시하지 않으면, Spring Boot 컨테이너 이미지에서는 buildpack의 Memory Calculator가 자동으로 계산합니다. 그리고 그 계산식이 앞 편의 분해 그대로입니다. 이 편은 Series 1 4편의 ...

앞 편에서 G1의 기계장치(pause 목표, adaptive IHOP, mixed collection)를 봤습니다. Series 2의 마지막인 이번 편은 그 손잡이를 튜닝하거나, JDK 버전이 G1의 휴리스틱을 바꿀 때 메모리 곡선이 어떻게 달라지는지를 다룹니다. 흔한 증상 하나: “런타임(JDK) 업그레이드 후 Old gen이 예전보다 높게 유지된...

ep2~3에서 메모리가 “어떻게 잡히나”(Heap + Non-heap, buildpack이 -Xmx 계산)를 봤습니다. 이번 편은 그 Heap 안에서 GC가 메모리를 어떻게 회수하는지입니다. 그리고 이게 다음 편(업무 메모리/GC 이슈)의 토대가 됩니다. TL;DR GC는 도달 가능성(reachability) 으로 live/garb...

이 글은 AWS 데이터 분석 스택 시리즈의 마지막 편입니다. 앞선 AWS Lake Formation 글에서 Lake Formation이 IAM 위에 얹히는 별도의 데이터 권한 게이트라는 점과 grant 모델, credential vending을 정리했습니다. 이번 글에서는 그 개념을 실제 트러블슈팅에 적용합니다. 상황은 이렇습니다. S3 Tables...