[개념짚고가기] FAISS 이 녀석은 왜 나타났나?

 

스터디에서 FAISS를 자꾸 언급하면서도 내가 얘를 전혀 이해하지 못하고 있단 생각이 들었다.

아 이해는 조금 했는데

얘가 왜 생겨났는지 얘가 왜 필요한건지 납득을 못했던 것 같다.

납득이 필요한가? 있으면 있는거고 필요하면 쓰고 필요없으면 안쓰고 그만이면 되는데 난 안된다.

내가 인지했으면 이해해야한다.

---

내 머릿속을 떠다니는 질문들

걱정이 된다. 아래 질문을 읽다가 와닿지 않아서 나가버릴 사람이 있을 것 같아서

잘 안 읽히면 다음 스텝으로 넘어가주길.

1. Q : "FAISS는 왜 데이터베이스가 아니라 '라이브러리'로 세상에 나왔을까?"

• 의도 : 이미 RDB가 세상을 지배하던 시대에, 왜 페이스북은 굳이 불편한 라이브러리 형태를 선택했는가?
• 포인트 : 관리(DB)보다 연산(Engine)이 우선이었던 빅테크의 고민과 '속도 올인' 전략차이.

2. Q : "FAISS와 Chroma 중 누가 먼저인가? (히스토리의 재구성)"

• 의도 : 최신 기술인 Chroma가 기준이 아니라, 왜 FAISS가 대선배일 수밖에 없는가?
• 포인트 : 2017년(추천 시스템/이미지 검색 시대) vs 2023년(LLM/RAG 대중화 시대)의 기술적 요구사항 차이.

3. Q : "RDB가 있는데 왜 벡터 전용 검색 엔진이 따로 필요할까?"

• 의도 : MySQL이나 Oracle로 벡터 검색을 하면 안 되는 물리적인 이유가 무엇인가?
• 포인트 : 텍스트 매칭(B-Tree)과 벡터 유사도 연산(L2 Distance, Cosine Similarity)의 근본적인 차이점.

---

4. Q : "FAISS를 'F1 머신', Chroma를 '세단'에 비유하는 이유는?"

• 의도 : 기술적 특징을 독자들이 이해하기 쉽게 비유로 풀어낸다면?
• 포인트 : 모든 편의 장치를 제거하고 속도에만 집중한 엔진(FAISS)과, 그 엔진을 품고 사용성(CRUD, 메타데이터 관리)을 극대화한 제품(Chroma)의 차이.

---

5. Q : "왜 실무 프로토타입 단계에서는 FAISS를 먼저 선택하는가?"

• 의도 : 단지 성능 때문인가, 아니면 개발 생산성 때문인가?
• 포인트 : 인프라 구축 비용(Server-less), 로컬 메모리 활용의 간편함, 그리고 벡터 검색의 원리를 가장 순수하게 테스트할 수 있다는 장점.

---

내가 가장 소화하기 어려웠던 부분은

아니 rdb가 있으면 당연히 바로 이와 비슷한 형태의 크로마 db 형태의 개발이 필요한거 아닌가 라이브러리가 아니고 말야였던 것 같다.

 

제미나이에 물으니 히스토리는 이렇단다.

---

1번은 당연한거 아냐? 그리고 이 내용은 불필요하지 않나 싶은데 내용을 포함한 것은 설명의 흐름을 위함이다.

1. RDB는 '벡터'를 감당할 수 없었다.

 우리가 흔히 쓰는 MySQL이나 Oracle 같은 RDB는 '텍스트'나 '숫자'를 정확히 일치(B-Tree 인덱스 등)시켜 찾는 데 최적화되어 있다. 하지만 벡터는 수백~수천 개의 숫자로 이루어진 '부동소수점 배열'이다.

• RDB의 방식 : "ID가 123인 데이터를 찾아줘" (1대 1 매칭)
• 벡터 검색의 방식 : "이 1,536개의 숫자 배열과 가장 비슷한 놈 10개를 찾아줘" (유사도 계산)

 이 '유사도 계산'을 수억 개의 데이터에 대해 RDB 방식으로 돌리면 서버가 터져버린단다.

그래서 페이스북(Meta)은 "DB의 편의성은 다 버리고, 오직 '수학적 계산 속도'에만 올인한 도구"가 필요했고, 그게 바로 FAISS란다.

2. '관리'보다 '연산'이 시급했던 시대 (2017년)

 FAISS가 나온 2017년 무렵에는 지금처럼 RAG(검색 증강 생성)라는 개념이 대중화되기 전으로, 당시에는 주로 대규모 이미지 검색, 추천 시스템 등에 벡터 검색이 쓰였다고 한다.

• 페이스북의 상황 : 수십억 명의 사용자 프로필이나 수천억 장의 사진 벡터를 처리해야 함.
• 해결책 : DB의 복잡한 기능(트랜잭션, 사용자 관리, 메타데이터 매칭 등)은 사치였습니다. 일단 메모리에 다 때려 넣고 GPU를 써서라도 광속으로 연산하는 게 우선이었던 것. 그래서 '데이터베이스'가 아닌 '라이브러리(엔진)' 형태로 탄생한 것이다.

3. 그 후, "불편함"이 Chroma를 만들었다.

구분	FAISS (Facebook AI Similarity Search)	Chroma DB
출시	2017년 (Meta Open Source)	2023년 (LLM 붐과 함께 등장)
정체성	벡터 검색용 라이브러리(Library)	벡터 전용 데이터베이스(Database)
핵심 목적	고차원 벡터의 '유사도 검색' 그 자체의 속도	LLM 앱(RAG 등) 개발을 위한 데이터 관리

 

FAISS를 써보니 속도는 엄청난데, 다른 부분에서는 너무 불편했다.

• "원문 텍스트는 따로 관리해야 하네?"
• "데이터 한 개 지우려면 인덱스 전체를 다시 만들어야 하네?"
• "서버를 껐다 켜니 데이터가 다 날아가네?"

이런 RDB 같은 편의성에 대한 목소리가 커지면서, "FAISS 같은 강력한 엔진을 내부에 품고, 겉은 RDB처럼 쓰기 편하게 만든 것"이 바로 Chroma DB나 Pinecone 같은 '벡터 데이터베이스'이다.

---

추후 공부 및 추가되어야 할 내용

'Annoy'나 'HNSW' 같은 키워드 

 

"FAISS가 광속으로 연산할 수 있는 이유는 모든 데이터를 다 뒤지는 게 아니라, ANN(Approximate Nearest Neighbor)이라는 알고리즘을 사용하기 때문이다. (쉽게 말해, '비슷한 놈들이 모여 있을 법한 동네'만 골라서 찾는 기술이다.)"

---

3. 마무리

결국 FAISS는 엔진'이고, Chroma는 그 엔진을 얹은 '완성차'다. 상황에 따라 엔진만 가져다 튜닝해서 쓸지, 편안한 세단을 탈지 결정하는 건 개발자의 몫이다.