엔터프라이즈 AI 에이전트를 안전하게 운영하는 거버넌스의 길

URL: https://www.youtube.com/watch?v=tZycGA_Fbfo 날짜: 2026-10-15 채널: aiDotEngineer 발표자: Harish Gaggar, Credit Karma

📌 핵심 질문 / 이 글이 다루는 핵심 논점

==실험 단계의 AI 에이전트를 엔터프라이즈 운영 환경에 올리려면 에이전트 하나를 빨리 만드는 데 그치지 말고, 인증·라우팅·도구 통제·관찰 가능성·메모리·평가·PII 차단·컨텍스트 비용 최적화를 포함한 공통 거버넌스 프레임워크를 먼저 구축해야 한다.==

• 프로덕션 실패의 핵심 원인은 에이전트의 foundation control이 빠져 있고, 중앙 MCP gateway·인증·감사·평가가 분리되어 있거나 존재하지 않기 때문이다.
• 모든 도구 호출은 중앙 MCP gateway에서 인증하고 승인된 MCP server의 승인된 tool로만 전달해야 한다.
• LangGraph 기반 에이전트, MCP gateway/server, monitoring, memory management, tracking/evaluation, PII treatment, context optimizer를 하나의 표준 개발·배포 경로로 제공해야 한다.
• 고위험 변경 작업에는 Human-in-the-loop(HITL)를 두고, 모든 실행·승인·거부를 audit log에 남겨야 한다.

엔터프라이즈 AI의 운영 단위는 개별 에이전트가 아니라 에이전트와 주변 통제 체계의 묶음이다. 개발자가 일관된 템플릿으로 에이전트를 만들고, 중앙 레지스트리와 CI/CD를 거쳐 Kubernetes에 배포하며, 모든 요청을 인증·추적·평가하고 민감정보와 토큰 비용을 통제해야 지속 가능한 운영이 가능하다.

1. 문제 정의와 전체 접근법

실험용 에이전트를 운영 시스템으로 옮기는 일은 모델 호출을 배포하는 일이 아니라 통제 가능한 시스템을 설계하는 일이다.

1.1. 발표자 배경과 다룰 범위

1. Credit Karma의 AI 인프라 책임

   1. 역할: Harish Gaggar는 Intuit Credit Karma의 senior staff software engineer로서 AI analytics infrastructure와 services를 구축하고 소유한다.
   2. 추가 활동: advisor, author, researcher로 활동하며 여러 조직의 program committee member로 참여하고 젊은 연구자를 멘토링한다.

2. 엔터프라이즈 전환의 순서

   1. 장애 요인 파악: AI agent를 만들고 production system에 배포할 때 생기는 문제를 먼저 확인한다.
   2. 프레임워크와 아키텍처: 문제를 다루는 공통 framework와 전체 architecture를 설계한다.
   3. MCP 계층: 자체 MCP server와 MCP gateway를 만들고 gateway 위에 monitoring을 얹는다.
   4. 보조 통제 계층: agent framework 종류, memory management, tracking과 evaluation, PII data 차단, context optimizer를 함께 다룬다.

1.2. 프로덕션 실패를 일으키는 foundation control의 부재

1. 인증·라우팅 기반의 부재

   1. Gateway 누락: agent가 gateway에 접속해 올바른 authentication provider로 먼저 인증하고 적절한 MCP server로 라우팅되는 경로가 없는 경우가 많다.
   2. 직접 접근 위험: 중앙 인증과 라우팅이 없으면 agent나 service account가 endpoint에 직접 접근하게 되어 권한·경로·감사 통제가 약해진다.

2. 도구와 운영 품질 통제의 부재

   1. MCP tool 부족: MCP server에 query를 실행할 올바른 tool이 없으면 모델이 요구한 작업을 안전하게 수행할 수 없다.
   2. Tracking/evaluation 부족: agent로 보낸 모든 query가 추적되는지, 응답 품질이 평가되는지 알 수 없게 된다.
   3. Memory management 부족: 여러 날에 걸쳐 대화할 때 과거 요청을 기억하고 복구할 수 없다.
   4. Context 최적화 부족: 불필요한 context가 그대로 LLM에 전달되어 token을 낭비한다.
   5. 민감정보 보호 부족: secret이 LLM, tracking/tracing, memory DB로 유출될 수 있다.

3. 해결 방향

   1. 마법 같은 agent를 만드는 접근 배제: 한 번의 데모에서 모든 문제를 해결하는 agent 대신 재사용 가능한 여러 framework를 결합한다.
   2. 표준 계층 구성: agent framework, MCP gateway, customized MCP server, audit, PII blocking, tracking/evaluation, memory, context optimizer를 함께 제공한다.

2. 엔터프라이즈 에이전트 개발·배포 아키텍처

개발 포털에서 에이전트 정체성과 공통 통제 리소스를 함께 만들고, 승인된 container를 CI/CD와 Kubernetes로 이동시킨다.

2.1. LangGraph 기반 agent framework

1. 그래프 기반 실행 모델

   1. 선택한 framework: LangChain community가 제공하는 LangGraph를 사용한다.
   2. 구조적 장점: graph-based architecture가 loop, branching, state management를 지원하므로 복잡한 multi-agent AI workflow를 표현할 수 있다.

2. 질문에 맞춘 구성

   1. Task-specific node: 질문 유형에 따라 필요한 node를 만들고 실행한다.
   2. 확장성: marketplace plugin, skill, prompt를 쉽게 연결해 query에 효율적으로 응답하도록 한다.

2.2. 등록과 내부 개발 포털

1. Agent 등록

   1. Use case 입력: 어떤 use case이며 어느 vertical 또는 system에서 사용할지 등록한다.
   2. 식별자 발급: 등록 정보로 agent ID를 생성한다.

2. Dev portal 메타데이터

   1. 기본 정보: agent use case와 agent ID를 입력한다.
   2. Framework와 언어: LangGraph, LangChain 같은 framework와 Python 또는 TypeScript 같은 구현 언어를 선택한다.
   3. 행동 정의: 사용할 skill과 prompt를 선택한 뒤 정보를 제출한다.

3. 표준 repository 생성

   1. 통합 템플릿: 포털은 LangGraph agent framework만이 아니라 memory framework, tracking/evaluation framework, context optimizer framework, PII blocking framework를 포함한 repository를 만든다.
   2. 중앙화 목적: 모든 개발자가 이 기능을 직접 설계하거나 하나의 framework만 아는 것은 아니므로 회사 전체에서 일관된 통제와 결과 시각화를 가능하게 한다.

4. 로컬 개발

   1. 실행 환경: 개발자는 repository를 clone하고 agent를 Docker image와 container로 만든다.
   2. 검증: query를 통해 agent input/output을 시험하고 local memory의 trace를 확인한다.
   3. 로컬 저장소: tracking과 evaluation 데이터는 SQLite 또는 BigQuery에 저장해 agent가 local에서 완전히 동작하는지 확인한다.

2.3. PR 승인부터 Kubernetes 배포까지

1. 변경 승인과 CI/CD 진입

   1. PR 조건: local agent가 검증되면 PR을 만들고 두 번의 PR approval을 받은 뒤 CI/CD pipeline으로 보낸다.
   2. 중앙 레지스트리 등록: pipeline은 먼저 중앙 agent registry system에 agent를 등록하고, trace를 볼 수 있는 Langfuse URL을 제공한다.

2. Container 보안 검증

   1. Production image 생성: local에서 만든 Docker container를 production system용 image로 빌드한다.
   2. 취약점 검사: image에 vulnerability가 없는지 검사한다.
   3. Registry 복귀: 보안 승인이 완료되면 image를 registry에 저장한다.

3. 오케스트레이션과 배포 리소스

   1. Kubernetes 배포: deployment platform 또는 orchestrator platform이 지정 namespace의 Kubernetes cluster에 agent를 배포한다.
   2. 포털이 함께 만드는 리소스: repository 외에도 workload identity, memory DB, tracking/evaluation table, agent secret management를 agent 이름에 맞춰 생성한다.
   3. 권한 바인딩: 내부 orchestrator가 배포할 때 agent가 사용할 workload identity가 이미 정해져 있어야 하며, Kubernetes service account(KSA)와 Google service account(GSA)의 KSA-to-GSA binding이 완료되어야 한다.
   4. 후속 endpoint: binding이 끝난 agent는 AI gateway, MCP server, Langfuse tracing, 기타 API endpoint와 통신한다.

3. 자체 MCP server와 중앙 MCP gateway

Air-gapped environment에서는 외부 MCP component에 의존하기보다 내부에서 server와 gateway를 만들고, tool·권한·라우팅을 한곳에서 통제해야 한다.

3.1. Customized MCP server

1. 자체 구축이 필요한 환경

   1. Air gap 대응: 외부 네트워크가 차단된 air-gapped environment에서는 자체 MCP server를 구축하는 것이 특히 권장된다.
   2. 구현 방식: FastMCP server package 또는 wrapper를 활용해 server를 구성하고 wrapper 안에 여러 tool을 정의한다.

2. Tool의 보안 검토

   1. Internal security review: production에 들어가는 모든 tool은 내부 security team의 검토를 받아야 한다.
   2. 허용 범위: 승인된 tool만 production에서 실행되도록 한다.
   3. 데이터 최소화: filter와 limit을 적용하고 LLM으로 보낼 필요가 없는 field를 차단한다.
   4. 권한 데이터 제한: 사용자가 얻으면 안 되는 정보를 MCP tool이 반환하지 않도록 tool 수준에서 제한한다.

3. 인증 전제

   1. 경로: MCP client에서 MCP gateway를 거쳐 MCP server로 들어오는 모든 traffic을 중앙 gateway에서 먼저 인증한다.
   2. 주체: user와 service account 어느 쪽에서 온 요청이든 gateway 인증을 통과한 뒤에만 MCP tool을 사용할 수 있다.

3.2. MCP gateway의 인증·라우팅 흐름

1. 최초 요청과 session state

   1. 요청 주체: cloud assistant, local code-assistance tool 또는 agent가 첫 query를 제출한다.
   2. 일회성 인증: client는 MCP gateway로 one-time authentication request를 보낸다.
   3. 세션 저장: gateway는 요청을 인식하고 session state를 Redis에 저장한다.
   4. 토큰 발급: gateway는 client에 JWT access token을 돌려준다.

2. Namespace 기반 MCP server 선택

   1. Tool call 형식: client는 호출해야 할 MCP server를 알고 /{namespace}/mcp 경로로 tool call request를 보낸다.
   2. 사례: namespace는 Artifactory 또는 GitHub가 될 수 있으며, 요청에는 Authorization: Bearer 방식의 JWT가 포함된다.
   3. 라우팅: gateway는 namespace를 해석해 호출할 MCP server를 찾는다.

3. 권한 전달과 응답

   1. 토큰 해제: gateway는 JWT를 unwrap하고 그 안의 user token을 요청에 붙인다.
   2. 외부 API 호출: MCP server는 해당 service endpoint에 API call을 수행하고 ID token을 교환한다.
   3. Scope 적용: MCP server는 사용자가 허가받은 scope에 해당하는 정보만 반환한다.
   4. 응답 변환: server는 데이터를 MCP gateway가 받을 수 있는 payload로 만들고 gateway는 최종 payload를 client에 전달한다.

4. 직접 endpoint 접근 금지

   1. 중앙 인증 허브: gateway는 coding assistant 또는 agent를 endpoint와 안전하게 연결하는 중앙 authentication·routing hub다.
   2. 강제 경로: endpoint에 직접 접근하지 않고 반드시 적절한 authentication을 거쳐 MCP gateway와 MCP server를 통과하게 한다.

4. Gateway monitoring과 observability

AI agent는 지속적인 monitoring, evaluation, feedback 없이는 신뢰할 수 없으므로 gateway 호출의 log·trace·metric을 서로 다른 저장소에 보낸다.

4.1. Operational log와 query 가능한 사건 기록

1. Log pipeline

   1. 수집: agent에 call을 제출하는 순간 operational log를 log store로 보낸다.
   2. 선택지: ELK, Loki, CloudWatch를 log store로 사용할 수 있다.

2. 운영 질문에 답하는 데이터

   1. 인증 오류: 최근 10분 동안 발생한 모든 401을 조회할 수 있어야 한다.
   2. OAuth 문제: token refresh가 실패했을 때 OAuth가 어떤 동작을 했는지 확인할 수 있어야 한다.

4.2. OpenTelemetry, Tempo, Prometheus, Grafana

1. Trace 수집

   1. OpenTelemetry: open-source solution인 OpenTelemetry가 실시간 trace와 metric을 수집하고 처리해 backend system으로 전달한다.
   2. Tempo 저장: trace는 open-source backend인 Tempo에 저장한다.
   3. Trace 내용: 어떤 tool이 느렸는지, 호출이 agent와 IDE 중 어디에서 왔는지, 실패한 call의 정확한 error가 무엇인지 확인한다.

2. Metric 수집

   1. Prometheus 저장: metric은 Prometheus에 저장한다.
   2. 성능 지표: 주어진 tool의 P95 latency를 확인한다.
   3. 인증 추세: 특정 시간대에 authentication rejection이 급증하는지 확인한다.

3. 통합 시각화

   1. Grafana 집계: trace와 metric을 집계해 Grafana에서 전체 운영 상태를 시각화한다.
   2. 목적: gateway의 인증, 지연, 실패, 도구 실행을 한 흐름으로 관찰하고 문제를 feedback으로 연결한다.

5. LangGraph의 안전한 agent 실행 흐름

LangGraph의 graph state와 subgraph를 활용해 질문 해석부터 정책 판정·실행·감사까지의 경로를 명시적으로 만든다.

5.1. 해석·분류·계획

1. 질문 해석

   1. 의도 파악: 첫 query가 어떤 종류의 질문인지와 어떤 응답을 요구하는지 해석한다.
   2. 계획 생성: 해석 결과를 바탕으로 실행 plan을 만든다.

2. 작업 위험도 분류

   1. Read: 정보 조회만 수행하는지 판정한다.
   2. Write/modify: modification-level change를 요청하는지 판정한다.
   3. Delete와 민감 작업: 삭제 또는 sensitive operation인지 판정한다.
   4. 계획 조정: 분류 결과에 따라 전체 실행 구조와 plan을 조정한다.

3. Plan subgraph

   1. 독립 subgraph: plan 자체가 주요 작업을 수행하는 subgraph로 동작한다.
   2. Evidence 획득: fetch-evidence 단계에서 질문에 필요한 데이터를 요청한다.
   3. 도구 경로: MCP gateway 인증을 거쳐 MCP server의 올바른 tool을 호출하고 결과로 evidence를 생성한다.

5.2. 정책 판정·HITL·감사

1. Read-only 실행

   1. 정책 확인: evidence를 검증한 뒤 해당 작업이 read-only인지 policy를 확인한다.
   2. 실행과 기록: read-only이면 실행하고 모든 record point를 audit log에 저장한다.

2. Write·Sensitive 작업

   1. Human-in-the-loop: write 또는 sensitive operation이면 HITL process에서 사람의 approval을 기다린다.
   2. 승인: 승인되면 작업을 실행하고 audit log에 기록한다.
   3. 거부: 거부되면 실행하지 않지만 거부 결과 역시 audit log에 기록한다.

3. 전체 호출 경로

   1. 단일 경로: agent가 제출한 모든 call은 MCP gateway에서 인증받는다.
   2. 도구 실행: gateway가 적절한 MCP server로 redirect하고 server가 endpoint API를 호출해 응답을 가져온다.
   3. 인프라 흐름: agent → MCP gateway → MCP server → endpoint 순서를 유지한다.

6. Agent memory management

Memory management는 workflow state를 시간에 따라 저장하고 복구해 query run 사이의 durability와 seamless recovery를 보장한다.

6.1. Thread·run·checkpoint 모델

1. Thread 생성

   1. 대화 단위: agent에 query를 제출할 때마다 thread가 생성된다.
   2. Run ID: thread에서 첫 질문을 하면 해당 실행을 식별하는 run ID가 생성된다.

2. Node별 상태 저장

   1. 실행 위치: 더 깊은 후속 질문을 하면 LangGraph의 특정 node로 이동해 query를 실행한다.
   2. Checkpoint: node에서 해당 실행의 checkpoint를 저장한다.
   3. 후속 질문: 같은 thread에 follow-up question을 제출하면 새 run ID를 만들고, 질문에 맞는 node와 checkpoint를 추가한다.

3. 환경별 DB

   1. Local: local development에서는 SQLite DB를 사용할 수 있다.
   2. GCP production: production GCP 환경에서는 Cloud Spanner를 사용할 수 있다.
   3. 다른 cloud: Azure와 AWS에서도 각각 해당 cloud의 데이터베이스를 사용한다.

6.2. Memory DB 데모에서 확인하는 정보

1. 초기 상태와 첫 query

   1. 빈 DB: local agent를 만들고 SQLite DB를 조회하면 처음에는 데이터가 없다.
   2. 첫 record: query를 제출하면 thread ID, 질문 내용, query가 실행된 정확한 시각이 담긴 record 하나가 생긴다.

2. Thread 메시지 조회

   1. 메시지 수: 별도 query로 해당 thread에서 몇 개의 message가 만들어졌는지 확인한다.
   2. Metadata: metadata query로 호출된 tool 수, thread ID, run ID 등 실행 정보를 확인한다.

3. 실행 재구성

   1. Tool 목록: 해당 query에서 실행된 MCP server의 정확한 tool name을 조회한다.
   2. Graph 진행: memory DB를 조회해 query 실행 중 어떤 LangGraph node들이 호출됐는지 순서와 진행 상태를 확인한다.

7. Agent-level tracking과 evaluation

Gateway monitoring이 인증·라우팅 인프라를 관찰한다면 agent-level tracking은 질문, 응답, 모델, token, 비용, 품질을 제품 단위로 기록한다.

7.1. 첫날부터 쌓아야 할 운영 데이터

1. Run 기본 데이터

   1. 입출력: 어떤 query를 제출했고 어떤 response가 돌아왔는지 저장한다.
   2. 모델·비용: 사용한 LLM model, 소모한 token 수, token cost를 저장한다.
   3. 품질 기준: response quality를 어떤 evaluation criteria로 판단하는지 함께 저장한다.

2. 대규모 운영의 조직 문제

   1. Agent 수 증가: 1,000개 이상의 agent가 생기면 agent마다 tracking/evaluation project와 table이 필요해진다.
   2. 예시 규모: agent가 100개라면 100개의 project가 생기고 각 project가 자체 tracking/evaluation table을 가진다.
   3. 경영 지표: 6개월 뒤 agent 성능, response, quality, token 사용량을 묻는 질문에 답하려면 데이터를 통합해 executive dashboard를 만들고 여러 agent 구축의 ROI를 계산해야 한다.

7.2. Tracking/evaluation table 구조와 데모

1. 여섯 개 table

   1. Job tracking table: query, response 등 job의 핵심 실행 정보를 저장한다.
   2. 세부 table: quality 관련 데이터, tool invocation, node-level execution 등 실행을 여러 관점에서 저장한다.
   3. 지연 반영: 첫 query 직후에는 데이터가 보이지 않을 수 있어 새로고침을 거쳐 record를 확인한다.

2. Job record

   1. 식별자: request ID, session ID, agent name을 기록한다.
   2. 내용과 상태: 질문, output, 완료 여부, 소요 시간, 사용 model, 중간 수준의 실행 정보를 기록한다.

3. Quality check와 eval score

   1. 8개 품질 검사: 각 run마다 success, latency, cost, tool accuracy, safety 등을 포함한 8개의 quality check를 저장한다.
   2. 통합 scoreboard: eval score는 하나의 row에 해당 run의 여러 quality dimension을 모아 0부터 1 사이의 점수로 표시한다.
   3. 심층 quality metric: 한 run을 깊게 보는 nested field에 response quality, safety, latency, cost, tool statistic을 기록한다.

4. Tool과 trajectory 기록

   1. Tool invocation: 실행된 MCP tool, 각 호출에 걸린 시간, 성공 여부를 모든 tool call 단위로 저장한다.
   2. Agent trajectory: run의 단계별 흐름으로서 각 LLM call과 graph state를 순서대로 기록하며 plan과 summarize 같은 상태를 포함한다.

8. PII와 secret을 LLM 경계에서 차단

민감정보는 모델로 보낸 뒤에 지우는 것이 아니라 입력되는 순간 분류하고 차단·redact해야 한다.

8.1. 민감정보 유입 사례

1. 문서 업로드

   1. Sensitive document: 사용자가 민감한 정보가 포함된 문서를 agent에 업로드할 수 있다.
   2. 노출 경로: 그대로 두면 문서의 secret이 query와 함께 후속 계층으로 전달될 수 있다.

2. 입력 중 secret

   1. API key: 사용자가 입력하는 중 API key를 query에 포함할 수 있다.
   2. 저장 위험: 입력을 즉시 처리하지 않으면 LLM뿐 아니라 memory DB, tracking/evaluation table, tracing system에도 남는다.

8.2. Severity 기반 차단

1. 정책 분류

   1. Data type: framework가 여러 data type을 정의한다.
   2. Severity level: 각 유형에 severity level을 부여해 위험도를 판단한다.

2. 90% 초과 정책

   1. 즉시 block/redact: severity가 90%를 초과하면 secret을 즉시 block하고 redact한다.
   2. 전파 차단: secret은 LLM model로 가지 않으며 memory DB, tracking/evaluation table, tracing system에도 가지 않는다.
   3. 처리 시점: 민감정보가 ingest되는 순간, 사용자가 입력하는 순간에 처리해 downstream 저장을 차단한다.

9. Context optimizer와 token 비용 절감

큰 query·파일·데이터 묶음을 그대로 모델에 전달하지 않고 shape, prune, rerank, dedupe, compress 순서로 핵심 context를 만든다.

9.1. 최적화 파이프라인

1. Payload 선별

   1. Query shaping: 제출된 query와 context를 먼저 적절한 형태로 만든다.
   2. Pruning: LLM으로 보내기 전에 payload를 prune한다.
   3. Token limit: token limit에 맞춰 전달할 payload를 선택한다.

2. 관련성·중복 처리

   1. Re-ranking: 큰 context에서 어떤 정보가 query에 가장 relevant한지 다시 순위를 매긴다.
   2. Deduplication: 중복 데이터를 제거한다.
   3. Curated set: 모델이 사용할 고유하고 엄선된 핵심 데이터 집합을 만든다.

3. 최종 압축

   1. Compression: 큰 payload를 LLM으로 보내기 전에 압축한다.
   2. 목표: 답변에 필요한 정보는 보존하면서 query당 token과 비용을 줄인다.

9.2. Artifactory와 Slack bot 데모

1. JFrog Artifactory 검색

   1. 기준 query: “내 JFrog Artifactory에서 모든 artifact를 찾아라”라는 query를 제출한다.
   2. 최적화 전: optimizer를 끄면 동일 query에 약 24,000 token을 사용한다.
   3. 최적화 후: optimizer를 켜고 정확히 같은 query를 다시 실행하면 약 2,400 token을 사용한다.
   4. 효과: 약 90%의 token을 절감한다.

2. Slack bot의 Docker image 검색

   1. 기준 query: “Artifactory의 모든 repository에서 내 Docker image를 찾아라”라는 질문을 Slack bot에 보낸다.
   2. 최적화 전: optimizer를 끄면 약 24,000 token을 사용한다.
   3. 최적화 후: optimizer를 켜고 같은 query를 다시 실행하면 약 1,500 token만 사용한다.
   4. 효과: 이 경우에도 약 90%의 token을 절감한다.

3. 일반적인 절감 폭

   1. 관측 범위: 대부분의 경우 70~78% token 절감 효과를 얻는다.
   2. 대규모 효과: 수천 개 agent가 매일 많은 query를 처리한다면 query당 절감이 누적되어 상당한 비용과 context 처리량을 줄인다.

10. 최종 운영 원칙과 다음 단계

엔터프라이즈 AI의 목표는 빠른 agent 출하가 아니라 처음부터 통제 체계를 내장한 agent platform을 갖추는 것이다.

10.1. 반드시 갖출 공통 framework

1. 출하 전 기본 원칙

   1. 전체 framework 선행: agent를 서둘러 만들어 ship한 뒤 나중에 통제를 덧붙이지 않는다.
   2. 초기 내장: gateway, memory, tracking/evaluation, PII blocking, context optimizer를 최초 설계부터 포함한다.

2. 접근·도구·감사 원칙

   1. Centralized MCP gateway: local tool call이든 agent를 통한 call이든 모든 요청을 중앙 MCP gateway로 보낸다.
   2. 인증 선행: MCP server에 도달하기 전에 gateway에서 authentication을 완료한다.
   3. Tool control: MCP server가 특정 query에 허용할 tool을 통제한다.
   4. Monitoring과 audit: tool execution을 위한 monitoring과 완전한 auditing을 마련한다.

3. 위험 작업과 비용 원칙

   1. Human in the loop: 모든 action item, 특히 high-risk item에 사람의 승인 절차를 유지한다.
   2. Observability: 전체 호출·오류·성능을 관찰할 수 있어야 한다.
   3. Context optimizer: agent 비용을 정당화하려면 context optimizer를 항상 둔다.

10.2. 참고 자료와 마무리

1. MCP 관련 책

   1. 출간: Harish Gaggar는 MCP 책을 Amazon에 최근 출간했다.
   2. 이용 조건: Kindle판은 무료로 내려받을 수 있고 hard copy판도 제공된다.

2. 연락 경로

   1. 질문 대응: 추가 질문은 LinkedIn 또는 Twitter로 문의할 수 있다.
   2. 마무리 발언: 질문에 답하겠다는 안내와 감사 인사로 마무리한다.

주요 발언 모음

“프로덕션에 배포할 때는 agent 하나만 만드는 것이 아니라, 그 아래에 있는 모든 framework를 포함한 enterprise framework를 만들어야 한다.”

“서둘러 agent를 만들고 ship하지 말고, 모든 framework를 함께 거치게 하라.”

“모든 tool call request는 중앙화된 MCP gateway를 거쳐야 하며, MCP server에 도달하기 전에 인증되어야 한다.”

“AI agent는 지속적인 monitoring, evaluation, feedback 없이는 신뢰할 수 없다.”

“민감한 secret은 입력되는 순간 차단해야 하며 LLM, memory DB, tracking/evaluation table, tracing system으로 보내서는 안 된다.”

“같은 query에서 context optimizer를 켜면 약 90%의 token을 절약할 수 있다.”

핵심 데이터 & 수치

• PR 승인: CI/CD pipeline 진입 전 두 번의 PR approval을 받는다.
• 저장·실행 경로: KSA-to-GSA binding 후 Kubernetes namespace에 agent를 배포하고 AI gateway, MCP server, Langfuse tracing 등과 통신한다.
• Gateway session: 최초 인증 요청의 session state는 Redis에 저장하고 JWT access token을 반환한다.
• Monitoring: 최근 10분간 401, OAuth token refresh 실패, tool P95 latency, authentication rejection 급증을 조회·분석한다.
• Memory: query마다 thread와 run ID를 만들고 node별 checkpoint를 저장한다.
• Tracking 규모: 1,000개 이상의 agent를 운영하면 agent별 tracking/evaluation project가 필요하며, 100개 agent는 100개 project와 각각의 table을 만든다.
• Quality: run마다 8개 quality check를 저장하고, 통합 eval score는 0~1 범위로 기록한다.
• PII 차단: severity가 90%를 넘는 secret은 즉시 block·redact한다.
• Context optimizer: JFrog Artifactory query는 24,000→2,400 token, Slack Docker image query는 24,000→1,500 token으로 약 90% 절감한다.
• 일반 절감률: 대부분의 query에서 70~78% token을 절약한다.

결론 및 시사점

1. 플랫폼을 먼저 설계하라: 에이전트의 기능보다 인증·메모리·평가·보안·관찰 가능성을 포함한 공통 플랫폼이 운영 성공을 결정한다.
2. 모든 도구 호출을 중앙화하라: MCP gateway를 단일 인증·라우팅 허브로 만들고 endpoint 직접 접근을 제거해야 한다.
3. 위험도에 따라 실행을 분기하라: read-only는 정책 확인 후 자동 실행하고, write·delete·sensitive operation은 HITL approval을 요구하며 결과를 모두 감사한다.
4. 첫날부터 데이터를 남겨라: request, response, model, latency, cost, token, tool, node, quality를 축적해야 나중에 품질과 ROI를 설명할 수 있다.
5. 민감정보를 경계에서 차단하라: PII와 secret을 모델·메모리·평가·trace 저장소에 보낸 뒤 정리하는 방식보다 ingest 순간 차단하는 방식이 안전하다.
6. Context를 비용 계층으로 다뤄라: pruning·re-ranking·deduplication·compression을 표준화하면 대규모 agent 운영의 token 비용과 처리량을 실질적으로 낮출 수 있다.
7. 거버넌스는 사후 보완물이 아니다: production으로 가는 첫 commit부터 agent와 거버넌스 framework를 하나의 배포 단위로 취급해야 한다.