이번 주는 정말 정신없이 지나갔다. 드디어 EC2에 AI 코드를 git clone으로 올리고 API 호출까지 성공시켰다. 이때까지만 해도 '아, 이제 거의 다 왔다!' 싶었는데, Swagger로 응답값을 확인해보니 내가 생각했던 결과랑은 전혀 딴판이었다. 그때부터 지옥의 프롬프트 재작성이 시작됐다.
그러다 멘토링 시간에 이 고민을 털어놓았는데, 멘토님께서 EC2보다 ECS가 더 좋을 거라는 조언을 해주셨다. 인프라뿐만 아니라, 내가 벡터 저장소로 쓰던 FAISS에 대해서도 다시 생각해보는 계기가 되었다.
주말에도 쉬지 않고 AI 프롬프트를 뜯어고치면서, 'FAISS 말고 Chroma로 갈아타볼까?' 하는 생각이 머릿속을 맴돌았다. 사실 처음엔 캐시 저장소를 이용하니까, 최초 임베딩 때만 시간이 좀 걸리고 그 다음부터는 결과가 빠르게 나와서 꽤 만족하고 있었다. 그래도 더 좋은 방법이 있다면 당연히 바꿔봐야지.
처음에 내가 생각했던 FAISS와 Chroma의 가장 큰 차이는 이랬다.
FAISS는 벡터 '스토어'가 아니라, 그냥 페이스북에서 만든 벡터 '라이브러리'일 뿐이다. 그래서 메타데이터를 이용한 인덱싱 같은 것도 안되고, 벡터 값이 한 100만 개? 정도 넘어가면 속도 저하가 너무 심하다.
반면에 Chroma는 진짜 벡터 '스토어'고, 메타데이터를 사용할 수 있는 제대로 된 벡터 저장소다.
이 생각이 맞는지 좀 더 깊게 파고들어 보니, 내가 생각했던 게 거의 맞았고 몇 가지 더 중요한 차이점들을 깨닫게 됐다. 이번 기회에 확실히 정리하고 넘어가야겠다.
내가 몰랐던 FAISS의 진짜 모습
FAISS는 정말 말 그대로 초고속 유사도 검색 '계산기' 같은 존재였다. 모든 인덱스를 메모리에 올려놓고 계산만 빠르게 해주는 역할에 극도로 충실한 놈이었다. 데이터를 추가하거나 삭제하려면 인덱스 전체를 다시 만들어야 해서 운영이 까다롭고, '2024년 데이터 중에서만 찾아줘' 같은 메타데이터 필터링은 다른 DB의 도움 없이는 불가능했다. 내가 겪었던 속도 저하도 결국 메모리 문제였을 가능성이 크다.
Chroma가 매력적인 이유
반면에 Chroma는 처음부터 AI 애플리케이션을 위한 '데이터베이스'로 설계된 녀석이었다.
벡터 데이터와 메타데이터를 한 쌍으로 취급해서 저장하고, 내가 원했던 메타데이터 기반 필터링 검색을 아주 쉽게 할 수 있었다. 데이터를 디스크 기반으로 관리하니 서버의 RAM 용량을 걱정할 필요도 없고, 데이터 추가/삭제도 자유로웠다. LangChain 같은 프레임워크와 붙이기도 훨씬 편해 보였다.
