Hermes Agent는 터미널과 메시징 환경에서 동작하는 self-hosted open-source agent입니다. 단순한 CLI 챗봇이 아니라 memory, SOUL.md persona, skills, cron, messaging gateway를 함께 사용해 개인 작업 환경에 상주하는 자율 AI agent로 구성할 수 있습니다. 이번 글에서는 W...
RAG 1편에서 RAG 파이프라인의 큰 그림을 살펴봤습니다. 이번 글에서는 그중에서도 검색 품질을 가장 크게 좌우하는 인덱싱 단계, 즉 문서를 어떻게 쪼개고(chunking), 어떤 임베딩으로 벡터화하며, 청킹 과정에서 잃어버리는 맥락을 어떻게 되살리는지(Contextual Retrieval)를 다룹니다. RAG는 “검색이 틀리면 생성도 틀린다”는 구...
서버 쪽 observability는 APM, logs, metrics로 비교적 익숙하게 다룹니다. 그런데 “백엔드는 200 OK로 빠르게 응답했는데 사용자는 느리다고 한다”는 상황은 server-side 신호만으로는 잘 잡히지 않습니다. 느린 렌더링, 레이아웃 이동, 브라우저 JS 에러처럼 사용자가 실제로 겪는 문제는 대부분 client-side에서 ...
RAG 2편에서 청킹과 임베딩을, 3편에서 벡터 DB와 인덱스를 살펴봤습니다. 그런데 dense 벡터 검색만으로는 검색 품질에 한계가 있습니다. 임베딩은 의미가 비슷한 문장을 잘 찾지만, “제3조” 같은 정확한 조항 번호나 고유명사, 제품명 매칭에는 오히려 약합니다. 이번 글에서는 dense 검색과 키워드 검색을 결합하는 Hybrid Search, 두...
지금까지의 시리즈에서 검색 품질을 높이는 인덱싱, 벡터 DB, hybrid search와 접근제어를 다뤘습니다. 실제 서비스에 올리면 그다음으로 마주치는 문제는 응답이 느리다는 점입니다. RAG는 매 질문마다 검색과 생성을 모두 수행하므로 단계마다 지연이 쌓이고, 정확도를 높이려 붙인 reranking이나 접근제어가 다시 지연을 늘립니다. 이번 글에서...
RAG 1편부터 6편까지 검색 파이프라인을 인덱싱, 벡터 DB, 검색 정확도, 보안, 지연/평가 순으로 살펴봤습니다. 이번 글에서는 검색된 청크를 LLM에 넘겨 답을 만드는 generation 단계와, 이 단계에서 출처(citation)를 어떻게 보장하는지를 다룹니다. 이어서 표준 vector RAG를 넘어서는 고급 기법인 GraphRAG와 Agent...
매일 ./gradlew bootJar나 mvn package를 치고, 만들어진 app.jar를 java -jar로 실행합니다. 그런데 그 사이에 무슨 일이 일어날까요. 의존성에 버전을 안 적었는데 어떻게 빌드가 되고, 하나의 jar 안에 라이브러리가 전부 들어가는 건 어떻게일까요. Series 5(빌드/보안)의 첫 글에서는 빌드 도구가 하는 일, 의존...
앞 편에서 “컨테이너 메모리 = Heap + Non-heap + 여유”라는 걸 봤습니다. 그런데 -Xmx(Heap)를 누가 정할까요? 명시하지 않으면, Spring Boot 컨테이너 이미지에서는 buildpack의 Memory Calculator가 자동으로 계산합니다. 그리고 그 계산식이 앞 편의 분해 그대로입니다. 이 편은 Series 1 4편의 ...
앞 편에서 프로세스 메모리가 stack/heap 등으로 나뉜다는 CS 기초를 다시 잡았습니다. 이번 편은 그 위에서 JVM이 자기 메모리를 어떤 영역으로 조직하는지를 봅니다. JVM도 하나의 프로세스지만, 자기만의 “런타임 데이터 영역(runtime data areas)”으로 메모리를 관리합니다. 이 편의 한 문장: -Xmx는 Heap만 제한한다. ...
1편에서 요청이 Controller -> Service -> Repository를 거쳐 처리되고, 이들이 “전부 빈(Bean)으로 힙에 상주한다”고 했습니다. 그런데 빈이 정확히 뭐고, 왜 우리는 이 객체들을 직접 new로 만들지 않을까요? 이 글은 Spring의 가장 근본적인 질문 - “Spring은 대체 무슨 일을 해주는가”에 답합니다...