RAG 1편에서 RAG 파이프라인의 큰 그림을 살펴봤습니다. 이제 오프라인 인덱싱이 온라인 답변에 어떤 영향을 주는지 보겠습니다. 문서를 어떻게 쪼개는지(chunking), 어떤 임베딩으로 벡터화하는지, 청킹에서 잃은 맥락을 어떻게 보강하는지(Contextual Retrieval)를 다룹니다. 검색 후보가 부실하면 근거 기반 답변도 부실해지므로, 인덱...

사내 정책 문서를 찾는 상황을 떠올려 봅니다. “출장 규정에서 숙박비 한도가 얼마였지”, “보안 정책상 외부 저장소 사용이 허용되는가” 같은 질문의 답은 대부분 어딘가의 문서에 이미 존재합니다. 하지만 문서는 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...

S3 Tables 레이크하우스로 옮긴 데이터베이스를 IAM role로 Athena에서 쿼리하는데 테이블이 TABLE_NOT_FOUND 또는 CATALOG_NOT_FOUND로 보이지 않습니다. IAM 정책에서 Glue와 Athena 권한은 충분히 열어 뒀고, 관리자 계정으로 같은 쿼리를 던지면 정상 동작합니다. Lake Formation이 IAM 위에...

앞 편에서 프로세스 메모리가 stack/heap 등으로 나뉜다는 CS 기초를 다시 잡았습니다. 이번 편은 그 위에서 JVM이 자기 메모리를 어떤 영역으로 조직하는지를 봅니다. JVM도 하나의 프로세스지만, 자기만의 “런타임 데이터 영역(runtime data areas)”으로 메모리를 관리합니다. 이 편의 한 문장: -Xmx는 Heap만 제한한다. ...

Series 3 1편에서 리액티브는 “블로킹을 하지 않는다”는 데까지 봤습니다. 그런데 블로킹을 하지 않으면 서버 스레드는 구체적으로 어떻게 동작할까요? “적은 스레드로 많은 요청을 처리한다”는 말의 실체는 무엇이고, netty가 쓰는 메모리는 왜 JVM 힙 바깥(off-heap)에 있을까요? Spring WebFlux의 실행 모델인 event loo...