*이 장을 다 읽고 나면 알게 될 것: 기업용 Agent의 기술 스택이 개인용과 어떻게 다른지, 모델·도구·메모리·오케스트레이션 네 개의 레이어가 왜 필요한지, 인프라와 개발 환경을 어떻게 설계하는지, 그리고 '교체 가능성'이라는 원칙이 왜 모든 선택을 관통하는지*
도입: 서버실에서 보낸 설날
2025년 설 연휴였다. 대부분의 사람들이 가족과 떡국을 먹고 있을 때, 나는 나의 시스템의 RunPod 인스턴스 앞에 앉아 있었다. Qwen3-32B 모델이 자꾸 메모리를 초과해서 죽었다. VRAM 24GB짜리 GPU로는 부족했다. 48GB로 올리면 비용이 두 배가 된다. 모델을 양자화하면 비용은 줄지만 품질이 떨어진다. 트레이드오프. 어디서나 만나는 그것이다.
그 새벽에 깨달은 것이 있다. 10장에서 개인용 Agent의 기술 스택을 다뤘다. 개인용은 비교적 단순했다. LangGraph 하나, pgvector 하나, 오픈 LLM 하나. 세 개면 출발할 수 있었다. 그러나 기업용은 달랐다. 기업용 Agent의 기술 스택은 개인용의 확장이 아니다. 구조 자체가 다르다.
개인용은 한 사람이 산다. 실패해도 나만 불편하다. 기업용은 수백 명이 동시에 쓴다. 사내 시스템과 연결되어야 한다. 보안 규정을 지켜야 한다. 장애가 나면 업무가 멈춘다. 그래서 레이어가 늘어나고, 실수의 비용이 커진다.
이 장에서는 기업용 Agent의 기술 스택을 네 개의 레이어로 나누어 본다. 그리고 그 위에 인프라, 개발 환경, 모니터링이라는 세 개의 기반을 깐다. 마지막으로 모든 선택을 관통하는 설계 원칙 세 가지를 제시한다.
23.1 네 개의 레이어 — 기술 스택의 전체 그림
기업용 Agent의 기술 스택을 처음 그릴 때, 나는 건물에 비유했다.
1층은 모델 레이어다. LLM이 산다. 건물의 두뇌에 해당한다.
2층은 도구 연결 레이어다. 외부 시스템과 연결된다. 건물의 문과 창문이다.
3층은 메모리 레이어다. 대화와 지식을 저장한다. 건물의 서재이자 창고다.
4층은 오케스트레이션 레이어다. 전체 흐름을 제어한다. 건물의 관리인이다.
그리고 이 건물이 서 있는 땅이 인프라다. 건물을 짓고 고치는 도구가 개발 환경이다. 건물의 상태를 감시하는 CCTV가 모니터링이다.
이 구조가 중요한 이유는 간단하다. 레이어를 분리해야 교체가 가능하다. GPT-4를 쓰다가 Claude로 바꿔야 할 때, 모델 레이어만 교체하면 된다. 도구 레이어와 메모리 레이어는 그대로 둘 수 있다. 레이어가 엉켜 있으면 하나를 바꿀 때 전부 다시 짜야 한다. 그러면 죽는다. 기업 시스템은 그렇게 죽어왔다. ERP 시대에도, 클라우드 시대에도, 그리고 AI 시대에도.
잠시 멈추고 생각해보자
당신의 조직이 현재 쓰고 있는 AI 도구들은 레이어가 분리되어 있는가? 모델을 바꾸면 나머지도 다 바꿔야 하는 구조인가?
23.2 모델 선택 레이어 — 하나로는 부족하다
모델 레이어에서 가장 흔한 실수는 하나의 모델에 올인하는 것이다.
2024년에는 GPT-4가 거의 유일한 선택지처럼 보였다. 2025년에는 상황이 달라졌다. Claude가 코드 생성과 긴 문서 처리에서 강점을 보인다. Qwen3가 비용 대비 성능에서 놀라운 결과를 낸다. Llama 4가 오픈소스 진영의 대표 주자로 자리 잡았다. 각각이 잘하는 영역이 다르다.
기업용 Agent는 멀티 모델이 기본이다. 이유는 세 가지다.
첫째, 과제별 최적 모델이 다르다. 요약은 Claude가 잘한다. 구조화된 데이터 추출은 GPT-4가 잘한다. 한국어 처리는 Qwen3가 비용 효율적이다. 코드 생성은 Claude나 GPT-4 모두 강하다. 하나의 모델로 모든 과제를 처리하면 어딘가에서 반드시 품질이 떨어진다.
둘째, 비용 구조가 다르다. GPT-4의 토큰 비용과 Qwen3-32B를 자체 호스팅할 때의 비용은 열 배 이상 차이가 난다. 단순한 분류 작업에 GPT-4를 쓸 이유가 없다. 작은 모델로 충분한 일은 작은 모델에 맡기고, 큰 모델은 정말 필요한 곳에만 쓴다. 이것을 모델 라우팅(model routing)이라고 한다.
셋째, 종속 위험이 있다. 하나의 API 제공자에 의존하면, 그 제공자가 가격을 올리거나 정책을 바꿀 때 대안이 없다. 2024년 한 해 동안 OpenAI의 API 가격 정책이 세 번 바뀌었다. 기업은 그런 변동에 취약하면 안 된다.
그래서 실무에서는 이런 구조가 된다.
모델 라우터
├── 복잡한 추론 → Claude Opus / GPT-4
├── 일반 생성 → Claude Sonnet / GPT-4o
├── 단순 분류·추출 → Qwen3-32B (자체 호스팅)
├── 임베딩 → text-embedding-3-large 또는 BGE-M3
└── 코드 생성 → Claude Sonnet / GPT-4o
그 다음 문제는 온프레미스 vs 클라우드다. 이것은 기술 문제가 아니라 정책 문제다.
금융, 의료, 국방 분야는 데이터가 외부로 나가면 안 된다. 이 경우 오픈소스 모델을 자체 서버에서 돌려야 한다. Qwen3, Llama 4가 그 선택지다. 자체 호스팅의 비용은 높지만, 데이터 주권의 가치는 더 높다. 16장에서 다룬 하이브리드 전략이 여기서 구체화된다.
반대로 스타트업이나 일반 기업은 API가 합리적이다. 관리 부담이 적고, 최신 모델을 즉시 쓸 수 있다. 다만 API 키 관리와 비용 모니터링은 필수다.
잠시 멈추고 생각해보자
당신의 조직에서 가장 빈번한 AI 과제 세 가지를 떠올려보라. 그 세 가지가 같은 모델로 최적 처리되는가, 다른 모델이 필요한가?
23.3 도구 연결 레이어 — Agent가 세상과 만나는 곳
모델이 두뇌라면, 도구는 손과 발이다. Agent가 실제로 일을 하려면 외부 시스템과 연결되어야 한다.
기업 환경에서 Agent가 연결해야 할 시스템을 나열하면 이렇다. ERP, CRM, 이메일 서버, 문서 관리 시스템, 데이터베이스, 웹 검색, 사내 위키, 슬랙이나 Teams. 목록이 길다. 그리고 각각의 연결 방식이 다르다. REST API, GraphQL, SOAP, JDBC, 웹소켓, FTP. 카오스다.
이 카오스를 정리하는 방법이 API Gateway다. Agent가 직접 각 시스템에 접속하지 않는다. Gateway를 통해 접속한다. Gateway가 인증, 속도 제한, 로깅, 에러 처리를 대신한다.
2025년에 등장한 중요한 표준이 하나 있다. MCP, Model Context Protocol이다. 앤트로픽이 제안한 이 프로토콜은 LLM과 외부 도구 사이의 연결을 표준화한다. 쉽게 말하면 이렇다. USB가 나오기 전에는 프린터마다, 키보드마다, 마우스마다 연결 규격이 달랐다. USB가 하나의 표준으로 통일했다. MCP는 AI 도구 연결의 USB를 목표로 한다.
MCP의 구조는 단순하다. 서버가 도구를 제공하고, 클라이언트가 그 도구를 호출한다. 서버는 자기가 제공하는 도구의 목록과 스키마를 공개한다. 클라이언트는 그 스키마를 읽고, 필요한 도구를 호출한다. JSON-RPC 기반이라 언어에 구애받지 않는다.
# MCP 서버 예시 — 사내 문서 검색 도구
from mcp.server import MCPServer, tool
server = MCPServer("internal-docs")
@tool(description="사내 문서를 검색합니다")
async def search_docs(query: str, department: str = "all") -> list[dict]:
# 사내 문서 검색 로직
results = await doc_store.search(query, department)
return [{"title": r.title, "snippet": r.snippet} for r in results]
server.run()
이것이 왜 중요한가. MCP가 확산되면 도구 연결의 비용이 급격히 줄어든다. 도구 제공자가 MCP 서버를 만들고, Agent 개발자는 그것을 플러그인처럼 꽂기만 하면 된다. 2025년 하반기 기준으로 Claude, Cursor, Windsurf 등이 이미 MCP를 지원한다. 생태계가 빠르게 확장 중이다.
다만 MCP는 아직 초기 단계다. 기업 환경에서는 MCP 위에 자체 인증·인가 레이어를 얹어야 한다. 표준이 편리함을 주지만, 보안까지 공짜로 주지는 않는다.
잠시 멈추고 생각해보자
당신의 조직에서 AI Agent가 접근해야 할 사내 시스템은 몇 개인가? 그 시스템들의 API는 표준화되어 있는가, 각각 다른가?
23.4 메모리 레이어 — 세 개의 기억이 필요하다
Agent에게 메모리가 없으면 금붕어와 같다. 매번 처음부터 시작한다.
기업용 Agent의 메모리는 세 겹이다.
첫째, 단기 메모리. 현재 대화의 맥락이다. 사용자가 "아까 말한 그 보고서"라고 하면, 아까 무슨 보고서를 말했는지 기억해야 한다. 이것은 대화 히스토리를 세션 안에 유지하는 것으로 해결된다. 기술적으로는 인메모리 캐시나 Redis를 쓴다. 가장 단순한 레이어다.
둘째, 장기 메모리. 과거의 문서, 지식, 학습 결과를 저장한다. 핵심 기술은 벡터 데이터베이스다. 문서를 임베딩 벡터로 변환해 저장하고, 의미 기반으로 검색한다. 이것이 RAG(Retrieval-Augmented Generation)의 기반이다.
벡터 데이터베이스의 선택지는 많다. pgvector, Pinecone, Weaviate, Milvus, Qdrant, Chroma. 나의 시스템에서는 pgvector를 주력으로 쓴다. 이미 PostgreSQL을 쓰고 있으면 확장 하나만 추가하면 된다. 운영 부담이 적다. 벡터 수가 천만 개 이하라면 성능도 충분하다. 억 단위를 넘기면 Pinecone이나 Milvus 같은 전문 벡터 DB가 필요하다.
셋째, 관계 메모리. 가장 많이 간과되는 레이어다. 벡터 DB는 유사한 것을 찾는 데 강하다. 그러나 "A는 B의 공급업체이고, B는 C의 고객이며, C는 A의 경쟁사다"라는 관계는 표현하지 못한다. 이것은 그래프 데이터베이스의 영역이다.
18장에서 다룬 Composite AI Framework의 핵심 요소 중 하나가 바로 이 그래프 메모리다. 나의 시스템에서는 ArangoDB를 쓴다. ArangoDB는 문서 DB, 키-값 DB, 그래프 DB를 하나로 합친 멀티모델 데이터베이스다. 하나의 시스템으로 세 가지 역할을 한다. 운영할 DB 수가 줄어든다. 작은 팀에게는 이것이 결정적이다.
세 메모리를 합치면 이런 그림이 된다.
메모리 레이어
├── 단기: Redis / 인메모리 (현재 대화)
├── 장기: pgvector / Pinecone (문서·지식 검색)
└── 관계: ArangoDB / Neo4j (엔티티 간 관계)
이 세 메모리가 협력해야 Agent가 풍부한 답을 낼 수 있다. 사용자가 "삼성전자의 주요 공급업체 중 최근 리스크가 있는 곳을 찾아줘"라고 하면, 그래프 DB에서 공급 관계를 찾고, 벡터 DB에서 최근 뉴스를 검색하고, 두 결과를 합쳐서 답한다. 이것이 21장에서 다룬 GraphRAG의 실전 적용이다.
23.5 오케스트레이션 레이어 — 누가 지휘하는가
레이어의 꼭대기에 오케스트레이션이 앉는다. 모델을 호출하고, 도구를 쓰고, 메모리를 읽고 쓰는 전체 흐름을 제어하는 레이어다. 20장에서 다룬 9-node GoT 아키텍처가 바로 이 레이어 위에서 작동한다.
2025년 현재, 주요 오케스트레이션 프레임워크는 세 가지다.
LangGraph. LangChain 팀이 만들었다. 상태 그래프 기반이다. 분기, 순환, 조건부 라우팅이 자유롭다. 10장에서 이미 다뤘다. 나의 시스템의 주력 도구다. 강점은 유연성이다. 약점은 학습 곡선이 있다는 것이다. 그래프를 설계하려면 상태 머신에 대한 이해가 필요하다.
CrewAI. 역할 기반 접근이다. Agent에게 "당신은 리서처입니다", "당신은 편집자입니다" 같은 역할을 부여하고, 그 역할에 맞게 협업하게 한다. 직관적이다. 코드량이 적다. 빠르게 프로토타입을 만들 수 있다. 약점은 복잡한 흐름 제어가 어렵다는 것이다. 단순한 순차 실행은 잘 되지만, 조건 분기나 순환 루프는 제한적이다.
AutoGen. 마이크로소프트가 만들었다. 멀티 Agent 대화 기반이다. 여러 Agent가 서로 대화하면서 문제를 푼다. 연구 프로젝트에 강하다. 약점은 대화가 발산할 수 있다는 것이다. 제어하지 않으면 Agent들이 끝없이 대화만 한다.
세 프레임워크를 비교하면 이렇다.
| 기준 | LangGraph | CrewAI | AutoGen |
|---|---|---|---|
| 흐름 제어 | 상태 그래프 (가장 유연) | 역할 기반 순차 | 대화 기반 |
| 학습 곡선 | 중간~높음 | 낮음 | 중간 |
| 복잡한 분기 | 강함 | 제한적 | 중간 |
| 운영 안정성 | 높음 | 중간 | 낮음~중간 |
내 선택은 LangGraph다. 이유는 하나다. 운영 환경에서 예측 가능해야 한다. CrewAI는 프로토타입에 좋다. AutoGen은 실험에 좋다. 그러나 매일 수백 건의 요청을 처리하는 운영 시스템에서는, 흐름이 정확히 제어되어야 한다.
다만 이것은 2025년 현재의 판단이다. 이 분야는 빠르게 변한다. 그래서 오케스트레이션 레이어도 교체 가능하게 설계해야 한다. 비즈니스 로직을 프레임워크에 깊이 결합하면 안 된다.
잠시 멈추고 생각해보자
당신이 만들려는 Agent는 단순한 순차 실행으로 충분한가, 분기와 순환이 필요한가? 그 판단이 프레임워크 선택을 결정한다.
23.6 인프라와 개발 환경 — 땅과 도구
건물을 다 설계했으면, 이제 땅과 도구를 정해야 한다.
인프라 선택지는 크게 네 가지다.
RunPod. GPU 클라우드다. 오픈소스 모델을 자체 호스팅할 때 쓴다. 나의 시스템에서는 Qwen3 모델을 RunPod에서 돌린다. 가격이 합리적이고 GPU 선택지가 다양하다. 단점은 스케일링을 직접 해야 한다는 것이다.
AWS SageMaker / Azure ML / GCP Vertex AI. 3대 클라우드의 AI 플랫폼이다. 각각 자기 생태계와 강하게 연동된다. Azure는 OpenAI 모델, GCP는 Gemini, AWS는 Bedrock을 통한 멀티 모델 접근이 장점이다.
어떤 것을 고를 것인가. 정답은 없다. 이미 쓰고 있는 클라우드를 따라가는 것이 가장 합리적이다. 두 개의 클라우드를 동시에 관리하는 부담은 크다. 예외는 자체 호스팅이 필요한 경우다. 특정 오픈소스 모델을 써야 한다면 RunPod이나 자체 GPU 서버가 옵션이 된다.
개발 환경은 세 가지가 기본이다.
Docker. 컨테이너다. "내 컴퓨터에서는 되는데 서버에서는 안 돼요"라는 고전적 문제를 해결한다. Docker 없이 AI 시스템을 배포하는 것은 상상하기 어렵다.
Kubernetes. 컨테이너 오케스트레이션이다. 수십 개의 컨테이너를 자동으로 관리한다. 다만 작은 팀에게는 과할 수 있다. Docker Compose로 시작하고, 규모가 커지면 Kubernetes로 넘어가는 것이 현실적이다.
CI/CD. 코드를 고치면 자동으로 테스트하고 배포한다. GitHub Actions, GitLab CI가 대표적이다. Agent 시스템에서 CI/CD가 특히 중요한 이유가 있다. 프롬프트도 코드다. 버전 관리되어야 하고, 테스트를 거쳐야 하고, 롤백이 가능해야 한다.
23.7 모니터링 — 보이지 않으면 고칠 수 없다
Agent 시스템의 모니터링은 전통적 소프트웨어와 다르다. 전통적 소프트웨어는 에러가 나면 로그에 에러가 찍힌다. 명확하다. Agent는 다르다. 에러 없이 작동하지만 답이 틀릴 수 있다. 환각이다. HTTP 200 OK를 반환하면서 거짓말을 한다. 이것을 잡으려면 특별한 모니터링이 필요하다.
LangSmith. LangChain 팀이 만든 모니터링 도구다. LangGraph와 자연스럽게 연동된다. 각 노드의 입력과 출력, 모델 호출의 프롬프트와 응답, 토큰 사용량, 지연 시간을 추적한다. 디버깅에 강하다. 유료다.
LangFuse. 오픈소스 대안이다. 자체 서버에 설치할 수 있다. LangSmith와 기능이 비슷하지만, 데이터가 자기 서버에 남는다. 데이터 주권이 중요한 기업에 적합하다.
자체 로깅. 위 도구에 의존하지 않고, 자체 로깅 파이프라인을 만드는 것이다. MLflow를 쓰면 모델 실험 추적, 프롬프트 버전 관리, 성능 메트릭 기록이 가능하다. 나의 시스템에서는 MLflow를 기반으로 자체 모니터링 시스템을 운영한다. LangSmith도 병행하지만, 핵심 메트릭은 MLflow에 쌓는다. 이유는 간단하다. 외부 서비스에 의존하면, 그 서비스가 바뀔 때 데이터를 잃는다.
모니터링에서 추적해야 할 핵심 지표는 다섯 가지다.
1. 응답 품질. 답이 맞는가. 사용자 피드백, 자동 평가(LLM-as-judge), 인간 평가를 결합한다.
2. 지연 시간. 요청에서 응답까지 몇 초 걸리는가. 각 노드별 지연을 분해해야 병목을 찾을 수 있다.
3. 비용. 토큰 사용량 × 단가. 모델별, 과제별로 추적해야 최적화 지점이 보인다.
4. 에러율. API 타임아웃, 모델 거부, 도구 실패 등.
5. 사용 패턴. 어떤 과제가 많은지, 어떤 시간대에 집중되는지. 이것이 스케일링 계획의 기초가 된다.
잠시 멈추고 생각해보자
당신의 조직에서 AI 시스템의 "답이 맞는지"를 어떻게 확인하고 있는가? 확인하는 체계가 없다면, 그것은 시스템이 아니라 도박이다.
23.8 환경 설계 세 원칙 — 교체 가능성, 관찰 가능성, 점진적 확장
지금까지 많은 기술 이름이 나왔다. 선택지가 넘친다. 이 혼란 속에서 길을 잃지 않기 위한 원칙이 세 가지 있다. 나의 시스템의 시스템을 세 차례 갈아엎은 끝에 도달한 원칙이다.
첫째, 교체 가능성(Replaceability). 모든 구성 요소는 교체 가능해야 한다. 모델이 바뀔 수 있다. 벡터 DB가 바뀔 수 있다. 오케스트레이션 프레임워크도 바뀔 수 있다. AI 분야는 6개월이면 판도가 바뀐다. 2024년 초에 최선이었던 선택이 2025년에는 차선이 된다. 교체가 어려우면 진화가 멈춘다.
구체적으로는 추상화 레이어를 둔다. 비즈니스 로직이 특정 모델이나 특정 DB의 API를 직접 호출하지 않는다. 중간에 인터페이스를 둔다. 모델을 바꿀 때 인터페이스 뒤의 구현만 바꾸면 된다. 소프트웨어 엔지니어링의 기본이지만, AI 프로젝트에서는 놀라울 정도로 많이 무시된다.
둘째, 관찰 가능성(Observability). 시스템 안에서 무슨 일이 일어나는지 볼 수 있어야 한다. Agent가 왜 그런 답을 했는지, 어떤 문서를 참조했는지, 어떤 노드에서 얼마나 시간이 걸렸는지를 추적할 수 있어야 한다. 볼 수 없으면 고칠 수 없다. 고칠 수 없으면 개선할 수 없다.
셋째, 점진적 확장(Incremental Scaling). 처음부터 대규모로 설계하지 않는다. 작게 시작하고, 필요할 때 키운다. 모델 하나로 시작해서 멀티 모델로 간다. pgvector로 시작해서 필요하면 Milvus로 간다. Docker Compose로 시작해서 필요하면 Kubernetes로 간다.
이것은 단순한 검소함이 아니다. 실전의 지혜다. 처음부터 Kubernetes를 깔고, Milvus 클러스터를 구축하면 어떻게 되는가. 시스템은 멋있지만 정작 Agent의 핵심 기능 개발이 늦어진다. 나도 그 실수를 했다. 그래서 안다.
23.9 나의 시스템의 실제 환경 — 이론에서 현실로
마지막으로, 나의 시스템의 실제 기술 스택을 공개한다. 이것이 정답이라는 뜻이 아니다. 하나의 작동하는 예시라는 뜻이다.
[나의 시스템 기술 스택 — 2025년 기준]
모델 레이어
├── 주력 추론: Claude Sonnet (API)
├── 복잡한 분석: Claude Opus / GPT-4 (API)
├── 한국어 처리 + 비용 절감: Qwen3-32B (RunPod 자체 호스팅)
├── 임베딩: text-embedding-3-large (API)
└── 모델 라우팅: 과제 유형별 자동 분기
도구 연결 레이어
├── 웹 검색: Tavily API
├── 문서 처리: Unstructured.io
├── 사내 데이터: PostgreSQL 직접 연결
└── 외부 도구: MCP 서버 (점진 확대 중)
메모리 레이어
├── 단기: LangGraph 내장 상태 + Redis
├── 장기: pgvector (PostgreSQL 확장)
└── 관계: ArangoDB (GraphRAG)
오케스트레이션
└── LangGraph (9-node GoT 아키텍처)
인프라
├── 모델 호스팅: RunPod (GPU), API (Claude/OpenAI)
├── 애플리케이션: Docker Compose
├── DB: PostgreSQL + ArangoDB
└── 실험 추적: MLflow
모니터링
├── LLM 추적: LangSmith + 자체 로깅
├── 실험 관리: MLflow
└── 인프라 모니터링: Grafana + Prometheus
이 스택이 완성되기까지 1년이 걸렸다. 세 번 갈아엎었다. LangChain에서 LangGraph로, Chroma에서 pgvector로, 모니터링 없음에서 MLflow로. 매번 아팠지만 매번 나아졌다.
기술 스택은 한 번에 정하는 것이 아니다. 운영하면서 진화하는 것이다. 그래서 교체 가능성이 첫 번째 원칙이다.
핵심 정리
기업용 Agent의 기술 스택은 네 개의 레이어로 구성된다. 모델 레이어(LLM 선택과 라우팅), 도구 연결 레이어(API Gateway, MCP), 메모리 레이어(단기·장기·관계), 오케스트레이션 레이어(LangGraph, CrewAI, AutoGen). 이 네 레이어가 분리되어야 각각을 독립적으로 교체할 수 있다.
모델은 하나로 충분하지 않다. 멀티 모델 라우팅이 기업 환경의 기본이다. MCP는 도구 연결의 새로운 표준이다. 메모리는 단기·장기·관계 세 겹이 필요하다.
인프라는 Docker와 CI/CD가 기본이다. 모니터링은 관찰 가능성이 핵심이다. 환경 설계의 세 원칙은 교체 가능성, 관찰 가능성, 점진적 확장이다. 처음부터 완벽한 스택은 없다. 운영하면서 진화한다.
반드시 답해봐야 할 질문 5가지
질문 1. 당신의 조직에서 AI 모델을 바꿔야 할 상황이 발생하면, 현재 구조에서 얼마나 빨리 교체할 수 있는가? 일주일인가, 한 달인가, 불가능한가?
질문 2. 모델 라우팅을 도입한다면, 당신의 업무 중 비싼 모델이 반드시 필요한 과제와 작은 모델로 충분한 과제를 구분해보라. 비용이 얼마나 줄어들 것 같은가?
질문 3. 당신의 조직이 보유한 지식 중, 벡터 검색으로 찾을 수 있는 것과 그래프 관계로만 찾을 수 있는 것을 각각 예시를 들어보라.
질문 4. MCP가 보편화되면 당신의 조직에서 가장 먼저 연결하고 싶은 사내 시스템 세 가지는 무엇인가?
질문 5. 점진적 확장의 원칙을 따른다면, 당신의 Agent 프로젝트에서 모델 하나, 도구 하나, 메모리 하나로 만들 수 있는 가장 단순한 버전은 어떤 모습인가?
더 깊이 탐구하기
LangGraph 공식 문서 (https://langchain-ai.github.io/langgraph/). 상태 그래프 설계와 체크포인터 설정의 상세 가이드.
Anthropic, "Model Context Protocol Specification" (2025). MCP의 설계 철학과 기술 스펙. 도구 연결 표준화의 방향을 이해하는 데 필수적이다.
pgvector 공식 문서 (https://github.com/pgvector/pgvector). PostgreSQL 확장으로서의 벡터 검색 설정과 성능 튜닝.
ArangoDB, "Multi-Model Database for AI Applications" 백서 (2025). 문서·그래프·키값을 하나로 합친 아키텍처의 장점과 GraphRAG 적용 사례.
Chip Huyen, 「AI Engineering」 (2025). AI 시스템의 기술 스택 설계와 모니터링에 대한 실무적 관점.
다음 장에서는 이 기술 스택을 가지고 실제 프로젝트를 시작하는 방법을 다룬다. PoC에서 운영까지, 구현 로드맵의 현실적인 단계를 밟아본다.