[한글자막] AI 에이전트와 도구를 연결하는 5가지 핵심 패턴: API부터 MCP까지

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI 에이전트와 도구를 연결하는 다섯 가지 핵심 패턴은 API 키 직접 연결에서 OAuth·MCP·위임형 토큰 교환·볼트 기반 단기 자격 증명으로 발전하며 사용자와 에이전트의 신원 가시성과 보안을 높이는 설계 경로다.

📌 핵심 요점

1. API 키나 서비스 ID를 사용하는 직접 연결은 기존 방식을 재사용할 수 있어 구현이 빠르지만, 도구가 실제 사용자의 신원과 접근 권한을 확인할 수 없다는 근본적 한계가 있다.
2. OAuth를 도입하면 GitHub·Jira·Slack 등이 사용자를 인증하고 사용자 권한에 맞는 접근 토큰을 발급할 수 있지만, 도구에는 작업 주체인 에이전트의 신원과 의도가 보이지 않아 사용자 가장과 장기 토큰 오용 위험이 남는다.
3. MCP는 OAuth와 접근 토큰 흐름을 유지하면서 에이전트와 개별 도구의 직접 결합을 줄인다. 에이전트가 도구별 호출법 대신 MCP 규격만 이해하면 여러 도구를 일관된 방식으로 사용할 수 있다.
4. 위임 기반 토큰 교환은 사용자뿐 아니라 에이전트도 인증하고, 사용자가 허용한 특정 작업을 에이전트에 위임한다. 이를 통해 사용자·에이전트·허용 작업을 함께 식별하고 추적할 수 있다.
5. 볼트 기반 구조는 장기 토큰을 통제된 저장소에 보관하고 실제 작업에는 사용자별 단기 자격 증명만 노출한다. 토큰이 탈취되더라도 재사용 가능한 시간을 줄여 장기 자격 증명 위험을 낮춘다.

🧩 배경과 문제 정의

• 기업 업무 프로세스에 에이전트 시스템이 빠르게 통합되면서, 에이전트가 외부 도구를 어떤 인증·권한 구조로 호출할지가 핵심 설계 문제가 됐다.
• API 키 기반 직접 연결은 구현이 간단하지만 실제 사용자의 신원과 권한을 도구가 확인할 수 없어, 사용자별 접근 통제가 필요한 업무에는 한계가 있다.
• 다섯 가지 패턴은 OAuth 사용자 인증, MCP 추상화, 위임 기반 토큰 교환, 볼트 기반 단기 자격 증명으로 발전하며 신원 가시성과 보안을 단계적으로 강화한다.

🕒 시간순 섹션별 상세정리

1. API 키 기반 직접 연결의 기본 구조

• 사용자는 에이전트와 상호작용하고, 에이전트는 API 키나 서비스 ID 같은 자체 자격 증명으로 도구에 직접 연결해 정보를 가져온 뒤 LLM으로 요청과 응답을 처리한다. [00:58]
• 기존 연결 방식을 그대로 재사용하므로 구현이 단순하고 빠르며, 별도의 인증·중개 계층 없이 에이전트와 도구를 결합할 수 있다. [01:31]

2. 사용자 신원이 사라지는 직접 연결의 한계

• 도구에는 에이전트의 자격 증명만 보이므로 실제 사용자가 누구인지, 해당 데이터에 접근할 권한이 있는지 판별할 수 없다. [01:52]
• 초기 생성형 AI 환경에서는 공개 정보나 전사 공용 정보만 접근하도록 제한해 문제를 우회했지만, 사용자별 권한이 필요한 민감한 업무로 확장하기 어렵다. [02:08]

3. OAuth 인증이 해결한 문제와 새로 만든 위험

• 신원 제공자와 OAuth를 연결하면 GitHub·Jira·Slack 같은 도구가 사용자를 인증하고 접근 토큰을 발급하며, 에이전트는 이 토큰으로 사용자 권한에 맞춰 도구를 호출할 수 있다. [02:58]
• 도구에는 사용자만 보이고 실제 작업 주체인 에이전트의 신원·의도·허용 범위는 보이지 않아, 에이전트가 사용자를 가장하는 구조가 된다. [04:22]

4. MCP를 통한 도구 연결 추상화

• 기존 OAuth 인증과 접근 토큰 흐름 사이에 MCP를 배치하면 인증 구조를 유지하면서 에이전트와 개별 도구의 직접 결합을 줄일 수 있다. [05:44]
• 각 에이전트가 도구별 호출법을 모두 알아야 했던 구조와 달리, MCP 추상화 계층에서는 에이전트가 MCP 규격만 이해하면 여러 도구를 일관된 방식으로 사용할 수 있다. [06:30]

5. 토큰 교환과 사용자 대신 수행하는 위임 구조

• 사용자 대신 수행하는 토큰 교환 구조에서는 에이전트도 자신의 신원을 인증하고, 사용자는 특정 도구 작업을 에이전트에 위임하므로 사용자와 에이전트를 동시에 식별할 수 있다. [07:30]
• 토큰 교환 계층은 접근 토큰이 여러 구성 요소를 거쳐 전달되는 과정을 보호하며, 인증된 사용자와 인증된 에이전트의 관계를 토큰 흐름에 유지한다. [08:03]

6. 볼트 기반 단기 자격 증명으로의 전환

• 장기 접근 토큰은 탈취 후 재사용될 수 있지만, 토큰 수명을 짧게 제한하면 공격자가 토큰을 가로채더라도 악용 가능한 시간이 크게 줄어든다. [10:13]
• 장기 토큰은 통제된 볼트에 보관하고 볼트가 사용자별 단기 자격 증명을 MCP에 발급함으로써, 실제 에이전트 작업 흐름에는 수명이 짧은 자격 증명만 노출된다. [10:35]

🧾 결론

• 에이전트 연결 구조의 성숙도는 단순한 도구 호출 가능 여부보다 사용자와 에이전트의 신원을 얼마나 명확하게 구분하고 추적할 수 있는지에 달려 있다.
• MCP는 도구 연결을 표준화하고 결합도를 낮추지만, 에이전트 신원과 위임 범위를 보장하려면 별도의 토큰 교환 구조가 필요하다.
• 위임형 토큰 교환과 볼트 기반 단기 자격 증명을 결합할수록 사용자 가장, 장기 토큰 탈취, 재사용 공격의 위험을 단계적으로 줄일 수 있다.

📈 투자·시사 포인트

• 기업용 에이전트 솔루션을 평가할 때는 연동 가능한 도구 수뿐 아니라 사용자 신원, 에이전트 신원, 허용 작업을 함께 기록할 수 있는지를 확인해야 한다.
• MCP 지원 여부만으로 보안 수준을 판단하기보다 MCP 추상화 뒤에서 OAuth, 토큰 교환, 위임 관계가 어떻게 구성되는지 분리해 살펴볼 필요가 있다.
• 볼트 보관, 단기 자격 증명 발급, 토큰 수명 통제, 감사 가능성은 민감한 기업 업무로 에이전트를 확장할 때 중요한 설계 평가 요소가 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 다섯 가지 패턴의 보안상 발전 방향은 제시되지만, 각 구조의 도입 비용·응답 지연·운영 복잡도를 비교한 정량 자료는 제공되지 않는다.
• GitHub 접근 토큰이 90일 이상 유지될 수 있다는 설명은 설정에 따른 사례이므로 모든 OAuth 토큰의 기본 수명으로 일반화해서는 안 된다.
• MCP, 토큰 교환 계층, 볼트를 함께 운영할 때 발생할 수 있는 장애 처리, 도구별 호환성, 토큰 폐기 방식은 구체적으로 설명되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 에이전트가 API 키나 서비스 ID로 직접 연결하는 도구를 목록화하고, 사용자별 접근 통제가 필요한 연결을 구분한다.
• 각 작업 흐름에서 사용자 신원, 에이전트 신원, 대상 도구, 허용 작업이 어디까지 전달되고 기록되는지 도식화한다.
• MCP 도입 검토 시 도구 호출 추상화와 사용자·에이전트 인증 구조를 별도 항목으로 평가한다.
• 장기 접근 토큰은 통제된 볼트에 보관하고 실제 에이전트 실행에는 단기 자격 증명만 노출하는 방안을 검토한다.

❓ 열린 질문

• 어떤 민감 작업부터 사용자와 에이전트를 동시에 식별하는 위임형 토큰 교환을 의무화해야 하는가?
• 단기 자격 증명의 수명과 갱신 주기를 보안성과 업무 연속성 사이에서 어떻게 설정해야 하는가?
• 여러 도구를 MCP로 연결한 뒤에도 사용자·에이전트·허용 작업의 관계를 종단 간 일관되게 감사할 수 있는가?