AI 에이전트와 도구를 연결하는 5가지 핵심 패턴

메타데이터

• 채널: Tech Bridge
• 원문 제목: [한글자막] AI 에이전트와 도구를 연결하는 5가지 핵심 패턴: API부터 MCP까지
• 원본 발행일: 2026-08-18
• URL: https://www.youtube.com/watch?v=CSVg3rUZSQo
• 영상 길이: 약 11분 17초
• 주제: 에이전트(Agent)와 기업 도구를 연결하는 인증·권한·자격 증명(credential) 아키텍처

---

📌 핵심 질문 / 이 글이 답하는 핵심 논점

==에이전트와 도구의 연결은 단순한 API 호출에서 시작해 사용자 인증, MCP 추상화, 에이전트 위임, 금고 기반 단기 자격 증명으로 발전하며, 단계가 올라갈수록 보안·가시성·관찰 가능성이 강화된다.==

• 직접 연결은 API 키(API key)나 서비스 ID(service ID)를 사용해 빠르게 구축할 수 있지만 도구가 실제 사용자를 알 수 없다.
• OAuth는 사용자를 인증하지만 에이전트가 사용자를 사칭(impersonation)하는 문제가 남고, 장수명 액세스 토큰(access token)이 위험해질 수 있다.
• MCP(Model Context Protocol)는 도구별 지식을 에이전트에서 분리하는 추상화 계층(abstraction layer)을 제공한다.
• 토큰 교환(token exchange)은 사용자와 에이전트를 모두 식별하고, 사용자가 에이전트에 작업을 위임했다는 관계를 토큰 흐름에 반영한다.
• 금고(vault)는 장기 토큰을 통제된 저장소에 보관하고 MCP에는 짧은 수명의 자격 증명만 발급해 탈취·재생(replay) 피해 시간을 줄인다.

에이전트 기반 시스템(Agentic system)이 기업 프로세스에 빠르게 통합되면서, 도구를 호출하는 기능 자체보다 “누가 무엇을 대신 수행하는가”와 “그 권한을 얼마나 오래 유지하는가”가 핵심 설계 문제가 된다. 다섯 패턴은 서로 완전히 다른 기술 목록이 아니라, 기존 연결에 인증·추상화·위임·비밀 관리 계층을 차례로 더해가는 보안 성숙도 순서다.

1. 전체 흐름: 다섯 번째에서 첫 번째로 거슬러 올라가는 보안 성숙도

다섯 패턴은 가장 단순한 직접 연결에서 시작해, 매 단계마다 사용자 가시성·에이전트 식별·토큰 보호를 추가한다.

1.1. 패턴의 계층적 변화

1. 패턴 5 — 직접 연결(Direct connection)
   1. 사용자(User)가 에이전트와 상호작용하고, 에이전트가 도구(Tool)에 직접 연결된다.
   2. API 키, 서비스 ID 같은 기존 연결 수단으로 정보를 가져와 LLM이 프롬프트와 응답을 처리한다.
2. 패턴 4 — 직접 연결 + OAuth
   1. ID 공급자(Identity Provider)를 추가해 사용자를 인증하고 도구가 액세스 토큰을 발급한다.
   2. 도구는 사용자를 볼 수 있지만, 에이전트가 그 사용자의 자격으로 행동한다.
3. 패턴 3 — OAuth + MCP
   1. 에이전트와 도구 사이에 MCP(Model Context Protocol)를 넣는다.
   2. 에이전트는 개별 도구의 세부 API가 아니라 MCP와 상호작용하는 방법만 알면 된다.
4. 패턴 2 — MCP + 토큰 교환 및 위임
   1. 에이전트 자체를 인증하고 사용자 대신 행동하는 위임(delegation) 관계를 만든다.
   2. 토큰 교환이 토큰 전파(token propagation)를 보호하며 사용자와 에이전트 양쪽에 대한 가시성을 만든다.
5. 패턴 1 — MCP + 금고 + 단기 자격 증명
   1. 장기 액세스 토큰은 금고에 보관하고, MCP에는 사용자를 위한 단기 자격 증명만 발급한다.
   2. 에이전트 흐름이 장기 비밀을 직접 들고 다니지 않게 되어 탈취와 재생의 유효 시간이 짧아진다.

1.2. 패턴을 선택할 때의 축

1. 구현 단순성에서 보안 통제로 이동
   1. 패턴 5는 기존 시스템을 거의 그대로 활용하므로 가장 쉽게 만들 수 있다.
   2. 패턴 1로 갈수록 인증 주체, 위임 관계, 토큰 보관 위치와 수명을 분리해 설계해야 한다.
2. 신원과 권한의 가시성 확대
   1. 직접 연결은 도구가 사용자를 모른다.
   2. OAuth는 사용자를 보여주지만 에이전트의 존재와 권한은 숨긴다.
   3. 토큰 교환과 금고를 더하면 사용자·에이전트·토큰 수명·행동 범위를 함께 관찰할 수 있다.

2. 패턴 5: API 키를 이용한 직접 연결

직접 연결은 사용자 요청을 받은 에이전트가 자기 자격 증명으로 도구를 호출하고, LLM이 결과를 가공해 사용자에게 돌려주는 가장 단순한 모델이다.

2.1. 기본 작동 방식

1. 에이전트와 도구의 일대일 연결
   1. 사용자가 에이전트와 상호작용한다.
   2. 에이전트는 도구에 직접 연결되며, 도구 호출과 데이터 추출을 스스로 수행한다.
2. 기존 GenAI·RAG 구조의 재사용
   1. GenAI(Generative AI) 초기 시스템과 RAG(Retrieval-Augmented Generation) 모델에서 흔히 사용한 방식이다.
   2. 개발자는 API 키(API key), 서비스 ID(service ID) 등 도구가 요구하는 기존 인증 정보를 붙인다.
   3. 도구에서 필요한 정보를 가져오고, LLM(Large Language Model)이 프롬프트와 응답을 처리한 뒤 사용자에게 반환한다.

2.2. 장점과 한계

1. 장점 — 빠르고 직관적인 구축
   1. 이미 보유한 연결 방식보다 훨씬 많은 구성 요소가 필요하지 않다.
   2. 에이전트를 만들고 도구를 연결한 뒤 기존 방식을 사용하면 전체 흐름이 곧바로 작동한다.
2. 한계 — 사용자 가시성 부재
   1. 에이전트는 도구와 통신하지만 자기 자격 증명을 사용한다.
   2. 도구는 요청을 보낸 사람이 누구인지, 그 사용자가 해당 정보에 접근할 권한이 있는지 알 수 없다.
   3. 초기 GenAI 시스템은 이 문제를 공개 정보나 회사 전체에 공개된 정보만 읽도록 제한하는 방식으로 우회했다.
   4. 제한된 데이터 범위에서는 문제가 잘 드러나지 않지만, 개인별 권한이 필요한 기업 도구로 확장하면 구조적인 약점이 된다.

3. 패턴 4: OAuth를 더한 직접 연결

OAuth는 사용자 인증을 직접 연결 흐름에 더해 도구가 사용자 신원을 확인하게 만들지만, 에이전트가 사용자의 자격을 빌려 행동하는 사칭 문제를 남긴다.

3.1. OAuth 인증 흐름

1. ID 공급자와 도구의 역할
   1. 프로세스에 ID 공급자(Identity Provider)를 추가해 사용자를 인증한다.
   2. GitHub, Jira, Slack처럼 자체 OAuth 기능을 제공하는 도구가 인증 흐름을 수행한다.
2. 액세스 토큰 발급
   1. 에이전트가 도구와 통신하면 도구가 “이 사용자는 누구인가? 인증하자”라고 요구한다.
   2. 사용자 인증이 끝나면 도구가 액세스 토큰(access token)을 발급한다.
   3. 에이전트는 토큰으로 도구에 연결하고, 개발 환경에 따라 토큰을 로컬에 저장한다.
   4. Vibe coding으로 개발 도구를 사용할 때 Claude가 도구와 상호작용해 액세스 토큰을 받고 로컬에 저장하는 흐름이 사례로 제시된다.

3.2. 장점과 한계

1. 장점 — 이미 검증된 인증 패턴
   1. OAuth는 확립된 표준적 흐름이라 사용자 인증을 새로 발명할 필요가 없다.
   2. 패턴 5의 직접 연결에 사용자 인증이라는 추가 계층을 얹는 비교적 자연스러운 확장이다.
2. 한계 — 에이전트의 사용자 사칭
   1. 도구 입장에서는 사용자가 정상적으로 접속한 것처럼 보이지만, 실제 요청을 수행하는 주체는 에이전트다.
   2. 도구는 에이전트의 신원, 에이전트가 하려는 일, 에이전트에게 허용된 범위를 알 수 없다.
   3. 따라서 에이전트는 사용자 자격을 빌려 행동하는 형태가 된다.
3. 한계 — 장수명 토큰의 위험
   1. GitHub 같은 도구는 설정에 따라 최대 약 90일 동안 살아 있는 액세스 토큰을 만들 수 있다.
   2. 에이전트가 인증을 끝낸 뒤 토큰을 저장하면, 탈취된 자격 증명이 상당히 오랫동안 유효할 수 있다.

4. 패턴 3: MCP를 삽입한 OAuth 연결

MCP는 에이전트와 도구 사이에 추상화 계층을 둬 도구별 지식을 에이전트 구현에서 분리한다.

4.1. 연결 구조의 변화

1. 기존 인증 흐름 유지
   1. 직접 연결 부분을 제거하고 그 위치에 MCP(Model Context Protocol)를 넣는다.
   2. 에이전트가 도구와 통신하고 OAuth로 애플리케이션을 인증하며 액세스 토큰을 사용하는 큰 흐름은 유지된다.
2. MCP 계층의 위치
   1. 도식의 가운데에 MCP가 들어가 에이전트와 실제 도구 사이의 통신 경계를 만든다.
   2. MCP는 도구를 대신해 모든 권한을 결정하는 장치라기보다, 에이전트가 도구와 대화하는 방식을 표준화하는 중간 계층으로 기능한다.

4.2. 추상화가 주는 이점

1. 에이전트 구현의 단순화
   1. MCP 이전에는 에이전트가 특정 도구를 알아야 했다.
   2. 도구마다 호출법을 알아야 했고, 여러 도구를 사용하는 모든 에이전트가 각 도구와 상호작용하는 방법을 개별적으로 학습·구현해야 했다.
2. 도구 지식의 분리
   1. MCP를 도입하면 에이전트는 개별 도구 자체가 아니라 MCP와 상호작용하는 법만 이해하면 된다.
   2. 에이전트가 도구의 모든 세부 사항을 알 필요가 없어져 새로운 도구 연결과 에이전트 재사용이 쉬워진다.
   3. OAuth와 액세스 토큰을 없애는 단계가 아니라, 기존 흐름 위에 도구 독립성을 추가하는 단계다.

5. 패턴 2: 토큰 교환과 사용자 대신 행동하는 에이전트

토큰 교환은 사용자와 에이전트의 신원을 모두 인증하고, 사용자가 특정 업무를 에이전트에 위임했다는 관계를 토큰 흐름에 담는다.

5.1. 인증·위임 흐름

1. 에이전트 자체 인증
   1. 기존 OAuth 흐름을 그대로 의존하는 대신 토큰 교환(token exchange)을 추가한다.
   2. 시스템이 에이전트에게 스스로 인증하도록 요구해 “이 에이전트가 누구인가”를 확인한다.
2. 사용자와 에이전트의 역할 분리
   1. 사용자는 도구에 대해 수행할 작업을 특정 에이전트에 위임한다.
   2. 에이전트는 사용자를 대신해 행동하지만, 사용자와 동일한 주체로 위장하지 않는다.
   3. 시스템은 사용자 신원과 에이전트 신원을 모두 알게 된다.
3. 토큰 흐름 보호
   1. 액세스 토큰이 시스템 안에서 이동할 때 토큰 교환 계층이 전파 경로를 감싼다.
   2. 토큰 교환은 토큰이 올바른 경로로 전달되도록 보안 계층을 추가한다.

5.2. 개선되는 점

1. 직접 연결·OAuth 의존성의 축소
   1. 단순한 직접 연결을 제거하기 시작하고, 애플리케이션이 OAuth 하나에만 전적으로 의존하지 않게 된다.
   2. 사용자 인증과 에이전트 인증을 결합한 토큰 흐름을 구축한다.
2. 위임과 토큰 전파
   1. 인증된 사용자가 있고 인증된 에이전트가 있으며, 에이전트가 사용자를 대신해 작동한다.
   2. 토큰 전파(token propagation)가 추가되어 사용자 권한이 에이전트의 행동 맥락과 함께 이동한다.
3. 가시성·사칭 문제의 해소
   1. 사용자 가시성이 생겨 시스템이 어떤 사용자의 요청인지 확인할 수 있다.
   2. 에이전트 사칭이 줄어들어 시스템이 사용자와 에이전트, 각각의 허용 범위, 실제 진행 상황을 볼 수 있다.
   3. 관찰 가능성(observability)과 투명성이 확보되어 시스템이 의도한 방식으로 작동하는지 점검할 수 있다.

6. 패턴 1: 금고에서 MCP로 단기 자격 증명 발급

금고는 장기 비밀을 에이전트 흐름에서 분리하고 MCP에 단기 자격 증명(short-lived credentials)을 발급하는 최상위 패턴이다.

6.1. 장기 토큰을 금고에 격리

1. 기존 방식의 문제
   1. OAuth와 패턴 2에서는 사용자의 액세스 토큰을 시스템으로 가져와 오랫동안 저장해야 했다.
   2. 장수명 토큰이 도구·애플리케이션·에이전트 흐름 곳곳에 남는 구조는 탈취 시 피해 범위를 키운다.
2. 금고(vault)의 도입
   1. 금고를 MCP와 상호작용하는 별도 구성 요소로 둔다.
   2. 장기 토큰(long-term token)은 강하게 잠그고 접근을 통제할 수 있는 금고에 보관한다.
   3. 에이전트는 장기 토큰을 직접 보관하거나 전달받지 않는다.

6.2. 단기 자격 증명의 효과

1. MCP를 위한 사용자별 발급
   1. 금고가 해당 사용자를 위해 MCP에 단기 자격 증명을 발급한다.
   2. 에이전트 흐름은 장기 토큰이 아니라 짧은 수명의 자격 증명만 사용한다.
2. 탈취·재생 공격의 시간 제한
   1. 자격 증명이 가로채져 재생(replay)되더라도 공격자가 사용할 수 있는 시간은 잠깐뿐이다.
   2. 유효 기간이 끝나면 같은 자격 증명으로 더 이상 작업을 수행할 수 없다.
   3. 영상의 표현을 빌리면, 탈취자가 잠깐 “웃을” 수는 있어도 오래 즐길 수는 없다.
3. 보안 개선의 의미
   1. 단기 실시간 자격 증명(short-term live credentials)이 패턴 1에 추가되는 핵심 장점이다.
   2. 장기 토큰을 에이전트 흐름에 다시 가져와 저장하는 위험한 조각을 전체적으로 제거한다.

7. 주요 발언 모음

“에이전트와 도구를 연결하는 가장 일반적인 다섯 가지 패턴을 살펴보겠다.”

“직접 연결에서는 도구가 사용자가 누구인지, 접근이 허용되는지 알 수 없다.”

“MCP를 넣으면 에이전트는 도구 자체가 아니라 MCP만 알면 된다.”

“사용자는 자신이 도구에 대해 할 일을 에이전트에 위임한다.”

“금고는 사용자에게 단기 자격 증명을 MCP로 발급한다.”

“다섯 패턴은 앞선 패턴보다 조금씩 더 많은 보안을 제공한다.”

8. 핵심 데이터 & 수치

• 약 11분 17초: 자막으로 확인되는 전체 설명 분량이다.
• 5개 패턴: 직접 연결, OAuth 추가, MCP 추상화, 토큰 교환·위임, 금고·단기 자격 증명 순서다.
• 최대 약 90일: GitHub 등 일부 OAuth 도구가 설정에 따라 발급할 수 있는 장수명 액세스 토큰의 예시다.
• 단기 수명: 패턴 1의 핵심은 특정 고정 만료 시간을 제시하는 것이 아니라, 탈취·재생에 노출되는 시간을 최대한 짧게 만드는 것이다.
• 3개의 주요 신원 축: 사용자(User), 에이전트(Agent), 도구(Tool)가 단계별로 분리·확인된다.

9. 패턴별 비교

패턴	연결 구조	도구가 보는 주체	주요 장점	주요 약점 또는 해결 과제
5	에이전트 → 도구 직접 연결	에이전트 자격 증명만 봄	가장 단순하고 빠름	사용자 가시성과 개인별 권한이 없음
4	직접 연결 + OAuth	사용자로 보이는 에이전트	확립된 사용자 인증 흐름	에이전트가 사용자를 사칭하고 토큰이 장수명일 수 있음
3	에이전트 → MCP → 도구 + OAuth	MCP를 거친 사용자 흐름	도구별 지식을 추상화	인증·토큰 수명 문제 자체는 남음
2	MCP + 토큰 교환 + 위임	사용자와 에이전트 모두	신원 분리, 위임, 토큰 전파, 관찰 가능성	토큰 흐름과 인증 구성이 더 복잡해짐
1	금고 → MCP → 도구, 단기 자격 증명	통제된 사용자·에이전트 흐름	장기 비밀 격리, 재생 시간 최소화	금고 운영과 단기 발급 체계가 필요함

결론 및 시사점

1. 단순한 내부 프로토타입이나 공개 데이터 조회는 패턴 5로 빠르게 시작할 수 있지만, 개인별 권한이 걸린 기업 데이터에는 사용자 가시성이 필요하다.
2. OAuth는 사용자 인증을 해결하는 중요한 중간 단계지만, 사용자 사칭과 장수명 토큰 보관을 해결하지 못한다.
3. MCP는 도구 연결을 표준화하는 추상화 계층으로서 에이전트가 모든 도구의 세부 API를 알아야 하는 부담을 줄인다.
4. 실제 업무 위임을 안전하게 표현하려면 사용자의 신원과 에이전트의 신원을 따로 인증하고 토큰 교환으로 관계를 전파해야 한다.
5. 장기 토큰은 금고에 격리하고, 에이전트와 MCP에는 짧은 수명의 자격 증명만 전달해야 탈취·재생 피해를 제한할 수 있다.
6. 다섯 패턴의 최종 방향은 기능을 더 많이 붙이는 데 있지 않다. 사용자·에이전트·도구의 책임 경계를 분리하고, 토큰의 노출 범위와 수명을 줄이며, 시스템 행동을 관찰 가능하게 만드는 데 있다.