수익 운영(Revenue Operations) 팀의 누군가가 CRM 데이터 관리(Hygiene) 문제로 영업 담당자(Account Executives)들을 계속 잔소리하는 것에 지쳤습니다. 그래서 그들은 에이전트(Agent)를 연결했습니다. Salesforce에는 MCP 서버가 있고, 모델은 도구(Tools)를 호출할 수 있으며, 워크플로우는 명확합니다. 회의 녹취록을 가져와서, 다음 단계(Next steps)를 추출하고, 기회(Opportunity)를 업데이트하고, 활동을 기록하고, 후속 작업을 푸시하는 것입니다. 오후 시간 동안의 작업, .env 파일에 있는 API 토큰 하나면 모든 것이 작동합니다.

잘 작동합니다. 영업 담당자들은 불평을 멈춥니다. 데모는 여기저기 공유됩니다. 일주일 안에 다른 두 팀이 Zendesk와 Jira에 대해서도 똑같은 기능을 원하게 되고, 당신은 조용히 사내에서 프로덕션 단계의 에이전트형 AI(Agentic AI) 소유자가 됩니다.

그러다 이것은 더 이상 오후 시간의 프로젝트가 아니게 됩니다. 에이전트가 나빠졌기 때문이 아니라, 에이전트가 다른 사람들을 대신하여 행동하는 순간, 프로토타입을 빠르게 만들었던 모든 지름길들이 print() 문으로는 대답할 수 없는 질문들로 변하기 때문입니다.

요약 (TL;DR)

• 인증(Auth), 권한(Permissions), 감사 로그(Audit logs), 통합(Integrations), 재사용성(Reuse) 또는 리스크 소유권(Risk ownership)이 프로토타입 단계를 벗어나기 시작할 때, AI 에이전트를 위한 MCP 런타임(Runtime)이 필요합니다.
• MCP는 도구 연결(Tool connections)을 표준화하지만, 그 자체만으로 프로덕션 거버넌스(Production governance) 문제를 해결하지는 않습니다.
• MCP 런타임은 신원(Identity), 정책(Policy), 도구 실행(Tool execution) 및 증거(Evidence)를 중앙 집중화하여, 프로덕션 환경에 AI 에이전트를 배포할 때 이러한 레이어들을 처음부터 다시 구축할 필요가 없게 만듭니다.

벽에 부딪히는 것은 실패가 아니라 예측 가능한 과정입니다

당신은 옳은 것을 만들었습니다. 프로토타입 우선(Prototype-first) 경로는 올바른 첫 번째 움직임입니다. 모델이 도구를 호출할 수 있고 MCP 서버가 기능을 노출할 수 있다면 프로토타입을 조립하는 비용은 저렴하며, 소규모 팀은 좁은 해피 패스(Happy path)를 감당할 수 있습니다. 현재 규모 있게 에이전트를 운영하는 모든 팀은 단 하나의 워크플로우, 하나의 테넌트(Tenant), 가벼운 사용량, 그리고 관대한 리스크 태세(Risk posture)를 가진 당신과 정확히 같은 지점에서 시작했습니다.

첫 번째 버전이 작동하는 이유는 조용히 편법을 쓰고 있기 때문입니다. 그것을 만든 엔지니어가 곧 보안 경계(Security boundary)입니다. 그들은 에이전트가 어떤 레코드를 건드릴 수 있는지 알고 있고, 프롬프트(Prompt)를 직접 작성했으며, 토큰(Token)을 보유하고 있습니다. "이 에이전트에게 무엇을 허용해야 하는가"라는 질문은 생기지 않습니다. 왜냐하면 그 답이 "개발자인 내가 할 수 있는 모든 것"이기 때문입니다. 이러한 가정은 에이전트가 당신이 아닌 다른 사람들을 위해 일을 하기 시작하는 순간까지는 유효합니다.

작동하는 프로토타입과 실제 인프라가 필요한 결과물을 구분하는 여섯 가지 신호가 있습니다. 이 중 특별하거나 생소한 것은 없습니다. 대부분의 경우 당신의 저장소(Repo)에서 직접 목격하게 될 것입니다.

신호 1: 에이전트 로직보다 인증(Auth) 및 로그인 배관 작업(Plumbing)을 더 많이 작성하고 있다

ID 계층(Identity layer): 실제로 도구(Tools)를 호출하는 주체가 누구인지 증명하는 것.

임계점을 넘었다는 증거: auth/ 디렉터리가 tools/ 디렉터리보다 커졌을 때.

당신의 저장소를 살펴보십시오. tools/ 디렉터리에 auth/라는 형제 디렉터리가 생겨났고, 이제 auth/가 더 커졌습니다. 스탠드업(Standup) 미팅의 주제는 "어떻게 에이전트를 개선할 것인가"에서 "왜 이 사용자의 리프레시 토큰(Refresh token)이 실패했는가" 또는 "에이전트가 어떤 계정을 사용 중인가"로 옮겨갔습니다. 새로 합류한 엔지니어의 첫 번째 티켓(Ticket)은 "Slack 추가"이지만, 이를 완료하는 데 2주가 걸립니다.

발생하는 이유

실행 에이전트(Acting agents)는 사용자와 다운스트림 API(downstream API) 사이의 까다로운 중간 지점에 위치합니다. 이로 인해 과거에는 무료로 제공받았던 다중 사용자 AI 에이전트 인증 및 인가 (multi-user AI agent authentication and authorization) 메커니즘을 직접 관리해야 하며, 기업용 API들은 통일된 ID 표준을 공유하지도 않습니다. Slack은 12시간마다 액세스 토큰을 교체(rotate)하며; GitHub은 설치 토큰을 한 시간 내에, 리프레시 토큰(refresh tokens)을 6개월 내에 만료시킵니다. Microsoft Graph는 앱 전용 액세스(app-only access)와 위임된 액세스(delegated access)를 자체적인 동의 모델로 분리합니다. 하나를 구현하는 데는 일주일이 걸립니다. 하지만 갱신(refresh), 교체(rotation), 취소(revocation), 그리고 사용자별 저장 기능을 포함하여 다섯 개를 구현하려면 한 분기 내내 매달려야 합니다. 동시성(concurrency) 처리를 잘못하여 두 개의 스레드가 동시에 동일한 일회용 토큰을 갱신하려고 하면, 서비스 제공업체는 이를 재전송 공격(replay attack)으로 간주하고 사용자의 접속을 차단해 버립니다.

전개되는 양상

Salesforce 에이전트를 통해 이 과정을 추적해 보겠습니다. 첫 번째 버전은 하나의 정적인 관리자 토큰(static admin token)으로 실행됩니다. 그러다 영업 이사가 통화에 참여했던 영업 사원의 이름으로 업데이트가 기록되기를 원하게 되면, 여러분은 토큰을 저장, 암호화 및 갱신하기 위한 백그라운드 워커(background worker)를 갖춘 사용자별 OAuth를 구축해야 합니다 (Salesforce 액세스 토큰은 2시간 후에 만료됩니다). 그다음 보안 팀에서 AE(Account Executive)가 퇴사할 경우 어떻게 되는지 묻기 시작하면, 권한 취소(revocation) 기능이 여러분의 IdP(Identity Provider)의 계정 삭제(deprovisioning) 프로세스와 연동되어야 합니다. 각각의 요청은 모두 타당합니다. 하지만 이 모든 것이 합쳐지면 여러분이 애초에 만들려고 했던 것이 아닌 IAM(Identity and Access Management) 클라이언트를 구축하게 됩니다.

결론: 프로토타입에는 로그인이 필요했지만, 프로덕션 에이전트에는 ID 모델(identity model)이 필요합니다. 특히 기업 팀들이 AI 에이전트를 위한 SSO (SSO for AI agents)가 나머지 소프트웨어 스택과 동일하게 작동하기를 기대할 때는 더욱 그렇습니다.

신호 2: 권한 설정이 수동으로 관리되는 if-then 규칙의 거대한 더미가 되어가고 있다

정책 계층(The policy layer): 에이전트가 무엇을 할 수 있는지 결정하는 단계.

이 선을 넘었다는 신호: 코드를 읽지 않고서는 에이전트가 무엇을 할 수 있는지 아무도 말할 수 없을 때.

첫 번째 신호는 인증(Authentication)이었습니다. 즉, 요청자가 누구인지 증명하는 것이었죠. 이것은 인가(Authorization)의 문제입니다. 인가는 더 어려운 절반으로, 그들이 무엇을 할 수 있는지 결정하는 단계입니다. 프로덕션 환경에서 에이전트는 대개 사용자, 에이전트, 그리고 동작을 함께 평가하는 위임된 인가 스택 (delegated authorization stack)을 의미합니다. 처음에는 하나의 깔끔한 체크로 시작합니다. 로그인한 담당자가 수정할 수 있는 경우에만 기록을 업데이트합니다. 그러다 보면 규칙이 기하급수적으로 늘어납니다. Stage를 업데이트하되

결론: 처음에는 if 문이 컨텍스트를 인코딩하는 가장 빠른 방법이지만, 시간이 지나면 이는 문서화되지 않은 정책 시스템이 되며, 단 하나의 잘못된 분기(branch)가 에이전트가 접촉하는 모든 테넌트(tenant)에 폭발적인 영향(blast radius)을 미치게 됩니다.

신호 3: 모든 도구 호출(tool call)에 대한 에이전트 감사 로그(audit logs)가 필요함

증거 계층: 실제로 무슨 일이 일어났는지 재구성하는 것.

임계점을 넘었다는 신호: 사후에 누가 무엇을 했는지 재구성할 수 없을 때.

권한 규칙이 올바르다고 가정해 봅시다. 그럼에도 불구하고 그 규칙들이 준수되었음을 증명할 수 없습니다. 이 신호의 가장 명확한 사례는 다음과 같은 Slack 대화입니다:

"저기, 방금 봇이 그 기회(opp)를 종료한 건가요?"
"그런 것 같은데요?"
"확인 좀 해줄 수 있어요?"
"로그가 롤오버(rolled over)되어 사라졌어요."

이 대화 자체가 발견된 문제입니다. 무언가 잘못되어 보일 때, 여러분은 빠르게 답변해야 합니다: 어떤 실행(run)이 수행되었는지, 누가 승인했는지, 입력값은 무엇이었는지, 하류(downstream)에서 무엇이 변경되었는지, 그리고 승인이 있었는지 말입니다. 만약 답변할 수 없다면, 여러분은 가드레일(guardrails)을 가진 것이 아니라, 단지 주관적인 의견이 반영된 래퍼(wrapper)를 가진 것뿐입니다.

발생하는 이유

감사 가능한 작업(auditable action)은 함께 기록되어야 하는 최소 다섯 가지 측면으로 구성됩니다: 요청 사용자, 에이전트 식별 정보(identity), 권한 결정, 입력값, 그리고 결과로 나타난 변경 사항입니다. 임시방편적인 로깅(Ad-hoc logging)은 한두 가지만 캡처하며, 이들은 서로 다른 시스템에 존재합니다. Salesforce의 필드 이력(Field History)에는 상태 변경 사항은 있지만 그 근거(reasoning)는 없으며, LLM 트레이스(trace)에는 근거는 있지만 변경 사항은 없습니다. 이 둘을 상관관계(correlate) 지어주는 것은 아무것도 없습니다. 가드레일은 특정 시점의 제어 장치(point-in-time controls)인 반면, 감사 추적(audit trails)은 지속적인 증거이며, 실행 시스템(acting systems)에는 이 두 가지가 모두 필요합니다. Slack의 감사 로그 API(Audit Logs API)는 행위자(actor), 작업(action), 엔티티(entity), 그리고 컨텍스트(context)를 제공하지만, 해당 작업이 적절했는지 여부는 명시적으로 알려주지 않습니다.

전개 양상

분기 마감 시점에 금액이 마감일 이후로 이동했다는 이유로 재무팀이 거래를 문제 삼을 때, 여러분은 새로운 값을 확인할 수는 있지만 누가, 누구를 대신하여, 어떤 입력을 바탕으로 이를 변경했는지는 판단할 수 없습니다. 그리고 에이전트가 규제 대상 데이터를 변경(mutate)하는 순간, 이 문제는 더 이상 내부적인 문제에 그치지 않습니다. 45 CFR §164.312(b)의 HIPAA 규정에 따르면, ePHI(전자 보호 건강 정보)를 처리하는 시스템은 활동을 기록하고 검토해야 합니다.

핵심 요약: "LLM 트랜스크립트(transcript)를 가지고 있습니다"라는 말은 감사관(auditor)이 받아들일 수 있는 답변이 아닙니다. 그들에게 필요한 것은 대신 모든 도구 호출(tool call)에 대한 감사 로그(audit logs)와 텔레메트리(telemetry)입니다. 즉, 누가 요청했는지, 어떤 도구가 실행되었는지, 무엇이 변경되었는지, 그리고 해당 작업이 어떻게 승인되었는지를 알아야 합니다.

신호 4: 새로운 시스템이 추가될 때마다 작업량이 늘어나는 것이 아니라 배가되는 경우

통합 계층(integration layer): 하나의 액션을 여러 시스템에 걸쳐 실행하는 것.

임계점을 넘었다는 신호: 다섯 번째 커넥터(connector)를 구축하는 비용이 첫 번째보다 적게 드는 것이 아니라 더 많이 들 때입니다.

지금까지의 모든 상황은 본질적으로 하나의 에이전트가 하나의 시스템을 상대하는 것이었습니다. 그러다 로드맵이 등장합니다: "Gmail, Calendar, Zendesk, Jira, Slack, 그리고 Salesforce를 추가하세요." 여러분은 6개의 커넥터에 대한 예산을 세우고 그 비용이 대략 비슷할 것이라고 예상합니다. 하지만 실제로는 6개의 서로 다른 인증 모델(auth models), 스코프 어휘(scope vocabularies), 속도 제한(rate-limit) 동작, 스키마(schemas), 페이지네이션(pagination) 스타일, 그리고 감사 영역(audit surfaces)을 마주하게 됩니다. Slack을 추가하는 것이 Salesforce를 추가하는 것보다 쉬워야 했지만, 실제로는 그렇지 않았습니다. 첫 번째 통합에는 2주가 걸렸지만, 다섯 번째 통합에는 5주가 걸렸습니다.

발생하는 이유

당신은 6개의 도구를 추가한 것이 아니라, 6개의 거버넌스 접점 (governance surfaces)을 추가한 것입니다. 그리고 각 접점은 앞서 언급한 징후들을 뒤따라 가져옵니다: 연결해야 할 또 다른 신원 모델 (Sign 1), 인코딩해야 할 또 다른 권한 접점 (Sign 2), 상관 관계를 분석해야 할 또 다른 감사 스트림 (Sign 3). 당신이 덧붙이는 모든 도구는 이 각각의 완전한 인스턴스를 가져옵니다. 에이전트가 여러 시스템을 가로질러 구성 (compose)할 때 상황은 더 악화됩니다. 왜냐하면 단일 논리적 작업(캘린더에서 읽기, Salesforce에서 조회, Slack에 게시)이 단일 연산 내에서 세 가지 신원 전파 (identity propagations), 세 가지 권한 확인 (permission checks), 세 가지 속도 제한 (rate limits), 그리고 세 가지 실패 모드 (failure modes)를 조정해야 하기 때문입니다. 이것이 바로 커넥터 수의 오류 (connector-count fallacy)이며, MCP 게이트웨이 패턴 (MCP gateway pattern)이 피하고자 하는 바로 그 문제입니다.

전개 방식

속도 제한 (rate limits)만으로도 로드맵이 중단될 수 있습니다. Microsoft Graph는 편지함당 동시 요청을 4개로 제한하며, 이 상한선은 2026년 10월 1일에 Exchange Web Services가 은퇴하고 훨씬 여유로운 제한(27개 연결)이 사라지면 더욱 뼈아프게 다가올 것입니다. 에이전트가 후속 조치를 예약할 수 있도록 Outlook을 추가한다고 가정해 봅시다. 에이전트가 회의를 예약하는 동안 처음으로 받은 편지함 스레드를 읽을 때, 이 제한에 걸려 429 오류(Too Many Requests)를 수집하기 시작할 것입니다. 프로토타입 단계에서는 전혀 필요 없었던 중앙 집중식 큐 (centralized queue)와 속도 제한기 (rate limiter)를 구축하는 동안 로드맵은 중단됩니다.

결론: 도구 하나를 더 추가하는 것은 가산적인 것이 아니라, 이미 연결된 모든 것에 대해 곱하기로 작용합니다.

징후 5: 새로운 팀마다 동일한 인프라를 재구축함

재사용 계층 (The reuse layer): 에이전트와 팀 전체에 걸쳐 작업을 분할 상환함.

임계점을 넘었다는 신호: 다음 팀이 아무것도 포크(fork)하지 않고 제로 베이스에서 시작할 때.

네 번째 신호는 하나의 에이전트에 도구(tools)를 추가하는 비용이었습니다. 이것은 기업에 에이전트를 추가하는 비용이며, 다른 축에서 관찰되는 것과 동일한 배수 효과를 나타냅니다. 영업 운영(sales ops) 에이전트는 수개월간의 보안 승인, 토큰 저장 코드, 그리고 맞춤형 감사 로깅(audit logging)을 거친 후에야 배포됩니다. 한 달 후, 지원 팀은 Zendesk 티켓이 생성될 때 Salesforce 레코드를 가져오는 에이전트를 원합니다. 그들은 영업 팀의 리포지토리(repo)를 살펴보지만 결국 처음부터 다시 시작합니다. 인증(auth)은 하나의 큐잉 모델(queueing model), 하나의 스코프(scopes) 세트, 하나의 감사 싱크(audit sink)와 얽혀 있습니다. 그들의 로깅은 Salesforce를 가정하고 있습니다. 어떤 것도 깔끔하게 가져다 쓸 수 없으므로, 이제 두 팀 모두 병렬적인 인증 코드를 유지 관리해야 하며, 보안 팀은 동일한 위험에 대해 두 가지 패턴을 검토해야 합니다.

왜 이런 일이 발생하는가