*이 장을 다 읽고 나면 알게 될 것: AI Agent를 만드는 기술 스택이 무엇으로 구성되는지, 왜 특정 도구를 선택하고 다른 도구를 버리는지, 그리고 초보자가 어디서부터 시작해야 하는지*
도입: 2024년 11월, 새벽 세 시의 선택
2024년 11월, 새벽 세 시였다. 나는 나의 시스템의 첫 번째 Agent 시스템을 설계하고 있었다.
화면에는 스프레드시트가 하나 떠 있었다. 왼쪽 열에는 기술 이름이 빼곡했다. LangChain, LangGraph, CrewAI, AutoGen, Semantic Kernel. 오른쪽 열에는 벡터 데이터베이스가 줄지어 있었다. Pinecone, Weaviate, Milvus, Chroma, pgvector. 그 아래에는 LLM 목록이 있었다. GPT-4, Claude, Llama, Mistral, Qwen. 선택지가 너무 많았다.
금융·제조 산업에서 데이터 분석 기반 컨설팅과 AI/ML 솔루션 사업을 하면서 수백 개의 기업에 기술 선택을 조언했다. ERP를 SAP로 할지 Oracle로 할지, 클라우드를 AWS로 할지 Azure로 할지. 그런 선택을 도왔다. 그런데 정작 내 시스템의 기술 스택을 고르는 일은 달랐다. 남의 일은 쉽다. 내 일은 어렵다.
새벽 네 시쯤 깨달은 것이 있다. 기술 스택의 선택은 기술의 선택이 아니다. 세계관의 선택이다. 폐쇄형 API에 의존할 것인가, 오픈소스로 자유를 확보할 것인가. 관리형 서비스에 돈을 낼 것인가, 직접 인프라를 구축할 것인가. 빠르게 시작할 것인가, 단단하게 시작할 것인가. 이 질문들은 기술 질문이 아니다. 철학 질문이다.
그날 새벽, 나는 선택했다. 그리고 그 선택의 결과로 만들어진 것이 지금의 나의 시스템 시스템이다. 이 장에서는 그 선택의 과정과 이유를 공유한다.
기술 스택이라는 말이 어렵게 들릴 수 있다. 쉽게 말하면 이렇다. 집을 짓는다고 하자. 기초는 콘크리트로 할지 철골로 할지, 벽은 벽돌로 할지 목재로 할지, 지붕은 기와로 할지 슬레이트로 할지를 정하는 것이다. 각 선택은 독립적으로 보이지만, 실제로는 서로 영향을 준다. 철골 기초 위에 한옥 지붕을 얹기는 어렵다. 기술도 마찬가지다. 하나를 고르면 다른 선택지가 좁아진다. 그래서 처음이 중요하다.
이 장에서는 개인 Agent를 만들기 위한 기술 스택을 하나씩 본다. 각 기술이 무엇인지, 왜 그것을 선택하는지, 대안은 무엇인지를 본다. 그리고 마지막에 전체 그림을 그린다.
10.1 LangGraph — 왜 LangGraph인가
Agent 시스템의 뇌에 해당하는 것이 오케스트레이션 프레임워크다. Agent가 어떤 순서로 생각하고, 판단하고, 행동할지를 정하는 뼈대다.
2024년 초까지만 해도 대부분의 사람들은 LangChain을 썼다. LangChain은 LLM 애플리케이션을 만드는 가장 유명한 프레임워크였다. 프롬프트를 연결하고, 도구를 호출하고, 결과를 정리하는 파이프라인을 쉽게 만들 수 있었다. 좋았다. 처음에는.
문제는 복잡해질 때 나타났다. LangChain은 기본적으로 체인(chain) 구조다. A → B → C처럼 순서대로 흐른다. 단순한 작업에는 충분하다. 그러나 실제 Agent는 단순하지 않다. 판단에 따라 분기해야 한다. 실패하면 되돌아가야 한다. 여러 작업을 동시에 돌려야 한다. 중간 상태를 기억해야 한다. 체인 구조로는 이것이 어렵다.
LangGraph는 이 문제를 풀기 위해 태어났다. LangChain을 만든 같은 팀(LangChain Inc.)이 만들었다. 핵심 아이디어는 단순하다. Agent의 작동을 상태 그래프(state graph)로 표현하는 것이다.
그래프에는 노드(node)와 엣지(edge)가 있다. 노드는 하나의 작업 단위다. "사용자 질문을 분석한다", "외부 데이터를 검색한다", "답변을 생성한다" 같은 것이 각각 하나의 노드다. 엣지는 노드 사이의 이동 경로다. 조건에 따라 다른 노드로 갈 수 있다. 이것이 핵심이다.
간단한 예를 보자. 사용자가 질문을 한다. Agent는 먼저 질문의 종류를 판단한다. 단순한 질문이면 바로 답한다. 복잡한 질문이면 외부 데이터를 검색한 후 답한다. 검색 결과가 불충분하면 다시 검색한다. 이 흐름을 LangGraph로 표현하면 이렇다.
from langgraph.graph import StateGraph, END
from typing import TypedDict
class AgentState(TypedDict):
question: str
context: str
answer: str
need_search: bool
def classify(state: AgentState) -> AgentState:
# 질문 분류: 단순한가, 검색이 필요한가
...
return {**state, "need_search": True}
def search(state: AgentState) -> AgentState:
# 외부 데이터 검색
...
return {**state, "context": "검색 결과"}
def generate(state: AgentState) -> AgentState:
# 답변 생성
...
return {**state, "answer": "생성된 답변"}
graph = StateGraph(AgentState)
graph.add_node("classify", classify)
graph.add_node("search", search)
graph.add_node("generate", generate)
graph.set_entry_point("classify")
graph.add_conditional_edges("classify",
lambda s: "search" if s["need_search"] else "generate")
graph.add_edge("search", "generate")
graph.add_edge("generate", END)
app = graph.compile()
이 코드가 하는 일은 명확하다. 상태(state)를 정의하고, 노드를 만들고, 노드 사이의 이동 규칙을 정한다. 조건부 분기가 자연스럽다. 상태가 노드 사이를 흘러다닌다. 이것이 LangGraph의 핵심이다.
LangGraph가 LangChain보다 나은 점은 세 가지다.
첫째, 분기와 루프가 자유롭다. 체인은 일직선이다. 그래프는 갈림길이 있고, 되돌아가는 길도 있다. 실제 Agent의 사고 과정에 더 가깝다.
둘째, 상태 관리가 명시적이다. 현재 Agent가 무엇을 알고 있는지, 어디까지 진행했는지가 상태 객체에 담겨 있다. 디버깅이 쉽다. 무엇이 잘못되었는지 추적할 수 있다.
셋째, 인간의 개입이 가능하다. 특정 노드에서 멈추고 사람의 확인을 받은 후 진행하는 구조를 만들 수 있다. 자율성과 통제의 균형을 잡을 수 있다.
물론 대안도 있다. Microsoft의 AutoGen, CrewAI, 또는 직접 만든 프레임워크를 쓰는 사람도 있다. 각각 장단점이 있다. 그러나 2025년 현재, LangGraph는 가장 활발한 커뮤니티, 가장 많은 예제, 가장 빠른 업데이트를 가지고 있다. 실전에서 선택할 때 이 세 가지는 기술 사양 못지않게 중요하다.
잠시 멈추고 생각해보자
당신이 쓰는 도구(엑셀, 노션, 파워포인트 등)를 선택한 이유는 무엇이었는가? 기능 때문이었는가, 아니면 주변 사람들이 쓰기 때문이었는가? 기술 스택 선택에서 커뮤니티의 크기는 어디까지 고려해야 하는가?
10.2 pgvector — 왜 전용 벡터 DB가 아닌가
Agent가 똑똑하려면 기억이 필요하다. 그리고 AI 시대의 기억은 벡터(vector)로 저장된다.
벡터가 무엇인가. 쉽게 말하면 숫자 목록이다. "서울의 가을 날씨"라는 문장을 AI 모델에 넣으면, [0.23, -0.47, 0.81, ...] 같은 수백 개의 숫자로 변환된다. 이 숫자 목록이 그 문장의 의미를 담고 있다. 비슷한 의미의 문장은 비슷한 숫자 패턴을 가진다. 그래서 벡터끼리 비교하면 의미가 비슷한 것을 찾을 수 있다. 이것이 의미 검색(semantic search)의 원리다. RAG(검색 증강 생성) — 사용자의 질문에 답하기 전에 외부 지식을 먼저 검색해서 LLM에 제공하는 기법이다 — 의 핵심이기도 하다.
이 벡터를 저장하고 검색하는 전용 데이터베이스가 벡터 DB다. Pinecone, Weaviate, Milvus, Chroma, Qdrant. 전용 벡터 DB는 많다. 각각 성능이 좋다. 그런데 나는 pgvector를 선택했다.
pgvector는 전용 벡터 DB가 아니다. PostgreSQL의 확장(extension)이다. PostgreSQL은 40년 역사를 가진 관계형 데이터베이스다. 세상에서 가장 안정적인 데이터베이스 중 하나다. pgvector는 이 PostgreSQL에 벡터 저장과 검색 기능을 추가한 것이다.
왜 전용 벡터 DB 대신 pgvector인가. 이유는 세 가지다.
첫째, 운영 복잡성의 문제다. 전용 벡터 DB를 쓰면 시스템에 데이터베이스가 두 개가 된다. 일반 데이터는 PostgreSQL에, 벡터 데이터는 Pinecone에. 두 곳의 데이터를 동기화해야 한다. 백업도 두 번 해야 한다. 장애 대응도 두 곳에서 해야 한다. 큰 회사에서는 감당할 수 있다. 개인이나 작은 팀에게는 부담이다.
둘째, 조인(join)의 문제다. 실제 Agent를 만들면 벡터 검색 결과에 메타데이터를 붙여야 하는 경우가 많다. "이 문서는 언제 작성되었는가", "이 정보의 출처는 어디인가", "이 사용자의 선호도는 무엇인가". 이런 정보는 관계형 테이블에 있다. pgvector를 쓰면 벡터 검색과 메타데이터 조회를 하나의 SQL 쿼리로 할 수 있다. 전용 벡터 DB에서는 두 시스템을 오가야 한다.
셋째, 비용의 문제다. Pinecone 같은 관리형 서비스는 월 사용료가 있다. 데이터가 늘면 비용도 는다. pgvector는 PostgreSQL만 돌리면 된다. 클라우드에서 PostgreSQL 인스턴스 하나면 충분하다. 또는 자기 서버에서 돌릴 수도 있다.
물론 단점도 있다. 벡터가 수억 개 이상이면 전용 벡터 DB의 검색 속도가 더 빠르다. 분산 처리가 필요한 대규모 시스템에서는 전용 솔루션이 유리하다. 그러나 개인 Agent나 중소 규모 시스템에서 벡터가 수억 개일 일은 거의 없다. 수만에서 수십만 개면 pgvector로 충분하다.
정리하면 이렇다. 대규모 플랫폼을 만든다면 전용 벡터 DB가 맞다. 개인 Agent나 중소 시스템을 만든다면 pgvector가 현명한 선택이다. 하나의 데이터베이스로 모든 것을 처리할 수 있다는 것은 작은 팀에게 큰 힘이다.
잠시 멈추고 생각해보자
"하나로 통합한다"와 "전문 도구를 각각 쓴다" 사이의 판단 기준은 무엇인가? 당신의 프로젝트에서 벡터 데이터는 얼마나 될 것으로 예상하는가? 그 규모에서 운영 복잡성과 검색 성능 중 무엇이 더 중요한가?
10.3 오픈 LLM — 자유의 가격
기술 스택에서 가장 큰 선택은 LLM이다. Agent의 두뇌를 무엇으로 할 것인가.
2024년까지만 해도 선택은 단순했다. OpenAI의 GPT-4가 압도적이었다. 앤트로픽(Anthropic)의 Claude가 그 다음이었다. 가장 좋은 모델을 API로 호출하면 됐다. 간단했다.
그런데 2025년, 상황이 바뀌었다. 오픈소스 LLM의 성능이 폐쇄형 모델을 따라잡기 시작한 것이다.
중국 알리바바의 Qwen3, 메타의 Llama 3, 프랑스 미스트랄(Mistral)의 모델들. 이 오픈 LLM들은 무료로 공개되어 있다. 누구나 다운로드해서 자기 서버에서 돌릴 수 있다. 성능은 GPT-4의 약 90% 수준에 도달했다. 특정 작업에서는 100%를 넘기기도 한다.
그래서 선택지가 생겼다. 폐쇄형 API를 쓸 것인가, 오픈 LLM을 자체 운영할 것인가.
폐쇄형 API의 장점은 명확하다. 설치할 것이 없다. API 키 하나면 된다. 항상 최신 모델을 쓸 수 있다. 인프라 걱정이 없다. 시작이 빠르다.
단점도 명확하다. 데이터가 외부로 나간다. 사용자의 질문, 문서, 개인 정보가 OpenAI나 앤트로픽의 서버로 전송된다. 대부분의 회사는 데이터를 로깅하지 않겠다고 약속한다. 그러나 약속과 기술적 보장은 다르다. 금융 데이터, 의료 데이터, 기업 기밀을 다루는 Agent에서는 이것이 큰 문제가 된다.
또 하나의 단점은 비용의 예측 불가능성이다. API 호출 건당 과금이다. 사용량이 늘면 비용이 기하급수적으로 늘 수 있다. 그리고 가격 정책은 제공자가 언제든 바꿀 수 있다.
오픈 LLM의 장점은 이 단점의 반대다. 데이터가 내 서버 안에 머문다. 비용은 GPU 서버 비용으로 고정된다. 모델을 내 필요에 맞게 파인튜닝할 수도 있다. 완전한 통제권이 내 손에 있다.
단점은 운영의 부담이다. GPU 서버를 구축하거나 임대해야 한다. 모델을 배포하고 관리해야 한다. 업데이트도 직접 해야 한다. 기술적 역량이 필요하다.
나는 나의 시스템에서 둘 다 쓴다. 핵심은 이렇다. 프로토타입과 빠른 실험에는 폐쇄형 API를 쓴다. 안정적인 운영과 민감한 데이터 처리에는 오픈 LLM을 쓴다. 특히 Qwen3 시리즈를 주력으로 쓰고 있다. 한국어와 영어 모두에서 안정적인 성능을 보여주기 때문이다.
이 "둘 다 쓴다"는 전략이 현실적이다. 처음부터 오픈 LLM만 고집하면 시작이 느려진다. 처음부터 API만 쓰면 나중에 종속된다. 시작은 API로, 성장은 오픈 LLM으로. 이것이 내가 추천하는 경로다.
10.4 RunPod와 GPU 서버 — 자체 추론 인프라
오픈 LLM을 쓰기로 했다면, 그것을 어디서 돌릴 것인가의 문제가 생긴다.
LLM은 GPU가 필요하다. 그것도 꽤 좋은 GPU가. Qwen3-32B 모델을 돌리려면 NVIDIA A100 80GB 또는 그에 준하는 GPU가 필요하다. 이런 GPU를 사는 것은 비현실적이다. A100 한 장이 약 1,500만 원 이상이다.
그래서 GPU 클라우드 서비스가 등장했다. AWS, GCP, Azure 같은 대형 클라우드에서도 GPU 인스턴스를 제공한다. 그러나 비싸다. 시간당 수천 원에서 수만 원이다.
RunPod는 이 시장의 대안이다. GPU 클라우드 서비스인데, 대형 클라우드보다 저렴하다. 온디맨드(on-demand)와 스팟(spot) 인스턴스를 모두 제공한다. 스팟 인스턴스는 남는 GPU를 저렴하게 빌려주는 것이다. 가격이 절반 이하로 떨어진다. 중단될 수 있다는 위험이 있지만, 실험이나 배치 작업에는 충분하다.
나의 시스템에서는 RunPod를 주로 쓴다. 이유는 세 가지다. 비용이 합리적이다. 설정이 간단하다. Docker 컨테이너로 바로 올릴 수 있다. 그리고 커뮤니티가 활발하다.
다만 GPU 서버 운영이 모든 사람에게 필요한 것은 아니다. 개인 프로젝트라면 처음에는 OpenAI API나 Together AI, Groq 같은 서비스로 시작하는 것이 맞다. 자체 GPU 서버는 사용량이 일정 수준을 넘거나, 데이터 보안이 필수일 때 검토하면 된다.
잠시 멈추고 생각해보자
당신의 Agent가 다룰 데이터는 외부 서버로 보내도 되는 데이터인가? 그 답에 따라 기술 스택의 방향이 크게 달라진다. 비용과 보안 사이에서 당신은 어디에 서겠는가?
10.5 MLflow — 실험을 기억하는 시스템
Agent를 만드는 과정은 실험의 연속이다.
프롬프트를 바꿔본다. 모델을 바꿔본다. 검색 전략을 바꿔본다. 파라미터를 조정한다. 매번 결과가 달라진다. 그런데 일주일 전에 어떤 설정으로 어떤 결과를 얻었는지 기억나지 않는다. 엑셀에 기록하다가 세 번째 실험부터 기록을 깜빡한다. 이것은 나만의 문제가 아니다. 모든 개발자가 겪는 문제다.
MLflow는 이 문제를 푸는 도구다. 머신러닝 실험의 추적과 관리를 위한 오픈소스 플랫폼이다. 원래 데이터브릭스(Databricks)가 만들었고, 지금은 사실상 업계 표준이 되었다.
MLflow가 하는 일은 단순하다. 실험을 돌릴 때마다 설정(어떤 모델, 어떤 프롬프트, 어떤 파라미터)과 결과(정확도, 응답 시간, 비용)를 자동으로 기록한다. 웹 대시보드에서 실험들을 비교할 수 있다. "지난주 GPT-4로 돌린 것과 이번 주 Qwen3로 돌린 것 중 어느 것이 나았는가"를 한눈에 볼 수 있다.
Agent 개발에서 MLflow가 특히 유용한 이유가 있다. Agent는 여러 단계를 거치기 때문이다. 검색 단계의 품질, 생성 단계의 품질, 전체 파이프라인의 품질을 각각 추적해야 한다. MLflow의 실험 추적 기능이 이 복합적 평가를 체계적으로 만들어준다.
솔직히 말하면, MLflow 없이도 Agent를 만들 수 있다. 처음에는 없어도 된다. 그러나 실험이 열 번을 넘어가면 후회한다. 그때 도입하면 이미 기록이 없는 열 번의 실험을 잃은 것이다. 그래서 나는 처음부터 넣는 것을 권한다. 설치도 간단하다. `pip install mlflow` 한 줄이면 된다.
10.6 ArangoDB — 그래프의 힘, GraphRAG
여기서 한 걸음 더 들어간다. 고급 주제다. 그러나 Agent의 수준을 한 단계 올리는 핵심이다.
앞서 pgvector로 벡터 검색을 한다고 했다. 벡터 검색은 의미가 비슷한 문서를 찾아준다. 좋다. 그러나 한계가 있다. 벡터 검색은 관계를 모른다.
예를 들어보자. "삼성전자의 반도체 매출에 영향을 주는 요인은 무엇인가?"라는 질문을 Agent에게 던진다. 벡터 검색으로 관련 문서를 찾으면, 삼성전자에 대한 문서, 반도체 매출에 대한 문서가 나올 것이다. 그러나 "삼성전자 → HBM 생산 → SK하이닉스와 경쟁 → NVIDIA의 수요 → AI 데이터센터 투자"라는 관계의 사슬은 벡터 검색만으로는 잡기 어렵다.
그래프 데이터베이스는 이 관계를 저장하고 탐색하는 도구다. 노드(개체)와 엣지(관계)로 지식을 표현한다. "삼성전자"라는 노드, "HBM"이라는 노드, 둘 사이에 "생산한다"라는 엣지. 이런 식으로 지식의 그물망을 만든다.
ArangoDB는 문서 DB, 키-밸류 DB, 그래프 DB를 하나로 합친 멀티모델 데이터베이스다. 하나의 시스템에서 일반 데이터도 저장하고, 그래프도 저장하고, 검색도 할 수 있다. 앞서 pgvector를 고른 이유와 비슷하다. 여러 시스템을 운영하는 것보다 하나로 통합하는 것이 작은 팀에게는 유리하다.
GraphRAG는 이 그래프 DB를 RAG에 결합한 것이다. 벡터 검색으로 관련 문서를 찾고, 그래프 탐색으로 관계의 맥락을 추가한다. 두 가지를 합치면 Agent의 답변 품질이 눈에 띄게 올라간다.
나의 시스템에서 만든 시스템 중 하나인 SAF(Stock Analysis Framework)가 이 구조를 쓴다. 기업 정보를 그래프로 연결하고, 산업 가치사슬의 관계를 따라 분석한다. 벡터 검색만 썼을 때보다 분석의 깊이가 달랐다. 관계를 아는 Agent와 모르는 Agent는 같은 질문에 다른 수준의 답을 내놓는다.
다만 분명히 해둔다. GraphRAG는 고급 기술이다. 처음 Agent를 만드는 사람에게는 필요 없다. 벡터 검색만으로도 충분히 좋은 Agent를 만들 수 있다. GraphRAG는 시스템이 성숙하고, 다루는 지식이 복잡해질 때 도입하면 된다.
잠시 멈추고 생각해보자
당신이 Agent에게 답하게 하고 싶은 질문 세 가지를 떠올려보라. 그 질문 중에서 단순한 의미 검색으로 답할 수 있는 것은 무엇이고, 관계의 탐색이 필요한 것은 무엇인가?
10.7 전체 기술 스택 구성도
지금까지 본 기술들을 하나의 그림으로 정리하면 이렇다.
┌─────────────────────────────────────────────────┐
│ 사용자 인터페이스 │
│ (웹 앱, 챗봇, API, 모바일 앱) │
└──────────────────────┬──────────────────────────┘
│
┌──────────────────────▼──────────────────────────┐
│ 오케스트레이션 레이어 │
│ LangGraph │
│ (상태 그래프 기반 Agent 워크플로우) │
└──────┬──────────────┬──────────────┬────────────┘
│ │ │
┌──────▼─────┐ ┌──────▼─────┐ ┌─────▼──────────┐
│ LLM 레이어 │ │ 검색 레이어 │ │ 실험/관리 레이어 │
│ │ │ │ │ │
│ · Qwen3 │ │ · pgvector │ │ · MLflow │
│ · Llama │ │ (벡터) │ │ (실험 추적) │
│ · GPT-4 │ │ · ArangoDB │ │ │
│ · Claude │ │ (그래프) │ │ │
└──────┬─────┘ └──────┬─────┘ └───────────────┘
│ │
┌──────▼──────────────▼──────────────────────────┐
│ 인프라 레이어 │
│ │
│ · RunPod / GPU 서버 (오픈 LLM 추론) │
│ · PostgreSQL (관계형 데이터 + pgvector) │
│ · Docker / Docker Compose (컨테이너 관리) │
└─────────────────────────────────────────────────┘
이 구성의 특징을 정리하면 이렇다.
LangGraph가 중심이다. 모든 흐름이 LangGraph를 통해 조율된다. LLM을 호출하고, 검색을 하고, 결과를 조합하는 모든 과정이 상태 그래프 안에서 이루어진다.
LLM은 교체 가능하다. Qwen3를 쓰다가 Llama로 바꿀 수 있다. 실험 단계에서는 GPT-4를 쓰고 운영에서는 오픈 LLM을 쓸 수 있다. LangGraph가 중간에서 추상화해주기 때문이다.
데이터는 PostgreSQL에 모인다. 일반 데이터, 벡터 데이터, 사용자 정보가 모두 한 곳에 있다. 운영이 단순해진다.
그래프는 선택이다. ArangoDB와 GraphRAG는 필요할 때 추가한다. 처음에는 없어도 된다.
10.8 Closed vs Open — 두 세계의 Trade-off
마지막으로 가장 큰 그림을 본다. 폐쇄형 기술 스택과 개방형 기술 스택의 비교다.
폐쇄형 스택이란 이런 것이다. OpenAI API + Pinecone + Vercel. 모두 관리형 서비스다. 설치할 것이 거의 없다. 시작이 빠르다. 운영 부담이 적다. 그러나 데이터가 외부에 있고, 비용이 사용량에 비례하고, 제공자의 정책 변경에 종속된다.
개방형 스택이란 내가 선택한 것이다. LangGraph + pgvector + Qwen3 + RunPod. 모두 오픈소스이거나 자체 운영 가능한 것이다. 설정이 필요하다. 시작이 느리다. 운영 부담이 있다. 그러나 데이터가 내 안에 있고, 비용이 예측 가능하고, 완전한 통제권이 내 손에 있다.
어느 쪽이 옳은가. 정답은 없다. 상황에 따라 다르다.
빠르게 프로토타입을 만들고 시장 반응을 보고 싶다면, 폐쇄형이 낫다. 몇 시간 만에 작동하는 Agent를 만들 수 있다.
데이터 주권이 중요하거나, 장기적으로 비용을 통제하고 싶다면, 개방형이 낫다. 초기 투자가 크지만 장기적으로 자유롭다.
가장 현실적인 답은 혼합이다. 시작은 폐쇄형으로. 검증이 끝나면 핵심 부분을 개방형으로 전환한다. 나의 시스템도 이 경로를 따랐다. 처음에는 GPT-4 API로 빠르게 프로토타입을 만들었다. 작동하는 것을 확인한 후, 핵심 추론 엔진을 Qwen3로 전환했다. 벡터 DB도 처음에는 Chroma를 썼다가 pgvector로 옮겼다. 이런 점진적 전환이 가장 안전하다.
한 가지 더 말하고 싶은 것이 있다. 기술 스택 선택에서 가장 위험한 태도는 완벽한 스택을 찾으려는 것이다. 완벽한 스택은 없다. 모든 선택에는 트레이드오프가 있다. 중요한 것은 자기 상황에 맞는 트레이드오프를 의식적으로 선택하는 것이다. 그리고 나중에 바꿀 수 있는 구조로 만드는 것이다.
잠시 멈추고 생각해보자
당신이 지금 당장 Agent를 만든다면, 폐쇄형과 개방형 중 어디서 시작하겠는가? 6개월 후에는? 그 차이는 어디서 오는가—기술 역량인가, 데이터의 민감도인가, 예산인가?
10.9 초보자를 위한 시작 가이드
이 장을 읽으면서 압도당한 사람이 있을 것이다. LangGraph, pgvector, Qwen3, RunPod, MLflow, ArangoDB. 너무 많다.
솔직히 말하겠다. 처음에는 이것들이 다 필요 없다.
처음 Agent를 만드는 사람에게 내가 추천하는 최소 스택은 이렇다.
최소 시작 스택:
1. OpenAI API (또는 Anthropic API) — LLM
2. LangGraph — 오케스트레이션
3. Chroma (로컬 벡터 DB) — 간단한 RAG
4. Python + FastAPI — 서버
이 네 가지면 작동하는 Agent를 만들 수 있다. GPU 서버 없이, 복잡한 인프라 없이, API 키와 노트북 한 대로 시작할 수 있다.
다음 단계는 이렇다. Agent가 작동하는 것을 확인한 후, 필요에 따라 확장한다.
확장 경로:
1단계: OpenAI API + LangGraph + Chroma (빠른 시작)
↓
2단계: + pgvector (Chroma → PostgreSQL 전환)
↓
3단계: + MLflow (실험 추적 추가)
↓
4단계: + 오픈 LLM + RunPod (자체 추론 인프라)
↓
5단계: + ArangoDB + GraphRAG (고급 검색)
각 단계는 이전 단계가 안정적으로 작동한 후에 진행하면 된다. 한 번에 다 하려고 하면 아무것도 완성하지 못한다. 이것은 기술만의 문제가 아니다. 모든 프로젝트에 해당하는 원칙이다.
수없이 본 패턴이 있다. 기업이 새 시스템을 도입할 때, 처음부터 최고 사양으로 시작하는 곳은 거의 다 실패한다. 작게 시작해서 점진적으로 키우는 곳이 성공한다. Agent도 마찬가지다. 작게 시작하라. 작동하는 것을 확인하라. 그 다음에 키우라.
다음 장에서 우리는 이 기술 스택을 가지고 실제로 첫 번째 Agent를 만든다.
핵심 정리
기술 스택의 선택은 기술의 선택이 아니라 세계관의 선택이다. 폐쇄형과 개방형, 관리형과 자체 운영, 빠른 시작과 단단한 시작 사이에서 자기 상황에 맞는 트레이드오프를 의식적으로 고르는 것이 핵심이다.
LangGraph는 Agent의 오케스트레이션 프레임워크다. 상태 그래프 기반으로 분기, 루프, 인간 개입이 가능하다. LangChain의 체인 구조를 넘어선다.
pgvector는 PostgreSQL에 벡터 검색을 추가한 확장이다. 전용 벡터 DB 대신 하나의 데이터베이스로 모든 것을 처리할 수 있다. 개인과 중소 규모 시스템에 적합하다.
오픈 LLM(Qwen3, Llama, Mistral)은 데이터 주권과 비용 통제를 위한 선택이다. 폐쇄형 API와 혼합하여 쓰는 것이 현실적이다.
MLflow는 실험을 기억하는 시스템이다. ArangoDB와 GraphRAG는 관계 기반 지식 검색을 가능하게 한다. 둘 다 처음에는 필요 없지만, 시스템이 성숙하면 큰 차이를 만든다.
초보자는 OpenAI API + LangGraph + Chroma로 시작하면 된다. 작게 시작해서 점진적으로 키우는 것이 가장 안전한 경로다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신이 만들려는 Agent는 어떤 데이터를 다루는가? 그 데이터는 외부 클라우드로 보내도 되는 것인가? 이 답이 기술 스택의 방향을 결정한다.
질문 2. 폐쇄형 API의 가장 큰 위험은 무엇이라고 생각하는가? 가격 변동인가, 데이터 유출인가, 서비스 중단인가, 기능 제한인가? 당신에게 가장 치명적인 위험은 무엇인가?
질문 3. LangGraph의 상태 그래프 개념을 자기 언어로 설명할 수 있는가? 노드와 엣지로 자기 업무 프로세스를 그려본다면 어떤 모양이 되겠는가?
질문 4. 벡터 검색만으로 해결할 수 없는 질문을 세 개 떠올려보라. 그 질문들에는 어떤 공통점이 있는가? 그래프 검색이 왜 필요한지를 그 질문에서 발견할 수 있는가?
질문 5. 당신의 현재 기술 수준에서 최소 시작 스택(OpenAI API + LangGraph + Chroma)으로 시작할 수 있는가? 없다면 무엇이 부족한가? 그 부족한 것을 채우는 데 얼마나 걸리겠는가?
더 깊이 탐구하기
LangGraph 공식 문서 (https://langchain-ai.github.io/langgraph/). 상태 그래프의 개념과 다양한 패턴을 단계별로 설명한다. 튜토리얼부터 시작하는 것을 권한다.
pgvector GitHub 저장소와 PostgreSQL 공식 문서. pgvector의 설치, 인덱싱, 성능 튜닝에 대한 실무 가이드가 있다.
Chip Huyen, 「AI Engineering」 (2025). AI 시스템의 기술 스택 선택에 대한 가장 체계적인 안내서. 특히 LLM 운영과 평가에 대한 장이 유용하다.
ArangoDB 공식 문서의 GraphRAG 가이드. 그래프 데이터베이스와 RAG를 결합하는 구체적인 방법을 다룬다.
MLflow 공식 문서의 LLM 추적 기능 가이드 (2025). Agent 실험을 체계적으로 추적하는 방법을 실무 중심으로 설명한다.
다음 장에서는 이 기술 스택을 가지고 실제로 첫 번째 Agent를 만든다. 코드를 쓰고, 실행하고, 결과를 본다. 기술의 이름을 아는 것과 직접 만드는 것은 다른 차원의 경험이다. 손이 기억하는 것은 머리가 잊지 않는다.