AI 에이전트 도구 연결 5가지 패턴: 직접 연결부터 OAuth, MCP, 토큰 교환, 볼트까지

핵심 메시지

• 가장 단순한 직접 연결은 에이전트가 자기 자격증명으로 도구에 접속하기 때문에, 도구 입장에서는 실제 사용자가 누구인지 전혀 알 수 없다.
• OAuth를 붙이면 사용자 인증은 되지만 에이전트가 사용자를 사칭하는 구조가 되고, 90일까지 살아 있는 장기 토큰이 생긴다는 부담이 따라온다.
• MCP(Model Context Protocol)를 중간에 두면 에이전트가 도구마다 다른 연결 방식을 알 필요가 없어지는 추상화 계층이 생긴다.
• 토큰 교환을 도입하면 사용자뿐 아니라 에이전트도 인증되고, 에이전트가 사용자를 '대신해서' 일한다는 위임 관계가 기록으로 남는다.
• 가장 권장되는 방식은 장기 토큰을 볼트에 가둬두고 MCP에는 짧게 만료되는 자격증명만 발급하는 구조다.

쉽게 이해하기

AI 에이전트가 기업 업무 절차 안으로 들어오면서, 에이전트를 사내 도구에 어떻게 연결할지가 실질적인 설계 문제가 됐다. IBM 기술 채널의 이 영상은 실무에서 흔히 쓰이는 다섯 가지 연결 패턴을 보안 수준이 낮은 것부터 높은 것 순으로 되짚는다. 각 단계는 앞 단계의 약점을 하나씩 메우는 형태로 이어진다.

가장 낮은 단계인 직접 연결은 생성형 AI 초기와 RAG 시스템에서 널리 쓰이던 방식이다. API 키나 서비스 계정 같은 기존 수단으로 에이전트가 도구에 바로 붙기 때문에 구축이 쉽지만, 도구는 요청을 보낸 사람이 누구인지 알 방법이 없다. 그래서 초기에는 회사 전체에 공개된 정보만 다루도록 범위를 좁혀 이 문제를 우회했다.

네 번째 패턴은 여기에 OAuth 인증을 더한다. GitHub, Jira, Slack처럼 자체 OAuth를 갖춘 도구가 사용자를 인증하고 액세스 토큰을 발급하면, 에이전트가 그 토큰으로 접속한다. 이미 검증된 표준을 쓴다는 장점이 있지만, 도구는 여전히 에이전트의 존재를 보지 못한 채 사용자만 인식하고, 발급된 토큰이 오래 살아남는다는 문제가 남는다.

세 번째 패턴은 여기에 MCP를 끼워 넣는다. 인증 흐름 자체는 같지만 에이전트는 이제 MCP와 대화하는 법만 알면 되고, 도구별 연동 방식을 일일이 익힐 필요가 없어진다. 두 번째 패턴은 OAuth 대신 토큰 교환을 도입해 에이전트 자신을 인증하고, 사용자가 에이전트에게 작업을 위임했다는 관계를 시스템이 추적할 수 있게 만든다.

1위로 꼽힌 구조는 여기에 볼트를 더한다. 오래 사는 토큰은 통제된 볼트 안에만 보관하고, MCP에는 짧은 수명의 자격증명만 내려준다. 토큰이 중간에 가로채여도 곧 만료되기 때문에 재사용 위험이 크게 줄어든다.

주요 인사이트

• 다섯 패턴은 서로 대체 관계가 아니라 누적 관계다. 뒤 단계일수록 앞 단계에서 드러난 약점(사용자 불투명성, 사칭, 도구 종속, 장기 토큰)을 순서대로 걷어낸다.
• '누가 요청했는가'와 '무엇이 요청했는가'는 다른 문제다. OAuth만으로는 사용자만 보이고, 토큰 교환 단계에 와서야 에이전트라는 행위 주체가 시스템에 드러난다.
• MCP의 가치는 보안보다 결합도 완화에 있다. 에이전트가 도구마다 다른 연동 코드를 갖지 않아도 되는 추상화 계층이라는 점이 이 영상이 짚는 핵심이다.
• 장기 토큰은 편의성의 대가다. 90일짜리 액세스 토큰이 로컬에 저장되는 순간, 유출 시 피해 기간도 그만큼 길어진다.
• 볼트는 '토큰을 없애는' 장치가 아니라 '토큰의 수명을 관리하는' 장치다. 긴 토큰은 격리하고 짧은 토큰만 유통시키는 분리가 요점이다.

자주 묻는 질문

관련 AI 소식