기업 보안 검토 자리에서 에이전트 이야기가 나오면 질문은 대개 하나로 수렴한다. "어떤 도구를 붙였습니까." 승인된 커넥터 목록이 나오면 그 자리는 정리된다. 목록이 곧 통제라고 보는 것이다.
7월에 확정된 두 건의 표준화 소식은 그 목록을 만드는 일을 훨씬 쉽게 만들었다. 동시에 그 목록이 무엇을 보증하지 않는지도 스펙 문서에 적어 두었다.
두 규격 모두 '연결까지'라고 못 박았다
7월 14일 구글은 마이크로소프트, GitHub, Hugging Face, Cisco, Databricks, NVIDIA, Salesforce, ServiceNow, Snowflake 등과 함께 ARD(Agentic Resource Discovery) 규격을 공개했다. 조직이 ai-catalog.json으로 제공 기능을 기술하면 레지스트리가 이를 모으고, 에이전트는 하드코딩된 연동 대신 작업 의도로 검색한다. 리소스 소유권은 도메인 기반으로 검증한다. 규격 설명은 ARD가 MCP·OpenAPI를 대체하지 않으며 호출이 아니라 발견을 다룬다고 분명히 한다.
같은 달 MCP의 EMA(Enterprise-Managed Authorization) 확장이 stable로 올라갔다. 서버마다 뜨던 동의 창을 조직 IdP 로그인 한 번으로 대체한다. 사용자가 ID-JAG(Identity Assertion JWT Authorization Grant)를 액세스 토큰으로 교환하는 방식이다. 여기에도 같은 단서가 붙는다. 이것은 개별 행위에 대한 런타임 권한 부여가 아니고, 토큰 발급 이후 IdP는 MCP 트래픽을 들여다보지 않는다.
서로 다른 문제를 푼 두 규격이 같은 지점에서 멈춘다. 무엇을 찾을 수 있는지, 누가 접속할 수 있는지는 표준이 생겼다. 토큰이 나간 뒤 에이전트가 어떤 레코드를 읽고 무엇을 덮어썼는지는 두 규격 어디에도 없다.
승인 목록은 통제의 증거가 아니라 통제의 범위다
ARD의 첫 구현 중 하나인 GitHub Agent Finder는 6월 17일 전 요금제에 열렸다. 평문으로 작업을 설명하면 인덱스를 검색해 순위를 매긴 후보를 돌려주고, 공개 카탈로그와 사내 레지스트리 중 어느 쪽을 볼지 조직이 정한다. GitHub는 자동 설치는 하지 않으며 무엇을 실제로 연결할지는 사람이 정한다고 명시했다.
사람 한 단계가 남아 있다는 뜻이다. 다만 그 단계가 지키는 것은 '무엇이 연결됐는가'까지다. 커넥터 심사를 아무리 촘촘하게 해도, 승인된 티켓 시스템 하나에 붙은 에이전트가 티켓 열 건을 잘못 종결하는 일은 그 심사 밖에서 벌어진다. 감사 로그에는 승인된 연결만 남고, 그 로그는 완전해 보인다.
InfoQ가 인용한 커뮤니티 논의도 ARD의 실효는 노출된 도구의 품질과 접근·과금 모델에 달려 있다고 짚었다. 발견이 쉬워질수록 목록은 길어지고, 목록 심사에 쓰던 시간의 한계 효용은 떨어진다.
검사 지점을 행동 쪽으로 옮겨야 한다
실무에서 바꿀 것은 두 가지다. 권한은 커넥터가 아니라 대상 시스템에서 건다. 에이전트 전용 계정에 실제 필요한 범위만 부여하고, 되돌릴 수 없는 조작은 별도 승인 경로로 뺀다. 그리고 로그는 연결 이벤트가 아니라 변경 이벤트를 기준으로 남긴다.
교육에서도 같은 이동이 필요하다. "어떤 도구를 쓰는가"를 가르치는 과정은 이제 반나절이면 끝난다. 남는 것은 에이전트가 실행한 결과를 어떤 기준으로 되짚고 무엇을 되돌릴지 정하는 일이고, 이건 도구 교육이 아니라 업무 프로세스 설계다.
조녁컴퍼니가 AX 전환 교육과 컨설팅에서 커넥터 목록보다 검토·승인·롤백 절차를 먼저 다루는 이유가 여기에 있다. 표준이 대신 해주지 않는 구간이 정확히 그곳이다.