AI 챕터 생성기를 만들면서 왜 벡터 데이터베이스 (Vector Database)를 가장 먼저 찾지 않게 되었는지에 대하여.

AI 챕터 생성기를 만들기 시작했을 때, 나는 벡터 데이터베이스 (Vector Database)를 조사하는 데 수 시간을 보냈습니다. 나는 그것이 반드시 필요하다고 확신했습니다.

하지만 필요하지 않았습니다.

아이디어

서류상으로 이 프로젝트는 간단했습니다. 사용자가 긴 강의 영상을 업로드하면, 앱이 이를 전사 (Transcribe)하고, 강사가 한 주제에서 다음 주제로 넘어가는 지점을 파악하여, 타임스탬프가 찍힌 챕터를 출력하는 방식입니다.

실제 기능을 단 한 줄도 작성하기 전에, 내 머릿속은 이미 아키텍처 (Architecture)가 어떤 모습이어야 할지 결정해 버렸습니다. 긴 텍스트와 AI 앱의 조합은 다음과 같아야 한다고 생각했습니다: 청킹 (Chunking)하고, 임베딩 (Embedding)하고, 저장하고, 검색한다. 그것이 요즘 사람들이 훈련받은 전형적인 형태입니다.

그래서 나는 그 길을 따라갔습니다. 저녁 내내 Pinecone, Chroma, FAISS를 비교했습니다. 청킹 전략 (Chunking strategies), 고정 크기 청크 (Fixed size chunks), 중첩 윈도우 (Overlapping windows), 의미론적 청킹 (Semantic chunking) 등 모든 것을 읽었습니다. 내 메모 앱에는 RAG 파이프라인 (RAG pipeline)의 초안이 절반쯤 그려져 있었습니다.

그러다 나는 멈춰 서서 훨씬 더 기본적인 질문을 스스로에게 던졌습니다:

내가 실제로 해결하려는 문제가 무엇인가?

나는 제대로 된 답변을 내놓지 못했습니다. 그래서 나는 뒤로 물러나 처음부터 다시 시작했습니다.

임베딩 (Embeddings)이 실제로 하는 일

이 분야가 처음이라면, 아주 쉽게 설명해 드리겠습니다.

임베딩 (Embedding)은 텍스트 조각을 그 의미를 포착하는 숫자 리스트로 변환합니다. 비슷한 의미를 가진 텍스트는 결국 비슷한 숫자를 갖게 됩니다. 그것이 이 기술의 핵심적인 트릭입니다.

그 범위를 좁히는 과정이 바로 검색 (Retrieval)입니다. 그리고 검색은 추론 (Reasoning)과는 다른 작업임이 드러납니다.

검색 (Retrieval) vs 추론 (Reasoning)

이 부분은 제가 실제로 이해하는 데 시간이 좀 걸렸던 부분이며, 대부분의 사람들이 대수롭지 않게 넘기는 지점이라고 생각합니다.

임베딩 (Embeddings)은 검색 문제를 해결합니다. 임베딩은 당신이 완전히 다 읽을 수 없는 건더미 속에서 바늘을 찾는 데 능숙합니다.

LLM은 추론을 담당합니다. LLM은 눈앞에 놓인 것이 무엇이든 그것을 바탕으로 사고합니다.

RAG가 검색 증강 생성 (Retrieval Augmented Generation)이라고 불리는 이유는, 검색이 모델이 무엇을 볼 수 있을지를 결정하는 전처리 단계에 불과하기 때문입니다. 검색은 모델이 올바른 것을 보고 있을 때, 모델의 추론 능력을 더 좋게 만들어주지는 않습니다. 그저 모델이 애초에 올바른 것을 보고 있도록 보장할 뿐입니다.

이는 당연한 질문으로 이어집니다. 만약 모델이 이미 올바른 정보를 가지고 있다면 어떻게 될까요?

그것이 기본적으로 제 상황이었습니다. 전체 스크립트가 이미 그곳에 있었습니다. 제가 파헤쳐서 찾아내야 할 어딘가에 묻혀 있는 것은 아무것도 없었습니다. 찾을 것도 없었습니다. 그저 순서대로 처리해야 할 무언가가 있었을 뿐입니다.

하지만 긴 스크립트는 여전히 청킹 (Chunking)이 필요하지 않나요?

네, 맞습니다. 이 점 때문에 저도 잠시 혼란을 겪었기에 명확히 짚고 넘어갈 가치가 있습니다.

한 시간 분량의 강의 스크립트는 단 한 번의 모델 호출 (Model call)로 편하게 보내기에는 너무 깁니다. 따라서 어떻게든 나누어야 합니다. 그 부분은 피할 수 없습니다.

하지만 무언가를 청킹하는 데에는 두 가지 서로 다른 이유가 있으며, 저는 인지하지 못한 채 머릿속에서 이 둘을 하나로 뭉뚱그려 생각하고 있었습니다.

검색을 위한 청킹 (Chunking for retrieval)은 검색할 수 있도록 텍스트를 나눕니다. 각 청크는 임베딩 (Embedded)되어 쿼리 (Query)와 대조되어 점수가 매겨지며, 가장 잘 일치하는 것들만 사용됩니다.

컨텍스트를 위한 청킹 (Chunking for context)은 단순히 크기 제한 때문에 텍스트를 나눕니다. 모든 청크가 순서대로 사용되며, 아무것도 필터링되지 않습니다.

저에게 필요했던 것은 두 번째 방식이었습니다. "어느 조각이 가장 관련이 있는가"가 아니라, "여기 전체 내용이 조각나 있으니, 순서대로 전부 훑어봐라"가 필요했던 것입니다. 그것은 임베딩 (Embeddings)을 필요로 하지 않습니다. 그저 루프 (Loop)가 필요할 뿐입니다.

깨달음의 순간

머릿속에서 검색 (Retrieval)과 추론 (Reasoning)을 분리하고, 검색을 위한 청킹 (Chunking to search)과 적합성을 위한 청킹 (Chunking to fit)을 구분하고 나니, 상황이 매우 빠르게 명확해졌습니다.

저는 스스로에게 질문했습니다. 사람이 이 작업을 수행한다면 어떻게 할까? AI가 아니라, 강의를 보고 있는 실제 사람 말입니다.

사람들은 어떤 쿼리 (Query)와 가장 "유사한" 문단을 찾기 위해 훑어보지 않을 것입니다. 왜냐하면 쿼리가 없기 때문입니다. 아무도 질문을 던지지 않습니다. 그들은 그저 처음부터 끝까지 시청할 것이고, 강사가 하나의 아이디어를 마무리하고 다음 아이디어로 넘어가는 시점을 자연스럽게 알아차릴 것입니다.

그때 실제로 깨달음이 왔습니다. 챕터 생성 (Chapter generation)은 유사성 (Similarity)이 아니라 순서 (Sequence)에 관한 것입니다.

임베딩 (Embeddings)은 "이 더미의 어디에서 X와 유사한 것이 나타나는가?"라는 질문에 답합니다. 하지만 저의 문제는 "이 순서가 정해진 하나의 흐름이 어디서 변하는가?"였습니다. 이 둘은 옷만 바꿔 입은 같은 문제가 아닙니다. 이들은 진정으로 다른 문제이며, 그 어떤 영리한 검색용 청킹 (Chunking-for-retrieval) 기술로도 이를 해결할 수 없었습니다. 왜냐하면 검색 (Retrieval)은 애초에 수행해야 할 작업이 아니었기 때문입니다.

내가 필요하다고 생각했던 것

Transcript
   │
   ▼
...

내가 실제로 구축한 것

Transcript
   │
   ▼
...

입력은 동일하고 출력도 동일하지만, 파이프라인 (Pipeline)은 절반으로 줄었습니다.

내가 실제로 구축한 것

대략적인 워크플로 (Workflow)는 다음과 같습니다:

1. 비디오를 전사 (Transcribe)합니다.
2. 전사된 내용을 순서와 타임스탬프 (Timestamp)를 유지하면서 각각 몇 분 단위의 순차적인 청크 (Chunks)로 나눕니다.
3. 각 청크를 이전의 모든 내용을 담은 짧은 롤링 요약 (Rolling summary)과 함께 모델에 입력하고, 주제가 전환되는 지점을 표시하도록 요청합니다.
4. 서로 가까이 위치한 전환점들을 병합하고, 각 경계선을 가장 가까운 자연스러운 휴지기 (Natural pause)에 맞추어 챕터가 문장 중간에서 시작되지 않도록 합니다.

3단계가 정말 핵심적인 비결입니다. 각 청크 (Chunk)는 이전 청크들로부터 문맥 (Context)을 전달받습니다. 모델은 서로 어떻게 연결되는지 추측하려고 애쓰는 여섯 개의 단절된 파편들을 멍하니 바라보는 것이 아니라, 사람이 강의를 듣는 것처럼 맥락의 실타래를 따라가며 강의를 훑어 내려갑니다. 이러한 연속성 덕분에 모델은 실제로 "좋아, 여기서 주제가 바뀌었군"이라는 점을 인지할 수 있습니다. 이는 또한 유사도 검색 (Similarity search)이 버려버리는 요소이기도 합니다. 유사도 검색은 모든 청크를 점수를 매겨야 할 각각의 고립된 개체로 취급하기 때문입니다.

벡터 데이터베이스 (Vector database)도, 임베딩 (Embedding) 호출도, 검색 (Retrieval) 단계도 필요 없습니다.

내가 임베딩을 버린 진짜 이유

나는 이것을 비용이나 속도에 관한 이야기로 구성할 수도 있습니다. 움직이는 부품이 줄어들고, 지연 시간 (Latency)이 낮아지며, 벡터 DB 비용이 발생하지 않는다는 점 말입니다. 그것들은 실제적인 이점이었고 실제로 얻어낸 결과이기도 합니다. 하지만 그것이 내가 변화를 준 진짜 이유는 아니며, 그것을 앞세우는 것은 본질을 놓치는 일이 될 것입니다.

진짜 이유는 더 간단합니다. 임베딩은 나에게 존재하지도 않는 문제를 해결하려 했을 뿐입니다. 나의 병목 현상 (Bottleneck)은 결코 "이 전사 데이터 (Transcript)에서 관련 있는 부분을 어떻게 찾을 것인가"가 아니었습니다. 왜냐하면 전사 데이터 전체가 곧 관련 있는 부분이었기 때문입니다. 그 위에 검색 (Retrieval) 기능을 덧붙이는 것은 출력을 더 좋게 만드는 것이 아니라, 아무도 묻지 않는 질문에 답하기 위한 기계 장치만 추가하는 꼴이었으며, "주제가 바뀌는 지점이 어디인가"라는 실제 질문은 이전과 마찬가지로 해결되지 않은 상태로 남았을 것입니다.

비용과 지연 시간이 개선된 것은 불필요한 것을 제거함으로써 얻은 부수적인 효과였습니다. 그것들이 불필요했던 이유는 아니었습니다.

실제로 검색이 필요한 경우에는 여전히 임베딩이 훌륭합니다

이 모든 내용이 임베딩에 반대하는 논거는 아닙니다. 나는 여전히 다른 종류의 문제를 해결하기 위해 임베딩을 항상 사용합니다.

예를 들어, 10,000개의 도움말 문서 위에 고객 지원 봇을 구축한다고 가정해 봅시다. 누군가 질문을 했을 때 모델에게 10,000개의 문서를 한꺼번에 전달할 방법은 없으므로, 모델은 먼저 실제로 관련 있는 몇 개의 문서를 찾아내야 합니다. 그것이 바로 임베딩이 만들어진 목적 인 검색 (Retrieval) 문제이며, 그런 경우에는 벡터 데이터베이스를 사용하는 것이 매우 훌륭한 활용법입니다.

그것과 제 챕터 생성기(chapter generator)의 차이점은 포함된 텍스트의 양이 아닙니다. 둘 다 텍스트는 충분했습니다. 차이점은 모델이 수많은 별개의 항목들을 검색(search)해야 하는지, 아니면 이미 온전하게 가지고 있는 하나의 항목을 읽어야 하는지의 여부입니다.

검색(Retrieval)이 필요한 경우: 기업 문서, 대규모 지식 베이스 (knowledge bases), 연구 논문 라이브러리, 제품 매뉴얼, 지원 문서 컬렉션, 긴 채팅 기록 아카이브.

검색(Retrieval)이 필요하지 않은 경우: 단일 문서 요약, 텍스트 번역, 콘텐츠 분류, 하나의 파일에서 구조화된 데이터 추출, 단일 코드베이스 검토, 하나의 트랜스크립트(transcript)로부터 챕터 생성.

만약 모델이 필요한 모든 것을 이미 눈앞에 가지고 있다면, 임베딩 (embeddings)은 모델의 추론 (reasoning) 능력을 향상시키는 데 도움이 되지 않습니다. 찾아야 할 것이 없으므로, 검색 (retrieval)이 가속화할 것도 없습니다.

훔쳐갈 가치가 있는 질문

이제 저는 어떤 것에 벡터 데이터베이스 (vector database)를 추가하기 전에 스스로에게 한 가지 질문을 던집니다. 여러분이 아직 이 질문을 하지 않고 있다면, 훔쳐갈 가치가 있습니다.

내 AI가 정보를 찾아야 하는가, 아니면 이미 정보를 가지고 있는가?

만약 이미 모든 것을 가지고 있다면, 임베딩 (embeddings)은 답변을 더 날카롭게 만들어주지 못합니다. 그저 비용과 지연 시간 (latency)을 추가하고, 조용히 고장 날 수 있는 시스템을 하나 더 늘릴 뿐입니다.

마지막 생각

저는 검색할 것이 전혀 없는 문제에 대해, 단지 그것이 모두가 찾는 기본 동작이라는 이유만으로 전체 검색 파이프라인 (retrieval pipeline)을 구축할 뻔했습니다. 여기서 얻은 진짜 교훈은 임베딩 (embeddings) 자체에 관한 것이 아니었습니다. 그것은 제가 실제로 눈앞에 놓인 문제가 아니라, 튜토리얼에서 설명하는 문제를 해결하고 있는 자신을 발견하는 것에 관한 것이었습니다.

최고의 아키텍처 (architecture)는 가장 많은 부품을 가진 것이 아닙니다. 가장 적은 요소를 덧붙여서 실제 문제를 해결하는 아키텍처입니다.