LangGraph 에이전트에 PostgreSQL BM25를 직접 붙여본 기록 – Elasticsearch 없이 검색 노드 만들기

PostgreSQL_BM25

며칠 전 PostgreSQL 안에서 BM25 검색이 네이티브로 돌아간다는 소식을 보고 바로 테스트해봤다. 그동안 하이브리드 검색을 하려면 BM25는 PostgreSQL의 tsvector로 어설프게 흉내내거나, 아예 Elasticsearch를 따로 띄우는 수밖에 없었다. 그런데 이제 PostgreSQL 익스텐션 하나로 진짜 BM25 스코어링이 인덱스 레벨에서 돈다는 거다. 마침 LangGraph 에이전트의 검색 노드를 손보던 시기여서, 바로 적용해봤다. 이 글은 그 적용 과정과 결과를 정리한 … Read more

FastAPI RAG 서버가 느려진 이유! 비동기인데 왜 막히나 싶었던 디버깅 기록

fastapi_rag_비동기

분명히 비동기로 짰는데 왜 느려지는 거지. RAG 서버 운영하면서 가장 많이 했던 생각이 이거다. FastAPI는 처음부터 async를 전제로 설계된 프레임워크다. 동시성 처리에 강하다는 게 거의 상식처럼 통한다. 그런데 실제로 RAG 파이프라인을 얹어서 운영해보면, “비동기로 썼다”는 사실 자체가 성능을 보장해주지 않는다는 걸 몸으로 배운다. 이 글은 내가 운영하던 RAG API가 동시 요청 몇 개만 들어와도 응답 … Read more

Qdrant vs PostgreSQL, RAG 검색 인프라 두 가지 다 운영해본 결론

Qdrant vs PostgreSQL

얼마 전에 새 RAG 파이프라인을 설계할 일이 있었다. 기존에 운영하던 시스템은 PostgreSQL에 pgvector를 얹어서 벡터 검색까지 한 곳에서 처리하는 구조였다. 그런데 이번에는 검색 정확도 요구사항이 더 높았고, 팀 내부에서 “Qdrant로 가야 하지 않냐”는 의견이 나왔다. 그래서 결국 둘 다 직접 붙여보고 비교하게 됐다. 이 글은 그 과정에서 겪은 걸 정리한 글이다. 어느 쪽이 “더 좋다”는 … Read more

Claude Code를 RAG 파이프라인에 붙여봤다. 코드 안 짜고 디버깅한 날의 기록

claude_code_rag_pipeline

올해 초, 앤트로픽이 조용히 하나의 숫자를 꺼냈다. 자사 프로덕션 코드베이스에 병합되는 코드의 80% 이상이 이제 Claude가 작성한다는 것. 심지어 내부 엔지니어 한 명은 5개월째 코드를 직접 한 줄도 작성하지 않았다고 했다. 처음 이 글을 봤을 때 솔직히 반응이 두 갈래로 갈렸다. “그게 가능하다고?” 하는 의심과, “그럼 나도 한번 해봐야 하는 거 아닌가” 하는 호기심. 나는 … Read more

앤트로픽이 직접 꺼낸 말, “AI가 스스로를 만들기 시작했다”, “에이전트 콘웨이”

앤트로픽_콘웨이

2026년 6월 4일, 앤트로픽이 블로그에 글 하나를 올렸다. 제목은 조용했지만 내용은 조용하지 않았다. “When AI Builds Itself.” AI가 스스로를 만들고 있다는 선언. 그 안에 이런 숫자가 박혀 있었다. 현재 앤트로픽 프로덕션 코드베이스에 병합되는 코드의 80% 이상이 클로드가 작성한 것이다. 엔지니어 한 명은 5개월째 코드를 한 줄도 직접 쓰지 않았다고 한다. 클로드 코드가 2025년 2월에 출시되기 … Read more