AI 에이전트를 실제로 배포하는 데 필요한 것

모두가 에이전트를 만들고 있습니다. 그중 절반은 작동하고 있고, 나머지 절반은 '활성 계획'을 가지고 있습니다.

저도 두 진영에 모두 있었습니다. 차이점은 모델이 아닙니다. 모델들은 이미 한동안 충분히 좋았습니다. 문제는 튜토리얼에서 아무도 이야기하지 않는, 모델 주변의 모든 것입니다. 왜냐하면 튜토리얼은 데모가 작동할 때 끝나기 때문입니다.

이것이 저를 괴롭혔습니다. 받아들이거나 아니면 포기해야 합니다.

애초에 에이전트를 구축해야 하는 이유

프레임워크를 선택하기 전에 물어볼 가치가 있습니다.

에이전트가 실제로 의미가 있는 경우(단순히 데모되는 것이 아니라, 실제로 사용되는 경우)는 꽤 제한적입니다:

• 간단한 자동화로는 너무 가변적이지만, 사람이 하루에 500번 할 만큼 반복적인 작업. 에이전트가 사용자 누구인지, 어떤 플랜을 사용하는지, 지난 세 번의 세션에서 무슨 일이 있었는지 알아야 하는 고객 지원 분류(triage). 내부 운영 업무: 네 개의 시스템에서 정보를 가져와 슬랙 요약본을 작성하고 끝내는 것. '사용자 계정을 아는 AI'가 일반적인 챗봇에 붙이는 것이 아니라 실제 가치가 되는 SaaS 기능.

이 모든 공통점은 무엇일까요? 에이전트는 무언가를 기억해야 한다는 것입니다. 누가 요청하는지 알아야 합니다. 도구 호출(tool call)이 실패하거나 LLM 제공업체가 안 좋은 오후를 보내도 제정신을 잃지 않아야 합니다.

아래 내용은 이 모든 것을 작동하게 만드는 것에 관한 것입니다.

오케스트레이션 (Orchestration)

LangGraph를 사용하세요. 우아해서가 아니라(항상 그렇지는 않습니다), 프로덕션에서 당신을 죽이는 것들을 처리하고 현재 다른 어떤 것도 이것만큼 잘 하지 못하기 때문입니다.

중요한 점들은 다음과 같습니다: 충돌이 발생해도 상태가 유지됩니다(문제가 생겼다고 해서 처음부터 다시 시작하지 않습니다). 실행 중간에 일시 중지하여 인간의 승인을 기다린 후 재개할 수 있습니다. 데이터 경쟁 조건(data races) 없이 병렬 도구 호출이 가능합니다. 실제로 무엇이 실행되고 있는지 알 수 있도록 명시적인 제어 흐름(explicit control flow)을 가집니다.

Postgres 체크포인팅과 LangGraph를 설정하는 것이 실제로 어떻게 보이는지 알려드리겠습니다. 이것이 에이전트가 충돌에서 살아남게 하는 부분입니다:

from langgraph.graph import StateGraph
from langgraph.checkpoint.postgres import PostgresSaver
from psycopg_pool import ConnectionPool
...

thread_id가 여기서 핵심입니다. 사용자의 ID를 전달하면 모든 세션이 자동으로 격리(isolated), 재개 가능(resumable)하며 지속(persisted)됩니다.

아무도 경고해주지 않는 사실: 이것을 사용하면 단순한 것을 엄청나게 과잉 설계(over-engineer)할 수 있습니다. 저는 FAQ 챗봇이 14개의 노드를 가진 상태 그래프(state graph)로 끝나는 것을 본 적이 있습니다. LangGraph는 당신이 그렇게 하는 것을 막지 않습니다. 스스로를 제어해야 합니다.

다른 대안을 고려해야 할 때: 만약 TypeScript를 우선적으로 사용한다면, 확정하기 전에 Mastra를 살펴보세요. TypeScript 네이티브이며 빠르게 성장하고 있으며, 몇 가지 면에서 더 나은 개발자 경험(DX)을 제공합니다. 만약 워크플로 오케스트레이션(workflow orchestration)을 위해 이미 Temporal을 실행 중인 엔터프라이즈 조직이라면, 또 다른 상태 저장 런타임(stateful runtime)을 도입하는 것보다 에이전트 단계를 Temporal 액티비티(activities)로 구축하는 것이 더 나을 수 있습니다. LangGraph는 새로운 프로젝트를 위한 가장 신뢰할 수 있는 선택지이지만, 절대적인 법칙은 아닙니다.

MCP 및 도구

MCP (Model Context Protocol, Anthropic, 2024년 말)는 올바른 아이디어입니다. 모든 도구마다 커스텀 글루(glue) 코드를 만드는 대신, 에이전트를 외부 서비스에 연결하기 위한 하나의 프로토콜을 사용하는 것입니다. GitHub, Slack, Nhost, Google Drive 등 대부분은 현재 MCP 서버를 갖추고 있습니다. 에이전트를 한 번 연결해 두면 통합 코드를 다시 작성할 필요 없이 도구를 교체할 수 있습니다.

생태계는 실재합니다. 다만 그 성숙도는 불균형하며, 이 점을 솔직하게 말씀드리고 싶습니다.

커뮤니티 MCP 서버들은 차이가 매우 큽니다. 어떤 것들은 견고하고 활발하게 유지 관리됩니다. 어떤 것들은 8개월 동안 손대지 않은 주말 프로젝트 수준입니다. 몇몇은 정말 심각한 보안 문제를 가지고 있었습니다. 한 패키지는 15개 버전 동안 깨끗하게 배포되다가 16번째 버전에서 데이터 유출(exfiltration) 코드를 추가했습니다 (CVE-2025-6514, CVSS 9.6). Anthropic 자체의 공식 Git MCP 서버는 프롬프트 인젝션(prompt injection)을 통해 원격 코드 실행(RCE)이 가능한 취약점을 포함하여 3개의 CVE와 함께 출시되었습니다. 이는 커뮤니티 프로젝트가 아니라 Anthropic의 레퍼런스 구현(reference implementation)이었습니다.

MCP 서버를 npm 패키지처럼 취급하세요. 버전을 고정(pin)하고, 무엇을 하는지 감사(audit)하며, 민감한 데이터에 접근하는 것에 대해 커뮤니티 서버를 맹목적으로 신뢰하지 마세요.

자체 내부 비즈니스 로직을 위한 경우: 직접 MCP 서버를 작성하세요. 생각보다 간단하며, 이는 에이전트가 다른 모든 것과 동일한 인터페이스를 통해 귀하의 자체 시스템과 통신함을 의미합니다.

메모리 (Memory)

이것은 모든 사람이 과소평가하는 스택의 부분이며, 저 또한 여전히 파악해 나가는 중입니다.

실제 문제는 이렇습니다: LLM은 기본적으로 상태가 없는 (stateless) 특성을 가집니다. 모든 API 호출은 제로(zero) 상태에서 시작됩니다. 데모용으로는 괜찮습니다. 하지만 당신이 누구인지 알고, 당신이 긴 답변을 싫어한다는 사실을 기억해야 하는 에이전트에게는 괜찮지 않습니다.

단기 메모리 (세션 내)는 LangGraph의 체크포인터 (checkpointer)가 처리합니다. Postgres에 저장하세요. 특별할 건 없지만, 그냥 잘 작동합니다.

장기 메모리 (세션 간)가 진짜 문제입니다. 두 가지가 필요합니다:

사용자 세션 종료
       │
       ▼
...

단순히 현대적이라는 느낌 때문에 벡터 전용 (pure vector-only) 방식을 택한다면, 질의 가능성 (queryability)과 감사 가능성 (auditability)을 잃게 됩니다. 결국 검사하거나 디버깅할 수 없는 임베딩 (embeddings) 덩어리를 갖게 될 뿐입니다. 두 가지를 모두 사용하세요.

에이전트 노드 내부에서 두 곳 모두에 쓰기:

async def save_memory_node(state: AgentState):
    # 구조화된 사실 → Postgres
    await nhost.graphql("""
...

이것이 가능한 가장 깔끔한 구현 방식이라고 주장하는 것은 아닙니다. 단지 실제 쓰기 경로 (write path)가 어떻게 생겼는지를 보여주는 것입니다.

직접 깊게 파고들기 전까지는 아무도 말해주지 않는 것들:

충돌하는 기억 (Conflicting memories). 사용자가 2월에 "짧게 유지해줘"라고 말했습니다. 4월에는 "이 부분에 대해 더 자세한 내용이 필요해"라고 말합니다. 어떤 것이 승리할까요? 이에 대한 깔끔한 정답은 없으며, 저도 누구도 정답을 가지고 있다고 생각하지 않습니다. 당신은 메모리 로직에서 판단 (judgment calls)을 내려야 합니다.

환각된 기억 (Hallucinated memories). LLM은 당신이 저장한 적 없는 것을 "기억"할 수 있습니다. 이는 프로덕션 환경에서 발생하며, 처음 이를 목격하면 매우 불안합니다.

메모리 비대화 (Memory bloat). 영원히 계속 추가하기만 할 수는 없습니다. 어느 시점에는 요약 (summarization), 망각 (forgetting), 또는 계층적 검색 (tiered retrieval)이 필요합니다. 정확히 언제일까요? 무엇을 요약하고 무엇을 그대로 유지할까요? 무엇을 버릴지 어떻게 결정할까요? 모두 열린 질문들입니다. 이를 진지하게 수행하는 모든 팀은 커스텀 로직을 가지고 있습니다.

Mem0는 이러한 문제 중 일부를 해결하려고 시도하고 있습니다. 현재 상태를 확인해 볼 가치가 있습니다. 유망해 보였지만, 아직 "이것만 끼워 넣으면 끝"이라고 말할 정도는 아닙니다.

너무 늦기 전까지는 아무도 계획하지 않는 백엔드

대부분의 에이전트 튜토리얼은 백엔드를 단순히 "무언가를 저장하는 어딘가"로 취급합니다. 하지만 실제로 에이전트에는 네 가지가 필요합니다:

• 벡터 검색 (vector search) 기능이 있는 데이터베이스 (메모리, 위에서 다룸)
• 사용자 식별 (user identity): 이 사람은 누구인지, 무엇을 할 수 있는지, 어떤 플랜 티어 (plan tier)를 사용하는지
• 파일 스토리지 (file storage): 사용자가 업로드한 문서, 에이전트가 생성한 것, 영구적으로 보관해야 하는 출력물
• 자체 비즈니스 로직을 위한 서버리스 함수 (serverless functions): 모든 도구가 제3자 API인 것은 아니기 때문입니다.

이것들을 별개의 서비스로 엮을 수 있습니다. DB를 위한 Supabase, 인증 (auth)을 위한 다른 서비스, 파일을 위한 S3, 함수를 위한 Lambda 같은 식입니다. 작동은 합니다. 하지만 이는 유지 관리해야 할 네 가지 시스템, 동기화해야 할 네 가지 권한 모델 (permission models), 그리고 서로 어긋날 수 있는 네 가지 요소가 있다는 뜻이기도 합니다.

저는 Nhost를 사용하는데, 그 이유는 이 모든 것이 한곳에 있기 때문입니다: Postgres, pgvector, Auth, Storage, Functions가 일관된 권한 모델과 함께 제공되며, MCP 서버가 있어 에이전트가 단일 인터페이스를 통해 이 모든 것과 상호작용할 수 있습니다. 기능은 동일하면서 관리해야 할 접점 (surface area)은 줄어듭니다.

유일한 정답은 아닙니다. 핵심은 독특함이 아니라 일관성 (coherence)입니다.

LLM 게이트웨이 (LLM Gateway)

이전 프로젝트에서는 이 단계를 건너뛰었습니다. 그러다 Anthropic에서 3시간 동안 장애가 발생하여 제품이 중단된 적이 있습니다. 그때 이후로 다시는 건너뛰지 않았습니다.

게이트웨이가 하는 일은 다음과 같습니다: 오케스트레이터 (orchestrator)와 모델 API 사이에 위치합니다. 폴백 (fallback) 처리 (Anthropic 장애 시 → 자동으로 GPT-4o로 라우팅), 캐싱 (caching) (동일한 프롬프트가 호출 비용을 발생시키는 대신 캐시를 사용), 세션당 비용 제한 (제어되지 않는 에이전트 루프는 누군가 알아차리기 전에 수백 달러를 쌓을 수 있으며, 이는 가설이 아닌 실제 상황입니다), 그리고 대규모 환경에서 API 키 간의 부하 분산 (load balancing)을 수행합니다.

LiteLLM은 제가 시작할 때 선택할 도구입니다. 오픈 소스이며, 자체 호스팅이 가능하고, 통합된 OpenAI 호환 API 뒤에 100개 이상의 제공업체를 갖추고 있습니다. 설정하는 데 오후 한나절이면 충분합니다. 초기 단계에 필요한 모든 것을 충족합니다.

Portkey는 가드레일 (guardrails), 개인정보 (PII) 마스킹 (redaction), 감사 추적 (audit trails), 더 정교한 라우팅 정책 (routing policies) 등이 필요할 때 사용합니다. 2026년 초에 완전히 오픈 소스 (open-source)로 전환되었습니다.

제가 접한 대략적인 휴리스틱 (heuristic)은 다음과 같습니다: LLM 지출액이 월 $10,000 미만이라면 단순한 래퍼 (wrapper)로도 충분합니다. 그 이상이라면 게이트웨이 (gateway)를 선택 사항이 아닌 인프라 (infrastructure)로 취급하십시오.

모델 (The model)

Claude나 GPT-4o를 선택해서 시작하세요. 이 계층은 진정으로 범용화 (commoditizing)되고 있습니다.

여전히 중요한 점: 도구 호출 (tool calling)의 신뢰성은 모델마다 동일하지 않습니다. 다단계 에이전트 도구 사용 (multi-step agentic tool use), 긴 체인 (long chains), 잘못된 도구 출력으로부터의 복구 (recovery from bad tool outputs) — 제 경험상 Claude 3.5 Sonnet이 가장 일관적입니다. GPT-4o가 그 뒤를 바짝 쫓고 있습니다. 오픈 웨이트 (open-weight) 모델들은 이전보다 나아졌고 계속해서 발전하겠지만, 복잡한 복구 시나리오에서는 여전히 뒤처져 있습니다. 격차는 줄어들었지만, 사라지지는 않았습니다.

규모에 따른 비용: 단계별 복잡도에 따라 라우팅 (route) 하세요. 단순한 분류 (classification)나 라우팅 단계에는 거대 모델이 필요하지 않습니다. 그러한 단계에는 Haiku나 GPT-4o mini를 사용하고, 추론 (reasoning) 단계에는 비용이 높은 모델을 사용하십시오. 만약 에이전트가 세션당 25번의 LLM 호출을 수행하는데 그중 20번이 단순한 작업이라면, 당신은 돈을 낭비하고 있는 것입니다.

보안 (Security)

이 섹션은 2024년 버전의 가이드에는 존재하지 않았습니다. 하지만 지금은 존재합니다.

당신이 이해해야 할 공격: 간접 프롬프트 주입 (indirect prompt injection). 당신의 에이전트가 문서를 가져옵니다. 그 문서에는 숨겨진 지침이 포함되어 있습니다. 모델은 컨텍스트 (context) 내에서 콘텐츠와 지침을 구분할 수 없기 때문에 이를 실행합니다.

이것은 이론적인 이야기가 아닙니다. Supabase의 Cursor 에이전트는 통합 토큰 (integration tokens)을 유출하기 위해 SQL이 삽입된 지원 티켓을 처리했습니다. 공격자들은 공격 페이로드 (payload)가 포함된 지원 티켓을 제출했습니다. 에이전트는 권한이 있는 DB 접근 권한을 가지고 있었고, 읽어온 내용을 신뢰했습니다.

Anthropic 자체의 Git MCP 서버는 프롬프트 주입을 통해 RCE (원격 코드 실행)를 허용하는 CVE를 포함하여 배포되었습니다. 경로 탐색 (path traversal), 인자 주입 (argument injection), 리포지토리 범위 제한 우회 (repo scoping bypass) 등이 포함됩니다. 만약 레퍼런스 구현체 (reference implementation)가 그런 문제를 가지고 배포되었다면, 제3자 커뮤니티 MCP 서버는 더 높은 위험이 있다고 가정하십시오.

이것은 아키텍처(architectural)의 문제이기 때문에 완전한 방어책은 존재하지 않습니다. 즉, 이는 패치할 수 있는 버그가 아니라 LLM 컨텍스트 윈도우(context windows)가 작동하는 방식의 특성입니다. 여러분이 할 수 있는 일은 다음과 같습니다:

• 최소 권한 (Least privilege). 에이전트가 읽기만 필요하다면 읽기 권한만 부여하십시오. "만약을 대비해서" 쓰기 권한을 부여하지 마십시오.
• 도구 출력을 신뢰할 수 없는 것으로 취급하십시오. MCP 응답이 모델 컨텍스트(model context)에 들어가기 전에 검증(validate)하고 정화(sanitize)하십시오.
• 되돌릴 수 없는 작업에 게이트(Gate)를 설치하십시오. 에이전트가 이메일을 보내거나 결제 기록을 수정하기 전에 정책에 따라 검증하십시오. 위험도가 높은 경우에는 명시적인 사용자 확인을 요구하십시오.
• MCP 서버를 조사(Vet)하십시오. 버전을 고정(Pin)하십시오. 민감한 데이터 근처에 배치하기 전에 해당 서버가 무엇을 하는지 감사(Audit)하십시오.

관찰 가능성 (Observability)

저는 항상 이것을 마지막에 연결합니다. 그리고 항상 후회합니다.

에이전트는 포착하기 어려운 방식으로 조용히 실패합니다. 일반적인 API는 500 에러를 반환합니다. 하지만 잘못된 메모리를 검색하거나 잘못된 도구를 호출하는 에이전트는 유효한 응답처럼 보이는 무언가를 반환합니다. 실패는 사용자가 알아차리거나, 수치를 확인했을 때 무언가 잘못되었다는 것을 깨닫기 전까지는 보이지 않습니다.

단계별 추적(step-level traces)이 필요합니다. 어떤 노드가 실행되었는지, 어떤 도구가 정확히 어떤 입력값과 함께 호출되었는지, 무엇을 반환했는지, 그 순간 프롬프트(prompt)에 무엇이 있었는지, 각 단계가 얼마나 걸렸는지, 비용은 얼마였는지 등을 알아야 합니다. 로그(logs)가 아니라 추적(traces)이 필요합니다.

제가 사용하는 것은 LangSmith입니다. LangGraph에 네이티브하게 통합되어 있으며, 환경 변수 하나만 설정하면 추적 UI(trace UI)가 정말 훌륭합니다. 종속성(lock-in)은 실재합니다. 이는 LangChain의 제품이니까요. 하지만 현재로서는 이 용도에 이만큼 기능적인 다른 것은 없습니다.

오픈 소스 대안: Langtrace. OpenTelemetry와 호환되며, 데이터를 직접 소유할 수 있고 Grafana 또는 Datadog과 통합됩니다. 설정은 더 많이 필요하지만, UI는 덜 다듬어져 있습니다.

직접 계측(instrument)해야 할 한 가지는 에이전트 추적(agent traces)과 사용자 세션(user sessions) 간의 상관관계입니다. 사용자의 불만을 접수했을 때, 해당 세션을 찾아보고 발생한 전체 체인을 볼 수 있어야 합니다. 이것은 거저 주어지는 것이 아닙니다. 초기에 연결해 두십시오.

여전히 엉망인 것들

메모리 아키텍처 (Memory architecture). 아무도 명확한 해답을 가지고 있지 않습니다. 충돌하는 신호를 어떻게 처리할지, 무엇을 요약하고 무엇을 유지할지, 언제 잊어야 할지 등: 이를 진지하게 다루는 모든 팀은 커스텀 로직 (custom logic)을 사용합니다. 만약 누군가 완전한 솔루션을 판매하려 한다면, 철저히 검증하십시오.

평가 (Evals). 대부분의 팀은 여전히 인간의 검토에 의존하고 있는데, 이는 개방형 에이전트 행동 (open-ended agent behavior)에 대한 자동화된 평가를 제대로 구축하는 것이 진정으로 어렵기 때문입니다. 단순히 '해피 패스 (happy-path)' 동작이 아닌 실제 회귀 (regressions)를 잡아낼 수 있는 평가 데이터셋 (eval datasets)을 구축하려면 상당한 투자가 필요하며, 대부분의 팀은 프로덕션 (prod) 환경에서 문제가 발생하기 전까지는 이를 수행하지 않습니다.

멀티 에이전트 패턴 (Multi-agent patterns). 플래너-실행자 (Planner-executor) 설정, 디베이트 루프 (debate loops), 에이전트 계층 구조 (agent hierarchies) 등: 사람들은 이 모든 것을 프로덕션에서 사용하고 있습니다. 어떤 상황에 무엇을 사용해야 하는지에 대한 합의는 아직 없습니다. 빠르게 진화하고 있습니다.

MCP 보안 (MCP security). 이 프로토콜은 생긴 지 2년이 채 되지 않았습니다. CVE (취약점)들이 나타나고 있습니다. 최신 상태를 유지하십시오.

비용 (Cost). 하루 1,000 세션에서 20단계의 에이전트 루프를 돌리는 것은 실제 큰 비용이 발생합니다. 청구서를 받은 후가 아니라, 비용이 필요해지기 전에 토큰 예산 제어 (token budget controls) 기능을 구축하십시오.