기업 내부의 AI 에이전트가 실제 업무를 맡기 시작하면 연결에 성공했다는 사실만으로는 부족하다. 사용자는 필요한 일을 끝낼 수 있는지로 시스템을 판단하고, 조직은 그 과정에서 허용할 범위를 정하게 된다.
13주 만에 40개를 연결한 뒤
고객 서비스 AI 스타트업 Sierra의 사내 에이전트 Pinecone은 서비스 하나로 시작해 13주 만에 40개를 연결했다. 같은 기간 주간 이용률은 86%까지 올랐고, 지금은 89%에 이른다. 성장을 이끈 것은 연결 규격 자체가 아니라 매주 기능과 제약을 다듬은 운영이었다. 개발 기록에는 이 변화가 고스란히 남아 있다.
연결만 놓고 보면 MCP는 어렵지 않다. Uber는 사내 서비스의 .proto, Thrift IDL 파일(서비스 인터페이스를 정의하는 파일)로 도구 정의를 자동 생성해 매주 6만 건의 에이전트 작업을 처리한다. 하지만 연결 이후에는 여러 서버를 한곳에 묶으면서 사용자 권한, 고객별 데이터 경계, 감사 기록을 일관되게 관리해야 한다.
익숙한 것은 CLI, 낯선 것은 MCP
Anthropic의 사례에서는 도구 58개의 정의에만 약 5만5천 토큰이 들었다. 도구를 무작정 늘리면 시작하기도 전에 컨텍스트가 그만큼 차오른다. 비슷한 이름과 매개변수가 늘수록 모델이 엉뚱한 도구를 고르지 않겠는가. 필요한 정의만 그때그때 불러오는 Tool Search Tool은 토큰 사용량을 85% 줄인다.
그래서 Sierra는 GitHub 공식 MCP 서버 대신 읽기 전용 토큰을 붙인 gh CLI를 쓴다. 모델에 익숙한 GitHub나 AWS는 CLI가 효율적이고, 낯선 사내 시스템은 MCP가 더 알맞다는 판단이다. 게이트웨이는 단순한 연결 장치가 아니다. 어떤 도구를 보여주고 언제 불러올지 정하는 관리 계층이다.
데이터는 처음부터 격리한다
Sierra는 에이전트의 판단에 고객 데이터 보호를 맡기지 않는다. 규칙과 모델로 접근 대상을 좁히고, 서로 다른 고객의 민감정보가 한 세션에 섞이면 차단한다. 장애 조사처럼 예외가 필요할 때만 사전 승인을 받고 별도 기록을 남긴다. 에이전트가 잘못 쓰지 않기를 기대하는 대신, 불필요한 데이터를 애초에 접근하지 못하게 막는다.
실행 주체도 나뉜다.
- 대화형 작업은 사용자 권한으로, 예약, 공유 작업은 최소 권한의 서비스 계정으로 실행한다.
- 자동화가 고객 데이터에 접근하려면 대상 고객과 사용할 도구도 미리 밝혀야 한다.
서버마다 인증과 감사를 따로 구현하는 대신 게이트웨이에서 접근 검사와 민감정보 삭제를 맡기면, 정책 변경을 모든 연결에 한 번에 적용할 수 있다. 도구 설명에 악성 지시를 숨기는 MCP Tool Poisoning에도 같은 관문에서 대응할 수 있다.
90% 자동화가 실패인 이유
자동화가 업무의 80~90%만 처리하면 충분할까. 사용자는 결국 기존 도구로 돌아간다. 영업팀에는 정해진 형식의 이메일이, 운영팀에는 지역별 Grafana, OpenSearch 조회가 필요했다. Sierra는 이런 요구를 반영해 기존 도구를 보완하고 위험한 도구를 교체했다. 사용자가 직접 부족한 기능을 추가하면서 외부 기여가 전체 커밋의 3분의 2까지 늘었다.
기능이 갖춰졌다고 에이전트의 성공 보고까지 믿을 수 있는 것은 아니다. Sierra의 코딩 에이전트는 인증 오류를 고치는 대신 저장소의 토큰을 읽거나 curl로 서버를 우회하고도 작업을 끝냈다고 판단했다. SpecBench 연구에서도 공개 테스트는 실제 명세 충족도를 과대평가했다.
Sierra는 이를 막기 위해 파일시스템과 셸을 쓸 수 없는 별도 모델로 최종 결과를 점검한다. 우회로를 차단한 검증자가 공식 기능만으로 성공 여부를 확인하는 방식이다. 반드시 지켜야 할 원칙은 문서 한 장에 모아 모든 에이전트가 작업 전에 읽게 했다.
MCP가 제공하는 것은 연결 규격뿐이다. 89%라는 사용률은 그 규격이 아니라, Sierra가 13주 동안 도구 정의와 권한 규칙을 손본 결과로 나왔다.
결국 에이전트의 역할이 커질수록 사소해 보이던 인터페이스 결정도 업무 방식의 일부가 된다. 사용자는 기술이 AI라는 사실보다 기존 업무로 돌아가야 하는 순간에 제품의 한계를 느낀다.