ebson

이 글은 RAG 아키텍처 발전사 시리즈의 다섯 번째이자 마지막 편입니다. 1편에서 Naive RAG의 단순한 Retrieve → Read 파이프라인으로 출발하여, 2편에서 Hybrid Search와 Reranker로 검색 품질을 높이고, 3편에서 Self-RAG와 CRAG로 자기 성찰과 교정 능력을 도입했으며, 4편에서 Ontology-Enhanced RAG로 도메인의 형식적 지식을 파이프라인에 심는 과정까지 살펴보았습니다. 이번 편에서는 그 여정의 2026년 3월 기준 현재 도달점인 4세대 Agentic RAG를 다룹니다.정적 파이프라인의 한계이 시리즈를 관통하는 하나의 흐름이 있습니다. 각 세대는 이전 세대의 명확한 한계에 대한 응답으로 등장했고, 그 한계의 상당 부분은 파이프라인이 사전에 설계된 정..

이 글은 RAG 아키텍처 발전사 시리즈의 네 번째 편입니다. 이전 편에서 3세대 Modular/Self-Corrective RAG가 자기 성찰, 교정, 적응적 라우팅, 구조적 검색, 모듈화를 통해 파이프라인에 시스템 수준의 지능을 도입한 과정을 살펴보았습니다. 이번 편에서는 3.5세대 Ontology-Enhanced RAG를 다루며, 시리즈의 마지막 편인 4세대 Agentic RAG로 이어질 예정입니다.Graph RAG와 온톨로지 사이의 간극3세대에서 다룬 Graph RAG는 소스 문서에서 LLM으로 엔티티와 관계를 자동 추출하여 Knowledge Graph를 구축하고, 커뮤니티 기반 요약으로 전역 질의에 대응하는 접근이었습니다. 이것만으로도 기존 벡터 기반 검색의 지역적 한계를 크게 넘어선 것이었지만,..

이 글은 RAG 아키텍처 발전사 시리즈의 세 번째 편입니다. 이전 편에서 2세대 Advanced RAG의 네 가지 기법(Hybrid Search, Reranker, RAPTOR, Tree RAG)이 검색 품질을 어떻게 향상시켰는지 살펴보았고, 이번 편에서는 그 다음 단계인 3세대 Modular / Self-Corrective RAG를 다룹니다. 시리즈는 이후 3.5세대 Ontology-Enhanced RAG, 4세대 Agentic RAG로 이어질 예정입니다. 2세대가 해결하지 못한 것2세대 Advanced RAG는 "더 좋은 문서를 더 정확하게 가져오는 것"에 성공했습니다. Hybrid Search로 검색 커버리지를 넓히고, Reranker로 정밀도를 높이며, RAPTOR와 Tree RAG로 검색 대상의..

이 글은 RAG 아키텍처 발전사 시리즈의 두 번째 편입니다. 이전 편에서 1세대 Naive RAG의 구조와 의의를 살펴보았고, 이번 편에서는 그 한계를 극복하기 위해 등장한 2세대 Advanced RAG를 다룹니다. 시리즈는 이후 3세대 Modular/Self-Corrective RAG, 3.5세대 Ontology-Enhanced RAG, 4세대 Agentic RAG로 이어질 예정입니다. Naive RAG가 남긴 숙제이전 편에서 Naive RAG의 네 가지 구조적 한계를 정리한 바 있습니다. 검색 품질에 전적으로 의존하는 구조, Dense Retrieval만으로는 키워드·희귀 엔티티 매칭이 어려운 문제, 청크 단위 검색으로 인한 거시적 맥락 부재, 그리고 모든 질의에 대해 무조건 검색을 수행하는 비효율성..

이 글은 RAG(Retrieval-Augmented Generation) 아키텍처의 발전 흐름을 정리하는 시리즈의 첫 번째 편입니다. 시리즈는 1세대 Naive RAG를 시작으로, 2세대 Advanced RAG(Hybrid Search, Reranker, RAPTOR, Tree RAG), 3세대 Modular/Self-Corrective RAG(Self-RAG, CRAG, Adaptive-RAG, Graph RAG), 3.5세대 Ontology-Enhanced RAG, 그리고 4세대 Agentic RAG까지 이어질 예정입니다. 각 세대가 이전 세대의 어떤 한계를 극복하기 위해 등장했는지를 중심으로 살펴볼 계획이며, 이번 편에서는 그 출발점인 Naive RAG를 다룹니다.LLM은 왜 외부 검색이 필요했는가..

LLM 기반 서비스가 일상적인 개발 환경으로 들어왔습니다. 그러나 우리가 호출하는 LLM API 역시 결국 HTTP 위에서 동작합니다. 모델의 파라미터 수나 추론 최적화만으로는 사용자가 체감하는 응답 속도를 설명하기 어렵습니다. 네트워크 계층에서 어떤 프로토콜을 사용하고 있는지에 따라 지연 특성은 달라집니다. HTTP의 진화는 기능 추가의 역사가 아니라 병목을 줄이기 위한 설계 변화의 과정이라고 이해하고 있습니다. 이 글에서는 HTTP/1.1부터 HTTP/2, 그리고 HTTP/3와 QUIC까지 이어지는 흐름을 RFC 기반으로 정리해보고자 합니다. HTTP/1.1의 구조적 한계 HTTP/1.1은 RFC 2616에서 정의되었고, 이후 메시지 문법과 의미는 RFC 7230부터 RFC 7235까지의 문서로 재..

LLM API를 호출하고 스트리밍 응답을 받는 일은 이제 일상이 되었습니다. 그러나 우리가 InputStream.read()를 호출하는 순간, 그 아래에서 어떤 계층과 버퍼를 거쳐 데이터가 올라오는지 설명해보면 생각보다 명확하지 않은 경우가 많습니다. 이 글에서는 소켓이 무엇인지, 파일 I/O와 TCP I/O는 어떻게 다른지, 커널 버퍼는 어떤 역할을 하는지, 그리고 packet·segment·frame은 무엇이 다른지 공식 문서 기반으로 다시 정리해보려 합니다. 개념을 암기하기 위한 글이 아니라, 실무에서 병목을 설명할 수 있는 관점을 정리하는 것이 목적입니다. Socket이란 무엇인가? 소켓은 네트워크 통신을 위한 추상화입니다. 이 추상화는 University of California, Berkel..