사내 AI 에이전트에 MCP 런타임이 필요하다는 6가지 신호
Source: Dev.to
수익 운영 팀의 누군가가 영업 담당자에게 CRM 정리를 계속 독촉하는 데 지쳤다. 그래서 에이전트를 연결했다. Salesforce에 MCP 서버가 있고, 모델이 도구를 호출할 수 있으며, 워크플로는 명확하다: 회의 녹취록을 가져와서 다음 단계를 추출하고, 기회를 업데이트하고, 활동을 기록하고, 후속 작업을 푸시한다. 오후에 작업을 한 번, .env 파일에 API 토큰 하나만 넣으면 시스템이 돌아간다.
작동한다. AE들은 불평을 멈추고, 데모는 사내에 퍼진다. 일주일 안에 다른 두 팀이 Zendesk와 Jira용으로 같은 것을 원하고, 당신은 조용히 회사 안에서 프로덕션 에이전트 AI의 소유자가 된다.
그때부터는 오후 프로젝트가 아니다. 에이전트가 다른 사람을 대신해서 행동하기 시작하면서, 프로토타입을 빠르게 만들게 해준 모든 지름길이 print() 한 줄로는 답할 수 없는 질문으로 바뀐다.
인증, 권한, 감사 로그, 통합, 재사용, 혹은 위험 소유권이 프로토타입 단계에서 벗어나기 시작하면 AI 에이전트를 위한 MCP 런타임이 필요하다.
MCP는 도구 연결을 표준화하지만, 그 자체만으로는 프로덕션 거버넌스를 해결하지 못한다.
MCP 런타임은 아이덴티티, 정책, 도구 실행, 증거를 중앙화하여 AI 에이전트를 프로덕션에 배포할 때 이 레이어들을 새로 구축할 필요가 없게 만든다.
당신은 올바른 것을 만들었다. 프로토타입‑우선 접근은 올바른 첫걸음이다. 모델이 도구를 호출할 수 있고 MCP 서버가 기능을 노출할 수 있게 되면, 프로토타입은 저렴하게 조립할 수 있다. 작은 팀은 제한된 해피 패스를 감당할 수 있다. 현재 규모로 에이전트를 운영하는 모든 팀은 정확히 당신이 지금 있는 지점, 즉 하나의 워크플로, 하나의 테넌트, 가벼운 사용량, 관대한 위험 자세에서 시작했다.
첫 번째 버전이 작동하는 이유는 은밀히 속였기 때문이다. 이를 만든 엔지니어가 보안 경계다. 에이전트가 건드릴 수 있는 레코드를 알고, 프롬프트를 작성했으며, 토큰을 보유하고 있다. “이 에이전트가 무엇을 할 수 있어야 하는가?”라는 질문은 “내가, 만든 사람이 할 수 있는 모든 것”이라는 답으로 해결된다. 이 가정은 에이전트가 당신이 아닌 다른 사람을 위해 일을 하기 시작할 때까지는 유효하다.
작동하는 프로토타입과 실제 인프라가 필요한 상황을 구분하는 여섯 가지 징후가 있다. 별난 것은 없으며, 대부분은 당신의 레포지토리에서 바로 확인할 수 있다.
아이덴티티 레이어: 도구를 실제로 호출하는 주체를 증명한다.
건너뛰었다고 판단되는 시점: auth/ 디렉터리가 tools/ 디렉터리보다 커졌을 때.
레포를 살펴보라. tools/ 디렉터리가 형제인 auth/ 디렉터리를 만들었고, 이제 auth/가 더 커졌다. 스탠드업 회의 주제가 “에이전트를 어떻게 개선할까”에서 “왜 이 사용자의 리프레시 토큰이 실패했는가”, “에이전트가 어떤 계정을 사용하고 있는가”로 바뀌었다. 새로운 엔지니어의 첫 티켓이 “Slack 추가”인데 두 주가 걸린다.
행동하는 에이전트는 사용자와 하위 API 사이의 딱 중간에 위치한다. 이는 다중 사용자 AI 에이전트 인증·인가 메커니즘을 직접 관리해야 함을 의미한다. 엔터프라이즈 API는 아이덴티티 표준을 공유하지 않는다. 예를 들어 Slack은 접근 토큰을 12시간마다 회전하고, GitHub은 설치 토큰을 1시간, 리프레시 토큰을 6개월에 만료시키며, Microsoft Graph는 위임된 접근과 앱 전용 접근을 각각 별도의 동의 모델로 구분한다. 하나 구현하는 데 일주일, 다섯 개를 구현하고 리프레시·회전·폐기·사용자별 저장까지 하면 최소 한 분기가 걸린다. 동시성을 잘못 잡아 두 스레드가 같은 일회용 토큰을 동시에 리프레시하면 제공자는 이를 재생 공격으로 간주하고 사용자를 잠그게 된다.
Salesforce 에이전트를 예로 들면, 첫 버전은 정적 관리자 토큰 하나로 동작한다. 이후 영업 이사가 통화를 담당한 영업 사원의 이름으로 업데이트를 기록하길 원해 사용자별 OAuth와 백그라운드 워커를 만들어 토큰을 저장·암호화·리프레시한다( Salesforce 접근 토큰은 2시간마다 만료). 그 다음 보안팀이 AE가 퇴사하면 어떻게 할지 묻자, 토큰 폐기를 IdP의 탈퇴 프로세스와 연동해야 한다. 각각의 요구는 합리적이지만, 합쳐지면 전혀 만들 의도가 없던 IAM 클라이언트가 된다.
핵심: 프로토타입은 로그인만 필요했지만, 프로덕션 에이전트는 특히 엔터프라이즈 팀이 SSO를 기대하게 되면 아이덴티티 모델이 필요하다.
정책 레이어: 에이전트가 할 수 있는 일을 결정한다.
건너뛰었다고 판단되는 시점: 코드를 읽지 않고는 에이전트가 무엇을 할 수 있는지 말할 수 없을 때.
첫 번째 징후는 인증(누가 물었는가)이었다. 이번은 인가(무엇을 할 수 있는가)이며, 프로덕션에서는 보통 사용자·에이전트·행동을 동시에 평가하는 위임 인가 스택을 의미한다. 간단한 체크 하나로 “서명된 영업 사원이 편집할 수 있는 경우에만 레코드 업데이트”를 시작하지만, 규칙은 곧 복잡해진다. 예: “Update Stage”는 “Pipeline Manager” 권한 집합만 허용, “Closed‑won” 업데이트는 매니저 승인 필요, EMEA는 예외, SDR은 노트는 편집 가능하지만 고급 단계는 편집 불가 등. 각각은 정당한 비즈니스 요구이며, 모두 permissions.py에 분기와 주석(# do NOT remove, breaks renewals team)으로 쌓이다가 스프린트 하나에 새로운 권한 요청이 들어온다.
문제는 구조적이다. 인가는 주체, 객체, 컨텍스트에 의존하고, 인라인 조건문은 이 차원을 절차적 혼합물로 전락시킨다. NIST의 ABAC 가이드라인이 바로 이 문제를 위해 존재하고, Open Policy Agent와 같은 도구는 정책을 애플리케이션 코드 밖으로 외부화한다.
Salesforce는 경고 사례다. 프로필, 권한 집합, 공유 규칙, 필드 수준 보안 등 20년 넘게 손으로 관리해 온 복잡한 권한 모델을 가지고 있다. 이를 Python으로 일부 재구현하는 에이전트는 소수 인력으로 동일한 여정을 시작하는 셈이다.
핵심: 초기에는 if 문이 가장 빠른 컨텍스트 인코딩 방식이지만, 나중에는 문서화되지 않은 정책 시스템이 되고, 하나의 잘못된 분기가 에이전트가 건드리는 모든 테넌트에 큰 영향을 미친다.
증거 레이어: 실제로 무슨 일이 일어났는지 재구성한다.
건너뛰었다고 판단되는 시점: 사후에 누가 무엇을 했는지 재구성할 수 없을 때.
권한 규칙이 올바르다고 가정해도, 실제로 준수했는지 증명할 수 없다. 가장 명확한 예는 Slack 스레드이다:
“야, 봇이 방금 그 기회를 닫았어?”
이 대화 자체가 의심이다. 뭔가 잘못 보이면 빠르게 답해야 한다: 어느 실행이었는가, 누가 승인했는가, 입력은 무엇이었는가, 하위 시스템에 어떤 변화가 있었는가, 승인이 있었는가? 답을 못하면 가드레일이 없는 것이고, 의견이 반영된 래퍼에 불과하다.
감사 가능한 행동은 최소 다섯 가지 요소를 함께 기록해야 한다: 요청 사용자, 에이전트 아이덴티티, 인가 결정, 입력, 결과 변화. 임시 로깅은 하나 또는 두 개만 캡처하고, 서로 다른 시스템에 흩어져 있다. Salesforce 필드 히스토리는 상태 변화는 기록하지만 이유는 없고, LLM 트레이스는 이유는 있지만 변화는 없다; 두 정보를 연결해 주는 것이 없다. 가드레일은 순간 제어, 감사 로그는 영구 증거이며, 실행 시스템은 둘 다 필요하다. Slack Audit Logs API는 행위자, 행동, 엔터티, 컨텍스트를 제공하지만, 행동이 적절했는지는 알려주지 않는다.
예를 들어 회계팀이 분기 마감 시점에 금액이 마감일 이후에 변경된 거래를 발견하면, 새로운 값은 보이지만 누가, 누구를 대신해, 어떤 입력을 기반으로 바꿨는지는 알 수 없다. 에이전트가 규제 데이터를 수정