AI 에이전트 개발 필수 용어 총정리 (4): 벡터 데이터베이스와 메모리 관리

Think harder. Think systematically.

[Context]
I am a new junior developer who has absolutely zero background in modern AI agent development and software infrastructure. I have recently joined a development team to build AI agents, but I find myself completely lost when my seniors use terms like 'Bun' or 'pi' as if they are common knowledge. I now need to master the essential vocabulary of AI agent development and its underlying infrastructure to build and manage agents effectively in a software development setting.

I have never studied, practiced, or even casually encountered modern runtimes, package managers, or agentic frameworks. My knowledge in this area is completely blank.

Therefore, do NOT skip over terms, actions, or concepts that a senior software engineer would consider so obvious they go without saying. The things that are "too basic to mention" are precisely what I need explained — the implicit, taken-for-granted knowledge that experts forget is not universal.

[Request]
Create an encyclopedia-level deep-dive terminology dictionary covering these sub-domains: JavaScript and TypeScript Runtimes, Package Managers and Dependency Management, Agentic Orchestration Frameworks, Vector Databases and Memory Management, Execution Environments and Sandboxing, API Integration and Tool Calling.

For each term, explain not just the definition but also: why the term exists (historical or practical origin), how it connects to neighboring concepts, common beginner mistakes or misconceptions, edge cases or exceptions that practitioners know from experience, and how the term is actually used in day-to-day work (not just textbook definitions).

[Output Constraints]

Output Language: ALL output MUST be written in Korean. English original terms should appear in parentheses where they aid understanding (e.g., 런타임(Runtime)).

Output Volume: Use your FULL output token capacity with ZERO abbreviation. Absolute maximum verbosity.

Output Format: Use long-form descriptive paragraphs, NOT short bullet points. No emojis.

Depth: Expand on every nuance, edge case, historical context, and common real-world mistake for each term.

If you reach the output limit, end with ">>> 여기서부터 이어서 작성 <<<" so the user can prompt you to continue.

4부: 벡터 데이터베이스와 메모리 관리 (Vector Databases & Memory Management)

벡터(Vector)와 임베딩(Embedding)

벡터(Vector)와 임베딩(Embedding)은 AI 에이전트의 메모리 시스템을 이해하기 위한 수학적·개념적 기반이다. 수학에서 벡터는 방향과 크기를 가진 양으로 정의되지만, AI/ML 맥락에서의 벡터는 단순히 숫자들의 순서 있는 배열(Ordered Array of Numbers)이다. 예를 들어 $[0.23, -0.87, 0.45, 0.11, ...]$처럼 수백 내지 수천 개의 부동소수점 숫자로 이루어진 배열이다. 이 숫자들의 배열이 텍스트, 이미지, 오디오 같은 비정형 데이터의 “의미(Semantic Meaning)”를 수학적으로 표현한다.

임베딩(Embedding)은 이러한 벡터 표현을 만들어내는 과정 혹은 그 결과물이다. 임베딩 모델(Embedding Model)은 텍스트를 입력받아 그 텍스트의 의미를 담은 벡터를 출력하는 신경망이다. 핵심적인 특성은, 의미가 비슷한 텍스트는 벡터 공간(Vector Space)에서 서로 가까이 위치한다는 것이다. 예를 들어 “왕”과 “여왕”의 임베딩 벡터는 “사과”와 “오렌지”의 임베딩 벡터보다 훨씬 가까이 위치한다. “고양이”와 “강아지”는 “자동차”보다 서로 가깝다. 이 성질 덕분에 사용자 질문과 의미적으로 유사한 문서 청크를 벡터 간의 거리를 계산하는 것만으로 찾아낼 수 있다. OpenAI의 text-embedding-3-small, Cohere의 embed-v3, 로컬에서 실행 가능한 nomic-embed-text 등이 대표적인 임베딩 모델이다.

초보 개발자들이 임베딩에 대해 가장 많이 오해하는 것은 “임베딩을 만든 모델이 다르면 서로 비교할 수 없다”는 사실을 모르는 것이다. 즉, OpenAI의 text-embedding-3-small로 생성한 벡터와 Cohere의 모델로 생성한 벡터를 서로 비교하는 것은 의미가 없다. 마치 서로 다른 언어로 번역된 문장을 글자 수로만 비교하는 것처럼 무의미하다. 따라서 문서를 인덱싱할 때 사용한 임베딩 모델과 쿼리할 때 사용하는 임베딩 모델은 반드시 동일해야 한다. 팀에서 임베딩 모델을 교체하면 전체 벡터 데이터베이스를 처음부터 다시 인덱싱해야 하는 비용이 발생한다.

코사인 유사도(Cosine Similarity)와 벡터 검색(Vector Search)

벡터 검색(Vector Search), 또는 시맨틱 검색(Semantic Search)은 키워드 기반의 전통적인 검색과 근본적으로 다른 방식으로 작동한다. 전통적인 키워드 검색은 “사용자가 입력한 단어가 문서에 포함되어 있는가?”를 기준으로 한다. 벡터 검색은 “사용자 질문의 의미(Semantic)가 문서의 내용과 얼마나 유사한가?”를 기준으로 한다. 예를 들어 “자동차 연료 절약 방법”을 검색하면, 키워드 검색은 “자동차”, “연료”, “절약”이라는 단어가 포함된 문서를 찾지만, 벡터 검색은 “연비를 높이는 운전 습관”, “기름값 아끼는 법” 같은 단어가 전혀 다르지만 의미가 같은 문서도 찾아낼 수 있다.

유사도를 측정하는 대표적인 수식이 코사인 유사도(Cosine Similarity)다. 두 벡터 사이의 각도(Angle)를 코사인 함수로 계산하여, 두 벡터가 같은 방향을 가리킬수록(각도가 작을수록) 코사인 값이 1에 가까워지고, 완전히 반대 방향이면 -1에 가까워진다. 벡터의 크기(Magnitude)와 상관없이 방향만을 비교하므로, 긴 문서와 짧은 문서를 비교해도 공정한 결과를 얻을 수 있다. 또 다른 유사도 측정 방법으로 유클리드 거리(Euclidean Distance, L2 Distance)와 내적(Dot Product)이 있으며, 사용하는 임베딩 모델과 데이터의 특성에 따라 최적의 방법이 다를 수 있다. 실무에서 OpenAI 임베딩 모델은 코사인 유사도 또는 내적을 권장하고, 두 값의 비교 결과가 실제로 거의 동일하게 나온다.

벡터 데이터베이스(Vector Database)

벡터 데이터베이스(Vector Database)는 벡터 임베딩을 효율적으로 저장하고, 고차원 벡터 공간에서 가장 가까운 이웃(Nearest Neighbor)을 빠르게 검색할 수 있도록 특화된 데이터베이스다. 일반적인 관계형 데이터베이스(RDBMS)인 MySQL이나 PostgreSQL에서는 수백만 개의 벡터를 저장할 수는 있지만, 각 쿼리마다 모든 벡터와 거리를 계산하는 브루트 포스(Brute Force) 방식으로는 실시간 검색이 불가능하다. 벡터 데이터베이스는 ANN(Approximate Nearest Neighbor) 알고리즘, 특히 HNSW(Hierarchical Navigable Small World) 같은 인덱싱 알고리즘을 사용하여 정확도와 속도 사이의 균형을 맞추며 수백만~수십억 개의 벡터도 밀리초(ms) 단위로 검색할 수 있게 한다.

Pinecone

Pinecone은 완전 관리형(Fully Managed) 서버리스 벡터 데이터베이스 서비스로, 설치나 운영이 필요 없이 API를 통해 바로 사용할 수 있는 클라우드 서비스다. Pinecone의 가장 큰 장점은 간단함과 확장성이다. 몇 줄의 코드로 인덱스(Index)를 생성하고, 벡터를 업서트(Upsert)하고, 쿼리하는 것이 가능하다. 수십억 개의 벡터도 자동 확장(Auto-scaling)하여 처리하므로, 인프라 관리에 시간을 쓰지 않고 싶은 팀에 적합하다.6

Pinecone에서 알아야 할 핵심 개념은 인덱스(Index), 네임스페이스(Namespace), 메타데이터 필터링(Metadata Filtering)이다. 인덱스는 벡터들을 저장하는 최상위 컨테이너다. 네임스페이스는 하나의 인덱스 안에서 벡터를 논리적으로 분리하는 파티션이다. 예를 들어 멀티 테넌트(Multi-tenant) 에이전트 시스템에서 고객 A의 데이터와 고객 B의 데이터를 같은 인덱스 안에 두되, 서로 다른 네임스페이스로 격리할 수 있다. 메타데이터 필터링은 벡터 검색 결과를 추가 조건으로 필터링하는 기능이다. 예를 들어 벡터 유사도 상위 100개를 찾은 다음, 그 중에서 “날짜 >= 2025-01-01”인 것만 반환하는 방식으로 검색 정밀도를 높일 수 있다.7

초보 개발자들이 Pinecone을 사용할 때 가장 많이 저지르는 실수 중 하나는 인덱스를 생성할 때 차원 수(Dimension)를 잘못 설정하는 것이다. Pinecone 인덱스를 생성할 때 반드시 사용하려는 임베딩 모델의 출력 차원 수와 동일하게 설정해야 한다. 예를 들어 OpenAI의 text-embedding-3-small 모델은 기본적으로 1536차원의 벡터를 출력한다. 인덱스를 1536 차원으로 설정하지 않으면 업서트 시 오류가 발생하거나, 차원이 다른 벡터들이 혼재하여 검색 품질이 떨어진다. 또한 Pinecone의 스타터(Starter) 플랜에서는 인덱스 수와 벡터 수에 제한이 있으므로, 테스트 중에 무분별하게 인덱스를 생성하면 한도에 도달하는 경우가 있다.

Weaviate

Weaviate는 오픈소스 벡터 데이터베이스로, 자체 호스팅(Self-hosting)이 가능하면서도 클라우드 관리형 버전도 제공한다. Pinecone과 비교했을 때 Weaviate의 강점은 두 가지다. 첫째, 하이브리드 검색(Hybrid Search) 기능이다. Weaviate는 벡터 유사도 기반의 시맨틱 검색과 BM25 알고리즘 기반의 키워드 검색을 동시에 수행하고 결과를 융합(Fusion)하는 하이브리드 검색을 기본으로 지원한다. 이는 순수한 벡터 검색만으로 성능이 부족한 경우, 예를 들어 제품 코드나 고유명사처럼 정확한 키워드 매칭이 중요한 경우에 효과적이다. 둘째, 제너레이티브 모듈(Generative Module) 통합으로, Weaviate 내부에서 직접 검색 결과를 LLM에 전달하고 응답을 생성하는 RAG 파이프라인을 데이터베이스 쿼리 레벨에서 수행할 수 있다.89

Weaviate의 데이터 모델은 클래스(Class)와 오브젝트(Object) 개념을 사용한다. 관계형 데이터베이스의 테이블과 행에 해당하는 개념이라고 이해할 수 있다. 각 클래스는 프로퍼티(Property)와 벡터라이저(Vectorizer) 설정을 가지며, 데이터를 업로드하면 자동으로 임베딩을 생성하고 저장하는 설정도 지원한다. 초보 개발자들이 Weaviate에서 흔히 혼란스러워하는 것은 스키마(Schema) 관리다. Weaviate는 데이터 구조(스키마)를 미리 정의해야 하므로, 스키마 변경이 필요할 때 기존 데이터를 마이그레이션하는 과정이 복잡할 수 있다. 최근 버전에서는 자동 스키마 감지 기능을 통해 이 부담을 일부 줄였다.

ChromaDB (Chroma)

ChromaDB(이하 Chroma)는 2022년 오픈소스로 공개된 임베딩 데이터베이스로, 초보 개발자들에게 가장 진입 장벽이 낮은 벡터 데이터베이스다. Chroma의 가장 큰 특징은 파이썬 패키지 하나를 설치하면 추가 설정 없이 인메모리(In-memory, 메모리 내) 또는 로컬 파일 시스템에 데이터를 저장할 수 있다는 것이다. 서버를 별도로 실행하거나 클라우드 계정을 만들 필요가 없어, 로컬 개발 환경이나 프로토타이핑(Prototyping)에 매우 적합하다.10

Chroma의 데이터 모델은 컬렉션(Collection)이라는 개념을 중심으로 한다. 컬렉션은 관련 임베딩들의 그룹이다. 각 임베딩은 ID, 임베딩 벡터, 메타데이터(딕셔너리), 원본 텍스트 문서를 함께 저장할 수 있다. 쿼리할 때는 query_texts로 원본 텍스트를 직접 전달하면 Chroma가 내장 임베딩 함수를 사용해 자동으로 벡터화하고 검색하는 방식을 지원한다. LangChain, LlamaIndex 등 대부분의 에이전트 프레임워크에서 Chroma를 기본 벡터 스토어로 예제 코드에 사용하기 때문에, AI 에이전트를 처음 배울 때 자연스럽게 가장 먼저 접하게 되는 벡터 데이터베이스다.11

Chroma의 단점은 확장성(Scalability)이다. 수백만 개 이상의 벡터를 다루거나 고가용성(High Availability, HA)이 필요한 프로덕션 환경에서는 Pinecone이나 Weaviate 같은 프로덕션 그레이드 솔루션으로 이전이 필요하다. 실무에서 흔히 발생하는 패턴은 개발/테스트 환경에서 Chroma를 쓰다가 프로덕션 배포 시 다른 벡터 데이터베이스로 교체하는 것인데, LangChain 같은 프레임워크는 이 전환을 벡터스토어 인터페이스의 일관성 덕분에 상대적으로 쉽게 만든다.

pgvector

pgvector는 기존의 PostgreSQL 관계형 데이터베이스에 벡터 검색 기능을 추가하는 확장(Extension)이다. 많은 AI 에이전트 팀이 이미 PostgreSQL을 운영하고 있는 상황에서, 별도의 벡터 데이터베이스를 새로 도입하는 대신 기존 데이터베이스에 pgvector 확장 하나만 설치하여 벡터 검색 기능을 사용한다. 이는 인프라 복잡성을 낮추고 기존의 PostgreSQL 생태계, 즉 트랜잭션(Transaction), 조인(JOIN), 롤백(Rollback) 등을 그대로 활용할 수 있다는 장점이 있다.

pgvector의 실무적 장점은 관계형 데이터와 벡터 데이터를 하나의 쿼리 안에서 결합할 수 있다는 것이다. 예를 들어 “userId = 123인 사용자의 문서 중에서 현재 질문과 가장 유사한 상위 5개를 찾아라”라는 조건을 SQL 한 줄로 표현할 수 있다. 순수한 벡터 데이터베이스에서는 이런 복합 조건을 처리하려면 메타데이터 필터링이나 별도의 로직이 필요하지만, pgvector에서는 기존 SQL의 WHERE 조건을 그대로 활용한다. 단점은 데이터 양이 수십만 개를 넘어가면 인덱싱 성능이 전용 벡터 데이터베이스에 비해 떨어질 수 있다는 것으로, 실무에서는 약 100만 벡터 이하의 규모에서 pgvector가 합리적인 선택이며 그 이상이면 전용 벡터 데이터베이스를 고려한다.

에이전트 메모리 유형 (Agent Memory Types)

AI 에이전트의 메모리는 인간의 기억 구조와 유사하게 여러 종류로 나뉘며, 각각 다른 방식으로 관리된다. 에이전트 메모리를 이해하는 것은 에이전트가 왜 이전 대화를 기억하지 못하거나, 왜 느려지거나, 왜 엉뚱한 맥락을 가져오는지 디버깅하는 데 필수적이다.

인컨텍스트 메모리(In-Context Memory), 또는 단기 메모리(Short-term Memory)는 LLM의 컨텍스트 윈도우(Context Window) 안에 직접 포함되는 정보다. 대화 기록(Chat History)이 대표적인 예다. 이 메모리는 빠르고 즉각적이지만, 컨텍스트 윈도우의 한계(예: 128K 토큰) 때문에 대화가 길어지면 오래된 내용이 잘려 나간다. 외부 메모리(External Memory)는 벡터 데이터베이스나 일반 데이터베이스에 저장된 정보로, RAG를 통해 필요할 때 검색하여 컨텍스트에 추가한다. 장기 기억에 해당하며 이론적으로 무한히 확장 가능하다. 에피소드 메모리(Episodic Memory)는 과거 대화나 작업의 구체적 사례를 저장하여, 유사한 상황에서 참고하는 방식이다. 시맨틱 메모리(Semantic Memory)는 사실(Fact)이나 개념에 대한 구조화된 지식을 저장한다. 절차적 메모리(Procedural Memory)는 어떻게 행동해야 하는가에 대한 지식으로, LLM 자체의 파라미터나 시스템 프롬프트에 내재된 지식이 여기에 해당한다.

컨텍스트 윈도우(Context Window)는 LLM이 한 번에 처리할 수 있는 최대 텍스트 길이를 토큰(Token) 단위로 나타낸다. 토큰은 언어 모델이 텍스트를 처리하는 최소 단위로, 대략 영어 기준 0.75단어, 한국어 기준 0.5~1글자에 해당한다. GPT-4o는 128K 토큰, Claude 3.7 Sonnet은 200K 토큰의 컨텍스트 윈도우를 제공한다. 실무에서 컨텍스트 윈도우는 곧 비용과 속도에 직결된다. 컨텍스트에 넣는 내용이 많을수록 API 호출 비용이 증가하고 응답 시간이 늘어난다. RAG의 핵심 가치 중 하나는 전체 지식베이스를 컨텍스트에 넣는 것이 아니라 관련 부분만 선택적으로 넣어 컨텍스트 사용을 최적화하는 것이다.

청킹(Chunking)

청킹(Chunking)은 RAG 파이프라인에서 문서를 임베딩하기 전에 적절한 크기의 조각으로 분할하는 전처리 과정이다. 왜 통째로 저장하지 않고 청크로 나누는가? 두 가지 이유가 있다. 첫째, 임베딩 모델은 입력 텍스트의 최대 길이 제한이 있다. 예를 들어 OpenAI의 임베딩 모델은 최대 8191 토큰까지만 처리한다. 10만 토큰짜리 책을 통째로 임베딩하면 자를 수밖에 없다. 둘째, 너무 긴 텍스트를 하나의 벡터로 표현하면 세부 의미가 희석되어 검색 정밀도가 떨어진다. 반대로 너무 짧으면 컨텍스트가 부족하여 의미를 제대로 담지 못한다.

실무에서 청킹 전략은 RAG 시스템의 성능을 좌우하는 매우 중요한 설계 결정이다. 고정 크기 청킹(Fixed-size Chunking)은 문자 수나 토큰 수를 기준으로 균일하게 분할하는 가장 단순한 방법이지만, 의미 있는 경계(예: 문단, 절)에서 잘리지 않을 수 있다. 재귀적 문자 분할(Recursive Character Text Splitter)은 단락 → 문장 → 단어 순서로 재귀적으로 분할하되 지정한 크기를 초과하지 않도록 하는 방식으로 LangChain에서 가장 널리 사용된다. 오버랩(Overlap)은 연속된 청크가 일부 내용을 공유하도록 설정하는 것인데, 예를 들어 200 토큰 크기의 청크에 50 토큰의 오버랩을 주면 청크 경계에서 문맥이 잘리는 문제를 완화할 수 있다.